5 ms·

I've been using Debian for about 10 years now and with all the FUD I was worried about the systemd switch, but its been largely uneventful for me. The only bug

I've been using Debian for about 10 years now and with all the FUD I was worried about the systemd switch, but its been largely uneventful for me. The only bug I've noticed after switching to Jessie is that on one of my systems that has two NICs for some reason both NICs will occasionally end up with the same IP on both NICs. I need to investigate further to figure out the root cause but a reboot always solves the problem for a couple days. I'm confident its not a dhcp server issue. I expected much more grief due to edge cases that weren't planned for but I've yet to find more than the dual nic issue.

deleted 11y ago
[deleted]
currysausage 11y ago
Maybe some glitch in your /etc/udev/rules.d/70-persistent-net.rules?
Scramblejams 11y ago
As a fellow Debian user, I haven't been so lucky. Installing systemd broke sleep on two of my laptops, broke a keyboard[1] (!), broke my /etc/rc.local (stopped executing it on boot)... Not a happy camper. [1] https://github.com/systemd/systemd/issues/340 https://github.com/systemd/systemd/issues/340
- bonzini 11y ago
  At least the keyboard thing is unrelated to the systemd switch, it's just buggy hardware as usual.
  - Scramblejams 11y ago
    No, not unrelated. The hardware may be buggy but it worked fine for years and years, until I installed systemd. Only then did it break. Not good. This is what happens when you throw old software out and try to replace it wholesale -- you stub your toes on all these corner cases that the prior software got right, and now you have to get it right in the new software. And for somebody like me who personally never felt much pain from boot times or writing init scripts, the payoff from the switch has been negative so far.
Touche 11y ago
That's good that you didn't experience any bumps in the road, but did you notice the supposed benefits of systemd yet? Namely faster startup times?
- chimeracoder 11y ago
  > That's good that you didn't experience any bumps in the road, but did you notice the supposed benefits of systemd yet? Namely faster startup times? I have, for what it's worth, but it's worth noting that the biggest benefits of systemd are invisible to end-users. Startup time is the one mentioned most frequently because it's one of the few that's directly observable by end-users, not because it's the most important. For example, systemd makes it much easier to write services (both system and user services), and it definitely has delivered on this promise, since I take advantage of it frequently. Most users still don't have a need for this, though for the ones that do, it's now several orders of magnitude easier to write basic services. But more importantly, systemd is far easier to maintain. That's the real reason distros like Arch switched so rapidly[0]; it wasn't part of some vast systemd conspiracy. They were willing to support sysvinit as long as there were people to maintain them, but it turns out that almost nobody wanted to maintain it. And since it's a volunteer/community-run distro, you can't exactly force people to maintain code they don't want to. There was one guy who posted to the mailing list and was very adamant about providing an AUR package for it, but last I checked, it didn't have much traction. [0] Arch switched back in 2012, long before most other distros. And they deprecated sysvinit within less than a year - far faster than they originally planned - for the above reasons.
  - vezzy-fnord 11y ago
    Please stop perpetuating the false dichotomy of systemd versus sysvinit, it gets tiring. [1] One does not "write services" in systemd. One configures manifests for services in the unit file format, which is internally translated into a Unit object, used for representing various system resources, including services (service actions being queued as another internal unit type, that of jobs). "systemd is far easier to maintain" is not measurable in any way. In fact, given it expects a particular FHS [2], has a lot in the way of needing optimization [3], has a rapid pace of development, adds a complicated transactional dependency system based on seven different job queuing modes and undocumented heuristics, the evidence would point that it is not. Indeed, I do recall Dave Reisner of Arch Linux complaining about systemd's pace and its poor test suite, requiring lots of patching. [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/ [2] http://www.freedesktop.org/software/systemd/man/file-hierarchy.html http://www.freedesktop.org/software/systemd/man/file-hierarc... [3] https://wiki.freedesktop.org/www/Software/systemd/Optimizations/ https://wiki.freedesktop.org/www/Software/systemd/Optimizati...
e12e 11y ago
I had some issues with console initiation, and display in general. But I can't recall if that was before or after release (rough edges are to be expected in "testing", especially when large infrastructure changes are happening). I'm not happy Debian moved to systemd, but I understand why -- and I think they (I wish I could say we, but I didn't really encounter any unreported bugs) did a great job with the transition. I do agree that for many use cases having a simple text-DSL for startup scripts make sense (even for someone reasonably proficient in shell scripts, the code-duplication and complexity of init-scripts are a problem. The duplication might be the worst part -- it requires a lot of job moving the system as a whole forward, and keeping even less-used packages consistent with current "best practices" as they evolve). But that's not an argument for a monolithic init-system -- it just happened that systemd came with a DSL. One could even generate shell scripts based on unit-files[1]. I'm keeping a close eye on the kFreeBSD-port -- I wouldn't mind getting off Linux and systemd, while remaining on Debian. [1] https://github.com/akhilvij/systemd-to-sysvinit-converter https://github.com/akhilvij/systemd-to-sysvinit-converter
- digi_owl 11y ago
  The whole code duplication had long since been solved by other shell based init schemes. Its only sysv thats hanging on to the notion that each script has to be self contained.

deleted 11y ago

[deleted]

currysausage 11y ago

Maybe some glitch in your /etc/udev/rules.d/70-persistent-net.rules?

Scramblejams 11y ago

As a fellow Debian user, I haven't been so lucky. Installing systemd broke sleep on two of my laptops, broke a keyboard[1] (!), broke my /etc/rc.local (stopped executing it on boot)... Not a happy camper. [1] https://github.com/systemd/systemd/issues/340 https://github.com/systemd/systemd/issues/340

bonzini 11y ago
At least the keyboard thing is unrelated to the systemd switch, it's just buggy hardware as usual.
- Scramblejams 11y ago
  No, not unrelated. The hardware may be buggy but it worked fine for years and years, until I installed systemd. Only then did it break. Not good. This is what happens when you throw old software out and try to replace it wholesale -- you stub your toes on all these corner cases that the prior software got right, and now you have to get it right in the new software. And for somebody like me who personally never felt much pain from boot times or writing init scripts, the payoff from the switch has been negative so far.

Touche 11y ago

That's good that you didn't experience any bumps in the road, but did you notice the supposed benefits of systemd yet? Namely faster startup times?

chimeracoder 11y ago
> That's good that you didn't experience any bumps in the road, but did you notice the supposed benefits of systemd yet? Namely faster startup times? I have, for what it's worth, but it's worth noting that the biggest benefits of systemd are invisible to end-users. Startup time is the one mentioned most frequently because it's one of the few that's directly observable by end-users, not because it's the most important. For example, systemd makes it much easier to write services (both system and user services), and it definitely has delivered on this promise, since I take advantage of it frequently. Most users still don't have a need for this, though for the ones that do, it's now several orders of magnitude easier to write basic services. But more importantly, systemd is far easier to maintain. That's the real reason distros like Arch switched so rapidly[0]; it wasn't part of some vast systemd conspiracy. They were willing to support sysvinit as long as there were people to maintain them, but it turns out that almost nobody wanted to maintain it. And since it's a volunteer/community-run distro, you can't exactly force people to maintain code they don't want to. There was one guy who posted to the mailing list and was very adamant about providing an AUR package for it, but last I checked, it didn't have much traction. [0] Arch switched back in 2012, long before most other distros. And they deprecated sysvinit within less than a year - far faster than they originally planned - for the above reasons.
- vezzy-fnord 11y ago
  Please stop perpetuating the false dichotomy of systemd versus sysvinit, it gets tiring. [1] One does not "write services" in systemd. One configures manifests for services in the unit file format, which is internally translated into a Unit object, used for representing various system resources, including services (service actions being queued as another internal unit type, that of jobs). "systemd is far easier to maintain" is not measurable in any way. In fact, given it expects a particular FHS [2], has a lot in the way of needing optimization [3], has a rapid pace of development, adds a complicated transactional dependency system based on seven different job queuing modes and undocumented heuristics, the evidence would point that it is not. Indeed, I do recall Dave Reisner of Arch Linux complaining about systemd's pace and its poor test suite, requiring lots of patching. [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/ [2] http://www.freedesktop.org/software/systemd/man/file-hierarchy.html http://www.freedesktop.org/software/systemd/man/file-hierarc... [3] https://wiki.freedesktop.org/www/Software/systemd/Optimizations/ https://wiki.freedesktop.org/www/Software/systemd/Optimizati...

e12e 11y ago

I had some issues with console initiation, and display in general. But I can't recall if that was before or after release (rough edges are to be expected in "testing", especially when large infrastructure changes are happening). I'm not happy Debian moved to systemd, but I understand why -- and I think they (I wish I could say we, but I didn't really encounter any unreported bugs) did a great job with the transition. I do agree that for many use cases having a simple text-DSL for startup scripts make sense (even for someone reasonably proficient in shell scripts, the code-duplication and complexity of init-scripts are a problem. The duplication might be the worst part -- it requires a lot of job moving the system as a whole forward, and keeping even less-used packages consistent with current "best practices" as they evolve). But that's not an argument for a monolithic init-system -- it just happened that systemd came with a DSL. One could even generate shell scripts based on unit-files[1]. I'm keeping a close eye on the kFreeBSD-port -- I wouldn't mind getting off Linux and systemd, while remaining on Debian. [1] https://github.com/akhilvij/systemd-to-sysvinit-converter https://github.com/akhilvij/systemd-to-sysvinit-converter

digi_owl 11y ago
The whole code duplication had long since been solved by other shell based init schemes. Its only sysv thats hanging on to the notion that each script has to be self contained.