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;)
I'm impressed, I wish Linux programmers knew as much about designing UI interfaces as you do. Seriously. For example, Gtk+ doesn't have proper modal dialog box support. Ever try to create a dialog box with Gtk+ that disables only it's parent window? You can't. Consider yourself lucky you "learned" yourself some advanced topics, such as modal dialog boxes. ;)
it's gonna be half as good as kernel v 5.0
We've been over and over and over again...
Moving from X windows to FB (frame buffer) you'll loose:
1. Hardware acceleration. Sure, you can write hardware acceleration, but how many people here do know how to write hardware acceleration for the various chips?
2. You'll loose 3D, DGA(1/2), Xv, XDND, and zillion libraries which are using Xlib and other extensions. Want to write them with the frame buffer? please, be my guest. Just tell me which year you're going to have 1.0 version
3. You'll loose all X applications support that needs X - think commercial applications that doesn't give a fuck that you like Frame Buffer. Think about commercial vendors who port their applications from other unices to Linux and vice versa.
X is fine! You should start reading some info about X, why it shows in "top" that it takes lots of resources (hint - it's not what you think).
I like X, and I like the extensions that are being written of it. I like DRI, I like Anti Aliasing in QT, and I like the Xv extensions which let me watch full screen TV (on 1600x1280x32bpp) with my ancient TV tuner and lets me watch DVD's with Xine.
Hetz (Heunique)
There are lots of us. And we're all different.
We're not all the same moderator; we're not all rabid Linux-zealots; we're not all Windows trolls. Some Linux users don't use Napster. Some Windows users don't like software patents. Some of us are probably Buddhist Libertarians who aren't vegetarians and like to program GTK+ apps when they're not using IE to browse the web on their Windows 2000 box.
If any of you ever think that we're all the same, you need to pay more attention to the flame-fest that goes on whenever any topic with two sides is muttered. (And realize that you are still. only seeing the the vocal minority of Slashdot users.)
I'm using the CVS tree version, just because the patches tend to run a bit too far behind for my tasts.
Here are the instructions for grabbing the tree via CVS:
Linux XFS CVS Instructions
I really hope Linus changes his opinion on the relative urgency of merging XFS. It is something that I think the kernel could really benefit from, given the kinds of things people are using Linux for these days. I'd like to see it in 2.5.x ASAP, and hopefully backported to 2.4.x.
Explaining why the hell you have to take about *umpteen* hours in downtime upgrading kernels every so often becomes such a hassle. At least with BSD fixes are easy, and releases aren't done everytime someone *thinks* their new revision is revolutionary enough to release another current.
Linux kernel versions come out on a regular basis because the development is open. Most major software has at least as many internal releases, it's just that at various points one of them is picked to be a 'new version'.
There need not be umpteen hours of downtime due to kernel upgrades (however much 'umpteen' is..). Just pick a version that works for you and stick with it. Perhaps consider an upgrade the next time downtime is scheduled for hardware upgrades (if then). The big upgrades only happen for major version releases (which many people complain are too far apart). Even those can be skipped in many cases if what you have is still doing the job. There are still plenty of servers out there running a 2.0.x kernel for just that reason.
Linux is not like certain *other* operating systems where the new software you have to use deliberatly breaks on older versions of the OS.
Eh?
Any Linux or BSD user can get the source to the kernel they use. They can change the local version. If they are on the BSD core team they can change the global version. If they are Linus they can change the global version. If they aren't the core team or Linus they can send a patch to the core team or Linus and hope it is appreciated. Or they can fork the code (it happened to BSD at least three times, about zero tomes for Linux).
I don't know anyone on the FreeBSD core team, I've never met any of them (I know some of the OpenBSD core, I've met Linus). I had a problem with the FreeBSD USB stack. I tracked it down and fixed it. I used diff to make a patch file. I ran send-pr to report the bug, I attached the patch. Some automated software assigned me a bug id (kern/17815). Some time later I received the following message:
So my change didn't exactly make it in, but as far as I can tell only because I wasn't the first to make it. Somebody actually looked at my bug report, and checked to see if it was fixed. I have no doubt that if it wasn't they would have used my patch, or fixed it in a better way.
So why do you think the core team hinders BSD's growth? Does Linus hinder Linux's growth in the same way?
Or in other words, yeah, sure, Linux is great, but why do you assume BSD sucks when you have no damn idea how it works?
If you want to bitch about BSD, go install it. Don't make uninformed complaints about it. It's just as bad as all the articles about how hard Linux is to use written by a bunch of Windows users who have never given Linux a shot.
X's problem is a *lack* of primitives, not that they are too low level. This results in people who want to do something being forced to draw the entire thing in a local image buffer and thus losing all hardware acceleration.
In my opinion the client-server model is much easier to program and debug and can be FASTER than direct calls due to the reduction in context switches (since many graphics calls are easily batched together). The fact that it makes it trivial to get network transparency is just gravy and not the main reason for X's design.
X's insane flaws are the extremely bad graphics interface that ruins the client-server model by requiring synchronous communication, and a mess they created by making the window manager be a process.
Graphics should be powerful (not necessarily high-level) and should work without the program having to "inquire" anything about the device. For instance you should pick a color by specifying a r,g,b triple and the server decides what actual color it can display and does it.
The window manager should be scrapped and all programs control exactly all the pixels drawn on the screen. "consistency" (a very highly overrated thing, in my opinion) can be done by toolkit libraries, the same way they make buttons and menus consistent.
Both of these things require such significant changes that the result will not be X.
You still didn't answer my question. What part of this has anything to do with the kernel? The kernel is process agnostic. You could build a system on top of the kernel that doesn't even use usernames and passwords.
What the hell are you talking about with number 5? The kernel doesn't give a rat fuck about console logins or any other kind of login. It just starts itself, and hands some filehandles off to an initial process. The kernel doesn't care what happens from there on.
That's what the distributors do. Linux is just the kernel, and there is usually no need to upgrade when a new patchlevel is released.
But I like to have the patch quickly if my system happens to need it. With a quarterly cycle, you have no choice but to wait for the whole next release.
Great ideas! When should I expect to see patches from you, and where will you post them?
* Fast, non-X-based 2D (GGI) and 3D (??) graphics control.
Well, we already have
What I'd like to see is a DMA subsystem that allows you to allocate large areas of physical memory (optionally mapped through the AGP GART)--something the rest of the *nix's can adopt.
Write the Linux kernel in Java.
The benefits are obvious - it will be cross-platform and garbage collection will be taken care of.
--
Vidi, Vici, Veni
Umnh...
I don't think you have the BSD license correct. I believe that anyone is allowed to release a fork of the BSD kernel, but that they are also able to release a binary-only fork. And to add additional license restrictions.
BSD is more free for the current developer. GPL is more free for the past & future developer. There are arguments in favor of each. However, I prefer the GPL, partially because I want the future changes to contiue to be available.
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
Tell me they are going to fix the memory management!
Right now, the kernel takes a constant 1G of virtual space. Which means any process can only take 3G of memory. Really annoying if you acutally have 4G or more of memory. And worse, the virtual address space is fragmented enough that the largest contiguous piece of space (say for a dynamic SINGLE array) is 2G. that really sucks.
I hear they are going to employ OpenBSD-like methods. Does this include thinking of Virtual Address space as just another resource, like memory used to be before VM? I've come to realize that VM separates the allocation of the address space and the physical space, when without it, they were bound together. Now, before it, contigous memory was scarce on a even lightly used system. So the big things that 2.5 needs to consider is good use of high memory (like putting the kernel in there for good), and actually making an allocation scheme for Address space, as that is still a vital resource that cannot be wasted.
$.02
"Did you wash your hands? You don't know where Linux has been."
Lycestra
What are you on?
While the 2.5 talks are going on, at the rate their releasing kernels, 2.7 will be out while they speak about 2.5.
For starters major releases are always delayed.
Minor releases on the stable kernel are only bug fixes, and minor updates, they don't add features to the kernel.
I don't want to have to wait three months for a bug fix thank you very much.
It's just not possible for anyone to "release 2.7" before "2.5" - you seem to think that Linux kernel development is really muddled.
I can only assume that you're a BSD zealot, as some of your other posts lately have been quite reasonable. If this is the case why not just ease up a little and keep your posts to the BSD area until you've done adequate research to base your arguments on fact.
Well i dont think its as much a troll / flame as much as a offtopic opinion or flame bait.
..
.Net threads that happend earlier for that :)
This new headline is about the features that might or might not make it into the next rebirth of the linux kernel, and posibly even discussion about linux development might be in place..
But 'WindowsXP is more stable then Win9x' is no where near relevant to the kernel development discussion that this news item encompases. I think thats where you got confused about the modding
Thus it is flame bait, since it tries to bring the Windows9x vs Linux discussion into this thread, whereas this thread is not ment for such discussion. Try the WindowsXP /
-- Chris Chabot
"I dont suffer from insanity, i enjoy every minute of it!"
I don't see why. It's to Linux's benefit if it performs well with Oracle, and if this can be done without compromising any other components of the kernel then why not? Oracle aren't demanding anything, they're merely pointing out that if these features were implemented Oracle (and, presumably, similar large-scale apps) preformance will be better. Most of the items listed are flaws in the current kernel, so you could always argue that fixing them is just a matter of neatness...
If Sun or Microsoft pointed out that the current kernel code compromised the performance of some of their applications and that it could be fixed without compromising the performance of anything else, I really can't imagine anyone refusing to do anything about it.
True. I won't deny it. I maintain it wasn't worth the gain and linux should not follow the same path.
You don't understand - not just what they kernel spews out, but the distribution as a whole.
I understood you completely. Nothing you mention cannot be hidden. And most of it already is with a properly configured machine. A framebuffer splashscreen during boot going into XDM and you wouldn't see a single system message.
A desktop OS is a far more amorphous problem - the focus should be on letting the user get what tasks they need to get done, with the minimum amount of worrying what is under the hood.
I guess I have a unique perspective on this - I work with people who need computers, but are easily confused by what we understand. They don't understand a driver conflict, all they know is that "the Internet is broken."
You hardly have a unique perspective. I work in the IT department for a newspaper with over 1400 clients doing network and end-user support. It's a fun job. I get to help people out and learn new things constantly.
That said, no, a desktop OS does not need a bunch of stuff packed in the kernel that could be applied in userspace. Configuring a printer does not require a kernel module. Being able to plug in a gnumeric spreadsheet into abiword does not require new code in the kernel. We don't need a checkbox to compile Mozilla's renderer when doing a make Xconfig.
Desktop OSes should protect the user from the computer. Your average user doesn't care about what most of Linux does, or what it can run on - they just want to write a paper, or check their email.
I'm not debating that point at all. I am debating why a single line of code must go into the kernel to accomplish this. Except for the speed of rendering graphics, which imho isn't worth the probable code fork it would require to get little Bobby an extra 20fps in Alice, nothing -absolutely nothing- you want has to be in kernel space. Is this the way you see NT? As one big kernel GUI that has every program running in Ring 0? Office isn't in the kernel. Outlook isn't in the kernel. This is not preventing Joe Average from reading their mail or writing the next Great American Novel.
You want linux for the desktop then developers need to make improvements in XFree. XFree can be made faster just as it can be extended to incorporate new technoligies like TT fonts. They need to continue to improve KDE and Gnome and GnuStep. Apps like Konqueror and Mozilla and Abiword need to be improved. Technologies like KParts and Bonobo worked into more apps. The list goes on and on and on.
I guess I must have a unique perspective on this. I look around and see every single one of those items being worked on. Just like the kernel developers are doing what they should be and improving the performance, and design of the kernel. Between the two I see nothing sabotaging or hindering the development of a consumer friendly linux desktop.
I don't want knowledge. I want certainty. - Law, David Bowie
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.
;-)
Windows does offer some graphical speed improvement as a result of it, though. I can't offer you hard numbers, and perhaps it is a placebo effect, but my Matrox G200 does perform better under Win98 than Linux/XFree4. I run a fairly fast window manager (wmaker) under Linux, so I don't think its attributable to wasted eye candy. If you know of some tests to run each OS, I'd be happy to run them - I'd be happy to know I was wrong
But anyways, if there is a potential for improvement, why not take it? As long as the implementation is thorougly tested and debugged, I can't imagine any problems. Both WinNT and Win2k in my experience have been fantastic with not crashing, and they've got this "flaw in design".
Already done. If you want a nice splashscreen while the system boots up and not see all that boot information you can.
You don't understand - not just what they kernel spews out, but the distribution as a whole. Does Joe Blow care about GTK errors? All of the stuff X dumps as it starts up? MacOS is wonderful in the regard that it takes all the complexity of the system, and buries most of it. Yes, that's quite possible with >/dev/null, but an effort should be made to make all the extraneous output that is off by default.
The fact that you can run linux in everything from a wristwatch to a supercomputer is a testament to its design. Not a flaw.
Debatable. I'd rather have a well refined tool for a specific task, not a cure-all kernel.
Oh, and a true desktop is a thought out and planned set of layered services running atop a kernel.
Yes, but we differ in what we think a kernel should consist of, and my feeling is that a kernel for a user should be fairly different than a kernel for a Cray. The Cray is doing serious number crunching. Asthetics are at best a secondary concern. This is what Unix was after orginally, completing jobs.
A desktop OS is a far more amorphous problem - the focus should be on letting the user get what tasks they need to get done, with the minimum amount of worrying what is under the hood.
I guess I have a unique perspective on this - I work with people who need computers, but are easily confused by what we understand. They don't understand a driver conflict, all they know is that "the Internet is broken."
Desktop OSes should protect the user from the computer. Your average user doesn't care about what most of Linux does, or what it can run on - they just want to write a paper, or check their email.
--------------------------
The presentation was about features that XFS developers would like to see in the kernel, and why.
It means no more than suggestions from Oracle. If you look at the things they suggest, they also give reasons for them. Remember that XFS is a fairly maure journeling FS, compared to Reiserfs which started for Linux.
Resierfs is in the Kernel, last I checked XFS wasn't yet. Both, and ext3, will be around for a while.
--
I mean, I'm running Linux 7.2! These guys are behind the times!
sup
Perhaps the example was poorly chosen, or poorly worded. The problem mentioned is very real, though. Trying to distinguish between transient and permanent errors, HBA and device errors, or HW-RAID controller and actual-disk errors, is hard enough even when you have access to all of the available information - e.g. sense data for SCSI. I know this because I wrote one of the very first UNIX-based multi-path disk driver extensions, and nearly went insane dealing with this exact problem. Linux makes this problem even worse by basically throwing away most of the useful information at various points along the way from adapter driver to SCSI mid-layer to generic block-device layer, etc. I'm glad they're finally doing something about it.
Slashdot - News for Herds. Stuff that Splatters.
Lots of good points.. I guess I have totally given up on surfing at anything less than 1. This means I don't see the vast majority of PURE crap (first posts, beowulf clusters, goatse.cx etc. From that point of view, it would be better to get the good posts that have a rating of 1 to get a rating of 2 (or more) so that one could set the filter to 2 and get an even better signal ratio.
But either way, spending points moderating serious posts "off topic" just because they were slightly off topic seems like an awful waste to me. Same goes for many "redundant" moderations. So what if there's a little redundancy? It's much worse to have a lot of pure crap in there than to have some ok post that is redundant. That's what I think anyway.
Dude, moderator points are mostly wasted on things like "oh, oh! i don't think that was QUITE on topic! i'll moderate it down for being 'off topic'" or "oh!!! i think i saw another post touching that a few screens up, i'll moderate this one down for 'redundant'". Instead, moderators should spend their points moderating GOOD POSTS UP! It's sad, because many good posts never get moderated up - probably because all moderator points are wasted on crap.
And.. a little rant.. ANYTHING even SLIGHTLY off topic that mentions something even slightly positive about Microsoft will always be moderated down. Anything, no matter how off topic, that says something negative about Microsoft will either be moderated up or left untouched. It doesn't matter if the story is about the Muppet Show or Mars landers..
I myself hate modal dialog boxes.
War is necrophilia.
if oracle sucks then why should the hackers listen to them? If oracle didn't suck AND the hackers weren't listening to them then I can see your point but you seem to be contradicting yourself.
War is necrophilia.
Hardware support for /dev/fb is minimal, and there's no 3D.
--------
Genius dies of the same blow that destroys liberty.
I've found the development time and cost associated with "low-level" languages like VB are too great for kernel development. I'd much wrather bring the PowerBuilder and ColdFusion approach to kernel design. Also, I don't understand all of this confusion around I/O. Why not use a language like Javascript, that doesn't even need any I/O.
Someone you trust is one of us.
I never said moving to the current Linux framebuffer, I asked why the framebuffer can't be expanded into a proper driver model/API that we can use. I only use the name Framebuffer to distingish it from X, but it's a misleading name as it would no longer be a framebuffer.
You don't loose your hardware exceleration, you've got it in the new drivers. You don't have to loose 3D, as OpenGL can sit on top (Or even parts of it in) the device drivers.
You don't even need to loose your toolkit libraries or even, dare I say it, XLib. The toolkits are fully portable, no problem there, and if you put your mind to it, you could layer an XLib implentation over the lower level Framebuffer. Another option would be to allow the user to switch off the Framebuffer and just run the old X.
For home users, they can still run GTK+, Qt, and the Gnome or KDE desktop(s) without even noticing anything other than the fact that Linux is easier to use. The Old Guard, and people who need X for whatever reason, can still run X.
Syllable : It's an Operating System
firstoff: bollocks! I can understand your concern, but things you mention are not of concern in this case. You see, THE thing about this meeting is that people who are there, are (not all, but most) _organizers_. Linus himself is not as much a kernel programmer than he is kernel developement organizer. These people are those who listen to "bigger forces", and maybe push kernel development into that direction. The question is NOT about linux kernel getting "core" development team (altough there's one already, though in fluctuating state as it is..). Here's question about "bigger picture". Of course I'm very sorry about people who've committed to kernel but still not getting to the meeting, but well, that's how life goes, now it's time for them to get their thoughts heard thru code. Linux (kernel) makes it fully possible. Remember that Linus (T) is not some bs-man sitting somewhere, but he's a real haccker with great attitude to great "hacks". If you'r code is good, it'll always gets through, if not immediately (ReiserFS).. there's time for everything under the sun..
fucktard is a tenderhearted description
edwarddes:
:) Many of the things I want for a smooth desktop experience I have been poking around to find out about, and I find that many of them are either part of 2.4 (even if not yet totally polished), or really application issues rather than kernel issues (And so developments on 2.5 don't have that much to do with them ...) Support for USB devices like my external SmartMedia reader and HP 8200 CD-RW drive is in there, and support for a lot of USB scanners and other devices. More USB stuff will arrive* but the kernel infrastructure doesn't really seem like the problem.
:)
What kernel changes do you hope to see in future versions?
Not a facietious question!
Likewise, the "easy desktop" stuff seems more in the hands of the various window manager and desktop environment projects than in the kernel -- and they're doing a good job!
So I'm curious what kernel things you're thinking about. I certainly am more interested in Linux as a personal operating system than in servers, but it seems like a lot of the thresholds have moved up. The kernel can *already* handle most (currently) reasonable demands for personal computing, while the mondo systems of the world are now the ones that the kernel guys face as a challenge.
simon
*I'm not a USB fanatic, but I know this makes it sound that way;)
"Hey Carlito, r'membah me? Benny Blanco from the Bronx!"
I read the laundry list in the article, and agreed with every single point. (No, I don't work for Oracle.) In fact, I'm surprised there weren't a couple of other items, such as the OOM killer problem that has consumed a lot of linux-kernel mail list space lately.
Everything Oracle asked for is bread-and-butter for high-performance database functions. If the PostgreSQL people had been at the summit, they would have asked for the same things. Another group that would benefit from the proposed changes would be real-time apps people, because several of the requests center around simplification of large-transfer requests.
As for resources, you can bet that Oracle people will be right in there testing the changes that are made, providing benchmark data, and perhaps submitting patches from time to time. I suspect, though, that they will leave the big-brush architecture work to the core people, so that the changes they want can be cleanly added to radditional changes requested by others, requests just as worthy for inclusion.
As for "what strings are attached," I suggest you read the GPL again...
Not every single release requires one to download the tarball and rebuild the kernel...but for every release there is someone out there who wants the new feature or needs the bug fix and sees the advantage to take the time to upgrade. If we were to move to quarterly point releases, you would make a number of people mad.
For example, on some of the systems around here I'm still running 2.0.34, because those systems don't need the updates. The work gets done. Others are running 2.2.15 (soon to move to the latest 2.2 for security reasons). Not one of my servers is running a 2.4 -- yet -- because I don't think that the 2.4.x series has enough run time on it yet -- I tend to be conservative about upgrades. In other words, the 2.4.3 doesn't have something that I can't live without, so I let other early adopters (the people on the bleeding edge) scope out the system before I move to it on any of my boxes.
Does this sound to you like a variation on "If it ain't broke, don't fix it?" Good hearing...
Kernels aren't part of the user interface - you just don't use them directly. You do, however, use the abilities of them to run your programs. Basically, it's better for the developers to focus on large server support because you really can't focus on making the kernel easier for the user...
I can't be karma whoring - I've already hit 50!
SIG: HUP
It's a minor driver issue. You don't need to be a core hacker and OS architect to fix it.
BTW just becasue that are releasing a new kernel every couple of weeks doesn't mean the bussiness need to keep taking their computers down to upgrade. They only need to upgrade if there is a bug that affects them in the kernel that they are using and the new one has a fix for it. Or if there is a realy brand spanking new feautre that they can't be with out. Other than that the is no reason.
They people who will upgrade every release are developers, proformance freaks, and people that want to be helpful by providing bug reports.
So don't get your nickers in a twist, no one is forcing you to upgrade if you don't want to.
Mark Hillary
Shoot me
There is an error in the article. X can automatically see new hardware plugged in. Thats what "/dev/input/mice" is for. It is a multiplexer for mice.
Use it!
-EvilMonkeyNinja
a.k.a. Joseph Nicholas Yarbrough
Security Grunt by Day
Programmer by Night
-EvilMonkeyNinja
Mild Mannered Host by Day
Wild Hammered Programmer by Night
Hai! Well, since my first post was considered troll, so will this one. I can think about these os' and it will take Linux quite a bit to catch up. First off, it needs to become compatable with most all hardware so these people at home can set it up easily. Number 2, lack of support (so far). I know it's gaining, I use linux too, but right now, Windows is in the lead. Linux has winme/98/98se whipped in terms of stability but I've used the WinXP beta, and I can tell you, it's stable, not as much as linux, but puts the 9x family to shame. The Fusion 2.5 (DLL and System File Protection) is great, almost making sure DLLHeLL will not occur. Both have equally sleek interfaces, and now WinXP has the theme manager, like Gnome and KDE. It's an opinion moderators, seriously. If something is not in check with your linux zealot powers, you mod it down. Get a life damnit.
You can't fight ideas with bullets - NSF Terrorist Leader, Level One of Deus Ex
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.