Comment Re:They all suck badly (Score 1) 198
I know nothing of the USA's mobile carrier market, aside from what I read on Slashdot. But $50/month seems like highway robbery.
I know nothing of the USA's mobile carrier market, aside from what I read on Slashdot. But $50/month seems like highway robbery.
methodical vacuumer: http://www.youtube.com/watch?feature=player_detailpage&v=y021R6c4uPE#t=51s
What part?
...the opportunity cost of having just 2-4 10-minute periods of that same employees' productivity get incinerated every day.
I wish it was just 2-4 10-minute periods. I have no hard data to back me up, but with my current work-machine it certainly feels like I spend between 60 minutes to 120 minutes each day simply waiting for the computer to respond. Common tasks that my home-machine completes in under a second easily take anywhere between 20-30 seconds on my work-machine.
Cheeky, but clever.
School should never devolve into "keeping the children busy during the day". If it does, then yes, either overhaul the curriculum or close the damn schools.
Bull, I find bugs all the time *because* dd/mm/yyyy in applications is often stored/operated on with millisecond/second precision.
Let's see:
a) the case of the missing midnight: some date or another in the 1920's IIRC that doesn't have a 00:00:00 hour but that day starts at 02:00:00 hour (so, two missing hours). Unable to create or store that date with the time set at midnight.
b) range 01/01/2012 - 10/12/2012 entered by the user, inclusive. On 10/12/2012 00:00:01 the system determines the current date is no longer in the range. Bug, certainly not what the user intended.
c) amount of days between 1/1/2012 CET and 1/6/2012 CEST. A naive way to calculate this is is to subtract the two dates (with millisec precision) and divide by 24 hours. That will give the wrong answer though.
Anyway, I've come to believe that in an application you store/use the date the user typed in, not a derivative with millisecond precision.
And, also agree with DragonWriter above.
Hmmm. Given a appointment on October 1st, 2014, 22:00. Appointment is in a country that has no summertime/wintertime difference. GMT/UTC offset is say +1:00.
On February 1st, 2013 the government decides that from September 2013, there will be a summertime/wintertime difference. Wintertime offset will be +2:00.
When stored in UTC, the appointment is now rendered with a local time of October 1st, 2014, 23:00. IMHO, the timezone, and the timezone offset are not just presentation issues; they are an implicit part of the data the user entered. Although I concede my example is a bit contrived.
One example for java (there are others): http://code.google.com/p/windowlicker/
The defectiveness of the Start Screen isn't a matter of it "being hard". For me, it disrupts the context information in my brain for the task I'm currently doing. It isn't hard, it's annoying. And, same as with Clippy of days past, it isn't hard to bypass, but it's annoying all the same. It hinders me, it disrupts me from getting things done. And that is all the reason I need to shun it.
Incidentally, I feel perfectly justified to complain often and loudly about the Start Screen, as this is my only small way of providing feedback to Microsoft. Feedback, that, accumulated with thousands of others, hopefully will result in a change to disable Metro.
free summer stays for its employees
Renumeration. Taxed as income.
It buys you a private jet
Renumeration. Taxed as income.
It also pays you in cash, but in some tax haven so you don't have to pay US income tax.
Renumeration. Taxed as income. If there is tax-treaty with that country, tax already payed in foreign country on that income is tax-deductable (or vice versa).
flat tax rate it wouldn't really help. The people with the most would still pay substantially less than the rate you set.
And while I'm at it, I'll suggest a _progressive_ tax rate.
Actually, a pair of boots stuffed with a few insoles sounds like a *perfect* place to keep a (fragile piece of art/ornate watch). Depending on the material of the boots, they could protect the watch from any mishandling of the luggage. Yes, he could have put the watch in a separate box, but that box would have taken up space on its own. This just sounds to me like efficient use of space.
Property rights? Over money stored at a bank? In a bank-account?
Sorry, you don't own that money. The only thing you have is credit. The bank promises to give you that amount of money when you ask for it. That's all.
So, well, the answer is; no.
And what exactly do you think a human crew will do with:
a) a weapon
b) a target
c) orders in hand to bomb said target
d) a communications outage?
It doesn't matter if it's a human crew or not, because that target will go BOOM in that scenario.
Hell, there could even be evolutionary advantages for some people to sleep longer/deeper than others. Some people being more awake/alert during the night; others better rested during the day. That could be advantageous in a hunter/gatherer civilization.
"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."
