Announcement

Collapse
No announcement yet.

A Run Down Of VT Switching On Linux

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

  • #16
    Originally posted by Rallos Zek View Post
    This sounds like a solution in search of a problem and users that actually care. On the other hand, it could break things horribly especially for those failsafe situations.

    it sounds like yet another example for of change for it's own sake not driven by any actual end user requirements that is actually being done DESPITE end user objections.

    It seems like a perfect microsoftism.
    What. Again, did you even read the posts in the article? Did you read my last post? What you're saying is pretty much the same as claiming that Wayland is a solution in search of a problem, because X.org happens to still somehow work. And yes, users do care about stability, security and opening multiple sessions on multiple seats.

    Comment


    • #17
      Lets not mess with the TTY's they are STILL NEEDED for when things go wrong.

      Start messing with the console, and you could end up, like Windows, with no basic, self-reliant recovery options.

      With systemd, upstart and company and all the other rubbish we are going towards a messy opaque system much like windows. I do not like this trend.

      This wannabe Lennart Poettering trying to make 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 possible.

      Comment


      • #18
        Originally posted by Rallos Zek View Post
        Lets not mess with the TTY's they are STILL NEEDED for when things go wrong.

        Start messing with the console, and you could end up, like Windows, with no basic, self-reliant recovery options.

        With systemd, upstart and company and all the other rubbish we are going towards a messy opaque system much like windows. I do not like this trend.

        This wannabe Lennart Poettering trying to make 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 possible.
        The console already depends upon working userspace... Invalid point is invalid. If your X Server freezes, you can't switch to a console. If the kernel isn't compiled with Sys-Rq AND its not actived in sysctl.conf, you can't even Sys-Rq out. If something is hogging the CPU to the point where almost nothing can happen... you might get to console, but the console can't call /bin/login. And even if /bin/login IS called and you get a login screen, you probably won't get /bin/{bash.sh,zsh,csh} running anyway.

        The very fact that you say "Messy opaque system much like windows" and "complexity in userspace" tells EVERYONE on these boards that you don't actually know what you're talking about and have only heard information from equally biased third parties, who probably selectively pulled out quotes to fit their own bias. Either you're trolling on purpose-- in which case you'll be reported, or you'll showing your ignorance for everyone to see and only embarrassing yourself. I its the latter I HIGHLY suggest you start reading code and documentation FOR YOURSELF and TALK to the developers YOURSELF and you'll realize how much of a mess we are in NOW and these "complexities" you call them are the result because we half-assed systems for so long, called them "good enough" and convinced ourselves they were "good enough" because the alternative was facing how much of a piss-poor position we were actually in.

        Comment


        • #19
          Originally posted by Rallos Zek View Post
          Lets not mess with the TTY's they are STILL NEEDED for when things go wrong.

          Start messing with the console, and you could end up, like Windows, with no basic, self-reliant recovery options.

          With systemd, upstart and company and all the other rubbish we are going towards a messy opaque system much like windows. I do not like this trend.

          This wannabe Lennart Poettering trying to make 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 possible.
          Yea, this shows that you didn't read a single one of the posts linked in the article. They explain that the current system is the cause of not being able to access self-reliant recovery options, and the new system introduces them. With the current system if your X server hangs where it doesn't release the resources, you can't switch out of it, because it is the only thing that has access to your input (and output) devices. The improvements in logind make it so that logind is capable of forcefully disconnecting the resources from such a hung X server and giving them to a newly spawned session.

          Comment


          • #20
            Originally posted by GreatEmerald View Post
            Did you read the posts linked to in the article? Because they explain all that. VTs are as old and as difficult to deal with as the X server due to them not being designed to do anything like what they're asked to do today. Getting rid of them gets rid of a very poor, extremely limited IPC layer. And the "needless daemon" is already running on most Linux distributions, including Ubuntu, and its design fits this purpose pretty much exactly.

            As for what it adds, it's enhanced stability and no more resource conflicts. As I said on the blog there, the current system is much like the Real Mode of CPUs, it's a horrible idea based on trust that all the software has no bugs and is written sanely. The new system is like Protected Mode, making sure that even if a program misbehaves/malfunctions, it won't be able to deadlock the whole PC. In addition, the new system does away with artificial limitations, which allows such things as multiple sessions on a single seat (currently that's only possible if there is only a single seat).

            Also, VTs have no reason to be in the kernel, because as the name implies, they're virtual. They're not actual devices. They ought to be created and deleted by the userland.
            Yes, I did read his blog posts. Did you read my post?

            VTs are as old and as difficult to deal with as the X server due to them not being designed to do anything like what they're asked to do today.
            Originally posted by curaga
            ...that extending VTs...
            And the "needless daemon" is already running on most Linux distributions, including Ubuntu, and its design fits this purpose pretty much exactly.
            No, it's not. If you read the blog posts, the work to make it do its job is just now being done. So why would any existing distro deploy it, when it doesn't do its job fully yet? It may be in the development Ubuntu version, but not in any released one.

            which allows such things as multiple sessions on a single seat (currently that's only possible if there is only a single seat).
            Originally posted by curaga
            ...that extending VTs and input handling in kernel...
            Also, VTs have no reason to be in the kernel, because as the name implies, they're virtual. They're not actual devices. They ought to be created and deleted by the userland.
            They have every reason to be in the kernel, which is why they are. The kernel manages the display, the kernel manages the input. It manages the processes that run on that VT. Now, can you make an argument, when given all that, that the combination of those three should also not be in the same place?

            Comment


            • #21
              Originally posted by Ericg View Post
              If your X Server freezes, you can't switch to a console.
              That is a completely valid point, but how can you be so ignorant to think the solution in logind to that, forcing it with a timeout, could not also be implemented in kernel?

              Comment


              • #22
                Originally posted by curaga View Post
                They have every reason to be in the kernel, which is why they are. The kernel manages the display, the kernel manages the input. It manages the processes that run on that VT. Now, can you make an argument, when given all that, that the combination of those three should also not be in the same place?
                Your argument makes it sound like X should be in the kernel.

                Comment


                • #23
                  Originally posted by curaga View Post
                  Yes, I did read his blog posts. Did you read my post?
                  By that logic, the fix to all the problems in the X server is to extend the X server. Which it isn't, due to legacy reasons. The actual fix is to throw it all out the window and start fresh.

                  Originally posted by curaga View Post
                  No, it's not. If you read the blog posts, the work to make it do its job is just now being done. So why would any existing distro deploy it, when it doesn't do its job fully yet? It may be in the development Ubuntu version, but not in any released one.
                  It will be included in a later version of logind, but logind itself is already used in a lot of distributions. So they'll get this functionality after updating it.

                  Originally posted by curaga View Post
                  They have every reason to be in the kernel, which is why they are. The kernel manages the display, the kernel manages the input. It manages the processes that run on that VT. Now, can you make an argument, when given all that, that the combination of those three should also not be in the same place?
                  No. The kernel manages the display drivers and the input drivers, and then provides access to them to the userland. It shouldn't manage any processes, it's not the job of the kernel. It's the job of logind or other init daemons.

                  Comment


                  • #24
                    Originally posted by GreatEmerald View Post
                    By that logic, the fix to all the problems in the X server is to extend the X server. Which it isn't, due to legacy reasons. The actual fix is to throw it all out the window and start fresh.
                    Well, I continue to think that throwing away one of the X platform's biggest advantages, networking for all apps, is a huge mistake. But there's quite a difference in scale here, the X codebase may be 1000 times that of the VT codebase, which means different solutions would work for them.

                    @erendorn: Also the difference in scale.

                    Making VTs multi-seat aware, and adding revoke() or alternatives, is a much saner choice than yet another daemon.

                    No. The kernel manages the display drivers and the input drivers, and then provides access to them to the userland. It shouldn't manage any processes, it's not the job of the kernel. It's the job of logind or other init daemons.
                    That's systemd think, init should have nothing to do with that (of course depending on the definition of "manage" - starting and stopping them is quite different from what systemd does).

                    Comment


                    • #25
                      Originally posted by curaga View Post
                      Well, I continue to think that throwing away one of the X platform's biggest advantages, networking for all apps, is a huge mistake. But there's quite a difference in scale here, the X codebase may be 1000 times that of the VT codebase, which means different solutions would work for them.
                      Direct rendering on X is somehow more network-transparent than direct rendering on Wayland? How so?

                      Comment


                      • #26
                        Originally posted by dee. View Post
                        Direct rendering on X is somehow more network-transparent than direct rendering on Wayland? How so?
                        Direct rendering by definition is not, but indirect rendering is. However I mainly meant 2d apps, as for 3d it usually is more bandwidth-efficient to send the image; for 2d text is much more efficient than image.

                        Comment


                        • #27
                          Originally posted by curaga View Post
                          ...than yet another daemon
                          It's already used to handle user logins, device access and seats on every distribution that uses systemd and Ubuntu 13.10+. This just extends it, systemd-logind itself replaces ConsoleKit so it's not "yet another daemon".

                          Comment


                          • #28
                            Originally posted by Ericg View Post
                            Fair enough, it will probably be hidden by a config switch for many years. HOPEFULLY it will eventually be removed after its fairly certain that its no longer used.
                            How would a removal of this code (or its move to userspace) affect single purpose or embedded systems that don't use/have no need for session management, multi-seat or VT switching, for example if they directly boot into a shell script or other applications. That is something I use often and the inability to do that would make Linux more or less unusable for my purposes.

                            Comment


                            • #29
                              Originally posted by Vim_User View Post
                              How would a removal of this code (or its move to userspace) affect single purpose or embedded systems that don't use/have no need for session management, multi-seat or VT switching, for example if they directly boot into a shell script or other applications. That is something I use often and the inability to do that would make Linux more or less unusable for my purposes.
                              If you don't want session-switching then you don't need VTs. Especially if you have no monitor attached.. People often confuse VTs and TTYs. Without VTs you can still use whatever TTY you want, just not on a virtual console.

                              Comment


                              • #30
                                Originally posted by dvdhrm View Post
                                If you don't want session-switching then you don't need VTs. Especially if you have no monitor attached.. People often confuse VTs and TTYs. Without VTs you can still use whatever TTY you want, just not on a virtual console.
                                Just to clarify that that, it would still be possible to run a bare Bash script (no init or getty used) on console with output to a monitor and keyboard input?

                                Comment

                                Working...
                                X