I have some bills which will get "lost" if they are not sent at least certified mail. Sent electronically, it isn't anywhere near as concrete proof [1] as a piece of physical mail sent with a signature trail.
Paper complaints, especially legal work are hard to ignore. E-mail, even calls, there is no paper trail and can be hidden. However, a certified message either gets received or it gets refused. Either way, someone had to interact with the document in a provable way. Even now, our society isn't paperless and when it comes to legalities, there is no beating physical paper documents.
As for banking software on my phone, I'd say that iOS and Android have a better record for security with a few caveats [2], than a desktop machine. However, my biggest concern with too much stuff on a phone is if it gets stolen. Of course, the ideal would be having the banking software use KeyChain or Google's equivalent and ask for a PIN before it is run, so all sensitive data is encrypted, not just by the phone's encryption, but by a specific API.
[1]: Proof to judges and juries who are still in the pen and paper age, and those are the people who need to be persuaded if worse comes to worst. You can talk crypto all day long to a jury, and their eyes will glaze over. Show them a piece of paper with a physical John Hancock on it, they will make a decision.
[2]: Depending on how well the jailbreak is crafted, it can destroy's iOS's security, where an app can go hog wild and do what it wants to.
Android is more secure in this regard, but apps ask for a lot of permissions . However, a rooted Android device is just as secure (barring a dumb user) than a non rooted one. Attacks like a compromised Web browser will have far less effect than they do on a PC.
On a desktop, systemd and firewalld make sense, because one might have an Ethernet connection that is in a trusted zone, a Wi-Fi adapter that is on a public (untrusted) zone, and so on. Plus, the parallel startup of systemd makes booting a lot faster.
For a server, one wants reliability and security above all. One reason why IBM still obtains boku bucks is because AIX 7.1 still runs applications written for 3.2.5. It might require some compatibility programs to be installed, but if one wanted to run FrameMaker or WordPerfect under Motif, they still can, assuming a graphics card present.
Server-side, it doesn't matter if things start in series. Things need to work properly and be coded for maximum security and reliability.
systemd is the iTunes of the Linux world. It does so much in userland, that a bug in that can mean disaster, or a series of disasters similar to the tons of sendmail holes found in the early to mid 1990s. While it does improve some things, having a large, monolithic package handle so much of userland can mean big trouble [1].
My personal take: systemd is a leap forward. But, for something this crucial to infrastructure, with so many moving parts and so many different interactions between them, this really needs to run through a bug stomping session. Maybe Facebook would torture-test it like they are doing btrfs so that virtually all the major bugs get squashed sooner, rather than later. Even better might be a formal code audit on it (a la TrueCrypt) to find and squash anything that could cause the next Shellshock or RTM worm in coming years.
The one thing that has kept the epic fails out of UNIX is the fact that the OS is made out of a lot of little subsystems. Replace bash with busybox, not that many programs would notice. Replace/bin/yes with busybox's yes... who cares. However, systemd breaks this philosophy. If something breaks, I can't just rename the binary, link in the busybox equivalent, and call it done. I'm dead in the water until a patch comes out, and since this is a subsystem that completely controls the userland environment, this is worrisome when it comes to production critical items.
[1]: Ironic how this is similar to what Tanenbaum said about the Linux kernel.
For me, it isn't the Ethernet port, but the Kensington lock slot. It would be nice to be able to tie down a laptop when not in use, so it doesn't have to be in a rental car in a seedy area of town. Bonus points for a mechanism that deters opening if the lock slot is in use, similar to what the old IBM Thinkpads had.
The certificates would be carried with the cryptographic token. If more info is needed, the old fashioned way of hitting queries is always still there.
The goal is to give people/companies just the info they need to be compliant... and nothing more.
Nail. Head. Hit. I don't want yet another Windows Tablet PC. I want a tablet, but with a docking connector where I can put the tablet in a stand (preferably a stand that has some type of locking mechanism so I can physically lock the tablet down [1].) Of course, a lightweight dock/port replicator would be nice as well, so one could use the laptop as a monitor and a BT keyboard/mouse, and the replicator would give access to USB ports and whatnot.
[1]: It is too bulky, but I'd say the PowerBook Duo dock was one of the absolute best designed docks out there. The laptop was closed and was inserted like a large VCR tape, and locking it was trivial (since it used an active motor to dock/undock.) Maybe something similar for a tablet.
When I saw the iPad, I was assuming it would be the top tier tool for music production, with the ability to handle a lot of virtual sliders. However, in a lot of cases, it only can act as an interface. Can it run ProTools with all the extensions, as well as physically handle the license dongle that some stuff has? Not really. iOS keeps the apps so far away from the device's facilities that a musical application as high end as ProTools or Logic Pro would not be usable.
For music production, a hybrid tablet would be great, especially with Thunderbolt as a way to attach hardware cards. I can see a mini studio that would configured around a device like this, where the device resides in a horizontal cradle and can function as a real time mixer, synth, DAW, and other realtime tasks.
Technically, it sits on a Mach/XNU kernel, with a BSD userland.
If you want a kernel that has an unbroken heritage, the only mainstream OS out there that would have that would be Solaris, which was formerly a BSD kernel, but switched to a AT&T SVR4 kernel. AIX also started out from AT&T code, but went with an odd mix of BSD and AT&T userland items.
All and all, kernel heritage is one thing, but consider the application first. Would someone use QNX for a large-scale database cluster? Not really. Would one use AIX for a realtime microcontroller that has to check a sail switch every 500 ms, and then turn a valve off to a propane line if the sail switch shows not enough air? Not really. There are a lot of UNIX variants (and there were far more in the past... even Dell had their own SVR4 UNIX), so choose the best tool for the job.
AFAIK, the jury is out on that fact. SSDs -tend- to be more predictive due to how they wear out. However, I've not seen any definite comparisons that state that a SSD will have a life longer than a HDD.
There is one limiting factor with SSDs: Once the electrons escape the gates, that's it. No recovery is possible unlike HDDs which the magnetic domains can be present indefinitely. So, as an archiving medium where data is stashed, it isn't very good, unless the media is constantly checked and the data moved periodically.
The a good thing to do with an iMac would be a decent SSD... as well as an external drive appliance with RAID 1, or a volume with software RAID that is similar.
How will it be leaked, is the question. Usable energy is money, pure and simple, and a disruption will get people with trillions of dollars at their disposal to hide the info, especially anyone in any energy industry. Someone who doesn't get it out far and wide will be 86-ed quickly, similar to the guy back in the Roman times who discovered aluminum, and was promptly killed for it, making a metal too good for mankind to have.
I'd probably say, it would be impossible, once the device gets past the first person. Someone comes up with a working free energy [1] source, as soon as they show it to someone, the inventor is pretty much dead.
[1]: Realistically working... like in the kilowatt to megawatt range. Some gewgaw powering a millivolt LED for a few seconds doesn't count.
A patent will just be violated, and completely ignored. Keeping it secret is the way to go, similar to Heinlein's Shipstones. Place a tamper-resistant box at the client's location, set a meter to charge by the watt-hour, and be done with it. Someone tries breaking into the box, it completely obliterates anything inside showing how it works, or just does a big kaboom, Outer Limits, "Final Exam" style.
On a large scale, build it right on top of a natural gas well. Even though the well is completely empty, nobody will know that and power is power. Done right, one can just use an electric resistance heater to blow hot air out a smokestack so it looks like some combustion is happening. Another option is to use a decommissioned nuclear reactor, pump out some heat to make it look like something is going on, and nobody would even know or care that the electricity came from atoms squeezed together as opposed to blown apart.
I'm reminded of a contraption I've seen used to restore batteries to a usable state via short, high voltage sparks (basically a crude desulfation cycle.) It was called the Bedini SSG... essentially a spinning wheel of whatever size one wants, some magnets around it, and supposedly gave more energy than it took in.
It is just a crude way to try to spark crud off of the plates in a battery, or offering "free" energy? I lean towards the former, but it is an interesting experiment, and apparently does work to get batteries usable again.
Problem is that the Safety Check assumes FB knows where you are. I have that switched off, either via iOS's allow/deny access to the GPS, or on Android since permissions are all or nothing, XPrivacy feeds it a random place each time.
For example, One of three things will happen if I eat a twister while RV-ing:
1: I'm dead. 2: I'm injured (hopefully the SPOT device or phone works.) 3: I'm OK enough to start sending texts and FB posts out with pics of the mess.
If I'm dead, it won't be that long before it is found out. Injured, similar. The benefits of getting asked if I'm OK don't outweigh the fact of being being tracked via location 24/7 and having that info handed to whomever feels like buying it.
Going on a limb here, why not replace the national ID system with a bunch of decentralized CAs that sign certificates with a piece of data. For example, a user would have some cryptographic token. This could be a smartphone, a card, a USB keyfob, a SIM card, or something similar.
Then, the state would add a signed entry with the person's name and photo to the key as a certificate. The actual public key is not affected. It just gets a cert attached that can be deleted by the user just like a PGP/gpg cert.
With this in place, the state can add a series of certs if they are true:
User is a citizen. User is 18+ years of age. User is 21+ years of age. etc.
This way, when a cardholder goes to a bar, the bar has a reader that shows a signed picture, perhaps the name of the user, and the signed fact that the user is of legal age. No other information needs to be shared. Not citizenship, not anything... just who the user is, and that they are legal (doesn't matter what their age is as long as it is above the drinking age). No cert, no booze.
Another example is a NGO use. A university signs a certificate that the key's owner has a diploma from them. When getting vetted for a job, this means that the employer knows that the applicant has a degree, but other info isn't given.
Done this way, here is what the criminals can attack:
1: The CA. If it is a distributed service, damage done can be minimized, as opposed to having everything in one basket.
2: The actual card or token. This is a solved problem. SIM card hacking on LTE networks is minimal, satellite piracy is nonexistant, and there isn't any such thing as pirated software on the XBox One. Even things like CAC/PIV cards are very rarely broken.
3: The user (yes, xkcd.com/538 applies.) However, this can be dealt with through means in place.
4: The PKI. Using different algorithms (so a document is signed by multiple keys of RSA, ECC, and something quantum-factoring resistant, and hashed with multiple algorithms) will bring some robustness.
So, there can be a national ID system, but if it is based on a PGP-like web of trust that is decentralized, it can be quite secure, but yet extremely protecting of privacy.
It really depends on the blades and 1U machines. Without exact machines, it can be a tossup, as a blade chassis takes up a ton of rack units. If comparing HP G8 blades to HP G8 1Us, the blades will edge out if they are just being use as compute nodes with the onboard storage used to load the hypervisor, then they hit the SAN for everything else. However, stacking a bunch of 1U machines can be just as good, and the advantage of 1U boxes is that you don't have to worry about the server maker discontinuing the enclosure the blades are in.
If HP can get the Moonshot environment with 45 blades in a fairly skinny enclosure going, then things will change big time, but for now, I personally lead towards a rack/blades, but there isn't anything wrong with stacking the 1Us, provides there is a decent storage and network fabric [1] that is available.
[1]: One can use the same fabric for both. Toss in some Isilon heads and a subnet for NFS or iSCSI access, call it done.
Other than the flat UI, I've been using it as a beta for a few months now. Not much really different from previous releases except some new gewgaws under the hood and some better SeatBelt like security policies. If you have debug mode in your Mac's NVRAM set, there are a few new things like a cache that gets rebuilt on bootup.
Couple new features, a new coat of paint. For the cost of the upgrade ($0), I cannot complain, and I'm pretty sure it brings to the table a number of security updates as well.
As for Windows 8, that also is a solved problem. Even without Classic Shell, it is not hard to get around.
Now, if I get a version of OS X that only allowed signed executables, didn't have a command line (or didn't have sudo/root access), wouldn't allow ssh-ing in, only allowed one program to run at a time, there is much higher chance that I booted up System 6.x on my Mac SE than OS X's userland being absolutely gutted.
Of course, there is the fact that the VM running with VMWare's fault tolerance can only have one vCPU... so this means that you can't really use it for high-availability database apps. Even a Splunk instance will set off high CPU alarms.
There are other restrictions as well. VMWare's high availability is somewhat useful (lose a running VM, it will restart the instance)... but there is the downtime waiting for the VM to come up, load its stuff, and start taking requests.
All and all, it is better than nothing, but it isn't a silver bullet.
I personally would like to see it (and its evil compatriot, firewalld) as options.
In RHEL 7 and downstreams, you can choose between LVM2, standard partitioning, or btrfs as ways to carve up your disks. It would be nice to have systemd as an option, so for laptops where parallel starting of daemons makes a nice speed increase, it is useful. For a server where one doesn't want many changes to the underlying OS unless it is something to be tested, it can be an option. If one is using containers, maybe systemd might be useful to have.
There are changes to Linux like SELinux and AppArmor which are must haves. These add significantly to the security of the OS. systemd does add security... but not really that much. One can specify that a program run with ulimits and possibly in a container, but a wrapper can do the same thing, and one thing that I get concerned about is one program having so many moving parts that touch everything on the system, even perhaps the TTY functions.
I have a strange idea. If overcrowding is not a concern, why not have the jail construction bonds go through and have it go to the usual private contractors.
A jail or prison consists of a school, dorm, library, kitchen, cafeteria, chapel, gym, infirmary, and so on. Why not just call a facility corrections related (because it does help prevent crime), and build a multipurpose building? A school, perhaps. Maybe a public library? An indoor playground for an urban area? Keep the contracts, but build things that are useful to the populace and lump them in under "corrections".
The problem is that once in prison, always in prison. With NCIC records public of both arrest and convictions, even an arrest for PI in college can keep someone from getting meaningful employment.
I know at least a few companies who ask for -arrest- (not conviction) records. The people I asked said that someone can buy their way out of a conviction, but if the cop thinks they are guilty enough to pull out the cuffs, they are guilty.
Felonies are also ridiculously easy to get. In the '80s, if two people were caught racing in their cars, it would be a $111 fine. Now, here in Texas, that is a felony.
Of course, once a felony is on a record, a person is pretty much hosed for life. For insurance reasons, few employers other than call centers will hire felons. They are not part of the voting bloc. They are prey to other felons. They cannot get apartments for the most part. Any brushes with the law will almost certainly result in an arrest. In society, they are persona non grata; the untouchables. This pretty much means that without a solid family support structure, there is no future. Good luck moving to another country. Nobody will take US felons.
So, because there isn't any real way to make income, crime is always available... which usually means arrest and another, longer sentence. Great for private prison profit margins, but a cost center until the person dies... all paid for on the US taxpayers nickel.
Swift must be really in demand. In the past few weeks, I've gotten at least five recruiters with positions open, but with requirements of at least five years work with the language.
With this in mind, having colo equipment can be just as good, if not better than using a cloud provider:
1: The equipment is yours, not theirs, so if the colo goes under, you pull your stuff out of the rack, call it done.
2: Generally you have physical control over your racks, be it a locking door on either side, or a cage (dancers not included) with one's racks inside it.
3: If you put in a SAN, proper switches, a stack of 1U machines (or rack/blades), a decent VM infrastructure (VMWare, Xen, etc.), management and logging tools, it can even perform as a DR site, at least on the level of a "disasterous recovery" with RPO/RTO metrics blown... but better that than nothing.
4: Add a tape silo, and it now becomes a place for offsite archiving.
The cloud is one tool... but people are relying too heavily on it. It has its uses, but a plain old T1 colo facility can be just as good... and there is still physical control of the data, even if it is just a deadbolt on the rack's cage.
This is a solved problem before cloud providers ever came around, and still can be solved effectively.
Any enterprise-grade SAN has asynchronous replication as a feature, so one can set up a remote site with critical data backed up in real time to another location. Done right with DNS failover, the downtime of a completely lost data center may be minimal.
Even before SANs, there was tape. It seems archaic, but modern LTO tapes are quite fast, have usable capacities, and have very easy to use encryption [1] to make the legal eagles happy. Doing a daily or weekly offsite scenario is also something that is quite common and well known.
This isn't to say the cloud is not useful, but I always ask people to think twice about using it for offsite databases and such, because with all the security breaches in the news, who knows what actually is protecting the VMs.
Cloud storage can be useful. It needs to be treated as its own type of backup media (like HDD, SDD, tape, and optical), but most enterprise backup utilities have support for storing data on it as well as clientside encryption [2].
My biggest worry about cloud providers is that they WILL get broken into, just because of the fact that they have so many eggs in one basket. Second worry is that when they go under, the servers -should- be blanked out by the auction site... but lets be real, that likely doesn't happen, so the next person who gets the actual boxes will have all the data on them, free and clear, and could post it up as a torrent if they wanted, with no legal ramifications. The only way to prevent this is to have leased third party encryption appliances that are yanked out and returned to the company leasing them before the servers go to the auction block.
[1]: https://silo1.foo.local/ log on, find the config tab, click the encryption, put an easily remembered passphrase in two blanks, click "submit", job done. The tapes are now more secure than 90% of the installations out there, so if media falls off the back of the Iron Maiden truck, it won't make the front page of the national news.
[2]: Similar configuration, but backup program specific. In Netbackup, fire up KMS, type in your "correct horse battery staple" of choice, point it to your cloud provider, and call it done.
Slashdot Mirror
I have some bills which will get "lost" if they are not sent at least certified mail. Sent electronically, it isn't anywhere near as concrete proof [1] as a piece of physical mail sent with a signature trail.
Paper complaints, especially legal work are hard to ignore. E-mail, even calls, there is no paper trail and can be hidden. However, a certified message either gets received or it gets refused. Either way, someone had to interact with the document in a provable way. Even now, our society isn't paperless and when it comes to legalities, there is no beating physical paper documents.
As for banking software on my phone, I'd say that iOS and Android have a better record for security with a few caveats [2], than a desktop machine. However, my biggest concern with too much stuff on a phone is if it gets stolen. Of course, the ideal would be having the banking software use KeyChain or Google's equivalent and ask for a PIN before it is run, so all sensitive data is encrypted, not just by the phone's encryption, but by a specific API.
[1]: Proof to judges and juries who are still in the pen and paper age, and those are the people who need to be persuaded if worse comes to worst. You can talk crypto all day long to a jury, and their eyes will glaze over. Show them a piece of paper with a physical John Hancock on it, they will make a decision.
[2]: Depending on how well the jailbreak is crafted, it can destroy's iOS's security, where an app can go hog wild and do what it wants to.
Android is more secure in this regard, but apps ask for a lot of permissions . However, a rooted Android device is just as secure (barring a dumb user) than a non rooted one. Attacks like a compromised Web browser will have far less effect than they do on a PC.
This gets me wondering what brand of SSDs is best these days. I've read a lot of good about Intel brand drives, but wonder what is decent these days.
On a desktop, systemd and firewalld make sense, because one might have an Ethernet connection that is in a trusted zone, a Wi-Fi adapter that is on a public (untrusted) zone, and so on. Plus, the parallel startup of systemd makes booting a lot faster.
For a server, one wants reliability and security above all. One reason why IBM still obtains boku bucks is because AIX 7.1 still runs applications written for 3.2.5. It might require some compatibility programs to be installed, but if one wanted to run FrameMaker or WordPerfect under Motif, they still can, assuming a graphics card present.
Server-side, it doesn't matter if things start in series. Things need to work properly and be coded for maximum security and reliability.
systemd is the iTunes of the Linux world. It does so much in userland, that a bug in that can mean disaster, or a series of disasters similar to the tons of sendmail holes found in the early to mid 1990s. While it does improve some things, having a large, monolithic package handle so much of userland can mean big trouble [1].
My personal take: systemd is a leap forward. But, for something this crucial to infrastructure, with so many moving parts and so many different interactions between them, this really needs to run through a bug stomping session. Maybe Facebook would torture-test it like they are doing btrfs so that virtually all the major bugs get squashed sooner, rather than later. Even better might be a formal code audit on it (a la TrueCrypt) to find and squash anything that could cause the next Shellshock or RTM worm in coming years.
The one thing that has kept the epic fails out of UNIX is the fact that the OS is made out of a lot of little subsystems. Replace bash with busybox, not that many programs would notice. Replace /bin/yes with busybox's yes... who cares. However, systemd breaks this philosophy. If something breaks, I can't just rename the binary, link in the busybox equivalent, and call it done. I'm dead in the water until a patch comes out, and since this is a subsystem that completely controls the userland environment, this is worrisome when it comes to production critical items.
[1]: Ironic how this is similar to what Tanenbaum said about the Linux kernel.
For me, it isn't the Ethernet port, but the Kensington lock slot. It would be nice to be able to tie down a laptop when not in use, so it doesn't have to be in a rental car in a seedy area of town. Bonus points for a mechanism that deters opening if the lock slot is in use, similar to what the old IBM Thinkpads had.
The certificates would be carried with the cryptographic token. If more info is needed, the old fashioned way of hitting queries is always still there.
The goal is to give people/companies just the info they need to be compliant... and nothing more.
Nail. Head. Hit. I don't want yet another Windows Tablet PC. I want a tablet, but with a docking connector where I can put the tablet in a stand (preferably a stand that has some type of locking mechanism so I can physically lock the tablet down [1].) Of course, a lightweight dock/port replicator would be nice as well, so one could use the laptop as a monitor and a BT keyboard/mouse, and the replicator would give access to USB ports and whatnot.
[1]: It is too bulky, but I'd say the PowerBook Duo dock was one of the absolute best designed docks out there. The laptop was closed and was inserted like a large VCR tape, and locking it was trivial (since it used an active motor to dock/undock.) Maybe something similar for a tablet.
When I saw the iPad, I was assuming it would be the top tier tool for music production, with the ability to handle a lot of virtual sliders. However, in a lot of cases, it only can act as an interface. Can it run ProTools with all the extensions, as well as physically handle the license dongle that some stuff has? Not really. iOS keeps the apps so far away from the device's facilities that a musical application as high end as ProTools or Logic Pro would not be usable.
For music production, a hybrid tablet would be great, especially with Thunderbolt as a way to attach hardware cards. I can see a mini studio that would configured around a device like this, where the device resides in a horizontal cradle and can function as a real time mixer, synth, DAW, and other realtime tasks.
Technically, it sits on a Mach/XNU kernel, with a BSD userland.
If you want a kernel that has an unbroken heritage, the only mainstream OS out there that would have that would be Solaris, which was formerly a BSD kernel, but switched to a AT&T SVR4 kernel. AIX also started out from AT&T code, but went with an odd mix of BSD and AT&T userland items.
All and all, kernel heritage is one thing, but consider the application first. Would someone use QNX for a large-scale database cluster? Not really. Would one use AIX for a realtime microcontroller that has to check a sail switch every 500 ms, and then turn a valve off to a propane line if the sail switch shows not enough air? Not really. There are a lot of UNIX variants (and there were far more in the past... even Dell had their own SVR4 UNIX), so choose the best tool for the job.
AFAIK, the jury is out on that fact. SSDs -tend- to be more predictive due to how they wear out. However, I've not seen any definite comparisons that state that a SSD will have a life longer than a HDD.
There is one limiting factor with SSDs: Once the electrons escape the gates, that's it. No recovery is possible unlike HDDs which the magnetic domains can be present indefinitely. So, as an archiving medium where data is stashed, it isn't very good, unless the media is constantly checked and the data moved periodically.
The a good thing to do with an iMac would be a decent SSD... as well as an external drive appliance with RAID 1, or a volume with software RAID that is similar.
How will it be leaked, is the question. Usable energy is money, pure and simple, and a disruption will get people with trillions of dollars at their disposal to hide the info, especially anyone in any energy industry. Someone who doesn't get it out far and wide will be 86-ed quickly, similar to the guy back in the Roman times who discovered aluminum, and was promptly killed for it, making a metal too good for mankind to have.
I'd probably say, it would be impossible, once the device gets past the first person. Someone comes up with a working free energy [1] source, as soon as they show it to someone, the inventor is pretty much dead.
[1]: Realistically working... like in the kilowatt to megawatt range. Some gewgaw powering a millivolt LED for a few seconds doesn't count.
A patent will just be violated, and completely ignored. Keeping it secret is the way to go, similar to Heinlein's Shipstones. Place a tamper-resistant box at the client's location, set a meter to charge by the watt-hour, and be done with it. Someone tries breaking into the box, it completely obliterates anything inside showing how it works, or just does a big kaboom, Outer Limits, "Final Exam" style.
On a large scale, build it right on top of a natural gas well. Even though the well is completely empty, nobody will know that and power is power. Done right, one can just use an electric resistance heater to blow hot air out a smokestack so it looks like some combustion is happening. Another option is to use a decommissioned nuclear reactor, pump out some heat to make it look like something is going on, and nobody would even know or care that the electricity came from atoms squeezed together as opposed to blown apart.
I'm reminded of a contraption I've seen used to restore batteries to a usable state via short, high voltage sparks (basically a crude desulfation cycle.) It was called the Bedini SSG... essentially a spinning wheel of whatever size one wants, some magnets around it, and supposedly gave more energy than it took in.
It is just a crude way to try to spark crud off of the plates in a battery, or offering "free" energy? I lean towards the former, but it is an interesting experiment, and apparently does work to get batteries usable again.
Problem is that the Safety Check assumes FB knows where you are. I have that switched off, either via iOS's allow/deny access to the GPS, or on Android since permissions are all or nothing, XPrivacy feeds it a random place each time.
For example, One of three things will happen if I eat a twister while RV-ing:
1: I'm dead.
2: I'm injured (hopefully the SPOT device or phone works.)
3: I'm OK enough to start sending texts and FB posts out with pics of the mess.
If I'm dead, it won't be that long before it is found out. Injured, similar. The benefits of getting asked if I'm OK don't outweigh the fact of being being tracked via location 24/7 and having that info handed to whomever feels like buying it.
Going on a limb here, why not replace the national ID system with a bunch of decentralized CAs that sign certificates with a piece of data. For example, a user would have some cryptographic token. This could be a smartphone, a card, a USB keyfob, a SIM card, or something similar.
Then, the state would add a signed entry with the person's name and photo to the key as a certificate. The actual public key is not affected. It just gets a cert attached that can be deleted by the user just like a PGP/gpg cert.
With this in place, the state can add a series of certs if they are true:
User is a citizen.
User is 18+ years of age.
User is 21+ years of age.
etc.
This way, when a cardholder goes to a bar, the bar has a reader that shows a signed picture, perhaps the name of the user, and the signed fact that the user is of legal age. No other information needs to be shared. Not citizenship, not anything... just who the user is, and that they are legal (doesn't matter what their age is as long as it is above the drinking age). No cert, no booze.
Another example is a NGO use. A university signs a certificate that the key's owner has a diploma from them. When getting vetted for a job, this means that the employer knows that the applicant has a degree, but other info isn't given.
Done this way, here is what the criminals can attack:
1: The CA. If it is a distributed service, damage done can be minimized, as opposed to having everything in one basket.
2: The actual card or token. This is a solved problem. SIM card hacking on LTE networks is minimal, satellite piracy is nonexistant, and there isn't any such thing as pirated software on the XBox One. Even things like CAC/PIV cards are very rarely broken.
3: The user (yes, xkcd.com/538 applies.) However, this can be dealt with through means in place.
4: The PKI. Using different algorithms (so a document is signed by multiple keys of RSA, ECC, and something quantum-factoring resistant, and hashed with multiple algorithms) will bring some robustness.
So, there can be a national ID system, but if it is based on a PGP-like web of trust that is decentralized, it can be quite secure, but yet extremely protecting of privacy.
We have the same thing here in the US, but good luck getting a new SSN if it gets compromised.
At this rate, lets just check systemd into the Linux kernel tree itself and call it done.
It really depends on the blades and 1U machines. Without exact machines, it can be a tossup, as a blade chassis takes up a ton of rack units. If comparing HP G8 blades to HP G8 1Us, the blades will edge out if they are just being use as compute nodes with the onboard storage used to load the hypervisor, then they hit the SAN for everything else. However, stacking a bunch of 1U machines can be just as good, and the advantage of 1U boxes is that you don't have to worry about the server maker discontinuing the enclosure the blades are in.
If HP can get the Moonshot environment with 45 blades in a fairly skinny enclosure going, then things will change big time, but for now, I personally lead towards a rack/blades, but there isn't anything wrong with stacking the 1Us, provides there is a decent storage and network fabric [1] that is available.
[1]: One can use the same fabric for both. Toss in some Isilon heads and a subnet for NFS or iSCSI access, call it done.
Other than the flat UI, I've been using it as a beta for a few months now. Not much really different from previous releases except some new gewgaws under the hood and some better SeatBelt like security policies. If you have debug mode in your Mac's NVRAM set, there are a few new things like a cache that gets rebuilt on bootup.
Couple new features, a new coat of paint. For the cost of the upgrade ($0), I cannot complain, and I'm pretty sure it brings to the table a number of security updates as well.
As for Windows 8, that also is a solved problem. Even without Classic Shell, it is not hard to get around.
Now, if I get a version of OS X that only allowed signed executables, didn't have a command line (or didn't have sudo/root access), wouldn't allow ssh-ing in, only allowed one program to run at a time, there is much higher chance that I booted up System 6.x on my Mac SE than OS X's userland being absolutely gutted.
Of course, there is the fact that the VM running with VMWare's fault tolerance can only have one vCPU... so this means that you can't really use it for high-availability database apps. Even a Splunk instance will set off high CPU alarms.
There are other restrictions as well. VMWare's high availability is somewhat useful (lose a running VM, it will restart the instance)... but there is the downtime waiting for the VM to come up, load its stuff, and start taking requests.
All and all, it is better than nothing, but it isn't a silver bullet.
I personally would like to see it (and its evil compatriot, firewalld) as options.
In RHEL 7 and downstreams, you can choose between LVM2, standard partitioning, or btrfs as ways to carve up your disks. It would be nice to have systemd as an option, so for laptops where parallel starting of daemons makes a nice speed increase, it is useful. For a server where one doesn't want many changes to the underlying OS unless it is something to be tested, it can be an option. If one is using containers, maybe systemd might be useful to have.
There are changes to Linux like SELinux and AppArmor which are must haves. These add significantly to the security of the OS. systemd does add security... but not really that much. One can specify that a program run with ulimits and possibly in a container, but a wrapper can do the same thing, and one thing that I get concerned about is one program having so many moving parts that touch everything on the system, even perhaps the TTY functions.
I have a strange idea. If overcrowding is not a concern, why not have the jail construction bonds go through and have it go to the usual private contractors.
A jail or prison consists of a school, dorm, library, kitchen, cafeteria, chapel, gym, infirmary, and so on. Why not just call a facility corrections related (because it does help prevent crime), and build a multipurpose building? A school, perhaps. Maybe a public library? An indoor playground for an urban area? Keep the contracts, but build things that are useful to the populace and lump them in under "corrections".
The problem is that once in prison, always in prison. With NCIC records public of both arrest and convictions, even an arrest for PI in college can keep someone from getting meaningful employment.
I know at least a few companies who ask for -arrest- (not conviction) records. The people I asked said that someone can buy their way out of a conviction, but if the cop thinks they are guilty enough to pull out the cuffs, they are guilty.
Felonies are also ridiculously easy to get. In the '80s, if two people were caught racing in their cars, it would be a $111 fine. Now, here in Texas, that is a felony.
Of course, once a felony is on a record, a person is pretty much hosed for life. For insurance reasons, few employers other than call centers will hire felons. They are not part of the voting bloc. They are prey to other felons. They cannot get apartments for the most part. Any brushes with the law will almost certainly result in an arrest. In society, they are persona non grata; the untouchables. This pretty much means that without a solid family support structure, there is no future. Good luck moving to another country. Nobody will take US felons.
So, because there isn't any real way to make income, crime is always available... which usually means arrest and another, longer sentence. Great for private prison profit margins, but a cost center until the person dies... all paid for on the US taxpayers nickel.
Swift must be really in demand. In the past few weeks, I've gotten at least five recruiters with positions open, but with requirements of at least five years work with the language.
With this in mind, having colo equipment can be just as good, if not better than using a cloud provider:
1: The equipment is yours, not theirs, so if the colo goes under, you pull your stuff out of the rack, call it done.
2: Generally you have physical control over your racks, be it a locking door on either side, or a cage (dancers not included) with one's racks inside it.
3: If you put in a SAN, proper switches, a stack of 1U machines (or rack/blades), a decent VM infrastructure (VMWare, Xen, etc.), management and logging tools, it can even perform as a DR site, at least on the level of a "disasterous recovery" with RPO/RTO metrics blown... but better that than nothing.
4: Add a tape silo, and it now becomes a place for offsite archiving.
The cloud is one tool... but people are relying too heavily on it. It has its uses, but a plain old T1 colo facility can be just as good... and there is still physical control of the data, even if it is just a deadbolt on the rack's cage.
This is a solved problem before cloud providers ever came around, and still can be solved effectively.
Any enterprise-grade SAN has asynchronous replication as a feature, so one can set up a remote site with critical data backed up in real time to another location. Done right with DNS failover, the downtime of a completely lost data center may be minimal.
Even before SANs, there was tape. It seems archaic, but modern LTO tapes are quite fast, have usable capacities, and have very easy to use encryption [1] to make the legal eagles happy. Doing a daily or weekly offsite scenario is also something that is quite common and well known.
This isn't to say the cloud is not useful, but I always ask people to think twice about using it for offsite databases and such, because with all the security breaches in the news, who knows what actually is protecting the VMs.
Cloud storage can be useful. It needs to be treated as its own type of backup media (like HDD, SDD, tape, and optical), but most enterprise backup utilities have support for storing data on it as well as clientside encryption [2].
My biggest worry about cloud providers is that they WILL get broken into, just because of the fact that they have so many eggs in one basket. Second worry is that when they go under, the servers -should- be blanked out by the auction site... but lets be real, that likely doesn't happen, so the next person who gets the actual boxes will have all the data on them, free and clear, and could post it up as a torrent if they wanted, with no legal ramifications. The only way to prevent this is to have leased third party encryption appliances that are yanked out and returned to the company leasing them before the servers go to the auction block.
[1]: https://silo1.foo.local/ log on, find the config tab, click the encryption, put an easily remembered passphrase in two blanks, click "submit", job done. The tapes are now more secure than 90% of the installations out there, so if media falls off the back of the Iron Maiden truck, it won't make the front page of the national news.
[2]: Similar configuration, but backup program specific. In Netbackup, fire up KMS, type in your "correct horse battery staple" of choice, point it to your cloud provider, and call it done.