Racking Mac Pros • Hacker News Board

Re: Racking Mac Pros

#141

Post by Someone » Wed, May 06, 2015, 8:43 PM UTC

MrBuddyCasino wrote: post #127

tinco wrote: post #113

Earlier quoted context omitted.

Obviously, but running OSX on non-Apple hardware is a violation of its EULA. I have contacted a lawyer for this (I wanted to run Hackintosh in the office), the language is very clear. The author of the software has the full power to license its use to you with any restrictions they find necessary no matter how ridiculous. If Apple only sells you the license if you promise not to run it on a thursday, you'll be in vio…

Depends on where you live. At least in Germany (and I think the whole EU), EULAs are meaningless.

I can't find that for EULA's proper (would surprise me, too, as that would allow anyone to pirate any shrink-wrapped software), but EULAs cannot prohibit selling your license: that was upheld for software bought by download, too: http://curia.europa.eu/jcms/upload/docs/application/pdf/2012...:

"Where the copyright holder makes available to his customer a copy – tangible or intangible – and at the same time concludes, in return form payment of a fee, a licence agreement granting the customer the right to use that copy for an unlimited period, that rightholder sells the copy to the customer and thus exhausts his exclusive distribution right. Such a transaction involves a transfer of the right of ownership of the copy. Therefore, even if the licence agreement prohibits a further transfer, the rightholder can no longer oppose the resale of that copy"

You can even buy the right to download future updates:

"Therefore the new acquirer of the user licence, such as a customer of UsedSoft, may, as a lawful acquirer of the corrected and updated copy of the computer program concerned, download that copy from the copyright holder’s website."

Re: Racking Mac Pros

#142

Post by dinasaurusrex » Wed, May 06, 2015, 8:44 PM UTC

to3m wrote: post #125

jallmann wrote: post #78

This seems risky from a business perspective: it's voluntary vendor lock-in. What if Apple decides to change the Mac Pro form factor for the next iteration? Then you have to retool and are left with a bunch of incompatible chassis. What if Apple stagnates with hardware upgrades? You'd be stuck running obsolete hardware. What if Apple discontinues the entire Mac Pro line? Not to mention the price premium of Apple hard…

This was pretty much my thought as well. The results of this cost-benefit analysis make me raise my eyebrow, and, same as you, I can only assume that OS X permeates the infrastructure from top to bottom, to an extent that makes pulling it out too painful to even contemplate. Image processing shaders of this type aren't that hard to write. If you're worried about them not matching some piece of client software exactly…

(full disclosure: I work at imgix)

Uploading pre-edited images takes time/resources, and in general a lot of our customers rely on us to do all of their image processing so that they don't have to.

Additionally, creating edited versions of images in advance presents two problems: 1) Any future site redesigns or edits must now be applied en masse to the existing images or risk older images not complying with the new scheme, and 2) Instead of only managing the one original source image in the origin, now we're talking about maintaining all of the different edited versions, which is very inefficient from a storage and image management perspective.

There are many advantages to applying all of the image transformations on-demand, rather than in advance. Keep in mind that we are not simply photo filters, but a full end-to-end image processing offering (which applies everything from simple photoshop edits like cropping, face detecting, color correction, watermarks, etc. to automatic content negotiation and automatic resizing/responsive design) that works on the fly; this means that our customers now can make batch edits to their entire corpus of images through a few simple code edits.

This can become extremely cost-effective, but also helps in reducing page weight significantly.

Re: Racking Mac Pros

#143

Post by [deleted] » Wed, May 06, 2015, 8:46 PM UTC

[deleted]

Re: Racking Mac Pros

#144

Post by sabujp » Wed, May 06, 2015, 8:46 PM UTC

8 mp's in a 7u : https://www.facebook.com/pages/Rack-Your-Mini/10374582632541...

Re: Racking Mac Pros

#145

Post by SG- » Wed, May 06, 2015, 8:46 PM UTC

frugalmail wrote: post #133

This seems like a company destined to fail: 1) Massive premium for compute 2) They're at the mercy of Apple, a single completely unpredictable vendor. 3) Apple changes it's form-factors to the latest "design" way to frequently 4) Apple sucks to manage in mass

1) They did a cost analysis and it was alright, I can't imagine high-end servers with dual GPUs being much cheaper or much more expensive myself.

2) This isn't the 90s where Apple was at risk of folding and going away.

3) They actually don't other than phones. Go back to all their Pro desktop lines starting with the PowerMacs. The previous MacPro case lasted quite long and came from the PowerMac G5.

Re: Racking Mac Pros

#146

Post by wnevets » Wed, May 06, 2015, 8:47 PM UTC

nulltype wrote: post #116

tinco wrote: post #113

Earlier quoted context omitted.

Obviously, but running OSX on non-Apple hardware is a violation of its EULA. I have contacted a lawyer for this (I wanted to run Hackintosh in the office), the language is very clear. The author of the software has the full power to license its use to you with any restrictions they find necessary no matter how ridiculous. If Apple only sells you the license if you promise not to run it on a thursday, you'll be in vio…

Even if that were not the case, I doubt the performance of the OS X image pipeline is tuned for non-Apple hardware if it supports it at all.

which hardware is "Apple"?

Re: Racking Mac Pros

#147

Post by smackfu » Wed, May 06, 2015, 8:49 PM UTC

TD-Linux wrote: post #134

Given all of the effort spent to use Quartz's graphics operations, I was curious as to how they actually performed. I opened an account and tried out the upsampling, and was a bit disappointed. http://chen.imgix.net/rose.png?w=560 What other upsamplers look like: https://github.com/haasn/mpvhq-upscalers/blob/master/Rose.md Looking at the other operations available, I fail to see what is done better by Quartz than jus…

I assume 99% of users are using downsampling, to get thumbnails.

Re: Racking Mac Pros

#148

Post by KeytarHero » Wed, May 06, 2015, 8:50 PM UTC

tinco wrote: post #120

nulltype wrote: post #116

Earlier quoted context omitted.

Even if that were not the case, I doubt the performance of the OS X image pipeline is tuned for non-Apple hardware if it supports it at all.

Non-Apple hardware does not differ in any meaningful way from Apple hardware. The performance of anything in OSX is perfectly tuned for any generic desktop computer. It also supports most hardware straight from the box.

> any generic desktop computer

Any generic desktop computer with the same hardware. It sounds like they're using Apple's image pipeline, which I imagine would be designed around the specific graphics hardware in the Mac Pro. Sure it could work on other hardware, but when you know exactly the hardware you're running on you can do a lot of low-level optimizations you couldn't otherwise do.

Re: Racking Mac Pros

#149

Post by lurkinggrue » Wed, May 06, 2015, 8:51 PM UTC

Wow, that's cool and yet doesn't seem to be the best power vs cost solution.

Vendor lock-in is a bitch.

Re: Racking Mac Pros

#150

Post by acdha » Wed, May 06, 2015, 8:52 PM UTC

robbyt wrote: post #24

exelius wrote: post #19

Earlier quoted context omitted.

The Mac Pro isn't a great value in the datacenter space. It's a single socket server that's limited to 64 GB of RAM. It's not unusual anymore to throw GPUs in rack mount systems; most of them already have the PCIe bandwidth necessary to support 4 big GPUs so it's often just a matter of getting the right riser cards. Compare a Mac Pro to an HP DL360 that can hold 4 8-core Xeons (32 cores total) and over 200GB of RAM a…

OS X does not have NUMA. It has some nice libraries for multi-threading, but that doesn't really matter that much when you're saturating your memory bus because the CPUs are doing too many cross-zone memory requests.

While OS X doesn't have something like Linux's NUMA interface to explicitly lock a thread to a core, 10.5 shipped a thread affinity API which allows you to help the scheduler make better placement decisions:

“OS X does not export interfaces that identify processors or control thread placement—explicit thread to processor binding is not supported. Instead, the kernel manages all thread placement. Applications expect that the scheduler will, under most circumstances, run its threads using a good processor placement with respect to cache affinity.

However, the application itself knows the detailed caching characteristics of its threads and its data—in particular, the organization of threads as disjoint sets characterized by their association with (affinity to) distinct shared data.

While threads within such a set exhibit affinity with each other via shared data, they share a disaffinity or negative affinity with respect to other sets. In other words, a set expresses an affinity with an L2 cache and the scheduler should seek to run threads in a set on processors sharing that L2 cache.”

https://developer.apple.com/library/mac/releasenotes/Perform...