Slashdot Mirror
Debian To Replace SysVinit, Switch To Systemd Or Upstart
An anonymous reader writes "Debian has been one of the last holdouts using SysVinit over a modern init system, but now after much discussion amongst Debian developers, they are deciding whether to support systemd or Upstart as their default init system. The Debian technical committee has been asked to vote on which init system to use, which could swing in favor of using Upstart due to the Canonical bias present on the committee."
But that doesn't mean that Upstart does.
"When information is power, privacy is freedom" - Jah-Wren Ryel
I fucking hate this new system. Its a mess of scripts that call on more scripts. Its such a pain in the ass now if you want to have a program run when the system starts. Gone are the days of just adding a line to /etc/rc.local
Only the State obtains its revenue by coercion. - Murray Rothbard
Because of the anti-Canonical/Ubunutu bias present on the committee.
now that would be awesome. fighting over minor syntax. the loser grabs a fork and goes on his merry way
next up we tie their beards together and have them fight it out
It sucks because of upgrade issues with /run/initctl and new dependencies on DBus, etc...Plus upstart is a running proc....
Init would have been my pick, but I still hope this works out well for them.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Why not keep sysvinit and switch to OpenRC for managing the init scripts?
If they start replacing SysV init with Upstart I'll start looking for a new distro. I've run Debian since I got a VA Linux Debian Slink CD, but that would do it to get me running.
If they have to switch away from sysV init then systemd is better supported by various upstreams and is not locked in with only Canonical developers (and copyright assignments to them etc.)
Fuck Ubuntu.
Actually, that's how sysv init works. To get a program started by systemd you have to create a service file full of magic commands and put it in the magic systemd directory. Then you have to type systemctl --abracadabra enable yourservicename.service. Then you have to go and add an [install] section to your service file, because nobody actually remembers that you have to write one or how to do it. Then you do the systemctl again. Then you check the log files to see if the thing actually started, because nothing gets output to the console during boot (except the filesystem mount messages and the big fat warning that my root fs is readonly).
Tell me I'm not the only one still clinging to sysvinit?
The new "replacements" (alternatives) are ghey++ and will no doubt be replaced in due time.
I dno't want to hear about a few seconds faster boot time. I want my *nix startup to be configurable, scripted, and simple. sysvinit takes the cake;.It's documented, and sysvinit is so simple it doesn't really require documentation, anyway.
This is your way of stating your opinion? Looks, like your parents forgot to teach you something particular important to be considered an adult and able to participate in a discussion. You could say that you disagree with Canonicals decision towards Wayland/Weston. You could say that the way they handled the issue and announced Mir sucks and was not a cooperative mode. In addition they made some bad blood. And that all would sound like someone really discussing the issue, but really you just sound like someone either too young to remember the vi vs. emacs wars or like someone exhumed from that day, just to behave like a troll.
BTW: Get a life, normally that reduced these urges to hate someone just because you find his or her decision questionable.
What would the BSDs do? Actually, what do the BSDs use? And since Debian does kFreeBSD as well, will they use Upstart or Systemd here as well? What will they do for their HURD version? Same for all 3, or pick according to the OS?
I used to not only use RedHat, but contributed fixes. Ubuntu is not, in many respects, my ideal, but systemd is enough reason all by itself for me to use Ubuntu.
SysV init scripts just work. They are simple to create and easy to maintain. Debugging is a cinch when things go wrong -- and a lot of packages DO NOT get upstart init, nor SysV init correct. Upstart is only easier in theory. In practice it's made a complete mess of things and I have several Ubuntu systems to prove it.
Join the Slashcott! Feb 10 thru Feb 17!
On a Gentoo box, and it should still be starting via sysvinit.
My #1 reason for keeping it installed is standardization:
All the BSDs use a similiar system, all the legacy UNIXes do as well, as do all my linux installs that are more than 2 years old.
Additionally I have had *NO* problems with it in like 15 years that weren't caused by user error, or distro error. Systemd on the other hand rendered my system hung or inoperable on more than a few occasions when it first became popular, as has udev by itself. There's something to be said for 'windows-like' functionality, but all the subsystems that have been getting added to linux to provide it are proving messy, unmaintainable, and even more prone to 'unidirectional grading' (it used to be you could have both newer and older kernels, even across major versions running. Nowadays you're lucky if the minor versions don't break things over the span of two months. Anyone here remember having 1.2 installs running 2.0? Or 2.0 with a 2.2 kernel? Or 2.2/2.4? The only major issues you had were if you used ipchains/tables/ipfwadm and had to migrate your settings. And there was almost always legacy support for most or all of a major version change.)
Honestly with the way linux is going nowadays, as well as the various *BSDs, I'm considering very strongly migrating to another platform. If you change what people are used to too much, there's far far FAR less incentive for them not to try something totally new rather than bungling themselves up with half remembered details about how their *FORMER* version of the system operates. Much like happened with WinXP/Vista/7/8.)
Not that many people will agree with this assessment.
That sounds retarded. Why would anyone wanna change to that? It's all one command currently (in Debian, which I've used for years), update-rc.d with simple params and done?
What is it with all these different ways of doing the same thing, it takes the TIMTODI idea and stretches it somewhat. Solaris has SMF, RH has systemd, Ubuntu has upstart, DOS has autoexec.bat, can't we just agree on one thing, init.d is a happy middle ground for me.
Why UNIX?
This sounds like a really awful idea, based on what I've read here. I like how Debian's init works now, its fine, there's nothing wrong with and it's simple.
Where the heck do I send hatemail to perhaps encourage them not to do this?
Citation needed, anonymous. When has the Debian Technical Committee last made a decision based on a political bias?
It seems like I'm the only person on here who thinks this, but I really can't wait for the switch to happen. Upstart scripts are unbelievably easy to write when compared with init scripts. For one thing, they don't require massive amounts of boilerplate code. For another, they are relatively easy to manage and execute.
Just the other day I was trying to set up a couple of machines running deluge as a daemon. The Ubuntu machines took me 10 minutes tops. The remaining debian one had me in init script hell for an hour or more...
sysvinit isn't a bad idea, but, IMO, it's too complicated. But obviously I'm biased, since I like the *BSD's rc system.
The thing that gets me with linux is that narely a look is spared to what exists already. It obviously isn't good enough, for reinventions are calling out in dire need of getting reinvented. And so there are at least two, but possibly as much as half a dozen contenders, all different, none of them compatible with what was, what is, or what shall be. Because it's the linux way.
Troll, me? Possibly. But what if it's true? Bring on the downvotes anyway. You know you want to.
We want to change to "that" because basic idea is a good one. The ability to start services in parallel, socket activation, and cgroups for process group management are all good things. The problem with systemd is not so much these ideas, but the implementation. To put it bluntly, the developers are all "superstar" jerks who wouldn't know usability if it hit them over the head.
They designed an ugly interface with way too much automatic magic that no doubt is perfectly obvious and correct to them, but abstruse and incomprehensible to anybody outside their little circle. Then they wrote a couple of "howto" articles on complex sysadmin tasks that almost nobody has to do, and declared documentation complete. To do a simple task, like writing a service file, or God forbid, changing the getty program you want to use, requires a monumental effort of sifting through disconnected, unintuitively named man pages.
systemd: good idea, horrible implementation.
So upstart has some things that need to be fixed (mostly the clean shutdown thing)...
Systemd is a monster that gets to infect more of you packages over time, plus you get the benefit of binary log files!
I hope they choose upstart and just fix it up a bit.
OpenRC has been proposed by some too, which seems like a nice sysvinit replacement, but event driven startup and shutdown of services (think laptops and hotswap stuff) is more important than just a fast startup time.
Nobody wanted systemd, other distros went along after they took over udev maintenance. Sane heads were left pointing at pulseaudio and screaming "keep this fool away from init".
All's well that ends well though and I just love having "systemctl halt" break whenever I upgrade dbus. This kind of functionality takes a special kind of software engineering genius.
Get the SMF framework, and make everything XML driven !
I cannot abide the SysV (AT&T) mess'o'symlinks multiple-indirect startup scripts. One reason I've stuck with Slackware for almost 20 years. It uses BSD-style inits that have far less indirection and need far fewer lookups. Frankly, some of the BusyBox startup look attractive too -- one script to rule them all :)
Debian should stay true to its core principles. The user should be able - by installing a package - to choose the init system she wants.
There is no one true mail server on Debian. You can choose to run zsh as a shell instead of bash. There should never be only one supported init system.
Distributions don't choose, users do. Oh and technical committees are there to find solutions to make that work, not to complain about how difficult that is.
Please tell me how to reboot or shutdown a systemd based distro if the /run/systemd directory got deleted by accident.
And systemd is a tentacle-monster which tries to suck in any other component of a linux-distro. Session-management, udev, cgroups, loging ...
I hope for systemd; I know it from Fedora. And in my opinion upstart is some kind of mess; it's a mixture of bash script and their own added syntax. It kind of feels like Microsoft's extensions for C++. I'm also a fan of declarative configuration like systemd is. After 5 minutes reading the manual of systemd I could write my own service for pdnsd.
[Unit]
Description=PDNSD
ConditionPathIsMountPoint=/mnt/read
After=NetworkManager.service
[Service] /var/run/pdnsd.pid
Type=forking
ExecStart=/usr/local/sbin/pdnsd --daemon -p
PIDFile=/var/run/pdnsd.pid
[Install]
WantedBy=multi-user.target
# systemctl status pdnsd /var/run/pdnsd.pid (code=exited, status=0/SUCCESS) /usr/local/sbin/pdnsd --daemon -p /var/run/pdnsd.pid
pdnsd.service - PDNSD
Loaded: loaded (/usr/lib/systemd/user/pdnsd.service)
Active: active (running) since Mon 2013-10-28 18:46:23 CET; 1h 14min ago
Process: 1585 ExecStart=/usr/local/sbin/pdnsd --daemon -p
Main PID: 1587 (pdnsd)
CGroup: name=systemd:/system/pdnsd.service
1587
Oct 28 18:46:23 vostrotitan.localdomain systemd[1]: Starting PDNSD...
Oct 28 18:46:23 vostrotitan.localdomain pdnsd[1587]: pdnsd-1.2.9a-par starting.
Oct 28 18:46:23 vostrotitan.localdomain systemd[1]: Started PDNSD.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
...abstruse and incomprehensible to anybody outside their little circle.
Its "obtuse", but your point is taken. But let's be honest, many, if not every, circle of technical wizards in charge of a popular project gets infected with elitism to some degree. I will say however, and without really understanding the exact technical reasons canonical seems to be taking the technical "high road" and laughing some of their userbase writhes in pain on the ground behind them.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
Mozilla Circus renders the system-level init mechanism almost moot. Besides, things like systemd and udev aggressively couple system-level facilities with the GUI user-space system (via DBUS messaging, etc.). These designs are about as anti-Linux/UNIX as it could possibly get. From hard experience, I can attest to the pain down the anti-Linux path ...
Please tell me how to reboot or shutdown a systemd based distro if the /run/systemd directory got deleted by accident.
Wait, seriously? You don't know how to kill processes and umount filesystems? YMBNH
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Because:
1. What sane organization wants to follow in Canonical's footsteps?
2. Who, besides an utter fool, thinks systemd is a good idea?
No Solaris SMF was a good idea, systemd is what you get when someone looks at that idea and says "you know what, I can fuck that up."
"I use a Mac because I'm just better than you are."
To shutdown: yank the power cable.
To reboot: yank the power cable, then plug it back in again. Then depress power button if necessary.
Accompany either process by shouting the magic words "fuck it, it'll probably be fine".
At a former university the Linux side of the desktops used Slackware with initscripts all the way up until 2011. These desktops were beefy machines with decent chunks of RAM and SATA disks but would take minutes to finish booting. The administrators there switched the start-up scripts to systemd over the holidays and things were so much better - no boot took more than 30 seconds to finish (most took less than 15 seconds) making the old system look laughable.
SysV initscripts have had their day and it's time to move on.
At a former university the desktops used Slackware with initscripts all the way up until 2011. These desktops were beefy machines with decent chunks of RAM and SATA disks but would take minutes to finish booting. The administrators there switched the start-up scripts to systemd across a holiday and things became dramatically better - no boot took more than 30 seconds and most disk based boots were sub 15 seconds making the old system look laughable.
I'm glad that Slackware gave the admins the choice because the old way of doing it has had its day. Not everything from the 90s was better...
You need to remember that most of the time Debian is not about developing new stuff, it's primarily about PACKAGING and DISTRIBUTING existing stuff.
From "package a bunch of software into an usable system" standpoint it is a smart decision to wait until the dust settles and things are tried and proven. Especially if you are producing system as stable as Debian Stable.
--Coder
It's not needed now SSDs are common and cheap. My Debian boots in under 5 seconds, thank you very much.
I do agree bootup times don't matter if you run a server. For a laptop, a tablet, a mobile, even a desktop that gets turned off startup times are important. For tablets, laptops and mobiles, they are VERY important.
:-/
I agree that complexity is evil. I have no experience with systemd nor with upstart, so I cannot comment on them. However, dependency graph and parallel execution should not be THAT difficult or complex
--Coder
Killing process isn't the point. Just try it for your own.
[detached]
FTS: The Debian technical committee has been asked to vote on which init system to use, which could swing in favor of using Upstart due to the Canonical bias present on the committee."
So what are the chances of getting the Canonical-associated board members to recuse themselves from the vote, given the obvious conflict of interest there?
Nothing to see here
There are reasons to do more than that, but they all add complexity. Some developers are more interested in new features than in reducing complexity.
Ie, if you want graphical control over "services" then the current method of dropping any old random script in a directory is not too helpful. Also all the SysV style scripts are assumed to run sequentially and are ordered via priority in the file name, which makes it more difficult to start a lot of things in parallel (not a big deal for a server but some people want fast boot ups). Other things like that.
Personally, I'm in the keep-it-simple-stupid camp but I can understand why some people want it changed.
systemd service files are quite straightforward---I'm not sure what kind of monumental effort you are referring to when creating service files. For a simple service, starting/stopping/restarting the service is handled automatically, leaving a very minimal service file.
For example:
[Unit]
Description=AutonNav
[Service]
ExecStart=/usr/sbin/autonnav
Type=forking
[Install]
WantedBy=multi-user.target
And that is a good thing for Linux because it can use a lot of good technology from the kernel. The major issue is that systemd requires cgroups and that means no support for kFreeBSD. Even if the ex-Canonical people recused themselves, systemd was always going to have an uphill battle.
There is a Debian derivative that has decided to use systemd, but it's -- the still incubating -- Tanglu.
After having repeatedly run into the limitations of SysV init, I'm all for replacing it with something smarter, but I'm torn between these two.
I've used Upstart on Ubuntu, both as an admin and as a developer. I like that the commands and configuration files are clean and pretty easy to understand. A few things bother me, though:
I haven't used Systemd at all, but the common points that come up again and again in every writeup I encounter have me forming me some opinions already. I really like the idea of the load-as-needed dependency model. A few things have me quite worried about the implementation, though:
I'm still not sure why we, or I, need to change from SysVinit.
You can't control systemd... without rewriting all the given startup files to force a serialization... and then you are defeating systemd.
You can't debug problems with systemd as it hides most of the evidence you need to fix problems.
It still can't shutdown a system reliably - it hangs, sometimes.
It still can't boot a system reliably - again it hangs sometimes - though at least with a boot hang you know It hung.
It does work in simple environments... but not very well in complex ones. The interactions between processes is too complex and when errors occur it is nearly impossible to identify what caused it.
Its "obtuse", but your point is taken
Actually, it is "abstruse".
abstruse
adj. Difficult to understand; esoteric; recondite.
And when it hangs you have no choice but to crash the machine again...
And finding out what hung the shutdown is rather difficult...
And it really doesn't boot faster than any properly set up sysVinit system.
systemd is a solution in search of a problem. Let's see what they are trying to do:
1. Speed up the boot process? The reason SysvInit is slow is because most distros have 3500 or so kernel modules in their build. They want one set of modules for everybody. My system has exactly one (proprietary) module and boots in about 8 seconds on a system I bought in 2005.
2. Use cgroups to contol processes? For 99% of systems in use, this is unneeded. Perhaps we are going back to the 1990's where one large system provided direct accounts for hundreds of users, but that is the exception. A server has a few system accounts and maybe a couple of developers. A workstation generally has one account. Yes, a supercomputer may have a lot of accounts for submitting to a queue, but outside of that, cgroups are really unneeded. The beauty of Linux is that we don't need a one-size fits-all approach.
3. Binary logs? Enough said.
4. Simplicity? Not hardly. systemd has about 150K LOC. My sysvinit system has about 2K of bash scripts -- about 75% of which are comments. I once complained about the complexity of systemd and was told that there were over 100 pages of documentation. My response was that the problem with systemd was that it *needed* 100 pages of documentation.
I am afraid that Linux is being driven away from the philosophy of creating simple programs and allowing the users to do things in their own way. Complexity is being forced upon us, even if we don't need it.
Just FYI, "abstruse" is a real word that means difficult to understand.
You're retarded.
If you delete /run/systemd/ you need to reboot your brain with a .45.
Nothing is stopping you running your init scripts in parallel if you need it.
This bullshit is one of the best reasons to move off of linux and onto FreeBSD stack.
I have used linux since 1995 and all this change because "I can" has forced me off linux and onto *BSD.
I wanted something that just works.
If I didn't want a *NIX environment I would just use MS Windows.
Hell even windows is better than linux these days.
It's a well thought out post.
Control groups of course are at the center of what a modern server needs to do. Resource management of services is one of the major parts (if not the biggest) of service management, and if you want to stay relevant on the server you must have something in this area.
-systemd apparently does this?
-upstart does not.
For me, this is exactly the right direction, but I'm biased to server applications. ...The kernel folks want userspace to have a single arbitrator component for cgroups...
-systemd has this
-upstart apparently does not. He has grave doubts about upstart being able to do it.
I don't understand what he wrote.
ether you take the path where you use the stuff that the folks doing most of the Linux core OS development work on (regardless if they work at Red Hat, Intel, Suse, Samsung or wherever else) or you use the stuff Canonical is working on (which in case it isn't obvious is well... "limited").
It's an accurate assessment. How is that FUD?
I do agree bootup times don't matter if you run a server.
Indeed.
And isn't Debian mostly used on servers?
I know it's what I use on all my servers, while using Ubuntu these days for my notebook. If my notebook can boot faster when I need to restart it, I'm interested. But for my servers, no thanks. What is wrong with the simple and reliable SysV init scripts used by Debian now?
These were good admins, there were a lot of NFS3/4 shares and it was part of a Kerberos domain but maybe your setup is better tuned. I don't think it was misconfiguration and seeing how things sped up so dramatically after the change... But if it's that hard to get it right with initscripts that's another nail in their coffin in my book.
Human readable initscripts can be far more complicated than systemd units but it depends massively on the task at hand. Some initscripts can be horrific - the Debian Apache initscript is not simple (but it does a lot so...).
How often do I reboot *nix boxes? Varies massively from "only when glibc and kernel changes are released" (so a few times a month tops) to a few times a day. In my previous example many of the machines were in computer labs so they would shut themselves down every day. When you are watching these machines boot up at start of the day you really notice these things. 40 machines just sitting there with text sporadically appearing just to get to a greeter which Windows 7 reached in less than half the time until the systemd switch wasting students tuition fees in practicals - bleh. I even notice boot times on my VM's at work these days - when I spin up 10 Linux VMs from scratch it's nice seeing them all ready in under 40 seconds. Even on my creaky EeePC it's nice being able to get to the desktop from cold in less than 20 seconds.
I'm happy work has been put into improving boot speed over the years - it really has become much better than it was back in 2001 even though more is being done. Stuff like systemd is even solving some long standing problems which used to require hacks like portreserve so it's not just speed.
Killing process isn't the point. Just try it for your own.
I have. If you can get all the appropriate daemons terminated and your filesystems unmounted or read-only, you're done. What were you hoping to accomplish, having the machine turn itself off? Who cares?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
systemd falls into the same trap as "desktop environments". It starts with appealing goals (basically, make startup a graph that is traversed parallel-breadthfirst), but it winds up sucking. Consider what happens when systemd dies. This happened to me recently (fedora19, upon resume) - there's not much you can do except reboot. Yes, this could have happened with sysvinit, but who among us ever had a crash of init? I certainly haven't, and I'm a certified greybeard.
AFAIKT, the problem is that it's trying to borg a whole bunch of subsystems that do a great job by themselves. For instance, systemd tries to replace syslog for the most part. It's easy to see why it would want to do this, since daemon/server IO is a useful part of managment. But trying to do so, the system becomes more fragile and *narrower* in its applicability - more specific to how one guy (Lennart) thinks every system should behave.
I suspect what will happen is that systemd will get shaved down a bit with some of the excess functionality removed, and in the process will become reasonably robust (ie, NEVER crash).
There is a BIAS against systemd in Debian, yes. But it is caused mostly by the lack of FreeBSD support and the general instance of systemd upstream of trying to take on the whole core plumbing in a way that would make *any* proper system engineer rather nervous.
Now, systemd doesn't have a track record that helps one to sleep at night *even after porting it to FreeBSD*, either, because it is certain to embrace something idiotic just because (e.g. user namespaces, because someone will have the brilliant idea that systemd also needs to be a light-container manager). AND its chief architects DO have a track record that is very detrimental (pushing half-baked experimental non-designs).
Now, maybe kFreeBSD doesn't look interesting, but both Debian and Gentoo believe it to be a good idea to have a escape route from Linux for their users should a corporate war make it not a viable option somewhere in the world.
Mod parent up, simply for the "anti-Unix" pappp.net article link.
Its daemon management, It by its nature touches a lot of stuff to do its job well. Now the relivant question is, could it do everything it needs to do in a cleaner fashion with well established interfaces allowing other programs to do the same thing, while also limiting systemd to just do a subset of it. Leinart seems think that's a silly goal, to have a daemon manager that isn't as good as it could be.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Size and complexity
Upstart (1.5): 285 files, ~185k lines, ~97k C
Debian: sysvinit + 120 files, 5.8k lines
systemd (v44+): dbus + glib + 900 files, 224k lines, 125k C
sysvinit: 560kB, 75 files, ~15k lines
Debian startup is smallest, it's only shell with sysvinit (C) as dependency
Upstart is about 10 times bigger in terms of lines of code/text. Most of the extra complexity size comes from C.
systemd is about 10 times bigger, like upstart. But with the mandatory deps it blows up to about one hundred times the code footprint! Most of the extra code is in mandatory dependencies, but the systemd core is also bigger than anything else.
http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems
What was wrong with launchd or rc.d?
sysvinit works great, because it's almost trivial to copy some random init script for $application made for say FreeBSD, and use it on Debian. In many cases you can simply copy away and it works fine, in others some small modifications to a shell script are needed. Easy.
Init scripts are also great in that they can do *anything* you want them to. Need to purge some old tmp files before startup? Add a single line of code to your shell script. Need to do other complex hackery to get around OS-specific bugs? No problem. Just have some ghetto script you want run on boot? Add it's path to rc.local and done/done. No fucking around.
While systemd sounds interesting in an ideal world, you just have to look at how Windows is an absolutely inscrutable mess on startup to see how this is going to go. Good luck actually debugging shit when something random fails. Trying to replace syslog? wtf. Have any of these devs actually administered hundreds of machines?
Anyone working on a machine in a remote datacenter, for starters. Which is where Debian machines are far more likely to be found, by the way.
Hmmm. I do believe he was quite correct and did say what he meant to say. If it were not abstruse and incomprehensible then only an obtuse individual would have difficulty with it.
Anyone working on a machine in a remote datacenter, for starters. Which is where Debian machines are far more likely to be found, by the way.
Wait, you're telling me that you don't have some remote power functionality? How rinky-dink is this data center? And why aren't the machines virtualized?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Multi USB to VGA support? Please?
I think I've only ever seen a boot that took ten minutes (or longer) in the case that fsck had to run to check a disk and I'm not counting that. I'm also not including time spent in the BIOS. I guess I should have said "a few minutes" to be clearer though.
Well, I've been running Debian Sid on my desktop (and now laptop) for last 10 years. Works well enough for me...
I know Debian doesn't spend that much time polishing the desktop experience, but installing vanilla XFCE and tweaking it a bit is all I need. And having all the power of Debian at the fingertips is very nice.
--Coder
There are more things in heaven and earth, than are dreamt of in your philosophy, drinkypoo. There are, in fact, use cases for which virtualization is not particularly appropriate.
As for the remote power... it was determined that it was needed rarely enough that the per-incident "pay the NOC monkey to push the reset button" fee was more cost effective than a dozen remote-controlled power units.
I'd rather that frequency didn't change because someone said "I've made basic sound support a complete clusterfuck, now lets see how I can screw up the boot process."
I've had some dealings with systemd on Fedora. Oh, it's *so* much easier to find the magical names of services (as opposed to, say, ls /etc/init.d/), and start and stop them. Oh, it's all so much easier. And configurable? Just like grub2....
mark
--
grub2 must DIE!
Restore the directory from backups, proceed to `shutdown -h now`. Let me guess though, you don't have backups?
If the configuration is gone, and you have no backups, I could see a few paths to take from there: :p
1.) Reinstall systemd for starters, then figure out what is running on the system, download each of their packages (if necessary), extract only the systemd scripts into the systemd directory.
2.) Backup what information and configuration you need and perform a full reinstall.
3.) Write your own script to safely bring down your processes, unmount your filesystems and send a signal to the machine hardware to power down.
Deleting important files sucks, but hopefully you have learned your lesson. You can blame others for this issue if you like, but it doesn't help solve your problem at all.
phillistines. ms-dos edit and then dos2unix when done
I remember learning the edlin command set pretty well. My roommate mocked me, but I defended this use of time by saying "every computer will always have edlin on it".
I can still feel the scorn of his laughter when MS-DOS 5.0 replaced my trusty edlin with that monstrous "edit" bloatware. :'(
https://en.wikipedia.org/wiki/Edlin
I'm happy to see that the FreeDOS project includes a GPL-licensed version of my beloved edlin...
"edit" indeed!
Nothing is stopping you running your init scripts in parallel if you need it.
Quite true, actually I think in Debian this is already supported for the system boot sequence at least since Squeeze.
Together with dash being the default /bin/sh now, it already boots pretty fast, I don't see the startup time being a major factor in this decision.
It's probably more because of the fact that systemd now reaches into areas beyond pure service control that forces Debian to either follow that move or switch to another alternative that has enough manpower behind it.
I don't care what they replace it with, so long as there's a flag/switch/option somewhere to make the boot deterministic and identical across systems and across boots.
We run ~5000 diskless clients using Debian, booting via PXE/TFTP and mounting all filesystems via NFS.
With Debian 5, everything ran perfectly. With Debian 7, the boot is now very racy and too many things depend on the speed of the network (some services start before their dependencies are ready). We actually had to turn on verbose boot messages in order to slow things down enough for everything to boot correctly. We're testing the "don't run in parallel" flag now to see if that fixes things.
It's virtually impossible to debug a concurrent/parallel boot system, as every boot is just slightly different from the last. With the original sysvinit system, where things ran in series, one after another, it was very easy to find problems and fix things.
We don't care if the computer takes an extra 15-30 seconds to boot; we boot everything in the morning via WoL before classes start, and they are rarely booted during the day. What we do care about is being able to debug problems and make things work the same, time after time after time.
Upstart doesn't sound like it helps much in this area. Don't know about SystemD.
Both upstart and systemd will support unmodified initscripts. It can make your boot slower but it preserves backwards compatibility so your wish has been already been granted (albeit in reverse)!
You can still use startx even under systemd and upstart (e.g. if you boot to runlevel 3 (which is also emulated)) assuming your setup has provided it.
GRUB 2 is very configurable. It's also far more convenient to get from a broken state (low-res boot console and missing drives) to OS, since I can load GPT and LVM drivers from its console. It's especially handy to have when stupid retarded motherboard vendors (ASRock 990FX Extreme9, "BIOS" versions 1.30, 1.40, and 1.50) include a fucking broken "built-in EFI shell" that hangs after showing a list of devices 100% of the time. and provide no built-in support for booting a shellx64.efi from the ESP. Also, a broken nvram that consistently deletes every other entry every time you add one is annoying. (U)EFI GRUB2 on a USB drive is a life saver.
Good luck w/that.
I hope you don't expect to update any SW on your system for a while.
opensuse has gone out of their way to make their systems NOT be systemV compat... including moving to a requirement for booting from a ramdisk image (because systemd doesn't handle PATH, it uses fixed paths for it's binaries), integrating the power, device, udev and logging subsystems into systemd, with logging going to a binary MS-like format that is, by default, not saved.
Also put all the var/run files on ram disk, so progs that were used to their own directory for run /var/run/dir/xxx so they could run as non-root, need to have it recreated each boot....
it can be real hairy trying to get around all those problems and opensuse's official position is that any other config (including booting directly from your hard disk) is not supported.
I would be surprised to find these issues with Debian, they tend to be very good about avoiding breaking compatibility with different options.
"I opened my eyes, and everything went dark again"
Lennart or Canonical (i.e. S.J.R.)
Both suck in some way but systemd sucks less..and has more clever features, is more cared about. Obviously Upstart was forgotten for a while, I think the lead developer left it untouched for a while. So let systemd win, except - for kFreeBSD. That is a real problem. Debian folks should reimplement configuration file API on top of *BSDs, with whatever they get in their kernel. or just let it die as it probably deserves. Or keep old scripts which is a burden (especially when the system doesn't start).
Linux ftw but unfortunately hurried up by Lennart et al.
They were bought out by "attachmate" -- a maker of appliance like office support stuff. Suse was a desktop & server company, now they are focusing on a closed & secure boot for supporting user-tamper proof appliances -- not that it won't be usable for laptops and such, but makes user control and configuration much more difficult.
They claim that they are following in the steps of redhat on many of these issues who's also going to have a secureboot offering (booting w/binaries signed by MS-certs.
*shiver*.
It's only straightforward if it's documented somewhere in a sane, complete and concise manner. Is it in a manpage? If not, is it installed by default at least?
If you believe Pulse is rock solid or used by the entire world, I can only imagine that you don't get out much. The rest of your comment seems to be responding to something that I didn't write, so I guess I'll ignore it.