Slashdot Mirror
Interview: Alan Cox Answers
Phil-14 asks:
Do you think that non-x86 versions of Linux will forever remain on the periphery, or will Linux actually become a
force for platform independence?
Alan Answers:
The focus of developers is always going to reflect the hardware people have.
As non x86 machines become more prevalent the importance of the kernel port
will do so. PowerPC for example has gone from being a fringe BeBox project
to a major platform.
Embedded systems and palmtops are likely to increase the amount of non-x86 linux platforms. The price squeeze is also going to take its tool - there are simpler cheaper processors and in the end that pricing will begin to count big time.
Intel clearly see IA64 eventually replacing x86. It may be in time that the x86 port is viewed in the same way as the 680x0 port. It may also be that IA64 is a turkey, we all run AMD K7's and x86 lives on. Its a guessing game.
asad asks:
Do you see yourself still working on Linux 5 years from
now? What about other people on the Kernel mailing list? And
do you think the quality of the code people now write for
Linux is still up to the standards of the old days ?
Alan Answers:
I have no idea what I will be doing in five years. Somehow I suspect it will
involve Linux and Red Hat a great deal.
The code standards haven't changed much. Linus is very keen on having clean modular and maintainable code. We have ugly code in there, but its mostly in specific drivers and quite frequently coping with ugly hardware.
Linus is picky, but Linus always was picky. Linux is as good as it is because he is prepared to be a right pain about doing things properly.
aheitner asks:
Okay, there's not a Linux hacker on the face of the planet
who wouldn't kill to have your job.
- - Paid by RHADL.
- - Wake up when you want, work when you want.
- - Go to all the big trade shows.
- - Work with the likes of Linus and all the other regulars.
- - Get free toys (and I mean good toys) like PA-RISC systems from HP and Athlons from AMD.
Alan Answers:
I'm actually paid by the support side of Red Hat not RHAD labs. That
might sound strange but if you are selling high end support to people they
want to know you have someone to fix the really bizarre, and you also
need people who can. So in many ways I'm in support.
I did it because it was fun. I'd been doing other free(ish) software stuff like AberMUD before that. I got into Linux to have a better development platform for AberMUD then got side tracked somewhat into hacking the OS.
As for the toys. New toys are fun whether they are expensive or not. The important thing is new. So I had lots of cheaper strange devices I was hacking on before - like the Macintosh 68K port, and Linux 8086.
The advantage of working for Red Hat is much more time than money: So many toys so few hours.
Techno_Jesus asks:
I'm always concerned with redundancy and I think the linux
kernel development could benifit from it the same way our
servers can. If something were to happen to Linus (albeit
very tragic) would you or someone else be able to take the
weight that he bears for the kernel development process? I
fear that the community is putting all it's eggs in one
basket and perhaps you are the only viable replacement.
Alan Answers:
It used to be "what happens if Linus gets hit by a bus" now its
"What happens if Linus and Alan both get hit by busses". I guess someone
like DaveM would take over (yes next years question is "What happens if
Linus, Alan and DaveM get ...")
Kindjal asks:
How is the whole linux-on-sgi thing going? You were
originally the guy behind that....what's your opinion on the
sgi embracing linux stuff happening now?
Alan Answers:
I was hardly the guy behind it. Dave Miller did the original ground work while
at SGI. Ralf Baechle did a lot of the other work along with Miguel de Icaza.
Almost all the work I did was on fixing up userspace packages and building
install and bootstrap tools.
The SGI I had is now in the hands of some other people who are still working on it. There is a lot of work within SGI on the new x86 machines and some work on the mips boxes. Check out oss.sgi.com
Amphigory asks:
I notice here that you were involved in the creation of
the nano-x project at some point. What is your opinion on
the continued viability of X-Windows? Should the open source
community be focusing on developing something better, or is
X the best we can hope for?
Alan Answers:
Ben Pfaff wrote a library for Debian called Bogl that did basic drawing but
was very compact - ideal for non X boot disks. I had a copy of an old Minix
library called mini-X and I stuck them together. Alex Holden and others then
decided to actually clean it up and make it work usefully.
Its good enough to play minesweeper and probably doesn't need much work to be able to use it as say a Mozilla front end or to port gdk (and thus gtk/gnoem) to it.
For most things X11 is far superior. X is bad at some things - notably code size and handling fast 3D games. These are all getting fixed. X is a very flexible framework and there is little wrong with X itself as a system. XFree 4.0 should do a lot to polish up the implementation. Its rarely a good idea to throw out 15+ years of work because it has a few glitches. X is probably relevant to everything but small PDA devices or set top boxes. My interest in Nanogui is with the Psion5/Geofox Linux port where you have very tight storage constraints.
Borg[9 of 9] asks:
Alan, with the upcoming 2.4 kernel is there any work
being done to address Linux tcpip performance issues? Is
there any plans on making the IP stack multi-threaded and
what about the stack spin lock issues on SMP machines?
Alan Answers:
DaveM, Alexey Kuznetsov and others have been working on this very hard. It is
one reason the 2.3.x tcp/ip is currently a little wobbly. It is however all
happening.
John Fulmer asks:
I'm a network security person and have always been
intrigued by the concept of the 'hardened' BSD kernel (which
isn't really THAT hard), and some of the role-based and
compartmentalized systems out there.
What is the status of the security of Linux' overflows and root hacks) and what do you see as the overall direction, if any, of Linux's security beyond the standard UNIX security model?
Alan Answers:
Ok Linux 2.0 is absolutely traditional. Later 2.0 adds securelevel which gives
a little more security at a usability price. Linux 2.2 uses capability sets so
you can give processes finer grained rights. You can also revoke rights for all
processes which can be useful in higher security environments.
There are people playing with role based models on Linux, although not in the mainstream kernel tree. There are also projects like Stackguard designed to catch buffer overflow attacks. Ultimately the only real way to improve security is careful auditing of packages. On the whole this works. Almost no packages that have been audited have future security holes logged against them. The Linux security audit project is the place to get involved with this. Anyone want to audit the perl interpreter ?
emil asks:
While I realize that you might not be completely
objective about this question, what do you think of the
design of the HURD, as it compares to Linux?
I once asked Linus himself this question and he replied in rather annoyed tones that "the HURD is a great academic design that would never work in practice" (or something along those lines).
Richard Stallman has been steadfast in refusing to endorse Linux as the GNU kernel. Does he raise these objections merely for emotional reasons, or does he see the HURD as having real technical advantages to the current monolithic design?
Alan Answers:
HURD is a great concept. Like most great concepts it isnt
efficiently implementable I suspect. Hurd is a GNU vision and every
project needs some lofty probably unachievable goal.
The HURD design is more about Richard Stallman's ideas about how a system should work to promote community than about high perfomance OS design. Linux is a bit more pragmatic about things. We took ideas from the microkernel world (like loadable device drivers) but we didn't take the accompanying partitioning and performance loss.
HURD is a rich flexible environment where the user has a lot of power to say "no I don't like that, I'll write my own code and use it" - even for things like filesystems. Right now HURD is a research project. Maybe one day it will become a useful OS.
Tekmage asks:
How has the multicultural and multilingual participation
affected the development of Linux as a whole?
Have you begun to see evidence of third-world participation effecting the progress of Linux yet, or is it still in the "hope to see soon" category? What needs to be done/changed to assist in the cross-cultural adoption of Linux? (Unicode?)
When can we expect to see a Linux Universal Translator Engine? :-)
Alan Answers:
We have uf8 unicode support in the kernel for stuff like the console and file
names. We have Japanese X11 fonts. Gnome and KDE have a lot of translations
although mostly to left to right rendered Western european languages. Its
a start.
What do you call third world ? Really its a gradation, and also a lot of it is based on perception. I get code and patches from countries as culturally varied as India, and Iran. There is a noticable amount of activity in Brazil, both with the kernel and other packages. The real third world countries don't really yet have the infrastructure to support the Linux development model. Linux helps to give them the tools to create that infrastructure and I am sure in time it will come when I get kernel patches from these countries too.
Developing countries are also in a good position to benefit from the opening of the market. It doesn't matter where I am on the globe providing I have part time connectivity, electricity and computers I can do Linux development work for companies anywhere in the world - this is one of the other great things about my job. If I wanted to move country there are almost no logistical barriers to doing that and continuing to work for Red Hat.
Actually promoting cross cultural adoption of Linux is hard. It has to come from people in those countries. Maybe I can get away with putting together a French language Linux distribution in the UK, but to put together a good distribution for any significantly different culture I think you need to be part of it. I expect a lot of the growth in support for other languages, and cultural needs to come directly from people hacking the code in the countries that need it.
Linux development isnt centralised in Redmond so you can go out and do this. Most of the time we can communicate world wide. Not always. Its really hard sometimes to follow Japanese Linux projects in Europe and the USA. I guess the reverse is probably true.
Next week's interview: Tim O'Reilly
If one does NOT understand the source code one does _NOT_ have any business messing with it. Documented or not dumented. Period.
Is there a place to find out what acronyms like this stand for?
Not that I know of. It doesn't seem to be in the FAQ.
Some people are happy to compile code they don't completely understand just to see if it works, and this kind of code should be guarded against in production software.
Hooo boy, you said a mouthful! I used to work with a guy (since fired) who would just flail around helplessly, until by trial and error something worked. I saw functions he'd written that were 50% dead code; sometimes there were branches that could never happen, and sometimes a return right in the middle, with ten lines of code after it. Horrible. He'd also write switch's with three lines of code in each case, two of which were the same in every case. Oh, my gawd. Sorry to vent, but I still wake up in a cold sweat over that stuff.
This kind of understanding should be a prerequisite for any code being included in a project.
Yeah, and it works retroactively too: I've often finished a function or a whole class, and then sat down to describe it. The process of trying to boil down the code into a clear and concise summary is very helpful in terms of stepping back and seeing what I've done in broad terms, and deciding whether it's what I should have done. It's a forest v. trees thing. Teaching a subject is the best way to learn it; documenting your code is the best way to give yourself an overview, as well as providing an overview for the poor bastard who has to maintain your spaghetti
More than thirty km? I don't think you'd be too concerned about Linux after the gigantic explosion that would wipe out maybe a good amount of a continent (if not more), and were at the beginning of an ice age because the sun's light was being blocked out.
- They always get out of date.
- They give tons of false hits when I grep.
- It's not what I want to know anyways.
The purpose of a comment is to say what the designer would say if the designer could be with me and have a conversation. Occasionally this is some commentary on the parameters. It's almost never "who calls this" because the answer is almost always "whomever needs it".Design comments are good. Mechanical function headers are bad.
i think if we are missing a hemisphere linux will drop down to priority level 2, right behind the gapping hole in our planet
t seems that the corporate and open-source development models have at least one flaw in common: insufficient documentation. He said corporate(Microsoft) and open-source (Linux) have one flaw in common (I was almost tempted to use BLINK...not really :) ).
Avoid the busses! For they are a real threat to Linux development.
No he doesn't me
It is
Read this again...carefully:
:) ).
>He said corporate(Microsoft) and open-source
>(Linux) have one flaw in common (I was almost >tempted to use BLINK...not really
Did he say "corporate" mean (Microsoft)
and "open-source" mean (Linux)?
He is a software developer of Microsoft but
doesn't mean "the corporate" written there
equals to M$.
Linux is a open-source project
but "open-source" community is not equivalent to Linux.
M$ is a fscking software corporate, but
more "corporate" are out there.
"You completely failed to understand his message"
I really like people mocking himself/herself.
I wished you had blink that sentence.
I've programmed in Win32 API and MFC and I can say both are easier to do than GUI programming under linux. Soure code is useless to a developer who just wants to write a damn application. The documentation on the Win32 API and MFC are both not excellent but are more than adequate which is alot more than I can say for GTK. I've bought books, printed out Tutorials, read the docs and I still have no clue how to make something in it. Kernel source is one thing...GUI source is another
See? No one is right.
2. Third world is technically defined as countries that are neither part of the Western alliance of NATO and friends (first world) nor the Warsaw Pact and friends (second world). There is no fine gradation.
I'm guessing the moderator were told to ignore questions from ACs. Is there a better explaination?
Aww.. he must have a cold -- "bank" is the word ("banque" if you're french, "benck" if you're German or "%%$£&*^"£" if you're not using the right character set and trying to type in Japanese =) Sorry for being so damned picky but I couldn't resist! (and I'm Belgian, **everybody** gives us a hard time...)
The phrase "third world" was actually coined by former Indonesian president Sukarno in a speech referring to impoverished countries like Indonesia. It was probably intended to mean third rate. Sukarno didn't bother identifying the first and second worlds, which is why no one ever hears about them.
Linux is a open-source project but "open-source" community is not equivalent to Linux.
This doesn't have any bearing on the rest of what he said, of course, but given that this is a discussion about the Linux kernel, it's not much of a stretch to suppose that a participant in the discussion might be discussing the Linux kernel. Or is that too complicated for you? At any rate, Linux is a canonical example of "open source development", so it's very much to the point.
M$ is a fscking software corporate, but more "corporate" are out there.
That may be so, but the guy was talking about his own experience, and Microsoft is the company where he works. When somebody says, "I work at Microsoft, and my impression of corporate software development is this . .
What I'm saying here is that even if your point weren't ludicrous, it would still be irrelevant.
"You completely failed to understand his message"
I really like people mocking himself/herself. I wished you had blink that sentence.
Leaving aside your strange plural/singular practices, are you trying to claim that the post you're criticizing "completely failed to understand" anything at all, or even partially failed to understand it? If so, please provide some kind of rationale. Post A made some general remarks about the two development models; post B provided specific examples, which happened to be the most obvious and relevant examples available. What exactly is your problem with this? A specific remark may or may not be generalizable, but a general remark had damn well better apply to all relevant specifics. For example: If somebody mentions that birds have wings, it's perfectly reasonable to bring up the subject of geese. By contrast, a remark about geese may or may not apply to birds in general. Are you still with me here? Probably not.
It's nothing short of mazing to me that people like you run around loose in this world and expect to be taken seriously.
this is a recent "issue" with me because I've had to pick up the pieces from some asshole who thought he was too good to research and document what he was doing before he went coding some difficult and sensitive code. Result?? I rewrote the whole damn thing...properly.
I hear you. IMHO the phenomenon we're seeing here is that a large minority of Slashdotters who make programmer noises have never had to work on anybody else's code, nor on any programs that strangers had to use and rely on, nor even on any code they themselves wrote more than a week ago. Hey, when I was in school I thought unreadable code was clever too. Most of them will grow up, sooner or later. The rest will find their level of incompetence at a young age and live happily ever after.
(This is the AC you replied to)
I've programmed in Win32 API and MFC and I can say both are easier to do than GUI programming under linux.
I've looked at some GTK docs a bit, but I never tried to code with it. I'd think that there are probably some relatively trivial programs out there written with it, which would serve as example code; but finding them is another matter
Kernel source is one thing...GUI source is another
Um, yeah. I'll buy that.
Soure code is useless to a developer who just wants to write a damn application.
With MFC, the source often answers the musical question, "why the f*ck did that blow an assert?!". Sometimes the answer is "because somebody put an assert there", but that's better than nothing, I guess
you're a moron, huh? Why don't you take the time to read the comment AND understand it.
Can we get these annoying advertisements moderated to -1? this has no relevance here.
-GoNINzo, trapped behind a dead DNS link.
While the theory of subscribing is nice, I've tried it three times (with three different *valid* email addresses), and never have recieved an account ...
Programming a functional QT or GTK-- app is trivial. A VC++ app is a freakin complex nightmare compared to the ease of QT. Why was something like Lizard so easy to write? QT Rocks.
Well, I don't know where you get your "information" from, but there are definitely more people working on the Hurd than two. Of course, we don't draw that much attention as Linux. And we don't have so many developers. But there are quite some people working on the Hurd, many not full time, and you won't see many of them shouting out loud what they are doing currently. The Hurd is alsr a research project, because it is innovative. It does not try to copy only, but really implement new features in the Operating System. This is a lot more work than just copying POSIX. The Hurd is also a useful OS, it implements the full POSIX standard and has become quite bug free by now (of course, there is missing stuff, and there are a lot of known bugs, but no critical ones). The Hurd is available in source code and as a binary distribution. New software is uploaded regularly, we are working on completing the distribution (with an auto-builder) and creating boot disks for convenient installation. Please see http://www.debian.org/ports/hurd, ftp://ftp.debian.org/dists/sid/main/binary-hurd-i3 86/, http://www.gnu.org/software/hurd There is no need for animosities. The Hurd and Linux will go along very well for a long time. Development on either machine will help the other. Don't allienate, please. (Marcus Brinkmann, , Debian GNU/Hurd coordinator)
none of the AC posts carried a Score (they usually do),
Hmmm. If they had no score at all, rather than just defaulting to zero, that looks very much like The Mangement decided something. I didn't see that discussion, though.
Of course, Slashdot always has an undercurrent of blind anti-AC cretinism ("blind . . . cretinism" as distinct from people who just recognize the fact that a lot of AC posts are crap while judging all posts on their own merits), but I don't know if it's enough to have had a big effect on the moderation there.
Sorry, I meant "Literate Programming", by Donald Knuth.
I thought the reason /. didn't want to let interview subjects pick their own questions was that if it was a politician or business type they might only pick favorable questions to answer and duck the hard ones. The way it is now, if they duck a question at least we know which ones they're afraid to answer. Another problem with letting a lot of anonymous coward questions through is that a politician or someone like that could pack the house with questioners friendly to them. At least the moderators have been on /. a while so it keeps things sort of honest. I've been a moderator and no one told me how to do anything except for the published page on it. - Another victim of a slow-to-update DNS who can't log in right now
I agree in theory, but in practice, what often happens is someone writes a comment, and then someone else changes the code but not the comment. Now you're worse off than if there was no comment to begin with. What we need more of is stuff like asserts, which enforce hidden assumptions as well as documenting them. $0.02
I agree with your complaint. The kernel documentation is lame. The classical answer to your question is: "anyone who wants to write docs is free to do so and send doc patches to Linus". I've done that, and it does work. But my answer is: "the kernel will be as documented as Linus cares to make it". If he chose, he could reject patches with insufficient documentation. The open source model actually has a much stronger change control model than the usual closed-source "everybody can check into the master". I wish Linus would exercise his gatekeeper function more strongly vis-a-vis documentation. But hey, if I don't like it, I could always start the Documented Linux Kernel fork.
Simplified, you could say DBC is like a fancy assertion mechanism (hope I don't get flamed too much for saying this). The idea is that for each method of your object you define a precondition (the client's part of the contract) and a postcondition (the objects part of the contract). In addition object has an invariant (if you're any good at C++, you've already made invariants for all your classes).
So let's say we have a method foo(int) that has a precondition which states that the integer must always be something in the range of 1 and 10. If the client (the party calling this method) does not fill in its part of the contract by providing an argument that is valid, in range of 1-10, an exception gets thrown.
Our postcondition could state that after the method has been executed, some field, let's call it bar, is always set to zero. If it's not, again, an exception gets thrown. Also, before returning from method foo, we've checked the invariant for this object guaranteeing its valid state.
So, what you in fact are doing, is formalizing your design in the code. You set up pre and postconditions, and the compiler takes care of generating the proper code to enforce these rules. Instead of you having to do if-elses for all your params at the beginning of your method (error prone and very easy to forget), you let the compiler make sure you're handling proper arguments.
One day, we may see design-by-contract in a cool, practitioner-friendly language
I'm not sure what makes Eiffel not practitioner-friendly. Other than that it doesn't look like C. Care to elaborate?
Any tool or language feature which promises to solve your problems for you, will simply make matters worse
I don't believe DBC promises to solve your problems for you. What it does do, however, is it helps you to put some of your design into the code, in a way that is easily recognizable to people coming and reading it after you're long gone.
I definitely agree with you about RAD sometimes making things worse, though.
Don't be such a pessimist!
;)
;)
Maybe it'll miss the Linux conference and hit Redmond instead
- Anyone else find it disconcerting that we're talking about a meteor hitting the planet and the concern is whether some of the upper eschelon Linux developers are taken out? Statistics repeatedly indicate a higher proportion of "rational" thinkers in IT fields - I think we're doing our best to combat this image
Actually, we pronounce 'aluminium' as described, but we don't bother pronouncing 'aluminum' at all.
After all, what price consistency..
Helum
Beryllum
Magnesum
Aluminum
Calcum
and so on..
..d
Ofcourse with the proliferation of linux on the desktop and on the business world.. and now it claims to be ready for the enterprise.. once again i like to say .. that the linux community don't say to much or too proud of it yet. based on 3 landmark articles i've read stating linux shortcomings, one by Mark Russinovich (his article on "Linux and the Enterprise", second by ZDnet's benchmark (where it had plateau chart graph on smp benchmark and network benchmark), third alan cox recent interview and i quote " Borg[9 of 9] asks: Alan, with the upcoming 2.4 kernel is there any work being done to address Linux tcpip performance issues? Is there any plans on making the IP stack multi-threaded and what about the stack spin lock issues on SMP machines? Alan Answers: DaveM, Alexey Kuznetsov and others have been working on this very hard. It is one reason the 2.3.x tcp/ip is currently a little wobbly. It is however all happening." as u can analize Sir Alan Cox is talking about linux kernel 2.2.4 its sometime to realized in the future it doesn't say that AS OF NOW the linux kernel is that stable and reliable .. where talking PRESENT here not the "FUTURE" compared to other Network which seemed to have meet furfilled these challenges.(like Solarisand the very windowNT but winning and have an edge, BSDs ). so I think Linux users should consider thinking about it , and think on better way of improving linux rather than jumping on every aspect of the computer industry(from servers, desktops, embedded, what next linux-based-dog-house?)
Ofcourse with the proliferation of linux on the desktop and on the business world.. and now it claims to be ready for the enterprise.. once again i like to say .. that the linux community don't say to much or too proud of it yet. based on 3 landmark articles i've read stating linux shortcomings, one by Mark Russinovich (his article on "Linux and the Enterprise", second by ZDnet's benchmark (where it had plateau chart graph on smp benchmark and network benchmark), third alan cox recent interview and i quote " Borg[9 of 9] asks: Alan, with the upcoming 2.4 kernel is there any work being done to address Linux tcpip performance issues? Is there any plans on making the IP stack multi-threaded and what about the stack spin lock issues on SMP machines? Alan Answers: DaveM, Alexey Kuznetsov and others have been working on this very hard. It is one reason the 2.3.x tcp/ip is currently a little wobbly. It is however all happening." as u can analize Sir Alan Cox is talking about linux kernel 2.2.4 its sometime to realized in the future it doesn't say that AS OF NOW the linux kernel is that stable and reliable .. where talking PRESENT here not the "FUTURE" compared to other Network which seemed to have meet furfilled these challenges.(like Solarisand the very windowNT but winning and have an edge, BSDs ). so I think Linux users should consider thinking about it , and think on better way of improving linux rather than jumping on every aspect of the computer industry(from servers, desktops, embedded, what next linux-based-dog-house?) posted by Vangarde
it's teeming with asserts. clogged with the damn things. and a good thing, too -- the documentation is so rotten that often the only way to understand an MFC function is to watch your code crash in the debugger, step to the assert, and read the comment next to it. sometimes there's no comment though, and then you just have to grovel through the code for a while.
:)
Bullshit.
Sorry it had to be said but that's what it is.
Having the source does NOT make up for lacks in documentation.
AC, who maintains a code that has SOME documentation, most of it too fluffy to help fix real problems, and has all the source available, and thinks anyone who says source code is good enough of documentation should be burnt on a stake.
What nonsense!!! It is ONE MILLION times better to have good, easy to read code with good, sparse comments than it is to have poorly written code with hungarian notationed, function headered , useless, please the auditors comments. Only a PHB or a rookie who believes his PHB beleives otherwise. Function Headers DO NOT make the function correct.
The worst situation of all is when the function header is all wrong but the PHB thinks it's great code because it's formatted so nicely. Actually, you comments say a lot about how Microsoft implements its software. Gimme and Allan Cox "hack" anyday. At least I have the source to read it myself. Hey Mr. Microsoft programmer, where's your source code????
We have the source code available. That means the actual implementation of our design is available for EVERYBODY to look at and critique.
Yeah, but he's talking about documentation for people working on the code, who by definition have the source; he mentions commenting function definitions and so forth. He's right, too. It's good practice, and as long as the comments are kept in sync with the code (which is not a trivial requirement, I know) it makes everybody's life a hell of a lot easier. Source code as end-user documentation is another matter, and we all know the drill on open source development. I'm not disagreeing with you about that part at all.
At a certain fundamental level, I want the kernel to not be super easy to hack on. This keeps people like me from burdening down Linus and Alan with poorly thought out patches. If, there is a certain level of expertise required, then only those people who can actually throw down and do it, do it. This isn't to say that all code should be self obfuscating. Rather, to say that some times, complex systems are complex, and that Joe Average User, who was weaned on GUI's, is rightly going to have a hard time figuring them out.
(Sorry to quote such a huge chunk of text, but I didn't know where to cut that paragraph, because none of it seemed off dispensible.)
The point about keeping the dingbats out of the code is one that'd never occurred to me, and whether it's valid or not (I don't claim to know), it's appealing to me in a weird sort of a way. The problem is that the people who can make a worthwhile contribution, would be more likely to break something they don't know about in so doing. In any case, somebody above claims that the Linux kernel code is very well commented, but I've never seen the code so I can't vouch for that.
One can only hope the point gets across. It's high time we start thinking about software maintainability and start seriously thinking of ways to provide adequate documentation for all our software, closed or open. We need new mechanisms and new tools to help us document our software and to keep the documentation up to date.
The thought process inside the hacker's head needs to be put on print. Just showing us the source code means more than half of the vital information is lost.
I'm not sure what you meant, but 'buss' means 'kiss'.
if you're any good at C++, you've already made invariants for all your classes
I'm not a divine master of C++, but I'm pretty solid with it; however, my face is a bit red here because I don't know what an invariant is; possibly something like AssertValid( ) in MFC?
You set up pre and postconditions, and the compiler takes care of generating the proper code to enforce these rules.
Um, to me that sounds somewhat analagous to C++ guaranteeing that the destructors of automatic objects get called, in contrast to C style "OOP" where you have to remember to call "destroy( struct foo )" on everything before you return.
It's sort of an extension of static type checking; like Pascal lets you define range-restricted integer types (which I've on occasion kludged in C with enums, and in C++ with enums and also weird templates that, essentially, enforce preconditions by hand).
I don't believe DBC promises to solve your problems for you.
I expressed myself poorly, I think. I should have said that any good language feature can be used well, or abused; and trusting the feature to do your work for you almost always results in abuse. It's people who can come down with silver-bullet syndrome, not the tools themselves.
What it does do, however, is it helps you to put some of your design into the code, in a way that is easily recognizable to people coming and reading it after you're long gone.
Or even if they're buttheads who don't read it, if it works like asserts. Which is cool.
It's high time we start thinking about software maintainability and start seriously thinking of ways to provide adequate documentation for all our software, closed or open.
People have been agonizing over this for decades. Knuth, among others.
I agree, though: It does absolutely bear repeating. It's better to repeat truisms than to repeat history, as you might say.
Before it's too late.
Wow, in your haste to flame Microsoft, you completely failed to understand his message.
:) ). Documentation is a means, not an end. Documentation doesn't necesarily make better software...it gives developers the ability to make better software. As a result, the "good software potential" for every developer, whether open or proprietary, benefits. That, my rash friend, is the point he was trying to make.
Read this again...carefully:
It seems that the corporate and open-source development models have at least one flaw in common: insufficient documentation.
He said corporate(Microsoft) and open-source (Linux) have one flaw in common (I was almost tempted to use BLINK...not really
ummm, i don't see how this is so hard. I have gotten 2 accounts very easily and am not logged in because of the DNS change. What if you tried sending the password to one of the usernames you registered?
It is ONE MILLION times better to have good, easy to read code with good, sparse comments than it is to have poorly written code with hungarian notationed, function headered , useless, please the auditors comments.
There's no reason to assume that those are the only two options available, nor is A "one million" times better than B. He's talking about good programmers making the effort to write good, informative comments for the benefit of other programmers.
Function Headers DO NOT make the function correct.
No, good coding makes the function correct. A good comment along with the good coding is very helpful. DEAL with it, that's the way it is.
The worst situation of all is when the function header is all wrong but the PHB thinks it's great code because it's formatted so nicely.
Whatever. You're babbling hysterically. Nobody mentioned PHB's until you reared your ugly head.
You strike me as a kid who think's he's a "programmer" because he reads Slashdot. Fuck off. Serious people (this includes Cox, who by all accounts does write comments) take their work seriously, whether they happen to be paid for it or not.
I'm curious about nanoX and microgui. Does anyone know anything about linux on Psion5? I'd be very glad bring my little machine back from (EPOC)death.
(I'm not an AC, I'm GnrcMan)
I think something bears mentioning here, because many people seem to be confusing source code with documentation. Source code does not in any way make up for a lack in documentation. The fact is, most software I've worked on hasn't been documented to my satisfaction. It's actually a really hard thing to do. There is absolutely no substitute for rock solid documentation. Many, many experts in our field have pointed this out. I think, as our field matures, more developers will come to realize this, and all will benefit.
Some good books referencing this: "The Art of Programming" jumps to the forefront of my mind. As does "Code Complete", which should be required reading for anyone touching code...of course, that is published by Microsoft Press.
GnrcMan (casey@sarahandcasey.com)
What we need is something similar Eiffel has a hint of. Design-By-Contract. We need to start evolving ideas like this, and designing new programming languages that support such features.
:)
Not knowing Eiffel, I'm not real clear on what that entails. If it can't be done without significant overhead, a language that has it is going to make very slow headway among C/C++ programmers -- who also will give up their pointers and potentially unsafe typecasts when Nick Weurth pries their cold, dead fingers from the keyboard. I speak as one who feels this way myself. The problem is that academically beautiful languages never really sink in with practitioners, because "cleanly expressing computer-science concepts" is not exactly the same thing as "writing code that does stuff". Practitioners do the latter. This is why Pascal is dying and C is in good health; C preserves a lot of what made Pascal good (e.g. a bias in favor of structured programming), while rejecting all the mother-knows-best features that made Pascal vile. A serious general-purpose programming langauge must never lose sight of the fact that it's being used to program a real computer in the real world; Pascal was designed with the express purpose of doing exactly that. So much for Pascal. (er, I'm drifting off-topic a bit here, but never mind) One day, we may see design-by-contract in a cool, practitioner-friendly language -- but then again we may not. The big question is, "does it get on the nerves of practicing programmers"? If they find it to be more hassle than it's worth, they're not going to go along with it. A new generation of programmers may be more willing to buy into such things than the current crop -- hell, I have a fiftyish uncle who swears to me that structured programming is overrated, and that we should all just use goto's like the good Lord intended. (He's a nice guy, but I wouldn't hire him if you put a gun to my head
There's also the silver-bullet syndrome: Any tool or language feature which promises to solve your problems for you, will simply make matters worse. Take a look at RAD tools, and the garbage that people do with them.
One last thing, regarding Pascal v. C: Damn, I sure do wish C had nested functions! That would be so handy for callbacks sometimes, or for clarifying loops. You can kludge it in C++ by defining a local class with a static member function, but that's ugly. Nested functions are the one feature of Pascal that I really groove with. Now, in LISP, oh, baby . . . anonymous temporary local functions! Man. That's just too cool.
i went to polyester.net. it sucks. theonion.com wins, hands down. ~ac
What? The Vogons? Can't you see, they want to tear my house down with this bulldozer, and you want to talk about aliens!?!
Nobody asked for the input of a developer from a company that was named after it's founders penis.
Red Hat, you mean?
Heh heh.
Anyhow, nobody asked for input from morons dumb enough to make jokes like yours. He's a programmer at least, which I doubt that you are.
We have the ultimate documentation and that is the source.
Uncommented source is not very informative. Learn C, maintain somebody's uncommented code, and find out for yourself. Or just read the other posts in this thread.
I'm not much of a Microsoft fan; I have cause to curse them just about every day. But that doesn't mean that when I take a break from coding I want to read bullshit from teenage idiots with attitude problems, regardless of their views.
SO be like him. Laugh! It's Funny! http://www.polyester.net
The best technology satire news on the web today!
Small world isn't it?
Yeah, but only one of 'em can do it at a time :)
No, coffee percolates. It doesn't perkolate.
i prefur my java perkolated and paid with a check not as a perk
The kernel documentation does seem to lack comments on every function parameter, and a comment header at the start of every function saying what calls it and what it calls. Indeed most comments seem to be warnings of some sort. However lots of comments would probably confuse patch. If you dig around the net, there seems to be plenty of information on how the kernel works. I've just downloaded 50 meg of compressed NT device driver kit, compared to about 13 meg of linux kernel. I am trying to be open-minded, but I am currently of the opinion that setting up some simple serial/parallel device drivers in linux would be about 10 times easier.
Before blatantly assuming you know your language, please consult www.dict.org. In both American English and British English, it is spelt "perk". PKE.
"One model I believe has a neato set of LEDs build into the case that rise and fall with CPU use. But don't quote me on that. : )"
Just to alleviate your curiosity, you are correct on this one.
A friend of mine has one of those and it's pretty cool to watch.
Almost hypnotic.
Posted by cookieman.k:
...
Have you done VxD programming ever under Win9x?
Try it with the DDK help only.
Good luck !
M$ sucks !, The OSS is the only good thing here.
If you cannot understand the internal kernel code, no docs will help you.
I think than more people understand good part of the kernel Linux code than M$ programmers understands their API.
Whics one API?
All of them !
By the way if you know the internals of the file system architecture of Win9x, told me wy is so crapy?
Whos desing is this ?
Can docs be writen for W*Dose ?
Why am bothering myshelf to reply to you
Until I hear from Alan that he's the one that requested only +5 posts, and not slashdot, that's a moot point. And if he did, I'll take the issue up with him instead.
Besides, you have your +2 rating, and are IMHO abusing it to call attention to what for you is a non-issue.
You're entitled to your opinion. However, if slashdot wishes to continue to be a free and open forum for all - they need to address this "non-issue". The truth is that ACs were put at a disadvantage. Comments ought to be scored soley and entirely on the basis of their content - not extraneous factors like whether you logged in or not. To do anything else is prejudice - and this can't be a free and open forum if prejudice exists within it.
--
Alan should have gotten the complete list, and replied to those that he found interesting and worthwhile - just like the last Q&A article from the kid on MTV.
If we're going call slashdot a public forum - we ought to have everybody on even footing for stuff like this.
--
It's flat out wrong - there were alot of people that spent alot of time crafting those questions - good questions, which were effectively ignored. Slashdot could have informed their readership ahead of time that ACs would be effectively ignored, and that only posts of a score of 5 would even be considered. It's common courtesy.
I think slashdot should appologize and show Alan the whole list. It ought to be up to Alan, not slashdot, as to what questions are answered. If slashdot wants to maintain any credibility as an open and public forum, it should immediately redress these grievances.
--
42
-- You are in a twisty maze of passages, all alike.
This is not funny, people! NASA puts the chance of an object of > 30 km radius striking the Earth within the next 25 years at 47% ! Such a strike, in addition to its potentially devastating consequences for the U.S. stock market could, given the right conditions [e.g. *ANOTHER* Linux conference in progress], eliminate much of the leadership in the Linux community.
We absolutely must begin immediate development of a global early-warning and interdiction system. If this global program should prove too costly, then I suggest we use localized variants [maybe a Smart Pebbles system], protecting areas such as Redwood City, Santa Clara, Wales, Research Triangle, and Monterrey.
At times like this we need to pull together and work for the greater good of Linux!
If only Slashdot could get Bill to do a Q/A?
Is there a place to find out what acronyms like this stand for? BTW, I agree with your comment. To document well, whether through commenting or design docs, you must understand your code well enough to explain it to someone else. This kind of understanding should be a prerequisite for any code being included in a project. Some people are happy to compile code they don't completely understand just to see if it works, and this kind of code should be guarded against in production software.
Posted by cookieman.k:
So, I misspelled some of the words.
That's because I am not a writer, just a
simple programmer. My mothertongue is not
English. I'll try to improve myshelf.
I was off topic anyway. I was angry on M$
products (which I must use day by day).
Thanks anyway.
Posted by cookieman.k:
Don't be scared.
You won't use my programs.
Anyway I am not just a Win programer.
I think every program wich run under Win
can give you the kind of 'pleasure' you are
thinking of.
Look with SoftIce in Win code, while you are
trying to do some driver stuff.
Thanks anyway for your reply.
The PowerPC port was originally done by Gary Thomas ages and ages ago on I believe early PReP machines. It was later expanded to CHRP and PowerMacs. The BeBox port hasn't gotten too far along. There are stable, but UP kernels for 2.0.31 or so, and there is a test kernel for 2.2.something. However, the Be port just hasn't had anybody with a machine and the time to do all the needed work. In short, Alan wasn't totally correct. :)
I GOT 18 disks on a raid!
~ ^~
Where's the memo on that one?
I see what you do on company time and bandwidth now....
^~~^~^^~~^~^~^~^^~^^~^~^~~^^^~^^~~^~~~^~
MS is already doing that. Didn't you know that MS used to be in Waco, Texas? Its only recently did they move all their resources to Redmond.
Waco, eh? Hm.. It wouldn't surprise me if MS has a high level manager or director working for them under the guise of "Data Koresh". It all makes sense now...
It is pitch black. You are likely to be eaten by a grue.
go read Knuth's Literate Programming and
use WEB and CWEB. Its like the reverse of code.
Instead of writing code with inline documentation, you write documentation with in-line code, then CWEB TANGLE's it into something the C compiler understands or WEAVE's it into documentation.
I write alot of my code with CWEB now.
As the subject says. Just an observation :-)
"The invisible and the non-existent look very much alike." -- Delos B. McKown
This isn't an issue confined entierly to this story. Sometimes when their are hundreds of comments on a story you want to browse only the comments which have been moderated up. You don't care if it was by an AC or not.
Similarly suppose you want to cut out all the flamebait setting your threshold to zero just won't cut it b/c if a registered user gets moderated down he's still at zero while setting it at one cuts out alot of worthwhile AC comments.
A good solution, when Rob has time, would be to make the AC gets -1 option in the preferences just like the small post option. Then when picking questions for this posts they could just not use the -1 for AC option
Marriage is the "pseudo-ethics" that cloaks the messy truth of sexuality in the raiment of propriety -- it's "Don't Ask,
It seems that the corporate and open-source development models have at least one flaw in common: insufficient documentation.
All too often one finds a section of code that is not commented in-line worth a damn, and there is no thorough "architectural overview" of the project to even help clue you in.
So to address the question, "What if so-and-so gets hit by a stampeding buffalo?", let's first address a larger issue: how can we get people up-to-speed on development projects more easily?
For several reasons your issues/complaints are moot.
1) We have the source code available. That means the actual implementation of our design is available for EVERYBODY to look at and critique. Design documents, review meetings, and a whole host of other mechanisms that the close source community has come up with to avoid open peer review simply are not as effective. How can I say this with certainty. Well, one easy way is to look at the speed with which OSS systems respond to security problems. Security problems are generally not easy to fix, and require a relatively high level of expertise to identify and correct. Yet, OSS continously addresses them more rapidly than closed source software companies.
2) At a certain fundamental level, I want the kernel to not be super easy to hack on. This keeps people like me from burdening down Linus and Alan with poorly thought out patches. If, there is a certain level of expertise required, then only those people who can actually throw down and do it, do it. This isn't to say that all code should be self obfuscating. Rather, to say that some times, complex systems are complex, and that Joe Average User, who was weaned on GUI's, is rightly going to have a hard time figuring them out.
scottwimer
-- Beer. It's what's for breakfast.
At my last job, the phrase "what if gets hit by a bus?" arose a few times. We, the work grunts, decided that being hit by a bus was the worst manner of death possible, so we started using the phrase "hit by the beer truck". Being hit by a beer truck was viewed as a more glamourous way of leaving this world. Somehow that made the morbid thoughts of what to do in case of someone's imminent death easier on the brain.
To quote Ziggy and his friend:
I want a death by misadventure,
Wanna die face down in some dude's pool.
Not gonna kick it in my sleep biting on my dentures,
When I die, Jack, it's gonna be real cool.
Not gonna die from drugs, don't wanna go insane,
Like that Pink Floyd guy, Syd.
I wanna be on a bus that crashes into a train,
Just like Ozzy Osbourne did.
(no man, it was a plane and a train,
and it was Randy Rhodes)
Plane and a train? Righteous Cool Death!
How's my programming? Call 1-800-DEV-NULL
This is the same BeBox that Phase5 did? Maybe I'm wrong...erm...
Yes
Have you compiled your kernel today??
Well, you can look at Dave Cutler's fan club - it's not quite the same, though. A bit scary, in fact.
-- Ed Avis ed@membled.com
I don't suppose this is the same Alan Cox as the one on the ELKS / linux-86 listserv?
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
Guys, you're all worrying too much. Remember that old TV show about Max Headroom? Edison Carter, a TV reporter, is almost killed when his motorcyle runs into roadbloack (which reads MAX HEADROOM 5' 8", hence the name). In the fear that he is about to die, his semi-evil corporate employers (Channel 23) have an in-house teenage computer whiz create a computer clone. Unfortunately, not everything goes right, as the computer clone (Max Headroom) develops a markedly different personality and from there on runs amock in Channel 23's networks. And a short-lived series was born.
I still find myself drawn to buy more Coca-Cola everytime I see it in reruns on the Sci-Fi channel.
Anyhow... Linus, Alan, et al., should just get computer clones made now, and we can 'release' them onto the networks of the world if anything happens to the real thing.
Feel better?
--Philip
"It's amazing how our industry is strewn with beautiful, dead technology and bitter engineers." --M. Huyck
When we talk about the "What if so-and-so gets hit by a bus?" question, I think the point is who will provide the vision, leadership and technical skills to keep Linux a stable, well-built OS. It's not about who understands how the kernel works and what each line of code does. There are many people who know code are have the capability to understand it, but, do they have the unique skills to be the driving force behind the kernel.
-harry
This from somebody who pronounces "aluminum" with two "i"s and 5 syllables. :-)
Having the source Makes up for SOME lack of doc's, but I bet I can write a small procedure in C that nobody will ever be able to understand if it isn't documented.
Memo? If you're subscribed to linux-raid then there were mentions of it.
http://www.bombcar.com It's where it is at.
Fellowship 9/11
the newsgroup is not the best place for questions like this. Please submit it to linux-kernel@vger.rutgers.edu
Please god, kill Bill Gates with a stampeding buffalo. I'll even drive the buffalo.
Then a couple of us social misfits should free some buffalo, so you can drive them and kill Bill Gates. Bless the Beasts and Coders!
Richard Frost
A quick question:
Have you ever actually _read_ Linux' kernel source code? From what I can tell, this is one very well documented project. Only, the source IS the documentation. That, and the kernel mailing list.
Floris
--- Your superiour intellect is no match for our puny weapons
http://www.kernel.org is the home site for the Linux kernel distribution.
http://www.linuxdoc.org is the home site for the Linux Documentation Project, which is also useful.
The uncompressed kernel source is just under 60 megabytes. Compressed, it is around 12. Text compresses very well.
Note that, in the future, if you ask a question, leaving an email address for replies is a Good Thing. All I can do here is hope you check your info page and see my reply.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
the BeBox was made by Be, and it had two 60Mhz PPC chips
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
ReadThe ReflectionEngine, a cyberpunk style n
and moderators don't get any information that we don't. there just regular /. readers. the only diffrence is there's a little HTML form for each post, that you can moderate up and down.
also, AC's start at one moderation point less then regular readers.
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
ReadThe ReflectionEngine, a cyberpunk style n
well..
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
ReadThe ReflectionEngine, a cyberpunk style n
use jpeg
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
ReadThe ReflectionEngine, a cyberpunk style n
Click Here I don't know if it has PHB (a term for retarted people who manage smart people, from the boss in dilbert) but it's got a lot of other acronimical information :)
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
ReadThe ReflectionEngine, a cyberpunk style n
This is really nice. It should get bumped up to informative/interesting..
-
ping -f 255.255.255.255 # if only
To agree and combind a few of your statements, MS is not as open as the alternatives. To get into development, I heard that it cost money to get into development. I remember when I had a hard time with linux a while back, before I knew what modules were, I modified the source to use IRQ 5 for com4. And it worked. I self-released to my-self a custom linux kernel to suit my needs. Getting into MS devel is a bit more involved (as you well point out).
-
ping -f 255.255.255.255 # if only
MS is already doing that. Didn't you know that MS used to be in Waco, Texas? Its only recently did they move all their resources to Redmond.
-
ping -f 255.255.255.255 # if only
Rightly said. I was following the thread and found a lot of good questions that I'd like answers to. I hope that part II is in the pipeline. It's not often that we get core developers answering questions from everyone else who do not (or is unable to) attend LinuxWorld and other frequently held linux conferences in America.
hmm...i wonder if all those linux support startups would agree.
-- your knees hurt, don't they?
Not "a" BeBox. "The" BeBox. A nifty chunk of hardware based on the PPC designed to run Be from the get-go. I've seen them. One model I believe has a neato set of LEDs build into the case that rise and fall with CPU use. But don't quote me on that. : )
I keep trying to pick fights, but I can't shake this Excellent karma.
An example of why this isn't always the answer.
;)
A couple of months back I was writing a block-device driver for the Rio (MP3 player). The Rio (or actually the Flash) erases in 32K blocks, so I made my block-size 32K. When I did this the kernel went crazy.
So, great to have source, and yes, I was able to quickly find out that in a certain function there was a test to make sure block-size was smaller than the page size (which is 4K on x86). Since this test failed it caused the kernel to crash.
However, I could never find this explained/documented, so the question now is, is this a bug or is this by design? And if this is by design is that a good design,- what if I want to use my driver on an other platform that has even smaller pages?
I posted the problem on a Linux newsgroup and didn't get _any_ reply.
Breace.
btw. Je zit in ieder geval bij de juiste provider
Who's to argue with blinking lights?
If one does NOT understand the source code one does _NOT_ have any business messing with it. Documented or not dumented. Period.
Why do people always revert to this? This has nothing to do with the discussion at hand. Appropriate documentation makes it easier to understand the source in the first place! I am loathe to make broad sweeping statements, but, I must say this: People who don't understand the value of good documentation are missing a valuable and important aspect of programming. This "rambo" coding does nothing but degrade code quality.
Sorry, but this is a recent "issue" with me because I've had to pick up the pieces from some asshole who thought he was too good to research and document what he was doing before he went coding some difficult and sensitive code. Result?? I rewrote the whole damn thing...properly. I may have been able to reuse some of what he had, but there was no documentation. So I was forced to start over.
People who don't think documentation is valuable are coding in a black box. End of Story.
Generic Man
The problem as I see it is the disconnect between the documentation and code. Both are descriptions of what the software does, one is readable by humans, the other by the target platform. Problems in both documentation and code arise when the two descriptions aren't equivalent.
One early attempt to remedy this was COBOL. This was to be a computer language that read like a natural language but could be compiled to a machine language. Little documentation should be necessary given a well-structured program source. Needless to say, COBOL didn't really succeed, the mapping between language and operation was too clumsy to be very effective or useful.
Knuth's made some good attempts in the direction of unifying human and machine code specificiations in his CWEB tool.
One day, who knows how long from now, programming may consist of having a conversation with a computer, and explaining a problem to it in natural language, while the details of implementation and correctness are mostly left to the computer. Nice documentation may be output, right along with the executable binary.
If you think that is far-fetched, you may be right. But just this morning I read a report that someone has written software capable of reading a Time magazine and answering questions about it. Very impressive, if true.
Jim
I think it would benifit the community greatly were companies like Red Hat to pay people to document the more obscure parts of the kernel.
It's not just the kernel. Everything needs to be commented. And Red Hat should have the people working for them comment their code, sure. But people who are not being paid need to comment as well, or it won't work. If you write it, you comment it. Simple as that.
---
END OF LINE
An overall document summing up the source trees and how they connect in a gif would be nice.
;-)
Perhaps an updated Kernel-hacking howto would have such (I assume such a howto exists because I think I saw one, once
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
English is inherently an extremely bastardized language. Its rapid and continual evolution has in fact been a major reason for its success.
It is also a much less splintered language than it has been in the past when it usage was confined to a much small geographical area.
Alan could just as easily go to the comments section of the story where you should your questions, then he could read it and reply to more questions. Nothing is stopping you. Everything is out in the open. :) I'm sure /. wouldn't deny a second interview from Alan.
fou aje oym asoyf ueyf jaffaq afset su!6j!/\ op 'ua>|7!>| ppn7
Oh dear, watch out for Microsoft buying Greyhound.
fou aje oym asoyf ueyf jaffaq afset su!6j!/\ op 'ua>|7!>| ppn7
Might I inquire where one could get the source? I'd be interested in reading (at least some of) it. It sounds like a good learning experience, although it would probably take me several hours to download it all if it's 60 megabytes. Oh well. Any information would be appreciated.
I've come for the woman, and your head.
*gasp!* drop down to priority 2?!? why hath thou pushed such vile thoughts unto us all? no, we must push it up to priority 0! otherwise M$ will just grip the world even tighter by promoting that they're OS can withstand a gaping hole in the earth...
...yea
A demand for documentation from M$? Why? Aren't they smart enough over there to understand *nix without it? It may be that the overhead from their code "Borrowing" Dept. would be reduced, if the open source community provided pictures as well. It is ironic that the single most CLOSED community would harp on documentation. The only documentation from M$ involves, "click here, scroll there", or similar(deliberate exaggeration). Certainly, someone with a higher indulgence level could phrase this better. How does M$ document "undocumented features"? They don't. Obviously their internal documentation and/or auditing system is inadequate/apathetic.
Now maybe if Billy Boy gets hit by a stampeding buffalo........
No, it's not, but unfortunately for your argument, I, like Alan, am in the UK, where it's "perk" (and "cheque" and "colour").
"The invisible and the non-existent look very much alike." -- Delos B. McKown
If Linus were to be hit by a meteor, development resources would have to be shifted. Such high-priority tasks as porting MS-Bob to the PalmPilot would have to be tabled until the relatively unsexy items such as, oh say, clotting, could be completed.
After that, life would go on. Not to worry.
-- What you do today will cost you a day of your life.
having ht esource code makes up for some lacks in documentation. If you do not understand the documentation you can look at the function declaration, and hte function itself, and how it handles things. It does lack in documentation, yes, but it is often better, than trying to fiddle with a messed up API, that does not work as it is supposed to. Also something to note is that many of the M$ API's are not very well documentened either, and sometimes it is just hard to get there documentation too.
Only 'flamers' flame!
Perk is what gets the coffee ready. Perq is access to the coffee.
---------
Bill Gates Is My Evil Twin.
Exactly. I think it would benifit the community greatly were companies like Red Hat to pay people to document the more obscure parts of the kernel. This is especially important as the changes are so rapid and the systems are always evolving (for example: modules in 2.0 to modules in 2.2)
But then again:
I GOT 18 disks on a raid!
http://www.bombcar.com It's where it is at.
Fellowship 9/11
ac> Ultimately the only real way to improve
ac> security is careful auditing of packages.
There may be other, complimentary, ways of improving Linux security. For many years, people in the security research community have been working on systems whose security relies only upon the kernel, or a small part of the kernel sometimes called a reference monitor (RM). The general idea is, once you've implemented your RM properly, it will guarantee certain useful global security properties even in the presence of user-space applications with exploitable bugs. I personally believe that implementing an RM in the theoretically optimal way would probably make unreasonable and unacceptable demands on the Linux architecture. However, I suspect that a sub-optimal implementation in a Loadable Kernel Module (LKM) could provide some security benefits with zero impact to the Linux code-base. The LOMAC project is implementing an experimental prototype of such an LKM-based RM, which may be downloaded under the GPL from ftp://ftp.tislabs.com/pub/lomac . If the LOMAC experiment succeeds, LKM-based tools like it may become a useful complement to the careful auditing of packages.
- Tim Fraser, NAI Labs
Thanks for answering my questions!
Hope a few of the good 4-rated and 3-rated comments from this past round get thrown in the pot for the next edition of Ask Alan.
--The more you know, the less you know.
To a certain degree, Microsoft does provide developer contact. They just don't publish it in "mainstream" press.
The Microsoft Developer's Network is the first line of contact with the developers: "here's a huge stack of CDs of everything we think you might need to develop for our OS."
You can also get significant interaction with developers and evangelists at trade shows. When I was programming games I found that the time spent at Microsoft Meltdown was invaluable. You get to schedule time in a hotel suite with DirectX developers from Microsoft to review your code and get pointers on how the OS works. Plus, it's their front-line for input on new features to add.
I was even invited to spent a few days in Redmond at the offices to get direct interaction with DirectX developers.
However, Microsoft is a traditional company when it comes to trade secrets. You didn't get invited to Meltdown without signing NDAs. OpenSource eliminates the need for NDAs and lawyers in general.
Microsoft's position is also bound by the fact that they are in the business of creating de facto standards. Linux is based on open standards. The concept of open community interaction is there from the initial stages of development.
First off-I may loose all moderation priviledges (I am not one right now) from this point forward-but I would like to clarify that I have been a moderator several times...and not once, regarding ANY issue was I ever contacted nor asked to ignore AC comments.
/. came up with the threshold option...That is why I now use it to keep from having to look at that crap.
/. was just making it easier on him..and I think that they were good questions and it was a great interview-next time why not just log in?
I can see why you are upset that NO AC questions were used in the interview-but I can assure you that there is no conspiracy. I set my threshold to 1, and it is sometimes left there while I have been a moderator-I assume I am not alone,which would explain why a lot of them are overlooked in the first place.
With all the agony of First Post! and Meeppphhtt! etc.. that had to be accepted before
As far as any of this goes, why should Alan HAVE to weed through dozens of questions-maybe he just didn't want to. He was doing US a favor by doing the interview -
p.s. I was not a moderator at the time the questions were asked either.
Hi,
:) :)
I just read the interview and wondered what Alan ment with the PPC port starting on a BeBox? Was there not porting done to PPC before the BeBox? Does Alan have a BeBox? I am amazed at the far reaches of Be here
Can someone, even Alan, clarify?
Oliver
Right on opensource os's! FreeBSD, Linux and others!
-
ping -f 255.255.255.255 # if only
Except that there wasn't any reason to be anonymous for this. Unless there were well-phrased questions of the form "Why does Linux suck?" (and I don't know if that could be done), there wasn't anything political going on. Certainly in this discussion there could be unpopular views that someone doesn't want reveal an identity. But not asking a question.
Do you think Alan Cox would personally respond to a question from a random anonymous email address? If no, then this is a moot point. If yes, then you may have a point, but I still can't see what you would want to ask anonymously.
Comments ought to be scoredsoley and entirely on the basis of their content - not extraneous factors like whether you logged in or not.
We already know this isn't the case. Logged-in posters start with 1, ACs with 0. Those are the rules of this game, Don't like it, take your ball and go home. The prejudice is already there. You knew this going in.
People need anonymity for a few reasons.
Posting a message that will bring harm to them. I don't think there's ever this on /., except if insiders are posting infomation that will get themselves fired or cut off from the information.
Posting an unpopular view. If you don't want to deal with flames, you may post devil's advocate stuff. This is probably the majority of legitimate /. anonymity.
Posting a view contrary to their established positions. If someone (like a political candidate) has to be "tough on drugs", but they're a closet pot smoker, anonymity gives them some leeway between their public and private lives. (Doesn't solve the hypocrisy, but maybe that's not the battle to fight at that particular time.) I wouldn't be surprised if this happened sometimes (e.g. a Linux supporter thinks one particular thing is stupid, but doesn't want to "taint" his rep)
Someone who doesn't want to be tracked. In this case, they would also don't trust the /. maintainers to keep their real (off-Slashdot) identity secret.
Those are all legitimate reasons, but again, I can't see how they apply to asking pertinent questions to an interview subject.
The downside of anonymity, you get people who post drivel like "ALAN COX SUX" with, of course, no reasons why. (Not even a whining "he didn't answer my question"...) I'm willing to put up with that because there are times you need anonymous voices.
Like this discussion. I could totally see someone posting what you did as an AC, because it threatens the established (Taco, Hemos, et al.) authority.
Asking Alan a question wasn't one of those times though... Unless you can come up with a legitimate reason...
"...and the ability to manipulate ip packets by thought."
They can't do that now?
I keep trying to pick fights, but I can't shake this Excellent karma.
someone put a little too much crack on their cereal this morning.
The primary reason there is such a lack of documentation is because it is not nearly as much fun to write as code. Declaring that people should document their code will never work unless you made it less painful to do so.
Perhaps if you knew interested parties were going to look over your code you would comment it for the gloat factor. Usually the more ingenious the code the more proud you are of it and the harder it is to understand. If you had someone to show off to, you'd be more inclined to comment it.
--SolidGold
Everything you know is wrong. Or more accurately, inaccurate.
>Of course, you yanks have a way of bastardizing the spelling of words...
You mean "yanqs" of course...
It seems like the corporate closed-source model has several flaws, the most aggregious of which is.. no source code access!
A) I've seen the source for MFC (it's distributed with their compiler) and you don't want to look at it, believe me
B) IMHO the most egregious fault of the Free Software movement is an inability to spell. I'd still rather deal with that than MFC, of course.
There are thousands of open-source projects, some as small as a few lines of code. Who are WE? doesn't the we that is YOU work for M$?
The "we" that he's referring to is "we software developers". That's abundantly clear in his post. Yessiree Bob, them fiends -- fiends, I tell you! -- who code at MS are programmers too, much like the heavenly angels in the free software camp.
I'm going to assume that you're claming that closed-source corporate software DOES have this,
You can assume anything you like, but the point of his entire post was that MS does not have that. Here's his second sentence, which seems to have escaped your comprehension (even though you quoted it):
It seems that the corporate and open-source development models have at least one flaw in common: insufficient documentation.
Get it? I think your second "aggregious [sic]" flaw is an inability to understand simple declarative sentences in the English language.
please, don't give me any line of shit about corporate $oftware being better than OSS. It's bullshit.
He said nothing of the kind. He's developed some software and he's seen how the process works, and now he's offering some thoughts about how the process might be improved. In his opinion, his thoughts on the subject apply equally to both open and closed development. IMHO he's right, too, even though he's not suggesting anything terribly revolutionary. IIRC Knuth has been on a similar kick for years. If he did anything wrong, he may have been assuming his audence consisted of programmers. Of course there are a lot of them around Slashdot, but there are also a lot of dingbats like you.
Ok, I'm as sick and tired of everyone complaining about moderation, censorship, and those sorts of things as anyone else. But the system plain doesn't work unless people honestly and fairly moderate things. I guess I'll just e-mail Alan directly to ask him the question.
Of course, now it's up to 5 again - after the questions had been sent to Alan. gah.
Actually, in the off chance Alan's reading this article: Alan, how much of your software development is done because of a contract, and how much just for the fun of hacking?
I'll concede that two or even three people getting hit by busses is improbable; but meteors do a lot more damage, and can take out a hemisphere or more. I'd suggest to Alan that he and Linus never be in the same hemisphere at the same time, and that at least resources be devoted to a rocket that can take at least one of them to a planet far away in the event of Earth's destruction. Who knows; they may land on a planet whose sun gives them powers such as flight, x-ray vision and the ability to manipulate ip packets by thought.
While there are some definite troll elements in the original post, they do make a good point: Documentation is useful and important. And I mean, beyond the kernel source instructions themselves. There are a number of reasons for this. I thought they were well-known, perhaps not.
:-)
For one, stating the design and then implementing it has been shown to increase code quality. More importantly, it means you know what the code *should* be doing. This makes "Is this a bug?" questions much easier to solve. I've noticed a lot of patches on the linux-kernel list arise from misunderstandings due to unclear code.
Then there is the generally accepted fact that programmers of all skill levels sometimes forget things. How many here have gone back to their own code they wrote six months ago, and said to themselves, "What does this do?" I know some kernel hackers have -- that same phrase shows up in the Linux kernel source!
Linux is contributed to by tens, if not hundreds, of developers. Not *all* of them are going to be Seventh Level Hackers like Linus and Alan. For someone who is, say, just tring to implement an input device driver, it would be nice if some of the magic_kernel_functions() were explained a little clearer.
I'm not saying every function should be documented complete with purpose, arguments, return value, pre- and post-conditions. If someone wants to do that, more power to them, but I'm not saying It Must Be.
However, some things could be added, to positive effect: Top-of-file comments explaining what is contained in a file. Brief comments explaining which a function is supposed to do. A guide to where key kernel structures, macros, etc., come from.
A lot of this stuff was laid out very well in the Kernel Hacker's Guide and similar documents, but they have fallen far out of date. Documention for the 2.2 and 2.3 series kernels is very lacking.
I would try my hand at doing some of this, but frankly, I don't understand much of the kernel myself. I've been reading source lately trying to figure some stuff out, but with almost *SIXTY MEGABYTES* of kernel source, that is a lot of reading!
Just my 1/4 of a byte.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I'm a developer at M$, and I've watched the Linux community for a couple of years now too. It seems that the corporate and open-source development models have at least one flaw in common: insufficient documentation. All too often one finds a section of code that is not commented in-line worth a damn, and there is no thorough "architectural overview" of the project to even help clue you in. So to address the question, "What if so-and-so gets hit by a stampeding buffalo?", let's first address a larger issue: how can we get people up-to-speed on development projects more easily? The answer is to simply shift our philosophical viewpoint. We should place correctness, thoroughness, and efficiency of _documentation_ on the same priority level as correctness, thoroughness, and efficiency of _code_. Then you don't have to worry about a project dying just because a few key people left and took all the knowledge with them! This means commenting (in the code) the purpose and inner functioning of every function so that a newcomer can immediately see what the function does, why it gets called (and from where), and how it works inside. This means modifying your original design specs as you go along to reflect what is actually happening in the project as it takes shape, so that at the end of the project you have a complete architectural overview that one could read to easily see how the project fits together.
- "It's just a matter of opinion!" - PRIMUS
Short for "perquisite".
:-)
Of course, you yanks have a way of bastardizing the spelling of words, so it may well be "perk" in the US, but that's not where Alan is, is it?
(And the piece of paper you sign authorizing the back to give somebody your money is a cheque. A check is a pattern of alternate colo[u]r squares.)
-- Alastair
Reading this, a strange image comes to mind....
"Thank you for coming, gentlemen..."
"Cut the crap, Bill. Why did you want us here?"
The speaker glares. "No names", he replies. "As for why I called us togeather... I understand this is highly irregular. Normally we would be attempting to tear each other apart in the marketplace. And I know that means there's no love lost towards me. However, today we are seeing a bigger enemy. All our business is dependant on proprietary technology. Today, the threat to our business models is not each other... it's open source."
There is a wave of grumblings and grudging agreements. One speaker blurts out "OK... sure... but what do we do? Many of our numbers are attempting to embrace it to survive..."
The speaker frowns. "You'll notice THEY aren't here. No... there is another solution. Destroy open source. Destroy its poster child: Linux."
More grumbling. The speaker grins.
"Obviously you think I'm insane. Gentelmen, I'm not. We have a solution. Cut off the head, and the snake dies. You'll note that a year or two ago... if a bus had hit Linus Torvalds... it may have stopped this menace before it surfaced. Now it would take two, possibly three bus incidents. Gentlemen, we must act now! The plan is simple... at the next big Linux convention, we pool our collective resources togeather and charter lots and lots of busses...."
The plot thickens. And I swear to cut down on Penguin mints...