I may me just humble Linux user, but I'm a Linux user since 0.96 times :)
And I've always rejected patched up kernels that some distributions
seemed to rely on. I've to mention, that I've no connection to the
GGI people. (perhaps a unhappy feeling with the current system, where
I've a box that freezes completly sometimes when I switch from X to text,
no clean reboots from the net, just flipping the power switch *g*)
> I won't answer to any of the individual postings, but I _can_ try to
> explain my own personal standpoint, and at least let people know _why_ I
> think as I do.
I basically believe and understand it. But: One should reevaluate his
position.
[...]
> - I have always seen my job as kernel maintainer to be acting as not
> only a developer, but more importantly act as a _filter_ for others.
> That has obviously become more and more important over time, as my
> personal development effort has been more and more superceded by
> having tens of other kernel developers.
We know this. And you are doing still a marvelous job :)
>
> As such, my most important function is to say NO! to people. This
> continually surprises some people, as they see a very rapid pace of
> development, and often huge patches on a weekly (or even daily)
> basis. However, there are a few things you should realize:
>
> - I usually don't say no to driver development and stuff that
> doesn't impact anything else. If a new disk driver is broken,
> it can't be any worse than not having a driver at all, and even
> a broken driver is more likely to receive attention than
> somebody having to start from scratch.
Right a driver is better than no driver :) However buggy, it will add the
given item to the ``allowed'' hardware shopping list of some ppl, more
testers, better code are the result. The only risc are early converters
that could missunderstood this for ``Linux is crap''.
> - There's often a backlog of patches that have been floating
> around for some time, and they have often had quite a bit of
> feedback from me before they actually make it into the standard
> kernel. Usually they have also had a longish period of real
> use by real users.
Another painful but good idea. This way the patch is tested, the ppl get
some time to think about it, and the kernel is not bloated by defunct
patches.
>
> - I don't see the world in black-and-white. I don't actually like
> Linux-only features unless they have a good reason for them, and I
> really like Linux to be a "standard" system (with reasonable
> extensions where they make sense, but they really should have either
> minimal impact or be _really_ sensible in somethign that there is no
> previous standard).
>
> The world would not be a better place if Linux were to be the only
> operating system out there, and we should play along with established
> standards if we can and when that makes sense. From the very
> beginning of Linux development the whole idea was not to create a
> Linux-centric world, but to create a good operating system that
> worked with what was already there. Much of early development was
> not modifying applications to suit Linux, but to modify Linux to suit
> applications.
Correct. But for graphical console handling there are no REAL standards.
And these don't have to deal with the PC hardware variety, including
2d and 3d acceleration. So a clear cut may be a good idea.
Especially as the libGGI subproject is not at all Linux specific:
It works on top X, svgalib, KGI, at least, and it will even work on top
of Win32 systems.
libGGI is in some way a possibility to create a huge interoperability
standard.
>
> - Finally: I'm flexible. I can be convinced. But I am almost _never_
> convinced by rhetoric: I'm completely unmoved by people arguing about
Ok, I don't want to start to convince you about CGI. The problem that I
seem to see is about communication. CGI is a huge project, and it probably
went to early public, and made some mistakes in the course, but on the
other hand, I'm seeing rejection based on name developing on the kernel
list.
> I may be cynical, but there's way too much hot air on the internet,
> to the degree that I don't believe in anything that I set sent in
> email or see on the internet before I've actually seen some real
> action. "Show me the code" can convince me, but "wouldn't it be nice
> if" has absolutely no power over me.
Than perhaps the fact, that CGI is working for a real long time now
producing code (even patches for the kernel), may help you :)
>
> Ok, with that not-so-short preface, I'll tell you a few reasons for why
> I have been less than entusiastic about GGI:
>
> - I think that X is good enough. Yes, X is larger than some people
> like, and it could be faster. But X has a lot of good features that
> make it better than any of the alternatives I've seen so far. I
> never much cared for the original SVGA-lib, and the GGI people seemed
> to be more impressed with SVGA-lib than with X.
X is good enough. But the implementation is NOT. It is not acceptable that
a X server crashes one box completly hard when switching to the text
console. Less because it bothers me (and fsck 8.5GB doesn't help), but
what if this happens to a newbie that turned to Linux for stability.
[This aside, I'm also a BIG X11 fan :) It works, it's standard, ...]
>
> Yes, there are older and smaller machines that don't run X all that
> well, but I refuse to let those kinds of machines set the Linux
> design decisions. I think SVGA-lib is the correct solution for thise
> kinds of setups, and for anything remotely modern X is the way to go.
> I want to think about the _future_, not the past.
Right. And beside I've run textmode on a 486DX/25 8MB for a long time
and switched to X11 only for previews. Worked ok then.
>
> Again, I can be convinced, but I need to be conviced by _actions_,
> not words (and "new graphics cards don't come with support in
> SVGA-lib" is not a very good argument, even though I've seen it
> multiple times. New graphics cards are usually plenty good enough
> for X).
The problem is, that new graphic cards are not really 100% supported by
X. (Example: Where is the 3d acceleration?)
>
> - I'm distrustful of projects that do not have well-defined goals, and
> well-defined interfaces. They tend to bloat and do "everything" over
> time. This is what gives us horrors like GNU emacs and Mach: they
> don't try to do one thing well, they try to do _everything_ based on
> some loose principle ("LISP is good" or "microkernels make sense" or
> "GGI should do graphics")
It's not like this. KGI just states, that the kernel probably should know
much more about the hardware state of the display than it knows now.
(I hope that you can support this notion. :) )
> - I've seen more arguments about GGI than about anything else. That
> may be because the issue is so muddled, but the point is that it's
> not endearing me to the project. There's a lot of [mis]information
> floating around, and the whole _issue_ is muddy. I don't think that
> leads to a good design.
CGI isn't muddy. The problem is that they went very early public, so to
say during their design phase. (And really muddy it got, because there
was some experimental code floating at that time.) The problem is
misinformation, and misconception. Or to put it differently, the ppl
associate with graphics in the kernel/OS somehow a certain bootloader
from redmond. [Interesting thing is, that they never see, that XFree
without full cooperation of the kernel is very similiar to the Win3 hack
of layering graphics on top of something else. Hmmm. It seems that the
quality of the layered components (Linux+XF86) are making the difference
*g*)
> Anyway, I do believe that graphics support is extremely important, but I
> think that doing it right is more important. And I'm not going to jump
> head-first into anything that would be very hard to back out of before I
> _know_ it is right.
What about allowing small optional KGI support in 2.3.x? At the moment I
only see one project that addresses:
- security. (Giving a user level program the possibility to hold IRQs
isn't that much of fun :( )
- stability. (The kernel should contain the core of the graphics driver,
so it knows what is happening. Or at least so it can
reenable interrupts and panic via the standard methods.)
- acceleration. (Basically using the ``full'' potential of the card over
the kernel/userlevel wall.)
- portability. libGGI, the programming interface runs on top of many
systems, including X, svgalib, KGI (and coming Win32).
I think that especially stability and acceleration are important things
for newbies: (I've been more and more often in the situation to
explain/defend the Linux way to newbies fleeing from the
enemy :) )
* stability, because stability is one main selling point for Linux. And it
doesn't matter for the newbie if the new prealpha AGP X
Server locks up the system or the kernel.
* accel, that's what the people see after installing. Does the thing take
2 seconds to build the 1280x1024x24bpp image, or goes it in a
snap?
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu