It's nowhere near that rosy out there. I can name half a dozen Fortune 500 companies that we do business with who are freezing budgets, cutting suppliers, and putting lots of projects on hold. Which means that a lot of small companies out there are getting squeezed hard. There's a lot of fear in the boardrooms and it's trickling down quite nastily.
We find out this week whether we're about to lose about 15-20% of our gross revenue for the year due to cutbacks.
Also, was 2000's four year old hardware proportionally as slow as 2009's four year old hardware? That is, if you were to plot the CPU and IO performance increase over time from ~1997-2009, would the plot's slope remain relatively constant? (I have no idea, that's why I'm asking.)
In general, no. Back in the 90s, the speed increases were in the range where computers got twice as fast every 12-15 months. So a 3 year old machine was 6-8x slower then a new one. Corporations really needed to replace machines every 3 years, and there were lots of issues with depreciation schedules back then.
1999 machines were basically 300-450MHz Pentium III units. It only took a year or two for that to jump to 1GHz and another year or so to hit 1.5GHz. (Ignoring the fact that we switched from P3 to P4 architecture and that clock frequency doesn't map 1:1 between the two architectures). But you were still looking at replacing machines every 3-4 years if you wanted to stay semi-current.
But after that, it took until '03 or '04 to get up to around 3GHz. Maybe even as late as '05. So the performance was definitely no longer doubling every 15-18 months. Now it had slowed down to 24-36 months in order to double performance. Now a 3 year old machine is only 2x-4x as slow as a current model. Useable, a bit sluggish, but given enough RAM, still a very useful machine. Machine lifespan is now probably 4-6 years, unless you got bit by the bad capacitors.
Back in '04-'05, we could buy a 2GHz Opteron, in '08 those Opterons were only up to around 3GHz (50% faster for a single core). I'm not sure what Intel CPUs did during that time period because we switched to Athlon/Opteron as soon as dual-cores dropped below $300. But basically, you're looking at only a 50%-80% performance improvement over a 3 year period for a single-core. So except for the issue of multi-core, a 3 year old CPU is perfectly viable.
The game changer in this is multi-core. Dual-core makes a *huge* difference in keeping the machine responsive while under load. Even back in '03-'05, there were a lot of folks who would take Athlon M CPUs, figure out how to put two of them on a single board, and get a machine that would take a few more years before it feels slow. So even though the individual CPUs might be a bit pokey, the second CPU can handle the interactive tasks. And you'll get a small performance increase because the task can have a CPU all to itself instead of having to share it with other processes.
The machines that we put in at the office over the past 3 years have all been dual-core, 2GB RAM, RAID1 drive setup. Conservatively, I expect them to last for at least 6 years and hopefully 9-10. The major threat to lifespan here is motherboard failure (due to shoddy components). We've gone with fanless motherboards (all heatsinks and heatpipe) in an attempt to reduce the chance of early failure.
New machines will likely be 3/4 core units with 4/8 GB of RAM. At which point, you're definitely looking at a 8-12 year machine. At least, for general office work.
But seriously, I installed Ubuntu last night. I've been a diehard RHEL/CentOS user for years. It just plain worked out of the box for me on a relatively new laptop. It found the Wifi,sound, my bluetooth mouse, asked me if I wanted the "non free" binary accelerated Radeon X1600 video driver, etc. Pretty slick.
RHEL/CentOS makes a lot of sense on the server side, Ubuntu makes a lot of sense on the desktop side. Each to their own strengths?
I don't know about that. Ten years ago, when Javascript implementations were spotty, buggy, and at times incompatible, I'd probably agree. But nowadays I'd consider having a working Javascript implementation just about as important in browser selection as standards-compliant HTML and CSS support.
Except for the little nasty issue called malware writers who abuse Javascript in order to infect your machine. Which is the primary reason that I run with Flashblock and NoScript.
The other half of the issue is that too often, Javascript is abused to do things like pop-ups, pop-unders, or other user-hostile actions. Which is the secondary reason that I run Flashblock and NoScript. It's a nice technology, but it's too prone to abuse by bad actors.
The web is a lot saner place when you block by default and only selectively whitelist sites. I switched a year or two ago to blocking it all and only allowing a few sites to run Javascript and will never go back.
We never use standard names, our company deals with lots of e-payments and the idea is that the less obvious our naming scheme is, the more difficult it is for hacker to really figure out what the purpose of a server is and what it may store.
Very true for public-facing servers. Now, things like mail, web, ftp don't make sense to obscure. But database or transaction servers should probably be obscured.
The other reason that you want server names to be obscure: it might force the attacker to spend more time mapping out your network. Which gives you a bigger time window and the possibility that the attacker's actions will trigger a network alert.
Also look for network monitoring. Nagios does a nice job of showing the network layout if you defined things properly. Which makes it quick to pickup on what servers are where.
On our Linux servers, we also use FSVS with a Subversion backend repository to version control all configuration files on the server. Which ends up making changes self-documenting if you remember to commit after making configuration changes (# fsvs ci -m "message"/path/to/filename). Also useful for figuring out what broke when you can do diffs between files (even if the server is down if the SVN repository is on a different box).
I know lots of old displays still use DSub VGA but when can I get one with HDMI?
Or DVI.
The problem right now seems to be that the PC laptop makers are all waiting on the "next big thing" called Displayport rather then put DVI ports on their motherboards.
Re:this is good *because* people are rarely offlin
on
Offline Gmail Launched
·
· Score: 1
And a hassle it is. Right now, I use Thunderbird for off-line access, and I use it so rarely that on the few occasions I start it up, things usually take forever to sync and nothing works quite right.
I think that's more a function of the fact that Thunderbird v2 is a horrid IMAP client. Yet it's still a major step above Outlook over IMAP.
(I fight with Thunderbird on a weekly basis, using it as an IMAP client. It's near hopeless if a folder has more then a few thousand messages because Thunderbird constantly corrupts its index and then has to re-download everything.)
SSD drives are not as unreliable as people seem to think, It would take a *minimum* of 5 years of *continuous* writing and thats for the cheaper SSD's like you would find in a netbook rather than the $300 Intel top of the line ones, not to mention ones being used in a RAID would have a longer life.
Pretty sure that's only true for a drive that is empty. If the drive is half full, or even 75% full, the SSD has a lot less unused space to spread wear over. That can cut lifespan down to 1/4 of the original.
(Unless it's a really really good bit of firmware that moves rarely written blocks over to blocks that are frequently written during idle time.)
I suspect the OP meant RAID-10, which is generally RAID-0 spread across a bunch of RAID-1 pairs. The advantage there is that you get the speed of RAID-0, where performance mostly increases linearly as you add spindles, with the safety of RAID-1. (You also get small rebuild windows, because a rebuild only has to reconstruct a single drive in the array to rebuild a mirror pair.) RAID-10 over a dozen spindles is very speedy.
A good RAID-1 implementation should have the same write performance as a single disk. Reads *could* be sped up based on the # of drives in the mirror set, but doesn't always happen. On the other hand, it's easy to use RAID-1, mirrored across 3 drives instead of only 2 drives, to protect against double-drive failures.
RAID5 is absolutely a bad idea once drive sizes went past the size where rebuild times take more then an hour or two. Too great of a chance that a second drive will fail during the rebuild window due to the stress.
RAID6 with one hot-spare should be considered the minimum safe level. For 15-drive arrays, I prefer RAID6 over 13 spindles with 2 hot-spares.
I wish there were tests covering "typical user mishaps". Things like inopportune powerdowns and flash drive yanking. My anecdotal evidence is that I've never had issues with FAT32 but have had entire NTFS partitions become unreadable. It's just anecdote though. Now throw a truecrypt file into the mix...
Ugh... FAT32 is so much more likely to lose data compared to NTFS (which is journaled). (My only data loss due to a screwed up FS is due to FAT32 going crazy.)
(Either way, I always setup my flash drives to auto-backup when they are hooked up to my PC.)
One last thought. Once you learn how to search/replace in vim - you'll mostly know how to work with sed (the syntax is very similar). At which point you'll probably start to learn the ins/outs of bash scripting, using sed, tr, find and grep to mash data and parse the output. Basic knowledge of regular expressions is a boon as well.
There's a lot of fun to be had in unix/linux where "everything is a file" was the old mantra.
For emacs and vi - learn the key set of commands and keep them on a handy cheat sheet (index card, electronic note, tattoo, MotD). For vim, that's about a dozen commands:
gets you back to command mode :q! - quit without saving
ZZ - save and quit
d$ - delete to the end of the line
dw - delete to the next word break
dd - delete an entire line
x - delete a single character
i - start an insert before the current position
A - start an insert at the end of the line
u - undo
Then there's learning how to search & replace, or find text, or move to a particular line #. Basically, if you find yourself doing something over and over (such as mashing "dd" repeatedly to delete lines), you learn to scratch the itch and go look it up in the help (or the Linux in a Nutshell book which is a great reference).
Been using vi/vim for close to 10 years now, it's only in the last 3 that I've expanded beyond learning the basic commands. I'm no expert, but I can do pretty well now with it. At least enough to edit configuration files quickly and pretty efficiently.
Do text apps still have a place in today's world? Heck, network speeds and capacities (read bandwidth) have improved a great deal. I would rather have these programmers focus their efforts on Krusader ? It seriously needs some love.
It's a lot easier to log what I do at the command line then what I do in a GUI. Which comes in handy 6-18 months down the road when I'm trying to remember what the heck I did to configure XYZ. And a 132x50 display area for a console is nice and roomy.
In fact, lack of logging is one of the things I dislike about Windows now. I would have to take copious screenshots in order to keep track.
(We also use FSVS with a SVN storage repository to keep track of changes. The log files are more for my convenience.)
Define old? I know that back when I was in the Netherlands around '91, they had lots of wind farms along the shores of the Ijsselmeer. I know the Ijsselmeer is fresh-water, and I can't remember whether there were also wind turbines along the seaward end of the lake.
I'm guessing that the new bit is putting them somewhat over-the-horizon offshore, rather then close to the shoreline where they're more visible.
I'd be happier to see true import/export features in Base. It needs to be dead-simple to import to/from CSV, tab-delimited,.sql files, and MDB files.
It's still too convoluted to connect to external data sources. There's no easy way to connect to ODBC or MDB tables without creating a "registered" data connection. Often, I'm not interested in a semi-permanent "registered" data source. I want something quick and easy for a one-time import, not something that I'll have to go delete later.
I took a look at OpenOffice.org v3 last week, primarily to look at the database component. There are still some big deficiencies:
- No built-in import/export functionality comparable to MS-Access
- No easy way to link to a MS-Access MDB within an existing.odb file (it's buried under Edit -> Database -> Connection Type)
- No DELETE / INSERT / UPDATE queries using the query designer
Frankly, the lack of an easy import/export feature is a big killer. It should be dead easy to import/export from CSVs, tab-delimited, and.sql files. Or to pull tables/queries out of an existing MDB into the ODB file. Linking to other tables in ODBC or MDB data sources should also be dead simple, not buried in some obscure menu location.
The current workarounds for import/export is to go through the spreadsheet component, which is extremely convoluted.
The major frustrations that I have with OpenLDAP/Samba (currently wrestling with eliminating Active Directory myself) is that there are very few *good* guides out there that explain the process. Most of the guides out there are do XYZ and you're done, but only if you're on this specific version of Linux.
Nobody bothers to explain how to verify that things are working. Or why they chose the settings that they did. Or what settings are required and which ones were only due to some local mandate.
All of this, I think, is why there's a lot of frustration out there with OpenLDAP. Yes, it's a complex piece of software, but I think a lot of it is due to poor documentation.
- They had a 1TB drive early
- They had a 5 year warranty
Now that their warranty is no longer 5 years, I tend to buy a wide variety of drives. Which works well for RAID scenarios because I'm less likely to end up with two drives from the same batch that fail during the same time window.
I replaced a Seagate drive during that timeframe as well, and they preshipped the replacement drive without any hassle at all. Of course, I was replacing a high-end not-your-typical-consumer drive, so perhaps that made the difference.
In general during the 90s and most of this decade (and probably still), high-end drives can be cross-shipped or even advanced shipped for free. Lower-end drives require a security deposit or advanced fees if you want cross-ship or advance shipping.
Which makes a lot of sense from a business standpoint. Better service for the more expensive products.
It's been a while since I've watched it. But if you have the DVD version with both subtitle tracks and know a little bit of Japanese language/culture, you can find the differences between the two different subtitle tracks.
(It's just a big pet peeve of mine where the english dub westernizes something. That particular movie stands out because it's full of shades of grey. Is the lady in charge of the town good or evil? Is the stag spirit good or evil? What about the protagonists?)
Slashdot Mirror
It's nowhere near that rosy out there. I can name half a dozen Fortune 500 companies that we do business with who are freezing budgets, cutting suppliers, and putting lots of projects on hold. Which means that a lot of small companies out there are getting squeezed hard. There's a lot of fear in the boardrooms and it's trickling down quite nastily.
We find out this week whether we're about to lose about 15-20% of our gross revenue for the year due to cutbacks.
Also, was 2000's four year old hardware proportionally as slow as 2009's four year old hardware? That is, if you were to plot the CPU and IO performance increase over time from ~1997-2009, would the plot's slope remain relatively constant? (I have no idea, that's why I'm asking.)
In general, no. Back in the 90s, the speed increases were in the range where computers got twice as fast every 12-15 months. So a 3 year old machine was 6-8x slower then a new one. Corporations really needed to replace machines every 3 years, and there were lots of issues with depreciation schedules back then.
1999 machines were basically 300-450MHz Pentium III units. It only took a year or two for that to jump to 1GHz and another year or so to hit 1.5GHz. (Ignoring the fact that we switched from P3 to P4 architecture and that clock frequency doesn't map 1:1 between the two architectures). But you were still looking at replacing machines every 3-4 years if you wanted to stay semi-current.
But after that, it took until '03 or '04 to get up to around 3GHz. Maybe even as late as '05. So the performance was definitely no longer doubling every 15-18 months. Now it had slowed down to 24-36 months in order to double performance. Now a 3 year old machine is only 2x-4x as slow as a current model. Useable, a bit sluggish, but given enough RAM, still a very useful machine. Machine lifespan is now probably 4-6 years, unless you got bit by the bad capacitors.
Back in '04-'05, we could buy a 2GHz Opteron, in '08 those Opterons were only up to around 3GHz (50% faster for a single core). I'm not sure what Intel CPUs did during that time period because we switched to Athlon/Opteron as soon as dual-cores dropped below $300. But basically, you're looking at only a 50%-80% performance improvement over a 3 year period for a single-core. So except for the issue of multi-core, a 3 year old CPU is perfectly viable.
The game changer in this is multi-core. Dual-core makes a *huge* difference in keeping the machine responsive while under load. Even back in '03-'05, there were a lot of folks who would take Athlon M CPUs, figure out how to put two of them on a single board, and get a machine that would take a few more years before it feels slow. So even though the individual CPUs might be a bit pokey, the second CPU can handle the interactive tasks. And you'll get a small performance increase because the task can have a CPU all to itself instead of having to share it with other processes.
The machines that we put in at the office over the past 3 years have all been dual-core, 2GB RAM, RAID1 drive setup. Conservatively, I expect them to last for at least 6 years and hopefully 9-10. The major threat to lifespan here is motherboard failure (due to shoddy components). We've gone with fanless motherboards (all heatsinks and heatpipe) in an attempt to reduce the chance of early failure.
New machines will likely be 3/4 core units with 4/8 GB of RAM. At which point, you're definitely looking at a 8-12 year machine. At least, for general office work.
But seriously, I installed Ubuntu last night. I've been a diehard RHEL/CentOS user for years. It just plain worked out of the box for me on a relatively new laptop. It found the Wifi,sound, my bluetooth mouse, asked me if I wanted the "non free" binary accelerated Radeon X1600 video driver, etc. Pretty slick.
RHEL/CentOS makes a lot of sense on the server side, Ubuntu makes a lot of sense on the desktop side. Each to their own strengths?
I don't know about that. Ten years ago, when Javascript implementations were spotty, buggy, and at times incompatible, I'd probably agree. But nowadays I'd consider having a working Javascript implementation just about as important in browser selection as standards-compliant HTML and CSS support.
Except for the little nasty issue called malware writers who abuse Javascript in order to infect your machine. Which is the primary reason that I run with Flashblock and NoScript.
The other half of the issue is that too often, Javascript is abused to do things like pop-ups, pop-unders, or other user-hostile actions. Which is the secondary reason that I run Flashblock and NoScript. It's a nice technology, but it's too prone to abuse by bad actors.
The web is a lot saner place when you block by default and only selectively whitelist sites. I switched a year or two ago to blocking it all and only allowing a few sites to run Javascript and will never go back.
Yah, he ran afoul of guidelines for good names:
- unobjectionable
- easy to type
- easy to pronounce
- distinct (so you don't get the wrong server)
Colors, birds, animals, insects, geology, chemistry... are all pretty safe.
We never use standard names, our company deals with lots of e-payments and the idea is that the less obvious our naming scheme is, the more difficult it is for hacker to really figure out what the purpose of a server is and what it may store.
Very true for public-facing servers. Now, things like mail, web, ftp don't make sense to obscure. But database or transaction servers should probably be obscured.
The other reason that you want server names to be obscure: it might force the attacker to spend more time mapping out your network. Which gives you a bigger time window and the possibility that the attacker's actions will trigger a network alert.
Also look for network monitoring. Nagios does a nice job of showing the network layout if you defined things properly. Which makes it quick to pickup on what servers are where.
/path/to/filename). Also useful for figuring out what broke when you can do diffs between files (even if the server is down if the SVN repository is on a different box).
On our Linux servers, we also use FSVS with a Subversion backend repository to version control all configuration files on the server. Which ends up making changes self-documenting if you remember to commit after making configuration changes (# fsvs ci -m "message"
I know lots of old displays still use DSub VGA but when can I get one with HDMI?
Or DVI.
The problem right now seems to be that the PC laptop makers are all waiting on the "next big thing" called Displayport rather then put DVI ports on their motherboards.
And a hassle it is. Right now, I use Thunderbird for off-line access, and I use it so rarely that on the few occasions I start it up, things usually take forever to sync and nothing works quite right.
I think that's more a function of the fact that Thunderbird v2 is a horrid IMAP client. Yet it's still a major step above Outlook over IMAP.
(I fight with Thunderbird on a weekly basis, using it as an IMAP client. It's near hopeless if a folder has more then a few thousand messages because Thunderbird constantly corrupts its index and then has to re-download everything.)
On the more expensive drives maybe... but on the cheaper SSDs? Why should the low-cost drive maker pay for that complexity?
SSD drives are not as unreliable as people seem to think, It would take a *minimum* of 5 years of *continuous* writing and thats for the cheaper SSD's like you would find in a netbook rather than the $300 Intel top of the line ones, not to mention ones being used in a RAID would have a longer life.
Pretty sure that's only true for a drive that is empty. If the drive is half full, or even 75% full, the SSD has a lot less unused space to spread wear over. That can cut lifespan down to 1/4 of the original.
(Unless it's a really really good bit of firmware that moves rarely written blocks over to blocks that are frequently written during idle time.)
I suspect the OP meant RAID-10, which is generally RAID-0 spread across a bunch of RAID-1 pairs. The advantage there is that you get the speed of RAID-0, where performance mostly increases linearly as you add spindles, with the safety of RAID-1. (You also get small rebuild windows, because a rebuild only has to reconstruct a single drive in the array to rebuild a mirror pair.) RAID-10 over a dozen spindles is very speedy.
A good RAID-1 implementation should have the same write performance as a single disk. Reads *could* be sped up based on the # of drives in the mirror set, but doesn't always happen. On the other hand, it's easy to use RAID-1, mirrored across 3 drives instead of only 2 drives, to protect against double-drive failures.
RAID5 is absolutely a bad idea once drive sizes went past the size where rebuild times take more then an hour or two. Too great of a chance that a second drive will fail during the rebuild window due to the stress.
RAID6 with one hot-spare should be considered the minimum safe level. For 15-drive arrays, I prefer RAID6 over 13 spindles with 2 hot-spares.
I wish there were tests covering "typical user mishaps". Things like inopportune powerdowns and flash drive yanking. My anecdotal evidence is that I've never had issues with FAT32 but have had entire NTFS partitions become unreadable. It's just anecdote though. Now throw a truecrypt file into the mix ...
Ugh... FAT32 is so much more likely to lose data compared to NTFS (which is journaled). (My only data loss due to a screwed up FS is due to FAT32 going crazy.)
(Either way, I always setup my flash drives to auto-backup when they are hooked up to my PC.)
One last thought. Once you learn how to search/replace in vim - you'll mostly know how to work with sed (the syntax is very similar). At which point you'll probably start to learn the ins/outs of bash scripting, using sed, tr, find and grep to mash data and parse the output. Basic knowledge of regular expressions is a boon as well.
There's a lot of fun to be had in unix/linux where "everything is a file" was the old mantra.
For emacs and vi - learn the key set of commands and keep them on a handy cheat sheet (index card, electronic note, tattoo, MotD). For vim, that's about a dozen commands:
:q! - quit without saving
gets you back to command mode
ZZ - save and quit
d$ - delete to the end of the line
dw - delete to the next word break
dd - delete an entire line
x - delete a single character
i - start an insert before the current position
A - start an insert at the end of the line
u - undo
Then there's learning how to search & replace, or find text, or move to a particular line #. Basically, if you find yourself doing something over and over (such as mashing "dd" repeatedly to delete lines), you learn to scratch the itch and go look it up in the help (or the Linux in a Nutshell book which is a great reference).
Been using vi/vim for close to 10 years now, it's only in the last 3 that I've expanded beyond learning the basic commands. I'm no expert, but I can do pretty well now with it. At least enough to edit configuration files quickly and pretty efficiently.
Do text apps still have a place in today's world? Heck, network speeds and capacities (read bandwidth) have improved a great deal. I would rather have these programmers focus their efforts on Krusader ? It seriously needs some love.
It's a lot easier to log what I do at the command line then what I do in a GUI. Which comes in handy 6-18 months down the road when I'm trying to remember what the heck I did to configure XYZ. And a 132x50 display area for a console is nice and roomy.
In fact, lack of logging is one of the things I dislike about Windows now. I would have to take copious screenshots in order to keep track.
(We also use FSVS with a SVN storage repository to keep track of changes. The log files are more for my convenience.)
Define old? I know that back when I was in the Netherlands around '91, they had lots of wind farms along the shores of the Ijsselmeer. I know the Ijsselmeer is fresh-water, and I can't remember whether there were also wind turbines along the seaward end of the lake.
I'm guessing that the new bit is putting them somewhat over-the-horizon offshore, rather then close to the shoreline where they're more visible.
I'd be happier to see true import/export features in Base. It needs to be dead-simple to import to/from CSV, tab-delimited, .sql files, and MDB files.
It's still too convoluted to connect to external data sources. There's no easy way to connect to ODBC or MDB tables without creating a "registered" data connection. Often, I'm not interested in a semi-permanent "registered" data source. I want something quick and easy for a one-time import, not something that I'll have to go delete later.
I took a look at OpenOffice.org v3 last week, primarily to look at the database component. There are still some big deficiencies:
.odb file (it's buried under Edit -> Database -> Connection Type)
.sql files. Or to pull tables/queries out of an existing MDB into the ODB file. Linking to other tables in ODBC or MDB data sources should also be dead simple, not buried in some obscure menu location.
- No built-in import/export functionality comparable to MS-Access
- No easy way to link to a MS-Access MDB within an existing
- No DELETE / INSERT / UPDATE queries using the query designer
Frankly, the lack of an easy import/export feature is a big killer. It should be dead easy to import/export from CSVs, tab-delimited, and
The current workarounds for import/export is to go through the spreadsheet component, which is extremely convoluted.
The major frustrations that I have with OpenLDAP/Samba (currently wrestling with eliminating Active Directory myself) is that there are very few *good* guides out there that explain the process. Most of the guides out there are do XYZ and you're done, but only if you're on this specific version of Linux.
Nobody bothers to explain how to verify that things are working. Or why they chose the settings that they did. Or what settings are required and which ones were only due to some local mandate.
All of this, I think, is why there's a lot of frustration out there with OpenLDAP. Yes, it's a complex piece of software, but I think a lot of it is due to poor documentation.
The only reason(s) I bought Seagates:
- They had a 1TB drive early
- They had a 5 year warranty
Now that their warranty is no longer 5 years, I tend to buy a wide variety of drives. Which works well for RAID scenarios because I'm less likely to end up with two drives from the same batch that fail during the same time window.
I replaced a Seagate drive during that timeframe as well, and they preshipped the replacement drive without any hassle at all. Of course, I was replacing a high-end not-your-typical-consumer drive, so perhaps that made the difference.
In general during the 90s and most of this decade (and probably still), high-end drives can be cross-shipped or even advanced shipped for free. Lower-end drives require a security deposit or advanced fees if you want cross-ship or advance shipping.
Which makes a lot of sense from a business standpoint. Better service for the more expensive products.
It's been a while since I've watched it. But if you have the DVD version with both subtitle tracks and know a little bit of Japanese language/culture, you can find the differences between the two different subtitle tracks.
(It's just a big pet peeve of mine where the english dub westernizes something. That particular movie stands out because it's full of shades of grey. Is the lady in charge of the town good or evil? Is the stag spirit good or evil? What about the protagonists?)
Related to this... is there any software for linux that functions in this way? (Blocking connections by program, with gui notification)
Probably SELinux handles that.