Live data from Hacker News

Software bloat makes me sad

remarkablyrestrained.com

61–70 of 165 posts

Re: Software bloat makes me sad

#61
post #54

"There are very little tools available to to help the user select unbloated software" Actually there is a whole community around this http://suckless.org/

It's a funny idea of sucking less where any user configuration involves editing config.h and recompiling.

Which is easier? Re-running make, or having to write and induce another library to read configuration files?

Configuration files introduce a new point of failure (file not present, file corrupted, file not readable), a point of slowdown (how long does it take to read the file from disk, how long does it take to parse and load the file), and a point of complexity (parsing even ini files is pretty complicated, if you want to support the myriad of ways we write them).

All of this for values which change once every... how long? Once a year? Once an install? Or for most configuration values, never?

I still use configuration files, because I'm OK with including third party libraries... but I can certainly understand why some people may not be.

Re: Software bloat makes me sad

#62

Software bloat as such doesn't make me sad. Free open source software bloat makes me sad. However, that bloat is winning on its own merits. For instance, GNU/Linux distributions which are minimal are not popular. The popular ones tend to be the bloated ones. Vim has gotten a lot bigger in 20 years, yet I'm not going to jump ship to a smaller vi implementation. FOSS makes us confront the fact that we actually seem to…

Because bloat is like government. Multiple people might agree that there's too much of it, but they don't necessarily agree on which parts should be gotten rid of.

This. As always, there's a relevant xkcd[1]. Features that I might decry as bloat are probably someone else's "necessary, to be preserved at all costs" features. If you want to cover a large number of use cases, you have to include all of them. And with that comes bloat. There's a reason why even a minimalist CLI-only Linux installation requires more than 24MB of RAM when Windows 3.1 runs on 3MB - the Linux kernel is capable of a hell of a lot more.

[1]https://xkcd.com/1172/

Re: Software bloat makes me sad

#63
post #17

Atom and Vim (and imo even Ubuntu) aren't good example of software bloat. While they might be slow and use a lot of memory, they're usually shipped with basic functionality and more functions can be added and removed at any time. Good examples are iTunes, Office, iOS and Android (the latter two are usually shipped with non removable bloatware).

In my (controversial) opinion, Atom is a great example. It includes/requires Nodejs, an embedded web browser, and runs Javascript, to run a rather basic text editor.

And in many cases, it's slow, CPU hungry, and memory intensive. Those three characteristics are the very definition of bloat to me.

Re: Software bloat makes me sad

#64

I've previously decried bloat too, but I find that my rants against software bloat are based on emotion, not reason. So, looking at this rationally, consider your favorite lightweight window manager or desktop environment for Linux. Is it fully internationalized, including support for CJK input methods? Is it fully accessible to users with disabilities, e.g. blind people and people with mobility impairments? Does it…

Is it fully internationalized, including support for CJK input methods? i18n is an orthogonal service that the DE or any other program may call into. Is it fully accessible to users with disabilities, e.g. blind people and people with mobility impairments? Screen readers and screen magnifiers are orthogonal services that the DE may make accommodations for, though some DEs may be lesser fit for users with disabilities…

Not sure if device node managers are the right place either, as not every mount is related to a local device.

NFS in the classic cross-network *nix mount. And depending on available software (FUSE and related) you can mount the likes of SMB/CIFS shares, FTP servers, even SSH/FISH can be used via a mount.

Re: Software bloat makes me sad

#65

Earlier quoted context omitted.

If I want to start Microsoft Word right now, here's what I have to do: I press the Windows key, type "word", press enter, and then wait for it to start. That entire process takes three seconds; I just timed it. Now that Word's been run once already, I can start it again in less than one second. That compares pretty favorably with the process of finding a floppy disk, inserting it, and then finally running a command o…

That's probably because you have SSD, but anyway; I could do the exact same process 10 years ago (with "winword" instead of "word"), get similar response times, and yet the software was an order of magnitude smaller and more responsive. And it's not like Word gained many actually useful features during that time.

>> And it's not like Word gained many actually useful features during that time.

Then use the 10 year old version! Unless, of course, one of those few "actually useful features" is something you can't live without.

A lot of people use Word for a lot of use cases. The value of an added feature that someone needs always trumps the performance cost of adding it until the performance becomes so bad that it becomes the reason that other people stop using it.

Re: Software bloat makes me sad

#66

One thing that strikes me is the explosion in dependencies in most software. I'm guilty of this, too. I've seen plenty of examples where an entire library or framework is added to a project just for a couple of features. Add a few libraries like that and suddenly you have a few megabytes of additional libraries, where maybe 90% or 95% of the features will never be used. A good article a while back looked at common un…

A good article a while back looked at common unix utilities, comparing the size of commands like cp from the 1980's to the present. Most of the bloat had to do with features that almost nobody ever uses.

That was actually a talk called "Bloat: How and Why UNIX Grew Up (and Out)": https://www.youtube.com/watch?v=Nbv9L-WIu0s

Well worth a viewing.

Re: Software bloat makes me sad

#67
post #6
post #2

That's pretty much the only reason I cringe every time somebody writes a piece of client code in golang. While I really like the language itself, statically linking everything is creating exactly what this article describes. Burn karma, burn. I don't care.

I dont really understand the link between software bloat and static linking...

When you statically link and executable, all the code from the libraries that it links to (at least the code that is directly or indirectly called by the application) is bundled into the binary. If you have 13 applications running that each statically link in 60% of a 2MB library, then you're using 15.6MB of memory where with dynamic linking you only need 2MB.

Re: Software bloat makes me sad

#68
post #6
post #2

That's pretty much the only reason I cringe every time somebody writes a piece of client code in golang. While I really like the language itself, statically linking everything is creating exactly what this article describes. Burn karma, burn. I don't care.

I dont really understand the link between software bloat and static linking...

[deleted]

Re: Software bloat makes me sad

#69

I'm not really convinced. Leaving aside the argument about whether or not software is 'bloated' at all, or what 'bloat' actually means, this in particular stands out: “wouldn’t it have been easier not to create the problem in the first place?” It would seem obvious that the answer to this is indeed “yes”. It doesn't seem obvious at all, especially considering the implicit assumptions about whether or not bloat is act…

I came to believe there are two types of programmers - those who get emotionally upset about ineficciencies, and those who couldn't care less. I'm in the first camp, so I understand the feelings of the author perfectly. You say your computer can do "more things much faster" than before - just imagine how many more things, how much faster you could do if the software didn't bloat itself up almost at the same pace as t…

I'm one of these developers with powerful machines and I routinely kill both Spotify and Skype because they use obscene amounts of memory and CPU power for programs that are just idling. Just having a chat program and a music player open should not take over 400Mb of my RAM. I might have plenty of RAM, but I have no problem using it more productively.

Re: Software bloat makes me sad

#70
post #55
post #22

There is another side of extra resource use that I don't really see addressed except in the mobile space: ecology. Even though my computer can run all applications without a hitch, it is still very wasteful to constantly use CPU power because of technology choices or plain laziness. As an example, Spotify and Slack are two applications that seem to use most of my CPU after Chrome. Spotify and Slack combined seems to…

It's not that they have poor algorithms or whatever, it's that they're part native, to handle the desktop interaction and the rest is a bunch off html/css/JavaScript running in an embedded browser. At least that's how Spotify works. The problem is that our tools for making multiplatform native GUI's suck so bad we'd rather just embed an entire Web browser into everything.

There are some okayish cross platform frameworks, such as QT and even JavaFX. One of the main complaints of cross platform GUI's has been that they don't work like native applications. But for some reason nobody cares when the app works like a single page web app, which in many cases is a lot worse than even plain old Swing apps. Which at least supports right-click properly.

I think the main reason that node-webkit and what-not are popular, is because of web developers moving to native app development. It's really easy to get started that way, and you can even share code with your web app. Where something like QT has a really huge learning curve for programmers transitioning from Javascript.

About poor algorithms. I actually worked on optimizing a well known web browser for a couple of years. And most of the stuff we did, was because of really bad Javascript code. Even though it seems gluttonous to embed a web browser in applications, and even insecure, it doesn't have to be as bad as it is, especially with a simple application like Spotify. This is going on a bit of a tangent, but every frontend programmer should at least learn how the browser actually works, a nice site for that is http://jankfree.org/

Post reply on HN