It reminds me of 2008/2009, but weirder. I remember in that time a lot of companies going through the motions as if everything was alright and they were still hiring just fine, but then not actually hiring in the way they were acting.
It seems weirder now partly because it isn't a clear across the board recession, though part of me keeps looking at quarterly earnings reports and the DOW and keeps wondering if we're still "early 2008" on that rather than "late 2009" and that it will get worse before it gets better.
Marked decks are an ancient tradition for both cheaters and magicians. There are also ways to mark a deck that aren't obvious to most people with a casual inspection and that don't need an app to read from the edge.
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).
It seems weirder now partly because it isn't a clear across the board recession, though part of me keeps looking at quarterly earnings reports and the DOW and keeps wondering if we're still "early 2008" on that rather than "late 2009" and that it will get worse before it gets better.
reply