Virtualization != sandboxing. You can sandbox on Windows with SandboxIE, where all writes from the sandboxed app are redirected elsewhere. Doing this doesn't require a separate OS or filesystem, so it doesn't add that context shifting as overhead.

You can also run your Web browser in a VM. You get better separation, but at a price, although with hypervisors becoming the norm and not the exception, running VMs may not have as onerous a penalty as they used to.

I like a combination of the two. I like browser windows and tabs separated from each other, like what Chrome/Chromium does, but the browser should run in its own VM so if something does get out of the browser, it is in a completely separate user and machine context. Without the VM isolation, even if malware just has context of a user, that can allow files to be uploaded and ransomware to do its dirty work.

Jails are another solution, but it can be argued that it might be best to completely isolate filesystems, especially if some software decides to do stuff like mkdir foo; cd foo loops, or just create tons of files in order to use up all inodes. Done on a VM, worst case, it means one dumps the VM and rolls back. Done on a desktop, it can mean work stoppage.

I've wondered about this myself, because I took some time out of my career to pursue my degree full time. Are companies using a B. S. or a B. A. as a filter these days, or has the filter mechanism moved to the keywords and/or certifications like a MCSE? Times have changed. About 10-15 years ago, in a recession, you could sidestep stuff by going back for a M. S., and when you got the degree, it would mean higher pay. Now, I don't see that being the case.

It depends on countries. When I was in college, I had classmates from Germany, China, and Chile. The Chinese government paid for the education for their citizen. The German had his paid for. The Chilean had his paid for by his government. It was the people in the US who were paying for their own education in a STEM major. The US needs to stop eating its seed corn.

If there is a need for transactions to be atomic, perhaps multiple signatures with expiration dates would be useful. One to "pre-sign" the transaction, and if that transaction isn't cancelled (perhaps with a nonce that is stored as a hash), after "x" amount of time, the transaction becomes permanent. Or, a signature to start a transaction, another to end it. One can use blockchain technology in a lot of ways, and allowing people to "un-sign" something is just asking for trouble.

At least it can ship with Ubuntu by default. If W10 is needed, it can be run under VMWare, VirtualBox, or one's virtualization utility of choice. That way, Windows 10 can be run, but it is isolated from the hardware.

As for options, I would go with the M7, 480GB SSD, and glass case. One can't argue with a beefier CPU (assuming cooling isn't an issue), and more disk space. The glass case is useful for tamper resistance.

My only wish is if the device had a port for a Kensington lock slot, with some mechanism to zero out keys if someone yanked out something out of the slot by force.

Of course, there is blue-sky stuff. For example, a S/PDIF port that would be used with a fiber optic cable as a tether. If the S/PDIF port got unplugged or the fiber optic cable got cut, the keys would be zapped. This would provide extreme security, with the only way to get around it is to destroy what the fiber optic cable was looped around.

I've ended up using VPNs to get around that. It isn't cheap, but a Linode box acting as a NAT/proxy box [1], with a VPN to your real machines can get around most of that. You can also use AWS, a router OS like VyOS or PFSense, and a VPC to also allow for your home servers to have a "legitimate" IP to handle incoming traffic.

[1]: Assume the Linode box can be compromised at any moment, so don't terminate your TLS connections there. Terminate them on your machines. It also is wise to have provisioning scripts (or Ansible playbooks) so if your Linode instance gets compromised, you can zero it out and rebuild it quickly.

That can be solved. It would take a PKI, but I can see something like USENET with some trusted CAs, ability for people to chose whom they trust, and signed messages doing a good job at stopping spam. If someone does spam, their cert gets revoked, or if a SLC based system is used, the CA just doesn't bother to sign the certs, and the nodes forwarding traffic just drop anything from that key.

The problem is that decentralized PKI research stopped at PGP, and the world moved to SSL/TLS's model of all or nothing trust. If we had various amounts of trust, a decentralized model would stop spam, but would also keep the same anti-spam mechanisms from being used for censorship.

I remember a few years back, having a FB account was pretty much a job requirement, where I got told to bugger off because I didn't tell the world how many coils I dropped in the commode that morning. It has gotten better, but for a while, I eventually just wound up making a dummy account on there, Twitter, and other places just to make the HR people happy.

It isn't just Facebook. I'm seeing companies put all their eggs in the AWS basket. My fear is that cloud providers overtake having servers in-house, and we are back to the mainframe era. Cloud places have their use, but there is always the security question, and there is always the grave concern about data sitting on a remote site where you have zero physical control over it. If there is a security breach and the data is local, you can physically yank the network cable. If there is a breach at a cloud provider, trying to staunch the bleeding is a lot tougher, especially if one of the cloud accounts got hacked, and the rogue admin has just as much power as you do.

Right now, we are at the point where a technology is starting to be widely adapted, and people are nervous about it (perhaps rightly so.)

However, I can list a number of things that can save time:

1: Being able to use commute time for something else than watching the taillights of the car ahead. You can have a vehicle which can function as a mobile office, or a bedroom, where with longer commutes, use that time for useful things, be it reading, doing some work, or just going back to sleep.

2: Vehicles can take themselves to get oil changed and inspected. This can save a day's worth of work.

3: Fewer trips would be needed. With a self-driving van, one can call Home Labyrinth, run the credit card, have the van drive to the pickup depot, and come back. This way, if someone runs out of plywood, but still has stuff to do, all it takes is a quick order via a web page, and work can continue.

4: If you are drunk, stoned, tripping balls, high, or all the above, you can still go home in your own vehicle. This in itself will save a lot of time because the police will have to clean up fewer wrecks.

5: Vehicle safety can improve. Cars can be packed closer together, intersections for highways can be made into simple four way intersections, with the cars slowing up or speeding up so vehicles can fly through without having to stop.

6: It saves time parking. Parking of automated vehicles can be handled far more densely than normal parking. Vehicle parking can be moved to the outskirts and not downtown, with a small lot used for quick unloading/loading.

7: It would allow for long trips easily, assuming vehicle auto-fueling. Speed limits can be tossed out the window, with the speed of the vehicle being what it can do, as well as environmental conditions.

8: If you need to carry a lot of stuff to a jobsite, and you just have one person, you can load multiple vehicles.

Of course, there are a few issues that need to be solved:

1: Security. If a blackhat could lock a vehicle's doors and demand ransom, or else it will ram the vehicle (and its occupants) off a bridge, that would be a show-stopper.

2: Third party control. It could be done that cars could be told that they cannot stop at or near areas, or that when someone hops in their car, it takes them downtown for jail processing because of a warrant. Or, some bill collector gets with the car maker and shuts down cars.

3: Corner cases. Thankfully few, but there will be many people out there looking for many ways to get a driving AI to fuck up, so they can play the lawsuit lottery.

All and all, there are issues, but the benefits are quite useful, and far outweigh the risks (which can be mitigated.) Security can be done. For example, the XBox is going on years, with not a single working jailbreak. Similar with the PS4. Even humble old Blu-Ray is still a cat and mouse game, with fewer and fewer decoding utilities available. Third party control can be legislated. Corner cases are relatively few, and that is what insurance is for, as well as dash cams to show if it was a true deliberate action.

Is it possible to roll back to an earlier version? Even though it is rather old, the pre-AOL one wouldn't be too bad. Maybe the one before Canter & Seigel? Heck, I'd take the one before Eternal September.

Well okay, seeing as how I'm part of that 'science industry' as you put it, your claim is interesting if true. Let's see here, the first study detected proteins at a level lower than that test can accurately detect (ergo it was noise), the second one doesn't seem to indicate anything special about GE crops, the third one is mere correlation by a known liar with a made up institute (you could use that exact same bogus methodology to link those maladies with organic food sales), the fourth one has been widely debunked for extremely shoddy methodology, then next couple are about glyphosate, not actually genetic engineering, which is it's own often misunderstood topic, the ninth study was based basically on eyeballing pig organs with nothing particularly substantive and was widely criticized when it made the rounds a few years back, and a quick glance over the tenth one looks to me like it does not actually indicate anything about genetic engineering being dangerous, rather it seems to be criticizing not using a one size fits all approach to testing (not a criticism I would make).

So yeah, try again. Maybe explain to me what the causative mechanism is on the genetic and molecular levels and why it shows up in no other type of natural or man made genetic alteration while you're at it because I never really got that part about the claimed dangers of genetic engineering.

Now, about those bribes, know where I can sign up for Monsanto's Free Money Program? Because those stingy bastards haven't been paying me like they're apparently supposed to.

Why? Do you have any evidence to indicate what you are implying, that somehow the corporate conspiracy owns most plant scientists? Because there's also money to be made in literally everything sold at a profit, which is most things, so what's your point?

Linux is nice because one can secure at as they see fit. Someone on the operator level can enable patching at certain times in RedHat and downstreams, Debian, and Ubuntu, with ease. This isn't something you would do in production for obvious reasons, but with modern mainstream Linux distros with their default installs, it actually is more work to not enable patching than to enable it.

An admin that is more versed would be using some sort of patch management system, if only to ensure that SSH, OpenSSL, the kernel, and other critical components are not just patched, but there is validation that things are at that patch level.

Next tier up, the admin would have a CM tool which either gets pushed or runs locally with a stanza like this:

---
- name: Update openssl
    package: name=openssl state=latest

The above stanza would get pushed to all boxes every so often.

Of course, Linux can be horrific if unpatched, because there is so much a blackhat can do on a Linux box, even if root access is unavailable. However, in general, because Linux is open, there are fewer moving parts which are hidden away from the user. For example, when Shellshock came out, and a quick patch had to be done, it wasn't hard to build a static busybox binary as a workaround until a few hours later, bash was patched.

One ideal might be having good in and out firewall rules on the machine. It takes time for initial setup and maintaining, but isn't that bad (it can be put in your playbooks or .pp files.) That way, a telnet server will be not accessible by anything.