Slashdot Mirror
Ubuntu 15.04 Released, First Version To Feature systemd
jones_supa writes: The final release of Ubuntu 15.04 is now available. A modest set of improvements are rolling out with this spring's Ubuntu. While this means the OS can't rival the heavy changelogs of releases past, the adage "don't fix what isn't broken" is clearly one 15.04 plays to. The headline change is systemd being featured first time in a stable Ubuntu release, which replaces the inhouse UpStart init system. The Unity desktop version 7.3 receives a handful of small refinements, most of which aim to either fix bugs or correct earlier missteps (for example, application menus can now be set to be always visible). The Linux version is 3.19.3 further patched by Canonical. As usual, the distro comes with fresh versions of various familiar applications.
Agree but i've had problems with Mint for a while, and the official forums for it are dead; you're much more likely to get help on AskUbuntu or UbuntuForums, so I've gone back to Ubuntu then upgraded the ui to xfce. Problem solved! (I tried briefly but unity is still a mixture of awful and buggy).
I've been using Unity for a few years and I like it. Typically I might have several browser windows, several terminals, and other windows like WireShark open. In the older UI these would have all been accessible from the bottom bar, and there might be twenty or so tabs there. Unity changes it around so you go to the side (a good place to put things on a 16:9 monitor) and select the browser, terminal, or another icon. With the muscle memory in place it has worked very well. Alt-tab also works as you might expect. I also have Mac laptops, and it's not especially annoying to go from one UI to the other.
Systemd "won" because of the choices of distibution maintainers, not the choices of linux users or the linux ecosystem. The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage. Somehow it's not surprising that systemd itself (the software) operates in a similar top-down manner, forcing adoption by creating new dependency issues.
Gnome 2, MATE, XCFE, and maybe other desktops allow vertical toolbars too if you like it (not my case).
Alt-TAB window switching work equally well on all of them too.
I personally found both Gnome 3 and Unity catastrophic in term of productivity. I actually work with close to 40 virtual desktops and over 100 windows. I configured to switch around them using right CTRL+arrow keys, without any animation or effect. Blazing fast and simple.
You can't just leave things alone, because computers have also changed. Today we do not work on mainframes or desktop computers, but increasingly on laptops and mobile phones, which constantly change state, in terms of network connections, devices plugged in, location, hibernation.
I think there is consensus that these things did not work well on the old init system, although band-aids were found. I remember that changing the hostname stopped X from working, which can occur when DHCP gives you a new hostname. That is 80s design for you. Or changing the time messes up the logfiles.
Now you can choose which modern init system you want, and there are a couple out there: OpenRC, upstart and systemd are the most well-known ones.
OpenRC is the familiar runlevel based approach, which runs scripts which may or may not succeed.
Upstart is a triggering framework, that takes pre-defined actions (but does not work with goals). That means you have to write tasks for how to get from A to B with your system.
systemd is a dependency resolution program, that knows what to activate next to get to a certain state (goal). It handles services, mount points and network connections in the same framework. It is essentially an overseer of a services tree.
There are some upsides to systemd, besides parallelizing the tasks of a dependency tree to reach a goal. One is for every process it is known which service launched it (there are some Linux-specifics that allow marking those processes). Also, each service can be assigned resources (memory, number of processes), which it can not exceed (again, modern Linux supports that). And, obviously, you are not limited to a set number of runlevels.
Yes, systemd is annoying, because it is a new thing to learn. And it is annoying, because the maintainers are inconsiderate. But in the end, it is just a program to start other programs, with one particular way to do it. I don't get what the big deal is. If it is feature bloat -- Linux also has a lot of features, so does VLC -- there we consider them a good thing. Technically, the dependency resolution approach of systemd seems like a good thing (as in progress for Linux) to me.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
I first used systemd on a complex custom embedded project that dynamically switch between multiple loads and it have saved me days of work compared to previous designs. Dependencies are managed the right way, and status+analysis tools are very good.
PulseAudio is unstable I agree (I juste deleted a ~1.5GB .xsessionerror filled with insanity from it, and it crash at least one a day), but not so systemd, even if journald need some more work to fix some minor issues.
I just had a bootup of a laptop after what must have been a crash. Rather than fsck and check as under traditional init, it halted in systemd, because it had something to tell me. Which it didn't. So you log in to the single-user mode with a poor prompt (really, if you're asking me to log in, maybe you should *look* like a login). Then to see anything you need to run journalctl -xb. Nothing wrong with the disks as far as I could see. It seemed upset that there were a lot of logs in this boot. OK, so I reboot. And back to the same thing. You have to tell *it* to be OK that you've read the warnings. Then tell it to reboot. It being systemd.
So it's a regression, just extra layers of failure to get through when you already have an issue. All the same tools still have to run, but someone has to tie them together, and no one has. That's plebwork apparently.
I think this is the same problem that stumped Red Hat's support for a while when we first upgraded to 7. MongoDB refuses to start after an unclean shutdown. It detects that by placing its PID in a file named mongod.lock on start and then clearing the PID on clean shutdown. When you start MongoDB with the lock file in place, it gives you an immediate and clear error message on stderr that this is the problem. When starting with systemd, because it swallows stderr and syslog messages, there is no indication whatsoever what is causing it to not start. There is nothing in the journal or the console. systemd hides the information you need. Instead of taking thirty seconds to fix this problem, it took us most of a day and required using strace to see the stderr output that systemd hides.
Even worse is trying to troubleshoot SELinux-related problems. SELinux is very sophisticated so anything that hides stderr or deletes syslog messages makes life very difficult.
With systemd's policy against stderr, it is swallowed and not shown on the screen and not logged.
A lot of this criticism is coming from AC.
I tested your script on CentOS 7 and Fedora 21 a moment ago. Both logged your "Error that should not be thrown away" to both the journal and to the syslog messages file. Both detected that the service failed, and did not "throw away" its exit status.
And as another user pointed out, the old init system did not save stderr to the logs. systemd is an improvement in this aspect.
Because stderr isn't being hidden under systemd. It's logged to both the journal and the syslog messages file.