So, Deepwater Horizon (and hundreds of other smaller disasters, still with larger environmental impact than the Fukushima incident) never happened?
The reality is that nuclear is safer than oil, and yet there is so much fear, It's like airplanes, occasionaly one falls down and people are afraid of flying even though it is 100x safer than driving a car which people do every day without fear.
I'm working in a company that does Scientific Visualization, and we have driver issues on a regular basis and have to find workarounds for them. It's a big pain to do testing with all kinds of different configurations and try to work around the problems in the drivers. The reason you don't have driver issues is because you play games and the poor graphics programmers have had to work around all the issues in the drivers you're running. If you have some combination of driver/graphics card that the developers didn't test, chances are you're going to have issues.
Honestly, I would pick Visual Studio / C#... I have a MacBookPro as my home computer and I program C++ (in a variety of environments) for a living. Visual Studio is by far the best IDE I've used (the others are XCode, Eclipse and QT Creator), actually the only IDE which has good integration of the debugger and working go-to-definition for non-trivial C++ code.
I've done a bit of C# programming recently and I expected to hate it, since I'm not a big fan of Java and everyone were telling me it is a similar language. However it's proven to be a wonderful experience, the.NET libraries are well thought out and work well with the language features, the delgate system works fantastic for GUI applications, the WinForms editors are a joy to use and the edit-and-continue debugging is amazing.
XCode is getting better now that they are moving over to the clang/LLVM toolchain instead of gcc. It will eventually let Apple provide a good IDE experience which has never been the goal of gcc/gdb. Unfortunately Objective-C is not a modern programming language and Apple really needs a strategy for a next generation programming language. Here's to hoping they adopt C# and make a C#/Cocoa alternative to C#/.NET (probably right about the time hell freezes over).
Apple is just requiring that the Sony Reader app doesn't include functionality to launch the web browser to purchase content from inside the app. If you're able to purchase content from within the App, it has to be through Apple's API (which gives a 30% cut to Apple). Not very newsworthy if you ask me...
The article is just a very bad summary of a sony press release about how they were not allowed to circumvent the apple 30% cut of _in App_ purchases by creating their own purchasing system in their app. Nothing has changed about Apple's terms.
No, the insanity here is that Google and Mozilla refuse to use the codecs installed in the operating system that you've already paid royalties for (if they require royalties to be paid) and that automatically take advantage of hardware acceleration and any other features the OS offers for media playback.
What Google (and Mozilla) _should_ do if they want to play nice and not just hurt their competitors is to bundle a DirectShow/Quicktime codec for WebM in their Windows/Mac version of their browser. This would also enable all other applications on the OS to play WebM so it's a win-win.
Please point me to this alleged plug-in that can be used to view h264 encoded HTML5 video in Firefox. I'm using OS-X so the windows media player bridge for windows doesn't count.
I must be confused, but you're saying that the browser that won't let me play certain formats is looking out for my freedom while the browser that lets me play anything I install/develop a codec for is restricting my freedom?
While Apple might be 'politically opposed to Ogg Theora and WebM', at least they don't restrict my freedom to play those formats in their browser.
You are exactly right, this is a serious accusation and he should have contacted Tandberg before making claims like this. And if he had done so he would have found out that the code that the patent was based on was checked in to the Tandberg repository more than half a year before the code in x264 was checked in. Tandberg is preparing an official statement about this as we speak. Making serious accusations like this without first contacting Tandberg is irresponsible and unprofessional.
I would disagree and say that making a good API instead of just exposing the underlying architecture directly is an art. With experience you start to see how people often go wrong in the same ways when trying to use your API and it becomes a game of trying to make the API in such a way that 1) all errors are caught 2) all the possible ways you can use the API which is not an error actually work and 3) that it's relatively intuitive to write good code with good performance.
An in-depth look at Microsoft Security Essentials, it made me decide to try it out on my girlfriend's laptop (I run OS X myself) and it's worked great.
The computers just brute-force chess, but a team of human+computer (look up "Advanced Chess") is much stronger than just a computer. This is because humans have much better chess intuition, so if they can rely on the computer to double-check that they haven't missed some tactic twenty moves deep in the position they can do really well. It's a bit like using a calculator when you do maths, you can avoid basic errors and do the basic calculations faster but you still need to come up with a plan of how you arrive at the solution.
Needless to say, in the game of Go computers are still pretty pathetic.
If you app is performing a function that really needs to be as locked-down and secure as possible, then you shouldn't be using shared libraries or DLLs at all. Fortunately, there are very, very few types of apps where such concerns are valid.
You do realise that the SxS cache is primarily used for system libraries like the C runtime, MFC and ATL? I've yet to see any third party ship their libraries as SxS assemblies. I think it's probably quite important that it's hard to compromise the system DLLs, and since almost all programs use them it's a huge win to have them in the SxS cache instead of distributing them in each application's directory.
And again, the SxS signing approach doesn't actually add any real security. Someone wanting to modify an application will find a way to do it regardless of any special "don't modify me" bits the application might contain.
You think public key signatures of the executable and it's dependencies is not real security?... Then what is?
if one of your DLLs were complied with one version of the datastructure and the other with another version, how else would you try to run this? Do you think the libtool system can solve this?... Of course it goes wrong if your application starts sending datastructures between DLL A and DLL B which are using different major versions of DLL C, but you can actually code around this. It's better to upgrade your dependencies so they use the same version of DLL C, but sometimes that's just not possible so you have to work with what you've got.
This was a _minor_ version update which means that the newer library gets loaded even for DLLs that reference the older version. So I think your points are all not valid. It's just that this guy forgot to include the runtime libraries in the installer or had some kind of weird setup where he was not including the patched version of the runtime libraries even after his build machine had been patched.
Why do you think it's a hack? I mean, the manifest files used by the SxS assembly system are much more expressive than the three digits used by libtool versioning to tell which shared libraries can be loaded for a specific process. Also note that two DLLs loaded into a process can reference different major versions of the same third DLL without a name clash (leading to two versions of it being loaded), while that's AFAIK not possible with shared libraries.
The SxS system also has some additional security since it uses signatures for the DLLs when loading your process, so it's much harder for a hacker to replace the library you're using behind your back (by setting LD_LIBRARY_PATH for example).
Everybody who developes applications for the Windows platform should know that you need to include the merge module for the C/C++ runtime libraries in your installer. You've just been luck so far that other applications have installed the DLL's you needed for you. Try your app the way it is on a clean install of Windows XP without the service packs and see how well that goes:P
In fact the SxS assembly system in windows is the only real way out of DLL hell, much better than the versioning scheme for shared libraries used in Linux. Get your facts straight before posting.
... with the ability, knowledge and inclination. The real problem is that they can all make twice or more money by doing some other line of work. This is a matter of paying what is necessary to compete with the other possibilities open to mathematically able, knowledgeable and inclined people.
There is no doubt that multi-core, multi-cpu programming is the future, but at the moment the tools are bascially crap. At least with CUDA there's a programming paradigm that's actually usable, but there is still no way to debug your program. Well, you can run in emulation mode, but your code will run so slow it never gets to the point where the bug occurs -- and anyway if you have a non-trivial bug it won't behave the same. And CUDA has the _best_ of these next generation toolchains. Until you have real debugging and profiling capabilities, even the best programmers won't be able to reach the level of productivity they can on more mature platforms...
I'm interested in how you would design an experiment to show that the brain is doing something uncomputable. I know that people seem to be poor at solving problems of low computational complexity compared to computers, while they are relatively good at solving problems of high computational complexity. So I don't think it seems so improbable that our 'reasoning' is fundamentally different from computation. However I have no idea how you would make an experiment to either prove or disprove this hypothesis.
The best way to learn the game on the internet is the one I link to in my signature. But the very best way to learn the game is to find a go club near you and show up in person. Most go clubs in the west are very friendly towards beginners, since there are relatively few players the aim is to make more people play not to 'be the best'. If there are no go clubs near you I reccommend playing online at www.gokgs.com
Slashdot Mirror
So, Deepwater Horizon (and hundreds of other smaller disasters, still with larger environmental impact than the Fukushima incident) never happened?
The reality is that nuclear is safer than oil, and yet there is so much fear, It's like airplanes, occasionaly one falls down and people are afraid of flying even though it is 100x safer than driving a car which people do every day without fear.
I'm working in a company that does Scientific Visualization, and we have driver issues on a regular basis and have to find workarounds for them. It's a big pain to do testing with all kinds of different configurations and try to work around the problems in the drivers. The reason you don't have driver issues is because you play games and the poor graphics programmers have had to work around all the issues in the drivers you're running. If you have some combination of driver/graphics card that the developers didn't test, chances are you're going to have issues.
Honestly, I would pick Visual Studio / C# ... I have a MacBookPro as my home computer and I program C++ (in a variety of environments) for a living. Visual Studio is by far the best IDE I've used (the others are XCode, Eclipse and QT Creator), actually the only IDE which has good integration of the debugger and working go-to-definition for non-trivial C++ code.
I've done a bit of C# programming recently and I expected to hate it, since I'm not a big fan of Java and everyone were telling me it is a similar language. However it's proven to be a wonderful experience, the .NET libraries are well thought out and work well with the language features, the delgate system works fantastic for GUI applications, the WinForms editors are a joy to use and the edit-and-continue debugging is amazing.
XCode is getting better now that they are moving over to the clang/LLVM toolchain instead of gcc. It will eventually let Apple provide a good IDE experience which has never been the goal of gcc/gdb. Unfortunately Objective-C is not a modern programming language and Apple really needs a strategy for a next generation programming language. Here's to hoping they adopt C# and make a C#/Cocoa alternative to C#/.NET (probably right about the time hell freezes over).
You copied the game and even made the name of the game sound similar to the original, and you call it a 'witch hunt' -- man, you need a reality check.
Apple is just requiring that the Sony Reader app doesn't include functionality to launch the web browser to purchase content from inside the app. If you're able to purchase content from within the App, it has to be through Apple's API (which gives a 30% cut to Apple). Not very newsworthy if you ask me...
The article is just a very bad summary of a sony press release about how they were not allowed to circumvent the apple 30% cut of _in App_ purchases by creating their own purchasing system in their app. Nothing has changed about Apple's terms.
http://digitaldaily.allthingsd.com/20110201/apple-on-sony-reader-we-have-not-changed-our-guidelines/
No, the insanity here is that Google and Mozilla refuse to use the codecs installed in the operating system that you've already paid royalties for (if they require royalties to be paid) and that automatically take advantage of hardware acceleration and any other features the OS offers for media playback.
What Google (and Mozilla) _should_ do if they want to play nice and not just hurt their competitors is to bundle a DirectShow/Quicktime codec for WebM in their Windows/Mac version of their browser. This would also enable all other applications on the OS to play WebM so it's a win-win.
Please point me to this alleged plug-in that can be used to view h264 encoded HTML5 video in Firefox. I'm using OS-X so the windows media player bridge for windows doesn't count.
I must be confused, but you're saying that the browser that won't let me play certain formats is looking out for my freedom while the browser that lets me play anything I install/develop a codec for is restricting my freedom?
While Apple might be 'politically opposed to Ogg Theora and WebM', at least they don't restrict my freedom to play those formats in their browser.
You are exactly right, this is a serious accusation and he should have contacted Tandberg before making claims like this. And if he had done so he would have found out that the code that the patent was based on was checked in to the Tandberg repository more than half a year before the code in x264 was checked in. Tandberg is preparing an official statement about this as we speak. Making serious accusations like this without first contacting Tandberg is irresponsible and unprofessional.
I would disagree and say that making a good API instead of just exposing the underlying architecture directly is an art. With experience you start to see how people often go wrong in the same ways when trying to use your API and it becomes a game of trying to make the API in such a way that 1) all errors are caught 2) all the possible ways you can use the API which is not an error actually work and 3) that it's relatively intuitive to write good code with good performance.
You forgot:
6) Paid a lot of money to do it.
http://arstechnica.com/microsoft/news/2009/09/first-look-microsoft-security-essentials-impresses.ars
An in-depth look at Microsoft Security Essentials, it made me decide to try it out on my girlfriend's laptop (I run OS X myself) and it's worked great.
The computers just brute-force chess, but a team of human+computer (look up "Advanced Chess") is much stronger than just a computer. This is because humans have much better chess intuition, so if they can rely on the computer to double-check that they haven't missed some tactic twenty moves deep in the position they can do really well. It's a bit like using a calculator when you do maths, you can avoid basic errors and do the basic calculations faster but you still need to come up with a plan of how you arrive at the solution.
Needless to say, in the game of Go computers are still pretty pathetic.
If you app is performing a function that really needs to be as locked-down and secure as possible, then you shouldn't be using shared libraries or DLLs at all. Fortunately, there are very, very few types of apps where such concerns are valid.
You do realise that the SxS cache is primarily used for system libraries like the C runtime, MFC and ATL? I've yet to see any third party ship their libraries as SxS assemblies. I think it's probably quite important that it's hard to compromise the system DLLs, and since almost all programs use them it's a huge win to have them in the SxS cache instead of distributing them in each application's directory.
And again, the SxS signing approach doesn't actually add any real security. Someone wanting to modify an application will find a way to do it regardless of any special "don't modify me" bits the application might contain.
You think public key signatures of the executable and it's dependencies is not real security? ... Then what is?
if one of your DLLs were complied with one version of the datastructure and the other with another version, how else would you try to run this? Do you think the libtool system can solve this? ... Of course it goes wrong if your application starts sending datastructures between DLL A and DLL B which are using different major versions of DLL C, but you can actually code around this. It's better to upgrade your dependencies so they use the same version of DLL C, but sometimes that's just not possible so you have to work with what you've got.
This was a _minor_ version update which means that the newer library gets loaded even for DLLs that reference the older version. So I think your points are all not valid. It's just that this guy forgot to include the runtime libraries in the installer or had some kind of weird setup where he was not including the patched version of the runtime libraries even after his build machine had been patched.
Why do you think it's a hack? I mean, the manifest files used by the SxS assembly system are much more expressive than the three digits used by libtool versioning to tell which shared libraries can be loaded for a specific process. Also note that two DLLs loaded into a process can reference different major versions of the same third DLL without a name clash (leading to two versions of it being loaded), while that's AFAIK not possible with shared libraries.
http://www.freesoftwaremagazine.com/books/agaal/building_shared_libraries_once_using_autotools
The SxS system also has some additional security since it uses signatures for the DLLs when loading your process, so it's much harder for a hacker to replace the library you're using behind your back (by setting LD_LIBRARY_PATH for example).
Everybody who developes applications for the Windows platform should know that you need to include the merge module for the C/C++ runtime libraries in your installer. You've just been luck so far that other applications have installed the DLL's you needed for you. Try your app the way it is on a clean install of Windows XP without the service packs and see how well that goes :P
In fact the SxS assembly system in windows is the only real way out of DLL hell, much better than the versioning scheme for shared libraries used in Linux. Get your facts straight before posting.
... with the ability, knowledge and inclination. The real problem is that they can all make twice or more money by doing some other line of work. This is a matter of paying what is necessary to compete with the other possibilities open to mathematically able, knowledgeable and inclined people.
There is no doubt that multi-core, multi-cpu programming is the future, but at the moment the tools are bascially crap. At least with CUDA there's a programming paradigm that's actually usable, but there is still no way to debug your program. Well, you can run in emulation mode, but your code will run so slow it never gets to the point where the bug occurs -- and anyway if you have a non-trivial bug it won't behave the same. And CUDA has the _best_ of these next generation toolchains. Until you have real debugging and profiling capabilities, even the best programmers won't be able to reach the level of productivity they can on more mature platforms...
You're trolling, right? iTunes plays anything Quicktime plays and you can get Quicktime plugins for all the formats you mentioned...
I'm interested in how you would design an experiment to show that the brain is doing something uncomputable. I know that people seem to be poor at solving problems of low computational complexity compared to computers, while they are relatively good at solving problems of high computational complexity. So I don't think it seems so improbable that our 'reasoning' is fundamentally different from computation. However I have no idea how you would make an experiment to either prove or disprove this hypothesis.
The best way to learn the game on the internet is the one I link to in my signature. But the very best way to learn the game is to find a go club near you and show up in person. Most go clubs in the west are very friendly towards beginners, since there are relatively few players the aim is to make more people play not to 'be the best'. If there are no go clubs near you I reccommend playing online at www.gokgs.com