Well, I wouldn't want to accuse you of being highly insane, but... Changelog-2.4.8 says thusly:
- Jeff Hartmann: upgrade DRM to XF86 4.1.x, drop support for 4.0.x
So either you're using a kernel >= v2.4.8 or a vendor-kernel that has been patched to provide DRM for v4.1, or you aren't using DRI/DRM despite believing so.
Alan doesn't have a complete merge between the ac-tree and Linus' own tree as a goal. Even for the kernel-tree Alan himself maintains (v2.2.xx) he sometimes releases ac-patches when he deems something not stable enough to go into the main kernel.
The v2.5 tree will open when v2.4 is on a quality-level such that Linus won't have to bother with it again. Having to focus on several trees at once is bothersome business.
YES, the change from Riel's VM to Arcangeli's VM was revolutionary (and not necessarily evolutionary) and shouldn't have been made, but it seems that most problems have been solved now non-the-less.
The "old" VM (or rather, the -Riel VM) will probably be packaged with RH 7.2, yes, because that's what Alan has in his v2.4.xx-ac kernels which mostly are the base for RedHat's kernels.
Rik van Riel's VM is better documented (little
instead of no) and seems to work predictably
nowadays.
I hope that v2.5.xx will be opened soon, so
that any forth-coming VM-tuning will be done there
instead of in the supposedly stable kernel.
XFree 4.1 requires a v2.4.10 or v2.4.11 kernel to use DRI/DRM. On the other hand, Xfree 4.0 doesn't work with v2.4.10/v2.4.11.
Other than that, the need for upgrading is mostly if you experience problems or have new
hardware.
AFAIK you can use make rpm to build
an RPM of your kernel nowadays (new in v2.4.(some number > 3). For Debian, the counterpart is ake-kpkg which has existed
for ages.
(Dunno why I bother to reply to this, but...) Obviously, if he wanted his employer to have it before the rest of the world, he wouldn't be able to release it under the GPL, which he has. Any user or distributionmaker who wants ext3 in their system can simply download it from ftp.kernel.org and patch it into their kernel... Can we PLEASE stay on the sane side now?!
My best wager is Trond Myklebust or Neil Brown. Hint: there are two very useful files in the kernel; "Documentation/SubmittingPatches" and "MAINTAINERS". Combine the two, and voila!
Re:But the question everyone is asking is
on
Linux Kernel 2.4.10
·
· Score: 1
Some cleanups and a common journaling layer to avoid duplicating code in all the journaling file systems that will go into the kernel; hence v2.5 is a better time for a merge than v2.4; a backport might be possible, though. Oh, and Alexander Viro had some interesting comments on XFS on LKML the other day.
Re:But the question everyone is asking is
on
Linux Kernel 2.4.10
·
· Score: 1
Uhm, actually, the latest v2.0.xx kernel is v2.0.40pre1, and more are expected. Released a couple of days ago. AFAIK, the v2.1-tree was forked from v2.0.21.
Re:linux-2.4.10.tar.bz2 is really 2.4.9!!
on
Linux Kernel 2.4.10
·
· Score: 1
This sounds extremely unlikely, as ftp.kernel.org has a buildrobot; if you upload a tar.gz, it'll create the tar.bz2; if you upload a tar.bz2, it'll create the tar.gz. Very neat indeed. It also creates checksum-files.
Pretty simple: because the author hasn't submitted it to Linus yet; he wants it to be as close to perfect as possible first. A honourable decision, if you ask me.
I'm sorry to disappoint you, but the at least the potato-brand Blue Congo (quite usual here in Sweden) is blue on the inside too. And they taste really nice. And make mashed potatoes look soooo much nicer. Those aren't GMO either.
Sure, everyone can contribute anything to the kernel. But this summit wasn't for those who regularly submit drivers/documentation fixes etc., however important they are. This meeting is for people who design the subsystems, API:s and other core-parts; the very intestinals. I like to think of myself as having contributed to quite some things in the kernel; bugfixes, documentation, the driver-management system for the MCA-subsystem and what not. I also maintain the v2.0.xx-kernel series.
However, I do not feel the least bit slighted by not being invited to the summit. Why? Because I wouldn't have done a lot of good there anyway. I'm not really the kind of visionary (and more importantly, the great OS-theory scholar) that are needed in such a meeting. I'm a codeslave. I munch C for breakfast, and I'm proud of it. I write manualpages for lunch, and I'm proud of it. I fix typos for dinner, and I'm proud of it. But hacking up a new scheduler or an OOM-killer? Merely the thought gives me a headache. I'd rather search for memory-leaks or possible deadlocks.
Maybe it's just me, but I'd much rather see a SCUMM game engine (for LucasArts games, such as Loom, Monkey Island, D.O.T.T., Full Throttle, Sam'n'Max, Zak McKracken et al.) And before anyone says I should get coding myself, I've got too much programming-work to do already.
I really hope that the GNOME-team has been in contact with the KDE-team here, to create a protocol that will make the protocol a common standard rather than a GNOME-specific invention. Sadly, I don't hold my hopes up on this one...
My guess is that MacOS X v1.0 only will be sold on Apple's online store. Apple has already said that they'll wait until v1.1 before shipping computers with it, so those who don't know what their doing will probably not be subjected to it anyway. And as for subjecting those users to software, I'd rather subject them to MacOS X than to Windows or Linux. But if I have the opportunity to guide them through their first install, I always recommend Linux...
About Joe Blow having to pay because he can't download the entire update. Well, dohhhh, did you expect Apple to send free CDs to everyone? The shipping cost would probably be higher than the production-cost...
Yup. Let's see... Windows. Numerous bugs and errors that can cause system hangs or freezes (ok, those are not acknowledged by Microsoft, but that's merely because Microsoft almost never acknowledges bugs...) Solaris. Numerous bugs and errors, some of them acknowledged by Sun. AIX. Numerous bugs and errors, some of them acknowledged by IBM. BeOS. Numerous bugs and errors, acknowledged by Be Inc. Linux. Numerous bugs and errors, definitely acknowledged (why wouldn't we; we want people to know that they might not be able to use their favourite feature until the next minor release.) *BSD. Same thing here... You name it. You simply have to call it a freeze somewhere and release your software. If you're smart, you release an errata with it or soon after the release.
As for lacking support for some hardware, it's the same here. You have to draw the line somewhere. And it's not as if the ability to watch DVD-movies is the most important feature in a computer, huh? You'll still be able to use your DVD-drive as a CD-rom (I know, I've tried it with my G4 with the
public beta of MacOS X), which is what most people use it for anyway... Oh, and it's not like Microsoft have been the first to adopt all hardware either; especially not for Win NT.
The reason that Apple want people to wait is pretty simple: they want to give software-companies a fair chance to develop against a frozen API. Oh, and be honest, have you tried any operating-system with a version# of v1.0 that you'd actually recommend for everyday users? No?! I'm not surprised. Still, I regard MacOS X to be one of the better operating-systems in this regard. It is rock stable in most regards; and the only glitches I ever noticed in the public-beta was some GUI-details. I'm looking forward to trying out v1.0, to see what a build without the tons of debug-code they sprinkled into the betas can do.
Finally, I don't believe that Apple will charge for the update from MacOS X v1.0 to v1.1; at least they didn't charge for 8.0 to 8.1, 9.0 to 9.1 or other minor upgrades.
Yes, the TiBook is an impressive piece of hardware ((Btw, it has a PC-Card controller, not a PCMCIA-controller. But that's a minor nitpick), but 11'x7' (whatever that is in metric measurements), is pretty big if you want to squeeze it into a palmtop, where you want most/all functions in a single chip (I/O-controller, MMU, etc.)
The advantage Bluetooth has is that the chipset is extremely small, already here and extremely cheap. I doubt that the FireWire-chipset will be as cheap. But I'd be happy if it was, of course.
For many machine-rooms, 12 metres would be fully sufficient. Just imagine getting away from some of the cables in the storage-arrays (hooray!)
Oh, and FireWire is mostly used for digital videocameras, cd-recorders and other stuff that you don't need to have connected to your computer most of the time. Not having to go look for some connector you put somewhere everytime you want to transfer something from your digicam to your computer will likely be regarded as something wonderful by most people.
About the size: as long as people are perfectly happy with buying FireWire as add-ons to their computers, I can't see why it'd matter much. And there are (to my knowledge) no FireWire-capable palmtops yet. But I'm pretty convinced that smaller chipsets will developed pretty fast if needed. If for no other reason, Apple will probably want such for their next generation of PowerBooks.
Maybe I'm just overly nostalgic, but I still consider many of the best games so far came during the golden age of the Commodore 64. Games like Wizball, Paradroid, The Last Ninja, Gunship, Red Storm Rising, Zak McKracken, Maniac Mansion, Agent USA, Parallax, Archon, Boulder Dash, Pirates!, The Guild of Thieves, Leather Goddesses of Phobos,... Yee $DEITY, I could go on for hours.
Not to mention that most of the games on the 64, even the really crappy ones (like Rambo, which has got my alltime favourite tune, and Robocop 3, which has a most amazing intro-tune, but badly sucking gameplay), had better music than any of the games produced nowadays (except a few exceptions, where I seem to notice a strange pattern; the music in those highlights are made by musicians such as Jeroen Tel and other people who was active during the 64-era...)
You know, if you really *do* dislike all the Jon Katz-features, why not simply use your personal Slashdot-preferences; "Exclude stories from Slashdot: Authors", and you'll never have to read another story by him.
Slashdot Mirror
How the **** do you apply the patches? I've never had a single problem so far. My typical patch-procedure:
cd linux-2.4.12bzcat
cd
mv linux-2.4.12 linux-2.4.13
Should take care of everything.
Well, I wouldn't want to accuse you of being highly insane, but... Changelog-2.4.8 says thusly:
So either you're using a kernel >= v2.4.8 or a vendor-kernel that has been patched to provide DRM for v4.1, or you aren't using DRI/DRM despite believing so.
Alan doesn't have a complete merge between the ac-tree and Linus' own tree as a goal. Even for the kernel-tree Alan himself maintains (v2.2.xx) he sometimes releases ac-patches when he deems something not stable enough to go into the main kernel.
The v2.5 tree will open when v2.4 is on a quality-level such that Linus won't have to bother with it again. Having to focus on several trees at once is bothersome business.
YES, the change from Riel's VM to Arcangeli's VM was revolutionary (and not necessarily evolutionary) and shouldn't have been made, but it seems that most problems have been solved now non-the-less.
The "old" VM (or rather, the -Riel VM) will probably be packaged with RH 7.2, yes, because that's what Alan has in his v2.4.xx-ac kernels which mostly are the base for RedHat's kernels. Rik van Riel's VM is better documented (little instead of no) and seems to work predictably nowadays.
I hope that v2.5.xx will be opened soon, so that any forth-coming VM-tuning will be done there instead of in the supposedly stable kernel.
XFree 4.1 requires a v2.4.10 or v2.4.11 kernel to use DRI/DRM. On the other hand, Xfree 4.0 doesn't work with v2.4.10/v2.4.11.
Other than that, the need for upgrading is mostly if you experience problems or have new hardware.
AFAIK you can use make rpm to build an RPM of your kernel nowadays (new in v2.4.(some number > 3). For Debian, the counterpart is ake-kpkg which has existed for ages.
(Dunno why I bother to reply to this, but...) Obviously, if he wanted his employer to have it before the rest of the world, he wouldn't be able to release it under the GPL, which he has. Any user or distributionmaker who wants ext3 in their system can simply download it from ftp.kernel.org and patch it into their kernel... Can we PLEASE stay on the sane side now?!
My best wager is Trond Myklebust or Neil Brown. Hint: there are two very useful files in the kernel; "Documentation/SubmittingPatches" and "MAINTAINERS". Combine the two, and voila!
Some cleanups and a common journaling layer to avoid duplicating code in all the journaling file systems that will go into the kernel; hence v2.5 is a better time for a merge than v2.4; a backport might be possible, though. Oh, and Alexander Viro had some interesting comments on XFS on LKML the other day.
Uhm, actually, the latest v2.0.xx kernel is v2.0.40pre1, and more are expected. Released a couple of days ago. AFAIK, the v2.1-tree was forked from v2.0.21.
This sounds extremely unlikely, as ftp.kernel.org has a buildrobot; if you upload a tar.gz, it'll create the tar.bz2; if you upload a tar.bz2, it'll create the tar.gz. Very neat indeed. It also creates checksum-files.
Pretty simple: because the author hasn't submitted it to Linus yet; he wants it to be as close to perfect as possible first. A honourable decision, if you ask me.
I'm sorry to disappoint you, but the at least the potato-brand Blue Congo (quite usual here in Sweden) is blue on the inside too. And they taste really nice. And make mashed potatoes look soooo much nicer. Those aren't GMO either.
You know, there was a special FAQ-entry for people like you:
Sure, everyone can contribute anything to the kernel. But this summit wasn't for those who regularly submit drivers/documentation fixes etc., however important they are. This meeting is for people who design the subsystems, API:s and other core-parts; the very intestinals. I like to think of myself as having contributed to quite some things in the kernel; bugfixes, documentation, the driver-management system for the MCA-subsystem and what not. I also maintain the v2.0.xx-kernel series.
However, I do not feel the least bit slighted by not being invited to the summit. Why? Because I wouldn't have done a lot of good there anyway. I'm not really the kind of visionary (and more importantly, the great OS-theory scholar) that are needed in such a meeting. I'm a codeslave. I munch C for breakfast, and I'm proud of it. I write manualpages for lunch, and I'm proud of it. I fix typos for dinner, and I'm proud of it. But hacking up a new scheduler or an OOM-killer? Merely the thought gives me a headache. I'd rather search for memory-leaks or possible deadlocks.
Have a look here, and you'll become enlightened. In short: it's from an introduction to a game that went through a lousy translation into English.
Maybe it's just me, but I'd much rather see a SCUMM game engine (for LucasArts games, such as Loom, Monkey Island, D.O.T.T., Full Throttle, Sam'n'Max, Zak McKracken et al.) And before anyone says I should get coding myself, I've got too much programming-work to do already.
I really hope that the GNOME-team has been in contact with the KDE-team here, to create a protocol that will make the protocol a common standard rather than a GNOME-specific invention. Sadly, I don't hold my hopes up on this one...
My guess is that MacOS X v1.0 only will be sold on Apple's online store. Apple has already said that they'll wait until v1.1 before shipping computers with it, so those who don't know what their doing will probably not be subjected to it anyway. And as for subjecting those users to software, I'd rather subject them to MacOS X than to Windows or Linux. But if I have the opportunity to guide them through their first install, I always recommend Linux...
About Joe Blow having to pay because he can't download the entire update. Well, dohhhh, did you expect Apple to send free CDs to everyone? The shipping cost would probably be higher than the production-cost...
Yup. Let's see... Windows. Numerous bugs and errors that can cause system hangs or freezes (ok, those are not acknowledged by Microsoft, but that's merely because Microsoft almost never acknowledges bugs...) Solaris. Numerous bugs and errors, some of them acknowledged by Sun. AIX. Numerous bugs and errors, some of them acknowledged by IBM. BeOS. Numerous bugs and errors, acknowledged by Be Inc. Linux. Numerous bugs and errors, definitely acknowledged (why wouldn't we; we want people to know that they might not be able to use their favourite feature until the next minor release.) *BSD. Same thing here... You name it. You simply have to call it a freeze somewhere and release your software. If you're smart, you release an errata with it or soon after the release.
As for lacking support for some hardware, it's the same here. You have to draw the line somewhere. And it's not as if the ability to watch DVD-movies is the most important feature in a computer, huh? You'll still be able to use your DVD-drive as a CD-rom (I know, I've tried it with my G4 with the public beta of MacOS X), which is what most people use it for anyway... Oh, and it's not like Microsoft have been the first to adopt all hardware either; especially not for Win NT.
The reason that Apple want people to wait is pretty simple: they want to give software-companies a fair chance to develop against a frozen API. Oh, and be honest, have you tried any operating-system with a version# of v1.0 that you'd actually recommend for everyday users? No?! I'm not surprised. Still, I regard MacOS X to be one of the better operating-systems in this regard. It is rock stable in most regards; and the only glitches I ever noticed in the public-beta was some GUI-details. I'm looking forward to trying out v1.0, to see what a build without the tons of debug-code they sprinkled into the betas can do.
Finally, I don't believe that Apple will charge for the update from MacOS X v1.0 to v1.1; at least they didn't charge for 8.0 to 8.1, 9.0 to 9.1 or other minor upgrades.
Sorry, I meant CardBus, not PC-Cards. CardBus == busmastering-able 32-bit PC-Cards, whereas PCMCIA == non-busmastering-able 16-bit PC-Cards. Once again, sorry.
Yes, the TiBook is an impressive piece of hardware ((Btw, it has a PC-Card controller, not a PCMCIA-controller. But that's a minor nitpick), but 11'x7' (whatever that is in metric measurements), is pretty big if you want to squeeze it into a palmtop, where you want most/all functions in a single chip (I/O-controller, MMU, etc.)
The advantage Bluetooth has is that the chipset is extremely small, already here and extremely cheap. I doubt that the FireWire-chipset will be as cheap. But I'd be happy if it was, of course.
For many machine-rooms, 12 metres would be fully sufficient. Just imagine getting away from some of the cables in the storage-arrays (hooray!)
Oh, and FireWire is mostly used for digital videocameras, cd-recorders and other stuff that you don't need to have connected to your computer most of the time. Not having to go look for some connector you put somewhere everytime you want to transfer something from your digicam to your computer will likely be regarded as something wonderful by most people.
About the size: as long as people are perfectly happy with buying FireWire as add-ons to their computers, I can't see why it'd matter much. And there are (to my knowledge) no FireWire-capable palmtops yet. But I'm pretty convinced that smaller chipsets will developed pretty fast if needed. If for no other reason, Apple will probably want such for their next generation of PowerBooks.
Maybe I'm just overly nostalgic, but I still consider many of the best games so far came during the golden age of the Commodore 64. Games like Wizball, Paradroid, The Last Ninja, Gunship, Red Storm Rising, Zak McKracken, Maniac Mansion, Agent USA, Parallax, Archon, Boulder Dash, Pirates!, The Guild of Thieves, Leather Goddesses of Phobos, ... Yee $DEITY, I could go on for hours.
Not to mention that most of the games on the 64, even the really crappy ones (like Rambo, which has got my alltime favourite tune, and Robocop 3, which has a most amazing intro-tune, but badly sucking gameplay), had better music than any of the games produced nowadays (except a few exceptions, where I seem to notice a strange pattern; the music in those highlights are made by musicians such as Jeroen Tel and other people who was active during the 64-era...)
You know, if you really *do* dislike all the Jon Katz-features, why not simply use your personal Slashdot-preferences; "Exclude stories from Slashdot: Authors", and you'll never have to read another story by him.