Devuan Releases Beta of Systemd-Free 'Debian Fork' Base System (devuan.org) 293
jaromil writes: Devuan beta is released today, following up the Debian fork declaration and progress made during the past two years. Devuan now provides an alternative upgrade path to Debian, and switching is easy from both Wheezy and Jessie. From The Register: "Devuan came into being after a rebellion by a self-described 'Veteran Unix Admin collective' argued that Debian had betrayed its roots and was becoming too desktop-oriented. The item to which they objected most vigorously was the inclusion of the systemd bootloader. The rebels therefore decided to fork Debian and 'preserve Init freedom.' The group renamed itself and its distribution 'Devuan' and got work, promising a fork that looked, felt, and quacked like Debian in all regards other than imposing systemd as the default Init option."
In Other News: People Hate Change (Score:2, Insightful)
What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for
Re: In Other News: People Hate Change (Score:3, Informative)
Nobody is against systemd just because it's change. People are against systemd because it is change that causes them many problems, including computers that don't boot.
Re: In Other News: People Hate Change (Score:4, Insightful)
Who art in Portland, OR
Hallowed by thy name...
deliver us from systemd
For thine is the kernel
The power and the glory
Forever and ever
Amen
Re: (Score:2)
Re: (Score:3)
Maybe. But my initial reaction was "binary logs?!? on a *nix system? WTF?"
But then I chilled out 'cause it seems Debian is configured to double log, ot the same old comfortable places it has always logged in plain text.
Emergency over.
Re: (Score:3, Insightful)
Maybe. But my initial reaction was "binary logs?!? on a *nix system? WTF?"
But then I chilled out 'cause it seems Debian is configured to double log, ot the same old comfortable places it has always logged in plain text.
Emergency over.
Err what do you call utmp and wtmp since they have been around in Unix since pretty much, well forever.
You have obviously not played with AIX which is a real Unix system and actually uses a database for administration purposes. Try any of the other Unix systems and they all have different flavours although there is allot of similarity.
As for Linux not being Unix. Well it isn't although it does have the look and feel of a Unix system. Oh and what do you call a text file? Strictly speaking it is a binary with
Re: In Other News: People Hate Change (Score:5, Insightful)
Oh and what do you call a text file? Strictly speaking it is a binary with a specific structure and can only be read with tools that can read that type of file.
Of which there are vastly more for plain ASCII text. In fact, Unix/Linux is famous for them. And people can read, search, and manipulate them under foreign OS's using tools common to those OS's.
Also, you don't have as much breakage with text files as you do with binary files. A binary file can become effectively unreadable very easily even on its native OS if a new OS version with a new file format comes out. A text file can be streamed straight to the hardware on virtually any printer.
It's also much, much easier to recover fragments of a broken text file than it is for a broken binary file. Something that's very valuable when a system is damaged and you need all the information you can get as fast as you can get it.
Re: In Other News: People Hate Change (Score:4, Informative)
Unless you can convert your binary to a stream of text, forget grepping it or doing any of the transformations everybody with a modicum of experience of *nix is very familiar with.
On the commandline, binary files are going to require a custom built interface for that specific type of binary. That custom built interface needs to have all the features you want for easy searching etc.: no regular expression search built-in? Then forget about it. If you're lucky, there is another tool that understands your specific binary flavour which may or may not do what you want.
A text file does not have those problems because it can be interpreted using a standard that is ridiculously simple, old as dirt and supported by and ingrained in pretty much fucking everything that displays letters.
I'm not saying a binary format cannot have its advantages (databases obviously have many), but to dismiss the difference between binaries and text files with 'you still need a tool to read them' is absolutely fucking idiotic.
Re: (Score:2)
Re: (Score:2)
I wasn't talking about journalctl. I was responding to this: "whether a file is text or binary you still need a tool to read it so its a meaningless argument."
That is still an idiotic way to dismiss the difference between text(ASCII) files and some binary format.
You can also pipe the text output from journalctl to any text parser you like.
That is a great feature. To me this pretty much settles the argument over binary logging vs. text logging and deserves being stated often and immediately when it comes up.
Re: (Score:2)
Re: (Score:2)
If you're not experienced enough to pipe somebinaryfile.foo through footobar so that you can use it with other command line files, then you're fibbing about having any use for such a difference. ;)
Re: (Score:2)
Unless you can convert your binary to a stream of text, forget grepping it or doing any of the transformations everybody with a modicum of experience of *nix is very familiar with.
Well there are many ways to do that with systemd, including various language bindings to eg. Python, allowing you to directly query the journal.
It would also be trivial to tech "grep" etc to learn to read the journal, just like "zgrep" can read binary files. There is no point to that however, since the concept of piping works so well: All the standard text tools like grep, awk, tee, wc etc. works with the systemd journal through piping.
On the commandline, binary files are going to require a custom built interface for that specific type of binary. That custom built interface needs to have all the features you want for easy searching etc.: no regular expression search built-in? Then forget about it. If you're lucky, there is another tool that understands your specific binary flavour which may or may not do what you want.
No, that is wrong. Through the Unix concept of piping all standard text
Re: (Score:2)
whether a file is text or binary you still need a tool to read it so its a meaningless argument.
No, I don't need a *special* tool to read it. I need a tool to read the disk and a tool to display to screen. I don't need a tool that goes in-between those two tools jut to read a text file. Those two tools are just fine. It's intellectually dishonest to claim what you claimed above.
You are basically making the claim that, because one needs a tool to decrypt ciphertext, that *proves* that everything is ciphertext. Sorry, no it isn't. Using dd to read a text file is not in any way the same as needing an
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You can cut that down further.
"Users are not morally obligated."
Just use which one you want. If you're hating on things you don't use, after you realized you didn't want to use them, that is an unrelated non-technical problem.
Users are not morally obligated. They're just users.
Re: (Score:2)
> Maybe. But my initial reaction was "binary logs?!? on a *nix system? WTF?"
Besides the POSIX utmp and wtmp binary logs, there is also the Kernel ring-buffer on Linux; Without the ring-buffer collecting and storing messages from /dev/ksmg there would be no boot-logs at all, or even any logs until the rootfs has been mounted and the syslog daemon started.
systemd's "journald" service is the Kernel ring-buffer equivalent, and "dmesg" similar to systemd's "journalctl" tool; they both extract binary log-info
Re: (Score:2)
Hey look, another "systemd horror story" with no distro, no release, no hardware specifics and no bug# 0/8, lrn2troll.
This should be modded up. Meanwhile, I have installed and used Ubuntu and Mint, and Lubuntu and and UMate and Xubuntu on a lot of computers (I didn't keep count) with only one problerm - which turned out to be a dd bug that was fixed in a couple days.
Including my latest personal project, a Raspberry Pi that I'm on right now, with Ubuntu Mate running happily, systemd and all.
Re:In Other News: People Hate Change (Score:5, Insightful)
Seriously, who cares how fast it boots? Unless you're on some tablet type device I see no reason why boot speed should even be a thing. The old initscripts are plenty fast enough for my laptop even.
The issue that I have with Lennarts work is that it goes completely against the design philosophy of *nix that made it so great in the first place. It also broke a bunch of stuff that relied on the old behavior - a big no-no and an instant turn-off.
Re: (Score:2, Interesting)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
While you might not care about faster boot times, clearly many people do. PC manufacturers and Microsoft have been improving boot times for years now, with UEFI and Windows 8 really speeding things up. Personally I like that my laptop goes from off to ready to use in 4 seconds.
And stuff breaks because it relies on specific, unspecified behaviour? Sounds to me like that stuff is broken, not systemd. In any case, the logical thing seems to be to fix the broken stuff so that it is more reliable and more compat
Re: (Score:2)
And stuff breaks because it relies on specific, unspecified behaviour? Sounds to me like that stuff is broken, not systemd. In any case, the logical thing seems to be to fix the broken stuff so that it is more reliable and more compatible.
Yeah, but if they actually made a specific claim about something being broken, one of those know-it-all systemd users would just go and fix it for them, and they'd lose the whole complaint. You're trying to ruin perfectly good straw men.
When people whine to me about systemd in person, I tell them straight up; find a real bug or problem and I will personally slay it for you. Nobody has ever been able to cite a real bug, that they actually had, though all of them have a cousin's friend's brother's wife's frie
Re: (Score:2)
LOL there are often some non-ASCII chars in the logs, and there are always were.
All you have to do is type "bar" instead of "foo" and you'll be reading the text-only log, because that is how the tools work.
Your idea that you'd need to rewrite something to find an exit code from a log because the log is binary is hilarious; it shows that you don't actually use logs that way, don't understand what the word "binary" means here, and you don't actually have the problem that you claim exists.
The absolute worst ca
Re: (Score:2)
Seriously, who cares how fast it boots?
People who pay for your time by the hour.
Re: (Score:2)
Seriously, who cares how fast it boots?
*raises hand*
Given booting faster, or booting slower, I'll take faster.
Re:In Other News: People Hate Change (Score:4, Insightful)
What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.
The init capabilities of systemd aren't too bad. The "scripts" look pretty similar to many other init system alternatives and, for basic stuff, are fine. The problem is that systemd isn't an init system anymore. It has become a layer between the kernel and traditional userspace. *That* is why people hate it. Basically, RedHat has gained too much control over the Linux ecosystem and so has started ramming their agenda down the throats of all Linux users. If the systemd/PulseAudio/etc abominations were just confined to RedHat, no one would even vaguely care (except RedHat users). But, it's become increasingly difficult to avoid the garbage coming out of RedHat because, as I stated before, they have gained too much control and influence over Linux.
Re:In Other News: People Hate Change (Score:5, Insightful)
yep.
systemd's init functionality is fine, as good as (or better than) most other alternatives.
it even makes sense to have the control group manager as part of the init process (although even that should be optional if someone wants to run something else to manage control groups).
absolutely everything else that systemd does, though, (network setup, logging, crappy cron imitation, consolekit login services, etc etc etc) should be entirely separate, completely optional programs with good documentation (incl. API and protocol docs).
if systemd confined itself to just init services, nobody would bother hating it because there would be nothing to hate - it would be just one init option amongst many. probably a very popular option because, as init, it's pretty good.
Re: (Score:2)
The only place where I feel it falls somewhat short is in systemd-networkd which currently lacks good support for policy routing.
no, that's the only place that you have seen it fall short, there is a difference. i'd go on to list all the ways it falls short but it would only fall on deaf ears.
Re:In Other News: People Hate Change (Score:5, Interesting)
So you learned to do the easiest part and called good. 'grats. Now, consider my use case. I build a btrfs using RAID1 in a VM. I dettached one of the virtual drives to test things and rebooted the VM. Systemd dumped me to an emergency shell with the network down. Try as I might, even digging through the 100 or more low level config files kept under the rug I could see no way to show systemd the error of it's ways. And yes, I specified mount option degraded on the kernel command line and fstab, but systemd ignored it. All it knew is that it was prepared to wait forever for that no longer connected disk to come online and was not going to be made to see reason.
Naturally, I hit up google. Turns out many people had a similar problem with RAID1 volumes as root. No solution there, even from LP. Furthermore, the devs were stumped as to an approach to fix the problem. They considered it intractable and so WONTFIX. It never did get fixed as far as I can tell. The best solution on offer is to use SCRIPTING in the initfs to mount the RAID volume before systemd gets to run. Yes, SCRIPTING.
THAT is why I object to systemd. It's just too damned easy to find something is simply won't do as soon as you use a system in any manner that LP doesn't. I guess he doesn't do much with servers.
Now, if they would just keep their fingers out of all the pies I wouldn't care. You can use systemd and I'll stick to scripts. Alas, they insist on sticking their fingers in every pie through a pernicious knot of dependencies. For a while it seemed that the stronger the objections, the more things became dependent on it. That's why it took Devuan so long to purge it from Jessie.
Very ugly.
Re: (Score:3)
Just not in your initramfs, I guess?
Really, though, distros use sophisticated scripts in initramfs anyway, which should handle this sort of thing. Mounting the root filesystem is initramfs's job, not /sbin/init's. My root filesystem is on LVM on top of dm-crypt on top of bcache on top of RAID1, and Debian makes it work just by runn
Re: (Score:2)
Naaa, that would be solid engineering, as opposed to anything Poettering can do. This person must not even have heard of KISS or he is to stupid to recognize what it means and why it is at the core of solid engineering.
Re: (Score:2, Insightful)
Since the last time you whined about Lennart not fixing bugs you were lying, you wouldn't mind backing this up with a link, now would you?
Re:In Other News: People Hate Change (Score:4, Interesting)
Here's one of a few discussions [freedesktop.org]
Also google on: systemd degraded btrfs
The hell of it is that once it dropped to the emergency shell, simply entering the needed mount command by hand mounted it right up. Had it been a script based system, I could just stuff the mount command in as an imperitive and moved on to the next issue.
This is interesting. How about issue the mount command? If it is complete enough to succeed then it will succeed. Otherwise it will fail. That was obvious enough that SysV init got it right. Note how "let the admin decide" wasn't apparently even a consideration.
Since that wasn't the only issue, I found a way to mostly defang systemd in Jessie (Debian) so I left it at that. I fave the Devuan beta downloading now. I may very well go that route.
Re: (Score:2)
And indeed, that discussion:
Like I said, you're lying. Again.
Re: (Score:2)
If you're going to call someone a liar, you need to back it up. So back it up or STFU.
Do the google, you'll find the same problem reported a year later. I pointed to that one because it best described the problem.
Re: (Score:3, Insightful)
You lied, he called you on it, you tried to defend, the documentation you pointed at shows you had a problem with your distro, and are lying about it to blame systemd.
Learn how to set up your raid next time. Take responsibility for your mistakes. There are lots of sysadmins here, you can't avoid being a liar just by calling names afterwards.
Re: (Score:3)
And you apparently can't read. I posted a representative message from the systemd list (not a particular distro) where LP himself admitted to not having a solution (you did actually read it, didn't you).
I did indicate that a number of distros solved the immediate problem for RAID by doing an end run around systemd.
You didn't even read well enough to understand that I was testing with BTRFS. I solved the problem (that is, configured the system correctly) by disabling systemd and putting SysV back in charge o
Re: (Score:2)
Right, distros solved the problem without systemd's help... because it was their bug, not systemd's! duh. Stop lying about it.
Re: (Score:2)
No, they worked around it because the systemd team were running around in circles with their pants around their ankles.
Re: (Score:2)
That's not how it works, kiddo.
You stated there was a problem, you need to put up the evidence. The link you put up did nowhere near state what you said it did. Ergo, you're a liar. You backed that up yourself.
Re: (Score:2)
Sorry, no. I put up a reference and a google search you could use. If you don't want to believe it, fine. But if you want to call people a liar, you'd better have a better reason than "I can't read so I don't acknowledge your evidence."
Sorry about goring your sacred cow and that you have so much butthurt over it. I suggest you retreat to your safe space and seek counselling.
Re: (Score:2)
I'm not going to bother saying anything about Lennart or other core systemd developers since it's been widely established that they have proven to be disagreeable on numerous occasions.
Yeah, why can't they be professional, courteous and agreeable at all times like other prominent linux developers? [youtube.com]
Re: (Score:2)
When systemd is in use, installing on one partition makes the other partitions unbootable...unless they can be booted with SysV. This has been known for over a year, and, IIUC, has been marked "won't fix".
So I find systemd to be unusable. I like to test new systems without rendering my current system unusable.
Re: In Other News: People Hate Change (Score:2)
Re: (Score:3)
Funny you post that it isn't going anywhere in an article about a significant milestone accomplished.
Re: (Score:2)
What is wrong with systemd? (Score:2, Flamebait)
I am new to this and I have seen a fair few "systemd is 3vil" posts, but with little indication as to why people dislike it, compared to the alternatives? Just to be clear I don't have a position here, rather I am looking for some insight.
Re:What is wrong with systemd? (Score:5, Insightful)
There is a perception that it is a "borg" which keeps taking over more functionality and becoming a dependency for so many things that there is no choice but to use it, an example being Gnome. I don't know if this is fair or not.
This is effectively the crux of it. Everything else is just a symptom of this. People will make detailed technical analysis of the inner workings of systemd and that's cool and some of them are correct. But, bad technical decisions aren't that big of a deal until they start spreading across the system like a virus. Once systemd has infected everything (and, we are rapidly approaching that), it will be difficult or maybe impossible to cut out that cancer. We are right on the verge of being stuck with systemd and that's a very bad situation to be in.
I will note that maintainers of several unrelated distributions independently chose to adopt it, including Arch Linux. I mention Arch because A) they are famously in favour of a simple base system which you customise the way you want, B) I don't believe have anything to do with Red Hat (where the systemd creators come from), and C) they haven't been forced to switch by e.g. gnome because they don't require gnome or any other desktop.
Comments from an Arch developer on their forum: https://bbs.archlinux.org/view... [archlinux.org]
This is the second problem with systemd. It has polarized people to such an extent that it resembles a religion or US politics. You must pick a side and you must rabidly defend that side no matter what. To be fair, it's an issue worth having an opinion on but, your opinion definitely doesn't matter. You have distros with very finite resources (like Arch) and distros with effectively unlimited resources (RedHat). The smaller distros kinda have to eat whatever shit sandwich the larger distros serve up because they don't have the resources to do anything else.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The first time your system goes down hard and you need to login to the systemd emergency console, run the command to review the binary-logs, and then set the system default to boot again, you'll hate systemd too.
The command to review the logs is called "journalctl" and it works perfectly from the emergency console or initrd. That means you have access to powerful log querying with systemd, even in a limited environment. So full service management and log querying even from the emergency console with systemd, which is much better than SysVinit/OpenRC based systems that just give you "cat" and a neutered version of "vi" to work with and often doesn't even have syslog in the initrd, but rely on the binary logging in
Having run some CentOS 7 boxen... (Score:4, Insightful)
...my take on systemd is this: As an init system, I actually like it - far better than other SysV replacements, especially SMF on Solaris and friends. Where it goes off the rails, though, is the ever-expanding mission creep into things that really aren't an init system's purview.
If systemd would just be an init system and get out of the way, I'd cheer it on. But one of the first things I do when I set up a CentOS 7 server is to shut off firewalld and use iptables directly. Firewalld is OK on a laptop where you're connecting to a variety of different networks, but leave it off my servers, please.
systemd works perfect on 1020 node Cray XE6 (Score:4, Interesting)
unnecessary (Score:3)
I still have no idea why they needed to fork from debian, instead of just maintaining packages/patches required to provide a systemd alternative from within debian.
When choosing a distribution, why anybody choose a distribution whose only clear philosophy was that it is not something else? Unlike debian which is ultimate software freedom and stability or whatever.
Re:unnecessary (Score:4, Informative)
There's only so much you can do to maintain software packages for an alternative. When a core system component deviates the way systems did you would have to dedicate an incredible amount of testing and modifying of packages to ensure the system doesn't randomly break. If you need to retest much of the system then it's just easier to maintain your own distribution.
Re: (Score:2)
On the Fedora side, they have "spins" and it is really easy to maintain your own subset of packages without forking anything.
Maybe "fork and wither" is a Debian thing I just don't understand?
Old farts that can't change (Score:2)
I'm 61 - took me about an hour to figure out systemd - not that I asked for the change - but it wasn't a big deal. In the end I realized it fixed a few issues and all the hate-flame-bait crap was uncalled for.
I've come to realize it is must be only a minority of really old farts that complain about systemd - I get it - as people age they can't learn new things - can't see why the changes are happening - growing old sucks.
I suppose it is really the old guys over 70 just can't adapt to these changes - so I ha
Really old farts just can't change (Score:2)
I'm 61 - took me about an hour to change over to systemd syntax. I didn't ask for it - thought it was a bother, but in the end I see it fixed some things and it is working fine - the hate-flame-bait-carp was uncalled for.
I have come to realize that it is only the really old guys over 70 or so that no longer can learn new things or see other points of view. Growing old and losing metal agility must really suck. I put up a page with notes for these guys that can't adjust on their own:
https://wiki.xtronics.com [xtronics.com]
Re: (Score:2, Insightful)
Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together. If there is a willing team of people who want to maintain these scripts I see no reason why the Debian team should stop them.
A beautiful thing about open source is you have the choice to go against the flow. Sometimes it pays off. Often times it doesn't. If someone stops you then fork, but I really don't see what the big deal is. Let's keep our egos in check and hopefully we
Re: (Score:2, Insightful)
To me, systemd is a solution looking for a problem. Ego has little to do with it; rather, trying to get shit done is what the issue is all about.
Also, systemd reminds me of the time I got soap suds up my pee-pee hole.
Re: (Score:3)
Oh the problem is there alright.
See here for example: https://www.youtube.com/watch?... [youtube.com]
You want to replace sysvinit with something.
Now whether that is upstart, OpenRC, systemd or something else is the question.
systemd's service dependency tree and triggering is definitely attractive, and you can do some cool server configurations with it. For example, assign resources to a service, and that restriction applies to all sub-processes. Or find all processes launched by a service.
Re: (Score:2)
And LaunchD [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Redundant)
The problem was service inter-dependency in startup/shutdown was quite awkward in SysV, plus the opportunity to increase service startup/shutdown speeds by handling unrelated services in parallel.
People who have this perception aren't using inittab properly. We are yet to see a use case presented that init cannot deal with and these two are already covered. Dependancies are meant to be initialized via rc scripts and services are maintained via inittab.
People seem to be hung up on using runlevel scripts to do everything. It's this mis-use case of red hat's runlevel scripting system that is being used as an excuse to replace initd with systemd. It's pretty reasonable for people to be skeptical about
Re:SystemD = Bolsheviks (Score:4, Interesting)
So either you get a new hotplug environment within runlevel 5, which then handles all the temporarily running services, or you just accept that the hotplug environment does nothing else than init (starting and stopping services depending on a set of constraints), just in a more flexible and granular manner, and init with runlevels 1, 2, 3 and 5 is just a special case of the hotplug environment, which just duplicates the functionality of the hot plugging environment in a more clumsy and less flexible manner.
Re:SystemD = Bolsheviks (Score:4, Insightful)
Servers sitting in a light's out facility rarely have things plugged ind unplugged.
The whole controversy could have been avoided if systemd was properly designed as a plug-in component. System starts up under the old init. At some point (after the basic system has been brought up), an rc script or inittab starts systemd (a series of event listeners) to deal with hot-plugging and such. Make sure it doesn't block others from listening.
Poof, no controversy, no objections.
Re: (Score:2)
Re: (Score:3)
initd starts the event manager in that use case.
Re: (Score:2, Insightful)
Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together.
Found the guy that has never dealt with Debian developers.
Re: (Score:3, Interesting)
The problem with systemd isn't its replacement for scripts.
Well, kind of it is, since they arrogantly didn't bother to provide any way of getting certain things done that scripts were doing, but that's only where the outrage begins.
The problem with systemd is that it doesn't want to coexist peacefully. It wants to own everything. Not just resource control, but logging and other things as well.
Re: (Score:2, Insightful)
Re: (Score:2)
Except for its ability to happily hand over to scripts, it's ability to happily log to a syslog daemon, and happily hand over networking, NTP, and all other functions to another system of your choice.
Key word "choice". Configure it how you want to. This may require you to read a manual or do a Google search but that's hardly a new thing in Linux.
Re: (Score:2)
systemd logs perfectly fine to rsyslog. Stop acting like a parrot by repeating FUD.
Re: (Score:2, Insightful)
The problem with systemd is that it doesn't want to coexist peacefully. It wants to own everything. Not just resource control, but logging and other things as well.
I don't think you have actually studied the design of systemd; it is exactly designed to co-exist peacefully with other components. It is a major reason why it was adopted so successfully and fast:
You can use any syslog daemon like Rsyslog or syslog-ng with systemd's journald.
You can use you own homegrown resource manager using cgroups instead of systemd's. systemd uses cgroups for two things; tracking and grouping services, and resource control. But the latter use is entirely optional and you can compile s
Re: (Score:2)
Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together. If there is a willing team of people who want to maintain these scripts I see no reason why the Debian team should stop them.
The problem isn't the init-scripts, the problem is supporting two different init-systems at the same time, including replicating and fixing bugs.
That is why Devuan is removing systemd from their Debian fork, even though Debian Jessie at present can support both SysVinit and systemd.
Re: (Score:2)
Re: (Score:2)
So, doomed to failure, then?
Well , as much failure as any Linux distro has. The best thing about this is it's one more solution for those who really hate systemd.
However, this dislike has a life of it's own, so I don't expect any diminishment of the complaining.
Comment removed (Score:5, Insightful)
Re: (Score:2)
Yes, this, uh, adult, reasoned, calmly and rationally stated essay really instills confidence in the maturity and professionalism of the maintainers of this distribution.
It has always struck me that I can't seem to find a critique of systemd that lacks namecalling, cursing or at least one suggestion that Poettering do something that sounds anatomically unfeasable. It's as if the critics are largely middle-schoolers who don't actually have any skin in the game.
Re: (Score:2)
All my systems are now switched to Devuan.
The essay made people like me (linux-only since 1998) switch.
Re: (Score:2)
Re: (Score:2)
My first linux was slackware 3.0 which I got by buying a magazine that had the CD glued to the cover. Then I spent 3 days downloading a newer slackware over dialup. Before that I had to telnet into my ISP's SunOS 4 box if I wanted some *nix.
Throwing my hat in with, "a hell of an improvement [over SysV]."
The types of "technical complaints" people come up with... they aren't even enough of a challenge to make the daily list of sysadmin annoyances. They're all just small changes people would have to make in wh
Re: (Score:2)
I value having frivolous boxes around that I can just "do whatever" with, but I value even more having root on boxes that I wouldn't alter frivolously.
Re: (Score:2)
Re:Init Freedom (Score:5, Interesting)
It prevents it. The init part of systemd is just a small part of it. It has started to replace many (and a growing number) of core Linux userspace subsystems. It has gotten to the point where you may not be able to run the desktop environment you want without systemd. The generic, modular bits that systemd has consumed are now components that more and more pieces of software are depending on. In the very near future, it may not be possible to run a modern Linux desktop without systemd.
And, for what benefit? None that I've ever seen. There is nothing that I can now do with my laptop that I couldn't do before. But, there are plenty of things that I can no longer do since the introduction of systemd.
Re: (Score:3)
You know i for one welcome our new systemd overlords. Part of why non-systemd users don't get supported anymore is because there are no non-systemd services anymore with a rich API as systemd. And very often unification is very good.
You know there have been multiple projects for standardisation among linux, and many of them have failed. Most of them just published a standard nothing more. systemd offered an implementation, without a standard, and it was successful, didn't fail.
Re: (Score:2)
Indeed. No tangible benefits for many people and at the same time massive mission creep. If it were a sane design and just stuck to being an init-system, it would also be very easy to fully support other init-systems in parallel. The systemd developers have made that hard, and I think intentionally so. I call that one thing: "sabotage".
Re: (Score:2)
well, if nothing has changed then they've done such a good job as you carried on as normal. What can you no longer do?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Did you even read the summary? You know, the one about the group building and maintaining a systemd free distro who just released a beta?
Re: (Score:2)
Re: (Score:3)
And that is just it: This thing does not exist to solve any exiting problem, it is a power-grab, plain and simple. That is also why it grows though Linux like a cancer and absorbs everything it can, so it cannot easily be ripped out. If it had stuck to being a better init-system, it may have had merit, but this way it is a huge threat to Linux, nothing else.
Re: (Score:2)
None of the companies I work with care if a person, place, or thing "sounds like a... ladyboy." If a person wants to be a ladyboy, that is fine with us. If they want to identify as a man or woman instead, that is fine too.
But if they make non-technical complaints about technical things, or have a passionate dislike for something that is merely not their first technical preference, then they're out the door, and if they don't want their desk contents in the mail, they'll sign the paperwork and leave promptly
Re: (Score:2)
I thought this whole Linux thing was all about freedom to choose?
Not when it comes to Devuan; they won't let you choose systemd as init. No "init-freedom" there.