And Unix is defined by being simple. Which Linux, it no longer is.
They should worry less about authenticating who contributes, and then finding the scapegoat to blame for the mess ups, but instead they should try to go back to core principles, and clear up the mess and establish a system where mess ups are impossible. It's not the individual programmers who are messing up, but the leadership at the top who fails to implement core principles, who have allowed themselves to stray far from them, under the pressure of features, and patching the patches that patch the patches that patched we don't even remember what anymore. The herd simply just follows the command of the shepherd through his dogs. You can't blame the ewe. You can't blame the dogs. If both the ewe and the dogs each follow command as they are supposed to. That's how a military works. Chain of command. Battle of Jutland is a good read on military and controlling chaos into musical and dance-like order. Jellicoe's formation of the ships, where they almost hit each other while assuming positions, "flying" by each other at only a few miles per hour. Battle about turn to starboard, by Scheer, a motion by complete mess-prone chaotic-prone beings executing it in unison, from prior practice. That is the way to beat down chaos, in middle of a messy battle, which by definition is chaos itself. Top down chain of command, following orders, everyone moving in unison.
The basic problem with Linux is complexity. I've stopped using Linux ever since kernel 2.6.26 or so, anything new that boots does just way way too much. It's obvious what a hopeless mess it is just from the boot up messages. Damn Small Linux is trying to get back to core principles, but it's hopeless with the present code size of the kernel. The basic principle of Unix is the KISS principle. Quoting from the Wikipedia page:
The principle most likely finds its origins in similar concepts, such as Occam's razor, Leonardo da Vinci's "Simplicity is the ultimate sophistication", Mies Van Der Rohe's "Less is more", or Antoine de Saint Exupéry's "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away". Colin Chapman, the founder of Lotus Cars, urged his designers to "Simplify, and add lightness". Rube Goldberg's machines, intentionally overly-complex solutions to simple tasks or problems, are humorous examples of "non-KISS" solutions.
An alternative view - "Make everything as simple as possible, but not simpler." - is attributed to Albert Einstein.
That is a warning that even the KISS principle should not be abused, though maximized as much as possible.
I did a google search on "core principles of unix," and I came up with this:
http://www.faqs.org/docs/artu/...
http://undeadly.org/cgi?action...
http://people.fas.harvard.edu/...
etc, etc.
In all of them the basic principle of Unix is simplicity, clarity, modularity, human readability, beating complexity down with a club anywhere you can, if you can find clever ways to get something accomplish, forget about it, it's too complex, do it cleanly, neatly, simply, and even brute force. Don't be clever, be stupid, and expect everyone to be stupid. In Unix, every program does one thing, and does it extremely well. If you need features, you write a different program. Then these programs come together and interact through extremely simple interfaces, and this soup of experts interacting simply to accomplish any needed complex task in the world is what you call Unix. The swiss army knife of software. Which also goes for C, as C and Unix are the same thing.
The first thing the Linux developers have to accomplish is to beat down the complexity mess they've created, to gut the whole thing to bare bones, throw away "clever" things, and substitute them with "dumbed" down things. Sound the tornado siren or air raid siren in the bazaar, where everyone runs to shelter, or picks up defensive positions. Practice emergency evasive maneuvers in unison, where everyone follows orders, and can be relied to follow orders by their sub-superiors. You have to organize yourselves like http://en.wikipedia.org/wiki/M... This requires lots of existing volunteers signing up for various functions, just like during WW2 the US military had an influx of volunteers that picked up specific roles. Responsibility trickles down from the top through the chain of command.
Once the war or campaign to fix up Linux, and gcc, and the like, is over, then you can disintegrate again, like the baby boomers in peace time, and everyone goes back to bazaar mode, coming up with random ideas they can toss into the common pile, but every time things get out of hand, and complexity, like a big boa constrictor, gets loose, and starts choking the whole system, you have to fight it off to get a breath of fresh air.
I'm not a programmer, but here are some ideas from someone who has no clue:
A milestone of progress would be a compiled Linux core kernel of 50 KB, running in Vesa mode graphics (nobody uses serial printers anymore). You may have to throw away gcc for this and hand code the whole thing in assembler, per architecture. But 50 KB is human readable amount of machine code. I know hardware has become complicated where you have to take care of its features and performance benefits. See what features you can ignore, and if you cannot, pressure the manufacturers to make them ignorable. Code size above all is the measure of complexity. Ability to hand trouble shoot simple machine code that's not clever, or even efficient, but extremely simple and plain English, is like gold.
Then organize the add-ons that tie into the minimalist core, based on levels of complexity. The level 0, 50 KB compiled kernel should boot on anything with a bios, level 1 should boot on most modern architectures, but without performance features, level two add performance features to video, disk and memory, level 3 network performance, level 4 encryption and security to all levels below it, level 5 everything else. You probably understand these things better. You could send the kernel into different run levels to easily find out what makes it crap out. And by this we don't mean System 5 runlevels of what processes to run, but the level of complexity the kernel is attempting to fight with. Every benefit comes with a complexity cost, and you should be able to pick and choose as you need. In fact performance might be better with less complexity, to where hardware manufacturers could design hardware to better fit and adapt to simple code, as opposed to you having to design software to manage the complexity needed to get extra performance out of that hardware. Security is only possible through utter simplicity, and even then you get all kinds of surprises. A very important thing is humor. Old school Unix was very simple, yet there was place for humor in it. It is difficult to not be clever, yet humorous, but in fact being utterly dumb, and humorous about it at the same time, glitters like gold in degree of cleverness. In essence, the dumber you can afford to get the smarter you have proven yourself to be.
A favorite game of mine is Go, Wei Chi, Baduk. It takes 5 minutes to learn the rules and the game, and 30 years to become a good go player. The guiding principles - cut where you can cut, connect where you can connect, enlarge eyespace reduce eyespace, the enemy's key point is your key point, do not use thickness to build territory, drive weak stones against your thickness to attack them, recognize bad shape and how to avoid it, force your opponent into bad shape, etc. By far the most important principle is the sente/gote pair, fighting for the sente, the initiative, and only sacrificing it when there is clear and tangible profit, and then doing everything to gain it back again, to dictate the moves around the board. In that, the most important thing is being able to ignore your opponent last move, and move somewhere else on the board, where the economics prove that it's worth more then faithfully and blindly replying to an attack. This quest for ability to ignore has distilled into the very being of players, and you recognize a strong player by his ability to ignore moves you yourself would not have ignored, because of the grave economic sacrifice that creates. This ability to ignore, and in that ignore necessary features to their maximum possible extent, and find them unnecessary instead, this utter terseness, could come in handy when designing the core of Unix, and the first parts of any new add on, before one can let loose and add the remaining desired features, but there has to be a core, a small stepping stone built on rock, a foundation, for any new features, as Unix philosophy dictates, that is extremely simple, robust, clean, dumb, terse, secure, transparent, and easy to build on, and easy to fall back on, into manual mode, when the automation part messes up.
The guiding principles of Go are simple, applying them in practice is the difficult part, and someone who's 7 dans runs circles around someone who is 5 kyu, there is a gaping abyss between them. This kind of skill rating system could be used in ranking coders in the kernel, in a amazon-like purchase review stars, by anyone who revises anyone else's code. I know that's a great source of flame wars, but direct criticism like that, and achieving a higher rank, such as 4 kyu from 5 kyu, or 3 dan from 1 dan, is a great incremental ego booster. And anyone who achieves level 7d on IGS, Tokyo, their games get "observed" by many other players, they can teach by example, and it's very clear from the rankings who the experts are, or how many handicaps should a new game get, from simple game results. There is no simple feedback mechanism to rate coders in Linux, or black belt achievement awards, so the ranking system from Go could be pirated. It is much simpler and plain English than a chess Arpad Elo score of 2473 or 2945 - that's too many numbers, unbeautiful in design compared to dan and kyu rankings. In go you start at 30kyu, which is -30, or BC (beginner category), and then you escalate through the ranks to 2kyu, then 1 kyu, and 1 dan means you have grasped some rudimentary basics of the art. The highest dan ever is 9d, for amateurs or professionals alike, but few players reach it. Nevertheless 6 dan amateur ~ 1 dan professional. A good go book to start with, for both 30 kyu experts, or 9 dan professionals to constantly remeditate and review, is Kageyama Toshiro, Lessons in the Fundamentals of Go. By the way he never reached 9 dan in his life, he maxed out at 7 dans, but could teach much better than 9 dan professionals, who can't really verbalize and express their intuition.
There was a recent post on Slashdot about how the Japanese still have telegrams as an option. STOP. When even the Brits, known for their robustness, have abandoned it. STOP. But the japs have abandoned Morse coding them in the 60's too, unfortunately. STOP. I mentioned how in Japan they understand the KISS principle, when you look at the furniture in a paper room: there is almost zero, there is a low lying coffee or tea table, and two floor pillows to sit on. That's what you call a functional room, and simplicity is the ultimate sophistication. There is almost nothing left to take away, and you can find beauty in that. I have to add, that personally, I could not live like that, I need some complexity in my living environment to feel good, as in baroque or rococo lush exuberance of features, but I used that to highlight what Unix is about, if it is Unix that you're trying to create. And it comes down to personal preferences, as you look at pussy(or labia minora), and some pussy is complicated rococo, and some pussy is straightforward and simple Unix. When it comes to pussy, both kinds are beautiful, but when it comes to software, only the simple one, only Unix is beautiful. You can get the features out of Unix by add ons, and combinations of known things, variations on the same topic, and thus you can pile on the complexity, similar to how life follows a simple design of A C T G, and then varies that topic to create butterflies, flowers, you and me, your cat, an elephant or a bird, grass, tree, bacteria, fish. That's how Unix, a swiss army knife software, is supposed to function, extremely simple design at the core, but anything desirable can be easily accomplished with it.
Ok, that above paragraphs may not have been very useful, coming from a person with zero experience of programming. But let me quote some things from the page links I posted above;
This is the Unix philosophy: Write things that do only one thing and do it extremely well. Write programs to work together. Write things to handle text streams, because that is a universal interface.
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. (I'm adding that this is Einstein's principle, and you must follow it, as in give me 19 parameters and I can fit an elephant with an algebraic curve, give me 20 and I can fit the tail accurately too if necessary (it may not be necessary), but I cannot fit an elephant with only 2 parameters, no matter how badly I wish to do so.)
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for “one true way”.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.
If you're new to Unix, these principles are worth some meditation. Software-engineering texts recommend most of them; but most other operating systems lack the right tools and traditions to turn them into practice, so most programmers can't apply them with any consistency. They come to accept blunt tools, bad designs, overwork, and bloated code as normal — and then wonder what Unix fans are so annoyed about.
By the way, in Go, the proverbs, the guiding principles are extremely simple, but putting them effectively into practice is a superhuman feat even for the cleverest of cleverest players. And the rule to every rule is that there is no rule, and every proverb has an exception, and when you can find those exceptions to be the correct things to do given the circumstances, you're perverting and subverting a principle, which is highest beauty in itself. For instance, pros know how to avoid bad shape, and how to force the opponent into bad shape, but sometimes the world champion will intentionally seek out a horrible looking bad shape group, whose beauty only shines after long meditation of the possibilities, and showing that they are all fake, and the bad shape is untouchable. Thus, the guiding principle of "avoid bad shape" has been perverted, or subdued, and is a source of BDSM-like sexual gratification, so to speak. But only when done by the 9 dan pros, not the clumsy 30 kyu or 15 kyu beginners, who haven't even grasped a concept of good shape, what it looks like. There has to be a similar concept in coding, as an expert can only glimpse at a position, and rate it for shape in under a second, on appearance, and know instantly the rank of the players, within 2 kyu accuracy. There has got to be a similar thing with code, one quick glimpse from the experts, and every programmer could get an initial ranking that gets fine tuned as things go along.
Linux needs to be gutted, in a seasonal cleanup fest, and all the garbage that wants to be clever thrown away and rewritten in dumb ways.