Actually, water droplets are thicker than water. Go to a mattress store and ask about their mattress covers; buying a waterproof cover is pretty much mandatory for a foam mattress (think *sponge*), and the current level of technology stops water and allergens but not air.
Mattress sellers often have a demo device, basically a closed tube where one end is covered only by their fabric and the tube has a whole bunch of colored mouthwash in it. Air goes through it, but you can't shake the mouthwash out.
This would obviously ding fan efficiency, but fanless laptops already exist...
I would wonder about their claim of "Completely Waterproof"... does that mean I can drop it in the tub and scrub it clean? There has to be a limit somewhere...
Yes, I know.localdomain won't be available, but what about users and systems within local networks that tend to function on alternate (internal-only) and implied (non-canonicalized) domains?
Let's say I have a partitioned office network at the company Foo Powers. My workstation is khopesh.office.foopowers.com (which is NAT'ed). From another system within the office, I'd probably just run ssh khopesh to get there (which implies khopesh.office.foopowers.com). To log into the web server (which lives in the DMZ), I'd run ssh www.dmz and to get back to my system, ssh khopesh.office would do the trick.... Under an infinite number of TLDs, this isn't reliable.
There are cool SSH tricks you can do to traverse NATs; I have it rigged so that from home, I can run ssh khopesh.office and get in. This triggers an entry in my ~/.ssh/config that looks like this (the first entry fits the above example. the second entry allows me to define an arbitrary extension to trigger a proxy rule and then remove the extension inside the proxy):
While a real.office or.foo TLD wouldn't stop this from working, I'd prefer a lookup failure to a key mis-match when trying such a command from a machine lacking the above config.
Oops, there should be only one percent sign in the target="${file%.*}.tiff" line. This enables your use of "User Manual 3.7.pdf" -> "User Manual 3.7.tiff" instead of "User Manual 3.tiff" as the above AC posted (and I copied). Also, the second script should have quotes around the first argument to find, which should use @ instead of 1, which respects multiple arguments and the spaces within them while still defaulting to the current working directory when there are no arguments.
I've incorporated this into my psmerge replacement script psmerge2 which uses ghostscript to merge and convert documents that it can read. I often use it to convert single documents from one format to another, and now it can also convert PDFs (and PSs) to TIFF.
This code will not work on files with spaces in them, because the back-ticks will expand spaces without escapes while the shell globbing used in the original code will escape them. Since most PDF titles I've seen use spaces in their names, this is important. The rest of those modifications will help, though.
Were I coding this script, I'd write two (since xargs can't use a function). One for the inner loop, and one for the outer loop (or if only running it once, I'd do the outer loop on the command line.
$ cat pdf2tiff.sh
#!/bin/sh
# convert specified files from PDF to TIFF
for file in "$@"; do
target="${file%%.*}.tiff"
if [ -r "$file" ] && [ ! -s "$target" ]
then
echo "gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg4 -sOutputFile='$target' '$file'"
gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg3 -sOutputFile="$target" "$file" 2>/dev/null
else
echo "'$file' not readable or '$target' exists, skipping"
fi
done
$ cat pdf2tiff-recursive.sh
#!/bin/sh
# convert all PDFs to TIFF format within supplied directory tree (default: $PWD)
find ${1:-.} -name '*.pdf' -print0 |xargs -0./pdf2tiff.sh
Re:Google Andriod is about to be hit by a steamrol
on
Android Phones Delayed
·
· Score: 1
IMHO, if someone, anyone decided to actually put their effort into the browser like apple has, they would actually be able to compete against the iPhone. Like you said every single browser stinks on cell phones except safari. if I could get a phone similar to the iphone but with a real browser I'd go towards that instead of AT&T any day of the week.
You'll love the Qtopia phones once they start rolling out; Qtopia 4.4+ includes a very nice and cleaned version of webkit, so the built-in web browser will be virtually identical (in terms of HTML/JS/etc rendering). The big difference is that since webkit is an integral part of Qt, you'll see HTML-enrichened widgets and views all over the place rather than just the browser and a few custom applications. Using webkit in Qt apps is as trivial as using a text box.
Re:Google Andriod is about to be hit by a steamrol
on
Android Phones Delayed
·
· Score: 2, Insightful
The Greenphone was ditched in favor of better options. The current development platform of choice is the Neo1973, the same platform used by the OpenMoko folks. Nokia hasn't yet announced a new development platform (i.e. one that they actually make) for Qtopia Phone Edition.
As to portability, that's one of Qtopia's biggest merits. It was so extreme that before the Greenphone was nixed, people were finding better support on other platforms (since Trolltech had no idea of how to design cellphone hardware). The only reason they even made the Greenphone was to jump-start the Qtopia Phone development community and (probably) as the second big step to position themselves for a buyout by either Motorola or Nokia. (The first step was the IPO in Norway.)
Google Andriod is about to be hit by a steamroller
on
Android Phones Delayed
·
· Score: 4, Interesting
With Nokia's acquisition of Trolltech (makers of Qt and Qtopia), Google is set to butt heads against a VERY large competitor, who is all-in on re-entering the US cellular industry.
Nokia is roughly the same size as Google (bigger in some ways, smaller in others), but more importantly, it's got more at stake. Qt/Embedded (a.k.a. Qtopia) is a heavyweight competitor to Android which has had far more design time, with a much more solid basis (Qt and Qtopia are both many years old, though Trolltech only recently aimed at cellular technology, which should be quickly rectified by Nokia's massive development teams). Google's dot-com mentality allows them to toss megabucks at an idea, like throwing things against a wall to see what sticks. If Android doesn't stick, whatever; they can afford it. If Qtopia doesn't stick, Nokia is back the drawing board and fighting a losing battle against LG.
Google's only merit is that they've been working on Andriod for longer than Nokia has been working on Qtopia (Nokia only finalized the Trolltech purchase last week). Google's only chance is to bring Andriod to dominance before Nokia manages to release Qt-powered phones. While they appear well-poised for this, the setback of this and other delays hurt the Andriod line more than you might think at a quick glance.
The cellphone platforms of tomorrow will be Apple iPhone, Google Andriod, and Nokia Qtopia. The other players (Motorola, Erickson, LG) will be left in the dust (or they'll adopt one of the above platforms rather than squeezing as much as they can out of standard J2ME). We'll see where Palm fits in with their revamped platform; they could easily go either way.
Can Google really face Microsoft on one front (office apps) and Nokia in the other? What about its bread & butter of web searching (their original front against Yahoo)? What's next, a car to take on Ford and Toyota?:-p
To sum up this massive paper in a very small (and likely highly imprecise) nutshell, building models up from basic objects (the traditional method) is only one way to approach this. Using this method, you are correct; it's impossible to understand what a canyon is. Using the new global properties methods in this upcoming paper, you can gather basic elements that could easily help in assigning location properties, understanding that something pictured is a desert or forest, and theoretically using that data to help determine which desert or forest (this latter portion is beyond the scope of the paper, but great fodder for a future paper that builds upon these fundamentals).
While the method currently requires a high level of labeling in its images, it is hoped that this labeling becomes unnecessary on larger data sets.
The book How to Design Programs specializes in this topic. It is available for free online, it was written by a programming languages specialist at Northeastern University (a 30 minute T ride from Tufts) and published at MIT (a 15 minute T ride from Tufts).
Yes, it's very academic in nature -- it uses Scheme as its base language (well, a very simplified/gimped Scheme) under the premise that it's not your standard procedural language (so you won't fall into old habits) yet it is easy to pick up and learn the fundamentals of programming rather than the specifics of a useless language (e.g. whatever language-of-the-day is liked by industry).
I'm sure there are several research papers tied to the book, and I'm also sure that Matthias Felleisen (its author, trustee professor at Northeastern University) would be happy to sit down and talk to you about it.
Get his home email address
Enter it here (don't visit from work, do it from a web cafe and behind 7 proxies) http://www.spamyourenemies.com/
Uh, isn't that opting in? If you're soliciting email, it's not spam... Sure, you're acting as the victim's unofficial proxy, and few spammers properly instantiate verification mechanisms ("double opt-in"), but still, this site isn't fair to spammers who have gone into the trouble of actually implementing opt-in rather than opt-out.
First, the terms of Qt's released software state that if they don't have a timely update with real content under GPL, the whole damn thing defaults and becomes BSD Licensed. This is a hasty overview (as in they have specifics for each piece and it's well worded), and Nokia is a big enough giant that they could conceivably nullify this clause if they wanted, but it's there. Qt will remain free.
Second, Nokia recently bought a music distribution company, and they're rapidly developing touch-screen systems. Apple has already proven the profitability of DRM. Nokia is simply joining the club. So of course, they're encouraging DRM-friendly applications.
Speaking of joining clubs, Nokia recently purchased Trolltech (Qt), Navtech (the map/traffic db company whose data powers Google Maps), a music distribution firm, and they're likely to keep on purchasing like crazy for a while because (a) they can and (b) they've been slumping lately and they need to get back in the A-game.
Yes, the Prius has the ability to catch up on a long-term scale. My point was that many hybrids (especially the Camry) do not. My above "plan" that doesn't include the Camry but does include the Prius.
The new Camry is a TANK. It's as big as a Crown Victoria! One online review says "I stuck to local streets during my Camry Hybrid test drive and averaged 30 MPG," which is only slightly better than my non-hybrid Corolla. I suppose the hybrid Camry would be a great investment for a taxi company or somebody else who needs the trunk space, but anybody else should steer clear.
Unless your demand is otherwise, smaller is still better. Don't get fooled by the "hybrid" marketing game - compare the hybrid's MPG to a smaller car. If I were shopping for a car right now, I'd be looking at the hybrid Civic, the Prius, or (more likely) a 15-year-old crapper that does 30+MPG highway as a holdout for an all-electric car or plug-in hybrid (without voided warranty), which should be coming out in the next few years, e.g. Chevy Volt, AXP winner(s), 2010 Prius (maybe).
Looking at minimizing your carbon footprint, hybrids aren't even an option; the environmental cost of creating the battery is never going to offset the efficiency of a nice light-weight sedan. Wired had a nice article about this called "Don't Buy that New Prius!" a short while ago.
Er, I guess it ruined them if you forgot that worlds other than Dragonlance existed... And I was a super Dragonlance fanboy, and played lots of Dragonlance campaigns, and I never forgot that a gnome in Forgotten Realms wasn't a tinker...
Congratulations, you aren't in the norm. As mentioned below, even the developers of World of Warcraft's gnomes were influenced by tinker gnomes, thus further biasing a significant portion of the RPG genre in that direction. Perhaps it was because you were so knowledgeable about Dragonlance; you knew the distinction for DL gnomes was very world-specific and less applicable in other worlds. Most people fail to mke that distinction.
Don't forget that the novels and model characters greatly influence players' characters. Tinker gnomes make great characters in novels and as NPCs, but (imho) they rarely make great D&D player characters. Most people (obviously not including yourself) therefore play their gnomes as Tinkerers, regardless of the campaign setting.
Gnomes are a jolly-natured people of the highlands (hills, woods, and the like). I used to think (back in the 2e days) of gnomes as like "dwelves" - as much dwarves as they are elves.
Gnomes differ most from dwarves in terms of magic. Dwarves are very attached to their religions and draw most of their magic from divine paths, whereas gnomes have innate arcane abilities and a natural predisposition to arcane disciplines (e.g. illusionist). Their jolly nature makes them natural entertainers (e.g. bard). In many ways Tinker Gnomes were merely an extremity of this; jolly investigators into alchemy (a very universally gnomish trait) and invention, who are more interested in the fun of the process and the unpredictability of the output than in getting hard results or reliable devices.
Let's just hope they didn't forget the dragons this time.
As a matter of fact, this isn't the first time that has happened. Back in the early 80s, TSR (then-makers of D&D) had a brain-storming session to determine where the game should go. They concluded that they had tons of dungeons but not much by way of dragons. So somebody got the kooky idea that dragons could be the focal point of a world, and there would be annoying klepto midgets, loopy mad scientists, exploding humanoid dragons, knights that rode dragons instead of horses, and the gods would suck and then die. The Dragonlance world resulted.
Frankly put, the Kender and Tinker Gnomes were an awful addition to playable races - they make great non-player characters, but the genre was already riddled with an over-capacity of socially inept players; why egg them on? Dragonlance ruined gnomes in D&D, ultimately leading to their exclusion from playable races in 4th edition. Hopefully, their new role as "monsters" will remove the notion of "all gnomes are tinker gnomes" and we can see them returned in 5th edition.
It gets better: Revision3 can sue MediaDefender under the terms of the very law that MediaDefender was supposed to use: the DMCA.
Think about it; Revision3 was inserting malicious code into the torrent stream, which is breaking through the "encryption" of bittorrent, which violates the DMCA. Content be damned, MediaDefender is guilty of more than just the DoS.
I hope you're not stupid enough to think that your company's trade secrets are safe in email that doesn't go through gmail...
www.gmail-is-too-creepy.com has a good run-down of the issues with using Google's email. Specifically, Google tracks everything and has a LOT of intimate knowledge of using statistical data (like the data in your corporate emails) for it's own benefit -- behold the power of relational databases (Bayesian techniques are just the tip of the iceberg).
Also of note, even without encryption, intra-office email travels from one user's computer to the company's internal mail server, never leaving the office. The recipient is also in the office, so even upon delivery, nobody can have read the message. On top of this, any sane implementation will involve encryption (SSMTP and IMAPS), so even if either or both of these users are off-site, it still doesn't pass unencrypted outside the company.
Well, your reading of the EULA is interesting. Slapping an Apple logo on a non-Apple computer, though, would be a violation of Apple's trademark in their logo. No it wouldn't. SELLING a system with an Apple logo would violate their trademark. You can do anything you want with your stickers on your private possessions.
This License allows you to install and use one copy of the Apple Software on a single Apple-labeled computer at a time.
So... the license restricts your use on Apple-labeled computers but says nothing of non-Apple-labeled computers. You can interpret this in two ways: Since it does not restrict you from using the Apple Software on non-Apple-labeled computers, you are thus limitless, or you can slap an Apple, Inc. sticker on your computer (or build your computer within an Apple-labeled tower) and use the software on it (you know how EULAs always go to such extreme measures to define each term? "Apple-labeled computer" isn't defined!).
Java doesn't do anything by itself. It's a programming language. Programming languages are like sewage plants: if the average user becomes aware of them, something's gone wrong.
Wow, I thought these "photo gallery" articles were all fluff to attract link propagation sites like Digg and Slashdot (speaking of annoying things out there).
Isn't NetBSD the system filled with academics who insist upon clean, manageable, and portable code above all other standards? Too bad the NetBSD kernel didn't get judged here, I suspect it would have taken the cake.
I still recall this exhaustive report comparing several kernels' performance back in 2003 in which NetBSD pretty much beat the pants off of everybody else (note the two updates with separate graphs). The initial poor performance was due to an old revision, and upon seeing that there were some places in which the newer revision wasn't so hot, the developers fixed them and in only two weeks, NetBSD beat out FreeBSD on every scalability test. Their pragmatism and insistence on quality code finally paid off.
Ever since seeing those charts, I've been waiting for Debian/NetBSD to come out...
With ZFS you can smash a hard drive and keep the system running
How is this different than RAID-6? It looks like a slightly different ordering of the parity, which may seem more like a doubly-redundant RAID-10 (RAID-60?), but it's still something easily achieved with Linux software RAID and LVM. ZFS might make it easier or simpler, but it's all there in the Linux kernel.... and LVM can be read by rescue disks, but ZFS would need to use a Solaris rescue disk.
ZFS looks great and promising, but I'll hold off until it's supported by knoppix and available without hand-recompiling the Linux kernel. I'll probably only see it as a viable option when Debian offers it as an option for my root filesystem in the installation process.
Slashdot Mirror
Actually, water droplets are thicker than water. Go to a mattress store and ask about their mattress covers; buying a waterproof cover is pretty much mandatory for a foam mattress (think *sponge*), and the current level of technology stops water and allergens but not air.
Mattress sellers often have a demo device, basically a closed tube where one end is covered only by their fabric and the tube has a whole bunch of colored mouthwash in it. Air goes through it, but you can't shake the mouthwash out.
This would obviously ding fan efficiency, but fanless laptops already exist...
I would wonder about their claim of "Completely Waterproof" ... does that mean I can drop it in the tub and scrub it clean? There has to be a limit somewhere...
Yes, I know .localdomain won't be available, but what about users and systems within local networks that tend to function on alternate (internal-only) and implied (non-canonicalized) domains?
... Under an infinite number of TLDs, this isn't reliable.
.office or .foo TLD wouldn't stop this from working, I'd prefer a lookup failure to a key mis-match when trying such a command from a machine lacking the above config.
Let's say I have a partitioned office network at the company Foo Powers. My workstation is khopesh.office.foopowers.com (which is NAT'ed). From another system within the office, I'd probably just run ssh khopesh to get there (which implies khopesh.office.foopowers.com). To log into the web server (which lives in the DMZ), I'd run ssh www.dmz and to get back to my system, ssh khopesh.office would do the trick.
There are cool SSH tricks you can do to traverse NATs; I have it rigged so that from home, I can run ssh khopesh.office and get in. This triggers an entry in my ~/.ssh/config that looks like this (the first entry fits the above example. the second entry allows me to define an arbitrary extension to trigger a proxy rule and then remove the extension inside the proxy):
Host *.office
ProxyCommand ssh proxy.office.foopowers.com nc -w 1 %h %p
Host *.foo
ProxyCommand ssh proxy.office.foopowers.com nc -w 1 $(echo %h|sed s/\.foo$//) %p
While a real
Oops, there should be only one percent sign in the target="${file%.*}.tiff" line. This enables your use of "User Manual 3.7.pdf" -> "User Manual 3.7.tiff" instead of "User Manual 3.tiff" as the above AC posted (and I copied). Also, the second script should have quotes around the first argument to find, which should use @ instead of 1, which respects multiple arguments and the spaces within them while still defaulting to the current working directory when there are no arguments.
I've incorporated this into my psmerge replacement script psmerge2 which uses ghostscript to merge and convert documents that it can read. I often use it to convert single documents from one format to another, and now it can also convert PDFs (and PSs) to TIFF.
This code will not work on files with spaces in them, because the back-ticks will expand spaces without escapes while the shell globbing used in the original code will escape them. Since most PDF titles I've seen use spaces in their names, this is important. The rest of those modifications will help, though.
Were I coding this script, I'd write two (since xargs can't use a function). One for the inner loop, and one for the outer loop (or if only running it once, I'd do the outer loop on the command line.
$ cat pdf2tiff.sh#!/bin/sh
# convert specified files from PDF to TIFF
for file in "$@"; do
target="${file%%.*}.tiff"
if [ -r "$file" ] && [ ! -s "$target" ]
then echo "gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg4 -sOutputFile='$target' '$file'"
gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg3 -sOutputFile="$target" "$file" 2>/dev/null
else
echo "'$file' not readable or '$target' exists, skipping"
fi
done
$ cat pdf2tiff-recursive.sh
#!/bin/sh
# convert all PDFs to TIFF format within supplied directory tree (default: $PWD)
find ${1:-.} -name '*.pdf' -print0 |xargs -0
You'll love the Qtopia phones once they start rolling out; Qtopia 4.4+ includes a very nice and cleaned version of webkit, so the built-in web browser will be virtually identical (in terms of HTML/JS/etc rendering). The big difference is that since webkit is an integral part of Qt, you'll see HTML-enrichened widgets and views all over the place rather than just the browser and a few custom applications. Using webkit in Qt apps is as trivial as using a text box.
The Greenphone was ditched in favor of better options. The current development platform of choice is the Neo1973, the same platform used by the OpenMoko folks. Nokia hasn't yet announced a new development platform (i.e. one that they actually make) for Qtopia Phone Edition.
As to portability, that's one of Qtopia's biggest merits. It was so extreme that before the Greenphone was nixed, people were finding better support on other platforms (since Trolltech had no idea of how to design cellphone hardware). The only reason they even made the Greenphone was to jump-start the Qtopia Phone development community and (probably) as the second big step to position themselves for a buyout by either Motorola or Nokia. (The first step was the IPO in Norway.)
With Nokia's acquisition of Trolltech (makers of Qt and Qtopia), Google is set to butt heads against a VERY large competitor, who is all-in on re-entering the US cellular industry.
Nokia is roughly the same size as Google (bigger in some ways, smaller in others), but more importantly, it's got more at stake. Qt/Embedded (a.k.a. Qtopia) is a heavyweight competitor to Android which has had far more design time, with a much more solid basis (Qt and Qtopia are both many years old, though Trolltech only recently aimed at cellular technology, which should be quickly rectified by Nokia's massive development teams). Google's dot-com mentality allows them to toss megabucks at an idea, like throwing things against a wall to see what sticks. If Android doesn't stick, whatever; they can afford it. If Qtopia doesn't stick, Nokia is back the drawing board and fighting a losing battle against LG.
Google's only merit is that they've been working on Andriod for longer than Nokia has been working on Qtopia (Nokia only finalized the Trolltech purchase last week). Google's only chance is to bring Andriod to dominance before Nokia manages to release Qt-powered phones. While they appear well-poised for this, the setback of this and other delays hurt the Andriod line more than you might think at a quick glance.
The cellphone platforms of tomorrow will be Apple iPhone, Google Andriod, and Nokia Qtopia. The other players (Motorola, Erickson, LG) will be left in the dust (or they'll adopt one of the above platforms rather than squeezing as much as they can out of standard J2ME). We'll see where Palm fits in with their revamped platform; they could easily go either way.
Can Google really face Microsoft on one front (office apps) and Nokia in the other? What about its bread & butter of web searching (their original front against Yahoo)? What's next, a car to take on Ford and Toyota? :-p
There's an upcoming paper coming from MIT on this topic, Recognition of Natural Scenes from Global Properties: Seeing the Forest Without Representing the Trees that proves this isn't as hard as you might think.
To sum up this massive paper in a very small (and likely highly imprecise) nutshell, building models up from basic objects (the traditional method) is only one way to approach this. Using this method, you are correct; it's impossible to understand what a canyon is. Using the new global properties methods in this upcoming paper, you can gather basic elements that could easily help in assigning location properties, understanding that something pictured is a desert or forest, and theoretically using that data to help determine which desert or forest (this latter portion is beyond the scope of the paper, but great fodder for a future paper that builds upon these fundamentals).
While the method currently requires a high level of labeling in its images, it is hoped that this labeling becomes unnecessary on larger data sets.
The book How to Design Programs specializes in this topic. It is available for free online, it was written by a programming languages specialist at Northeastern University (a 30 minute T ride from Tufts) and published at MIT (a 15 minute T ride from Tufts).
Yes, it's very academic in nature -- it uses Scheme as its base language (well, a very simplified/gimped Scheme) under the premise that it's not your standard procedural language (so you won't fall into old habits) yet it is easy to pick up and learn the fundamentals of programming rather than the specifics of a useless language (e.g. whatever language-of-the-day is liked by industry).
I'm sure there are several research papers tied to the book, and I'm also sure that Matthias Felleisen (its author, trustee professor at Northeastern University) would be happy to sit down and talk to you about it.
Enter it here (don't visit from work, do it from a web cafe and behind 7 proxies)
http://www.spamyourenemies.com/
Uh, isn't that opting in? If you're soliciting email, it's not spam... Sure, you're acting as the victim's unofficial proxy, and few spammers properly instantiate verification mechanisms ("double opt-in"), but still, this site isn't fair to spammers who have gone into the trouble of actually implementing opt-in rather than opt-out.
First, the terms of Qt's released software state that if they don't have a timely update with real content under GPL, the whole damn thing defaults and becomes BSD Licensed. This is a hasty overview (as in they have specifics for each piece and it's well worded), and Nokia is a big enough giant that they could conceivably nullify this clause if they wanted, but it's there. Qt will remain free.
Second, Nokia recently bought a music distribution company, and they're rapidly developing touch-screen systems. Apple has already proven the profitability of DRM. Nokia is simply joining the club. So of course, they're encouraging DRM-friendly applications.
Speaking of joining clubs, Nokia recently purchased Trolltech (Qt), Navtech (the map/traffic db company whose data powers Google Maps), a music distribution firm, and they're likely to keep on purchasing like crazy for a while because (a) they can and (b) they've been slumping lately and they need to get back in the A-game.
Yes, the Prius has the ability to catch up on a long-term scale. My point was that many hybrids (especially the Camry) do not. My above "plan" that doesn't include the Camry but does include the Prius.
The new Camry is a TANK. It's as big as a Crown Victoria! One online review says "I stuck to local streets during my Camry Hybrid test drive and averaged 30 MPG," which is only slightly better than my non-hybrid Corolla. I suppose the hybrid Camry would be a great investment for a taxi company or somebody else who needs the trunk space, but anybody else should steer clear.
Unless your demand is otherwise, smaller is still better. Don't get fooled by the "hybrid" marketing game - compare the hybrid's MPG to a smaller car. If I were shopping for a car right now, I'd be looking at the hybrid Civic, the Prius, or (more likely) a 15-year-old crapper that does 30+MPG highway as a holdout for an all-electric car or plug-in hybrid (without voided warranty), which should be coming out in the next few years, e.g. Chevy Volt, AXP winner(s), 2010 Prius (maybe).
Looking at minimizing your carbon footprint, hybrids aren't even an option; the environmental cost of creating the battery is never going to offset the efficiency of a nice light-weight sedan. Wired had a nice article about this called "Don't Buy that New Prius!" a short while ago.
Congratulations, you aren't in the norm. As mentioned below, even the developers of World of Warcraft's gnomes were influenced by tinker gnomes, thus further biasing a significant portion of the RPG genre in that direction. Perhaps it was because you were so knowledgeable about Dragonlance; you knew the distinction for DL gnomes was very world-specific and less applicable in other worlds. Most people fail to mke that distinction.
Don't forget that the novels and model characters greatly influence players' characters. Tinker gnomes make great characters in novels and as NPCs, but (imho) they rarely make great D&D player characters. Most people (obviously not including yourself) therefore play their gnomes as Tinkerers, regardless of the campaign setting.
Ever seen a svirfneblin tinkerer? Yuck.
Gnomes are a jolly-natured people of the highlands (hills, woods, and the like). I used to think (back in the 2e days) of gnomes as like "dwelves" - as much dwarves as they are elves.
Gnomes differ most from dwarves in terms of magic. Dwarves are very attached to their religions and draw most of their magic from divine paths, whereas gnomes have innate arcane abilities and a natural predisposition to arcane disciplines (e.g. illusionist). Their jolly nature makes them natural entertainers (e.g. bard). In many ways Tinker Gnomes were merely an extremity of this; jolly investigators into alchemy (a very universally gnomish trait) and invention, who are more interested in the fun of the process and the unpredictability of the output than in getting hard results or reliable devices.
As a matter of fact, this isn't the first time that has happened. Back in the early 80s, TSR (then-makers of D&D) had a brain-storming session to determine where the game should go. They concluded that they had tons of dungeons but not much by way of dragons. So somebody got the kooky idea that dragons could be the focal point of a world, and there would be annoying klepto midgets, loopy mad scientists, exploding humanoid dragons, knights that rode dragons instead of horses, and the gods would suck and then die. The Dragonlance world resulted.
Frankly put, the Kender and Tinker Gnomes were an awful addition to playable races - they make great non-player characters, but the genre was already riddled with an over-capacity of socially inept players; why egg them on? Dragonlance ruined gnomes in D&D, ultimately leading to their exclusion from playable races in 4th edition. Hopefully, their new role as "monsters" will remove the notion of "all gnomes are tinker gnomes" and we can see them returned in 5th edition.
It gets better: Revision3 can sue MediaDefender under the terms of the very law that MediaDefender was supposed to use: the DMCA.
Think about it; Revision3 was inserting malicious code into the torrent stream, which is breaking through the "encryption" of bittorrent, which violates the DMCA. Content be damned, MediaDefender is guilty of more than just the DoS.
I am not a lawyer.
www.gmail-is-too-creepy.com has a good run-down of the issues with using Google's email. Specifically, Google tracks everything and has a LOT of intimate knowledge of using statistical data (like the data in your corporate emails) for it's own benefit -- behold the power of relational databases (Bayesian techniques are just the tip of the iceberg).
Also of note, even without encryption, intra-office email travels from one user's computer to the company's internal mail server, never leaving the office. The recipient is also in the office, so even upon delivery, nobody can have read the message. On top of this, any sane implementation will involve encryption (SSMTP and IMAPS), so even if either or both of these users are off-site, it still doesn't pass unencrypted outside the company.
The Electronic Frontier Foundation (EFF), Software Freedom Law Center (SFLC), and other key "patent busters" need to write open letters in support of this action. We need visibility here.
So ... the license restricts your use on Apple-labeled computers but says nothing of non-Apple-labeled computers. You can interpret this in two ways: Since it does not restrict you from using the Apple Software on non-Apple-labeled computers, you are thus limitless, or you can slap an Apple, Inc. sticker on your computer (or build your computer within an Apple-labeled tower) and use the software on it (you know how EULAs always go to such extreme measures to define each term? "Apple-labeled computer" isn't defined!).
here's a gem from the article:
Wow, I thought these "photo gallery" articles were all fluff to attract link propagation sites like Digg and Slashdot (speaking of annoying things out there).
Oops, it needs a trailing slash: http://bulk.fefe.de/scalability/
Isn't NetBSD the system filled with academics who insist upon clean, manageable, and portable code above all other standards? Too bad the NetBSD kernel didn't get judged here, I suspect it would have taken the cake.
I still recall this exhaustive report comparing several kernels' performance back in 2003 in which NetBSD pretty much beat the pants off of everybody else (note the two updates with separate graphs). The initial poor performance was due to an old revision, and upon seeing that there were some places in which the newer revision wasn't so hot, the developers fixed them and in only two weeks, NetBSD beat out FreeBSD on every scalability test. Their pragmatism and insistence on quality code finally paid off.
Ever since seeing those charts, I've been waiting for Debian/NetBSD to come out...
How is this different than RAID-6? It looks like a slightly different ordering of the parity, which may seem more like a doubly-redundant RAID-10 (RAID-60?), but it's still something easily achieved with Linux software RAID and LVM. ZFS might make it easier or simpler, but it's all there in the Linux kernel. ... and LVM can be read by rescue disks, but ZFS would need to use a Solaris rescue disk.
ZFS looks great and promising, but I'll hold off until it's supported by knoppix and available without hand-recompiling the Linux kernel. I'll probably only see it as a viable option when Debian offers it as an option for my root filesystem in the installation process.