No, we have convenient online services in spite of the endless security theater that permeates consumer tech. All it's done is gradually increase maintenance burden and technical complexity until useful features are slowly stripped out to create a more "streamlined" experience. The mobile app for my credit union has become so shitty that I'm not even sure if losing access to it is a deal-breaker for rooting my phone - I already prefer to do my online banking and shopping on my laptop.
There is no "just works" technical solution for a problem caused mainly by naivete and gullibility. Governments and the private sector know this, of course; as others have said, the real purpose is to control users, not to protect them.
Why is the banking server trusting the client? Thats criminally incompetent security. If your website gets hacked because a client had "root" whose fault is it?
I see the cause of confusion. I was assuming and talking about the case of the legitimate user have a root/non locked down device as being imputed as the "attacker". I don't think he was talking about other people stealing or having acces to your device. And in any case, all bets are off then if you meant that scenario. At least with a browser user can choose not to save passwords and the attacker won't get bank creds, so even in that case a web app would be better.
Very nice site, but it seems to expect you to be following along with some other resource. The exercises each have links under the details tab, but the links are broken, and I cannot find the web pages they are supposed to be linking to.
The OP defeats his own argument. LSP was a collaborative effort that benefited from a degree of coordination that only hierarchical organizations can provide, yet it still sucks ass.
OP blames FOSS for not providing an IDE protocol a decade earlier, but doesn't ask the rather obvious question of why language-specific tooling is not only still around, but as market-viable as ever. I'd argue it's because what LSP tries to do is just stupid to begin with, or at least exceptionally hard to get right. All of the best language tooling I've used is ad-hoc and tailored to the specific strengths of a single language. LSP makes the same mistake Microsoft made with UWP: trying to cram the same peg into every hole.
Meanwhile, Microsoft still develops their proprietary Intellisense stuff because it actually works. They competed with themselves and won.
(Minor edit: I forgot that MS alone didn't standardize LSP.)
> OP blames FOSS for not providing an IDE protocol a decade earlier
Everybody standardized on Eclipse plugins almost 2 decades earlier anyway. It got replaced because the standard sucked. The new one is better, but by how much is still a question.
Maybe I don't ask too much from LSP, but it has enabled autocomplete on arbitrary languages across two or three IDEs I have to use regularly, so it satisfied my goals in a way the previous solutions did not.
I elaborated a bit when I edited my post, but to be more specific, I think LSP is a protocol that fails at its stated goals. Every server is buggy as hell and has its own quirks and behaviors, so editors that implement LSP have to add workarounds for every server, which renders the point of LSP moot. It's the worst of both worlds: editors are still duplicating effort, but with fewer, if any of the benefits of tools tailor-made for a specific editor-language combination. And that's not even touching on the protocol's severe performance issues.
Unsurprisingly, the vast majority of servers work much better with VSCode than other editors. Whether this was a deliberate attempt by Microsoft to EEE their own product, or simply a convenient result of their own incompetence, is ambiguous.
LSP is underspecified for sure. I don't think this is a situation that is limited to LSP though. It happens when software interfaces are underspecified (or post-hoc specified) with a strong dependence on a reference implementation (VSCode in this case) and the absence of a canonical validation test suite.
Exactly the same thing happened with VST audio plugins. Initially Cubase was the reference host, later Ableton Live became the reference and it was impossible to convince plugin developers that they were out of spec because "it works in Ableton".
My impression, having programmed against both the LSP and VST specifications is that defining well-specified interfaces without holes in them is not a common skill. Or perhaps such a spec (maybe ISO C is an example) is too expensive to develop and maintain.
I'm pretty sure that a VM gets abstrations of the underlying hardware. And these abstractions are fully documented and as such the generic drivers bundled with any linux distro will work perfectly with it. Running on actual hardware requires hardware specific drivers. Generic drivers exist for many types of devices, but they might not be able to fully use the hardware (or at all), which can lead to some features/the os to not work out of the box on linux distros.
And I assume that he refers to that emacs is the default $EDITOR var on ubuntu? I don't know if that's true, but i think emacs is one of these editors which is seen as having very bad usability. I can't imagine that emacs is the default $EDITOR on a recent ubuntu version, but I agree with the sentiment that those kind of editors should never be the defualt.
I thought it was a rather clear and obvious analogy how opinionated nerds hinder mass adoption of good FOSS products because user experience is dogshit.
„Running Linux in VM“ as you have put it, is miles better because it works all the time with 0 friction, driver issues, random freezes, reboots, etc.
I understand the analogy, it's just ridiculous. You are conflating entirely unrelated things based on your personal feelings about them with no regard to historical or technical context.
Hardware support issues are certainly understandable, but blaming "opinionated nerds" for them is asinine. It cannot be understated how difficult it is to deal with certain OEMs.
Although I totally get where you're coming from, and certainly agree that user-experience could improve by not setting unintuitive defaults like emacs or vi or whatever. But 'opinionated nerds' is a strawman. FOSS and Linux ecosystem isn't a big mass of like-minded people all deciding that user-experience isn't worth spending time on.
Let's not forget that computer science and programming initially has been a field for and by expert and academics. A lot of tools are written by experts, people that were used to writing and reading long documents with instructions, are intimately familiar with their systems, and often write similar software themselves too. Nowadays that have changed of course, but the field still has a lot of these experts.
And experts in any field often forget how it feels to not be an expert, and as such assume a lot of things to be obvious and often forget to mention or explain crucial things. But you can't expect every expert in some field to also be an expert in educational psychology, that is a whole field in itself. And even then, you might not have the creativity or writing prowess to write clear and intuitive documentation and pick variable and function names.
On top of that people are free to do what they want. That they work on this stuff publicly and make it available in itself is something worth of praise. They don't suddenly have the responsibility to make stuff easy to use for people who aren't at the same level like that.
A distribution like Ubuntu is in part basically a specific collection of all these free tools and software and presets. And maybe there doesn't exist a super user-friendly alternative for every one, and there is basically no incentive for people to spend free time making these.
Even if Ubuntu specifically states to be user-friendly (i don't know if they do), there are numerous valid reasons might exist for that. It could be that the rather spend their time refining and improving a often used part of the system. Or that they see the terminal in itself as an expert tool, and they rather have non-experts use the configuration that's available through the UI.
Although it's beside the point I think it's also important to realize that it's basically inevitable that there's going to be at least some difference between the quality of software that's free and open source, versus a company that has the ability to spend, and stands to profit from it. In my opinion the free part means infinite value and trumps any gap in quality or functionality.
Still agree that nano or something similar should be the default and vi or emacs should be an option.
I noticed this the other day when I installed VSCodium on my new Windows box. I had a functional setup for one day, then the next day I couldn't install a language extension I direly needed.
It's left a very sour taste in my mouth. I've used Emacs for ages and despite being a much more niche editor, it's never been so hard-dependent on centralized repositories, and the centralized repositories it does have (ELPA/MELPA) are apparently a lot more reliable than OpenVSX. Installing Emacs packages manually from source is a breeze, doing so with VSC is masochistic.
VSC is not really "open source" in any meaningful sense. It is just plainly unusable if you don't do things the way Microsoft wants you to. I do respect the VSCodium devs for trying to make VSC more properly open, but it does feel like a futile effort.
I feel that you're conflating few concepts, hackability, "open source", single point of failure architectures.
Yes, VSC is less hackable than emacs, but I don't think it's necessarily the same thing. VSC (and others like it) are going for a more streamlined "App Store" experience, while emacs is going for a more DIY/hackable style editor.
You can always fetching the VSIX file and sideload it is if the "store" is down though.
Yes, VSC is less "open source" than emacs. if "open sourceness" is a score out of 10 or something. Pretty sure RMS would argue linux is less "open source" than emacs too.
Not sure why this is futile for the VSCodium devs. They are taking a dependency on a service for installing extensions. The solutions is more readonly mirrors for the official OpenVSX endpoint.
If your main archlinux mirror is down, you don't cry about the centralized state of our life. You use a different mirror. You throw in 5 or 10 in case one or two are down. I understand why a company like Microsoft might want a more centralized service to distribute the extensions. But for an open source clone? is Microsoft also expected to create the mirror clone?
My point about VSC is that brands itself as "open source" when Microsoft clearly intends for it to have a proprietary, tightly controlled ecosystem. It's not just RMS-unapproved, it's practically a lie. You can use it as a FOSS editor, but only if you are willing to accept a vastly subpar experience. Oh, and they've started cracking down on people using their proprietary VSC plugins in derived editors, too.
I expected it to be a little less convenient to leave Microsoft's beaten path. I did not expect it to be a massive waste of time. This is what I meant by futile. Not only is it apparently very brittle, it's missing large swaths of VSC's ecosystem. Hell, I don't even know if the extension I wanted is available on OpenVSX because it's still down!
If Microsoft hadn't openwashed their product, I wouldn't care nearly as much.
Besides, Emacs still provides a streamlined system for managing packages on top of being hackable. It even makes installing and upgrading packages straight from a Git repo easy. Sometimes you can have your cake and eat it too.
For me, the C/C++ language pack stopped working overnight with Cursor. This was clearly because of commercial concerns about derivative IDEs fairly and squarely gaining traction over the original product. But it broke my workflow a couple hours before a meeting.
I use neovim with LSPs and this is unimaginable in my world. I have started using IDEs only because the productivity gains from better LLM integration are undeniable. Sure I moved to clangd in Cursor and it was all fine, but the IDE actively pushes you to install Microsoft extensions, that can be yanked off whenever some Msft PM decides "oh we didn't actually want our competitors to be making money".
LLVM/GCC/Neovim/Apache projects are open-source. Anything that is "open-source until it is not" is not open source, and this perfectly describes VSCode today.
I saw someone mention Avante on here a few days ago, which looks like it tries to emulate the Cursor experience in Neovim. Might be worth a look: https://github.com/yetone/avante.nvim
When people started to toot the horn of VSCode, esp. younger, inexperienced people, I personally warned quite a few of them about Microsoft's practices and motivations. Of course, who listens to a graybeard who's talking about impending doom? All answered " Microsoft <3 Open Source, what are you talking about?"
The problem isn't the distribution system, it's the licenses on the flagship Microsoft extensions that provide C/C++, Python, Javascript/Typescript, etc. support. Those licenses are entirely Microsoft's fault.
My 2pence. C/C++ experience on VSCode is still subpar compared to other IDEs. Python is good, but very viable alternatives to VSCode exist. The biggest unique value proposition regarding languages is in TypeScript support. Support for many other languages still come from authorities from those languages who have no issue making them available on the open registry.
For me, the killer proprietary extension is their remote development extensions.
Language servers are open source. One can write your own extension like we do today for Vim and Emacs.
There is no reason we should expect Microsoft to invest tens of millions of dollars into a product development and give it free for competitors like Cursor. That's not just rational, even for companies that are not Microsoft.
100% this. It would be one thing if the only LSPs you could build came from Microsoft, but that’s just not true. It’s just that developing LSPs isn’t free.
Cursor, Windsurf, etc. are building multi-billion dollar businesses off the backs of the work that the VS Code team has done. And that’s totally fine! What’s not fine, is trying to have access to the whole ecosystem of first party extensions that aren’t MIT licensed.
I agree there should be more resilient extension repos, but this is one of the problems Eclipse Theia [0] has tried to take on, but most projects just fork the core VS Code experience and slot in OpenVSX rather than doing the hard, expensive work of building their own extension marketplaces or LSPs. And you know what, for a community or OSS fork, I think that’s fair. I think when you raise hundreds of millions in funding, you can build your own LSPs and start to maintain your own infra for extensions. And if you’ve got enough buy-in, you can probably convince developers to submit directly to your marketplace too.
And it isn’t even a rug pull, per se. The first changes to the license on some of the 1P VS Code extensions probably happened in late 2018 or early 2019, with remote share. The LSPs may have changed later. If anything, the Code team was probably too lax about letting the commercial forks use their resources wholesale against the license terms for as long as they did.
Disclaimer: I used to work at Microsoft and then at GitHub with things that touched VS Code. I now work at Google, who uses VS Code (well Monaco) inside some of our editors/products, but I don’t work on any of those.
> There is no reason we should expect Microsoft to invest tens of millions of dollars into a product development and give it free for competitors like Cursor. That's not just rational, even for companies that are not Microsoft.
It's an "open source" IDE. It costs nothing. All of the money they make from it is on top of the integrations like Azure Devops and Github that would make just as much money (if not even more thanks to vibe coding increasing accessibility) in Cursor, Windsurf, and VSCodium. Microsoft isn't a charity and they've been investing those tens of millions of dollars for a reason: to get a return. That's fine, that's what capitalism is (like it or not).
What's not fine is their schizophrenic approach to open source that looks very much like the classic Micro$oft embrace, extend, extinguish*. They're literally trying to extinguish competitors that are doing better than them by restricting the ecosystem after supposedly and ostensibly embracing open source. I lived through the IE6 era and this doesn't feel much different. Same player, slightly different game.
It's probably driven by some politically powerful PM or VP who perfectly resembles the Dilbert principle. Just like the degradation happening in the Windows OS front, it's just Conway's law happening all over again.
* Which if I may remind everyone, is a phrase straight out of the DOJ's discovery. Microsoft came up with the term.
I wonder if more differentiated branding would have helped. Chrome/Chromium is another example that came to mind: Like "Code - OSS" (the open-source base of VSCode), Chromium works just fine as a browser but with fewer Google-related features (syncing, DRM, etc). People seem to happily use Chromium despite the limitations (many actively seek them!), and I don't remember there being a controversy like this.
> Yes, VSC is less "open source" than emacs. if "open sourceness" is a score out of 10 or something.
VS Code is not Open Source, period. What exists in the “Visual Studio Code - Open Source” repo that is MIT licensed but cannot be used to build VS Code. Once-upon-a-time it was just branding, telemetry, and a license to use the Microsoft Extension Marketplace. Now, however, there are proprietary, closed-source extensions and additions that are only available in the proprietary-licensed VS Code.
> You can always fetching the VSIX file and sideload it is if the "store" is down though.
No, you cannot do so legally (in the context of using Vscodium or similar), as it is a violation of [the VS Code Marketplace ToS][1]: “You may not import, install, or use Offerings published by Microsoft or GitHub, or Microsoft affiliates in any products or services except for the In-Scope Products and Services.”
Caveat: this is not universal and depends on the juridiction.
For example in France a software/service editor can only really attack a user if he is infringing on copyrighted stuff. Outside of that the EULAs only allow it to ban/remove access to its services without risk of legal retaliation. And by infringing copyright I mean redistribution of copyrighted material, not downloading and using it. I am sure this is the case in many other countries.
This is again, wrong. EULA is just another word for "contract", and I'm not aware of any countries that have banned contracts.
Of course, specific EULAs may not be enforceable in some countries because they contain terms prohibited by law. But the concept of EULAs - a contract where you agree to certain terms in exchange for license to use software is enforceable in basically all countries.
IANAL, but the "A" is "agreement," which is only true if entered into. If I put a sentence at the top of my website that says "by loading this page you are agreeing to my terms of $1,000,000 per byte downloaded, payable by bitcoin" you are for sure not under any obligation that I can imagine because you didn't agree to my ~~terms~~ demand
> is Microsoft also expected to create the mirror clone?
Allowing open source VS Code (ie. VS Code you compiled from Microsoft’s repo) to access extensions would be enough. Nobody is asking Microsoft for more than basic access. It’s does not even require a code changes, just a policy change.
Even Google allows Chrome forks to access the Chrome Store.
> Pretty sure RMS would argue linux is less "open source" than emacs too.
The word you're looking for is 'free'. Free as in freedom and free software. The open source philosophy focuses on the openness of the code base and the associated advantages. Free software philosophy highlights the freedom that the software gives its user on their devices. Opening the source code is just a means to that end for the free software philosophy. Most open source software are also free software. But a few software like VSC and Chrome manages to be open while holding back the freedom from its users. Stallman and others tried to highlight this difference, but were largely neglected. The large scale ignorance of this distinction is what led to spread of travesties like the Chrome browser.
I completely agree with GP on this matter. I use centralized repos for Emacs like ELPA and MELPA like a metadata source. The actual packages are downloaded directly from their git repos. All these happen transparently and failure is practically non-existent, even in the absence of mirrors. In contrast with such convenience, the only way to fully utilize VSC extensions market is to use MS's proprietary build of VSC. If you tried installing some essential extensions (like remote editing and editor sharing) on a fork or an open source build of VSC, it would 'conveniently' tell you that it doesn't work on an alternate build and instead give you the link to download the proprietary build. Some of these functionality don't even need an extension on Emacs (eg: tramp). What are the justifications for such restrictions? They alone know. But I'm sure that they aren't technical. You're probably too busy to worry about the politics behind it, whenever you find yourself in such a situation. It's quiet manipulative in my opinion. And all these were before MS started banning VSC forks from their marketplace.
It's even worse. VSCode used to be more open source originally, back when it was enthusiastically adopted. And then, gradually, official extensions started replacing parts with closed blobs with onerous licensing terms. C# and Python extensions have both suffered from this. Although the C++ one was never fully open, if I remember correctly.
Same for the c# one I think, the old language server was and is still open source but the .net core debugger has always been proprietary.
I imagine it is because it is derived from the Visual Studio debugger in some fashion. JetBrains ran into the same problem with Rider back in the .NET core days and had to write their own debugger.
There was never an issue with Omnisharp OSS-ness itself nor what replaced it. It was always about debugger and then "Dev Kit" extension which builds on top of the base one - "Dev Kit" is what isn't OSS and what requires an account.
I was gonna write this. Package management with distributed mirrors for both speed + redundancy are a solved problem in the Linux world. Ship trusted signing keys and even the shadiest mirror becomes verifiable.
For context, Open VSX is run by the Eclipse foundation, which also develops the Eclipse Theia editor, which is basically a clone of VS Code (not a fork, like VS Codium).
The Open VSX registry is open source (https://github.com/eclipse/openvsx) and self-hostable, although I have no experience with that. I assume it's possible to host your own instance with the extensions you want instead of relying on the free public instance.
Personally I'm more of a Sublime guy, but people looking for an open VSC alternative should consider Theia over VSC forks. It seems like the smarter long term investment if you want to get out from Microsoft's control.
Even though I've heard of Theia Editor before I don't think I've ever seriously looked at it until now. It honestly looks like a good alternative to vscode. (It basically looks like a straight up clone, which is good for me) I'll definitely give it a try.
I think if it was a distro like VSCodium, you could call it a fork. But Monaco is a small piece of VS Code. It's a text widget. A _nice_ text widget, but you can play with bare Monaco here:
You could shove this widget alone into electron and call the result a text editor, and I mean, Notepad was basically this for the windows text entry component for years, but it's a long way away from VS Code, or from Theia.
The model is called Open Core, so is well understood so I am not sure what is causing this confusion. The editor is open source as evident from a dozen forks. The complete experience which includes extensions has closed source pieces which the forks won't access to. But OSS community can build replacement or other companies can provide alternatives.
Just because pylance is available doesn't stop jetbrains/Google/OSS from creating an LS. Maybe no such exists as if now, but not from a technical blocker. Just no one created one.
It’s plenty open source — that is why all these forks exist!
VS Code itself does not work without various propriety stuff, but that is a different thing. A large number of open-source projects work that way. If you don’t like the proprietary stuff, the recourse is to fork it, modify it, and implement the remaining stuff yourself.
Yeah, I know all about that stuff. But nevertheless, you _can_ fork it.
Is it the most awesome, selfless, altruistic version of open source? Clearly not.
But is it better than being proprietary closed-source software? Well, that's a value judgement, so we can each decide that for ourselves. Personally, I think so, but maybe it depends. Regardless, though, it's open source, and if it weren't the software landscape would look very different.
Cursor, Windsurf, etc. would presumably not be as far along as they are, because they'd have to invest in basic editor functionality. Among many other projects, both open-source and otherwise.
Some major bits and pieces of the base editor are, but little of what makes vscode into a usable productive tool (namely, the refined extensions and LSP implementations around it, i.e. what users come to expect when they install it in the first place) is open-source. vscode put a lot of marketing effort into being perceived as open-source so to buy sympathy from eventual users.
Let's stop at "vscode is open-source in a very narrow and limited capacity, and thoroughly deceptive in its messaging".
I would honestly love to see the result of a survey asking vscode users whether they think they are using an open-source product, and how much of that is actually verified based on the extensions being used.
> Let's stop at "vscode is open-source in a very narrow and limited capacity, and thoroughly deceptive in its messaging".
OK, yes, I agree; we should stop, as the disagrement seems to boil down to semantics.
I think "open source" is basically binary (modulo the usual free-as-in-beer or free-as-in-beer-but-also-you-can't-do-stuff-I-don't-like ambiguity).
But some nuance does come into play around "VS Code" — what is it? It feels the same as Chrome to me, but it's harder to see where the VS Code equivalent of Chromium is. (Not super hard, mind you, but Chrome/Chromium make it explicit, whereas VS Code does not.)
Anyway, I agree that VS Code is (while still, IMO, "open-source") is not "open-source to the point of maximal awesomeness".
Walmart used to claim they supported US businesses. A lot of people remember the ads and the native ads, especially in southern California when Wal-Mart was trying to make inroads there in the late 90s.
Walmart. Bringing back home. ™
The CEO even said the quiet part out loud in one of the commercials in the early 90s, roughly "we'll buy American products, unless they're lesser quality or more expensive" and trailed off, and the editors back then weren't as tuned in to corpo-speak or something.
Of course the countries with more lax environmental regulations and worker protections will have a cheaper product; the entire thing was a sham from the beginning.
Microsoft is pro open source, it's just that they use it as a means rather than an end which trips up a lot of people who view open source differently.
Its a tool they use to encourage adoption of their developer tools and get people to spend more money in Azure, not a philosophical stance.
Pointless was my thought after initially installing it years ago. Ok, I’m installing this open source “clean” version, just to install a bunch of MS proprietary spyware extensions? Why not just use the real thing?
Nowadays there are good alternatives to some of the proprietary Microsoft extensions, I use the basedpyright extension on VSCodium and prefer it to Microsoft's proprietary Pylance. I've also heard good things about the clangd extension as an alternative to the C/C++ extension.
> While there are technical differences between Snap and Flatpak, the gist is the same. Offer a sandboxed, isolated, and universal package format for Linux. Universal package formats are an overall win in my opinion. And make Linux feel a little bit more like one operating system. Still, they are now yet another choice that the developer needs to make when distributing their software on Linux.
Someone has yet to explain to me how the Linux desktop is supposed to just agree on a universal standard for everything without a proprietary ecosystem, at which point it would just be a shittier Windows. And that's not even touching on the fact that alternatives often exist for valid reasons, i.e. Pipewire being obviously better than Pulse, which used to be a de facto standard. Or the fact that some companies like Bitwig have already demonstrated that commercial Linux software via Flatpak is viable - Adobe simply does not care, and they never will.
The irony of Windows users sharing their opinions on the Linux desktop is that they often sound how they picture existing Linux desktop users: people who treat their computers as toys. We're fully aware that using Linux has major caveats.
It's okay to just not like Linux, man. Nobody is forcing you to.
Seeing Brave New World references every time drugs are mentioned is tiring and pretentious. There is plenty to be said about the virtues of moderation and abstinence, and none of it involves invoking the most over-referenced book in modern history not written by Orwell.
There is no "just works" technical solution for a problem caused mainly by naivete and gullibility. Governments and the private sector know this, of course; as others have said, the real purpose is to control users, not to protect them.