Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing the “rhel-tools” for RHEL Atomic Host

developerblog.redhat.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Introducing the “rhel-tools” for RHEL Atomic Host

#11

Post by dijit »

ape4 wrote: post #2

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.

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.

Re: Introducing the “rhel-tools” for RHEL Atomic Host

#12

Post by krakensden »

microtonal wrote: post #7
ape4 wrote: post #2

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.

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.

Re: Introducing the “rhel-tools” for RHEL Atomic Host

#13

Post by drinchev »

zorked wrote: post #3
ape4 wrote: post #2

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?

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

Re: Introducing the “rhel-tools” for RHEL Atomic Host

#14

Post by vezzy-fnord »

dijit wrote: post #11
ape4 wrote: post #2

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.

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.

Re: Introducing the “rhel-tools” for RHEL Atomic Host

#15

Post by vezzy-fnord »

krakensden wrote: post #12
microtonal wrote: post #7

Earlier quoted context omitted.

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.

Re: Introducing the “rhel-tools” for RHEL Atomic Host

#16

Post by pjmlp »

zorked wrote: post #3
ape4 wrote: post #2

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?

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

Re: Introducing the “rhel-tools” for RHEL Atomic Host

#17

Post by pjmlp »

vezzy-fnord wrote: post #14
dijit wrote: post #11

Earlier quoted context omitted.

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. T…

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

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

Re: Introducing the “rhel-tools” for RHEL Atomic Host

#18

Post by sciurus »

zantana wrote: post #10
ape4 wrote: post #2

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 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

Post reply on HN