The gist of article seems to be that for many tasks people should combine the powerful Unix standard commands like find, grep, xargs, sed, etc instead of writing dedicated programs in lower level languages such as Ruby, Python, Java etc. This idea is not new, and many of the people around here have heard it 15 or more years ago. Being a developer, I always liked the perspective of having to write lesser code.

However, the Unix command line and shell script approach never really worked for me, especially if other people in the team wrote them. The main reasons for that are:

• missing error handling (no checking for "$?", broken pipes, ...)
• lack of consideration for special cases such as file names with blanks in them
• difficult post-mortem analysis if the data causing an error got lost in a pipe instead of being available in an intermediate or temporary file
• possible configuration nightmare to get non-ASCII characters working (depending on the actual platform you're on; it can be easy, too)
• terse syntax with a tendency to "write only" code (which makes sense for a direct input command line but less so for code that should be maintained for years to come)

All of this could be overcome by measures such as checking $?, redirecting stderr, using temporary files, configuring encodings properly, documentation comments and so on. However, this rarely ever happens in practice.

For the past couple of years I have been using ant for many tasks formerly delegated to shell scripts. Its main advantages are:

• provides many standard tasks to copy/move/delete files, search and replace in files, filter files, download files, send mails etc.
• provides many ways to limit commands only to certain files depending on name, date, contents etc.
• most tasks fail on encountering any error and consequently terminate the whole script (though this can be disabled for a certain task if needed be)
• generic <exec> task to execute shell commands in case ant does not provide a standard task; you have to be careful with this one though and set failonerror="true" or it will continue even if it fails
• pretty legible due to using english words instead of abbreviations for most things
• many simple typos are already detected when ant parses your script and not only when a task gets executed.
• platform independent syntax for file paths so your script can work on Unix and Windows.
• takes care of all escaping and non-ASCII issues with files names.

Of course it's not perfect. For example, it uses XML and consequently contains some syntactic noise, it lacks advanced string operations, there are no pipes and sometimes seemingly trivial things result in a lot of messing around with properties. Nevertheless I rarely see a need to write shell scripts anymore except for simple launchers. YMMV but despite ant initially being a build tool for Java developers, we use it for many sysadmin-like tasks with great success and a small amount of development time.

If you want to know what is actually going on in a company, the 3 groups of people you need access to are the admins (who can watch people's computer use), the security guards (who can watch people's physical activities), and the bookkeepers (who know where the money and therefor the power is going).

In order to gain all this information, the only group of people you need access to are the secretaries.

Get a 27 inch at 2560x1440 and set the resolution to 1380x720

This should read 1280x720 obviously.

[D]oes this offer hope that someone might finally make a good movie based on a game IP?

A good movie based on MMORPG game IP has already been made: Ben X revolves around the game Archlord and the real life of some players. Think Rainman meets WoW.

I still have an Amiga 2000 standing around from 1989 with a 8 Mhz 68000 CPU and 7 MB RAM. Funny thing about it is that it can run the relatively modern AmigaOS 3.1, for which reasonably well working graphical web browsers exist. Occasionally I fire it for fun just to demonstrate that 80's hardware can show web pages in a semi decent way. Configure it to run on a 640x400 screen with 8 shades of grey and it still shows most of the modern web sites that have some sort of accessibility fall back. It can do tables and basic CSS, so in some cases the results are almost indistinguishable from what you see on a modern browser. Of course it is awfully slow and needs several seconds to render a medium sized PNG image.

It's particular cool to show it too kids that think you need GHz's and GB's to surf the web.

Reservoir Dogs is a remake of http://en.wikipedia.org/wiki/City_on_Fire_(1987_film)

According to the IMDB FAQ there seems to be some disagreement on this:

Is this film a remake?
[...] [T]here are clear similarities. Both films deal with a robbery, and feature a warehouse rendez-vous spot, a climactic Mexican stand-off, and the relationship between a veteran thief and an undercover cop, but Lung fu fong wan deals mostly with events leading to the robbery, while Reservoir Dogs is famously about the aftermath of an unseen heist gone wrong. [...] There are similar elements between the two films, but much of what makes Reservoir Dogs a classic - pacing, style, and some famous plot twists - is not present in Lung fu fong wan. Nevertheless, the debate has continued among some film fans.

Personally I can't think of any Tarantino movie I'd call "original" though some of them I find reasonably amusing.

Your eyes can only pickup 80fps anyway; you wouldn't know if it was 100 or 10,000 fps unless the fps counter didn't say.

[...]Gunny how that number keeps creeping upwards. First it was 24 FPS (because that was all the eye could see), then 30, then 60, now you're saying 80.

There are to different issues at work which are well documented in literature and backup up with experiments:

1. At a certain framerate, single images blur into an animation an can not be distinguished as single images anymore. This happens at about 25 FPS.
2. If you flash a single image for a short enough time, the eye and brain will not be able to recognize it anymore. While the brain decodes an image, it does not have to look at it all the time due to a "burn in" effect with the eye. Because of that, the time you actually see the image can be very short. Experiments with showing silhouettes of airplanes to fighter pilots yield that some of them could still distinguish certain planes even if they were flashed for only 1/200 of a second.

So 25 FPS are enough to make a game look basically fluid, but 200 FPS can be useful to process rough and basic information. For example when quickly rotating the view and scanning for the muzzle flash of enemies firing at you.

And, as others pointed out already, more FPS means less latency. As example consider a muzzle flash the game internally creates 1 milliseccond after you last screen refresh. At 25 FPS, you will be able to actually see it after 40 milliseconds, at 200 FPS it only takes 5 milliseconds. This give you 35 milliseconds more time to process the information. But you still lose 4 milliseconds compared to a system with 1000 FPS.

Granted these milliseconds might not matter much for casually playing a shooter, for instance I still enjoyed playing Doom at about 20 FPS on an upgraded Amiga 2000 back then. But for competitive gamers these milliseconds might just be the edge they need to win some price money.