Rik van Riel on Kernels, VMs, and Linux

F FKIN P! by Anonymous Coward · 2002-01-15 03:25 · Score: -1, Offtopic

WOOOOHOOOOOOO

Yet again by ringbarer · 2002-01-15 03:25 · Score: -1

Get an account. It's easy.

--
"Why did they cancel my favorite Sci-Fi show? I downloaded ALL the episodes!"

Re:Yet again by Anonymous Coward · 2002-01-15 03:31 · Score: -1, Offtopic

I have lost 23 karma in the last two weeks giving people shit, and I want people to have to put up with my shot, so posting as AC for now :)

ohhh by Quasar1999 · 2002-01-15 03:26 · Score: 0, Flamebait

Come on, you all know that any talk about the Linux VM is going to go over the heads of 95% of slashdot readers... :P

--

---
Programming is like sex... Make one mistake and support it the rest of your life.

Re:ohhh by yatest5 · 2002-01-15 03:28 · Score: -1, Offtopic

With some controversy towards Linus Torvalds.

FLAMEWAR!!!!!
--
- Mod parent up! [a] by Anonymous Coward (Score:5) Thurs, June 31, @13:37

We all know what it means... by ringbarer · 2002-01-15 03:27 · Score: -1

VM = Virgin Masturbators. The only people that use Linux.

--
"Why did they cancel my favorite Sci-Fi show? I downloaded ALL the episodes!"

Minor nit... by FauxPasIII · 2002-01-15 03:30 · Score: 3, Informative

>> (which was recently adopted in Alan Cox's tree).

As I understand it, the Rik VM is what we started the 2.4 series with.
The Andrea VM was adopted in 2.4.10 amidst much controvery, and Alan has kept
the Rik VM as a part in the -ac kernels.

--
25% Funny, 25% Insightful, 25% Informative, 25% Troll

Re:Minor nit... by FauxPasIII · 2002-01-15 03:34 · Score: 2, Informative

Hate to follow up to myself, but I went and reread some old stuff; look like Alan has actually move -from- the Rik VM now, and is using the same Andrea VM that's in the linus kernel.

--
25% Funny, 25% Insightful, 25% Informative, 25% Troll
Re:Minor nit... by Rik+van+Riel · 2002-01-15 03:41 · Score: 5, Informative

Both Alan's and Michael's kernels are including my -rmap VM now.
This is quite interesting since I haven't begun tuning -rmap for speed yet ;)
Re:Minor nit... by FauxPasIII · 2002-01-15 03:48 · Score: 3, Redundant

Hrm... how impossible/practical would it be to have
multiple VMs in the same source tree and select one at
menuconfig time ? It would probably add up to a lot
more testing done on all the non-linus-kernel VMs, but
I have a hunch that the VM is probably something that's
a pretty pervasive patch; could it be localized down to just
an option in menuconfig ?

--
25% Funny, 25% Insightful, 25% Informative, 25% Troll
Re:Minor nit... by ringbarer · 2002-01-15 03:51 · Score: -1

This is quite interesting since I haven't begun tuning -rmap for speed yet ;)

Yet more half finished shit masquerading as enterprise-ready software...

--
"Why did they cancel my favorite Sci-Fi show? I downloaded ALL the episodes!"
Re:Minor nit... by trollercoaster · 2002-01-15 04:00 · Score: -1

I wonder when they are going to start "tuning" this crap for usability?

--
Slashdot, come for the goatse, stay for the trolls.
Re:Minor nit... by Anonymous Coward · 2002-01-15 04:05 · Score: 0

VERY difficult. Linus doesn't believe in well defined interfaces inside the kernel, so chaning the vm touches *everything*. This is very very dumb.
Re:Minor nit... by ringbarer · 2002-01-15 04:18 · Score: -1

That'll be when they start giving a damn about the users... Never.

Linux exists to please only one type of computer user - the programmer. By definition, Open Source excludes the efforts of the people that have real jobs and need to get work done WITH computers.

Linux is like a car that has the engine on the outside. Sure, you can maintain it with ease, but if you don't know what you're doing, or fail to read the obscenity-laden manual, you can endanger yourself and your fellow drivers.

This car would only appeal to car mechanics, and of course, is an ugly piece of shit.

Just like Linux. An embarressment to have on the desktop. If it wasn't, how come the only Themes you can get for the Windows rip-offs they call Desktop Managers are blatant copies of Apple and Microsoft designs.

Apple and Microsoft care about their users. That's why they pump MILLIONS into user group testing, and have published tomes on Human-Computer-Interface concepts.

These are blatantly stolen by Open Source thieves, and due to the immaturity of Linux programmers, are invariably implemented incorrectly.

--
"Why did they cancel my favorite Sci-Fi show? I downloaded ALL the episodes!"
Re:Minor nit... by Pussy+Is+Money · 2002-01-15 05:20 · Score: 0

What's the use? We would just end up with 2 different VM's and 3 subvariants of each, none of them actually working.

--
Pushin' 'n dealin', shovin' 'n stealin'
Re:Minor nit... by Mr.+Piccolo · 2002-01-15 10:22 · Score: 1

Don't like it? Write your own damn OS!

Worked for Linus...

--
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei

Wondering... by prisoner-of-enigma · 2002-01-15 03:32 · Score: 5, Interesting

I'm wondering why both VM's can't be included in a distro and allowing the end user to select the one he/she wishes to compile into the kernel? Are the two implementations THAT mutually exclusive?

BTW, this kind of bashing between the high priests of Linux is not good. You can bet your bottom dollar that MS is going to use this conflict to fuel their propaganda machine, saying Linux is a fractious OS run by a bunch of young upstarts who can't agree on anything.

--
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky

Re:Wondering... by Anonymous Coward · 2002-01-15 03:35 · Score: 0

this kind of bashing between the high priests of Linux

High priests? They're just these guys, ya know?
Re:Wondering... by prisoner-of-enigma · 2002-01-15 03:36 · Score: 1

It's called "figuratively speaking", just in case you didn't know.

--
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
Re:Wondering... by reaper20 · 2002-01-15 03:43 · Score: 5, Insightful

I think this kind of infighting is great, as long as it doesn't get out of control.

We get to see arguments and competing subsections of the kernel - this is SO one of the most underrated benefits of open source. Users of some other OS's don't have this benefit. I am not a programmer, so to me, I don't really understand/care the benefits of different VM systems, but I know that some other, smarter people do, and they're all trying to figure out the best way to do it, and that's good enough for me.

I say let them go at it, let the best code win - it can only help us. And who cares how MS construes this, I'd like to see them open up their development model and see what kind of conflicts they are having.

OT - but kerneltrap.org has a good interview with Alan Cox today....
Re:Wondering... by kaisyain · 2002-01-15 03:44 · Score: 5, Insightful

this kind of bashing between the high priests of Linux is not good

Sure it is. How else are we going to find out where our disagreements are and work through them? Or, at the very least, learn not to make the same mistakes in future projects. The problem of the Linus bottleneck has been known for a long time. This "bashing" is not new, it's just current.

Having Linus Torvalds around helps insure that, for the average user, there is no splintering of development effort -- just use the Linus kernel. But it also severely hinders improvement because you are limited to what Linus likes or dislikes.

And despite what may be the common conception on /. Linus is not an all knowing genius. He makes mistakes. Perhaps this is one of those mistakes. The real question is whether the benefits of the stewardship he provides compensates for the hindrances his authoritarianism creates.
Re:Wondering... by Anonymous Coward · 2002-01-15 03:52 · Score: 0

It's just that while they're smart guys, there's nothing particularly special about them (except linus perhaps, but it's the initiative not the intellegence). If you studied and learned the theory, you too could be a kernel hacker. It's not really any different then other kinds of programming. The people who are big names in the linux kernel 'circle' are either people who got in early, or people who play the political game well. There are way more then a handful of people out there that can write at least as good a VM system as Rik, but either they don't want to deal with the politics of getting their code used, or they don't have a big enough mouth... And the same goes for other kernel subsystems as well.

I think people like Rik are a detriment to the progress of the Linux kernel.
Re:Wondering... by Anonymous Coward · 2002-01-15 03:54 · Score: 0

> saying Linux is a fractious OS run by a bunch
> of young upstarts who can't agree on anything.

Kinda like Windows was back in the day when they were trying to figure out whether to embed the browser in the OS...
Re:Wondering... by Fly · 2002-01-15 03:54 · Score: 2, Insightful

As I hear it, there's plenty of fighting over ideas and direction within Microsoft as well. The open software environment just allows the discussions to be public. Microsoft can try to use this as "fuel for their propaganda machine," but I doubt they'd get very far.
Rarely does one person have a monopoly on good ideas, so it's inevitable that finding the right solution will come from competition between more than one good idea. So long as progress continues, as it has, this is healthy. Both Mr. Torvalds and Mr. van Riel recognize that they are "stubborn," and both seem to deal with the heat fairly well.

--
end of line
Re:Wondering... by neal+n+bob · 2002-01-15 03:55 · Score: -1

he compares them to priests because just like catholic priests a large number of them like to touch little boys.
Re:Wondering... by garcia · 2002-01-15 03:57 · Score: 1, Flamebait

yup but at least we don't have a single moron running the show telling everyone else what to do. This way at least there is some internal competition. I suppose in the short-term dictatorship works the best but in the long run free ideas work best (Hitler/Stalin rapid Industrialization vs. Free World)

I don't particularly like the comments made by this kid but I don't think he is entirely wrong for doing so.
Re:Wondering... by prisoner-of-enigma · 2002-01-15 03:59 · Score: 1

I was referring to the extremely public and somewhat "pointed" nature of how the debate is being carried on as being detrimental to the Linux effort.

I'm all for debate, and public discussion, but some of the comments I've seen flying around sound more like teenage namecalling than professional developers with a disagreement. Linux isn't infallible, neither is Alan or Rik.

It sounds like these two VM's are aimed at two different problems, each addressing their own problem to the detriment of the other. I'm going to go back to my original statement of "let the user choose". Maybe I want the extra speed in a uniprocessor enviroment. Maybe I need the extra scalability in a large muliprocessor environment. I should be able to choose based upon my needs, not upon what Alan, Linus, or Rik thinks is best. After all, choice is what Linux is all about.

--
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
Re:Wondering... by gwillden · 2002-01-15 04:04 · Score: 2

Apparently the two implementations are or at least were that mutually exclusive.
I don't have the link (sorry) but there was talk on the kernel mailing list that it would be a big ball of spaghetti to include them both.
So Linus made his choice.

I disagree about the arguing. It would be nice if they were a little more civil about it. But hey, these guys are some of the best in the world at what they do. You know they've all got egos too. And those egos will sometimes cause people to work extra hard to prove the other wrong. That is good for the user. And the fact that a lot of great work happens at a fast pace in spite of the arguing and ego plays is a tribute to the Open Source development strategy.

--
-- Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re:Wondering... by Mel · 2002-01-15 04:06 · Score: 0

> I'm wondering why both VM's can't be included
> in a distro

This was discussed around about the time the new Page Replacement algorithm (Most of the VM remained the same) was introduced and thrown out the window rapidly. It would be a logical nightmare to have two VM's or even two versions of one subsection in there. You're not talking about two versions of a driver here or a subsystem easily switched out like the scheduler. The whole VM is a major piece of work and many of the arguements that have been flying around are only on one section of it, page replacement. Having two VM's in as a config item would turn the whole VM into a bloated mess of #defines and it's tricky enough to understand as it is. Worse, there are very few users that would know the difference between one page replacement policy and the next. Bad config decisions would make the system behave so badly that a propaganda machine wouldn't be needed to turn Linux into a laughing stock

> BTW, this kind of bashing between the high
> priests of Linux is not good

At the risk of been flame bait, thats utter balls. l-k is a list where the development of thekernel is discussed, not the super-friends club. Linus isn't God and neither is Rik, Alan, Marcelo or any of the names that are thrown around here like confetti. Around about the whole 2.4.10 mess, Rik had a serious point, his patches were been added inconsistently and to not argue this point because "the high priests" thought different would be sheer folly.
Re:Wondering... by Kefaa · 2002-01-15 04:17 · Score: 2

I'm wondering why both VM's can't be included in a distro and allowing the end user to select the one he/she wishes to compile into the kernel? Are the two implementations THAT mutually exclusive?

The issue appears to fall into the simplicity of installation. Yes, we could have both sent, but one will need to be the default or we make all users recompile the kernel. That would really sound bad from a PR perspective.

BTW, this kind of bashing between the high priests of Linux is not good. You can bet your bottom dollar that MS is going to use this conflict to fuel their propaganda machine, saying Linux is a fractious OS run by a bunch of young upstarts who can't agree on anything.

This issue has to do with the public nature of open source. I am certain MS has people on the mailing lists (as does every competitor), so the message would get out. With billions to spend on advertising, even an non-issue can be made one.

I hope people are able to understand that disagreement, consensus and resolution are part of what keeps OSS healthy. We do not have a single point of failure in leadership and that is a very good thing. If we all blindly followed Linus, we would sound like zealots and the competition would focus on that.
Re:Wondering... by Nelson · 2002-01-15 04:20 · Score: 4, Insightful

I'm wondering why both VM's can't be included in a distro and allowing the end user to select the one he/she wishes to compile into the kernel? Are the two implementations THAT mutually exclusive?

I've been wondering that myself. It's just work to do but it shouldn't be rocket science. Of course a number of people are concerned about the code size as is, you can't just add a new branch of code every time there is a conflict and pack them all together. This does seem like a somewhat good case for it.

BTW, this kind of bashing between the high priests of Linux is not good. You can bet your bottom dollar that MS is going to use this conflict to fuel their propaganda machine, saying Linux is a fractious OS run by a bunch of young upstarts who can't agree on anything.

No this is a good thing. Most of the linux kernel hackers have egos the size of small countries, and that's a good thing because they take pride in their work. Most of them also work as professionally and egolessly as I have ever seen. They can get in fights and then deal with it and keep working. This is far better than the closed world where people get in fights and take it personally and then try to react in some way. I've seen project where people were trying to fail the project to get revenge on someone on the team or managment for something stupid they did in the past. In the linux world people get in fights and everyone can see and they react accordingly, sometimes being told that you're being an ass is a good thing when you're being an ass, sometimes having people stop talking to you for a few days is a good thing, and sometime people appologize and that's a good thing. It's not behind closed doors though and it's hard to undermine things when it's all in the open. There is also some insanely good discussion on certain things some times. There is also something to be said for defending ideas and the strength they have when you can defend them in public.
Re:Wondering... by marco_craveiro · 2002-01-15 04:21 · Score: 1

I'm all for debate, and public discussion, but some of the comments I've seen flying around sound more like teenage namecalling than professional developers with a disagreement. Linux isn't infallible, neither is Alan

yeah, but sometimes it seems rik is probably more of a teenager than linus... for example, not so long ago a thread started *again* regarding linus's theory of "linux evolution vs design" and guess what: rik still seemed like he did not understand the macro vs micro views of the linux environment.

rik must be an excellent coder (hell, he's doing a vm...) but - and i do beg your pardon here rik - sometimes he's kinda slow. having said that, if linus was randomly dropping patches like he admits he does all the time one must understand riks frustration.

at any rate, i think it is better to have all of these discussions out here in the open instead of having them behind close doors. how many times does a manager get away with behaviour that is much worse than linus's patch dropping and no one gets to know about it? and how many times did this cause the end of a good product?
Re:Wondering... by Anonymous Coward · 2002-01-15 04:30 · Score: 1, Interesting

>Rik had a serious point, his patches were been added inconsistently and to not argue this point because "the high priests" thought different would be sheer folly.

True, his patches were being ignored. However, there is a good reason for that. At that time, the VM was failing in wierd ways and there were several people pumping out heaps of patches to try and fix the problems. However, none of the patches seemed to do more than paper over the problem.

Look up "shotgun debugging" in the jargon file. That is an extremely good description of what was happening.

Imho Linus did the right thing and cut the craziness off at the bud. At least now the problems with the VM are known, and are fixable.
Re:Wondering... by gmack · 2002-01-15 04:32 · Score: 1

You do have the abillity to chose, just apply the patch with the vm you want.

The abillity to have both in the kernel sa a compile option would result in a huge unmaintainable mess.

Check any of the kernel archives for more details.
Re:Wondering... by _johnnyc · 2002-01-15 04:48 · Score: 1

Wholeheartedly agree. Dissent is healthy and usually a sign of a dynamic social, cultural and intellectual environment. Lack of dissent anywhere is usually a sign of stagnation.

The interview is a good sign that Linux will continue to evolve, that OSS gives users an opportunity to participate and reflect on the development of their OS. This is better than some debate going on behind closed doors that no one will ever know about.

Great interview.
Re:Wondering... by sboss · 2002-01-15 04:48 · Score: 2, Interesting

Arguing and debating over the VM or other technical issues is good. But when the parties begin bashing each other (not the technical issues but the people) then we have problems. I do consulting on very large projects with many different players (aka companies) involved. Whenever the discussions/debates/arguements move from issues/technical problems into people/companies that is when the whole process breaks down. I am glad that we (as a community) have the ability to debate/discuss the technical issues. I love that. It works great. But lets do not loose the prespective of what we are here to do (write good software that beats the commerical stuff) and start trashing each other.

Just my point of view.

--
Scott
janitor
sdn website family
email: scott at sboss dot net
Re:Wondering... by kaisyain · 2002-01-15 04:59 · Score: 2, Interesting

When Linus is the source control system then personal issues become technical issues.
Re:Wondering... by Courageous · 2002-01-15 05:19 · Score: 2

Yes, we could have both sent, but one will need to be the default or we make all users recompile the kernel. That would really sound bad from a PR perspective.

Eh? I fail to see why you couldn't have two different precompiled kernels.

C//
Re:Wondering... by Pussy+Is+Money · 2002-01-15 05:23 · Score: 0

We don't need two different VM's. What is the use? Do you also want your car to have two steering wheels and three gas pedals?

--
Pushin' 'n dealin', shovin' 'n stealin'
Re:Wondering... by Enahs · 2002-01-15 05:46 · Score: 2

BTW, this kind of bashing between the high priests of Linux is not good.

OTOH, It's had positive results. On one side, we have a VM that's being optimized for server use. On the other, a VM that's more optimized for desktop performance.

I'd rather have two VMs than some big, complex piece of code that tries to allow the user to tune the kernel while running...nothing like making a more complex piece of software. As far as I'm concerned, more code complexity == more chances for bugs. ;-)

--
Stating on Slashdot that I like cheese since 1997.
Re:Wondering... by _ECC_ · 2002-01-15 05:47 · Score: 1

In answer to your question about compile-time options for the vm's...
http://kt.zork.net/kernel-traffic/kt20011029_139.h tml#3

http://kt.zork.net/kernel-traffic/kt20011105_140.h tml#3

-- ecc
Re:Wondering... by SpaceLifeForm · 2002-01-15 07:01 · Score: 1

I think people like Rik are a detriment to the progress of the Linux kernel.
Stirring up the pot is A Good Thing.
I've seen way too many occurances of 'we can't change that', even though the software design (while it works) is flawed enough that it prevents you from doing other things. In many software development environments, you can't even prove that the changes are worthwhile. At least with Linux, if you have the time and smarts, you can.
Keep up the good work Rik!

--
You are being MICROattacked, from various angles, in a SOFT manner.
Re:Wondering... by cyberkreiger · 2002-01-15 08:07 · Score: 1

A link to shotgun debugging would be nice.

--
Stumbling in the dark
I hear slavering of jaws
Eaten by a grue.
Re:Wondering... by Nailer · 2002-01-15 10:29 · Score: 2

Most of the linux kernel hackers have egos the size of small countries

small countries? Guess you haven't met Rusty yet...
Re:Wondering... by AndroSyn · 2002-01-15 11:32 · Score: 1

Why does it matter if Microsoft has fuel for their propaganda machine. Its an operating system, not the freaking cold war. I'm sick of crap like that. Its not a war, and most of the real developers don't see it as such. And if it is a war, perhaps one of the best ways to win it, is to ignore the fact that the enemy exists.
Re:Wondering... by rusty · 2002-01-15 11:50 · Score: 2, Funny

Heh...

HEY! Wait a minute!

I *knew* I'd never live down that linux.conf.au talk 8(
Re:Wondering... by Manaz · 2002-01-15 12:22 · Score: 2

That's all well and good, assuming that these people don't let their egos get in the way of their good judgement.

And let's be honest - while they may be coding gods, and extremely intelligent, they are only human. And humans don't like being wrong.

There is also the fact that in wanting to argue to support their own code, these *very* intelligent people may become blind to their own faults, or the faults of their work.

Infighting isn't necessarily good. It's certainly not good when it gets personal. Active discussion and intelligent, coherent arguments are fine, infighting which includes calling each other names, rather than focusing on the problems/issues at hand, is not.

Also, when you look at non-open OS development, you have to remember that just because we, as users, don't see arguments/discussions about the best/easiest/most effective way to do something doesn't mean that those arguments/discussions don't occur. Or that non-open OS developers aren't also intelligent people who are also trying to find the best way to tackle a problem/issue...
Re:Wondering... by Cef · 2002-01-15 22:54 · Score: 2

It was the graph that did it!

Lies, damn lies, and statistics.

Multi-proc 'big iron'.. by MattRog · 2002-01-15 03:32 · Score: 4, Insightful

I believe that the trend is to optimize Linux for the very powerful machines (multiprocessor and with a lot of RAM). Do you agree with me?

No, not at all. The embedded Linux market seems to be much more active than development of Linux on high end servers. On the other hand, the high end server improvements tend to touch more code in the core kernel while a lot of the embedded systems people just keep separate patches and have no plans of merging their code with Linus.

I'm not so sure I agree with him -- if you want to make a dent in the market shares of Solaris and NT/2000/XP you have to keep up with their innovations (Async-I/O, better SMP, etc.). As a user of Linux as our OS of choice for our database and web servers I am feeling a lot of pressure to switch to Solaris because of their better handling of higher-load environments (OLTP databases, web servers, etc.). If Solaris wasn't so damn expensive we'd probably be using SunFire 280's. So I'm pleading to keep up with the big dogs so that I can be reassured that Linux has what it takes (it's handling things fine now but as he said in the article, everyone needs more RAM, CPU, etc.).

--

Thanks,
--
Matt

Re:Multi-proc 'big iron'.. by Rik+van+Riel · 2002-01-15 03:54 · Score: 5, Informative

Indeed, it is important to optimise the VM to work right on such large machines. I guess what I wanted to say is that the VM isn't just optimised for high-end machines, but also for machines on the low end.
To be honest though, optimising for machines of different sizes really is a no-brainer compared to having to make the VM work with really diverse workloads ;)
Re:Multi-proc 'big iron'.. by smcdow · 2002-01-15 04:21 · Score: 1

To each his own.
All we do here is embeded systems. I'm feeling a lot of pressure to stay the course and stick with VxWorks, rather than make the switch to Linux (this, despite the fact that WRS gets you coming and going with maintenance contracts and run-time royalties).
Continued efforts to optimize Linux for the server space isn't going to help my cause very much.

--
In the course of every project, it will become necessary to shoot the scientists and begin production.
Re:Multi-proc 'big iron'.. by MattRog · 2002-01-15 04:46 · Score: 2

I appreciate your reply, Rik. Would it make more sense then to perhaps have a 'database' oriented VM (or kernel), a 'web server', 'embedded device' etc system? Granted such levels of specialization aren't always that clear cut but I know of many a situation in which each machine has a well-defined primary (obviously your web box can also be your POP3) roll. I know I try to keep the web boxes separate from the DB machines (since they are two wildly different methods of spitting out data to the user) and so on and so forth.

--

Thanks,
--
Matt
Re:Multi-proc 'big iron'.. by sparkz · 2002-01-15 04:52 · Score: 1

As I'm sure you're aware, Solaris is free; it's the servers which are expensive. The 280's nice, look at the V880 too, and the 3800-6800 range.

--
Author, Shell Scripting : Expert Re
Re:Multi-proc 'big iron'.. by Big+Jason · 2002-01-15 10:58 · Score: 1

Last I checked, Solaris was free to use on systems up to 8 processors. You can download the ISOs straight from Sun, today if you like.

The argument that low-end Sun hardware is not competitive with Wintel hardware is B.S. now that the V880 is available. 8 CPU, 32GB RAM, 12 FC-AL disks for $130k without a discount.

Go back under you bridge, troll.
Re:Multi-proc 'big iron'.. by MattRog · 2002-01-15 13:17 · Score: 1

I mis-spoke -- I was referring to the hardware (and it is really expensive for a 2CPU system 280). How am I a troll?

--

Thanks,
--
Matt
Re:Multi-proc 'big iron'.. by Big+Jason · 2002-01-15 18:22 · Score: 1

Expense is relative. Look at the TCO for a Sun box and a Wintel, I bet you come out ahead with Sun. Yes, Sun does carry a price tag, but you pay for quality.
Re:Multi-proc 'big iron'.. by Anonymous Coward · 2002-01-17 01:00 · Score: 0

Oh no, sun kit is far more than expensive, it is extortionate. Ive seen £80,000s worth of sun kit get beaten into the ground by £500s worth of x86 kit.

The disk-array was slow, the processors just didn't want to crunch the way they should, and subsequently the database performance was shoddy. The clustering wasn't even automatic failover, it had to be done manually.

If I sound bitter it is because the extra £79,500 could have kept my job going for a couple of years longer. And just like every other peice of kit, those machines will be outdated in 5 years.

So, who sells a £200 seagate disk for £800, sun does... who sells £20 of memory for £500, sun does...

Im happy for linux not to scale so well onto multiprocessor machines with huge amounts of memory, because the performance on so-called low powered machines can be better than some of these expensive peices of multiprocessored junk. Clustering is a bigger concern (and often a better solution.) The day I can use 4 machines as one linux install as easily as we currently use 1 machine is the day I rejoice.

Regards

I Smell a Fork by TRoLLaXoR · 2002-01-15 03:34 · Score: 1, Interesting

This talk of "Alan's tree" and "Linus's tree" is kind of foreboding. A de facto fork has already taken place.

What would Alan call his version of kernel? His last name already ends with an "X" so... I dunno where that would leave us.

Yeah, better off to just keep referring to them as "Alan's tree" and "Linus's tree."

Re:I Smell a Fork by Tasty+Beef+Jerky · 2002-01-15 03:48 · Score: -1, Troll

He'd call it Coccyx.

Get it, funny! Hahaha!

--
I'm the tasty treat nobody can resist!
IM Me! AOL IM:Tasty Beef Jerky
Re:I Smell a Fork by neal+n+bob · 2002-01-15 03:58 · Score: -1

are you suggesting they call it Al-cox. All Cocks would definitely appeal to the linux userbase.
Re:I Smell a Fork by mccalli · 2002-01-15 04:06 · Score: 1

Yeah, better off to just keep referring to them as "Alan's tree" and "Linus's tree."
That way, you could call Linus "out of his tree" when advocating Alan's fork...
Cheers,
Ian
PS: No, I'm not being serious...
Re:I Smell a Fork by ivan256 · 2002-01-15 04:20 · Score: 1

Linux forked years ago. People need to get over it.

Think RTLinux, linuxppc (though it's merging back now), the -ac tree...
Re:I Smell a Fork by Anonymous Coward · 2002-01-15 04:20 · Score: 0

What would Alan call his version of kernel? His last name already ends with an "X" so... I dunno where that would leave us.

Well, it would be Coxux.

Presumably, people who used that tree would be Coxuxers.
Re:I Smell a Fork by aminorex · 2002-01-15 04:28 · Score: 1

> What would Alan call his version of kernel?

I know what I would call it: Coccyx.

--
-I like my women like I like my tea: green-
Re:I Smell a Fork by gmack · 2002-01-15 04:36 · Score: 1

So what? Linus himself has said forks are a good thing.

Forks allow comparisons of 2 diffrent ways of approaching a problem(-ac or -riel) or allow for quick inclusion of features that work but aren't elegent enough to be included in tje linus tree(RedHat or SuSe).
Re:I Smell a Fork by Anonymous Coward · 2002-01-15 10:00 · Score: 0

Call it "Cawkix".
Re:I Smell a Fork by Anonymous Coward · 2002-01-15 13:17 · Score: 0

Sorry, linuxppc was never a fork. the ppc developers have their own development trees. Every few minor revisions they push their changes to the mainline tree. This is not a rare event either, they try not to let the differences get too big.

Same goes for a lot of non-x86 architectures. Think of it as a filtering process so that Linus (or the stable maintainer such as Cox or Tosatti) isn't always inundated with each and every piece of work in progress on non-core-kernel code. They only have to look at it when the ppc (or alpha or sparc or whomever) folks are done banging on it and feel it's ready for inclusion.

RTLinux would be a true fork -- a tree dedicated to doing something different with no intent of ever merging it back.
Re:I Smell a Fork by aminorex · 2002-01-16 02:43 · Score: 1

I CAN'T BELIEVE I'm not reaping Funny karma
from this one. Amazing. Y'all are a bunch o'
philistines!

--
-I like my women like I like my tea: green-
Re:I Smell a Fork by Freija+Crescent · 2002-01-16 05:42 · Score: 1

c'mon, this was pretty damn funny, mod this poor chap up..

-fc

--
. echo -e \\04 > /dev/hand1

In that case... by ringbarer · 2002-01-15 03:37 · Score: -1

Keep up the good work! I just like the freedom that not getting IP-blocked provides.

--
"Why did they cancel my favorite Sci-Fi show? I downloaded ALL the episodes!"

Important by Anonymous Coward · 2002-01-15 03:39 · Score: -1, Offtopic

This site is in violation of laws. To aviod heavy legal action, remove all contents at once. Your swift reply is appreciated (and mandatory).

Re:Important by Tasty+Beef+Jerky · 2002-01-15 03:51 · Score: -1

I have removed the contents of my stomach. Please give me your address so I may confirm my compliance with your directive.

Thank you.

--
I'm the tasty treat nobody can resist!
IM Me! AOL IM:Tasty Beef Jerky

Why NOT call them High Priests? by ringbarer · 2002-01-15 03:39 · Score: -1

Linux is more Cathedral than Bazaar these days anyway!

--
"Why did they cancel my favorite Sci-Fi show? I downloaded ALL the episodes!"

Good decision to remove Rik's VM from mainline. by PastaAnta · 2002-01-15 03:41 · Score: 5, Insightful

I think it was an excellent decision of Linus to remove Rik's VM from the mainline kernel. If not for technical reasons then for political reasons.

Rik's VM obviously needed to be fixed and/or tuned, but apparently lacked the necessary attention from Rik. If Linus had not removed the VM, it would probably have been the situation for a while. Instead we now have TWO VM's which are rather stable and Rik working full speed to make his VM the best.

Competition is good! Which VM will be the best for the future will be determined by Survival Of The Fittest(tm)

It can be argued though, that it was not the right time during 2.4, but Andreas VM seemed to stabilise rather quick with the high level of attention to the problem. Sometimes it takes drastic measures to get results...

Re:Good decision to remove Rik's VM from mainline. by ringbarer · 2002-01-15 03:48 · Score: -1

Competition is good! Which VM will be the best for the future will be determined by Survival Of The Fittest(tm)

Which is EXACTLY how Microsoft operates internally... Guess Linux has gone beyond the need to just blatantly rip off the Start Menu innovation and is moving on to business practises.

--
"Why did they cancel my favorite Sci-Fi show? I downloaded ALL the episodes!"
Re:Good decision to remove Rik's VM from mainline. by GypC · 2002-01-15 04:12 · Score: 2

By Rik's comments in the interview one would think that Rik's patches apparently lacked the necessary attention from Linus. I tend to believe Rik, a one man revision control system on a project of that size has got to be damn lossy...
Re:Good decision to remove Rik's VM from mainline. by PastaAnta · 2002-01-15 04:40 · Score: 4, Interesting

I think you are right that Linus could probably have taken more patches from Rik than he did.

On the other hand you could argue, that too many patches are a sign of the VM not being stable enough. Therefore the VM should probably be matured in a seperate tree (as Rik himself suggests) instead of flooding Linus with bugfixes and tweaking. Then when the VM is stable and can be proven to perform better I am sure even Linus can be persuaded.

And yes a one man control system IS lossy but that is not a bug but a feature - because it ensures consistensy. In every project of this scale coordination is essential and the individual developers MUST be more thorough with their work before comitting it!!!
Re:Good decision to remove Rik's VM from mainline. by docwhat · 2002-01-15 04:54 · Score: 3, Informative

Rik's a really smart guy, but he isn't (or, rather, wasn't) so good at keeping the mainline kernel moving forward. Despite his comment about Linus dropping patches (which is true). What he didn't mention is that he never resubmitted the patches. He tried once and then dropped them.

I thinks Rik's VM will become really really good as he maintains a branch for himself. When it's 95% of the way done, he can then work on merging it into maintstream (ie, the Linus kernel). Then we'll have a really kick-ass VM.

But Rik wasn't working well with the established method for dealing with the Linus kernel. Linus then made the choice to go with a VM from someone who *did* know how to work with the Linus Kernel.

It's not a technical issue, it's a maintence issue.

Read up on the kernel cousin stuff with Rik and Linus talking about this.

Ciao!

--
The Doctor What (KF6VNC)
Re:Good decision to remove Rik's VM from mainline. by Enigma2175 · 2002-01-15 05:20 · Score: 2

one man revision control system on a project of that size has got to be damn lossy...
And Rik's solution to this is to create a patchbot to keep submitting the patches to Linus. I hope he does not apply this concept to his OOM killer, or instead of killing processes when you run out of memory it will spawn serveral new processes. Linux is OOM, he is overloaded, so Rik decides he will put an even greater load on him.

--
Enigma
Re:Good decision to remove Rik's VM from mainline. by krogoth · 2002-01-15 05:43 · Score: 4, Insightful

After reading the interview, I agree with this. Rik says:

You want me to answer that question in how many books ? ;) Well, lets make a short answer. Andrea's VM is an attempt to improve the performance of the Linux VM without modifying the structure of the VM. He seems to succeed at it very well, but due to the fact that he doesn't modify the structure of the VM his VM still has the same fundamental problems as the Linux VM. My VM is an attempt to attack some of the fundamental problems the Linux VM has, at the moment still without too much performance tuning.

In other words, he's trying experimental ideas, while AA is improving on a stable system. Experimental development should not be done in the main kernel tree! I think once he has implemented his ideas and stabilized the development of his VM it might have better chances of getting back in. I think in the long run he actually has a better chance, because once he has something to show for all this, if his ideas are right, he should have a much better VM. Until then I agree with Linus' decision.

--

They that quote Benjamin Franklin on liberty and safety deserve neither.
Re:Good decision to remove Rik's VM from mainline. by Cocoronixx · 2002-01-15 05:44 · Score: 1

You retard, MS ripped off the Start Menu "innovation" from Mac. Just drag that "innovation" to the top of your screen, and look.

Get a clue

--
"Obscenity is the crutch of the inarticulate motherfucker." - cloak42
Re:Good decision to remove Rik's VM from mainline. by arkanes · 2002-01-15 06:37 · Score: 2

Mac versions around that time had nothing that looked or worked even remotely like the Start button and menu. Let's keep our facts straight.
Re:Good decision to remove Rik's VM from mainline. by codingOgre · 2002-01-15 09:37 · Score: 1

Oh really? Why don't you elaborate on your point.

--
Space may be the final frontier, but it's made in a Hollywood basement. --Red Hot Chili Peppers, Californication
Re:Good decision to remove Rik's VM from mainline. by jrockway · 2002-01-15 16:54 · Score: 1

Nothing like the, uh, Apple menu?

--
My other car is first.
Re:Good decision to remove Rik's VM from mainline. by arkanes · 2002-01-16 01:39 · Score: 2

The apple menu might've been the inspiration for the start menu, but the apple menu (then) didn't have nearly the functionality that the start menu does - it only provided access to certain system-level stuff, like control panels. There was a third party util to make it more or less like the start menu, but I'm fairly sure that didn't come out till System 8 or so (after win95).
Re:Good decision to remove Rik's VM from mainline. by jrockway · 2002-01-16 08:39 · Score: 1

Okay, the Apple menu *has always* been able to open programs (and documents), control panels, and anything else you can put in System Folder::Apple Menu Items (this includes scripts to log out [with AtEase or whatever] or shut down).

Now the Start button does the exact same thing, right? What I'm asking (since I've never owned a windows machine) is what the start button can do that the Apple Menu with a bit of AppleScript can't do.

--
My other car is first.
Re:Good decision to remove Rik's VM from mainline. by arkanes · 2002-01-16 09:15 · Score: 2

Nothing, probably. Except that, in the time frame we (or at least _I_ am talking about, which is when I used macs in high school, the apple menu could NOT open whatever you stuck in the system folder/apple menu items, and there was no such animal as applescript.

isn't it the truth? by ArchieBunker · 2002-01-15 03:43 · Score: -1, Flamebait

Is there body of people that decides what goes and what stays, other than RMS and AC? Just what I want more kernel config options. It takes a good half hour to go through them all now. Who the hell uses ham radio shit? No one. Give me a flat BSD config file any day.

--
Only the State obtains its revenue by coercion. - Murray Rothbard

Re:isn't it the truth? by Anonymous Coward · 2002-01-15 03:54 · Score: -1, Offtopic

Who the hell uses ham radio shit?

I do. Dozens of my friends do.
Your nick, "Archie Bunker", really is appropriate. You think the world revolves around your needs, and aren't intelligent enough to know how to skip a config section.

Solaris expensive? by ArchieBunker · 2002-01-15 03:45 · Score: -1

You can download the ISO's for free and its good for up to 8 cpus per box. Even if you buy the media its still no more expensive than redhat. Linux is so great that the queen of england dumped it for win2k.

--
Only the State obtains its revenue by coercion. - Murray Rothbard

Re:Solaris expensive? by jdh28 · 2002-01-15 04:21 · Score: 1

I think the poster meant more that Sun boxes are expensive.
I know Solaris is available on x86, but the thread was about Big Iron. Besides, Sun seem to be stopping development of Solaris on x86.
john
Re:Solaris expensive? by HanzoSan · 2002-01-15 04:48 · Score: 1

Sunblade is cheap

--
If you use Linux, please help development of Autopac
Re:Solaris expensive? by MattRog · 2002-01-15 04:49 · Score: 1

That is correct -- which is why I said I'd want a SunFire 280 if we could afford it. :D The I/O is simply astounding -- I wouldn't want Solaris on x86 anyway. :)

--

Thanks,
--
Matt
Re:Solaris expensive? by Anonymous Coward · 2002-01-15 07:34 · Score: 0

But blades SUCK. Especially the 100 series.

The problem with Sun hardware is that the good stuff is insanely expensive, and the reasonably priced stuff is complete crap.

A $1000 Sun 1u will be destroyed in every way by a $1000 Dell 1u.
Re:Solaris expensive? by phajek · 2002-01-15 07:46 · Score: 1

"Every Way"---- Let's see... you're comparing a mature 64 bit arch with a 32 bit POS????

Shame that what was clueless NT "Admins" are now advocating Linux... another reason why I'm happy using FreeBSD on x86.

Slashdot Editors are deleting posts!!! by CmderTaco · 2002-01-15 03:47 · Score: -1

Read this FAST, before the editors delete it!!!

This post was deleted by the Slashdot Editors. It had some negative things to say about Linus, but it was pretty informative, but they deleted it to further thier agenda!!! I am shocked at the lengths that the editors will go to to keep everyone's opinion the same as thiers on this site!!!

--
- Marco

Interesting by 4of12 · 2002-01-15 03:48 · Score: 5, Insightful

I have a lot of respect for Rik van Riel, but I think that Linus made a good decision to "cut bait" on his VM implementation for 2.4.

It was not that Rik's ideas were bad, it was just that their complexity and implementation were going to take too long - they should have been hashed out in 2.3 instead of 2.4.10.

I'm looking forward to having Rik prove his reverse mapping technology implementation in 2.5.

May the best ideas ultimately win, and may the giants of the kernel not take offense at each other. It would be a real shame if something stupid like Linus' lossy source code control system put off Rik so much the Linux community at large lost his wonderful contributions.

Here's to hoping that Linus gets more sensitive in some cases, and that Rik gets less sensitive in some cases.

--
"Provided by the management for your protection."

Re:Interesting by PigleT · 2002-01-15 04:07 · Score: 1

How do I agree without being scored down as redundant? ;)

Yes, it's partly linus' fault that 2.4.n=10 a more stable VM has appeared, although that shouldn't have been in 2.4.x at all.

Here's wishing 2.5 not only solves all these silly bickerings and mismanagements, but that 2.6 comes out with New Toys resulting from a lengthy 2.5.x tree as well.

--
~Tim
--
.|` Clouds cross the black moonlight,
Rushing on down to the circle of the turn
Re:Interesting by Delphis · 2002-01-15 07:48 · Score: 1

Until the dust settles I'm sticking with 2.2 .. does all I want for now :)

--
Delphis

Rik a prime devoloper Linus don't think so by mab · 2002-01-15 03:49 · Score: 2, Informative

I saw a post on the linux kernel news groups (you can serch for it) about 2-3 weeks ago where Linus says something like "that's why I don't consider you a kernel developer" he always seems to be wining about something. But hey what do I know I'm still trying to get xscreensver to do a mozilla -remote openurl (some url) for a kiosk :)

Re:Rik a prime devoloper Linus don't think so by xphase · 2002-01-15 04:52 · Score: 2, Informative

See this link and scroll down a bit for this quote from linus:

"Which, btw, explains why I don't consider you a kernel maintainer, Rik, and I don't tend to apply any patches at all from you. It's just not worth my time to worry about people who aren't willing to sustain their patches."

--xPhase

--
The following sentence is TRUE. The previous sentence is FALSE.
Re:Rik a prime devoloper Linus don't think so by laserjet · 2002-01-15 05:24 · Score: 3, Insightful

I don't want to get marked down or flamed for trolling or anything, because I am not:

Thanks for posting this quote. The more I read in to this stuff, it often times seems as though Linux has an immature attitude, and often acts like a baby. Ignoring patches because you have a disagreement from someone is just plain immature. I can see how frustrated I would get working with Linus. He still acts like it is his little baby project, and that is just not the case anymore. Thosands of developers are working on it, and this kind of attitude by Linus would just turn people off from the project.

These kind of snide remarks by Linus are not needed, and if I was Rik, I would tell Linus to fuck off and put my talent to use somewhere else. Linus, act a little more mature.

--
Moon Macrosystems. Sun's biggest competitor.
Re:Rik a prime devoloper Linus don't think so by Chang · 2002-01-15 08:04 · Score: 1

If you found this interesting then you really should read the relavent thread from lkml yourself and maybe gain some context around this quote as there was more to it than what you appear to think.

I urge you to read (and think) for yourself instead of relying on choice quotes from Slashdot.
Re:Rik a prime devoloper Linus don't think so by GigsVT · 2002-01-15 09:09 · Score: 1

These kind of snide remarks by Linus are not needed, and if I was Rik, I would tell Linus to fuck off and put my talent to use somewhere else. Linus, act a little more mature.

Anyone can sound bad taken out of context. You really need to read the whole thread to understand what this is about.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.

slashdotted? by Anonymous Coward · 2002-01-15 03:49 · Score: 0, Offtopic

"..but -rmap will make sure that your server can survive better if it gets slashdotted.."

what does "get slashdotted" mean ?

Re:slashdotted? by feldkamp · 2002-01-15 04:10 · Score: 1

It refers to when a website is clogged with traffic due to it being posted on slashdot.

Us geeks always rush to read the story, and the website is hosed.

Need Help ? by Anonymous Coward · 2002-01-15 03:50 · Score: 1, Insightful

Maybe we need some help from *BSD VM hackers to to solve this VM thing.

Since a year and it still has big holes.

Re:Need Help ? by Art+Deco · 2002-01-16 03:38 · Score: 1

I don't think Linux kernel hackers want any help from the *BSD camp. Remembering back to the KA9Q networking days in Linux; it was more important for the Linux group to do things their own way than to provide the best services to their users. My understanding is that Linux could have incorporated large parts of BSD network code that would carry both the BSD and GPL licenses but the Linux developers made their users wait until they could develop their own BSD-like networking.

I Luvvvvvv My Windows Box by Anonymous Coward · 2002-01-15 03:50 · Score: -1, Flamebait

I'll never use any other OS besides one from Microsoft for any of my productive activities

AHHAHAHA I SPIT ON on all the BUGGY Window Managers (Enlightment, KDE, GNOME)!

I SPIT on GIMP. Photoshop 6.0 on XP Runs like a DREAM!!!

I SPIT on StarOffice and KOffice, Microsoft Office XP runs soooo nice. I luv it.

I have no problem forking over as much cash for any Windows Version because I get what I pay for - QUALITY not some second rate operating system that SECURITY is its only decent feature.

Windows + Firewall + Regular Patches = NO NEED FOR LINUX

Dont try argue with me! Im a Windows User and I will always be ;)

Re:I Luvvvvvv My Windows Box by Anonymous Coward · 2002-01-15 03:56 · Score: -1, Offtopic

You have no brains.
Re:I Luvvvvvv My Windows Box by rapid+prototype · 2002-01-15 04:00 · Score: -1, Flamebait

i think you're on the wrong site. this is 'news for nerds' and you, obviously, are a moron, not a nerd :)

-rp
Re:I Luvvvvvv My Windows Box by Zapdos · 2002-01-15 04:22 · Score: 1

Windows + Firewall + Regular Patches = NO NEED FOR LINUX

let me rewrite that in a different way

$199 retail "Home version" + $10/month Internet connection + $$software = need for Linux

You are not the world. Most of the worlds population is poor. You are the minority coming in at 8%. The poor can not afford windows. What they can afford is time. So with a planet of Linux hackers "92%" there will be no need of windows.

Lets not assume what we will always be. You will miss out on allot of things.

As for the quality of Office XP on window XP it is a joke. Outlook cant handle multiple filters properly. Word can not complete a simple search and replace in a large text file. Excel borks on large files as well. And this is on tier 1hardware with only office installed.

--
Get a free ipod.

Patch bot is the answer? by imrdkl · 2002-01-15 03:50 · Score: 2, Informative

Rik seems pretty hot on this idea, but I dont see how it could help much. I mean, won't repeated email be ignored nearly as much as the initial submission? I recall in the interview with Marcelo that he did not plan to use either public CVS or a tracking system, but rather planned to keep things close to the cuff as in the past. Perhaps this is the persona of a kernel-master, or perhaps openness and publicity lead to more interruptions, I dunno.

Anyways, an enlightening, no-holes-barred interview. Enjoyable.

Re:Patch bot is the answer? by PigleT · 2002-01-15 04:03 · Score: 3, Insightful

Yes, such a thing would be appreciated. It's all very well developing linux in order to "improve itself" but one can take the "stuff the users" approach too far.

The problem is that there isn't a decent multi-patch versioning system out there: how would you tell CVS you wanted to store versions of files pertaining to 2.5.2-mjc and 2.4.13-ac1 and 2.4.18 and then a set of files for Rik's VM? Then how on earth would you pull out the set of files that constitutes a `linus+mjc' tree, or a `linus+ac' tree, from what you've stored?

--
~Tim
--
.|` Clouds cross the black moonlight,
Rushing on down to the circle of the turn
Re:Patch bot is the answer? by Rik+van+Riel · 2002-01-15 04:27 · Score: 5, Informative

The problem is simple: maintainers of any parts of the kernel get flooded by email, maintainers of the whole kernel (Linus, Alan, Marcelo) get flooded even worse.
You really cannot expect these people to read all their email all the time, so patches and bugfixes get lost and may need to be resent various times before they get noticed.
Add to that the fact that many of the people writing these patches are also extremely busy and may not get around to resending the patch all the time (I know I don't).
The solution here would be to have the patch re-sent automatically as long as it still works ok with the latest kernel version ... this can all be checked automatically.
Re:Patch bot is the answer? by _Quinn · 2002-01-15 04:30 · Score: 3, Informative

cvs co -r 2.5.2
# patch mjc-1
cvs tag -b 2.5.2-mjc
cvs tag mjc-1
cvs commit
# elsewhere/when
cvs co -r 2.5.2-mjc
# patch mjc-2
cvs tag mjc-2
cvs commit

cvs co -r 2.4.13
#patch ac1
cvs tag -b 2.4.13-ac
cvs tag ac-1
cvs commit
# elsewhere/when
cvs co -r 2.4.13-ac
# patch 2.4.13-ac2
cvs tag ac-2
cvs commit

# assuming that Rik's VM patches are independent
cvs co 2.5.2
cvs co rvr-VM
# patch rvr-VM
# or, maintain Rik's VM patches as their own
# files:
# cvs co rvr-VM
# cvs update # forces merge
cvs tag -b 2.5.2-rvr-VM
cvs tag rvr-VM-1
cvs commit
# elsewhere
cvs co 2.5.2-rvr-VM

Why wouldn't something like this work? You could even wrap everything up in a nice GUI if you wanted to. :)

-_Quinn

--
Reality Maintenance Group, Silver City Construction Co., Ltd.
Re:Patch bot is the answer? by imrdkl · 2002-01-15 04:33 · Score: 1

Ah, I see. So the patches which dont make it into a particular pre get reapplied to see if they still "fit" into the next one. Automation will answer whether the tree still builds, but it sounds like there needs to be a warm body in there, somewhere.
Keep up the good work, sir. And thanks for the clarification.
Re:Patch bot is the answer? by gmack · 2002-01-15 04:40 · Score: 1

Linus himself said the patchbot is a god idea so long as it checks to make sure the patch still compiles cleanly before resending.

There was also talk of a backoff mechanism to keep it from becomming a flood.

IMO this would be a very cool source control system if it gets implemented correctly.
Re:Patch bot is the answer? by Anonymous Coward · 2002-01-15 05:39 · Score: 0

I don't know why Linus doesn't just check
the code into CVS and be done with it.

God forbid!
Re:Patch bot is the answer? by Score+Whore · 2002-01-15 05:57 · Score: 1

No offense, but you can check if they apply automatically, but you certainly can't check if they work automatically. Changes in different parts of the kernel can have wide reaching effects if they change the semantics of a particular routine, piece of data, or interface. It's absurd to think that merely because a patch applies, it works.
Re:Patch bot is the answer? by frohike · 2002-01-15 06:30 · Score: 1

Pak Chooie Unf

I am the patcher robot
Patching is the answer
Patching will protect you from the terrible secret of Linux

Pak Chooie Unf

--
Cryptic Allusion - New Mac and Dreamcast Games!
Re:Patch bot is the answer? by MikeBabcock · 2002-01-15 06:38 · Score: 2

I submit that a patch-holding website would be much more valuable. The patches are sent to a common site with destination E-mail specified (Linus, Alan, Rik, etc.) and are visible or private (visible allowing others to come along and look through the patch and post comments to it; like Slashdot).

This is similar to the submission already made on the LKML that patches be auto-resent, but I don't believe the resending of them is necessary; I think sending a daily E-mail with a list of the patches and an URL to retrieve them, as well as basics about who submitted it and when would be much more valuable to all.

--
- Michael T. Babcock (Yes, I blog)
Re:Patch bot is the answer? by derobert · 2002-01-15 07:55 · Score: 1

You'd probably use branches and tags. To get linus+ac, you'd do something like:
cvs co -r 2.4.18 linux cd linux cvs update -j 2.4.13-ac1
Then, of course, fix everything that didn't patch. mjc would be very simular.
Perhaps the cvs(1) manpage would help?
Re:Patch bot is the answer? by Chang · 2002-01-15 08:08 · Score: 1

This is true, but user testing is supposed to catch this so that it can be rolled back in the next -pre release.

The problem is hardly anybody tests -pre patches but everybody complains when a -final comes out screwed up.
Re:Patch bot is the answer? by Anonymous Coward · 2002-01-15 20:18 · Score: 0

The reason why CVS and BitKeeper don't work for the Linux kernel guys is not technical, it's political - Linus doesn't like it.

He receives so many patches per day he cannot take a stand and argue on each and everyone of them. Therefore he just drops them, leave them unattended. Patches should be brief and with a clear, stated object.

CVS and BK would just overflow with overaged patches within months as it would require a lot more administration.

If a "maintainer" of a particular patch is not persistent re-sender of patches he is not a maintainer.

"Linus doesn't scale" as said by Linus Torvalds.

Big split? by grub · 2002-01-15 03:52 · Score: 2, Insightful

Recall that "Linux" is owned by Linus. It's not inconceivable to envision a pissing match of the egos ending in "Cox' "rogue" kernel isn't true Linux. Rename it." one day.

--
Trolling is a art,

Re:Big split? by Anonymous Coward · 2002-01-15 03:59 · Score: 3, Funny

Recall that "Linux" is owned by Linus. It's not inconceivable to envision a pissing match of the egos ending in "Cox' "rogue" kernel isn't true Linux. Rename it." one day.

Yea, but then they'd have to call it "Coxux" and they'd never get that past the censors.

---

Darn right I'm not signing my name to this post.
Re:Big split? by Anonymous Coward · 2002-01-15 04:02 · Score: -1, Offtopic

hmm, would that be coxix (or, unfortunately, coccyx?)
Re:Big split? by Anonymous Coward · 2002-01-15 04:15 · Score: 0

/me squirts coffee out his nose.
Re:Big split? by jgerman · 2002-01-15 08:59 · Score: 2

Uhh GPL, heard of it. Cannot happen, Alan would never have to rename his branch. Linux is owned by no one, Linus gave it away.

--
I'm the big fish in the big pond bitch.
Re:Big split? by GigsVT · 2002-01-15 09:13 · Score: 1

Linux is a trademark of Linux Torvalds. He owns the name. Please learn a little about IP.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:Big split? by GigsVT · 2002-01-15 09:15 · Score: 1

Sheesh, Linus Torvalds. You know what I meant.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:Big split? by jgerman · 2002-01-15 09:57 · Score: 2

He gave it away. Not to mention he hasn't agressively defended it. Please learn a little about IP.

--
I'm the big fish in the big pond bitch.
Re:Big split? by mindstrm · 2002-01-15 09:58 · Score: 2

And that trademark will never hold up in court, other than to not allow someone ELSE to trademark it.

It's not enforced> Many people, with their own custom kernels, call their kernel 'linux'. Alan could fork to his heart's delight.. Linus could not decide one day that it's not Linux any more, and stop him from using the name. Nor WOULD he, I imagine.

The trademark on Linux only serves to ensure nobody else can trademark it.
Re:Big split? by GigsVT · 2002-01-15 13:27 · Score: 1

I know, the original poster implied that the GPL somehow made his trademark invalid. The first poster clearly does not know the difference between trademarks, copyrights, and patents.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:Big split? by GigsVT · 2002-01-15 13:29 · Score: 1

I realize that, I was just posting in reply to his claim that the GPL somehow made him not have any claim to the name Linux, showing a clear confusion about the difference between trademarks and copyrights (licensing, etc).

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.

rmap VM: about bloody time, OOM: booo by Anonymous Coward · 2002-01-15 03:53 · Score: 1, Interesting

it's about time rmap VM was developed and integrated into the kernel. together with O(1) scheduler and low-latency patches it will be a great advance for 2.5 kernel But sooner or later OOM due to memory overcommit will have to be solved properly (by not overcommitting). OOM killer is just a hacky solution (even windows doesn't have suck a hack). CaptnMArk (forgot my password right now :(

Re:rmap VM: about bloody time, OOM: booo by gmack · 2002-01-15 04:48 · Score: 2

Actually windows will do an OOM kill.. I've seen it.

As for overcommiting: it's needed; in fact Solaris and BSD both do it. The main problem is that it's hard to fix the OOM killer without getting the VM down to an art.
Re:rmap VM: about bloody time, OOM: booo by Amazing+Quantum+Man · 2002-01-15 08:35 · Score: 2

Actually windows will do an OOM kill.. I've seen it.

So have I. It's called "Blue Screen of Death".

--
Fascism starts when the efficiency of the government becomes more important than the rights of the people.

by Tasty+Beef+Jerky · 2002-01-15 03:53 · Score: -1

--

I'm the tasty treat nobody can resist!
IM Me! AOL IM:Tasty Beef Jerky

Rip Van Winkle? by Anonymous Coward · 2002-01-15 03:54 · Score: -1, Offtopic

Did anyone else read that as Rip Van Winkle?

Re:Rip Van Winkle? by Anonymous Coward · 2002-01-15 04:08 · Score: -1, Offtopic

I jusked asked everyone hear and the answer is no. It's just you.

Black box VM by king_ramen · 2002-01-15 03:58 · Score: 2, Insightful

Designing the same VM for a microwave oven, gaming PC, database server, and massively parallel cluster will make nobody happy. I think that the choice in VMs will give Linux very good flexibility to run well in different environments. A fully abstracted VM that wrote to fully abstracted IO would allow for "snap ins" that would be optimized for the task at hand. I think forcing 2 VM trees to compete and coexist is good.

Then again, how much is RAM? I just bought 512MB for less than $40. I NEVER swap (running ~800MB RAM / server) and never want to. I ran my first e-commerce web site w/ SSL and mSQL on a 486SLC-20MHz with 5MB of 110ns DRAM. Yeah, it swapped. But these days, most machines are way overkill for serving web pages, files, and queries.

--
----- Refactoring is the reason why man does not mistake himself for a god.

Their site runs on Win2k :) by Anonymous Coward · 2002-01-15 04:02 · Score: -1, Offtopic

BAHAHAHAHAHA!

The site linux.html.it is running Microsoft-IIS/5.0 on Windows 2000.

Re:Their site runs on Win2k :) by Anonymous Coward · 2002-01-15 05:56 · Score: 0

I m not a geek, but you, you are a moron.

It s html.it which runs Win2k. It does only have a linux section which is linux.html.it. So there is nothing ridiculous about that, because it s not a linux devoted site. And it s surely not as ridiculous that linuxsucks.org running ... linux...

Anyway, nice try FlameBaiterWannabe

Born in '78?? by bwhaley · 2002-01-15 04:06 · Score: 1

I noticed that Rik was born in '78. That puts him just 2 years older than myself. How could he possibly know so much? I have been involved in computers since I was around 6 but I have no where near the knowledge that this fellow has. It must be all the gaming I do, not to mention he said he's been involved with Linux since '94. Anyway, what a smart guy.

--
"I either want less corruption, or more chance
to participate in it." -- Ashleigh Brilliant

Re:Born in '78?? by Tower · 2002-01-15 04:55 · Score: 1

It is all a matter of focus - think of the physics world. Most of the shatteringly new physics theories have come before the age of 35, many before 30 years old. Your "brain power" peaks in your mid 20s (according to some studies), and with a little direction and some motivation, it isn't at all unreasonable that any number of people have the knowledge and ability to do these things at that age.

That being said, I don't mean this as a knock on Rik - he certainly has shown a good deal of intelligence.

--
"It's tough to be bilingual when you get hit in the head."
Re:Born in '78?? by HanzoSan · 2002-01-15 04:56 · Score: 1

Because hes smarter. Yes its possible for someone to be smarter than you. I dont know coding as well as him, but i didnt have a computer since I was 6, maybe if i did, I'd be as good as him as I'd have no excuse to use.

Stop playing games and read 4-5 books on C and kernel s

--
If you use Linux, please help development of Autopac

Here you go, ignorant prick: by Anonymous Coward · 2002-01-15 04:08 · Score: -1

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
CONFIG_M586=y
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_USE_STRING_486=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_TOSHIBA=m
# CONFIG_I8K is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_LOCK_BREAK=y
# CONFIG_X86_UP_APIC is not set
# CONFIG_X86_UP_IOAPIC is not set
CONFIG_HAVE_DEC_LOCK=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_EISA=y
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=m
CONFIG_MTD_REDBOOT_PARTS=m

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
# CONFIG_NFTL_RW is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
# CONFIG_MTD_AMDSTD is not set
# CONFIG_MTD_SHARP is not set
# CONFIG_MTD_JEDEC is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_PHYSMAP=m
CONFIG_MTD_PHYSMAP_START=8000000
CONFIG_MTD_PHYSMAP_LEN=4000000
CONFIG_MTD_PHYSMAP_BUSWIDTH=2
CONFIG_MTD_PNC2000=m
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_SBC_GXX=m
CONFIG_MTD_ELAN_104NC=m
# CONFIG_MTD_MIXMEM is not set
# CONFIG_MTD_OCTAGON is not set
# CONFIG_MTD_VMAX is not set
# CONFIG_MTD_L440GX is not set

#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=m
# CONFIG_MTD_PMC551_BUGFIX is not set
# CONFIG_MTD_PMC551_DEBUG is not set
CONFIG_MTD_SLRAM=m
CONFIG_MTD_MTDRAM=m
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
# CONFIG_MTD_BLKMTD is not set

#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOC1000=m
CONFIG_MTD_DOC2000=m
CONFIG_MTD_DOC2001=m
CONFIG_MTD_DOCPROBE=m
CONFIG_MTD_DOCPROBE_ADVANCED=y
CONFIG_MTD_DOCPROBE_ADDRESS=0000
CONFIG_MTD_DOCPROBE_HIGH=y
CONFIG_MTD_DOCPROBE_55AA=y

#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_ECC is not set
# CONFIG_MTD_NAND_VERIFY_WRITE is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_SUNBPP is not set
CONFIG_PARPORT_OTHER=y
CONFIG_PARPORT_1284=y

#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_XD=m
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_BPCK6=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
# CONFIG_PARIDE_EPATC8 is not set
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_MD_MULTIPATH=m
CONFIG_BLK_DEV_LVM=m

#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_TOS is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_ROUTE_LARGE_TABLES is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
# CONFIG_IP_NF_MATCH_LENGTH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_COMPAT_IPCHAINS=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_COMPAT_IPFWADM=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IPV6=m

#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
# CONFIG_IP6_NF_MATCH_MAC is not set
# CONFIG_IP6_NF_MATCH_MULTIPORT is not set
# CONFIG_IP6_NF_MATCH_OWNER is not set
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_FILTER=m
# CONFIG_IP6_NF_TARGET_LOG is not set
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
CONFIG_KHTTPD=m
CONFIG_ATM=y
CONFIG_ATM_CLIP=y
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
CONFIG_VLAN_8021Q=m

#
#
#
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
CONFIG_DECNET=m
# CONFIG_DECNET_SIOCGIFCONF is not set
# CONFIG_DECNET_ROUTER is not set
CONFIG_BRIDGE=m
CONFIG_X25=m
CONFIG_LAPB=m
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
CONFIG_ECONET=m
CONFIG_ECONET_AUNUDP=y
CONFIG_ECONET_NATIVE=y
CONFIG_WAN_ROUTER=m
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_CSZ=m
# CONFIG_NET_SCH_ATM is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y

#
# Telephony Support
#
CONFIG_PHONE=m
CONFIG_PHONE_IXJ=m
# CONFIG_PHONE_IXJ_PCMCIA is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=m

#
# IDE chipset support/bugfixes
#
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
CONFIG_BLK_DEV_ISAPNP=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_PCI_WIP=y
CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_AEC62XX_TUNING=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_AMD74XX_OVERRIDE is not set
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT34X=y
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_PDC202XX=y
# CONFIG_PDC202XX_BURST is not set
# CONFIG_PDC202XX_FORCE is not set
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDE_CHIPSETS=y

#
# Note: most of these also require special kernel boot parameters
#
CONFIG_BLK_DEV_4DRIVES=y
CONFIG_BLK_DEV_ALI14XX=y
CONFIG_BLK_DEV_DTC2278=y
CONFIG_BLK_DEV_HT6560B=y
CONFIG_BLK_DEV_PDC4030=y
CONFIG_BLK_DEV_QD65XX=y
CONFIG_BLK_DEV_UMC8672=y
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_IVB=y
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_BLK_DEV_ATARAID=m
CONFIG_BLK_DEV_ATARAID_PDC=m
CONFIG_BLK_DEV_ATARAID_HPT=m

#
# SCSI support
#
CONFIG_SCSI=m

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_SD_EXTRA_DEVS=40
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_DEBUG_QUEUES is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y

#
# SCSI low-level drivers
#
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_7000FASST=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AHA1740=m
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_BUILD_FIRMWARE is not set
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_AIC7XXX_OLD_TCQ_ON_BY_DEFAULT=y
CONFIG_AIC7XXX_OLD_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_OLD_PROC_STATS=y
CONFIG_SCSI_DPT_I2O=m
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_IN2000=m
CONFIG_SCSI_AM53C974=m
CONFIG_SCSI_MEGARAID=m
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
CONFIG_SCSI_CPQFCTS=m
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_DTC3280=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
# CONFIG_SCSI_EATA_LINKED_COMMANDS is not set
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_EATA_DMA=m
CONFIG_SCSI_EATA_PIO=m
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_GENERIC_NCR5380=m
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_G_NCR5380_PORT=y
# CONFIG_SCSI_G_NCR5380_MEM is not set
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
CONFIG_SCSI_NCR53C406A=m
CONFIG_SCSI_NCR53C7xx=m
# CONFIG_SCSI_NCR53C7xx_sync is not set
CONFIG_SCSI_NCR53C7xx_FAST=y
CONFIG_SCSI_NCR53C7xx_DISCONNECT=y
# CONFIG_SCSI_SYM53C8XX_2 is not set
CONFIG_SCSI_NCR53C8XX=m
CONFIG_SCSI_SYM53C8XX=m
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
# CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
CONFIG_SCSI_PAS16=m
CONFIG_SCSI_PCI2000=m
CONFIG_SCSI_PCI2220I=m
CONFIG_SCSI_PSI240I=m
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_ISP=m
CONFIG_SCSI_QLOGIC_FC=m
# CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_SEAGATE=m
CONFIG_SCSI_SIM710=m
CONFIG_SCSI_SYM53C416=m
CONFIG_SCSI_DC390T=m
# CONFIG_SCSI_DC390T_NOGENSUPP is not set
CONFIG_SCSI_T128=m
CONFIG_SCSI_U14_34F=m
CONFIG_SCSI_U14_34F_LINKED_COMMANDS=y
CONFIG_SCSI_U14_34F_MAX_TAGS=8
CONFIG_SCSI_ULTRASTOR=m
CONFIG_SCSI_DEBUG=m

#
# Fusion MPT device support
#
CONFIG_FUSION=m
# CONFIG_FUSION_BOOT is not set

#
# (ability to boot linux kernel from Fusion device is DISABLED!)
#
CONFIG_FUSION_ISENSE=m
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LAN=m
CONFIG_NET_FC=y

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
CONFIG_IEEE1394=m

#
# Device Drivers
#
CONFIG_IEEE1394_PCILYNX=m
# CONFIG_IEEE1394_PCILYNX_LOCALRAM is not set
CONFIG_IEEE1394_PCILYNX_PORTS=y
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_IEEE1394_VERBOSEDEBUG is not set

#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_PCI=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_LAN=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
CONFIG_ARCNET=m
CONFIG_ARCNET_1201=m
CONFIG_ARCNET_1051=m
CONFIG_ARCNET_RAW=m
CONFIG_ARCNET_COM90xx=m
CONFIG_ARCNET_COM90xxIO=m
CONFIG_ARCNET_RIM_I=m
CONFIG_ARCNET_COM20020=m
CONFIG_ARCNET_COM20020_ISA=m
CONFIG_ARCNET_COM20020_PCI=m

#
# Appletalk devices
#
CONFIG_APPLETALK=y
CONFIG_LTPC=m
CONFIG_COPS=m
CONFIG_COPS_DAYNA=y
CONFIG_COPS_TANGENT=y
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_ETHERTAP=m
CONFIG_NET_SB1000=m

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_SUNLANCE is not set
CONFIG_HAPPYMEAL=m
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNLANCE is not set
CONFIG_SUNGEM=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL1=m
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL16=m
CONFIG_EL3=m
CONFIG_3C515=m
# CONFIG_ELMC is not set
# CONFIG_ELMC_II is not set
CONFIG_VORTEX=m
CONFIG_LANCE=m
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
# CONFIG_ULTRAMCA is not set
CONFIG_ULTRA=m
CONFIG_ULTRA32=m
CONFIG_SMC9194=m
CONFIG_NET_VENDOR_RACAL=y
CONFIG_NI5010=m
CONFIG_NI52=m
CONFIG_NI65=m
CONFIG_AT1700=m
CONFIG_DEPCA=m
CONFIG_HP100=m
CONFIG_NET_ISA=y
CONFIG_E2100=m
CONFIG_EWRK3=m
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_LP486E=m
CONFIG_ETH16I=m
CONFIG_NE2000=m
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_AC3200=m
CONFIG_APRICOT=m
CONFIG_CS89x0=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
CONFIG_DE4X5=m
CONFIG_DGRS=m
CONFIG_DM9102=m
CONFIG_EEPRO100=m
CONFIG_LNE390=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_NE3210=m
CONFIG_ES3210=m
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
CONFIG_WINBOND_840=m
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m

#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
# CONFIG_MYRI_SBUS is not set
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_SK98LIN=m
CONFIG_FDDI=y
CONFIG_DEFXX=m
CONFIG_SKFP=m
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
CONFIG_STRIP=m
CONFIG_WAVELAN=m
CONFIG_ARLAN=m
CONFIG_AIRONET4500=m
CONFIG_AIRONET4500_NONCS=m
CONFIG_AIRONET4500_PNP=y
CONFIG_AIRONET4500_PCI=y
# CONFIG_AIRONET4500_ISA is not set
# CONFIG_AIRONET4500_I365 is not set
CONFIG_AIRONET4500_PROC=m
CONFIG_AIRO=m
# CONFIG_HERMES is not set
# CONFIG_PLX_HERMES is not set
CONFIG_NET_WIRELESS=y

#
# Token Ring devices
#
CONFIG_TR=y
CONFIG_IBMTR=m
CONFIG_IBMOL=m
CONFIG_IBMLS=m
CONFIG_TMS380TR=m
CONFIG_TMSPCI=m
CONFIG_TMSISA=m
CONFIG_ABYSS=m
# CONFIG_MADGEMC is not set
CONFIG_SMCTR=m
CONFIG_NET_FC=y
CONFIG_IPHASE5526=m
CONFIG_RCPCI=m
CONFIG_SHAPER=m

#
# Wan interfaces
#
CONFIG_WAN=y
CONFIG_HOSTESS_SV11=m
CONFIG_COSA=m
# CONFIG_COMX is not set
# CONFIG_DSCC4 is not set
CONFIG_FARSYNC=m
# CONFIG_LANMEDIA is not set
CONFIG_SEALEVEL_4021=m
# CONFIG_SYNCLINK_SYNCPPP is not set
# CONFIG_HDLC is not set
CONFIG_DLCI=m
CONFIG_DLCI_COUNT=24
CONFIG_DLCI_MAX=8
CONFIG_SDLA=m
CONFIG_WAN_ROUTER_DRIVERS=y
CONFIG_VENDOR_SANGOMA=m
CONFIG_WANPIPE_CHDLC=y
CONFIG_WANPIPE_FR=y
CONFIG_WANPIPE_X25=y
CONFIG_WANPIPE_PPP=y
CONFIG_WANPIPE_MULTPPP=y
CONFIG_CYCLADES_SYNC=m
CONFIG_CYCLOMX_X25=y
# CONFIG_LAPBETHER is not set
# CONFIG_X25_ASY is not set
CONFIG_SBNI=m
CONFIG_SBNI_MULTILINE=y

#
# ATM drivers
#
CONFIG_ATM_TCP=m
# CONFIG_ATM_LANAI is not set
CONFIG_ATM_ENI=m
# CONFIG_ATM_ENI_DEBUG is not set
# CONFIG_ATM_ENI_TUNE_BURST is not set
CONFIG_ATM_FIRESTREAM=m
CONFIG_ATM_ZATM=m
# CONFIG_ATM_ZATM_DEBUG is not set
CONFIG_ATM_ZATM_EXACT_TS=y
CONFIG_ATM_NICSTAR=m
CONFIG_ATM_NICSTAR_USE_SUNI=y
CONFIG_ATM_NICSTAR_USE_IDT77105=y
# CONFIG_ATM_IDT77252 is not set
CONFIG_ATM_AMBASSADOR=m
# CONFIG_ATM_AMBASSADOR_DEBUG is not set
CONFIG_ATM_HORIZON=m
# CONFIG_ATM_HORIZON_DEBUG is not set
CONFIG_ATM_IA=m
# CONFIG_ATM_IA_DEBUG is not set
CONFIG_ATM_FORE200E_MAYBE=m
CONFIG_ATM_FORE200E_PCA=y
CONFIG_ATM_FORE200E_PCA_DEFAULT_FW=y
CONFIG_ATM_FORE200E_TX_RETRY=16
CONFIG_ATM_FORE200E_DEBUG=0
CONFIG_ATM_FORE200E=m

#
# Amateur Radio support
#
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
CONFIG_AX25=m
CONFIG_AX25_DAMA_SLAVE=y
CONFIG_NETROM=m
CONFIG_ROSE=m

#
# AX.25 network device drivers
#

#
# AX.25 network device drivers
#
CONFIG_MKISS=m
CONFIG_6PACK=m
CONFIG_BPQETHER=m
CONFIG_DMASCC=m
CONFIG_SCC=m
# CONFIG_SCC_DELAY is not set
# CONFIG_SCC_TRXECHO is not set
CONFIG_BAYCOM_SER_FDX=m
CONFIG_BAYCOM_SER_HDX=m
CONFIG_BAYCOM_PAR=m
CONFIG_BAYCOM_EPP=m
CONFIG_SOUNDMODEM=m
CONFIG_SOUNDMODEM_SBC=y
CONFIG_SOUNDMODEM_WSS=y
CONFIG_SOUNDMODEM_AFSK1200=y
CONFIG_SOUNDMODEM_AFSK2400_7=y
CONFIG_SOUNDMODEM_AFSK2400_8=y
CONFIG_SOUNDMODEM_AFSK2666=y
CONFIG_SOUNDMODEM_HAPN4800=y
CONFIG_SOUNDMODEM_PSK4800=y
CONFIG_SOUNDMODEM_FSK9600=y
CONFIG_YAM=m

#
# IrDA (infrared) support
#
CONFIG_IRDA=m

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y
CONFIG_IRDA_OPTIONS=y

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m
CONFIG_IRPORT_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m

#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
CONFIG_TOSHIBA_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m

#
# ISDN subsystem
#
CONFIG_ISDN=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_ISDN_PPP_BSDCOMP=m
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y
CONFIG_ISDN_X25=y

#
# ISDN feature submodules
#
CONFIG_ISDN_DRV_LOOP=m
CONFIG_ISDN_DIVERSION=m

#
# low-level hardware drivers
#

#
# Passive ISDN cards
#
CONFIG_ISDN_DRV_HISAX=m

#
# D-channel protocol features
#
CONFIG_HISAX_EURO=y
CONFIG_DE_AOC=y
# CONFIG_HISAX_NO_SENDCOMPLETE is not set
# CONFIG_HISAX_NO_LLC is not set
# CONFIG_HISAX_NO_KEYPAD is not set
CONFIG_HISAX_1TR6=y
CONFIG_HISAX_NI1=y
CONFIG_HISAX_MAX_CARDS=8

#
# HiSax supported cards
#
CONFIG_HISAX_16_0=y
CONFIG_HISAX_16_3=y
CONFIG_HISAX_TELESPCI=y
CONFIG_HISAX_S0BOX=y
CONFIG_HISAX_AVM_A1=y
CONFIG_HISAX_FRITZPCI=y
CONFIG_HISAX_AVM_A1_PCMCIA=y
CONFIG_HISAX_ELSA=y
CONFIG_HISAX_IX1MICROR2=y
CONFIG_HISAX_DIEHLDIVA=y
CONFIG_HISAX_ASUSCOM=y
CONFIG_HISAX_TELEINT=y
CONFIG_HISAX_HFCS=y
CONFIG_HISAX_SEDLBAUER=y
CONFIG_HISAX_SPORTSTER=y
CONFIG_HISAX_MIC=y
CONFIG_HISAX_NETJET=y
CONFIG_HISAX_NETJET_U=y
CONFIG_HISAX_NICCY=y
CONFIG_HISAX_ISURF=y
CONFIG_HISAX_HSTSAPHIR=y
CONFIG_HISAX_BKM_A4T=y
CONFIG_HISAX_SCT_QUADRO=y
CONFIG_HISAX_GAZEL=y
CONFIG_HISAX_HFC_PCI=y
CONFIG_HISAX_W6692=y
CONFIG_HISAX_HFC_SX=y
CONFIG_HISAX_DEBUG=y
# CONFIG_HISAX_SEDLBAUER_CS is not set
# CONFIG_HISAX_ELSA_CS is not set
CONFIG_HISAX_ST5481=m
CONFIG_HISAX_FRITZ_PCIPNP=m

#
# Active ISDN cards
#
CONFIG_ISDN_DRV_ICN=m
CONFIG_ISDN_DRV_PCBIT=m
CONFIG_ISDN_DRV_SC=m
CONFIG_ISDN_DRV_ACT2000=m
CONFIG_ISDN_DRV_EICON=y
CONFIG_ISDN_DRV_EICON_DIVAS=m
CONFIG_ISDN_DRV_EICON_OLD=m
CONFIG_ISDN_DRV_EICON_PCI=y
CONFIG_ISDN_DRV_EICON_ISA=y
CONFIG_ISDN_DRV_TPAM=m
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_CAPIFS_BOOL=y
CONFIG_ISDN_CAPI_CAPIFS=m
CONFIG_ISDN_CAPI_CAPIDRV=m
CONFIG_ISDN_DRV_AVMB1_B1ISA=m
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
CONFIG_ISDN_DRV_AVMB1_T1ISA=m
# CONFIG_ISDN_DRV_AVMB1_B1PCMCIA is not set
# CONFIG_ISDN_DRV_AVMB1_AVM_CS is not set
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
CONFIG_CD_NO_IDESCSI=y
CONFIG_AZTCD=m
CONFIG_GSCD=m
CONFIG_SBPCD=m
CONFIG_MCD=m
CONFIG_MCD_IRQ=11
CONFIG_MCD_BASE=300
CONFIG_MCDX=m
CONFIG_OPTCD=m
CONFIG_CM206=m
CONFIG_SJCD=m
CONFIG_ISP16_CDI=m
CONFIG_CDU31A=m
CONFIG_CDU535=m

#
# Input core support
#
CONFIG_INPUT=m
CONFIG_INPUT_KEYBDEV=m
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SERIAL_EXTENDED=y
CONFIG_SERIAL_MANY_PORTS=y
CONFIG_SERIAL_SHARE_IRQ=y
# CONFIG_SERIAL_DETECT_IRQ is not set
CONFIG_SERIAL_MULTIPORT=y
CONFIG_HUB6=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_COMPUTONE=m
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
CONFIG_DIGIEPCA=m
CONFIG_ESPSERIAL=m
CONFIG_MOXA_INTELLIO=m
CONFIG_MOXA_SMARTIO=m
CONFIG_ISI=m
CONFIG_SYNCLINK=m
CONFIG_N_HDLC=m
CONFIG_RISCOM8=m
CONFIG_SPECIALIX=m
# CONFIG_SPECIALIX_RTSCTS is not set
CONFIG_SX=m
CONFIG_RIO=m
# CONFIG_RIO_OLDPCI is not set
CONFIG_STALDRV=y
CONFIG_STALLION=m
CONFIG_ISTALLION=m
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_PHILIPSPAR=m
CONFIG_I2C_ELV=m
CONFIG_I2C_VELLEMAN=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ELEKTOR=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m

#
# Mice
#
CONFIG_BUSMOUSE=m
CONFIG_ATIXL_BUSMOUSE=m
CONFIG_LOGIBUSMOUSE=m
CONFIG_MS_BUSMOUSE=m
CONFIG_MOUSE=m
CONFIG_PSMOUSE=y
CONFIG_82C710_MOUSE=m
CONFIG_PC110_PAD=m

#
# Joysticks
#
CONFIG_INPUT_GAMEPORT=m
CONFIG_INPUT_NS558=m
CONFIG_INPUT_LIGHTNING=m
CONFIG_INPUT_PCIGAME=m
CONFIG_INPUT_CS461X=m
CONFIG_INPUT_EMU10K1=m
CONFIG_INPUT_SERIO=m
CONFIG_INPUT_SERPORT=m

#
# Joysticks
#
CONFIG_INPUT_ANALOG=m
CONFIG_INPUT_A3D=m
CONFIG_INPUT_ADI=m
CONFIG_INPUT_COBRA=m
CONFIG_INPUT_GF2K=m
CONFIG_INPUT_GRIP=m
CONFIG_INPUT_INTERACT=m
CONFIG_INPUT_TMDC=m
CONFIG_INPUT_SIDEWINDER=m
CONFIG_INPUT_IFORCE_USB=m
CONFIG_INPUT_IFORCE_232=m
CONFIG_INPUT_WARRIOR=m
CONFIG_INPUT_MAGELLAN=m
CONFIG_INPUT_SPACEORB=m
CONFIG_INPUT_SPACEBALL=m
CONFIG_INPUT_STINGER=m
CONFIG_INPUT_DB9=m
CONFIG_INPUT_GAMECON=m
CONFIG_INPUT_TURBOGRAFX=m
CONFIG_QIC02_TAPE=m
CONFIG_QIC02_DYNCONF=y

#
# Setting runtime QIC-02 configuration is done with qic02conf
#

#
# from the tpqic02-support package. It is available at
#

#
# metalab.unc.edu or ftp://titus.cfw.com/pub/Linux/util/
#

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
CONFIG_SOFT_WATCHDOG=m
CONFIG_WDT=m
CONFIG_WDTPCI=m
CONFIG_WDT_501=y
CONFIG_WDT_501_FAN=y
CONFIG_PCWATCHDOG=m
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
CONFIG_I810_TCO=m
CONFIG_MIXCOMWD=m
CONFIG_60XX_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_MACHZ_WDT=m
CONFIG_INTEL_RNG=m
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_DTLK=m
CONFIG_R3964=m
CONFIG_APPLICOM=m
CONFIG_SONYPI=m

#
# Ftape, the floppy tape device driver
#
CONFIG_FTAPE=m
CONFIG_ZFTAPE=m
CONFIG_ZFT_DFLT_BLK_SZ=10240

#
# The compressor will be built as a module only!
#
CONFIG_ZFT_COMPRESSOR=m
CONFIG_FT_NR_BUFFERS=3
CONFIG_FT_PROC_FS=y
CONFIG_FT_NORMAL_DEBUG=y
# CONFIG_FT_FULL_DEBUG is not set
# CONFIG_FT_NO_TRACE is not set
# CONFIG_FT_NO_TRACE_AT_ALL is not set

#
# Hardware configuration
#
CONFIG_FT_STD_FDC=y
# CONFIG_FT_MACH2 is not set
# CONFIG_FT_PROBE_FC10 is not set
# CONFIG_FT_ALT_FDC is not set
CONFIG_FT_FDC_THR=8
CONFIG_FT_FDC_MAX_RATE=2000
CONFIG_FT_ALPHA_CLOCK=0
CONFIG_AGP=m
CONFIG_AGP_INTEL=y
CONFIG_AGP_I810=y
CONFIG_AGP_VIA=y
CONFIG_AGP_AMD=y
CONFIG_AGP_SIS=y
CONFIG_AGP_ALI=y
CONFIG_AGP_SWORKS=y
CONFIG_DRM=y
CONFIG_DRM_TDFX=m
CONFIG_DRM_GAMMA=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_MGA=m
# CONFIG_DRM_SIS is not set
# CONFIG_MWAVE is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#
CONFIG_VIDEO_PROC_FS=y
CONFIG_I2C_PARPORT=m

#
# Video Adapters
#
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_PMS=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
# CONFIG_VIDEO_ZORAN_DC10 is not set
# CONFIG_VIDEO_ZORAN_LML33 is not set
CONFIG_VIDEO_ZR36120=m
CONFIG_VIDEO_MEYE=m

#
# Radio Adapters
#
CONFIG_RADIO_CADET=m
CONFIG_RADIO_RTRACK=m
CONFIG_RADIO_RTRACK2=m
CONFIG_RADIO_AZTECH=m
CONFIG_RADIO_GEMTEK=m
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
CONFIG_RADIO_MIROPCM20=m
CONFIG_RADIO_MIROPCM20_RDS=m
CONFIG_RADIO_SF16FMI=m
CONFIG_RADIO_TERRATEC=m
CONFIG_RADIO_TRUST=m
CONFIG_RADIO_TYPHOON=m
CONFIG_RADIO_TYPHOON_PROC_FS=y
CONFIG_RADIO_ZOLTRIX=m

#
# File systems
#
CONFIG_QUOTA=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_ADFS_FS=m
# CONFIG_ADFS_FS_RW is not set
CONFIG_AFFS_FS=m
CONFIG_HFS_FS=m
CONFIG_BFS_FS=m
CONFIG_EXT3_FS=m
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_UMSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_EFS_FS=m
CONFIG_JFFS_FS=m
CONFIG_JFFS_FS_VERBOSE=0
# CONFIG_JFFS_PROC_FS is not set
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_CRAMFS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=m
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_MINIX_FS=m
# CONFIG_VXFS_FS is not set
CONFIG_NTFS_FS=m
# CONFIG_NTFS_RW is not set
CONFIG_HPFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVFS_FS=y
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
CONFIG_SYSV_FS=m
CONFIG_UDF_FS=m
# CONFIG_UDF_RW is not set
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
CONFIG_CODA_FS=m
CONFIG_INTERMEZZO_FS=m
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
# CONFIG_NCPFS_IOCTL_LOCKING is not set
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_ZISOFS_FS=m
CONFIG_ZLIB_FS_INFLATE=m

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
# CONFIG_MINIX_SUBPARTITION is not set
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_MDA_CONSOLE=m

#
# Frame-buffer support
#
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FB_RIVA=m
CONFIG_FB_CLGEN=m
CONFIG_FB_PM2=m
CONFIG_FB_PM2_FIFO_DISCONNECT=y
CONFIG_FB_PM2_PCI=y
CONFIG_FB_CYBER2000=m
CONFIG_FB_VESA=y
CONFIG_FB_VGA16=m
CONFIG_FB_HGA=m
CONFIG_VIDEO_SELECT=y
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_MATROX_G450=m
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_ATY=m
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_CT=y
CONFIG_FB_RADEON=m
CONFIG_FB_ATY128=m
CONFIG_FB_SIS=m
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_FB_3DFX=m
CONFIG_FB_VOODOO1=m
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FBCON_ADVANCED is not set
CONFIG_FBCON_MFB=m
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=y
CONFIG_FBCON_CFB32=y
CONFIG_FBCON_VGA_PLANES=m
CONFIG_FBCON_HGA=m
# CONFIG_FBCON_FONTWIDTH8_ONLY is not set
# CONFIG_FBCON_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Sound
#
CONFIG_SOUND=m
CONFIG_SOUND_BT878=m
CONFIG_SOUND_CMPCI=m
# CONFIG_SOUND_CMPCI_FM is not set
# CONFIG_SOUND_CMPCI_MIDI is not set
CONFIG_SOUND_CMPCI_JOYSTICK=y
CONFIG_SOUND_CMPCI_CM8738=y
# CONFIG_SOUND_CMPCI_SPDIFINVERSE is not set
CONFIG_SOUND_CMPCI_SPDIFLOOP=y
CONFIG_SOUND_CMPCI_SPEAKERS=2
CONFIG_SOUND_EMU10K1=m
CONFIG_MIDI_EMU10K1=y
CONFIG_SOUND_FUSION=m
CONFIG_SOUND_CS4281=m
CONFIG_SOUND_ES1370=m
CONFIG_SOUND_ES1371=m
CONFIG_SOUND_ESSSOLO1=m
CONFIG_SOUND_MAESTRO=m
CONFIG_SOUND_MAESTRO3=m
CONFIG_SOUND_ICH=m
CONFIG_SOUND_RME96XX=m
CONFIG_SOUND_SONICVIBES=m
CONFIG_SOUND_TRIDENT=m
CONFIG_SOUND_MSNDCLAS=m
# CONFIG_MSNDCLAS_HAVE_BOOT is not set
CONFIG_MSNDCLAS_INIT_FILE="/etc/sound/msndinit.b in "
CONFIG_MSNDCLAS_PERM_FILE="/etc/sound/msndperm.b in "
CONFIG_SOUND_MSNDPIN=m
# CONFIG_MSNDPIN_HAVE_BOOT is not set
CONFIG_MSNDPIN_INIT_FILE="/etc/sound/pndspini.bi n"
CONFIG_MSNDPIN_PERM_FILE="/etc/sound/pndsperm.bi n"
CONFIG_SOUND_VIA82CXXX=m
CONFIG_MIDI_VIA82CXXX=y
CONFIG_SOUND_OSS=m
CONFIG_SOUND_TRACEINIT=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_AD1816=m
CONFIG_SOUND_SGALAXY=m
CONFIG_SOUND_ADLIB=m
CONFIG_SOUND_ACI_MIXER=m
CONFIG_SOUND_CS4232=m
CONFIG_SOUND_SSCAPE=m
CONFIG_SOUND_GUS=m
CONFIG_SOUND_GUS16=y
CONFIG_SOUND_GUSMAX=y
CONFIG_SOUND_VMIDI=m
CONFIG_SOUND_TRIX=m
CONFIG_SOUND_MSS=m
CONFIG_SOUND_MPU401=m
CONFIG_SOUND_NM256=m
CONFIG_SOUND_MAD16=m
CONFIG_MAD16_OLDCARD=y
CONFIG_SOUND_PAS=m
# CONFIG_PAS_JOYSTICK is not set
CONFIG_SOUND_PSS=m
CONFIG_PSS_MIXER=y
# CONFIG_PSS_HAVE_BOOT is not set
CONFIG_SOUND_SB=m
CONFIG_SOUND_AWE32_SYNTH=m
CONFIG_SOUND_WAVEFRONT=m
CONFIG_SOUND_MAUI=m
CONFIG_SOUND_YM3812=m
CONFIG_SOUND_OPL3SA1=m
CONFIG_SOUND_OPL3SA2=m
CONFIG_SOUND_YMFPCI=m
# CONFIG_SOUND_YMFPCI_LEGACY is not set
CONFIG_SOUND_UART6850=m
CONFIG_SOUND_AEDSP16=m
CONFIG_SC6600=y
CONFIG_SC6600_JOY=y
CONFIG_SC6600_CDROM=4
CONFIG_SC6600_CDROMBASE=0
# CONFIG_AEDSP16_SBPRO is not set
# CONFIG_AEDSP16_MSS is not set
# CONFIG_AEDSP16_MPU401 is not set
CONFIG_SOUND_TVMIXER=m

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_LONG_TIMEOUT is not set

#
# USB Controllers
#
CONFIG_USB_UHCI=m
CONFIG_USB_UHCI_ALT=m
CONFIG_USB_OHCI=m

#
# USB Device Class drivers
#
CONFIG_USB_AUDIO=m
CONFIG_USB_BLUETOOTH=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_HP8200e=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDDEV=y
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
CONFIG_USB_WACOM=m

#
# USB Imaging devices
#
CONFIG_USB_DC2XX=m
CONFIG_USB_MDC800=m
CONFIG_USB_SCANNER=m
CONFIG_USB_MICROTEK=m
CONFIG_USB_HPUSBSCSI=m

#
# USB Multimedia devices
#
CONFIG_USB_IBMCAM=m
CONFIG_USB_OV511=m
CONFIG_USB_PWC=m
CONFIG_USB_SE401=m
CONFIG_USB_DSBR=m
CONFIG_USB_DABUSB=m

#
# USB Network adaptors
#
CONFIG_USB_PEGASUS=m
CONFIG_USB_KAWETH=m
CONFIG_USB_CATC=m
CONFIG_USB_CDCETHER=m
CONFIG_USB_USBNET=m

#
# USB port drivers
#
CONFIG_USB_USS720=m

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
# CONFIG_USB_SERIAL_IR is not set
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
# CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OMNINET=m

#
# USB Miscellaneous drivers
#
CONFIG_USB_RIO500=m

#
# Bluetooth support
#
CONFIG_BLUEZ=m
CONFIG_BLUEZ_L2CAP=m

#
# Bluetooth device drivers
#
CONFIG_BLUEZ_HCIUSB=m
CONFIG_BLUEZ_HCIUART=m
CONFIG_BLUEZ_HCIVHCI=m

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
CONFIG_DEBUG_BUGVERBOSE=y

IBM HEARS YOU by Anonymous Coward · 2002-01-15 04:08 · Score: -1, Offtopic

The Big Dog IBM hears you dude, don't worry man, stay 31337! :)

On developer spats and high drama by ajs · 2002-01-15 04:09 · Score: 5, Informative

Open Source's biggest PR dilema is this sort of argument.

Make no mistake, every company has developers that do this. There's two differences in the Open Source world: 1) you can't just fire an Open Source developer who won't "play ball" with management's edict 2) it's usually public.

These are actually both really good things. The fact that you can't silence someone leads to repeated analysis of a problem. OSS' biggest benefit is that it brings massive peer review to bare not just on the code, but on the process.

The fact that it's public feeds into that, and is equally good.

The problem is PR. The Linux kernel is starting to look like anarchy to non-developers. I suggest that the process works, so we should all take a deep breath and leave it be. However, we all need to take the front lines on PR. Spin is all-important. This is not a "spat" or a "fight", this is "parallel development" and "peer review". The joy of this kind of spin is that, unlike most spin, it's TRUE! This guy is pissed at Linus. Linus has dumped his code. Yet, the two of them keep working hard to meet their customers' demands and producing what they feel is the best possible product.

Please, don't foster the idea that we're a bunch of anarchists producing code that's any less functional than the rest of industry, because quite the opposite is true.

Re:On developer spats and high drama by bryanbrunton · 2002-01-15 05:11 · Score: 2, Insightful

>> The Linux kernel is starting to look like anarchy to non-developers.

What data points do you base this observation on? You believe that there is an appearance of linux kernel development becoming increasing chaotic?

You are very wrong. A true analysis of the progress of linux kernel development would show a measurable decrease in the level of chaos in the system.

The past few years have seen an increase in paid full time linux kernel hackers. These hackers are generally tasked with working on a specific sub-system and/or providing source control management. The Marcelos and Coxes of the world are increasing in number and their work is really paying off in a more ordered kernel development process.

Even the volunteers like the kernel janitors work in a more structured and orderly manner.

Perhap someone should write a white paper detailing the main kernel hackers and the evolution of the kernel development process. THAT would make for good PR.
Re:On developer spats and high drama by MikeBabcock · 2002-01-15 06:35 · Score: 2

Hmmm ... I remember a certain Rasterman disappearing from RedHat ... and then E was no longer part of Gnome (although I use it because its dramatically better than the alternatives in my opinion).

It happens.

--
- Michael T. Babcock (Yes, I blog)
Re:On developer spats and high drama by stitch · 2002-01-15 09:50 · Score: 1

"Please, don't foster the idea that we're a bunch of anarchists producing code that's any less functional than the rest of industry, because quite the opposite is true."

by the opposite you mean "...we're a bunch of anarchists producing code that's MORE functional than the rest of industry..."

You seem to labour under the misapprehension that anarchy is an arrangement that will always fail. Anarchism is not a bunch of hooligans smashing things up, it is a reasonable and well thought out political theory that has had its practical successes.

See the writings of Proudhon, Bakunin, Kropotkin, etc.
Re:On developer spats and high drama by ajs · 2002-01-15 10:41 · Score: 2

You believe that there is an appearance [...] You are very wrong. A true analysis of the progress

Ok, so you're argument is that the perception is not one of chaos because the perception does not match the reality of the situation?

I'm just trying to understand, since that would seem to be a self-contradicting statement.

Yes, Linux kernel development is moving along just fine. Yes, it's very well structured. But I work in a Linux shop, and let me tell you what the perception of the folks we deal with is: "Oh, Linux. Isn't that the bunch of kids that are always arguing and forking projects?" I know that that's bunk, but most folks don't.

Which point of view do you think Microsoft is working hard to portray?

Good interview, fun drama by f00zbll · 2002-01-15 04:09 · Score: 4, Insightful

Lets get real for a second. The linux community isn't the only OS with politics behind it. God knows there's probably more politics behind IRIX, Windows and AIX.

I strongly feel that honesty wins in the end, because people aren't stupid. No one believes that IBM or Microsoft is one happy camp singing "we are the world."

It's great there is a lot of attention on the VM and intense effort to make it better. I have no doubt linux and Rik are professionals and have no problems putting politics aside to get the job done. That is after all part of being a professional. Rik makes some good argument and given enough time and money he'll build the VM of his design. Will it matter 10 years from now? Most likely not. Development will continue and linux will get better. Butting heads is part of the fun, because without conflict people tend to stagnate.

Re:Good interview, fun drama by laserjet · 2002-01-15 05:28 · Score: 1, Flamebait

I liken this to Vi vs. Emacs. Both suck for usability (admit it), and to this day we continue to butt heads about them. I use vi, and like it more than Emacs, but I am adult enough to admit they both have some of the worst user interfaces available today.

not trolling, or starting a debate, just being honest.

--
Moon Macrosystems. Sun's biggest competitor.
Re:Good interview, fun drama by Anonymous Coward · 2002-01-15 08:10 · Score: 0

...and sometimes, at Microsoft or anywhere else, I'm sure it comes down to do you want to argue with billg, steveb et al? over a technical issue or do you just roll over and keep working?

Developer politics by Achilleas · 2002-01-15 04:10 · Score: 0

Since Linux is about choice, both VMs should be included, and the admin should choose the one that is most beneficial for the type of installation (desktop, server, etc).

[ot] what a bummer.... by msouth · 2002-01-15 04:19 · Score: 0, Offtopic

he's asleep for a hundred years and wakes up to find out that they have completely changed the spelling of his name!

--
Liberty uber alles.

Rik's patches by Anonymous Coward · 2002-01-15 04:20 · Score: 0

I've heard several times that Linus refused
to apply patches for Rik's VM before deciding
to switch to a different VM. My question is
why did Linus refuse to apply these patches?
Obviously he was unhappy with the VM, so you
would think he'd make sure all of Rik's patches
got incorporated into the kernel. Does anyone
know why he refused to apply the patches?

Re:Rik's patches by Anonymous Coward · 2002-01-15 08:15 · Score: 0

Because he's a narrow-minded asshole. Duh.

Linux news site running IIS? by mikech@rbsgi · 2002-01-15 04:24 · Score: 2, Interesting

I know that it has nothing to do with the topic...
But while waiting for the page to load, I noticed that the extension was "htm" which lead me to lookup "linux.html.it" using netcraft and discovered it running IIS. Go figure?

Demonstration of Rik's immaturity by dgb2n · 2002-01-15 04:29 · Score: 2, Insightful

Label this a flame if you want but I was absolutely disgusted by the tone and tenor of Rik's responses in that article. Regardless of the technical merits of his code or algorithms, Rik's repeated attacks on Linus will certainly not move the operating system forward.

When the author of the article ended with "Thank you for your kindness and the opportunity to get to know you better", I almost fell out of my chair laughing. The only thing that stopped me was that Rik's behavior really isn't funny. It isn't professional and it has no place in the open source or any other community. It speaks volumes about Rik's emotional maturity or more accurately his lack thereof.

Re:Demonstration of Rik's immaturity by Erik+Hensema · 2002-01-15 04:57 · Score: 4, Interesting

Somebody has to speak up against Linus. Linus is not a god. The man makes mistakes. And over the last view years it becomes increasingly a problem that "Linus doesn't scale".

Linus however continues to develop the kernel pretty much the same way he started doing it ten years ago. And not many people think that's a problem. Rik does (AFAIK). And I tend to agree with Rik: the current system just isn't working very well. It's not very bad, but it certainly isn't optimal, IMHO.

However, remaining silent doesn't solve the problem. Somebody has to speak up.

--
This is your sig. There are thousands more, but this one is yours.
Re:Demonstration of Rik's immaturity by anpe · 2002-01-15 05:21 · Score: 2, Insightful

I think that the matter is the _tone_ Rik uses to attack Linus.

Remebers me this article : Prima donna syndrome : Managing the employee who's too talented for rules
Re:Demonstration of Rik's immaturity by Anonymous Coward · 2002-01-15 05:21 · Score: 0

Label this a flame if you want but I was absolutely disgusted by the tone and tenor of Rik's responses in that article

Translation: I can't believe someone would have the gall to say anything negative about Linus
Re:Demonstration of Rik's immaturity by Courageous · 2002-01-15 05:25 · Score: 2

However, remaining silent doesn't solve the problem. Somebody has to speak up.

Public name-calling (e.g., "Asshole" was the exact word) is a sign of immaturity. But then again, not that suprising. As one poster aptly put it, "kernel developers have egos the size of small countries."

C//
Re:Demonstration of Rik's immaturity by Zog · 2002-01-15 05:28 · Score: 4, Interesting

RTI - Read The Interview.

...Rik's repeated attacks on Linus will certainly not move the operating system forward.

Rik was interviewed in order to get insight into how he thinks/sees things, no? So if he doesn't like the way Linus does things, is he not at liberty to say so? (also, see quote below about still having respect for Linus in spite of their disagreements/conflicts)

Rik's behavior really isn't funny... It speaks volumes about Rik's emotional maturity or more accurately his lack thereof.

Rik Say:
With Linus out of the way, I can make a good VM. I no longer have to worry about what Linus likes or doesn't like. ... Yes, though I guess I have to add that I have a lot of respect for Linus. He is a very user unfriendly source management system, but he is also very honest about it.

I don't quite think that qualifies as immature - granted, there is a lot of conflict going on, but they still have respect for each other, even if Rik doesn't like to work with him, and there's not really anything showstopping about it. The VM situation wasn't pretty, but it's being resolved.
Re:Demonstration of Rik's immaturity by mark_lybarger · 2002-01-15 06:04 · Score: 1

I didn't notice any problem with the tone of the article. Rik definately doesn't come across as prima donna. the interview emphisized strongly that linus (and the linux kernel development model) could use some serious improvement. bug fixing patches to major portions of the kernel NEED to be applied. lost or overlooked email just doesn't cut it. I think that lots of times the "younger" people pay less attention to politically corectness, feel-good warm overs, and the such. Linus seems very similar in his interviews. Linux seem to be more of a get the job done kinda person, but sometimes shoves off any politically touchy questions. Rik definately wants to get the job done, but also doens't hesitate to speak up when he sees an issue. Now.. will anyone listen seriously? Guess we'll have to wait and see.
Re:Demonstration of Rik's immaturity by MikeBabcock · 2002-01-15 06:31 · Score: 2

Example:

Interviewer: You and Linus don't seem to be getting along ...

Me: I'm sorry but I don't think I should comment on that; that's between Linus and I and we're working on it.

--
- Michael T. Babcock (Yes, I blog)
Re:Demonstration of Rik's immaturity by Zog · 2002-01-15 08:15 · Score: 1

It is better that way, I agree :)

It's just a weird situation with all the discussions and flames being out in the open all the time; I guess it to some extent dulls one's sense of keeping certain things between two people. Also, ego tends to have a factor in stuff like this (it's been said that kernel hackers tend to have the egos of small countries; I think small continents would be far for accurate for the comparison ;) )
Re:Demonstration of Rik's immaturity by ahde · 2002-01-15 19:11 · Score: 2

the difference is that most of Linus' barbs are jokes. Lots of people don't get them, but there isn't very often malice. Political correctness is aimed at staving off humor (nobody can be funnier, or smarter than someone else), not rudeness.

Fear Factor by ChaoticCoyote · 2002-01-15 04:34 · Score: 5, Insightful

An honest environment -- such as fostered by "free" software -- is both good and bad. On one hand, I (as a programmer) am comforted to read the kernel mailing list and other resources that let me know exactly what is happening with my tools. I don't need to wonder what's happening with "free" software -- and this is more comforting to an engineer like myself than is the closed-door, silence-is-golden, hide-the-bugs policy of a Microsoft.

On the other hand: Show this interview to an MIS manager who need 24/7/365 reliability, and she is going to be very nervous about deploying a Linux-based solution. You can talk until you're blue in the face about reliable distros and the open road to sofwtare quality -- what the MIS/corporate person sees is chaos and feels a lack of COMFORT .

"Out of sight, out of mind" is a philosophy many people adhere to, especially when dealing with complex issues they can not or do not want to grasp. From waste storage in Nevada to the the war in Afghanistan, most people lack the time and initiative to understand what is really happening; they go on appearances and marketing, and ignore complex and disturbing facts.

Technology is no different. The MIS manager doesn't want to hear about VM conflicts or file system bugs or different kernels -- such issues are beyond their capability and desire to understand. Buying Microsoft is (or was, until recently) comforting, because no one ever saw the internal debates and code battles and what-not that any development team expresses. Even recent security disclosures about WinXP are unlikely to shake the faithful -- but those same people will run in fear from the blunt honesty of Linux.

Ignorance may be bliss, but it can also get you killed. I know people whose lives depend on cars, but they have no knowledge of how to check the oil. Most MIS managers simply want to drive software; if it looks good (like a Jeep Liberty), they don't pay attention to whether it is safe (the Liberty performs poorly on crash tests).

I doubt, however, we're going to change human nature -- and I'd rather have spirited debate and even some nasty contention if it means that people are striving to make Linux the "best" it can be.

--
All about me

Re:Fear Factor by cornjones · 2002-01-15 05:18 · Score: 1

so what is your solution? don't talk about it? This is an issue being discussed on developer mailing lists. Slashdot is probably about as mainstream as this issue gets. If your hypothetical MIS manager is really looking to appearances and marketing then he will be reading eweek and redhat press releases (if that). They won't mention this issue. If he is reading the kernel dev lists or pouring through random linux sites he probably is savvy enough to understand a bit more about the issue.

It is an important issue to thosed involved and IMHO it is being discussed in the right areas. (Although I think it has gotten more attention outside of the list than it deserves)

Bug posts by zmokhtar · 2002-01-15 04:40 · Score: 1

Several times the article mentioned the automated posting of patches and bug reports. Wouldn't a slashdot type system solve some of these problems of an over busy linux mailing list?

--
Why aren't we told when editors moderate our posts?

OOM Killer must die by Salamander · 2002-01-15 04:43 · Score: 5, Informative

Rik is an extremely bright (and likeable) guy, but his adherence to the OOM killer concept is disappointing. I've seen a lot of dumb ideas gain currency in the computing community or some part of it; OOM killer is the dumbest. If your process was allowed to exist in the first place, it should not be killed by the VM system. The worst that should happen is that it gets suspended with all of its pages taken away. If that doesn't free up any memory then neither would killing it (modulo some metadata - read on). If there are other processes waiting for the one that's suspended, then eventually they'll go to sleep, their pages will be released, and the suspended process will wake up - which won't happen if you killed it. There are only two differences between the two approaches:

Suspension does not take irrevocable action; the suspended process can still be restarted.
Suspension bears the cost of retaining the metadata for the suspended process so it can be restarted.

The usual whine from OOM-killer advocates is that you can still get into a situation where all of that retained metadata clogs up the system and essential system functions can't allocate pages. However, that's preventable too. All you need to do is preallocate a special pool of memory that's only available for use by those essential system processes - either individually or collectively. The size of that pool and the exact details of how it gets allocated (e.g. which processes are considered essential) could be treated as site-specific tuning parameters. The same idea can then be further generalized to allow definition of multiple private pools, creating a semi-hard barrier between different sets of tasks running on the system (if you want one; the default pool is still there otherwise). This actually fits in very nicely with other things like processor affinity and NUMA-friendly VM, which I know because I once worked on a kernel that had all of these features.

In short, there's no need for the OOM killer. Plenty of systems, many of which handle extreme VM load much better than Linux, have been implemented without such a crock. Rik contends that a lot of people make suggestions without actually understanding the problem, and he's right, but I also submit that sometimes he also rejects suggestions from people who do know what they're talking about. This row has been hoed before, and Rik's smart enough that he should know to avoid the NIH syndrome that afflicts so many of the other Linux kernel heavyweights.

--
Slashdot - News for Herds. Stuff that Splatters.

Re:OOM Killer must die by _xeno_ · 2002-01-15 05:14 · Score: 4, Interesting

This may just be my misunderstanding, but the way I understood it was that the OOM killer takes effect when there is no more memory available at all. You say "The worst that should happen is that it gets suspended with all of its pages taken away." but I have to wonder what the process is going to do when it starts up and has no pages - it'll crash instantly, so why not kill it, right?
Or did you mean that "the process's pages will be swapped?" Even if you did mean that, my understanding is that the OOM killer only takes effect when there is no memory space left - including swap. In this scenario, there isn't much to be done should the system need more memory to continue - you either kernel panic or you find some process to kill and kill it. In an extreme circumstance like OOM on a kernel alloc, I see nothing wrong with deciding to kill a process. I really don't see how "suspending" on a process solves memory issues since it still needs its pages somewhere...
My understanding was that the idea behind the OOM killer was to prevent the kernel from panicing and instead leave a working system which needs to have its memory problems worked out. I could be wrong since I haven't really looked into the OOM killer and when it's invoked.

--
You are in a maze of twisty little relative jumps, all alike.
Re:OOM Killer must die by Anonymous Coward · 2002-01-15 05:20 · Score: 2, Insightful

While I'm not entirely convinced that overcommit and OOM-killer are the right approach, I don't understand how your proposal solves anything.
If your process was allowed to exist in the first place, it should not be killed by the VM system.
So we know before a process gets to execute exactly what its memory usage profile is? A VM is called upon to predict the future all the time, but this is ridiculous. I can understand that we'd rather not start a process if we're going to kill it off later, but just how are we supposed to make that determination? I've got 3/4 of my memory free. Of course the system will let me start another process --we're nowhere near OOM. But the new process proceeds to allocate and allocate and allocate... And now we really are OOM. What now? What have we solved?
The worst that should happen is that it gets suspended with all of its pages taken away.
"taken away"? Where do they go? You obviously can't drop them on the floor if you're planning to unsuspend the process at some point. You can drop the executable pages, but if we're in an OOM condition we've already done that. And we're out of swap, so we're not putting the pages there, either.
If there are other processes waiting for the one that's suspended, then eventually they'll go to sleep, their pages will be released, and the suspended process will wake up.
Now *that* is a chain of events which makes absolutely no sense to me. I repeat: *We* *are* *OOM*. Where do their pages go and how, exactly, does this allow the VM to make some progress without deadlocking the system?
Color me skeptical.
Re:OOM Killer must die by puetzk · 2002-01-15 05:26 · Score: 3, Interesting

there is indeed a /proc entry (/proc/sys/vm/overcommit_memory) to disable VM overcommit. In which case, it's impossible to reach the scenario where the OOM is needed (some process gets a null from malloc instead).

However, as it stands, linux by default is willing to overcommit (via copy-on-write). This is a good, and beneficial thing - when one forks, the pages don't need to be allocated and copied until they are changeed (as most never are). This saves memory, saves time, and vastly improves scalability of many tasks. Ditto for many, many other situations. But, it means when everything goes to hell in a handbasket, you have promised memory to processes that you simply do not have, and you've already told them they can have it. So you have to produce something, and that means someone gets tossed.

as far as reservving special memory, the mlock call does just that. It tells the VM that these pages can't be messed with, they need to be ready immediately.

You can't just suspend, because you already did that - OOM doesn't occur until you are also out of swap. OOM is a last-ditch, we have *nowhere* left to put this. If you ever see OOM, you need more swap. Simple as that.

(Now, one thing that would be very nice would be dynamically resizing swapfiles, so that if you had disk space left not currently being used for swap, the swaparea could grow. But even then, there is such a thing as out of disk as well. The only way to completely avoid OOM is to avoid overcommit/copy-on-write and allocate any pages that could potentially be used by a call every time (even when, as in fork/exec they very rarely are). That way you could make the calls fail in this worst of worst-cases and the applications could respond.

--
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Re:OOM Killer must die by Pussy+Is+Money · 2002-01-15 05:32 · Score: 0

The parent poster is right. Just suspend processes which require more memory than can be made available. Use a preallocated pool of memory to store the suspended process information. Then wait for memory to become available again, perhaps writing messages to syslog so the sysadmin can take action to expediate this process. In the worst case nothing ever happens, which is better than the alternative, namely having processes killed basically at random (when the heuristics become complex enough, the result becomes indistinguishable from chance).
If you still do not agree, think long and hard about the scenario sketched by the poster above:
If there are other processes waiting for the one that's suspended, then eventually they'll go to sleep, their pages will be released, and the suspended process will wake up - which won't happen if you killed it.)

--
Pushin' 'n dealin', shovin' 'n stealin'
Re:OOM Killer must die by Salamander · 2002-01-15 06:01 · Score: 2

I have to wonder what the process is going to do when it starts up and has no pages - it'll crash instantly, so why not kill it, right?

If you can't start the process, fork() should fail. That way the caller gets an error code and has some hope of doing something genuinely useful.

Even if you did mean that, my understanding is that the OOM killer only takes effect when there is no memory space left - including swap.

What I'm saying is that you should never wait that long to detect that condition. Sure, you can disable overcommit entirely, but that's pretty inflexible. Overcommit is a good thing, if it's handled properly. Some people would rather not, but if you want you should be able to walk out on that narrow ledge, right up to the point where you can't go any further, and then stop. Gracefully. OOM-killer is like taking you right up to the edge of the cliff, then throwing you off and saying it's your own damn fault.
the idea behind the OOM killer was to prevent the kernel from panicing...

Fine, but there are other ways as well.

...and instead leave a working system

If that's the goal, it fails, because it makes no such guarantee that your system will be working in any intuitive or useful sense of the word.

--
Slashdot - News for Herds. Stuff that Splatters.
Re:OOM Killer must die by Salamander · 2002-01-15 06:20 · Score: 4, Informative

So we know before a process gets to execute exactly what its memory usage profile is?
Please don't construct strawmen. Oh wait, that's not just a strawman, it's also circularity. You're assuming that the OOM killer exists, then using that to "prove" that an alternative approach is impossible to implement. Well yeah, an alternative system that both does and does not incorporate the OOM-killer concept is impossible. Congratulations. Well done.

What I'm really saying is that the VM system should ensure that it has other means to deal with memory exhaustion. Disallowing overcommit altogether is one approach, and that has proven quite acceptable for many systems, but there are plenty of other approaches as well. I've briefly sketched out only one; look up the others yourself (the information is available in plenty of places including some OS textbooks).

"taken away"? Where do they go?

The phrase "suspended with all of their pages taken away" (which is what I said) includes the case where the pages have already been taken away. English 101.

As for where they go, the obvious answer is not the general swap area, because that's already full. However, that doesn't preclude the existence of a secondary (actually tertiary) swap area that exists only for this purpose. It could also be a percentage of the general swap area, which starts to look very much like the memory-pressure code in the very highly regarded FreeBSD VM, or Solaris, etc. The point is that there's a middle ground between "no overcommit at all" and "if you allow overcommit we might shoot you in the head just because we feel like it".

Color me skeptical.

Skepticism is one thing; strawmen and circularity are another. I'm skeptical about the need for an OOM killer.

--
Slashdot - News for Herds. Stuff that Splatters.
Re:OOM Killer must die by MikeBabcock · 2002-01-15 06:27 · Score: 2

When process A tries to write to the memory it was given but that memory isn't actually available, suspend it. Suspend it _before_ actually allocating the memory that it thinks it has.

Put into motion the required steps to make more memory available (suspend things as necessary) and allow process A to continue if and _only_ if that memory is actually allocatable.

If desired, have a timeout period after which the process is killed. I don't see how that's worse than just killing the process.

--
- Michael T. Babcock (Yes, I blog)
Re:OOM Killer must die by Elladan · 2002-01-15 06:35 · Score: 3, Informative

Your scheme won't work. Think about it.
The OOM killer is triggered when the system is completely out of all memory, including swap, and a process (any process, not just some ram hog) tries to allocate more. That allocation request cannot complete, so the kernel needs to do something else. Note that it can't fail the request, because it already passed it due to overcommit.
The OOM killer approach is to find a process that looks ripe and get rid of it. Thus, stability is restored.
Your approach is to freeze the process that wanted a little bit more ram. What do you hope to gain by this? Well, presumably, you think that some other process is going to release some memory and allow the first one to complete. As should be obvious, this may not happen. In fact, it probably won't. What you'll end up with is a dead system with a lot of frozen processes. If you're careful, root might still be able to get in on the console to kill some stuff or link in more swap, but that's about it.
For all practical purposes, the system is hosed.
Your scheme has the advantage for a computation server that the administrator might be able to link in some more swap to complete a computation, but for normal uses, it's just a hang. The OOM killer approach is to attempt to blow away the memory hog and keep the system operational, without administrator intervention.
The other approach, of course, is to get rid of overcommit entirely. People wouldn't like this too much, since they'd need a lot more swap space.
Re:OOM Killer must die by The+Pim · 2002-01-15 06:38 · Score: 2

As for where they go, the obvious answer is not the general swap area, because that's already full. However, that doesn't preclude the existence of a secondary (actually tertiary) swap area that exists only for this purpose.
If you have enough swap space (whether you call it "tertiary" or not) for all writable memory, you're not overcommitting. By definition.
PS. It's funny that you accuse Rik of NIH, because his VM is strongly influenced by FreeBSD's, and receives praise from that camp. Indeed Rik is usually the one making NIH accusations.

--

The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Re:OOM Killer must die by oldmanmtn · 2002-01-15 06:59 · Score: 1

I've got 3/4 of my memory free. Of course the system will let me start another process --we're nowhere near OOM. But the new process proceeds to allocate and allocate and allocate... And now we really are OOM. What now?

Stop allowing the process to allocate before you are out of memory. If you fall below a certain threshold (leaving yourself some headroom for root processes), simply return -1 for brk() calls. At that point, it is up to the application to run with fewer resources, or to exit.

It's not quite as simple for c-o-w faults, but it's not that much harder. If a user process triggers a c-o-w fault and the number of free pages has fallen below a certain threshold, simply let that process hang until free memory increases again.

Allowing processes to hang while waiting for free memory obviously introduces the possibility of deadlock. So, you always have to leave enough free pages available for root to get in there and start killing off non-root processes. You can certainly argue that this is just to OOM killer with a different name, but adding administrative discretion to the process makes the OOM killing approach more reasonable.

Now, if you have root processes that consume excessive memory, you are screwed. But as long as 'root' exists, you can always get screwed by ill-behaving root processes.

--
- Old Man of the Mountain ---- "I want to disturb my neighbor"
Re:OOM Killer must die by _xeno_ · 2002-01-15 07:09 · Score: 2

I have to wonder what the process is going to do when it starts up and has no pages - it'll crash instantly, so why not kill it, right?
If you can't start the process, fork() should fail...

I meant "resume," not start - sorry about the confusion... (as in, resume the suspended process that you said should be suspended to recover memory). In other words, you suggested that a process should be suspended in an OOM situation. When suspended, however, the pages can't just disappear, because the application still needs them.
I think you're talking about an over-committed application where the process is suspended because it tried to write to a page that hasn't been copied yet. (In other words, process A forks process B which does nothing for a while and then starts doing some massive changes to memory structures that it was reading off of process A's memory space which causes a page fault and causes a new page to need to be allocated, which fails due to OOM.)
That sounds like a good idea as a method to potentially help avoid OOM, but I can still invent a scenario where it doesn't work. (For example, say the X-server gets suspended, and therefor the various clients get suspended waiting for the local socket to send an event, leaving only login running on other ttys - not enough memory to exec a new shell, and therefore a useless system.)
Even with preventative OOM measures, it's still possible to run into an OOM situation, and when the situation arises, there needs to be a way to handle it. OOM killer, assuming it's sophisticated enough, is one way of ensuring that the box doesn't just grind to a halt and panic.
If that's the goal [preventing the kernel from panicing], it fails, because it makes no such guarantee that your system will be working in any intuitive or useful sense of the word.

Beats the Black Screen Of Panic, Linux's version of the Blue Screen Of Death... (unless INIT dies (which panics anyway...) or X dies (which locks display/keyboard) or login dies or ...)
Bottom line, OOM is a pretty drastic state which I have yet to ever reach (although I've come close with Unreal Memory Leak Tournament). If you hit OOM, something needs to be done, and OOM killer is better than just panicing and causing everything to be lost.

--
You are in a maze of twisty little relative jumps, all alike.
Re:OOM Killer must die by Kopretinka · 2002-01-15 07:26 · Score: 1

But you can't just suspend the processes that hog the memory because you are already in a situation where you don't even have any free swap. Therefore the dirty pages would just stay in memory.
You could save some memory in this way but all such situations would require the attention of either the process's owner (to kill or resume it) or of the admin in case the owner is unavailable.
OK, OOM killer might become configurable (which it may be already, I don't know), but it should at least be an option.

--
Yesterday was the time to do it right. Are we having a REVOLUTION yet?
Re:OOM Killer must die by Salamander · 2002-01-15 07:26 · Score: 5, Interesting

If you have enough swap space (whether you call it "tertiary" or not) for all writable memory, you're not overcommitting. By definition.

You might (or might not) be overcommitting. Up to you. However, even if you are, you're not waiting until the last second and then going postal instead of taking concrete steps sooner to avoid total memory exhaustion. For example you could say that, once you start dipping into the overcommit pool, fork() will start failing but existing processes can continue. You could say that only certain processes that are being allowed to run to completion will be able to allocate new swap space; anyone else will just get suspended the first time they try. Once you have set a high watermark somewhere short of total exhaustion, you can do any number of things, even if you're overcommitting. Some of those measures are pretty drastic, but still better than the OOM killer.
To a certain extent, perhaps, these "softer" approaches just slow down what might be an inevitable march to OOM. In theory, you could still reach the total-exhaustion deadlock that OOM-killer is supposed to deal with, although it really doesn't because it doesn't in any way guarantee that your system will really be any more useable than if the deadlock had occurred. In practice, though, you'd be hard pressed to find a system that (a) allows overcommit, which is only necessary with VM systems that are broken (wrt how much swap they allow) to start with, (b)takes such drastic measures before going OOM, (c) does in fact hit OOM anyway, and (d) would benefit from an OOM killer if it had one. Without such an existence proof, claims that an OOM killer is necessary are pretty bogus.
As I've said, these aren't new ideas just off the top of my head. These are approaches that are proven to work. Ask yourself: how is it that so many systems get by just fine without an OOM killer? There are answers out there.

It's funny that you accuse Rik of NIH

Actually I didn't. I accused other Linux kernel hackers of NIH, and tried to warn Rik about becoming more like them. I know Rik's smarter than that, but sometimes even smart people submit to "common nonsense".

--
Slashdot - News for Herds. Stuff that Splatters.
Re:OOM Killer must die by dramaley · 2002-01-15 08:16 · Score: 1

>The other approach, of course, is to get rid of
>overcommit entirely. People wouldn't like this too
>much, since they'd need a lot more swap space.

Hard drive space is cheap. I'd rather have to allocate a couple GB more swap than have random processes killed off in an OOM situation.

--
----- "I'm still sane on three planets and two moons."
Re:OOM Killer must die by jgerman · 2002-01-15 09:14 · Score: 2

This topic is kind of like abortion for me, I just can't decide which way I feel, however your statement:
If that doesn't free up any memory then neither would killing it (modulo some metadata - read on).
Is simply not true, any process may grow over time without executing a single fork, and force the system out of total memory, in that case killing the process will free up memory. I'm not saying that an OOM killer is the right way to go but you definitely need to address this part of your argument if you want to convince anyone that it's valid.

--
I'm the big fish in the big pond bitch.
Re:OOM Killer must die by Todd+Knarr · 2002-01-15 09:55 · Score: 2

I think you're forgetting one thing. We've already swapped out everything we can, physical RAM is full, the swap space is full, and something still wants more memory. So, we suspend something. OK, what do we do with it? We can't swap it out, no swap space to put it in. If we can't swap it out, how do we free up any of it's pages? And if we can't free up any pages, how do we satisfy the process that wants more memory?

I don't like the OOM killer, but when you're in that tight a bind there's not a lot of better options.
Re:OOM Killer must die by Anonymous Coward · 2002-01-15 11:04 · Score: 0

(although I've come close with Unreal Memory Leak Tournament)

I have had the OOM killer save me from Unreal Tournament (although having Mozilla running in the background didn't help at all). I was worried that I might have to reboot, but the OOM killer came to the rescue. It didn't kill all of the UT processes, and it also killed one of the java_vm processes from my Mozilla, but it was enough to get me a login prompt so I could finish the job.
Re:OOM Killer must die by Pussy+Is+Money · 2002-01-15 13:14 · Score: 0

That sounds like a good idea as a method to potentially help avoid OOM, but I can still invent a scenario where it doesn't work. (For example, say the X-server gets suspended, and therefor the various clients get suspended waiting for the local socket to send an event, leaving only login running on other ttys - not enough memory to exec a new shell, and therefore a useless system.)
But obviously the reason why the X server had to be suspended in the first place is because there is not enough memory. But why is there not enough memory? Because some process has allocated it. Now why the assumption that this process will never release the memory again? Most likely it will. And in the case where it doesn't, why not preallocate a chunk of memory as scratch space, so that it can be guaranteed that there is always enough memory to spawn another shell? You might even make it possible for the operator to selectively grant usage of the scratch space to memory starving processes, allowing them to complete gracefully, thus easing the memory pressure. As the original poster said, how much space is used as scratch space and which processes can access this scratch space could be site specific tunable parameters.

--
Pushin' 'n dealin', shovin' 'n stealin'
Re:OOM Killer must die by Elladan · 2002-01-15 13:36 · Score: 1

Then do so. The OOM killer (should) only kick in when you're completely out of ram+swap. If you link in a lot of swap space beforehand, it shouldn't take effect.
What you gain by getting rid of overcommit is the ability of user programs to actually fail memory allocation attempts when there's no ram left, instead of having the OS fail them later when the lazy VM gets around to it. This is conceptually somewhat nice, but since there are basically no pieces of software in existence that know how to handle these errors in a reasonable way, it's not very useful in practice.
What you gain by having overcommit is that you can use memory more efficiently, and more quickly. The downside is that when the system runs out of memory, the kernel has to be the one to decide what to do, instead of letting user programs deal with it. The OOM Killer is the kernel's method of dealing with the problem.
Keep in mind here that the OOM Killer in recent kernels has been rather buggy, with an irritating problem of killing processes for no good reason. So, you might see it killing gimp on you when you have hundreds of megs of ram free. A non-buggy OOM Killer should only kill processes when the system's memory has been completely exhausted by some monster ram hog. So to understand the idea properly, imagine that it only kills StarOffice.
Re:OOM Killer must die by Bitmanhome · 2002-01-15 15:28 · Score: 4, Insightful

What the hell, I'll join the fray. You're spreading a huge amount of lies and FUD, and doing it VERY LOUDLY. Unfortunately, volume doesn't make up for sense.

First off, you need to study your own subject line: OOM Killer. OOM means out of memory. It does not mean low memory; it does not mean "maybe the admin can link in some more swap;" and it does not mean "move pages into a protected buffer." It means out of memory: there is no memory left. Anywhere.

You say:

If your process was allowed to exist in the first place, it should not be killed by the VM system.
then you say:

So we know before a process gets to execute exactly what its memory usage profile is?
Make up your mind dude -- which side are you on? Hint: Your second statement is correct, sarcastic as it was. We can't know the true memory behavior of a process ahead of time, so we can't block processes that are going to become too large.

Next you say:

The worst that should happen is that it gets suspended with all of its pages taken away.
Those pages contain data, they cannot be taken away. The must be moved somewhere .. got any ideas?

... a secondary (actually tertiary) swap area that exists only for this purpose.
Ah, your fingers are moving, but you don't understand the words. This is still swap space; the label is meaningless. And if we have swap available, then we're not out of memory, are we? This is a low memory condition, and is irrelevant to this discussion.

Okay, so how about:

... a special pool of memory that's only available for use by those essential system processes - either individually or collectively.
Once again, you use the term without understanding it. This is called memory (as you said,) and if there's some left, then we're not out of it, are we? Once again, this is a low memory condition, and is irrelevant to this discussion.

This next statment needs to be pulled apart, as you try to make two points with it:

Plenty of systems ... handle extreme VM load much better than Linux ...
Agreed, but we're not talking about "extreme VM load", are we? We're talking about out of memory conditions. No memory left. Anywhere.
Plenty of systems have been implemented without such a [patch].
Sure, but these systems have been hand-tuned to avoid running out of memory in the first place. Is this a good thing? Let's see:

In short, there's no need for the OOM killer.
Oddly, you first said "must die," but now say "no need," but I'm willing to ignore that. Ideally, a system should never run out of memory. But how can you know your machine is safe? After all, you can never know the memory requirements of a program ahead of time. So you can either throw excessive amounts of resources at your machine, or you can add support for low-memory and out-of-memory conditions. Your ideas for low-memory problems may be good, but they're not relevant here.

So the only question is this: Is an OOM killer worth the effort? OOM killer performs a partial system shutdown, allowing reletively quick recovery. This might be valuable for servers, but for single-user computers, it's usually easier to just reboot, especially since the machine will be desperately thrashing by that point.

Is an OOM killer worth writing? We're not paying Rik, so that's up to him. If you want low-memory conditions handled better, pay up, or write it yourself.

Rik contends that a lot of people make suggestions without actually understanding the problem...
Look in the mirror, dude -- that's you!

-B

--
Not that this wasn't entirely predictable.
Re:OOM Killer must die by Inoshiro · 2002-01-15 15:44 · Score: 2

"That allocation request cannot complete, so the kernel needs to do something else. Note that it can't fail the request, because it already passed it due to overcommit."

Gee, here I though malloc was supposed to return NULL when it couldn't grab any pages.

RETURN VALUE For calloc() and malloc(), the value returned is a pointer to the allocated memory, which is suitably aligned for any kind of variable, or NULL if the request fails.

Shucks be darned, I was right. So why should the VM kill a legit app?

This is a VM problem. You won't solve it by attacking user space. If you run programs that try and suck all your memory, perhaps you should get well behaveb, properly designed programs.

--
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Re:OOM Killer must die by evbergen · 2002-01-15 20:03 · Score: 1

Well, what you can do in the mean time is to wait for processes that can still run to exit gracefully on their own, possibly handling the condition of a malloc() returning NULL.

Of course, because processes tend to wait on each other sometimes, this can still cause nasty deadlocks.

But combined with a number of physical pages that you reserve until you reach OOM condition (cannot free up memory regardless of how hard we try), which even then become available only for processes having uid 0, so that a human root can always get a shell and run kill -9 to break those deadlocks, this could still be an alternative.

--
All generalizations are false, including this one. (Mark Twain)
Re:OOM Killer must die by mattdm · 2002-01-16 09:13 · Score: 2

For example you could say that, once you start dipping into the overcommit pool, fork() will start failing but existing processes can continue.

Why make this a special pool? I mean, isn't this effectively like saying "once 80% (or whatever) of swap is full, don't allow any more forks"? I'm not convinced that's any improvement over the OOM killer. (Or at least not over turning off overcommit, if that's the way you want to go.)
Re:OOM Killer must die by peter · 2002-01-17 16:23 · Score: 1

why not preallocate a chunk of memory as scratch space, so that it can be guaranteed that there is always enough memory to spawn another shell? You might even make it possible for the operator to selectively grant usage of the scratch space to memory starving processes, allowing them to complete gracefully, thus easing the memory pressure. As the original poster said, how much space is used as scratch space and which processes can access this scratch space could be site specific tunable parameters.

I don't think that solves anythink. How is the kernel going to know when to dip into the scratch space to allow a new shell to start? If it lets anything dip into it, so they can compete "gracefully", then we need a mechanism for graceful competition. We're back to square one. Why not let processes "gracefully compete" for the whole system memory in the first place. An earlier post from someone who said he'd worked on such graceful systems claimed that it would be possible to make linux gracefully handle running low on mem.

--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes , .ca)
Re:OOM Killer must die by Pussy+Is+Money · 2002-01-17 22:18 · Score: 1

It can know because you might tie the scratch space to a particular virtual console. You might also tie it to a privileged process such as sshd.
The point here is that the OOM killer needs a lot of knowledge to make reasonable decisions. At the same time no matter how clever you make it, it's knowledge will always be incomplete.
The solution is simply to not put this knowledge in the kernel in the first place, and put the decision with the only person who can know, namely the system operator.

--
Pushin' 'n dealin', shovin' 'n stealin'

My impression of what happened in 2.4 by iabervon · 2002-01-15 04:51 · Score: 4, Insightful

It started out with Rik's VM in the kernel, since it was a promising new development. However, once it was in Linus's kernel, the fact that Rik's development style was not compatible with Linus's source control style because an issue, because the VM wasn't getting updated in Linus's tree.

So Linus switches to the other VM, which is based more on the original. This means that Rik can do his development without dealing with Linus and the Linus tree can have an up-to-date VM. When Rik's is to the point where he's really happy with it and he doesn't think he'll have to make a lot of patches (and it does all the things he wants), it will probably go back in.

Since then, Rik and Linus have figured out (hopefully) how their interaction failed to work, and what Rik has to say along with his patches to make Linus know they're worth looking at. It turns out that it is possible to automate this process, such that a script will send the patches when appropriate, with the right assurances of freshness (having actually tested them, of course).

Linus wants to be able to ignore any patch that isn't for the part he's thinking about at the time (e.g., non-block-i/o patches around the beginning of 2.5). When it becomes interesting again, however, the original patch may not be right any more. Having not looked at the patch at the time when it was sent, Linus can't determine whether it is still good, since the author may have found bugs, and he doesn't know exactly what the patch was supposed to do. He wants the author to make any updates needed and resend it. It may be, of course, that the patch doesn't need to be changed, and the author doesn't have a new and better patch, but Linus can't tell unless the author sends it again with a note that it's still good.

So Rik's patchbot will test whether the patch still applies and still works, and has not been replaced by a new version, and then will send it again until Linus actually looks at it. This seems to me like a good plan, since it doesn't require Linus to test everyone's old patches and have a complicated mail system. And Linus won't accidentally apply the wrong version of a patch or be unable to find a patch.

Has anyone noticed.... by Second_Derivative · 2002-01-15 04:51 · Score: 2, Insightful

...how a lot of kernel developers seem to talk mainly about how well their patches help a server withstand slashdotting? ;)

I mean... look at that bloke who posted a scheduler patch in Kernel Traffic, and now Rik... both mention a certain website. I dunno if this is a good or bad thing

It's not rocketscience by Otis_INF · 2002-01-15 05:01 · Score: 3, Insightful

A VM is basicly a small thing: a list of pages, every page has a set of properties and an interface on top of that to get things done with the pages (claim/free/mark dirty etc). I wrote one on an MSX2 in 1986 for having 256KB roms in 128K ram + 128K vidram (and 32K disk :)). Of course, modern OS-es need a VM that can take decisions, is scalable on different hardware, and can handle the requests fast.

A lot of research has been done on virtual memory and the managercode for this type of memory. Also a lot of different types of VM's are implemented in different OS-es, all with pro's and con's in different situations. It's therefor not hard to dig in and get the knowledge you need.

F.e.: the rmap stuff is a nobrainer. If you let the VM handle every request to share/allocate a mempage, that VM can keep a set of pid's per page. IIRC NT's VM (VMM32) does this. That the current VM in Linux doesn't already have this feature is beyond me.

--
Never underestimate the relief of true separation of Religion and State.

Glibblidy Globbidy by jd · 2002-01-15 05:06 · Score: 2

Ok, now I've got people wondering if I've finally gone nuts, I'll give my 2 cents on the interview.

First off, an honest account of a person's feelings is not a personal attack. In fact, it has nothing to do with the other person at all. Nobody can "make" another person feel a particular way. A feeling is simply what a person has. The question is what the person does with that feeling. Rik van Riel seems to be doing what any dedicated, driven, psycho-geek would do - he's making his VM the best he possibly can.

Second, there are MANY possible resolutions to the purported conflict. The idea of having modular VMs is extremely sound, and likely to be implemented at some point. In the same way that networking QoS code supports multiple methods, in parallel, with rule-matching to determine the "probably best" solution, I could easily see a "meta-VM" engine which used a similar system to drive multiple VMs which could "steal" memory off each other, as needed, to run the most programs closest to optimally.

--
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)

Re:Glibblidy Globbidy by Pussy+Is+Money · 2002-01-15 05:18 · Score: 0

The idea of a modular VM stinks. It would just be another circle jerk to postpone having to work at actually getting a decent (mind you, decent, not perfect) VM subsystem.
Plug-ins, snap-ins, modular design; just different words for "procrastination".

--
Pushin' 'n dealin', shovin' 'n stealin'
Re:Glibblidy Globbidy by yukonbob · 2002-01-15 06:08 · Score: 1

Nobody can "make" another person feel a particular way. A feeling is simply what a person has.

That's stupid. Why don't you go fsck yourself?

Did that make you angry, or did you already 'simply have anger' before you read this. My point is that there are tactful ways to broach a subject, and some things are better left unsaid, whether you think a thought or not. Arguing the semantics of "making" a person feel something is best left for a psych course, not kernel development. That won't help advance Linux.

-yb

ps: I take back the 'fsck yourself' :)

CVS isn't decent by kaisyain · 2002-01-15 05:11 · Score: 4, Flamebait

The problem is that there isn't a decent multi-patch versioning system out there

Uh, yes there are. Perforce, aide-de-camp, bitkeeper, and others all do this just fine. I haven't used squeak much, but I think this is also how the built-in version control in their smalltalk image works as well. Every change management system that uses changesets works pretty much exactly this way.

CVS basically sucks, which is why some people are trying to replace it. It only gets used because it is popular and free, not because it is technically superior. The only thing it is better than is RCS/SCCS. Every other possible solution is no worse, and usually much better, than CVS.

Re:CVS isn't decent by jslag · 2002-01-15 05:39 · Score: 2, Informative

Every other possible solution is no worse, and usually much better, than CVS.

That's a little strong. True, I haven't used anything but CVS for the last couple years, but last time I tried common alternatives (namely MS VSS and PVCS), they were major PITAes - slow, unreliable, and not helpful when more than one developer was working on the same file. Not to say that CVS doesn't have its problems, of course, but for a number of years it has been the logical choice for anyone who doesn't want to plunk down hundreds of dollars per seat for a closed-source tool.
Re:CVS isn't decent by Anonymous Coward · 2002-01-15 05:39 · Score: 0

There are three distinct levels of source management tools :

low end ~($0-$500)
midrange ~($500-$2500)
high end ~($2500+)

Once you graph out all the possible products in the market, and compare them CVS is the king of the low end, and beats out some of the lower quality medium end tools.

It works over the internet well, can be made relatively secure with ssh, its merge works reasonably well, and you can create sandboxes with it that don't hurt anybody else until you are ready to merge the sandbox back. Pretty powerful for free. It does need replacing though, the code is virtually unmaintainable.
Re:CVS isn't decent by jgerman · 2002-01-15 08:54 · Score: 2

Instead of flaming the original poster for his obvious bias and lack of knowledge. I'll add another PITA revision control system... MKS. I cannot stand this piece of crap.

--
I'm the big fish in the big pond bitch.

MOD PARENT UP by Anonymous Coward · 2002-01-15 05:16 · Score: 0

+5 insightful

who is ignorant by ArchieBunker · 2002-01-15 05:16 · Score: -1

Uh can you just delete the lines instead of commenting them out? Otherwise thats pretty inefficient.

--
Only the State obtains its revenue by coercion. - Murray Rothbard

Re:who is ignorant by SpaceLifeForm · 2002-01-15 07:20 · Score: 1

Best page-lengthening post I've seen.

--
You are being MICROattacked, from various angles, in a SOFT manner.

Why not automatic 'emergency-only' swap-files? by Anonymous Coward · 2002-01-15 05:21 · Score: 0

We all know and hate the way that Windows uses a dynamically sized swap-file on the local drive, but as hard-drives have gotten bigger, the concept perhaps deserves more merit.

Linux's VM problems are not severe. For 99.99% of the time for 99.99% of people, the VM is able to deal with the loads (my guesstimates), utilising the pre-configure swap partition. The problem appears to be the 0.01% of people who occasionally overrun this limit.
Rather than OOM immediately killing off processes, wouldn't it make more sense to to a quick 'df' and create a temporary swap-file if space exists, and use it for the lower-priority processes first? If the usage was logged,it would give the admin a chance to deal with the situation gracefully.
This would only leave 2 classes of machine with potential problems - Embedded and those servers that experience a load that they weren't specified to deal with (eg slashdotting). Embedded designers always pay attention to memory footprints anyway, and the applications that are running are usually fewer and smaller. People that expect to get /.ed should buy more memory or diskspace ;)

dozens is the key word by ArchieBunker · 2002-01-15 05:26 · Score: -1

Dozens of people out of how many hundred thousand, whoop de fucking do. What possible kernel options could you need for packet radio?

--
Only the State obtains its revenue by coercion. - Murray Rothbard

Demonstration of YOUR immaturity. by Anonymous Coward · 2002-01-15 06:13 · Score: 0

The kid is only 24! Give him a break. Look what the tiny lad has accomplished in so short a while. What have you done for the community that comes close to a tenth what he has done? Right. My point. When you can come close, then you can belittle. Until then, shut the fuck up.

10 years? I hope we don't need a VM... by gosand · 2002-01-15 06:27 · Score: 2

"Will it matter 10 years from now? Most likely not."

And I really hope that the reason it doesn't matter is because our systems will have nearly unlimited memory. You don't really need a VM if you don't have limitations on memory.

Think I am crazy? Think back to what kind of system you were using 10 years ago, and how quickly we have gotten to where we are. What do you think will happen in another 10 years?

Hopefully, we won't even need a VM in 10 years.

--

My beliefs do not require that you agree with them.

Re:MEMORY OVERCOMMIT must die by CaptnMArk · 2002-01-15 07:01 · Score: 2, Informative

> there is indeed a /proc entry >(/proc/sys/vm/overcommit_memory) That setting doesn't work properly. Linux will just overcommit slightly less.

In favor of being open by dgero · 2002-01-15 07:40 · Score: 1

Think of this in terms of an open society versus a closed and/or repressive one. Which would you rather live in?

Yes, airing your dirty laundry in public doesn't look cool to an outsider. It's probably the biggest thing people in foreign countries don't get about the U.S. They see all these protests and arguments right out in the open and fail to understand how much commonality is underlying everything. Then along comes something like Sept. 11 and they're astonished when all these fractious people suddenly look very united and act together.

Public courtrooms, public lawmaking, public education, and freedom of expression are the cornerstones of open society. I'd rather have public arguments and discussions, like this one between Rik and Linus, no matter how ungraceful such arguments might appear, than the Potemkin Village of Microsoft, where everything looks wonderful on the outside but is hiding a lot of problems when you get closer.

Yes, Linus is somewhat akin to a benevolent dictator. Yes, he's no computer scientist. On the other hand, it's his baby, and I see no signs he's stopped caring for it. Perhaps the comparison to a parent is more apt. Even courts are reluctant to intrude in such relationships unless the parent's actions are particularly reprehensible. If Rik's open airing of his problems getting patches in the tree cause Linus to change his behavior a little, then it's worth the so-called bad PR.

I'll take the open society over the closed and repressive one any day. If someone you deal with doesn't understand why, educate them. Ask them why they're committing their 24/7 operations to Microsoft software that looks pretty on the outside, but which they have no way of examining for hidden flaws, in spite of the security and reliability problems in the past. Ask them why Microsoft has taken so long to fully implement what Unix has done for decades. Ask them which SUV they'd rather drive: the brand-new one from a manufacturer who's still figuring out four-wheel drive, or the one from the manufacturer who's been doing four-wheel drive for decades.

Sometimes people need a period of education before they support the revolution.

Yes, they are, unfortunately... by devphil · 2002-01-15 08:32 · Score: 2

I'm wondering why both VM's can't be included in a distro and allowing the end user to select the one he/she wishes to compile into the kernel? Are the two implementations THAT mutually exclusive?

It's not so much "mutually exclusive," it's more like "they both rewrite the same chunks of code." Maybe I'm splitting hairs there. AFAICT, the amount of common code between the two isn't enough to make this worth it.

The result is that the kernel hackers aren't concerned about, say, code size, as much as they're worried about readability and maintainability. The number of #ifdef's scattered throughout the VM code would be incredible, the resulting total code would look like Your Favorite Form of Pasta[tm], and fixing bugs would be difficult.

There are other ways to do it besides #ifdef, of course, but they all detract from maintainability. And it all becomes vastly difficult to scale as soon as a third VM implementation comes along...

--
You cannot apply a technological solution to a sociological problem. (Edwards' Law)

Re:10 years? I hope we don't need a VM... by Anonymous+DWord · 2002-01-15 08:55 · Score: 2

Think back to what kind of system you were using 10 years ago, and how quickly we have gotten to where we are.

Ten years ago I was running a 486/66 with 16M of RAM, and a 340M hard drive that eventually filled up. Right now I'm on an Athlon 950 with half a gig of ram, and ~50 gigs of hard drive that's just about full. The programs you run are always going to drive development of the equipment you run it on. It doesn't matter how much space you have- you'll fill it.

--
"If he thinks he can hide and run from the United States and our allies, he's sorely mistaken." Bush on bin Laden

This is a troll thread! Mod it down by PastaAnta · 2002-01-15 09:05 · Score: 2, Insightful

Yes you are trolling! Especially since the original poster could not get the quote right.

Linus wrote: "...Which, btw, explains why I don't consider you a kernel maintainer, Rik, ..."
See for yourself!

The reason was that Rik didn't care about everybody else if his bugfixes were not applied. Would YOU like a maintainer that didn't care about the rest of the world?

"I would tell Linus to fuck off" ... who is being immature now?

Linus is an asshole by Anonymous Coward · 2002-01-15 11:21 · Score: -1, Troll

I second the remark about Linus being an asshole.
I personally hold him responsible for setting
back the state of computing 10 years by re-inventing things which are already in BSD.

Furthermore, his refusal to set up a shared source
repository for Linux is holding back the state
of Linux.

Repeat after me, Linus is a fucking asshole.

IRIX by Pussy+Is+Money · 2002-01-15 12:58 · Score: 1, Informative

Here's an interesting tidbit by Steve Lord on the linux-xfs mailing list as well:

... [malloc] does not fail can also mean does not return for a VERY long time. Plus the memory system on Irix has a mechanism where various subsystems which consume memory can register callouts which the memory system can call to ask them to release memory. Linux does not have the latter except for the explicit calls in page_launder or what ever it is called this week.

--
Pushin' 'n dealin', shovin' 'n stealin'

Yes, it's indeed running on IIS, as shown by wget by Anonymous Coward · 2002-01-15 14:41 · Score: 0

HTTP request sent, awaiting response... HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 16 Jan 2002 02:38:16 GMT
Connection: Keep-Alive
Content-Length: 16339
Content-Type: text/html
Set-Cookie: ASPSESSIONIDGQGGGVNY=OIEGJMBCLEOHNMLGNKFBFPMM; path=/
Cache-control: private

holds barred not holes by spage · 2002-01-15 15:55 · Score: 1

Anyways, an enlightening, no-holes-barred interview.

I think you mean "no holds barred", as in free-form wrestling. "No holes barred" sounds like a tag line from a porno movie.

--
=S

LKML Feud by ahde · 2002-01-15 18:31 · Score: 2

Am I the only one who's spent more time reading the Linux Kernel Mailing List than slashdot recently *because* of the feuding and flaming that's going on? All the patches, bug reports, insults, ideas, and philosophical asides are like a soap opera (with diffs). Okay, I admit I'm addicted to reading through diffs that I have no idea what they're doing, but it makes me *feel* smarter.

About the only thing I didn't like was Linus' rambling evolution thread. Personally, I'm on Andrea's side in the VM wars, but I think its because he had a clever flame or two a while back. Plus, I've had to build kernels for two friends with 2.4.13 & 15 who were having problems with memory with older 2.4.x's (probly redhat's problems) but since Rik's siding with redhat, that's another strike against him. I don't run a data warehouse, and I hate xinetd, and am still bitter over the RPM incompatibilities between 3 & 4.

Re:LKML Feud by ahde · 2002-01-15 18:41 · Score: 2

I forgot to mention my main point, and that's that for 90% of us (running servers or desktops), 99% of the time, we'll never notice the difference between either VM or even the old 2.2 (which I still use)

Maybe we're all missing the point by pdqlamb · 2002-01-16 09:58 · Score: 3, Insightful

There's a lot of back-and-forth discussion, not only on the VM, but on the feature (un)freeze of 2.4/2.5, and on how Linus is a lousy patch control system. But maybe that's not the most important thing here.

Way back when, the purpose of a development kernel was to feed things in to a stable kernel tree. Now part of the problem has to be that Linus started 2.4 way before 2.3.X was ready for it, but it looks like history is repeating itself. 2.4 isn't all that stable, even now, but Linux is happily accepting lots of new goodies to play with in 2.5.

Something is not working right here. Is Linus less demanding of quality now, since he's willing for somebody else to come in and fix up the allegedly stable kernel tree? Or is he accepting too many things to allow a development tree to stabilize?

I suspect it's a combination of too much stuff and too big a kernel. Instead of the heady days of 2-3 kernels per week in the development tree, and the stable tree gets another kernel every week or two, now we have a development kernel every week or two and a stable patch every month or three. And the kernel size is 10x bigger than in the 1.0 days.

Look how long it took the USB stuff to filter through the development into the stable tree.

It seems obvious the Linus Linux development process is not scaling. I'm not sure what the answer will turn out to be, but it may be some combination of the following:

(1) More "boutique" kernels like Alan Cox's ac series, feeding into the "stable development" kernels that Linus has been generating.

(2) More formal check-in methods, a la CVS commit. This may take some developer training in how to use CVS -- does anyone want to offer Linus a course and set up a server for him? I bet he'd take a complementary Geek Cruise!

(3) Some kind of more rigorous control in the stable kernel tree. I suppose you could say Redhat and SuSE are doing this informally now; if they start coordinating their efforts, and get IBM involved, the kernel will be incredibly stable. And even more incredibly slow to update.

(4) More beta testers to crack the newer kernels. This is going to get harder, as more of us need to get work done on our Linux boxes. It used to be a hassle when Linux crashed; now it's not acceptable any more!

(5) Better ways for these users to track down problems and report bugs. This last week I heard myself say, "Try rebooting your Linux box and see if the problem goes away." I just don't have the time, energy, knowledge, and skills to deal with lusers' "I've got a problem" whines any more.

(6) Is the quality of kernel patches too low? Do we need to develop some regression tests for the kernel, which a patch would have to pass before it would be accepted? (And how do you do a regression test program of this magnitude without Microsoft's beta testers, AKA customers?)

Anybody want to contribute more ideas to the list? We can spam Linus with them until he agrees!

Linux is dying. by Anonymous Coward · 2002-01-17 01:35 · Score: 0

Heh heh heh. Actually, I'd say the real reason for the spat between Rik and Linux -er Linus is probably some blonde. (Assuming their both heterosexuals)

Honest? Trolling? debate. by castlan · 2002-01-18 11:42 · Score: 1

The best that you can hope for in a public forum is that "being honest" is the start to a fruitful debate. An alternative is to not state your honest opinion in a public forum, because for whatever reason you feel that it would be better to not debate it. Perhaps your opinion is insignificant, and better not voiced. At the other extreme, trolling is provoking a response that might likely be withheld under better judgement. Some "noble" trolls can see themselves as acting along similar lines to Civil Disobedients or Freedom Fighters, in that they would be catalysts of progressive change. Unfortunately, such trolling requires intelligence and skillful execution, or else it is simply entropy, noise, or akin to arbitrarily "hitting below the belt" without justification beyond lowbrow entertainment.

To prove that your post was not a troll, you should justify your post by shedding some insight into your statement of honesty. You might just enlighten somebody. You claim that Vi sucks for usability, but despite it having one of the worst UIs available, you use it.

Why do you use Vi? What alternative to Vi (or Emacs) provides greater usability? why not utilize the alternative? More to the topic, how exactly do you liken this issue of Linux VM contention to Vi vs. Emacs? Could it be that Like Vi vs. Emacs, the choice of Andrea's VM or Rik's VM is likely to stretch beyond the forseable future, and will generate more useless "heat" then insight and "light", until the entire debate is made moot by a significant change in the text-processing or Virtual Memory consumption habits of society at large?

... or maybe you feel that you will fool somebody by adding a contrary disclaimer to your troll.

-castlan

Slashdot Mirror

Rik van Riel on Kernels, VMs, and Linux

233 comments