Live data from Hacker News

Software bloat makes me sad

remarkablyrestrained.com

111–120 of 165 posts

Re: Software bloat makes me sad

#111

Earlier quoted context omitted.

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.

NFS grossly violates POSIX file system semantics, so it's better to use something like 9P/Styx, instead. Unix systems really aren't good at abstracting local and remote mounts and binds into a singular resource, but the parent poster's scenario was implied to be a local user hotplug, which is what device managers largely do (if even that, udev these days just maintains the /dev/disk/* symlinks and handles query reque…

it's better to use something like 9P/Styx, instead

Who does this, though? Are there reliable adoption numbers? NFS semantics are wrong in well-known, familiar ways and it ships everywhere, making it still quite popular.

Re: Software bloat makes me sad

#112

Earlier quoted context omitted.

I think so too. It's not about ASM snippets; it's about people not knowing what their software actually does. Software bloat isn't magic, nor is it static; your CPU is doing something . If with time application gets bigger and slower, and yet no extra features appear to explain it, it means your CPU is running code that shouldn't be run, wasting its cycles on pointless and irrelevant computations. That's laziness and…

>That's laziness and/or stupidity Or the failure of a large team to properly manage software complexity.

Or higher priority things to work on. Optimisation doesn't come for free.

Re: Software bloat makes me sad

#113

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…

Dart makes a decent argument for a smarter compiler. They've implemented "Tree Shaking" in their compiler: essentially cross-library dead code elimination.

This would probably be quite tricky in Java land where reflection does add new entry points, but it could be used to solve the problem of "I only need this one function from this library, don't compile in anything else".

I was personally quite surprised when I ported from code from Node to Java/Groovy and the resulting shaded JAR was > 70MB, I think at some point it peaked above 110MB. I don't know what I changed, but it's down to 35MB now. But the code that we've written in house on that codebase boils down to 1MB. But besides figuring out that I don't want to make local builds I scp to staging (because scp is terrible), these numbers are all completely equivalent for writing server-side software that runs on dedicated machines.

We could certainly make it more efficient, but there's exactly zero business case for it.

Re: Software bloat makes me sad

#114
post #97
post #88

Earlier quoted context omitted.

> But doesn't static linking JUST link in the used features of the linked libs? No, not if it works like it does in C and C++. Lisp used to do that, back when Symbolics still existed; it was called tree-shaking, as in "shake the call graph tree to see what falls out". The main function calls functions FOO, BAR, BAZ, which call FROTZ and QUUX, which call... and remove everything not in that tree. Of course, this gets…

In C and C++ you can conservatively eliminate unused code for statically linked libraries using --gc-sections and -fdata-sections. Go uses the Plan9 compiler architecture, which means that its linker knows more about the code and is responsible for more optimizations than its Unix equivalent, so it quite effectively eliminates dead code. Of course, libraries are often highly coupled within themselves, so not much cod…

Interesting. I didn't realize there had been any substantive new work done on linkers in decades.

Re: Software bloat makes me sad

#115
post #95

Earlier quoted context omitted.

That doesn't excuse resource inefficiency, which is really the main point. The issue of size can be further addressed by separation of mechanism and policy, and building for extensibility.

Are you sure there's inefficiency? Do you have specific points in the code or behavior which are obviously inefficient, or does it just feel "too big"?

ahem MorkDB.

There's tons of code in Mozilla that isn't necessary to do the one job the browser was built for.

I don't need code that manages bookmarks. At all. I don't need code that stores history for years. Honestly, I don't /want/ cookies persisted /at all/. I don't need themes to browse the web, and a reorganizeable UI is /never/ what I'm looking for in a browser.

I don't need WebGL. I don't need Canvas. Hell, I definitely don't need syncing of all this extra bloated data around to services somewhere in the 'net, either. Frames? What about floating frames?

Half this stuff is better left to tools that are built for it, the other half is junk I don't need, or is junk that actually creates more problems than it solves.

Re: Software bloat makes me sad

#116
post #54

Earlier quoted context omitted.

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 w…

Parsing config files is not hard. A simple key-value flat file is often more than enough. You don't need external libs for it, but it does add additional complexity.

Suckless is about minimalism and speed, and if you want speed, you don't want extra junk like config files clogging up your code's mainline.

Re: Software bloat makes me sad

#117
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…

I'm conflicted on this.

On the one hand, I wonder how much of the wasted CPU cycles can be attributed to carelessness that could easily be avoided, or caught early, if we developers deliberately used underpowered hardware for our own machines. Speaking for myself, my main workstation, where I also do most of the testing on my desktop apps, has a Core i7-4770 processor and 32 GB of RAM. Maybe if I used something more modest, like an ultrabook with only 8 GB of RAM, I'd be more likely to notice when I'm carelessly writing inefficient code.

On the other hand, as others have argued both on this thread and elsewhere, there's a trade-off between machine efficiency and developer productivity. We may argue that it's wrong to waste machine resources when the machines in question don't belong to us, but then again, developer productivity means we can crank out more features that drive sales and make users happy.

Re: Software bloat makes me sad

#118

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…

We can write tools that stop using idiotic ideas like dynamic libraries and only link in symbols that apps need.

If you only use one or two features out of a lib, why are you dynamically linking them in? If you do a static link, the linker can at least remove most of the bloat you don't use.

Re: Software bloat makes me sad

#119
post #3

The notion of 'premature optimisation is evil' is partly to blame; It's not a terrible rule, but it's much better with conditions applied. i.e. apply some intelligence/judgement to where you use optimisation rather than just lazily following some rule.

Premature optimization is evil -- when you don't have a design for how your system will work.

The axiom is only valid in those cases because if you've designed your system well, the points for optimization are already obvious and the code can be written mostly optimized the first time round.

Re: Software bloat makes me sad

#120
post #95

Earlier quoted context omitted.

Are you sure there's inefficiency? Do you have specific points in the code or behavior which are obviously inefficient, or does it just feel "too big"?

ahem MorkDB. There's tons of code in Mozilla that isn't necessary to do the one job the browser was built for. I don't need code that manages bookmarks. At all. I don't need code that stores history for years. Honestly, I don't /want/ cookies persisted /at all/. I don't need themes to browse the web, and a reorganizeable UI is /never/ what I'm looking for in a browser. I don't need WebGL. I don't need Canvas. Hell, I…

Then use something else. It's not like you don't have a choice.

https://en.wikipedia.org/wiki/List_of_web_browsers

Based on your stated requirements, perhaps you'll like Dillo.

http://www.dillo.org

Post reply on HN