willsher

Whether software based access control is sufficient depends on the workload and where in the stack the workload runs. I agree though, hardware virtualisation based is more secure and less complex. It also requires access to bare metal, so a providers service or run it yourself, which is a trade off.

They are, or should be, entirely self contained such that whatever segregation is employed - be it hardware via a VM or in kernel with apparmor or SELinux provides sufficient segregation for the work load. V8s problem is JavaScript and NPM, but limiting the blast radius with hardware virtualisation is a win for segregation and v8 will win, at least for front end, because it’s got the mindset. As long as the library ecosystem cleans up.

There is a value that transcends money. Value to society as a whole. Sure people need to live and have basic needs met, but to transcend finance is perhaps a necessity. One can make do with a lot less when the soul is enriched, when we take solace from the learning of humanity.

Humanities - history, geography, politics, religion and partially are economics, are our legacy; what we are and therefore what we can become. They are arts not sciences. Oral and written tradition for generations before technology & science. Of course this is important to humans, and as a species we should embrace it. Computers should augment us, not replace is.

It seems the nature of this and VR that they come to boom for a while and then bust, having stagnated. They then wait for the next alignment of underpinning technology, knowledge and culture to emerge again. Last last one I'm aware of was mid-late 1990s, where VRML was gaining traction and new ways of thinking about AI were emerging.

IBM Watson or similar (if I recall IBM was still calling their business AI system Watson back then) seems to be promenant in these two booms and both times the results it gives haven't matches it's marketing hype.

The technology, having been significantly furthered fades into the day to day of computing somewhat until the next boom that drives more short burst innovation and awareness.

Conscious AI and realistic VR is some way off, if we ever see it. Culturally and ethically we are not ready to answer the questions it poses and the cyclical nature gives us more time to digest the latest raft of questions in light of the progress.

My understanding from my Solaris days was that CPU load is the number of processes queued for CPU time over the given period. It doesn't related to usage directly at all. (Other than higher cpu speed and io through out leads to a reduction in load because tasks finish quicker)

I though of seven. Is there any significance to the number one Kubernetes?

That's part of the point of doing it to me. They can, hopefully, use the data in a useful way. Sure, they may make it private and paid for the data set they have, but I also have a copy of the data I can upload to other more publicly minded companies.

From a selfish point of view, perhaps my DNA will contribute to solving some of the illnesses I'm more prone to to or already have, and help my children if they treatment. From a more altruist view, it may help others too.

Do I trust Big Pharma? I'm not sure I do, but what I do know is medical advances are making many people's lives more bearable and longer, both in developed and developing nations.

There are still a few gotchas on the low level stuff, especially networking, but also other areas that involve kernel drivers more directly.

The security around the containers still isn't as good as a hardware VM, but I think hardware segregation is on the road map.

It's ideal for running container inside VMs, though, and offers nice management segregation on those larger VMs.

From research around the Internet, D3 is generally seen as safe (http://www.mayoclinic.org/drugs-supplements/vitamin-d/safety... is pretty typical on the safety information) Personally I take a D3 supplement of 2000IU/day during the dark months (along with some other supplements due to a mostly vegan diet, some of which contain low D2/D3 amounts, so my actual supplemented intake is around 2400 IU).

Config management, as it currently stands with Puppet/Chef etc./ ideally has no place _in_ containers iff the issue of how applications are deployed there can be solved in a suitably generic and straight forward way. A container becomes and immutable item - logs get shipped off container, config comes from service discovery, failing containers get taken out of service.

There is a need for shims like confd, though perhaps we'll see configuration information libraries emerge that can go straight to a service discovery/config lookup endpoint such as etcd or zookeeper.

All of the config management tools have some sort of overhead and all affect the ability for a container (bar its data in the case of databases) to be immutable.

Building the container should be as simple as installing the package for the given app into whatever container systems is being used, be it Docker, a more bare bones container, or something that comes from the standarisation effort.

The base 'OS' in the container then becomes irrelevant, as the base OS is really the containing, host OS, with the containers just containing the apps and not additional overhead.

In terms of where configuration management fits, it potentially is at the orchestration level, but that said there are already other, more specialised tools emerging in that space too.

That's a fair point, but the alternative of always compiling the packages at the point in time negates that, at the risk of regressions and other 'new version' bugs, but that may be endemic in this anyway - if the author of the golang container built it at a point in time against version X, then went away and left the container alone, upgrading versions may become risky in any case.

Those kind of risks, and perhaps the larger container risks look like CI pipeline issues - how is the container tested a given new versions? As an adjunct, how do we so container component integration testing? Is that part of this packaging & building system?

Which version of X library can be introspected via which binary is linked, rather than which package is installed - inspecting the actuality rather that an meta-data wrapper in the form of a package may be preferable.

As for static vs dynamic binaries, is dynamic less memory intensive even in containers - that is, do library version get shared across containers in RAM or are they separate? If not separate, static may be much easier to manage in general, though there maybe cases where they can't be provided. Upgrading the app involves a recompile, but that's a container building exercise. Versioning can then become tied explicitly to the container version, or by inspecting the static binary.

There is also pkgsrc, which from memory can be build to be separate from the underlaying OS. FreeBSD's ports is similar. Slackware's packaging is based off simple tar files.

It does seem that this software build/deploy is a key problem that needs solving and the decentralised, easy to grok nature of Docker is key to the software delivery system. Nix is a really clever bit of engineering and design, but is also hard to grasp. Could it be made more simple? I suspect it's 'functional' nature is the hard part.

The nature of containers being essentially immutable, at least from a base software stance, with packages not being upgraded so much as newly installed avoids the problem of upgrading running services. Most (all?) software would run as its own user, so no root level daemons.

Configuration files are built from service discovery (e.g. via Kelsey's confd in lieu of the apps themselves deriving config), so even config need not be preserved if a roll back to prior to the package layering is done.

Just some thoughts, but I agree there is a need to better manage dependencies. Heck, why not build static linked binaries?