Slashdot Mirror
The Silent Kernel Platform War?
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?"
Well, yes people objected to sourceforge fwd'ings to the -dev list. Hence Dave Wolfe (the guy running all the lists) is creating a list for them. So yes, I do think you're a bit too cynical Who have you been reporting these bugs to? The one you're referring to is rather well known (Paul knows about it, Cort knows about it, I think everyone knows about it.) The problem is finding time to yank yet another hw bug fix out of darwin. What machine do you have anyways. And dare I ask what "2.1.24" kernel it was? That tree took ages to finally die.
> It's pretty hard to keep up with nowadays. It is apparently getting worse.
Actually, as of 2.4.2preN, the difference is much smaller than it used to be (>500kB). It's still missing critical things like IDE updates, but it's not as bad as before.
What SMP box do you have? The dual G4s work rather well, and the daystar boards are still being fixed up (they almost work rather stabily). Finally, Linux (2.2.18 and 2.4.N, from the right tree of course) can read/write HFS rather well. I wouldn't use my main volume, but i've had a 32mb partition on a few machines, and diskcheck (the apple util, I think thats the name but I'm not sure). hasn't found any errors.
The only problem here is that Cort (the maintainer for PPC) has been sending in patches since the late 2.3 days. Hell, 2.3.49ish or so was actually up to date. There wasn't too much work being done on PPC-specific things (because the main kernel was too buggy and liked to eat FS'). But as other people have said, if you're machine isn't x86, you shouldn't be using the "main" tree anyways. It's not Linus' fault or the maintainers fault. It just happens. It's also certainly not a "War".
And virtually all of those people are the hotshot intel developers. Almost never do I see a non-endian-clean patch from the MIPS or SPARC crowds. They're all from the i386/ia64 people. So if the kernel has an endianness problem you can bet good money where it came from. This is absolutely not the reason patches for (some) big-endian platforms get rejected.
And then they will have a bloated piece of shit, horribly out of date with the current kernel. Its not like there are a thousand people working on the Linux kernel at any one time...
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?
OSC, for one. NCSA, for another. Most of the larger vendors (IBM, HP, Dell, Compaq, SGI, etc.) have a few as well. Plus there's a software simulator from HP that lets you run IA64 programs (including the Linux kernel) on an IA32 box.
They exist, though admittedly only as engineering samples right now. But people do have them.
"My life's work has been to prompt others... and be forgotten." --Cyrano de Bergerac
NetBSD has already forked. Where do you think OpenBSD came from?
NetBSD: the cathedral vs the bizzare.
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 page really lays out the reasons I like NetBSD.
NetBSD: the cathedral vs the bizzare.
Ummm....so download the kernel patches.
Problem solved.
Or, as someone else here said, try NetBSD, though I can't say I've ever tried it myself.
Stating on Slashdot that I like cheese since 1997.
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?
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
"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.
- (c) 2018 Hank Zimmerman
Behind me over my left shoulder sits a NuBus based Power Mac 7100/80. Nothing Unix-like runs on it but MkLinux, as far as I've been able to determine, and that just doesn't seem like it's worth it.
"Of course it runs NetBSD (unless it's a Power Mac 7100/80)"
Ugh.
Zack Brown was laid off from Linuxcare :-( and
as such the kernel cousin lists have moved to
kt.zork.net
Right. And that's one reason why the PPC tree itself is maintained as a BitKeeper repository.
There's one fed from Linus official patches which is the "parent" of the linuxppc_2_4 tree which is our current "stable" tree. We also have a _2_5 tree with our "work in progress" things that will ultimately be rooted on Linus 2.5 when it comes to life.
Thanks Michel ;)
..
Actually, I _was_, I've been pretty lazy lately
Ben.
Well, I don't think important bug fixes are beeing ignored. And if they are, then you didn't spam us hard enough. There used to be few kernel developers (fortunately, that number is increasing) and even less who had knowledge of some of the badly (or un-) documented chipsets in macs, since I beleive your rants are about Apple HW.
The fbdev's are not broken. Maybe _some_ fbdevs have bugs, but that's an issue with the fbdev maintainers which are not the same as the kernel maintainers. A given person can hardly have knowledge of the entire set of hardware out there today.
The IDE init code is not broken AFAIK. If it is, please send me a detailed report. The only breakage I know with it so far are with some very odd portables with weird old hard disks that may timeout trying to detect the disk (no disk detected), and the usual breakage that happened regulary with CMD646 chips (broken hardware). AFAIK, only the first one remains and those rare affected users already know how to work around it.
The lost interrupts are a symptom of either a wrong bootloader or a too old kernel used on newer hardware.
I can't speak for the floppy driver as I hardly ever touched that beast, but it's definitely a very weird and sensible (and badnly or undocumented) chip that have some bizarre timing constraints. It works well on some machines. I don't think anybody ever posted a patch, and I at least don't own a machine with a floppy anymore to give it a try.
Serial port drivers suffered from HW bugs on some machines that have finally been worked around, and AFAIK, they are working now.
I don't either know what you call bells & whistles, but please don't underestimate the importance of a strong lower layer. The large variety of machines requires it.
Thanks ;)
The official 2.2.18 should work pretty fine on most boxes. I remember a few things slipped past 2.2.18 release and will be in official 2.2.19. However, there may be some SMP troubles with 2.2.x in general on SMP, I would suggest using a 2.4 for that.
For 3rd party IDE, There should be no problem with 2.4 provided that you enable support for the card's chipset when compiling the kernel. For 2.2, the reason is that most of these cards use chipsets not supported by plain 2.2 and Andre's big IDE patch for 2.2 lacks some stuffs for PPC. That's my fault, I did the fixes and never took the time to make the proper patches for Andre (it's a bit painful to make a patch of a patch).
Ben.
Sorry, I meant some 2.2.x SMP problems on PPC... looks like it's time for me to reach my bed.
Hrm... Where the hell did you see that we were changing a _lot_ of non-PPC specific code ?
In your dreams maybe ?
How do you feel bashing other people's work like this ?
Ben.
Heh, well, don't worry for my feeling s;)
/. was not a good idea at the very beginning ;)
The fact is that we always try to avoid as much as possible changing non PPC-specific code, and when such has to be done (like endian fixes), we usually separate this clearly and go thru the specific maintainers.
But I also think bringing this whole thing to
Ben.
I'll wager that LinuxPPC seats outnumber Linux Alpha seats.
I'm sure, but how about the # of _shelves_?
I'd _love_ to be able to afford a quick Alpha for workstation duty, but it'd be relatively easy (and apropos) to get one for server duty..
Your Working Boy,
- Otis (LICQ: 85110864)
Uh, I think this was meant to be sarcasm.
"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.
Log in or piss off.
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
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....
There's nothing in Linux to support architecture portability ? No hardware abstraction layer or the like ?
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
yes, but you have the better processor. Apple's current line of G3 and G4 processors are descendants of the 603. They were cheaper to build I guess.
Descendants of the 604 live in massively parallel supercomputers and no small number of RS6000 systems.
If you really want to be different, you could replace your Apple ROM with a PC BIOS and run WinNT 4.0 PPC. (though only to SP4 I think.) Or you could just stick with an older linux kernel. It's not like they go bad or anything.
Really? I could have sworn that OpenSHH was renamed ssh, and ssh renamed ssh-NON-FREE. Which, of course, was an improvement over previously, where ssh was called ssh2.
Je ne parle pas francais.
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.
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.
Your right to not believe: Americans United for Separation of Church and
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
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.
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.
excluding the fact that dell doesn't ship an athlon machine I mostly agree.
:)
You can really use the same argument against the P4.
If you wanto to just run linux you should buy x86.
But a lot of people either already own a ppc or want to continue to run mac-these people will use ppc. Also I would add on the workstation/enterprise level the situation is very different as x86 isn't even in the same league as power4. Off course tahts just an argument to use alpha
You seemed intent on making it a religious issue, though:
which rather detracts from any serious point you might have.
That said, I agree with what you're saying:
And that seems to be exactly what's already happened: the PPC folk maintain their own version of the kernel.
Actually, I think in many respects, people relying on free software have a better chance of getting what they really need, even without doing it themselves, than those who're dependent on large companies to fix things or add features.
I would phrase this as "Mac OS doesn't come with source code, and therefore wouldn't be as useful to me". "Evil" is nicely inflammatory shorthand for that.
Unfortunately, Open Source is a religion to many people
One could just as easily say "Unfortunately, [Mac OS | Windows | Java | Catholicism | etc] is a religion to many people". It's just an aspect of human nature, that some people lead the way and many others follow, with the followers often not completely understanding why they follow - they have delegated their decisions in certain areas to the leaders they are following. But it makes little sense to argue with a movement by arguing with follower-level positions like "x is evil". You have to get past that to more fundamental things - like the actual benefits of having access to the source code of the systems you use. Once you get to that, you might find that there are rational reasons not to use Mac OS, at least for those who know how to benefit from and leverage the availability of source code.
The argument I was making still applies in a broader sense. As far as Mac OS X goes, I guess it would come down to the Apple Public Source License vs. the GPL, which I assume may be what you were alluding to when you said "proprietary product". The same kind of rational reasons vs. religious reasons would apply in that case, but since I know nothing about the APSL, I'll leave it at that.
Incorrect. It's egcs 1.1.2.
GNU/Linux. The Freshmaker.
You seem to have confused `Linux' with `Linus'.
.|` Clouds cross the black moonlight,
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
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
I fail to see why this is so surprising. It became clear after the first year or so of ppc kernel development that Linus has no interest in the PowerPC platform. He has even stated publically that he has no such interest, and that x86 is the only architecture that matters to him.
Blaming this on the port maintainers shows how little you understand the PowerPC port. Traditionally, PowerPC port patches consist of either several small pieces, as you describe, or major chunks of code, or a combination of both. This is not because the maintainers are somehow stubborn or lazy. The size of a patch is only as large as it needs to be, which in some cases can be fairly large. Since Linus approves all source for the official tree, it's clear that PowerPC has, for the most part, escaped his notice. Again, he has stated in the past that he's not particularly interested in non-x86 architectures. Some might say this is because ppc is a marginal platform, but it is certainly less so than, say, Alpha...
There are a lot of people around now saying, "I'll try a Mac if it'll run Linux," which often translates to "I'll try it if it someone else does the work to make it run, and only then if I can grab the official source, specify a PowerPC target, and have a useful kernel." This has been possible only a handful of times in the history of the kernel, for some loose definition of useful.
Bottom line: Linux is open source, but it's far from being a portable kernel. If you need portability, use NetBSD. If you just gotta have that GPL... oh well. If there has to be a fork to support Linux on other hardware, who really cares? It doesn't matter. Certainly, the gap between a fork of Linux to support hardware is nothing compared to the gulf between, I don't know, MacOS and Windows. BSD can run most of the same software as Linux and vice versa. I don't understand the fuss over forking Linux.
The ppc kernel source is, let's see, *years* older than reiserfs. Mackerass and company have made considerable efforts to integrate smoothly. A mainstreaming of ppc kernel code was anticipated by 2.2 release. Yeah, right.
Again, it really doesn't matter much for those of us who actually *use* ppc linux, but the simple fact is, Linux is written for x86. That's not going to change until x86 stops being the majority architecture. x86 people generally do not care about any other architectures, and Linus is definitely an x86 person. People who care about platform-independent code should look at NetBSD. Platform independence is not going to come from Linus.
I'm almost certain NetBSD handles this... at least there is a package called [award for the longest package name, btw:] airportbasestationconfig
-- Colin
It basically gives you a 20 second break whenever you open one of your MacOS 9 apps. I love it!
The compatibility environment only launches once per session, thank you.
- Scott
--
Scott Stevenson
WildTofu
Scott Stevenson
Tree House Ideas
Have you seen the system requirements for it?
The recommended physical RAM is 128MB. The reason for this is that the classic environment (to run non-native OS9 apps) is a major resource hog. If you're only going to be running Carbon, Cocoa, Java and BSD apps, then you can probably get away with 64MB.
all for eye-candy.
All the graphics engine is vectorized. The eye candy aspect of the visuals doesn't have much do at all with the recommended memory.
- Scott
--
Scott Stevenson
WildTofu
Scott Stevenson
Tree House Ideas
It is mentioned in the kernel-traffic FAQ that if you send patches to Linus, don't expect a response regardless of whether or not he puts it in... especially since the 'option 3' stuff is fairly neatly spelled out in the FAQs about patches.
--
"It's tough to be bilingual when you get hit in the head."
Because the kernel is getting so large to maintain, it is quite difficult to keep a handle of all the changes in the system, to make sure that the code segments are adequate for release. If Linus does not think the code is soundly developed, he will not apply it to the kernel. There are tons of patches to the kernel that have nothing to do with the architecture, but the instability or design incompatabilities with them.
The PPC port of linux may have suffered the same fate as the ARM port. The ARM port is very diffferent from the baseline kernel. Despite the fact that nothting will 'break' having it there, it still makes the kernel messier because of the differences how they were developed.
Also, the ARM port allows new features that are not exactly stable, but puts them in if nothing serious breaks. This is not quite mainstream kernel acceptable, but to the ARM developers that use it, they can get a big boost. That is why they are patches.
Bye!
You know, if you're going to troll, AND abuse your +2 bonus on it, you could do a better job than that.
siri
Try NetBSD, ti runs really well on those 68k mac's. I even got X windows to run on my Mac IIci, the only issue I had was the installer was v ... e ... r ... r ... y slow.
Other than that it worked great.
Every rule has an exception, and this is the only rule with no exceptions! Huh? -- Spatch
Every rule has an exception, and this is the only rule with no exceptions! Huh? -- Spatch
Mod this guys post up! This is a very good example of how people need to post patches to Linus! Maybe this guys post needs to be eamiled to Paul Mackerras!
Every rule has an exception, and this is the only rule with no exceptions! Huh? -- Spatch
Every rule has an exception, and this is the only rule with no exceptions! Huh? -- Spatch
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..)
perl -e 'fork||print for split//,"hahahaha"'
Nah. Let them continue with HURD. If the HURD gets done right, it will kick Linux's bottom in the long run.
--------
Genius dies of the same blow that destroys liberty.
I switched after about RedHat 5.2, and I'll never go back (though I might roll my own distro sometime). Debian has some glitches about it too (like only releasing a "stable" version every year or so), but I think it's still a lot more well-done than RH has been.
I recently ran a RH7.0 system, and I have to say I still prefer Debian.
--------
Genius dies of the same blow that destroys liberty.
Maybe (not usually, I don't think), but I think most Debian users just roll their own debs from a tarball from kernel.org.
--------
Genius dies of the same blow that destroys liberty.
Now don't go ripping on the Timex Sinclair! If the good people at Banana ever get it together and send me that extra 64k memory expansion I ordered 10 years ago, I'm going to resume trying to set up my Timex Beowulf cluster!
meh.
Why risk removing this extra peer review?
Good idea, because god knows that Richard Stallman and the Free Software Foundation are far more open and accomidating than Linus Torvalds.
Oh, wait..
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******************
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].
huh? arch endianess has NOTHING to do with patches being rejected. that doesn't even make sense.
Paul Mackerras maintainer of the PPC kernel and his response was quite interesting
/.? :) 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.
I wonder if Paul Mackerras knew his response was going to be put up on
-Moondog
AFAIK the open BSD variants were started 2 years after Linux
Really?
BSD started out in late 1977 as a kit of additional software and patches to AT&T's UNIX version 6. The source was aviable and open to anyone who had the proper AT&T License.
Given you have a linux POV, perhaps this link would be of help in educating you.
it could be argued that they wouldn't have taken off without Linux as an example that it can be done.
And making that argument might fly with blind "the world is Linux" zealots, but the reality is Linux is based on Minix, and BSD's roots go back to 1977.
But now that you have been educated, you won't make that mistake, will you?
If it was said on slashdot, it MUST be true!
You blind BSD zealots might not like it, but the reality is, Linux was real open software while BSD was still a set of patches to a proprietary OS.
A set of patches?
What AT&T release ran on VAXen? Or Sun i386 boxes? Or the 300 series HP's?
Minix wasn't based on Unix at all,
Minix was a clone. To the best of anyone's knowledge, no AT&T code was harmed in the making of Minix.
If it was said on slashdot, it MUST be true!
most of the people reading this would still be using Windoze.
Really?
BSD is an Open Source OS. Works like GNU/linux and in fact some say it works BETTER.
To make such a statement, you must not have known that BSD based open source OSes exist.
If it was said on slashdot, it MUST be true!
I too would like to express my thanks to you and the others who have contributed to giving my StarMax a new life. Thank you! :)
- Sig
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"
Higher Logics: where programming meets science.
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.
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.
Stop over-analyzing your analizations
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.
------- "One of the joys of travel is visiting new towns and meeting new people." -- G. KHAN
Well, AFAIK the open BSD variants were started 2 years after Linux; it could be argued that they wouldn't have taken off without Linux as an example that it can be done.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Which cost an arm and a leg, and pretty much removed all "opnenness".
And making that argument might fly with blind "the world is Linux" zealots, but the reality is Linux is based on Minix, and BSD's roots go back to 1977.
Yeah, and Minix wasn't based on Unix at all, sure. You blind BSD zealots might not like it, but the reality is, Linux was real open software while BSD was still a set of patches to a proprietary OS.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Heh, actualy, I always use the PPC bk tree, even for my x86 machines.
why? for one thing, it's in bk so there is revision control, I can know what has changed at a glance. Linus has just started to make release notes, under pressure.
and it works on my iMac DV too.
and it also work on my Tosh.
and it's updated dayly with either Linus OR Alan patch sets (if we get dry on patches from Linus).
So, I consider it a nice branch!
Huh, actualy, Ben is one of the main contributor to the PPC tree, he usualy is the first to get anything running on any new box that comes out. :-)
Heck, that #&#&$ always gets the brand new toys before any of us does!
Check the Credits file, and if you are in there, you might start having a discussion about Ben's right to comment on the patches he contributes to.
Because, he *knows* what is in them. You don't.
I'll second that magical syncing of the PPC patches into the offical tree. You'll find my fuel for that below. I would say that the info in the comments is very informative including the kernel traffic stuff, and I would say that Alan Cox more than likly had something to do with this and probably keeps his tree updated as suggested.
My whole point with writing the article in the first place was that It has been since 2.2.17 since I have been able to compile a kernel from the offical source tree, and that is an awful long time to wait for the "all new and improved" stuff in the 2.4.X tree. Most LinuxPPC users are left to the precompiled kernels that their distro sets out for them. The acceptance issue comes into play here where I belive man PPC linux users would like to know that they aren't being left out in the cold by the community as a whole, and have to rely on just a few solid resouces out there. It's Linux, and I'll pull a Shakespeare here i386 or PPC, what's in a processor/name?
Moderating to further my personal world domination agenda... and to get chicks.
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.
"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.
Try Hurd if you are looking for a different kernel.
I think you hit the nail on the head there. That was basically what I was thinking, someone has already done it. You have to stop and ask yourself if the new is better than the old or not. Too many times people jump for the different without trying to work out the issues with what they already have. If you don't fix the issues, you will run into them all over again.
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.
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.
Maybe I just got lucky, picking a couple drives at random from these sites? Maybe a "Contact Start Stop" is different from Maxtor's new 50000 "on/off cycles" ??
I tried to look up the similar spec for my little Hitachi DK23AA-12 laptop drive, which I've abused in so many ways while working my my little homebrew mp3 player (ok, shameless plug)... but Hitachi doesn't seem to have a spec about the number of times you can start/stop the drive. Just for one last try, I pulled up one of IBM's laptop drives, the Travelstart 20GN (page also covers larger models), and they have a spec of 300000 "Load/unload cycles". I wonder if a "load/unload cycle" is similar to a "contact start stop".
Sometimes I wonder if hard drive specs (other than formatted capacity) really mean much anyways.
PJRC: Electronic Projects, 8051 Microcontroller Tools
Slight correction...
2.The platform isn't as popular, so maintaining
the ppc tree at the expense of the x86 one would
be ludicrous.
PPC is still king in the embedded world. That's why Motorola
can offer PPC chips at commodity prices -- the volume
is there. Now Apple popularity is a different matter...
Dial 1-800-GOOD-SIG to find out what should be here.
point well taken
I thought the kernel was GPL software
The GPL is just a license, not a deed. Linux IS Linus's.
If I want to use it, I to ask him to use it
By releasing it under the GPL, he has given us permission to use it freely.
*NOBODY* expects the Spanish Inquisition
The Knights Templar did actually
---
This
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
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
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...
The m68k-forked CVS tree seems to be much better. I applaud your efforts. SONIC support would be nice :D But alas, I appear to be losing my development box, and I couldn't get serial console support to work (even after building my own kernel containing it) so I couldn't even provide any debug messages, making it hard to figure out what's going wrong with my kernel.
If I don't lose my dev box, I'll do what I can.
--
ALL YOUR KARMA ARE BELONG TO US
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Try compiling a kernel for ANY m68k architecture. You can't do it. This worked back in 2.2, but now in 2.4.1 (supposedly a stable kernel) you can't actually build a m68k kernel from the 2.4.1 sources. I actually disabled all my drivers, input support and so on, and STILL couldn't build one.
What I want to know is, how does one justify actually BREAKING support for AN ENTIRE CPU ARCHITECTURE and then still releasing as a "stable" release? x86 is on its way out, even if the replacement is just going to be another crappy intel architecture. Soon, the only people making x86 chips will be Cyrix... Or have they died, finally? I should swear they were still making MediaGX chips. So treating x86 as the only important architecture in linux (although I suspect IA64 support works too) is a mistake, because soon x86 will be another unexciting architecture which gets relegated to the same status as the PPC or m68k support.
--
ALL YOUR KARMA ARE BELONG TO US
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Well, a 604e _may_ work on BeOS: http://www.be.com/support/guides/beosreadylist_ppc .html
The proper way to put this would be "... bitches about the government and isn't politically active."
If you feel like you haven't been given a reasonable choice in an election, you certainly don't have to vote -- and you haven't given up the right, IMHO, to bitch about the government to whom you pay taxes. The right to govern is granted by consent of the governed; those who pay taxes and those who do not.
In fact, I think starting a discussion on a political point (aka, "bitching") is in many ways more productive and more politically active than simply pulling a lever every four years to pick the party your pappy voted for.
If it ain't broke, it doesn't have enough features yet.
[I]s it truly possible to avoid having the linux kernel end up forking somehwhere along the line?
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.
The "major code changes [that] IBM is doing" are platform support, not kernel-forking, are entirely contained within the approved architecture-variant directories (linux/arch/s390 and linux/drivers/s390) and are being integrated into Linus' kernel as fast as humanly possible. Alan Cox's 2.2 kernels have been incorporating those changes molto rapido since 2.2.1. The IBM System/390 kernel patch gets smaller with each new kernel level as a result. If anything, the s390 support in Linus' kernel is better than the PPC support, and that appears to be entirely the result of the IBM programmers following Linus' preferences for code modification.
I know the PPC kernel effectively forked a "long" time ago, and that there's bad feeling in the PPC camp (see KernelTraffic for the easy-to-follow version of the fights), but it doesn't have to be that way. Linus controls the One True Source (TM), and if you want him to accept patches you have to work within his rules.
Except that from the sound of it, he is dismissing these patches without indicating why he is dismissing them. Further, it sounds like ALL patches for PPC are being dismissed, without regard to size.
IANAL... But I play one on
...another case of poor PPC support that is the result of it's lack of sufficient market share to generate interest. I hate to say it (as a PPC/Mac fan) but I'm not sure the OSX "threat" is really viewed seriously enough to enicite a 'kernel war'. ;)
One can always hope though
The GPL does *not* place something in the public domain. The kernel *does* belong to Linus just as every piece of software under the GPL belongs to whoever places it under the GPL. Of course you can fork it the GPL gives you that right but Linus does own the code. In fact the whole concept of the GPL is based on the idea of copyright law it just happens to be a sane implementation of copyright law. Don't worry about it many people don't understand this. Here is a thought get a copy of the GPL and read it. It will make these things much easier for you to understand.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
Don't worry about it - you'll have OS X in about six weeks.
A message from our sponsor
Is there something more 'between-the-lines' here?
Perhaps Linus has had a few calls from Apple, saying - 'Look, we're about to launch our Unix-like OS for our Macs, and your Linux OS is taking a large chunk of the market we're looking at....whaddayousay we give you $lots of dollars, and you forget about PPC compatibility?"
Spooky, huh?
--
jambo
system.admin.without.a.clue
-- js.
wow, that was good. I don't think there was any way at all of not getting hit by that.
-- the most controversial site on the Web
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.
If you don't have anything nice to say, say it often.
- Ed the Sock
Most of whom were compensated with cash and perhaps stock, thus fulfilling Gates' obligation.
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.
BFD
So does Slackware.
my sig's at the bottom of the page.
if you look at the most recent changelog for 2.4.1 you'll see PPC patches among the changes.
u suck arse
---------------
100% Australian
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.
What?!? Be left the PPC platform! Oh no, the PPC is doomed now!
There's a port of LinuxPPC to the NuBus macs at http://nubus-pmac.sourceforge.net/. Runs pretty well on my 8100/100. Much faster than MkLinux. It does have some issues regarding the detection of the available memory, but with the help of the memory reporting utility and passing the appropriate settings to the kernel in BootX, it works.
I hadn't known there were so many idiots in the world until I started using the Internet -Stanislaw Lem
Don't post on slashdot anymore pal. This site is for people with brains in their heads, not prejudism in their heart.
You must be new...
Yeah, but he's obviously learning quickly.
Prejudism?
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!
Better the pride that resides in a Citizen of the world, than the pride that divides when a colourful rag is unfurled
If you are unhappy with Linus ignoring Linux PPC or believe that he is ignoring Linux PPC, or whatever, try NetBSD PPC.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
Darwin mainly uses Open Firmware to get the device tree. The MkLinux BootX app passes the device tree in it's own data structure (passing it to the kernel by storing the pointer to it in r4). One could edit the MkLinux BootX app (which is GPLed) to load a >4MB Mach-O kernel instead of a 2MB ELF binary, then edit the start.s mach source file in Darwin to handle the new device tree.
MkLinux will also be useful for NuBus drivers and 601 support.
---
>80 column hard wrapped e-mail is not a sign of intelligent
>80 column hard wrapped e-mail is not a sign of intelligent
>life
Using Linux for multimedia? Give me a BREAK!
Apple will release the audio and graphics IOKit classes soon enough. Until then Darwin makes a great server with a very stable version of XFree86 4.0.2. There is also a LD compatibility library in the works so porting applications won't be a hassle.
As it is now Darwin has superior USB, and will soon have superior firewire, MIDI, audio, networking, and PPC optimizations than Linux ever will.
So choke on that multimedia biscuit
---
>80 column hard wrapped e-mail is not a sign of intelligent
>80 column hard wrapped e-mail is not a sign of intelligent
>life
Youch.
I'm sure glad I thought different.
Can't say much about this -- apologies for being so mysterious -- but Linus' stubborn refusal to go for modern threads means that a certain group is actively extending a few core data structures and the scheduler to support a many-to-many threading model. Hint: these are people who've built this kind of thing before....
I had the same problem trying to compile 2.4.1 for my TRS-80!!! How irresponsible of Linus to release this information into the public domain without testing it on my platform! I think I'll bitch to Slashdot about it. It's probably part of Microsoft's secret conspiracy to dethrone the TRS-80 as the true heir to computer supremacy!!!
+5:offtopic,but anti-American
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."
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
The post was about the 2.4.1 kernel. I can get it to build but (IMHO) it dosen't appear to be as stable as the 2.4.0. Isn't that usually the case having the .0 kernel be more stable than the .1 up until about .5 ?
This sig intentionally left blank.
Linus also owns the trade-mark. No matter how much you contribute, you'll never own any part of the trade-mark. Which is as it should be. After all, if it wasn't for Linus, most of the people reading this would still be using Windoze.
"I might have made a tactical error in not going to a physician for 20 years." -- Warren Zevon
You are one more reason why /. needs to solve the Moron Problem.
i dont know
but am i the only one feeling jealous !!
sheep for the sheep human for the human i just wonna keep my soul alive
There's a known problem with 2.4.x and sun4c sparclinux users. The problem was first mentioned here. Basically the kernel cannot correctly map esp's dvma. I got a one line solution from uzi @ #sparc @ irc.openprojects.net .
Here it is:
edit arch/sparc/mm/sun4c.c
go down to sun4c_mapioaddr()
after the "unsigned long page_entry;", add:
if (!(physaddr & 0x0f000000)) physaddr |= 0x08000000;
That should get you booting.
Why not migrate your Linux/PPC boxen to the powerpc port of OpenBSD?
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.
"RISC architecture has outperformed the usual CISC for years now..." Oh really? Expect on the really high end stuff, explain?
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.
Chris Kuivenhoven is a thief, beware
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.
The global economy is a great thing until you feel it locally.
#define HOURS_IN_DAY 24 /* give Linus a break! */
Have I missed a decade or something? ;-) x96???
Not that it's a problem, I'd just like to know... ;-)
Linus' chain of thought at this case:
Me Linus.
Me Human (probably).
Me need food.
Me need to buy food.
Me need money to buy food.
Me work for Transmeta to get money.
Me work on Linux for no money.
Me have to choose, Transmeta or Linux.
Me need money for food, Transmeta pays, Linux doesn't.
Me kicks Linux out of the door.
--
Two witches watched two watches.
Which witch watched which watch?
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.
--
--
I Hit the Karma Cap, and All I Got Was This Lousy
If you want a Unix system to fiddle with, install NetBSD on your old Quadra (or your SE/30 for that matter). Or go out and buy a cheap second-hand Pentium box. Then you can keep your regular OS on your 'main' computer.
You said 'CVS' in a discussion of the Linux kernel, on Slashdot.
You lose three turns. Proceed to 'Go' and do not collect $200.
I can ship you a handful of Z80 chips if you're really interested.
Maybe you could make a massively parallel Z80 box of some sort. If you did a really good job it could be as powerful as a 386 chip.
Word! Nice one
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
It is better to be feared than loved
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
--Kara
Before you ask, I already have a boyfriend and he's more of a man than you'll ever be.
Like Linux is the only open source project, or the only way to organize one: http://www.netbsd.org/Ports/macppc/models.html
I can confirm the same problem with 2.4 kernel compilation on: 1) Sun UltraSparc 5s 2) Alpha Linux on UP-1000 Is it 64bit issue?
Point being? If the world is 95% MS, wouldn't it be a good idea to know how to use it, or improve it? Your lack of scope is humorous.
After reading all these little cries, complaints and statements I am wondering... Is anything being done about it? Are the fixes being added? Are any improvements being made? I just want this to work. Will it, and when?
There isn't much like the scent of a fresh harddisk
51. Linus, this patch fixes an assumption in the Frangle Hypercube driver that made it crash on PPC.
If only it were that easy... Unsaid in the line was: (oh, and by the way Linus.. it fixes the Frangle Hypercube driver, but in the process breaks the Froptle Metacube support... but neither you and I have one to test on, so just apply it and pray).
One simple patch can maytimes break other things in the process. Who does the QA testing? If I send him 50 lines of code to the VM system and say "this fixes bug X" is he just supposed to apply it?
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.
You can't just compare OSes willy-nilly. You can compare them for a specific task, but you aren't doing that.
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
If your feelings are so brittle that what I wrote felt like an attack, then you probably should run, not walk away from trying to get code integrated into the "official" kernel, as the normal course of discussions involves vastly stronger wording than I ever use...
If you're not part of the solution, you're part of the precipitate.
NT4 used to ship on x86, Alpha, MIPS and PPC. There was even a SPARC port at one point, although it was abandoned. Initial NT development was, IIRC, on the Intel i960. But with the low-end MIPS market shrinking, CHRP cancelled (due to an IBM/Motorola/Apple turf war) and x86 pretty much dominating the low-to-mid range workstation and server markets (by market share) that's where Microsoft are focussing their development efforts. It's not worth porting to SPARC because almost no-one buys SPARCs unless they also want Solaris, and similarly there's no market for PPCs that don't run AIX or MacOS.
I'm sorry, but you can't slate MS here - they tried to ship an architecture neutral OS and no-one wanted it!
That makes no sense when its a platform patch. If I port the kernel to chip 'XYZ', do I submit 1k 10k patches, each labeled, "Adds code to handle XYZ chip"?
-- I'm the root of all that's evil, but you can call me cookie..
Throwing stones can invalidate your greenhouse's warranty.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Besides, he said he didn't think he -could- do better. It's up to you how you interpret W2K in that light.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
Engineering and the Ultimate
I don't understand your question. There are several points here:
1) the kernel _is_ the hardware abstraction
2) some things (notably drivers and VM) are abstracted as well
However, every tree needs tweaks/testing/changes
Does that answer your question?
Engineering and the Ultimate
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
Engineering and the Ultimate
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).
Engineering and the Ultimate
... 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.
I believe the hangup is not the line count of the patches, but how many topics they cover. When one patch touches a lot of different areas, it's hard to tell exactly what it does, it's impossible to back out just part in case something fails, and there's more potential for conflict with other patches.
Linus has mde it pretty clear he wants one patch for one problem, not one patch for many problems.
--
Infuriate left and right
I have a UDB too, what distro are you using? Are you using an internal or external drive?? email me back
"Linus shouldn't be "reviewing" anything."
nonsense. it's his source tree, he can (and does) review anything that gets submitted to him. bitching and moaning about how "he can't do that!" is the least productive way to respond.
when faced with a rejection from linus, you have two options: suck it down and do as the man says, or fork off your own tree.
it's obvious which path the linuxppc folks took.
--
> but you can't slate MS here - they tried to ship an architecture neutral OS and no-one wanted it!
I was responding to someone's claim that Open Source doesn't work as well as commercial software. They claimed that MicroSoft would never fail to support some hardware because they'd loose money if they did. The whole story here, of course, is that Linux must be failing because Linus hasn't updated the 2.4 kernel for PPC. If "commercial" is better because it supports more hardware, you'd think that it would at least support the hardware that the entire article was complaining about.
I didn't realize that NT ever worked on PPC. No one seems to care. If it no longer works on PPC, of course, you're SOL because you can't do it yourself (the way the PPC folks did for Linux).
> It's not worth porting to SPARC because almost no-one buys SPARCs unless they also want Solaris
Yet Linux was ported there.
> and similarly there's no market for PPCs that don't run AIX or MacOS.
The whole article was about someone wanting Linux for PPC, so there must be *some* sort of market for alternative OSes. I guess just not Windows...
-- Don't Tase me, bro!
Ahh, so we should all keep to using whatever compiler happens to compile the kernel, no matter how old it is. After all, we wouldn't want to give the kernel developers any incentive to clean up their code so it compiles properly with a newer, better optimizing, more standards compliant compiler.
I don't think Redhat was in the least bit disingenuous by calling the compiler that could compile the kernel 'kgcc'.
As for whether or not they should released a snapshopt of gcc... Well, I question the wisdom of that too. I would point at that almost all (maybe all?) of the (very few) bugs that caused bad code to be generated were in the C++ front end, not in C, which is the language most things depend on anyway.
Need a Python, C++, Unix, Linux develop
If you don't recognize the benefits of having access to the source code for the software platform(s) on which you or your company depend, you either aren't a developer or CTO, or else you haven't really thought it through yet. Religion has nothing to do with it. The religious ones are just those who are following the smart ones, because they recognize that they're onto something important, something that liberates them from being at the mercy of large software companies with private agendas that don't put the interests of their customers first.
That depends. You might know people who can hack the source code, or the existence of a larger community of source code hackers may help you get what you want. That's one of the benefits of Linux, even notwithstanding some of its shortcomings: its popularity means that it now fits a staggering variety of applications, from diskette-based routers to massively parallel supercomputers, just to take one measure of its breadth. Sure, there are always exceptions, things that it doesn't do well, and any user has to evaluate their requirements and choose what's most appropriate for them.
["Evil" is] a simple expression of the fact that the core Free Software movement considers commercial software to be morally wrong. See Richard Stallman's essay on the subject.
I'm not an expert on Stallman's position, but I don't see this in the essay you referenced. He doesn't actually use the word "evil" in the essay, and the strongest adjective I could find applied to proprietary software was that it is "harmful". His only use of the word "moral" is related to the moral obligation of users to pay developers for their efforts.
Stallman's objection is to software for which the source code is not available - not necessarily "commercial" software but rather "proprietary" software. His position is based entirely on what I've been saying about proprietary software: "...doesn't come with source code, and therefore wouldn't be as useful to [users]".
This pragmatic and fairly uncontroversial observation forms the basis for Stallman's other claims. Whether you agree with his conclusions or not, the underlying premise remains valid, and has nothing to do with good or evil: instead, it's eminently practical - all things being equal, open source is better than closed source, for the user. No religion necessary.
This was the same situation with the IRDA susbsystem as detailed in this Kernel Traffic 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.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
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
Remember Amalek.
-jon
Remember Amalek.
Since I lack an Ethernet card for the SE/30, it's not exactly a network-friendly computer. Dang cards (required for Apple's custom SE/30 slot) still cost more money than I'd consider paying for one, too.
-jon
Remember Amalek.
LinuxPPC is not a tenth as usable as Mac OS, much less Mac OS X. Linux bigots aside, the GUI isn't as good, the applications aren't as good or as plentiful, and the hardware support (where's my Software Base Station support in LinuxPPC? For those who don't know, it lets a Mac with an AirPort card work as an 802.11b base station, complete with WEP, MAC restrictions, etc.) is poor.
NetBSD and Darwin are kissin' cousins, so it doesn't seem worthwhile to use NetBSD if I want Unix. I might as well go with Mac OS X.
-jon
Remember Amalek.
Slackware ships with a stock Linus kernel... It's one reason a switch from **cough**, because I never knew what I was getting.
A Government Is a Body of People, Usually Notably Ungoverned
Shipping something of quality was exactly what they tried to do. The problem was that the gcc maintainers had not released anything for over a year. gcc 2.95.2 was broken with regards to lots of stuff, most notably C++ and Alpha stuff, for which many fixes had existed for a long time in cvs.
So what Red Hat did was to debug and polish a release snapshot with all these fixes, to ensure a quality compiler.
And with the 2.96-69 update, it's probably the best gcc compiler you can get.
GNU/Linux. The Freshmaker.
Fine, yeah, I agree.
You have to admit though, Dell giving in and selling AMD machines would be a big story!
That's very interesting, since I never heard of Dell selling Athlons before. Do you mean Pentium 4?
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...
LOAD "SIG",8,1
LOADING...
READY.
RUN
Basically what all this means is that I use Linux on a PPC machine every day. It's an indespensible tool for me. I couldn't do my job without it. Keeping up with the latest greatest kernel is something I have to do at times. For me, I really don't mind rsyncing the Paul's latest source (I don't really like bk). It is annoying to have to explain to someone why they (or I) can't just use the official Linus kernel. Granted, it is a pain. It's a pain not having an "official" 2.4.1 tarball that works on PPC machines. I would love it if you guys could roll a final version of 2.2.18, tarball it, and leave it be. I understand that the bug fixing process is neverending but there never seems to be an end to it, or an official release. Sure I could snag the latest pmac-stable but that's not a complete release. That's not the final 2.2.18. That's a little annoyance for me personally.
Another annoyance for me is that I can't find a 3rd-party IDE controller that will work in my machines. The onboard Apple controller will work but none of the 3rd-party controllers seem to. 3rd-party SCSI driver support is also sketchy. Having that would be a big boon for me.
I don't want this to sound like I'm nit-picking. I'm not a kernel hacker myself. I do a nominal amount of programming, that's it. You guys do a great job and don't really get much for it. These are just a couple of thing I've noticed and wouldn't mind seeing changed. Keep up the great work!
--Justin
--
The next time I reinstall Linux I think I'll install Debian instead of RedHat. I've stuck with RH because of habit, but RH7 really convinced me to switch. kgcc, plus shipping a frickin SNAPSHOT of gcc - are they on crack? If you can't release something of good quality, don't do a release at all.
But only the BSD people adopt such a closed model, right?
(8-DCS)
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
God Fucking Damnit
1. Linus, this patch fixes the "glooble" function which makes a bad endian assumption.
2. Linus, this patch addes the magic number for ppc to the magic numbers for X86, alpha, and m68k in the "toto" function.
3. Linus, this patch fixes a typo in the momark function that prevents it from working on ppc.
.......
51. Linus, this patch fixes an assumption in the Frangle Hypercube driver that made it crash on PPC.
--
You don't need a weatherman to know which way the wind blows.
>Yeah, I'm going to spend 50% more on a laptop b/c it looks cool and runs a POS non-multithreaded OS? Sure..
Uh, how is LinuxPPC a POS non-multithreading OS?
>I bet it really screams at Q3 and compiling the kernel. I hope you still like your 350Mhz imac in 2 years, when everyone else has 2Ghz machines. At least you can say it looks cool!
Performance is good compared to x86 machines of equivalent spec - outfit a P2-450 with a crappy Rage Pro or whatever the rev. B iMacs have and watch it crawl with Q3.
I don't dispute the fact that your 1GHz machine is fast, sorry to make you feel like less of a man.
I just think your notion that dropping support for every platform except x86 because its the cheapest is laughable, stupid and obviously the wrong thing to do.
I gots ta ding a ding dang my dang a long ling long
What if you already have a Mac on your desk?
You think it's cheaper to throw it away and go out and buy a new 1GHz Athlon than to run LinuxPPC on your existing machine??
Try getting a laptop that looks anywhere near as cool at a Titanium Powerbook G4 from any x86 vendor.
'Oh forget it, those guys don't need another OS. If you buy a Mac, you don't deserve Linux. Linux should only be available for x86 because its the cheapest' - is that your line of reasoning?
Should we just deep-six the Alpha, PPC, MIPS, SHx, 68k ports of Linux because Athlons are cheap right now.
You better tell the NetBSD guys they've been wasting their time, and how bout you email the CEO of Lineo and all the other embedded Linux developers and break the news to them.
And while you're at it, why don't you have Linus ditch support for Intel chips. Athlons are, after all, cheaper.
My 350 MHz iMac makes a great Linux workstation. It doesn't take up too much room on my desk, is easily transportable - without making two trips (one for sys unit etc, one for monitor) every time i want to move it somewhere, and it runs extremely snappily.
I have been very happy with it, and you sir, are a f*cking idiot.
I gots ta ding a ding dang my dang a long ling long
IMHO, there are much cleaner ways of doing it than Red Hat's hack. Regardless, you cannot defend Red Hat's bad decisions in package policy by placing the blame on the Kernel developers. They didn't write the spec file. They didn't mislead the users.
--
assert(expired(knowledge));
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.)
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.
"The Linux kernel belongs to Linus."
/. post, if the LinuxPPC people feel abandoned, they should be the ones working for support on their hardware, not simply sitting around and asking Linus to do it.
What? Silly me, I thought the kernel was GPL software. Imagine my disillusionment, I though that "Information wants to be free."
I never said it wasn't. In fact, I was referring to *his particular tree*, since that is the base issue of this whole slashdot thread anyway. It ought to have been implied, but I guess I should make such things more clear next time.
Anothing thing that I [failingly] implied was the existance of the GPL itself. What does one do if they have an uber-patch that increases kernel speed by 1400% but Linus won't accept it because he doesn't like the commenting style? You fork it. Or you just release your patch anyway, like the Reiser team did.
Apparently I have this all wrong - the kernel belongs to Linus. If I want to use it, I to ask him to use it.
You aren't going to make much of a point by emulating an extreme that is far detatched from the issue.
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.
That's just what I said! But you can GPL it all day long and you'll *never* change the fact that he is the only one that has the final say in what goes in it.
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.
I agree completely. It will be neccessary eventually.
Competition encourages development, and if you add GPL to the mix, the competition benifits everyone.
The GPL was never in question. I am just fairly tired of people saying what Linus *ought* to do with the kernel he maintains. In particular relevance to this
Since Linus really has the final say on what goes in or remains left out, is it time to go to a more Republic-like model? Most people will freak out at this thought but I think its way past due for Linux. ulinux has different ideas than SparcLinux and AlphaLinux which is different from BettyLinux and BarneyLinux (me obscure? never!) A core team or core group could hold the reigns a bit more.
Ok, I'm going to make the charitable assumption that you are intelligent, but English isn't your native tongue. So, here's a free clue: the article you replied to was Sarcasm. Sarcasm is a type of humour and rhetorical device where you make a point by stating the point's anti-thesis in such a way to show that the anti-thesis is ridiculous and beyond believability.
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
. We've got computers, we're tapping phone lines, you know that ain't allowed - Talking Heads, "Life During Wartime"
Project axed, but he OS is sort of still out there, check any NT Workstation 4.0 CD, there's a "Ppc" arch directory. Not that I know if it even functions, or even if I care, I'm not a winfreak, that's why I went with PPC in the first place.
Moderating to further my personal world domination agenda... and to get chicks.
So because of the competition, Linus decides not to make a competing product... That's marketing.
Ext3fs, Tux2fs are still waiting for merge. 2.4.1 was nothing more than 2.4.0 with Reiserfs merged in. You can't merge too much at the same time, that's the policy that makes you deserve the keyword "stable".
I don't know how all the kernel folks manage to exchange parts of these different trees each time and keep an overview of what they're doing, but I guess that's they way things go at the kernel. Until stuff can merge it has to wait in a custom kernel source tree. 2.4 is still very young so there must be a lot of stuff in wait. Linus said he would for now not make much big changes in order to maintain stability. People said the inclusion of Reiserfs in 2.4.1 was a miracle because of that.
So I guess the real reason is that the PowerPC folks are just bad at sweet-talking Linus. They don't have to feel ashamed about that: as far as I can tell, it's a real skill an sich.
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Hey BenH - if you know and can tell us, why did Apple yank the ppclinux.apple.com site, and your page along with it?
just curious... and a big thanks for all the great work on linux-ppc!
----
Free yourself. Everything else will follow.
How much is this royalty and where's the URL to prove it?
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).
/. users...), then you already know how to get a kernel or apply a patch.
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
So what's the problem?
Can You Say Linux? I Knew That You Could.
Don't leap into a religous lecture unless it's a religious issue. It's not important whether or not I buy into the open source model. What's important is that people who choose to use Open Source products understand the consequences.
Since we don't pay Linus to maintain the kernel for us, what obligation does he have to maintain it any way but his own? If it's important to anyone that the kernel have more PPC features than Linus is willing to include, they're free to start their own branch. The same goes for any other open source product.
The whole Open Source thing relies on people with a "Lead, Follow, or Get Out of the Way" mentality. If you say, "I want X to happen, but I want somebody else to take responsibility for it," you're thinking in terms of commercial software, no matter how many RMS mantras you recite.
__________________
__________________
That hardly applies to developers who are moving from Linux to Mac OS because of features missing from Linux. If you're not prepared to hack the source code, what's the point in having it?
"Evil" is nicely inflammatory shorthand for that.
No it's not. It's a simple expression of the fact that the core Free Software movement considers commercial software to be morally wrong. See Richard Stallman's essay on the subject.
__________________
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.
__________________
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.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
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.
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.
--- I used to moderate, then I read the -1 articles and decided having to filter through them was not worth it.
it'd be appreciated if that vulnerability hole was closed.
we all want that hole closed, man! believe me...
i wish i was but oh well
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.
--
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
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
"All your base are belong to this file I send in order to have your advice."
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.
Read the rest of this comment...
As someone who actually works on the PPC kernel, I do admit that there are bugs, but the other side of the coin is that hardly anyone reports these things. The developers only have a finite number of machines, and can only test what they have.
But anyways, frambuffers are working well (with an occasional problem on the wierder ATIs, or some of the undocumented apple controllers.) Serial was broken once upon a time, but that's been fixed for ages (and even made it into Linus' tree in 2.4.2pre2). I assume you're referring to "standard" IDE cards which work in 2.4. Patches do indeed get ignored, but again there's more people trying to keep track of things now.
As for the rewrites you mention, I know some of the recent ones have been so that new machines can be used and maintained sanely.
Unfortunately, it has sat in "ready Real Soon Now" status for a long time now. I'd hazard the guess that a bunch of developers are feeling rebellious about the fact that it is not free software.
By the way, the "let's set up a CVS repository" idea has the conspicuous demerit at "send the patch to Linus time" that it is still going to take a lot of effort to make sure that the patches that get sent on to Linus are reasonably perspicuous. You're still left with the dilemma that:
But this will tend to "bulk up" into something that involves a horde of changes, which again will not be terribly perspicuous.
This is certainly spelled "dilemma," as all the alternatives are pretty poor...
If you're not part of the solution, you're part of the precipitate.
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.
Engineering and the Ultimate
When Linus can start delegating authority over subsystems, when Linus can learn to use revision control, when any kind of coordination of changes affecting multiple subsystems does or even *can* go through anyone but Linus himself, then perhaps he won't need to personally review each and every patch that comes to him.
As it is now, he doesn't even trust Alan Cox to maintain any part of the official tree -- he still has to send Linus patches. Forks do happen in a project, when such sweeping changes are needed, and they get merged in later versions. Linus tacitly admits this because he can find an incremental way to do it each time. In other cases, people decided to just stop trying to go through Linus, because they know what Linus doesn't: Linus doesn't know everything.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
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
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
> if MS ignore a set of hardware, they lose money, so they won't do it
So where is Windows for PPC?
-- Don't Tase me, bro!
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.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
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.
This is exactly why Linus wants small patches. With a small patch, it is possible to quickly look at it, see what it's doing, and evaluate the patch on several levels:
clarity - is it clear what the patch fixes/adds (this tends to be a sign of well-written code)
correctness - a 300K patch would take days to go through and make sure that you aren't breaking something else by applying the patch. Small gotchas will stand out more in smaller patches.
If you apply a 300K patch, and something new breaks, what do you do now? Look through the code slowly and try to figure out what happened. With a small patch, there is a greater chance that you can back out exactly what change broke whatever function, making it easier to find where you broke it, if not why.
Doug
Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
http://kt.linuxcare.com/kernel-traffic/kt20010108_ 101.epl#7, http://kt.linuxcare.com/kernel-traffic/kt20001127_ 95.epl#6
and especially: http://kt.linuxcare.com/kernel-traffic/kt20001002_ 87.epl#3, http://kt.linuxcare.com/kernel-traffic/kt20001010_ 88.epl#7.
Have a good read. KernelTraffic Rocks.
-Chris
http://www.nondot.org/~sabre/os/
So, if your small patch is "Prevents the Frangle Hyperqueue Monitor from crashing on PPC", how does it get verified in the official kernel if you need 50 other similar small patches before your kernel will even get as far as trying to access the Frangle Hyperqueue on PPC?
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
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.
Zeros, Ones, and sometimes Twos.
I could kick my own ass for thinking different.
Don't post on slashdot anymore pal. This site is for people with brains in their heads, not prejudism in their heart.
You must be new...
--
I'd hope that architecture politics stay away from the linux kernel.
Chris Kuivenhoven is a thief, beware
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 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.
WWJD? JWRTFM!!!
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...If you're not part of the solution, you're part of the precipitate.
Well, I won't even try to rely to most of the crap I've read here, sorry guys, but some of your comments are just so...
;) The truth is that we are in fact paid by Microsoft to write crappy code, flood Linus with huge and unmergeable patches in the clear intend to cause a Linux fork !
There are several points about the PPC arch. First of all, it's huge and very quickly growing. Why ? Well, in a single arch, it handles all PCI PowerMacs (with new hardware coming out of Apple every 6 monthes), CHRP boxes (including some RS6k IBM machines), PReP boxes, APUS, NuBus PowerMac is coming in, Gemini, and I'm forgetting some...
Add to that the embedded hardware (8xx CPUs, 4xx CPUs coming in soon) with the zillion of hardware variations.
So it's _huge_, it's quickly moving forward (remember USB, we needed to get that working for kbd and mouse on iMacs while most x86 boxes didn't even had Windoze drivers for their USB controller), and the necessary consequence is that patches are huge. Fortunately, most of them just touch arch/ppc, include/asm-ppc or PPC specific drivers.
But I'm not telling you all here
Ben.
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.
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 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.
--
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?
The first priority for 2.4.x has to be to get it rock solid for the majority of users (and unfortunately for most definitions that means x86). Linus has also been avoiding making vast numbers of changes in one go while working on the really hard to debug and critical fixes to the core code. In the meantime I've been merging chunks of architecture code into the -ac tree ready to go as I get them.
A good solid well maintained self sufficient ppc tree is one of the reasons we can do that of course
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.
--
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)