We're not arguing about Amazon's default shipping period. If you remember, this whole thread is about whether Amazon's patent makes less-favored customers wait more than they would have without the new system. It doesn't matter whether Amazon has a lowest-common-denominator duration of 5 days, since this is the longest time you could expect to wait.
If a customer used to be served (on average) in 3 days and he now hits the 5-day limit because somebody jumped the queue (and gets served in one day) he gets a worse service however you want to spin it.
That's exactly what an 'order' implies as well. It's perfectly possible to dispatch multiple entities simultaneously from the head of a queue (I do it all the time in multi-threaded server applications).
But the fact is, unless Amazon are serving orders from the whole queue in parallel, if they're changing the order based on customer profiles then favored customers will be served ahead of the less favored. That is sure to mean that some customers receive their orders later than they would in a 'first come, first served' system.
I've read it. Apart from the fact that it's just written in a obfuscated way (does each claim have to be a single paragraph?), claim 3 basically says that they'll prioritize shipments based on the customer's expected future orders. I.e. they'll slow orders to customers who are not predicted to order in the future.
Exactly. They could have just implemented this like every other bean-counting company does. Instead, they've just handed an advertising slogan to their competitors:
HotJava is a lame prototype from 1996. A better comparison would be Eclipse 3.3 against Visual Studio 2005. I use both daily (yes, I program quite a lot of C++), Eclipse is far superior.
I doubt very much whether a Java web browser and runtime would fit in 6MB (the program itself almost certainly could). But one thing is for sure - it could certainly fit in the eventual memory usage of well-tabbed Firefox after one week.
Using C++ for a modern software engineering project where reliability and security is paramount is like building a large bridge out of cast iron. You can do it with a lot of care and expense, but the result is always going to be suspect.
It's trivial to record your keystrokes or even the whole screen if somebody else (like your IT dept...) has admin access to your machine. SSH (God bless it! What would I do without it?) won't help you there.
It is, but the X38 chipset is 'officially' 1333MHz max. It has to be overclocked to reach 1600MHz (apparently fairly easily but with boatloads of latency on the DDR3). Only with X48 will 1600MHz be supported.
The phone is probably the W580i and the gesture picks a random track rather than the next track. It's the only gesture the music player recognizes and does require a button to be held down - probably to screen out false positives. Also many music phones these days do have dedicated buttons for play control (none have a 'random track' button though afaik!)
Your point is well taken, a more sensitive version which could recognize multiple gestures without accidental false positives would be way cool. It's coming...
People were voluntarily using his computer as a tor exit node. He didn't open their doors, they opened his and dumped their data in. He can sniff whatever he likes on his own computer. No one is forced to use tor.
You didn't offend me. Sorry if I seemed a little brash, but I often come across developers who give me these sorts of problems. ('Make it right before you make it fast' is the message given here).
The point is, you've got to verify it somehow if you're going to delete it, when I said 'read it back' this means 'ensure it's the same as the source'. You may have a facility on the other side (depending on what sort of transfer this really is) to get a hash back, or you may even be happy with a size report (starts to get dodgy). For the 'write but no read' situation (is that WOM..?), I would still insist on some kind of verification otherwise I'd do a copy not a move.
You're not a programmer, are you? You'd have failed an interview with me, anyway. If you're gonna do something as drastic as deleting a source file, you'd better be sure the destination's there because you're gonna get bitten one day. Some would call it 'defensive programming' and it's the default for many developers.
BTW, how could a failed write (USB drive unplugged mid-move) be seen by the OS as "it doesn't seem like anything went wrong"?
1. Copy the source file to the destination 2. Read the destination file back to ensure it's identical to the source file 3. Delete the source file
Rocket science it ain't (probably been patented though...). At what point in this process would a power failure lose your data? If your OS programs a move in any other way, run away.
The counterweight is not magic, it just balances the weight of the elevator. Energy certainly is required to lift the car against gravity, although a lot of it could be reclaimed on the descent with regenerative braking.
Slashdot Mirror
We're not arguing about Amazon's default shipping period. If you remember, this whole thread is about whether Amazon's patent makes less-favored customers wait more than they would have without the new system. It doesn't matter whether Amazon has a lowest-common-denominator duration of 5 days, since this is the longest time you could expect to wait.
If a customer used to be served (on average) in 3 days and he now hits the 5-day limit because somebody jumped the queue (and gets served in one day) he gets a worse service however you want to spin it.
That's exactly what an 'order' implies as well. It's perfectly possible to dispatch multiple entities simultaneously from the head of a queue (I do it all the time in multi-threaded server applications).
But the fact is, unless Amazon are serving orders from the whole queue in parallel, if they're changing the order based on customer profiles then favored customers will be served ahead of the less favored. That is sure to mean that some customers receive their orders later than they would in a 'first come, first served' system.
If you have an 'order' in which you have prioritized customers, that's exactly the equivalent of being in 'a line'.
I've read it. Apart from the fact that it's just written in a obfuscated way (does each claim have to be a single paragraph?), claim 3 basically says that they'll prioritize shipments based on the customer's expected future orders. I.e. they'll slow orders to customers who are not predicted to order in the future.
Exactly. They could have just implemented this like every other bean-counting company does. Instead, they've just handed an advertising slogan to their competitors:
"Amazon: the company that patented bad service"
Too late. But "on a mobile phone" is still available.
The current shareholders obviously think differently, otherwise they would have sold their shares already.
And one that was even immortalized in song:
Rolling Stones Mobile Studio
HotJava is a lame prototype from 1996. A better comparison would be Eclipse 3.3 against Visual Studio 2005. I use both daily (yes, I program quite a lot of C++), Eclipse is far superior.
I doubt very much whether a Java web browser and runtime would fit in 6MB (the program itself almost certainly could). But one thing is for sure - it could certainly fit in the eventual memory usage of well-tabbed Firefox after one week.
By not building it with GCC in the first place?
Using C++ for a modern software engineering project where reliability and security is paramount is like building a large bridge out of cast iron. You can do it with a lot of care and expense, but the result is always going to be suspect.
It's trivial to record your keystrokes or even the whole screen if somebody else (like your IT dept...) has admin access to your machine. SSH (God bless it! What would I do without it?) won't help you there.
It is, but the X38 chipset is 'officially' 1333MHz max. It has to be overclocked to reach 1600MHz (apparently fairly easily but with boatloads of latency on the DDR3). Only with X48 will 1600MHz be supported.
The phone is probably the W580i and the gesture picks a random track rather than the next track. It's the only gesture the music player recognizes and does require a button to be held down - probably to screen out false positives. Also many music phones these days do have dedicated buttons for play control (none have a 'random track' button though afaik!)
Your point is well taken, a more sensitive version which could recognize multiple gestures without accidental false positives would be way cool. It's coming...
Wasn't Allard the mighty brain behind the all-conquering Zune? I mean, you see them everywhere...
--
In Soviet Russia cowboys slow down you!
Why not just use the button to skip to the next song?
People were voluntarily using his computer as a tor exit node. He didn't open their doors, they opened his and dumped their data in. He can sniff whatever he likes on his own computer. No one is forced to use tor.
You didn't offend me. Sorry if I seemed a little brash, but I often come across developers who give me these sorts of problems. ('Make it right before you make it fast' is the message given here).
The point is, you've got to verify it somehow if you're going to delete it, when I said 'read it back' this means 'ensure it's the same as the source'. You may have a facility on the other side (depending on what sort of transfer this really is) to get a hash back, or you may even be happy with a size report (starts to get dodgy). For the 'write but no read' situation (is that WOM..?), I would still insist on some kind of verification otherwise I'd do a copy not a move.
You're not a programmer, are you? You'd have failed an interview with me, anyway. If you're gonna do something as drastic as deleting a source file, you'd better be sure the destination's there because you're gonna get bitten one day. Some would call it 'defensive programming' and it's the default for many developers.
BTW, how could a failed write (USB drive unplugged mid-move) be seen by the OS as "it doesn't seem like anything went wrong"?
A move is programmed as:
1. Copy the source file to the destination
2. Read the destination file back to ensure it's identical to the source file
3. Delete the source file
Rocket science it ain't (probably been patented though...). At what point in this process would a power failure lose your data? If your OS programs a move in any other way, run away.
http://en.wikipedia.org/wiki/Counterweight
But the process doesn't need to be patented. IBM could just offer the service as a business anyway.
Surely that should be "shutdown -h" if you're looking to save some leccy. (Can't say I do that very often!)
That's fine, leave the WTO then. But while you're in it, take some responsibility for the things you've signed-up for.
Python should reinvent itself to be the multi-processing language
Why bother when Java has done that successfully for years? (And with performance on a par with your unoptimized C).
Or even
http://en.wikipedia.org/wiki/Doomsday_argument