people that say things like this are exhausting. exhausting. You make it so very easy to classify you straight into the "looney" bin. People said that WSL was EEE for Linux. when that didn't happen, people said that WSL gaining GPU support was EEE. When that didn't happen, people said that WSLg was EEE for Linux. People said that Powershell was EEE for Windows.
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.
I think the down-votes on this comment are too bad. It's legitimately funny to write a muli-paragraph rant in high dudgeon calling other people "exhausting".
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 give it five years before the GH CLI is the only way to interact with GitHub repos.
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.
I do use a command-line program as the only way to interact with GitHub (using the GitHub API), but I do not use GH CLI; I have my own implementation (which is much smaller than theirs). (They can see that I use my own, because of the User-Agent header, and they can also see what APIs are accessed.) (Git can also be used, but only for the functions of Git rather than the functions of GitHub.)
They're not exclusive. Quite often developers use a filesystem with a database.
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.
It's definitely not just for JS web apps anymore—you can run Rust, Python, and even standard Docker containers now. Plus, things like D1(SQL) and R2(Storage) give you the entire backend stack ready-made.
But you're completely right that it doesn't replace a raw VM. Cloudflare's goal is to abstract away the infrastructure so you don't have to manage a Linux server just to host an API or SaaS. But if you actually need OS-level access, background daemons, or to run legacy code, you absolutely still need EC2 or a traditional VPS.
Using vim to do this seems silly. Nano is also nearly always present, and doing those “basic” things is 10x more straightforward in an editor that isn’t modal and just gets out of your way.
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).
reply