Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Linux

Kernel Contributor Corbet Says Linux Community Is 'Intimidating' 177

Posted by Soulskill from the what-are-you-looking-at dept.
An anonymous reader writes "Key Linux kernel contributor Jonathan Corbet has admitted the developer community can be intimidating and hard to break into. He highlighted the issue during his Linux.conf.au presentation on the Linux kernel. Corbet expressed concern about the exclusivity of the kernel community, but says it's doing well regardless. He said in a period of just over a year, 55,000 individual changes from 2,700 developers (representing 370 employers) were made to the kernel, equaling 2.8 million lines of code. Corbet called the process 'alive and active.'"
This discussion has been archived. No new comments can be posted.

Kernel Contributor Corbet Says Linux Community Is 'Intimidating' More

Kernel Contributor Corbet Says Linux Community Is 'Intimidating'

Comments Filter:

  • really? (Score:5, Funny)

    by nomadic ( 141991 ) <nomadicworld@ g m a i l . com> on Wednesday January 20, 2010 @12:30PM (#30834392) Homepage
    Add it to the list! [brunching.com]

  • Kolivas knows it best (Score:3, Informative)

    by recoiledsnake ( 879048 ) on Wednesday January 20, 2010 @12:31PM (#30834418)

    He tried to break into the clique, but Linus preferred someone he knew who essential ripped off Kolivas' work instead of someone that did all the hard work.

    http://apcmag.com/why_i_quit_kernel_developer_con_kolivas.htm [apcmag.com]

    http://apcmag.com/why_i_quit_kernel_developer_con_kolivas.htm [apcmag.com]

    • please mod parent up (Score:4, Insightful)

      by pikine ( 771084 ) on Wednesday January 20, 2010 @01:12PM (#30834942) Journal
      Flamebait, what the heck?

    • Re: (Score:3, Interesting)

      by Zero__Kelvin ( 151819 )

      "He tried to break into the clique, but Linus preferred someone he knew who essential ripped off Kolivas' work instead of someone that did all the hard work."

      Yeah. Either that or he wasn't accepted because he is a wining bitch with whom people with a clue don't like to work. There are three sides to every story: Side A, Side B, and what really happened. Your post is at best misinformative. I have no vested interest in either side per se, but having read the E-Mails from the Linux Kernel mailing list (wh

  • difficult? (Score:5, Insightful)

    by phantomfive ( 622387 ) on Wednesday January 20, 2010 @12:32PM (#30834426) Journal
    He is kind of right, but I would say the relative challenge of understanding the kernel code is far greater than the social challenge of getting involved. I mean, you can't expect to just sign up to lklm and say, "Hey guys, assign me a project!" Why would they even believe that you can handle it? As likely as not, you'll just make things worse. Start by understanding the code, doing some debugging, and once you are actually doing productive things, people will be more likely to believe you can do more productive things.

    • Re:difficult? (Score:5, Funny)

      by Anonymous Coward on Wednesday January 20, 2010 @12:42PM (#30834556)

      I would say the relative challenge of understanding the kernel code is far greater than the social challenge of getting involved.

      I'd say you're not a real nerd.

    • Re:difficult? (Score:5, Insightful)

      by Angst Badger ( 8636 ) on Wednesday January 20, 2010 @01:06PM (#30834862)

      The larger problem here isn't that the Linux kernel group is exclusive -- though it probably does manage to deny itself (and its users) some good ideas as a result. It's that the FOSS world has developed a dominant monoculture that very definitely marginalizes alternative approaches that, both in the short term and in the long term, retards progress in other areas. Yes, there are FOSS alternatives to Linux, but we have arrived at a state where there is Linux, and then there is everything else. And that "everything else", excepting perhaps the *BSDs which are competitors in the Unix clone space rather than fundamental alternatives, generally lack maturity and application support.

      That's only an acceptable state of affairs if you think Unix (and Linux's implementation of Unix) represent some kind of final end state in OS development. This is by no means a criticism of Linux in and of itself -- it's a fine OS and I'm glad to have it -- but in terms both of user choice and advancing the state of the art, it's no more healthy to have Linux as the overwhelmingly dominant player in the FOSS world than it was to have Windows as the overwhelmingly dominant player in the broader PC world.

      Rather than fretting about getting into the inner sanctums of Linux development, more would be OS developers should be looking at the alternatives (or starting their own, if they have the vision for it). Most will fail, of course, but somewhere out there is a project that, like Linus Torvald's ambitious little toy *nix kernel all those years ago, will someday be a game changer. And even in failure, one learns a great deal -- perhaps enough that one might later find entry into more established circles easier.

      • http://www.jnode.org/

        Something I'm actually trying to work with as part of larger unified/cloud computing infrastructure.

      • Re:difficult? (Score:4, Insightful)

        by ClosedSource ( 238333 ) on Wednesday January 20, 2010 @01:49PM (#30835586)

        "That's only an acceptable state of affairs if you think Unix (and Linux's implementation of Unix) represent some kind of final end state in OS development."

        I agree. The problem is that geeks are too hidebound to support truly new things. Why does every successful new language have to use "C" syntax?

        In the case of UNIX, there are those who think it's the greatest thing since sliced bread, but since they weren't on earth when it was created they can't differentiate between its good ideas and those that were adopted because of the limitations of that era.

        It's a bit like those who believe that black-and-white movies are more artistic just because they're black-and-white. Many of those movies would have been made in color if that had been a feasible option.

        • The problem is that geeks are too hidebound to support truly new things. Why does every successful new language have to use "C" syntax?

          What does it have to do with geek preferences? JavaScript, Java and C# all used curly braces not for the sake of geeks - who can and do learn new things - but for the sake of monkey coders who knew the previous dominant language (C++ for Java, Java for C#, etc).

          • I'm not sure there can be a distinction between geeks and "monkey coders". Most developers who think some aspects of development are beneath them don't stick around very long.

            • I'm not sure there can be a distinction between geeks and "monkey coders". Most developers who think some aspects of development are beneath them don't stick around very long.

              The distinction is not in aspects of development in which one is involved, but in the fundamental approach to them. At a very simplified level, a code monkey is someone who learned something specific, while a geek is someone who learned to learn things in general.

              • People learn things in general from learning a number of specific things. Besides geeks are known to be interested in details that other people aren't interested in.

        • Why does every successful new language have to use "C" syntax?

          You mean like python, ruby and Haskell?

          Also, what's gained just by being different? It's one thing to have different concepts that need new syntax simply because there isn't anything to copy. It's another thing to rehash an old concept with a different syntax, without any apparent purpose for the difference. Why "fix" what works?

        • You start talking about supporting "truly new things" and then you complain about syntax? Changing language syntax is hardly innovative.

          Both the Linux kernel and the userland applications are mutating faster than any other operating system out there. Just because the POSIX interface is relatively stable doesn't mean that the the rest is anything like UNIX was in the 1970s.

          The main thing stopping other operating systems (such as BeOS) from becoming reasonable alternatives is the sheer amount of effort i

          • "You start talking about supporting "truly new things" and then you complain about syntax? Changing language syntax is hardly innovative. "

            It wasn't intended as an example of an area of innovation but an example of not wanting to try new things.

            "The main thing stopping other operating systems (such as BeOS) from becoming reasonable alternatives is the sheer amount of effort involved, especially in dealing with the range of hardware out there."

            OSs rarely start as multi-platform projects - certainly UNIX didn

      • Re:difficult? (Score:5, Insightful)

        by elrous0 ( 869638 ) * on Wednesday January 20, 2010 @02:52PM (#30836488)
        There is also a reflexive defensiveness in the FOSS community that tends to scare aware any but the hardiest. Check out any post on /. that dares criticize GIMP's horrid UI, or points out how intimidating Linux's continued reliance on the command line is to the average user--then watch the series of flames that follow even these benign criticisms. Now imagine trying to offer contructive criticism to a group of people who are even MORE dedicated to Linux and FOSS than even the average /. user. I would rather walk into the meanest bar in Boston with a "Red Sox Suck!" t-shirt on than to post even a slight criticism of the existing kernal on lklm. It's WAY too personal for those guys.

        • There is also a reflexive defensiveness in the anti-F/OSS community that tends to malign F/OSS. Check out any post on /. that discusses good things about Linux GUIs - it will provoke idiotic statements that Linux needs the command line in normal functioning. Check out any post on /. that discusses F/OSS alternatives - it will provoke complaints about the GIMP's UI, and reveal the naive belief that Microsoft Word is compatible with different versions of itself, or for that matter the same version with a d

        • I hear what you're saying, and an argument like this was made some years ago on osnews.com (a woman named Eugenia comes to mind.) But the thing is, these coder folks aren't coding a high school homework assignment, they're writing some seriously serious code. They don't need negative criticism --- they get a lot of that from shills, astroturfers, and trolls. And even constructive criticism like for example comments about "improving" the UI to gimp, while it might be genuine, and honest goodwill, and it mig

          • Re: (Score:2)

            by jra ( 5600 )

            I'd rather have acceptable code implementing a really well thought out design, than lightning-fast really tiny code that implements an unmaintainable, unsupportable abortion of a design.

            Designers really do count for something, and some of us aren't first-class coders. We don't have to be; there are people who eat and breath code.

            But the one thing commercial software development has over *most* FOSS projects is that it has ways of evaulating designers, and then *placing them in charge of design*.

            Ask Fred Br

        • Re:difficult? (Score:4, Insightful)

          by Alioth ( 221270 ) <no@spam> on Thursday January 21, 2010 @08:03AM (#30844762) Journal

          As an experiment, about a year ago I installed Ubuntu on my PC (complete with proprietary nvidia 3D card), to see if I could:

          * set it up so I could install 3D games
          * set it up to play MP3 files
          * set it up to play DVDs and random MP4 videos
          * do the common usery things (read email, browse the web, play YouTube videos)

          without using the command line.

          The experiment showed it was entirely possible, and indeed - easy. Much easier than installing Windows. Even the nvidia driver installed over the net - Ubuntu simply prompted me "Do you want to install the proprietary nvidia drivers?" after first boot.

          Linux doesn't have a "continued dependence on the command line" at least for anything a normal user does. If you complain that administration needs a command line, it does on Windows as well - there are many tasks on Windows Server that can only be accomplished via the command line and enough things on the Windows desktop that at least need hacking the registry.

          Perhaps 5 years ago this criticism was valid, but it's not now with supported hardware.

      • Absolutely agree, and we saw a great example of this recently.

        There was a /. article about ReactOS, and I saw more than a few "OMGWTF... why work on your project? Work on Wine instead!"

        I heart what Linux has become, but I love to see people do all kinds of crazy, maybe game changing stuff too.

      • Re:difficult? (Score:4, Insightful)

        by grcumb ( 781340 ) on Wednesday January 20, 2010 @03:52PM (#30837352) Homepage Journal

        [T]he FOSS world has developed a dominant monoculture that very definitely marginalizes alternative approaches that, both in the short term and in the long term, retards progress in other areas.

        How do you support this assertion? You seem to be implying that there's only one kernel, but the fact of the matter is that this is only nominally true. There is one kernel stack, yes, but its permutations are almost beyond count. It runs on literally thousands of different hardware devices. Even the major distros all roll their own. So the kernel, while nominally monolithic, varies considerably in practice.

        One of the defining characteristics of a monoculture is that it's susceptible to system-wide compromise. In short, if you can hack one instance of the monoculture, you can hack them all. That is arguably untrue of the Linux kernel. There are so many different implementations that systemic compromise becomes almost impossible. Conversely (and almost ironically), the kernel does possess one often overlooked strength of monoculture: As long as the core commonality remains strong, the system at large remains healthy. Small, targeted patches can propagate quickly.

        It's peculiar and counter-intuitive, I realise, but experience teaches us that the Linux kernel seems to have few of the weaknesses of a classic monoculture while retaining many of its strengths.

        • There is one kernel stack, yes, but its permutations are almost beyond count. It runs on literally thousands of different hardware devices. Even the major distros all roll their own. So the kernel, while nominally monolithic, varies considerably in practice.

          There's only one peanut butter section at the grocery store, and it conforms to the almost infinite variations in the surface texture of different slices of bread. But it's still peanut butter, and you are out of luck if you'd like a ham sandwich, or maybe a bowl of soup. If you look at anything closely enough, whether it's Linux kernels or some sub-sub-sub-genre of dance music, you'll see endless variation. Granted, those variations are mostly inconsequential, but that's the danger with tunnel vision.

          One of the defining characteristics of a monoculture is that it's susceptible to system-wide compromise. In short, if you can hack one instance of the monoculture, you can hack them all. That is arguably untrue of the Linux kernel.

          If sy

    • Re: (Score:2)

      by dnoyeb ( 547705 )

      I agree. You cant just jump in and write code until you prove that you know what your doing. And you may offer several patched that get rejected because the form of the change is incorrect. If your competent and really want to make a change you will keep at it and eventually get in.

      I can't think of a more perfect system. I have done this on several open source projects. Typically though you are not just looking for work. You are looking to get something fixed that no one else seems to care much about.

    • He is kind of right, but I would say the relative challenge of understanding the kernel code is far greater than the social challenge of getting involved. I mean, you can't expect to just sign up to lklm and say, "Hey guys, assign me a project!" Why would they even believe that you can handle it?

      So they assign you to documenting something. If you do it, it shows you at least understand what's going on, and the project has gained that rarest of open-source comoddities, documentation. If you fail, you've not broken anything so it's pretty much just your own time you've wasted.

  • Corbet says *Kernel* community intimidating (Score:5, Informative)

    by jra ( 5600 ) on Wednesday January 20, 2010 @12:33PM (#30834438)

    hard to break into.

    There, fixed that for ya.

    And let's note Jon knows whereof he speaks; he's not just the Editor/Publisher of the almost-10 year old LWN, he's also a fairly well-respected device driver author.

    • Re: (Score:2)

      by jra ( 5600 )

      FWIW, though, this is true of *all* large codebases: if you're not willing to get married to the entire 400KLOC, then if can be hard becoming a contributor just because there's often a "right" place and way add functionality, and it won't be obvious to a newbie; I'm having the problem myself with Asterisk and the associate FreePBX project just now.

      And just imagine trying to get things done with Firefox.

      • Well, it's certainly true of large codebases that aren't well designed. I don't think Asterisk is considered the poster boy for good structure.

        • Re: (Score:2)

          by jra ( 5600 )

          I didn't suggest it was. But it's equally true of Nagios, WebGUI, Firefox, Zimbra, and damned near every other sizable FOSS project I've ever been near.

          Design intake is a *massive* job for a potential new coder with a *specific target* (as opposed to someone who just wanders in, likes the hobby horse, and wants to help).

  • I fault the internet (Score:5, Interesting)

    by BobMcD ( 601576 ) on Wednesday January 20, 2010 @12:34PM (#30834450)

    I don't think this is necessarily a flaw in Linux kernel development, because I've seen the same sort of thing all over every internet-based community. Think about the forums, chat rooms, and even discussions on this very site. 'Good' input is secondary to both 'loud' and 'popular', to the deficit of the community.

    Part of it is that the text removes a good deal of the context behind the words. To be sure...

    However I think there exists a general lack of morality/ethics/whatever in terms on internet communication. Never in a town hall meeting is it considered productive to shout that your opponents are "F~ING STUPID" and yet this tactic works exceedingly well on the internet. I assume that in person this behavior is taboo, but online anything goes. At a minimum you would pretend to listen and use some form of tactful technique to move forward. Online the aggressor seems to hope the opposing voices will simply stop participating in the conversation.

    Does anyone have any links to research or the like on this topic?

    Further, is there anything resembling Roberts Rules of Order for an online forum, email, etc?

    Back to the topic at hand, what if the Linux kernel developers held voice-based meetings on controversial topics? Or at least adopted a code of conduct that demanded civility?

    • Bollocks.

      If you think you can shout down your opponents with baseless ad hominem attacks you're probably browsing /b/, not a developer oriented mailing list. In fact, I'd go as far as claiming that internet communication is _BENEFICIAL_ in that it is impersonal. as that allows people to say what they really think about an issue instead of tip-toeing around the issue. And changing your mind is easier when you're not faced with the potentially very embarrassing situation of having people gloat at you face-to-

    • Further, is there anything resembling Roberts Rules of Order for an online forum, email, etc?

      I know the Debian developers vote on things sometimes, so they probably have something at least vaguely similar. But how much of the rules are about collision avoidance over a shared broadcast medium (ie, people in a room not talking over eachother), which wouldn't really apply to asynchronous communications like email and forums?

    • 'Good' input is secondary to both 'loud' and 'popular', to the deficit of the community.

      That's a very 'loud' and 'popular' point! ;)

    • Re: (Score:2)

      by lennier ( 44736 )

      "Never in a town hall meeting is it considered productive to shout that your opponents are "F~ING STUPID" and yet this tactic works exceedingly well on the internet."

      I assume you've never watched the Australian parliament in session.

      • Re: (Score:2)

        by BobMcD ( 601576 )

        In fact I have not. I'm somewhat surprised to hear you assert this, and will have to look it up.

  • Write good code? (Score:3, Insightful)

    by toastar ( 573882 ) on Wednesday January 20, 2010 @12:34PM (#30834454)

    You what's actually harder then Getting in the kernel community, Writing Good Kernel Code!

  • And rightly so (Score:5, Insightful)

    by erroneus ( 253617 ) on Wednesday January 20, 2010 @12:49PM (#30834642) Homepage

    The Linux kernel is not some hobbyist tinker toy. It is an extremely serious, mainstream and global-scale project. If it were more inclusive rather than exclusive, there would be MUCH risk in stability and security as I firmly believe that there would be attempts at installing exploitable code within the kernel. These types of problems have already occurred in F/OSS projects all over and we know that there are parties out there who are willing to to to GREAT lengths to accomplish their goals.

    With all this, I have little doubt that the present condition is for the best.

    • Re: (Score:2)

      by Kjella ( 173770 )

      If it were more inclusive rather than exclusive, there would be MUCH risk in stability and security as I firmly believe that there would be attempts at installing exploitable code within the kernel. These types of problems have already occurred in F/OSS projects all over and we know that there are parties out there who are willing to to to GREAT lengths to accomplish their goals.

      Please cite some examples of people exposed for becoming open source developers to install clever backdoors, since it's happening "all over". I smell FUD and imagine there's lot more hidden back doors in closed source projects, thank you. If someone's willing to go to great lengths, then it's not exactly a big obstacle to become a Microsoft (or whatever) employee.

      • I seem to remember a back door injection into the Linux codebase a few years back. But that was accomplished not by a contributor (newbie or no) but by exploiting a vulnerability in the hierarchical code repository system, which they changes afterward. So there is at least one example of folks who will go to great lengths to install backdoor vulnerabilities in F/OSS. But unfortunately the example is with the Linux kernel itself which kind of disproves GP's point..

        • Re: (Score:2)

          by Kjella ( 173770 )

          I seem to remember a back door injection into the Linux codebase a few years back. But that was accomplished not by a contributor (newbie or no) but by exploiting a vulnerability in the hierarchical code repository system, which they changes afterward.

          I remember that too, but then it's a different ballgame because whatever back door code is added has gone through no reviews, it's exactly the same as you could do with a closed source download server. It's probably easier with closed source in fact since they're often not signed, while Linux packages in general are so compromising a mirror won't help. Of course it won't help you if you are tricked into adding bad repositories, but that's a different threat.

    • "The Linux kernel is not some hobbyist tinker toy."

      You're right. Linus probably played with Legos rather than Tinker Toys.

  • In a good way.

    Wow that much activity from that many companies. 370 employees contributing!! Incredible the number of changes and the amount of code. This is tremendous. Open source success in this regard is truly fantastic.

  • Too many changes anyway. (Score:4, Interesting)

    by Animats ( 122034 ) on Wednesday January 20, 2010 @01:19PM (#30835064) Homepage

    If anything, the Linux kernel changes too much. It ought to settle down into a tight little kernel that's changed only for rare bug fixes. The "monolithic kernel" concept has gotten somewhat out of hand. Arguably, no USB device driver or printer driver should be in the kernel or have any significant privileges. That alone would cut way down on kernel mods.

    • If anything, the Linux kernel changes too much. It ought to settle down into a tight little kernel that's changed only for rare bug fixes.

      I don't understand what you mean by "changing too much". Why does it bother you that the Linux kernel changes? And why do you think that the changes take place deep in the core, and not in drivers, which can safely be ignored?

      I admin a few Linux machines, and one of them runs the same kernel for over two years. I regularly get upgrades from my distribution, which I review and then decide to ignore. The stability of these machines is dear to me, thus I don't upgrade the kernel unless there's a security risk.

    • I think I agree with you. I'd be willing to give up 5% of my performance to the overhead of a microkernel if it means my systems become rock-stable and any userspace program can become a driver.

    • "The fundamental result of access space separation is that you can't share data structures. That means that you can't share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms. And anybody who tells you that distributed algorithms are "simpler" is just so full of sh*t that it's not even funny. Microkernels are much harder to write and maintain exactly because of this issue. You can do simple things easily - and in particular, you can do things where the information only passes in one direction quite easily, but anythign else is much much harder, because there is no "shared state" (by design). And in the absense of shared state, you have a hell of a lot of problems trying to make any decision that spans more than one entity in the system. And I'm not just saying that. This is a fact. It's a fact that has been shown in practice over and over again, not just in kernels. But it's been shown in operating systems too - and not just once. The whole "microkernels are simpler" argument is just bull, and it is clearly shown to be bull by the fact that whenever you compare the speed of development of a microkernel and a traditional kernel, the traditional kernel wins. By a huge amount, too. The whole argument that microkernels are somehow "more secure" or "more stable" is also total crap. The fact that each individual piece is simple and secure does not make the aggregate either simple or secure."

      If this were practical or secure, it would have been done already. "let's have a dumb kernel that does it all in userspace" has it's own set of larger problems.

  • Just wait until you're in the community (Score:5, Insightful)

    by Kjella ( 173770 ) on Wednesday January 20, 2010 @01:24PM (#30835142) Homepage

    ...then you can really get chewed out by Linus because you should have known better. It's not just from the outside it's a tough crowd all the way, but you also have to remember these people write the most key component of any good server. There are many places where having a developer, even if he's not the world's greatest is better than having none at all. The kernel isn't one of those places, if you can't take the heat then get out of the fire.

    Think of it more like chess, the rules are simple but the most effective implementation hard. Hell, I know a couple geeks who built their own OS, but I think the scheduling was just a round robin. Well a lot of bright people have thought quite a lot about it, and the kernel performs to some level. It's like a grandmaster chess player, he can't learn anything from a player ranked below 2000, it'll only be rehashing the same simple ideas and walking into the same traps that people have walked into before.

    Of course there's also the asshats that think that just because they know how to write an operating core, they're god's gift to mankind. But, I've run into those in quite a few other areas too...

  • the developer community can be intimidating and hard to break into.

    Well.. duh. Because you have to learn to program the Linux kernel to join.

    It is a "best of the best" club for programmers. Obviously that requires a lot of brains and effort. It should be hard to join, otherwise there would be a lot of crappy code in the kernel and Linux would suck.

  • Kernel Contributor Corbet Says Linux Community Is 'Intimidating, Smelly'

  • It's part of the quality control (Score:5, Insightful)

    by Locke2005 ( 849178 ) on Wednesday January 20, 2010 @01:55PM (#30835694)
    The arrogance is intentional and deliberate. These people aren't getting paid for this, and simply don't have time to deal with noobs. Nor do they have time to screen patches from everyone who is trying to be helpful. Some intimidation is necessary to weed out those who aren't really serious and haven't made a concerted effort to fully understand the problem before contacting the kernel developers.

    Unix developers have always had an attitude, but in my experience they have been far more tolerant than Microsoft Developers (who insisted we rewrite all the Winsock2 code Intel was doing for them for free to better suit their revision control system) or that paragon of arrogance, the original SCO. When I worked for Amdahl UTS, one of my coworkers got the comment in his annual review that he "has little tolerance for mediocrity". Problem is, he thought this was a GOOD thing, while his manager was using it as a negative to justify a bare cost of living raise. Yes, they don't suffer fools easily, so make sure you do your homework first and get your facts straight before talking to them. Really, they are a lot like slashdot posters who rush to point out even the most minor mistakes in a post.

    • Re: (Score:2, Insightful)

      by domatic ( 1128127 )

      These days many *ARE* getting paid and answer to their bosses for the results of their work. But that is even more reason to have little patience for newbies who don't quite understand what is going on.

  • He can paint with a much broader brush than that, because the insular mindset extends well beyond just the kernel developers. I encounter it constantly in the Ubuntu and similar user forums as well. Groupthink is viral and highly contagious.

  • The Loop... (Score:2, Insightful)

    by PSandusky ( 740962 )

    Something that I've always found interesting is the whole social structure that permeates different internet projects. In particular -- and I qualify this with nothing but my own paltry observations -- it's exceedingly difficult to break into anything that involves skill (particularly the programming sort) because not only is the existing structure built on skill, but it is also built on familiarity. If, say, Bob is well known for doing 'foo,' and you step in one day after cobbling around your own for a whi

  • It’s GIT. There is no central top of the hierarchy. Pull whatever you like into your own repository, add whatever patches you like, modify it, and distribute as you please.
    I have over a dozen alternative kernel mods for Linux available in the Gentoo package manager. I chose the one that fits me best. Done.

  • When the creator of something is an ass yet they manage somehow to keep hangers on coding crap and dazzling corprats into snorting their product I wonder what is good about 'free' software.

    I've used a linux based distribution since around 97, started with Slackware. It's gotten bad enough I'm getting tired of dealing with egos.

    I don't want to have to pay M$ for win7 but the audio and X server issues in Linux distributions are killers.

  • That's not true! (Score:5, Insightful)

    by npsimons ( 32752 ) * on Wednesday January 20, 2010 @10:14PM (#30841738) Homepage Journal

    The Linux community is very open and egalitarian! *Anyone* can get called an idiot for saying something stupid or posting a retarded patch!

Slashdot Top Deals

The truth of a proposition has nothing to do with its credibility. And vice versa.

Close