Very little iOS software is written in assembly. It's mostly written in Objective-C, with some C and C++. From the perspective of these languages, architecture differences are:

• Size of various primitive types.
• Alignment of primitive types.
• Endian.
• Ability to do unaligned loads and stores.

Between x86-32 and ARMv7, these are all the same (well, the cost of unaligned loads and stores is more on ARM). Between x86-64 and ARMv8, they are the same. This also means that you can trivially share memory-mapped data between the two. If you were to ship a laptop with some ARMv8 cores and some x86-64 cores on cache-coherent memory interface, then you could trivially translate system calls made on the ARM chip into system calls delivered to the x86-64 operating system - you'd need to tweak the call frame, but any of the data passed by pointer would be readable by the kernel (actually, this doesn't necessarily require cache coherency, as the OS X kernel always explicitly copies data in and out via some well-defined code paths). You could also use shared memory and Mach ports to communicate between the application and the window server.

In fact, given the comparatively stateless nature of the OS X window server, it would be conceivable to have the ability to dynamically switch between a window server running on the ARM core (when in low-power mode, checking email or whatever) or the x86 core (when doing real work).

That depends a lot on what you want to work on. For some things, there are a very few institutions that specialise in a particular field, and if the reason you picked your undergraduate university was that they're world leaders in something you're interested in then you'd be crazy to go elsewhere. Similarly, if you're already at a top university then there often aren't many places where you can go that aren't a step down or don't require relocating to a different country (which may or may not be desirable).

Even if your good students do go elsewhere, if you encourage them to do a PhD somewhere then they're likely to come into contact with good undergrads at their new institution, and when those students are considering somewhere to go then you want your former undergrads to put you in touch with them.

A debug build of LLVM generates over 2GB for the debug info. Much of this is removed by the linker. For FreeBSD, it's the userland for 6 architectures when I'm doing a test build and a few dozen kernel configs. It adds up quickly.

That's true to a degree, but teaching and research (and publications) are not as separate as you might see. If you're a lecturer, a lot of your publications are going to be things that you've coauthored with your PhD or MPhil students. And the easiest way to get PhD students is to encourage your undergraduates to apply to continue studying with you (or apply for postgraduate research assistant jobs). The undergrad teaching is how you get the PhD students, and they're how you get significant quantities of research done.

Uh, what? Compiling is so fast on an existing, consumer-grade laptop with an SSD that for incremental builds it's a productivity boost, and it works when I'm at home, at work, on the train, or whatever. The difference in price between the SSD and a mechanical disk was about £300, two years ago (for a 256GB disk). It's now even lower. When I'm doing a lot of builds in different configurations I'll use a centralised server. When I'm actually hacking, I want my working copy to be local. The entire point is to speed up the edit-compile-test cycle, and sticking a network in the middle does not do that.

I have a build machine that has 24 cores, 256GB of RAM, 256GB of SSD, and 4TB of spinning rust. Building on the SSD is significantly faster than the spinning rust (factor of 2-4 depending on what you're building). Building on the RAM disk is probably 1-2% faster, but within the noise for subsequent runs. I often put the object files on the RAM disk though. It doesn't seem to impact performance, but it means that the OS never has to bother writing them out to disk, which should help the SSD last longer when I'm generating 2-30GB of object files per build.

I do, and so does everyone else on my corridor. Yes, we also have machines in racks that can build things faster, but with a quad-core i7 and an SSD in my laptop, I can build the LLVM codebase in 5-10 minutes, with incremental builds often taking under a minute, and that's a big win for my productivity over spinning rust. Most software projects that I work on have been ongoing for 10 or more years and in that time even a small team can produce something that has thousands of source files.

If you're compiling a single file, not doing a parallel build, and having all of the headers already in cache, then you'll probably see about that kind of speedup. If, however, since this isn't the 1960s anymore, you're working on a codebase with a few hundreds or thousands of files, doing a parallel build, then you'll likely see your builds take about half as long. Less if you have a faster processor, because they're now going to be totally CPU limited and not I/O bound.

And for most single-user uses, that's fine. I just kicked off a run of the LLVM test suite, since it was the first thing I could think of that would cause a lot of I/O. It was doing 1000 random reads and 500 random writes per second on my (two-year-old) laptop's SSD. It wasn't a great benchmark, because it was CPU limited, even with a quad-core i7, but that's largely the point of the SSD: the CPU is now the bottleneck, whereas with my old machine (spinning disk and Core 2 Duo), the same operation was I/O limited, even with a CPU less than half the speed.

There was a paper from Google about 18 months ago that showed that, while SMART errors do usually mean the disk will fail, lack of SMART errors does not mean that the disk is not about to fail. In a large number of cases, the drives failed with no warning.

The noise is also something of a red herring. I have a laptop whose drive started to make slightly worrying noises about 2 years ago, but which hasn't died (yet). I've also had several hard disks die with no warning at all. Sometimes, the failure correlates with hearing an odd noise first, but often it doesn't.

I've had three hard disks fail, none of them was in a state where any data was readable. My university computer lab at the time had about half of the drives fail within 18 months of purchase, all with the same failure mode. So I guess you were luckier. I've not had any SSDs fail yet, but I only have one and it's only about 2 years old, so there's still a lot of time...

FedEx is a company that I will avoid at all costs. I lost about half a day chasing them because they'd reported me to a debt collecting agency over an unpaid delivery. There were only two problems with this: paying for the delivery was not my liability (I hadn't signed anything) and they actually were paid by the people who were supposed to pay (who had a corporate account and a FedEx account number that deliveries could just be charged against). FedEx admitted this to me after the first time they wrote to me telling me that there was an unpaid debt, and issued me with a credit note for it. Unfortunately, they somehow managed to get the delivery entered into their accounting system twice and so they closed one as paid and then sent the other to a legal firm.

The R in RAID-0 does stand for redundant. As in 'the person who made the decision to use RAID-0 on our infrastructure has just been made...'

Controller failures are usually easy to fix. The controller on most disks is on a board on the outside that can be unscrewed and replaced. If you find another drive (often cheap, second hand) of the same make and model you can switch them across. I wouldn't recommend doing anything with the drive other than dumping the data when it's in this state, however...

That said, I completely agree. Stuff that is on a single drive is stuff that you don't care about.

You're the second post I've seen on this article conflating 10x the productivity with 10x the amount of code written. There's very little correlation between the two, which is why IBM learned that paying bonuses per line of code results in terrible code. The developers who are ten times as productive are the ones that spend the time understanding the requirements and then write code that does a good job of solving the problem at hand. They don't spend time writing hand-optimised versions of code that is not on the critical path, and they don't waste effort writing complex general solutions when their code is only going to need to handle one input. They do document their work and they do ensure that it's easy to refactor when the requirements change, because they've learned that the poor sap who will have to change it in a year's time is probably them.