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.
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
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.
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
> > 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: [email protected] (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.
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
> > 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: [email protected] (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.
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.
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...
> 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
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
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
> 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.
> > 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.
> 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.
> > 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.
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...
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...
In article <[email protected]> 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
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...
On Sun, Oct 21, 2001 at 09:13:17PM +0200, Bernd Eckenfels wrote:
> In article <[email protected]> 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
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
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
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
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...
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...
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, [email protected]
>
> bye...
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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 :: [email protected]
Network Administrator :: The Leather Collection, Inc.
GnuPG Key: <http://jijo.leathercollection.ph/jijo.gpg>
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
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: [email protected]
[mailto:[email protected]] On Behalf Of G?bor L?n?rt
Sent: Sunday, October 21, 2001 3:04 PM
To: john slee
Cc: [email protected]
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
-
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
> 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
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
On Mon, Oct 22, 2001 at 01:44:23AM +0400, Samium Gromoff wrote:
> folks, let`s end this stupid thread...
OK, I think you're right. Please do not answer at least to my letters
on this topic (maybe in private :) But this was a funny thread :) though
it's not strictly related to the borders of this list imho.
- Gabor
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...
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
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.
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.
--
................................................................
: [email protected] : 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}...............:
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...
> 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.
The Right Way To Do Graphics, According to Dan (tm):
----------------------------------------------------
1. kernel driver accepts buffers of drawing commands from user-space clients
and sends them to graphics card via DMA. Also provides interface for clients
to allocate pieces of video RAM. Also maintains per-client graphics engine
state that is context-switched as necessary; textures and framebuffers are
demand-paged between system RAM and video RAM. Also provides "global"
controls like graphics mode switching and hardware
cursor position.
(DRI does most of this today)
2. user-space library maps from a convenient platform-neutral API (i.e.
OpenGL) to card-specific buffers of drawing commands.
3. user-space window server process owns the only visible framebuffer in
video RAM. Clients give the window server the address of their private
non-visible framebuffer and wake up the server whenever its contents change.
Window server assembles the visible desktop by blitting client framebuffers
to the visible framebuffer. Window server also dispatches input events
(keypresses/mouse clicks) to appropriate client processes.
(this is basically how Mac OSX works, except OSX does most of these
operations in software so it is very sluggish)
Advantages of this approach:
1. clients running on the local machine get full DMA access to the video
hardware.
2. window server can do real alpha-channel compositing (true
transparent/non-rectangular windows).
3. slow/crashed clients can not harm the window server or other clients.
4. clients don't have to double-buffer because the window server does it for
them.
5. full-screen clients (e.g. games) can be allowed to usurp the window
server and get direct access to input devices and video hardware.
6. to achieve network transparency, a "stub" client can be written that
sends input events and receives drawing commands over a socket.
7. GUI toolkits can offer a retained-mode API that maps high-level commands
(e.g. "draw a button") directly to graphics hardware, instead of long, slow
X protocol streams.
i.e. this system provides a superset of the features we have today, because
it is a "meta" windowing system where every client is equivalent to an X
server or a DRI client.
Disadvantages:
1. would probably require >$1 million investment in software engineering to
implement, could not be done as a free product.
2. demands a sophisticated resource-management system to demand-page
fine-grained resources to and from the video card; may not be fully
implementable on today's graphics hardware.
3. only a single graphics card vendor provides (partial) documentation for a
card that is fast and functional enough to make this idea interesting (ATI).
4. a translation layer would have to be written to emulate X for legacy
clients.
5. Linux/UNIX people mostly don't give a sh*t about good graphics.
Regards,
Dan
>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..
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:[email protected]]
Sent: Sunday, October 21, 2001 4:53 PM
To: Sean Cavanaugh
Cc: [email protected]
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
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: [email protected] (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.
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 - [email protected]
> (DRI does most of this today)
Your description of DRI is btw mostly wrong.
> 2. user-space library maps from a convenient platform-neutral API (i.e.
> OpenGL) to card-specific buffers of drawing commands.
Its called X11
> 3. user-space window server process owns the only visible framebuffer in
> video RAM. Clients give the window server the address of their private
You might hae numerous visible frame buffers
> 5. Linux/UNIX people mostly don't give a sh*t about good graphics.
6. More likely Dan doesn't know **** about real graphics hardware ;)
Alan
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...
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: [email protected] Kenilworth, 7700
Http: http://www.2d3d.com South Africa
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.
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: [email protected] Kenilworth, 7700
Http: http://www.2d3d.com South Africa
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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
From: "Abraham vd Merwe" <[email protected]>
>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.
> > 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.
> > 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.
> 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.
James Simmons <[email protected]>:
> > 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.
I may not have been complete -
Your initial example was of a force feedback mouse (or data glove), where
the process that has the device open dies.
Between the process failure, some other process (not owned by the same user)
may modify characteristics of the device in an inappropriate way. Then the
original user starts using it again.
Resource allocation requires the device to be initialized to a base, known
state. That state MUST NOT be modified by session other than the one that
allocated it. The driver may or may not be currently "open" by a process.
It is a security violation to leak state information or to have that state
information modified by any but the owner of that state.
Some "devices" (like the Xserver is a device), already do this. If the
attached allocator (the X login) becomes inoperable (X server dies), then
the state of the device is reset (logged out), and allocation of the "device"
reclaimed (logged out in this case). All physical devices associated with
the X server must also be reset (mouse/keyboard/frame buffer...).
Resource allocation is easier to visualize when it is a tape drive.
The actions of a resource allocator must/should be:
1. initialize the resource/device to a known state.
2. control access to the resource/device (prevent access).
3. be able to grant access to the resource/device to user sessions.
4. prevent multiple sessions from accessing the resource/device
simultaneously.
5. reclaim the resource/device (abort all outstanding access) and
return to step 1.
Some procedure (as outlined, though not complete) would prevent your
"state" misconfiguration where multiple users had access to a single user
resource (tape, mouse, keyboard, data glove, etc).
I've already had to deal with "inadvertant" use of state information leaking
across sessions (audio devices). Personally, I think it is time for a resource
management system.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
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...
On Mon, Oct 22, 2001 at 03:33:07PM +0100, MichaelM wrote:
> From: "Abraham vd Merwe" <[email protected]>
>
> >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
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 | (http://www.brainbench.com)
U chaos and madness await thee at its end."
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.
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.
> 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/
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 | (http://www.brainbench.com)
U chaos and madness await thee at its end."
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/