Slashdot Mirror
Future of 2.4 and 2.6 Kernels
Blair16 writes "According to this article on C|Net, not everybody is chomping at the bit for the new Linux 2.6.0 kernel. Marcelo Tosatti, the appointed deputy for the 2.4 kernel is not expecting to make any non-crucial additions to the popular kernel, saying that all new projects should be pumped into the new 2.6. This has upset some people who are not quite willing to move to so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold?"
From the linked email:
Having that mentioned, I pretend to: - Fix pending problems which might required more intrusive modifications during 2.4.24. New drivers will be accept during this period (for example, Cyclades PC300 driver, input userlevel driver support, or other sane driver which might come up). - From 2.4.25 on, fix only critical/security problems.
Heh, so that solves the issue of being a kernel maintainer with little time on your hands, only pretend to do stuff :)
From the story text:
. This has upset some people who are not quite willing to move to so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold
Seriously, are people expecting major changes and new features to be added to a kernel that is supposed to be the stable branch? Doesnt this stuff belong in 2.6? or hell, even 2.7? I for one wouldnt like my kernel to constantly have new and untested features when its supposed to be production capable!
Linux kernels are generally released when ready and not sooner.
I don't know, but shouldn't someone actually test it to become tested? This is the way Open Source works, everyone should help developing the software, even non-programmers, by testing, and I guess the kernel team won't release something for production until it is ready for.
The IT section color scheme sucks.
Hasn't this discussion been held before? Stable kernel remain just that - Stable.
New features always go in new releases. Since 2.6 is around the corner, any new feature need to go in 2.7 now. Big deal. Move along, nothing new or interesting to see here.
How do these guys have any credibility? Aren't they just fanboys for whonever buys ads, or for whomever [SPIFFY CONSULTANCY COMPANY] says is the Next Big Thing. Want information? Ask RedHat. Ask Linus. Ask the folks at SuSE. What's next, Slashdotters panicking when Dvorak weighs in on kernel patches?
I want to delete my account but Slashdot doesn't allow it.
Of course people want new features AND stability.
Pretty funny.
He sent another mail later that he ment "intend".
;)
Apparently enough people had sent him a patch for that one
If the "well tested" 2.4 kernel were to be adding new features, such new features might risk making it unstable, therefore the time-tested status it has would have to be restarted.
If 2.6 isn't "well tested" enough for your production servers, wait a while. The test of time will perform itself... of course, if you want the new features, you'll just have to take the plunge because somebody's gotta do the testing...
I think the benefits of a few bugs outweigh the problems they may cause. If I can save 5 million dollars in a server deployment and there's a slight risk of a crash but my data is safe then I'll run that risk.
However some companies are still running RH 7.2 so there will be those who stick with the 2.4 kernel as long as they can. This will more likely be the groups that are unable to move their software from 2.4 to 2.6 due to how they built their systems possibly.
Does anyone know if this new kernel will support nVidia's nforce2 motherboard? I have it and use the integrated ethernet adapter, but I can't it to work in Linux. It'd be nice to see support for it compiled into a kernel perhaps, or maybe offered as an easier-to-use module. I'm a total newbie, but the learning curve is somewhat steep.
I for one welcome our new lazy-ass overlords
Fortunately, there are a few really interesting technologies that have received surprisingly little attention, but which I believe point the way toward Linux overtaking Microsoft, and perhaps even Apple on the desktop:
- Dashboard
- Zero Install
- Gnome Storage
These projects are the future of Linux, they are novel ideas that will allow Linux to leap-frog its non-free competitors on the desktop. It is a shame that they receive so little attention.This is a wonderful idea where a "dashboard" essentially acts as a memory augmentation tool. It watches what you are doing and presents information it thinks might be relevant. For example, if you are chatting with someone on IRC, it will look for information about that person and present it to you (such as their name, homepage, recent blog entries etc). Applications can support it by sending it "clue packets" to alert it to what it might want to pay attention to.
This software essentially eliminates the process of information by mapping web-servers to the filesystem, and combining this with a fast local cache. If your software relies on another piece of software, it can just refer to its binary or libraries on this "web" filesystem, and the appropriate files will be downloaded transparently. The next time you need them, they will be cached. It is infinitely cooler than DEBs or RPMs, and very flexible indeed.
This project blurs the line between filesystems and databases, creating much more flexibility than is possible with more conventional filesystems. This is particularly powerful when combined with Zero Install. Microsoft is also moving in this direction with their WinFS that will be part of Longhorn.
Cnet article:
Marcelo Tosatti, the deputy that Linux leader Linus Torvalds appointed to maintain the 2.4 Linux kernel, said in a posting to the Linux Kernel Mailing List this week that the follow-on 2.6 kernel is mature enough that it should be the foundation of new projects.
Tosatti will accept some significant changes and some support for selected new hardware in version 2.4.24, now under development. But versions 2.4.25 and beyond will be released only to fix security problems or other critical issues, he said.
"2.6 is becoming more stable each day, and we will hopefully see a 2.6.0 release during this month or January," Tosatti said in a posting to the Linux Kernel Mailing List on Monday.
The 2.6 kernel is in final testing, and its maintainer, Andrew Morton, said in November that he expects to release it in December. The new kernel includes several features, such as the ability to work better on large multiprocessor servers, that are expected to make Linux more appealing to corporate customers.
Tosatti's decision didn't sit well with some who are reluctant to move so soon to untested software.
"I am terrified of the following scenario, which is extremely probable to happen soon," responded Jan Rychter in a Wednesday post. "2.4 is being moved into 'pure maintenance' mode and people are being encouraged to move to 2.6. While people slowly start using 2.6, Linus starts 2.7 and all kernel developers move on to the really cool and fashionable things. 2.6 bug reports receive little attention, as it's much cooler to work on new features than fix bugs."
But shifting attention to the new kernel isn't unreasonable, D.H. Brown analyst Tony Iams said. "It makes perfect sense to me that they'd focus on putting new features into 2.6," he said. "As soon as the new release is ready, the old release goes into maintenance mode. Any software release is going to work that way, whether commercial or open source."
The discussion about 2.4 and 2.6 was triggered Monday by a request by Silicon Graphics programmer Nathan Scott, who on Monday asked Tosatti to accept SGI file system software called XFS. Tosatti rejected the software, saying advocates should submit it for inclusion in 2.6, though he later relented somewhat.
File system software controls how information is written on hard drives, and XFS is a "journaling" file system in which logging features make it easier for a computer to recover from a crash. Three other journaling file systems--ext3, ReiserFS and IBM's JFS--have been accepted into the 2.4 kernel.
SGI developed XFS for Irix, its version of the Unix operating system, and said in 1999 it would contribute XFS to the Linux community. But SGI's handling of the software has led to a chilly reception by some--including Al Viro, a deputy who oversees Linux file system work.
SGI's emphasis could change, however, Iams said.
"Historically, it was true that SGI has focused on Irix as the primary platform for XFS, but I wouldn't be surprised to see tha
Microsoft no longer develops for Windows 98... Apple no longer develops for OS9...
So they don't want to move on to "untested" 2.6? If people added features to 2.4, it would become just as untested. Nobody's saying to halt all development on 2.4, just not to add new features. Stability fixes will still go in... heck, stability and security fixes are still being added to 2.2! Those who don't want "untested" software favor stability and security anyways... so stick with 2.4.
-3Suns
~~~~
The Revolution will be Slashdotted
Well then "some people" can get off their butts, or cough up the cash to do it themselves. It's amazing how some people who use free software think that the developers owe them something.
Erm, no. They wrote it, they can do what they like, how they like and when they like. They don't have to put in features if they don't want to. They certainly don't have to justify their work or decisions to anyone except their contributing peers. If you don't like it please whine to somebody else. Nobody is stopping you from backporting code or doing it yourself.
this discussion happens every time there's a new stable kernel version. people get mad, the new kernel is a bit buggy at first, but then things smooth out and pretty much everybody upgrades unless they don't need to or don't want to..
move along folks, nothing to see here.
The logical volumes manager (device-mapper) is still incomplete in current 2.6 kernels.
:
Snapshots don't work without an experimental patches.
Other patches are needed to make EVMS properly work.
This is a showstopper.
However, if you don't need virtual volumes, yes, 2.6 definitely
1) rocks
2) is stable.
{{.sig}}
But for slightly different reasons. It's not like 98 was terribly stable or anything. :-)
(\(\
(^v^)
(")")
This is the cute vorpal bunny virus, copy to your sig or runaway, runaway in fear!
Checking SCO site, I couldn't find anything regarding the new 2.6 kernel, so I guess no additional fees are charged over the 2.4 kernel, you can upgrade guys with no worries.
The IT section color scheme sucks.
Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold?
Of course they will, and they will get the traditional open source answer to such situations - "If you want it so bad stop whining and do it yourself. Nobody is stopping you, and, after all, you do have the source. See how great open source is? If this were Microsoft you would be stuck, no source, no nothing."
I personaly do not see any problems with this. If someone want the latest and greatest in the current version of the kernel. They can either port it themsevles or pay someone to do it for them. This is the beauty of opensource. In any case the major vendors of linux will do this at times the featues is really wanted by thier customer base.
Get Movie Posters
i will get a 2.6.xx kernel when most the major distros start packageing them with their distros...
Mandrake, SuSE, Slackware, etc...etc...
Sorry but this the way the world of software works. The old version gets put into maintainance mode and eventually is retired. In the Linux world as far as kernels go users and companies have much better deal then they get in the commercial closed source world. For example company X wants to stay on 2.4 for some odd reason. Once 2.6 comes out 2.4 will still be around and updated for security flaws AND they can add/remove/improve 2.4 inhouse any way they want. Sounds like these people just want OSS hackers to continue to do free work for them on an old kernel without regard for the natural order of things. It's all a bit selfish really. They are course free to migrate to an OS where they have Zero control over the kernel and when updates stop, they just stop.
If you wanna get rich, you know that payback is a bitch
In the meantime, there are some bugfixes that look like new features; that's the way software works. There are some new features that look like bugs; ditto. We know that security bugs are considered vital no matter how old the kernel (well, to a point). And so someone often will fix that.
All that to say that it's called "software" because it's squishy and can change (or be changed). And there's nothing besides lack of time that keeps you from including a new feature in 2.0, 2.2, or 2.4 and putting up a patch archive to support your favorite feature/fix that "someone" really should have put in long ago. To paraphrase my Subject line, "one man's trash is another man's treasure".
According to a statement by a company spokesman, Microsoft is not expected to make any non-crucial additions to the popular Windows 98, NT4, 2000 operating systems, saying that all new projects should be pumped into the new Windows 2003 server, or Windows XP. This has upsome some people who are not quite willing to move to the so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold?
PJRC: Electronic Projects, 8051 Microcontroller Tools
And it's working great. That's 2 weeks without rebooting.
Now, I don't do anything critical or really strain the kernel at all, but it works great...never had one lick of trouble. It's also very peppy!
But for people running critical servers and the like, I can understand their reluctance.
"Music is everybody's possession. It's only publishers who think that people own it." - John Lennon.
Marcello's position means that the 2.4.x will become much more solid than any Linux kernel has ever been. As new hardware is introduced, there will be pressure to accept drivers to support popular hardware. I expect that Marcello will accept drivers as necessary for 2.4.x to run on popular hardware -- after all, such new drivers impose minimal risk on users without such hardware. I welcome this development, but will keep on open mind as time prove its merit or lack thereof.
When Linus released 2.4.0, there was a several
month pause before opening 2.5.0. This was to
allow continued bugfix and stabilization work
to happen on 2.4.0. It seems reasonable that
he would do the same w/ 2.6/2.7. So, there should
not be any fear of 2.6 suffering from developer
inattention in the several months after release.
If Linus doesn't release 2.7, the developers can't
ignore 2.6.
i would gladly buy linux (No SCO license though) with APIs that supported games like D2 and CS if someone wuld make such a linux
idea?
*resistance is futile, or fuzzy, i dunno*
if variable2 or constant are 0, the statement evaluates to false.
+5 Informative
Their example is of people who are using XFS with a 2.4 kernel. These people are (according to CNet) "upset" because XFS won't get added to 2.4. Now just think about this for a second: they are using XFS with 2.4 right now! So obviously, they are not being prevented from doing what they want. The whole issue (which CNet is trying to make out as a big deal) is that these people wish they didn't have to perform an extra step (applying a third-party patch). I hardly think it's going to kill these people to keep on doing what they have been doing for a little while longer (i.e. until they decide that the 2.6 series is sufficiently tested that they're willing to trust it). No one is being "left in the cold".
Actually, to be fair to CNet, they're only mildly misrepresenting the situation. The major source of confusion and misrepresentation is (as usual) the slashdot summary.
Exactly what are they bitching about? If they don't want to run untested software, they should run 2.4. If they want new features, they should run 2.6.
So, if untested patches go into 2.4, does that make them anything more stable? The logics of this just escapes me...
I'd like to point out that the nature of open-source de-emphasizes the importance of central decisions such as this.
Linus and his helpers are the de-facto maintainers, yes, because people find they generally make a good job of it. AFAIK the only legal claim they have is to the name "linux".
If you want the 2.4 kernel line to still have new features added, fine. Download the source, add the features, put it up for download. You could even apply the security and stabilisation patches from the main tree to your "experimental" tree..
As you can read here and here there seems to be strange things going on with memory management in the new Kernel, so please beware and protect your data. By the way, this is probably not related to PREEMPT.
This isn't a problem. A kernel is a kernel, not a complete OS installation. If 2.6 doesn't work dandy, people can (freely) hop back to 2.4 until 2.6 is solidified, even if it has "gone gold".
This doesn't even begin to sound like a problem. They'll be on 2.6 soon enough - whether it's a "tried platform" sooner or later.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
If you want to know better the status of XFS read up on the lkml. The cnet article doesn't even explain the good reasons not to include it. Even in 2.6, just in the last couple days, some serious issues have cropped up with it. At there has been some indication that XFS is related to the slab corruption.
There is very little reason to include it in the stable 2.4, when there may be unresolved issues. I'm not saying that you shouldn't use XFS, but it needs more work than to be in 2.4 by default. Lets face it, XFS has alot of cruft still. The main development right now is in the unstable branch 2.6, which is basically XFS's status. If XFS wants to prove it's stable enough for 2.4, it should do so in 2.6, and then it will get back ported then.
Generally, when something is not ready for a stable line, it doesn't have enough people using it. Even linus said recently that he knows very few people that use XFS.
people don't have to use it. They can tell Marco and Linus to fuck off for stranding them after they told their execs that Linux was better and more stable - which might be the case for the server uptime, but perhaps not for the development model.
And the companies that make money off Linux, especially the ones like Red Hat who have yet to use any sort of 2.6 for anything, who EMPLOY people who make major contributions, don't have to continue to contribute the time of their employees.
Open source may not mean the developers OWE you something, but there are expectations that are fair, like not abandoning the current standard before the next one has already come out!
Come on!
If you want to use 2.4, keep using it.
Sheesh, there are still 2.2, and 1.2.13 boxed kicking around doing work.
If you don't need new features, you can keep using an old kernel.
If you need new features, you probaly want a new kernel anyway.
For future reference, the term is "champing at the bit", not "chomping at the bit":
http://www.brainydictionary.com/words/ch/champ1
Its a equine/race track metaphor. When a horse wants to run and you hold it back it impatiently grinds its teeth.
Chapel Hill, NC
Am I the only one who is tired of setting up joysticks on Linux by inserting kernel modules. Couldn't RedHat et al come up with a nifty configuration tool like Microsoft's joystick tool in the control panel?
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
The total opposite is true in this case. Marcelo is the maintainer of only one particular fork of the 2.4 kernel. If some one/group wants XFS in the stock kernel, he/they can petition for his/their own kernel to be Linus' 2.4 kernel.
That is the beauty of open source. Myself and others can't fire Steve Ballmer. Only the M$ board of directors can do that. Using the open source process, all of us working together can get Marcelo and his kernel fork replaced. That's what I will be working towards.
But let's be honest. With $CO being mercilessly beaten by IBM, it sure feels good to be a Linux user again.
The big deal is that there IS NO 2.6 yet! How can we have the maintainer of, what is as of this writing, the current branch of Linux saying nothing new is going in?
Seriously, if 2.6.2 or 2.6.3 were out, this would be a much different scenario, but we're only at 2.6.0-test11, so refusing to add new features to the newest non-development kernel strikes me as a major league bad decision!
This has upset some people who are not quite willing to move to so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold.
This is really not true, since almost ALL the features in the 2.6 branch are available as patches for the 2.4. The 2.4 branch has achieved a nice level of maturity and adding a lot of new stuff to it now makes no sense.
The people complaining should learn the magic of open source. They should realise that at any desirable time they can start mantaining their own tree with their desired features. Hell, starting a new tree is not even necessary since there is such a big variety of 2.4 trees around that the feature they want is most likely already beeing supported by someone else in one of them.
I don't get your point. He is about STABILISING 2.4 kernel, NOT about adding new and new features to vanilla kernel and so causing maintaining 2.4 kernel difficult. It's stable now, so let's leave it alone. If you want use XFS with 2.4 kernel, do your patching and go. No one forbids you to do that. And about a trust - I trust my Linux systems. Only because I run them by myself. Not because Linux development is somehow more superior that FreeBSD (or vice versa).
user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
http://uptime.netcraft.com/up/today/top.avg.html
What's the point in using (and developing) deprecated software? I mean, who seriously uses 2.0 and 2.2 now? nobody.
Comment removed based on user account deletion
I agree, and C/NET articles usually repeat their concerns, even the most minor ones.
I personally use 2.6 test 11 and while I can't tell if it is anymore stable than 2.4, it is much easier to compile (very few errors vs. vanilla 2.4), and the layout is far easier to understand.
I think it is a good thing to make people move to the 2.6 for new features. The 2.4 kernel will become more stable as less features are added, in theory, and it is open source. I mean they can just add the code themselves like what SGI mentioned about what they did with XFS in the article.
> Want information? Ask RedHat. Ask Linus. Ask the folks at SuSE.
Yes. I mean, God knows those people won't be biased. It's only Linus' most famous accomplishment. He's a good guy, so he'll not have the slightest bias what-so-ever in any way. And RedHat's not supporting their business model on this stuff, are they? And SuSE, well, they're Germans! That alone should tell you that they'll have no bias for something that their income depends on.
Just name 2.6.* something like 2.4.(*+26). Then they continue working on 2.4 Or maybe just tell the idiots to get lost.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
Since 2.4 won't be getting anything other than bug fixes, you won't have to contend with other people making other changes.
You just grab a copy of tree and start your own development.
You get your stuff stable AND TESTED and then you talk to the maintainer about adding it.
"I am terrified of the following scenario, which is extremely probable to happen soon," responded Jan Rychter in a Wednesday post. "2.4 is being moved into 'pure maintenance' mode and people are being encouraged to move to 2.6. While people slowly start using 2.6, Linus starts 2.7 and all kernel developers move on to the really cool and fashionable things. 2.6 bug reports receive little attention, as it's much cooler to work on new features than fix bugs."
What insight! I can't imagine how anybody could see that far into the future as Jan Rychter.
So many people use the "cooler to work on new features" argument without evidence. Since when has Linux favoured new features over fewer bugs? Linux 2.4 bugs receive plenty of attention, thank you very much -- so do Linux 2.2 bugs and 2.0 bugs.
Isn't the joy of the OSS model, that if this were truely a problem, a group of users (presumable corperations interested in the viability of thier 2.4 kernel) could get together to create and maintain a patch for the 2.4 kernel that would back port more then just the critical updates from 2.6? I thought that the whole point of having an open model was to allow everyone to mess with the code to make it fit their needs. I know there is always a fear of forking, and that someone will bring up the issue, but there are many patches some like the -ac patch even get posted on kernel.org.
There has alwasy been a gap between the needs of buisness for stable and realiable software and the desire of enthusiests for the latest and greatest. as Linux continues to gain share in diverse markets, I antisipate that the number of patches will likewize increase, making a kernel that can meet the needs of several different types of users.
JFMILLER
Strive to make your client happy, not necessarly give them what they ask for
No more security breaches will occur with the new kernel, like with GNU/FSF, GNOME, Debian, and now Gentoo, all just this year alone.
Otherwise, you get a ton of security breaches all in the span of six months, like with GNU/FSF, GNOME, Debian, and now Gentoo. It's anybody's guess as to who will be next.
The kernel maintainers have been clear on their reasons *not* accepting xfs into linus's tree (see prior posts in this thread). Considering that so many of the people who clamor for xfs (imx) are kids who're principally attracted to it's rep for high performance, yet have no concept of the tradeoffs delineated above -- well I can see why it's not being accepted into mainline. I'm sure if SGI actually cleans up the interface it'll go in but who knows if _that_ will ever happen.
Marcello on XFS:
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
What??? Tosatti says he's going to concentrate on ultra stability for the next few 2.4 releases, and you use this to advocate FreeBSD? That makes no sense.
In fact, Linux 2.4 will have bugfix and security releases for another year at least, following 2.2 and 2.0. Meanwhile, FreeBSD EOLs each x.x release after 12 months.
What's better now, kid?
it's like 2.0 and 2.2
they've been worked on up to airly recently.. well.. 2.2 anyways.. but they were being worked on way past their shelf life, namely due to the fact that there are people with older machines that dont need usb.. or the latest hardxware drivers because someone with a 486 is less likely going to need support for a ATI radeon 9000
same mentality for 2.4...
there's going to be people with computers (like me) that arent going to be the latest bit of technology and wont be upgraded any time soon..
so keep working on the 2.4 kernel just keeping basic features in sync with 2.6 (vulnerabilities that need patching, etc)
Damn I miss. How do I next story?
I think the package you need is xlibs-dev. Try it out and let me know. I am watching this post.
What release date?
2.6 is on feature freeze as it should be. But to end the entire kernel series forcing an upgrade to a new kernel that doesn't exist yet? How can you tell me that's not premature?
I wish someone on the kernel team would consider this issue from a user's perspective. Sure, I understand their objections to binary drivers on a moral and a support-headache perspective, but what options do the users have?
nVidia: binary-only drivers, but mostly stable
ATI: binary-only drivers, unstable and out of date
Everybody else: my favorite game is "Unreal Tournament 2003:The Slideshow"
I sympathize with the SGI developers, about the inclusion of the xfs filesystem into the kernel. The reasoning for this is because there is a perception that something that is not included into the main kernel branch is unstable, which is absolutely wrong. So it is beneficial for a developers to have their module included into the branch, so it can be considered a proper part of the kernel. I think this is a major weakness to how the kernel releasing structure it set up.
Honestly, I would like to have this releasing structure changed. For example, filesystems don't need to be inside of the kernel branch, only the virtual file system. Let the distributions take care of putting all of the different filesystems into their kernel branch. The kernel branch should be the base point of all the other distribution branches. If you want ext2 in your kernel then go to the ext2 guys and grab the patch and apply to the kernel, no more inclusion. I have already heard people state that patching should not be done by a regular user, which is correct; but that is why you have distributions that have there kernel branches with all of the filesystems they think should be included. No more arguments why one module is inside of the kernel branch and the other isn't.
Linus and his maintainers can now only worry about the main system and let everyone else deal with there on patches. If your patch needs a change to the kernel branch then you talk to Linus and his maintainers. Which they decide if it is a good idea, or if you need to change something in your code. This would lower the amount of releases of the main kernel branch, since there is a smaller amount code that can be changed. Also the releases can be base on if a interface to the main system has been changed which effects the other patches, or just a fix to the internal code. This can lead to easier maintenance of other patches. The more code that can be taken out and put into there out tree the better. Kinda like having a hierarchy of trees.
This can lead to cool pseudo linux distributions where one can say I have xx branch of the kernel. This is already happening like mm-sources, redhat-sources, etc; But taking out the favoritism of the main kernel developers. This could also solve a problem with the size of the kernel source tree in the future when there is tons of different drivers,filesystem,etc.
This is just an example of what it could be like, and I am sure there is more that has to be look at; but think this approach has some credits.
Nothing more, For me to say; About my life, A life of dreams....
A well designed dual AthlonMP2800+ in linux/openMosix is mainly more quicker than a single AthlonXP3200+.
In linux/openMosix/bsd, we always use the system's call fork.
open4free
Well noone ever stoped working on Apache 1.x and look at all the people that have switched to 2.x... Oh wait, almost noone has switched to 2.x yet because people just kept working on 1.x. noone has even bothered to port most of the modules to 2.x _correctly_ yet.
And so it will be with Linux 2.6.x
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
>> This has upset some people who are not quite willing to move to so-called untested software.
If you use Linux, or plan to use Linux, and you are not testing 2.6 under YOUR particular install and usage patterns, and reporting all issues up to the kernel team, then forfeit your right to complain if it breaks anything when you install next year.
I have a really old Microsoft Intellimouse pro. .. bla bla bla! :(
yeah, yeah, yeah, microsoft this
But I like this mouse so much that I am willing to do anything to extend it's life. Even if I have to do a frankenstein and replace the mouses organs at some point
A bad analogy is like a leaky screwdriver.
Now, this comment is mildly off topic, but the article in question does show up a problem with the current structure of the Linux kernel, namely that drivers (including filesystem drivers) are closely intertwined with the workings of the kernel at a source level.
Currently, there is no way that you can have a totally stable kernel and yet have device drivers and filesystems develop independently. To do this, Linux would need at the very least a standardised device driver and filesystem API or better yet, a standardised ABI which doesn't change for the lifetime of a major revision.
All the major commercial UNIX's I know of have a standard ABI for their drivers, as do Windows. This is why you can still get hardware developers who maintain and release versions of device drivers for old releases of kernels for those operating systems for new hardware, because they can. I'd like to see someone try doing that for the current crop of Linux kernels.. oh yes, which version and sub-version from who's source tree was that for?
Not having a standard ABI for drivers helps cause a support hell, not only for end users, but as demonstrated here, the kernel maintainers as well.
Agrajag: "Oh no, not again!"
All in the span of six months. It's hilarious watching the Linux boys squirm with each new announcement.
How legitimate a gripe this is really depends on what people think they'll be missing. Linux kernel modules mean that slower updates to the kernel don't necessarily mean anyone will be left out in the cold. Things that are currently supported via kernel modules may still be supported and updated by whoever maintains those modules, it's just that those updates may not make it into Marcelo's (Linus's) kernel. Whether or not those 2.4-based modules get written and/or updated is somewhat independent of the issue of whether or not they get bundled into an official new 2.4 update past 2.4.25.
Of course, if they're worried about missing out on new scheduler or vm features, or other more central kernel functionality... well, that's what new kernel versions are for.
Now, Apache uses a BSD style license but they have an open development model which allows them to take advantage of a very large developer pool in order to stay ahead of their competition. In fact although proprietary versions of Apache exist which perform better than the official releases, SGI has put out some open source patches which generate even larger performance boosts. This is the reason why they have such a strong showing in terms of market share.
BSD once had potential but the procedural problems they are experiencing hurt it when it comes to the market. I suspect that this is probably in part because the BSD teams are not interested in such things, and that is a shame... In fact, although I labeled it as an inferior OS, this is not due to lack of progress within BSD -- it has been progressing somewhat, but rather because all the improvements they make tend to be quickly copied by their competitors AND they lack the developer pool to stay ahead of this game (a problem which does not exist in the Linux or Apache communities, though for somewhat different reasons).
I don't think that there is enough widespread support for BSD to save the operating system. What must be done is an opening up of the development process OR a GPL-style restriction on redistribution. In many ways I favor the former.
Even in a worst case scenario, I don't see BSD completely dying. I think the developers are less into competition and more into a sort of idealized cooperation. As a result, even if BSD becomes more marginalized, I don't think that it will die outright. It will most likely outlive Netware, for example.
this is like MS saying that we're not developing any new features for Win 98 two months before Win 2000 is released
Bull, it is! If MS did this, people would be in an UPROAR about forced upgrades. Face it, most Slashdotters EXPECT Microsoft to provide new features but they defend Linux stopping development on their stable product before the next version is even released.
People who want these features can use one of various patchsets floating around. (Con Kolivas for desktop responsiveness, various others for grsecurity, xfs etc.) It was ever thus (I remember when 2.2.x-acy had a following approaching that of vanilla 2.2.x.
Besides which, most users will get their kernel upgrades from their distribution's updates package system, and except for debian which sticks closely to Linus' kernels most distros include well-tested versions of most of the patches that have been backported anyway. Certainly they almost all have xfs.
This is a lame story - 'new' features have very rarely gone into stable branches; occasionally drivers get merged when they touch very little else in the kernel (i2o in 2.2, Cyclades in 2.4) but no really new big chunks.
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
Alright...so they don't want relatively new and untested code...but they want new features. This so sounds like something Dilbert would get as a request, doesn't it?
For your security, this post has been encrypted with ROT-13, twice.
You mentioned background spellchecking as a Microsoft innovation - I'm interested as to when they invented that.
:)
On my old Atari ST, I had a word-processor called Papyrus, which had an identical squiggles-under-the-words spellchecker. The program was dated 1995 (I think, and it was version 3.66 so it could have been an older feature) - when was the Microsoft version introduced? The first I time I saw it was in Office 97, although I wouldn't be surprised if the Papyrus version was a direct copy of a Microsoft implementation.
One feature from Papyrus which has been 'co-innovated' is that of discontinuous text selections; I've read that modern versions of Office now offer it. Who came up with that idea? The ability to, say, select all text in Swiss 721 Bold, any font size, and apply a uniform subheading style in a few mouse clicks is brilliant. But who was first?
User interface concepts seem to spread all over the place, and apparently forgotten ideas get rediscovered or genuinely reinvented - it's one of the aspects of 'innovation' that gets very complicated. Who came first, and does it matter when one implementation is better than another?
Here's how You should understand this issue:
linux-2.4.0.tar.gz is 24378762 bytes
linux-2.4.23.tar.gz is 37010062 bytes.
So you can expect 2.4.25 etc. won't go over 40 megs compressed. That's what a "stable" kernel development stands for.
(BTW it is kind of weird thing that a stable kernel has grown so much)
We've run our MMOG's on Linux (Red Hat flavor) for years now (migrated away from IRIX when we use to run on Challenge/Origin 2000s). Linux is amazingly stable, but it took awhile for 2.4 to get that way. It wasn't "out of the box". We need our OS to be up... well always. Five 9s is nice. And Linux goes the distance. Failures tend to be our fault, not its.
On the other hand we also had a heavy-load database running on NT for 3 years non-stop. It came to a stop only when we decided to shut it down to get a clean slate on something (an optional thing). But the fact it had run for 3 years without a glitch was amazing too. Lots of people doubt NT can do that under any serious production stress, but I can attest that it can.
We are anxiously awaiting 2.6 because the scheduling problems in 2.4 show their ugly head very obviously for us. We get by for now, but can already see how 2.6 will make life better. But 2.6.1 will probably be the first we try unless we hear amazing success stories.
David Whatley
Try "guinea", "dago", or "WOP" if you want a legit insult for those half-eggplant bitches.
I'm a technical PHB. I started working as a System Admin back on SCO (the original) Xenix in the late 80's. I'm still fairly technical and hands on, but now, at 36, I manage a team and make purchasing decisions, etc., as well.
This is simply WAY WAY WAY too early to talk about stagnating the 2.4 kernel. It feeds directly into the "open source is really a bunch of geeks who are far more interested in shiny new baubles than core business requirements!"
2.6 isn't out yet. And it's not known when it will stabilize (my definition of stable is when revs "live" for more than 30 days).
It's quite possible that a 'stable' 2.6 won't be out for a year. Then it needs to be tested, and a migration plan (since this is NOT a 'build and drop in' kernel) put into place, and that tested.
Easily 18 months or more -- and that's assuming that as soon as the kernel stabilizes, it becomes a company priority to migrate.
Again, MS loves to tout "with open source, you have to build your business around your solution, rather than building your solution around your business."
Big companies don't want to be on this treadmill, they don't want to develop and maintain their own kernel team and kernel tree -- they want stuff that WORKS. And having your own dev organization is a fast way to spend more money than buying someone else's solution.
Hopefully this won't come to pass. But sadly, the fuel's been added to the fire.
Steve
not too long ago I loaded SuSE 8.1 pro on a new 'puter; 8.1 is a release about a year or so old and definately a 2.4 series kernal. I installed the XFS filesystem, primarily to spite SCO, but was plesantly surprised with its performance, its much faster than the reiserFS i had previously used.
Apocalypse Cancelled, Sorry, No Ticket Refunds
Oh ... Get ... Lost.
Slow news day at ZDNet? This is such a non issue, it's silly. Of course 2.4 users will not be "left out in the cold". There will be plenty of time to feel out the 2.6 kernel before 2.4 is abandoned completely.
Let's get real people... Even the 2.2 kernel was last updated in March. And just because the fine people at kernel.org won't make any significant changes to 2.4, nothing is stopping any number of 3rd party sources from doing so.
You know I believe I remember Alan Cox adding new drivers to the 2.0 series after 2.2 was released. There was a while when you didn't want to touch 2.2 because it wasn't quite there. It wasn't nowhere as bad as 2.4. I think that one was released before it was golden. I can't comment on anything prior to 2.0 though. My first kernel was a 2.0.20 something.
In Republican America phones tap you.
there are several meaning of the word "innovative". sweetcode mainly is about interesting implementations, strange programming languages and such. this may (but doesn't need to) do anything for non-programmers.
I disagree, in this case.
2.6 is getting more positive reports and more good buzz on lkml than I have ever seen for a 2.x stable series. There can be no comparison to 2.4's rocky childhood, for example.
I think 2.6 is going to be the smoothest early stable series yet, and that 2.4 is going to be looked back upon as a relative stinker. The subtext in Marcello's posts about 2.4 imply that he thinks the same.
Sometimes I wonder if the difference between 2.4 and 2.6 is the change in the development maintainer's (Linus') source control model -- that is to say, he finally started using one (bitkeeper).
It seems many slashdotters miss the point in its entirety.
SGI is not complaining that XFS is not in 2.4 yet, they are complaining that it never will be.
It will not always be "EXPERIMENTAL, UNSTABLE" code.
They simply wish to see that when it is considered established, safe, and stable that it can be included in an established, safe, stable tree.
And now it never will be. People who want it, though, obviously either know what they are doing, or are so stupid they deserve to get screwed. Those people can apply the patch(es) without breaking a sweat.
(and by the way, before I commented, my first reaction was also "so what? 2.4 is stable, XFS is unstable, just like it seems most of you have pointed out repeatedly)
Back in the day, when everyone was excited for the 2.4 kernels to come out, I was waiting very eagerly. You see, I had just purchased a quad-processer machine, and 2.4 was supposed to scale much better than the 2.2 series. Now, as should be imagined, this wasn't a "toy" or "testing" machine, it was a production database server that the entire company depended on.
When 2.4.1 came out, I downloaded it, compiled it, and installed it on the production machine. It purred along beautifully. I completely forgot about it.
Some time later, the o(1) scheduler patches came out, so I downloaded what was the then-current version, 2.4.17. Here's where it gets good: The database server with the 2.4.1 kernel was still running.
No, I don't mean that I was just still using it. I mean that it was *still running*. It had never been shut down, crashed, or had a reboot for any reason.
Based on that experience, I'm not terribly worried about using the 2.6 kernels.
Oh, you're not stuck, you're just unable to let go of the onion rings.
Is to try out 2.6.0-test11 which is the latest at this point in time.
Correction ATI:Open Source drivers acctually work. Provide OSS developers with documentation.
"We Don't Need No Truthless Heros!" - Project 86
Floating point seems screwed on powerpc, preempt is dodgy, the must-fix list goes on forever, not to mention the should-fix.
:/
Just plain unprofessional, if you ask me. 2.6.0 should be READY
I guess we'll have to wait another four years before we have close to decent support for cheap file backup.
When I have backed things up onto CDROM, I have done as follows (these steps could be abridged/changed/etc.-- they are the way they are because it made it easy for me to organize the material and maintain the solution):
1) Copy files into a staging folder (not necessary, but makes them easier to organize, if you have the space). I would often do this using smbtar, tar, etc. to copy and archive certain directories. The relavent backups would then be tar archives (compressed).
2) I would make an ISO image and pipe that to cdrecord.
This would all be scheduled by Cron. It is not perfect, but then it took me less than 1/2 hour to set up one day for a network of 5 or so systems.
Free tools, 1/2 hour setup time (a little shell scripting). Cheap hardware and media. I call that an inexpensive backup. Do you have a problem with this solution?
BTW-- anyone have an answer for this one-- if you have a tar archive and you append another file onto the end with the same name, is there a way you can choose which file you can extract from the archive? Any tools out there?
LedgerSMB: Open source Accounting/ERP
I have a couple of servers with AIC7xxx SCSI RAID arrays. One of them gets a mysterious timing problem which leads to a kernel panic from not being able to mount the root filesystem. It was supposed to be fixed in 2.6.0test11, but it ain't. 2.4.x works fine on that machine.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Blimey, I stand (fully) corrected!
Remember kids, it's all fun and games until someone commits wholesale galactic genocide.
The kernel is there to let all these spiffy things talk to the hardware. Code to shove a lot of bits as fast as possible out to the video hardware belongs as a kernel module, but things that define what these bits are are done elsewhere.
IMHO the previous poster has got confused about the difference between the kernel and applications. Gcc is not a linux thing, It is an application I can run in windows, while ideally all the applications mentioned in the above post should compile and run on a mac, and be happy to do things via the mach kernel.
These projects are the future of Linux, they are novel ideas that will allow Linux to leap-frog its non-free competitors on the desktop.Forget the competitive ideas, we just want something that is good. Things that will only run on linux are a disadvantage, not an advantage - if we ignore being able to run on multiple platforms we run into problems like the emacs split (due to the developer adding support for X windows, which was seen a bad idea by one person, since hurd did not support X and the main mission was hurd).