Has modern Linux lost its way? Some thoughts on Jessie
changelog.complete.org
changelog.complete.org
That aside... I think it's pretty clear that modern Linux is not losing its way. If you go back even five years, and complain that your latest pre-release version of Debian won't suspend properly because it needs a password, you'll get laughed at by all the people who try to suspend their laptop and have it crash in some way or another.
We're now in the uncanny valley of software progress. If suspend weren't working, you'd feel hardcore and learn it and deal with it. If it worked perfectly, then you wouldn't think about it. (What was the last time you thought about how OS X or Windows does suspend, or handles permissions on mounted drives, or whatever? When was the last time you read a manpage about launchd or one of its helpers? Hint, the manpages are useless.) If it has almost all the complexity to work perfectly, you get neither of these benefits.
But it would help things immensely if someone were to document all this, from a busy sysadmin's perspective, not from an upstream developer's. There are occasionally manpages, but they're written like git's. Lennart's "systemd for administrators" series is a start, but that's more of a pitch for why you should want to build your new systems on it, and it only covers systemd. Docs on how to figure things out when they go wrong would be most useful.
Every. Freaking. Time. That is, since an employer equipped me with a cheap Dell. It looks like it suspends, but one time out of ten it'll come straight out of sleep and cook in my bag.
I've only used Thinkpads, with Linux, for my own work before, and they suspend multiple times a day without a problem ever. So this was a big a-ha moment for me regarding Linux usability complaints, to see what it is that people actually try to do.
And I think that may be the crox of the issue.
The recent changes to the Linux middelware ecosystem has added a mass of new automations.
Supposedly making people's lives easier, but for many producing issues that remind them of why they moved from Windows to Linux in the first place.
# cat /proc/acpi/wakeup
Device S-state Status Sysfs node
LID S4 *enabled platform:PNP0C0D:00
...
# echo "LID" > /proc/acpi/wakeup
# cat /proc/acpi/wakeup
Device S-state Status Sysfs node
LID S4 *disabled platform:PNP0C0D:00
...
It's not a one-shot setting though, as the desktop environments reset it before suspending. As far as I can remember, I put a script in /usr/lib64/pm-utils/sleep.d to make it permanent.Every time I had to write a lauchdaemon to implement the equivalent of what would be done in cron or inetd.
But I do a lot of Mac sysadmin work.
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.rethinkdb.plist
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.rethinkdb.plist
cassandra
To have launchd start cassandra at login:
ln -sfv /usr/local/opt/cassandra/*.plist ~/Library/LaunchAgents
Then to load cassandra now:
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.cassandra.plist
To have launchd start redis at login:
ln -sfv /usr/local/opt/redis/*.plist ~/Library/LaunchAgents
Then to load redis now:
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.redis.plist
Or, if you don't want/need launchctl, you can just run:
redis-server /usr/local/etc/redis.conf
.. and so on and on it goes .. seems like the more things 'improve', the more they stay the same.'gem install lunchy' to install it. Your commands would have been eg 'lunchy stop rethinkdb', 'lunchy start rethinkdb' - it matches on substrings. The ln step is handled slightly differently - it doesn't work with lists of files, and installs to two different places, but this is roughly equivalent:
for f in /usr/local/opt/cassandra/*.plist; do lunchy install -s $f; done
(here the -s flag is symlink rather than copy)I wish there were some sort of Guild of OS Developers that could be relied on to enforce the inclusion of standardized tools in all OS's released by its members. It seems that a lack of an organizing body to enforce these standards - or in Apples' case, any way for the public to influence the standards they dictate - is a real problem with OS development today.
Nevertheless, good to know about lunchy. I will try to remember to check it out some time.
$ brew info cassandra
cassandra: stable 2.1.2
http://cassandra.apache.org
Not installed
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/cassandra.rb
==> Caveats
If you plan to use the CQL shell (cqlsh), you will need the Python CQL library
installed. Since Homebrew prefers using pip for Python packages, you can
install that using:
pip install cql
To have launchd start cassandra at login:
ln -sfv /usr/local/opt/cassandra/*.plist ~/Library/LaunchAgents
Then to load cassandra now:
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.cassandra.plistIt appears that "run a python program as root on a schedule regardless of if anyone is logged in" is no longer possible on a Mac. Or rather, me and my CS PhD aren't capable of figuring out how to do it. I just keep a terminal window open at all times as a reminder to occasionally manually run the script.
It's the reason I started preferring linux in the first place - I run into bugs on windows and mac os x, and I can't make a system fully the way I like it, except with something like linux. But I digress.
Things also work fine now, but during the transitions from "udev and group permissions" to HAL to udisks / consolekit to systemd / logind, stuff broke. It seems like the same group of well-meaning people worked on HAL then dropped it, worked on consolekit then dropped it, and ended up in the systemd ecosystem.
The various desktop / filemanager projects that started supporting one of these previous systems, to be more compatible with the others and theoretically make things easier for users, sort of got pulled from one to the next, whether it was better or not. Because the previous was unsupported and somehow getting more flaky.
Anyway... it's not the end of the world, there are still other distros and more minimal projects, and it's all still open source. There are even people trying to maintain independent udev and consolekit (the end of the usb-drive-access line, if you don't get on systemd).
But it is annoying that there are these people and projects, that have a lot of influence on other prominent, "classic" projects, that are trying to make a linux system like windows or os x, and adding huge amounts of coupling and complexity. All because they want all sorts of things to "just work" and attract the "common user". Both of these goals are futile, and the costs paid are for naught.
There are benefits to running Arch, but 'just works without breaking' is not something it's good at.
In the long run though, I'm glad to have made the switch. I find it much easier to maintain. I also use FreeBSD at home and while I love it too, some aspects of maintaining it don't feel as nice (I suck at writing init scripts apparently).
http://osxdaily.com/2013/01/21/mac-slow-wake-from-sleep-fix/
Though I think the user experience could at least be significantly improved.
All because they don't want a sodding LED on the machine
(I'm running Ubuntu 14.04 with Gnome 3.12)
Fix: just remove the USB drive entry in /etc/fstab, then it works like a charm again.
Someone not installing from the USB key will not see the issue. As the issue is known it may have already been fixed in the latest Jessie installer (didn't check).
* before the switch to systemd everything "just worked" on Debian and you didn't have to deal with this
* during the switch to systemd there were situations when switching was worse than staying with sysvinit (e.g. system wouldn't boot anymore due to entries in fstab).
* then the situation started to improve in systemd at the detriment of those who stayed with sysvinit (no suspend button in KDE when not on systemd; policykit not working; virt-viewer shows a permission error on MATE, but not on KDE, etc.)
Whether you switched to systemd or not you noticed that something broke. That was always a possibility with unstable of course, but usually fixing it was quite simple. In this situation it was worse because you first had to find where the problem lies, which means understanding all the complex interactions of a desktop's components. Searching for documentation isn't very easy either, because sometimes there is no documentation except the source code and configuration files themselves. Fxing things isn't easy as downgrading or fixing a configuration file either: usually you have to patch the applications, or wait for others to do it.
All this is made worse that systemd tries to do too many things at once: PID1/service supervision, initscripts, dbus stuff for logind, policykit/pam, syslog etc. Some people have strong opinions on PID1 and initscripts (myself included) and don't like all these forcibly changed at once.
I wouldn't be opposed to service supervision (I like runit), or a better initscript format, but I'd like to have a choice of changing that without breaking unrelated things (like policykit on the desktop). OTOH I don't really care how consolekit/policykit/dbus is implemented as long as it works, and as long as I'm not forced to change something unrelated, like how I boot my system.
Also if these were all independent applications that didn't require the rest of systemd troubleshooting would be easier by switching out components one at a time. Things like systemd-shim/cgmanager attempt to do that, but that is more like a band-aid than a properly designed, modular application.
I recall trying to set up dbus on a minimal install, and finding that often when something borked, it borked in odd ways. This in that a signal could seemingly get stuck inside dbus, as one party thought it had sent the relevant message, the other party never responded in kind, and the only real way to get everything unstuck was to kill dbus and all relevant parties (pretty much a reboot of anything above the kernel these days).
With something as seemingly simple as mounting a thumbdrive, the process goes something like filemanager > udisk > pol(icy)kit > consolekit/logind. All that to "verify" that the person sitting at the keyboard has the rights to do "mount /dev/sdb1". And every > in that chain involves dbus. So if dbus borks, everything borks. And dbus is pretty much a black box.
The irony I'm finding these days is that suspend does work, but now the options to turn it off don't.
Then I switched to OpenBSD.
I think it all stems from D-Bus, which has become the primary mechanism of command and control on desktop Linux. To address the OP's initial issue of user mounting disks, it's managed via Udisks, which is mostly accessible via D-Bus.
I have trouble reconciling Unix's notion of "everything is a file" and how a modern Linux desktop operates via D-Bus. Don't get me wrong, I think D-Bus very powerful and flexible. I just wish it was easier to explore and test via file-based tools. Maybe a FUSE layer?
Anyhow, if the OP thinks that Linux was once "clean, logical, well put-together, and organized", I can only laugh at his rose-colored glasses. Linux is and always was a cobbled-together mess of orthogonal paradigms (no better illustrated than by the design philosophy clash of XWindows vs Unix). Maybe earlier Linux was simpler because it was still playing catch-up with other Unix clones out there. Nowadays it's leading the pack in innovation, and so things are changing, and fast. I don't know if documentation really is worse now that it used to be, I'm afraid to fall in the same nostalgia fallacy.
Ultimately, I see this rant as nothing other than "things are different now and I'm scared and confused". Not that I don't sympathize, being in roughly the same place. However, I decided I can't stop technology, and sucked it up and sharpened my google-fu.
I've been using D-Feet and dbus-monitor, which seem to be solid enough. D-Bus does have extensive introspection.
But yeah, in general the state of D-Bus tooling is miserable. Part of it is how verbose it is — which is fine for compiled software, but for interactive use, it really makes you miss the "creat" and "umount" school of thought. Part of it is that there aren't great introspection tools at the command line.
It's a little tool that works really well with dbus services that properly implement introspection. We used it extensively on Openmoko phones to play with our middleware (or when GUI was broken ;) )
Of course, the fact that you need a full DE to easily mount a usb stick as a non-privileged user means the whole thing is already failing hard. This is not how this should work.
This is not true. I use udiskctl (and thus the udisks2-polkit-dbus based machinery) to mount pendrives in a vty on a regular basis.
As a bonus, it asks for my password (the user one, not the root one) if i'm in an ssh terminal instead of a vty, and by configuring polkit i can have it allow me (only this particular user) to put a certain HDD to sleep (and no other actions like giving rights on the block device would do) without root password.
You must have mixed up D-Bus with CORBA.
> It's not discoverable
Try installing "d-feet", it's a nice GUI that will show you everything that's listening on the bus and what objects and interfaces it supports.
I may try Arch, I heard a lot of good from it, but from people who have more time on their hands than me. Right now it is Ubuntu for me and it is working fairly well.
I've had the occasional small technical hitch but the forums[1] are some of the most helpful I've found and that in combination with the standard google-fu/stack exchange approach has made quick work of any bugs I've had.
My favourite thing about Arch however is the AUR[2] which makes installing any small command line tool that you just heard of (on hacker news) as effortless as installing a supported package, even though they're unsupported (officially) they most often work and I rarely find something that doesn't already have an AUR package to build it.
N.B. if anyone wonders, the only other distros I've played around with are ubuntu, debian, and open suse (and I've actually liked them all). So I don't have too much comparison.
[0] https://wiki.archlinux.org/index.php/beginners%27_guide
You know, that's funny. Debian has neven been as pragmatic and apolitical as it's now. Bugfixes never had so little red tape. And yes, they often get lost in political discussion; it's just your memories that are too rose-colored.
(By the way, I'm a happy Debian user. Wouldn't switch to any other main distro, altough a few niche ones look promissing.)
I'm surprised about your issue with the Intel driver, which I've found to be quite stable on Linux, but then I don't do any 3D in Linux. Is this on your System76 laptop? As for mounting a USB drive, that's patently false, see my comment above. Nowadays you can either use udisks, udiskctl (depending on which version distro you're using), or even good old pmount.
I also contest your comment about how political bullshit overruns Debian and Ubuntu. If you think it's different or even worse than before, you're falling for nostalgia :)
I mean, I sympathise with your issues, and I understand the frustration of having to fight something that you'd expect to just work, ("it's 2015 for fuck's sake! Why am I still dealing with this bullshit!?"). Of course, you're doing much more cutting edge stuff with 3D and computer vision, so you're probably tickling the bleeding edge of driver support in Linux. Nevertheless, you've had this class of complaint for 15 years. Haven't you bitten the bullet yet? :)
Add to that that the basic install does not allow USB to be automounted by a user. I did manage to get this one to work after a wasted hour or two, but I don't consider it normal that this is not default behavior or at least very easy to configure. In 2015.
Both these things worked flawlessly out of the box on a Ubuntu with KDE.
As for nostalgia, I actually do not remember stumbling on a case like the intel GPU before: "We are holding bugfixes because we don't like the name of Intel's package". Actually, every time I try to go back to debian, I arrive with a ton of motivation thinking "this time I am going to look deep into the issues and solve them!". This particular issue had no good solution: it would have required me to install the intel driver and accept that my system would probably break at the next big update.
I am used to the old proprietary vs open debate and the horror of binary blobs. Here it is not the case.
The user can then at any moment emulate the actions of a programs towards those files, and look at when it breaks. And this while only using the barest of CLI tools, rather than having to aim something like GDB or strace at the process and hope to catch the tentacle flailing.
Overall, it has been a sequence of constant rewriting, and I don't see an end to it. People who have been using rolling distributions like Gentoo and administer their own machines are the most affected. If one is not using the whole systemd to major DE (KDE, Gnome, XFCE, etc) stack, it is arduous to set up a mounting system which always works. Usually, vfat external disks tend to be immediately writable on mount. Move over to exfat, mtp, ext[234], or another other native filesystem and it is an exercise in exasperation to get them to mount as read-write as an unprivileged user, or even mount at all as an unprivileged user (see https://bugzilla.kernel.org/show_bug.cgi?id=15875).
The only decent program that I have found that works quite reliably is udevil.
I agree that the rewrites all the time were annoying, but I have a hard time seeing systemd developers rewriting the same part of their project over and over now. For better or worse systemd should at least slow churn.
They are developing in Mac but targeting server software or devops tools. So pretty modern, hot and bleeding edge things are happening in there but not desktop area.
GNOME - Always doing some experiment. No application. Just changing shell. No reliable usability. Call me when they are done. One good thing about GNOME is they care about beauty and elegance.
KDE - They just don't care about beauty of ... anything. But their applications are freaking featureful, reliable and developed by people who actually using it. I can feel they are dogfooding. I saw KF5 screenshots. They still don't care about beauty.
ElementaryOS(Pantheon) - Better than GNOME. They are having and developing actual application like geary and midori. You can feel they are actually dogfooding in contrast to GNOME couterpart.
Unity - I like Unity itself. Very long time user. But Canonical lied to us it's stable but actually alpha stage. One more bad thing is it smells vendor lock-in pretty much. Anyway pretty usable and has big ecosystem(community + vendor).
XMonad - At first time, it just looks like another tiling window manager. More I use it, it feels like 'custom desktop construction kit' if you don't mind learning about some haskell. As you all know, 'kit' is about fun and learning more than actual result. So I'm doing still this dumb like window manager ...
Are you trolling?
Geary is a GTK3 application. It's great that people from Elementary are helping out, but basically it's made for GNOME, using GNOME's toolkit, object system and programming language. Midori is part of XFCE, and also uses GTK and Vala. The GNOME project of course has their own browser, called Web (previously Epiphany).
This move to the most generic names possible for the software makes searching for i formation mearly impossible for people who don't know the old names.
Problem with "Files"? Good luck searching for a solution and getting relevant results unless you know to include the word "nautilus".
"Package kit" has four different names in the version on Fedora 20.
Package Kit is called "Packages", "Software", "Software Install" and "Package Kit". Searching for "Fedora packages" or "Fedora software install" is obviously sub-optimal.
Here's a screenshot for the package kit name thing. Package in the Gnome menu bar, Software in the program's title bar, Software Install and PackageKit in the About dialog.
I would prefer the about dialog to contain a magic-word to be used when searching for that software. So, you can call the file manager "Gnome Files", but in the about dialog let people know that "Gnome Files" is "nautilus".
[This was a huge annoyance with NextStep-derived projects like gnustep... Because they started from a proprietary system developed in relative isolation, all the apps had super generic names, and culturally they were loathe to make them any less generic. This resulted in a big mess on systems where multiple desktop environments are supposed to live in relative harmony...]
Perhaps it is just different aesthetics. Too often 'beaty' means: cut features to half, remove all icons and make huge empty dialogs.
The appearance options are so complicated and multi-layered that it's hard to replicate simple changes, and even installing a pre-built theme isn't wholesale: Separate types of themes need to be applied in a few different places.
Then you finally have the problem of GTK apps: They look bad in 99% of KDE themes, and most users are using at least some GTK apps (Firefox, Chrome ).
> GTK apps: They look bad in 99% of KDE themes
??? There is GTK engine which uses QT to render widgets. I really do not see any difference.
I use Chrome and only problem I have is new window placement, which is not really KDE problem. Chrome uses KDE dialogs and even KDE password manager.
Also, I am not sure why you say Firefox looks ugly in KDE - http://album.gnufied.org/firefox.png . I have made 0 modifications in KDE/GTK theming and firefox looks just fine under KDE.
As it would mean Motif, http://www.opengroup.org/standards/unix
My little travel netbook is quite happy with Unity.
I'd pay for that. Snow Leopard was the best iteration of OS X ever.
What Elementary does better for me: * works with standard free software (gimp etc) without looking ugly. * installs easily on standard hw, no need to use laptops with crippeled keyboards (fn/ctrl instead of ctrl/fn) * you can use home/end everywhere instead of a mix of ctrl+a, ctrl+e, fn+something, cmd+something depending ob application. (yes, Excel on Windows annoys me as well because ctrl + a doesn't work like it does in about every other app there, but on Windows this is unusual.)
As stated above Geary is built on top of GNOME technology (Vala, EDS), and uses GNOME infrastructure (i.e. bug tracker and git.gnome.org) -- and I'd argue it's built for GNOME.
Mirdori is also developed independently, again building on top of GNOME technology (i.e. WebkitGTK). Based on this thread[1], "Midori does not securely handle unverified TLS certificates, so it's not safe to use for HTTPS."
[1] https://lists.fedoraproject.org/pipermail/devel/2014-Novembe...
As an aside, I think this is the Linux community in a nutshell - this offer of help is similar to many I've received in the past.
I don't generally comment on the whole systemd controversy but I'll make an exception. I have two points:
1) I think we probably do need something better than init.d scripts. Consistency would be a good thing and better sandboxing couldn't hurt.
2) I've had more issues with pulseaudio than any other piece of software on Linux ... asking for a new piece of software from the guy that wrote pulseaudio is like asking Ross Ulbricht to be in charge of OpSec for BofA.
(Yup ... I'm probably going to get spanked for this comment since he's a far better marketer and politician than he is software engineer)
I've now switched to having a dedicated linux desktop and just letting my mac continue to just be a mac for now. After many hours of effort there's a point where you wonder if it's worth it. I want to contribute to the linux kernel, so feel I should live in linux too, the desktop is my solution to this (if a bit extreme!)
Which offer of help? :) I am really undecided on the systemd thing. I read terrible diatribes against it, but a friend recently pointed me towards an article which contradicts many of these points - http://0pointer.net/blog/projects/the-biggest-myths.html. the reality is it's a lot faster for sure all other concerns aside. I'm glad arch defaults to using it as a user :)
Being 1 binary or 10001 binaries don't change that they are useless unless systemd is running as init.
In essence the issue of systemd being monolithic is about run time, not compile time.
Works great for me.
The devs are all current/former OpenBSD guys, including Marco Peereboom (Who forked OpenBSD recently).
I have it in my smallest laptop, because it is much faster than the alternatives, but it has several shortcomings as well.
Open a video and the video player detects an incorrect aspect ratio? Good luck changing it without menus.
Except the Mac UI is crap. It's uncomfortable and unconfigurable.
If you're a technical user/programmer and you want something more minimal, simple, hackable, then don't use GNOME/KDE. Use xmonad or dwm, they are written by programmers for programmers. They are literally only window managers, nothing else. Only what you put in your .Xsession is what gets started when you run startx.
Sure, you don't get a file manager or auto-mounting of usb drives out of the box, that's because no sane programmer would want that by default. If you are one of the few that do, then install udisks and configure it the way you like (e.g. mount specific usb drives to specific locations with specific permissions). As a programmer you'll ultimately be happier. I promise.
Debian doesn't get in the way. It fully supports customization at this level. Take advantage of it!
Seriously: Red Hat is a very big company and they provide loads of resources to GNOME for no apparent reason. Red Hat also expands their commitment in this. Still, there are loads of volunteers. Suggest to talk to people at the GNOME stand at various conferences. Or maybe you meant developer instead of contributor. In which case I suggest to read the membership applications to the GNOME foundation. There's more to contributing than just being a developer. See ttps://mail.gnome.org/archives/membership-committee/ for the archives.
By "core contributor" I did mean developer but really my point was that there is an explicit gap in the roles of the people involved in these platforms. You have a small group of people explicitly focused on development, and a much larger group of people explicitly focused on usage. Windows and Mac OS X are in the same situation. The best strategy for the people developing these platforms is to focus on a generally applicable UI to accomodate the large heterogeneous group. Ultimately this will result in the platform being more omakase (if you will) and less likely to be everything for everybody, though a decent default.
I don't mean to say that this is a fault with GNOME/KDE themselves but more of a likely unavoidable consequence when you build a product for a large general audience.
If you're a programmer this is really annoying. When something is broken or annoying to you, you have the ability to fix it but because there is so much organization/process/design around these systems, the activation energy is too high.
But if you're a programmer you don't have to deal with this. You can just use a simpler system meant for hackability, a system where the users are the developers.
I see nothing wrong with big vertically integrated Linux systems like GNOME/KDE and in fact I'm glad they exist. If they did not, I would not be able to genuinely recommend Linux to my non-technical friends. Apple has shown the vertical integration is an efficient and successful way to design products for large groups of people, not unsurprising that those systems are mimicking that.
My first UNIX was Xenix and I used quite a few variants of commercial UNIX and open source clones.
Unless I have to do a remote XWindows sessions, I see no value in xmonad or dwm.
Maybe I don't want to have to read Learn You a Haskell to configure my window manager. Maybe I hate the whole concept of tiling window managers because I like to have overlapping windows?
You are making a lot of assumptions about what other people should want to spend their time on. I don't want to waste time or brainpower coding xmonad or dwm to behave in a way that doesn't annoy me, and manually setting up a bunch of basic infra like automounting USB keys, when I can just use KDE which doesn't annoy me by default.
I don't know how the solution to that is the buggy mess of, for example, Gnome on Fedora20 which is a buggy mess.
Everyone has an opinion about Technology X/Y/Z, often strongly held.
But you can't make a usable desktop OS out of opinions. You need a big-picture long-term strategy. There doesn't seem to be a lot of that in most of distro world.
Server Linux has done better because the problem space is (kind of...) smaller and better defined, so strategies and innovations have appeared, and there are clear goals to work towards.
Consumer Linux is like a military campaign advancing in all directions. Everyone is working on something, but - beyond development for development's sake - it's not at all obvious why.
- Ubuntu had a polished GNOME 2 desktop.
- Red Hat Enterprise Linux had a polished GNOME 2 desktop.
- SUSE Enterprise Linux had a polished GNOME 2 desktop.
They were also using pretty much the same components. Since then, we had the MATE/GNOME 3/Unity/Cinnamon split and the upcoming X.org/Wayland/Mir split.
I agree, it really doesn't. Just look at Linus Torvalds for example. Some people asked him at a recent DebConf [0] what he thought of Debian and Linux distributions and his reply was basically "Oh I don't really care about distributions or systemd, I just wanna install it and get on with my life (i.e. the kernel)".
In the nineties I had endless time to customise and fix the system, but these days I have so much work to do beyond the OS that I really can't spend much time at all on making the OS work.
I actually like a simple-to-use end-user DE like KDE as a container for terminal and browser windows. And I like that USB sticks can be mounted with a simple click, so I can copy something and tell the person that's bugging me to disappear with the stick so I can work on.
I remember an open-source and security conference around 2000 where I was wondering why all the hackers had default RedHat (or SuSE) installations with default Gnome or KDE and default backgrounds instead of nicely customised machines like mine. It took me some years to realise they were on stage because they got things done and didn't spend half of their time playing with settings, themes, backgrounds, fonts and convenience scripts.
Discovering GNU/Linux in the 90's meant playing with configuration files and themes for fvwm (the original not the rewrite one), twm, AfterStep, WindowMaker, GNOME, KDE, Sawmill, Enlightment, Metacity and a few others.
I also don't have the time nor the patience to do it any longer and just take the default install.
Which currently means Unity with Ubuntu on my travel netbook.
All my other computers run something else as OS.
To preempt the usual disagreement when I say this, I have never consistently been able to get projectors/second monitor working in Linux on a laptop, so I have learned to live without these. This is also why you see Linux devs doing presentations using Windows/OS X.
Then I got really fed up with always messing up my terminals and switched to awesome as my window manager. It's more pleasant to use, especially with multiple monitors. The downside was that it's taken quite a lot of effort to customize it enough to make it work even half as smoothly as Gnome does (which basically means running half of gnome's services in the background).
If someone took Gnome and replaced gnome-shell with a modern compositing tiling window manager with some (optional) 3d eye candy thrown in, I would switch to it in a heartbeat. Hopefully there will be a tiling compositor for Wayland eventually.
I don't want to fart with random scripts I have to cook up and futz with to get a working system.
The things I want to hack are the things that are coming out of my own work, not making someone else's work useable.
There are tasks I only do very rarely (burn a CD, use Gimp, tag some MP3s, use a VPN, hold a beamer presentation, etc). When I do them, I want to be done quickly. GNOME does this quite well. The last time I used a tiling window manager, I tweaked the configuration for an hour to make Gimp's weird window behavior work well.
That often? Sometimes its hard to remember Dropbox is only about 7 years old and I've only had "always on" internet for about 15 years. Its surprising how fast we forget how things used to be. The future is very unevenly distributed and it feels so weird to read stuff in 2015 about antique USB sticks that sounds like griping about mtools and 360K floppy support.
Something that annoys me about USB drives is I haven't used one for anything but making bootable installer sticks for many years, and the "auto mount" paradigm makes life more difficult for me not easier. All I wanna do is dd the freebsd installer to the USB stick, now stop trying to automount.
And the NSA is not reading my USB file names.
My point isn't that people in general should be hacking up their own Linux desktops, even if they can. Programmers that like to do that probably should though.
My point is that if you are going to commit to using user-oriented systems like GNOME/KDE, don't do non-standard things and don't complain because system internals seem too complicated. They aren't meant to be hackable/simple!
This is a false contradiction. You can have a system with a user-friendly default configuration (for developers) and that is still understandable and hackable.
In fact, this is the entire premise of UNIX: it consists of small orthogonal programs that you can combine in various ways to solve problems. E.g. remember the old script-driven hotplug[1]. It was user-oriented: users did not have to add manual modprobe stanzas to some file anymore or manually mount USB sticks. On the other hand, it was a set of shell scripts that could be modified easily by anyone with some basic grasp of bourne shell scripting.
[1] Which had the problem of being slow due to requiring a lot of fork/execs.
The OP is running GNOME and complaining because he's not using systemd and it broke something (non-standard configuration) and because he can't understand the d-bus-controlled cgroups system (complicated system internals).
I use Kubuntu for work and I don't see your point. All my work is done on CLI/vim/emacs and GUI is mainly just to run a browser. Why would I spent my time "hacking" it if it suits my need?
I plug in usb sticks all the time and of course I expect them to automount on linux just like on the other OSs I use on a daily basis. (and I was very annoyed last week to discover that my linux machine did not auto-mount a sdcard, and I had better things to do than start troubleshooting it)
The same applies to suspend. The local user perhaps should or should not be able to suspend the machine. Presumably remote users should not be able to do so at all.
What about wireless network connectivity as the machine moves? Who should have permission to manipulate that?
If we did not have more a more complex dynamic permission system[1], some would be saying that modern Linux is outdated and unable to cope with the more modern reality of much more dynamic needs like this.
Instead, the article seems to be saying that it's become too complicated.
We can't have it both ways.
[1] http://www.freedesktop.org/wiki/Software/systemd/multiseat/
I also wonder how other OSes handle that, I'm looking at Windows and OSX. With VNC/RDP/Teamviewer/etc you get full access to the Windows desktop and all devices. I guess OSX has the same, plus sshd.
So, maybe supporting a fringe use case is making more common use cases more inconvenient?
Sudo configs are configurable (as are default command aliases) to at least make this a deliberate decision, and not an accidental occurrence. You could also, in rare cases, just "whitelist" certain commands, although this is generally not that practical.
Sudo, is however, by definition, a dangerous tool. I try to make sure that everyone who has the right is aware of the responsibilities.
Windows and Mac both have their own privilege escalation, and shutdown commands, so there's nothing particularly different about their situations.
Regarding Windows, it's all explained on MS website (just a Google search away), and it seems quite potent, but a default consumer OS doesn't push for stringent requirements for each and every application being installed. It's up to the user to setup the adhoc policy, and hook up VNC to it, I guess. The good thing with application markets and distro supported package repositories is that in theory all this could be included in the package and verified for conformance by the repository maintainers.
The policy contains items such as "Devices: Allow undock without having to log on" or "Deny access to this computer from the network" (user/group list).
A policy consists of a number of such settings. For instance you can set who can shut down the system, and who can do it from remote.
With Windows 8 came <a href="http://www.windowsecurity.com/blogs/shinder/microsoft-securi... access control</a> where access control lists (ACLs) now can include tests for type of device being used, network location etc. This can be used to disallow access to certain documents or applications from phones/tablets while allowing access for the same user as long as he/she uses a stationary device within the corporate network. Dynamic access control also takes most of the pain out of complex access control as it can decide access not just upon your security group membership, but also on other claims such as limits, department, organizational unit, local certificates etc.
http://article.gmane.org/gmane.linux.kernel/706950
In essence they don't see the problem inherent in having the server sitting encased in concrete at the bottom of the Marian Trench.
The way this kind of thing was solved 20 years ago was that you could be given membership of some additional groups when logging in locally.
(The wart is that if you, say, opened the sound device when you were logged in to one of the lab workstations locally, you could pass that file descriptor to another process and keep it open after you'd logged out, and then use it to play Rob Zombie at full volume when some unsuspecting victim was by themselves in the lab at 2am).
I literally can not think of a situation where the multiseat usecase is relevant, small SOC computers cost too little compared to buying extra graphics cards and USB hubs.
Then again, i can't see how to fix that with software, other than blankly refuse to assign a device that goes away and comes back to a existing seat. Never mind trying to assign a whole new device. It seems to sprout edge cases all over, like trying to zoom in on a Mandelbrot.
$ groupadd camera
$ usermod -a -G camera $USER_WHO_NEEDS_CAMERA_PERM
Of course, this would require the group ownership of the necessary /dev/device or
camera program: chmod 660 /dev/$CAMERA_DEVICE
# and/or
chown .camera /usr/bin/$CAMERA_UTIL
chmod 770 /usr/bin/$CAMERA_UTIL
In practice, the "camera" group should be added by the driver (or whatever) install script, or maybe by the OS installer. Adding the user to the "camera" group would usually be the job of a wrapper around /usr/sbin/useradd or other admin tools. Usually, I would expect the distro to set up permissions that are apropriat4e for their intended audience (i.e. desktop vs multiuser-server vs "other").On my gentoo desktop, my user account is in many groups for this very reason:
$ grep pdkl95 /etc/group | cut -d: -f1 | sort | column
audio deskmsg plugdev sshpermit video
cdrom floppy portage usb wheel
cron games postgres users
davfs2 pdkl95 realtime vboxusers
Often, I find that when someone claims that the user/group system is too restrictive, they haven't considered simply adding more groups.> login in locally > login in remotely
You would use PAM(8) for this. One method would be to use pam_group(8), by putting something like this in the appropriate /etc/pam.d/ config file, such as /etc/pam.d/login
auth optional pam_group.so
...and configure /etc/security/group.conf (see group.conf(5)) with something like: gdm; *; *; Al0000-2400; camera
This way, the people that login with gdm are added to the "camera" group. Again, this is something I would expect desktop-focused distros to setup, at least for the common stuff.> wireless network connectivity as the machine moves?
That would be a local permission, generally, which would be covered by a setup similar to what I describe above. Even if the computer moves, it is still the logged in (possibly through a suspend) user that needs permission to configure a network interface.
> some would be saying that modern Linux is outdated
...and I would reply that those people probably need to spend some more time researching how to fully utilize the user/group system and PAM. While there are a few cases where the UNIX style of permission is insufficient, they are rarely encountered on a typical desktop or simple server. In the case of the common single-user laptop where the one user is also the "admin", there only granularity you need is a description of when they should be prompted to be become root, which is trivial using basic user/group permissions.
I don't think this was ever really the case, but I do think software is evolving to meet the list of constantly updating use cases.
Of course managing one network interface with all your peripherals connected at startup required less complexity. But if your target audience also has use cases of wanting their USB drive to "just work" when plugged in, being able to connect to a new wifi access point under their normal user, etc., you will want some extra layers of abstraction that aren't available if you limit yourself to FDs and Unix-style permissions.
In addition, some software is cross-platform and doesn't always care about maintaining consistency with the conventions on a single platform.
I have yet to see a single case where FDs and unix-permissions wouldn't have been perfectly sufficient.
I think the real problem is that we are facing a generation of developers who never learned how to properly use them.
You can solve the problem by using socket FDs, but you have to roll your own format for registration, communication, error checking, making sure the appropriate applications can read, etc.
I think many developers would prefer using DBus as an abstraction for these types of problems.
That's how unix used to work before the desktop people took over.
[1] Yes, DBus is "sort of" line based. But from all I've heard it's the opposite of simple and... well, let's just say people don't seem to have much good to say about it.
But having a daemon that relays your messages to other applications based on a standardized protocol has some merit of its own, even if it isn't strictly Unix-like.
I might have some bias, since I think the Unix-way is oversimplified for some problems, even though there are often ways to make it work.
I agree, and I'm not opposed to the idea of a daemon.
DBus just seems to be (from my perception) rather poorly designed on every level. And the more pervasive it becomes the more of its bad design bleeds into more or less unrelated other software packages.
the Unix-way is oversimplified for some problems
The unix-way of course has limits, but it's usually worth to explore it as far as possible and only then divert to more baroque designs.
In the majority of cases you'll find that pure, file-based approaches are a lot more elegant, efficient, discoverable and debuggable than the alternatives (see e.g. qmail vs postfix, or runit).
There's a lot to be said for being able to use the standard unix cutlery to inspect and interact with the guts of your application.
Imagine DBus was just a directory with one or two files per pid. Imagine you could read past messages with 'cat', follow them with 'tail' and inject new ones with 'echo'.
Why not instead use fuser(1) to find programs using the file descriptor you want closed, and then take program-specific actions (kill(1), restart, signal) to ensure that they sanely release the descriptor?
Using fuser() in that way is racy, and how is kill() any better than returning a possibly-ignored error anyway? You can't do program-specific actions because the point is to enforce "You did have permission to open that, but now you don't and you aren't allowed to keep using it".
Why not simply close the fd and let the regular transport error handling (retry/backoff) do its job?
If you find yourself needing any more ceremony than that then that almost certainly hints at a higher level mistake in your protocol design.
revoke() basically works like closing it on the "other side" - the process still has an open file descriptor, but any IO on it will error.
Could you give some examples of USB drives not working or new networks not found? Thanks.
The way this is done is with a message bus and other subsystems (there were consolekit, networkmanager, ...), and these don't really match the "Unix-way" of doing things. Though I don't consider this to be a big issue, some people do.
If you have a minimal distro and install a very basic environment, you'll often have to set up these to work if you want some of the above features. Ubuntu will already have all this set up though.
I've tried FreeBSD several times but at the end of the day features and compatibility beat clean and logical.
Features? Well, FreeBSD has a lot of them (big ones: ZFS + DTrace + Jails + pf) and they work great out of the box!
It's unfathomable that this ultra common hardware is unsupported, until you consider that even most FreeBSD devs don't run it on their laptops, they run MacOS with FreeBSD in a vm / via ssh, because it's not up to the job.
It's at least 5 years behind Linux, probably more.
As opposed to other distros, Arch is the only user-centric distribution out there. When something goes wrong, I don't have to deal with "where does this come from", because the distro itself doesn't interfere with anything. It's either a bad config on my part, or an upstream bug.
Upstream bugs are fixed immediately due to the rolling release nature of Arch. And configuring my system is extremely easy, since 95% of the problems are solved by looking at the wiki.
I won't bash on other distros - to each her own. But I urge any power user that wants full control over their system to try Arch. It's truly another class of Linux.
Never in my life have I had to work ON my computer as opposed to doing work using my computer as much as I have using Arch.
I'd say FOR instead of ON, but otherwise, that was my impression of Arch.
Eventually I stumbled across Cinnamon (and/or Mate) with hotcorners and tmux. It doesn't have the previous configurability but it's still pretty good.
The reason people held onto XP for so long was that it just worked well and it was consistent. Many of the Linux GUI people should take that to heart. Instead they always seem to try to be in catchup or trying to surpass Windows. Gnome 3 and KDE 3+ have been so very unwieldy, resource hungry, or lacking in features. They've been the Windows 8 equivalent of the Linux desktop.
Even to this day, most people don't like the Metro style interface (unless they are playing with it on a phone). I'm blown away by how difficult it is becoming to use Windows. I will go into the Metro style settings and see that a configuration option is not present and then have to go into the good ol' control panel. Or vice versa. I'm getting increasingly drawn towards using Powershell by default so I don't have to backtrack.
Windows has been trying to force new "UI paradigms" to sell more copies of Windows. Linux should realize it doesn't need to adopt the new and flashy... unless it really is an improvement.
I did notice the 3d windows does make some horrid tearing artifacts on rotate. Turning that off; it gives me the nice 8 desktops I'm used to.
(Have Thinkpad T61, bound rotate cube keys as above the arrow keys)
Ever tried KDE ?
For the record, my permission problem was solved via "sudo pam-auth-update --force". Thanks Arch Wiki for giving me the crucial hint.
Do you happen to have a link to the arch wiki entry you are mentioning? What was exactly your problem?
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1317518
As in the bug report, the problem was not replicable. While my Thinkpad had these issues, my desktop was fine.
Unfortunately, my notes say nothing about the Arch wiki. Maybe I confused that with another issue.
My impression is that figuring things out is getting a lot harder, the big mess of D-Bus, GNOME, NetworkManager, anything ending in Kit and systemd is not only in a constant state of flux but their internals are also poorly documented (or not documented at all).
Googling to troubleshoot Linux sucks. Part of the suck is that Google's page rank favors old pages. Part of it sucks because it's keyword finding favors forum threads where the terms are in someone's signature.
And part of the suck isn't Google's fault because GNU/Linux documentation is dense to the point of opacity. It is great for professional standings and not so great for amateur ones.
Worst of all is that FOSS documentation has a lot of "not my problem" links. If a piece of Software is doing something bad to Firefox it's documentation will mention Firefox and link to the Mozilla homepage...so to speak.
If this is the crux for the OP I don't really see how this is for Modern Linux. Maybe it's just me (though I doubt it) but what is described here is basically how working with linux (and software in general to a lesser extent) has been for me as long as I've used it. Small annoying problems here and there which take quite some amount of time to find a fix for, if any. And after a while if there are too many of them it becomes irritating and you start a blog post to nag about it :]
I feel the same way. Maybe modern linux isn't a bad thing viewed neutrally, but it's not the same thing as the one I love.
Offering the alternative makes finding solutions to his problems more complex and confusing.
When I learned unix 20 years ago on sunOS, man pages were complete. It has never been the case on linux. I think man pages should give all the assumptions about the system that may someday break or give pointers to documentations.
I have often to use strace to analyse issues. When dbus starts to be involved, I am often lost.
I'm actually somewhat worried about the current state (especially on the desktop). It never was a big deal to me that some flashy functionality or hardware support took longer to show up in Linux and *BSD, because once it arrived, it usually worked well and was stable. Now however there are a lot of annoying complex bugs that are hard to trace and don't seem to be actively analysed and fixed.
It's not a good sign that as a hacker I don't know where to begin to properly track some of these bugs myself, and the people who receive the bug reports don't seem to have a clue either.
Face it, there are only so many years you can work on the same issues for every new model of laptops. People get tired, people retire from projects.
But it is still open source. You are right that many behaviors (of Debian, apparently the focus of your article) suck. Well, jump in!
The problem is: in Linux, pretty soon, you cannot do without the fancy bits anymore.
I run a bunch of servers. Servers need a firewall. Nothing fancy, just iptables. Right?
I'm running Ubuntu servers. They have 'firewalld' installed. Firewalld uses dark magic to manipulate iptables and ip routes. Oh, it's all great when it works, for as long as it works. You can simple open up a port by issuing a firewalld-cmd command. Until you can't. Until firewalld-cmd says it can't connect to firewalld even though it thinks it is running. And firewalld can't restart because it thinks the configuration files are wrong.
I'm not a Linux newbie by any standard, but I could not solve this problem. After restarting firewalld, all the routes on the machine were gone. And thank god for iLO.
This is on a production server providing secondary services to 200.000 users. Soon after, I found similar issues on our loadbalancers, webservers, database servers, all running firewalld.
There was no other solution other than to reboot the server. I tried debugging firewalld and ran into (no particular order) apparmor, dbus, python, firewalld-cmd, firewalld, network-manager and libvirtd. No where was a hint to be found of why firewalld didn't work.
I don't consider this to be anything fancy. This is supposed to be a simple wrapper around iptables. It is supposed to 'just work'. It is supposed to leave clear logs about what it is trying to do in /var/log/syslog.
Sure, I'm getting old and cranky. But I'm really tired of having to get called out of my bed at 03:00 am because of this 'innovation' that tries to solve edgecases. And solves them badly.
Looks like you mean Fedora/RHEL7? Ubuntu on the server (14.04) is quite okay in my experience.. you can even deinstall dbus and still use upstart..
RHEL7 made me furious (NetworkManager by default... ) but I'm not used to it so it may be just missing experience.
Back when I played around with my OS as a hobby I was able to keep up with most of the issues and changes, but without investing that kind of time, I don't have much choice but to leave things at their defaults, install updates, and hope for the best. Things weren't better before, I was just more involved, and I wonder if the same is true for the author.
This all has to be done to stay compatible with previous systems and raises complexity.
So I've just kind of gotten used to using the source. Seriously! If I find something I don't get, I build the package from source, and debug it. This is really the only way I've been able to survive as long without tearing my hair out in frustration over the years.
Its a glib response to the problem, but actually it really works.
Back when I used sarge, it was okay - there was some configuration I had to do to get X working, and at one point I had a pretty sweet custom kernel build on a laptop that extended its battery life 35% over windows.
Decided to spin up a VM to use debian as a dev environment again recently, and -- well -- after three hours of futzing with it I deleted the VM and booted Ubuntu instead. Had issues getting virtualbox extensions working; some others that I can't remember.
Anyway, I've been using Debian Sid since 2000 and, for what it's worth, it "just works" on my hardware now and it's much easier to install/manage than, say, five years ago. Then again, if you mess with the default configuration you're looking for trouble and should accept that problems are harder to fix for corner cases.
I remember updating to Debian testing (never had the nerves for unstable) when they switched to Gnome3 and I experienced bugs (and really nasty ones). When they make big changes it is going to break things.
If you don't want to have things broken, either use a stable distribution, don't upgrade for some time or live with it.
Right now I am using Arch Linux mostly - but I've heard the change to systemd had some rough edges for Arch Linux too (didn't use it at this time).
I can say that I am completely fine with systemd on Arch Linux and I don't understand the big problem some people have with it (on a philosphical level I do understand them, but not on a pragmatic level).
I'm not saying they're wrong this time, but there's no reason why not. The haphazard state of the Linux desktop that the original author laments over might be indication they're wrong in some places.
Personally, I enjoy new technologies and systems in linux. I used to run Gentoo and other distros that constantly brought out cutting edge software. And I'm used to somewhat alpha/beta quality software that mostly works. And because it works well compared to my experience with windows software, so I wasn't too bothered.
Maybe it's because my background is in hardware, but all of the new software had always taken awhile for me to grasp and appreciate. But in the linux community, I've always been able to find info and solve problems that I've come across and learn about the system. Windows problems usually can be solved because large masses of people tried so many things, but I wouldn't get any enlightenment about computers or software when fixing Windows problems. Maybe my world view has been skewed by comparing linux to windows, but I've always felt that I'm able to learn and understand more with linux vs Windows.
Are you familiar with branches beyond Stable? I switched from Arch to Debian Unstable (which uses a rolling release) and find their edges to be about equally sharp.
At times I do feel like packaging in Debian lags because of maintainers lack. For example KDE could get packaged faster (there is no Plasma 5 in Debian yet). But usually it catches up if it falls behind.
- Adapted from Betteridge's law of headlines [1]
[1] http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines
I don't see why people throw this around a lot, it really isn't. Most recent example I can remember is when Debian decided to remove NVIDIA drivers from Testing and you end up with a nonfunctional desktop [0].
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755020
I'd say testing is. Unstable is not supposed to be normally used except for debugging stuff.
also please call is gnu linux nog only linux. linux is a very small part of your operating system
http://en.wikipedia.org/wiki/Vogon#Poetry
Maybe if he used Klingon as "alien poetry starting with a V" instantly makes me think of HHGTG
..anywho :)
I have always been on the NetBSD side, and it's bright over here. Even FreeBSD suffers from similar problems as Linux, trying to get new features fast. That's just how software development works (or does not), you have to follow proper design to get something for the future.
Linux will always be stuck in past design decisions, and in order to stay compatible, things will need be become more and more complex, until they break.
A number of bad decisions started to get made as these sponsors became frustrated with the low rate of uptake. One of them, I'm sure, was the perceived need to keep up with the competition, essentially getting into an arms race with the strategy (if there was one) of outdoing Microsoft.
A good example of this is the absurd introduction of PulseAudio, which introduced features that nobody asked for while simultaneously breaking audio for a large number of users including myself. All because a similar (but working) feature was introduced in Vista.
There appears to be (at least at the time) dick-all documentation on policykit, excepting magic invocations on the Ubuntu forums to do this or that. Reading the configuration files appears to suggest the primary use case for policy kit is to work in large installs like a university lab where the permissions are being portioned out in a highly granular manner via third-party authentication services. If this isn't true, don't blame me for coming to the wrong conclusion. I do not give a shit about any of this. I'm on a single-user machine and the one user can do anything it damned well pleases (to a first approximation). But there is absolutely no clue I could find about how to accomplish this.
By just fucking around and turning off permission checking in every manner I could work out, I eventually got myself into a position where "root" was capable of adding new network, but my normal user is only permitted to switch between existing networks. (Incidentally, read that sentence again, it's actually quite surprising. The result of what I did should have been to let everybody do everything, right? No. Why not? Hell if I know.) This was enough for me to declare victory and move on, but it really isn't a victory.
And the point of me posting all this isn't so much to bitch; that was just a bonus extra. The point is, if this is a "professional" solution to the problem of system permissions, I have no idea how it meets that goal. There seems to be no way for the aforementioned University administrators to learn how to properly configure it for their use cases, no logging to help them get it right. Putting on my sysadmin hat, I'd never trust this system any further than I could throw it, it's so opaque. I would get a bug report that Bob was able to use the video camera when he shouldn't be able to, and I'd push a fix, but I'd have virtually confidence that I'd actually solved the problem, to say nothing of continuously wondering exactly what my permission scheme was permitting to people. To me, it looks worse than a closed source solution... at least the closed source has a support line you could call.
"It worked, but I don’t know why"
"I don’t even know where to start looking."
"That’s about as comprehensible as Vorlon poetry to me"
Potentially non politically-correct answer to the article title: maybe it's not Linux who lost its ways, but some old-time users? (who forget the beginner's spirit to look for answers on forums, manuals, to try to understand before casting a judgment)
Linux has always innovated around the paradigms, taking inspiration from everywhere. It was never "clean, logical, well put-together, and organized". It has always been messy, but in a good way.
When I first discovered linux, I had to adapt to all these new things. That was in 1992. When I decided to use again a modern linux distribution on my laptop in 2014, I had to adapt - again. I have no doubt I will have to keep adapting in my lifetime.
The error would be to consider that the "right ways" are fixed, and that innovation should be stopped.
There will be many new things, some will be kept, some will be discarded. Change is the only thing one can constantly bet on.
“For years, I used to run Debian sid (unstable) on all my personal machines.”
“Sometimes things broke. But it wasn’t a big deal, because I could always get in there and fix it fairly quickly, whatever it was.”
“I’ve googled this issue, and found all sorts of answers pointing to polkit, or dbus, or systemd-shim, or cgmanager, or lightdm, or XFCE, or… I found a bug report of this exact problem — Debian #760281, but it’s marked fixed, and nobody replied to my comment that I’m still seeing it.”
… doesn't sound like somebody “who forget the beginner's spirit to look for answers on forums [etc]”
So why couldn't he find it?
It's not that a current linux system is N times more complex than the sid he used to run, it's that things changed: as was properly noted by someone else on this thread, dbus was one of these important changes. Now it's systemd. Next it'll be wayland or something else.
You're correct in that he still tries to do some search, but he expects things to be like they were in the past, where he "could always get in there and fix it fairly quickly, whatever it was", i.e. to be just as efficient, without learning the new tricks!
The beginner's spirit is to want to learn new tricks, looking for answers and being really insistent in understanding better, instead of stopping after a google search and a comment on a bug report.
As said in another post I loved for it straight-to-the-fact comment, "In contrast, to 10 years ago, I do not like hours of debugging to get USB working anymore. It was fascinating then".
It's not more complex. A Linux system is a time investment, where knowledge has a half line. If you no longer can or wants to commit to learn new things at the same pace, but still want to fix things as before, maybe it's not the best idea to stick to Linux.
IHMO, the author would be best served to try say FreeBSD, where things seem to change at a slower pace. But he would still have to learn this new thing, and I strongly believe he doesn't want that - just a system as before, without any changes. Ain't gonna happen.
Its an aesthetic decision.
A car analogy is anyone who doesn't like tail fins on cars is too old to be driving and should go back to a horse. An architecture analogy is something incredibly cluttered looking like gothic or victorian architecture is the only way to design a house and anyone who wants clean modernist design is aesthetically wrong and should go away. Cars and houses are supposed to be ugly and pointlessly expensive and cluttered looking and anyone who disagrees is inherently wrong because, um, well just because they're noobs to cars and houses.
The advantage of freebsd is its design aesthetic is dramatically superior to the linux design aesthetic. Its devs have better taste in OS style. As a side effect that makes it easier to use and more productive and more noob friendly, but thats merely a side effect.
All that do automate "mount /dev/sdb1".