Slashdot Mirror
Systemd-Free Devuan Announces Its First Stable Release Candidate 'Jessie' 1.0.0 (devuan.org)
Long-time reader jaromil writes: Devuan 1.0.0-RC is announced, following its beta 2 release last year. The Debian fork that spawned over systemd controversy is reaching stability and plans long-term support. Devuan deploys an innovative continuous integration setup: with fallback on Debian packages, it overlays its own modifications and then uses the merged source repository to ship images for 11 ARM targets, a desktop and minimal live, vagrant and qemu virtual machines and the classic installer isos. The release announcement contains several links to projects that have already adopted this distribution as a base OS.
"Dear Init Freedom Lovers," begins the announcement, "Once again the Veteran Unix Admins salute you!" It points out that Devuan "can be adopted as a flawless upgrade path from both Debian Wheezy and Jessie. This is a main goal for the Devuan Jessie stable release and has proven to be a very stable operation every time it has been performed. "
"Dear Init Freedom Lovers," begins the announcement, "Once again the Veteran Unix Admins salute you!" It points out that Devuan "can be adopted as a flawless upgrade path from both Debian Wheezy and Jessie. This is a main goal for the Devuan Jessie stable release and has proven to be a very stable operation every time it has been performed. "
is for D lovers
thankfully Ubuntu lets you easily switch back to Upstart, permanently
apt-get install upstart-sysv; update-initramfs -u
Most Linux users don't have a strong opinion on systemd either way, because the system boots up reliably without systemd, and it also boots up reliably with systemd. Overall it's barely noticeable and doesn't matter (right now, anyway) for most users.
There are people who write startup scripts for Linux, and they tend to have a stronger opinion, because it affects them more directly. Some really like systemd, some really don't. Some (like Patrick Volkerding) are fairly neutral about the whole thing but see no pressing need to switch.
Then there are people who are system designers, who are ok with systemd as an init system, but see it as horrid when it's a platform for building an entire OS. As long as it stays as an init program, it's fine because it can be swapped out easily. But if it starts becoming a required component for turning up the volume, that is clearly a sign of poor design.
"First they came for the slanderers and i said nothing."
I blame the current generation.
They just can't say 'I don't like X; I'm going to do Y instead.' No, it's a holy war with every little thing. These kids need to miss a few meals in their life and then maybe they will get some perspective.
I think the should've called it 'Jevuie'.
These kids need to miss a few meals in their life and then maybe they will get some perspective.
No they won't, they'll protest until they get their meals.
"This was the whole point of open source. If something is wanted then it is usually developed. If it doesn't work for some reason, support the guys who are trying to make it work rather than bitching that someone moved your cheese."
Except it wasn't wanted, and many people feel like it was rammed down their throats. It's not that it does or doesn't work (sometimes it does, sometimes it causes trouble). It's that open source is not about 'supporting the guys' who are making something you don't want, and who are making it more and more difficult to opt out.
If it was designed properly we wouldn't have to go to another distro.
It's like saying if you don't like the radio go buy a different car.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Except it wasn't wanted, and many people feel like it was rammed down their throats.
Horseshit. Systemd won on all technical ground. It was chosen to fit the vast majority of use cases. A few people wanted an alternative and Devuan was born. The system works. Get over it and move to the distro which suits you.
What technical ground? Was there a vote or consensus reached? Redhat switched because they are Redhat and everyone else said sure whatever. If anyone wanted a new feature for systemd Poettering shit out some code overnight and they were happy. This is like claiming McDonald's is the best restaurant because they sold the most hamburgers last year. What is the deal with binary logs? I know AIX has them but why Linux? What's next, all the config files are stored in a flat binary database? Brilliant!
Only the State obtains its revenue by coercion. - Murray Rothbard
Personally, I am still trying to figure out what real problem it solves.
Every claim for systemd seems to be that it solves things that are simply not real issues.
Anyone?
The one real problem it seems to solve is: how does RedHat become the company that controls the architecture of all Linux distros.
The real "Libtards" are the Libertarians!
Real world example:
https://www.digitalocean.com/c...
This howto tells you to disable firewalld and enable the iptables service because it is easier to set up.
The real "Libtards" are the Libertarians!
The radio is one of the things I look at when choosing a car, and I have decided not to buy a car based on the features and functionality provided by the radio.
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
"First they came for the slanderers and i said nothing."
I am missing Fedora without systemd.
> solves things that are simply not real issues.
I've managed UNIX servers for over thirty years, and systemd config files are a hell of a lot easier to manage than complicated shell scripts. I now manage servers with Puppet scripts, and the first time I added a custom systemd start-up daemon, I thought I was doing something wrong since it was so simple. It just worked.
The real problem with systemd is that Poettering has no experience managing servers so he just doesn't grok the importance of logging. Several times most months, I have a problem that would be trivial to fix if systemd didn't swallow the log message. We leave SELinux enabled on servers so we often make mistakes that break things, and systemd makes it hard as hell sometimes to troubleshoot. We often have to resort to using strace and looking through thousands and thousands of lines of output to try to find the problem that would have only taken a simple "tail /var/log/messages" pre-systemd.
Nice example, but I've noticed the guys working for me just can't grasp the concept of this:
systemctl start openvpn@server.service
The @ sign? server? .service? You can't use tab completion to find the name of the service like you can with /etc/init.d/something. Plus, it's confusing that Poettering decided to call the system systemd while the command name is systemctl. We use four different Linux distributions and six other UNIXes, so that small inconsistency turns into a big thing.
Yes, there were multiple votes. Debian's technical committee voted for systemd, OpenSuSE committee voted for systemd, Fedora (that was independent from RedHat at that time) adopted systemd before RHEL.
Oh, and had there ever been a vote for sysv-init?
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
You can always install another radio into a car. But it might not integrate with any of the things in the car, and it might not even fit into the dash these days.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
An example of real-world problem: crappy init scripts. With sysv-init a shutdown sequence can hang forever, for example. It's not a theory, it happened to me personally: https://lwn.net/Articles/61679...
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
Have you been to any car dealers in the last 10 years? The radio/nav unit is now highly integrated in control of far more than just the radio, and is not replaceable without losing other functionality (or replaceable at all).
Have you been to any car dealers in the last 10 years?
No actually haha. I should update my knowledge.
"First they came for the slanderers and i said nothing."
Badly-written code is badly-written code.
Yes, the service files may be easier to write, but how many people actually write init scripts?
The real "Libtards" are the Libertarians!
Debian voted to leave SysV and to pick systemd instead of Upstart. No RedHat influence.
Quite a lot of people need to write initscripts. Debian has several thousand packages with init files, and any of them might be broken in the same way.
And by the way, your argument is self-defeating. If you don't need to write init scripts then why do you care about systemd?
It wasn't a free choice. The fact that Gnome3 requires systemd was a significant influence.
The real "Libtards" are the Libertarians!
Wasn't Open/Free/whatever software about choice ?
I can understand that systemd brings some improvements.
In specific contexts.
For example, when your profession is sysadmin, when you have more than, let's say 4 or 5 servers to administrate, OK, may be systemd brings improvements over scripts. Real sysadmins are responsible of dozens, hundreds of servers.
What about other people like me ? I'm in computer programming since 1982, very well, but I'm no sysadmin.
A very kind friend told me once that, as a programmer, I'm a good sysadmin (I'm not sure I translated this properly from French), but I'm no sysadmin; first, I'm a programmer.
I mean that it's OK for me to have a Debian FW+many services at home, or to have one or two "shadow servers" at work to help me do my programmer job.
It's OK for me to install and configure services on a recent Debian, with systemd. As long as it's working. Magically.
What's not OK :
- few years ago, when Debian forced the change : it broke my system after an apt-get dist-upgrade. Before that, when a Debian had boot problems, I could handle them as long as I could dig in the scripts and trace the sequence. Suddenly, Debian replaced those scripts by systemd. At the first reboot, systemd was not pleased with something. The boot was interrupted with some cryptic error message, asking my to look at some logs, or run some new commands. What ? No ! No time, Internet connection broken, go to hell ! OK, I preferred to re-install a Debian from scratch, it was faster.
- this kind of problem still happens from time to time. Today, I'm afraid I still can not handle every situation. Most often : when a drive is missing, what will systemd do : a) timeout and continue ? b) timeout, put me in a shell that I can quit and continue ? c) timeout, put me in a shell, leaving me helpless because, with or without knowing what's wrong, I cannot (try to) correct the problem.
You could answer : RTFM.
Yes, but I have better things to do. I cannot read every man page of the world. And systemd manual is not small, and it needs practice. Reading alone is not enough.
So give me back the choice, give me back my scripts and let systemd to those who have time, or to those which profession it is to learn that monster !
And now that systemd has become a synonymous for Godwin point, let me ask : I've been told that systemd takes care of the network config by itself ? Or that it makes binary logs ? Seriously ? It cannot be, this is not the UN*X spirit, is it ?
Totof
Technically gconf already provides that opaque, central configuration DB. And like systemd, GNOME is maintained and controlled mostly by Red Hat employees. It's probably written in a language nobody important uses (Vala), too.
@thegarbz: I question the merit of systemd's "adoption". Every debate had about it was almost forced by systemd supporters, and systemd developers and supporters both are incapable of having a discussion about the social or political side of FOSS, especially in relation to their own projects. They'd rather pretend it doesn't exist or has no bearing on the merits of a project. Social merit is indeed a thing, and the systemd team fails horribly in that litmus test. No amount of plugging your ears and chanting, "NOT TECHNICAL NOT TECHNICAL" will make the shitty cult of personality surrounding the systemd project go away.
You're not wrong that people should move distros or build their own thing, but at the same time Red Hat forced this decision on people. Poettering himself has encouraged debate and "gently pushing" to put systemd on every distro. He's part of the GNOME Foundation, too, and pushed them to depend on logind. It's probably why Mozilla switched to PA, also. He's actively trolled Gentoo developers and generally has no respect for other projects. When he attends talks, he lacks the respect to sit in the audience and shut his mouth. Instead, he's taken over at least one talk with his aggressively argumentative attitude and disrespected both the speaker and the community organizers that made such talks possible by disregarding the standards for conduct. Every ounce of ire directed at him is deserved, and will continue to be deserved until he stops being a dick. The FOSS ecosystem is not a playground for egotistical developers, whether they're named Lennart, Linus, or Eric. The difference here is Linus knows his place and doesn't pretend to own userspace. He has very stringent rules on kernel development and will ream someone for breaking userspace. systemd simply doesn't have the same culture of careful engineers improving a system behind the scenes. When I get a new kernel, I get a nice script that will allow me to configure it to my tastes, and compiling has never failed, even with some odd or outlandish configurations. That's the sort of battle-hardened project the kernel is, and part of why it's so great is due to its strict QA culture. By comparison, systemd is a bunch of kids building sand castles with a bucket who then want to build sand castles all over the beach, even on top of other, more carefully built, sand castles.
We already have distros that simply won't work without systemd, due to how many components of systemd that they use that haven't been copied or forked. That's not what I'd call a step forward, considering how much functionality systemd as a project attempts to subsume. One day, systemd will be as old as SysV, and it already has a few stupid behaviors (such as not following symlinks for service files) that would make its way to a "why systemd is crufty" list 10+ years from now. With the breadth of endeavors that systemd intends to pursue, replacing it down the line will be extremely painful for users. Of course, the systemd team hasn't, and won't, think of that scenario because most of those "rockstars" will have collected their money and pursued an early retirement, so they won't have to deal with the realities of their software becoming old and crufty. That's the systemd motto, after all: "It's somebody else's problem."
Keep in mind it's taken a few years to have a mainstream-ish, .deb based distro without systemd. The rest are hobby/enthusiast distros like Slackware and Gentoo; basically projects that don't follow for the sake of following. Most distros have no real identity and instead just suck on the Red Hat teat. (see: Arch) It's taken a while, but with Devuan, anti-systemd users now have something they can use that isn't Gentoo or Slackware, both of which require considerable (but not wasted, imo) effort to maintain and aren't really for the average user.
I wish the Devuan team the best of luck, and will be trying their ISO in a VM.
What technical ground?
The discussion and the reasons for making the change were made public. Go read up on them.
Was there a vote or consensus reached?
Yes there was.
This is like claiming McDonald's is the best restaurant because they sold the most hamburgers last year.
Actually it's more like claiming McDonalds is the most suitable restaurant to feed people because it's the most convienient and fastest way to get food. They are called technical benefits. Systemd has many numerous of them. As does upstart, openrc, launchd, SMF, and all those other projects all launched to address the many short comings of sysvinit.
What is the deal with binary logs?
What's not the deal with them? It's a design choice. You want text based logging, systemd offers you that too through your logging daemon of choice with the only difference is that it has become more useful as you now have more options with how to log, where to log to, and can start logging earlier during the process.
Brilliant!
That sarcasm says a lot, namely that you don't have a clue and are just a product of an echo chamber. There's a reason why systemd is being widely adopted by core projects, and it hasn't got shit to do with Redhat or Poettering, and everything to do with it being the most feature complete and configurable of the many attempts to replace init.
Personally, I am still trying to figure out what real problem it solves.
Here's one: sysvinit is unable to manage services.
You don't see the short comings of sysvinit? The people who work with linux do. The people who create distributions do. Upstart, openrc, smf, ... systemd is just the latest and most successful in a long history of the attempts to address the many shortcomings of sysvinit. Hell Apple decided to use Unix as the core basis for their OS, what's the first thing they do? Launchd, a replacement for the dumb init system, and dumb is the only way to describe sysvinit which can trivially be confused as to the running state of the software it manages because ... it doesn't manage them, just writes a placeholder file and fires up a hundred line script.
Hundred line scripts. Yeah one of those for each program that needs to be started. Makes perfect sense to need a long bash script just to start Apache. I suppose 100 lines of scripts could be justified for managing many conditions in the system an OS may experience. Oh wait sysvinit has no event driven capabilities, and even if it did it would just screw up the running state as there's no dependency tree.
If you don't see what problems are being solved, you've never actually looked.
What is the deal with binary logs? I know AIX has them but why Linux? What's next, all the config files are stored in a flat binary database? Brilliant!
This sounds like a great idea. I propose we call it The Registry. We can even make tools to convert the binary into an almost-human-readable format. It will be glorious.
Wow, your "real world example" for "what does systemd solve" is literally a webpage that shows you how to disable the systemd built in firewalld and use the old iptables way of doing things. I think you might have given an ideal example of how most people deal with systemd and its ever growing host of half-baked replacements for established tools: Route around it whenever possible.
How is it that nobody has brought up that Debian still has sysvinit available, including for the upcoming Debian 9 "stretch".The release notes for Debian 8 "Jessie" included instructions for how to stick with sysvinit if you didn't want systemd. That was two years ago, and sysvinit is still an option in Debian today.
Do "init freedom lovers" include people that like systemd? It seems to me that Debian gives you that freedom, and Devuan takes it away so that you cannot choose systemd.
There are valid criticisms of systemd. I understand that some people who have tried it don't like it. That's fine, people can and should use what they want. However I often doubt that systemd haters have really given it a chance, bothered to learn the new technology at all, or explored the new things that are possible and easy with systemd.
Personally I think systemd is the best thing on GNU/Linux since package managers with dependency resolution.
It wasn't a free choice. The fact that Gnome3 requires systemd was a significant influence.
The choice was made long before any mention of the fictitious Gnome dependency on systemd. It IS ficticious by the way. Gnome has a dependency on one thing: something that provides a DBUS API. systemd-logind is now shipping on many systems so it made sense for Gnome to use it. Notice however Gnome is still available for all non-systemd systems, and BSD, and simply reverts to using gnome-session instead of systemd-logind. The whole dependency thing was just another out of control rage induced verbal vomit out of the echo chamber.
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
Do you still drive a car from the 90s? You would lose a lot of functionality in a modern car by attempting to replace the radio system. Shit my car is 14 years old and the radio is a headless box that provides power in, audio out, and a wiring loom to the CANbus that integrates with the dash, steering buttons, console display, central buttons, GPS system, etc.
Which organisation is the 400 lb gorilla when it comes to Linux development?
You can follow them and have an easy life. Or you can spend it on the treadmill constantly trying to peel out the shit you don't want, while they're adding it ten times as fast.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I test out quite a few Linux distros and even though I'm a systemd fan, I thought I'd give Devuan a try as a KVM virtual machine... something I would expect a lot of Linux users to do considering that KVM has been the native Linux kernel hypervisor since 2007. Anyhoo... no matter that I did, the partitioner would allow me to partition /dev/vda but when making the mount points it couldn't see anything because it was expecting /dev/sda. Wha, wha, what?
Doesn't seem ready for prime time.
Scott Dowdle
www.MontanaLinux.Org
Personally, I am still trying to figure out what real problem it solves.
I see systemd as the perfect compliment to Linux cgroups. It makes managing containers a lot better than how say docker does things. But if you like docker or systemd, I think we can all agree that the way containers are done now, versus sysvinit + chroot methods, is vastly better. However, if sticking with the old sysv stuff helps anyone sleep, then go for it. However, I remember doing the whole httpd inside a chroot and remember the headache it caused if one of your boxes out of a 100 was hung up and trying to hunt it down... systemd or docker make managing thousands of systems a whole lot easier.
Every time an American makes fun of us Canadians, I go to my hospital to have my feelings checked for free.
I don't know about the other distros, but it's almost silly to call what Debian did a "vote." It was a 2-2 tie and was over-ruled to force a pro systemd outcome. Considering how many people develop for and use Debian and that systemd was decided based on 2 or 3 people, it's hardly worth calling it a vote.
I've used systemd about 4 years or so now (mostly from Arch). It definitely has some pros, but the thing I don't like is Pottering himself. You should see some of the YouTube videos of him where he was pointed out to be wrong and instead of talking about the technical merits of the suggestion, he attacks the man. I've read a decent amount of his writing segments on posts and things and I will admit, he is smart, but he is seriously incapable of admitting when he is wrong.
When systemd was first being developed a lot of the bug reports were around problems with system crashes that resulted in corrupted and unreadable binary logs. They were all closed as WON'T FIX and some basically said "it's your problem."
systemd unit files, I will admit, are nice and clean. But if you actually look into the code and the systemd-itself unit files and dependencies it's really a nightmare waiting to happen. I think that's one of the biggest problems. A lot of the people commenting about systemd have only used it at the surface level. It would be like buying a used car that looks nice on the outside but never looking at the engine and realizing it's all duct-taped together.
Do you still drive a car from the 90s? You would lose a lot of functionality in a modern car by attempting to replace the radio system.
haha yeah, actually. I should get my knowledge updated.
"First they came for the slanderers and i said nothing."
That is an example of instantiated services which are a pretty handy feature.systemd.unit(5) documents this feature. If your 'guys' aren't into reading manuals for the tools they use, it's not that hard to figure out what's going on just reading the openvpn@.service file.
systemd is becoming standard, so there will be *fewer* inconsistencies between distros. One of the biggest drivers behind all the systemd hate seems to be resistance to learning new things, which is a shame because systemd is actually pretty cool.
Jessie + Wheezy = Jizzy.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Many of those issues did not require something so intrusive as systemd to solve. OpenRC solves most of them.
Yes, the init.d files are long, but so what? Most users never look at these files, let alone edit them and even for the creators of the files, they are rarely changed.
Most of the int.d scripts on my Gentoo system are less than 100 lines, with a lot of them 20-30 lines.
The real "Libtards" are the Libertarians!
Pop just came out of my nose.
You are confusing popular with best. You have poor arguments.
I found out about systemctl tab completion a few weeks ago and it's been very useful. Centos 7 server, if that matters.
Worst.porn.ever.
You failed to tell us that reason.
IMHO it's fine for desktops where fuckups only result in one person being unable to work but it's still very problematic for servers. I've still go a pile of stuff on CentOS6 because some commercial software vendors haven't figured out how to get their stuff to work reliably with Poettering's stuff.
LOL
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
You can always install another radio into a car. But it might not integrate with any of the things in the car, and it might not even fit into the dash these days.
There are adapters for all that fancy shiz that you'd probably actually care about. Just go to crutchfield and check for yourself. All those stereos integrate with the CANBUS these days (which is really stupid to do from a security standpoint, BTW), and there are adapters which allow after market devices to communicate on the bus.
You can usually install another radio into a car, FWIW. You don't need to get a completely new car.
Do you still drive a car from the 90s? You would lose a lot of functionality in a modern car by attempting to replace the radio system. Shit my car is 14 years old and the radio is a headless box that provides power in, audio out, and a wiring loom to the CANbus that integrates with the dash, steering buttons, console display, central buttons, GPS system, etc.
You do realize that there are CANBUS adapters for every single car on the market, right? At least, the ones in the US market. Plus who the hell wants their car stereo communicating with the other devices on the CANBUS? That's just poor security right there just so that you can do things like turn the stereo off when the car is off and the door opens.
Are they working on removing systemd from Stretch? Also what's the performance difference between the two? Can someone benchmark both startup systems on modern nVMe ssds on same hardware? I'd be interested in some comparisons.
Here's one: sysvinit is unable to manage services.
You should read the manual page on inittab - that is what it does. It is clear you do not understand what initd is capable of whilst you criticize it.
You don't see the short comings of sysvinit? The people who work with linux do.
Yes, it needs a complementary event management system. It also needs better examples of how to use inittab properly to run things like event managers. If inittab was documented properly and people understood how to use it I doubt that systemd would have come into existence at all.
Oh wait sysvinit has no event driven capabilities, and even if it did it would just screw up the running state as there's no dependency tree.
If you don't see what problems are being solved, you've never actually looked.
initd is a process manager, it is not an event manager. Event management should not be done by the init system, it should be performed as a spawned process that is abstracted from the process manager so that it can be restarted in case an event software dependency blocking on IO locks up the whole system.
Before you say cgroups, that would be part of the event system too.
That you cite the presence of an event management inside a process management system as a *justification* for systemd shows that people advocating for systemd have a really poor understanding of system design. If you can't write a shell script you have no business messing with system processes.
You failed to tell us that reason.
I am not your mother. The justification for the use of systemd in Debian was published by the core dev team and was many pages long. Go look it up yourself.
But you won't.
but it's still very problematic for servers
Half the justification came from servers. Something about actually being able to monitor the status of processes rather than blindly firing off one and never knowing if it continues to run. Heck many of the design features of systemd was built with servers in mind, such as reporting process failure combined with an adjustable attempted restart of the process, isolating logging to the process etc.
I've still go a pile of stuff on CentOS6 because some commercial software vendors haven't figured out how to get their stuff to work reliably with Poettering's stuff.
If a software vendor has trouble getting their program working on a system that provides 100% compatibility with sysvinit then I'm glad not to have anything to do with that software vendor. There is literally a configuration file with 5 lines required to get systemd to execute and monitor a traditional sysvinit system, and you can even blindly start a process and then ignore it in the dumb sysvinit way too.
Vendors not coding things in standard ways is not the init system's fault.
Many of those issues did not require something so intrusive as systemd to solve.
I only gave you one example. systemd is intrusive due to the very large scope of it's functionality and what it provides. This is also why it won technical challenges when various distributions adopted it.
Yes, the init.d files are long, but so what? Most users never look at these files
Users? It wasn't the users crying. Except for when it didn't work and you had to pour through 100 lines trying to figure out why you can run Apache on the command line but it fails to start by script (about the typical problem users experience). No what systemd provides is a far simpler interface for developers and distribution maintainers. None of this go to the developer's website and chose one of 5 100+ line long scripts which may or may not work depending if they are using the same version of your distro. Just a 5 line configuration file for systemd.
Most of the int.d scripts on my Gentoo system are less than 100 lines, with a lot of them 20-30 lines.
Congratulation. Maybe that's why Gentoo is still using OpenRC. On distributions that are popular and used by a far wider community than Gentoo, scripts can easily run into the 200+ lines.
Funny, I remember the whole httpd inside a chroot quite straightforward.
And managing containers with LXC, for instance, without systemd, works just fine as well. LXC did make managing multiple systems a whole lot easier. I do not see how this topic even relates to systemd.
For the record, I started using systemd in 2012 ( https://yeupou.wordpress.com/2... ), early enough for a project started in 2010, and, at that time, was baffled by bootup time.
I went away in 2015 after trying systemd on many boxes : some stuff just stopped to work, or did not work as I expected it to work and I decided it required way too much extra work for me without any massive benefit, considering that I am not starting up machines that often ( https://yeupou.wordpress.com/2... ). So I really do not share your feeling it made things simpler. Maybe it has many benefits, but the one I noticed were less important that the extra trouble.
> I don't know about the other distros, but it's almost silly to call what Debian did a "vote."
It followed the processes debian had established to decide in inter-maintainer disputes.
> It was a 2-2 tie and was over-ruled to force a pro systemd outcome.
Actually this is overly simplyfied:
* The numbers are wrong. The voting process came to a tie with upstart and systemd being in the running set. All other options were out at this point.
* The chairman broke the tie by casting another vote between upstart and systemd in favor of systemd. That is far from "over-ruling the decision".
* The whole discussion was about "default init system for Jessie". It is not about systemd being systemd-only.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 for all the details.
> [...] but the thing I don't like is Pottering himself. You should see some of the YouTube videos of him where he was pointed out to be wrong and instead of talking about the technical merits of the suggestion, he attacks the man.
I've seen those videos, too. If I were in his shoes, then I would not have stayed silent with some idiot on stage sprouts non-sense.
> I've read a decent amount of his writing segments on posts and things and I will admit, he is smart, but he is seriously incapable of admitting when he is wrong.
That is absolutely not my experience interacting with the systemd community.
> When systemd was first being developed a lot of the bug reports were around problems with system crashes that resulted in corrupted and unreadable binary logs. They were all closed as WON'T FIX and some basically said "it's your problem."
They did fix the log corruptions, they just did not add a binary to fix broken log files. The logic is to not mess with log files on disk (those should be read-only!) but to have logic to extract as much data as possible from the existing files in the normal tools.
> systemd unit files, I will admit, are nice and clean. But if you actually look into the code and the systemd-itself unit files and dependencies it's really a nightmare waiting to happen. I think that's one of the biggest problems. A lot of the people commenting about systemd have only used it at the surface level. It would be like buying a used car that looks nice on the outside but never looking at the engine and realizing it's all duct-taped together.
At least there is now one place to fix the mess: That mess used to be copied into each and every init-file! And each package update nicely overwrote your fixed init files for you.
That's odd, one of the reasons I like systemd is that it *doesn't* eat process output. With sysvinit, non-syslog output would end up on /dev/console, scroll up and be lost forever (especially relevant for headless servers). With systemd's journalctl I can easily review the output of any process together with its syslog logs.
There's plenty of things about systemd that annoy me but that ain't one.
Yeah sure, because the system hanging for no reason at shutdown or reboot or even at startup after a failed reboot (!) never happened to anyone using systemd...
Crappy units are as bad and as real as crappy init scripts.
If systemd is eating your log outputs maybe you should configure systemd properly. One thing systemd provides is more logging earlier and more consistently than the previous methods. But if you really need the old syslog, well systemd can output to that too.
that is because they felt entitled to tell the DISTRO they use for ZERO money what they should do - tough... its people that create the distro that decide. those that feel it was "rammed" down their throats should move and freeload on another distro which makes Devuan one of their choices.
so yes that is one of the points of open source, if you don't like it, fork it and/or make your own.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Redhat wouldn't have switched if it wasn't technically good enough. You write up a paper that challenges the technical merits of systemd and put it to RedHat.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
"This is specifically wrong. systemd was designed to implement specific features, not to replace init. " - can you provide a link where that was said? Have you read this ? http://0pointer.de/blog/projec...
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
maybe you should do some research into the reasons for systemd and how it benefits servers, particularly those that uses containers and VMs where they need fast shutdown and reboot instead of making things up. Any benefit to the desktop was an additional bonus.
You'll feel better when you find the reasons rather than rely on ignorant crap from trolls
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
To me typing 'journalctl --since 09:00 --until "1 hour ago"' is a lot easier than `journal -b0 | grep something | awk ....' and needs no testing
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
maybe you need to do at least some research because others think different. there are too many reasons for anyone to type them out here. if you don't research what it does better, you won't ever know and remain in "ignorance is bliss" camp. Don't rely on the trolls here and other forums.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
I can use tab completion on opensuse using your example, maybe i'm doing it wrong
machine:/home/sd # systemctl start openvpn-hit tab-
openvpn@ openvpn.target
machine:/home/sd # systemctl start openvpn
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
"I have a problem that would be trivial to fix if systemd didn't swallow the log message. " eh????? have you not found journalctl yet?
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
because no-one was maintaining console kit and Poettering actually wrote a work around library for Gnome to work without sysyemd which they decided not to use
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Is it to hard to get may people do not want something rammed down forcibly down our throats, with forceful upgrades without any warning, and the old and tried methods that were well tested and maintained for decades not presented in the automated installation - and worse - being discontinued from packages as they never existed.
Tell me again why you should not understand/get why such a rushed migration was forced to something many people does not agree with, when traditionally the power of open source/Linux was about choice?
Are you retarded or are you just daft?
I've got it on a few desktop systems, test machines and my home PC. I've seen it hang when it shouldn't (one USB mouse stopped it dead half way every time - so much for parallel init) and had all kinds of trouble trying to work out what is wrong on others due to the very poor logging behavior (which may get fixed some time, but not yet). I've been though plenty of documentation, bug reports and Lennart's smug blog about linux domination.
So I've got some reason to write what I've written even though you want to call me a liar after I've written something as mild as the post above. What's with the thin skinned fanboys?
Me, back on RH 6 or 7, once. That's RH, not RHEL.
It's so long ago I found the answer I needed in an actual paper book.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
let me send you either a pen and paper, slate and flint chisel, or do you prefer new when the older stuff was so simple
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Isn't that the job of nagios or similar and not an init system?
Also, many of the problems I have personally had with systemd are about exactly what you say it should be doing - trying to find out why something is not running and the logs not telling me if it's running or not. That justification seems a little odd to me until more improvements have been made and it's better than what came before it for that feature. Are you just repeating something you read somewhere?
Good advice. Pity you didn't follow it, Lennart.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
The culprit of the problem is not discussing the `new = better paradigm. A much better discussion is why the installation of several distributions, and namely Debian, does not allow us to both select system and SysV, and each one will install what it does see fit effortlessly.
You can choose your own web server ; nobody forces Apache upon you ; likewise you can choose your DHCP software, or your DNS server ; in pretty much any solution you can choose alternatives; gosh nowadays you can even chose in Debian between Linux and a FreeBSD kernel....so why not an easy choice between systemd and other competing systems that were already implemented for decades.
As I said, the indignation of most people is that Debian and developers went out of their way to impose systemd to everybody, as if there is some ulterior motive for it. (NSA backdoors is an interesting conspiration theory).
The fact that most of the systemd proponents seem to inconveniently ignore that nobody likes to be sodomized, it yet another monumental damning thing. Why for instance, why in a thread about Devuan, about choice, there will be idiots whining that they do not understand the systemd "hate"...the fact is they do not accept nor phantom that in open source there can be a choice.
The choice for me is clearly *BSD...thanks for all those years and for betraying us, Debian.
So long, and good luck.
I don't hate the idea, just the implementation leaves a bit to be desired and fucking stupid ideas growing out of an urge for total linux domination (like killing all of a users background processes) keep on cropping up due to inexperience in the project and an unwillingness to take advice.
There are still a lot of servers around the world stuck on RHEL6 and CentOS6 - the slow software vendor that is messing me about is not alone. People are having trouble with the change, you may dismiss them as idiots but there are aspects of this project that are causing real problems.
You can find the reasons here
It is good for servers with complicated boot dependencies such as a clustered fs on top of iSCSI which before systemd, used to require me to hack the init files every time. Systemd was designed to solve problems on servers and that was it's primary justification. The fact that is makes desktops boot faster was a happy side affect, despite the meme.M
CentOS did the Systemd transition badly, Debian's was more smooth with the exception that I wish they hadn't abandoned /etc/default at the same time.
Let me guess, when you first found out that MySQL database files are binary, you freaked out and moved your data to CSV format. Later that day you moved your Mediawiki installation to Dokuwiki. On the more serious note, did you know that you can still log stuff in plaintext with systemd?
You're comparing the benefits of having a tool dedicated to extracting and displaying log entries to having to roll your own out of tools that follow the Unix philosophy.
The fact that you're so confused about the task says a lot.
I've seen it hang when it shouldn't
Oh no a bug quick burn the entire computer and shoot every programmer in sight.
So I've got some reason to write what I've written
Okay you're right. So let me chime in: All software is bad, we should go the way of the Amish, they NEVER had a bug.
Normally I'd finish with some comment about sarcasm, but this isn't sarcastic. Something as stupid as what you just wrote simply needs to be repaid in kind.
Arrogance, inexperience and general stupidity are plenty of explanation. This is not the first time people think they can do better and ultimately fail. In fact, that happen all the time in the tech-world. Usually these "improvements" get ignored in the Linux-world tough.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
decontaminated from Poettering-infestation
If you wanted an OS with all the intelligence and capabilities of Linux in the 90s, why not just install a version of Linux from the 90s.
Classical fallacy. Just shows you are stupid. People like you are the ones that replaced water with Gatorade in "Idiocracy".
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Who cares? BSD baby...
I advise you researching a little better how tab completion works.
Usually something is expected to be superior in some way to the thing that replaces it when the cost of keeping the old thing is negligible.
I'm just somewhat pissed off that it's been rushed out unfinished and we have to put up with beta software due to Lennart's ego. However it appears that for some reason expressing such an opinion is forbidden - why? What's with the mindless fanboy shit? What's wrong with you today?
I don't actually agree that systemd actually improves on many of those points (and some of it is just bald opinion that I disagree with), a lot of it is really just a description of init systems in general, but it's good to get something other than insults and cheerleading.
Here's a few parts (but I could pick on a dozen):
Considering how incredibly verbose the commands are - sorry - nothing close.
Is that a joke or is it an aim for the future, because it's like a black box to work around now. Sure there are commands for that sort of thing but they don't seem to actually report anything when you need it.
Who wrote this incredibly unprofessional shit?
Come on kids - read it - and if you actually know something about the topic compare what is written with what you have observed instead of just blind cheering or ridiculous fanboy insults.
Indeed, and RHEL before them. I have not had so many linux boxes hang and not tell me why since before 2000.
As the proverb goes, one lesbian's bug is another transgender's feature.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Sounds more that the applications that you use need options on startup to enable logging and that whoever created your unit files forgot to add these options while there are present in the old sysvinit files. Could also be that you have new SELinux templates that denies the syslog messages from being sent by the applications in the first place. All that I know is that systemd does not swallow any logs, in fact it catches far more logs than sysvinit ever did since it also catches output from stdout and stderr which few other init:s do (upstart did to some extent).
thats what tools are written for, speed and consistency. whats the point of continually re-inventing the wheel? awk, grep etc are also dedicated tools to doing a job but when there is a better way, you take it or you might as well go back to pen and paper.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
he took the advice, he made his own and it got accepted
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
whats poor about its logging? it far more comprehensive than any other system, journalctl is your friend. You may have a had one bug, so what, bugs happen. No need to think the sky is falling over one bug
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
it is far superior to what was before otherwise it wouldn't have been adopted. Stop going on about the "fanboy" stuff especially when you say things like "beta software due to Lennart's ego", why does someone have be accused of being a "fanboy" when responding to "the sky if falling because of LP or any of his software" , release often has always been the process to get stuff out, sometimes it has bugs.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Yeah, and my point was that a tool could be written to filter any other log format as well. It would be maybe 10 lines of Perl, if you went for legibility over terseness. Your comparison had nothing to do with binary logs or anything else about how systemd stores logs, and everything to do with what tool ships with the logger.
Systemd won on all technical ground.
No. Systemd won on political ground. The technical "win" is had was demonstrating that it was a technically workable solution, not that it was a technically superior solution.
All those stereos integrate with the CANBUS these days (which is really stupid to do from a security standpoint, BTW),
Why would you want to do that? What benefit do you get?
"First they came for the slanderers and i said nothing."
You're not making any sense. Try later after you sleep Saturday night off.
Let them believe you have to wait for months for treatment so they feel better.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
If you brought it back, why the old debian? Never mind, I hope the 50 people world wide that aren't smart enough to handle systemd use it and leave everyone else alone now. You have your toy now, go home and play by yourself.
You should be old enough to know about office politics. Office politics at RedHat is how this happened and not the superiority of the solution to the "problem" that all the init software was not under the control of a single person.
It's still very patchy in what it logs and that makes solving problems related to services much harder on CentOS7 than on CentOS6.
Because _there is life beyond Linux. And if you were not and idiot, you know they hit the road at the same time. Google_ for NetFlix, trivago and FreeBSD, you might learn _something.
Well _why having sex with girls? The new fashion is being gay and taking it up your _ass. Go_ for it.
Err systemd and firewalld have nothing to do with each other
I suggest you do a modicum of research next time before spewing such obvious bullshit
That's the same response this question often gets: " there are too many to list". But what I see is that specifics on the real advantages of systemd are missing. No one wants to elaborate on what these "too many to list" advantages are.
It's all hand waving without specifics. Why should I not think that the claimed advantages don't actually exist?
The real "Libtards" are the Libertarians!
When systemd was first being developed a lot of the bug reports were around problems with system crashes that resulted in corrupted and unreadable binary logs. They were all closed as WON'T FIX and some basically said "it's your problem."
Since there were many of these bug reports you'll be able to give a link to one of them, right?
By the way, don't bother giving a link to bug 64116 without reading comment #3.
Watch this Heartland Institute video
Keep in mind it's taken a few years to have a mainstream-ish, .deb based distro without systemd.
Nonsense. You can't get more mainstream-ish than Debian and Debian is a systemd-free distro if you want it to be.
Watch this Heartland Institute video
trying to find out why something is not running and the logs not telling me if it's running or not.
What does
systemctl status service
show? Why would you look in the journal to see if something is running?
Watch this Heartland Institute video
It's still very patchy in what it logs
It logs whatever you ask it to log. I have seen problems caused by people writing units and /etc/init.d files that specifically asked for no logging to be done, which then gets blamed on systemd.
Watch this Heartland Institute video
systemd is Roko's Basilisk.
Heh. Somebody modded you troll. Boy, are they in for a surprise.
Watch this Heartland Institute video
service httpd restart
systemctl --restart httpd
that's annoying.
It's also wrong. The systemd command would be
systemctl restart httpd
Of course you could also just do
service httpd restart
and it would work as before.
Watch this Heartland Institute video
Here's one: sysvinit is unable to manage services.
You should read the manual page on inittab - that is what it does. It is clear you do not understand what initd is capable of whilst you criticize it.
You are both right. sysvinit is unable to manage services, but initd is. The problem is is that sysvinit is not initd. sysvinit is a festering pile of shell scripts that ignore almost every interesting feature of initd.
Watch this Heartland Institute video
I feel like most of the complaints against systemd are little more than graybeards complaining that something is different.
Very few of those complaining have grey beards. Jaromil, for one, doesn't.
Watch this Heartland Institute video
The fact that most of the systemd proponents seem to inconveniently ignore that nobody likes to be sodomized
Nobody? You need to get out more.
Watch this Heartland Institute video
Ah yes. Blame the user despite missing features. Just like Lennart.
What are the missing features?
What has not been logged that should have been logged?
Why?
Be concrete. Put up or shut up.
Watch this Heartland Institute video
Something in a log about specific services stopping and starting would have been nice but it wasn't happening on those occasions - stuff not implemented yet it appeared.
Because a new project implementing the features of another that it aspires to replace is normally the done thing.
As for put up or shut up - don't take it from a biased person like me just look up the bug reports.
As for put up or shut up - don't take it from a biased person like me just look up the bug reports.
Which bug reports?
Watch this Heartland Institute video
The project has a website. Perhaps you should stop wasting your time attacking people on the internet by taking a contrary view about a topic that you appear to know absolutely nothing about and instead actually find out something about the topic.
So you're making shit up like I thought.
Bye.
Watch this Heartland Institute video
Look for yourself instead of taking it from a biased source such as myself - it was not born perfect as you seem to be arguing. Oddly enough people actually have had less than a perfect experience with it.