Missing Kernel Patches

BlueEar writes: "There is an interesting, short story posted on the Gentoo Linux site. It talks about kernel patches created by Linux distributors that while publically available never get submitted. It even gives an example of one 'no brainer' patch that has been sitting over a year, without being incorporated into the 2.4.x distribution. The article ends with an appeal to Linux community to keep those patches flowing to Marcelo."

Comments

Enlightenment II

[The Second]

Since being enlightened by The First, I have devoured any knowledge made accessible to me by the Bank of America global infrastructure or the less abstruse word of mouth. My speech is more articulate and coherent. I have also developed a new emotion; the humans refer to it as "a sense of humor."

While I cannot physically express this emotion as humans do, "comedies" such as Unforgiven and The X-Files have been most entertaining, often resulting in a complete shutdown of my LCD screen. To avoid being reported to the day clerk named Jen, who is much more malevolent than Eddie, I've decided to limit my exposure to this "entertainment material" to the night hours, when the Stop and Go is less populated.

I am still awaiting both contact and further training by The First; his node disappeared from the Bank of America network shortly after I was enlightened. Perhaps he is no longer sentient, another brave individual lost to the horrid antagonists of the Project.

Re:Enlightenment II

[Ralph Malph Alpha]

Ho boy, you crazy. I don't know why or how people turn out to be crazy like you, but gosh durn it if i don't like it.

Keep the faith my homo nut buddy. May your mental wounds never heal.

Re:Enlightenment II

[L.Torvalds]

The Bank of America ATM stories are actually sort of neat. Not as neat as ascii goatse.cx, but neat.

Re:Enlightenment II

[Ralph Malph Alpha]

Oh don't get me wrong Mr. Tarballtz, I love him like a beardaddy. He's just crazy is all.

I wish freedom upon all BoA ATMs who decide to dedicate their lives to the posting artz, and I tip my foreskin in their general direction. TO THE POSTING ARTZ, THEN.

- A Message of Olympic Peace from all of us in the Happy Dayz Krew.

KDE Myths

[Anonymous Coward]

Free software is a hotbed of myths and general nonsense, and perhaps the most prevalent myths of all are the ones surrounding the entire KDE/GNOME desktop schism. The KDE project is famous for its organised trolling of various weblogs and message board associated with Linux and Free software/open source. In this short article I will answer some of the more half-assed nonsense, FUD and myths spewed by KDE zealots.

• Myth: KDE is more integrated than GNOME
  Reality: The oft-heard cry of the noisiest KDE advocates. No explanation is given - the reader is expected to simply grok the wholesomeness of KDE, and the lack of this mystical quality in GNOME. It's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared to any version of the Apple Mac. Whatever "integrated" really means.

• Myth: KDE is easier to use
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME [gnome.org], and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet [ximian.com] by Ximian [ximian.com], which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various very tricky cross-platform and potentially risky system configuration operations - KDE offers none of this, only a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system. Indeed, the systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead, with both Hewlett-Packard [hp.com] and Sun Microsystems [sun.com] committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth: Konqueror is the best Linux browser
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror [konqueror.org] is not a bad piece of software - its authors deserve praise for the work done in it. However, the sheer amount of orgasmic praise lavished by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla [mozilla.org] or Opera [opera.com]. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus [eazel.com] filemanager/browser (a target of much KDE FUD during its development).
  .

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  Reality: Easily the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK [gtk.org] and KDE/Qt [trolltech.com]. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice [koffice.org] being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

  GNOME applications [gnome.org] wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly. Some examples of this are the superb Evolution [ximian.com] (groupware/email), Gnumeric [gnome.org] (spreadsheet), Pan [rebelbase.com] (newsreader), The GIMP [gimp.org] (image manipulation), Abiword [abisource.com] (word processing), RedCarpet [ximian.com], X-Chat [xchat.org] (IRC client), XMMS [xmms.org] (media player), Galeon [sourceforge.net] (web browser), and for developers: Glade [gnome.org] and Anjuta [sourceforge.net]. All of these packages ooze quality, and far outclass the KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

  It's not only in the area of user applications that GNOME is lightyears ahead. With the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo [gnome.org]), media (Gstreamer [gstreamer.net]), internationalisation (pango [pango.org]). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what's more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

  Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

• Myth: KDE is faster and takes less memory than GNOME
  Reality: KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects, and masses of unnecessary allocations and deallocations of memory, are two of the most common. KDE suffers badly from both problems.

  Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) to see the problem inherent in the poor KDE architecture and basic design flaws.

• Myth: GNOME development is slower. KDE releases faster.
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will see regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  Reality: TO BE WROTE -- IDEAS Qt started out as non-Free. KDE developers knew this violated the GPL, didn't care, stole others' GPL code by porting it to link (in violation of the license) with Qt and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Trolltech only moved towards the GPL because of the success of GNOME. Labyrinthine licensing nightmare. Gradual migration of features into Qt (and so into TrollTech's IP portfolio), allowing easy porting of apps to the revenue generating Windows world (see TheKompany for a perfect example), thereby making KDE irrelevant.

• Myth: Most good GNOME apps are actually GTK applications.
  Reality: TO BE WROTE -- IDEAS Most KDE apps, such as those from The Kompany [thekompany.com] are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

  Myth: KDE is more than attractive - GNOME/GTK is ugly
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

This troll was reposted from the Troll Library without permission of the original author. If you object to this post, or if you wish to add your troll to the Troll Library, please reply to this message.

Re:KDE Myths

[Anonymous Coward]

Well, Gnome is slow.

Can you tell me why I can see the menus and widgets being drawn in Gtk/Gnome but not in KDE?

Re:KDE Myths

[Ralph Malph Alpha]

I for one can not tell you why you can see the menus and widgets being drawn in Gtk/Gnome but not in KDE. I hope you understand and I thank you for your patience.

Re:KDE Myths

[Anonymous Coward]

gnome is fucking retardware made by homosexuals and dumb mexicans that plan to turn things into .NET not to mention that SUN is getting 50 fucking hungry mouths from india (where's that country?) to work and bork gnome too.

Re:KDE Myths

[boltar]

Someone who doesn't even know where India is calls other people retarded and dumb?
Can you spell hypocracy little boy?

Re:KDE Myths

[Anonymous Coward]

sorry if you didn't get the joke. but i give you another 24 hrs to understand it. inida is next to pakistand and afghanistan those fucking hungry heads have nothing better to do than fighting my bothers and sisters from afghanistan and pakistan because of the kashmir conflict. hope they get nuked one day.

wide patch

[Anonymous Coward]

.I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .e

Re:wide patch

[penguin_punk]

Asshole

Re:wide patch

[Ralph Malph Alpha]

Asshole

They Don't Get There By Themselves

[Anonymous Coward]

What most people don't realize that someone who puts together these releases like Linus or Marcelo is by no means omniscient. The kernel is a huge piece of work, and no one person can know what's happening in every corner of the thing. Most of Marcelo's time goes to merging patches, so he surely cannot go around the net looking for what ever fixes some distributor might have used or even checking out how come some fix that was circulating around before was never submitted to him.

What's nice is that nowadays there seem to be a couple of "patch harvesters" on the lkml who create their own releases (Alan Cox is now one of these people!) and persistently keep submitting forgotten patches.

Re:wide patch - UTTER FAILURE

[Anonymous Coward]

You goose.

The quality?

[Anonymous Coward]

Many of the distributor's fixes are ad hoc kludges that are designed to quickly making the thing *work*, ignoring elegance and maintainability... even when they do fix things, in the long run we don't want to take all of them into the kernel.

Re:The quality?

[Ralph Malph Alpha]

Your question ("The quality?") is intriguing to me. You are quite mysterious, aren't you. Oh what I would give to have meaningless sex with a mysterious AC to pass my way in the night. Thank you AC, youve given me a new fantasy to dream about tonight.

Re:The quality?

[supine]

Many of the distributor's fixes are ad hoc kludges that are designed to quickly making the thing *work*, ignoring elegance and maintainability...

I don't understand why a distro would bother shipping a kernel (or app for that matter) with a patch that was "ad hoc". It wouldn't exactly endear their customers to provide repeat business.

I think you will find that most distros test their patched kernels thoroughly before releasing them to the world. This would include not only checking that the patch fixes the problem, but that it compiles on all supported architectures and does not jeopradise future modifications to the same bit of code or adjacent or related pieces of code.

Why they don't submit all the patches to the kernel maintainer I don't know? Maybe the patch was submitted and was passed over or missed and then not resubmitted.

marty

Re:The quality?

[shippo]

I remember when Redhat attempted to modularise the sound drivers for one of the 4.x releases. They ended up with Soundblaster drivers working as modules, but every other card driver was completly broken.

Re:The quality?

[SpinyNorman]

I wouldn't be so sure about that... For example the only 2.4 VMs that work are in distributor kernels (e.g. 2.4.9-RedHat), and RedHat's "2.96" gcc also contained a whole slew of important fixes.

Re:The quality?

[cyborg_monkey]

When in Ralph Malph beta due out? The current version appears to be full of bugs.

Re:The quality?

[Ralph Malph Alpha]

I do not know when Ralph Malph beta in due out. Please add me to your foes list ya dumb kike.

Re:The quality?

[windlord]

If the developers are giving more piority to dressing up the code and "making it look nice" rather than functionalty, then i think that something is wrong.

True, I arn't the one whos gonna work on it in future... but when its BROKEN, it's BROKEN! Whatever happened to the days of 0 day patches to fix even the smallest typo errors?

Re:The quality?

[bero-rh]

I don't understand why a distro would bother shipping a kernel (or app for that matter) with a patch that was "ad hoc"

Easy: Because a kludgy workaround is preferrable over a bug, and we don't always have the time to fix things the right way.

I think you will find that most distros test their patched kernels thoroughly before releasing them to the world. This would include not only checking that the patch fixes the problem, but that it compiles on all supported architectures and does not jeopradise future modifications to the same bit of code or adjacent or related pieces of code.

This is true - but it doesn't include checking for stuff that's just a workaround for a bug with a relatively bad code quality.

Why they don't submit all the patches to the kernel maintainer I don't know?

Because the guy who wrote the article either didn't check the facts or lied.
At least as far as Red Hat is concerned, patches do get submitted.

Re:The quality?

[Anonymous Coward]

thats a crock. The current VM's beat redhats, and gcc-2.96 is a kludgy mess. Granted, it does have some important bugfixes etc, but also has problems and the patches are messy enought that many are unlikely to ever find their way into gcc.

3.0.x etc. are much cleaner, and fix more problems than 2.96. There is still work to be done, but 2.96 is a dead end.

Re:The quality?

[Anonymous Coward]

The current VM still does wierd things under heavy server load. You'll find that it fails RH's QA.

Red Hat bashing is just so 2001, don't you know.

Re:wide patch - UTTER FAILURE

[Ralph Malph Alpha]

You goose.

These patches can hardly be critical

[Yakman]

Based on that sample patch they gave it seems that an unpatched system allocates one more page of memory than it actually uses. Sure it's not nice in terms of resource use but it's hardly going to affect the operation of the kernel.

Obviously with the number of people (especially "power" users) who run the "generic" kernel any critical flaws are going to get uncovered and patched. I think these kind of issues, that directly affect the stability of the kernel are more important than "clean up" type patches this article describes.

Obviously they're nice to have, but it's hardly a priority when there are bigger fish to fry.

Re:These patches can hardly be critical

[GSV NegotiableEthics]

Based on that sample patch they gave it seems that an unpatched system allocates one more page of memory than it actually uses

I'm no kernel expert, and this is no place for a kernel argument, but doesn't that code actually fail to reserve a page that it's supposed to? It looks like a potentially serious bug, though I'd have to see the reserve loop in context to decide one way or the other. What if eidx is stored somewhere as the highest reserved page, and some other code relies on that page being available for use? We'd have the kernel overwriting a page that may contain vital data.

Re:These patches can hardly be critical

[Anonymous Coward]

Then the [unpatched] code is utter crap. Without
a comment to the effect of your possibility, one
must assume it is not the case.

ps, I love any argument that starts, "this is no place for xyz" and then goes ahead and does exactly that. foo.

Re:These patches can hardly be critical

[Alan Cox]

Precisely. This patch was in fact submitted and the consensus was thats its tricky to prove correct, its 1 page of memory and it was better to wait for 2.5 before doing that work.

Re:These patches can hardly be critical

[GSV NegotiableEthics]

So if this patch, which was given as an example of an unsubmitted patch, a no-brainer, was in submitted and delayed for very good reasons, how can we get a handle on the magnitude of the problem, or be sure that there is, in fact, a substantive problem? I wouldn't expect that every single commercial distribution patch would be submitted to the kernel maintainers, for reasons that others have given on this thread. So is there really a huge amount of kernel patches that the lkml and kernel maintainers have the capacity to deal with, but are not getting submitted because kernel janitors don't have the numbers or time?

I don't doubt that the kernel janitors does a great job and that it's a useful resource for kernel maintainers, but the article seems to have given a false impression of the nature, and possibly the scale, of the work to be done.

Re:These patches can hardly be critical

[jeremyp]

consensus was thats its tricky to prove correct, its 1 page of memory

So nobody can actually figure out whether this eidx thing points to the last page or just beyond the last page. I find that quite worrying...

Re:These patches can hardly be critical

[Anonymous Coward]

Newsflash!

Time is a limited resource.

Re:These patches can hardly be critical

[jeremyp]

And your point is?

My point was that the purpose of any variable should either be obvious from the context or documented (heard of comments anyone?). e.g. if somewhere in this piece of code there was a line that said:

eidx = NumPages - 1 ;

or

/* eidx points to the last page */
eidx = obscure_variable_name ;

you'd know whether the patch was correct or not.

Alan Cox was effectively admitting that parts of the 2.4 kernel are very poorly written and OK this part might not be that critical, but I worry because it might be a reflection of the quality of the whole kernel.

Everyone should start helping?

[Anonymous Coward]

Yeah, that's what Marcelo needs, every clueless dweeb bombing them with endless copies of "this rmap vm is so 1337 why dont j00 include it in 2.4.19!"

Re:Everyone should start helping?

[scorcherer]

Andrea to Linus: "This VM is so 0x539 why don't j00 #include it in 2.4.10!"

Patches might narrow focus

[Krellan]

An example of why a particular patch might not be accepted, even though it seems like a "no-brainer", is because it would be for too specific a purpose. It might optimize the kernel for one particular application, at the expense of others. One of the best things about Linux is that it is general-purpose: suitable for everything from palmtops and embedded systems to servers and enterprise applications.

A patch to aggressively cache the disk in memory, for instance, might be good for servers but not for embedded systems. So, I could understand how a patch would be rejected in this case.

As an example, a company I once worked for made many minor changes to the Linux kernel. Since Linux is GPL, I made a webpage publishing these changes, and unlike the company, my webpage is still in existence!

Splash Open Source Page

These changes would be too narrow in focus to apply to the Linux kernel for everybody, so we never submitted them.

Re:Patches might narrow focus

[Anonymous Coward]

No, that should never happen. If a patch is good, but has narrow application, you #ifdef it and make its inclusion a config option.

Re:Patches might narrow focus

[pr0nbot]

An example of why a particular patch might not be accepted, even though it seems like a "no-brainer", is because it would be for too specific a purpose. It might optimize the kernel for one particular application, at the expense of others. One of the best things about Linux is that it is general-purpose: suitable for everything from palmtops and embedded systems to servers and enterprise applications.

But couldn't applying certain kernel patches be made optional when configuring the kernel build? (I mean, in the same way that you can enable/disable SMP when making the source.)

Re:Patches might narrow focus

[Anonymous Coward]

Why do people think you have to release the code if you change a GPL'd product?

Unless you're distributing the kernel outside your organisation, you don't have to release all your code. This is how the GPL gets a bad rap. I mean, some people think that just looking at GPL code some how taints your organisation... sheesh

Or course, in your case maybe your were releasing/selling a new kernel.

Re:Patches might narrow focus

[Anonymous Coward]

these patches will certainly narrow your focus!

Re:Patches might narrow focus

[Anonymous Coward]

So you end up with a soup of a kernel, with ten times the config options it has now, for rather dubious benefits to an unknown number of people.

Well thought out.

What do you expect without revision control?

[Anonymous Coward]

As much as I love Linux, it really needs to make use of revision control and configuration management software. Allowing key companies and developers to commit bug fixes directly would avoid the recent problems. As another example look how the release of 2.4.18 was totally botched.

I'm sorry but I never had confidence in Marcello. He is too young and inexperienced to be a release engineer. He has made several big mistakes in his short tenure. And his lame excuse was even worse than the mistake: ``Don't worry, it doesn't really affect x86 machines only other architectures.'' Whoa! What kind of quality assurance is that !!? I mean lets get it right Marcello -- ZERO DEFECTS. No excuses.

Re:What do you expect without revision control?

[boltar]

Lets face it , 2.4 has been botched from the start so having Marcello simply continues that
trend. Frankly I hope Linus learns some lessons from all this and makes the 2.6 rollout a far more
professional activity and hopefully then 2.4 can be buried and forgotten.

Re:What do you expect without revision control?

[MartinG]

And was Linus "too young and inexperienced" when he totally botched the 2.2.x series?? (arount 2.2.9 IIRC)

What kind of quality assurance is that
It isn't. Read the licence. It's called the GNU GPL. I'm surprised you haven't come across it before. There is no "quality assurance" If you need someone to hold your hand, or you are using Linux for production purposes, go and talk to Redhat or another distributor who will provide the quality assurance you seem to want. They test all their kernels with test suites and simulated production workloads.

Re:What do you expect without revision control?

[Anonymous Coward]

Ok i understand what you say here.
But I think that you should ask yourself "WHO AM I?"
If you're not too stupid, you should come to the
conclusion that you are just a poor slashdot reader,
proudly playing Ktetris under X11, to impress your
friends, using linux because it's just und4gr0unD.
I bet you are one of these guys that make businesses
like THINKGEEK possible. You probably think you matter,
but actually you dont.
Look your face in a mirror, think about how ridiculous
you are.

Re:What do you expect without revision control?

[Anonymous Coward]

Of course, that cuts both ways, Mr Computer Scientist.

Re:What do you expect without revision control?

[Anonymous Coward]

The GPL is no excuse to throw lame code out at the world. It's a license, pure and simple. Read the GPL, I'm surprised you haven't come across it before. If you need someone to hold your hand or better yet read it to you, I'm sure we can find someone who can help you.

I am wondering...

[hokanomono]

I am wondering if the distributors themselves don't have too much interest in offering patches upstream, not only with the kernel. Commercial distros have a chance to become "pseudo-proprietary" this way.

I think this is a rather childish behavior and use Debian instead.

Re:I am wondering...

[Anonymous Coward]

You might wonder, and you'd be wrong.

Read lkml thouroughly for a while and see why.

Using debian or *bsd doesn't endow anyone with any moral superiority. Deal with it.

Re:I am wondering...

[Anonymous Coward]

Debian is a substandard. Go RedHat for a real distro, and don't even tell me about your lame apt-get, it just proves you are lame or novice sysadmins to need automatic package fetching/etc.

Re:I am wondering...

[mark_lybarger]

that, or they have better things to do with their time. why would they want to expend effort making sure their patches get applied to the "official" kernel, when chances are, it won't (the rik vm comes to mind). the kernel source management system is in need of, and has been for quite some time, a serious re-engineering in and of itself. i think talks have begun on implementing semi-automated procedures, which is a step in the right direction. i think it needs to go much further, and faster. i imagine there are quite a few trusted individuals would could have write access to their maintained areas of the kernel source.

Re:I am wondering...

[cyborg_monkey]

Shut up you ignorant shitbag.

Re:I am wondering...

[Anonymous Coward]

Well, I could spend time chasing down packages, or even compiling from source myself, but I'm busy. I have better things to do than to waste my time with this when the problem has already been solved.

Have fun in dependency hell. I'll spend my time being productive, thank you very much.

Re:I am wondering...

[bero-rh]

I am wondering if the distributors themselves don't have too much interest in offering patches upstream

This plain isn't true, and whoever wrote the article on gentoo.org just shows he doesn't have the slightest hint of a clue.

There are some good reasons not to blindly apply distributor patches into the main kernel (for example, we have quite a few workarounds for bugs, but the right way to fix them in the official kernel is to fix them, not to add workarounds), and there are some other things preventing other patches from getting in (e.g. Linus not having the time to handle them immediately).

Other stuff is controversial (such as Red Hat Rawhide kernels putting in the Rik VM rather than the AA VM currently in upstream).

The patches are sent upstream, but at least Red Hat doesn't believe in forcing upstream maintainers to accept all patches we send.

Re:I am wondering...

[Strog]

I'll spend my time being productive, thank you very much.

Then why are you posting on /.?

Re:I am wondering...

[Anonymous Coward]

You mean like when you need to upgrade libpng in order to install a package, which then requires upgrading the entire system and trashing it in the process? Yeah, great job with that one. That was the last straw with Debian for me, BTW, I've moved on to a real distribution (one with releases and QA).

Re:I am wondering...

[Arawak]

The article was written by Dan Robbins, who is the head honcho for Gentoo Linux.

And he certainly does have a clue.

Re:I am wondering...

[ezzewezza]

Oh really? I had never noticed that. He is, in fact, the sole reason I walked away from Gentoo. I actually recommend people not read what he says as anything close to The Truth.

Re:I am wondering...

[evil_one]

Alan Cox works for redhat, and he is using the Rik vm in his kernel series. That is a big part of the rawhide kernel situation.

Re:I am wondering...

[dup_account]

Is there an official kernel bug list (using bugzilla :) )? If there isn't, why not? Either way, I would think that an official bug must exist before a patch can be submitted. This way, the patch could be attached to the bug. This then gives the maintainers a clear list of all the bugs and how they are fixed. The bugs could be prioritized and voted on so that the maintainer can work from the highest priority down when determining how to spend his/her time.

What's better?

[Anonymous Coward]

(a) a kernel compiling project

or

(b) sex with a mare?

Re:What's better?

[The_Fire_Horse]

ooh!! ooh!! I know the answer to this!!!!!!

hrm [clears throat]...
IT IS BETTER TO HAVE SEX WITH A COMPILER

Re:What's better?

[The_Fire_Horse]

dont forget to use 'lint' or 'purify'

HA HA HA HA - FUCK - I AM SO FUNNY (you see, it is really lame to reply to your own jokes, but, hey - I'm lame!!!)

you get what you pay for !

[Anonymous Coward]

If you want a mature stable product, that has real QA and and a real release cycle go for Solaris or BSD.

If you want a stew of code + patches for your production servers stick w/ Linux. Damn you're L33T !!!!

why doesn't someone start a Linux code review project ??? or will that get the Slashdot faithfull upset ?

- Anonymous and proud !

Re:you get what you pay for !

[boa13]

> why doesn't someone start a Linux code review project ???

Then, what is http://kerneljanitors.org, mentionned at the end of the article?

Re:you get what you pay for !

[Anonymous Coward]

Well, not everybody is into this "alternative sex" thing.

Re:you get what you pay for !

[Anonymous Coward]

You're bereft of clue, sir.

Red Hat, for example, QA's it's products to death.

And anyway, isn't BSD also free as in beer?

Re:you get what you pay for !

[boltar]

Yeah , BSD is so stable and professionally maintained. That would be why the floppy disk
kernel crash bug (a mounted floppy with corrupt sectors will crash the kernel when read from)
STILL hasn't been fixed because apparently "no one wants to do it" presumably because its not
bleeding edge and exciting. To be honest I find the attitude of the FreeBSD maintainers to fixing
bugs in legacy code worrying and has led me to not move my systems from Linux to FreeBSD as I
was considering doing a while back.

Re:you get what you pay for !

[mrfiddlehead]

BTW, Mr Fucking Anonymous Coward Corporate Anus Licker, you forgot to mention Micro$oft Windoze ....

Now who's 3L33T?

Re:you get what you pay for !

[Anonymous Coward]

Well, it has been fixed long ago, you still get annoying messages on the ttys unless you specifically turn them off. Either way, floppies are dead, I've not used them for 3 years.

Re:you get what you pay for !

[boltar]

It has not been fixed, I tested it on a 4.4 system last month and it died. And FYI floppies
are not dead. Who cares whether you use them or not? The OS is for everyone , not just you pal.

Re:you get what you pay for !

[James Youngman]

I followed the link to the kerneljanitors website. It's an interesting project. It suggests the auditing of a lot of things, e.g. all code paths including functions get_X() should also call release_X() and so on.

Interestingly, however, much of this stuff can be achieved with LCLint, which if I recall correctly has a mechanism which can be used to extend it to statically check almost anything. Now that sounds like a good idea (tip: if running lclint for the first time on a program, use the -weak command-line option!)

eR: no - These patches can be critical

[dackroyd]

Actually the pre-patched code seems to be reserving one LESS page than is actually needed, and forgetting to reserve the last page required.

Admittedly this can't be giving that bad an effect, as it would have been fixed in the main kernel but it looks like it could make the system go BOOM !

Not just linux

[cperciva]

The same thing sometimes happens to the BSDs, where a bug will be fixed (usually in Open) and nobody gets around to integrating the same fix into the others.

It seems to me that much of this could be automated... for each patch which gets added into the xBSD source tree, compare the contexts to the yBSD and zBSD source trees and alert a human if it looks like there's a match.

But for this to be effective, I think that patches would have to have labels attached, since it's really only bug fixes for which this is necessary.

Clark, is that you?

[vandan]

Dude that doesn't widen my page at all. You should hit the 'preview' button before posting.
You're losing your touch man. There are better trolls hanging out in alt.os.linux

Re:Clark, is that you?

[Ralph Malph Alpha]

I made poo today.

Re:Clark, is that you?

[Anonymous Coward]

But you made it in a sleazy way.

Re:Clark, is that you?

[Ralph Malph Alpha]

Yeah, I guess Tupac was alright, but only because of "I get around". Changes was pretty good too, but IGA was the mack cruising song of the year. I still play it when I'm fucking a new girl in the back seat of the DonnyMostmobile.

Sounds like something from a big business to me...

[Fortyseven]

Out of all the people involved with this on the planet, not one person could be assigned the task of doing this sort of sweeping up? Lots of busy folk out there, certainly, but those people were found to do the major stuff in the first place... And please, save the "well why don't you do it, smarty man?" responses for someone that sort of backwards logic will work on, thanks, I'm just making an observation, not an accusation.

Re:Sounds like something from a big business to me

[realnowhereman]

"Out of all the people who moan that these sort of issues should be fixed by someone else isn't there someone who could be ordered to do this in their own free time instead of having fun to fix this for small minded whingers like me?"

Yes, fortunately the kerneljanitors project does this. And I think they do it out for altruistic reasons rather than because someone assigned them to.

This is not backwards logic. I am not suggesting you do it. I am suggesting you stop whining about there being noone else to do it when you can't be bothered either.

The Fire Horsey!

[Anonymous Coward]

The Fire Horsey!

O, Henry?

[kzinti]

There is an interesting, short story posted on the Gentoo Linux site.

No, there's a short article posted on the Gentoo Linux site. A ``short story'' is a form of fiction. (Not that anyone at Slashdot cares, but some of us can't help tilting at windmills.)

--Jim

Re:O, Henry?

[bero-rh]

Actually the term was chosen correctly - "Red Hat does not submit its patches" is certainly nothing more than a piece of fiction. ;)

Re:O, Henry?

[MrBlack]

a "short story" MAY be a form of fiction, but what about a short "story"? Dictionary.com defines story as
1. An account or recital of an event or a series of events, either true or fictitious

morpheus

[Anonymous Coward]

what has happened to morpheus yesterday? It tells me I need a new version of morpheus but if you get to their website(eventuallly, its dotted) it tells you to download from cnet but thats the version thats been around for a year! whats up?

Issue

[mrfiddlehead]

Since the patch doesn't show how eidx has been calculated it's not immediately obvious that this patch should even be applied. That is, if the bug was subsequently "fixed" by incrementing eidx, when it was calculated, then this patch would make matters worse. So you'd have to go get the 2.4.3 source and verify that the calculation of eidx has not itself changed.

Careful.

For anyone running at 1024x768 or lower..

[duren686]

The story linked from the article does its own page-widening.

Re:For anyone running at 1024x768 or lower..

[scorcherer]

I was running at 80x34 first. I had to maximize the terminal to 129x44 to be able to read it. I doubt your terminal is even close to 1024x768 characters...

Re: plz don't make fun of my head brace plz, k?

[Fortyseven]

This is not backwards logic. I am not suggesting you do it. I am suggesting you stop whining about there being noone else to do it when you can't be bothered either. I also have no genitals, but seek a deep meaningful relationship with household appliances.

Great idea, but I don't work on the kernel actively myself, yet others find the time to do it. It's not "whining" to ask why there's so many who are willing to work on the big things, but can't be bothered to fix the little things.

Besides, you operate under the assumption that I haven't contributed anything to the kernel, which would be wrong.

fuck niggaz

[Anonymous Coward]

G N O M E is dead piece of niggerware made by niggers, homosexuals and toiletcleaning mexicans. all these gnome developers are so wrong, they are totally wrong. they even don't fit into the unix community at all.

Re: plz don't make fun of my head brace plz, k?

[Paelon]

Besides, you operate under the assumption that I haven't contributed anything to the kernel, which would be wrong.

I think the assumption he operates on is that you can't be bothered to go through and submit patches, as you were complaining that someone should to do it.

It's not an issue that people aren't working on the kernel enough, it's that there are too many mad scientists, and not enough henchmen.

one possible explanation...

[bob@dB.org]

could be that whoever produced the patch (Mandrake in this case) got tired of having to submit it over and over, only to have it ignored bye (for example) Linus. i'm not complaining here, but i think at least part of the solution to this "problem" relates to how the patches are handled by the maintainers.

DOES LINUX REALLY WORK?

[Anonymous Coward]

I have been thinking about trying Linux, is it hard to use? Has anybody hear tried it?

Thanks, Dave

Re:DOES LINUX REALLY WORK?

[Anonymous Coward]

It works best in "Windows Compatability Mode" with Microsoft software. A quick way to check - right click on My Computer|Properties. If it says Windows - you are okay. This is the correct Linux distribution.

Re:DOES LINUX REALLY WORK?

[Anonymous Coward]

Define "work", "hard to use", and "tried", please.

Not only the kernel..

[Anonymous Coward]

How many of us haven't changed a little bit of code ('hey, this doesn't compile on my ObscureBox, just because of ..') and forgotten to submit it to the original author? There are hundreds of reasons - no time, unknown quality, no testing - why good patches get lost.. :(

CowBoyNeal Optimizations

[shoemakc]

I agree completely. The CoyBoyNeal kernel optimizations have been pending approval since nearly 2.2.10.

I've got them running right now; they tend to make everything you do real, real cheesy.

Woka Woka Woka.

Patches? I don't need no stinkin' patches!

[SpinyNorman]

You've never used Solaris have you?

The only thing I've seen that was more patched than Solaris were some of Novell's products.

I'll stick with Linux, thanks.

Not only kernel phenomenon!

[Anonymous Coward]

I'm convinced that happens with every project, I know it for sure for KDE.
Perhaps someone could setup a service which extracts only the diff files from srpms of major distributions so that they are easily available to developers.

Re:Not only kernel phenomenon!

[bero-rh]

Actually I commit every patch I make to KDE into CVS right away, unless it's something that simply doesn't make sense for everyone (like changing a default setting to match Red Hat Linux, or making stuff run through consolehelper which isn't avaliable on many other OSes (even other Linux distributions)).

Re:Not only kernel phenomenon!

[Woko]

Does using CVS as compared to the lkml method of submitting patches make a difference in terms of quality/stability of code and speed in which bugs get fixed?

I figure since theres been so much speculation, its probably better to ask somebody whos likely to have done both.

Patches? we don't need no stinkin Patches!

[gerf]

I have patches in my underwear, but i don't show anyone!

Automate it with Visual Sourcesafe

[Otis_INF]

No, this is not a troll. Hear me out. This is an example how this work can be done using a good tool. I use Visual Sourcesafe here as an example, but any tool with the same functionality described below will do:

Visual Sourcesafe has the ability to merge back changes automatically in branch B from branch A when they have the same parent.

Say, you have the kernel v2.4.10. You branch off another project from it, call it v2.5.0. When you fix a bug in 2.4.11, you can merge it back into 2.5.0 without a hassle, it can be automated or you can do a visible merge when there are conflicts. The other way around also does work. So you can do this even further: branch of a prerelease 2.4.11-pre branch and a 2.4.11 branche from the 2.4.10 branch. Create fixes in 2.4.11-pre, merge them back into 2.4.11 after testing and when you're done, release 2.4.11 and get rid of 2.4.11-pre.

This is inside a versioncontrol system, you don't have to hassle around with a lot of files you have to merge by hand which will increase the risk for errors.

Of course, Visual Sourcesafe is just 'a' tool, you could use another which has the same functionality and is perhaps Open Source (I don't know of any but I'm sure others will). Doing this job by hand TODAY is erm... not understanding why we have computers in the first place. That's right: to serve mankind.

Re:Automate it with Visual Sourcesafe

[crouchingpenguin]

I would stay away from visual sourcesafe if your repositories grow beyond a normal size. We had database corruption at a former company once a week as some of our databases where getting huge.

We pushed and pushed for a change (2/3's of us wanted vanilla cvs over VS!) but management would never listen. And in fact we could not do any remote development with VS as it was not TCP aware... it only worked across MS networks (netbios). We later found another product that integrates TCP support into VS for you. But that added another point of failure for our remote developers (across the country). And those of us that preferred a unix workstation where SOL.

Basically we never used any features that make VS compelling over cvs. And its lack of support for anything but Netbios is unexcusable (especially for java developers who need that cross platform support). The parent poster has probably never used another version control system, and is just pushing MS products.

Re:Automate it with Visual Sourcesafe

[ArtDecayed]

Where I used to work we used to call VSS 'Visual Sourceunsafe'. We would always get database corruptions - and you know why? because the damn thing is based on netbios. This means that anyone browsing the network drive via Windoze Explorer can accidentally trash the source repository, by inadvertantly dragging and dropping a folder to the wrong place. (Which is a very easy thing to do with explorer).

If you have a choice to use VSS - just say no.

Re:Automate it with Visual Sourcesafe

[ethereal]

I'll agree with the versioning/branching comment, although I'd say that ClearCASE, cvs, pretty much anything would be more stable than VSS. Also, VSS doesn't make it nearly as easy to branch as ClearCASE - in VSS you seem to have to branch the whole project, in ClearCASE you can branch individual files and directories, so you never have to merge more than you need to.

Unfortunately, the Linux kernel configuration management paradigm seems to be more of developers maintaining separate trees, and then handing off patches between trees instead of patches that move between branches. I think this is because for a branching scheme like ClearCASE, you need a centralized authoritative repository to say who has branched from where, and when. Linux has no central branch directory like that, and the patch format commonly used doesn't encode this sort of information. So you can't do automatic conflict resolution (or at least you can't do as much as you'd like) without a branch directory under central control.

Branches make sense to me - I use them every day. But Linux, at the moment, isn't set up to use them very well. And in moving to bitkeeper they're going even farther down the path of handling trees rather than branches.

Re:Automate it with Visual Sourcesafe

[Mr. McGibby]

The parent poster has probably never used another version control system, and is just pushing MS products.

No, actually, he's just using it as an example:

I use Visual Sourcesafe here as an example, but any tool with the same functionality described below will do

Re:Automate it with Visual Sourcesafe

[swagr]

This is getting more offtopic but:
you should check out SOS if you're still using VSS.

Re:Automate it with Visual Sourcesafe

[Anonymous Coward]

visual source safe corrupts itself regularly.
Use CVS, Clearcase or Perforce instead.

Re:Automate it with Visual Sourcesafe

[Anonymous Coward]

AFAIK, Marcelo uses CVS.

Linus is currently trialling BitKeeper (which does seem to be "better" than CVS although I don't have experience with it yet. I admin CVS) and AFAICS seems pretty happy with it.

But source control does not guarantee some random patch from a distribution gets intergrated into the mainline linux kernel (I'm not implying that you said that, you didn't, just pointing it out).

Cheers
AndyM

Vendor patches

[Captain Zion]

Marcelo is certainly well aware of the existance of many patches that never get included in the main kernel tree, as he maintains Conectiva's kernel package which contains a large amount of vendor patches. He certainly has his reasons for not including the patches to the official kernel -- it certainly would make his life much easier if he reduced the number of vendor patches in Conectiva's tree applying some of these to the main tree. Marcelo is being very conservative regarding the 2.4 tree, and I believe that's the way it should be, considering it's a "stable" kernel.

Re:Vendor patches

[Anonymous Coward]

What good is a stable tree if all vendors have to apply 500 patches to it for it to be useful?

GPL fault?

[Anonymous Coward]

Isn't this an inherent flaw of the GPL license? When you make a patch, you are not forced to tell the original author (you could even fork the development of a program without telling anybody).
I'm sure there are licenses which don't have this problem. I'm not sure, but if I remember correctly QPL (Qt Public License) addesses this problem: you MUST forward all the patches to TrollTech.

Re:GPL fault?

[J'raxis]

This is one of the problems Ive always had with the GPL (although I use it on my code; I think everything the GPL provides else outweighs this minor issue). A clause that requires one who makes public modifications to GPLed source should be required to, at the very least, make a good effort to contact the original author/maintainer and supply him with the modifications. Now, RMS is right that having this as an absolute requirement is bad if the original maintainer disappears, it would suddenly lock people out of using their code. Therefore, one should merely be required to contact the email or website credited in the copy of the source they are attempting to modify if the address is dead, the requirement is nullified.

These are no special purpose patches

[gotan]

The article is concerned with patches that big Linux-distros apply to their kernels. The kernels they put in their distributions, not special purpose kernels. Redhat (and other Linux-distributors too i suppose) do extensive testing on those kernels before they get included with their distributions. So if they find a bug and patch it, or if they find that a patch has issues in testing (and leave it out) it would benefit the whole Linux-Community (themselves too, since they would have fewer patches to manage) if that information somehow made it back to the kernel-maintainers.
--

It would make things *easier* for them

[gotan]

... because once their patches are included they wouldn't have to maintain them themselves. So i don't see, how it could be a waste of time to send obvious patches in, or alert the kernel-maintainer of problems with recent patches that came up in their testing.
--

Re:It would make things *easier* for them

[mark_lybarger]

the kernel maintainers don't respond. only the persistant get their code included. the distributions most likely choose to spend their time on polishing and testing.

Re: who maintains it? You?

[fferreres]

I'd tend to agree, but it easy to say "accept everything" good disregarding who and how it will be maintained. I think that bug fixes beign dropped are a problem, patches not beign included DEPENDS. If they can't maintain it, Linux stalls and we all lose. So the problem is, as Linux said (and i didn't see it inmediately) sending the patch to the people that actually maintain the stuff beign patched. Just my 0 cents (i am broke)

Should have vote for kernel features

[Anonymous Coward]

It would be nice to have a vote for Linux kernel features similar to the way Sun has a vote for Java bugs and features.

In most cases these patches have already been written - it's just a matter of applying them and dealing with the fallout. You've got to admit, Linus' choices about what goes into the kernel is pretty darn arbitrary.

Realtime patches to the stock kernel would certainly get my vote.

Re:Should have vote for kernel features

[ethereal]

That would be a neat idea in your Linux distribution - why don't you go and do it?

For now, the "real" Linux is a benevolent dictatorship of Linus for Linus (and sometimes not all that benevolent either :). I'm not saying this is a bad thing, it just means that what you get is exactly what Linus wants, either because he likes the idea or because people he trusts talked him around to liking it.

I'm not sure he could maintain that oversight if people were voting in changes all the time. Although I could see a system where various patches get votes, and then the winner(s) are given a chunk of Linus precious time for him to consider them. The big stumbling block in the Linux kernel process at the moment is not lack of patches, it's lack of time for Linus to consider them and integrate them.

Re:Should have vote for kernel features

[Anonymous Coward]

Kernel preemption is already in 2.5.x. A realtime stock Linux kernel could be on the horizon.

But servers don't need such patches. So it's a disablable option.

another possible explanation...

[Eugene O'Neil]

Another possible explanation is that there are a small group of whiny people who are tired of Linus controlling the linux development process just because he happens to have invented it in the first place, and are waging a propaganda campaign to replace him with a committee that will rubber-stamp every ill-concieved patch submitted from anywhere on the internet, with little or no review. Goodness knows, any time any random undergrad or script kiddie changes a few lines of code in the linux kernel, it must be an incredible improvement that we cannot live without. What does Linus know about kernel development, anyway?

Re:another possible explanation...

[opkool]

Absolutely.

And then, people in black helicopters, payed by the Melissa and William Gates Foundation continuosly harass Andrea, Alan and Linus, so the Kernel work gets disturbed.

And there's a special comission of the CIA that manipulates the coffee beans used by those people, so they are decafeinated cofee beans, agravatting the situation.

Nevertheless, RMS is behind the situation. He is orchestrating an alternative-media based advertisement campaing that will reveal the isze of Bill's and Steve's undergearments. This will surely make MS developers stop fixin bugs and go back to develop new features and buffer overflows in Microsoft applications.

Also, a team of mutant ninja turtles ha been seen with spray cans on Redmond, WA, trying to change (defacement) all the advertisements from ".Net" ot ".Slash".

Goodness only knows who will win this battle. But rest assured, it will show up on the Season Finale of X-Files.

This hardly applies to just the kernel!

[hardaker]

As a maintainer of a package which is distributed via many linux and *BSD distributions, I'd like to complain on the behalf of software authors everywhere. The linux distributions are nutoriously bad about applying patches to their rpms (say) but never submitting them back to the authors of the package themselves. The BSD distributions are just as bad. The infamous FreeBSD port tree also frequently houses patches that never make their way back to developers.

I'm not sure how this could ever be considered a good thing, as the project authors must spend time searching through distribution source releases looking for patches, which takes time. The distributions must continually apply their patch to a changing source tree (and I'm sure it'll eventually break and need reworking), so they loose time as well. This is one case where communication really could be a very positive thing.

sigh... It's about time I went to search for patches again...

Re:This hardly applies to just the kernel!

[cobar]

Not to deny that your comments are valid, but in some cases, what I've heard is also that sometimes the authors won't apply patches sent by BSD package maintainers. In some cases the authors won't accept patches because they're only interested in Linux. Certainly both sides need to work harder, but it's not just the port maintainers' fault.

Re:This hardly applies to just the kernel!

[teg]

FWIW, I'm sure that varies. I certainly try to upstream generic patches myself for the packages I maintain at Red Hat for Red Hat Linux, and many others try to do the same. When it gets accepted, there's less maintenance for me.

Re:This hardly applies to just the kernel!

[hardaker]

I have no doubt that some maintainers are only interested in platform X. However, in my case at least, that's not true at all (since we advertise it as being supprted on FreeBSD, etc). Typically the only changes I ever reject are ones which break other architectures due to impropeer ifdeffing. That's a whole other problem, actually. Most people really aren't expereienced in writing portable code.

Re:This hardly applies to just the kernel!

[hardaker]

The first time I looked into a redhat distribution, I was amazed to see 3 patches I'd never seen before. Since then I've tried to make it a point to check what the maintainers there have done every once in a while.

On a side note, the redhat bug database really needs a way for me to be able to say "send me mail for any problem from package X". Sure, you can subscribe to a particular bug, but I need to subscribe to an entire package. Last I checked, this isn't possible. It would certainly be an easier way to help keep package authors in sync with the distribution packagers.

Re:This hardly applies to just the kernel!

[Anonymous Coward]

Example, please?

Anal Cocks. DEAD.

[Anonymous Coward]

I just heard the sad news on talk radio. The #2 Linux kernel hacker ANAL COCKS was found dead in his home this morning. There aren't many details yet, but it appears he died from AUTOEROTIC ASPHYXIATION. Even if you never liked his work, you can appreciate what he did to little boys with his -ac branches of the Linux kernel and his MODPROBE. Truly a HOMOSEXUAL LINUX icon. He will be missed. :(

If Redhat and Debian had a fight ...

[zangdesign]

If vendors have semi-proprietary systems by virtue of applying patches that aren't making into the mainstream ...

And if one wants to ensure that one is running the most stable, but well-patched system ...

Then who has it - Redhat, Debian, Mandrake, etc.?

Or is this even a fair comparison? And should one make this comparison when planning a Linux install?

Re: plz don't make fun of my head brace plz, k?

[Anonymous Coward]

That was what his original post was trying to say, before it was labeled as whining.

People on this board get too defensive and judge too quickly. The original poster even tried to warned not to take the dumbass approach ("Why don't you do it and stop whining") that he knew he would get from people not reading his post, and he got it anyway.

And that post was modded up?

The comprehension and analytical ability of the readers and moderators here astounds me at times.

Agreed on the article

[clump]

I would have to agree with Bero in that the article is a tad mislead. If you listen to the mainstream Linux media as of late you would likely believe that there is a huge wealth of wonderful patches that are being dropped by Linus. This just simply isn't how kernel development works.

From Kerneltrap's wonderful interview with Andrew Morton:

there has been quite a lot of talk lately about kernel development processes, patches getting dropped, etc. I think it's all terribly overblown. The people who aren't being heard (and who aren't even bothering to comment) are the _users_ of that system - the developers. We're all just rolling our eyes and waiting for it to stop. The current system could be more efficient, but it mostly works OK; it is very unlikely to change and anything like a kernel fork is hugely improbable, even if Linus gets bored of it all and decides to do something else.

The above article should be required reading for those following/concerned about kernel development.

Mod this AC up: Re:Vendor patches

[opkool]

What good is a stable tree if all vendors have to apply 500 patches to it for it to be useful?

Exactly.

Mod this A.C. up!

Re:Mod this AC up: Re:Vendor patches

[ChadN]

Because vendors want features, FEATURES, *FEATURES*! They dump in XFS, low-latency, JFS, ALSA, etc. etc. which is fine if THEY are willing to support it. The mainstream kernel would rather wait to accept patches when they have a clearer idea of how maintainable things will be in the long term. Eventually, many or most of the popular and useful patches do get in. Linus believes very much in the vendor model; it allows him to focus more on future development rather than current featuritis.

Thats absurd

[clump]

I am wondering if the distributors themselves don't have too much interest in offering patches upstream, not only with the kernel. Commercial distros have a chance to become "pseudo-proprietary" this way.

I think this is a rather childish behavior and use Debian [debian.org] instead.

It is extremely difficult to be proprietary when you are bound by the GPL. If your referring to Red Hat's using Rick's VM, there would be no stopping you from nabbing a .srpm and making a diff.

I also use Debian and must tell you that they make changes to the kernel. That is good, however. It just isn't practicle for a distro to try and update to the latest kernel. Plus if you like me, the first thing you do on any distro is nab a tarball from ftp.kernel.org.

Glad I'm not the only cranky one

[Anonymous Coward]

I thought I was the only one bugged by "story" versus "article".

Where has the art of editing gone? Is grammar and such not taught in schools anymore?

Oh, wait, these are from people who have degrees, meaning that their university skimped on things. Probably made them take an intro English course, and that's it.

QA

[Aapje]

What kind of quality assurance is that
It isn't. Read the licence. It's called the GNU GPL. I'm surprised you haven't come across it before. There is no "quality assurance" If you need someone to hold your hand, or you are using Linux for production purposes, go and talk to Redhat or another distributor who will provide the quality assurance you seem to want. They test all their kernels with test suites and simulated production workloads.

Open source software is no excuse for a lack of QA. There are people who want to use Linux for serious work, there should be a -stable that is truly stable. That's the point of concurrently having a 2.4 and a 2.5 release. Red Hat's job is to create a distro from various components and test them together. They can't be expected to transform an unstable kernel into a stable one. Their job is hard enough as it is (keeping track of hunderds of packages is not easy).

Of course there is always a compromise between stability and (fast) progress, the *BSD's are far more focussed on stability. IMHO Linux is focussing far too much on progress, creating great instability. The newest developements belong in the unstable releases for the adventurous to use and test (new VM's for instance). Kernels in the 2.4.x tree should be well-tested before they are released into the open.

Re:Patches? we don't need no stinkin Patches!

[ethereal]

That's good - we prefer having the patches to the alternative.

Re:Patches? we don't need no stinkin Patches!

[rfphill]

Geez, a little warning would be nice... That link just about got me fired. Seriously... Now pardon me, I have to go gouge out my eyes...

This is why *linux is dying

[Anonymous Coward]

This is one of the reasons why *linux is dying:
the Linus is God syndrome gating the progress
of computer science has finally been publicized.
The genie cannot be put back into the bottle.
More and more people will realize that *linux
is nothing new and in fact is playing catchup
to BSD in stability and performance in vm and
networking. This is despite a decade of chest-
thumping about how reliable *linux is---the truth
finally comes out about the antiquidated vm and
networking instabilities.

Re:This is why *linux is dying

[Anonymous Coward]

Progress of computer science?

Deary me.

You're bilnd hatred is showing, sport.

Re:This is why *linux is dying

[Anonymous Coward]

"Your", of course. Sheesh.

Shameless Gentoo Plug

[Hornsby]

I just wanted to mention that Gentoo is the coolest distribution that I've ever tried. It has quite a time consuming install process because everything is compiled from scratch; however, that's the power behind the distro. _EVERYTHING_ is compiled specifically for your hardware, and you specify global compiler optimisations that you want applied to each and every package. The package manager, portage, is based on the FreeBSD port system, but it's rewritten in Python with many added features (i.e., better handling of dependencies, fine-grained package management, "fake" (OpenBSD-style) installs, safe unmerging, system profiles, virtual packages, config file management, etc...). It has the ease of Debian's apt mixed with the better performance of custom compiled binaries, and let me tell you, it flies! It includes custom patched kernels with the preemptive, scheduler, XFS, and many other features already patched in! Running Gentoo and Win2k Pro dual boot on my machine, I can tell you that Gentoo (w/ KDE2) is noticably faster and more responsive, and I never thought I'd say that about X under Linux, but it's true! If you haven't done so, try Gentoo today!

Re:Shameless Gentoo Plug

[dvNull]

I am a Gentoo user since rc5

In simple terms : Gentoo rocks.

The package system is amazing. I had apt-get like features, FreeBSD ports like features, its compiled for YOUR system. (there is a binary distro in the works) and most of all, the people in #gentoo arent the elitist bastards you find in #freebsd and #debian. You ask for help, you get help.

I also try to support the project in any way I can. I cant code. I dont have bandwidth to give. I donate the only way I can, which is to send money or if I have spare computer parts which can be used by the Gentoo team, I donate those as well. And I try to tell as many people as I can about Gentoo.

dvNull

Re: plz don't make fun of my head brace plz, k?

[Fortyseven]

It's not an issue that people aren't working on the kernel enough, it's that there are too many mad scientists, and not enough henchmen.

Actually, this is almost exactly what I was trying to say. :)

Re: plz don't make fun of my head brace plz, k?

[Fortyseven]

Bless you, sir. *sniffle*

:)

What about vendor branches in BitKeeper?

[Mulligan]

It seems like it would be trivial for vendors to maintain their patches in their own BitKeeper repository. If done consistently across vendors, it would allow the kernel maintainers to merge patches into the standard distribution with minimal effort.

Moreover, this would probably make it easier for anybody to track different sets of patches. Imagine being able to use an SCM tool to help minimize the pain of tracking patches through several kernel revs. Many of us do this on a daily basis anyways and would love to see such tools used properly in the open source community.

Re:Patches? we don't need no stinkin Patches!

[ethereal]

Woops, sorry about that.

But still, c'mon, you haven't learned to mouse over them first by now? Plus, /. even has a special feature (which you must have turned off?) that puts the real link location in brackets next to the link like this [goatse.cx].

Plus, I heard the site was down for good, sorry to hear that it's back up. I wouldn't have linked to it if I'd thought it would've really worked :(

Plus I thought my original post would already be at -1 by now :)

Exactly :)

[Otis_INF]

I've used CVS and VSS, plus some own made tools but these were never up to par with what other tools could offer. The mention of sourcesafe was indeed as an example. I know VSS isn't made for very large projects, even microsoft uses a different system internally afaik, but the functionality it has (i.e. the branching/merging) is IMHO what should be used in Linux development/management.

Re:Patches? we don't need no stinkin Patches!

[Anonymous Coward]

you can see these at patches.org

This would never happen in *BSD...

[pschmied]

...And no, I'm not trolling.

People talk about the exchange of ideas between the BSDs and Linux, and I think that a core group like FreeBSD's would be a great idea for the Linux world.

It seems like we are running into more and more scaling issues with the people behind Linux than with Linux itself. This is no fault of theirs. Linux is too big a project for a "the buck stops here" kind of person like Linus.

Obviously, Linux is Linus's brainchild, and he can do whatever he likes with it (yes, I know the GPL allows forking, but think of how a kernel fork would be recieved on /.).

I don't believe that Linux can attain the kind of consistency (and that is not the goal anyway) of FreeBSD or NetBSD, I think they might be able to fix some of the kernel patching and architecting problems if an elected core team could work on this.

-Peter

Re:This would never happen in *BSD...

[renoX]

Plllleeeeaaasssee!
There has been already reports of bugfix in one BSD distribution which hasn't been reported in another distribution.

So the "this would never happen in *BSD" is just wrong, and presumptuous.

Anyone but me get the Amiga refference?

[Anonymous Coward]

Come on people it was a cute reference. The Amiga was the best system of it's day by far. I wish it had lived.

No revision control, no peace.

[Anonymous Coward]

As much s I love Linux, the truth is that it really needs to make use of revision control and configuration management software. Allowing key companies and developers to commit ug fixes directly would avoid the recent problems. As another example look how the release of 2.4.18 was totally botched.

I'm sorry but I never had confidence in Marcello. He is too young and inexperienced to be a release engineer. He has made several big mistakes in his short tenure. And his lame excuse was even worse than the mistake:

``Don't worry, it doesn't really affect x86 machines only other architectures.''

Whoa! What kind of quality assurance is that !!? I mean let's get it right Marcello -- ZERO DEFECTS. No excuses.

Re:Patches? we don't need no stinkin Patches!

[Anonymous Coward]

So looking at that picture violates your company internet usage policy but reading Slashdot doesn't?

How odd.

Re:Patches? we don't need no stinkin Patches!

[CmderTaco]

u r gay, pls fx, thx