Same here, strangely enough. Looks like a measure to avoid load caused by foreigners that got curious from all the bad reporting that this website got.
The film opens with a recruitment commercial which is a bit over the top and then shows a small ad like piece of clear propaganda about the new planetary defenses. This should make you suspicious of the tone of the film right there. And as the film goes on, these inserts become more and more ludicrous.
The bugs are not defeated in the film. The ending narration states that the war effort is ongoing with more success than ever. So nothing really has changed. It even stands to reason that the whole Brain Bug hunt is pure propaganda to boost morale and nothing that is actually expected to have a positive impact. Remember, when you watch Starship Troopers you are actually watching a propaganda program that is running a story about some recruits and their story in the service. So you cannot take take anything in the movie quite at face value. Would you like to know more?
I honestly wonder what the systemd developers were thinking when they turned it into a feature-creep laden mountain of mostly annoying features which slowly takes over the system from you. The way it seems to force itself into other things in the system (e.g. by way of systemd-specific modifications in daemons and such) just should have set off a lot of software engineering alarm bells. Why didn't that happen?
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.
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.