Slashdot Mirror
Preview Of Linux 2.5
mojo-raisin writes: "Linux Weekly News is providing a report of the 'Linux 2.5 Kernel Summit,' a gathering of 65 core kernel hackers. Notes are provided on the first day of session, which covers changes required to make Linux more capable on high-performance machines and more user-friendly with hot pluggable devices." 2.5 looks close on the horizon, especially now that Linus has donned a funny paper hat. Better get your feature requests in soon;)
The desktop stuff is meaningless. Half of the desktop problems ARE NOT solved by adding junk to the kernel.
Fix the I/O and network problems first; DON'T listen to the clueless masses who just want a win2k (read: porn browser/game platform) replacement.
The networking stuff IN PARTICULAR is a huge problem. We are writing some serious high bandwidth drivers and they are CREAMING the hell out of the Linux kernel because there is only one single backlog queue, and we need to be able to service possibly hundreds of devices. A SINGLE misbehaving network device can bring down the whole network stack currently, and YOU are worried about your stupid desktop apps?
Spare me.
With the appropriate patches, linux can acheive a level of latency that is better than any version of Windows and even gives MacOS and BeOS a run for their money. Search Kernel Traffic for the appropriate discussions. The fact is linux could be used for professional multimedia. The foundation is already there.
You want better support? Get on the vendor's ass to pump out a real fully functional driver for their hardware. Creative anyone?
Bring a graphical interface into kernel land
This will never happen and the design reasons why it shouldn't are sound. Why people don't look at Windows and just admit that it is an object lesson of why it shouldn't be done boggles me.
Hide all of the system nastiness (do I really care how many bogoMIPS I have?)
Already done. If you want a nice splashscreen while the system boots up and not see all that boot information you can.
Basically, change Linux from Unix clone to something more along the lines of BeOS, MacOS, or WinNT (but done right, of course ;-) ).
Can be done and there was a /. story on this. Linux is a kernel. There is nothing preventing someone from creating a new userspace for it.
I don't think that is what Linus wants, though - if he did, I don't think he'd care about getting Linux to run on all that heavy iron.
More like there are a ton of people out there that want linux to run on heavy iron and are getting it done by contributing. The fact that you can run linux in everything from a wristwatch to a supercomputer is a testament to its design. Not a flaw.
IMHO, all the DE's we have right now are just big hacks...yes, Gnome and KDE are rather sophisticated hacks, but a "true" desktop isn't layer after layer of services running on a kernel, its a more thought out and planned OS. You make sacrifices - you might only go down to one widget set, one way of doing audio, etc.
And it is your opinion to have. I just completely disagree with it. A DE should stay in userspace. KDE and Gnome are much more than just hacks and the fact that we have them along with GnuStep, CDE and the like *is* a good thing. I'm pleased as punch that at this stage of the game there is competition and exploration into different designs. The concept that we need one true desktop to rule them all, right here, right now, is deeply flawed imho. You call KDE and Gnome hacks but you offer nothing to replace them.
Oh, and a true desktop is a thought out and planned set of layered services running atop a kernel.
I don't want knowledge. I want certainty. - Law, David Bowie
--------
Genius dies of the same blow that destroys liberty.
I know that I always look for kernel hackers to wear paper hats whenever I select an OS...
If people would only look to the paper hat, it would solve all the computer problems in the world...
Maybe that's Microsoft's problem... no paper hats. No hats at all actually. Maybe Gates should invest in some headgear... perhaps a fedora would be appropriate...
Dave
DOS is dead, and no one cares...
DOS is dead, and no one cares...
If there's a Bourne Shell, I'll see you there
That with all the kernel hackers gathered in the same place. Microsoft might make a deal (another?)with Satan for a terible disaster to strike that building and kill everyone? :(
Since a lot of unwanted doors (read security vulnerability) are created as a result of buffer overflows (blame it on who ever you want to: CPU manufacturers, compiler designers, language architects, etc) is it possible to create a kernel-level watchdog that keeps an eye on stack tampering?
So it's only logical to address hardware issues. The focus on usability should be on other fronts, like the windowing system. Of course some capabilities of a user-friendly windowing system will perhaps need kernel changes. And I would understand your concern if such changes were ignored or treated lightly by the kernel community. But I see no evidence of that.
I am too very interested in seeing the Linux system get mainstream. But from my point of view the advances made are lighting fast, really. When I think about five years ago I find myself unable to say where can we be five years from now. Perhaps a really mainstream Linux. And when that day arrives, it will make me very happy to know that they are using the very same system in the NASA computers.
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
- A development kernel series is created. (x.odd.x)
- New features are added
- The kernel is frozen (hopefully under a year after the development series is started)
- The kernel is tested
- Bugs are found and fixed
- A stable kernel is released (x.even.x)
- More people try it(not on production machines)
- Bugs are found. They are fixed.
- New releases happen frequently
- Things start to stabalise
- Releases drop to a bi monthly then quaterly rate.
- A new development series is started
- New features are put in the development series
- Bug fixes/device drivers are still added to the stable kernel
Most linux users understand the release cycle and act accordingly. You don't need to run the latest kernel if you don't need the new features. If upgrades have costly downtime don't upgrade to the latest stable kernel until it hits x.x.5 or so. If you want to advocate BSD. There is a much better way to do it. The BSD attitude to source is MUCH better than that of Linux. If I modify ls. I can cvs up to the latest ls and keep my changes. If I change my makefile (say to Optomize for my prossesor) I can easily upgrade my package without worrying about my Makefile. Another advantage to cvs is it makes it very easy to audit every change. You can have each commit emailed to you. This helps the development team audit the changes. If the BSDs ever catch up with Linux in terms of mainstream hardware feature support (Power Management...) I will switch because of the CVS support.Picture this...
The kernel hacker summit begins, with a beautiful starlit night (hackers would never be caught hacking in bright sunlight). Hackers are absorbing caffiene, discussing better ways to manage memory, more efficient uses for resources and so forth...
Fade to Redmond. [Wide shot of the Microsoft campus] Lightning bolts, thunder and rain abound. Bill Gates is on his throne, stroaking his Evil Goatee(tm). As he pets his cat, he mutters..."Yes, this is my chance..." With a quick decisive action, he calls up his satelite targeting system...aims it at the hacker conference...presses the button, and *BLAM* Blue Screen of Death. Just at that time, our heroes stumble into the room. Scoobie Doo rolls into Bill Gates, knocking him down, and he's pinned under Scooby. "Curses!!!", Bill cries. Fred and Daphne walk up to Bill, and pull off his mask. It's Old Mr. Withers, the curator at the local museum! "I had a good scam going, and I would have got away with it, if it wasn't for you meddling kids, and that mangy mutt!"
Check out my sysadmin blog!
How about getting ACPI working?
/dev/mixer causing it to get reloaded?).
How about improving "apm -s" so I don't need to manually unload my cs sound driver (and first kill xmms which constantly reopens
How about improving boot up time? Including the bootup logo patch?
How about getting DMA mode working on all the IDE controllers out there and having them intelligently configure themselves (I've lost more than one disk to hdparm tweaking).
How about making my mp3's not get choppy when my system starts swapping? (short of needing to apply rtlinux patches and nice --19'ing mpg123).
(DMA overruns too!)
How about including a kflushd that's smart about laptops?
How about cleaning up the documentation for proc.txt, with some examples of what humans could set things to.
How about splitting scsi, ham radio support, pcmcia, architectures, etc, etc into seperate tarballs so I don't need to download them all, or watch make depend go through them all?
I can't imagine that the same schedule() used to handle Apache and Oracle would do the same job as running GNOME..
Why not try ditching LILO for GRUB?
Please tell me that linux isn't going to adopt the idea of having a "core" team like the BSD's do ...
the only thing that will happen is that the kernel will be something that only the l33tist will be able to work on ...
This has been the case for quite some time. I remember reading complaints by many would be contributors that Linux kernel development may as well be closed since it has now become so complex only a few people are able to contribute anything meaningful to it. Also Linus is notorious for not accepting patches that people have worked hard on for a variety of reasons that sometimes smack of petulence.
Anyway, exactly how do you expect the future roadmap of for the Linux kernel to be handled if not by disussions by the people who are contributing about 90% of the code? Heck just a few years ago it was done by one person, Linus, despite the number of patches that were received by the "open Source" community. It's one thing for patches and bug fixes to be handled in a bazaar manner where discussion is done via a mailing list but on the other hand when dealing with the design of the system architecture or "vision for the future" this is best done by as few people as possible. Design by committee is always bad.
Heck even Perl which has probably as many contributors as Linux gone a similar route with a fewer number of developers directing the future of the project.
This alone made linux great because it was a community effort to get the kernel rolling into a quality piece of code
However this "meeting" makes your wonder if this is a community project anymore, there are hundreds of kernel hackers out there, who have in some way contributed code to the kernel
however only 65 get to attend this meeting ..
Please tell me that linux isn't going to adopt the idea of having a "core" team like the BSD's do ... ...
the only thing that will happen is that the kernel will be something that only the l33tist will be able to work on
additionally forking the kernel code just so that the community can work on the code as opposed to a "core" team is even more stupid ... there go whatever standards the linux kernel had ... get what I mean?
just my 2 cents ...
Sunny Dubey
Isn't detecting CPU and internal system temperature already done at the BIOS level? It shouldn't be hard to implement here; just test the temperature levels every time a disk operation fails. But maybe the rest of the room is on fire! But we'll save space in the bad block table once the system is restored.
If you read further down the article, you'll see that Stephen Tweedie, a well-established kernel hacker, read his laundry list of changes, many of which mirrored the Oracle suggestions. Oracle is just pointing out what limits the performance of their file-intensive applications, limitations that other kernel hackers who care about file performance also observed.
I don't think you should see this as Oracle demanding stuff from Linux hackers. I think it is very useful that developers of high-performance application software, such as Oracle, are giving this kind of feedback on kernel performance issues.
Kernel hackers can use this for our (the users) good, not just Oracle's.