A leap second is defined as, for example, Thu Dec 31 23:59:60 UTC 1998. It's fairly uncommon, but that's what makes dates so hard. They're complex, and don't work like you'd expect.
And the pre-1969 stuff isn't an epoch limitation, inherently. You could use negative Unix times, since they're signed. BUT. You can't, because a Unix time is defined as a UTC time. And UTC didn't use a SI second before 1972. And they had non-integer leap "second" style adjustments. So...what precise time does Unix time 20032 refer to? Well, you can probably figure out that specific one, but depending on where the adjustments were made...it can be ambiguous. All Unix time does is define that a day is exactly 86400 seconds long. Even if, in reality, the day isn't that long.
And a 1AD epoch is tough, too, because when is that? Extended continuous Gregorian calendar? Julian from some arbitrary-ish Julian end-epoch? Who knows.
Again, this is all edge case stuff that you don't USUALLY have to worry about. Until you do, and it (or some other date issue) breaks everyone's credit card.
Half right. Under POSIX, it is ambiguous, and could be either 915148800 or 915148801. There was a leap second. And POSIX specifies that a leap second has the same UNIX time as the second before it. Of course, there are plenty of Unix-like implementations that make it so that there were multiple 915148799s, instead. Take your pick, there's an ambiguous second in there somewhere, and you don't really know where it was.
Never mind times before 1970, or future times which are unpredictably ambiguous.
You don't know what x does. But you know what x= does. It sets x to the RHS value. If x is a field, all bets are off. x= can do anything, and it's not the same thing that y= does, even if x and y are (properties wrapping) the same datatype.
I agree that you don't write stuff like that if you're not an idiot. But sometimes you maintain code written by people who DO write code like that. And properties obscure that it's not just an assignment, it's a method call.
If you have a 4000 line file called program.cs, written 5 years ago by someone who was rightfully fired 3 years ago, it's a pain in the ass to check if something is a property or an actual member, and what that property may or may not do when assigned to.
By not implementing properties, and instead using getters and setters, you make it more obvious. It's a flag that says "Check this! It might be insane!"
That would be fine, if that was what was happening.
If you were changing the state of an integer with that = operator, it would be ok. But you're not, you're performing a separately defined action on that specific integer. Which may, or may not, merely change the state of the variable. And there's no blindingly obvious way to know if myObj.x is an int or a property that can be setted, or getted. (Somehow, set and gotten sounds wrong).
No. Google TELLS you that they do it. If they told you that they didn't, well, they still might. If you assume that Google has some intent to invade your specific privacy, then you must make the same assumption of ALL search engines.
I'm not saying that Google isn't violating your privacy. I'm saying that with ANY search engine, when you make a set of queries to that search engine, you're giving them the ability to "invade your privacy" for some reasonable definition of that phrase. And the only thing that distinguishes them is that one search engine might tell you they don't save the data. But you have no particular reason to believe that fact.
No, it's not. It's impossible for Google to offer the services they offer without compromising your privacy. ANY search engine will know what you search for on it. ANY email service will know what email you send through it. ANY map service will know where you are trying to drive to. ANY photo service will have your photos. ANY news service will know what news you are reading. ANY RSS reader will know what you have subscribed to.
There is no legitimate reason for a police officer to frisk you for no reason. There is no alternative for a search engine to not care what you're searching for.
No, but Albany is 1/2 hour west of the towns in Mass (New England) and Vermont (New England) that need to be revitalized. To think that this won't help is being stupid for the sake of pedantry.
"At the game developers conference, Sun is releasing a white paper on their new "Java Games Profile." Their ultimate goal? To have one CD you could pop into an Xbox, a PS2, a Windows machine, or a Linux machine, and play the same game on them all. If they get full support for it I can finally get rid of that windows gaming partition!"
I agree...that had to be like the most confusing game ever. It probably didn't help that I got like a 5th generation pirated version and had no manual, but many a night was spent using the elevators, beating those crazy zappy R2D2 like robots, stopping time, and wondering just what the hell I was supposed to do at that big tic tac toe board.
No...all numerals are lowercase. Uppercase 1 is !, and uppercase 2 is @...etc. The reason you rarely see uppercase numerals on computers is because of the binary issues. !))!)! is much harder to read than 100101.
Slashdot Mirror
His? Hers? Its. All pronouns skip the apostrophe.
A leap second is defined as, for example, Thu Dec 31 23:59:60 UTC 1998. It's fairly uncommon, but that's what makes dates so hard. They're complex, and don't work like you'd expect.
And the pre-1969 stuff isn't an epoch limitation, inherently. You could use negative Unix times, since they're signed. BUT. You can't, because a Unix time is defined as a UTC time. And UTC didn't use a SI second before 1972. And they had non-integer leap "second" style adjustments. So...what precise time does Unix time 20032 refer to? Well, you can probably figure out that specific one, but depending on where the adjustments were made...it can be ambiguous. All Unix time does is define that a day is exactly 86400 seconds long. Even if, in reality, the day isn't that long.
And a 1AD epoch is tough, too, because when is that? Extended continuous Gregorian calendar? Julian from some arbitrary-ish Julian end-epoch? Who knows.
Again, this is all edge case stuff that you don't USUALLY have to worry about. Until you do, and it (or some other date issue) breaks everyone's credit card.
Half right. Under POSIX, it is ambiguous, and could be either 915148800 or 915148801. There was a leap second. And POSIX specifies that a leap second has the same UNIX time as the second before it. Of course, there are plenty of Unix-like implementations that make it so that there were multiple 915148799s, instead. Take your pick, there's an ambiguous second in there somewhere, and you don't really know where it was.
Never mind times before 1970, or future times which are unpredictably ambiguous.
What time was it one second after 915148800? Unix time hardly solves all problems.
Well, not to speak for ginko or non-science, but it's not like eating weeds that grow in exotic jungles hasn't helped save a life or two.
You don't know what x does. But you know what x= does. It sets x to the RHS value. If x is a field, all bets are off. x= can do anything, and it's not the same thing that y= does, even if x and y are (properties wrapping) the same datatype.
I agree that you don't write stuff like that if you're not an idiot. But sometimes you maintain code written by people who DO write code like that. And properties obscure that it's not just an assignment, it's a method call.
If you have a 4000 line file called program.cs, written 5 years ago by someone who was rightfully fired 3 years ago, it's a pain in the ass to check if something is a property or an actual member, and what that property may or may not do when assigned to.
By not implementing properties, and instead using getters and setters, you make it more obvious. It's a flag that says "Check this! It might be insane!"
That would be fine, if that was what was happening.
If you were changing the state of an integer with that = operator, it would be ok. But you're not, you're performing a separately defined action on that specific integer. Which may, or may not, merely change the state of the variable. And there's no blindingly obvious way to know if myObj.x is an int or a property that can be setted, or getted. (Somehow, set and gotten sounds wrong).
Of course properties are a terrible idea. They allow operator overloading on the instance level. That's insane.
int x = object.x; //works //works //works //fails
assert(x == object.x);
int y = object.y;
assert(y == object.y);
object.x = x;
assert(x == object.x);
object.y = y;
assert(y == object.y);
That's stupid and confusing.
No. Google TELLS you that they do it. If they told you that they didn't, well, they still might. If you assume that Google has some intent to invade your specific privacy, then you must make the same assumption of ALL search engines.
I'm not saying that Google isn't violating your privacy. I'm saying that with ANY search engine, when you make a set of queries to that search engine, you're giving them the ability to "invade your privacy" for some reasonable definition of that phrase. And the only thing that distinguishes them is that one search engine might tell you they don't save the data. But you have no particular reason to believe that fact.
No, it's not. It's impossible for Google to offer the services they offer without compromising your privacy. ANY search engine will know what you search for on it. ANY email service will know what email you send through it. ANY map service will know where you are trying to drive to. ANY photo service will have your photos. ANY news service will know what news you are reading. ANY RSS reader will know what you have subscribed to.
There is no legitimate reason for a police officer to frisk you for no reason. There is no alternative for a search engine to not care what you're searching for.
Nautical Miles, as opposed to statute miles. Give or take 6k feet instead of 5280.
Actually, baseball was introduced to Japan LONG before WW2. It's been a national obsession since the 1860s or so.
Actually, MLB has seen a giant UPswing in attendance over the past 10 years. Good try, though.
Nah, they're pretty firmly in bed. Groove has gotten LOTS of MS money. But they're not actually MS...yet.
That said, Groove is a hell of a product, and, as someone who formerly worked there, I have to say, it's a great company.
Yeah, I caught that just after I submitted. I suppose it's a nit, but it is an awfully large nit.
Of course he has a business relationship with RedHat. He's licensed his software to them under the GPL to do with as they choose.
That said, I disagree with the notion that a user can sue a software author when all warranties have been disclaimed, but IANAL.
MSNBC didn't say that, if you read the article. In fact, MSNBC was relatively positive about Linux. You were trolled by Taco's headline.
No, but Albany is 1/2 hour west of the towns in Mass (New England) and Vermont (New England) that need to be revitalized. To think that this won't help is being stupid for the sake of pedantry.
"At the game developers conference, Sun is releasing a white paper on their new "Java Games Profile." Their ultimate goal? To have one CD you could pop into an Xbox, a PS2, a Windows machine, or a Linux machine, and play the same game on them all. If they get full support for it I can finally get rid of that windows gaming partition!"
Dude, read the article. That "typical image" WAS one of the images. It was the 3d image created, by putting the clouds back in.
I agree...that had to be like the most confusing game ever. It probably didn't help that I got like a 5th generation pirated version and had no manual, but many a night was spent using the elevators, beating those crazy zappy R2D2 like robots, stopping time, and wondering just what the hell I was supposed to do at that big tic tac toe board.
Unix for Dummies may be subpar, but DOS for Dummies is one of the all time best introductory computing books. Truly a publishing masterpiece.
No...all numerals are lowercase. Uppercase 1 is !, and uppercase 2 is @...etc. The reason you rarely see uppercase numerals on computers is because of the binary issues. !))!)! is much harder to read than 100101.
>>Instead, they become bolides - fireballs - as it sounds like this one did.
That's the second time in 2 days I've seen the word "bolides" used correctly on Slashdot. I don't think I've EVER seen it anywhere else.