This is a simple, open standard that can eliminate spam from forged domains, which I would guess is most of it, at this point in history.
Just for the record... SPF is not anti-spam, it's anti-forgery. Which are admittedly overlapping problems.
Where SPF excels is:
- Blocking e-mail from an IP address that fails an SPF check. A good use of the system, but it probably won't block a ton of spam (spammers just create bogus domains with very loose SPF records).
- Eliminating bounce messages that are sent to a domain that doesn't care. Bounce messages are not free (they use up outbound bandwidth and CPU) and can be used as a DoS. If an e-mail fails the SPF check there's no point in sending a bounce message back to the source. Odds are high that the mail was forged.
I'll be on cloud nine if mail server admins ever figure out the 2nd point. For the domains that I administer, we have very strict SPF records published (and our users are aware). Our firm is small enough to make such a mandate work. I keep my SPF records on a short TTL (half a day) so that we can adjust them fairly quickly if an unforseen situation arises. But we also have encrypted SMTP/POP3 access for our users along with VPN access to the mail server. Plus encrypted webmail and encrypted IMAP ports. Which eliminates any reasons not to use our official mail servers for outbound e-mail.
(Yes it breaks forwarding and other semi-legitimate uses for domain forgery such as greeting card sites. But so far that's been a complete non-issue for us.)
A big one a lot of people don't like and I've never been sure why: 95%+ of all messages where the domain in the 'To:' doesn't match the DNS domain of the IP address in the 'X-Originating-IP:' line are SPAM. So just reject them ALL. SPAM problem solved. Whiners will be executed on site.
That doesn't work for situations where the mail server hosts multiple domains on a single IP address. Which is a very common situation for all but the few hundred largest organizations. Everyone else typically shares space on a mail server (or they have a mail server configured to handle multiple domains).
While you can technically assign multiple PTR records for an IP address, it doesn't work well in practice.
Interesting... I hadn't realized there were such things.
One question. How does the PostgreSQL IP4 (and other) data types map to more traditional types in more limited databases? What does the field type appear as if I attach via ODBC from MS Access?
I'll agree with that. From what I've seen over the years, the PostgreSQL folks are pretty big on "never lose data" which is what correctness and attention to detail gets you. It may not have been the fastest database to use, but I don't have to worry that it's doing something incorrect under the covers for the sake of speed.
The only thing holding us back from using PGSQL prior to v8 was lack of good Win32 support. (While we're moving towards Solaris/Linux, it will still be a few years before we retire all of our Win32 boxes.)
The other reason I prefer PostgreSQL over commercial offerings is that it's one less set of licenses that I need to track. (Yay!)
This is one of those areas where I feel that AMD was about 2 (3?) years ahead of Intel.
They came out with a 64bit CPU that, unlike Itanium, performed just as fast on 32bit tasks as the predecessor. Which meant that buying AMD 64bit chips was a no-risk decision. You could get a 64bit chip (future-proof) but without sacrificing performance on existing 32bit workloads. I don't know if it was an engineering or marketing decision, but it was an important one.
Imagine a world where Intel's Core 2 was the first 64bit chip for x86. It would've pushed the move to 64bit back to 2010 instead of possibly happening as soon as 2007.
(Not sure when the 64bit Xeon CPUs first hit the market. We've been buying all Opteron systems.)
One problem with specialized chips (or specialized silicon) is that you're always at least one step behind the state of the art. Sure, you've got silicon to help with DES processing... but oops, we've all moved to AES now!
Now, I can also think of a few examples where that's not true, such as:
That pretty much covers it for me. I've watched them repeatedly stick their noses into various projects over the years, only to subvert them or extend them in incompatible ways (that usually result in security problems).
Either they're arrogant enough to think they know better then the original designers of the protocol. Or else it's a corporate mandate to be slightly incompatible in order to break the standard.
Too much focus on control, not enough on true interoperability and competing on merits.
I'd rate them as 2nd tier still. Their prices for LCD TVs were about 20% cheaper then Sony and other name brand TVs last year. OTOH, I have a Samsung DVD player that I'm not very pleased with at all.
They're better then they were a few years ago, but their quality and product design is still missing a few beats.
30MB/s sustained for a laptop is very impressive. (My 4-year old unit only gets about 6-10MB/s with 5400rpm 120GB drives.)
But yes, 7200rpm 750GB SATA drives are in the 50-75MB/s range. Then you toss those into a 6-drive RAID10 array for rates in the 150-225MB/s range. (Size to fit your need...)
I guess the big advantage of flash drives isn't going to be so much their sequential speed, it's going to be the throughput they can maintain in a random access environment. Which should perform a lot better then a single-spindle magnetic drive.
When I was 100% telecommute I was always terrified I would be promoted and given responsibilities that required me to travel, or else, forced to relocate to a main office.
I think telecommuting works better for small, regional level firms in that regard. I don't worry about promotions, because the only person above me is the CEO. I don't worry about feeling unvalued, because I talk to the CEO about once a week about issues.
There's also a lot less organizational nonsense.
The downside of small firms is that they often live quarter to quarter. So things may not be as secure over the long-term.
If this means Firefox will have decent support for higher dpi displays, then I just might jump at it once it goes Beta.
I think the only way to do it is to zoom the entire page (including images). Which I hear is something that Opera does and I know the Avant Browser does. Scaling one without the other only works if you're going up/down by about 5% (maybe 10%). Beyond that, page layouts start getting funky and you'll have text that overlaps other screen elements.
I have a higher DPI display as well (125dpi) and even with using the "minimum font size" settings, it still causes more issues then it fixes.
4. When one tab is 'busy' (opening a PDF, for example) the entire browser window freezes. This is a tough one, I understand, but not impossible.
This is the one that absolutely drives me crazy. I'm a heavy tab user, loading a lot of stuff into background tabs while I work in the foreground tab. Every time I go to open a page in the background I have to WAIT on a tab that I'm not even looking at. Gee, I thought the whole point of loading something in the background was so that it wouldn't interfere with what I'm doing in the foreground.
I should dig up my old 0.5 or 0.6 versions and see if they had that misbehavior. It seems like they broke something in 1.5 (and left it broken in 2.0) where the UI blocks on network events.
If not, maybe it's time to go look at IE7 or Opera and see if they're less braindead about blocking the UI.
Of course, if a disk gets a read error in the sector holding the FAT, I'm toast.:-)
Maybe not. PAR2 files store the filenames as part of the recovery data. As long as the TOC track (innermost track) isn't kaput, you can recover the data even if both the UDF and older 8.3 file tables are blitzed. If the TOC is busted, you'll have to get a professional DVD reader or go to a recovery service.
(The "how to" is over on the QuickPar forums. Basically, you rip the disk at the sector level to a pair of files. Rename the one with a PAR2 extension, then feed it the 2nd file as source data. QuickPar will find all of the data blocks and reconstitute the original files.)
If it's stuff that I found on the web, and could probably dig up again if I had to, then it's no worry to burn a single copy and put 10% PAR2 data on the same disk. From my experience, the odds are very slim (1:500), that I will encounter errors trying to read the disk after a few years. And even when I do encounter errors, I can put the disk into a 2nd machine and pull the missing bits off. Or else, I only end up with about 1% damage which is easily repaired by the 10% parity data that I put on the disk.
(Again, the whole advantage of parity data is that it gives you a recovery window. If you test regularly, at a higher frequency then the disk is failing at, you can catch errors early enough to repair. If you want a lower frequency of testing, then you should put more parity data on the disk. Maybe 20-25% of the disk devoted to parity data. If you are less concerned, you can get away with 2-5% parity data.)
For more important stuff: That always ends up spread across multiple archival snapshots before it is permanently removed. For example, I'll backup up the previous 6 months of data every month. Which means that a single piece of data should end up on at least 5 of the disks. The PAR2 data on each disk is more of a time-saver and double-check. Just enough PAR2 data to recover from minor scratches / blemishes and I can use the PAR2 data to double-check the disk health.
If I'm doing a very large snapshot (say when I image my laptop HD) and don't want multiple copies... Let's say I have 8 disks worth of data in the snapshot. I'll spread it across 10 disks. The 10th disk will be 100% PAR2 data. Disk 1-9 will be 89% data and 11% PAR2 data. Which I think works out to 2 disks (25% parity) worth of PAR2 data. I can lose an entire disk out of the set without worrying.
Also, some version control systems only store the diffs of binary files (such as Subversion).
Which makes it efficient enough that we don't worry much about what we store in our Subversion repository (as opposed to older, dumber systems that stored a fresh copy of binary files for each commit).
Aye, I have the Epson Stylus Photo R200 and it's worked well. It uses separate cartridges for each color (6 total, including black).
The only issue that I've had with mine is that the CD tray will not automatically feed into the unit. I have to stand there putting a little inward pressure on it to get it to feed properly. Once it feeds, it's good to go and works just fine.
Heat is an issue, and if you store them on your dashboard, you deserve what results.
I have MP3 CD-Rs in my car from 2001 that have either been up in a visor holder or stored in a door compartment. I live in Pennsylvania (to give you an idea of the weather extremes). Now, they weren't in direct sunlight, which probably helped. But you figure they still ran the temperature range of 0F up to 120F.
I think I might've had trouble with one or two disks over the years. But since they're MP3 CDs, I just re-copy them from my central storage (or else I backed the disks up to DVD-R which I keep in my house).
Don't know if the ones I bought were counterfeit, but at least they came from MWave. (Where I'd think it would be unlikely that they'd sell grey-market goodes.)
I tend to buy the 100/pack, tape-wrap, inkjet printable. As long as you have some empty cake boxes around to transfer them into, the tape-wrap style works fine.
You're a bit on the high side there... SATA/PATA drives are down around $0.28-$0.32 per gigabyte and have been for a while. The sweet spot seems to be the 250GB drives for $70, with the 200GB, 300GB, 400GB sizes at around $0.32/GB.
(Which hasn't changed a whole lot in the past few months. But Seagate's 7200.10 series is one of the cheaper $/GB drives on the market even though it's brand new tech.)
A three-year-old computer is obsolete as a gaming machine in terms of CPU and graphics power... consoles are the same way.
That was true (for PCs) up until around 2001-2002. Then things stalemated and a 3 year old machine is still plenty powerful as a gaming machine. (My game system is a 2GHz Opteron with the last possible AGP card, GeForce 7800GS. I reckon I won't upgrade that system until 2008 at this rate.)
Why would they need to do that? For most positions that companies would consider allowing telecommuting for, I think it's reasonable to expect the employee to have their own computer. Just don't bother them about having porn on the same computer they do work on.
If you allow the employees to supply their own machine, who is on the hook when it doesn't work? Can you discipline an employee for buying sub-standard tools that are required to do their job? Who pays for the software? Who pays for the court costs if pirated software is found (probably the employee).
The closest corollary I can think of is mechanic's tools. Mechanics supply their own tools (I think) but I think there are also monthly allowances for the replacement/purchase of new tools.
Personally, I draw the line based on whether the person is a contract worker (paid hourly or piece-work fashion) or a salaried employee. For salaried employees, we supply the hardware and software just as we would if they were in the office. For contract workers, they're required to have their own tools.
That technology was around back in 2000? I'm pretty sure that NASA was talking about using it to stitch together multiple frames from a video clip to clean up / enhance a section of the frame.
Too lazy to go looking right now though.
There's another instance on CSI (or one of the others) where a suspect goes into a pawn brokers shop to buy up some piece of evidence prior to the police finding it. On his way out, he ducks out the side of the frame and touches something before leaving the shop.
So... they grab the tape and look at what is supposedly the "overscan" area of a 4:3 NTSC signal. Darned if that full-framed image didn't look like a 16:9 HDTV frame.
I mean, we're not talking an additional 10-20 pixels of information that wasn't shown on the original screen... we're talking looking at stuff that was 3 counties away from what a 4:3 NTSC camera would record.
For example, I've read several sci-fi novels (Stephen Donaldson's Gap series being a favorite) that depict space combat occuring at realistic ranges -- ranges where even using light-speed weaponry it takes several minutes to reach the target. In a novel, the tension of having to wait minutes to know if you scored a hit works whereas in a movie it would be boring as hell.
See also the Chanur Saga (3 books rolled into one followed by a 4th separate book). C.J. Cherryh does a good job of dealing with the fragmentary information of battles using beam/missle weapons over a large area.
A very noteable exception -- or maybe not since it isn't Hollywood but what you're saying is common of action movies from everywhere -- being The Seven Samurai. Everyone who uses a sword in that movie uses it to kill, and as a result most sword fights are one or two strokes long. While lacking the acrobatic beauty of a good ten-minute lightsaber duel, it did have a gritty reality that just felt right.
Ah sweet... The Seven Samurai just arrived in my mailbox today.
Now to find time in my busy admin schedule to view it. Maybe I'll recompile the Xen kernels a few times...
Slashdot Mirror
This is a simple, open standard that can eliminate spam from forged domains, which I would guess is most of it, at this point in history.
Just for the record... SPF is not anti-spam, it's anti-forgery. Which are admittedly overlapping problems.
Where SPF excels is:
- Blocking e-mail from an IP address that fails an SPF check. A good use of the system, but it probably won't block a ton of spam (spammers just create bogus domains with very loose SPF records).
- Eliminating bounce messages that are sent to a domain that doesn't care. Bounce messages are not free (they use up outbound bandwidth and CPU) and can be used as a DoS. If an e-mail fails the SPF check there's no point in sending a bounce message back to the source. Odds are high that the mail was forged.
I'll be on cloud nine if mail server admins ever figure out the 2nd point. For the domains that I administer, we have very strict SPF records published (and our users are aware). Our firm is small enough to make such a mandate work. I keep my SPF records on a short TTL (half a day) so that we can adjust them fairly quickly if an unforseen situation arises. But we also have encrypted SMTP/POP3 access for our users along with VPN access to the mail server. Plus encrypted webmail and encrypted IMAP ports. Which eliminates any reasons not to use our official mail servers for outbound e-mail.
(Yes it breaks forwarding and other semi-legitimate uses for domain forgery such as greeting card sites. But so far that's been a complete non-issue for us.)
A big one a lot of people don't like and I've never been sure why: 95%+ of all messages where the domain in the 'To:' doesn't match the DNS domain of the IP address in the 'X-Originating-IP:' line are SPAM. So just reject them ALL. SPAM problem solved. Whiners will be executed on site.
That doesn't work for situations where the mail server hosts multiple domains on a single IP address. Which is a very common situation for all but the few hundred largest organizations. Everyone else typically shares space on a mail server (or they have a mail server configured to handle multiple domains).
While you can technically assign multiple PTR records for an IP address, it doesn't work well in practice.
Interesting... I hadn't realized there were such things.
One question. How does the PostgreSQL IP4 (and other) data types map to more traditional types in more limited databases? What does the field type appear as if I attach via ODBC from MS Access?
I'll agree with that. From what I've seen over the years, the PostgreSQL folks are pretty big on "never lose data" which is what correctness and attention to detail gets you. It may not have been the fastest database to use, but I don't have to worry that it's doing something incorrect under the covers for the sake of speed.
The only thing holding us back from using PGSQL prior to v8 was lack of good Win32 support. (While we're moving towards Solaris/Linux, it will still be a few years before we retire all of our Win32 boxes.)
The other reason I prefer PostgreSQL over commercial offerings is that it's one less set of licenses that I need to track. (Yay!)
This is one of those areas where I feel that AMD was about 2 (3?) years ahead of Intel.
They came out with a 64bit CPU that, unlike Itanium, performed just as fast on 32bit tasks as the predecessor. Which meant that buying AMD 64bit chips was a no-risk decision. You could get a 64bit chip (future-proof) but without sacrificing performance on existing 32bit workloads. I don't know if it was an engineering or marketing decision, but it was an important one.
Imagine a world where Intel's Core 2 was the first 64bit chip for x86. It would've pushed the move to 64bit back to 2010 instead of possibly happening as soon as 2007.
(Not sure when the 64bit Xeon CPUs first hit the market. We've been buying all Opteron systems.)
It screams Wiki to me to... until the Wiki server is offline.
How do you handle documentation that is stored on a centralized bit of storage that may be inaccessible when the documentation is needed?
Are there distributed wikis?
One problem with specialized chips (or specialized silicon) is that you're always at least one step behind the state of the art. Sure, you've got silicon to help with DES processing... but oops, we've all moved to AES now!
Now, I can also think of a few examples where that's not true, such as:
- SSL co-processors
- TCP off-load engines
Embrace, Extend, Extinguish.
That pretty much covers it for me. I've watched them repeatedly stick their noses into various projects over the years, only to subvert them or extend them in incompatible ways (that usually result in security problems).
Either they're arrogant enough to think they know better then the original designers of the protocol. Or else it's a corporate mandate to be slightly incompatible in order to break the standard.
Too much focus on control, not enough on true interoperability and competing on merits.
I'd rate them as 2nd tier still. Their prices for LCD TVs were about 20% cheaper then Sony and other name brand TVs last year. OTOH, I have a Samsung DVD player that I'm not very pleased with at all.
They're better then they were a few years ago, but their quality and product design is still missing a few beats.
30MB/s sustained for a laptop is very impressive. (My 4-year old unit only gets about 6-10MB/s with 5400rpm 120GB drives.)
But yes, 7200rpm 750GB SATA drives are in the 50-75MB/s range. Then you toss those into a 6-drive RAID10 array for rates in the 150-225MB/s range. (Size to fit your need...)
I guess the big advantage of flash drives isn't going to be so much their sequential speed, it's going to be the throughput they can maintain in a random access environment. Which should perform a lot better then a single-spindle magnetic drive.
When I was 100% telecommute I was always terrified I would be promoted and given responsibilities that required me to travel, or else, forced to relocate to a main office.
I think telecommuting works better for small, regional level firms in that regard. I don't worry about promotions, because the only person above me is the CEO. I don't worry about feeling unvalued, because I talk to the CEO about once a week about issues.
There's also a lot less organizational nonsense.
The downside of small firms is that they often live quarter to quarter. So things may not be as secure over the long-term.
If this means Firefox will have decent support for higher dpi displays, then I just might jump at it once it goes Beta.
I think the only way to do it is to zoom the entire page (including images). Which I hear is something that Opera does and I know the Avant Browser does. Scaling one without the other only works if you're going up/down by about 5% (maybe 10%). Beyond that, page layouts start getting funky and you'll have text that overlaps other screen elements.
I have a higher DPI display as well (125dpi) and even with using the "minimum font size" settings, it still causes more issues then it fixes.
4. When one tab is 'busy' (opening a PDF, for example) the entire browser window freezes. This is a tough one, I understand, but not impossible.
This is the one that absolutely drives me crazy. I'm a heavy tab user, loading a lot of stuff into background tabs while I work in the foreground tab. Every time I go to open a page in the background I have to WAIT on a tab that I'm not even looking at. Gee, I thought the whole point of loading something in the background was so that it wouldn't interfere with what I'm doing in the foreground.
I should dig up my old 0.5 or 0.6 versions and see if they had that misbehavior. It seems like they broke something in 1.5 (and left it broken in 2.0) where the UI blocks on network events.
If not, maybe it's time to go look at IE7 or Opera and see if they're less braindead about blocking the UI.
Of course, if a disk gets a read error in the sector holding the FAT, I'm toast. :-)
Maybe not. PAR2 files store the filenames as part of the recovery data. As long as the TOC track (innermost track) isn't kaput, you can recover the data even if both the UDF and older 8.3 file tables are blitzed. If the TOC is busted, you'll have to get a professional DVD reader or go to a recovery service.
(The "how to" is over on the QuickPar forums. Basically, you rip the disk at the sector level to a pair of files. Rename the one with a PAR2 extension, then feed it the 2nd file as source data. QuickPar will find all of the data blocks and reconstitute the original files.)
You put the PAR2 files on the same disk?
Depends on what I'm archiving to DVD-R.
If it's stuff that I found on the web, and could probably dig up again if I had to, then it's no worry to burn a single copy and put 10% PAR2 data on the same disk. From my experience, the odds are very slim (1:500), that I will encounter errors trying to read the disk after a few years. And even when I do encounter errors, I can put the disk into a 2nd machine and pull the missing bits off. Or else, I only end up with about 1% damage which is easily repaired by the 10% parity data that I put on the disk.
(Again, the whole advantage of parity data is that it gives you a recovery window. If you test regularly, at a higher frequency then the disk is failing at, you can catch errors early enough to repair. If you want a lower frequency of testing, then you should put more parity data on the disk. Maybe 20-25% of the disk devoted to parity data. If you are less concerned, you can get away with 2-5% parity data.)
For more important stuff: That always ends up spread across multiple archival snapshots before it is permanently removed. For example, I'll backup up the previous 6 months of data every month. Which means that a single piece of data should end up on at least 5 of the disks. The PAR2 data on each disk is more of a time-saver and double-check. Just enough PAR2 data to recover from minor scratches / blemishes and I can use the PAR2 data to double-check the disk health.
If I'm doing a very large snapshot (say when I image my laptop HD) and don't want multiple copies... Let's say I have 8 disks worth of data in the snapshot. I'll spread it across 10 disks. The 10th disk will be 100% PAR2 data. Disk 1-9 will be 89% data and 11% PAR2 data. Which I think works out to 2 disks (25% parity) worth of PAR2 data. I can lose an entire disk out of the set without worrying.
Also, some version control systems only store the diffs of binary files (such as Subversion).
Which makes it efficient enough that we don't worry much about what we store in our Subversion repository (as opposed to older, dumber systems that stored a fresh copy of binary files for each commit).
Aye, I have the Epson Stylus Photo R200 and it's worked well. It uses separate cartridges for each color (6 total, including black).
The only issue that I've had with mine is that the CD tray will not automatically feed into the unit. I have to stand there putting a little inward pressure on it to get it to feed properly. Once it feeds, it's good to go and works just fine.
Heat is an issue, and if you store them on your dashboard, you deserve what results.
I have MP3 CD-Rs in my car from 2001 that have either been up in a visor holder or stored in a door compartment. I live in Pennsylvania (to give you an idea of the weather extremes). Now, they weren't in direct sunlight, which probably helped. But you figure they still ran the temperature range of 0F up to 120F.
I think I might've had trouble with one or two disks over the years. But since they're MP3 CDs, I just re-copy them from my central storage (or else I backed the disks up to DVD-R which I keep in my house).
Don't know if the ones I bought were counterfeit, but at least they came from MWave. (Where I'd think it would be unlikely that they'd sell grey-market goodes.)
MWave Taiyo Yuden
I tend to buy the 100/pack, tape-wrap, inkjet printable. As long as you have some empty cake boxes around to transfer them into, the tape-wrap style works fine.
Hard Disk Drives now are about $0.50 a Gigabyte.
You're a bit on the high side there... SATA/PATA drives are down around $0.28-$0.32 per gigabyte and have been for a while. The sweet spot seems to be the 250GB drives for $70, with the 200GB, 300GB, 400GB sizes at around $0.32/GB.
(Which hasn't changed a whole lot in the past few months. But Seagate's 7200.10 series is one of the cheaper $/GB drives on the market even though it's brand new tech.)
A three-year-old computer is obsolete as a gaming machine in terms of CPU and graphics power... consoles are the same way.
That was true (for PCs) up until around 2001-2002. Then things stalemated and a 3 year old machine is still plenty powerful as a gaming machine. (My game system is a 2GHz Opteron with the last possible AGP card, GeForce 7800GS. I reckon I won't upgrade that system until 2008 at this rate.)
Why would they need to do that? For most positions that companies would consider allowing telecommuting for, I think it's reasonable to expect the employee to have their own computer. Just don't bother them about having porn on the same computer they do work on.
If you allow the employees to supply their own machine, who is on the hook when it doesn't work? Can you discipline an employee for buying sub-standard tools that are required to do their job? Who pays for the software? Who pays for the court costs if pirated software is found (probably the employee).
The closest corollary I can think of is mechanic's tools. Mechanics supply their own tools (I think) but I think there are also monthly allowances for the replacement/purchase of new tools.
Personally, I draw the line based on whether the person is a contract worker (paid hourly or piece-work fashion) or a salaried employee. For salaried employees, we supply the hardware and software just as we would if they were in the office. For contract workers, they're required to have their own tools.
That technology was around back in 2000? I'm pretty sure that NASA was talking about using it to stitch together multiple frames from a video clip to clean up / enhance a section of the frame.
Too lazy to go looking right now though.
There's another instance on CSI (or one of the others) where a suspect goes into a pawn brokers shop to buy up some piece of evidence prior to the police finding it. On his way out, he ducks out the side of the frame and touches something before leaving the shop.
So... they grab the tape and look at what is supposedly the "overscan" area of a 4:3 NTSC signal. Darned if that full-framed image didn't look like a 16:9 HDTV frame.
I mean, we're not talking an additional 10-20 pixels of information that wasn't shown on the original screen... we're talking looking at stuff that was 3 counties away from what a 4:3 NTSC camera would record.
For example, I've read several sci-fi novels (Stephen Donaldson's Gap series being a favorite) that depict space combat occuring at realistic ranges -- ranges where even using light-speed weaponry it takes several minutes to reach the target. In a novel, the tension of having to wait minutes to know if you scored a hit works whereas in a movie it would be boring as hell.
See also the Chanur Saga (3 books rolled into one followed by a 4th separate book). C.J. Cherryh does a good job of dealing with the fragmentary information of battles using beam/missle weapons over a large area.
A very noteable exception -- or maybe not since it isn't Hollywood but what you're saying is common of action movies from everywhere -- being The Seven Samurai. Everyone who uses a sword in that movie uses it to kill, and as a result most sword fights are one or two strokes long. While lacking the acrobatic beauty of a good ten-minute lightsaber duel, it did have a gritty reality that just felt right.
Ah sweet... The Seven Samurai just arrived in my mailbox today.
Now to find time in my busy admin schedule to view it. Maybe I'll recompile the Xen kernels a few times...