Andrew Morton, maintainer of “mm” patchset of the Linux Kernel which acts as a development tree has posted a long list of features for potential inclusion in the 2.6.13 version of the Linux kernel.
Linux kernel 2.6.13 discussions
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
… 2.6 is the development tree. 🙂
Any news on the VIA DRM code? Or is that in the tree already? (Via Unichrome)
Well, it is the development tree until a stable tree is branched in the form of 2.6.12 -> 2.6.12.1 -> 2.6.12.2 etc.
It is similar to how the free BSDs do things, and is starting to operate on similar timescales to the more aggressive BSDs (eg. OpenBSD, and where FreeBSD wants to be).
So yeah, 2.6 is the development tree same as CVS HEAD is FreeBSD’s development tree.
Maybe it’s just me, but I don’t want features, I want them to clean their code, and make reorganization – if they have to.
My thoughts of nowadays linux kernel development is that it is to much focus on features.
Maybe it’s just me, but I don’t want features, I want them to clean their code, and make reorganization – if they have to.
Clean their code? Is that the same code that a NetBSD developer recently said is cleaner than theirs? Or what?
What code would you have them clean?
This one looks pretty kool….
___
pcmcia-*.patch
Makes the pcmcia layer generate hotplug events and deprecates cardmgr.
Will merge.
hehe, the discussion about R4 is rather heated tho.
From AKPM’s mail :
reiser4
Merge it, I guess.
The patches still contain all the reiser4-specific namespace
enhancements, only it is disabled, so it is effectively dead code. Maybe
we should ask that it actually be removed?
YES !!!!!
At last ! By isolating the controversial aspects of Reiser4 (the so-called ‘silent semantic changes’, ie every file behaves as a directory, conflicting with the impossibility of hardlinking directories), they’re at last able to merge Reiser4 while preserving both stability of the virtual filesystem, and Reiser4’s interesting performance.
This will even widen the performance gap between Linux and Windows (which is already rapidly widening due to the arrival of multi-core machines and Linux’s better SMP support).
Moreover, even without the ‘namespace enhancements’, Reiser4 will still allow very interesting plugins like Encryption and Compression (on a system with a fast CPU, Compression means much improved performance, as the CPU can compress/decompress faster than what the disk can handle.)
http://kerneltrap.org/node/5330
More information.
“Clean their code? Is that the same code that a NetBSD developer recently said is cleaner than theirs? Or what?
What code would you have them clean?”
That’s why I was trying to ask with a neutral touch..
” if they have to. “..I mean I use the kernel 2.6.12 – and people seems to whining about a bloated kernel..okey you can choose what to compile into the kernel…but they still come with the argument that the kernel is still to bloated nowadays
I wasn’t sure how I was going to respond on this, “Linux Kernel which acts as a development tree has posted a long list of features”.
IIRC now 2.6.12 should have no 2.6.12.x, and a 2.6.13.x tree should start right away, leading to a “stable” 2.6.14. Am I right or I didn’t get it?
Thanks
2.6 isn’t the devel tree, 2.6.12 is considered stable, and will remain so, until some bug is found, fixed and a 2.6.12.x release is made.
If no bugs are found before 2.6.13, there will never be any 2.6.12.x
The -mm branch of the kernel is the current devel tree.
Thanks, I think I got it now.
Clean their code? Is that the same code that a NetBSD developer recently said is cleaner than theirs?
—————–
Could you post where a NetBSD developer said that…
I’m not saying it didn’t happen, but I follow NetBSD pretty close and haven’t read that. Unless you are talking about recent interview along side Theo. In which case thats take out of context.
“Reiser4 will still allow very interesting plugins”
yep it will introduce a great path for malicious, exploit, spyware plugins to be a integral part of your filesystem… boy oh boy that sounds wonderful…. cant wait to get mine!
don’t troll : it is obvious that only root will be able to install plugins, so the problem won’t happen. For the very same reason viruses don’t exist for Linux.
So, do you just see the word ‘plugin’ and immediately think of spy-ware?
no but if i install a propriatary app and they want to install something to monitor my use of it then hello reiser4….
i wont troll if you wont dismiss so easily…
think about it….
nice way to install spyware with those graphical smileys package you just had to have!
“no but if i install a propriatary app and they want to install something to monitor my use of it then hello reiser4…. ”
What makes you think that just because reiser4 supports plugins it’s making malware “easier”? If you have
root on a computer, filesystem monitoring is trivial. Reiser4 is not adding any new risks.
no but i am not so one-sided that I cannot expand a bit and realize that if a filesystem allows plugins then nothign stops that plugin from being a BAD plugin or a GOOD plugin…
how about a AOL plugin that redirects you to the websites it wants you to see and of course it is installed with the latest netscape browser…
OK, what happens if a plugin is buggy? It is one thing for your internet browser to crash because of a bad plugin but that is NOT anything I want my whole filesystem to do…
MAN! Just because it’s called plugin doesn’t mean ANY program can just ‘plug in’. Don’t talk about Reiser4 plugins without actually knowing what you are talking about! This is a FS, implemented in the KERNEL, the plugins are ALSO implemented in the KERNEL! THis isn’t something you can do with a checkbox and BOOM, you are PLUGGED IN! This isn’t the matrix you know?
>”OK, what happens if a plugin is buggy? It is one thing for >your internet browser to crash because of a bad plugin but >that is NOT anything I want my whole filesystem to do…”
OK, what happens if the linux kernel is buggy??
The plugin system in Reiser4 is meant to enable people who aren’t FS experts to enhance the FS. Howhever, these plugins would still have to be in the kernel, so Linus would have to accept them OR you’d have to patch the kernel. They are just meant to open up the development of the FS to a broader range of developers by making it easier to expand.
this is great thing. we can get rid of gnome-vfs and kio.
Could you elaborate on that?
“no but i am not so one-sided that I cannot expand a bit and realize that if a filesystem allows plugins then nothign stops that plugin from being a BAD plugin or a GOOD plugin…”
Oooh, yeah. And since we are at it, let’s also state that nothing stops the whole damn software business from being “good” or “bad”. It must be Captain Ovious Day or something.
I still don’t see your point.
The plug-ins are not going to be able to get into your
system without knowledge. This means that:
a) It’s up to you to decide if the plugin is good for you or not.
b) Just like with any other piece of software, if you don’t trust it or don’t know where it’s coming from, you don’t use them.
c) “B-b-b-b-but what if they are unstable?” If it has known problems, don’t use it. If it was released yesterday, don’t use it. If it was released by Claria.com, don’t use it. End of story.
d) The fact that this system allows non-experts to enhance the filesystem does NOT mean that it’s meant to allow grandma to install crapware plugins and bork her computer.
Therefore:
e) People that are unable to follow a, b, or c should not have the root password.
Like any other technology in the world, this has good uses and not-so-good uses. Questioning reiser4 for it’s cool new features just because they might mean trouble for ignorant users is rather silly IMO. Let’s just wait and see how this works itself out.
I have noticed a major decline in the quality of the kernel. I have a specific incident in mind so it is not some generic statement. We have Linux servers acting as gateway servers. These servers are using CentOS 4, running Postfix. Their basic function is to forward all incoming and outgoing emails to and from our domain. We have put these servers at the gateway as an added security measure since it allows us to hide our internal Windows SMTP and Exchange Servers from the outside world. We send out a lot of email (probably around 50,000 / day) and receive about 5,000 / day. This is not evenly distributed as we hit peaks during certain times of the day. Most of the outgoing email is automatically generated by a Windows machine and is forwarded to these Linux machines through SMTP (this includes invoices, specials, UPS info, late payments, etc). We were previously using CentOS 3 on the gateway and had no problems. Recently, I migrated these gateway servers to CentOS 4 with the 2.6 kernel (don’t know why, I guess I should follow the old saying about if it ain’t broke, don’t fix it.) Since then, these servers have crashed causing major problems in automation. I have tried replacing the entire machine but still get the same kernel panics. This has really shaken my image of the 2.6 Linux kernel. It used to be that whenever Windows couldn’t handle it, we put in Linux boxes. We still do that with the 2.4 kernel. But the 2.6 kernel is a whole different beast. There are real stability issues in 2.6 kernel. I have been forced to configure SMTP on the Windows machine to directly send out emails. Now our Linux Email gateways just accept incoming emails and forward this email to the Windows machines. The 2.6 kernel just couldn’t handle the email the Windows machine was generating.
ok fine, youll are right….
“because they might mean trouble for ignorant users is rather silly”
uh that would be 99% of home users…. so yea i think it is a issue
I WILL SAY AGAIN! THE “PLUGINS” ARE JUST AN EASIER WAY TO EXTEND THE FS IN THE KEEERRRNNNEEELLL!! AND YOU CAN’T INSERT RANDOM AND UNKNOWN STUFF IN THE KERNEL WITHOUT KNOWING!
sorry for shouting but man, you people aren’t reading well!
Isn’t CentOS using Red Hat kernels ?
That’s a very good reason for poor quality. A distro-specific kernel receives less testing than vanilla, and receives special patches. Two good readons for instability.
Try a vanilla 2.6.11.12, it rocks. 12 bugfix releases since 2.6.11. Or try 2.6.11-ck10, that’s what I use.
But please, don’t blame Linux for what Redhat is doing.
By the way, CentOS 4.1 uses a 2.6.9 kernel. That’s one of the worst ones (2.6.8 was also very bad). This low-quality is what prompted the 2.6.x.y releases, starting with 2.6.11. So you definitely should upgrade to 2.6.11.12 or a -ck version.
i only use 2.4 kernels, i never go with a newer kernel tree until it reaches at least around X.X.14
Well the kernel is bound to get somewhat bloated since new feature make it bigger, but 2.6 is faster than 2.4 for desktop, udev, HAL, Thats why I use Kernel_proper 2.6.x with Slackware.
udev and HAL supporting in 2.6.x is a real step forward, why do people thing 2.6 is somewhat less stable? especially with udev which as we know hugely reduces device clutter. I’ve never had a problem with 2.6.
Isn’t CentOS using Red Hat kernels ?
That’s a very good reason for poor quality. A distro-specific kernel receives less testing than vanilla, and receives special patches. Two good readons for instability.
You realize Alan Cox, Dave Jones and serveral other RH dev’s supply kernel patches? Most of the patches you see in RH kernels are vanilla with ac patch set and added to mainline latter.
By the way, CentOS 4.1 uses a 2.6.9 kernel.
There on 2.6.11 + patches
rpm -qpl kernel-2.6.9-11.EL.src.rpm | grep linux-2.6.11
linux-2.6.11-s390-cio-vary_off-fix.patch
linux-2.6.11-s390-qeth_fake_ll-fix.patch
linux-2.6.11-sys_ipc-fix.patch
$ rpm -qpl kernel-2.6.9-11.EL.src.rpm | grep linux-2.6.10
linux-2.6.10-CAN-2005-0867-sysfs-signedness.patch
linux-2.6.10-ac-selected-bits.patch
linux-2.6.10-net-3c59x-reload-EEPROM.patch
linux-2.6.10-net-e100-update.patch
linux-2.6.10-net-e1000-update.patch
linux-2.6.10-net-tg3-update.patch
linux-2.6.10-s390-cio-fix.patch
linux-2.6.10-s390-dasd_io_error-fix.patch
linux-2.6.10-s390-qdio_packet_loss-fix.patch
linux-2.6.10-s390-qdio_time_delay-fix.patch
linux-2.6.10-sata-updates.patch
linux-2.6.10-scsi-cciss-clustering-fix.patch
linux-2.6.10-scsi-midlayer-updates.patch
linux-2.6.10-scsi-qla2xxx-update.patch
linux-2.6.10-sysfs-update.patch
linux-2.6.10-x86-dma_declare_coherent_memory-kmalloc-args.patch
Now if pluggable code in the kernel would be that problematic, it would have happended a long time ago, as basically any running linux kernel (or at least a lot?) has support for kernel modules, and they are not installed while browsing using a konquerer, mozilla, etc. …
Sorry, but if you’re indeed a sysadmin at a commercial organisation I’d recommend they fire you and get someone else today. Updating kernels by a major revision number on a production machine without first testing on a comparable system is stupid enough to constitute gross negligence. The rest of your comment also betrays significant lack of clue.
For the record, I admin an email gateway which passes around 30k mails every day, this has been running a 2.6 kernel for half a year (currently 2.6.11 Debian) without any problems. On the contrary, the 2.6 kernel performs significantly better when dealing with high loads.
I’m not saying that it’s impossible to experience problems on certain hardware when switching between 2.6 and 2.4, but this is definitely the exception and if you have such a problem you should contact your vendor and have it fixed (of course you should do this before converting your production machines).
To the mail administrator… I have a dual Athlon 2000+ box handling over 400,000 mail + 11,000 IMAP4/POP3 connections + outbound relaying. The box also keeps track of generating about 300 SNMP devices with MRTG (which I really need to move to RRD some day).
I haven’t even made kernel parameter modifications, and that box seldom runs over 0.30 load. 3.5G memory and four 15K SCSI drives in RAID 10 setup. Software is homespun vpopmail + qmail (with patches including chkuser and TLS), courier-imap and qsheff with Clam antivirus.
I got the same experience as you..now with the 2.6.12 release I did compile udev and, yes I like it.
Why people are saying 2.6.x is unstable, I have also wondered why..
btw I am a slacker also
“Sorry, but if you’re indeed a sysadmin at a commercial organisation I’d recommend they fire you and get someone else today. Updating kernels by a major revision number on a production machine without first testing on a comparable system is stupid enough to constitute gross negligence. The rest of your comment also betrays significant lack of clue. ”
You are right, maybe they should fire me. However, if you had half a brain, you would realize that you made a point to a completely different argument. You basically made a point about my conduct but did not bother to back up the quality of the 2.6 kernel code. I don’t see how my conduct affects the 2.6 kernel code quality. I don’t see how it affects the thousands of other people that experience similar crashes with the 2.6 kernel. Maybe you can point out how my conduct affects stability. Tell me how my conduct cause a fresh vanilla install of an “Enterprise Level” clone distribution to kernel panic. I guess in your opinion, if I had better conducted myself, the 2.6 kernel would have somehow magically worked.
You don’t determine your kernel version with some rpm command, you do either uname -r or cat /proc/version.
I’ve never tried Redhat, but what you’ve shown here suggests that you have patches from 2.6.10 and 2.6.11 backported to your kernel.
I went to http://www.distrowatch.com to determine which kernel CentOS had. Unless they’re wrong, CentOS has a 2.6.9 kernel. Check here :
http://distrowatch.com/table.php?distribution=centos
I’m also a slacker …. funny thing how slackers don’t experience the ‘instability’ other people attribute to linux itslef, when it’s really about the distribution and/or a mistake by the admin.
If you would have tested, you would likely have found the problem, and perhaps would have had the chance to find a fix to the problem or submit a bug report. But, without testing it, you put yourself in the position of needed a quick, dirty, fix to get it working.
The discussions on Reiser 4 were interesting, and I don’t think that the kernel developers have quite understood what Hans Reiser is trying to do with it in terms of the plugin architecture. Presumably they’ve got their own implementations and filesystems to protect – the politics of kernel development are fascinating.
The common complaint is that it implements too much which they think should be at higher levels, but they haven’t read his rational for it at all. All the layers on top of a filesystem (i.e. WinFS) currently do things very badly and perform diabolically. This is best implemented at a filesystem level, despite what anyone says. Andrew Morton couldn’t be more wrong when he said that a filesystem is some dumb thing which implements address_space_operations, filesystem_operations, etc. More is expected of a filesystem these days, and the half-cocked Storage, Beagle, WinFS etc. implementations and hooks above the filesystem in userspace are not getting anyone anywhere.
Whatever, no kernel or OS can go on using filesystems now in the way they’ve always been used and designed. That’s the whole point of Reiser 4, and if they won’t include it then distributions should just merge it because I certainly think it will become the dominant filesystem. Hans Reiser is implementing what he’s doing at the right level.
> You are right, maybe they should fire me. However, if
> you had half a brain, you would realize that you made a
> point to a completely different argument. You basically
> made a point about my conduct but did not bother to back
> up the quality of the 2.6 kernel code.
You must have missed the part of my post that talks about running 2.6 in production without problems for the last 6 months then…Your dilettantism extends to the simple task of reading, it seems.
> I don’t see how my conduct affects the 2.6 kernel code
> quality.
It doesn’t. It does however make it evident that noone should take your comments seriously because you don’t have a clue what you’re talking about.
> I don’t see how it affects the thousands of other people
> that experience similar crashes with the 2.6 kernel.
Pure FUD, who do you work for, SCO?
> Maybe you can point out how my conduct affects
> stability. Tell me how my conduct cause a fresh vanilla
> install of an “Enterprise Level” clone distribution to
> kernel panic.
For all I know you tried to run a PPC kernel on an i386 machine. It’s probably something slightly more subtle like forgetting to load the correct modules but I’d bet money that a competent admin could have solved it without blaming the kernel.
> I guess in your opinion, if I had better
> conducted myself, the 2.6 kernel would have somehow
> magically worked.
If you knew what you were doing you would have avoided problems. Since you’re a muppet or a troll nobody should take your claims seriously.
reiser – when it works it REALLY works and when it is borked it is BORKED beyond recovery and god help ya!
Let’s assume I am a retard with an IQ of 40. What does that got to do with the 2.6 kernel? Absolutely nothing. But I guess you are too stupid to figure my intelligence has anything to do with the 2.6 kernel.
Want to know what does show have something to do with it’s quality? Go to http://www.kernel.org and look at the changelog for 2.6 series and then compare it to the 2.4 series. Look at what has changed between 2.6.12 and the supposedly ultra-stable, beautiful 2.6.11. Look for the word panic in the changelog. It surely appears a lot for a stable kernel. Now go look through the 2.4 series kernel. Go back through it’s history and look for the word panic. Don’t find it much.
As I said, 2.6 is not stable. I have provided changelogs and my own personal experience to back it up. You haven’t provided anything but your zealotry. ‘Nuff said.
for what it is worth, i dont consider 2.6 to be well tested enough and it is usally that way, i didnt switch to the 2.4 series until 2.4.18…
if you have NEW hardware then you MIGHT need to use a 2.6 but I find the older kernels to be very stable and heck where do you think stability comes from in the newer ones, the new features or all the work that was put into the older kernel line and brought over into the newer one…
new kernel IF you really need it but older if it works for you! peace out
my new patent – method by which asinine folks after brain dumping then proceed to propagate brain dump by a single click on a submit comment button
First off, plugins, they have to be compiled into the system, you can’t just install them and load them, actually, I don’t think you can even load them as a module, they have to be compiled as part of reiser4. ie. If you’re a freakin’ moron and you compile in spyware, kill any offspring you have and die.
Second, I don’t think the kernel maintainers are “getting it”. Complaining over and over again, saying it’s the wrong layer doesn’t do anything except betray ignorance. If you look at the FS’ design, you quickly release that the code naturally follows it’s design philosophy and vice versa, as in it’s good, natural and thusly synergistic. As in, don’t go against the grain, you’ll get icky code.
*gasp* Isn’t this what we have now, a whole bunch of hacks to get things work rather than more natural extensions and scaling? One complaint was, what if you wanted it, then you’d have to do surgery and put it into the VFS. Doesn’t that illustrate who poor the other solution is? That it’s hard to get things working, that it’s not that good a design? It’s hard because one scales and the other doesn’t.
The design philosophy is naturally extendable allowing for all of what Hans is proporting. Furthermore, just because they’ve defined their layers, doesn’t mean a thing, I think reiser is proving their definitions are wrong. Sure, go ahead and make all the logical definitions you want on the architecture of the system, but don’t use those arbitrary models to argue that the code and the design are anything but superior.
The fact that it eases innovation could well mean that reiser could rapidly standardize and improve the linux filesystem scene.
AHAHA.
Poor re-use of an old /. troll post.
Will you two drop your egos for a moment and admit that you are both right and both wrong.
-tnt – The 2.6 series of kernels does have a history of instability, or did you skip 2.6.7? That is to be expected with something that is new, you know this, as any admin with an ounce of sensibility would.
– Slash – How do you know it was the kernel? Did you install a 2.4 series kernel to test it and suddenly have stability? Or could it be that in the upgrade process something wasn’t upgraded properly? Can you vouch for the quality of your hardware?
For the record – The majority of kernel panics that I’ve witnessed in the 2.6 series have been caused by faulty hardware.
Yes, I meant to say 2.6.9 + patches
On enterprise systems, they don’t just update version release for the fun of it.
I was showing they backport needed patches, not the whole tree.
“Will you two drop your egos for a moment and admit that you are both right and both wrong. ”
I will not drop my ego. Linux had a perfect working model of releasing stable even versions and unstable odd versions. It worked great for all the previous releases. The first few revisions of stable releases were always a little rocky, but because the kernel maintainers focused only on stabilizing the code, the kernel quickly became rock solid. The stable kernel during it’s later life might have not been bleeding edge, but when you migrated to it, you could be darn share it will be stable as hell.
On the otherhand, 2.6 has been nothing but a nightmare and disaster. Every single release of 2.6 has been a development release. We are already at 2.6.12 and the amount of fixes and enhancements that are appearing are still astronomical. When is 2.6 going to stabilize? Why exactly are such drastic changes being labelled as minor changes. The fact is that the problem with stability will not go away until the kernel maintainers revert to the old system. We need a 2.7 branch so that 2.6 can be stabilized.
Isn’t CentOS using Red Hat kernels ?
That’s a very good reason for poor quality. A distro-specific kernel receives less testing than vanilla, and receives special patches. Two good readons for instability.
Yet, the new development model for Linux states that it’s up to the distributors for stabilising the kernel on their systems…
If your experience with the 2.6 kernel is so bad and you are so disgusted with it, fix it. This is not proprietary code, you _can_ fix the problems you are having with the code yourself. Fix the bugs and send your fixes upstream, this is how FOSS gets better.
Now answer the question, did you test out your “unstable” server with a 2.4 kernel? If not, you can’t say for sure that it was the kernel causing your instability.
… that one day some one, with way more time and money then me (Mark Shuttleworth?), will fork linux gnu and gnome. Throw out all portabillilty (innovation stoppers) crap and create a killer OS.
An yes Reiser4 is a major part of that dream. I see a little of Plan9 in there too though.
Part of the problem I think with reiser4 and the kernel guys is Hans attitude that his filesystem is the best and everything else is crap and must die. People don’t like to hear that, and IMHO they are right. It’s up to Hans to prove that _everyone_ wants and needs to use reiser4 before any kernel developer could think of ditching VFS, ext2, ext3, XFS, etc and implementing them on top of reiser4.
Hans Reiser is not God, but he acts like nobody else knows a damn thing about filesystems, which is completely wrong.
But Hans isn’t just talking about filesystems he’s talking about name spaces and ways to interact with our data in more consistent ways.
While linux developers aproach the problem as a techincal one “How do I save data in an efficient manner?”
Hans is thinking about it from a usabillity point of view, “How can a the file system name space and it’s interactions be extended to improve the usabillity of a computer system?”.
Anonymous (IP: —.bos1.dsl.speakeasy.net)
Oh, so Hans is showing a little ego, but the kernel developers can’t seem to see the technical merit of his stance and the work he’s leading, but that’s fine, since he’s not being exceptionally amicable.
Heh, that’s my ‘how to build a new BeOS’ dream in a nutshell!
I am constantly surprised that noone is (visibly) following this route, it seems like the simple option.
“Now answer the question, did you test out your “unstable” server with a 2.4 kernel? If not, you can’t say for sure that it was the kernel causing your instability. ”
Yes, it was the same exact server. I wiped out the old install and the installed the new server from scratch. After about running for four weeks, it kernel paniced. I got a new server, with the exact same server specs, and reinstalled on that one. 3 weeks later, the same thing happened to that one. Perfectly fine with 2.4, problems with 2.6.
I just don’t understand the problem.
I understand the need of vfs layer for other fs, but reiser.
Why don’t make vfs implemented as a factory
(a la getVFS for partition X) and then implements different vfs code for different fs and in case of reiser just use a dumb one based on plugins???
Sorry if I do not undestand the issue correctly.
did you post your problem on the CentOS mailing list. There is a great community around the distro and you would have probably found a solution for the problem.
we recently tested CentOS4 for 7 days on full load for a application of ours and found the stability verymuch acceptable… we are shortly migrating a few of machines from MS Win2K, CentOS4 is our distro of choice for a few reasons, with the great community around it being one of them
Throw out all portabillilty (innovation stoppers) crap… (sic)
Now that’s a load of manure if I ever saw one. Portability does not stop innovation. It puts a neccessary check on the “bleeding edge” and forces developers to put something out that is USABLE for more people.
Hardware vendor lock-in is just as bad (if not worse) than software lock-in and personally, I don’t want to deal with it. If every new x86 processor pulls some kind of DRM+Hypervisor OS restriction and I can only run Windows, then I want to be able to dig up my PowerPC box (which could be a game console 😉 knowing that my OS and my software can be recompiled and run without having to sacrifice features. Note: hardware performance is irrelevant to this post. Portable software gives you an out in case we all lose control of our hardware (unrealistic, but possible).
Besides, if some k3wl n3w f34ture is really that good, then why SHOULDN’T it be ported to other architectures? If it takes advantage of some unique hardware capability, fine, I understand, but if it’s high-level enough, then everyone should have it.
–JM
Who hopes that someone will take this mythical fork and make it portable out of spite.
sorry, i stilll want my filesystem to be rock solid stable and simple, my filesystem is not where I want any complexity or features implemented because complexity and features brings instability and potential trouble….
raise your hand if you have ever had a reiserFS crap out on you completely… total wipeout… (raises hand)
by “portabillity crap” i didn’t mean the abillity to run on diffrent hardware. I ment that Gnome can’t leverage new linux fetaures for the sake of being runnable on Solaris or BSD or whatever. Sure portabillity is nice, but I’ll take a usable system over a portable system any day.
It seems that each time someone comes up with a great new way of doing things people begin to shout, “but it is not POSIX”. Screw POSIX, if you can’t have new feature because of POSIX it is POSIX that is broken.
That’s the funny thing, Hans showed some really amazing stuff that can be done with reiserfs, so much so that one could go so far as get rid of posix and do things in a “linux/reiser” fashion.
The problem is people are too worried about compatability, well if they worried about that, there would be more than posix and a lot of shared kernel API and all sorts of things between the BSDs and Linux, but there isn’t. There are a lot of niggles and quibbles that makes things hard. It would just be easier to maintain a posix sub-system hack which emulates all that’s needed by posix programs, but move on to new things. It’d also be nice if protocols were opened up along the way so that one could allow for compatability with the new system, this would imply the protocols to not be GPL, however.
Honestly, this would be the first major development in Linux, but that’s not going to happen with this, we have to make everything be friends, rather than ruthlessly pursuing meritorious technology.
Man, it just blows me away that some of the kernel devs don’t want to merge Reiser4 because it is too good and might make ext3 look bad.
And they don’t want FUSE, seemingly because it might bring a useful feature to the OS… I really can’t fathom what the problem with not compiling FUSE if you don’t want it might be.. But to deny the users, who clearly are crying out for this functionality, who have been forced to introduce ugly, incompatible and poorly performing hacks (gnome-vfs, kio slaves) the benefit of a simple, kernel-level layer is baffling.
Whats really odd is that in other cases seemingly any kind of garbage is welcomed into the kernel (e.g. broken firewire under 2.6, the please-panic-my-kernel ‘ub’ usb block device driver, devfs which was abandoned and deprecated as soon as it was included etc. etc. etc.)
Clearly a number of kernel devs have lost their perspective on these issues, and from an outsiders point of view they look like big fat hypocrites.
You should try the new Preempt in the 2.6.12-mm1 kernel for desktops machines, makes my desktop very snappy indeed so I think people seem to under estimate 2.6.x. I’ve been using 2.6.x right from 2.6.3 and it’s always worked perfect for me, makes me wonder what some distros are doing under the hood because Slackware is just soooo solid.