Slashdot Mirror
2.4 Maintainer Marcelo Tosatti Answers Your Questions
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. ;)
If you were on the Linux Kernel Mailing List the past two weeks, you would have seen how much email your simple question can generate. The flame war about style lasted for at least 3 days. Check the thread at:
n el /0111.3/index.html
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
"Do you guys read your own site?"
-no.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I think he meant he wants to use LTP, not STP.
STP isn't much use for testing kernel pre-releases.
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.
What I'm listening to now on Pandora...
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)
As a reader of the kernel development mailing list, I think I can answer this question, although I certainly don't claim to speak for Marcelo or anyone else...
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.
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
ALSA is a major code change and will not happen on a minor release. Expect it for inclusion only with development trees (and then rather early on).
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
Marcelo gave a good interview to a Brasilian magazine, talking about his self and how he met linux. the interview is in portugese but you can use some sort of translator on it.. Folow the link: http://epoca.globo.com/semanal/_materias/entrevist a.htm
Wow. Could everyone here cut Marcelo a little slack and be nice, if only for a little while? I just don't see the point of making hurtful remarks like that about a complete stranger, especially one that young. He's obviously talented or he wouldn't have been chosen, and I'm sure he's going to do the best he can with his new responsibilities if people let him. And, really, why are you assuming that he's not "a balanced human being?" What a lousy stereotype.
Like you said, give him a chance.
rtsp://mediafarm2.rjo.embratel.net.br/~parana-d/pr 2linux091101.rm