Originally posted by funkSTAR
View Post
Announcement
Collapse
No announcement yet.
Upstart Now Available In Debian Unstable
Collapse
X
-
-
Originally posted by Bernard Swiss View PostSystemd may be all kinds of "cool"; but its arguably an inherently and needlessly obfuscating, complicating approach -- that imposes the same drawbacks on all too many other tasks, bits of software and other files that it touches, and even requires new tools to deal with the problems it creates. It's a very "MS Windows" way of doing things, and its not clear that the benefits actually outweigh the drawbacks. Some would even describe it as a solution looking for a problem.
The rest is about features which will keep linux(thus its sponsors) relevant tomorrow. Linux NEEDS flawless session management, ressource control better than nice-levels, a metadata based logging which cant be tampered by intruders and so on.
This what systemd is about. Clean boot, and a bootload of future features. Shopping init and session systems is a different thing to teenagers shopping shoes. You cant just follow your feelings. You need to do whatd right. Systemd doesnt exclude others by CA, it has a growing community and is getting adopted in fast pace. Upstart is just a skunkwork.
Leave a comment:
-
Originally posted by 89c51 View PostThe interesting bit about Upstart is that Canonical seems to be sticking to it and also -according to LP G+- they want to use it in the user session.
- - - -
I'm probably speaking beyond my competence, here, but here goes:
Upstart is arguably an improvement on SysV init; it's simple, straight-forward, and human-readable/comprehensible, like Unix-y software should be whenever possible.
Upstart isn't much more complicated than SysV init, and offers some clear benefits. It's right dead-centre in line with the "Unix philosophy" of software and operating system design.
On the other hand: Systemd may be all kinds of "cool"; but its arguably an inherently and needlessly obfuscating, complicating approach -- that imposes the same drawbacks on all too many other tasks, bits of software and other files that it touches, and even requires new tools to deal with the problems it creates. It's a very "MS Windows" way of doing things, and its not clear that the benefits actually outweigh the drawbacks. Some would even describe it as a solution looking for a problem.
Leave a comment:
-
Originally posted by ryao View PostHow does the Ubuntu CLA differ from copyright assignment to the FSF?
Upstart: CA, low canonical investment, no community.
Systemd: no CA, high RH investment, much larger community.
Systemd is already way ahead based on technical merits. Based on metrics like keeping the source code on free license and building communities systemd is your pick.
So in order to follow your PurgePoettering agenda you have to accept less features, less freedom and less community. Only a suffering hater can do something this stupid. I hope you will get well by time. God bless you.Last edited by funkSTAR; 30 November 2012, 01:39 PM.
Leave a comment:
-
Originally posted by kigurai View PostIf sysvinit is the only really good choice to couple with OpenRC, why would I want that instead of just running sysvinit directly? Genuine question, because I haven't used gentoo in a long time, and never heard of OpenRC.
Let's use a software xxx that can use different database backends as an example. On Gentoo, I can just put
Code:use mysql postgresql
Code:rc-update add postgresql-9.2 default rc-update add xxx default
Leave a comment:
-
Originally posted by ryao View PostWith that said, systemd is probably the worst choice possible for an OpenRC init daemon on Linux. systemd has the largest quantity of code that would be useless for anything other than introducing bugs and regressions. sysvinit is the best in this regard while upstart is somewhere in-between the two.
Also, the "more code = more bugs" is a rule of thumb, not some kind of law. As you are probably aware there are some really stable pieces of hardware with milions of lines of code (Linux kernel, to take one relevant example), and lots of very small applications that are riddled with bugs.
If systemd crashed substantially more than sysvinit I suppose you could have a point. I have not seen anything that hints about that.
Leave a comment:
-
Originally posted by AdamW View Post...which, according to the talk page, appears to have been primarily written by someone with an agenda to promote OpenRC. I give all such stuff - including Lennart's similar table for the purpose of pimping systemd at http://0pointer.de/blog/projects/why.html - approximately the same weight, i.e., very little. But at least Lennart put his table on his blog and acknowledged that he was likely to be biased, while in this case the table was published on what is supposed to be a neutral site with no acknowledgement of the author's bias.
Originally posted by AdamW View PostI haven't looked at it in any detail, no, because it just doesn't seem significant enough. My evaluation of the meta-discussion on init daemons is that OpenRC has no chance of adoption outside its current niche, so I haven't bothered using any of my finite time to look into it much.
With that said, systemd is probably the worst choice possible for an OpenRC init daemon on Linux. systemd has the largest quantity of code that would be useless for anything other than introducing bugs and regressions. sysvinit is the best in this regard while upstart is somewhere in-between the two.Last edited by ryao; 29 November 2012, 08:49 PM.
Leave a comment:
-
Originally posted by ryao View PostOpenRC was designed to plug into an existing init system. When it does this, that init system will handle basic things like starting OpenRC and setting up terminals. Any init system will suffice and sysvinit is perfect for this on Linux because it provides the basics that OpenRC expects and nothing more. OpenRC provides the rest. You cited upstart and systemd as having new capabilities that systems using sysvinit lack, but OpenRC is special in that it can provide many of those capabilities to systems using sysvinit.
It's an interesting design, sure. I'm not sure what it wins you in practice, though, because apps can and often do ship both sysv and systemd-native/upstart-native init scripts. What's the practical difference between shipping an internally-complete sysv script along with an internally-complete upstart/systemd-native script, and shipping an internally-complete sysv script along with a not-internally-complete OpenRC script that builds on the sysv script?
Remember in context we were talking about socket activation, so far as I can tell, OpenRC has no capabilities for socket activation anyway.
Originally posted by ryao View PostThere is a nice feature comparison between OpenRC, Upstart, Systemd and sysvinit in the OpenRC Wikipedia article:
Originally posted by ryao View PostYour question suggests that you have never examined OpenRC. I highly recommend taking a look at it.
Originally posted by ryao View PostHow does the Ubuntu CLA differ from copyright assignment to the FSF?Last edited by AdamW; 29 November 2012, 04:37 PM.
Leave a comment:
-
Originally posted by AdamW View PostI honestly don't see how this paragraph has anything at all to do with the paragraph you quoted, which was about socket activation.
There is a nice feature comparison between OpenRC, Upstart, Systemd and sysvinit in the OpenRC Wikipedia article:
Your question suggests that you have never examined OpenRC. I highly recommend taking a look at it.
Originally posted by AdamW View PostTo simplify massively, the systemd and upstart developers could not agree on a design, and so could not work on the same project. This is touched upon in http://0pointer.de/blog/projects/systemd.html "On Upstart". It's probably also significant that RH staff are in general not allowed by corporate policy to sign the Ubuntu CLA as our legal department is not happy with it.
Leave a comment:
Leave a comment: