We were delighted at a seeing 96 MacBook Pros in a rack a couple of days ago which served as testing hardware. It’s pretty cool so see a similar exquisitely executed hack that is actually in use as a production server. imgix is a startup that provides image resizing for major web platforms. This means they need some real image processing horsepower and recently finalized a design that installs 44 Mac Pro computers in each rack. This hardware was chosen because it’s more than capable of doing the heavy lifting when it comes to image processing. And it turns out to be a much better use of rack space than the 64 Mac Minis it replaces.
Racking Mac Pro for Production
Each of the 11 R2 panels like the one shown here holds 4 Mac Pro. Cooling was the first order of business, so each panel has a grate on the right side of it for cold-air intake. This is a sealed duct through which one side of each Pro is mounted. That allows the built-in exhaust fan of the computers to cool themselves, pulling in cold air and exhausting out the opposite side.
Port access to each is provided on the front of the panel as well. Connectors are mounted on the right side of the front plate which is out of frame in this image. Power and Ethernet run out the back of the rack.
The only downside of this method is that if one computer dies you need to pull the entire rack to replace it. This represents 9% of the total rack and so imgix designed the 44-node system to deal with that kind of processing loss without taking the entire rack down for service.
Why This Bests the Mac Mini
Here you can see the three different racks that the company is using. On the left is common server equipment running Linux. In the middle is the R1 design which uses 64 Mac Minis for graphic-intensive tasks. To the right is the new R2 rack which replace the R1 design.
Obviously each Mac Pro is more powerful than a Mac Mini, but I reached out to imgix to ask about what prompt them to move away from the R1 design that hosts eight rack panes each with eight Mac Minis. [Simon Kuhn], the Director of Production, makes the point that the original rack design is a good one, but in the end there’s just too little computing power in the space of one rack to make sense.
Although physically there is room for at least twice as many Mac Mini units — by mounting them two-deep in each space — this would have caused several problems. First up is heat. Keeping the second position of computers within safe operating temperatures would have been challenging, if not impossible. The second is automated power control. The R1 racks used two sets of 48 controllable outlets to power computers and cooling fans. This is important as the outlets allow them to power cycle mis-behaving units remotely. And finally, more units means more Ethernet connections to deal with.
We having a great time looking that custom server rack setups. If you have one of your own, or a favorite which someone else built, please let us know!
[Bbraun] has an old Macintosh SE computer. He was looking for a way to view the video output from the SE on a newer, modern computer. He ended up working out a pretty clever solution using a stm32f4discovery board.
First, the SE’s logic board was removed from its case and placed onto a desk for easier access. The discovery board was then hooked up to the SE’s processor direct slot (PDS) using normal jumper wires. The discovery board acts as a USB COM port on a newer Mac OSX computer. The discovery board watches the SE for writes to video memory. When it sees that the R/W pin goes low, it knows that a write is occurring. It then waits for /AS to go low, which indicates that an address is on the bus. The discovery board reads the address and verifies that it falls within the range of the video frame buffer. If it does, then the discovery board writes a copy of the data to a local buffer.
The OSX computer runs a simple app that can make a request to the discovery board via USB. When the board receives the request, it sends its local frame buffer data over the USB connection and back to the host. The OSX computer then displays that data in a window using CGImage. The demo video below was captured using this technique. Continue reading “Viewing A Macintosh SE’s Video On A Modern Computer”→
The Macintosh Classic – a small all-in-one computer with a 9″ monochrome screen – was one of the more interesting machines ever released by Apple. It was the company’s first venture into a cost-reduced computer, and the first Macintosh to sell for less than $1000. Released in 1990, its list of features were nearly identical to the Macintosh Plus, released four years earlier. The Classic also had an interesting feature not found in any other Mac. It could boot a full OS, in this case System 6.0.3, by holding down a series of keys during boot. This made it an exceptional diskless workstation. It was cheap, and all you really needed was a word processor or spreadsheet program on a 1.44 MB floppy to do real work.
[Steve] over at Big Mess O’ Wires had the same idea as the Apple engineers back in the late 80s. Take a Macintosh Plus, give it a bit more ROM, and put an OS in there. [Steve] is going a bit farther than those Apple engineers could have dreamed. He’s built a rewritable ROM disk for the Mac Plus, turning this ancient computer into a completely configurable diskless workstation.
The build replaces the two stock ROM chips with an adapter board filled with 29F040B Flash chips. They’re exactly what you would expect – huge, old PDIPs loaded up with Flash instead of the slightly more difficult to reprogram EEPROM. Because of the additional space, two additional wires needed to connected to the CPU. The result is a full Megabyte of Flash available to the Macintosh at boot, in a computer where the normal removable disk drive capacity was only 800kB.
The hardware adapter for stuffing these flash chips inside a Mac Plus was made by [Rob Braun], while the software part of this build came from [Rob] and [Doug Brown]. They studied how the Macintosh Classic’s ROM disk driver worked, and [Rob Braun] developed a stand-alone ROM disk driver with a new pirate-themed startup icon. [Steve] then dug in and created an old-school Mac app in Metrowerks Codewarrior to write new values to the ROM. Anything from Shufflepuck to Glider, to a copy of System 7.1 can be placed on this ROM disk.
This isn’t the first time we’ve seen ROM boot disks for old Macs. There was a lot of spare address space floating around in the old Mac II-series computers, and [Doug Brown] found a good use for it. Some of these old computers had optional ROM SIMM. You can put up to 8 Megabytes in the address space reserved for the ROM, and using a similar ROM disk driver, [Doug] can put an entire system in ROM, or make the startup chime exceptionally long.
A router with WPS requires a PIN to allow other devices to connect, and this PIN should be unique to every router and not derived from other easily accessible data found on the router. When [Craig] took a look at the firmware of a D-Link DIR-810L 802.11ac router, he found exactly the opposite; the WPS PIN was easily decipherable because it was generated entirely from the router’s MAC address and could be reverse engineered by sniffing WiFi.
When [Craig] was taking a look at the disassembled firmware from his router, he noticed a bit of code that accessed the NVRAM used for storing device-specific information like a serial number. This bit of code wasn’t retrieving a WPS pin, but the WAN MAC address instead. Instead of being unique to each device and opaque to every other bit of data on the router, the WPS pin was simply generated (with a bit of math) from the MAC address. This means anyone upstream of the router can easily derive the WPS pin of the router, and essentially gives everyone the keys to the castle of this router.
A few years ago, it was discovered the WPS pin was extremely insecure anyway, able to be brute-forced in a matter of minutes. There are patches router manufacturers could apply to detect these brute force attacks, closing that vulnerability. [Craig]’s code, though, demonstrates that a very large number of D-Link routers effectively broadcast their WPS PIN to the world. To make things even worse, the BSSID found in every wireless frame is also derived from the WAN MAC address. [Craig] has literally broken WPS on a huge number of D-Link routers, thanks to a single engineer that decided to generate the WPS PIN from the MAC address.
Who of us out there don’t have a spare iPad and Mac Classic kicking around? If you are one of those lucky folks then this project is for you. [site hirac] has made a pretty neat stand for an iPad made out of a Mac Classic case (translated). It just happens that the screens of the Mac Classic and iPad are pretty darn close in size. Although the screen size is similar, the resolution is not. The original Macintosh Classic had a black and white screen with a resolution of 512 × 342 pixels. The iPad’s resolution of 1024 x 768 pixels has 450% more pixels than the original Mac.
To get the iPad to fit correctly, the case had to be significantly modified. First, all of the internals of the Mac were removed, leaving just an empty case. The front panel of the case was removed and a slot on the left side is made. This slot helps to allow the iPad to slide into the Mac. On the inside of the front panel quite a few of injection molded supports were trimmed away for clearance. A slot was also cut in the left side of the rear case half. When the case is re-assembled, the slots in the front and rear halves provide a large enough hole for the iPad to fit through. Oddly, there are some plastic features on the front panel that are at just the right height to hold the iPad in the ideal location to line up with the screen cutout in the case.
Check out this jumbled confirmation window. At first glance the message appears to contain a bunch of gibberish, but it can actually be read if you start at the right side and read each character moving left. The text displays like this because it is prefixed by a special Right-to-Left override Unicode character. The technique is being used in malware to obscure the actual extension of the file being launched. Notice that when written backwards your eye can still pick out the string “pdf” which may be enough to trick the uninitiated into approving the launch of the file.
This confirmation screen is launched when clicking on a piece of malware found in the wild a little over a week ago. If you do choose to run it, a decoy PDF file is opened in order not to arouse suspicion. But at the same time the program — which is signed with an Apple Developer ID — is installing itself in the home directory and making a cron job to launch at each boot. Sneaky!
The problem he had with some of the pre-packaged tool chains is that they didn’t support the hardware floating point functionality of STM’s Cortex-M4 chips. To get around this without doing his own ground-up build (which can be quite a challenge) he forked the Summon Arm Toolchain script and modified it to include ST-Link support in the build. One of the things that we like about that script is it installs the tools in a sub-directory of your home directory. This way if you already have another ARM toolchain you can switch between the two by tweaking your PATH variable.