Page 4 of 8 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 71

Thread: Upstart Now Available In Debian Unstable

  1. #31

    Default

    Quote Originally Posted by AdamW View Post
    I honestly don't see how this paragraph has anything at all to do with the paragraph you quoted, which was about socket activation.
    OpenRC 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.

    There is a nice feature comparison between OpenRC, Upstart, Systemd and sysvinit in the OpenRC Wikipedia article:

    http://en.wikipedia.org/wiki/OpenRC

    Your question suggests that you have never examined OpenRC. I highly recommend taking a look at it.

    Quote Originally Posted by AdamW View Post
    To 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.
    How does the Ubuntu CLA differ from copyright assignment to the FSF?

  2. #32

    Default

    Quote Originally Posted by ryao View Post
    OpenRC 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.
    Okay. Fine. I still don't see how that fits in context.

    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.

    Quote Originally Posted by ryao View Post
    There is a nice feature comparison between OpenRC, Upstart, Systemd and sysvinit in the OpenRC Wikipedia article:

    http://en.wikipedia.org/wiki/OpenRC
    ...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.

    Quote Originally Posted by ryao View Post
    Your question suggests that you have never examined OpenRC. I highly recommend taking a look at it.
    I 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.

    Quote Originally Posted by ryao View Post
    How does the Ubuntu CLA differ from copyright assignment to the FSF?
    I am not a lawyer and not interested in going into any detail on that whole thicket. There are plenty of posts around the blogosphere if you want to get into it. I just noted it as a fact of life: my personal opinion or yours is irrelevant to the fact that RH devs in general can't contribute to projects that require signing of the Ubuntu CLA. Note that systemd does not require any kind of copyright assignment or agreement for contribution, so far as I know.
    Last edited by AdamW; 11-29-2012 at 03:37 PM.

  3. #33

    Default

    Quote 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.
    The comparison could use more information, but I would not consider it to be written in favor of OpenRC. It shows outstanding issues that need to be resolved. On the other hand, Lennart's comparison makes no mention of such things, takes credit for things in udev, such as "Automount handling" and ignores things that are handled on systems using alternative systems , such as "Swap handling". There are also some fairly vague bullet points like "XDG_RUNTIME_DIR Support" and "Built-in kexec support". I have no idea what "XDG_RUNTIME_DIR Support" means and kexec is a tool that needs no scripts. I often run it by hand when testing kernel modifications.

    Quote Originally Posted by AdamW View Post
    I 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.
    OpenRC is not an init daemon. It is an RC system that relies on an external init daemon. In theory, it can run on top of systemd.

    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; 11-29-2012 at 07:49 PM.

  4. #34
    Join Date
    Nov 2012
    Posts
    206

    Default

    Quote Originally Posted by ryao View Post
    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.
    If 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. But to me, it sounds a bit hypocritical to bash systemd for "unused code" while championing an init system that sits on top of another init system...
    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.

  5. #35
    Join Date
    Nov 2012
    Posts
    2

    Default

    Quote Originally Posted by kigurai View Post
    If 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.
    Just a Gentoo user here. With OpenRC, first and foremost, I am free from the horror of the 0 1 2 3 4 5 6 runlevels. Also, I found the syntax provided by OpenRC (need, use, provide, before, after) to be very nice.

    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
    in the /etc/init.d/xxx script, and then never have to bother whether the deployed instance uses MySQL or PostgreSQL. Let's say my deployed instance uses PostgreSQL, while I also have MySQL installed on the same machine for testing only and thus doesn't want it to autostart, then I can just run:
    Code:
    rc-update add postgresql-9.2 default
    rc-update add xxx default
    and it will just work. As I mostly just use Gentoo, I am not sure how to do the same with sysvinit, upstart, or systemd.

  6. #36
    Join Date
    Dec 2011
    Location
    Basement
    Posts
    389

    Default

    Quote Originally Posted by ryao View Post
    How does the Ubuntu CLA differ from copyright assignment to the FSF?
    FSF is a non-commercial org caring deeply about software freedom.They want CA to maximize legal protection for the licensed code. Canonical is just a RH competitor seeking an advantage. They dont want CA to keep the code open and protect it. Canonical want the copyrigtht so they can do whatever skunkwork they need. This includes distrobuting closed source editions. And yes Canonical KNOWS the CAing will keep RH out of the loop. They are causing fragmentation without any regrets.

    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; 11-30-2012 at 12:39 PM.

  7. #37

    Default

    Quote Originally Posted by 89c51 View Post
    The 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 thought the interesting thing about Upstart was that it was something Ubuntu got right.

    - - - -
    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.

  8. #38
    Join Date
    Jul 2011
    Posts
    368

    Default

    Quote Originally Posted by 89c51 View Post
    The 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.
    How do this differ from systemd --user? I use that to control my user daemons.

  9. #39
    Join Date
    Dec 2011
    Location
    Basement
    Posts
    389

    Default

    Quote Originally Posted by Bernard Swiss View Post
    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.
    You really should go read what the systemd commumity is doing. They are making boot so much simpler and tje truth is they are inspired by other unixy "friends" from Apple, not MS. The basic idea is spawnig as few processes as possible and do socket activation. Is is simple and clean, and as a side effect; damn fast! Thats for init.

    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.

  10. #40
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    390

    Default

    Quote Originally Posted by funkSTAR View Post
    You really should go read what the systemd commumity is doing. They are making boot so much simpler and tje truth is they are inspired by other unixy "friends" from Apple, not MS. The basic idea is spawnig as few processes as possible and do socket activation. Is is simple and clean, and as a side effect; damn fast! Thats for init.
    Apple was inspired by MS, it even uses CamelCase. Unix-like OS-es never had problem spawning many processes and socket activation doesn't belong to init. If it's so simple, reimplement it in one month or even better make it POSIX.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •