FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-29-2008, 04:33 PM
Dax Kelson
 
Default Reasons to preseve X on tty7

On Wed, 2008-10-29 at 08:26 -0400, Brian Wheeler wrote:
> I'm going to agree with the -1.
>
> Almost all of the "reasons" from the original email boil down to "we've
> always done it this way".

Absolute not! I gave 9 distinct, independent reasons. Only one of which
was regarding tradition.

Listen, it's easy to win arguments if you rephrase/restate all the
opposing arguments into one straw man.

Dax Kelson
Guru Labs

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-29-2008, 04:41 PM
Dax Kelson
 
Default Reasons to preseve X on tty7

On Wed, 2008-10-29 at 08:32 -0800, Jeff Spaleta wrote:
> On Wed, Oct 29, 2008 at 8:11 AM, Matthew Woehlke
> > it don't appear to care about the objections; they're not responding
> > intelligently to them,
>
> I don't have an intelligent response to any argument which essentially
> comes down to "tradition." Have the traditionalists pulled put forth
> any consensus document like an RFC to support that at some point in
> time a group of people actually talk through the need for doing gettys
> a certain way?
>
> Traditions which codify a collection of arbitrary decisions..are
> traditions I will gladly help throw into the fire.

Jef,

Not you too. My arguments are NOT "essentially" tradition. One of my 9
distinct arguments was Fedora becomes inconsistent with itself.

Another was that Fedora becomes incompatible with other Linux
distributions. Do we really want to go down the path where we have to
have "Fedora experts", "SUSE experts, "Ubuntu experts", etc and there is
no such thing as a "Linux expert"? That were the path of frivolous
incompatibilities leads.

The shepherds of the the various Linux distros should keep this in mind.
Their own distribution doesn't exist in a vacuum. If if they don't
use/work on other distributions, their users do.

Dax Kelson
Guru Labs

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-29-2008, 04:42 PM
"Colin Walters"
 
Default Reasons to preseve X on tty7

On Wed, Oct 29, 2008 at 1:20 PM, Dax Kelson <dkelson@gurulabs.com> wrote:
>
> Most (all?) of the technologies you mentioned are cross-distribution.
> Everybody switched, compatibility across distributions was maintained.

Right, because it was driven by the desktop, which besides the kernel
is the only point of technology sharing between vendors that we have.
Everything in between distributions tend to reinvent in their own
little sandbox, which is a tendency we have to fight strongly.

If you like, we can make GDM depend on plymouth =)

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-29-2008, 04:47 PM
"Jeff Spaleta"
 
Default Reasons to preseve X on tty7

On Wed, Oct 29, 2008 at 9:20 AM, Dax Kelson <dkelson@gurulabs.com> wrote:
> Most (all?) of the technologies you mentioned are cross-distribution.

Believe what you want. Different distros pick up different technology
changes at different times. They do not all move as a block.
PolicyKit and its authorization concepts being a current area where we
lead the integration and we are breaking established traditional
practises to get to something better. PolicyKit still blows my mind I
haven't really figure out how to work with it as an admin. I'm still
getting comfortable with how to script interaction with HAL and DBUS
to deal with removable devices as an admin and not a user. Far more
disruptive and more important than dickering over what vt anything
defaults to appearing on.

the cross distro tty behavior issue with regard to tty initialization
is a FANTASY. Its is concensus by inaction and a lack of discussion.
People took an arbitrary inittab example and have propagated
it..mindlessly. No attempt at cross-distribution standardization
addresses this as an expectation on behavior.

jef"At some point...all phones were rotary dial..until someone made a
push button phone. Dear god, my fingers have to move in a completely
different pattern to do get exactly the same work done.....that's
incompatible...think of the children....down with push button
phones!"spaleta

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-29-2008, 04:50 PM
"Jeff Spaleta"
 
Default Reasons to preseve X on tty7

On Wed, Oct 29, 2008 at 9:21 AM, Ralf Corsepius <rc040203@freenet.de> wrote:
> You will likely comprehend the absurdity of this proposal when X server
> races the next time.

As a user...wtf do I know about a race condition?

As a tester...im going to turn on a going to turn on gettys no matter
what the defaults are.
where the getty is..is arbitrary...for my needs to interact with it.

As an admin....serial consoles are great.

-jef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-29-2008, 04:52 PM
Chris Adams
 
Default Reasons to preseve X on tty7

Once upon a time, Alan Cox <alan@redhat.com> said:
> Because it was the number of getty tasks someone had in the example inittab
> for SysVInit I suspect. It is useful to have a couple even for debug hiding
> where you can direct a user but the number is arbitary and the fact X happens
> to be VT7 is just a further arbitary fallout from this.

I think 6 gettys goes back before SysVInit, maybe to SLS.

I used to boot in level 3, log in on tty1, and run startx to get X, but
I stopped doing that years ago. However, from that time, on the rare
occasions I need a text console while in X, I switch to tty2, not tty1.
On my servers with serial consoles, I typically disable most of the
console gettys anyway.

Didn't somebody have an on-demand console daemon for Linux at some
point? You'd just run it, and when someone switched to a new VT where
nothing was running, it would start a getty. I always thought that
would be much better than an arbitrary 6.

I don't see this as a big deal. I've been using X since before Linux
existed, and I just see non-X ttys (on a system running X) as an extra
thing (none of the other systems I've used X on support that; the
console is either text or X, not both).

The argument appears to be coming from a (very!) vocal minority (what
percentage of Fedora users are on this list, and what percentage of list
members are objecting?). The vast majority of users have no idea or
care about VT switching in my experience and will not care that X
switched from one tty to another (if you tried to explain it to them,
you'd just get blank stares). If it speeds up the boot process and
causes less flicker and monitor reset (which does disconcert regular
users), they'll be happy.

As for the argument that speeding up boot and making the boot smoother
is meaningless because you should never need to reboot, there are still
a lot of users that have to dual-boot. Speeding up boot (and shutdown!)
is a good thing for them.

A better solution to this issue of "where is my X or text tty" would be
to allow console managers to register for a different set of keystrokes;
e.g. gettys could register for [CTRL-]ALT-F<1,2,...> and X for
[CTRL-]ALT-<1,2,...> (or something like that). The first getty to
register would get F1 and the first X to register would get 1.

--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-29-2008, 05:06 PM
Dax Kelson
 
Default Reasons to preseve X on tty7

On Wed, 2008-10-29 at 09:47 -0800, Jeff Spaleta wrote:
> On Wed, Oct 29, 2008 at 9:20 AM, Dax Kelson <dkelson@gurulabs.com> wrote:
> > Most (all?) of the technologies you mentioned are cross-distribution.

>
> the cross distro tty behavior issue with regard to tty initialization
> is a FANTASY. Its is concensus by inaction and a lack of discussion.
> People took an arbitrary inittab example and have propagated
> it..mindlessly. No attempt at cross-distribution standardization
> addresses this as an expectation on behavior.

How the behavior arrived is, for the most part, irrelevant. We have what
we have. Don't break it NEEDLESSLY.

Dax Kelson
Guru Labs

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-29-2008, 05:09 PM
Dax Kelson
 
Default Reasons to preseve X on tty7

On Wed, 2008-10-29 at 12:52 -0500, Chris Adams wrote:

> The argument appears to be coming from a (very!) vocal minority (what
> percentage of Fedora users are on this list, and what percentage of list
> members are objecting?). The vast majority of users have no idea or
> care about VT switching in my experience and will not care that X
> switched from one tty to another (if you tried to explain it to them,
> you'd just get blank stares). If it speeds up the boot process and
> causes less flicker and monitor reset (which does disconcert regular
> users), they'll be happy.
>
> As for the argument that speeding up boot and making the boot smoother
> is meaningless because you should never need to reboot, there are still
> a lot of users that have to dual-boot. Speeding up boot (and shutdown!)
> is a good thing for them.

Chris,

The problem is that we can have both. Let's all eat cake! This change of
X's VT is un-needed.

Dax Kelson
Guru Labs

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-29-2008, 05:13 PM
Brian Wheeler
 
Default Reasons to preseve X on tty7

On Wed, 2008-10-29 at 11:33 -0600, Dax Kelson wrote:
> On Wed, 2008-10-29 at 08:26 -0400, Brian Wheeler wrote:
> > I'm going to agree with the -1.
> >
> > Almost all of the "reasons" from the original email boil down to "we've
> > always done it this way".
>
> Absolute not! I gave 9 distinct, independent reasons. Only one of which
> was regarding tradition.
>
> Listen, it's easy to win arguments if you rephrase/restate all the
> opposing arguments into one straw man.
>

Ok, lets go through them.

Your first one is the tradition argument.

So is the second one ("developers should tread respectfully in such
hallowed places")

The third one is documentation. That's a fair argument, but its not
insurmountable. I can't think of any of the linux books/faqs/etc I've
used over the last 15 years that haven't become out of date at least
partially...and usually fairly quickly.

The fourth is "no other distros are doing this" is kind of a tradition
argument, but its also a compatibility issue. There are all kinds of
differences between the distros, so I'm not sure how this advances your
argument that it shouldn't change.

Fifth argument is just documentation (again) combined with the one
above.

The 6th argument is dealing with a non-standard startup. When you don't
use the defaults, all bets are off.

The 7th is "nobody should care what tty X is on". Indeed, why are
people so upset that it has changed? Its not an argument for or
against, its an argument that this thread shouldn't be taking place at
all.

Eighth is tradition again. "experienced users will try..."

Ninth is fast user switching. Interesting side effect, but with
"argument 7" its moot. Who cares if the 2nd user display is on tty7?

Tenth is "switching to vt7 causes no flicker". Switching VTs takes
time, even if the flicker is not present. Its not an argument, so much
as its a workaround. Its a workaround with a (time) cost.


So, it boils down to tradition, documentation, and compatibility with
other distros.

Tradition is important, but I'd vote that a faster, flicker-free startup
trumps it.

Documentation is also important, but it is just documentation. The move
from SysV Init is far more in-depth than the X vt thingy.

Compatibility isn't a driving priority, especially for something that's
low-level and used primarily by those who've been around for a long
time...


*shrug*

I don't really get why there's so much anger about this change. I
booted the rawhide and was very impressed by the speed of the startup
(as well as lack of flicker/monitor resync time). It seems like a
reasonable trade off.

Brian





--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-29-2008, 05:16 PM
Les Mikesell
 
Default Reasons to preseve X on tty7

Chris Adams wrote:


The vast majority of users have no idea or
care about VT switching in my experience and will not care that X
switched from one tty to another (if you tried to explain it to them,
you'd just get blank stares).


The reason those people don't need to care about vt's is that they'll go
to whoever recommended linux to them in the first place if they have a
problem with X. And those are the people who care about consistency.



If it speeds up the boot process and
causes less flicker and monitor reset (which does disconcert regular
users), they'll be happy.


But it doesn't - the flicker is caused by switching modes at the wrong time.


As for the argument that speeding up boot and making the boot smoother
is meaningless because you should never need to reboot, there are still
a lot of users that have to dual-boot. Speeding up boot (and shutdown!)
is a good thing for them.


And they'd probably be better off with VMware instead, running
whichever OS handles sleeping better as the host.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 07:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org