4 ms·

I swear, I must be the only person on the planet satisfied with the current state of systemd and GNOME 3. Fedora 23 is my main workstation OS and I have the lea

by snuxoll 10y ago

I swear, I must be the only person on the planet satisfied with the current state of systemd and GNOME 3. Fedora 23 is my main workstation OS and I have the least amount of friction getting my work done on it compared to either Windows or macOS these days. Then again, I mostly spend my day in IntelliJ, DataGrip, PyCharm, Firefox, a terminal, and a Windows VM for when I'm forced to open Visual Studio.

digi_owl 10y ago
Well Fedora is basically systemd central, so no surprises there. Frankly if it continues the way it has, every distro becomes Fedora with the serial numbers filed off...
derefr 10y ago
Count me in too. Among other reasons, because I administer both Linux and OSX systems—and the systemctl(8) utility is basically invocation-for-invocation identical to OSX's launchctl(8), so I never really have to context-switch.
noelsusman 10y ago
You are not alone. I've been running Arch with GNOME as my main workhorse and I couldn't be happier. It just works.
AnonymousPlanet 10y ago
Hmm, my impression of Gnome 3, so far, is that it's kind of a poster boy for ambitious design gone bad, visual as well as functional. On top of that, it seems to be very unstable (every minor update knocked out most of my plugins and I had to re-scramble to get a working desktop back together) and a security train wreck waiting to happen. Who thought it was a good idea to download plugins from a website that are basically JS code mashed into the existing code? Or has that changed recently? After approaching Gnome 3, Cinnamon, and Unity with an open mind, I'm a happy Unity user.
cyphar 10y ago
I'm a maintainer of runC and long-term contributor to Docker. From my perspective, systemd has been nothing but a huge pain from a development perspective. Not because of the UX (which is okay, there's lots of odd stuff there too) but because systemd sets up the system in a way that is ridiculously frustrating for people using low-level kernel primitives directly. If you want to use cgroups and don't want systemd to start messing around with your setup, then you have to go through systemd (which is bad, but it gets worse when you find out that systemd doesn't support all cgroups). Also, systemd has ridiculous defaults. I wrote the pids cgroup code in the kernel, and was surprised when systemd set the default limit for all system services to be 512 tasks and 4096 for all user tasks. Then there's the binary logging format which is such a brain-dead idea, that I'm not even sure how someone actually went through the process of writing the code without ever considering that it was a bad idea. That's just one example of the things that annoy me with systemd. Things mostly work with it, but if you actually want to do something, using it is such a pain. If systemd had stayed as what was promised (a replacement for init scripts) and hadn't gone beyond that (managing your bootloader, binary logging, abusing cgroups and changing the kernel plans for what cgroupv2 should look like, messing around with coredumps, misusing /dev/kmem to actually spam people who are trying to debug kernel issues, an-almost-but-not-quite reimplementation of ntpd, etc). If they didn't have such strong views that they were entitled to be the owners of my system, it might actually have turned out as a good project. Too bad that the management of the project has decided that they should "rewrite all the things, but badly".
- elcritch 10y ago
  I concur as a user of Docker. Trying to get a legacy application running on Docker went smoothly. That is until I tried to start a simple rpcbind service and discovered that during my time away from software development and linux that systemd had taken over plain old kludgy (but hackable!) sysV init scripts. Trying to get a dead simple service running took hours because systemd segfaults instead of gracefully handling and reporting errors. In this case, cgroups wasn't mounted, though why a system init system has a hard requirement on a relatively new kernel feature set not needed in this situation, I can't fathom. Eventually I found a shim for cgroups, but seriously it was a pain. I lost half a night's sleep due to shoddy system level programming you mention from systemd. I'm currently highly eager for FreeBSD 11.0 to reach code freeze. It has a new Docker / linux64 layer and _no_ systemd.

by snuxoll 10y ago

digi_owl 10y ago

Well Fedora is basically systemd central, so no surprises there. Frankly if it continues the way it has, every distro becomes Fedora with the serial numbers filed off...

derefr 10y ago

Count me in too. Among other reasons, because I administer both Linux and OSX systems—and the systemctl(8) utility is basically invocation-for-invocation identical to OSX's launchctl(8), so I never really have to context-switch.

noelsusman 10y ago

You are not alone. I've been running Arch with GNOME as my main workhorse and I couldn't be happier. It just works.

AnonymousPlanet 10y ago

Hmm, my impression of Gnome 3, so far, is that it's kind of a poster boy for ambitious design gone bad, visual as well as functional. On top of that, it seems to be very unstable (every minor update knocked out most of my plugins and I had to re-scramble to get a working desktop back together) and a security train wreck waiting to happen. Who thought it was a good idea to download plugins from a website that are basically JS code mashed into the existing code? Or has that changed recently? After approaching Gnome 3, Cinnamon, and Unity with an open mind, I'm a happy Unity user.

cyphar 10y ago

I'm a maintainer of runC and long-term contributor to Docker. From my perspective, systemd has been nothing but a huge pain from a development perspective. Not because of the UX (which is okay, there's lots of odd stuff there too) but because systemd sets up the system in a way that is ridiculously frustrating for people using low-level kernel primitives directly. If you want to use cgroups and don't want systemd to start messing around with your setup, then you have to go through systemd (which is bad, but it gets worse when you find out that systemd doesn't support all cgroups). Also, systemd has ridiculous defaults. I wrote the pids cgroup code in the kernel, and was surprised when systemd set the default limit for all system services to be 512 tasks and 4096 for all user tasks. Then there's the binary logging format which is such a brain-dead idea, that I'm not even sure how someone actually went through the process of writing the code without ever considering that it was a bad idea. That's just one example of the things that annoy me with systemd. Things mostly work with it, but if you actually want to do something, using it is such a pain. If systemd had stayed as what was promised (a replacement for init scripts) and hadn't gone beyond that (managing your bootloader, binary logging, abusing cgroups and changing the kernel plans for what cgroupv2 should look like, messing around with coredumps, misusing /dev/kmem to actually spam people who are trying to debug kernel issues, an-almost-but-not-quite reimplementation of ntpd, etc). If they didn't have such strong views that they were entitled to be the owners of my system, it might actually have turned out as a good project. Too bad that the management of the project has decided that they should "rewrite all the things, but badly".

elcritch 10y ago
I concur as a user of Docker. Trying to get a legacy application running on Docker went smoothly. That is until I tried to start a simple rpcbind service and discovered that during my time away from software development and linux that systemd had taken over plain old kludgy (but hackable!) sysV init scripts. Trying to get a dead simple service running took hours because systemd segfaults instead of gracefully handling and reporting errors. In this case, cgroups wasn't mounted, though why a system init system has a hard requirement on a relatively new kernel feature set not needed in this situation, I can't fathom. Eventually I found a shim for cgroups, but seriously it was a pain. I lost half a night's sleep due to shoddy system level programming you mention from systemd. I'm currently highly eager for FreeBSD 11.0 to reach code freeze. It has a new Docker / linux64 layer and _no_ systemd.