Slashdot Mirror
Linus Says No To Annoying Boot Messages
Pants Ripper writes: "In a victory for all Linux users, Linus Torvalds declared jihad
on annoying 'informational' kernel boot messages. I'm sure we'll all miss the inspirational 'spewtron driver 0.09 installed (C)2000 by Wardwick Extrusion' messages in our dmesgs." I've always thought those messages looked pretty interestingly verbose, but people want pretty boot-ups. And this Linus guy seems to know a lot about this "Lee-nuks," too.
Okay, it's obvious that the Great Ship Linux is going down. Between VA's decision to *ahem* get out of the hardware business and all the IPOs tanking, it's time to expand the paradigm. Why not keep the boot messages, and sell ads?
For instance, instead of getting messages in your inbox about mortgage, it would display while the kernel boots up! We could also make it fsck each time, to increase the impact of the display.
Also, with SVGA mode, we could have graphics.
And therefore make money off of the only profitable internet business--porn.
Each time you connect to the internet, Linux could unobtrusively download a new set of ads for various services and websites. It's about the only way Redhat and VA are going to stick around.
If the suggestion was to make the statements display only display if in a special verbose booting mode, that might be reasonable. Killing all messages, always, that's just dumb.
--
The whole "real men grok the code" idea is just arrogant and stupid. If your goal is to hack on the kernel, then yes you need to understand it deeply. However, if you just want to figure out why your linux 2.4.5 machine just panic'd after loopback mounting an iso image, then all you really need is a kernel debugger and some basic software engineering skills.
--
There's no way to put a large amount of text on screen atomically, thus if you have code with a bug that's getting called repeatedly you have a choice of:
I stand by my assertion that linux makes kernel debugging unneccessarily difficult, asserting the arrogant notion that only total kernel hackers know how to find or fix bugs.
--
Quite a neat hack, considering that the bytes used to hold this state were appropriated from the end of the space normally used to hold the application name once the system boots.
On Mac OS X, where there are no extensions, the only visible messages are a single-line caption in the middle of the boot screen that flicks through a couple of high-level tasks ("Starting AppleTalk", etc).
-dair
If you read all the way to the bottom, he talks about removing the "good status" messages as well. This means if a driver loads fine it won't show up in the boot sequence. Some people were expressing concern that they might leave old cruft in their kernel (drivers for hardware they don't have, and pseudodrivers that aren't useful anymore) and not notice it. Some drivers report if they can't find the piece of hardware they're looking for, but I belive some are silent other than the informational messages (version foo copyright so and so messages).
Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
I read the internet for the articles.
FreeBSD has an option (although it is disabled by default.) to display a boot screen (similar to windows). IIRC, the boot screen can be dumped for the regular boot message by a flag to the loader, or by simply pressing escape during the boot (unless your error is: atkbd0: Error failed to initalize keyboard...
Really, what Linus seems to be annoyed at here are the excessivly verbose messages that some drivers like to print out (like I need to see the algorigthm benchmark each time I boot) that might drown out an important message by scrolling it off of the screen before you see it (although it should still be available through dmesg, just like the FreeBSD boot messages are still are even when you have the "graphical" boot.). The Linux boot sequence is getting a bit heavy on the pointless informational messages these days, so a bit of a pruning won't hurt too much.
Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
I read the internet for the articles.
Attention, We-Want-Linux-On-The-Desktop crowd: Support this and help out, it is a big step in the right direction. To a consumer, diagnostic messages are confusing and pointless. Admit that Apple did something right, for once (interpret that as you will): the Mac OS, up to and including X, will never show cryptic messages or break out of the GUI unless you give it a direct order to do so (launch Terminal or Console, hold down key sequences during boot) or a fatal error occurs. This is a good thing, it makes the experience seamless and friendly. Remember that consumers don't care about what drivers got loaded when (and isn't improving the drivers themselves a much more important goal than improving the error messages?) and similar arcane knowledge of the computer's internals, and saying "learn it anyway because it's good for you" will not win you any friends or customers.
Whadayathink 'cat /proc/interrupts' is there for?
There are two ways a driver could "fail". One is to try to do something and fail, the other is to never get called in the first place because the kernel didn't recognize that the hardware was of the appropriate type for that driver to be called. It would be handy to tell the difference between the two. Today you can because today if the driver is being called you will get either a good or a bad message, but you know you will get *something*. If you see no message, then you know it didn't even *try* the driver in the first place, and that helps you figure out the exact type of error you are dealing with (probably a driver that's older than the hardware, so it doesn't recognize its ID string.)
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Read all the way to the bottom. He also rants about not wanting "yup, I worked" messages to show up either. I agree about the copyright and version numbers, but NOT about pruning the "it worked" messages. Take them out and now "This driver worked just fine" looks exactly the same as "The kernel never loaded this driver in the first place." When you are trying to figure out why some piece of hardware doesn't seem to be working, that is a relevant difference.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
I agree with getting rid of ads and versions, but NOT with getting rid of good status messages. The difference between a driver being silent because it isn't even being loaded in the first place and a driver being silent because it was working okay is a HUGE difference. It's something I want to know when I'm trying to figure out why I can't get my new WidgetMasterProBlaster device to work.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Why not just use /sbin/lsmod to see which drivers are loaded?
If you do that and see that a driver is not loaded, can you tell the difference between that driver not being loaded because it failed at start-up (didn't see the right hardware), vs that driver not being loaded because the attempt was never made to do so?
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
I think what would be nicer is if everything used a common way of presenting information. Each driver that gets an IRQ or something has a different wording for telling you which one it has, and some drivers' messages sound like they might indicate errors even when the situation is pretty normal and supported.
I'd much rather see a list of:
driverx.c Driver for X on IRQ n DMA m
drivery.c Driver for Y device not detected
so you could see, at a glance, what stuff is in your kernel, what is actually active, and how it autoconfigured itself. Currently, you have to look through the messages for the one that applies to a misbehaving device, and then sometimes look at the driver source to figure out what the message means.
In my case, that gives:
Now tell me again exactly why you need the version printed at boot time?
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Well, Linus is wrong.
Error messages only occur when there's an errror.
What if there's no error, what if it just HANGS on boot?
How the hell are you supposed to diagnose a hang if you can't see what's running?
--
Andrew Oakley - www.aoakley.com
No, it tells you that Windows installs every frickin protocol under the sun when you pop in a new network card, and it just sitting there waiting for a nonexistent DCHP server.
--
Andrew Oakley - www.aoakley.com
Actually, he is. One of the big quandries about the graphical boot project was how to display all of those various informational messages. Some drivers' licenses (particularly non-Free ones, for example, for certain graphics cards) require that the message be displayed.
Imagine that you're the one writing the graphical boot. How do you decide which messages to display and which to skip? If Linus had his way, and no unimportant messages are printed, then the task would be much easier.
Dewey, what part of this looks like authorities should be involved?
--
Care about electronic freedom? Consider donating to the EFF!
I personally have done a little kernel programming, and that is the only time I paid any attention to these messages. Every other boot ends up with me just looking at the screen with glazed over eyes, not a single message registering. When things go wrong, those messages are invaluable, but if the kernel can't get it's debugging messsages on the screen during a catastrophe, there's not much chance that dmesg would help anyway.
I've always thought those messages looked pretty interestingly verbose... The more I think about that sentence, the more my head hurts.
Yes, I'm still a junky. Are you still a bitch?
There are two problems here - first, fluff like copyright information is being printk'd at too high an importance level, and second, the minimum level for display defaults to KERN_DEBUG (lowest level). The changes being proposed are that fluff should be printk'd at a lower importance level and the minimum level for display should be higher by default. That would not stop you from specifying a lower minimum level to dmesg (which currently also defaults to KERN_DEBUG) and seeing messages which were suppressed from display at boot time.
Dynamic allocation isn't necessarily safe in all the places printk() can be (is) used.
... what happens if the printk() happens to be reporting something due to VM exhaustion? ....from within the VM subsystem?
There are some points in the kernel at which you just cannot touch the parts of the VM subsystem that would be necessary to dynamically allocate memory. It's not a design flaw; it's just a constraint of the way locking and reentrancy have to be handled.
With a lot of work, you could probably create a dynamically allocating printk(), but you'd have to introduce a tremendous amount of additional locking just to support printk(), which would kill performance, and would mean that printk() couldn't be used in many places that it is now (certain interrupt handlers where the locking overhead would be too much).
Also, an obvious one
The static printk() buffer is a necessary design decision.
DNA just wants to be free...
As a longtime UNIX admin who's used many UNIX systems, I think this is a good thing. I don't mind text printing on startup, but Linux prints so much ABSOLUTE USELESS CRAP to screen.
90% of them are ego-boosting messages by the authors of each chunk of the kernel. These are in particular what Linus seems to have an issue with.
I don't think boot messages should be completely gotten rid of, but they should be put on a rigorous diet. Let's look at the way other Unices do it. FreeBSD, for example, prints stuff, but it's terse and professional looking. Same with Solaris.
On Linux, the messages scroll so damn fast, especially on a speedy modern system, that you can't even read them. That's bad, folks. I can't even tell if the kernel is printing any error messages, because the credits messages scroll it so quick.
Yes, I don't mind a kernel component telling me it's there and the hardware's functional, but don't be so verbose about it!
On some DOS machines you will get the memory count displayed by the BIOS, then only a few more lines of text before the C:\> prompt. That means you can start using the machine while still on the first screenful of text since it was switched on. I think that's cute.
On Linux you can usually Shift-PageUp to scroll all the way back to the beginning of time, but it's not the same.
BTW - drivers that are likely to crash must print something, so you know what crashed. Although in a production system you wouldn't expect anything to just hang the machine at boot time, so the suggestion of a special 'verbose mode' for kernel troubleshooting is a good one.
-- Ed Avis ed@membled.com
I would not understand why this wouldn't be an option. I find it very annoying to try and fix a Windows machine and not know what the hell is being loaded at startup.
:)
:)
I think it is great that people don't want to see that shit. Hell, we are trying to make a move towards having more "dummy friendly" OS. "Dummies" don't like watching kernel messages. They would rather stare at the pretty pictures
I am fine w/all of that, in fact I believe it is a great idea and it should be implemented! Just make it optional. At least have a keystroke bring up the kernel messages.
dmesg is nice to have but I just like to know that there is something really going on other than just watching that stupid little bar at the bottom of Win bootups
I'd like to see NEW services and devices etc, but after they are running nicely I'd just as soon they fade in the background and not take up screen time unless an ERROR is generated. As a development system builder I never know what specs the developers will want.
errr....umm...*whooosh* *whoosh* Is this thing on ?
I think Version numbers, and other informational data should be kept in. Too much information is better than no information.
By your arguement, we should be calling Digital Unix, Irix, Solaris, and a host of other rock-solid variants of Unix "poor and brittle," because they don't "run" on as many architectures.
And it's a funny thing, but I don't seem to remember any informative messages from Linux telling me why I couldn't bind an IP to my 3com (3c589d) pcmcia ethernet card. The solution to that problem was found not through "transparency and diagnosibility" but through a win2k cd.
Those non-informational messages do contain information -- in their negative space. Sometimes things fail silently. There are no error messages. If you are expecting a success message, however, and don't recieve one, then the lack of a message indicates failure
On the other hand, some of the messages are useless. When my sound card driver loads, it outputs three lines:
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
es1371: found es1371 rev 8 at io 0x1080 irq 11
es1371: features: joystick 0xx
That much information is overkill (and unneeded). Go ahead and throw out the results of profiling code. Go ahead and ditch the ReiserFS built in ad. Go ahead and throw out the copyright notices. But please keep the sucess messages - they are just as important as failure ones.
Not particularly useful when your console is a real tty, not to mention that modern boxes are so fast that you wouldn't see much like that anyway, so there's no point to print it in the first place.
You ought to pass that book on to the MS Access developers. Does this sound familiar?
"You are about to modify 0 records. This action cannot be undone."
The Outlook people could use some help, too:
"This graphic does not do anything. For Help on an option, click tho question mark [?], and then click the option."
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Why don't we have different levels of information for each category? Then I could get info-level messages about failures, and only warning-level messages about credits. And also I'd like to customize these messages for each category: for example, I only want warning-level messages about failures in the filesystem category. And perhaps I'd like only critical-level messages about successes in the boot-message-printing category, to prevent me from getting a notification about a successful notification (thus crashing at boot because some poor driver wanted to tell me that its programmers have big egos). Or alternatively the kernel would be smart enough to check the boot-message-printing options (configured through LILO perhaps? there's lots of unused space in my MBR) to make sure that it won't get stuck in a successful-message loop. Maybe for ease of maintenance we could get ESR to write this in Python, and then compile a small Python interpreter into the portion of the kernel code that gets loaded first...
Yes, this all sounds very good, Mr. Gates. True innovation. We'll implement it at once, sir.
--
Gates' Law: Every 18 months, the speed of software halves.
Out the outset, let me say that I agree that kernel advertising/credits messages hide useful information and make the system unnecessarily confusing to less experienced users. I am glad to see Linus taking aim at them, as it really takes someone very respected in the development world to attack something that has so much ego attached to it.
That said, I would like to still have a verbose mode that includes these messages so that someone who knows what they are doing can verify that a given facility is being initialized at boot. The simplest way to achive this would be to change DEFAULT_MESSAGE_LOGLEVEL in linux/kernel/printk.c, from 7 (KERN_DEBUG) to 6 (KERN_INFO), thereby filtering out KERN_INFO messages. Maintainers who feel that some of these messages really should be printed by default could submit patches to change them to the previously ill-defined KERN_NOTICE (5) level and try to convince Linus to apply them.
It is also trivial for individual Linux distributions and sysadmins to modify this policy by booting with the "debug" argument (sets console_loglevel to 10) or to modify this in a boot script by writing to /proc/sys/kernel/printk as documented in linux/Documentation/sysctl/kernel.txt. A "loglevel=n" kernel boot argument would also be a helpful feature for the future and would be trivial to add.
You make me believe whole-heartedly in censorship.
It doesn't mean much now, it's built for the future.
Yep, That entire end sequence made me fall off the couch!
It doesn't mean much now, it's built for the future.
>('cept to add new hardware of course.)
Bah. Like a marksman who fires his gun between hearbeats, I just listen for the 60-cycle hum and slam my PCI cards in during the trough between signal peaks. Unfortunately my teeth are starting to blacken from gnawing on live IDE ribbon cables, so I may have to reconsider my hardware techniques.
hey now, I needed to downgrade from the "new" delete-all-your-data adaptec scsi driver (6.x.x) to the "old" doesn't-delete-all-your-data driver (5.x.x), and I knew I had done it properly when I saw the correct version number. leave that in!
This way, there would be several modes, selected by kernel parameters in the lilo.conf file or LILO prompt.
Meldroc, Waster of Electrons
"Unnecessary messages are pure evil."
- Everett N. McKay, page 367
Developing User Interfaces for Microsoft Windows
(c) Copyright 1999
What's your damage, Heather?
Red hat is doing fine...
ReadThe ReflectionEngine, a cyberpunk style n
CONFIG_SUPPRESS_VERBOSE_INIT
????
Then RH and the rest can choose that (and lpp) in their default kernels. The rest of us can let 'er rip.
I always wanted more messages. That way when rebooting, I looked extra '1ee7. The only thing more frightening to the employees is when they see a kernel compile running. Or a BSOD (a true NT type one with all of that debugger information or whatever it is. Not the wimpy Win9x one)
Jesus was all right but his disciples were thick and ordinary. -John Lennon
So, he's just talking about copyright notices and that sort of garbage. He's actually keeping the good stuff in. So, this makes sense. Must be a slow newsday, what with no Micro-Soft FUD to report.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Relying on dmesg to configure a kernel (like the person you replied to) is kinda like relying on the author/editor blurb at the top of a Slashdot story to give an accurate impression of the news (like the person you replied to).
Jesus was all right but his disciples were thick and ordinary. -John Lennon
If you bother to read Linus's message, you'll note that this will not eliminate messages scrolling by on bootup. This will simply eliminate the display of suplimentary information that isn't crucial to the booting process.
For instance, you will no longer see:
Random Device Driver: Initialized
Random Device Driver version 1.23 (c)1999 John Doe
You will simply see:
Random Device Driver: Initialized
The other stuff is available elsewhere, and just adds to the clutter. Simple == beautiful.
Thats one thing that sorta anoyed me about ReiserFS kernel module. I don't use SuSE and hate mp3.com so I simply went in and changed the output message to something amusing.
Great thing about open source, if you don't like the messages.. change em!
--------------------
Would you like a Python based alternative to PHP/ASP/JSP?
Linus specifically said that the important kind of messages are the ones that are displayed when something isn't working properly,
/var/log/messages and I happen to notice that you're running the 2yr old ReiserFS code with the security hole, I'll tell you and you will be happy. But because there isn't a problem, ReiserFS doesn't ever say anything and you get cracked.
You see, the problem is that software often doesn't KNOW when something isn't working properly. The software cannot know unless the developer either:
1)predicts every possible failure case or,
2)checks the inputs at every function call (which will slow your 1000GHz Fitztanium to 8086 speeds)
Version numbers are also important. If you show me your
Bootup messages are a very important standard that has become an invaluable troubleshooting tool. Even know that something DOES work is good information when troubleshooting. Linus should leave it alone. If I don't wanna see "ReiserFS is brought to you by MP3.com", I'll either modify it (I do have the source), or I'll use IBM's JFS.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
Now, I know this isn't a (hugely) likey possibility, but there has been more than one occasion when I've needed to know what was in a remote box, and checking dmesg remotely was MUCH faster than physically going to the box.
It's just an example of a good reason to keep the information available somewhere (/proc isn't very good for this, because it tells you what's happening now, but it won't tell you what happened while the machine was booting.)
For all the Windows flames that get thrown around here, I think MS hit the nail on the head with the Windows 9x series. (Well, boot screens that is...) The Windows 9x series had the best of both worlds: A pretty picture (animated even!) that was shown while the system was booting, but if you wanted to see DOS messages, just hit escape and you're greeted with the standard DOS bootup.
/CRASHDEBUG option. It's not particularly pretty, but serves kind of the same purpose. It's just not available with an escape key. You can't set the option (easily) if you can't boot the system, so what's the point?
I think Linux should do the same thing - leave the bootup messages, debug messages, and whatever else there, but cover it up with a penguin sitting in a speedboat. For 95% of the time that I don't care what happens as long as the thing boots, I'll see my happy Tux, but for the other 5% of the time, I can just hit escape to see all the messages I've grown to know and lov^H^H^Hhate.
Windows 2000 doesn't offer this functionality. Yes, yes, I know about Windows 2000's
"Of course that's just my opinion, I could be wrong." - Dennis Miller
LOAD "SIG",8,1
LOADING...
READY.
RUN
I would just really really like to avoid being forced into a non-verbose display. By default your bootup sequence should have full verbosity turned on
:)
Perhaps yours should.
Assuming you want your OS to become mainstream, you better start letting go of these things that make it decidely ugly and confusing. By default, it should display general high-level information ("starting networking") and provide errors only. Most people don't need to know the filesystem was mounted as read/write.
People aren't going to change for Unix. Unix will have to change for people (as Mac OS X demonstrates).
- Scott
--
Scott Stevenson
WildTofu
Scott Stevenson
Tree House Ideas
Then patch /usr/src/linux/init/main.c with:
/etc/lilo.conf All messages are still accessible by dmesg and you can boot with "debug" if you want to.
;->
if (!strcmp(line,"silent")) {
console_loglevel = 1;
continue;
}
Just below the "quiet" option...
Remember to add the "silent" option in
Silencing about 50 bazillion init scripts is left as an excercise for the reader
Red to red, black to black. Switch it on, but stand well back.
Far be it for me to disagree with Linus, but version numbers don't take up much space, and they often make debugging instantaneous. ("Oh, you only have version 4.5.6. Obviously that's not going to work.")
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
We need the messages printed at boot time to be classified. You can have success messages, failure messages, credits, etc. Then you could configure the system to display the kinds of messages you want to see.
I don't know much about the innards of the kernel, but I suspect something like this already exists. Could it be used for boot messages? Perhaps it could be extended?
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Either that, or a simple script which will open up as many connections as possible,send the data, and then each of those connections does a near simultaneous hit of the 'submit' button (or rather, the equivalent of doing so). Simple trick, doesn't require a lot of bandwidth, and would probably get past the race condition that's been found and is being more than slightly abused.
GPL made simple: What was my stuff is now our stuff. If you improve our stuff, please keep it our stuff.
I read the article.
And I think removing versions and "good status" messages is just plain stupid. When I boot up, I
WANT to know what is running, and that everything is "just swell". What is the problem,
anyway? BOO HOO! BOO HOO! "I cannot deal with all those confusing boot messages. BOO HOO!"
And how many times do you reboot, anyway? Once a week? Twice a year? Every day? Whatever the
interval, a few pages of messages aren't going to hurt anyone. What if you have a problem and now
NEED the messages from last week? On many systems, that will still be in the message logs.
There are a lot of ways to get information, but the message logs are often the most convenient.
I don't see why someone would be so upset about a few K of storage or a few extra kprintf calls.
A dingo ate my sig...
The boot messages are annoying and obscure actual errors.
You state that as if it were an objective fact. Actually it is your opinion. My opinion is otherwise.
The discussion is about NOT DISPLAYING THE USELESS ONES during booting.
Useless is also a matter of opinion. And the messages do not add any appreciable delay. I have
seen kernel messages go by at hundreds per second on occasion. Mere dozens of "useless" messages won't make any difference in boot time.
I read the article. I was paying attention.
A dingo ate my sig...
My analysis isn't that Linus is killing dmesg, but rather he is responding to advertisements and junk clogging up needed boot and debugging messages. I agree with this. Have you seen what an AOpen motherboard boot screen looks like? On some models there is a right frame with all sorts of advertisements for all sorts of products. That is insane.
Linus isn't killing boot information but rather not placing everything from URLs to copyright information in the same place where you find out if your networking interfaces are functioning properly.
Linus specifically said that the important kind of messages are the ones that are displayed when something isn't working properly, so no more whining that you think those messages are going to disappear, okay?
Moreso, some people seem to be under the delusion that the linked Slashdot article with the "pretty bootup" is related to what Linus said. No. Linux isn't saying anything at all about a graphical boot, and that graphical boot system is still hugely experimental anyway.
--
Win dain a lotica, en vai tu ri silota
Personally I don't use Linux anymore so I don't really care, but I think it's a dumb move on Linus' part and here's why. Suppose you've just been hired as a sys admin in a company and have to recompile kernels across a couple dozen perhaps hundreds of Linux based servers... Suppose that company was crappy via way of having things documented.
It's so easy to just do a dmesg and see exactly what's being used in order to recompile the kernel, as well as determine should something be replaced, or removed to make things better for the network. Anyways it's his dictatorship... err... OS, however it'll just makes things a bit more difficult for some
Want Root?
I've always felt since day 1 of using Linux that about half of the kernel output was ego-stroking, and very little useful information. It made the whole thing feel less like a unified project and more like a haphazard collection of little bits and pieces.
I hope the opportunity will also be taken to give everything a more unified look, a la commercial UNIX and *BSD kernels; it will certainly make finding what you're looking for in the dmesg much easier rather than having to sift through rabble.
Sure I could go digging around in proc and eventually turn that crap up, but it's usually much easier to grep dmesg or watch the kernel bootup. You might be able to squeeze everything that's needed into one line, but you still need some message during bootup.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I mean, I start up my computer once a day. I know, I know, it's a lot. And yet somehow I manage to cope with the daily trauma of my computer displaying messages as it boots. In fact, some days, I barely even notice them!
Does anyone else get this, or am I unusually Zen?
Relying on dmesg output to decide what to configure a kernel with is error prone and SLOW. any decent admin would have the config file handy.
Naturally, this means that a dmesg output doesn't give you any idea of what a system is running, but we have other better ways of displaying that through for example the proc interface.
I know someone is going to put a hit out on me for saying this, but why not do what Win95/98 do. Put up a picture of something and if the user wants to see diagnostic messages, they just hit a key...
However I'm still not clear whether Linus wants to squelch all 'happy messages' or only author attributions. If it's the latter, I don't care.
I disagree with this. I have used the Linux boot process to identify an unknown system that a friend wanted Windows installed on, so that I'd know which Windows drivers to look for! I find one of the best ways to take hardware inventory of an unknown computer is to attempt to boot Linux on it. Even if the boot is unsuccessful, the console messages tell a lot about the hardware and what's in there!
I sincerely hope the drivers aren't edited down to prevent this logging. All of the text should be available to read with dmesg. What I hope is that a compromise can be reached: default to a pretty-boot process, but have a way for the knowledgeable user to still see the console (perhaps by pressing the ESC key).
Or, use the priority system of printk to prioritize each message, and have an optional boot parameter that would control how many messages get printed. It could be something like bootverbosity=8, given on the boot command line. This already exists, look at the argument to klogd -c!
Doing a kernel-wide purge of all informational messages is just the Wrong Thing, as these messages will then be lost and there will be no way to print them when they are needed to solve problems!
Super eurobeat from Avex and Konami unite in your DANCE!
Dr. Demento On The 'Net!
um the way i read this is that linus doesn't want our dmesg full of crap about the maintainer's email address and other gobbledy gook that just doesn't matter. all i want to see on boot up is
keyboard.......ok
mouse..........ok
modem..........hosed---->read such and such to fix problem.
monitor........doing better than the modem apparently
-
There seems to be some agreement that personal names, copyrights, etc. are harmful. The opinions here seem to be divided on the usefulness of successfull messages "Driver Foo loaded OK and detected 2 Foo cards at oxF00 and oxBAR". Those messages annoy some, and are very useful for some. So, why not add a boot parameter, a key, or something, to make them visible when needed. When not needed, they could be kept away from confusing the poor users...
In Murphy We Turst
In fact, there's much to be said for presenting messages as openable trees, rather than text streams. I came across this in an application from Eastern Europe written by someone who was very good, but did everything their own way. The message file was a tree, and you could open up messages and see submessages. This is way ahead of using "grep" on text files.
Otherwise I won't get to gloat that my BOGO MIPS is higher than yours.
This isn't about the same thing as the slashdot story linked from it. This is about not telling you you're using HardwareDriver 1.34.135 by Abjkl Magdinadf. That is exactly the kind of thing we don't need - if I want to know the name of the person who wrote my drivers, i'll find the information myself. I don't need to be told every time I start my computer. This is optional - the messages like this should be removed from the boot process, and if you want to know you can just get the version information.
---
They that quote Benjamin Franklin on liberty and safety deserve neither.
if I want to know the name of the person who wrote my drivers
Sounds like Linus wants only his name on the system...
--
To me this does NOT sound like an ego-maniac wanting his name and only his name all over the system.
I know, I just like provoking people who subscribe to that idiotic cult of personality. Actually I always assumed he called it linux to rhyme with minix.
--
I just junked the graphical boot screen on NetMax because I don't like the idea of things grinding away under a pretty (or ugly) graphic. Even if I don't like the text, at least I can see what the system is doing....or what it's stuck on. If we're going to go graphical, then we need to be able to hit a key, change a config or use a LILO option to boot textually. But I think what Linus is saying is that we should be seeing boot messages that mean something, not ads for someone or chest-pounding geek speak designed to echo how much tech talk we can slap together. If you want to tell me something, tell me. Don't show me a picture nor read me the spec sheet.
This way, the message is only on the screen for the duration of the time the installation is running. If it hangs, you have a mea culpa sitting there. If it doesn't hang, but the next thing does, the whizzomatic is absolved.
When I boot Linux I see a little pic of Tux and a line saying something like "ABCXYZ Bogomips"
According to Linus's definition, this information is useless. It doesn't help me debug anything and isn't necessary for the system. I think it's a cool thing personally, but I can undestand concern that this bootlog space would be used for spamming the Linux using community. And whenI say Linux using community I'm not talking about sysadmins who tweak out their systems to the utmost. You're not users guys, you're not the audience Linux needs to reach.
Steven
-- I have marked myself unwilling to moderate-- I don't have other accounts to artificially inflate the karma of
Well I like the boot messages....At least you see what your computer is working on. A lot of modern computers show a bitmap while doing POST (Dell screen, Toshiba screen, Tulip screen, whatever...). I disable it when possible because I like to see my puter check it's memory, giving a report of IRQ usage, PCI bus stuff, SCSI finding the drives, etc...
I just like to be informed...That's all...
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Some readers are operating under lack of information.
If you see "OK...OK...OK...FAILED...OK" when you boot up or "Pass...Pass...Pass...FAILED..." when you boot up, then you're thinking of the wrong messages. To see the messages Linus is talking about (the endless copyrights and chit-chat of the kernel) type 'dmesg' as root after a fresh boot.
The status messages that give you an OK or a FAILED on a system-by-system basis are (in the most broad sense) init messages rather than kernel messages and are added by your distribution. These will not go away under the "new deal" Linus is proposing...
STOP . AMERICA . NOW
I didn't get that _at_all_ from what Linux said. Given that he first said that there weren't any extranious messages, I think that what he meant was that only those items of a completely non-useful nature would be removed.
What does that mean? I think it means that stuff like:
Jun 6 13:10:04 localhost kernel: hdc: ATAPI 1X CD-ROM drive, 32kB Cache
eth0: PCnet/PCI II 79C970A at 0x1000, 00 50 56 8e 6e 4d assigned IRQ 9.
will stay around. But stuff like:
pcnet32.c:v1.25kf 26.9.1999 tsbogend@alpha.franken.de
which (arguably) provides little information will go away.
I really don't think there's any intent to take away boot messages.
Sean.
Rock Linux uses the Device Filesystem by default.
Got friends?
Sure, pretty boots are nice and all, but I can't imagine what I'd do without my boot logs. It's kind of hard to catch those first few kernel messages as it is, and I'm usually rummaging through my log to see why the hell something is no longer working like it was on the last boot.
Try cat /proc/cpuinfo
No penguins... but you do get to see the stepping number of your CPU!
Living better through chemicals
That what's being said is that the modules shouldn't be spitting out this information as part of their code, as modprobe could handle that function. It could then be turned on and off as needed. Makes sense to me, why does every kernel module need to have code in it to print out information when the software loading the modules could do it, it would then only be written once, could be configurable. (verbose level = X, or modprobe -v, modprobe -vv, modprobe -vvv, etc.)
If it fails, print out a message "Module X failed to load. Noncritical error, continuing to load linux. Fix me if you dare."
I'm going to go back in my box and will think within the limits of my box: MS Sucks Linux Good I read too much Slashdot.
These messages are usefull and I hope will either be logged or better yet be optionally echoed to the screen instead of prty pics. Wven WinDoS has an option for bootlogging.
A more real example-- troubleshooting an ethernet card you just installed. The boot messages can tell you quite a bit about its initializaton on the kernel level before your network script is run. This can tell you whether you need to recompile your kernel.
LedgerSMB: Open source Accounting/ERP
Everyone knows we never have reboot our Linux boxen anyway. ('cept to add new hardware of course.)
'Same speed C but faster'
Winter 2010: With Glowing Hearts
When Linus starts thinking about changing boot messages, that must mean the rest of the kernel is perfect 8)
contacting host slashdot.org..... connected
slashdot.org contacted.... waiting for reply
downloading slashdot.org 10.5k/s
document:done
welcome marcus brody
congratulations! you have moderator satatus...
please go forth and moderate
words speak a thousand pictures. so much so, we often take the information they contain for granted.
what does some flying windows or clouds tell you exactly??
well... if they freeze you know your computer has crashed.
Linus: "Let's make it policy that we _never_ print out annoying messages that have no useful purpose for debugging or running the system, ok?"
Dont worry - Linus isnt going all Mac on us! As ever he is making more sense than your average hacker. I know what OS I'm running - and which kernel version, and even what modules im using. but yes some of this information is occasionly useful, and these are the bits that should be left. Maybe then they might not scroll off the screen so fast that we never read them anyhow.
The more I think about it, the more I feel this is a win here; we get a bootlog that's easily eyeball parsed without all the cruft of a driver maker sending out mad props to all the sponsors.
Though what I'd really be interested in seeing one of the big vendors at least experimenting with the DevFS system. It looks like it could clear up confusion and make things drivers/programs easier to write.
If god had intended you to be naked, you would have been born that way.
Flying Headless Goku - version 0.8 (the other 0.2 would be the head)
thinking of idea
considering approaches
initialization complete, beginning typing
I dont' se e the protlem with verbose messages, you can just ignroe tem if you're not interested in what they say.
spellcheck:
dont': don't dent donut
don't
se: sea see is se.cx
see
e: a
ignroe: ignore
ignore
tem: Tim term team them
them
finished processing!
I don't see the problem with verbose messages, you can just ignore them if you're not interested in what they say.
--
IMHO it is perfectly acceptable to see who contributed to what on startup. How often do people have to reboot their systems anyway?
It may be obvious to Linus which version of the driver a particular kernel version uses, it isn't obvious to other people. In fact, in the presence of driver patches, there is just no way to tell. The bit of vanity, having people's names print out who put in a lot of effort into writing a driver, seems justifiable to me as well: these people don't get money, the least they can get is a little publicity. Besides, some licenses require copyright information to be printed.
The Linux kernel has lots of serious problems in terms of configurability, usability, and lack of support for crucial standards. The bootup messages are completely harmless, take almost no resources, and are useful to many people. Why fix something that isn't broken? I'm disappointed that such a stupid idea would even get seriously considered.
Small precision on OSX:
/. =)
it has a verbose option ("Apple key+ v" at system boot) wich looks like good ol' *nix boot.
And it supports color !
I bet it can make coffee too =)
--
Arnaud Willem
1st post of my life on
Linus is saying that MS was right in hiding bootup information from the user and masking it with a pretty picture? Why! Windows obviously does this and often times fails to load drivers, or loads useless ones, etc, and the user has no clue why their machine takes 10 minutes to load. Isn't the point of linux to feel like a real geek who doesn't need technical details hidden from them? Maybe not, but I like my verbose kernel boot messages.