Everyone starts off without references, and there’s already less of a pipeline from user to helpful contributor to fellow maintainer than most projects want without having to add more chokepoints. There isn’t a solution without downsides while there are people using LLMs.
TOML’s design is based on the idea that INI was a good format. This was always going to cause problems, as INI was never good, and never a format. In reality, it was hundreds of different formats people decided to use the same file extension for, all with their own incompatible quirks and rarely any ability to identify which variant you were using and therefore which quirks would need to be worked around.
The changes in the third panel were inevitable, as people have data with nested structure that they’re going to want to represent, and without significant whitespace, TOML was always going to need some kind of character to delimit nesting.
There’s a pretty good reason to think it’s not going to improve much. The size of models and amount of compute and training data required to create them is increasing much faster than their performance is increasing, and they’re already putting serious strain on the world’s ability to build and power computers, and the world’s ability to get human-written text into training sets (hence why so many sites are having to deploy things like Anubis to keep themselves functioning). The levers AI companies have access to are already pulled as far as they can go, and so the slowing of improvement can only increase, and the returns can only diminish faster.
If LLMs aren’t going to reach a point where they outperform a junior developer who needs too much micromanaging to be a net gain to productivity, then AI’s not going to be a net gain to productivity, and the only productive way to use it is to fight its adoption, much like the only way to productively use keyboards that had a bunch of the letters missing would be to refuse to use them. It’s not worth worrying about obsolescence until such a time as there’s some evidence that they’re likely to be better, just like how it wasn’t worth worrying about obsolescence yet when neural nets were being worked on in the 80s.
Usually, having to wrangle a junior developer takes a senior more time than doing the junior’s job themselves. The problem grows the more juniors they’re responsible for, so having LLMs stimulate a fleet of junior developers will be a massive time sink and not faster than doing everything themselves. With real juniors, though, this can still be worthwhile, as eventually they’ll learn, and then require much less supervision and become a net positive. LLMs do not learn once they’re deployed, though, so the only way they get better is if a cleverer model is created that can stimulate a mid-level developer, and so far, the diminishing returns of progressively larger and larger models makes it seem pretty likely that something based on LLMs won’t be enough.
CUDA is an Nvidia technology and they’ve gone out of their way to make it difficult for a competitor to come up with a compatible implementation. With cross-vendor alternatives like OpenCL and compute shaders, they’ve not put resources into achieving performance parity, so if you write something in both CUDA and OpenCL, and run them both on an Nvidia card, the CUDA-based implementation will go way faster. Most projects prioritise the need to go fast above the need to work on hardware from more than one vendor. Fifteen years ago, an OpenCL-based compute application would run faster on an AMD card than a CUDA-based one would run on an Nvidia card, even if the Nvidia card was a chunk faster in gaming, so it’s not that CUDA’s inherently loads faster. That didn’t give AMD a huge advantage in market share as not very much was going on that cared significantly about GPU compute.
Also, Nvidia have put a lot of resources over the last fifteen years into adding CUDA support to other people’s projects, so when things did start springing up that needed GPU compute, a lot of them already worked on Nvidia cards.
Generally, you’ll get better results by spending half as much on GPUs twice as often. Games generally aren’t made expecting all their players to have a current-gen top-of-the-line card, so you don’t benefit much from having a top-of-the-line card at first, and then a couple of generations later, usually there’s a card that outperforms the previous top-of-the-line card that costs half as much as it did, so you end up with a better card in the long run.
When AMD’s biggest market was Litecoin (and derivatives like Dogecoin) mining and Nvidia’s hardware was pants at mining, they initially couldn’t increase production of the HD 7000 series quickly enough, so the initial glut of money went to scalpers. They responded by making huge volumes for the Rx 200 series, but shortly after it launched, Litecoin mining ASICs became available and GPU mining stopped being viable. That meant that:
This wasn’t the only time ATi/AMD took a calculated risk and it backfired horribly, so with their history of bad luck, chasing the AI bubble in any way that involves risk instead of just selling things for money might be a bad idea.
Instead of git history, you get a git fairy tale. Practically, the merge conflicts and their resolutions get spread across one or more commits on the branch that was rebased, and the history makes it look like all the work was done after the upstream commit(s) that there was a conflict with. This can be much tidier, but also loses the context of changes. E.g. you can no longer see that something is done differently to everywhere else that does the same thing not because it needs to do it differently, but because it copied and pasted something from ten lines above and the thing ten lines above received a bug fix on another branch which the feature branch was rebased onto. Based on my experience working on large projects that used both approaches, I’d rather scroll past extra commits and squiggly branch lines than try to reconstruct what someone was thinking when they made a mistake without access to the original commit they made the mistake in. If I had to allow history-rewriting operations in git, the one I’d pick would be rewriting the history of Earth so that when history rewriting operations were implemented in git, they defaulted to adding some metadata to the rewritten commits making the operations reversible so I could decide I wanted the real history back.
In this case, the product was free to OSS developers not because they were the product, but because they’re influencers likely to end up encouraging their users and/or employers to buy the paid version, so it was the marketing that those people could do that was the product.
This change with the data harvesting makes those developers the product, though.
Technically it’s even a ToS violation to install extensions from the VS Code marketplace (or whatever it’s called) if you’re using VS Codium. Many are also available somewhere else like the code forge where they’re developed and are under open source or free software licenses, but quite a few important ones are only available through the one distribution channel you’re not allowed to use, and contain proprietary components that can’t be forked to lift this restriction.
I know people who say exactly this kind of thing entirely seriously (potentially because they first saw it as an unlabelled joke that they took too seriously). Sometimes people are just incorrect pedants smugly picking fault with things that aren’t even wrong.
It depends on the sense of wet that you’re using. Most of the time, the relevant kind of wet is how much water something contains, and water achieves peak theoretical wetness by that definition. It’s only in specific circumstances that the surface is coated evenly by a wetting agent definition is relevant, like painting or firefighting.
There aren’t currently any RISC-V hardware implementations that support big endian (although I guess someone must have tried it on a simulator), so supporting it in the Linux kernel is about as useful as supporting any other hypothetical CPU that only exists on paper. The mainline kernel is meant for computers that exist in the real world, so supporting BE RISC-V should only happen after such CPUs have actually been made. As things stand, there’s nothing to suggest that anyone will bother making them, so the Linux maintainers shouldn’t bother supporting them.
Oops. I’d somehow missed that there was now a third kind of JPEG.
The compression technique it used was patented, and the licence fee was extortionate. By the time the patent expired, other, royalty-free, techniques were available that outperformed it.
Windows permissions are more flexible than basic Unix ones. A file doesn’t just have an owner and a group, it can have individual permissions for arbitrarily many entities, so taking ownership doesn’t remove any of the permissions from anything that already had access, it just adds more. The command shown here is closest in effect to deciding you’re always going to log in as root from now on, although Windows has a way to effectively do that without modifying the ACL of every file. Either way, it’s silly, and usually people who suggest it are under the impression that XP did permissions right by not meaningfully enforcing them and not having an equivalent of a root account you can temporarily switch to, and Vista only changed things specifically to annoy people, and not to be more like Unix.
Soldiers are supposed to question potentially-illegal orders and refuse to execute them if their commanding officer can’t give a good reason why they’re justified. Being in charge doesn’t mean you’re infallible, and there are plenty of mistakes programmers make that the compiler can detect.
That’s not what Rust’s documentation says. It does a compile-time bounds check if it can prove what the index might be during compilation, and a runtime bounds check if it can’t. In release mode, it tries harder to prove the maximum index is below the minimum length, but it still falls back to a runtime bounds check if it can’t unless you use get_unchecked, which is unsafe.
Premature optimisation often makes things slower rather than faster. E.g. if something’s written to have the theoretical optimal Big O complexity class, that might only break even around a million elements, and be significantly slower for a hundred elements where everything fits in L1 and the simplest implemention possible is fine. If you don’t know the kind of situations the implementation will be used in yet, you can’t know whether the optimisation is really an optimisation. If it’s only used a few times on a few elements, then it doesn’t matter either way, but if it’s used loads but only ever on a small dataset, it can make things much worse.
Also, it’s common that the things that end up being slow in software are things the developer didn’t expect to be slow (otherwise they’d have been careful to avoid them). Premature optimisation will only ever affect the things a developer expects to be slow.