The reason that Apple disabled this is that a lot of SSDs have really buggy TRIM implementations. This observation wasn't unique to Apple: Microsoft and the Linux kernel defaulted to TRIM being off until quite recently. Apple could afford to turn it on for their own SSDs because they did extensive compatibility testing of those before shipping them.

Now, it doesn't really make sense, but enabling it automatically would likely burn some users, and bug reports about data loss lead to a lot more anger than bug reports about lower performance.

TRIM says 'I won't read back from this sector, so you can erase it whenever you want'. That makes it a bit easier for the wear levelling to work. It isn't essential though. An SSD controller can remap sectors at will. Typically, it will keep track of the age (number of erase cycles) of each cell and the time of the last erase. Once a cell reaches a certain age it will write some old (and therefore hopefully infrequently changing) data onto it. Current SSDs, because of the low reliability of individual flash cells, over provision by quite a lot, so it's relatively easy to structure the writes so that everything is a copy. This doesn't even affect performance, as the reads and writes can happen in parallel. The only thing that hurts performance is if you need to block a write waiting for an erase to finish.

Although the mean population density when you average across land mass is pretty low in the US, the modal and median population densities (averaged across people) are actually compared to most places in the western world. The problem is the batshit insane zoning policies of US cities that insist that people live on top of each other in one place and then work on top of each other somewhere far away, and shop on top of each other in a third place.

We flipped the default switch in 10.0, but 9.x shipped with a src.conf option to build with clang instead of gcc. We found quite a few LLVM bugs during this time and didn't flip the switch until we were confident that it would work.

A good example of this is Netflix. Because their infrastructure is designed to support server failures, they're quite happy to deploy random patches against -CURRENT on machines that saturate their network and disk bandwidth pretty much full time and report performance numbers. This has been a really good way of stress testing network and storage stack improvements recently.

The pf in FreeBSD is not just a copy of the OpenBSD code that was then forgotten about. It has been worked on since it was imported, for example adding significantly better SMP scaling in the 10.0 release.

Use the same one. Report every single Conservative Party web site (including candidate web sites in the run up to the next election) as inappropriate content. If enough people do it then some are bound to accidentally slip in to the censor list...

So now it's a high-skill, high-stress job that's earning $26.89/hour (above the living wage in Manhattan, but not by much)?

I don't remember being asked to show ID on checking into a hotel anywhere in Europe. In the US, however, credit card and photo ID are the first things that they ask for at every checkin desk at every hotel I've stayed at (about a dozen over the last couple of years, in quite a few states).

And states should be allowed to legalise slavery. Because that worked so well the last time.

Most of that is microcoded. There's no benefit in removing most of the 32-bit stuff, because it's exactly the same in 64-bit mode. Things like segments are microcoded and if you have a non-zero base you hit a really slow microcoded path on Intel's low-power CPUs.

How about because they're not open sourcing any of the client side bits?

First, to know that it actually is a compiler bug. You can spend days debugging your code and failing to find the error if you regard your compiler as infallible. Second, because you want it to actually be fixed. There are a few thousand bugs open in LLVM and GCC. If you want yours to be fixed, then you need the people doing bug triage to be able to work out who to assign it to. A simple reduced test case and an explanation of exactly what the compiler is doing wrong means that it is likely to be fixed the same day that it's filed. Without that... come back in a year and we might have fixed it if someone better at writing bug reports than you has filed a duplicate.

Yup. Unfortunately, the people in the idiots camp seem to be trying to make it all about them.

In the non-idiots group.

I spend most of my time fixing compiler bugs (when I'm lucky, I get to add new compiler features), so perhaps I'm slightly biased about compiler code quality. Most recently, I was working on an error in LLVM where functions with more than 8 integer / pointer arguments were mangled on big-endian MIPS (if they were smaller than register size), because they were spilled to the stack in the little-endian position. If you encountered this as a programmer and weren't able to look at the function call and prologue, then you'd have absolutely no idea why your code was doing seemingly random things.