kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3
I have nothing against it being faster -- *as long as nothing about the way I use it changes.* Most of my kernel upgrades are done while I'm at work, programming, doing Solaris system admin, sitting in meetings, making phone calls, or any of the other things my employer is paying me to do. I have a cron job that checks kernel.org periodically and pops up a message on my screen when a new kernel patchset appears there. When that happens, I quickly switch to another virtual console, ftp the patch, and then:
zcat patch-X.Y.Z.gz | patch -p1 -s -E
mv .config ..
make mrproper
mv ../.config .
make oldconfig
make dep && make bzlilo modules modules_install
Then I go back to work. When the compile finishes I stop long enough to reboot, then start working again, and unless there's a problem, don't give another thought to it until the next patchset is ready.
I have all this down to a science. All these commands are in my bash command history so I can pull them up with a couple of keystrokes. I've done them all so many times that I can type them from scratch almost without thinking about them. I've gone through this whole process while in the midst of business conversations without anyone even noticing that I'm doing it. (Of course, if there are compile errors it's another story, and I have to deal with those later, but often I can go through several upgrades in a row without any errors.) Anything that changes this process -- new commands, new syntax, whatever -- takes extra time and disrupts whatever else I'm doing.
Different people have different needs. I don't care how many new bells and whistles the developers add for their own use, but it would be nice if those of us who just want to apply patches and recompile with a minimum of fuss could keep our old user interfaces.
Nicolas Pitre <[email protected]> on 05/17/2002 05:09:20 PM
To: Wayne Brown/Corporate/Altec@Altec
cc: [email protected]
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3
But even if you recompile *everything* _everytime_, kbuild 2.5 is "faster".
What do you have against that?
Nicolas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · On Fri, 2002-05-17 at 15:59, [email protected] wrote:
I have nothing against it being faster -- *as long as nothing about the way I use it changes.* Most of my kernel upgrades are done while I'm at work, programming, doing Solaris system admin, sitting in meetings, making phone calls, or any of the other things my employer is paying me to do. I have a cron job that checks kernel.org periodically and pops up a message on my screen when a new kernel patchset appears there. When that happens, I quickly switch to another virtual console, ftp the patch, and then:
So we should curb progress in the name of you not spending 2 minutes rewriting your bash scripts or repopulating your bash history with new commands?
Bah go away. I and most other people here are the exact opposite - give us new features, less bugs, or innovation and we will surely change. Otherwise we would still be in the stone age.
Robert Love
[email protected] said:
[Long explanation on routine kernel compilation elided]]
Quoted 2 lines
I have all this down to a science. All these commands are in my bash command history so I can pull them up with a couple of keystrokes.
Guess what... after the first time you do it the newfangled way the new commands will be in .bash_history too!
Quoted 3 lines
I've
done them all so many times that I can type them from scratch almost without thinking about them.
If you do it _that_ often, then you'll get it the same automation in no time with any strange new commands. Or find a way to integrate them with your cron job that downloads patches (Heck... I update gcc from CVS nightly, build it and run its testsuite from cron). But just compiling any random kernel that shows up is not enough...
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Quoted 10 lines · On Fri, 17 May 2002 17:59:28 -0500 [email protected] escribió:
I have all this down to a science. All these commands are in my bash command history so I can pull them up with a couple of keystrokes. I've done them all so many times that I can type them from scratch almost without thinking about them. I've gone through this whole process while in the midst of business conversations without anyone even noticing that I'm doing it. (Of course, if there are compile errors it's another story, and I have to deal with those later, but often I can go through several upgrades in a row without any errors.) Anything that changes this process -- new commands, new syntax, whatever -- takes extra time and disrupts whatever else I'm doing.
oh, please, you don't have to learn 666 new commands. I'd like to think that we've enought intelligence to learn a few new command.