10 ms·

Bloat is still software's biggest vulnerability (2024)

260 points by kristianp 1y ago

boznz 1y ago
Yet if you deliver a system without a modern bloated framework or a massive cloud stack and you are "old fashioned" and "out of touch" - been there done that, got the tee-shirt.
- al_borland 1y ago
  Being mandated to throw away simple and stable code in favor of the “new platform” that changes every 18 months has been one of the most frustrating experiences of my working life and turned me into a bit of a nihilist (in a work context).
jmclnx 1y ago
No argument from me, I also believe bloat is a very large problem. A get of my lawn section :) I remember when GUIs started becoming a thing, I dreaded the move from Text to GUIs due to complexity. I also remember most programs I wrote when I started on minis were 64k code and 64k text. They were rather powerful even by today's standards, they did one thing and people had to learn which one to use to perform a task. Now we have all in one where in some cases you need to page through endless menus or buttons to find an obscure function. In some cases you just give up looking and move on. Progress I guess.
- zelphirkalt 1y ago
  There is still a fundamental difference between move from text interface to GUI on one hand and adding bloat so many people add these days on the other hand. GUI is some entirely different paradigm of usage, while the bloat of today can often be replaced with little code and one retains the same functionality.
- rjsw 1y ago
  My first GUI applications used GEM, they were compiled to 8086 small model so the same 64k code and 64k data, didn't get close to running out of address space.
jongjong 1y ago
In my last job, just to run the software on my local machine, I had to launch 6 different microservices running in a containerized, Linux virtualized environment on Windows and had to launch them in a particular order and had to keep each one in a separate console for debugging purposes. It took about 20 minutes to launch the software to be able to test it locally. The launch couldn't be automated easily because each service was using a mix of containers and plain Node.js servers with different versions and it was Windows so I would probably have to write some unfamiliar code for Windows to automate opening all the necessary git bash tabs... The services usually persisted except for automatic updates so I only had to restart all the services a few times per week so it didn't make sense to invest time to automate.
- bee_rider 1y ago
  I like that they are containerized microservices, but you have to launch them in a particular order. Hahaha. What a nightmare. Congrats on it being a former job. Move on to better things? Well, unemployment would be preferable.
- vjvjvjvjghv 1y ago
  I had a discussion with team members and we agreed that we will make our next systems fully deployable with one script or installer. It requires a little more thought and discipline but will result in much cleaner architecture and will also document itself this way.
  - jongjong 1y ago
    Completely worth it IMO. My philosophy nowadays (on my side projects) is to make every software feel like a complete product that you can run out of the box, batteries included... I also try to support older engine versions to avoid setup issues. If you take care of the developer, the project looks after itself.
- n_ary 1y ago
  At the risk of sounding very naïve and making huge guesses, what you describe seems to be what docker-compose solves. Special order of services, launching several containers at once. However, I have seen my fair share of oddities in the trenches where containers are evolution of virtual machines(vagrant) running everything in one vm but now split out into containers without adapting to how containers work, because new tech lead thought vms were uncool and everything must be docker now.
GuB-42 1y ago
I am beginning to think that the terrible situation with dependency management in traditional C and C++ is a good thing. Now, with systems like npm, maven or cargo, all you need to do to get a package is to add a line in a configuration file, and it fetches all the dependencies you need automatically from a central repository. Very convenient, however, you can quickly find yourself with 100+ packages from who knows where and 100s of MB of code. In C, traditionally, every library you include requires some consideration. There is no auto-download, and the library the user has may be a different version from the one you worked with, and you have to accommodate it, and so does the library publisher. Or you may have to ship is with your own code. Anyways, it is so messy that the simplest solution is often not to use a library at all and write the thing yourself, or even better, realize that you don't need the feature you would have used that library for. Bad reason, and reinventing the wheel comes with its own set of problems, but at least, the resulting code is of a manageable size.
- klysm 1y ago
  Unfortunately that comes with the baggage of terrible memory safety. I do agree with the sentiment though, that deps should be taken with more consideration.
  - codr7 1y ago
    Given how much critical software is written in C, and the number of problems we run into; I don't see a reason to keep repeating that line outside of the Rust marketing department. Some people will always prefer C to Rust, might as well learn to live with that fact.
    - klysm 1y ago
      I never mentioned rust. I’m just saying C and C++ have terrible memory safety.
      - codr7 1y ago
        And what's the alternative then, from your perspective? What did you have in mind when you wrote the comment?
geodel 1y ago
Considering the disdain for software which does not have a thousand external dependencies in form libraries and framework is it any surprise?
gitroom 1y ago
This hits hard for me because I've run into way too much extra code getting piled on for no real reason. Stuff just gets harder to handle over time and gets in the way. Kinda makes me ask myself- you think folks are just chasing easy installs or is it more about looking busy than keeping things actually simple?
- voxelghost 1y ago
  Of the three great programmer virtues of Larry Wall, only laziness remains.
  - antfarm 1y ago
    For those who, like me, only knew Larry Wall’s quote “Lazyness is a virtue”, here are all three: https://thethreevirtues.com/ https://thethreevirtues.com/
dang 1y ago
Discussed at the time: A 2024 plea for lean software - https://news.ycombinator.com/item?id=39315585 https://news.ycombinator.com/item?id=39315585 - Feb 2024 (240 comments)
ronbenton 1y ago
>Even companies with near-infinite resources (like Apple and Google) made trivial “worst practice” security mistakes that put their customers in danger. Yet we continue to rely on all these products. I am at a big tech company and have seen some wildly insecure code make it into the codebase. I will forever maintain that we should consider checking if candidates actually understand software engineering rather than spending 4 or 5 hours seeing if they can solve brainteasers.
- spooky_action 1y ago
  How do you propose we do this?
  - udev4096 1y ago
    Look at their code, from projects or any open source contributions. Ask how they intend to write secure code, rather than asking a bunch of useless algorithmic problems
- shakna 1y ago
  When tech reports a library as insecure, but it takes a year to approve removal, much of the difficulty doesn't lie at the coder level of the corporation's infrastructure.
macrocyclo 1y ago
Is there an OS that embodies this sentiment?
- pbohun 1y ago
  9front, the modern fork of Plan 9.
grg0 1y ago
Unfortunately, this is not something that programmers, let alone security ops, can fix. In many companies, the management is too brain-dead to even conceive of the possibility of doing something that does not immediately translate into (short-term) profit. Companies that treat its software as a quality artifact are rare. At best, you have to go out of your way as a programmer to fix shit and maintain even a baseline of quality before shit hits the fan. The only way to get the bulk companies aligned with this goal is to make it so that failure to do so costs them money, AKA fining them for security breaches, accidents, etc.
- chilldsgn 1y ago
  Yup. I've been advocating for leaner software to make maintainability easier, which can help prevent developer burnout (I've been there twice in 365 days). My overall health suffered because of dealing with bloated software. Having burned out employees is a cost implication for any business. I do not have concrete data to back this up, though, but from personal experience, I can attest to this. I had to take sick leave and lose days of productivity due to illness caused by burnout from having to deal with bloated software and the deadlines associated with that. Business makes promises to clients without realising how difficult and time-consuming it is to add features and try to keep software operational and secure can be if it is so bloated and difficult to understand.
  - jffhn 1y ago
    >burnout from having to deal with bloated software and the deadlines associated with that I did not have the deadlines, but to bear having to deal with bloated software, my solution was vodka: since it has no color, I filled mineral water bottles with it and everyone thought I was drinking water.
    - chilldsgn 1y ago
      Hah! Yeah I drank more alcohol that I normally do during this period, however I work from home so I never had to hide it :D
  - 1y ago
al_borland 1y ago
A big issue is the speed at which teams are expected to deliver. If every sprint is expected to deliver value to the user, there is isn’t enough slack in the system to go back and prune the code to remove cruft. People end up cutting corners to meet deadlines set by management. The corners that get cut are the things that are invisible in the demo. Security, documentation, and all the chewing gum holding it all together.
- BLKNSLVR 1y ago
  And once a level of "story points" is achieved within a Sprint you can't go backwards and you can't deliver less value to the Customer. There is no room for re-evaluation. Forwards, moar! As per Tame Impala's Elephant: He pulled the mirrors off his Cadillac Because he doesn't like it looking like he looks back Looking back gives the impression of missteps or regret. We have no such thing!
- chading 1y ago
  Scrum points are about engineering controllability, rather than performance. But that's a complexity most don't get.
  - deleted 1y ago
    [deleted]
  - JackSlateur 1y ago
    Exactly And because it is based on nothing, you can just lie about it
- JackSlateur 1y ago
  This is why cruft removal is linked to the value delivered to the user You do not say : "there is two task: add some feature, takes 1 day, and delete some cruft, takes 1 day". You say: "Yes, that feature. That's one task. It will take 2 days."
BobbyTables2 1y ago
At the library level, I dislike how coarse grained most things are. Sadly becomes easier to reimplement things to avoid huge dependency chains. Want a simple web server ? Well, you’re going to get something with a JSON parser, PAM authentication, SSL, QUIC, websockets, an async framework, database for https auth, etc. Ever look at “curl”? The number protocols is dizzing — one could easily think that HTTP is only a minor feature. At the distro level, it is ridiculous that so long after Alpine Linux, the chasm between them and Debian/RHEL remains. A minimal Linux install shouldn’t be 1GB… We used to boot Linux from a 1.44mb floppy disk. A modern Grub installation would require a sizable stack of floppies! (Grub and Windows 3.0 are similar in size!)
- udev4096 1y ago
  Alpine's biggest hurdle is musl. Most of the software still relies on libc. You should look into unikernels [0], it's the most slimmed down version of linux that you can ship. I am not sure how different a unikernel is from a distroless image tho [0] - https://unikraft.org/ https://unikraft.org/
  - anacrolix 1y ago
    Alpine is not as good as it seems. It's mostly broken it just works when you ask it to run a handful of common tools. Everything out of view is completely broken.
- michaelmrose 1y ago
  >A minimal Linux install shouldn’t be 1GB Why not this seems pretty arbitrary. Seemingly developer time or functionality would suffer to achieve this goal. To what end? Who cares how many floppies grub would require when its actually running on a 2TB ssd. The actually simpler thing is instead of duplicating effort to boot into Linux and use Linux to show the boot menu then kexec into the actual kernal or set it to boot next. See zfsbootmenu and "no more boot loader" this is simpler and less bloated but it doesnt use less space
  - spacerzasp 1y ago
hilbert42 1y ago
This IEEE Spectrum article on software bloat and security provides a good summary of the problems plaguing much software these days but I see no indication that we will find solutions anytime soon. There's just too much invested in the building of software to dismantle current arrangements or change methodologies quickly, it would take years to do so. Commercial interests depend on bloat for income, so do programmers and support industries. For example, take Microsoft Windows, these days it's so huge it will not even fit onto a DVD, that's petty outrageous really. I recall Windows expert Mark Russinovich saying that the core/essential components of Windows only take up about 50MB. But there's no incentive for Microsoft to make Windows smaller and thus have a smaller footprint for hackers to attack. Why? As that bloatware makes Microsoft money! Rather than dispense with all that bloatware Microsoft has build a huge security edifice around it, there are never-ending security updates, secure Windows boot/UEFI, it's even had to resort to a hardware security processor—Pluton. And much of this infrastructure is nothing but a damn nuisance and inconvienience for end users/consumers. Microsoft doesn't just stop there, it then makes matters worse by unnecessarily changing the Windows GUI with every new version. Moreover, it's not alone, every Linux distribution is different. What this means is that there's less time to perfect code as its features keep changing. Now take the huge numbers of programming languages out there. There are so many that many programmers have to learn multiple languages thus cannot become truly proficient in all of them. That lack of expertise alone is problematic. Surely it would be better to concentrate on fewer languages and make those more adaptable. But we know that's not going to happen for all the usual reasons. Same goes for Web browsers and Web bloat. Every time I complain on HN about browser bloat, the abuse of JS by websites and the never-ending number of Web protocols that keep appearing, I'm voted down. That's understandable of course because programmers and others have a financial vested interest in them. Also, programmers have taken much time to learn all this tech and don't want to see their efforts wasted by its obsolescence. And I've not yet mentioned the huge and unnecessary proliferation of video, sound codecs, image and audio formats not to mention the many document formats. Programs that use all these formats are thus bigger and more bloated and more prone to bugs and security vulnerabilities. In a more organized world only faction that number would be necessary. Again, we know it's not just technological improvements that have brought such numbers into existence but also commercial and vested interests. Simply, there's money in introducing this tech even if it's only slightly different to the existing stuff. I've hardly touched this subject and said almost nothing about the economic structure of the industry, but even at first glance it's obvious we can't fix any of this in the near future, except perhaps by tiny incremental steps which will hardly make much impact.
aaron695 1y ago
[dead]
antfarm 1y ago
FWIW, I started learning Elixir and OTP to overcome architectural bloat in future projects. The Erlang ecosystem has many useful abstractions at just about the right level that allow you to build the simplest possible custom solution instead of reaching for a 3rd party solution for a component of your (distributed) system. Building just the right wheel for the task at hand does not mean you have to reinvent it first.
dvh 1y ago
People often think "speed" when they read "bloat". But bloat often means layers upon layers of indirection. You want to change the color of the button in one dialog. You find the dialog code, change the color and nothing. You dig deeper and find that some modules use different colors for common button, so you find the module setting, change the color and nothing. You dig deeper and find that global themes can change colors. You find the global theme, change the color and nothing. You start searching entire codebase and find that over 17 files change the color of that particular button and one of those files does it in a timer loop because your predecessor couldn't find out why the button color changed 16 times on startup so he just constantly change it to brown once a second. That is bloat. Trivial change will take you half a day. And PM is breathing on your neck asking why changing button color takes so long.
- alganet 1y ago
  No. What you described is known as technical debt. Bloat affects the end user, and it's a loose definition. Anything that was planned, went wrong, and affects user experience could be defined as bloat (many toolbars like Office had, many purposes like iTunes had, etc). Bloat and technical debt are related, but not the same. There is a lot of software that has a very clean codebase and bloated experience, and vice-versa. Speed is an ambiguous term. It is often better to think in terms of real performance and user-perceived performance. For example, many Apple UX choices prioritize user perceived performance instead of real performance. Smooth animations to cover up loading times, things such as that. Their own users don't even know why, they often cannot explain why it feels smooth, even experienced tech people. Things that are not performant but appear to be fast are good examples of good user-perceived performance. Things that are performant but appear to be slow exist as well (fast backend lacking proper cache layer, fast responses but throttled by concurrent requests, etc).
  - FirmwareBurner 1y ago
    >many Apple UX choices prioritize user perceived performance instead of real performance. Then why does Apple still ship 60Hz displays in 2025? The perceived performance on scrolling a web page on 60Hz is jarring no matter how performant your SoC is.
kreetx 1y ago
The article makes using dependencies look bad, while the actual issue rather is "quality controlling" the code in dependencies, as dead code elimination (or "tree shaking") removes the bloat from the final artifact. Because dependency as a concept itself is good, because going the opposite way and reinvent the wheel you'll get an even worse kind of bloat - bloat you have to maintain yourself.
- whstl 1y ago
  Nah, I disagree. Dependency as a concept is 100% neutral and contextual, and treating it as 100% positive is cause for several issues in software bloat, security and compatibility. It’s like drugs: if a doctor prescribes, it’s probably ok. If you have an addiction, then you’re in for a lifetime of trouble.
  - kreetx 1y ago
    If the dependency solves a thing you need and isn't part of your core business, it pretty much is 100% positive. E.g, do you really want to implement your own json parser? When will you then ship your actual product?
    - whstl 1y ago
      I'm answering to the claim that "dependency as a concept itself is good". They're not universally good, and have side effects even when they solve the problem at hand. The answer to your questions is already in my reply.
    - k__ 1y ago
      I mean, deps aren't free. You're buying them with the risk that they could become a threat in the future. At one point it's not worth it anymore.
      - kreetx 1y ago
        Sure, nothing is, but where you draw the line? And why would you implement something again when you are unlikely to do it better, or even have time for it? And of course, if you're doing just recreational coding to learn something, or if what you need differs from what is available, or the available thing seems sketchy somehow, then you'd write it yourself (if it's feasible). But for most things where what you need is clear and unambiguous, I don't see why you'd invent it yourself. For an established library it's unlikely that you'd do any better anyway. (And again, if it's recreational what you are doing, you want to learn and have a hobby, of course, do it yourself. But in that case, you aren't actually looking for dependencies anyway - your goal is elsewhere.)
kristianp 1y ago
They talk about the imessage vulnerability (1), but is it really an example of bloat to accidentally allow pdfs to be parsed with an extension of .gif? I guess it's an example of an unnecessary functionality, but Apple would sell a lot less iPhones if they didn't add all these UI gimmicks. (1) https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
- athrowaway3z 1y ago
  While I agree with the overall post, I think the iMessage-preview is a bad example. If they instead had filtered/disabled previews the security problems would still exist - and potentially have less visibility.
bob1029 1y ago
When it comes to building software for money, I prefer to put all of my eggs into one really big basket. The fewer 3rd parties you involve in your product, the more likely you will encounter a comprehensive resolution to whatever vulnerability as soon as a response is mounted. If it takes 40+ vendors to get pixels to your customers eyeballs, the chances of a comprehensive resolution rocket toward zero. If every component is essential, does it matter that we have diversified the vendor base? Break one thing and nothing works. There is no gradient or portfolio of options. It is crystalline in every instance I've ever encountered.
- joseda-hg 1y ago
  So Microsoft's everything and the kitchen sink approach?
dmos62 1y ago
In other news, bad software is bad. Heh, excuse the sarcasm. Tangential: I've come to think of the major software problems (like bloat, or closed-source, or lack of interop) as an effect of our generally chaotic and self-contradictory culture: "money is the root of all evil", "how much do you make", "it has to be good", "it has to be done fast", "do what you think is best", "do what's expected", "be conservative", "be innovative". It's hard to navigate through all that, and if you do, and you have something to show for it, you have my applause, irrespective of how good it is, for whatever problematic definition of good I happen to use today.
smeg_it 1y ago
Interesting! I'm not an expert but an aging amateur and *nix/foss enthusiast. I see some parallels to what I've thought before that may, or may not be erroneous. First, it seems to point toward the original *nix philosophy of do one thing. From a user/fanboy/paranoid point of view, I don't like systemd. I've good development arguments for it's improved coding for usb device drivers. Still, when I have to reboot, because my system is frozen. It's more complex to use than say runit. Lastly, I'm nervous, that if a company took it over, it's the one piece that might help destroy most distros. Please no hate. This is only my personal point of view, as an amateur e.g. there are people on both sides that have a much better understanding of this. Seems to favor the microkernel? I've been hoping we one day get daily driver micro-kernel distro. I asked about this but didn't get a lot of answers, except for those that mentioned projects that aren't there yet e.g. I would love to try Redox, but from my understanding, after 10yrs it's still not there yet. It also brings me to a point that has confused me for years. As, an amateur how to I decide what is better for what level of virtualization from program images like appimage/flatpacks, containers, to VMs. So far, I've hated snaps/flatpacks because, they make a mess of other basic admin commands, and because there seems to be missing functionality. and/or configuration. It may be better now; I haven't tried in a while. Personally, I've enjoyed portage systems in the past, and they are so fast now (to compile). A lot of forums, forget that there are home enthusiast and basically talk about it from an enterprise perspective. Is there a good article or book that might explain when to choose what. Much of what I've read are just "how to" or "how it works". I guess, I would prefer someone who acknowledges we need something for the hardware to run on and when it makes more since to use a regular install vs an image (appimage/flatpack/snap). Anyway, thanks so much for the article. I do believe you are right, a lot of companies just put out fires because none want to invest in the future. I mean even the CEO usually only is there a few years, historically comparatively; so why would they care? Also, I think H1-B is a security risk in and of itself because, at least in TX, most IT is Indian H1-B. I mean they want a better life, and don't have as many family ties here. If they were to "fall into" a large sum...they could live like Kings in India, or elsewhere.
penguin_booze 1y ago
To me, the root cause of this problem is the externalizing of knowledge. The number of tools used in building software has exploded. Each such tool, while purporting to make the job of the developer easy, hides what it really takes to make software. In turn, the developer unwittingly grows reliant on the tools, thereby externalizing the essential knowledge of what it really takes to build software, or what the real cost of adding a dependency is. Everything turns into, "pff, I'll just click that button on my IDE--job done!". Every software component follows the same pattern. Software, thus made from these components, ends up being intractably complex. Nobody knows what a thing is, nor how things work. This is where we are right now, before we add AI. Add AI and "vibe coding" to the mix, and we're in for a treat. But don't worry - there'll be another tool that'll make this problem, too, easy! I'm hereby coining the term 'cognitive sovereignty'.
- kovac 1y ago
  That's a good point. I do see developers overestimating the difficulty when supporting the use a 3rd part lib. I recently came across a library in our code base that's about 200 LOC including comments, line feeds, etc. The library is in C#, a language that takes a fair bit of vertical space due to braces. So, the actual LOCs are just over a 100. I asked the team why can't we write something this simple ourselves. The reality was they didn't know how to, and it isn't a habit to have even a cursory glance at the source of the dependency they were bringing in.
PaulHoule 1y ago
Personally I see Docker as a problem more than a solution. Back when I had slow ADSL (like 2 Mbps) I couldn't use Docker at all at home because the repository server had low timeouts. I was downloading 20GB games with Steam not to mention Freebase data dumps and other things that large because I had reliable tools to do the downloads, which Docker didn't use so downloading 5GB of images was not "wait for it" but rather "you can't do it." By accelerating the rate at which you can attach random dependencies you can run into problems because you are using 6 different versions of libc for Christ's sake. Rather than getting Python from some reputable source like conda or deadsnakes, Docker gives data scientists superpowers to get Pythons with random strange build options and character encodings. A 20 megabyte patch requires 2 GB of disk IO once it goes through the Docker IO multiplier. A 5 minute build becomes a 20 minutes build. Docker is fast from the viewpoint of "ops" but is slow from the viewpoint of "dev"; where people use Docker they are always taking forever to do the simplest things and facing extreme burnout.
- moralestapia 1y ago
  Docker sandboxes execution so it kind of helps as well?
  - PaulHoule 1y ago
    Back in 2004 I was regularly setting up Apache and IIS servers with 80 or more applications running on them simply by being systematic about how they were configured. In 2014 somebody wants to sell it back to me with 10x the disk I/O and a lot more that can go wrong, no thanks! There are some places where people really want to run 8 versions of Java and 3 versions of PHP and think it's going to make them productive that they can write 15 microservices in 15 different languages... It's a delusion. If you get purposeless variation of variances in your system in control you are in control and have a huge competitive advantage over 10x larger teams who use tools that let them barrel on without being in control.
osigurdson 1y ago
Perhaps a better title would be "Supply chain vulnerabilities and attacks are software's biggest vulnerability".
nwlotz 1y ago
I'd expect LLMs to continue making bloat significantly worse. When the cost of a thing craters, in this case generated lines of code, then you'll inevitably get way more of that thing. Also my observations so far of "vibe coding" include a lot of copy and pasting errors that are then fixed with installing yet more libraries until you have a massive, glued-together mess.
ahmedaley 1y ago
So we have been working on a solution to this problem for the past 5 years at university. We have just released one tool for containers (not the full thing for now) and we are about to release our tools for removing bloat in shared libraries. Out paper describing one of these tools won the best paper award at MLSys yesterday! https://mlsys.org/virtual/2025/poster/3238 https://mlsys.org/virtual/2025/poster/3238 If there are any adopted or anyone who would like to try our tools, please reach out! We would love to support you!

260 points by kristianp 1y ago

Yet if you deliver a system without a modern bloated framework or a massive cloud stack and you are "old fashioned" and "out of touch" - been there done that, got the tee-shirt.

al_borland 1y ago
Being mandated to throw away simple and stable code in favor of the “new platform” that changes every 18 months has been one of the most frustrating experiences of my working life and turned me into a bit of a nihilist (in a work context).

jmclnx 1y ago

No argument from me, I also believe bloat is a very large problem. A get of my lawn section :) I remember when GUIs started becoming a thing, I dreaded the move from Text to GUIs due to complexity. I also remember most programs I wrote when I started on minis were 64k code and 64k text. They were rather powerful even by today's standards, they did one thing and people had to learn which one to use to perform a task. Now we have all in one where in some cases you need to page through endless menus or buttons to find an obscure function. In some cases you just give up looking and move on. Progress I guess.

zelphirkalt 1y ago
There is still a fundamental difference between move from text interface to GUI on one hand and adding bloat so many people add these days on the other hand. GUI is some entirely different paradigm of usage, while the bloat of today can often be replaced with little code and one retains the same functionality.
rjsw 1y ago
My first GUI applications used GEM, they were compiled to 8086 small model so the same 64k code and 64k data, didn't get close to running out of address space.

jongjong 1y ago

In my last job, just to run the software on my local machine, I had to launch 6 different microservices running in a containerized, Linux virtualized environment on Windows and had to launch them in a particular order and had to keep each one in a separate console for debugging purposes. It took about 20 minutes to launch the software to be able to test it locally. The launch couldn't be automated easily because each service was using a mix of containers and plain Node.js servers with different versions and it was Windows so I would probably have to write some unfamiliar code for Windows to automate opening all the necessary git bash tabs... The services usually persisted except for automatic updates so I only had to restart all the services a few times per week so it didn't make sense to invest time to automate.

bee_rider 1y ago
I like that they are containerized microservices, but you have to launch them in a particular order. Hahaha. What a nightmare. Congrats on it being a former job. Move on to better things? Well, unemployment would be preferable.
vjvjvjvjghv 1y ago
I had a discussion with team members and we agreed that we will make our next systems fully deployable with one script or installer. It requires a little more thought and discipline but will result in much cleaner architecture and will also document itself this way.
- jongjong 1y ago
  Completely worth it IMO. My philosophy nowadays (on my side projects) is to make every software feel like a complete product that you can run out of the box, batteries included... I also try to support older engine versions to avoid setup issues. If you take care of the developer, the project looks after itself.
n_ary 1y ago
At the risk of sounding very naïve and making huge guesses, what you describe seems to be what docker-compose solves. Special order of services, launching several containers at once. However, I have seen my fair share of oddities in the trenches where containers are evolution of virtual machines(vagrant) running everything in one vm but now split out into containers without adapting to how containers work, because new tech lead thought vms were uncool and everything must be docker now.

GuB-42 1y ago

I am beginning to think that the terrible situation with dependency management in traditional C and C++ is a good thing. Now, with systems like npm, maven or cargo, all you need to do to get a package is to add a line in a configuration file, and it fetches all the dependencies you need automatically from a central repository. Very convenient, however, you can quickly find yourself with 100+ packages from who knows where and 100s of MB of code. In C, traditionally, every library you include requires some consideration. There is no auto-download, and the library the user has may be a different version from the one you worked with, and you have to accommodate it, and so does the library publisher. Or you may have to ship is with your own code. Anyways, it is so messy that the simplest solution is often not to use a library at all and write the thing yourself, or even better, realize that you don't need the feature you would have used that library for. Bad reason, and reinventing the wheel comes with its own set of problems, but at least, the resulting code is of a manageable size.

klysm 1y ago
Unfortunately that comes with the baggage of terrible memory safety. I do agree with the sentiment though, that deps should be taken with more consideration.
- codr7 1y ago
  Given how much critical software is written in C, and the number of problems we run into; I don't see a reason to keep repeating that line outside of the Rust marketing department. Some people will always prefer C to Rust, might as well learn to live with that fact.
  - klysm 1y ago
    I never mentioned rust. I’m just saying C and C++ have terrible memory safety.
    - codr7 1y ago
      And what's the alternative then, from your perspective? What did you have in mind when you wrote the comment?

geodel 1y ago

Considering the disdain for software which does not have a thousand external dependencies in form libraries and framework is it any surprise?

gitroom 1y ago

This hits hard for me because I've run into way too much extra code getting piled on for no real reason. Stuff just gets harder to handle over time and gets in the way. Kinda makes me ask myself- you think folks are just chasing easy installs or is it more about looking busy than keeping things actually simple?

voxelghost 1y ago
Of the three great programmer virtues of Larry Wall, only laziness remains.
- antfarm 1y ago
  For those who, like me, only knew Larry Wall’s quote “Lazyness is a virtue”, here are all three: https://thethreevirtues.com/ https://thethreevirtues.com/

dang 1y ago

Discussed at the time: A 2024 plea for lean software - https://news.ycombinator.com/item?id=39315585 https://news.ycombinator.com/item?id=39315585 - Feb 2024 (240 comments)

ronbenton 1y ago

>Even companies with near-infinite resources (like Apple and Google) made trivial “worst practice” security mistakes that put their customers in danger. Yet we continue to rely on all these products. I am at a big tech company and have seen some wildly insecure code make it into the codebase. I will forever maintain that we should consider checking if candidates actually understand software engineering rather than spending 4 or 5 hours seeing if they can solve brainteasers.

spooky_action 1y ago
How do you propose we do this?
- udev4096 1y ago
  Look at their code, from projects or any open source contributions. Ask how they intend to write secure code, rather than asking a bunch of useless algorithmic problems
shakna 1y ago
When tech reports a library as insecure, but it takes a year to approve removal, much of the difficulty doesn't lie at the coder level of the corporation's infrastructure.

macrocyclo 1y ago

Is there an OS that embodies this sentiment?

pbohun 1y ago
9front, the modern fork of Plan 9.

grg0 1y ago

Unfortunately, this is not something that programmers, let alone security ops, can fix. In many companies, the management is too brain-dead to even conceive of the possibility of doing something that does not immediately translate into (short-term) profit. Companies that treat its software as a quality artifact are rare. At best, you have to go out of your way as a programmer to fix shit and maintain even a baseline of quality before shit hits the fan. The only way to get the bulk companies aligned with this goal is to make it so that failure to do so costs them money, AKA fining them for security breaches, accidents, etc.

chilldsgn 1y ago
Yup. I've been advocating for leaner software to make maintainability easier, which can help prevent developer burnout (I've been there twice in 365 days). My overall health suffered because of dealing with bloated software. Having burned out employees is a cost implication for any business. I do not have concrete data to back this up, though, but from personal experience, I can attest to this. I had to take sick leave and lose days of productivity due to illness caused by burnout from having to deal with bloated software and the deadlines associated with that. Business makes promises to clients without realising how difficult and time-consuming it is to add features and try to keep software operational and secure can be if it is so bloated and difficult to understand.
- jffhn 1y ago
  >burnout from having to deal with bloated software and the deadlines associated with that I did not have the deadlines, but to bear having to deal with bloated software, my solution was vodka: since it has no color, I filled mineral water bottles with it and everyone thought I was drinking water.
  - chilldsgn 1y ago
    Hah! Yeah I drank more alcohol that I normally do during this period, however I work from home so I never had to hide it :D
- 1y ago

al_borland 1y ago

A big issue is the speed at which teams are expected to deliver. If every sprint is expected to deliver value to the user, there is isn’t enough slack in the system to go back and prune the code to remove cruft. People end up cutting corners to meet deadlines set by management. The corners that get cut are the things that are invisible in the demo. Security, documentation, and all the chewing gum holding it all together.

BLKNSLVR 1y ago
And once a level of "story points" is achieved within a Sprint you can't go backwards and you can't deliver less value to the Customer. There is no room for re-evaluation. Forwards, moar! As per Tame Impala's Elephant: He pulled the mirrors off his Cadillac Because he doesn't like it looking like he looks back Looking back gives the impression of missteps or regret. We have no such thing!
chading 1y ago
Scrum points are about engineering controllability, rather than performance. But that's a complexity most don't get.
- deleted 1y ago
  [deleted]
- JackSlateur 1y ago
  Exactly And because it is based on nothing, you can just lie about it
JackSlateur 1y ago
This is why cruft removal is linked to the value delivered to the user You do not say : "there is two task: add some feature, takes 1 day, and delete some cruft, takes 1 day". You say: "Yes, that feature. That's one task. It will take 2 days."

BobbyTables2 1y ago

At the library level, I dislike how coarse grained most things are. Sadly becomes easier to reimplement things to avoid huge dependency chains. Want a simple web server ? Well, you’re going to get something with a JSON parser, PAM authentication, SSL, QUIC, websockets, an async framework, database for https auth, etc. Ever look at “curl”? The number protocols is dizzing — one could easily think that HTTP is only a minor feature. At the distro level, it is ridiculous that so long after Alpine Linux, the chasm between them and Debian/RHEL remains. A minimal Linux install shouldn’t be 1GB… We used to boot Linux from a 1.44mb floppy disk. A modern Grub installation would require a sizable stack of floppies! (Grub and Windows 3.0 are similar in size!)

udev4096 1y ago
Alpine's biggest hurdle is musl. Most of the software still relies on libc. You should look into unikernels [0], it's the most slimmed down version of linux that you can ship. I am not sure how different a unikernel is from a distroless image tho [0] - https://unikraft.org/ https://unikraft.org/
- anacrolix 1y ago
  Alpine is not as good as it seems. It's mostly broken it just works when you ask it to run a handful of common tools. Everything out of view is completely broken.
michaelmrose 1y ago
>A minimal Linux install shouldn’t be 1GB Why not this seems pretty arbitrary. Seemingly developer time or functionality would suffer to achieve this goal. To what end? Who cares how many floppies grub would require when its actually running on a 2TB ssd. The actually simpler thing is instead of duplicating effort to boot into Linux and use Linux to show the boot menu then kexec into the actual kernal or set it to boot next. See zfsbootmenu and "no more boot loader" this is simpler and less bloated but it doesnt use less space
- spacerzasp 1y ago

hilbert42 1y ago

This IEEE Spectrum article on software bloat and security provides a good summary of the problems plaguing much software these days but I see no indication that we will find solutions anytime soon. There's just too much invested in the building of software to dismantle current arrangements or change methodologies quickly, it would take years to do so. Commercial interests depend on bloat for income, so do programmers and support industries. For example, take Microsoft Windows, these days it's so huge it will not even fit onto a DVD, that's petty outrageous really. I recall Windows expert Mark Russinovich saying that the core/essential components of Windows only take up about 50MB. But there's no incentive for Microsoft to make Windows smaller and thus have a smaller footprint for hackers to attack. Why? As that bloatware makes Microsoft money! Rather than dispense with all that bloatware Microsoft has build a huge security edifice around it, there are never-ending security updates, secure Windows boot/UEFI, it's even had to resort to a hardware security processor—Pluton. And much of this infrastructure is nothing but a damn nuisance and inconvienience for end users/consumers. Microsoft doesn't just stop there, it then makes matters worse by unnecessarily changing the Windows GUI with every new version. Moreover, it's not alone, every Linux distribution is different. What this means is that there's less time to perfect code as its features keep changing. Now take the huge numbers of programming languages out there. There are so many that many programmers have to learn multiple languages thus cannot become truly proficient in all of them. That lack of expertise alone is problematic. Surely it would be better to concentrate on fewer languages and make those more adaptable. But we know that's not going to happen for all the usual reasons. Same goes for Web browsers and Web bloat. Every time I complain on HN about browser bloat, the abuse of JS by websites and the never-ending number of Web protocols that keep appearing, I'm voted down. That's understandable of course because programmers and others have a financial vested interest in them. Also, programmers have taken much time to learn all this tech and don't want to see their efforts wasted by its obsolescence. And I've not yet mentioned the huge and unnecessary proliferation of video, sound codecs, image and audio formats not to mention the many document formats. Programs that use all these formats are thus bigger and more bloated and more prone to bugs and security vulnerabilities. In a more organized world only faction that number would be necessary. Again, we know it's not just technological improvements that have brought such numbers into existence but also commercial and vested interests. Simply, there's money in introducing this tech even if it's only slightly different to the existing stuff. I've hardly touched this subject and said almost nothing about the economic structure of the industry, but even at first glance it's obvious we can't fix any of this in the near future, except perhaps by tiny incremental steps which will hardly make much impact.

aaron695 1y ago

[dead]

antfarm 1y ago

FWIW, I started learning Elixir and OTP to overcome architectural bloat in future projects. The Erlang ecosystem has many useful abstractions at just about the right level that allow you to build the simplest possible custom solution instead of reaching for a 3rd party solution for a component of your (distributed) system. Building just the right wheel for the task at hand does not mean you have to reinvent it first.

dvh 1y ago

People often think "speed" when they read "bloat". But bloat often means layers upon layers of indirection. You want to change the color of the button in one dialog. You find the dialog code, change the color and nothing. You dig deeper and find that some modules use different colors for common button, so you find the module setting, change the color and nothing. You dig deeper and find that global themes can change colors. You find the global theme, change the color and nothing. You start searching entire codebase and find that over 17 files change the color of that particular button and one of those files does it in a timer loop because your predecessor couldn't find out why the button color changed 16 times on startup so he just constantly change it to brown once a second. That is bloat. Trivial change will take you half a day. And PM is breathing on your neck asking why changing button color takes so long.

alganet 1y ago
No. What you described is known as technical debt. Bloat affects the end user, and it's a loose definition. Anything that was planned, went wrong, and affects user experience could be defined as bloat (many toolbars like Office had, many purposes like iTunes had, etc). Bloat and technical debt are related, but not the same. There is a lot of software that has a very clean codebase and bloated experience, and vice-versa. Speed is an ambiguous term. It is often better to think in terms of real performance and user-perceived performance. For example, many Apple UX choices prioritize user perceived performance instead of real performance. Smooth animations to cover up loading times, things such as that. Their own users don't even know why, they often cannot explain why it feels smooth, even experienced tech people. Things that are not performant but appear to be fast are good examples of good user-perceived performance. Things that are performant but appear to be slow exist as well (fast backend lacking proper cache layer, fast responses but throttled by concurrent requests, etc).
- FirmwareBurner 1y ago
  >many Apple UX choices prioritize user perceived performance instead of real performance. Then why does Apple still ship 60Hz displays in 2025? The perceived performance on scrolling a web page on 60Hz is jarring no matter how performant your SoC is.

kreetx 1y ago

The article makes using dependencies look bad, while the actual issue rather is "quality controlling" the code in dependencies, as dead code elimination (or "tree shaking") removes the bloat from the final artifact. Because dependency as a concept itself is good, because going the opposite way and reinvent the wheel you'll get an even worse kind of bloat - bloat you have to maintain yourself.

whstl 1y ago
Nah, I disagree. Dependency as a concept is 100% neutral and contextual, and treating it as 100% positive is cause for several issues in software bloat, security and compatibility. It’s like drugs: if a doctor prescribes, it’s probably ok. If you have an addiction, then you’re in for a lifetime of trouble.
- kreetx 1y ago
  If the dependency solves a thing you need and isn't part of your core business, it pretty much is 100% positive. E.g, do you really want to implement your own json parser? When will you then ship your actual product?
  - whstl 1y ago
    I'm answering to the claim that "dependency as a concept itself is good". They're not universally good, and have side effects even when they solve the problem at hand. The answer to your questions is already in my reply.
  - k__ 1y ago
    I mean, deps aren't free. You're buying them with the risk that they could become a threat in the future. At one point it's not worth it anymore.
    - kreetx 1y ago
      Sure, nothing is, but where you draw the line? And why would you implement something again when you are unlikely to do it better, or even have time for it? And of course, if you're doing just recreational coding to learn something, or if what you need differs from what is available, or the available thing seems sketchy somehow, then you'd write it yourself (if it's feasible). But for most things where what you need is clear and unambiguous, I don't see why you'd invent it yourself. For an established library it's unlikely that you'd do any better anyway. (And again, if it's recreational what you are doing, you want to learn and have a hobby, of course, do it yourself. But in that case, you aren't actually looking for dependencies anyway - your goal is elsewhere.)

kristianp 1y ago

They talk about the imessage vulnerability (1), but is it really an example of bloat to accidentally allow pdfs to be parsed with an extension of .gif? I guess it's an example of an unnecessary functionality, but Apple would sell a lot less iPhones if they didn't add all these UI gimmicks. (1) https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

athrowaway3z 1y ago
While I agree with the overall post, I think the iMessage-preview is a bad example. If they instead had filtered/disabled previews the security problems would still exist - and potentially have less visibility.

bob1029 1y ago

When it comes to building software for money, I prefer to put all of my eggs into one really big basket. The fewer 3rd parties you involve in your product, the more likely you will encounter a comprehensive resolution to whatever vulnerability as soon as a response is mounted. If it takes 40+ vendors to get pixels to your customers eyeballs, the chances of a comprehensive resolution rocket toward zero. If every component is essential, does it matter that we have diversified the vendor base? Break one thing and nothing works. There is no gradient or portfolio of options. It is crystalline in every instance I've ever encountered.

joseda-hg 1y ago
So Microsoft's everything and the kitchen sink approach?

dmos62 1y ago

In other news, bad software is bad. Heh, excuse the sarcasm. Tangential: I've come to think of the major software problems (like bloat, or closed-source, or lack of interop) as an effect of our generally chaotic and self-contradictory culture: "money is the root of all evil", "how much do you make", "it has to be good", "it has to be done fast", "do what you think is best", "do what's expected", "be conservative", "be innovative". It's hard to navigate through all that, and if you do, and you have something to show for it, you have my applause, irrespective of how good it is, for whatever problematic definition of good I happen to use today.

smeg_it 1y ago

Interesting! I'm not an expert but an aging amateur and *nix/foss enthusiast. I see some parallels to what I've thought before that may, or may not be erroneous. First, it seems to point toward the original *nix philosophy of do one thing. From a user/fanboy/paranoid point of view, I don't like systemd. I've good development arguments for it's improved coding for usb device drivers. Still, when I have to reboot, because my system is frozen. It's more complex to use than say runit. Lastly, I'm nervous, that if a company took it over, it's the one piece that might help destroy most distros. Please no hate. This is only my personal point of view, as an amateur e.g. there are people on both sides that have a much better understanding of this. Seems to favor the microkernel? I've been hoping we one day get daily driver micro-kernel distro. I asked about this but didn't get a lot of answers, except for those that mentioned projects that aren't there yet e.g. I would love to try Redox, but from my understanding, after 10yrs it's still not there yet. It also brings me to a point that has confused me for years. As, an amateur how to I decide what is better for what level of virtualization from program images like appimage/flatpacks, containers, to VMs. So far, I've hated snaps/flatpacks because, they make a mess of other basic admin commands, and because there seems to be missing functionality. and/or configuration. It may be better now; I haven't tried in a while. Personally, I've enjoyed portage systems in the past, and they are so fast now (to compile). A lot of forums, forget that there are home enthusiast and basically talk about it from an enterprise perspective. Is there a good article or book that might explain when to choose what. Much of what I've read are just "how to" or "how it works". I guess, I would prefer someone who acknowledges we need something for the hardware to run on and when it makes more since to use a regular install vs an image (appimage/flatpack/snap). Anyway, thanks so much for the article. I do believe you are right, a lot of companies just put out fires because none want to invest in the future. I mean even the CEO usually only is there a few years, historically comparatively; so why would they care? Also, I think H1-B is a security risk in and of itself because, at least in TX, most IT is Indian H1-B. I mean they want a better life, and don't have as many family ties here. If they were to "fall into" a large sum...they could live like Kings in India, or elsewhere.

penguin_booze 1y ago

To me, the root cause of this problem is the externalizing of knowledge. The number of tools used in building software has exploded. Each such tool, while purporting to make the job of the developer easy, hides what it really takes to make software. In turn, the developer unwittingly grows reliant on the tools, thereby externalizing the essential knowledge of what it really takes to build software, or what the real cost of adding a dependency is. Everything turns into, "pff, I'll just click that button on my IDE--job done!". Every software component follows the same pattern. Software, thus made from these components, ends up being intractably complex. Nobody knows what a thing is, nor how things work. This is where we are right now, before we add AI. Add AI and "vibe coding" to the mix, and we're in for a treat. But don't worry - there'll be another tool that'll make this problem, too, easy! I'm hereby coining the term 'cognitive sovereignty'.

kovac 1y ago
That's a good point. I do see developers overestimating the difficulty when supporting the use a 3rd part lib. I recently came across a library in our code base that's about 200 LOC including comments, line feeds, etc. The library is in C#, a language that takes a fair bit of vertical space due to braces. So, the actual LOCs are just over a 100. I asked the team why can't we write something this simple ourselves. The reality was they didn't know how to, and it isn't a habit to have even a cursory glance at the source of the dependency they were bringing in.

PaulHoule 1y ago

Personally I see Docker as a problem more than a solution. Back when I had slow ADSL (like 2 Mbps) I couldn't use Docker at all at home because the repository server had low timeouts. I was downloading 20GB games with Steam not to mention Freebase data dumps and other things that large because I had reliable tools to do the downloads, which Docker didn't use so downloading 5GB of images was not "wait for it" but rather "you can't do it." By accelerating the rate at which you can attach random dependencies you can run into problems because you are using 6 different versions of libc for Christ's sake. Rather than getting Python from some reputable source like conda or deadsnakes, Docker gives data scientists superpowers to get Pythons with random strange build options and character encodings. A 20 megabyte patch requires 2 GB of disk IO once it goes through the Docker IO multiplier. A 5 minute build becomes a 20 minutes build. Docker is fast from the viewpoint of "ops" but is slow from the viewpoint of "dev"; where people use Docker they are always taking forever to do the simplest things and facing extreme burnout.

moralestapia 1y ago
Docker sandboxes execution so it kind of helps as well?
- PaulHoule 1y ago
  Back in 2004 I was regularly setting up Apache and IIS servers with 80 or more applications running on them simply by being systematic about how they were configured. In 2014 somebody wants to sell it back to me with 10x the disk I/O and a lot more that can go wrong, no thanks! There are some places where people really want to run 8 versions of Java and 3 versions of PHP and think it's going to make them productive that they can write 15 microservices in 15 different languages... It's a delusion. If you get purposeless variation of variances in your system in control you are in control and have a huge competitive advantage over 10x larger teams who use tools that let them barrel on without being in control.

osigurdson 1y ago

Perhaps a better title would be "Supply chain vulnerabilities and attacks are software's biggest vulnerability".

nwlotz 1y ago

I'd expect LLMs to continue making bloat significantly worse. When the cost of a thing craters, in this case generated lines of code, then you'll inevitably get way more of that thing. Also my observations so far of "vibe coding" include a lot of copy and pasting errors that are then fixed with installing yet more libraries until you have a massive, glued-together mess.

ahmedaley 1y ago

So we have been working on a solution to this problem for the past 5 years at university. We have just released one tool for containers (not the full thing for now) and we are about to release our tools for removing bloat in shared libraries. Out paper describing one of these tools won the best paper award at MLSys yesterday! https://mlsys.org/virtual/2025/poster/3238 https://mlsys.org/virtual/2025/poster/3238 If there are any adopted or anyone who would like to try our tools, please reach out! We would love to support you!