This is blindingly obvious to everyone except themselves; like the story submitter, they tend to make up all sorts of more palatable justifications for why they like their hobby.
Resorting to ad hominem attacks like that really doesn't help your point.
I'll agree that some people use roleplaying (or anime, novels, what have you) as a form of escapism. But I'll bet there are a lot more who use them simply as a form of entertainment, as they are designed to be. Not all of us have this urge to rip on anything that's not a true literary work of art; what is fun, is fun, and doesn't need justification beyond that.
Theoretically, the amount of residential electricity needed in the evening hours is dependent both on when the sun sets and when people go to bed. Because people tend to observe the same bedtime year-round, by artificially moving sunset one hour later, the amount of energy used is theoretically reduced.
Theoretically, there's no difference between theory and practice. In practice . . . well, you know the rest.
As a demonstration: How many of you have the air conditioner on while you're at home in the summer? (raises hand)
When the U.S. went on extended DST in 1974 and 1975 in response to the 1973 energy crisis, Department of Transportation studies found that observing DST in March and April saved 10,000 barrels of oil a day
And how many buildings had air conditioning in 1974 and 1975, or used it all the time even if they did? Far fewer than have it now, I'm willing to bet.
a friend has a Canon A40 that exhibits the exact same symptoms described, but Canon says it is not on the list, so they won't do anything about it. Anybody else out there? If so, start bugging Canon and maybe they'll realize there is a problem.
That may be the best course of action--I'm actually not sure whether to be relieved that my own Sony DCR-TRV70K isn't listed, because I bought it in late 2003, right around the time they were putting out these bad CCDs. On the other hand, if it does go bad, I guess I could use that as an excuse to splurge on one of the new high-def video cameras . . .
The advantage of this approach is that blocking is explicit: the programmer knows exactly which functions that block that which functions the never blocks.
My English parser thread shut down at that point . . .
Seriously, this looks like a handy little thing for low-memory systems, though I'd be a bit hesitant about pushing at the C standard like that--the last thing you need is a little compiler bug eating your program because the compiler writers never thought you'd do crazy things to switch blocks like that.
Japan recently enacted a law along similar lines. The target is skimming, not phishing, but it makes banks 100% responsible for account owners' losses from duped ATM cards (with a few limited exceptions, like if you write the PIN on the card you don't get your money back). The net effect has been to speed the introduction of IC-based cards, some of which use biometric verification as well--my own bank (Tokyo-Mitsubishi) has this funky palm reader thing on their latest ATMs that makes me wonder if it tells you your fortune while it's processing.
It never made sense to me that we'd have to "shut down" as opposed to just turning the thing off.
As everyone else is saying, you lose your disk cache that way. The solution to long shutdown sequences is rm/etc/rc.d/rc?.d/K* (or the equivalent for your distribution). 99% of the daemons out there will shut down just fine on SIGTERM and won't suffer any harm from a SIGKILL; let the standard shutdown script unmount everything and you're done. Shutdown time on my desktop is around 3-5 seconds after the global SIGKILL, which is definitely within my acceptable range.
(Caveat: make sure you check what you're deleting before you delete it! Some weird distribution might have the shutdown script as a K* script, who knows)
I can assure you I won't go in an airplane if it was done with Linus' practices...
Don't blame the builder if he doesn't have the tools. The real problem is that the field of software development is just too young for the sort of meaningful and useful standards and practices needed for solid engineering to have been developed. Right now, we have:
A design process thought out by people who have spent way too long thinking about design theory (in theory, theory and practice are the same--in practice, they're not)
A bunch of programming languages, most of which were created by looking at earlier ones and saying "hey, I can tweak this and call it a new language!"
A testing methodology that says "throw everything in the book at it, and hope your book isn't missing any pages"
That's not exactly a recipe for success. Granted, it is possible to make things work right for a single project if you throw enough effort into it (e.g. the Space Shuttle software), but the vast majority of developers don't have that kind of effort available to throw around, and we're still a good number of years (decades?) away from figuring out what everything has in common and how to make it work cleanly. We're making progress, certainly--concepts like encapsulation spring to mind--but there's still a long way to go before you can talk about "software engineering" the same way you do, say, "civil engineering".
There are no "infinite" levels per se . . . however, there is a "very-close-to-infinite" level that pops up after you've finished every other stage, including the bonus stage that appears after finishing the game and the bonus stage that appears after collecting all the cousins. It is, unfortunately, not a very interesting level (you're closed into a small area, you can only collect one type of object, and you don't grow in size), but you never run out of stuff to collect, so if nothing else it's a good time-waster.
Yum. Somebody slashdot me so I can finally find out how much upstream bandwidth I have--so far all I've been able to do is max out everyone else's downstream . . .
Good grief. Here I thought people would be intelligent enough to see how blindly impossible my suggestion was, realize that I was joking, and take the light humor as it was intended. That'll teach me.
Granted, I'm living in Tokyo where the population density is about 137 people per square foot, but it can't be that hard to string optical fiber alongside the phone lines . . .
I so wish I'd had a few more years on me during those days . . . we didn't have a C64 at home, but we did have an Atari 400, and I didn't really understand until much later all the things you could do with it. (Though it did give me my start in assembly, by way of a cassette loader that dumped 40 mysterious characters on the screen--which, I discovered after much staring at character and opcode tables, was the first-stage loader in machine code. I still remember thinking, wow, look at all this neat stuff you can do! And then I got caught up in the IBM-PC era.)
Source, please? (I'm not doubting you, I just want to know exactly what the standards say. I did glance through the drafts on www.14443.org but didn't see anything related to authentication; is it something that was only added in the final version of the standards?)
You are telling us publicly you've been raising your hand to six month old babies?
Being unmarried, I'm not in a position to be doing anything to six-month-old babies, but I expect that when I am in that position, I will be using physical discipline to the extent needed--as it was used, effectively IMHO, with me. (No, I'm not saying I'm going to break bones or anything like that! Good grief.)
If you still believe that's a bad idea, then I'm happy to agree to disagree with you. But I have a feeling that this "avoid-pain-at-all-costs" super-pampering attitude is going to come back to bite us as a society in the future. If a kid doesn't know what pain is, how will s/he know that hurting others is a bad idea--or more importantly, why it's a bad idea?
Kiki's Delivery Service is just as good, though it has a different flavor than most of his other movies (as other posters mention below).
I do have to say, however, that I was disappointed by Howl's Moving Castle; perhaps it's just that I've come to expect a higher standard from Miyazaki, but it really didn't live up to what I was looking forward to. (Not that it was a bad movie--just not Miyazaki quality.) I've never read the book it was based on so I can't make comparisons, but my feeling is that he does better writing original stories.
Okay, I'll grant that the SD card interface may be a poor one, but the same holds true for every other solid-state interface I've used--CF, SmartMedia, Sony's little Memory Stick thing, and USB2 (High-speed) flash devices. (FWIW, I recall similarly poor results when I was doing R&D with a solid-state disk on 2.5" IDE, but that was a few years ago so things may well have changed in the meantime, and speed wasn't important for the particular application so I never took down numbers.) I am of course aware of the seek issue, and I'll agree that for a server that accesses lots of different files randomly seek time can become a factor; when I wrote my reply, dumps of large, relatively contiguous data streams (e.g. MP3 files) were on my mind, and even a 20ms seek time is only a small fraction of the time it takes to actually get the data off the device, so sustained transfer rates really do make a difference. But I suppose I'll keep an eye out for how they progress.
Incidentally, the speed tests in my original reply were done with hdparm, which tries hard to keep system overhead from affecting the measured transfer rate. As it turns out, I was misrunning it, since it seems to support O_DIRECT now (previous versions used the cached read timings to adjust for buffering), but since the data read from the disk wasn't in memory in the first place anyway, buffering can't have sped it up--the data has to come off the disk one way or another. For the record, I just re-ran the tests with --direct, and got the same results +/- 1%.
This one claims 44MB/s sustained writing - considerably more than whatever your buffer-obscured HD is actually capable of, I'll wager.
Let's see:
# hdparm --direct -t/dev/hda (ATA100 HD) /dev/hda:
Timing O_DIRECT disk reads: 134 MB in 3.04 seconds = 44.14 MB/sec
Why don't parents *explain* to their kids, honestly, why their activity is bad? Is that just too hard?
Yes, it is. Or perhaps you could tell me how you intend to present such an explanation to a 6-month-old baby?
I'll agree with your point that spanking kids when they're 7, or 5, or maybe even 3 (depending on the kid), is unnecessary. But don't take that to the extreme so many politicians are taking it to.
It sounds like they sponsored you to come to Japan and work.
Nope, I entered NTT exactly the same way everyone else did: interviews and a test, the same standard fare most Japanese companies use. Admittedly I'd been doing an internship there so they knew my qualifications already, but once I started full-time they treated me exactly the same as everyone else. (Which is in fact the main reason I left them.)
You have to keep in mind too that you're working for NTT. [...] It's a huge frigg'n company that pays well.
10 years ago it was, or so my friends say. These days, between telephone deregulation, splitting (NTT East/West), and mobile phones (NTT DoCoMo is separate from East/West), the phone company itself is in really dire straits; bonuses dropped something like 30% in the four years I was there, and yearly raises were on the order of 1% of salary. When I shopped around for a new job, my lowest offer was about $10k over what I was making.
Incidentally, all the (respectable, stable) companies I've looked at pay at least couple months' worth of bonuses and offer some degree of housing benefits, like a few man off your rent, even if they don't sponsor apartments like many large companies do. Granted, tiny startups may not have that leeway, but otherwise you might seriously want to look into finding a new job. There are a number of good job fairs around--I found my current job at this one run by Gakken Medicom.
P.S. The reason for the bonus is so that the company get's an interest free loan from the employees by dividing your yearly payments into 14 parts as opposed to 12.
Aha, I knew they had to be getting something out of it . . .
Slashdot Mirror
It does indeed seem to be: http://slashdot.org/users.pl?uid=0
Resorting to ad hominem attacks like that really doesn't help your point.
I'll agree that some people use roleplaying (or anime, novels, what have you) as a form of escapism. But I'll bet there are a lot more who use them simply as a form of entertainment, as they are designed to be. Not all of us have this urge to rip on anything that's not a true literary work of art; what is fun, is fun, and doesn't need justification beyond that.
Developers! Developers! Developers! Developers!
At least, I can't think of any other explanation for the continuing proliferation of Windows software . . .
Theoretically, the amount of residential electricity needed in the evening hours is dependent both on when the sun sets and when people go to bed. Because people tend to observe the same bedtime year-round, by artificially moving sunset one hour later, the amount of energy used is theoretically reduced.
Theoretically, there's no difference between theory and practice. In practice . . . well, you know the rest.
As a demonstration: How many of you have the air conditioner on while you're at home in the summer? (raises hand)
When the U.S. went on extended DST in 1974 and 1975 in response to the 1973 energy crisis, Department of Transportation studies found that observing DST in March and April saved 10,000 barrels of oil a day
And how many buildings had air conditioning in 1974 and 1975, or used it all the time even if they did? Far fewer than have it now, I'm willing to bet.
Give it a few years, you'll get over it.
a friend has a Canon A40 that exhibits the exact same symptoms described, but Canon says it is not on the list, so they won't do anything about it. Anybody else out there? If so, start bugging Canon and maybe they'll realize there is a problem.
That may be the best course of action--I'm actually not sure whether to be relieved that my own Sony DCR-TRV70K isn't listed, because I bought it in late 2003, right around the time they were putting out these bad CCDs. On the other hand, if it does go bad, I guess I could use that as an excuse to splurge on one of the new high-def video cameras . . .
Digital still cameras
Digital video cameras
Professional camcorders
Other products
I got to this little gem:
My English parser thread shut down at that point . . .
Seriously, this looks like a handy little thing for low-memory systems, though I'd be a bit hesitant about pushing at the C standard like that--the last thing you need is a little compiler bug eating your program because the compiler writers never thought you'd do crazy things to switch blocks like that.
Japan recently enacted a law along similar lines. The target is skimming, not phishing, but it makes banks 100% responsible for account owners' losses from duped ATM cards (with a few limited exceptions, like if you write the PIN on the card you don't get your money back). The net effect has been to speed the introduction of IC-based cards, some of which use biometric verification as well--my own bank (Tokyo-Mitsubishi) has this funky palm reader thing on their latest ATMs that makes me wonder if it tells you your fortune while it's processing.
It never made sense to me that we'd have to "shut down" as opposed to just turning the thing off.
As everyone else is saying, you lose your disk cache that way. The solution to long shutdown sequences is rm /etc/rc.d/rc?.d/K* (or the equivalent for your distribution). 99% of the daemons out there will shut down just fine on SIGTERM and won't suffer any harm from a SIGKILL; let the standard shutdown script unmount everything and you're done. Shutdown time on my desktop is around 3-5 seconds after the global SIGKILL, which is definitely within my acceptable range.
(Caveat: make sure you check what you're deleting before you delete it! Some weird distribution might have the shutdown script as a K* script, who knows)
I can assure you I won't go in an airplane if it was done with Linus' practices...
Don't blame the builder if he doesn't have the tools. The real problem is that the field of software development is just too young for the sort of meaningful and useful standards and practices needed for solid engineering to have been developed. Right now, we have:
That's not exactly a recipe for success. Granted, it is possible to make things work right for a single project if you throw enough effort into it (e.g. the Space Shuttle software), but the vast majority of developers don't have that kind of effort available to throw around, and we're still a good number of years (decades?) away from figuring out what everything has in common and how to make it work cleanly. We're making progress, certainly--concepts like encapsulation spring to mind--but there's still a long way to go before you can talk about "software engineering" the same way you do, say, "civil engineering".
There are no "infinite" levels per se . . . however, there is a "very-close-to-infinite" level that pops up after you've finished every other stage, including the bonus stage that appears after finishing the game and the bonus stage that appears after collecting all the cousins. It is, unfortunately, not a very interesting level (you're closed into a small area, you can only collect one type of object, and you don't grow in size), but you never run out of stuff to collect, so if nothing else it's a good time-waster.
My super-sparkly Palladium Wristwatch I got from Microsoft will get splashed and start bluescreening again!
Here in Japan, I have 55 megabit fiber DSL.
That's all? I'm sitting here in Yokohama with an ONU in my kitchen, and wget doing things like this:
Yum. Somebody slashdot me so I can finally find out how much upstream bandwidth I have--so far all I've been able to do is max out everyone else's downstream . . .Good grief. Here I thought people would be intelligent enough to see how blindly impossible my suggestion was, realize that I was joking, and take the light humor as it was intended. That'll teach me.
As long as they're going that far, why not just build it all the way to the moon? All the counterweight mass you need and then some, right there!
Granted, I'm living in Tokyo where the population density is about 137 people per square foot, but it can't be that hard to string optical fiber alongside the phone lines . . .
I so wish I'd had a few more years on me during those days . . . we didn't have a C64 at home, but we did have an Atari 400, and I didn't really understand until much later all the things you could do with it. (Though it did give me my start in assembly, by way of a cassette loader that dumped 40 mysterious characters on the screen--which, I discovered after much staring at character and opcode tables, was the first-stage loader in machine code. I still remember thinking, wow, look at all this neat stuff you can do! And then I got caught up in the IBM-PC era.)
ISO/IEC 14443 has two-factor authentication.
Source, please? (I'm not doubting you, I just want to know exactly what the standards say. I did glance through the drafts on www.14443.org but didn't see anything related to authentication; is it something that was only added in the final version of the standards?)
You are telling us publicly you've been raising your hand to six month old babies?
Being unmarried, I'm not in a position to be doing anything to six-month-old babies, but I expect that when I am in that position, I will be using physical discipline to the extent needed--as it was used, effectively IMHO, with me. (No, I'm not saying I'm going to break bones or anything like that! Good grief.)
If you still believe that's a bad idea, then I'm happy to agree to disagree with you. But I have a feeling that this "avoid-pain-at-all-costs" super-pampering attitude is going to come back to bite us as a society in the future. If a kid doesn't know what pain is, how will s/he know that hurting others is a bad idea--or more importantly, why it's a bad idea?
Kiki's Delivery Service is just as good, though it has a different flavor than most of his other movies (as other posters mention below).
I do have to say, however, that I was disappointed by Howl's Moving Castle; perhaps it's just that I've come to expect a higher standard from Miyazaki, but it really didn't live up to what I was looking forward to. (Not that it was a bad movie--just not Miyazaki quality.) I've never read the book it was based on so I can't make comparisons, but my feeling is that he does better writing original stories.
Okay, I'll grant that the SD card interface may be a poor one, but the same holds true for every other solid-state interface I've used--CF, SmartMedia, Sony's little Memory Stick thing, and USB2 (High-speed) flash devices. (FWIW, I recall similarly poor results when I was doing R&D with a solid-state disk on 2.5" IDE, but that was a few years ago so things may well have changed in the meantime, and speed wasn't important for the particular application so I never took down numbers.) I am of course aware of the seek issue, and I'll agree that for a server that accesses lots of different files randomly seek time can become a factor; when I wrote my reply, dumps of large, relatively contiguous data streams (e.g. MP3 files) were on my mind, and even a 20ms seek time is only a small fraction of the time it takes to actually get the data off the device, so sustained transfer rates really do make a difference. But I suppose I'll keep an eye out for how they progress.
Incidentally, the speed tests in my original reply were done with hdparm, which tries hard to keep system overhead from affecting the measured transfer rate. As it turns out, I was misrunning it, since it seems to support O_DIRECT now (previous versions used the cached read timings to adjust for buffering), but since the data read from the disk wasn't in memory in the first place anyway, buffering can't have sped it up--the data has to come off the disk one way or another. For the record, I just re-ran the tests with --direct, and got the same results +/- 1%.
This one claims 44MB/s sustained writing - considerably more than whatever your buffer-obscured HD is actually capable of, I'll wager.
Let's see:
# hdparm --direct -t /dev/hda (ATA100 HD)
/dev/hda:
Timing O_DIRECT disk reads: 134 MB in 3.04 seconds = 44.14 MB/sec
Whaddya know?
Why don't parents *explain* to their kids, honestly, why their activity is bad? Is that just too hard?
Yes, it is. Or perhaps you could tell me how you intend to present such an explanation to a 6-month-old baby?
I'll agree with your point that spanking kids when they're 7, or 5, or maybe even 3 (depending on the kid), is unnecessary. But don't take that to the extreme so many politicians are taking it to.
Where do you get the notion that flash is slow?
Right here:
Timing cached reads: 1584 MB in 2.00 seconds = 791.72 MB/sec
Timing buffered disk reads: 20 MB in 3.20 seconds = 6.26 MB/sec
Timing cached reads: 1568 MB in 2.00 seconds = 784.12 MB/sec
Timing buffered disk reads: 118 MB in 3.03 seconds = 38.92 MB/sec
It sounds like they sponsored you to come to Japan and work.
Nope, I entered NTT exactly the same way everyone else did: interviews and a test, the same standard fare most Japanese companies use. Admittedly I'd been doing an internship there so they knew my qualifications already, but once I started full-time they treated me exactly the same as everyone else. (Which is in fact the main reason I left them.)
You have to keep in mind too that you're working for NTT. [...] It's a huge frigg'n company that pays well.
10 years ago it was, or so my friends say. These days, between telephone deregulation, splitting (NTT East/West), and mobile phones (NTT DoCoMo is separate from East/West), the phone company itself is in really dire straits; bonuses dropped something like 30% in the four years I was there, and yearly raises were on the order of 1% of salary. When I shopped around for a new job, my lowest offer was about $10k over what I was making.
Incidentally, all the (respectable, stable) companies I've looked at pay at least couple months' worth of bonuses and offer some degree of housing benefits, like a few man off your rent, even if they don't sponsor apartments like many large companies do. Granted, tiny startups may not have that leeway, but otherwise you might seriously want to look into finding a new job. There are a number of good job fairs around--I found my current job at this one run by Gakken Medicom.
P.S. The reason for the bonus is so that the company get's an interest free loan from the employees by dividing your yearly payments into 14 parts as opposed to 12.
Aha, I knew they had to be getting something out of it . . .