The State Of Systemd In Debian (2016)

[phoronix]

Phoronix: The State Of Systemd In Debian (2016)

Debian developer Michael Biebl has presented a status update on systemd in Debian at this week's DebConf 16 event in Cape Town, South Africa...

http://www.phoronix.com/scan.php?page=news_item&px=Debian-systemd-Status-2016

[Karl Napf]

http://saimei.acc.umu.se/pub/debian-meetings/2016/debconf16/systemd_in_Debian_a_status_update.webm

[edmon]

Resistance to systemd is futile. It really is the best way to go. I just wish It wasn't going through growing pains in "stable" releases... same with PulseAudio actually. Feels like we're being used as beta testers without our permission or desire.

I just love it when someone on a message board tells me to quit complaining and fill out a bug report. Unfortunately you have to fill out one of my forms to request I fill out one of your form, and that just isn't happening. Oh well... free as in... er, um... I forget.

Resistance is meaningless, systemd will eat itself....

[SystemCrasher]

Actually this guy tells right things. Systemd heading right direction and damn, it quite amazing it brings my debian systems on ARM in ~5 seconds while solving shitload of difficult engineering problems in one shot. Too bad not all debian packages and maintainers care about minimal systems like this.

On side note, when it comes to minimal systems and Debian, has someone managed to get rid of perl in minimal systems without really odd package manager hacks? It isn't really needed, especially in "embedded" installs. There is e.g. cdebconf, but Debian dependencies are just as fancy as their, erm, "bug tracker" and it still fails to replace debconf+perl for really obscure reasons. Well, unless I resort to overriding package manager hardcore ways. Which works, but a bit odd way of building Debian images.

[starshipeleven]

I just love it when someone on a message board tells me to quit complaining and fill out a bug report. Unfortunately you have to fill out one of my forms to request I fill out one of your form, and that just isn't happening. Oh well... free as in... er, um... I forget.

Another guy that didn't understand what GPL is all about. It's not about user freedom, but about source code freedom.
Freeloaders never get any say, it's ok.

[liam]

Resistance to systemd is futile. It really is the best way to go. I just wish It wasn't going through growing pains in "stable" releases... same with PulseAudio actually. Feels like we're being used as beta testers without our permission or desire.

I just love it when someone on a message board tells me to quit complaining and fill out a bug report. Unfortunately you have to fill out one of my forms to request I fill out one of your form, and that just isn't happening. Oh well... free as in... er, um... I forget.

Think about what you are saying, for a moment.
You downloaded a free operating system and installed it on your computer. Thus you chose it.
Even assuming they owe you anything beyond the union of license requirements and community promises, what would you expect them to do? A survey? How is a survey (directed to a broad audience) the best way to determine the technical direction of a project?
From their side, how else are they going to see if the software works without it getting extensive testing?
Lastly, you can choose to use other software (even if other distros, or go LFS, if you want).

[liam]

Resistance to systemd is futile. It really is the best way to go. I just wish It wasn't going through growing pains in "stable" releases... same with PulseAudio actually. Feels like we're being used as beta testers without our permission or desire.

I just love it when someone on a message board tells me to quit complaining and fill out a bug report. Unfortunately you have to fill out one of my forms to request I fill out one of your form, and that just isn't happening. Oh well... free as in... er, um... I forget.

Think about what you are saying, for a moment.
You downloaded a free operating system and installed it on your computer. Thus you chose it.
Even assuming they owe you anything beyond the union of license requirements and community promises, what would you expect them to do? A survey? How is a survey (directed to a broad audience) the best way to determine the technical direction of a project?
From their side, how else are they going to see if the software works without it getting extensive testing?
Lastly, you can choose to use other software (even if other distros, or go LFS, if you want).


SystemCrasher It's funny you should mention this b/c I was looking at what's coming up in fedora 25 and I found this:

https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl

Depending on the results, Debian may well follow suit.

[unixfan2001]

I just love it when someone on a message board tells me to quit complaining and fill out a bug report. Unfortunately you have to fill out one of my forms to request I fill out one of your form, and that just isn't happening. Oh well... free as in... er, um... I forget.

I have no clue what the heck you're talking about.
Is it too hard to sign up for Github and report the issue there?

Another guy that didn't understand what GPL is all about. It's not about user freedom, but about source code freedom.
Freeloaders never get any say, it's ok.

Huh? That's news to me.
AFAIK, the GPL has always been about user freedom at the expense of developer freedom.

Not that the above complaint would've anything to do with either.

People being too lazy or incompetent to post bug reports aren't exactly a licensing issue. I met them on every piece of software I've ever been working on. Whether that be OSS, FOSS or proprietary (yes. Even people who got paid for testing the freaking software failed to file proper bug reports).

[darkfires]

systemd might be ok for your slowass ARM stuff, but it's a huge pain in the ass and a time waster when you are dealing with servers. It's got a long way to go and as far as I'm concerned has no business being on production systems. I work at a large datacenter and it causes a lot of problems that you would not see otherwise.

I lost count of how many times I've seen it throw a system on boot into emergency shell, randomly and for no good reason, and how many times networking shit randomly stopped working. 99% of servers don't care much about the faster boot time as they only get rebooted for kernel patches. We don't have many customers requesting Debian but I've seen a few completely hose their server leaving it unbootable messing with systemd. systemd seems to work a little better on CentOS 7 than debian with what I've seen personally...

All I will say is I'm thrilled that FreeBSD will never use systemd, I'm running FreeBSD on as much shit as I can these days just to stay the fuck away from that garbage.
The funny part? FreeBSD boots faster than debian with systemd on the same hardware. Ever notice who employs the main systemd developer?

Red Hat. What's their primary source of revenue? Support. Is it strange that systemd has been out for quite a while now and it's still full of stupid issues? I think it's on purpose if you ask me. Just for comparison out of all the CentOS 6.x machines we have, you NEVER see any issues related to init. CentOS 7.x and Debian 8.x, countless, enough that we avoid it as much as possible.

It's mind blowing so many of you think it's great but I'm willing to bet most don't use it in production environment (desktop's DON'T count)

[niner]

[QUOTE=darkfires;n882989]It's mind blowing so many of you think it's great but I'm willing to bet most don't use it in production environment (desktop's DON'T count)/QUOTE]

On our SUSE based servers systemd actually improved reliability and manageability. The fact alone that it can reliably kill processes with all their unknown and even unpredictable children (think for example CGI processes, yes they do still have their uses occasionally) finally made cluster failovers work in practice and not just in test cases.

Thanks to systemd-init being a real service manager, we could get rid of daemonization code that previously had more than one bug and which developers dreaded to even touch because it was really a bunch of arcane invocations. Need something running as a daemon? That's literally just a while (1) { } now. Logging is just printing whatever you want to STDERR without even the need for any prefix or time stamps since journald already knows where the message is from and when it came.

The simple and yet powerful unit files help avoid stupid bugs we had in init scripts for our own software like sudo swallowing environment variables set earlier in the init script. Speaking of environment - that services always start from a very well known state instead of inheriting the environment of the user running the init script got us rid of issues where software would run perfectly fine when started manually but throw errors when ran as part of system boot. There's just so many things you don't have to thing about anymore that a junior could easily write service files for all our home grown tools.

In the years since we upgraded to systemd, we've never had any boot or network issues like you've described. Maybe SUSE just did a much better job at integrating systemd? Remember that debian came very late to the party.