That still so much assumes a "waterfall" ideal world where specs can be captured up front perfectly and coding is just an inevitable artifact of that with no creative input/feedback into the spec.
At least in my experience, that ideal has never existed. "Engineering" (and "re-engineering" and "re-re-engineering" in the agile worlds) was always what I was spending the majority of my time on. Coding was a medium for the engineering. By the time I finished the engineering the code was either already finished, being discovered in the written code and then documented, or the code was "the fun part" reward for all the hard engineering work that lead to it (and all the ugly specs documents it took to get there).
It would be a potentially breaking change so out of an abundance of caution likely would require (or need to wait for) a new version of HTTP like HTTP/4.0. On the other hand, adding an entirely new Method potentially can be applied across HTTP versions. It's possible for an HTTP/1.1 server to accept QUERY today under this RFC, it doesn't need to wait for and upgrade to HTTP/4.0 service, whatever that would entail. (Especially in the Postel's Law world where HTTP/1.1, HTTP/2.0, and HTTP/3.0 are all living side-by-side and are very different protocols under the hood.)
Actually this is a use-case supported by this RFC [1]. You accept an arbitrary QUERY /search/ and you cache it on your side (or in a middle box somewhere such as a CDN edge) you can return in your response:
Location: /search/?queryHash=SOMECDNHASH
The browser can then cache that Location and the next time convert that same QUERY /search/ into GET /search/?queryHash=SOMECDNHASH.
Sure, it is more work for your webserver to compute that and potentially the browser to cache it's knowledge of that QUERY, but it potentially gives you an advantage in keeping things like CDN edge caches generally aware of client/browser caches in a way that can be performance optimized.
Feeling rather flippant, but what's the difference in practice? Can you point to an AOSP "brand" phone on a store shelf that is "de-Googled" out of the box?
What is AOSP really for other than "open source washing" Google's ecosystem? Is it ever making standards that Google has to follow/comply with or is it always just the tail being wagged by the dog to make it look like the dog is happy about open source (but still isn't majority open source)?
Again, let me know when you see a LineageOS or GrapheneOS phone for sale on a store shelf.
I am certainly familiar with these things. I just don't see them having a practical effect on the average consumer, just fellow HN commenting nerds. I think I have one friend in real life with GrapheneOS at the moment, and it is not an experience they would recommend to any other friend of mine.
I support such things in theory, sure, but in practice, especially in HN comments there seems to be a lot of forgiveness to the very locked in by Google Android ecosystem purely because these alternatives exist, ignoring the practical realities such as marketshare/mindshare/ease of use/ease of access.
I don't have any easy answers on how to fix AOSP because it seems to be a sociopolitical problem, not a technical one, and I am mostly just complaining without skin in that particular game because I can't find myself caring about Android politics, but when my less technical friends and family that prefer Android are upset at something Google does I don't have good answers because "do months of research into LineageOS or GrapheneOS, deal with most of your apps not working most of the time, and it getting harder to buy phones because you have to make sure that they are rootable" isn't a good answer. "Why don't you just switch to an Apple device?" is at least an easier answer.
Goodhart's Law will always be a factor, and "the bottom line" is largely the ultimate perverse metric for Goodhart's Law. If doing something everyone hates still has a chance to increase revenue, it's still "winning" to management.
Low quality "spam" tactics still reel in enough fish to be monetarily worth the "backlash" from customers that find it distasteful and or start to lose trust in the company. The "We promise we don't spam people" metrics and "Consumer distrust" metrics don't talk enough to the "revenue" metrics, but especially have very different cycles: big customer satisfaction metrics like J. D. Power are big annual things, not quarterly reports like earnings. In my experience things like "how often are we calling the same disinterested people to the point where it starts to feel like very personal spam" metrics don't ever really get prioritized in internal reports unless there's enforcement from Legal departments, and even then Legal departments can't "upset the bottom line" and only care about such compliance when it becomes News and/or Lawsuits, both of which don't even merit even an annual review cycle. (In fact, the modern class action lawsuit pretty effectively prevents that feedback mechanism from cycling, because generally the terms of agreement in a settled class action lawsuit is that the class is no longer allowed to sue again for the same problem, even if the same problem keeps happening and is never actually fixed.)
Unless quarterly earnings reports need to include things like client satisfaction and spam tracking, the only metric management will continue to care about, because it also is the only metric shareholders claim to ever care about, is the "bottom line", no matter how ugly the sausage is made to bump it from quarter to quarter.
Fundamentally, you can convert reputation into current earnings. The former is hard to measure, the latter is much easier to measure. Thus there is a huge incentive for managers to do such. Better run companies tend to understand this problem and are reasonably careful about avoiding it--but when something comes along and upsets the apple cart like AI does they fail to recognize what they are doing.
Also, for a lot of SVN history running it required such a specific Apache webserver setup that it was at times complex to configure correctly and made it comparatively expensive to find SVN repository hosts. SVN seemed cheap mostly only if you had cheap labor for infrastructure. Very few hosts got to "forge scale" like SourceForge did with CVS or GitHub would eventually/"quickly" do with git.
It feels like a Pareto Principle problem. 80% of source control is text files that can be three-way merged as text files, but a lot of hard problems are in that 20% that isn't.
Git does very well at the 80% and with tools like custom merge tools and git lfs/annex and git sparse "cone" checkouts can get pretty close to hitting the 90 or 95% case.
But yeah, so many of those extra tools in that 80 to 90% area are awful to work with because they aren't the default, aren't out the box, are hard to configure and get right. Partly because it always seems like there will be a gap in that 95%-100% window and partly because the use cases that need that 80% to 90% often are only "just 10% of use cases".
(Which is also to say that to survive Jujitsu and Pijul and others seem to have to work to make sure they handle the 80% base case extremely well just to compete with git, they haven't necessarily time to think about the 90% or 100% problem.)
(ETA: And also relates to why game development seems to feel the 20% cases more, because by volume of data game development is certainly closer to a flip of the 80/20 sides with 80% or more large binaries by volume.)
That it is difficult to merge e.g. media files has nothing to do with Git. It's just that it is one of the core assumptions in Git, that it is fine to diverge locally and cheaply, because you can just merge. I think this can't really be solved without a centralized server and that is just something, that Git doesn't want to be.
Yeah, decentralization is an important principle to git and tools to manage concurrency such as "file locking" become a lot harder to do in an a decentralized way than a centralized one. (Pijul has the same problems because decentralization is also an important principle to it.) It is something of a problem space that transcends beyond git. But I also think this is how we've arrived to this moment where the best source control tools have decentralization as an important principle. That 80% case with easy mergeable text files is a lot nicer to work with in a decentralized world because it is "offline-first" and quite capable. It often seems, across a lot of different styles of software development, worth the trade-offs that things like media files are harder to work with. (Again, realizing the obvious problems with game development where that often flips and the majority of work is often in the media file assets as much or more than the text files.)
I would say that at least the submodule problem is more like the last 45%. Every single company I've worked in has ended up using submodules and it always ends up causing huge amounts of pain because they suck.
The only alternative Git offers, which is slightly better IMO, is monorepos. But they're only slightly better - they also have really significant downsides.
I'm 100% sure there's a much nicer solution to the kinds of problems people use submodules for that isn't submodules, but as far as I can tell zero people are trying to find it, despite it being such a universal problem.
From my viewpoint, a lot of the submodule problems are effectively same as the monorepo problems, including how you end up with both problems. There certainly are factorings of projects into "microservices" and moving the dependency management problems out of source control to package managers of different types. Microservices and package management sure do have their own problems and trade-offs and there isn't a "universal solution", just what side of the trade-offs you prefer to be on.
Perforce is more the IBM of VCS. Older than it has any right to be. Has quiet "dark matter" support contracts with a lot of companies you wouldn't think need Perforce, but they've been using it for long enough they aren't going to change. Some of those support contracts included complicated forks and homegrown solutions that are so sunk cost as to be nearly black holes (and sometimes so different from baseline Perforce as to be evolutionarily different species).
The consoles at the time had dedicated sprite video RAM and hardware and dedicated hardware instructions for background scrolling. The NES for instance had up to 64 sprites (independently moving 16x16 or 32x32 pixel images) supporting up to 8 of those sprites per scanline. The NES background layer was a relatively simple tile map that supported smooth scrolling. All of which was managed by a dedicated hardware Picture Processing Unit [1].
PCs were designed to be general hardware and it didn't seem to make sense to create a generic "PPU" for the PC, so instead game engines at the time (and many game engines to this day) had to emulate one entirely in software. The video RAM of EGA and VGA is just one big blob of pixels, or perhaps two if your system supported double-buffering. At the hardware level it doesn't have concepts like sprites or scrolling backgrounds.
Carmack was one of the first (if not the first; Commander Keen was also among the first commercially successful attempts) to get a software "PPU" renderer on the PC working reliably in real time. Another notable achievement for side scrollers on the PC in that era was Cliff Bleszinski managing to software render the parallax effects similar to Sega's "Blast processor" PPU (notable for "gotta go fast" Sonic games) for Jazz Jackrabbit (in 1994).
It has sort of long been the arc of PC development of eventually doing entirely in software what consoles and arcades were doing with dedicated and/or one-off hardware. (Right up until about the invention of the modern GPU when suddenly the PC was leading graphics hardware in a different way.)
The big win seems to be "GitOps". There are other tools for "GitOps" than Kubernetes, Kubernetes is just the elephant in the room in terms of size/scale/current adoption patterns. (Certainly not "ease of use", though.) I think one of the themes in comments here is how much people want more "middle ground" "GitOps" tools somewhere between "Serverless" (especially given vendor lock in in that space) and Kubernetes.
At least in my experience, that ideal has never existed. "Engineering" (and "re-engineering" and "re-re-engineering" in the agile worlds) was always what I was spending the majority of my time on. Coding was a medium for the engineering. By the time I finished the engineering the code was either already finished, being discovered in the written code and then documented, or the code was "the fun part" reward for all the hard engineering work that lead to it (and all the ugly specs documents it took to get there).
reply