Announcement

Collapse
No announcement yet.

A Run Down Of VT Switching On Linux

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

  • Originally posted by curaga View Post
    Every additional layer by the very definition increases complexity.
    That's certainly not the definition of a layer, especially if it is not about adding a layer, but replacing a big one by several smaller ones.

    And no, separating problems cleanly does not necessarily make the whole more complicated (at least according to widespread design practices).

    Comment


    • Originally posted by GreatEmerald View Post
      Aha, so you are using an init after all.
      No, I don't. The init= parameter tells the kernel which process to run as PID 1, nothing more, nothing less. In this case it is Bash, there is no init system at all in use.

      Comment


      • Originally posted by Vim_User View Post
        No, I don't. The init= parameter tells the kernel which process to run as PID 1, nothing more, nothing less. In this case it is Bash, there is no init system at all in use.
        I'm not talking about an init system, I'm talking about the init process (PID 1). Like I said, there is no difference between having Bash as PID 1 and having a dispatcher, that spawns a terminal with bash, as PID 1.

        Comment


        • Originally posted by GreatEmerald View Post
          I'm not talking about an init system, I'm talking about the init process (PID 1). Like I said, there is no difference between having Bash as PID 1 and having a dispatcher, that spawns a terminal with bash, as PID 1.
          Yes there is, added maintenance for dispatcher and terminal. Like I said before, the number of independent software modules to maintain doubles with this approach.

          Comment


          • Originally posted by erendorn View Post
            That's certainly not the definition of a layer, especially if it is not about adding a layer, but replacing a big one by several smaller ones.

            And no, separating problems cleanly does not necessarily make the whole more complicated (at least according to widespread design practices).
            I may have gotten confused; if we're still talking about the input handling of logind, it's quite certainly an additional layer. It doesn't replace anything, it still uses the kernel's input devices underneath; but it also multiplexes them to its own virtual devices (the additional layer).

            This is not separating problems cleanly to me.

            Comment


            • Originally posted by Vim_User View Post
              Yes there is, added maintenance for dispatcher and terminal. Like I said before, the number of independent software modules to maintain doubles with this approach.
              Right now that maintenance is on the kernel developers. Moving it outside of the kernel means less maintenance for them, and more maintenance for the userland maintainers. The sum of maintenance stays exactly the same.

              Originally posted by curaga View Post
              I may have gotten confused; if we're still talking about the input handling of logind, it's quite certainly an additional layer. It doesn't replace anything, it still uses the kernel's input devices underneath; but it also multiplexes them to its own virtual devices (the additional layer).

              This is not separating problems cleanly to me.
              It's a safeguard against programs hogging resources, including input. There is no cleaner way of doing that, and the overhead is minimal, logind should just relay the input further if it doesn't include a preset keystroke.

              Comment


              • Originally posted by GreatEmerald View Post
                Right now that maintenance is on the kernel developers. Moving it outside of the kernel means less maintenance for them, and more maintenance for the userland maintainers. The sum of maintenance stays exactly the same.
                You're disregarding the system creator's maintenance as free - it is not. The kernel is a single package to maintain, if a daemon was needed additionally, it would be more total maintenance, as each system creator would need to make sure the versions are compatible, and that the daemon and kernel work together.

                It's a safeguard against programs hogging resources, including input. There is no cleaner way of doing that, and the overhead is minimal, logind should just relay the input further if it doesn't include a preset keystroke.
                I already presented the alternative, revoke(), which does not require an additional layer like that. What is unclean in it?

                Comment


                • Originally posted by GreatEmerald View Post
                  Right now that maintenance is on the kernel developers. Moving it outside of the kernel means less maintenance for them, and more maintenance for the userland maintainers. The sum of maintenance stays exactly the same.
                  No, it does not. Now you have exactly one point where this software has to be maintained, the kernel. If you split that software out you multiply the burden of maintenance, because now every developer of projects using this software stack has to do the maintenance. Assume that only 100 projects use the kernel in this way you still have 100 times more maintenance.

                  Comment


                  • Making the console depend on layers of complexity in user space, yeah that'll all be there when things go south.... the console is there for emergencies, needs to depend on as little as possibile, This could be an essential part of GNOME 3!

                    Comment

                    Working...
                    X