I was especially interested in using it as an ebook reader when I first got it. It retailed for about $600 at the time, but the specs look more like the current crop of $200-$300 PDAs, so you can probably find one for less than that on EBay...
Anyway, it's not great as a text reader platform. The screen is high enough res to render text in a crisp -- but not jagged -- and nicely readable format. It's Pocket PC (2002), and runs both MS Reader and Pocket Acrobat Reader well enough. There are various utilities for browsing text files. It has a built-in Li-ion battery and USB connection.
So what's the problem? It's just not as nice as a book. I keep a few books on it just in case, but rarely use it as an e-reader nowadays. The screen is too small, and you're forever flipping to the next page. And if you need to skip forward or back to check something, you're often skipping a lot of pages. It's also not easy to find a comfortable reading position, and it's no use in bed.
All not necessarily relevant to your needs, but from experience...
But hang on, 1989 was two years after Nasa launched the last of its deep space probes. And you'd think even after the embarrassing apparent loss of Captain Buck Rogers (who's actually going to be floating out there another 485 years or so, frozen) that they'd be able to work out the bugs and get to Mars no trouble at all...
And they need to do it without tipping that person off. A problem with suicide bombers is that rumbling them away from the intended target can just cause them to improvise. Security checkpoints are nice and busy, and so are buses and shopping streets. It doesn't tip the balance if someone just blows himself up somewhere else that's still packed with people.
It doesn't matter too much -- and this isn't a flame -- but the Hurricane was a prop aircraft, not a jet. Looks superficially like a Spitfire (the other backbone fighter of the RAF at the time), but a Spitfire has a bulbous cockpit, the Hurricane's is straight. All about it here.
"...since I would hope you wouldn't need much of a bang to move in the Martian gravity."
That only counts if you're going up, i.e. pulling against the gravity of the planet. The mass of everything involved is still the same, and that governs the amount of force you need to move against inertia.
So if you need to push the rover around, you'll need similar-sized forces (i.e. engines) that you'd need on Earth*.
(*) For the pedants: OK, the atmosphere is thinner, and the lack of gravity would reduce friction yadda yadda...
You might not have heard of them, but lots of people have. Lots of people who might not be avid Slashdot readers or care much about the issues usually discussed here. And they're artists who -- until now -- haven't generally been available on other download services. For those of thus who like the stuff Warp puts out, this is a good thing.
It's not that tricky to get them running SFU and Cygwin installed together. Obviously you can't expect them to do everything simulataneously (who gets the X port?) but it's no problem to have them both on the same box.
They do a bunch of different bags, including commuter and courier bags with padded laptop sleeves. I got one after lots of friends steered me in that direction. Had it for a couple of years; it's bombproof. And also waterproof.
"...using Linux and KDE in some of the rendering."
Linux is a pretty popular platform in the industry. Maya seems to be a little slower on Linux than Windows (don't flame me: talk to Alias). And expect to find tens or hundreds of nodes of Linux-based renderfarm all over the place. All our shots for Matrix III were rendered on Athlons running RedHat.
Re:Behold the power of /.
on
Superball!
·
· Score: 1
Nah. It's not that hard to handle server-wise if you're just delivering a handful of media files, even big ones. We had a 512MB Netra X1 dish out about 50Mb/s of those for a couple of one time under the Slashdot effect (we'd put them on a spare box because we weren't too sure what'd happen.) Of course your network connection wants to be good, too...
"The Northbridge comes with passive cooling, however, the design is not the most effective for dissipating heat. We think a taller, more extruded heat sink like MSI's is more effective at wicking heat away from the chipset."
Let's keep it scientific: did you do any measurements, or just you just reckon you have a better eye for heat dissipation than the folk at Asus?
"Following up on what is an equivalent of a million years of computation..."
When the RIAA talks about the "equivalent number of CD burners", it's a meaningless inflation. Here's another example. It would have served better to mention the number of SETI@Home clients. A true and meaningful figure which would still have conveyed the scale and a sense of awe.
Swoop down and clobber spacecraft in lower orbits, smashing them into tiny pieces that could go one to clobber other spacecraft. Or perhaps larger pieces that re enter in fiery displays of wasted millions.
The "proof" is based on predictable repeating sequences of moves from the machines. Couldn't this be caused by the emulator environment causing (or using) identical seeding for random number generation?
Of course that doesn't answer the assertion that the outcome of any "gamble" is predetermined, and thus it isn't a gamble at all but "tell me your decision". But: there's no comparison with one (in fact, several) actual machines, so it's not clear this is the same real-world; if the machine randomly arrives at the win/lose decision, does it make it any less fair if it does so before you press the button?
OK, so this is pretty close to trolling, but will the wrap up of the story and finale be done well this time round?
In Snow Crash, The Diamond Age and Cryptonomicon there was a sense of something epic building all the way through that didn't really pay off. More of shame because he spins such an excellent yarn, and his writing is very engaging. But don't (please) pop the balloon just to bring the book to a conclusion.
Which is why I will never trust the Strategic Defence Initiative - the star wars project.
Or any software. You might want to consider the software all the weapons systems that actually exist first, or anything in a safety-related environment. Take a look at Risks Digest.
"...knowledge of the vulnerability, which makes no material difference..."
That's not the attitude of a good systems administrator. You're suggesting two things: that if no patch exists no exploit exists; that no countermeasures could be taken given knowledge of a vulnerability.
The first point is false logic: if you're aware of the vulnerability and that no patch exists, that's all you know. It's then prudent to assume that an exploit exists when considering what to do next. Head in the sand and all that.
Countermeasures can often be taken. If it's a service useful to administration but not vital to the business, perhaps it can be shut off until an alternative exists (OpenSSH, for instance). For any vulnerability, an alternative operating mode may be difficult but possible, and preferable to compromise or denial of service. If this isn't a "material difference" between knowledge an ignorance of vulnerability, I'd be fascinated to hear your definition of same.
And my original point: it's a good idea to consider what happens when a given system is compromised. Ever notice how (many) medieval castles (and I'm not talking about mainframes) have a moat, external walls with door and portcullis, and a keep in the center? You could retreat to the keep if the outer walls were breached. That didn't mean you expected the walls to breach.
Of course, but until those vulnerabilities have been documented, they might as well not exist.
With all due respect: bollocks. They may be known by any number of people before they are documented and patched (if they're ever patched). All that time, you're vulnerable.
You should never assume anything is 100% secure. For it to be so means it have a provably secure design and no flaws in the implementation. That's a desperately naive assumption.
Slashdot Mirror
I was especially interested in using it as an ebook reader when I first got it. It retailed for about $600 at the time, but the specs look more like the current crop of $200-$300 PDAs, so you can probably find one for less than that on EBay...
Anyway, it's not great as a text reader platform. The screen is high enough res to render text in a crisp -- but not jagged -- and nicely readable format. It's Pocket PC (2002), and runs both MS Reader and Pocket Acrobat Reader well enough. There are various utilities for browsing text files. It has a built-in Li-ion battery and USB connection.
So what's the problem? It's just not as nice as a book. I keep a few books on it just in case, but rarely use it as an e-reader nowadays. The screen is too small, and you're forever flipping to the next page. And if you need to skip forward or back to check something, you're often skipping a lot of pages. It's also not easy to find a comfortable reading position, and it's no use in bed.
All not necessarily relevant to your needs, but from experience...
But hang on, 1989 was two years after Nasa launched the last of its deep space probes. And you'd think even after the embarrassing apparent loss of Captain Buck Rogers (who's actually going to be floating out there another 485 years or so, frozen) that they'd be able to work out the bugs and get to Mars no trouble at all...
"Aggressor Squadron"
(Yes, yes, it's not for the same thing, I know. Go back to your 'Dew.)
And they need to do it without tipping that person off. A problem with suicide bombers is that rumbling them away from the intended target can just cause them to improvise. Security checkpoints are nice and busy, and so are buses and shopping streets. It doesn't tip the balance if someone just blows himself up somewhere else that's still packed with people.
It doesn't matter too much -- and this isn't a flame -- but the Hurricane was a prop aircraft, not a jet. Looks superficially like a Spitfire (the other backbone fighter of the RAF at the time), but a Spitfire has a bulbous cockpit, the Hurricane's is straight. All about it here.
That only counts if you're going up, i.e. pulling against the gravity of the planet. The mass of everything involved is still the same, and that governs the amount of force you need to move against inertia.
So if you need to push the rover around, you'll need similar-sized forces (i.e. engines) that you'd need on Earth*.
(*) For the pedants: OK, the atmosphere is thinner, and the lack of gravity would reduce friction yadda yadda...
You might not have heard of them, but lots of people have. Lots of people who might not be avid Slashdot readers or care much about the issues usually discussed here. And they're artists who -- until now -- haven't generally been available on other download services. For those of thus who like the stuff Warp puts out, this is a good thing.
It's not that tricky to get them running SFU and Cygwin installed together. Obviously you can't expect them to do everything simulataneously (who gets the X port?) but it's no problem to have them both on the same box.
San Francisco's finest: Timbuk2.
They do a bunch of different bags, including commuter and courier bags with padded laptop sleeves. I got one after lots of friends steered me in that direction. Had it for a couple of years; it's bombproof. And also waterproof.
Cannnot connect to DB server
Seems at Groklaw they know something about DOS after all.
The pompously smug and self-important among us preferred Ymodem-G when on an error-corrected link. And now we are relics.
Arse. Time to upgrade the servers.
I'm guessing you're thinking of ESC? This would not be they, though they're just down the road and I hear that they're still a Windows shop...
Linux is a pretty popular platform in the industry. Maya seems to be a little slower on Linux than Windows (don't flame me: talk to Alias). And expect to find tens or hundreds of nodes of Linux-based renderfarm all over the place. All our shots for Matrix III were rendered on Athlons running RedHat.
Nah. It's not that hard to handle server-wise if you're just delivering a handful of media files, even big ones. We had a 512MB Netra X1 dish out about 50Mb/s of those for a couple of one time under the Slashdot effect (we'd put them on a spare box because we weren't too sure what'd happen.) Of course your network connection wants to be good, too...
Let's keep it scientific: did you do any measurements, or just you just reckon you have a better eye for heat dissipation than the folk at Asus?
So you don't like Extreme Programming. That's not the same thing as "Extreme Programming doesn't work" in general. You're generalizing excessively.
"Following up on what is an equivalent of a million years of computation..."
When the RIAA talks about the "equivalent number of CD burners", it's a meaningless inflation. Here's another example. It would have served better to mention the number of SETI@Home clients. A true and meaningful figure which would still have conveyed the scale and a sense of awe.
God, how pedantic and picky of me.
Error creating new session
Hell, that's what most geeks say when normal people ask them about their lifestyle.
Swoop down and clobber spacecraft in lower orbits, smashing them into tiny pieces that could go one to clobber other spacecraft. Or perhaps larger pieces that re enter in fiery displays of wasted millions.
Or it might work. That'd be something.
The "proof" is based on predictable repeating sequences of moves from the machines. Couldn't this be caused by the emulator environment causing (or using) identical seeding for random number generation?
Of course that doesn't answer the assertion that the outcome of any "gamble" is predetermined, and thus it isn't a gamble at all but "tell me your decision". But: there's no comparison with one (in fact, several) actual machines, so it's not clear this is the same real-world; if the machine randomly arrives at the win/lose decision, does it make it any less fair if it does so before you press the button?
In Snow Crash, The Diamond Age and Cryptonomicon there was a sense of something epic building all the way through that didn't really pay off. More of shame because he spins such an excellent yarn, and his writing is very engaging. But don't (please) pop the balloon just to bring the book to a conclusion.
Or any software. You might want to consider the software all the weapons systems that actually exist first, or anything in a safety-related environment. Take a look at Risks Digest.
"...knowledge of the vulnerability, which makes no material difference ..."
That's not the attitude of a good systems administrator. You're suggesting two things: that if no patch exists no exploit exists; that no countermeasures could be taken given knowledge of a vulnerability.
The first point is false logic: if you're aware of the vulnerability and that no patch exists, that's all you know. It's then prudent to assume that an exploit exists when considering what to do next. Head in the sand and all that.
Countermeasures can often be taken. If it's a service useful to administration but not vital to the business, perhaps it can be shut off until an alternative exists (OpenSSH, for instance). For any vulnerability, an alternative operating mode may be difficult but possible, and preferable to compromise or denial of service. If this isn't a "material difference" between knowledge an ignorance of vulnerability, I'd be fascinated to hear your definition of same.
And my original point: it's a good idea to consider what happens when a given system is compromised. Ever notice how (many) medieval castles (and I'm not talking about mainframes) have a moat, external walls with door and portcullis, and a keep in the center? You could retreat to the keep if the outer walls were breached. That didn't mean you expected the walls to breach.
Of course, but until those vulnerabilities have been documented, they might as well not exist.
With all due respect: bollocks. They may be known by any number of people before they are documented and patched (if they're ever patched). All that time, you're vulnerable.
You should never assume anything is 100% secure. For it to be so means it have a provably secure design and no flaws in the implementation. That's a desperately naive assumption.