It's pretty obvious that what's happening is that every time they start it up at full power, it collapses the false vacuum and instantly destroys the universe. So the only versions of the state vector we can observe are the ones in which the LHC never ramps up all the way, because we've been destroyed in the rest of them...
"With the Internet, the greatest disseminator of bad data and bad information the universe has ever known, it's become impossible to trust any news from any source at all, because it's all filtered through this crazy yenta gossip line. It's impossible to know anything."
Soft-science academics have been complaining about the Crazy Yenta Gossip Line ever since it got big enough for them to notice.
Doesn't stop them from being a hugely active part of it.
Just think, in the future you could read a sentence, and then as soon as you finish reading it, it could change right before your eyes to say the opposite of what it originally said.
Apple removed copies of the book "Nineteen Eighty-Four" (which, ironically, describes a pre-computer version of this problem) from peoples Kindles. Apple could just as easily have revised the book if they wanted to.
This is satire, right? You're illustrating the point by substituting "Apple" for "Amazon" here?
The first part is harder: it's more difficult to understand five people speaking simultaneously than one person talking fast -- especially if you can tell the one person to stop temporarily, or go back and repeat.
That's why the Internet is still mostly text. Typing is slower than talking, but reading is faster than listening, and reading doesn't suffer from this problem.
I don't know whose fault it is but the idea of running ISS plugins under Apache on Windows scares me. Whose fault is it when you run naked through the "hot" ward snogging the e-bola patients? It's ironic that you end up getting sick because the pretty nurse you kissed had mono, but... good lord, people...
If you were running a new version of WoW on all platforms that had been rewritten from scratch in a brand new API designed specifically to be portable, yes, I would be disappointed that they had to write 10% device-specific code. Or *any* device-specific code.
It's just like Apple and Microsoft both pushing DRM that wasn't compatible with each other. It's good for consumers, in the long term, because it teaches them not to trust it earlier rather than later when it really matters. Thank you Ubisoft, I hope you learned your lesson as well.
Unix pipe and filters can't be used to build a complex workflow. They are unidirectional streams of bytes. They are useful tools, but when was the last time you wrote a shell script that used only pipes?
Did you miss the next sentence of my message?
The next step from UNIX pipes and filters was never taken.
And the procedural model is increasingly a bottleneck. Dataflow design is highly paralellizable and latency insensitive.
But I would add that it's not just a matter of API design, it's also a matter of use cases.
Sure, but that's no excuse not to implement standard methods. I'm really tired of digging through documents trying to figure out whether the method I want is called length() or size() (or, when there's separate length() and size() methods in a class (yes, really), whether they're aliases or not). I'm tired of "reverse-hungarian" method typing like toStringA() and toStringW() (not to mention people using "C style" hungarian method names like szName in a language with strings as a fundamental data type). This stuff shouldn't be rocket science.
God almighty, their code base is more fragmented than I ever imagined.
Even at the worst of the "UNIX wars", if you had to rewrite as much as 10% of your code to get it to run on (say) AIX, SunOS, and System V that meant you'd done a really bad job of isolating the platform-specific parts of your code. If Microsoft can't keep their code bases in sync when they control all of them and they have incentive to do so, they're really slipping.
Back in the 1990's, all the rage was about "software components", what was back then a dream.
Back in the '70s, software components were already achieved, in UNIX pipes and filters. They really WERE as easy to put together as electronic components. Extending the dataflow model to structured data with a nice 2d shell that let you tie your pipes and filters together in ways that the UNIX shell couldn't dream of seemed like the obvious next step. Instead what we have today is LINPACK on steroids. It doesn't matter whether your framework is FORTRAN, COM, or EnterpriseJavaBeansOnHoliday, or whether you spend all your time looking up the parameters of ObscureFunctionThatAlmostDoesWhatYouNeed, or figuring out why ComplexClassYouNeed doesn't support StandardMethodThatEveryOtherClassSupports, or researching the efficient way to do INSERT OR UPDATE in YetANotherNotQuiteSQL, the API always seems to be a huge ugly mess that reminds me of the 47 parameters (or however many it is) you need to specify an open file call in OS/360.
There seems to be a shortage of people who actually know how to design an API. It's like library designers get halfway through Stage 2 and go "Man, this is boring... oh well, I've implemented everything I need, let's release it and call it done".
If you play the demo version of Windows 7, after some time period it starts locking up periodically, and you must buy a full version to restore the full game functionality.
I'm not talking about software on the controller, I'm talking about software on the CPU. If it was possible to jigger the process of writing a sector of data on an MFM controller to write raw bits to the disk surface, you could convert the sector to RLL in the driver and write that. That's how a lot of copy protection on Apple II and Amiga worked (the Amiga used the Blitter for encoding and decoding, the Apple II just did it in the 6502).
I suppose it MIGHT be possible to jigger some drives to format a cylinder in some specific weird format, so it contains information you can only get at if you use a 666 byte sector size, but even this kind of thing hasn't really been possible on hard drives any time... I don't think even ST506 MFM and RLL controllers let you do much more than jigger some encoding of the sector and the sector size, otherwise you'd have been able to upgrade an MFM controller to RLL in software.
Heck, the ability of the Apple-II and Amiga *floppy* controllers to play clever games at the bit/nybble/byte level was unusual.
And given that the most common use of that kind of shenanigans was for copy protection, the speculation this fellow is looking for some help in coming up with a hard DRM scheme seems spot on.
Well the barrier to entry in my mind is separate from the lock-in part.
My point was that Windows has two barriers to entry: economy of scale, and application lock in.
Google only has economy of scale. If you're searching using Google, there's no cost to you to try something else, so there's no "if you switch to Bing you can't run Office any more". You don't even have to *switch*, there's no cost to using both.
Also Linux as a platform could have vendor lock-in from apps too. Or are you just considering open-source apps on Linux?
I've run Linux binaries on FreeBSD. In fact there's at least one hosting service that's provided Linux virtual colo using a Linux userland under FreeBSD Linux emulation in a FreeBSD jail.
Also, the barrier to entry *is* great. It would costs hundreds of millions of dollars to setup data centers to give any kind of competition to Google.
Depends on where you start.
There's lots of special-purpose search engines and portals that compete very well with Goole/Bing/etcetera by focusing on a specific problem space... an application, a group, a genre...
And costing hundreds of millions to compete with Google isn't necessarily a sign of the kind of barrier to entry we're talking about. It would cost hundreds of millions to compete with Linux, but that doesn't mean that Linux has deliberate application lock-in the way Windows does. You can get your application out of Linux and onto BSD, OSX, or even Windows without a huge amount of effort, but unless you went to outrageous lengths to make your app portable in the first place you're not going to take it from Windows to anything else at all easily.
If you know anything about sorting, you can see the problem here. Sorting requires a self-consistent definition of ordering. The following assertions must be true if sorting is to make any sense at all:
1. If aa
2. If a>b then bb and b>c then a>c
6. If a=b and b=c then a=c
All of these statements are violated by the given Microsoft comparison function.
The problem has nothing to do with whether they generated a random float between 0 and 1 and subtracted 0.5, or generated a random integer between 0 and 2 and subtracted 1. The problem is that
1. You need to get *the same* result when comparing A to B the first time, and when comparing A to B the second time. 2. When you're comparing multiple sets of numbers the results need to be well-ordered. If A B and B C then A C.
If you're just generating a random result for every comparison, then these are no longer true.
By memoizing the result of the comparison algorithm, you can fix (1), but (2) will remain a problem. And it doesn't matter what "fan belt" you plug in to generate the random numbers, you're still trying to use it as a necktie.
It's pretty clear that's what happened in this case. [gibberish about using the wrong PRNG API]
No, um, it isn't. It isn't. At all. Go back and re-read the article until you understand it. If the big words are too much, crack open the shop manual (Knuth, H&S, whatever your college algorithms course used) and study the way sort algorithms work until you get it figured out.
Seriously. You are completely wrong at every level.
Knuth is definitely not a shop manual, because he makes a point of not talking about specific implementations.
Knuth is the shop manual for "sorting and searching", or for "data structures". There are other "shop manuals", like Horowitz and Sahni, or other college texts, but they're all similar to Knuth. The API guide isn't the shop manual, the API guide is for someone who has already read the shop manual.
The API programmer's guide is the instructions on the back of the box the "sort function" comes in. It doesn't tell you "don't use the sort function this way" any more than the fanbelt comes with instructions telling you not to use it as a necktie.
Slashdot Mirror
It's pretty obvious that what's happening is that every time they start it up at full power, it collapses the false vacuum and instantly destroys the universe. So the only versions of the state vector we can observe are the ones in which the LHC never ramps up all the way, because we've been destroyed in the rest of them...
I guess it depends on how long it takes before Steam's anti-cheat code starts stomping on other apps.
Not interested in running a rootkit engine on my Mac.
That's not what the incompleteness theorem says.
"With the Internet, the greatest disseminator of bad data and bad information the universe has ever known, it's become impossible to trust any news from any source at all, because it's all filtered through this crazy yenta gossip line. It's impossible to know anything."
Soft-science academics have been complaining about the Crazy Yenta Gossip Line ever since it got big enough for them to notice.
Doesn't stop them from being a hugely active part of it.
Just think, in the future you could read a sentence, and then as soon as you finish reading it, it could change right before your eyes to say the opposite of what it originally said.
Google Buzz Trick - The Edit Button
Apple removed copies of the book "Nineteen Eighty-Four" (which, ironically, describes a pre-computer version of this problem) from peoples Kindles. Apple could just as easily have revised the book if they wanted to.
This is satire, right? You're illustrating the point by substituting "Apple" for "Amazon" here?
The first part is harder: it's more difficult to understand five people speaking simultaneously than one person talking fast -- especially if you can tell the one person to stop temporarily, or go back and repeat.
That's why the Internet is still mostly text. Typing is slower than talking, but reading is faster than listening, and reading doesn't suffer from this problem.
I don't know whose fault it is but the idea of running ISS plugins under Apache on Windows scares me. Whose fault is it when you run naked through the "hot" ward snogging the e-bola patients? It's ironic that you end up getting sick because the pretty nurse you kissed had mono, but ... good lord, people...
If you were running a new version of WoW on all platforms that had been rewritten from scratch in a brand new API designed specifically to be portable, yes, I would be disappointed that they had to write 10% device-specific code. Or *any* device-specific code.
It's just like Apple and Microsoft both pushing DRM that wasn't compatible with each other. It's good for consumers, in the long term, because it teaches them not to trust it earlier rather than later when it really matters. Thank you Ubisoft, I hope you learned your lesson as well.
Color me unimpressed. Device-dependent APIs were embarrassing in the '80s.
Unix pipe and filters can't be used to build a complex workflow. They are unidirectional streams of bytes. They are useful tools, but when was the last time you wrote a shell script that used only pipes?
Did you miss the next sentence of my message?
The next step from UNIX pipes and filters was never taken.
And the procedural model is increasingly a bottleneck. Dataflow design is highly paralellizable and latency insensitive.
But I would add that it's not just a matter of API design, it's also a matter of use cases.
Sure, but that's no excuse not to implement standard methods. I'm really tired of digging through documents trying to figure out whether the method I want is called length() or size() (or, when there's separate length() and size() methods in a class (yes, really), whether they're aliases or not). I'm tired of "reverse-hungarian" method typing like toStringA() and toStringW() (not to mention people using "C style" hungarian method names like szName in a language with strings as a fundamental data type). This stuff shouldn't be rocket science.
God almighty, their code base is more fragmented than I ever imagined.
Even at the worst of the "UNIX wars", if you had to rewrite as much as 10% of your code to get it to run on (say) AIX, SunOS, and System V that meant you'd done a really bad job of isolating the platform-specific parts of your code. If Microsoft can't keep their code bases in sync when they control all of them and they have incentive to do so, they're really slipping.
Back in the 1990's, all the rage was about "software components", what was back then a dream.
Back in the '70s, software components were already achieved, in UNIX pipes and filters. They really WERE as easy to put together as electronic components. Extending the dataflow model to structured data with a nice 2d shell that let you tie your pipes and filters together in ways that the UNIX shell couldn't dream of seemed like the obvious next step. Instead what we have today is LINPACK on steroids. It doesn't matter whether your framework is FORTRAN, COM, or EnterpriseJavaBeansOnHoliday, or whether you spend all your time looking up the parameters of ObscureFunctionThatAlmostDoesWhatYouNeed, or figuring out why ComplexClassYouNeed doesn't support StandardMethodThatEveryOtherClassSupports, or researching the efficient way to do INSERT OR UPDATE in YetANotherNotQuiteSQL, the API always seems to be a huge ugly mess that reminds me of the 47 parameters (or however many it is) you need to specify an open file call in OS/360.
There seems to be a shortage of people who actually know how to design an API. It's like library designers get halfway through Stage 2 and go "Man, this is boring... oh well, I've implemented everything I need, let's release it and call it done".
If you play the demo version of Windows 7, after some time period it starts locking up periodically, and you must buy a full version to restore the full game functionality.
I'm not talking about software on the controller, I'm talking about software on the CPU. If it was possible to jigger the process of writing a sector of data on an MFM controller to write raw bits to the disk surface, you could convert the sector to RLL in the driver and write that. That's how a lot of copy protection on Apple II and Amiga worked (the Amiga used the Blitter for encoding and decoding, the Apple II just did it in the 6502).
I suppose it MIGHT be possible to jigger some drives to format a cylinder in some specific weird format, so it contains information you can only get at if you use a 666 byte sector size, but even this kind of thing hasn't really been possible on hard drives any time... I don't think even ST506 MFM and RLL controllers let you do much more than jigger some encoding of the sector and the sector size, otherwise you'd have been able to upgrade an MFM controller to RLL in software.
Heck, the ability of the Apple-II and Amiga *floppy* controllers to play clever games at the bit/nybble/byte level was unusual.
And given that the most common use of that kind of shenanigans was for copy protection, the speculation this fellow is looking for some help in coming up with a hard DRM scheme seems spot on.
Well the barrier to entry in my mind is separate from the lock-in part.
My point was that Windows has two barriers to entry: economy of scale, and application lock in.
Google only has economy of scale. If you're searching using Google, there's no cost to you to try something else, so there's no "if you switch to Bing you can't run Office any more". You don't even have to *switch*, there's no cost to using both.
Also Linux as a platform could have vendor lock-in from apps too. Or are you just considering open-source apps on Linux?
I've run Linux binaries on FreeBSD. In fact there's at least one hosting service that's provided Linux virtual colo using a Linux userland under FreeBSD Linux emulation in a FreeBSD jail.
Also, the barrier to entry *is* great. It would costs hundreds of millions of dollars to setup data centers to give any kind of competition to Google.
Depends on where you start.
There's lots of special-purpose search engines and portals that compete very well with Goole/Bing/etcetera by focusing on a specific problem space... an application, a group, a genre...
And costing hundreds of millions to compete with Google isn't necessarily a sign of the kind of barrier to entry we're talking about. It would cost hundreds of millions to compete with Linux, but that doesn't mean that Linux has deliberate application lock-in the way Windows does. You can get your application out of Linux and onto BSD, OSX, or even Windows without a huge amount of effort, but unless you went to outrageous lengths to make your app portable in the first place you're not going to take it from Windows to anything else at all easily.
The problem has nothing to do with whether they generated a random float between 0 and 1 and subtracted 0.5, or generated a random integer between 0 and 2 and subtracted 1. The problem is that
1. You need to get *the same* result when comparing A to B the first time, and when comparing A to B the second time.
2. When you're comparing multiple sets of numbers the results need to be well-ordered. If A B and B C then A C.
If you're just generating a random result for every comparison, then these are no longer true.
By memoizing the result of the comparison algorithm, you can fix (1), but (2) will remain a problem. And it doesn't matter what "fan belt" you plug in to generate the random numbers, you're still trying to use it as a necktie.
The search engine barrier to entry isn't as great, because users can't get "locked in" to one search engine like they can to an OS or API.
mod parent up "nice bitchslap". :)
It's pretty clear that's what happened in this case. [gibberish about using the wrong PRNG API]
No, um, it isn't. It isn't. At all. Go back and re-read the article until you understand it. If the big words are too much, crack open the shop manual (Knuth, H&S, whatever your college algorithms course used) and study the way sort algorithms work until you get it figured out.
Seriously. You are completely wrong at every level.
Knuth is definitely not a shop manual, because he makes a point of not talking about specific implementations.
Knuth is the shop manual for "sorting and searching", or for "data structures". There are other "shop manuals", like Horowitz and Sahni, or other college texts, but they're all similar to Knuth. The API guide isn't the shop manual, the API guide is for someone who has already read the shop manual.
The API programmer's guide is the instructions on the back of the box the "sort function" comes in. It doesn't tell you "don't use the sort function this way" any more than the fanbelt comes with instructions telling you not to use it as a necktie.