If you're running an up-to-date GNOME/KDE/etc. desktop, and not running systemd, for better or worse you're using a less-supported configuration. There's going to be other stuff that systemd will break, but in the long run you're better off using the upstream-recommended configuration.
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.
USB drives and suspend were working well for me, for a few years before systemd took over the distro I used (arch linux). Of course, I set it up to work perfectly for me. It wasn't too hard.
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.
Please note: These problems don't crop up in non-rolling distros nearly as much. The transitions are held off, managed and only rolled out for new major versions of a distro.
There are benefits to running Arch, but 'just works without breaking' is not something it's good at.
Indeed. I love Arch and generally it has been very reliable for me (more so than Kubuntu or Suse ever was previously). However, the transition to systemd was one of the few times where I had a issues. Systemd is pretty mature these days, but back then it was much buggier and less well-supported.
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).
That's kinda true, but I did use non-rolling-release distros, particularly ubuntu for a while, and they're generally more buggy (and I expect Fedora is even buggier than that).
> What was the last time you thought about how OS X or Windows does suspend
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.
Some laptops have a mechanical lid switch (instead of a magnetic one) that easily triggers when some pressure is applied to the lid. I have the same problem with... a Thinkpad. Luckily, under Linux, you can disable wakeup through the lid switch:
# 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.
I don't understand the point you're trying to make: are you saying that no matter the OS, some hardware platforms will be flaky and others well supported?
You are not alone. I also have a work provided Dell that I have to shutdown unless I want to use my work bag to keep me warm on the walk home. We have another Toshiba at home running windows that will at random times of the night just spin up its hard drives and perhaps throw out the odd notification sound before spinning down again. It seems for windows suspend is not really go to sleep until you are woken up again by a human.
I have a Dell M4600 running Windows 8.1 (started off with Windows 7). Suspend and resume has always worked. I never think about suspending - I just close the lid or hit the sleep button and throw it in the bag. When I get home I press it into the home dock and press the power switch on the dock to wake up. Windows 7 also never had a problem. Yes, this is anecdotal evidence to counter anecdotal evidence.
My work Macbook Pro has constant problems with suspend. Sometimes it doesn't get the external display up again and sometimes it just takes a long time to wake. To be fair the slowness is likely due to old fashioned hard drive that always gives you time to ponder the finer things in life.
I've got a MBPr and its worse than your situation. Reinstalled 3 times to see if it helps. So when it suspends and i open it up very soon afterwards i just get a blank screen for 30-40 seconds. I've learned to wait but sometimes you have to press keys to get it to wake up. Sometimes you press the power button. Then as you type your password it suspends again.
All because they don't want a sodding LED on the machine
From what I've heard it's because Macbooks have really aggressive hibernation(I've experienced this on my MB Air personally). Basically they will copy everything from the ram to the SSD and shut down fully. Then when you wake up it copies everything from SSD back to RAM - but if you have 16GB of ram, then even with an SSD it will take nearly 30 seconds to copy everything back, and until then the machine is unresponsive. I think it would be better if they just told you they are doing it "please wait, waking up", instead of just giving you a blank screen.
I'm very careful to not plug in an external screen before the MBP wakes up as your MBP may crash. Have made that mistake myself a few times and am nowadays very careful to first wake up the MBP before plugging in an external screen.
As does mine, sometimes when I just close it rather than suspending first it doesn't wake up and needs a hard reboot. Other times it needs quite some time before letting me enter my password and acts frozen until then.
Granted, the problem is likely related to age and failing memory (one of the slots is dead) but I do certainly think about suspend behaviour.
If I didn't know better I'd say it's almost as if maybe the user knows better whether to suspend or hibernate, and conflating the two is a classic "Apple knows best" pitfall they return to over and over.
I think the problem is that we don't know how to troubleshoot problems with our desktops (especially things related to permissions as in consolekit/policykit/dbus etc):
* 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 think you are hitting on something with this. And part of the problem is perhaps that so much happens across dbus.
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.
My iMac's automated backup has been broken since Yosemite because Apple removed the ability to set environment variables that all processes started from launchd could use.
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.
As a homebrew user I absolutely abhor having to keep around a list of instructions that I've only barely just caught during an install .. things like:
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.
Pro-tip: you can use "brew info [package-name]" to lookup the post-install info that flashes up after a homebrew install.
$ 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 have much disdain for this solution - even though it is a solution - because its a non-builtin tool and has dependencies outside the OSX sphere in order to run.
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.
If I am having a problem with OpenBSD, I read the man pages. If I am having a problem with OS X, I search the web for a result. I just don't quite trust the OS X man pages anymore.
Same, and I had the issue described in the article. It's just a result of the installation process and is documented on a bug page... somewhere. What happens is that if you install Jessie from USB, a line is added into /etc/fstab for this USB drive. And this changes the usual auto-mount of USB drives later on: instead of mounting them as the logged in user, they're mounted as root, read-only. Hence the error when trying to access the USB key.
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).
Ah, yes, I remember this issue in the past actually when installing from a USB drive. I guess I'm used to removing that line from fstab in such cases, so I don't keep track of that :)
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.