Linux 2.2.18 Released

If you haven't heard yet, another version of the Linux kernel has hit the mirrors. This is the first release to the 2.2 tree in quite some time, so it's probably worth updating on those machines which can afford a reboot. There's a whole bunch of changes, most notably the backport of USB code from the 2.4 tree, so all those neat-o USB devices you get over the holiday season won't be gathering dust.

Comments

Re:backporting driver frameworks?

[GrenDel Fuego]

The difference is, USB was not backported by Linus or Alan. It was backported by someone who wanted to get their USB devices working properly without waiting for 2.4 to come out.

Who says they would have worked on other components of 2.4 if they hadn't been working on this? They were scratching their paritcular itch.

Re:Request...

[GrenDel Fuego]

I've never used linux on a mac before, but here's something to look for:

I believe Linux PPC is based on Redhat. Redhat likes leaving default config files in /usr/src/linux/configs. If that directory exists on your machine, copy one of the configs there into /usr/src/linux, and run a make oldconfig to just update the config options that have changed.

If that dosen't work, maybe someone else has an idea.

And the tie-in

[jaa]

to an early /. story -- 2.2.18 fixes the CPUID "bug" that causes problems for Linux on the Pentium IV.

Cute link.

[Covener]

'mirrors' points right to www.kernel.org!

Re:backporting driver frameworks?

[Snowfox]

But backporting is not easy! The time would be better spent getting 2.4 into better shape, making those who MUST live on the cutting edge be able to do so.

Alan Cox has pointed out that backporting is a wonderful tool for finding bugs and reviewing code. Makes a lot of sense, and if it means a more stable 2.4 in the long run, it's definitely a worthwhile investment.

Many of us would be happy if 2.4 was still another year away if it's better architected as a result.

Re:Linux Security

[Peter H.S.]

Well, first of all, this isn't a security kernel release.So no need to upgrade for that reason.

But speaking of security updates; there really isn't any difference between running Linux and MS-windows servers, regarding security updates. In both cases, the sysadmin has to subscribe to his vendors security lists, read them, and apply the patches.

It is very easy, to apply new patches to eg. a Red Hat Linux box: get the files as described in the security mail. Instructions are provided in the mail, but in most cases, one just do a 'rpm -Fvh [filename]' This will update the system, if the program is installed.
There is even a program, that automatically fetch and update all the needed rpms for you.(this may require some setting up).
And if you want really easy upgrades, then pay a minor amount, and get priority access,web instructions and a nice graphical userinterface, for automatic security upgrades (Red Hat Network). As an ordinary web-surfer, this would basically mean, that you can forget about following security lists.

Regarding the hacking as described in:
http://www.securityfocus.com/news/122
"It's a story of great incompetence," said the hacker, a 25-year-old Dutch man who calls himself "Kane." "All the data taken from these computers was taken over the Internet. All the machines were exposed without any firewalls of any kind."

This has less to do, with security upgrades, than sheer incompetent network designing, and administration. Really basic stuff, like NAT/Masquerading, firewalls etc, would likely have prevented that hack.

Eerie....

[Symbiosis]

just after the slashback with Two Kernel Monte comes the announcement for a new kernel threatening to obliterate uptimes around the world. :-)

2.2.18 procfs API

[1010011010]

is different than both 2.2.17 and 2.4.0. I tried to post a patch to fix it here, but amusingly, slashdot's lamness filter rejected it.

The two big things I like about 2.2.18 (I've been running the -pre kernels) is that they include a working, and version 3, NFS client, and the VM seems more stable. I used to get "VM: do_try_to_free_pages failed for" .. whatver/everything, especially kswapd, in 2.2.16 and 2.2.17. It seems to have gone away with 2.2.18.

________________________________________

Differences in the EMU10K1 drivers

[bconway]

Yes, the Creative open-source drivers for the SB Live!/512 are very different than the current ones included in the kernel sources, and use an extra ac97_codec module, in addition to the emu10k1 module. I've extensively tested both, and I'd say that both performance and quality _sound_ better. I've also found the ones included in the 2.2.18 kernel to be a bit buggy, in addition to being outdated. Starting and stopping a .wav file with the 2.2.18 drivers often causes a small burst of static, which is simply unacceptable.

A proposed project to help QA the linux kernel

[goingware]

Check out my proposal for making an easy to use Linux QA database at http://www.goingware.com/linuxquality/.

Want to help? Write crawford@goingware.com I know how to code in a variety of languages, but I don't know squat about designing a database schema.

I thought something like this would be helpful after I subscribed to the linux-kernel mailing list for a while to report a bug in 2.4.0 and work with the kernel developers to get it fixed. The bug got fixed, but I sure got a lot of mail and it was a little hard getting the fix nailed down.

Michael D. Crawford
GoingWare Inc

Linux Security

[Cofactor]

This is good news..

I was wondering about the disadvantages of open source systems.
The problem is in security bugs (as in Red Hat) with people who are not IT professionals. One incident is the one at University of Washington Medical Center where a hacker gained access to thousands of medical records and confidential patient data. The start was with a Linux server in the Pathology Department:
http://www.securityfocus.com/news/122

The frequent updates are great, but I am thinking that some updates are starting to resemble those of Internet Explorer; in the IE case, less than 5% of users have the time or awareness to update their browsers and operating system. In Linux, a minority will face this problem, but it seems that it is the same issue.

I know that this is a bit different than the above topic, but I think that this problem will be more apparent with time.

Re:Linux Security

[Malor]

Security through obscurity is really only a temporary stopgap. It slows down an attacker but it doesn't prevent him/her/it from eventually finding and attacking holes. Worse, most of the proprietary vendors have been quite slow about releasing patches.

I don't have any way of knowing how long it will take, but you are seeing the bugs getting shaken out of the operating systems we depend on. They're very complex creations and there are probably whole classes yet of undiscovered security exploits.

Open source allows people to more effectively find and attack holes. This means that they are both found and fixed faster. It is my belief that eventually, the open source operating systems will come pretty close to being free of security holes. It's unlikely to ever be 100%, but the number of remaining, unfound security flaws should slowly approach 0 without ever quite touching it.

The closed-source operating systems, Microsoft's in particular, are a long way further up that curve. I'm guessing that you're going to be seeing nasty system holes in those operating systems for years and years after they have slowed to a mere trickle on the Unices. You just can't assemble forty million lines of code and put it into production without there being problems. Linux has 1/10th the code size, and because of that probably 1/1000th of the potential security-breaking unforeseen interactions.

The so-far-unstated assumption I have is that systems will eventually get extremely secure. This could be wrong. If new bugs get added as fast as, or faster than, old ones get taken away, then the high number of found bugs in Open Source software will prove to be only a detriment.

I'm *assuming* that we are paying now to have security later. But if we aren't, then the security through obscurity model is probably RIGHT -- because if there will ALWAYS be new security holes, any method of slowing down detection of those holes makes sysadmins' lives a little easier.

We will probably know which of these two models is right within the next 3 or 4 years. In the interim, fight very hard any suggestion to suppress information about hacks/exploits or cracking tools. The ultimate goal is secure systems, and it will take some time for us to find out which way is more secure in actual practice. If one method is hamstrung by legal action, then we may never know the right approach and may forever suffer with buggier software than we needed to.

By the 2004-2005 timeframe, the overall progression in the number of bugs reported on Open Source versus proprietary systems should be much clearer, and we will likely make much more intelligent decisions.

Re:Linux Security

[Platinum Dragon]

I was wondering about the disadvantages of open source systems.
The problem is in security bugs (as in Red Hat) with people who are not IT professionals.

News flash: this is a general issue with most (all?) operating systems, not just open source ones. It's not a disadvantage of open source alone, but a general difficulty all admins and end users deal with on a daily basis. The difference is, the sysadmin is expected to keep the doors closed and locked. That's part of his/her job description. An end user just wants to check e-mail, browse the web, maybe play a game or write a letter, in which event, they won't religiously follow security mailing lists.

Helix Code, Red Hat, and MS are probably doing end users a favour with automatic update systems, although I'm sure everyone here can rattle off three potential attacks and security holes involving these autoupdaters without thinking (man-in-the-middle attacks, spoofed routing entries, spoofed DNS entries, leading to trojaned packages being downloaded and installed without the user's input).

In the end, it's just an eternal conflict between the developers of new software and the developers of ways to poke holes in new software. That's life.

For ReiserFS users...

[Wakko Warner]

There's a patch which (purportedly) works against 2.2.18 here. You'll also need the latest full ReiserFS patch. Patch as usual, ignore the failures, and then patch again with this patch.

- A.P.

--
* CmdrTaco is an idiot.

NFS v3 support is quite notable

[DenialS]

Let me just say that the NFS (network file system) support in 2.2.18 is vastly improved over the previous kernels. Alan rolled in the patches that most distros had been adding to the 2.2 kernel, fixed their bugs, and made me a very happy man. NFS v3 support is there for the taking, folks... enjoy.

Re:Arch-based Downloads

[Spoing]

Don't download everything, only download the bzip2 patch. Most 2.2.x relase patches are about a meg, and I've never had a problem getting one even after a big announcement.`

Here's a mangled section from a kernel maker script to give you an idea how simple using patches can be;

cd /usr/src
tar Ixfv /usr/src/usr/src/linux-2.2.14.tar.bz2
cd /usr/src/linux
patch -p1 < /usr/src/kernel/patch-2.2.15
patch -p1 < /usr/src/kernel/patch-2.2.16
patch -p1 < /usr/src/kernel/patch-2.2.17
patch -p1 < /usr/src/kernel/patch-2.2.18

If you want to make this a little fancier, you can put in a loop that only decompresses the patches just before being applied and does not need hard coding like the above. Symlinks and other parts are also missing from the example above...and are not needed to get the job done.

For that matter, you can tar the whole patched release up once in a while when you get annoyed with all those extra patch files hanging around.

Re:backporting driver frameworks?

[bonzoesc]

The reason the 2.4 usb support is being backported is because users want it *now*. Our silly win9x-bound relatives send us USB stuff to use, and we can't because it doesn't work in Linux. So, USB support is a high-demand backport. Backporting stuff that isn't high-demand is silly, because nobody will appreciate it. The Linux kernel folks (Linux included) have to obey politics, too, even if it is among a group of presumably understanding Linux hackers. (Hackers meaning intelligent users, not h4x0rz.)

Tell me what makes you so afraid
Of all those people you say you hate

Re:A rant, I know, but I can't help it.

[Frymaster]

I wish Linus would pull his socks up

The man wrote (most of) an operating system. If his socks were any higher, he'd be wearing pantyhose.

Who do Linus and Cox answer to?

Themselves. I think you're forgetting that this is a free operating system. In the "Real World" we answer to whoever's writing the paycheque. It's mildly nauseating to see people download their free iso and then complain about release dates.

I'd like to see some sort of body set up that has soveriegnty over Linus and Cox,

Okay, these people, who are working for free, aren't meeting you're timeline. You're solution is not to write a cheque or organize some other funding effort to encourage the development process or to pitch in yourself, but rather to demand some sort of "linux police force".

If you want to complain about customer service, I suggest you call your Sun sales representative

ReiserFS/ EMU10K1 patches

[bconway]

Keep in mind before upgrading that if you're running ReiserFS (as you should be =) ), the latest 2.2.17 won't patch correctly, be it 2.2.18 + patch or 2.2.17 + patch + 2.2.18 patch. These should be out imminently, however, so keep an eye on their web site. Also, be sure to check out opensource.creative.com for the latest EMU10K1, as the drivers are far more recent than the ones included in 2.2.18, and a great bit better, I've found. This is definitely worth the upgrade, for no other reason than the USB backporting, as well as the AGPgart and DRI drivers.