I'm sure that will go over really well: Punish people HARDER for picking on someone who's already advantaged compared to the perpetrator, as opposed to picking on someone who's disadvantaged. How about additional punishments for picking on the rich. Or those good at sports. Sorry, but we aren't QUITE yet living in the world of Idiocracy, so no, being smart doesn't make you a vulnerable class.
You mean, exactly how many postal services ORIGINALLY operated? In the UK, it was receiver-pays until about 1840. Of course, that doesn't mean that the system wasn't terrible and unfair.
As someone who's been doing Android app development the last few years, this was the approach that we decided upon for a new thin-client application. An HTML5 based app seems like a good choice when the app is mostly consuming multimedia content, but if you need rich interactivity, a native Java application definitely seemed the better fit.
Re the 2nd:
You realize the speed of sound in water is more than 4x of that in air, right? We can barely build a craft that can go that speed in the air, let alone water.
Even assuming that bulk transmutation of elements is a "trivial breakthrough", Osmium is actually much less abundant than gold (citation). You're right that the value is what the market says it is, but wrong in thinking that being able to turn one into the other would cause the price of gold to plummet. Osmium is simply not as _useful_ of an element compared to gold, regardless of its rarity.
Well, technically, since this not a criminal case, nobody has to 'prove' anything. One side just has to have a preponderance of evidence. So far, the analysis of the code shows that only a fraction of a percentage of it is close enough to Sun/Oracle's to warrant looking more closely at it.
And while it offers no direct evidence one way or another, Google's intention from the beginning was to have the source code to Android published and would expect many, many eyeballs on their source code. If nothing else, it's inconceivable to me that the strategy at Google was, "let's clean-room implement 99.5% of this code, but then directly copy this other 0.5% of the code in order to save us time and money." A single engineer being lazy, on the other hand? I could buy that, maybe.
Clean-room reimplementation is not a new or obscure activity in software. It's been done for many decades and the legal hoops to jump through to perform it are well known. Standard practice is to have anyone who contributes as much as a line of code to sign an affidavit stating that they had never so much as glanced at the source code to what is being reimplemented. I suspect that Google has quite a lot of evidence that the clean room implementation was done according to legal standards. The truth is, though, a lot of APIs behave in ways that provide very few reasonable code structures to accomplish its implementation and therefore it is to be expected that even a clean-room implementation will have more than a passing resemblance to the original.
Google (Schmidt, personally) has testified in court that Google did a clean-room implementation of Java. So far, Oracle's argument that Google did not do a clean-room implementation amounts to, "Uh uh! No they didn't!". Also, to nitpik, you can't "lift code" from an API.
This whole thing seems rather silly. First of all, yes, clearly Google copied the Java API. How can they even begin to deny that? Secondly, there is a crapload of legal precedence that indicates that an API is not legally protected by copyright.
Well, if it's 'hard' Real Time, It means that the kernel is designed to give certain guarantees for responsiveness. An example could be that a process that requests it can be certain that it gets a timeslice every certain number of milliseconds either most of the time (for a 'soft' RTOS) or completely deterministically (for a 'hard' RTOS).
As a (former) Blackberry developer, I've decided that I will be doing no more development for their platforms. They pissed away any goodwill I had for them by their crappy tools, crappy support and their ridiculous policies. As an example, in order to become a development partner, which is the ONLY way to get real support from them, you have to sign a license that basically gives RIM rights to use any of your source code that you develop for their platform. Or typically, if you tried to discuss a problem on their support forums, they would allow developers to spend weeks or months trying to figure out a problem before stepping in and say, "Oh, ya, we know about this. It's on our internal bug tracking system," and then close the discussion to new posts. This was often for bugs that had been around for several major API versions, or even from the very FIRST API version.
Fighting through the mess seemed like it was worth it when it seemed like everybody in the market for the software I was developing had a Blackberry, but now that it's dropped down to almost zero, you want me to invest my time and money into a brand new platform? No, thanks. At this point, I'm content to see you slip beneath the waves and to try to forget you exist. Goodbye.
Do you forget that DVD also has DRM? It's functionally equivalent to the one for Blue-Ray: it took a while to crack, and now is essentially completely toothless.
I think GWT is actually a reasonable tool for writing code that compiles to Javascript. This makes a lot of sense if you're writing your server code in Java, since your server and client code can all live within the same source tree and be edited with the same IDE in the same language. Significantly, this also allows you to debug your code using your Java debugger (read up on 'hosted mode' if you want to understand that witchcraft) while it's running in your browser. GWT also de-fangs the javascript event model that often leads to memory leaks. It might be of benefit to some people that by default (you can turn it off) the emitted JS code is heavily obfuscated. GWT is mature and well-supported, and integrates simply with vanilla JS code if you wish to. Available for GWT is GWTQuery, which is (you've probably guessed) a jQuery clone for GWT, including events, effects, etc...
Sorry, this is incorrect, knowing from personal experience. The vast majority of the time, breaking the glass (and digitizer) does not break the LCD. The LCD is right underneath the class, but most of the time that the glass breaks, the LCD does not. The two are adhered around the edges, but not on the actual surfaces.
While I see your point, if you have a truly random entropy source, ANY xored combination of cleartext and cyphertext could (incorrectly) appear to form any arbitrary message in the encrypted message.
grep "attack at dawn"/dev/random (and wait a while. Probably a LONG while.)
Err, what? All of these devices include an integrated battery and are simply mechanically attached to your car, usually by magnets. They're not wired into your car's electrical system.
According to the story, the devices that they researched send their data to the observers once an hour. At any other time, the device would effectively be completely passive. If you had a way of detecting cel-phone usage and were patient enough, presumably you would be able to detect it during this transmission period.
An Android developer here: This limitation just means that there can only be a single icon on the launcher screen that starts the app. On a real Android device, the same 'application' can have multiple icons, each of which opens a different starting screen. Not really that big of a deal except for special-purpose apps. I suspect that the Playbook's launcher shell simply doesn't support the concept of multiple entry-points for an application, so they introduced this limitation to make supporting things easier. Honestly, if they can actually make useful Android support work, I'll be VERY surprised. But it also means that I can stop doing any real work on native BB support for our apps. What a nightmare it's been!
Slashdot Mirror
Someone clarify for me - if a game doesn't have DRM, does that mean you can copy the folder to another HD, and the game will still work?
Yes, or at least the installer can be copied and used without restrictions.
Is password protection a weak form of DRM, or not DRM at all?
Passwords are not DRM.
I'm sure that will go over really well: Punish people HARDER for picking on someone who's already advantaged compared to the perpetrator, as opposed to picking on someone who's disadvantaged. How about additional punishments for picking on the rich. Or those good at sports. Sorry, but we aren't QUITE yet living in the world of Idiocracy, so no, being smart doesn't make you a vulnerable class.
Good point.
You mean, exactly how many postal services ORIGINALLY operated? In the UK, it was receiver-pays until about 1840. Of course, that doesn't mean that the system wasn't terrible and unfair.
As someone who's been doing Android app development the last few years, this was the approach that we decided upon for a new thin-client application. An HTML5 based app seems like a good choice when the app is mostly consuming multimedia content, but if you need rich interactivity, a native Java application definitely seemed the better fit.
Re the 2nd: You realize the speed of sound in water is more than 4x of that in air, right? We can barely build a craft that can go that speed in the air, let alone water.
If you watch the video, you'll see the answers to each of these questions in detail.
Even assuming that bulk transmutation of elements is a "trivial breakthrough", Osmium is actually much less abundant than gold (citation). You're right that the value is what the market says it is, but wrong in thinking that being able to turn one into the other would cause the price of gold to plummet. Osmium is simply not as _useful_ of an element compared to gold, regardless of its rarity.
Well, technically, since this not a criminal case, nobody has to 'prove' anything. One side just has to have a preponderance of evidence. So far, the analysis of the code shows that only a fraction of a percentage of it is close enough to Sun/Oracle's to warrant looking more closely at it.
And while it offers no direct evidence one way or another, Google's intention from the beginning was to have the source code to Android published and would expect many, many eyeballs on their source code. If nothing else, it's inconceivable to me that the strategy at Google was, "let's clean-room implement 99.5% of this code, but then directly copy this other 0.5% of the code in order to save us time and money." A single engineer being lazy, on the other hand? I could buy that, maybe.
Clean-room reimplementation is not a new or obscure activity in software. It's been done for many decades and the legal hoops to jump through to perform it are well known. Standard practice is to have anyone who contributes as much as a line of code to sign an affidavit stating that they had never so much as glanced at the source code to what is being reimplemented. I suspect that Google has quite a lot of evidence that the clean room implementation was done according to legal standards. The truth is, though, a lot of APIs behave in ways that provide very few reasonable code structures to accomplish its implementation and therefore it is to be expected that even a clean-room implementation will have more than a passing resemblance to the original.
Google (Schmidt, personally) has testified in court that Google did a clean-room implementation of Java.
So far, Oracle's argument that Google did not do a clean-room implementation amounts to, "Uh uh! No they didn't!". Also, to nitpik, you can't "lift code" from an API.
This whole thing seems rather silly. First of all, yes, clearly Google copied the Java API. How can they even begin to deny that? Secondly, there is a crapload of legal precedence that indicates that an API is not legally protected by copyright.
What am I missing here??
Well, if it's 'hard' Real Time, It means that the kernel is designed to give certain guarantees for responsiveness. An example could be that a process that requests it can be certain that it gets a timeslice every certain number of milliseconds either most of the time (for a 'soft' RTOS) or completely deterministically (for a 'hard' RTOS).
As a (former) Blackberry developer, I've decided that I will be doing no more development for their platforms. They pissed away any goodwill I had for them by their crappy tools, crappy support and their ridiculous policies. As an example, in order to become a development partner, which is the ONLY way to get real support from them, you have to sign a license that basically gives RIM rights to use any of your source code that you develop for their platform. Or typically, if you tried to discuss a problem on their support forums, they would allow developers to spend weeks or months trying to figure out a problem before stepping in and say, "Oh, ya, we know about this. It's on our internal bug tracking system," and then close the discussion to new posts. This was often for bugs that had been around for several major API versions, or even from the very FIRST API version.
Fighting through the mess seemed like it was worth it when it seemed like everybody in the market for the software I was developing had a Blackberry, but now that it's dropped down to almost zero, you want me to invest my time and money into a brand new platform? No, thanks. At this point, I'm content to see you slip beneath the waves and to try to forget you exist. Goodbye.
Do you forget that DVD also has DRM? It's functionally equivalent to the one for Blue-Ray: it took a while to crack, and now is essentially completely toothless.
You should probably have checked that before posting... Are you confusing LCD with LED?
I think GWT is actually a reasonable tool for writing code that compiles to Javascript. This makes a lot of sense if you're writing your server code in Java, since your server and client code can all live within the same source tree and be edited with the same IDE in the same language. Significantly, this also allows you to debug your code using your Java debugger (read up on 'hosted mode' if you want to understand that witchcraft) while it's running in your browser. GWT also de-fangs the javascript event model that often leads to memory leaks. It might be of benefit to some people that by default (you can turn it off) the emitted JS code is heavily obfuscated. GWT is mature and well-supported, and integrates simply with vanilla JS code if you wish to.
Available for GWT is GWTQuery, which is (you've probably guessed) a jQuery clone for GWT, including events, effects, etc...
EBay for $15, just the glass and digitizer, no LCD.
Sorry, this is incorrect, knowing from personal experience. The vast majority of the time, breaking the glass (and digitizer) does not break the LCD. The LCD is right underneath the class, but most of the time that the glass breaks, the LCD does not. The two are adhered around the edges, but not on the actual surfaces.
While I see your point, if you have a truly random entropy source, ANY xored combination of cleartext and cyphertext could (incorrectly) appear to form any arbitrary message in the encrypted message.
grep "attack at dawn" /dev/random (and wait a while. Probably a LONG while.)
Curious, what does the sensor bar have to do with the form factor of the Wii?
Err, what? All of these devices include an integrated battery and are simply mechanically attached to your car, usually by magnets. They're not wired into your car's electrical system.
According to the story, the devices that they researched send their data to the observers once an hour. At any other time, the device would effectively be completely passive. If you had a way of detecting cel-phone usage and were patient enough, presumably you would be able to detect it during this transmission period.
You think that sea salt isn't (almost) entirely made up of sodium chloride?
The USPS is not actually a government agency and its employees are not actually civil servants.
An Android developer here:
This limitation just means that there can only be a single icon on the launcher screen that starts the app. On a real Android device, the same 'application' can have multiple icons, each of which opens a different starting screen.
Not really that big of a deal except for special-purpose apps. I suspect that the Playbook's launcher shell simply doesn't support the concept of multiple entry-points for an application, so they introduced this limitation to make supporting things easier.
Honestly, if they can actually make useful Android support work, I'll be VERY surprised. But it also means that I can stop doing any real work on native BB support for our apps. What a nightmare it's been!