Hacker News Reader

Comment by dancek | Hacker News Reader

I agree that containers (both for shipping and servers) are a great idea. And because I'm tired of always configuring servers, I decided to give it a try some time ago.

I wrapped my IRC client (weechat + glowing-bear) in a Docker container. Oh, not a container though, because I also needed https, which meant I needed either a mechanism to build and update letsencrypt certs in the weird format that weechat expects, or to run an nginx instance in the front (and also somehow get the certs, but that's easier with nginx). So two containers.

And even though there was a ready-made nginx+letsencrypt https reverse proxy container (actually several), I had a huge amount of headaches to get it actually working. Even with the system set up, I occasionally have the container crash with exit status 137 (IIRC), which I've assumed might be because weechat leaks/consumes memory and eventually the host server kernel kills the process. Maybe.

So in my limited experience, comparing Docker containers to shipping containers is a gross simplification. Shipping containers are simple constructions requiring well-defined simple maintenance, while Docker containers seem to be complex thingamabobs that have multiple points of failure.

View on HN

Docker is a poorly engineered and over-hyped technology.

The concept is great - and in fact, many companies have built great tooling around Linux cgroups. It lets you efficiently binpack applications on a single server - which is why 'containers' were created in the first place.

The side benefit of letting you define your OS libraries, and other things, is a nice bonus, and way overblown in my opinion.

Docker and its tooling is just plain bad. It's so bloody unstable, unless you pick some esoteric combination of versions and storage backends (old docker + old aufs + old ubuntu seems to do the trick) - and even then, you'll run into problems. Documentation won't help you here - it's trial and error.

The docker group seems focused on feature, feature, feature, while the basic stability and performance remains poor. It's quite amazing how they get it so wrong. Browse through the github issues for performance and hanging issues. The surrounding tooling is poor as well - registry v2 doesn't even support deletes (because they need to maintain compatibility with the 100000 different storage backends for it). There is no LTS release, bug fixes only happen in latest version, so you're in a constant state of brokenness. And so on.

The concept is great but it's also not original. It's called "processes". Docker is little more than a mass of complication laid atop fork+exec.

That's why nobody can get it right - because we already did.

I totally agree. The real issue is dynamic libraries and how hard it is to compile C/C++ code statically with GCC.

If you could just pass `-static` to gcc and it actually worked like you expect this would never have happened.

Fortunately that seems to be changing somewhat. Go is totally static, and Rust can easily be made totally static using muscl. You can even do totally static C/C++ apps fairly easily with muscl.

Dynamic libraries (in the C/C++ sense) only scratch the surface. Containers give you your own file system namespace (among other namespaces), which means all of the files that make up your complicated application unit can be put together and work together in isolation, separate from the machine's main file system.

Isn't that chroot jails?

Yes, quite literally, in fact: https://github.com/opencontainers/runc/blob/ee992e5ff7143ea3...

What advantages do file system namespaces have over separating by directories and users?

A big one is managing software which you didn't write: if you have two things which expect to be able to write to /etc/mydaemon.conf etc. you either need to burn a VM for each one, fork the startup scripts or take the Debian-style approach of maintaining patches which make everything configurable, or manage something like maintaining chroots directory hierarchies.

(repeat for network namespacing: it's really nice not to need to play games to have your CI server start 3 running jobs which all think they're listening on port 80)

None of that is impossible – in the case of chroot there's many years of precedent - but if you do it regularly, there's a strong appeal to automating a common pattern.

This is especially true when your goal is supporting development teams: with something like Docker, normal users don't need root just to start a daemon on a privileged port or write to a couple of files. If you work in a large or security-conscious environment, that's a fairly big draw.

(Not saying that Docker is perfect or necessarily the long-term winner in this space, only that there's a usability gap which a lot of people fall into).

> This is especially true when your goal is supporting development teams: with something like Docker, normal users don't need root just to start a daemon on a privileged port or write to a couple of files. If you work in a large or security-conscious environment, that's a fairly big draw.

On the contrary, any user that can run arbitrary containers (such as rootplease[0], for example) has root-level privileges on the host system.

[0] https://hub.docker.com/r/chrisfosterelli/rootplease/

What I was thinking about wasn't protecting against outright malice but rather mistakes and errors: If you give developers sudo access and you don't have an extremely diligent team with strong system administration experience, you're going to run into problems where people made incompletely documented changes or cause problems while working which aren't caught early enough – ever see someone break out sudo or chmod 777 as their first debugging step or even write that into the install process because it was too much work to do it right? Docker is an enormous win here both because it sharply reduces the number of times someone needs privilege escalation and because it ensures that the end result of their work can be reliably audited and repeatedly deployed.

It's true that Docker doesn't protect against compromised or malicious users with privileged access. That's a very hard problem in general which can only partially be addressed at this level — especially since many of the most damaging attacks don't need it (“The bad news: they exfiltrated our customer database. Good news: they didn't get root on the EC2 instance”). I think most of the answers for this problem are going to continue to rely on existing practices like code review, auditing, getting finely-grained SELinux / seccomp rules into the development mainstream, etc.

> If you give developers sudo access

Why would you, though? A developer would at the very most require the application's privileges, not the super user's. And that's only really necessary when doing live troubleshooting.

You have to if your developers are installing packages, working on deployment, running anything which runs on a privileged port, use tools like systemtap, etc. In some cases that can be avoided with configuration but then you're asking for bugs due to discrepancies between the environments.

You can reduce the number of things which hit that friction in a number of ways: having easily repeatable builds so a developer can test on their own VM; using a cloud service so test VMs are disposable and never shared; setting up a platform / microservices approach so a wider range of things either don't need to be touched or can be deployed without privileged or direct access, etc.

Containers (really namespaces) one way to hit that last goal: as a classic example, if you have a web app running on port 80 everyone who deploys will need to periodically restart Apache/nginx/Varnish/etc. and that may include elevated access to debug processes running as a different user. This is by far the simplest problem in this class and there are various ways (proxies, site users, firewall NAT rules, moving config into .htacccess or its equivalent, etc.) to reduce the number of times you have to care about it but but it still requires work to maintain and adapt code (especially with third-party apps).

Some people quite reasonably prefer to solve this entire class of problems by tossing everything into a container so it can run as if it's the only thing on the box.

Basically if you're a shit sysadmin, you don't have to bother learning anything or working hard.

This is absolutely fine if you intend to remain a shit sysadmin. Go nuts with Docker. The 21st century will be waiting for you when you're done.

So will 19 fucking 60 because nothing's fucking changed.

How is "your own network, your own view of the file system, your own view of the process table, your own view of the user IDs, ..." the same as "processes"?

On modern Linux distros every process is running in a cgroup and namespace by default. So these days the main difference between a "container" and a regular process is that regular processes are all jumbled together in the same root namespace, and containers are in separate namespaces.

Which Linux distributions do this? I'd like to read how "most" instances of fork and exec end up with unique networks and file system namespaces.

I didn't say unique, I said "jumbled together".

Now as far as which distros put processes in a namespace and cgroup by default, I know at least CentOS 7 and Ubuntu 15 do this. And those two distros on their own would qualify for "most".

To check if your distro does it, one way of checking is just doing a `cat /proc/1/cgroup`. This will show you what cgroups process 1 is in. By default you will be in the "root" cgroup.

To check your namespaces, `ls -l /proc/1/ns/`. You'll see the process is in some randomly generated namespace ID per item.

I'm sure you could recompile your kernel to disable this behavior, but the default reality of modern Linux is that everything is already running in a "container".

Now the question is whether or not people want to take advantage of that reality, and separate out processes in isolation, or keep running everything on a system in such a way that any single process can impact the whole system.

Plan 9 is knocking on the door and would like to have a word …

The context of this discussion would like to have a word too...

I think that Plan 9's filesystem-based namespacing (and lack of a superuser) actually have a lot to offer for container-like solutions. Any Plan 9 user can set up namespacing of the network and of resources and spawn a process within that restricted namespace.

The whole process is much simpler, I think, than that of creating a Linux container (that's the whole reason Docker exists: to simplify & abstract something which isn't really inherently complex, but is accidentally complex).

Plan 9 certainly wasn't perfect, but it had some really high-quality ideas we still haven't assimilated in mainstream platforms.

I'm not disputing any of this. But it really has nothing to do with the context of this thread...

Wouldn't it be more akin to jails?

I think the real problem with Docker is Docker Inc. The pressures and constraints the company is under promotes the creation of new features that can be marketed and new software that competes with products from the competition.

They have effectively no incentive on getting rid of bugs in the core product or to test features they do add exhaustively.

Sooner or later someone actually using containers will produce a docker replacement that will take over unless Docker focusses on what actually matters.

Docker Inc. desperately wants to be VMware. I don't think it's a coincidence that the official documentation is so full of virtualization-like choice of words you'd be forgiven if you thought they already were.

They do however seem to be cutting so many corners technically, that the risk is they get undercut on their core offering.

Deletion from registry v2 is definitely supported now. It's just a total PITA, and took them a while to implement. But I got my disc space back, so I'm not complaining. :P

Any pointers?

This answer on SO is more or less the approach I used:

http://stackoverflow.com/a/37716286/308278

We used Docker sort of early on, and got out of it around v1.6. Many problems that you had to work around yourself, but the one you just reminded me of was the repos: There was Dockerhub, a third-party place without 100%(-ish) uptime, and two serve-your-own, one of which was a black box you could never delete from, and the other had stamped "NOT FOR PRODUCTION USE" in big letters on its github page.

I remember one of the engineers giving a talk, saying that the problem they had was growing too big too quickly - they didn't have time to properly work out the base architecture in the early days.

Ok, throw Docker away.

Did anybody have better experience with e.g. Rkt?

I really like: daemontools + static binary + setuidgid and maybe chroot.

Or mesos where everything needs to be in a tarball, which is extracted and sole program run.

If stuff is statically linked and related files (config, assets, ...) are part of bundle that can be chrooted, what is the value add of a container?

Containers are easier for folks with less operational experience to understand. Or maybe easier to get started with is a better way to put it. It's easy to underestimate easy to use tooling when you aren't the target demographic.

It's not hard to use control groups in daemontools family style, either.

* http://jdebp.eu./Softwares/nosh/guide/move-to-control-group....

You might have better luck with container specific reverse-proxy like Traefik[0] - it has builtin Let's Encrypt support with auto-renewal

> I had a huge amount of headaches to get it actually working.

Moving from running one container to running multiple containers is probably one of the most confusing parts of getting started with Docker

There are a large array of orchestration options and tools - each with their own pros and cons: Swarm, Kubernetes, Mesos, Marathon, Mesosphere, Centurion, Rancher, etc.

Docker 1.12 now having built-in orchestration with Swarm should make this easier[1].

[0] https://github.com/containous/traefik

[1] https://blog.docker.com/2016/06/docker-1-12-built-in-orchest...

Traefik sounds great! I'm using https://github.com/SteveLTN/https-portal which is a Docker container, and that kind of setup is just complicated. Putting the reverse proxy outside sounds much cleaner.

Containers!=docker, I think if you used lxd container, your experience might have been different as they work like virtual machine. I am using lxd in production and it has been a pleasure with live migration, snapshots and good old configuration management using ansible.

And, as probably everyone knows, Google runs everything in containers and has been using containers for a decade:

http://www.nextplatform.com/2016/03/22/decade-container-cont...

Docker may be flawed, but containers aren't. If you need some enterprise leader to tell you this instead, here are some Gartner posts showing this is the way:

VMs may be well established and "magic quadrant", but they are also on decline, and containers make better use of hardware/resources:

http://www.informationweek.com/cloud/infrastructure-as-a-ser...

It's important what you use to roll out containers and requires forethought:

https://www.gartner.com/doc/3267118/containers-change-data-c...

What really surprises me about Google is why they don't open source some of these great core technologies (MapReduce, Containers etc.) instead of publishing theory as academic papers. On the one hand, it may be a great way of promoting the creating of these tools from the ground up, inspired by the theory alone. On the other hand, Google's invaluable experience with using these technologies probably means their versions are more stable, faster, resilient etc.

Kubernetes:

http://kubernetes.io/

Google Container Engine:

https://cloud.google.com/container-engine/

Open-source MapReduce implementation:

https://gigaom.com/2015/02/18/google-open-sources-a-mapreduc...

https://github.com/google/mr4c

Kubernetes just got a pretty sweet update as well. The improvements to the dashboard alone were worth revisiting.

Dataflow [aka Flume]:

https://github.com/GoogleCloudPlatform/DataflowJavaSDK

http://research.google.com/pubs/pub35650.html

It's entirely possible that they consider those core technologies part of their "magic sauce". If their development and production environments are so far ahead of everyone, their development cycle will be much faster.

Why enable their competitors to such an extent? What benefit is in it for them, when they seem to be at the absolutely forefront of this work? They have to let their researchers publish academic papers or they won't get the best researchers, but when they also have the most experience with ops and such a lead in implementation, the theory only gets competitors so far.

I think they've said in talks/presentations that the challenge they have with some stuff (like Borg) is that they can't really extract individual components. It's all too tightly coupled. It wouldn't be fair to ask them to open source their whole stack. The fact that they took the lessons learned and created Kubernetes or published papers on their technologies is more than enough.

There's also rkt!

I'll also add a plug for tredly.com here. "Containers done right" and pretty much all of Joyents container work.

Still, I'm not sure why I should use containers VS Vagrant + ansible (or just ansible)

Docker is just overhyped deal with it. There are some nice ideas, but nothing that we couldn't or haven't seen before. FreeBSD Jails and Solaris Zones exist for more than ten years. Where they addressed many things that Docker didn't.

Can you download a BSD Jail image from an application's website, and have it 'just work'?

No, but I do not see how it is related to my comment. Read more carefully. I didn't say that Jails and Zones did everything that Docker did, yeah DockerHub is cool and I gave them credits for that.

Federation credits?

"nothing that we couldn't or haven't seen before"

Yeah, surface simplicity seems to be the heart of what drives tech fads, even if the actual cost in labor and effort is exponentially larger on the back end.

MongoDB? Yes, don't worry about data design or normalization! Just throw that stuff in there, call it anything you want! Finally programmers are free from the tyranny of decent databases. I can't think of any downsides to that arrangement.

Docker? Yeah man, you can just say "docker pull redis" and then you don't even have to bother with Ubuntu getting in your grill with all of its apt-get shenanigans. It's awesome! Now how do we make that port accessible...

I work for a Fortune 50. I can't just download anything. When some third party curates a store of containers and guarantees their safety then maybe. Until then docker, rkt and the rest are a distant dream.

Don't know about BSD Jails, but you certainly could download OpenVZ images and run them.

it's called curlbashism.

If anyone would provide those, then sure, why not? I could just give you my jails with database, web server, irc client and everything else as compressed archives, you could just unpack them, execute jail commands on them and have them running. This is pretty much that's there to is. No different than Docker, and yet, many more years used in production environments.

I ran into weird problems with FreeBSD Jails. Like cronjobs running twice, and `ezjail-admin console` not allocating a tty.

Docker gives you the building blocks, but that means you have more pieces to arrange and manage. Take a look at Docker Compose if you haven't already, since the Docker CLI only gets you so far when you're creating apps that consist of multiple containers.

I think the best approach for your cert issue is to abstract that into a separate service (nginx is an option, but I'd recommend the Rancher approach below). Yes, that means you have to add another container, but that's just another block in your docker-compose.yml file. Embrace the approach of separating your components into containers and organizing them as a stack. You can easily link containers together, share data volumes, and start/stop individual containers or the stack as a whole.

The problems that you're having are pretty easy to fix with some tooling. Rancher (http://rancher.com/) greatly simplifies the cert issue by allowing you to import certs and provide them to the Rancher loadbalancer service (which you can add to any stack). There's also a LetsEncrypt community catalog template that automatically retrieves and imports certificates to Rancher. There are other open source orchestrators like DCOS, but Rancher is probably the simplest to use, and it's the only one I'm very familiar with. There are SaaS options that you can look into, but I don't have experience with them.

As for the container crashes, it's trivial to automatically restart them. Just pass the --restart=always flag to the Docker run command. You can also add the flag to a docker-compose.yml file.

> but that means you have more pieces to arrange and manage

wait. aren't these things supposed to give us less pieces to arrange and manage?

> The problems that you're having are pretty easy to fix with some tooling

yes, of course the solution is more tools. what exactly was the problem again?

> wait. aren't these things supposed to give us less pieces to arrange and manage? No, not fewer pieces. You'll have more pieces, but you can combine the pieces and control them individually or as a group. You can think of Legos, since you have many pieces but they all fit together in the same way.

Docker compose lets you group these containers together, and that is what ultimately makes it feel like you have fewer pieces to manage. With that, you can start/stop a stack of containers (e.g. django, nginx, postgres, redis) with a single command, but still inspect and manage each component separately. This is something you might normally do with bash scripts, but with Docker you can take that same app to an orchestration platform and run it on any host. Run it on your laptop, run it on a linux server, run it on a SaaS provider like Docker Cloud, run it on a private cloud with an orchestration platform.

> yes, of course the solution is more tools. what exactly was the problem again? Docker is just the foundation. Nothing more. I'm fine with learning more tools because I feel that the foundation is solid. The problem is being able to ship and manage your apps. That is much, much easier for me now and I'm very glad I invested the time.

Its somewhat akin to microservices, where you split each functionality into its own service rather than having one monolith do everything.

Thanks, I'll have to look into Rancher. I'm already using Docker-compose.

Also good to know about automatic restarts. I don't know how I missed that, I had to read a lot of docs to get where I am.

Still, the amount of tooling that exists and the knowledge needed to pick the right ones for a given situation goes to show that this isn't as simple as packing a shipping container and letting someone ship it...

You're right, it's not quite that easy yet, but it probably will be eventually. Docker just provides the building blocks. SaaS providers like Docker Cloud will get better and continue to abstract complexity away until it really is that easy.

You don't need to use Rancher if you're just running one app. If that's all you need to do, then it could be as simple as running docker-compose on a linux server and mounting the certs into the nginx container as a host volume (https://github.com/jwilder/nginx-proxy). This is a fine approach until you want to split your containers across several hosts (redundancy or scaling) and you have several apps to worry about.

Hey chewchew you seem to be knowledgeable on docker-compose.

What's the easiest way to get a .yml on a cloud server somewhere and let it assemble it assemble the containers for you?

Also, do you know where containers set environment variables? The official Postgres makes available something like PG_PORT_3542 and u can just refer to it from another container. Where I can't seem to do the same with the Redis one...

kubernetes allows you to upload a yaml snippet and launch, which sounds like what you described.

The absolute easiest is probably Docker Cloud. I've checked it out but haven't really used it much. It's still relatively immature but if you just want to deploy and forget something simple, this is probably the way to go.

If you want to use your own Linux host, then the simplest way would probably just be to SSH into the box, git pull, and run "docker-compose build && docker-compose up".

Setting environment variables is pretty easy, but I don't think you need them in this case. If you're trying to make a redis or postgres container available to another container (your app), then you can do so easily with links in docker-compose. Something like:

    myapp:
        image: myimage:0.0.1
        command: cmd to run
        links:
        - redis:redis
        ports:
        - 80:8000
        environment:
        - hardcoded_var=my_env_value
        - var_from_host=${host_var}
    redis:
        image: redis:latest

You can then access redis from the myapp service using the hostname "redis" and the default port "6379". So, "telnet redis 6379" would work from the myapp container (assuming telnet is actually installed). The redis port isn't even publicly exposed- it's only available to myapp.

If you need to define environment variables, you can do so with an environment dict as shown above. There are a few other ways to define env vars:

https://docs.docker.com/compose/compose-file/#variable-subst...

https://docs.docker.com/compose/environment-variables/#/the-...

Thanks chewchew so much win in this reply. I use Heroku a lot and was wondering if there is a "believable" alternative using Docker.

Seriously? If something crashes continuously in production then the solution is "just pass the --restart=always flag. I really wonder if you guys are really using docker in prod. I would never use something like that to manage important transactions.

No the correct solution is to debug the issue not just reboot/restart/reinit the damn thing.

This mentality is WHY Linux/docker/containers/Linux worlds NIH syndrome, is such a tire fire.

It's not one or the other. Restarting might save you some downtime if you're running a single IRC container. That doesn't mean you shouldn't find and resolve the root issue. Normally I just rollback to the previous version container if I have a recurring issue.

Windows containers are now available, if you can't stand linux: https://msdn.microsoft.com/en-us/virtualization/windowsconta...

Anyway, don't use containers if you don't want to. I'm glad I invested the time since I understand them very well and use them to my advantage. But I did have to learn a lot and experiment with a bunch of tools, and maybe that's not worth it to you.

Isn't this the much-lauded and respected Erlang approach to failures?

I never used Erlang, so I have no idea if it follows the same approach(although I find it quite strange). But for sure I can't afford to deploy anything like that in prod. You lose one transaction in the middle and several millions go lost. I'd rather lose an hand than try to explain my clients that it is fine, docker just restarted by itself as expected..

As someone said, this is the normal behavior in the Erlang/Elixir world, and it seems to have worked extremely well for the telecom industry.

That said, my reply was to someone running an IRC server, presumably on a single server, so don't stretch my advice to a production app handling millions of transactions. Obviously the core issue is that the app crashes, and it's still up to him to fix that. This is almost certainly a problem with his app/config, not Docker itself (though it ain't perfect). If it's something that happens every 6 months, then auto restarting will probably save him a lot of problems. If your transactions are so precious, don't pass the flag- it's up to you.

I wanted to write about my experience with containers. It mimics yours. The idea of a container is beautiful and elegant. The execution, not so much. I'm more or less convinced that to reduce this complexity, we need a limited scope ecosystem. Microsofts .Net would probably be a good place to start, but MS, being enterprise, have a habit of turning things into a mess of configuration.

I think the container example is actually more apt than you think.

Running out of memory is a bit like running out of space in the container.

If I dropship a container on your yard, you're going to have a container but your options in what to do with it are limited.

Now if your container has a lifecycle and a scheduler because it needs to be in China on Wednesday, you suddenly have a lot more complexity.

Docker itself being a buggy piece of crap is neither here now there in the grand scheme of things.

Someone told me that I should switch to using shipping containers instead of my current method.

Unfortunately, when my cattle arrived in the US, they were all dead. I was told containers "would just work".

After some experimentation, we managed to get our cattle in a container by building a system that correctly managed food and waste. Then we found a partner who had successfully packaged sheep and so we just used that. Unfortunately, they appeared to have a leak in their waste management system, and the container overflowed and all the sheep died. We did not have this problem when the sheep were able to fill the entire hold with their output.

Clearly the idea that shipping containers just work is a gross oversimplification. In fact containers seem to be complex thingamabobs with multiple points of failure.

Same here with docker. The ideas are nice as an application, but it's just a pain in the ass. LXC on the other hand is a breeze.

Does LXC provide a way to automatically create new working instances (like a Dockerfile / docker-compose.yml)? I'm not quite grokking LXC in my first 10 minutes of reading...

I think you could create your own lxc template and then create new instances. The other way would be to just clone existing working instances with overlayfs.

Base lxc may be a bit of a pain. Look at lxd - I believe that makes things much much simpler.

Another thing about lxc is the unpriviledged container - which I think is great for security (not sure if docker provides this).

man lxc.conf ... this is your dockerfile equivalent.

LXC is nice, as a building block, but it is far from "a breeze".

It is refreshing, however, being able to write, in a couple of hours, a setup script from scratch that debootstraps an install, chroots in there to configure it and launches the container via systemd-nspawn. Very few moving parts, excellent for development environments. Not yet something I trust in production, though.

As others say Docker is probably over-hyped technology.

However, I do see it as positive, because its hype, regardless if good or not, has created the traction for Go and OCaml on the data center, thus eventually leading to less C code for such use cases.

So hype or not, maybe we do get some security improvements on the overall stack.

Out of curiosity, why is less C code a good thing?

Maintenance. A lot of the younger programmers have very little experience with running/working with C code and stack; they are a lot more comfortable with Java/Python/Go (for backend). So the less C code you have to deal with in your stack, the easier it is for deployment/debugging. Not to mention, the more modern languages also provide many features that allow pinpointing errors faster etc.

Security exploits caused by memory corruption, undefined behavior, ability to inject code, numeric overflows plus whatever is common to all memory safe languages.

https://www.cvedetails.com/vulnerabilities-by-types.php

There are legitimate reasons to not want to use C, but I find around here it's mainly reflexive hate and language zealotry.

It's popular to hate on C (and C++) because the languages are so ubiquitous and long-used that a large body of terrible, unsecure, and poorly written code exists using them. Other languages haven't had the same success as these two yet, so haven't had their warts exposed enough to be dumped in the "automatically hated" category. Java comes close, but it also is typically lumped in the "automatically hate it" bucket and for similar reasons.

It was already clear in the late 70's and early 90's that C wasn't a reliable option to write safe systems.

Dennis M. Ritchie himself on the history of the language[0]

"To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions."

Lint which is still mostly ignored by the masses to this day. At CppCon 2015, about 1% of the audience acknowledge using static analyzers.

Per Brinch Hansen letter to C.A.R. Hoare in 1993a [1]

"The 1980s will probably be remembered as the decade in which programmers took a gigantic step backwards by switching from secure Pascal-like languages to insecure C-like languages. I have no rational explanation for this trend. But it seems to me that if computer programmers cannot even agree that security is an essential requirement of any programming language, then we have not yet established a discipline of computing based on commonly accepted principles."

There are many other sources of similar statements since C exists, so the hate isn't something new.

Regarding C++, yes unfortunately it inherits C flaws, but at least the community tends to embrace language features to improve the language safety and push for type based programming.

[0] https://www.bell-labs.com/usr/dmr/www/chist.html

[1] brinch-hansen.net/papers/1999b.pdf

Where is this mythical C++ community that promotes safe and auditable programs?

Whenever I'm forced to use a C++ program it's buggier than the C equivalent.

They are here:

https://isocpp.org/

http://cppcon.org/

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

http://erdani.com/index.php/books/modern-c-design/

https://msdn.microsoft.com/en-us/library/hh279654.aspx

http://stroustrup.com/Tour.html

http://elementsofprogramming.com/book.html

Most of the C++ bugs I found happened to be written by former C developers that disregard using C++ stronger type safety, RAII, the standard library containers and usually use naked pointers alongside malloc() and free().

And that is the biggest problem with C++, its copy-paste compatibility with C, which allowed its adoption by C compiler vendors, but made it as safe as C when developers disregard best practices.

Except for relatively uncomplicated, or relatively low level programs I have had the opposite experience.

Lint is built in to modern C compilers.

I'm missing the initial assumption. What is the connection between Docker and traction for Go and OCaml? People are using the latter in order to simply avoid containers?

Parts of Docker are implemented on them.

So anyone that wants to improve Docker or adapt it to their distribution of choice needs to eventually use them.

For example, Microsoft did several contributions in Go for making Docker run on Windows.

The TCP/IP stack used by Docker on OS X is taken from MirageOS, written in OCaml.

Got it. Thanks.

I'm doing the same with a couple of containers and my experience is pretty much the opposite. What containers are you using, if I may ask?

I'm using jwilder's nginx rproxy container, the let's encrypt helper container for that plus half a dozen Web apps on a VPS. Among those Weechat, two instances of vanilla nginx, rutorrent, dovecot, mattermost, nextcloud and a test environment for my Python tinkering. Works like a charm. Upon bringing up a new container, I supply the desired subdomain and my letsencrypt user data, the container comes up and uses SSL plus automatically renewed certificates.

My Docker experience so far - in a private, limited, very much not production environment - has been "virtualisation light" all the way.

I think of Docker as a somewhat extended chroot, to wrap my mind around it.

They're "complex thingamabobs" because our applications are. Which is exactly why we want to wrap them up and isolate them and expose as narrow interfaces as possible.

Containers are a symptom of our still immature ways of building applications.

The problems you bring up would still be there without containers, but you might not notice them, until you e.g. want to bring your setup over to another machine, for example.

Or want to duplicate it somewhere else. Or want to upgrade something else on you machine that just happens to interact badly with your setup.

Reply on news.ycombinator.com