Slashdot Mirror
2.6 and 2.7 Release Management
An anonymous reader writes: "A recent discussion on the Linux kernel mailing list debated whether the upcoming 2.6 and 2.7 kernels should be released at the same time instead of first stabilizing the 2.6 'stable tree' then branching the 2.7 'development tree.' The theory behind the proposition is to keep "new" things from going into 2.6 once it is released, focusing instead only on making it stable. On the flip side of this argument is the possibility that with a 2.7 kernel in development, there will be too little focus on stabilizing the 2.6 kernel.
The resulting debate makes for an interesting read."
I am doing fine with 2.4.x, but release fight? How can it be possible, just release the thing.
I think 2.6 should be patched first. Coming from the west siiiiiiiiiiiiiiiiiiiiiide.
I will not be updating for a while. The neverwinter nights developers should be as fast to release their linux client, as the linux developers are to release kernels. Good job linux hackers. Bad job neverwinternights crew.
there will always be a kernel in development and one being stabalized.... its a wash either way.
i would recommend the stabalization of 2.6 before the branch of 2.7 (the initial arguement) and i think the flip side is incorrect... just because 2.7 is 'in the works' doesn't mean that the 2.6 hackers are going to take a nap on their work
MARIJUANA, SHROOMS, X: ONLINE?! - E
Keeping the kernal stable is much more important than adding more features. That's why most of us have migrated to linux in the first place.
If I don't have to reboot in 6 months or beyond, then I'm happy with that.
Opensource=Openmind=Freedom
I would release them at the same time. Just as now, with 2.4 and 2.5, there are people who are very good at stabilizing current code, and people very good at developing new code. Some folks can't stand working on new things when the old need work, and vice versa.
I see this as having two benifits. First, it will help with the ``Most things work pretty well---let's go ahead and release it.'' attitude. The 2.4 series has only recently gotten stable enough to reliably use in a production environment, and not everyone agrees on that even.
Second, it will allow people to focus on what they are good at. The 2.6 series will mature much faster without adding new features in every release. Sure, there are bound to be a few gotchas, but if the focus is on stabilizing the code, they will be out by the 2.6.3 or 2.6.4 release. At the same time, people will be adding to 2.7, which should mean that there is much less time between stable kernel series releases.
I'm all for it!
--Wyatt
Karma: Marginal (mostly due to the border around the website)
It's spelled "kernel".
You must be one hell of a lunix user.
"2.6 and 2.7 Release Management" - Most Boring Slashdot Topic Ever!
Isn't this a problem faced by most software projects? Stabilize resent release (bug/feature fix) or move team to next version/revision.
I would recommend dividing the team up.
See, to me when someone calls it a "stable release", that means it's already been stabilized. Sure, you're going to have the occasional bug fix here and there, but actual "stabilization" should've been done in the 2.5.99 range, ie. the previous development branch. Once the stable tree is released, there shouldn't be a need to stabilize it and branching the new development tree right then makes sense. There should not be an "development" per se in the stable release after that, only the occasional maintenance.
.0 release of the kernel.
If the kernel maintainers would just grasp this one simple point, maybe this issue wouldn't be one, and maybe people wouldn't laugh at the
From the bsd world, there is the concept of "backport" which is where a feature in the development kernal is ported back to a previous stable kernal series.
Great for bug fixes, and other things in the middle ground.
Certainly if there is interest, a set of patches to a stable kernel, or even another -someone kernel series can be developed. If these turn out to be in demand, and stable enoug, they can be officially included.
A large reason for the awful VM mess that 2.4 was in around 2.4.8 - 2.4.11 or so was largely due to the fact that a totally new VM was just kind of "thrown in" to the "stable" branch, probably mainly cause there wasn't a 2.5 branch yet at that point (as I recall). This is the sort of thing that branching earlier would hopefully prevent. While the stable branch may not have some of the "bells and whistles" it could have gained from keeping the branches together, at least hopefully a mess like that can be avoided.
Then again, that's just my opinion :)
It can only lead to improvement. Remember the whole affair of dropping in a completely new VM right in the middle of the supposedly "stable" 2.4 kernel branch? BSD has never had problems like these, and it pains me to see Linux doing silly stuff like that. I await the day when I can safely assume that something located in the "stable" branch really is stable.
Friends don't let friends use multiple inheritance.
The linux kernel,. besides stability .. what sort of things do they want top add/improve?
.. such as being able to allocate how much CPU, memory, or disk space a particular user or process can use. These are things that solaris has had for a long time .. and it seems that linux kernel developers arent interested in adding those features .. how can linux hope to take over the enterprise server market without it?
better networking? better I/O performance?
what about multiple CPU support?
The most important thing for me would be resource management features
Does anyone have any info on what's happening in the area of adding resource management features to the linux kernel?
Actually any info on what cool features they are working on for future releases would be appreciated
...would be a good idea IMHO if this kept Linus away from working on the stable branch.
Look at what happened with 2.4, we had the change to VM, 2.4.11 which needed immediate patching and is tagged as dontuse, 2.4.13 similar problems, 2.4.15-greased-turkey released by Linus for Thanksgiving and a nice syncing problem.
When it comes to deciding what is and is not allowed into the kernels the buck stops with Linus. This is why I think Linus should stick with the development kernels where a major change can have all its kinks worked out in relative safety. The stable branches should be maintained by someone who only has authority to accept and apply bug fixes.
I've got a fever and the only prescription is more COBOL.
When it comes to how much resources a particular use can, well use, PAM is your friend. It can limit data, ram usage, CPU time, number of processes, and user priority.
Spencer Ogden
Linux kernel development is slowing down rapidly with current economic situation. In the next year or so Linux could be facing the same situation that FreeBSD is now. I mean windows will always be around as long as Microsoft is around and Microsoft isn't going anywhere but linux is just a bunch of dudes hacking. What happens when Linus, Alan and others start getting bored and give up the JKH did.
I know what you mean. Everyone always talks about how much more stable GNU/Linux is compared to Windows. That's why I switched. I was using Windows 2000 Professional, but I haven't noticed much of an honest improvement. Sure, it doesn't crash as hard as Windows ME and earlier do, but what's the point of stability if my web-browser (one of 310981209 to choose from) crashes every ten minutes. Is the the browser? Is it some faceless kdieninitd arts oaf esd bonobo program crashing in the background? I guess I'll spend MY friday night re-installing Windows 2000.. :(
Most of our opinions on this really dont matter. I have run unstable kernels for a long time and never had any trouble with them. The only time it is really an issue is with production servers, which most of us dont run. I think those of us who dont run production servers should refrain from submitting our opinion and leave the line clear for those who it really affects.
Im not here now... Im out KILLING pepperoni
Another one of thes people complaining about Linux and just about to install Windows 2000.
Can you please tell me how much you are being paid to post these messages and if it lucrative - maybe I should test it too ?
Is it still 30 pieces od silver or what ?
Sorry, you have to be able to spell before they'll hire you.
If 2.7 begins before 2.6 is stable aren't we in danger of seeing a win9x syndrome in that bugs will live for ever and instead of being fixed they will be coded around. I fear very much the long term affects on the kernel and in turn Linux if the trees are split prior to a stabilization period. I am a developer, not on this level, but I have seen the affects of splitting a code base simply to continue developing and at the same time trying to patch existing "production code" and then port things back and forth. It is a very bad idea!! Usually what happens is things don't get back ported they are only provided doing a major upgrade, again the microsoft way of bug fixing.
Granted, you will always have some cross patching, however I think the idea of building off of a clean base is very important. For example, you would not put new tires on your car if the engine is not running, right?
Essentially, I think the issue here is one of knowing the base is clean versus drudging on in the dark despite the fact that you have been offered a lantern.
To put this most bluntly I would call this Microsoft syndrome. As I said before win9x is the perfect example of a system that was never stabilized rather it was constantly released to the unsuspecting public as upgrades which where really bug fixes and the monkeys went back to the keyboards never addressing issues raised by numerous consumer requests on the so called production release because the devel team would rather work on that new feature because it is more interesting than maintaining the existing code base.
I am being harsh here I know, but I am trying to view this in the long term. I feel that this would weaken the kernel and as I said weaken Linux which would in the end at least decrease corporate trust in the stability of Linux or at worst give M$ what it wants, Linux's death,
Maybe I am extreme, feel free to beat me but I know you have to have a clean starting point before you can move forward otherwise you will constantly be taking steps backwards which eventually leads to stagnation and death.
Just my thoughts
Well, being able to spell is a clear indication that it's not real nerd - thus it must be a troll.
I really don't give a shit how they manage releases.... AS LONG AS IT WORKS.
That's why I generally browse at -1, most of the good shit is down there.
Hey nerds!
I like it when the future and the past both happen concurrently, in the present. So let's mix in a little 2.7, and a little 2.6. But it sure would be nice if like (seemingly)ALL of the dev efforts weren't focused away from the stable branch...
Now if we could only manage to get that 2.4.19 released... It's been what, like 9 months since 2.4.18's debut...
Release version 2.71828 and call it quits.
Shut the F*CK up. Try KDE, shit try GNOME both may have bugs but I can say they crash less than winblows GUI and are atleast as easy to use.
> How about first focusing on making a decent >(standard) GUI that is comparable to Windows 2000 >in ease-of-use instead of having all these "window >managers"?
Better yet where are the major software houses on providing the packages we like, roxio and the like, and when will they consider this platform as legitimate?
Just a note, Windows 2000 GUI crashes an average of 6 times every 6 hours in my experience, they just made the thing restart automagically like OS/2's did 10 years ago so that the user is none the wiser and suddenly is faked into the belief that a stable GUI makes a stable OS.
So, the best time to let 2.6 "escape" is when you're fairly confident it's "ready" and won't need patching.
Of course, you'll be wrong -- it will need patching, or backports of useful features that just didn't make it in time.
But, the idea is that these patches or backports should be trivial "oopses" where the change does not require massive code review, or the backport is clearly something that was "99% done" already.
So, my suggestion is release 2.7, and hold off on release 2.6 until the obvious release-related "oops"es are found, say 1-2 weeks, then try your best to release a 2.6 that won't need patching. It will anyway, but don't lose sleep over it.
You could've hired me.
Anyone who runs production systems expects (demands?) even-numbered releases to be stable.
There's no serious linux admin out there that wants to have to test a new supposedly "stable" kernel for a week before employing it on a bunch of mission critical boxes. Say I want/need a feature in the new release of the "stable" kernel, should i expect anything less that a kernel that is rock solid? There's people still running 2.2 series kernels because of the whole 2.4 feature creep fiasco.
All the stability issues should be worked out before a kernel is considered "stable." Seems to make sense to me...
I should not have posted anonymously. I wanted this to be publicly my statements.
/.
Anyway, the next comment is correct. In the Linux world, and might I add the correct world(not because it is linux but because there should no real connection between the kernel and a GUI system, the GUI has absolfuckinlutely nothing to do with the kernel!!!
This guy should get a clue prior to spouting off at the mouth, especially at a place like
I use "winblows" (real mature) XP and have not had a crash in... I can't even remember the last time.
Better yet where are the major software houses on providing the packages we like, roxio and the like, and when will they consider this platform as legitimate?
When you stop using terms like "winblows".
Unstable series often start off with versions which break everything, because whatever fundamental change is first up for the series has gone in and the drivers and so on haven't been updated. It was a long time in 2.5 before it was really sensible for people to work on it (aside from the bio work), and people were actually doing their development on 2.4 even after 2.5 had started. In part, this wasn't even an issue of stability: Linus just wasn't taking patches on other subsystems. If 2.7 starts when 2.6 comes out, and major changes go into 2.7.1, people will stay on 2.6 until the first major set of changes in 2.7 has stabilized. Provided that the first thing under development in 2.7 isn't broken in 2.6 (in which case, the people who could fix it would be working on 2.7), everyone important to fixing obscure bugs in 2.6 will still be working on 2.6, but sitting on their patches, because they can't go into 2.6 (not fixes). As the interfaces for 2.7 (where they differ from 2.6) become known, people will start using them, but, until that point, 2.6 and 2.7 are basically the same, except that you can get 2.6 running to develop on.
Odd numbers RULE.
Make the even numbers the silly-branch of the kernel, I say. There is stability in odd numbers! You can hack down a man very easily if he is a believer in even numbers!
A pirate walks into a bar, with a ship's steering-wheel in his pants. After a few drinks, one fellow can't take it any more, and belts out to the pirate "Hey mister, you have a ship's steering-wheel in your pants!?!".
To which our pirate responds: "Aye, it's drivin' me nuts!"
Got the point?
[ ...Putting on my "politically incorrect" hat... ]
It's a common Open Source Software problem: there is the last release, and there is the developement branch.
Developers would all prefer that you use the developement branch, report bugs against *that*, provide patches for the bugs against *that*, do all new work in the context of *that*.
But it's not how things work, outside of an Ivory Tower.
In the real world, people who are using the system are using it as a platform to do real work *unrelated to developement of the system itself*.
I know! Unbelieveable! Heretics! Sacreligios!
FreeBSD has this disease, and has it bad. It very seldom accepts patches against it's last release, even in the developement branch of the last release, if those patches attempt to solve problems that make the submitted work look suspiciously like "developement". The cut-off appears to be "it fixes it in -stable, but would be hard to port to -current; do it in -current, as your price of admission, and back-port it instead, even if you end up with identical code".
The only real answer is to keep the releases fairly close together -- and *end-of-life* the previous release *as soon as posible*.
The FreeBSD 4.x series has lived on well past FreeBSD 4.4 -- supposedly the last release on the 4.x line before 5.0. FreeBSD 4.6 is out, and 4.7 is in the planning stages.
It's now nearly impossible for a commercially paid developer to contribute usefully to FreeBSD, since nearly all commercially paid developers are running something based on -stable. FreeBS -current -- the 5.x developement work -- is *nearly two years* off the branch point from the 4.x -stable from which it is derived.
Linux *MUST* strive to keep the differences between "this release" and "the next release" *as small as possible*. They *MUST* not "back-port" new features from their -current branch to their -stable branch, simply because their -current branch is -*UN*stable.
Delaying the 2.6 release until the 2.7 release so that you can "stabilize" and "jam as many 2.7 features into 2.6 as possible" is a mistake.
Make the cut-off on 2.6. And then leave it alone. People who are driven by features will have to either run the developement version of 2.7, or they will simply have to wait.
Bowing to the people who want to "have their cake and eat it, too" is the biggest mistake any Open Source Software project can make.
Don't drag out 2.7, afterward, either... and that's inevitable, if everything that makes 2.7 desirable is pushed back into 2.6. Learn from the mistakes of others.
-- Terry
Kernels don't get truly stable until you get thousands of people using them, but all those thousands of people aren't going to install a kernel until it's deemed a stable release.
Release candidate kernels help alleviate this somewhat, but you can never really duplicate what happens when the bulk of normal users stand using it on an everyday basis.
...skip both and go straight to 3.0! Oh wait, let's make it 4.0...few months longer and we could have 5.0...
If you after 2.6 emidietly start working on 2.7 then maybe you didn't do a good enough job with 2.5.
Would starting the new development branch immediately after the stable release help? Hardly. It's the time when a lot of work has to be done on the stable branch.
But what if we make sure that the stable kernel is indeed stable when it's released, not after the "stabilization"? The only solution to make kernel stable is to test it a lot before it's released.
I don't think we should be afraid of "debian syndrome". Kernel is much more monolithic than a disribution, and if e.g. IDE doesn't work well, it takes much more efforts to downgrade it safely compared to downgrading e.g. Mozilla.
The fundamental problem with the development branch is that issues with one part of the kernel affect all developers and testers. If I e.g. want to test ACPI and know how to fix it, but I don't know how to fix IDE, I won't test the latest 2.5 kernel.
I believe that the best solution would be to have branches for different subsystems. IDE changes would be merged to the trunk only when they are stable enough for other developers. It's important that the development on the branches is done openly, step by step, so that an interested developer could find the exact place where a bug was introduced. But this style of development doesn't require doing everything in the trunk. In fact, to keep the kernel relatively stable the development should be done on specialized branches.
More stable development kernel would mean more testers. More testers would mean stable release, which is truly stable, at least compared to 2.2.0 and 2.4.0. And that would eliminate the need to force developers on stabilizing the branch that is supposed to be stable form the beginning.
4. The enter beast was so unyeilding, it was known that the only one person who ever understood it, had to keep a journal just to keep track of the beast (Seriously). This was one of the major reasons that ticked off Linus and I believe the reason why he pushed the new VM.
what is the "enter beast"?
cpeterso
The funny part is that FreeBSD figured this out 10 years ago.
Your comment is one of the primary reasons why Bill Gates is a billinaire and you are not
Just a note, Windows 2000 GUI crashes an average of 6 times every 6 hours in my experience,
:-D
:(
/somewhat/ understandable API running underneath things? Hell, if even MS can admit that GUI APIs are a not going to be gotten right the first time, certainly the OpenSource community can admit to the same thing and do it again until it IS gotten right. Yes it would be a lot of work, but it would be worth it. (and had somebody started back in 1999 or so it might be nearly complete by now....)
Nice math their buddy, that is called once an hour....
Granted I had Windows 2000 core dump on me ~10-12 times yesterday (w00t) and another good 3 or 4 unexplained crashes, but that is all because I have managed to fuck up the DirectX sub layer to hell and well, err, heh;
when it IS running properly (which it will be as soon as I manage to find the install disks. ^_^ ) it has very long uptimes, though it is awfully dependent on what you are doing. After the first 3 or 4 hundred program installs/uninstalls things to tend to, err, get a bit cluttered, heh.
Then again I would like to see you do that many program installs in as short a time on a *nix box.
Bah, what am I saying, dependencies suck period, no matter what OS you are on.
Oh, and the *nixs DO have a shitty ass GUI system, seriously, there needs to be a BIG effort to ditch X and get a real system underneath that, technology has advanced a lot in the intervening years since X came out, hell, just the pure CS theory stuff has advanced a good deal, for crying out loud, come up with a better system. Or at least a more coherent one. It has taken MS how long and how many revisions/API changes to get even a
Need help treating your acne? Come here!
> Then again I would like to see you do that many program installs in as short a time on a *nix box. :-D
(You were grinning, but even so..)
On a Debian Linux box, I can *easily* cause a download & install of several hundred programs, libraries, etc by "apt-get dist-upgrade" from stable to testing, for example. No such instabilities post-upgrade.
I believe Red Hat 7.2 -> 7.3 upgrades do the same amount of work.
Agreed on sucking dependencies, though.
Couldn't the problem be solved by brancing the unstable first, then releasing the stable branch when it's ready?
For example, let's say that we're happy with the feature set in the 2.5 unstable series. Instead of putting off waiting for all of the bugs to get shaken out and call it 2.6, just switch from 2.5 to 2.7 on the unstable development side. Linus can pass the reins off to someone he trusts, we can have a GROF (Get Rid Of the Fin) party and his trusted lieutenant can finish stabilizing 2.5 into 2.6 without him.
This solves the problem of wanting to keep back-porting features from 2.7 into 2.6, it allows for time to make sure the 2.5 code is stable before public release as 2.6, and provides a clear feature-freeze mechanism: once Linus is gone, go bugfixes only. If you want the new features, run the unstable kernel or wait for 2.8 (released sometime after 2.9 is branched).
Not that my opinion matters at all, it's just an idea.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
OK, so as background, I just woke up ~ 5 minutes ago, so the coffee isn't finished brewing, much less finding it's way into my body yet... I read the headline and the first thing that came to mind was "What? OpenBSD 2.6/2.7? I manage those releases by keeping them neatly stacked in my pile-o'-unixen under 2.8 and 2.9..." Then my brain assimilated the fat little bird under the topic, some gears churned, a little smoke came out, and I realized we were talking about Linux... ;-) The moral of this story I think is don't read slashdot right after you've woken up...
News for Geeks in Austin, TX
With a pretty loaded and underpowered (p2-300 256MB ram running usually mozilla, IE6, some office products, management tools, java based trouble ticket system (I hate Peregrine) etc) I have had an uptime of 146 days before we moved buildings and am on day 47 since then. I don't know what kind of shitty drivers you are running but the only bsod's I have seen under 2k were all driver related.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Okay, what stable is, really? What does it mean to release 2.6.0?
To me, 2.6.0 means "okay, this is what we can possibly get if only developers are running the code. We have tested our kernel, we have high confidence that it will work for you, but, you know, there are surprises. So do try it out, if you can. We promise that if you find problems and tell us, we will put you to the highest priority, so that you don't have to fall back to 2.4.XX."
What is 2.7.0? People says that it means "okay, now we have 2.6.Y stable, we can pretty much ignore it. Let's put it in the hand of Xyz Abc, the new maintainer of 2.6 series, and new work will be placed at 2.7.ZZ". But I don't like this view. This ignores the possibility that new thing can land directly into 2.6.XX. This happened quite frequently in 2.4.XX, actually, and it does work.
I believe the real reason for 2.7.XX is that "after some use, we find that 2.6.XX has the following stupid problems. It can also be improved if we don't do things this way, but instead do things that way. But they are so fundamental to 2.6.XX, that if we ever change it, we can no longer make the claim that we made when we roll out 2.6.0. These things really needs to be done, though, but we prefer people not to use it yet, and we developers will try to make things work again after they break, and after every developers can reasonably make the claim we made when we delivered 2.6.0, we will roll out 2.8.0, when every of you can try this new neat way of doing things. Currently, please stick with what we have in 2.6.XX."
If that reasoning can stand, then what 2.7 is for is really new API. A new one that can cause everything else to break. I'd say, once we know what new API we want to create, we should create 2.7.0, *regardless* of whether 2.6.XX is stable enough or not. It is absurd to be afraid that stablization of 2.6.XX will slow down because of the existence of 2.7.YY: preference is always given to 2.6.XX if things go wrong there. The real problem to release 2.7.0 too early is that many things get implemented too quickly, when most of the API changes are still up in the air, forcing most things to be written again, perhaps for many times. When that "up-in-the-air" problem goes away (or has settled to a point that we want to write and see what will happen if we really do things in the new way), there is no excuse not to release 2.7.0. Further delay only makes sure that the next kernel will arrive late again.
After the first 3 or 4 hundred program installs/uninstalls things to tend to, err, get a bit cluttered, heh.
:-D
:-)
Then again I would like to see you do that many program installs in as short a time on a *nix box.
So, let's see if I got this right. You install a lot of stuff, the box goes bad. And you can install a lot of stuff a lot faster in windows than in an *nix box.
Therefore, the primary attraction in Windows is that you can muck it up one HELL of a lot faster.
Efficiency, in other words.
Yep, I'm with you
Blearf. Blearf, I say.
With a pretty loaded and underpowered (p2-300 256MB ram running usually mozilla, IE6, some office products, management tools, java based trouble ticket system (I hate Peregrine) etc) I have had an uptime of 146 days before we moved buildings and am on day 47 since then. I don't know what kind of shitty drivers you are running but the only bsod's I have seen under 2k were all driver related.
/that/ bad, I have had it up to 3 gigs before just with old ass DLLs and other crap lying around. :( )
/great/ in stable always on enviroments but appears to suck horribly when it gets in a situation where it is booted on and off all the time. :( (with power bills what they are, no way in heck am I leaving things on 24/7!!!)
:(
See, there is your problem;
the misc software crud part of my registery?
Over 50 thousand entries. (!!!!)
158 fonts installed (ouch); 3 language packs; 3 versions of Photoshop, 2 versions of Java (err, well 3 but only 2 that the system will admit to, uninstaller failed miserably), and if I even try and install Java into Moz bad things happen.
Well heck now if I even run moz.exe bad things happen, heh.
DirectX is like one layer BELOW the drivers, if the DirectX layer is shot ANY driver will fuck up on you. That is what is happening to me.
My WinNT directory is still a 'mere' 1.43 Gigs though, heh.
(not
I appear to be gathering ~50-60 cookies a day just browsing the internet (ouch),
and none of this is counting that NT5 apparently works
I have seen NT5 literaly kill itself just by being rebooted, boot, shutdown, boot, shutdown, eventualy it just refuses to boot and you have to go into safe mode and start correcting crap.
Oh yah, Microsoft also decided to install the French version of the Matrox G400 Dual Head drivers some time back, hehe, I installed a more, err, appropriate verison of them, but even in Safemode I cannot remove the old version.
I also have a bunch of things called WAN Miniport drivers which I have like NO idea what they are, there are four of them installed on the system (just kinda showed up one day. . . . better then 9x where things would just disappear one day I guess though) and when I tried to remove them (any mode) it said "cannot remove this device is neccisary to start up your computer."
Disabled them though, yaah. Didn't have too much of an impact on stability one way or the other though.
Need help treating your acne? Come here!
So, let's see if I got this right. You install a lot of stuff, the box goes bad. And you can install a lot of stuff a lot faster in windows than in an *nix box.
:-)
:-D (yah so darn nearly everything else about it may have sucked, but at least you could turn the computer on and know you'd get to something and be able to run something! If one app went down it didn't take nothing else with it.))
Therefore, the primary attraction in Windows is that you can muck it up one HELL of a lot faster.
Efficiency, in other words.
Yep, I'm with you
Well, thing is, I would like a setup (out of the box, I know I could just keep sequential images of my HD on a RAID array someplace on an older machine or such, but, err, that is NOT exactly eloquent. Kick ass yes, eloquent, no) where I can install all the crap I want and not have to worry about some bloated huge central depository of crap getting too big, or of the alternative, everything becoming so cross referenced and dependent that uninstalling anything becomes like a giant Jenga game.
Either pathway sucks.
DOS rocked, copied apps, ran apps, deleted apps. None of this installing or dependency bullshit.
Need help treating your acne? Come here!
Slightly offtopic:
It's really frustrating not to have a Linux kernel bug tracking system available. Searching through the huge lkml mailing list just doesn't cut it. And some questions pop back up every month, with no sign of it ever being addressed.
Example: the Athlon/VIA chipset freeze bug. Is it a chipset bug? A bios bug? A kernel bug? Is it fixed? Is it AMD's fault? Is it VIA's? Is it Linus's? Is it a PCI latency problem? An IDE problem?
Who the fuck knows!
joe.
ps. not a flamebait, but genuinly funny.
Have Linux installed at your place in Amsterdam, for cheap
There is a list of the new features in 2.5 here.
In summary:
Performance
- Major rewrite of the disk IO layer meaning better harddisk performance for Joe-user and high-end database servers as well
- New and faster scheduler
- Pre-empt scheduling for better interactive performance
Features- ALSA sound infrastructure
- Video for Linux redesign
- ACPI interface and other power-control patches. Especially a new software suspend-to-disk feature that does not involve Windows specific BIOS magic.
- Lots of high-end features (High memory, 64 bit processor support, per-CPU infrastructure, hot-swap CPU etc.etc.)
- JFS - Journaling filesystem from IBM (where's XFS?)
- Bluetooth
- USB-2.0
Security- Access Control Lists (ACL) which gives fine-grained security
- Per-process namespaces (some Al Viro hackery. Someone please tell that man to slow down a bit)
- Plugable quota system
And as usual a lot of new driver updates.Suspiciously missing are any memory management patches (although Rik has his reversed mapping patch in the pipe). Perhaps the topic is still a litte too hot...
The most important thing for me would be resource management features
I think that the with the current kernel you can already do much of this. But some of the new features of the 2.5 kernel allows for much more fine-grained control - like binding a process to a distinct CPU, better quota accounting etc. Perhaps thats what you're looking for ?
The direction of the 2.5 kernel seems to me to be mainly (but not exclusively) targetting enterprise systems.
1) CVS (or Subversion)
2) Tinderbox
3) Bugzilla
Maybe others as well. Mozilla has a good development procedure IMHO.
This is an honest problem with Linux credibility. The way I see it Linux needs to get on a serious business/seasonal calander. They need to provide 1 ultra-stable release per year and 1 continuous development release per year. Also provide a compatibility suite for each level of the OS. One for the Kernel, one for X11, one for KDE/Gnome,and one for apps. These would be key programs that all sub versions of the stable even-numbered release must be able to run! The best desired system would be a Gentoo style system merged with cvs controls, bug reporting, and problem handling forums that additionally could be used by developers to concurently get the latest code and stamp out bugs faster before actual release. Linux will only grow by leveraging the real power of the internet of mass concurrency of code and extend to automated forums and distributions that take care of themselves without user intervention.
Also, dammit, now you've got me wondering what the insult was in Monkey Island whose retort was something like 'get the POINT?'
Burning karma for Jesus.
Now I'm pissed and it's the mod's fault. Godamn nazis.
Somewhere between 2.4.12 and 2.4.16 (i believe that it was : mempages should be 4k long or AGP goes bust -- and the rest goes down hard and fast)