Page 11 of 11 FirstFirst ... 91011
Results 101 to 109 of 109

Thread: A Run Down Of VT Switching On Linux

  1. #101
    Join Date
    Sep 2012
    Posts
    780

    Default

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

  2. #102
    Join Date
    Jan 2013
    Posts
    1,116

    Default

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

  3. #103
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,636

    Default

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

  4. #104
    Join Date
    Jan 2013
    Posts
    1,116

    Default

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

  5. #105
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,283

    Default

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

  6. #106
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,636

    Default

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

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

  7. #107
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,283

    Default

    Quote 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?

  8. #108
    Join Date
    Jan 2013
    Posts
    1,116

    Default

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

  9. #109
    Join Date
    Sep 2011
    Posts
    167

    Default

    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!

Posting Permissions

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