I hope this sets the trend for cars too.

I would happily buy a new car with a 2000s Japanese engine and no tech.

Embrace, extend, extinguish.

The first two have been done.

I give it five years before the GH CLI is the only way to interact with GitHub repos.

Then the third will also be done, and the cycle is complete.

None of these happened. none of them even appear to have happened, and none of them appear to have even been planned. It's all a hallucination by people that talk like this. It's all imaginary. Show me any evidence of anything like this. ANY AT ALL. Not a hunch, not something that could be interpreted that way, show me the very clear and repeatable steps that Microsoft used in the 90s to EEE something in anything they're doing today.

They're too busy copiloting everything and arguing with each other to do this. Show me Microsoft Git with extra features over the open source version. Show me Microsoft Linux with extra features over the open source version. Show me Microsoft ANYTHING with extra features over the open source version they copied, and show me the doors slowly closing behind me. You can't. Because it isn't happening.

git repos can't be locked up in the way you're describing. github is a wrapper around git. it would take an enormous amount of work for microsoft to change this fundamental decision in the design of github. GitHub is a git server, over both HTTP and SSH. These are core decisions of the software that everything else sits on top of. If pulling git repos over HTTP or SSH ever stops being supported, so many things are going to stop being supported, that it just won't be useful at all after that point.

the gh cli makes api calls, that's all. it just makes api calls easier. it exposes a lot of api calls as friendly commands. it's not something that most of github users are even aware of, much less use. gh is not going to lock someone into a github "ecosystem" A) because such a thing doesn't exist and B) again, most people don't use it.

Microsoft is far more likely to kill GitHub because of people with MBAs (aka "morons") who somehow call the shots in business these days. They are not going to pilot into the ground by EEE. They are going to pilot it into the ground because they don't know what they're doing, and they don't know what users want or what they like. That will be the fate of GitHub; incompetence will kill it, not cold, calculating, nefarious competence.

The comment’s size is apparent before reading a single word, so you can avoid it if it is too large. “EEE” comments are short and exhausting and there is no warning visible.

I'll take that bet. How much are you willing to put on it?

I do not doubt this, already it seems to be a pain to deal with some repos on github without using gh. I do not know what gh buys you but I have never used it so I do not know if it is "better". To me the standard git commands are fine. But yes, I think the trend to forcing gh upon us is already being done.

Store the file on the filesystem with a unique name. Store the original name, the unique name, the owner, tags, a description, locking, auth, enforce uniqueness, and track access with the database.

Then try and keep things performant and handle concurrency!

Try doing all of the above just using a filesystem and you'll either:

1. Waste years making a rubbish database. 2. Do a bad job trying to do everything with flat files.

PostgreSQL/MySQL or SQLite are easy wins.

Leave Git alone.

Not everyone is making serverless JS web applications!

Most of the time, people need a Linux server they can SSH into.

Cloudflare don't offer this, so I continue to use AWS.

5. Implement infrastructure monitoring.

Assuming you're on something like Ubuntu, the monit program is brilliant.

It's open source and self hosted, configured using plain text files, and can run scripts when thresholds are met.

I personally have it configured to hit a Slack webhook for a monitoring channel. Instant notifications for free!

You'll need to edit files sometimes, and Vim (or Vi) is usually present. I don't think I've seen an install without it.

The basics (opening files, writing, and closing) can be learnt in an hour. It's enough to make simple changes to .conf files.

I’ve often in my career witnessed engineers who’ve cargo culted the need for vim, but they only know how to hit ESC !wq or whatever, and one errant keystroke puts them in modal hell of some sort that, often requiring they just close the terminal and try again.

I don’t begrudge those who want to become power-VIM-users, though it seems wildly awkward to me, to each their own. But if you just want to use it to do the “basics” on ssh sessions, using nano makes more sense. PGUP and PGDN and Home and End and arrows work just fine to navigate, and the bindings for most things are printed right on the screen (except Ctrl-S to save… for some reason, but it works).

Old petrol Toyotas and Hondas met your criteria.

And the back catalogue of parts is huge and supported for a long time.

Modern cars aren't built as well.

Maybe the modern non-turbo petrol Mazdas are the best fallback.

Can you cite a source for this? There's no question that they're vastly more complex, but I would think that modern car manufacturing is far more exacting (and efficient) than in the past.

If you're saying that older cars are more repairable, I'm happy to agree with you, even without a source to back up that claim.

Interior wise, you can look at things like fabric durability-- lower deniers can be cheaper, but will wear sooner. Springs/foam in seats are another example, but this will vary across manufacturers, models and trims.

This isn't exclusive to financial engineering manufacturers like Stellantis or Nissan, either. Toyota has had issues with simple things like rust proofing (whether intentional or not) on 1st generation Tacomas leading to massive recalls and things like plastic timing guides prone to wearing out. Ford with the wet clutches having belts submersed in oil. German cars needing body off access for rear timing chain maintenance at 80k miles. Water cooled alternators (really, VW?). All types of "why?" if you follow cars once they are 3+ years old.

It seems like there are a lot of regressions that probably result from cost cutting, while others may exist to simply drive service revenue.

In the United States, the Environmental Protection Agency assumes the typical car is driven 15,000 miles (24,000 km) per year. According to the New York Times, in the 1960s and 1970s, the typical car reached its end of life around 100,000 miles (160,000 km). Due in part to manufacturing improvements, such as tighter tolerances and better anti-corrosion coatings, in 2012 the typical car was estimated to last for 200,000 miles (320,000 km) with the average car in 2024 lasting 160,545 miles according to the website Junk Car Reaper.

[1] https://en.wikipedia.org/wiki/Car_longevity#Statistics

That'll influence the average reliability minimally, unless you were unlucky enough to buy one of those models.

Personally, why I'd rather get something at 120k mileage w/ 250k+ max examples on the road by that calendar date. You'll know whether they designed a lemon.

Add: undersized Tacoma rear leaf springs, multiple manufacturers' head gaskets, a few early aluminum engines (? from memory)

Leaning on those prior mentioned product mixes, keep in mind that Japanese manufacturers weren't in the American market 60 years ago, so market mix would be wildly different. (Multiple 400k+ mi Toyotas in my family, along with 60 year old GMs, but with aftermarket or rebuilt engines.) The cost of vehicles (and repairs) relative to prevailing wages will impact the repair vs replace balance. Trade publications like Cox/NADA/Adesa/etc. are always cited by financial blogs when mentioning consumer spending/state of economy by average age of cars on the road. Why cars get junked or totaled has shifted drastically, too. Steel bumpers were easy to replace, modern bumper covers with styrofoam backing and aluminum crumple zones, not so much. Tolerances is a vague term in that veiled PR piece on that wiki article. Machining has improved. Tech like direct injection and improved lubrication (synthetics) have done much more in terms of efficiency and longevity. In a lot of cases, manufacturers try to get more and more horsepower from the same displacement by pushing tighter engine tolerances (crank/main bearings, pistons/rings, valvetrain) and things like higher compression ratios and revs, leading to more heat and earlier failure. So while you have better initial engineering, you are closer to the point of failure. For another example, interference engines will grenade themselves if you ignore timing belt maintenance, but in the meantime, you get more horsepower by getting more air into the cylinders.

A v6 Camry or Accord is going to be have more hp, be faster,more reliable at same age, be quieter and get 3x the mpg than nearly any muscle car of the past. Unfortunately it seems that many Americans prefer giant vehicles that place more emphasis on their size (and status) than materially important factors like reliability engineering or fuel economy.

Obviously these are ancedotal examples, they can be confirmed by wasting hours reading about cars and watching mechanic review videos from people who work on them daily (I am partial to the CarCareNut on YT).

There's a reason why roman architecture is still standing: it is massively overbuilt, the very opposite of efficient (they also used to make the architect stand under his own arches as they removed the temporary support, that could have contributed to the overbuilding).

Is it? Every city in Roman empire had temples and forum. Where are they still standing? Maybe half a dozen survived, like pantheon in Rome or temple in Nimes, but it's extremely rare. Maybe they weren't overbuilt at all?

https://web.archive.org/web/20150122235642/http://www.busine...

But an AI assistant can do so much more damage in a short space of time.

It probably won't go wrong, but when it does go wrong you will feel immense pain.

I will keep low productivity in exchange for never having to deal with the fallout.

  git commit 
  aws ec2 create-snapshot --volume-id ...
  git reset --hard
  git clean -fdx
  aws ec2 create-volume --snapshot-id ...
  robocopy "C:\backup" "D:\project" /MIR 
  ...