Software support is hard enough just in a niche (for example, imagine Dantz's headaches supporting Retrospect and the endless combinations of host/adapter/drive!)
It would have been better for Apple to support the standard UNIX tape interface instead. Then we wouldn't need to use Retrospect... we could use existing UNIX backup software from "dump" and "tar" up through "Amanda" and "BRU".
We need only look at Darwin/x86 to see what a dismal base they'd be starting from on the driver front.
Not necessarily. I've run drivers in Mac OS X using the "legacy" BSD driver APIs instead of Apple's IOKit: the old Adaptec SCSI drivers from NetBSD. There's some shortcomings, for example the BSD API doesn't support sleep the way Apple does it, but they do work.
I don't know how hard it would be to convert these drivers to run under IOKit, but there's a huge pool to start with.
The reason the threat from the private sector is so high is the government provides the private sector with artificial monopolies... essentially renting the private sector the ability to use government force by proxy... without anything like the kind of oversight that the government's agents themselves are subject to.
In most countries in the Western world, if I try to expose an abuse or a mistake by the government, there are departments and agencies throught the government to provide a mechanism for me to safely release this information or to protect me if agents of the government attempt to prevent me from speaking. If I try to expose an abuse or a mistake by the private sector those protections are much weaker or nonexistent, and in some areas (ironically, areas most relevant to free speech), I can be arrested, sued into perpetual bankruptcy, or if applicable deported.
And that's without considering the effectiveness with which the two groups can cover things up. Thanks to the FOIA even major deliberate abuses by people acting within the government are public knowledge, whereas cases where people in the private sector may have merely ignored information that might have prevented harm are permanently locked under court order as part of settlements.
Now, let's consider Microsoft:
Even though Microsoft has achieved (by every measure that seems sensible to me) monopoly status, I'm not forced to use it.
If you need to view material that is published in Protected Windows Media format, you are forced to use Microsoft Windows to view it, because it's actually illegal for anyone else to write and distribute a program that can read and display these files. There is an increasing tendency for both private and government agencies to release information in proprietary formats like Real, Quicktime, or WMV/WMA. Protected Windows Media format is being included in many new distribution and media standards.
How do you keep from paying Microsoft when by law every television set in the US contains Microsoft software?
When {President,Represenative,Senator,Judge} So-and-so does something that screws me, I'm just screwed.
Most of the examples I've seen lately of people being screwed by Pres/Rep/Sen/Hizonner so-and-so in order to restrict their freedom of speech have been initiated by the private sector using the courts as "hired coercive force"... most often under the cover of alleged contract or copyright violations. It's MUCH safer to release pictures of prison abuses than an analysis of flawed source code.
About two million copies of Tiger have been sold since April, that is about a quarter billion dollars in revenue if you don't count any sort of discount pricing (student etc.).
Let's say the margin on a Mac or an iPod is about 40% (that's a widely quoted figure), so earnings (well, EBIT) on the 3.5 billion was... let's call it a billion and a half.
How many copies of Tiger would have been sold if anyone in the US with a PC could have bellied up to the bar and bought one and taken it home and run it on their PC? 10 million? 20 million? 50 million? Windows XP sold 17 million copies in the first 2 months in 2001. PC sales have increased 50% since then, so I don't think 20 million in the first quarter would be unreasonable... considering that's 2 million Tiger sales to 2.5% of the PC market.
That would mean you're talking revenues of 2.5 billion. Now the margin on desktop Windows is allegedly 86%, and this is just back-of-the-envelope stuff, let's say Apple does as well. That's 2 billion dollars EBIT even if Apple doesn't sell a single Mac or ipod, *and* sells Tiger for $130.
XP Home actually retails for $200, and Apple could certainly sell Tiger Intel for that... which would raise all those numbers by about 50%, or about twice as much earnings from software sales as they made from hardware.
Now that's assuming that generic OS X on Intel would sell 10 times as many copies as it does now, but it also assumes Apple doesn't make another penny from the Mac, the iPod, iLife, iWork, or anything else... just Tiger. I could easily see another billion income (not revenue) just from their other software...
I don't think this is an impossible or even improbable scenario. Risky, yes, so I'm not surprised Apple's apparently not risking it. But hardly outrageous.
Nobody seems to have figured out that there are much more difficult things to solve before OS X can "run everywhere"
Personally, I don't care where else it runs, but I want it to run on a Thinkpad. The Thinkpad hardware is so far ahead of the 'books that it's practically a tragedy that Apple didn't continue their relationship with IBM Japan after the PB2400.
before people fly off the handle on media rights, perhaps we ought to wait until it ships?
I'm not flying off the handle. I'm simply explaining why I care about the existence of DRM software in the Mac OS X kernel.
I'm actually kind of disappointed with Apple. They could have done a lot better job of it. For example, they could put the check in the video drivers (even make it also depend on some Apple OpenGL extension that only worked in a GenuineApple computer, if the video card could be made to "see" the Infineon chip), so that you could only run accelerated on a real Mac... turning piracy into "crippleware" marketing.
As far as the GPL is concerned, it doesn't matter what the component is, it only matters how the component interacts with a GPLed program. In particular, the GPL reqires that anything that is linked to a GPL program is covered under the GPL. Linus has specifically listed the exceptions that he allows.
In the case of networking, Linux gives you a userspace API for directly modifying the packets sent over the network. [...] Linux explicitly excludes userspace from the GPL in its license
That's fine, but then this isn't a kernel component any longer. I'm not concerned with the behaviour of non-kernel components because unless they're protected by kernel components (as they are in Windows NT) they can always be shimmed.
to take the case of crypto signing, the private key never leaves the chip
But we're not talking about crypto signing here, we're talking about DRM. To be useful for DRM the crypto chip would have to (a) be powerful enough to perform the decryption itself and have a protected path to the output device, or (b) pass a key to a component outside the crypto chip but still protected by the DRM software that can perform the decryption and pass the result over a protected path to an output device.
If neither of these cases hold, the DRM is no more secure than DRM implemented entirely in userspace.
Now, DRM implemented entirely in userspace can be strong enough to deter enough people for it to serve the economic purpose of DRM... The success of the iTunes Music Store demonstrates that it doesn't even have to be as strong a DRM as would be possible to implement in userspace to do that job... Fairplay is actually a relatively easy system to compromise.
And that brings us back to my point: implementing DRM in a GPL-ed kernel would be futile, because it would not be any harder for someone to write a "click-and-go" tool that would defeat it than it would be for someone to do the same thing for DRM implemented entirely in an application.
That is, it's not that the DRM would be futile from the point of view of the publisher who simply wants to encourage sales and reduce unapprooved sharing, it's that moving the DRM into a GPL-ed kernel would be futile from the point of view of the publisher who wants something stronger than that.
I care about Apple putting DRM support in the OS X kernel because I don't see DRM support in the kernel being a good thing for the future of OS X as a general purpose desktop. If they just use it for copy protection of OS X itself, that's one thing. If they go on to use it for increasing the strength of the "honor system"-level DRM in iTunes, or for some potential "iTunes Video Store", that's another.
I don't want to play music or watch videos on my Mac enough to make it worth the kinds of restrictions that something comparable to Microsoft's IRM would require.
why in the world would I want to spend $500 on a crappy Mac Mini when I've got an Athlon X2 sitting on my desk?
Because you can't run Mac OS X on your Athlon X2?
I mean, that's a simple bloody question. You know the answer. Whether you believe that OS X is worth the "Mac Tax" or not is beside the point, you know why you might want to pay it.
If you don't want to pay it, don't pay it, but don't pretend you don't understand what it's all about.
Mac OS X costs $130, which is less than Windows XP. Now, most generic PCs are sold with little or no margins, so you can consider the sales cost to be comparable to the production costs. Apple gets pretty good margins, so you can look at the "Mac Tax" to figure out what else they are making on the box. That's about $150-$200 on the mini (depending on whether you insist on the comparable PC having EXACTLY the specs of the mini, or you count things like extra USB ports or the ability to upgrade the video against the mini), so you could expect OS X for generic intel (if Apple sold such a thing) to cost at least $300 for Apple to avoid taking a loss... assuming their sales of OS X intel were comparable to the loss of sales of Mac minis.
You can perform similar calculations on other models, and come up with what Apple would need to sell OS X for if it's going to be a good business decision for them, IF they sell as many copies of OS X as they do now, AND their other costs stay about the same. It's not likely to be as low as $200.
Whether the total sales would go up or down or stay the same, that's another question. I've heard arguments all three ways, and I don't know enough to say which ones I believe. I would LIKE to believe sales would go through the roof and make Bill Gates cry...
I switched to Mac as soon as I was able to install Mac OS X 10.1 on a Powermac 7500 with an upgraded CPU (first a 240 MHz pre-G3 processor, then a Sonnet Crescendo G3/400). I had to use XPostFacto to even get it to load, then find a third-party floppy driver, a third-party patch for the disk burning framework to get the CDROM to work, and just generally screw around on and off for over a week to get it to work.
It was a lot harder than just about anything I've installed on Wintel hardware... certainly harder than anything I've gone on to actually use. And it still rocked enough to keep me using it and eventually upgrading to the first *new* computer I've bought for myself in 10 years.
I would not want an OS X that could run on Compaqs to Dells to A Opens to your custom PC because then I wouldn't get uptimes of 90 days
Here's uptimes of three of the generic Wintel boxes I run FreeBSD on:
About the only ones that aren't this good are ones that aren't on a good UPS.
Surely Apple can do as well as a group of open-source volunteers... especially considering they've hired Jordan and are using FreeBSD code in the Mac OS X kernel.:)
If your crypto cant withstand its source being looked at, it isnt crypto, it's crap.
That's right. That's the fundamental reason why Hollywood wants hardware DRM, because DRM turns into crap as soon as its exposed to the air.
Good crypto depends on having a good algorithm and making sure that the attacker doesn't have access to either the plaintext or both the ciphertext and the key needed to decipher it. The problem with DRM is that either the recipient is also the attacker, so the recipient has the ciphertext and the key... all you can do is protect the algorithm... or the recipient is a piece of hardware owned by the attacker under the attacker's physical control and you have to keep the attacker from copying the plaintext... while you're simultaneously showing it to them.
This is a hard problem. Actually, it's an insoluble problem if the attacker is determined. All you can do is make it hard enough for the non-determined attacker by doing things like obfuscating the algorithm or obsessively monitoring more and more output stages to try and make sure that any copy the attacker can make is of low enough quality that they don't bother... while at the same time letting them listen to and/or look at a copy that's good enough that they'll actually buy it.
When the attacker controls the operating system the DRM module is running on, they can bypass the DRM by observing the key manipulations and reproducing them, by intercepting the decrypted stream from a decryption device, or by intercepting the decrypted stream between the application and the device driver. If the application monitors the device driver, you can perform a man-in-the-middle attack so that neither the application nor the device driver knows that it's being observed. If the stream between the application and the device driver is encrypted, you can modify the application to extract the unencrypted intermediate stream, or a replayable encrypted intermediate stream, or the token required to authorize the stream...
Unless you put the DRM in the playback device (video card, audio card, etc) itself, and the application simply acts as a blind intermediary for the authentication process just as if it were a router or switch between the computer and the DRM authorizer (music or video store), you can't allow the user unrestricted access to the operating system kernel as you would have in an open-source OS.
One could have a propriety networking stack working over Ethernet just as easily on Linux as on Windows.
Well... that depends on how Linus is feeling about the GPL that week. Linus has said that certain kinds of non-GPL kernel components are allowed, but it's not always clear what those are: there's certain calls that are known to be non-OK, and certain kinds of components that are pretty much blesses, but there's a certain amount of uncertainty involved. After the Sveasoft incident, I suspect that proprietary network code (other than device drivers) in a GPLed kernel would be hard to justify.
All of the DRM stuff would be built on top of the TPM driver, not part of it.
Understood. My point is that if you have the source to the TPM driver, or if you have the source to any of the code that the DRM application uses to communicate to the TPM driver (and you would... the system call interface at least) the DRM would not be any stronger, when you come down to it, than the same code running on a system where the DRM was entirely in user-space.
Because people pay cash for the right to use OSX, and with that comes certain restrictions.
You can't enter into a contract after purchase, and you can't enter into a contract if you haven't seen the terms of that contract. Except for the case of clickthrough license in an online purchase, where you have an opportunity to read the license before use, the basis of the EULA is copyright law, not contract law... either by restricting your right to copy the code to computer memory before using it (the legal fiction I mentioned), or by explicit clauses in copyright law in the nation you live in.
I couldn't give a damn about a BSD derivative 'under the hood' of OSX if the rest comes with handcuffs.
Then you don't actually care if the OS is rented or bought, because either way the software you need to run to play the music you bought can come with handcuffs. The existence of OSX is proof of that.
This will be laughed at in years to come. "People actually paid for that?"
I'm afraid that, to the contrary, this will be remembered as the end of the golden age.
Both OSX and Windows are rented operating systems.
Because they use copyright law to enforce a compulsary license? So does Linux, so does BSD (though that license has been pretty watered down by now). Anything that's not in the public domain does that.
If you're talking about the actual terms, well, there's ways to use an open-source "unrented" operating system and impose additional terms on the whole system you buy. There's Linux-based systems that do that. Heck, OSX is built that way... when you boot OSX you start by booting Darwin/XNU, and OSX runs on top of that... so millions of prople are already playing restricted-use media a non-rented OS...
What does it mean to have TPM support in a GPL-ed kernel?
It means a software component can securely extract keys from hardware.
Does it mean that it can securely do anything with the keys? When the kernel can (for example) wrap tpm_read() with code that copies everything it reads for later replay? Or trap to an invisible code tracer on tpm_open()? Or just start saving everything that the program write()s so the program itself becomes a cracker for whatever DRMed content you're trying to protect?
There's lots of things you can do with TPM in an open-source kernel, but DRM isn't one of them.
[Your] retort to my argument is that it's wrong because I'm a Libertarian?
No, my response is that my experience with big-L-libertarians is that we're operating from such different axioms that it's futile to continue this debate. That doesn't mean that I'm right, or that you're wrong, it just means that I believe things you don't, and you believe things I don't.
For example, I believe that the difference between direct coercion by a representative government and indirect coercion by a non-accountable organization using the power of the state to enforce contracts is not significant. I believe that there are so many communication channels available to individuals today that government censorship is no more effective than any other kind of censorship, and the biggest current threat to our freedom of speech comes from the private sector.
You don't believe these things, and I don't believe that I can convince you of these things, and I'm not even sure I should try to convince you because even if I'm right I believe it's important that there's people unwilling to grant the government one inch of power even if I think they do need that power... so I'm not going to try.
microsoft's problem is the complete opposite as this one. microsoft is trying to prevent unsigned code from running on "their" hardware.
The question is... once they have the DRM support, what will they do with it?
FairPlay that actually works?
Make sure you have good backup copies of your iTMS music on audio CD or (cough cough) otherwise. Not so you can warez it, but so you can keep playing it on your PPC Mac if iTunes switches to requiring Intel DRM support to decode iTMS tracks.
Also: if they're actually planning on supporting strong DRM (hint: Video), they're going to have to think about closing the Darwin source.
Here I am, releasing Trusted Linux. Here's the GPL-ed kernel, and because it's GPL here's the source to the DRM component that's linked with the GPL-ed kernel. Now none of you buys download the source to the DRM code and modify it, y'all hear, that would be naughty.
It's even hard to see how you'd get away with DRM in an open-source kernel, since if everything in the kernel except DontTouchMeImTheDRMCode() is available in source, the opportunities for bypassing DontTouchMeImTheDRMCode() DRM are unlimited.
The time to panic is when 10.4.7 or so is released on the new Intel Macs and Darwin 8.7 doesn't show up on Apple's website. Right now we should be in pre-panic mode.
The Apple Panic Alert level is: [A Nice Hot Cup of Tea].
First, it assumes that businesses survive because of merit. Exhibit A: BeOS.
The OS that was released half-finished on hardware that was half-finished, and that was sustained by sales of incomplete betas? The OS that uses the worst object-oriented language in existence as a core part of its API? The OS that was never released with production quality TCP/IP support, at a time when the Internet was becoming key? The OS that was supposed to be small and fast and sleek and yet required more hardware and a faster processor than any of its competitors (yes, even Windows NT and UNIX) just to boot?
It's only by comparison with "classic" Mac OS (which has also finally got what it deserved... some seven years later than originally scheduled) that BeOS looks good.
If you analyzed the mach_kernel binary file on the Developer Kits, you would see that the kernel is vastly different than the Darwin 8.2 that Apple released as open source.
The software shipped with the developers kits isn't any of the released software, so there's no reason to assume that the released version of Darwin would match it. Apple didn't release the source to Darwin 8.0 when developers got Tiger, but rather when it shipped.
Someone put together a script that pulls up software patents (or lets people suggest them) and rates them. People can go through and hit an "obvious" or "unobvious" button to see the next patent.
Engineers whose names are on the most "obvious" patents each month would get a boobyprize.
Give people an incentive NOT to put their names on stupid patents.
OK, you're one of those hardcore impractical Libertarians-with-a-capital-L who can't recognise a negative externality unless it's imposed by the government. I do appreciate that it's useful to have some of you lot around, but we're clearly not going to get any kind of productive discussion here.
Smalltalk didn't even have self-repairing windows - you had to click in them to get them to repaint, and programs couldn't draw into partially obscured windows.
Aha, that makes a lot more sense. Though they definitely did have them by the time they showed Smalltalk-80 at NCC - I remember being boggled by a demo where a floating window (with a picture of Albert Einstein on it) drifted across the screen on top of other windows.
But it's entirely possible that some earlier versions didn't.
And of course before Mac OS X the scheduler made it almost a moot point, at least as far as having background programs writing into windows was concerned.
Ironically, with "screen-scraping" remote control programs on Windows we have returned to having to click on a window to get it to update.:)
Slashdot Mirror
Software support is hard enough just in a niche (for example, imagine Dantz's headaches supporting Retrospect and the endless combinations of host/adapter/drive!)
It would have been better for Apple to support the standard UNIX tape interface instead. Then we wouldn't need to use Retrospect... we could use existing UNIX backup software from "dump" and "tar" up through "Amanda" and "BRU".
We need only look at Darwin/x86 to see what a dismal base they'd be starting from on the driver front.
Not necessarily. I've run drivers in Mac OS X using the "legacy" BSD driver APIs instead of Apple's IOKit: the old Adaptec SCSI drivers from NetBSD. There's some shortcomings, for example the BSD API doesn't support sleep the way Apple does it, but they do work.
I don't know how hard it would be to convert these drivers to run under IOKit, but there's a huge pool to start with.
The reason the threat from the private sector is so high is the government provides the private sector with artificial monopolies... essentially renting the private sector the ability to use government force by proxy... without anything like the kind of oversight that the government's agents themselves are subject to.
In most countries in the Western world, if I try to expose an abuse or a mistake by the government, there are departments and agencies throught the government to provide a mechanism for me to safely release this information or to protect me if agents of the government attempt to prevent me from speaking. If I try to expose an abuse or a mistake by the private sector those protections are much weaker or nonexistent, and in some areas (ironically, areas most relevant to free speech), I can be arrested, sued into perpetual bankruptcy, or if applicable deported.
And that's without considering the effectiveness with which the two groups can cover things up. Thanks to the FOIA even major deliberate abuses by people acting within the government are public knowledge, whereas cases where people in the private sector may have merely ignored information that might have prevented harm are permanently locked under court order as part of settlements.
Now, let's consider Microsoft:
Even though Microsoft has achieved (by every measure that seems sensible to me) monopoly status, I'm not forced to use it.
If you need to view material that is published in Protected Windows Media format, you are forced to use Microsoft Windows to view it, because it's actually illegal for anyone else to write and distribute a program that can read and display these files. There is an increasing tendency for both private and government agencies to release information in proprietary formats like Real, Quicktime, or WMV/WMA. Protected Windows Media format is being included in many new distribution and media standards.
How do you keep from paying Microsoft when by law every television set in the US contains Microsoft software?
When {President,Represenative,Senator,Judge} So-and-so does something that screws me, I'm just screwed.
Most of the examples I've seen lately of people being screwed by Pres/Rep/Sen/Hizonner so-and-so in order to restrict their freedom of speech have been initiated by the private sector using the courts as "hired coercive force"... most often under the cover of alleged contract or copyright violations. It's MUCH safer to release pictures of prison abuses than an analysis of flawed source code.
About two million copies of Tiger have been sold since April, that is about a quarter billion dollars in revenue if you don't count any sort of discount pricing (student etc.).
... let's call it a billion and a half.
Let's say the margin on a Mac or an iPod is about 40% (that's a widely quoted figure), so earnings (well, EBIT) on the 3.5 billion was
How many copies of Tiger would have been sold if anyone in the US with a PC could have bellied up to the bar and bought one and taken it home and run it on their PC? 10 million? 20 million? 50 million? Windows XP sold 17 million copies in the first 2 months in 2001. PC sales have increased 50% since then, so I don't think 20 million in the first quarter would be unreasonable... considering that's 2 million Tiger sales to 2.5% of the PC market.
That would mean you're talking revenues of 2.5 billion. Now the margin on desktop Windows is allegedly 86%, and this is just back-of-the-envelope stuff, let's say Apple does as well. That's 2 billion dollars EBIT even if Apple doesn't sell a single Mac or ipod, *and* sells Tiger for $130.
XP Home actually retails for $200, and Apple could certainly sell Tiger Intel for that... which would raise all those numbers by about 50%, or about twice as much earnings from software sales as they made from hardware.
Now that's assuming that generic OS X on Intel would sell 10 times as many copies as it does now, but it also assumes Apple doesn't make another penny from the Mac, the iPod, iLife, iWork, or anything else... just Tiger. I could easily see another billion income (not revenue) just from their other software...
I don't think this is an impossible or even improbable scenario. Risky, yes, so I'm not surprised Apple's apparently not risking it. But hardly outrageous.
Nobody seems to have figured out that there are much more difficult things to solve before OS X can "run everywhere"
Personally, I don't care where else it runs, but I want it to run on a Thinkpad. The Thinkpad hardware is so far ahead of the 'books that it's practically a tragedy that Apple didn't continue their relationship with IBM Japan after the PB2400.
before people fly off the handle on media rights, perhaps we ought to wait until it ships?
I'm not flying off the handle. I'm simply explaining why I care about the existence of DRM software in the Mac OS X kernel.
I'm actually kind of disappointed with Apple. They could have done a lot better job of it. For example, they could put the check in the video drivers (even make it also depend on some Apple OpenGL extension that only worked in a GenuineApple computer, if the video card could be made to "see" the Infineon chip), so that you could only run accelerated on a real Mac... turning piracy into "crippleware" marketing.
But we're talking about a stack here.
As far as the GPL is concerned, it doesn't matter what the component is, it only matters how the component interacts with a GPLed program. In particular, the GPL reqires that anything that is linked to a GPL program is covered under the GPL. Linus has specifically listed the exceptions that he allows.
In the case of networking, Linux gives you a userspace API for directly modifying the packets sent over the network. [...] Linux explicitly excludes userspace from the GPL in its license
That's fine, but then this isn't a kernel component any longer. I'm not concerned with the behaviour of non-kernel components because unless they're protected by kernel components (as they are in Windows NT) they can always be shimmed.
to take the case of crypto signing, the private key never leaves the chip
But we're not talking about crypto signing here, we're talking about DRM. To be useful for DRM the crypto chip would have to (a) be powerful enough to perform the decryption itself and have a protected path to the output device, or (b) pass a key to a component outside the crypto chip but still protected by the DRM software that can perform the decryption and pass the result over a protected path to an output device.
If neither of these cases hold, the DRM is no more secure than DRM implemented entirely in userspace.
Now, DRM implemented entirely in userspace can be strong enough to deter enough people for it to serve the economic purpose of DRM... The success of the iTunes Music Store demonstrates that it doesn't even have to be as strong a DRM as would be possible to implement in userspace to do that job... Fairplay is actually a relatively easy system to compromise.
And that brings us back to my point: implementing DRM in a GPL-ed kernel would be futile, because it would not be any harder for someone to write a "click-and-go" tool that would defeat it than it would be for someone to do the same thing for DRM implemented entirely in an application.
That is, it's not that the DRM would be futile from the point of view of the publisher who simply wants to encourage sales and reduce unapprooved sharing, it's that moving the DRM into a GPL-ed kernel would be futile from the point of view of the publisher who wants something stronger than that.
I care about Apple putting DRM support in the OS X kernel because I don't see DRM support in the kernel being a good thing for the future of OS X as a general purpose desktop. If they just use it for copy protection of OS X itself, that's one thing. If they go on to use it for increasing the strength of the "honor system"-level DRM in iTunes, or for some potential "iTunes Video Store", that's another.
I don't want to play music or watch videos on my Mac enough to make it worth the kinds of restrictions that something comparable to Microsoft's IRM would require.
why in the world would I want to spend $500 on a crappy Mac Mini when I've got an Athlon X2 sitting on my desk?
Because you can't run Mac OS X on your Athlon X2?
I mean, that's a simple bloody question. You know the answer. Whether you believe that OS X is worth the "Mac Tax" or not is beside the point, you know why you might want to pay it.
If you don't want to pay it, don't pay it, but don't pretend you don't understand what it's all about.
Mac OS X costs $130, which is less than Windows XP. Now, most generic PCs are sold with little or no margins, so you can consider the sales cost to be comparable to the production costs. Apple gets pretty good margins, so you can look at the "Mac Tax" to figure out what else they are making on the box. That's about $150-$200 on the mini (depending on whether you insist on the comparable PC having EXACTLY the specs of the mini, or you count things like extra USB ports or the ability to upgrade the video against the mini), so you could expect OS X for generic intel (if Apple sold such a thing) to cost at least $300 for Apple to avoid taking a loss... assuming their sales of OS X intel were comparable to the loss of sales of Mac minis.
You can perform similar calculations on other models, and come up with what Apple would need to sell OS X for if it's going to be a good business decision for them, IF they sell as many copies of OS X as they do now, AND their other costs stay about the same. It's not likely to be as low as $200.
Whether the total sales would go up or down or stay the same, that's another question. I've heard arguments all three ways, and I don't know enough to say which ones I believe. I would LIKE to believe sales would go through the roof and make Bill Gates cry...
I switched to Mac as soon as I was able to install Mac OS X 10.1 on a Powermac 7500 with an upgraded CPU (first a 240 MHz pre-G3 processor, then a Sonnet Crescendo G3/400). I had to use XPostFacto to even get it to load, then find a third-party floppy driver, a third-party patch for the disk burning framework to get the CDROM to work, and just generally screw around on and off for over a week to get it to work.
:)
It was a lot harder than just about anything I've installed on Wintel hardware... certainly harder than anything I've gone on to actually use. And it still rocked enough to keep me using it and eventually upgrading to the first *new* computer I've bought for myself in 10 years.
I would not want an OS X that could run on Compaqs to Dells to A Opens to your custom PC because then I wouldn't get uptimes of 90 days
Here's uptimes of three of the generic Wintel boxes I run FreeBSD on:
DL360# uptime
10:57AM up 298 days, 16:10, 1 user, load averages: 0.00, 0.06, 0.06
DL320# uptime
10:57AM up 326 days, 18:33, 1 user, load averages: 0.00, 0.01, 0.00
CLONE# uptime
10:58AM up 715 days, 14:32, 11 users, load averages: 0.02, 0.02, 0.00
About the only ones that aren't this good are ones that aren't on a good UPS.
Surely Apple can do as well as a group of open-source volunteers... especially considering they've hired Jordan and are using FreeBSD code in the Mac OS X kernel.
I don't follow you?
DRM is not like regular crypto.
If your crypto cant withstand its source being looked at, it isnt crypto, it's crap.
That's right. That's the fundamental reason why Hollywood wants hardware DRM, because DRM turns into crap as soon as its exposed to the air.
Good crypto depends on having a good algorithm and making sure that the attacker doesn't have access to either the plaintext or both the ciphertext and the key needed to decipher it. The problem with DRM is that either the recipient is also the attacker, so the recipient has the ciphertext and the key... all you can do is protect the algorithm... or the recipient is a piece of hardware owned by the attacker under the attacker's physical control and you have to keep the attacker from copying the plaintext... while you're simultaneously showing it to them.
This is a hard problem. Actually, it's an insoluble problem if the attacker is determined. All you can do is make it hard enough for the non-determined attacker by doing things like obfuscating the algorithm or obsessively monitoring more and more output stages to try and make sure that any copy the attacker can make is of low enough quality that they don't bother... while at the same time letting them listen to and/or look at a copy that's good enough that they'll actually buy it.
When the attacker controls the operating system the DRM module is running on, they can bypass the DRM by observing the key manipulations and reproducing them, by intercepting the decrypted stream from a decryption device, or by intercepting the decrypted stream between the application and the device driver. If the application monitors the device driver, you can perform a man-in-the-middle attack so that neither the application nor the device driver knows that it's being observed. If the stream between the application and the device driver is encrypted, you can modify the application to extract the unencrypted intermediate stream, or a replayable encrypted intermediate stream, or the token required to authorize the stream...
Unless you put the DRM in the playback device (video card, audio card, etc) itself, and the application simply acts as a blind intermediary for the authentication process just as if it were a router or switch between the computer and the DRM authorizer (music or video store), you can't allow the user unrestricted access to the operating system kernel as you would have in an open-source OS.
One could have a propriety networking stack working over Ethernet just as easily on Linux as on Windows.
Well... that depends on how Linus is feeling about the GPL that week. Linus has said that certain kinds of non-GPL kernel components are allowed, but it's not always clear what those are: there's certain calls that are known to be non-OK, and certain kinds of components that are pretty much blesses, but there's a certain amount of uncertainty involved. After the Sveasoft incident, I suspect that proprietary network code (other than device drivers) in a GPLed kernel would be hard to justify.
All of the DRM stuff would be built on top of the TPM driver, not part of it.
Understood. My point is that if you have the source to the TPM driver, or if you have the source to any of the code that the DRM application uses to communicate to the TPM driver (and you would... the system call interface at least) the DRM would not be any stronger, when you come down to it, than the same code running on a system where the DRM was entirely in user-space.
Because people pay cash for the right to use OSX, and with that comes certain restrictions.
You can't enter into a contract after purchase, and you can't enter into a contract if you haven't seen the terms of that contract. Except for the case of clickthrough license in an online purchase, where you have an opportunity to read the license before use, the basis of the EULA is copyright law, not contract law... either by restricting your right to copy the code to computer memory before using it (the legal fiction I mentioned), or by explicit clauses in copyright law in the nation you live in.
I couldn't give a damn about a BSD derivative 'under the hood' of OSX if the rest comes with handcuffs.
Then you don't actually care if the OS is rented or bought, because either way the software you need to run to play the music you bought can come with handcuffs. The existence of OSX is proof of that.
This will be laughed at in years to come. "People actually paid for that?"
I'm afraid that, to the contrary, this will be remembered as the end of the golden age.
Both OSX and Windows are rented operating systems.
Because they use copyright law to enforce a compulsary license? So does Linux, so does BSD (though that license has been pretty watered down by now). Anything that's not in the public domain does that.
If you're talking about the actual terms, well, there's ways to use an open-source "unrented" operating system and impose additional terms on the whole system you buy. There's Linux-based systems that do that. Heck, OSX is built that way... when you boot OSX you start by booting Darwin/XNU, and OSX runs on top of that... so millions of prople are already playing restricted-use media a non-rented OS...
What does it mean to have TPM support in a GPL-ed kernel?
It means a software component can securely extract keys from hardware.
Does it mean that it can securely do anything with the keys? When the kernel can (for example) wrap tpm_read() with code that copies everything it reads for later replay? Or trap to an invisible code tracer on tpm_open()? Or just start saving everything that the program write()s so the program itself becomes a cracker for whatever DRMed content you're trying to protect?
There's lots of things you can do with TPM in an open-source kernel, but DRM isn't one of them.
[Your] retort to my argument is that it's wrong because I'm a Libertarian?
No, my response is that my experience with big-L-libertarians is that we're operating from such different axioms that it's futile to continue this debate. That doesn't mean that I'm right, or that you're wrong, it just means that I believe things you don't, and you believe things I don't.
For example, I believe that the difference between direct coercion by a representative government and indirect coercion by a non-accountable organization using the power of the state to enforce contracts is not significant. I believe that there are so many communication channels available to individuals today that government censorship is no more effective than any other kind of censorship, and the biggest current threat to our freedom of speech comes from the private sector.
You don't believe these things, and I don't believe that I can convince you of these things, and I'm not even sure I should try to convince you because even if I'm right I believe it's important that there's people unwilling to grant the government one inch of power even if I think they do need that power... so I'm not going to try.
microsoft's problem is the complete opposite as this one. microsoft is trying to prevent unsigned code from running on "their" hardware.
The question is... once they have the DRM support, what will they do with it?
FairPlay that actually works?
Make sure you have good backup copies of your iTMS music on audio CD or (cough cough) otherwise. Not so you can warez it, but so you can keep playing it on your PPC Mac if iTunes switches to requiring Intel DRM support to decode iTMS tracks.
Also: if they're actually planning on supporting strong DRM (hint: Video), they're going to have to think about closing the Darwin source.
Here I am, releasing Trusted Linux. Here's the GPL-ed kernel, and because it's GPL here's the source to the DRM component that's linked with the GPL-ed kernel. Now none of you buys download the source to the DRM code and modify it, y'all hear, that would be naughty.
It's even hard to see how you'd get away with DRM in an open-source kernel, since if everything in the kernel except DontTouchMeImTheDRMCode() is available in source, the opportunities for bypassing DontTouchMeImTheDRMCode() DRM are unlimited.
The time to panic is when 10.4.7 or so is released on the new Intel Macs and Darwin 8.7 doesn't show up on Apple's website. Right now we should be in pre-panic mode.
The Apple Panic Alert level is: [A Nice Hot Cup of Tea].
First, it assumes that businesses survive because of merit. Exhibit A: BeOS.
The OS that was released half-finished on hardware that was half-finished, and that was sustained by sales of incomplete betas? The OS that uses the worst object-oriented language in existence as a core part of its API? The OS that was never released with production quality TCP/IP support, at a time when the Internet was becoming key? The OS that was supposed to be small and fast and sleek and yet required more hardware and a faster processor than any of its competitors (yes, even Windows NT and UNIX) just to boot?
It's only by comparison with "classic" Mac OS (which has also finally got what it deserved... some seven years later than originally scheduled) that BeOS looks good.
If you analyzed the mach_kernel binary file on the Developer Kits, you would see that the kernel is vastly different than the Darwin 8.2 that Apple released as open source.
The software shipped with the developers kits isn't any of the released software, so there's no reason to assume that the released version of Darwin would match it. Apple didn't release the source to Darwin 8.0 when developers got Tiger, but rather when it shipped.
Where have you been these last 2 years?
Using a real Mac instead of a fake one?
Yes, it's spatial, and it's been flamed to hell and back for it.
That's just wrong.
PS: I hereby donate this algorithm to the public domain.
Someone put together a script that pulls up software patents (or lets people suggest them) and rates them. People can go through and hit an "obvious" or "unobvious" button to see the next patent.
Engineers whose names are on the most "obvious" patents each month would get a boobyprize.
Give people an incentive NOT to put their names on stupid patents.
OK, you're one of those hardcore impractical Libertarians-with-a-capital-L who can't recognise a negative externality unless it's imposed by the government. I do appreciate that it's useful to have some of you lot around, but we're clearly not going to get any kind of productive discussion here.
Smalltalk didn't even have self-repairing windows - you had to click in them to get them to repaint, and programs couldn't draw into partially obscured windows.
:)
Aha, that makes a lot more sense. Though they definitely did have them by the time they showed Smalltalk-80 at NCC - I remember being boggled by a demo where a floating window (with a picture of Albert Einstein on it) drifted across the screen on top of other windows.
But it's entirely possible that some earlier versions didn't.
And of course before Mac OS X the scheduler made it almost a moot point, at least as far as having background programs writing into windows was concerned.
Ironically, with "screen-scraping" remote control programs on Windows we have returned to having to click on a window to get it to update.