Yes, I'm most interested in what's going in the portables. I got an iBook for cheap some time ago, but since then they've added 200 MHz to the high-end iBooks (damn you, Apple! ^_^; ). I've been wanting to upgrade, but I definitely want to see at least a G4 in the iBook first. A PPC 970 portable, though, would be great, I'd be willing to wait another year or more for a G5 iBook if I knew they were coming.
Heh. I have an Apple laptop and it's a Linux laptop, both at the same time!
OS X is pretty good. PPC Linux runs just fine (aside from a few "all the world's an Intel" complexes some developers have). Dual booting is nice and stylish for the developer on the go.
They don't because they don't believe it will make them money. Seriously.
Using GNOME or KDE in their next release would be a horrible idea for Apple. And here's why.... this really isn't an attack on you or the GNOME/KDE teams. Some of this is going to seem harsh, but I'm stating my opinion. Please don't take it personally, or as a slam to KDE or GNOME, since I do actually like both of these projects, even though I don't think they (or Apple, for that matter) are the best thing since sliced neko bread.
Apple already just recently (well, 10.0) totally changed their UI and user experience from what it had been for a decade. That pissed off a lot of hardcore old users. Apple doesn't need to go alienating their users again. (And no, I don't feel that the Aqua themes "count". They're pretty, but they're not "there", from my recollection.)
Performance-wise? The most recent releases of GNOME and KDE felt slower on my 866 MHz i686 machine than 10.2 did on my 700 MHz PPC750. Apple really doesn't need their OS getting slower, especially on their low-end machines, which people here already bitch and taunt as being horribly underpowered.
Finally... what do you mean, exactly, by "little incompatibilities"? Are you throwing this out to make your post look balanced, or did you have something specific in mind? I couldn't think of anything off hand... until I realized that switching to GNOME or KDE would likely mean GTK+ or QT, which would involve changing the entire desktop API for every Mac OS application. This is not! a "little" incompatibility. Making some sort of Cocoa wrapper would be a huge pain in the ass, no matter how good a coder you are. That would still be better than forcing every OS X developer to rewrite their application (again, if it used to be an old OS 9- program). This would be a huge waste of Apple's time and money and probably piss off their developers to no end.
Really finally, now, as a matter of personal opinion, I do actually like the whole OS X UI system better than GNOME or KDE. The legions of rabid and not-so-rabid Apple loyalists would probably agree with me, since OS X probably at least tries to follow whatever Apple's UI standards are. Not only are GNOME and KDE "not Apple", but the UI experience is different. So I don't think Apple would garner support from their users by switching.
Ssssh. I still can't believe people paid money for Windows ME.
And to answer your question, it'll probably be US$129, just like the last point upgrade they released. How minor it truly is we will never know, since we can't see their source. But I suggest you cut the version number whining, unless you'd like to suggest to me that the Linux kernel 2.2, 2.4, and (upcoming) 2.6 releases were all "minor updates". (And yes, I know i'm not paying for kernel.org. That's also not my point.)
Well... the few times I've done or seen programming on Windows it's been Win32. I've shied away from MFC... for various reasons ^^; But originally because I wanted to know how stuff really worked. (This decision was also around the time I started learning intel assembly and basic architecture.) My mom (also a CS person) has had NTSP6 and 2k, but by this time I had started running Linux, so I never really learned as much about boot-time options and such for NT-derivative systems.
That's pretty neat, though. I wonder if I should hack up a split= command line param for Linux, just for fun, some time.
Sorry. By "Win32" I really meant "NT-like operating systems". This was mostly making observations stepping through programs in VC++, which I had the opportunity to do recently. (Well, I do know some people that run Windows even if I don't. ^^; )
Yeah. Windows 9x is horrible in several respects..
Well this is somewhat of a generalization. Yes some errors can cause the whole system to crash in both Linux, Windows, and Unix. The difference is that it the way Unix and Linux are designed, it is far less likely.
What particular Windows design flaw are you thinking of here? (In other words, I'm far from a Microsoft apologist, but it's nice to back up your statements.:3 )
Protected memory space for the kernel or microkernel: Even Windows has that. The only problem is that "protected" is a very loose term for Windows. Unlike Windows, Unix and Linux doesn't allow any ordinary application to write to the kernel.
That's funny, I don't seem to remember being able to write to addresses above 0x80000000 on NT4, although I haven't tried loading a pointer with such an address and dereferencing it in purpose. Somebody with immediate access to a Win32 system could try this and tell us what happens:
#define WIN32_LEAN_AND_MEAN #include <windows.h>
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { char *p; p = (char *) 0x80000001L;// start of kernel address space + 1 *p = 0;// this *should* terminate process MessageBox (NULL, "Nyah nyah, Kourino doesn't know what he's talking about", "Ha!", 0); return 0; }
The expected outcome and possible outcomes should be clear.:D
(Win32 userland/kernel split is 2:2, unlike Linux's default 3:1. 2:2 seems a bit excessive to me, but ah well; i haven't thought that much about it. I know there are issues in 3:1 for stuff like page tables on large memory machines). If you're thinking of the bad old days of 16-bit Windows, please say so; it's important to know that you're comparing a broken OS implementation.
A few PALs and an FPGA would be cheaper, but it wouldn't be as much fun. The whole appeal of a project like this, I imagine, is building stuff up from the ground up. That's why Linus started a multitasker to learn about the 80386, and why I'm writing a game now that talks to Xlib directly as one of its backends. (Another potential graphical backend is VBE framebuffer, but I think the DOS port is an idea that's far past its life. Still, we'll see; I have all my old VBE setup code laying around. Hmm... I also wrote some simple protected mode code in those days, but never got to multitasking. Sigh.)
Oh, and in the industrialized world, 90 hour work weeks and sub-standard working conditions are an American phenomenon these days. The French, for example, get enough leave to blow your mind:D
Re:allows a bypass of GPL
on
Linus on DRM
·
· Score: 1
The point is that DRM could be used to subvert the GPL.
Okay. How? Explain clearly and completely, and I'll listen. ^_^
If that's where you were going with your situation in the parent post, I think you need to do some more explaining.
What this actually means
on
Linus on DRM
·
· Score: 2, Informative
Since I've already replied to three messages this way, and a lot of people seem to be missing the point...
Okay. First of all, DRM is NOT synonymous with "digital copyright protection", okay?
Second. Linus is NOT saying "DRM is good" or "copyright protection is the shiznit". He in fact says in the message that a lot of uses for DRM he doesn't like.
Third. An example of what this article is actually talking about is cryptographically signing a regular, run of the mill built-by-Linus kernel image, somehow providing the signature along with the image at boot, and refusing to load it if the signature doesn't match. Since you don't modify the kernel itself, the GPL has no scope here, so it's obviously not prohibited under the terms of the GPL.
Fourth. This does NOT allow magically modifying the kernel image, nor does it allow magically allow copyright protection in the kernel, nor does it allow hiding private keys in the kernel, etc.
READ THE ARTICLE. Turn off your Slashdot "omg wtf it says drm so it's bad, lol" meme. Linus is not selling your souls to Jack Valenti here.
Re:allows a bypass of GPL
on
Linus on DRM
·
· Score: 1
You're missing the point.
Cryptographically signing a kernel image is not modifying it. That's like saying taking a picture of a book cover and recording all the pixels so I can see if it gets damaged is changing the book cover. What's getting brought up is basically making a cryptographic signature of a kernel image, somehow providing that to boot firmware when you want to go load the image, and refusing to boot if the image and signature don't match.
Go reread the mail.
Re:I think Linus Missed the Point....
on
Linus on DRM
·
· Score: 4, Insightful
In Soviet Russia, the point misses YOU!
Nowhere in this message does Linus even begin to talk about RIAA-driven media protection schemes. Why are you even bringing it up in this post? "Digital copyright protection" IS NOT the be-all and end-all of DRM.
Try reading the message again. Linus brings up the exact same point you did: "hiding" a private key in GPLed source is obviously not okay because it exposes the private key. And how does "wrapping it up in a shared lib" "violate everything OSS stands for"? Or are you conveniently overlooking the entire point behind the LGPL? Nevermind that shared libs don't even make sense at the kernel level.
Linus' message has nothing to do with Winputers or the RIAA or forcing you to run/not run whatever because some guy in a suit in Hollywood doesn't trust you with things that aren't his anyway. There's nothing to see here. Move along.
Re:source to the key in the kernel?
on
Linus on DRM
·
· Score: 4, Informative
What you're missing is the point.
Say I have a machine that has uber-top-secret data or whatever on it. I want to make sure that all the code that runs on it comes from "trusted" source. (I do this because I know the code may have mistakes or exploits in it, and this doesn't protect me from that, but it makes it less likely that I run code with trojans in it if I at least have proof of where it comes from.)
So, my machine has a cryptographic check in its firmware: instead of taking a kernel image and just booting it, it takes the kernel image and an accompanying signature tacked to the end of it and checks the signature against Linus' public key. If it matches, it boots. If not, it provides some sort of warning (flashing alerts on screen, sirens, whatever).
Linus, in his message, is saying that it's perfectly okay for me to do all of that. Not in so many words, but that's a valid example of "rights" management by digital signature, which he's saying the GPL can't prevent you from doing.
Remember, DRM is not just "digital copyright protection" as so many people on Slashdot seem to enjoy thinking.
Re:i don't quite follow...
on
Linus on DRM
·
· Score: 2, Insightful
Try rereading the message. What Linus is, in fact, saying, is that DRM of the Linux kernel is okay. So, for example, you can digitally sign a kernel binary and have your platform refuse to boot if there isn't a valid signature if it floats your boat. He's also making the case that this is a valid action under the GPL. He never said "I like DRM in most fashions"; in fact, he said something rather the opposite of that at least once in this morning's message:
And like the software patent issue, I also don't necessarily like DRM
myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I
refuse to play politics with Linux, and I think you can use Linux for
whatever you want to - which very much includes things I don't necessarily
personally approve of.
Err, crap. Actually you're right. I did a more extensive search on this and realized that I totally misremembered. I apologize and retract that statement, don't know what I was smoking yesterday ^^;
(Just refound the AC message that said it might be about a 5-10% slowdown. Note to self, do not post in a rush! >_> )
See, SPARC doesn't have that silly 4GB addressing limitation that IA-32 does. Running "without PAE" on a Sun box makes no sense because it's an "extension" that only x86 is afflicted with. I bet any of the free Unix-like systems would run fine on sane architectures with 10GB of RAM, too...
PAE never really excited me. I mean... it's like EMM386, with 4GB instead of 1MB. It's a hack, and from what I hear (that is to say, what Will Irwin has said on LKML) PAE is fairly slow compared to regular memory, anyway. (And regular memory is already fairly slow compared to core CPU clock speeds, even with high-speed DDR.)
I won't say people don't do >4GB on x86, because obviously they do, but there are reasons not many people do.:3
Nonono. I'm not really complaining about it. I know the limit of what I can expect as a consumer of free software. I'm just pointing out my opinion that maybe mplayer isn't the best thing since sliced bread after all.:3
Of course each person has the option of not downloading and using the windows binaries, but I will guarantee that for those who use mplayer as their main video player, when they have the choice of using mplayer's.dll loading capabilities or switching to another video player that has a native linux decoder, they will stick with mplayer.
Wrong. Most of my computers can't run Windows binaries. (In fact, the computer I've come to use the most runs a PowerPC 750.) After all, not all the world's an x86. I'll take my native decoder, thanks. That way I can actually watch stuff.
... that only work on one platform? It still annoys me greatly that mplayer runs extremely well on my Pentium 3, but, depending on the task, absolutely crawls on comparable hardware from other architectures, or just plain doesn't support stuff at all.
mplayer? Plays everything? You obviously don't use powerpc-*-linux or alpha-*-linux:3
I'm so discouraged by this I just need to stop and agree...
I've been sitting in the IRC channel for a popular icculus game recently and every day someone brings up (again) the "we need OpenGL support" topic.
Now, you can't do this in general, but today on LKML I saw what I consider to be a contender for greatest message ever... damn, did it make me laugh XD
From: Alan Cox Subject: Re: poweroff problem
On Sad, 2003-04-05 at 07:08, Anant Aneja wrote: > also i cant give u the complete listing of the cpu > registers since it occurs at the last stage > of shutdown and i cant copy it to a file > and am too lazy to write it down
Slashdot Mirror
Yes, I'm most interested in what's going in the portables. I got an iBook for cheap some time ago, but since then they've added 200 MHz to the high-end iBooks (damn you, Apple! ^_^; ). I've been wanting to upgrade, but I definitely want to see at least a G4 in the iBook first. A PPC 970 portable, though, would be great, I'd be willing to wait another year or more for a G5 iBook if I knew they were coming.
Heh. I have an Apple laptop and it's a Linux laptop, both at the same time!
OS X is pretty good. PPC Linux runs just fine (aside from a few "all the world's an Intel" complexes some developers have). Dual booting is nice and stylish for the developer on the go.
They don't because they don't believe it will make them money. Seriously.
... this really isn't an attack on you or the GNOME/KDE teams. Some of this is going to seem harsh, but I'm stating my opinion. Please don't take it personally, or as a slam to KDE or GNOME, since I do actually like both of these projects, even though I don't think they (or Apple, for that matter) are the best thing since sliced neko bread.
... what do you mean, exactly, by "little incompatibilities"? Are you throwing this out to make your post look balanced, or did you have something specific in mind? I couldn't think of anything off hand ... until I realized that switching to GNOME or KDE would likely mean GTK+ or QT, which would involve changing the entire desktop API for every Mac OS application. This is not! a "little" incompatibility. Making some sort of Cocoa wrapper would be a huge pain in the ass, no matter how good a coder you are. That would still be better than forcing every OS X developer to rewrite their application (again, if it used to be an old OS 9- program). This would be a huge waste of Apple's time and money and probably piss off their developers to no end.
Using GNOME or KDE in their next release would be a horrible idea for Apple. And here's why.
Apple already just recently (well, 10.0) totally changed their UI and user experience from what it had been for a decade. That pissed off a lot of hardcore old users. Apple doesn't need to go alienating their users again. (And no, I don't feel that the Aqua themes "count". They're pretty, but they're not "there", from my recollection.)
Performance-wise? The most recent releases of GNOME and KDE felt slower on my 866 MHz i686 machine than 10.2 did on my 700 MHz PPC750. Apple really doesn't need their OS getting slower, especially on their low-end machines, which people here already bitch and taunt as being horribly underpowered.
Finally
Really finally, now, as a matter of personal opinion, I do actually like the whole OS X UI system better than GNOME or KDE. The legions of rabid and not-so-rabid Apple loyalists would probably agree with me, since OS X probably at least tries to follow whatever Apple's UI standards are. Not only are GNOME and KDE "not Apple", but the UI experience is different. So I don't think Apple would garner support from their users by switching.
Ssssh. I still can't believe people paid money for Windows ME.
And to answer your question, it'll probably be US$129, just like the last point upgrade they released. How minor it truly is we will never know, since we can't see their source. But I suggest you cut the version number whining, unless you'd like to suggest to me that the Linux kernel 2.2, 2.4, and (upcoming) 2.6 releases were all "minor updates". (And yes, I know i'm not paying for kernel.org. That's also not my point.)
Well ... the few times I've done or seen programming on Windows it's been Win32. I've shied away from MFC ... for various reasons ^^; But originally because I wanted to know how stuff really worked. (This decision was also around the time I started learning intel assembly and basic architecture.) My mom (also a CS person) has had NTSP6 and 2k, but by this time I had started running Linux, so I never really learned as much about boot-time options and such for NT-derivative systems.
That's pretty neat, though. I wonder if I should hack up a split= command line param for Linux, just for fun, some time.
Sorry. By "Win32" I really meant "NT-like operating systems". This was mostly making observations stepping through programs in VC++, which I had the opportunity to do recently. (Well, I do know some people that run Windows even if I don't. ^^; ) Yeah. Windows 9x is horrible in several respects ..
Well this is somewhat of a generalization. Yes some errors can cause the whole system to crash in both Linux, Windows, and Unix. The difference is that it the way Unix and Linux are designed, it is far less likely.
What particular Windows design flaw are you thinking of here? (In other words, I'm far from a Microsoft apologist, but it's nice to back up your statements. :3 )
Protected memory space for the kernel or microkernel: Even Windows has that. The only problem is that "protected" is a very loose term for Windows. Unlike Windows, Unix and Linux doesn't allow any ordinary application to write to the kernel.
That's funny, I don't seem to remember being able to write to addresses above 0x80000000 on NT4, although I haven't tried loading a pointer with such an address and dereferencing it in purpose. Somebody with immediate access to a Win32 system could try this and tell us what happens:
The expected outcome and possible outcomes should be clear.(Win32 userland/kernel split is 2:2, unlike Linux's default 3:1. 2:2 seems a bit excessive to me, but ah well; i haven't thought that much about it. I know there are issues in 3:1 for stuff like page tables on large memory machines). If you're thinking of the bad old days of 16-bit Windows, please say so; it's important to know that you're comparing a broken OS implementation.
The module-init-tools link is valid, but you really should read this if you want to try 2.5 and haven't been following the development.
A few PALs and an FPGA would be cheaper, but it wouldn't be as much fun. The whole appeal of a project like this, I imagine, is building stuff up from the ground up. That's why Linus started a multitasker to learn about the 80386, and why I'm writing a game now that talks to Xlib directly as one of its backends. (Another potential graphical backend is VBE framebuffer, but I think the DOS port is an idea that's far past its life. Still, we'll see; I have all my old VBE setup code laying around. Hmm ... I also wrote some simple protected mode code in those days, but never got to multitasking. Sigh.)
:D
Oh, and in the industrialized world, 90 hour work weeks and sub-standard working conditions are an American phenomenon these days. The French, for example, get enough leave to blow your mind
The point is that DRM could be used to subvert the GPL. Okay. How? Explain clearly and completely, and I'll listen. ^_^ If that's where you were going with your situation in the parent post, I think you need to do some more explaining.
Since I've already replied to three messages this way, and a lot of people seem to be missing the point ...
Okay. First of all, DRM is NOT synonymous with "digital copyright protection", okay?
Second. Linus is NOT saying "DRM is good" or "copyright protection is the shiznit". He in fact says in the message that a lot of uses for DRM he doesn't like.
Third. An example of what this article is actually talking about is cryptographically signing a regular, run of the mill built-by-Linus kernel image, somehow providing the signature along with the image at boot, and refusing to load it if the signature doesn't match. Since you don't modify the kernel itself, the GPL has no scope here, so it's obviously not prohibited under the terms of the GPL.
Fourth. This does NOT allow magically modifying the kernel image, nor does it allow magically allow copyright protection in the kernel, nor does it allow hiding private keys in the kernel, etc.
READ THE ARTICLE. Turn off your Slashdot "omg wtf it says drm so it's bad, lol" meme. Linus is not selling your souls to Jack Valenti here.
You're missing the point.
Cryptographically signing a kernel image is not modifying it. That's like saying taking a picture of a book cover and recording all the pixels so I can see if it gets damaged is changing the book cover. What's getting brought up is basically making a cryptographic signature of a kernel image, somehow providing that to boot firmware when you want to go load the image, and refusing to boot if the image and signature don't match.
Go reread the mail.
In Soviet Russia, the point misses YOU!
Nowhere in this message does Linus even begin to talk about RIAA-driven media protection schemes. Why are you even bringing it up in this post? "Digital copyright protection" IS NOT the be-all and end-all of DRM.
Try reading the message again. Linus brings up the exact same point you did: "hiding" a private key in GPLed source is obviously not okay because it exposes the private key. And how does "wrapping it up in a shared lib" "violate everything OSS stands for"? Or are you conveniently overlooking the entire point behind the LGPL? Nevermind that shared libs don't even make sense at the kernel level.
Linus' message has nothing to do with Winputers or the RIAA or forcing you to run/not run whatever because some guy in a suit in Hollywood doesn't trust you with things that aren't his anyway. There's nothing to see here. Move along.
What you're missing is the point.
Say I have a machine that has uber-top-secret data or whatever on it. I want to make sure that all the code that runs on it comes from "trusted" source. (I do this because I know the code may have mistakes or exploits in it, and this doesn't protect me from that, but it makes it less likely that I run code with trojans in it if I at least have proof of where it comes from.)
So, my machine has a cryptographic check in its firmware: instead of taking a kernel image and just booting it, it takes the kernel image and an accompanying signature tacked to the end of it and checks the signature against Linus' public key. If it matches, it boots. If not, it provides some sort of warning (flashing alerts on screen, sirens, whatever).
Linus, in his message, is saying that it's perfectly okay for me to do all of that. Not in so many words, but that's a valid example of "rights" management by digital signature, which he's saying the GPL can't prevent you from doing.
Remember, DRM is not just "digital copyright protection" as so many people on Slashdot seem to enjoy thinking.
Try rereading the message. What Linus is, in fact, saying, is that DRM of the Linux kernel is okay. So, for example, you can digitally sign a kernel binary and have your platform refuse to boot if there isn't a valid signature if it floats your boat. He's also making the case that this is a valid action under the GPL. He never said "I like DRM in most fashions"; in fact, he said something rather the opposite of that at least once in this morning's message:
Err, crap. Actually you're right. I did a more extensive search on this and realized that I totally misremembered. I apologize and retract that statement, don't know what I was smoking yesterday ^^; (Just refound the AC message that said it might be about a 5-10% slowdown. Note to self, do not post in a rush! >_> )
Ahh. Well, that's understandable. :D
See, SPARC doesn't have that silly 4GB addressing limitation that IA-32 does. Running "without PAE" on a Sun box makes no sense because it's an "extension" that only x86 is afflicted with. I bet any of the free Unix-like systems would run fine on sane architectures with 10GB of RAM, too ...
PAE never really excited me. I mean ... it's like EMM386, with 4GB instead of 1MB. It's a hack, and from what I hear (that is to say, what Will Irwin has said on LKML) PAE is fairly slow compared to regular memory, anyway. (And regular memory is already fairly slow compared to core CPU clock speeds, even with high-speed DDR.)
I won't say people don't do >4GB on x86, because obviously they do, but there are reasons not many people do. :3
I misread that bit. It's really that simple. Thanks, SlashBot! :D
Nonono. I'm not really complaining about it. I know the limit of what I can expect as a consumer of free software. I'm just pointing out my opinion that maybe mplayer isn't the best thing since sliced bread after all. :3
Of course each person has the option of not downloading and using the windows binaries, but I will guarantee that for those who use mplayer as their main video player, when they have the choice of using mplayer's .dll loading capabilities or switching to another video player that has a native linux decoder, they will stick with mplayer.
Wrong. Most of my computers can't run Windows binaries. (In fact, the computer I've come to use the most runs a PowerPC 750.) After all, not all the world's an x86. I'll take my native decoder, thanks. That way I can actually watch stuff.
mplayer? Plays everything? You obviously don't use powerpc-*-linux or alpha-*-linux
I'm so discouraged by this I just need to stop and agree ...
... damn, did it make me laugh XD
I've been sitting in the IRC channel for a popular icculus game recently and every day someone brings up (again) the "we need OpenGL support" topic.
Now, you can't do this in general, but today on LKML I saw what I consider to be a contender for greatest message ever
From: Alan Cox
Subject: Re: poweroff problem
On Sad, 2003-04-05 at 07:08, Anant Aneja wrote:
> also i cant give u the complete listing of the cpu
> registers since it occurs at the last stage
> of shutdown and i cant copy it to a file
> and am too lazy to write it down
We are too lazy to help you.
Goodbye
Alan
FreeBSD, at least as of 4.5, does not have a GUI installer. That means it's right out.
Or are you implying that GNOME applications in FreeBSD magically have context-sensitive help?