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).
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.
# 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
...
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.
All because they don't want a sodding LED on the machine
(I'm running Ubuntu 14.04 with Gnome 3.12)
http://osxdaily.com/2013/01/21/mac-slow-wake-from-sleep-fix/
Though I think the user experience could at least be significantly improved.
* 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.
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.
It 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.
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
$ 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.plist'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
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.
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).
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.
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.