... vs. an integrated home-brew system capable of playing DVDs, ripped DVDs, surfing the Internet, GPS tracking, listening to MP3s, etc. for right around $550 (and about $120 if you want to add a second head for multiple viewers).
The tech for this is cheap. Very cheap. Doing it yourself is pretty trivial: small Atom system with disk = under $200. DVD = $20. Smaller LCD = $100 (whether it's a 7" touchscreen or a 19" widescreen). GPS and WiFi (or WiMax)/cellular card = $100. Software = another $150 or so, depending on what you want (if anything).
Honestly, for in-car viewing, I don't really see what this iPad offers over a normal laptop or netbook. It costs more? That's hardly a selling point. And I can see kids quickly bitching about having to hold the iPad to watch a movie.
It largely depends on the child. More active children are a nightmare on a long trip, particularly if you've got two of them. I've found a car trip is easily 3-4 times more difficult with multiple children than it is with just one - even if you've got a second adult to help. A single child is pretty easy to handle, really (provided they're over the age of 2).
The problem isn't even so much keeping the kids engaged; it's keeping them engaged and not causing trouble. When you're driving on a busy interstate, the last thing you need is to be hit in the back of the head with a flying toy or have your blood curdled by a scream.
Do you have children? Have you taken a long car trip with them?
An hour in the car is a long time for kids. A very long time. When I was a kid, we'd take a 5-hour trip once a year to visit my grandparents: my dad would pack the minivan early, go to bed early, and then wake up at 4am to start the trip. Hed bundle us up (it was usually Thanksgiving/Christmas time, and cold), and package us in the van, hoping we'd stay asleep until we got there. Even still, we were awake for 2-3 hours of the trip each time, and it seemed like an eternity.
I've taken several long trips with my kids (and my definition of 'long' is slightly longer than the measly 5 hours): I've done a 2-day 1800 mile trip with them and my wife in a Ford Focus. (Yes, it sucked.) There would have been no way to get through the trip in anything less than 4 or 5 days if it wasn't for having a laptop with movies on it. Yes, we gave them books, and when we weren't shift-sleeping (one person would drive and the other would sleep), we were reading books to them, playing games with them (I spy, I'm thinking of..., stupid songs, etc.), and talking with them.
The general rules with kids on a long trip is "if they're in touching distance, they're fighting. If they can see each other, they're fighting." Either that, or they're playing (loudly). It makes any sort of driving difficult.
Leave it to a (probably) childless person to criticize parents for something like this.
Absolutely. Every once in a while there's an article of interest - maybe one or two a day - but compare it to the slashdot of 10 years ago:
* lots of stuff on matchbox PCs * generally cool wearables and project sites * good space articles * the occasional link to esoteric HOWTOs and "look what I did" * links to fun/interesting/cheap hardware (today, we'd have links to the latest/greatest dual core Atom boards and interesting/cheap ARM boards, per chance) * cryptography, weapons and communication tech * indepth insights about archeology * start-up companies with something interesting/innovative/fringe improvements * crazy benchmarks on overclocked hardware and esoteric/fringe/interesting setups
Of course, we had the Hellmouth self-sympathizing crap back then, too. But still! Maybe tech in general was cooler a decade ago than it is now, but it seems that 2/3 front page postings on/. these days is something about Apple, new product news releases, corporate purchases and dealings, rumors, and generally un-geeky things which only impact us in a cursory fashion.
Just take a look at slashdot from today in 2000. And that was after Slashdot already started to suck.
Slashdot was more interesting before it started shilling Apple nonsense, to be sure.
This is something I've been thinking about lately. Obviously, good design dictates that we use a separate app and db server for performance reasons (as it is usually more responsive). However, what about separate purposes (app server, db server), each running in its own VM on the same host? It's something I'm hoping to implement at a not-too-distant time to test.
Put simply: which would you rather have servicing millions of small, distributed requests?
a) thousands of 2.8GHz multicore Intel platforms using large amounts of electricity and heat b) tens of thousands of 800MHz multicore ARM systems using much less than 1/10th the power of the Intel platform, producing significantly less heat?
The answer - to me - is pretty clear. The bottleneck to implementation is the software.
Also: don't use a stupid book that teaches someone how to use "RedHat" or some other such thing. Those people generally have no understanding of existential things like:
* cron * init * the kernel * much of anything in/etc except apache, etc. * LSB directory structure
Honestly, I'd like to see a college course where they take someone from "I've tooled with Linux on the side" to "I've rolled my own distribution for esoteric custom-purpose hardware and turned it into a functional single-use system". It should be part of every CS curriculum; maybe make it a 200 or 250 level, and throw them to the wolves ("get going - and you can work alone or in teams, but everyone must account for their own work").
I'm a strong believer in immersion as the best way to instruct people how to do things.
Probably the best way to go about it would be a VM disk image file sitting on the flash drive itself. Dealing with the actual flash drive might be problematic due to compatibility.
For the virtualization, I'd probably just go with the Open Source version of Virtualbox. It can be run as a server for the lab (if need be - though not advised),
The biggest problems with going with USB flash drives are speed and compatibility, in that order. Flash drives are still very, very slow compared to a hard disk: it will jade their opinion of the operating system due to very sluggish writes (particularly due to the virtual disk allocation on top of the flash). There are also a number of limitations with the flash drive standardization themselves, as many are utter crap. Best to verify the make/model of flash drive you pick works. (Caveat: note that vendors -very frequently- change the underlying chips in the flash drives within a single model. Expect to have to buy them in lots.)
Honestly, given the cost of external hard disks, the lack of flash drive consistency, and your stated apparent requirements of them being able to use their own systems as well as the school lab, you might want to make a USB hard disk a class requirement instead of a flash drive.
But: why stop there? Honestly. When I was in school, we had a lab. I had a laptop. I brought my laptop and did almost everything on my laptop in the lab - and this was way before virtualization became commonplace (VMWare existed, but just barely). There were very few classes where I needed to have anything other than what was on the laptop - Debian Linux. Students could come and use the labs at any time (though most did not, as they had their own computers which were better).
Seriously. This is 2010, not 1998. Assuming you're not offering this as an entry-level course (you shouldn't) and you'll have at least 2nd-semester CS students taking it, there's no reason to coddle them. Just set up a CentOS or Debian system and allow students to connect to it from the campus.
On top of that, encourage them to install Linux themselves and configure it from scratch. It'll be good for them. Make obscene recommendations, like Gentoo or (god forbid) Slackware. A certification isn't going to mean jack shit in the long run (except for maybe taking a job from someone more qualified who doesn't have the cert) if they're not intimately familiar with the material.
This, like the virtualization question the other day, is yet another instance of "virtualization is cool so I want to apply it". It's not appropriate for every scenario (and I'd argue this is one of them, due to the added complexity and potential for outside cases).
As someone else said, memtest86 and prime95 don't cover even a fraction of the CPU functionality.
A better test would be to compile something for a prolonged period of time for your architecture. Off the top of my head, the gentoo install CD might be a good choice for this: start from scratch and build up a kernel and userland for your architecture. In the process you'll be testing the whole system - RAM, CPU, and disk - to at least know there is not an apparent manufacturing defect (short of a drive/electrical failure 2 days later).
If a printer has a 22ppm rate and has 64MB of RAM, you're not going to be able to print more than one or two larger print jobs at a time - particularly if they're RAW jobs. You'll need a print server for that, and you'll have a significant bottleneck before getting to the printer/the printer accepts the job. This leads to user agitation.
So, while 128MB costs $100 (at the time), a 40G disk costs roughly the same amount - and you can cache to disk with marginal overhead and provide a more seamless user experience than the RAM would provide - all while increasing how many jobs can be accepted to queue at a time.
If you let one of these Apple engineers off the hook for their crimes against humanity, then you've got to make exception for them all. It's a slippery slope. First, Apple engineers today; tomorrow, lawyers and political figures. That's a social travesty we can not allow.
While I dislike Apple as a company, let's be fair. Not only are their products quite good (from both a technical and aesthetic standpoint), but they're able to continually change their game. Of the big companies out there, they're the only ones doing truly "different" things during the depression.
Oh, as for "dime a dozen"... seriously? There are how many open systems out there? Debian, Fedora, RedHat, CentOS, FreeBSD, NetBSD, OpenBSD, OpenSolaris - and all their derivatives. Maybe if you were talking hardware, I'd understand, but c'mon: that, if anything, differentiates Apple from the pack.
The need for firewalls in the first place would be negated if every operating system out there didn't ship with a substantial set of outside-facing services enabled. A network connection should always be considered to be a hostile, unsafe environment: you enable what you need, when you need it. Make the UI easy to do so, sure; but don't make it the default.
Yes, there are those outside cases. However, consider how many scenarios can be easily covered with an "exceptioned template".
Take IP tables, for instance. It typically goes something like this: Deny all, do NAT/masq from the inside, do traffic shaping/QoS, and finally allow specific ports/do specific port forwarding. It's formalistic and not all that complex, once you understand it - and it's largely linear, with most of the scripts following the same basics.
For 90%+ of scenarios, it would be easy to instigate a framework for transparent transport of rules between systems (homogeneous and maybe even heterogeneous ones) or automatically setting rules based on inside services. The problem with doing it, however, is that it would provide a negligible benefit over what's out there now (as firewall rules tend to rarely change).
The security ramifications of such an application seem like they'd be hit and miss, internally. Yes. you want to prevent hosts from talking to each other when they've got no reason to - though there are other methods for doing this in a cleaner, less granular/more centralized fashion (802.1q VLANs). It works better because, again, it covers 90%+ of conceivable scenarios with less configuration.
It all comes down to KISS. Sometimes firewall restrictions are appropriate; sometimes something else is. More often than not, though, people use what they know and misapply it for fear of not being able to grasp a new technology in time to properly implement it, and we end up with a gongshow.
It might work, but probably not if the soldier is a US soldier. More often than not, the guys shooting at them can't shoot for shit, and you'd be more likely to be hit due to inaccuracy variance.
My vote is for perl. It's more common in a "base install" than any other shell (in the BSDs and most Linux distros) and has a non-trivial amount of power. It's good at dealing with path and input permutations and you can interface it with pretty much anything. Hell, pcre came from perl, and that's used almost everywhere these days: it's got a lot of things right for the little that's wrong, at least in terms of being a good scripting language.
I avoid "shell" scripting (csh, sh, bash) if at all possible, too. The contortions necessary to do the frequently-necessary evaluations takes quite a bit longer, even with a chain of awk/sed/grep and the like. Unlike those languages, perl is entirely self-contained and does not have any system-specific oddities (eg. with a shell script, many system binaries are different and an option/parameter pair on one system might do something entirely different on another - or not work at all).
I realize perl can often (usually) be difficult to read. But for my purposes, it's good enough, because I'm a bit of a prolific comment writer as a matter of process.
Often, I find myself writing scripts dealing with tasks which are semi-automated: I need a couple variables of input to deal with variance, but for the most part it's a repetitive task.
What you're referring to is a batch script; that's good and fine, and I need those two. But that doesn't mean that interaction delineates a "script" from an "application".
Though, I agree on one thing: a script is a script. There's no need to throw a dialog on there unless it in some way cleans up your input/output code and/or makes parsing the input cleaner.
That definition also excludes a great deal of the artwork of history: anything dealing with religion, lust, beautiful women, political statement - and so on.
For some, emotional impact is key. A "sterile", though accurate drawing can never be art to them. For some, technical skill is important. I know I've refused to call a lot of abstract works "art". For others, social commentary or message is important. A pop singer is mere entertainment (the horror), but replace her lyrics about her boyfriend with ones about the hardships of poverty and she becomes an artist.
For me, two of those have to be met for me to consider it art; all three criteria have to be met for me to consider it "good art". Something like Michaelangelo's David? That's "good art" - for the Romans. To me, it's an artistically made statue and its cultural relevance is lost. It's a technical work I have never seen (first hand) and lacks the gravity required for what I view as "art". I'm sure if I were to see it in person, I'd consider it art - the location of a work is almost as significant as the work itself, in many regards (lighting, setting, etc.)
When someone says something like "games can't be art" I always come back to two examples of games-as-art:
* Max Payne * Deus Ex
Yes, they are my favorite games. They are great games because they are great art - presenting convincing characters, immersive art (auditory and visual), and a well-written story. They are not "winnable" games in the traditional sense, though you can finish them: they have little variance in the actual storyline, regardless of how they are played. Even with the multiple endings of Deus Ex, it's no different than (say) a choose-your-own-adventure book or one of the many 'artsy' movies which do, in fact, have alternate endings.
While some would say that what separates a game from art is the fact that you've got to try at a game but art is more passive, I beg to differ. Compare them, if you will, to movies like Momento, 12 Monkeys, or Donnie Darko. These are movies you've got to think about to "get" - they're not passive movies. Likewise, artistry in drink (whisk(e)y, wine, and beer), music (Chopin, Mozzart, Pink Floyd, etc.) and the like often take effort on the viewer's part to fully appreciate. Much of great art can't be simply summed up in a moment as art; likewise, dismissing anything out of hand is somewhat jaded and small-minded. Those aren't characteristics found in a maven of the arts, though they probably are those of a skeptic or cynic.
Would Ebert say the same thing about computer generated models and animations? How about the CG characters in movies? If those can be considered art, why can not the whole they compose be considered art? Anything otherwise would be as if to say that the Pantheon and Colosseum of Rome were artistic, but the greater architecture of ancient Rome was not. But even though the whole of Rome was not cohesively designed and planned as a whole, many would consider it an example of artistry just the same.
If anything, games are, as a genre, more artful than movies due to the fact that they're much more interpreted by the player than a movie or book. They give you more options. Isn't interpretation half of what art is? And if we're going to judge art by the effort and genius involved in creating it, a great game is certainly on par with many movies.
Well, considering the Old Worlders appear to think that way about their neighbors and the US, it's hardly surprising that they'd assume we'd be doing the same.
Actually, they did. A lot of people said the Government, under Bush, used some sort of weather modification/seismic device in Alaska to change the weather patterns and push the storm directly towards New Orleans - because Bush and the Republicats hateses the Blacks.
Or some such rot. It was even on major broadcast a number of times in passing, and in quite a few printed sources.
Also, a lot of your statements are a bit out of whack. FEMA's funding was cut directly, but they assumed a much larger budget of control: they were placed in control of emergency coordination, not so much being on the ground themselves. This was somewhat difficult on account of the "on the ground" locals being complete dipshits and insisting everything was OK prior to the storm, even though it was not. It took time to respond because they needed to bring in help from outside, as can be expected.
Slashdot Mirror
... vs. an integrated home-brew system capable of playing DVDs, ripped DVDs, surfing the Internet, GPS tracking, listening to MP3s, etc. for right around $550 (and about $120 if you want to add a second head for multiple viewers).
The tech for this is cheap. Very cheap. Doing it yourself is pretty trivial: small Atom system with disk = under $200. DVD = $20. Smaller LCD = $100 (whether it's a 7" touchscreen or a 19" widescreen). GPS and WiFi (or WiMax)/cellular card = $100. Software = another $150 or so, depending on what you want (if anything).
Honestly, for in-car viewing, I don't really see what this iPad offers over a normal laptop or netbook. It costs more? That's hardly a selling point. And I can see kids quickly bitching about having to hold the iPad to watch a movie.
It largely depends on the child. More active children are a nightmare on a long trip, particularly if you've got two of them. I've found a car trip is easily 3-4 times more difficult with multiple children than it is with just one - even if you've got a second adult to help. A single child is pretty easy to handle, really (provided they're over the age of 2).
The problem isn't even so much keeping the kids engaged; it's keeping them engaged and not causing trouble. When you're driving on a busy interstate, the last thing you need is to be hit in the back of the head with a flying toy or have your blood curdled by a scream.
Do you have children? Have you taken a long car trip with them?
An hour in the car is a long time for kids. A very long time. When I was a kid, we'd take a 5-hour trip once a year to visit my grandparents: my dad would pack the minivan early, go to bed early, and then wake up at 4am to start the trip. Hed bundle us up (it was usually Thanksgiving/Christmas time, and cold), and package us in the van, hoping we'd stay asleep until we got there. Even still, we were awake for 2-3 hours of the trip each time, and it seemed like an eternity.
I've taken several long trips with my kids (and my definition of 'long' is slightly longer than the measly 5 hours): I've done a 2-day 1800 mile trip with them and my wife in a Ford Focus. (Yes, it sucked.) There would have been no way to get through the trip in anything less than 4 or 5 days if it wasn't for having a laptop with movies on it. Yes, we gave them books, and when we weren't shift-sleeping (one person would drive and the other would sleep), we were reading books to them, playing games with them (I spy, I'm thinking of..., stupid songs, etc.), and talking with them.
The general rules with kids on a long trip is "if they're in touching distance, they're fighting. If they can see each other, they're fighting." Either that, or they're playing (loudly). It makes any sort of driving difficult.
Leave it to a (probably) childless person to criticize parents for something like this.
Absolutely. Every once in a while there's an article of interest - maybe one or two a day - but compare it to the slashdot of 10 years ago:
* lots of stuff on matchbox PCs
* generally cool wearables and project sites
* good space articles
* the occasional link to esoteric HOWTOs and "look what I did"
* links to fun/interesting/cheap hardware (today, we'd have links to the latest/greatest dual core Atom boards and interesting/cheap ARM boards, per chance)
* cryptography, weapons and communication tech
* indepth insights about archeology
* start-up companies with something interesting/innovative/fringe improvements
* crazy benchmarks on overclocked hardware and esoteric/fringe/interesting setups
Of course, we had the Hellmouth self-sympathizing crap back then, too. But still! Maybe tech in general was cooler a decade ago than it is now, but it seems that 2/3 front page postings on /. these days is something about Apple, new product news releases, corporate purchases and dealings, rumors, and generally un-geeky things which only impact us in a cursory fashion.
Just take a look at slashdot from today in 2000. And that was after Slashdot already started to suck.
Slashdot was more interesting before it started shilling Apple nonsense, to be sure.
This is something I've been thinking about lately. Obviously, good design dictates that we use a separate app and db server for performance reasons (as it is usually more responsive). However, what about separate purposes (app server, db server), each running in its own VM on the same host? It's something I'm hoping to implement at a not-too-distant time to test.
Put simply: which would you rather have servicing millions of small, distributed requests?
a) thousands of 2.8GHz multicore Intel platforms using large amounts of electricity and heat
b) tens of thousands of 800MHz multicore ARM systems using much less than 1/10th the power of the Intel platform, producing significantly less heat?
The answer - to me - is pretty clear. The bottleneck to implementation is the software.
Mod this up.
Also: don't use a stupid book that teaches someone how to use "RedHat" or some other such thing. Those people generally have no understanding of existential things like:
* cron /etc except apache, etc.
* init
* the kernel
* much of anything in
* LSB directory structure
Honestly, I'd like to see a college course where they take someone from "I've tooled with Linux on the side" to "I've rolled my own distribution for esoteric custom-purpose hardware and turned it into a functional single-use system". It should be part of every CS curriculum; maybe make it a 200 or 250 level, and throw them to the wolves ("get going - and you can work alone or in teams, but everyone must account for their own work").
I'm a strong believer in immersion as the best way to instruct people how to do things.
Probably the best way to go about it would be a VM disk image file sitting on the flash drive itself. Dealing with the actual flash drive might be problematic due to compatibility.
For the virtualization, I'd probably just go with the Open Source version of Virtualbox. It can be run as a server for the lab (if need be - though not advised),
The biggest problems with going with USB flash drives are speed and compatibility, in that order. Flash drives are still very, very slow compared to a hard disk: it will jade their opinion of the operating system due to very sluggish writes (particularly due to the virtual disk allocation on top of the flash). There are also a number of limitations with the flash drive standardization themselves, as many are utter crap. Best to verify the make/model of flash drive you pick works. (Caveat: note that vendors -very frequently- change the underlying chips in the flash drives within a single model. Expect to have to buy them in lots.)
Honestly, given the cost of external hard disks, the lack of flash drive consistency, and your stated apparent requirements of them being able to use their own systems as well as the school lab, you might want to make a USB hard disk a class requirement instead of a flash drive.
But: why stop there? Honestly. When I was in school, we had a lab. I had a laptop. I brought my laptop and did almost everything on my laptop in the lab - and this was way before virtualization became commonplace (VMWare existed, but just barely). There were very few classes where I needed to have anything other than what was on the laptop - Debian Linux. Students could come and use the labs at any time (though most did not, as they had their own computers which were better).
Seriously. This is 2010, not 1998. Assuming you're not offering this as an entry-level course (you shouldn't) and you'll have at least 2nd-semester CS students taking it, there's no reason to coddle them. Just set up a CentOS or Debian system and allow students to connect to it from the campus.
On top of that, encourage them to install Linux themselves and configure it from scratch. It'll be good for them. Make obscene recommendations, like Gentoo or (god forbid) Slackware. A certification isn't going to mean jack shit in the long run (except for maybe taking a job from someone more qualified who doesn't have the cert) if they're not intimately familiar with the material.
This, like the virtualization question the other day, is yet another instance of "virtualization is cool so I want to apply it". It's not appropriate for every scenario (and I'd argue this is one of them, due to the added complexity and potential for outside cases).
I said they were good products, not great. The marketing hype lives above and beyond the product.
MOD UP
I'm trying my damnest to stop from laughing and disturbing the office.
Thank you. I'm telling that story to my son tonight.
As someone else said, memtest86 and prime95 don't cover even a fraction of the CPU functionality.
A better test would be to compile something for a prolonged period of time for your architecture. Off the top of my head, the gentoo install CD might be a good choice for this: start from scratch and build up a kernel and userland for your architecture. In the process you'll be testing the whole system - RAM, CPU, and disk - to at least know there is not an apparent manufacturing defect (short of a drive/electrical failure 2 days later).
It probably comes down to cost.
If a printer has a 22ppm rate and has 64MB of RAM, you're not going to be able to print more than one or two larger print jobs at a time - particularly if they're RAW jobs. You'll need a print server for that, and you'll have a significant bottleneck before getting to the printer/the printer accepts the job. This leads to user agitation.
So, while 128MB costs $100 (at the time), a 40G disk costs roughly the same amount - and you can cache to disk with marginal overhead and provide a more seamless user experience than the RAM would provide - all while increasing how many jobs can be accepted to queue at a time.
If you let one of these Apple engineers off the hook for their crimes against humanity, then you've got to make exception for them all. It's a slippery slope. First, Apple engineers today; tomorrow, lawyers and political figures. That's a social travesty we can not allow.
Closed systems are a dime a dozen.
While I dislike Apple as a company, let's be fair. Not only are their products quite good (from both a technical and aesthetic standpoint), but they're able to continually change their game. Of the big companies out there, they're the only ones doing truly "different" things during the depression.
Oh, as for "dime a dozen"... seriously? There are how many open systems out there? Debian, Fedora, RedHat, CentOS, FreeBSD, NetBSD, OpenBSD, OpenSolaris - and all their derivatives. Maybe if you were talking hardware, I'd understand, but c'mon: that, if anything, differentiates Apple from the pack.
- Caimlas (I would never buy their products)
The need for firewalls in the first place would be negated if every operating system out there didn't ship with a substantial set of outside-facing services enabled. A network connection should always be considered to be a hostile, unsafe environment: you enable what you need, when you need it. Make the UI easy to do so, sure; but don't make it the default.
Yes, there are those outside cases. However, consider how many scenarios can be easily covered with an "exceptioned template".
Take IP tables, for instance. It typically goes something like this: Deny all, do NAT/masq from the inside, do traffic shaping/QoS, and finally allow specific ports/do specific port forwarding. It's formalistic and not all that complex, once you understand it - and it's largely linear, with most of the scripts following the same basics.
For 90%+ of scenarios, it would be easy to instigate a framework for transparent transport of rules between systems (homogeneous and maybe even heterogeneous ones) or automatically setting rules based on inside services. The problem with doing it, however, is that it would provide a negligible benefit over what's out there now (as firewall rules tend to rarely change).
The security ramifications of such an application seem like they'd be hit and miss, internally. Yes. you want to prevent hosts from talking to each other when they've got no reason to - though there are other methods for doing this in a cleaner, less granular/more centralized fashion (802.1q VLANs). It works better because, again, it covers 90%+ of conceivable scenarios with less configuration.
It all comes down to KISS. Sometimes firewall restrictions are appropriate; sometimes something else is. More often than not, though, people use what they know and misapply it for fear of not being able to grasp a new technology in time to properly implement it, and we end up with a gongshow.
It might work, but probably not if the soldier is a US soldier. More often than not, the guys shooting at them can't shoot for shit, and you'd be more likely to be hit due to inaccuracy variance.
You mean something like perl? Or maybe python?
My vote is for perl. It's more common in a "base install" than any other shell (in the BSDs and most Linux distros) and has a non-trivial amount of power. It's good at dealing with path and input permutations and you can interface it with pretty much anything. Hell, pcre came from perl, and that's used almost everywhere these days: it's got a lot of things right for the little that's wrong, at least in terms of being a good scripting language.
I avoid "shell" scripting (csh, sh, bash) if at all possible, too. The contortions necessary to do the frequently-necessary evaluations takes quite a bit longer, even with a chain of awk/sed/grep and the like. Unlike those languages, perl is entirely self-contained and does not have any system-specific oddities (eg. with a shell script, many system binaries are different and an option/parameter pair on one system might do something entirely different on another - or not work at all).
I realize perl can often (usually) be difficult to read. But for my purposes, it's good enough, because I'm a bit of a prolific comment writer as a matter of process.
Often, I find myself writing scripts dealing with tasks which are semi-automated: I need a couple variables of input to deal with variance, but for the most part it's a repetitive task.
What you're referring to is a batch script; that's good and fine, and I need those two. But that doesn't mean that interaction delineates a "script" from an "application".
Though, I agree on one thing: a script is a script. There's no need to throw a dialog on there unless it in some way cleans up your input/output code and/or makes parsing the input cleaner.
That definition also excludes a great deal of the artwork of history: anything dealing with religion, lust, beautiful women, political statement - and so on.
For some, emotional impact is key. A "sterile", though accurate drawing can never be art to them.
For some, technical skill is important. I know I've refused to call a lot of abstract works "art".
For others, social commentary or message is important. A pop singer is mere entertainment (the horror), but replace her lyrics about her boyfriend with ones about the hardships of poverty and she becomes an artist.
For me, two of those have to be met for me to consider it art; all three criteria have to be met for me to consider it "good art". Something like Michaelangelo's David? That's "good art" - for the Romans. To me, it's an artistically made statue and its cultural relevance is lost. It's a technical work I have never seen (first hand) and lacks the gravity required for what I view as "art". I'm sure if I were to see it in person, I'd consider it art - the location of a work is almost as significant as the work itself, in many regards (lighting, setting, etc.)
When someone says something like "games can't be art" I always come back to two examples of games-as-art:
* Max Payne
* Deus Ex
Yes, they are my favorite games. They are great games because they are great art - presenting convincing characters, immersive art (auditory and visual), and a well-written story. They are not "winnable" games in the traditional sense, though you can finish them: they have little variance in the actual storyline, regardless of how they are played. Even with the multiple endings of Deus Ex, it's no different than (say) a choose-your-own-adventure book or one of the many 'artsy' movies which do, in fact, have alternate endings.
While some would say that what separates a game from art is the fact that you've got to try at a game but art is more passive, I beg to differ. Compare them, if you will, to movies like Momento, 12 Monkeys, or Donnie Darko. These are movies you've got to think about to "get" - they're not passive movies. Likewise, artistry in drink (whisk(e)y, wine, and beer), music (Chopin, Mozzart, Pink Floyd, etc.) and the like often take effort on the viewer's part to fully appreciate. Much of great art can't be simply summed up in a moment as art; likewise, dismissing anything out of hand is somewhat jaded and small-minded. Those aren't characteristics found in a maven of the arts, though they probably are those of a skeptic or cynic.
Would Ebert say the same thing about computer generated models and animations? How about the CG characters in movies? If those can be considered art, why can not the whole they compose be considered art? Anything otherwise would be as if to say that the Pantheon and Colosseum of Rome were artistic, but the greater architecture of ancient Rome was not. But even though the whole of Rome was not cohesively designed and planned as a whole, many would consider it an example of artistry just the same.
If anything, games are, as a genre, more artful than movies due to the fact that they're much more interpreted by the player than a movie or book. They give you more options. Isn't interpretation half of what art is? And if we're going to judge art by the effort and genius involved in creating it, a great game is certainly on par with many movies.
Well, considering the Old Worlders appear to think that way about their neighbors and the US, it's hardly surprising that they'd assume we'd be doing the same.
No one blamed bush for Hurricane Katrina
Actually, they did. A lot of people said the Government, under Bush, used some sort of weather modification/seismic device in Alaska to change the weather patterns and push the storm directly towards New Orleans - because Bush and the Republicats hateses the Blacks.
Or some such rot. It was even on major broadcast a number of times in passing, and in quite a few printed sources.
Also, a lot of your statements are a bit out of whack. FEMA's funding was cut directly, but they assumed a much larger budget of control: they were placed in control of emergency coordination, not so much being on the ground themselves. This was somewhat difficult on account of the "on the ground" locals being complete dipshits and insisting everything was OK prior to the storm, even though it was not. It took time to respond because they needed to bring in help from outside, as can be expected.