The good thing is that degrees of maintaining should emerge. There is the obvious, such as an oil pressure loss which means the vehicle moves to the side and phones a tow truck.
However, stuff on lower tiers. Lets assume headlights get multiple LED arrays in them. One array fails, so the car schedules a visit to the mechanic at night [1] so things can get fixed while the owner is asleep. Similar if a car's radio needs a firmware upgrade [2].
[1]: If the market niche appears for self-driving cars to hit a garage, you bet that there will be both car dealers and independent shops that would be open for business late at night... and they will make money, because people are far more willing to pay a premium for a car to be fixed and there in the morning than spend taxi fares and such to drop a vehicle off in the day.
[2]: With a self-driving car, no real need for the security issue for OTA firmware upgrades. Just have the vehicle head to a shop where a physical flash is done. This could even be automated so a car just stops in, gets plugged in, the new firmware upgraded and tested (or changed backed out), and the car then returns back to its owner.
I've seen HW and SW RAID leapfrog each other. Before Oracle bought Sun, there was a time where Sun pushed software RAID and Veritas Volume Manager, saying how CPU is cheap so might as well use it for drive I/O. A year or two later, they came out with hardware RAID appliances and the sales guys pushed how good having all the CPU overhead of party generation done on disk controllers was.
HW and SW raid I use on an application basis. For enterprise tasks, this tends to be moot because the data resides on FC/FCoE LUNs, and the only time I might worry about using RAID on the system side would be if I were migrating data from one SAN to another without shutting things down. Local disk tends to be more an afterthought (mainly because it tends not to have the ability to use MPIO), so it ends up being mirrored, just out of simplicity.
Of course, for desktops that are used on a day to day basis, those get hardware RAID so a drive failure means a SNMP trap firing off and a trouble ticket to desktop support versus a user screaming bloody murder.
The best is having both RAID6 and at least a hot spare. With the difference between disk capacities versus I/O so disparate, even with two drives, there is a large window (~24 hours in some cases, even on the high end SANs and lower tier drives) where the array is in a degraded state and is being rebuilt. The hot spare is important in this case because it allows the array to start being rebuilt immediately.
The ironic thing is that tier 3 drives store a lot of critical data, even though they are relatively cheap and slow. Because of this, taking reasonable measures such as RAID 6 + a hot spare or two is a must.
One thing I'd recommend is going with a RAID 1 setup for the HDDs. Drive failure is still a constant issue, and there is a big difference between seeing a dialog that pops up and going "crap, time to replace a drive", compared to hoping you have a recent backup... somewhere. Even if documents are saved on Dropbox or backed up via Mozy, it still is a PITA to reload/activate the OS, reload/activate apps, etc.
For SSDs, I have not seen any concrete proof that they are any more reliable than HDDs, so I'd have a second controller and have those mirrored or RAID-ed as well, so their I/O performance isn't linked to the I/O of the slower HDDs.
I would not mind seeing SSDs and HDDs merge, with a smart "SAN in a can" drive controller. This drive controller would do autotiering. If a region of blocks is used often, it gets moved to the SSD. If more areas get used more frequently, that set of blocks goes to the spinning platters. This way, over time (assuming consistent usage), there is a good balance between SSD speed and the capacity of traditional HDD.
I like Droidwall, have been using it since the 1.x days. Yes, it does require root, but it is worth using. Oddly enough, on rooted Motorola phones, it takes a while to push the iptables entries out when you tell it to. On HTC phones, it is a lot quicker.
Another app that I used to use was LBE Privacy Guard, but it doesn't work on Andoid 4.1 or newer (will bootloop your phone if you try.) I know it is a free app, but when it worked, it was a very useful tool, as it limited what apps could access (contacts, GPS, phone) without having to manually edit permissions in a manifest file.
My mind gets blown by sites that demand you authenticate from FB in order to use functions like posting, seeing pictures, and other stuff.
Call me crazy, but basic security 101 just says that you don't trust another site with the keys to your kingdom... especially with zero assurance that it might even work.
The thing is, we can always sacrifice freedom for security. It is a one way ratchet. Going the other way usually is only done in a complete revolution.
A more mundane use would be things like car or RV covers. Cover the rig, plug the cover into a smart battery charger, walk off.
Even more simple, just something to toss over a roof and fasten into place with double-sided tape (perhaps Velcro.) The result would be useful power, but without sacrificing repairability, other than the added weight.
I can see 486 machines (I'm guessing 4-16 MB of RAM) still being used in embedded controllers because ripping them out and replacing them with modern equipment would screw up the machinery and software timing. MS-DOS isn't pretty, but it can be used as a platform for realtime operations even though the OS isn't technically realtime.
I can't judge, as I don't know the situation. I've been in situations where I've scoffed at older machines in use, then found that because of a certain embedded task, there was no way to replace them.
However, if they are "just" being used as workstations, might as well P2V the desktops, replace the 486 machines with machines that have a RAID card and two drives (to minimize the chance of drive failure outages), and let the users boot to their VMs. One also can add another disk or two with use with wbadmin for backups, as well as automatic snapshots of the VM.
The same reason I use pick-resistant padlocks on storages: Someone getting the lock off will leave a signature.
Yes, the angle grinder will knock a boron shackle off in seconds flat, there will be some sort of proof of forced entry, either because the lock is missing, or the fact that there are obvious cuts on the wall. When placing a claim with an insurance company, it is a LOT easier to get them to play when there are obvious signs that someone forced their way in, as opposed to a picked/bumped lock which in some cases gives zero signes of entry.
Insurance companies are a lot more likely to pay when the adjuster comes by and sees chainsaw marks on a wall, as opposed to no signs of any forced entry whatsoever.
Then, there is the criminal aspect. If a thief picks a lock and enters... they may score a trespass charge, but no B&E. Forcing their way in, that is a definite felony, assuming they ever get caught.
So, I'll keep my high security locks. Yes, they are by-passable, but they give protection in another arena, the legal one.
Connections are fairly straightforward. You have your NICs (be it copper, fiber, 10gigE, 100gigE, etc.) This can vary. Then you have a dedicated Ethernet adapter for an offline configuration process. Here, you plug a laptop in, go to 192.168.0.1, and do the configuration before the main network is put online [1]. A physical Medeco keyswitch controls that port, so one can be sure of access by the key position. From there, you can configure it to allow management from other places... or just only allow access through the management port.
Backups are simple and one on the "offline" ports -- attach a USB flash drive (for small deployments), a USB hard disk for medium sized stuff. Since it requires both physical access, a key to enable ports, and access via a UI for a dump, it isn't 100% secure, but it will definitely foil a remote intruder, assuming the OS on the online network side is solid, and nobody bridged the two adapters.
If one wanted to get exotic, it wouldn't be hard to add a CNA, FCoE, and have the device dump the data encrypted via NDMP. Replication can easily be added as well for redundancy.
The key (pun not intended) is to post a limited attack surface and prevent wholesale dumping of the password hashes to a remote intruder.
[1]: Since this is a security appliance, it has to be configured first, as there cannot be any assumptions that it can rely on DHCP.
Exactly. A keyfile stored on your devices solves the brute force password issue cold, mainly because the attackers have to deal with the complete keyspace, not just the subset that they get from dealing with what people type in.
Using TrueCrypt or KeePass with a keyfile manually copied to all devices is just being smart. Of course, if an endpoint is compromised, it would allow an attacker access, but that is a lot more difficult and expensive than just sifting through people's home directories on a cloud provider.
Easy fix... I have a hardware module which stores username/password hashes in a physically tamper-resistant container. When a web service wants to authenticate a user, it sends a request, and gets back a yes/no/locked out answer.
There are only a limited number of commands which work on the module. One is a query where the username and the password is handed to the module. If correct, it will return yes. If incorrect, no, and too many wrong guesses, it will return a value for "disallowed".
The reason for this appliance is that it is a lot tougher to grab all the user hashes if they are sitting in a hardened appliance. Everything else on the network can be compromised, but username/passwords would still have to go through the timeout/lockout feature.
It is similar to a HSM that large CAs use for their private signing keys. Even someone physically grabbing the appliance will only find that it has zeroed out the volume encryption keys, so they basically scored a blank hard disk, and little more.
Yes, one can do the same identical functionality with a dedicated database instance, but having a hardened appliance doing this will go a long way in preventing someone from grabbing your company's wad of customer password hashes.
I think it is time that we moved to two factor authentication as a whole.
What would be nice would be if there was one secure time/event based standard across the board for the authentication keyfob. OATH comes close, but there is always people/enterprises using SecurID. Perhaps something like the Google Authenticator, except with a stronger [1] hashing algorithm.
Ideally, it would be good to have multiple hardware devices, just like one keeps more than one key to a vehicle, and this can be a smartphone app, a dumbphone/featurephone app, a dedicated token like a Blizzard Authenticator, or a device that gets power when plugged into a USB slot.
One can add biometric authentication before the device offers the 6-8 digit code as well for three factor authentication (what you know, what you own, what you are.)
[1]: Perhaps multiple algorithms with the output XOR-ed together so if one algorithm is weak, it won't affect the unpredictability of the outputted numbers.
[2]: Reason one has it run from a computer is so it does not need to worry about having a battery. Even the best lithium ones eventually will fail in a couple years.
What I find nice about Android is that with devices that have an unlocked bootloader, it is very easy to change and back up ROMs, just as easy as downloading the OTA ROM from the carrier. It does take rooting and downloading an app called ROM Manager (possibly registering it as well), but once that is done and the ClockworkMod recovery installed, ROM updates and upgrades for unofficial things are very easy to do, just as easy as grabbing an official ROM from an OTA update at the least.
To boot, you can do a nandroid backup (both online or offline), so if the new ROM isn't usable... you boot into CWM, do a wipe, and restore your old one.
Of course, if I want to take my apps with me to a new ROM, there is always Titanium Backup (which actually uses a very sane and well written encryption method so backups can be stored securely on a cloud provider). After a re-ROM, I just grab TB from the store (or sideload it), and restore.
Personally, I don't care about what the carrier tosses on the phone. I've gold-carded and reflashed a ROM on a HTC phone while still in the store.
Done right, the phones can definitely last longer than the 2 year upgrade cycle. This is probably why some phone makers like Motorola lock bootloaders -- devices like the Atrix 2 are stuck on the same kernel and end up having to get tossed (if there are not enough devs), or a kexec hack put in in order to keep the phone up to date.
I've seen some teasers about Motorola offering an unlock for a developer model of the Atrix HD, but it would be nice if they would allow their paying customers full use of their device like HTC and other makers.
If the bootloader is unlocked, who needs regular carrier updates? Generally the ROM from them tends not to be optimal anyway, with a good chance of bloatware.
All Android phones I have used, I end up putting a new ROM on them anyway, either because one is faster, or just has useful features I like.
Only downside of this is when one encountered devices with locked bootloaders. It would be nice if every company went with the oem-unlock item, but at least having the chance to register and unlock a device is better than nothing.
Most people, that is... Some devices can be dragged into Jelly Bean land with a solid ROM and work without issue.
Other devices tend to be set aside at best thanks to locked bootloaders. For example, the Atrix 2 had promise, but the combination of a locked bootloader with the killing off of the laptop-esque dock made it just something to toss in a donate bin and write off taxes.
Major number means a large jump in interface, coding, modules, and the build tree in general. An example would be a word processor getting a new format, a major new feature like spell checking, or a layout change that changes functionality completely.
Minor numbers meant some features were added, but not enough to increment a major number. Continuing the word processor example, adding multi-dictionary support to the spell checker, adding PDF/A as an export format, or significant but not earth-shattering new items.
Then you had your revision number. This was almost always for bugs or UI items. As with the word processor, it would be a process where a display glitch when scrolling gets fixed, or that during the save process, the old document gets renamed, the file gets saved, then the old document gets set aside or deleted, to ensure that there is always a working copy of the data.
On the IT side of the fence, one shys away from x.0.0 or even x.x.0 versions, and waits until the x.0.1 release happens. With version inflation like in Web browsers, this goes out the window, so it is harder to find a "stable" version to include in a corporate image.
In the past, one could buy raw frames and receivers, put the parts on, and have a fully functioning firearm except sans a serial number.
These days, the frames have to be 80% finishes (the customer has to do the last part) to be legal with BATF.
What I'm waiting for is the changes in NFA/BATF policy to deal with the printed lower receivers. I doubt they would require barrels or other parts to be serialized, but who knows.
I just have a key on keyservers, and the fingerprint and ID in my.sig. It takes less space than having the whole key, especially a key with a ton of people signing it.
There are a few things I wish the gpg/PGP WoT had for tools though. One of them would be an ability to not just revoke a key, but point to the key's successor. This way, one could set a weight (say six out of 8 friends, or 2 out of 3), and if the signatures were higher than the set threshold, the key pointed to by the other people would be considered trusted. This way, if someone lost access to their key, and couldn't revoke it... they could still ask their friends to sign a "revoke/use this key" certificate which would continue to allow an unbroken chain of custody. Of course, there is the fact that the people could collude and say someone else's key is the successor, but that isn't the WoT/PKI structure's fault.
One thing I noticed is how CDs became thinner. When the Red Book CD spec came out, it stated between 1.1 and 1.5 millimeters. However, as manufacturing became cheaper and more precise, CD makers started making them as close to 1.1 millimeters as possible. It doesn't sound like a lot, but the added material half the thickness of a dime can greatly increase shelf archival life.
A very similar thing happened to me. I had a file server that had all my data on it, with hardware RAID, and with two different backup programs copying the data to external HDDs.
Cue a power failure long enough to have the UPS shut down the machine. The RAID array lost its metadata and couldn't be recovered. One of the external drives came up, and was howling... what once was data is now sitting as powder in the inside of the case. Another just failed. The last external HDD did have a backup of everything...
but the backup program had 20,000 errors upon restoring.
So, I reached for a spindle of 100 DVDs that I used for a backup... managed to get critical data back that way, data the backup program failed at.
Moral of story: Yes, DVDs get bit rot, but no media is perfect. The best thing to do is have not just a RAID array, but an array that backs up the RAID as well, so files deleted via malware or other corruption can be put back in place.
I use EAC, LAME at a decent preset, and keep the ripped WAV files. That way, I end up with decent rips, don't have to re-rip should another compression system come out, and the MP3 files are recognized by both Amazon and Apple for their cloud music services.
Slashdot Mirror
The good thing is that degrees of maintaining should emerge. There is the obvious, such as an oil pressure loss which means the vehicle moves to the side and phones a tow truck.
However, stuff on lower tiers. Lets assume headlights get multiple LED arrays in them. One array fails, so the car schedules a visit to the mechanic at night [1] so things can get fixed while the owner is asleep. Similar if a car's radio needs a firmware upgrade [2].
[1]: If the market niche appears for self-driving cars to hit a garage, you bet that there will be both car dealers and independent shops that would be open for business late at night... and they will make money, because people are far more willing to pay a premium for a car to be fixed and there in the morning than spend taxi fares and such to drop a vehicle off in the day.
[2]: With a self-driving car, no real need for the security issue for OTA firmware upgrades. Just have the vehicle head to a shop where a physical flash is done. This could even be automated so a car just stops in, gets plugged in, the new firmware upgraded and tested (or changed backed out), and the car then returns back to its owner.
I've seen HW and SW RAID leapfrog each other. Before Oracle bought Sun, there was a time where Sun pushed software RAID and Veritas Volume Manager, saying how CPU is cheap so might as well use it for drive I/O. A year or two later, they came out with hardware RAID appliances and the sales guys pushed how good having all the CPU overhead of party generation done on disk controllers was.
HW and SW raid I use on an application basis. For enterprise tasks, this tends to be moot because the data resides on FC/FCoE LUNs, and the only time I might worry about using RAID on the system side would be if I were migrating data from one SAN to another without shutting things down. Local disk tends to be more an afterthought (mainly because it tends not to have the ability to use MPIO), so it ends up being mirrored, just out of simplicity.
Of course, for desktops that are used on a day to day basis, those get hardware RAID so a drive failure means a SNMP trap firing off and a trouble ticket to desktop support versus a user screaming bloody murder.
The best is having both RAID6 and at least a hot spare. With the difference between disk capacities versus I/O so disparate, even with two drives, there is a large window (~24 hours in some cases, even on the high end SANs and lower tier drives) where the array is in a degraded state and is being rebuilt. The hot spare is important in this case because it allows the array to start being rebuilt immediately.
The ironic thing is that tier 3 drives store a lot of critical data, even though they are relatively cheap and slow. Because of this, taking reasonable measures such as RAID 6 + a hot spare or two is a must.
One thing I'd recommend is going with a RAID 1 setup for the HDDs. Drive failure is still a constant issue, and there is a big difference between seeing a dialog that pops up and going "crap, time to replace a drive", compared to hoping you have a recent backup... somewhere. Even if documents are saved on Dropbox or backed up via Mozy, it still is a PITA to reload/activate the OS, reload/activate apps, etc.
For SSDs, I have not seen any concrete proof that they are any more reliable than HDDs, so I'd have a second controller and have those mirrored or RAID-ed as well, so their I/O performance isn't linked to the I/O of the slower HDDs.
I would not mind seeing SSDs and HDDs merge, with a smart "SAN in a can" drive controller. This drive controller would do autotiering. If a region of blocks is used often, it gets moved to the SSD. If more areas get used more frequently, that set of blocks goes to the spinning platters. This way, over time (assuming consistent usage), there is a good balance between SSD speed and the capacity of traditional HDD.
I like Droidwall, have been using it since the 1.x days. Yes, it does require root, but it is worth using. Oddly enough, on rooted Motorola phones, it takes a while to push the iptables entries out when you tell it to. On HTC phones, it is a lot quicker.
Another app that I used to use was LBE Privacy Guard, but it doesn't work on Andoid 4.1 or newer (will bootloop your phone if you try.) I know it is a free app, but when it worked, it was a very useful tool, as it limited what apps could access (contacts, GPS, phone) without having to manually edit permissions in a manifest file.
My mind gets blown by sites that demand you authenticate from FB in order to use functions like posting, seeing pictures, and other stuff.
Call me crazy, but basic security 101 just says that you don't trust another site with the keys to your kingdom... especially with zero assurance that it might even work.
The thing is, we can always sacrifice freedom for security. It is a one way ratchet. Going the other way usually is only done in a complete revolution.
A more mundane use would be things like car or RV covers. Cover the rig, plug the cover into a smart battery charger, walk off.
Even more simple, just something to toss over a roof and fasten into place with double-sided tape (perhaps Velcro.) The result would be useful power, but without sacrificing repairability, other than the added weight.
I can see 486 machines (I'm guessing 4-16 MB of RAM) still being used in embedded controllers because ripping them out and replacing them with modern equipment would screw up the machinery and software timing. MS-DOS isn't pretty, but it can be used as a platform for realtime operations even though the OS isn't technically realtime.
I can't judge, as I don't know the situation. I've been in situations where I've scoffed at older machines in use, then found that because of a certain embedded task, there was no way to replace them.
However, if they are "just" being used as workstations, might as well P2V the desktops, replace the 486 machines with machines that have a RAID card and two drives (to minimize the chance of drive failure outages), and let the users boot to their VMs. One also can add another disk or two with use with wbadmin for backups, as well as automatic snapshots of the VM.
The same reason I use pick-resistant padlocks on storages: Someone getting the lock off will leave a signature.
Yes, the angle grinder will knock a boron shackle off in seconds flat, there will be some sort of proof of forced entry, either because the lock is missing, or the fact that there are obvious cuts on the wall. When placing a claim with an insurance company, it is a LOT easier to get them to play when there are obvious signs that someone forced their way in, as opposed to a picked/bumped lock which in some cases gives zero signes of entry.
Insurance companies are a lot more likely to pay when the adjuster comes by and sees chainsaw marks on a wall, as opposed to no signs of any forced entry whatsoever.
Then, there is the criminal aspect. If a thief picks a lock and enters... they may score a trespass charge, but no B&E. Forcing their way in, that is a definite felony, assuming they ever get caught.
So, I'll keep my high security locks. Yes, they are by-passable, but they give protection in another arena, the legal one.
Connections are fairly straightforward. You have your NICs (be it copper, fiber, 10gigE, 100gigE, etc.) This can vary. Then you have a dedicated Ethernet adapter for an offline configuration process. Here, you plug a laptop in, go to 192.168.0.1, and do the configuration before the main network is put online [1]. A physical Medeco keyswitch controls that port, so one can be sure of access by the key position. From there, you can configure it to allow management from other places... or just only allow access through the management port.
Backups are simple and one on the "offline" ports -- attach a USB flash drive (for small deployments), a USB hard disk for medium sized stuff. Since it requires both physical access, a key to enable ports, and access via a UI for a dump, it isn't 100% secure, but it will definitely foil a remote intruder, assuming the OS on the online network side is solid, and nobody bridged the two adapters.
If one wanted to get exotic, it wouldn't be hard to add a CNA, FCoE, and have the device dump the data encrypted via NDMP. Replication can easily be added as well for redundancy.
The key (pun not intended) is to post a limited attack surface and prevent wholesale dumping of the password hashes to a remote intruder.
[1]: Since this is a security appliance, it has to be configured first, as there cannot be any assumptions that it can rely on DHCP.
Exactly. A keyfile stored on your devices solves the brute force password issue cold, mainly because the attackers have to deal with the complete keyspace, not just the subset that they get from dealing with what people type in.
Using TrueCrypt or KeePass with a keyfile manually copied to all devices is just being smart. Of course, if an endpoint is compromised, it would allow an attacker access, but that is a lot more difficult and expensive than just sifting through people's home directories on a cloud provider.
Easy fix... I have a hardware module which stores username/password hashes in a physically tamper-resistant container. When a web service wants to authenticate a user, it sends a request, and gets back a yes/no/locked out answer.
There are only a limited number of commands which work on the module. One is a query where the username and the password is handed to the module. If correct, it will return yes. If incorrect, no, and too many wrong guesses, it will return a value for "disallowed".
The reason for this appliance is that it is a lot tougher to grab all the user hashes if they are sitting in a hardened appliance. Everything else on the network can be compromised, but username/passwords would still have to go through the timeout/lockout feature.
It is similar to a HSM that large CAs use for their private signing keys. Even someone physically grabbing the appliance will only find that it has zeroed out the volume encryption keys, so they basically scored a blank hard disk, and little more.
Yes, one can do the same identical functionality with a dedicated database instance, but having a hardened appliance doing this will go a long way in preventing someone from grabbing your company's wad of customer password hashes.
I think it is time that we moved to two factor authentication as a whole.
What would be nice would be if there was one secure time/event based standard across the board for the authentication keyfob. OATH comes close, but there is always people/enterprises using SecurID. Perhaps something like the Google Authenticator, except with a stronger [1] hashing algorithm.
Ideally, it would be good to have multiple hardware devices, just like one keeps more than one key to a vehicle, and this can be a smartphone app, a dumbphone/featurephone app, a dedicated token like a Blizzard Authenticator, or a device that gets power when plugged into a USB slot.
One can add biometric authentication before the device offers the 6-8 digit code as well for three factor authentication (what you know, what you own, what you are.)
[1]: Perhaps multiple algorithms with the output XOR-ed together so if one algorithm is weak, it won't affect the unpredictability of the outputted numbers.
[2]: Reason one has it run from a computer is so it does not need to worry about having a battery. Even the best lithium ones eventually will fail in a couple years.
What I find nice about Android is that with devices that have an unlocked bootloader, it is very easy to change and back up ROMs, just as easy as downloading the OTA ROM from the carrier. It does take rooting and downloading an app called ROM Manager (possibly registering it as well), but once that is done and the ClockworkMod recovery installed, ROM updates and upgrades for unofficial things are very easy to do, just as easy as grabbing an official ROM from an OTA update at the least.
To boot, you can do a nandroid backup (both online or offline), so if the new ROM isn't usable... you boot into CWM, do a wipe, and restore your old one.
Of course, if I want to take my apps with me to a new ROM, there is always Titanium Backup (which actually uses a very sane and well written encryption method so backups can be stored securely on a cloud provider). After a re-ROM, I just grab TB from the store (or sideload it), and restore.
Personally, I don't care about what the carrier tosses on the phone. I've gold-carded and reflashed a ROM on a HTC phone while still in the store.
Done right, the phones can definitely last longer than the 2 year upgrade cycle. This is probably why some phone makers like Motorola lock bootloaders -- devices like the Atrix 2 are stuck on the same kernel and end up having to get tossed (if there are not enough devs), or a kexec hack put in in order to keep the phone up to date.
I've seen some teasers about Motorola offering an unlock for a developer model of the Atrix HD, but it would be nice if they would allow their paying customers full use of their device like HTC and other makers.
If the bootloader is unlocked, who needs regular carrier updates? Generally the ROM from them tends not to be optimal anyway, with a good chance of bloatware.
All Android phones I have used, I end up putting a new ROM on them anyway, either because one is faster, or just has useful features I like.
Only downside of this is when one encountered devices with locked bootloaders. It would be nice if every company went with the oem-unlock item, but at least having the chance to register and unlock a device is better than nothing.
Most people, that is... Some devices can be dragged into Jelly Bean land with a solid ROM and work without issue.
Other devices tend to be set aside at best thanks to locked bootloaders. For example, the Atrix 2 had promise, but the combination of a locked bootloader with the killing off of the laptop-esque dock made it just something to toss in a donate bin and write off taxes.
I'm old school in that regard too:
Major number means a large jump in interface, coding, modules, and the build tree in general. An example would be a word processor getting a new format, a major new feature like spell checking, or a layout change that changes functionality completely.
Minor numbers meant some features were added, but not enough to increment a major number. Continuing the word processor example, adding multi-dictionary support to the spell checker, adding PDF/A as an export format, or significant but not earth-shattering new items.
Then you had your revision number. This was almost always for bugs or UI items. As with the word processor, it would be a process where a display glitch when scrolling gets fixed, or that during the save process, the old document gets renamed, the file gets saved, then the old document gets set aside or deleted, to ensure that there is always a working copy of the data.
On the IT side of the fence, one shys away from x.0.0 or even x.x.0 versions, and waits until the x.0.1 release happens. With version inflation like in Web browsers, this goes out the window, so it is harder to find a "stable" version to include in a corporate image.
In the past, one could buy raw frames and receivers, put the parts on, and have a fully functioning firearm except sans a serial number.
These days, the frames have to be 80% finishes (the customer has to do the last part) to be legal with BATF.
What I'm waiting for is the changes in NFA/BATF policy to deal with the printed lower receivers. I doubt they would require barrels or other parts to be serialized, but who knows.
I just have a key on keyservers, and the fingerprint and ID in my .sig. It takes less space than having the whole key, especially a key with a ton of people signing it.
There are a few things I wish the gpg/PGP WoT had for tools though. One of them would be an ability to not just revoke a key, but point to the key's successor. This way, one could set a weight (say six out of 8 friends, or 2 out of 3), and if the signatures were higher than the set threshold, the key pointed to by the other people would be considered trusted. This way, if someone lost access to their key, and couldn't revoke it... they could still ask their friends to sign a "revoke/use this key" certificate which would continue to allow an unbroken chain of custody. Of course, there is the fact that the people could collude and say someone else's key is the successor, but that isn't the WoT/PKI structure's fault.
One thing I noticed is how CDs became thinner. When the Red Book CD spec came out, it stated between 1.1 and 1.5 millimeters. However, as manufacturing became cheaper and more precise, CD makers started making them as close to 1.1 millimeters as possible. It doesn't sound like a lot, but the added material half the thickness of a dime can greatly increase shelf archival life.
A very similar thing happened to me. I had a file server that had all my data on it, with hardware RAID, and with two different backup programs copying the data to external HDDs.
Cue a power failure long enough to have the UPS shut down the machine. The RAID array lost its metadata and couldn't be recovered. One of the external drives came up, and was howling... what once was data is now sitting as powder in the inside of the case. Another just failed. The last external HDD did have a backup of everything...
but the backup program had 20,000 errors upon restoring.
So, I reached for a spindle of 100 DVDs that I used for a backup... managed to get critical data back that way, data the backup program failed at.
Moral of story: Yes, DVDs get bit rot, but no media is perfect. The best thing to do is have not just a RAID array, but an array that backs up the RAID as well, so files deleted via malware or other corruption can be put back in place.
I use EAC, LAME at a decent preset, and keep the ripped WAV files. That way, I end up with decent rips, don't have to re-rip should another compression system come out, and the MP3 files are recognized by both Amazon and Apple for their cloud music services.