Quote of the week [LWN.net]

Which part of "sysfs patches can be written by idiots and usually are" is too hard to understand? Oh, wait. I see... Well, nevermind, then...

-- Al Viro is back.

to post comments

Quote of the week

Posted Apr 7, 2006 18:17 UTC (Fri) by stock (guest, #5849) [Link] (6 responses)

Rest assured that this bug is only inside Linus' latest offering : linux-2.6.16. I would call it a typo. Other linux IT businesses would call it a frenzy. See also : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1055

Here's the diff for early bird patchees from the commitdiff page from the kernel.org git repository. In there we see that some drunken kernel master made a stupid typo. Instead of "count = PAGE_SIZE - 1;" its written "count = PAGE_SIZE;". Next the total linux media madness like vnu goes bonkers.

Now go check on your linux src 2.6.x trees whats inside fs/sysfs/file.c , and you will see that only inside 2.6.16 this typo by Linus can be found back. Manually patching is rather simple and straight forward here, but if your a obedient RedHat update(er) you will have to make some massive actions this weekend.

The debian crowd is sneering away : "Ohh we the mighty boys of debian run 2.4.x and are not affected by this!! The 2.6.xx crowd yet again has to spend an entire weekend updating."

I heard someone even claim: " i stick with the 2.0.38 kernel, its the only one I can be sure that contains no stolen SCO code"

This kernel.org git repository of the linux source code tree sure looks like a nifty tool to me. I would even call this GIT the "Apres mois la deluge" upload site ([tm]Kevin Mitnick), for companies like SUN, IBM, HP/Compaq... you name em. Then again, during the years 2000/2001 SCO was basicly doing the SAME thing.

The git source pool of Linux code is even what i would call the perfect "do not resist, we Borg will assimilate all your code" upload button. Because as was reported on lwn.net : any uploader of code must agree that the linux kernel masters WILL adjust the coding typing style of all your precious code !! In effect any genuine original code will NEVER EVER be found back or identified as such. Now compare that to the honest methods of SCO, replacing inside genuine UNIX header code, (c)1988 AT&T only with the copyright comments of the SCO group, leaving the rest of the code untouched!

Robert

Quote of the week

Posted Apr 7, 2006 18:50 UTC (Fri) by nix (subscriber, #2304) [Link] (4 responses)

That link didn't read like a sneer to me. I think you need to relax and cut way back on the coffee.

And anyone sticking with 2.0.38 is a maniac or has *really* peculiar requirements (avoiding `stolen code' that doesn't exist naturally counts as peculiar!)

And as for your last strange paragraph, well, per-person `code ownership' is loose in any multi-person free software project once something is contributed; you have to expect the other devs will hack at it too. This is a feature.

Quote of the week

Posted Apr 10, 2006 12:26 UTC (Mon) by arafel (subscriber, #18557) [Link] (1 responses)

I'm assuming the OP was trying to make a joke...

Quote of the week

Posted Apr 18, 2006 21:42 UTC (Tue) by nix (subscriber, #2304) [Link]

It's Robert Stockmann. I reserve judgement. ;)

2.0.38

Posted Apr 13, 2006 4:14 UTC (Thu) by pm101 (guest, #3011) [Link] (1 responses)

Agreed. Upgrade to 2.0.40 already. Sheesh.

(The kernel of choice for people with low-memory systems. Or who want to be able to go through the kernel configuration script by hand in a reasonable amount of time. Or who want their kernels to almost always compile once configured (assuming the right version of the toolchain). Or who want to avoid the bugs, crashes, and data corruption associated with running the no-longer-odd-numbered unstable devel series kernels of the 2.6 era. Although I agree; 2.2 or 2.4 is better for most applications).

2.0.38

Posted Apr 18, 2006 21:45 UTC (Tue) by nix (subscriber, #2304) [Link]

The stable kernels are 2.6.16.x, not 2.6.x. Think of it that way and all will be well. Since I started using it in 2.6.10 the 2.6 series has seemed really hot stuff to me: bitten by one nasty swap-killing UltraSPARC bug in 2.6.10, fixed by davem in hours... you can't pay for that sort of response time, and the only way to get it is to use a kernel at least somewhat similar to that used by the upstream developers.

(Major data-corruption events experienced here with 2.6: 0.
Major data-corruption events experienced here with 2.4: 1.
2.6 even kept running with RAM so faulty that md5sums of 10Mb files returned different values each time.

Does my anecdote defeat your anecdote?)

Quote of the week / 2.6.15.7 as well

Posted Apr 7, 2006 19:09 UTC (Fri) by didierj.richard (guest, #142) [Link]

Hello

Reading Robert's message I felt confident this afternoon's upgrade to 2.6.15.7 was the safe choice. Unfortunately I checked according to Robert's message and found 2.6.15.7 was affected as well :

# grep "PAGE_SIZE" /usr/src/linux-2.6.15.7/fs/sysfs/file.c
BUG_ON(count > (ssize_t)PAGE_SIZE);
if (count >= PAGE_SIZE)
count = PAGE_SIZE;
#

I am no C expert, but this sounds like the CVE statement : "2.6.12 and further"

Didier