Would you like to explain in what way Ardour is lacking? I admit that I have not experience in this matter, but I'm curious. I always notice how OSS graphics tools lack behind commercial offerings and I'm trying to get a better understanding of how this happens. Now I wonder if something similar is going on with audio software.

I have tried SCons and cmake as replacements for Makefiles and I'm pretty happy with cmake. Both tools are better than make in that they have more insight in what you're trying to accomplish and end up doing the right thing in many cases. You certainly don't have to spell out every command explicitly like you have to do with Makefiles.

SCons gives you a lot of programmer's freedom by handing you a whole Python interpreter to work with. That can be cool in some situations, the downside for me is that you have to come up with all the code that configures the build by yourself. The big plus with SCons is that it knows what to do with about any kind of file that can be compiled without having to tell it how to invoke the corresponding compiler.

cmake on the other hand brings a lot of tools that let you spell out the configuration of the build in terms of user-set variables in a very straight-forward manner and it also has. It doesn't run the build, but can generate build scripts or project definition for a lot of environments and IDEs. I find it to be very easy to write cmake scripts that compile moderately complex builds with lots of dependencies on multiple platforms, where each user has his/her dependencies layout it in a different fashion from everyone else.

I'm sorry to say it that way but you are wrong. Google has documentation and sample on writing Android activities without any Java code involved. Take a look at samples/native-activity in the NDK. That's a single C file plus the XML file you need to describe your app. No Java code to go inbetween and make JNI calls.

Well, and how does it change the nature of Android that you can write apps entirely in C without a single line of Java anywhere? Google even ships demos that do just that.

Very few apps use it? Everything that is ported from other platforms is using the NDK, Or do you think that apps like Firefox, Chrome or Opera have been rewritten in Java? And then there's all the cross-platform games.

You are wrong. Android has a C interface that is very POSIX conformant. It is there for applications to use. Google offers all the tools you need to make use of that.

You should read Ken Thompson's "Reflections on Trusting Trust" and the thesis that shows how to detect that attack (forgot the name of the author - Bruce Schneier has written a good summary of it, though). This will tell you why you want multiple compilers for some things.

Very short summary (probably wrong - it's confusing): You want to compile your production compiler with two different compilers to check if the binaries these resulting production compiler binaries produces are the same (e.g. you let the production compiler compile itself again using the two different binaries). Your alternate compiler does not strictly have to be up to date or fully featured for that. It must only be able to compile the compiler that was used for creating the actual product under scrutiny.

There are many things that you can argue about, but only few that you should argue about as a professional. For example, it is OK to argue about the best way to go about something. Done right, everybody leaves a bit wiser. But it is usually not OK to argue on a personal level in a tech job.

I think you are overestimating the difficulty in slipping unwanted hidden functionality into code. Take a look at the underhanded C code contest for some ideas. The number of entries in each contest suggests that it's easier than it looks to come up with that kind of thing if you really want to.

Well, at Unity you are in the cozy position of not having to work much on actual games. Game studios have a lot of shit going down because of the creative and economic aspects of games. Game engines are sort of decoupled from that. Consider yourself lucky in that regard!

Also, you guys at Unity are doing great work.

Although I'm in danger of talking out of my ass here I'll say it anyway: wayland has a lot of the typical OSS project flaws that make running a Linux box a nightmare. It is designed to be reimplementable (open and extendable interface, yada yada) which means that there will be incompatible , incomplete and buggy implementations out there. Essential parts of GUI environments (standard DND and copy/paste protocols, for example) were omitted last time I looked due to the focus on graphical IO. The result will be incompatible protocol extensions or 3rd party daemons to handle that. Naturally, they will be incompatible and some of them might eventually learn to work together, but that will only work properly when the phase of the moon is correct and the stars align in the proper way.

I would really love to see an OpenGL based (not ES based) graphics/GUI stack for Linux that is designed monolithically enough to provide a dependable and clean base for 3rd party apps to depend on without being full of nasty surprises. I really fear that wayland will botch that. :(

Not likely going to happen since f****** Oracle forbade redistribution of Java. Distributions now can only provide OpenJDK without making the user go through manual download procedures. And OpenJDK doesn't quite have the same quality and stability in my experience.

Java is amazing technology and it is sad to see Oracle hellbent on killing it off.

A key that is only used for communication and never for storage does not need to be recoverable, does it?

Still, it's asymptotic. Have fun! ;)

Obviously it will be PHP ;)