Hacker News Reader

Comment by mwcampbell | Hacker News Reader

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 auto-mount USB thumb drives? Does it do all of the other things I'm not even aware of that are required for a fully usable desktop environment covering a wide variety of machines, users, and use cases? AFAIK, the only Linux desktop environments that come close are GNOME and Unity.

Basically, the world is complicated, so real-world software has to be complicated too.

It sounds like Atom could still use some optimization though.

View on HN

> AFAIK, the only Linux desktop environments that come close are GNOME and Unity.

I'm the project lead of LXQt. All those things you listed can be supported without introducing much bloat at all. In DEs, most bloat comes from pure technical debt. Unnecessary libraries, duplicated code/libs, etc.

Feature bloat is another matter and is more subjective. A lot of it is down to UX.

Fun fact: KDE 4.x depends on ruby in most distros. Do you know why? Dolphin ships with a ruby script to update some folders (don't remember what it does). Nobody runs it. That's it.

> Fun fact: KDE 4.x depends on ruby in most distros. Do you know why? Dolphin ships with a ruby script to update some folders (don't remember what it does). Nobody runs it. That's it.

Why did they allow an additional dependency on Ruby in? It seems like perl or python would be the more logical choice, given they'd already be on the system (heck.. maybe bash?)

Probably because a Ruby activist wrote a cool script and no-one cared about the implications of a new dependency at all.

I fear many projects seems to take the infrastructure and manpower of large distros for granted these days.

Bash would have been more appropriate, yes. I don't think the author of the script even thought it was going to be run by users, but some debian package checker probably flagged ruby as a dependency and there it was.

> Bash would have been more appropriate

A script that is compatible with POSIX Bourne shell (/bin/sh) would be more appropriate. FreeBSD, for example, does not come pre-installed with bash. If you want cross-platform portability, this is a better default.

don't forget about backwards compatibility.

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 in general.

Does it auto-mount USB thumb drives?

This isn't even the job of the desktop environment, it's the job of a dedicated device node manager, which the DE may call into. It's completely orthogonal and can be accomplished even without so much as a display server, because it's a different layer.

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 requests for the hardware database).

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.

The real problem with NFS is that NFSv3 is easy to implement but insecure and has scalability issues (e.g. users can be in no more than 16 secondary groups) while NFSv4 is complicated and requires a complete Kerberos infrastructure (which is more complicated than rocket science!) to utilize in a way that works around the limitations of NFSv3.

There's much better network file systems but because of many factors (boat/complexity being the biggest) their adoption is minimal.

Once you move beyond single-user/simple read/write permissions there's really no easy to avoid complexity. It's just the nature of the beast that is sharing files over the network in a way that appears native to the user.

If I don't mind not having those features, can I have the light version?

Just make sure your use of the light version won't impact anyone else who would mind the missing features.

For example, suppose you're developing an application, and you want to use a lightweight GUI toolkit, or roll your own as Spotify apparently used to do. Unless the toolkit is just a thin wrapper over the underlying OS's native GUi facilities, like wxWidgets or SWT, the resulting application is very likely to have accessibility problems, unless you do the hard work of implementing the accessibility APIs for your target platform(s).

The real problem is precious snow flake developers who do not care about bloated code, who think it becomes the dev ops problem to go and get bigger aws instances, or newer macs. Shit attitude to your work will always show. If engineers, plumbers, electricians, doctors, chefs - basically any other field of employment took the same cavalier approach to the end product, we would right castigate them. But somehow, we give devtards a free pass. Why?

And, for some reason you forgot about KDE...

I didn't forget about KDE. Last time I checked, it fails on accessibility.

Reply on news.ycombinator.com