Live data from Hacker News

Show HN: Bocker – Docker implemented in 100 lines of bash

github.com

71–80 of 89 posts

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#72
post #66
post #35

Earlier quoted context omitted.

A lot of the cgroups and namespaces functionality too time to mature and stabilize. User name spaces for instance was only available with 3.8. Cgroups and namespaces still don't play well with each other. Cgroups was initially added by some folks from Google in 2007. A lot of the early work on Linux containers was done by Daniel Lezcano and Serge Hallyn of the LXC project, supported by IBM. It was initially a kernel…

Systemd-nspawn is way easier to use than LXC imo in that it replicates the simplicity of chroot with the power of cgroups. The security story is unfinished though.

What do you mean that "The security story is unfinished though."?

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#73

Here's a proof-of-concept implementation of "docker pull" in bash (YMMV, I think it has broken since I wrote it): https://gist.github.com/tlrobinson/c85dca269f4405ad4201

There are some images still in registry v1, I recon a problem like that where it gives you another URL

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#75
post #54

Earlier quoted context omitted.

@Shykes, is that your alter-ego account?

No, that's a dumb joke. Actually I don't really even use Docker personally. HN's standard middlebrow dismissal of Docker is to claim that it's nothing except LXC, which really misses the point entirely. But at least it lets people pretend they are smarter, which is what really counts.

The problem is that the buzz will often entirely miss the point also. If the reader understands the underlying CS concept it is better to focus on the benefits of the product as a particular implementation of a concept, rather than attribute all the benefits to the actual product itself.

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#77
post #60

You published it? You should have gotten a "micro-docker"-like hashtag trend going and then pitch your idea to VCs. The main "Lighter than Docker" startup would be valued at around 5-7 billion right now.

Just a quick interjection: Something that one smart developer can do in 100 lines on any interpretter is never worth billions of dollars. Someone who can do it, on the other hand, is certainly worth hundreds of thousands of dollars, annually. Meanwhile, so many people continue to marvel at what can be done with an interpretter and a turing-complete language. Yet, the last thing we need is yet another turing complete…

"Something that one smart developer can do in 100 lines on any interpretter is never worth billions of dollars."

100 lines maybe not, but docker is pretty lightweight glue riding on existing technology that did most of the heavy lifting. The valuation IS lopsided because it sort of did a "name grab" around the underpinning technology (sort of like "AJAX" was "XMLHttpRequest") and packaged it in a way that made it a more useful (some) and more importantly, talked about in a way people could understand, mostly giving it a name and describing some common practices was what happened.

The original idea was definitely clever though, and it is getting people who didn't adopt immutable systems before to start to understand immutable systems, even if the future is not actually going to be Docker. Yet, Docker is getting the press versus the higher level software that needs to exist to drive Docker.

While this makes it very hard for other projects to get VC attention, I think that's maybe a good thing for them if they don't know it - you want to bootstrap if you can anyway, and I hope many of them do.

While this isn't a super robust implementation or anything, I think it's important to show that Docker is more or less glue around existing concepts, and that there's still room to make better things.

Don't get me wrong, immutable systems are GREAT. Docker deserves points for getting people to understand them, and the ideas of private registries and Dockerfiles (though also not original) are good parts. Microservices? Not really neccessary for most people, that's more of a human problem. It sort of conflates immutable with microservices and makes you hop out of the norm to do the basics, but ok, sure, that's somewhat like a celebrity actor advocating for environmental causes. Still a good thing.

But is it a giant leap forward? Not as much as people think, compared to AMI builds, and you see folks running Docker on top of EC2 in cases (yes, they boot faster - but AMIs gave you immutable and things like Packer allowed redistributable images; stacking images is kind of sketchy if you don't control them all). But it's enough to make people use them, and that's a win, and someday the management software for it may be smart enough to make it feel as easy and powerful as that (fingers crossed for ECS?).

The 100 liner at least has the advantage of reminding people when people say "Docker is great" they mostly mean "I like this immutable systems thing and describing systems in text", and the other properties of Docker, and reminds people that if they can do better and try to make a better thing, they should also still try.

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#79
post #78

As an entry level developer - how does someone go about re-writing "x" in 100 lines of "x"? Is there a certain process that goes into developing something like this, and why is this a popular thing to do? (writing an existing software in lesser lines)

1) Knowledge of the space is good, but can be learned while implementing. You'll need to know the language pretty well, in order to keep the line count down.

2) It's fun

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#80
post #66
post #35

Earlier quoted context omitted.

A lot of the cgroups and namespaces functionality too time to mature and stabilize. User name spaces for instance was only available with 3.8. Cgroups and namespaces still don't play well with each other. Cgroups was initially added by some folks from Google in 2007. A lot of the early work on Linux containers was done by Daniel Lezcano and Serge Hallyn of the LXC project, supported by IBM. It was initially a kernel…

Systemd-nspawn is way easier to use than LXC imo in that it replicates the simplicity of chroot with the power of cgroups. The security story is unfinished though.

Not really, Nspawn is extremely promising and is developing fast. Systemd 220 adds support for user namespaces so you can run nspawn containers as non root users.

But containers need minimal OS templates, networking and a way to configure it properly, storage support for things like cloning and snapshots, a way to configure cgroups, and management and those are still not available beyond some basic machinectl commands, and neither is the documentation. Nspawn is going to be a very strong solution, especially given Systemd is now there by default on most mainstream distros, but its not there yet.

User namespaces while letting non root users run containers brings with it a whole bunch of problems on accessing host resources like mounting file systems, networking devices etc that LXC has faced and addressed.

I have an article up on using nspawn containers here [1]. There are a lot of wild misconceptions floating around about LXC. It is actually pretty mature and easy to use, has supported user namespaces since 2013, has advanced networking and storage support for things like cloning and snapshots with btrfs, zfs, overlayfs, LVM thin, aufs, a nice set of tools to manage containers, and a wide choice of minimal container OS templates.

We have a lightweight boot2lxc VM image based on Alpine Linux for those who want to give it a go [2]

[1] https://www.flockport.com/a-quick-look-at-systemd-nspawn-con...

[2] https://www.flockport.com/start/

Post reply on HN