Announcement

Collapse
No announcement yet.

Debian May Be Leaning Towards Systemd Over Upstart

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AdamW
    replied
    Originally posted by liam View Post
    While the comment was funny (I think the poster said something along the lines of nb not understanding the Unix way) I thought nb's response spot on.
    Argument from authority and all that...
    Well, to an *extent*. The problem is the person criticizing Neil was doing the same thing: arguing about the person, not about the issue. Levelling an entirely unfounded accusation at *Neil Brown* that he doesn't understand the Unix way is, you have to admit, pretty funny.

    Leave a comment:


  • liam
    replied
    Originally posted by AdamW View Post
    BTW, folks: if you started using Linux in the last five years, do yourself a really big favour and read up on who Neil Brown is before replying to this with 'he's just some systemd pusher who doesn't understand the Unix way!', like some hilariously misguided idiots on the LWN thread did. That gave the rest of us a good laugh.
    While the comment was funny (I think the poster said something along the lines of nb not understanding the Unix way) I thought nb's response spot on.
    Argument from authority and all that...

    Leave a comment:


  • tomato
    replied
    Originally posted by rudregues View Post
    Damn Red Hat and L.P.
    I prefer OpenRC over the extend and embrace systemd, but it seems I won't have the choice in a foreseeable future. Everyone in Linux will be forced to use systemd. The problem with systemd is not the init system itself, but the assimilation of other parts of the system.

    At least I'll have the choice between Wayland, Mir and X11, like I can with video player (mplayer2, vlc etc) or browser (firefox, chromium etc).
    The problem is, systemd fixes multiple ugly issues which really are unsolvable for anything but the init system. And sure we've lived them for few decades. You can also live with a nail in your foot for a long time, doesn't make it desirable.

    While it is true that systemd now does mean a lot more than "init process", and near future you'll be able to argue that even kernel implementation of dbus is systemd, doesn't change the fact that in practice the tools are very separate. So, please stop parroting old, multiply refuted arguments and actually read (or watch) what Pottering has to say. If you don't want to, shut up and migrate back to BSD edition 3, as you obviously like 80's so much. We'll be working in the present working on current problems.

    Leave a comment:


  • AdamW
    replied
    Originally posted by Ericg View Post
    An even better response than my own for this comes from Neil Brown...
    BTW, folks: if you started using Linux in the last five years, do yourself a really big favour and read up on who Neil Brown is before replying to this with 'he's just some systemd pusher who doesn't understand the Unix way!', like some hilariously misguided idiots on the LWN thread did. That gave the rest of us a good laugh.

    Leave a comment:


  • Ericg
    replied
    Originally posted by lano1106 View Post
    Add the news that dbus will eventually be moved to the kernel. This goes against the UNIX philosiphy that at its base is a collection of small tools specialized in doing ONE thing well.
    An even better response than my own for this comes from Neil Brown...

    Originally posted by http://lwn.net/Articles/576078/
    I remember being severly disillusioned by this in my early days. I read some article that explained how a "spell" program can be written to report the spelling errors in a file. It uses 'tr' to split into words, then "sort" and "uniq" to get a word list, then "comm" to find the differences. "cool" I thought. Then I looked at the actual "spell" program on my university's Unix installation. It used a special 'dcomm' (or something like that) which knew about "dictionary ordering" (Which ignores case - sometimes). Suddenly the whole illusion came shattering down. Lots of separate tools only do 90% of the work. To do really complete work, you need real purpose-built tools. "do one thing and do it well" is good for prototypes, not for final products.

    Leave a comment:


  • AdamW
    replied
    Originally posted by lano1106 View Post
    I have nothing to say against systemd. It is working fine.

    My concern is that it is getting bigger and bigger all the time and IMO this is worrysome.

    It could be a perfect replacement for sysv init without replacing syslog. I have heard that it is about to replace inetd. What is next?

    Add the news that dbus will eventually be moved to the kernel. This goes against the UNIX philosiphy that at its base is a collection of small tools specialized in doing ONE thing well.

    With systemd, Linux starts to look like WINDOWZE. So basically, what happens if systemd stops working after an update? By taking such a disproportionnate importance, I'm afraid that it could render a system unusable if something breaks.

    With PulseAudio on top of it, by centralizing everything in a single place, that sounds like a terrible catatrosphe waiting to happen. If this gets compromised, linux boxes, will become amazing spying devices knowing everything that the user is doing. I really don't like where this is going!
    You...really can't simplify things that much.

    It's not like there is a single systemd process running which does init, and journalling, and everything else. Just because the functions are part of one *project* doesn't mean they're part of one *code path*. It's not like a bug in systemd's journalling code will inevitably break your init sequence. Functions can be isolated from each other without being part of completely different development projects.

    Leave a comment:


  • [Knuckles]
    replied
    I think the issue is, upstart had a pretty interesting design and ideas, but had (and still has) the troubling "Contributor Licence Agreement".

    Then along came systemd, that took those ideas and others (from OSX for instance) and did them a lot further and better. I'm not aware of issues but even if it there were any, by now the project has almost 4 years of existence and plenty of experience in driving Fedora, openSUSE, Arch, etc.

    So right now I believe canonical still uses Upstart more because it's their loved baby and then don't want to both give up on him and on top of it having the trouble of migrating to systemd.

    But it the long run, it's the right thing to do. You've served us well, upstart, but it's time to go. So long and thanks for all the fish!

    Leave a comment:


  • finalzone
    replied
    Originally posted by lano1106 View Post
    Add the news that dbus will eventually be moved to the kernel. This goes against the UNIX philosiphy that at its base is a collection of small tools specialized in doing ONE thing well.
    From Neil Brown himself, UNIX philosophy is dead long time ago.

    Leave a comment:


  • profoundWHALE
    replied
    Originally posted by Serge View Post
    What makes you believe that Debian cannot maintain a fork of Upstart on their own? It is a project that records contributions on the packaging side from around 1000 people every release cycle, and that doesn't even count contributions to other aspects of the project. What makes you believe that not enough Debian contributors would be willing to sign Canonical's LCA to avoid forking? With such a large pool of contributors, surely there are all kinds of people with differing views on the LCA, not to mention that many Ubuntu developers double as Debian developers already. And finally, what makes you believe that a middle ground solution, one where those developers willing to sign the LCA submit their patches upstream and those not willing to sign the LCA keep their patches with just Debian's fork, would be unsustainable?
    The point is that it wouldn't be worth it for THEM.

    Leave a comment:


  • Serge
    replied
    Originally posted by c117152 View Post
    You're all working under the assumption the DTC decision on the matter could actually make a difference.
    You're wrong. It can't.

    Debian doesn't have the resources to maintain an Upstart fork or the volunteers willing to sign Canonical's contributor license agreement.
    And that's that.
    What makes you believe that Debian cannot maintain a fork of Upstart on their own? It is a project that records contributions on the packaging side from around 1000 people every release cycle, and that doesn't even count contributions to other aspects of the project. What makes you believe that not enough Debian contributors would be willing to sign Canonical's LCA to avoid forking? With such a large pool of contributors, surely there are all kinds of people with differing views on the LCA, not to mention that many Ubuntu developers double as Debian developers already. And finally, what makes you believe that a middle ground solution, one where those developers willing to sign the LCA submit their patches upstream and those not willing to sign the LCA keep their patches with just Debian's fork, would be unsustainable?

    Leave a comment:

Working...
X