Announcement

Collapse
No announcement yet.

Debian May Be Leaning Towards Systemd Over Upstart

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

  • #76
    Originally posted by GreatEmerald View Post
    2) You can't, without sacrificing all of the things that make journald so good, like different log priorities (warn/error/debug etc.), filtering, unified timeline view (where all of the daemon messages are shown in one place in the order that they were emitted, including the messages from the init system itself), etc.
    Log priorities in the standard error? You can't have them unless the program is rewritten with the promise that its standard error is formatted in a certain way. Which is against (1) - and then a well-behaving program could as well use the syslog. Logging by process name is found in the plain inetutils' syslogd and is in upstart too: but this discussion is really unnecessary, because the point was whether those things *need* to be done by pid 1 or not. I am already convinced that systemd is excellent software.

    You couldn't argue that. If anything, the main function of the kernel would be to control the hardware.
    What do I do with a well-controlled hardware that doesn't run processes? What's your opinion about microkernels, which do not control hardware by design?

    Care to point out an example?
    Systemd's sd-daemon library. It can be used to achieve init-system-independent socket activation and service state notification.

    No. With the new approach, you issue systemctl disable network.target and carry on with your day.
    It's not the same thing. Also, you're exchanging a soft requirement (that a server is stopped when I no longer want the network target) with a hard fact (with a stopped inetd, there is no way that any internet socket-activated service can be executed).

    Or even better, disable the actual services that you don't want to boot, because otherwise you might accidentally stop a service you did want to boot after all.
    That's only a problem if the same program that serves internet services also manages your console session. I know that I have no critical services depending on inetd, and that I can keep running internet clients if I stop inetd.

    Stopping the inetd daemon is a horrible, hacky way of doing that and you should never even consider doing that as an option.
    It was just an example. And we have a different idea of what's a hack and what's elegant.

    And that's what unit files are about. They are supposed to be cross-distribution,
    Debian for instance are currently shipping modified unit files to suit their unique environment, IIRC.

    and as far as I know there is nothing preventing other init systems from using them.
    Now that would be a good idea. How practically realizable, I don't know.

    Comment


    • #77
      Originally posted by beetreetime View Post
      They donít have to go that far. Thereís Slackware and Crux. Linux distributions known for their stubboness in accepting new technologies.

      On that subject, the Linux community will get a great boost if all distributions rally behind systemd. Itís time for distros like slackware to be made to use systemd.



      OSes compliant with the UNIX philosophy and POSIX are useless today. Donít believe me? Just look at all the BSDs today. They are so useless that their developers use either windows or apple macs instead of usinf what they develop.
      Never mind OS X is UNIX and POSIX Compliant.

      Comment


      • #78
        Originally posted by GreatEmerald View Post
        Nice, I'm glad to hear that the technical committee are making technical choices.
        http://www.debian.org/devel/constitution#item-6
        technical means, they should decide in technical question. Obviously they should find the solution what is the best for Debian Project, and not, which program is technically better

        Comment


        • #79
          Originally posted by GreatEmerald View Post
          Nice, I'm glad to hear that the technical committee are making technical choices.
          http://www.debian.org/devel/constitution#item-6

          technical means, they should decide in technical question. Obviously they should find the solution what is the best for Debian Project, and not, which program is technically better

          Originally posted by AdamW View Post
          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.
          GNOME requires logind for some reason, therefore they requires systemd as PID 1 well. systemd is the bug you mentioned.

          Comment


          • #80
            Originally posted by Siuoq View Post
            GNOME requires logind for some reason, therefore they requires systemd as PID 1 well. systemd is the bug you mentioned.
            OpenBSD runs Gnome 3.10 without using logind.
            https://www.bsdfrog.org/tmp/gnome310.webm

            In addition: https://wiki.gnome.org/ThreePointEle...emdUserSession
            Originally posted by Colin Walters
            It's important to note that with these patches, we still support non-systemd systems (as well as older systemd). How far into the future we do so is an open question, but it should not be too difficult to leave non-systemd systems with the previous model over the next few cycles.

            Comment


            • #81
              Originally posted by Siuoq View Post
              GNOME requires logind for some reason, therefore they requires systemd as PID 1 well. systemd is the bug you mentioned.
              You can rip out the logind requirement, the developers specifically not (see the other user's post like 1 or 2 above me). MORE specifically though... Gnome doesn't actually require -LOGIND- what it requires are the dbus interfaces that currently only logind provides. But if someone wanted to start their own login project that provided those same interfaces then Gnome could require logind OR $project_name OR neither of them for as long as the fallback code is maintained.

              Thats the beauty of it, you don't depend specifically upon logind, you depend upon the dbus interfaces it provides. Then if something else wants to provide them and do it in a non-breaking manner, then its just a drop-in replacement

              Comment


              • #82
                Originally posted by JX8p View Post
                Systemd as Debian's new init-system of choice has probably just been dealt its fatal blow as upstart is preliminarily working with kFreeBSD. Given the immature refusal of Poettering to even accept any patches allowing systemd to run on other platforms, which is vulgarly defiant of Debian's stated aims, one assumes they will be leaning towards upstart once more.
                Speaking as someone who's been following those discussions from the start - not likely. It's new that the BSD port of Upstart is working, but the fact that such a port existed has been known since the beginning, and it's had very little impact on discussions.

                Basically, all the committee are accepting of the idea that while the continued existence of the BSD and Hurd variants is important, it's of secondary importance to doing the right thing on Linux, even if that means having different default init systems on Linux and other. It's increasingly looking like their decision will be to go with Systemd on Linux, and Upstart on the other two...

                Comment


                • #83
                  Originally posted by mark45 View Post
                  systemd is killing upstart!
                  That is actually the plan, I guess, as Lennard&Co. used to work on upstart, however, they eventually realised that upstart contains unfixable fundamental design flaws.

                  Comment


                  • #84
                    Originally posted by Ericg View Post
                    You can rip out the logind requirement, the developers specifically not (see the other user's post like 1 or 2 above me). MORE specifically though... Gnome doesn't actually require -LOGIND- what it requires are the dbus interfaces that currently only logind provides.
                    With the note that forking is not entirely free. On Ubuntu a logind fork is used to provide an alternative. Such is also mentioned in the ctte discussions. However, the dbus API will receive new items as development goes on. Things we need/want for user sessions as well as tty switching (running Wayland/Xorg not as root).

                    During development you need something to be aligned with. Systemd maintainers you can work with. You know the roadmap, plans, objections, etc. So you can explain your needs and they'll work on it. For Upstart option, the answer basically is "we maintain the fork". So what'll happen in practice is that GNOME will continue to work with systemd developers. Then we have no other option than to assume that Upstart option duplicates whatever has been done within the systemd project.

                    Above sounds like a totally insane way to work IMO. Way easier for Debian to use systemd. Choosing Upstart means consciously choosing to be behind in the latest developments. And this is not due to forcing, it is due to the lack of cooperation and development in Upstart. Further, it is not really needed, loads of people (distributions, systemd developers, developers from other projects, low level stack developers) are already working together under the systemd name.

                    Comment


                    • #85
                      Originally posted by peppepz View Post
                      The subshell is just an example to show that even something as dumb as a bash shell can capture the standard error of a daemon and save it to a file. So saying that this is a "real problem that can only be solved by putting code in PID 1" is simply not true. Which does not mean that putting code in PID 1 is wrong. What is wrong is stating it as inevitable.
                      That's not the same functionality. If you redirect the output to a file, it will forever go to that file. So good luck with logrotate and so on. Obviously you could add yet another program inbetween to solve that. But at one point it is better to just see that the way to solve it is by handling this in the init system and all other solutions might work, but are just hacks/unreliable.

                      Comment


                      • #86
                        Originally posted by bkor View Post
                        That's not the same functionality. If you redirect the output to a file, it will forever go to that file. So good luck with logrotate and so on. Obviously you could add yet another program inbetween to solve that. But at one point it is better to just see that the way to solve it is by handling this in the init system and all other solutions might work, but are just hacks/unreliable.
                        using standard POSIX
                        http://stackoverflow.com/questions/5...-a-bash-script
                        dosen't seem unreliable to me
                        you see something that could break ?

                        i think maybe it could be done without cat

                        maybe "it is better to just see"
                        thinking hurts
                        Last edited by gens; 01-22-2014, 08:13 AM.

                        Comment


                        • #87
                          sry if i came on too hard in last post

                          just i don't see a big problem with using standard tools and kernel provided things

                          edit: i see a problem
                          cat can be killed with a couple char's in buffer
                          solution, dd if=/that/fifo of=/that/log bs=1
                          Last edited by gens; 01-22-2014, 08:48 AM.

                          Comment


                          • #88
                            Yes the first thing is you must learn actually what is the problem behind the reason the find solution or need to support from other.

                            Comment

                            Working...
                            X