Debian Project Votes 'Systemd But We Support Exploring Alternatives' (debian.org) 203
DevNull127 writes: The Debian Project has announced the results of its vote on how much to support non-systemd init systems. The eight options voted on included "Focus on systemd" and "Support for multiple init systems is required" (as well as milder choices like "Support for multiple init systems is Important" and "Support non-systemd systems, without blocking progress.") The winning option?
"Systemd but we support exploring alternatives."
Here's the position for the Debian project described by that option:
The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features.
Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.
Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.
Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.
"Systemd but we support exploring alternatives."
Here's the position for the Debian project described by that option:
The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features.
Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.
Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.
Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.
Unix philosophy died on systemd sword (Score:5, Insightful)
Re: (Score:2, Insightful)
Another way of looking at it is that some things work well as highly integrated systems, e.g. the Linux kernel. Many other systems have a similarly powerful and integrated init/service management system.
Not saying Lennart isn't an arse or that systemd isn't without some major flaws, just that the "Unix way" might not always be the best way.
Re:Unix philosophy died on systemd sword (Score:5, Insightful)
"just that the "Unix way" might not always be the best way."
In this case however it is. A monolithic binary is a large attack vector and subject to many MANY bugs as we've discovered. Plus it has yet another config system instead of powerful shell scripts. Init is small, lean and pretty much bulletproof now. Ok , systemd might boot faster but when servers are generally rebooted on the timescales of months or years who fucking cares? And my 10 year old laptop running slackware still boots in 20 seconds so The Desktop is NOT a valid argument for quick boot times.
Re:Unix philosophy died on systemd sword (Score:5, Insightful)
To add to your points. I prefer a system to boot in 21 seconds with all the services started than it boots in 20 with services not booting and wasting hours figuring out why only to go through it again with the next upgrade.
Binary log files is a stupid default. It works well when things are working well but if your system is crawling because of an issue wasting resources in reading the logs does not help things along.
Yes I know I can change it but it happens on system I'm not responsible for.
Re: (Score:3)
Binary log files is a stupid default
You should complain to your package maintainer. Ubuntu defaults to outputting to syslog in plain text allowing you to ignore the binary ever exists.
A lot of people blame systemd for the way their distribution maintainer set it up. Logging is a prime example of this.
Re: (Score:2)
I am a hacker. I r00t your system. Guess what I am going to do first? Go to /var/logs and modify the text logs to hide my presence.
Plain text logs are a stupid idea for security
Re: Unix philosophy died on systemd sword (Score:3)
Systemd isn't a monolithic binary. It's a whole suite of tools; there are dozens of binaries. Many are replaceable or designed in such a way they can be. It exclusively uses text files and symlinks and the file system for configuration. Unix philosophy.
Semi trucks and motorcycles are both good (Score:5, Interesting)
For me it's not necessarily about what is *best".
Windows has its place, Linux has its place.
Much like sometimes you need a semi truck, sometimes you want a motorcycle, sometimes a sedan. I don't want drive a semi to work every day; I don't want to use a sedan to move to a new house.
When I want Windows, I'll use Windows. When I want *nix, I use *nix.
If Kawasaki put a fifth wheel on a motorcycle, we'd call that "doing it wrong". A Lamborghini shouldn't have a tow hitch, Linux shouldn't have systemd.
Re:Semi trucks and motorcycles are both good (Score:4, Insightful)
Linux shouldn't have systemd
What is Linux? To continue your definition Linux is nothing more than a road vehicle nothing more, nothing less. The way you use Linux is completely different to the way I use Linux. The way I use Linux on my server (semi-truck) is different to how I use it on my desktop (daily commuter), and different to how I use it for embedded programming (kawasaki motorbike).
Re: (Score:2)
> The way I use Linux on my server (semi-truck) is different to how I use it on my desktop (daily commuter), and different to how I use it for embedded programming (kawasaki motorbike).
One thing that allows flexibility is that you have parts you can put together in different ways. Linux isn't an RTOS, it's not QNX - a bike. It's kinda like an F-150 or maybe a flexible and configurable. You lose the ability to uwe it for the embedded programming or in a router when it's dependent on a 250MB init blob.
Re: (Score:2)
> The way I use Linux on my server (semi-truck) is different to how I use it on my desktop (daily commuter), and different to how I use it for embedded programming (kawasaki motorbike).
One thing that allows flexibility is that you have parts you can put together in different ways. Linux isn't an RTOS, it's not QNX - a bike. It's kinda like an F-150 or maybe a flexible and configurable. You lose the ability to uwe it for the embedded programming or in a router when it's dependent on a 250MB init blob.
Systems or openrc or whatever Solaris uses these days is much needed in a modern especially cloud like environment. Init was great with a big refrigerator sized DEC mini computer in the 80's which had maybe 80 utilities. Not clustered, cloud based, dynamic nodes running like a fabric where an image can be shutdown on a blade, then restarted in Amazon E3 elastic cluster.
I heard the same gripes on DHCP being a cheat and static IPS only were the way to go in the mid 90s by grayhairs. Laptops on the go changed
Re: (Score:2)
> Explain with static init how this won't become a support nightmare FAST?
I do that all the time and I've been doing it for many years.
The service in charge of the network adapter (currently Network Manager) notices that the interface is down and brings it back up. Note this is precisely the same as walking out of range without putting it to sleep. That has absolutely nothing whatsoever to do with init.
Agree. (Score:3, Insightful)
In my opinion, the primary selling point of Linux is not its similarity to Unix, but it's freedom. This logically includes the freedom for communities to build distros around whatever philosophy they like.
There are always trade-offs. Other posters have pointed out how large multi-purpose binaries present unique attack vectors, maintenance challenges, and configuration challenges of their own. Obviously, this is true, but this change in the nature of challenges faced also reduces the net number of challen
Re: (Score:2)
Can you support your assertions in any way? For example, one service failing means you read one log for errors, not a giant log with many sub-services logging info that you don't care about.
And if you have the same configuration options, you have the same configuration to do. One place or many places, there is no more work unless there are more options.
Your turn.
Re: Agree. (Score:2)
Sounds like better log-reading tools are what is actually needed. Log everything, retrieve what you need later.
Re: Agree. (Score:2)
We tried that. Then the disk filled up.
Re: (Score:2)
My statement about easier maintenance was intended as theoretical. It is, in theory, possible to simplify troubleshooting and maintenance by taking a cluster of independent processes and unifying them into one streamlined process.
The actual benefits will depend on how well that unified process is actually built, and how troublesome the swarm of small processes has actually been. That mileage may vary, and I don't have data to back up either position in the specific context of Systemd. But I can see how,
Re: (Score:2)
With fewer components involved, there are fewer things to configure, and fewer points-of-failure to know about and examine during troubleshooting.
I don't know what world you live in, but that is dead wrong unless said fewer components also have fewer options to configure. You might have to open fewer config files, but assuming feature parity there will be the same amount, if not more, config keys that will have to be personalized on a per use case basis. The other problem with that is the simple fact that fewer points of failure means there has to be logic built in to the mentioned fewer components on what constitutes a hard failure in various fa
Re: (Score:2)
Re: Unix philosophy died on systemd sword (Score:3, Interesting)
Re: (Score:2, Insightful)
Indeed. But Debian and the other failed Linux distros that do not get the basics of the Unix philosophy are not without alternatives. Enough people still remember that KISS is king if you want a reliable and secure system and enough people still learn that every day. If I want Windows, I run Windows. If I want Unix, I do most definitely not run systemd.
Re: (Score:3)
If I want Unix, I do most definitely not run systemd.
Of course not! systemd requires Linux, and Linux is not, nor has it ever been, Unix.
Re: (Score:2, Insightful)
Bullshit and you know it. Of course I am talking about the API here. So for terminology-nazis like you: "Unix -> Unix-like".
Re: (Score:2)
If you're talking about APIs, you should have said POSIX (or POSIX-compatible).
But that's completely orthogonal to systemd or init systems, of which there is no UNIX/POSIX standard, much less any sort of standard API for that functionality.
Re: (Score:3, Insightful)
Ah, more deranged nit-picking. You have any actually good arguments? Obviously not.
"Unix-like" does obviously include Unix-philosophy. Or at least it did until a large part of the Linux world began to degenerate.
Re: (Score:3)
Ah, more deranged nit-picking. You have any actually good arguments? Obviously not.
"Unix-like" does obviously include Unix-philosophy. Or at least it did until a large part of the Linux world began to degenerate.
Wait, I thought you wanted to talk about APIs instead? Way to move the goalposts after being called out again.
Folks that are sloppy with their language are sloppy with their thinking. You're not going yourself any favours here.
Re: (Score:2)
Actually, I have zero desire to talk to you now. You obviously have some mental issue and believe _you_ set the standards here out of some megalomania thing. You do not. Nit-picking like you do is just some dominance thing. Find somebody else to play with.
Re: (Score:2)
Or at least it did until a Unix got a GUI.
FTFY. It's kind of amazing that people complain about systemd not being Unix like while praising X. It's an incredibly stupid double standard.
Re: (Score:2)
Especially Emacs too from these same users. We should all just use Ed and cat like the 1970s intended
Re: (Score:2)
Bullshit and you know it. Of course I am talking about the API here. So for terminology-nazis like you: "Unix -> Unix-like".
Systemd doesn't require unix, it requires Linux very specifically.
Re:Unix philosophy died on systemd sword (Score:4, Insightful)
Its as much unix as any other flavour these days. Just because it hasn't got the official Unix stamp means nothing any more. It IS the de facto unix system in the 21st century.
Re: (Score:3)
Of course not! systemd requires Linux, and Linux is not, nor has it ever been, Unix.
Several flavours of Linux have been certified under the Single UNIX Specification. That is literally the definition of UNIX.
Re: (Score:3)
I am very interested to know why you call Debian a "failed" Linux distro. What metric are you using to determine success?
Because as far as I can tell, it is one of the most popular. It would seem to me that popularity (as in, number of people actually using it or its derivatives) would be a major metric of success. A perfect solution that nobody uses doesn't do anyone any good, whereas a "good enough" solution that everyone uses can change the world.
Here [howtogeek.com] is one random article I found listing Debian among
Re: (Score:2)
I think it's kind of a stretch to call Debian a failed distro....The number of others that use Debian as the upstream basic master is eye-watering, including the most popular ones of all time. Need I list them? It's pretty much all but that failed one recently bought by IBM - I guess they thought it YUMmy.
Re: (Score:2)
Failed distro? Debian is probably the most popular distro on the planet. Certainly it's the most widespread if you count derivatives which depend on it, such as Ubuntu. Yeah it's failed alright, just like all the other linux distributions out there. To say nothing of Android, which itself does not use anything like init scripts.
Let's all stop using these politically-derived and meaningless epithets like "failed" when describing something we simply don't like or don't agree with.
Re: (Score:3)
Some people forgot Unix was originally designed as many small tools that do one thing really well
No... Unix was designed to be simple to implement. Everything else -- functionality, consistency, correctness, ease-of-use, error handling, etc etc -- was secondary.
It so happens that it's simpler to implement small tools that "do only one thing". Mind you, that's not the same as "doing one thing well", as that tends to require a far more complex implementation.
Re:Unix philosophy died on systemd sword (Score:5, Interesting)
And yet we have many examples of services running that do one thing well and are complex at the same time. Systemd obfuscates data, hides settings and doesn't initiate a startup well. Just one example is a Fedora system that just doesn't want to keep Apache enabled. It might work for a little while then on update/upgrade will just tank it. Why? I have other system that go through 10 years without a hiccup. The only difference is that they don't run systemd. What is the point of systemd?
Re: (Score:2)
And yet we have many examples of services running that do one thing well and are complex at the same time. Systemd obfuscates data, hides settings and doesn't initiate a startup well. Just one example is a Fedora system that just doesn't want to keep Apache enabled. It might work for a little while then on update/upgrade will just tank it. Why? I have other system that go through 10 years without a hiccup. The only difference is that they don't run systemd. What is the point of systemd?
So you're seriously saying that the two systems are completely identical except for systemd? Bullshit -- because the other one isn't Fedora, which means there are a _lot_ of differences between the two systems.
Meanwhile. You did an update/upgrade, and something broke. Have you considered that perhaps there's something wrong with your Apache configuration? Maybe you should oh, examine the apache logs to see why it's terminating before blaming the messenger?
Re:Unix philosophy died on systemd sword (Score:5, Informative)
And yet we have many examples of services running that do one thing well and are complex at the same time. Systemd obfuscates data, hides settings and doesn't initiate a startup well
What data is being obfuscated, and what settings are being hidden? And what "startup" is not being initiated well?
The only "data" that systemd has any control over is system logging, I have a hard time seeing how one could call it "obfuscated" given that you can just forward everything to a bog-standard syslog daemon of your choice (and that's also the default for some distros). Meanwhile, even in a pure forwarding configuration systemd-journald provides a better logging experience as it captures and reports system management messages and *all* output of a given process (ie stdout, stderr, and syslog) instead of just what the process chooses to log.
As for configuration -- All of systemd's settings are in plain-text files that live in a single filesystem location, share a common declarative ("ini file") syntax, and are extensively documented, both online and in accompanying man pages. Which is a far cry from the mess systemd displaced.
All startup problems I've personally run into are due to systemd actually respecting configured dependencies and catching/reporting errors that the prior mudball blithely ignored..
Re: (Score:2, Informative)
Systemd obfuscates data
No it doesn't. It provides more verbose logging that systems which came before it. If you're talking about binary logging you're free to output those to syslogd just like systems that predated systemd with the added benefit of additional verbosity during the boot process.
hides settings
Not sure what you're talking about. There's no settings in the stable release that aren't described in the manual.
doesn't initiate a startup well
Your opinion. My opinion is that a startup that doesn't initiate well is usually PEBCAK resulting from failure to RTFM.
Just one example is a Fedora system that just doesn't want to keep Apache enabled. It might work for a little while then on update/upgrade will just tank it. Why?
You tel
Re:Unix philosophy died on systemd sword (Score:4, Informative)
Except multiple people have reported that messages haven't reached syslog. There was no need to integrate logging nor to make binary logging the only option for systemd. All they needed to do was make a new syslogd replacement with binary log format support. That would have been the Unix way. Systemd is not the way.
Re:Unix philosophy died on systemd sword (Score:4, Insightful)
Re: (Score:2)
Which other system are you talking about? This is not systems. It is the retardedness of Linux rewritting config files as it's static in nature. FreeBSD for example doesn't have this problem by design and Linux band ABIs so it will always break unlike a real os like Solaris, FreeBSD, or Windows where drivers just work
Re: (Score:3)
I just don't buy your argument. I don't think anyone can seriously argue that the sysv init system is true to the unix philosophy. It's a mess of hard-to-debug scripts that try to do everything and where everyone reimplements the wheel, often poorly. Many times I've had to put a "set -x" at the top of a complex init script just to help me figure out why it was failing, often after running for years. In those cases, syslogs often weren't enough information either. Certainly this fails the "many small to
Re:Unix philosophy died on systemd sword (Score:5, Informative)
" I don't think anyone can seriously argue that the sysv init system is true to the unix philosophy. It's a mess of hard-to-debug scripts "
No, no it is not. It is a small and simple daemon that launches executables, including scripts. The scripts are not part of init.
"Many times I've had to put a "set -x" at the top of a complex init script just to help me figure out why it was failing"
As opposed to having to literally use a debugger to figure out why a daemon is not correctly being run from a unit file by systemd. Clearly that's better! Wait, what?
"Everyone here talks like systemd is a giant piece of cast iron. But it is actually many little pieces,"
All of which are both dependent on systemd and interdependent, so they cannot easily be swapped out, or used without systemd, which is not the Unix way.
Re: (Score:3)
Re: (Score:2)
Some people seem to think systemd is a giant monolithic daemon that does tons of unrelated stuff all in pid 1. It isn't. It's a collection of programs, each for a specific purpose, designed to work together through interfaces. There are some questionable design choices (l
Re: (Score:2)
Re: (Score:3)
systemd isn't that big. Remember when you hear someone talking about how systemd sucks because it configured their DNS incorrectly, they're not actually talking about systemd, but one of the sister tools that's part of the same project and is branded as 'systemd-whatever'.
Well it's not hard to create a puzzle where every piece only fit "sister" pieces. Oh I'm the systemd-network daemon but I need to talk to the systemd-hardware daemon if the current systemd-user has got the systemd-rights to access the systemd-credentials at this systemd-time to authenticate to this systemd-share on that systemd-network. I might be heavily biased by /. but it's my impression that the systemd philosophy is basically we'll set off in a direction we think is a good idea, try to keep up. There'
Re: (Score:2)
Now we get this one size fits all do everything monstrosity.
No we don't. You're confusing the overarching group of programs known as systemd with the init system of systemd. Systemd as in init system is JUST an event driven init system, nothing more, nothing less. The fact that there are other packages such as systemd-networkd systemd-journald systemd-logind etc etc doesn't make systemd any less of the "unix design" as the underpinnings of the graphical subsystem that every Linux desktop depends on.
Except for wayland of course, but even though that does one thing we
Re: (Score:2)
I do hate systemd as much as you. I also like the unix philosophy and I probably know its gospel as much as you do. It would be unnatural and surprising that it would loose ground to a lesser adapted philosophy.
You have to realize that any ideology is only relevant during specific periods of time. Any ideology can degenerate into a dogma if it is enforced at a time where it is not relevant. Any dogma can be made sound again if the context is right.
Ideas are not sound in a vacuum ; their relevance has to be
Re: Unix philosophy died on systemd sword (Score:2)
I will concede that systemd utilities are too tightly coupled.
Re: Unix philosophy died on systemd sword (Score:2)
Establishing dependencies is pretty damn important, and so is a consistent config "language".
Still, systemd has as many flaws as alternatives so there's not much to argue about really.
Why systemd? (Score:2)
There's been much discussion about systemd, the cons, philosophical dislike, etc. I haven't run it nor dealt with it, so I don't directly know. But from what I read, I'm not in favor of it, nor will deploy any Linux systems with systemd.
Q: Why are people, like Debian maintainers, in favor of systemd?
Re: (Score:3, Interesting)
I have no idea. Probably a mix of "new = good" dementia, an aggressive and utterly despicable marketing campaign by Red Hat and an influx of too many people that learned coding on Windows and hence never developed reasonable standards.
Re:Why systemd? (Score:5, Informative)
too many people that learned coding on Windows
It's pretty much this. If you read some of the proposals for systemd when it was still under development, two things stand out:
Re:Why systemd? (Score:4)
too many people that learned coding on Windows
It's pretty much this. If you read some of the proposals for systemd when it was still under development, two things stand out:
Indeed. The whole thing is basically a kind of hostile takeover to force a philosophy change by people that do not understand the Unix philosophy or what a Unix-like kernel actually can do. Windows never got system management under control, the registry is an incredibly convoluted mess. And those process numbers may be an issue under Windows, they are no on an Unix-like system.
Re:Why systemd? (Score:4, Insightful)
Because systemd is a home of total mess half-baked "closed: won't fix" hacks designed, implemented badly and accumulated over years instead of decades?
Re: (Score:2, Insightful)
Q: Why are people, like Debian maintainers, in favor of systemd?
Because, unlike you, the Debian maintainers have seen how systemd (and sysvinit, upstart, and the various alternatives) works in the real world, have read the documentation, and have come to the conclusion that it the pros vastly outweigh the cons, both as end-users and as distribution developers/maintainers?
Re:Why systemd? (Score:4, Funny)
Sure, that'll be why sys admins in large companies running major linux installs all give systemd the thumbs up... oh, wait...
Re: (Score:3)
Sure, that'll be why sys admins in large companies running major linux installs all give systemd the thumbs up... oh, wait...
RHEL/CentOS, Debian, [Open]SuSe, and Ubuntu all default to (or exclusively use) systemd and between them, comprise the overwhelming majority of Linux systems deployed by large companies.
Re:Why systemd? (Score:5, Insightful)
Re: (Score:2)
I mean, I'm a sysadmin in large company that favors systemd over sysvinit or others.
This is not really correct. Large Companies want a stable commercial entity to support them, and they went with Red Hat, maybe a few with SUSE due to their support. RHEL and SUSE both use systemd, and the bean counters do not care what init system is being used. So they got systemd without deciding to use it.
BTW, you will never see a fortune 500 company running another distro on their critical infrastructure. You may see others in use by a person or two without the knowledge of IT, but if the get caught
Re: (Score:2)
So, what you're saying is "I find bash hard and don't want to learn the simplest aspects of how bash works, so instead I am going to remain ignorant of how the system actually works and write config files because I'm really a windows admin at heart". Thanks for clarifying. And that attitude is why skilled and knowledgeable sysadmins make huge bucks but I can't get most applicants to explain the simplest concepts re: bash, dns, file system management, backups, tcpip, udp, apache or any web server of their choice, or pretty much anything a competent mid level admin used to know. If there isn't a GUI, they can't do it. I'd hire all the guys writing those guis but there's only a handful of them to go around.
I am not an Unix admin and even I know how ignorant that is. Bash is great for non event typed events. Useless to respond to changes as they happen. Explain with bash how to shutdown a an OS. Clone it and have one run on VMware and the other Amazon E3 elastic without knowing the future configurations before hand?
Re: (Score:2)
I know you are trying to be funny, but yes that is the reason.
The 4 fulltime system admins I personally know, really prefer systemd. None of them prefer Windows.
Re: (Score:2)
They've not issued the ringing endorsement you've assumed. I believe they're decided to invest their work elsewhere.
Re: (Score:3)
I think it may depend on your use case. I haven't seen a single advantage to systemD, and I've encountered a few mild drawbacks. (E.g., coded system logs. Won't fix the translator.) Others have encountered much worse problems, all the way up to totally borked systems with no data recovery. (Well, that was in the early days. I haven't heard that one recently.)
So for me there is no, zero, advantage. The drawbacks haven't been sufficient for me to switch distributions. But they've been enough that I ke
Re: (Score:3)
I'd love to see the age spread on the votes for systemd. Not Invented Here syndrome has been getting worse. They didn't invent the old system therefore its bad and needs improved.
Re: (Score:2)
I can imagine that if you'd invested the amount of time required to fully understand the sysvinit you wouldn't want the younguns to not have to suffer the same thing.
Re: (Score:3)
They like systemd because they eliminate init scripts, and they find shell scripting difficult.
Yes, that's right, point-and-clickers who find shell scripting difficult are maintaining Debian.
Re: (Score:2)
Re: (Score:2, Insightful)
Like clicky-clicky interfaces, systemd makes easy things trivial, and moderate or harder -- impossible. That's a win for MSCEs but not for me.
Re: (Score:2)
So you don't like a system that can be fixed in a few minutes with a text editor over a console session?
I've tried using some projects like Open Media Vault that rely heavily on systemd. They're immature from a software development point of view. The software breaks and requires running repair programs to right them again.
The further we get from almost military-style documentation as the original Bell Labs UNIX started with, the less reliable and harder to maintain the systems are getting. The documentat
Re: (Score:2)
Great so when I hack into your system I can go to /var/Logs and edit the config files to hide my presence and changes. Brilliant
Re: (Score:3)
If you don't know the difference between a log file, and a config file, I'm not particularly worried about you hacking in to my system.
Re: (Score:2)
Yes, that's right, point-and-clickers who find shell scripting difficult are maintaining Debian.
Well, I'll take this opportunity to bash sh. I find it odd that there's so little hate vented on Unix shell scripts, when much better designed and more useful languages routinely get savaged.
I've used dozens of languages over the decades, and I rank sh near the very bottom of widely used languages, somewhere between Javascript and COBOL. It's got bizarre syntax (a 40-year pile of duct tape), that makes Javascript look well-planned. It's got unexpected subtle whitespace syntax dependencies that should make a
Re: (Score:2)
"Each procedure call that would be implemented in a utility library in any sane language are instead implemented by the inefficient, error-prone steps of spawning separate processes and parsing the output."
You know you can write init scripts in bash, right? Which has many more builtins?
"I've personally seen people who are only familiar with coding shell scripts write huge thousand-line files filled with inscrutable calls to sed, awk and other "Unix philosophy" utilities."
Have you personally seen init script
Re:strawman fallacy (Score:4, Insightful)
Care to back that up with any proof
It's exactly what package maintainers have said, they like systemd because it eliminates init scripts. And it's also the primary argument that people trot out to justify systemd. If you haven't been keeping up, it's not my job to bring you up to speed.
Re: (Score:2)
Actually, I believe that primary argument is that it's useful when you're maintaining multiple remote systems. That's not something I do, so that's no advantage to me.
Not what they said (Score:2)
Here's what the maintainers said:
We recognise that some maintainers find init scripts a burden and we hope that the community is able to find ways to make it easier to add support for non-default init systems. Discussions about the design of such systems should be friendly and cooperative, and if suitable arrangements are developed they should be supported in the usual ways within Debian.
Just because someone finds it to be a burden does not mean that they find shell scripting difficult. They did not elaborate as to why it was a burden, but YOU decided to assert that the maintainers find scripting to be difficult.
Looking more and more like a Fox News story to me.
Re: (Score:2)
"Just because someone finds it to be a burden does not mean that they find shell scripting difficult"
Of course it does. Init scripts are shell scripts. If they're a burden, that means they're having difficulty with shell scripting by definition.
Re:Why systemd? (Score:5, Insightful)
In the old, stable environment, it made sense to have all services started via scripts in a pre-defined and finely tuned manner. And it might still make sense in some environments, that are mainly stable.
But for most environments, there is no stability. So you need a way to start and stop services and figure out dependencies all the time without manually editing scripts. You can't even be sure that the combination of hardware and services, you run right now might ever occur again during the lifetime of the system. A method to handle hardware, drivers and services and to start and stop them at not-foreseeable points in time in no predefined sequence has to be there. And if that system is there, the need for another system to start and stop hardware, services and drivers, this time completely predefined, is no longer there, as the first system supersedes it.
Re: (Score:2)
Q: Why are people, like Debian maintainers, in favor of systemd?
Lennart did a really good job doing product management. He worked closely with the system maintainers (mainly RedHat and Debian), listened to them, figured out what they wanted, got their feedback and responded to them. So even if it isn't architected well, systemd does what the Debian maintainers want.
At this point it might be noted that a lot of the Debian maintainers weren't great shell-scripters.....if you have a lot of repeated boilerplate code, that's your fault. Put it in a function or something so
Re: (Score:2)
Q: Why are people, like Debian maintainers, in favor of systemd?
Because while systemd is crap, the other options are worse (except possibly OpenRC, which I have never tried).
Re: (Score:2)
SystemD came about from a variety of problems:
1. Distros became incredible complex and more than 2 dozen utilities of ancient Unix when init was written.
2. Cloud computing and clustering mean images are moved between different systems and locations and types
3. Ubiquitous networking and mobile laptops. This means a system with a static init with a workplace configuration will break when it sleeps and is opened at a hotel.
4. Plain text logs. A hacker can simply edit the logs to hide his presence.
Ignore the w
Re: (Score:3)
This is the third time I've seen you mention this "hacker can edit plain text logs" point. Which is bloody stupid because the systemd non-text logging format is openly published. Extra stupid because of the response where you talked about editing the config files in /var/log. And "guessing what problem might occur" is the job of a programmer.
So when you talk about "ignoring the whiny gray hairs" here, you're one of the best demonstrations why having the "gray hairs" on one's side is the smartest thing you c
Someone explain to me why... (Score:3, Interesting)
...systemd is better than init when init has all the power of shell scripts at its disposal whereas systemd has yet another limited config language format? Yes you can run scripts with systemd but AFAIK its not well integrated with the boot system as a whole.
Re:Someone explain to me why... (Score:4, Interesting)
In theory it makes adding new services and sequencing them easier, along with running things in parallel to speed up the boot process. However when something goes wrong you often get no notification that your new service isn't working. I had loads of trouble trying to get a script to run at startup on a BeagleBone Black board. There was an option to enable /etc/rc.local but it didn't work and the logs showed nothing wrong.
The other problem is now things like desktop environments requiring systemd to run. Breaking compatibility with other distros. So the other distros have to tailor their code with shims and workarounds.
The claim is also made about systemd being able to restart a daemon if it dies for one reason or another but I have yet to see anything die randomly without cause.
Systemd people also argue its not some monolithic structure but a collection of small individual programs. But are you able to pick and choose among them or is it all or nothing? That question is murky.
Re: (Score:3)
So the other distros have to tailor their code with shims and workarounds.
Not always. You want to run our service? Here's the init script. You figure out a way to get systemd to run it. Hint: It's not all that difficult. The dbus system can be integrated with shell scripts pretty easily. And as an added benefit, we get to watch the systemd fans get their panties in a bunch over running a few scripts.
Re: (Score:2)
Ask the good folks over at gnome.
Re: (Score:3)
I will grant that systemd is better than init scripts, partly because it _removed_ a lot of very poorly integrated or implemented power of shell scripting. It also handles logging of init processes and and even of kernel startups in ways that SysV init could never hope to do. It's also multi-threaded, which init scripts were _not_, and handled restoring crashed daemons better.
There are many lighter-weight init tools that support many platforms and are not as _aggressive_ as systemd to take on system managem
Re: (Score:2)
Especially killing off user processes when users log out and disabling "screen" and "tux" with no log that it killed a process, and no way to turn this misfeature off without recompiling systemd.
The option to terminate any outstanding user processes upon logout was _always_ run-time configurable and was present for years before that pointless drama blew up.
(I'l grant you there was no logging when the session processes were nuked, but that was implemented as soon as someone asked for it)
Re: (Score:2)
...systemd is better than init when init has all the power of shell scripts at its disposal whereas systemd has yet another limited config language format?
Init's only power is to start a shell script. It does not know what happens as a result. It is completely dumb in the literal sense.
Systemd actually tracks processes like a damn init system should, and if you want to run a shell script you can.
There is a difference in power and capabilities between the two systems, unfortunately for the narrative you tried to push the more powerful and more configurable of the two is systemd.
systemd is more like a virus.... (Score:3, Interesting)
Had systemd stuck to being an innovative init system there would be much less discussion. But instead systemd has morphed into a virus like clone of windoze for linux. That's the problem (as I see it). Systemd is not an init system, it's a monolithic operating system pretending to be an init system.
With a preference for running real operating systems with actual init systems that don't try to be a full operating system I currently run PCLinuxOS (w/MATE) for desktop use and FreeBSD (or almost any BSD) for servers. Choices subject to change as folks new and improve stuff into a horrid state like RedHat and Debian have. Kind of a shame really, I used to truly respect both those companies a great deal, but no longer.
--
Steve (finally registered after all these years)
Predictable (Score:2)
Package maintainers have taken the time to learn to live with the D and are going to be resistant to change and certainly to being forced to support multiple inits.
If you don't want the inconvenience from using a distribution with a small user/contributor base just learn to love the D ... otherwise use Void Linux, it's the most realistic way forward.
What does "but we support exploring..." mean (Score:2)
WTF does "Systemd but we support exploring alternatives" mean ? I read that at a detail level a number of times and it still has no meaning.
I think it is a option that really says "we will support systemd only but we are afraid of saying that"
Going forward I see many complex packages will only support systemd by default. It will be up to you or the other distro maintainers to allow support without systemd
At this point, for Debian, the boat has sailed for non-systemd support and fully supporting systemd i
How was voting conducted anyway? (Score:2)
I have been a Debian user for close to twenty years, in both personal and professional capacities. I did not find any information on where to vote, I didn't even find information on what constituted criteria for voting eligibility. Given this state of things it seems somewhat disingenuous a result.
Re: (Score:2)
So many sillygisms on why ... (Score:2)
I love systemd.
I have a IPv6 tunnel through Hurricane Electric. The script they supplied to create the tunnel stopped working with Bionic, so I started creating the connection by hand in a Konsole:
sudo ifconfig sit0 up sudo ifconfig sit0 inet6 tunnel ::www.xxx.yyy.zzz
sudo ifconfig sit1 up
sudo ifconfig sit1 inet6 add 2001:w:x:y::z
sudo route -A inet6 add ::/0 dev sit1
but I soon got tired of doing that manually at boot up every time, or if I wanted to reconfigure. So
Re: (Score:2)
https://github.com/dyne/arm-sd... [github.com]
Roll your own Devuan image?