5 ms·

I say go the other way: Sell a version of OS X without video drivers. (ok, maybe a text console so it can cry piteously when it is broken and you can create an

by jws 14y ago

I say go the other way: Sell a version of OS X without video drivers. (ok, maybe a text console so it can cry piteously when it is broken and you can create an account or something if you have to.) Remote desktop to manage; if you have a supported GPU it is 100% free for compute; only support chipsets and processors that Apple supports anyway. The engineering cost is minimal. Compatible hardware is the customer's problem. People that need horsepower for their render farms or whatever can build or buy the systems that make sense the month they need to buy. People that need to stick code in a hosting service can do that. Stop making me do my engineering twice; once for the native Mac OS, and once for the servers. Stop losing customers when the Pro line gets too long in the tooth. Give it a "no brainer" price. You aren't doing much engineering and it isn't canibalizing your human interaction machines, it protects them from migration.

larsberg 14y ago
I'm not sure about the engineering cost being minimal. My research group builds a compiler for a parallel programming language, and we have trouble getting reliable performance on OSX. Many of the things you take for granted on Linux are not there: - Pinning the kernel to one core - Reliable pinning of threads (instead of just suggesting that groups be co-located on the same cache bank) Honestly, we have a fairly long list to even get to basic performance, and that's before you start hammering network stack reliability (as my distributed systems friends complain), etc. OSX on the client with Linux on the server works pretty nicely, and I'm somewhat concerned that the OSX team would have to drop client work for a whole release to focus on hardening the server experience, as well as figuring how what they need to implement to be able to support the wide variety of Linux libraries that don't quite work due to holes in the OS that performance people rely on (numactl; papi; etc.). That said, I thought most of the Apple developers have Mac Pros under their desks. If for no other reason, to maintain a highest-end client workstation, it makes sense to keep things alive. But the server sell seems a bit of a reach, engineering-wise.
- jws 14y ago
  I don't think you'll pry linux developers away with this. But for people adding distributed backend workers to existing OS X apps it makes great sense, even if you don't end up at the same speed as a tweaked out Linux implementation. Likewise, you probably won't beat a good Linux network stack for jamming bits through, but lots of people just need to be up and running, and if the code is shared with the client, that's great. I think its a case of "showing up", they can worry about being best later, if it makes sense, but showing up at all is important. Apple just lost a premier video production house run by a friend of mine over the Mac Pro lifecycle. They'd have stocked up on render machines and waited out the front ends if they could, but that wasn't an option. (Apple will beat my last round of 100% Intel motherboards in Linux servers which have a years old, unresolved flaw in one of their two ethernet controllers that make them reset whenever you push them too hard. They also have a good chance of beating Linux in GPU computation because the vendors actually care a bit about Macs. I've got a lot of GPU power laying around that I can't use at all in Linux.)

by jws 14y ago

larsberg 14y ago

I'm not sure about the engineering cost being minimal. My research group builds a compiler for a parallel programming language, and we have trouble getting reliable performance on OSX. Many of the things you take for granted on Linux are not there: - Pinning the kernel to one core - Reliable pinning of threads (instead of just suggesting that groups be co-located on the same cache bank) Honestly, we have a fairly long list to even get to basic performance, and that's before you start hammering network stack reliability (as my distributed systems friends complain), etc. OSX on the client with Linux on the server works pretty nicely, and I'm somewhat concerned that the OSX team would have to drop client work for a whole release to focus on hardening the server experience, as well as figuring how what they need to implement to be able to support the wide variety of Linux libraries that don't quite work due to holes in the OS that performance people rely on (numactl; papi; etc.). That said, I thought most of the Apple developers have Mac Pros under their desks. If for no other reason, to maintain a highest-end client workstation, it makes sense to keep things alive. But the server sell seems a bit of a reach, engineering-wise.

jws 14y ago
I don't think you'll pry linux developers away with this. But for people adding distributed backend workers to existing OS X apps it makes great sense, even if you don't end up at the same speed as a tweaked out Linux implementation. Likewise, you probably won't beat a good Linux network stack for jamming bits through, but lots of people just need to be up and running, and if the code is shared with the client, that's great. I think its a case of "showing up", they can worry about being best later, if it makes sense, but showing up at all is important. Apple just lost a premier video production house run by a friend of mine over the Mac Pro lifecycle. They'd have stocked up on render machines and waited out the front ends if they could, but that wasn't an option. (Apple will beat my last round of 100% Intel motherboards in Linux servers which have a years old, unresolved flaw in one of their two ethernet controllers that make them reset whenever you push them too hard. They also have a good chance of beating Linux in GPU computation because the vendors actually care a bit about Macs. I've got a lot of GPU power laying around that I can't use at all in Linux.)