True. But riddle me this: when you get up tomorrow and go to sign in to GMail and all you get is a single page saying "Due to financial constraints and an inability to derive revenue from GMail to pay our bills, we have regretfully been forced to terminate the service.", where are your game serial numbers now and how do you plan on getting at them? I know it seems unlikely Google would just drop a service like that. Except that, well, they already have.
Agreed. The tests will tell you if you broke anything they test in a way they test for. In any real-world application, though, you end up with untested and untestable interactions between components. Worse, you end up with errors that aren't bugs in the implementation, they're bugs in the component specification. The tests pass because the component's doing what it's supposed to do, but that causes the entire system to fail when you get to integration testing because what it's supposed to do isn't what it needs to do. That's why programmers have the term "broken as designed".
The voting system shouldn't need to be open-source. In fact I'd go so far as to say that any electronic voting system that requires the voting machines to be open-source is fundamentally flawed and shouldn't be trusted. The system should be designed so that it doesn't matter whether the machines themselves are recording correctly or not, it's still possible to determine whether the counts are correct (ie. match the intent of the voter) or not and ideally to be able to reconstruct the correct count.
Yes, it can be done. Anyone who accounts for money has been doing it for centuries. Any lowly night auditor at a hotel can explain the principles complete with examples.
$75K gross. Less Federal taxes, state taxes, insurance premiums, etc. etc.. At that level you can figure about 35% of your paycheck going to taxes and deductions (401K isn't optional if you expect not to be living in a cardboard box and eating dog food during your retirement). So for a $75K/year job, figure about $4K/month net income. For a 1-bedroom apartment in San Diego, you're talking around $1100/month in rent. For a family figure at least a 2-bedroom house, those will run you at least $2K/month. For a median-priced house in San Diego county at expected rates, the mortgage payments alone will run you $2-2.5K/month and that's before you pay homeowner's insurance and all the other bills that come with a house. So you're looking at anywhere from about 25% to over 50% of your monthly income just for basic housing costs.
I've been doing this kind of throttling on a per-connection basis for a long time. I needed to set up the packet scheduler on my Linux-based router correctly, but now it's configured to watch connections and any connection that eats a lot of sustained bandwidth gets bumped down to bulk-transfer priority. Packets for those connections go to the back of the queue and get to share the bandwidth left over after everything at a higher priority's gotten what it needs, subject to a hard cap of 80% (20% of total bandwidth is reserved for non-bulk-transfer connections at all times). That lets me start a large file download and quickly have it shunted off to soaking up only otherwise-unused bandwidth, letting games and other low-bandwidth applications continue pretty much unaffected. If I can do it on a cheap Linux box I'm pretty sure a high-end Cisco router can handle it too, it's just a matter of configuring it.
You can't fix this. Only the manager can fix it, by realizing his first, basic mistake: when he thought IT needed something, he went off on his own deciding what it was they wanted instead of asking "What do you need to do that?". Even if the manager understood IT jargon, he shouldn't have been going off deciding what to get in the way of IT equipment without asking that question and getting an answer first. This is, in fact, the basic problem I see between business and IT: that business goes making decisions about IT matters without consulting IT first or without giving weight to IT's advice. No businessman would go making or accepting a contract without consulting the company's lawyers and heeding their advice, yet that's exactly what's routinely done when it comes to IT matters.
You lose on density, though. Aisle space in front of the racks is fixed, you need a certain amount for humans to move in. Shallow, tall equipment means fewer units per rack. With a current-format rack you need say a 3'-deep area for the rack and a 3'-wide aisle for access. That's 50% equipment and 50% access. If the racks were only 1' deep instead, you'd be using 25% for equipment and 75% for access (since you still need that 3' wide aisle). And in that 25% of space for equipment you now get perhaps 25% of the amount of equipment since each one's using 4x more vertical space in the rack and rack height can't change (it's limited by basically how high off the floor a human can reach to get to the equipment).
To make up for that, you need more square footage of data center to hold the equipment. That increases operating costs, which is what we're trying to reduce.
Well, it makes sense. Normal PCs run on essentially ambient air, and live for years even under heavy loads (games put a lot of load on systems) despite all the dust and cruft. Servers aren't that different in their hardware, so it makes sense they'd behave similarly. And there's a lot that can be done cheaply to reduce the problems that were seen. Dust, for instance. You can filter and scrub dust from the incoming air a lot cheaper than running a full-on AC system. In fact the DX system used on the one side of the test probably scrubbed the incoming air itself, which would explain the lower failure rate there. Reduce the dust, you reduce the build-up of the thermal-insulating layer on the equipment and keep cooling effectiveness from degrading. Humidity control can also be done cheaper than full-on AC, and wouldn't have to be complete. I don't think you'd need to hold humidity steady within tight parameters, just keep the maximum from going above say 50% and the minimum from going below 5%. Again I'll bet the DX system did just that automatically. I'd bet you could remove the sources of probably 80% of the extra failures on the free-cooling side while keeping 90% of the cost savings in the process.
I could, but the WRT54 series is a router not an access point. I have a completely different configuration: a dedicated NIC on the primary router box going to a switch that all the access points attach to, with the APs providing only the wired-to-wireless bridge and the router box handling all routing, DHCP, VPN termination, etc.. I'd prefer to keep that configuration so I can manage everything at a single central point (and have a much more powerful machine there too to handle heavy-duty VPN encryption tasks, Web proxy and assorted other things).
The cost of having (probably) Cisco write custom firmware for all their equipment, and the cost of maintaining that custom firmware. It's possible to get the routers to handle a/128 assignment, but you're fighting the equipment the whole way. And it fails to work with Windows, whose IPv6 stack assumes that IPv6 stateless autoconfig works properly and doesn't play well with routers that refuse to accept the stack's use of it's own MAC-address-based value in the lower 64 bits. Again this can be worked around, but it takes a lot of heavy messing-about in low-level configuration to make it all work right. And how many ISPs are going to tell their customers that the ISP doesn't support Windows?
Dual IPv4/IPv6 stack. Almost all IPv6 stacks today are dual stacks, you usually have to play some interesting configuration tricks to create a true IPv6-only, no IPv4 support at all, host. Generally the source address is handled by the stack, which'll select the IPv4-mapped adapter address as the source address when sending to an IPv4-mapped destination address. Unless you're using a 6-to-4 bridge, in which case the bridge will handle the address translation if the source host has no IPv4-mapped adapter address.
Yeah, I'm in the process of turning on IPv6 on my home network, and I'm ironing out all the kinks. The big one's the consumer WAP that doesn't understand IPv6 at all, which I'm dealing with by using IPSec VPN tunnels.
The IPv4 machine doesn't need an IPv6 address to reply. It replies to the IPv4-compatible address the IPv6 host is using. Now, the IPv6 machine needs either a dual stack (allowing it an IPv4 and an IPv6 address) or a 6-to-4 bridge connecting the IPv6 network to the IPv4 world, but the IPv4 machine needs nothing special, not even a knowledge that IPv6 exists.
Well, you still can use NAT on your home network, it's just that you don't have to. You won't need to get a block of IP addresses assigned to you, you'll get one by default. The smallest assignment your ISP will be able to give you (without violating the IPv6 spec) will be a/64. Since IPv6 addresses are 128 bits, that gives you a 64-bit block (4 billion IPv4-sized networks) to assign your own machines in. For the average user who doesn't care about subnetting within their home network, that means just allowing automatic address assignment (based on the MAC address of the machine and the IPv6 router-discovery protocol results) or a simple DHCPv6 setup (built into your router) to do it's thing.
Except that the IPv6 design is backwards-compatible. Any IPv4 address has, per the IPv6 spec, an IPv6 representation, so any IPv6 machine can talk to a machine that has only IPv4 connectivity. Likewise, if your IPv6 machine also has an IPv4 address, there's a defined transformation to allow traffic to it's IPv4 address to be handled by the IPv6 stack. Most IPv6 stacks include all this functionality internally already.
And yes, IPv6 is radically different from IPv4. It's different for the same reasons a Freightliner semi tractor's radically different from a Mini Cooper: it's designed to do things the Mini's incapable of. Sure, you can redesign a semi tractor to be similar to the Mini, use the same parts as the Mini and all that, but in doing so you'd make the tractor cease to be a semi tractor and cease to be capable of doing what you wanted a semi tractor for.
You're assuming that most IT people went in initially with the "attitude". Most of us didn't. We developed the "attitude" after years of exposure to the business side making promises on behalf of the technical people without consulting them, then screaming when the technical people told them all resources were already committed to the current projects and if business wanted this new thing done they'd have to decide which of the other things they'd asked for would get set aside to free up people. Or asking for our best estimate of how long something will take, and then when we give it they go "That's not acceptable. We promised the customer we'd deliver in half that time, and we can't accept any estimate higher than that.". After a few repeats of Dilbert's manager, it's hard not to lose respect for them.
Re:Some geeks fail to grasp the purpose of IT
on
Tech Vs. Business?
·
· Score: 1
Yes, but there's another point there too: all too often if the servers aren't running, the business isn't running. The business folks often fail to grasp that concept.
NB: this is an attitude I see often from business, and it's one of the reasons I think techies dislike the business side. Business demands that the techies respect them and acknowledge their positions, but at the same time refuse to respect the techies or acknowledge their positions. Yes, sometimes what I have to say may not be exactly what the business people want to hear, but I wasn't hired to tell them what they want to hear. I was hired to tell them what's technically possible and, given that constraint, what's the best way to get from where we are to where they want to be. Sometimes that means taking a detour, just like a truck load that's too high for a bridge on a highway needs to turn off and take a detour around the bridge. You don't yell at that truck driver for refusing to take the short route and plow his load into the bridge, do you? Even if it means taking more time and costing more money, you don't want to destroy your cargo.
"The most exciting phrase in science, the one that heralds a new discovery, is rarely "Eureka!" and more often "That's funny. It's not supposed to do that..."."
When I interview, I use those basic-skills tests to weed out the ones who simply don't know what they're claiming on their resumes. I'd love to not have to do this, but 50% of our applicants claiming 5+ years experience in C/C++ programming can't pass even a basic C/C++ programming test. So we use the test to avoid wasting our time and the applicant's time when the applicant isn't even remotely qualified for the position. I don't see changing this until I see a significant reduction in the weed-out rate.
Are you willing to turn that around? Face it, as an employer and a manager your company and you reflect on me professionally when I work for you. If the company's involved in shenanigans, I'm going to catch the fallout. Think about any technical type still employed at SCO, for instance. If you as a manager pull borderline-unethical stunts, future employers will be wondering if I share those same questionable ethics. So are you OK with me as an employee digging up your credit history and arrest record and everything else, digging up all the internal financial and strategic details your company'd rather not have anyone outside the company knowing about, to go through with a fine-tooth comb to decide if I want to take the risk of working for you?
I tend to create profiles just to insure nobody else creates one in my name. Of course the profiles just have my name, the city I live in, birthdate, that sort of minimal information. If an employer demands to see it, they're welcome to it.
Yes. Google for "little ice age". That's the last time there was a serious drop in solar activity. Basically, sunspots are a proxy for activity in the solar furnace: the fewer sunspots, the lower the sun's energy output. Less solar output means less solar heating of Earth and lower global temperatures. One month isn't going to make a difference, but if the sun goes into a prolonged period of low activity (lasting a full solar cycle or more) we'll notice the results.
No, he didn't. What's to stop someone from claiming to have authorization? Think a minute. When was the last time, when paying by automatic debit from your account (e-check), you told your bank that the merchant had authorization? You didn't. You told the merchant he had authorization, but the bank is simply trusting that he does. So what exactly stops a fraudster from claiming he's got authorization too?
Actually I know a fair number of people who won't fly particular airlines if there's any reasonable alternative available because of the bad service they've gotten from them. It's obviously not unlimited, for instance they might be willing to pay an extra 10% to avoid the undesirable airline but not an extra 30%, but they will pay a certain amount extra not to have to deal with something they've had problems with before.
I suspect it's a "You knew it was wrong." feature. It's not intended to stop people from stealing the data so much as to make it impossible for them to claim they didn't know they weren't supposed to. Much like a simple chain-link fence with a locked gate: the lock isn't really stopping anybody, it's trivial to jump/climb over the fence and bypass the lock completely, but there's no way you can do that and claim you didn't realize somebody intended access to be restricted. Same thing here, if your software understands that flag and does the decryption needed nobody's going to believe you if you claim you didn't realize the font had restrictions on it.
The media may survive and be theoretically readable, but nobody will be able to read it. 25 years ago was 1983. The IBM PC was only 2 years old, the PC/XT had just been introduced. The IDE interface you hope will be around in 25 years? It didn't exist then. It didn't appear until 1986, and wasn't standardized (as ATA) until 1994. And it's at this point been all but replaced by SATA (I expect EIDE/ATAPI CD/DVD drives to be completely replaced by SATA ones by next year). The standard disk interfaces 25 years ago? ST-506, ESDI and SCSI. I don't expect changes in drive interfaces to slow down any, so expect in 25 years that even if you include the drive nobody's going to have a controller interface to plug it into. 9-track mag tape, 8" floppies, 5.25" floppies, punch cards, all those were standard digital media 25 years ago and you'd be hard-pressed to find equipment to read the media or computers that can interface with the equipment if you do find it.
Slashdot Mirror
True. But riddle me this: when you get up tomorrow and go to sign in to GMail and all you get is a single page saying "Due to financial constraints and an inability to derive revenue from GMail to pay our bills, we have regretfully been forced to terminate the service.", where are your game serial numbers now and how do you plan on getting at them? I know it seems unlikely Google would just drop a service like that. Except that, well, they already have.
Agreed. The tests will tell you if you broke anything they test in a way they test for. In any real-world application, though, you end up with untested and untestable interactions between components. Worse, you end up with errors that aren't bugs in the implementation, they're bugs in the component specification. The tests pass because the component's doing what it's supposed to do, but that causes the entire system to fail when you get to integration testing because what it's supposed to do isn't what it needs to do. That's why programmers have the term "broken as designed".
The voting system shouldn't need to be open-source. In fact I'd go so far as to say that any electronic voting system that requires the voting machines to be open-source is fundamentally flawed and shouldn't be trusted. The system should be designed so that it doesn't matter whether the machines themselves are recording correctly or not, it's still possible to determine whether the counts are correct (ie. match the intent of the voter) or not and ideally to be able to reconstruct the correct count.
Yes, it can be done. Anyone who accounts for money has been doing it for centuries. Any lowly night auditor at a hotel can explain the principles complete with examples.
$75K gross. Less Federal taxes, state taxes, insurance premiums, etc. etc.. At that level you can figure about 35% of your paycheck going to taxes and deductions (401K isn't optional if you expect not to be living in a cardboard box and eating dog food during your retirement). So for a $75K/year job, figure about $4K/month net income. For a 1-bedroom apartment in San Diego, you're talking around $1100/month in rent. For a family figure at least a 2-bedroom house, those will run you at least $2K/month. For a median-priced house in San Diego county at expected rates, the mortgage payments alone will run you $2-2.5K/month and that's before you pay homeowner's insurance and all the other bills that come with a house. So you're looking at anywhere from about 25% to over 50% of your monthly income just for basic housing costs.
I've been doing this kind of throttling on a per-connection basis for a long time. I needed to set up the packet scheduler on my Linux-based router correctly, but now it's configured to watch connections and any connection that eats a lot of sustained bandwidth gets bumped down to bulk-transfer priority. Packets for those connections go to the back of the queue and get to share the bandwidth left over after everything at a higher priority's gotten what it needs, subject to a hard cap of 80% (20% of total bandwidth is reserved for non-bulk-transfer connections at all times). That lets me start a large file download and quickly have it shunted off to soaking up only otherwise-unused bandwidth, letting games and other low-bandwidth applications continue pretty much unaffected. If I can do it on a cheap Linux box I'm pretty sure a high-end Cisco router can handle it too, it's just a matter of configuring it.
You can't fix this. Only the manager can fix it, by realizing his first, basic mistake: when he thought IT needed something, he went off on his own deciding what it was they wanted instead of asking "What do you need to do that?". Even if the manager understood IT jargon, he shouldn't have been going off deciding what to get in the way of IT equipment without asking that question and getting an answer first. This is, in fact, the basic problem I see between business and IT: that business goes making decisions about IT matters without consulting IT first or without giving weight to IT's advice. No businessman would go making or accepting a contract without consulting the company's lawyers and heeding their advice, yet that's exactly what's routinely done when it comes to IT matters.
You lose on density, though. Aisle space in front of the racks is fixed, you need a certain amount for humans to move in. Shallow, tall equipment means fewer units per rack. With a current-format rack you need say a 3'-deep area for the rack and a 3'-wide aisle for access. That's 50% equipment and 50% access. If the racks were only 1' deep instead, you'd be using 25% for equipment and 75% for access (since you still need that 3' wide aisle). And in that 25% of space for equipment you now get perhaps 25% of the amount of equipment since each one's using 4x more vertical space in the rack and rack height can't change (it's limited by basically how high off the floor a human can reach to get to the equipment).
To make up for that, you need more square footage of data center to hold the equipment. That increases operating costs, which is what we're trying to reduce.
Well, it makes sense. Normal PCs run on essentially ambient air, and live for years even under heavy loads (games put a lot of load on systems) despite all the dust and cruft. Servers aren't that different in their hardware, so it makes sense they'd behave similarly. And there's a lot that can be done cheaply to reduce the problems that were seen. Dust, for instance. You can filter and scrub dust from the incoming air a lot cheaper than running a full-on AC system. In fact the DX system used on the one side of the test probably scrubbed the incoming air itself, which would explain the lower failure rate there. Reduce the dust, you reduce the build-up of the thermal-insulating layer on the equipment and keep cooling effectiveness from degrading. Humidity control can also be done cheaper than full-on AC, and wouldn't have to be complete. I don't think you'd need to hold humidity steady within tight parameters, just keep the maximum from going above say 50% and the minimum from going below 5%. Again I'll bet the DX system did just that automatically. I'd bet you could remove the sources of probably 80% of the extra failures on the free-cooling side while keeping 90% of the cost savings in the process.
I could, but the WRT54 series is a router not an access point. I have a completely different configuration: a dedicated NIC on the primary router box going to a switch that all the access points attach to, with the APs providing only the wired-to-wireless bridge and the router box handling all routing, DHCP, VPN termination, etc.. I'd prefer to keep that configuration so I can manage everything at a single central point (and have a much more powerful machine there too to handle heavy-duty VPN encryption tasks, Web proxy and assorted other things).
The cost of having (probably) Cisco write custom firmware for all their equipment, and the cost of maintaining that custom firmware. It's possible to get the routers to handle a /128 assignment, but you're fighting the equipment the whole way. And it fails to work with Windows, whose IPv6 stack assumes that IPv6 stateless autoconfig works properly and doesn't play well with routers that refuse to accept the stack's use of it's own MAC-address-based value in the lower 64 bits. Again this can be worked around, but it takes a lot of heavy messing-about in low-level configuration to make it all work right. And how many ISPs are going to tell their customers that the ISP doesn't support Windows?
Dual IPv4/IPv6 stack. Almost all IPv6 stacks today are dual stacks, you usually have to play some interesting configuration tricks to create a true IPv6-only, no IPv4 support at all, host. Generally the source address is handled by the stack, which'll select the IPv4-mapped adapter address as the source address when sending to an IPv4-mapped destination address. Unless you're using a 6-to-4 bridge, in which case the bridge will handle the address translation if the source host has no IPv4-mapped adapter address.
Yeah, I'm in the process of turning on IPv6 on my home network, and I'm ironing out all the kinks. The big one's the consumer WAP that doesn't understand IPv6 at all, which I'm dealing with by using IPSec VPN tunnels.
The IPv4 machine doesn't need an IPv6 address to reply. It replies to the IPv4-compatible address the IPv6 host is using. Now, the IPv6 machine needs either a dual stack (allowing it an IPv4 and an IPv6 address) or a 6-to-4 bridge connecting the IPv6 network to the IPv4 world, but the IPv4 machine needs nothing special, not even a knowledge that IPv6 exists.
Well, you still can use NAT on your home network, it's just that you don't have to. You won't need to get a block of IP addresses assigned to you, you'll get one by default. The smallest assignment your ISP will be able to give you (without violating the IPv6 spec) will be a /64. Since IPv6 addresses are 128 bits, that gives you a 64-bit block (4 billion IPv4-sized networks) to assign your own machines in. For the average user who doesn't care about subnetting within their home network, that means just allowing automatic address assignment (based on the MAC address of the machine and the IPv6 router-discovery protocol results) or a simple DHCPv6 setup (built into your router) to do it's thing.
Except that the IPv6 design is backwards-compatible. Any IPv4 address has, per the IPv6 spec, an IPv6 representation, so any IPv6 machine can talk to a machine that has only IPv4 connectivity. Likewise, if your IPv6 machine also has an IPv4 address, there's a defined transformation to allow traffic to it's IPv4 address to be handled by the IPv6 stack. Most IPv6 stacks include all this functionality internally already.
And yes, IPv6 is radically different from IPv4. It's different for the same reasons a Freightliner semi tractor's radically different from a Mini Cooper: it's designed to do things the Mini's incapable of. Sure, you can redesign a semi tractor to be similar to the Mini, use the same parts as the Mini and all that, but in doing so you'd make the tractor cease to be a semi tractor and cease to be capable of doing what you wanted a semi tractor for.
You're assuming that most IT people went in initially with the "attitude". Most of us didn't. We developed the "attitude" after years of exposure to the business side making promises on behalf of the technical people without consulting them, then screaming when the technical people told them all resources were already committed to the current projects and if business wanted this new thing done they'd have to decide which of the other things they'd asked for would get set aside to free up people. Or asking for our best estimate of how long something will take, and then when we give it they go "That's not acceptable. We promised the customer we'd deliver in half that time, and we can't accept any estimate higher than that.". After a few repeats of Dilbert's manager, it's hard not to lose respect for them.
Yes, but there's another point there too: all too often if the servers aren't running, the business isn't running. The business folks often fail to grasp that concept.
NB: this is an attitude I see often from business, and it's one of the reasons I think techies dislike the business side. Business demands that the techies respect them and acknowledge their positions, but at the same time refuse to respect the techies or acknowledge their positions. Yes, sometimes what I have to say may not be exactly what the business people want to hear, but I wasn't hired to tell them what they want to hear. I was hired to tell them what's technically possible and, given that constraint, what's the best way to get from where we are to where they want to be. Sometimes that means taking a detour, just like a truck load that's too high for a bridge on a highway needs to turn off and take a detour around the bridge. You don't yell at that truck driver for refusing to take the short route and plow his load into the bridge, do you? Even if it means taking more time and costing more money, you don't want to destroy your cargo.
"The most exciting phrase in science, the one that heralds a new discovery, is rarely "Eureka!" and more often "That's funny. It's not supposed to do that..."."
When I interview, I use those basic-skills tests to weed out the ones who simply don't know what they're claiming on their resumes. I'd love to not have to do this, but 50% of our applicants claiming 5+ years experience in C/C++ programming can't pass even a basic C/C++ programming test. So we use the test to avoid wasting our time and the applicant's time when the applicant isn't even remotely qualified for the position. I don't see changing this until I see a significant reduction in the weed-out rate.
Are you willing to turn that around? Face it, as an employer and a manager your company and you reflect on me professionally when I work for you. If the company's involved in shenanigans, I'm going to catch the fallout. Think about any technical type still employed at SCO, for instance. If you as a manager pull borderline-unethical stunts, future employers will be wondering if I share those same questionable ethics. So are you OK with me as an employee digging up your credit history and arrest record and everything else, digging up all the internal financial and strategic details your company'd rather not have anyone outside the company knowing about, to go through with a fine-tooth comb to decide if I want to take the risk of working for you?
I tend to create profiles just to insure nobody else creates one in my name. Of course the profiles just have my name, the city I live in, birthdate, that sort of minimal information. If an employer demands to see it, they're welcome to it.
Yes. Google for "little ice age". That's the last time there was a serious drop in solar activity. Basically, sunspots are a proxy for activity in the solar furnace: the fewer sunspots, the lower the sun's energy output. Less solar output means less solar heating of Earth and lower global temperatures. One month isn't going to make a difference, but if the sun goes into a prolonged period of low activity (lasting a full solar cycle or more) we'll notice the results.
No, he didn't. What's to stop someone from claiming to have authorization? Think a minute. When was the last time, when paying by automatic debit from your account (e-check), you told your bank that the merchant had authorization? You didn't. You told the merchant he had authorization, but the bank is simply trusting that he does. So what exactly stops a fraudster from claiming he's got authorization too?
Actually I know a fair number of people who won't fly particular airlines if there's any reasonable alternative available because of the bad service they've gotten from them. It's obviously not unlimited, for instance they might be willing to pay an extra 10% to avoid the undesirable airline but not an extra 30%, but they will pay a certain amount extra not to have to deal with something they've had problems with before.
I suspect it's a "You knew it was wrong." feature. It's not intended to stop people from stealing the data so much as to make it impossible for them to claim they didn't know they weren't supposed to. Much like a simple chain-link fence with a locked gate: the lock isn't really stopping anybody, it's trivial to jump/climb over the fence and bypass the lock completely, but there's no way you can do that and claim you didn't realize somebody intended access to be restricted. Same thing here, if your software understands that flag and does the decryption needed nobody's going to believe you if you claim you didn't realize the font had restrictions on it.
The media may survive and be theoretically readable, but nobody will be able to read it. 25 years ago was 1983. The IBM PC was only 2 years old, the PC/XT had just been introduced. The IDE interface you hope will be around in 25 years? It didn't exist then. It didn't appear until 1986, and wasn't standardized (as ATA) until 1994. And it's at this point been all but replaced by SATA (I expect EIDE/ATAPI CD/DVD drives to be completely replaced by SATA ones by next year). The standard disk interfaces 25 years ago? ST-506, ESDI and SCSI. I don't expect changes in drive interfaces to slow down any, so expect in 25 years that even if you include the drive nobody's going to have a controller interface to plug it into. 9-track mag tape, 8" floppies, 5.25" floppies, punch cards, all those were standard digital media 25 years ago and you'd be hard-pressed to find equipment to read the media or computers that can interface with the equipment if you do find it.