Debian Talks About Systemd Once Again

An anonymous reader writes: A couple of months ago the technical committee for Debian decided in favor of systemd. This is now a subject for discussion once again, and Ian Jackson says he wants a general resolution, so every developer within the Debian project can decide. After a short time, the required amount of supporters was reached, and the discussion can start once again.

Comments

wondered why it took so long.

[turkeydance]

and i still don't know.

Re:wondered why it took so long.

[TangoMargarine]

If you're talking about Deb & Ian, they apparently got a divorce in 2008 and Ian stepped down from project leader in 1996 anyway.

Re:wondered why it took so long.

[Richy_T]

Crap. I thought the "Ex" was for "Extreme"

Some Sense Restored?

[Anonymous Coward]

Hopefully they'll come to their senses and reject the disease that Pottering has cursed the Linux ecosystem with.

Re:Some Sense Restored?

[TWX]

More to the point, as with the System V vs BSD init debate, this'll further help to separate the UNIX-method distributions from the desktop, automagic ones.

I learned on Slack and at the time just about all of the books that I could find were UNIX admin books, not Linux admin books. With Slackware in the 2.0 kernel days this wasn't a problem; the kernel-specific stuff was really the only differentiator from regular UNIX-style admin.

I expect Desktop-oriented distributions to increasingly obfuscate things from the user, in the manner that MacOSX does. And for most users that'll work fine. For those that want to tinker under the hood, hopefully distributions like Debian will continue to allow for a more UNIX-like method of doing things.

Re:Some Sense Restored?

[FudRucker]

i have to agree, i was running Jessie for a while and systemD is just awful, i rather have the old init system that Debian has used for years, it works and i figure if it isn't broken don't fix it, i have since removed Jessie and switched to Slackware and have made up my mind to stick with Slack and keep my eye out for using only non systemD distros

Re:Some Sense Restored?

[CRCulver]

Debian is a lost cause. From Gnome 3 to Systemd they've lost their independence.

Debian's offering of Gnome 3 and Systemd are not comparable. Gnome 3 is only the default desktop for people who just want to click through the installer. But you can completely avoid Gnome 3, and indeed many people do because they do e.g. headless server installations or choose another GUI. Systemd, however, is spreading through so much of the system that it may not be possible to avoiding installing it. Even if one hangs on to sysvinit as one's init system, programs like Gimp on Debian now end up pulling in systemd libs.

Re:Some Sense Restored?

[mlts]

I personally would like to see it (and its evil compatriot, firewalld) as options.

In RHEL 7 and downstreams, you can choose between LVM2, standard partitioning, or btrfs as ways to carve up your disks. It would be nice to have systemd as an option, so for laptops where parallel starting of daemons makes a nice speed increase, it is useful. For a server where one doesn't want many changes to the underlying OS unless it is something to be tested, it can be an option. If one is using containers, maybe systemd might be useful to have.

There are changes to Linux like SELinux and AppArmor which are must haves. These add significantly to the security of the OS. systemd does add security... but not really that much. One can specify that a program run with ulimits and possibly in a container, but a wrapper can do the same thing, and one thing that I get concerned about is one program having so many moving parts that touch everything on the system, even perhaps the TTY functions.

Re:Some Sense Restored?

[Anonymous Coward]

If the moving "toward the 21st century" means suffering an all-encompassing virus that diverges entirely from the established design philosophy of the context it resides in then get me a ghetto blaster, some jolt cola and my stone washed jeans because I'm living in the 80's forever.

Re:Some Sense Restored?

[Anonymous Coward]

Your snark only makes my erection harder.

Re:Some Sense Restored?

[Anonymous Coward]

"just awful"? Can you elaborate?

Re:Some Sense Restored?

[nicolastheadept]

I'm assuming that you're saying that the automagic ones are the ones adopting systemd. Like arch.

Re:Some Sense Restored?

[petermgreen]

Debian's offering of Gnome 3 and Systemd are not comparable. Gnome 3 is only the default desktop for people who just want to click through the installer.

It's also what everyone previously using gnome2 on squeeze would get on upgrade to wheezy or above.

A fork of gnome 2 did eventually make it back into debian but it wasn't in wheezy and you still have to manually remove all the gnome bits and replace them with their forks.

Even if one hangs on to sysvinit as one's init system, programs like Gimp on Debian now end up pulling in systemd libs.

Pulling in libs related to things you don't use isn't really anything new.

The bigger question IMO is to what extent will systems that don't use systemd as init be supported going forward? Will users of other init systems be treated as second-class citizens. When the technical comitee chose the default init system they refused to rule on this issue and it looks like the current GR is what this is about.

Re:Some Sense Restored?

[Anonymous Coward]

What does Gimp have to do with systemd? Would you explain the relationship further? i.e., which libs?

Re:Some Sense Restored?

[dos1]

This resolution, even if systemd remains default in Debian, is meant to prevent exactly that.

Re:Some Sense Restored?

[csnydermvpsoft]

The problem with supporting multiple init systems is that each package that provides a daemon needs to support all of them. A traditional init script is just a shell script, while upstart and systemd have their own formats. You could write software to convert an upstart or systemd script to a shell script, but there would likely be cases where it wouldn't be easy to translate automatically.

With filesystems, applications don't need to know anything about what's mounted how and where—you could mount /var on a btrfs partition on LVM2, /home over NFS, /tmp on an ext2 ramdisk, /usr on a read-only CD-ROM, /etc on a floppy... and everything would just work (albeit slowly because of some of my hypothetical choices).

Re:Some Sense Restored?

[Anonymous Coward]

text user interface is faster and would give debian an edge...

Re:Some Sense Restored?

[goulo]

That Gimp (and more and more other programs) require systemd (which is supposedly merely "an init system") is the really evil thing. Poettering & Red hat are explicitly trying to force all Linuxes to have systemd.

I don't trust Poettering & Co's track record, nor competence, nor intentions (e.g. seeing him use sleazy manipulative rhetoric in a conference video where he accused a systemd opponent of not caring about handicapped people), and I sure don't want their unnecessary huge mass of dubious code on my machine. (Though I'm sure the NSA will be happy for the increased opportunities of exploits in such a huge messy mass of code.) And even if this "init system" were somehow really necessary for Gnome, I don't use Gnome.

They have lied, e.g. claiming that systemd is just an init system, or that it is not a big monolithic chunk of code, yet it becomes more and more monolithic. E.g. I just watched a week or two ago as several libsystemd packages in debian became merged into a single package while one user was trying to create a stub for one of them to satisfy some needless systemd dependencies by some applications.

I am becoming increasingly convinced that Ignorant Guru is right, and Linux is being manipulated for corporate interests, not users' interests. http://igurublog.wordpress.com...

Re:Some Sense Restored?

[thrig]

Selinux a must have? Hardly. Look at the security bulletins. Note the stupidly large number of exploits. Tally up how many would be prevented by selinux and where selinux would even be relevant to an attacker (who are your attackers, by the way?). Why not instead dedicate that time to fixing and auditing the code (see e.g. OpenBSD), and then only if there is spare time after all that work, only then consider the dubious benefit of a RBAC system. Consider two companies, 3-tier, sell stuff on the web, blah blah database blah blah email blah. One spends time setting up selinux, the other audits their code. An attacker desires customer data, and breaks into the selinux company via a code flaw (permitted by selinux) and reads the customer data from the database (permitted by selinux) and mails it off somewhere (permitted by selinux). The company that instead audited their code does not have the embarrassing flaw, because they found and fixed it, and were not hacked. Or what if the attacker, again via some local flaw, simply turns off selinux, and then does what they need to do? Again, time would have been better spent auditing and fixing the code, and not pouring manhours into the RBAC system.

Now let's say there is selinux AND the attacker cannot simply bypass selinux AND there is some customer data that selinux would prevent access to—say by not allowing a shell to run. This could be implemented in other ways (isolation of that customer data, so that even if they get a shell on some front-end machine, the critical data is simply not available there) that benefit the setup regardless of whether selinux is around. Oh but defense in depth, come the cries? Well, if you think you need a Maginot line off in the Pacific, or have some Potemkin policy that requires it, have fun!

Re:Some Sense Restored?

[sjames]

The funny part is that systemd has nothing to do with making a good desktop system with things papered over. Once the whole cgroups kernel interface will be stabilized, I would expect any number of improvements on the SysV init to take place.

Start with the parallel init already available in Wheezy and add a simple daemon manager called in the init scripts to stick a system daemon in a cgroup and manage it and you have every advantage systemd offered and none of the drawbacks.

If desired, that manager could support the "I'm ready" callback through a passed FD (a pipe endpoint). For non-Linux systems, the wrapper can support the callback and skip cgroups.

My big concern over systemd hasn't been that SysV would go away, but that a mediocre at best replacement would wedge itself in through crazy dependencies and prevent the better solution from even starting.

Re:Some Sense Restored?

[Dagger2]

In RHEL 7 and downstreams, you can choose between LVM2, standard partitioning, or btrfs as ways to carve up your disks. It would be nice to have systemd as an option

From what I've heard of systemd, I'm honestly not quite sure whether this was -- as I initially thought -- badly phrased, or if they are in fact planning to roll partitioning into systemd along with everything else.

Re:Some Sense Restored?

[Anonymous Coward]

Ebola?

Re:Some Sense Restored?

[Anonymous Coward]

Slackware doesn't use the SysV init.

Re:Some Sense Restored?

[mlts]

At this rate, lets just check systemd into the Linux kernel tree itself and call it done.

Re:Some Sense Restored?

[Anonymous Coward]

-1? I guess not a lot of fans of systemd in the moderator pool.

Re:Some Sense Restored?

[Anonymous Coward]

What if blowhards with an obvious agenda didn't come to /. spewing poorly written fantasies which contradict everything we see in the real world? What a wonderful world it could be.

Re:Some Sense Restored?

[mfwitten]

Compared to what Arch used to be, it is indeed worthy of the epithet "automagic".

Then again, I've always had the impression that Arch maintainers tend to confuse "Keep it Simple" with "Keep it Simplistic".

Re: Some Sense Restored?

[CPUmonster]

Sadly, eventually everything comes down to the almighty dollar and greed. Linux is no different I'm afraid.

Re:Some Sense Restored?

[X0563511]

Everything Pottering has done, I can't stand. That can't be a coincidence.

Re:Some Sense Restored?

[X0563511]

Which is a perfect argument as to why upstart and systemd can go fuck themselves with rusty spoons.

Re:Some Sense Restored?

[Anonymous Coward]

Let's pretend I have a RHEL 6 system. I'm running Apache.

Someone busts Apache. They execute a shell, which is possible because I've configured selinux to allow this..

Game over? Not quite. They can't access anything other than a few items in /var, /var/www, and the apache configuration files, and libraries. They can't get into /home. They can't copy out my database.

Not very useless at all, is it, even after I gimp it by letting Apache run bash?

Re:Some Sense Restored?

[DrJimbo]

The problem with supporting multiple init systems is that each package that provides a daemon needs to support all of them.

I agree with you in theory. In this case SysV init has been around for ages so SysV init scripts already exist for almost all packages. Just don't remove those and there is very little additional work required to maintain the SysV init scripts.

Yes, new packages will need to support both for a while, but this is a tiny fraction of the work to create and maintain a new service. It is a very small price to pay in order to get some breathing room and a graceful transition period.

It will give people a chance to put down the torches and pitchforks for a while. One of the biggest objections to systemd was that it was being rammed down our throats whether we wanted it or not, whether it was ready or not, etc. Look at Pulse Audio. After a few painful years, it was finally ready for non-beta use. Systemd should be given a similar incubation period during which people can easily choose to use it or not.

On a more poetic note::

Before the creation of Arda (The World), Melkor was the most powerful of the Ainur. Because of his unique station, he sought to create wills in the manner of his own Creator, so he alone would venture sometimes into the Void in search of the Flame Imperishable, the Secret Fire, which would grant him this ability. But he never found it, as it is with Eru only. He had sought to fill the Void with sentient beings and was dissatisfied with Eru's abandonment of it. Instead, in what he hoped would be an expression of his own originality and creativity, he contended with Eru (God) in the Music of the Ainur, introducing what he perceived to be themes of his own.

Unlike his fellow Ainu Aule, Melkor was too proud to admit that his creations were simply discoveries wholly made possible by, and therefore "belonging" to, Eru. Instead, Melkor aspired to the level of Eru, the true Creator of all possibilities.

During the Great Music of the Ainur, Melkor attempted to alter the Music and introduced what he believed to be elements purely of his own design. As part of these efforts, he drew many weaker-willed Ainur to him, creating a counter to Eru's main theme. Ironically, these attempts did not truly subvert the Music, but only elaborated Eru's original intentions: the Music of Eru took on depth and beauty precisely because of the strife and sadness Melkor's disharmonies (and their rectification) introduced.

Since the Great Music of the Ainur stood as template for all of history and all of material creation in the Middle-earth cycle (it was first sung before Time, and then the universe was made in its image), there was an aspect of everything in Middle-earth that came of Melkor's malign influence; everything had been "corrupted". Tolkien elaborates on this in Morgoth's Ring, drawing an analogy between the One Ring, into which Sauron committed much of his power, and all of Arda -- "Morgoth's Ring" -- which contains and is corrupted by the residue of Melkor's power until the Remaking of the World.

Re:Some Sense Restored?

[sjames]

I don't think there would be too many such cases, most of the init scripts are primarily boilerplate.

Re: Some Sense Restored?

[substance2003]

Why wouldn't it be different? Most of the open source projects where there was a major disagreement ended up with a fork.
Just think of the Open Office when Oracle was just letting it die. People just went and did Libre Office when they were ignored.
There's no reason to think that the folks over at Debian couldn't just create their own fork if they felt they were being ignored.
If that were to happen, it would then all come down to how many Debian users move over vs who stays.
That being said, I'd rather they all come to a consensus that everyone could be happy with.

Re:Some Sense Restored?

[tajribah]

A traditional init script is just a shell script, including almost invariably a couple of nasty race conditions and other subtle bugs. Starting and stopping a daemon safely is close to impossible in shell. I am not a huge fan of systemd, but init scripts written in shell are a nightmare.

Re:Some Sense Restored?

[Anonymous Coward]

This is one of the big reasons package maintainers and developers like systemd. They don't have to include boilerplate. Unit-files are easily maintained by developers instead of by distros and package maintainers save a pile of time.

Re:Some Sense Restored?

[devman]

Its actually one of the big reasons systemd is popular with distros/package maintainers. Unit-files are maintained by the upstream and not customizing initscripts with lots of boilerplate saves package maintainers time. Daemon configuration being declarative has been a long time coming.

Re:Some Sense Restored?

[CRCulver]

Gimp has a dbus dependency, and dbus in turn has the systemd libs as dependencies.

Re:Some Sense Restored?

[gl4ss]

but it is a game over when due to exploit it runs something you didn't allow

Re:Some Sense Restored?

[geminidomino]

Unless, of course, you have a database backend for anything on your web server. If the apache daemon can access it, so can the asshat who exploited it for a shell.

Re:Some Sense Restored?

[rastos1]

The problem with supporting multiple init systems is that each package that provides a daemon needs to support all of them.

The idea that "a daemon needs to support an init system" somehow does not make sense to me. But I'm ready to improve myself and learn. So, please, enlighten me:

Let's say I have a daemon that implements a network server. You start an executable, it reads a config file, opens a socket, listens for connections on some TCP port, reads a command from the socket, sends a reply. It can be shut down with a specific command received via socket connection or perhaps by sending a SIGTERM.

What do I need to do to "support an init system"?

Re:Some Sense Restored?

[causality]

Gimp has a dbus dependency, and dbus in turn has the systemd libs as dependencies.

Which still sounds odd to me. I'm running Gentoo on my main desktop (Mint on my laptop) and have never installed systemd. I've decided to stick with OpenRC. GIMP works fine here and I do have dbus installed.

It seems this dbus dependency is not an unsolvable problem.

Re:Some Sense Restored?

[TWX]

Yes. I look at systemd as being the opposite in what I want; I deal with mostly daemon-serving boxes that do special purpose tasks. Those boxes don't need GUIs, and outside of storage don't really even need plug-and-play. They need to be repairable on the console without ever gaining physical access to the box, and everything needs to be crystal-clear with the configurations.

Re:Some Sense Restored?

[mrchaotica]

Yes, new packages will need to support both for a while, but this is a tiny fraction of the work to create and maintain a new service. It is a very small price to pay in order to get some breathing room and a graceful transition period.

See, the problem here is that your whole concept of the issue is mistaken. You're talking about supporting both "for a while" during a "graceful transition period" when the issue is that people don't ever want to switch. Not now, not after a "transition period," not 1000 years from now -- never. The issue is that lots of people see SystemD as fundamentally wrong, bad, incorrect, doubleplusungood, and anathema to the "Unix nature." A "graceful transition period" will not and can not fix that!

Re:Some Sense Restored?

[Anonymous Coward]

Which is a perfect argument as to why upstart and systemd can go fuck themselves with rusty spoons.

Yeah, Itanium didn't support x86 well enough and it went fucking itself with rusty spoons. It's why we can't have nice things.

Re:Some Sense Restored?

[Anonymous Coward]

Well, who wants this? Does anyone but developers use Linux on the desktop? I want Linux on the desktop precisely because it is a desktop OS that does everything the same way a server does, so I can develop server-ish stuff from the comfort of KDE.

Re:Some Sense Restored?

[sjames]

Why would a developer maintain a unit file suitable only for Linux when they also support *BSD which can never go to systemd?

Re:Some Sense Restored?

[Anonymous Coward]

Yes, but you're talking about Debian. It will be five years, thirteen committees, two general resolutions, and eight votes until dbus is compiled without that dependency.

Re:Some Sense Restored?

[metrix007]

You couldn't be more wrong. Improving an dauditing code is a noble goal, but OpenBSD haven't done enough in that regard. They were vulnerable to heartbleed just as everyone else, were they not?

SELinux isn't the nicest implementation, but the idea is sound. Take away the legacy concept of an all powerful user. Don't have processes automatically inherit permissions, instead assign them only the permissions they need.

There have not been many SELinux exploits and you generally need local access anyway, with the ability to run executable. If SELinux is in place, that actually becomes a hell of a lot harder.

I'd much rather have a system that protects against unknown future attacks than a system which does nothing to protect against attacks and instead tries to remove them all..leaving little to deal with to contain a compromise.

Re:Some Sense Restored?

[HiThere]

I don't know about him, but I date the automagic systems back to early versions of Mandrake Linux.

Please note: There's no reason a felxible desktop system can't be sysV init. Many have been. In fact, almost all of them until extremely recently. Debian Etch was an excellent desktop system. I've disliked many of the changes since then. (The only one I found useful was the automatic identification of SCSI devices w/o regard to boot order, though UUIDs are clumsy to type, and I which that a simpler system specific id could have been used.)

Re:Some Sense Restored?

[bigfinger76]

Yes, there are non-developer users of Linux on the desktop.

Re:Some Sense Restored?

[HiThere]

testing has had some really bad problems with systemd. But it *is* testing.

OTOH, I see not one single advantage to me in using systemd. I see several advantages in avoiding it. E.g., I have a non-standard partition arangement that I frequently need to hand edit into fstab. I'm not convinced that this will remain possible under systemd, as it seems to frequently say "my way or the highway". This causes me to lack any trust in it remaining usable. (It currently is usable, but then I switched to Ubuntu to experiment with it without rendering my system unbootable. So in a reasonably debugged system it works. But it isn't nearly as flexible. I don't trust the intentions of its developers. And when an error in the log files gets responded to with a "won't fix" reply, I feel my distrust is vindicated. I'm also disturbed that they are expanding it to include its own terminal interface. This seems to clearly be an embrace and extend operation. The existence of the third step is, at this point, merely a hypothesis, but the circumstantial evidence is suggestive.

Re:Some Sense Restored?

[Anonymous Coward]

Its actually one of the big reasons systemd is popular with distros/package maintainers. Unit-files are maintained by the upstream and not customizing initscripts with lots of boilerplate saves package maintainers time. Daemon configuration being declarative has been a long time coming.

There's no reason declarative start scripts can't be used with sysV. It requires some retooling of the implementation to accept declarative files on top of shell scripts, plus bundling a 'shell' program that parses and executes the declarative ones but there's no need to replace the whole system just for that. A declarative format ultimately maps to a bunch of shell commands anyway, it's just a cleaner way of doing the same thing so the existing system should be able to cope with it.

The only thing systemd does that sysV cannot reasonably do is "socket activation", everything else just requires a few extensions and cleanups.

Re:Some Sense Restored?

[afidel]

You know what's funny, you blast systemd as insecure yet it is every init based system with Bash installed (most of them, though certainly not all) that has been a security issue in the last few weeks thanks to shellshock.

Re:Some Sense Restored?

[rahvin112]

Did the microchip in your brain tell you to say that?

Re:Some Sense Restored?

[TangoMargarine]

I actually did a "which systemd" on my current Mint XFCE install--which has GIMP installed and up-to-date--and got only silence.

Um...I know apt-get isn't shy about installing all kinds of dependencies when I need them...wat.

Re:Some Sense Restored?

[JohnFen]

Yes, nondevelopers do use Linux on the desktop. I personally know 6 of them.

Re:Some Sense Restored?

[TangoMargarine]

1 "it works and i figure if it isn't broken don't fix it"
2 [condescension about sys v init being old]
3 goto 1

Self-defeating trolls. Huh.

Re:Some Sense Restored?

[gweihir]

Actually, there is no problem with systemd as long as you can avoid it easily.The fanbois shall have their toy, I have no issue with that. But forcing it on everybody, even those that actually have a clue about good and reliable system design, is just wrong.

Re:Some Sense Restored?

[TangoMargarine]

Remiiiiind you of anything??

*cough*beta*cough* Still interested to see how long they wait in the hopes we cool down before they roll it out anyway.

Re:Some Sense Restored?

[gweihir]

Well, obviously "moving to the 21th century" means being ignorant about things that work. New is not equal to "better" in any way. Maybe they could put a Farcebook client into systemd as well, that would show the quality level of the design of this thing clearly.

Re:Some Sense Restored?

[gweihir]

Systemd does not add security. It removes security y being complex enough that it must introduce new vulnerabilities. There is no way around that, the human race does not know how to write complex software from scratch without vulnerabilities. Certainly, the systemd team has proven that they cannot even manage reliable software.

Re:Some Sense Restored?

[gbjbaanb]

but if Debian drops systemd, what will "automagic" Ubuntu do, seeing as its very much based on Debian?

What it will do is divide the Linux distros into systemd and dependencies, and those without (or with something better). If projects like Gnome become more tied into systemd, will this mean they won't work on non-systemd distros?

Re:Some Sense Restored?

[lannocc]

Really, you should use `locate` or `find`, as `which` only locates executables that are in your search path.

Re:Some Sense Restored?

[Richy_T]

Systemd is the Poochie of the Linux world?

Re:Some Sense Restored?

[Anonymous Coward]

It is their clearly stated purpose. They intend to simply take Linux as a set of device drivers and have set themselves the goal of 'writing an operating system atop them.' As unlike UNIX as they can get away with, and apparently there is nothing they can't get away with.

My objection is fundamental. It is like Libertarians debating against a government program. They will happily USE the fact the program is failing to achive the purpose it was created for. They will even wield arguments that make claims that it isn't even possible, in theory, that the program can ever achieve the goal. Because those arguments work on the undecided masses. But their objections aren't really based on any of that, they object to the premise.

That is my position vs systemd, I object to the very premise of replacing a known, understandable (by non dedicated developers) and flexible UNIX philosophy based tech with one ripped right out of the Windows world. I am happy to point to the failures of systemd, happy to point to the 'won't fix' attitude that follows Pottering like a stench. But even if it worked flawlessly I'd still avoid it like a veneral disease. Because it is not just broken, it is wrong.

Th resolution to the problem is clear, systemd adoption is being driven by the Gnome3 tie in. So drop that. Do not be confused by the naming, enough projects change names we should able to cope. Gnome 2 changed names to Mate, Gnome 3 is an entirely new codebase that forked off. Mate didn't exist for Debian 7 so write that off as a wrong turn. Restore the default desktop from Debian 5 and 6, ditch Gnome3 AND systemd, problem solved and we all live happily ever after.

Re:Some Sense Restored?

[Anonymous Coward]

You made it harder, might even less script kiddie vulnerable. But apache can access the database, files accesable to to apache almost certainly contain the details on how (hostname, port, username, password) to connect to the database and the attacker has a shell. You bought some time but the clock is ticking. Bottom line, if you screw up and give them a shell and you must assume they are going to win.

Besides, I have never managed to keep a SELinux enabled all the way to putting a machine into production. Neither server or workstation. I have tried. But it is almost entirely undocumented, undiscoverable and utterly broken. I even bought the O'Reilly book but it documents a product that doesn't actualy exist. Which is typical of all this New Tech, including systemd to bring this back on topic.

Re:Some Sense Restored?

[gerddie]

This vote is not about whether systemd will be the default init system for jessie, it is about whether to ensure that other software packages are kept independent from the init system that is installed, because currently it seems that more an more software packages pull systemd in, even though they are not directly related to the init system.

Re:Some Sense Restored?

[jbolden]

If you just want a sysinitv2 for things like cross-service dependencies/events OpenRC is that. It has started. It works. But OpenRC can't keep daemons alive. That's the big trade off.

Re:Some Sense Restored?

[jbolden]

Will users of other init systems be treated as second-class citizens.

Yes. Once applications can freely have long chains of cross-service dependencies which they are assured will be kept functional by the init system they will be written to require this. Debian can't do anything about that. It is already happening at the IaaS and PaaS level. The alternative is going to be you run Debian but all your applications run inside some micro-PaaS that has these functions anyway.

Re:Some Sense Restored?

[TWX]

For how many of them did you set up their computers?

Re:Some Sense Restored?

[TWX]

They'll fork, or Ubuntu will be forced to consider following Debian back to the UNIX model with System V.

Re:Some Sense Restored?

[TWX]

Yep. I'm one, I've got a box at home and my primary box at work both running Linux. I do network administration and it's convenient, with the amount of SSH that I do, to have Linux as my desktop.

I wish that I'd ended up with the X1 Carbon instead of the Yoga for my work laptop, the tablet doesn't get along well with Linux and is stuck as a Windows machine :(

Re:Some Sense Restored?

[tqk]

I actually did a "which systemd" on my current Mint XFCE install--which has GIMP installed and up-to-date--and got only silence.

Unsurprising. Same here. Wrong command. Try:

aptitude search systemd | grep ^i
i libpam-systemd - system and service manager - PAM module
i libsystemd-daemon0 - systemd utility library
i libsystemd-journal0 - systemd journal utility library
i libsystemd-login0 - systemd login utility library
i systemd-services - systemd runtime services
i systemd-shim - shim for systemd

Huh. I'm running a (very recently installed) hacked Mint 17 (and I'm still learning how it works; long story).

Um...I know apt-get isn't shy about installing all kinds of dependencies when I need them ...

Tell me about it ("CUPS"). "aptitude upgrade" has always wanted to upgrade/re-install seemingly thousands of packages every time I try it. I call these things "Debian gotchas", but I don't much worry about it. Debian would be exstatic for me/us to volunteer to see if I/we can "fix" them if I/we can. I'm pretty lazy, and I trust the DDs to generally do the right thing (they're smarter than I am). This "systemd dependency" issue is just the latest "WTF?!? *Everything* drags in CUPS!!!" issue. Meh.

[Filter error: Please use fewer 'junk' characters.] FUCK THE HELL OFF, /., DAMNIT! Leave my <code> inserts alone, FFS! Ass HOLES!1!

Re:Some Sense Restored?

[Skarjak]

Nonsense. Arch is now harder to configure with systemd. The Arch maintainers do believe in "Keep it Simple", but to them, simplicity is elegance. They adopted systemd because they believe it is the more elegant solution. Ease of use is not their primary concern, obviously, and this is really damn far from an "automagic desktop" distro. The very claim is quite ridiculous honestly.

Re:Some Sense Restored?

[Anonymous Coward]

Read the part you quoted again:

each package that provides a daemon needs to support all of them.

It's not the daemon that needs to support one or more init systems, it's the package. IOW, he's saying the package maintainer needs to supply a systemd-style unit file as well as a SysV-style init script, and make sure both work correctly. Not a herculean task, but still more work and a doubling of combinations to test.

Re:Some Sense Restored?

[thegarbz]

That people think GIMP and GNOME require systemd is outright absurd. They both depend on a single feature exposed by the kernel which have nothing to do with the init system. It just so happens that the most prevalent API available for this is currently the logind component of systemd.

Rather than bitch and moan about them tying the two together, why not start / sponsor the start / donate to an alternative API that's not part of systemd which GNOME / GIMP can depend on for the functionality they need.

As for Poettering's track record. His software is released early in it's infancy, that and that alone (in my minority opinion) is his big problem. All of his previous projects have resulted from a very real need to clean up some of Linux's most stupid (again in my opinion) design features. People like talking about the disaster of pulse-audio, but those same people have never had the fun of attempting to plugin a USB headset to take a call or transfer audio to another device currently playing, or never had to try and get bluetooth audio work. For all it's complaints pulse-audio is now mature and (in my opinion) works rather well.

systemd is not just an init system. The only people who claim that are those that haven't understood what Poettering is making. It's a complete system management platform. I have no opinion on if it will be good or bad to go this route, but it does look like it will solve some very real gripes that I and others have with the current Linux setups, which includes the arcane task of digging through log files. (Ok I have an opinion that binary logs aren't the way to go, but the old system was just screwed).

Re:Some Sense Restored?

[thegarbz]

Given the size and complexity of a typical upstart script I think this is a non issue. The old shell scripts are by far the largest and most complicated of any method to start the system.

Ubuntu already support multiple startup scripts for different systems. The entire networking upstart script is 7 lines on my system, compared to 120 for the shell script. I hardly consider that an unsupportable problem.

Re:Some Sense Restored?

[sjames]

Keeping daemons alive is easily enough added. Just have OpenRC start a program whose job is to re-run the daemon when necessary. It could be the same manager I proposed for SysV, in fact.

Re:Some Sense Restored?

[tqk]

There are changes to Linux like SELinux and AppArmor which are must haves.

I don't know anybody who uses Linux who doesn't despise SELinux. Data centres or corporate firewalls, maybe it's used, but I haven't seen it here.

Re:Some Sense Restored?

[tqk]

You start an executable ... What do I need to do to "support an init system"?

[Guessing] Tell it how to start an executable?

Re:Some Sense Restored?

[Anonymous Coward]

At least Arch makes it painless to switch init systems.

I've got OpenRC running beautifully on my Arch box, and one day I'll replace udev with eudev so I can get rid of systemd entirely.

Re:Some Sense Restored?

[laffer1]

You do realize that daemons started by systemd could be vulnerable to right? Web servers, mail servers, etc. It's the going to save you from GNU bash.

Re:Some Sense Restored?

[styrotech]

but if Debian drops systemd, what will "automagic" Ubuntu do, seeing as its very much based on Debian?

Go back to Upstart? And carry on just like it is still 2012.

You're forgetting that Ubuntu wasn't really a big fan of systemd, and it was only Debians decision that caused them to reluctantly switch anyway.

Re:Some Sense Restored?

[jbolden]

I suspect if it were easy the OpenRC guys would have done it since this is by their own admission the main thing that people wanted systemd for. Upstart does do this and it also ends up being designed a lot like systemd, except that Upstart uses plaintext configs.

Re:Some Sense Restored?

[CRCulver]

You know what's funny, you blast systemd as insecure yet it is every init based system with Bash installed (most of them, though certainly not all)

Debian (you know, the topic of this discussion) and its many derived distros like Ubuntu had for many years used dash as their /bin/sh. Init wasn't passing anything to bash. Indeed, the switch was made because dash offered faster boot times for a script-based init system than bash.

Re:Some Sense Restored?

[Anonymous Coward]

As for Poettering's track record. His software is released early in it's infancy, that and that alone (in my minority opinion) is his big problem.

The problem isn't that his projects come from someone incompetent. He could code viruses for all I care. The problem is many otherwise good distros have decided to include his code and remove all sane alternatives.

clean up some of Linux's most stupid (again in my opinion) design features.

Like following POSIX?

it does look like it will solve some very real gripes that I and others have with the current Linux setups, which includes the arcane task of digging through log files.

Try to understand the guys being thrown down the bus for this could not care less that it could help a few users. They are still getting fucked.

Re:Some Sense Restored?

[Anonymous Coward]

I will not use a distribution with Gnome (or KDE for that matter) but there is lubuntu, xubuntu, ....

I doubt that there will be an official debian based distribution without systemd for jessie.

Re:Some Sense Restored?

[sjames]

It looks a little more complex from the brief search I did. They are also concerned with monitoring the started daemon through cgroups. Currently, that's not TOO hard, but we have been warned that the API may be changing.

Re:Some Sense Restored?

[Anonymous Coward]

I do not understand why certain aspects of systemd technical design can be accepted by the technical committee. Based on their decision on systemd, I can't help but question their abilities to make sound technical discussions.

This serves as a warning and I will stay away from debian based distributions from now on.

PS: I used mainly server-based linux distributions.

Re:Some Sense Restored?

[the_povinator]

I tried using Ubuntu briefly (cloud-computing stuff) but I found upstart very very difficult to work with, and, if I recall correctly, buggy.

I've never attempted to use Ubuntu since.

Re:Some Sense Restored?

[Anonymous Coward]

That people think GIMP and GNOME require systemd is outright absurd. They both depend on a single feature exposed by the kernel which have nothing to do with the init system.

Caveat: I'm a part-time distro constibutor, and you're incorrect here.

I can't speak to GIMP, but Gnome most *definitely does* depend upon systemd -- the Gentoo distro just went through this, and it's documented in their bug tracker that systemd was now mandated via upstream. eg, Gnome3 depends upon logind which depends upon systemd. GDM now depends upon systemd. etc. etc. etc. This all really started happening around 3.8-3.12.

This left gentoo devs in the position where they could patch Gnome3 to not require logind, but then suspend/restore doesn't work unless they revert and patch upower, and on and on on.

Re:Some Sense Restored?

[Anonymous Coward]

If that persists for more than 4 hours you should see a doctor.

That is very difficult to do with SystemD(eath) constantly trying to restart the process when it fails (falls limp).

Re:Some Sense Restored?

[Anonymous Coward]

Actually, there is no problem with systemd as long as you can avoid it easily.The fanbois shall have their toy, I have no issue with that. But forcing it on everybody, even those that actually have a clue about good and reliable system design, is just wrong.

And another thing....

For those packages that don't implement a SystemD(eath) unit and stay with "init" style startups, that is fine with me.

For those packages that "move" to SystemD(eath), that is fine with me.

In either case there will be an audience for those packages.

What if a package is "great", but it only supports SystemD(eath) or "init" style? If it is "open source" and it's license allows, them someone might "fork it" to make the necessary changes. That is fine with me.

As for distributions that decide SystemD(eath) is the only way to go, but everybody wants to use it with "init" style scripts? If it is "open source" and it's license allows, them someone might "fork it" to make the necessary changes. That is fine with me. The same thing with being "init" style and people wanting it to run SystemD(eath).

The point is this: The Debian proposal by Jackson is a request to support multiple "init" systems so the user can decide which one they want to use. If the user wants to use Gnome3, well then SystemD(eath) is a requirement per Gnome developers...unless some wants to "fork it"...if the license permits that.

Ultimately the argument could come down to 1 or more new installer screens that present the user with "conflict resolution" questions. You want Gnome3? You gotta have SystemD(eath) also, but you selected XYZ and it only works in "init" style. Here are your choices. Yep, that would definitely add some work to the developers and packagers, as if sorting out package dependencies was not hard/complicated enough already.

The alternative is: Every distribution that runs SystemD(eath) has precious few ways to differentiate itself from the others. So what if they say, "Hey! We use Gnome3 and we applied this super fancy skin to it that does eveything for you AND makes your coffee.", but everything else "under the hood" is just a port of another disitribution's packages (looking at Ubuntu here) with some "fluff" added.

Seriously, the distribution that gets the question right with regards to choice in "init" systems & desktop GUI interfaces, and getting the necessary "conflict resolution" built into it's installer and package maintenance system, AND with the "added value" of having a "super stable train" for server environments as well as a more "cutting edge train" for "advanced" users...that distribution could be a real winner...IMHO.

But would/could it happen? I dunno.

Re:Some Sense Restored?

[afidel]

I learned something today =)

I've been using Debian since forever, but dash must be a good enough copy of bash that it's never come up, heck I even run Debian on my cellphone via chroot!

Re: Some Sense Restored?

[Electricity Likes Me]

What services does your daemon provide? Will it rebind to network interfaces if they change? Does it need to write to disk? Does it need syslog to do logging output? If it crashes, should someone be notified? How? When? How often? Who?

Re:Some Sense Restored?

[rastos1]

You start an executable ... What do I need to do to "support an init system"?

[Guessing] Tell it how to start an executable?

That is a solved problem and does not need a new solution of the size of systemd.

Re:Some Sense Restored?

[rastos1]

So as long as I can disable dependency checking, I can avoid systemd altogether?

Re: Some Sense Restored?

[rastos1]

What services does your daemon provide?

?? Does it matter? It answers queries received over the network.

Will it rebind to network interfaces if they change?

Hmm. Can you be more specific? I have problem coming up with scenario where replacing of NIC or changing of MAC/IP address could be handled transparently to the clients.

Does it need to write to disk?

Yes.

Does it need syslog to do logging output?

Does it matter? The typical configuration is to use direct logging to file. Without syslog. On Linux syslog may be used to log startup/shutdown of the daemon. Most likely using logger(1). On other platforms some native solution would be used.

If it crashes, should someone be notified? How? When? How often? Who?

If it crashes, people will notice because they don't get a service the daemon is providing. Immediately. They will notify the administrator and require the service to be restored. The administrator will capture the current logs and storage for investigation and restart the service. For HA systems, there will be failover system.

Re: Some Sense Restored?

[Anonymous Coward]

For my use-cases systemd was a huge step forward compared to the traditional arch way. I do tend to run rather esoteric setups though:-)

Re: Some Sense Restored?

[t_hunger]

How should that work? You need cgrouo support in the init system for that. Do you seriously think that is ever going to be added to sysv init?

Having some external process managing cgroups for init itself can not work, except by having init start the cgroup manager and then having that start everything else.

Re: Some Sense Restored?

[t_hunger]

Whichh sane ternatives to pulseaudio are you referring to?

Re: Some Sense Restored?

[Anonymous Coward]

How is systemd straight out of windows world?

Why is it harder to understand than sysv init?

Re: Some Sense Restored?

[Anonymous Coward]

We bad the same outcry when the true Unix way of BSD-style init was replaced with this overly complex and unnecessary sysv init.

Re: Some Sense Restored?

[Anonymous Coward]

Because the developer will most likely use Linux to develop on. There are not that many BSD based devs out there!

Hardly anything is tested on BSD nowadays.

Re: Some Sense Restored?

[Anonymous Coward]

You are aware that upstart is dead, are you?

Canonical stopped development of it. You still get patches while Ubuntu versions using upstart are supported, but there is no new development happening.

Re: Some Sense Restored?

[t_hunger]

The complexity of systemd is in stand-alone executables running inseverly restricted environments (no access to /home, private /tmp, read-only /, no network but through one file descriptor, etc.). That is a huge step forward.

This is especially true considering that the systems complexity is also running as separate, far less restricted services on non systemd systems (e.g. cron, xinetd, nwtpd, etc.).

Re:Some Sense Restored?

[Anonymous Coward]

Jessie can still be used without systemd. I uninstaaled it, installed systemd-shim and the old style init and everything works as before, except certain parts of Gnome, which are not that great, anyway.

Re:Some Sense Restored?

[Anonymous Coward]

Neither Gnome nor Gimp actually require systemd even now (on a Debian Jessie system, anyway). Only a handful of Gnome utilities do. People are writing systemd replacements (systemd API providers) all the time.

Re: Some Sense Restored?

[gweihir]

Since when are monolithic "stand-alone" executables a hallmark of secure coding? Sure, some things need to be complex, and then it is necessary to do a clean privilege-separation and minimal-privilege approach. But that does not make them more secure, it only brings them (if done right) to the level of simple things. Replacing a simple infrastructure with a complex one can in practice _never_ increase security and you are very lucky, and need very competent, dedicated and experienced architects, designers and implementers to make it not _decrease_ security. Systemd has neither.

Re:Some Sense Restored?

[gweihir]

Well, we will see. As to "GUI", what does that have to do with the distro? I have been using the same, carefully optimized fvwm configuration for 25 years by now (originally created on SunOS, one major change in the config formar bit not the functionality when fvwm2 came out), I have no need or desire to learn something new every few years when I already have something that works exceptionally well for me.

Re: Some Sense Restored?

[sjames]

Why? The beauty of using scripts is that the scripts can invoke a helper and that helper can use cgroups. I don't need for init itself to be changed in any way. I can do it myself without getting anyone else involved and without wading through anyone else's code. Then I can try it out on just one or two daemons on my own system. Once done, others can add it to their init scripts of not as they see fit.

Unless someone screws up the cgroups API really badly, that is.

Re:Some Sense Restored?

[See Attached]

Should SystemD then be a fork, and leave other init managers to fight it out? If all the things that rely on systemd had published hooks, then there could be some co-opetition. Then the most popular solution would (in theory) be adopted most probably, and the others would wither away?

Re:Some Sense Restored?

[goulo]

I'm not sure I get your point. It sounds like you think shellshock is a security risk only during system init...?

The shellshock exploits I've read about are not related to system init.

https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29

Or are you suggesting that people with systemd don't even have bash on their systems?

Or are you arguing that because bash has (had) a serious bug, it means we shouldn't be concerned about other software like systemd having bugs?

Re:Some Sense Restored?

[sjames]

That would be closer to the right thing, though the hooks should be optional. If they aren't, then we get stuck with a poorly designed API.

I find it hard to imagine why Gnome even benefits from a systemd hook. What use could it possibly be? Sure, an app that is an optional part of gnome (or better, 'sold separately') might be useful, but the consequences of running Gnome without systemd should be at most that that one app doesn't run and the rest works as it always has.

It's like your car not starting because you hung a different air freshener from the rear view. (We had to have a car analogy in here somewhere :-)

Re: Some Sense Restored?

[Anonymous Coward]

It's harder to understand, because SystemD config files are very compact and define only minimal set of information needed for the task to be done, moreover in completely new unknown syntax, so no one really knows what happens behind the scenes and even why everything works. Whereas old init scripts are full of known and proven syntaxes like "if then case start-stop-deamon" and so on with dozen of parameters, so definitely they are doing something important with so many lines of code and given enough amount of time you would for sure understand why they aren't working in your scenario. In the meantime, with that warm feeling that you could fix whatever really is wrong with it, you've found on some forum that putting familiar and safe 'sleep 10' near the beginning should solve the problem, and it really did! So once again you are happy to have such an opportunity to fix the issue thanks to the power of scripting language working behind the scenes. But... hmm now other service seems to got stuck during the boot. Let's see, I guess there's another' 'sleep...' missing somewhere for sure.

Re: Some Sense Restored?

[Anonymous Coward]

... POSIX is important to the Linux community because... They secretly want to port their software to Solaris someday?

Re: Some Sense Restored?

[Anonymous Coward]

Straight alsa.

Re:Some Sense Restored?

[Anonymous Coward]

Using a shell script to start/stop/check/reload/checkconfig a process is brain dead. No process should be allowed to exist without conforming to simple well-understood protocols for these common functions. Any process that cannot conform should not be distributed.

Re: Some Sense Restored?

[Anonymous Coward]

For my use-cases systemd was a huge step forward

I like to think it's just the Linux people who want to be on the "leading edge" so bad they walk right off the precipice.
-- Craig E. Groeschel

Re:Some Sense Restored?

[the_B0fh]

So, how many systems do you manage where SELinux is actually in use, and by that, I do not mean enabled with a "allow all".

Re:Some Sense Restored?

[thegarbz]

I know you're talking in the literal sense, but the reality is that there's only one package providing the feature Gnome wanted.

My point was that Gnome does not have a dependency on systemd as the system management package. You are correct it has a dependency on logind. Why? Well why don't we ask the Gnome developers, and if they have a good reason for wanting a specific feature then implement it as a separate API. I remember reading there's at least one project looking to fork logind in a way to make it independent from systemd for this very reason, can't remember the details but it was in some slashdot post.

Now the irony is every time we discuss closed source we get endless comments about open source being better because you can change things the way you want. Now we're discussing open source there are are pathetically few people coming forward with this as a possible option.

Gnome does not have a dependency on a specific init system. It has a dependency on a specific feature of a package which people incorrectly refer to as only an init system. Find out what that feature is and implement it separately.

Re:Some Sense Restored?

[putaro]

But you have to support multiple init systems anyway unless you're going to make your package dependent on the latest distro release.

We have stuff that runs on RHEL, Debian and Ubuntu. We can't ditch RHEL 6 , Debian Wheezy or Ubuntu Trusty Tahr support for quite a few years.

Re:Some Sense Restored?

[putaro]

The daemon should stop and start itself safely. The shell script is just there to tell it to do so.

Re:Some Sense Restored?

[tajribah]

That's a noble goal. Do you have any examples?

Re: Some Sense Restored?

[Electricity Likes Me]

So it can't run a desktop. Or a laptop. Or any system where network status might change really.

It requires a whole min $50,000 a year employee to keep it running (sysadmin). You're going to write a separate HA failover daemon (or you're going to use...something that will look a lot like an init system).

You want to log to file but don't now if the disk is mounted, and writeable (again: how are you going to ensure this, what do you do if it fails?).

And this is just your simple network service. What about console services? Localization? Graphics? Drivers and daemons for hardware?

This is just a crazy suggestion, but maybe a normal computer is fairly complex since people want their computer to do a lot of things, and if you have such simple requirements, then you shouldn't be installing a desktop or (apparently in your example case) server OS. I would suggest a microcontroller. Of course even there you'll still need some type of bootloader to get things running...

Re:Some Sense Restored?

[putaro]

Postgres seems to do it OK.

Re: Some Sense Restored?

[Anonymous Coward]

Hear hear. I just setup a new Linux install for a family member and I had Alsa installed and working in about a minute and a half.

If I was offered $10,000 to use PulseAudio I would decline just on principle. That is garbage.

Re:Some Sense Restored?

[metrix007]

Not many, although I manage many with RSBAC.

Re: Some Sense Restored?

[Anonymous Coward]

if this is you, i didn't think you'd ever use linux due to its reliance on "cat"

Re:Some Sense Restored?

[Anonymous Coward]

But there are a lot of of server use cases where you really dont want a pid 1 daemon to always keep an daemon alive, since it can cause all sorts of split brain issues in a cluster if one node just wont let a package/application fail, even if it cannot run correctly. and the whole toc or "crash now with a vengence" mecanism a lot of clusters use is not something a lot of admin like to see because it can cause unwanted fallout. Sure it can be fixed but it's stil requiring stuff to be redesigned for systemd.

A huge part of the problem with systemd is that it kind of locks a lot of stuff into the needs of a few use rcases, and sort of throw a lot of other stuff under the bus. Projects that want to work flawlessly on both xBSD, solaris, and Linux might run into a lot of problems if systemd start forcing people to use systemd api's on linux etc.

The benefits of the small lean pid 1 system that have been the norm for unix like system. are that they allow for a lot more local customization then a huge monolithic pid 1. All of the systemd functionality were basically there as separate tools before systemd which is also why the systemd source tree got so big so fast, and before systemd opting out of individual components did not involve recompiling a major system component etc.

Re:Some Sense Restored?

[See Attached]

What we face losing is the buy-in from the majority of users. Perhaps a surveymonkey would be good to pick out the good from the bad, and start anew on improving the boot process. While Linus is a benevolant dictator, he had many good choices and built a stellar product that inspired a global assemblage of workers thru trust and inspiration. Systemd (how ever its spun now) seems to have revoked that trust, and switched passion for frustration. $.02. Redhat 6 is good. I predict a long life there.

Re:Some Sense Restored?

[jbolden]

You are making a good point. I wish you would get an account.

And absolutely you are correct. Systemd is taking functions that were part of the PaaS and driving them into individual nodes which means the PaaS needs to be redesigned for systemd. The PaaS people all think this is a plus, the lower level hooks are an advantage.

Projects that want to work flawlessly on both xBSD, solaris, and Linux

That's a pretty obscure use case a cross platform daemon, running in a cluster (i.e. not virtualized hardware), that can't just use a low level daemon for Linux / systemd support. I'm going to assume systembsd or something similar is going to exist for BSD long term, but right now it does. So yes short term those projects get hurt by systemd. Either they are going to only work on obscure distributions or the are going to have to do some engineering. They are an obscure corner case that is going to get hit, but even then it doesn't sound too bad for them.

The benefits of the small lean pid 1 system that have been the norm for unix like system. are that they allow for a lot more local customization then a huge monolithic pid 1

I'm not sure that's quite true. It certainly isn't true for Digital Unix, HPUX, AIX. It was true for IRIX, SunOS.Solaris is a middle case on big hardware it wasn't true as well. It isn't true for OSX either on which systemd is based. But it certainly was true for Linux. And yes it is likely that as systemd becomes the norm people who want to customize are going to have to use more specialized distributions and lose access. OTOH systemd is very configurable so there isn't much reason to just not run the functionality of a component via configuration. The argument is not that systemd has 0 disadvantages but rather that on the whole the advantages so far outweigh the disadvantages that it was safe to just standardize.

Linux does have a healthy distribution ecosystem that allows for non-standard choices.

Re:Some Sense Restored?

[goarilla]

That's not true Slackware uses SysV init (sysvinit-2.88dsf-x86_64-3).
Its init scripts are more BSD like. A few global init scripts in /etc/rc.d/
instead of specially named and numbered symlinks in /etc/rcX.d/.

Re:Some Sense Restored?

[JohnFen]

One.

Re:Some Sense Restored?

[phantomfive]

Interesting ideas.

Hope!

[Anrego]

A very well written proposal that outlines many of the concerns I (as a non-Debian user) and I suspect most have about systemd. It’s worming it’s way into everything for the sake of better integration, which it may deliver on, but this goes against much of the traditional Linux spirit of small self-contained bits that can be swapped out at will.

In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place. Personally I want a hackers OS that I can play with and tweak as I feel like, but I accept that many people basically want open source windows or even just zero cost windows (i.e. free as in my wallet).

I hope Debian rolls back on their decision. I doubt this will happen, but at least we’ll get some more discussion in a somewhat visible forum. I may not agree with a lot of the Debian mentality, but they are very good at thinking about and discussing things, so I think this will be good overall.

And before someone says "just use gentoo", I do, and have for almost a decade (I started using it fairly soon after it came out). The problem is that systemd, being basically a virus at this point, is causing exactly the kind of problems mentioned in the proposal. I've had to use the blacklist for the first time in a while because *McBane voice* the use flags, they do nothing!

Re:Hope!

[FudRucker]

maybe systemD will cause a Fork in the Debian distro,

i like Slackware too, maybe Slackian_Debware

Gentoo users will make a Debtoo

Re:Hope!

[rjmx]

> In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.

I'm not even convinced that it makes for a better-functioning OS. I've been a Debian user for 12 years, mostly running 'testing' distributions. When systemd first turned up, I let it run for a couple of weeks, but switched back to sysV after half of my startup daemons didn't. Tried it again a month or two later, but when it had trouble stopping Samba (and, worse, claiming that it would wait *five* *minutes* before killing the processes, I decided enough was enough, and now I'm in the process of switching all five of my Debian boxes to Gentoo. Now, granted, the testing distribution is for just that purpose -- testing -- but if I'm dealing with the kind of idiot that would claim that systemd results in faster startups, but thinks that a five-minute wait to shut down a process is acceptable, then I want no part of it.

Debian should listen to what its users want, rather than just its developers. We're not all technically ignorant.

Re:Hope!

[Anonymous Coward]

How dare these big distros try to appeal to a broader community. Running Linux just isn't cool anymore if my mom is running it too.

Re:Hope!

[Anonymous Coward]

There was an attempt at a Debtoo a few years ago. I don't think it ever moved past the planning stages though.

Re:Hope!

[Anonymous Coward]

WTF does systemd have to do with your mom?

Re:Hope!

[MightyMartian]

Binary logs are anti-*nix. Rebut that.

Re:Hope!

[drinkypoo]

And before someone says "just use gentoo", I do,

I tried to, so I followed the handbook and ended up with emerge errors I couldn't trivially solve by reading the output... just trying to emerge sudo. Last time I tried gentoo (years ago) it went without a hitch. The install process has actually been made more complicated, which is hilarious, and now it shits itself when followed. So I guess gentoo has reached parity with Linux from Scratch.

Re:Hope!

[Anonymous Coward]

Binary logs are anti-*nix. Rebut that.

journald supports forwarding to syslog

Re:Hope!

[Sarten-X]

this goes against much of the traditional Linux spirit of small self-contained bits that can be swapped out at will.

In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.

Personally, that principle of having many swappable self-contained bits is one of the worst qualities on UNIX.

I've been using GNU/Linux for over a decade. I know my way around most distros, and I can usually figure out what I need to do to accomplish any task... usually. The biggest problem I face now is that distros have so many small components doing their small tasks that figuring out exactly which component is responsible for a given task is no small feat.

I understand and appreciate the programming simplicity that a small component brings, but from a user's (or admin's) perspective, the operating environment is now more cluttered. As distros pick and choose their preferred swappable components, the view gets worse. Sure, I know exactly what the "finger" command does, but it's not obvious that "pinky" is an alternative, because having a lightweight finger command is apparently an important thing. Some distros will even create symlinks or scripts to provide alternative common names for their chosen packages, but there's seldom a guarantee that the input or output will be the same. This is why the first step of many build processes is to examine the environment and figure out exactly what is available on the system, often using methods that uncomfortably remind me of browser-detecting JavaScript.

I'm not saying that systemd is the solution we need, or even that it is a solution. I've just dealt with far too many poorly-named packages to have excessive reverence for this archaic principle.

We should also keep in mind that Linux itself, as a monolithic kernel, defies the concept. By design, the kernel's one job is to interface with every piece of hardware on the machine. Is it really so far out of line to define systemd's one job as interfacing with every service provider in the OS?

Re:Hope!

[Anonymous Coward]

They both suck.

Re:Hope!

[Anrego]

I've used gentoo for a long damn time, so my ability to objectively gauge it's difficulty is probably long gone.

That said, I for one think gentoo has gotten far easier to install and especially maintain. The default profiles are no longer the joke they once were, and most packages are using more generic high-level use flags so you have one --with-feature-x instead of the old --with-compat-mode-z --with-doublefork --with-some-other-unrelated-but-required-flag type stuff you had years ago, which translates into much simpler USE flags. You can actually leave make.conf relatively untouched and still end up with a decently functional system, especially if you want a desktop and go for one of the desktop profiles.

Portage is also a lot smarter these days, being able to resolve many issues that it previously would have died on. When it does run into problems, the descriptions these days are much nicer than before!

I'm being completely honest when I say that systemd has been the first major gentoo headache I've had in a while. Everything was just dandy then suddenly I'm having to switch packages around (udev being the big one), and having to blacklist udev and systemd because so much random shit pulls them in (and a -systemd use flag isn't enough), and then uninstalling a bunch of random packages (like some power management widget that got pulled in by god knows what for some reason).

I know you've probably written off gentoo at this point, here's a completely random bit of usage advice:

- Set use flags as you need them, even if this means re-installing the same thing multiple times. This avoids big important packages being pulled in as mere dependencies (though you can add them to the world list afterwards) and more importantly lets you set up and configure everything one at a time and makes it more likely that you'll notice error messages.
- Don't be afraid of package.keywords, especially for very specific use flags.
- Avoid gnome if possible. I don't know wtf it is with gnome, but it seems to be the poster child for weird and hard to diagnose issues as well as crazy dependency trees.
- Pay attention to what virtual packages are doing. Usually they are in your best interest, but not always.
- Don't bother using ebuilds for web apps

Re:Hope!

[Palinchron]

In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.

In my mind, it comes down to streamlining the common use cases for a given system, while throwing under the bus everyone who wants to do something with their system that Lennart didn't think of or doesn't care to support.

Re:Hope!

[rjmx]

Great! Thanks for the advice.

Re:Hope!

[Anonymous Coward]

Simple. She wants the D and is willing to use the System to get it.

Re:Hope!

[Zeromous]

Great, so what happens when journald breaks>?

Re:Hope!

[Princeofcups]

Personally I want a hackers OS that I can play with and tweak as I feel like, but I accept that many people basically want open source windows or even just zero cost windows (i.e. free as in my wallet).

How about neither? I want a rock solid OS that can scale to N processors, allows hot swapping of hardware, allows the admin to spin up CPUs and memory on a live system, and has drivers that can be added and removed on the fly. That is, all the things that any enterprise level server OS has.

Re:Hope!

[TheCarp]

utmp.

I agree its bad, and its something the unix community has moved away from and avoided, but its not so much "anti-unix" as "What unix did when it was a teenager and would rather we didn't talk about in public, especially not in front of its kids"

And...that is where binary logging should stay, until it can be eliminated entirely.

binary logging is bad mm'kay.

Re:Hope!

[bill_mcgonigle]

And...that is where binary logging should stay, until it can be eliminated entirely.

I don't even know why I'd care if systemd uses a binary representation internally, as long as it can give me human-readable logs with only text tools.

Only showing binary logs with systemd tools is a misfeature of the type "exposing the implementation". Userland requires a UI, and it's bad UI, and frankly bad Unix.

Now then, I hear you can somehow configure systemd to echo a copy of its logs to rsyslog. But, and maybe I'm just a fool with poor GoogleFu, but I tried for a couple hours to get this working and only found company for misery on the mailing lists.

If any systemd fans can point us to a quick-n-easy HOWTO on getting text [r]syslog working under systemd, then by all means shut a few of us up. Tell us how there's plenty of documentation too, we'll all hang our heads and wander away.

Re:Hope!

[Anonymous Coward]

I think Gentoo is moving to systemd too so you are stiil fucked. Gentoo does a better job than most with supporting "non standard" configurations but its NOT as good as it used to be and I have to spend hours getting shit to build that used to slide through smooth (often with overlays).

Re:Hope!

[Synonymous Homonym]

We should also keep in mind that Linux itself, as a monolithic kernel, defies the concept.

It does not. Not only is the Linux kernel itself customizable at compile time to fit the needs of globally distributed supercomputers as well as wrist watches.
In Debian you have the choice between Linux kernels, a FreeBSD kernel, and the Hurd. (Unless your software requires systemd.)

Is it really so far out of line to define systemd's one job as interfacing with every service provider in the OS?

No, and if that was all systemd was doing, there wouldn't be a problem.

Re:Hope!

[BlackPignouf]

bcat /var/log/blablabla_log.bin | less
bcat /var/log/blablabla_log.bin | vim -
bcat /var/log/blablabla_log.bin | grep pattern
where bcat is an alias to whatever command you need to open systemd binary logs.
and with the appropriate plugin :
vim /var/log/blablabla_log.bin
just like you can do
vim /var/log/auth.log.2.gz

What's not *nix about it?

Re:Hope!

[Anonymous Coward]

Is it really so far out of line to define systemd's one job as interfacing with every service provider in the OS?

If all systemd did was be an init system, people would care a lot less.

The main gripe is that it's becoming a system logger, session manager, network manager, console, etc. Hopefully when they get around to adding the html parser people will say enough is enough and dump the garbage.

Re:Hope!

[X0563511]

I tried to get back into it.

I shortly drowned in USE flags.

There's too fucking many of them for them to be presented sensibly in an alphabetical list. They need some organization.

Re:Hope!

[X0563511]

Your real problem is that you don't have a homogenous environment. If everything you managed was rhel, you'd have a much easier time of it.

We have the same problem at work. Everyone is fine on the rhel boxes. But when the opensuse stuff comes around, good luck. When one of the solaris 10 machines acts up (we are stuck with that version for reasons outside of our control) there's only one other person than myself who has any kind of an idea.

Re:Hope!

[Anonymous Coward]

Fuck systemd, fuck pulseaudio, and fuck Pottering.

At least he put some kind of compatibility wrapper into pulseaudio (or allowed one to exist)

Re:Hope!

[Anonymous Coward]

And yet all the complaints ignore the fact that systemd is a diverse modular set of tools, and not a monolithic blop, that can work perfectly well with other tools (like the usual system log).

Consisting of a boatload of different programs which are all required to work with each other and may not be switched out is not modular; it is, in fact, nearly the very definition of monolithic as applied to software.

And that not much code actually runs in PID 1.

Define not that much? How much is too much if the design and implementation are deeply flawed?

And that the TC found in its favor.

Railroaded by Red Hat, as anyone who actually followed the process knows.

And that before systemd there was a default init system that everyone used as well.

Because everyone was able to agree that that one worked in the way it should.

I'm not qualified to judge the technical merits of the case...

And yet you do.

...but the people that are overwhelmingly came down in favor of systemd.

Comments attempting to support systemd always seem to trot out this little chestnut, despite the fact that there is no evidence whatsoever to support it. It's almost like there's a playbook somewhere telling you all what to say.

The criticisms on philosophical grounds were rebuted and the rebutals stand unopposed.

Rebuttal: You keep using that word. I do not think it means what you think it means.

Instead the same questionable objections are raised again and again....

Which in most sane groups would indicate that the objections are perhaps not so questionable. Nice editorializing, though.

Re:Hope!

[Barsteward]

so what happens when XxX breaks?? every bit of software has a chance of breaking..

Re:Hope!

[sjames]

I don't see why we can't get a better functioning OS that adheres to the Unix way. Step one is to not let systemd get itself wedged in place through dependencies. If that happens, there can be no progress. I see nothing in systemd that can't be done as well or better while respecting Unix. As for the inevitable "what are you waiting for", the answer is for the cgroups kernel API to stabilize (there are changes in the works) and to make sure it wouldn't be frozen out by a wedged in systemd.

Re:Hope!

[Barsteward]

i see yet another one redefining the dictionary definitions of modular and monolithic to suit their needs

Re:Hope!

[Hognoxious]

In my mind, this comes down to whether we want a better functioning OS

Better in what way?

IOW (I should assign a hotkey to this): "What problem with init scripts needs solving?"

Re:Hope!

[BellyJelly]

FYI the Funtoo flavour of Gentoo avoids systemd completely, even with the lastest Gnome 3.

Re:Hope!

[sjames]

The existance of the GR and how quickly it collected seconds puts the lie to your claim that systemd has 'overwhelming' support.

As for being a big blob, no, it isn't a monolithic binary, rather it is a hairball of dependencies welded on to a bit that can't be moved from PID 1 (even when containerized in a sandbox like docker).

The GR is all about not letting the hairball expand for any reason. No more making unrelated things like the window manager depend on systemd.That way, when a superior init comes along it will still be practical to drop it in.

Re:Hope!

[Anonymous Coward]

"vim /var/log/auth.log.2.gz"...

You call yourself a *nix user?

Re:Hope!

[geminidomino]

whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place

There's precious little evidence that systemd makes for "a better functioning OS" and plenty that the people behind systemd don't even understand how the OS functions -- and that's on a practical level, not a "OMG UNIX Philosophy is so 1980s" level.

Re:Hope!

[Anonymous Coward]

They both need lots of little trinkets to be happy.

Re:Hope!

[Peter H.S.]

Binary logs are anti-*nix. Rebut that.

That is of course wrong. If you have a POSIX compliant system, you have binary logs in /var/log. On Linux they are usually called "utmp" and "wtmp" and they keep track of logins and logoffs. You use the "last" tool to read these binary logfiles. utmpx is actually a formal part of Unix.

Re:Hope!

[Anonymous Coward]

so why add an extra layer of bits?

what if the filesystem gets corrupted? does that ever happen? what if 95% of the bytes on the disk were recoverable? if the log files are text based, you can still recover a lot of data. if the logs are binary, it is very likely you've lost all of your logs.

systemd is dumb, and so are all of you.

ROLL YOUR OWN.

Re:Hope!

[Cramer]

Then it's not "modular". It doesn't matter how many pieces the jigsaw puzzle has, it takes all of them to complete the picture. You cannot use systemd without it's BS journald, or logind, or udevd, or dbusd, and so forth. It's a fucking cancer invading everything.

Re:Hope!

[Peter H.S.]

Great, so what happens when journald breaks>?

It is trivially easy to read systemd journal logs on remote machines.
Also, there already exist several journal readers since the log format is defined and have an API. So it is easy to have many different log readers installed for the "belt and suspender" types.
Even rsyslog reads journal files these days.

Re:Hope!

[Anonymous Coward]

*My* mom is smart enough not to use it.

Re:Hope!

[Peter H.S.]

Only showing binary logs with systemd tools is a misfeature of the type "exposing the implementation". Userland requires a UI, and it's bad UI, and frankly bad Unix.

You don't have to use systemd tools to read systemd journal files. There already exist alternative readers, and systemd provides both a journal library and Python/Ruby/etc bindings for accessing the logs.

Now then, I hear you can somehow configure systemd to echo a copy of its logs to rsyslog. But, and maybe I'm just a fool with poor GoogleFu, but I tried for a couple hours to get this working and only found company for misery on the mailing lists.

If any systemd fans can point us to a quick-n-easy HOWTO on getting text [r]syslog working under systemd, then by all means shut a few of us up. Tell us how there's plenty of documentation too, we'll all hang our heads and wander away.

There are two ways of doing it: having rsyslog reading(and writing directly to the systemd journal:
http://www.rsyslog.com/doc/imj...
I think this is the default behavior these days with modern versions. More info here:

Else check :
"/etc/systemd/journald.conf"
And set:
"ForwardToSyslog=yes"

(only for syslog-ng or rsyslog versions that can't read the journal directly)

Re:Hope!

[rahvin112]

So you were running a distribution which is declared inherently unstable (the warning with Debian Testing) and not recommended for anything but testing and you're upset that it wasn't stable? And then you blamed it all on one piece of software?

Is this a joke? It's not April first so I must be missing the joke.

Re:Hope!

[The Technomancer]

I'm all for having systemd available as a choice, or even having a "desktop" spin that defaults to it. While I can't speak for everyone, I don't mind the concept of systemd, because there are use cases where the market has decided that they value speed over stability -- see mobile apps, desktops, etc.

I don't want it as the init system for my servers, though. Even if I think it's cool for the init system, I sure as hell don't want it handling login, messaging, logging, acting as a superserver, etc. My metal boxes reboot when a security patch requires it. The virtual instances boot the first time and never again. My log aggregator wants plaintext logs. I already have supervisord or monit keeping an eye on my daemon processes. Systemd could be $DEITY's gift to UNIX, and it still wouldn't go on an existing cluster of mine because any gains from it are offset in the engineer man-hours I'd have to pay out to thoroughly test all of the software I run against, convert all of our in-house tooling and software to it, etc.

Re:Hope!

[rahvin112]

As has been stated 1 Billion times already you still run syslog right on top and have all text readable logs.

Re:Hope!

[The Technomancer]

Why do I want the extra overhead of that? Yes, it's tiny. Tiny adds up at scale.

Re:Hope!

[JohnFen]

In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.

I don't think that systemd, on the whole, gives us a better functioning OS at all.

Re:Hope!

[TangoMargarine]

"X violates the fundamental spirit of Y but at least it lets you copy its data to Z to handle it the old way" is not a reason to implement X.

Re:Hope!

[gweihir]

Systemd is not modular in architecture and spirit. Stop propagating lies.

Re:Hope!

[metrix007]

I used to like Slackware until they lost their minds requiring a full install for what used to be a minimal system.

Re:Hope!

[BlackPignouf]

What's wrong about this command?

Re:Hope!

[Anonymous Coward]

There is nothing wrong about vim. Why do you ask ?

Re:Hope!

[Anonymous Coward]

Common user complaint: Debian stable is ancient.
Common debian answer: use testing, it's pretty stable and has software that's at most a few years old.

But then point out _any_ problem with testing, and this is the response you get.

Debian calling testing "testing" is like google calling products that have been in use for years "beta".

Re:Hope!

[lannocc]

Gentoo users will make a Debtoo

SystemD is merely a USE option in Gentoo, and (so far) has been easy to avoid. No fork necessary.

Re:Hope!

[rahvin112]

Don't look at me buddy. I take them at their word with that big warning that says this is unstable. Debian is old, that's the point, it's stable. Most of us appreciate that.

If you want a recent and "stable" version of Debian Testing use Ubuntu. But if you listed to some talking head on the internet that testing was just a more up to date Debian than that is your fault, because the warning is very plain, so stop bitching when it turns out it's not. Testing breaks all the time. You run testing you better keep your home on a separate partition so when they inevitably bork testing like they do quite frequently then you format / and reinstall while keeping your data safe in /home.

Blaming systemd when there are endless stories of people relying on testing and getting fucked over that can be found in a few seconds on Google is just plain stupid. It wasn't systemd that screwed up your Debian testing install, it was because it WAS testing. Yea it doesn't break everyday like Unstable but it still breaks and those breaks can be quite catastrophic. People that want stable systems run stable, even if it is ancient. Those that run stable but need a newer piece of software then use /etc/apt/preferences to add in select newer software packages from testing that they want/need. Those that run straight up testing 24/7 are asking for breakage.

Re:Hope!

[UnderCoverPenguin]

The Debian team is very conservative about what they are willing to call "stable". They are also very conservative about what they let in to "testing".

In my experience, Debian "testing" is very solid. I know several sys admins who choose Debian testing over anything not Debian. Sometimes they deploy Debian stable, but usually go with "testing" because it's enough closer to other distros to run most current versions of specific applications while still having fewer problems.

Personally, I think they could call what is currently "testing", "near stable".

Re:Hope!

[Anonymous Coward]

utmp.

Which is also a bad idea.

Personally, on Debian systems, I always go to /var/log/auth.log, and on RH-based ones to /var/log/secure (? IIRC).

Re:Hope!

[thegarbz]

The fundamental problem with Poettering's projects is they are released prematurely.
I honestly believe that in a year if you tried systemd again you'll have a different reaction to it. Probably still have complaints, but none that are related to bugs.

But really that has been my experience with Linux for a long time. A lot of projects (especially on cutting edge distributions like Ubuntu which roll with the latest) have been broken, feature incomplete, and full of showstopping bugs (I still can't believe how hard it is to plug a projector into a modern Linux system).

The real crime is that Debian, the bastile of stable and consistent distributions is switching to systemd. It's not ready for a distribution of Debian's calibre. It is for FedoraOS or Ubuntu, etc. That's the biggest problem. There's nothing fundamentally wrong with systemd (don't talk to me about the Unix way I believe it's crap), the only real problem is that EVERYONE is switching to it and it is not yet in my opinion stable enough for general consumption.

Re:Hope!

[Anonymous Coward]

so what happens when XxX breaks?? every bit of software has a chance of breaking..

Except that journald is not ACID and so corrupts in the even of a system crash. The developer's response? This is WONTFIX ("just rotate the log"):

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116

As a sysadmin, if I don't have decent logs, I can't debug things. Most of our logs are sent off-host Just In Case, but it's COMPLETELY FUCKING STUPID for a logging system to corrupt it's own log files.

Instead of using a well-know DB format (SQLite, BerkleyDB, OpenLDAP's LMDB), they rolled their own... and completely screwed the pooch.

If they couldn't get writing to a file right, why should I trust them with anything else?

Re:Hope!

[Anonymous Coward]

Is it really so far out of line to define systemd's one job as interfacing with every service provider in the OS?

If all systemd did was be an init system, people would care a lot less.

The main gripe is that it's becoming a system logger, session manager, network manager, console, etc. Hopefully when they get around to adding the html parser people will say enough is enough and dump the garbage.

They haven't integrated PulseAudio into it yet, much less the html parser and a graphics editor. Give them time.

Re:Hope!

[Anonymous Coward]

ForwardToSyslog=yes still stores to journald binary. This is not what we want. We want to have it stored to syslog ONLY.

Re:Hope!

[danomac]

- Don't be afraid of package.keywords, especially for very specific use flags.

Another long-time gentoo user here - the above file is used for mixing stable and unstable/testing packages. I'm sure the parent meant package.use.

Another thing to note is portage has a built-in way to deal with patches that happen outside of ebuilds, you simply create a directory specific to the package that needs patching and drop the patches in it, and portage will automatically use the patches. This is extremely handy for a system maintainer as you don't need to edit ebuilds.

Re:Hope!

[rahvin112]

Whether or not it has remarkable runs of stability Debian testing does have and will continue to have gotcha moments just like they've had in the past. I don't run testing on servers, I've run it on desktops where all the real data was safe in the home partition. But my point still stands, to have a gotcha in testing that was related to systemd and then blame systemd when you are using testing is silly.

That's the reason they have the warning about testing so that you understand that if you take the risk running testing you are taking the risk that one day your system might not be bootable. This is the reason they've talked about adding another repository that is closer to the Ubuntu LTS and Regular Ubuntu where LTS would be stable and a new repository between testing and stable could be added that would be more up to date. My understanding is that the idea was nixed because the amount of work was tremendous and beyond the number of volunteers that help run the system.

Re:Hope!

[tqk]

I can't believe people like you. Install a bare-bones Debian (no desktop, server, print manager, ...), then apt-get anything you want. You don't have to run Gnome n/KDE/??? or whatever comes stock installed. You can apt-get blah after the install making it the sweet, 133t box you want it to be, no cruft (well, perhaps I overstate ... :-) whatever!

Physician heal (or educate) yourself. FFS, grab an unused box and try a few installs in as many ways as you want. When the weekend's over, you'll know what you want for your precious snowflake box.

Re:Hope!

[Anrego]

Another long-time gentoo user here - the above file is used for mixing stable and unstable/testing packages. I'm sure the parent meant package.use.

Yikes! Yup.

Re:Hope!

[Anonymous Coward]

Hi,

From a fellow Gentoo user for more than a decade, this well written post conveys my thoughts and experiences well. systemd indeed just showed up on the radar, and slapped my in the face. I'm hoping that we'll be able to go for as long as possible without the virii that are systemd and Gnome. I'm perfectly happy with MATE.

Re:Hope!

[Anonymous Coward]

Start with no use flags, and a desktop profile, and add only the ones needed using package specific use flags in /etc/portage/package.use, or a tool like ufed.

Re:Hope!

[The Technomancer]

Tell you what. You go do that with RHEL/CentOS 7 or with the expected package set for Jessie, and tell me what you come back with.

In reality, if you think that process is any sort of worthwhile for large server installations, then you work for a small shop handling bullshit traffic or you're riding your coworker's coattails while you screw around with hobbyist installations -- and that's if you work as a server/infrastructure engineer at all.

Let's say that even works right now to give me a working box. I lead an infrastructure team, boss. My ass gets fired or my stock becomes worthless if I'm not working on a 5-10 year outlook plan. That might mean I'll have to go with a systemd-based distro, which means internal tooling and software chains need to retested, if not outright rewritten, much of the automation in place, along with additional monitoring on the new attack surface that systemd opens up.

The OS is supposed to the be base of this stack that's dumb as hell and a stable foundation for the software that does the actual work on top of it, and provides as few attack vectors as possible. The major distributions seem to be tossing away that role away, long with embedded systems, in favor or trying to beat iOS and Android on mobile and Windows and OSX on the desktop.

Noble goals, but that ain't what butters the bread, not what's kept Linux kicking for this long.

Re: Hope!

[Anonymous Coward]

Journald forwarding to syslog is a mess. To get all the info out, you need to use JSON as your message format. While syslog can forward or store it, it can't efficently process it. Worse, you can't put it back into a format journalctl can read, you lose all the query features. All you are left with is a huge file full of bloated JSON, filled with unhelpful systemd internal metadata.

Basically they've reinvented the Windows event system.

-john

Re:Hope!

[Boltronics]

When X breaks, you can look at the logs to figure out why it broke. When systemd/journald breaks, how do you look at the logs? It's a problem that journald with binary logging introduces unnecessarily.

Re:Hope!

[donaldm]

Binary logs are anti-*nix. Rebut that.

No problem, every heard of "wtmp" or " "utmp" which have been in Unix for over 30 years. How about the "sar" logs which also came from Unix (Solaris) but are available on pretty much all Unix/Linux platforms.

You could also look at AIX which maybe a big shock to you since many system administration logs and configuration files are binary. The thing is AIX is Unix but that is IBM's way of doing things. :)

Re:Hope!

[donaldm]

You originally wrote "vim /var/log/auth.log.2.gz"

"vim" can open a gzip'ed file but you will only see the "text based" result which is not really human readable. You would be better off using (you basically did say this BTW):

zcat /var/log/auth.log.2.gz" | less (or on some *nix systems "more")

Using a text based editor on any log file is not good practice since it is fairly easy to make a mistake which would effectively compromise that file. Also most vanilla Unix systems don't have "vim" installed although they do have "vi". Nitpicking maybe but basically every thing you said was valid.

Re:Hope!

[Anonymous Coward]

so what happens when XxX breaks?? every bit of software has a chance of breaking..

Meaning when you have additional bits of software required to complete the same end, you now have a greater chance of something in the entire chain breaking.

Therefore, remove the requirement of syslog as a binary-log translator. At least, make the logs non-binary; if not getting rid of the whole of systemd.

Re:Hope!

[jbolden]

They want you moving towards a PaaS type infrastructure. https://www.openshift.com/ https://www.heroku.com/ http://www.activestate.com/sta... ... So yes an entirely new stack but one that is already well tested and in use. The entire concept of how you do internal tooling should be changing.

Re:Hope!

[Anonymous Coward]

What about Funtoo? I was thinking about moving back to Gentoo, but then I learned that Funtoo is not even bothering with systemd whatsoever. Seems like less of a headache. Just gotta back up what I need on the laptop.

Re:Hope!

[The Technomancer]

I've not had good experiences with Heroku.

Beyond that, if I want PaaS functionality, I've got Docker and/or Elastic Beanstalk for the simpler applications. PaaS is fine if you're running a simple app backend or a medium-traffic frontend. But a data warehouse isn't going there. Log analysis isn't happening there, as much as I'd ike to outsource that, but the expense is ridiculous, My time series metrics and monitoring isn't going there. Sensitive PII isn't going up there.

Those options (sans Heroku) are great if you're trying to get a proof-of-concept off the ground, or you've got high enough margins going that you can eat the pain when the cost of outsourcing so much of your infrastructure catches up with you. Thise "good problems to have" aren't so good to have as people think.

Re:Hope!

[jbolden]

if I want PaaS functionality, I've got Docker and/or Elastic Beanstalk for the simpler applications

And those Docker containers have to be running inside an infastructure.

But a data warehouse isn't going there.

Why not? Data warehouse seems perfect of a PaaS. I've got ETLs running constantly and I'd like to break them clean of my computational nodes. I have queries that are hitting or not hitting various tables so I want to associate and disassociate CPU from.... Seems like an excellent application of PaaS. And BTW both Oracle, IBM and EnterpriseDB (Postgres) agree with me on this.

Log analysis isn't happening there, as much as I'd ike to outsource that, but the expense is ridiculous,

Log analysis has always been one of the core applications of big data systems. Of course that's happening there. They are way way ahead of traditional infrastructure.

Those options (sans Heroku) are great if you're trying to get a proof-of-concept off the ground, or you've got high enough margins going that you can eat the pain when the cost of outsourcing so much of your infrastructure catches up with you. Thise "good problems to have" aren't so good to have as people think.

Large in-house systems should also be running PaaS. I don't agree with you on the outsourcing infrastructure question but even if you were right that's irrelevant to whether you in-sourced infrastructure should be a PaaS.

Re: Hope!

[Anonymous Coward]

GNU is not unix.

Done.

Re:Hope!

[tqk]

You go do that with RHEL/CentOS 7 or with the expected package set for Jessie, and tell me what you come back with.

No thank you. I don't do RH (or Centos, or SLS, or its freres), for a reason. I'm a Debian guy. However, my friends do, and they have no problems with them.

I lean toward Slackware (and OpenBSD), but Debian's *better* (or my way). Meh. You go your way, I'll go mine. They all work, and much better than the comercial alternatives.

Re:Hope!

[BlackPignouf]

Thanks for the explanation.
At least on my systems (LMDE, Ubuntu server and Mac OS X), vim automagically opens archives, lets you browse the structure inside the gz file, lets you read the compressed files and even save the modified files.
If it doesn't, you can add this to your vimrc :
http://vimdoc.sourceforge.net/...

Re:Hope!

[AntiSol]

It sounds more to me like he was running a distribution which had a track record of being fairly stable despite being declared inherently unstable, and that one particular piece of software broke things fairly substantially for him on more than one occasion, so he decided to avoid that piece of software, even if it meant changing distros.

Seems sensible enough to me.

Re:Hope!

[Anonymous Coward]

Binary logs are anti-*nix. Rebut that.

Pssst, I'll tell you a secret: a text file is made of bytes, like binary ones.

Run "strings" instead of "cat" on the journal file. "grep" for "MESSAGE". "sed" to adjust to your liking if needed. Done.

Text only logs are much more limited because you can not simply log a pure text multiline message.

Re:Hope!

[Anonymous Coward]

Binary logs are anti-*nix. Rebut that.

"Linux != Unix" ~ Linux Torvalds

Rebut that (butthead)

Re: Hope!

[t_hunger]

Why journald?

Because systemd logs stuff that is not accessible to syslog and thus needs an interface to buffer (e.g. before syslog is up) and forward that information to syslog.

That system grew up to handle most of the things syslog also does. So syslog was made optional, so that small systems have one less service that they need to run.

Send like a sensible decision to me.

Re: Hope!

[t_hunger]

That is indeed not posible: systems logs stuff that is not accessible to syslog (e.g. stdout and stderr of all processes run by systemd, output geerated before/after syslogd is up, etc.) and needs journald as some kind of internal interface to pass all that information on.

Re: Hope!

[Anonymous Coward]

The systems guys did not get themselves stopped by unstable APIs, instead they help to improve them. Just saying.

Re: Hope!

[t_hunger]

What does systemd make worse?

I can e.g. restrict services far more effectively since I switched my machines to systemd. I really appreciate that. I also find the socket activation really convenient and am really happy to be rid of that horrible crontab syntax. Networkd works like a charm and debugging became so much easier since the log output is finally complete.

So far I have yet to find anything I miss from sysv unit.

Re: Hope!

[Anonymous Coward]

Sure it is. We wrote a logging library that when syslog is not avail, it keeps the messages in a queue, a text based, RFC 5424 (syslog) formatted, and once syslog is up, the messages are delivered to syslog and the queue enteries are removed.

It's simple, fast, reliable, and you can read the queue messages if you want/need.

Re:Hope!

[ziggyzaggy]

funny I also have those logins and logoffs in simple text logs

Re:Hope!

[ziggyzaggy]

Not all programs use utmp logging so not the most useful thing. Text logs with the login info are. Nice try though, but I think you just pointed out problem with binary db vs. text for /var/log files

Re: Hope!

[sjames]

That's because one of their team is the one monkeying with the API. Just saying

Re:Hope!

[CRCulver]

I used to like Slackware until they lost their minds requiring a full install for what used to be a minimal system.

I'm a longtime Debian user, but upset at the whole systemd thing, I installed Slackware on a spare computer I had to see how that distro was. During the Slackware install process, I was given the ability to either install everything, or choose which packages I wanted. I did the latter, and installed only a bare minimum of packages. I don't know why you think it's all or nothing.

Re:Hope!

[See Attached]

Great point... everyone feels slighted by the belevolant dicatator thats very self assured. Its really a philosophical change marketed as a technological update. From the Wiki page: The name systemd adheres to the Unix convention of making daemons easier to distinguish by having the letter d as the last letter of the filename. Thats about as far as it adheres to any Unix Convention. This is where we all leap over the beast, pick out the good bits and revisit how the objectives are met. in the long run, this may be a very healthy thing for the Open Source movement, in that we all get to decide where it goes, right?

Re:Hope!

[Anonymous Coward]

i see yet another one relying only on the dictionary definitions of modular and monolithic to suit their needs.

Re:Hope!

[Anonymous Coward]

What a stupid rant about small self contained micro this and that running /on Linux/ - a monolithic kernel if there ever was one. And no sense of irony. No sense at all, really.

Re:Hope!

[walterbyrd]

Until recently, when RHEL 7 was released, RHEL was running a five year old kernel.

Actually, I am using CentOS 6.5 right now. I have CentOS 7 installed on another desktop, but 6.5 with the way old 2.6 kernel just works much better. Gnome2 and init.d work just fine - why change them?

Why get in such a wad about an old system? What do you actually need your system to do?

Re:Hope!

[Anonymous Coward]

Look at the journald.conf man file: http://www.freedesktop.org/software/systemd/man/journald.conf.html.

Set ForwardToSyslog=true in /etc/systemd/journald.conf under the [Journal] section. Make sure you have a syslog daemon running. Done.

Re:Hope!

[metrix007]

I was an exclusive slack user for about 8 years.

At some point they started trying to compete with Ubuntu and the like, and many packages had weird dependencies which to get around you had to install the dependency or recompile. An example would be mplayer now requiring samba.

The community is also far less willing to offer support if you didn't do a full install.

Re:Hope!

[danomac]

Yes, there are a lot of USE flags, but this is part of the extreme flexibility gentoo's package management offers. I have tried to use other distros several times but I always wind up returning to gentoo for the package management flexibility. Remember heartbleed? All I had to do was toggle a USE flag to disable the tls heartbeat and recompile openssl immediately. It was patched eventually, of course, and it could be reenabled again. However, as far as I know, other distros had no easy way to do this, unless you had source tools and did things outside of the package management system for the distro.

There are a lot of USE flags that are shared between lots of packages and this can be enabled globally if need be (thinking of things like printing support, hardware video acceleration, etc.) There are ways to deal with USE flags.

1. First, get the base system running (no gui, just get it so you can login to a shell.)
2. Set a profile (use `eselect profile list` to show them, and `eselect profile set x to set one.)
3. Use `emerge --info` to set what flags are used.
4. Use `emerge -pnuDN world` to see which packages will be compiled. USE flags triggering the change will be highlighted.
5. If you're wondering what a specific USE flag is doing with a package, use `equery uses <package>` to check. equery is in the gentoolkit package.

If you need changes it is better to set USE flags for individual packages as someone else posted.

Yes, this takes a while to set up but once it's done you will know what you need and it can be noted somewhere.

Re:Hope!

[Anonymous Coward]

I am running systemd since testing introduced it. I haven't had a single problem. Actually it works much better than anything before. Especially writing your own startup script is so much easier than before. Not only that, but built it monitoring and automatic restart.

Where is this hate for systemd coming from? Wake up, you can't work with this utterly oldschool 1970 startup style forever.

Re:Hope!

[rdnetto]

I know you've probably written off gentoo at this point, here's a completely random bit of usage advice:

- Set use flags as you need them, even if this means re-installing the same thing multiple times. This avoids big important packages being pulled in as mere dependencies (though you can add them to the world list afterwards) and more importantly lets you set up and configure everything one at a time and makes it more likely that you'll notice error messages.
- Don't be afraid of package.keywords, especially for very specific use flags.
- Avoid gnome if possible. I don't know wtf it is with gnome, but it seems to be the poster child for weird and hard to diagnose issues as well as crazy dependency trees.
- Pay attention to what virtual packages are doing. Usually they are in your best interest, but not always.
- Don't bother using ebuilds for web apps

I started using a Gentoo derivative (Sabayon*) about a year ago, and it's an absolute pleasure to work with. (Particularly how colourful the package manager is compared to Debian.) In addition to the above, I suggest the following:
-Keep package.use, etc. and make.conf under version control. (This is really helpful in case you accidentally break something.)
-Use git instead of rsync for the portage tree - it's much faster, especially when the total no. of changes is small. (This is doubly true if you have multiple Gentoo installs.)

* Sabayon has systemd as the default, but it's easy enough to change back to OpenRC and being able to use binary packages saves a lot of time.

Re:Hope!

[badkarmadayaccount]

Ugly syntax, race conditions, lack of cross distro portability, too many fork()s, binding of the implementation identifier of a service to the interface identifier.

Re:Hope!

[badkarmadayaccount]

AIX.

Re:Hope!

[Anonymous Coward]

Thats perfectly understandable and I agree with that use case, even if it isn't something I want.

Your probably looking for a Redhat based distro than. Centos/Fedora et al.

Debian is/was the poster child for the "10 different packages that does the same thing, choose the one you like" paradigm.

Remove It

[Anonymous Coward]

Debian is by far the most stable of the Linux distros. systemd does not lend itself to this stability. Nothing wrong with the old init system. We all know it and its quirlks. I fell in love with UNIX because of editable text config files. Every aspect of the system needs to be editable by an admin. Linux is losing morally to OpenBSD because OpenBSD does not allow binary blobs in the system. Ever. Debian should be the same. No binary blobs of any kind. If it's not text, it doesn't belong.

Re:Remove It

[Anonymous Coward]

What does binary blobs have to do with systemd?

Re:Remove It

[Anonymous Coward]

More systemd FUD. The journal files are in a binary format (but optional from the standpoint of logging, you can forward to standard syslog with one config line). The rest of the files in systemd are editable text files. I had a friend of mine regurgitate this FUD to me the other day. I had to sit him down and show him you could edit the files.

Re:Remove It

[Anonymous Coward]

systemd using binary logging, not text. Everything is a UNIX-like system was designed to be text based. binary format makes log files corruptible. systemd is huge. It has too many hooks into too much userland stuff. This should never be. The old way, while nowhere near perfect was better. Better what you know... systemd is not really progress. It's complicated and huge. Binary for logfiles is a no-no for old-school UNIX guys like me. systemd violates the tenets of the UNIX philosophy in many ways, not the least of which is the aforementioned binary logfiles. No. Just no.

Re:Remove It

[Anonymous Coward]

I'm a Linux noob, but Wikipedia says systemd's logfile is binary. I know one of the big complaints has been that it doesn't use plain text files the way Unix systems traditionally have.

Re:Remove It

[rubycodez]

Not FUD, if something wrong you'll never get to the part where you forward to syslog. Logs should be simple text files, that can be read even without the OS. ASCII text is viewable on just about anything

Re:Remove It

[Barsteward]

yes but it can be exported as text so you can view it the existing ways

Re:Remove It

[Anonymous Coward]

Systemd represents the ongoing Redhatification of Gnu/Linux. Wonder why all those stupid complex looking projects come from Red Hat ? Although they cannot claim ownership of Linux, they can make it so that most Linux components are guided by Red Hat. Which is the next best thing as far as they're concerned. As for Linux users ? Who the fuck cares about them.

Re:Remove It

[Anonymous Coward]

If you want text logs, you can easily do that by ... *gasp*... editing a text file.

Re:Remove It

[blane.bramble]

How exactly are binary logs more secure? Either they are in a documented, useful format, or they are proprietary ("secure") and useless.

Re:Remove It

[MightyMartian]

Binary logs are also far more secure, but I guess that doesn't matter to you.

That has to be most bizarre justification I've yet read. How exactly is a binary log more secure?

*nix systems have had permissions systems for the better part of half a century. If you don't want someone looking at a file, don't give them permissions, but if they do have permissions, the mere fact that a file is binary isn't an obstacle save to the technically illiterate (who wouldn't likely be looking at a log file anyways).

Re:Remove It

[MightyMartian]

What if I want a straight text log file that requires no other tools? Why would anyone even have a binary log on a *nix system?

If you want binary log files that require tools to dump them to text, use Windows.

Re:Remove It

[Anonymous Coward]

Binary logs are also far more secure, but I guess that doesn't matter to you.

Oh horseshit, what you speak of is security by obscurity. By the same token you could say gzipped logs are more secure than non-compressed logs. When reading a binary format is well understood it's not an increase in security it's merely pig-headed obfuscation for the sake of itself, a sentence that describes the intentions and outcome of the entire systemd project perfectly.

Re:Remove It

[Anonymous Coward]

You missed the point completely. It's not about others viewing the logs, it's about an intruder altering the logs to cover up their activities.

Re:Remove It

[MightyMartian]

And how exactly would a binary log be any more secure even in that regard? You can have binary streams in stdio as well.

Re:Remove It

[Anonymous Coward]

I'm aware of this. The old system is still better.

Re:Remove It

[Barsteward]

I'm sure some elder statesman of the Unix world would ask "Why would you ever want a GUI on a UNIX system? " Things change and move on and not to everyone's satisfaction. As the majority of users are probably desktop/laptop users, they wouldn't care a jot if the files are binary or ascii. Anyway I think the export of binary to ascii is a text file config option if you want both at the same time and it can also be done via a specific tool.

Re:Remove It

[rubycodez]

if your system is hacked and they rewrite the binary database logs of systemd, how are you to know?

Re:Remove It

[Anonymous Coward]

Nothing more true has been written here today on this subject. It is embrace and extend. Full stop. It's the same reason Red Hat wanted a "closer relationship" with CentOS. Control.

I've been a *nix admin for a long time, and I have seen the embrace and extend from MS and other companies. Like a lot of people, the BSDs are looking good about now. They are not perfect, but they will never have systemd shoved down their throats. systemd has its hooks in so much userland stuff it's poison. Not playing fairly with other libraries, etc. It's bloated, it's huge.

Re:Remove It

[gnupun]

What if I want a straight text log file that requires no other tools? Why would anyone even have a binary log on a *nix system?

What if you want to filter or search the log? Binary logs would be much easier to deal with in that case instead of having to write a text parser to process the text file.

Re:Remove It

[osu-neko]

What if I want a straight text log file that requires no other tools?

Then you write your systemd log in text format. If you can't figure out how to do that, you're not qualified to be reading the log file output.

Why would anyone even have a binary log on a *nix system?

It takes less space, especially if you're archiving them for long periods, causes less I/O in general and less disk fragmentation over time as you compress and delete them every day/week. Note that indeed, you do the same on most classic BSD or SysV init systems by compressing the old logs, requiring you to use a tool to dump them to text if you want to read them later... but that's not as efficient.

If you want binary log files that require tools to dump them to text, use Windows.

Do you turn off the compression of logs on your boxes, or do you admit that having to use a tool to read them isn't so big a deal when you aren't grasping at straws to justify why you hate a particular piece of software?

Re:Remove It

[Anonymous Coward]

So you think the hash or checksum of a binary file will change if you edit it but not of a text file and the subsequently re-compressed archive? Yeah, I'm the idiot.

Re:Remove It

[Bobakitoo]

if your system is hacked and they rewrite your ascii log files to hide their hack , how are you to know?

Because a proprietary stream of byte is so much more difficult to 'hack' compared to a stream of utf8 bytes.

Re:Remove It

[Anonymous Coward]

What? Is this a troll?

Re:Remove It

[Anonymous Coward]

I think in your rush to tell people they've missed the point completely, you've missed it yourself.

If you're reliant on trusting the logs of a system that you think might have been compromised you're already shafted. If an intruder can edit your plain text logs then they can edit everything else on the system as well, including binary ones; hacking is generally more sophisticated than vim /var/log/daemon.log dd dd dd :wq. There's nothing inherently unhackable about binary logs and if your box is rooted your only real option is to burn the hard drives to the ground and reinstall.

"Just add some hashes! Then the hash won't match and the log will reveal itself as being tampered with" comes the chorus. Nope. If you've already got the ability to rewrite the logs then recalculating the hashes so they match the massaged data is trivial.

The only remotely secure way to record logs is to write them off to a seperate log server (firewalled off, no remote access, managed by a completely different team, barbed wire, attack dogs, Slim Whitman, yadda yadda) the second they're generated - although by all means keep a local copy if you feel like it.

Windows has the whole binary logging thing, and goes to great pains to make them as hard to access as possible (which of course makes viewing them a pain as well). But anyone with admin access can clear the logs or delete whatever entries they like with winzapper or a few lines of code. Windows in secure environments uses... wait for it... a remote log server.

Long and the short of it is binary logs don't get you any extra security and, especially in the nix world where there are many and varied tools for examining plaintext logs, constitute a colossal loss of readability.

Disclaimer: I work in computer forensics. Most hacks are done by people who haven't even thought of covering their tracks and you'll have nice local log entries that tally up with those on the remote server that scream out "Look, here's me hacking teh gibson!". Advanced hacks are almost impossible to spot without a) a good IDS b) examining the discs offline.

Re:Remove It

[blue9steel]

Wait, what? I don't have to write a text parser there are tons of well known tools already in existence. Binary != Improvement

Re:Remove It

[Anonymous Coward]

Ooh, what are we boycotting today?

Re:Remove It

[Anonymous Coward]

A GUI enhances usability for end users who have not memorized all the commands and their arguments. A binary log file enhances usability for... who, exactly? Must be other programs, because end users can't do squat with them directly.

Re:Remove It

[Anonymous Coward]

Seems to me the major arguments against binary logs are exactly that text is easier to manipulate.

Re:Remove It

[TheCarp]

> Disclaimer: I work in computer forensics. Most hacks are done by people who haven't even thought of covering
> their tracks and you'll have nice local log entries that tally up with those on the remote server that scream out
> "Look, here's me hacking teh gibson!". Advanced hacks are almost impossible to spot without a) a good IDS b)
> examining the discs offline.

I have only had the "pleasure" of dealing with a few actual incidents. A couple of times on personal systems (apparently "Spykidz 0wn3d" me) a couple of times at work. I think the most memorable for me was when we found someone had installed an IRC bouncer on a production mail server using a password they likely sniffed as some professor insisted on using telnet (we did, eventually, get to close that down).

I got the job of spending a day figuring out what they were up to, so I setup a sniffer (two actually because it was a braindead system and I needed one for each direction) and I spied on the...well.... kids.

The most memorable part of the whole exchange between them was about how "I might be offline for a while because my dad is talking about cancelling comcast"

Re:Remove It

[jedidiah]

> I'm sure some elder statesman of the Unix world would ask "Why would you ever want a GUI on a UNIX system? "

This would be the "green screen" myth that certain trolls like to fixate on so much.

The truth is that GUIs were commonplace on Unix workstations long before they were widely adopted on DOS kludge clones. However, this fact does not mean that this feature has to be force fed to everyone all the time.

The key feature of a Unix GUI is that it is HIGHLY OPTIONAL. It also does not sabotage anything else. It doesn't require abandoning the Unix design philosophy. A GUI is not fundementally incompatible with the rest of Unix.

If you want an all-singing-all-dancing-crap-of-the-world style logfile, leave the originals alone and create a new set of tools that build on top of what's already there and leave what's there alone.

There's no need to sabotage other people's stuff.

Re:Remove It

[Kardos]

Proprietary? You're ill informed. The code that writes those files is part of systemd. Anyone with a computer can grab a copy and rewrite them.

Re:Remove It

[Anonymous Coward]

What self-indulgent tripe. Logs are meant to be easy to work with while you need them the most, and rotated and archived when you probably won't. I shouldn't have to suffer extra work just because someone isn't doing their job right and thusly has performance problems on their logging partitions. I shouldn't have to concern myself with a fundamental change to my OS just because a few people want to overthink things and disrupt things for a solution that isn't even superior in any meaningful way.

Re:Remove It

[Lord Apathy]

Oh horse shit! Binary logs are the biggest crock of shit to blow out someones ass since Windows ME. Pure text log files can be parsed with the same system tools that come with all linux distributions. I'm talking grep, awk, and sed. An you really adventurous, perl.

All the excuses that I've seen for keeping this foul system are bullshit!

Re:Remove It

[swilly]

I don't know about journald, but on Solaris the binary logging works using digital signatures. Each log message (and the prior log messages signature) is signed to ensure that the log message hasn't been tampered with, and that log messages haven't been removed. In the event of tampering, the log messages can still be read, but are flagged as untrustworthy. I understand that administrators prefer text messages (which is why our Solaris systems also logged to syslog), but for security auditors digitally signed binary logs are a godsend.

Re:Remove It

[Lord Apathy]

Exactly. Text log files allow you to pull them off the damaged system and examine them on another system. Many times the system that you have to examine them on won't be a linux system. The other day I had to examine a log file that my co worker sent to me on my phone.

If it had been a binary log file, I would have had to get off the toilet, get dress, and find a compatible system to decode the log files on. Maybe even spin up a VM to do it in.

I was able to tell her the boot params to boot up the box with out leaving my seat. Fuck binary log files.

Re:Remove It

[RavenLrD20k]

On my servers, the current business week is in plain text and not compressed and archived until 11pm Sunday night for the next week. I keep a month's worth of archived logs. Now here's why: If a system goes down for some reason, the only logs that are going to have anything immediately useful are going to be the uncompressed ones that can easily be cat dumped or vi'd for initial troubleshooting. You're most likely going to need only the last few lines of the log just to find out what went wrong. If troubleshooting is greater than that and you find a longer history of problems that culminated in the panic, any liveCD distro will have the tools necessary to crack open your archives.

Binary log systems are a Disaster Recovery nightmare. The only reason you have a log system is that something went wrong and you need to do some form of troubleshooting/recovery. If your core system is still working fine and the native systemd is able to read the binary, great. What happens when a system partition crashes and won't boot back up? Please enlighten me on how a binary log file can be read on a system that won't boot itself? Can any liveCD using a systemd based distro read the binary file and translate it to a human readable format? Also, it's been said that using a config file, the journal system of systemd can write to a plaintext file. Please explain how that works? Using the config file, does the journal system completely turn off and each component individually writes to syslog, generating their own log file or adding to one of the already created pertinent log files, as it does with System V? Or, does each program send it's message to the journal system and it's this system that sends a message to syslog to write? If it's this latter case, what happens if during a system panic the journal system corrupts the data being written? What if the journal system itself craps out in a failure?

These are all questions that I legitimately do not have an answer to yet, and I haven't had time to research into it. Before I consider updating my systems to a systemd based distribution these questions MUST be answered satisfactorily, and it will be as I draw closer to that point that I will be making time to research it. I don't have time for FUD, fanboyisms, or anything else as such from either side. I have specific requirements that must be completely answered. If the answers are not forthcoming, I, and many many many sysadmins like me, will be keeping System V init systems on my servers by whatever means necessary.

Re:Remove It

[Barsteward]

its going to be a darn sight more difficult to insert into a binary file, maybe less to append to it.

Re:Remove It

[Barsteward]

yes, so export the binary file to text files.. not difficult

Re:Remove It

[Barsteward]

this might help. the binary log files are subject to Forward Secure Sealing - http://lwn.net/Articles/512895...

Re:Remove It

[Barsteward]

have a read of this. http://lwn.net/Articles/512895...

Re:Remove It

[devman]

You can use a journalctl (see the --root or --file options) from a rescue disk or simply lift the logs and move them to another system. I'm not sure why people think that binary logs can only be read by the system that generated them.

Re:Remove It

[MMC Monster]

I was under the impression that the binary log entries each had to sign itself and all previous log entries?

So if someone were to alter the log they'd have to alter the signatures of everything downstream in the log, which is presumably easier to figure out?

Or am I mistaken?

Re:Remove It

[Anonymous Coward]

... you don't have to. That's the point of having log files in text.

Re:Remove It

[Anonymous Coward]

Binary logs less space ?

Dude! On my Fedora 20 the binary log turns out to be over 100mb in one week. While within the same timeperiod It only gets 10mb text only. The binary log is much much bigger because of the internal structure.

Re:Remove It

[Lord Apathy]

yes, so export the binary file to text files.. not difficult

A completely unnecessary step.

An one that might be impossible if the server has promptly stuck its thumb up its ass and won't boot. Then add that you are a junior system admin that doesnt' know how to do that. But you know enough to boot the system with a rescue disk so you can mount the drive and then ftp the log files some place where you can mail them to your boss at 2 am. Who might just reach through the network and strangle you because you took down his porn server anyway.

Not everything speaks binary log files, but just about everything speaks ascii. Log files are in ascii on purpose. So you can read them with the minimal tools and not have to fight the system to get to them.

Just because you can do something, doesn't mean you should. That applies to binary log files.

Re:Remove It

[mrchaotica]

Exported by what? For all you know, I might be trying to look for the damn things using strings on the raw block device!

Re:Remove It

[thaylin]

So I have to have special tools to read something which could have been read universally previously. You dont see an issue by that?

Re:Remove It

[Cramer]

With binary blobs, it's less "rewrite" and more "corrupt". As anyone who's used InnoDB will attest, it doesn't take many flipped bits to turn a blob into a pile of garbage. And the most common action of hackers is a) delete the log files, or b) write over them.

People who are paranoid about this sort of thing, use syslog forwarding to a machine that cannot be remotely accessed. (the age-old "rx-only" ethernet cable.)

Re:Remove It

[Cramer]

Nope. TEXT is trivial for a human to process, even heavily damaged text files can make sense to a person trying to read them. Reading "binary" is like trying to read gzip; very difficult for a human to do without using the program to decode it.

Re:Remove It

[Anonymous Coward]

Well, there's an analog joke in that bathroom story somewhere...

Re:Remove It

[Cramer]

Have you ever had a system compromised? Hackers don't give a single f*** about altering log files, they just destroy them and keep on truckin'.

Re:Remove It

[MightyMartian]

You can encrypt text files as well.

Re:Remove It

[Cramer]

Right, a file generated by the computer cannot be altered/regenerated by that same computer? Bull. The signing information is somewhere on the system (in the logging process's memory at minimum), so an enterprising hacker can steal it and start making a mess of the logs.

The people who are serious about logging security and integrity do not trust the system that generated the message(s). They are, instead, streamed to other systems making it very difficult to "rollback the universe" -- once the message is sent, there's no recalling it.

Re:Remove It

[Peter H.S.]

I'm a Linux noob, but Wikipedia says systemd's logfile is binary. I know one of the big complaints has been that it doesn't use plain text files the way Unix systems traditionally have.

If you are new to Linux, the systemd bianry logfiles are great; they are much easier to deal with than learning and memorizing a lot of "grep" switches.". Not that you can't use all the standard Linux text tools with the systemd logfiles, but you don't _have_ to.

Since the systemd journal has a stable API to accessing log file information, it is now actually possible to make a GUI log viewer that works properly.

I was skeptical about binary log files too, until I actually tried systemd properly and read up upon how systemd's journal functions. I am totally converted now, and will never go back to simple text log-files. Systemd's log implementation is simply so much better.

Re:Remove It

[gweihir]

Indeed, well said. Now, I have no problem with systemd being there as an alternate init system for the fanbois that confuse "new" and "good". But it has no business being the default. And if the embrace-and-extend move being tried by the systemd-team with udev is not countered soon, they will get way to much power. True, it will require work, but Gentoo has laid a foundation with eudev, and that should be kept a viable alternative.

Re:Remove It

[Peter H.S.]

What if I want a straight text log file that requires no other tools? Why would anyone even have a binary log on a *nix system?

If you want binary log files that require tools to dump them to text, use Windows.

I want systemd's binary logfiles because they are so much better than old style text log files. Having rich meta data with every log entry is simply too good a thing to have. Small things like monotonic time stamps are really handy, the ability to filter messages based on field values is simply awesome.

systemd's journal is really cool stuff. Don't be prejudiced against it and try it out in earnest.

Re:Remove It

[gweihir]

There is also the little problem that in an enterprise environment, log-file analysis is not done on the system that produced it and often not even done on the same OS. Binary log-files are an extreme expression of ignorance about the purpose of log-files. They are not just a bunch of startup-messages that can be ignored as long as things work.

Re:Remove It

[JohnFen]

You can have your tamper-resistant logs right now, without systemd.

Re:Remove It

[JohnFen]

Indeed. Which is why I hate Red Hat with a burning fire of a thousand suns. I stopped using Red Hat for my own systems many years ago, and I am greatly irritated that its influence is so hard to avoid.

Re:Remove It

[Anonymous Coward]

Binary logs are far more secure? So you can't, say, base64 encode a signature and stick it onto each line?

Besides which, what use are binary logs if you can't tell the difference between a corrupt log and an incursion?

Re:Remove It

[TangoMargarine]

grep

Re:Remove It

[Anonymous Coward]

Because by default the systemd logs are cryptographically sealed.

Re:Remove It

[rahvin112]

Yes text log files are very handy, and just like with SysV you can run syslog on top of systemd just like you did before when you ran syslog on top of SysV. Amazing isn't it!

Re:Remove It

[Peter H.S.]

It is trivial to read systemd journal files from a boot media. They can also just be copied to a USB stick or whatever and moved to another system for analyzing.

Every log entry line has rich meta-data, including machine name, UUID etc, so you will never be in doubt on which machine the log was generated on

You can forward journald messages directly to syslog-ng just by adding a line to /etc/systemd/journal.conf

rsyslog can now natively read (and write) systemd journal files, and make the usual text logs if that is what you want (or use forwarding). http://www.rsyslog.com/doc/imj...

the journald daemon listen to /dev/log where all log messages from all programs are directed to, and the journald then forward these messages to another syslog. It will strip them of meta data first.
Since the journald can get log messages from early boot before even the root filesystem is mounted, this is actually an enhancement of just using syslog.

The journald journal is primarily an append based system, so it is quite resistant to file corruption. The journald files are basically text files with another line delimiter and an index. journald has integrated logfile-verification and can therefore discover if something is wrong (it will then log-rotate etc).

Re:Remove It

[Lord Apathy]

Yes text log files are very handy, and just like with SysV you can run syslog on top of systemd just like you did before when you ran syslog on top of SysV. Amazing isn't it!

Then your wasting even more space by keeping both binary and ascii logfiles on the same system. One of the key reasons that someone put forth to have them in the first place. Binary logfiles are smaller than ascii. Which is a case I'm not really sure of any way. But now you have both the binary AND the ascii files now thus completely negating one reason to have them in the first place.

I want even bother to talk about having two systems in place anyway. Just skip the whole thing and do away with the one that nobody really wants in the first place.

Re:Remove It

[Anonymous Coward]

So why haven't you sent that to the computer forensics guy so you can tell him he's wrong and knows nothing?

Re:Remove It

[Peter H.S.]

Binary logs are also far more secure, but I guess that doesn't matter to you.

That has to be most bizarre justification I've yet read. How exactly is a binary log more secure?

The systemd logs have better security in a number of ways; there is "Forward Secure Sealing" (FFS) that allows for cryptographically ensured verification, even if root is compromised on the host. It also have a integrated logfile verification, much less strong, but "free" and default.

Also, journald have kernel guarantees that log entries are made by the exact binary/program the log entry claims. On syslog, any program can claim anything in the text log file. Of course, the kernel guarantee is only truly secure with FFS turned on, but it is an improvement never the less; on a syslog system, the hacker only have to alter a text file. On a systemd machine, he has to have exploit booth root and journald, and then alter the logfiles in such a way that the internal log verification still works. Not trivial at all.

Re:Remove It

[Anonymous Coward]

The binary format supports cryptoghraphic signing in intervals. You can be more sure no-one hampered with the files.

Re:Remove It

[Peter H.S.]

If you're reliant on trusting the logs of a system that you think might have been compromised you're already shafted. If an intruder can edit your plain text logs then they can edit everything else on the system as well, including binary ones; hacking is generally more sophisticated than vim /var/log/daemon.log dd dd dd :wq. There's nothing inherently unhackable about binary logs and if your box is rooted your only real option is to burn the hard drives to the ground and reinstall.

That simply isn't true. If a hacker gets access to gpg encrypted mails, he can't read or alter them undetected if he doesn't have the key. Same with systemd journal logs with "Forward secure sealing". This isn't hash'es but strong crypto security like gpg. The concept is quite old in the crypto world:
Here is an introduction to FSS:
http://lwn.net/Articles/512895...

Re:Remove It

[Peter H.S.]

Binary logs are also far more secure, but I guess that doesn't matter to you.

Oh horseshit, what you speak of is security by obscurity. By the same token you could say gzipped logs are more secure than non-compressed logs. When reading a binary format is well understood it's not an increase in security it's merely pig-headed obfuscation for the sake of itself, a sentence that describes the intentions and outcome of the entire systemd project perfectly.

You seems to misunderstand how the signed logs works in systemd: the logs are perfectly readable by anyone with the right permissions. There is no encryption going on, only secure signing. (striclty speaking it isn't signing, or hash' chaining)

There is no signing key on the computer that can be extracted. The key is only used once to sign the first log segment, then removed from the system, the next signing key is generated on the basis of the first and so on. systemd makes cryptographically secure sealing called "Forward secure sealing". The concept is old in the crypto world, here is an introduction to how it is done:
http://lwn.net/Articles/512895...

Re:Remove It

[rahvin112]

I've never heard the space argument for binary logging. The reasons I have heard and that are listed on numerous websites are worth the couple megabytes they occupy. It's an utterly silly reason to be opposed to systemd, because you run syslog on top of sysv now, running it on top of systemd isn't functionally any different from a user perspective. That a binary logging file exists has no impact on the system other than providing the numerous benefits they can convey.

Re:Remove It

[Anonymous Coward]

If you think binary logs are useful then you never used linux in a professional setting.
When you have to reach for an emergency shell as fast as you can to boot a server ASAP, you don't want to deal with binary logs that need special treatment, you want to use grep and a pager over any log you want to peek into to fix whatever is wrong.

Re:Remove It

[Anonymous Coward]

What if you're locked out of the original system and all you have is an emergency shell with common unix utilities?

Re:Remove It

[jbolden]

If this is a big deal you can have systemd write an additional plaintext log. Binary only is an option.

Of course it is an issue. All sorts of things in life have some negatives and some positives, you weigh them accept the negatives of your choice and move on. In this case you get better seeking and indexing.

Re:Remove It

[Zontar The Mindless]

... there are tons of well known tools already in existence. Binary != Improvement

Such as... any text editor that features the cutting-edge technologies known as "search" and "regexps"?

Wow! No... really?

Re:Remove It

[Barsteward]

can the system encrypt the log files are they are written or is it done afterwards?

Re:Remove It

[Barsteward]

I know, i've used the horrible things in the long distant past. I also remember the days that anyone using a GUI was trashed. A GUI is only optional if you don't need to use GUI programs. X is an outdated mess that has a lot of the same "complaints" that the anti-systemd posters moan about (do one thing etc etc) but X gets defended instead of trashed.

Its a distro's choice of whatever it wants to include in its distribution, no-one is forcing you to use it so its not sabotaging anyone elses stuff. systemd can be uninstalled and any init system used, its just a choice you have to make.

Re:Remove It

[Barsteward]

why is it an issue, its just another tool to use. Do you complain about just how many editors are there? is more than one editor needed? you can create yourself a little alias or script (bash, bourne, zsh, etc etc) that extracts the text files and continue as normal or you can just configure it to suit your needs. heres a link on how to set up systemd to log as text https://fitzcarraldoblog.wordp...

Re:Remove It

[Barsteward]

here's how to do it https://fitzcarraldoblog.wordp...

Re:Remove It

[Barsteward]

well, don't configure it for binary logging then https://fitzcarraldoblog.wordp...

Re:Remove It

[RabidReindeer]

yes, so export the binary file to text files.. not difficult

It is if the logged system won't boot any more.

The NEXT step in opacity beyond binary files is to do something like embed them in an all-in-one database a la the Windows Registry. Ever tried to restore a single application AND its runtime settings and context on a Windows system when the app kept all the goodies in the Registry?

Do that, and even exporting the binary to another binary-compatible system for conversion (if one is handy) is going to be frustrating. As it is, conversion to text already adds a step which may be ill-appreciated when you're operating in a panic environment.

I worked with binary log files in OS/2. I don't want to do that again.

Re:Remove It

[soliter]

Tamper resistance binary log is a nice feature to have. As the linked article said, the algorithm for FSS is based on "Forward Secure Pseudo Random Generators" (FSPRG), which comes from some post-doctoral research by Poettering's brother Bertram Poettering. Is there any explanation on why the algorithm is based on FSPRG? At the time the article is written (August 2012), the paper on FSPRG has not been published. I'm worried about the crypto aspect here.

Re:Remove It

[AntiSol]

Having rich meta data with every log entry is simply too good a thing to have. Small things like monotonic time stamps are really handy, the ability to filter messages based on field values is simply awesome.

So why don't you set syslog up to log everything to a database? It's had that ability since forever. The data files written by the DB engine will even be binary, just like you want. You'll be able to save very rich metadata and do all kinds of interesting things. For example, use the rich SQL language to do complex queries and joins - much more than simple filters you love in systemd. If you like binary logs, you'll *love* database logs!

Database engines are designed to handle massive amounts of data efficiently, so you can keep your entire log history all in one huge binary blob and query away at it to your heart's content - none of this 'only 3 months worth of logs' crap. Pretty much any modern database engine will handle a table with millions of rows no sweat - way more than you're likely to need for a logging system unless you're just being gratuitious.

Database engines also come with other nice features such as data consistency guarantees (this is a big one) and user access control and support for clustering, replication, and load balancing (if you're e.g pumping out a lot of log entries or need security, reliability, or redundancy). Hell, you could use triggers to make things happen when certain things are logged. You can do really cool stuff.

And if you have mysql installed you probably won't even need to install any new software. You definitely wouldn't need to go near the init system. Or mess with compatibility or reliability. Or force a bunch of dependencies down anybody's throat. And I could still use sane, simple tools like grep to look at the logfiles on my desktop system, and you could use your huge binary enterprizey system running on oracle databases, and neither would need to impact on the other, and we could all live in peace and harmony.

It's pretty cool what we already have. All you need to do is read the docs and configure things to do what you want.

Re:Remove It

[Anonymous Coward]

Systemd represents the ongoing Redhatification of Gnu/Linux. Wonder why all those stupid complex looking projects come from Red Hat ? Although they cannot claim ownership of Linux, they can make it so that most Linux components are guided by Red Hat. Which is the next best thing as far as they're concerned. As for Linux users ? Who the fuck cares about them.

Then, if you were a dd, you'd be voting in favour of this GR, the same one that failed for Ian previously. He worked for Canonical then - and voted for upstart. Now he works for Citrix, and has reproposed the same GR on the basis that he lost the last one because of industry conspiracy. Logic is not your strong point is it?

Re: Remove It

[t_hunger]

Yeap, the indexing in the journald files does increase the file size. That does speed up searches though, so it does have its advantage.

But systemd also logs a lot more than syslog ever could. This includes a lot of meta data (e.g. systems unit that started a process, cryptographic hash) for each entry as well as more entries (e.g. stdout and stderr from all daemons).

Re:Remove It

[Peter H.S.]

Sure, systemd's journal with its advanced and rich meta data works very well with database logging, much better than the old legacy style syslog text dumps. This is hardly surprising.

But database logging is also much more complex which is why it is only used on large setups with syslog, and the systemd's journal is designed with simplicity as a primary design goal, so it works with all the standard Linux text tools like grep, tee, less, etc.

Systemd's journal can be used as a drop in replacement for syslog with total backwards compatibility, including in-house made watch scripts, or it can be used as a next generation syslog with a stable API for generating watch scripts (finally!), and providing rich meta data like monotonic timestamps.

I don't know how you got the idea that grep etc. doesn't work with the journal?
"journalctl -b -p err | grep -i ata | tee sata-errorlog.txt" works brilliantly: show all log entries from this boot that have error log level "error", grep it for "ata" and tee the result into a textfile. Think of "journalctl" as the most powerful log filter tool you have ever seen. It works perfectly with the standard Linux tools.

Anyway, you can still use rsyslog or whatever together with systemd. You even gain the benefits of early boot logs (journald can log from before the root filesystem is even mounted while living in initramfs). I did too in the beginning, but removed it when I got to know systemd better. Forget about what other people say about systemd's binary logs, and try them yourself; it is really good stuff.

Re:Remove It

[Peter H.S.]

It is pretty common to "vet" academic papers before publishing, so that other people can give a qualified input etc. So it is hardly surprising that Lennart had "early access" to the paper. As I understand it, then "Forward security" is a pretty old crypto concept. What Marson and Poettering did was tweaking the concept to log files which represents special problems to more static texts like emails, and use the concept for sealing, not encryption. The concept seems sound and have been formally peer reviewed.

Here is the paper in case you haven't read it:
https://eprint.iacr.org/2013/3...

Re:Remove It

[Anonymous Coward]

You can't have strong crypto on a system that is compromised to the level where an attacker can edit the logs. If the system has the crypto keys then *gasp* so does the attacker! Even full disk encryption doesn't protect against a system that is compromised while running (OTOH FDE is good protection against offline log editing). FSS has it's place, mainly when shipping log streams you can make sure that they weren't edited on the remote side by verifying the chain and checking that the final signature matches. This doesn't require binary logging and could be duplicated with a periodic plain text mark. Don't get me wrong, there are cases where binary logging makes sense, I just don't think that direct system logs are one of them.

Re:Remove It

[Anonymous Coward]

So if the attacker has access to the logs they can just change the signatures starting from the first omit/add whatever logs they want and no one will know. Easy to do offline, online attack would require patching the new signature into the memory of the running logging process (harder but not actually that hard).

Re:Remove It

[marcello_dl]

In a way, Red Hat cares about linux users. You see, when linux users have a distro working perfectly out of the box, RH's business model crumbles.

A systemd based, never fully defined, never fully complete Linux, is what RH Canonical and hardware makers need to do the desktop linux transition. Devs who jump on the train will do like devs on win and osx, always work to adapt the new versions to the changes and fuck the old versions and its users.

New users are even more fucked up because they might look up howtos on the web that have worked for more than a decade, until systemd and similar projects obsoleted them for no compelling reason.

Re:Remove It

[Anonymous Coward]

Proprietary to systemd. Proprietary do not mean it is closed, it only mean it is not standard. UTF8 is a standard encoding. Any simple text editor can decode and display them. Even terminal emulator can decode them. That mean you can cat, tail or grep them directly on screen.

Re:Remove It

[Anonymous Coward]

From the link:

"One key is the "sealing key" which is kept on the system, and the other is the "verification key" which should be securely stored elsewhere"

What GP said is correct. The security in this comes from having two computers, one of which is not compromised. It has nothing to do with wether or not the log is binary. So why not just send a cryptographic hash for every 10 minutes of text log to the secure computer and compare with that? In fact, why not just send the whole log to the other computer? Then the attacker couldn't modify the logs at all. I don't see why knowing that the logs were tampered with would help. Presumably you wanted to look at the logs for a reason. Not to mention all regular old syslogs already support remote logging.

The whole thing just seems like an annoying anti-feature invented by someone who doesn't quite understand what he's doing.

Re:Remove It

[Anonymous Coward]

It is far easier for the attacker to just corrupt the binary log files. And by design, the systemd will then just ignore/backup/overwrite the corrupt files and the poor admin will not have any clue if the corruption is due to bug in systemd or if there was some abnormal activity in system. It is just insane, how the systemd has implemented the bad sides of a binary log file and not the good ones, eg. the transactions and atomic modifications used in any database.

Please Debian

[Anonymous Coward]

I've been a Debian user for 14 years now, please do the right thing and get rid of systemD.

I've been trying systemD on another machine for about a month now, it's not terrible but it's not all it's cracked up to be either.

The part that I don't like (besides it going against the unix philosophy) is how fast it's taking over before the majority of the Linux community even had a chance to have their say. And what really gets me is, if systemd was just an init system, fine. But at the rate they are going there is going to be a systemd everything.

Re:Please Debian

[BlackPignouf]

And what really gets me is, if systemd was just an init system, fine. But at the rate they are going there is going to be a systemd everything.

I hope you're not using Emacs ;)

Re:Please Debian

[Anonymous Coward]

Oh,come on. Nobody uses Emacs.

Re:Please Debian

[gweihir]

I think it is ultimately designed as a kernel-wrapper, because the huge-ego developers would actually like to do the kernel, but some sane people are not willing to let them. So they go for the next best thing: A bloated monster that every Linux installation ultimately must have running.

Re:Please Debian

[kthreadd]

The part that I don't like (besides it going against the unix philosophy) is how fast it's taking over before the majority of the Linux community even had a chance to have their say. And what really gets me is, if systemd was just an init system, fine. But at the rate they are going there is going to be a systemd everything.

Distributions are free to choose whichever init system they want to support. A lot of them choose systemd because it is better than everything that came before it. As simple as that. There is no big conspiracy going on. It's better, that's why it's used. Get over it.

Re:Please Debian

[thaylin]

And you have no evidence of that.. there are some better things in it, but there are many WAY worse things in it.. This is an embrace, extend, extinguish maneuver.

Re:Please Debian

[Warbothong]

Emacs doesn't hog PID 1, so it can co-exist with alternatives. Running Emacs doesn't stop Vi from working. Running w3m-el doesn't stop Firefox working. Running shell-mode doesn't stop xterm working. Running eshell doesn't stop bash working. Running doc-view doesn't stop mupdf working.

Gnome doesn't drag in Emacs as a dependency.

Re:Please Debian

[Anonymous Coward]

But at the rate they are going there is going to be a systemd everything.

What makes you think that?

Re:Please Debian

[kthreadd]

If systemd really was a bad thing then distributions would not choose it. It's amazing that people think that distributions are dictated which init system to use.

Good to hear

[CRCulver]

I was really unhappy with Debian's move to systemd, and the fact that once systemd is running as one's init system through a general upgrade, one cannot even go back to sysvinit..

Having heard that Slackware was resistant to systemd, I installed the latest version of Slackware on a netbook I have lying around, and while it's a fine project that clearly has its fans, it seems to require a lot of retraining for someone coming from Debian. I'd love to be able to stay on the venerable old Linux distro I have so many years of experience in.

Re:Good to hear

[petermgreen]

I've taken two debian jessie systems successfully from systemd to sysvinit without running into the problems the author of that bug mentions.

There is probablly a valid issue underlying that bug but one should always be aware when reading bugs that they are often not as general as their author's make out.

Re:Good to hear

[Anonymous Coward]

you were a debian admin not a linux admin...

Re:Good to hear

[myowntrueself]

I was really unhappy with Debian's move to systemd, and the fact that once systemd is running as one's init system through a general upgrade, one cannot even go back to sysvinit..

Having heard that Slackware was resistant to systemd, I installed the latest version of Slackware on a netbook I have lying around, and while it's a fine project that clearly has its fans, it seems to require a lot of retraining for someone coming from Debian. I'd love to be able to stay on the venerable old Linux distro I have so many years of experience in.

I predict that use of systemd will result in too many 'release critical' bugs, and that future releases will be delayed very badly because of this.

Re:Good to hear

[CRCulver]

Get off your high horse. Slackware's init system intentionally follows a BSD model, not the model of nearly all other Linux systems. One can have vast experience with an array of Linux distros and still have to do some retraining when confronted with Slackware.

Re:Good to hear

[Anonymous Coward]

Having heard that Slackware was resistant to systemd, I installed the latest version of Slackware on a netbook I have lying around, and while it's a fine project that clearly has its fans, it seems to require a lot of retraining for someone coming from Debian. I'd love to be able to stay on the venerable old Linux distro I have so many years of experience in.

If you know Slackware, you know Linux. By its very nature, Slackware demands a better understanding of the operating system as a whole than does any other distribution. So by coming from Debian you are having to learn how to do a little bit more with your system. I went from Fedora to Slackware and though the learning curve is steep I learned a lot about my system and about just wanting my OS to work.

With that said I now use Linux Mint which uses systemd and I havent seen any noticeable defects in my PC. This PC is used for development, graphic work, plus my kid does his homeschooling on it which consist of video chat, watching videos, listening to audio and doing a lot of word processing. So I have yet to see the negative effects of systemd.

Re:Good to hear

[Cramer]

Other than the issue of no one maintaining the sysvinit shell scripts, and at some point in the very near future, the sysvinit package(s) being removed entirely??? (and that's not even counting the growing number of projects infected with the systemd cancer that are going to require significant parts of systemd be installed in the first place.)

Hopefully, this "re-think" will reverse the first two, and start to quell the later.

Re:Good to hear

[Anonymous Coward]

I'd love to be able to stay on the venerable old Linux distro I have so many years of experience in.

This is what it comes down to for me, too. I can't be arsed spending the time re-learning a system that might end up with that pile of crap SystemD in it, and may end up going OSX... and I really don't what to do that.

Completely wrong

[Anonymous Coward]

The summary is completely wrong. They are not discussing systemd, just whether packages can depend on a specific init system. I thought there was some kind of moderation here?

Re:Completely wrong

[NotInHere]

+1 Informative. That Systemd is default isn't criticised by the mail. They only want to "preserve the freedom of our users now to select an init system of their choice, and the project's freedom to select a different init system in the future.".

Re:Completely wrong

[Anonymous Coward]

A key point is the systemd approach to things seems to directly contradict this goal. It's seems almost by design to be getting hooks into as much as it possibly can to make removal very difficult. It's the lamprey eel of init systems.

In a world where GIMP, a graphics editing tool, has a dependency on a specific init system, it's hard not to discuss whether this was a good idea in the first place when discussing the replacability of that init system.

I'm hoping this is the path these discussions go down. Continuing to support systemd is going to lead to a two tiered Linux where not using systemd excludes you from a tonne of software, and this is about as anti-Linux as you can get.

Re:Completely wrong

[Barsteward]

you need to speak to the developers that changed their programs to use the systemd hooks and get them to make it optional so then you can install and run any other init system and they won't be dependent on systemd.

Re:Completely wrong

[Zeromous]

THe problem is this has been top down dictated. The correct way would have been to offer both, and let developers develop for BOTH. Not systemd primacy. Beg for secondary.

Re:Completely wrong

[Barsteward]

I don;t see why they can't develop both, this is open source after all.

Re:Completely wrong

[sjames]

The problem isn't that the Gimp developers took any steps to depend on systemd, that tendril is creeping up on them from underneath.

Re:Completely wrong

[JohnFen]

The summary is completely wrong. They are not discussing systemd, just whether packages can depend on a specific init system. I thought there was some kind of moderation here?

Yes, and this is really the key point. That there are packages that depend on systemd is the root problem -- it means that it's very difficult to use an init system other than systemd. If I could just select my preferred init system like I can select my preferred DE, then I wouldn't have an issue over systemd at all, since I could just avoid it entirely.

Re:Completely wrong

[inhuman_4]

systemd isn't sinking it's hooks in to anything. It is exposing kernel functionality, and adding additional functionality that developers want to use. That is why things are becoming dependant on it.

There is no secret cabal of systemd people sneaking in hard dependencies in Gnome3 or GIMP. It's just regular developers taking advantage of functionality provided by someone else.

Re:Completely wrong

[Anonymous Coward]

If I have got to have systemd to run some software then I, for one, will abandon that software!!!

Too Late

[Anonymous Coward]

Already switched to OpenBSD. Everyone else jump on the *BSD bandwagon, to the desktop in the next 10 years!

Re:Too Late

[MightyMartian]

Getting to the point. A couple of KVM hosts may have to stay Debian for a while, but my other servers will be migrated very soon unless Debian removes systemd dependencies.

Not again...

[torsmo]

Keeping a tab on these changes is becoming tiresome, init?

Re:Not again...

[Anonymous Coward]

There's no change here, if you read the actual email instead of the completely false summary.

Re:Not again...

[torsmo]

There is a joke in here, though, if you don't miss it. tab...init...inittab?? Ok, well, I tried.

make it option for aunt minnie

[rubycodez]

I could see why a desktop user might want to have such a thing as systemd (not me though), or someone with no admin skills having a canned all-in-one solution for their little business or hobby website.

But for where Linux dominates, server and embedded systems, I don't believe it fits into the Unix way of doing things and makes admin harder.

Completely wrong

[Anonymous Coward]

Score: -1 Reasonable

Re:Quit fucking with systemD

[goarilla]

Yes, your kernel is broken. I can hardlock it using the swap file in a weird way you shouldn't even allow in the first place.

Are you talking about FreeBSD ? I was able to crash it with a swapfile by writing to the swapfile after
swapoff but while it was still a memory disk.

Re:Quit fucking with systemD

[Anonymous Coward]

There you go: https://bugzilla.kernel.org/

One of the worst points about systemd

[NotInHere]

is for me that it isn't interoperable. Please correct me when I'm wrong, but AFAIK systemd never did anything to create standards their new functionality is compatible with. Instead they only support linux APIs. I recognize that their needs exceed POSIX, but their current approach "lets make everything a hard dependency" is -to be polite- hacky. It doesn't have to be an official ISO standard, a simple document that ensures exchangeability of components inside systemd, and perhaps even makes systemd cross-platform.

Re:One of the worst points about systemd

[Anonymous Coward]

This is one of my major gripes as well. I think if we're going to start rewriting/updating software to the spec of a better init system, it needs to be a universal specification that many (perhaps systemd-like, perhaps not) alternative init systems of the future can adhere to, include those on other *BSDs and *nixes and operating systems we haven't even dreamed of yet.

I really dread a future in which, due to current Linux dominance and all distros going systemd, all of the major software packages start depending on systemd's APIs and behaviors, and then the software packages become very hard to port sideways or forwards to other platforms. Don't get me wrong, I love Linux. However, what I love more is the idea and culture behind Linux and all *nix/*BSD. I want there to be alternatives, and I want there to be future upstarts that disrupt Linux and give us something even better.

The reason the culture of all of this was so disrupt-able in the first place, leading to all the greatness we have today, is because we had *standards*, and new implementations could adhere to those standards and all the other software could quickly be ported over to them.

Aside from technological gripes about how systemd operates and/or is implemented, the key failing of systemd is failing to specify a standard for authors of everyday runtime software and daemons, so that those other authors can conform to that standard, and then the *BSDs and whoever else in the world can implement that newer, better standard independently of systemd.

Systemd is like an anti-standard. They seem to have never even *thought* about it from a standards perspective. They think only in a functional perspective, and the only function that seems to matter to them is "Today's current iteration of Desktop Linux systems". Arguably even within that limited realm systemd has standards issues. They make incompatible changes from release to release and hardly even mention them in their changelogs, much less provide backwards compatibility or a path for sane future feature changes.

Re:One of the worst points about systemd

[Anonymous Coward]

Systemd is like an anti-standard. They seem to have never even *thought* about it from a standards perspective.

Well, I think they have, actually. If you were a large corporation selling an operating system which you don't write, and you wanted to take as much control of that system as you could, breaking its standards compatibility to the maximum extent possible while making as much of it as possible dependent on projects that you started and control would be a really good start.

Re:One of the worst points about systemd

[Peter H.S.]

is for me that it isn't interoperable. Please correct me when I'm wrong, but AFAIK systemd never did anything to create standards their new functionality is compatible with. Instead they only support linux APIs. I recognize that their needs exceed POSIX, but their current approach "lets make everything a hard dependency" is -to be polite- hacky. It doesn't have to be an official ISO standard, a simple document that ensures exchangeability of components inside systemd, and perhaps even makes systemd cross-platform.

The systemd developer have explained, and explained why they did what they did; they have made stable interfaces;
http://www.freedesktop.org/wik...

They have explained what interfaces that can easily be made on non-systemd distros or even other OS's:
http://www.freedesktop.org/wik...

There are systemd libraries and what not, and lots of documentation.

That systemd is a Linux only thing, is because it uses kernel features that are only available to Linux like cgroups, "namespaces" and "kernel capabilities" and soon, kdbus. If eg. Hurd or OpenBSD or Mac OSX implemented such features, systemd could be ported. Of course, *BSD would never allow LGPL licensed software to become a critical part of their core OS, so the point is rather moot though.

Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

Re:One of the worst points about systemd

[laffer1]

> Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

No, what we want is for systemd to not be forced on us as a way to destroy any chance of running a graphical environment in the future. Wayland compositors, GNOME and various other things are starting to require systemd. That is why everyone is upset. Linux users may also not like systemd and that is another issue.

The forced nature of systemd means that every linux distro must switch and that *BSD people may have to fork X or wayland (if it takes off) in the future in order to have a damn GUI.

Re:One of the worst points about systemd

[Peter H.S.]

> Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

No, what we want is for systemd to not be forced on us as a way to destroy any chance of running a graphical environment in the future. Wayland compositors, GNOME and various other things are starting to require systemd. That is why everyone is upset. Linux users may also not like systemd and that is another issue.

The forced nature of systemd means that every linux distro must switch and that *BSD people may have to fork X or wayland (if it takes off) in the future in order to have a damn GUI.

There is nothing forced anywhere. The problem the non-systemd crowd is facing is they have no developers and no development taking place. Upstream projects like Gnome and KDE uses systemd features because they are necessary for having a modern DE, and because nothing else provide such features.

Gnome developers have said for years that people would have to either maintain ConsoleKit or make something similar so Gnome could function on non-systemd distros. But no one is listening and no one is developing an alternative, so Gnome is left to use systemd-logind that is maintained, take bug fixes and have good features, or try to support ConsoleKit (they still do in Gnome 3.14 despite what people claim on systemd hate blogs). But as said; ConsoleKit isn't maintained, so Gnome can't have urgent CK bugs fixed.
Same with Wayland. The non-systemd crowd simply aren't helping upstream projects to make them still support non-systemd distros.

This Debian proposal is exactly about this; if this GR succeed, the non-systemd Debian crowd can _force_ developers to work on features that SysVinit needs. It is simply impossible to gather the necessary developer talent for doing so without such force.

Re:One of the worst points about systemd

[Anonymous Coward]

So your point is that the status quo cannot be maintained and is "forced" rather than the new paradigm. That makes no sense. ConsoleKit worked. sysv init worked. Systemd developers are trying to change things and they don't care about non linux environments which adopt their system. You have your thinking backwards.

GNOME developers who choose to only support systemd are downgrading their system to only support a subset of linux systems. It's a choice. It's not on us to make this work.

Re:One of the worst points about systemd

[Peter H.S.]

Yes, you are correct. Status quo can't be maintained without development. ConsoleKit worked, and if it was maintained it could still be a working solution, but it has been deprecated for years now.

That is the problem in a nutshell; the non-systemd distros have the sole responsibility for maintaining and developing the necessary code for making a non-systemd distro run.

Oh, and stop getting your "information" about systemd from the tin foil hat systemd hate-blogs, they are so filled of misinformation it is laughable. Gnome, including the lates Gnome 3.14 still supports ConsoleKit: http://blogs.gnome.org/ovitter...

They are not happy about developing against dead software that can't be bugfixed though, and they have said so for years. But the systemd-opponents don't care at all about that, they don't care about helping upstream projects support their ever dwindling numbers of distros, all they seemingly wants to do, is ranting all day long about how bad systemd is.
All rant and no code.

Re:One of the worst points about systemd

[ChunderDownunder]

Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

When I use gimp, pidgin, geany etc on a Windows desktop, it's because they consistently work well with a thin Gtk+ shim over Win32. That's without installing a Linux compatibility layer like cygwin.

If in future one has to install some cygwin-systemd abomination just to run Gimp, then free software will have lost a fan.

Re:One of the worst points about systemd

[jbolden]

An easy boot BSD sounds like a good idea. I think over the next 15 year or so BSD is eventually going to have to create their own systemd emulator (which is going to be a high privilege process capable of manipulating daemons i.e. effectively a new init) or just add those Linux kernel features to their kernel and use actual systemd. Systemd of course also introduces a license problem in addition to technical problems, an emulator is going to get ever more difficult as systemd incorporates PaaS features.

This is the problem with legacy software. There is a window of time where crossover is supported and once that window starts to close crossing over quickly gets more and more complex. We are just slightly after the crossover point.

Re: One of the worst points about systemd

[t_hunger]

So the proposal is an attempt to force volunteers to do something they do not care doing by themselves? That sounds like a solid plan and will surly result in well working support for non-systemd unit systems.

What could possibly go wrong with that plan?

Re:One of the worst points about systemd

[Peter H.S.]

Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

When I use gimp, pidgin, geany etc on a Windows desktop, it's because they consistently work well with a thin Gtk+ shim over Win32. That's without installing a Linux compatibility layer like cygwin.

If in future one has to install some cygwin-systemd abomination just to run Gimp, then free software will have lost a fan.

The problem is that nobody really develops for non-systemd distros anymore. Sure, a loud minority is constantly attacking systemd, but they don't bother with developing crucial software needed to run non-systemd distros, nor do they help upstream projects to support them either.

The reason why upstream projects depend on systemd, is because systemd provides essential low level stuff that nothing else really provides on Linux.
There will probably be no problem with running Gimp etc. on Windows (or OSX) simply because those OS's have the necessary low level stuff to keep modern software running, so the projects can just use that instead of systemd.

Re:One of the worst points about systemd

[Anonymous Coward]

This is not about systemd but about the shit which is dependend on it like GNOME. The Gnome devs in their wisdom decided to fuck their users and force them to use systemd.

I think that Theo de Ratt dont care what init linux uses. Maybe he cares and get pissed off when some project he supported shows him the finger.

Re:One of the worst points about systemd

[Anonymous Coward]

Or maybe BSD has simply fallen woefully behind, and we don't all want to wait for BSD to catch up before we start using features Linux offers today.

More concerns after the TC decision: Read more!

[Anonymous Coward]

The decision took place in feburary. Now we have close to year-change and new features has been swallowed into systemd. People on the debian mailing list are worried that they have once talked about systemd as as init replacement. The current state of systemd is that it swallows a lot of other features into it's throath making it an uncontrollable mess.

Re:More concerns after the TC decision: Read more!

[Anonymous Coward]

Yes, init process is about launching other processes at various run levels. And from what I've read on the matter, systemd's selling point is to ensure a certain daemon is not launched unless its dependencies are already loaded. So NFSd won't be launched if there's no networking and that seems like a good idea.

But then why does systemd want to take over the logging system, something that is unrelated to the init process? That's feature creep... Anyway, I wish there was more discussion of the pros and cons of systemd on slashdot threads instead of endless name-calling.

Re:More concerns after the TC decision: Read more!

[Anonymous Coward]

There is even more.

systemd console soon to be in
systemd networking soon to be in ....

Re:Quit fucking with systemD

[Khyber]

No, I'm talking about Linux. Tried making an encrypted RAMDisk. DEAD KERNEL. Memory fills up, kernel hard lock, the end of system until reboot.

Finally

[hrvach]

Thank God there is still some sense in people behind Debian.

Re:Finally

[Anonymous Coward]

Not that many.
Only one guy who was on the TC (Ian Jackson)
And about 10 or so old Debian Devs are still around.

The rest of them are silent, have left, have been kicked out (weren't nice to women), or are new and just in it so they can put it on their resume (compiling packages is a whole lot easier than actually programming, and you get to claim you're a dev).

Plus abunch of feminist women that don't do anything but are "debian devs"

Re:Whining luddites

[Anonymous Coward]

This is the same kind of attitude that had gnome and windows losing users in droves.

"We are right, our users are wrong, lets just ignore them and keep going!"

There are enough of us luddites that see systemd as a major step backwards in what makes Linux what it is that if they don't pacify us, they might have an exodus on their hands.

Re: Whining luddites

[Anonymous Coward]

If systemd is the future remains to be seen. It might go the way of upstart if someone writes jet an other init system that doesn't have developers that upset so many users.
Personaly I'll be waiting as long as I can before I'll move my servers. Not because I dislike systemd, but it is has just a to big and to complex code base to use right a way.
I do wish I could deinstall a lot of the junk it depends on.

Question

[Anonymous Coward]

I use linux for personal but rarely any x server or GUI. i always have ssh open in my mac. i'm just wondering about all the systemd haters - if init does need to be replaced or improved why hasn't that happened? Why is it that there is 1 solution to a problem and they hate it but no one else can link to another project or effort or no other solutions? does init need fixing? replacement?

if systemd will ruin the linux ecosystem where is the project that will save it?

i dunno

Re: Question

[kthreadd]

This happens every time something happens. Some people always hate everything.

Re: Question

[Anonymous Coward]

Only when the new something is bad. Nobody hated on Gnome 1 because it quickly became obviously better than stuff like FVWM that it was replacing and KDE was simply out of bounds because it had the Qt cooties. (Since fixed of course by Qt becoming GPL.) Lots of hating on Gnome2 but guess what? The H8ers were -right- and the Gnomes relented and restored the lost functionality. Hint, when your 'new and improved' version consists mostly of removing things you are probably doing it wrong. Gnome 3 can't even BE fixed by reverting, only by abandoning that fork and rolling back to Mate.

Microsoft made exactly the same mistake, seeing the iPad, getting Tablet Madness and making the desktop into a big tablet. Users rejected both in no uncertain terms. Difference is Microsoft is listening to their customers and reversing course, slowly and painfully it might be in happening but it is happening. Gnome does not care. Of course it is also true that Microsoft probably had to sack their CEO to make the change, who would have to go to fix GNOME?

Re:Whining luddites

[Anonymous Coward]

Just because something exists doesn't mean everything and everyone must change to it, using your own logic, LINUX would be a micro kernel, LLVM would be the default compiler, their would be only one solution for anything (because everything else is obsolete). and the LINUX eco systems would not exist, it would be one binary blob, the installers wouldn't even give you a choice of anything, it would just say "Installing LINUX" of and there would be no distros either, because they would be all obsolete as well.

Freedom of choice (which is why GNU/LINUX exists in the first place) would be no more.

Not all change is bad, but when that change removes choice, then there is a problem. No package in all of the LINUX/UNIX eco-system is as bad as systemd.
Xorg can be replace with XFree86, LINUX with BSD, Desktop with anything. Only systemd is removing choice. That is the problem, and I am not saying remove systemd, just don't use it as the ONLY init system. I don't even think it should be the default, once it's installed it's very hard to remove without breaking the system. It should be the users choice to run systemd, it shouldn't be rammed down the users throats.

OpenRC

[Anonymous Coward]

Seriously, why not OpenRC?

It solves all the deficiencies with classic init, but at the same time it doesn't have the interoperability problems and un-Unix-like feel of systemd.

Re:OpenRC

[Zeromous]

Why not indeed!

Re:OpenRC

[Anonymous Coward]

As a gentoo user, I agree with this sentiment. It was discussed, but as a kind of "or if we really wanted to, we could use OpenRC or something" alternative. It was never really a serious contender, and I never understood why.

Re:OpenRC

[Rich0]

As a gentoo user, I agree with this sentiment. It was discussed, but as a kind of "or if we really wanted to, we could use OpenRC or something" alternative. It was never really a serious contender, and I never understood why.

I believe the concern is that it isn't as event-driven. It also tends to go against the prevailing winds. I'm sure OpenRC will be supported for a long time, but a lot of Gentoo devs are moving away from it (though many are also sticking with it). Actually, my biggest concern is that neither is going to end up being well-supported on Gentoo as a result, but that is going to impact the OpenRC users harder since they can't just steal their scripts/units from other distros like SystemD users can.

Re:OpenRC

[Anonymous Coward]

Because pottering didn't write it, that's why.

Re:OpenRC

[kthreadd]

Because a lot of software depend on Systemd, and it's quite handy to use the stuff that software depends on when you want to put it in your distribution.

Re:OpenRC

[kthreadd]

Lennart does not decide what init system distributions choose to use. Distributions choose systemd because it is better than all that came before it.

Re:OpenRC

[thaylin]

way to fanboi.. It could not be any reason, such as hooks from other dependencies forcing them right?

Oh, nifty!

[DdJ]

Nifty! If this plays out the right way, I may be able to drop my plans to abandon Debian on my servers.

Re:Oh, nifty!

[Delicious Pun]

Me too. That would be a very good day!

Re: Whining luddites

[Anonymous Coward]

Don't forget about Mozilla. Not only have they alienated almost all Thunderbird users, but they've driven away most Firefox users, too.

Re:Sorry it's freebsd FTW

[juanfgs]

Can you guys just telling you when you finish moving? you guys have been threatening to move to FreeBSD since Kernel 2.6 and it's getting old.

Re: What are they going to change to?

[Anonymous Coward]

The problem with systemd is not systemd but all the other junk I have to install with it.
I couldn't even deinstall avahi!!

FORK DEBIAN!

[Anonymous Coward]

Maybe it's time ? Half of the debian developers hate systemd the other half likes it. Maybe it's time to split up?

Re:FORK DEBIAN!

[Anonymous Coward]

It isn't developers or distro maintainers who hate systemd, so I don't know where this "half" number comes from. People are free to go create there own distros and then find out that systemd saves them a huge amount of time and frustration in actually maintaining the distro. Then they can realize that maybe the major distro maintainers know what the fuck they are doing.

Re:FORK DEBIAN!

[HiThere]

Sorry, but *you* are an anonymous coward. This means that your assertions have no value. There's no particular reason to believe anything you claim about yourself.

You could make logical arguments, or refer to other sources, and those would be reasonable contributions, but assertions aren't useful.

P.S.: I also dislike and distrust systemd. But this doesn't cause me to accept your assertions.

Re:FORK DEBIAN!

[JohnFen]

It isn't developers or distro maintainers who hate systemd

I'm a developer and I hate systemd.

Re:FORK DEBIAN!

[tqk]

Sorry, but *you* are an anonymous coward. This means that your assertions have no value.

BS. Anonymity doesn't lessen the value of their statements. Judge them on their merits, or shut up.

Re: FORK DEBIAN!

[Anonymous Coward]

I'm relieved to see that you used your full actual name, HiThere. If you hadn't, then we'd have had to assume that you were using a pseudonym, and posting in a cowardly, anonymous fashion!

Re: FORK DEBIAN!

[Anonymous Coward]

You're an awfully entitled little shitwipe, aren't you? "Oh, you don't have an account so any opinion you have is invalid." Really? That's the pathetically ignorant, self righteous twat of a way you judge people?

Fair enough, I'll judge you based on the contents of your Slashdot posts, that makes about as much sense. You're a part-time Neanderthal and you like huffing glue. Probably like taking it up the ass well, if the huge fucking stick you've got jammed up there already is any indication. Might want to get that checked out before it works its way up to the one brain cell you used to sign up with.

Fuck you and your account. You'd still be an asshat whether you signed in or not. Maybe the reason we don't sign up is that it seems like a waste of time to somebody who actually has a life. Doesn't surprise me that you're not familiar with the concept.

Re: FORK DEBIAN!

[Anonymous Coward]

I'm a distro maintainer for a custom Linux distro we created at my place of work for our embedded systems. I don't like systemd. It doesn't offer any value to my field. It also doesn't run well when yoyre in a memory constranded environment. The custom init system I wrote supports running dependences, IPC, and process supervision, written in shell and Lua. Boots to login prompt in 3 seconds on the 800mhz single core ARM processor.

Re:FORK DEBIAN!

[vilanye]

HiThere is your real name?

You are as anonymous as any AC.

There is a good thing coming from systemd!

[Anonymous Coward]

I get to increase my knowledge of BSD which I have been putting of for ages!

Systemd seems fine to me at this stage

[rongten]

Hello,

  I have deployed some fedora 20 machines in the last 3-4 months, and so far I did not see anything that led me to cry foul against systemd.

  Actually, the handling of the user sessions for house-keeping purposes seems much simpler now.

  So I don't get all this hate. Maybe I did not look deep enough, time will tell.

  Cheers

Re:Systemd seems fine to me at this stage

[Rich0]

Well, it does some things differently, and I can get why some don't like the "new way."

Also, on distros that are just adopting it like Debian it is immature. When you replace an init system that has been in use for 15 years with all those tiny little bugs worked out with a dependency-based init system that is brand new, there are going to be bugs. Dependency errors are easy to miss when you have unusual configurations. I had all kinds of issues with services not waiting for DNS to be available before starting, since the assumption was that if the network was available, DNS must be available. That is usually true, but it tends to fail when you're talking about a DNS server. Etc...

Re:Systemd seems fine to me at this stage

[kthreadd]

That's why distributions support their releases for some time, 5-10 years usually depending on the distribution. If you give it some time these bugs that you think of will go away. I have not run into them, I guess I'm lucky.

Re:Systemd seems fine to me at this stage

[Anonymous Coward]

So I don't get all this hate.

That's because you're actually working with Linux in the real world, and aren't merely a frothing fanboi hobbyist.

Am routinely deploying RHEL7 (and thus, systemd) these days. It's about time Linux gets the fuck out of the '90s and has an init system that isn't completely braindead.

Keep it up, Linux, and I'll stop regretting the death of Sun.

Re:Systemd seems fine to me at this stage

[Anonymous Coward]

Oh, is that what it was. I thought (for example) GIMP suddenly requiring systemd was a problem. I thought binary logs were a problem.

In fact, I thought that a number of people above made some damned good points about those particular things, and a few others besides.

Good to know that it's because they're "fanboi" hobbyists, particularly the guy who works in computer forensics. He must be one of those guys who breaks into server rooms, clones the hard drives, then works through the originals just for fun.

Re:Systemd seems fine to me at this stage

[Anonymous Coward]

I have deployed some fedora 20 machines in the last 3-4 months, and so far I did not see anything that led me to cry foul against systemd. Actually, the handling of the user sessions for house-keeping purposes seems much simpler now. So I don't get all this hate. Maybe I did not look deep enough, time will tell.

Whether systemd seems to work or not on new machines is not the main point of the discussion. The main arguments against systemd are its corruptible logs and, more importantly, the inflexibility it lends to the architecture of Linux itself.

There's a solution:

[tyggna]

Break up systemd into its components and let certain functionality of it be augmented or replaced by sysvinit. The ONLY problem with systemd is that it's rather monolithic and breaks the *nix paradigm of do one thing an do one thing well. We break out the features of systemd, and let each one work in a stand-alone way, then great.
One binary for parallelized boot
One binary for syslog database
One binary for daemon chroot
and in one kernel module for interface!

Re:There's a solution:

[Rich0]

All those functions already are in separate binaries (sort of - spawning a container is a separate binary, but chrooting a daemon is part of the same daemon that launches them). However, they aren't really designed to operate in isolation (at least not the log and the init), and nobody is interested in building bash-based replacements for journald or nspawn, etc.

Binutils and gcc consists of a whole stack of separate binaries, but you don't see people really mixing and matching individual ones much. They certainly weren't doing it back when it was first created.

Re:There's a solution:

[kthreadd]

It already works that way. If you build systemd with all features enabled you end up with something like 70 binaries or so.

Re:There's a solution:

[Peter H.S.]

Break up systemd into its components and let certain functionality of it be augmented or replaced by sysvinit.

There is actually good reason for why systemd is designed like it is. If people tried to re-implement systemd, they would face the exact same dilemmas that the systemd developers did, and probably solve them the same way.
If you remove certain parts from PID1, you will get an awful lot of overhead and communication between the new module and PID1. This isn't a trivial problem.

Another thing worth considering, that most of the things systemd deals with, are really hard low level stuff. Very few developers actually have the skills needed for dealing with session management like in "systemd-logind". So there are almost no independent developed "modules" that can be used to replace systemd "modules"; The no serious full alternative to "udev" or logind on any other init system. There is multi-seat support outside systemd either. Even journald has no real alternative, since rsyslog etc. can't get early boot log info, since unlike journald, they can't log info before the root filesystem is mounted.

So the alternative doesn't really exist anyway. The non-systemd proponents simply lack developers, especially low-level OS developers.

PaX Control.

[Anonymous Coward]

GRSecurity is better.

FORK DEBIAN!

[slashdice]

good call. Then, instead of one distro that's 5 years out of date, we can have two distros that are ten years out of date.

But seriously, systemd sucks. I don't understand why people would take a good operating system (and this has happened with Windows (vista and 8), OSX (Yosemite), and GNU/Linux (gnome, systemd)) and ruin it for the sake of ruining it.

Re:Summary of slashdot comments

[Anonymous Coward]

People that posting for the most part are fanboi's or people that cannot take change or desire to learn or spent 5 minutes trying it found their old way didnt work didnt care to learn something new and perhaps the new would benefit them.. Obviously why Microsoft still dominates the desktop and laughing at linux.. 2014 we still cannot make a dent

Maybe it's just time for RedHat ReactOS

[morgauxo]

Maybe Potering and his other buddies at RedHat are great, the best thing since sliced bread.... but... they are working on the wrong OS. These guys don't belong in Linux. They belong working on ReactOS! Imagine ReactOS with all of RedHat's resources behind it. It could quickly be a better Windows than Microsoft's! Meanwhile those of us who like Linux as Unix and aren't in the market for "Free Windows" can go on enjoying a better Unix than Unix. We could all be happy!

Re:Maybe it's just time for RedHat ReactOS

[Anonymous Coward]

So much ignorance in a single comment. All they did was write a new init system for their distro, other distros also happen to like it and use it, that isn't RedHat's fault.

Re:Maybe it's just time for RedHat ReactOS

[Rich0]

Meanwhile those of us who like Linux as Unix and aren't in the market for "Free Windows" can go on enjoying a better Unix than Unix.

Nothing is preventing you from forking the last Debian and doing just that. The problem is that while those opposed to systemd are fairly vocal, they're not nearly as numerous as they think and most aren't active contributors.

For the number of people crying "just use OpenRC" or whatever, how many of them have written a patch for OpenRC in the last year? Certainly not nearly as many as there are writing patches for systemd.

Re:Maybe it's just time for RedHat ReactOS

[Anonymous Coward]

For the number of people crying "just use OpenRC" or whatever, how many of them have written a patch for OpenRC in the last year? Certainly not nearly as many as there are writing patches for systemd.

For the number of people crying "just use TeX" or whatever, how many of them have written a patch for TeX in the last year? Certainly not nearly as many as there are writing patches for MS Word.

Re:Maybe it's just time for RedHat ReactOS

[thaylin]

Lol, so the ignorance statement was yours huh, that is not all they did. They made it hook and replace things it should not, causing dependencies, so that other things eventually had to use it. But I assume that is why you are posting AC.

Re:Maybe it's just time for RedHat ReactOS

[jbolden]

No they made it hook into things it should and replace other outdated systems. The dependencies exist because upstream developers wanted the advanced feature set that init didn't provide. And now that it exists upstream software is starting to evolve in ways that deeply take advantage of those advanced features being readily available making it harder and harder to work around them.

Re:What are they going to change to?

[armanox]

Actually, OSS was the older sound daemon. And it still works quite well in Solaris.

Spin up 100's of Linux instances in 10-20s? Boot time is insignificant for virtual servers. Oh, and guess what Amazon's web platform runs on...?

In summary: BSD Init and SysV Init are fine.

Re:Sorry it's freebsd FTW

[geminidomino]

I used to use FreeBSD back in the day and I gotta say, pkgng is looking like it's pretty slick at solving the #1 reason I moved away from it (too much of a PITA to keep many heterogeneous servers up-to-date)

Opposition was suppressed.

[Anonymous Coward]

Anyone who talked against systemd in the debian IRC channel(s) was banned.
Anyone who talked forcefully against systemd on the debian mailing list was silently banned.
Eventually Anyone who wrote out "systemd" in a mail to the mailing list had their mails silently dropped, delayed, filtered.
(People started calling it killer rabbit)

Thank Don Armstrong (mailing list president for life) and the systemd cabal within debian.
(8 men plus all of debian-women)
.

Re:Opposition was suppressed.

[ziggyzaggy]

How many of thoe debian-women are there? is that the real problem with this systemd bullshit?

Re:Whining luddites

[Anonymous Coward]

You are correct, we should just move to Windows 10. Human readable config files and configurable systems are just stupid. All systems should be designed with the average Facebook user in mind. The people who use this shit for actual real world applications and know what they are doing should be ignore and so should their needs. The most important thing is that no thinking has to go into installing and configuring a system. How else can we get Linux on grandma Ednas desktop and finally cash out?

All's I know...

[MouseTheLuckyDog]

The #2 developer of systemd has been banned from contributing to the kernel.
The #1 developer of systemd was the main developer of PulseAudio-- does generate much confidence.
He has also just given the finger to the OSS community--makes me wonder why he doesn't do Macs or Windows.
It is being given control over critical services such as TTY and networking.
It is hard for the average techie to audit it, given it's nature. Little access to a lot of tools: valgrind, strace, ftrace.

This does not make me feel very good about systemd.

Re:All's I know...

[kthreadd]

Remember this before ranting too much on Lennart. He is not in any position to force any distribution to do anything. Distributions choose to use his software because it actually is better than the stuff that came before it.

Re:All's I know...

[thaylin]

That is very debateable, stop trying to say it like it is an undisputed fact.

Re:All's I know...

[grcumb]

Remember this before ranting too much on Lennart. He is not in any position to force any distribution to do anything. Distributions choose to use his software because it actually is better than the stuff that came before it.

Yes, of course Lennart's just a developer with a better idea. He's never seen software development as a means to a larger political end.

Except when he has:

Getting a clear message out what Linux is supposed to be is definitely a social issue, but to make that happen the Linux platform needs to be streamlined first, and that's a technical task, and not done yet.

All of these disingenuous statements that there's no other agenda in place are just bullshit. They're simply and self-evidently not true, because you can't do system design without some kind of vision of what you want. And you don't change the system design unless you don't like the one you've got. Lennart's vision, as he says, is a 'streamlined' Linux, which is to say catholic, not agnostic, unified rather than pluralistic, with fewer options rather than more. And when you cut away all the cruft, it's his stuff that remains.

Poettering and his acolytes can argue all they like that their vision is simply better. I disagree, but I accept that this is always an argument worth having. But when you start arguing that POSIX is a constraint and that Linux should be 'leading' the way (and that POSIX can just catch up, thank you), you're taking a stance that is not simply in opposition to others, it cannot coexist with the others because the alternatives have become mutually exclusive within a particular space.

POSIX is a limiting factor. That's true. Its limitation is that we've all agreed on a basic subset of behaviours in order that we all have enough in common to interact. So when you discard POSIX, you have effectively announced that you do not see the value of playing nicely with the other children. From that moment, your 'better idea' is being implemented at the expense of interoperability.

Which is a really fucking bad idea.

(The quote above is from an interview with Lennart, linked from his Wikipedia page.)

Lastly, to respond directly to the assertion that he is not in a position to force any distro to do anything. The tight web of dependencies, his position at RedHat and the support and assistance provided on the corporate level is perhaps not sufficient literally to force a distro to use his software, but it's enough to raise the question that undue influence is being brought to bear and that rather questionable tactics are being indulged in expressly because Lennart and his cohorts think that doing the right thing does not imply contributing in an open[*] and inclusive way.

-----------------
[*] Lennart's idea of openness is allowing others to interact with his software, but fuck you if you want him to take a second look at your requirements. And then, of course, to act shocked (shocked!) when others get upset.

Re:All's I know...

[jbolden]

Not really. There is the:

a) I don't like complex binaries even though I run the Linux kernel crowd.
b) There are the people who claim to be interested in server but don't seem to know anything about server. So when you try and discuss issues like the mechanics like setting up security contexts and Linux control groups (cgroups) for processes having to be done manually or the complexities process management they don't have answers.
c) There are the people who don't like change and talk about "the Unix way" even though most of them don't seem to have done much Unix other than Linux.

I have yet to hear the sysinit come forward with real solutions to the limitations of init. OpenRC was an attempt and if they wanted to provide a solution building on that would make sense.

Re:All's I know...

[jbolden]

I think you are conflating two distinct things:

a) Not supporting POSIX in 2014
b) Not supporting the concept of interoperability.

You talk about it a little with "POSIX can catch up". But that's really the core. POSIX as it exists today came out of the late 1980s+ open systems movement as a way to tie together a bunch of proprietary Unixes which mostly are dead. It doesn't really help on porting software today, Windows has POSIX but it isn't easy for Windows software to move back and forth. IBM is really the only player left from the original group and even they support Linux leading AIX.

Obviously there are going to be needs for diverse operating systems today and going forward. OSX is the dominant desktop Unix. Windows is a huge player even in server. zSeries continues to exist and thrive. It is important to figure out how to get software to cross between these systems. POSIX doesn't really help with that problem today. The group that is really focused on working through the issues of getting software to run cross platform is the Azure group at Microsoft and I don't see the sysinit crowd contributing to that effort. What evidence is there that we are talking about interoperability and not just resistance to change. Thursday I was at the meeting where interoperability for large databases came up, no one even mentioned POSIX because POSIX doesn't say anything remotely relevant about running large databases between systems.

Re:Sorry it's freebsd FTW

[kthreadd]

Do they still only rebuild packages once per week? They used to do that when pkgng was new and waiting up to a week for an update was a bit too long.

SystemD = NSA bugged software

[Anonymous Coward]

And I'm keeping my 0days for this.

Please let this be a good sign

[JohnFen]

The systemd problem will force me to stop using Debian, a prospect that I dread for a number of reasons (but mostly because changing all my servers and workstations will be a lot of work). Could it be that this is a sign I might not have to leave? Oh, please let it be so!

Re:Please let this be a good sign

[kthreadd]

Really? For most users all systemd means is that there are some new commands that you can use if you want. Not a big deal at all.

Re:Please let this be a good sign

[JohnFen]

For my own collection of systems, there's only one use that counts: that's me -- and this is a big deal for me. For my needs, both on my servers and workstations, systemd presents a lot of downsides and no upsides. Therefore, I reject it. I would prefer the relatively short-term pain of migrating my systems over the long-term pain of dealing with systemd -- but I rather that I could just continue to use Debian without having to use systemd at all.

Re:Please let this be a good sign

[kthreadd]

What's so painful about systemd? Seriously.

Re:Please let this be a good sign

[thaylin]

why does he need to explain to you, someone who has a habbit of fanboishly attacking others for their issues?

Re:Please let this be a good sign

[JohnFen]

I have a moderately long list of pain points, but the biggest one for me is all those damned dependencies. For the most part, my list is the same as most everyone else who has used it and found it wanting. There's no need to go into detail, as these details can be easily found pretty much anywhere that discusses systemd.

Ian Jackson

[inhuman_4]

For those who don't know, Ian Jackson was the most vocal anti-systemd proponent on the committee. Considering that last time systemd was up for vote he tried: strategic voting, usurping the committee chairman, and finally throwing a temper-tantrum and refusing to talk to anyone for a few days. When it was all over he promised to try and reverse the committees decision with a General Resolution.

And now having failed to win on technical merits, he is back at it again trying to kill systemd via 'loose coupling'. Something that the committee declined to rule on.

Re:Ian Jackson

[Anonymous Coward]

Regardless of his conduct, the tight coupling that systemd is leading to has shown itself to be a very real problem and I think it totally needs to be looked into.

I'd love to see Debian roll back on their decision and then the whole community just totally abandon systemd and pretend it never existed. As I don't see that happening, I'd love to at least see Debian put the brakes on the tight coupling. If having things like Gimp depend on systemd is no longer an option, it might at least suppress the systemd virus for a little while as the devs try to figure out how to avoid that with an init system that wants to be half the operating system.

Re:Ian Jackson

[Anonymous Coward]

Well he's a hero of mine now. Thanks for pointing out his commitment and good work.

Re:Ian Jackson

[Anonymous Coward]

systemd developers have tantrums all the time. Linus does on occasion. That doesn't mean Ian is wrong.

This isn't about what systemd can or cannot do, it's about the stick nature of the change rather than using a carrot of the supposed technical merit you speak of. usually in the linux world, the best thing wins.. this time it was bought.

Re:Ian Jackson

[Anonymous Coward]

... we are talking about Ian Jackson, the person who was projectleader of debian, author of dpkg and president of Software in the public interest ? If so then state his contributions to debian and stop making a troll out of him. He has some value in what he said and there are plenty (if not more than half) of the debian developers who back his side.

Re:Ian Jackson

[Anonymous Coward]

+1.

Re:Ian Jackson

[Sipper]

Ian Jackson is a man of principle, and the way the final vote was done within the TC [Technical Committee] was certainly objectionable: he was in the middle of discussing what should be on the ballot when Bdale Garbee called for an immediate vote on the same subject but with a totally different ballot. Then when the vote came to a tie, Bdale used the "casting" vote, meaning he had two votes where all the other TC members had only one. Furthermore Bdale's friend and close business partner Keith Packard had just recently joined the TC.

Furthermore this GR [General Resolution] isn't about reversing the TC decision nor in changing the default init system for the Jessie release -- it's about giving the other init systems a fair chance by making them possible to use by making the bugs in packages causing them to break RC [Release Critical]. That's all.

And he did bring this GR up in March, but at that time the Debian community was more hopeful that support would continue for the other init systems, but instead support for everything else has waned -- Ubuntu immediately decided to switch to systemd and drop upstart, and there have been issues with support for other packages concerning the standard sysv-rc init -- all of which Ian had expected to happen.

The main objection from Debian developers concerns the timing of this GR only because the Jessie release is nearing, but ... Ian did bring this up in March...

Re:Ian Jackson

[Anonymous Coward]

For those who don't know, Ian Jackson was the most vocal anti-systemd proponent on the committee. Considering that last time systemd was up for vote he tried: strategic voting, usurping the committee chairman, and finally throwing a temper-tantrum and refusing to talk to anyone for a few days. When it was all over he promised to try and reverse the committees decision with a General Resolution.

And now having failed to win on technical merits, he is back at it again trying to kill systemd via 'loose coupling'. Something that the committee declined to rule on.

...backed by a huge Risup-based conspiracy campaign. See debian-user lists for examples. Even threats to kill. It's like the NSA invested enormous resources in backdooring internet appliances and systemd threatens that deployment (oh wait.. that is a conspiracy theory).

Let's not forget Debian is a meritocracy - where the workers decide what they do - or did....
Social contract - users. How do you please everyone - especially the unwashed mob, many of whom only migrated to Debian two months ago simply to protest that nothing should change, ever. It's not just anti-systemd (Poettering is a nazi/RedHat stooge, etc), it's anti-udev, anti-GRUB, anti-Iceweasel (it has DRM support!), wants developers to swear an oath of no commercial affiliation, wants to register users for a vote that will force volunteers to develop there way.

"Their" way is the antithesis of Open Source - if you don't like it fuck you and we'll pour sand in the tank until we get our way - instead of fork it yourself.

And most of the packages that the anti-systemd troofers claim rely on systemd don't[*1]. But let's not let facts get in the way of a rabble rebellion. Bring on the "I've been using Debian for thirty years and I refuse to learn anything new - because (I'm retarded), it's monolithic, binary, anti-Unix (Linux ain't Unix idiots).

[*1] I'm looking at you - Steve "Bullshit Artist" Litt, this month redesigning Debian, last month XBuntu, rinse and repeat trail of havoc and trolling while promoting his books and building his sock-puppet armies.

Re:Ian Jackson

[Demonoid-Penguin]

Ian Jackson is a man of principle, and the way the final vote was done within the TC [Technical Committee] was certainly objectionable: he was in the middle of discussing what should be on the ballot when Bdale Garbee called for an immediate vote on the same subject but with a totally different ballot. Then when the vote came to a tie, Bdale used the "casting" vote, meaning he had two votes where all the other TC members had only one. Furthermore Bdale's friend and close business partner Keith Packard had just recently joined the TC.

Furthermore this GR [General Resolution] isn't about reversing the TC decision nor in changing the default init system for the Jessie release -- it's about giving the other init systems a fair chance by making them possible to use by making the bugs in packages causing them to break RC [Release Critical]. That's all.

And he did bring this GR up in March, but at that time the Debian community was more hopeful that support would continue for the other init systems, but instead support for everything else has waned -- Ubuntu immediately decided to switch to systemd and drop upstart, and there have been issues with support for other packages concerning the standard sysv-rc init -- all of which Ian had expected to happen.

The main objection from Debian developers concerns the timing of this GR only because the Jessie release is nearing, but ... Ian did bring this up in March...

I'd encourage anyone reading the above tripe to read the debian-project lists and form their own opinion based on facts. Failure to do so is problematic.

Re:Sorry it's freebsd FTW

[geminidomino]

I honestly can't say. I've only been messing with it in a testing/dicking around capacity, and haven't been swimming in free time for the past month or so. Hopefully someone lucky enough to be doing it full time will post and let us know.

Still, it's a damn sight better than "make buildworld" was (yes, it's been that long)

Re:What are they going to change to?

[gweihir]

Really, you have no concept of what "flawlessly" means. Ultimately, systemd will cause Linux to become as flaky as Windows, because it shares the design philosophy.

Re: What are they going to change to?

[Anonymous Coward]

Then your distro is broken. These are all dependencies as of version 216. Mostly standard stuff.

acl.x86_64
audit-libs.x86_64
bash.x86_64
coreutils.x86_64
cryptsetup-libs.x86_64
dbus.x86_64
diffutils.x86_64
elfutils-libelf.x86_64
elfutils-libs.x86_64
glibc-common.x86_64
glibc.x86_64
kmod-libs.x86_64
kmod.x86_64
libacl.x86_64
libblkid.x86_64
libcap.x86_64
libcurl.x86_64
libgcc.x86_64
libgcrypt.x86_64
libidn.x86_64
libseccomp.x86_64
libselinux.x86_64
pam.x86_64
qrencode-libs.x86_64
sed.x86_64
shadow-utils.x86_64
systemd-libs.x86_64
xz-libs.x86_64

Re:Init is broken

[Billly Gates]

It can't do event driven launches and yes it does impact desktop users. Example, your on your corporate network on a laptop and you close the lid and take a plane to somewhere else and the laptop wakes up. How can Init handle something like this and know to configure it to a new network?

This is why Sun, Apple, and Ubuntu developed their own event driven systems. System D is not good. But event driven systems can respond to events like a hack attack, excess load, and other things for servers.

Init was made for stationary mini computers with only 20 text based commands and apps. It's not designed for the hacks we use to get it to work today on modern systems

Five minutes for shutdown?

[Anonymous Coward]

You have to be joking. Five minute time delay on shutdown? Don't those idiots realize what that does to anyone with a UPS? You typically get a choice of two or five minutes for the impending power loss warning. A five minute time delay makes a clean shutdown impossible by design. Of course lib-virt does the same thing now on Debian 7. Seriously.

Re:FORK DEBIAN! Suit yourself

[Anonymous Coward]

Suit yourself.

I program for various free software videogames. Text console, 2d and 3d. I also make music, 3d models, levels, pixel art for them.

Last time I said what they were the cunts attacked and took them down. There is no room for "mysoginists" in the "free software" world anymore. Because the cunts said so.

Regardless of the quality of my work, it is far and above anything the bitches have done, and the "developers" (packagers) they imagine themselves to be.

EMACS vs SystemD

[Anonymous Coward]

Actually, I think the fear is that we are now watching a race to see which happens first: Does EMACS add device drivers and become self hosting before SystemD grafts in a text editor? Either one is only going to be a abomination.

Good!

[Anonymous Coward]

Good. He is trustworthy and true against the virus.
The committie had NO RIGHT to vote on init at ALL.
It is not a BUG that systemd isn't default init.

He's the only one not bought out by REDHAT OR CANONICAL.

You are a fucking piece of shit because you put forth the falsehood that the technical committie has the RIGHT to be an oligarchy upon debian.

FUCK YOU YOU FUCKING PIECE OF SHIT CUNT!

Re:Init is broken

[Anonymous Coward]

It can't do event driven launches and yes it does impact desktop users. Example, your on your corporate network on a laptop and you close the lid and take a plane to somewhere else and the laptop wakes up. How can Init handle something like this and know to configure it to a new network?

This is why Sun, Apple, and Ubuntu developed their own event driven systems. System D is not good. But event driven systems can respond to events like a hack attack, excess load, and other things for servers.

Init was made for stationary mini computers with only 20 text based commands and apps. It's not designed for the hacks we use to get it to work today on modern systems

So why would/should that be a function of an init system, and not a function of, say, an event driven network daemon that gets started by init on bootup - and receives event notifications on you opening/closing the laptop lid (suspend/resume)? Why should that need an entirely re-written init system when it could easily be done in just a (rewritten) network daemon using the existing init system?

Sounds to me more like entirely missing the point of what the init system is supposed to do... which is *not* reconfiguring NICs, etc (those are functions of the scripts/daemons it starts).

Re:What are they going to change to?

[The Technomancer]

As someone who does spin up a metric fuckload of instances in the cloud (or more specifically, has his monitoring system trigger a set of scripts to do it based on site and API traffic), I can guarantee you that you are full of shit and haven't actually had to do those things as part of your career thus far.

I -love- new technology that makes my life easier. I'm a big fan of the Vagrant -> Docker -> Deploy workflow for apps where that flexibility outweighs the overhead costs. There's now way I could manage my cluster in a sane matter without the central config management apps.

Systemd ain't the way. At best, it's a large attack surface and single point of failure. At worst, it's an anti-pattern.

Third init needed - freedom is cool.

[xtronics]

I love Debian - this messy debate is what freedom looks like. We should embrace it. This is how real progress is made.

That being said. The evolution of an init system is still needed, and there are some major problems with both systems - thus it is obvious that there is an opportunity for a third system that is more elegant than either of these two.

I think the debate has shown that neither way is correct and that a third way - probably more evolutionary and less draconian will emerge.

syselegant ? sys-e for short?

The gradual middle road

[gnu-sucks]

I don't see why nobody is taking the middle road here.

Why not strip out all the non-init.d stuff from systemd for now (I understand there's a light fork that does this already), add plaintext logging (easy), and see how things go (testing).

This is linux, and debian at that. We shouldn't have to deal with extremely beta ideas that change so many paradigms all at once. If they can do what I've outlined here, then we should give it a shot (not on production servers yet of course). If it catches on, then over the years we can debate how much to delegate to systemd and how much to do another way.

For one, I can see no disadvantage in keeping a plaintext log around. Sure, takes a little more space, but most systems are not that space-limited these days. Seems like it would be handy...

Re:The gradual middle road

[raxx7]

systemd-journald has long been capable of forwarding the logs to rsyslogd.
And systemd-journald can even be configured to keep it's binary log in /var/run/journal, which gets deleted at each reboot.
And Debian uses this configuration for default.

Unfortunately, if they acknowledged this, systemd haters would be left with one less thing to hate.

Other functions provided by the systemd package (eg, session managment by systemd-logind) are just a lot of work to implement, specially if you try to go for a more decoupled architecture.
Not that people aren't working on it though.

Re:The gradual middle road

[Anonymous Coward]

Perhapd they would have one thing less to hate. But how many would left?

It is not only about syslog anymore. Even if Debian will use rsyslog then what? How many ppl are learing not syslog but journald thesse days? This may lead to ignoring syslogs and alienate them from Linux. I hate systemd not for one project it may kill but for many it did kill this way already.

I hate it for slowing progres of linux inowation. RH thinks that they are soo innowative that they can fuck their profesionals bad and its ok.

The RH can have their vision of things but if we all take their vision as ultimate true, then we are like scientis who believed that earth if flat - you cannot argue with ultimate non questionable truth. We need ppl who will chalenge our views because they can sometimes move us forward. Just by showing us that we might be wrong.

Re:The gradual middle road

[AntiSol]

systemd-journald has long been capable of forwarding the logs to rsyslogd.

Unfortunately, if they acknowledged this, systemd haters would be left with one less thing to hate.

This isn't true - compare:

* daemon -> systemd -> syslog -> textfile
with
* daemon -> syslog -> textfile

Simple question: Which one has more parts and contains new software and is therefore more prone to failure?

Writing a binary log and then forwarding to syslog isn't acceptable because it makes the assumption that nothing will go wrong with the logging. Since we're talking about failure conditions this is not necessarily going to be true. This translates to an increased risk of lost and unrecoverable logging information, which in a mission-critical production environment is a big deal.

If you're going to write both plaintext and binary logs, you should be writing the text log first. That way if there's a problem like disk failure you can read the (partial) text log rather than being left with a corrupt and unreadable binary blob. The problem with doing it that way, apparently, is that then you wouldn't need binary logging...

Re:Summary of slashdot comments

[thaylin]

how funny, the fanbois seem to be the one who refuse to see that there is any issue. Remember there is a reason Linux has dominated the server market, and not Microsoft, and this process seems to want to take us away from that for the sake of something most users will probably not consider using for a long time off. It is not because of the init system by the way.

Cgroups

[Tenebrousedge]

The reason why systemd exists, and the reason why it isn't portable, are the same reason: it depends on a feature specific to the Linux kernel.

It's not up to the systemd developers to write kernel features for other OSes. If there's an "anti-standard" it's the kernel, not systemd. If the rest of the Unix world wants to implement something similar then I am sure it could be made part of a standard eventually. Until then, you've wasted space typing.

Re:Sorry it's freebsd FTW

[tqk]

... waiting up to a week for an update was a bit too long.

WTF are you doing in a Debian discussion?!?

Power User vs. Common User

[Anonymous Coward]

Yikes! All I see modded up in this thread are the power users and admins AGAINST the common user. This continuing struggle is why Linux has never and will never gain a stronghold in the desktop market until it ends. It is also why Mac OS X is gaining ground over the Windows alternative market while Linux continues to hold less than 1% of the desktop OS market.

Until you myopic Linux power users (most of whom these changes really don't matter to as they could roll their own distro or use a stripped down one) get over yourselves and realize that if you want adoption of Linux to really grow on the desktop you have to accept the needs of the less technical among the populace, you're going to be in a minority that most of the world doesn't give a shit about. But, I guess that's what makes you "special", but not in a good way.

Re:Power User vs. Common User

[walterbyrd]

How does making Linux worse create more Linux adopters?

IMO: Linux adoption is not about ease of use, it's about entrenchment. MS is masterful at using vendor-lock-in techniques, and leveraging the network effect.

Creating a huge rift in the linux community with this systemd crap is not going to improve desktop linux adoption in the least. In fact, it will have the opposite effect.

To all of you who want to fork or abandon Debian..

[JoSch1337]

...you do realize that the TC decision was just one about the default init system for Jessie? Nobody will stop you from not using systemd if you so wish. There is also no decision yet on how to upgrade people from wheezy to jessie, whether that upgrade should mean to switch the init system by default or whether users should stay with their existing init or be given a choice at upgrade time.

The only thing that'll make it harder to switch to non systemd is that some desktops (gnome) will depend on logind. Unless somebody creates a replacement for logind, gnome will depend on systemd but this is hardly Debian's fault. So if you want to complain about Debian "forcing" systemd on you, please complain to gnome to use logind or (better) come up with your logind variant.

It is also necessary to mention the existance of systemd-shim (but this also has to be maintained by someone...).

Re: Whining luddites

[Zontar The Mindless]

Would that be the Mozilla that touted its extensibility, then proceeded to break extensions with every update?

Would that be the Mozilla that insists on moving around major chunks of the UI with every release, and with no way to change it back?

Would that be the Mozilla that has become a hotbed of elitist "We know what you want, and what you want is Chrome?" assholes?

Just checking...

Re:Summary of slashdot comments

[Anonymous Coward]

Or it could be that such people KNOW WHAT THE FUCK THEY ARE TALKING ABOUT.

And what they are talking about is known as, "Reinventing the wheel... Badly."

You want to change things? Great. Fix things that are broken. Or add new things that give us new capabilities.

Otherwise, fuck off and *don't try to "fix" stuff that ain't broke*.

my experience

[Joepie69]

Problems I had with systemd on jessie before giving up.. 1/ When using virtualbox and mount my shared vboxsf using fstab... system died. No login prompt... nada just stuck. 2/ In another case (i still dont know the root cause) I got the emergency console with the messsage to fix the problem after login... But unfortunately I couldn't type anyhting at the prompt 3/ Jetty did'nt start. Nothing in systemd journal, nothing in /var/log/jetty). Forced the thing to use the normal init script and found the problem within 10seconds. So my conclusion is that it's not stable at this point in time and not for main deployment. I hope that debian is offering multiple init systems. Linux is about choice.. So let people choose... We can choose already the desktop, why not the init system?

Re:my experience

[Demonoid-Penguin]

Problems I had with systemd on jessie before giving up.. 1/ When using virtualbox and mount my shared vboxsf using fstab... system died. No login prompt... nada just stuck. 2/ In another case (i still dont know the root cause) I got the emergency console with the messsage to fix the problem after login... But unfortunately I couldn't type anyhting at the prompt 3/ Jetty did'nt start. Nothing in systemd journal, nothing in /var/log/jetty). Forced the thing to use the normal init script and found the problem within 10seconds. So my conclusion is that it's not stable at this point in time and not for main deployment. I hope that debian is offering multiple init systems. Linux is about choice.. So let people choose... We can choose already the desktop, why not the init system?

Error messages? cat /etc/fstab?

You do know that Jessie is not Stable - right?

It's possible that your lack of literacy might by an obstacle... (simple is an synonym for what?)

Re: Init is broken

[t_hunger]

That actually is a pretty good description of how systemd handles this.

Context folks

[Demonoid-Penguin]

Debian wanted an init system for the linux kernel - and the KFree-BSD kernel, and the Hurd kernels. Reassess you suggestions in that light and don't forget it's the developers who have implement this - ask the impossible and lose developers. It is that simple.

I expect I'll get down-voted to obscurity for bringing facts to this ignorance fest/celebration of One-bookian, Unix-deluded, festival of ignorance.

Did I mention that Debian never dropped alternative init systems? Too late - cue the conservative hate.

You lie or...

[Anonymous Coward]

You haven't been paying attention.

Udev, gnome kde,... - again

[ebvwfbw]

Yet again, people who don't want to learn something different. They learned the old way (so get off their lawn). There is no question the old BSD and sysv stuff has served its purpose well. For the past 10-15 years I really wished the startup would do things better. There was no reason to cling to those old ways especially with the new hardware. None at all. New stuff makes sense and isn't that hard to learn. Tear yourself away from looking at porn or games for an evening and learn it. It won't hurt, I promise. RedHat has a man ( for dummies if that helps ) page here - https://fedoraproject.org/wiki... . For most of you that's all you'll ever need to know. For guys like me - http://0pointer.de/blog/projec... .

Never see these discussions with Microsoft. It's their way (or the highway), right or wrong (mostly wrong). I didn't like it either. Spend about an hour, learn it, enjoy.

Re:Udev, gnome kde,... - again

[walterbyrd]

> Never see these discussions with Microsoft. It's their way (or the highway),

Microsoft Windows is not built on open-source code that was created by the community. Microsoft owns Windows, Red Hat does not own Linux.

Linux is supposed to be the anti-MS, that is one thing that a lot of people like about Linux. Some users do not like being shoved around by an abusive monopoly: be it Microsoft or RedHat.

Re:Udev, gnome kde,... - again

[ebvwfbw]

Microsoft Windows is not built on open-source code that was created by the community. Microsoft owns Windows, Red Hat does not own Linux.

Linux is supposed to be the anti-MS, that is one thing that a lot of people like about Linux. Some users do not like being shoved around by an abusive monopoly: be it Microsoft or RedHat.

You're wrong about Linux being anti-MS. That's simply not true. It's the free version of Unix. We had Unix long before Microsoft. It was around when Bill Gates was just a page walking around the halls of the US Congress. Clearly Windows was a joke well up until 2000. Unix you had to pay a lot of money for. I remember those days. I actually had paid for copies of Unix. $350 if memory serves me. There was also SUN's version for about $80. Ran only on their hardware though. Absolutely loved it when freebsd and Linux came out. Windows was crap. MS-DOS was just $30 at the time.

RedHat isn't an abusive monopoly. Not sure who told you that. They give away a lot of software, probably stuff in your favorite distro that you though they wrote. They have made some decisions that were unpopular, however I realized they were making the right decision. I'm sure some people disagree, just the nature of things. Choice for choices sake isn't always a good thing.

Anyhow, here we are all over again. Now it's bsd/sysv/systemd. To me there really is no choice. Sooner or later everyone else will realize it but the people who refuse to admit they were wrong. Sometimes that's entertaining too. When they are just really, really, really wrong about something and everyone knows it.

Are big institutions upgrading to RHEL 7 ?

[walterbyrd]

That is what really matters.

Nobody cares if individual users switch to Slackware, or FreeBSD, or whatever. In fact, Red Hat would probably prefer that.

But, if the big companies, and governments, stick with RedHat 6.5, I think that would be a big deal.

I doubt big institutions would switch away from RHEL, they like that corporate support. But, I can see big institutions holding off on buying RHEL 7, and that would be a big deal.

Will it matter in the long run?

[lsatenstein]

Technology is leaping forward by the second. The availability of very high-speed internet means that thousands of small to medium business Linux systems will be transferred to the cloud. Cloud systems will mean a huge reduction in the need for in-shop linux systems. It means, essentially, that businesses will buy computing services, will give up the systems department and that expensive "Air Conditioned" computer room, and support staff.

This is Autumn 2014, and this transition is happening now. Is this season the beginning of the autumn decline of independently installed Linux business computer systems? Have you the guts and funding to begin a cloud service or to transition to a job in a cloud service?

Will you care about making a profit, or of the differences between Systemd and the existing interface?

Here's some advice.

[aithiopis]

Those who don't understand UNIX, are DOOMED to reinvent it! POORLY!

NSA?

[Haluk Yildirim]

Someone has to connect the binaries to NSA !

old debian user here

[geroy]

I'm sysadmin using Debian for servers since it was 2.0/Hamm (back in 1999 or something). The one thing that I really like in Debian is that there are a lot of alternatives if you don't like particular software. Back in the days I was using djb daemontools to keep critical services up and running and some years ago I moved to 'runit'. Now I made some tests and it seems that 'runit' is capable of replacing /bin/init without any major problem. The whole systemd crap is the opposite of the idea of freedom to use whatever you like. Moving to systemd because GNOME will not run on a system without X at all is just plain wrong. Debian is good for servers, desktop users probably are already moved to Ubuntu or some other user friendly distro. Perosnally I prefer a fork of Debian!!

Structured, and even an OO system configuration

[Anonymous Coward]

this goes against much of the traditional Linux spirit of small self-contained bits that can be swapped out at will.

In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.

Personally, that principle of having many swappable self-contained bits is one of the worst qualities on UNIX.

I've been using GNU/Linux for over a decade. I know my way around most distros, and I can usually figure out what I need to do to accomplish any task... usually. The biggest problem I face now is that distros have so many small components doing their small tasks that figuring out exactly which component is responsible for a given task is no small feat.

I understand and appreciate the programming simplicity that a small component brings, but from a user's (or admin's) perspective, the operating environment is now more cluttered. As distros pick and choose their preferred swappable components, the view gets worse. Sure, I know exactly what the "finger" command does, but it's not obvious that "pinky" is an alternative, because having a lightweight finger command is apparently an important thing. Some distros will even create symlinks or scripts to provide alternative common names for their chosen packages, but there's seldom a guarantee that the input or output will be the same.

Configuration is a sort of programming, in a way. What we need is applying learned principles and good practices from software engineering and apply them to art of system construction from atomic components, instead of constructing compiled monolithic software application to do that instead. Systemd is replacing components with its own internal parts, but true way is to make a scaffolding which organizes other's components, and to demand components to declare what they do and how they differ from other substitutes. If (because) they don't do that themselves, we need some sort of accompanying manifest files that could allow components' composition into a system, and blueprint of that system should be described with yet another kind of descriptive file. Also, such method of system construction should allow hierarchical breakdown: small components could be parts of stacks and aggregations which are then given their on manifest file, so that they can be encapsulated and used as black box components in higher hierarchical levels. There should be no mixing of responsibilities and mixing of levels allowed. Dependency graphs must be de-spaghettized (just like control graphs in structured programming).