The problem is, adding a copyright notice when you are not the copyright holder is legally dubious, and so if there isn't one in the file you have to maintain the license information separately. This leads to a load of LICENSE.GPL, LICENSE.LGPL, LICENSE.BSD, and so on files in your tree, and separate lists of which files each relate to. It saves everyone time to just stick your license template in the top of every new file that you create.

Clang/LLVM does not include any libc. All of the BSDs, however, ship their own (BSD licensed) libc. The libc in Android is mostly code from FreeBSD libc.

Not having a license on every file is a colossal pain for people wanting to take part of your code and integrate it into something else. I recently went through this with OpenIndiana: they wanted to take some of my code from another project and include it in their libc. This is fine - the license I'm using is more permissive than their libc so there's no legal problem - but I'd forgotten to include the license text in the file, I'd only put it in a LICENSE file in the repository root. Keeping track of the license for one file that is different from the others in the project imposes a burden for them and, without the copyright in the file, potentially means that others will grab that file and think it's under a different license.

In short: Please put licenses in files. It makes life much easier for anyone wanting to use your code. If you don't want people to use your code, then you can save effort by not publishing it in the first place.

Care to explain why I'm wrong? You have to collect garbage somehow (unless you are using an infinitely long tape instead of RAM).

David F Bacon designed some GCs for realtime applications that used reference counting with deferred cycle detection. The longer you defer cycle detection for, the higher the probability that the object will already have been proven to be non-garbage (by having its reference count incremented again) or garbage (by having its reference count reach 0 and it being collected). The trade for this is that it increases the maximum time for the cycle detector to run. You can adjust the delay based on the latency constraints of your application.

I have to wonder what you're talking about here. First of all, the Objective-C runtime is not in crt1.o. This contains some symbols that allow dyld to find things in the executable. The Objective-C runtime is in libobjc.dyld. Every message send (method invocation) in Objective-C goes via one of the objc_msgSend() family of functions and these all do late binding. You can define a category on a system class and override methods, or you can use method swizzling via explicit APIs such as class_replaceMethod(). Apple does absolutely nothing to stop this, because the OS X and iOS security model does not depend on the integrity of system shared libraries within a process. It is based on the MAC framework from FreeBSD and enforces limits on interactions of the process with the wider system. A process is free to do whatever it wants within its own address space without violating the security model.

The core issue is that GC vs no GC is a false dichotomy. You can't get away without GC, the question is whether you use a general-purpose algorithm, like tracing or reference counting with cycle detection, or a special-purpose design. This is especially true on mobile: if a desktop application leaks memory then it will take a while to fill up swap, but it might not be noticed. Apple provides a very coarse-grained automatic GC for iOS: applications notify the OS that they have no unsaved data and then can be kill -9'd in the background and restarted on demand. They also provide reference counting (with explicit cycle breaking via weak references, no automatic cycle collection) as a tool for developers to build per-application memory management strategies. Android, in contrast, provides a finer-grained automatic GC based on generational tracing.

It confuses me that many of the advocates of avoiding automatic GC seem to follow a train of reasoning something like this:

• Memory management is a hard problem.
• Therefore, we can't trust a team of skilled programmers to get a general solution right.
• Therefore, we will trust every average developer to get it right.

Most of the time, GC can be cleanly integrated with event delivery in interactive applications: you set the GC to only collect if memory is exhausted while handling an event and allow application memory to grow, and you then do a more aggressive collection when there are no pending events. This doesn't work for large multiuser server applications, because they can easily do a few hundred GBs of allocations in between idle periods, but it's surprisingly effective for typical desktop and mobile apps.

Good idea. By the way Sarah, over at the FreeBSD project, we try to treat developers with respect and would welcome contributions to our USB stack...

The one where the person that now develops a kernel that ships with FUSE and CUSE, and which has its largest install base running on top of the Xen microkernel in cloud deployments or an L4-derived microkernel in mobile deployments, was saying that microkernels are bad?

Someone recently cc'd him on a post on the LLVM mailing list, and he decided to chime in with a long rant where he was both rude and technically incorrect. It made me very glad that I don't use Linux, and just that little bit less likely to respond to bug reports that only affect people who do. Meanwhile, I recently got a bug report from one of the OpenBSD developers (a community with a reputation for being somewhat... acerbic). It was detailed, polite, and proposed two possible fixes. It was followed up by testing of the fix that I proposed. I don't use OpenBSD either, but I'm a lot more likely to fix bugs for people who do because this report was characteristic of my interactions with their developers.

Using .local is a bad idea, because it's also the domain used for mDNS. This caused quite a few places problems when they started getting Macs with mDNS support appearing on the network. Now most operating systems support it, so people have had to work around it. For a while, some systems were putting .local in the search domains list, which made things all sorts of fun...

That seems to be a fairly recent thing. The 1903 edition of Websters lists two definitions for ass: a donkey and a stupid person. This is pretty much in keeping with English usage. The conflating of ass and arse is more recent.

Exporting encryption has not been illegal in the USA for some time. Certain forms of encryption, however, are still illegal to export to countries under arms embargoes.

ZFS RAM usage depends on the size of your pool, whether you need deduplication, and your performance needs. The rule of thumb for ZFS is 1GB of RAM per TB of storage, 2GB if you want deduplication. This, however, assumes that you are using mechanical disks and either using the pool locally or via something like iSCSI over GigE. If you're using it over WiFi, then you can get away with a really small ARC, because a cache miss won't slow things down that much, especially if the miss is filled by something that can do random reads quickly.

I don't have the glibc sources to hand, but du in /usr/src/lib/libc on FreeBSD tells me that the libc sources are around 13MB. /usr/src/lib/msun (the libm sources) are another 1.9MB.