10 ms·

A 2024 Plea for Lean Software

124 points by Teckla 3y ago

fiddlerwoaroof 3y ago
The funny thing to me about this is that Trifecta is still less lean than the minimal “image sharing site”: copy the images to a web root (for drag and drop, use Samba, NFS or your favorite remote mounting protocol over an internal network). Have a minimally-configured web server serve the image (perhaps with some html generator to make an actual page). 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/3daaf7ce49ca221702c70b0d10ac5caec8962b78.el*.html https://fwoar.co/pastebin/3daaf7ce49ca221702c70b0d10ac5caec8...
- kdklol 3y ago
  I don't disagree, but few non-techies will be able to download an image off of an FTP server or mount an NFS share. Thats where such a service adds value.
  - fiddlerwoaroof 3y ago
    No, that's the _upload_ mechanism: it's just an HTTP URL on the download side like normal.
    - kdklol 3y ago
      Yes, I meant upload, sorry. Downloading from a page is trivial. I was more concerned ith the case of grandma sending a picture or similar.
  - yjftsjthsd-h 3y ago
    I know my perspective is really skewed, but don't filezilla and the like make ~FTP easy enough? Or failing that, even Windows must have the hooks to (implement an add-on to) mount SFTP and treat it like a thumb drive? Why is it harder to use FTP/SFTP than a fancy web frontend?
    - jeffhuys 3y ago
      Because a lot of people nowadays just use a browser. That’s 99% of what a computer is to them. “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.
      - fiddlerwoaroof 3y ago
        This is less true of software like the one mentioned in the article that are intended to be self-hosted, though: I have to walk my users through using it anyways and so I can show them FileZilla or install a SFTP filesystem on their computer or setup syncthing/dropbox for them to handle uploads. There’s lots of ways to avoid exposing a custom file upload service for this sort of thing.
      - palata 3y ago
        > Because a lot of people nowadays just use a browser. That’s 99% of what a computer is to them. 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.
SadCordDrone 3y ago
I'm actually surprised that grafana is just 350 MB, I deal with more trivial images which pack 700-800 MBs.
- heads 3y ago
  The grafana/grafana-oss docker image has a bin/grafana static go binary that takes up 180MB. It compresses to 20% that size as does the long tail of .js.map files each of which are 1MB to 10MB in size. Presumably these are only there for debugging Javascript. I wonder why they were included? The whole image is ~80MB, compressed. It is, indeed, impressively lean.
transcriptase 3y ago
If any modern software company was given a spec sheet for Ventrilo (https://www.ventrilo.com/about.php https://www.ventrilo.com/about.php) and asked to develop it, you would get back a few hundred Mb installer that needed to download additional components, would send telemetry to their servers all day and check for updates, add background services to startup, and consume half a gig of ram while continuously managing to use a percent or two of your CPU at idle and probably even tapping the GPU to do god knows what. 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.
- fastball 3y ago
  Ventrilo (client) also: 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
  - hombre_fatal 3y ago
    It also has such a bad UX that few people use it anymore.
  - ahoka 3y ago
    Everyone moved to Discord which does all the things the parent complains about, but somehow it’s still a better product. As if most people don’t really care about those, for the better or worse.
- noduerme 3y ago
  This is one of the luxuries of developing only in-house software for a business. You have none of the incentives to add consumerware bloat, and in exchange you get all that extra time to refactor and focus on making things svelte, performant, scalable, documented and concise. 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.
  - sakjur 3y ago
turtlebits 3y ago
This article is a bit hyprocritical. The example is an image sharing tool, but you don't resize images at all. 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.
- torstenvl 3y ago
  > > In this post I briefly go over the terrible state of software security, and then spend some time on why it is so bad.... The security of software depends on two factors - the density of security issues in the source code, and the sheer amount of exposed code.... It is not just the amount of code that is worrying. It is also the quality, or put another way, the density of bugs. > 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.
  - turtlebits 3y ago
    The author spends a lot of time on how large software has gotten, even going as far as comparing the size of their image sharing tool to another. 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.
    - torstenvl 3y ago
      Not stripping EXIF metadata is not a security vulnerability. The only EXIF-related CVE I can find is in fact the opposite. https://nvd.nist.gov/vuln/detail/cve-2021-22204 https://nvd.nist.gov/vuln/detail/cve-2021-22204
      - lolinder 3y ago
        Attack surface is about all the ways in which your software might be used to harm you or your customers. It's more than just remote code execution or DOS attacks. 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.
somenameforme 3y ago
The article doesn't mention the most basic cause and issue: motivations. One guy writes absurdly bloated and bug prone code, but creates workable components/products/whatever in a month. Another guy writes tight, elegant, and rock solid code for the same thing in 6 months. The first guy's getting promoted and the second guy's going to end up having to explain his 'lack of productivity.' 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.
- bee_rider 3y ago
  Why do we have all these layers of middle management, if not to promote the first guy up into them and hopefully out of the way?
- palata 3y ago
  > Nobody (at the top) wants to reduce bloat because it would likely reduce rather than increase profit on short time frames. And also because they were probably "the first guy", chances are that they don't even know about bloat at all.
photonthug 3y ago
Maybe we should drop the idealism and be realistic: for various reasons bloatware is not going away. If we were to admit something like that, the next question is what can be done? We need better tooling for generating and reasoning about software manifests and supply chains, and we need better tooling and training for at least lightweight formal methods in design / development phases. Industry adoption of such things is not impossible but it needs to be more accessible to devs without phds and it needs to be faster/cheaper.
- SilentM68 3y ago
  Unfortunately, bloatware is the reality and that is depressing :( I wish things were like the 90s and software dev environments like Rebol [ http://www.rebol.com http://www.rebol.com ] were still king. It was simple to use, small executables, expressive, but no longer maintained :(
  - brabel 3y ago
    There's a descendant of Rebol that is maintained: https://www.red-lang.org/ https://www.red-lang.org/
    - SilentM68 3y ago
      Yes, I was aware of RED since it was proposed but I have not checked its progress to see how it has evolved.
    - pbronez 3y ago
      Red looks pretty cool. Will try it out once they reach 1.0!
- anta40 3y ago
  >> the next question is what can be done? 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.
- 3y ago
hasoleju 3y ago
I already experience the change in perspective that the new legislation caused. The new legislation requires software to be developed compliant to standards that define detailed thread and risk analysis processes and requires suppliers to offer updates for all their customers if a security breach was found in their software or in a dependency. This often is a big logistically challenge. Both requirements already lead us to rethink which dependencies we want to include in our software.
dilawar 3y ago
I just downloaded a freshly minted app from Notion called Notion calendar. It looks beautiful, and it's download size is 84Mb! Most likely an electron app.
injuly 3y ago
I feel that we would've had better tooling for writing performant GUI apps today if electron JS never took off. 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/ 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.
- stakhanov 3y ago
  Lack of toolchain is one problem, although I think that there are alternative toolchains out there that are quite feature-rich and could definitely achieve feature-parity with the web ecosystem, if only there was enough interest in using them. 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.
  - brabel 3y ago
    You know, I thought I was a fool for writing my apps in JavaFX... but after trying many other things, it seems it's up there with the best of the bunch. 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.
nmca 3y ago
By 2030, if not sooner, the idea of humans writing software will be very quaint.
- Aerbil313 3y ago
  People are downvoting you now, but this is very possible… Save it as a bookmark.
- FpUser 3y ago
  I think some particular cases might be covered but in general I think your prediction is total BS.
- abenga 3y ago
  Ha ha, no. What will replace humans? LLMs? Doubtful.
  - ceeam 3y ago
    I think his point was mostly about "writing software". As in you won't need specific software anymore and the computer/network would do what you tell it without specific "apps".
rollcat 3y ago
Mesa alone is like 50mb of tightly optimized x86-64 machine code (Windows 95, by comparison, came on 8x1.4mb floppies); and that's just to talk to the actual kernel drivers - you need that for the GPU to draw things on the screen (unless you want software rendering = idle silicon). 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?
- pixelesque 3y ago
  I think Windows 95 came on 13 1.4MB floppies actually...
  - rollcat 3y ago
    I checked, and it was Win3.11 that came on 8 floppies! https://archive.org/download/dos-622-3 https://archive.org/download/dos-622-3 Windows 95 was almost 30: https://ia803207.us.archive.org/view_archive.php?archive=/22/items/windows-95-oem-floppy-disk-version/Windows%2095%20OEM%20-%20Floppy%20Disk%20Version.rar 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 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.
- guappa 3y ago
  mesa is a shared library, electron isn't. That's a way to draw a line.
scott_w 3y ago
I’m struggling with this post because it seems to imply that software quality has gotten worse over time. Bluntly put: I think this is nonsense. 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?”
- stakhanov 3y ago
  I think there was a kind of "golden period" that goes in between. 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.
jackblemming 3y ago
Seems like a lot of complaining and the only solution offered is regulation or “just do it better”? Ok.
rubymamis 3y ago
That is why I've decided to develop all my apps in Qt C++ and QML. For example I've created Plume[1] - an alternative to the resource-hag Electron app Notion. It's the fastest block editor in my benchmarks (on the website). Faster than the fastest comparable native app on macOS. 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. [1] https://www.get-plume.com/ https://www.get-plume.com/
- petabyt 3y ago
  Doesn't Qt make you pay for a license in order to statically link?
  - rubymamis 3y ago
    If you use Qt under the GPL, you can statically link Qt with your application, but your application must also be licensed under the GPL. If not, then yes, you need to pay for a license. That's from what I know.
  - guappa 3y ago
    Then don't statically link? What's the problem?
jillesvangurp 3y ago
The software crisis was proclaimed to exist as early as 1969. We never solved it. But we did massively improve the scope of what software can do. The natural state of software is always to be almost but not quite at the breaking point. This is actually fine. Occasionally something goes wrong and then we fix it. And we move on. But the amount of stuff that works just fine is actually constantly growing. 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.
defanor 3y ago
While I generally agree with the article, the "reality check" project seems somewhat forced: there are many widely used projects that are fairly lean. Many of the GNU projects are like that, not to mention explicitly minimalistic ones, and generally on a GNU/Linux system (either server or desktop) you have a few notable resource hogs, but the rest you would barely notice. Many of those can be built without Python build-time dependencies, too. And there are tens of thousands of proper packages in common distributions' repositories, so surely it is possible. The mentioned Electron, Node.js, and SaaS examples probably happen more often in certain other settings, perhaps enterprise software tends to be like that. Likely its advocates would bring up speed and cost of development, and it may be argued that even security is improved with those, given the other constraints. A more interesting "reality check" may be to take a few actual (and preferably somewhat widely used) bloated projects, and implement leaner alternatives, while fitting into the same constraints: similar profits for commercial projects, maybe similar initial expertise levels, time spent, and perceived impact for non-commercial ones.
- culebron21 3y ago
  Linux distros nowadays runs several hundreds of processes, just after fresh install. That's nowhere near "lean".
  - palata 3y ago
    It really depends on the distro. But of course there is the same risk as ElectronJS: getting a huge Ubuntu distro that ships with everything is faster than building up from a lean distro. Not better, just faster.
  - guappa 3y ago
    30 processes of 100kb each are still less than 1 process of 500mb
  - defanor 3y ago
    That aspect could be leaner, indeed, although all those processes put together can easily consume fewer resources than a single bloated program or a web page, especially if they do not include a particularly large DE. The systems I have in mind as references are Debian with Xfce (runs on an old Atom-based netbook, taking 600 MB of main memory altogether), or Debian on a server with a bunch of common services (web, email with related services, XMPP, Gopher, IRC bouncer, authoritative and caching DNS servers, etc), also consuming under 600 MB (under 400 without DNS cache), with CPU load coming mostly from fail2ban, but being pretty close to zero. On the other hand, there are KDE and GNOME, which would probably at least double that resource usage. 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.
petabyt 3y ago
I just released an update to my open source tool where the binary+dll size was reduced from 33mb to 1.4mb. Feels good to get rid of bloat.
- pabs3 3y ago
  What was the bloat you got rid of?
- rubymamis 3y ago
  Any more information on how did you manage to do that? Where was the bloat coming from?
badgersnake 3y ago
Google are the worst. The dependencies for something a simple as the official cloud storage client are horrendous. I just want to download a file from a bucket, why do I need all this cruft.
deleted 3y ago
[deleted]
robin-whg 3y ago
But you can't have the cake and eat it too. We can't expect every company to maintain native apps for every platform and a website on top of that; not relying on 3rd party packages and instead to write everything themselves. Maintaining all that, they're bound to f-up at some point and expose vulnerabilities.
- palata 3y ago
  > Maintaining all that, they're bound to f-up at some point and expose vulnerabilities. Who maintains the 1600 dependencies of a project? Pretty sure some of those expose vulnerabilities. Not counting those that are downright malware.
- nottorp 3y ago
  Yep, for some reason only poor indie gaming companies do that. 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.
culebron21 3y ago
To commenters claiming this is nonsense, I can point at Firefox packaging for Linux, which is now on Snap, and it's like Docker container. A little version bump happens silently and eats up __extra__ ~500 MB (old versions are kept!), where it used to be (just ~5 years ago) like 50MB for the whole binary, and it was replaced upon update. 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 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.
- gkbrk 3y ago
  > I've installed `clickhouse-client` (a new SQL database), which needs almost 900 MB for just a CLI client 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.
palata 3y ago
I wish legislation was pushing for open APIs. 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.
mikewarot 3y ago
>Software security is dire 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.
1vuio0pswjnm7 3y ago
"I hope that this post provides some mental and moral support for suffering programmers and technologists who want to improve things. It is not just you, we are not merely suffering from nostalgia: software really is very weird today." 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.

124 points by Teckla 3y ago

The funny thing to me about this is that Trifecta is still less lean than the minimal “image sharing site”: copy the images to a web root (for drag and drop, use Samba, NFS or your favorite remote mounting protocol over an internal network). Have a minimally-configured web server serve the image (perhaps with some html generator to make an actual page). 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/3daaf7ce49ca221702c70b0d10ac5caec8962b78.el*.html https://fwoar.co/pastebin/3daaf7ce49ca221702c70b0d10ac5caec8...

kdklol 3y ago
I don't disagree, but few non-techies will be able to download an image off of an FTP server or mount an NFS share. Thats where such a service adds value.
- fiddlerwoaroof 3y ago
  No, that's the _upload_ mechanism: it's just an HTTP URL on the download side like normal.
  - kdklol 3y ago
    Yes, I meant upload, sorry. Downloading from a page is trivial. I was more concerned ith the case of grandma sending a picture or similar.
- yjftsjthsd-h 3y ago
  I know my perspective is really skewed, but don't filezilla and the like make ~FTP easy enough? Or failing that, even Windows must have the hooks to (implement an add-on to) mount SFTP and treat it like a thumb drive? Why is it harder to use FTP/SFTP than a fancy web frontend?
  - jeffhuys 3y ago
    Because a lot of people nowadays just use a browser. That’s 99% of what a computer is to them. “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.
    - fiddlerwoaroof 3y ago
      This is less true of software like the one mentioned in the article that are intended to be self-hosted, though: I have to walk my users through using it anyways and so I can show them FileZilla or install a SFTP filesystem on their computer or setup syncthing/dropbox for them to handle uploads. There’s lots of ways to avoid exposing a custom file upload service for this sort of thing.
    - palata 3y ago
      > Because a lot of people nowadays just use a browser. That’s 99% of what a computer is to them. 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.

SadCordDrone 3y ago

I'm actually surprised that grafana is just 350 MB, I deal with more trivial images which pack 700-800 MBs.

heads 3y ago
The grafana/grafana-oss docker image has a bin/grafana static go binary that takes up 180MB. It compresses to 20% that size as does the long tail of .js.map files each of which are 1MB to 10MB in size. Presumably these are only there for debugging Javascript. I wonder why they were included? The whole image is ~80MB, compressed. It is, indeed, impressively lean.

transcriptase 3y ago

If any modern software company was given a spec sheet for Ventrilo (https://www.ventrilo.com/about.php https://www.ventrilo.com/about.php) and asked to develop it, you would get back a few hundred Mb installer that needed to download additional components, would send telemetry to their servers all day and check for updates, add background services to startup, and consume half a gig of ram while continuously managing to use a percent or two of your CPU at idle and probably even tapping the GPU to do god knows what. 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.

fastball 3y ago
Ventrilo (client) also: 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
- hombre_fatal 3y ago
  It also has such a bad UX that few people use it anymore.
- ahoka 3y ago
  Everyone moved to Discord which does all the things the parent complains about, but somehow it’s still a better product. As if most people don’t really care about those, for the better or worse.
noduerme 3y ago
This is one of the luxuries of developing only in-house software for a business. You have none of the incentives to add consumerware bloat, and in exchange you get all that extra time to refactor and focus on making things svelte, performant, scalable, documented and concise. 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.
- sakjur 3y ago

turtlebits 3y ago

This article is a bit hyprocritical. The example is an image sharing tool, but you don't resize images at all. 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.

torstenvl 3y ago
> > In this post I briefly go over the terrible state of software security, and then spend some time on why it is so bad.... The security of software depends on two factors - the density of security issues in the source code, and the sheer amount of exposed code.... It is not just the amount of code that is worrying. It is also the quality, or put another way, the density of bugs. > 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.
- turtlebits 3y ago
  The author spends a lot of time on how large software has gotten, even going as far as comparing the size of their image sharing tool to another. 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.
  - torstenvl 3y ago
    Not stripping EXIF metadata is not a security vulnerability. The only EXIF-related CVE I can find is in fact the opposite. https://nvd.nist.gov/vuln/detail/cve-2021-22204 https://nvd.nist.gov/vuln/detail/cve-2021-22204
    - lolinder 3y ago
      Attack surface is about all the ways in which your software might be used to harm you or your customers. It's more than just remote code execution or DOS attacks. 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.

somenameforme 3y ago

The article doesn't mention the most basic cause and issue: motivations. One guy writes absurdly bloated and bug prone code, but creates workable components/products/whatever in a month. Another guy writes tight, elegant, and rock solid code for the same thing in 6 months. The first guy's getting promoted and the second guy's going to end up having to explain his 'lack of productivity.' 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.

bee_rider 3y ago
Why do we have all these layers of middle management, if not to promote the first guy up into them and hopefully out of the way?
palata 3y ago
> Nobody (at the top) wants to reduce bloat because it would likely reduce rather than increase profit on short time frames. And also because they were probably "the first guy", chances are that they don't even know about bloat at all.

photonthug 3y ago

Maybe we should drop the idealism and be realistic: for various reasons bloatware is not going away. If we were to admit something like that, the next question is what can be done? We need better tooling for generating and reasoning about software manifests and supply chains, and we need better tooling and training for at least lightweight formal methods in design / development phases. Industry adoption of such things is not impossible but it needs to be more accessible to devs without phds and it needs to be faster/cheaper.

SilentM68 3y ago
Unfortunately, bloatware is the reality and that is depressing :( I wish things were like the 90s and software dev environments like Rebol [ http://www.rebol.com http://www.rebol.com ] were still king. It was simple to use, small executables, expressive, but no longer maintained :(
- brabel 3y ago
  There's a descendant of Rebol that is maintained: https://www.red-lang.org/ https://www.red-lang.org/
  - SilentM68 3y ago
    Yes, I was aware of RED since it was proposed but I have not checked its progress to see how it has evolved.
  - pbronez 3y ago
    Red looks pretty cool. Will try it out once they reach 1.0!
anta40 3y ago
>> the next question is what can be done? 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.
3y ago

hasoleju 3y ago

I already experience the change in perspective that the new legislation caused. The new legislation requires software to be developed compliant to standards that define detailed thread and risk analysis processes and requires suppliers to offer updates for all their customers if a security breach was found in their software or in a dependency. This often is a big logistically challenge. Both requirements already lead us to rethink which dependencies we want to include in our software.

dilawar 3y ago

I just downloaded a freshly minted app from Notion called Notion calendar. It looks beautiful, and it's download size is 84Mb! Most likely an electron app.

injuly 3y ago

I feel that we would've had better tooling for writing performant GUI apps today if electron JS never took off. 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/ 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.

stakhanov 3y ago
Lack of toolchain is one problem, although I think that there are alternative toolchains out there that are quite feature-rich and could definitely achieve feature-parity with the web ecosystem, if only there was enough interest in using them. 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.
- brabel 3y ago
  You know, I thought I was a fool for writing my apps in JavaFX... but after trying many other things, it seems it's up there with the best of the bunch. 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.

nmca 3y ago

By 2030, if not sooner, the idea of humans writing software will be very quaint.

Aerbil313 3y ago
People are downvoting you now, but this is very possible… Save it as a bookmark.
FpUser 3y ago
I think some particular cases might be covered but in general I think your prediction is total BS.
abenga 3y ago
Ha ha, no. What will replace humans? LLMs? Doubtful.
- ceeam 3y ago
  I think his point was mostly about "writing software". As in you won't need specific software anymore and the computer/network would do what you tell it without specific "apps".

rollcat 3y ago

Mesa alone is like 50mb of tightly optimized x86-64 machine code (Windows 95, by comparison, came on 8x1.4mb floppies); and that's just to talk to the actual kernel drivers - you need that for the GPU to draw things on the screen (unless you want software rendering = idle silicon). 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?

pixelesque 3y ago
I think Windows 95 came on 13 1.4MB floppies actually...
- rollcat 3y ago
  I checked, and it was Win3.11 that came on 8 floppies! https://archive.org/download/dos-622-3 https://archive.org/download/dos-622-3 Windows 95 was almost 30: https://ia803207.us.archive.org/view_archive.php?archive=/22/items/windows-95-oem-floppy-disk-version/Windows%2095%20OEM%20-%20Floppy%20Disk%20Version.rar 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 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.
guappa 3y ago
mesa is a shared library, electron isn't. That's a way to draw a line.

scott_w 3y ago

I’m struggling with this post because it seems to imply that software quality has gotten worse over time. Bluntly put: I think this is nonsense. 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?”

stakhanov 3y ago
I think there was a kind of "golden period" that goes in between. 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.

jackblemming 3y ago

Seems like a lot of complaining and the only solution offered is regulation or “just do it better”? Ok.

rubymamis 3y ago

That is why I've decided to develop all my apps in Qt C++ and QML. For example I've created Plume[1] - an alternative to the resource-hag Electron app Notion. It's the fastest block editor in my benchmarks (on the website). Faster than the fastest comparable native app on macOS. 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. [1] https://www.get-plume.com/ https://www.get-plume.com/

petabyt 3y ago
Doesn't Qt make you pay for a license in order to statically link?
- rubymamis 3y ago
  If you use Qt under the GPL, you can statically link Qt with your application, but your application must also be licensed under the GPL. If not, then yes, you need to pay for a license. That's from what I know.
- guappa 3y ago
  Then don't statically link? What's the problem?

jillesvangurp 3y ago

The software crisis was proclaimed to exist as early as 1969. We never solved it. But we did massively improve the scope of what software can do. The natural state of software is always to be almost but not quite at the breaking point. This is actually fine. Occasionally something goes wrong and then we fix it. And we move on. But the amount of stuff that works just fine is actually constantly growing. 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.

defanor 3y ago

While I generally agree with the article, the "reality check" project seems somewhat forced: there are many widely used projects that are fairly lean. Many of the GNU projects are like that, not to mention explicitly minimalistic ones, and generally on a GNU/Linux system (either server or desktop) you have a few notable resource hogs, but the rest you would barely notice. Many of those can be built without Python build-time dependencies, too. And there are tens of thousands of proper packages in common distributions' repositories, so surely it is possible. The mentioned Electron, Node.js, and SaaS examples probably happen more often in certain other settings, perhaps enterprise software tends to be like that. Likely its advocates would bring up speed and cost of development, and it may be argued that even security is improved with those, given the other constraints. A more interesting "reality check" may be to take a few actual (and preferably somewhat widely used) bloated projects, and implement leaner alternatives, while fitting into the same constraints: similar profits for commercial projects, maybe similar initial expertise levels, time spent, and perceived impact for non-commercial ones.

culebron21 3y ago
Linux distros nowadays runs several hundreds of processes, just after fresh install. That's nowhere near "lean".
- palata 3y ago
  It really depends on the distro. But of course there is the same risk as ElectronJS: getting a huge Ubuntu distro that ships with everything is faster than building up from a lean distro. Not better, just faster.
- guappa 3y ago
  30 processes of 100kb each are still less than 1 process of 500mb
- defanor 3y ago
  That aspect could be leaner, indeed, although all those processes put together can easily consume fewer resources than a single bloated program or a web page, especially if they do not include a particularly large DE. The systems I have in mind as references are Debian with Xfce (runs on an old Atom-based netbook, taking 600 MB of main memory altogether), or Debian on a server with a bunch of common services (web, email with related services, XMPP, Gopher, IRC bouncer, authoritative and caching DNS servers, etc), also consuming under 600 MB (under 400 without DNS cache), with CPU load coming mostly from fail2ban, but being pretty close to zero. On the other hand, there are KDE and GNOME, which would probably at least double that resource usage. 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.

petabyt 3y ago

I just released an update to my open source tool where the binary+dll size was reduced from 33mb to 1.4mb. Feels good to get rid of bloat.

pabs3 3y ago
What was the bloat you got rid of?
rubymamis 3y ago
Any more information on how did you manage to do that? Where was the bloat coming from?

badgersnake 3y ago

Google are the worst. The dependencies for something a simple as the official cloud storage client are horrendous. I just want to download a file from a bucket, why do I need all this cruft.

deleted 3y ago

[deleted]

robin-whg 3y ago

But you can't have the cake and eat it too. We can't expect every company to maintain native apps for every platform and a website on top of that; not relying on 3rd party packages and instead to write everything themselves. Maintaining all that, they're bound to f-up at some point and expose vulnerabilities.

palata 3y ago
> Maintaining all that, they're bound to f-up at some point and expose vulnerabilities. Who maintains the 1600 dependencies of a project? Pretty sure some of those expose vulnerabilities. Not counting those that are downright malware.
nottorp 3y ago
Yep, for some reason only poor indie gaming companies do that. 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.

culebron21 3y ago

To commenters claiming this is nonsense, I can point at Firefox packaging for Linux, which is now on Snap, and it's like Docker container. A little version bump happens silently and eats up __extra__ ~500 MB (old versions are kept!), where it used to be (just ~5 years ago) like 50MB for the whole binary, and it was replaced upon update. 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 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.

gkbrk 3y ago
> I've installed `clickhouse-client` (a new SQL database), which needs almost 900 MB for just a CLI client 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.

palata 3y ago

I wish legislation was pushing for open APIs. 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.

mikewarot 3y ago

>Software security is dire 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.

1vuio0pswjnm7 3y ago

"I hope that this post provides some mental and moral support for suffering programmers and technologists who want to improve things. It is not just you, we are not merely suffering from nostalgia: software really is very weird today." 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.