Debian 8.7 Released (debian.org)

Debian 8.7 has been released. An anonymous reader quotes Debian.org: This update mainly adds corrections for security problems to the stable release, along with a few adjustments for serious problems. Security advisories were already published separately and are referenced where available. Please note that this update does not constitute a new version of Debian 8 but only updates some of the packages included.

There is no need to throw away old "jessie" CDs or DVDs but only to update via an up-to-date Debian mirror after an installation, to cause any out of date packages to be updated. Those who frequently install updates from security.debian.org won't have to update many packages and most updates from security.debian.org are included in this update.
86 packages have been updated -- including some fixes for systemd. ("Rework logic to determine when we decide to add automatic deps for mounts; various ordering fixes for ifupdown; systemctl: Fix argument handling when invoked as shutdown...")

Comments

systemd

[Anonymous Coward]

YOU WERE THE CHOSEN ONE DEBIAN.

I will say that ZFS on Root, out of the box, is quite nice with FreeBSD.

Re:systemd

[msk]

If FreeBSD worked with my tuner devices (cx88 PCI cards and an xc5000 USB device) together with MythTV, I'd consider switching. Might be time to check again.

Re:systemd

[0100010001010011]

cx88 PCI cards

http://corona.homeunix.net/cx8...

https://gist.github.com/dreamc...

xc5000 USB device)

https://wiki.freebsd.org/Webca...

Requires dvb-fe-xc5000-1.6.114.fw firmware

https://www.linuxtv.org/downlo...

MythTV

http://www.freshports.org/mult...

Re: systemd

[Anonymous Coward]

There are several Linux distributions without systemd.
I've been using Manjaro openrc for a while now. There is also an Arch version now. And when it will have matured a bit Devuan will be a good candidate too.

Re: systemd

[Anonymous Coward]

Slackware, too

Re:systemd

[Anonymous Coward]

Works good for a while, but eventually crashes

v4l2: select timeout 0 0
v4l2: select timeout 0 0
v4l2: select timeout 0 0
v4l2: select timeout 0 0
v4l2: select timeout 0 0

Re: systemd

[unixisc]

There are, but unless something is explicitly built for that, like Devuan, it's more that they are behind a few releases, and are just starting to get systemd

Re:systemd

[ls671]

You sound just like an apple fan boy. I have noticed similarities between both. Not that I don't like BSD, on the contrary.

link:
http://www.slackware.com/

Re: systemd

[Anonymous Coward]

They are built exactly for that. As the name 'openrc' suggests.

Estimated time until systemd-related flame war...

[Anonymous Coward]

...5 parent posts. Tops.

One can hope

[lucm]

some fixes for systemd

There's only one fix for systemd: delete it.

Of course it has to be done right. 3 easy steps:

1) run Lennart Poettering's hard drives through a shredder
2) track down every person who ever cloned the source repo and burn their computers, tape backup and usb sticks
3) track down every cloud provider used by every single person who cloned the repo and burn their datacenters.

Losing all those cloud providers could drive us back a few decades as a connected society but it would be worth it. We need to walk away from the madness and find a better way forward.

Re:One can hope

[Anonymous Coward]

I like systemd, but I went through the SMF transition with Solaris and the complaints were basically the same. Systemd is lightyears better than anything it replaced. If you're an honest person, you'd probably come to the same conclusion.

Re:One can hope

[Anonymous Coward]

This is why I switched my company over to CentOs

Re:One can hope

[Anonymous Coward]

Do tell one reason how Systemd has actually helped something? It it were really so great, It would have not interrupted my and other peoples work so often.

Re: One can hope

[Anonymous Coward]

I had high hopes for systemd. I thought it would be like launchd on OS X, which has never caused me any problems. But systemd was nothing like that. It has caused me nothing but problems. It's a lot like GNOME 3. The potential is there, but the reality ends up being awful. I'm saddened that all real Linux distros now force it. I don't want to use a niche distro like Devuan.

Re:One can hope

[Anonymous Coward]

There's only one fix for systemd: delete it.

Of course it has to be done right. 3 easy steps:

1) run Lennart Poettering's hard drives through a shredder
2) track down every person who ever cloned the source repo and burn their computers, tape backup and usb sticks
3) track down every cloud provider used by every single person who cloned the repo and burn their datacenters.

Losing all those cloud providers could drive us back a few decades as a connected society but it would be worth it. We need to walk away from the madness and find a better way forward.

You forgot to add "Run Redhat through a shredder".

Re:One can hope

[geek]

And here its made my life much easier and I've had zero issues with it. I hate Pottering as much as anyone but if something he's done has made my life easier, the way systemd has, then kudo's to him.

Your post however contributes nothing.

Re:One can hope

[lucm]

Your post however contributes nothing.

My post doesn't try to take Linux over one feature at a time by replacing things that were not broken with more and more legs of the same octopus. I'm happy if systemd made your own life easier but that doesn't mean everyone should bend over and take it quietly.

Re:One can hope

[lucm]

You forgot to add "Run Redhat through a shredder".

I like Red Hat and I appreciate all they've done for open-source in the enterprise, but the desktopification of core Linux aspects is a bad thing. It's fascinating to see how Microsoft took a desktop o/s and shoehorned it into a server product, while Red Hat is taking the perfect server and adding stuff like systemd to make it more convenient for desktop users.

systemd is bad for servers. It adds nothing, just makes everything brittle and clunky. Maybe it's awesome for plug & play devices and soundcards and window managers but none of that is relevant on servers. No wonder even in the CentOS docker images it's not enabled by default - it's USELESS.

Re:One can hope

[whodunit]

... was sysvinit really that better? I was under the impression that you're picking between a brand-new pile of shit, or an old-fashioned and badly outdated pile of shit.

Re:One can hope

[sjames]

The old pile of shit was willing to keep its fingers out of other people's pies if you wanted to try something else along side it.

It also understood imperatives. If you tell it run something NOW, it does just that, every time.

Re:One can hope

[Anonymous Coward]

Some may say that we're too extreme, but all we want is gnu/linux systems that boot clean

Re:One can hope

[Motherfucking Shit]

More importantly to me, I've used the old pile of shit for 20 years. I know how it works, I know its quirks and shortcomings, and I'm comfortable with all of that.

I have no particular aversion to trying new things. I ran ntpd for years, now I use chrony. I ran exim for years, now I use postfix. I ran apache for years, now I use both apache and nginx. I ran cvs for years, then svn for years, and am now aboard the git train. I was able to gradually step through all of those changes and take time to learn them properly. And when something went wrong along the way, the problem was isolated and I could troubleshoot it in isolation.

systemd on the other hand wants to implant itself underneath every aspect of the OS like a kludgey layer of Elmer's paste, where even such basic functionality as DNS resolution wants to worm its way through an unnecessary and complex intermediary service. Not to mention that when systemd goes tits up, it has a tendency to take the entire machine with it.

No thanks.

Re:One can hope

[Anonymous Coward]

... was sysvinit really that better?

sysvinit is an init system. If systemd had simply tried to be a good init system, it might have been all right as a replacement. The trouble is that it is init system plus kitchen sink. It is hostile to the concept of modularity.

Re:One can hope

[Anonymous Coward]

Do tell one reason how Systemd has actually helped something?

Systemd has helped raise awareness of the *BSDs.

Many former Linux desktop users who were driven away by systemd have ended up using FreeBSD. Many who ran Linux servers have started using OpenBSD instead. Those who ran Linux on older or less-powerful hardware have discovered the joys of NetBSD.

Systemd has turned out to be one of the best advertising campaigns for the *BSDs.

Re:One can hope

[nadaou]

What was a better way, the UNIX way, was having multiple interchangeable options for any particular cog in the machine. No reliance on a sole supplier. In Debian even HURD or BSD could be swapped out for the Linux kernel in a semi-official, if experimental, way.

Avoiding a mono-culture has huge industry implications for surviving horrific infrastructure bugs, engaging competition and A/B tests, and filling niches with the best tool for the day's particular job. If systemd was truly optional in official Debian there would be no crisis, no endless talking past each other hate filled forum threads. Instead there was an unfortunate slim-vote by a Debian technical committee and major community damage to the project with a large number of DDs and contributors losing passion for the greater project. Which is the real horror and tragedy of the thing.

Re:One can hope

[Anonymous Coward]

Mods shouldn't mod something down just because it hurts their feelings. Like it or not, systemd *did* raise awareness of the *BSDs.

Re:One can hope

[Anonymous Coward]

We never had that much modularity in the first place. Most distros all used the same core components anyway. But if you want to you can still disable pretty much any systemd component and replace it with whatever you want. I do that in Docker, I have lots of containers that use only systemd as init and journald, and my app. Nothing else is running in the container, and if I wanted something more I could easily have systemd start it for me.

Re:One can hope

[93 Escort Wagon]

CentOS 7 is systemd-based as well.

Re:One can hope

[Anonymous Coward]

A UID of 1099??

Isn't that like, an IRS form or something (Apologies; couldn't resist=)

Re:One can hope

[Anonymous Coward]

And here its made my life much easier and I've had zero issues with it. I hate Pottering as much as anyone but if something he's done has made my life easier, the way systemd has, then kudo's to him.

Easier? Probably millions of wasted man hours and you call it easier? Whether it's the broken documentation (which is voluminous but useless because it misses key facts all over the place - a bit like Microsoft documentation; written by documentation "specialists" so it looks pretty but doesn't actually tell you what you need to know because the "specialists" are ignorant about the system they're supposed to be writing about) or the broken dependency management (which has race conditions all over the place, has no sensible way of dealing with dependency trees in fstab and has a bizarre view of timeouts) or broken daemon management (it'll frequently kill daemons for no good reason and doesn't actually use process groups in a rational way) or the broken configuration language (which claims to be state free but isn't and provides no mechanism for dealing with state that isn't associated with an individual process) or the lying systemd promoters (it's quite clear now that they lied through their teeth to get systemd into mainstream linux) etc. etc.

Your post however contributes nothing

Actually it's your post that contributes nothing.

Re:One can hope

[Anonymous Coward]

>Do tell one reason how Systemd has actually helped something? It it were really so great, It would have not interrupted my and other peoples work so often.

Helps with getting remote root.
Helps alot.

Re:One can hope

[johannesg]

"The UNIX way" was to have multiple, not quite compatible, complete operating systems from multiple vendors such as HPUX, Solaris, IRIX, etc. Porting your software between those was a considerable effort, and in fact a whole standardisation body (posix) has sprung up around efforts to make those systems at least nominally compatible. And in later years, the Linux way was quite similar, with LSB attempting to keep distributions at least nominally compatible with each other, but the effort of porting an application from one distribution to another still going by the name of "porting".

I have no idea in which dimension your UNIX way happened, but it wasn't this one.

Re:One can hope

[Anonymous Coward]

modprobe +1 insightfull oh wise master

Re:One can hope

[Anonymous Coward]

The old init system at least succeeded in bringing up and down the machine every time. With systemd it is a time of excitement after each update if it has decided to break booting with some stupid 90 second blocking wait error. And since few updates ago, the systemd does not shut down my laptop anymore. It just goes to 100% CPU loop and blocks forever. No relevant messages on screen or in logs.

Re:One can hope

[thegarbz]

The old pile of shit was willing to keep its fingers out of other people's pies if you wanted to try something else along side it.

Oh? I never realised that systemd was the only way to start and stop programs? You want to use systemd just to boot the system and then revert to using xinetd to dynamically start your services, followed by a lot of rc scripts (fun fact, systemd can simply run them for you). Then you go right ahead. It's a very strange form of sadism but I'm not going to judge.

It also understood imperatives. If you tell it run something NOW, it does just that, every time.

Yep, one of it's worst features that lead to a lot of dependency related headaches and failed startups simply because something was done in the wrong order.
But again if you wish to generate errors there's a handy command for you:

"systemctl start process_i_want_to_screwup --job-mode=ignore-dependencies --force"

But I get it, reading a manual is hard.

Re:One can hope

[sjames]

Actually, I want to to use other tools to help boot the system. With sysvinit, I can easily plug modules at will.

because something was done in the wrong order.

I know it sounds like a really radical idea, but howsabout just specifying the right order?

But here's an example: I was testing a system with BTRFS doing mirroring. As part of the test, I dropped one of the disks to simulate a failure. Systemd flatly refused to start in degraded mode. It dropped to the shell every time. There was no way to tell it "Just mount the damned thing and let me worry about it". So much for high availability. Under sysV, I just added the degraded option and it worked every time. If I want to wait an arbitrary amount of time for all the drives to spin up, I can do that in the mount script with no difficulty.

Literally anything systemd can do could already be done using simple helpers called by sysV. You even provided an example yourself.

Re:One can hope

[Anonymous Coward]

Your post however contributes nothing.

OMFG! And your post does? Kissing Pottering's ass? Go fuck yourself, Geek.

Re:One can hope

[Anonymous Coward]

Christ Almighty. Overreact much? If you don't like it, either switch to a distro that doesn't use it or move to BSD.

I was expecting systemd to be a steaming turd based on all the hysterical screaming and tears from parts of the Linux community. The reality is I've been using it at home just fine for a while now, and we have production servers at work using it without a hitch.

Re:One can hope

[nadaou]

You are twisting the meaning to fit a particular straw man you want to knock down. I obviously wasn't talking about Berkley vs. Bell Labs UNIX as being interchangeable cogs and was talking about the philosophy governing the interaction of the various sub and support systems within a modern Linux deployment.

Re:One can hope

[Sesostris III]

systemd is bad for servers. It adds nothing...

My understanding (which may be wrong) is that the impetus behind SystemD from the server side might be containers. Currently, these can't be managed centrally (AFAIK), but with SystemD...

Just something I heard in passing during a Docker presentation, so I can't provide references.

Re:One can hope

[jez9999]

Easier? Probably millions of wasted man hours and you call it easier?

Microsoft keep doing that with their new "features" and people keep paying them.

Re:One can hope

[Anonymous Coward]

Forget it. This is most a Fedora dev/maintainer, and they are as anti-choice as it gets.

There is only one true Linux for them and that is Fedora+Freedesktop+Gnome.

Anything else needs to become a derivative of that combo, or die a fiery death...

Re:One can hope

[Anonymous Coward]

The only way I can read your original comment is ‘you can swap out any part, including the kernel, and this is the Unix way’. As Johannes said, this a) isn't true and was never true and b) has never been the Unix way. What you said was wrong, and there's little point in claiming you meant to say something else.

Re:One can hope

[rl117]

Yes, we did have that modularity.

We previously had these components:

• sysvinit (low-level process spawning and runlevel change triggering; all done from /etc/inittab)
• sysv-rc (intermediate-level script to effect runlevel changes by batch invoking rc.d scripts)
• initscripts (high-level rc.d scripts to do the actual work of bringing the system up or down, with helper scripts to unify logic shared between multiple scripts)
• package-specific scripts whch use the initscripts helpers and to some package-specific action
• insserv and startpar, to use LSB script headers to compute a global dependency graph with make-like syntax and allow sysv-rc to start the scripts up in parallel with proper dependency constraints

Not only is it modular, the system is fully composable, allowing the admin to build each layer upon each layer to their own liking. The layers are not tightly-coupled, and it's entirely possible to replace any or all of the layers:

• You can swap out sysvinit but retain sysv-rc and all higher-level parts; example: s6
• You can swap out sysv-rc; example: file-rc which gives a bsd-style startup with a single file to configure what starts, or daemontools which runs directly from inittab and does process supervision
• You can replace the initscripts with whatever you like, but retain sysvinit; example: openrc, which replaces sysv-rc and uses its own scripts

When people complain about sysvinit being old and outdated, these claims are usually considering the sysvinit+sysv-rc+initscript triad as a single entity. sysvinit is old, but it's a tool with just two purposes: running specified programs and runlevel switching. You can build anything you want on top of that. It does exactly what it was designed to do, and *only* what it was designed to do. It's not broken, and never was. If you want more functionality, you build that on top of it.

Some parts of the old system were crusty, for example dynamic networking configuration. But the vast majority worked pretty well, and pretty efficiently. And it would have been perfectly possible to fix those issues, with vastly less effort and disruption than throwing it all away and breaking much backward compatibility in the name of inter-distribution uniformity (and consequent stagnation).

Note that while common distributions came with their default, it was absolutely possible to run with all sorts of different combinations of components; Debian supported several. file-rc was a supported alternative to sysv-rc, and daemontools and other alternatives were also available. It's this very flexibility which allowed systemd to be swapped in relatively easily. But consider that once systemd was adopted, the vast majority of this flexibility was lost. The low-level init, the rc runner and the initscripts are all in one place, and it's no longer possible to swap one part for another or tweak one little bit. It's all or nothing, and that will effectively entrench it. As an ex-Debian sysvinit/sysv-rc/initscripts maintainer, I wasn't dictating that you use them all together. You want to use openrc, or daemontools or s6? Go for it, you don't need me to approve it, you do what you like. Want to change the initscripts around to do something different, be my guest. We took care not to break any custom setups on upgrade as well, e.g. preserving file-rc configuration when adding/removing/upgrading packages, as well as helper script API stability. Contrast that with the top-down dictatorial approach which comes from the systemd people: you'll use the system the way we tell you to, and no, we don't approve of you doing anything non-standard unless we like it (and good ideas only come from us, so forget it). And if you do change stuff and it breaks, that's 100% your fault since we don't care to consider this. That's the real difference, the attitude and thought behind the design, and how that affects your freedom to use your system as you see fit. And that's one major reason why my servers now run FreeBSD.

Re:One can hope

[rl117]

Yep, exactly.

I used Linux exclusively from the mid-90s until almost exactly two years back. I was aware of the BSDs, occasionally read about them and once installed it for a few hours just to see, but never had any real reason to bother with them. Seemed like it would be a lot of pain for a worse experience, particularly when you had to build all the ports and cope with worse hardware compatibility.

One of my work colleagues is a long-time Debian user. For the last 18 months, his servers are running OpenBSD.

When it came time to upgrade from wheezy to jessie, I had the option of futzing with the system to retain or reinstall sysvinit, but since it's clearly not supported properly and several key packages deliberately depend upon systemd, you get an inferior experience which is likely to continue to regress. So I looked at FreeBSD, anticipating it would be awful. However, what a revelation. With the new pkg tool, installing and upgrading packages is on a par with apt, and with 25000 packages, it's rare to find anything missing, being at least as comprehensive as the Debian archive. It's also gratifyingly up-to-date for the most part, and if you track the weekly (rather than default quarterly) builds, you're pretty much always up to date with the tools you need (e.g. cmake, clang for me). And then there's ZFS, the "killer feature". Absolutely superb, and really well integrated; vastly easier to use and more featureful than the Linux port. This alone makes it worth using for archiving and serving files.

While there are plenty of people who cope with systemd, or even like it, it's spurred an awful lot of people to step out of the "comfort zone" of Linux, and take a proper look at the alternatives. For some of us, it's been an eye-opener to see just how capable those alternatives are, and we've not looked back.

Re:One can hope

[rl117]

This behaviour is where I really dislike the sytemd way. The "it will be done this way, and only this way" attitude. It's my system, why should I not be the one who gets to decide policies such as this? In the initscripts world, this would have been effected through a little configuration file in /etc/default, which would customise the behaviour of the script (or you could edit the script as well if you wanted something truly custom). While systemd does allow some modicum of customisation in the unit files, there's a heck of a lot of policy and behaviour directly encoded in the implementation, which an admin isn't going to be able to touch without rebuilding the thing. While old and crusty, sysv-rc and initscripts left every part out in the open and hence amenable for changing and tweaking. So the "don't boot if a single filesystem in fstab fails to mount" policy would have been a tweak to the mountall script (or better, one of the mount helper shell functions).

Re:One can hope

[rl117]

There's also another factor to the migration which is familiarity.

Moving from a pre-systemd to a systemd Linux system fundamentally changes many aspects of system administration and maintenance, not just because of the init system replacement, but also from the replacement of all the other tools which systemd absorbed or replaced, or made mandatory. While FreeBSD has its minor differences, a contemporary BSD system is significantly more similar to a pre-systemd Linux system than a systemd Linux system. I personally feel more at home there (it's very similar to a traditional Debian system in many respects), and that my 2+ decades of Unix expertise is as relevant there as it ever has been.

I'm not a Luddite, but change for the sake of change isn't automatically a good thing, and while systemd has some good ideas, the design and implementation of the thing leave a lot to be desired. There doesn't seem to have been as much consideration towards backward compatibility of interfaces and configuration than could have been achieved. Linux was a mature platform, and you don't go around making gratuitous incompatible changes to such systems. At least, not without major fallout, which we continue to see.

Re:One can hope

[drinkypoo]

My understanding (which may be wrong) is that the impetus behind SystemD from the server side might be containers. Currently, these can't be managed centrally (AFAIK),

What supposedly prevents this? There are many packages for maintaining containers.

Re:One can hope

[fisted]

This needs to be +6 Informative

Re:One can hope

[thegarbz]

Systemd has turned out to be one of the best advertising campaigns for the *BSDs.

And yet it's market share is quite stable measured at 0.00% and has for the past 3 years for internet servers.
As much as I see this message come up over and over again, the number of people who legitimately shifted to BSD can be counted using your appendages. In the real world BSD's market share increased by only a few people who got upset because they refused to read a manual and decided that changing the OS was the only way forward.

Hurrah.

Re:One can hope

[thegarbz]

systemd is bad for servers. It adds nothing, just makes everything brittle and clunky.

That's funny given that it was primarily designed with servers in mind. Oh it boots quickly and that makes you think it's "desktopification". How silly.

Re:One can hope

[segedunum]

Systemd has helped raise awareness of the *BSDs.

Many former Linux desktop users who were driven away by systemd have ended up using FreeBSD. Many who ran Linux servers have started using OpenBSD instead. Those who ran Linux on older or less-powerful hardware have discovered the joys of NetBSD.

The number of sys admins specifically using older distributions or looking at BSD variants where they can is astonishing. There are a ton of bugs to troubleshoot in systemd that can only be solved seemingly by rebooting, and that's not any guarantee. Admins simply don't have the time to debug systemd alongside all the other problems they have.

Re:One can hope

[segedunum]

... was sysvinit really that better?

It worked.

Re:One can hope

[Anonymous Coward]

We switched many of our servers over to OpenBSD, but most people wouldn't be able to tell. We lie as to what the server is running. When trying to secure something, why tell everybody exactly what you are running? That just gives them the ability to target you better.

Re:One can hope

[thegarbz]

With sysvinit, I can easily plug modules at will.

I'm going to assume you didn't RTFM if you're having problems with modules and when they get plugged.

I know it sounds like a really radical idea, but howsabout just specifying the right order?

The right order is stable during one scenario only, a controlled boot. It was a good idea in the 70s, but it's a truly horrible way to run a system of interdependent daemons, especially when boot time is such a rare state to be in for a server.

I was testing a system with BTRFS doing mirroring. As part of the test, I dropped one of the disks to simulate a failure.

So you were using an experimental filesystem and complaining that your system didn't boot in degraded mode? It's quite telling that when you search online for the issue it is noted that this ONLY happens with BTRFS and not ZFS or mdadm. BTRFS's design is to not mount in degraded mode by default, and the fact that when you force the mount it doesn't act like every other file system, or indeed itself in a healthy state (which leads to udev not getting the device UUID) is a BTRFS bug / "feature". Maybe don't use an experimental filesystem if you're worried about your system.

Literally anything systemd can do could already be done using simple helpers called by sysV. You even provided an example yourself.

So literally anything systemd can do could already be done using sysV-init, a whole host of other programs, a shitload of scripts re-written and customised for each and every daemon .... except for the myriad of things you can't do with sysV-init. The fact that you think it can just shows how little you know of the topic. My guess is you don't even realise that systemd isn't the first attempt to work around the many shortcomings of sysv-init and the things it *can't* do, it's not the 2nd, 3rd, 4th or 5th either. It's somewhere in the double digits, and based around a combination of the way 2 different UNIX systems manage processes.

Those last two words are key, since it's something that sysV-init can't do.

Re:One can hope

[K. S. Kyosuke]

BSD: Because SystemD? ;)

Re:One can hope

[Anonymous Coward]

systemd is bad for servers. It adds nothing, just makes everything brittle and clunky.

That's funny given that it was primarily designed with servers in mind. Oh it boots quickly and that makes you think it's "desktopification". How silly.

Oh. The boots quickly argument.
1) I never experienced boot duration problems with Debians before the switch. Starting VMs felt like instant on.
2) Starting physical servers isn't accelerated either. Most of the time the system spends in initialization before the system kicks in.
3) How often do you need to reboot the server anyways? Even if you reboot a system with each available kernel patch it won't make a dent noticable in availability charts.

Re:One can hope

[Anonymous Coward]

Recent systemd anecdote.

Helped out a friend by setting up a backup server for them.
Bought 8TB HDD.
Installed Linux Mint 18.1 on old spare PC. Worked great.
Installed CrashPlan, configured as backup server. Worked great.
Installed TeamViewer (I know it's shit, don't fight me on this one) so I can monitor the server remotely. Won't start. Tried a few things. Won't start. Won't fucking start the program. OK, check the logs. Systemd is reporting "file not found" in the logs. The error reporting is entirely fucking useless and doesn't make any sense.

Google this problem and am fortunate enough that others have had it too. Turns out CrashPlan uses up all the file system watching resources, which can be increased in sysctl but there was nothing in those error messages that would have ever pointed me in that direction.

Fuck systemd.

Re:One can hope

[Anonymous Coward]

Ofcourse ot does. Most of us happily moved to systemd. Good luck convincing us it's faster to learn FreeBSD then Systemd. And Btw, i used to use FreeBDS (versions 4 and 5) and liked them quite a bit. Moved away to linux mostly to reduce maintainance.

If others went to FreeBSD, good for them. Good for BSD, they need more users. But nobody cares about your philosophical view. You think you are forced to systemd or entitled to systemd free distro, well, go fund it. Majority has no problem, it's only the vocal minority that distorts the picture.

Re:One can hope

[Anonymous Coward]

Before SystemD I had no need to understand the init process, just a bit of bash and a the old change to rc.d. init just worked. Now I'm aware of a number of inits capable of providing the functionality of a modern init system without the fundamental design flaws of SystemD or encroaching into all aspects of userspace.

Before SystemD I trust most of the decisions my distribution with regard to packaging or trivially avoid or reverse those decisions. Now I have Jenkins CI, jenkins-debian-glue and a my own reprepro because the deps imposed by welding SystemD into every package broke how apt is meant to work and damage has to be routed around.

I used to waste time helping on my distros forum on large numbers of topics now all the talk is bending SystemD into something useful and any criticism will get you banned.

All In all, leaving debian when it became a redhat derivative has made me knowlegable about my system and the process of removing SystemD from numerous packages has informed me of more of the internals of those packages and their complete lack of needing SystemD to be fully functional. The SystemD adoption process has identified whole organizations and individuals that can happily be avoided for a more placid life.

For all these things I thank SystemD. Without you I'm in a better place and moving in a better direction. Next step - identify the anti-patterns in the freedesktop wiki and purge my system of those.

Re:One can hope

[sjames]

I'm going to assume you didn't RTFM if you're having problems with modules and when they get plugged.

Not KERNEL modules, init system modules.

The right order is stable during one scenario only, a controlled boot.

You prefer an out of control boot? Not sure what you mean there.

BTRFS hasn't been listed as experimental for some time now. It is considered usable in production now. The problem wasn't BTRFS, the problem was systemd trying to be clever when it really isn't. It would refuse to even attempt to mount btrfs until all disks showed present. It offered no timeout. I did have the degraded option set, such that when systemd inevitably dropped me to a shell, I could just type mount /home and POOF, there it was.

systemd never did solve the problem for MD RAID devices, it's just that the initrd now assembles the RAID before systemd gets a chance to screw it up.

The Unix philosophy has always been small tools that do one job well combined to do nearly anything. That's how it's SUPPOSED to be.

Systemd COULD have been designed to play well with others. It's whole process management thing could have been called by /sbin/init to take care of whatever was configured under it and leave everything else to the rc scripts (or whatever other modules might be called by init). Instead, it's a hairball. It reminds me of Robin Williams joke about God getting stoned and creating the Platypus just to fuck with us.

Since I actually wrote an init system for bproc nodes, I probably know a hell of a lot more about it than you do.

You know what it usually means when dozens of "new and improved" replacements fail to replace the original? It means the original is actually a lot better than you think it is.

Re:One can hope

[Anonymous Coward]

You could look at LXD and I'm pretty sure docker has it's own. Any time I hear "SystemD is the only way" I know there are numerous better options available, just step outside the redhat derivative world.

Re:One can hope

[Anonymous Coward]

systemd is bad for servers. It adds nothing, just makes everything brittle and clunky.

That's funny given that it was primarily designed with servers in mind. Oh it boots quickly and that makes you think it's "desktopification". How silly.

If the boot time is critical for your servers and shaving just few seconds, then you are doing it wrong. You should study how set up active/passive cluster setups or if that isn't enough how you set up active/active cluster with load balancing, context switching or with reverse proxies. That's how you keep providing services while being able simultaneously to do maintenance and even migration to newer system without outages. And when you get good at it reaching five nines isn't even too hard.

Also, regarding systemd, which I've now have experience with servers about two years period, the only positive side of it is being able to manage containers better than systemv. Otherwise it's just meh, overkill and caused some serious surprises by when some minor service was not able to start and it failed to continue bringing up whole system. It's mostly useful in desktop and laptop systems, in servers not that much.

Re:One can hope

[phantomfive]

That's funny given that it was primarily designed with servers in mind.

Not sure that's true. It was inspired by launchd from Apple (specifically this video). Personally I think launchd is cleaner, but that's partly because Apple has full control of the ecosystem.

Re:One can hope

[phantomfive]

complete operating systems from multiple vendors such as HPUX, Solaris, IRIX, etc

Using HPUX and IRIX as an example of the unix way only shows you don't understand what the unix way is. Suggested reading here.
Hint: it's significantly more sophisticated than "each tool does one small thing." For people who think that's the Unix way, they need to read the afore linked to page.

Re:One can hope

[Anonymous Coward]

Systemd is to blame for you installing crappy proprietary programs that causes problems like CrashPlan?

"Oh, I typed 'rm -rf /*', better blame systemd!"

Re:One can hope

[Anonymous Coward]

Your problem is pebkac...

Re:One can hope

[lucm]

Majority has no problem, it's only the vocal minority that distorts the picture.

And you know that how?

Re:One can hope

[lucm]

My understanding (which may be wrong) is that the impetus behind SystemD from the server side might be containers. Currently, these can't be managed centrally (AFAIK),

What supposedly prevents this? There are many packages for maintaining containers.

True. Even kubernetes can be installed with yum and can run under the dictatorship of systemd.

Re:One can hope

[lucm]

systemd is bad for servers. It adds nothing, just makes everything brittle and clunky.

That's funny given that it was primarily designed with servers in mind.

Of course! That must be why the documentation is hosted on "freedesktop.org", which is self-described as "an open source / open discussion software projects working on interoperability and shared technology for X Window System desktops".

Re: One can hope

[Anonymous Coward]

No you are wrong. Writing service definitions for systemd is way better than stupid old bash scripts. That alone is worth the price of admission. I'm sorry you don't actually administer any servers and therefore can't appreciate it.

Re:One can hope

[Anonymous Coward]

> And it would have been perfectly possible to fix those issues, with vastly less effort and disruption than throwing it all away and breaking much backward compatibility in the name of inter-distribution uniformity (and consequent stagnation).

Sure, but "Coordinated with twenty other projects to significantly improve the state of Linux service management" looks far less impressive on one's resume and in the annual bonus meeting than "Wrote groundbreaking, revolutionary init and service/network/cgroup/etc management from scratch and foisted it on another major Linux distribution.". Management types _love_ it when you validate their NIH Syndrome.

Re: One can hope

[Anonymous Coward]

bless, if your bash scripts are stupid and old you must be using redhat. If my distributions initscripts were as poor as redhats were I'd have looked for an alternative, just not one coming from redhat thats all.

Re: One can hope

[lucm]

I'm sorry you don't actually administer any servers and therefore can't appreciate it.

Good point. Nowadays we have $15/hr visa workers for that - they get along very well with their counterparts when they call Red Hat helpdesk - maybe I could put you in touch in case you're looking for a job. I hear Infosys is on a hiring spree this winter.

Re:One can hope

[Anonymous Coward]

Evidence? Sounds more like desktop marketshare than servers

Re: One can hope

[unixisc]

In which case, come to *BSD

Re:One can hope

[Kjella]

I like Red Hat and I appreciate all they've done for open-source in the enterprise, but the desktopification of core Linux aspects is a bad thing.

Uh you realize Red Hat only has one little side project for workstations and it's essentially the server version with a GUI and a cheaper license? Fedora is just their testbed, they don't care about the desktop. For me it's pretty clear that the core feature of systemd is resource management for containers and other forms of light virtualization. If you run a dedicated server, you don't need it. If you use a hypervisor and full VMs you don't need it. If you want to "app-ify" your servers with Docker then systemd is the management tool around it. It's a huge selling point to cloud providers which is core business for Red Hat. They're not doing it to compete with Linux Mint...

Re:One can hope

[Anonymous Coward]

Oh. The boots quickly argument.

Yes.

1) I never experienced boot duration problems with Debians before the switch. Starting VMs felt like instant on.

Good for you.

2) Starting physical servers isn't accelerated either. Most of the time the system spends in initialization before the system kicks in.

Often true.

3) How often do you need to reboot the server anyways? Even if you reboot a system with each available kernel patch it won't make a dent noticable in availability charts.

The more virtual servers you have, the more it adds up. For highly dynamic environments, fast shutdowns and bootups are important.

Re:One can hope

[jandersen]

"The UNIX way" was to have multiple, not quite compatible, complete operating systems from multiple vendors such as HPUX, Solaris, IRIX, etc. Porting your software between those was a considerable effort, and in fact a whole standardisation body (posix) has sprung up around efforts to make those systems at least nominally compatible. And in later years, the Linux way was quite similar, with LSB attempting to keep distributions at least nominally compatible with each other, but the effort of porting an application from one distribution to another still going by the name of "porting".

You know, I have worked for something like 30 years as a UNIX developer, later sysadmin - HP-UX, AIX, SunOS, DECOS, Linux (most HW architectures: POWER, zArch, Intel/AMD, SPARC, etc), even USS (UNIX System Services under MVS) - and the one thing that stands out to me is how easy it is, in practise to move from one to the other. As developer, I was part of a team that wrote C code which was compiled to all our UNIX systems, and while there were one or two quirks to work around (most notably HP-UX's tendency to issue warnings about FUTURE errors, figure that), it was remarkably easy. Sysadmin is even easier - there is a large overlap, and the minor differences there are, are easily mastered - unlike what you find on Windows between versions.

Re:One can hope

[thegarbz]

Yeah it's almost like a fundamental part of the system can have two purposes. Amazing isn't it.

Instead try and look up what it does and why it does it rather than championing the name of a domain which is hosting their documentation.

Re:One can hope

[thegarbz]

You prefer an out of control boot? Not sure what you mean there.

I can tell. There's one scenario where a specific order applies, boot time. It's also a time you don't normally find yourself. So having an entire process manager with hard coded order is asinine and is the number 1 "feature" that every single other init system has removed.

BTRFS hasn't been listed as experimental for some time now. It is considered usable in production

By who? Certainly not the project team who say that only the physical disk format is stable, and the rest of the project is still under heavy development including the caveat that bugs may creep in.

The problem wasn't BTRFS, the problem was systemd trying to be clever when it really isn't.

Nope the problem was udev (nothing to do with systemd itself) and the fact that even when the options are passed in fstab to mount degraded that it doesn't report back to udev that a valid UUID is present. Systemd then tries to boot a system with a filesystem that has a valid UUID and does what every good system should do when fundamental hardware is missing in the boot process: fails to console.

systemd never did solve the problem for MD RAID devices, it's just that the initrd now assembles the RAID before systemd gets a chance to screw it up.

Initrd? You mean the thing that is supposed to assemble rootfs devices before a system tries to boot from them? Colour me surprised. Amazed. Gobsmacked! What a revelation!

The Unix philosophy

Don't care.

Since I actually wrote an init system for bproc nodes, I probably know a hell of a lot more about it than you do.

Now there's an appeal to authority no one gives a shit about. Sorry but you're still just a name on the internet.

You know what it usually means when dozens of "new and improved" replacements fail to replace the original? It means the original is actually a lot better than you think it is.

Actually it means that no one was happy with the original. The only problem was that up until this point people couldn't agree on what the replacement was supposed to look like. Hence we ended up with 5 different distros with 5 different init systems all under parallel development all of them got traction in their own way. Fortunately one project came along that actually offered the benefits of most of them and appeased them enough to all focus the efforts on a single replacement.

Re:One can hope

[Anonymous Coward]

I like systemd, but I went through the SMF transition with Solaris and the complaints were basically the same.

And look how well Sun is doing...

Re:One can hope

[thegarbz]

So the "don't boot if a single filesystem in fstab fails to mount" policy would have been a tweak to the mountall script (or better, one of the mount helper shell functions).

Or you define your filesystems correctly as something that is important to boot the system or something that is not. If it needs to be automounted then why would any sane boot process not fail? The previous behaviour is what generated a shitton of filesystem related problems from programs that started blindly reading and writing to directories that didn't exist on file systems that weren't mounted.

Anyway this is irrelevant since this is a bug in btrfs, and no other redundant FS fails this way with systemd. I do understand though, some people prefer not only having enough rope to hang themself with, but for the noose to be pre-tied. Hence why so many guides told people to setup filesystems withautomount despite what a stupid idea that was, and you get bug reports from people complaining that their system fails to boot when a USB stick isn't present.

RTFM

Re:One can hope

[Anonymous Coward]

Hmm, you know people only run servers on *BSD under a hypervisor, don't you? We can't trust the bare metal to them, they just don't get the required churn to support the firmware madness on the newer servers.

So, it is really vmware or Linux + kvm running the bare-metal and *often* (not always) doing all the I/O and CPU scheduling, and the BSDs are just being used as glorified second-tier O.S. This is Not Good.

Obviously this is not valid for bare metal made specifically with the *BSDs in mind, but we only find those for small-scale systems, and network equipment (e.g. Server-U).

Re:One can hope

[kobaz]

Yeah this is nothing to do with systemD. Try installing crashplan on *any* distro and feel free to notice that it's using the max open file handles.

I believe crashplan uses inotify()... and if you have any decent count of files to be backed up, you'll hit your sysctl limit of open file handles. What we need is a single handle event notification in the linux (like *bsd kqueue) kernel and it would make these apps a lot simpler and less resource intensive.

Re:One can hope

[sjames]

I can tell. There's one scenario where a specific order applies, boot time.

If you can tell, one might expect ypu to make an effort to communicate more clearly. If you find you cannot, then you should clerify your own thinking first.

Boot time is also the only scenario where initializing the system is relevant. All those other systems failed to catch on, probably because non-deterministic system initialization is problematic.

By who?

By the kernel configuration, SuSE, Facebook, Tripadvisor, and a number of other operations using it in production.

Either way, systemd needs to be flexible enough to deal with this sort of thing. It isn't.

Nope the problem was udev ...

SysVinit with udev doesn't have this problem. Beyond that, the absorberthon that is systemd claims udev for itself, so it's their problem now. This was udev's behavior before there was systemd and it is still udev's behavior. It's not like it popped up as a surprise. Pure and simple, systemd neither took that into account nor changed udev to no longer behave that way. Thus, the blame falls squarely on systemd.

Initrd? You mean the thing that is supposed to assemble rootfs devices...

/home is not root. Actually, at one time systemd was supposed to aldo take care of things in the intird/initramfs. It doesn't now because it isn't capable of it due to it's inability to deal with RAID and other systems where some failures are OKish. This is just an example of something very fundamental they didn't think of, didn't build in enough flexibility to make it fixable in configuration, and didn't make it open and modular enough to allow something else to take care of this task for it.

Don't care.

So you don't care about the philosophy that made Linux superior to Windows? You are happy to degrade the usefulness of Linux so you can switch to the losing strategy born from insufficient understanding??

Now there's an appeal to authority...

Referring to one's own relevant experience is in no way an appeal to authority. Particularly after a claim that one lacks relevant knowledge or experience. In other words, you went there and got shot down. In response, for some reason you smashed an egg on your face.

Actually it means that no one was happy with the original.

Sure, it is the most disliked init system ever, other than all of the others.

Re:One can hope

[Anonymous Coward]

I wanted an easy FreeBSD installer and found TrueOS. It ran fine on a 2011 laptop I had lying around.

https://www.trueos.org

Thanks, systemd!

Re: One can hope

[Anonymous Coward]

Bugs in systemd? Send patches to their repos or talk with their developers about your problems. If you don't like this "classic" approach, switch to something else, eg. openrc. Or change OS, it's a free World.

Re: One can hope

[lucm]

No I mean how can someone talk on behalf of the "silent" majority

Re:One can hope

[strikethree]

"The UNIX way" was to have multiple, not quite compatible, complete operating systems from multiple vendors such as HPUX, Solaris, IRIX, etc. Porting your software between those was a considerable effort, and in fact a whole standardisation body (posix) has sprung up around efforts to make those systems at least nominally compatible. And in later years, the Linux way was quite similar, with LSB attempting to keep distributions at least nominally compatible with each other, but the effort of porting an application from one distribution to another still going by the name of "porting".

I have no idea in which dimension your UNIX way happened, but it wasn't this one.

Perfect troll or perfect idiot? No idea. Don't care.

Drip

[lucm]

worked with my tuner devices (cx88 PCI cards and an xc5000 USB device) together with MythTV

You're like a wet dream for QA people

only 1 reason to run debian

[Anonymous Coward]

to run chrome. ? Am I wrong?

(and systemd sucks and is not safe)

Debian with no pain packages?? Hmm..

[Neuronwelder]

I started with Debian. It's a very nice system but as a newbie, I wasn't smart enough to work with it. So I went Ubuntu.. I know Dos games are old. But when I tried to update my Ubuntu operating system. I either had to start from scratch updating package after package and spend days to get them to possibly work again. Or forgo the update and use my backup. I used backup.. My Ubuntu 15.10 has reached its end of life. So I'm going to get a new hard drive and install Ubuntu 16 for Web searches and new software. I'll keep my old hard drive for the games. ..Also I just got a copy of my hospital MRI to work with Ubuntu (With the help of Wine software of course.) the same day.

Awesome

[Anonymous Coward]

Awesome . When will Ubuntu pick up this release?

Re:Awesome

[Anonymous Coward]

No. This is just a point-release. It's basically just a respin of the isos with the latest updates pre-applied.

More horse shit

[Anonymous Coward]

It has not been released. We are just kidding! Thank you.

-Management

Debian Logo

[Anonymous Coward]

Have you noticed the similarity between the Debian logo and the one for the PBS Create television channel? Perhaps there will be a series called "This Old Operating System."

Re:One can rope a weiner-dude dope

[Anonymous Coward]

Step into a desktop shredder, Jackson ... how do those bloody parts feel ... heh? Kinda like a Linux shell ... heh Jackson? Hurt lots? GOOD !!! That's what desktop casual usrs think about byteboy bitching ... make-it-easy to use: shreddit out not wheat!

My first linux experience was a systemd hang

[Anonymous Coward]

I installed mint on an old x86-32 inspiron box to play with some web development.

After the install finished, the system decided to reboot. No biggie, except the last line the screen mentioned something about a systemd hang during shutdown.

I hit the power switch and everything came back up.

Is this what the linux world means by great desktop experience?

FUCK SYSTEMD

[Anonymous Coward]

Fuck SystemD.

--MikeeUSA--

Re: FUCK SYSTEMD

[Anonymous Coward]

Gladly,

SYSTEMD is just a bigger more veiny version of =====D

Re: FUCK SYSTEMD

[Anonymous Coward]

Gladly,

SYSTEMD is just a bigger more veiny version of =====D

It's also a plane, railway system and a cat.

Re: FUCK SYSTEMD

[Anonymous Coward]

SystemD is a huge backdoor but doubles as an init system.

Fixed the hdparm bug?

[Anonymous Coward]

I wonder if they've fixed the laptop HDD spindown bug? I seem to remember the hdparm configs were ignored and the HDD was spun down every 6 seconds. This might not have been a pure Debian fault though.

Thank you Debian maintainers

[cwveg]

Have just reinstalled Debian after 17 years away from Linux on my home machines. I have to say I'm impressed. It worked on a 2007 MacBook without any messing around. Graphics, sound, fan speed, touchpad, brightness and volume buttons, sleep etc. all worked out of the box. The default desktop looks good. The fact that it's a root distribution and not derived from something else makes it feel solid. I'm liking it. I'm liking it a lot :-)

Re:Thank you Debian maintainers

[Anonymous Coward]

Wait until after doing a routine update, or until after your first systemd-related boot disaster, before praising it. In my experience, those two things happen one after another: you do a typical "apt-get dist-upgrade", and then systemd starts acting up in some peculiar and hard-to-diagnose way that prevents the system from properly booting.

Let's also hope that you have another Internet-enabled computer or smartphone available to search mailing lists and bug reports with. If systemd starts acting up, and your computer won't boot, you'll pretty much need to resort to searching for help online right away, due to systemd's complexity. It's not like sysvinit, where even inexperienced users could look at the boot log, read through a few short shell scripts, and typically figure out what's wrong. With systemd you'd better hope that somebody else ran into the problem earlier, and that they went begging for help online.

It isn't enough for an OS to just install properly. It needs to keep working flawlessly for years on end. Debian used to be like that, before switching to systemd. But these days? I've had nothing but problems with it, and pretty much every single problem had to do with systemd.

Re:Thank you Debian maintainers

[Anonymous Coward]

Do the fonts still look like shit? That's the main thing derivatives give me over Debian. Ubuntu implemented a tons of fixes to the font rendering stuff. The "stock" Debian stuff (and other unmodified distros like Arch) the fonts look absolutely terrible. Like "damage your eyes" terrible.

Other than that the main reason I continue to use Ubuntu is just because it has later versions of the packages whereas Debian tends to be woefully out of date. Which I guess is OK for stable servers but no good on the desktop. Sometimes it's not good for servers either because quite often I find myself having to manually install newer software that then won't get upgraded/patched through the standard package system.

Re:Thank you Debian maintainers

[caseih]

Been using systemd for nearly 5 years now and have never had a boot problem from it yet. I hear scattered reports of the occasional problem but there's nothing like the problems you claim to experience on a regular basis.

Short shell scripts? Have you even looked at an an init script the last 10 years? Init scripts are anything but short and simple. There are good reasons all the commercial Unixes moved away from SysV init long before Linux did. Systemd logging is actually quite good and verbose. I still run a syslogger as well. I'm just happy not to have to write error-prone init scripts anymore.

It sucks that you have so many problems with your systems. I'm not convinced systemd is causing them, but I'm sure there are solutions and wish I knew what they were. Your experience is not the usual experience across the board, though, no matter what the slashdot anti-systemd echo chamber claims.

Re:Thank you Debian maintainers

[Anonymous Coward]

Been using systemd for nearly 5 years now and have never had a boot problem from it yet.

Probably because you aren't actually 'doing' anything that presses systemd beyond the most simple use cases.

I bet you don't, for example, use NFS mounts, or NAS, or run applications that fail to release mounts when systemD tells them to shutdown. I bet you've never had to sit on a console watching a server hang on shutdown because systemD has walked its self into an impossible loop waiting for an application to quit, which is waiting for a drive write to finish, which is waiting on a mount that's been disconnected because systemD thought "all systems are a go"

If you haven't had systemD problems it's because you haven't done anything complicated enough to expose them. You might as well just say "the computer worked great in the store demo, I don't see what all the buyers are bitching about"

Re:Thank you Debian maintainers

[rl117]

NFS is still broken for me (Ubuntu 16.10). Fails to mount on startup almost every time; sometimes it succeeds but the chance is about 1 in 10. Some race I guess, but who knows? It's too much of a black box to easily debug. With sysv-rc, I could step through every script by hand, and pinpoint a failure to the line. Contrast that with the "old" FreeBSD and Debian systems using BSD init or sysvinit. They manage to mount the NFS filesystems reliably, every damned time. Which is of course what I'm looking for. Is reliable startup too much to ask for?

Re:Thank you Debian maintainers

[Anonymous Coward]

There are good reasons all the commercial Unixes moved away from SysV init long before Linux did.

By "commercial Unixes", I assume you mean companies like Sun (rest in piece) and SGI (rest in piece)?

The best fix for systemd..

[thejynxed]

...would be to get rid of systemd.

some fixes for systemd

[Anonymous Coward]

So it was removed?

"including some fixes for systemd"

[Anonymous Coward]

*excited face*

DID THEY REMOVE IT??? IS THE SALVATION OF LINUX AT HAND???

"Rework logic to blah blah blah blah blah you are still Redhat's bitch if you use Linux and if you question systemd in any way that makes you automatically wrong and incompetent"

Oh, I guess I can cancel my download for the iso then. Back to FreeBSD and Windows 7 I go!

Why do we still have releases?

[Anonymous Coward]

Oh clap hands, pat backs or complain you font like something new or the direction.

Arch and other distros have rolling releases, Wikipedia effectivly has a rolling release if you stay current.

Seems like this should be less of a deal

How To disable SystemD on Debian 8

[psergiu]

http://without-systemd.org/wik...
http://jrigg.co.uk/linuxaudio/...
I did it, and it works perfectly if you don't use any Gnome & co. stuff.

Re:How To disable SystemD on Debian 8

[Anonymous Coward]

This. I can confirm that. Running a mixture of stable and unstable (!), a so-called FrankenDebian. Plus bits and pieces of self-compiled stuff. No systemd (personally I dislike it), heck: not even DBUS. No problems. Works a charm.

If you like systemd: use it. If you don't: don't use it. But whining, throwing hissy fits or mudslinging doesn't help us! It only helps those who want to keep free software from disrupting their businesses (and *I* *fucking* *want* Free software from disrupting some kinds of businesses, dammit).

Just respect each other. I must admit I don't particularly like Lennart's attitude. *But he is writing free software*. Therefore: thank you, Lennart.

And other OpenRC-based distros

[fluffynuts]

In particular, Gentoo. I did (very seriously) consider a BSD -- but would have always preferred a linux distro because I can get Steam working and I saw that the BSD kernel was dropping Linux ELF compat for security reasons (which may make sense -- I'm not here to judge).

I used Debian (or a derivative -- Mint, Ubuntu, and, very long ago, Corel Linux, but we don't have to dwell on that...) for around 16 years. When my Ubuntu box started getting insanely slow, I thought it was perhaps time to just go back to vanilla Debian. Turns out the problems persisted there too. Long boot times (minutes when win10 would boot in about 30 seconds to a usable desktop). Longer shutdown / reboot times (even more minutes when, again, win10 on the same machine would shut down in about 15s). 10-30 seconds to open a freakin' Konsole session -- and it wasn't Konsole: the window would show, black, waiting for a prompt.

I honestly couldn't stand that my win10 install was faster in every respect than my Linux install on the same hardware. It's just not right.

I put some research into which distros supported OpenRC. Arch does -- but it's not the default. Gentoo does -- and it's the default (and you don't need it if you don't want a masochist's desktop).
Yes, there's no pretty installer. There's a handbook and it's very informative. No, Gentoo is not about to woo casual desktop users and sub-par "administrators" who couldn't install grub without a lot of babying, but Gentoo gave me back my i7 3770 with 16 Gb RAM -- once again, I have a machine which is a total pleasure to use, even with a heavy desktop like KDE (plasma5).

I put up with the audio latency of PulseAudio in Debian because it meant I didn't have to learn the voodoo of .asoundrc files for dmix (turns out: you don't need 'em! dmix works out the box on now on cards with no hardware mixer, no configuration required!). Yes, PA has other features (unifying soundcards so your app can output to all of them -- stopped working for me, never managed to get it working again; network transparency (how many people actually need to project sound across a network?!) and per-application volume control (which people claim to love, but seriously, most of us just change the master volume if an app is too loud / soft, mainly because that's immediately available and the per-app volume control is a few clicks away).

PA also had annoyances (apart from the latency) like not remembering the default device and being plain flaky (so much so that I seriously wrote a cron'd script to bring it back up again because it crashed so often).

Then I heard that the same banana was taking over the init system in the most non-UNIX way possible and I just held on for the ride. I didn't want to give up my beloved Debian.

About a month in to using Gentoo and I wish I'd done this at least a year and a half ago, when I lost my patience with my slow Ubuntu install and switched back to a (not all that much faster) vanilla Debian install.

Gentoo is (probably) great for the same reasons *BSDs are great -- heck, portage only exists because of the inspiration of ports. Huzzah! It's like I can have the benefits of BSD and Linux all at once!

Compiling your own packages can make you feel like a hero -- but it's not the reason why my system flies now (heck, even my browser (palemoon) is using about 1/10 the memory it was before (300-500mb vs 3-5 gig)). One reason is that you don't have to accept "features" (PA, systemd) that you don't want support for in your apps. The other reason is simply that that Poettering crapware isn't on my system any more.

Of course

[lucm]

Yeah it's almost like a fundamental part of the system can have two purposes.

Ah, so either when you said "it was primarily designed with servers in mind" you were making shit up, or you are when you say that it fundamentally has two purposes. No need to explain further, you're busted.

Where is the problem?

[Anonymous Coward]

If you don't like systemd, change. I'm very happy with it.

Re: Where is the problem?

[Anonymous Coward]

Months ago I found a small "bug" in systemd. I sent patches to their repo, It was easy with github.

Re: Where is the problem?

[Anonymous Coward]

I work on freebsd systems, and I like this OS for its solid old feel. I work on Linux systems, because its distributions can look forward and take/test new solutions. Walk straight ahead, and take the best with you.