There's an old stock market scam. You open 100 accounts. You invest randomly. After a week, roughly half will be turning a profit. You close the ones that aren't, and do another round of random investing. Again, roughly half make a loss, half a profit. After a few rounds of this, you have lost quite a lot of money, but you have one account that looks really stellar - huge returns on investment. You then open this up to investment, with the disclaimer that past performance does not guarantee future results, and wait for the money to roll in (you can then invest this in your own companies, or just take it and run away).

Much the same applies with CEOs. You take a few thousand business graduates each year and put them in management positions. They all make random decisions. Then you cherry pick the handful that have made decisions that turned out well. Then you say 'Superstar CEO, please pay enormous salary'.

The counter argument to this is simple: Memory allocations accounts for 99% of all scarce resource allocation in a typical program (and all of the resources that they're actually likely to exhaust: when was the last time you saw a program that had so many file descriptors open at once that it was hard to keep track of them and they came anywhere close to the system limit? It happens, but in very unusual code). Saying 'well, I have to do it for 1%, I may as well do it for the other 99%' is really not a very compelling argument.

Given their recent track record, I'd trust ICANN under its current leadership significantly less than the UN, the Russian Mafia, or a random homeless guy.

So, did the person submitting this request own the copyright to the VLC media player?

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...