Slashdot Mirror

As I wrote in the comment to another KernelTrap story, using the term "GNU/Linux" (referring to the GCC and glibc essential role in the system) is totally misleading.

Both GCC and glibc are in the current state despite the RMS and FSF efforts. For GCC, remember the situation from the 2.8 times, when an independent team (egcs) had to fork GCC, because the FSF-managed development of GCC was dead. In the same way remember years of work that H.J.Lu invested in Linux libc, because GNU libc was unmaintained and unusable. And of course the work of Ulrich Drepper, who took GNU libc2 and developed it into a form usable in Linux-based system. Ulrich considers none of his work on glibc to be a part of a GNU project (details here, see the bottom part of the text). And it looks like even the present situation in the GCC development is the same (anonymous comment at KernelTrap).

So I can say run GCC/glibc/perl/X.org/TeX/etc/Linux system, but it has nothing special to do with GNU and FSF, and I just prefer the short name "Linux" (named after a single biggest, always-running, and essential component of the system).

Two worries were preventing me from doing it. One was a worry about the inability to send a Microsoft Word format document like a resume in an e-mail, but of course, you have the ability to do that in Linux currently, and I guess for now, legacy Word programs force Microsoft to maintain backwards compatibility. The second worry, a more real one, was games. I knew the latest versions of Doom, Warcraft, Everquest and so forth were on Microsoft and not Linux. This turns out to be more substantial than my vague uneasiness over the ability to send Word format documents (which of course, for now, you can send in Linux).

What I did is install Debian 3.0 ("woody"). I played some games with lightweight graphics capability like Freeciv or Xboard, but then wanted something more hardcore so I downloaded Tux Racer. It was slooooow when I played. Averaging 0.7 frames per second actually. So then I read I needed drivers for my specifics graphics card to get it to a higher fps rate. I began installing the non-free kernel modules for it, but it was unhappy with the versions of some Debian 3.0 packages, especially XFree86 (xserver-common). I was also having some problems with my H-P PSC (Printer-Scanner-Copier) and its Linux drivers because Debian 3.0 had an ancient version of Python and so forth. So I decided to upgrade from stable version Debian 3.0 ("Woody") to testing version Debian 3.1 ("Sarge").

This fixed my HP PSC problems with Python versions. I am still struggling with Mesa, OpenGL and so forth, and right now can not run tux-racer. I have newer version of Mesa then I did with Debian 3.0, but I'm told my newer one is out-of-date by Tux Racer (whereas my older one was not). I haven't even tried to put the special drivers for my graphics card driver in (which needed the newer version of XFree86).

Anyhow, I've been using UNIX since 1989, and have been a UNIX sysadmin since 1996, and getting Mesa/OpenGL packages working on Debian is giving me trouble, I can imagine what it would be like for someone less experienced. Plus, even if I do get Mesa working for Tux Racer, I will have to be fortunate enough to have graphics acceleration support for my card in Linux. And then, even if those two birds get knocked down, how many games are there out there for Linux with those capabilities - Tux Racer? One or two more? What else? I already know that ease-of-setup for graphics is easier in Windows than Linux (system upgrade, then Mesa problem, followed by looking for graphics acceleration support for my card which may or may not be a problem), how does it stack up against DirectX for the same equipment?

Of course, for free systems, one good thing is I can be part of the solution. I have over a decade of UNIX experience, but only recently has my C programming gotten semi-decent (if that - I can write an OK program in a month, but then it takes me a year to debug all the thread race conditions, buffer overflows and so forth I seem to leave about). Even so, it is very daunting for me to feel I can contribute to these sorts of projects. I know a lot about how the Gnutella protocol so I have a leg up on other people looking to contribute to them - but looking over the code and seeing all of the linked lists, pointers to pointers, calls to GLib and so forth, I wonder if I can ever make a contribution to them since unlike full-time developers, I only have the faintest ideas how things like linked lists work. The learning curve to be able to contribute to these projects is somewhat steep in my opinion, although I always hear stories about kids who stumble over some code, begin sending contributions, and begin running some major project while a teenager, like the guy who maintains the Linux 2.4 kernel I run on my machine.

Common misconception. No such exception exists.

Here's where I step in with a favorite URL - http://kerneltrap.org/node/view/4126 - wherein Linus himself points out that GCC 3.x is a generally worse C compiler, with some advantages in C++ compiling being its only real saving throws.

While I can't honestly say BSD projects haven't come under the same kind of problems (FreeBSD 5, for instance, which at least right now isn't a pretty sight), the tendancy is not to replace perfectly fine systems (like gcc 2.95's essential core, which was fast and light) with monstrosities (gcc 3.x). If something new is to be implemented, it has to be Right in design and in practice. If a BSD project wrote a compiler, it would be free, light, very UNIXy (functional, not kitschy), and few people would care because it's not GPL and anything non-GPL must be inferior, right? Some people...

ulib: Right on, and thanks for that.

It isn't enough for grandparent that Linus himself says the new gccs are slower than the oldies? (http://kerneltrap.org/node/view/4126) Okay, you can try it yourself (install, however you do, gcc 2.95.x and 3.3 or 3.4 or whichever you think is the better one, and compile the same code).

The new GCCs support more targets with more optimization and this is of course helpful, and C++ support is actually good for something now. But this should not have come with such a heavy performance cost. Care to argue this point? I'm more than willing (well not really) but you'd be wasting your time.

As for thinking I'm a lame troll, fair enough, join the club. Lots of people think that about me. What I say, I say from experience or research. If you don't like it, disprove it, don't just whinge. If you can't disprove it, deal with it. This applies to everyone.

I have to agree with Intel that 64-bit desktops don't make a lot of sense right now.

For those who missed it last time around, Linus was also tempted to call it amd64 in reaction to intel's handling of the subject but decided to stick with the vendor neutral x86-64.

And yeah, this moved from the realm of rumor to fact nearly a year ago :)

Alan Cox seems to be trying to stablize 2.6 with his -ac patchset.
I think I may be moving over to that from the vanilla releases of 2.6.

Alan Cox seems to be trying to stablize 2.6 with his -ac patchset.
I think I may be moving over to that from the vanilla releases of 2.6.

You can see where this is going.

Recapping:

• Microsoft source gets into the wild through negligence on someone's part
• Microsoft starts offering generous Royalty-Free terms on various internet protocols (though many are peeved that the blanket protection seemingly covers protocols not actually owned by MS. In the confusion, people not paying attention will be confused.)
• Microsoft, like HP, Novell and Red Hat before them, and, after all the FUD cloud emanating from the corpse company called SCO, offers indemnification against customers getting blackmailed by Intellectual Property Threats (like what SCO attempted to do to Autozone and Daimler Chrysler).

If you thought it was difficult doing a thorough Theo code audit for security was a formidable task, even given the open source code, then imagine the difficulty of looking through all of the source and wondering if any of it infringes on anyone's claimed "Intellectual Property". There aren't any options to diff and grep to complete such a task, AFAICT. The other half of the comparison remains under lock and key, except to those with rights to the IP.

Linus' policy of requiring signed patch contributions to the Linux source looks more and more like a good and proper defensive measure. I'd feel better if other high profile FOSS projects had systems of signing patches and an examinable web of trust between the major contributors. Go ahead and accept patches, but let each contributor sign them.

The whole issue of IP indemnification reeks of a deliberate strategy to slow the growth of free and open source deployments by sowing doubt into the minds of decision makers considering use of FOSS for their business but must consider risk in their decision (and a limited amount of time and information on which to base a decision).

Transparency should make FOSS less IP infringing quickly compared to closed source, where IP infringements can be compiled away from easy recognition by the IP owners.

The WiFi area is being tackled by OpenBSD:

Thanks to their efforts both all all OSS systems (including Linux) will soon be able to have wifi on install without hassles.

OpenBSD: Trying To Contact Texas Instruments

Feature: OpenBSD Works To Open Wireless Chipsets

OpenBSD: Intel Refuses To Open Wireless Chipsets

The WiFi area is being tackled by OpenBSD:

Thanks to their efforts both all all OSS systems (including Linux) will soon be able to have wifi on install without hassles.

OpenBSD: Trying To Contact Texas Instruments

Feature: OpenBSD Works To Open Wireless Chipsets

OpenBSD: Intel Refuses To Open Wireless Chipsets

The WiFi area is being tackled by OpenBSD:

Thanks to their efforts both all all OSS systems (including Linux) will soon be able to have wifi on install without hassles.

OpenBSD: Trying To Contact Texas Instruments

Feature: OpenBSD Works To Open Wireless Chipsets

OpenBSD: Intel Refuses To Open Wireless Chipsets

And just out of curiosity what totally free hardware are you using to post to /.? Video Card? Probably not. That's still talk. NIC? I ain't seeing much maybe I should make that an Ask /. question. Soundcard? What about your printer? Just how much are you sacrificing to be truely free? For the OBSD community it was some time to write a thoughtful letter to get the ball rolling.
Today we now have some easily distributable firmware for desired hardware. We'll see what tomorrow brings.

Linux made his view on C++ in the kernel a while ago here

Search Google or the kernel mailing list for "C++" and you'll come up with discussions about the whole issue. For example, see this discussion from earlier this year (which includes the quote from Linus.)

third: you can write in ASM too, but that doesn't mean you should.

No, that's not true -- sometimes, you really need to use ASM. Go poking around the linux kernel (in particular, the 'arch' subdirectory) and you'll find plenty of assembly code. The point here is that you use the right tool for the right job. Linus, obviously, feels that C is the better tool for writing an operating system kernel than C++. Obviously, there's more than one way to do things, but I tend to respect Linus' opinion on something like this.

Of course, if anyone feels like Linus is a total idiot, then they can try porting Linux to C++. I'm willing to bet that if someone could show substantial real benefits from a C++ Linux, Linus would happily eat his words.

Now suppose TCC is 10 times as fast as GCC (which is true based on my experience), the 32-way machine is 20 time as fast as than a single Power4 (the kerneltrap site said "2246% CPU usage"), and the 2.4GHz Pentium4 is as fast as a 1.1GHz Power4, then building the kernel just takes 15 seconds. Of course, it is a rough estimate, and I suspect the P4 should be faster than a 2002-ish Power4 for cpu-intensive job such as compilation.

UML support was added to the 2.6 kernel a while back (2.5.34 in Sep 2002).

Since then the mainline kernel has lagged behind the latest UML releases on user-mode-linux.sf.net.

Over the 2.6.8 to 2.6.9 timeframe BlaisorBlade (aka Paolo Giarrusso) has worked with Andrew Morton and Jeff Dike to bring the mainline kernel up to date with the latest UML changes. (To the point where the 2.6.9 kernel is more current than the latest 'official' UML release). I would guess this was the biggest, in terms of lines of code, change in 2.6.9. Most of the changes just touched the 'um' architecture though. So changes are pretty isolated from other arch-es.

This may be of interest to you if you run chrooted systems anywhere (UML may be more secure). Or if you are a kernel hacker (so much easier to debug things that run in a user process).

--
(UML-based) VPS Hosting

From the email threads and writeups on KernelTrap, it seems as though Linus (and his Lieutenants) have some issues with the invasiveness and maintainability of the patch, which are reasonable concerns from the maintainers.

Ingo Molnar - a RedHat employee/kernel hacker - has some patches that are similar in scope but different (and most likely preferable from a performance and maintainability viewpoint) in approach.

Read about them here and form your own opinion:

Linux: Real Time Kernel Prototype

Linux: Realtime Preemption

From the email threads and writeups on KernelTrap, it seems as though Linus (and his Lieutenants) have some issues with the invasiveness and maintainability of the patch, which are reasonable concerns from the maintainers.

Ingo Molnar - a RedHat employee/kernel hacker - has some patches that are similar in scope but different (and most likely preferable from a performance and maintainability viewpoint) in approach.

Read about them here and form your own opinion:

Linux: Real Time Kernel Prototype

Linux: Realtime Preemption

Read a bit on how a O(1) scheduler works, and how RT priorities work, an then think why a lowest-priority SETI process is really not much different than a lowest-priority NULL process. If your lowest prioirity idle process is calling HLT it's causing big latency problems by turning on and off clocks. If it isn't it's eatingn power.

How was problem discovered?
Is this attempted hack a "simple trivial bug" or an "interesting bug"?

Actually, I would like to see some interface in the kernel level. Here is a pretty recent discussion in kernel's mailing list regarding reiserfs4 (, winfs, mac osx' new search thing) and reiser4's plugin mechanism. Interesting read.

Well, Con Kolivas has his staircase scheduler patch that's trying to get better interactivity, and recently Nick Piggen also has a scheduler patch designed to get better interactivity. See these kerneltrap.org stories:

Nick Piggen's scheduler patch

Con Kolivas's scheduler patch

Well, Con Kolivas has his staircase scheduler patch that's trying to get better interactivity, and recently Nick Piggen also has a scheduler patch designed to get better interactivity. See these kerneltrap.org stories:

Nick Piggen's scheduler patch

Con Kolivas's scheduler patch

Don't be a moron. I never said that the BeOS scheduler was all-around better than the O(1) scheduler. I pointed out that the O(1) scheduler is *way* more scalable. However, the O(1) scheduler also has problems with interactivity estimation --- ie: figuring out what apps are interactive, and thus should get faster response times. That interactivity estimation is what made the BeOS so good for desktop workloads.

There is a reason why Andrew Morton is experimenting with different CPU schedulers in his -mm tree.

Don't be a moron. I never said that the BeOS scheduler was all-around better than the O(1) scheduler. I pointed out that the O(1) scheduler is *way* more scalable. However, the O(1) scheduler also has problems with interactivity estimation --- ie: figuring out what apps are interactive, and thus should get faster response times. That interactivity estimation is what made the BeOS so good for desktop workloads.

There is a reason why Andrew Morton is experimenting with different CPU schedulers in his -mm tree.

Install Stuff
You now have the possibility to add extra media (CD or network) during the installation. This means that you can download only the disc 1 or the new mini disc 1 and add a network source to complete your packages list.

Hardware Stuff
Firewire Networking
On computers with firewire, firewire networking will now be bound to eth0, while all other network cards will become eth1 and so on. People doing an upgrade, should remove their network configuration via Mandrake Control Center, and then recreate it, with the correct ethernet device. Laptop
laptop_mode is used to lower battery usage via the suspend-scripts package. Configure it with /etc/sysconfig/laptop.
PCMCIA network cards

Network cards must be set to ONBOOT=yes now. So you need to change it if you upgrade using drakconnect or any other ways.
udev is now the default device manager
Is there anything the user has to do to deal with this switch?

• Bug #4321 df lists full filesystem device names instead of short form => udev should solve that
• Bug #10821 udev doesn't remember NVIDIA driver devices => put in /etc/modprobe.preload

CD Burning

• there's currently a known bug in kernel-2.6.8.1 for CD burning Bug #10840
• the correction is available / should be included soon : http://kerneltrap.org/node/view/3659
• current impact on K3B : K3B news cannot recognize CD writer

PalmOS PDA

• most PalmOS PDA working device should now be automatically detected and linked to /dev/pilot (see Bug #3381), but some can't be autodetected (like Tungsten T, T2). In this case (ie if pilot-link -l failed after starting hotsync on the Palm), add "VISOR_SWAP=true" to /etc/sysconfig/usb to force correct device usage.

Userland Stuff Desktop KDE

• Removable devices

supermount isn't used anymore to mount removable devices, they won't automatically appear on KDE desktop. To have removable device icons back on your desktop, go in the KDE Control Center/LookNFeel/Behavior/Devices icons, and make sure that the "Unmounted Hard Disc Partition" option is checked. This will be fixed in 10.1 Community edition. GNOME

• GNOME 2.6

Menus The simplified menu system has been enhanced to avoid the "All Applications" entry. Networking hostname changes and X sessions hostname changes triggered by network scripts will no longer break X sessions. This is implemented in the s2u package. default route Default routes are handled by device now to allow easy plugging/unplugging of network cards. To have priority between your devices, use the METRIC variable in your ifcfg-* files. Are there instructions on how to do this somewhere?, what are the allowed values of metric? internet service The internet service has been removed in favor of the normal network service. The installer or drakconnect will take care of the transition. Net Applet There is a new net applet that displays the network status in the notification area of the panel.

System Udev Udev is now the default device manager. Xorg xorg is now t

I work at a manufacturing company...

Okay, that's an interesting starting point.

There are as yet unresolved issues with the use of binary software with GPL software in general and linux specifically, despite linus' assurances that userspace code doesn't require GPL license compatibility and that he won't enforce that section of the GPL.

What was the link supposed to show again? Modules aren't userland programs. Modules (at least with 2.6.x) have to compile against the kernel source, and that's *clearly* covered under the GPL. The only real question then is whether such use of the kernel code is fair use. Whatever the outcome of that, userland is a wholly separate issue where no linking takes place (headers aren't even needed; you can just use a syscall chart and make your own if you're that paranoid).

What we found, is that the GPL, LGPL and other FSF licenses are very problematic when dealing with the control of code(proprietry or otherwise).

That's the whole point, actually. The GPL is designed specifically to remove control from everyone through copyright law.

The GPL licensing terms are very strict and dangerous in terms of source code-ownership vs binary code-distribution and legal obligations.

I'm not sure what your basis is for strictness, but the only restriction the GPL includes is if you use GPL code in your code that if/when you distribute said code as a binary, you provide one of 2 or 3 ways for someone to gain the source under the same terms you got the GPL source. Yes, this is a good deal more restrictive than say the BSD, but at the same time it's a lot *less* restrictive than preventing you from giving out binaries *or* source.

As for "dangerous in terms of source code-ownership", it's not dangerous at all. You own your source code, but you don't have a right to distribute someone else's code except under their provisions. If you don't like it, don't use their code.

We're left to the whims of copyright owners and their good word to decide what is considered a breach and what is 'tolerated'.

You're describing the use of all external software. Look at how SCO is suing IBM over a contract dispute which they bought/inhereted through several generations of companies. If you're that worried about what external copyright owners might do, never use external code; then you just have to worry about being sued because someone external claims you used their code anyways.

As we see more GPL software being used by companies with proprietry code, I think we'll see a nasty side of the GPL rear its head as enforcement starts to kick in from different areas.

"Nasty side"? You mean copyright law? If copyright law didn't exist, there wouldn't be any "nasty side" nor "ownership" nor "enforcement" nor "licenses". Because there exists copyright and the first three are in place to only benefit the original author of a work and no one else, the GPL is designed to counteract all the negative effects of copyright with copyright, through bloody enforcement with lawsuits and all.

It sounds like you're more interested in taking something which you don't own (GPLed works), using it as you please with other works (possibly stuff you licensed from someone else), and you're unhappy that the GPL conflicts with the latter when stuff like BSDed works don't. But, the GPL is all about making things non-proprietary, so no one can claim exclusionary control as fundamentally it's the exclusionary control that is what's causing all your/our problems in the first place.

Linus and others in the "open source" group are pragmatic, though, and realize not everyone is going to change overnight. But, they also realize the best way to guarantee that the Linux kernel behaves well is to have as much information as possible; dumping in binary/closed modules is horribly insecure,

There are as yet unresolved issues with the use of binary software with GPL software in general and linux specifically, despite linus' assurances that userspace code doesn't require GPL license compatibility and that he won't enforce that section of the GPL. Linus is using the GPL license as written by the FSF, albeit fixed to V.2 and with some specific modifications. They (linus and the FSF) disagree on on the details of whether or not using GPL-licensed header files forces the software using them to be be under a GPL-compatible license. Even linus admits there are grey areas and his interpretation has been debated. Until this matter is resolved definitively (probably in court), I don't want to place my company at risk of being forced to release code that we do not want to release, simply because we compiled our software for linux.

What we found, is that the GPL, LGPL and other FSF licenses are very problematic when dealing with the control of code(proprietry or otherwise). The GPL licensing terms are very strict and dangerous in terms of source code-ownership vs binary code-distribution and legal obligations.
The FSF cannot of course, enforce the GPL for software they don't own the copyright for. However, the licensing conditions and restrictions of the GPL automatically come into effect without much influence from the actual copyright holders. We're left to the whims of copyright owners and their good word to decide what is considered a breach and what is 'tolerated'. As we see more GPL software being used by companies with proprietry code, I think we'll see a nasty side of the GPL rear its head as enforcement starts to kick in from different areas. Boundaries of legality are constantly tested, when they are wide and filled with grey.
Just because you don't get charged with doing something illegally as you do it, that doesn't mean that you can't get prosecuted afterwards, if someone feels like going after you.

Nope convertfs won't work... From the horses mouth:

To upgrade from reiserfs V3 to V4, use tar, or sponsor us to
write a convertfs.

The lkml posting is probably cached all kinds of places, but kerneltrap also reproduces it in full.

Then again, reiserfs v4 and v3 have nothing to do with each other (unlike ext2 and ext3 for instance), so there's no quick fix possible probably.

On the other hand - reiser4 is completely untested (compared to reiser v3 and jfs, xfs, ext2, heck even the wine-dll emulation layered ntfs writing driver...), so do yourself a favour and don't do anything quite so crazy as not just using it for a production machine but also trying to convert an existing system to it with 'smart' tricks... Give it a little while... or make a lot of backups...

Well, Mr. Reiser Dude suggests tar in his posting to lkml which can also be viewed on kerneltrap.org.

In other words,

no.

On occasion, someone will write up a nice summary of highlights. Anyone seen such a thing for 2.6.8?

Kerneltrap usually posts one shortly after release. Not yet posted for 2.6.8, though, but check periodically, I would think that they will update later today.

This is pretty much the de facto response by people who can't defend their position. "If you don't agree with me, then you're either an idiot, or you're being an asshole."

Metric prefixes were defined long before computers came around. The binary prefixes aren't the greatest solution, but at least it's something. Perhaps they used to be used only by a handful of elitists, but they're beginning to gain favor now in places that might surprise you.

I suppose you could call Alan Cox an elitist, but I think he's being a realist.

Jason.

4) (Anyone know why hostap stuff hasn't been brought into the main kernel tree?)
Read Linux: Generic 2.6 Wireless Driver,
"Jeff Garzik, the network device driver maintainer, announced the creation of a wireless-2.6 development tree, aiming to provide some generic wireless code that is non-intrusive enough to be merged into the 2.6 stable tree [forum]. He chose the Host AP driver as the starting point, with the intention of merging in some of the other existing work, including the current open source Centrino driver. "

Um, this was already tried last November. Not only was the exploit very subtle indeed but it was still detected and removed within 24 hours. This is about as effective a piece of FUD as AdTI's last effort, and it looks like they were so embarrassed by that one they are resorting to a new name. I'm guessing we won't be hearing from "Green Hills Software" again once they've been publically ridiculed either...

Gammage also stated that until Linux is shown to support the NX (No eXecute) security technology supported in Microsoft Corp's forthcoming Windows XP Service Pack 2, it will be seen as potentially deficient to Windows. However, Red Hat released a patch for the Linux kernel to support NX in June that has the full blessing of Linux creator Linus Torvalds.

Yeah, right. Read 'em and weep.

I don't think that they actually included that patch to the -mm patch set (that was what the actual debate was really about, as I recall)

greg k-h: "Hm, seems kernel.org dropped my big patch,..."

His point was that devfs was unmaintained and buggy. (I don't know about the validity of his claims, though -- he also said that it was unused) He then uses the "new development model" as a further justification, which I'm not sure is a valid justification, either.

It seems to me that everyone is assuming that there will never be a 2.7 tree. From the article, the simply quote Jonathan Corbet as saying that "2.7 will only be created when it becomes clear that there are sufficient patches which are truly disruptive enough to require it. When 2.7 *is* created, it could be highly experimental, and may turn out to be a throwaway tree."

They are just concentrating on the stable branch for now, and collecting a patch set (Andrew Morton's -mm patch set, that is) as a testing ground for proposed (stable) kernel changes.

This really doesn't seem like a big deal, and it implies that the kernel people will focusing on stability for the time being.

So with development continuing longer on the 2.6 branch it might help decreasing the diversety of the different vendor kernels. At least it is worth trying.

Maybe you forget that Marcelo Tosatti, a Brazilian, is the maintainer of the Linux 2.4 kernel? Linus sure seems to trust his code.

Maybe partly because of the new format:

From: Andy Whitcroft

[..some describtive text..]

Signed-off-by: Andy Whitcroft
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds

The good thing that came out of all the SCO-crap.

Sure, *BSD was the first OSes to implement IPv6, and FreeBSD have IPv6 enabled by default.
And for SMP, FreeBSD and NetBSD have had this feature for a long time.
Personnaly i remember removing this line in my freebsd kernel config file for almost 3 years.

No, the point of hyperthreading is to expose functional units that are not being used by the main process('s) running on the physical CPU. If you naively schedule everything across both 'CPU's' you will end up with stupid things like running parallel versions of a tight integer loop which is already maxing out the integer calculation units thus polluting the data cache and stalling the pipe MUCH more often which is a BAD thing on the P4. For more info on scheduler tweaks to accomodate HT I suggest you see this LK post by one of the Linux scheduling gods =)

Those who have done tests have found that kernel preemption reduces average latencies rather than worst case latencies (e.g. when your audio drops out or window stutters you are seeing worst case latencies) at the cost of hurting throughput a tiny bit (so things actually take longer because they are interrupted more). In general, the low latency patches had a bigger effect than preemption which is why many of the distros do not ship with a kernel with preemption on by default. However it is useful as a debugging aid and may well be a stepping stone to something else.

I suspect you will find more of the cheats that Window's uses making their way into Linux desktop distros because the user perception is improved. Currently I'm willing to trade a bit of RAM for a faster startup but it's how to do that so I do not notice that you are doing so is the real trick.

Rememeber the Great VM Replacement in 2.4.10?
I remember hearing about it, but I don't think I ever noticed a difference.

Or the current mess with reverse mapping?
AFAIK the performance is fine, the worst problem is the amount of memory it consumes for management. But Andrea Arcangeli has a solution.

/proc/sys/vm/swappiness

I forgot to explain swappiness. This is a entry in proc, /proc/sys/vm/swappiness, that you can plug a numerical value between 0 and 100 into. The higher the number, the more eager Linux will be to swap out applications from RAM to disk. There's a lot of conflicting opinions on what values you should use. Kerneltrap had a good article on it recently.

Personally I use a value of around 20 or less for desktop machines. This keeps Mozilla being paged out after a short while, that really shouldn't be happening on modern hardware. Too bad you can't achieve the same effect in Windows 2000. Some people swear that a swappiness of 0 is ideal for their desktops, your mileage may vary. It's fun to play with in any case, any changes you make take effect instantaneously.

I could see this as being true "6 or 7 years" ago, but any remotely modern linux distribution will NOT have a problem with this, even on 32-bit platforms. Here is a screenshot debunking your claims for both rcp and cat.

I realize that this could be corrected, even on 32bit systems, and that there are applications like tar that have had "large file support" for some time, but on my 64bit systems (alpha) running rh 7.1, this is not true. Upgrading is not really an option for me, and I consider them "remotely modern" because they are about 2.5 years old. I realize that compiling with the OFFSET_BITS or whaever the define is will give you large file support, but you cannot say that I did not have the problem with large files recently, because I did on the system that I mentioned.

ronically, the one limitation that you do state correctly is also one of the limitations that only applies to 32-bit systems. It sounds like you need a 64-bit system after all, preferably a modern distribution like Fedora 2 or SuSE 9.1 that doesn't have any of the weird userspace problems that you bring up.

This is regarding the 1 or 2 Tb limit. Well, I'm running RH AW 2.1 on 64bit Itaniums machines, and when I called RH support the polite Indian guy on the phone told me "maybe 4.0 will support this", I otherwise would have to partition my array. Logical volumes can be created beyond 2Tb, but block devices cannot. There are many kernel posts about this and this kernel trap article about it.

And you have corrected everyone by saying platform does matter, how? I still say for large memory applications, thats about it.

You may read the lkml thread and Linus post on kerneltrap.
Just thought it could be interesting...