> Andrew: First of all, please consider the following not a critism of
> yourself, nor your views, only that I suggest one "learns before they
> leap".
I always try to learn, and I did learn a couple of things from your post
(eg, the single mode from lilo. I'll give 'em a go soon). I'm just trying
to suggest some better ways, sometimes using imprecise language, which
occasionally masks my own skill set. Which is what everyone leaps upon
instead of what I'm really trying to suggest as an improvement.
> Secondly, please pardon this post to the mailing list, I feel, personally
> do not have the patience to teach someone that you dont make a square peg
fit
> into into a circular hole with a hammer, dor because it has a keyboard
and
> is called a computer, is a vic-20 comparable to a cray. (Apparrently
clues
> have the same noted hammer effect).
the cluefactor approach... netiqette would have suggested mailing me before
hand (I would have given permission, btw).
You assume too much about me in terms of clue factor (ie that I have no
clue and just another dumb user who has pretensions to kernel design and
hacking), and I've certainly overstepped the mark in the previous private
post about your clue factor. I'm sorry for that, and I want to raise the
level of constructive criticism. Let's just say that I've got industry
experience in differing areas than yourself. You've been on the list a
longer time than me, and have seen all these arguments before and leave it
at that. I don't see the need for heavy flaming when we're all intelligent
people, with much more than the average clue factor.
> Again, Different operating systems, different applications for each. Unix
> is based around being able to use the machine's CPU first, and any
> secondary graphical functions next. X is a protocol, it is graphical.
That
> still eludes to unix is not based graphical and to be so blind as to out
> some VGA proprietary code in a kernel not limited to the x86 shows
> stupidity, of course if we add the Sun/Alpha code for a similar thing to
> add a pretty 10 second flashy screen, and increase the kernel by more
> than 10k, we have lost.
If the user is primarily interacting with a graphical environment, the CPU
should be spending time dealing with the graphics side. The cool thing is
that with modern accelerated chipsets, less CPU time is needed. The other
cool thing is that with pre-emptive multi-tasking, a lot of spincycling can
be avoided, and other useful work done. With multi-threading, the machine
appears more responsive than it actually is, and can scale in a SMP
environment. One of the things you'll notice is that when users are
involved (ie visualisation, productivity apps, and general stuff), most
times a graphical desktop metaphor environment is used. Whether it be Win95
(urgh), mwm & CDE, fvwm or derivatives, MacOS, WinNT, etc... the main
reason that people use graphical environments is that, on the whole, they
are easier to interact with, faster to do most stuff, and generally more
productive. CLI's have their place, and I do not diminish that. There are
just better ways to do things. Linux in a desktop environment would benefit
from a completely graphical approach, one that can be escaped from for the
die hard administrator hampered by inadequate or non-existant graphical
tools. I for one, would appreciate it a graphical version of fsck and
formatting tools that took the guesswork (and hard work) out of
partitioning.
With PCI being adopted on a wide range of hardware (DEC Alpha, PPC, Intel,
some custom hardware (BeBox), and new versions of the PC specification
(PC97, NetPC), I'd say that PCI video adapters will soon become almost
universal. Then of course, there will be the newer cards that function with
Intel's new AGP bus, but they will be SVGA derivatives. If you get 95% of
the video adapter market, then you have succeeded. If you modularize and
design your interfaces properly, a small driver re-write gets even that
last 5% supported too (say those who have a herc adapter, or DEC TGA
adapter, or Macintosh on board video).
Linux's boot time on my PPro 150 is roughly 30 seconds from the LILO
prompt, and my machine is no slouch, nor do I load unnecessary drivers. If
your machine is booting in 10 seconds, it must be pretty fast, or have few
files or partitions.
I'm not suggesting that graphical boot mode becomes mandatory; just that an
option to do so might encourage more Linux use. The more it gets adopted as
a corporate desktop, the more jobs that are likely to be available to
people like yourself and the other "clueful" Linux hackers.
What's 10 kb? Nothing. Nada. It's less than 0.000001% of my disk space.
It's less than 0.00001% of my physical RAM space. If the kernel was paged
or if it were a user mode program, it'd be swapped out if necessary, or
simply discarded after exiting.
In XFree, we write our drivers in C to be fairly portable. The DEC alpha
guys use almost all of our code, unchanged. There are about 2 extra
defines, mostly to do with padding to make it 64 bit clean. There is a MIPS
guy working on our code, and he's not reporting any problems yet, and the
BeBox (PPC) linux guy is having no problems either, although I haven't
heard from him in quite a while. It's also the fastest Xserver in town on
PC hardware, and gives many highend workstations a good run for their
money. By choosing to write portably, by using excellent algorithms and
minimal numbers of instructions, we have achieved what the kernel needs -
stability, extensibility, flexibility, portability, accuracy (no use in
rendering the wrong stuff), modularity (wait until you see 3.2B), and most
of all speed.
> > MacOS has never had a textual mode.
>
> The apple macintosh was not created with a text mode. The PC was, as was
> almost all unix systems. We are not dealing with Macintosh here.
> > NextStep has a
> > graphical boot, and no one complains about that being single user.
>
> This was the design of the NeXT System. See above.
Someone once said (and I'm paraphrasing here), that if you ignore a child's
advice simply because that person is a child, you are missing out on some
potentially good advice. What do I mean by this? Just because something
works in a completely different way to what happens now does not mean you
cannot possibly adopt some of the good points of another paradigm. What is
so wrong with adopting a no-fuss approach to computers? A good computer is
an invisible one IMHO. I prefer things to work for me, which is why when I
really want to do work, I use a Mac, as although it isn't perfect, the OS
gets out of the way so I can use its tools. When I want to get down dirty
and talk to hardware, I hack XFree and code for that. Right tool, right
job. But, there's no reason for Linux to quite so difficult as it is.
> > For many
> > of us, we boot straight into X. [snip]
>
> Then why not just comment every printk() out of your kernel code? If
thats
> what you want, go ahead. I personally find the status useful, especically
> considering I use more than one machine and do pay attention to the
> hardware within, rather than attempting to hide all technical knowledge
> and specifications for the related device, unix is not designed like mac
> "never see, never do" interface. It is very touchy and very picky. I want
> too see how its enabling my hardware. Why should a pretty splash screen
to
> mesmorise one to not see what the actual level is used, while just adding
> bloat to the actual kernel?
I wasn't saying to completely mask the text mode - sometimes you do need
that, or a replacement, like the Mac's notification manager, or NT's Event
Viewer. Otherwise it's hard to debug a problem. If something is simpler,
though, it wont need so much debugging. This is true at user level as well.
The worst thing that happens on Macs is that they crash (sometimes a lot)
if a bad init/cdev is installed. Sometimes these startup extensions
conflict with each other (say two virus protectors were loaded by mistake).
On the Mac it is truly trivial to rectify this. Under NT, it gives you
staggering amounts of information about what went wrong, and as long as you
know which device or driver failed first (ie the earliest warning or error
message in the log), you can usually sort it out pretty quickly. Under
Linux, this is not the case. End users care about results and whether they
can affect them. Linux is going through a painful transition phase from
hacker toy to serious business tool. Many web servers are Linux boxes and
do serious amounts of work. As part of this, for better penetration into
semi and non-hacker desktops, Linux needs to be easier to administrate,
work on, and generally install. The last part has been dealt with by
commercial companies (most notably RedHat, whose graphical installer is
fairly good, although a little complex and feature poor by my standards).
The kernel list need to address a couple of the other things, which is why
I posted there, instead of sending a feature request to RedHat, Debian,
Caldera or one of the others.
> Ok, you are a programmer, if you notice, this was a generally stated
> comment, Andy, and was not directed at you personally. This message here
> is. You have progammed commercially. Congratulations. So have I for both
> the PC and Morotola platforms, mainly proproetary inline OS-on-a-chip
> programs, not hypercard&c hacks of database systems or whatever. You do
> seem to know about the Macontosh, please study on the systems linux is
> designed for before making a statement that it should be "just like mac".
I never made the point that Linux should be just like Mac, as MacOS has its
shortcomings. I've not done Hypercard development (except as a tool for
user interface mockups, which it is very good at sorting out ideas with a
customer before committing resources). I have a Mac next to my home PC
workstation which I use as my serial console and various other things. At
work, I have a 7600/120 on my desk with my pathetic P133 NT box. If I
wanted Linux to be like a Mac, I'd just shut up, unsubscribe and use a Mac.
If I wanted 95, or NT, similarly. I'm going to be installing NextStep soon
as there are likely to be some projects coming my way to port Mac programs
to the yellow box. The raison d'etre of my being on this list is to maybe
provide some fixes for my hardware (pci problems, etc), and maybe soon
power management, and maybe just point out that there are better ways to do
some things. It's obvious that the list doesn't really want to know about
these better ways, which is a shame. I've read a lot of David Miller's
posts in the linux-smp archive, and he seems a pretty intelligent guy, and
definitely knows his stuff. I downloaded a paper he suggested about
parallization of TCP and UDP protocols. I read and understood the paper,
but as yet, this work hasn't shown up in linux code. The speedups were 12x
for UDP and 3x for TCP/IP assuming enough processors were free (the authors
used 20). This is the sort of stuff we should be doing, not attacking new
ideas because it hasn't been done in the past.
> what good is a cpu and task
> wasting ugly bloody splash screen? What does it contribute to the kernel
> other than "our boot loader looks cooler"? Nothing? Oh. Then stipulate
why
> it "needs to be part of the kernel", although it has no function.
Okay, say you spend 2 seconds on the bootscreen display (a complex png for
example). Why does it waste CPU time after it has finished? It doesn't.
Could this process work in the background whilst the CPU is I/O bound doing
the rest of the boot? Yes, definitely. Would that 2 seconds add 2 seconds
to the boot process. No. It would add some, but not all of the time you
claim would be wasted. Would a user notice 1 and a bit seconds? No. They
don't boot Linux every day like I do. Or if they do, at least they aren't
bombarded with stuff that may confuse them. For those that love the text
display or the graphical display doesn't provide the information they need,
they either don't install it, or they can use the graphical display's get
out of the way key (escape on 95, and I see no reason not to use it under
any graphical boot manager).
It doesn't need to go into the kernel, except for maybe the bootsector. It
would be nice if the idea had kernel hacker's blessings, but this seemingly
will not be forthcoming. So even if I did finish the project before my
annual leave finishes in two weeks, or sometime down the track, it's so
unlikely to be widely adopted, that I may as well stop now, and save
everyone the hassle. That's why I've been trying to kill the threads as
they were unproductive.
> You want NeXTStep, my friend. UNIX is still based around "30 year old"
> hardware limitations (text is a limitation?). If you want something which
> is not this way, and is graphical by design, you want another kernel.
The irony is that NeXTStep is based upon BSD 4.3, with Mach microkernel
underpinnings. It is unix, and many posix and older 4.3 code ports easily
to NextStep. But good Nextstep apps use the OpenStep API, which is
graphical in output (although there are a large number of useful classes
underneath that which help you re-use common algorithms, like collections,
etc). Unix doesn't need to be text based. In some situations, it is a good
idea (unix as router, terminal concentrator, etc), but on the desktop, text
mode is dead. You can't even buy a text mode wp any more (although I'm sure
many emacs adherents would claim that this is not true).
> > They should be using a second stage bootstrap to allow any
> > size kernels, although if modularization was done properly, the kernel
size
> > issue will die down.
>
> Perhaps your programming skill would be better wasted for such a project,
> rather an arguing why the kernel boot sequence should be "graphically
> enhanced", not to mention not all systems are VGA, and X is STILL a
> protocol. VGA just happens to be your adapter. You suggest we sense if
> someone has a vga and just seize it for graphical use? This is exactly
why
> I made my previous post.
I don't have enough long term time to commit to such a project (making a
second stage booter to allow any size kernels). Anyway, given the
environment, many people are so against kernel bloat the argument would
run, well, if everything was a module, we'd not need a big kernel, so
you've wasted your time.
The idea is to give console access up for X or GGI (or Berlin, or
whatever). The boot program has served it's purpose as soon as the
graphical environment starts to load. The really dedicated user can use
dmesg and /var/adm/messages like I do now, as most of the boot text I see
scrolls too quickly to be of any use anyway.
> I would like to see a Macintosh (*lets say LC class*) running MacOS host
> my four vt220 terminals, NFS mount, web server, name server and a
firewall
> for my other box. What? it cant? Oh.
Simple - use MachTen or NetBSD. It could do what you ask, albeit slowly. So
would an equivalent PC - a 286/16. You'd need to find some support for a
four port serial board or use a terminal concentrator. Since Linux doesn't
run on such slow hardware (it's 386 and above) it's not a fair comparison.
A 386/16 or 25 is not a good machine for four users, nfs mount, web server
and firewall, and neither would be a SE/30 or a LC III, although I have
used an SE/30 in the past using A/UX 3.0 as a firewall and web server and
name server. I have a friend who runs NetBSD 1.1 on his Mac II (a 16 MHz
68020) as a firewall/router (10Base-T to 28.8 PPP connection), and
ghostscript lpd for his internal network, and it does the job quite well in
16 MB. He uses fwtk for proxying and squid for caching. It's nice. And slow
as a wet week - tcsh 6.0.4 took ages to compile. He doesn't use graphics as
16 MB is not enough and not necessary in his case. I wouldn't force any
user or administrator who doesn't want a graphic boot to use it. It would
be nice to have the option, though.
If you didn't want the serial terminals (MacOS is practically single user,
remember), then there are best of class name servers, web servers, nfs
products, and OpenTransport does a good job of routing for you. There is a
competition on the net at the moment to try and break into a Mac web
server. There's $10,000 US dollars riding it, so I'm sure there are many
takers, but no winners yet. Security is a lot simpler on the Mac.
> Better way? I keep good backups, and when need be, I use them. if you
> screw up your libraries, that is just the way of unix. I do think that
you
> are not comfortable with the design of unix, and feel that NT is an
> operating system you will continue to find happiness in for many years to
> come...
NT has the same problems (and more) with it's libraries (and versioning). I
also keep good backups, although I rarely use them in anger. Most of the
time fsck and chkdsk do their job.
> > Why isn't
> > there an easily enterable single user mode under Linux when almost
every
> > other Unix (and unix look alikes) have one?
>
> There is: I assume you are speaking of the PC linux here.. when you see
> the LILO prompt, type single and press enter. Scarey shit, this
> configuration sans pulldown menus. of course, when in multiuser mide, if
> using SysVinit, type "init S" (the S means single). Crazy.
> Uhm.. there can be if you learn a minimal amount of programming in shell
> scripting. or better yet, easy way that you should understand... mv. mv
> the rc scripts and execute them manually, or execute each remark
manually.
> oh, doing that is a waste of time, you say? thats what is required to
> properly initialize your machine for useage.
I learnt something even from this post (the bit about lilo - I really
should look closer at it). Thank you. I knew about the init S bit, I use it
occasionally to kill off my rampant or dead X sessions.
I don't want to execute the individual bits of the rc scripts manually, I
want to step through them, skip past dodgy drivers (or support for
non-existant hw, etc). I know bash does the rc script processing, and I
know how to program sh (and csh and derivatives, like tcsh). I think using
the SysVinit stuff with single stepping and skipping will require bash
modifications, not kernel modifications. Again, might be stymied by bash
developers. (Might introduce security bugs, for example).
> I am not preaching that you should learn some worthless knowledge that no
> one gives a crap about, I am stating basically that rectal-cranial
> inversion is cured by studying the design, and the useage of an operating
> system. Let me suggest a book, which I have found most useful. "Operating
> System Concepts (3rd edition)", By A. Silberschatz, J Peterson and P.
> Galvin, ISBN 0-201-51379-X. Please read this before posting, defending
> your "right" to a graphical pretty-boot feature, while not yet knowing
the
> basics of shell scripting.
I have not yet used the word "right". I've found in the freeware world, the
things that get things done are: people actually doing the code instead of
just yabbering b) adoption of aforesaid code
Unlike in the movie, if you build it and they will come is not always true.
See OpenDoc for an example of an excellent technology that's just been
killed because no one came. If I can't convince you guys that this is a
good idea, it wont be adopted into distributions, and thus it would have
wasted my time, and your time.
I've done the OS design subject a few years ago, when the prerequisite book
was Tanenbaum's excellent book on OS design, which used Minix to illustrate
features, which from whence Linux came. Most of the things I've suggested
so far have come to naught, and arent't covered in these sort of books
anyway. I'll check out the book you've suggested, as it might contain
something I don't know, and as I've said, I like to learn. I've always got
room for another book in my technical library.
Most of the time, I've been suggesting different approaches that improve
stability or improve speed by looking at what you're doing and improving
the methods that you use, not shaving nanoseconds off poor algorithms or
good algorithms hampered by poor data design. If you can speed a routine up
by (say) an order of magnitude, then you've saved a lot more time than a
few cycles here and there. Examples of choosing the right method: avoiding
linked lists, unless it makes excellent sense. If you have ordered data,
make sure you use the best algorithm to access it. Avoid built in limits -
it really pisses users and administrators off. Design your data structures
with portability and extensibility in mind. Design your data structures
with current caching strategies and limitations in mind (ie avoid page
thrashing, data traversal, etc).
I don't care if my machine, capable of nearly 150 BogoMIPS (and I know just
how bogus that is), spends a few microseconds resizing the kernel's memory
structures to avoid a crash. I want something that's stable, extensible,
and fast (in decreasing order of priority, left to right). What's the
problem with that?
Andrew