Has Linux Development Become Too Political? 218
1010011010 asks: "Has Linux development become too political, bottlenecked and ego-driven? Witness the recent exchange between Hans Reiser, of ReiserFS fame, and Alexander Viro (VFS maintainer) on Linux-Kernel; Hans, and others, were griping about Viro refusing patches and ideas on principle, and Viro keeps telling people to shut up and read the code. It's obvious that the kernel needs better documentation and fewer penis-size contests, but it also needs better 'roadmaps' and plans -- i.e., documentation in advance of changes. Does anyone have a current "org chart" for Linux kernel development? Is Linux Kernel Development sustaintable as a coalition of little feifdoms?" Such things are concerns, but sometimes it can be that very ego that drives a project. Behind technology, there are the politics of that technology. Being human, is there any way we can avoid this? Should we?
I agree... (Score:1)
Re:Linus Torvalds (Score:1)
The problem is that Hans Reiser carefully timed his tirade / paranoid ranting to coincide with Linus' annual 3-week trip back to Finland, and Linus doesn't read Linux-kernel when he travels.
The final test of the Bazaar model (Score:1)
This model has so far worked fine for smaller projects like gcc, emacs, vi, and gnutella. But now we are finally seeing a project that has grown a lot since its conception and the rules are changing. More and more people are getting involved in the development of the Linux kernel. These people have different backgrounds, varying levels of coding skills, some are better communicators than others etc.
Can this model remain successful under those circumstances? Or is the Linux kernel going to become another Tower of Babel, disintegrating into chaos?
My opinion is that the kernal development needs to become more centralized, with firm management. I think it is time for an IPO.
It's their code, they can do whatever they want! (Score:1)
Re:More women in charge of linux (Score:1)
Need better resources to keep kernel info (Score:1)
Re:Ego in the name (Score:1)
Perhaps you're too new to Linux to remember it but one of the old filesystems, xiafs, was also named after it's creator, Frank Xia.
Re:ReiserFS? (Score:1)
hubris
n : overbearing pride or presumption
Being a pedant isn't so great either.
Re:ReiserFS? (Score:1)
Agreed, but this is something for the reiserfs crew to implement. FWIW, I'm unaware of a free util for resizing ext2 at all, is there one?
I have to wonder what the holdup with ext3 is.
Well, S. Tweedie keeps saying he doesn't have time to do anything, so thats keeping ext3. I just don't understand it. Add it to the kernel, flag it experimental and be done with it. It's really as simple as that guys. How long could it hold up 2.4.0? A week if that.
Hmm.. sounds like S.T. should could use some help, being so swamped and all. There must be _somebody_ who has the skills/desire to help him out. Unless of course, he doesn't _want_ any help (Hubris, anyone?). A backward compatible journalled fs is to much of a good thing to let languish like that.
Simple, don't build it as a module...
I know, however my reply was to someone who was saying "I don't see what the problem is, just build it as a module!"
Really however, if I want my root partition to be ReiserFS I shouldn't be penalized for that decision.
Okay I missed the post you responded to but again, I agree with you. It's not inconceivable that at some point RedHat will have to include reiserfs or lose sales... Nah, what was I thinking, they have enough deals/PR to not include it ever.
think a lot of CS types need to take a reality check and tone down the egotism, they aren't so great.
I don't know who you're refering to when you talk about egotism.
vi or EMACS, Perl or Python, Gnome or KDE, man or info, ad nauseum.
The flame wars break out because people take things as personal attacks and egotism contributes to the lashing out in response.
I just recently had a Solaris admin tell me that he thinks of linux like linux users think of windows. Then he went on to curse Larry Wall because he had major headaches for 6 months trying to cross compile a perl module for a linux machine under Solaris.... Between that little gem and his acknowledgement that commercial unix man pages often contain mistakes (and any corrections never get incorporated by the vendors), I had a hard time not giggling.
Oh, the irony.
I spent a good amount of time as an audio engineer (no more, thanks), and as far as I can tell you the hackers ain't got nuthin' on the "rock stars" when it comes to egos.
I've heard it said that one of the things that makes Linus a good leader is his _humility_. I guess it's a matter of balance.
Re:The final test of the Bazaar model (Score:2)
Re:ReiserFS? (Score:2)
SuSE, since 6.3
Well I haven't heard of one of them, so I am going to say a tenative zero.
No comment
This is a problem. If I want to use ReiserFS for all my filesystems (root, usr, etc) I have to install a distribution using ext2, download ReiserFS and patch it into my kernel, make new partitions formatted with ReiserFS, copy everything over, and blow away the ext2 ones.
Admittedly a pain when you have no existing Linux install, but if you already have an installed system you can prepare a kernel before hand with reiserfs not as a module and put it on the installer floppy
1. This effectively reduces the amount of disk space that can be used because you can't resize the partitions (not exactly sure about this, correction?)
Here is your correction.
2. It's a huge hassel to get a journaling filesystem which linux should have in the kernel by now!
I think thats why the original question was asked. reiserfs works, I've been using it for a while. It's debateable whether or not you would want to use it in certain situations, but it _is_ here and it _does_ work. I have to wonder what the holdup with ext3 is.
3. Stock boot CD/Floppies will no longer be able to access the root/usr filesystems because.... ReiserFS isn't in their kernels!
Err.. I think I answered this already.
4. I'd really like to see how you can load a module from a filesystem you can't read. (ReiserFS built as a module loading from a ReiserFS root filesystem, enjoy that chicken and egg)
Simple, don't build it as a module. Or, gasp, keep your / as ext2! (wise-ass mode on) On a properly configured system the root file system is going to be around 500M. It doesn't take an inordinate amount of time to fsck. (w-a off). This reminds me of installing on a system with ATA66.. you need to install on vanilla IDE bus first then patch, edit a pile of config files, move disks around, hope you got all the edits right...
As you can see, this makes using ReiserFS cumbersome at best. Jumping through massive hoops just to get functionality other *nix's have had for years (Journaling Filesystems) is pathetic really.
Jumping through hoops isn't restricted to this one issue, personally, I think a lot of CS types need to take a reality check and tone down the egotism, they aren't so great.
You have to realize, that when you write parts of the kernel or kernel modules, you are part of a community. You need to be able to work with everyone because the end goal is the same: Making Linux a better system.
Sounds good, but talented people are stubborn and inflexible, it gets worse once there is some recognition. Then it's a slippery slope to keep from winding up like Bob Metcalfe. Hubris is never a good thing, I don't care what ESR says.
Could you please tell Viro that? He doesn't seem to want to work with anyone, especially to fix a gaping feature hole. Pretty sad really, when "maintainers" are working to the detriment of Linux.
Well, hopefully we won't be reminiscing in n years how linux peaked at 2.2..
Re:I agree... (Score:2)
>default.
>Could you take a few seconds of your precious time and explain us why
>?
>I guess not. You're probably trolling...
Can you explain why support for ReiserFS should be placed into the kernel when people working on the kernel don't want it there?
Odd moderation (Score:2)
Just goes to show that people don't agree on stuff. Even Slashdot Moderators.
Re:Well..maybe (Score:2)
It was a radical new way of managing people, and it worked against a system that was totally about control and presenance of upper managing figures.
Re:I don't mind third-party patches (Score:2)
/* Steinar */
Re:Maybe... (Score:2)
(Of course, if there's a prebuilt package for _your_, you can always use that...)
/* Steinar */
Re:The final test of the Bazaar model (Score:2)
OS kernels are certainly complex, in terms of concurrency and so on, but they are not particularly large.
Re: Has Linux Development Become Too Political? (Score:2)
Concerning 2: The concensus of the list at present is not that "generic journalin" (sic) is a good idea, but rather that the VM system needed some way to apply pressure to journaling filesystems which have to pin pages in memory, and that a generic journaling layer would be one solution to do that. There are plenty of other approaches being discussed as well.
You are also making crossed-purpose demands; in 7 you state that the VFS is becoming more and more and more critical - absolutely! So you want us to (in 1+4) perform a major modification to the structure and allocation strategy of inodes, and to (in 3) open up the VFS architecture to whatever flaky whiz-bang "extensible" modification to its semantics anyone wants? Give me a break. When dealing with core APIs, "extensible" and "unstable" may not be identical, but they are certainly fraternal. Remember the KISS principle?
Granted, I too would like better VFS documentation, and would like it now, too. Richard Gooch has historically done a good job documenting it longer-term, while day-to-day patches from Al do tend to include at least notes about what the interface is expecting and expecting to break. Welcome to bleeding-edge development.
So what's your agenda? This kind of venom is rarely loosed without an ulterior motive, especially by someone who was presumably posting an innocent and curious "Ask Slashdot" question.
Re:Maybe... (Score:2)
I'm sorry, but did you just basically say that Linux wishes it was as widely accepted as BSD?
I think your information is about three years out of date.
--
Re:Maybe... (Score:2)
--
AT v. LT (Score:2)
Remember, Linux was started because of political differences between Linus and Andy Tanenbaum. And I am by no means suggesting that *that* was the first flamewar. This stuff happens all the time. The biggest difference with Open Source is that we all see it.
I'll admit that there is a story here, but the story is not the fact that politics have *suddenly* broken out in the Linux kernel.
Re:AT v. LT (Score:2)
I'm afraid I don't see your logic. On the one hand, you admit that things would have turned out differently were it not for this fundamental conflict of visions, while on the other hand you deny that this was pivotal. Seems to be the very definition of a pivotal moment.
Now, I'll certainly admit that there was *more* to it than a simple flamewar or difference of opinion. But you have to admit that Linux was born out of the fire. While I never meant to imply that this *single* moment spurred the creation of Linux, it was certainly *a* significant event.
My only real point, of course, was to simply argue that flames are not a new thing in the Open Source world (nor any other, for that matter).
ReiserFS? (Score:2)
Realistically, this argument is silly. It doesn't matter if code "gets in the kernel". As long as it is available and can be patched into the kernel, then that's just fine!
You have to realize, that when you write parts of the kernel or kernel modules, you are part of a community. You need to be able to work with everyone because the end goal is the same: Making Linux a better system. When I started writing the Matrox Marvel video capture drivers [sourceforge.net] for Linux, I just wanted something that I could use to grab screenshots from a web-cam. It's been a while since I released the code, and the development has really taken off, with other more capable and more talented people. Although I haven't done too much development on this project lately, I know that sometimes there are disagreements, and the best way to resolve them is to think about what is best for Linux as a whole. Although "getting your code into the kernel" may seem [neat/eleet/prestigious/etc] it may not be best for the overall system.
That's whats great about loadable modules. If your code is not ready for the kernel, you can still release it and people can compile it as a module. People can STILL use your code, while the community makes the decision about kernel inclusion.
Evil open source empires (Score:2)
Re:It's our right to make noise (Score:2)
Personally, I very often see this true. But it is especially true of developers (particularly hackers) who perceive documentation to be a waste of their time.
A few hackers, such as ESR, don't mind writing documentation. As a result you see certain projects have excellent documentation with other projects having almost non-existant documentation. For ESR, my example would be fetchmail [ccil.org]. This program is not only very well written, its extremely well documented, although I have to believe that the documentation was NOT written in a bazaar mode like the program itself is.
That faq-o-matic is very interesting, though. I hadn't heard of it prior to your posting this.
Re:It's our right to make noise (Score:2)
I agree with this statement, especially the first part. Anyone not sure that making noise keeps open source healthy, particularly in the bazaar mode of development that is present in Linux, should read the writings of ESR [ccil.org], particularly Homesteading the Noosphere [tuxedo.org] and possibly the Cathedral and The Bazaar [tuxedo.org]. (Not necessarily in that order though
I think this should change. I think that the design documentation we need should be readily available - it has to be posted somewhere where everybody can get at it, and contribute to it.
Yeah, current documentation would be great. But I don't think that documentation lends itself well the bazaar mode of development. The "roadmaps" you speak of reek very much of "requirements documents" and I don't think you will find any of those in Linux development.
Maybe... (Score:2)
Many important people are afraid of Linux's development system, or lack of it. OTOH, *BSD is pretty widely accepted anywhere but Linux isn't as much as some would like it to.
The recent flames between Vero and Reiser just show that, maybe, the Linux way of doing things isn't good enough anymore. Now that it has reached a certain level, some organisation à la *BSD wouldn't be a bad thing.
Just my
Re:Much Ado About Nothing (Score:2)
Re:1010011010's crusade against Linux (Score:2)
6. See points 1-5,7
You appear to have the wrong type of attitude towards Linux development. Posting your technical questions on Slashdot instead of linux-kernel & | linux-fsdev is one example of this.
Re:1010011010's crusade against Linux (Score:2)
Your point about VFS development being 'too fast' in the past couple of months for the casual, eventually non-Linux FS maintainer to follow, I have to agree with you. I do think this is and was a necessery evil. All of fs/*.c and fs/*/*.c got way too messy over the years and nobody really maintained it consistently. This is what Alexander started doing around early 2.3. I do have code that has internal VFS dependencies, and I had my share of interface breakage as well - we've got to live with this. The VFS is one of the most complex pieces of Linux. Documentation is advancing IMO - check out 2.4.0-test2, it has more and more VFS functions documented properly, check out fs/dcache.c for example.
The 'right attitude' IMO is to point out flaws on the apropriate mailing lists, and ask for suggestions how to get around that particular flaw. If your question does not get answered then you have a reason to complain. I'm 100% sure nobody asked any questions about a generic transaction engine on linux-fsdevel ever for example (I just checked the archive to be sure) - 1010011010's implicit and (IMO) bad-faith conclusion was that 'it must be ext3fs-centric'. I think that is the kind of attitude that is very contraproductive.
Does this answer your points sufficiently?
Re:Much Ado About Nothing (Score:2)
Re:Much Ado About Nothing (Score:2)
To repeat it, Hans Reiser has not contributed to the Linux kernel on any public mailing list so far in any meaningful way. Looks like he doesnt really care about Linux, but he expects Linux to do everything for him. Not a very sympathetic position to me.
Re:Much Ado About Nothing (Score:2)
"... you have my
vote for temporary inclusion of the *@!#^* ->read_inode2(). AFAICS it's
the least of anyone's problems.".
[and check out the subject of this slashdot thread...] THERE IS NO PROBLEM.
Also check out another email on linux-fsdev, , where it becomes clear that Hans Reiser has fundamental misunderstandings wrt. how the Linux VFS works, and Alexander Viro explains him how things work. How does this fit your paranoid conspiracy theories??
Re:Much Ado About Nothing (Score:2)
Linus always agreed to journaling filesystems in principle. Given conceptual agreement it always depends on the quality of said patch wether it gets accepted. Thats all.
Re:Much Ado About Nothing (Score:2)
ramfs/cramfs is not possible in 2.2. The 2.3 pagecache redesign enabled ramfs/cramfs.
Linus objected to specific devfs patches for more than 2 years. It took alot of time for Richard Gooch to fix all the issues that devfs had. While Linus supported the *idea* of devfs, it took from early 1998 to this year, with more than 100 releases, that devfs be accepted into the mainstream 2.4 kernel.
Re:Much Ado About Nothing (Score:2)
Obviously on linux-kernel you'll find a thread about just about any kernel subsystem, with various people representing all mathematically possible positions.
The fact that there were heated discussions about DevFS, and still it made into the kernel appears to support my point that decisions are made on a technical basis and not based on advocacy.
Re:Much Ado About Nothing (Score:2)
The point is, if ReiserFS people were actively participating in Linux VFS development (and Linux development), then they could have cleaned this up properly during 2.3. ESPECIALLY if all you have is an ugly kludge, and not a good/generic solution! So Hans Reiser was demanding an extension that only ReiserFS needs - why doesnt he / didnt he code it himself?
About the conspiracy bit - you raised this whole non-issue, so I thought you believed in it. If we agree then why have you raised this non-issue, asking wether Linux development got 'too political'?
Re:Linux : incapable of leveraging commercial asse (Score:2)
Re:Linux : incapable of leveraging commercial asse (Score:2)
I believe that he meant not leveraging one over the other, but leveraging the benefits of a JFS on Linux over other, less-capable OSes. What does one do in a predominantly Linux environment? The ideal, after all, is world domination:-)
Re:It's our right to make noise (Score:2)
>well the bazaar mode of development
Not sure ! you just need to have the right tool.
There is actually an excellent tool for writing documentation in a "Bazar way", it's called FAQ-O-MATIC; the Java Apache project has implemented an excellent instance at :
http://locus.apache.org/jyve-faq/Turbine.
In fact we often hear that developers are reluctant to write documentation; this is true for everybody else. People are often shy from writing a big document from scrach, as they often don't know where to begin ! what to put in it ! this is what writers call "The white page anguish". But as soon as you come with something to begin with, or a draft, people are often willing to contribute small chuncks of information, to correct or complete things. This why the Net, and especially forums are so great to achieve complete information about a particular subject. This is in fact what Open Source is all about.
Everybody agree that what Open Source so badly needs is "Documentation", I really believe that tools like FAQ-O-MATIC can be great to achieve this in a Bazar way.
Wiki tools are great too.
Re:Maybe... (Score:2)
I think formalizing the process by creating a core group would introduce much more politics and ugly flames rather than reduce them.
I'm not involved in Linux Kernel development (nor would I have the skills), but I lurk around the main lists and have found that the current way is fascinatingly efficient.
By all practical means, there _is_ a core group formed by those who can impose their opinions trough the work they have contributed or the knowledge they have in their specific field. Then, there's Linux, who acts as "benevolent dictator". This is the best form of organization imho, because it is based on good old-fashioned trust (however, it is also the most vulnerable to commercial outside interests).
Frankly, I think Linux development has already proven itself to be more efficient than BSDs trough the years by the lack of spectacular splits (just compare...).
Many important people are afraid of Linux's development system, or lack of it. OTOH, *BSD is pretty widely accepted anywhere but Linux isn't as much as some would like it to.
I'm not sure I agree with you here. Despite being younger, Linux has seen a much steeper adoption curve than BSD. This is imho again, and I don't have any numbers to back it up, so please correct me. However, it as been argued that it was precisely because of the more rigid organization at BSD that alot of people have turned to Linux, where they seem to be able to get their patches integrated more rapidly.
Finally, just to clear things up: I don't mean to slam BSD in any way. I've recently installed FreeBSD on a test machine and have been playing around with it extensively (love it)... Why Linux didn't reuse the BSD tcp/ip stack I still haven't understood. But having recently read up on the ugly flame wars which lead to the creation of OpenBSD, I don't want to see this happen for Linux.
Re:It's our right to make noise (Score:2)
I also think it's possible that anyone with a good enough grasp of the latest kernel and how it works is more than likely writing code rather than writing docs.
I would really like to see a documentation project similar to TLK that is kept as up-to-date as possible. Unfortunately the rate of change of the kernel, the immense amount of traffic of the lists and the years of experience required to understand and interpret the latest changes, rules out most people. Those it doesn't seem to be writing code :)
I would happy to be corrected by someone like Joe Pranevich [linuxtoday.com] for example...
Re:I don't mind third-party patches (Score:2)
Patching the kernel to support ReiserFS is something else completely - I have no idea how to do this at all. Does this make me computer-illiterate? I use Linux for my job, you may (for all I know) be a kernel maintainer but for me it is a desktop and server OS.
Linux has been trying to move into the mainstream for a while now, a reliable Journaling FS that can be activated simply is something I *need* - hardware errors and even some kernel problems (try rebooting with a smbmounted directory loaded) mean that I sometimes need to hit that button. Why are you trying to reserve Linux as a niche-OS for the ultra pure-at-heart?
Re:ReiserFS? (Score:2)
While this is true for most drivers, when it comes to filesystems it really does matter.
Case in point: Which distributions allow me to use ReiserFS filesystems on installation? Well I haven't heard of one of them, so I am going to say a tenative zero. This is a problem. If I want to use ReiserFS for all my filesystems (root, usr, etc) I have to install a distribution using ext2, download ReiserFS and patch it into my kernel, make new partitions formatted with ReiserFS, copy everything over, and blow away the ext2 ones.
1. This effectively reduces the amount of disk space that can be used because you can't resize the partitions (not exactly sure about this, correction?)
2. It's a huge hassel to get a journaling filesystem which linux should have in the kernel by now!
3. Stock boot CD/Floppies will no longer be able to access the root/usr filesystems because.... ReiserFS isn't in their kernels!
4. I'd really like to see how you can load a module from a filesystem you can't read. (ReiserFS built as a module loading from a ReiserFS root filesystem, enjoy that chicken and egg)
As you can see, this makes using ReiserFS cumbersome at best. Jumping through massive hoops just to get functionality other *nix's have had for years (Journaling Filesystems) is pathetic really.
You have to realize, that when you write parts of the kernel or kernel modules, you are part of a community. You need to be able to work with everyone because the end goal is the same: Making Linux a better system.
Could you please tell Viro that? He doesn't seem to want to work with anyone, especially to fix a gaping feature hole. Pretty sad really, when "maintainers" are working to the detriment of Linux.
-- iCEBaLM
-- iCEBaLM
Re:I don't know what's right... (Score:2)
Outsiders? Is that how the users of the kernel these folks are writing are known as? Outsiders?
outsider n : someone who is not a member of a group [syn: foreigner]
Hrmm... Well, I don't know about you, you may wish to be an outsider, and thats your right, however I'm going to be using this kernel, I have time and money invested into linux, and I see a gaping hole which needs to be filled, which there is also a viable solution for which seems to be getting blocked.
Most every other *nix on the planet has journaling filesystem options for it, but not Linux, atleast not in the kernel. "Oh but you can patch it" and thats great, but it's also a huge headache. ReiserFS is a viable solution. Where is my proof? Well "the proof is in the pudding", namely large sites such as mp3.com and sourceforge.net use ReiserFS to reliably store massive amounts of data. If VA Linux systems can trust ReiserFS to store large amounts of open source projects such as Mesa, DRI, slash, OpenUT, Ghostscript, etc, then I think it needs to go into the kernel as atleast experimental.
Linux simply *needs* a journaling filesystem, period, and it needs it today. When will 2.4.0 get released? 2 months? 3 months? Then 2.5 will start up and possibly RFS will get into there, but when will 2.6.0 get finalized? A year? Maybe two? I reiterate, Linux needs a journaling filesystem *today*.
I don't care what you kernel hackers have to do to get it in there, but as a user of the code you people are writing, you need to fix this feature hole, and you need to put aside your "well hans will make money so we're not going to include it" bent, and you need to work with the Reiser team to get it in, as ext3 is nowhere near complete, neither is JFS/XFS for Linux, and ReiserFS works.
-- iCEBaLM
Re:ReiserFS? (Score:2)
Well, there's ext2resize [freshmeat.net] and GNU Parted [freshmeat.net] but I've never used either.
Hmm.. sounds like S.T. should could use some help, being so swamped and all. There must be _somebody_ who has the skills/desire to help him out. Unless of course, he doesn't _want_ any help (Hubris, anyone?). A backward compatible journalled fs is to much of a good thing to let languish like that.
I'm not sure on this one, there has to be someone else, sure, but I don't know if people have asked to help, submitted patches or not, etc. We need a journaling filesystem, it's too long in the making...
vi or EMACS, Perl or Python, Gnome or KDE, man or info, ad nauseum.
Pico, C, enlightenment, text.
The flame wars break out because people take things as personal attacks and egotism contributes to the lashing out in response.
I agree with you, but I'm not so sure the case is so cut and dried here. I think someone doesn't want to include RFS, not based on its technical merits, but for some other reason. I mean there simply is no reason NOT to include it. I've read through the lkml archives and I haven't seen one, not one good reason not to include ReiserFS in the kernel and flag it experimental.
I spent a good amount of time as an audio engineer (no more, thanks), and as far as I can tell you the hackers ain't got nuthin' on the "rock stars" when it comes to egos.
I think we all know this from the rantings that unnamed [metallica.com] rock band. Thank god too, if we had people as bad as THEM in our community I think we'd have a full blown civil war.
-- iCEBaLM
Re:ReiserFS? (Score:2)
Absolutely pathetic, this basically lowers all filesystems to the common denomonator that is ext2, and then tries to raise less feature rich filesystems to ext2 (DOS FAT for one.. Unix permissions? I don't think so!).
This obviously needs to be virtualized with a FS API where the filesystem can tell the VFS what it supports, what it doesn't, etc, instead of making the filesystem act like ext2, this should all be done "on the fly".
As I understand, many large sites already use ReiserFS (sourceforge for one). If VA Linux can depend on RFS for a huge site hosting massive numbers of open source projects such as Mesa, Open UT, Ghostscript, Slash, DRI, Sawfish, Python, Linux UDF, etc, I think it should be an option in the kernel for Joe User so he can store his porn reliably and not have to fsck every 10 mounts...
This is just absolutely pathetic.
-- iCEBaLM
Re:If you want to read up on the situation yoursel (Score:2)
And why should they be converged? All three of those no doubt journal QUITE differently, and making them all journal in the same way by making them use a journaling API would be really stupid.
Which filesystem do you model the API for, ext3? So XFS, JFS and RFS will have to end up adapting to journal like ext3, so whats the point of picking the other two? You end up having 3 filesystems which work the same way negating the reason to use one over the other, useless.
-- iCEBaLM
Re:ReiserFS? (Score:2)
Here is your correction.
/usr/src/linux/fs/reiserfs/utils/resize_reiserf
It's not perfect. AFAIK it shrinks only.
Well then it still reduces the amount of space you can use as to recapture that lost space from the partition merry-go-round you'd need to enlarge the ReiserFS partitions.
I think thats why the original question was asked. reiserfs works, I've been using it for a while. It's debateable whether or not you would want to use it in certain situations, but it _is_ here and it _does_ work. I have to wonder what the holdup with ext3 is.
Well, S. Tweedie keeps saying he doesn't have time to do anything, so thats keeping ext3. I just don't understand it. Add it to the kernel, flag it experimental and be done with it. It's really as simple as that guys. How long could it hold up 2.4.0? A week if that.
Simple, don't build it as a module. Or, gasp, keep your / as ext2! (wise-ass mode on) On a properly configured system the root file system is going to be around 500M. It doesn't take an inordinate amount of time to fsck. (w-a off).
I know, however my reply was to someone who was saying "I don't see what the problem is, just build it as a module!"
Really however, if I want my root partition to be ReiserFS I shouldn't be penalized for that decision.
Jumping through hoops isn't restricted to this one issue, personally, I think a lot of CS types need to take a reality check and tone down the egotism, they aren't so great.
While I understand it isn't restricted to this one issue, as I have to deal with some patches to get hardware to work, I don't know who you're refering to when you talk about egotism.
Well, hopefully we won't be reminiscing in n years how linux peaked at 2.2..
It would be sad...
-- iCEBaLM
To decide whether its too political . . . (Score:2)
Now, to do that we must first decide who is eligible to vote, and then how many votes each such person gets. Then we must establish the rules of order for the voters and non-voting stakeholders to comment.
Perhaps we should issue an RFC first? Let's appoint a committee to come up with a first draft.
Re: Has Linux Development Become Too Political? (Score:2)
Re:Much Ado About Nothing (Score:2)
It's because the VFS function isn't capable, and isn't being fixed, that he had to add a second function to do the same thing,
Granted, Reiser has some problems with presentation... but it's not like ideas and even actual, working code have not been supplied.
Re:Much Ado About Nothing (Score:2)
Granted Hans can be a little incendiary. Often the manner of presentation can overwhelm what is said, as with Hans calling Viro an asshole and Viro calling everyone whiners/wankers/etc.
What paranoid conspiracy theories? HANS has said that there's a "RedHat Conspiracy." I've said no such thing, because I don't think there is. WTF?
Re:ReiserFS? (Score:2)
Re:Much Ado About Nothing (Score:2)
shmfs [linux.org]: don't know history of this one, but it is a simple filesystem; prob. doesn't hit the VFS limitations.
ramfs/cramfs [kernelnotes.org]: simple filesystems, look like Ext2. Actually support fewer features than does Ext2.
Reiser: Linus said that ResierFS would not be included in 2.4. It also has to do a lot of work around shortcomings of the VFS, for which Viro has been unhelpful. Fat chance it'll be included when working against that. It's irrelevant that Reiser makes his living off of his FS, although stupid of him to make that argument.
The whole "ReiserFS thing" is not a red herring. Regardless of how "together" Hans gets his act, fact remains that his ideas and patches are being ignored. And he's bringing up real problems. HFS has to resort to some of the same silly kludges as he does. This problem has been popularized by Reiser, but isn't just Reiser's problem.
SurfsUp said 2.5 was going to focus on fixing the VFS. I hope so. A generic, stackable filesystem interface would be a good thing.
Re: Has Linux Development Become Too Political? (Score:2)
Re:If you want to read up on the situation yoursel (Score:2)
Problem is, ReiserFS cannot "adapt." There's fundamental limitations in the VFS, like in read_inode() for example, that prevent filesystems more complicated the Ext2 (i.e., any filesystem designed more recently than 1975) from working well, or at all, without patching the VFS.
I imagine XFS, JFS, and other more advanced filesystems are having to work around the same problems, because they cannot be made to look like Ext2. HFS -- a filesystem in the kernel already -- has to do a lot of workarounds. I can't imagine doing a full NTFS is possible with the current VFS, because the VFS makes it difficult to impossible to pass a context around with inode requests (for security, for example).
These aren't changes asked for "on a whim." They're changes that will benefit current filesystems and make it easier to add new filesystems. The VFS, if it were truely virtual, would not need to be patched to support new filesystems. As it is, there's a big union of filesystem-specific data in the VFS. It's silly to have specific filesystem info hardcoded in the VFS. Not very virtual, is it?
The VFS needs to provide a clean, extensible (stackable), implementation-neutral interface for filesystems.
Re:When you're the maintainer, it's your call. (Score:2)
The kernel is like a common carrier. It shouldn't mandate only certain types of development, but seek to be as extensible and flexible as it can.
Incidentally, the suggested changes to the VFS won't prevent existing filesystems from working. it'll just make it easier to develop new ones, and make non-Ext2 filesystems more efficient (because less kludging will have to be done).
If Linux development becomes limited and closed off, people will go somewhere else. I can't wait for the Hurd ot come out and provide a little competition in the GNU space... competition good... regis bad... heh
Re: Has Linux Development Become Too Political? (Score:2)
Umm... bullshit. That's not how it works. In reality, you do whatever you want, while criticizing everyone else for not being able to work inside your VFS. Address the real issues, Viro! Stop complaining and trying to change the topic!
Answer our questions and provide design documents/criteria/roadmaps/etc or keep wanking - nobody can deprive you of that right.
Re:An unavoidable side-effect of development model (Score:2)
Re:An unavoidable side-effect of development model (Score:2)
Re:It's our right to make noise (Score:2)
Re:An unavoidable side-effect of development model (Score:2)
I think you mean OpenBSD and NetBSD. FreeBSD developed out of 386BSD, and NetBSD developed out of Net/2. Fundamentally different projects.
OpenBSD and NetBSD split because Theo de Raadt wanted to change some of the way NetBSD did some of the things. He also made some rather unfortunate remarks because he is hot headed. Everyone threw around insults. People became afraid of Theo, and they revoked his CVS commit access to the NetBSD CVS servers. Theo got a complete copy of the NetBSD tree and spent a year and some with a few other developers auditing everything, and posting regular reports to Bugtraq. NetBSD did not merge any of the code changes because of political reasons. FreeBSD merged some of the pathes.
It's very easy for tempers to run out of control, especially people who haven't learned proper people skills (which, unfortunately, is a larger than average percentage of heavy computer users). These kernel developers need to talk out their problems instead of threaten or otherwise bandy about their particular "we're being discriminated against!" flags or accusations. Sometimes they do sit down and talk agreeably, and sometimes they don't. This is a complex situation, made more difficult by Hans wanting to get into Frozen code. Linus has not made it easier by making the freeze somewhat slushy at will for important changes, because Hans sees this as a further excuse to crow about his own code not being integrated.
I think this will we resolved when 2.5.x starts out. By then, Hans and Stephen (of ext[23] fame) will hopefully have discussed how to add generic journalling functionality to the VFS (where the Linux Kernel can better access it to ensure cleanlyness of journally metadata between the buffer cache, journally area, and other places), instead of keeping it separate (and thus bloating the kernel by lack of code resuse). We shall see.
---
A crisis of succession, then? (Score:2)
One of the great advantages democracy has over most tyrannies is that elections replace the problem of succession inherent in most single-leader systems. It was partly to uphold this principle that George Washington refused to stand for election a third time, even though he could have won without any trouble.
Linus is young so this isn't likely to ever be a serious problem, but sometimes the most important thing a leader can do is to name his eventual successor.
-cwk.
A well organized Anarchy is a powerful force. (Score:2)
Linux, like the early internet, is a well organized anarchy. Stuff gets done when people get around to getting it done.
If Viro -- or anybody else, for that matter -- really gets out of hand, somebody else is always free to light their own torch and lead a ragtag team of developers out of (or into) the wilderness. It's never a wasted effort because, even if you 'fail', the better aspects of your work can be folded into the 'winning' fork.
If documentation is REALLY needed, hunt down someone who would be willing to work on it. If they do a good enough job, they'll probably be commissioned to write a book about it.
Live life on the edge and risk getting blown away, or huddle in with the masses where you'll be relatively safe, but you'll never feel the wind in your face. Either choice is fine. Both choices are yours.
Linus, Rizer, Viro, etc. simply chose the former path. So did Kennedy, Hitler, Ghandi and Gates.
--
Open Design vs hidden agendas. (Score:2)
In this response [slashdot.org], Al Viro's point 2 reads:
2. Keep your attributions straight, I don't think that journalling is a good idea at all. Personally, I prefer soft-updates.
If I understand the context, Al Viro does not support journalling. Could all those journalling fs authors and design teams have gotten it so wrong? Or, is one man's agenda making a complex situation unecessarily more difficult.
If I've misunderstood the context of your post, Al Viro, I apologize in advance. If, however, you really don't think that journalling is a good idea, then could you explain why and save the ext3fs, XFS, JFS, ReiserFS, et al developers some time while they continue to go down a blind alley.
Re:Well..maybe (Score:2)
In North America we don't always expect people to have all the answers, we tolerate it when people don't know the answer to something (usually) and often try to find the answer. If a team leader doesn't know an answer, it is common for the employee with the question to continue the search for the answer, but not common for the employee to frown upon his/her boss' lack of knowledge.
That is just one example, but culture differences can play a major role in the relationships of people, and how people interpret the words of others.
Culture differences are important to bear in mind when dealing with all people. People from some cultures communicate in a form that is, inherently, more negative than others, and quite a bit different from what some cultures can be used to. Hence, the issue of cultural conflicts.
So the "excited
Also, consider that even if a person learns fluent English, that doesn't mean he/she learns the culturally-specific generalities of communication typical in English-speaking countries.
Always keep cultural differences in mind when talking to people from other cultures, it may help you avoid unnecessary conflicts.
This whole inspired debate may be nothing more than the country of origin of these two gentleman. It may, in fact, have nothing to do with politics.
Re:Debian, politics, and speaking out of our asses (Score:2)
yes (Score:2)
Don't know about that.
Should we?
While I don't know if we can, or should, get rid of it completely, it's probably a good idea to minimalize it to a certain extent. A lot of it seems to come from insecurity; I've noticed a lot of people, especially techies, are extraordinarily thin-skinned when it comes to disagreements or questions. They interpret mild differences of opinion as attacks on their knowledge, and respond accordingly. Look how many threads on slashdot devolve into constant bickering over some technical minutiae that in the grand scheme of things don't really amount to much.
Read the lastest news (Score:2)
Thar's money to be made with that there Linux stuff.
And because of that, companies, individuals and venture capitalists are all struggling to figure out how they can enter, lead and make the most money off this market. It reminds me of the PC wars of the early 80's. Everyone just about used the 8088 hardware/BASIC combination, now it was a matter of whistles, bells and marketing to push your TRS 80 over the Timex Sinclair over the Commodore.
Argue, steal, criticize and so on and so on.
Things will either get better or worse. But they will definitely get interesting.
Cause and effect (Score:2)
It seems to me that the flames served their purpose - everything in reply was civilised and co-operative, and an awfull lot of discussion, and quite a bit of work seems to be getting done.
I am particularly impressed with the way that everybody is handling the meatier questions of design - with a mixture of intuition, KISS, reusing what is available (where helpful only), looking at each others code, and setting it up for general future use.
I am left wondering if that is what happens all the time after a flame, or if /. (and presumably others) have had a calmic (karmic?) effect by putting up the hysterical headline they did, and forcing the debate into the 'public' eye.
If so, you could say that the /. flame has had it's desired effect too.
Whatever the reasons, this is good, clear evidence (to any heretics out there) of the workings of open-source, and the self-correcting system of open debates that surround it.
Re: Has Linux Development Become Too Political? (Score:2)
2. I'll say... generic IO stuff _does_ belong to VFS, unless you are going to redefine meaning of the word.
3. Care to show something better? If you know how to do it - I'm sure that Erez will be rather interested in your help.
6. You know how it happens? Interface-changing patch gets submitted to Linus and there is no way in hell to tell how many iterations it will take and when it will go into the tree. And iterations may be rather fast. It's not a CVS, Linus does not use it. He has every right to prefer other methods - no point complaining, but the reality is that process _is_ different. Summary of which version of patch do you want? All of them, slightly changing and separated by 5-10 minutes? Wow. I know that I would not be happy about that, but tastes differ. If you think that I don't get the same problems - well, I have a nice bridge for you. For non-trivial changes summary usually goes _after_ the final variant gets into the tree. Tough.
Oh, well... I'm going down right now, if you want to talk about the read_inode() and union-killing stuff - let's take it to fsdevel where it belongs. BTW, same goes for another variant - the problem I see with it is that we would have to put the icache into a large bunch of caches (size of element is a constant) and that's going to make icache eviction interesting.
Re: Has Linux Development Become Too Political? (Score:2)
2. Keep your attributions straight, I don't think that journalling is a good idea at all. Personally, I prefer soft-updates.
3. Check the work of Erez Zadok. He has a stacking toolkit and working filesystems based on it. With the current VFS. There are problems with his code, but they are mostly semantical (i.e. nobody knows what is actually the right thing in several corner cases). Again, his code works with current VFS.
4. And what would I do with it? Split in per-fs parts and send to fs maintainers? Sure, I can do that, but this stuff has nothing with VFS at this stage, each fs may do such switch quite fine and decision definitely belongs to maintainers.
5. I'm _not_ Linus. Ask him. BTW, I don't get 100% patch inclusion (nobody does).
6. read fsdevel. Design stuff is posted and discussed there.
7. Huh???
BTW, _all_ the stuff you are asking about is available in archives of l-k and fsdevel. I understand that you simply don't have free time to read it, but I'm sure that you can understand that other may have no time for retyping it for you. And get a clue, already - search would take less than it took you to type your posting.
Re:Open Design vs hidden agendas. (Score:2)
It's not like we had to have One True Fs(tm) - there is no such thing, simply because there are different tasks, different loads and solution that is good for one may suck for another.
So no, I don't think that journalling folks are wasting their time. I also don't think that s-u folks are doing that. The only agenda I have here is curiosity - I want to know how far can these variants be pushed. And it means that cheating is not an option - not to mention anything else, it simply defeats the purpose of the exercise
In other words, personal opinion is exactly that - personal opinion. Personally I find s-u more attractive, but I'm pretty interested in seeing Chris, Stephen, XFS folks, [substitute the list of journalling projects] doing their best. So far everyone needs the same infrastructure and I'm quite happy to see what Chris and Stephen are doing. Moreover, once it will be there we are not going to stomp on each other's toes - after that point work belongs to individual filesystems.
I have no strong opinions on the way this stuff will look like - needs are similar enough and guys doing that are in much better position to decide - they have more or less debugged code to look at, and that's a big help.
In principle, the less code duplication they will get, the better (less pain to catch bugs afterwards), but IMO it's for them to decide. AFAICS they are working together quite fine, so the best thing for everybody who doesn't actively participate right now (e.g. for me) is to avoid interfering.
Relevant links (Score:3)
For instance look here [linuxcare.com] for an example of Linus apologizing for his behaviour, and then there is Donald Becker's problems [linuxcare.com]. Past complaints [linuxcare.com] have shown up as well.
Unfortunately I cannot right now find the post I was most interested in pointing out that the confrontational atmosphere limits participation by people from different cultures. (Specifically Japan.)
OTOH let me wrap up with my all-time favorite discussion of design philosophy, which happens to (coincidentally?) show Linus' flaming abilities [linuxcare.com]...
In short I think there is an issue. Can it be fixed? Should it be fixed? I don't rightly know...
Cheers,
Ben
Re: Has Linux Development Become Too Political? (Score:3)
This is a big ugly wart that has to be fixed. But there's another way to handle it than forcing everything through the generic pointer: just include the length of the fs-specific data in the fs registration struct. Then all the nasty includes can be unwound. I proposed this a few months ago but didn't get any feedback one way or the other so I didn't code the patch. After getting some email about it later along the lines of "good idea, where's the patch?" I decided to do it after all, but by that time 2.4 was getting too close and this really isn't the kind of change you want to make when you're on the putting green. As soon as 2.5 comes out I'll do it and submit it, we'll see what happens. All the filesystems have to be changed at the same time (though trivially) so basically the patch has to be coded and submitted all on the same day. And if it doesn't get accepted the first time around (the likely case) the process will have to be repeated a couple of times.
This is by way of saying that I hope that that particular issue hasn't got long to live. (on to the next...)
--
Re:If you want to read up on the situation yoursel (Score:3)
So summary (from all threads):
1. Al is not one of the most pleasant characters to deal with. As he himself says: "I am a BOFH, not a nurse". But he is usually right. And if you subtract the inflammatory tone so typical for *nix dicsussions he is right here as well. That is besides the fact that Al was not the only accused and at one point Reiser was throwing accusations left right and center.
2. I like what Hans does, but:
2.1. There is no common journaling API so his work, xfs work and ext3fs work cannot be converged. Especially at user space level. And this API is nowhere close.
2.2. As per Hans statement he has more than 6 more additional months of roadmap for features and cannot freeze. Kernel is in feature freeze right now. So ReiserFS should not go in. So if there is a problem with ReiserFS conforming to the current VFS layer then ReiserFS should be adapted.
2.3. There has been a flurry of new VFS level features. bind mounting, multiple mounting of partitions, devfs related stuff, etc. IMHO: these all have some very serious security implications that must be flushed all the way to userland. Before that VFS should not be modified at anyone's whim. That is besides the fact that kernel is in freeze and the discussion on modifications is moot.
3. Overall: IMHO in this case Hans p... is shorter. That is besides the fact that it is shorter by definition due to his licencing practices.
YetAnotherLinuxUser (and sometimes sysadmin).
P.S. This is not the only thread. There are few more.
Re:I don't mind third-party patches (Score:3)
leading to problems with too many pages being
dirty because the vm system can't write out ones
that are required for a transaction, so some sort
of major modification is required to fix things.
NT has a similar write-throttling mechanism.
Re:ReiserFS? (Score:3)
http://devlinux.com/projects/reiserfs/ - also,
Underhand.net's very own Kurt has a nice page
about converting your box to reiser, if you're interested,
at http://kurt.andover.net/Reiser-filesystem-HOWTO.h
Well, I use reiser on my x86 based squid at work,
and it's pretty damned nippy. It saves quite a bit
of space, gives me a 15% speedup on reads, and is
journalling. Of course, with journalling, unlinking is a little slow, but that's less
critical for me.
Of course, I don't like the three lines of ads on startup; I want to see
important messages about the health of my box, not spam for mp3.com, SuSe
and so forth. It didn't take long to knock that bit out, but it shouldn't
have been needed. When linux becomes spamware is when I choose to untrash
my FreeBSD boxes
It's a pretty nice fs, all in all. However, as much as I admire his work,
I can't condone Hans R's rather hotheaded behaivior, esp towards Viro.
The kernel guys have a lot of factors to juggle, and have to (in theory)
make changes based on the biggest potential upside. Where there are
disagreements, the maintainer makes the call, because he/she/it is the
maintainer.
I think we can do without fireworks in the kernel list. This filesystem
isn't really needed for endusers right now, it won't kill people if they
have to patch it in.
I know that Hans and others have put loads of very hard work into the code,
and I am sure we all applaud them for their efforts, and the quality of the
results. However if it's not right for the direction of the kernel, and
the vfs stuff etc, it's more than a little arrogant to expect the kernel
supertanker to be turned on a dime, just for one FS.
I genuinely suspect that the problem is as much in Hans' approach as the
code itself, and that if he were to cool down a little, there could be a way
to mesh a lot of the excellent work he's done into the kernel proper. Of
course, it would involve him losing a little face, but it's a question of
priorities. If he swallowed his pride, maybe he'd be better off, and hell,
the rest of us would too, since some of his work is absolutely first class.
Like I say, my work squid runs on his FS, it's not like I think it's utter carp- it runs like a dream..
It's not really appropriate to try and send the pugilistic villagers up the
hill to Castle Viro to burn the place down quite yet; he, and the other
kernel guys, are doing a sterling job- there's no reason to tear them to
bits because of one brilliant but misguided loose cannon. (There's a mixed metaphor for you)
Oh, and this 2.4.0-test2 kernel is doing pretty well so far, too
Just my two cents.. YMMV, etc.
Oh and my own spam for mp3.com, visit http://www.mp3.com/tib -it still sucks.
(Sorry about the cruddy formatting, bad hair day)
I don't know what's right... (Score:3)
Non-(kernel developers) should stay the heck out of this discussion. Political infighting is never helped by the uninformed butting in of outsiders.
Yeah, yeah "maybe we have a better view from the outside". But just imagine YOU are a coder working on a project with a bunch of people you know are competent but who don't agree with you. In comes a consultant to "help you out". How do you feel about the consultant? Now imagine that you were working on the project voluntarily and for no money. And further imagine that there is no "management" to appeal to make the coders listen to the consultant's ideas.
One of three things will happen:
1) Everyone will be rational and form a consensus.
2) Opinions will polarize and the project will fork.
3) Squabbling will continue.
Nope, I'll watch this one from the sidelines and I suggest you all do too.
--
1010011010's crusade against Linux (Score:3)
1) the VFS union has been around since early Linux, and was designed by Linus - this has nothing to do with Alexander Viro. Feel free to submit patches.
2) journaling will be what people submit. Right now ext3fs has a generic journalling subsystem, ie. any other filesystem can use the same transaction engine. Feel free to submit patches if you disagree.
3) feel free to submit patches that make the VFS stackable. Be wary of deadlock, recursion and generic complexity issues.
4) the answer is 'if done right then yes, sure.' Feel free to submit a patch.
5) Feel free to submit patches to Linus.
6) your observation does not match that of mine. As a matter of fact I dont have a vested interest in ReiserFS.
7) sure, feel free to submit patches.
I hope to not sound arrogant, but your VFS-related comments so far did not show a great deal of experience. Writing a filesystem does not necesserily mean you understand the VFS! Please make sure you understand what you are talking about - best way of learning is to post your comments to the linux-kernel and/or linux-fsdev mailing lists, not Slashdot.
Alexander Viro has brought alot of simplification to the 2.4 VFS: despite having 35% more filesystems, the total linecount of filesystem-specific code got 30% smaller. Alexander took lots of filesystems-specific hacks and made them a generic VFS feature. I dont think you want to argue with the fact that this makes the Linux filesystem architecture much more flexible. Ext2fs got only 12% smaller in 2.4, so it's mostly other filesystems that benefitted. (ext2fs got so much attention during the years due to its large 'user mindshare' that it was pretty clean already.)
Much Ado About Nothing (Score:3)
How come other filesystems have no 'problems' getting into the Linux kernel? How come that the number of filesystems in 2.4 is 35% more than in 2.2? Why is it that every kernel developer who contributes on a daily basis acknowledges Alexander Viro's hard work of cleaning up the VFS? Witness Mandrake and SuSE kernel developers defending Alexander Viro in the other thread, so it's ridiculous to shout 'Red Hat conspiracy'.
New filesystems in 2.4:
shmfs (a much bigger change to the VFS and MM layer than any journaling filesystem. Stephen Tweedie wrote a journaling ext3fs on almost-vanilla 2.2 VFS, so it's not rocket science.)
ramfs/cramfs. Features compressed file data - not a triviality either.
devfs. Despite Linus' reservations against devfs, it's in the 2.4 kernel.
This whole 'Reiserfs' argument is a red herring. Hans Reiser has to get his act together, and he should start contributing to the Linux codebase on a daily basis so that he can integrate potential extensions cleanly. Hans Reiser's problem could be rather that he financially depends on Reiserfs to succeed?
An unavoidable side-effect of development model. (Score:3)
Re: Has Linux Development Become Too Political? (Score:3)
And as another point, from a logistical issue, there have been a couple "feature freezes" announced for Linux 2.4. Which makes people really hesitent to send in patches since by all rights they will probably be ignored. Feature freeze to me ususally means bugfixes only. Yet the VFS has changed ENTIRE SEMANTICS for certian functions since the last two "feature freezes." This by itself is a little odd. Since you have name recognition with Linus, it's easier for you to get patches recognized than anyone new to the kernel team, yet the level of change is the same.
So as a polite request, could we utilize linux-fsdev more for the VFS traffic, and just keep good summaries of what VFS patches are going in? That by itself would help clear up alot of the debates.
Re:It's our right to make noise (Score:3)
Not a flame.
mav[LAG] thinks it's possible that anyone with a good enough grasp of the latest kernel and how it works is more than likely writing code rather than writing docs
I've known a lot of technical writers who have decided to focus their energies on English, and not C. They can understand how something works, and not be compelled to write more code on top of something that few people understand.
I've also known a few of these gifted technical writers who also have the knack of talking at length with programmers, asking the right questions and rephrasing things and asking again, thus forming a translator from "arrogant coder who expects everyone to read source code" speak into "interested technophile who wants to understand algorithms" speak.
As a matter of teaching people to program, I always insist that a person write out their algorithm in English, as comments, then each comment becomes a statement or two of real code. Then, importantly, leave the original comments in. It's all about the algorithms, people, not the reserved tokens and the use of operators. I wish more "advanced" programmers did this design-in-comments technique, because it (1) makes cleaner algorithms, (2) makes documentation for later readers, (3) makes it easier to port later.
Lastly, I know a LOT of programmers who would be a lot better if there were definitive 'state of the art' examples of source code, along with carefully written English discussions of what the source code is doing. If you don't know C, you don't know what while (*s) *d++ = *s++; does. If you're just learning C, it helps to see /* copy to the end of the source */ nearby.
ego's and Development (Score:3)
Re:When you're the maintainer, it's your call. (Score:3)
That's why i think linus and alan cox should have a web browser integrated into the operating system so that you can't remove it. I want to see something like IE5 in there! yeah! that would be good!!
in all seriousness - the linux kernel, ironically, is the same thing as neo-mail....it was a free 'program' (if you'll allow me a little license here) - that Linus originally intended for himself because he didn't want to have to pay inordinately high prices for other *nix distributions. That being said, linus (and AC now) have pretty much absolute say over what goes into the kernel, and more importantly, what doesn't. - I think the politics of the kernel have little to do with what's going on around it. Up to now, Linus and AC have been very good about keeping cool heads. If this changes, maybe other people will use other operating systems...their choice.
Right now, I use linux because it's the best choice for me, if that changes, i'll use another OS, probably (Open|Free)BSD. This is exactly like the NeoMail example. If it's right for you, use it, if it isn't - don't. No skin off your back, no skin off the developer's back.
Linus hasn't made any money off linux (aside from the peripheral gains like fame, and he'll never have to pay for a buger when he's around John 'maddog' Hall) - So, who cares about ego so long as he's still building a good OS. Like i said, if that changes, people will move on.
When software pissing matches go to far....people don't need to talk about the consequences...they just happen. Look at MS - all people see coming out of Redmond now days is a big river of piss...and look where it's getting them. Bad software is bad software, regardless of the reasons. Maybe it's shitty code, maybe it's shitty managerial decisions (brought on by whatever reason). But either way, it's a natural process.
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
Linux : incapable of leveraging commercial assets. (Score:3)
Gimme a break. The whole idea of open source is that (like some kind of chaotic genetic algorithm) it will weed out the best way to do things.
My criticism of Linux is that, in a case like the JFS, it fails to leverage the commercial entities who have a lot to offer -- SGI and IBM. It was just several months ago that SGI seemed strongly interested in moving it's JFS to Linux. IBM has made similar offerrings, as I recall.
Apache has done very well working with the com types, but Linux seems to prefer hiding in a cave, with a score of unrelenting primitives camped at the opening, shouting "Ugga Bugga!" at any which seek to enter, and poking them with a sharp stick.
Go ask Joerg Schilly(sp?) about scsi generic. Surely SGI, Sun, IBM or Adaptec could do something about the horrid state of CD Writing under Linux.
Make design docs available before implementation (Score:3)
Again a CS 101'er... I do not believe a thing such as Linux VM system has no actual design behind it. Of course, there is. But why isn't there some readily available design-doc of all important parts of Linux on the Internet?
Maybe Linux development could be made two-layered: open-designed and open-sourced. In stead of leaving the design issues to a few, many could contribute ideas at higher level. Then we hopefully get what we all want: the best design combined with the best implementation.
Re:It's our right to make noise (Score:3)
Yes. And being software developers and not diplomats the language used is not always the most polite in the world - I personally think it is fully OK, but not everyone thinks so. I am not a kernel hacker, but I already have the experience of being flamed down by one of the gurus (well - he was right :-)), after which I responded by sitting down for a day and identifying a though bug in his code :-) Someone else might respond with "Fsck you" and never again read l-k.
The current discussion regarding ReiserFS is not very significant, although it would be sad if it ended with Hans giving up his high-quality work. What bothers me more is that IMHO we are approaching a limit where the current way of project management won't work in the long term and there is very little being done about it. Just a few points:
- There is no version control system - instead we play games with x.y.z-test-pre-ac-aa-whatever and if something goes wrong, we binary-search the exact version where it happened instead of getting clue from changelog.
- There is no issue tracking system (the TODO saga on the l-k is better than nothing, but...).
- The design papers are missing (even a separately archived and publicized relevant mail threads would help).
- There is no regression testing (no doubt the developers of the particular subsystem have something, but it is not readily available).
Some problems were identified and adressed - the big delay between 2.0 and 2.2 due to missing definition of the target feature set and (hopefully) the horrible state of 2.2.0 when it came out due to allowing non-bugfix changes in the last pre-versions. Alan Cox does a great job at integrating and testing the patches.I hope that when the 2.4.0 comes out, the core developers will look back and discuss what can work for next years and what cannot.
Re:More women in charge of linux (Score:3)
==============================
http://www.geek-ware.co.uk
It's always been like that... (Score:4)
In fact, stuff like this happens no matter what, whenever you bring a number of people together... some people are going to argue. Just with OSS, they end up doing it in public... for all the world to see.
You should accept it, expect it, hell... even enjoy it... but still realize that nothing has changed.
--
Re: Cooperation (Score:4)
Obviously, it is a good idea to avoid ego-involvement, or conflicts stemming from same, in coding as in other human endeavors. Can this be achieved in the free OS movement? Possibly, but not with current tools.
So, the open source movement clearly has two problems to solve if participants want to work together more effectively. First, it has no managers with these skills, since only techies are involved, and they (naturally) have to spend most of their time focussing on learning new technical skills. Second, really effective project management software for remote or diffuse projects doesn't yet exist.
Btw, more bandwidth won't solve the latter problem, because even perfect video conferencing doesn't allow the same kind of interaction that live meetings run by great managers achieve. For example, social researchers have determined that just the presence in a room of a mirror increases "objective self-awareness" (which generally inhibits free and creative exchanges). The mere presence of a tape recorder -- even if it's not turned on!-- has the same effect. So imagine what effect the recorders for video conferencing have....
That said, pro-active documentation (which I used to recommend when I managed documentation at Bear, Stearns in the early '80's) can certainly remove some of the potential conflicts,if nothing else by helping individuals who need to work alone choose areas not impinged on by others! The possible trade-off is that the strength of the open source movement is precisely a not-necessarily-scripted characteristic, its willingness to embrace a totally new (better or more comprehensive) answer or approach to already solved problems.
If you want to read up on the situation yourself (Score:5)
(Posted anonymously to avoid karma whore allegations)
Concurrent systems, docs, and MMU guarantees (Score:5)
For Linux to remain stable, one of two things are going to have to happen. Either extremely heavy-handed personal control by people with a supreme grasp of everything that's going on in the kernel and who won't be deflected from their straight and narrow path --- that's where we are now, so be careful not to throw the baby out with the bathwater when knocking it. Or, fight the problem with technology and abandon the single monolithic unprotected space approach and partition the kernel into a large number of interacting but separate domains using the MMU plus well-specified and relatively stable internal interfaces. Needless to say, the second of these approaches would result in an utterly different kernel altogether, but at least it would have a longer life expectancy.
The current kernel is as brilliant as it is because of the brilliance of the people that are keeping it from falling apart under force of change. But there is a limit to human intellect, at least in the current pre-nanotech timeframe. The current developers should accept that, and work towards a kernel design that reduces dependency on their brilliance by providing an effective assortment of hardware-assisted guarantees. Learn from the user-space design of Unix. It's a good model.
It never happened (Score:5)
Truth is that in the heat of the email thread both sides wrote up some things that just weren't there. And after yesterday's invention of the "VFS flamefest" here on Slashdot, it seems logical that some of the people who weren't on linux-kernel but were on Slashdot yesterday get a bit worried.
Well, I guess this is how rumours come into existance :) Lets forget this whole thing and get back to coding like we always do...
Read the exchange for yourself... (Score:5)
Calling the kernel a "coalition of little feifdoms" is wildly inaccurate, because as the core systems of the kernel become more integrated with each other (think f.e. of the tangled web of interaction between VM/VFS/buffer cache/dcache/icache/swap cache/etc...), the "heads" of each work more and more cooperatively. Sure they still flame each other (time was, being called "pinhead" in linux-kernel was a mark of high esteem), but the amount of respect and degree of deference shown to each other's expertice is truly admirable.
Of course, politics show up every now and then... there are still people who think DevFS integration is the seventh sign of the coming of the antichrist. But even those who vehemently opposed it are now helping to make it really good by adapting the dcache and VFS to work better with it.
IMVHO, Hans made something of a spectacle of himself on the list. He ran around accusing everyone he could find of being corrupted by corporate influences (RedHat was his favorite target, since Alan and SCT of ext3 fame both work for them), while simultaneously admitting he had a strong financial incentive to get ReiserFS integrated with the kernel.
Of course, there are two sides to every story; Hans has been working on/with this thing for a long time, and has sunk a lot of his own blood, sweat, and tears into it, so I don't blame him for getting a little fanatical about it now and again. :-)
It's our right to make noise (Score:5)
On the other hand, I think the system could be improved a lot. There are some annoyances. For example, there is little, if any, documentation available on the one of the most critical aspects of the kernel, namely the buffer cache component of the VFS. It seems that you are expected to either learn about it yourself by reading every post on Linux Kernel, and every line of code in the filesystem tree, plus all patched versions. If you get stuck, you can play 20 questions on the kernel list, trying not to appear too clueless and at the same time trying not to appear so clueful that you will get flamed on grounds that you should have figured it out yourself. If your post to the kernel is phrased correctly then one of the VFS gurus will answer it - usually clearly and accurately, but not necessarily completely. And the game goes on.
The good news is that you *can* get the information you need. The bad news is that you are expected to jump through a lot of hoops to get it, and the information seems to be dolled out as a kind of payment for playing the game correctly and politely.
I think this should change. I think that the design documentation we need should be readily available - it has to be posted somewhere where everybody can get at it, and contribute to it. There's already a place for it: kernel.org. Why isn't there more there than just kernels and patches?
(The Linux Doc project is a good source of documentation, but not for in-progress kernel work.)
There's no shortage of people who would be willing to do this kind of documentation work if they were able to. Right now there seem to be some roadblocks in the way.
--
When you're the maintainer, it's your call. (Score:5)
I'm the author of an open source project entitled NeoMail [sourceforge.net]. As an aside -- yes, my real nick is Neo, not Bedemus, everyone started calling me that after I spent way too much on a Neo outfit for my work's halloween dress-up day and started wearing an ankle-length trenchcoat during the colder months -- I know, I'm a loser. :) When I set out to design NeoMail I had a certain audience in mind, essentially the same one as all open source authors when they start out -- myself.
Now, once I had something that worked pretty well for me (I had poured at least a month or so of effort into it at that point -- was taking on the project just to see if I could, teaching myself Perl in the process), I posted the code on the web and announced its release on Freshmeat. Immediately, the mails started pouring in -- some bug reports, which are always appreciated -- but more and more suggestions as to what people would like to see. Most of these suggestions were from non-programmers, and therefore included no patches or anything, just opinions as to where NeoMail should head.
I quickly realized that I'd better start narrowing the scope of NeoMail beforehand, otherwise I'd NEVER reach 1.0! A few things were decided up front:
- NeoMail would require no extra software be installed, aside from the necessary Perl 5 distribution and included modules, a web server, and an MTA.
- NeoMail would not be designed to do POP3, IMAP, etc. There were plenty of solutions doing this already, and it would have been easier to use Net::POP3 than to code local mbox spool handling myself, but it just wasn't the direction I wanted to head in. NeoMail served a certain niche quite well, and a chief benefit was that it didn't require users to even have access to a real system account for it to work.
- Plenty more -- you get the idea. I'd list everything here but how do I know people have even read this comment this far?
:)
Next, the arguments started."Why don't you use thus-and-such module to add thus-and-such feature?"
"Because NeoMail doesn't need that feature, and it'll make for a hairier install for admins having to hunt down additional modules to install."
"Yes it does need that feature."
"No it doesn't, and if it does, code it yourself -- that's why I made it open source!"
"But I don't code, why don't you add the feature and just make it an option so it doesn't increase system requirements?"
"Because I only have so much spare time, and after a while when you're dealing with an interpreted (yes, compiled before execution, but you know what I mean
"Fine, then I'll be forced to go elsewhere for my webmail solution." (This one always floored me! Made it sound like I had a commercial interest in them using my software!)
"That's your right, thanks for trying NeoMail anyway though."
"Wait, I was just kidding -- PLEASE won't you add this feature?"
And so on, ad nauseum.
Eventually, come arguments actually convinced me to add something, but only if I thought it would benefit the majority of users. I was writing a webmail solution for normal people, not geeks like me. :) When people started saying they wanted NeoMail to import and use their pine or mutt settings, I tried to explain that the vast majority of people that actually are using NeoMail aren't the admins installing NeoMail, but their users, who likely don't even know that pine's a mail client, not a tree. That's the problem when you release your work to a community of people like you -- eventually if you don't fight the urge to do it, your tool will become so big and complex that only people like you will be able to use it. That isn't always a good thing.
Now, I understand that filesystems are much more complicated than my humble webmail solution, but I think that what people need to realize is that just because someone is the maintainer of a piece of code that allows user contributions doesn't mean that the individual is morally obligated to include everything that comes across their desktops, no matter how well thought out or convincingly argued the matter is. The individual is, after all, the maintainer, and if you don't like it you're always free to add the feature for your own use -- that is, unless you're seeking to satisfy your own ego by getting your code included and a credit in the CHANGES file. The door swings both ways, you know.
I'd post more -- have a lot of thoughts on this -- but if I don't click "Submit" soon, I can almost guarantee nobody's going to read to the end of this little rant!
--
NeoMail - Webmail that doesn't suck... as much.
Re: Has Linux Development Become Too Political? (Score:5)
As for the "external pressure" - get a grip. Really. As far as I'm concerned this stuff is done on technical merits. You can't build a pressure sufficient to make me act against that. And I mean it - I consider self-respect more valuable than having a paid job. YMMV. You can't force anyone of us to do what you like. You can learn the kernel and start submitting patches that would be acceptable to Linus on their technical merits. That's how it works. I would be glad to see anyone joining the VFS/fs work. Learn it and go ahead. Or keep wanking - nobody can deprive you of that right.