Movie Round-Up: January 5, 2004

Monday January 05, 2004 @ 04:27 PM (PST)

You all probably know by now that I generally watch a dangerously huge number of movies during any given week. Since I love talking about movies almost as much as I love watching them, I’m going to start collecting my thoughts about the movies I’ve seen and posting them here as a weekly feature.

I won’t be giving these movies a rating in stars like most reviewers do. Instead, if I think you should watch a movie, its title will have a green background. If I think you should avoid it, it’ll get a red background. Nice and simple. I also won’t go into detail about plots or characters, but all of that is available from the IMDB by clicking on a movie’s title.

Now, on to the movies:

Barry Lyndon (1975)

Like most of Stanley Kubrick’s films, Barry Lyndon sets the benchmark for the genre — in this case, the epic period drama. The cinematography is so beautiful I felt like I was watching a painting. Thankfully, the writing, acting, and even the music (which I’ve often found to be lacking in Kubrick’s films) were all top-notch as well, so this movie is no one-trick pony.

Being There (1979)

This movie demonstrates why Peter Sellers was one of the best film actors of all time. His performance is unsettlingly good. While the story seemed a little strained, the solid direction and Sellers’ brilliance make this movie very much worth seeing. At times, I wasn’t sure whether it was trying to be a farce or a more serious political and social satire, but things became clear by the end.

Below (2002)

Much better than I expected it to be. Below is both a good submarine movie and a good supernatural thriller, and it maintains just the right balance of realism and fantasy to make the story fun. It also doesn’t take itself too seriously, which is always a good thing in this sort of movie.

Chopper (2000)

Gritty and violent, but with the sort of twisted humor that’ll appeal to you if you liked Pulp Fiction or Reservoir Dogs. The biggest surprise about this movie was Eric Bana’s excellent performance.

CQ (2001)

Hilarious. Manages to spoof campy sixties sci-fi while satirizing the film industry and even sneaking a few touching moments into the cynicism. Jeremy Davies and Jason Schwartzman need to be in more movies, dammit. Roman Coppola’s direction has solidified my belief that the Coppola family must have some kind of genetic trait that makes them all good directors.

Harry Potter and the Sorcerer’s Stone (2001)

I still haven’t read the books, but hopefully they’re better than this movie was. The story seemed to be one big long introduction to the characters and the world, with a hastily cobbled-together conflict arising just in time to make the movie uncomfortably long. Chris Columbus’s uninspired direction didn’t help, nor did the painfully overdone special effects, which stuck out like a sore thumb. Even the score was annoying; it seemed like John Williams was being too John Williamsish, if that makes any sense. I guess what hurts worse than anything is that there’s this constant undercurrent of potential greatness, but it never quite makes it to the surface.

Last Night (1998)

Ouch. This was painful to watch. Not just because of the obviously low budget and the fact that it’s only available in pan & scan, but because the plot plods along and seems to do its best to defy your attempts to guess where it’ll go next, while falling too often into silly sentimentality and angsty, unconvincing philosophizing. It’s not all bad, though. Sarah Polley has a minor role, and any movie with Sarah Polley in it can’t be all bad.

The Man Who Wasn’t There (2001)

The Coen brothers have never made a movie I didn’t like. This one’s no exception. It’s got the trademark twisted Coen humor, the quirky characters, and above all the incredible visual style. This is the most beautifully-shot black and white movie I’ve ever seen, which I feel a little silly saying, since it was actually shot in color.

Moulin Rouge! (2001)

Wow. This movie was brilliant. I ignored all the fuss about this one when it came out, but now I wish I hadn’t. I’m generally not a big fan of musicals, but this was something on an entirely different level. Instead of being annoyed every time someone broke into song, I found myself being annoyed when someone failed to break into song. This is the most visually and aurally pleasing movie I’ve seen in years. Watch it. Watch it now.

Roger Dodger (2002)

It pains me to say this, since the chances of me getting a date decrease every time any woman sees this movie, but it’s a good movie. I usually can’t stand the whole low-budget shaky handheld camera thing, but it’s used to good effect here. The best thing about this movie, though, is the dialog, which just crackles. It’s the kind of dialog Kevin Smith likes to think he writes, only Dylan Kidd does it better than Smith ever pretended to, and with a lot more maturity.

Stranded (2002)

Do not watch this movie. I don’t care if you think you like bad sci-fi. This isn’t just bad sci-fi. This is bad on so many levels it’s not even worth watching to laugh at how bad it is. The only good thing about this movie is that most people have never heard of it, and hopefully it will stay that way. When clouds are clearly visible in almost every single external shot of a movie that’s set on Mars, you know the filmmakers just don’t give a shit. If I thought I could do it without getting caught, I’d kill every actor in this movie and then beat the writer and director to death with their bloody corpses. For the love of God, do not watch this movie. If you want a good bad movie about Mars, watch Mission to Mars, Red Planet, or even Robinson Crusoe on Mars.

Comments

I see no red. I see no green. I am not supposed to be color-blind.

Your evil browser has cached the old stylesheet. Reload.

The Wonkrix Reloaded - another movie review in the offing? Was it better in black and white?

Hey, that was not my evil browser. I was at home, with Mozilla, so neener.

I see red. I see green. I am supposed to be red/green color blind. What's up with that?

So here's a question:
If someone is supposed to be red/green colorblind, how would they know what red and green look like if they see them?

Exactly my point. It's like saying that if you haven't got 20/20 vision, you're blind. If someone has no color vision whatsoever, they of course cannot tell the difference between red and green. Everything would be - well, gray, I suppose, just like in low light conditions, very faint light reds and light greens seem gray to me. But oh no, my color vision isn't just slightly below normal; I'm color-blind!!!1!

Of course, it's also a fascinating question. I believe there /are/ some people who really can't see the difference at all. So the question is twofold; how do you describe green and red so that someone understands them (and could you describe them to a completely blind person?) and secondly, frighteningly, how do you know that what you think of as "red" is red? As long as your eyes don't perceive two things that people usually differentiate as the same, there is NO way of knowing for sure that what you see is the same as what others see. It's completely subjective. And scary.

Yes, there is no guarantee that different people experience the input from their senses in the exact same way. In fact, it is highly unlikely that they do. Take a simple thing as your taste in music, for instance. ALthough that to a great extent is dependent of your personality and temperament, some people find beauty in music that others perceive as unharmonic and noisy. Some people love the sound of cymbals, while others detest it. Clearly, the same sound, color, shape, texture or taste must be perceived very differently by different people. We do, however, all share a common set of concepts, which is what 'red' and 'green' really are. They are words describing a particular type of sensory stimulation; a way of discerning between different stimuli. All we verifiably have in common is definitions of concepts, and that's really all we need in order to communicate on a meaningful level. Hence, language is what makes all the difference. It is what sets us apart from animals, who are unable to share concepts on the level at which we do. What our true perception is actually like doesn't really matter, for without language and concepts, we would still be unable to compare those perceptions. When you think of it, it becomes clear that our differences in perception obviously play a very important part in our differences regarding preferences. Individual taste.

What still boggles me, however, is that with all our present knowledge in the fields of life sciences, there are still only types of color vision impairments, but no gradients. Since certain professions require (often unnecessarily, I might add) a certain level of color recognition capabilities, being stamped as color-blind at the slightest abnormality of color vision seems excessively judgmental, not to mention absurdly misinformed.

It's not the browser's fault. Mozilla's cache is pretty well-behaved. If you don't want the stylesheet cached for all eternity, then you ought to employ cache-control headers with your stylesheets.

Well, you could turn your CSS pages into PHP, send the cache-control headers, and set the content-type to text/css.

You could also use the and Header directives in .htaccess to send cache control headers for specific files, all .css files, or all files in a directory.

Sections 14.9 and 14.32 of RFC 2616 specify headers relevant to cache control.

The short version is if you send the headers:

Pragma: no-cache
Cache-Control: no-cache

then HTTP 1.1 compliant proxies and user agents must not cache the response. More fine-grain control is possible as well (with Cache-Control, not the HTTP 1.0 holdover Pragma).
I was hoping you knew a way of doing it without resorting to nasty tricks. Making the CSS dynamic would increase the burden on the server for very little gain.

An .htaccess file or global Apache directive wouldn't be so bad, but then again, I only rarely change the stylesheet. If I tell browsers not to cache it, that increases the load time of the site and the burden on my server.

Browsers should be intelligent enough to notice when a file changes. It's not hard. In fact, the HTTP spec makes it extremely easy to compare both the timestamp and the size of a file with a minimum of network traffic. I could understand a browser ignoring a difference of a few seconds and only one byte, but the changes I made amounted to a difference of at least several months in the timstamp and several hundred bytes in the file size.

From a usability standpoint, it also doesn't make any sense at all for the Refresh command to reload the cached page. I can already see the cached page. Why would I want to see it again? For fun? The only possible reason for clicking the Refresh button is to get a refreshed version of the page. That should be the default behavior. If, for some screwy reason, I'm feeling redundant, I'd be perfectly happy using Shift-Refresh to reload the page from the cache.

The Cache-Control header allows for aging, as well as simply no-cache. You can send, for example:

Cache-Control: max-age=120

and browsers will ask the server if there have been any changes if their copy of the file is 120 seconds old, using a conditonal get request (by sending the If-Modified-Since request header).

If there are no changes, then you don't have to send the whole file, just a response saying "yes, you're up to date" (304 Not Modified). So the bandwidth costs are minimal, and people will see fairly up-to-date stuff.

I seriously doubt your server will be significantly strained by each active reader making a 100 byte request and recieving a equally small response once every two minutes.

I mean really, your load average is zero. How worried can you be?
From a usability standpoint, it also doesn't make any sense at all for the Refresh command to reload the cached page. I can already see the cached page. Why would I want to see it again? For fun? The only possible reason for clicking the Refresh button is to get a refreshed version of the page. That should be the default behavior. If, for some screwy reason, I'm feeling redundant, I'd be perfectly happy using Shift-Refresh to reload the page from the cache.
I think that's what the shift-reload combination did in the early days. I'm not sure how it's implemented today, though...
Ah, I wasn't aware of the max-age feature. I'm still perplexed as to why browsers don't check a file's age by default, though. As you said, it's not like bandwidth is an issue.

Oh, and there's a reason my load average is usually near zero. It's because I'm careful about not putting unnecessary load on my server. ;)

Often times, a server under heavy load will have trouble responding to even the simplest request. From the client's point of view, it is better to serve up cached pages without checking them than waiting five minutes for a slow server to verify that they're still fresh.

If your server were actually resource constrained, it might be a problem (for the clients). But it's not.

I have a sneaking suspicion that processing power will never be the limiting factor on your server. Your bandwidth will give out first.
Actually, back when the Uptimes Project was in full swing processing power was indeed the limiting factor. Despite the thousands of machines reporting uptimes every few minutes, bandwidth was never a problem due to the very small amounts of data being transferred (although it did lead my ISP to believe I was being DOSed on several occasions).

It was the strain on the database and on PHP (which generated the pretty graphs) that was the problem. Each uptime report required several database operations (check that the host exists and is valid, determine whether this report is a continuation of an old uptime or a reboot, update the database accordingly), and on top of that there were some pretty intense statistics being generated on the fly. And the database got pretty huge.

Granted, if I had simply been serving a static website without any database goofiness, bandwidth would have been the limiter. But with dynamic sites, especially sites as dynamic as that one, processing power is more and more important.
But we are, after all, talking about stylesheets.

It would surprise me if you couldn't improve the database performance by tweaking your queries/physical schema a bit and maybe adding RAM. Are you sure disk IO wasn't the limiting factor, rather than CPU time?
I've implemented some basic caching on the site I am currently running. As a result, most of the pages require no queries, so I'm not expecting to hit a database bottleneck anytime soon.

The MySQL wrapper I use already returns data in the form of an object, so all I have to do is serialize() that object and save it to a file. Later, when I need the same query, I just grab that file and unserialize().

And yes, It's much faster.

Copyright © 2002-2012 Ryan Grove. All rights reserved.
Powered by Thoth.