Devuan's Systemd-Free Linux Hits Beta 2 (theregister.co.uk) 338
Long-time Slashdot reader Billly Gates writes, "For all the systemd haters who want a modern distro feel free to rejoice. The Debian fork called Devuan is almost done, completing a daunting task of stripping systemd dependencies from Debian." From The Register:
Devuan came about after some users felt [Debian] had become too desktop-friendly. The change the greybeards objected to most was the decision to replace sysvinit init with systemd, a move felt to betray core Unix principles of user choice and keeping bloat to a bare minimum.
Supporters of init freedom also dispute assertions that systemd is in all ways superior to sysvinit init, arguing that Debian ignored viable alternatives like sinit, openrc, runit, s6 and shepherd. All are therefore included in Devuan.
Devuan.org now features an "init freedom" logo with the tagline, "watching your first step. Their home page now links to the download site for Devuan Jessie 1.0 Beta2, promising an OS that "avoids entanglement".
Devuan.org now features an "init freedom" logo with the tagline, "watching your first step. Their home page now links to the download site for Devuan Jessie 1.0 Beta2, promising an OS that "avoids entanglement".
Init alternatives (Score:3, Insightful)
Do any of these alternatives offer the same speed benefit of systemd? Serious question as I've never tried to replace the init system on any linux distro.
Re:Init alternatives (Score:5, Funny)
Do any of these alternatives offer the same speed benefit of systemd?
No, your system might boot two, or even three seconds slower than with systemd.
Re:Init alternatives (Score:5, Insightful)
And your non-systemd boot process will also be comprehensible and easy to troubleshoot.
Re: (Score:3, Informative)
Since my day job involves comprehending and troubleshooting init scripts, I'm going to assume that's sarcasm.
There are some good non-systemd boot processes, with nice clean service definitions... there have to be... please tell me there are...
Re: (Score:3)
While I did not have a lot of problems with SysV or Systemd, I wish I could make Systemd boot sequentially. Once I spent quite a bit of time troubleshooting a problem where a zpool would not mount at boot time. It turned out that the controller for the zfs hard drives was initialized too late for the boot process (system drives were on a different controller). This never happened with SysV and I wish I could set Systemd to mimic this as well, even if it adds some seconds to the boot time of a server I reboo
Re:Init alternatives (Score:5, Insightful)
With all due respect, that comparison is awful.
In the effort to make an "apples to apples" comparison, it uses only the bare minimum of functionality from each toolset. There's no illustration of dependencies or capability control. It is useful for getting a rough idea of how the init systems' config files look, but not really as the basis for any kind of comparison, especially with regard to advanced features.
Re: (Score:2)
Bad comparison. ...
Apples don't use systemd. Neither on the BSD nor on the BootCamp Site
yeah ... just kidding.
Re: (Score:3)
Please unconfuse me, is the "it" in your opening sentence referring to Systemd or the Init system.
Like all new replacement functionalities, there are teething problems. Already, systemd is stable and easy to use as a system management tool.
I find systemd just fantastic, considering it's age and the progress made.
I guess, thats why SUSE' RedHat, Ubuntu and Debian have evaluated systemd against their existing init system and made the switch. Resistance to change reminds me of the expression.
When the only t
Re:Init alternatives (Score:4, Insightful)
So let me get this straight... in order to say "Foo depends on some kind of bar, which happens to be baz on this system", I need to write a "bar" definition that actually runs "baz", and go modify a completely separate dependency file to add "foo".
...and you're suggesting this is clean?
Re: (Score:3, Informative)
The correct way is create services foo, baz and a bundle bar, and then
;)
$ echo baz >> bar/dependencies
$ echo bar >> foo/dependencies
You need to read the page more patiently. It's not the never-ending systemd documentation, and does not require much time to read in its entirety
Re:Init alternatives (Score:4, Insightful)
Ok, that may waste time. Everybody knows that reinstalling is the way to go on boot-problems, right?
Re: (Score:3)
Re: (Score:2, Insightful)
And your non-systemd boot process will also be comprehensible and easy to troubleshoot.
+5 Funny. Now if you'll excuse me I have to go back through hundreds of log files and filter through init scripts with 1000s of lines to find out why something's not working.
Re:Init alternatives (Score:4, Informative)
Except that in reality there is no log of early boot messages with sysvinit. So the information to find issues is actually not there.
So with sysvinit, there is a *guarantee* that the diagnostic log messages do *not* exist. On the other hand, systemd logs these as well: this makes debugging boot failures way easier.
Re: (Score:2, Informative)
Re:Init alternatives (Score:4, Informative)
There's tons more *useless* information in the systemd journal, and all the useful logging daemons usually do tends to be turned off by whoever wrote the default service file.
I really can't see how a system where a failed service doesn't bother to tell you it failed when started by hand from the command-line got anywhere popularity-wise. Seriously. Doing a "systemctll start blah" when blah enters a failed state doesn't say anything different than when blah starts successfully. What. The. Hell.
Also, I don't appreciate having to learn a bunch of directives only useful inside systemd unit files, named apparently by someone with really bad instincts for naming things. With a shell script, I can see a command being used, and if I do not know it yet, I can read the manpage for it, and here's the trick: I can then use that command for other stuff, not just running daemons.
Granted systemd is better at "structuring" the init scripts... is you need to manipulate them programmatically that's handy. Almost. Everyone. Does. Not. Need. To.
Re: (Score:2, Informative)
Do any of these alternatives offer the same speed benefit of systemd?
No, your system might boot two, or even three seconds slower than with systemd.
Actually, that's not necessarily true. I don't know if Devuan supports it, but OpenRC is an alternative init system that started with Gentoo (pre-systemd), but is now also available in other distros. It is written in C, and supports parallel startup processes, but it is *just* an init system, and sysvinit-style bash startup scripts need only very minimal modification to work with it. (You don't determine a fixed load order; you specify "depends" and "provides", which OpenRC uses to decide on a load order an
Re: (Score:2)
I don't know if Devuan supports it, but OpenRC is an alternative init system...
Not to be a dick, but the answer is right there in the description. You could take just a few more seconds before rushing to reply.
Re:Init alternatives (Score:5, Insightful)
Except for one little problem. Gentoo Bug 391945 [gentoo.org]: "boot can hang when rc_parallel=yes".
Reported 2009. Current status 5 years later: "CONFIRMED".
Re: (Score:3, Informative)
Well, on my systems, runit boots faster than systemd, and does not run into those corner cases systemd encounter that cause it to hang forever ;)
Re: (Score:2)
Corner cases such as...??
Re: (Score:2)
I'm not joking.
Something so incredibly trivial hung the thing consistently as it attempted to start a systemD service to handle it, failed and did nothing - on several machines after an "upgrade" to a distro with systemD.
Where is the parallel init that Lennart promised?
No second thread doing stuff and no giving up and going onto the next thing like a production quality init system.
I've seen others but that was the most recent
Re:Init alternatives (Score:5, Interesting)
I'm not sure if that's a serious question or an attempt to troll, but regardless...
Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?
In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies". To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving. In my opinion, them, I don't really see the point in changing one's distro (including support lifecycles, development trust, and organization philosophy) just to swap out init. It's just not that big a deal.
Re: (Score:3, Interesting)
Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?
Well, on my home rolled NAS appliance, I really like the ability to reboot all of my VMs very quickly when applying security updates, because I'm not the only one that uses it.
In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies". To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving. In my opinion, them, I don't really see the point in changing one's distro (including support lifecycles, development trust, and organization philosophy) just to swap out init. It's just not that big a deal.
I personally don't have a problem with systemd. The thing is, there's so much damn drama over it that I'm curious what its detractors want to use in its place. And why are some people going to go out of their way to say "you don't need a faster boot time" when they don't know my use case? Furthermore, with the way I hack my Android sm
Re: (Score:3, Insightful)
The truth is that the boot speed improvements of systemd are effectively notional. The boot process is so fast now that starting in parallel only saves you time when something goes wrong. If you regularly have a problem during boot, then you should think about fixing that regardless of what your init system is.
Re: (Score:2)
hardware wise to a point you wont notice a diff with either init.
The place I believe it makes sense is in short-lived virtual machines. But that's no excuse for making it the default in other forms of OS.
Re: (Score:3, Interesting)
Well, on my home rolled NAS appliance, I really like the ability to reboot all of my VMs very quickly when applying security updates, because I'm not the only one that uses it.
A fair point.
The thing is, there's so much damn drama over it that I'm curious what its detractors want to use in its place.
Typically sysvinit or mostly-compatible equvalents. From my perspective, they don't want to learn something new, and they don't see the existing system as broken.
And why are some people going to go out of their way to say "you don't need a faster boot time" when they don't know my use case?
The obligatory XKCD [xkcd.com] applies. Most boot processes are fast enough now that it's not really worthwhile for an end user to shave a few seconds off the time. On the other hand, doing something as a hobbyist is entirely about wasting time, so I won't hold that against you.
The biggest improvement over antique boot systems is going to paralle
Re:Init alternatives (Score:4, Insightful)
The biggest improvement over antique boot systems ...
That there is the heart of the problem, an attitude that anything old is necessarily bad. That your otherwise calm and reasoned presentation allowed this pejorative to slip in belies the psychological bias that underlies the wide arguments on the subject.
Lest we forget, Linux as a whole turned 25 recently. That's antique. Are you giving up the entirety because it's old? Your favorite editor is probably (just based on popularity) is either emacs or vi / vim. They are very, very old (heck, I've been using emacs since the early 1980s!). Are you dumping them because they are old? I hope you see why calling something "antique" is ill-conceived.
Now to make sure that my point is being made clear, allow me to be explicit: old does not necessarily mean bad, but it does not necessarily mean good, either. Things that are old now were once shiny and new, and weren't necessarily an improvement when they were introduced. But change merely for the sake of change -- which seems to be what was behind debacles in KDE, Gnome, systemd, and Wayland to name a handful -- is wasted effort. For systemd in particular, the primary argument for using it seems to be parallel init, something that as many others have pointed out really isn't much of an issue these days since (a) Linux is generally stable enough that reboots are rare (although there are specific use-cases that benefit, like demand-based VM creation), and (b) computers have become generally fast enough that reboots are inherently speedy.
Re: (Score:2)
You're reading far too much into one word. You should try reading the rest of that paragraph.
The first init systems were damned little more than just a shell. After that, we moved to running a single script at startup, and eventually went to runlevels with some common conventions. That's where development stagnated for a decade or two, and that's where I'm drawing my "antique" line. At the time, systems couldn't handle multitasking very well (mostly in terms of race conditions and programmers' sanity), and
Re: (Score:2)
that's where development stagnated
More flippant handwaving in usage of words that shows a lot about weakness in your argument.
Development 'stagnated' only implys development needed to continue. Now, we all know that everybody wants their email address in important headers in the software project, so everything needs to be ripped out and replaced at whim on a regular basis.
But things aren't 'stagnant' unless there's a reason for something newer to replace them. Has the development of new cinder block desig
Re: (Score:2)
Has the development of new cinder block designs 'stagnated' because nobody has designed a new cinder block for probably a century? No, the existing design is fine and doesn't need replacement.
That's a very interesting analogy, since I'm currently in a Japanese hotel overlooking a construction site.
Rather than the typical cinder blocks, the bottom two floors are being built from large reinforced concrete slabs, about 1 meter by 3 meters, which interlock and periodically have apparently-plastic pieces. It definitely has increased the speed of construction over laying cinder blocks, and I suspect the slabs and plastic provide some means of safety in an earthquake.
Elsewhere on the technological spec
Re: (Score:2)
>Personally I love systemd, not because it's fast, but because it completely prevents boneheads from putting stuff in init.d scripts that never should have been there.
This.
I used to go in to troubleshoot a service problem to find page after page of dense impenetrable bash script with no obvious purpose. That doesn't happen much any more.
Re: (Score:2)
The old stuff still works better than the new thing in rapid development so the question is the other way around. The detractors (I'm halfway to being one despite or maybe because of using it on some systems) either think it isn't ready or think various parts are doing things the wrong way, plus the newbie level bugs are a bit offputting. A binary log unprotected from race conditions - what fun!
Re: (Score:2)
You are lost in Microsoft land. You don't reboot after applying updates unless they are kernel updates.
If I shell in and the Ubuntu login banner says "system restart required", then what do you suppose I do?
(yes, automatic security updates are enabled)
Re: (Score:2)
You obviously log off immediately!
Man, that was easy!
Re: (Score:2, Informative)
I'm not sure if that's a serious question or an attempt to troll, but regardless...
Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?
In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies". To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving. In my opinion, them, I don't really see the point in changing one's distro (including support lifecycles, development trust, and organization philosophy) just to swap out init. It's just not that big a deal.
It most certainly is if you manage servers!
Most performance evaluations include an uptime requirement. Most businesses it is 99.97% uptime while some Slashdot readers it might be as high as 99.99% or 99.9999% if they work at Amazon or a Wall Street trading firm where any downtime costs millions a minute.
If servers randomly do things behind your back or you restart one during a standard change and it doesn't come back up and your change window is between 1am - 3am (like my employer) you can be in hot water i
Re: (Score:3, Insightful)
It sounds like you should be looking into your high-availability architecture, not your init system.
Re: (Score:2)
99.9999% (six nines!) is 31.5 seconds of downtime per year. If you get an outage, it's not reasonable to expect anyone to be able to investigate anything in 31.5 seconds, let alone fix it. So any system with six nines of availability must be architected so that it is a cluster of servers, with automatic failover. If a single server crashing can take out your availability SLA, then the system needs to be rearchitected.
With 99.99% (52.56 minutes per year) of availability, having a backup server will still hel
Re: (Score:3, Insightful)
BWAHAHA!
Re: (Score:2, Insightful)
BWAHAHA!
You just don't understand the one thing that systemd is aspiring to do: replace.
Re: (Score:2)
The major issue people are concerned about is that things will be built on top of systemd (and they have been built on top of systemd), and then you have a huge unrelated dependency on this init system which makes it hard to swap out in the future if you want to use containers.
Re: (Score:2)
The major issue people are concerned about is that things will be built on top of systemd (and they have been built on top of systemd), and then you have a huge unrelated dependency on this init system which makes it hard to swap out in the future if you want to use containers.
I have been running Fedora before systemd (2010) was introduced and have never had an issue with it. I am now running Fedora 25 without any issues. Since my OS is on an SSD I can power up then login in then start my applications within less than one minute.
Just for you I started up my systemd configuration GUI and you can for "Units" and "User Units" see the following "Load State", "Active State", "Unit State" and "Unit". If I want I can "stat", "stop", "restart" and "reload" a unit as well as being able
Re: (Score:2)
Re: (Score:2)
Just for you I started up my systemd configuration GUI
Wow, thanks. Why would you do that for me? How does it at all relate to my post?
Re: Init alternatives (Score:2)
Let's rephrase that: Linux finally has an init system that does something devleopers find useful enough to make their software use that functionality.
How dare systemd be useful? It should stay as useless as all the rest, so that we can have more useless init systems and switch back and forth between those.
Re: (Score:2)
Re: (Score:2)
> In the spirit of "Do one thing and do it well",
That's generally a good idea but it's wise to consider whether sometimes a better solution is arrived at via integration of multiple pieces of functionality. One of the things I've really enjoyed lately is neovim. It's essentially vim, but amongst the improvements is a built in terminal. Why not use vim (or neovim) and tmux? Because having the terminal built in is just better, that's why. No need to install and configure the apps separately, and when y
Re: (Score:2)
The FreeSWITCH [freeswitch.org] bunch have a useful saying: "Don't glue the Lego pieces together".
A modular system is best enjoyed as a modular system. This is one of the most powerful things about unix systems, you can pipe the output of cat to the input of sed and feed that to a text file for editing by vi.
I don't have a dog in this systemd fight, and I agree with another poster who thinks this is much drama over not much. It is a sea change in how to think about things, but I certainly do not miss hunting down a missing
Re:Init alternatives (Score:5, Insightful)
> To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving.
Systemd has also taken over network configuration with an unnecessary DHCP service, which it should _not_ have touched, automounting, and is now attempting to manage user processes with misfeatures that kill user processes silently, such as the default enabled "KillUserProcess" command. Please be clear that systemd is not attempting to _manage_ processes. It is attempting to directly manage almost _all_ system services, many of them by direct replacement with dangerously incompatible and modified systems.
Re: (Score:3)
Re: (Score:3)
Doesn't fit, systemD is an octopus that grabs hold of something new before the old bits are stable. Didn't you see the article about how it is going to fuck about with shells and kill background jobs just because the user has closed their shell? That's not doing it's thing and it's definitely not doing it well.
Re: (Score:2)
Re: (Score:3)
I may be wrong, but isn't it that systemd also depends on things like dbus?
And again the problem is the mindset. Even though it might be possible to run systemd in a sane way, distributions now package it with all sorts of crap. The opposition against systemd is not about systemd itself, it's about people who constantly try to re-invent the wheel while not having understood the problem or how to solve problems in general. Just look at alsa and pulseaudio which were both attempts at fixing the previous state
Re: (Score:3, Informative)
I may be wrong, but isn't it that systemd also depends on things like dbus?
Systemd uses the D-Bus protocol for communication (e.g. between the systemctl client and the PID 1 daemon), but a minimal systemd install does not require the D-Bus daemon. That said, you'll be hard pressed to find a Linux desktop systems or server without the D-Bus daemon (no matter what init system is in use), but it'd certainly be possible to build an embedded Linux system with systemd init, and no D-Bus daemon.
Even though it might be possible to run systemd in a sane way, distributions now package it with all sorts of crap.
Really? Ubuntu now ships with systemd service management and the journal (and, yes, udev and t
Re:Init alternatives (Score:5, Funny)
Are you seriously asking such a deranged question or just trolling? We don't live in the 90s any more.
There is no reason, even with the price of electricity in Europe to shut your computer down, hence boot time is moot. And considering since 2005 or the whereabouts most people are on laptops, and it is relatively not so hard to find one with a working ACPI, hibernation to disk is what people do. Actual startup should only be performed after kernel patching (and not in all cases necessary) or hardware changes. Which is about 2-3 times a year at most.
Re: (Score:2)
I'd say security-patching the kernel is a pretty goddam good reason.
Re: (Score:2)
Re: (Score:3)
How come there is so much noise and heat about a small piece of software that runs maybe 2-3 times per year?
All of this is anger, just to be angry. It serves no purpose other than giving you that heady rush of Socially Justified Rage. And as the great master said, it only leads to suffering...
Re:Init alternatives (Score:4, Insightful)
How come there is so much noise and heat about a small piece of software that runs maybe 2-3 times per year?
Point is, it is neither small nor it runs only 2 to 3 times a years. It's starting to be a giant squid of interdependant parts (gnome depends on systemd now) that runs constantly (the init is always running, not just at boot), that is basically a kernel on top of the kernel, trying to control everything in userspace and "be the glu" between everything, and from which most people can't run from.
Re: (Score:2)
Seriously? (Score:2)
Issues of systemd aside, all those computers switched on doing nothing use up a boatload of electricity when you total the amount. Not only that, but leaving a machine on allows plenty of time for potential hackers to have a crack at it - unless you specifically switch off networking when you leave it - plus counter to what people think, computer components do wear out when left on, not just fans and spinning disks but also the electronics. If you only use your machine once or twice a day its actually bette
Re: (Score:2)
> There is no reason, even with the price of electricity in Europe to shut your computer down, hence boot time is moot
There is with Virtual Machines. You pay for uptime, a reboot is often necessary to add more storage or memory successfully to an existing VM, and even for local development VM's they take significant server RAM for their active kernels. For many VM's, proper nightly backup snapshotting also requires a short shutdown. Also, after activation of new services, it's often useful to reboot the
Re: hibernation vs shutting down (Score:2)
As one who has been burned by the inability of Windows to recover properly from hibernation, I just go right ahead and shut down. Next time I need it I know I'm getting a clean boot, not some corrupted version of the OS with funky looking screen and partially working subsystems.
I assume from context that you all are describing linux, but for those coming from the Windoze world it's once bitten, twice shy.
Re: (Score:2)
I have Linux servers that I rarely reboot (and they usually spend more time booting the BIOS than booting Linux with SysV or Systemd).
My main PC is a Windows PC and I reboot it less frequently than the servers, because I cannot back up the "state" (that is, open programs, open files, window positions, open connections), while the servers reboot and autostart all that I need, I just have to ssh to them again when I need to.
I have a HTPC that I shut down when not in use, and I installed an SSD after its hard
Re: (Score:2)
What "speed benefit"?
Re: (Score:2)
Re: (Score:2)
logging (Score:2)
My one question is logging....
what did they replace SystemD with and how does it log ?
the FAQ and the rest of the site is VERY bare...
Re: (Score:2)
what did they replace SystemD with and how does it log?
Unless they tell you so, you should assume they did something sensible like use something syslogd compatible, and if you don't like it, you can switch to another one. From googling I get the idea it's rsyslog.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Basic install uses SysV and rsyslog, at least that's what I got from the first Beta.
lol! "entanglement" is right! (Score:5, Insightful)
lol! "entanglement" is right!
What did Einstein call quantum entanglement?
"Spooky action at a distance".
What better way to talk about systemd...
Re: (Score:2)
We can say that of abstraction layers in general.
Apple has the same problem with launchd (Score:2)
Apple has the same problem with launchd.
In Apple's case, the trigger messages are not entirely asynchronous, as with systemd, but they may as well be, since the Mac ports being used most frequently do not have peer information available, and are (effectively) just integers.
This leads to what I call the "on behalf of" problem.
Something starts running. And you want to know *why*. Clearly, it;s running because someone requested one or more of the services it provides -- but there's no way to know who it is
Libre (Score:2)
Is there an option to install it with all non-free repositories disabled by default? As my man RMS says, Debian is better than Ubuntu because it at least segregates packages into free and non-free repositories, but still enables both by default. If the non-free repositories were disabled by default, GNU might finally have a modern distribution it could throw its weight behind.
https://www.gnu.org/distros/fr... [gnu.org]
My goal in running a GNU/Linux box is to not run a GNU/Linux box, and Debian and Ubuntu are really n
Re: Libre (Score:3, Informative)
Ubuntu separates non-free stuff into restricted and multiverse (as opposed to main and universe).
Main and restricted are the supported packages. Universe and multiverse are unsupported packages. Here, "support" means paid technical support from Canonical and a security update promise (as opposed to best effort) from the Ubuntu developers.
Re: (Score:3)
The fact that Debian doesn't meet Stallman's standards is a problem with Stallman's standards. Trisquel gives you what you are looking for, but when you can't use your hooble-dooble because the company is a bunch of apes that never made a FOSS driver, you'll be angry at the company, and a little angry that you didn't bend for just that one thing. You can run Debian as a fully free software Linux build, why is that not good enough? Because you could, if you wanted, not do that?
Their rationale on not inclu
Re: (Score:2)
Says who?
Re: (Score:2)
Re: (Score:2)
>Trisquel gives you what you are looking for, but when you can't use your hooble-dooble because the company is a bunch of apes that never made a FOSS driver, you'll be angry at the company, and a little angry that you didn't bend for just that one thing.
I guess. I run a headless server, device drivers aren't much of a concern for me. My main concern is minimizing the amount of work I have to do maintaining the server, including security patches and updates to the latest version of source code. I hate was
Re: (Score:2)
I hate wasting my time.
Oh, I LOVE it! Why, just now I find myself sitting on my butt reading this whole thread, for example.
Let's roll! (Score:2)
Greybeards? (Score:2)
We may have been programming for longer than Lennart but there are plenty of people younger than him that don't make the same arrogant newbie mistakes about *nix.
Somebody should give Lennart "The Cathedral and the Bazaar" to read since he missed it the first time. It's not difficult but for some reason he does not understand or care and wishes to change linux entirely.
Re: (Score:2)
> yay gentoo! Its very easy
no
Re: (Score:2)
yay gentoo! Its very easy to avoid that systemd garbage. I'm not just bandwagoning here, I have to setup RHEL7 for a very large company because they wanted to stay with RedHat. It was hell on wheels. RHEL7.1 was a slight improvement but still not enough to ever consider it again.
I would kill for a systemd-free rebuild of RHEL, but it doesn't seem like there's enough of a push to be able to make it happen with some sort of plausible enterprise ability. It wouldn't be that hard -- basically take RHEL7 and stick RHEL6's initscripts and startup system onto it -- but it wouldn't be "EL7", which is important.
A systemd-free version of Fedora is tricker, if only because LP and friends have succeeded in burning as many bridges as possible within the base install away from any other init par
Re: (Score:2)
SystemD is available as an option on Gentoo. It is however not the default. If you really want it, you can have it.
Re: (Score:2)
Gentoo lets you use systemD if you want to, hence the availability of systemD packages for Gentoo.
However, OpenRC is the default.
Re: (Score:2, Funny)
> Slackware
Correct
> Slackware still
VERY correct
> Slackware still works
MOSTLY correct
> Slackware still works great
For certain values of "great"
> Slackware still works great, and has never had systemd.
True, but they aren't on record saying that they won't.
Re: (Score:2)
Re: (Score:2)
Unfortunately, that is very likely.
Re: (Score:2)
Well, yes. Fortunately I use not one of the technologies in your list (with the exception of a small number of applications using gtk+, all of them replaceable by others), but the "normal" Linux user begins to be screwed almost as badly as a Windows-user.
Re: (Score:2)
You can fork systemd, except you don't have a team to help you and a company to pay you, so in practice, you can't really.
I do not need to. I can use sysIV init. It is finished, reliable, reasonable fast. No need for maintenance. And in the same venue, I find that packaged that need boot-scripts but do not support sysIV init are not worth using anyways.
Re: (Score:2)
Re: (Score:2)
Not Microsoft. Red Hat.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: FreeBSD (Score:2)
Yep dtrace, jails, high uptime, and ZFS oh and init have no appeal at all!
Re: I'm still waiting for Horse Buggy beta 2 (Score:2)
Debian never gave guarantees for anything but their default init. That has always been like that, it is just the init that changed. How could a responsible distribution make claims that init systems it never made am effort to test is supported?
I think users are mostly happy (or blissfully ignorant about init systems) with systemd. If they were not, then users would storm devuan. That distribution has seen lots of press when it started, so people did know about what is happening there, yet interest does seem