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.
I thought about this several years ago and I think I hit the right balance with these 2 rules of thumb:
* The closer something is to your core business, the less you externalize.
* You always externalize security (unless security is your exclusive core business)
Say you are building a tax calculation web app. You use dependencies for things like the css generation or database access. You do not rely on an external library for tax calculation. You maintain your own code. You might use an external library for handling currencies properly, because it's a tricky math problem. But you may want to use your own fork instead, as it is close to your core business.
On the security side, unless that's your speciality, there's guys out there smarter than you and/or who have dedicated more time and resources than you to figure that stuff out. If you are programming a tax calculation web app you shouldn't be implementing your own authentication algorithm, even if having your tax information secure is one of your core needs. The exception to this is that your core business is literally implementing authentication and nothing else.
I feel like "shouldn't be implementing your own authentication" is overblown. Don't write the crypto algorithms. But how hard is it to write your own auth? If you are pulling in a third party dependency for that you still would need to audit it, and if you can audit authentication software why can't you implement it?
Just follow OWASP recommendations. A while back this was posted to HN and it also provides great recommendations: https://thecopenhagenbook.com/ .
The main challenge isn't necessarily implementing the algorithms, it is keeping up with the security space
Do you expect your team to be keeping up with new exploits in hardware and networking that might compromise your auth? That takes a lot of expertise and time, which they could instead be spending building features that add business value
It sounds cynical, and it kind of is, but offloading this onto external experts makes way more business sense and probably is what allows you to deliver at all. Security is just too big a space for every software company to have experts on staff to handle
The thing is, your "roll your own" auth is likely way smaller and less targeted than the library everyone uses. So the new exploits may simply not apply to your case.
Many famous vulnerabilities happen in parts of software people don't actually use. For example, the "Heartbleed" vulnerability in OpenSSL targeted the "heartbeat" feature few people actually used. In the "Log4Shell" vulnerability the exploit targeted LDAP support in log4j, which I have never seen used and didn't even know existed.
In addition, the "experts" maybe aren't. You may think that whoever is writing that popular library has a team of experts in security, it is used by big, serious companies after all. But in reality it may just be one overworked guy, and people only notice when the system has been publicly compromised. And that's if the developers themselves don't have malicious intent, or have accepted someone with malicious intent in the team (for the latter, see the xz story).
What's missed in me saying roll your own auth, even though I did say it, is that you aren't implementing the network stack or crypto. As long as you keep your dependencies up to date you shouldn't have any increased risk over using a third party library.
If there is a novel security flaw discovered, consider the first SQL-injection or XSS attack, then you definitely should know about it. The idea that not rolling your own security related functionality absolves you from the responsibility to know or understand major security considerations is incorrect. It is the responsibility of every programmer to be knowledgeable of the security risks in their space and the patterns that protect against those risks.
There have been major F-ups in recent history with Okta, CrowdStrike, and so on. Keycloak had some major long-standing vulnerabilities. I've had PRs accepted in popular open-source IAM libraries a bit too easily.
Yeah, we shouldn't roll our own cryptography, but security isn't as clean cut as this comment implies. It also frequently bleeds into your business logic.
Don't confuse externalizing security with externalizing liability.
As far as I know tacking on security after the fact usually leads to issues.
It should be a primary concern from the beginning. Even if you don't do it 100% right, you'd be surprised how many issues you can avoid by thinking about this during (and not after) development.
Dropping your rights to open files as soon as possible, for example, or thinking about what information would be available to an attacker should they get RCE on the process.
Shoehorning in solutions to these things after the fact tends to be so difficult that it's a rare sight.
I have been recommended to think of security as a process rather than an achievable state and have become quite fond of that perspective.
I think this helps, but I also think the default for any dev (particularly library authors) should be to minimize dependencies as much as possible. Dependencies have both a maintenance and a security cost. Bad libraries have deep and sprawling trees.
I've seen devs pull in frameworks just to get access to single simple to write functions.
Even if you make the obviously wrong assumption that every library is more secure than the one you would write (that will do less the vast majority of the time) We still end up in a eggs in one basket situation.
You haven't thought through any cyber security games or you are funded to post this bad argument over and over again by state agencies with large 0-day stockpiles.
I would like to dig into point 2 a bit. Do you think this is a matter of degree, or of kind? Does security, in this, imply a network connection, or some other way that exposes your application to vulnerabilities, or is it something else? Are there any other categories that you would treat in a similar way as security, but to a lesser degree, or that almost meet that threshold for a special category, but don't?
How many vulnerabilities were due to badly reinventing the wheel in C/C++ though?
Also, people often complain about "bloat", but don't realize that C/C++ are often the most bloated ones precisely because importing libraries is a pain, so they try to include everything in a single library, even though you only need to use less than 10% of it. Look for example at Qt, it is supposed to be a UI framework but it ends up implementing vectors, strings, json parser and who knows how much more stuff. But it's just 1 dependency so it's fine, right?
>> Look for example at Qt, it is supposed to be a UI framework but it ends up implementing vectors, strings, json parser and who knows how much more stuff. But it's just 1 dependency so it's fine, right?
Qt is an application development framework, not a GUI toolkit. This is one reason I prefer GTK (there are things I dislike about it too).
I remember back in the early 2000's that discussion, but now with the the tonnage that systems like npm can pull in I laugh that we ever thought it wouldn't get worse.
There is still an advantage to using Qt over dozens of libraries that offer the same functionality.
Qt is backed by a single company, so all you have to watch out for is that company. Also, Qt is generally high quality, I have worked with it, read the source code, etc... and I generally liked what I saw. So I can reasonably assume that quality is consistent overall. When you have many libraries from many independent developers, it doesn't work. The JSON parser may be good, but it doesn't tell me anything about the library that deal with internationalization for instance, and if I wanted to keep track of everything, that's several time the work compared to a single vendor.
I agree that Qt is bloated though, but multiplatform UI frameworks are hard to keep light. There is a lot going on in a desktop UIs that people only notice when it isn't there. I tend to treat them like I treat the standard libraries, the OS, and for web apps, the browser. Big components, but you reasonably can't do without.
In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being included into new projects sooner or later (and everyone and their dog has their own bespoke string handling libraries). Copy/pasting large chunks of code from elsewhere is also rampant.
I'm not so sure C/C++ solves the actual problem. Only sweeps it under a carpet so it's much less visible.
This runs the risk of shipping C/C++ libraries with known vulnerabilities. How do you keep track of that? At least with npm / cargo / etc, updating dependencies is a single command away.
> every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc
You are right. But my conclusion is different.
If it is a stable and people have been there for a while then developers know that code as well as the rest. So, when something fails they know how to fix it.
Bringing generic libraries may create long callstacks of very generic code (usually templates) that is very difficult to debug while adding a lot of functionality that is never used.
Bringing a new library into the code base need to be a though decision.
> In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being included into new projects sooner or later
Same here. And a lot of those homegrown functions, utilities and classes are actually already available, and better implemented, in the C++ Standard Library. Every C++ place I've worked had its own homegrown String class, and it was always, ALWAYS worse in all ways than std::string. Maddening. And you could never make a good business case to switch over to sanity. The homegrown functions had tendrils everywhere and many homegrown classes relied on each other, so your refactor would end up touching every file in the source tree. Nobody is going to approve that risky project. Once you start down the path of rolling your own standard library stuff, the cancer spreads through your whole codebase and becomes permanent.
Although I like std::string for somethings becomes a little tricky with cross platform work that involves both linux and windows. It also can be tricky with unicode and lengths.
This is something that I think about constantly and I have come to the same conclusion. While the idea of being able to trivially share code worldwide is appealing, so far it seems to encourage shittier software more than anything else, and the benefit of sharing trivially seems to be defeated by the downsides that bloat and bad software bring with it. Adding friction to code re-use (by means of having to manually download shit from a website and compile it yourself like it's 1995) seems to be a good thing for now until a better package management system is figured out. The friction forces you to think seriously where you actually need that shit or you can write the subset of the functionality you need yourself. To be clear, I also think C++ projects suffer a lot from re-inventing the wheel, particularly in the gamedev world, but that seems to be less worse than, e.g., initializing some nodejs framework project and starting with 100+ dependencies when you haven't even started to write shit.
When doing SBOM/SCA we see apps with 1000+ deps. It's insane. It's so often we see large packages pulled in because a single function/behavior is needed and ends up massively increasing the risk profile.
> Npm/node_modules is typically one of the worst offenders, but programmers can do this with any import/library based system.
You can, but I think this thread speaks volumes about the problem with the JavaScript/NPM ecosystem as a whole vs. pretty much any other.
We need something else for the web. The only reason we have 200+ NPM packages for a blank project is because JavaScript is atrocious and has almost nothing built-in. We got crap like LeftPad, isodd, is-array, etc. because of the language. Most of what NPM will pull in on any new web front end project is likely already part of the standard library in C#/dotnet, or Java, Go, etc.
But you could go further back and say it's not javascript's fault, it's the fault of trying to hammer the web into doing things it was never designed to do in the first place. But, we insisted on making it an application delivery platform, and now we're suffering the consequences of that. I'm hopeful for WASM, but ideally I'd love to see a resurgence of native apps.
And they're opaque. You have to mitm proxy to even see if they're making requests to who knows where. They run with too many privileges. You can't block ads. You can't link to them.
Meanwhile, the web runs in a web browser. You have a network bar. You can inspect element. You can inject Javascript. You can run your own code inside people's apps.
The former scenario isn't better than the latter scenario just because some people build their website with too many NPM dependencies.
I take your point, but a lot of that needn't be the case. Native apps can have lesser privileges with sandboxing, you can inject code if your OS doesn't forbid it, etc. A lot of this is just in how many of are native apps are, not how they must be.
True. But one of the biggest wins of the web is that it's how things are, and it was only a historical fluke of luck that things panned out this way.
As it's often said, there's no way the concept of a web browser would be feasible in today's walled garden app store norms. You mean a god app than can run remote, arbitrary code? And it lets you sideload arbitrary extensions that can do things like block ads and mutate apps?
The only reason it's allowed is because the web was ubiquitous by the time computing became so highly controlled.
So we shouldn't be quick to dismiss it, despite its warts.
> While the idea of being able to trivially share code worldwide is appealing, so far it seems to encourage shittier software more than anything else, and the benefit of sharing trivially seems to be defeated by the downsides that bloat and bad software bring with it.
A lot of projects would simply not exist without it. Linux, comes to mind. I guess one might take the position that "Windows is fine" but would there ever have been even competition for Windows?
Another example, everyone would be rolling their own crypto without openssl, and that would mean software that's yet a lot more insecure than what we have. Writing software with any cryptography functionality in mind would be the privilege of giant companies only (and still suck a lot more than what we have).
There's a lot more things. The internet and software in general would be set back ~20years. Even with all the nostalgia I can muster, that seems like a much worse situation than today.
All those projects existed long before package managers in programming languages were a thing (although you could consider the distro's package manager to fulfill that purpose, I guess), so I don't think your point really takes away from mine. And for sure, there are critical dependencies like openssl that better be a shared endeavour. But whether you pull those dependencies in manually or through a package manager is somewhat tangential.
This is all heuristic (read "guessing") and not a real solution to the problem.
The ground truth is that software bloat isn't bad enough of a problem for software developers to try and fight it. We already know how to prevent this, if really want to. And if the problem was really hurting so much, we'd have automated ways of slimming down the executables / libraries.
In my role in creating CI for Python libraries, I did more hands-on dependency management. My approach was to first install libraries with pip, see what was installed, research why particular dependencies have been pulled in, then, if necessary, modify the packages in such a way that unnecessary dependencies would've been removed, and "vendor" the third party code (i.e. store it in my repository, at the version I need). This, obviously, works better for programs, where you typically end up distributing the program with its dependencies anyways. Less so for libraries, but in the context of CI this saved some long minutes of reinstalling dependencies afresh for every CI run.
In the end, it was a much better experience than what you usually get with CI targeting Pyhon. But, in the end, nobody really cared. If CI took less than a minute to complete instead of twenty minutes, very little was actually gained. The project didn't have enough CI traffic for this to have any actual effect. So, it was a nice proof of concept, but ended up being not all that useful.
The reason bloat doesn't get fixed is that it's a problem that doesn't really harm software developers. It is a negative externality whose pain is spread uniformly across users. Every little dependency developers add to make their work more convenient might increase the download size over the user's network by 100MB, or use another 0.5% of the user's CPU, or another 50MB of the user's RAM. The user gets hit, ever so slightly, but the developer sees only upside.
There is. Linux distributions have package managers whose entire purpose is to distribute and manage applications and their dependencies.
The key difference between Linux distribution package managers and programming language package managers is the presence of maintainers. Any random person can push packages to the likes of npm or PyPI. To push packages to Debian or Arch Linux, you must be known and trusted.
Programming language package managers are made for developers who love the convenience of pushing their projects to the world whenever they want. Linux distribution package managers are made for users who prefer to trust the maintainers not to let malware into the repositories.
Some measured amount of elitism can be a force for good.
Writing everything from scratch by hand is an insane take. It is not just reinventing the wheel but there are whole frameworks one should use because writing that thing on your own will take you a lifetime.
Yes you should not just pull as dependency thing that kid in his parents basement wrote for fun or to get OSS maintainer on his CV.
But there are tons of legitimate libraries and frameworks from people who are better than you at that specific domain.
Here's a scenario. You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB.
Worse, you pull in different libraries and they all pull in different versions of their own dependencies, with lots of duplication of similar but slightly different code. Node_modules usually ends up like this.
The point is not writing the resize code yourself. It's the cultural effect of friction. If pulling in the resize library means you need to chase down the dependencies yourself, first, you're more aware of the cost, and second, the library author will probably give you knobs to eliminate dependencies. Perhaps you only pull in a JPEG decoder because that's all you need, and you exclude the metadata functionality.
It's an example, but can you see how adding friction to pulling in every extra transitive dependency would have the effect of librabry authors giving engineers options to prune the dependency tree? The easier a library is to use, the more popular it will be, and a library that has you chasing dependencies won't be easy to use.
> You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB.
This is more likely to happen in C++, where any library that isn't header-only is forced to be an all encompassing framework, precisely because of all that packaging friction. In an ecosystem with decent package management your image resizing library will have a core library and then extensions for each image format, and you can pull in only the ones you actually need, because it didn't cost them anything to split up their library into 30 tiny pieces.
Actually I think a big part of the problem in C++ is the low level of abstraction of the standard library. It isn't friction that might cause an image resizing library to be all-encompassing; it's the lack of an abstract Image class in the standard library which would enable a resizing library to live side by side with image encoders and decoders, instead of needing to bundle them together.
The C++ standard library isn't rich enough. It doesn't have enough concepts for a good ecosystem of smaller components.
> The easier a library is to use, the more popular it will be
You're thinking correctly on principle, but I think this is also the cause of the issue: it's too easy to pull in a Node dependency even thoughtlessly, so it's become popular.
It would require adding friction to move back from that and render it less easy, which would probably give rise to a new, easy and frictionless solution that ends up in the same place.
There's a difference between "I need to connect to the database and I need to parse json, so I need two commonly used libs for those two things" and whatever npm is doing, and to some extent cargo or popular java frameworks are doing.
Building everything from scratch is insane, but so's uncritically growing a dependency jungle
... 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 ... the resulting code is of a manageable size..
I don't see the nuance there, that is my take of the comment, those are pretty much strongest statements and points about using libraries are minimal.
That is why I added mine strongly pointing that real world systems are not going to be "managable size" unless they are really small or a single person is working on the.
For me "realize that you don't need the feature" is strong and also hits home. I sometimes prototype in C because it makes me think really hard about "what does this thing really have to do? What can I omit for now?"
While in for instance C# I tend to think "this would be simple to implement with whatever-fancy-thing-is-just-a-package-away".
Neither way is impossible to judge as good or bad on its own.
A real world system is almost always part of a larger system or system of systems. Making one thing simple can make another complex. The world is messy.
When you "Reinvent the wheel", you implement only what you need in an optimized way.
This gives a couple of advantages: you own your code, no bloat, usually simpler due to not having all the bells and whistles, less abstraction, so faster because there is no free lunch, minimize the attack surface for supply chain attacks...
For fun, the next time you are tempted to install a BlaZiNg FaSt MaDe in RuSt software: get the source, install cargo audit and run the cargo audit on that project.
See how many vulnerabilities there are. So far, in my experience, all the software I checked come with their list of vulnerabilities from transitive dependencies.
I don't know about npm, I only know by reputation and it's enough for me to avoid.
That wheel is only as good as your skill in making it. For many people (the majority i'd guess) someone else making that wheel will have a better end result.
The skill is produced by carving the wheel. You've got to start somewhere. Whether a mess or not the returned product is a product of your own. By relying on dependencies you're forever reaching for a goal you'll never achieve.
There are no absolute good or bad reasons here, it depends on the problem domain and usage environment. If you're writing code where safety or security matters then of course you need to carefully manage the software supply chain. On the other hand, if you're writing an internal utility for limited use with no exposure then who cares, pull in all the dependencies you need and git 'er done.
Tree-shaking is able to remove code that will never be called. And it's not necessarily good at it: we can detect some situations where a function is never called, and remove that function, but it's mostly the obvious situations such as "this function is never referenced".
It cannot detect a case such as: if the string argument to this function contains a substring shaped like XYZ, then replace that substring with a value from the environment variables (the Log4j vulnerability), or from the file system (the XML Entity Extension vulnerability). From the point of view of tree-shaking, this is legitimate code that could be called. This is the kind of vulnerable bloat that comes with importing large libraries (large in the sense of "has many complex features", rather than of megabytes).
1. Write everything yourself, time consuming and hard, less likely to lead to these types of vulnerabilities.
2. Import others code, easy and takes no time, can lead to vulnerabilities.
3. Use others code, but only what you actually need. Maybe less time consuming than 1 but more than 2, adds a different sort of complexity, done correctly less likely to lead to these vulnerabilities.
I would say 4. grab individual code files (as opposed to entire libraries) and manually edit them, removing unnecessary features and adding new ones where needed.
Yeah everybody should reimplement their own security for example, that's a really smart fool-proof approach especially down the line, no real cases for any contrarian opinions.
I do get what you mean, but it works only on some very specific types of projects, when you & potentially comparably (very) good & skilled peers are maintaining and evolving it long term. This was never the case in my 20 years of dev career.
This sort of shared well tested libraries -> gradually dependency hell is in some form shared across all similar languages since its pretty basic use case of software development as an engineering discipline. I haven't seen a good silver bullet so far, and ie past 14 years of my work wouldn't be possible with approach you describe.
Within reason, we need to be able to promote third party libraries into the standard library.
A small standard library pairs well with an easy mechanism to download code, but at some point it's probably a crutch. There are maybe 5 functions in lodash at this point that show up routinely in production code but cannot be sufficed by existing editions to EcmaScript - sortBy, recursive get, and recursive merges being among the most useful. We could just have these and be done.
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.
> Unfortunately that comes with the baggage of terrible memory safety.
Isn't this unrelated to the parent post's thoughts about the benefit's of the C/C++ ecosystem (or lack thereof) for dependency management? I.e., a Rust-like language could still exist with a dependency management system similar to what C/C++ have now -- that isn't predicated on how the language handles memory.
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.
Remember how cloudflare (in 2017) leaked pretty much everyone's secret tokens in search engine cache due to a simple buffer overflow? Yeah, that wouldn't have happened with Rust
This just isn't true. A segfault happens when an access happens outside of the memory space of the process, such as a 0x00 pointer. Pages are typically allocated in 4kB chunks and allocators will try to minimize syscalls to allocate more virtual pages by trying to maximize reuse of existing pages. All of this results in an out of bounds access being trivial and hard to detect without additional code to check: https://paste.sr.ht/~chiefnoah/be5864cb0d78d6691fe3e36946709...
A runaway loop can access program memory until it segfaults pretty easily.
Remember that the most expensive exploit the world has ever seen was in a memory safe GC language?
My argument is that you are missing the point: the point is that a larger attack surface enables more exploits regardless of language.
When using a language that has tremendous friction in expanding the attack surface you tend to have a small attack surface as a result.
Theres obviously a crossover point where you'd be safer with a memory safe language and a larger attack surface than with a memory unsafe language and a minuscule attack surface.
> Remember that the most expensive exploit the world has ever seen was in a memory safe GC language?
No I don't, which exploit are you talking about? The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language. The "most expensive software bug" (not an exploit) caused by turning off the safe overflow handler in the language being used can hardly be considered an indictment of language level safety either. So what exploit are you talking about?
Not the person you replied to, but they're probably talking about Log4j. It's a Java logging library that had a helpful feature where logging a special format string would pull code from a remote URL and execute it. So anywhere you can get a Java server to log something you can run arbitrary code. (Ex: by setting a malicious User-Agent.) Estimates say 93% of enterprise cloud environments where affected.
I suppose Stuxnet could also count, where the initial infection depends on the human curiosity of plugging an unknown usb drive into an air gapped system.
> No I don't, which exploit are you talking about?
Log4j
> The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language.
Heartbleed was nowhere near as costly as Log4j. Last I checked, there was two orders of magnitude difference between the cost of fixing Log4j (which still isn't completely fixed for a few systems) than Heartbleed (which is completely fixed).
I wouldn't consider the remediation costs as being the costs of the exploit - that's more just a measurement of how widely used something is (if anything I'd say it should count for the other side - cost of exploitation divided by cost of remediation is a reasonable measure of how "bad" the bug was, because the cost of remediation is generally proportionate to the cost that was being saved in the first place). Heartbleed has the most expensive case of actual exploitation I can think of - the $73M JP Morgan hack. So far I haven't heard of any attackers actually using the log4j vulnerability.
> Log4j (which still isn't completely fixed for a few systems) than Heartbleed (which is completely fixed)
How are you counting that? There are definitely embedded systems out there running old versions of OpenSSL that will never be patched. Because there's no standard package management and vendoring dependencies is more common in the C world, it's probably less easy to get a list of vulnerable systems, but that doesn't mean the vulnerability isn't there.
> I wouldn't consider the remediation costs as being the costs of the exploit - that's more just a measurement of how widely used something is
Maybe you won't in general, but we're chatting on a thread about the threats of supply chain attacks.
Reading upthread, some GG...P thread espoused the idea that maybe the trade-off in using a memory-safe language with almost frictionless thirdy-party dependency might not always be worth it compared to a memory-unsafe language with very high friction for third-party dependencies.
In this context, the specific comment I replied to made a frankly asinine comment about how "this wouldn't happen in Rust", to which I felt compelled
to point out that a) More expensive breaches have occurred in memory safe languages, and b) Supply chain attacks have large dollar impacts anyway.
To add, there's also c) The majority of breaches are occurring irrespective of tech stacks.
I had no alternative in mind. The topic at hand is security and bloat, and C/C++ might be leaner apps in practice but they are generally going to have memory safety bugs which is a security problem.
It is, but there are very good tools and plenty of experience with dealing with the problem. It's been blown way the fuck out of proportion lately by the Rust mob.
Bloat might be correlated with the ease of bloating software and it indeed easier to do precisely that if you don't have to write it yourself.
Bloat is uncontrolled complexity and making it harder to manage complexity reduces bloat. But it also makes it harder to write software that has to be complex for legitimate reasons. Not everybody should write their own library handling SSL, SQL or regex for example. But those libraries are rarely the problem, things like leftpad are.
Or: you can use package systems for good and for evil. The only real way to fight bloat is to be diciplined an vet your dependencies. It must cost you something to pull them in. If you have to read and understand everything you pull in, pulling in everybody and their dog suddenly becomes less desireable.
Also I think this is much more an issue off the quality of dependencies than it is about using dependencies themselves (it would be stupid to write 1000 implementations of HTTP for a language, one that works really well is better).
> But it also makes it harder to write software that has to be complex for legitimate reasons.
Might have stolen this quote somewhere, but imho:
Simple things should be easy, complex things should be possible.
Related: software (binary) size should reflect the complexity of the problem domain.
Some time ago, ran down the size of apps on my phone. Smallest one? ~2MB. What does that app do? Calculate some hash on a file. Select a file, it does its thing, shows the hash (and/or copy to clipboard).
What the ..!?!#$ 2,000,000+ bytes for that?
This is on Android, 'batteries included'. Selecting / opening a file should be a couple (or couple dozen) lines of source code, a function call to the OS, and presto. Same with reading file contents, and display output / clipboard copy.
Which leaves... computing the hash. I'm not an expert, but what hash functions are so complex that you'd need a MB+ of code to calculate? (answer: none).
Note that this app was the least worse offender.
Conclusion: Android app model is broken. Or SDKs used to build Android apps are crap. Or other reasons / some combination thereoff. Regardless, ~2MB to compute a file hash is ridiculous. Full-blown Graphical User Interfaces (GUI) have been done in less.
I'd be interested to know what that 2MB consists of, though. And where the hash function is at. And what (minute) % of overall binary size. And what all the rest of that binary does.
It's also worth mentioning the extensive standard library and golang.org/x/, which means that you generally don't even need that many 3rd party packages.
Since you're apparently interested in downvotes (why?), I'm pretty sure it's not due to criticism of Go but rather the fact that your criticism is entirely non-specific and therefore doesn't add anything to the discussion...
There's plenty of perfectly good libraries on npm and pypi, and there's awful ones. Likewise for go which pulls from "the internet".
Must I really demonstrate that bad code exists in go? You want examples? There's plenty of bad libraries in go, and pinning to a commit is a terrible practice in any language. Encourages unstable APIs and unfixable bugs.
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.
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).
>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.
Apple backed themselves into a corner with desktop monitors by setting the bar for Retina pixel density so high, display manufacturers still aren't able to provide panels which are that large and very dense and very fast. Nobody makes 5K 27" 120hz+ monitors because the panels just don't exist, not to mention that DisplayPort couldn't carry that much data losslessly until quite recently.
There's no excuse for 60hz iPhones though, that's just to upsell you to more expensive models.
> Then why does Apple still ship 60Hz displays in 2025?
To push people who want faster displays to their more expensive offerings.
60Hz: $1000
120Hz: $1600
That's one reason, among many, why Apple has a $3 trillion market cap.
For a site with so many people slavishly obsessed with startups and venture capital, there seems to be a profound lack of understanding of what the function of a business is. (mr_krabs_saying_the_word_money.avi)
I said many choices are focused on user-perceived performance, not all of them.
Refresh rate only really makes a case for performance in games. In everyday tasks, like scrolling, it's more about aesthetics and comfort.
Also, their scrolling on 60Hz looks better than scrolling on Android at 60Hz. They know this. Why they didn't prioritize using 120Hz screens is out of my knowledge.
Also, you lack attention. These we're merely examples to expand on the idea of bloat versus technical debt.
I am answering out of kindness and in the spirit of sharing my perspective to point the thread in a more positive discussion.
You lack attention. It matters for comfort in everything. It matters for performance on games much more. Most users don't even know about refresh rate, they just know their iPhones feels good.
They don't let you scroll as fast as Android does, which makes the flickering disorienting sensation of speed scrolling in a low refresh rate less prominent. It optimizes for comfort given the hardware they opted to use.
Android lets you scroll faster, and it does not adjust the scrolling dynamics according to the refresh rate setting. It's optimized for the high end models with 120Hz or more, so it sucks on low end settings or phones.
Some people take years to understand those things. It requires attention.
Battery life? Temperature? Price-to-performance ratio? These are not decisions that are solved as simply as decreeing "every device must have at least 3000Hz refresh rate."
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!)
> 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.
Simple means different things for different people it seems. For a simple web server you need a tcp socket.
If you want a full featured high performance web server, it's not gonna be simple.
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
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.
I think we lost something with static linking when going from C to Dotnet. (And I guess Java.) Many C (and C++, especially "header only") libraries when statically linked are pretty good at filtering out unused code.
Bundling stuff in Dotnet are done much more "runtime" often both by design of the library (it uses introspection¹) and the tools².
1: Simplified argument - one can use introspection and not expect all of the library to be there, but it's trickier.
2: Even when generating a self contained EXE, the standard toolchain performs no end-linking of the program, it just bundles everything up in one file.
> I think we lost something with static linking when going from C to Dotnet. (And I guess Java.) Many C (and C++, especially "header only") libraries when statically linked are pretty good at filtering out unused code.
This is an interesting statement because, for example, in C version of Mimalloc you end up paying for opt-in assertions because they still exist in the code unless you compile a different version that strips them away. In C# port, you can set the same assertions/checks early with AppContext switch, and then the values will be cached in static readonly fields. Then, when JIT recompiles the code to a more optimized version, these values will become JIT constants leading to all the unreachable code to be optimized away completely (and to much better inlining of now streamlined methods).
> Even when generating a self contained EXE, the standard toolchain performs no end-linking of the program, it just bundles everything up in one file.
/p:PublishTrimmed=true
or even
/p:PublishAot=true # please note it's better to set it as a project property, but either way it requires non-optional linking
Lastly, consider that JITing the bytecode essentially acts like if everything is a single, statically-linked compilation unit since it's not subject to inconvenient compilation unit restrictions even Rust is subject to, the problems of which need to be cleaned up with link-time optimization.
I think you overestimate ability of Dotnet to trim unused things. As a person who spend a lot of time wandering across ecosystem and measuring what can be done, I would say we have very bulky and complicated libraries in the .Net.
Just bringing HttpClient(without SSL support) add 6Mb of generated code.
Minimal API gets you additional 21 Mb. And we not even talk about desktop applications here.
Reflection is very very core of .Net ecosystem and you cannot reliably trim with how we use it currently
Last time I checked the base web template (the one which uses minimal API) was around 10-12 MB (which is pretty good for something with a full web server, GC, async runtime and more). I’ll message you in private to see what’s going on.
But otherwise yes, reflection is used heavily even when completely unnecessary.
> 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…
I would say this is a feature and not a bug. Alpine Linux is largely designed to be run in containerized environments so you can have an extremely small footprint cause you don't have to ship stuff like a desktop or really anything beyond the very very basics.
Compare that to Ubuntu which for the 5GB download is the "Desktop" variant that comes with much more software
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
There is more to size than storage space. Larger applications take more memory, more cpu caches; things spill over to normal memory, latencies grow and everything runs much slower
For practical purposes given more than enough RAM and fast storage there is no meaningful user discernible performance differences between a 500Mb OS and a 30GB OS.
Whereas very small linux distros are useful in several areas like containers and limited hardware running such on the desktop is an objectively worse experience and is moreso a minimalism fetish than a useful strategy.
> (..) there is no meaningful user discernible performance differences between a 500Mb OS and a 30GB OS.
I call BS. A small single board computer I have, came with 8 GB of RAM. Not esoecially big or small. 500 MB would fit into this, comfortably. Leaving ~7.5GB for apps. Load everything into RAM once, run from there. RAM bandwith is ~8.5GB/s.
30 GB wouldn't fit. So: swap everything in & out using a (cheapish) SSD over a x1 PCIe lane. Or (more common) from an SD card / eMMC module. Think ~100 MB/s on a good day. That's with apps competing for the memory crumbs left.
That's a ~85x factor difference. 2 orders of magnitude. Yes users would notice.
Sure, developer with fully decked out system doesn't see this. Or even understand it. But:
Size matters.
Note: smartphones, tablets etc are not unlike that SBC. And flash storage tends to be on the low-end side where speed is concerned. Desktop you say? Nope, smartphones & tablets are where it's at these days.
Intelligently swapping stuff from storage to RAM is literally how most OS on earth have worked for a while because as long as you have enough to keep what is liable to be used soon in RAM performance can trivially be excellent.
Libreoffice on my system spends 99.9% of the time consuming only 650MB of storage. Opening an office doc makes it require about 165MB of RAM. The consequence of it being swapped out at some point is that it takes slightly longer to get started the next time on the order of an additional 0.6 seconds.
If you watched me and the computer whilst I completed a 15 minute task with office you would note that the computer spent most of its time waiting on me rather than the other way around.
It would start 0.6 seconds faster but it wouldn't get done meaningfully faster. It would be 6 100ths of 1% faster rather than being "two orders of magnitude faster"
Worse if I really want faster libreoffice I can just start that at boot and thereafter create new writer windows in ms I wouldn't be obliged to run my entire OS from RAM to achieve this goal.
Virtually nobody runs standard desktop linux on smartphones or tablets. Distro's that target desktops and laptops should not reduce their fitness wherein they are actually used in order to be better suited for environments in which they are not.
> Libreoffice on my system spends 99.9% of the time consuming only 650MB of storage. Opening an office doc makes it require about 165MB of RAM.
Most office type docs I have, are a few hundred KB (some smaller) to a couple of MBs.
So in your example, that means checking a small document takes (on average) in the order of 100..1000x the document's size worth of RAM. And 'only' 4x that amount of storage for the app doing it.
It wasn't long ago that file sizes vs. code to process it, were more like in the 10:1..1:10 range. 200KB text editor, 50KB text. 100KB image, image viewer under 1MB, etc.
As file sizes grow (higher screen resolutions etc), a reasonable expectation would be for code size (=file format complexity + interfacing with the OS) to lag behind. But the reverse seems to be happening. And let's not get started about browsers, or (worse) "web frameworks".
So if anything, your example nicely demonstrates the point of the article.
There is expected to be no inherent stable ratio of RAM consumed to document size because the smallest possible document still requires 100% of the basic app and assets to be loaded in order for the app to work and thereafter this isn't expected to grow linearly with the size of the file.
What you are seeing is the expansion of the baseline app not the expansion of RAM required per kb of data. Indeed multiplying your post to a 3000 page monstrosity through the magical of cut and paste and select all only took around twice as much memory as a blank document.
> As file sizes grow (higher screen resolutions etc), a reasonable expectation would be for code size (=file format complexity + interfacing with the OS) to lag behind.
It is pretty clear that the opposite is always going to be true. Programs that don't die outright accumulate features and file formats over time multiply. Further even if the app were the same there are going to be opportunities to trade RAM consumed for a better experience that are going to make more sense the more plentiful RAM is.
There is no expectation whatsoever that coders targeting machines with 16GB of RAM and TB of storage to produce applications that are as parsimonious as those produced to target machines that have 512MB of RAM and GB of storage.
If you want parsimony you can always run emacs and export to pdf its rather fun.
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.
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.
We do use docker compose (thank god) but I also need to run a server from source for most of the microservices in order to modify and debug the code. There are around 20 something containers in practice, 6 pods/services. All interdependent and necessary to run the product (it's a legacy codebase 10+ years old, I joined less than 1 year ago and had nothing to do with architecture decisions). Most features touch on at least 3 to 4 repos/microservices all impossible to decouple. The problem is really opening and launching code across 6 bash consoles some of which require an additional manual authentication step with various cloud providers. I need the ability to restart some independently after making code changes. It's just a very complicated system.
I'm sure the launch can be fully automated but it's kind of at the edge of not worth automating because of how relatively infrequently I need to restart everything... Also the CEO doesn't like to make time for work which doesn't yield visible features for end users.
I actually handed my resignation a month ago, without another job lined up. It became too much haha. Good practice though. Very stressful/annoying.
I remember, at the turn of the century (was is 2001?) when Microsoft was touting "weak coupling" achievable through "web services" and demoing the support for SOAP in Visual Studio.
To me, that was the strangest idea - how could you "decouple" one service from another if it needs to know what to call, and what information to pass and in what format? Distributing the computing - for performance, or redundancy or security or organizational reasons - that I can understand - but "weak coupling" just never made sense to me.
Yeah it's a case of falling in love with the solution, not with the problem.
The real reason for tight coupling is simply complex interfaces. That means a range of things; complex function signatures which rely on highly specific parameters (e.g. live instances instead of raw primitive values or raw data) or return complex values instead of raw information "here's what I did". It can also mean complex API parameters and response payloads. Ideally, complex processing should be hidden behind simple interfaces which don't encourage micromanaging the module/service. If the interface is as complex as the processing behind it, that's a design failure and will lead to tight coupling.
Separating code into modules and services may be intended as a way to encourage developers to think about separation of concerns so that they may end up designing simpler interfaces but it doesn't seem to help certain people. Some see it as an opportunity to add even more complexity.
Yep, one of the minor details the micro service fan club don't talk about much.
Firing up the whole mess and debugging one or two of them locally is always a major pain, and god help you if you have no idea which services to stub and which to debug.
Something I've felt is missing is a developer orchestration layer that makes it really easy to define the set of services like a docker-compose but just as easy to switch implementations between container, source, or remote.
Sometimes you need them all from source to debug across the stack, when you don't you might need a local container to avoid pollution from a test env, sometimes it is just fine to port-forward to a test env and save yourself the local resources.
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.
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.
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.
Try CUDA in a Docker environment. Yesterday it took all day long to download an Ubuntu image (5.27Gb) and its Python dependencies (another few Gb) to install Pytorch. I've probably wasted 10Gb of bandwidth just to have the environment up and running. Fortunately in the meantime I wrote 90% what I needed to do. Oh I forgot that I still need to download a couple of hugging face models. Nice.
Was Windows a requirement or your own choice? Asking because I have seen people unwilling to switch to a GNU/Linux VM or boot into GNU/Linux and then forever struggling with their setup, while other people on the team used GNU/Linux or MacOS and didn't have nearly as many problems.
>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.
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
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.
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.
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.
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.
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.
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).
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?
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.
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!
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.
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.
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.
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.
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'.
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.
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.
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.
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?
>do you really want to implement your own json parser?
On the recreational and creative side, maybe, but not as much as coming with an original exchange format which is a better feat to the specific case at hand.
On a professional side, if JSON support is a burden engraved in the specification so be it. Then having the transformation of the PL native data structure back and forth to various other formats shipped in the standard library is really the best that can hoped. As second best case it is having a single clearly preponderant and well maintained library. Otherwise, bet among a plethora of possible libraries is becoming less attractive compared to building something internally brewed.
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.
The part you are missing: If something in the dependency isn't working as you'd like at some point later, making your code work as you desire may be dramatically more difficult than if you hadn't brought it in.
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.)
One should draw a different line depending on the situation. That's where the engineering comes in. There is no silver bullet. We should still be suspicious and judicious about every single dependency.
> So with infinite resources it would be best to write everything from scratch?
Re-read the parent and the other replies: A critical point you are missing is your interlocutor's practical mindset in contrast to your idealistic one. This is about making engineering-mindset tradeoffs; they vary depending on the specific scenario. The answer to your Reductio ad absurdum is yes, but I believe that side tracks rather than elucidates.
The explicit re-statement: There is no general line to draw of whether to use a dependency, or write code internally using a language's primitives (Or already-used libs); it varies based on the situation, and there is a high degree of subjectivity in each of these choices.
- How much work would it take to implement and maintain this if done without a library?
- What other libraries are available?
- Does this library meet our needs superficially, or will it be a robust solution long-term?
- When our requirements change slightly, or we need to add or change features, will this library still work?
- How much code architecture needs to change to integrate this? Does it require changing other parts of the program that it seems should not be required to change for the reason we are bringing this in?
- What impact does including this have on binary size and compile time?
- What is the risk of security vulnerabilities?
- Does this library have its own deep dependency tree?
- Will this require continuous maintenance to keep it in sync with other dependencies?
- Does this library require certain system dependencies to be installed that will make the build more fragile / less portable?
- Will using this dependency impact performance over implementing manually? (Or over another dependency)
A good dependency solves a well defined problem with a direct API towards it, so yes, if the dependencies you talk about aren't high quality then yes, don't use those.
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.
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.
A distribution is just a collection of software to handle common needs. Most are quite similar: systemd, coreutils, glibc, dbus, polkit, pipewire/pulseaudio, and a DE, typically GNOME or KDE. You'll expect to see them on Debian, Ubuntu, Fedora, Nix, Arch, or anywhere else except Void, Alpine, and Gentoo. The only meaningful difference is typically the package manager. We have more standardization in the Linux ecosystem then ever and equally as much bloat, both thanks to systemd.
> Surely it would be better to concentrate on fewer languages and make those more adaptable.
Programming languages are a combination of tools and notation. Different domains have different needs and preferences. We don't lament quantum physicists using bra-ket standard linear algebra notation. Unlike notation, there are material reasons to use one beyond clarity. Some languages support deeper static analysis, some prove complete theorems about your specification, some are small enough to embed, some are easier to extend, and some exist only within a narrow domain like constraint satisfaction. We can add macros or introspection to a language, but in doing so it will fall outside a domain that might value predictability or performance.
> Now take the huge numbers of programming languages out there
~> open langs.csv | filter {|x| $x.SOPercent > 0.25} | get Year | math median
1994
I took data from the 2024 Stack Overflow survey filtered for professional developers. The median release year for languages above 25% market share is 1994. The youngest serious language on the list is Swift, dated 2014. I don't think this is evidence of a growing number of programming languages.
See converted data below. The release year was augmented by o4-mini.
Right, you've given me a reply I'd expect from programmers and Linux uses. I say that as some who has done programming and that I use Linux as my preferred OS.
I don't know why I mentioned Linux here because every time I do in such comments it distracts from the main issue, we Linux users have very fixed and firm opinions about such matters.
Despite your comments, which I essentially agree with (at least in principle), I cannot see rhyme nor reason why there are so very many Linux distros. Yes, there'd be good reason if they were one-offs for a specific application, say in embedded systems etc., but to have so many widespread and in the public domain makes little sense to me. It not only causes confusion amongst users, especially novices, but also spreads human effort widely that would be otherwise better spent on developing fewer systems—it's the more hands make light work philosophy. For the same reason it's why Linux has been so slow to take hold on the desktop. Yes, the usual hardcore Linux user who knows Linux well says 'who cares, that's the least of our worries'. For some odd reason they don't care that the Linux ecosystem would be better off with a more cohesive and unified approach to development.
Even with that said, Linux is forever changing, new kernels come out so frequently that it's hard to find two Linux distributions with simultaneously the same kernel code. No matter how one views it, that load puts a constant strain on bug finding, security testing, etc. Frankly it's a mess, if for no other reason that so many versions are a nightmare for administrators. All these updates cause lots of extra work for all those who don't work in tightly controlled environments that have rigid/strict update procedures. …And that's many of them.
Leaving me out of the argument for a moment, I'd reckon many of the Linux fraternity would object to you lumping Arch with say Debian in the one sentence although they'd likely agree with you over Gentoo etc. That said, why then can't Linux have a single package manger? It's a damn nuisance that it's not so. As usual, not enough people can agree to reach a unified consensus (and they disagree for very questionable reasons). And it's why in many instances we've had to resort to messy kludged solutions such as flatpack. I've more but I'll stop there.
"Programming languages are a combination of tools and notation. Different domains have different needs and preferences."
Why? Yes, I've seen many reasons but I've never seen it justified with solid argument. Most of those reasons arise out of historical happenstance, and or favouritism, or that 'we've always done it that way' syndrome. As I said, programmers have an investment in learning and they don't want to see it made obsolete. Whilst that makes sense to them, it doesn't go any way towards solving the chronic software problems as outlined in the IEEE story.
Let's look at the number programming languages problem a little further. A quick search finds this quote on the CLRN—California Leaerning Resource website:
"According to The International Organization for Standardization (ISO), there are approximately 14,000 programming languages out there. However, this number is often disputed, and different sources may provide varying estimates. For instance, Wikipedia lists over 23,000 programming languages, while Rosetta Code, a website that aims to document programming languages, claims to have data on over 6,000 languages."
That makes me shudder.
OK, lets whittle that down to something more reasonable. Some references claim the number of well-known languages is upward of 700, with between 200 and 400 being those most commonly used. Others say the most frequently used languages number upward of 50. How correct that is and how much of those numbers can be put down to programmers' favorites I cannot say (I only know a few, Lisp, Fortran, C and a few others, so I'm not qualified to speak for those others). I would suggest however that a rational approach would reduce that number down to many fewer than we have now.
To test that hypothesis one could begin with a mathematical analysis of each language. Perhaps the formal mathematical logic à la Whitehead and Russell's Principia Mathematica would be a good place to start as not only the mathematical structures of a language could be tested for coherence and correctness but also so could its grammatical syntax. Possibly there are even better ways of going about such an analysis but I've not given them much thought. Little doubt, AI will rationalize all this in the near future irrespective programmers' wishes.
Suffice to say, until those analyses are done I remain unconvinced that all those (at least common) languages are needed. Preference and favoritism may drive the current status quo but it's not a logical way to proceed and to properly tackle the problems outlined in that story.
I see a common thread in that comment: there's too many distros, there's too many languages, there's too much software. But there's no central authority telling people to make them. You can't force people to not reinvent the wheel; that's hubris, the third virtue of a programmer, as well as parallel invention.
If you base your solution on top of something else, like writing a DSL in Lisp instead of starting from scratch, it will still become a new language as it diverges, like Coalton. Otherwise we'd say Perl isn't a language, because its interpreter is written in C.
If these tools weren't needed, nobody but their author would use them. There's a genetic hill climb happening in every sphere of life, from film and poetry to science and programming, where every new thing either sets a new threshold of goodness, or is forgotten when it fails to. Sooner or later things stabilize, when the new solution is not better enough to outweigh the old one: we used to see many version control systems, but only Git remained, because for all its flaws, something like Jujitsu or Pijul weren't as much better than Git as Git was than SVN. We measure how close we are to convergence not by the size of the population, but by the average age of the used solutions. By that metric, software is cooling.
There is no problem to solve: nobody is writing enterprise software in a bespoke SKI-combinator derived language they found on Rosetta Code, nor paralyzed by choice between 275 Linux distros to put on their server. The duplication of effort is a cost offset by dysfunctional application and maintenance of solutions designed by committee. Simplicity does not precede
complexity, but follows it.
"…there's too many distros, there's too many languages, there's too much software. But there's no central authority telling people to make them."
You are right, there is no central authority telling people what to do and what software to write. And you are correct "you can't force people to not reinvent the wheel…".
What can be done however is to mandate specified software that's gone through rigorous testing in certain buisnesses, government, utilities, the military, critical engineering—aircraft, nuclear, and so on. There's already been a bit of this with Ada and the military but it's miniscule compared with what I am advocating.
Think of it this way: no matter what country one is in all electrical outlets are the same and comply with strict electrical standards for that country. That's not to say there is only one standard worldwide but there are far fewer than if it were a free-for-all as it is in the software industry.
You don't stop people from doing anything, reinventing the wheel or whatever—instead you make it unlawful to supply sofware to those vital entities that does not comply with those specified standards (as set by the ISO, etc.). Outside that realm programmers can do what they want but if they want to play with the big end of town then they'll have to play strictly by the rules.
We'll get to this stage eventually, but it's taking undue time.
As you've said, "Sooner or later things stabilize, when the new solution is not better enough to outweigh the old one…"* but the software industry as a whole is nowhere near that stage of development. Individual program may have reached that stage of development, but in a global sense the software industry is still decades behind the professional standards of other well-established professions (don't take my word for it, just consult the literature).
Right, that sounds authoritarian and something a dictatorship would do. But not so fast: those electrical standards to which I referred were only mandated by govermnents after the free-for-all chaos of the early electrical era where industry could not or would not adopt common standards.
.
The same applies for other disciplines, electrical engineering has any number of rigorous standards in addition to the example I've already given, same with civil, chemical engineering, transport, shipping etc., weights and measures, and almost all of them are tied to national and international standards. Moreover, a large subset is mandated by law for reasons of compatibility/interoperability (shipping containers, etc.) and or health and safety reasons, or for economic reasons, to minimize costs, to stop people being cheated etc.
These standards and concomitant laws and regulations are a fact of life worldwide and in many instances penalties apply for violating them. About the only exception is the software industry, it's no longer young and should have matured by now but it still operates like the Wild West were anything goes.
I say that as someone who has sat on standards committees and been involved in writing standards. Moreover, in my profession if I were to act in the undisciplined manner of much of the software industry, I'd be struck off.
Right, those are harsh words indeed—but they are only harsh for an industry that has never had to comply with rigorous rules and regulations that have been set by law. Whilst other disciplines have learned to accept them long ago the software industry still does what it damn-well wants, and it's done so with impunity from its outset. That has to change.
So you think I'm a self-opinionated crank. OK, let me bring you back to this HN story and think again. Software programmers and developers like to call their work software engineering and themselves software engineers but I'd suggest many in other engineering professions just laugh at the notion. If you don't hear them shouting it out loud it's because they're being polite.
What we in other engineering professions laugh about isn't the skill sets of programmers and developers, we accept there are many very skilled people who work in the industry. The real issue is the laissez faire free-for-all attitude of the industry—an undisciplined industry not bound by strict procedures and lawful regulations. Without regulations and clearly defined rules and procedures we end up with inconsistent results, bugs and lots of mess.
I'd suggested you read this story again then read the document in the link below, it was written nearly 31 years ago and covers the issues I've addressed, it's a SciAm article titled Software's Chronic Crisis. One of its key postulates is that software development doesn't have the disciplined lineage of say chemical engineering and that programmers are more akin to artists than engineers because they operate without industry standard strictures and procedures (such as those set by law).
What's so poignant about that article nowadays is that precious little has changed in the software industry in respect to those matters it refers to. Now ask yourself why is that so given that there has been much development in other areas of software development.
Little doubt the above commet is correct. Look at the way Niklaus Wirth's Pascal lacks widespread support amongst programmers whereas languages such as C are very popular because programmers don't feel constrained to the extent that Pascal constrains them, they feel hemmed in by it. Pascal essentially works like other professions—you must define what you want first up, (the concept, say a bridge) and then draw up the plans and revise them before anyone starts building it. After it's built few if any changes can be made. That's the cultural difference between software development and other engineering professions. It's a fundamental one.
The state of software is the state of the structures
of primitive societies: some in cave shelters, some
under roofs of sticks and leaves, some in mud huts.
We talk of Cathedral and Bazaar, but there are very
few carefully designed Cathedrals of software,
and those probably have plenty of barely hidden flaws.
The Bazaars are all around us, jammed together, spreading
for miles and miles, tent walls
and roofs billowing in the breeze, all awaiting a strong
zephyr to carry many of them away, and leave most of the rest in ruins.
What software needs is building blocks. Bricks of uniform size,
easily joined together. Concrete masonry units. Tilt-up walls.
Trans-oceanic shipping containers (connex, seabox).
Solid, composable, engineered, units. We should be able to
pull a well-known and heavily tested package or function to use,
just like a contractor would call for a delivery of 200 8x8x16"
CMU blocks, and be able to expect they will get just that,
with no gaps, weak spots, or broken webs.
But, no , all of us software crafts-folk want to carefully create
our very own artisanal version of whatever library functions,
that are needed for the project at hand. In a world that could be
made of solid concrete blocks, we are crafting our very own adobes,
with our own special blend of straw and mud, and we think we have advanced far beyond the folks living in mud huts.
Some of us will say they are master masons, crafting cathedrals out
of hand cut stones, each carefully measured and chiseled, and each
stone unique. We're still duplicating effort when we could be using
commercial off-shelf libraries. And all the while the project deadlines
go zipping past as we try to craft our way to local perfection.
All I can suggest as a solution is a multi-government and
multi-corporate effort to design and build fairly universal
functions, libraries, and packages that are robust,
exhaustively reviewed by humans,
and tested thoroughly. I won't ask for provable correctness, yet. :-)
Would the result be an Ada on steroids?
Depends on who is involved.
Choice of language should not matter.
The APIs would matter, a lot.
A few competing teams would be a possibility.
Passing several existing functions to an AI, with a
"do like these, only perfectly" might be useful, or useless.
And yes, then we would have 15 competing standards.
https://xkcd.com/927/
(Well, we probably already have at last 1,500, so, go figure.)
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.
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.
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.
>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.
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.
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.
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.
I thought about this several years ago and I think I hit the right balance with these 2 rules of thumb:
* The closer something is to your core business, the less you externalize.
* You always externalize security (unless security is your exclusive core business)
Say you are building a tax calculation web app. You use dependencies for things like the css generation or database access. You do not rely on an external library for tax calculation. You maintain your own code. You might use an external library for handling currencies properly, because it's a tricky math problem. But you may want to use your own fork instead, as it is close to your core business.
On the security side, unless that's your speciality, there's guys out there smarter than you and/or who have dedicated more time and resources than you to figure that stuff out. If you are programming a tax calculation web app you shouldn't be implementing your own authentication algorithm, even if having your tax information secure is one of your core needs. The exception to this is that your core business is literally implementing authentication and nothing else.
I feel like "shouldn't be implementing your own authentication" is overblown. Don't write the crypto algorithms. But how hard is it to write your own auth? If you are pulling in a third party dependency for that you still would need to audit it, and if you can audit authentication software why can't you implement it?
Just follow OWASP recommendations. A while back this was posted to HN and it also provides great recommendations: https://thecopenhagenbook.com/ .
The main challenge isn't necessarily implementing the algorithms, it is keeping up with the security space
Do you expect your team to be keeping up with new exploits in hardware and networking that might compromise your auth? That takes a lot of expertise and time, which they could instead be spending building features that add business value
It sounds cynical, and it kind of is, but offloading this onto external experts makes way more business sense and probably is what allows you to deliver at all. Security is just too big a space for every software company to have experts on staff to handle
The thing is, your "roll your own" auth is likely way smaller and less targeted than the library everyone uses. So the new exploits may simply not apply to your case.
Many famous vulnerabilities happen in parts of software people don't actually use. For example, the "Heartbleed" vulnerability in OpenSSL targeted the "heartbeat" feature few people actually used. In the "Log4Shell" vulnerability the exploit targeted LDAP support in log4j, which I have never seen used and didn't even know existed.
In addition, the "experts" maybe aren't. You may think that whoever is writing that popular library has a team of experts in security, it is used by big, serious companies after all. But in reality it may just be one overworked guy, and people only notice when the system has been publicly compromised. And that's if the developers themselves don't have malicious intent, or have accepted someone with malicious intent in the team (for the latter, see the xz story).
I think this is good retort to what was argued.
What's missed in me saying roll your own auth, even though I did say it, is that you aren't implementing the network stack or crypto. As long as you keep your dependencies up to date you shouldn't have any increased risk over using a third party library.
If there is a novel security flaw discovered, consider the first SQL-injection or XSS attack, then you definitely should know about it. The idea that not rolling your own security related functionality absolves you from the responsibility to know or understand major security considerations is incorrect. It is the responsibility of every programmer to be knowledgeable of the security risks in their space and the patterns that protect against those risks.
There have been major F-ups in recent history with Okta, CrowdStrike, and so on. Keycloak had some major long-standing vulnerabilities. I've had PRs accepted in popular open-source IAM libraries a bit too easily.
Yeah, we shouldn't roll our own cryptography, but security isn't as clean cut as this comment implies. It also frequently bleeds into your business logic.
Don't confuse externalizing security with externalizing liability.
As far as I know tacking on security after the fact usually leads to issues. It should be a primary concern from the beginning. Even if you don't do it 100% right, you'd be surprised how many issues you can avoid by thinking about this during (and not after) development.
Dropping your rights to open files as soon as possible, for example, or thinking about what information would be available to an attacker should they get RCE on the process. Shoehorning in solutions to these things after the fact tends to be so difficult that it's a rare sight.
I have been recommended to think of security as a process rather than an achievable state and have become quite fond of that perspective.
You are describing domain-driven design. Outsource generic subdomains, focus your expertise on the core subdomains.
https://blog.jonathanoliver.com/ddd-strategic-design-core-su...
I think this helps, but I also think the default for any dev (particularly library authors) should be to minimize dependencies as much as possible. Dependencies have both a maintenance and a security cost. Bad libraries have deep and sprawling trees.
I've seen devs pull in frameworks just to get access to single simple to write functions.
Even if you make the obviously wrong assumption that every library is more secure than the one you would write (that will do less the vast majority of the time) We still end up in a eggs in one basket situation.
You haven't thought through any cyber security games or you are funded to post this bad argument over and over again by state agencies with large 0-day stockpiles.
I would like to dig into point 2 a bit. Do you think this is a matter of degree, or of kind? Does security, in this, imply a network connection, or some other way that exposes your application to vulnerabilities, or is it something else? Are there any other categories that you would treat in a similar way as security, but to a lesser degree, or that almost meet that threshold for a special category, but don't?
How many vulnerabilities were due to badly reinventing the wheel in C/C++ though?
Also, people often complain about "bloat", but don't realize that C/C++ are often the most bloated ones precisely because importing libraries is a pain, so they try to include everything in a single library, even though you only need to use less than 10% of it. Look for example at Qt, it is supposed to be a UI framework but it ends up implementing vectors, strings, json parser and who knows how much more stuff. But it's just 1 dependency so it's fine, right?
>> Look for example at Qt, it is supposed to be a UI framework but it ends up implementing vectors, strings, json parser and who knows how much more stuff. But it's just 1 dependency so it's fine, right?
Qt is an application development framework, not a GUI toolkit. This is one reason I prefer GTK (there are things I dislike about it too).
I remember back in the early 2000's that discussion, but now with the the tonnage that systems like npm can pull in I laugh that we ever thought it wouldn't get worse.
There is still an advantage to using Qt over dozens of libraries that offer the same functionality.
Qt is backed by a single company, so all you have to watch out for is that company. Also, Qt is generally high quality, I have worked with it, read the source code, etc... and I generally liked what I saw. So I can reasonably assume that quality is consistent overall. When you have many libraries from many independent developers, it doesn't work. The JSON parser may be good, but it doesn't tell me anything about the library that deal with internationalization for instance, and if I wanted to keep track of everything, that's several time the work compared to a single vendor.
I agree that Qt is bloated though, but multiplatform UI frameworks are hard to keep light. There is a lot going on in a desktop UIs that people only notice when it isn't there. I tend to treat them like I treat the standard libraries, the OS, and for web apps, the browser. Big components, but you reasonably can't do without.
How many vulnerabilities were due to badly reinventing the wheel in C/C++ though?
I don't know. Suppose you tell us.
In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being included into new projects sooner or later (and everyone and their dog has their own bespoke string handling libraries). Copy/pasting large chunks of code from elsewhere is also rampant.
I'm not so sure C/C++ solves the actual problem. Only sweeps it under a carpet so it's much less visible.
It definitely does solve one problem. Like it or not, you can't be hit by supply chain attacks if you don't have a supply chain.
I mirror all deps locally and only build from the mirror. It isn’t an issue. C/C++ is my dayjob
at some point you could mirror a supply chain attack... xz was a pretty long game and only found by accident for example
I’m sure I will.
This runs the risk of shipping C/C++ libraries with known vulnerabilities. How do you keep track of that? At least with npm / cargo / etc, updating dependencies is a single command away.
Pull, update, build?
How do you even know a dependency has an open vulnerability?
Conversely, how do you know when a dependency doesn’t have a vulnerability?
> every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc
You are right. But my conclusion is different.
If it is a stable and people have been there for a while then developers know that code as well as the rest. So, when something fails they know how to fix it.
Bringing generic libraries may create long callstacks of very generic code (usually templates) that is very difficult to debug while adding a lot of functionality that is never used.
Bringing a new library into the code base need to be a though decision.
> In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being included into new projects sooner or later
Same here. And a lot of those homegrown functions, utilities and classes are actually already available, and better implemented, in the C++ Standard Library. Every C++ place I've worked had its own homegrown String class, and it was always, ALWAYS worse in all ways than std::string. Maddening. And you could never make a good business case to switch over to sanity. The homegrown functions had tendrils everywhere and many homegrown classes relied on each other, so your refactor would end up touching every file in the source tree. Nobody is going to approve that risky project. Once you start down the path of rolling your own standard library stuff, the cancer spreads through your whole codebase and becomes permanent.
Although I like std::string for somethings becomes a little tricky with cross platform work that involves both linux and windows. It also can be tricky with unicode and lengths.
This is something that I think about constantly and I have come to the same conclusion. While the idea of being able to trivially share code worldwide is appealing, so far it seems to encourage shittier software more than anything else, and the benefit of sharing trivially seems to be defeated by the downsides that bloat and bad software bring with it. Adding friction to code re-use (by means of having to manually download shit from a website and compile it yourself like it's 1995) seems to be a good thing for now until a better package management system is figured out. The friction forces you to think seriously where you actually need that shit or you can write the subset of the functionality you need yourself. To be clear, I also think C++ projects suffer a lot from re-inventing the wheel, particularly in the gamedev world, but that seems to be less worse than, e.g., initializing some nodejs framework project and starting with 100+ dependencies when you haven't even started to write shit.
When doing SBOM/SCA we see apps with 1000+ deps. It's insane. It's so often we see large packages pulled in because a single function/behavior is needed and ends up massively increasing the risk profile.
Holy cow. What domain is this? Web-based probably?
Could be a Hello World React app using the legacy creator-tool :/
Check this out: https://news.ycombinator.com/item?id=39019001
Of course, this is the whole environment except for Node.js itself. And Vite has improved it.
But there are definitely some tools that are worse than others.
Npm/node_modules is typically one of the worst offenders, but programmers can do this with any import/library based system.
> Npm/node_modules is typically one of the worst offenders, but programmers can do this with any import/library based system.
You can, but I think this thread speaks volumes about the problem with the JavaScript/NPM ecosystem as a whole vs. pretty much any other.
We need something else for the web. The only reason we have 200+ NPM packages for a blank project is because JavaScript is atrocious and has almost nothing built-in. We got crap like LeftPad, isodd, is-array, etc. because of the language. Most of what NPM will pull in on any new web front end project is likely already part of the standard library in C#/dotnet, or Java, Go, etc.
But you could go further back and say it's not javascript's fault, it's the fault of trying to hammer the web into doing things it was never designed to do in the first place. But, we insisted on making it an application delivery platform, and now we're suffering the consequences of that. I'm hopeful for WASM, but ideally I'd love to see a resurgence of native apps.
The problem with native apps is they are (mostly) locked behind "stores" run by Big Tech.
And they're opaque. You have to mitm proxy to even see if they're making requests to who knows where. They run with too many privileges. You can't block ads. You can't link to them.
Meanwhile, the web runs in a web browser. You have a network bar. You can inspect element. You can inject Javascript. You can run your own code inside people's apps.
The former scenario isn't better than the latter scenario just because some people build their website with too many NPM dependencies.
I take your point, but a lot of that needn't be the case. Native apps can have lesser privileges with sandboxing, you can inject code if your OS doesn't forbid it, etc. A lot of this is just in how many of are native apps are, not how they must be.
True. But one of the biggest wins of the web is that it's how things are, and it was only a historical fluke of luck that things panned out this way.
As it's often said, there's no way the concept of a web browser would be feasible in today's walled garden app store norms. You mean a god app than can run remote, arbitrary code? And it lets you sideload arbitrary extensions that can do things like block ads and mutate apps?
The only reason it's allowed is because the web was ubiquitous by the time computing became so highly controlled.
So we shouldn't be quick to dismiss it, despite its warts.
Cathedrals vs Bazaars.
Cathedrals are conservative. Reactionary, even. You can measure the rate of change by generations.
Bazaars are accessible and universal. The whole system is chaotic. Changes happen every day. No single agent is in control.
We need both to make meaningful progress, and it's the job of engineers to take any given problem and see where to look for the solution.
> While the idea of being able to trivially share code worldwide is appealing, so far it seems to encourage shittier software more than anything else, and the benefit of sharing trivially seems to be defeated by the downsides that bloat and bad software bring with it.
A lot of projects would simply not exist without it. Linux, comes to mind. I guess one might take the position that "Windows is fine" but would there ever have been even competition for Windows?
Another example, everyone would be rolling their own crypto without openssl, and that would mean software that's yet a lot more insecure than what we have. Writing software with any cryptography functionality in mind would be the privilege of giant companies only (and still suck a lot more than what we have).
There's a lot more things. The internet and software in general would be set back ~20years. Even with all the nostalgia I can muster, that seems like a much worse situation than today.
All those projects existed long before package managers in programming languages were a thing (although you could consider the distro's package manager to fulfill that purpose, I guess), so I don't think your point really takes away from mine. And for sure, there are critical dependencies like openssl that better be a shared endeavour. But whether you pull those dependencies in manually or through a package manager is somewhat tangential.
I agree fully, most users care about making their lives easier, not about development purity. If you can't do both, the puritanistic approach loses.
This is all heuristic (read "guessing") and not a real solution to the problem.
The ground truth is that software bloat isn't bad enough of a problem for software developers to try and fight it. We already know how to prevent this, if really want to. And if the problem was really hurting so much, we'd have automated ways of slimming down the executables / libraries.
In my role in creating CI for Python libraries, I did more hands-on dependency management. My approach was to first install libraries with pip, see what was installed, research why particular dependencies have been pulled in, then, if necessary, modify the packages in such a way that unnecessary dependencies would've been removed, and "vendor" the third party code (i.e. store it in my repository, at the version I need). This, obviously, works better for programs, where you typically end up distributing the program with its dependencies anyways. Less so for libraries, but in the context of CI this saved some long minutes of reinstalling dependencies afresh for every CI run.
In the end, it was a much better experience than what you usually get with CI targeting Pyhon. But, in the end, nobody really cared. If CI took less than a minute to complete instead of twenty minutes, very little was actually gained. The project didn't have enough CI traffic for this to have any actual effect. So, it was a nice proof of concept, but ended up being not all that useful.
The reason bloat doesn't get fixed is that it's a problem that doesn't really harm software developers. It is a negative externality whose pain is spread uniformly across users. Every little dependency developers add to make their work more convenient might increase the download size over the user's network by 100MB, or use another 0.5% of the user's CPU, or another 50MB of the user's RAM. The user gets hit, ever so slightly, but the developer sees only upside.
The phrase "cheap and nasty" comes to mind. Over time, some markets tend towards the cheap and nasty.
Some? Almost all. That's the default end state if there's actual competition on the market.
100, ha! The official rust docs, built in rust, use ~750 dependencies - queue the apoligists
> There is no auto-download
There is. Linux distributions have package managers whose entire purpose is to distribute and manage applications and their dependencies.
The key difference between Linux distribution package managers and programming language package managers is the presence of maintainers. Any random person can push packages to the likes of npm or PyPI. To push packages to Debian or Arch Linux, you must be known and trusted.
Programming language package managers are made for developers who love the convenience of pushing their projects to the world whenever they want. Linux distribution package managers are made for users who prefer to trust the maintainers not to let malware into the repositories.
Some measured amount of elitism can be a force for good.
Writing everything from scratch by hand is an insane take. It is not just reinventing the wheel but there are whole frameworks one should use because writing that thing on your own will take you a lifetime.
Yes you should not just pull as dependency thing that kid in his parents basement wrote for fun or to get OSS maintainer on his CV.
But there are tons of legitimate libraries and frameworks from people who are better than you at that specific domain.
That's not how it works.
Here's a scenario. You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB.
Worse, you pull in different libraries and they all pull in different versions of their own dependencies, with lots of duplication of similar but slightly different code. Node_modules usually ends up like this.
The point is not writing the resize code yourself. It's the cultural effect of friction. If pulling in the resize library means you need to chase down the dependencies yourself, first, you're more aware of the cost, and second, the library author will probably give you knobs to eliminate dependencies. Perhaps you only pull in a JPEG decoder because that's all you need, and you exclude the metadata functionality.
It's an example, but can you see how adding friction to pulling in every extra transitive dependency would have the effect of librabry authors giving engineers options to prune the dependency tree? The easier a library is to use, the more popular it will be, and a library that has you chasing dependencies won't be easy to use.
> You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB.
This is more likely to happen in C++, where any library that isn't header-only is forced to be an all encompassing framework, precisely because of all that packaging friction. In an ecosystem with decent package management your image resizing library will have a core library and then extensions for each image format, and you can pull in only the ones you actually need, because it didn't cost them anything to split up their library into 30 tiny pieces.
Actually I think a big part of the problem in C++ is the low level of abstraction of the standard library. It isn't friction that might cause an image resizing library to be all-encompassing; it's the lack of an abstract Image class in the standard library which would enable a resizing library to live side by side with image encoders and decoders, instead of needing to bundle them together.
The C++ standard library isn't rich enough. It doesn't have enough concepts for a good ecosystem of smaller components.
Do you have an example?
> The easier a library is to use, the more popular it will be
You're thinking correctly on principle, but I think this is also the cause of the issue: it's too easy to pull in a Node dependency even thoughtlessly, so it's become popular.
It would require adding friction to move back from that and render it less easy, which would probably give rise to a new, easy and frictionless solution that ends up in the same place.
There's a difference between "I need to connect to the database and I need to parse json, so I need two commonly used libs for those two things" and whatever npm is doing, and to some extent cargo or popular java frameworks are doing.
Building everything from scratch is insane, but so's uncritically growing a dependency jungle
I feel you are arguing a bit of a strawman. The take is much more nuanced than write everything from scratch.
... 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 ... the resulting code is of a manageable size..
I don't see the nuance there, that is my take of the comment, those are pretty much strongest statements and points about using libraries are minimal.
That is why I added mine strongly pointing that real world systems are not going to be "managable size" unless they are really small or a single person is working on the.
For me "realize that you don't need the feature" is strong and also hits home. I sometimes prototype in C because it makes me think really hard about "what does this thing really have to do? What can I omit for now?"
While in for instance C# I tend to think "this would be simple to implement with whatever-fancy-thing-is-just-a-package-away".
Neither way is impossible to judge as good or bad on its own.
A real world system is almost always part of a larger system or system of systems. Making one thing simple can make another complex. The world is messy.
When you "Reinvent the wheel", you implement only what you need in an optimized way.
This gives a couple of advantages: you own your code, no bloat, usually simpler due to not having all the bells and whistles, less abstraction, so faster because there is no free lunch, minimize the attack surface for supply chain attacks...
For fun, the next time you are tempted to install a BlaZiNg FaSt MaDe in RuSt software: get the source, install cargo audit and run the cargo audit on that project.
See how many vulnerabilities there are. So far, in my experience, all the software I checked come with their list of vulnerabilities from transitive dependencies.
I don't know about npm, I only know by reputation and it's enough for me to avoid.
That wheel is only as good as your skill in making it. For many people (the majority i'd guess) someone else making that wheel will have a better end result.
The skill is produced by carving the wheel. You've got to start somewhere. Whether a mess or not the returned product is a product of your own. By relying on dependencies you're forever reaching for a goal you'll never achieve.
There are no absolute good or bad reasons here, it depends on the problem domain and usage environment. If you're writing code where safety or security matters then of course you need to carefully manage the software supply chain. On the other hand, if you're writing an internal utility for limited use with no exposure then who cares, pull in all the dependencies you need and git 'er done.
I'm not a professional Dev but thought this is was tree-shaking is about? Certainly this happens in flutter, whatever you feel about flutter/dart.
Or is this a sticking plaster? Genuinely don't know as I only develop personal projects.
Tree-shaking is able to remove code that will never be called. And it's not necessarily good at it: we can detect some situations where a function is never called, and remove that function, but it's mostly the obvious situations such as "this function is never referenced".
It cannot detect a case such as: if the string argument to this function contains a substring shaped like XYZ, then replace that substring with a value from the environment variables (the Log4j vulnerability), or from the file system (the XML Entity Extension vulnerability). From the point of view of tree-shaking, this is legitimate code that could be called. This is the kind of vulnerable bloat that comes with importing large libraries (large in the sense of "has many complex features", rather than of megabytes).
Thanks for the explanations, much appreciated.
I suppose the options are then:
1. Write everything yourself, time consuming and hard, less likely to lead to these types of vulnerabilities.
2. Import others code, easy and takes no time, can lead to vulnerabilities.
3. Use others code, but only what you actually need. Maybe less time consuming than 1 but more than 2, adds a different sort of complexity, done correctly less likely to lead to these vulnerabilities.
Not sure if there's any other options here?
I would say 4. grab individual code files (as opposed to entire libraries) and manually edit them, removing unnecessary features and adding new ones where needed.
Yeah everybody should reimplement their own security for example, that's a really smart fool-proof approach especially down the line, no real cases for any contrarian opinions.
I do get what you mean, but it works only on some very specific types of projects, when you & potentially comparably (very) good & skilled peers are maintaining and evolving it long term. This was never the case in my 20 years of dev career.
This sort of shared well tested libraries -> gradually dependency hell is in some form shared across all similar languages since its pretty basic use case of software development as an engineering discipline. I haven't seen a good silver bullet so far, and ie past 14 years of my work wouldn't be possible with approach you describe.
Within reason, we need to be able to promote third party libraries into the standard library.
A small standard library pairs well with an easy mechanism to download code, but at some point it's probably a crutch. There are maybe 5 functions in lodash at this point that show up routinely in production code but cannot be sufficed by existing editions to EcmaScript - sortBy, recursive get, and recursive merges being among the most useful. We could just have these and be done.
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.
> Unfortunately that comes with the baggage of terrible memory safety.
Isn't this unrelated to the parent post's thoughts about the benefit's of the C/C++ ecosystem (or lack thereof) for dependency management? I.e., a Rust-like language could still exist with a dependency management system similar to what C/C++ have now -- that isn't predicated on how the language handles memory.
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.
Remember how cloudflare (in 2017) leaked pretty much everyone's secret tokens in search engine cache due to a simple buffer overflow? Yeah, that wouldn't have happened with Rust
I've seen segmentation faults in java, go, python. All you need is a bug in a hidden library :)
A segfault won't leak sensitive data, though.
The problem is that the code is incorrect and what happens instead/before the segfault, not the segfault itself :)
What happens before/instead is normally worth a CVE.
Segfaults, no. Usually they're a null dereference, but it could also be an out of bounds read on an array, which can leak data.
Not if it's segfaulting, no. That's the point of a segfault.
This just isn't true. A segfault happens when an access happens outside of the memory space of the process, such as a 0x00 pointer. Pages are typically allocated in 4kB chunks and allocators will try to minimize syscalls to allocate more virtual pages by trying to maximize reuse of existing pages. All of this results in an out of bounds access being trivial and hard to detect without additional code to check: https://paste.sr.ht/~chiefnoah/be5864cb0d78d6691fe3e36946709...
A runaway loop can access program memory until it segfaults pretty easily.
Remember that the most expensive exploit the world has ever seen was in a memory safe GC language?
My argument is that you are missing the point: the point is that a larger attack surface enables more exploits regardless of language.
When using a language that has tremendous friction in expanding the attack surface you tend to have a small attack surface as a result.
Theres obviously a crossover point where you'd be safer with a memory safe language and a larger attack surface than with a memory unsafe language and a minuscule attack surface.
> Remember that the most expensive exploit the world has ever seen was in a memory safe GC language?
No I don't, which exploit are you talking about? The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language. The "most expensive software bug" (not an exploit) caused by turning off the safe overflow handler in the language being used can hardly be considered an indictment of language level safety either. So what exploit are you talking about?
Not the person you replied to, but they're probably talking about Log4j. It's a Java logging library that had a helpful feature where logging a special format string would pull code from a remote URL and execute it. So anywhere you can get a Java server to log something you can run arbitrary code. (Ex: by setting a malicious User-Agent.) Estimates say 93% of enterprise cloud environments where affected.
I suppose Stuxnet could also count, where the initial infection depends on the human curiosity of plugging an unknown usb drive into an air gapped system.
> No I don't, which exploit are you talking about?
Log4j
> The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language.
Heartbleed was nowhere near as costly as Log4j. Last I checked, there was two orders of magnitude difference between the cost of fixing Log4j (which still isn't completely fixed for a few systems) than Heartbleed (which is completely fixed).
I wouldn't consider the remediation costs as being the costs of the exploit - that's more just a measurement of how widely used something is (if anything I'd say it should count for the other side - cost of exploitation divided by cost of remediation is a reasonable measure of how "bad" the bug was, because the cost of remediation is generally proportionate to the cost that was being saved in the first place). Heartbleed has the most expensive case of actual exploitation I can think of - the $73M JP Morgan hack. So far I haven't heard of any attackers actually using the log4j vulnerability.
> Log4j (which still isn't completely fixed for a few systems) than Heartbleed (which is completely fixed)
How are you counting that? There are definitely embedded systems out there running old versions of OpenSSL that will never be patched. Because there's no standard package management and vendoring dependencies is more common in the C world, it's probably less easy to get a list of vulnerable systems, but that doesn't mean the vulnerability isn't there.
> I wouldn't consider the remediation costs as being the costs of the exploit - that's more just a measurement of how widely used something is
Maybe you won't in general, but we're chatting on a thread about the threats of supply chain attacks.
Reading upthread, some GG...P thread espoused the idea that maybe the trade-off in using a memory-safe language with almost frictionless thirdy-party dependency might not always be worth it compared to a memory-unsafe language with very high friction for third-party dependencies.
In this context, the specific comment I replied to made a frankly asinine comment about how "this wouldn't happen in Rust", to which I felt compelled to point out that a) More expensive breaches have occurred in memory safe languages, and b) Supply chain attacks have large dollar impacts anyway.
To add, there's also c) The majority of breaches are occurring irrespective of tech stacks.
Yeah I know, if only we could rewrite the entire world in Rust everything would be rainbows and unicorns. But it's not going to happen, deal with it.
I never mentioned rust. I’m just saying C and C++ have terrible memory safety.
And what's the alternative then, from your perspective? What did you have in mind when you wrote the comment?
I had no alternative in mind. The topic at hand is security and bloat, and C/C++ might be leaner apps in practice but they are generally going to have memory safety bugs which is a security problem.
It is, but there are very good tools and plenty of experience with dealing with the problem. It's been blown way the fuck out of proportion lately by the Rust mob.
Bloat might be correlated with the ease of bloating software and it indeed easier to do precisely that if you don't have to write it yourself.
Bloat is uncontrolled complexity and making it harder to manage complexity reduces bloat. But it also makes it harder to write software that has to be complex for legitimate reasons. Not everybody should write their own library handling SSL, SQL or regex for example. But those libraries are rarely the problem, things like leftpad are.
Or: you can use package systems for good and for evil. The only real way to fight bloat is to be diciplined an vet your dependencies. It must cost you something to pull them in. If you have to read and understand everything you pull in, pulling in everybody and their dog suddenly becomes less desireable.
Also I think this is much more an issue off the quality of dependencies than it is about using dependencies themselves (it would be stupid to write 1000 implementations of HTTP for a language, one that works really well is better).
> But it also makes it harder to write software that has to be complex for legitimate reasons.
Might have stolen this quote somewhere, but imho:
Simple things should be easy, complex things should be possible.
Related: software (binary) size should reflect the complexity of the problem domain.
Some time ago, ran down the size of apps on my phone. Smallest one? ~2MB. What does that app do? Calculate some hash on a file. Select a file, it does its thing, shows the hash (and/or copy to clipboard).
What the ..!?!#$ 2,000,000+ bytes for that?
This is on Android, 'batteries included'. Selecting / opening a file should be a couple (or couple dozen) lines of source code, a function call to the OS, and presto. Same with reading file contents, and display output / clipboard copy.
Which leaves... computing the hash. I'm not an expert, but what hash functions are so complex that you'd need a MB+ of code to calculate? (answer: none).
Note that this app was the least worse offender.
Conclusion: Android app model is broken. Or SDKs used to build Android apps are crap. Or other reasons / some combination thereoff. Regardless, ~2MB to compute a file hash is ridiculous. Full-blown Graphical User Interfaces (GUI) have been done in less.
I'd be interested to know what that 2MB consists of, though. And where the hash function is at. And what (minute) % of overall binary size. And what all the rest of that binary does.
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
They can't hack what doesn't exist.
Reducing surface area is sometimes the easiest security measure one can take.
Go has the most lean and simple dependency management. It's far better than npm or pypi dumpster fire
It's also worth mentioning the extensive standard library and golang.org/x/, which means that you generally don't even need that many 3rd party packages.
Also the extensive measures to combat supply chain security for packages [0]
[0] - https://go.dev/blog/supply-chain
Go is a dumpster fire as well as those.
edit: lol at the downvotes. Go developers showing how insecure they are once again.
Since you're apparently interested in downvotes (why?), I'm pretty sure it's not due to criticism of Go but rather the fact that your criticism is entirely non-specific and therefore doesn't add anything to the discussion...
Because the comment I replied to was so specific?
There's plenty of perfectly good libraries on npm and pypi, and there's awful ones. Likewise for go which pulls from "the internet".
Must I really demonstrate that bad code exists in go? You want examples? There's plenty of bad libraries in go, and pinning to a commit is a terrible practice in any language. Encourages unstable APIs and unfixable bugs.
It added just as much to the discussion as the comment it was in reply to, so downvoting one but not the other seems somewhat unfair.
[dead]
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.
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).
>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.
Apple backed themselves into a corner with desktop monitors by setting the bar for Retina pixel density so high, display manufacturers still aren't able to provide panels which are that large and very dense and very fast. Nobody makes 5K 27" 120hz+ monitors because the panels just don't exist, not to mention that DisplayPort couldn't carry that much data losslessly until quite recently.
There's no excuse for 60hz iPhones though, that's just to upsell you to more expensive models.
> Then why does Apple still ship 60Hz displays in 2025?
To push people who want faster displays to their more expensive offerings.
60Hz: $1000
120Hz: $1600
That's one reason, among many, why Apple has a $3 trillion market cap.
For a site with so many people slavishly obsessed with startups and venture capital, there seems to be a profound lack of understanding of what the function of a business is. (mr_krabs_saying_the_word_money.avi)
I don't know why.
I said many choices are focused on user-perceived performance, not all of them.
Refresh rate only really makes a case for performance in games. In everyday tasks, like scrolling, it's more about aesthetics and comfort.
Also, their scrolling on 60Hz looks better than scrolling on Android at 60Hz. They know this. Why they didn't prioritize using 120Hz screens is out of my knowledge.
Also, you lack attention. These we're merely examples to expand on the idea of bloat versus technical debt.
I am answering out of kindness and in the spirit of sharing my perspective to point the thread in a more positive discussion.
>Refresh rate only really makes a case for performance in games
Refresh rate really matters for everything in motion, not just games, that's why I said scrolling.
> In everyday tasks, like scrolling, it's more about aesthetics and comfort.
Smooth scrolling IS everyday comfort. Try going from 120Hz to 60Hz and see how you feel.
>their scrolling on 60Hz looks better than scrolling on Android at 60Hz.
Apple beat physics?
You lack attention. It matters for comfort in everything. It matters for performance on games much more. Most users don't even know about refresh rate, they just know their iPhones feels good.
They don't let you scroll as fast as Android does, which makes the flickering disorienting sensation of speed scrolling in a low refresh rate less prominent. It optimizes for comfort given the hardware they opted to use.
Android lets you scroll faster, and it does not adjust the scrolling dynamics according to the refresh rate setting. It's optimized for the high end models with 120Hz or more, so it sucks on low end settings or phones.
Some people take years to understand those things. It requires attention.
Battery life? Temperature? Price-to-performance ratio? These are not decisions that are solved as simply as decreeing "every device must have at least 3000Hz refresh rate."
I have heard that battery life is the primary reason. After all, it is screen and modem that consumes most of it.
Could be about 20% worse battery life.
https://www.phonearena.com/news/120Hz-vs-60hz-battery-life-c...
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!)
> 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.
Simple means different things for different people it seems. For a simple web server you need a tcp socket.
If you want a full featured high performance web server, it's not gonna be simple.
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/
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.
I think we lost something with static linking when going from C to Dotnet. (And I guess Java.) Many C (and C++, especially "header only") libraries when statically linked are pretty good at filtering out unused code.
Bundling stuff in Dotnet are done much more "runtime" often both by design of the library (it uses introspection¹) and the tools².
1: Simplified argument - one can use introspection and not expect all of the library to be there, but it's trickier.
2: Even when generating a self contained EXE, the standard toolchain performs no end-linking of the program, it just bundles everything up in one file.
> I think we lost something with static linking when going from C to Dotnet. (And I guess Java.) Many C (and C++, especially "header only") libraries when statically linked are pretty good at filtering out unused code.
This is an interesting statement because, for example, in C version of Mimalloc you end up paying for opt-in assertions because they still exist in the code unless you compile a different version that strips them away. In C# port, you can set the same assertions/checks early with AppContext switch, and then the values will be cached in static readonly fields. Then, when JIT recompiles the code to a more optimized version, these values will become JIT constants leading to all the unreachable code to be optimized away completely (and to much better inlining of now streamlined methods).
> Even when generating a self contained EXE, the standard toolchain performs no end-linking of the program, it just bundles everything up in one file.
or even Lastly, consider that JITing the bytecode essentially acts like if everything is a single, statically-linked compilation unit since it's not subject to inconvenient compilation unit restrictions even Rust is subject to, the problems of which need to be cleaned up with link-time optimization.I think you overestimate ability of Dotnet to trim unused things. As a person who spend a lot of time wandering across ecosystem and measuring what can be done, I would say we have very bulky and complicated libraries in the .Net.
Just bringing HttpClient(without SSL support) add 6Mb of generated code.
Minimal API gets you additional 21 Mb. And we not even talk about desktop applications here.
Reflection is very very core of .Net ecosystem and you cannot reliably trim with how we use it currently
Last time I checked the base web template (the one which uses minimal API) was around 10-12 MB (which is pretty good for something with a full web server, GC, async runtime and more). I’ll message you in private to see what’s going on.
But otherwise yes, reflection is used heavily even when completely unnecessary.
I disagree. Most people here myself included aren't using Java or .NET. You are in a microcosm in this audience.
> 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…
I would say this is a feature and not a bug. Alpine Linux is largely designed to be run in containerized environments so you can have an extremely small footprint cause you don't have to ship stuff like a desktop or really anything beyond the very very basics.
Compare that to Ubuntu which for the 5GB download is the "Desktop" variant that comes with much more software
>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
There is more to size than storage space. Larger applications take more memory, more cpu caches; things spill over to normal memory, latencies grow and everything runs much slower
For practical purposes given more than enough RAM and fast storage there is no meaningful user discernible performance differences between a 500Mb OS and a 30GB OS.
Whereas very small linux distros are useful in several areas like containers and limited hardware running such on the desktop is an objectively worse experience and is moreso a minimalism fetish than a useful strategy.
> (..) there is no meaningful user discernible performance differences between a 500Mb OS and a 30GB OS.
I call BS. A small single board computer I have, came with 8 GB of RAM. Not esoecially big or small. 500 MB would fit into this, comfortably. Leaving ~7.5GB for apps. Load everything into RAM once, run from there. RAM bandwith is ~8.5GB/s.
30 GB wouldn't fit. So: swap everything in & out using a (cheapish) SSD over a x1 PCIe lane. Or (more common) from an SD card / eMMC module. Think ~100 MB/s on a good day. That's with apps competing for the memory crumbs left.
That's a ~85x factor difference. 2 orders of magnitude. Yes users would notice.
Sure, developer with fully decked out system doesn't see this. Or even understand it. But:
Size matters.
Note: smartphones, tablets etc are not unlike that SBC. And flash storage tends to be on the low-end side where speed is concerned. Desktop you say? Nope, smartphones & tablets are where it's at these days.
Intelligently swapping stuff from storage to RAM is literally how most OS on earth have worked for a while because as long as you have enough to keep what is liable to be used soon in RAM performance can trivially be excellent.
Libreoffice on my system spends 99.9% of the time consuming only 650MB of storage. Opening an office doc makes it require about 165MB of RAM. The consequence of it being swapped out at some point is that it takes slightly longer to get started the next time on the order of an additional 0.6 seconds.
If you watched me and the computer whilst I completed a 15 minute task with office you would note that the computer spent most of its time waiting on me rather than the other way around.
It would start 0.6 seconds faster but it wouldn't get done meaningfully faster. It would be 6 100ths of 1% faster rather than being "two orders of magnitude faster"
Worse if I really want faster libreoffice I can just start that at boot and thereafter create new writer windows in ms I wouldn't be obliged to run my entire OS from RAM to achieve this goal.
Virtually nobody runs standard desktop linux on smartphones or tablets. Distro's that target desktops and laptops should not reduce their fitness wherein they are actually used in order to be better suited for environments in which they are not.
> Libreoffice on my system spends 99.9% of the time consuming only 650MB of storage. Opening an office doc makes it require about 165MB of RAM.
Most office type docs I have, are a few hundred KB (some smaller) to a couple of MBs.
So in your example, that means checking a small document takes (on average) in the order of 100..1000x the document's size worth of RAM. And 'only' 4x that amount of storage for the app doing it.
It wasn't long ago that file sizes vs. code to process it, were more like in the 10:1..1:10 range. 200KB text editor, 50KB text. 100KB image, image viewer under 1MB, etc.
As file sizes grow (higher screen resolutions etc), a reasonable expectation would be for code size (=file format complexity + interfacing with the OS) to lag behind. But the reverse seems to be happening. And let's not get started about browsers, or (worse) "web frameworks".
So if anything, your example nicely demonstrates the point of the article.
There is expected to be no inherent stable ratio of RAM consumed to document size because the smallest possible document still requires 100% of the basic app and assets to be loaded in order for the app to work and thereafter this isn't expected to grow linearly with the size of the file.
What you are seeing is the expansion of the baseline app not the expansion of RAM required per kb of data. Indeed multiplying your post to a 3000 page monstrosity through the magical of cut and paste and select all only took around twice as much memory as a blank document.
> As file sizes grow (higher screen resolutions etc), a reasonable expectation would be for code size (=file format complexity + interfacing with the OS) to lag behind.
It is pretty clear that the opposite is always going to be true. Programs that don't die outright accumulate features and file formats over time multiply. Further even if the app were the same there are going to be opportunities to trade RAM consumed for a better experience that are going to make more sense the more plentiful RAM is.
There is no expectation whatsoever that coders targeting machines with 16GB of RAM and TB of storage to produce applications that are as parsimonious as those produced to target machines that have 512MB of RAM and GB of storage.
If you want parsimony you can always run emacs and export to pdf its rather fun.
There is never actually enough RAM and fast storage.
There is enough that for most consumer use cases micro optimization only make sense in the context of poverty.
One of my work laptops with 16GB of Ram struggles to open a few spreadsheets and browser tabs because of bloat.
Either install more RAM or install a better OS
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.
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.
We do use docker compose (thank god) but I also need to run a server from source for most of the microservices in order to modify and debug the code. There are around 20 something containers in practice, 6 pods/services. All interdependent and necessary to run the product (it's a legacy codebase 10+ years old, I joined less than 1 year ago and had nothing to do with architecture decisions). Most features touch on at least 3 to 4 repos/microservices all impossible to decouple. The problem is really opening and launching code across 6 bash consoles some of which require an additional manual authentication step with various cloud providers. I need the ability to restart some independently after making code changes. It's just a very complicated system.
I'm sure the launch can be fully automated but it's kind of at the edge of not worth automating because of how relatively infrequently I need to restart everything... Also the CEO doesn't like to make time for work which doesn't yield visible features for end users.
I actually handed my resignation a month ago, without another job lined up. It became too much haha. Good practice though. Very stressful/annoying.
I remember, at the turn of the century (was is 2001?) when Microsoft was touting "weak coupling" achievable through "web services" and demoing the support for SOAP in Visual Studio.
To me, that was the strangest idea - how could you "decouple" one service from another if it needs to know what to call, and what information to pass and in what format? Distributing the computing - for performance, or redundancy or security or organizational reasons - that I can understand - but "weak coupling" just never made sense to me.
Yeah it's a case of falling in love with the solution, not with the problem.
The real reason for tight coupling is simply complex interfaces. That means a range of things; complex function signatures which rely on highly specific parameters (e.g. live instances instead of raw primitive values or raw data) or return complex values instead of raw information "here's what I did". It can also mean complex API parameters and response payloads. Ideally, complex processing should be hidden behind simple interfaces which don't encourage micromanaging the module/service. If the interface is as complex as the processing behind it, that's a design failure and will lead to tight coupling.
Separating code into modules and services may be intended as a way to encourage developers to think about separation of concerns so that they may end up designing simpler interfaces but it doesn't seem to help certain people. Some see it as an opportunity to add even more complexity.
Yep, one of the minor details the micro service fan club don't talk about much.
Firing up the whole mess and debugging one or two of them locally is always a major pain, and god help you if you have no idea which services to stub and which to debug.
Something I've felt is missing is a developer orchestration layer that makes it really easy to define the set of services like a docker-compose but just as easy to switch implementations between container, source, or remote.
Sometimes you need them all from source to debug across the stack, when you don't you might need a local container to avoid pollution from a test env, sometimes it is just fine to port-forward to a test env and save yourself the local resources.
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.
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.
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.
Try CUDA in a Docker environment. Yesterday it took all day long to download an Ubuntu image (5.27Gb) and its Python dependencies (another few Gb) to install Pytorch. I've probably wasted 10Gb of bandwidth just to have the environment up and running. Fortunately in the meantime I wrote 90% what I needed to do. Oh I forgot that I still need to download a couple of hugging face models. Nice.
Was Windows a requirement or your own choice? Asking because I have seen people unwilling to switch to a GNU/Linux VM or boot into GNU/Linux and then forever struggling with their setup, while other people on the team used GNU/Linux or MacOS and didn't have nearly as many problems.
Requirement. Had to use Azure too. I use Linux at home.
>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.
How do you propose we do this?
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
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.
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.
So Microsoft's everything and the kitchen sink approach?
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.
Docker sandboxes execution so it kind of helps as well?
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.
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.
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).
Discussed at the time:
A 2024 plea for lean software - https://news.ycombinator.com/item?id=39315585 - Feb 2024 (240 comments)
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?
Of the three great programmer virtues of Larry Wall, only laziness remains.
For those who, like me, only knew Larry Wall’s quote “Lazyness is a virtue”, here are all three:
https://thethreevirtues.com/
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.
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!
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."
Scrum points are about engineering controllability, rather than performance. But that's a complexity most don't get.
Exactly
And because it is based on nothing, you can just lie about it
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-i...
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.
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.
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.
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.
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'.
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.
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.
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.
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?
>do you really want to implement your own json parser?
On the recreational and creative side, maybe, but not as much as coming with an original exchange format which is a better feat to the specific case at hand.
On a professional side, if JSON support is a burden engraved in the specification so be it. Then having the transformation of the PL native data structure back and forth to various other formats shipped in the standard library is really the best that can hoped. As second best case it is having a single clearly preponderant and well maintained library. Otherwise, bet among a plethora of possible libraries is becoming less attractive compared to building something internally brewed.
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.
The current usage pattern means that you end up with multiple different JSON parsers linked into your product, multiple XML parsers, etc ...
It isn't that hard to write a JSON parser (especially when it targets a specific application).
The part you are missing: If something in the dependency isn't working as you'd like at some point later, making your code work as you desire may be dramatically more difficult than if you hadn't brought it in.
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.
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.)
One should draw a different line depending on the situation. That's where the engineering comes in. There is no silver bullet. We should still be suspicious and judicious about every single dependency.
Reply to the child
> So with infinite resources it would be best to write everything from scratch?
Re-read the parent and the other replies: A critical point you are missing is your interlocutor's practical mindset in contrast to your idealistic one. This is about making engineering-mindset tradeoffs; they vary depending on the specific scenario. The answer to your Reductio ad absurdum is yes, but I believe that side tracks rather than elucidates.
So with infinite resources it would be best to write everything from scratch?
This is not a black-or-white situation. There's no need to only go to one extreme or the other.
You have made your normative assessment very clear, but I haven't heard of where and how do you draw the line.
EDIT: Can't post any deeper, but the child can see that no such "statements" have been made.
The explicit re-statement: There is no general line to draw of whether to use a dependency, or write code internally using a language's primitives (Or already-used libs); it varies based on the situation, and there is a high degree of subjectivity in each of these choices.
So what do you subjectively consider when making this choice?
Some examples:
A good dependency solves a well defined problem with a direct API towards it, so yes, if the dependencies you talk about aren't high quality then yes, don't use those.
Please re-read his or her replies. I will (re) state it explicitly if you don't see it, but I believe you will find it.
Perhaps a better title would be "Supply chain vulnerabilities and attacks are software's biggest vulnerability".
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.
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.
> Every Linux distribution is different
A distribution is just a collection of software to handle common needs. Most are quite similar: systemd, coreutils, glibc, dbus, polkit, pipewire/pulseaudio, and a DE, typically GNOME or KDE. You'll expect to see them on Debian, Ubuntu, Fedora, Nix, Arch, or anywhere else except Void, Alpine, and Gentoo. The only meaningful difference is typically the package manager. We have more standardization in the Linux ecosystem then ever and equally as much bloat, both thanks to systemd.
> Surely it would be better to concentrate on fewer languages and make those more adaptable.
Programming languages are a combination of tools and notation. Different domains have different needs and preferences. We don't lament quantum physicists using bra-ket standard linear algebra notation. Unlike notation, there are material reasons to use one beyond clarity. Some languages support deeper static analysis, some prove complete theorems about your specification, some are small enough to embed, some are easier to extend, and some exist only within a narrow domain like constraint satisfaction. We can add macros or introspection to a language, but in doing so it will fall outside a domain that might value predictability or performance.
> Now take the huge numbers of programming languages out there
I took data from the 2024 Stack Overflow survey filtered for professional developers. The median release year for languages above 25% market share is 1994. The youngest serious language on the list is Swift, dated 2014. I don't think this is evidence of a growing number of programming languages.See converted data below. The release year was augmented by o4-mini.
Right, you've given me a reply I'd expect from programmers and Linux uses. I say that as some who has done programming and that I use Linux as my preferred OS.
I don't know why I mentioned Linux here because every time I do in such comments it distracts from the main issue, we Linux users have very fixed and firm opinions about such matters.
Despite your comments, which I essentially agree with (at least in principle), I cannot see rhyme nor reason why there are so very many Linux distros. Yes, there'd be good reason if they were one-offs for a specific application, say in embedded systems etc., but to have so many widespread and in the public domain makes little sense to me. It not only causes confusion amongst users, especially novices, but also spreads human effort widely that would be otherwise better spent on developing fewer systems—it's the more hands make light work philosophy. For the same reason it's why Linux has been so slow to take hold on the desktop. Yes, the usual hardcore Linux user who knows Linux well says 'who cares, that's the least of our worries'. For some odd reason they don't care that the Linux ecosystem would be better off with a more cohesive and unified approach to development.
Even with that said, Linux is forever changing, new kernels come out so frequently that it's hard to find two Linux distributions with simultaneously the same kernel code. No matter how one views it, that load puts a constant strain on bug finding, security testing, etc. Frankly it's a mess, if for no other reason that so many versions are a nightmare for administrators. All these updates cause lots of extra work for all those who don't work in tightly controlled environments that have rigid/strict update procedures. …And that's many of them.
Leaving me out of the argument for a moment, I'd reckon many of the Linux fraternity would object to you lumping Arch with say Debian in the one sentence although they'd likely agree with you over Gentoo etc. That said, why then can't Linux have a single package manger? It's a damn nuisance that it's not so. As usual, not enough people can agree to reach a unified consensus (and they disagree for very questionable reasons). And it's why in many instances we've had to resort to messy kludged solutions such as flatpack. I've more but I'll stop there.
"Programming languages are a combination of tools and notation. Different domains have different needs and preferences."
Why? Yes, I've seen many reasons but I've never seen it justified with solid argument. Most of those reasons arise out of historical happenstance, and or favouritism, or that 'we've always done it that way' syndrome. As I said, programmers have an investment in learning and they don't want to see it made obsolete. Whilst that makes sense to them, it doesn't go any way towards solving the chronic software problems as outlined in the IEEE story.
Let's look at the number programming languages problem a little further. A quick search finds this quote on the CLRN—California Leaerning Resource website:
"According to The International Organization for Standardization (ISO), there are approximately 14,000 programming languages out there. However, this number is often disputed, and different sources may provide varying estimates. For instance, Wikipedia lists over 23,000 programming languages, while Rosetta Code, a website that aims to document programming languages, claims to have data on over 6,000 languages."
That makes me shudder.
OK, lets whittle that down to something more reasonable. Some references claim the number of well-known languages is upward of 700, with between 200 and 400 being those most commonly used. Others say the most frequently used languages number upward of 50. How correct that is and how much of those numbers can be put down to programmers' favorites I cannot say (I only know a few, Lisp, Fortran, C and a few others, so I'm not qualified to speak for those others). I would suggest however that a rational approach would reduce that number down to many fewer than we have now.
To test that hypothesis one could begin with a mathematical analysis of each language. Perhaps the formal mathematical logic à la Whitehead and Russell's Principia Mathematica would be a good place to start as not only the mathematical structures of a language could be tested for coherence and correctness but also so could its grammatical syntax. Possibly there are even better ways of going about such an analysis but I've not given them much thought. Little doubt, AI will rationalize all this in the near future irrespective programmers' wishes.
Suffice to say, until those analyses are done I remain unconvinced that all those (at least common) languages are needed. Preference and favoritism may drive the current status quo but it's not a logical way to proceed and to properly tackle the problems outlined in that story.
I see a common thread in that comment: there's too many distros, there's too many languages, there's too much software. But there's no central authority telling people to make them. You can't force people to not reinvent the wheel; that's hubris, the third virtue of a programmer, as well as parallel invention.
If you base your solution on top of something else, like writing a DSL in Lisp instead of starting from scratch, it will still become a new language as it diverges, like Coalton. Otherwise we'd say Perl isn't a language, because its interpreter is written in C.
If these tools weren't needed, nobody but their author would use them. There's a genetic hill climb happening in every sphere of life, from film and poetry to science and programming, where every new thing either sets a new threshold of goodness, or is forgotten when it fails to. Sooner or later things stabilize, when the new solution is not better enough to outweigh the old one: we used to see many version control systems, but only Git remained, because for all its flaws, something like Jujitsu or Pijul weren't as much better than Git as Git was than SVN. We measure how close we are to convergence not by the size of the population, but by the average age of the used solutions. By that metric, software is cooling.
There is no problem to solve: nobody is writing enterprise software in a bespoke SKI-combinator derived language they found on Rosetta Code, nor paralyzed by choice between 275 Linux distros to put on their server. The duplication of effort is a cost offset by dysfunctional application and maintenance of solutions designed by committee. Simplicity does not precede complexity, but follows it.
"…there's too many distros, there's too many languages, there's too much software. But there's no central authority telling people to make them."
You are right, there is no central authority telling people what to do and what software to write. And you are correct "you can't force people to not reinvent the wheel…".
What can be done however is to mandate specified software that's gone through rigorous testing in certain buisnesses, government, utilities, the military, critical engineering—aircraft, nuclear, and so on. There's already been a bit of this with Ada and the military but it's miniscule compared with what I am advocating.
Think of it this way: no matter what country one is in all electrical outlets are the same and comply with strict electrical standards for that country. That's not to say there is only one standard worldwide but there are far fewer than if it were a free-for-all as it is in the software industry.
You don't stop people from doing anything, reinventing the wheel or whatever—instead you make it unlawful to supply sofware to those vital entities that does not comply with those specified standards (as set by the ISO, etc.). Outside that realm programmers can do what they want but if they want to play with the big end of town then they'll have to play strictly by the rules.
We'll get to this stage eventually, but it's taking undue time.
As you've said, "Sooner or later things stabilize, when the new solution is not better enough to outweigh the old one…"* but the software industry as a whole is nowhere near that stage of development. Individual program may have reached that stage of development, but in a global sense the software industry is still decades behind the professional standards of other well-established professions (don't take my word for it, just consult the literature).
Right, that sounds authoritarian and something a dictatorship would do. But not so fast: those electrical standards to which I referred were only mandated by govermnents after the free-for-all chaos of the early electrical era where industry could not or would not adopt common standards. . The same applies for other disciplines, electrical engineering has any number of rigorous standards in addition to the example I've already given, same with civil, chemical engineering, transport, shipping etc., weights and measures, and almost all of them are tied to national and international standards. Moreover, a large subset is mandated by law for reasons of compatibility/interoperability (shipping containers, etc.) and or health and safety reasons, or for economic reasons, to minimize costs, to stop people being cheated etc.
These standards and concomitant laws and regulations are a fact of life worldwide and in many instances penalties apply for violating them. About the only exception is the software industry, it's no longer young and should have matured by now but it still operates like the Wild West were anything goes.
I say that as someone who has sat on standards committees and been involved in writing standards. Moreover, in my profession if I were to act in the undisciplined manner of much of the software industry, I'd be struck off.
Right, those are harsh words indeed—but they are only harsh for an industry that has never had to comply with rigorous rules and regulations that have been set by law. Whilst other disciplines have learned to accept them long ago the software industry still does what it damn-well wants, and it's done so with impunity from its outset. That has to change.
So you think I'm a self-opinionated crank. OK, let me bring you back to this HN story and think again. Software programmers and developers like to call their work software engineering and themselves software engineers but I'd suggest many in other engineering professions just laugh at the notion. If you don't hear them shouting it out loud it's because they're being polite.
What we in other engineering professions laugh about isn't the skill sets of programmers and developers, we accept there are many very skilled people who work in the industry. The real issue is the laissez faire free-for-all attitude of the industry—an undisciplined industry not bound by strict procedures and lawful regulations. Without regulations and clearly defined rules and procedures we end up with inconsistent results, bugs and lots of mess.
I'd suggested you read this story again then read the document in the link below, it was written nearly 31 years ago and covers the issues I've addressed, it's a SciAm article titled Software's Chronic Crisis. One of its key postulates is that software development doesn't have the disciplined lineage of say chemical engineering and that programmers are more akin to artists than engineers because they operate without industry standard strictures and procedures (such as those set by law).
What's so poignant about that article nowadays is that precious little has changed in the software industry in respect to those matters it refers to. Now ask yourself why is that so given that there has been much development in other areas of software development.
Little doubt the above commet is correct. Look at the way Niklaus Wirth's Pascal lacks widespread support amongst programmers whereas languages such as C are very popular because programmers don't feel constrained to the extent that Pascal constrains them, they feel hemmed in by it. Pascal essentially works like other professions—you must define what you want first up, (the concept, say a bridge) and then draw up the plans and revise them before anyone starts building it. After it's built few if any changes can be made. That's the cultural difference between software development and other engineering professions. It's a fundamental one.
https://www.researchgate.net/publication/247573088_Software'... (best copy—PDF)
https://www.cse.psu.edu/~gxt29/bug/localCopies/SoftwareCrisi...
I agree. Here's a different perspective:
Bloated and crafted software - a rant:
The state of software is the state of the structures of primitive societies: some in cave shelters, some under roofs of sticks and leaves, some in mud huts.
We talk of Cathedral and Bazaar, but there are very few carefully designed Cathedrals of software, and those probably have plenty of barely hidden flaws.
The Bazaars are all around us, jammed together, spreading for miles and miles, tent walls and roofs billowing in the breeze, all awaiting a strong zephyr to carry many of them away, and leave most of the rest in ruins.
What software needs is building blocks. Bricks of uniform size, easily joined together. Concrete masonry units. Tilt-up walls. Trans-oceanic shipping containers (connex, seabox).
Solid, composable, engineered, units. We should be able to pull a well-known and heavily tested package or function to use, just like a contractor would call for a delivery of 200 8x8x16" CMU blocks, and be able to expect they will get just that, with no gaps, weak spots, or broken webs.
But, no , all of us software crafts-folk want to carefully create our very own artisanal version of whatever library functions, that are needed for the project at hand. In a world that could be made of solid concrete blocks, we are crafting our very own adobes, with our own special blend of straw and mud, and we think we have advanced far beyond the folks living in mud huts.
Some of us will say they are master masons, crafting cathedrals out of hand cut stones, each carefully measured and chiseled, and each stone unique. We're still duplicating effort when we could be using commercial off-shelf libraries. And all the while the project deadlines go zipping past as we try to craft our way to local perfection.
All I can suggest as a solution is a multi-government and multi-corporate effort to design and build fairly universal functions, libraries, and packages that are robust, exhaustively reviewed by humans, and tested thoroughly. I won't ask for provable correctness, yet. :-)
Would the result be an Ada on steroids? Depends on who is involved.
Choice of language should not matter. The APIs would matter, a lot. A few competing teams would be a possibility. Passing several existing functions to an AI, with a "do like these, only perfectly" might be useful, or useless.
And yes, then we would have 15 competing standards. https://xkcd.com/927/ (Well, we probably already have at last 1,500, so, go figure.)
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.
Considering the disdain for software which does not have a thousand external dependencies in form libraries and framework is it any surprise?
Is there an OS that embodies this sentiment?
9front, the modern fork of Plan 9.
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.
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.
100% relate to your comment.
>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.
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
Most developers I've met are completely ok with pulling whatever dependency, even is_odd kind of stuff.
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.
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.
[dead]