That is a good point.
On the flip side, they’re not largely selling something that has any physical finiteness to it anymore, and the sales volumes have increased drastically, resulting in significantly higher profits despite a smaller inflation adjusted unit cost.

The cost of a good decreasing as an industry matures feels right. Jello cost 23¢ a box in 1940. Adjusted for inflation it should cost $5.17 a box now, but it’s only $1.59.
When there’s 2 games to buy, they can be justifiably more expensive than when there’s a massive surplus.
The games are different, but it’s not like consumers can’t find a different one they’ll also enjoy if the first one they look at is too expensive.

Inflation has made $60 less valuable, but they’re not selling to the same market that they were 30 years ago either.
It’s hard to use inflation to justify raising prices or adding exploitative features when you’re already seeing higher inflation adjusted profits due to a larger more accessible market, lower risk due to reduced publishing overhead, and more options for consumers, which would be expected to bring prices down.

It’s particularly annoying because those are all AI. AI is the blanket term for the entire category of systems that are man made and exhibit some aspect of intelligence.

So the marketing term isn’t wrong, but referring to everything by it’s most general category is error prone and makes people who know or work with the differences particularly frustrated.
It’s easier to say “I made a little AI that learned how I like my tea”, but then people think of something that writes full sentences and tells me to put dogs in my tea. “I made a little machine learning based optimization engine that learned how I like my tea” conveys it much less well.

Yes and no. There’s some dated topical humor, and some of the seasons are not as good.
Overall a pretty good show though.

While that’s definitely a factor in global food trends, I don’t see that impacting the US price of food as drastically as companies thinking they can get away with raising prices.

My reasoning is the web of tarrifs and subsidies that the US uses to stabilize domestic markets, prop up farmers, and generally ensure the US is the key grain player. Shortly after the war started the US and Canada also saw a better than average harvest of the grains that Ukraine typically exports.

https://fred.stlouisfed.org/series/WPU02120301 https://fred.stlouisfed.org/series/PCU3112113112111 https://fred.stlouisfed.org/series/CPIUFDSL

The domestic prices paid for wheat and flour both started to fall shortly after the Ukraine invasion, while food prices maintained a rocketing trajectory without much if any changes, with only a slight decrease in the rate of increase about a year after.

While protectionist US food policies are chock full of horrible problems, in this case they should have insulated people from radical changes in the availability and price of wheat.
That consumer prices have risen despite falling costs paid to producers is a big indicator that the cost increases are due to something else in the US.

None of this applies to countries that are dependent on grain imports who have to rely on the global markets instead of adjusting export profitability to stabilize things.

In the sense that they have a manager? Sure. In the sense that there’s one individual dictating the design of the software? I’ve never even been on a team with that dynamic, to say nothing of the entire codebase.

Modern software teams tend to eschew design by decree.

What’s the dynamic that you’re thinking is typically what teams use?

I’m not sure I’d construe a manual you can find, or a variety of guides, as a negative. :) most days my usage of git consists of “pull, commit, push, merge” in different orders. You might be overestimating how much effort goes in to managing the tool.

Most of my professional experience has been working on projects that consist of multiple teams of between 4-6 developers, and between 5 and 40 teams. I’m not entirely sure what you mean about git not mirroring the development patterns of most “real life” projects.
“Real” projects are frequently developed by groups of people working on the same goal adjacent to other groups working on related but distinct goals.

We very clearly work in different professional environments. :)

In no particular order: Administrating a git server is similarly trivial. A repository is a folder (easy to backup, easy to repair, easy to host), and setting up a new server usually a matter of ssh key management. Don’t even need to install sqlite or anything beyond the git package. Or, because the tool has wide support, you can install a wide selection of tools that manage it for you, or use a free hosting service, or a paid one.

I’m startled that you would say you can’t think of anyone who would care. My entire professional experience has been developer stories about bad jobs often include details about using old or esoteric VCS systems, usually met with “ew” or “wtf” comments. Sets the flavor of the story.
Personally, in a business environment, I would take using anything except git for the org as a red flag. It’s a sign that someone in leadership at the company values doing things unrelated to the core mission “their way” above doing it the easy or “paved path” way.

The standard tool is indeed not constant. Before git existed, using CVS would have been the better choice, as well as for years afterwards until it had clearly been usurped. Most projects aren’t Linux when it made the switch to git.

You joke that no one really “knows” git, but… This is literally the first time I’ve ever seen a fossil command. I just searched for “fossil manual” and I get analog watches. It’s not even available in any of my systems package managers.
Developer familiarity is a big advantage that I think you’re downplaying in comparison to “there are metadata files in .git”, which I don’t know has ever been relevant to me in any significant way.
(Also, I thought the different systems all work basically the same? 😛)

I’d handily agree people should be using the best tool for the job. Familiarity and ease of use are significant factors in what makes a tool better.
Ability to integrate with other tools is also a major factor. Setting up continuous integration or code review tools with git is trivial with any number of different systems.

What are any of the tools you’re using doing better than git? The biggest selling point you’ve shared for fossil is that it’s functionally similar to git, and that it has better merging. I can’t find anything related to merge conflicts outside of years old forum posts, and barely anything relating to merges at all, so I’m not entirely certain what makes it “better”.

If it’s biggest advantage is that it’s similar enough to git that you can pick it up fast, why wouldn’t I just use git?

Like I said, there are always factors.

For a company starting from scratch though, the usage base factor becomes vastly more significant.
Using a tool that radically limits your integration capabilities is a poor choice, to say nothing of most likely needing to onboard every new employee to an entirely new VCS.

I don’t know that I’ve encountered anyone using svn that wasn’t interested in moving in recent memory, so “developer experience” would be a reason to move.

Of course it’s not the only factor, but all things being equal, the most prevalent tool should be preferred.

Why?

How does fossil or svn protect you from a remote server going down making it’s contents unavailable?

Are those advantages worth others not knowing how, or caring to bother, to access or contribute to your software?

What are you gaining by eschewing what is effectively the standard tool?

File1, file2, file_3.new, etc would be bizarrely stupid. A home rolled solution involving rsync, tar, gzip, crons or inotify would also be bizarrely stupid.

https://en.wikipedia.org/wiki/List_of_version-control_software anything on that list that’s marked anything other than “active” as a more serious answer. So like DCVS, visual source safe, or bitkeeper. Anything that’s not getting bug fixes or maintenance.

Anything that doesn’t have significant enough usage to give confidence that bugs or glitches are being caught by common usage would be risky, since you don’t want to be the person to find that edge case.

There’s things other than git that aren’t wrong, but I see little compelling reason not to use the most ubiquitous tool.

There’s a difference between “can’t code” and “can’t work”.

A lot of people use git for version control: super good idea, basically anything else is at best unorthodox, at worst bizarrely stupid.
A lot of people also use github for repository hosting, continuous integration, code review, deployment, packaging, etc, etc. this is more of an opinion thing than a standard practice thing, and there are plenty of other ways to get the same tools, either all in one package or from a variety of different ones, self hosted, in the cloud, or some hybrid in between.

If GitHub goes down, you can make code changes and everything to your hearts content. But you might not be able to run your full integration testing pipeline on it, get a code review, or package your software.

If your local build process pulls packages from GitHub or refreshes a remote repository automatically, it can also powerfully mess that up, but that’s nothing to do with git. You can use “ctrl-c/v” backups and still have a build process that tips over when GitHub goes down.

Most of them are mediocre. Most burger places were mediocre, and then the American gastropub trend saw burgers being made nice as opposed to diner food or bar food. They could also charge more money because they were making nicer food.

Eventually a bunch of the mediocre places shifted to try to also be nice, but mostly just increased prices, changed decor, and started using the word aioli more than mayo. Oh, and pretzel buns on burgers that got taller without being bigger and are cumbersome to eat.

In the plus side, if you like a Swiss burger with a garlic aioli, a burger with a fried egg on it, or a burger with 2 pieces of bacon, a spicy BBQ sauce, and fried onion strings and you’re in the mood for some fries with bits of peel on them and a garlic Parmesan butter, then you know exactly what they’re going to put in from of you and exactly what it’ll taste like.

Mediocre. Not bad, but definitely not the best you’ve ever had.

And also based on chrome. That’s the thing that people seem to keep ignoring. Your browser options are Firefox or something based on chrome.