Slashdot Mirror

There are already tools to detect that, at least some of them are FOSS:
https://www.alfresco.com/blogs...

For example this one is open source:
https://coreos.com/blog/vulner...

My intention is not to spread FUD. I'm genuinely interested and what you wrote in your answer is definitely something to look into. My understanding is that this is however not the way most Docker users uses Docker, but I don't have any statistics. However, according to some people that do it doesn't look very good.

For example, CVE-2014-0160, aka "Heartbleed" has been known for over 18 months, yet Quay Scanning found it is still a potential threat to 80 percent of the Docker images users have stored on Quay. Just like CoreOS Linux contains an auto-update tool which patched Heartbleed at the OS layer, we hope this tool will improve the security of the container layer, and help make CoreOS the most secure place to run containers.

Now I don't know exactly what Quay is. But if 80 percent of images are still vulnerable to something that was fixed over 72 hours ago then that sounds like a lot of people are seriously not paying attention.

Nothing as far as a distro (or desktop environment) with 3D VR or AI comes to mind but there is innovation in OS going on. Not many have attempted to answer the OP, so here's my list. Others mentioned Qubes, Urbit, and Mirage.io, which reminded me of Nix OS and HaLVM.

Both innovative and seems daily-driver ready:
1. Qubes OS - https://www.qubes-os.org/ - Linux distro that runs a Xen hypervisor to contain every app (including Windows ones) away from the desktop environment
2. Haiku OS - https://www.haiku-os.org/ - Tiny (under 200MB installed), Non-Linux that is binary-compatible with BeOS, nice understated GUI that is bland but usable
3. ReactOS - http://reactos.org/ - Win32 compatible open source OS, very active development scene working toward full NT kernel ABI compatibility. Seems stable enough to be a daily driver but hardware support is lacking
4. PC-BSD & freeBSD 10 - http://www.pcbsd.org/ http://www.freebsd.org/ - PC-BSD is a desktop distro of freeBSD 10 built for user-friendliness with automatic ZFS snapshoting and a nice graphical package manager, freeBSD 10 has a completely new package manager (pkg-ng replaces the 'pkg' binary)
5. Nix OS - https://nixos.org/ - Linux distro with innovative package manager promising atomic upgrades & rollback.

Innovative server-exclusive (ie no GUI):
5. SmartOS - https://smartos.org/ - Solaris + KVM + Docker w/ full Dtrace support. Claims ZFS as an innovation? Joyent is running a cloud of it
6. CoreOS - https://coreos.com/ - Linux distro exclusively for large Docker deployments. developing a suite of Go tools for datacenter management.

Innovative, but not ready for desktop use:
7. Redox OS - http://www.redox-os.org/ - OS written in Rust (rust-lang), which guarantees a lot of memory-safety, screenshots of desktop in 'News' section
8. Contiki OS - http://www.contiki-os.org/ - Linux distro for IoT embedded devices that claims an innovative network stack
9. Urbit - http://urbit.org/docs/user/int... - *nix distro with exclusively web-based userland, invite-only at the moment, doesn't seem like it will have a UI but that each user is the dev of their own interface
10. Mirage.io - http://mirage.io/ - Develop each app and compile into a single-purpose kernel to be run on some hypervisor
11. HaLVM - https://github.com/GaloisInc/H... - The Haskell Ligthweight Virtual Machine - which runs just the GHC on Xen, another 'build uni-purpose VMs' system

You hated init scripts ? I loved them. I loved the flexibility and power they gave me. If I wanted my webserver to start later, or I wanted to tweak the way it got started to fit some localized need - I could do that, with no risk of breaking anything else. How exactly would I do this with systemd ? It's opague and hard to figure out and badly documented and I can't pipe the stuff between a thousand disparate commands to construct whatever I need on the fly as and when I need it - those are the REASONS to use Linux (technical reasons).

you could use Before= and After= in the systemd unit files, you can even place overrides in /etc/systemd/system/ instead of modifying the package files in /usr/lib if you so choose:

https://coreos.com/docs/launching-containers/launching/getting-started-with-systemd/

Do you know what, editting what is typically 10 lines of key=value pairs in a config file is a hell of a lot easier and safer than monkying with some bash script.(or dash in debian).

Do you know what else I don't miss, stuck proccesses, when a proccess hangs, and /etc/init.d/proccessname can't do a damn thing about it, and it still leaves its pid file to clean up. speaking of which, the PID file is the only way that the rest of the system knows if the program is running or not. systemctl stop has never failed me. It hits with the power of kill -9 and cleans up the mess. Which is great because if you run a poorly written program with an equally poorly written init script, systemd is better at getting that crap off your system.

Oh yeah, and the fact is your running a shell script to start and stop programs. What could possibly go wrong. Its like having your car held together with duct tape.

but yes, systemd is very configurable, with easy to read configuration files. Configuration files that work key=pair, like everything else.

Then we get to runlevels, instead of an esotetic mess of 123560, we get singleuser, multiuser,reboot, etc...

If you want/need syslog back you can edit /etc/systemd/journald.conf and uncommont FowardToSyslog= and change the value to "yes".

it is, in fact, a very sound way to engineer an operating system

Its a sound way to engineer nothing. Its akin to having many moving parts, and many more points of failure. One of GNU/Linux's greatest weaknesses is that its many moving parts written by diffrent peope.

people weren't this pissed when HAL was depreciated and the functionality taken over by udev. Again, one less moving part. One less point of failure.

Just in case anybody wanted to pick political sides, CoreOS sponsored the development of networkd for systemd. So, the systemd perspective is the perspective that they're using when they criticize Docker for not being a tool that does one thing well.

... but rationalizing it. Sometimes you just need to run more or less isolated single apps, not for a full blown OS. In a lot of usage scenarios is far more efficient, (both in disk/memory/cpu usage and app density) and probably more flexible. In others full OS virtualization or running on dedicated hardware may be the best option.

It also brings a virtualization-like approach for apps in the cloud. You can have cointainerized apps in aws, google apps and many others, something like having a vm inside a vm.

Is not the only solution of its kind. Google is heavily using containers in Omega (you can try their container stack with lmctfy), you can use openvz, lxc, or solaris zones or bsd jails. But the way that docker mixes containers (not just lxc by 0.9) with union fs, making them portable and to have inheritance, is a touch of genius.

The missing pieces are being added by different projects. CoreOS as a dedicated OS for containers (that coupled with etcd and fleet could become a big player in a near future), OpenStack/OpenShift bringing manageability, and maybe someone could bring to the table what Omega does with google containers.

Unlike the article, http://coreos.com/ front page actually summarizes what they are doing. Stripped down Linux kernel only OS that runs your apps in 'containers'.