Slashdot Mirror

On more modest hardware, NetBSD is a lot of fun. See - I even swing both ways. :)

But come to think of it, there are commercial alternatives to Winblows as well: e.g. Mac OS X. A lot of people are discovering that OS X is an industrial strength server O/S that shines very brightly on the desktop too. And Apple hardware is very hard to beat reliability-wise (speaking as someone who's been in charge of Mac studios nearly 20 years).

All we need are some facts to shine through the constant smog of FUD from Redmond and their hirelings. Then the war is won. Can't wait.

http://kerneltrap.org/node/view/3097

Unfortunately this doesn't fix the problem with Virtual PC. Install works fine (textmode) but then booting crashes with a processor error immediately after uncompressing the kernel. Must be related to the 4K page update? :-(

--jeff++

My (one and only) blog entry on kerneltrap has instructions for running Fedora Core 2 Test 3 under VMware Workstation 4.5.1. I will confirm the procedure works with the released FC2 as soon as I finish downloading the damned thing. (3 hours to go on disc 3. W00t.)

http://kerneltrap.org/node/view/3097

Hm. I'm not sure, not having done much looking into ext* for mission-critical stuff. Theo de Raadt in an interview banged pretty hard on those, and what linux is doing w.r.t. filesystems. There is a -o sync option for ext*.

Still, having been bitten a few times by ext2, I kind of have bypassed ext3 altogether. I only use it in a few places (normally where I store the kernel, so grub can read it, and well, with GNU/Hurd....but FS stability is a whole other issue there). When I do use Linux for important things, it's almost exclusively XFS these days, and I make up the performance with hardware. Sychronous writes are fast enough on a 10k rpm scsi disk. :-p

I think they should make a short version of the change log with a summery of what changed. Does anybody know of such a thing?

KernelTrap.org is fairly close to what you're asking.

I have found that KernelTrap often discusses things in language I can understand, and then it should be quite accessible to many more than kernel hackers... :-)

You don't need to back out the patch. It's a configurable option. (You're talking about 4k vs 8k ...) More info here.

KernelTrap has more information about the 2.6.6 release. Looks like lots of good stuff was merged! Laptop mode, CFQ, ...

It's a big deal because this is Slashdot, and we need something from Microsoft to bitch about daily, especially if it's Longhorn.

This isn't a pro-Linux site--it's become an anti-Microsoft site. Where's the article about the I/O file regressions happening in kernel 2.6? Oh, that's right, it would break the hegemony.

Slashdot doesn't want you to read this:

A recent discussion on the lkml looked into a reproducable random file I/O regression in 2.6 compared to the 2.4 kernel [forum]. Alexey Kopytov posted the benchmark results, attempting to simulate the workload of a database under intensive load. The tests were tried with all I/O schedulers, including the anticipatory [story], deadline [story] and CFQ [story], and in all cases 2.4 outperformed 2.6.

The resulting thread was primarily between anticipatory scheduler author Nick Piggin [interview] and 2.6 kernel [forum] maintainer Andrew Morton [interview], examining the state of the readahead cache. At one point, Andrew suggested, "readahead has got too complex and is getting band-aidy. I'd prefer to tear it down and rethink things." The regression was ultimately tracked down by Ram Pai, caused by multiple threads accessing the same file descriptor. Andrew agreed, "for some reason this mucks up the 2.6 readahead state more than 2.4's." He provided a small patch to properly maintain the read ahead state, included within.

Hop on over there if you want the whole thing.

Sure. Now, the documentation is available.

However, on the day that the UltraSPARC III was released to the market, the documentation was not available. What was finally released as documentation was a hurriedly upgraded version of a set of micro-architecture notes that had been out of date by 4 years.

The compiler folks at Sun had a hell of a time in writing the optimizations because there was no current micro-architecture documentation. Just ask the 500 engineers who were laid off from the Sun processor group. They will tell you about the sorry state of processor development at Sun.

The motivation for the non-disclosure had little to do with protecting company secrets. The documentation that was released to the Linux folks was flawed and missing key information becuase the documentation was a rush job. Making such documentation public would have been a public-relations disaster.

Let's not mince words here. McNealy deliberately reached outside of the company to develop the next-generation processor, the Niagara based on the Hydra (that was developed at Stanford University), because the in-house processor groups just sucked. To be fair, I must say that McNealy's server engineers are decent and kick-ass. Their systems were ready, on schedule, to accept the UltraSPARC III, but sat idle for 2 years because UltraSPARC III was behind schedule by more than 2 years.

From: Linus Torvalds [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Wed, 3 Dec 2003 16:00:21 -0800 (PST)

On Wed, 3 Dec 2003, Kendall Bennett wrote:
>
> I have heard many people reference the fact that the although the Linux
> Kernel is under the GNU GPL license, that the code is licensed with an
> exception clause that says binary loadable modules do not have to be
> under the GPL.

Nope. No such exception exists.

There's a clarification that user-space programs that use the standard
system call interfaces aren't considered derived works, but even that
isn't an "exception" - it's just a statement of a border of what is
clearly considered a "derived work". User programs are _clearly_ not
derived works of the kernel, and as such whatever the kernel license is
just doesn't matter.

And in fact, when it comes to modules, the GPL issue is exactly the same.
The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that
leads to any gray areas. There are areas that are not gray at all: user
space is clearly not a derived work, while kernel patches clearly _are_
derived works.

But one gray area in particular is something like a driver that was
originally written for another operating system (ie clearly not a derived
work of Linux in origin). At exactly what point does it become a derived
work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe
that some modules may be considered to not be derived works simply because
they weren't designed for Linux and don't depend on any special Linux
behaviour.

Basically:
- anything that was written with Linux in mind (whether it then _also_
works on other operating systems or not) is clearly partially a derived
work.
- anything that has knowledge of and plays with fundamental internal
Linux behaviour is clearly a derived work. If you need to muck around
with core code, you're derived, no question about it.

Historically, there's been things like the original Andrew filesystem
module: a standard filesystem that really wasn't written for Linux in the
first place, and just implements a UNIX filesystem. Is that derived just
because it got ported to Linux that had a reasonably similar VFS interface
to what other UNIXes did? Personally, I didn't feel that I could make that
judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray
area.

Personally, I think that case wasn't a derived work, and I was willing to
tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work?
HELL NO! It has nothing to do with modules per se, except that non-modules
clearly are derived works (if they are so central to the kenrel that you
can't load them as a module, they are clearly derived works just by virtue
of being very intimate - and because the GPL expressly mentions linking).

So being a module is not a sign of not being a derived work. It's just
one sign that _maybe_ it might have other arguments for why it isn't
derived.

Linus</blockquote></i>

Full thread available here.

This is just a long line that I have to include because apparently my characters per line is too low, I would use the space to tell a crap joke but that would be a waste of time. God the line length is still too low, this is really dull. Am I there yet? Apparently not, I could really fall out with slashcode over this.

Jeremy Andrews from kerneltrap.org has just published an Interview with Ryan McBride, which makes for an excellent read on CARP and pfsync.

I'm not sure where you'd find it, but you might make some headway searching for "anticipatory scheduler" on kerneltrap.org. This scheduler was discussed multiple times on that site.

If you ever think about how inefficient it would be for the system to go read /bin/ls every time you typed the ls command you could see where caching is a damn good idea.

Doing read-ahead, write-behind and maintaining coherency isn't easy, from what little I understand.

Here's an older benchmark made by Andrew Morton showing the anticipatory scheduler vs the previous one.

The benchmark was made before 2.6.0, but I still think it shows the big difference from the 2.4 IO scheduler.

Quote:
Executive summary: the anticipatory scheduler is wiping the others off the map, and 2.4 is a disaster.

You're right preempt is turned off in Mandrake's stock kernels but it doesn't make a difference in this case since preempt only affects average case latencies not the worst case ones in a 2.6 kernel according to benchmarks.

I love the speed increases that the 2.6 kernel has achieved on the desktop (and for things like media: mplayer never bugs out with that charming "YOUR COMPUTER IS TOO SLOW" message anymore). However, I don't know if it can be considered even remotely stable. Since switching, my uptime has been a Windows like joke.

[...]

- Firewire and sbp2 support is completely broken. Ironically this has, I believe, more from "experimental" in 2.4 to a normal feature, yet it worked fine before and now doesn't work at all (the linux1394 forums forums reflect that I am not alone in this). Trying to copy data to sbp2 drives segfaults, hangs, and worse. Beware of connecting to 2.6 if you have a firewire drive with data you hold dear...

It's important to keep some perspective. Usually whenever anyone says something is full of bugs, they mean that they keep running into the same bug over and over. If you're having problems with Firewire, very likely you're running into one bug in your driver repeatedly. The other people complaining may have the same chipset and the same problem.

My point is that you can't make any generalizations to the entire kernel series (or even subsystem, like 1394) being more or less stable just because you encounter a single bug that you didn't used to. Look more closely at the oopses and your system logs, see where it's happening, file a good bug report. They'll probably have it fixed in a couple releases.

People use "stable" or "unstable" to mean a lot of different things:

1. If they're changing the APIs constantly or not.
2. If the core of the system doesn't crash and performs well under a variety of loads
3. If their system doesn't crash and performs well under their load

...and #3 really needs to be qualified with "for me" or "with this exact hardware, doing this". Because otherwise, you're saying the whole series sucks because of a single bug. And very likely, a bug in a driver. When I read kernel traffic, lwn, or kernel trap, I frequently see mention of fixing some unsafe coding practice...in the core kernel. Drivers are left for their maintainers to update. Some do so quickly and well. Some don't.

Ideally, a system would be so rock-solid that you would never run into even one stability or performance bug. But I don't think that's much more realistic for Linux 2.4 than it is for 2.6.

(This message is not just aimed at you. I see this a lot.)

Ah but what was being discussed on the list was that kernel preempt makes the kernel SLOWER. I believe it was Andrea Arcangeli that was saying it was slow.

Lessee.... link, link... ah, there: link

Firstly, pf IS available on NetBSD.

Also I don't really think there's that much of a performance difference between NetBSD and OpenBSD. Although the latest release of Open I've tried is 3.3, so unless it got a lot slower...

There's a drupal module that does that. Coded by kerneltrap webmaster.

I prefer to get Opterons over "Xeopterons", if for no other reason than because Intel blatantly ripped off the 64-bit extensions from AMD, and didn't even bother mentioning them in the "ia32e" specification documentation.

Granted, AMD is making designs based on Intel's ancient and decrepit architecture, but at least they acknowledge this and give Intel credit where credit is due. Many of AMD's AMD64 technology papers are published as the differences between Intel's IA32 papers and their design.

Of course, the fact that Opterons scale better due to not sharing all memory bandwidth between CPUs, using HyperTransport for interCPU communication, and having a dedicated and integrated low-latency memory controller for each individual CPU helps in the Opteron-vs-Xeopteron choice as well....

I have heard many people reference the fact that the although the Linux
Kernel is under the GNU GPL license, that the code is licensed with an
exception clause that says binary loadable modules do not have to be
under the GPL.

Nope. No such exception exists. ...

Basically:
- anything that was written with Linux in mind (whether it then _also_
works on other operating systems or not) is clearly partially a derived
work.
- anything that has knowledge of and plays with fundamental internal
Linux behaviour is clearly a derived work. If you need to muck around
with core code, you're derived, no question about it.

What about software which utilises Linux specific kernel services, such as
say some cd writing software?

An ordinary program that uses normal system calls?

linux/COPYING says: This copyright does *not* cover user programs
that use kernel services by normal system calls - this is merely
considered normal use of the kernel, and does *not* fall under
the heading of "derived work".

Yeah, and the GPL specificly invalidates that statement. We're on thin
ice here. Linus is making up the rules, which is cool (since I tend to
like his rules) but the reality is that the GPL doesn't allow you to
extend the GPL. It's the GPL or nothing. ...

But given that, neither Linus (nor any of you) get to say "well, that's fine
for userland but drivers are derived works".

I've said this over and over and I'll say it again. If you want the
protection of the law you have to live with the law's rules. You DO
NOT get to say "user programs are a boundary across which the GPL does
not apply but drivers are a boundary across which the GPL does apply".
It doesn't, and can't, work that way. Either userland is GPL and drivers
are GPL or neither are GPLed. Take your pick.

WTF why is this troll.

It sure looks like a troll. You toss around technical-sounding terms and make vague assertions. I've followed the kernel preemption patch as it appears in the news, and I don't remember ever seeing the words "preemption points" so I don't know what you are talking about. Linux kernel preemption allows preemption except when an SMP spinlock would have been invoked. What are these "preemption points"? Can you provide a URL to a page that explains them?

anyone familair with the way something like Solaris works knows how primitive the thread support in linux is.

If you don't want people to think you are a troll, don't say things like this without pointing to some kind of reference that backs this up. Since Linux kernel 2.6 just got the NPTL, threads are way better than they used to be. Are you claiming that Solaris is way better than NPTL on kernel 2.6? Or did you not know about NPTL? Or are you just trolling?

the new scheduler is quite controversial, i wouldnt be surprised if they return to the previous one later

References for this statement, please? All the articles I have been reading are very enthusiastic about the new scheduler, especially with the interactivity boost.

steveha

You're supposed to use /dev/input/mice now, while /dev/psaux is depricated. Point XFree to it in your /etc/X11/XFree86Config-4 file and you're done. See the Linux 2.6 Input Drivers FAQ for common inout problems with solutions.

I agree with your sentiment (saying 'Upgrade' is pretty normal) but your example is flawed. Marc-Christian Petersen just release version 2.2.26 of the Linux kernel. To quote his news post

I am very proud to announce this because it fixes several of security bugs including the last mremap() bug, the longer known hashing exploit possibility in the network stack and /dev/rtc leakage.

Ian

But, you are wrong about this. In fact, a new Kernel update to 2.2 was released. Version 2.2.26. It's been a year, but they were still released.

Here's a quote from the release: "Marc-Christian Petersen announced the release of the 2.2.26 Linux kernel. This release includes several security fixes, including a fix for the latest mremap() bug." See the Linux 2.2.26 Release Notes

So, really, MS is forcing users to upgrade by not releasing patches to old version.

Well, you are right in that you need to change some configs in XFree.
This FAQ is your friend. Mostly, changing the mouse protocol from auto to event should improve the mouse behaviour ;)

I am going to give you a couple of links and second a tip that another poster made. Since I use Gentoo and grub I don't want to tell you exactly how I do this and have it break your stuff ;)

link 1
link 2

You should be able to install many kernels side by side just by using the kernel-version and System.map-version naming scheme and I highly recommend you do that and add entries to your lilo.conf for each one you want to test. Then you shouldn't need to use your live cd to save your self.

as usual: YMMV

not to flame, but why is slashdot posting an article from feb 24, 2004 on how to upgrade to linux 2.6?

this article i have bookmarked tells you how to upgrade to 2.6 and its from august 29, 2003.

http://kerneltrap.org/node/view/799

Granted, it would be great to finally see Subversion nicely integrated with SourceForge, but CVS (the current concurrent versioning system used by SourceForge) while lacking lots of essential (at least for experienced developers) functionality, is free software nonetheless. What I am most concerned about is whether this new version of Subversion is already good enough to use with Linux, so one could contribute without the need to choose between restrictive EULA and being a second class citizen. Does anyone know what features exactly does it still lack, if any, for Linus to accept? I hope it would be legally possible to accept now, but I might be wrong. [emphasis added]

You've made two posts with the same apparent misconception. Subversion is not bitkeeper. Subversion is completely free. Its license is essentially MIT-ish. There's absolutely no concern by anyone that Subversion is restrictively licensed; especially when the current Linux SCS being compared to it is BitKeeper!

You seem to have completely misunderstood me. I might have been not clear enough. Of course Subversion is free software, there is absolutely no question about that and that is exactly why I would like to see it being used in Linux development which, after all, is free software itself. What I am concerned about is the very license of BitKeeper causing lots of controversy[1][2][3] with the clause preventing the development of competing products, like the very Subversion we are talking about.

X is a single-threaded client/server application which provides windowing services and network transparency.

Since the terms 'client' and 'server' tend to be redefined every year or two by the Xfree team, nobody else really knows which is which any more. X interfaces directly with video drivers and also with the window managers.
The problems are fairly numerous and unfortunately difficult to fix:
Single-threaded X is forced to share its timeslice with every client (?) program, which leads even people like Linus to complain about GUI latencies on 4-way systems with top of the line hardware. Not so cool. Kernel 2.6 contains some hacks to kludge around this problem, but the underlying issue still hasn't (yet) been addressed. Considering Xfree's Design by Committee creed, it never will be fixed. You might say that X is rotten by design. You might more accurately state that X is 1980 technology, and wasn't meant to do the things that modern users expect as a matter of course (eg. 3D low latency, non-stuttering graphics). There isn't an elegant solution aside from ditching X entirely.

From the other end, the Xfree API is a big mess of kludges. Extensions have proven an excellent tactic to obfuscate and uglify code.

KernelTrap reported "large merges" to 2.6.3-rc2, including:

network driver updates, compiler warning fixes, PPC updates, a major ALSA update and SCSI updates, NFSv4 update, XFS fixes, ARM and sparc updates

No need to do so, check this out: HowTo Upgrade To The 2.6 Kernel And you are not idiots, you just don't RTFM...

Please someone tell me why I have been moderated as troll(parent post). I am just curious. Has this problem been solve already? Am I worrying for nothing?

I don't understant it seems like a legitimate concern to me. I search in google and found the following things concerning this issue:

this

this

this

this

so it has been discused plenty but it is far from being resolved. Meanwhile the companies try to stretch more and more the meaning of the GPL.

I had to upgrade to RH9 to get support for the SATA controller in my SuperMicro 6013P-T server. Otherwise I would have used 7.3 (the last decent RH release). I'm now running 2.6 on my server and it works flawlessly (the kernel that is. RH9 sucks ass). You don't need Fedora or Rawhide to run 2.6 though. It's quite easy to get it running on RH9 and older. Just follow the instructions over at KernelTrap. I'm preparing to give Gentoo a whirl. I'm hoping I can scrap RH for Gentoo in the near future. Whoot!

Yes it was available in RH9. NPTL was developed by Ulrich Drepper of RedHat.

KernelTrap Announcement

Cheers
Stor

There is a 2.6 Input Drivers Faq . It covers some of the more common issues, including some KVM problems.

When will some OSS developers get a clue... ... and get together with an MBA, and write the killer app for OS.

Yes... Now where would we find an experienced devloper with an MBA? Hmmmm. :)

Interesting. That's not the reason for disabling HyperThreading that I've heard. I often hear people say it should be disabled unless you have a scheduler that supports HyperThreading well. There are lots of opportunities to go wrong when scheduling tasks on HT-enabled CPUs.

For example, if you have one real processor and are running a high-priority task and a low-priority task, the low-priority task will get 50% of the processor time with a non-HT aware scheduler, since it says "well, I've got this processor free, so I might as well use it" when that's not really true. This problem is discussed more here.

Similarly, if you've got several high-performance tasks and several real processors, you want to spread them out across as many real processors as possible to maximize parallelism.

ULE is becoming the default scheduler in -current.

Of course, things may have changed since then. I don't follow BSD all that closely, I just hang out on KernelTrap.

ULE is becoming the default scheduler in -current.

Of course, things may have changed since then. I don't follow BSD all that closely, I just hang out on KernelTrap.

That can be found here . Nothing really brand spanking new.

Actually, it wouldn't suprise me if this is correct. If you notice, he was reading the 500MB file while a continuous streaming write was going on in the background. On 2.4.x, a write streamout will kill read performance drastically. Mostly due to the way the I/O scheduler schedules the read. Which, most of the time, is to stash it at the end of the writes.

The two new I/O schedulers in 2.6.x help to resolve this. For more info, check here.

His example is a great way to remain a doctor and become a major figure in another field at the same time.

It has been integrated into the kernel and will be available in 2.6.2. Source (search for "forcedeth").

Ok, i've asked this before, and i could not get any responses. Is the new ULE scheduler prone to the same problems as Con Kolivas of the Linux Interactivity patches fame, claims?

According to this, Con Kolivas suggests that the ULE scheduler is prone to the same problems that the Linux O(1) scheduler faced initially. Can someone with a more detailed knowledge of the workings of the ULE scheduler throw some light on this?