The new X-Kernel !

The new X-Kernel !

[MichaelM]

People need a nice stable Operating System for networking purposes of any
type, and this exists, linux of course. What else should the world need?

People need a nice stable Operating System for Desktop and Multimedia
purposes and this doesn't exist. We should create a new stable X-Kernel with
build in support for X. Pressing Alt-F1 a console should pop up.

Boots up with X, that means.

Come on Linus, show the world what you can do, release the X-Kernel 1.01.

Hit the MS dominar where it hurts, THE DESKTOP.

Parallel release of Kernel and X-Kernel, will put Linux where it belongs,
THE TOP of course.

Re: The new X-Kernel !

[Mike Fedyk]

On Sat, Oct 20, 2001 at 10:30:00PM +0100, MichaelM wrote:
> People need a nice stable Operating System for networking purposes of any
> type, and this exists, Linux of course. What else should the world need?
> 
> People need a nice stable Operating System for Desktop and Multimedia
> purposes and this doesn't exist. We should create a new stable X-Kernel with
> build in support for X. Pressing Alt-F1 a console should pop up.
> 
> Boots up with X, that means.
>

We already have this.  It's called xdm, kdm, or gdm.

> Come on Linus, show the world what you can do, release the X-Kernel 1.01.
> 
> Hit the MS dominar where it hurts, THE DESKTOP.
> 
> Parallel release of Kernel and X-Kernel, will put Linux where it belongs,
> THE TOP of course.
> 

Starting X sooner or later in the boot process won't make Linux any better
or worse than the competition.

What you are asking for is a distribution feature request, not a kernel
feature request.

You can get X to startup sooner by modifying your init scripts.  Just start
?dm after networking, and any other services that X will depend on.  Now you
can have any other services such as nfsd, samba, http, etc in parallel to X.

Mike

Re: The new X-Kernel !

[Aaron Lehmann]

On Sat, Oct 20, 2001 at 10:30:00PM +0100, MichaelM wrote:
> Come on Linus, show the world what you can do, release the X-Kernel 1.01.
> 
> Hit the MS dominar where it hurts, THE DESKTOP.

 +--------------------+
 |      Please,       |
 |    don't feed      |
 |       the          |
 |     trolls.        |
 +--------------------+
           ||
           ||
           ||
           \/

With appologies to Rik.

Re: The new X-Kernel !

[Gábor Lénárt]

On Sat, Oct 20, 2001 at 10:30:00PM +0100, MichaelM wrote:
> People need a nice stable Operating System for networking purposes of any
> type, and this exists, linux of course. What else should the world need?
> 
> People need a nice stable Operating System for Desktop and Multimedia
> purposes and this doesn't exist. We should create a new stable X-Kernel with
> build in support for X. Pressing Alt-F1 a console should pop up.
> 
> Boots up with X, that means.
> 
> Come on Linus, show the world what you can do, release the X-Kernel 1.01.
> 
> Hit the MS dominar where it hurts, THE DESKTOP.

I've never understood why people want X, StarOffice (OpenOffice) etc to be
moved into kernel space :) IMHO it's strictly user space issue. You can
start X or gdm/xdm/kdm from a boot script and so on. No kernel modification
is needed for this.

- Gabor

Re: The new X-Kernel !

[Jonathan Morton]

>  > Boots up with X, that means.
>
>I've never understood why people want X, StarOffice (OpenOffice) etc to be
>moved into kernel space :) IMHO it's strictly user space issue. You can
>start X or gdm/xdm/kdm from a boot script and so on. No kernel modification
>is needed for this.

Probably because they don't know the difference between kernel and 
user space.  Kinda understandable when you come from a Mac or Windows 
background, where (in the former) there is no distinction or (in the 
latter) it's so blurred as to make little difference.

And if they *do* understand it, from a dispassionate point of view, 
it does seem to make sense to put graphics drivers in the kernel - 
they're implemented as "device drivers" in every other desktop OS. 
Except MacOS X, where's it's an application layer like glibc, but 
nobody understand OS X yet beyond the hardest of developers.

But they don't realise that XFree86 has an *enormous* amount of 
developer time behind it, which would need to be duplicated to make 
it work in kernel space with full backwards compatibility.  Oh, and 
did I mention this would all be for one platform - XFree86 is 
designed to run on many!  It would also bloat the kernel tremendously.

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

Re: The new X-Kernel !

[Gábor Lénárt]

On Sun, Oct 21, 2001 at 09:33:34AM +0100, Jonathan Morton wrote:
> > > Boots up with X, that means.
> >
> >I've never understood why people want X, StarOffice (OpenOffice) etc to be
> >moved into kernel space :) IMHO it's strictly user space issue. You can
> >start X or gdm/xdm/kdm from a boot script and so on. No kernel modification
> >is needed for this.
> 
> Probably because they don't know the difference between kernel and 
> user space.  Kinda understandable when you come from a Mac or Windows 
> background, where (in the former) there is no distinction or (in the 
> latter) it's so blurred as to make little difference.

Hmmm, I don't know Windows very well but AFAIK it's something microkernel
architecture (well this makes me laughing always though :), HAL, and so on.
But even the GUI of windows can be changed but it's more hard to implement.

> And if they *do* understand it, from a dispassionate point of view, 
> it does seem to make sense to put graphics drivers in the kernel - 
> they're implemented as "device drivers" in every other desktop OS. 
> Except MacOS X, where's it's an application layer like glibc, but 
> nobody understand OS X yet beyond the hardest of developers.

:) It would be interesting to learn more on it (if infomartion is available).
afaik it's a unix like system in its core.
 
> But they don't realise that XFree86 has an *enormous* amount of 
> developer time behind it, which would need to be duplicated to make 
> it work in kernel space with full backwards compatibility.  Oh, and 
> did I mention this would all be for one platform - XFree86 is 
> designed to run on many!  It would also bloat the kernel tremendously.

Hmmm. It quite complex question. Let's think about direct rendering kernel
modules ... XFree 4 went a step closer to the "right solution(TM)" because
it can cooperate with low level rendering capabilities of direct rendering
modules can be found in newer Linux kernels. And I think it's right to
split functions of a driver into "kernel level" and "user level" parts based
on functionality and hw access needs of particular parts of the whole gfx cloud.
However this "splitted" design can cause problems. Nowdays, XFree4 uses
OS independent, separated drivers (on a different OS but with the same CPU
the driver module is the same for XFree. afaik this technique was donated by
Metro). But kernel rendering modules are VERY kernel related stuffs and it's
quite hard for a video hardware vendor to release binary only drivers for
almost every kernels and so on. Of course the perfect solution would be open
source (let's dream a bit: GPL) drivers but our world is far from being perfect :(

Also it would be nice if frame buffer can support 3D hw accelerated gfx functions.
And so on. So probably a better interaction should be implemented between
various gfx elements of a tipical Linux system. [I don't know GGI very well
but AFAIK its goals are very interesting]

But this is far from the original topic of this thread so I must say: sorry :)

- Gabor

Re: The new X-Kernel !

[Jonathan Morton]

>  > And if they *do* understand it, from a dispassionate point of view,
>>  it does seem to make sense to put graphics drivers in the kernel -
>>  they're implemented as "device drivers" in every other desktop OS.
>>  Except MacOS X, where's it's an application layer like glibc, but
>>  nobody understand OS X yet beyond the hardest of developers.
>
>:) It would be interesting to learn more on it (if infomartion is available).
>afaik it's a unix like system in its core.

Take a look around Apple's site, particularly the developer section. 
There's documentation in spades if you can read PDFs.  Fact, that's 
one of the best things about Apple - they document nearly everything 
in public view.

>  > But they don't realise that XFree86 has an *enormous* amount of
>>  developer time behind it, which would need to be duplicated to make
>>  it work in kernel space with full backwards compatibility.  Oh, and
>>  did I mention this would all be for one platform - XFree86 is
>  > designed to run on many!  It would also bloat the kernel tremendously.
>
>Also it would be nice if frame buffer can support 3D hw accelerated 
>gfx functions.
>And so on. So probably a better interaction should be implemented between
>various gfx elements of a tipical Linux system. [I don't know GGI very well
>but AFAIK its goals are very interesting]

Come to think of it, the kernel already supports a fair amount of 
video hardware, through framebuffer.  I don't know how capable that 
is, though, beyond displaying and scrolling text in various 
resolutions, and as a place for XFree86 to fall back to.  If fbdev is 
accelerated, some kind of userspace utility and kernel-space cleanup 
would potentially allow fully-accelerated (including 3D?) graphics, 
with much of the hard work in kernel space.  Or is fbdev just a dumb 
framebuffer and I'm totally off track?

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

Re: The new X-Kernel !

[James Simmons]

> Come to think of it, the kernel already supports a fair amount of 
> video hardware, through framebuffer.  I don't know how capable that 
> is, though, beyond displaying and scrolling text in various 
> resolutions, and as a place for XFree86 to fall back to.  If fbdev is 
> accelerated, some kind of userspace utility and kernel-space cleanup 
> would potentially allow fully-accelerated (including 3D?) graphics, 
> with much of the hard work in kernel space.  Or is fbdev just a dumb 
> framebuffer and I'm totally off track?

At present fbdev is just a dumb framebuffer. In time I plan to merge both
DRI and fbdev into one common interface. Their is alot of ideas on where
graphics handling should be done. IMO the kernel should only manage the
state of the hardware amoung the various processes. This is defintely
needed for SMP machines where two processes could be using the hardware 
at the same time. Not actually programming the video hardware. That is
userland job.  

Re: The new X-Kernel !

[Allan Sandfeld]

On Sunday 21 October 2001 10:33, Jonathan Morton wrote:
> Probably because they don't know the difference between kernel and
> user space.  Kinda understandable when you come from a Mac or Windows
> background, where (in the former) there is no distinction or (in the
> latter) it's so blurred as to make little difference.
>
> And if they *do* understand it, from a dispassionate point of view,
> it does seem to make sense to put graphics drivers in the kernel -
> they're implemented as "device drivers" in every other desktop OS.
> Except MacOS X, where's it's an application layer like glibc, but
> nobody understand OS X yet beyond the hardest of developers.
>
We have the AGP, DRM and framebuffer drivers in the kernel anyway. It would 
make sense to do all the autodetection in kernelspace, and let the info be 
available to the X-server. I would love to kill all the hardware specific 
stuff in /etc/XF86Config, especially the keyboard and mouse stuff that 
belongs in or near the kernel.

Re: The new X-Kernel !

[Alan Cox]

> We have the AGP, DRM and framebuffer drivers in the kernel anyway. It would 
> make sense to do all the autodetection in kernelspace, and let the info be 
> available to the X-server. I would love to kill all the hardware specific 
> stuff in /etc/XF86Config, especially the keyboard and mouse stuff that 
> belongs in or near the kernel.

Quite the reverse. The handling for mice/keyboards and dynamic changes of
keyboard/mouse need to be in X11.

Alan

Re: The new X-Kernel !

[James Simmons]

> > We have the AGP, DRM and framebuffer drivers in the kernel anyway. It would 
> > make sense to do all the autodetection in kernelspace, and let the info be 
> > available to the X-server. I would love to kill all the hardware specific 
> > stuff in /etc/XF86Config, especially the keyboard and mouse stuff that 
> > belongs in or near the kernel.
> 
> Quite the reverse. The handling for mice/keyboards and dynamic changes of
> keyboard/mouse need to be in X11.

I disagree. Mice and keyboards are becoming more complex. To the point
where the hardware state has to be managed between processes in a
possible SMP system. Consider mice with force feedback. If several process
program the mouse to vibrate at the smae time it sums all the values up.
You can end up breaking the mouse because it vibrated to hard. Also look
at the problems GPM and X have had before. This problem gets more complex
as more pieces of software that play around with mice and keyboards 
emerges besides X or even while running in X. 

Re: The new X-Kernel !

[Alan Cox]

> at the problems GPM and X have had before. This problem gets more complex
> as more pieces of software that play around with mice and keyboards 
> emerges besides X or even while running in X. 

What is this non-X thing 8)

Seriously however most of this can be done well in userspace. The fact that
X + gpm years ago got it wrong doesn't disprove the theory. 

Re: The new X-Kernel !

[James Simmons]

> > at the problems GPM and X have had before. This problem gets more complex
> > as more pieces of software that play around with mice and keyboards 
> > emerges besides X or even while running in X. 
> 
> What is this non-X thing 8)

In the embedded market their is alot of GUI environments that are not X.
Working for a embedded linux company I come across many of them. Talking
to other embedded companies they all have the same answer. We will not use
X. They need something more portable and more powerful. A few off the top
of my head.

MicroWindows. 
Kaffe
Embedix   

Now before you say embedded devices don't use PS/2 mice and keyboards. I 
have a adapter to connect a PS/2 keyboard or mouse to the iPAQ at work. I
also have a alchemy board which allows you to plug in usb mice/keyboards. 

Plus for real game support I really like to see OpenGL use direct input.
Sorry but you need real time response in games. Have input events going
back a forth between the X cleint and the X server is just a waste.

> Seriously however most of this can be done well in userspace. The fact that
> X + gpm years ago got it wrong doesn't disprove the theory. 

As a said it is a matter of managing the hardware state between processes.
Consider a SMP machine that supports multiple desktops. Person on desktop
fires up a X server. It sets the hardware state of the keyboards and the
mice. The user runs apps that alter the state. The second user comes along
and log in on desktop two. He runs another small application to test the
mice. It changes the state which in turn effects the person on desktop
one. 

Re: The new X-Kernel !

[Tim Jansen]

On Sunday 21 October 2001 19:40, James Simmons wrote:
> It sets the hardware state of the keyboards and the
> mice. The user runs apps that alter the state. The second user comes along
> and log in on desktop two. He runs another small application to test the
> mice. It changes the state which in turn effects the person on desktop
> one.

Isn't this a driver problem? If two processes can interfere when using the 
same device the driver should only allow one access (one device file opened) 
at a time. And if two processes need to access it it should be managed by a 
daemon. 

bye...

Re: The new X-Kernel !

[Jesse Pollard]

On Sunday 21 October 2001 14:17, Tim Jansen wrote:
> On Sunday 21 October 2001 19:40, James Simmons wrote:
> > It sets the hardware state of the keyboards and the
> > mice. The user runs apps that alter the state. The second user comes
> > along and log in on desktop two. He runs another small application to
> > test the mice. It changes the state which in turn effects the person on
> > desktop one.
>
> Isn't this a driver problem? If two processes can interfere when using the
> same device the driver should only allow one access (one device file
> opened) at a time. And if two processes need to access it it should be
> managed by a daemon.

Neither - It is a resource allocation problem, which all UNIX style systems
seem to lack. And second, it doesn't happen at the present time with 
mice/keyboard/display unless somebody (root) did not configure the system 
properly (as in leave the device inodes accessable to world) OR change the
protection to permit access.

Once a resource is allocated to a user session (not process) it should not be 
accessable to other users.

Linux doesn't have a resource allocation other than the limited single open
support for character device drivers. This is usually sufficient for 
keyboard/mouse/display since it is the X server that is opening the device.

It is NOT sufficient for things like tape drives. The only way to prevent
conflict at the present time is to change the ownership of the inode, and 
ensure that the protection mask only permits user access. It is ALSO 
necessary to ensure that no other processes have that device open at the same 
time.

How those devices are controled/configured/used after allocation is and 
should remain a user mode function, NOT a kernel function.

Re: The new X-Kernel !

[Tim Jansen]

On Monday 22 October 2001 02:10, you wrote:
> Neither - It is a resource allocation problem, which all UNIX style systems
> seem to lack. And second, it doesn't happen at the present time with
> mice/keyboard/display unless somebody (root) did not configure the system
> properly (as in leave the device inodes accessable to world) OR change the
> protection to permit access.
> Once a resource is allocated to a user session (not process) it should not
> be accessable to other users.

But what's the point of doing it in the kernel instead of the user space? 
Basically X11 is nothing but a library for accessing mice/keyboard/display 
plus some daemon that manages these resource and introduces some policies 
(for example each process gets one or more windows it can draw in). And 
especially the display clearly needs some policy enforced to be useful for 
several processes.


> It is NOT sufficient for things like tape drives. The only way to prevent
> conflict at the present time is to change the ownership of the inode, and
> ensure that the protection mask only permits user access. It is ALSO
> necessary to ensure that no other processes have that device open at the
> same time.

Why should several process be allowed to access a tape drive? Raw access, 
like the kernel driver will provide, that allows things like fast-forward 
must be coordinated, at least. You need a higher level interface that 
coordinates things among processes. 

I do agree that the neccessary IPC for the communication between such a 
higher-level driver and the processes that use it is a problem though. That's 
why I like FUSD (http://www.circlemud.org/~jelson/software/fusd/), it gives 
you the ability to create higher-level drivers in user-space that behave like 
kernel drivers. (And, BTW, makes fun stuff possible like accessing 
device files on other computers over the network, without rewriting 
applications)

bye...

Re: The new X-Kernel !

[James Simmons]

> On Sunday 21 October 2001 14:17, Tim Jansen wrote:
> > On Sunday 21 October 2001 19:40, James Simmons wrote:
> > > It sets the hardware state of the keyboards and the
> > > mice. The user runs apps that alter the state. The second user comes
> > > along and log in on desktop two. He runs another small application to
> > > test the mice. It changes the state which in turn effects the person on
> > > desktop one.
> >
> > Isn't this a driver problem? If two processes can interfere when using the
> > same device the driver should only allow one access (one device file
> > opened) at a time. And if two processes need to access it it should be
> > managed by a daemon.
> 
> Neither - It is a resource allocation problem, which all UNIX style systems

[snip]...

I think everyone has misunderstood me. I know I'm not the most clear
person sometimes. I'm just talking about fine grain locking of some kind
between input devices. I really like to see "direct input" in OpenGL
someday. You need some kind of locking between OpenGL and the X server in
this case just like you have with graphics.

Re: The new X-Kernel !

[James Simmons]

> > It sets the hardware state of the keyboards and the
> > mice. The user runs apps that alter the state. The second user comes along
> > and log in on desktop two. He runs another small application to test the
> > mice. It changes the state which in turn effects the person on desktop
> > one.
> 
> Isn't this a driver problem? 

That is what I'm pointing out. 

> If two processes can interfere when using the 
> same device the driver should only allow one access (one device file opened) 
> at a time. 

That is the current solution.

> And if two processes need to access it it should be managed by a 
> daemon. 

And if the daemon dies you could end up with a broken mouse if using force
feedback. 

Re: The new X-Kernel !

[Tim Jansen]

On Monday 22 October 2001 18:51, James Simmons wrote:
> > And if two processes need to access it it should be managed by a
> > daemon.
> And if the daemon dies you could end up with a broken mouse if using force
> feedback.

But you have the same problem when the kernel driver dies. So moving the 
daemon into the kernel won't help.

bye...

Re: The new X-Kernel !

[Allan Sandfeld]

On Monday 22 October 2001 20:35, Tim Jansen wrote:
> On Monday 22 October 2001 18:51, James Simmons wrote:
> > > And if two processes need to access it it should be managed by a
> > > daemon.
> >
> > And if the daemon dies you could end up with a broken mouse if using
> > force feedback.
>
> But you have the same problem when the kernel driver dies. So moving the
> daemon into the kernel won't help.
>
> bye...
>
Kernel drivers are not supposed to fail. We can't assume the same about 
userspace programs.

Re: The new X-Kernel !

[Gábor Lénárt]

On Sun, Oct 21, 2001 at 10:40:06AM -0700, James Simmons wrote:
> 
> > > at the problems GPM and X have had before. This problem gets more complex
> > > as more pieces of software that play around with mice and keyboards 
> > > emerges besides X or even while running in X. 
> > 
> > What is this non-X thing 8)
> 
> In the embedded market their is alot of GUI environments that are not X.
> Working for a embedded linux company I come across many of them. Talking
> to other embedded companies they all have the same answer. We will not use
> X. They need something more portable and more powerful. A few off the top
> of my head.

OK then not use X for this purpose. But I don't see *ANY* point cause X
is not suitable for any usage with support kernel DRI API, giving you
XShm, DGA and many other things. Even you can create a tiny X like server
(actually it should be a library linked to applications or other) for
very low resourced embededd systems.

> have a adapter to connect a PS/2 keyboard or mouse to the iPAQ at work. I
> also have a alchemy board which allows you to plug in usb mice/keyboards. 
> 
> Plus for real game support I really like to see OpenGL use direct input.
> Sorry but you need real time response in games. Have input events going
> back a forth between the X cleint and the X server is just a waste.

This is something like DGA. DGA allows you to direct access the video
memory. DGA is very raw solution now, and yes, it should be more clever
for handling compilcated input devices as well, better integration into
X server (now, it simply mmap()s videoram so it needs root privs) and so on.
But I don't see any MAJOR point that is not possible with the current XFree
architecture which should be enhanced a bit (?) in the future, of course.

But don't move anything into kernel space which is possible in user space
as well! Just a point: XFree 4 now has got nice drivers (cross platform
compatibility on same CPU, vendors can release binary only drivers and so
on). It's MUCH harder to release binary only kernel modules not counting
cross OS compatibility ...

- Gabor

Re: The new X-Kernel !

[James Simmons]

> > have a adapter to connect a PS/2 keyboard or mouse to the iPAQ at work. I
> > also have a alchemy board which allows you to plug in usb mice/keyboards. 
> > 
> > Plus for real game support I really like to see OpenGL use direct input.
> > Sorry but you need real time response in games. Have input events going
> > back a forth between the X client and the X server is just a waste.

[snip]...
 
> But don't move anything into kernel space which is possible in user space
> as well! 

I think we are misunderstanding each other here. I just want to see some
kind of locking like DRI for input if "direct input" would ever be
implemented. I would like to see also a standard api used for all the
keyboards and mice. This is why I'm a a fan of the input api. Lets face
it. The XFree86 developement cycle is many many many times longer than
linux. This way as soon as a driver using the standard input api is
avaliable for linux it is supported under XFree86. 

Re: The new X-Kernel !

[Albert D. Cahalan]

Jonathan Morton writes:

> And if they *do* understand it, from a dispassionate point of view, 
> it does seem to make sense to put graphics drivers in the kernel - 
> they're implemented as "device drivers" in every other desktop OS. 
...
> But they don't realise that XFree86 has an *enormous* amount of 
> developer time behind it, which would need to be duplicated to make 
> it work in kernel space with full backwards compatibility.  Oh, and 
> did I mention this would all be for one platform - XFree86 is 
> designed to run on many!  It would also bloat the kernel tremendously.

So true... but for that bloat you get your oops and panic messages
on the screen, get cooperation with the VM, and reduce latency.

Other platforms? You're dreaming if you think they matter.
If video had been in Linux from the start, XFree86 would not be
alive today and that would have pretty much killed BSD. (OK w/ me)
Even today, I strongly suspect that XFree86 (and most of GNU BTW)
couldn't live without Linux providing developers.

Re: The new X-Kernel !

[Tim Jansen]

On Sunday 21 October 2001 09:37, Gábor Lénárt wrote:
> moved into kernel space :) IMHO it's strictly user space issue. You can
> start X or gdm/xdm/kdm from a boot script and so on. No kernel modification
> is needed for this.

But what the kernel COULD do is include something like the Linux Progress 
Patch (http://lpp.freelords.org/). It replaces the text output of the kernel 
with graphics and a progress bar, so people are not frightened by cryptic 
text output while booting.

bye...

Re: The new X-Kernel !

[john slee]

On Sun, Oct 21, 2001 at 02:54:15PM +0200, Tim Jansen wrote:
> But what the kernel COULD do is include something like the Linux Progress 
> Patch (http://lpp.freelords.org/). It replaces the text output of the kernel 
> with graphics and a progress bar, so people are not frightened by cryptic 
> text output while booting.

this is something for distributions to do...  even if the world turned
inside out and it got included there'd be endless flamewars (and
patches) concerning what colour the progress bar should be by default.

i read an interesting essay about that sort of thing on a freebsd list
once - search on freebsd archives for "garden shed" or similar.

j.

-- 
R N G G   "Well, there it goes again... And we just sit 
 I G G G   here without opposable thumbs." -- gary larson

Re: The new X-Kernel !

[Tim Jansen]

On Sunday 21 October 2001 17:37, john slee wrote:
> this is something for distributions to do...  even if the world turned
> inside out and it got included there'd be endless flamewars (and
> patches) concerning what colour the progress bar should be by default.

LPP is themeable, you need to change three header files (one containing the 
picture as an array definition) and then recompile to change a theme. The 
default theme could just use the usual, small penguin as picture, I don't 
think that this will cause a flamewar. If you want another theme it's quite 
easy to create one, you can also download a few themes at 
lpp-themes.sourceforge.net.

> i read an interesting essay about that sort of thing on a freebsd list
> once - search on freebsd archives for "garden shed" or similar.

In which freebsd list? I cannot find it.

bye...

Re: The new X-Kernel !

[Gábor Lénárt]

On Mon, Oct 22, 2001 at 01:37:47AM +1000, john slee wrote:
> On Sun, Oct 21, 2001 at 02:54:15PM +0200, Tim Jansen wrote:
> > But what the kernel COULD do is include something like the Linux Progress 
> > Patch (http://lpp.freelords.org/). It replaces the text output of the kernel 
> > with graphics and a progress bar, so people are not frightened by cryptic 
> > text output while booting.
> 
> this is something for distributions to do...  even if the world turned
> inside out and it got included there'd be endless flamewars (and
> patches) concerning what colour the progress bar should be by default.
> 
> i read an interesting essay about that sort of thing on a freebsd list
> once - search on freebsd archives for "garden shed" or similar.

Errrm ;-) It's very bad thing to hide boot messages even for novice users.
They can't bugreport in this way ... I thing the best way would be the
penguin logo at the top, and some pixel progress bar under Tux. The messages
should remain IMHO. But this bar indicator confuses me. How do you calculate
the remaining percentage? And of course this is kernel boot only. After init,
you can start costum process to show an indicator bar to messure remaining
tasks before hitting xdm/kdm/gdm/login/whatever.

But IMHO *hiding* kernel messages is the worst thing you can do ...
Probably a versatile parameterable boot logo + indicator setting tool
should be implemented (and of course the right code to the kernel to render
them on startup). It can include (let's say:)

position and size of text area inside the screen (kernel messages)
background picture
progress bar indicator attributes, position

and so on

Again: I'm AGAINST this stupid thing but if many user wants  ...
However HIDING kernel messages would be bad move ....

Major distributions include default kernels patched for nice boot screens,
so IMHO it isn't an issue for us. A user how can COMPILE kernel himself
probably does not want gfx-only boot screens .... or at least he can patch
kernel before compile it.

- Gabor

LPP (was: The new X-Kernel !)

[Tim Jansen]

On Sunday 21 October 2001 22:03, Gábor Lénárt wrote:
> Errrm ;-) It's very bad thing to hide boot messages even for novice users.
> They can't bugreport in this way ... 

You can switch to the regular console using some key. You probably don't want 
bug reports from users who can't even do this, so basically it's a filter :)

> messages should remain IMHO. But this bar indicator confuses me. How do you
> calculate the remaining percentage? And of course this is kernel boot only.
> After init, you can start costum process to show an indicator bar to
> messure remaining tasks before hitting xdm/kdm/gdm/login/whatever.

No, the LPP screen remains until X starts. You set the progress by writing to 
a file called /proc/progress. So there is a patch (at least for debian) that 
changes the init scripts to report the progress of booting. You can easily 
calculate the percentage when you count the scripts in /etc/rcX that you have 
to start.

bye...

Re: The new X-Kernel !

[Federico Sevilla III]

On Sun, 21 Oct 2001 at 22:03, Gábor Lénárt wrote:
> Errrm ;-) It's very bad thing to hide boot messages even for novice
> users. They can't bugreport in this way ... I thing the best way would
> be the penguin logo at the top, and some pixel progress bar under Tux.
> The messages should remain IMHO.

I strongly agree with this. Besides, dislike of the "greek" kernel
messages is not universal to all newbies. I know a number of ultra-newbies
who actually like this, and have asked me to (they don't know how) remove
their Windows 9x bootup screens so that it feels "geekier". And these
people aren't geeks.

The good side to having decent kernel information at boot up is that users
inevitably remember _patterns_. They may not remember what the things
mean, but they'll sure know when something's suddenly different (if they
look, of course). And this leads to knowing the system more. In this sense
the bootup information is a good tool for the slow and painful process of
educating users, weening them from the shelter from information that a
number of other OSs provide.

 --> Jijo

--
Federico Sevilla III  :: jijo@leathercollection.ph
Network Administrator :: The Leather Collection, Inc.
GnuPG Key: <http://jijo.leathercollection.ph/jijo.gpg>

Re: The new X-Kernel !

[Gábor Lénárt]

On Mon, Oct 22, 2001 at 05:22:47AM +0800, Federico Sevilla III wrote:
> On Sun, 21 Oct 2001 at 22:03, Gábor Lénárt wrote:
> > Errrm ;-) It's very bad thing to hide boot messages even for novice
> > users. They can't bugreport in this way ... I thing the best way would
> > be the penguin logo at the top, and some pixel progress bar under Tux.
> > The messages should remain IMHO.
> 
> I strongly agree with this. Besides, dislike of the "greek" kernel
> messages is not universal to all newbies. I know a number of ultra-newbies
> who actually like this, and have asked me to (they don't know how) remove
> their Windows 9x bootup screens so that it feels "geekier". And these
> people aren't geeks.

:) Even an (ex)girlfriend of mine said that Linux is much better than Windows,
because of the messages on boot ("superb cyber feeling a'la Matrix :)").
So I don't think so that messages are annoying even for stupid users.

- Gabor

RE: The new X-Kernel !

[Sean Cavanaugh]

This side thread is funny, everyone here is thinking too much like a
developer :)

Normal users really don't need to see the startup message spam on boot,
unless there is an error (at which point it should be able to present
the error to the user).  Any kind of of progress indicator' s really
more for feedback that the boot is proceeding ok.  The fact the boot
sequence isn't even interactive should also be a big hint that it isn't
really necessary (except for kernel and driver developers).

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Gábor Lénárt
Sent: Sunday, October 21, 2001 3:04 PM
To: john slee
Cc: linux-kernel@vger.kernel.org
Subject: Re: The new X-Kernel !


On Mon, Oct 22, 2001 at 01:37:47AM +1000, john slee wrote:
> On Sun, Oct 21, 2001 at 02:54:15PM +0200, Tim Jansen wrote:
> > But what the kernel COULD do is include something like the Linux 
> > Progress
> > Patch (http://lpp.freelords.org/). It replaces the text output of
the kernel 
> > with graphics and a progress bar, so people are not frightened by
cryptic 
> > text output while booting.
> 
> this is something for distributions to do...  even if the world turned

> inside out and it got included there'd be endless flamewars (and
> patches) concerning what colour the progress bar should be by default.
> 
> i read an interesting essay about that sort of thing on a freebsd list

> once - search on freebsd archives for "garden shed" or similar.

Errrm ;-) It's very bad thing to hide boot messages even for novice
users. They can't bugreport in this way ... I thing the best way would
be the penguin logo at the top, and some pixel progress bar under Tux.
The messages should remain IMHO. But this bar indicator confuses me. How
do you calculate the remaining percentage? And of course this is kernel
boot only. After init, you can start costum process to show an indicator
bar to messure remaining tasks before hitting
xdm/kdm/gdm/login/whatever.

But IMHO *hiding* kernel messages is the worst thing you can do ...
Probably a versatile parameterable boot logo + indicator setting tool
should be implemented (and of course the right code to the kernel to
render them on startup). It can include (let's say:)

position and size of text area inside the screen (kernel messages)
background picture progress bar indicator attributes, position

and so on

Again: I'm AGAINST this stupid thing but if many user wants  ... However
HIDING kernel messages would be bad move ....

Major distributions include default kernels patched for nice boot
screens, so IMHO it isn't an issue for us. A user how can COMPILE kernel
himself probably does not want gfx-only boot screens .... or at least he
can patch kernel before compile it.

- Gabor
-

Re: The new X-Kernel !

[Alan Cox]

> Normal users really don't need to see the startup message spam on boot,
> unless there is an error (at which point it should be able to present
> the error to the user).  Any kind of of progress indicator' s really

The big problem is making sure they then see the error, and the previous
progress information. On a solid hang they might not get it

> more for feedback that the boot is proceeding ok.  The fact the boot
> sequence isn't even interactive should also be a big hint that it isn't
> really necessary (except for kernel and driver developers).

You are thinking the small picture not the big one. If you are going to
graphical in init then you want to make full use of the graphical
environment to clearly show things like parallel fsck behaviour, what
servers are starting up (with pretty icons) and to do interactive things 
like starting a rescue shell, going single user, pausing the boot,
changing run level, interactive boot.

Alan

Re: The new X-Kernel !

[Oden Eriksson]

On Sundayen den 21 October 2001 23.52, Alan Cox wrote:
> > Normal users really don't need to see the startup message spam on boot,
> > unless there is an error (at which point it should be able to present
> > the error to the user).  Any kind of of progress indicator' s really
>
> The big problem is making sure they then see the error, and the previous
> progress information. On a solid hang they might not get it
>
> > more for feedback that the boot is proceeding ok.  The fact the boot
> > sequence isn't even interactive should also be a big hint that it isn't
> > really necessary (except for kernel and driver developers).
>
> You are thinking the small picture not the big one. If you are going to
> graphical in init then you want to make full use of the graphical
> environment to clearly show things like parallel fsck behaviour, what
> servers are starting up (with pretty icons) and to do interactive things
> like starting a rescue shell, going single user, pausing the boot,
> changing run level, interactive boot.
>

Gee, this sounds like Mandrake with candy like "Aurora" and "Linuxconf", I 
prefer the old behaivour though :)

-- 
Oden Eriksson, Jokkmokk, Sweden.
Mandrake Linux release 8.1 (Vitamin) for i586, kernel 2.4.12-3mdk. Uptime: 
18:17

RE: The new X-Kernel !

[Sean Cavanaugh]

Well this thread is sort of a silly argument to begin with, seeing as
all my Linux machines except one don't even have monitors attached to
them :)

I can argue the other side of the fence just as easily . . .
The messages can be handy for figuring out what piece of hardware or
kernel service is taking ages to load when one of them suddenly decides
to take an unusually long time start.  Try piecing that kind of
information out of a dmesg output.  I would rather see
'system/module foo loading . . .' 
'     module specific startup information (stuff we already see in
startup'
'system/module foo loaded in .xxx seconds'

Also ,I also wouldn't really advocate hiding the messages anyway, since
there are thousands of areas elsewhere (outside of the Kernel) to spend
time on and improve usability which would have more of a real impact to
users.

-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] 
Sent: Sunday, October 21, 2001 4:53 PM
To: Sean Cavanaugh
Cc: linux-kernel@vger.kernel.org
Subject: Re: The new X-Kernel !


> Normal users really don't need to see the startup message spam on 
> boot, unless there is an error (at which point it should be able to 
> present the error to the user).  Any kind of of progress indicator' s 
> really

The big problem is making sure they then see the error, and the previous
progress information. On a solid hang they might not get it

> more for feedback that the boot is proceeding ok.  The fact the boot 
> sequence isn't even interactive should also be a big hint that it 
> isn't really necessary (except for kernel and driver developers).

You are thinking the small picture not the big one. If you are going to
graphical in init then you want to make full use of the graphical
environment to clearly show things like parallel fsck behaviour, what
servers are starting up (with pretty icons) and to do interactive things

like starting a rescue shell, going single user, pausing the boot,
changing run level, interactive boot.

Alan

Re: The new X-Kernel !

[Gábor Lénárt]

On Sun, Oct 21, 2001 at 04:38:26PM -0500, Sean Cavanaugh wrote:
> This side thread is funny, everyone here is thinking too much like a
> developer :)
> 
> Normal users really don't need to see the startup message spam on boot,
> unless there is an error (at which point it should be able to present
> the error to the user).  Any kind of of progress indicator' s really
> more for feedback that the boot is proceeding ok.  The fact the boot
> sequence isn't even interactive should also be a big hint that it isn't
> really necessary (except for kernel and driver developers).


A big no-no ... as I told my story of my girlfriend with Linux.
Nobody is forced to use Linux .... I don't think so to put more complexity
JUST FOR stupid users. But come on! I don't inmagine that a user CAN'T
live with visible kernel messages ... Or if so, send them to the hospital
because they're allegric to letters :) 

But for being serious ... For example you can build SECURITY into an OS.
You can install "firewalls" to Windows. And that sw component may ask
user that it detects something which MAY cause problems, and it asks
user if this task is allowed or not. And most of "stupid-users" don't
even read what message said! And if so, it's not helpful at all, since
the security on answering a question is to KNOW what does it covers.
What does it means? There is NO perfect security, there is NO perfect
solution and so for "stupid-user' TILL someone invents AI to help them ;-)

- Gabor

LPP (was: The new X-Kernel !)

[Tim Jansen]

On Sunday 21 October 2001 23:53, Gábor Lénárt wrote:
> But for being serious ... For example you can build SECURITY into an OS.
> You can install "firewalls" to Windows. And that sw component may ask
> user that it detects something which MAY cause problems, and it asks
> user if this task is allowed or not. And most of "stupid-users" don't
> even read what message said! And if so, it's not helpful at all, since
> the security on answering a question is to KNOW what does it covers.

But part of this problem is that users get too much information that they 
don't understand, so they are getting used to ignore it. What you have to do 
to make the system easier to use is reduce the amount of information and make 
it easier to understand. The boot messages of the kernel are certainly much 
more than a regular user needs (and I am speaking those people who are 
currently using Windows or Macs, not Linux) and not very helpful for them.

bye...

Re: LPP (was: The new X-Kernel !)

[Jakob Østergaard]

On Mon, Oct 22, 2001 at 12:19:07AM +0200, Tim Jansen wrote:
> On Sunday 21 October 2001 23:53, Gábor Lénárt wrote:
> > But for being serious ... For example you can build SECURITY into an OS.
> > You can install "firewalls" to Windows. And that sw component may ask
> > user that it detects something which MAY cause problems, and it asks
> > user if this task is allowed or not. And most of "stupid-users" don't
> > even read what message said! And if so, it's not helpful at all, since
> > the security on answering a question is to KNOW what does it covers.
> 
> But part of this problem is that users get too much information that they 
> don't understand, so they are getting used to ignore it. What you have to do 
> to make the system easier to use is reduce the amount of information and make 
> it easier to understand. The boot messages of the kernel are certainly much 
> more than a regular user needs (and I am speaking those people who are 
> currently using Windows or Macs, not Linux) and not very helpful for them.
> 

How would hiding that information make the system "easier to use" ?   They
can't interact with the boot process anyway - but they can call their sysadmin
and say "it said 'kernel panic'" and he can make them read up the last few
lines on the screen.

I've done that successfully with the mail-relay/proxy/router/fileserver at my
parent's house, with my mother at the keyboard ! She writes books about gardens
for a living.  If all she could tell me was "well there's a penguin with a line
under it that doesn't move", I'd be pretty stuck.

Really, treating people like idiots will get you idiots.  I don't believe there
are that many idiots around - but some computer litterates seem to have the
idea that computer illiterates are best treated as drooling morons. Those poor
people will never know, because they never get a chance.   This is *not* doing
them a favour.

 "User friendliness is often confused
  with designing software for idiots"
    - me  ;)

Now don't think that I'm against nice user interfaces.  Not at all.  I'm just
against over-protecting people from the real world.   Don't hide generally
useful information, that's all.

--
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: LPP (was: The new X-Kernel !)

[Tim Jansen]

On Monday 22 October 2001 02:28, you wrote:
> How would hiding that information make the system "easier to use" ?   

Because the majority of people (and especially those who haven't been reached 
by Linux yet) don't care for the messages. They are as interested in boot 
messages as you may be in reading debug information from your DVD player or 
car. 

Assuming you have a car with a display for the embedded computer, and you 
don't know anything about its software or hardware, you just want to drive. 
Would you prefer to see lots of cryptic messages when you turn the key, or 
just some simple picture with a progress bar showing you when the system is 
ready?
IMHO the bar is all you need. Everything else just distracts you from the 
only important thing. 

Showing unimportant information is like turning on debug messages that you 
don't need.

bye...

Re: LPP (was: The new X-Kernel !)

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]

Hi Tim!

> > How would hiding that information make the system "easier to use" ?   
> 
> Because the majority of people (and especially those who haven't been reached 
> by Linux yet) don't care for the messages. They are as interested in boot 
> messages as you may be in reading debug information from your DVD player or 
> car. 
> 
> Assuming you have a car with a display for the embedded computer, and you 
> don't know anything about its software or hardware, you just want to drive. 
> Would you prefer to see lots of cryptic messages when you turn the key, or 
> just some simple picture with a progress bar showing you when the system is 
> ready?
> IMHO the bar is all you need. Everything else just distracts you from the 
> only important thing. 
> 
> Showing unimportant information is like turning on debug messages that you 
> don't need.

Interesting you should mention this analogy. Incidently, I would've
preferred that my car give me a detail analysis of what's wrong. In fact, it
would've been such a cool feature that it would be reason enough to sell my
car and by that one (I could save myself years of arguing with incompetent
mechanics).

I suspect most people on this list feel the same as me and also feel that
kernel debugging messages is not only a feature, but essential!

See the difference between the O/S in question and the one you might be
confusing it with is that this O/S was (and still is) written and being
maintained by technical people. These kind of people like to know what's
going on. It also happens that the primary audience for these people's work
is themselves (us) and NOT novices - that my friend, is a bonus, not the
sole aim of the exercise.


-- 

Regards
 Abraham

You can't run away forever,
But there's nothing wrong with getting a good head start.
		-- Jim Steinman, "Rock and Roll Dreams Come Through"

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: LPP (was: The new X-Kernel !)

[Ragnar Hojland Espinosa]

On Mon, Oct 22, 2001 at 10:34:11AM +0200, Abraham vd Merwe wrote:
> > 
> > Because the majority of people (and especially those who haven't been reac
> > by Linux yet) don't care for the messages. They are as interested in boot
> > messages as you may be in reading debug information from your DVD player o
> > car. 

Even better paralelism:  What do people run, strace ls or ls?

> Interesting you should mention this analogy. Incidently, I would've
> preferred that my car give me a detail analysis of what's wrong. In fact,

Please reread what you have written.  Now run dmesg.  Do you see messages
telling you what's wrong there?  No?  Okay.. So what is it telling you?

Details about your system?   No, thats *how* it is telling you.  What aaall
those lines are saying is that everything is working as usual. Wait wait,
don't jump yet :)

Okay.  They do help to debug early kernel crashes, showing exactly where it
stopped.  With no messages, an literate user would use 'boot_verbose=1' to
override the 'boot_verbose=0' in lilo.conf and see where it crashed.  

Now picture a quite iliterate user with a messages, and a boot problem..
what will he say in the majority of the cases?  I'll tell you: "my linux 
wont boot" / "my linux crashed", and if you ask what was on the screen to 
"oh.. dunno.. the lines it uses to print..", so messages wouldnt make a
difference.  If people dont use to read error/message dialogs, are you
seriously expecting them to read and understand that "text thingie"?

> confusing it with is that this O/S was (and still is) written and being
> maintained by technical people. These kind of people like to know what's
> going on. It also happens that the primary audience for these people's work
> is themselves (us) and NOT novices - that my friend, is a bonus, not the

I disagree with your reasoning.  You give two points.. first, that technical
people want to know whats going on.  They do.  They would.  In fact, nobody
is saying the "raw" kernel (ie without args) shouldn't show the messages.

And primary audience.  Well.  People don't get educated out of the blue.
You need to soften (even more, yes) the learning curve.  What would you
consider more pleasant, an OS in which you can dive bit by bit, or one that
just drops you there and requires you to read a lot of stuff?  I am quite
concerned about about the people who say they want to try linux, but that
its too hard for them.

Someone said in this thread that you write for idiots you get idiots, wrt
hiding boot messages.  I don't read them when I boot, so they are,
effectively, hidden.  Does that make me an idiot?

Idiocy has nothing to do with simplicity.  And we know simplicity is good.

-- 
____/|  Ragnar Højland      Freedom - Linux - OpenGL |    Brainbench MVP
\ o.O|  PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
 =(_)=  "Thou shalt not follow the NULL pointer for  | (www.brainbench.com)
   U     chaos and madness await thee at its end."

Re: LPP (was: The new X-Kernel !)

[Petr Baudis]

> Even better paralelism:  What do people run, strace ls or ls?
With strace ls, output of ls is not very usable. So this doesn't match.

> > Interesting you should mention this analogy. Incidently, I would've
> > preferred that my car give me a detail analysis of what's wrong. In fact,
> 
> Please reread what you have written.  Now run dmesg.  Do you see messages
> telling you what's wrong there?  No?  Okay.. So what is it telling you?
With hiding of messages during boot, you won't ever have an idea to _run_
the dmesg!

> Okay.  They do help to debug early kernel crashes, showing exactly where it
> stopped.  With no messages, an literate user would use 'boot_verbose=1' to
> override the 'boot_verbose=0' in lilo.conf and see where it crashed.  
They can also help to presume problems on the horizon and then seeking for
the cause of them... one might say... ah, wait a minute, now i remember,
during bootup i glanced there, and there was something about DMA errors,
wtf is that? can't it be a problem?

> Now picture a quite iliterate user with a messages, and a boot problem..
> what will he say in the majority of the cases?  I'll tell you: "my linux 
> wont boot" / "my linux crashed", and if you ask what was on the screen to 
> "oh.. dunno.. the lines it uses to print..", so messages wouldnt make a
> difference.  If people dont use to read error/message dialogs, are you
> seriously expecting them to read and understand that "text thingie"?
and when they hide them, they will say "it didn't do anything. dunno where
it stopped. to run it with li..what? loot_virboss:zero? excuse me?"

> Someone said in this thread that you write for idiots you get idiots, wrt
> hiding boot messages.  I don't read them when I boot, so they are,
> effectively, hidden.  Does that make me an idiot?
if you want to force one not to see them even if he might want once time,
but dunno how to turn them on...

> Idiocy has nothing to do with simplicity.  And we know simplicity is good.
debug messages don't add complexity. optionality of them does. :P

as someone said here, this is also a psychological issue, the feeling of
common secret knowledge, the feeling of speciality, the cool matrix-like
look which make you look as geek and expert, the mysterious messages which
will actually tell you everything what that thing does, does it matter
that you don't understand it? it looks cool so it is good :P and you said
they won't even read it, so they won't have a feeling of informations
overhead, so they won't hate or fear the computer, just like it that it
is willing to tell them what is going on, if they would ever want to listen...

-- 

				Petr "Pasky" Baudis

UN*X programmer, UN*X administrator, hobbies = IPv6, IRC
Real Users hate Real Programmers.
Public PGP key, geekcode and stuff: http://pasky.ji.cz/~pasky/

Re: LPP (was: The new X-Kernel !)

[Ragnar Hojland Espinosa]

On Tue, Oct 23, 2001 at 10:50:03PM +0200, Petr Baudis wrote:

Sorry for the late reply Petr, I'm a bit swamped here..

> > Even better paralelism:  What do people run, strace ls or ls?
> With strace ls, output of ls is not very usable. So this doesn't match.

Fine.  rm then.  perfectly useable.

> > Please reread what you have written.  Now run dmesg.  Do you see messages
> > telling you what's wrong there?  No?  Okay.. So what is it telling you?
> With hiding of messages during boot, you won't ever have an idea to _run_
> the dmesg!

I don't understand why you are saying that (in this context)

> They can also help to presume problems on the horizon and then seeking for
> the cause of them... one might say... ah, wait a minute, now i remember,
> during bootup i glanced there, and there was something about DMA errors,
> wtf is that? can't it be a problem?

Sure.  But what is easier, to glance "something" about DMA errors among all
the other usual chatter, or just by itself?  That's something the different
KERN_ could do for us. 

> > Now picture a quite iliterate user with a messages, and a boot problem..
> > what will he say in the majority of the cases?  I'll tell you: "my linux 
> > wont boot" / "my linux crashed", and if you ask what was on the screen to 
> > "oh.. dunno.. the lines it uses to print..", so messages wouldnt make a
> > difference.  If people dont use to read error/message dialogs, are you
> > seriously expecting them to read and understand that "text thingie"?

> and when they hide them, they will say "it didn't do anything. dunno where
> it stopped. to run it with li..what? loot_virboss:zero? excuse me?"

*laugh* true :)  Thats what il-user friendly tools are for.  I'm sure theres
some gtk/gnome/kde gui thing to select how to boot next time.  And if there
isn't I'm sure you realize its easy to do.

> as someone said here, this is also a psychological issue, the feeling of
> common secret knowledge, the feeling of speciality, the cool matrix-like
> look which make you look as geek and expert, the mysterious messages which

Soo.. bob goes to alice, and sees the usual messages.  Or, bob goes to alice:
"wow, how did you get all those mysterious messages from?"

Not only hiding would enhance this factor you are alluding(sp?), but it
would also help the people who are "impressed" by them.

> that you don't understand it? it looks cool so it is good :P and you said
> they won't even read it, so they won't have a feeling of informations
> overhead, so they won't hate or fear the computer, just like it that it
> is willing to tell them what is going on, if they would ever want to
> listen...

Theres people who don't want to.  Mostly because for normal operation they
don't have to, and because they aren't willing to commit enough time/effort
to figure out what is going on.  If their car doesn't work, they take it to
a mechanic, they don't try to figure it out by themselves.  They know and
only want to drive it.

-- 
____/|  Ragnar Højland      Freedom - Linux - OpenGL |    Brainbench MVP
\ o.O|  PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
 =(_)=  "Thou shalt not follow the NULL pointer for  | (www.brainbench.com)
   U     chaos and madness await thee at its end."

Re: LPP (was: The new X-Kernel !)

[Sunil Phatak]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

Abraham vd Merwe wrote:

> Hi Tim!
>
> > > How would hiding that information make the system "easier to use" ?
> >
> > Because the majority of people (and especially those who haven't been reached
> > by Linux yet) don't care for the messages. They are as interested in boot
> > messages as you may be in reading debug information from your DVD player or
> > car.

Well, people and even novices may be interested in the boot messages and/or can
learn a great deal from them.  But at boot time the messages can be hidden as they
anyway scroll past too fast to read, and are available later by 'dmesg'. Even the
init log is available for anyone to read. It would be nicer if the messages were
displayed on if a critical error occurred.

> I suspect most people on this list feel the same as me and also feel that
> kernel debugging messages is not only a feature, but essential!

The 'startup screen+ progress bar' can be enabled for all stable kernels once
Linus freezes that version.

> See the difference between the O/S in question and the one you might be
> confusing it with is that this O/S was (and still is) written and being
> maintained by technical people. These kind of people like to know what's
> going on. It also happens that the primary audience for these people's work
> is themselves (us) and NOT novices - that my friend, is a bonus, not the
> sole aim of the exercise.

Not really! The developers might be 'technical people' (as expected for an OS),
but the users are most definitely an audience worth caring for and most of them
are unaware of even the simplest of OS fundamentals.


[-- Attachment #2: Card for Sunil Phatak --]
[-- Type: text/x-vcard, Size: 336 bytes --]

begin:vcard
n:Phatak;Sunil
tel;home:0832-255918
x-mozilla-html:FALSE
org:Tata Infotech Ltd.;Embedded Technology Group
version:2.1
email;internet:sunil.phatak@tatainfotech.com
title:Associate Systems Engineer
adr;quoted-printable:;;B-4, Shalini Niwas,=0D=0AAnsabhat;Mapusa;Goa;403507;India
x-mozilla-cpt:;14208
fn:Sunil Phatak
end:vcard

Re: LPP (was: The new X-Kernel !)

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

Hi Sunil!

> Well, people and even novices may be interested in the boot messages and/or can
> learn a great deal from them.  But at boot time the messages can be hidden as they
> anyway scroll past too fast to read, and are available later by 'dmesg'. Even the

That's what ScrollLock and Shift-PageUP are for (;

dmesg is also useless if the kernel crashes before you've booted up
completely.

> > I suspect most people on this list feel the same as me and also feel that
> > kernel debugging messages is not only a feature, but essential!
> 
> The 'startup screen+ progress bar' can be enabled for all stable kernels once
> Linus freezes that version.

I guess this won't be too bad as long as you have the option to boot up the
traditional way. I definitely prefer knowing what's going on to looking at
progress bars.

-- 

Regards
 Abraham

You can't judge a book by the way it wears its hair.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: LPP (was: The new X-Kernel !)

[MichaelM]

From: "Abraham vd Merwe" <abraham@2d3d.co.za>

>See the difference between the O/S in question and the one you might be
>confusing it with is that this O/S was (and still is) written and being
>maintained by technical people. These kind of people like to know what's
>going on. It also happens that the primary audience for these people's work
>is themselves (us) and NOT novices - that my friend, is a bonus, not the
>sole aim of the exercise.

Have you ever thought that people get great difficulties when they try to
change to linux, e.g the partitioning, 3d games graphics ;) etc..

... therefore, only technical and technical-wanna-be people remain?

It's quite clear to me.

Re: LPP (was: The new X-Kernel !)

[Mike Fedyk]

On Mon, Oct 22, 2001 at 03:33:07PM +0100, MichaelM wrote:
> From: "Abraham vd Merwe" <abraham@2d3d.co.za>
> 
> >See the difference between the O/S in question and the one you might be
> >confusing it with is that this O/S was (and still is) written and being
> >maintained by technical people. These kind of people like to know what's
> >going on. It also happens that the primary audience for these people's work
> >is themselves (us) and NOT novices - that my friend, is a bonus, not the
> >sole aim of the exercise.
> 
> Have you ever thought that people get great difficulties when they try to
> change to linux, e.g the partitioning, 3d games graphics ;) etc..
> 
> ... therefore, only technical and technical-wanna-be people remain?
> 
> It's quite clear to me.
> 

X in the kernel won't help with that.

The progress bars will make it *look* less technical.

The setup of hardware like 3d graphics is up to the distribution.  Those are
the people you should be talking to.

Mike

Re: LPP (was: The new X-Kernel !)

[David Relson]

If I correctly remember the days when I used NeXTSTEP, there were two boot 
modes.  In graphics mode, there was a status bar.  In verbose (text) mode, 
all the messages appeared.  As the boot started, there was a prompt in 
which you could specify single-user mode, verbose mode, etc.  With no 
specification, after a few seconds it would go ahead and boot.  Also, the 
mode (graphics vs text) could be set via the Preferences capability.

As a software developer, most of the time I didn't want/need the messages 
so I'd let it run in graphics mode.  Of course when the boot had a problem, 
I'd reboot and run it verbose (text) mode.

David

At 08:57 PM 10/21/01, you wrote:
>On Monday 22 October 2001 02:28, you wrote:
> > How would hiding that information make the system "easier to use" ?
>
>Because the majority of people (and especially those who haven't been reached
>by Linux yet) don't care for the messages. They are as interested in boot
>messages as you may be in reading debug information from your DVD player or
>car.
>
>Assuming you have a car with a display for the embedded computer, and you
>don't know anything about its software or hardware, you just want to drive.
>Would you prefer to see lots of cryptic messages when you turn the key, or
>just some simple picture with a progress bar showing you when the system is
>ready?
>IMHO the bar is all you need. Everything else just distracts you from the
>only important thing.
>
>Showing unimportant information is like turning on debug messages that you
>don't need.
>
>bye...
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

RE: The new X-Kernel !

[Leo Spalteholz]

>This side thread is funny, everyone here is thinking too much like a
>developer :)
>
>Normal users really don't need to see the startup message spam on boot,
>unless there is an error (at which point it should be able to present
>the error to the user).  Any kind of of progress indicator' s really
>more for feedback that the boot is proceeding ok.  The fact the boot
>sequence isn't even interactive should also be a big hint that it isn't
>really necessary (except for kernel and driver developers).


I agree that for the normal user, plain messages are useless..   I remember 
something in Mandrake (7.0?), what they did is print a green [OK]  after 
every message and a red [ERROR] when something failed..  This was great for 
a quick visual check..   As soon as you see something red scroll past you 
know there's something wrong and you can check it later..
So this should really be left up to the distros..

RE: The new X-Kernel !

[Jonathan Morton]

At 3:14 pm -0700 21/10/2001, Leo Spalteholz wrote:
>>This side thread is funny, everyone here is thinking too much like a
>>developer :)
>>
>>Normal users really don't need to see the startup message spam on boot,
>>unless there is an error (at which point it should be able to present
>>the error to the user).  Any kind of of progress indicator' s really
>>more for feedback that the boot is proceeding ok.  The fact the boot
>>sequence isn't even interactive should also be a big hint that it isn't
>>really necessary (except for kernel and driver developers).
>
>
>I agree that for the normal user, plain messages are useless..   I 
>remember something in Mandrake (7.0?), what they did is print a 
>green [OK]  after every message and a red [ERROR] when something 
>failed..  This was great for a quick visual check..   As soon as you 
>see something red scroll past you know there's something wrong and 
>you can check it later..
>So this should really be left up to the distros..

That's been in there since at least Red Hat 6.0, and has spread to 
all the derivatives, including mkLinux, Mandrake, Yellow Dog et al. 
I agree, it's a great system, even though it only works once the 
System V scripts start going.  If the kernel could do something like 
that (maybe with a "pretty" argument via LILO, and a compile-time 
option), it'd make the boot sequence a little less forbidding to 
(l)users.

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

Re: The new X-Kernel !

[Malcolm H. Teas]

Tim Jansen wrote:

> On Sunday 21 October 2001 09:37, Gábor Lénárt wrote:
> 
>>moved into kernel space :) IMHO it's strictly user space issue. You can
>>start X or gdm/xdm/kdm from a boot script and so on. No kernel modification
>>is needed for this.
>>
> 
> But what the kernel COULD do is include something like the Linux Progress 
> Patch (http://lpp.freelords.org/). It replaces the text output of the kernel 
> with graphics and a progress bar, so people are not frightened by cryptic 
> text output while booting.


But what graphics resources does the LPP require?  If it's more restricted than 
the current Linux boot process it affects server-oriented machines that aren't 
running X or graphics, that just serve resources on the net.

I'd not like to see the minimum bar for hardware compatibility raised without 
very good cause.  Boot time messages aren't a good cause for me. YMMV.

My feeling: At best it should be an option only, and default to no LPP.

-Malcolm Teas

Re: The new X-Kernel !

[Tim Jansen]

On Sunday 21 October 2001 18:09, you wrote:
> But what graphics resources does the LPP require?  If it's more restricted
> than the current Linux boot process it affects server-oriented machines
> that aren't running X or graphics, that just serve resources on the net.
> I'd not like to see the minimum bar for hardware compatibility raised
> without very good cause.  Boot time messages aren't a good cause for me.
> YMMV.
> My feeling: At best it should be an option only, and default to no LPP.

Of couse as an option. I don't say that it's a good idea for servers, but I 
heard several times that people are "confused" by Linux's boot messages, and 
people consider it as less "friendly" than other OSes because of the boot 
messages that they don't understand anyway. So it may be a good idea for 
desktop machines and inexperienced users.

Currently it needs a VESA-framebuffer, and if this is not available it could 
fall back to text mode. I'm not sure what the current patch does in this 
situation though. 

bye...

Re: The new X-Kernel !

[Bernd Eckenfels]

In article <20011021093728.A17786@vega.digitel2002.hu> you wrote:
> I've never understood why people want X, StarOffice (OpenOffice) etc to be
> moved into kernel space :)

Well, it is not a question of moving X or Office into Kernel Space. But
current development clearly shows, that some things like Video Card Access
need Kernel Support. IMHO the Amount of GDI related Functions in NT Kernel
are too much, but X11 is not exactly the Windowing System you can consider
well suited for Desktop and Game Use.

Greetings
Bernd

Re: The new X-Kernel !

[Gábor Lénárt]

On Sun, Oct 21, 2001 at 09:13:17PM +0200, Bernd Eckenfels wrote:
> In article <20011021093728.A17786@vega.digitel2002.hu> you wrote:
> > I've never understood why people want X, StarOffice (OpenOffice) etc to be
> > moved into kernel space :)
> 
> Well, it is not a question of moving X or Office into Kernel Space. But
> current development clearly shows, that some things like Video Card Access
> need Kernel Support. IMHO the Amount of GDI related Functions in NT Kernel
> are too much, but X11 is not exactly the Windowing System you can consider
> well suited for Desktop and Game Use.

And why? I think it's perfect solution. The only problem IMHO is DGA. DGA
is not a direct competitor with DirectX because it lacks some features and
needs root privileges to use it (because it mmap()s video ram). But this
is NOT a kernel issue either: according the answer to my old letter to the
XFree mailing list it can be possible (I mean DGA access without root rights)
but it would require major modifications inside XFree so it's not planned
in the near future. What do you want to move into kernel space? IMHO the best
way is to keep as less functionalities into kernel space as possible. Other
things can be implemented in user space as well.

- Gabor

Re: The new X-Kernel !

[J Sloan]

Bernd Eckenfels wrote:

> Well, it is not a question of moving X or Office into Kernel Space. But
> current development clearly shows, that some things like Video Card Access
> need Kernel Support. IMHO the Amount of GDI related Functions in NT Kernel
> are too much, but X11 is not exactly the Windowing System you can consider
> well suited for Desktop and Game Use.

That strikes me as odd, can you explain further?

I have had a wonderful experience with XF86
as a daily work environment and entertainment
platform (multimedia, 3d intetrnet gaming etc).

cu

jjs

Re: The new X-Kernel !

[Tim Jansen]

On Sunday 21 October 2001 21:13, Bernd Eckenfels wrote:
> Well, it is not a question of moving X or Office into Kernel Space. But
> current development clearly shows, that some things like Video Card Access
> need Kernel Support. IMHO the Amount of GDI related Functions in NT Kernel
> are too much, but X11 is not exactly the Windowing System you can consider
> well suited for Desktop and Game Use.

Actually some gfx code has already been moved into the kernel, see DRI and 
the nvidia kernel modules. And AFAIK there aren't any noticably speed 
differences between nvidia's linux drivers and the Windows drivers, at least 
not for 3D, so X11 can't be that bad.

bye...

Re: The new X-Kernel !

[D. Stimits]

Tim Jansen wrote:
> 
> On Sunday 21 October 2001 21:13, Bernd Eckenfels wrote:
> > Well, it is not a question of moving X or Office into Kernel Space. But
> > current development clearly shows, that some things like Video Card Access
> > need Kernel Support. IMHO the Amount of GDI related Functions in NT Kernel
> > are too much, but X11 is not exactly the Windowing System you can consider
> > well suited for Desktop and Game Use.
> 
> Actually some gfx code has already been moved into the kernel, see DRI and
> the nvidia kernel modules. And AFAIK there aren't any noticably speed
> differences between nvidia's linux drivers and the Windows drivers, at least
> not for 3D, so X11 can't be that bad.

It isn't bad at all. My GeForce I DDR typically exceeds 300 FPS, and
approaches 400 FPS, on 32 bit, 640x480. It goes down at higher
resolution of course, but it is insanely fast compared to tech from just
a short time ago in history. People are reading old information and hear
about the theoretical problems of X11, without realizing direct
rendering works just fine on X11 (it's just a matter of writing the
software to do it, the effort started at a later date than with Win, and
is sometimes crippled by manufacturers hiding information). Even on Win,
bad drivers cause very bad performance. I'd love to see the day that Win
can crash its graphics interface and survive without bringing the
machine down.

D. Stimits, stimits@idcomm.com

> 
> bye...
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: The new X-Kernel !

[Gábor Lénárt]

On Sun, Oct 21, 2001 at 03:20:47PM -0600, D. Stimits wrote:
> Tim Jansen wrote:
> > 
> > On Sunday 21 October 2001 21:13, Bernd Eckenfels wrote:
> > > Well, it is not a question of moving X or Office into Kernel Space. But
> > > current development clearly shows, that some things like Video Card Access
> > > need Kernel Support. IMHO the Amount of GDI related Functions in NT Kernel
> > > are too much, but X11 is not exactly the Windowing System you can consider
> > > well suited for Desktop and Game Use.
> > 
> > Actually some gfx code has already been moved into the kernel, see DRI and
> > the nvidia kernel modules. And AFAIK there aren't any noticably speed
> > differences between nvidia's linux drivers and the Windows drivers, at least
> > not for 3D, so X11 can't be that bad.
> 
> It isn't bad at all. My GeForce I DDR typically exceeds 300 FPS, and

Yes-yes! XFree does not put more extra overhead than Windows ... And even
the first drivers for XFree 4 almost gave the same result as Windows
Turbo GL drivers ... Probably architecture of XFree/DRI/GLX/etc is MUCH
better than Windows! The problem is "ONLY" that there're less GOOD driver
written for Linux/XFree than Windows ... I don't see any major problem
with XFree ... only write GOOD drivers and make vendors release drivers
which are as good as Windows drivers (or better ...)

If someone wants to move more things into kernel space it will cause
LESS driver for Linux since many vendor does not like release open
source drivers (as I said it's because of our non-perfect world :),
and it's much harder to produce binary-only drivers as kernel modules
than let's say XFree drivers. But this is only ONE point. The techniqual
one is also forces me to say that keep as much things in user space as
possible (of course without major hurting in performance ...).

- Gabor

Re: The new X-Kernel !

[Dwayne C. Litzenberger]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

On Sat, Oct 20, 2001 at 10:30:00PM +0100, MichaelM wrote:
[snippage]

Am I the only one who thought this was a smug joke?

-- 
Dwayne C. Litzenberger - dlitz@dlitz.net

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: The new X-Kernel !

[Jim Freeman]

On Sat, Oct 20, 2001 at 10:30:00PM +0100, MichaelM wrote:
> People need a nice stable Operating System for Desktop and Multimedia
> purposes and this doesn't exist. We should create a new stable X-Kernel with
> build in support for X. Pressing Alt-F1 a console should pop up.

Name's already taken?

	http://www.cs.princeton.edu/nsg/xkernel/


And a successor project that targets multimedia, and has some Linux
support?

	http://www.cs.princeton.edu/nsg/scout/