2.4 Maintainer Marcelo Tosatti Answers Your Questions 287
1) list of changes for the common folk
by e40
One thing that is really missing is a list of changes in each kernel release that is meant to be consumed by the masses. The "changelogs" that are offered up are sorely lacking for us non-kernel hackers. What I'd like to see is a prose description of the changes in each version. Something like Release notes for 2.2.18 by Alan Cox [linux.org.uk] is a step in the right direction, but some of it is even a little too technical. For example, in the above document, set_current_state
* Fixed potential SMP race
means little to me and probably a lot of other people. Under what condition does this occur? The question why should I care about this change? should be answered for each entry.
How do you feel about doing something like this?
MT: I agree on that the changelog is "not for end users."
As I've seen several requests, I'll try to do more extended changelogs.
However, please note that right now I'm giving higher priority to fixing problems than to writing extended changelogs.
2) diary
by Lennie
Do you have a diary, like Alan Cox we can read?
Because we all like to know, if you'll actually be doing what your gonna promise now :)
MT: No I don't, sorry...
3) Kernel growth -- is it a problem?
by connorbd
While I am a passionate Linux supporter, I have also come to the conclusion that kernel bloat is likely to be a major issue fairly soon. It appears to have been the case for some time that =486 systems Need Not Apply, and Red Hat in particular has become a rather memory-hungry distro (it won't even install on my 16MB Pentium system, though I doubt this is really a kernel issue). The end result is that Linux seems slowly to be growing out of the lower-end used-server-in-a-closet market that helped it get so big in the first place.
My question: I presume kernel bloat, both in terms of code size and resource demands, can impact heavily on maintainability. Do you see this as a significant issue for the future, how much of a problem is it, and is it something that can be easily addressed without tearing apart the code base and reorganizing it from the ground up?
MT: Core kernel bloat is a _very_ bad problem. However, I'm pretty confident Linus is not going to allow that on 2.5, though.
About more drivers/fses being added to the kernel, well, thats a bad problem for maintenance.
All we can do about it is to make sure all accepted code to the kernel is clean, simple, and well designed to make maintenance easier later...
4) code control
by brer_rabbit
Have you thought about putting your changes under some sort of version control software? If you started putting the kernel/patches under CVS, maybe the rest of the kernel crowd would follow.
MT: I'm releasing pre patches now pretty often. However, I could export my local CVS, yes.
I might do that in the future.
5) Any plans to improve documenting the kernel?
by Carnage4Life
Currently the Linux kernel is filled with functions that are either poorly documented or completely undocumented. One of the purported benefits of Free Software is that many developers can jump in and help yet when you have functions like __free_pages_ok [linux.no] in page_alloc.c that are important, complex yet the only comment is:
"Buddy system. Hairy. You really aren't expected to understand this."
Doesn't this somehow defeat the point of the source being available in the first place? Basically the question I have to ask is this, "I have flirted with the thought of sending comment only patches to the kernel to further help people understand certain subtleties (e.g. why the pprev and next pointers in user_struct are not what they seem) in the source code especially CS students who are learning about the kernel in operating systems classes. If someone were to start such a program would such patches be accepted into the kernel?
MT: Yes, I would accept such patches as long as I agree with the documentation _and_ as long as I have time to read all patches :)
6) A pretty generic question
by archen
How do you view Linux in the scheme of things? Mainly where do you think the niche of Linux is now, and where will it be years from now. How do you view the direction Linux tends to be taking compared to other OS's (Windows XP, FreeBSD, etc) - ["direction" is up to what ever you personally interpret it to be BTW]
MT: Linux has a lot of "niches": the embedded market, the home users market, the enterprise market: Handling all of those "niches" in the best possible way is a very nice challenge.
I don't see any "direction" to Linux, though: It can work well on several niches.
7) Why you?
by CmdrPinkTaco
This is not intended as a flame or a troll, more of an interview style question. I figure since we are the people who are putting our trust in this person to handle *our* kernel, that this should also be our chance to learn about the person responsible.
What makes you think that you can handle maintaining the Linux Kernel? What qualifications do you have and why should we (the people) trust you with the Linux kernel.
I realize that this is actually two questions, but they more or less go together in one answer.
MT: I think they chose me because I can deal with different people without ego fights. I usually avoid conflicts and instead I try to solve problems.
About qualifications: I've been working at Conectiva for some time (4 years) as a software developer. I'm working together with technical support, which makes me have an idea of usual end users problems/needs.
8) Patches
by return 42
Linus likes very small patches, everything broken down into little chunks of functionality. Alan is ok with bigger patches. What do you like and dislike in the patches people send you?
MT: I prefer patches which touch specific things only: what I really hate are patches which touch several kernel parts.
9) CML2, cvs, kdb, crypto and more
by iamsure
If during the course of your maintainership CML2 proves very successful (as I beleive it already has) would you consider using it instead of CML1?
Also, would you consider moving crypto into the main tree in the near future? Debian has, Redhat will "soon" ...
Would you consider using bitkeeper, cvs, or even complete changelogs with proper attribution of WHICH merges took place?
And finally, would you consider FINALLY bringing kdb into the main kernel? Linus doesnt want it, but he doesnt want it because he doesnt see the value. He didnt say he banned it ...
MT: About CML: Sure, I may consider including it in the future. Not now, though.
About crypto: I want to be out of legal problems. Sorry.
kdb: Maybe. Not now, though.
10) Alan Cox and politics
by melquiades
Alan Cox's stand on the changelog is clearly not only a matter of personal protection, but a political statement. He has chosen an issue that is tremendously important to Linux, free software, and software developers everywhere, and certainly it's right for him to be pursuing it.
But is the Linux kernel the right forum for politics? Do you feel that it's a bad idea to involve the kernel in politics -- a slippery slope in which the software itself becomes a political pawn? Or would you say that the kernel -- and all software -- has already become a political pawn, and Cox's actions are entirely justified given that free software's existence is under increasing threat?
MT: I'll try to avoid involving the kernel in political questions.
11) Sound drivers
by BlowCat
The sound drivers are very poorly written. A lot of code is duplicated. Not all drivers support some ioctls. Every driver has its peculiarities, e.g. some drivers reset dsp to mono, 8bit on DSP_RESET, some don't. Some support /dev/audio, some don't.
Not having ALSA in 2.4.x means no good sound support in the stable kernel for another year of two. Do you plan to integrate ALSA into the 2.4 branch? If yes, will it happen after it's done on the 2.5 branch?
MT: I do not plan to integrate ALSA on 2.4.x.
12) How do you plan to handle the big companies?
by hansendc
As all of us know, many large companies are putting large amounts of resources toward Linux. 2.4 will continue to be important to these companies because it is the version currently being shipped with the distributions, and will continue to be shipped for at east a year or two.
How are you going to deal with the submissions from people like IBM and SGI who are going to want to make significant changes to 2.4?
MT: If their changes are non intrusive and I agree with the way they are coded, sure I'll apply them. Why not?
13) Stability vs Features
by azaroth42
How do you intend to decide which new patches should be added to 2.4, the stable tree, and which are not to be included as being more appropriate to just 2.5, the unstable development tree? For example, do new or updated device drivers rank more highly than VM updates?
MT: I'm really trying to avoid new features which are intrusive: Those ones are for 2.5.
New features which are non intrusive are OK.
14) Threads
by Exmet Paff Daxx
What are your thoughts about threads? Specifically, do you support Linus's "Context of Execution" generality with clone() or are you going to focus more on plain POSIX pthreads compliance?
Any chance of Alan Cox's multi-threaded post-mortem debugging patch which dumps multiple core files for each lightweight process (LWP) making it into the kernel? How about support for post mortem debugging of multithreaded core files in general (right now there is zero support).
Any rants about threading as a general topic would work.
MT: I do support Linus's "Context of Execution" idea, yes.
About Alan's multi-threaded post-mortem debugging patch: I haven't read it yet. But I might apply it.
15) Age a question?
by debrain
If what I've read is correct, you are the youngest maintainer for this kernel. Do you have any feelings on a social level, regarding much of the peer review and critism will come from people who are older? (and very possibly set in their ways, and potentially intimidating)
MT: I don't have any feelings wrt age. I just hope that older people don't take that into account.
16) Expectations
by MikeBabcock
In the time you've been aware of or been using Linux, how have your expectations for what it ought to be or eventually become changed? I know in the time I've used it I'd never expected it, for example, to become a desktop OS but rather a good server or embedded product. What did you expect when you first started with Linux, and what do you expect now?
MT: I expected it to be a server system when I started using it.
Now I expect it to be a Unix system which can work in a lot of different environments. :)
17) Hit by a bus
by moonboy
I'd hate to stray from the status quo where standard interview questions are concerned, so in keeping with it, I ask:
What's it like knowing that, if (God forbid) Linus and Alan were hit by a bus, you might be "The Man"?
Hey, someone had to ask.
MT: I don't know, dude.
18) Re:Do you use a distribution?
by bfree
To rewrite the above question the way I'd like it asked:
What operating systems and platforms do you personally use and which ones do you also use (and why)?
MT: I use Linux for work and sometimes I use Windows to play games.
Do you run a common environment on all your machines (in as far as possible) or do you run different things in different places and which environments do you prefer for what?
MT: I do run Linux on all of my machines. I like to take a look at other OSes when I have time...
What development tools do you use (especially for the kernel), would you do anything differebtly for the kernel (like make it compile with other compilers) if you could (or will you) and would you like to (or will you) place the Linux stable kernel into CVS or another version control system?
MT: I use vi for editting source code and gcc to compile the kernel. :)
No, I'm not going to put the kernel in any kind of version control system because I have to know what goes into the kernel.
One thing which I'm going to do, and which matters, is the use of STP in each -pre release of the kernel.
I hope the SGI guys can get STP stable and working well soon.
Do you feel any personal preferences for anything might actually be in anyway reflected in your work as the stable kernel maintainer?
MT: No.
Do you have a good lawyer?
MT: No. Actually, I don't have a lawyer at all and I hope I'll never have to use one on Linux related issues.
Are you planing on travelling to the U.S.A.> (for all I know you live there, excuse my ignorance:-)? [Note: Marcelo lives in Brazil.]
MT: No. I may go to some congress, though. Not sure yet, though.
Have you experience dealing with politicians, business leaders and large groups and do you see this as a part of your job description? MT: I do not have experience dealing with politicians, business leaders or large groups. I see that as part of my job description, yes. I hope I can learn that with time...
When you stop maintaing the stable kernel, what would you like people to be saying about your reign?
MT: That it works well. ;)
Whelp... (Score:5, Funny)
Questions that didn't make the cut (Score:5, Funny)
What do you think is an appropriate length for interview answers?
MT:17
Can you elaborate?
MT:no, sorry
Do you think that people who write long interview answers are compensating for other shortcomings?
MT: Yes, definitely
B side questions (Score:4, Funny)
MT: it's groovy...
Tell us your psychological approach to kernel development vis-a-vis great 19th century philosophers.
MT: not now. maybe later. sorry...
Some people have likened coding to a visual-perceptual dialectic where the dynamic energy of structure versus entropy result in communal "oneness." What are your thoughts on this?
MT: Code is green...
Is there anything else you'd like to add to this interview, given that you now have a chance to speak to the large slashdot community? Any particular issues you feel strongly about?
MT:
Re:B side questions (Score:2)
vi vs emacs (Score:5, Funny)
Re:Whelp... (Score:3, Insightful)
Advice for the new maintainer... (Score:2)
Short and to the point answers? (Score:1, Interesting)
Re:Short and to the point answers? (Score:5, Interesting)
Code style? (Score:4, Interesting)
MT: If their changes are non intrusive and I agree with the way they are coded, sure I'll apply them. Why not?
Whats he mean by "... and I agree with the way they are coded"? If it works and has nothing bad in it, why would he reject it?
Re:Code style? (Score:4, Informative)
http://www.uwsg.indiana.edu/hypermail/linux/ker
Search the page for "Coding style - a non-issue" (subject of the thread) and read for a while.....
Pbur
Re:Code style? (Score:5, Funny)
int fuckfuckfuckfuckfuckfuckfuckfuck = 2;
int fuckfuckfuckfuckfuckfuckfuckfuckfuck = fuckfuckfuckfuckfuckfuckfuckfuck + 2;
/* Accepted */
int min_value = 2;
int max_value = min_value + 2;
Re:Code style? (Score:2, Insightful)
/* Accepted */
int min_value, max_value;
minvalue = 2;
max_value = min_value + 2;
Re:Code style? (Score:2)
Re:Code style? (Score:2)
Re:Code style? (Score:2)
Ummmm, have you tried to compile the above? You will be in for a rude surprise when you discover that the kernel headers (specifically <linux/kernel.h>) define macros 'max' and 'min'.
This is a rather recent development (debuting in 2.4.10, a controversial variant appeared in 2.4.9) - Linus has long been staunchly opposed to the traditional 'max' and 'min' macros because they mask unsafe type promotions - i.e. they can easily hide bugs. Someone (Dave Miller, was it?) came up with the current versions in kernel.h in which the compiler whinges noisily if you try to use them on incompatible types.
Pure genius, if you ask me, but then I think that about a lot of Linux kernel code, which probably goes to show the dearth of my lifetime exposure to clever code. (:
Re:Code style? (Score:5, Informative)
You have to understand that most of the "development" that goes on in the stable series is actually bug fixes, and "new features" are mostly new drivers that don't affect the core code. New features that affect the core code are much less likely to be accepted, Marcelo will likely tell the person to send it to Linus for the 2.5 series.
The kernel maintainer, (Alan for 2.2, Marcelo for 2.4, Linus for 2.5) has to look at new code submissions with the question "What will it be like to maintain this code?"
In some ways, this is more important than if it actually works or not - if the design and code is very clean and straightforward, and has minimal dependencies, then future bug fixes and maintenance will be easy. If the code has a fragile design, or uses a coding style completely different from the rest of the kernel, then other developers will have a hard time reading it, fixing it, and updating it.
If code like that gets into the kernel, it would become an unmaintainable heap of crap. Even if each individual new feature "worked".
This is one of the things that Linus is pretty good at. (At least for the core code, Alan Cox apparently thinks Linus lets too much crappy code get into the drivers... but now I'm spreading stories from the mailing list without the benefit of the context, so take that with a grain of salt.)
Or read the mailing list yourself. But be warned, I had 582 messages in my inbox this morning, and that was just the kernel mailing traffic from the weekend.
Interview suggestion... (Score:1, Insightful)
That gives you guys an easy interview, and we get our questions answered straight up.
Anyone else interested?
Mods that are interested, mod me up (don't worry, I'm at the cap).
FIRST ON THE LIST!!! (Score:5, Informative)
"Do you guys read your own site?"
-no.
Re:Interview suggestion... (Score:5, Informative)
OlympicSponsor: Seriously, can you give us a breakdown of how much time each editor spends actually reading the site they nominally run? Like, time spent clicking on user comments?
CowboyNeal: I know from our internal discussion lists and channels, that all of us are constantly reading the site, but as for a detailed breakdown, I'd have no idea where to start.
Segmond: Have you ever used "super moderating power" to mod down posts attacking slashdot editors...?
CowboyNeal: As for "super moderating power", I know I could go into the database and moderate like crazy, but my ethics won't allow me to do so. Also, I don't usually read comments attached to stories.
Truth is, most of the editors seem to have gotten completely bored with the site but for whatever reasons feel compelled to keep plugging on. They've long since given up caring about it and seem mystified that any of the readers would care either.
Re:Interview suggestion... (Score:2)
CNeal: 9.5 months ago
JK: 22 months ago
Okay, CowboyNeal probably has nothing new to add, but the other interviews are so old that it's worth revisiting. Hell, there are nearly duplicate "Ask Slashdot" questions that are only six months old (and answerable via gg:ask slashdot).
Re:Interview suggestion... (Score:2, Interesting)
Another thing, in response to
Truth is, most of the editors seem to have gotten completely bored with the site but for whatever reasons feel compelled to keep plugging on. They've long since given up caring about it and seem mystified that any of the readers would care either.
Its ok to get bored with (hobby) projects, but, god, they get paid to run this site! Its not a hobby they can just get bored with, if they don't like it change jobs and let someone else run the site!
BTW - on Katz's interview, "Preaching to a Choir" question, in his response he says:
So I stay here because Im happy, stimulated and welcome
I'm surprised the trolls never hit that...
No bloat (Score:1, Redundant)
Coolest interview to date.
Priorities... (Score:5, Insightful)
Poor/Incomplete/Out of date documentation is the Achilles Heel of open source.
Re:Priorities... (Score:1)
The Achilles Heel of open source is software that does not work or cannot be gotten to work. What good is software that's documented well but that doesn't work?! Documentation is good, but if the features are not there or are not stable, well then, what's the point?
Re:Priorities... (Score:1)
jeez
Re:Priorities... (Score:5, Interesting)
One thing is writing user manuals, which is something that can be done by non-developers and is much easier solved But documentating APIs and code is something that needs to be done by developers, who rather spend time writing working code than writing up to date docs. Somehow the documentation process always gets the lowest priority.
If you were developing in your free time, what would you rather do? Write code or write docs? I guess you know the answer :-) Guess what gets done last (or when there's some time to waste)?
Same btw, goes for code reviews and bugfixing of lower priority bugs (bugs which are kind of irritating but not critical).
documentation (Score:5, Interesting)
Re:Priorities... (Score:5, Interesting)
I would have to disagree with this. While poor documentation does hurt one open source project against another, actual help files, FAQ's, and newbie files are rampant in linux - from a broad base I think mandrake 8.1 is better documented than windows. As to specific documentation in the kernel etc, yeah, its poorly documented, but you're missing 2 important points - one: its poorly documented across the board, and two: when's the last time you saw the documentation in kernel32.dll for windows? ANY documenting is better than none. The fact that we can see the source in and of itsself makes it superior to anything non-open.
~z
Re:Priorities... (Score:2)
I'll take good clear docs over messy undocumented source any day.
Re:Priorities... (Score:3, Insightful)
Not in the kernel, it is not.
Documentation as the Achilles heel is end-user documentation. Developer documentation is a poor poor substitute for the source. Any problem can be traced through the kernel calls, flow charted, etc. There is no problem there. The source is critical, documentation is just about making it a little easier.
For the end user though, you cannot have an expectation the user will ever read the source, so documentation becomes important. I think you can strongly argue the kernel documentation is utterly irrelevant to the end user, though. Quite whining and "Use the source"
Re:Priorities... (Score:2)
People really want the IDEAL of good documentation. The reality is that documentation NEVER gets you all the way there, and you end up in the source anyway. In the case of non-open products, you end up doing even sillier things like object dumps of the link libraries trying to figure out why the documentation is different from the actual library.
What people will say (Score:4, Insightful)
Nothing. The less that ends up being said, the better a job he's done.
Remember the Anagram (Score:4, Funny)
Spread the word.
"Worst... Interview... Ever!" (Score:2, Insightful)
Come on! This guy is the kernel maintainer? I know I will probably get modded down as flamebait because I am not singing his praises about being concise and to the point, but that interview was awful! I can't believe he is suppose to be the point of contact of anybody (read IBM, HP etc) that want to submit patches to be in the 2.4 tree. It looks like he spent about 10 minutes answering these questions, I can only hope he takes his job maintaining the kernel seriously. This interview certainly doesn't instill confidence in his ability to maintain the tree.
Re:"Worst... Interview... Ever!" (Score:2, Insightful)
I hope I don't need to spell it out any more clearly for you
Re:"Worst... Interview... Ever!" (Score:2, Insightful)
He's a Kernel maintainer, not a celebrity -- and he acts accordingly. Cool.
Re:"Worst... Interview... Ever!" (Score:2)
He's a kernel maintainer and therefore a celebrity. And his public relation skills aren't very good.
I agree his primary task is maintaining the kernel, and as far as I can see he's doing a fine job, but he's also one of the primary spokesmen for the Linux kernel.
Re:"Worst... Interview... Ever!" (Score:4, Insightful)
Why judge the guy's ability to maintain a complex technical work like the linux kernel based on an informal non-technical interview?
I am willing to bet that if he was asked to explain how various parts of the kernel work together, that he could give a very reasonable answer, that would leave you with no problem understanding how it works. Now that would be a good base for his ability to maintain a kernel.
Re:"Worst... Interview... Ever!" (Score:3, Insightful)
But it would be nice if he could show that he is, oh, *human*. With guys like him giving representing Linux, no wonder computer ppl have the image of humorless, socially awkward children. I mean, a simple lighthearted question about how it "feels" to be in the position he is in, and he has no idea? WTF?
Believe me, I'm not looking for a friggin dissertation coming from him, but it might be nice to see that a computer person can speak and act like a human.
Probably too much to ask for though.
Re:"Worst... Interview... Ever!" (Score:2)
But sadly, it seems like you are a typical ignorant American who only knows how to speak one language. And you do not even spell it correctly--humor is supposed to be spelled humour.
I can understand that the English language has not many jokes of its own and so when you see a Portugese speaker you want him to tell jokes. But Americans don't have an advanced sense of humour and can't understand it even if it was explained to you.
In the end you have to learn Portugese.
Re:"Worst... Interview... Ever!" (Score:2)
Re:"Worst... Interview... Ever!" (Score:2, Informative)
I bet if you meet him in person and talk over a beer or something he can explain things in more detail. Another thing that plays is that English is not his native language (nor is mine).
Most developers/hackers I know are real short and direct in their answers and explanations when they're in deep-hack mode, including myself. Why say more than needed?
People, instead of critisizing(sp?) his interviewing his interviewing skills, one should try reading his posts on LKM. That's where he's in his element (or natural habitat). I find no fault with Marcello. I hope he does a good job and I wish him success with it (and of course a lot of fun)
Re:"Worst... Interview... Ever!" (Score:3, Insightful)
If I was submitting code this is exactly the sort of response that I'd most appreciate.
Re:"Worst... Interview... Ever!" (Score:3, Insightful)
The question was completely niave, but Marcelo being the diplomat that he is did not want to point this out and embarass moonboy.
The question assumes that Marcelo is not currently "The Man" when in fact Marcelo is quite clearly "THE Man."
Re:"Worst... Interview... Ever!" (Score:2)
> instill confidence in his ability to maintain the tree.
Remember that English is NOT Marcelo's first language, so perhaps he is far more chatty in Portuguese. (This is a hint to the Brazilian readers of
But as another follow-up post mentioned, this was a stupid question. David Weinehall has been maintaining the 2.0.x tree for a few months now, & might become ``The Man" due to seniority. (And there's a few other developers who have been involved for close to a decade, & they might want first grab.)
In short, there's a pretty deep bench of talent available to take over Linux kernel development should the proverbial bus flatten Linus & Alan.
Geoff
Re:"Worst... Interview... Ever!" (Score:2, Funny)
...and much longer than I spent proofreading my post.
I meant to write "...longer than the slashdot editors spent proofreading..."
Re:"Worst... Interview... Ever!" (Score:2, Insightful)
Ah, cut the crap! Where do people get the attitude from, that the kernel developer owe them anything? He did this on his free time as a hobby. Sure, now he's getting paid for it and is famous and all, but that doesn't mean that he has any special responsibility in advancing the "only viable alternative to a desktop OS."
People, please don't be so uptight!
spreading rumors about me (Score:2, Funny)
No I didn't.
Formatting (Score:1, Offtopic)
Kernel bloat is inevitable. (i.e.: Stop whining.) (Score:4, Insightful)
- A.P.
Re:Kernel bloat is inevitable. (i.e.: Stop whining (Score:4, Insightful)
being able to say it runs on a 386/486 has always been a great way to get the point across. Sure we can say 'it runs on a p90! but that just doesn't have the same kick.
Personally I don't have a problem with slow obsolence 10 year old hardware support in the 'newer' kernels, as long as its only with hardwaare at least 10 years old. To do obsolence of support any quicked pputs us in the samw league as MS. meaning we can't point our fingers t MS and say "See they made you buy new hardware, AGAIN"
Re:Kernel bloat is inevitable. (i.e.: Stop whining (Score:5, Insightful)
It does run fine on 368/486 - if you run the software appropriate for that system. KDE2 is gonna suck goat balls, but so is XP. The difference is, you can trim down Linux to work great. On a 486, you can use Blackbox, on a 386, I'd stick with textmode apps - there are plenty of good editors, browsers, etc, still in active development for textmode in Linux. Significantly fewer for XP (and many of them are "Unixy" things like shells and telnet clients).
Use a setup appropriate to the hardware, and Linux works fine... the Jailbait distro (so named because it's under 16 megs, haha), is very full featured, and there are "routers on a disk". Also, don't forget that 2.0.36 and kin are still out there, downloadable and usable. Unlike Win98, which just went unsupported and realistically unavailable, old *and* stable kernels are available. And then there are specialty forks - I think the one for the 16 Mhz Dragonball processor is an amusing example (a.k.a., Linux on Palm).
--
Evan
Re:Kernel bloat is inevitable. (i.e.: Stop whining (Score:2, Interesting)
no, that was win95 that went unsupported. IIRC, win98 won't go unsupported 'till 2003.
Re:You'd need a lot of ram, though (Score:2)
--
Evan
Re:Today's distros are memory hungry (Score:2)
That's precisely why Linux versioning works the way it does. If a 2.0.x security or bug patch is written, it can still be accepted. No new features, but that's why it's been moved on from. Same for 2.2.x, and now 2.4.x (although at first, some of the "bug" patches are really feature enhancements to the point that they are almost new fatures). If you want to stay secure, you don't have to stay modern - you just have to stay up to date.... which is neigh axiomatic when dealing with security.
--
Evan
Re:Kernel security is just part of the story (Score:2)
I am talking about Linux, not a distribution. I am talking about ther kernel - if you are using a premade distro, the comments don't apply - they are aimed at the people *making* the distros.
Basically, the 2.4 kernel when stripped down to the requirements have no problems running on a 386 or 486.
Absolutely - I'm talking about 16 Mhz processors with 8 megs of RAM, and *their* ilk - embedded and archaic systems. On a full blown, general purpose computer, 2.4 will fit and run nicely.
Are we approaching an agreement?
I think we always were - I was referring more to the kernel going "below" the level of a 386 when I referred to the 2.0.x series. That, for specific deticated uses, it is still available as a code base, not for "Joe Smith" on his old 486. And we broke down on the classic lines - I meant Linux as in the kernel code, you read Linux as in the complete system. There are a fair number of deticated distros out there using old stable kernels for everything from routers on a disk to MMU-less archetechtures. Most are heavily patched into custom beasts.
And the bit about usersapce programs eating RAM - yup, that's why I advocated textmode apps for 386es... they tend to be *much* more svelt then even their Xlib counterparts.
--
Evan
Re:Kernel bloat is inevitable. (i.e.: Stop whining (Score:3, Insightful)
The thing is that I would never dream of using a 486 to surf the net, send/receive e-mail, play games etc. But I DO use a 486 as the router for my network.
Why would I want to put a fairly modern machine in charge of something that doesn't require it?
I love the fact that I can install slackware on my old 486 and have it forward packets for me. If Linux didn't run on it I would have to have used one of my celeron boxes that I instead gave my kid. What a waste that would have been!
--
Garett
Re:Kernel bloat is inevitable. (i.e.: Stop whining (Score:3, Interesting)
I have not noticed *any* kernel bloat (and I've been running Linux for a loooong time). All the bloat is in the apps (especially the GUI gizmos). I'm surprised this question was even asked (but then again this is slashdot...)
old machines just becoming supported today (Score:2, Insightful)
I have an active interest in Linux on Nubus PowerMacs. They were new in the 1994 era. Support for Linux on these machines is still spotty, and you have to jump through hoops to get something to work. However, it is a perfectly adequate machine once you get done.
One might have to build a custom kernel to fit within the limitations of the hardware. But it's a case of only the newest kernel being able to run on the old hardware at all. I'm glad that people are actively developing for it, otherwise I'd be unable to learn to use Linux because I don't have new hardware available.
Re:Kernel bloat is inevitable. (i.e.: Stop whining (Score:2)
L2 cache is still fairly small, and the more you can do inside it the better. The performance hit of a cache miss is bigger than you think.
But, yeah, if the reason would be to keep it running on 10-20 year systems, that's wrong.
Embedded use (Score:4, Insightful)
If Linux is going to be suitable for a wide variety of niche markets, it needs to be scalable down as well as up.
Re:Kernel bloat is inevitable. (i.e.: Stop whining (Score:3, Insightful)
Many programmers (yes, I am guilty too), take inexpensive hardware as license to write ineficient code. So what if the end user needs more RAM or a faster processor....thats progress!
This attitude only works because end users don't realize the benefit of non-bloatware. The replies to the above post all mentioned being able to run the kernel on an old 386/486 computer....fine, thats a worthy goal. I do it myself. However, what happens when the same "removal of bloat" is applied to regular software, as to that run on old hardware?
I dare anyone to say that the above four points are in any way a Bad Thing [tm]! I don't know about everyone else reading Slahdot, but I'd love for my computer to run even 5% faster without any changes to the hardware....even (especially?) on my new 1.0 GHz / 512 MB RAM / 48 GB HD system.
actually it's not. but yes stop whining... (Score:2)
Actually, it's not inevitable. The core kernel code hasn't grown significantly since 2.2 which was released in early 1999.
By the core I mean everything except drivers.
Re:Kernel bloat is inevitable. (i.e.: Stop whining (Score:3, Insightful)
Look at it this way: yes, I can use a 1.x kernel, but forget about things like up-to-date security, USB support (a lot of old Pentium MMX boxen have the ports), etc. Who can someone in that situation turn to but Linux?
/Brian
Old hardware. (Score:2)
I run the latest NetBSD kernel on a 486. Doesn't seem to be a problem.
So far as I can tell, there's no new advances coming down the pike in VESA or ISA cards. It's not like there's huge drifts of new code that need to be written for my shitty old Dell.
Incidentally, I thought the big advantage of Linux was that it works on old hardware. At least, that's what the zealots keep telling me.
--saint
Linux embedded is a player in the embedded market (Score:2)
Yes
Level Control Systems Matrix 3 [lcsaudio.com] has a embedded linux ppc system with 100baseT and UW-SCSI for real time audio system.
--jeff
Inconsistent answers re: revision control? (Score:4, Insightful)
However, I could export my local CVS, yes. I might do that in the future.
And then, to Q18:
No, I'm not going to put the kernel in any kind of version control system because I have to know what goes into the kernel.
Last time I used it, CVS was a version control system. So, am I the only one to think this question can't be answered with "yes" and "no" at the same time and still make sense? To me, this is just plain weird, and if this was a "real" interview, I'd think bad thinks about the interviewer. Now I guess I'll have to settle for the editors, as a few others in the thread already have. Heh.
Re:Inconsistent answers re: revision control? (Score:2, Insightful)
Obvious (Score:4, Insightful)
What he said is that hes Not going to make a writable cvs available to anyone else: all contributions will have come come as patches in email.
In summary he gets cvs and you dont.
I don't care what kernel people eat for breakfast. (Score:1, Interesting)
For some reason, though, I like this guy.
Maybe it's because of his short and to the point answers.
LTP not STP (Score:5, Informative)
STP isn't much use for testing kernel pre-releases.
Re:LTP not STP (Score:2)
Re:LTP not STP (Score:4, Funny)
No, no, he means STP.
STP Helps Your Kernel Rum Like It Should! [stp.com]
Wonder when he'll change his mind? (Score:2, Interesting)
MT: I use Linux for work and sometimes I use Windows to play games.
Man, sounds kind of like why I still have the Win box at home - to play games. I'm wondering if/when he'll finally decide to switch - I'm expecting to dump my last Win box when I get the Mandrake 8.1 with The Sims bundle (WINE plus DirectX support).
I know that people believe we should all play Linux games, but the reality is that most of us still have Windows cause of the games. We don't really care why we can finally get rid of it, but we need something workable.
-
Changelogs should answer the 5 Ws (Score:5, Funny)
parent funny? (Score:2)
Big Bus (Score:5, Funny)
Linus lives in Silicon Valley, Alan in Swansea, Wales. That's one monster bus.
Re:Big Bus (Score:2, Funny)
Kernel changelogs (Score:4, Interesting)
I don't necessarily think that end user style changelogs should be of much concern to core kernel developers. Obviously, they should be concentrating on fixing problems. However, I have an idea that should make everybody happy...
A group of kernel savvy & knowledgeable systems experts should get together and form an open changelog review project. This project could work alongside the core kernel team for the sole purpose of documenting kernel changes, answering the questions of why, where, how, etc.
This would achieve great kernel documentation, and avoid putting that added stress on the kernel team. Thoughts?
Re:Kernel changelogs (Score:4, Insightful)
Right now, for example, I'm using 2.4.17-pre6 because it's the first kernel with drm support for sis. But that was clearly marked in the changelog.
For most people, I just say they should probably stick with their distro's kernel. Those will be more thouroughly tested.
Anyways, it doesn't matter to most end users if the changelogs were longer. Only a minority of end users would be able to understand them or care. Take Andrea's changelogs. They are normally quite in depth. Here is an actual excerpt: [kernel.org]
I mean... wasteful cows???
Of course, I'm fairly sure that if you wanted to write some really great changelogs then either kerneltrap.org or linuxtoday.com would post them for you. I would definately read them.
Re:Kernel changelogs (Score:2)
copy-on-writes, presumably.
interview answers [sic] (Score:4, Troll)
I have to agree with several posts that say inaccurate documentation is OSS Achilles' Heel. Sure, you could just jump in the fire and learn, but why not help folks out with some documentation?
What good is an OSS project if no devs join the construction effort and no users can figure out how to make it work? I'm not saying that you need a big fancy website and tons of UML diagrams, but don't just dump a pile of code and a makefile in my lap and expect me to be as giddy as a schoolgirl about the project.
Alsa? (Score:4, Interesting)
Re:Alsa? (Score:3, Insightful)
As I understand it, it's not a problem with OSS being wonderfully advanced or with ALSA being buggy, but just that ripping out the core sound code and replacing it with ALSA in a stable kernel seems like more work than it's worth, especially when it's pretty easy to build the drivers as kernel modules 'outside' of the kernel.
That said, I'm STILL looking forward to seeing ALSA go into 2.5...
Re:Alsa? (Score:2)
http://lwn.net/2001/1206/kernel.php3
-l
Linux Dude #3 uses windows.... (Score:4, Insightful)
I can't that you can blame him, personally I don't run windows, but I also don't play many games... However, almost all of the really good games at the moment are either console or PC only.
Most of the rest of the interview was pretty much what you would expect anyone to say, this is the only bit that jumped out and said "boo" to me. If we can keep him to his promises though Marcelo looks to be every bit as good a maintainer as Alan and Dave.
Re:Linux Dude #3 uses windows.... (Score:2)
Question: if it turned out he owned, say, a Playstation 2, would you bother to mention that as a significant point? It's a non-Linux game console, no different than a Windows PC used exclusively for games. In fact, a PS2 is about the same price as a crappy Windows box. Chances are that you own a PS2, and don't see a problem with it not running Linux. So why does his owning a Windows box for that purpose deserve special mention?
I can't that you can blame him
If you can't blame him, then why the heck are you bothering to complain about this?
ALSA (Score:3, Informative)
I won't believe any claims regarding this until it happens however. There has been a push to include it for a long time.
Luckily the project has gotten past it's biggest old problem, which was constantly, drastically, and suddenly changing the API, breaking many programs and pissing lots of people off, not to mention making it completely in flux.
we'll see
Re:ALSA (Score:3, Informative)
http://lwn.net/2001/1206/kernel.php3
-l
best NON-interview ever (Score:2, Funny)
Question: Will you introduce XXX into the kernel?
Answer: I will do the job of kernel maintainer.
Question 2: Do you like cheese?
Answer: I will do the job of kernel maintainer.
Question 3: Do you know your pants are on fire.
Answer: Only if it is in regards to maintaining the kernel.
I have seen more personality on a head of moldy lettuce. But hey, good luck to you man, and don your flame retardant suit, you are going to need it.
A little on the young side? (Score:2)
Re:A little on the young side? (Score:5, Informative)
Like you said, give him a chance.
Re:A little on the young side? (Score:2, Insightful)
Just an observation....
Re: young genius ? has experience (Score:2)
Ok, ok, don't get bent. I'm not putting him down for being a teenager. And I'm 29 BTW. I may be insecure but not about my age
But you have to think for a second that a teenager is maintaining the freaking main Linux Kernel already. That's some pretty serious pressure. Then again it's probably just computer program to him so it shouldn't matter right? Don't come cryn' to me when the kid turns out like Gary Coleman
A good interview with the new kernel mantainer!!!! (Score:2, Informative)
Curt is not a problem (Score:2, Insightful)
Okay, fine: the interview was a little dry. Perhaps, 5 years from now, we'll have trouble remembering it.
What the hell do you expect from a kernel maintainer? Trust me, you don't want revved-up and passionate...because he'll make revved-up and passionate mistakes. Marcello wasn't hired because of his strong views on the future of technology...he probably just does his job really well. I wish I could say the same about many people I've worked with.
Mmmmnnnnn... (Score:2, Insightful)
On the other hand I am not sure Marcello was the correct choice for 2.4 maintainer (no offense intended... read on). In my opinion Alan should have handed the relatively mature codebase that is 2.2 on to Marcello so he could get to grips with maintaining something that is already pretty mature. Giving him 2.4 is kinda throwing him in at the deep end because we all know it has a long way to go before it is what it could be. Also, with 2.4, SGI, IBM and all the others will be hounding him with patches that they want in the kernel, this would have been less of a problem with 2.2.
However... I love to be proved wrong.
(PS: I think the biggest complement a maintainer can get is to be told that you want him to maintain the next kernel release too. Thanks Alan.)
Re:Interesting interview but... (Score:2)
One wonders what this guys trying to defend. I wish this guy who let us know for whom he works, and what he does
You can tell the coders... (Score:2)