Hi, I'm Subsentient, the original author of the Epoch Init System. It's been around a while, and it does the job I gave it well enough for me, but Epoch has failed to reach its ultimate goal of becoming a viable alternative to systemd. This is for a few reasons, among them being a total lack of parallelism, difficulty for package maintainers to easily set up services, and a codebase even I myself am ashamed to admit I wrote. I got some things right too, like good documentation, powerful service management, lack of dependencies, and unintrusiveness, but it seems it wasn't quite enough, because the most commonly requested features were true dependency support and parallelism.
I'm doing a near-complete rewrite of Epoch, save for the few parts of code that were well-written, and it will be called Epoch-ng (next generation). While dependencies, parallelism and easy package manager support are the big things, I think I'd like to get feedback on what Linux users actually want from an init system, and I'll try to write an init system that does its best to meet everyone's desires.
So, what would you like to see in an init system? What would you like to NOT see? I'll be taking this feedback seriously. :^)
-Subsentient
(Score: 0) by Anonymous Coward on Wednesday June 01 2016, @09:39PM
Why would you use a new name instead of a new number? Remember, MS-DOS 1.0 and 2.0 were wildly different, and it wasn't a big deal because 1.0 hadn't had much adoption.
(Score: 2) by Subsentient on Wednesday June 01 2016, @09:46PM
Because the new system breaks virtually all compatibility with the old one. Try and use your old configuration with the new one, it'll give you a confused stare and then kernel panic.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 3, Informative) by Anonymous Coward on Wednesday June 01 2016, @10:17PM
well, semantic versioning allows for that, so you're fine. see http://semver.org/ [semver.org] for details.
in brief, if you change the slowest counter in your version, it means you break backwards compatibility.
however, since the function of your code is more or less the same, and it's a rewrite of an older version, it's logical to keep the old name.
(Score: 2) by Marand on Wednesday June 01 2016, @10:34PM
The AC's right, there's no reason to throw out the name over some compatibility changes. When the Linux kernel went from 1.x to 2.x it was a pretty major change but there was no reason to name it Linux-ng. Perl 5 to 6, Python 2 to 3, KDE 3 to 4, grub1 to grub2, etc.; in all cases there's major breaking changes but as long as it's made very clear it's usually okay.
Grub's a pretty good example here, actually. They're extremely different designs, to the point that about the only thing they share is the name, but it hasn't been a huge problem. Distros still provide both versions, and end users can choose which one they want. Grub2 has its issues, but they're more about how it made its new configuration format a giant mess compared to the old one, rather than a compatibility problem between versions.
Just don't be ashamed of the old work and try to sweep it under the metaphorical rug. Let users stick with the old one if they want, make it clearly available and easily downloadable at some sort of "old versions" link somewhere. The problem tends to be when someone goes "my new shit is better than my old shit, nobody will ever want the old stuff, so I'm going to take it away." Creators (devs, artists, etc.) have a bad habit of that, because we don't like being reminded of our mistakes, and that's what ends up pissing off the end users/viewers/whatever. Be proud of the old work no matter how bad it is, leave it online, and let people choose.
Bonus points if you create a configuration migration tool from Epoch 1 to Epoch 2, too. That can go a long way toward helping make a compatibility-breaking change less painful.
(Score: 2) by tangomargarine on Thursday June 02 2016, @02:33PM
Plus let's assume you get actual adoption. Fast-forward to 10 years from now and "next generation" starts to sound silly.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by urza9814 on Friday June 03 2016, @06:32PM
See, you say he doesn't need a different name to differentiate them, but then you use Grub as an example where even you yourself use different names for different version -- "Grub" vs "Grub2". This is also what most distros do. Because there's a significant difference, and people want to know which one is being used when the setup program often just gives the package name, not the version number. That, and it's harder to support both versions if the package manager considers them to be the same package.
"Epoch-ng" vs "Epoch2" doesn't seem like a very substantial difference...
Of course, if he's not going to keep supporting the old version, then it doesn't matter as much. You don't *want* to make it easy for people to keep obsolete software sticking around. Still might make sense to give it a new name if it's a complete rewrite from the ground up though, as it wouldn't really be the same program at that point.
(Score: 2) by Marand on Friday June 03 2016, @09:05PM
The difference is that grub is still grub, not grub2; the grub devs made a clean compatibility break moving to 2.0, but they didn't rename the project at all. Just gave it a version bump to indicate breaking changes. Distros generally kept the grub package as just 'grub' and moved grub1 to 'grub-legacy' I believe, or maybe made grub a metapackage that requires either, but the software itself is still just grub.
My usage of 'grub2' was to indicate which version in a context where the version matters. Same as how one calls different Windows versions by name when the difference matters (Windows 7, 8, 8.1, 10) but just "Windows" at other times ("Do you use Windows?"). I also didn't all-caps GRUB, which is proper, because I treat comments as informal writing where such shortcuts are acceptable as long as they don't reduce clarity.
Plus I sometimes post these from a tablet, with either a touch keyboard or a tiny bluetooth one, and choose to make sacrifices to simplify the typing.
(Score: 3, Funny) by Anonymous Coward on Wednesday June 01 2016, @10:48PM
It should obviously be called Twopoch.
(Score: 2, Insightful) by Anonymous Coward on Wednesday June 01 2016, @09:46PM
To begin, systemd is not a init system. To continue, part of the energy behind it seems to be about push other projects out. Next is network effects, projects asking for things that, magically, only systemd is ready to offer. Oh, yeah, also as "new, it must be better" cargo cult, but your new will be an "anti-systemd so it can never be good" cargo cult. And don't forget to move the goal posts as the discussion requires.
Figure those, and you are golden. Maybe. Because you want a tech solution, the issue is a power game.
I will post my ideas about init systems in other post.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @05:52AM
Actually, what we historically meant as init is one part of systemd. That is, systemd fulfill the roles of an init. It provides other ones as well, but it definitely provides functionalities of an init system. That is why I believe it is valid to say that systemd is an init system. Not just an init system, as it provides other functionalities, but it is used as an init system as well.
(Score: 2) by maxwell demon on Thursday June 02 2016, @06:03AM
According to this reasoning, Debian is an init system. Sure, it provides much more than just an init system, but one part of what it offers is an init system.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2, Informative) by Anonymous Coward on Thursday June 02 2016, @10:25AM
Systemd was sold as an init system, was chosen as an init system. When the opponents of systemd pointed out that it wasn't just an init system they were shouted down. Now systemd is in the incumbent position they say it's not an init system but if anyone where to want to write an init system they are anti-systemd. It's quite impressive how many contradictory positions so people can hold in there heads at one time, but I do worry for the quality of their code.
(Score: 0) by Anonymous Coward on Wednesday June 01 2016, @09:50PM
All my quick searching could find was that systemd uses the kernel apis. It would be great if epoch-ng could be a drop in replacement :)
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @12:40AM
Make a drop in replacement for systemd that looks and feels entirely like openrc.
(Score: 0) by Anonymous Coward on Wednesday June 01 2016, @09:55PM
Let's face it. The real problem is that it's too difficult to fork a distro.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @10:32AM
Yup forking never happens, it's just too difficult. Moving a large distro to a 'continuous integration' platform yields no benefits and talking to upstream and contributing code directly never helped anyone.
Chear up, it took a couple of years but things are getting better, the choices are becoming more diverse again.
(Score: 5, Insightful) by VLM on Wednesday June 01 2016, @09:57PM
A short list of priorities:
Simplicity when troubleshooting above all. My hourly alone is not cheap at 2am. Even worse, the hourly of 100 employees waiting during the day while I try to figure out something "smart", that isn't, is incredibly expensive. No surprises. Nothing sneaky or "creative". Help me start and stop processes that eat electrons and poop out money (a bit of a simplification, but yeah that's pretty much it). Confusing and creative is for some dude bragging about his pc master race gaming station, and there's not a thing wrong with that other than using it at work. Never, ever, make the admin wonder what happens when, in what order, maybe due to some dynamic thing or phase of the moon. Downtime is just too expensive for that kind of stuff.
No new languages. If you can't handle bash scripts you don't work here. Haskell is cool. Clojure is cool. Those two are not the lingua franca of sysadmins. Write that sucker in bash. Not DASH to make it 20 ms faster, who cares, none of us use or program DASH. Look we use BASH OK, I'm not even sure everyone here speaks English, in fact I'm pretty sure that's not the case, but we all are fluent in bash. Yeah yeah you'll save 2 ms each boot if you write it in COBOL and JCL, I don't care see above. We speak bash here. not node.js, not go, not python.
It lives in an ecosystem now a days. Legacy puppet, now ansible, used to use munin and nagios, now I use zabbix. Like 15 years ago I used vanilla syslog and more recently rsyslog. Play nice with the neighbours. By lives in the ecosystem I don't mean I want a metastasizing cancer that adsorbs ntp and my firewall and my sound system. Do nothing but start and stop processes while cooperating with the system, not trying to take it over.
I don't care how slow or fast it reboots because it'll be faster than everything else. Just don't take 10 minutes or something. Seriously, it just doesn't matter. I need speedy simple troubleshooting (see above) yet my load balancer doesn't care if you pick up the load in 50 seconds or 30 seconds, that stuff just doesn't matter compared to troubleshooting and admin time. I have infinite cloudy CPU and NAS power, so I don't care if a powerpc mac mini from 2004 takes 145 seconds, for me its darn near a flash of the screen and I'm up.
Everything I run at work and lots at home is a virtual image. You don't really have to do anything different to be a cloud os other than at install time don't freak and assume your first boot is going to be on openstack or maybe vmware or the ... mess that I have at home. Just be cool that 95% of the init systems I babysit live on virtual images. To some extent openstack is the BIOS of 2016 we were promised and never got, and I like it that way, other than the joined at the hip to redhat stuff. Anyway, yeah, its gonna boot virtual images not bare hardware, mostly.
(Score: -1, Flamebait) by Anonymous Coward on Wednesday June 01 2016, @10:04PM
Speaking of languages, the proposed init system should include a mandatory "feature" which rm -rf's all drives in the system upon detection of anglophonetic Hebrew, Arabic, or Turkish words typed into the keyboard.
Filthy undesirables should not be granted the privilege of using a new improved init system or the system on which it runs.
(Score: -1, Troll) by Anonymous Coward on Wednesday June 01 2016, @11:18PM
Er, so Unicode representations of Hebrew, Arabic, or Turkish works wouldn't be a problem? On the other hand, I could get behind an init system that does rm -rf upon detecting a Bible!
(Score: 4, Insightful) by black6host on Wednesday June 01 2016, @10:39PM
Absolutely. I ran a programming team that was solid. All code met standards and the easiest way to do things is what we did. I did have one programmer, a prima donna type, who loved to put in clever but obscure code. Code which could be done much simpler. I just insisted that all code written be maintainable by all. That clever code never made it in. Saved a lot of headaches over the years. Why would I want the hassle of building a team of high dollar experts for a project that wasn't that difficult? And, to boot, this project came in on time, relatively few issues and under budget. KISS
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @03:25AM
A coworker at the same rank as me was like this.
At the end, just before I left the team, he took code from an application developer and created a whole subsystem syncing code between environments. Three years later he is still dealing with the mess and can't fix the problems.
I did warn him.
There is a time and a place for rockstar developers, unfunded projects and adhoc fixes. Building a key CMS control system between environments for which will manage code through a lifecycle to production is not one of them.
When I hear that yet again the system failed to sync production code at 3am I give silent thanks to the manager who authorised my transfer out.
My old manager comes around every six months or so asking if I would like to "help" them to "fix the system". Which I politely decline.
(Score: 2) by dyingtolive on Wednesday June 01 2016, @10:57PM
I was just going to come here to say "Not systemd", but I like this one. +1 to you.
Don't blame me, I voted for moose wang!
(Score: -1, Flamebait) by Anonymous Coward on Thursday June 02 2016, @07:46AM
My hourly alone is not cheap at 2am.
Stopped right there. As if you can even measure the hourly rate of a kernel dev. Damn these IT tards, they think they're gods when they're just gonads that know how to run software.
Get fucked or else learn how to write the system you desire because you suck as fuck at actually describing it -- which would seem to be a prerequisite for anyone to pay you for the skills you claim to have (but obviously don't).
(Score: 2) by cafebabe on Thursday June 02 2016, @11:05PM
You may be interested in the following:-
1702845791×2
(Score: 1) by stargazer on Thursday June 02 2016, @11:39PM
Since the System-D debacle has caused some of our servers to die after upgrade, we are moving slowly to FreeBSD. There goes 20+ years of knowledge. I'm hoping we can come back to Linux at some point, but for now, I can't upgrade our servers without System-D instability, so I'll put in my two cents. Maybe between your project and Devuan, I'll have the ability to actually use what I've learned.
I'd suggest marketing it as a "Server Grade Init System" since most of the people opposed to System-D's limits are like me, sysadmins. On my laptop, I don't care that much if it dies; I'll just go get the other one until I have time to reformat/reinstall. For my servers, it means lost revenues and some very pissed off clients.
The things I would like.
No parallel processing. It only makes for difficult to diagnose problems.
Dependency processing, maybe. I don't care that much as long as I have an error log and can change the order manually, but it is handy. However, dependency processing can cause problems sometimes, so maybe not.
Text based log files. No alternatives. If I am running out of space, I'll allocate more to my log directory. But, being able to grep a log file and find out what the hell is going on is essential. Inefficient, slow, lots of I/O, but finding the entries you need is up to your ability to use grep. Or write a script that finds what you want.
Emit all boot messages to a text log file for debugging. Text file should be opened and written to with no buffering as soon as the log device becomes available (cached beforehand, I guess). A few times, I've had to mount my log directory after a failed boot to try and figure out what exactly I totally screwed up.
Boot time is not an issue. It takes my DL-380 5-6 minutes just to boot BIOS. I don't care if it takes 30s or 50s to boot into the OS, I just want the freaking thing to boot.
Run levels are confusing, but if you change them, I'd suggest just naming them "GUI", "Console", "Shutdown" and "Single User". The current SysV is not horrible except I have to always remember what the hell Level x is used for. But, that is just my poor memory, not a reason to throw them away.
Easily edit startup configuration scripts. The current ones in SysV are not bad. Me, personally, I hate BASH, mainly because I'm not very good at it. But, it is reliable, damned near bug free, and gets the job done, so it is an excellent choice. Under SysV, I assume I could put a Perl script in /etc/init.d if I wanted (never tried it), but I want my sytem to boot every time, so everything is in BASH.
Above all, KISS. Do one thing, do it right, and don't get into scope creep (the big problem with System-D, from what I've seen). Boot the system and let the init scripts worry about how to start processes. Your job is to make sure the init scripts can be run at a certain run level (or whatever you want to call it), then get out of the way.
Most of these have been stated around here someplace, but like I said, I'm just adding my two cents.
(Score: 0) by Anonymous Coward on Wednesday June 01 2016, @10:07PM
among them being a total lack of parallelism, difficulty for package maintainers to easily set up services, and a codebase even I myself am ashamed to admit I wrote.
You already have you answer. Also, don't name it Epoch-ng. Name it Epoch v2. You're allowed to have major redesigns and breaking chances between primary number changes. Something called "next generation" looks dumb once it becomes a little behind the times.
Why are you writing an init system? Do you use one daily and it gets in your way? If you don't understand what people need (not want) out of their init systems and how the current ones are used then you shouldn't be trying to create one unless its purely for personal education and experience.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @10:44AM
Just because he asks doesn't mean he doesn't know. Questions open discussion between people of diverse backgrounds with common goals. Many here have had quite enough of the 'never ask, never discuss (outside the team)' types who assume we all use software they way they intend us to and if we don't then we should change or go away.
(Score: 4, Interesting) by spaceman375 on Wednesday June 01 2016, @10:24PM
No feature creep. Just an init system. You might consider a two part system, one for kernel space and one for user space.
Readable logging via stdout & stderr, optionally to syslog/rsyslog/another remote epoch, and/or console, as I see fit.
No complicated directory structure with links & pointers.
Simple commandline use, with a -h for help flag, and as few external scripts as possible. Maybe a separate syntax checker for the easily readable/editable config file.
Verbosity and destination of logging on a per service basis.
Maybe nice enough to run another init system under it?
How about smart enough to re-nice and ulimit processes based on system load, IFF I configure given services with that kind of priority rating.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @01:15AM
I like this idea: "Maybe a separate syntax checker for the easily readable/editable config file." I hate the way you have to reboot or load a service to see if it spits out an error then. That can be a huge security risk and a pain to pick out that error message among the rest of the messages in the console/dmesg.
(Score: 0) by Anonymous Coward on Wednesday June 01 2016, @10:28PM
We might never have had to deal with systemd if Apple had released launchd under the Apache license from the start. From Wikipedia,
The Ubuntu Linux distribution considered using launchd in 2006. launchd was rejected as an option because it was released under the Apple Public Source License – which at the time was described as an "inescapable licence problem".[7] Ubuntu instead developed and switched to Upstart, its own service management tool.
In August 2006, Apple relicensed launchd under the Apache License, Version 2.0 in an effort to make adoption by other open source developers easier.[8] Most Linux distributions use systemd or Upstart, or continue with init, and the BSDs also continue with init.
(Score: 2) by butthurt on Thursday June 02 2016, @12:45AM
The previous licencing of launchd doesn't seem to fully explain the creation of systemd.
Red Hat didn't adopt Ubuntu's upstart either. In October 2010, systemd was in the alpha version of Fedora [fedoraproject.org] Linux. That was released in May 2011 as Fedora Linux 15 [arstechnica.com], at which time an Ars Technica story described systemd as "new" and went on to say
Going mainly by what you posted, it looks like Apple was offering a mature init system that, from 2006, had an acceptable licence, yet Red Hat declined to adopt it. Instead, they waited several years, until systemd was written by their employee, to change init systems.
(Score: 3, Informative) by r1348 on Thursday June 02 2016, @01:39AM
You're mistaken, Red Hat used upstart in RHEL 6 and Fedora 9 to 14.
(Score: 1) by butthurt on Thursday June 02 2016, @02:14AM
I see you're right. Thanks.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @05:20PM
Likely very few is even aware, because:
A. Upstart limited itself to doing init.
B. Upstart could transparently use sysv scripts.
Those two meant you could basically drop Upstart on top of an existing sysv distro, and keep on trucking.
(Score: 5, Interesting) by RamiK on Wednesday June 01 2016, @10:33PM
http://blog.darknedgy.net/technology/2015/10/11/0/ [darknedgy.net]
Even if I personally don't agree with everything he says, he obviously spent more then enough time thinking this through.
compiling...
(Score: 1) by nicdoye on Wednesday June 01 2016, @10:33PM
Possibly the only thing I like about systemd is that, for the most part, as an admin, I look at config files not a plethora of bash scripts that do almost the same thing (DRY). There's a place for both custom bash scripts (some stuff is too different - like networking) and ones which are fundamentally just config + generic functions.
Some people (I'm not one of them) may want dependency management like Sun's SMF http://www.oracle.com/technetwork/articles/servers-storage-admin/intro-smf-basics-s11-1729181.html [oracle.com].
Performance will be an issue for people who shut their laptops down, and possibly for VM farms. (I don't do either of these things).
Other than that, you know what we want: we want it UNIXy :-)
I code because I can
(Score: 5, Interesting) by VLM on Thursday June 02 2016, @12:06PM
I think there's a lot more weird stuff. As linux moved away from unix I/we moved to freebsd at home and work but I have access to a legacy linux box.
I am accessing that legacy linux box now, which doesn't really do much of anything. It runs Debian. Theres 53 init scripts in /etc/init.d
Most are custom and verbose and mostly not DRY.
Lets look at /etc/init.d/openvpn for fun. 298 lines to start and stop a vpn superficially sounds a tad excessive. But look at all the stuff it does.
First burn a screen full of comments. Good. Its well commented. Comments are good.
One of the very few things the LSB concept got right was making a shared set of init functions, so load that up. You claim DRY would be a new idea, but its decades old.
Test if the daemon binary exists and config dir exists and if not silently fail. Um thanks. Might be nice to log that failure. I'd like to know if I somehow made the config dir unreadable or WTF.
The /etc/defaults system is inherently a bit awkward and could be DRY'd or improved "somehow" I agree its cluttery.
Then some helper functions are defined to start and stop the daemon while messing with the daemons command line arguments, or not, depending on config. Its a bit confusing because its versatile. There's also an embedded bug fix, essentially, relating to misrouting ICMP traffic between peers. It has a rather elaborate system of marking running status messages and storing the PID of the daemon.
Then its time to actually start. You can autostart all vpns or specific VPNs. See openvpn can run multiple separate VPN systems and this is seen as a feature. Stopping is about equally exciting for the same reason. Likewise reload is exciting because you only reload ones that are in start status. Speaking of status, ditto status. And I didn't know until now there is a soft-restart option, interesting.
This was a complicated init script. But none of them are really simple anyway. bind9 does some magic checks on the network status and config, it has to be customized to run in an chroot/jail. Surprisingly to me, playing with bind messes with resolvconf, why couple them, i bet that confuses admins occasionally when they're playing with bind but their resolv.conf magically gets messed with in an unexpected manner.
hwclock.sh is complicated. Apparently if the admin trys the usual trick of delete a file to have the script not work, hwclock instead recreates the adjtime file and prepopulates with a boilerplate default ! Holy cow, kinda funny. Inconsistent. Its got obscure code to deal with UTC, or not.
The biggest problem with an init system is the simple answer is its just another supervisord running java app #2515 that can be DRY 2513 times before app 2515 is brought up, but the reality is even a pretty bare system has like 50 scripts that do crazy stuff that can't be DRY... plus folks want to run java app 2515 in a DRY manner. So good luck with that.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @05:25PM
It feels like most admins etc today are not even aware that shell script has the ability to inherit other scripts (source filename).
Myself only learned that this was a thing once i poked at a distro that is 99% shell script (Gobolinux).
Thus there is no real need for massive sysv style boilerplates pr script.
you write it once, and then source it into each script as needed.
(Score: 1, Insightful) by Anonymous Coward on Wednesday June 01 2016, @10:51PM
The scope of init is limited. Do one job and do it well.
I'd guess most people do not boot 50 times per day. I don't so for me boot time is irrelevant unless you intentionally make it slow. If given a choice between simplicity and performance, the init should opt for simplicity.
No fucking binary log files.
You hopefully did this already, but take a look into other inits like OpenRC.
As for gaining popularity, you're between a rock and a hard place. PoetteringOS has Red Hat behind it since it makes paying for support more attractive. You'd need some gimmick to stand a chance, like it's more secure, faster, gives blowjobs, etc.
(Score: 5, Insightful) by Justin Case on Wednesday June 01 2016, @11:18PM
Keep it very simple.
I'd like a boot time tool that does nothing more than read one plain-text file that tells it what to launch next.
Hypothetically, it might not even need to boot a kernel. Imagine a computer with only one binary file on it, say, a python interpreter, just for illustration. (Yeah I know Python doesn't have built-in hardware drivers. It's an example.) Everything else is plain text python source code and configuration files.
Every time things get too fancy -- I'm looking at you GRUB -- I have to go in and disable a bunch of stuff that was put in to make things "more automatic". Problem is, the writers didn't consider my use case, so their automation literally shits all over my drive. Not nice.
Imagine that you have to debug a boot problem at 3AM after an evening with five shots of tequila. Also, the Vice President of Sales is calling every 10 minutes to inform you about all the revenue the company is losing every second. Do you want a thousand bells and whistles, and something that automatically reconfigures itself at random without explaining what changed? No. You want something that is incredibly easy to understand.
Also, please don't clear my goddamn screen. There might have been a diagnostic message there I needed to copy down!
And log the entire boot sequence to a plain text file while we're at it. So I can go back later and check what was that "Warning, feeble flimjard found at #$FF820A66" that flashed by. Or diff today's boot vs. yesterday's to find out what derailed.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @11:20AM
> I'm old enough to remember when it was my computer, and I told it what to do.
No you're not.
(Score: 2, Informative) by Anonymous Coward on Thursday June 02 2016, @12:03AM
Make a Devuan package, and you would have a good testing group.
(Score: 5, Insightful) by Arik on Wednesday June 01 2016, @11:01PM
Absurdly enough we now have a dozen different projects aiming to replace init, but not one of them has given any sort of sensible answer to that question, to the best of my knowledge.
The trap you appear set to fall in is deciding that to replace systemD you need to do everything systemD does. But one of the main reasons people don't want systemD is because it does all kinds of stuff that no init system should ever do.
Forget about replacing systemD. Think of it as replacing init. What's wrong with init? If there's an answer besides 'nothing' then fine, but if not, then just use init.
If it aint broke dont fix it.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @12:07AM
I would make a few lists for reference.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @06:51AM
Easy: It's too big and does too much.
No, I'm not talking about systemd / upstart.
(Score: 1, Informative) by Anonymous Coward on Thursday June 02 2016, @10:53PM
EXACTLY this. Init does very little, and it does it very simplistically. I boggle at people who complain that init scripts are "too complex" (and granted, some vendors can indeed write some crazy scripts), but that's the beauty of the system: it runs scripts. If you want less complex scripts, you can write them. A non-trival part of my servers' boot configuration is done with laughable simplicity in the form of command lines thrown directly into /etc/rc.d/rc.local. You can throw away ALL the vendor's init scripts and just write your own in a blindingly simple "autoexec.bat"-style script.
SystemD seems like it might have a place on bleeding-edge netbooks, and other systems where single-user convenience and instability are expectations. Such criteria have NO place on servers.
(Score: 2) by Arik on Friday June 03 2016, @07:32PM
If laughter is the best medicine, who are the best doctors?
(Score: 1, Interesting) by Anonymous Coward on Wednesday June 01 2016, @11:44PM
Be careful about going parallel: You can run out of memory, causing pageouts (even if no swap enabled, since .text can be paged out) and similar horribleness.
Find a way to transfer state so that init can be updated without a reboot. SysV init would create a socket pair, fork, have the parent exec a new init, then transfer state across the socket from child to parent.
Package management and performance will conflict. A decent approach is to check the timestamp on a directory full of text files against the timestamp on a binary blob that is sort of a compiled version. If the blob is old, you read in the text files. Once the filesystem is read-write, you can update the blob so that the next boot will run faster. On that boot, you mmap the blob to avoid dirtying any memory.
Think carefully about how you want to get data for various services. Ideally you would have an optimum format (not nasty bash) but getting everybody to convert is probably hopeless.
Numbered SysV levels were crude. There should be named states that act as services (can start or stop them) but don't actually run daemons; they exist only as dependencies.
(Score: 2) by mth on Thursday June 02 2016, @02:51AM
Be careful about going parallel: You can run out of memory, causing pageouts (even if no swap enabled, since .text can be paged out) and similar horribleness.
Are there a lot of services that require more memory during startup than while running idle? Because that's the only scenario I can think of in which parallel startup would be more likely to run out of memory than sequential startup.
Think carefully about how you want to get data for various services. Ideally you would have an optimum format (not nasty bash) but getting everybody to convert is probably hopeless.
For adoption, it would be good if you can support init.d scripts (with LSB metadata) and/or systemd service definitions, either as-is or using a converter. Even if it's not fool proof, something to extract a draft configuration that the admin can then fix is better than having to start from scratch for each service.
I think the main problem with bash in traditional Linux init is that the init scripts were required to do way too much. For example, managing PID files ("status" command, missing PID file on "stop", dealing with stale PID files on "start") is left to the service script, while that could be handled by the init system instead. Another example is that the implementation of the "restart" and "force-reload" commands: every init script has to provide those, even though there is no need for service-specific code in them.
For simple daemons, handling of PID files could work like this:
There should be ways to execute command lines / scripts for daemons that have non-standard ways of reloading and shutting down, but the vast majority can be handled by a few config items.
(Score: 3, Insightful) by Arik on Thursday June 02 2016, @03:10AM
"Package management and performance will conflict. A decent approach is to check the timestamp on a directory full of text files against the timestamp on a binary blob that is sort of a compiled version. If the blob is old, you read in the text files. Once the filesystem is read-write, you can update the blob so that the next boot will run faster. On that boot, you mmap the blob to avoid dirtying any memory."
Nah that's insanity. Read the text files every time. You're making the system much more complex to save a fraction of a second of boot time. Bad trade.
"Think carefully about how you want to get data for various services. Ideally you would have an optimum format (not nasty bash) but getting everybody to convert is probably hopeless."
Bash is not a format so I am not sure what you mean here.
"Numbered SysV levels were crude. "
Crude in comparison to what?
"There should be named states that act as services (can start or stop them) but don't actually run daemons; they exist only as dependencies."
Why?
If laughter is the best medicine, who are the best doctors?
(Score: 2) by mth on Thursday June 02 2016, @03:39AM
I'm not the OP, but I think I can answer these:
"Numbered SysV levels were crude. "
Crude in comparison to what?
Compared to a dependency-based system. The sysv numbering is actually a manually-created flattened form of a dependency tree. But since the dependencies aren't explicit, it's hard to work with (which number do you pick for a new service?). It also means that parallel execution is impossible.
"There should be named states that act as services (can start or stop them) but don't actually run daemons; they exist only as dependencies."
Why?
As a replacement for runlevels: do you want to boot the system into maintenance mode or a full startup of all services?
I don't think it makes sense to start or stop a state though: instead of having "stop graphical desktops" implicitly switch to the "networked services running" state, it would be better to switch to an explicitly requested new state.
(Score: 3, Insightful) by Arik on Thursday June 02 2016, @05:30AM
Parallel execution is not desirable in an init system. It creates dependency problems it introduces indeterminacy, and there is no benefit to justify it.
"As a replacement for runlevels: do you want to boot the system into maintenance mode or a full startup of all services?"
So what's wrong with runlevels? Runlevel 1 is single user which I assume is what you mean by maintenance mode, runlevel 3 is full startup, where's the problem?
If laughter is the best medicine, who are the best doctors?
(Score: 3, Insightful) by mth on Thursday June 02 2016, @06:50AM
"It also means that parallel execution is impossible."
Parallel execution is not desirable in an init system. It creates dependency problems it introduces indeterminacy, and there is no benefit to justify it.
Parallel execution doesn't create the dependency problem: dependencies exist between services regardless of whether you start them sequentially or in parallel. The difference is that with sequential startup, if it works when you test it, there is a reasonable chance it will continue to work, even if you declared the dependencies wrong. With parallel startup, if you declared the dependencies wrong, it may work sometimes and fail at other times. So the end result is a lot more predictable in sequential startup, but the underlying problem is the same.
I'd argue that even if you don't want to execute in parallel, having correct dependency declarations in the services and then having the init system flatten that automatically would be preferable over manually creating a flattened version (the /etc/init.d/rc(n).d/S(nn)name numbering).
Booting faster may or may not be a benefit. If you have a server that is only rebooted during maintenance windows a few times a year, there is little benefit. If you have an embedded system where you're waiting for it to become available, a faster boot leads to a better user experience.
"As a replacement for runlevels: do you want to boot the system into maintenance mode or a full startup of all services?"
So what's wrong with runlevels? Runlevel 1 is single user which I assume is what you mean by maintenance mode, runlevel 3 is full startup, where's the problem?
A named label would be more clear than a number. Other than that, there isn't anything wrong with runlevels, which is why a replacement init system should have similar functionality.
(Score: 2, Disagree) by Arik on Thursday June 02 2016, @03:30PM
I'm sorry I really think it does. If your startup script is processed sequentially and deterministically dependencies are literally not a problem. There's never any chance of service x which relies on service y incorrectly failing to initialize because service y had not yet come available.
"So the end result is a lot more predictable in sequential startup"
Correct. And this is a very good thing. Init has one job, it should not fsck it up.
"but the underlying problem is the same"
What problem, exactly? Because see above...
"Booting faster may or may not be a benefit. If you have a server that is only rebooted during maintenance windows a few times a year, there is little benefit. If you have an embedded system where you're waiting for it to become available, a faster boot leads to a better user experience."
But why would your embedded system need to power down any more often than my netbook does?
I think you've got it backwards there, actually. It's people that run big server farms that care about fast boot times, and that's why PoetteringOS puts so much emphasis on it. Because there are businesses spinning large numbers of virtual machines up and down constantly. Still, I'd prefer they make their own tools on the host side to improve performance rather than shoving their system so deeply up the communities bung-end that things tear and rip.
"A named label would be more clear than a number. Other than that, there isn't anything wrong with runlevels, which is why a replacement init system should have similar functionality."
Something like rc.M or rc.CDROM?
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @05:31PM
Yet sysv will come up (at least to a terminal login) under worse conditions than will provoke systemd into going "here is a rescue cli, your on your own".
(Score: 3, Interesting) by Nerdfest on Thursday June 02 2016, @01:06AM
I really like the idea of text log files. It makes things much easier. Text based configuration as well. perhaps using dot notation (a la graphvis) for dependency management.
(Score: 4, Insightful) by mth on Thursday June 02 2016, @02:10AM
I think it would be best to use the syslog protocol and let the user decide what kind of storage backend they want to use for their logs.
You'd also need a solution for before the syslog daemon is running. What I did in an embedded system is log to /dev/kmsg, so your log lines end up in the kernel log. In practice this means they'll be visible on a console or serial port, which is useful if for example the mounting of file systems fails (which would break log files).
(Score: 2) by Nerdfest on Thursday June 02 2016, @02:34AM
Nice. I guess I really meant the *option* of text logs.
(Score: 1, Redundant) by Arik on Thursday June 02 2016, @03:14AM
I doubt the other gentleman is talking about sending xml to the kernel log.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @01:30AM
One thing I used to do a lot was put different daemons in inittab. Then that was a security issue and getting around that is kludgey, plus by that point the boot scripts started to become rather huge. Another I love is ondemand. A simple "telinit c" executes all sorts of goodies for me automatically in a very readable way.
(Score: 5, Informative) by Pav on Thursday June 02 2016, @01:41AM
If you want to make an init with a REAL chance of becoming a replacement, well, this is much bigger than beautiful and simple code, and a few peoples ideas about what would make a good init system. It's about collaboration and politics, philosophy and compromise. You're aiming at near universal acceptance WITHOUT a huge company backing you to jam it down everyones throat.
You're going about things the Right Way(tm) in asking for opinions, but I'd suggest asking some very important open source people and projects for info and/or help. You have experience writing an init system already, and this gives you the nerd cred required. For political and technical reasons this project should be bigger than yourself.
The #1 person I'd suggest talking to would be Roger Leigh... he's the old Debian sysvinit maintainer, and I believe he also became the upstream maintainer of sysvinit. He spent years making room for alternate init systems in Debian (until the same favour wasn't returned to him from the systemd people once it became default, and Roger quit Debian over this and the politics surrounding it). I'd imagine he could be good for information on what's required, how to play nicely with other init systems, and other people/projects to ask eg. those who require a more feature-filled init, and beyond init the other systemd-linked services which will also require a solution (even if it's just pointing to another solution).
#2 might be the Devuan project - not sure you'll hear many feature suggestions, but they're untangling Debian from systemd so have useful knowledge on which other projects rely on systemd extended features, and for what. There'll be lots of potential collaborators too I'd imagine (after all their project is to make room for alternatives with a more unix-ish approach), and an OS that could be a test base for you.
I "met" Roger on IRC/FreeNode (though I can't remember his nic)... and #devuan is also on IRC/Freenode.
To get political buy-in I'd suggest trying to work with Roger and some other respected people to collaboratively come up with a "requirements" document - achieving this would be very difficult... and then a spec, and only then an implementation (athough of course before 1.0 you could work on all three simultaneously). Working with such important people, even on preliminary documentation, will certainly create a buzz and hopefully attract other collaborators (along with detractors ;) . If you aren't racing to an implementation I'd imagine it would create confidence you're trying to do things The Right Way(tm). If you do things this way there's a chance the most important product of your project could be the process of helping the FOSS community become self aware enough to produce requirements and a spec... to me this is what seems the TRULY hard part. Noone has done it yet.
(Score: 2) by hendrikboom on Thursday June 02 2016, @12:36PM
I posted a link to this discussion on the Devuan mailing list. You might want to check there in case some non-soylentils reply there rather than here.
(Score: 3, Interesting) by Marand on Thursday June 02 2016, @02:45AM
I'm half joking here, but I think it would be interesting to see an emacs-esque extensible init system using something like Scheme or Lua. Then, make as little of the init as possible in a lower-level language, instead choosing to build more advanced features out of its own language, in the same way lisps do. Once you do that, you could create a bare-bones init system in your new Epoch Lisp (or Lua, or whatever else) variant, and bolt new features on over time.
At its core it would be simple, doing only what it absolutely needs, but if you make it able to fork itself off, you could optionally create more advanced features, like having an Epoch equivalent of logind that spawns off of the init, or spawn another process that does what systemd's cgroups crap does, things like that. Or, as another example, it might initially only support spawning processes at boot by reading .epoch files out of /etc/enit, but by being extensible, one could add support for systemd unit files or sysv-style inittab, or any other format one wants to add.
It's probably not something you'd want to do, but it'd be an interesting experiment. The base init could be the most bare-bones, feature-free init possible, and everything past that would be optional. Strip it down to nothing for embedded systems, or go full-fat for desktops, or anything in between.
(Score: 2) by Scruffy Beard 2 on Thursday June 02 2016, @04:42AM
I was going to suggest that:
set init to /usr/bin/emacs
Then all you need to complete the system is a decent text editor like vim.
I have never tried it, since I suspect it will mostly be a joke OS.
(Score: 2) by Marand on Thursday June 02 2016, @05:43AM
It's been done, as has booting to vim, but they're both really just "hey, I wonder if..." projects rather than anything seriously usable. Realistically, though, emacs is better suited to replacing your shell or X session than replacing init.
It would make much more sense to create an init with the same philosophy, preferably built on a minimal language. Hence the mention of Scheme and Lua, which are both "batteries not included" languages where you have to include your own extras if you want them. You'd have to add functions for some low-level things like managing processes, but you could end up with a tiny, bug-free base init that can be extended to handle fancier things, even things that haven't been thought of yet.
Rather than having to throw out your init system in the future, you could extend it, emacs-like, to add future concepts as they become needed.
(Score: 2) by tangomargarine on Thursday June 02 2016, @02:22PM
Then all you need to complete the system is a decent text editor like vim.
Done. [emacswiki.org]
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by mth on Thursday June 02 2016, @03:10AM
Being able to run multiple instances of the same daemon is something that sysvinit doesn't really support: you can fake it by copy-pasting and then editing the init.d script, but that's a lot of duplication and a pain to maintain. I don't know if/how systemd handles this.
What it would require is splitting the definitions used to hook the daemon into the init system (which are the same for every instance) from the configuration used to start up a specific instance.
(Score: 2) by Arik on Thursday June 02 2016, @03:19AM
Huh?
"you can fake it by copy-pasting and then editing the init.d script, but that's a lot of duplication and a pain to maintain."
Oh, so it supports it fine, you just think it's work to configure.
Wouldn't that be something better supported by the daemon package itself (via a configure script for instance) rather than by the init system?
If laughter is the best medicine, who are the best doctors?
(Score: 3, Interesting) by mth on Thursday June 02 2016, @04:13AM
"Being able to run multiple instances of the same daemon is something that sysvinit doesn't really support"
Huh?
"you can fake it by copy-pasting and then editing the init.d script, but that's a lot of duplication and a pain to maintain."
Oh, so it supports it fine, you just think it's work to configure.
That depends on how you define "support": the system is flexible enough that you can get it to work, but sysvinit doesn't help you in any way.
The main problem with this solution is that when the original init script is updated through a package upgrade, you have to manually update the copies for all the other instances. Also the distro doesn't know about the other instances, so it won't restart them as part of the package upgrade.
Wouldn't that be something better supported by the daemon package itself (via a configure script for instance) rather than by the init system?
Having a single interface for start/stop/status/reload etc. would be better than having to learn daemon-specific syntax for all daemons that you might want to run multiple instances of.
(Score: 2) by Arik on Thursday June 02 2016, @05:24AM
Why would it? It's an init system, not a configuration tool.
"The main problem with this solution is that when the original init script is updated through a package upgrade, you have to manually update the copies for all the other instances."
Again, sounds like a configuration problem, which should be addressed by the upgrade tool, not the init system.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by mth on Thursday June 02 2016, @07:15AM
The problem is that the reference to the daemon's configuration is hardcoded in the init script that hooks the daemon into the init system. If a configuration for the daemon could be specified without modifying the init script, configuration and the init system would be cleanly separated.
(Score: 2) by maxwell demon on Thursday June 02 2016, @06:48AM
Couldn't you just make symlinks instead of copies? Then all "copies" would be automatically updated with the original file.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by mth on Thursday June 02 2016, @07:09AM
If the script is writing a PID file, you have to make sure each copy uses a unique name prefix. Also each instance will need a different configuration file to be passed to the daemon.
I guess you could modify the original script to use "basename $0" to find the right PID file and config file and then symlink that script for each instance. I'm not aware of any distro actually doing that in their init scripts though, so in practice it would mean you'd have a customized init script and have to resolve potential breakage (merge conflicts or failed merges) of the init script on package upgrades. But that would have to be done once per package, not once per instance, so it is an improvement.
(Score: 1, Informative) by Anonymous Coward on Thursday June 02 2016, @10:06AM
systemd handles this
service@configname
(Score: 3, Informative) by Anonymous Coward on Thursday June 02 2016, @03:14AM
Other than your own pleasure in coding, are there features you want you don't see in the many other init systems around?
Some are listed here.
https://wiki.gentoo.org/wiki/Comparison_of_init_systems [gentoo.org]
There are others, including several based on djb's daemon tools, such as s3. Why do you want to create yet another init system?
(Score: 3, Troll) by darkfeline on Thursday June 02 2016, @04:24AM
What DO you guys want? I'm rather curious, because I don't want an init system, I want a computer that Just Werks.
For me, systemd works and initscripts + sysvinit doesn't. Run levels are arbitrary. initscripts can't kill processes properly. Writing a new service script involves copying and pasting the right 90% of boilerplate.
>most commonly requested features were true dependency support and parallelism.
Things systemd has. Maybe that's why distros started adopting it?
Some of us care about "bloat" and "the UNIX way", but the rest of us just want something that works, preferably FOSS. In fact, those of you who aren't wearing UNIX goggles knows that "the UNIX way" is hacking together monstrosities that just happen to work. Anyone who thinks UNIX is elegant is crazy.
Join the SDF Public Access UNIX System today!
(Score: 2) by Arik on Thursday June 02 2016, @05:50AM
So buy a commercial system. It won't Just Werk either, but at least you'll have someone to blame.
In reality computers always require administration. Slack init is great, because it's extremely easy to administer yourself. You just don't want to do it. SystemD will promise you an escape from administration tasks, and in a twisted sense that's what it will deliver. Oh, you'll still need system administration, but you won't be expected to do it yourself anymore. You'll be expected to cough up for a maintenance contract and let them do it for you, it's all too complicated now.
A certain sort of person is happier with that. I'd be happier if they would stay on Windows, personally.
"For me, systemd works and initscripts + sysvinit doesn't."
How *specifically* does sysvinit not work for you?
"Run levels are arbitrary."
Everything on a computer is arbitrary.
"initscripts can't kill processes properly."
Huh? Why would they need to? And what failure specifically are you seeing?
"Writing a new service script involves copying and pasting the right 90% of boilerplate."
And?
If laughter is the best medicine, who are the best doctors?
(Score: 2, Troll) by darkfeline on Thursday June 02 2016, @02:54PM
>Oh, you'll still need system administration, but you won't be expected to do it yourself anymore. You'll be expected to cough up for a maintenance contract and let them do it for you, it's all too complicated now.
I can assure you I haven't paid anyone, or in fact spent more than a few hours total since the move to systemd, administering my Arch installs. Sounds like a case of "can't teach old dogs new tricks". It's "all too complicated now" because one is unable or unwilling to learn a few new things.
>Huh? Why would they need to? And what failure specifically are you seeing?
Specifically, when I run the equivalent of "service foo stop", I expect the service to actually be stopped and not have to worry about running ps/kill afterward every time.
>"Writing a new service script involves copying and pasting the right 90% of boilerplate."
>And?
If I enjoyed doing repetitive mechanical work, I would write my own OS in assembly. It's not like my time is valuable, is it?
Join the SDF Public Access UNIX System today!
(Score: 2) by Arik on Thursday June 02 2016, @03:39PM
Sounds like a configuration problem, but since *foo is not a real service there is nothing more that can be made of it.
With slack or sysv or bsd init, these things are all scripts and if the distro or a package somehow screws you you can go in and fix the problem in a few seconds yourself, even if it's so bad you have to use a minimal boot to get in to do it that's not a problem, you don't see the virtue?
If laughter is the best medicine, who are the best doctors?
(Score: 2) by coolgopher on Thursday June 02 2016, @06:38AM
Lucky for you. For me the two things which reliably stop my systems from booting are: 1) systemD, 2) nouveau driver. I can get rid of the first by using e.g. Devuan, the second one I typically have to spend some time to purge from the system using arcane incantations while booted into a rescue shell after initial install.
(Score: 4, Insightful) by engblom on Thursday June 02 2016, @05:02AM
I want just scripts, nothing compiled. If the whole init system is just scripts, I am able to quickly check up why something goes wrong if I have a problem.
The very tiny amount of performance gained by a compiled init system is not worth. Most of the time is anyway spent on waiting for services and their dependencies to boot up and not by the init system itself.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @07:01AM
sysvinit works well. I don't see a need for any other init system.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @07:28AM
OK, so I got over the moronic nonsense that was "Everything is a File" when I tried to implement the Interstellar Internet (DTN [Disruption tolerant networking] + NDN [Named Data Networking]) [No, seriously, go search those terms or you won't know what the fuck I'm talking about].
So, now I realize that data is self descriptive via hash functions which can produce a handle (fingerprint) that refers to the data block, and file names should just be user readable names while the file systems use hashes for data handles and thus deduplicate information so that even if you rename "my cat eats it" to "funny feline foray" the bits on the disk (or network) don't have to change at all and when you uplink with Mars Control only one copy of that cute cat video will need to be sent because both views reference the same data-hash and thus a single batch of data.
Now, let's apply that to init systems.
First off, fuck right off. I don't need your init system. All I need is a list of deduplicated file names and call backs that need to be activated upon boot, and my Named Data Networking + Disruption Tolerant (Intergalactic) Networking already handles that.
So, get bent, fucko, we've through here fool. The grown ups are building out what we need, and when it comes time we'll release the specs to the idiots currest implementing "the Internet of Things" and blow their minds and loads all over again. Good day to you, and look up "BSD NeXT" first or else you'll make some dumb-ass response that you're not even qualified to make or educated enough to comprehend.
(Score: 2) by hendrikboom on Thursday June 02 2016, @12:44PM
Or look up Inferno OS.
(Score: 3, Interesting) by ptman on Thursday June 02 2016, @08:46AM
Take the good stuff from systemd. Support the .service file syntax so that people don't have to write new configs, as that will be a barrier for adoption. Support init-scripts as well if it isn't too inconvenient. Take a look at SMF and launchd, but note that XML and plists are worse options than systemd ini-like syntax. Support service supervision so that a separate supervisor isn't needed. Use dependencies, not events (upstart shows how that failed).
(Score: 0) by Anonymous Coward on Friday June 03 2016, @02:00PM
If you do all that, why not just use systemd then? How about sending patches to the systemd maintainers instead of starting a new project?
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @10:03AM
I'd say something simple and effecient, and also simple to write scripts for.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @10:12AM
Logging. This one is easy.
Differentiate system services and application services.
System services would be things like syslog. Things needed for the OS itself.
Application services would be sendmail, httpd, tomcat, etc.
Boot your system, start system services. And once the system is up, start application servers.
Have supervision of both.
Allow dependency trees to be created, where needed. If not needed, go parallel.
Don't do units like systemd, where hardware, services, are all the same.
Properly design a replacement for run levels/systemd targets.
Be a init system for the Linux kernel. Support Linux features, like control groups, network name spaces. Probably delegate control to processes dedicated for each purpose.
Pretty sure I could go on.
(Score: 2, Interesting) by froze_n1 on Thursday June 02 2016, @01:56PM
Give me an option to have IO early, really early - as in kernel starts init and init asks me if it should run itself or something else. Then let me set break points or single step my way through everything that is being done so I can see where it bails out and for what reason. Other than that (as mentioned elsewhere) No Binary Logs(tm), text only please; if you want structured (meta)data in the log stick it xml, json, yaml or similar. That is my wish list.
(Score: 1, Informative) by Anonymous Coward on Thursday June 02 2016, @02:57PM
Simplicity, reliability, ease of troubleshooting. Nothing more, nothing less.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @04:46PM
First off, I'm of the camp that sees nothing wrong with init.
That said, since just about everything Linux has gone crazy with "shiny new XYZ update!", I've gotten tired of it. I've switched to FreeBSD and Hackintosh at home.
For work, I must say that my init run servers are much easier to manage than the few systemd ones. Someone popped the latest "greatest" version of Centos onto two of our servers out in the Midwest and I've had more problems with CUPs, FTP, and simple firewall changes on those two than any of the 10 or so other production servers combined.
Parallel startup is actually a bad thing in some use cases.
So in answer to the question: sequential process startup, plain text logs, firewall control separate from the init system, service start/stop/status that works as expected rather than whatever corner case some script kiddy thought would be cool to design everything for.
(Score: 0) by Anonymous Coward on Friday June 03 2016, @04:40PM
hello Subsentent, i have actually used Epoch to init Debian 7, and am only using sinit instead these days because i got hit by the suckless.org bug. the only thing i would change would be to make transparent the commands used by Epoch to mount/unmount file systems during the early init stages. i am using Devuan [non-systemd Debian fork] these days, and i know that they are interested in replacing sysvinit. the alternatives [such as openrc] are far less interesting than Epoch, so maybe you should be put in contact with their team?
(Score: 1) by darkpixel on Friday June 03 2016, @11:31PM
I'm hardly an expert on init systems, but I'm a wanna-be software developer. From a high-level overview there are a few points that I think might make a decent 'next gen' init system that isn't retarded like systemd.
Make a plugin system for distros that ties in with events.
Have the init system fire various 'events' that trigger plugins, like network-start, network-up, shutdown-start, etc...
Distro maintainers can write their own plugins to deal with things like Debian storing network config in /etc/network/interfaces and RH storing it..uh.../etc/sysconfig/net..uh...ok--I'm not a RedHat guy. Regardless, a plugin could be written to read existing text-based config files depending on the distro.
Package maintainers can write their own plugins to handle events like 'network-up' to trigger starting SSH or Nginx.
I honestly don't care about parallel operations, but I do care that I see the login prompt *after* the system is fully up. It annoys the hell out of me that I sometimes reach a login prompt before all the filesystems are mounted (thanks systemd) or even weird things like being able to log in, do a bunch of stuff, have it fail, wonder what the hell is wrong with my box, and then notice it hasn't finished bring up the network yet. (Thanks again systemd--I can log in, get to the desktop, and open a web browser before the network is configured. What the hell?)
I'm not against parallel processes though. It would certainly be more efficient to start ssh, nginx, ntpd, and attempt to mount NFS filesystems at the same time (after the network-up event) rather than waiting for one to complete before starting the next one.
Hell--even the plugins/events can probably run in parallel like mount /usr and /var at the same time after / is mounted, then we're ready to start networking, and the GUI...or whatever.
Meh. Like I said, I'm not an init guy. There are probably all sorts of complexities relating to booting, device management, and X that I am completely unaware of.
(Score: 0) by Anonymous Coward on Tuesday June 07 2016, @04:54PM
The login prompt coming up early is a trick used to make it appear faster. Under the old system, seeing the login prompt meant the system was done booting. However, first Windows and now systemd don't do that. They spit up the prompt when the "essential" services start and Windows cheats even more by having huge chunks of the system hibernate. That they are hoping is you don't really notice that logging in takes forever and all the stuff starting in the background.
FWIW, one trick a coworker uses is to have a service that depends on everything else, and that plays a beep when the systems are really up. On some systems that can be a full five minutes after the prompt comes up and we have one where it is 30 minutes due to the sanity checks it runs every start because systemd doesn't take it down cleanly on shutdown and reboot and not everyone remember to manually take it down first.