Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux Kernel 2.2.6 Released 147

Posted by justin++ from the happy-now,-jes? dept.
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.
This discussion has been archived. No new comments can be posted.

Linux Kernel 2.2.6 Released More

Linux Kernel 2.2.6 Released

Comments Filter:

  • help on updating (Score:1)

    by Anonymous Coward
    If you're having problems, check out this easy to follow page, http://www.techni-cor.com/redhat/kerne l.html [techni-cor.com]

  • People are Stupid (Score:1)

    by Anonymous Coward
    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
  • 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

  • Why. (Score:1)

    by cduffy ( 652 )
    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?
  • 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?
  • will take a look


    Who am I?
    Why am here?
    Where is the chocolate?
  • 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... :)
  • 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.

  • PPP (Score:1)

    by Iggy ( 1156 )
    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

  • PPP (Score:1)

    by Iggy ( 1156 )
    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

  • PPP (Score:1)

    by Iggy ( 1156 )
    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.

    "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 .ppprc file. By creating an empty .ppprc file in my home directory all is peachy again.

    pppd has a /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.


    I can reboot to the 2.2.5 kernel, remove the .ppprc file and it doesn't kick up a fuss about a .ppprc file not being there !!!!

    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 [opensrc.org] 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.
    • Journalling patches for ext2fs
    • devfs (device file system, virtual /dev tree)
    • ALSA? :)
    • V4L2


    That's my list. I'm sure there are tons of new things. Ah, maybe USB support?

    -andy
  • 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...
  • agree... but dev versions are most fun :)
  • 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?
  • KGI!

    Only with KGI there will someday be games for Linux.
  • Yeah... but drivers don't belong in userspace (X) but in kernelspace (KGI)

  • Because nothing can be seperated....

    Sorry, couldn't resist.

  • $#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. ;-)
  • 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?
  • My own personal, utterly untested, working theory is thus:



    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 :\
  • 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...

  • 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. :)
  • People talk about the SMP stuff all the time, but the fact is 2.2 has some very nice desktop features too. Mainly fbcon (slrn in all it's glory!), support for TV cards, more filesystems, joysticks, etc.

    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.


  • 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 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 */
  • 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.

  • Maybe your hardware is defective, perhaps substandard, or unstandard.

    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

    --

  • 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

    --

  • 2.3.x (Score:1)

    by horndog ( 6938 )
    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 [xxedgexx.com] 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.

  • The most noticeable change is in the Speed. When I upgraded to 2.2.0 from 2.0.35, There was a good 150% speed increase.


    -- Give him Head? Be a Beacon?

  • It's damn near impossible to release software with "no bugs." It's impossible to forsee every hardware configuration that the software will run under. Linus even said himself that it would be dumb to assume that there wouldn't be later 2.2.X kernels.


    -- Give him Head? Be a Beacon?

  • surely this can already be done to some extent?

    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 .o file.

    See the MODULE_PARM, MODULES_DESCRIPTION (?) etc. macros in the kernel source.
  • 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 (Score:1)

    by grahammm ( 9083 )
    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.

  • PPP (Score:1)

    by Delphis ( 11548 )
    ppp support isn't compiled into the kernel even though lsmod says the the slhc and ppp modules are loaded.

    Er... Anyone else see it ? .. 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.
  • 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.
  • Hmm.. can you say 'patch file' ? :)
  • ...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.
  • 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.

    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 :) which I wont go into here.

    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.
  • 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
  • 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.
  • 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.
  • 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
  • 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.
  • 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... :)


  • There was a lot of talk about ACLs in 2.3.x on the linux-future list. Check out the archive [linux.org].

    Capabilities now seem to be the big topic on the list these days, though..


  • 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?


  • 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

  • Here's what you (probably) need.. (Score:3)

    by Telsa ( 29774 ) on Saturday April 17, 1999 @05:42AM (#1929231) Homepage
    Wow. A question I can answer. That's rare. You probably want to look at Joseph Pranevich's list of changes [lwn.net] which was put out in January for 2.2.0.

    I found this by going to Linux Weekly News [lwn.net] and looking through the archives for the week that 2.2.0 came out. Hope this helps.

  • 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!
  • 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
  • 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!
    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 > /dev/null) please explain the advantages/differences of 2.2.6 over, say, 2.0.36...
    Thanks! May segfaults never darken your monitor...

Slashdot Top Deals

A physicist is an atom's way of knowing about atoms. -- George Wald

Close