Slashdot Mirror
Has Linux Development Become Too Political?
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?
It seems wrong not to include ReiserFS just because Ext3fs ain't completed... Let us have ReiserFS until exst3fs is ready, then do rewrite the VFS-code and everyone will be happy... =)
Hmm... I thought the idea behind Linus Torvalds heading development was his lack of ego as far as good code is consderned. I guess he doesn't have any leadership over those *FS guys.
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.
I think that this will be the real test of the Bazaar model, as described by Eric S. Raymond in his paper "The Cathedral and the Bazaar".
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.
Are -YOU- developing a major part of the Linux kernel? If so then you can develop it however you like.. if you aren't then shut up and let those who are get back to work!
The problem with things not being in the kernel isn't patching, it's finding the patches or device drivers. Linux needs a way to keep device drivers, kernel patches, something like LhD http://www.linhardware.com with the Device Driver database and compatibility info. All neat, organized and easily accessible.
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.
Okay, so I don't care what Larry Wall says, hubris _still_ isn't a good thing.
hubris
n : overbearing pride or presumption
Being a pedant isn't so great either.
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.
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.
Just with OSS, they end up doing it in public... for all the world to see.
Exactly. I'm sure some of the same things happen inside of corporations pretty frequently - we just don't hear about them. We're human, it's normal. Why get uptight about it?
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
>development, I'm afraid there is probably nothing to be done, other
>than resolve issues on a case by case basis.
And what pray, tell is wrong with this?
>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.
What a dumb criticism. There is no reason why Linux should leverage SGI's JFS over IBM's JFS. If you are operating primarily in a SGI enviroment use the SGI JFS. If operating in a IBM enviroment use the IBM JFS.
>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:-)
Basically use the JFS you're the most familar with.
Last time I heard people (in the US) saying this, I don't think they mean the USA can be bought for no cost.
Free Software: the software by the people, of the people and for the people. Develop! Share! Enhance! Enjoy!
Hmm... I thought the idea behind Linus Torvalds heading development was his lack of ego as far as good code is consderned. I guess he doesn't have any leadership over those *FS guys.
I must be missing something with this whole RiserFS situation. You see RiserFS was built for speed. From the ground up it was designed to be faster than EXT2. Latter Jurnaling became a big thing and mp3.com went to bat with some money. Some geak merged jurnaling code into Riser and performance actually went UP. I don't know how that happened since Jurnaling is an added layer of complexity.
The current situation is that Linus doesn't yet ship Jurnaling but Mandrake Soft dose. I *WILL* continue to buy Mandrake Linux to avoid the huge headache of retrofitting a better files system by hand. In all likelihood RedHat, SuSE and the rest will add RiserFS when they actually ship 2.4.x kernels. The end result is that it will be PCMCIA all over again.
For those who don't know Every mainstream distribution pushed PCMCIA for *years* while it wasn't officially in the kernel. Laptop users who downloaded the kernel to "try this kernel compiling thing" were often surprised to find that they had to retrofit PCMCIA by hand. That was just a peripheral driver. A lot of 1st time compilers will be building kernels that do not support the root file system. This is not a good thing.
I here there are reasons for keeping RiserFS out. I have no clue what those reasons are. I suspect Riser isn't at fault because he keeps running around like an eager beaver "What do you want me to do to get this in?".
I don't get this waiting for EXT3 thing though. Unless Riser makes many changes to the core system in the wrong way and nobody wants to maintain those changes long term. In which case it would be better to modify Riser to support the correct approach ( which isn't happening ).
Jurnaling is the one piece of technology that two distinct commercial entities have opened for the Linux kernel ( XFS from SGI and JFS from IBM ). It is important to a huge number of users including some who don't know what it is but simply wish Linux would come up quicker after a power outage.
Something doesn't smell right about this situation and it bodes ill for the future.
--= Isn't it surprising how badly I spell ?
They are both there because they code. You will almost certainly be using ESR's new kernel config/build replacement to build your kernel sometime soon.
By the way, 2.4 isn't late.
Regards
> Thats *22* seperate sub-versions of the same
> kernel version over a period of a month.
> Thats not chaos, thats insanity.
No, it's more like looking into an active CVS tree. Classic troll.
> Look at the firewalling stuff. It's been
> different in every stable version since 2.0,
> and will be different in 2.4.
And you're conveniently ignoring that 2.2 provided backwards compatibility via ipfwadm-wrapper (userspace), and that 2.4 provides backwards compatibility by compatibility modules (kernel space).
IMHO,it's a nice compromise,
Rusty.
Patching the kernel to support third-party things like ReiserFS is not a big deal for me and I doubt it is for many other Linux users..
A Linux system is just a mix and match of many things from many places, why can't (shouldn't) the kernel be like this as well.. and if the arguement is its too hard for new users to figure out how to use it, they should NOT be using it.
Linux is nowhere near the stage where a computer-illiterate can use it.
I always wondered if people would have been more receptive to ReiserFS if he hadn't named his work after himself... how many other kernel components require you to chant the developer's name like a mantra whenever you're talking about them?
:)
Hmmm... well, I guess "Linux" is from "Linus." But if I recall correctly, it wasn't Linus who named it Linux.... he wanted "Freeix" or something like that.
---
You seem to have a bone to pick with Al Viro personally. What, did he flame you publicly and now you need to get back at him? When I read the threads he participates in, I find he's occasionally abrasive, but somehow he and whoever he's talking with always seem to get down to business. Anyway.... Back to your argument:
You keep saying this. It doesn't make a huge amount of sense in light of the facts though. Linux has a huge number of supported filesystems (I daresay as many or more than I've seen in any other popular OS). So already, there's a few leaks in your argument.
The VFS implements a generalized interface to a filesystem which supports Unix semantics, with some extensions to those semantics. Well, guess what, EXT2 happens to support that full set, and other filesystems support some subset. Does that mean VFS is inherently EXT2 biased? Sure. Is it biased that way in a bad way? I don't see how.
I will grant you that there's still some heavy EXT2-specific (and other filesystem-specific) crude hanging around in VFS-internal structures, but if you check out the traffic on linux-fsdevel, work is continually underway to clean things up. But the argument that "filesystems need to look like EXT2 to be supported by VFS" is a non-starter to me, because if a filesystem looks vaguely Unix-like, it probably looks a lot like EXT2. (You know, concepts like "inodes" and "hard links" aren't the sole province of EXT2.)
The common journalling API is a good thing. This API is not meant to provide a "grand unified way to implement a journal", it's to provide a "grand unified way for the kernel to respond to a journalling filesystem." The latter is quite different. The VM needs to behave properly in the presence of a journalling FS, and Tweedie and the ReiserFS guys are actually working actively on solving these issues, Hans' outbursts notwithstanding.
I think the real problem is that we're all in violation of that old saying that those who enjoy sausage should not watch while it's being made. To extend that metaphor to Linux, we're watching while it's being made, and are complaining when it upsets our stomach.
--Joe--
Program Intellivision!
It's not about the name. I don't care if his name is part of the filesystem name. It's about him. He think ReiserFS MUST be in the Linux kernel, he thinks is a right, not a privilege. He created ReiserFS as a future part of linux kernel, he wanted a piece of his huge ego inside /usr/src/linux. But he didn't thinked his ego is too big to fit in the linux kernel.
I give all my support to Alexander Viro. Besides the technical details of ReiserFS and its realibility, i've always thinked that Hans Reiser made that filesystem, not for linux users, but him. His ego is bigger than Bill Gates fortune.
It's only recently Linus started doing "pre-patches" instead of just daily point-releases to try to get "more stable" code out to the masses in "official" point-releases while getting the dismembering-edge stuff out in an accessible form, which led to the whole "-pre" nightmare (reminiscent of 0.99 days...)
And having an -ac* fork is nothing new either. Who remembers the fiasco about vger's CVS tree accumulating patches to the kernel mainline, and the flaming Linux gave davem about it?
Welcome to Linux development... we want to get it right, and doing so is hard, which means our best asset is as many eyeballs as we can get looking at new code.
Clashing egos can cause anything to fail. It's not just "open source". I've lost track of the number of times at my company when the fifty year old executives start acting like three year olds. The only thing different about "open source" is that a lot of the developers don't get paid for their work, so you don't have the threat of losing wages and pension (if any) keeping people in a project. As a result, the emotional return on investment is more important.
If you think deeply enough, you will have no single direction for your outrage.
This is clearly the most intelligent post on this thread. You are absolutely correct in every single point you make.
Need a Python, C++, Unix, Linux develop
Two words .. no fsck along with no screaming clients because their server is taking forever to boot because those 200gbs worth of drives takes 4.5 hours to fsck with ext2
We aren't talking about hostages or freedom of the press, we're talking about code and software, which are tangible objects on some form of storage. And when talking about tangible objects, name me something or some instance were the word free does NOT mean "free of charge."
look at the title of the story guys....."Has Linux Development Become Too Political?"
My post wasn't about the specific instance at hand, but it was about politics in the Linux development and user community.....hope you get smacked by some M2's.
It's Viro and not Vero. Apologies for the typo.
-- It's always darker before it goes pitch black.
I'm sure backline must have a well-considered argument to back up his/her proposition. I'd love to hear it.
Never trust a man in a blue trench coat, Never drive a car when you're dead
I don't know how meta-moderation is done now, but I'd have thought meta-moderation if done properly, should be self moderating. If it were done so that a minimum of 3-5 people had to meta-moderate any given piece of moderation before it took effect and majority ruled then most of the rogue meta-moderation would be minimised.
I guess this really is a hard problem to really solve. The above solution would start to fail as the rogues register multiple accounts to get in more meta-moderation attempts.
I think the only way to really stop it is to have some eminently trustworthy people at the top, so that meta-moderation, rather than having a direct impact simply refers them to a higher power to check....Hmmm....
Boffoonery - downloadable Comedy Benefit for Bletchley Park
I believe he was talking about the NetBSD and OpenBSD split.
--
FAQ-O-Matic looks mighty useful for a lazy person.
.
Wow, did you get up on the wrong side of the bed this morning?
A kernel developer is someone who develops for the kernel. That's a pretty clearcut definition. For instance, *I* am not a kernel developer nor did I claim to be.
I didn't use the word "real" and I wasn't taking an elitist attitude. In fact, I'm inclined to say that "chip on the shoulder" attitudes like yours are more likely the cause of friction on ANY software project.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
if Reiser fs is in the kernel. If I make my root partition reiser fs from patching it myself, how on earth do I upgrade the OS when Red Hat brings out a new version? I can't just slot in the latest CD, that's for sure because it won't see my fs. That's why it's critically important that reiser fs not only get into the kernel, but into the distributions as a default fs option.
> kinda suprised to see some not so professional
> communication
Professional? I wasn't aware the kernel developers were getting paid to develop the kernel; until they are "professionalism" is an irrelevancy.
Remember, they're volunteers, they can do whatever the hell they like!
"Political" (for want of a better word) infighting is pretty common in software development, especially in mostly-male software teams. Closed-source developments that I've been on have seen disagreements as fierce as this. The *good* thing about this is that it happens in the open, and all can see the basis on which certain decisions were taken and whether the rationales were technical or to satisfy someone's ego.
ben_ the technologist and platform agnostic
Yes, two ego disputes ended in a split. It can be argued, though, that three BSD's is less fragmented than 40 or so Linux's.
Uh excuse me, but we _are_ talking about kernel development right? Where do you see 40 different Linux kernels? last I heard I could still download it from ftp.kernel.org and compile it on any distribution I might want to. The kernel is not fragmented, it's the distributions (and LSB should theoretically take care of this).
...Now that I think of it, I have a question: Why aren't there different BSD distributions? Let's say I decide to take the BSD kernel, the gnu utils, a bunch of apps and create a MyBSD distro. What's to stop me (besides it being somewhat dumb), and why has noone done it?
I strongly believe that trying to be clever is detrimental to your health. -- Linus Torvalds
Ah ok, I didn't know this, I thought they shared a single oir at least similar kernel (modulo the various ports).
Regarding the Net/OpenBSD split: I recently read up on it and there were also other, more controversial issues to it. This is one side of the story.
I strongly believe that trying to be clever is detrimental to your health. -- Linus Torvalds
Only 1 in 5 posts marked Troll actually deserve the title (see the jargon file entry for troll at www.tuxedo.org for a good definition).
The other 4 posts deserve Redundant, Off-Topic, or Flame-bait instead.
That's why it's critically important that reiser fs not only get into the kernel, but into the distributions as a default fs option.
Aren't you being a little presumpsious here? It would be silly for the distrubutions to move to ext3, reiserfs, xfs, jfs, etc. for a long time. Remeber most all of the linux partitions out there are still ext2 and will be for some time. Should all the distributions all of a sudden stop? Be an option maybe (Isn't it already in Suse though?), be the default no. You have decided to live on the bleeding edge. Non support from more "traditional" orignizations should be expected. Remeber no one forced you to use ReiserFS. It was your choice, you should of been prepared to deal with inconviences like upgrading, non-support, etc.
And is there any reason you can't update your machine using apt or RPM when the system is running? All the install/updater does run those two programs.
I know this sounds a little trite... I'm sorry for that.
If you read the kernel list, there are always people who want to write something but can't code (I haven't coded, but at least I stay quiet!)
These people compensate for their ignorance by raising issues and questioning the development process. I'm 'glad' to see one of them has moved onto Slashdot.
I care, I'm the one being screwed.
-- iCEBaLM
Well thats great, but what if I don't want to use Mandrake? I'm screwed.
-- iCEBaLM
ext2fs at this point is linuxes equivalent of a one true FS(TM). the problem is the VFS favours it over anything else. that requirement should be removed IMHO...a VFS should be a generic interface and not biased towards one FS. ...and its a BIG pain when only you understand the VFS.
data corruption is another problem - with the VFS changing and hacks being added data corruption is more and more likely. how bout writing up docs (or at least a summary) of the current architecture of the VFS (and being open to debate on it) ? its clear that very few filesystem maintainers understand it
This is even more picky, but the two versions aren't the same. The first version doesn't copy the trailing zero byte while yours does:
while (*s) *d++ = *s++;
vs.
while (*d++ = *s++) ;
Easy, automatic testing for Perl.
It doesn't mean "more eyes" or "noone has broken into my machine yet. Just try me!"
This was the issue at hand. Linux does not have a road map. It's parts are kept by individuals, and internal interfaces are not published let alone planned. If you want to change the kernel, you submit a patch, not a proposal.
This question is about politics because that is some of what it takes to alter the kernel. You can't just go RTFM, there is no FM. Either your idea gets in or it doesn't. And if it doesn't, its because a PERSON turned it down (whether its bad code, bad ideas or bad attitude). You can't go to the specification and see if your patch is part of the plan or if it satisfies all the requirements. This is where politics comes in. When people make subjective decisions that affect other people, politics is inevitable.
This is not about ReiserFS. That is just an example, and arguing that it is right or wrong or not really a "political" situation isn't the point.
Kernel development can go a long way to solve BOTH of these issues (Trusted and politics) by adopting a more organized design methodology. I grant that Linus has done well organizing things. But he has also made decisions that are not forward thinking.
Examples:
1. refusal to move forward in later version GCC compatibility. He once specifically said he would refuse patches that were purely GCC compatbility patches. He claims that he likes 2.7.2 because he knows it well. That is a very personal reason that doesn't have much purpose beyond his own convenience. That's the stuff politics is made of.
2. refusal to accept scalability modifications, such as some of those from IBM. This is more subjective. Maybe linux needs it or maybe not. But so far it is still a subjective decision. Noone but Linus can say what will be done.
Linux needs a plan. Linux needs requirements. Linux needs organization. (brace yourself, here comes the hard one...) Linux needs a design committee. (AAAAAHHHHHRRRGGG!!! OK, thats out of the way).
If you lay down the roadmap, requirements and specs ahead of time, then more people can do more work more quickly, with less confusion about what is expected and acceptable. There is less politics (in the development part anyway) because you just point to the spec and say "read that". Unless what you really want is to maintain a few people in power, which is a very political motive.
In the discussion of trusted systems, this is what they were talking about. As long as everyone was up to spec and all modules conformed to interface, then you know the system was trustable. When modules change interface and break each other by surprise, when there is no requrement for security beyond "close the holes and look for bugs", then you are not trustable no matter how secure you eventually make it. It's just another type of security through obscurity, obscurity of design rather than obscurity of implementation.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
> I think it is time for an IPO.
Very obviously this is a troll. Why didn't any mods catch up on this?
:. Ultimate Control Dedicated/VM Servers
On a properly configured system the root file system is going to be around 500M.
Yeah? So you keep /usr in / ?
C'mon: make /usr /tmp /opt and /var separate partitions and / will need only 40 megs or so.
Because there seems to be a lot of trouble, attitude and stonewalling in the vicinity of A. Viro.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Are You Hans's stooge?
Hahaha! Why? Are you Viro's?
Sheesh.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Who are you?
t h+threat%22&num=10&meta=hl%3Den%26lr%3D&sa fe=off&btnG=Google+Search
Talk about attitude...
http://www.google.com/search?q=coca+cola+%22dea
77 hits... lol
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
On 2: that would be good. There's problems with clsoed inodes in open transactions. If that's all that's meant by a "generic journaling layer," great.
Not cross-purpose. As the VFS spreads throughout the kernel, more things will have to interface with it. To avoid repeatedly hammering square pegs in round holes, the VFS needs to be made easier to work with.
The 'extensions' can be as flaky as they want to be, but they wouldn't be part of the VFS. That's the whole idea.
I'm not talking about modifiying VFS semantics on a whim. I'm talking about making it possible for users of the VFS to implement their systems without kludging around limitations in the vfs.
Documentation: yeah, a good thing. Documentation in advance is a good thing, too, even in "bleeding edge development." How about a little planning?
Agenda? I want Linux to be a good OS. The preferred, default Unix. I want it to have a journaling filesystem. I want it to be neutral and not favor some systems over others -- and as long as the VFS is Virtual Ext2, it will favor some over others. The whole idea of open-source an Linux is that we have freedom - a choice. When choice is artificially limited by poor design choices and stonewalling, then we've lost some freedom.
I wasn't trying to be venemous, but I was a little irked by Yet Another Viro Post to the effect of "shut up, read the code, and leave me alone."
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Thanks, Viro. Cola's misguided ranting aside, I want to see Linux improve because I like it.
Out of curiousity, why does Linus not want to use CVS?
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
1. So? It's still ugly. Viro's the maintainer. And I'm sure there will be patches submitted.
2. Yuk. Let's end "transactions" randomly! Whee!
1b,2b,3-5+7. Well, I felt free before, but thanks. Who are you, anyway? I'll try to answer your points? That's answering?
6. Who cares about ReiserFS and whether you like it? I'm talking about making the VFS more useful. Reiser's just an example of a FS with VFS problems.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
You raised a couple good points here. Linus hasn't made gobs of money off it, unlike, say the CEO and stock owners of say RedHat. IMHO, I think this is a good thing, since it largely separates major corporate influence from the kernel.
But you're right, there are other OS's out there, and if you don't like one, you can go use another. I had a kernel-hacker friend that did just that. He left Linux for NetBSD a couple years ago, and he never looked back.
His reasons were valid for the time, that the code was too hard to read. Segments of code weren't well documented, and kludges poped up in the most surpising of places.
One of the other posts raised a good point -- a lack of good kernel documentation, and the unintentional difficulty of getting the knowledge to add things to the kernel. This by itself wouldn't be so bad, if control of the Linux kernel. It doesn't sound very democratic, does it?
Don't get me wrong here, I'm not complaining that the development process of Linux is or isn't democratic, of course it's not, However I feel it's just irresponsible to say things like, "anyone can make changes to to the open source package," when there's little chance that those changes will be implemented in the official Linux kernel. And I have heard that qoute from different people in the past.
I'll stay with Linux as long as the pissing matches upstream doesn't affect my water supply.
> yes, women, in my experience, generally tend not :)
> to have penises and also don't have so many
> ego problems.
I have to concede that you are right on the
penis part. As far as ego problems go, I'm
not sure I can agree with you, but perhaps
the point you are trying to make can be worded
another way.
I know there has been research into women only
discussion groups online, and one of the
conclusions drawn is that an online discussion
for which women are the primary participants
is considerably less likely to degenerate into
flame wars. The communications styles of men
and women are different, and in text only
communications, discussion between men tend to
be more... volitile. In addition, it was found
that in an online discussion where women are the
initial participants, the introduction of men
will likely change the atmosphere in a way that
tends to drive women out of the discussion. I
can't find the bookmark to that research on my
system at home, so I'll check my work bookmarks
tomorrow and post a reference then, if I can.
While I'm certain I do not have bookmarks to
it, I have heard of research suggesting that
similar (although perhaps less extreme)
results can be expected at the introduction
of men into previously women only class rooms.
There are definately differences between the way
men and women communicate, and there is no real
question in my mind that we men, on the whole,
undervalue and underappreciate those things that
characterize the communications styles of women.
Having said that, I also believe that women often
do not understand what we men value in our own
communications styles. First let me point out
that both men and women can be childish in the
way that they conduct a discussion; We men are
certainly no exception to this rule. Second, let
me say that the point I'm about to make may be
controversial, and I do not want to discourage
anyone from voicing their disagreement. I DO
want to discourage those people who find
themselves on my side from flaming those who
don't.
Now to the point I am trying to make: I think
men are more likely, on the average, to turn to
analysis in resolving disputes between
participants in a discussion. While this
approach is not always the right one in every
discussion, its value in discussions of highly
technical issues cannot be overstated.
I'm not saying that women cannot participate
in technical discussions. I am trying to
address a point that I think 'backline' was
trying to make about differing communication
styles. I think there is a great deal that
men can learn by trying to understand the
communication styles that we think of as typical
of women, and I've tried to learn these things
myself. I place a greate deal of value on those
things that I have learned, and I encourage other
men to try it more.
I argue that call for a shift to a communication
style that is characteristic of women may result
from ignorance of the value, in the context of
a highly technical discussion, of some elements
of a communication style that is characteristic
of men. I'm not saying that the men on the
Linux Kernel developement list couldn't stand
to grow up (or at least lighten up) a bit. But
I do think they cannot afford to give up any
tendency that they have to resolve disputes
through analytical discussion. In the midst
of all the flaming, I think those people who
respond to flames with reason are respected for
it, and that respect for a display of calm
reasoning skills is more characteristic of
communications amoung men than amoung women.
Adrian
True enough -- still, no matter how many users say that this is the case, when it comes down to it, if the maintainer says otherwise, then otherwise it is. In other words, if you feel that strongly about it, then by all means fork your own kernel, or perhaps simply publish your patches somewhere else. If they fall into common usage because they're better, then guess what -- they'll get included. As I said before, I'm not a kernel hacker, and understand that there are differences as you mentioned, but when you get right down to it, if most Linux developers disagree with the maintainer, then it's time to fork a project of their own and select a new maintainer. As you said, competition is good. :)
--
NeoMail - Webmail that doesn't suck... as much.
NetBSD and FreeBSD were never the same project. With people not satisfied with 386BSD's maitnence, they started their own patch kits. That's quite different from a fork, it was two people with different projects
-bugg
So out of curiosity, what is the right attitude? Pointing out peoples flaws and being antagonistic towards those "non-Linux" rather than giving constructive criticism seems to be popular. I personally liked Linux much more when it had less dogmatic a consituency. ;-)
/. isn't the best forum. It's just that the example in the story which got posted somehow moved the debate here.
If you do want to debate the generic transaction handling code, I'd love to. Drop me a line so i can Cc you and linux-kernel, and linux-fsdev. (I promise not to be as sarcastic as above.) I've been meaning to put my objections into a good form for a while, but you are right,
Cult of Personality
Oh, it's definately not contained in the ReiserFS patch at ftp://ftp.devlinux.com/pub/namesys/.
Cult of Personality
1 - No, the generic_ip problem is not the problem that will help HFS, but having a generic, opaque pointer passed with read_inode(), (and perhaps a new get_inode() function to also pass the context) would. Would you be hesitant to include such a patch? (Which any fs which requires an context to read an inode, i.e. Journaling, would require.) Also, what bugginess would a simple extension like this that's well needed have the chance to introduce?
2 - Your preferences are irrelevant to the design of a VFS. It's a VIRTUAL file system. It shouldn't dictate what mechanisms that filesystems should use to ensure consistency. It controls the way in which a user accesses a namespace.
3 - Yes, but try writing a filter driver with the current VFS on a filesystem not designed for it.
6 - Bullshit. I hardly ever see design stuff on linux-fsdev. Maybe i only get a few of the messages, and somethings wrong with my mail server, but i ususally find out about the changes when some of my code breaks. I understand that it's bleeding edge development, but I keep the developers that depend on the code I write half-way informed of changes I'm making. Even just posting a summary of the patch to linux-fsdev would be better than what I get in my mailbox. I have little time, and i still make it a point to write a CVS log so people can know what I did. (And i can know what i did later.)
Cult of Personality
I've been thinking about doing this myself. I've got plenty on my own project, but since this is directly relevant, i can definately give it priority. So feel free to drop me an email.
Cult of Personality
May i say that elitist attitudes like this are what lead to politics in software. So what is a REAL kernel developer? Or an outsider? Just because i haven't released my work yet because i want it in a consistent state, but i do keep up with and are intimately familiar with the changes, does that make me an "imaginary" kernel developer?
Could you post a list of your patches for us to see? I'm curious to see what a real kernel hacker is like...
Cult of Personality
Of course I call strcpy(). That's an even more powerful idiom, with the added benefit of being standardized, so that it can be incredibly cleverly implemented/optimized if the vendor felt like it. Still, I don't think that particular while loop is that horrible...
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
Well, I've noticed that most ego problems women have (including but limited to their all-prevading belief in the absolute superiority of their own gender) are things which we feeble males are not allowed to call ego problems, for fear of being labeled all sorts of negative things. When you take those into account; however, most women are easily as egotistical as most men, especially in high Mach positions like, say, linux kernel development.
ramfs/cramfs. Features compressed file data - not a triviality either.
Sure, but it doesn't touch stuff outside the filesystem, does it?
devfs. Despite Linus' reservations against devfs, it's in the 2.4 kernel.
Huh? Linus was the driving force (besides Richard Gooch of course) behind the inclusion of devfs into the kernel!
-- KDE programmer and computer science student in Klagenfurt, Austria.
Without much whining> that's simply not true. See this and that summary of discussions on linux-kernel.
-- KDE programmer and computer science student in Klagenfurt, Austria.
So? ReiserFS has had a lot of releases as well, and besides, while Linus may have had only implementational issues with devfs, other people object to it in principle.
So it's not that Linus stalled it for a long time, there were bugs to be ironed out, but even so it wouldn't be in had Linus not taken a favourable stance to it...
-- KDE programmer and computer science student in Klagenfurt, Austria.
Well,
:-) I have actually allways ten.
/. could have one permanent section /. users
I was only selected for moderating about 5 times,
as far as I can remember.
On the other hand I'm elceted to meta moderate each day.
As far as I can realize/understand there are
exactly 24h between two meta moderation sessions.
If I choose to meta moderate earlyer, I get the
same moderations to meta moderate again.
I can only speak for my self, of course.
I usualy accept all positive moderations to
a comment.
But I read carefully the negative ones. It is
realy rare (less then 10%) that I find a negative
moderation unfair. Very often those unfair down-
moderations are simple opinions of their author.
I do not hesitate to mark themn as unfair, in
the sence of *free speach*.
However it is astonishing how much *shit* is
posted and (correctly) moderated down as troll.
I've seen threads with up to 30% of the articles
moderated down.
Once I changed my settings to see all postings
and followed especially the down moderated stuff.
The majority included links to porn sites or
unrelated advertising.
Interesting is: I saw the same posting during
one moderation once moderated as "flamebait"
and once as "informative".
Some peaople wonder, how one can get a moderation
of plus 5. That's because a moderator does not
see the moderation done by others. If you choose
to moderate you see the threads without allready
applied moderations.
Well, I do no know what karma points are good
for
As far as I can see, unfair downmoderation is
rare. Unfair meta moderation should be cought
because the same comment is meta moderated
several times.
(I had the same comment three times during one
meta moderation session!)
I do not see a reason for change.
Propably
"controverse (meta) moderated postings".
The section could contain up and down moderated
postings and/or unfair meta moderated postings,
to be polled/voted on by all
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Oops. Didnt mean to post the above anonymously. I usually reserve AC for flames and trolls.
while( *d++ = *s++ );
That "algoritm" is one of my favorite piece of C code, since it shows the power of pointer arithmetics as well as how incomprehensible/ugly/evil C can get in real world situations.
Try out fish, the friendly interactive shell.
- All voters get exactly one vote
- Absolute majority(66%) is always required.
- Linus is the only one elgible to vote
IMO, this is the optimal balance between democracy and swiftness.Hope this helps
Try out fish, the friendly interactive shell.
I think its about time someone took the time to port the Linux kernel to a platform that is favored by Men with Big Penises (MwBP). For so long, MwBP have had to deal with the deal with the same distro of GNU/Linux used by Men with Small Penises (MwSP). How fair is that? Have you ever tried to grep in a MwSP distro of GNU/Linux and felt it didn't measure up? I have. You end up feeling cut off before you achieve full penetration.
According to South Park, a majority of Linux Distro's have been focused towards Japanese men. Instead of Blame Canada, it should be Blame Japan!
Just say no to Linux Distros for Men with Small Penises!!!
Strange women lying in ponds distributing swords is no basis for a system of government.
I read most of the exchange between Han Reiser and the other kernel people. Personally I think the problem is mainly with him. Not totally.
His way of writing often is very well... excited. And making comments about other people is certainly part of quite a few posting.
Now this is my own opinions so you don't have to agree with it. But really if someone can't even talk nicely it doesn't help anyone to help him.
-cwk.
Emil, I learned that you call strcpy() instead of such horrible statements, and that you call printf() for your example ;-)
Too bad I got tired of such games after coding in assembler, or I would have fun encoding my name like this too!
- Steeltoe
http://www.debunkingskeptics.com/
as far as the political contrast is full on the open, to be judged by everybody, and there are no hidden reasons behind it.
Ciao
----
FB
Farewell!
NightHawk
Tyranny =Gov. choosing how much power to give the People.
However if you want to join this same system, then log in and then visit here.
It's rather unfortunate that unlike moderation itself, Meta-moderation does not seem to have any checks and balances to prevent abuses. Hopefully someone will reform it.
-- "I can't tell the future, I just work there." -- The Doctor
I've never actually seen Meta-meta moderation before. Mind telling me how to join it? = P But still, having a top level in moderation in Slashdot that is unaccountable still creates the same problem, and more and more people are getting disillusioned with the whole system. Just read the posts in the Metamoderation and Moderation rooms/sids. I'm not lying about this one.
Feel free to enlighten me on this one if I'm totally unaware that this is already happening, but I believe that those allowed to participate in highest meta level of moderation should be drawn from those deemed to be the fairest and be a totally an accountable and trackable/tracable system. Currently, anyone (even brand-new trolling accounts) can become meta-moderators. This is really not my idea of a fair Slashdot and I've already been bled about 5 karma despite being my utmost at being fair in all my judgements and yet I have no idea why.
Someone should start a reform Slashdot movement.
-- "I can't tell the future, I just work there." -- The Doctor
- No penises: OK
- Not so many ego problems: My mileage does vary here. Just one example: Almost all the girls I know tell me it's awful to work in a place with just other women and no men around, because that leads to a lot of bitching and politics.
The main problem, however, would be that having chicks around would pump up the egos of all the males.
*sigh*, we (that is, all of us, women as well) just haven't left the caves for very long...
"We won't use guns, we won't use bombs, we'll use the one thing we've got more of and that's our minds" - Pulp
Humans don't organize well above the tribal level (5-25 people), just something built in. Any Larger structure that runs well is usually either INCREDIBLY disciplined, as in the Japanese Auto-worker sense. Otherwise it is merely a set of tribes or teams or fiefdoms where each leader is part of a "higher" tribe. You can of course rotate who belongs in the "management" tribe, but that would be representative democracy ;)
Usually you only get this kind of in-fighting when people see a great benefit to the users for general use, yet there end up being grey areas for features... people rarely fight over cut-and-dried this-or-that decisions that are easy to make (c++ or cobol in the kernel? -- that was easy right? Bobs' printing file system or Bills? - there aren't any quicky answers so people fight out of loyalty to a person or product.
I think recognizing it, and organizing a public treaty/ceasefire between the two parties is in order. Make them sit down and say what is at the root of the problem. Force them to review the others work, not negatively, but build a list of things that are good about the other product, and questions where they think it is bad.
Instead of "Mines better because of this", ask "why doesn't yours do this"... they might suprise each other.
I would be happy to host such a public debate.
father@bigattichouse.com
www.bigattichouse.com
If the BSDs had a king like Linus to resolve disputes, things would be quite a bit different now. There would be one BSD and it would probably have more marketshare than Linux.
Two things hampered the BSD marketshare:
1) The infamous lawsuit. That scared away the investors and corporations.
2) The GPL jihad. Certain loud voices in the Linux community used it to convince the geek crowd that the only thing worse than acne, the Borg, and dating was having your code 'stolen' by an evil corporation and used to nefarious ends.
So, you have the high and low ends of the mindshare market cut out of BSD.
Trust me, you don't want a core team.
Well the FreeBSD core team seems to be a heck of a lot better at settling ego disputes than the benevolent dictator model. Yes, two ego disputes ended in a split. It can be argued, though, that three BSD's is less fragmented than 40 or so Linux's.
"I shoulda never sent a penguin out to do a daemon's work."
Cat, the other, tastier white meat.
Meta-meta-moderation?
You're forgetting that the BSDs have many flame wars of their own.
The advantage of Linux in in regard to these sorts of flamewars is that in Linus, you have a divine-right monarch. A final arbiter, if you will. While its true that the BSDs have core teams, those core teams don't engender the sort of respect (hero worship?) that Linus appears to have. After a controversial decision is reached by core, there will be a lot of biching & moaning from the developers. The loosing parties sometimes flee to other BSDs or even Linux. Sometimes large numbers of developers start talking about overthrowing core. About every 4 years or so, BSDs split because of flame-wars like this. When is the last time the Linux kernel split?
If the BSDs had a king like Linus to resolve disputes, things would be quite a bit different now. There would be one BSD and it would probably have more marketshare than Linux.
Trust me, you don't want a core team.
Actually, I suspect he means code documentation. Meaning comments. So that when you go through the code for reasons of understanding, or debugging, or whatever, then you have a clear understanding of what's going on.
And IMHO, anyone who writes code (complex or not, but _especially_ complex) and doesn't document it should be summarily beaten with a wet noodle and sentenced to doing technical support. :) Anyone who does this for open source should get double the punishment, because god knows who's going to need or read this documentation or for what nefarious purposes. It's all hanging out, with a thousand eyeballs peering at it, and it needs to be crystal clear.
---
"No problem. I have the capacity to do infinite work so long as you don't mind that my quality approaches zero."-Dilbert
Linux has become political. Period. The part that really annoys me is how pretentious Linux and the whole OpenSource movement had become. The high profile of Linux as the next great challenger to Darth Gates and his evil Windows empire, had caused too many non-technical punditsto wax eloquent about the state of OSes and IT in general. Oy veh!
*** Stop trying to be cool. ***
Come on folks, this is really cheap. Mostly these topics are completely ridiculous attempts to fish for advocacy, or simply ridiculously narcissistic.
This shows how chaotic the Linux world really is. Look at the kernel versioning system; the development kernel is at something like 2.4.0-test1-ac22. Thats *22* seperate sub-versions of the same kernel version over a period of a month. Thats not chaos, thats insanity. Look at the firewalling stuff. It's been different in every stable version since 2.0, and will be different in 2.4.
It would be nice if stuff like this was toned down or private. I had a similar incident happen on a private (like a bunch of people I know) discussion group. The particular person (or me) was being a total peen about something so we hashed it out privately.
I am a firm believer in not fighting in public unless_there_is_no other option. I mean heck, there are a lot of people I have dealt with in the Linux, UNIXoss, GNU or whomever community, who are allegedly important, smart or suffering from cranial enlargement and they were total freaking dickbags. We all get that way about certain things.
I do not really know (or really care) if their attitude was political or penal related, but they kept if between us. Any public discussions we had were quite civil.
But I have been nice enough not say anything about it. When something is public, saying something that seems mean, even a phrase as trivial as shut up, makes you look bad.
The worst problems are unaddressed ones, at least this reader brought it to someone's attention. One thing I fucking despise are the haughty who refuse to answer your queries because you teed them one way or another. They are so sacless as not to try and resolve a problem. In such a case I can see where public lambasting may have to take place because, again, there may not be an alternative.
Where is it?
That's a fairly narrow and inaccurate description of how Linux started.
Linus Torvalds wanted to produce something big.
Andrew Tannenbaum had a pedagogical Operating System (sort of an ensigns training ship at the naval academy sort of thing) called Minix.
Linux didn't start because of this difference in objectives. The Linux/Minix 'struggle' was peripheral to the reasons Linus got started on his interesting experiment. Sure, if Minix had evolved into what Linus wanted he wouldn't have gotten started (he'd be 'just another Minix hacker' now,) but it's a mistake to claim that the conflict was in any way pivotal.
Some would even go so far as to say that the success of Linux was circumstantial. It started right at the point where the bandwidth explosion on the 'net got started. It was also the point in time where Microsoft's OS initiatives started orphaning perfectly good 386 boxes, which then became available 'for free' for hackers to tinker with.
No history can ever be distilled down to a single conflict. 'Great simplifiers' are usually demagogues.
That's scary you know.
Would you drive across a bridge that the workers made up as they went along?
Wouldn't you end up looking a few hundred yards down the river, notice the wreckage of previous builds hanging there and back off, looking for the ferry instead?
Yes, I know, I know. The 'reference design' is every other Unix that came before, and every OS textbook (though nobody will admit to owning a copy of Tannenbaum any longer) thats ever been published.
Unfortunately that amounts to 'looking backward' quite a bit more than a progressive software project should have to. We see in the issues that this discussion attempts to examine what happens when truly innovative people try to have their say in a project steeped in legacy.
The Linux kernel method could be the new great development model, if ESR's vision is accurate. Or it could be one of the last great skunkworks, a disaster nobody will ever want to repeat. Only time will tell.
Some people have actually forecasted that 'clashing egos' is the thing that will cause (noncommercial) open source to fail. I'm not saying there right, but it does seem they are on to something. It is good thing to have some authority that everyone has to listen and obey ("Do it like I say or you're fired!"). Linux has Linus controlling the kernel but he really can't nor doesn't want to interfere too much. If Linus started acting like Hitler the developers, who often don't get paid for what they do, would simply say "fuck this, do your own VFS cos' I'm not writing one line of GPL'd code ever again".
LOL. Too funny. It's all too true that everything becomes virtualized in the free software development arena. Testosterone
and penis-size contests translate perfectly
into the world of Free Software.
In my experience, I've received e-mails from people where their list of OSS achievements is 8 times longer than the body of their e-mail message. Yo, let's pull em out at the next BALUG meeting and measure! LOL, anyways, good post!
- besides, I think it's Linus' choice as to whether to have the _big_ operation or not.
[ insert meme here ]
Maybe if we just put more women in charge of Linux development we wouldn't have any of the problems.
==============================
http://www.geek-ware.co.uk
==============================
PROUD to be GEEK
I think you need to practice your reading skills.
Are you adequate?
You too need to practice your reading skills. I didn't imply anything. I didn't make the original statement.
Anyway, let's go back to the original. I'll bracket it so you can see:
Which expresses two different, independent clauses: (a) that *BSD is pretty widely accepted anywhere, and (b) that Linux isn't as accepted as some people would like it to. This is wholly compatible with Linux being more widely accepted than *BSD. (Remember, Linux Torevals has been quoted as saying that his goal with the OS is "world domination").
Now, you obviously read it this way:
This is what you thought it said. But all this shows is that (a) you don't know shit about comma placement (if that were the reading, one would have a comma after 'much'), and (b) you assumed the poster to be stupid and wholly oblivious to the facts, and by extension, that you are an arrogant idiot who thinks him or herself smarter than anybody.Are you adequate?
Case in point: Which distributions allow me to use ReiserFS filesystems on installation?
/usr/src/linux/fs/reiserfs/utils/resize_reiserfs
It's not perfect. AFAIK it shrinks only.
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..
Moderation Totals:Flamebait=1, Interesting=2, Overrated=1, Total=4.
Just goes to show that people don't agree on stuff. Even Slashdot Moderators.
--= Isn't it surprising how badly I spell ?
Hmmm... I use Slackware and Debian, and generally never have any problem getting other people's software to use... That's the point of having the source instead of using RPMs :-)
(Of course, if there's a prebuilt package for _your_, you can always use that...)
/* Steinar */
(This comment is of course GPLed.)
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.
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 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.
--
Torvalds.
--
Politics in software: this could be the oldest story /. ever covered. This is *so* not new.
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.
-- Don't Tase me, bro!
Would anyone who uses this FS on their box please post a little bit about what's so good about it? The only thing I could tell from reading the posts in the kernel archive is that it's a journaling FS.
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 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.
SuSE Linux as of 6.4 (I don't remember if it was available in 6.3) offers the use of ReiserFS as your primary FS on all your partitions except /boot because LILO has some problems with it. SuSE's kernel modifications are very good and I reallyu enjoy the use of a journalling FS, it is something Linux as a desktop OS really needs. But the fact SuSE has to offer it as an extra is something we're seeing alot more of. Things the kernel dudes don't like need to be hacked by distros and inserted into said distro. This causes a rift between Linux as an OS and a distro as an OS. Most of you are surfing around on some company's distro and you for sure know people who believe Redhat and Linux are synonyms. The whole development for Linux is going to fork, there will be the canonized kernel and "official" shit from the kernel dudes and there will be highly patched kernels released by distro companies. The GPL allows for you to change the entire kernel structure as long as you provide the source to it. If one distro becomes large enough they can decide to build an incompatible kernel that will only run Redhat or insertyourdistrohere software. We already see incompatibilities between different kernels, what the fuck are we going to do when one kernel build doesn't work with another?
I'm a loner Dottie, a Rebel.
In fact we often hear that developers are reluctant to write documentation; this is true for everybody else.
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. 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.
My journal has hot
Making noise is one of the things that keeps the open source system healthy. I think that in general the Linux kernel has had good stewardship, and though I personally have not had direct interactions with Al Viro, I think that extends to him as well.
:)
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, particularly Homesteading the Noosphere and possibly the Cathedral and The Bazaar. (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.
My journal has hot
...the Open/Free/whatever *BSD way of doing things, with a "core" making decisions according to what others have to say is the right direction.
.02
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
-- It's always darker before it goes pitch black.
I cannot see a single from Hans Reiser neither on linux-kernel, nor on linux-fsdev. *NOT A SINGLE ONELINER PATCH* This pretty much tells it all.
--Coke
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.
--Coke
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?
--Coke
--Coke
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.
--Coke
"... 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??
--Coke
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.
--Coke
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.
--Coke
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.
--Coke
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'?
--Coke
Once again, I believe that the point was that atm it is damn difficult to port a JFS to Linux. How can one use the familiar one if the familiar one does not exist on our platform?
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:-)
>I don't think that documentation lends itself
>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.
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 for example...
--- Hot Shot City is particularly good.
Non-(kernel developers) should stay the heck out of this discussion. Political infighting is never helped by the uninformed butting in of outsiders.
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
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.
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
. . . we should resolve this point properly. Have a debate and vote on it.
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.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
So you're saying that if Reiser re-submitted that same code outside the rest of the fs driver, it might be accepted? Oh, and removed the "hack comment?"
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.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Ah, but "temporary inclusion of the *@!#^* ->read_inode2()" is different than changing read_inode() itself, and actually providing decent functionality in the VFS rather than just including hacks. For instance, why not read_inode() with NULL as the second argument rather than read_inode2?
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?
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
DevFS: Linus mandated its inclusion. End of story. Also, it is a simple filesystem, like Ext2, and doesn't tickle problems with the VFS.
shmfs: don't know history of this one, but it is a simple filesystem; prob. doesn't hit the VFS limitations.
ramfs/cramfs: 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.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Great! Zappe might be doing that as well. Perhaps you two can talk...
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
All good and well for a single userspace program designed to meet specific, limited needs, but the kernel msut support all programs. If the kernel limits something, there's no way around it, w/o forking Linux.
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
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Sorry, I meant OpenBSD... I really did ;)
A deep unwavering belief is a sure sign you're missing something...
There is nothing inherently wrong with that, but from a cleanliness point of few it is not very nice. If another option is available, this is also not the nicest way to resolve the problem. We have a court system where there is a blanket (the law) that makes certain cases always come out one way. Usually, it is not handled on a case by case basis. If it was, then the court system would fall into anarchy. I think people generally hate this method for that very reason, and will try to find another, more structured way to do it if possible. However, in this case, I don't really think there is one.
A deep unwavering belief is a sure sign you're missing something...
He. If you think you know C, you should recognize that strcpy() implementation as a verbose version of K&R2 page 106. If you don't, you probably haven't read K&R, and it then immediately follows that you don't know C. ;^) Also, I think your idea that all code should be commented sort of goes against the idea of idioms in languages. The above snippet is an idiom, and an experienced C programmer will recognize it immediately as such. Of course, someone with less experience wouldn't, but then it becomes a learning experience!
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
"considering the circumstances behind the split of NetBSD and FreeBSD"
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.
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
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.
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.
--
Free Software: Like love, it grows best when given away.
In this response, 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.
Free Software =! Open Source Software! Actually, technically what you're saying in this is: Free software is equal to not (!) Open source software. I believe what you mean to say is: Free Software != Open source software. Nice little rant, but get your syntax right. :)
Perception is reality
"Being human, is there any way we can avoid this?"
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.
IBM to start shipping Caldera, Dell to start shipping Red Hat. MS has been ordered to break up. Several companies are intergrating Linux based OS's into previously, unchartered territory - handhelds, navigation systems, etc.
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.
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.
[ insert meme here ]
1. That may actually work, but I think that you are missing the real source of ->read_inode() ugliness. It's not a union in the inode, it's the fact that ->read_inode() itself is ill-defined. IMO iget() should eventually go away - the only reason why it is still there is knfsd and Roman's patches look pretty interesting in that respect. I suspect that one of possible solutions is to have a variant of iget() that would return the marked inode instead of doing ->read_inode(). And let the fs (in foo_lookup()) call that, check whether inode is marked (== new) and if it is - fill it directly. I.e. do whatever your read_inode() would do, but with the arguments passed explicitly instead of trying to fit them into ->i_ino. Filesystems that do not allow links are already doing something similar (they are pretty much guaranteed an icache miss). If you want more details - let's take it to fsdevel, OK? It's _not_ a 2.4 project, though. Allocation is completely separate beast.
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.
1. Search l-k archives for the last couple of weeks and you'll see there my posting proposing (one more time) exactly that, with details on implementation. Subject to approval of individual fs maintainers. BTW, any fs _may_ use ->generic_ip - quite a few do exactly that. Reiserfs can use it right now and could do so a year ago. At that point decision on each fs belongs to fs maintainers, in that case - to Hans. All infrastructure is there since long and many filesystems are using it. Oh, and that contributes _nothing_ to HFS problems.
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.
People who follow the kernel threads summary are well aware that this topic shows up there.
For instance look here for an example of Linus apologizing for his behaviour, and then there is Donald Becker's problems. Past complaints 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...
In short I think there is an issue. Can it be fixed? Should it be fixed? I don't rightly know...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
1.Why is there a big, ugly union in the VFS rather than having all filesystems use the generic pointer?
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...)
--
Life's a bitch but somebody's gotta do it.
I do not intend to avoid Carma Whore allegations as I get blasted on casual basis anyway to make sure that my carma is down with no artificial assistance.
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.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
...but I know what's wrong.
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.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
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.)
--Coke
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?
--Coke
While the very open style of development has been very succesful for Linux, it is not without it's flaws. Because it is open, people who maintain pieces of the code (such as VFS) actually have a lot of power over what happens to that code. In theory they don't, because people can always write their own code, but I don't think there is anybody who is willing to fork the kernel over this issue. Thus, egos and ego clashes get in the way of development. I'm sure this also occurs in the BSD development teams (considering the circumstances behind the split of NetBSD and FreeBSD) but is just less public due to the more closed nature of the development. Actually, I think such development problems are present in every large Open project simply because there is no management breathing down your neck to stop bickering and do something to further development. Given the fact that people will always have egos, and that nobody wants to close up Linux's development, I'm afraid there is probably nothing to be done, other than resolve issues on a case by case basis.
A deep unwavering belief is a sure sign you're missing something...
Actually, Al, I have been working with the VFS, and alot of the problems is the undocumented, unnanouced way in which the VFS gets changed. I try reading through linux-kernel, but the volume of messages is WAY too much to sort through daily. And linux-fsdev is a low volume list that rarely gets a post. So the way that i find out about changes is to have my filesystem break in some wierd way, and find the diffs for ext2, go through them, and see what changed. And i also haven't seen any reason for the symlink change, other than an "aesthetic". (If there are reasons, please feel free to direct me to them.) So one of the gripes that Reiser had that is valid -- that the changes to the VFS are kept opaque, and you end up having to read the source to ext2 to figure out what the hell is going on. Meanwhile, I am trying to write a filesystem, which is a rather mammoth task in itself.
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.
Cult of Personality
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.
[
I noticed the thread in the KC on Linux care and was kinda suprised to see some not so professional communication, as I read some of the response it became clear that the e-mail that started it was made out of frustration (you've spent years working on something and then you're told, it's not ready yet). I think initial responses had a little too much ego, but as they go on, they get down to business. I think this model will work in the long run, as long as people STAY OPEN MINDED, and are willing to listen and explain. Beware the darkside!
you're right bro! the kernel needs to be as flexible as possible and allow support for as many programs as possible.
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
"It is seldom that liberty of any kind is lost all at once." -David Hume
Two developers arguing about the best way to do something is a crisis in Linux politics?
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.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
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.
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.
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.
--
--
A PC without windows is like chocolate cake with no mustard.
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.
Start here.
(Posted anonymously to avoid karma whore allegations)
It's going to take more than just good documentation to keep Linux from developing out of control and spiralling down towards instability. Most non-trivial software heads in the general direction of loss of control as it grows, but operating systems are specially vulnerable to this syndrome because they are highly concurrent systems, and concurrency offers opportunity for problems to emerge with the greatest of ease.
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.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
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...
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. :-)
Making noise is one of the things that keeps the open source system healthy. I think that in general the Linux kernel has had good stewardship, and though I personally have not had direct interactions with Al Viro, I think that extends to him as well.
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.
--
Life's a bitch but somebody's gotta do it.
I'm the author of an open source project entitled NeoMail. 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.
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.