Ubuntu is developing the “upstart“, a replacement for the init daemon, the process spawned by the kernel that is responsible for starting, supervising and stopping all other processes on the system. The article compares upstart to Solaris SMF, Apple’s launchd, and initng.
It’s about time. The fact that Linux distributions have clung so long to the inadequate and problematic init system is embarassing. Good on you Ubuntu!
So much about linux is embarassing:
Lilo is embarassing.
X is embarassing – though to a lesser degree now, due to recent work with XGL, Compbiz, AIGL, X.org
The lack of applications is embarassing.
The lack of standardization accross distributions is embarassing.
Sendmail (which is full of security holes, and yet somehow still makes it into many current distrubutions) is embarassing.
Device driver support is embarassing.
… and the list goes on.
Why people get so excited about 30 year old technology, I’ll never understand.
Why people get so excited about 30 year old technology, I’ll never understand.
Yeah, because we all know that all the code in *nix is 30 years old and hasn’t been updated at all.
Moron.
Never mind, just saw the rest of the article and saw the differences.
Edited 2006-08-27 08:43
looks great on paper, best of luck in the implementation. makes mucho sense for modern systems.
didn’t sun already do this for solaris?
yes they did and compared in the article
Edited 2006-08-27 09:02
Maybe it’s a good idea to include in the summary that comparisons with launchd, initng and SMF are in the article. It might save us from knee-jerk responses from people who won’t bother to read before they post. We’ve already had those about launchd and SMF. I bet the next one will be about initng.
Good idea. Added.
Why just don’t create a new runlevel (or take existing runlevel 4 (unused) ) to boot a minimal X server configuration + framebuffer/vesa drivers (or damnsmalllinux like), not proprietary drivers or accelerated open source drivers (radeon, mga, nv) –> Emergency/Safe graphical mode.
Edited 2006-08-27 10:22
It’s great to see these big changes from Ubuntu, the best Desktop Linux system.
About the other problem: http://www.ubuntu.com/FixForUpgradeIssue
“It’s great to see these big changes from Ubuntu”
That would’ve been enough. But no,
“…the best Desktop Linux system.”
You couldn’t have started the day any other way, right ?
It’s nice to know we have you to tell us we should all only have one favourite OS.
And one favourite car.
And one favourite tv program.
And one political party.
And when to say it.
<sarcasm>
Communist Linux
Red Linux
</sarcasm>
No, just my opinion in some years using Linux That’s bad, if everyone has the same favourite things, specially the girlfriend, wife hehe
Wait, who are you to tell him which should be best in his opinion? Granted, his wording was not the best, but still he’s entitled to an opinion. In my eyes, Slackware is the best desktop linux. Sure it’s got issues but THEY ALL DO.
Try not to be so super-sensitive next time.
best for you….. not for me
not enought polish for me
not good managing tool like suse or mandriva
Good to see something new adopted in that front.
I’m not sure if it the same, or if it has been altered a lot but check this out, http://members.optushome.com.au/clausen/ideas/upstart/index.html
If we finally can get parallel booting that would be very nice! I couldn’t make that out of the article.
Nope, it’s not the same program … I did do a search around the usual places before naming it “upstart” and didn’t find this one.
Admittedly, it’s an “obvious” name
Looks like it’s unmaintained, so no reason to rename at this point.
I’ve tried various init systems: sysvinit, minit and initng. I’m currently using initng as it seems to be the least bad of the three.
I’m a bit confused by their analysis of it though:
The difference in model can be summed up as “initng starts with a list of goals and works out how to get there, upstart starts with nothing and finds out where it gets to.”
That sounds list an advantage of initng to me. I say what I want running, and it works out the most efficient way of getting to that state (running only other program that are needed).
Their example of initng’s networking ‘problem’ is odd too. By default, initng’s default.runlevel has ‘net/all’ as a goal, ensuring that networking will be configured. Their complaint is that if you remove this goal (to say that you don’t require networking) AND nothing else you want to run requires networking then… networking won’t be configured under initng. That’s what you want, isn’t it?
They complain that:
It’s also not clear how the dependencies interact with the different types of job, a dependency on Apache would need the daemon to be running where a dependency on “checkroot” would need the script to have finished running.
Since initng already works, this clearly isn’t actually a problem (I think that initng uses ‘services’ and ‘daemons’ to handle the two different cases).
I’m not saying initng is perfect: it’s still fairly confusing, the error messages are difficult to understand, syntax errors in the configuration files can make it crash, and most of the required documentation is not yet written, but the complaints in the article about it just don’t seem to make sense.
Well, a thorough comparison might not have been on the list at Ubuntu… It might be that the superficial comparison is a weak explanation that already existing solutions didn’t fit Ubuntu’s purpose.
If I read it right, initng requires the user to choose what he wants to run and the user needs to configure initng accordingly.
Ubuntu’s philosophy is that the default system needs to assume that the enduser doesn’t know anything about what he wants, so the system needs to do as much as possible to make the particular configuration it runs on work. It is a “just works” philosophy. It is absolutely not aimed at power users.
That is why startup is as autosensing as possible and requires as little input as possible from an unwitting end-user. It is noob-friendly (or it will be).
I like the idea of having a no brains required init. For newbies it poses the least amount of problems and power users (like me can still get out their pliers and bend it into shape if the fit is a little off.
http://smarden.org/runit/
Well? Has it been done before (just without the show)?
Is this old news?
Edited 2006-08-27 10:53
Actually, no. runit is based on concepts seen before in daemontools, which aims to provide high-availability for computer services/daemons by actually watching them and restarting them should they die. This is unlike sysvinit, for instance, which only starts or stops them and doesn’t care in-between.
IMHO, the “perfect” init system needs to provide these:
* Goal description via dependencies
* Multithreaded launch whenever deps allow it, to speed up boot-up and shutdown
* Unlimited number of custom runlevels, fully described by the administrator via goals
* Ability to switch from any runlevel to another by calculating the best way to accomplish the goals
* (This is a big one) separation of initialize/cleanup tasks and daemons/services. Tasks are one-time jobs to be performed while goal-hunting, services need to be monitored constantly. Setting your keyboard repet rate is a task, keeping Apache working is a service.
* Last but not least, it should be built on top of a very common scripting language, to allow admins to extend it easily. sysvinit got it perfectly here, because every admin should know Bash.
“* Goal description via dependencies”
To be honest I dont really understand what you mean by this.
“* Multithreaded launch whenever deps allow it, to speed up boot-up and shutdown”
I dont see what benefit threading gives as long as the startup is asynchronous.
“* Unlimited number of custom runlevels, fully described by the administrator via goals
* Ability to switch from any runlevel to another by calculating the best way to accomplish the goals”
I completely fail to see the point of runlevels other than normal and single-user/”safe-mode”.
“* Last but not least, it should be built on top of a very common scripting language, to allow admins to extend it easily. sysvinit got it perfectly here, because every admin should know Bash.”
Bash is not a common scripting language, POSIX-compatible shell scripts are.
Sorry, but i see that you have no idea what linux is.
First, “* Goal description via dependencies” means that you set a goal, like “i want to use kde”. then upstart looks what applications are needed for this, and then starts them in the best and fastest order.
then, * Multithreaded launch whenever deps allow it, to speed up boot-up and shutdown”
This is very usefull. When you wake up your lan connection, most of the time a dhcp request is sent out. during the waiting, nothing else happens. Anyway, a big part of the booting process is spent with waiting (dhcp answer, dns answer, reading config files), during this time other applications can start. You realy missed the point of multithread.
then, “I completely fail to see the point of runlevels other than normal and single-user/”safe-mode”. ”
Again, your perhaps a linux desktop user (well, i doupt that you use linux anyway), so you migth not know. You can have a linux box, and want it to do different things, like server, and desktop (perhaps desktop when you want to condfigure it). Or you have a runlevel for different server types. there are so many possibilities, sure, there is no use for a desktop machine, but for servers it can be very usefull.
“Sorry, but i see that you have no idea what linux is. ”
Yes, I really have no idea. At all. I’ve only used it since 1996 (RH 4.0 Colgate).
“First, “* Goal description via dependencies” means that you set a goal, like “i want to use kde”. then upstart looks what applications are needed for this, and then starts them in the best and fastest order.”
Ok, now I get what you mean.
“You realy missed the point of multithread.”
Not at all but multithreading isn’t the only solution to your problem. Applications can be started simultaneously without the launching process being multithreaded. Using multithreading is in itself not a goal and it’s not necessarily the best solution to the problem.
“Again, your perhaps a linux desktop user (well, i doupt that you use linux anyway), so you migth not know.”
I do know and I do use Linux, both on servers and workstations (along with a much larger number of OpenBSD boxes).
“You can have a linux box, and want it to do different things, like server, and desktop (perhaps desktop when you want to condfigure it).”
Sorry, I don’t see the point in using different runlevels for this. It’s a marginal use-case, imo.
“Or you have a runlevel for different server types. there are so many possibilities, sure, there is no use for a desktop machine, but for servers it can be very usefull.”
Do you boot into different server types a lot? I really don’t see the point of this. It’s a marginal use-case, imo.
“there is no use for a desktop machine, but for servers it can be very usefull.”
Either a server mostly works and you just want it to run or there’s a serious problem and you need single-user. I’ve never seen the point in any other “runlevels”.
Edited 2006-08-28 11:16
then, “I completely fail to see the point of runlevels other than normal and single-user/”safe-mode”. ”
Again, your perhaps a linux desktop user (well, i doupt that you use linux anyway), so you migth not know. You can have a linux box, and want it to do different things, like server, and desktop (perhaps desktop when you want to condfigure it). Or you have a runlevel for different server types. there are so many possibilities, sure, there is no use for a desktop machine, but for servers it can be very usefull.
Not counting single-user mode, name a situation where you have ever used more than 1 runlevel. Name a situation where you know someone who has used more than 1 runlevel.
Why do I need two separate runlevels to decide if I want to run a GUI or not? Why not just have a simple config file that has, oh I don’t know, xdm_enable=”{YES|NO}” in it.
I’ve never understood the whole SysV init process with 15 runlevels (Linux only uses the first 9, although nobody knows about the ones above 6). How often do you reboot your servers? How often do you reconfigure your servers?
There’s really only two modes that a system can run in: single-user mode for doing repairs, installs, configs, etc, and multi-user mode for everything else. What more do you need?
The BSD world got it right. A single, simple config file with *_enable lines, a single directory with RC scripts, and a tool parses the scripts to generate a dependency tree. The only thing missing is a method to do parallel tasks at boot/shutdown.
“The only thing missing is a method to do parallel tasks at boot/shutdown.”
It’s possible to replace the BSD (OpenBSD at least) init process with runit. I did that once just to try it and it worked fine. It’s also a great way to end up with a total frankensystem that’s a nightmare to keep up to date and support. ;P
Edited 2006-08-29 09:49
“* Goal description via dependencies”
To be honest I dont really understand what you mean by this.
Instead of saying “network start” at a fixed position in the runlevel to-do list, you say “apache needs networking” and “networking needs a network card”. The init system sorts out the order based on these dependencies.
I dont see what benefit threading gives as long as the startup is asynchronous.
Asynchronous to what? Let me rephrase my statement: whenever possible, run runlevel init tasks in parallel. There are a lot of individual tasks that don’t need a lot of cpu power, but if you wait for each one sequentially you’re wasting time.
I completely fail to see the point of runlevels other than normal and single-user/”safe-mode”.
That’s because you’re caught in the “runlevel” paradigm. Then think of them as profiles: “maintenance”, “at work”, “at home”, “using wifi in a public place”. Each one may have special needs which don’t stop just at network configuration. At work I need apache, at home I need beagled. With wifi in a public place I need a strong firewall. Maintenance aka single mode has its own needs. The idea is to allow everybody to configure their own “runlevels”, not impose a rigid couple of them on everybody.
Bash is not a common scripting language, POSIX-compatible shell scripts are.
Technically you’re right, but you’re nitpicking. Bash is pretty ubiquitous. The only other honest competitor is Perl and Debian for instance has based parts of apt on it.
“* Goal description via dependencies”
To be honest I dont really understand what you mean by this.
Instead of saying “network start” at a fixed position in the runlevel to-do list, you say “apache needs networking” and “networking needs a network card”. The init system sorts out the order based on these dependencies.
They should really have a look at RCng as implemented in NetBSD and FreeBSD. While it has a few issues (can’t easily use the rc scripts to start/stop things after boot for services you don’t want started at boot), it does a lot of what you are describing:
– simple text config file that lists the items you want to start/stop at boot
– the RC system looks at the REQUIRES, BEFORE, and PROVIDES lines in the rc script and builds the dependency tree dynamically at boot/shutdown
– a bunch of other stuff I haven’t really needed to use or looked into as yet
The only thing RCng doesn’t do, at the moment, is parallel task execution.
Compared to the horrid mess of symlinks that is SysV init, RCng is a dream to use.
Why do we need yet another init system? And why does Ubuntu need one? Hopefully at least Debian is going to use it otherwise there’s another good-bye from the Ubuntu developers.
Ah well, I forgot. This is UNIX where everything has to be developed at least three or four times. What a waste …
“why need” is explained in the article. Time has passed and older init systems are not good enough anymore. Have you read the article?
“why Ubuntu”: Why not? They feel the need for such a software, they are developing it. That’s how the open source movement works. Should they wait for someone else to develop it?
“What a waste”. It’s not waste, it’s evolution. Or do you want to go back to “sh” with no history, X server without any acceleration, TWM, non-resizable filesystems, tar limited to 100 character filenames, the “ex” editor, monochrome 80×24 terminals? All of these were “good enough” at some time.
1. there are enough solutions that all work rather well. There is just no need for another init. That’s all.
2. As I said: I hope Debian is going to use it too.
3. It is waste. What for do you need several tools that do – more or less – exactly the same thing. Do you need four OpenOffice? No.
1. Obviously not. Have you read the article? They have some serious motivation and goals for doing this work.
3. It’s not a waste. It’s (will be) a better tool then the existing ones. And better is always better. More choice is better as well. I don’t need four OOo, but knowing that OOo must evolve, because KOffice or the Gnome Office suite are continuosly getting better, is good. It assures me, the OOo will also get better in time.
1. And yet, this group of developers have studied the options and found them lacking for their needs. Why do you think this is?
3. There are many reasons to have “several tools that do – more or less – exactly the same thing.” Like text editors and web browsers and programming langauges and desktop environments and operating systems. Not to mention cars, planes, forks, houses…
I think it basically comes down to the fact that a single tool can’t be all things to all people: there will generally be some kind of tradeoff. There is enough variation in people that each side of the tradeoff will look appealing to at least some of them.
Is this waste? I dunno. There may be something to be said about diversity in product ecosystems, Darwinian economics and whatnot. The fact of the matter is people want to do these things. You or I calling it wasteful is not likely to change their minds.
1. And yet, this group of developers have studied the options and found them lacking for their needs. Why do you think this is?
Good for them and so we hope that this incompatibility crap goes no further than their personal computers.
Edited 2006-08-27 20:17
I like the fact that it is event based instead of dependency based. This makes the system a lot more dynamic, and still makes sure all dependencies are met.
For example, consider anything USB based, let’s say a net card. Net card plugged in -> driver loads -> system generates event indicating new device of type X -> job is started to upload firmware (for example) -> device is now ready -> depending on configuration, let NetworkManager handle the new device or look up a static config for it.
It also takes away a lot of the complexity in dependency based systems like the gentoo init system, or the various systems mentioned above. Furthermore, it should automatically provide parallel booting, which should be quite a bit faster.
What does plugging a USB card into a system have to do with the startup/shutdown process? By the time the system is able to start generating events like this, the init process has ended.
What you are describing is a devd that monitors hardware buses for events and takes action based on the event. udev tries to do this, but fails pretty miserably in my experience.
> launchd is the replacement init system used in MacOS X
> developed as an “Open Source” project by Apple.
> For much of its life so far, the licence has actually
> been entirely non-free
Yeah, right… “The Apple Public Source License (APSL) version 2.0 qualifies as a free software license. Apple’s lawyers worked with the FSF to produce a license that would qualify.” See http://www.gnu.org/philosophy/apsl.html
The recent license change he’s talking about is the switch to the Apache License.
Edited 2006-08-27 11:44
What about ‘for much of it’s life’ don’t you understand:
https://wiki.ubuntu.com/ReplacementInit
“Before writing this specification, a comprehensive review of the existing replacement init systems was performed and each one tested to discover whether it was able to solve our problems. Most of them by far were not fit, in fact only four passed the most basic test of being maintained by their author and suitable for production use.”
launchd was one of them. They did consider it, but it didn’t solve their problems.
Well, I wonder how SUSE, Red Hat/Fedora, Slackware, Gentoo, Debian etc. can exist _without_ upstart. They must have really crappy systems and customers that give a damn about the quality of their software.
But along comes Ubuntu that has “problems” only upstart can solve. It’s just funny that Ubuntu is a Linux distribution. But hey, never mind … it’s just a side note
Obviously they can all exist without upstart. However, that doesn’t mean that they couldn’t use something better. It really sounds like a very good system. I currently use Fedora, but I will change to Ubuntu once they get this implemented.
Well, untill now everybody just had to make do with the exixting sysvinit system. Some projects have been started trying to replace sysvinit, but these have never made a wide impact on distributions. It indicates they are not a well fit for current distro’s.
Upstart has the advantage of a well funded development team, with a real world distro to develop it on as a serious replacement for the badly ageing sysvinit.
Just because it is developed by the Distro that every GNU/Linux veteran seems to love to hate, doesn’t mean that it will be useless or that it won’t become the gold standard on other distributions.
Philosophy of init-scripts replacement :
https://wiki.ubuntu.com/ReplacementInit
how does it compare to rcng? they compare to launchd, initng and smf only..
anything replacing sysvinit cant be any worse
Clearly the fact that other projects are/have worked on a new init system shows that the need is there or at least perceived.
I am not sure we needed (yet another) project for a new init system but if their system is truly different than others then I guess it may be justified. I would like to see some new init project be well supported and come up with a good solution.
Upstart sounds interesting, but I am worried that it is looking really good on paper but implementation is going to reveal that it also has drawbacks and limitations. I do hope they manage a great implementation! So best of luck, and hope it all works out!
Thats what I always wanted in my Linux machine because I frequently use USB devices.
Good work canonial…
These comments read as if Ubuntu was its own distribution. Well, it’s not. It depends on Debian. If Debian is fine, Ubuntu is fine. But if Ubuntu invents more and more things on its own not taking care where Debian is moving to, then there is a slight problem with that dependency. It’s more a problem for Ubuntu, because the development is done – well, 95%, I should say – on the Debian side.
They can always push the changes upstream. IIRC, they wanted to offer their changes to Debian all along.
From https://wiki.ubuntu.com/ReplacementInit
Other Distributions
It is hoped that other distributions will see the benefit in the design outlined here, and will also choose to adopt the same system as their replacement for init. They have already been approached and the feedback has been largely positive and waiting on an implementation to test. It is also hoped that this could form the basis for a new LSB standard to replace the under-implemented chkconfig.
They already talked to other distros and the message has been well received.
> It is hoped that other distributions will see the benefit in the design outlined here
– SUSE hoped that Redhat would see the benefit of Yast
– Debian had hoped that SuSE and Redhat would have seen the benefit of apt-get
– Mandrake had hoped that other distros would have seen the benefit of turning off REGPARM in their kernels
– Fedora had hoped that other distros would have seen the benefit of not allowing binary drivers to be loaded
– Novell had hoped that Redhat would have seen the benefit of including Xen
– Redhat had hoped that other vendors would have seen the benefit of using their BlueCurve GNOME/KDE mishmash.
Finally LSB had hoped that ALL distros would have seen the benefit in a standard Linux base definition
Edited 2006-08-27 18:10
> SUSE hoped that Redhat would see the benefit of Yast
Notice that Yast never made it into Debian or it’s commercial offshoots (e.g. Linspire and MEPIS) or Mandrake who have no qualms about using Qt tools. The reason is that Yast has several SUSE specific features and from what I’ve read, it seems to be mostly GUI centered and does not produce files that are amenable to manual creation and editing (sort of like or Visual Studio 6 template generated code).
> Debian had hoped that SuSE and Redhat would have seen the benefit of apt-get
They have. They just used their own implementation of apt-get that is better suited to RPMs (read Red Hat’s reason for creating YUM).
> Fedora had hoped that other distros would have seen
> the benefit of not allowing binary drivers to be loaded
Debian had that hope too. And Novell finally came around to this point of view too.
> Novell had hoped that Redhat would have seen the
> benefit of including Xen
They do and they *are* contributing to get Xen into the *standard* kernel. They just don’t want to support massive patches that are incompatible with many device drivers. RedHat isn’t the only distro that’s cautious wrt Xen but will support it fully when it matures. Read: https://wiki.ubuntu.com/XenEdgy
> Redhat had hoped that other vendors would have seen
> the benefit of using their BlueCurve GNOME/KDE
> mishmash.
The BlueCurve theme didn’t get much support, but the idea of a cross-desktop theme did take off. That was a radical idea at the time (with KDE and GNOME screeming murder at changing their default), but these days its quite common.
I don’t know if upstart has any future, but it does implement different ideas that are worth exploring, so what’s wrong with that?
At least for Edgy, it will be implemented only as an option from the Universe repository (i.e. it’s not supported, but it is available) just like initng. If other distros jump on upstart, Ubuntu will likely follow suit. If everyone else chooses initng, Ubuntu will need to decide if the benefits of upstart are worth the price of being nonstandard.
To what I understand, one of the long-term goals of Upstart is a remplacement for init and system services like at, cron and inetd. While I am perfectly aware that GNU’s Not Unix, it seems to go against the Unix philosophy, which is “do one thing, do it well”.
If the Upstart process handles all these tasks, then I fear it could become a single point of failure. A bug in one of its parts could bring the whole system down. Remember that we are talking of an init replacement.
On the other hand, if Upstart is a collection of software (pretty much like Postfix), then it wouldn’t be much different from the current situation, where daemons are spawned. Wouldn’t it be more productive to adapt current solutions rather than writing their owns?
Support for sysv-init script doesn’t thrill me either. I understand that it would ease transition, but still. Why supporting the past if you are trying to break your ties with it? It will only hinder adoption, not to mention that those who prefer to keep their old init scripts will probably just rely on sysvinit, anyway…
Of course, I can only wish them best of luck with their project. It’s not the direction I would have taken, but it’s not my OS, after all. Still, I believe they could encounter some difficulties at getting it as a replacement for all GNU/Linux systems out there.
> To what I understand, one of the long-term goals of
> Upstart is a remplacement for init and system
> services like at, cron and inetd. While I am
> perfectly aware that GNU’s Not Unix, it seems to go
> against the Unix philosophy, which is “do one
> thing, do it well”.
From my understanding, upstart does do one thing: to start and stop services in response to events.
I imagine events could include things like a particular time has occurred or a connection has been made to a particular network socket. That would be how it is able to replace at, cron and inetd as well.
Actually, jobs would be the proper term, since upstart doesn’t make a difference between a task and a service. Furthermore, it will need to supervise these jobs for automatic restarts, logging failures, etc. That’s already two things to do…
Given its event-driven nature, I guess it makes sense to replace at and cron. Still, it will need to monitor time. As for inetd, it really depends whether they plan to replace the original version or xinetd… The former would be trivial, the latter would have some complications since it got many complex fetures like access controls (hosts, number of connections, redirection) that doesn’t really belong in an init daemon, at least IMO.
All that dynamic & event-driven stuff seem to add a layer of complexity that could be hard to manage. We’ll see where this is going to lead, but I’m still skeptical on its impact, especially in performance.
It used to be that regardless of what Linux distribution you chose, you could be pretty certain that you would have a base system that can be pretty much controlled in one manner. They stuck to the true nature of opensource by competing and collaborating. However, I see more and more distributions who now choose to only compete. They create their own opensource solution that only they will use, in effect, making their solution’s opensource nature useless.
Amen brother – Why doesn’t Ubuntu swallow some pride and just port Solaris’s SMF?. Atleast there would be two systems that share some commonality. I can bet you 1000 bucks that ANYTHING developed by Ubuntu will NEVER be used by Redhat/SuSE/Debian/Mandrake/Slackware – it’s bad enough that app developers have to contend with Redhat’s chkconfig and suse’s chkconfig programs to start and stop systems and then deal with Debians init scripts in a different manner than Slackware’s initscripts.
I think Open SOurce sucks and we might as well resolve to having one company doing Linux one company doing MacOS, one company doing Windows and one company doing Solaris.
We do have one company doing linux. Mandrake does its linux. Debian does its linux. Suse does its linux. How cool is that!
A 1000 bucks says you can look in almost any debian based distro and find packages with ubuntu in the name. You honestly think everything in debian was developed by debian?
I have this great idea… Take a look in the debian cvs logs and grep for ubuntu. Well I guess you would be surprised that major packages like oh, x.org, were packaged by ubuntu and then accepted into debian.
Also look at the work Canonical (ubuntu) employees have put into debian. Search the gnome bugzilla for ubuntu email addresses and you will see what I am talking about.
Stop your trolling.
“Why doesn’t Ubuntu swallow some pride and just port Solaris’s SMF?”
Read. The article.
I can bet you 1000 bucks that ANYTHING developed by Ubuntu will NEVER be used by Redhat/SuSE/Debian/Mandrake/Slackware
Anything? Ever?
You’re on
Are they trying to get this implemented in time for Edgy?
if you *read* the article, you will find out your answer.
Tip: “The current plan is that we will be at least part of the way into stage #3 by the time edgy is released”
Tip #2: Read the article to find out what stage #3 is.
I stand corrected
Don’t see parallel booting as a problem to be solved, serial sure. I’m not a single point of failure fan so the ideas of lumping the funcitionality into one super daemon does not appeal to me in the slightest, more like a step backwards.
Did you read the article about upstart or the wiki I put in my previous post? They state clearly that the current way is not desired and that it could be solved better, they also start with the code from their current INIT system but the changes are gonna be big enough to call it a new program. There are going to be changes that will make things easier as well.
I like Ubuntu, specifically Xubuntu, but it looks like I’ll be on the search again for a Linux that doesn’t suck when this gets released. Why? As if handling init on Debian based systems wasn’t an overly complex pain in the ass before, Ubuntu seems to want to make this even worse. And while they’re at it they’ve decided to replace cron, inetd, and god knows what else.
Edited 2006-08-27 18:15
Oh my god! They killed init. You bastards!
– Good one
Very good news. Apple’s intoduction of launchd really did wonders. I’ve seen a 700MHz iMac G4 boot tiger in 35 seconds, 30 of which was pre-gui, a third of that waiting for the bong and black screen (which takes a dramatically less amount of time on Macintels)
Similar results in Linux would be a boon.
Edited 2006-08-27 21:08
Actually I just ran Bootchart on my Debian Sid box, and it booted up to GDM in 35 seconds. Pretty quick for a Linux system, I’d say. I haven’t done any sort of tweaks to it either, and am running splashy.
Granted this is on my Desktop, in which case I don’t reboot all that often (unless I’m rebooting to my Windows partition, in which case of course Windows has to reboot every stinking update, not to mention it takes much longer to get to a usable state than Debian does, with the anti-virus, firewall, anti-spyware, etc.)
I’m actually quite impressed with Debian’s improvements since Sarge’s release, they are huge. I am probably going to test it again on my laptop which is currently running Edgy Eft.
VectorLinux has an option for a modified init system called vlinit. It would be good to see it in the fray too!!
Here is a link to more detail.
http://distro.ibiblio.org/pub/linux/distributions/vectorlinux/devel…
Edited 2006-08-27 22:18
+1 because I love VectorLinux 8)
They have. They just used their own implementation of apt-get that is better suited to RPMs (read Red Hat’s reason for creating YUM).
Red Hat did not create YUM.
http://en.wikipedia.org/wiki/Yellow_dog_Updater%2C_Modified
Sysvinit needs to be replaced. That much seems apparent to me.
My main gripe with it is its total brain-deadness when it comes to parallelism. SCO Openserver has had parallelism in its boot process since the mid 1990’s. Crude, yes. But still more advanced than what Linux has in 2006. (And what could possibly be more insulting while remaining true, I ask you?)
My initial feelling, when I heard about Upstart was “Yea, finally”!
But the more I think about it, the more I think this is overkill. I don’t want to replace crond, atd, xinetd, and Sysvinit. I just want an init system that isn’t totally unintelligent. Despite appearances, you can bet that a *lot* of work has gone into Sysvinit.
See http://www.joelonsoftware.com/articles/fog0000000069.html
That’s enough to try to redo. But to then tackle crond, atd, and xinetd, too?
Even that might not be enough to dissuade me from being excited about Upstart.
But then, I note that the 3 step plan does not include a step to “see if any other distros are interested”.
I like Ubuntu. I use Ubuntu. I think they’ve done great work. I don’t require convincing that Sysvinit either needs to be replaced or needs some major attention.
But I can’t help but wonder if this plan is ill-conceived. If other distros jump on board, I might get more excited. But as long as it is this ambitious, this isolated, and is solving problems that I didn’t really know existed until this article explained them (I thought hald was doing a good job of making my sd card available to me when I plug it in) I’m gonna say I’m a bit skeptical.
But I’m not averse to having my mind changed on this one.
SCO stealing a march on Linux? Ouch.
Neither cron nor atd are particularly advanced: anyone could write their own replacement. Indeed, cron is such a poor scheduler by today’s standards that many people have written their own replacements, such as the increasingly popular fcron.
xinetd is a bit more advanced, but not by much. You just open a load of sockets on a load of ports. When you receive an incoming transmission you close the port, start the service, and forward the transmission to it. There are issues with making sure nothing gets lost between closing the xinetd port and the server opening its own port, but that’s the worst of it, and xinetd being open-source and free, there should be no major difficulties copying the necessary code where needed.
Frankly, it seems like an excellent project. They’re already fairly advanced (on stage 5 of 7 I think), and they should be done within a year if they stick to their schedule.
I’m not sure what you’re talking about WRT to closing ports. (x)inetd hooks the socket traffic to the stdin/stdout of the “daemon” process.
I use and love ubuntu, im non technical user and usually boot once a day … so boot time isnt a huge issue. But iv still run across a few issues with usb devices. if this goes a long way to making usb devices on startup more robust then power to them.
Also, really surprising the number of replies who have clearly not read the article. Its not even a long or technical read, its actually quite an enjoyable account of where they are heading.
Their reasons for wanting the new system are explicit and well put in my mind. plus their approach seems more rational than a dependency based system.
I just thought, well funny enough the automobile as invented by Karl Benz & Gottlieb Daimler is even older, but still people get crazy about it.
As if the date of first invention of something would be of any importance. Let’s not even start to talk about Music, which to be honest hasn’t much evolved in the last 30 years… And still it’s a great bird puller.
I have managed to get my Linux box to boot in 19 seconds just by changing the order of when services are started, and putting a few of them in the background, e.g rc.network.