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.
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!
Using ints makes this kind of optimisation very easy. Usually, the types you use overloading for are more complex and the operators that are called will likely be inlined, but not combined in a meaningful way.
Clearly you have not yet had a chance to write code that does real maths with real mathematical types like vectors or matrices. This is wheree operator overloading really shines. You don't want to implement complex formulas with tons of explicit function calls. With overloaded operators you can basically transfer the formulas you calculated on paper into machine code almost exactly. Without them, it's a sad mess of nested function calls, long lines, superfluous temporary variables and almost inevitable mistakes in code that nobody wants to read.
Of course there are times when operator overloading is exactly the wrong thing to do. But if it is used the right way, it is an amazing feature.
The real shame is that some CS students only learn Java at University and when they encounter C or C++ for the first time, they immediately screw up royally because they never learned anything about basic things like memory addresses and pointers. They have problems grasping the basics of those. I find it a shame that you can graduate not knowing what a pointer is.
This reminds me of the odd undocumented workaround processes that always seem to creep into the work habits of the users of some complex systems. It is almost impossible to catch those when gathering requirements because they never formally exist.
Essentially, yes. They have sold a lot of their silverware in the last couple of years to keep going. They fired lots of developers, sold Qt, sold their company headquarters to rent them back, etc.
I consider lambdas and inner functions to be quite different types of biests. How would you write a lambda that has itself 10 to 20 lines of code? How would you nest another function inside a lambda expression?
At this point it's not about being better or worse. It's about which of the two alternatives gets the important closed source drivers first (high-end AMD and nVidia GPUs as well as mobile GPUs). *No* open source driver for this hardware is remotely good enough to put it through its paces properly.
Slashdot Mirror
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.
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.
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 ;)
Using ints makes this kind of optimisation very easy. Usually, the types you use overloading for are more complex and the operators that are called will likely be inlined, but not combined in a meaningful way.
Clearly you have not yet had a chance to write code that does real maths with real mathematical types like vectors or matrices. This is wheree operator overloading really shines. You don't want to implement complex formulas with tons of explicit function calls. With overloaded operators you can basically transfer the formulas you calculated on paper into machine code almost exactly. Without them, it's a sad mess of nested function calls, long lines, superfluous temporary variables and almost inevitable mistakes in code that nobody wants to read.
Of course there are times when operator overloading is exactly the wrong thing to do. But if it is used the right way, it is an amazing feature.
The real shame is that some CS students only learn Java at University and when they encounter C or C++ for the first time, they immediately screw up royally because they never learned anything about basic things like memory addresses and pointers. They have problems grasping the basics of those. I find it a shame that you can graduate not knowing what a pointer is.
This reminds me of the odd undocumented workaround processes that always seem to creep into the work habits of the users of some complex systems. It is almost impossible to catch those when gathering requirements because they never formally exist.
Essentially, yes. They have sold a lot of their silverware in the last couple of years to keep going. They fired lots of developers, sold Qt, sold their company headquarters to rent them back, etc.
I consider lambdas and inner functions to be quite different types of biests. How would you write a lambda that has itself 10 to 20 lines of code? How would you nest another function inside a lambda expression?
Most higher level languages in common use? C, C++, Java don't have them. What other language is in "common use" these days? PHP?
To know what was before is important to understand why the product that finally created the mass market managed to do just that.
Not if the .m4a is encoded using Apple's own lossless format, which they also store in a MPEG 4 container.
At this point it's not about being better or worse. It's about which of the two alternatives gets the important closed source drivers first (high-end AMD and nVidia GPUs as well as mobile GPUs). *No* open source driver for this hardware is remotely good enough to put it through its paces properly.