No offense, but let me ask you one question: why do you live there?
Most people take accessibility (roads, electricity, water, phone, broadband) into account when moving somewhere. Rural areas might be dirt cheap, but shops might be more expensive, and accessibility suffers. (many people live in cities for these very reasons, even THOUGH it's more expensive)
I can understand very well that you'd like your country to fund net neutrality, or even broadband for you, but why should they pay for your decision to live there?
Just because there's no market in the current (static) situation, doesn't mean there's no (dynamic) market!
As soon as providers would actually start to be non-net neutral, there might be enough users in a given place to either buy from a (new) alternative provider, or even start their own.
Competition (and monopolies) aren't static, they are dynamic. Even if there's no competition, the mere possibility of competition prevents the market players from doing just *anything*. If they did that, there'd be competition rather quickly.
I thought it was only about some data that's supposed to be private (like the encrypted hard disk, or maybe every person having a single data card where your doctor, your gas station etc. can store persistent data that only they can read, like a cookie), but of course for authentication the issue is very different.
Um, why does the chip, i.e. the hardware, have to support encryption?
Why not just store *encrypted* data on it? My hard disk doesn't support encryption, but I can store encrypted files (even partitions) on it nonetheless.
I don't get this. The price difference between a computer system + RFID reader/writer and one that also supports encryption should be zero. I think ANY computer system nowadays is perfectly capable of encrypting data.
If you only write a small program for a niche audience, i.e. your mentioned $5 shareware, that might not matter. Probably there'll not even be a patent troll to bother with you.
But if you actually write software that's excellent and competitive, and that competes in the mainstream field (i.e. has a large potential audience), you'll get sued immediately.
Patents don't protect innovation; they protect big players from competition. A small inventor can't profit from patents, because he's likely violating dozens of them himself.
Especially if you take into account the actual damage, which is - at most - as high as the number of CDs you could *actually* have bought with your income.
A raid is very likely much more expensive than that. Who pays it? Oh, you, and the taxpayer.
I love the way today's government makes us pay for our own slavery and fascism.
The problem is government spending out of control.
I don't know exactly how much typical state expenditures rose, but if we could reduce the federal budget to what it was only ten years ago, we could simply cut lots of taxes altogether.
I remember a magazine headline "G4 vs Pentium 3". Yes, G4. I think the P3 didn't run faster than 1000MHz either, more like 6-800, with G4s running at 4-500.
I haven't used Solaris much, but I think it's the same on Linux, BSD, or the Mac. Of course the exact system calls could change, if convenient, as long as the C API remains constant.
Typical Mac software uses BSD functions, and Mach functions (AFAIK Cocoa does), so as long as the Unix stuff and some kind of messaging remains intact, the kernel can change.
Thanks for your correction, but I don't think it makes my argument worse. Basically this means that system calls don't have to be cloned, but the API surrounding the kernel has to be cloned.
Ahuh. Would you then care to explain why on PPC any typical gcc-compiled function decrements the stack pointer on function entry and re-increments it when it's done, just like on x86?
That are open (http://cvsweb.netbsd.org/bsdweb.cgi/src/) and portable across BSD-compatible kernels anyway, yes.
So it's just about the kernel. Well, there used to be (working for some Mac apps, though alpha-quality!) Darwin-ppc emulation on NetBSD, not sure where it is right now, or how easily it could be ported to x86.
I ask you because you're an actual user of Darwin/x86 then.
What exactly is it that made Darwin compile but prohibits it from compiling right now?
Couldn't you (not you, just anybody) track down the changes made in recent version of Darwin - i.e. only changes relevant to the running system, i.e. only new system calls or changed system calls, plus the driver/kext interface - and incorporate them into the once-working x86 Darwin kernel?
I don't quite see why a kernel that (I assume...) has a semi-documented, stable interface, couldn't be cloned with open-source efforts. AFAIK it's mostly Mach calls + BSD calls, plus maybe some proprietary syscalls, and the kext layer, which is AFAIK documented for developers, though.
...trying to figure out Apple's true motivations is always a crap shoot.
Like... the motivation that billions of PC owners out there won't be able to compile a working Darwin kernel and install the rest of (pirated) Mac OS on top, without buying a nice, shiny Mac?
Good question. The only problem with continuing work on Darwin would be that any improvement you make could be taken by Apple into their proprietary kernel. Ok, no big news there.
To address the viability: I'm not familiar with Darwin (I've never compiled my own Mac kernel, nor used Darwin on x86), but speaking from Unix experience I'd say that there has to be some stable kernel API/syscall interface that you could clone either in a new development, or by continuing the Darwin source. The (closed) rest of Mac OS shouldn't notice if it runs on a non-apple kernel, because any syscalls could be emulated (there even used to be a Darwin-ppc emulation layer for NetBSD which could run some Mac apps! maybe we should adapt NetBSD to have a nice, BSD-licenced Darwin interface?).
I'm not sure exactly what aspects of Darwin/x86 prohibit building it. OTOH Darwin *used to* run on x86, so there has to be a functioning x86 layer for task switching, memory management, PCI, and stuff like that. OTOH, if they say that D/x86 doesn't compile, that means that D/ppc *does* compile, so that you could merge the current version of D/ppc with the hardware layer of older D/x86 kernels.
Sure, it'll be a hell of a lot of work, with the only real use being able to run Mac OS on non-apple machines (who needs their own kernel on a Mac?)... OR to merge this with GNUstep into a Mac OS clone à la ReacOS (for Windows).
PPC makes it much harder... to run code after overflow since it'll clear the stack.
Clear what stack? The only meaningful difference between PPC and x86 regarding buffer overflows is that PPC has more registers (including a link register which won't be saved by leaf procedures), and that the x86 CALL instruction pushes its value on the stack.
A buffer overflow would simply overflow some buffer, and be engineered so that it will overwrite the stack frame's return address to call some other code (which is also in the overflowed buffer).
Now on Intel every procedure has a return location on the stack, while on PPC only non-leaf procedures do, but since all computation happens in the context of *some* call stack, there will always be a parent procedure that has a return value that just waits to be overwritten.
I'm not sure how PPC can "clear" the stack, or with what purpose.
Slashdot Mirror
No offense, but let me ask you one question: why do you live there?
Most people take accessibility (roads, electricity, water, phone, broadband) into account when moving somewhere. Rural areas might be dirt cheap, but shops might be more expensive, and accessibility suffers. (many people live in cities for these very reasons, even THOUGH it's more expensive)
I can understand very well that you'd like your country to fund net neutrality, or even broadband for you, but why should they pay for your decision to live there?
Just because there's no market in the current (static) situation, doesn't mean there's no (dynamic) market!
As soon as providers would actually start to be non-net neutral, there might be enough users in a given place to either buy from a (new) alternative provider, or even start their own.
Competition (and monopolies) aren't static, they are dynamic. Even if there's no competition, the mere possibility of competition prevents the market players from doing just *anything*. If they did that, there'd be competition rather quickly.
Thanks, very informative.
I thought it was only about some data that's supposed to be private (like the encrypted hard disk, or maybe every person having a single data card where your doctor, your gas station etc. can store persistent data that only they can read, like a cookie), but of course for authentication the issue is very different.
You can bet your ass the MPAA has insiders in various government positions.
If there was a raid being planned, the MPAA would know about it and take protective action on time.
Um, why does the chip, i.e. the hardware, have to support encryption?
Why not just store *encrypted* data on it? My hard disk doesn't support encryption, but I can store encrypted files (even partitions) on it nonetheless.
I don't get this. The price difference between a computer system + RFID reader/writer and one that also supports encryption should be zero. I think ANY computer system nowadays is perfectly capable of encrypting data.
Exactly.
If you only write a small program for a niche audience, i.e. your mentioned $5 shareware, that might not matter. Probably there'll not even be a patent troll to bother with you.
But if you actually write software that's excellent and competitive, and that competes in the mainstream field (i.e. has a large potential audience), you'll get sued immediately.
Patents don't protect innovation; they protect big players from competition. A small inventor can't profit from patents, because he's likely violating dozens of them himself.
Especially if you take into account the actual damage, which is - at most - as high as the number of CDs you could *actually* have bought with your income.
A raid is very likely much more expensive than that. Who pays it? Oh, you, and the taxpayer.
I love the way today's government makes us pay for our own slavery and fascism.
Oh wait... nevermind.
100% ACK.
Now could somebody explain why my simple observation was modded Troll?
The problem is government spending out of control.
I don't know exactly how much typical state expenditures rose, but if we could reduce the federal budget to what it was only ten years ago, we could simply cut lots of taxes altogether.
Both Reps and Dems have stopped making sense a long time ago (and actually have stopped making very different politics).
It's all the same new world order, big government bullshit.
http://www.notonwo.com/
we know that "they" don't have to be too strict about human testing, so expect this to hit the market ... tomorrow.
http://www.harpers.org/OutOfControl.html
I remember a magazine headline "G4 vs Pentium 3". Yes, G4. I think the P3 didn't run faster than 1000MHz either, more like 6-800, with G4s running at 4-500.
I haven't used Solaris much, but I think it's the same on Linux, BSD, or the Mac.
Of course the exact system calls could change, if convenient, as long as the C API remains constant.
Typical Mac software uses BSD functions, and Mach functions (AFAIK Cocoa does), so as long as the Unix stuff and some kind of messaging remains intact, the kernel can change.
Thanks for your correction, but I don't think it makes my argument worse. Basically this means that system calls don't have to be cloned, but the API surrounding the kernel has to be cloned.
The PPC stack grows the opposite way.
Ahuh. Would you then care to explain why on PPC any typical gcc-compiled function decrements the stack pointer on function entry and re-increments it when it's done, just like on x86?
Good question.
Even Solaris comes with source these days...
That are open (http://cvsweb.netbsd.org/bsdweb.cgi/src/) and portable across BSD-compatible kernels anyway, yes.
So it's just about the kernel. Well, there used to be (working for some Mac apps, though alpha-quality!) Darwin-ppc emulation on NetBSD, not sure where it is right now, or how easily it could be ported to x86.
I think it's APSL, which is another license: http://www.opensource.org/licenses/apsl.php
I haven't read it, but it's a rather long legalese text (unlike BSD). It may or may not be relicensable.
I ask you because you're an actual user of Darwin/x86 then.
What exactly is it that made Darwin compile but prohibits it from compiling right now?
Couldn't you (not you, just anybody) track down the changes made in recent version of Darwin - i.e. only changes relevant to the running system, i.e. only new system calls or changed system calls, plus the driver/kext interface - and incorporate them into the once-working x86 Darwin kernel?
I don't quite see why a kernel that (I assume...) has a semi-documented, stable interface, couldn't be cloned with open-source efforts. AFAIK it's mostly Mach calls + BSD calls, plus maybe some proprietary syscalls, and the kext layer, which is AFAIK documented for developers, though.
...trying to figure out Apple's true motivations is always a crap shoot.
... the motivation that billions of PC owners out there won't be able to compile a working Darwin kernel and install the rest of (pirated) Mac OS on top, without buying a nice, shiny Mac?
Like
Good question. The only problem with continuing work on Darwin would be that any improvement you make could be taken by Apple into their proprietary kernel. Ok, no big news there.
To address the viability: I'm not familiar with Darwin (I've never compiled my own Mac kernel, nor used Darwin on x86), but speaking from Unix experience I'd say that there has to be some stable kernel API/syscall interface that you could clone either in a new development, or by continuing the Darwin source. The (closed) rest of Mac OS shouldn't notice if it runs on a non-apple kernel, because any syscalls could be emulated (there even used to be a Darwin-ppc emulation layer for NetBSD which could run some Mac apps! maybe we should adapt NetBSD to have a nice, BSD-licenced Darwin interface?).
I'm not sure exactly what aspects of Darwin/x86 prohibit building it. OTOH Darwin *used to* run on x86, so there has to be a functioning x86 layer for task switching, memory management, PCI, and stuff like that. OTOH, if they say that D/x86 doesn't compile, that means that D/ppc *does* compile, so that you could merge the current version of D/ppc with the hardware layer of older D/x86 kernels.
Sure, it'll be a hell of a lot of work, with the only real use being able to run Mac OS on non-apple machines (who needs their own kernel on a Mac?)... OR to merge this with GNUstep into a Mac OS clone à la ReacOS (for Windows).
PPC makes it much harder ... to run code after overflow since it'll clear the stack.
Clear what stack? The only meaningful difference between PPC and x86 regarding buffer overflows is that PPC has more registers (including a link register which won't be saved by leaf procedures), and that the x86 CALL instruction pushes its value on the stack.
A buffer overflow would simply overflow some buffer, and be engineered so that it will overwrite the stack frame's return address to call some other code (which is also in the overflowed buffer).
Now on Intel every procedure has a return location on the stack, while on PPC only non-leaf procedures do, but since all computation happens in the context of *some* call stack, there will always be a parent procedure that has a return value that just waits to be overwritten.
I'm not sure how PPC can "clear" the stack, or with what purpose.
Because we need the Gattaca brave new world for our safety!!1!!eleven!!!
Pfft, harmless.
OTOH, life after slashdot seems to prove rather difficult for the site.
Much more importantly, May 25th is Towel Day ;)