Slashdot Mirror
Linux Kernel 2.2.6 Released
Some guy named Chris was the first to write in to say Linus has blessed us with
2.2.6. Additionally, Alan has already posted 2.2.6ac1, and the mirrors will hopefully be synced by now. Cutting Edge Linux has the changelog.
That's what all the 2.2.0-pre patches were for. If you didn't help in testing those, or you never submitted a bug report, you have absolutely no right to complain.
:-) Listen: just cuz a new kernel release comes out doesn't mean you *have* to
upgrade to it.
Hell, I'm still running 2.0.36 and am happy as a clam. And yes, believe it or not: I
am a geek/nerd and a hacker.
I just have better things to do with my time than upgrade my kernel everytime the latest-and-greatest hits the streets.
If you use Linux (or *any* OS, for that matter) as a tool, and nothing's broken that
a new release addresses: leave the damn thing alone!
i've been playing this catch-up game ever since 2.2.0. I guess i'll have to delete 2.2.5 and start over again...
I'm typing this from a PPP connection under 2.2.6.
Why not just get the patch file?? Not only does it take a fraction of the time to download but it's the net friendly thing to do.
It seems a little pointles to download every driver available for the OS when I upgrade the kernel. Why not move to a more modular solution like Windows? It seems a better solution than downloading a massive package with alot of stuff I'll never use.
I would rather they work on MUCH more important stuff like SMP scalability, file systems, large memory support, etc. These things matter in the real world, online kernel upgrades are only important to kernel hackerz and bleeding edge users, all of whom are a small minority.
My IMPORTANT machines all run the stable 2.0.x kernel, and won't be upgraded until the 2.2.x kernel is does not change for at least 6 months.
I think you're probably refering to GNU/Hurd. You can find information at:
http://www.gnu.org/software/hurd-noframes/
I haven't tried in-place upgrading of it however. =)
I think you're missing the tone. They _like_ complaining. One of the charms of Linux is complaining about the frequency of new kernel versions. It's like a back-handed complement.
I would probably take almost as long to swap kernels as it would take to reboot. If not longer. but the advantage is you get to keep all your processes running the same exact way. Except for the processes which relly on certain drivers like vmware. I just don't see this as feasable.
use the patch files, you schmut.
Linux has worked beautifully with my Zip Plus since day 1 (kernels 2.0.36 and 2.1.92 on through 2.2.6 which I just installed). However, I have about a 50% failure rate booting Win98 when the Zip drive is powered on - it'll stop right before the desktop is supposed to come up and say "Windows Protection Error. Restart your computer." I know this doesn't help your problem, but it's amusing...
er...
maybe those who have sb live and/or voodoo 3...
Why should I have to shut down my system and boot into mickeysoft pee cee land just to use a decent sound card and/or 3d video? screw that, I want to use these things in Linux!
This other story is maybe what I was struggeling with too. The new 2.2 kernel just does not simply concludes you have a regular PC type parallel port. It needs some more info (it's more hardware independant). Suppose you had a Intel like PC, /etc/conf.modules file (it worked for me):
you might try to add the following line to your
alias parport_lowlevel parport_pc
If autodection of the port fails:
options parport_pc io=0x378 irq=7
or whatever setting is appropriate for your hardware.
Hope this helps.
Alan Cox's wife???
I won't upgrade my windows until new bugs haven't been found for at least 6 months
well duh!
Of course I buy only Linux compatible hardware now! but what of those who convert to Linux after having bought a shitload of expensive goodies that are shackled to microsoft pee cee OS? I want to see these things get supported.
You have a short memory. back in '93-94, diamond video cards were to be avoided, because they made proprietary windoze only drivers and would not allow X programmers to see the specs so as to write X windows drivers. However, diamond saw the light, and Diamond video cards are some of the best supported under Linux (only recently have they been passed up by Matrox), and as for the Sound Blaster live, creative labs did hire a Linux device writer, and drivers for the sb live will be forthcoming!
None of this happens, however, unless informed buyers holler long, loud and often at the vendors who refuse to support Linux.
I agree. Why should I have 60 MB of code laying around for a kernel image that's 500k. Be cool if someone put up a web site where you can configure your kernel online and then download the compiled kernel.
Help me out on "a) Reset Hardware" .. if the currently running kernel's state is correct for the hardware's current state, then couldn't we set the new kernel's drivers to the same state and not reset the hardware?
On the linux-future list, people implied that the root account was no longer necessary if Linux used capabilities. UID 0 would just be another user. Sounds like some cool security ideas, but how would this work? How could the admin can retain control over the OS?
Someone told that some commercial Unix (I think SunOS or Solaris?) could do this. Is that true?
and most of the updates since the 2.2.1 kernel (which an exception or two) have been minor updates. This is much better than that other OS from redmond where you are stuck with huge amounts of bugs and that they only attempt to fix maybe once every six months or so (and they always include lots of new stuff with it so it never really gets stable). As someone pointed out though, check the changelog and see if you really need to update your kernel (who cares about NFS filesystem updates if you never use it? What good does alpha fixes do on your x86 box? and so on...). Anyways, happy compiling and remember...
always keep your stick on the ice...
(sorry, couldn't resist responding to a fellow Red Green fan)
That thing is fucking amazing!
Take a look at this video, and prepare to pHEAR.
Some of the main things, of course, would be new drivers (i.e. like some of these new multiple GB removable media drives, etc). Personally though, I'd like to see more driver support for a wider range of scanners and DVD ROMS. An update to the Amiga fs to allow mounting of floppies would be cool (I may be wrong though, but last I read it only supported Amiga filesystems on the HD) so I can still grab some of the old stuff I had on my old Amiga. And of course, they will always be working on havign everything run smoothly a wider range of CPUs (can you say Transmeta?). Aside from that I am sure there will be newer and newer hardware and stuff comming out in the years ahead to keep up on too. All in all though, there isn't much I'd want that isn't already in the kernel.
I was just wondering if anyone has had problems compiling support for a parrallel port zip drive into the kernel. It seems to work fine if it is a module, but the kernel fails to build if I try to compile the ppa driver into the kernel. I know I should probably file a bug report but I was wondering if anyone else had similar problems. I have been experiencing this problem for awhile now. I know it worked in 2.2.1, but I am not sure about any kernel versions after that.
Hey, one day I hosed all the 2.2.x kernels I had and used a old 2.0.36 one to remove and install again the messed up ones. It took at least three times more to do a quota check on the whole filesystem! 2.2.x makes the HDD light be almost always lit, while at 2.0.36 it blinks at 8Hz! (yep, _eight_ pulses a second only - and when it's fast).
It's a matter of relative importance. The kernel and gcc are the two most important parts of any linux system, so those two get more attention (and since the kernel is so young it gets more). As time goes by, projects mature and programmers migrate to other projects.
One of my favorite changes from 2.0.x is the graphical framebuffer console device on Intel machines. Now I can write directly to my Matrox by mmap()ing /dev/fb0 (that may not mean much to you). I love this feature!
root (uid=0) would be some user who happens to be able to do anything.
Right, Linux is supposed to be just CLI. None of this fancy audio, or 3D graphics. Heck, you shouldn't even be using X. Who needs a GUI? Not a real Linux user, that's for sure.
A lot of idiots rebooting your machines when a new kernel is out and shitting because X (no, it's not XWindow) is broken. If you're a h4(k3r and just want that all your friends know that you're using the latest kernel, try this: /fset format_version ^BBitchX-76a1+^B by panasync - Linux 2.2.6-ac1
Run BitchX (run as root, it has backdoors but you are a h4(k3r) and do a
YES, YOU'RE RUNNING THE LATEST AND GREATEST KERNEL AND YOU DON'T NEED TO REBOOT ANYMORE.
Serious, why the fuck you need to compile all these pre, ac and "stable kernels"? I'm very happy with my 2.2.4.
As for mounting Amiga floppies, don't hold your breath. The standard PC floppy controller chips simply cannot be programmed to read the Amiga disk format. Your choices are
a) to transfer the data via parallel or serial port from an Amiga
b) to install additional hardware to your PC: you can buy the Catweasel from http://www.jschoenfeld.com/ or build your own according to the instructions at ftp://ftp.panservice.it/pub/uae/afr10f.zip
HR
Yeah, all this people who are 'absolutely rude' about new kernels not being tested.
But its not that easy. In order to put the 2.2 series you have to upgrade lots of packages; Its almost impossible to
catch up with all the packages from a 36Kbps modem and compile them on a P166.
For example pppd. Ok wanna test new kernel but at the same time wanna have old good working kernel to get to the net 'in case'
But nooooooo you need to patch the kernel with the new pppd stuff. The new pppd stuff would not work with the 2.0.36 so we would need two pppds.
Not to mention some util-linux or something (the one with 'login') which sais "if you make a mistake you may be in VERY big trouble"
Then if you have an old libc5 system its not at all easy to get to the state which you'll be alright for the kernel.
Linus should have said: "Go buy RedHat 5.2 (or equiv) and THEN test the new kernel"
Nope I don't care if we reach 2.2.500 due to not testing. Aint in the mood of reinstalling everything.
Hehe, i have RedHat 5.1 and grabbed pppd 2.3.5 from RedHat 5.2 when i was running 2.0.35. Worked fine with 2.2.0 et all. Now i installed 2.3.6 and 2.3.7 and works fine too. I just don't patched the kernel with ppp and recompiled it. But i grabbed a new util-linux and a lot of stuff and when i rebooted with 2.2.0 compiled lilo 21, ipchains 1.3.8 and modutils 2.1.121 (i'm not sure if it's 2.1.121 or 2.1.122 or... too many numbers...). The only problem i had with 2.2.0 and 2.2.1 was a fucking device or resource busy (root partition) when rebooting. I now kill all manually and do a init 1 and ctrl+alt+del. Works fine... It's not good, but... i really never reboot. So it's not exhaustive.
I think it needs an updated driver
model, where the available parameters can be read from the driver itself (e.g. like a NDIS2 NIF file, but instead of a seperate file in the driver itself).
Something like like linuxconf could then simply scan the current modules directory for available modules, and present them with the options available.
This prevents users from having to browse through half a dozen readme files to find some parameter and its options.
Welcome to the new world of modern OS design.
If you're having problems, check out this easy to follow page, http://www.techni-cor.com/redhat/kerne l.html
Jesus H. Christ on a Popsicle stick! Every single time there's a new kernel release a bunch of idiots start whining the same old whine. "EhhhHHhhHhHHhh! But I just updated to 2.2.x-1! I thought it was supposed to be perfect and stable!"
Don't people understand this by now? Haven't the whiners learned how it works already? Nobody is forcing you to upgrade. If it ain't broke, don't fix it. Is there some critical feature or bug fix you specifically need in the new version? No? Then SHUT UP!
Like the WHOLE WORLD is gonna stop programming because YOU'RE TOO TIRED!
"Oh! Poor Bob is exhausted from performing the 2.2.5 upgrade! Well...instead of looking for further improvements, let's just stop all development and go camping for a week or so and give him time to rest up! Poor tired guy!"
Hey, if you got problems with there being bugs... the source is right there for you. Why not fix everything perfectly so you never need to upgrade anything again, forever? You can either be part of the problem or part of the solution. Stop whining and start coding.
Jeez, what are people gonna start whining about next?
"EhhhHHHHhhHhHhHhhh! My computer is too much work to use! I need to keep my head propped up looking at this screen! And these mouse buttons are SO HARD to click!"
I don't know what exactly FreeS/WAN has in it, but crypto export restrictions will probably keep it from being included in the regular kernel distribution.
If I recall correctly, to go from 2.0.0 to 2.0.18 took two months. Some of those early 2.0 kernels didn't last 2 days before the next patch came out.
The 2.2 patch cycle is moving MUCH more slowly than that. At the current rate, I suspect that we'll end up at around 2.2.10 before Linus declares 2.2 to be "finished" and opens up 2.3. After that, you should see a new patch every 3 to 6 months, depending upon what bugs are found in the new kernel and what features have been back-ported from the 2.3 series.
We'll see, though!
-- Eric
Send mail here if you want to reach me.
The semi-official position at LHS is that if you're using Red Hat 5.2, you should use the 2.0.36-3 kernel from updates.redhat.com. The only exception is if you are doing SMP, where the performance advantages of 2.2 far outweigh the disadvantages of using software that is still in active development.
Of course, I had downloaded and installed 2.2.6 here on my personal machine at home within 12 hours of its release (grin). (And found a few glitches in it, but that's another story).
-- Eric
Send mail here if you want to reach me.
2.0.x are extremely stable (in theory) and well-debugged.
2.1.x was the development series, where 2.2.x features were tested. It's finished.
2.2.x is the current stable version, with the 2.1.x features but well-tested.
People who claim its bloat have no idea what they are talking about. 1) The kernel has support for PPC, Alpha, i386, Strongarm, Sparc, and other processors. You dont need all this? Delete the files you dont need. 2) You compile a custom kernel. Anything that you do not need does not get compiled in to the runtime kernel. You dont need scsi support? Dont compile it in, and if you are that anal about disk space, delete the scsi source tree directory. 3) I could go on more about this, but most readers either are well informed, and those who arent probably wont get it anyway.
Does 2.2.6(etc) have support for some of the fancy new hardware like Soundblaster Live and Voodoo III?
Who am I?
Why am here?
Where is the chocolate?
What is your Slash Rating?
This leads me back to my original question: When is "eventually"? Is it next month? July? December? Of course, I can always run vmware to take advantage of it (and was planning to run it anyhow), but I'd love to have native support too. Incidentally, what's the big deal about "binary only drivers"? If they provide a driver, why should you care if they don't provide the source? It isn't like they've gotten on the Open Source wagon...heck, this is their livelihood. As long as there is a WORKING driver, we should all be happy.
Who am I?
Why am here?
Where is the chocolate?
What is your Slash Rating?
will take a look
Who am I?
Why am here?
Where is the chocolate?
What is your Slash Rating?
Only with KGI there will someday be games for Linux.
KGI might be useful, but there'll be games regardless. XFree has a lot more hardware company involvement than KGI/GGI.
I have 3D hardware acceleration for my Permedia 2v card already.
creative labs did hire a Linux device writer, and drivers for the sb live will be forthcoming!
None of this happens, however, unless informed buyers holler long, loud and often at the vendors who refuse to support Linux.
They're going to release binary drivers for the SB Live, which isn't adequate. So don't stop hollering yet. Wait until we have full specs, as well.
The voodoo3, on the other hand, should have open source drivers, eventually.
Yeah... but drivers don't belong in userspace (X) but in kernelspace (KGI)
Which is why I said KGI might be useful.
However, userspace drivers are better than nothing.
My old (PPA) Zip-drive works fine in Linux, but my mother has the same problem in Windows. In her case, it trashes all the icons on the screen and freezes the computer, she has to reboot into safe mode, and change to a lower color depth. (this doesn't happen in 256-colors or less) We thought it was a video card problem, but who knows?
:)
Darn proprietary drivers...
pb Reply or e-mail; don't vaguely moderate.
I'm not sure if it's QNX or one of the other quasi-embedded operating systems that advertises it can do just this (I don't feel like tracking down my old Dr. Frobs' right now). They included comments from some users about how QNX had *never* crashed on them, and didn't even need to be taken out of service when OS components needed to be upgraded. But it did sound like it was a quasi-microkernel, and it certainly would be easier to do something like that on a microkernel than on a monolithic kernel.
It's not an entirely far-fetched idea, although it seems like an extremely specialized need. Something that would be of much more general value would be the ability to add more hardware on the fly. For servers in particular, being able to add more mass storage would be very useful indeed.
It's a lot harder than it sounds! For example, you'd also have to do stack fixups because the call return addresses would be incorrect for the new kernel. You'd have to manipulate any kernel structures that were revised in the new version. You would loose interrupts and possably crash the system. Each module would also have to support the operation.
It'd be a cool feature, but it's way too much effort for too little gain.
IIRC, it is scheduled to be GPLed several months from now.
Actually, capabilities are a division of root capabilities into several smaller capabilities. That way, a particular process can be given only what it really needs. For example, binding to a port below 1024. Others include overriding file permissions, changing the clock, rebooting, etc...
Capabilities aren't meant to be attached to a particular user, they are attached to processes and executables much like suid is used now. The idea is to reduce the damage that can be done with buffer overflows and such.
For example, named needs to bind to port 53. Right now, root has to run it, and if a cracker can use a buffer overrun to get a shell, he's root. Under capabilities, named will only be allowed to inheret CAP_NET_BIND_SERVICE. Now, if a cracker gets a shell, he'll be an unprivledged user other than being able to bind to a low port.
Under capabilities, files have three capability sets, Permitted, Effective, and Inheretable. A file with something set in effective gains that capability when it is run (much like an suid root binary gains root).
The system utilities that need special capabilities would have those set in it's effective set. The utility would be responsable for authenticating the user. Alternatly, they could simply be set as executable only to members of a special group. For example, a group calles 'backup' would have access to the do_backup script which has capabilities to override file permissions.
On some systems, (home systems for example), one user (the owner) might be in all of the special groups. On more secure systems, nobody would be in all of the groups. Trust issues can be further reduced by sending audit logs to another system. The priveledged users on the local system would have no privileges on the remote system so that they can't alter the audit logs.
The most powersful capability is SETCAPS. That capability is needed to set capabilities on a file. On a really secure system, there would be only one utility with that capability which would require several passwords. No person would be allowed to know more than one of those passwords, so that alterations to security would require several people to cooperate.
Has anybody noticed whether ppp is now broken ??
Having upgraded to 2.2.6 from 2.2.5 pppd(2.3.7) now reports that ppp support isn't compiled into the kernel even though lsmod says the the slhc and ppp modules are loaded.
I've checked my kernel config several times to see if i missed something out, but it all looks good.
Anybody had the same problem/know a fix
Urgh... i meant 'IN' in the sense that the service was available to the kernel. Of course i tried it both as a module and compiled into the kernel with the same result and as the following post has 2.2.6 and ppp 2.3.7 working it looks like it's something else.
:)
Thanks anyway, i should have been clearer
Iggy
I try that next. It's weird. I also had a clean patch between 2.2.5 and 2.2.6, no warnings... Compile went cleanly.
:)))
I tried recompiling ppp 2.3.7 against the 2.2.6 headers, no change....
pppd just seems to refuse to admit that there is ppp support in the kernel, it's almost as though the service isn't being registered.
Oh the joys of using linux
Funny thing is... there's absolutely *NO* way i would go back to using WinBlows...
Ok, finally sorted the problem and yet again was reminded of a valuable saying.
.ppprc file. By creating an empty .ppprc file in my home directory all is peachy again.
/etc/ppp/ppp-options file which it reads from. Now all of a sudden with 2.2.6 it seems to NEED to have a .ppprc file in my home directory even though it's never needed it in the past.
.ppprc file and it doesn't kick up a fuss about a .ppprc file not being there !!!!
:)
"ALWAYS check your kernel logs"
I've been using linux for about 2 years and so i really shouuld have this ingraved into my brain. It's the same as always checking your cabling first if something doesn't work on the hardware side.
pppd for somne strange reason is looking for a
pppd has a
I can reboot to the 2.2.5 kernel, remove the
Go figure....
Thanks for all the various suggestions.
Iggy
Maybe your hardware is defective, perhaps substandard, or unstandard. It is hard to blame the kernel people for poor hardware support when companies aren't helpful donating drivers or assisting development.
For a rant, it's pretty poliet and informative. Perhaps there are other people with the same problems, who'd like to come out and share?
I see a lot of people here saying they expect all manner of neat features in the 2.3.x experimental kernels. However, I don't see any inkling of what these neat features might be.
One thing I, for one, would like to see, is for the FreeS/WAN kernel patches to become part of the regular kernel distribution..
What other features do we need/want in a kernel?
My basic strategy on upgrading is to read the comments on /., keep an ear open for a day or two, and then upgrade if there nobody's screaming. Updates to the stable tree are usually pretty important.
There seems to be discussions about capabilities though (check the last few Kernel Traffic issues). Which seem to do what ACLs do in other systems. Or am I mistaken?
I was suprised that 16 bit vga frame buffer support hasen't made it into linus's tree and only alans. /me compiles ac1
--
Scott Miga
If you mean 2.0.0 to 2.0.36, it seems to be about 2 years and 4 months
/jarek
Yes, it can be painful if you upgrade from something like radhat 5.0 or even 5.1. Upgrading from RH 5.2 shouldn't be much of a problem.
/jarek
That, ACL's and volume management (at least I believe that is a kernel issue) is what I need. Esp. ACL's. Unfortunately there seems to be litle interest in ACL's on the kernel mailing list. Anybody knows if there is a ACL project going on. The page most people were pointing to doesn't seem to exist any more.
/jarek
i'd love to see the raid patches integrated into the lvm patches.
plus i wish T'So would GPL his resize2fs programme.
swapping/adding disks and repartitioning would then be incredibly painless.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
tesla cox??
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
That's my list. I'm sure there are tons of new things. Ah, maybe USB support?
-andy
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
Can't wait until 2.3.xx ... Think of all the cool stuff 2.3.xx is going to bring us. I hope KGI and ALSA will be part of this...
xer.xes -- 4181
agree... but dev versions are most fun :)
xer.xes -- 4181
no, because both companies do not provide the information needed to make drivers.
who wants to have a sb live and a voodoo 3 when running linux anyway?
xer.xes -- 4181
KGI!
Only with KGI there will someday be games for Linux.
xer.xes -- 4181
Yeah... but drivers don't belong in userspace (X) but in kernelspace (KGI)
xer.xes -- 4181
Because nothing can be seperated....
Sorry, couldn't resist.
The Norton Anthology of English Literature, 4th Ed., Vol 2
$#1t! I ust d/l'd source for 2.2.5 and was just going to compile it! You know, It is the best quality of linux, from a non-technical standpoint, that Linux is a "living" operating system. That living "quality" is what attracted me to linux several years ago, and what keeps me certain that Linux is the o/s of the future.
;-)
But sometimes it is frustrating. . . just when you think things will stand still for a couple of days. . . not that I'm complaining.
"Eye halve a spelling chequer, It came with my pea sea, It plainly marques four my revue, Miss steaks eye kin knot sea"
I thought that 2.2.0 was supposed to be "the" stable kernel, completely free of bugs, and that nothing like 2.2.6 would even be needed. :-)
Sorry. End of sarcastic aside. Anyone know when development on the 2.3.x series will begin?
I bought my Zip drive in late 1995, not long after they came out. Paid $200 or more for it, and disks were bloody hard to find. (Yep, I also had to walk barefoot, 26 miles each way, in the snow, uphill, to get to a computer store.)
Thus, I'm inclined to think it may simply be ridiculously old hardware, perhaps some really early revision that the current PPA driver no longer knows how to relate to. I'm planning to talk to my sister's GF and borrow her (somewhat newer) Zip drive for testing. Wish me luck.
Well, actually, that's a long story. Since this will probably get moderated out of existence anyway, why not tell it?
From 2.0.33 to 2.0.34, both the SCSI and PPA subsystems underwent some hefty revisions. The end result of such was that, for all kernels newer than that (including most of the 2.1 series, 2.2pre, and all 2.2 kernels to date) cause interesting kernel panics whenever I try to mount my Zip drive.
I spent a couple months in close touch with the PPA/parport people, and some with the SCSI people. We simply can't resolve the problem. Yes, I sent in copious bug reports (under an old email address, no less). Yes, I did -DDEBUG for nearly the whole damn kernel (as the problem occasionally manifests itself in places like the VFAT file system, for no reason we understand). No, we don't have a bleepin' clue what's up.
Okay. Go give this a low score, modkins. It deserves it. It's a rant, pure and simple. But it felt realllly good.
It's been done but I can't remember the site's name. If you look around you'll find it. I'm to lazy to do it for you right now :\
ayottesoftware.com
Well, go tell the manufacture who sold you those cards!
shouldn't the hardware company be held responsible for selling you hardware that doesn't work with your system? Would you buy a AGP video card, if you had no AGP slots? So, you either:
1. Stop buying from companies who don't support linux, or drivers are not available for their devices.
or
2. Contact your manufacturer on a daily basis and DEMAND them to make drivers for your OS, or pay a programmer to develop drivers for your device and send the bill and the now GPLed drivers to the Hardware Manufactures so that they can repay you, and release the drivers with all their devices to their customers.
simple ain't it...
now which do you want to choose?
i thought so...
Its spelt "L-I-N-U-X", but pronunced as "Free Beer"
Umm Modules are not moduler? or gee patches ki of kinda work to.Even Windows 95 drivers are dependent on what version of win 95 you have. AT LEAST YOU have a option to upgrade. go try to buy a copy of win95 osr C. :)
"Think of it as evolution in action."
For servers there's more new stuff than you can shake a stick at. There's a ton of ip routing features in it, and the firewall code was reworked. Very nice.
Of course, I still can't get my parallel port to work, but that's another story. I would say upgrading to 2.2 was very painful for me, but I learned quite a bit in the process.
support gun control: take guns from cops
Once it's compiled, none of those drivers are in the kernel. And if you use a completely modular kernel, you can have that once it's compiled.
Most people don't need to recompile their kernel anyway, since it comes with the distribution already compiled with support for modules.
good enough for me. just get the darn thing to work please
---
It might be FreeBIOS, the GPLed BIOS... Unfortunately I know very little about the project. I think it was supposed to be possible to start a new kernel on the fly, but only after a shutdown -h :-(
Again, I'm not really sure.
/* Steinar */
(This comment is of course GPLed.)
This might be because the compilation of PPP patches the kernel? (Or more correctly replaces some files.) Then you won't have the correct source to patch from, and the patch will be screwed up. Funny that patch didn't complain when applying it! (_If_ this is the case at all, of course.)
/* Steinar */
(This comment is of course GPLed.)
That sort of comparison is best dealt with by
sites like www.linuxhq.com - I think there's
a blow by blow "what's new in 2.2" thing by
Jason Pravenich (sp?) there. At any rate, all
you need to know is linked from linuxhq.
A defective Zip drive that's isolated from the CPU bus by a parallel port should not kernel panic the system. The Zip drive itself should simply not work, and not take the system down with it.
(It's a different story when you have defective hardware on either the CPU bus, or even on the SCSI chain, because it can affect the computer's ability to operate correctly at all. The parallel port, though, is a pretty effective means to isolate hardware from the rest of the system.)
--Joe--
Program Intellivision!
Because new drivers may have a slightly different set of state transitions. Also, the state of the hardware may change while the kernel is being reloaded. (Think "masked interrupts".)
--Joe--
Program Intellivision!
While I'd dearly love to try one of the 2.x.x kernels with a RedHat disk, even though I am a RedHat subscriber, I have YET to hear anything from my friends at RedHat about a kernel later than 2.0.36. So where IS the newest release with the newest kernel??? I have spent the last two days on a 56K never-to-be-sufficiently-damned modem trying to find, all over the Internet, all of the fracking files that are required before you upgrade beyond version 2.0.x Why the hell can't all these files be located in one fracking location, or at the very least, why can't we maintain a current list of the places to find such things??? The list included with the kernel 2.0.6 has a pointer to directory listings that aren't even CLOSE!!
I don't mind working to keep Linux up to date. It's actually one of the joys. But please, do not mislead me!
Benny (Xitron)
You might be interested in this guy, who has a working X server for voodoo 3 / banshee. No 3D yet, but according to his site, it's on the way.
I have noticed that 2.2.x series are MUCH faster on my system. In X, screen redraws, windows maximizing and minimizing, app startup - ALL much faster. It's a zippier system. Then again, I have a Celeron OC'd to 450mhz and 128 mb of RAM. Maybe the 2.2.x series runs better on fast hardware? Who knows. I ain't complaining.
There is also more hardware support, etc...
I'm about to state the obvious, but evidently it isn't obvious to some people. It depends on who you are and what you use Linux for.
If it's a production machine, the answer should be "hardly ever". Here "production" means that you'll have a bunch of pissed-off users or lose money if the machine has problems. Upgrade only when some critical problem is found (like a security hole that's actively being exploited by the script kiddies). Don't switch to 2.2.x until things get a bit more stable (2.2.6 is a large change, indicating that 2.2.x probably still isn't ready for use by ISPs or to run your business from). 2.0.36 is a pretty solid kernel; we know that it works. Folks with earlier kernels without a firewall between them and the net probably should go to 2.0.36 for the added security fixes.
If you have a machine inside a firewall that's carrying on some useful function (a server for filesystems, www or printers), just let it sit and brag about its uptime. Don't upgrade it ever until you want the machine to do something new. If it's still running 1.2.13, cool.
If it's your personal machine and you like being on the edge, build every kernel. Have a blast.
If you're somewhere in between (it'll be a pain in the butt if you hose your machine, but not a disaster), wait at least a week before installing a new kernel.
-- Give him Head? Be a Beacon?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
-- Give him Head? Be a Beacon?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
surely this can already be done to some extent?
.o file.
It's my understanding that modules work by having a special allocated ELF section for the parameter data, and an unallocated section for the module description, parameter format description etc. When insmod loads the module, it interprets the parameters according to the description and pokes the vlues into the parameter area, then hands the allocated sections to the kernel. ?
If so, this would mean you can at least retrieve the names and format (string, integer etc.) of the parameters from the
See the MODULE_PARM, MODULES_DESCRIPTION (?) etc. macros in the kernel source.
-- i will protect you from ideals to save you from defeat
I don't know about about QNX, but I know that WindRiver's VxWorks can do this. You can also upgrade a running application without shutting down the (embedded) equipment.
ppp (2.3.7) runs perfectly with kernel 2.2.6 as a module, as I am running that combination to send this. I suspect that the error message may be due to something else.
Though ppp 2.3.5/6/7 have all stated that you do not need to patch 2.2.x kernel sources, but only need to build pppd.
#1 its a diferent development model.
#2 this is why they release patch's
#3 You dont have to go to 50 diferent places looking for an obsucure driver written by a company that went out of buisness 3 years ago
#4 you can always tar.bz2 the source tree for
later use. (though keep linux/include else you wont be able to compile anything
#5 Utter convience. the win95 cd contians maybe 1/10th of the driver base for the entire platform.
and most of them are outdated and useless anyway.
#6 grabing modules off the net can lead to problems. This is how virus's and trojans are spread.
#7 who dare said you could speak out aginst linux.
BURN HIM!@#@!#$@!#!@$!@#!@#!@#$@!#@!$!@#$!@#@!#
I WANT MESA DRIVERS FOR TNT. but hey i am not blaming anyone other then nvida for being smug ignorant a**holes.
May 3dfx always render my polys.
Seems to me that since you have to shut all the processes down anyway, we can just acheive the same effect by allowing people to overwrite their uptime with a fake value. :-)
RC5 cracking sped up by something like 150% to 200% on my system when I upgraded from 2.0.36 to 2.2.1.
That's what patches are for.
DrWatt
ppp support isn't compiled into the kernel even though lsmod says the the slhc and ppp modules are loaded.
.. if it's compiled as a module it's not compiled IN to the kernel .. change your config to change the PPP support option to Yes (Y) and not Module (M) and all should be good.
Er... Anyone else see it ?
Delphis
If 2.3.xx goes the same way as 2.1.x it'll be like Linux 2.3.xxxxx .. with the amount of revisions that were brought out because it was a development version (odd minor version no.). Stable distributions (even minor version no.) are the ones really of any use if you don't like the idea that it might go belly-up during operation (not that I've ever had that btw).
Each to their own I guess. But as mentioned before in this thread, if you don't have anything of dire need for upgrade, don't worry about it.
Delphis
Hmm.. can you say 'patch file' ? :)
Delphis
...the ability to upgrade our kernel without rebooting! :-)
:-).
:-)
From what I can see, the kernel image is copied bytewise into memory on boot-up. Once we're finished with compiling a new kernel, why not have the old kernel copy a mini-kernel into memory that would do nothing but overlay the old kernel image in memory with the new kernel image, and then pass control to the new kernel?
(Of course, we would have to find a way to keep track of the current state of the kernel, (probably by swapping the kernel structures to a file, and then swapping those structures back in to the new kernel image))
If we disabled all interrupts when we switched kernels, and suspend all processes (which should be easy..since we're running in ring zero)..why wouldn't this work?
Think about the massive benefits of this! Think about the uptimes we could have with this!
Subjects says it all... When I'm trying to access my NTFS partition, the Sym56cXXX driver keeps resetting. Mounting is slow, but works.
This is your sig. There are thousands more, but this one is yours.
I don't think it is so tough, except that the Linux kernel is a massive piece of software not designed to do this, and it would be a lot of effort to change it.
:) which I wont go into here.
It really only needs a totally module based kernel (or a micro kernel). You have a very simple module system (easy to debug), which can load more complex module systems. Then you can swap modules easily (using an auxiliary module to convert the data on the fly between the two). With this mechanism you can even upgrade the more complex module system.
The only restriction you need to apply then is that you must have an appropriate auxiliary module for the upgrade.
Even the overhead of making calls into modules instead of static code can be avoid with a little ring 0 magic
Now you just need to make the boot code take parts of the boot image (modules required for booting) and run the module loading functions on them.
Or even, just always update :)
;)
It's easy to compile a kernel, and diffs are small.
It works for me anyway - But I would suggest staying a week or so behind (unless there's something you *really* need), because there's sometimes a serious bug introduced which takes a while to be found. Let one of the wannabe hackerz kill their system first
There's one around somewhere, but I wouldn't advise using it unless you trust the people who run the site. Imagine the security flaws they could add. They could spot when you enter a login password, and send it to themselves. Or they could do worse (I can't imagine what, but the password thing is so simple there has to be worse ;).
Mozilla doesn't get as much attention because for a long time it was huge, nearly impossible to compile, and if you could get it to compile, you didn't get a working product out of it. Only die hard hackers get into systems like this. Now w/ M4 and possible a beta release coming, this might change. I really hope it does.
-matt
I once heard about a project which intended to do exactly this.
Unfortunately I can't remember the URL nor if it's been active since then, but I wouldn't count on it, since it's been, um, a couple of years since they started it.
Furthermore, I can think of several huge problems when trying to accomplish this - the internal kernel structures may not be compatible with each other from version to version. Yes, you could write a subsystem which could convert the old data from one version to the next, but how about if you jump more than one version..? Not to speak about the -ac patches.
Trust me, I for one would like this to happen, but I'm just too pessimistic about the possibility that may be accomplished.
"Linux currently has an average uptime of 99.9923%, and we're working hard to fix the bug."
- Unnamed Linux vendor
Q: How does a Unix guru have sex? A: unzip;strip;touch;finger;mount;fsck;more;yes;umount;sleep
I think that about the only way to do this is to bring the machine back to the state where the boot loader is functioning and reload the system. Somehow I don't think that really counts as 'uptime', since the only difference is the power cycle and the 10 seconds while the POST runs and your BIOS detects your hardware (if you have a bios that does that kind of thing). It would be an ultra-soft reboot.
-Cheetah
here I go again, just get the patches downloaded and then do the change thing again.
okay I am sort of new to linux, and I have to say I like it, but one quick question that I would like to know, how long did it take from the release of the version 2 kernel did it take to get to version 2.36.
"sometimes I wish I was blind I thought I saw a whole lot more than this"
Do you think we upgrade just because we have nothing else to do? (Well, sometimes you're right :-) .) But people upgrade because they _know_ that the fix for the latest exploitz (to use your way of saying plurals) and _awful_ bugs are there. Every time I check the diffs, I see some _obvious_ bug fixes (if you can't recognize one, you're not a programmer) that could _have_ hurt me.
:-) ).
Update early, update often (sorry couldn't resist
We need to shut down the hardware to avoid mandelbugs. Never asked why all the linux boot loaders turn off the floppy drive motor? To avoid undeterministic state that could cause unexpected bugs depending on the exact point of operation, system heat condition, and the phase of the moon.
The Right Way to do this is to make a full dump of the system state (processes etc.), load the new kernel in the memory (compressed), install a trampoline in memory, and jump to it. The trampoline would:
a) Do the required hardware shutdown (to avoid undetermined state). Doing this without breaking a modem connection is left as a exercise to the reader.
b) Disable NMI and interrupts
c) Dump the kernel structures (ps tables, etc)
d) Change the structures to match the format in the new kernel (the 1st hard step)
e) Load the new kernel with a special flag. It will initialize, reinitialize the hardware, check the flag and jump back to the trampoline.
f) The trampoline disables NMI and interrupts (again)
g) The trampoline restore the kernel structs (now in the new kernel's format), calling special __initfunc functions in the kernel to alloc memory and setup the new values. It also reloads the modules the same way.
h) The program states is undumped (the 2nd hard step) by the kernel (called from the trampoline).
i) The trampoline jumps to the kernel, which cleans up and frees the trampoline and its data.
j) The kernel sends a SIGKUPD (kernel update) to all processes and runs schedule.
k) The update program notices the signal, and call the bootloader to setup the boot block (so if you have a power outage here the kernel to run will be the new one).
Note: the process dumps are to the disk (root directory, probably)
The hard parts:
0. Generating the trampoline.
1. Converting the kernel structures (doing this automatically, with version gaps of 2-3 minor numbers, is pretty hard).
2. Restoring the processes state. Some sutble things have changed, and will crash many processes. The signal to make them re-exec themselves helps a bit, but legacy (ahem) apps will suffer.
The 'hard part number one' is the worst one.
Stable does not mean "there are no problems with this" - it means "we aren't going to make any significant changes to this."
regards
So, tell me, exactly what got added to bloat the OS?
These releases are necessary mods to keep the high quality reputation of Linux. The frequent patches ensure issues are addressed when there is a problem (c.f. Windows, where you are lucky to get a patch at all, certainly months later than you needed it, and which probably totally screws your system when you install it)
This is a stable release. No big splendiferous features are being added that could *possibly* be called bloat.
if you are not having problems and you have scanned the list of mods and can't see anything that would affect you, then don't upgrade it. Save yourself the effort. You don't need to do it.
If you are having problems of one sort or another, it might help. If a fix relates to something you use, or a security issue, then you should consider updating.
It isn't compulsory to upgrade the kernel everytime.
2.2.0 pre 1 Late December
2.2.0 Final early january
Vote early, vote often! Oops, Release early, release often.
Don't be unhappy, fast kernel releases are a very good thing. As new things are added, you get your hands on them.
Remember, I'm pulling for ya; we're all in this together!
If you want to play it safe, go for the even numbers (as a newbie, it's probably your safest shot.) If you really like bleeding edge, and want to help out with bug reports, then by all means go for the odd numbered 'developer releases'
hanzie
********* sig: If you don't like the law, get filthy stinking rich, and buy a better one.
You'll be waiting a while then...
It wasn't until 2.0.30 that any 2.0.x kernel lasted 6 months without an update. Before that the record was 2 months. Compared to the release record of the original 2.0 kernel, we're doing pretty well.
I've heard that OS/9'll do this. Not positive though.
Why do they keep doing this godammit? It's not
like all I do is play with my computer all
day. I don't have time for this...oh wait, nevermind.
A noble spirit embiggens the smallest man -Jebediah Springfield (a.k.a. Hans Sprungfeld)
Because its a LOT harder than it sounds. As you point out, you have to keep track of the kernel state.
:)
Swapping it to a file is ONE way, but remember, when loading the kernel, THERE IS NO FILE HANDLING FUNCTIONS! Everything you might take for granted once the system is booted is simply not in place while the kernel is booting...
Besides, this is simply not that important of an ability. Most people do not switch kernels everytime a new one is released. I'm still using 2.2.2, and would still be using 2.2.0 except for a bug that caused support for my soundcard to be disabled.
Most people will upgrade their kernels MAYBE once a year, probably closer to every TWO years. Its simply not that big of deal to have to reboot once a year...
My journal has hot
There was a lot of talk about ACLs in 2.3.x on the linux-future list. Check out the archive.
Capabilities now seem to be the big topic on the list these days, though..
cpeterso
Capabilities and ACLs have the same purpose: access control. They're just different ways of specifying what actions users can invoke on OS objects (like files or sockets). An ACL is a list attached to the object, listing which users can access the object. A capability is just the reverse. A user has a capability list, which lists which actions he can perform on which objects.
ACLs and capability lists each have different pros and cons. To me, ACLs seem cleaner and easier to admin. You have a centralized list of everyone who can access this object. Capabilities are (supposedly) more flexible because you can programs can pass around capabilities for special actions (like giving someone the key to your car).
NT and some Unicies use ACLs. Off hand, I don't know of any (non-research) operating systems that use capabilities. Does anyone know of such a system?
cpeterso
Ok.. My question is why are there 3 diffrent kernals 2.0.x 2.1.x and 2.2.x???
Didn't 2.2.5ac7 come out friday?
I ate my tag line.
-=Ellis (D)25=-
I wish other projects got as much attention as the kernel... mozilla comes to mind
There's two main reasons to upgrade your kernel:
1. To fix a problem with your current setup, or add an additional feature that you really want.
2. Some folks just like to upgrade thier kernel as much as possible... they like to drive it around and report (or try to fix!) bugs.
If you can't find a good reason to upgrade then don't upgrade. If your system works, why fix what ain't broke?
Jono
I found this by going to Linux Weekly News and looking through the archives for the week that 2.2.0 came out. Hope this helps.
That happened to me once, and no one could ever help me. It happened after I patched the kernel between versions(no errors were seen during the patch). The way I fixed it? Rebooted back to an older kernel, downloaded the newest non-patch, and recompiled. It worked great. Or you might want to try just untarring the old 2.2.x tree you have, erasing the current one first, then patching it.
This is the first time the "standard" kernel has supported non-intel processors, so for those, its pretty much a no-brainer. For intel, there are devices that are only supported in the 2.2 series. Also, some new software coming out may require 2.2 over 2.0.
Changes aren't permanent, but change is.
If you want to see what people are talking about AFA new kernel development, kernel traffic is a handy summary of discussion on the Linux kernel mailing list which comes out once a week. Its announced right here on /.
Changes aren't permanent, but change is.
I find it amamzing how fast new kernals are coming out for linux. The linux community is really moving fast to devolpe new kernals. Do they really need to fix this many things. For a while I use to update my kernal every time a new one was relased. I think I'm going to just sit back and wait for 2.3 now. My system is stable and I don't want to mess with it. What reasons are there for updating every month?
Is there an official line on when users should or should not upgrade their kernel?
With more an more Linux users with less experience -- some might have only known enough to fumble their way through a RedHat5.2 install -- there needs to be guidelines.
Is it a case of don't fix it if it ain't broke or are there new features to be reaped from newer kernels?
I think this must be an important area to be marketed in order to forge ahead with world domination!
--
Rare Window - free your photos
First, there is the Kernel-HOWTO (on the LDP)
Second, usualy, you shouldn't upgrade if the new kernel doesn't have something you need. Usualy, revision kernels have mostly fixes (In 2.2.6, the revision is 6), most updates are in the development kernel, (2.1, was for the 2.0 stable,but it hasn't started yet for 2.2) and in minor updates, like 2.0 to 2.2. Anyway, you should read the Kernel-HOWTO
-- Hiroshima '45... Chernobyl '86... Windows '95...
It is a microkernel: Most of the components that are in the Linux kernel are seperate processes. This way components like the block filesystem support can be terminated and restarted without say interrupting the networking. And if the new block filesytem support segfaults - another version can be started. This is similar to support being developed with the HURD. In a way this is cheating; the actual micro kernel is not upgraded, because there is no need to. All it does is start and stop processes, and pass messages.
-- http://thegirlorthecar.com funny dating game for guys
Good point. I think most of us reboot primarily for new kernels--though I still stray to the dark side about once a week for a massive session of gaming...
-- That tickles!
Thanks, Tesla and Nemesys! The links were rather helpful.
Hi everyone. Okay I'm not new to Linux but I'm no programmer. I've upgraded to kernel 2.2.6 -- probably due to my M*cr*s*ft mind-set that takes over from time to time -- upgrade! submit! comply! /dev/null) please explain the advantages/differences of 2.2.6 over, say, 2.0.36...
But in all honesty I have *no* idea how the 2.2 series differ from the 2.0 series RedHat ships with.
Could someone here (strip sarcasm ; cat witty_asides >
Thanks! May segfaults never darken your monitor...
At this rate we'll see 2.4.0 before summer's
out!
Why not make Linux more like Windows?!
It's called a patch. It's small and lets you upgrade your kernel easily. Try it someday.
(Microsoft's "patches" are MUCH larger)
-meisenst
Green's Law of Debate: Anything is possible if you don't know what you're talking about.
Why don't you complainers take 2 seconds to read a changelog, and if you need things that have been changed, then update, if you don't then screw it! damn...fooazz