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