Live data from Hacker News

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

github.com

51–60 of 89 posts

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

#51

I thought puppet/chef were the pit of the devops ridicule. Then I not only saw this, but also positive reactions to a readable code in which you have : echo 'nameserver 8.8.8.8' > "$btrfs_path/$uuid"/etc/resolv.conf This is wrong on so many level that I don't know where to begin with.

i dont think this part is needed at all, it just means the base image sux basically, so this is some patching up, which, well, is fine for demo purposes

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

#52

not sure if you ever saw this - https://www.phoronix.com/scan.php?page=news_item&px=CoreOS-B... it might be interesting to see a version of your script using overlayfs

I've a more or less similar script that uses overlayfs. More less than more... since it uses machined really. But it's easy to to grab commands from there and put in bocker for ex. You just need to replace the btrfs commands by the overlayfs mount, it's almost nothing :)

https://github.com/gdestuynder/mctl/ See also this terrible draft https://www.insecure.ws/linux/systemd_nspawn.html

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

#53

I thought puppet/chef were the pit of the devops ridicule. Then I not only saw this, but also positive reactions to a readable code in which you have : echo 'nameserver 8.8.8.8' > "$btrfs_path/$uuid"/etc/resolv.conf This is wrong on so many level that I don't know where to begin with.

Sadly that is pretty much emulating how docker does it. To the best of my knowledge the '8.8.8.8' and '8.8.4.4' name-servers are kind of hard-coded in a lot of containers (all?)

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

#54
post #37

Wow, Docker in 100 lines! It runs as root? Oh. It is written in bash? Oh. It needs a ton of manual setup? Oh. It doesn't actually implement the package format which is most of the point of Docker? Oh. So is it that easy to reimplement Docker? Despite the obvious snarky intent, it appears not.

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

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

#55

I thought puppet/chef were the pit of the devops ridicule. Then I not only saw this, but also positive reactions to a readable code in which you have : echo 'nameserver 8.8.8.8' > "$btrfs_path/$uuid"/etc/resolv.conf This is wrong on so many level that I don't know where to begin with.

Can you share why you think puppet/chef are the "pit of the devops ridicule"?

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

#57
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.

They are rightfully dismissive of Docker because it's just the current cycle of trendy abstractions. It's a barely passable solution to a bigger problem.

"We're running many services on a single machine. But this is complicated and difficult to update and maintain."

"We took our machine, ran a virtualization platform on it, and split each service into its own VM. But this comes at the cost of increased resource usage."

"Instead of separate VMs we created a container format to decrease the overhead while retaining many of the benefits of virtualization. But this is still resource heavy, and insecure as the containers will rarely see updates."

"So we created 'lightweight' containers which are very thin wrapper around the base OS so that containers can take advantage of updated shared libraries to mitigate the security problems, and further decrease the overhead."

"We're running many services on a single machine..."

The cycle will eventually come around and we'll be in a better place having learned that was was really needed was improvements to the base OS, package management, more robust MAC policy, and name-spacing rather than containers.

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

#58

Earlier quoted context omitted.

Omnibus is a step backwards. Every monolithic Omnibus package has its own copy of each dependency, so you end up with duplicated binaries. You can no longer patch a library system-wide, you have to figure out which Omnibus packages have the library and rebuild it with the patched version. Package management was invented to deduplicate files across the system, and people seem to have given up on that. You say that Doc…

It turns out that the kernel is smart enough to deduplicate (in memory) the same version of a shared library across VM boundaries, so I don't really see why we need to make packaging handle this, especially if this can be applied to containers (if it isn't already). Duplicates of the same file on disk is not a big deal, and can be solved by a good file system which handles deduplication. I don't see why we necessaril…

This means your security depends on the app maintainer, which is a terrible place to be in. I don't want to have to wait for the latest image of 100 apps and hope they didn't break anything else just to deal with an openssl vulnerability.

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

#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 language.

Unfortunately, the problem with turing machines, virtual or otherwise, is that they're so good at faihfully reduplicating themselves...

Post reply on HN