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.
Show HN: Bocker – Docker implemented in 100 lines of bash
51–60 of 89 posts
Re: Show HN: Bocker – Docker implemented in 100 lines of bash
#52not 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
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
#53I 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.
Re: Show HN: Bocker – Docker implemented in 100 lines of bash
#54Wow, 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?
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
#55I 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.
Re: Show HN: Bocker – Docker implemented in 100 lines of bash
#56Re: Show HN: Bocker – Docker implemented in 100 lines of bash
#57Earlier 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.
"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
#58Earlier 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…
Re: Show HN: Bocker – Docker implemented in 100 lines of bash
#59You 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.
Re: Show HN: Bocker – Docker implemented in 100 lines of bash
#60You 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.
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...