The pyramid boom and bust are over. Maybe Bitcoin is valued at what it should be as of now, since various interests have actual value in the currency.
However, I still consider BitCoin a currency for trading, although I'd exchange as quickly as I can. As a currency for storing value, that will take years. The US Dollar took 50 years and was running alongside the Mexican peso before it became a value standard.
I had a HTC Wizard, with its dual-core TI OMAP puttering along at 200 MHz. Doesn't sound like much, but it did well with calls, and could run a week without having to be charged. This was about a decade ago. Now, most of my smartphones won't persist beyond 24 hours unless I have them plugged into an external battery, or like my HTC One M8, enable the extreme battery saving mode, which replaces the Android Launcher default, disables Wi-Fi, and cellular communication, and only runs the absolute minimum of processes. This probably would make the phone's battery last a week, maybe more.
I sort of wish the philosophy behind apps wasn't "lets make these as fast as a gaming computer or console", but the old PalmOS philosophy of "do the job done right, and if it doesn't need CPU cycles, don't do it." Because of demand for ever faster CPUs and GPUs, phones have to get bigger and bigger for heat dissipation reasons. It would be nice for CPU speed to lag a bit to allow for a better battery life, perhaps adding deeper caches. Adding more RAM to a phone might help things as well. This way, phone shape can be dictated by what users want, not having to have ever larger surfaces for engineering reasons.
If you use JuiceDefender, you can prolong the life of almost any Android phone, just because you can schedule it to turn off all communications other than for a certain gap. This does help with some phones that have a short battery life.
Problem with lithium based batteries, in general, are two things:
1: Puncture them, they go boom unless engineering is done to prevent this.
2: If they are not discharged and charged correctly, they go boom.
One place where lithium batteries are starting to make an impact (namely LiFePO4 batteries) is RV-ing. However, Silverleaf controllers tend to be expensive, so if you want this and you like off-grid camping, expect to pay upwards of $120,000 just to play in this ballgame. More useful setups (800-1200 ampere-hours) are available (Advanced RV comes to mind as well as Roadtrek), but expect to pay dearly for those.
What really is needed is a charge/discharge controller that can take a bank of lithium cells and make it appear to existing chargers and electrical loads like the battery is a flooded lead-acid or AGM battery. This would allow retrofitting without having to do major re-engineering of the rest of the electrical system. However, in reality, it will take a re-engineering of charging and discharging eventually because of lithium's different charging/discharging curves.
The Bolt looks like a car that is made to compete against the Mitsubishi i-MiEV. This is a great commute vehicle for an urban setting where you spend most of your time sitting at 0 RPM at lights or in traffic. But for something that might attract Tesla owners? That is like asking Corvette owners to buy a Sentra SE-R, or a Type R Civic.
Here is my dumb question: What is wrong with the Chevy Volt that the Bolt even needs to exist in the first place?
The current Volt is a completely electric car. Plug it in at night, and all that. However, having the gasoline engine means no range anxiety, so while the Leaf and the Tesla owner are back at home switching cars, the Volt is on the highway for a long trip. This is definitely a decent compromise between having an EV for commutes, and a second IC based vehicle for long trips.
If we pull numbers off a high precision clock function like Linux's clock_gettime (which has a nanosecond precision rate), it matters less what exact key the user pressed, because the part that rapidly changes (interval between keys, or even the absolute time (year/month/day/hour/minute/second/billionths of a second) can be used by running the output through a hashing algorithm and tossed into the RNG pool.
One you get into microsecond and nanosecond resolution, that is a quite usable random number source, since someone might be able to tap a key (even repeatedly) on a tenth to hundredth of a second scale, but definitely not be able to give repetitive keystrokes on a nanosecond level.
What key they press might give around six bits of random data, but you can get significantly more bits (20-30) per keystroke just from the high precision timer.
What I liked was the original version of PGP when it would ask you to type some random numbers/letters and would use that as a seed.
It depends on the crypto I was doing: For a number of tasks, say if I were rolling dice for a game,/dev/urandom is good enough. For generating a nonpersistant key (like a session key that is used and tossed during a SSL transaction),/dev/random. For a key that is persistant, it might be even better to use/dev/random, but also ask the user to toss in some random keypresses/mouse movement [1], similar to how TrueCrypt and KeePass request it. This way, if there is something defective with the RNG, it is mitigated by a chunk of random bits from the user.
[1]: Take the time down to as precise as possible, plus the keystroke result itself, hash it (using the hash function as a "bit blender"), toss that in. For mouse movements, take measurements every random fraction of a second, hash those, toss those in as well.
Bingo. Blowback is already happening. Yes, TESCO, WM, and other places have stopped selling the CSA items... but small businesses are being flooded with business. Flagmakers are absolutely slammed with requests.
That is the one thing about the US... it seems for something to get popular, it needs to be initially banned.
During the early days of Linux, UMSDOSfs was a quite useful tool, being able to superimpose UNIX file names and ACLs on top of a vanilla FAT filesystem.
With devices that might need to restrict access, but still require FAT32 because of interoperability concerns, would a variant of UMSDOS that works on this filesystem ever be feasible? Take Android for instance. The only way to keep app "A" and app "B" separated when they are granted access to an external SD card is by using SELinux rules (which the default pretty much denies access.) Having the ability to enforce permissions while still preserving interoperability of SD cards would be very useful.
I'm guessing it can be fitted with a remote control or guiding device to function autonomously, as well as with someone atop of it.
Is it me, or is this a variant of the hovercraft? Normal hovercraft are useful in swampy terrain, but something this small requires a lot of engine usage to keep the cushion of air underneath, and unlike most hovercraft which use curtains to keep the air from escaping as fast, this doesn't have this, so it needs to push significantly more air to keep it afloat.
Ada has a very good reputation for security. I know of a few websites that use Ada for the backend. Not as easy as the web language of the month... but tend to be decently bug resistant, and from what I've seen, haven't had any real security issues.
I do wish for a resurgence in Ada's use. Security depends on the programmer mainly (regardless of language), but there are better tools to do it right in Ada than most other languages. This doesn't mean it is a one size fits all language... but for code that is critical to security, it might be wise to use a language designed with security from the ground up. Spark Ada has provable security, for example (as per "SPARK - A Safety Related Ada Subset")
If really worried, do your work in a VM and have something like AutoProtect in VMWare Workstation save a snapshot every few hours. If you go home, find the VM rebooted, it isn't tough to go back to a point in time before the reboot, save one's work then reboot.
If the host machine reboots, it will just suspend the VM before the reboot, so unless one is running an item in real time, the RPO is 0 and RTO is just getting the VM turned back on.
Another option is using WSUS. I have it configured to auto-approve all patches, but if one wants to take the risk at delaying being patched, no machines will reboot until you tell it to.
Finally, you can always set Windows Update to notify you about updates, so you don't get any reboots until you push the button.
No, it isn't fun rebooting, especially when one has been in IT long enough to be proud of system uptimes, but better a low uptime than hacked box, so patches are a necessary evil.
Clevo comes to mind. They are a Taiwan based company, and have produced some very good hardware in the past.
They have a wide range of products to choose from. If you want a Xeon based laptop with three hard disks in a RAID 0/1/5 configuration, they have a model for that, although the battery with something like that is more of a UPS function (lasts ~30 minutes) than something you would use without having it plugged in. If you want an ultralight model, they also have those, and a lot in between.
Look at the Vista fiasco. OEMs had to be dragged, kicking and screaming, to the privilege model (which has been in the UNIX world for decades, and was in the Mac world for at least five years) where they don't have all their stuff run with admin rights. Then, when MS added some fundamental security features like ASLR, forcing drivers to be rewritten, OEMs shipped alpha-quality code, then blamed the crashes on MS.
Windows 2003 had a 64 bit version, but Windows 2003 mainly was 32 bit. If you used the/PAE option on the 32 bit edition, you could get past the 4GB barrier on that OS... but the caceat was only if you had the enterprise or data center editions (which got you to 32 GB or 64 GB respectively.)
So, I do agree with the parent... the ability to get past 4GB did exist, but required a bunch of flaming hoops to go through.
As for monitors, I've seen lots of screwy, nonsensical stuff, stuff (such as a glitch on a SCSI card causing the monitor to tint green), so I wouldn't be surprised if this was the case.
I had a laptop like that. It had drivers which were only in the OEM image, and the only way I still had the image was because I used ghost and copied the hard disk stuff somewhere safe.
I eventually was able to find the real OEM for the USB 2 drivers after looking by PCI ID, but the video card maker refused to give drivers, saying only the OEM had say in that, so I wound up using a third party's drivers that actually could make the video work. Of course, after the laptop's fan bearings went south and sounded like a jet plane taking off, I just yanked the hard drive for an external device and placed the carcass in a drawer, if I ever might have to use it again.
With Windows post-Vista, drivers should never be an issue. By default, the driver OEM needs to register their software with Windows Update, so on initial install, the machine can go out, fetch the drivers and autoinstall them.
In any case, it is still wise (assuming this is not an enterprise with a large amount of machines) to either pull the HDD (again, if possible), image it off somewhere safe, or boot the machine to Ghost or CloneZilla and save the HDD image. This way, if there is a driver present, it can be found, and the machine can always be returned to its factory state should the need arise.
Scenario 1: Archiving. This is where one sticks files into some archiving program (ZIP, RAR, etc.) and then uploads the archive to some place like Amazon Glacier where it pretty much remains indefinitely until needed. This takes some thought, since even though uploading and keeping stuff on Glacier is inexpensive... retrieving it isn't cheap. One should figure out a size of archive that isn't hard to download, but not too small that documents and other items require multiple downloaded files to retrieve. This can be done to mobile devices, but again, it is a balance of useful file size versus time downloading.
Scenario 2: Random access block-based file. Using TrueCrypt on a DropBox synced partition for example. The changes are propagated. Of course, the download with this is cross-platform compatibility.
Scenario 3: Subdirectory of files encrypted with something like CFS, EncFS, or another tool. This may work for OS X, Linux, and Android, but won't on iOS and Windows.
At the minimum, the guy should have at least an external hard disk and Mozy, Carbonite, BackBlaze, or another provider. The external HDD is for the backup program to allow for a bare metal restore of the box, and saving it on a remote provider helps with retrieving the files if the computer and its backup drive become inaccessible (destroyed/stolen/etc.)
SSDs just make it worse, since when they fail, they are usually impossible to recover.
I do three layers of backups:
Layer 1 is an external HDD. That covers "oh shit" failures where I can completely rebuild and bare-metal a machine quickly, as well as restore files.
Layer 2 is a server that "pulls" backups. It runs Windows Server 2012R2 and Server Essentials, (if I get past ~10 machines, that means time to go for a "big boy" backup platform like DPM or NetBackup.) What this provides is resistance against ransomware, because the client machines cannot access the server, as the server does the data pulling. The only downside is that a bare metal is easily doable... but it isn't as fast as recovering from a directly attached drive.
Layer 3 is an encryption layer and the cloud for documents. With DropBox and encrypted disk images, one basically can use a cloud storage provider a very limited bandwidth SAN. Definitely not fast, and not the best way to recover... but your documents are stored securely.
Layer 4 is an archive of documents done every 6-12 months, broken up into manageable pieces with an index file, burned to local optical media, and tossed onto Amazon Glacier.
MS would make money hand over fist by doing that. Look at OS/2. There is a company, EComStation still cranking out support and updates for Warp.
The problem is that XPe and other embedded versions can't be upgraded. Try that, and millions of dollars worth of equipment will be rendered into scrap. One can treat XPe like a broken SCADA system and firewall/airgap the living hell out of it, but the best of all worlds is to have MS continue supporting it (for a decent fee) which is a win/win for all parties involved.
This problem isn't going away anytime soon even with future releases. Embedded versions of newer operating systems exist, and when Windows 7 loses support, the same thing will happen.
Ideally, MS should see about a RLTS (really long term support) embedded platform that is intended to be supported for at least 20-50 years. In the past, this couldn't really be done, but now that technology has matured to the point where 20 years from now, we will still have RAM, storage, CPU, and other items, supporting something on a long time scale is possible.
Student loans are the absolute worst debt one can get because they don't go away. Tell any other type of creditor other than a government entity to shove it, and they have a statute of limitations (4 years in Texas) until they have to write off the debt [1].
Say the economy hits the shitter, which it will, one winds up filing personal bankruptcy, has to use a bicycle, and has to find some cheap rent arrangement. After 7-10 years, one can continue with life. Student loan debts are permanent. When they shit on your credit score, that stays forever.
So, in a nutshell, the OP has a good heart for finding a charity, but he or she needs to first get rid of student loan debt for a better financial position to actually do more good.
Now, assuming there are no student loans, I'd probably go for local charities. The local food bank comes to mind. One never knows... they may be donating to it one day, having to get food the next.
[1]: One side note, when they do write it off, the IRS considers that as "income"...
MEAN may have its place, but those duplicate fields implies not just additional disk space, but more data that has to be backed up, more data that can be hacked, more data that can get corrupted (what happens if two identical fields wind up with different values... what FirstName gets precedence), more data the backend RDBMS has to chug through.
For smallish tasks, this isn't a big deal, since a small Linode VM or whatnot can do the tasks. However, this can impose a performance and space penalty that can be costly later on.
I don't want a console, regardless of maker. They symbolize a fundamental pacts broken:
During the "don't copy that floppy" era, there were promises made repeatedly that if piracy went away, prices on software would decrease sharply. When the latest and greatest DRM system hit, it was mentioned that if piracy went away, the money spent on that would be shaved off the prices of games and other items.
Well, fast forward to today. Consoles have a 0% piracy rate on the latest gen, and previous gen consoles get perma-banned if the network detects they were modded. Have game prices on consoles gone down as repeatedly pledged to us? No. In fact, to play a game (or actually get a "game"'s worth of content), it requires hundreds of dollars of DLC.
So, consoles are an embodiment of a lie promised to the consumer repeatedly, but for the price of a PC game, one gets the luxury of paying a lot more for an immutable, unmodable game, which can't even be sold at a used game store.
Insurance companies shoulder risk as well. One could be a perfect driver, but all it takes is one bad driver backing up at a light (a rear ender is 100% the person behind's fault, even if they back up in most states), and you now are responsible for their neck injuries and vehicle damage. In most cases, the aftermath means just letting the insco handle the paperwork, getting the car fixed up, and maybe sitting in a driver's ed class.
Without insurance... it might be a financial disaster. Perhaps a bankruptcy.
Slashdot Mirror
The pyramid boom and bust are over. Maybe Bitcoin is valued at what it should be as of now, since various interests have actual value in the currency.
However, I still consider BitCoin a currency for trading, although I'd exchange as quickly as I can. As a currency for storing value, that will take years. The US Dollar took 50 years and was running alongside the Mexican peso before it became a value standard.
I had a HTC Wizard, with its dual-core TI OMAP puttering along at 200 MHz. Doesn't sound like much, but it did well with calls, and could run a week without having to be charged. This was about a decade ago. Now, most of my smartphones won't persist beyond 24 hours unless I have them plugged into an external battery, or like my HTC One M8, enable the extreme battery saving mode, which replaces the Android Launcher default, disables Wi-Fi, and cellular communication, and only runs the absolute minimum of processes. This probably would make the phone's battery last a week, maybe more.
I sort of wish the philosophy behind apps wasn't "lets make these as fast as a gaming computer or console", but the old PalmOS philosophy of "do the job done right, and if it doesn't need CPU cycles, don't do it." Because of demand for ever faster CPUs and GPUs, phones have to get bigger and bigger for heat dissipation reasons. It would be nice for CPU speed to lag a bit to allow for a better battery life, perhaps adding deeper caches. Adding more RAM to a phone might help things as well. This way, phone shape can be dictated by what users want, not having to have ever larger surfaces for engineering reasons.
If you use JuiceDefender, you can prolong the life of almost any Android phone, just because you can schedule it to turn off all communications other than for a certain gap. This does help with some phones that have a short battery life.
Problem with lithium based batteries, in general, are two things:
1: Puncture them, they go boom unless engineering is done to prevent this.
2: If they are not discharged and charged correctly, they go boom.
One place where lithium batteries are starting to make an impact (namely LiFePO4 batteries) is RV-ing. However, Silverleaf controllers tend to be expensive, so if you want this and you like off-grid camping, expect to pay upwards of $120,000 just to play in this ballgame. More useful setups (800-1200 ampere-hours) are available (Advanced RV comes to mind as well as Roadtrek), but expect to pay dearly for those.
What really is needed is a charge/discharge controller that can take a bank of lithium cells and make it appear to existing chargers and electrical loads like the battery is a flooded lead-acid or AGM battery. This would allow retrofitting without having to do major re-engineering of the rest of the electrical system. However, in reality, it will take a re-engineering of charging and discharging eventually because of lithium's different charging/discharging curves.
The Bolt looks like a car that is made to compete against the Mitsubishi i-MiEV. This is a great commute vehicle for an urban setting where you spend most of your time sitting at 0 RPM at lights or in traffic. But for something that might attract Tesla owners? That is like asking Corvette owners to buy a Sentra SE-R, or a Type R Civic.
Here is my dumb question: What is wrong with the Chevy Volt that the Bolt even needs to exist in the first place?
The current Volt is a completely electric car. Plug it in at night, and all that. However, having the gasoline engine means no range anxiety, so while the Leaf and the Tesla owner are back at home switching cars, the Volt is on the highway for a long trip. This is definitely a decent compromise between having an EV for commutes, and a second IC based vehicle for long trips.
If we pull numbers off a high precision clock function like Linux's clock_gettime (which has a nanosecond precision rate), it matters less what exact key the user pressed, because the part that rapidly changes (interval between keys, or even the absolute time (year/month/day/hour/minute/second/billionths of a second) can be used by running the output through a hashing algorithm and tossed into the RNG pool.
One you get into microsecond and nanosecond resolution, that is a quite usable random number source, since someone might be able to tap a key (even repeatedly) on a tenth to hundredth of a second scale, but definitely not be able to give repetitive keystrokes on a nanosecond level.
What key they press might give around six bits of random data, but you can get significantly more bits (20-30) per keystroke just from the high precision timer.
What I liked was the original version of PGP when it would ask you to type some random numbers/letters and would use that as a seed.
It depends on the crypto I was doing: For a number of tasks, say if I were rolling dice for a game, /dev/urandom is good enough. For generating a nonpersistant key (like a session key that is used and tossed during a SSL transaction), /dev/random. For a key that is persistant, it might be even better to use /dev/random, but also ask the user to toss in some random keypresses/mouse movement [1], similar to how TrueCrypt and KeePass request it. This way, if there is something defective with the RNG, it is mitigated by a chunk of random bits from the user.
[1]: Take the time down to as precise as possible, plus the keystroke result itself, hash it (using the hash function as a "bit blender"), toss that in. For mouse movements, take measurements every random fraction of a second, hash those, toss those in as well.
Bingo. Blowback is already happening. Yes, TESCO, WM, and other places have stopped selling the CSA items... but small businesses are being flooded with business. Flagmakers are absolutely slammed with requests.
That is the one thing about the US... it seems for something to get popular, it needs to be initially banned.
During the early days of Linux, UMSDOSfs was a quite useful tool, being able to superimpose UNIX file names and ACLs on top of a vanilla FAT filesystem.
With devices that might need to restrict access, but still require FAT32 because of interoperability concerns, would a variant of UMSDOS that works on this filesystem ever be feasible? Take Android for instance. The only way to keep app "A" and app "B" separated when they are granted access to an external SD card is by using SELinux rules (which the default pretty much denies access.) Having the ability to enforce permissions while still preserving interoperability of SD cards would be very useful.
I'm guessing it can be fitted with a remote control or guiding device to function autonomously, as well as with someone atop of it.
Is it me, or is this a variant of the hovercraft? Normal hovercraft are useful in swampy terrain, but something this small requires a lot of engine usage to keep the cushion of air underneath, and unlike most hovercraft which use curtains to keep the air from escaping as fast, this doesn't have this, so it needs to push significantly more air to keep it afloat.
Ada has a very good reputation for security. I know of a few websites that use Ada for the backend. Not as easy as the web language of the month... but tend to be decently bug resistant, and from what I've seen, haven't had any real security issues.
I do wish for a resurgence in Ada's use. Security depends on the programmer mainly (regardless of language), but there are better tools to do it right in Ada than most other languages. This doesn't mean it is a one size fits all language... but for code that is critical to security, it might be wise to use a language designed with security from the ground up. Spark Ada has provable security, for example (as per "SPARK - A Safety Related Ada Subset")
If really worried, do your work in a VM and have something like AutoProtect in VMWare Workstation save a snapshot every few hours. If you go home, find the VM rebooted, it isn't tough to go back to a point in time before the reboot, save one's work then reboot.
If the host machine reboots, it will just suspend the VM before the reboot, so unless one is running an item in real time, the RPO is 0 and RTO is just getting the VM turned back on.
Another option is using WSUS. I have it configured to auto-approve all patches, but if one wants to take the risk at delaying being patched, no machines will reboot until you tell it to.
Finally, you can always set Windows Update to notify you about updates, so you don't get any reboots until you push the button.
No, it isn't fun rebooting, especially when one has been in IT long enough to be proud of system uptimes, but better a low uptime than hacked box, so patches are a necessary evil.
Clevo comes to mind. They are a Taiwan based company, and have produced some very good hardware in the past.
They have a wide range of products to choose from. If you want a Xeon based laptop with three hard disks in a RAID 0/1/5 configuration, they have a model for that, although the battery with something like that is more of a UPS function (lasts ~30 minutes) than something you would use without having it plugged in. If you want an ultralight model, they also have those, and a lot in between.
Look at the Vista fiasco. OEMs had to be dragged, kicking and screaming, to the privilege model (which has been in the UNIX world for decades, and was in the Mac world for at least five years) where they don't have all their stuff run with admin rights. Then, when MS added some fundamental security features like ASLR, forcing drivers to be rewritten, OEMs shipped alpha-quality code, then blamed the crashes on MS.
Windows 2003 had a 64 bit version, but Windows 2003 mainly was 32 bit. If you used the /PAE option on the 32 bit edition, you could get past the 4GB barrier on that OS... but the caceat was only if you had the enterprise or data center editions (which got you to 32 GB or 64 GB respectively.)
So, I do agree with the parent... the ability to get past 4GB did exist, but required a bunch of flaming hoops to go through.
As for monitors, I've seen lots of screwy, nonsensical stuff, stuff (such as a glitch on a SCSI card causing the monitor to tint green), so I wouldn't be surprised if this was the case.
I had a laptop like that. It had drivers which were only in the OEM image, and the only way I still had the image was because I used ghost and copied the hard disk stuff somewhere safe.
I eventually was able to find the real OEM for the USB 2 drivers after looking by PCI ID, but the video card maker refused to give drivers, saying only the OEM had say in that, so I wound up using a third party's drivers that actually could make the video work. Of course, after the laptop's fan bearings went south and sounded like a jet plane taking off, I just yanked the hard drive for an external device and placed the carcass in a drawer, if I ever might have to use it again.
With Windows post-Vista, drivers should never be an issue. By default, the driver OEM needs to register their software with Windows Update, so on initial install, the machine can go out, fetch the drivers and autoinstall them.
In any case, it is still wise (assuming this is not an enterprise with a large amount of machines) to either pull the HDD (again, if possible), image it off somewhere safe, or boot the machine to Ghost or CloneZilla and save the HDD image. This way, if there is a driver present, it can be found, and the machine can always be returned to its factory state should the need arise.
I find there are multiple ways to skin this cat:
Scenario 1: Archiving. This is where one sticks files into some archiving program (ZIP, RAR, etc.) and then uploads the archive to some place like Amazon Glacier where it pretty much remains indefinitely until needed. This takes some thought, since even though uploading and keeping stuff on Glacier is inexpensive... retrieving it isn't cheap. One should figure out a size of archive that isn't hard to download, but not too small that documents and other items require multiple downloaded files to retrieve. This can be done to mobile devices, but again, it is a balance of useful file size versus time downloading.
Scenario 2: Random access block-based file. Using TrueCrypt on a DropBox synced partition for example. The changes are propagated. Of course, the download with this is cross-platform compatibility.
Scenario 3: Subdirectory of files encrypted with something like CFS, EncFS, or another tool. This may work for OS X, Linux, and Android, but won't on iOS and Windows.
WHS is still around, it is called W2012 R2 Essentials, and comes with the OS as a feature/role to toss on.
It still is WHS pretty much (other than the name change and being part of the OS)... and stashes backups as .dat files.
At the minimum, the guy should have at least an external hard disk and Mozy, Carbonite, BackBlaze, or another provider. The external HDD is for the backup program to allow for a bare metal restore of the box, and saving it on a remote provider helps with retrieving the files if the computer and its backup drive become inaccessible (destroyed/stolen/etc.)
SSDs just make it worse, since when they fail, they are usually impossible to recover.
I do three layers of backups:
Layer 1 is an external HDD. That covers "oh shit" failures where I can completely rebuild and bare-metal a machine quickly, as well as restore files.
Layer 2 is a server that "pulls" backups. It runs Windows Server 2012R2 and Server Essentials, (if I get past ~10 machines, that means time to go for a "big boy" backup platform like DPM or NetBackup.) What this provides is resistance against ransomware, because the client machines cannot access the server, as the server does the data pulling. The only downside is that a bare metal is easily doable... but it isn't as fast as recovering from a directly attached drive.
Layer 3 is an encryption layer and the cloud for documents. With DropBox and encrypted disk images, one basically can use a cloud storage provider a very limited bandwidth SAN. Definitely not fast, and not the best way to recover... but your documents are stored securely.
Layer 4 is an archive of documents done every 6-12 months, broken up into manageable pieces with an index file, burned to local optical media, and tossed onto Amazon Glacier.
MS would make money hand over fist by doing that. Look at OS/2. There is a company, EComStation still cranking out support and updates for Warp.
The problem is that XPe and other embedded versions can't be upgraded. Try that, and millions of dollars worth of equipment will be rendered into scrap. One can treat XPe like a broken SCADA system and firewall/airgap the living hell out of it, but the best of all worlds is to have MS continue supporting it (for a decent fee) which is a win/win for all parties involved.
This problem isn't going away anytime soon even with future releases. Embedded versions of newer operating systems exist, and when Windows 7 loses support, the same thing will happen.
Ideally, MS should see about a RLTS (really long term support) embedded platform that is intended to be supported for at least 20-50 years. In the past, this couldn't really be done, but now that technology has matured to the point where 20 years from now, we will still have RAM, storage, CPU, and other items, supporting something on a long time scale is possible.
You hit the nail on the head:
Student loans are the absolute worst debt one can get because they don't go away. Tell any other type of creditor other than a government entity to shove it, and they have a statute of limitations (4 years in Texas) until they have to write off the debt [1].
Say the economy hits the shitter, which it will, one winds up filing personal bankruptcy, has to use a bicycle, and has to find some cheap rent arrangement. After 7-10 years, one can continue with life. Student loan debts are permanent. When they shit on your credit score, that stays forever.
So, in a nutshell, the OP has a good heart for finding a charity, but he or she needs to first get rid of student loan debt for a better financial position to actually do more good.
Now, assuming there are no student loans, I'd probably go for local charities. The local food bank comes to mind. One never knows... they may be donating to it one day, having to get food the next.
[1]: One side note, when they do write it off, the IRS considers that as "income"...
MEAN may have its place, but those duplicate fields implies not just additional disk space, but more data that has to be backed up, more data that can be hacked, more data that can get corrupted (what happens if two identical fields wind up with different values... what FirstName gets precedence), more data the backend RDBMS has to chug through.
For smallish tasks, this isn't a big deal, since a small Linode VM or whatnot can do the tasks. However, this can impose a performance and space penalty that can be costly later on.
I don't want a console, regardless of maker. They symbolize a fundamental pacts broken:
During the "don't copy that floppy" era, there were promises made repeatedly that if piracy went away, prices on software would decrease sharply. When the latest and greatest DRM system hit, it was mentioned that if piracy went away, the money spent on that would be shaved off the prices of games and other items.
Well, fast forward to today. Consoles have a 0% piracy rate on the latest gen, and previous gen consoles get perma-banned if the network detects they were modded. Have game prices on consoles gone down as repeatedly pledged to us? No. In fact, to play a game (or actually get a "game"'s worth of content), it requires hundreds of dollars of DLC.
So, consoles are an embodiment of a lie promised to the consumer repeatedly, but for the price of a PC game, one gets the luxury of paying a lot more for an immutable, unmodable game, which can't even be sold at a used game store.
Insurance companies shoulder risk as well. One could be a perfect driver, but all it takes is one bad driver backing up at a light (a rear ender is 100% the person behind's fault, even if they back up in most states), and you now are responsible for their neck injuries and vehicle damage. In most cases, the aftermath means just letting the insco handle the paperwork, getting the car fixed up, and maybe sitting in a driver's ed class.
Without insurance... it might be a financial disaster. Perhaps a bankruptcy.