Linus Says No To Annoying Boot Messages 286
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.
Why not make money off of boot messages? (Score:2)
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 [babylonx.com]. It's about the only way Redhat and VA are going to stick around.
What a great idea (Score:2)
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.
--
printk (Score:2)
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.
--
Re:What a great idea (Score:2)
Secondly, removing informational messages provide an important function, in that they give you status updates as to the progress of the boot process. Thus, if the machine crashes due to a bug, where there is no error message, you have a clue where to start looking.
--
Re:printk (Score:2)
my point about the limitations of printk is simply that it's NOT a debugging tool, and linus shouldn't pretend that it is.
the linux kernel is far from intuitive, it's kind of amazing that it works when you read the code, let alone that it works well. telling the developers that they should be allowed access to NO debugging tools other than a 1024 character print buffer just makes people's lives unneccessarily difficult.
Sure, it's fine if all you want to do is hack kernel code, but it sucks ass if you want to hack userland code, but need to fix a glitch in the kernel first.
--
Re:saftey (Score:2)
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.
--
Re:This is a good thing (Score:2)
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
Re:how many people here actually *read* Linus's ms (Score:2)
Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
How about the way FreeBSD does it? (Score:5)
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.
This is a good thing (Score:5)
Re:I did and I still don't like it (Score:2)
Re:Ummmm... (Score:2)
Maybe you should. (Score:2)
"good status" messages ARE relevant. (Score:2)
Re:Ummmm... (Score:2)
Re:What a great idea (Score:2)
But in any case, Linus doesn't think that real men use printf() (or printk(), as the case may be). Real men grok the code.
Message uniformity would be better (Score:2)
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.
Re:no version numbers? (Score:2)
In my case, that gives:
Now tell me again exactly why you need the version printed at boot time?
Re:how many people here actually *read* Linus's ms (Score:2)
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?
--
Re:textulike (Score:2)
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.
--
Re:Not *all* messages (Score:2)
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.
how many people here actually *read* Linus's msg? (Score:5)
--
Re:This is a good thing (Score:2)
Imagine you're driving in your car, and all of the sudden, buzzers and warning lights start going off, announcing EVERYTHING'S FINE. Do this enough, and you'll not only be upset by it until you can manage to ignore it (if possible) but you'll have trouble distinguishing it from NOT EVERYTHING'S FINE.
Let the status messages come up if there's something new, or different, or wrong. But as long as things are running smoothly, there's no need to hurl that in our faces. (and when warnings are displayed, also include some fricking suggestions as to how to fix it or who to ask, dammit!)
So? (Score:2)
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.
Re:Bad move Linus (Score:2)
saftey (Score:3)
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.
A very good move. (Score:5)
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!
Single screenful from boot (Score:2)
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.
Re:I like those boot messages (Score:2)
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
the above has a point (Score:2)
Re:I did and I still don't like it (Score:2)
I think Version numbers, and other informational data should be kept in. Too much information is better than no information.
poor brittle engineering? (Score:2)
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.
I did and I still don't like it (Score:2)
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.
Re:A better solution (Score:2)
Re:A quote from The Good Book (Score:4)
"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."
--
Re:Message classification (Score:2)
Yes, this all sounds very good, Mr. Gates. True innovation. We'll implement it at once, sir.
--
Can we have a verbose mode? (Score:3)
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.
Re:OT: Crapflooding (Score:2)
Re:OT: Crapflooding (Score:2)
Re:It's all irrelevant. (Score:2)
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.
no version numbers? (Score:2)
Need multiple boot message modes. (Score:5)
This way, there would be several modes, selected by kernel parameters in the lilo.conf file or LILO prompt.
A quote from The Good Book (Score:4)
- Everett N. McKay, page 367
Developing User Interfaces for Microsoft Windows
(c) Copyright 1999
red hat? (Score:2)
Why not add a little statement like... (Score:2)
????
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)
Maybe I should read it first (Score:4)
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.
Re:No wonder you're not working with linux (Score:4)
You guys want to actually try reading the message? (Score:3)
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.
ReiserFS (Score:2)
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?
Re:Not *all* messages (Score:4)
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.
Imagine this: (Score:2)
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.)
Happy medium (Score:3)
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
Re:poor brittle engineering? (Score:2)
In fact, I often demonstrate how cool Linux PCMCIA support is by grabbing a random card (often one from the demonstratee), plugging it into my laptop, plugging in the network cable, and browsing to sites.
I even did it with a WaveLAN card once. It was the first time I plugged a 802.11 card into my laptop ever.
No messages, no popups, no "insert a stupid disk because I'm going to reboot the machine 3 times."
Interestingly enough, I have a tiny Windows partition on my laptop, but I never use it. Windows will lock up hard on boot if my NIC (3c575CT) is inserted. No biggie, Windows is useless to me and my solution was found through a SuSE DVD.
Re:I did and I still don't like it (Score:3)
Traditionally, in UNIX environments, the lack of a message indicates success. If it worked, why bother me about it?
This is important because I've seen *lot's* of people panic when they get success messages.
Pretend you know nothing of IRQs, IO ports, and hex numbers. If you saw a screen full of them you wouldn't know if it was good or bad. An important part of useability is not confusing the user, because they get very worried when they see something confusing.
Re:Mac OS X & Informative Boot Screens (Score:2)
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 [wildtofu.com]
If you want a really quiet kernel... (Score:2)
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
Version numbers ought to stay (Score:2)
--
Message classification (Score:4)
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?
--
Re:This is a good thing (Score:2)
While I agree that short, informative messages are a step in the right direction, a splash screen or other sweeping under the carpet is not. People who want to make money out of Linux products may want Linux on Joe Ordinary's desktop, but those of us who use Linux now should not - or at least, should not be prepared to make compromises in the features we value to do so.
Linux is high quality, very stable, rapidly developing system because it is a hackers operating system. When it doesn't work, hackers are motivated to fix it, and have the ability to fix it. Joe Ordinary will never have the ability to fix an operating system. If you compromise Linux to suit Joe Ordinary in a away that doesn't suit the hacker community, the hacker community will drift off to the next cool operating system, and Linux will start to suffer from bit-rot.
Ob: Neal Stephenson (Score:2)
Re:textulike (Score:2)
Re:Please oh PLEASE!!??? (Score:2)
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.
Re:Please oh PLEASE!!??? (Score:2)
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.
No, I think we are confusing issues. (Score:3)
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.
Its a good move. (Score:3)
Not *all* messages (Score:4)
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.
--
Bad move Linus (Score:2)
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
Maybe it'll look a little more professional (Score:3)
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.
Re:Imagine this: (Score:2)
It's nice that someone else seems to agree... I don't like seeing the corporate stuff, (mp3.com? sheesh...) but I don't really agree that it's all that annoying to notice a coder's name after his particular driver has just loaded. He wrote the code that makes my computer work and did it for free. Is it really that much to ask that his name appear next to his driver?
I'm afraid that this is one area where I don't agree with Linus. I *like* to know that my computer is doing something sucessfully. I *like* seeing that my serial drivers, ethernet, ppp, scsi, etc have all been detected by the kernel.
Lets not forget that all the stuff that the kernel outputs normally gets stored in logs. You'd be surprised what problems can be solved by noticing a mundane change in kernel output. Also, much of my important configuration stuff stuff comes from the output of dmesg. When I have a brain fart and can't remember the SCSI ID of my CD burner for cdrecord, I simply take a quick glance at dmesg. Ditto for pretty much every other device on my system. dmesg sure beats the hell out of spending 10 minutes searching
Please no one take this as flamebait, but the way Linus worded his ultimatum was that he didn't want *any* kernel output except errors. One thing I absolutely hate is operating systems which offer little to no information about what they are doing while booting. This includes Windows and Linux distributions with Aurora installed by default (Mandrake).
I like Linux because it lets me see more of what my system is doing which gives me the opportunity to act when I notice something that I don't like.
PLEASE, at the very least, Linus, if you're going to do this, give your users some option of verbosity. Don't just tell the kernel hackers to get rid of all non-error messages.
Re:This is a good thing (Score:2)
It is *normal* for commodity PC hardware to randomly blow up and do weird things, and being able to handle it without training people to press special key combinations is *good*.
I'd hide the messages unless the person watching can do something about it.
If Alan is unable to understand what via-rhine.o is, then being able to press a magic key that prints 'via-rhine.o' to the screen will do him no good.
However Bob understands what via-rhine.o means, and he knows the key to print it onto the screen.
Take for example 'F8' on old MSDOS bootups. I never knew about pressing that key until I understood enough to know what I was being asked. If I knew the key before understanding the questions MSDOS was asking me, I would have been lost.
If you can do something with the message, then you'll know how to find the message.
"good status" messages (Score:2)
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.
So? (Score:2)
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?
No wonder you're not working with linux (Score:2)
Read Linus' post. (Score:3)
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'm going to hell (Score:2)
Stephenson might disapprove (Score:2)
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.
Useful for configuration (Score:2)
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 [freelords.org], 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!
Re:This is a good thing (Score:2)
If nothing else, announcing module load/init should be output at debug priority, not informational priority. Debugging a non-working system would be the only real reason most people would ever need to see that.
cool your overreactive jets folks (Score:3)
keyboard.......ok
mouse..........ok
modem..........hosed---->read such and such to fix problem.
monitor........doing better than the modem apparently
Could this be made optional (Score:2)
Re:This is a good thing (Score:4)
My Computer (Score:2)
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.
Re:Read Linus' post. (Score:3)
I say we keep 'em .... (Score:2)
Re:I hope it will be optional (Score:2)
---
Re:I hope it will be optional (Score:2)
Sounds like Linus wants only his name on the system...
--
Re:I hope it will be optional (Score:2)
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.
--
Re:I hope it will be optional (Score:2)
A better solution (Score:2)
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.
No more Bogomips or Tux then. (Score:2)
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
Re:So let me get this straight (Score:2)
I just like to be informed...That's all...
OK/FAILED/Pass is NOT what LInus is talking about. (Score:2)
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...
Re:So let me get this straight (Score:3)
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.
Seems to me.... (Score:4)
If it fails, print out a message "Module X failed to load. Noncritical error, continuing to load linux. Fix me if you dare."
It's all irrelevant. (Score:4)
Re:This is a good thing (Score:3)
-----
textulike (Score:4)
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.
Re:So let me get this straight (Score:5)
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.
I don't see the problem. (Score:3)
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.
--
Re:So in shocking news... (Score:3)
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