Announcement

Collapse
No announcement yet.

Voting Proposed For Debian Jessie's Init System

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

  • #51
    Originally posted by gens View Post
    maybe you can explain to me
    what the f* does user space desktop/user/seat/monitoring/thing have to do with how the system loads modules and starts system daemons

    and don't we already have user groups, SUID and the likes to regulate user permissions, regardless of what's underneath

    i'm no admin but mine so console-kit and the likes confuse me
    don't we already have all that in the kernel/filesystem ?
    Since you admit you do not understand the technical issues, maybe give some credit to members of the Debian technical committee who do and have looked into the details?

    Comment


    • #52
      Originally posted by You- View Post
      Since you admit you do not understand the technical issues, maybe give some credit to members of the Debian technical committee who do and have looked into the details?
      maybe i want to understand more then i do already
      am i wrong to think execution permissions are already handled by the filesystem ?
      as those kind of things i read modern services solve

      "its too complicated" has been stated many times before, and does not deter me from trying to understand more (and why)

      Comment


      • #53
        Originally posted by gens View Post
        maybe you can explain to me
        what the f* does user space desktop/user/seat/monitoring/thing have to do with how the system loads modules and starts system daemons
        Why are you limiting yourself to system daemons? A user session has processes in need of management too. At least when you use a beast such as Gnome or KDE. There's a shell script to start KDE named, wait for it, startkde. But systemd --user is much better at doing the things startkde does. Right now we have a hodgepodge of things started by the init system, of things started by homegrown solutions such as startkde, and of things started by dbus-daemon. All of these work disjoint from each other. systemd aims to replace that hodgepodge with a unified way to start and monitor processes. All processes.

        Originally posted by gens View Post
        and don't we already have user groups, SUID and the likes to regulate user permissions, regardless of what's underneath
        logind and polkit are far more granular than what groups and SUID provide. An example would be "a user can shutdown/reboot the machine from a local session, but only if he's the only user logged in". Or "a user can plug in and mount portable storage devices, but is not allowed to un/mount persistent storage devices". Not really doable with just groups and SUID helper binaries. You need something that tracks sessions (logind or consolekit, but the latter is unmaintained) and something that understands more fine-grained permissions (polkit).

        Comment


        • #54
          Originally posted by Gusar View Post
          Why are you limiting yourself to system daemons? A user session has processes in need of management too. At least when you use a beast such as Gnome or KDE. There's a shell script to start KDE named, wait for it, startkde. But systemd --user is much better at doing the things startkde does. Right now we have a hodgepodge of things started by the init system, of things started by homegrown solutions such as startkde, and of things started by dbus-daemon. All of these work disjoint from each other. systemd aims to replace that hodgepodge with a unified way to start and monitor processes. All processes.

          logind and polkit are far more granular than what groups and SUID provide. An example would be "a user can shutdown/reboot the machine from a local session, but only if he's the only user logged in". Or "a user can plug in and mount portable storage devices, but is not allowed to un/mount persistent storage devices". Not really doable with just groups and SUID helper binaries. You need something that tracks sessions (logind or consolekit, but the latter is unmaintained) and something that understands more fine-grained permissions (polkit).
          ty

          i have actually read about sessions and seats at the freedesktop page about it

          so its just a locking mechanism ?

          hypothetically that is simple by having a .lock file or a dbus service that acts as a lock

          i seen console-kit start a thread every time a new user appears (like opening a shell for a generic example)
          why isn't it that it just sends something like "USER has logged in, use this PID as to tell if hes still there" and on example shutdown just go thru the PID's
          file backed on /tmp or some virtual file system that would require 0 running processes and few bytes RAM
          or is that flawed ?
          Last edited by gens; 26 January 2014, 03:12 PM.

          Comment


          • #55
            Debian voting system

            Anybody familiar enough with the complex Debian voting system to say whether tactical voting and collusion may change the outcome?

            I am thinking of the scenario where systemd is ranked first and Upstart second by four pro-systemd members, but four pro-Upstart members votes Upstart first and systemd fifth. Could that change the "tie" to a "win" for the Upstart members?

            Is the chairman's casting vote usable as second vote in the initial voting, or is it only used if the final outcome is a tie?

            There is a lot of info here, but I don't understand "Condorcet" voting with "Schwartz Sequential Dropping" enough to answer my own questions.
            http://www.seehuhn.de/pages/vote
            http://www.debian.org/devel/constitution.en.html#item-6

            Comment


            • #56
              Originally posted by blackout23 View Post
              There seems to be a high correlation between the persons favor of upstart and his affiliation with Canonical. Interesting. Correlation does not imply causation, though. Probably just a coincidence.
              "What do we say about coincidence, dear brother?"
              "The universe is rarely so lazy."
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #57

                Comment


                • #58
                  Originally posted by nll_a
                  I think Debian will go with the crowd and adopt SystemD anyway. But whatever, let's just move on once and for all.
                  dosen't matter at all for most all end users so...
                  there will still be an option for any of the other init like systems anyway
                  it is debian after all

                  Comment


                  • #59
                    Originally posted by Anarchy View Post
                    Upstart was released August, 2006.

                    Systemd was released march, 2010.

                    Canonical did and still is doing the right thing. Upstart is production ready, has been for many years and has been tested on a number of projects. Scraping their efforts for the sake of changing things makes no sense.
                    No.

                    Systemd started by revising whats wrong with SysV and Upstart. Systemd is the next evolution step. So the best thing would be to drop Upstart and start working on systemd, then on the next system.

                    The architectural mistakes are corrected in this way. It is normal.

                    Originally posted by Anarchy View Post
                    Bzr at the time was interesting project that is still used by Canonical for the internal projects and for keeping track of ubuntu through launchpad. Moving to git will be a major endeavor that will eat up huge engineering time and will not make anything better.

                    Honestly, I don't even know why you're mentioning git and bzr. They're versioning systems, which are one of the most boring parts of a programming project. Both tools do their job appropriately and are production ready.
                    Wrong again. I mention it due to [these reasons]. The correct way is to drop bazaar and start working in and on git, and on what comes after git.

                    Originally posted by Anarchy View Post
                    P.S. for debian it makes sense to go upstart. The project is healty ans stable. And debian nowafays plays the role of a staging ground for ubuntu, which has moved to upstart since many years ago.
                    Everyone except Ubuntu have moved to systemd and git for very well known reasons. Instead to follow the already deprecating, Debian should pick what is stable (and systemd is stable). Also claiming Debian plays role of staging ground for Ubuntu is like claiming Ubuntu plays as staging ground for Linux Mint. It is nonsense - just because someone takes the GPLed work, it does not mean it plays as a staging ground. But if Debian starts adopting Ubuntu-only outdated technologies, then it will become one, no questions.
                    Also Debian != Ubuntu. Collaboration applies to Debian in form of software, where for Ubuntu it boils down to just marketing.

                    Comment


                    • #60
                      Originally posted by brosis View Post
                      Systemd started by revising whats wrong with SysV and Upstart. Systemd is the next evolution step. So the best thing would be to drop Upstart and start working on systemd, then on the next system.

                      Everyone except Ubuntu have moved to systemd and git for very well known reasons.
                      yes, evolution has shown itself to be amazing
                      from cave men through burning people all the way to forum trolls
                      and sharks still eat people

                      and on the 2'nd part:
                      what ?
                      check distrowatch again
                      not even RHEL

                      Comment

                      Working...
                      X