Is there anything in the ToS that says 'Valve wouldn't do that'? I vaguely remember reading a couple of cases where they did exactly that (some system decided that they were cheating in one online game, Valve removed all of their access to all of their games, except ones that they had installed and allowed totally disconnected mode, but not allowing any redownloads / reinstalls). It's entirely possible that I imagined this, but if Valve had anything in their ToS that said they wouldn't then I'd expect to have heard from it.
It might not be a shill. I'd give it the benefit of the doubt and call it a troll, especially with a name like PrivateBill. And, judging by the number of replies, I'd go so far as to call it a successful troll...
So what you're saying is that you do need a PC for your Android phone, it's just one that someone else has the root password and physical access to, but you don't? Wow, that sounds... great.
You sound like a BeOS user. The reason that this kind of thing worked on BeOS was that the Tracker, unlike the Mac OS X Finder, was not a complete UI disaster.
I would also prefer to sync with my computer. My old phone would happily sync calendars and contacts over bluetooth with my computer. My new (Android) phone, however, requires third-party add-ons to do anything other than store all of your personal data on Google's servers. To me, it doesn't seem like a step in the right direction for the only way of synchronising data between two machines to be via a computer that you don't control.
It may start with a Slashdot post, but pretty soon there's a Facebook group, and then there's nothing you can do except issue a content-free pacifying press release.
I recently got to play with a new prototype credit card. It's pretty neat, there is a small LCD and a button built into the card, as well as a NFC transceiver. You put it near your phone or computer and it displays the transaction amount on the card's screen. You press the button and it authorises it, by sending a single-use token to the computer. If your computer is trojaned then it can only be used to steal amounts equal to those of purchases you make (but altering the payee ID, although the next version will probably also display the merchant name). If the remote end is compromised, the attacker gets nothing of value because the generated tokens are only enough to authorise a single transaction of a specified amount to a single recipient.
I had the idea for such a system a few years ago, and was very disappointed to discover that a lot of other people had the same idea. The cost of building the cards has recently dropped to the level where it's now feasible though, so they should start appearing in most of the world in the next couple of years, and in the USA some time around 2030.
There was a slashdot report recently about the average taking from a stolen card number in a recent breach being about $20. This probably makes sense. If you put three $7 transactions on a card over a six month period then most people will probably just ignore them and assume that they were things that they simply forgot about. Some people will complain, and the bank will just reverse the charge and make the merchant (you) eat the loss (not really a loss, because you didn't really provide a product in return). Get half a million people who don't dispute the charge and you've got an income of ten million dollars. Maybe spend one million setting up all of the fake companies to take payments and you walk away with $9m - enough to live quite comfortably for the rest of your life.
A similar approach works with mobile phone malware. Make a call to a premium-rate number for one minute and most people will either not look at their bill or assume that it was a number they dialled accidentally. If the cost is under a dollar, most people who do notice it will figure that it will cost them more to call their mobile phone company and dispute it than they'll get back.
No single customer loses much, but every time it happens the overall cost of using these systems goes up very slightly.
No it doesn't. NAT by default performs address translation. The stateful firewall drops incoming connections by default, NAT translates the permitted ones to a given address. There are consumer NAT boxes that include the concept of a 'default host' so any inbound traffic goes to that machine. There are others that include a firewall that drops inbound traffic.
The situation is more or less the same for IPv6. A firewall may default to not allowing any incoming connections, to only allowing incoming connections to a single machine, to only allowing incoming connections on a set of useful ports, or to allowing all incoming connections.
Why would they? If you are going to use Java you use Swing or AWT or SWT. Using Apple-specific bindings makes zero sense if you are going to use Java (kinda defeats the purpose of "write once, run anywhere" which actually does work if you know what you are doing).
And that's how you end up with crap applications. Good cross-platform applications are MVC with a different UI for each platform. Even the Swing documentation agrees with this, and recommends that you use a native look and feel. If you've got a Java application then you could add a Mac GUI that would use native widgets and behaviours everywhere (you could even get your Mac UI specialist to draw it in Interface Builder), but still reuse the same model code that you used on other platforms.
Two things: first, plenty of people still have devices with less than 32 MB of RAM and this was certainly the case when early devices are used
Irrelevant. No one has an iPhone with under 32MB of RAM. The existence of devices under 32MB has no baring on the
Secondly, Apple in its egocentricity decided to support neither
They also chose not to port Mono. Or any other VM environments. They let you run binaries (although they did restrict this in the developer license for a while), so as long as your language of choice can generate ARM assembly it will run. The egocentricity seems to be more on your part, deciding that Apple needs to pay to have the runtime for your favourite language ported to their platform.
Universal cross-platform was slowly becoming a reality but thanks to Apple (iOS) and Microsoft (XBox) they are trying to silo again. For *users* is a step backwards, not forwards
No, for users cross-platform applications that had a non-native look and feel were a step backwards. Java applications on OS X often can't even get text boxes right - the shortcut keys for navigating in a text field are different to every other application that the user uses on the platform - and things like menu layouts are also unconventional. How is that good for the user? Users benefit from good ports, not from half-arsed recompile-and-ship jobs. Or, in the case of Java, skipping even the recompile step.
ECT: the medical profession's version of 'have you tried turning it off and on again?' Actually, this approach works well with some heart conditions too (remove the load on the heart for 24 hours and let it recover).
They're not even good trolls. Dr Bob, at least, got a lot of responses from people who thought he was serious. These trolls are so obvious that after reading half of the first sentence you know that the post will contain nothing of value. The only thing I can think of is that they're intended to make mods waste their mod points so that ones hoarded by shilling companies will be more likely to affect the relevant posts.
Hmm, somehow I forgot about all of her later work. BBC BASIC was the first language I learned, and meant that I didn't understand why there was so much hatred devoted towards BASIC because she fixed pretty much all of the things that people criticised. She seems to still be doing interesting things at Broadcom now.
It is a real shame Apple hate Java with a passion. It makes sense since Java can and does run well everywhere it is permitted to - but Steve Jobs wanted to silo Apple, so he could make more money
Wow, someone doesn't remember history very well. NeXT rewrote some of their core products (e.g. WebObjects) in Java, replacing the Objective-C version. When OS X launched, Java was one of three first-class development environments (ObjC/Cocoa and C/Carbon being the other two), including a set of Cocoa bindings for better integration with the host environment. It had a few tricks that weren't present in other JVMs at the time, such as the ability to have only one copy of the standard classes in memory even if you had multiple Java applications running. This code was eventually contributed upstream by Apple and is now present in the official JRE.
The Cocoa/Java ('Mocha') bindings were eventually deprecated because no one was using them.
IIRC the earlier iPhones had JVMs in hardware
The original iPhone had an ARM11 core with Jazelle, but even that doesn't mean 'JVM in hardware' that they had to'spend development effort to block'. It means that it had hardware that executed a subset of Java bytecodes directly and trapped to a VM for the rest. To support it they would have had to:
Pay a license to ARM and Sun for every iPhone (the Jazelle stuff is disabled by default and must be licensed separately
Port the Jazelle VM to iOS.
They spent effort in not doing this in the same way that I spent effort in not porting Java to BeOS.
The later iPhones have a Cortex A8 processor. The Jazelle mode in all of these chips does not exist. If you try to enter Jazelle mode, you get an error and return to ARM or Thumb mode. Thumb-2EE mode is supported, but that's just a few small extensions to Thumb-2 mode to make it a slightly more useful target for JIT compilers for Java-like languages. If they had originally supported Java, then they would have needed to spend more time and money porting a different VM to iOS for the newer devices and a lot more time testing that the pure software VM worked the same way as the hardware one.
Oh, and on devices with more than about 32MB of RAM, the hotspot JIT actually runs faster than the Jazelle VM, so using Jazelle on the iPhone would have been entirely pointless.
This is how it works in the UK. You receive a formal notification of the fine, at which point you can either pay it or contest it. Before you decide, you can request all of the evidence against you, including any videos and photos. They may then choose to take you to court, or they may just let it slide.
If the code and documentation disagree, then they're both wrong
The documentation itself is probably not the important bit. The thing that a lot of programmers seem to do wrong is getting the correct ordering of the thinking and coding steps mixed up. Writing documentation first means that you have to do the thinking before the coding, and that eliminates a whole load of problems.
Wow, I've heard of not discriminating based on age, but the fourth guy from the left in that photo makes me think you're taking that ideal just a little too far...
There are a few citations, here's one from Time and another from NPR saying that about a third of women in the armed forces are raped during their time in the service. It's not really surprising when you consider that you take a group of men, teach them to dehumanise people and that force is a valid way of solving disagreements...
Slashdot Mirror
Is there anything in the ToS that says 'Valve wouldn't do that'? I vaguely remember reading a couple of cases where they did exactly that (some system decided that they were cheating in one online game, Valve removed all of their access to all of their games, except ones that they had installed and allowed totally disconnected mode, but not allowing any redownloads / reinstalls). It's entirely possible that I imagined this, but if Valve had anything in their ToS that said they wouldn't then I'd expect to have heard from it.
It might not be a shill. I'd give it the benefit of the doubt and call it a troll, especially with a name like PrivateBill. And, judging by the number of replies, I'd go so far as to call it a successful troll...
So what you're saying is that you do need a PC for your Android phone, it's just one that someone else has the root password and physical access to, but you don't? Wow, that sounds... great.
You sound like a BeOS user. The reason that this kind of thing worked on BeOS was that the Tracker, unlike the Mac OS X Finder, was not a complete UI disaster.
I would also prefer to sync with my computer. My old phone would happily sync calendars and contacts over bluetooth with my computer. My new (Android) phone, however, requires third-party add-ons to do anything other than store all of your personal data on Google's servers. To me, it doesn't seem like a step in the right direction for the only way of synchronising data between two machines to be via a computer that you don't control.
It may start with a Slashdot post, but pretty soon there's a Facebook group, and then there's nothing you can do except issue a content-free pacifying press release.
I recently got to play with a new prototype credit card. It's pretty neat, there is a small LCD and a button built into the card, as well as a NFC transceiver. You put it near your phone or computer and it displays the transaction amount on the card's screen. You press the button and it authorises it, by sending a single-use token to the computer. If your computer is trojaned then it can only be used to steal amounts equal to those of purchases you make (but altering the payee ID, although the next version will probably also display the merchant name). If the remote end is compromised, the attacker gets nothing of value because the generated tokens are only enough to authorise a single transaction of a specified amount to a single recipient.
I had the idea for such a system a few years ago, and was very disappointed to discover that a lot of other people had the same idea. The cost of building the cards has recently dropped to the level where it's now feasible though, so they should start appearing in most of the world in the next couple of years, and in the USA some time around 2030.
There was a slashdot report recently about the average taking from a stolen card number in a recent breach being about $20. This probably makes sense. If you put three $7 transactions on a card over a six month period then most people will probably just ignore them and assume that they were things that they simply forgot about. Some people will complain, and the bank will just reverse the charge and make the merchant (you) eat the loss (not really a loss, because you didn't really provide a product in return). Get half a million people who don't dispute the charge and you've got an income of ten million dollars. Maybe spend one million setting up all of the fake companies to take payments and you walk away with $9m - enough to live quite comfortably for the rest of your life.
A similar approach works with mobile phone malware. Make a call to a premium-rate number for one minute and most people will either not look at their bill or assume that it was a number they dialled accidentally. If the cost is under a dollar, most people who do notice it will figure that it will cost them more to call their mobile phone company and dispute it than they'll get back.
No single customer loses much, but every time it happens the overall cost of using these systems goes up very slightly.
One is the evil bit.
NAT by default drops all incoming connections
No it doesn't. NAT by default performs address translation. The stateful firewall drops incoming connections by default, NAT translates the permitted ones to a given address. There are consumer NAT boxes that include the concept of a 'default host' so any inbound traffic goes to that machine. There are others that include a firewall that drops inbound traffic.
The situation is more or less the same for IPv6. A firewall may default to not allowing any incoming connections, to only allowing incoming connections to a single machine, to only allowing incoming connections on a set of useful ports, or to allowing all incoming connections.
Wow. I'm sure I remember there being a company in Cupertino that was famous for its good UI design. I wonder what happened to it...
Why would they? If you are going to use Java you use Swing or AWT or SWT. Using Apple-specific bindings makes zero sense if you are going to use Java (kinda defeats the purpose of "write once, run anywhere" which actually does work if you know what you are doing).
And that's how you end up with crap applications. Good cross-platform applications are MVC with a different UI for each platform. Even the Swing documentation agrees with this, and recommends that you use a native look and feel. If you've got a Java application then you could add a Mac GUI that would use native widgets and behaviours everywhere (you could even get your Mac UI specialist to draw it in Interface Builder), but still reuse the same model code that you used on other platforms.
Two things: first, plenty of people still have devices with less than 32 MB of RAM and this was certainly the case when early devices are used
Irrelevant. No one has an iPhone with under 32MB of RAM. The existence of devices under 32MB has no baring on the
Secondly, Apple in its egocentricity decided to support neither
They also chose not to port Mono. Or any other VM environments. They let you run binaries (although they did restrict this in the developer license for a while), so as long as your language of choice can generate ARM assembly it will run. The egocentricity seems to be more on your part, deciding that Apple needs to pay to have the runtime for your favourite language ported to their platform.
Universal cross-platform was slowly becoming a reality but thanks to Apple (iOS) and Microsoft (XBox) they are trying to silo again. For *users* is a step backwards, not forwards
No, for users cross-platform applications that had a non-native look and feel were a step backwards. Java applications on OS X often can't even get text boxes right - the shortcut keys for navigating in a text field are different to every other application that the user uses on the platform - and things like menu layouts are also unconventional. How is that good for the user? Users benefit from good ports, not from half-arsed recompile-and-ship jobs. Or, in the case of Java, skipping even the recompile step.
mDNS is quite common on small LANs now. Each computer can advertise its own name, so there is no need for central configuration.
ECT: the medical profession's version of 'have you tried turning it off and on again?' Actually, this approach works well with some heart conditions too (remove the load on the heart for 24 hours and let it recover).
They're not even good trolls. Dr Bob, at least, got a lot of responses from people who thought he was serious. These trolls are so obvious that after reading half of the first sentence you know that the post will contain nothing of value. The only thing I can think of is that they're intended to make mods waste their mod points so that ones hoarded by shilling companies will be more likely to affect the relevant posts.
Hmm, somehow I forgot about all of her later work. BBC BASIC was the first language I learned, and meant that I didn't understand why there was so much hatred devoted towards BASIC because she fixed pretty much all of the things that people criticised. She seems to still be doing interesting things at Broadcom now.
It was yours...
It is a real shame Apple hate Java with a passion. It makes sense since Java can and does run well everywhere it is permitted to - but Steve Jobs wanted to silo Apple, so he could make more money
Wow, someone doesn't remember history very well. NeXT rewrote some of their core products (e.g. WebObjects) in Java, replacing the Objective-C version. When OS X launched, Java was one of three first-class development environments (ObjC/Cocoa and C/Carbon being the other two), including a set of Cocoa bindings for better integration with the host environment. It had a few tricks that weren't present in other JVMs at the time, such as the ability to have only one copy of the standard classes in memory even if you had multiple Java applications running. This code was eventually contributed upstream by Apple and is now present in the official JRE.
The Cocoa/Java ('Mocha') bindings were eventually deprecated because no one was using them.
IIRC the earlier iPhones had JVMs in hardware
The original iPhone had an ARM11 core with Jazelle, but even that doesn't mean 'JVM in hardware' that they had to'spend development effort to block'. It means that it had hardware that executed a subset of Java bytecodes directly and trapped to a VM for the rest. To support it they would have had to:
They spent effort in not doing this in the same way that I spent effort in not porting Java to BeOS.
The later iPhones have a Cortex A8 processor. The Jazelle mode in all of these chips does not exist. If you try to enter Jazelle mode, you get an error and return to ARM or Thumb mode. Thumb-2EE mode is supported, but that's just a few small extensions to Thumb-2 mode to make it a slightly more useful target for JIT compilers for Java-like languages. If they had originally supported Java, then they would have needed to spend more time and money porting a different VM to iOS for the newer devices and a lot more time testing that the pure software VM worked the same way as the hardware one.
Oh, and on devices with more than about 32MB of RAM, the hotspot JIT actually runs faster than the Jazelle VM, so using Jazelle on the iPhone would have been entirely pointless.
This is how it works in the UK. You receive a formal notification of the fine, at which point you can either pay it or contest it. Before you decide, you can request all of the evidence against you, including any videos and photos. They may then choose to take you to court, or they may just let it slide.
If the code and documentation disagree, then they're both wrong
The documentation itself is probably not the important bit. The thing that a lot of programmers seem to do wrong is getting the correct ordering of the thinking and coding steps mixed up. Writing documentation first means that you have to do the thinking before the coding, and that eliminates a whole load of problems.
So you're saying you want a phone with the security model that Symbian had for the last ten years? Everything old is new again...
Uh, you *do* know women are allowed on Slashdot, right?
No they aren't, neither are men, only androgynous text-base entities.
You're driven off by your inability to read to the end of a post?
Wow, I've heard of not discriminating based on age, but the fourth guy from the left in that photo makes me think you're taking that ideal just a little too far...
There are a few citations, here's one from Time and another from NPR saying that about a third of women in the armed forces are raped during their time in the service. It's not really surprising when you consider that you take a group of men, teach them to dehumanise people and that force is a valid way of solving disagreements...