On Mon, 16 Nov 2009 11:07:52 +0100 Josselin Mouette <joss@debian.org> wrote: > Le lundi 16 novembre 2009 à 10:33 +0100, Harald Braumann a écrit : > > I don't see any real arguments against the set-up as it is now or > > for a new way to do it. > > There are no real arguments for keeping the current setup either. Yes there is: that it has been like this forever. This is a value of its own, because users expect it to be like this and rely on it. Changing it will confuse many. It doesn't mean that it is carved in stone, but there should be good reasons and the gain should outweigh the cost. > > > Just because GDM is broken doesn't mean we should > > change a system that is, in your own words, a long-standing > > tradition. > > Just because it is a tradition doesn’t mean it’s the correct way. So far I haven't seen any argument as to why it shouldn't be the correct way. > Actually, several people in this thread felt the current way is > better, while explaining they don’t have *enough* text VTs for their > personal use in the default setup. > > Let me sum up the situation otherwise: > * Current situation is far from perfect. Why? > * New GDM upstream, as is, is completely broken. That seems to be the only reason. But this is clearly a bug in GDM, that should be fixed there. > Let me explain what proposal I have in mind after reading the thread, > now. It might sound a little crazy but I think it would be much better > than just keeping our current setup. > > We remove entirely the getty respawning from /etc/inittab. Instead, a > new daemon is started by a regular init script. This daemon does the > following: > * Opens all /dev/tty1 to tty6 and display a d-i-like “press > enter to activate this console” in them. > * Provide a very simple interface to reserve a VT, that can be > queried by the display manager. > * Whenever you press enter on a VT, reserve it and start a getty > process. > * When almost all ttys are allocated, start opening tty7+ and so > on. > * If no display manager is started, always run a getty process > in tty1. To me, this seems like a solution looking for a problem. What use-case do you have in mind here? On my system it currently works like this: - start gettys in /etc/inittab - define X's tty in /etc/X11/xdm/Xservers If you want X on another tty, change it in /etc/X11/xdm/Xservers. If you need more ttys, add gettys to /etc/inittab. This system is so simple and flexible, that I don't see how you can improve on it. So the solution is to make GDM configurable by a parameter or a config file to set the vt it should start on. > I don’t see this as rocket science software, and it means: > * No useless getty processes are started. I never considered this to be a real problem. > * tty1 is always the first VT you log on, regardless of your > setup. I don't see this as an improvement. I always want X on the same tty, no matter in which order I do things. Or did I misunderstand something here? > * You can start an arbitrary number of text or graphical > consoles, without any configuration. Is this really a requirement? Where are the wishlist bugs of users demanding this? And anyway, a simple script that looks for the next free tty and spawns getty there solves this nice and easy. Cheers, harry
Attachment:
signature.asc
Description: PGP signature