Sure, everyone makes mistakes, but if customer A wants this feature and customer B wants that feature, the design can change and bugs will result. The analogy here would be if a bricklayer lays some bricks and the architect says, "I changed my mind, let's use marble instead," the bricklayer is paid to replace the brick with marble.
Programming and construction are different beasts entirely. While some analogies work comparing the tech field to other fields, many analogies fail. Your bosses analogy just doesn't fit the tech field.
Also, OpenOffice (or Libreoffice) is just another office suite, like MS Office, so it's still pretty bloated.
"What else is out there?"
I recommend searching for the "tacobell programming" article. I use linux/bsd systems and almost all programs support CLI's. By using pipes, you can string several commands together, using one program's output as the next program's input, all on the command line. It's very, very powerful. There are so many programs I just take for granted, that when I use a Windows machine, I feel neutered without programs like grep, vi, dd, ctags, cat, head, tail, netstat, nmap, locate, less, sed... the list goes on and on (note, there are Windows versions of some of these programs, and they are available with cygwin for Windows, which provides a sort of decent unix-like interface for the Windows OS).
If these foreign subsidiaries aren't "tax resident in any nation", are they protected by the laws of any nation? It seems odd that a company can exist and be recognized as an entity that can hold property without being incorporated in a recognized nation. Can't we just take their stuff and see who they turn to for the protection of law?
I think this is a great idea. It would be especially ironic since Apple banned the drone strike tracking app from their app store.
From my limited experiences, "current" has nothing to do with it, nor does age. C has been around since there early '70's; in terms of systems-level programming, there is a huge benefit to being older. The older folk have seen tons of OS's born, raised, reach adolescence, get their first DUI, etc. They know what's it's like to play in a kernel that only has 256 KB of RAM, so they know how to optimize. Lots of youths these days are given higher and higher level languages as intro programming classes. My alma mater, to my dismay, replaced Java with Python for the intro class. I wish I had that insight. We younger generations are missing out on a lot of experience, and as more and more development moves to the web, lots of us are missing out on what really goes on under the hood.
Now, to address some of your statements:
"I work with a developer who is 10 years my senior, but still doesn't understand how to write concurrent code" This is a symptom of poor programmer quality, and has nothing to do with age. You can be 5, or you can be 65, but if you don't know what a spinlock is, then you don't know what a spinlock is. Multi-threading/multi-programming has been around for a long time.
"and cannot be trusted to use a revision control system without causing a mess that somebody else will have to clean up." I still have no idea how to use a revision control system. However, it's good practice, at least for me, to befriend someone who does understand them, so he can help you the hard times.
Second, the list of heuristics can easily spiral out of control. You might not want to cache a video file of a movie you're watching, but you probably would want to cache a video file of a movie you are editing. You have to know where the file came from, where it's going, how fast you want it to get there (i.e., priority), what programs are using it, etc. There's just too much contextual metadata that needs to be tracked; the more complicated the contextual metadata is, the more complicated the heuristics need to be. Also, statically defined heuristics may be inappropriate for dynamic environments.
Third, why cache an entire file if you're only working on a very small percentage of it? I have to admit, some file-level caches will only cache the "popular" portions of files, but in that case, why not just use a block-level cache and enjoy its better performance?
Also, I'm confused about "there are a lot fewer blocks than files," did you mean that the other way around? If you have a single 100 MB file, and the system's block size is 4K, you have a lot more blocks than files. There may be a smaller memory overhead with a file-level cache, but there's a greater CPU overhead due to all the contextual metadata and heuristic processing.
Other amusing features in 13.04: a button that shows the desktop, and a workspace switcher (disabled by default) that lets you know which workspace you're currently using. Wow, Ubuntu. Unity is on pace to have all the desktop features that Gnome 2 and Xfce have had for years by 2016.