A 2024 Plea for Lean Software
berthub.eu
berthub.eu
Meanwhile Ventrilo 3 has a 5.4 Meg installer, consumes 4 megs of RAM, and does none of those things. The newer bloated version has a 7.9 meg installer.
As much as any company is willing to load their customer-facing or retail software with a million kinds of garbage, that's the last thing they want in their own toolkit.
One of the things that inspired that was seeing how much better the mobile version of websites often were than their apps. Thinking about Facebook, Twitter, Reddit and similar. Their apps don’t have tabs, often drop state, and seem to occasionally focus on shiny over usable. My local newspaper prevents you from copying any text in the app. The mobile websites on the other hand tend to mostly have an annoying “our app provides a better experience” banner to bypass, otherwise they’re engineered to work, not push the envelope. They’re important enough for some resources, but it doesn’t seem like there is quite as much noise during the development for the ‘fallback version’. And I think that makes all the difference.
1. does not run on Linux
2. the macOS client is incompatible with many servers
3. has been in development for twenty-one (21!) years
Though honestly, crossplatform software too often just bundles Electron rather than relying on the entire OS layer (on Mac and Windows anyways) having all of this stuff built-in. For bugs and reproducibility it's nice, but it really sucks for "downloading the same bytes over and over again". This is downstream of OS vendors just historically not fixing bugs, but in an alternate universe people would have working OS stacks and we would use that.
But yeah, that page is not for people who have no clue! But maybe that's not that bad? Idk how many who comes to that page having no clue what that webpage is about, but I would guess a very tiny percentage. Maybe it makes sence to assume that the wast majority ending up there knows the basics already.
It's been around for 21 years, has a wikipedia page [0], and is mentioned in at least one old meme-worthy DOTA song [1], so the OP likely didn't feel it needed an introduction.
[0] https://en.wikipedia.org/wiki/Ventrilo [1] https://youtu.be/qTsaS1Tm-Ic?feature=shared
It certainly has its place, and I laud the authors for their efforts, but seeing how every startup is using electron for their native applications, I have little hope for lean software.
At the end of the day, developers need to finance their projects. No other toolchain out there [1] is going to give you the flexibility, development speed, and freedom to develop beautiful looking desktop apps using the muscle memory you trained while writing webpages. Of course, you can write the same application in Qt, GLFW, whatever, but I don't think anyone will disagree that it's much slower to build and prototype responsive UIs with these tools.
[1] Wry and Tauri (https://tauri.app/) might be noteworthy, but I don't know how much of a difference they make, as the runtime is still JavaScript, HTML, and CSS.
JavaFX, even though it's outdated, is quite up to the job of replacing most Electron-based UIs. Qt is definitely extremely powerful, but has the drawback of being tied into the C++ ecosystem which seems rather dated now. Even some hobbyist efforts are worth mentioning in this category: AvaloniaUI (in the C# ecosystem), HaxeUI & FeathersUI (both in the Haxe ecosystem and building on game engines).
I think, the bigger problem is sourcing developers. Web developers are comparatively cheap and abundant, so a commercial entity is always going to have trouble justifying hiring a comparatively expensive and difficult-to-find developer in the C#, ObjC/Swift, or Java ecosystem, when the job can also be accomplished by a web developer.
My non-trivial app can be built with jlink to be a no-dependencies on JVM binary for all Operating Systems.... each of which sits at just 30MB... and when run, it needs around 60MB of RAM, which is a lot but I am yet to find a multiplatform UI toolkit that delivers much less than that... except for some toy frameworks which can't really be used for realworld apps.
1. https://federicoterzi.com/blog/why-electron-is-a-necessary-e...
I have been using linux for 20 years and I've yet to use one electron based software.
There is no problem with LGPL. From your link: " QT is free to use as long as you release your code as GPL"
That is false. It is free as long as you don't statically link qt, and you distribute your eventual changes to qt itself (which aren't needed in most cases).
Of course if we spread misinformation, we might draw different conclusions, which is why it is important to start from correct non-made-up premises.
But I also believe that most devs are not comfortable with linking/packaging/dependency management, and therefore don't really know how to handle LGPL (or to say it in a more politically correct manner: "don't have time to handle it properly"). Which is obviously a pity.
Using `macdeployqt`, `windowsdeployqt` and `linuxdeployqt` takes care of that in mostly one click. I used to look at other open source apps workflows to figure it out. Now, others can look at my app's workflows for a complete packaging experience for Windows, Linux, and macOS[1]. Huge credit to contributors for my OSS app for implementing and perfecting it.
[1] https://github.com/nuttyartist/notes/tree/master/.github/wor...
Ofc I’m simplyfying a bit since if you use Firefox as your browser and Tauri uses Chromium that’s two browsers worth of memory usage, but still not 5 or 10.
this will become a problem once the systray clock becomes it's own (electron based) app
The web is the best cross-platform environment we have as evidenced by the fact that developers flock to stuff like Electron at all, but then you end up needing to ship your own entire browser engine to achieve a reasonable level of control. If PWAs didn't threaten App Store business models we'd probably be in a better place RE web app distribution (just use the browser you're already using anyway).
Doesn't address the issue that web app development is flooded with bad choices and opinions that lead people to decide that the whole ecosystem is overcomplicated and bloated, but that's not an opinion I hold very dear as someone who feels pretty comfortable with web tech stacks and understand where they came from.
I do think the skill bar is too high right now, where most engineers are likely to do a bad job RE performance and security with what we have unfortunately. But I'm not confident your average engineer would do any better if it were a different ecosystem.
I suspect that web developers who only know web development flock to electron because they think it's easier than learning a new technology.
In my professional experience, it is perhaps easier for a web developer who only knows JS to get a prototype working, but when you want a nice application you end up having to re-implement a number of things that any regular widget toolkit would already offer. So on the long term I don't think it's cost efficient at all, but at that point you've already spent resources on your electron GUI so you keep going forever.
Why do you restrict yourself to only knowing how to write webpages?
> Of course, you can write the same application in Qt, GLFW, whatever, but I don't think anyone will disagree that it's much slower to build and prototype responsive UIs with these tools.
Maybe because you don't have the "muscle memory" to write Qt?
But since you mentioned Qt, one of the greatest hits to developing cross platform applications was the Nokia/Microsoft disaster.
Nokia bought Qt from Trolltech and made it LGPL, because their plan was to make money from the hardware not the software. Then they died, for reasons that have been commented on endlessly.
From the ashes of Nokia rose Digia or whatever it's called this week, a company that maintains Qt badly and thinks it's a good idea to threaten developers that download their LGPL product.
RIP Qt, RIP cross platform development.
With that attitude I can't recommend it to any entity that can't afford a full time legal team.
https://www.qt.io/download-open-source
Here you go. Now that I looked at it, it's not only threats any more, it's a combination of threats, lies * and begging.
The point is not to discuss the properties of LGPL but Digia's attitude towards potential LGPL users.
* "In return for the value you receive from using Qt to create your application, you are expected to give back by contributing to Qt or buying Qt."
Where does the LGPL say that, I wonder?
That’s just how the market is. If you want to build your app with electron, you’ll find mountains of skilled developers everywhere. If you use QT, you’ll either have to pay an absolute fortune for the 10 people that know it, or accept hiring people that have never used it before.
Possibly easier to use a framework that includes a lot of things, rather than a language with no standard library that requires a soon-to-be-compromised dependency for every string function that QString already offers.
JavaScript might be a disaster of a language, but it is faster to make a UI with CSS. I can totally see why startups pick web programming to ship desktop apps.
The average software project sits on ginormous mountain of existing software. Libraries, components, tools, operating systems, etc. As a percentage of the overall source code, the tiny bit you add is a vanishingly small proportion. All this stuff exists, is being maintained by someone, and replacing it with something else has very low economic value. It adds negative value when it doesn't work because then you have to fix it or deal with the problems it is causing. But if it works as advertised, it just levels the playing field. Because everybody else is at that level as well.
Your attention as a software engineer should be focused mainly on things that others don't have that are valuable. It's always been like that. What has changed over time is the amount of stuff that you no longer have to build or worry about that much. That's the value of cloud based services. You get a lot of decent quality stuff that you pay a premium for that would be very expensive to match with in house development. Reinventing wheels like that is not lean but stupid.
So your server binary is tiny, but you're serving full size unoptimized images and wasting bandwidth for every single user that visits the site, as well as the uploader. Even thumbnails are served full size.
In this case you're optimizing for the wrong thing.
> This article is a bit hyprocritical. The example is an image sharing tool, but you don't resize images at all.
Can you explain how serving full-sized images opens up additional security vulnerabilities?
I don't see the connection between your argument about bandwidth and the OP's argument about attack surface.
More lines of code don't necessarily correlate to less secure - in fact, the author's tool makes a big security mistake, it doesn't strip EXIF.
The only EXIF-related CVE I can find is in fact the opposite. https://nvd.nist.gov/vuln/detail/cve-2021-22204
For many use cases stripping EXIF is a hard requirement for user privacy and security, and it's reasonable for OP to point out that cutting that out to cut lines of code would be inappropriate in many situations.
Show me the CVE that would provide any weight to the inflammatory and egregious claim that OP is a hypocrite.
> This article is a bit hyprocritical
Privacy in that sense is security. Never heard of OSINT? EXIF tags are of course security relevant.
/e: to make it more obvious: if I know your neighbourhood I can just blackmail you, I don't even have to hack you. I can gather information by maybe finding out your identity, getting insight into security questions and how you might answer them. I can find newspaper articles you were maybe part of etc. etc.
For example, there was no CVE issued for the security flaw that leaked private information of 530 million Facebook users before 2019 [0], but that was obviously a significant security flaw.
Edit: Also, regarding "privacy is not the same as security"—the line is a lot fuzzier than you think. At my org the same team ("infosec") is responsible both for the security of our products and the enforcement of rules regarding PII, because they're tightly interrelated—the main concern with security incidents is that we might lose PII. There's a reason why one of the 7 data protection principles in the GDPR is security [1]—without it there is no privacy.
[0] https://www.npr.org/2021/04/09/986005820/after-data-breach-e...
Which is not a security issue per se, is it? If the goal of the project is to self-host it and share it with family, then keeping the EXIF may be a feature.
but usually it does
Not better, just faster.
To be clear, I brought up GNU/Linux distributions as examples of container-free packaging, and as notable collections of relatively lean programs, but not necessarily as an example of the combined systems being particularly lean themselves. Though then again, compared to something like recent Windows versions, perhaps even the Linux-based systems with larger DEs would seem lean.
I wish things were like the 90s and software dev environments like Rebol [ http://www.rebol.com ] were still king.
It was simple to use, small executables, expressive, but no longer maintained :(
Minimize the usage of JS-based libs/tools, perhaps? Yes, I'm looking my daily tools like VSCode, Postman etc which are Electron-based. Perhaps rewriting it into Go/C++/Pascal could shrink the bloat.
It's not always that we need better tooling. Here I think we need better developers, as in "developers who care about this issue".
Developers are the ones including the bloat, right? If all the developers started working slower but including less bloat, what would the managers do? Probably the managers have no clue about the complexity of what their devs do: they just compare the tasks with t-shirt sizes (with estimations that are generally completely wrong, but they still use them).
The problem is that if one developer works slowly writing less bloated code, and their 3 coworkers keep adding bloat, then not only it's still getting bloated, but the first dev appears to be less productive.
It's a kind of competition between developers, where those who do the better job lose.
Does every program need all of that code? There's libraries in there to handle OpenGL (in half a million different versions), Vulkan, AMD, Intel, Nouveau, etc... Nope, you usually need just the tiny bits relevant to your application+hardware. But what's easier, figuring out which bits you don't need - or making the stack more portable and future-proof, by always shipping everything?
A lot of complexity is accidental, but most of it comes from conscious choices to make life simpler for everyone. Of course taken to the logical extreme, we do end up with Electron, but where are we supposed to draw the line?
Windows 95 was almost 30: https://ia803207.us.archive.org/view_archive.php?archive=/22...
Another fun article currently on the front page, diving into the insanity that is 8086/286/386 addressing modes: https://blogsystem5.substack.com/p/from-0-to-1-mb-in-dos
Even these "simple" operating systems managed to pack an incredible amount of complexity - again, just to deal with hardware, portability, different APIs, etc. Consumers - we, we demanded all of that.
If we really wanted/needed simpler software, OpenBSD is right around the corner. I've used it on&off as a daily driver for a bit, and it has an incredibly high ratio of code quality/readability vs how practical it is for everyday things (while remaining very portable). But simplicity is an uphill battle.
You could (theoretically, I think) link Mesa statically.
Hiding the complexity is not necessarily bad, but that decision should be made consciously. Some complexity is inherent to the problem space, some is accidental - but even the latter must sometimes be tolerated. So again, how do we draw the line?
My point was that a sane system package manager has maintainers for the packages and should not accept to ship a full OS in a single package.
Consider:
apt-get install myapp
CGO_ENABLED=0 go install example.com/myapp@latest
Also consider that the former command merely installs a pre-built artifact - try building Chromium from source. How is this not hiding complexity?
> My point was that a sane system package manager has maintainers for the packages and should not accept to ship a full OS in a single package.
How do you make that choice? Where do you draw the line? Why does Emacs make the cut, but VS Codium doesn't?
Also you can go check the recipe of your package, and if you choose a distro that only ships open source software, then it gives you the sources that were used to built it. You can even build it yourself. But again those are not points that I believe go into a "static vs shared" debate. Or do you disagree with that?
> How do you make that choice? Where do you draw the line? Why does Emacs make the cut, but VS Codium doesn't?
That's a distro philosophy. That's all a distro does, and you choose the distro that you like. Some distros will ship everything they can, some will be minimal, some will ship only free software, etc.
IMO it is not the developer's decision how I want my software packaged. It's a distribution question. The developer should provide the code open source, and let package maintainers build it and ship it in their distribution. If the developer (and the language tooling) can make it easy for maintainers to make their choices, then that's good. On the contrary, when the language officially refuses shared libraries, I think it oversteps.
I've been asking all of this time: where to draw the line between striving for simplicity, and just shipping software? How much complexity is acceptable because it's absolutely necessary, and how much of it is acceptable because we're busy doing more interesting things?
I keep pulling counter-arguments from both sides, because I don't think this line is clear. The closest thing we have to an objective measure seems to be the patience of the humans who have to deal with said software.
> The developer should provide the code open source, and let package maintainers build it and ship it in their distribution.
We're going a bit off topic here, but this has proven to be a poor model for many applications - see Linus' lament on trying to ship Subsurface builds for Linux, and his endorsement for AppImage.
Also: every single proprietary app in existence, which is a many-trillion-dollars industry.
> On the contrary, when the language officially refuses shared libraries, I think it oversteps.
Well that's an example of the practical trade-off that Go has made: they'd probably prefer to live in an ideal world, where you ship a static binary 100% of the time and completely refuse non-Go code, but instead they built cgo, which made C interop easy and practical.
Well I agree: the line is not clear at all. It is a matter of use-case and also of preference. Hence my point: developers should let those who build and distribute the code decide what they want, and organize their code such that both work (usually it does not require a lot of effort from the developer).
> see Linus' lament on trying to ship Subsurface builds for Linux, and his endorsement for AppImage.
I would think that this is his preference. My preference is to be given the sources and to build it myself, which allows me to maintain a package for my preferred distro.
> but instead they built cgo, which made C interop easy and practical.
Yes, I think this is great! On the Rust side, is cargo-c an official project though? It doesn't seem like it...
That's what happens when you use experimental libraries that are not ready for use. Your software goes into the "experimental" section.
He was in the wrong there, but likes to spin his own fantasy version of the events at conferences.
It creates a motivation system of to get something working, or even more cynically to just get something that looks like its working. The half dozen intermittently en vogue development acronyms also further this mindset. I don't see how to overcome this issue, because it's something like a tragedy of the commons. Nobody (at the top) wants to reduce bloat because it would likely reduce rather than increase profit on short time frames. Yet, at scale, it's leading to a complete enshittification of all software.
And also because they were probably "the first guy", chances are that they don't even know about bloat at all.
A while back, I wanted to host a pastebin for sharing bits of code and other text. Then I realized that about 10 lines of (compile-time) elisp gave me everything I needed to turn any webserver I could ssh to into a pastebin with no runtime dependencies aside from nginx: https://fwoar.co/pastebin/3daaf7ce49ca221702c70b0d10ac5caec8...
“What’s a filezilla?”
“go here, drop files there” instead of “download this, put this here, connect, drop your files here” makes the difference between people using your service and not using your service.
Doesn't mean they could not learn that it is not. I think that developers underestimating users is a problem. "They are too dumb to run a desktop app, so let's put everything in the browser" is a weak argument to me.
I remember using Windows 9x, the running jokes about poor quality and security of all MS products. Adobe’s formats came from those early days and are roundly mocked. Hell, I’ve built replacements for 90s software and, I can assure you, what I replaced was not high quality or robust at all.
On this very site, we discussed Horizon: a project started in the 90s and 20000s that was so badly built that it led to hundreds of innocent sub-postmasters being imprisoned, bankrupted and a number committed suicide.
Is the author just romanticising the “good old days?”
In the 90s, the economics around software had already heated up to the point where there was an insatiable appetite for software engineering manpower, but the university system wasn't yet geared to churning out specialists in this field in such large numbers, so a lot of software engineers back then were people coming from other professions who picked it up autodidactically and were just not very good. At the same time programming languages and tooling weren't yet at a point where they were good at guiding people towards good software engineering practice, and this lead to a kind of software quality crisis.
But this situation changed fast. I would say from maybe roundabout 2003 to maybe roundabout 2013 there was a bit of a "golden period" where we had good reason to be optimistic about the future of software quality. The software quality crisis of the 90s was largely overcome through better education, better software engineering methodology, and better programming language ecosystems and toolchains. Back in those days we still had purpose-built tooling for doing things like desktop UIs. Windows Forms based in C# and Aqua-era MacOS GUI programming in ObjC were actually quite a good experience for both developers and users. We also had cross-platform ways of doing GUI programming like Swing on Java.
In the next ten years, i.e. the ten years leading up to now, things took a decided turn for the worse. If I were to speculate about the reasons, I would say it was related to the rise of mobile, and the continued rise in the importance of the web platform over the desktop platform, meaning that application development now had to straddle web, mobile, and desktop as three distinct development targets. This created a need for truly cross-platform application development, while Apple and Microsoft continued to make plays to fortify their monopoly power instead of giving the world what it needed. Swing/JavaFX lost its footing when enterprises decided that web was all they really needed.
So, to answer your intial question: Has software quality really gotten worse? I would say, yes, over the last 10-15 years definitely. If you compare now to the mid-90s, then maybe, maybe not.
By what metric?
Taking all your above examples, I (and many others) could argue that the move to web brought new techniques that overall improved software for developers and users. That's not to say I'm right, or you are, but to point out that everything you put forward is purely subjective.
What has objectively gotten worse in the past 10 years?
I've never seen a chat app taking gigabytes of RAM before Electron, for example.
I've extremely rarely seen applications going nuts, eating several CPU cores and draining my battery in 20 minutes before Electron, for example. Now it's a weekly occurence.
It's improved only for developers who only know web development. And we users pay for it in hardware costs, electricity costs etc.
Is that a general software problem or a problem specific to Electron? Is that a permanent problem or a problem right now because of the technology and your attitude towards it?
I say this because I do recall seeing complaints about Java being bloated in the 2000s. I briefly used Swing in my university days and it was pretty awful compared to HTML at the time. In 2044, maybe I'm going to be shaking my fist at the new-fangled tech and telling everyone how nice Electron apps were in comparison.
It's bloated in the 2023s too. Last year I caught Android Studio (which I wasn't even using at the moment, just had it open from a quickie fix a few days ago) going over 4 Gb of ram. I had two projects open, under 20k lines of code total (ok, maybe I should count again).
But why bring Java in? We're talking about native applications vs applications that pull in a copy of Chrome and half of the npm registry. Java isn't native either.
Why not?
> We're talking about native applications vs applications that pull in a copy of Chrome and half of the npm registry.
You might be but I'm not. I'm talking about the state of software in the 1990s, 2000s, 2010s and today and how a general "it's worse" isn't particularly useful (or probably even true).
Oh and... if you want problems specific to Electron... I'm pretty sure Discord was keeping all the cat pictures and memes that it had ever displayed uncompressed, in ram, for a long while. Memory usage of several gigabytes if you had the meme channel open. Even it displayed only the last 3 cats.
It's better these days but it was a problem for years. And tbh I'm not sure they fixed it or even realized or cared about the problem or one of the 2498127 npm packages fixed it.
It seems you don't get my point so let me be explicit:
Pointing out issues with a single framework that powers a subset of software does not mean there is a general decline in software quality across the industry.
On the user's side: Just pick any set of well-established best practices such as Shneiderman's Eight Golden Rules or Nielsen & Molich's 10 Usability Heuristics, an then pick a typical 2024 electron app that has an equivalent from the 2003-2013 era and is written with a typical UI technology of the time (such as Windows Forms), and compare the two UIs with respect to those best practices. -- I'm pretty sure you will find usability blunders in today's software that you simply couldn't commit back then, even if you tried. -- Essential UI elements being hidden away (with no indication that such hiding is taking place) based on viewport size, leaving the user unable to perform their task is one thing that immediately comes to mind. Another example I happened to experience just yesterday: UI elements disappearing from underneath my mouse cursor when my mouse cursor starts to hover over them.
Also: Just look at the widget gallery in Windows Forms, providing intuitive metaphors for even quite subtle patterns of user interaction and check how many of those widgets you find implemented in modern web-based design languages and web component systems. ...usually you don't get much beyond input fields, buttons, and maybe tabbed-views if you're lucky. So today's software is relegated to using just those few things, where, 10 years ago, you had so many more widgets to pick and choose from to get it just right.
On the developer's side: Was JavaScript ever actually designed to do the things it's being used for today? Is dependency hell, especially in the web ecosystem, worse today than it was 10 years ago?
Excellent, we have something objective to look at. Now, where's the studies, reports, etc. that this has declined in the past decade? I'm not asking for a double-blind, peer reviewed study, just something a bit more concrete than "stop the world, I want to get off."
> Was JavaScript ever actually designed to do the things it's being used for today?
Was anything?
> [...] Now, where's the studies, reports, etc. [...] "stop the world, I want to get off."
This argument is getting a bit tediuos. It started with you offering an opinion. I offered a counter-opinion, while clearly marking my opinion as such using language such as "I think ...", "I would say ...", "If I were to speculate ..."
I'm clearly not alone with my opinion (see original post), and you're trying to undermine your opponents' credibility by getting ad-hominem and pointing out that their position lacks the kind of research which you yourself did not provide either.
> > Was JavaScript ever actually designed to do the things it's being used for today?
> Was anything?
Hyperbole. Many things were designed to do the things they now do. Lua was designed as a language for embedding. SQL was designed as a language for querying databases.
I recall seeing the same thing being said in the 2000s on Slashdot, so "software is shit now" is an opinion that's not new.
> and you're trying to undermine your opponents' credibility by getting ad-hominem and pointing out that their position lacks the kind of research
All I'm saying is that this popular position of "software used to be so much better" has strong "kids today" vibes.
> which you yourself did not provide either.
I'm not the one saying an entire industry has forgotten how to do our jobs.
> [...] strong "kids today" vibes. [...] entire industry has forgotten how to do our jobs.
The OP seemed to be pessimistic, your initial point was "It was pretty bad in the mid-90s, and it's no worse today" which is really not very optimistic either, and my point was "Well, it was bad in the mid-90s, then got better, then got worse again". So, FWIW, I think that my point was actually somewhat more nuanced than the pessimistic context. I was also expressing optimism towards certain technologies while expressing pessimism towards others.
[1] https://www.fastcompany.com/90338379/i-wrote-the-book-on-use...
Partially but I suspect things are better than everyone keeps saying. The whole "it used to be better" is a meme I see in all walks of life and I want to see something to prove it beyond a bunch of opinions.
Do I think some things are worse? Yeah, probably, such is the way of life. Do I think the entire industry went to shit? That's something that even the most respected people will need to provide evidence for. It seems a bit strange that I somehow joined the industry in 2010 and spent my entire career getting shitter and shitter.
Bloat does increase attack surface as mentioned.
There was reliable software in the old days as well. VAX/VMS, Windows NT 3.5x, my SGI workstation. Few wanted to pay for it. Today we have FLOSS.
It's 2024, why are we still blaming everything except the Operating Systems?
> simple products importing 1600 dependencies of unknown provenance.
Put yourself back in 1984... you've got an IBM XT with 2 floppy disks. You made write protected copies of all your important disks, and even more copies of your boot disk.
You'd go to a computer show, or your user group, and come home with stacks of software of unknown provenance, and then just try everything out over the next few weeks.
You were safe because your system made it easy to know what you were risking when you ran a program. There was one simple rule that was easy to understand:
Only un-write protected floppy disks in the drives were at risk.
That quite limited computer system was, in effect, a capability based security system. Crude, but extremely effective.
Here it is 40 years later, and the ability to just run code with abandon like we used to seems to be a fantasy to younger people. Because we don't expect our operating systems to be at least as safe as MS-DOS on an IBM-XT.
What about suffering software users.
"! want to end this post with some observations from Niklaus Wirth's 1995 paper.
"To Some, complexity equals power. (...) Increasingly, people seem to misinterpret complexity as sophistication, which is baffling - the incomprehensible should cause suspicion rather than admiration.""
Who were the "some people" to which Wirth referred. A wild guess: software developers.
I know many people push for interoperability, but that is a very hard problem. Open APIs are easy; I should be able to write e.g. my own Slack client, for my specific platform.
It is not a problem that there exists an (official) ElectronJS Slack app. The problem is that I am forced to use it. And what does it bring to Salesforce, except an opportunity to add telemetry in the app? With an open API, they would still make companies pay 5$ per account per month.
I believe that open APIs would enable better clients for popular services.
Yes, Qt is quite a bloaty - the binary size is 139.2mb currently, but I think with static linking and some trimming, I can get it much lower.
Who maintains the 1600 dependencies of a project? Pretty sure some of those expose vulnerabilities. Not counting those that are downright malware.
It's unrealistic to expect companies the size of Microsoft to take a break from putting spyware in your operating system and, for example, revert the piece of shit Skype has become back into a native app.
The whole image is ~80MB, compressed. It is, indeed, impressively lean.
And recently, I've installed `clickhouse-client` (a new SQL database), which needs almost 900 MB for just a CLI client!!! Absolutely insane!
I use QGIS, which is an open source alternative to ArcGIS, and a non-IT friend asked something to draw maps and see imagery -- I recommended QGIS, and he wrote: "1 GIG download? WTF IS THAT?" Oops. We didn't notice the little alternative open-source app turned into such a behemoth. (https://download.osgeo.org/qgis/windows/weekly/?C=M&O=D -- actually, since last year, it grew by 20%!)
The reason for this kind of bloat to me seems the race for version updates. And it probably did make sense in late '00s, when you could claim Linux ecosystem be underdeveloped. But 15 years late, it's still here. Every package is updated at high pace, breaking stuff downstream, and now instead of settling on compatibility, everybody just started to ship docker containers.
clickhouse-client is just a symlink to the main ClickHouse binary. That binary also includes the server and a lot of useful utilities.
It's large, yes, but it's on purpose it's super useful when you need to have a single binary for server, client, Zookeeper server, Zookeeper client, local data analysis tool etc.