You need to run it through a PDF parser, and therefore potentially trigger bugs. There's nothing stopping you from doing this from a sandboxed process, so exploit code would be contained. You'd also want to make sure that it went through a simpler intermediate format that another sandboxed process could check. On the other hand, if you can do decent sandboxing, why not solve the problem properly and just sandbox the PDF reader so it can't access anything except the PDF that's passed into it?

Why not? Open the PDF locally, and if there's an exploit in the parsing code then it will infect your machine. Upload it to Google, and if there's an exploit in the parsing code then it will infect one of their machines. Of course, doing this with any PDF that had commercially sensitive information in it would be stupid...

Everyone has the power to create debt. Money is just readily transferable debt, which is the entire point of it: I do some work now for someone, and they don't produce anything that I need right now, then they give me some tokens representing the debt. I can use these tokens to exchange for some useful product or service from someone else who doesn't directly want anything that I produce.

Saying that money is backed by debt is a nice libertarian talking point, but it doesn't actually convey any information. Money exists so that you can balance unequal trades with a promise that they will be equalised in the future, and any promise of future balance is debt.

The City never sleeps, but sometimes the people do. And then the City eats them.

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.