That's why (if they're smart) there are three spare ISA cards on the shelf, or more, preferably already installed in identical machines.
I work with a group that has ISA-based cards for research data acquisition (EEG variant, if I remember correctly) with a study that's been running for 20+ years on the same subjects. They can't swap the hardware, because the output data wouldn't be directly comparable -- newer equipment is "better", but in terms of continuity for the research, they need the same, not better. There's a stack of old 286 or 386 machines in the basement, and we run a Netware server (since they were originally tested with the DOS Netware clients over IPX, we continue to use it) to get the data from those DOS boxes to something vaguely modern over NFS.
ISA also had the oddity that the clock speed for the bus wasn't fixed. It's variable based on CPU speed on the original systems, the last machines shipping with ISA would lock it at 8Mhz or so (i.e., a 1/4 multiplier on a 33Mhz bus CPU, like a 486DX2/66).
They've considered it. And they're probably terrified of that happening -- it's either going to mean the end of a research project, or a multi-million dollar expense along with a major disruption in work. If it was less dire than that, they probably would have already replaced it.
Based on what I've seen on Linux distributions (Ubuntu LTS in particular), Google's going to drop XP support quickly for Chrome. You might be able to get a chromium build on it, but I expect that Chrome proper will stop auto-updating shortly.
Jebus, dude. That was almost 15 years ago. If you're looking back that far at a company (that's not a startup), you'll find some mistake, some bad product. People don't talk about the Pinto anymore when you mention Ford.
Way late to answer, but you'll probably be notified.
Typical consumer drives are intended for relatively low-heat, low-vibration environments. The firmware on the drives is typically optimized for desktop access patterns, and will automatically slow or stop the motor to save power. The drive assembly itself is quite a bit different -- lower quality bearings, less isolation on the heads (protection from vibration). Datacenters are hot, noisy, and vibrate badly. Consumer drives fail in that environment at a lot higher rate.
Firmware is typically optimized very differently, for different access patterns, power usage, etc.
The same model consumer drive, over different revisions, may have different capacities. In a RAID-1 config, if the replacement drive, or the drive you buy to create the mirror, is a few hundred sectors smaller, there's no joy and no mirror. If I remember correctly, some consumer-targeted RAID controllers actually reserve a bit of the disk and don't present it to try to protect against that particular problem. I ran in to that a lot in the past, not as much recently, but it still happens. Hell, back in the mid-90s I had that happen with enterprise SCSI drives that weren't vetted through a vendor that pushed it -- same model of the Barracuda from a random cheap-ass vendor (Dirt Cheap Drives, if I remember correctly), different capacities. Ruined my bloody weekend.
Going outside the facts, and moving to the artificial reality of vendor contracts, HP or Oracle may well respond that they won't support something until you pull the consumer-grade shit out of the machine.
Now, after all of that -- I do use consumer drives in servers when it's worth it, and when I can afford the risk. My backup media servers (Netbackup) are Sun x4500s with 48 internal disks -- those disks have been swapped with cheap-ass WD 2TBs and have close to 100TB of available space. The disk is managed by ZFS with single-parity RAIDZ and is used for staging backups before pushing to tape to move offsite (weekly/monthly), and duplicated storage of short-term backups (daily).
I'll use it for scratch space, and I'll use it when I can afford to lose it (or at least lose access until I rebuild and restore). If there's data I care about on there, it's typically using ZFS so that block-level checksums are done and I'll at least know that the data is bad without silent corruption.
I've got shit to work with for budget (public higher education), and the cheapest reasonable "enterprise-like" disk I can get runs us about $400/TB usable -- Dell MD3200 SAS-connected array with dual controllers (four hosts redundant, 8 non-redundant, and it's really an OEM LSI Engenio (sp)). Best I can do for disk on the SAN is more like $600 (Nexsan, Dell/LSI MD32xx), and those prices aren't for a single TB purchase. Most SAN-connected disk is still in the $1000/TB range and higher. I'm counting these prices including support (NBD response, usually) for three years or so. The other constraint is that I want the vendor to exist in a few years and have some track record, and I need to be able to get it past purchasing, which usually means state-or-U-level contract -- I've had to support some random shit bought from HPC vendors, usually OEM'd Infortrend or similar, and don't want to deal with that shit ever again.
It's all about the application and level of risk that's acceptable for that app/system. I'll never stick shit disk on a SAN to use with a VMware cluster, but I will happily throw a pair of cheap disks in a standalone ESX server that's running developer VMs or testing. Prod systems need to be expensive shit, sadly, to avoid giving the vendor an excuse (I'm looking at you, Oracle).
The speed increase matters once in a great while too -- more RAM is usually more effective, and cheaper.
Which might make for some interesting theoretical attacks -- if I can craft a block with the same hash as a block I'm interested in, I can read the contents of the other block.
// Assume that an information-leak bug that allows the attacker to read the hash values and other metadata necessary, which is entirely possible.
Then your company would likely frown on you working around that by indirectly syncing the personal machine as well. The technical measures in place that prevent you from connecting your laptop to Exchange are merely a way of enforcing policy. You're still violating the policy even if it doesn't stop you.
I don't give a shit, but I bet your company would.
I mostly agree with you, but ADB made it all the way from the Apple IIgs [1986] and IIc+ (6502/65816 CPU with Apple II OS), Mac SE (68000, System 5 or later), up through the beige PowerMac G3 [1998]. That's about a 12 year run. Even beyond that, it apparently was still used for internal keyboards on laptops until the Intel switch.
Because CoreData and the other improvements to the API and Xcode are useful. If y'all are programming for free, or nearly free (shareware), there's not much incentive to use older tools.
If you think we *want* to be stuck on IE 6, we don't. We don't really care. However, the developers wrote some asinine ActiveX shit that doesn't work on IE 7 or IE 8, and sure as fuck don't work on Firefox. Or, we're using PeopleSoft software that isn't certified on anything about IE 6, etc.
For XP? Well, by the time Vista was working well enough with the internal apps to roll out, Windows 7 was in beta. Why the hell would I go through upgrading everything to Vista just to have the same people turn around and want Windows 7 next week, but we can't afford to have any departments down for a day to reimage.
It comes down to the golden rule of the sysadmin -- if it's working, don't fuck with it.
I've dealt with enough developers that I'd say about 1/2 to 2/3 were competent, and some of those, while competent developers, didn't have anywhere near enough knowledge to be allowed to administer their own machine.
Of course, I'd probably say the same about 1/2 of the sysadmins I've worked with as well, and very few sysadmins have the knowledge to be competent developers. The higher percentage of incompetent sysadmins stems from not understanding security, or not understanding how to balance security with usability.
Note my use of the word knowledge -- most developers could be competent sysadmins, but don't have the knowledge base. If you're developing database-driven web applications using.NET, how likely are you to need to know details of filesystem ACLs, or how a rootkit may insert itself in to a OS kernel? How many sysadmins are going to know how to write (or even use) a database stored procedure, and more importantly,/when it's appropriate to do so?/
Unfortunately, most people don't have the wisdom to understand where their own knowledge ends. I understand quite a bit about a lot of topics, but I'm willing to let an expert (doctor, dentist, mechanic, athletic trainer, etc.) do their jobs. Why don't people have the same attitude about sysadmins? (Hint: I think it's because when you fuck up your car, you pay to fix it. If you fuck up your PC there's no direct financial penalty for you personally.)
You're focused on a large, complex problem. Someone interrupts you, and you have to go deal with them. When you get back to the large, complex problem, you lose a lot of time figuring out where you were and picking up the pieces of the troubleshooting.
That's not even factoring in that your co-worker called the help desk, someone there had a write a ticket, send it to a deskside support person, who had to leave their desk, come down, and do the "one minute" fix. Total time? Probably more like 30 minutes where your co-worker wasn't working.
I agree with one of the other posters -- I would have had *your* ass. Sending an email to the entire company to apologize to the tech? That's a cannon to kill a gnat -- but don't forget that you're the gnat, asshole.
If you really think the sysadmin is making the decision to block flickr, I (hope and expect) you're wrong. Generally, it's some asshole who's spending his day looking up nudists on flickr, someone else sees the monitor and complains, and because the asshole is the manager's nephew/golf buddy, the problem is that flickr.com was allowed -- tell the sysadmins to block it.
Even without that contrived scenario, if they're using a third-party service for the filter, like websense, you block a category -- porn, blogs, social networking, sports, gambling, etc. Because flickr has plenty of NSFW images, filters may include it in the porn category, as well as social networking (comments, friends, etc.)
If the filter is blocking it by default, in a non-work-related category (porn), how will you justify *un*blocking it?
Debian's a non-profit. Comparing the two isn't useful, for a couple of simple reasons. If a Debian build server is owned, what's the financial damage, and to who? How about Redhat?
It's a lot easier for RH to show direct and indirect financial damage due to a breach, which brings in the FBI. Once the FBI is involved, your whole reply is a "No comment." It's an ongoing federal investigation. If somebody found the trojaned openssh on a DoD server, you can bet that the NSA is probably involved as well.
Once the feds are involved, their hands are tied. If I'm right, it took a lot of work and negotiation by the lawyers to release as much info as they did.
They weren't owned for 6 days due to a redhat delay -- the trojaned packages didn't let the attackers install them remotely without hacking something else first.
You should change everything -- it doesn't matter what the openssh packages did, honestly, because they had root on the box. Did you reinstall the boxes, or just replace the SSH packages?
How much do other machines trust those, or have similar other (possibly zero-day) vulnerabilities? Do you know how they got in? Redhat's release of information related to this breach *had nothing to do with your servers being owned.* It had everything to do with you *discovering* they were owned.
There's also some insanity involved with the idea of distributed backup -- it's not so much thinking "inside the box," as thinking that backups are something you don't fuck around with. You can call that inside the box if you want to -- I personally don't agree with a large part of how the industry has gone -- I don't want to trust my backups completely to some third-party, not without significant assurances. I want physical copies (tapes, additional disks, etc.) well offsite. I want more than one copy. If at all possible, it's encrypted.
On a daily basis, I have to think about HIPAA, FERPA, PCI, and other private data, some of it going to international-incident level if it's breached. Someone gets hold of one of our backups, and it's a bloody world of hurt. Certified letters to every student at a major public university. Maybe, based on the state law that requires notification, letters to the population of Bolivia after the raw census data is leaked. Other nightmares...
I think the people telling you to just buy a SAN or other solutions are thinking of two costs you aren't. It's not just the cost of the software/hardware. It's the time involved -- can you afford for it to be down for an hour? Can you afford to spend hours fixing it, or updating it, with little or no documentation? If you're talking about using it for backups, can you afford either a data leak or data loss when a PC gets stolen by someone breaking in to the office, or a disgruntled employee rooting his own desktop box?
It might be worth it -- but for most of us, I don't think it would be. It'd be an excellent research project, though... I'd personally start with distributed replicated block devices, not filesystems. Have each block with a rev number and transaction log so that conflicts (and updates) can be handled when a node goes down or comes online. Build a filesystems over the top of it... but like you, I don't have six months or more of free time to do it.
For $DEITY's sake, the freaking RAZR sold for around $500 (with contract) at launch. Three months later, it was $100. Now, it's bloody free. Should I sue because I paid money for the RAZR when I could have gotten for free later? How about the Blackberry? That used to be $500.
Apple didn't think there was going to be a fucking backlash because this is normal fucking pricing for phones. The price drops off quickly. It's not a scam, it's standard business practice at AT&T, T-Mobile, Verizon, etc. Everybody's just pissed because Apple did it this time, and not Motorola or Nokia.
Ah, but UFS on a larger than 1TB filesystem sucks. The inode size becomes fixed at one inode per MB of disk. So, if you have small files on the disk, you're at 8% space used and a full disk because there are no free inodes.
Eh, I hate feeding trolls.
Hey, anonymous weaselnuts? Disk crash is a valid, and descriptive, term for a disk failure. The heads don't touch the disk -- this ain't your fscking vinyl record. If they touch, or *crash*, into the disk surface, bad things happen. It's a crash. Valid term. More correct would be head crash.
I've opened up a disk after the distinctive sound to see the beautiful half-millimeter deep groove in the surface of the platter and little strings of metal littering the inside. I've also sent disks that made the same distinctive sound to a data recovery service and gotten back data.
replacing 4mb L2 cash with 4 GB L2 cache would speed up most games, however spending that money on several components would be a better use for that same cash.
Actually, some chains have a "ID checks for everyone!" policy, and they send employees in to test. 65 year old man comes in, orders a beer with his meal. Server brings beer, is handed a red sheet of paper and leaves premises immediately, ne'er to return. Everyone gets ID'd, or the server gets fired. No exceptions.
Maybe a couple of pages of SRAM? Static RAM doesn't require refresh power, so it's non-volatile, but has none of the problems that flash does (like extraordinarily slow writes, or having a limited number of erase cycles.) It has its own problems, like being ridiculously expensive by comparison, but a 4K block should be enough to hold the map. I don't really know how the magi^H^H^H^H wear leveling works, just a guess.
That's why (if they're smart) there are three spare ISA cards on the shelf, or more, preferably already installed in identical machines.
I work with a group that has ISA-based cards for research data acquisition (EEG variant, if I remember correctly) with a study that's been running for 20+ years on the same subjects. They can't swap the hardware, because the output data wouldn't be directly comparable -- newer equipment is "better", but in terms of continuity for the research, they need the same, not better. There's a stack of old 286 or 386 machines in the basement, and we run a Netware server (since they were originally tested with the DOS Netware clients over IPX, we continue to use it) to get the data from those DOS boxes to something vaguely modern over NFS.
ISA also had the oddity that the clock speed for the bus wasn't fixed. It's variable based on CPU speed on the original systems, the last machines shipping with ISA would lock it at 8Mhz or so (i.e., a 1/4 multiplier on a 33Mhz bus CPU, like a 486DX2/66).
They've considered it. And they're probably terrified of that happening -- it's either going to mean the end of a research project, or a multi-million dollar expense along with a major disruption in work. If it was less dire than that, they probably would have already replaced it.
Based on what I've seen on Linux distributions (Ubuntu LTS in particular), Google's going to drop XP support quickly for Chrome. You might be able to get a chromium build on it, but I expect that Chrome proper will stop auto-updating shortly.
> Hitachi Deathstar
Jebus, dude. That was almost 15 years ago. If you're looking back that far at a company (that's not a startup), you'll find some mistake, some bad product. People don't talk about the Pinto anymore when you mention Ford.
Let it go, man.
Way late to answer, but you'll probably be notified.
Typical consumer drives are intended for relatively low-heat, low-vibration environments. The firmware on the drives is typically optimized for desktop access patterns, and will automatically slow or stop the motor to save power. The drive assembly itself is quite a bit different -- lower quality bearings, less isolation on the heads (protection from vibration). Datacenters are hot, noisy, and vibrate badly. Consumer drives fail in that environment at a lot higher rate.
Firmware is typically optimized very differently, for different access patterns, power usage, etc.
The same model consumer drive, over different revisions, may have different capacities. In a RAID-1 config, if the replacement drive, or the drive you buy to create the mirror, is a few hundred sectors smaller, there's no joy and no mirror. If I remember correctly, some consumer-targeted RAID controllers actually reserve a bit of the disk and don't present it to try to protect against that particular problem. I ran in to that a lot in the past, not as much recently, but it still happens. Hell, back in the mid-90s I had that happen with enterprise SCSI drives that weren't vetted through a vendor that pushed it -- same model of the Barracuda from a random cheap-ass vendor (Dirt Cheap Drives, if I remember correctly), different capacities. Ruined my bloody weekend.
Going outside the facts, and moving to the artificial reality of vendor contracts, HP or Oracle may well respond that they won't support something until you pull the consumer-grade shit out of the machine.
Now, after all of that -- I do use consumer drives in servers when it's worth it, and when I can afford the risk. My backup media servers (Netbackup) are Sun x4500s with 48 internal disks -- those disks have been swapped with cheap-ass WD 2TBs and have close to 100TB of available space. The disk is managed by ZFS with single-parity RAIDZ and is used for staging backups before pushing to tape to move offsite (weekly/monthly), and duplicated storage of short-term backups (daily).
I'll use it for scratch space, and I'll use it when I can afford to lose it (or at least lose access until I rebuild and restore). If there's data I care about on there, it's typically using ZFS so that block-level checksums are done and I'll at least know that the data is bad without silent corruption.
I've got shit to work with for budget (public higher education), and the cheapest reasonable "enterprise-like" disk I can get runs us about $400/TB usable -- Dell MD3200 SAS-connected array with dual controllers (four hosts redundant, 8 non-redundant, and it's really an OEM LSI Engenio (sp)). Best I can do for disk on the SAN is more like $600 (Nexsan, Dell/LSI MD32xx), and those prices aren't for a single TB purchase. Most SAN-connected disk is still in the $1000/TB range and higher. I'm counting these prices including support (NBD response, usually) for three years or so. The other constraint is that I want the vendor to exist in a few years and have some track record, and I need to be able to get it past purchasing, which usually means state-or-U-level contract -- I've had to support some random shit bought from HPC vendors, usually OEM'd Infortrend or similar, and don't want to deal with that shit ever again.
It's all about the application and level of risk that's acceptable for that app/system. I'll never stick shit disk on a SAN to use with a VMware cluster, but I will happily throw a pair of cheap disks in a standalone ESX server that's running developer VMs or testing. Prod systems need to be expensive shit, sadly, to avoid giving the vendor an excuse (I'm looking at you, Oracle).
The speed increase matters once in a great while too -- more RAM is usually more effective, and cheaper.
Which might make for some interesting theoretical attacks -- if I can craft a block with the same hash as a block I'm interested in, I can read the contents of the other block.
// Assume that an information-leak bug that allows the attacker to read the hash values and other metadata necessary, which is entirely possible.
Then your company would likely frown on you working around that by indirectly syncing the personal machine as well. The technical measures in place that prevent you from connecting your laptop to Exchange are merely a way of enforcing policy. You're still violating the policy even if it doesn't stop you.
I don't give a shit, but I bet your company would.
I mostly agree with you, but ADB made it all the way from the Apple IIgs [1986] and IIc+ (6502/65816 CPU with Apple II OS), Mac SE (68000, System 5 or later), up through the beige PowerMac G3 [1998]. That's about a 12 year run. Even beyond that, it apparently was still used for internal keyboards on laptops until the Intel switch.
Because CoreData and the other improvements to the API and Xcode are useful. If y'all are programming for free, or nearly free (shareware), there's not much incentive to use older tools.
I would write a critique of your spelling, but I don't think it'd matter. You must be a developer. ;)
(just kidding, really.)
If you think we *want* to be stuck on IE 6, we don't. We don't really care. However, the developers wrote some asinine ActiveX shit that doesn't work on IE 7 or IE 8, and sure as fuck don't work on Firefox. Or, we're using PeopleSoft software that isn't certified on anything about IE 6, etc.
For XP? Well, by the time Vista was working well enough with the internal apps to roll out, Windows 7 was in beta. Why the hell would I go through upgrading everything to Vista just to have the same people turn around and want Windows 7 next week, but we can't afford to have any departments down for a day to reimage.
It comes down to the golden rule of the sysadmin -- if it's working, don't fuck with it.
Need? No.
It sure does make life easier. 'Course, ctags and vim will do the same, if you know how to use it.
I've dealt with enough developers that I'd say about 1/2 to 2/3 were competent, and some of those, while competent developers, didn't have anywhere near enough knowledge to be allowed to administer their own machine.
Of course, I'd probably say the same about 1/2 of the sysadmins I've worked with as well, and very few sysadmins have the knowledge to be competent developers. The higher percentage of incompetent sysadmins stems from not understanding security, or not understanding how to balance security with usability.
Note my use of the word knowledge -- most developers could be competent sysadmins, but don't have the knowledge base. If you're developing database-driven web applications using .NET, how likely are you to need to know details of filesystem ACLs, or how a rootkit may insert itself in to a OS kernel? How many sysadmins are going to know how to write (or even use) a database stored procedure, and more importantly, /when it's appropriate to do so?/
Unfortunately, most people don't have the wisdom to understand where their own knowledge ends. I understand quite a bit about a lot of topics, but I'm willing to let an expert (doctor, dentist, mechanic, athletic trainer, etc.) do their jobs. Why don't people have the same attitude about sysadmins? (Hint: I think it's because when you fuck up your car, you pay to fix it. If you fuck up your PC there's no direct financial penalty for you personally.)
It's not "one minute out of work."
You're focused on a large, complex problem. Someone interrupts you, and you have to go deal with them. When you get back to the large, complex problem, you lose a lot of time figuring out where you were and picking up the pieces of the troubleshooting.
That's not even factoring in that your co-worker called the help desk, someone there had a write a ticket, send it to a deskside support person, who had to leave their desk, come down, and do the "one minute" fix. Total time? Probably more like 30 minutes where your co-worker wasn't working.
I agree with one of the other posters -- I would have had *your* ass. Sending an email to the entire company to apologize to the tech? That's a cannon to kill a gnat -- but don't forget that you're the gnat, asshole.
If you really think the sysadmin is making the decision to block flickr, I (hope and expect) you're wrong. Generally, it's some asshole who's spending his day looking up nudists on flickr, someone else sees the monitor and complains, and because the asshole is the manager's nephew/golf buddy, the problem is that flickr.com was allowed -- tell the sysadmins to block it.
Even without that contrived scenario, if they're using a third-party service for the filter, like websense, you block a category -- porn, blogs, social networking, sports, gambling, etc. Because flickr has plenty of NSFW images, filters may include it in the porn category, as well as social networking (comments, friends, etc.)
If the filter is blocking it by default, in a non-work-related category (porn), how will you justify *un*blocking it?
-30-
Debian's a non-profit. Comparing the two isn't useful, for a couple of simple reasons. If a Debian build server is owned, what's the financial damage, and to who? How about Redhat?
It's a lot easier for RH to show direct and indirect financial damage due to a breach, which brings in the FBI. Once the FBI is involved, your whole reply is a "No comment." It's an ongoing federal investigation. If somebody found the trojaned openssh on a DoD server, you can bet that the NSA is probably involved as well.
Once the feds are involved, their hands are tied. If I'm right, it took a lot of work and negotiation by the lawyers to release as much info as they did.
They weren't owned for 6 days due to a redhat delay -- the trojaned packages didn't let the attackers install them remotely without hacking something else first.
You should change everything -- it doesn't matter what the openssh packages did, honestly, because they had root on the box. Did you reinstall the boxes, or just replace the SSH packages?
How much do other machines trust those, or have similar other (possibly zero-day) vulnerabilities? Do you know how they got in? Redhat's release of information related to this breach *had nothing to do with your servers being owned.* It had everything to do with you *discovering* they were owned.
On a daily basis, I have to think about HIPAA, FERPA, PCI, and other private data, some of it going to international-incident level if it's breached. Someone gets hold of one of our backups, and it's a bloody world of hurt. Certified letters to every student at a major public university. Maybe, based on the state law that requires notification, letters to the population of Bolivia after the raw census data is leaked. Other nightmares...
I think the people telling you to just buy a SAN or other solutions are thinking of two costs you aren't. It's not just the cost of the software/hardware. It's the time involved -- can you afford for it to be down for an hour? Can you afford to spend hours fixing it, or updating it, with little or no documentation? If you're talking about using it for backups, can you afford either a data leak or data loss when a PC gets stolen by someone breaking in to the office, or a disgruntled employee rooting his own desktop box?
It might be worth it -- but for most of us, I don't think it would be. It'd be an excellent research project, though... I'd personally start with distributed replicated block devices, not filesystems. Have each block with a rev number and transaction log so that conflicts (and updates) can be handled when a node goes down or comes online. Build a filesystems over the top of it... but like you, I don't have six months or more of free time to do it.
For $DEITY's sake, the freaking RAZR sold for around $500 (with contract) at launch. Three months later, it was $100. Now, it's bloody free. Should I sue because I paid money for the RAZR when I could have gotten for free later? How about the Blackberry? That used to be $500.
Apple didn't think there was going to be a fucking backlash because this is normal fucking pricing for phones. The price drops off quickly. It's not a scam, it's standard business practice at AT&T, T-Mobile, Verizon, etc. Everybody's just pissed because Apple did it this time, and not Motorola or Nokia.
Ah, but UFS on a larger than 1TB filesystem sucks. The inode size becomes fixed at one inode per MB of disk. So, if you have small files on the disk, you're at 8% space used and a full disk because there are no free inodes.
It's an ugly hack, and it doesn't count.
Eh, I hate feeding trolls. Hey, anonymous weaselnuts? Disk crash is a valid, and descriptive, term for a disk failure. The heads don't touch the disk -- this ain't your fscking vinyl record. If they touch, or *crash*, into the disk surface, bad things happen. It's a crash. Valid term. More correct would be head crash. I've opened up a disk after the distinctive sound to see the beautiful half-millimeter deep groove in the surface of the platter and little strings of metal littering the inside. I've also sent disks that made the same distinctive sound to a data recovery service and gotten back data.
Do at least two passes, or the wear leveling may burn your ass. Hint: a 1G flash drive has a greater than 1G internal capacity.
It was "cash" vs. "cache" in the same sentence that killed me. Sorry.
This makes my brain hurt.
Actually, some chains have a "ID checks for everyone!" policy, and they send employees in to test. 65 year old man comes in, orders a beer with his meal. Server brings beer, is handed a red sheet of paper and leaves premises immediately, ne'er to return. Everyone gets ID'd, or the server gets fired. No exceptions.
Made my father's day.
Maybe a couple of pages of SRAM? Static RAM doesn't require refresh power, so it's non-volatile, but has none of the problems that flash does (like extraordinarily slow writes, or having a limited number of erase cycles.) It has its own problems, like being ridiculously expensive by comparison, but a 4K block should be enough to hold the map. I don't really know how the magi^H^H^H^H wear leveling works, just a guess.