Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Silent Kernel Platform War?

Cliff posted more than 13 years ago | from the quietly-taking-the-other-road dept.

Linux 242

iJosh asks: "Recently I decided to be hip and cool and update to the latest Linux Kernel (v2.4.1). Since this decision I've downloaded and tried to compile the offical source from Linus and crew on my PowerMac 7300 only to run into errors for the PowerMac PCI controller. I took this up with Paul Mackerras maintainer of the PPC kernel and his response was quite interesting to say the least and it got me thinking. He basically says that Linus is ignoring the patches from the people working on the PPC side of the kernel, and that they are keeping their own tree so people are not stranded out in the dust with kernels that will not work. My question really comes down to this: Is the linux kernel forking away from PowerPPC? Is this happening because of issues regarding OS X and the possibility of many users jumping ship, away from LinuxPPC upon release? Or is this some kind of quiet platform war from the major kernel developers?"

cancel ×

242 comments

Sorry! There are no comments related to the filter you selected.

Re:Is it really possible to avoid a fork? (1)

The Finn (1547) | more than 13 years ago | (#434909)

if NetBSD has avoided a fork, Linux couldn't avoid a fork?

NetBSD has already forked. Where do you think OpenBSD came from?

Re:This has been the case with Alpha for a while.. (1)

The Finn (1547) | more than 13 years ago | (#434910)

I started using NetBSD in 1996 after a surplus decstation 5000/240 was given to me by a friend. since then I've been won over by NetBSD's emphasis on portability and full support of platforms linux is still struggling on. (alpha 3000/xxx, decstation, and vax.)

the NetBSD Goals [netbsd.org] page really lays out the reasons I like NetBSD.

Why is the kernel one tree anyway? (1)

iabervon (1971) | more than 13 years ago | (#434912)

It seems like the situation of having a monolithic tree controlled by Linus with substantial portions that he doesn't have any personal use for is somewhat silly.

It leads to situations where he doesn't want to allow big patches that he can't look at to see if they are good, but the unpatched tree doesn't work at all.

Furthermore, it means the kernel source tree contains >16M of code specifically for processors that are not going to be used in a particular installation.

Why not have each arch subdirectory in a separate tarball, which follows the core kernel but doesn't go through Linus at all, going instead through a maintainer who actually works on that platform?

If the only current kernel that works on PPC is the fork, why doesn't kernel.org carry that instead of the portion of the official kernel that is specific to PPC but doesn't work?

Re:On the subject of Kernels (1)

iabervon (1971) | more than 13 years ago | (#434913)

The current status of 2.4.x is "*we* think it's stable, but massive testing might reveal something". 2.4.1 is stable for the kernel developers, but there are a lot of combinations of hardware out there that the kernel developers don't have access to, so there could be really subtle (one in a million machines, e.g.) bugs.

The 2.5 series will start when there's nothing left to do on 2.4.x, essentially. Presently, people are looking for bug reports on 2.4.x stuff and fixing problems found by distribution-makers and end users who wait for stable kernels. Then the developers will get some sleep for a bit, and then figure out what changes should go into 2.5

Re:Linus has said (1)

singularity (2031) | more than 13 years ago | (#434914)

"The Linux kernel belongs to Linus."

What? Silly me, I thought the kernel was GPL software. Imagine my disillusionment, I though that "Information wants to be free."

Apparently I have this all wrong - the kernel belongs to Linus. If I want to use it, I to ask him to use it.

Linus simply maintains one of the Linux forks (currently about the only one, excepting patched versions). He maintains the fork that he wants to maintain, with the features that he likes. He controls this fork, but that does not mean that it belongs to him. It is GPLed software, after all.

If he does not accept a patch into the fork that he maintains, that his within his powers. But anyone can start a forked copy with the patches and, since the kernel is GPLed, use any future versions of Linus's kernel in their fork (since the forked kernel would have to be GPLed, as well).

Sometimes I think that forking the Linux kernel might be one of the best things to happen to Linux. We are getting close to the need, since it will begin to be difficult to maintain a full kernel that will run on everything from a palm-top to a mutiple-processor server.

Competition encourages development, and if you add GPL to the mix, the competition benifits everyone.

Re:Look at the history... (1)

Marsala (4168) | more than 13 years ago | (#434916)

Zack Brown was laid off from Linuxcare :-( and as such the kernel cousin lists have moved to kt.zork.net [zork.net]

Re:No big deal (1)

c (8461) | more than 13 years ago | (#434926)

"IIRC, Linus' usual behavior with platforms he doesn't frequently use is to let the primary maintainers feed him big merges periodically... he basically lets them run their own "development" cycles (the "odd" cycles for the core kernel) and merge "stable points"."

Actually, I get a completely different impression. It appears that the PPC people are having the same problem that the ISDN people, the USB folks (I think), and Donald Becker have. These people branch off in their own direction, refuse the follow the current development tree, and then periodically play catch up and dump a huge load of crap on Linus and company. Every time this issue is brought up he comes down hard on these groups.

The gist of it is that if you're developing against your own CVS repository rather than tracking Linus' tree, you should expect to get ignored a good part of the time.

c.

Re:I used ppc for years, but enough is enough (1)

erwin (8773) | more than 13 years ago | (#434927)

Having personally suffered at the hands of Apple's stupidpidy, I can sympathize with you feeling. However, I still think the PPC is a good platform for Linux.

Remember, PPC doesn't automatically equate with Macintosh. RS6000 is PPC based, as are a lot of embedded controllers.

It's more than the desktop/server market. I thing good linux support is key to the PPC remaining a viable embedded product.

my $0.02

Re:Please tell me this is just a rumor (1)

erwin (8773) | more than 13 years ago | (#434928)

The architecture isn't abandoned, it's just not as convenient to build your own kernel as it would be on the x86 side. the LPPC crowd has the information that you need, you'll just need to know where to get it.

Esoteric political discussions aside, the PPC is still a great system to run Linux on....

Re:This has been the case with Alpha for a while.. (1)

rpk (9273) | more than 13 years ago | (#434929)

There's nothing in Linux to support architecture portability ? No hardware abstraction layer or the like ?

perhaps there's a reason (1)

whydna (9312) | more than 13 years ago | (#434930)

Perhaps Linus has his reasons. He could be too busy, or simply feel that the PPC code is in no state to even be entered into a development kernel. I haven't followed the kernel development list lately, but I'd have to imagine that there's a reasonable explination.

-Andy

Re:So my Mac is incompatible ... (1)

Bearpaw (13080) | more than 13 years ago | (#434933)

You think you got it bad? I never did get my TI calculator to run DR-DOS. Damn, I dunno why I ever bought the stupid thing.

Re:On the subject of Kernels (1)

ethereal (13958) | more than 13 years ago | (#434934)

2.4.1 is a test kernel in the sense that it's at the beginning of a new stable series, and historically the beginning of the new stable series have not been as stable as the series later becomes. Although IIRC Linus was commenting on kernel traffic that the 2.4.x stable series has started off much more stable than 2.2.x, for example.

Re:On the subject of Kernels (1)

Hammer (14284) | more than 13 years ago | (#434935)

It generally takes a few versions on the new "production" kernel series before it is considered stable enough to start the new development tree.

My guess is 2.5.x will start around 2.4.4-2.4.6

Re:Whatever (1)

Hammer (14284) | more than 13 years ago | (#434936)

Actually, in most cases the MAC is technically superior. Better processor (M68k) or even much better (PPC), better bus etc. Only the OS and the single button mouse sucks.

Does anyone know anything? (1)

jpgrimes (15330) | more than 13 years ago | (#434937)

Look, the linux kernel has never had proper ppc support, this is not an issue that has anything to do with Mac OS X or 2.4. This has been true since the early days of the ppc kernel. You always downloaded from Cort or Paul (at least for apple /clones).

Why it has not been integrated into the tree (especailly as of version 2.4) is something I don't understand. I would have liked to see Pauls response but know nothing about this issue.

Re:This wouldn't surprise me (1)

PigleT (28894) | more than 13 years ago | (#434943)

You seem to have confused `Linux' with `Linus'.
~Tim
--
.|` Clouds cross the black moonlight,

Doubt it. (1)

just dave (29782) | more than 13 years ago | (#434944)

Without knowing any of the details, I would have
to say that some sort of war is unlikely. After
reading some of the kernel mailing list about
patching leading up to 2.4, I will say that
submitting patches in big wads and essentially
doing closed development *does* annoy or even
piss off (if you can imagine such a thing) Linus.
This happened with the ISDN subsystem. There is
more likely some form of miscomunication, and
maybe the nature/frequency of the patches is
causing them to be dropped. More than likely,
we'll be able to read some article about this
somewhere soon enough.

-Dave

Re:PPC is an inferior platform (1)

sirinek (41507) | more than 13 years ago | (#434952)

You know, if you're going to troll, AND abuse your +2 bonus on it, you could do a better job than that.

Re:PPC is an inferior platform (1)

sirinek (41507) | more than 13 years ago | (#434953)

I agree about not asking slashdot, but asking the kernel developers. This was wholly inappropriate for "Ask Slashdot". If they wanted to write something about this issue, they should have gotten the other side of the story.

siri

Re:This wouldn't surprise me (1)

AYEq (48185) | more than 13 years ago | (#434956)

The only trouble with that logic is that you still get sub standard software fro less-that-popular platforms. This is probably just a lag due to the fact that the 2.4.x release was kind of pushed out the door. Were only at 2.4.1, give it some times to stablize on the i86 hardware then the patches should be integrated. Before we start thinking that this is a silent platform war, and if it is then "fork-away" and everything will be ok. Still the "comercial motive theory" kills platforms quicker than anything. (there is no M$ software for MIPS,ALPHA(anymore),etc..)

Re:perhaps there's a reason (1)

Cramer (69040) | more than 13 years ago | (#434963)

He pushed in the entire IA64 tree -- aside from the people who wrote it (and therefore already have a more up-to-date tree than Linus) and are prototyping the silicon, who actually has an IA64 system?

The PPC tree is already there. Linus is not it's maintainer. Code level decisions are entirely his to make in this vein.

(In reality, this is no different than the old vger/cvs/davem sparclinux tree.)

Re:You hit the nail right on the head (1)

scumdamn (82357) | more than 13 years ago | (#434965)

Do NOT click the above link!
The link above links to goatse.cx and manages to hide it very well.
*******************DO NOT CLICK THE ABOVE LINK******************

Re:Linus has said (1)

Eil (82413) | more than 13 years ago | (#434966)


Out of all the posts so far, I think I can agree with yours the most. You said it a lot more bluntly than I would have, but hey. The idea's the same. (Oh, and try to ignore all those Cowards below that refer to you as a troll. I despise AC posts because they are always flamebait.)

Anyway, back to the point. I see a lot of other posts that say, "Well, I'm sure Linus has his reasons..." Indeed he does. He probably doesn't give much of a shit. His experience obviously lies in the x86 arena, so why should he be bothered to make his kernel compatible with every architecture known to mankind?

I repect Linus as a master programmer, and I really wish people would get it through their heads that the Linux kernel belongs to Linus. He owes the Linux community no favours, yet everyone and their mongrel is yammering away with stupid statments like, "Why doesn't Linus add this filesystem?" or "How come [random bug] isn't fixed yet?" or "Why don't I have support for my 524,288-way SMP ARM system?"

For those mentioning ReiserFS, (and still remain in the realm of cluelessness) Linus did not include it in 2.4.0 because he wanted a *code-freeze* which meant *fixing bugs* whilest being absolutely certain not to introduce new ones. It had nothing to do with Linus's opinion of the FS nor the quality of the patch itself. And really, why complain at all? Adding the code to your favorite kernel is a single command away, do you really need Linus' blessing just to run the thing?

I [don't | didn't].

Re:one sided? (1)

heh2k (84254) | more than 13 years ago | (#434967)

huh? arch endianess has NOTHING to do with patches being rejected. that doesn't even make sense.

Poor guy... (1)

smoondog (85133) | more than 13 years ago | (#434968)

Paul Mackerras maintainer of the PPC kernel and his response was quite interesting

I wonder if Paul Mackerras knew his response was going to be put up on /.? :) Anyway, this post crosses the fine line between starting a flame war and reporting one. I wonder if this really is a non-issue and just a *very* subtle troll posting.

-Moondog

Re:It may be nothing insideous (1)

naasking (94116) | more than 13 years ago | (#434973)

That's not the point. The point is that people have already fixed some platform specific issues but Linus is rejecting them from the main source tree. That's the issue.

-----
"People who bite the hand that feeds them usually lick the boot that kicks them"

Re:It may be nothing insideous (1)

Cowboy (98435) | more than 13 years ago | (#434974)

>>The number of x86 users dwarfs the number of PPC/SPARC/etc users, so in the time it takes to verify and integrate the other architectures might be better spent elsewhere for now.

There is a distinct flaw in this argument. This would mean that Microsoft is more important than any other OS, and we as a result should spend all of our energies working with and supporting it rather than any other OS, like say, linux. If Linux is to be cross-platform with regard to hardware, then it does remain the onus of the primary developer to incorporate that information into the kernel.

Is it really possible to avoid a fork? (1)

jmenezes (100986) | more than 13 years ago | (#434975)

No, I'm not trying to troll here, but is it truly possible to avoid having the linux kernel end up forking somehwhere along the line?
Right now you have linux running on a power mac, on an ultra sparc, on a 386, on an SGI, on a cisco router, on IBM mainframes, on tiny embedded projects...
You have one kernel, yet everyone is trying to push it every which way imaginable..
If you try to make the code trully able to take advantage of big iron, you make it so it cant really run on a 386. You keep it optimized for your 386, you wouldnt consider putting it anywhere near your mainframe without major code changes, ala what IBM is doing.
yet by keeping these things away from the kernel, it will basically force forking in the not too distant future...
i guess Linus might be tryin to avoid a situation like NetBSD that runs on everything imaginable, but doesnt really doa good job on any.,.
but if he is, with all the diferent directions Linux is headed, forking is just inevitable.

anyone asked Linus? (1)

WebTurtle (109015) | more than 13 years ago | (#434977)


Surely the advent of MacOSX is not enough to warrant the neglect of the PPC linux.

Maybe we should ask Linus or someone else who is officially working on the kernel before double-guessing as to why the patches aren't being incorporated.

Underscores the freedom of FSS/OSS (1)

Angelwrath (125723) | more than 13 years ago | (#434983)

This underscores the freedom of FSS/OSS: do whatever the hell you want, and don't give a damn what anyone else is doing unless you want to.

Linus doesn't support the patches - someone else does. You don't need Linus' blessing to do anything with Linux, so whether he supports the patches or not is moot.

Re:It may be nothing insideous (1)

Angelwrath (125723) | more than 13 years ago | (#434984)

"I'd hope that architecture politics stay away from the linux kernel."

And substitute what in its place? Linux versus BSD? Vi versus Emacs? Ksh versus Bash versus sh, csh, zsh, sh? Gnome versus KDE? Free Software versus Open Source? CmdrTaco versus CowboyNeal?

I am looking forward to an orderly bloodbath that will avoid the need for senseless debate.

Re: Then we should wait and not speculate. (1)

tz (130773) | more than 13 years ago | (#434987)

There have been reasons in the past Linus has rejected patches and created a small fork.

This is a problem because a production (4 is an even number) kernel is badly broken and Linus isn't accepting fixes.

Though I doubt it is anything sinister. Maybe he simply can't test the patches, or can't test them easily. Could someone ask Apple to send Linus an iMac or something if that is all that is stopping it?

I have an Alpha (UDB), Dual P3, Athlon, iMacDV, 486 notebook and iBookSE, and run linux on all, except the iBook but that is because I got it last night and I need to adapt a boot kernel/disk for the vid chip - it booted but the screen blanked.

So I would really like a working 2.4 kernel for my iBook and iMac from an unforked tree.

It wouldn't be because of OS X or Darwin (1)

tz (130773) | more than 13 years ago | (#434988)

At least not for a long while. First, you really need OS X (and probably a paid Apple Developer) to do things like sound and other hardware functions since Apple is delaying opensourcing those layers.

For example, there is no way of getting sound under just Darwin unless you write your own driver, which is going to be superceeded by the official Apple driver.

The Man pages are wrong under Darwin - describing hardware and devices that don't exist, things that are overridden and disabled (netinfo/lookupd acts like NIS), and the paths for data are wrong (lookupd's manpage points to nonexistent paths).

Within those limits, Darwin works very well and has some interesting IO and VFS concepts. I won't say better until I see them developed for. Apple has also done a lot of work on things like GCC, so many things "under the hood" work better under Darwin than LinuxPPC.

Right now, I can get sound and even some multimedia (I've played mpeg movies) under LinuxPPC. I can't under Darwin. Under darwin, lots of things barely work, and those that do are limited in features. Under Linux, the framebuffer console is fast and I can easily change modes and fonts under Linux.

Basically LinuxPPC is usable as an environment - I've actually got most things I do under x86 working under it. A few others are compiler or endian hiccups I can usually resolve

Darwin is almost useless as an environment, except to develop Darwin in situ. But it was intended as a server, which might be the problem. They don't want it to be too "cool". A full Darwin (with X windows, sound, multimedia, just like LinuxPPC) system won't be a threat to OS X, but I don't think Darwin will spark a lot of of creative Opensource development until it is as good as LinuxPPC without Quartz and the rest of OS X.

Right now, if you want to run a rich UNIX style environment on your Mac, LinuxPPC is the only viable alternative. For development, Darwin and it's toolchain is more Mac friendly. They both have their advantages.

And actually I see any rivalry as friendly. Darwin and Linux can learn a lot from each other, and I would rather have several good alternatives.

2.4.x and other architectures (1)

evildead (150474) | more than 13 years ago | (#434995)

Most of the changes going into the test kernels seem to be focused on x86.

I've seen only a few for alpha, which I support at work; and even less for ppc and sparc.

It's very depressing, because 2.4.x is, at the moment, completely unuseable on one of our alpha workstations.

I can't say that its a lack of resources, especially from the questions raised in this article, so I don't know ...

Re:PPC is an inferior platform (1)

SisterRay45 (151982) | more than 13 years ago | (#434996)

PPC is a fine platform, its far superior to the CISC x96 platform that most of us use for one reason or another. I think the problem might be that their patches might be simply bad or maybe they just should try to get a straight answer from someone rather than having their own kernel tree. Maybe there is a good reason why their patches are being ignored...they might suck. Instead of asking Slashdot perhaps you should be asking the kernel development mailling list.

Jon

Linus isn't our savior... (1)

gozie (153475) | more than 13 years ago | (#434997)

I've noticed that we are relying to heavily on Linus to do what WE want him to do. Not necessarily doing it ourselves. I'd get pissed if I were him. It's hard enough for me to do something that I'm not passionate about (homework), let alone porting to something I don't use...

Re:So my Mac is incompatible ... (1)

jck2000 (157192) | more than 13 years ago | (#435000)

Well, a 604e _may_ work on BeOS: http://www.be.com/support/guides/beosreadylist_ppc .html

Re:Please tell me this is just a rumor (1)

The Mutant (167716) | more than 13 years ago | (#435006)

Don't worry about it - you'll have OS X in about six weeks.

Re:You hit the nail right on the head (1)

streetlawyer (169828) | more than 13 years ago | (#435008)

wow, that was good. I don't think there was any way at all of not getting hit by that.

RANT: Was:This wouldn't surprise me (1)

Fat Rat Bastard (170520) | more than 13 years ago | (#435009)

Then why don't you fork the code, create some sort of new organizational structure / committee and do it properly? That's what the GPL is all about, right? Put your money where your mouth is.

I always love people (OSOpinion submitters and ZDNet staffers) who seem to have all of the answers to perceived problems, especially when they aren't involved in the process in the first place. I bet you're the type that bitches about the government and doesn't vote.

Re:It may be nothing insideous (1)

gammoth (172021) | more than 13 years ago | (#435011)

Bull shit.

Torvald wasn't offered a lucrative position with transmeta because of his anonymity. Linux is the product of many people's efforts, including testers, the folks at GNU, and volunteer developers. Without them, Torvald would be just another Finn.

Re:The Kernel Forked Long Ago (1)

madumas (186398) | more than 13 years ago | (#435015)

Every major distribution has it's own kernel tree - no major distribution has ever shipped one of Linus's kernels.

I don't think we can call this a fork. Every distribution apply patches, but they always patch Linus' tree. When Redhat will release a 2.4.1 kernel, it will be Linus' kernel with a few patches. A real fork would be an independant work, with a different version numbering and in a few months a product completly different. I don't think it happened, but it may be happening with PPC.

Re:Is it really possible to avoid a fork? (1)

Huge Pi Removal (188591) | more than 13 years ago | (#435017)

i guess Linus might be tryin to avoid a situation like NetBSD that runs on everything imaginable, but doesnt really doa good job on any.,.

That's not entirely fair! I've got NetBSD up and running beautifully on two old 68k Macs, running BIND, netatalk, ntpd, you name it. It seems extremely stable, and I wouldn't swap it for anything.
(BTW, I tried to install Linux m68k, but it didn't support the ethernet card on one of the Macs.)

Just so I'm not completely OT, could I ask why, if NetBSD has avoided a fork, Linux couldn't avoid a fork?

- Oliver
"exp(i*Pi)+1=0" - Euler

Re:It may be nothing insideous (1)

Thackeri (203958) | more than 13 years ago | (#435021)

True, but it does seem to me that the strength of Linux (and other open sourced projects) is that anyone can make contributions and aid the developer.

Who should the onus lie with in this situation, PPC users or those writing the central kernel? Linus does have an obligation to the people who use Linux. It's his own damn fault - it's the price you pay for writing something that has become so popular!

Unhappy with Linux PPC? (1)

Fujisawa Sensei (207127) | more than 13 years ago | (#435022)

If you are unhappy with Linus ignoring Linux PPC or believe that he is ignoring Linux PPC, or whatever, try NetBSD PPC.

So my Mac is incompatible ... (1)

tenzig_112 (213387) | more than 13 years ago | (#435025)

with MacOSX (It's a 604e PPC), with all windows software (emulation sux0rz) and now with the main trunk of Linux.

Youch.

I'm sure glad I thought different [ridiculopathy.com] .

breaking stuff? (1)

TWX_the_Linux_Zealot (227666) | more than 13 years ago | (#435028)

I'm not a very good coder, but maybe some thing that has to be done to the PPC version breaks something in the normal distro? I'm using a Debian M68K version on my Centris, and it's not the stock kernel, there is too much weird stuff. If the mods break the normal kernel, I think it would make sense to not include the changes.

"Titanic was 3hr and 17min long. They could have lost 3hr and 17min from that."

Why not jump ship? (1)

rsimmons (248005) | more than 13 years ago | (#435034)

Why not migrate your Linux/PPC boxen to the powerpc port of OpenBSD [openbsd.org] ?

Re:one sided? (1)

klomper (250773) | more than 13 years ago | (#435035)

I agree. How can someone who says that this is a open platform totally screw over the PowerPC side of the picture? Even if Apple is releasing OSX, it should give Linus or any of the kernel developers a reason to not keep up on the patches.

Re:It may be nothing insideous (1)

eXtro (258933) | more than 13 years ago | (#435037)

It's not a flaw. It depends on what the desirable outcome is. If you're a business that sells software the desirable outcome is probably money. In this case your priority would most likely be developing software for Microsoft Windows. Ports to Linux, MacOS or BeOS might be planned and developed, but if those ports jeapordize the main project they'll at least be put on the back burner.

In Linus' case the desirable outcome is probably a stable kernel that meets the needs of most people who want to use it. In order to get to that stable kernel he has to mimimize outside influences that either distract him from the goal, or very likely compromise it. The amount of testing that needs to be done to ensure the integrity of a patch is proportional to the size of the patch. The ease of understanding a patch is inversely proportional. This is why he asks for small patches that do specific things as opposed to the tarball of patches that the Linux PPC folks try to force him to take. Any piece of that large patch may no longer be applicable in his development tree. A bunch of small patches may also not work, but at least they're isolated and much easier to debug.

I'm sure that eventually the PPC code will be merged in, but in the mean time given (from other posts including comments from Linus) that the modifications are being given in a format that he doesn't want he's doing the right thing. It's called project management.

Re:one sided? (1)

digidave (259925) | more than 13 years ago | (#435038)

No one ever believes their code is rejected on technical merits

While this is true, Linus would still have known about the issues. The question remains why he didn't correct the problem before the release of 2.4. I hope the thought of pushing back the release date again didn't scare Linus into ignoring some problems just to get it out the door. That's how MS released Windows 2000.

Re:This wouldn't surprise me (1)

Hiro Antagonist (310179) | more than 13 years ago | (#435043)

That is all fine and dandy, but let's not forget one key fact here: Linux is not a consumer OS. It never was designed to be a consumer OS. Linus didn't sit down at the University of Helsinki and think "How can I gain OS-consumer market share?" He sat down and thought about creating a free alternative to all of the expensive, proprietary OSen out there, that he could run on some old hardware that he, as a poor college student, happened to own.

Now, it is true that Linux has matured well beyond that stage, but it it still intended as a hacker's operating system, not a consumer operating system -- which is one of the big reasons it's so popular. Don't like what your OS vendor has dictated to you as "The Way Things Should Be(tm)?" Then write the code to change it. Or find someone who can code and pay them to change it for you (which is not as expensive as one might imagine). If you don't like it, you are free to use something else.

Note that market share has no place in this philosophy. Neither does the word "consumer". A "consumer" is an aptly named entity, namely one who consumes. This implies no contribution back to the community from which it is consuming. Linux may be free, but it is only free because the Linux community is filled with participants instead of consumers. People who give back to the community in some meaningful way -- either by helping others, writing documentation, coding, or providing donations to groups such as the EFF or FSF.

So, in short: Linux is steered by those who contribute, not those who leech off of the work of others. In turn, all involved gain the benefits of belonging to an open community, and the freedom to come and go as they please.

--

Flip side of coin (1)

pra9ma (315554) | more than 13 years ago | (#435048)

He basically says that Linus is ignoring the patches from the people working on the PPC side of the kernel

So Linus is holding off on a patch, big deal. Look how long it took 2.4 to come out, I don't buy that "Linus is holding out" comment. If Linus held out its probably because he's tied up with so many things and for the weight of the entire Linux project to be held on his shoulders is enough to make the typical person yank their hair out.

So if these patches are so detrimental to the advancement of it all, then why wait for Linus, code em yourself or have some other developers assist in the matter, a patch is not an OS and wouldn't require the amount of time as doing a complete kernel revsion so who does this guy think he's fooling. It seems to be more of an animosity based comment than one that would question Linus' integrity.

Is Fidel Catro really hacking [antioffline.com]

Please tell me this is just a rumor (1)

Kara B. (315771) | more than 13 years ago | (#435049)

I was planning on upgrading my imac to linux in a few months when I've learned more about it.
Why would they abandon such an cute little platform?

--Kara

Re:This wouldn't surprise me, but dumbasses do (1)

shakazulu (315787) | more than 13 years ago | (#435050)

Like Linux is the only open source project, or the only way to organize one: http://www.netbsd.org/Ports/macppc/models.html

That's nothing new (2)

Anonymous Coward | more than 13 years ago | (#435055)

A lot of the ports are in their own trees. Ia64, you name it... there's a couple of reasons: Linus only has so much time to incorporate the patches and the other one is that the tarballs are already way too large, not everyone needs to download all the architectures, most only want ia32.

Re:This wouldn't surprise me (2)

johnnyb (4816) | more than 13 years ago | (#435062)

It is Linus's project, and he's free to do with his code as he pleases. If his needs don't match everyone else's, they are completely free to fork. This actually happens quite a bit, as none of the distributions use a pure Linus kernel.

Re:Is it really possible to avoid a fork? (2)

johnnyb (4816) | more than 13 years ago | (#435064)

Actually, the kernel has forked several times over, and has been doing so for many years. The forks I can think of are:

MOSIX
MontaVista Real-Time
ucLinux
There's another real-time platform I'm forgetting
Each distribution
Each architecture

Yes, each distribution basically has its own kernel tree, because the users of each distribution are different. Of course, this kind of forking has typically only helped Linux, and I don't see that changing.

Re:This has been the case with Alpha for a while.. (2)

johnnyb (4816) | more than 13 years ago | (#435065)

Ummm.... its actually only by the good graces of people that any of the architectures stay in decent condition. They don't pop out of thin air. I've used LinuxPPC for over a year now, with no problems/reboots except to upgrade my machine. I run Ximian GNOME with no problems whatsoever. I've never use PPC on a server, however, so I can't comment there

Re:The Kernel Forked Long Ago (2)

johnnyb (4816) | more than 13 years ago | (#435066)

It's tough to say what's a fork and what's "just patches". Was it a fork when someone introduced USB support to the 2.2 series? What about removing the MMU component for ucLinux? Real-time support? On each of these, are they patches, or actual forks? I consider them forks, because they are independently maintained (generally). Alan Cox basically has his own kernel tree. It can takes months for a patch to move from Alan's tree to Linus's, if at all. Now, all these people tend to sync up every once in a while. This happens because (a)they can, (b) it would be stupid not to use someone else's technical advances, and (c) their common ancestry makes it easier to do so than porting from the BSDs or whatnot (that happens too, though). However, I don't think that a fork necessitates something becoming a completely different product. Think of the egcs fork of gcc, and things of that nature. With free software, eventually the best stuff will be used by all, and the sucky stuff will eventually be left in disuse or transformed into something better (note I said eventually).

This has been the case with Alpha for a while... (2)

Kha0S (5753) | more than 13 years ago | (#435067)

... and only by the good graces of folks like Jay Estabrook at DEC did it manage to stay in decent condition. I've become so frustrated with Linux/Alpha and its instabilities (including utterly broken IPv6 and major toolchain issues) that I moved to NetBSD/Alpha a little over a week ago. It's been wonderful.

I'd suggest that unhappy PPC people do the same. You'll find the NetBSD community to be a lot more responsive to issues with portability, and are on top of bugs very quickly.

IRDA All Over Again (2)

Royster (16042) | more than 13 years ago | (#435075)

This was the same situation with the IRDA susbsystem as detailed in this Kernel Traffic [linuxcare.com] thread. Linus dosn't like parge patches. If he gets 30 10K patches in seperate emails rather than one 300K patch, he can decide to merge 25 of them and ask questions about the other five and maybe later accept them or get them modified to fit his idea of the "right way" to do it. If Linus dosn't like a few lines of a 300K patch, he has no chouce but to reject the whole thing.

It has everything to do with the way that Linus works and nothing to do with the technical merit of the port.

Remember, it is Linus' kernel.

Re:one sided? (2)

TWR (16835) | more than 13 years ago | (#435076)

Um, no. People (like me) who own Macs but want a Unix system at home to fiddle with would naturally be attracted to LinuxPPC. But I also want an OS which actually support my computer's hardware and has a usable UI and applications. If Mac OS X wasn't coming out in 6 weeks, I'd have a Linux partition at home and dual-boot. But Mac OS X is going to be here Real Soon Now, so I don't bother with Linux.

In fact Mac OS X could put a tiny dent in Linux x86, too. Due to the less than stellar quality of Linux for the Macs, I've considered spending a grand or so to buy an x86 box to run Linux. Now I've got no need to do that. I'd imagine that there are plenty of Mac-using people who fall in the same boat.

-jon

Re:The Kernel Forked Long Ago (2)

Arandir (19206) | more than 13 years ago | (#435080)

Slackware ships with a stock Linus kernel... It's one reason a switch from **cough**, because I never knew what I was getting.

Uh-Oh (2)

eric2hill (33085) | more than 13 years ago | (#435084)

I thing the sysop needs to go get the fire extinguisher off the wall and sit it next to the server. He'll need it with this article...

I agree (2)

cxreg (44671) | more than 13 years ago | (#435088)

It sounds suspiciously like how Hans Reiser was "victimized" by the entire linux-kernel list in some huge conspiracy. No one ever believes their code is rejected on technical merits :P

Re:Yes, that's right (2)

johnathan (44958) | more than 13 years ago | (#435090)

How much is this royalty and where's the URL to prove it?
Oh my lord... is it really that difficult to detect sarcasm?

--

Re:calm down... (2)

Cramer (69040) | more than 13 years ago | (#435094)

While true, inside arch/ppc Linus shouldn't be "reviewing" anything. He's not a PPC guru. A quicky diffstat and browsing of the stuff outside arch/ppc would appear to be all that is required.

Linus' rant was about the ISDN people sending him huge (and they are bloody huge) patches a few days after the declaration of "code freeze" (which remains to be clearly defined by Linus as he, himself, then pushed the entire IA64 tree [4.9M gziped patch] into the kernel.) Linus is also insanely anti-CVS. (It worked perfectly for sparclinux.)

It's been that way for years (2)

Tony Hammitt (73675) | more than 13 years ago | (#435095)

PPC Linux has always been about getting the right patches to get a bootable system. No one in the official kernel seems to care that the deviations between the 'Linus' kernel and that which will boot a PPC box have been getting larger all of the time. It's pretty hard to keep up with nowadays. It is apparently getting worse.

My personal experience: I have an SMP PowerMac. It can run LinuxPPC or YellowDog in uniprocessor mode only. Any attempt to get the other processor working results in an unbootable kernel. There are no patches for it, there are no tools for debugging the problems, there is simply no way to get the system working correctly.

Then you have to take into consideration how difficult it is to actually get a new kernel installed on the system. The kernel has to reside in the HFS partition. The kernel cannot safely write to the HFS partition. Using a second box as an intermediate FTP server is the only way to change kernels. Maybe it's better now, I wouldn't know, it's too depressing to try to fix, every time you try to do something you have to reinstall. It's like windoze.

The whole edifice of running Linux on a Mac depends on just using the kernels that came with the computer. Which, by the way, they don't tell you how to build or what options they used. The LinuxPPC guys are trying their hardest but the system is still years behind the usability of Intel Linux. (and another problem, no ECC memory on the Macs, either, constant rebooting is necessary)

So, I'm back to MacOS. It would be nice to have a usable Linux system but it's looking like that will never happen. I wanted to use it for validating MSB code but it's too unusable. Maybe someday.

On the subject of Kernels (2)

carlhirsch (87880) | more than 13 years ago | (#435099)

Lots of folks in this thread seem to be referring to Kernel 2.4.1 as a test kernel.

This doesn't seem to jibe with my understanding of the kernel tree. I believe that any *.even-numbered revision is a productions kernel. *.odd-numbered kernels are the development branches. For example, any 2.3 kernel was development for the 2.4 kernel. You can still have 2.4.1test1 or 2.4.2pre3 however.

But this brings me to my question - where is the 2.5 kernel series? Do we have any goals stated for Kernel 2.6?

-carl

Re:Is it really possible to avoid a fork? (2)

cyber-vandal (148830) | more than 13 years ago | (#435103)

Isn't OpenBSD a fork of NetBSD, created when Theo fell out with the other developers.

Re:Yes, that's right (2)

cyber-vandal (148830) | more than 13 years ago | (#435104)

How much is this royalty and where's the URL to prove it?

No big deal (2)

macemoneta (154740) | more than 13 years ago | (#435106)

I don't see why this is a problem. Even the i386 branch is in this state. For example, I wanted to do exactly the same thing; upgrade a PC running a 2.2 kernel to 2.4.1. It turned out that the "official" 2.4.1 didn't correctly support some of the hardware I needed (Iomega Buz video capture), so I went with the Alan Cox 2.4.1-ac9 kernel (which incorporates the Buz patches and is working just fine for my configuration).

I periodically follow the kernel groups, and it's clear to me that the idea is to keep the kernel as stable as possible, while supporting the most mainstream environments. I'm sure the support I need will eventually find its way into the mainstream kernel.

If you're the type of person that needs the latest and greatest (probably most /. users...), then you already know how to get a kernel or apply a patch.

So what's the problem?

So Why Not Jump Ship? (2)

fm6 (162816) | more than 13 years ago | (#435110)

Forgive a stupid question from a non-PPC enthusiast, but what's wrong with people jumping ship? I admire both Linux and Linus, but it's just software, not the New Jerusalem [njchurch.org] . Anyway, the traffic will not be one-way, and having technology exchange between the Linux and Mac OS communities will be good for both platforms.

Oh wait, there's the "Free Software" religion. Well, if you believe in it that strongly, do what Linus did -- go hack your own kernel. You don't even have to start from scratch.

__________________

Linus has said (2)

SquadBoy (167263) | more than 13 years ago | (#435111)

over and over again that he does not care where the kernel goes. He only works on what he thinks is cool. I'm thinking that the people who use the PPC stuff are doing a good job and Linus is simply doing what he wants to.

I think it's time Linus gave up some of his contro (2)

uriyan (176677) | more than 13 years ago | (#435112)

Ten years ago when Linux was a very young project, with only a few of really devoted developers, the mailing list structure of the kernel development was efficient. Since it took over 3 years to get Linux to work on a TYPICAL PC configuration, it wouldn't make sense to talk about splitting the work into several groups.

However, now the situation is cardinally different. Linux runs on about a dozen of major CPU platforms, supports endless types of devices that sit on every imaginable kind of a bus.

In this situation, it makes sense to split the single bazaar into a few smaller ones, when a strict relationship is declared between them. I think no single individual (and that includes Linus) can fully understand the whole kernel workings. While Linus could (and should) remain active in many of those groups, it is no longer possible to leave all the decision-taking for him.

A kernel split would be BAD. First of all, consumers want one set of sources (and preferably, binaries). Secondly, the improvements in some projects could be of use to others. For instance, while hardware I/O and filesystem issues are quite different, their workings have to be combined in order to achieve optimal performance.

The bottom line: Kernel is growing up. More parties are willing to participate in its development. Linus has to ease his control, for the common good.

Re:Please tell me this is just a rumor (2)

ichimunki (194887) | more than 13 years ago | (#435113)

who is "they"? the following distributions all run on PPC: debian, suse, and yellowdoglinux.

Re:It may be nothing insideous (2)

vinnythenose (214595) | more than 13 years ago | (#435114)

Linux Thorvald owes nothing to the Linux community. He doesn't have to give up every waking hour to appearse millions of people just because they want to use something he created. The bottom line is that If someone creates something and people start using it, the creater does not owe those people anything.

It pisses me off when people refer to musics grous and claim the the group owes their fans a new album. The group only needs to put out a new album if they want to continue their popularity. If they don't care, more power to 'em.

Same goes here.

Re:Slahshdot should fix the hidden GOATSEX html li (2)

gimpimp (218741) | more than 13 years ago | (#435115)

it'd be appreciated if that vulnerability hole was closed.

we all want that hole closed, man! believe me...

Re:I used ppc for years, but enough is enough (2)

namespan (225296) | more than 13 years ago | (#435116)

1.Apple doesn't open up its specs, so coding for linux/ppc largely consists of hacks and other substandard patches.

Apple is partly open, partly closed. Some chipset details on their motherboard are closed, the OpenFirmware stuff is VERY well documented and a bit of a boon. Things ain't as bad as Be made it out to be.

2.The platform isn't as popular, so maintaining the ppc tree at the expense of the x86 one would be ludicrous.

This is true. Including PPC patches in the kernel shouldn't have to bring about this dichotomy, though.

3.The trend has been rightfully away from ppc for the last couple years, since Be decided to abandon the platform.

Uh... what? Be didn't decide to do this based on techincal merit. It was a political move -- and a good one for Be, but it has absolutely nothing to do with the nature of the PPC processor.

4.Several companies (LinuxPPC, YellowDog, etc.) exist to maintain linux/ppc. So why should Linus do their work for them?

We're simply talking about why Linus won't fold the work they've already done into the Kernel, not why he won't do their work. There are several well articulated reasons for this. Yours are not among them, though.

If you want an alternative to x86, then stick with Alpha. Now there's a real platform. The support still isn't as good as with x86, but what can you expect?

The support for Alpha is likely no better than for Linux PPC. In fact, if you want to apply the commodity hardware/number of units out there argument, I'll wager that LinuxPPC seats outnumber Linux Alpha seats. There is no sense in jumping from LinuxPPC to Alpha just because you're having some architecture deals. Out of the frying pan, into the fire.

I support Linus on this one. I think Paul Mackerras is treading awfully close to a kernel fork, and that's the last thing we need.

As has been well-pointed out in other posts for this article, we already have kernel "forks" of the kind that Paul Mackerras is treading close to, and we have for years.

--

Re:PPC is an inferior platform (2)

rbruels (253523) | more than 13 years ago | (#435117)

Many assume PPC = Mac, and granted it does, usually. Thus the teenaged platform-war instigators (no, I'm not discriminating against teens, I'm saying most rabid platform-war participants are the lesser brand of teenagers) decide to make some smart-assed comment such as "PPC is an inferior platform." Rant aside, that's not so bad, the Mac is a great platform in general, but PPC is a very fine processor. RISC architecture has outperformed the usual CISC for years now, and the 750 has some beautiful features on it that make open-source computing downright yummy. As for the kernel patches, yeah, the other guy was right -- if they suck, they're not going to use them. Are they good? I don't know, I've never done an evaluation but would love to see some input on them. If they are good, then is this some large conspiracy to start a platform war? Prolly not. Ryan

I used ppc for years, but enough is enough (2)

Chuck Flynn (265247) | more than 13 years ago | (#435118)

Why isn't it being supported as well as the x86 hardware, you ask? I can think of plenty of reasons off the top of my head:
  1. Apple doesn't open up its specs, so coding for linux/ppc largely consists of hacks and other substandard patches.
  2. The platform isn't as popular, so maintaining the ppc tree at the expense of the x86 one would be ludicrous.
  3. The trend has been rightfully away from ppc for the last couple years, since Be decided to abandon the platform.
  4. Several companies (LinuxPPC, YellowDog, etc.) exist to maintain linux/ppc. So why should Linus do their work for them?

PPC was great four years ago, but it's no longer a viable alternative to x86. Part of that has to do with Apple's bungling, and part of that has to do with the realities of the market -- unless hardware has the wide support of a broad community, it can't maintain the same level of support within an open-source system. There just aren't enough eyeballs.

If you want an alternative to x86, then stick with Alpha. Now there's a real platform. The support still isn't as good as with x86, but what can you expect? Linux is still a hobby OS for most people, and unless there's a strong economic motive driving the support, it'll lag. That motive exists for x86 and its large userbase. It'll be years (if ever) before it can exist for other platforms.

I support Linus on this one. I think Paul Mackerras is treading awfully close to a kernel fork, and that's the last thing we need.

Re:I agree (3)

Thomas Charron (1485) | more than 13 years ago | (#435121)

Not in this particular case. It's being rejected due to the sheer size of the patch required. It's a fairly significant change, and, well, Linux ain't to hot on updates such as those. Alan Cox is the only reason why alot of the stuff makes it into the kernel..

The Kernel Forked Long Ago (3)

johnnyb (4816) | more than 13 years ago | (#435122)

I think a lot of people are _greatly_ misinformed about Linux forking. The truth is, there are at least tens of forks of Linux. Every major distribution has it's own kernel tree - no major distribution has ever shipped one of Linus's kernels. They all have at least one patch or another applied on them. Then there are projects like ucLinux, which are pretty major Linux forks. And then you have the real-time Linux forks, of which there are several. So, the LinuxPPC forking is really not a new thing. Linus is generally pretty slow about applying patches for other architectures. If you are not on an x86 box, you _need_ to not be running a Linus kernel - you almost have to run a forked version. It's not that Linus doesn't like the other architectures or that the other architectures are trying to be rebels. They just have different goals and emphases. Linus can't validate every patch that comes in for every architecture, so he generally just does the x86 stuff. Also, Linus doesn't like large patches, because he can't validate them. And the patches for other architectures tend to be large. Anyway, kernel forking is a regular part of Linux, it's been happening for years with no ill effects (all the good stuff from each fork is shared). In fact, it's rather positive.

There's been a separate PPC tree for a long time (3)

deeny (10239) | more than 13 years ago | (#435124)

Functionally, the PowerPC tree forked a long time ago. Way back when, before the Linux kernel had any USB support, for example, Mackerras' tree had an incorporation of Inaky Perez Gonzales' USB stuff so that iMacs could boot. The USB style changed about a year and a half ago to support the newer stuff Linus was doing (Linus having rejected Inaky's USB code). But the support's always been way ahead on PowerPC of what it was on x86 -- and of necessity.

That makes the forking, what, 2 1/2 years old?

Yeah, it re-integrates from time to time, but the official kernel tree hasn't been the place to get a *usable* PowerPC kernel in like forever.

PS - don't get me started on support for weird PowerPC chipsets. Just don't.

_Deirdre

Re:This wouldn't surprise me (3)

deeny (10239) | more than 13 years ago | (#435125)

So where is Windows for PPC?

Actually, at a MacWorld one year (1995?), IBM was showing Windows NT running on an IBM CHRP-based PowerPC system.

The project was axed.

_Deirdre

Re:This wouldn't surprise me (3)

Col. Klink (retired) (11632) | more than 13 years ago | (#435126)

> if MS ignore a set of hardware, they lose money, so they won't do it

So where is Windows for PPC?

Re:one sided? (3)

arivanov (12034) | more than 13 years ago | (#435127)

The same complaint goes for m68K (which has maybe a handfull of mainstream kernels that even compile) and quite often for (u)sparc. There are lots of conspiracy theories but I think that the answer is very simple: endian-ness. Let's face it most linux development is done on 32 bit little endian. And quite a lot of people do not recheck their stuff for endian issues.

Hopefully now, with IBM's and other "big endian guns" involvment the issues will subside by themselves.

Nothing new here (3)

Pemdas (33265) | more than 13 years ago | (#435128)

The mips tree has its own CVS repository which is the most current mips stuff (oss.sgi.com). That one is maintained primarily by Ralf Baechle.

Similarly, the sparc tree's most up-to-date stuff can be found at the repository David S Miller maintains on vger.

In addition to being the gatekeeper for the official tree, Linus is pulling double duty as the portmaster for the x86 port. Thus, the x86 stuff is always up-to-date in the official tree, and the other archs tend to have some lag time associated with them.

This is nothing new. It's just symptomatic of the hierarchical Linux development style. {Free|Net|Open}BSD don't tend to suffer from this due to their use of a central CVS repository with all portmasters having access to their relevant parts. Whether this is a better system is left for others to flamewar about, but it does prevent the port floating the author is talking about.

Look at the history... (3)

sabre (79070) | more than 13 years ago | (#435130)

First of all, there is a lot more that goes into this than what you might first see... I recommend you read some of these links to get a better sense for the interations that go on about the kernel:

http://kt.linuxcare.com/kernel-traffic/kt20010108_ 101.epl#7 [linuxcare.com] , http://kt.linuxcare.com/kernel-traffic/kt20001127_ 95.epl#6 [linuxcare.com]

and especially: http://kt.linuxcare.com/kernel-traffic/kt20001002_ 87.epl#3 [linuxcare.com] , http://kt.linuxcare.com/kernel-traffic/kt20001010_ 88.epl#7 [linuxcare.com] .

Have a good read. KernelTraffic Rocks.

-Chris

http://www.nondot.org/~sabre/os/ [nondot.org]

It has been this way for some time... (3)

wesmo (181075) | more than 13 years ago | (#435132)

Really...

The LinuxPPC kernel (that's all I can speak about aside from the x86 kernel.. no experience with the others) and the main distribution tree have always diverted away from one another, and, then, seemingly magically, they get sync'ed.

If I remember correctly, it wasn't until the 2.1.128 series kernel that it started building, right out of the box (http://www.kernel.org) on a PPC box. Prior to that, PPC users had to rsync their kernl from a site in AU.

From then on through the 2.2 kernel, this remained true. But, as new Mac hardware flooded into the pool and USB device support became a much higher demand, patches and changes to the kernel came at an accelerated rate, and the master kernel source (http://www.kernel.org) didn't provide the functionality PPC users wanted/needed.

With the 2.4 kernel, it seems that almost all support within the master kernel tree has been halted, and, hence, secondary architecture-focused trees have popped up to fill the void.

PPC users have gotten accustomed to the kernel.org kernel source working for them (as it does for most other architectures), and, with that comes a feeling of acceptance. The fact that it hasn't been working as of late seems like a step backwards (or, in this case, sideways), and is pretty disappointing..

I suspect that, as one response stated already, things will get sync'ed again as soon as it bubbles up to the top of Linus' to-do list.

Older PPC Macs incompatible with Ones, Zeros (3)

tenzig_112 (213387) | more than 13 years ago | (#435133)

I knew I shouldn't have bought the Mac with "Binary Plus."

Zeros, Ones, and sometimes Twos.

I could kick my own ass for thinking different [ridiculopathy.com] .

It may be nothing insideous (4)

eXtro (258933) | more than 13 years ago | (#435135)

It may be a case where fixing outstanding bugs is more important than maintaining the different architectures is the right thing to do for the time being. If you look through the kernel logs you'll see that from time to time architecture specific changes are rolled in. The number of x86 users dwarfs the number of PPC/SPARC/etc users, so in the time it takes to verify and integrate the other architectures might be better spent elsewhere for now.

I'd hope that architecture politics stay away from the linux kernel.

Re:one sided? (5)

Ranger Rick (197) | more than 13 years ago | (#435136)

Yup, go read the linux-kernel mailing list archives; at least once every couple of months, someone tries to give Linus a 300K patch, and he rejects it. Linus wants *small* patches, which do specific things, or implement one new feature.

Kernel Traffic [linuxcare.com] has summarized this numerous times, if you don't want to wade through the lkml. Essentially, the only reason NON-platform-specific stuff gets through faster is because it all goes to Alan Cox, who then stuffs them into his own tree (the -ac* patches). When he decides they're stable enough to pass on, he breaks them up into bite-sized pieces for Linus.

It sounds like the PPC maintainer isn't willing to do this, and so they're falling by the wayside.


1st Law Of Networking: Loose ends are bad, termination is good.

Indeed. (5)

Christopher B. Brown (1267) | more than 13 years ago | (#435137)

If the PPC people are offering Linus huge patches that change lots of non-PPC-specific code and interact scarily with the little patches coming in from other groups, then what's he to do?

He can choose to:

  • Take the PPC patches as gospel, and throw away everyone else's contributions,
  • Go through a whole lot of work breaking the PPC patches down into bite-sized components, or
  • Tell the PPC developers to turn the PPC patches into bite-sized components themselves, and ignore the huge patches that he hasn't time to integrate in.
In effect, he's going with "option 3" here, and that's not an outrageous outcome. The LinuxPPC folk may not like this outcome, but it's neither new, capricious, nor is it discriminatory. Alpha has suffered from much the same issue...

No big deal (5)

artdodge (9053) | more than 13 years ago | (#435139)

I hate to be an old.fart.kernel.hacker and rain on your parade, but there is no news here. Stuff like this has been going on since 1995, at least, with all of the non-ia32 ports. It's a pretty simple problem - Linux supports a lot of platforms, and platform developers don't usually synchronize well with Linus's attempts at keeping some sort of release schedule for the "core" kernel. Linus himself worked on the initial AXP port, and it wasn't long before it fell off the "core" radar and had a separate team with independent patches feeding it. It wasn't a fork, it was just a concession to practical limits on Linus's time and energy.

IIRC, Linus' usual behavior with platforms he doesn't frequently use is to let the primary maintainers feed him big merges periodically... he basically lets them run their own "development" cycles (the "odd" cycles for the core kernel) and merge "stable points".

Since we're now in 2.4.small# mode, Linus is going to be extremely anal retentive about what he accepts, at least until 2.5 launches. I don't know the nature of the stuff the PPC people may be trying to feed him right now, but odds are unless it's either a critical bugfix or an "independent merge" that's been long planned for (f.e. reiserfs), it'll be rejected. When we get into later 2.4.X's, the policy will probably become more liberal.

The rule has always been (ever since the Alpha and M68k ports) that if you run on an alternative platform and follow the latest greatest developments for that platform, track with its maintainers kernels, not with the "mainstream". If you want to follow latest-greatest core stuff, either use ia32 or use a known-good arch bundle and cross-port any necessary changes from your arch maintainer's tree.

calm down... (5)

Phexro (9814) | more than 13 years ago | (#435140)

from what i have heard (from linux-kernel) linus doesn't like to get huge patches. he likes to get small patches that do one thing, since that's easier to review.

the linppc folks have had a hard time accepting this. they want to send one huge patch to get the ppc architecture up-to-date.

it's not a new problem. see this [linuxcare.com] bit on kernel traffic, which covers some of it. there was another thread, where linus flamed people for sending huge patches, but i can't find it atm.
--

one sided? (5)

sith (15384) | more than 13 years ago | (#435141)

I think we may be missing part of the story here... we did not get an explanation of how linus is justifying rejections and such. Anybody have more info?

Yes, that's right (5)

OlympicSponsor (236309) | more than 13 years ago | (#435144)

Anyone who's ever read the linux-kernel mailing list knows how vindictive and political Linus is. There's nothing he loves more than excluding platforms from HIS kernel (he's very protective of it, he only let's a couple of people submit changes, and even then only if they pay him a royalty).

Also, this problem just came out of the blue. It certainly was never discussed (and re-discussed and re-discussed ad nauseum) over the ISDN patches.

Get a grip people.
--
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>