Live data from Hacker News

Tiny Linux distro that runs the entire OS as Docker containers

github.com

161–170 of 177 posts

Re: Tiny Linux distro that runs the entire OS as Docker containers

#161
post #43
post #20

Earlier quoted context omitted.

I am starting to wonder, why not just execute processes directly with cgroups commands? $ cgcreate -g memory,cpu:groupname/foo $ cgexec -g memory,cpu:groupname/foo bash https://wiki.archlinux.org/index.php/cgroups It's the bare basic that libvirt and Docker et al are based anyway. So if you want to run just one process per "container" it seems rather logical to keep it simple and use cgroups commands directly. (Simil…

systemd already puts each service in a separate cgroup AFAIK, so commands like cgexec aren't even needed. I suspect people are more interested in namespace separation, but recent versions of systemd can also do that [1]. I don't think systemd has image management so that's still a reason to use Docker. [1] https://www.freedesktop.org/software/systemd/man/systemd.exe...

Systemd technically does include rudimentary image management through systemd-importd and machinectl.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#162
post #113

Earlier quoted context omitted.

Put up a sentence or two of informative discussion, or links or any kind, this is not any kind of way to advance the state of a thread. "Go on, try it" doesn't help me in any way. I believe that Docker has more attention, you might call it hype. I'd say "eyes" instead. We have here a way to shown to run everything in Docker, parent link of thread (RancherOS.) That's great, I already went ahead and tried it. I'm still…

Docker also is less invasive. You do not need to build the distro around docker to use docker...

This hasn't always been so, as historically a kernel patched to support aufs was a requirement. It's easier to install docker in 2017 as much of the plumbing shared by the container ecosystem (including nspawn) has become ubiquitous.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#163
post #46
post #17

Earlier quoted context omitted.

Unfortunately, systemd/nspawn does not benefit from the hype Docker garners, despite being infinitely better. This industry is becoming more and more hype and cargo-cult driven, instead of making sane technological choices

Being easier to try, having clear documentation/marketing, and having a bigger community are also forms of "better". If something is so infinitely technically better then winning is "just" a matter of creating on-ramps to ease its adoption.

systemd's documentation is second to none: https://www.freedesktop.org/wiki/Software/systemd/

Re: Tiny Linux distro that runs the entire OS as Docker containers

#164

Earlier quoted context omitted.

I don't think so. Consider that computers are generally so powerful these days that when running a single application stack their seriously under utilized. The first way people went about getting this going was Virtual Machines (made popular by IBM with its VM/370 OS :-) and that works well but when all of your clients are running the exact same OS down to the same version, it is kind of waste to have 'n' copies of t…

What exactly is the problem with process sandboxing and language level VMs? The industry is tackling all the wrong problems. So have we given up on process sandboxing with capabilities? The whole containerization movement is one giant hammer to kill a fly kinda business these days. While you guys are figuring all this out I'm gonna stick with BEAM, JVM, and other tried and true methods. I'll check back in another 5 y…

Well at Google where a lot of development on containers took place the problems with process sandboxing and language level VMs were machine resource allocation, both in memory and in I/O bandwidth. Lets say you have three "systems" on the box, one is a collection of processes providing elements of a file system, one is a collection of processes providing computation, and one is a collection of processes providing chat services. Now you want to allocate half of the disk i/o to the file services, and a half to the compute system, then 75 percent of the network bandwidth to the chat system, 20 percent to the file system, and the remaining plus any "unused" to the compute system. You want half of the memory in the system to go to the compute system and give the rest to the network file system processes.

That is a complex mix of services running on a machine, some sharing the same flavor of VM, and you're allocating fractions of the total available resource capability to different components. If you cannot make hard allocations that are enforced by the kernel you cannot accurately reason about how the system will perform under load, and if one of your missions is to get your total system utilization to be quite high, you have to run things at the edge.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#165

Earlier quoted context omitted.

Sounds like then you should learn what a chroot is. All the existing linux platforms already provide the solution to your exact problem with much less overhead than docker.

Only that chroot wont also run on the development machine, running a totally different OS.

This is a self-inflicted problem. 787 engineers don't have to test their work on a Learjet.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#166
post #138

Earlier quoted context omitted.

You forgot possibility (d) allow multiple library versions to be present simultaneously.

See: Virtualenv (for Python), Snappy, Flatpack The main advantage of docker, as far as my understanding goes, is more of a prebuilt system configuration thing. Need a database? Load the prebuilt PostgreSQL image onto the respective machine. One thing I think should get more use in general is that Dockerfiles are essentially completely reproducible scripts[1]. Too many companies I've seen still use Word documents full…

> The main advantage of docker, as far as my understanding goes, is more of a prebuilt system configuration thing

I think the main advantage is that it standardizes the interface around the application image/container. This allows powerful abstractions to be written once rather than requiring a bespoke implementation for each way that the application is structured. Imagine writing the equivalent of Kubernetes around some hacked-together allows-multiple-versions-of-a-dependency solution. It would be a nightmare. But because the Docker image/container interfaces are codified, you can build powerful logic around those boundaries without needing to understand what's inside those images/containers. Dynamically shifting load, recovering from failures, automatic deployments and scaling are all much easier when you don't have to worry about what language the application is written in or how the application is structured.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#167

Earlier quoted context omitted.

I work in a big company. It's much easier for us to spin up a container to run whatever experimental program we've thought might be useful to help us do our job than to provision a real box for it to run on or fit it into the whole bureaucracy. If it's actually useful we'll find someplace for it to live (or just in containers if that's all that's needed). If not, finding that out was cheap.

So you have an organizational problem and you're hacking one problem with another hack. Clearly nothing can go wrong with this approach.

[deleted]

Re: Tiny Linux distro that runs the entire OS as Docker containers

#168
post #46

Earlier quoted context omitted.

Being easier to try, having clear documentation/marketing, and having a bigger community are also forms of "better". If something is so infinitely technically better then winning is "just" a matter of creating on-ramps to ease its adoption.

systemd's documentation is second to none: https://www.freedesktop.org/wiki/Software/systemd/

Only if one sets the bar quite low, and has very lax standards for doco. Unfortunately, people often do set the bar low in the Linux world. But to those from other worlds the descriptions that come to mind are "acceptable" and "mediocre". As people have pointed out passim over the years, the expected as the norm quality of doco for the worlds of the BSDs and the commercial Unices is noticeably a higher standard than in the Linux world. By those standards, "second to none" is most definitely an exaggeration.

Sadly, "treated as an afterthought" is all too often still applicable, as well; this also being a disease of Linux doco that it hasn't wholly shaken off. The culture of updating the doco in lockstep when the software changes hasn't really taken a firm root, alas.

Just one example of such doco problems is a systemd issue where the doco does not tell the the issue raiser that the entire basis for the issue is wrong. Users have to resort to finding commentary hidden in the source code. Raised as a documentation issue, it requests a documentation change to warn users of something that is not in fact the case at all. Ironically, the true doco issue is actually that it is deficient, and the correct doco change would be to move the commentary into the manual where users can easily see it.

* https://github.com/systemd/systemd/issues/5735

* https://www.freedesktop.org/software/systemd/man/systemd-tim...

* https://github.com/systemd/systemd/blob/5f36e3d30375cf04292b...

* http://jdebp.eu./FGA/systemd-documentation-errata.html

Re: Tiny Linux distro that runs the entire OS as Docker containers

#169

This is starting to smell like a system on top of a system to fix something that could be fixed in the system. Kind-of like implementing a filesystem on top op a filesystem... or putting a database on a filesystem to run another filesystem inside the database, or using a webbrowser as a runtime instead of an operating system.

Have a look at http://genode.org/

Re: Tiny Linux distro that runs the entire OS as Docker containers

#170
post #158

Earlier quoted context omitted.

The reason a new layer is being built is because people don't want vendor lock in and VM's aren't portable anymore. You can't take an AWS VM and fire it up on DigitalOcean without trial by fire. VM's should be portable but they're not because cloud providers don't want them to be. For a while everyone was locked into AWS but now that there's other options some companies want to hedge their bets, or even run parts of…

"You can't take an AWS VM and fire it up on DigitalOcean without trial by fire. VM's should be portable but they're not because cloud providers don't want them to be." You can't ? I have never used DO, but I have deployed linux and FreeBSD systems on EC2 and moving them to bare metal was just a tar command away ... you can even pipeline 'dd' over ssh if you want to be fancy ...

My friend pointed out today that he can't see my comments on HN. I think we're both hellbanned, just letting you know.
Post reply on HN