3 ms·

has anyone used Fedora 23 with Gnome, Wayland and Systemd ? I see a lot of religious handwaving around systemd, but F23 shows you the future of Linux desktop..

has anyone used Fedora 23 with Gnome, Wayland and Systemd ? I see a lot of religious handwaving around systemd, but F23 shows you the future of Linux desktop.. and it is brilliant. Right from network interfaces that dont change names when you swap hardware (powered by systemd) to making it damn easy to file crash bugs (using coredumpctl) to checking what services have failed "systemctl --failed" to a more secure graphical desktop (rootless gnome with systemd) - it makes for a better linux. Deploying web-services on systemd is so much better - think supervisord, but much more stable and robust. Even docker machines using systemd is great (in fact it is a great way to explore systemd).

okasaki 11y ago
I think this is what annoys me most about systemd. All of the advantages you list seem extremely niche to me. I mean network interfaces that don't change names? I think in over 15 years of using Linux I have never had a problem with this, and if I did I'm guessing it would be a) obvious b) trivial to fix. Same with the other stuff. To get these niche features we need to install a very complex, opaque, fragile and verbose set of tools that throw away most of what I've learned in my 15 years. Blah!
- simoncion 11y ago
  > I think in over 15 years of using Linux I have never had a problem with this, and if I did I'm guessing it would be a) obvious b) trivial to fix. I have run into this. Two wired Ethernet NICs in a system. After a kernel upgrade, the module load order of each NIC got swapped, and the name of each NIC changed. Took me a while to track that one down. :P For 99.9% of desktop users (and -I suspect- many servers), this doesn't ever matter, and the "predictable" names are substantially less predictable and discoverable than 'eth0' or 'wlan0' or whatever. Additionally, if you move a NIC in your system to another expansion slot in the system, its name will change. So, there's that to remember about this particular scheme. NOTE: I'm not trying to claim that it's not helpful! The "predictable network interface" naming scheme solves a real problem. It's just that it -like most things- creates a few unique problems of its own. ;)
simoncion 11y ago
> ...network interfaces that dont change names when you swap hardware... I assume you're talking about udev's "Predictable Network Interface Names". [0] That's a feature of udev, and -IIRC- has been around since shortly after udev's repo got merged into systemd's repo, but quite a bit before it became obvious that the Systemd Cabal wasn't going to put much -if any- particular effort into making it easy for folks to use udev without systemd. While -due to inertia- I do use it on my systems, it doesn't provide value on systems that don't have more than one network interface of a given type. [1] > ...to making it damn easy to file crash bugs... I've been doing exactly this in KDE since... KDE 4.1? 4.2? So, this would be back in the ~2008->2009 time frame. I have fuzzy memories of a crash reporter in KDE 3, but -back then- I didn't build my systems with debugging info or frame pointers, so the backtraces were always useless and -thus- went unsubmitted. > ...to checking what services have failed... rc-status --crashed or rc-status --all --crashed does the same for me on my OpenRC systems. Every sysvrc replacement that's not a toy provides this functionality. > ...to a more secure graphical desktop... I'm very glad that the Wayland folks are making good progress with their work. > Deploying web-services on systemd is so much better... Can you be specific here? There are a whole host of service supervision systems out there of varying quality and feature sets. [0] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ http://www.freedesktop.org/wiki/Software/systemd/Predictable... [1] After all, you can name your single wired ethernet NIC eth0, your single WiFi NIC wlan0, and your single USB-connected cellular radio usb0. That's far easier and more predictable than reading the output of lspci to figure out the name of your NIC. (If you get the urge to point out the cases in which the NIC-physical-path-dependent naming scheme does help, please carefully re-read the 'graph to which this footnote was attached.)
- sandGorgon 11y ago
  >> Deploying web-services on systemd is so much better... >Can you be specific here? There are a whole host of service supervision systems out there of varying quality and feature sets. True - but that is a good question by itself right ? Why - when you already had sysv and upstart and everything. Supervisord seems to be very popular that is very, very similar to systemd in its working (same concept of unit files, declarative language,etc). If you like supervisord, then systemd is just a short hop away. OpenRC would do the same - but are you claiming that openrc is BETTER than systemd ? Because systemd is making that claim. What I'm failing to understand is how is systemd bad ? it is making my linux machine extremely stable and working with it (creating new unit files) is extremely intuitive. Where is it making everyone's life hard ? the old way of "service nginx restart" still works. "dmesg" still works...
Gonzih 11y ago
yeah, i had similar experience while deploying production stuff to systemd. It does not hurt anymore, it has lot reliable tooling that just works. I understand that it's not "unix way" as people like to say. For me that also means "being reliable". Systemd gives me as an application developer everything i need and takes a lot of pain away. I'm happy.
Sanddancer 11y ago
I think the key word there is desktop. The systemd folks are desktop folks first and foremost, server operations be damned. coredumpctl requires root access, which means one has to be much more diligent in scripting automatic actions to handle core dumps. Failed services again are something that any supervisor service can handle and report -- launchd can get all that information from launchctl. Rootless X is something OpenBSD has had for years, through better access control than linux devs seem to be able to be bothered with. The biggest problem with systemd is its mediocrity. The journal is an interesting idea, but it's inflexible. Its insistence on json and internal formats mean that it doesn't work with the rest of the extant logging infrastructure tools that exist, so if you want to have a dedicated log server, you have to run essentially two syslogds. Its core dump misfeatures make it harder to use extant access control features to manage files. Its unit files don't allow for any sort of extensibility, so adding things like a configtest command for a unit are impossible. In short, its oversimplified itself to the point where it adds a huge management load just to keep servers where they were.
- digi_owl 11y ago
  > server operations be damned. I think it depends somewhat on how one define server. The traditional hardware on shelf doing their designated task (i have seen it be referred to as "pet" servers) not so much, no. But they do seem to heavily support container and virtual machine based servers ("cattle", to go with the pet reference earlier).

okasaki 11y ago

I think this is what annoys me most about systemd. All of the advantages you list seem extremely niche to me. I mean network interfaces that don't change names? I think in over 15 years of using Linux I have never had a problem with this, and if I did I'm guessing it would be a) obvious b) trivial to fix. Same with the other stuff. To get these niche features we need to install a very complex, opaque, fragile and verbose set of tools that throw away most of what I've learned in my 15 years. Blah!

simoncion 11y ago
> I think in over 15 years of using Linux I have never had a problem with this, and if I did I'm guessing it would be a) obvious b) trivial to fix. I have run into this. Two wired Ethernet NICs in a system. After a kernel upgrade, the module load order of each NIC got swapped, and the name of each NIC changed. Took me a while to track that one down. :P For 99.9% of desktop users (and -I suspect- many servers), this doesn't ever matter, and the "predictable" names are substantially less predictable and discoverable than 'eth0' or 'wlan0' or whatever. Additionally, if you move a NIC in your system to another expansion slot in the system, its name will change. So, there's that to remember about this particular scheme. NOTE: I'm not trying to claim that it's not helpful! The "predictable network interface" naming scheme solves a real problem. It's just that it -like most things- creates a few unique problems of its own. ;)

simoncion 11y ago

> ...network interfaces that dont change names when you swap hardware... I assume you're talking about udev's "Predictable Network Interface Names". [0] That's a feature of udev, and -IIRC- has been around since shortly after udev's repo got merged into systemd's repo, but quite a bit before it became obvious that the Systemd Cabal wasn't going to put much -if any- particular effort into making it easy for folks to use udev without systemd. While -due to inertia- I do use it on my systems, it doesn't provide value on systems that don't have more than one network interface of a given type. [1] > ...to making it damn easy to file crash bugs... I've been doing exactly this in KDE since... KDE 4.1? 4.2? So, this would be back in the ~2008->2009 time frame. I have fuzzy memories of a crash reporter in KDE 3, but -back then- I didn't build my systems with debugging info or frame pointers, so the backtraces were always useless and -thus- went unsubmitted. > ...to checking what services have failed... rc-status --crashed or rc-status --all --crashed does the same for me on my OpenRC systems. Every sysvrc replacement that's not a toy provides this functionality. > ...to a more secure graphical desktop... I'm very glad that the Wayland folks are making good progress with their work. > Deploying web-services on systemd is so much better... Can you be specific here? There are a whole host of service supervision systems out there of varying quality and feature sets. [0] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ http://www.freedesktop.org/wiki/Software/systemd/Predictable... [1] After all, you can name your single wired ethernet NIC eth0, your single WiFi NIC wlan0, and your single USB-connected cellular radio usb0. That's far easier and more predictable than reading the output of lspci to figure out the name of your NIC. (If you get the urge to point out the cases in which the NIC-physical-path-dependent naming scheme does help, please carefully re-read the 'graph to which this footnote was attached.)

sandGorgon 11y ago
>> Deploying web-services on systemd is so much better... >Can you be specific here? There are a whole host of service supervision systems out there of varying quality and feature sets. True - but that is a good question by itself right ? Why - when you already had sysv and upstart and everything. Supervisord seems to be very popular that is very, very similar to systemd in its working (same concept of unit files, declarative language,etc). If you like supervisord, then systemd is just a short hop away. OpenRC would do the same - but are you claiming that openrc is BETTER than systemd ? Because systemd is making that claim. What I'm failing to understand is how is systemd bad ? it is making my linux machine extremely stable and working with it (creating new unit files) is extremely intuitive. Where is it making everyone's life hard ? the old way of "service nginx restart" still works. "dmesg" still works...

Gonzih 11y ago

yeah, i had similar experience while deploying production stuff to systemd. It does not hurt anymore, it has lot reliable tooling that just works. I understand that it's not "unix way" as people like to say. For me that also means "being reliable". Systemd gives me as an application developer everything i need and takes a lot of pain away. I'm happy.

Sanddancer 11y ago

I think the key word there is desktop. The systemd folks are desktop folks first and foremost, server operations be damned. coredumpctl requires root access, which means one has to be much more diligent in scripting automatic actions to handle core dumps. Failed services again are something that any supervisor service can handle and report -- launchd can get all that information from launchctl. Rootless X is something OpenBSD has had for years, through better access control than linux devs seem to be able to be bothered with. The biggest problem with systemd is its mediocrity. The journal is an interesting idea, but it's inflexible. Its insistence on json and internal formats mean that it doesn't work with the rest of the extant logging infrastructure tools that exist, so if you want to have a dedicated log server, you have to run essentially two syslogds. Its core dump misfeatures make it harder to use extant access control features to manage files. Its unit files don't allow for any sort of extensibility, so adding things like a configtest command for a unit are impossible. In short, its oversimplified itself to the point where it adds a huge management load just to keep servers where they were.

digi_owl 11y ago
> server operations be damned. I think it depends somewhat on how one define server. The traditional hardware on shelf doing their designated task (i have seen it be referred to as "pet" servers) not so much, no. But they do seem to heavily support container and virtual machine based servers ("cattle", to go with the pet reference earlier).