The problem is that those developers are also going to forget to update the ignore-by-default .gitignore to allow files, so there will be missing files. And they won't see any problems, because it works on their machine.
That's fixed by having the CI server compile the code and run tests, and having it fail the merge and publicly shame the offender in slack when that happens.
It's often said that you can't fix behavioral problems with technology, but I've found that tooling that strictly enforces rules is really useful.
In my opinion this will pretty quickly solve itself though. Accidentally committing keys to the repo potentially ruins your entire week. With a default disallow all list, you might have one bad deploy oopsie and then commit the files.
One problem I see all the time is that people are not using proper tools.
Yeah command line is cool and all but I do believe most of the developers should be using UI tooling where staging area is showing nice diffs.
Built in GIT handling in IDE usually is better than command line but also usually worse than dedicated tool like GitExtensions or SourceTree which are free and are super convenient for staging.
People don't know they don't have to stage whole files but they can stage hunks, well in command line it is too much hassle for me but in GUI tools it is no brainer.
If you are working in a team, maybe. Though you are probably better off making sure any files containing keys are already explicitly listed in .gitignore
Plus, it's not the worst idea to exercise your "whoops we leaked our secrets" procedures. You do have procedures, right?
But I'm a little worried that solo developers might follow this device. And then not notice for weeks or months, losing large amounts of git history in the best case; Or potentially massive amounts of actual work if their original development folder is gone.
The world is too mutable for it to exist as a decentralized system, you can set up all these permascrolls and enfilades and tumblers and stuff. But someone is going to see profit in making two-way links one-way or altering the permanent record, so they will. Not to mention what happens just by entropy, servers will get turned off because companies go under or people lose interest. You could make it everybody's problem with something like IPFS, you still would have to solve spammers exploiting the commons.
And it only makes sense for a place where documents are approximately equally popular. If the canonical Harry Potter contained links to all places referring or citing it, it would be one overloaded document.
And then the whole micropayments thing would make it a non-starter, since that have failed badly just about every time it has been tried.
Some people are actually interested in programming, coming and bleating about LLMs making all the finer points of it unimportant is as clueless as a manager coming here and telling us that syntax is unimportant because he has programmers for that crap.
If you don't care, don't go around in programming threads telling you how it doesn't matter anymore. It doesn't matter to you, because you prefer to be ignorant about the details of programming, and you have found tools that let you live in ignorance, good for you. But some of us do care, and are going to continue to do so.
My point isn't that what you are doing is pointless or that you shouldn't enjoy what you do but that it ultimately holds very little economic value especially as someone in charge of hiring developers, their experience is more valuable in the sphere of architectural design than expertise over syntax.
LLMs compile english to whatever code you want and it can write it better, faster and more efficiently than a human can over the long run. You might have an edge in shorter sprints but that gap is quickly reduced when LLMs simply learn and apply whatever optimization they find and it can continue to output without any diminishing returns and at fraction of what it takes to pay a human to do it.
C isn't an iota more fundamental than say Modula-2. It's just more popular. And C is very bad at being a low level language. There are plenty of things that you can express in assembly that you just can't do in C. And then the platform ABI won't support it, since C can't support it, and it hampers other languages that don't have C's limitations.
A couple of examples what's missing from C from a low level perspective: Multiple return values (why can't I have a function using more registers than rax or the stack to push back more values?), sane varargs, stack manipulation (an enabler for coroutines and a lot more)
Generally, in an ideal low-level language I wouldn't expect to be hampered because the language is designed for a notional abstract machine that doesn't have things like an actual stack and contiguous RAM.
Also C isn't well suited to a modern multi-core computer. The "fix" in C11 is to just say we have the C++ 11 Memory Ordering Model and here are some built-ins for the ordered atomic operations that implies.
Having any model at all is probably most of the value and only one part of the model (consume ordering) is unimplementable fantasy so it could have been much worse, but it's hardly a triumph for a "fundamental" language is it?
Rust does have the same Memory Ordering idea (minus the ill-fated "Consume" ordering) but provides richer tools for a modern world than C does. The C standard library provides nothing to actually do concurrency, such as making more threads, nor to synchronize them, such as with a mutex whereas of course Rust provides std::thread::spawn and std::sync::Mutex
In C this is a platform specific problem, for Unix systems you want pthreads for example while Windows provides a different arrangement.
Rust does not provide out-of-the-box structured concurrency - which I would like - but it's a lot closer to what I'd prefer here.
The C standard library has had <threads.h> since C11 https://www.cppreference.com/c/thread and there are now a nonzero number of systems that support it! (glibc, musl, maybe others?)
I'm definitely the wrong person to ask because my solution was to write Rust.
I think the machines C was conceived for are small enough by today's standards that I would not bring a high level language (like C) to the fight, a macro assembler and you'll be fine. For today's much larger machines, use Rust.
Oh you've got 16-bit addressing? Chart all the addresses and what you'll use them for on a white board or a big sheet of paper. You do not need "allocators" like malloc, that's Steve's job, Steve has a sharpie to "allocate" memory on the chart.
Ironically I think to make the best use of such a small memory window, you'd want a compacting garbage collector. Lots of the 16-bit era BASICs used compacting GC for their strings.
Yes you can statically allocate, but who wants an artificial limitation like "16 strings, 256 bytes each" when some users want 200 strings of 8 bytes and some users want 4 strings of 500 bytes. Static allocation is something you can do when your memory is large compared to your use cases.
I think I didn't make it very clear. I think that by fundamental, I meant that C does not do a lot of management on its own. So there is not a lot that another language could do different that adds a lot of value.
That wasn't what it seemed like at the time. Amazon didn't post profits, sure, but they sure as hell weren't a giant money suck either, they didn't need billions in financing to run their business. There were a lot of Amazon bears, but they were concerned about the high valuation, not about them going broke (since even the most pessimistic bear can read a cashflow statement).
Deciding on an ISA like RV32I only sets constraints on your architecture, it doesn't give you any of it for free. So I think it's entirely valid to say that it's a custom architecture if they didn't use any pre-existing CPU design.
Basically, they had the API interface and implemented everything behind it. I think saying that "it's an RV32I core" vastly underrates the design work that goes into actually implementing an RV32I core from scratch.
Making a particularly good core is hard. Making a core to the minimum risc-v spec is what you do in a single college course. It's what the ISA was designed for.
The *architecture* is RV32I_Zmmul which is unambiguously neither new nor custom.
What you describe (the specific implementation details of a core) is *microarchitecture*. In this case clearly a lot of work was done and it is cool, but the *architecture* is indeed RV32I and not custom
I was not undermining anything. I was helping others find the info I sought and took a while to find. This is why i left my comment. Everyone has their own interests. As an example, my thoughts were "whoa... a new architecture... did they write a new compiler or rewrite doom in assembly?" and for that "it is rv32i" would have been a quick answer.
It's common to call the instruction set just "architecture", or ISA (instruction set architecture) to be more precise. The implementation is commonly called "microarchitecture".
RV32I doesn't define any architecture, it's just an ISA i.e. a software contract that happens to be implementable in hardware. The CPU could run on outer space goop and still be RV32I.
I think this largely is about brand protection. They worry that discounting the clothes means they will just cannibalize sales of that brand's full-price clothes.
reply