Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Racking Mac Pros

photos.imgix.com

Post reply on HN
Print view View original

301–310 of 331 posts

Re: Racking Mac Pros

#301

Post by mauricemir »

MCRed wrote: post #245
blkhp19 wrote: post #217

Earlier quoted context omitted.

Hackintoshes would make a lot more sense.

No, they wouldn't. Look at the current state of Mackintoshes. People are having kernel panics and struggling to keep their machines running with current software. OS X moves pretty fast, possibly faster than Linux, and Apple builds it to support Mac hardware.... the teams who are porting hackintosh code have to support a lot more hardware variety and they have less resources than, say, linux. Running mackintoshes in…

You mean the professional market that that Apple is abandoning in favor of consumer devices.

I look after a mostly MAC environment and OX server is hopeless no migration from stand alone MAC's to Networked was the first shocker I found

And our Mac's are less stable than our windows 8 Box used for running hyperv VM's

Re: Racking Mac Pros

#302

Post by 72deluxe »

angersock wrote: post #153
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…

As I recall, the basic idea was for something lighter-weight than spinning up and spinning down imagemagick. Then again, one wonders why not just use FreeImage or something?

Is running imagemagick really that intensive?

Isn't running shaders intensive as it needs to be compiled on the fly and handed off to the GPU driver?

Re: Racking Mac Pros

#303

Post by fragmede »

x0054 wrote: post #271
barkingcat wrote: post #262

Earlier quoted context omitted.

"combined with the fact that it would be simply stupid for a company who makes their own OS to run anything but that OS" Why would you assume that? There are a ton of things that linux does better than OS X - and it would be extremely stupid for any company regardless of size to not use the right tool for the job. For example, even IBM uses, sells, and supports Linux instead of AIX or OS/360 on their line of servers…

At it's core OS X is Unix. In what way would Linux be a better choice? I am not saying that Linux is a worse choice, but for a company that writes an OS as one of it's core businesses, it only makes sense to run that OS in as many places as possible. For one, by running OS X as a server OS they would necessarily spend more time on development and improvement of the OS core. This would pay off in the long run by furth…

> In what way would Linux be a better choice?

Well, it's a supported operating system on machines that aren't cylindrical.

Re: Racking Mac Pros

#304

Post by kubov »

> Parts of our technology are built using OS X’s graphics frameworks, which offer high quality output and excellent performance.

I'm really curious about any study/compassion between OS X's graphics frameworks vs. other open/closed source solutions available. How 'output quality' is measured? Is really that great and unique? I hardly think that simple image operations like cropping/blurring/masks implemented in OS X framework are significantly faster and with 'better quality' than the same algorithms implemented in Linux/Windows. Not mentioning that you can boost your computation using cuda/opencl on Linux practically seamlessly. But again, citation is needed here.

Re: Racking Mac Pros

#305

Post by kolizz »

dinasaurusrex wrote: post #142
to3m wrote: post #125

Earlier quoted context omitted.

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 s…

I work at Hemnet, a Swedish real estate site, where we currently have about 300 000 - 400 000 new images each week. We recently investigated the on-demand approach but found that JPEG decompression was the biggest time consumer in our use case of scaling fairly large images down to sizes appropriate for web and mobile. This made us decide to do scaling in advance to all our sizes which resulted in overall CPU time savings.

It would be interesting to hear how img.ix solves this, since you are arguing for the resources savings in the on demand approach.

Re: Racking Mac Pros

#306

Post by rbanffy »

danielsamuels wrote: post #294
rbanffy wrote: post #256

Earlier quoted context omitted.

> People are having kernel panics and struggling to keep their machines running with current software. Not here. My Mac is at about 11 days of uptime and it's under constant use. At this moment, I can't say it's less reliable then my Linux machines. In this specific case, however, I'd consider ditching the enclosure and ducting cold air through the internal chassis/heatsink. A Macpro is, essentially a heatsink with b…

Is 11 days of uptime supposed to be impressive?

It's hardly the uptime of someone who's struggling with kernel panics and random crashes. Last power down was when I embarked on a trip. The previous one was a system update. In fact, I never saw a kernel panic with this machine.

Re: Racking Mac Pros

#307

Post by Macha »

x0054 wrote: post #242
skuhn wrote: post #158

Earlier quoted context omitted.

(I'm the datacenter manager at imgix, and I wrote the article) I've alluded to this elsewhere, but the math doesn't add up to your gut reaction. It's cheaper, but not by a significant enough margin relative to the engineering costs, to go with commodity servers and GPUs. Building things out of sheet metal is actually easier than migrating to Linux, for one big reason: we can pay someone else to do it, because it isn'…

It strikes me that OS X is a solid server platform. Linux is always a more flexible choice, but if OS X works for you, it works for you. That being said, is sticking cylindrical mac pros on their side into square racks really the best solution. There are 2 problems I see with this design: 1: You are placing the Mac Pros on their side, which may lead to premature bearing failure on the main cooling fan. Apple designed…

Apple are probably using Linux via AWS & Azure: http://daringfireball.net/linked/2014/02/04/icloud-azure

Re: Racking Mac Pros

#308

Post by geon »

x0054 wrote: post #254
skuhn wrote: post #246

Earlier quoted context omitted.

1. That's certainly a possibility, and one that we won't really have hard numbers on for some time to come. However, the fan is about a $60 part, so provided that we don't have coordinated, catastrophic failures and that they live for at least a year, we're doing alright. Do note that Apple specifically says that the Mac Pro may be operated on its side. https://support.apple.com/en-us/HT201379 2. True, but 1U per ser…

Fascinating, I had no idea Apple approves using the Mac Pros on their side. It would be interesting to find out what happens with the fans. It's also fascinating that they are running Linux internally nowadays, for their server side stuff. What next, I find out that all of the Microsoft data centers run Debian :) Considering that they employ all of those Objective-C and Swift engineers, you would thing that they woul…

> fascinating that they are running Linux internally

Not really. For a server software, why not run it on a mature, industry standard server OS?

> What next, I find out that all of the Microsoft data centers run Debian :)

Apple don't sell server software, not really. MS does.

https://www.apple.com/osx/server/features/

Re: Racking Mac Pros

#309

Post by gh02t »

x0054 wrote: post #292
gh02t wrote: post #279

Earlier quoted context omitted.

Because it isn't really about the OS, it's about the software. OS X is fine as a server platform, but it doesn't have the same software and support ecosystem for data center usage. Apple dumped that market with the Xserve because it didn't work for them. Red Hat/Suse/Oracle etc. all sell tailored solutions for that usage that are Linux specific technology (mostly, some stuff gets ported to other Unix derivatives but…

What tools is OS X lacking? From my experience most of the development and server tools are available natively on OS X. It lacks support for containers, but that would be a worthy addition, and I would say worth spending money and time on. The rest is already there for the most part. Developing further their server infrastructure would allow Apple to make a play for the corporate market. Any way, it's a silly argumen…

It's not small server stuff like Apache that they are missing. It's stuff like distributed failover, exotic driver support, SAN, management etc. that they are missing. Big data center stuff, the kind of thing companies like Red Hat make.

Those kinds of products are huge investments. Sure Apple might be able to market towards the enterprise, but they simply don't think there is any money to be made. They used to have for instance Xserve that tried to stay afloat in that market, but which made little money. Since they canceled it, Mac OS has only been developed as a small to medium server (which it isn't half bad at). But big time data centers are a different world.

For instance, as a very basic example, does Mac OS support Infiniband or the more exotic high-speed ethernet network interfaces? For Infiniband, the answer is no and in the other case the answer is "kinda, but not really."

Re: Racking Mac Pros

#310

Post by dinasaurusrex »

kolizz wrote: post #305
dinasaurusrex wrote: post #142

Earlier quoted context omitted.

(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 s…

I work at Hemnet, a Swedish real estate site, where we currently have about 300 000 - 400 000 new images each week. We recently investigated the on-demand approach but found that JPEG decompression was the biggest time consumer in our use case of scaling fairly large images down to sizes appropriate for web and mobile. This made us decide to do scaling in advance to all our sizes which resulted in overall CPU time sa…

It is true that the time to fetch, render, and deliver an image the first time it is requested can be a bit longer, because of all the processing we're doing in the case of that single request, but because we then cache that fetched image, all subsequent requests are delivered an order of magnitude faster (50th percentile 45ms).

The majority of the time taken in the first request is actually in fetching the image from the origin source, so once it's cached in our system it becomes a much faster operation: and of course delivering the cached image without it traversing our stack is even faster.

So yes, the initial request can take time, but all of the subsequent requests of that image are much faster than the alternative. And when you take into account that our service makes it possible to send the correctly sized image for the display (instead of loading a preset size and displaying it smaller), and optimal file types based on device and browser (webp for chrome, etc), load times/page weights on all of those requests are significantly improved.

In general, anyone who serves multiple requests for their images over time will see a marked improvement on page weight/speed, compared to rolling their own solution where they have preset image sizes and deliver jpeg only.

Post reply on HN