What check? That's at most half of the solution. It covers most cases on Unix systems, but the situation on Windows (which was referred to explicitly) is a far greater mess. The way linking happens depends on about 10 to 20 different things, and not all of them are under your control.
The alternative is deep packet inspection, on the fly ad replacement by your ISP, and some legalese in your contract with the ISP that forces you to not suppress those ISP-injected ads. The technology has been demonstrated. It's a question of when they'll get serious about it.
How do you explain that gnome is actually more configurable than it presents itself? There are vastly more options in the gconf database than in the GUI. By your logic, these shouldn't exist.
A lot of the libraries are actually loaded dynamically for certain tasks, so they never show up in ldd. But they are surely used. I'd wager that just viewing an HTML mail with an embedded image in kmail uses more of those plugins than you would believe. The beauty of it isn't that KDE apps have lots of features. It's in the fact that most of the features are in a shared framework, which ideally isn't even loaded into memory once per running program.
At least it's not wasted on such ridiculous things as Crysis, Call of Duty, Battlefield and all the other high budget game productions out there - oh, wait... the money they make is actually why you have that nice hardware *at all*.
I know this isn't the place for facts, but the Windows 8 installer asks the user whether to enable Do Not Track on the first start. The switch is on by default, but it can be turned off then. This happens well before IE10 is even started for the first time. And Windows 8 is currently the only available edition of IE10...
I'm feeling the same pain on Linux, but OS X is not appropriate for me at the moment (Apple hardware doesn't meet my - very special - requirements right now). So I'm using Windows more often nowadays because I've never run a non-multiboot system at home...
Because they are not installed with the rest of the system by default. So an average user tries to play video and all he gets is an obscure yes/no prompt from the video player with some gibberish about "video codecs" and "support" and "installation". Maybe he clicks yes, maybe no. But it's a pretty random choice at this point. If the user clicked yes, a password prompt appears. "Huh? What's that? Why do I suddenly have to enter a password to play a video? Something is seriously wrong here." So our average user is likely to hit cancel at that point and be very confused.
TL;DR: It's a confusing experience on Ubuntu for solely political reasons, ruining the user experience. Linux Mint just does does away with that. That's the difference.
That depends. Sometimes you have a hard time finding a possible result, but verifying it is simple. Factorization is just such a problem. So you repeat the algorithm and test the result until the test succeeds. If this is on average faster than a completely deterministic approach, you have won.
Literature recommendation: Ghost in the Wires. Kevin Mitnick describes some his thoughts behind his fake identities. He even provides a reference to the book that told him most of the tricks he mentions (and probably many more he didn't dare to write down).
I heard (through channels that I can't even reconstruct) roughly the same numbers from Ubisoft a couple of months ago. That same source said that the numbers were obtained by checking the game copies that conntected to the metaservers for online play. So if that's true, the numbers are valid, and probably even too low because pure offline play isn't included.
The caveat: if they can detect pirated copies that way, why aren't they blocked?
3D graphics programs like Maya and Houdini have a nice little set of features that comes quite close: they do not forget operations that you make, but instead can repeat them for you again and again. In fact, this mechanism exists to allow the user to go back and change parameters for old operations. The program then reruns the entire history (effectively a program) and displays the result. This works even for quite complex contraptions. In a way, this is just that same kind of visual debugging. Once you understand that a graph can be a representation of a program, that is. Animation features allow you to go back and forth in time and there are also features to trace out the complete paths of objects on the screen so that you can see it all at once.
Spreadsheets also come pretty close: if execution were allowed to loop and branch properly (to become Turing-complete), you would be able to create an instant visualization with them as well. Actually, the program would be its own visualization.
App crashes as a metric are skewed by the potential to produce crash bugs within the specific runtime environment. Take a bad programmer and let him write C code and Java code. My guess is that the Java code will crash less in the end because the potential to make really bad mistakes is a lot less.
Has anyone ever conducted that kind of experiment?
Oh, everything was fine under DOS? Really? Did you really forget all that crap about games having their own sound card drivers? Having to enter the correct IRQ numbers and IO addresses for the sound card model you have? Or how about freeing up enough memory in the infamous lower 640k for DOS programs so that your game would even start? How about choosing the right memory manager? I'm still amazed that mouse drivers didn't generate the same kind of trouble that sound card drivers did back then.
The reason for the current plateau is simply the fixed console hardware of the current generation that is now about ten years old. Game sales for consoles are way beyond PC sales, so it makes sense to put the effort into making things look as good as possible and and port stuff to the PC as it is. Even the "lower quality" assets for console games are expensive to create and require more than a hundred artists for over a year per AAA title. Creating the assets a second time in a higher resolution for the current generation of PC hardware is generally just not affordable given the overall sales figures.
I'll give that question a shot: maybe this is because it's a bit harder to make your app crash hard in Java than it is in Objective C. In Java, even a null pointer access just throws an ordinary, catchable exception. So the follow-up question for me is: how many of these exceptions are caught and ignored on Android that would cause a crash on iOS?
I am not an Apple fanboy, but I can understand the complaints about Android development and device compatibility. I'm not surprised that 3D rendering is a PITA on these things. It's not simple to create a decent renderer that works on all OpenGL implementations on the PC and that's with only 3 vendors putting a lot of effort into still crappy drivers. In the mobile phone market it's a lot more vendors with a lot more drivers and less resources for proper driver development. No suprise there.
However, the signal-to-noise-ratio is higher for each individual pixel. I'm not sure how the noise does scale exactly with pixel area, so I can't tell whether plain supersampling helps that much or much at all.
A while ago I read rather vage explanation that camera makers for these kinds of tiny cams do introduce certain errors in the camera optics on purpose so that they can tweak their way around the resolution barriers for sharp images. This trick naturally relies on a post-processing step. I wish I had more information on this kind of trick to judge it.
Not everything he said is a lie. LibreOffice Writer does not know how to handle styles with the Office OpenXML file format. I came across that issue quite recently.
Face it: LibreOffice isn't perfect, but it still works well enough for many purposes. Microsoft Office has the equivalent of a 10 year headstart through the sheer amount of money they can throw at software development and at times it shows.
I've occasionally had to review papers outside of my immediate subject area (don't ask how that comes to be...). In that case I have to honestly state that I basically know nothing, but even then I have to go through the rest of the motions of the review. So I end up giving (quite likely unjustified) criticism because I have to write down my judgement. My only hope is then that the primary reviewer notices my low confidence rating and uses it to ignore the result of this review, if I did get it too wrong.
Maybe because the software takes a rocket scientist to build in the first place? Maybe because you target users who should not have a need to learn about using a compiler and fixing fuckups in the system libs created by wild patching from distribution creators? Maybe because handing out the sources to your game would open the doors even wider for cheaters (server-side input testing is generally not enough)?
Back in 1996 it was at least very uncommon to actually do that. This kind of automatically filtering arrived in common desktop software many years later, if I'm not mistaken.
Slashdot Mirror
What check? That's at most half of the solution. It covers most cases on Unix systems, but the situation on Windows (which was referred to explicitly) is a far greater mess. The way linking happens depends on about 10 to 20 different things, and not all of them are under your control.
The alternative is deep packet inspection, on the fly ad replacement by your ISP, and some legalese in your contract with the ISP that forces you to not suppress those ISP-injected ads. The technology has been demonstrated. It's a question of when they'll get serious about it.
Europe does not grow enough food to feed itself.
So this is why the EU sells overproduced food to Africa on the cheap?
How do you explain that gnome is actually more configurable than it presents itself? There are vastly more options in the gconf database than in the GUI. By your logic, these shouldn't exist.
... which ideally is loaded into memory only once, even for multiple programs. Sorry, posted too early.
A lot of the libraries are actually loaded dynamically for certain tasks, so they never show up in ldd. But they are surely used. I'd wager that just viewing an HTML mail with an embedded image in kmail uses more of those plugins than you would believe. The beauty of it isn't that KDE apps have lots of features. It's in the fact that most of the features are in a shared framework, which ideally isn't even loaded into memory once per running program.
At least it's not wasted on such ridiculous things as Crysis, Call of Duty, Battlefield and all the other high budget game productions out there - oh, wait... the money they make is actually why you have that nice hardware *at all*.
I know this isn't the place for facts, but the Windows 8 installer asks the user whether to enable Do Not Track on the first start. The switch is on by default, but it can be turned off then. This happens well before IE10 is even started for the first time. And Windows 8 is currently the only available edition of IE10...
Nah, these capsules are designed for lawyers and politicians.
I'm feeling the same pain on Linux, but OS X is not appropriate for me at the moment (Apple hardware doesn't meet my - very special - requirements right now). So I'm using Windows more often nowadays because I've never run a non-multiboot system at home...
Because they are not installed with the rest of the system by default. So an average user tries to play video and all he gets is an obscure yes/no prompt from the video player with some gibberish about "video codecs" and "support" and "installation". Maybe he clicks yes, maybe no. But it's a pretty random choice at this point. If the user clicked yes, a password prompt appears. "Huh? What's that? Why do I suddenly have to enter a password to play a video? Something is seriously wrong here." So our average user is likely to hit cancel at that point and be very confused.
TL;DR: It's a confusing experience on Ubuntu for solely political reasons, ruining the user experience. Linux Mint just does does away with that. That's the difference.
That depends. Sometimes you have a hard time finding a possible result, but verifying it is simple. Factorization is just such a problem. So you repeat the algorithm and test the result until the test succeeds. If this is on average faster than a completely deterministic approach, you have won.
Literature recommendation: Ghost in the Wires. Kevin Mitnick describes some his thoughts behind his fake identities. He even provides a reference to the book that told him most of the tricks he mentions (and probably many more he didn't dare to write down).
I heard (through channels that I can't even reconstruct) roughly the same numbers from Ubisoft a couple of months ago. That same source said that the numbers were obtained by checking the game copies that conntected to the metaservers for online play. So if that's true, the numbers are valid, and probably even too low because pure offline play isn't included.
The caveat: if they can detect pirated copies that way, why aren't they blocked?
3D graphics programs like Maya and Houdini have a nice little set of features that comes quite close: they do not forget operations that you make, but instead can repeat them for you again and again. In fact, this mechanism exists to allow the user to go back and change parameters for old operations. The program then reruns the entire history (effectively a program) and displays the result. This works even for quite complex contraptions. In a way, this is just that same kind of visual debugging. Once you understand that a graph can be a representation of a program, that is. Animation features allow you to go back and forth in time and there are also features to trace out the complete paths of objects on the screen so that you can see it all at once.
Spreadsheets also come pretty close: if execution were allowed to loop and branch properly (to become Turing-complete), you would be able to create an instant visualization with them as well. Actually, the program would be its own visualization.
App crashes as a metric are skewed by the potential to produce crash bugs within the specific runtime environment. Take a bad programmer and let him write C code and Java code. My guess is that the Java code will crash less in the end because the potential to make really bad mistakes is a lot less.
Has anyone ever conducted that kind of experiment?
Oh, everything was fine under DOS? Really? Did you really forget all that crap about games having their own sound card drivers? Having to enter the correct IRQ numbers and IO addresses for the sound card model you have? Or how about freeing up enough memory in the infamous lower 640k for DOS programs so that your game would even start? How about choosing the right memory manager? I'm still amazed that mouse drivers didn't generate the same kind of trouble that sound card drivers did back then.
I can't say that I miss DOS.
The reason for the current plateau is simply the fixed console hardware of the current generation that is now about ten years old. Game sales for consoles are way beyond PC sales, so it makes sense to put the effort into making things look as good as possible and and port stuff to the PC as it is. Even the "lower quality" assets for console games are expensive to create and require more than a hundred artists for over a year per AAA title. Creating the assets a second time in a higher resolution for the current generation of PC hardware is generally just not affordable given the overall sales figures.
I'll give that question a shot: maybe this is because it's a bit harder to make your app crash hard in Java than it is in Objective C. In Java, even a null pointer access just throws an ordinary, catchable exception. So the follow-up question for me is: how many of these exceptions are caught and ignored on Android that would cause a crash on iOS?
I am not an Apple fanboy, but I can understand the complaints about Android development and device compatibility. I'm not surprised that 3D rendering is a PITA on these things. It's not simple to create a decent renderer that works on all OpenGL implementations on the PC and that's with only 3 vendors putting a lot of effort into still crappy drivers. In the mobile phone market it's a lot more vendors with a lot more drivers and less resources for proper driver development. No suprise there.
However, the signal-to-noise-ratio is higher for each individual pixel. I'm not sure how the noise does scale exactly with pixel area, so I can't tell whether plain supersampling helps that much or much at all.
A while ago I read rather vage explanation that camera makers for these kinds of tiny cams do introduce certain errors in the camera optics on purpose so that they can tweak their way around the resolution barriers for sharp images. This trick naturally relies on a post-processing step. I wish I had more information on this kind of trick to judge it.
Not everything he said is a lie. LibreOffice Writer does not know how to handle styles with the Office OpenXML file format. I came across that issue quite recently.
Face it: LibreOffice isn't perfect, but it still works well enough for many purposes. Microsoft Office has the equivalent of a 10 year headstart through the sheer amount of money they can throw at software development and at times it shows.
I've occasionally had to review papers outside of my immediate subject area (don't ask how that comes to be...). In that case I have to honestly state that I basically know nothing, but even then I have to go through the rest of the motions of the review. So I end up giving (quite likely unjustified) criticism because I have to write down my judgement. My only hope is then that the primary reviewer notices my low confidence rating and uses it to ignore the result of this review, if I did get it too wrong.
Try that with OO.o or Firefox. Good luck!
Maybe because the software takes a rocket scientist to build in the first place? Maybe because you target users who should not have a need to learn about using a compiler and fixing fuckups in the system libs created by wild patching from distribution creators? Maybe because handing out the sources to your game would open the doors even wider for cheaters (server-side input testing is generally not enough)?
Back in 1996 it was at least very uncommon to actually do that. This kind of automatically filtering arrived in common desktop software many years later, if I'm not mistaken.