My rommate says his reports 4-4.5 hours available when it's charged. Whether it actually lives up to that while playing games or movies remains to be seen, as does the long-term performance (Li-ion batteries have a disheartening tendency to lose the top 20% of their capacity within about the first month)
Well, that's good. I hope you enjoy the benefit of lots of people buying stuff on your account, without experiencing the hassle of anyone making sure that they're you.
Most people I know think I'm psychic just because I know how to play minesweeper. They don't get that there's actually a logic to it, so they think I have really good luck.
Because the results are fundamentally different. RDP moves a completely different kind of data than VNC does (see the great-grandparent or so). DFimage is somewhat of a known quantity, because it interfaces with the open-source TightVNC code, That plus a little common sense tells you that the data that DFimage produces (screen bits) can't be converted into the data that RDP needs (drawing primitives) in a useful way.
and as a client program, it displays the result of those drawing commands; it does not produce them, and especially not on a windows machine. Please read more closely to avoid making entirely irrelevant comments.
Um... I'll hook you up with my pal Newton, who will tell you that if, as you say, "the drag doesn't change", then the opposing force you need to stay at velocity also stays exactly the same.
As for the first point, I can't say that that makes much sense either. On a lighter bike, the rider is going to make up a larger portion of the mass, and the center of gravity is going to be higher, right? So shouldn't your raised Cg make for a longer moment arm for the torque keeping you "leaned over" and therefore produce roughly the opposite effect?
The question is, how do you hook into the UI at a low enough level to capture those drawing commands and send them over the network? The answer is, you don't -- unless you're Microsoft.
As for what you say about Knoppix: most modern distributions are like Knoppix in those good ways, except more mature, less flaky, and more standardized (try to figure out why the things in the KNOPPIX subsection of the KDE menu are there, huh?). Something like Ubuntu is essentially zero-conf for all manner of useful tasks, which cover pretty much everything that "average" Aunt Tilly windows users do.
Large enterprises shouldn't use Windows, because it isn't secure enough, has scalability problems, and is only available in one flavor, according to slashdot user arodland, which includes such IT heavyweights as me.
Almost true... a.nrg is either an ISO with a 300kB header, or it's some other stuff with a 300kB header, in which case you can't convert it to an ISO. If you understood the format of the header, you could convert most Nero images to bin/cue or cdrdao TOC format, but as far as I've seen, progress on figuring it out has been limited. On the other hand, your script is quite useful for when you have a Nero image and you know (or hope) that it contains a single Mode 1 Data track. I'd just recommend adding a little bit of extra detection logic so that it can bail informatively when the result isn't an ISO, instead of wasting the time and space to do a useless conversion:)
Actually, control is the one that does something different in every program; for the most part, any similarities in control sequences between different programs is the product of either luck or dedicated developers. The Windows key, on the other hand, doesn't do much of anything in any program; win-key combinations are almost always caught by Explorer and used to trigger such actions as "Run", "Minimize All", and "Log Out". Yay! Well, actually, it's moderately handy.
Both of those thoughts really point in the same direction. Your latter point isn't so much about things that "can't" go wrong, as things that the engineers didn't forsee going wrong. So both of them teach the same lesson: don't assume that it just can't happen. Don't make the connector that can plug in the wrong way; don't write the software that can't handle the full range of error conditions.
You do know that Simon signs all of the PuTTY binaries with a couple PGP keys, right? If you can make the initial verification, that should be even easier to trust than SSL:)
... except that libdvdcss has nothing at all to do with burning, only with ripping protected movies. Once you get to the burning stage, you're dealing with unencrypted data. As far as I can tell, Nero never touches CSS; Ahead's Recode product says it only works on "non-protected DVDs". So, I'm not sure what that has to do with anything, but I can't agree with your conclusion. mkisofs + cdrecord and a good front end are just as capable when dealing with Video DVD as they are with anything else. Which is, in my estimation, reasonably good and constantly getting better.
The way the IRC protocol is specified, there can't be any cycles in the connection graph; that means that there's only one valid path from any point A to any point B; if one of those servers goes down, then everyone at A splits from everyone at B.
A "mesh" network is fundamentally different. There are (hopefully) multiple possible routes between any A and B, and packets choose the best one. And because the whole thing is packet-switched, if a link goes down, then you just start sending through the next available link. As long as you don't get into a situation where the only node connecting two subgraphs goes down, there aren't exactly any "splitting" problems.
No, because the stuff that airplanes fly in (the atmosphere) also rotates with the earth. If it didn't, there would be easterly winds everywhere, ranging from zero at the poles, to over 1600km/h at the equator. But since it ain't so, you can compute the whole thing with reference to the earth, and rotation doesn't matter.
Now we'll get to see even more programs with Adobe's GUIs that ignore all of the settings and standards of the platform they're running on, not to mention reasonable design principles. I'm looking forward to that:)
Slashdot Mirror
You, sir, are a fuckwad.
He is. And I think that's his sofa.
My rommate says his reports 4-4.5 hours available when it's charged. Whether it actually lives up to that while playing games or movies remains to be seen, as does the long-term performance (Li-ion batteries have a disheartening tendency to lose the top 20% of their capacity within about the first month)
Well, that's good. I hope you enjoy the benefit of lots of people buying stuff on your account, without experiencing the hassle of anyone making sure that they're you.
Most people I know think I'm psychic just because I know how to play minesweeper. They don't get that there's actually a logic to it, so they think I have really good luck.
Has Western Union never heard of calling the number back?
Because the results are fundamentally different. RDP moves a completely different kind of data than VNC does (see the great-grandparent or so). DFimage is somewhat of a known quantity, because it interfaces with the open-source TightVNC code, That plus a little common sense tells you that the data that DFimage produces (screen bits) can't be converted into the data that RDP needs (drawing primitives) in a useful way.
YAML!
A little fodder for the lameness filter
and as a client program, it displays the result of those drawing commands; it does not produce them, and especially not on a windows machine. Please read more closely to avoid making entirely irrelevant comments.
If you mean DFMirage, you're wrong. It's nifty, and it makes TightVNC faster, and it's absolutely nothing like what I was talking about :)
Um... I'll hook you up with my pal Newton, who will tell you that if, as you say, "the drag doesn't change", then the opposing force you need to stay at velocity also stays exactly the same.
As for the first point, I can't say that that makes much sense either. On a lighter bike, the rider is going to make up a larger portion of the mass, and the center of gravity is going to be higher, right? So shouldn't your raised Cg make for a longer moment arm for the torque keeping you "leaned over" and therefore produce roughly the opposite effect?
The question is, how do you hook into the UI at a low enough level to capture those drawing commands and send them over the network? The answer is, you don't -- unless you're Microsoft.
1963? Yeah, that sounds about right.
As for what you say about Knoppix: most modern distributions are like Knoppix in those good ways, except more mature, less flaky, and more standardized (try to figure out why the things in the KNOPPIX subsection of the KDE menu are there, huh?). Something like Ubuntu is essentially zero-conf for all manner of useful tasks, which cover pretty much everything that "average" Aunt Tilly windows users do.
Large enterprises shouldn't use Windows, because it isn't secure enough, has scalability problems, and is only available in one flavor, according to slashdot user arodland, which includes such IT heavyweights as me.
Almost true... a .nrg is either an ISO with a 300kB header, or it's some other stuff with a 300kB header, in which case you can't convert it to an ISO. If you understood the format of the header, you could convert most Nero images to bin/cue or cdrdao TOC format, but as far as I've seen, progress on figuring it out has been limited. On the other hand, your script is quite useful for when you have a Nero image and you know (or hope) that it contains a single Mode 1 Data track. I'd just recommend adding a little bit of extra detection logic so that it can bail informatively when the result isn't an ISO, instead of wasting the time and space to do a useless conversion :)
Actually, control is the one that does something different in every program; for the most part, any similarities in control sequences between different programs is the product of either luck or dedicated developers. The Windows key, on the other hand, doesn't do much of anything in any program; win-key combinations are almost always caught by Explorer and used to trigger such actions as "Run", "Minimize All", and "Log Out". Yay! Well, actually, it's moderately handy.
Both of those thoughts really point in the same direction. Your latter point isn't so much about things that "can't" go wrong, as things that the engineers didn't forsee going wrong. So both of them teach the same lesson: don't assume that it just can't happen. Don't make the connector that can plug in the wrong way; don't write the software that can't handle the full range of error conditions.
You do know that Simon signs all of the PuTTY binaries with a couple PGP keys, right? If you can make the initial verification, that should be even easier to trust than SSL :)
... except that libdvdcss has nothing at all to do with burning, only with ripping protected movies. Once you get to the burning stage, you're dealing with unencrypted data. As far as I can tell, Nero never touches CSS; Ahead's Recode product says it only works on "non-protected DVDs". So, I'm not sure what that has to do with anything, but I can't agree with your conclusion. mkisofs + cdrecord and a good front end are just as capable when dealing with Video DVD as they are with anything else. Which is, in my estimation, reasonably good and constantly getting better.
To expand on mark-t's rather sparse comment:
The way the IRC protocol is specified, there can't be any cycles in the connection graph; that means that there's only one valid path from any point A to any point B; if one of those servers goes down, then everyone at A splits from everyone at B.
A "mesh" network is fundamentally different. There are (hopefully) multiple possible routes between any A and B, and packets choose the best one. And because the whole thing is packet-switched, if a link goes down, then you just start sending through the next available link. As long as you don't get into a situation where the only node connecting two subgraphs goes down, there aren't exactly any "splitting" problems.
No, because the stuff that airplanes fly in (the atmosphere) also rotates with the earth. If it didn't, there would be easterly winds everywhere, ranging from zero at the poles, to over 1600km/h at the equator. But since it ain't so, you can compute the whole thing with reference to the earth, and rotation doesn't matter.
Err, you mean "double jeopardy."
Now we'll get to see even more programs with Adobe's GUIs that ignore all of the settings and standards of the platform they're running on, not to mention reasonable design principles. I'm looking forward to that :)