Introducing the “rhel-tools” for RHEL Atomic Host | Hacker News Reader

Introducing the “rhel-tools” for RHEL Atomic Host

developerblog.redhat.com

64 pointsjeremyeder17 comments

Maybe containers can be the norm for all systems. Not just specialized server OSes. Need to install a video editing suite that has many packages? - use the container, etc.

I can't help but think what a failure of the Linux user land this is - we're essentially saying the only thing we can count on being there is the kernel?

Despite the plethora of Docker articles here on HN, I haven't paid much attention to containers. Reading this article, I get the impression that they occupy a niche somewhere between a chroot jail and a VM.

The question is, how to deploy an application in this kind of environment? Maybe I build a minimal container and find that a DBMS works fine until it does something like dlopen("/usr/lib/libxml2.so"). Oops, rebuild the container with another library and try again.

After fixing one of the broken links in the blog post, I found this article, which describes an Oracle container:

http://rhelblog.redhat.com/2014/10/29/containerizing-databas...

Yeah, it's called testing. But it's no different from, say, building a server and finding that the DBMS works fine until it doesn't. The only difference is that when you fix it, you can be sure(er) that you've actually fixed it, compared to a classic server, where there is a lot of state that can obscure the real problem.

Thank you, we will fix the link.

I agree. A couple of days ago there was a mention about Wirth's law [1], which reminded me how far we went with containers.

I'm using vagrant for development and sometimes I run 2-3 containers with the same project.

My MacBook has 16 GB RAM, 2.8 i7 CPU, but no wonder I have troubles with the CPU going to the top.

I'm not sure how far containers will be popularised, but indeed it will definitely have some performance drawbacks.

[1] : http://en.wikipedia.org/wiki/Wirth%27s_law

GNU/Linux is no better than other UNIX alternatives, it basically has the same bag of problems as during the UNIX wars.

There is no such thing as a linux user land. So no, the only thing you can count on is the kernel.

With systemd we are almost there http://www.freedesktop.org/software/systemd/man/systemd-nspa...

And when one of the usual system libraries is compromised (glibc, libssl, libxml), everyone need to update their containers.

To make this workable, I guess you have to union mount the application-specific filesystem over a filesystem with ABI-stable system libraries.

The systemd team has some goals around this, but the current 'state of the art' is that you reship all your containers.

I'm not sure how the systemd btrfs volume scheme actually solves this issue. The only ones who seem to have solved the problem are Nix through the use of isolated environment builds, associating packages via hashes and building anew for every discrepancy (new version, different configuration switch) while associating it in a store.

I see it as Red Hat's attempt to mitigate the long life cycles of its releases. Balancing the stability of a consistent OS without have to deal with an out of date (prehistoric) tool set.

That's what Software Collections are for.

http://dev.centos.org/centos/6/SCL/docs/#chap-RHSCL

Maybe something similar to how apple have "application packages" now?

each program is confined to it's own directory by default and has everything it needs to run.. if it depends on something in the OS, it's aware it's there because of the release version and distro..

this could be done easily in a manifest file (you can ask yum for instance what's installed).

maybe I'm overthinking it, maybe it's a horrible idea.

Apple are in the position of having full control over their platform and thus they're able to seamlessly work out separation of base system and applications with regards to the various quirks (API/ABI stability, symbol versioning, etc.) that are inherent in contemporary dynamic linking.

Some distributions have tried a similar approach. PC-BSD has the PBI format. Slax uses compressed file system images for packages. There's solutions like 0install (and tons of predecessors) that have tried to do it. None have really caught on.

This is also the Android and Windows approach (Phone, Store and upcoming 10[0]).

[0] From the GDC presentations about Windows 10 features.

Reply on news.ycombinator.com