Goodbye Docker and Thanks for all the Fish - <AUTHOR> https://technodrone.blogspot.com/2019/02/goodbye-docker-and-thanks-for-all-fish.html <comment><USER3> I'm failing to see the argument here. The author suggests that the advent of viable Docker competitors will inevitably bring about Docker's death. Why would that be the case? Competition is great, but it'll be a while before others can match Docker's maturity and ubiquity. Even then, there's no guarantee that any of them will be better than Docker, never mind good enough to warrant switching.

What's wrong with Docker? Why would I want to switch to something else? Are these other solutions really so superior that they warrant the significant time investment that it would take for me to learn how to use them?

The author doesn't actually answer any of these questions. No arguments against Docker are made, nor are any arguments made in favor of competitors.

<comment><USER4> You're missing the point of the author. It's not so much that Docker as a technology is bad; there's nothing wrong with it. The point is that Docker, the company, cannot monetize upon the technology, because the moment they start charging for their containerization technology, people will switch to an alternative container technology, especially now that Kubernetes has won the orchestration "wars" and made it so easy to switch the underlying technology.

Personally, I have to agree with the author and think it's difficult to see a bright future for the company that lives up to its $1.3B valuation.

<comment><USER5> Docker Inc is fine. It would be silly to charge for the actual containerization because that's not really the value of their platform.

Things Docker can/does charge for and could do very well with.

\- Support: Businesses are happy to pay maintenance contracts for fixed LTS versions of Docker which is their EE product.

\- Kube: Docker has pivoted their UCP product into a turnkey on-prem Kubernetes distribution. Plenty of room in that space to grow.

\- Registry; You wouldn't run random images from DockerHub in production, right? Similar to Red Hat's product in this space there's a lot of money to be made in having officially supported images. Images with a pedigree, aduit trail, CVE reporting, yada yada. Partner with Canonical and since it's way easier to do this when you already have distro maintainers and you have a solid RH competitor that devs will like more.

\- Security: Audit your images that have been sitting around and not updated in ages.

\- Hosting: They'll be one of many but there's plenty of space in providing some ergonomics compared to Google/AWS's offerings.

<comment><USER6> Fun fact: if you use Red Hat, you have to use Docker EE. You don't even have the option of getting CE and taking responsibility for Docker support yourself.

<comment><USER7> > if you use Red Hat...

"Red Hat" as in RHEL specifically, or are you meaning any of the family (eg CentOS)?

Asking because I've not hit any problems using Docker CE with CentOS 7. Well, aside from general bugs (etc). But nothing seems to force the use of EE instead of CE.

<comment><USER6> Docker CE is officially supported (well, it's not supported because its CE, but it's packaged, repos, install guide) etc. but only EE is packaged for RHEL. RedHat also has their own docker package like many other distros, so you can still get it free easily, but you have to get it through them and wait on them for updates.

<comment><USER5> If you're using RHEL why wouldn't you default to using Red Hat's build of Docker? I definitely prefer it to the official builds. Red Hat in general seems very annoyed at Docker and carries quite a few QoL patches like being able to add registries to search.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> A shame, really, but not a huge surprise that products like Swarm fell by the wayside. I feel it could've occupied a nice middleground for teams that didn't need the full capabilities (or overhead of supporting) Kubernetes, even though I think K8s is an exceptional project.

I chose Swarm as a pragmatic choice in an enterprise environment that didn't have any prior experience with Docker at all, really, at the operational level. We had to support financial models, often many different versions of the code at the same time, on top of the usual stack of applications to go with that. The choice was a "success", albeit one muted by the wacky networking layer they use. Compound that with RHEL's older kernels, and we had to deal with oddball issues like iptables/arp table getting out of sync with what's actually running, resulting in connectivity issues. And don't get me started on removing and redeploying a stack; that would occasionally wedge things so badly we had to cycle the docker daemon.

Still, a shame. The gap between "Look, I wrote a compose file" and running something on a small cluster is tiny, and that was its main strength, even if it did suffer from some serious heisenbugs. Why they decided to add and remove features between versions and do their damndest not to make a compose file 100% "forwards compatible" with Swarm is another mystery.

<comment><USER9> Swarm was a pretty big mistake. I think based on just relative resource investment compared to Kube, it ought to have been obvious that it'd never be relevant if it wasn't extremely specialised.

<comment><USER8> That's true. However, consider this environment:

\- The ops team are in a different country, and are wedded to very old- fashioned views of administration ("Automation? But I like manually running commands from a runbook!")

\- You work with a team of people who are quants/actuaries/scientists/engineers but not professional developers, but you want them to have a turn-key environment so they can Get On With It. When they need new python packages or god forbid upgrade pandas or something else, there's a full CI chain that'll make sure that what they do _here_ also works _there_.

\- Swarm is (from personal experience) easy enough to teach people who don't know anything about Docker. You can show them how to query the state, modify it, look at logs, etc. all without the hassle and overhead of configuring and running K8s, even though it will always be my #1 choice for tech-literate orgs. Swarm, for many, including myself, was a pragmatic choice -- 80% of the immediate benefit of container orchestration with 20% of the cognitive overhead for the chaps in another country who had to maintain it if things went south.

<comment><USER9> Sure and then google release "kubelite" or some guy writes a convenience script and there goes your competitive advantage for the use case :)

Docker didn't have enough of an advantage even though Swarm game shipped with it, so de facto if you had Kube you would have had Swarm first...

<comment><USER8> I made a tradeoff; keep in mind, it's not always the case that the best technology wins. Running <Technology X> is all well and good, but if you cannot keep it running perfectly, or it results in unacceptable downtime due to operator error, then that reflects poorly on the architect/lead in charge of picking the tools.

I am more of a mind to make sure that I can solve the task(s) that I am given, such as it is, with the resources available (people, knowledge, time, etc.). That inevitably means tradeoffs. In a parallel universe I would have used K8s instead, as I think it's exceptional and far superior to Swarm. However, with the limited resources available, I chose Swarm, and for all its faults it's running fine.

<comment><USER10> I agree with your pragmatism (and admire it). I would only urge you to add a couple of tools to your toolbelt for analysis:

1\. Open source politics aka is the project viable? 2\. Where's the money coming from? Aka, what products/companies build solutions off the tech? 3\. Look for growth, not survival. If a company is not growing, it is dying.

These extra three test "gates" help me select what technology I will use, learn, and bet my career on....

<comment><USER8> Keep in mind, when this solution was adopted Docker were still wedded to Swarm. Even if they stop caring about it -- as they pretty much have now -- we have a system that works at rest. Two years on, the team(s) that handle the production support and operations are more comfortable with Docker & co, because of this. Not to forget, this is a very large (and risk-averse) enterprise. You don't always get to pick whatever you like!

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I never understood why "modern" tools like Docker have to provide everything: networking, firewall, repository, you name it...

I understand somebody wanting to type "docker run xxx" and have everything setup automatically, but if you're running anything but default networking and actually care where the xxx image comes from, it's gonna fail miserably. Coming from the VM world, I found it much easier to work with macvlan interfaces that lxd supports for example - the container gets it's own interface and IP address and all networking can be prepared and set up on the host instead of some daemon thinking it knows my firewall better than me...

<comment><USER12> Yeah, it feels too monolithic. Just to showcase it can run Hello World in one "docker run" command I guess?

Another thing people use Docker for but shouldn't is application packaging. Using Docker you build one fossilized fat package with both all OS and app dependencies baked in. Then some day after years of using that Docker image you need to upgrade your OS version in the image but you can't replicate the app build because you didn't pin exact library versions and the global app repository's (pip, npm) later version of the package is no longer compatible with your app.

Application packaging is better to be done in proper packaging systems like rpm od deb or other proprietary ones and stored in organization's package repository. Then you can install these rpm packages in your Docker images and deploy them into cloud.

The difference in OS dependencies and app dependencies are clear when looking at contents of actual dockerfiles. OS dependencies are installed leveraging rpm or deb ecosystem. Apps are cobbled together using a bunch of bash glue and remote commands to fetch dependencies. Why not use proper packaging for both OS and apps and then just assemble the Docker image using that?

<comment><USER13> > Using Docker you build one fossilized fat package with both all OS and app > dependencies baked in.

Exactly. Most uses of Docker are like a junk drawer: neat on the outside, a total mess on the inside.

People stuff their python 2 app in there and forget what their dependencies are, or where they got them from.

Good luck upgrading that 2-3 years from now.

<comment><USER14> To be fair, this is how people build applications. "Oh there is this library let me just pull that in"

</comment></comment></comment></comment><comment><USER15> > When people understand that they can easily make the choice to swap out the > container runtime, and the knowledge is out there and easily and readily > available, I do not think there is any reason for us to user docker any more > and therefore Docker as a technology and as a company will slowly vanish

How about MySQL as a counter argument? It's always been feature-weak compared to PostgresQL, with a less business friendly license and now owned by one of the most despised software companies by technologists. But it's probably _still_ the default relational database people pick up. Habit, defaults and massive installed base can go a long, long way.

<comment><USER16> Container engine is just a wrapper around couple of Linux APIs mainly cgroups & namespaces & iptables/BPF - there is most of hard work done. A good example how trivially it can be implemented is this: [https://news.ycombinator.com/item?id=9925896](https://news.ycombinator.com/item?id=9925896)

Now, implementing DBMS with even basic SQL query language, is not a trivial job.

<comment><USER14> That's funny because getting these things right (without security issues) is quite difficult.

<comment><USER17> Its very likely that most of the challenging security stuff will continue to move down into the kernel itself. Its important to remember that the entire concept of a container wasn't really a single unified concept in the Kernel until very recently as they've gained popularity; instead, they were a amalgamation of a few different capabilities in the kernel.

<comment><USER10> Perhaps, you caught news of something I haven't seen, but AFAIK, "container" is still defined in user space. Talking to Eric Biederman, that's what the kennel team wants - people to experiment in user space, remixing kernel tech together...

<comment><USER14> There's a new-ish (from Feb) LWN article about container's as an object in the kernel: [https://lwn.net/Articles/780364/](https://lwn.net/Articles/780364/)

Reception still doesn't seem great.

</comment></comment></comment></comment></comment></comment><comment><USER18> It's fair to say that in the hype cycle Docker (the technology) has passed its peak, but I don't think the conclusion that as a technology, it's finished, is warranted.

Containerization is still on the rise and Docker is part of that. The toolset is still a good, fairly easy to use, place for individual developers to use containers on the client-side whilst creating containerized applications.

For smaller deployments (without orchestration) a single Docker engine with things like compose, can still work well.

Obviously on the orchestration side, Kubernetes has won, although it too will face the inevitable trough of disillusionment when people realise that all technologies have downsides.

Personally, for simpler workloads, I think Docker swarm can still be a good answer, as it's a lot less complex than Kubernetes to set-up and maintain.

The idea that the Redhat container stack (podman, CRI-O, et al) necessarily mean the end of Docker, doesn't really follow at all to me.

If anything the increased use of containerd directly is a bigger threat to Docker's market share.

<comment><USER19> I think the main point to consider is, if Kubernetes is the technology for large deployments, who is left to buy enterprise solutions from Docker the company?

And without enterprise sales, what is going to fund docker development for the small and simple docker workloads?

<comment><USER18> Well Docker the company is a different game. They have gone quite heavily for the enterprise market and support Kubernetes as part of their Docker EE product.

Of course, whether that will give them enough success to justify their valuation, is another matter. Personally, I had thought they would get bought out by one of the large tech. players who is heavily investing in containerization (e.g. Microsoft) but that doesn't seem to have happened so far.

<comment><USER20> Amazon might have a say in this, both their ECS and EKS solutions are based on docker.

</comment></comment></comment></comment><comment><USER21> What is wrong with Docker? This does not address any technical or other shortcoming and only seeks to replace one set of over engineered tools with another with the exact same problems. [1]

The is yet more of the ecosystem continuing to push over engineered tooling and 'winners' breathlessly without basic technical scrutiny that leaves end users dealing with needless complexity and debt.

Containers can be useful as a lightweight, efficient alternative to VMs and those who want containers untouched by questionable ideas should try the LXC project on which all this was based.

Any additional layer on top of this be it non standard OS environment or layers should meet technical scrutiny for end user benefits and most users will be surprised by the results.

[1] [https://www.flockport.com/guides/say-yes-to- containers](https://www.flockport.com/guides/say-yes-to-containers)

</comment><comment><USER22> This post links to podman. But the podman website is completely useless, because it does not tell me what it does differently/better than docker, only that

        What is Podman? Simply put: `alias docker=podman`

So, for someone who occasionally uses Docker for running services or creating specific build environments (manylinux1): what are the benefit of podman over Docker?

<comment><USER23> Podman doesn't have a daemon like Docker does. It also more tightly integrates with buildah, which the article doesn't expand on. Have a look at this (very brief) overview to get a bit better idea of their relationship: [https://github.com/containers/buildah#buildah-and-podman- rel...](https://github.com/containers/buildah#buildah-and-podman-relationship)

Podman also uses the same notion of pods, and it _doesn 't_ support docker- compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Basically, podman/podlib allow you an easy migration path from your local computer to a k8s cluster, with the same images and same concepts. Have a look here: [https://github.com/containers/buildah#buildah-and-podman- rel...](https://github.com/containers/buildah#buildah-and-podman-relationship)

<comment><USER24> _> Podman also uses the same notion of pods, and it doesn't support docker- compose syntax/files, because RedHat strongly believes that Kubernetes has already won._

Could you expand on that please? Almost everything I run locally (be it a self-hosted service or app devel) with docker is a docker-compose stack. It allows me to easily manage/monitor services via CLI or Portainer. How does Podman and other modern tools offer to solve this case, or is it proposed now to use K8s locally?

I got enthusiastic about Podman not having a daemon and running Podman containers as a non-root user[1].

[1] [https://opensource.com/article/18/10/podman-more-secure- way-...](https://opensource.com/article/18/10/podman-more-secure-way-run- containers)

</comment></comment></comment><comment><USER25> It's not clear to me that the author has a solid understanding of how Docker makes it money. You don't make money just by giving away software, and you also don't make money by providing support software for no one uses. Docker has been pretty smart to build a well-known brand around supporting a specific set of technologies -- some theirs, and some not. When it became clear they were unable to own every part of the container ecosystem, they made smart decisions around supporting k8s and engaging the open container standard.

Docker's got lots of runway providing enterprise support contracts, so I'm not worried about them.

I think the author's also not noticing that orchestration was really a bit of a stumbling block that would eventually be removed. Sure, you've still got to use k8s in self-hosted, GCP, and Azure, but those of us on AWS have the option to use ECS with Fargate and have many of the core features of something like Kubernetes fully managed.

So anyway, this post is a bit dramatic, and maybe has a few blinders on.

</comment><comment><USER26> This article contains really no good reasons and spends many words to say that unnamed alternatives exists.

One argument is that there are no new big features. But that is completely normal when things become stable.

<comment><USER27> Agreed. I came for rational but saw none. There seems to be a lot of hate for Docker I don't understand. Is it community management? Is it some esoteric tech concern? Can someone more knowledgeable pipe in?

<comment><USER28> I agree.

Why do people hate _Docker, the CLI_. Anyone? I mean, it's slowly going OCI, so no vendor lock-in.

<comment><USER29> HN crowd likes to gaze at FANG-like corps and treat it like gods, FANGs use Kubernetes? well then for sure docker is passe :) It doesn't matter that for some use cases swift and straightforward solutions like docker and it's ecosystem are better.

</comment></comment></comment></comment><comment><USER30> For me Docker's value is to be able to easily run some Linux services with Windows. They got a lot of ready to use recipes on their website, so it's really easy to run e.g. wordpress with mysql. I would spend at least hour to manually setup VM with Ubuntu, install that stuff there. Also I'm using it to run postgresql for development. While technically I can do it just from Windows, I feel safer concentrating all that stuff inside disposable VM, also it's easy to share onboarding scripts with colleagues. I don't see how RHEL's tools would help me with that. Actually I could replace all my Docker usage with few shell scripts, but they have to be written and with Docker they are already written, many by experienced software maintainers. Docker will die when popular software will discontinue their docker images.

<comment><USER31> How's docker on Windows working out for you so far?

<comment><USER30> No problems at all. There was weird problem when I tried to output binary file to stdout inside docker and redirect it inside cmd which resulted in garbage. But it wasn't appropriate usage I guess.

</comment></comment></comment><comment><USER32> Are there any container filesystems that support multiple inheritance, and create diff layers? It would be really nice if I could build a few different things independently, and then merge the final images together. Also if I could only include files that have changed in a new layer, and ignore duplicate files (even if the file was touched, or the timestamp has changed.)

Those are my biggest pain points with Docker at the moment. I have a complex build script that uses multi-stage builds and rsync to achieve this [1], but it's still a bit slow and inefficient. Would be nice if something supported this out of the box.

I've worked on a lot of projects where people just reinstall (and recompile) their entire list of dependencies (Ruby gems or NPM packages), and you have to jump through hoops to set up a caching layer, or maybe install them into a volume as a run-time step, instead of at build time. There should be a much better native solution for this, instead of needing to invent your own thing or read random blog posts.

[1] [https://formapi.io/blog/posts/fast-docker-builds-for- rails-a...](https://formapi.io/blog/posts/fast-docker-builds-for-rails-and- webpack/)

<comment><USER14> I would say check out buildkit, which is the tech behind "docker build"'s new builder.

I don't know if the Dockerfile format is really suitable for this, but you can now build your own format and Docker can just build it.

Basically buldkit breaks things down into a frontend format (like Dockerfile) and a frontend parser which gets specified as an image at the top of your file (`#syntax=<some image>`), the parser converts the frontend format into an intermediary language (called llb), buildkit takes the llb and passes it to a backend worker.

This all happens behind the scenes with `DOCKER_BUILDKIT=1 docker build -t myImage .`

Docker actually ships new Dockerfile features that aren't tied to a docker version this way.

Actually there are a number of new Dockerfile features that might get you what you need, even if the format isn't all that great, at least it's relatively natural to reason about. Things like cache mounts, secrets, mounting (not copying) images into a build stage's "RUN" directive, lots of great stuff.

This is all officially supported stuff.

Here's a demo of "docker build" building from a buildpack spec instead of Dockerfile: [https://github.com/tonistiigi/buildkit- pack](https://github.com/tonistiigi/buildkit-pack)

\- buildkit - [https://github.com/moby/buildkit](https://github.com/moby/buildkit) \- official Docker docs - [https://docs.docker.com/develop/develop- images/build_enhance...](https://docs.docker.com/develop/develop- images/build_enhancements/) \- buildkit Dockerfile docs - [https://github.com/moby/buildkit/blob/master/frontend/docker...](https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md)

</comment></comment><comment><USER33> This is a similar discussion to vinyl vs cassette vs cd vs streaming. All will keep existing in some form or another. Admittedly, some will die out completely (DCC, Minidisc) I'm pretty skeptical this going to be Docker though.

Even more, the argument that because Redhat RHEL 8 no longer has a Yum repo for it Docker is dead in the water is a bit far fetched. According to Wiki RHEl is a fairly small % of the server market compared to Ubuntu, Debian and Windows for that matter. [https://en.m.wikipedia.org/wiki/Usage_share_of_operating_sys...](https://en.m.wikipedia.org/wiki/Usage_share_of_operating_systems)

<comment><USER34> RHEL also means Fedora and CentOS, the latter is extremely popular for large scale deployments. The article is for web servers only, I think the real market share of RHEL and CentOS is more like 30-40%.

Podman just makes more sense because it doesn't require a big fat daemon. You launch containers like any other service: with systemd. And you can run podman without root permissions as well, which is a huge win for security.

<comment><USER33> Well, having worked quite a bit with RHEL and Centos in the past, I found their day to day usage quite different. Maybe that has changed.

More important, I only saw RHEL at traditional Fortune 500 companies. Not sure how their market in FANG type companies is. Probably negligible. F500 is still big of course.

<comment><USER35> FANG are making their own OS at this point so they're not really relevant.

There are two distributions left in Linux, RedHat derivatives and Debian derivatives. In terms of install base, it's maybe 1/3 and 2/3\. In terms of money, expect the other way around, because it's F500 who pay the most for software and they are on RedHat.

RedHat is actively trying to kill docker (along Google and Amazon). RedHat removing "docker" CLI and replacing it with its own tools is a major step toward that. Docker will be de facto dead in enterprise as soon as it stops being supported by RedHat.

<comment><USER36> Unless these orgs can replace it with something as feature complete and stable as Docker I suspect their customers will ultimately have the last word.

<comment><USER35> I will pass on the joke to call docker either stable or feature complete.

There is nothing that prevents RedHat to ship an alias to their own tools by default, just like java => openjdk.

It's not the responsibility of RHEL to maintain or support third party software. If case you didn't know, docker stopped shipping with Debian years ago.

<comment><USER36> Nothing is ever feature complete or stable, I know. All software is shit, right?

The day RHEL customers stop using the docker runtime is when RHEL will stop supporting it - until then, they'll support it. Case in point: java -> openjdk.

Anyhow, this article is just click bait, and it's been done at least twice a year since Dockers inception. I'm disappointed that this community finds shitposts like this more compelling than the NSA opensourcing a reverse compiler, but I digress.

Have fun in your bubble.

</comment></comment></comment></comment></comment></comment></comment><comment><USER37> Nope. Docker's value isn't just its software. It's the support built around it, tutorials, familiarity and common usage, Dockerfiles, huge Docker Hub, existing setups relying on it and so on. Articles like this tend to overlook the value of entrenched technology that works well enough.

<comment><USER35> Funny enough. Kubernetes ignores pretty much all of that in favor of its own, making experiences in running Docker alone mostly worthless.

</comment></comment><comment><USER38> Based on this, I've tried most of today to make minikube work on macOS. But as I'm using DNSCrypt-Proxy I had major issues making it work without manual steps.

So far, the Docker for Mac is a solution that just works.

If someone have some experience, I'll gladly want to know how you make it work flawless.

</comment><comment><USER28> The article mentions Kubernetes using containerd and the OCI is the future, but also fails to mention that containerd is developed by Docker, which supports OCI, which largely supported by the Docker company.

As of the latest versions of Docker, the dockerd is now using containerd under the hood.

I'm not sure how the Docker CLI will exactly die. The posts seem to focus on the CLI only, and even calls out that "the viability of the company Docker is outside the scope of the post", but it failed mention my previous points.

<comment><USER39> Containerd is a project within the Cloud Native Computing Foundation, which in turn is part of the Linux Foundation. Docker haven't been directly involved since 2015, and even then, it's arguable that they've never been (you may be thinking of runc though, which was donated in 2015).

It's true that Docker uses containerd under to hood, but that's actually part of what the author is arguing. Docker as a technology is a wrapper platform around core industry technologies that they neither own or control. That means they have to compete as a tooling company, and they have already lost ground there. The more things like Kubernetes and podman join the market, the less required Docker becomes, which means they're going to be more and more at risk of failing.

[https://en.wikipedia.org/wiki/Linux_Foundation#Containerd](https://en.wikipedia.org/wiki/Linux_Foundation#Containerd)

edit: added link for reference

<comment><USER28> > Docker haven't been directly involved since 2015, and even then, it's > arguable that they've never been

A large majority of even the recent commits to containerd are made by Docker employees.

[https://github.com/containerd/containerd/commits/master](https://github.com/containerd/containerd/commits/master)

> It's true that Docker uses containerd under to hood, but that's actually > part of what the author is arguing. Docker as a technology is a wrapper > platform around core industry technologies that they neither own or control.

I cede your point, but it's irrelevant and isn't want the author implying (even directly).

From the article: "I do not think there is any reason for us to user docker any more and therefore Docker as a technology and as a company will slowly vanish."

The end users do not care how cgroups are setup or mount points are built. The guts may be standardized, but the docker toolchain (Dockerfile, docker- compose, docker run) will continue to exist. The "runtime" is irrelevant and there just isn't a competitor in the "tool chain" arena.

Docker Swarm is the only thing that will vanish.

> The more things like Kubernetes and podman join the market, the less > required Docker becomes, which means they're going to be more and more at > risk of failing.

Kubernetes is an entirely different use-case. Nobody is arguing Docker Swarm will beat it.

You could say the Docker CLI isn't required with the advent of other tools, but those are incredibly big shoes to fill. Think of all that entails (Dockerfile, docker-compose, the CLI, cross-platform(-ish) support for Windows/OSX).

Also, competition leads to better tooling. Did anyone ever say "Unix isn't required any more, because with have Linux"?

The tooling of the Docker CLI is in a very good spot _as-is_. The guts are being opened, which I think would relieve the pressure some may feel to jump from Docker.

</comment></comment></comment><comment><USER40> Honest question from someone who only used docker on several occasions to deploy 3rd party software but wants to invest into containerization. Is it worth going deep into docker right now? Is he knowledge transferrable to kubernetes and whatever else is going to replace it? I want easy deployment that properly deploys containers and telheir dependencies, but many of my scenarios don't need redundancy, scalability etc. My use cases are in-house so managed solutions won't be considered. On the other hand I don't want to have much worse operational complexity than with docker (and that's what I heard running local kubernetes biggest drawback is). Also many open source solutions provide dockerfiles, not caring about other containerization solutions. Please help, I'd rather avoid investing in an already obsolete solution if possible.

<comment><USER18> Docker the technology isn't obsolete now and I very much doubt it will be in the future.

As you've noticed there's a load of solutions who make use of Dockerfile formats and store images on Docker hub.

I'd expect that there will be future developments, but that they'll be backwardly compatible with existing deployments.

Docker Engine (the daemon running on a single host) and Kubernetes (the orchestration system) largely serve different needs.

Kubernetes is good for large scale deployments where it's additional complexity is warranted.

For running groups of containers on a single host (or small number of hosts) Docker does just fine.

</comment></comment><comment><USER41> So many times have we thought that a technology will prevail or disappear based on its validaty or adequatecy, and so many times have we seen the most popular survive.

JavaScript comes to mind. If it's widespread and easy to learn, it might not matter how much technically better other alternatives might be.

We'll see

</comment><comment><USER42> Well I can see kubernetes being the dominant container orchestration, but what about use cases for docker that simply doesn't need any orchestration? I mean those containers that are run on a single machine, perhaps manually, for purposes other than deployment?

</comment><comment><USER43> I've always disliked articles that use this tone. It's meant to be informal, but comes off as lazy and spoken in muted tones as if the author were in a pub; Docker sitting in a booth a few meters away blithely sipping on a pint of bitter. The substance isn't much more enlightening than typical bar banter either.

Docker played a pivotal role in creating our modern understanding of containers and we should be thankful for that. I don't understand the value this article provided beyond pointing out a few container runtimes I hadn't heard of.

</comment><comment><USER44> I don't get why not more people are using Swarm. It's simple and it get the job done for many people who don't need a full Kubernetes setup. Also, for instance, it encrypts secrets, opposed to Kubernetes which only does Base64 encoding of secrets.

I do understand the market dynamic but still there are niches for other simpler products.

<comment><USER45> Kubernetes supports encryption at rest of secrets: [https://kubernetes.io/docs/tasks/administer- cluster/encrypt-...](https://kubernetes.io/docs/tasks/administer- cluster/encrypt-data/)

They're encrypted in transit via mTLS.

</comment></comment><comment><USER46> Since the author doesn't name any of the alternatives:

[https://containerjournal.com/2019/01/22/5-container- alternat...](https://containerjournal.com/2019/01/22/5-container-alternatives- to-docker/)

</comment><comment><USER47> The death of the Docker as a technology is laughable. Every Cloud provider is racing to add container orchestration features and they all use Docker under the hood [1, 2, 3, 4]. Cloud providers are dumping hundreds of millions into this ecosystem through, training, credits, new features, etc. I have not seen anyone step off the gas. They are all seeing massive growth in container adoption. My guess is this is only the start. Go look at any DevOps/SRE job posting and you will see Docker, Containers, Kubernetes. This post is wrong when is comes to the technology going away anytime soon.

Container orchestration is light years better than anything that we were doing on the operations side before. This is why I find it extremely hard to believe we are going back. We would need something much better to jump to and that has not been invented yet. So, Orchestration/Docker/Containers are here to stay for the foreseeable future.

The rkt image format tried early on to subvert the Docker Image format and was unsuccessful. Today, there is much more depending on the existing image standard. You would totally fragment the existing integrations if you attempted to change. I am not saying that people will not try. But, I just cannot see it happening anytime soon. You have all these Clouds betting on it, you have millions of Dockerfiles out there now, and tons of people trained on it. All these CI/CD platforms supporting it. You would need some massive reason to change. Why would they? You might see people under the hood take the Docker Image and wrap it somehow, like gvisor [5], but they will still likely accept the Docker Image.

Go look at these charts from Datadog about their customers Docker adoption [6]. Every single chart is hockey stick growth. This is a sampling of 10,000 companies running 700 million containers in real-world use. I am just offering a counter to the point that the image format is coming to its death. I do not see that.

Disclosure: Former Docker employee.

[1] [https://aws.amazon.com/ecs/](https://aws.amazon.com/ecs/)

[2] [https://aws.amazon.com/eks/](https://aws.amazon.com/eks/)

[3] [https://cloud.google.com/kubernetes- engine/](https://cloud.google.com/kubernetes-engine/)

[4] [https://docs.microsoft.com/en- us/azure/aks/](https://docs.microsoft.com/en-us/azure/aks/)

[5] [https://github.com/google/gvisor](https://github.com/google/gvisor)

[6] [https://www.datadoghq.com/docker- adoption/](https://www.datadoghq.com/docker-adoption/)

<comment><USER48> He isn't saying containers are dying, he's quite clear on that.

<comment><USER47> > upcoming death of Docker as a company (and also perhaps as a technology) ...

The first line says differently.

<comment><USER49> Docker isn't all container technology. It wasn't the first, isn't the best and is not synonymous with the concept.

</comment></comment></comment></comment><comment><USER50> As much as docker works, I can't help feeling it is a big kludge.

CLI usability is close to zero. One (temp) image per line in the Dockerfile might have some practical uses, but most of the time it doesn't.

Yes it seems their days are numbered.

<comment><USER28> > CLI usability is close to zero

What?

> One (temp) image per line in the Dockerfile might have some practical uses, > but most of the time it doesn't.

I completely disagree. Cached builds being one reason, viewing the intermediate layers is just a huge benefit. Why _don 't_ you like it. You could always build with "\--no-cache", which all CI should be using anyway.

<comment><USER50> > What?

Yes.

It's all over the place. [https://docs.docker.com/engine/reference/commandline/cli/](https://docs.docker.com/engine/reference/commandline/cli/)

It has no obvious separation of commands dealing with images/containers/running containers. Sometimes you refer to them by tags, sometimes by IDs.

It's non discoverable. It's non intuitive.

I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images?

Docker build has this nice example here:

'\--tag , -t Name and optionally a tag in the 'name:tag' format'

Ok so you set a name with --tag?

Compare with 'kubectl get pods'

> Cached builds being one reason, viewing the intermediate layers is just a > huge benefit.

Sure, as I said, it is useful, but you do not want to do this most of the time.

> You could always build with "\--no-cache", which all CI should be using > anyway.

Bad defaults are an UX problem, thanks for furthering my point.

<comment><USER51> >It's non discoverable. It's non intuitive.

> I can't know what 'docker rm' does without reading the docs. Oh and there is > 'docker rmi' is that for images?

I think you're using the old CLI. A couple of years ago, they added new syntax and "encouraged" its use by default [1] (though IME people still use the original).

This is definitely more discoverable and logical; the syntax would be `docker image rm` [2] or `docker container rm` [3], etc

[1] [https://blog.docker.com/2017/01/whats-new-in- docker-1-13/](https://blog.docker.com/2017/01/whats-new-in-docker-1-13/) [2] [https://docs.docker.com/engine/reference/commandline/image_r...](https://docs.docker.com/engine/reference/commandline/image_rm/) [3] [https://docs.docker.com/engine/reference/commandline/contain...](https://docs.docker.com/engine/reference/commandline/container_rm/)

<comment><USER50> Interesting, I used it last year, but I'd say it could have been an older version.

Thanks for pointing this, and I'm glad they realized the issue as well!

</comment></comment></comment></comment></comment><comment><USER52> This is sad, because what made Docker useful was a full feature set.

We could already build chroot environments. We could already keep remote images. We could already set up app-specific networks. Having the tools wasn't what we needed: it was the confluence of all the features.

If the alternative to Docker becomes learning 50 new tools, we'll have failed as an industry, and shouldn't call ourselves engineers. You don't replace a car with a wheel barrow-lawn mower-hand held radio-portable fan. This obsession with churning out a new tool every year has to stop.

</comment><comment><USER53> I basically agree with the technological argument made in the post. Orchestration plays the role of OS, where resources are defined, managed and protected. Containers are something analagous to device drivers, presenting the underlying resource as narrowly and efficiently as possible.

But that's the life I expect, not the one I live today. In the present day I'm much more reliant on docker than on kubernetes, and I cannot live without being able to freely mix and match go, python, or Java , really old and really new, in any host configuration I want.

</comment><comment><USER54> _All 3 big cloud providers, now have a managed Kubernetes solution that they offer to their customers (and as a result will eventually sunset their own home-made solutions that they built over the years - because there can be only one)._

I haven't heard anything about this from AWS. Certainly they've introduced EKS, but I haven't heard anything about setting their ECS orchestration out to pasture. Does anybody have information about this?

</comment><comment><USER55> Yea there are alternative Docker runtimes and Kubernetes won the orchestration war but Docker images are here to stay. As far as I know there aren't better alternatives for Docker images and even Kubernetes uses Docker images. Docker as company currently has a Red Hat-like business model and that's certainly hard to sustain so agree on that front.

</comment><comment><USER56> I'm using Swarm on a small cluster (3-5) machines. Is there any reliable Kubernetes alternative for that? Portainer as Swarm UI was buggy for me - <USER2> usable and stable UI would be nice, but I'm not sure if I should do the full Kubernetes dance :/

Easy to debug and lightweight would be also great. I didn't really found something good.

<comment><USER57> I'd be really interested to know more about your setup and processes if you're running Swarm in production? For example, how do you handle rolling updates?

<comment><USER56> we are not a SaaS company, we just run some simple nodejs based services on swarm and my goal is to use swarm as a testing hub for docker - mostly the ci should push something there for the devs. So uptime does not matter, however swarm crashed badly a few times on me and at the moment everything important is well configured outside using your typical LTS linux distribution and I'm hesitant to move our basic services to it...basically 9-5 it has to work, I can just run apt-get update && reboot earlier or later - really not sure if I should move all the stuff into swarm / k8s - also because bus factor would be one and there is some experience with the old linux way.

For everything that resembles a microservice/service -> Docker, everything else (ldap, mail) -> oldschool. So far so good.

I'm looking at k3s or minikube with rancher as ui - maybe that's better, or we just ignore the hype and run docker-compose.yml files by hand but that's also pretty shitty.

</comment></comment></comment><comment><USER58> Providing base technology doesn't seem to lead to financial success. You have to provide more concrete solutions for companies and people instead of the abstract infrastructure. I wonder if protection of the base technology through software patents could have averted this looming financial disaster.

<comment><USER59> Prior art existed for a decade.

</comment></comment><comment><USER60> I do like the fact that docker now works for non-Linux cases, like Docker on Windows with Windows containers. Would be nice if they would also support MacOS containers, FreeBSD etc. That would certainly entrench themselves as a "universal" container technology.

</comment><comment><USER61> Who is providing a container registry that can replace the offering from Docker (the company)? That seems to be the big contribution of Docker the company these days: a huge library of container images.

<comment><USER62> ..that have stagnated and are now riddled with vulnerable components.

<comment><USER63> Really? The official images have been quite solid and up-to-date in my experience. Has that changed since last year?

</comment></comment></comment><comment><USER64> Still using LXC where it makes sense and never felt the call of Docker...or Kubernetes or any of this developer popularized opaque tooling over sophisticated meddling with my systems.

</comment><comment><USER65> Yeah, no. Docker is still here and is finally being embraced by larger enterprises (if they haven't already).

I don't see it being switched out for any unproven technology any time soon.

</comment><comment><USER66> It's just normalized as any other technology, it doesn't mean company is not ready for it but that's up to how much they've been partying since.

</comment><comment><USER67> Docker should just merge with Npmjs. Then they might get big enough to get bought up by Microsoft, Oracle or IBM (which I think is their end game anyway).

</comment><comment><USER68> What do you replace Docker Hub with?

</comment><comment><USER69> _Docker was the company that changed the world_

I think I've seen one person use docker once, back in about 2013, to create and freeze a very particular Latex setup. Everybody sees a tiny slice of the world, but to each individual, that slice looks like all of it.

<comment><USER62> How many people have you seen printing money?

</comment></comment><comment><USER70> The main thing is Docker has been used as a way to distribute binaries with all dependencies builtins.

Bypassing all OS packaging systems. It's a hack on top of our broken packaging models. That does work but it is extremly fat and not very elegant.

</comment><comment><USER71> Are Kata and Clear containers actually a Docker replacement?

<comment><USER72> Not really. They can be used to replace one element of the docker stack, runc

</comment></comment><comment><USER73> The death of Docker could potentially happen, but not for the reasons the author lays out. The last argument in the article is interesting. The author implies because RHEL dropped Docker - then game over. But if we want to analyze this it isn't because Docker lost a technology battle. It's because RHEL is protecting their ecosystem. The article is correct in making the case there is choice. However the author doesn't put two and two together with regard to RedHat. Just because you can alias podman with docker doesn't really mean anything. Someone seems to have dipped into the non-reality of Docker-is- a-bad-word, by author Dan Walsh of RedHat. Also keep in mind containerd was contributed by Docker and is the graduated runtime in CNCF. You definitely don't need Docker to run containers. But it's easy to use Docker to run and build. And Docker is still a one line installation on all Linux platforms ([https://get.docker.com](https://get.docker.com))

Next is Docker Enterprise. Can they sell it? This is where Docker is making mistake after mistake IMO. Docker does have a leg up in Windows. But does it matter? Today Swarm is your only orchestration option and while I understand k8s support is coming it still remains to be seen if GMSA is included in the first release (doubtful). If you're a Windows developer and you're deep in the Microsoft ecosystem, you won't be able to productively use Windows Server and k8s this year is my guess given the timelines.

Regardless, Docker has done a poor job capitalizing on Windows. Maybe it's that people just don't need it as much as Docker would have you to believe? Or maybe it's too jarring of a workflow change. Regardless, it isn't working.

Next is the products you get for the money: Docker Universal Control Plane (UCP), Docker Trusted Registry (DTR) and Docker Enterprise Engine (EE).

They're all OK. But the sell is, again, tough. UCP is basically a dashboard for centralizing RBAC for Swarm and UCP in the enterprise, and don't get me wrong - the enterprise needs this. But UCP feels lacking. The UI is distracting and has a lot of oddities. Managing it is a decent amount of work. It's just OK. Also Docker UCP still doesn't support k8s PaaS while competitors do. Remember that Docker hired Kal De away from VMW as CTO. In his time at Docker not much has changed externally, but Docker needs to move faster. Much faster.

DTR is interesting because everyone who's doing containers in the enterprise needs an image repository with, again, those enterprise requirements. And DTR delivers this, but Docker doesn't want to sell you DTR only. You can't buy DTR by itself like it's competitors. Docker wants you to only use all of their bits and it's dumb because Docker claims choice as a core pillar then tries to lock you into UCP+DTR+EE. Oh I see Steve... Choice as in what DOCKER defines for me as choice. Choice of bare metal or hypervisor, but not how I manage containers and orchestration? Back to DTR: it's decent, but again there are other choice and a lot of them are better standalone offerings.

Finally EE. There are about three reasons you really need EE. The first is enterprise support and long term releases. The second is runtime enforcement of signed images at the engine level. The third is oddities like FIPS support. But that's it. And, again, Docker doesn't want you to buy just Engine. They want to sell you the 'platform'.

At the end of the day Docker has good products. They're not exceptional when taken into context of other enterprise software. They're just OK. Docker doesn't realize this yet from what I've gathered. They have recently changed pricing to very VMW-esque CPU count pricing. And Docker doesn't have the market capital to make that leap, unfortunately. At the end of the day my opinion is that Docker is marred by Docker. Not by the competitive landscape. Yes, that contributes to Docker overall but Docker doesn't seem to make sure they have the best product above everything else. Docker's CEO, Steve Singh, is the wrong guy for the job. He is constantly stating cash flow positive by end of this fiscal year yet doesn't seem to care about how good or bad the product actually is or why people wouldn't buy Docker over something else.

So yeah... Docker has done great things. Those great things are all of the contributions Docker has made to the community and continues to do so. But Docker on the enterprise side feels weak, lackluster and very confused. Docker is marred by Docker management and executive ranks from within. I'll give them 2 years make or break and I think, as it stands today it's a coin flip. The acquisition of RedHat by IBM was a good thing for Docker, but may be the nail in the coffin for RHEL long term. If Docker does flounder any longer look for them to be acquired by Microsoft. And then... Docker will be set to sail off into the ether.

</comment><comment><USER31> I have an honest question- is docker even useful for most projects or is it just a preparation for solving imaginary scaling issues that most won't even reach?

I ask because I'm wondering if I should care about docker in the beginning of my project which will have very few concurrent users/requests and would run fine on a single machine.

EDIT: Thank you to all the kind answers!

<comment><USER74> It depends on what you deploy to. If it's AWS or Azure web-app type stuff, then maybe not, but if it's your own infrastructure in anyway then fuck yes.

Ten years ago we build things in C#, used MSSQL and deployed to IIS. All Microsoft tech, all pretty straightforward, except it wasn't. We never kept track of the "it works in dev, but it explodes in prod and I don't know why" hours, but I wish we did. Because it's in the thousands, and those thousands of hours is exactly why we use docker.

We also use docker because it lets us build things that our IT crew isn't certified in running infrastructure for (and the lovely security issues that brings to the table) but we mainly do it because it works.

Docker might not have a monopoly on that, but they have enough of a brand that the word "docker" is to containers what "google" is to search. At least in my circles.

<comment><USER75> > We also use docker because it lets us build things that our IT crew isn't > certified in running infrastructure for (and the lovely security issues that > brings to the table) but we mainly do it because it works.

It is amazing how many technologies get traction simply because "It lets us bypass IT."

<comment><USER74> In our case it's the compromise between developers and a operations department which has 5 technicians to support the infrastructure of a municipality with 7000 employees and around 300 IT-systems.

To manage our IT had to make certain infrastructure decisions and build their competency around those. This clashes with a lot of modern development, but we manage with docker and an increasing Azure presence. It's not optimal, but sometimes it's just necessary. Don't get me wrong, we're trying to improve and build Devops that isn't handing off a container, but it's a challenge in sectors where digitisation and IT aren't priorities despite being an inherent part of any business process in 2019.

There is a real danger in there of course, but we have strategic choices for our development platforms as well. They just need to move a little faster than IT.

</comment></comment></comment></comment><comment><USER76> s/Goodbye/So Long/

</comment><comment><USER77> Dupe of [https://news.ycombinator.com/item?id=19350571](https://news.ycombinator.com/item?id=19350571)

<comment><USER78> It's not a dupe if the earlier submission(s) got few/no comments/upvotes.

</comment></comment><comment><USER79> > .. All the cool kids on the block are no longer using docker as the > underlying runtime.

Cool kids are not using containers at all, they use cloud VMs and autoscaling :) Simple is not easy (tm)

</comment><comment><USER80> If you are a coder, and you want to implement auto devops yourself, for free, then see this video. [https://youtu.be/Qlj6NiOy5jM](https://youtu.be/Qlj6NiOy5jM) You can do it to, remember the proffesionals will shout at you for using this method, it makes them obsolete.</comment>


Why new Firefox 13 'load tabs on demand' is bad UX.  - <AUTHOR> http://renesd.blogspot.co.uk/2012/06/why-new-firefox-load-tabs-on-demand-is.html

<comment><USER2> I don't care if it is bad UX, I prefer it. I also turn off all the different types of preloading in Chrome, but that's another story.

The loading of a page hardly takes any time at all, and I generally have to reload the page when I finally get to older tabs anyways. And, this is silly, but it feels wasteful to have all tabs loaded all the time when I'm only using one or a few at any given moment.

Also I wouldn't mind if someone invented the "next great thing" to get us away from tabs. They are unwieldy, encourage tab-hoarding, and it is difficult to quickly locate a specific tab within a nontrivial number of open tabs. My overloaded tab bar causes more anguish than my email inbox.

</comment><comment><USER3> We used to do this in Chrome in our pre-release days. It was annoying to use so we turned it off. The downside is that our session restore startup time could definitely be better for large numbers of tabs. We could do a better job of prioritizing loads. The right balance is doing the right thing for the user without exposing an implementation detail IMO.

<comment><USER4> Why not something like:

      If *n* tabs >= x

          Load tabs on demand

      Else

          Load tabs in background

x can be set by default at some arbitrary number and also be changed.

<comment><USER5> Problem is, X will change based on a bunch of factors - type of browsing, screen real-estate, etc. If that isn't taken into account, it could result in what the user perceives to be a jarring interface shift.

We could use much more subtle algorithms - what about loading visible page, then queuing up X background tabs to concurrently load (based tab order)? What about a logarithmic backoff (ie, load up visible and several background pages, then slowly load others)?

Fact is, user-time is valuable, compute time (and for most users) bandwidth is not. What's valuable should be prioritized.

</comment></comment></comment><comment><USER6> Except for users that have dozens of tabs loaded because they're digital packrats, and don't care about most of them most of the time.

<comment><USER7> I fully agree, I currently have 174 tabs open, and that's actually a low number for me (I closed a couple hundred down on the weekend). Having all of them reload when I restart my browser was a nightmare before this feature. Everytime I'd have to hunt down a couple tabs that contain auto-playing videos. All while getting Basic Auth password popups for work related resources.

Plus, it is much better for over-all performance since some websites switched to an interface that polls for updates in the background.

Of course I know I'm not a typical user, so I wouldn't really argue against this being an option that is off by default. But it would very much hurt my user experience if it weren't available at all.

<comment><USER8> Sounds like the ideal would be: preload the most recent N (configurable?) tabs.

<comment><USER7> That wouldn't hurt me :) I could even imagine it being useful to be able to automatically load the surrounding context (say N pages left and right). Or load all adjacent pages on the same domain as the active tab, which would be quite useful if one often browses manuals.

</comment></comment></comment></comment><comment><USER9> What about throttled loading ? processing wise, what is in the background will have 5% cpu allocated.

<comment><USER10> One thing that comes to mind is to do all the actual loading of assets (HTML, CSS, images, JS, etc) but don't decompress/run anything. That way it can be done 100% in the background and then spin up quickly without having to hit the network once a tab is clicked.

Might have to look into trying something like that out; I work on Gecko, but in totally different parts of the code, so it'd be a fun little experiment if nothing else.

<comment><USER9> Resource prefetch would be good. I don't even know if it's possible for applications to throttle cpu/thread usage.

<comment><AUTHOR> Threads and processes can be given a lower priority.

Edit for @barrkel: you can also do more advanced resource shaping on some OSen. Like limiting the number of network connections per second, and limiting the bandwidth. There are also cpu throttling possibilities where you can make sure a process only runs max 10% of cpu. Or as you say, putting scheduling into the app is another possibility.

<comment><USER11> Lower priority does nothing to throttle activity unless there is a higher priority thread available to run; if the machine is otherwise idle, lowest priority threads will use 100% of CPU resources. If you want to avoid high CPU graphs, whirring fans from increased heat, etc., you need to make the thread or process sleep occasionally.

For a thread, that's best done with explicit coding; for a process that isn't sharing resources with other processes, you can get away with more invasive freezing from the outside.

<comment><USER9> I guess it's possible to code a tiny arbiter that will wake 'background' thread every few ms.

</comment></comment></comment></comment></comment></comment><comment><USER12> This seems like an issue only power users will have for the most part. Firefox even has an option to disable this for power users.

However, with that being said, I'm not a big fan. I think agumonkey's throttled loading is a nice idea though.

<comment><AUTHOR> There's definitely different groups of users here. Without being able to spy on firefox users, I'd guess the 5-8 tabs people are a decently sized group. The one tab people, and the 50-400 tab people are probably other sizable groups.

The new change helps out the 50-400 tab people a lot. Each group could all do with a good UX though.

</comment></comment><comment><USER13> Off-topic: has anyone on HN spent time cataloguing either good UX choices or bad UX choices in today's web? I'm slowly beginning to take interest in user experience design (I'm a backend developer).</comment>


Teaching creationism as scientifically valid now banned in all UK public schools - <AUTHOR> http://www.upi.com/Top_News/World-News/2014/06/18/Teaching-creationism-as-scientifically-valid-now-banned-in-all-UK-public-schools/5631403128922?spt=su <comment><USER2> I very much doubt there were any UK schools teaching it anyway, hence this news is not really news this side of the pond. (Context for those in the US)

<comment><USER3> I went to a catholic school and we were still taught evolution, the Big Bang theory, etc. Even had compulsory religious education lessons (sane number per week as maths, english, science) and accompanying GCSE in Catholic Christianity and we were still taught evolution.

Many teachers even said that the Old Testament shouldn't be taken literally!

It's quite rare I think and I'm surprised there are schools still teaching it.

<comment><USER4> I was also at a Catholic school, same experience.

I would point out that this stuff has only become a problem after Academies and Free Schools were: firstly, allowed to be sponsored/funded by random people and organisations who were allowed to set the "ethos"; and secondly were given license to choose whether or not to teach the National Curriculum[1].

This second point was supposed to be so that English teachers could choose to teach _any_ Shakespeare play to pre-GCSE students, or indeed to substitute in Chaucer or someone else, but seems to have been used to substitute in this creationist nonsense in place of Science. Note that the school in question(in Manchester) also used a textbook that told students that wives were to be subservient to husbands, or something similarly hideous.

I don't know, but I believe this ruling is a reaction to news about a very small number of schools (this Christian one in Manchester, and the furore over the Muslim ones in Birmingham.)

[1] This is my main objection to such institutions - I'd be happy with a scaled back curriculum for them, but this ruling seems to do the job I wanted (to prohibit unscientific nonsense.) DO NOTE that in particular, Catholic schools like mine do not have this freedom in general, unless they've been given Academy or Free School status - Faith Schools are (AFAIK) orthogonal to these properties.

<comment><USER5> The reason why wives are to submit themselves to their husbands is because the Bible actually SAYS SO - or didn't you read the Bible when you were at Catholic school? (It stems from the fact that Adam was created first, and Eve second.) The fact remains that, if more people actually read their Bible, and used it as their moral compass, our world would not be in the mess it is in today. However, I do agree with you that "scientific nonsense" should not be taught in schools. This should of course include any alleged scientific theory that says that life sprang from nothing (This has never been observed in ANY laboratory anywhere in the world and totally contradicts the known laws of biochemistry), and that 'simple' organisms have changed from one form into another more complex form over time. There is ZERO fossil evidence for this fairy tale (all of the fossil evidence refutes it, and shows that STASIS is the rule [i.e. no change]), and almost any molecular biologist will now tell you that this kind of change is impossible anyway - which is why many of them are now abandoning Darwinism).

The fact that you use the term "creationist nonsense" shows that you are either (a) an outright atheist, or (b) have not bothered to study elementary science, much less the Bible, despite your apparent Christian schooling. You are therefore not qualified to make such a comment.

<comment><USER4> I'm from the UK. Hardly anyone here questions the scientific explanations of the origins of the universe, or evolution, because we understand how science works. Darwin is on the £10 note for a reason, the universe is 13.9 Billion years old according to the cosmic microwave background radiation, you lost this argument some time ago, get over it.

(on a side note, I am completing a PhD in a geology department, and the guy who sat behind me for two years was studying how those giant woodlouse things evolved for his whole PhD, using fossils. In addition to that inadmissible anecdata, I can assert that the scientific consensus on Evolution is much more emphatic that you claim.)

Secondly, yes, like many young people I was brought up in a (UK version of a) religious house and attended a faith school. I am now a Secular Humanist (you seems to call that an Atheist, although it would be more accurate to say that I don't believe _anything_ about deities, than to say I actively refute their supposed existence,) and this transition is entirely common here.

Frankly, I think there are much more important things to do in the world than debate unprovable things about gods. For example: persuading people that gun ownership is bad; state-funded healthcare is good; and that religous extremism/violence (including Christian violence that occurred in Europe centuries ago) would be silly if it weren't so damn serious.

(also, I'm sad that your comment is a direct child of mine, and thus I am prohibited from downvoting it.)

<comment><USER5> Ah, a Humanist, that explains a lot. Woodlice first appear in the fossil record 50 million years ago, and remain unchanged to this day, i.e STASIS, not evolution (as in every other case in the fossil record). If you have a picture of a woodlouse changing into anything else then please post it here. Or did you mean a trilobite by any chance? If so, I would expect a PhD geology student to know the difference between a woodlouse and a trilobite (and trilobites didn't evolve into anything else either - they just became extinct).

The cosmic microwave background (CMB) actually poses problems for Big Bang. Obviously you are unfamiliar with the most recent findings from 2001, so I suggest you start learning about it here:

[http://creation.com/recent-cosmic-microwave-background- data-...](http://creation.com/recent-cosmic-microwave-background-data- supports-creationist-cosmologies).

Furthermore, the CMB merely PRESUPPOSES a big bang in the first place (and big bang is by no means certain - as many astrophysicists will tell you), so there are many assumptions involved in drawing inferences from it. The CMB is also very smooth - contrary to big bang predictions - and the observed mass density does not agree with big bang predictions either. There is no evidence, observational or otherwise, to prove that a big bang actually occurred (which is why many scientist disbelieve in it) nor is there any definitive evidence that the universe is billions of years old (I think that old chestnut arose from uniformitarian geologists' misguided counting of strata, mistakenly believing each layer to have been laid down over 'millions of years', even though recent laboratory experiments as well as direct field observation, have proved it can happen in hours or days).

Like any typical atheist (even though you describe yourself here as a Secular Humanist)you refer to "Christian violence that occurred in Europe centuries ago", forgetting of course that the most appalling violence, including mass genocide, took place in modern history at the hands of exclusively atheistic regimes, all of whose despotic leaders followed Darwinian theories completely (e.g. Hitler, Stalin, Pol Pot, Mau Tse Tung, etc).

As it happens, I am from the UK too (and I'm an astrophysics major). You are free to refute the "supposed existence" of God in your own home, but please do not try to impose your own secular values on me, or on other people of faith in the UK, and especially not on my child's chance of benefiting from a decent indoctrination-free education. That's something I WILL defend, vigorously.

<comment><USER6> > If you have a picture of a woodlouse changing into anything else then please > post it here.

With that statement (and others) it is quite clear you have no idea what you're writing about. Please take your misinformation campaign elsewhere.

<comment><USER6> No sorry, nothing personal, but you have no idea what you're writing about, simple as that. You've taken a fundamental misconception about evolution and turned it into a diatribe.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> This is very encouraging to see. While it would be nice to live in a world where this kind of policy wasn't necessary it is good to see UK taking this kind of thing seriously.

My sister is a English teacher and she shared with me how some of her senior students where not even being taught basic evolution in their science classes owing to the fact that much of the Science faculty were deeply religious.

<comment><USER8> We do live in a world where this policy isn't necessary. the UK doesn't really have a ton of people who take creationism seriously like the US does. As the article mentions, the state mandates the teaching of evolution in schools, and bans the teaching of pseudoscience. That latter is actually pretty funny since UK educations are crammed with pseudoscience, but aside from a few high- profile cases creationism isn't really a problem there.

<comment><USER7> I don't live in the US

</comment></comment></comment><comment><USER9> I wonder how accurate it is to say this is for "all UK schools" as education is pretty heavily devolved in the UK - Scotland, Northern Ireland and Wales all have their own counterparts to the Department of Education:

[http://en.wikipedia.org/wiki/Department_for_Education#Devolu...](http://en.wikipedia.org/wiki/Department_for_Education#Devolution)

NB As an aside, from a UK perspective the title is a bit confusing as "public schools" are private schools here. "State schools" would probably be more accurate - even if there are 4 "states" involved.... :-)

<comment><USER8> If you read the article it applies to all the schools that take government money.

<comment><USER10> It does say that, but news organisations are notoriously poor at articulating the constitutional situation in the UK.

In this case, for example, the move has no effect on Scotland - the education system there is totally devolved, and AFAIK there's no concept of the "free school" or academy model which has been introduced in England and Wales. I'm not sure about the situation in Northern Ireland.

The Scottish Secular Society has been campaigning for a similar ban in Scotland - this will probably happen at some point, although my experience suggests that there's not as much of a problem there anyway.

<comment><USER9> We do have problems related to religion in education - particularly around sectarianism:

[http://www.educationscotland.gov.uk/supportinglearners/posit...](http://www.educationscotland.gov.uk/supportinglearners/positivelearningenvironments/inclusionandequality/challengingsectarianism/about/scottishissue.asp)

</comment></comment></comment></comment><comment><USER11> One might hope so. How about private/religious schools?

</comment><comment><USER12> I wonder if that was even an issue in the UK (or really everywhere except some parts of the US).

<comment><USER13> Yes, it was an issue in the UK. Our previous Government intentionally gave control of some state-funded schools to Christian fundamentalists with limited oversight and their schools have been teaching kids that the world is 6000 years old in science classes, complete with bogus scientific evidence for it. The current Government has been expanding this program.

<comment><USER14> That is a rather one-sided presentation of how this happened.

Neither Academies in general (the invention of the previous administration) nor Free Schools (one development of that idea by the current administration) are necessarily anything to do with religion. Moreover, we have had successful religious schools since long before that without the problems we're talking about here.

Whatever your politics and whatever think of either the Academies concept or allowing schools to be run by organisations with religious motivations, singling out a few cases where things have obviously gone wrong with insufficient oversight as if that is what either government intended to happen with the changes in recent years is hardly constructive.

<comment><USER13> The successful religious schools were, for the most part, run by some of the older and slightly calmer institutional religions like the Church of England and the Roman Catholic Church. With academies, the Government deliberately let random Christian fundamentalist businessmen with interesting religious views run them on the basis that their religion and business skills would make them suitable owners. They didn't actually expect them using this opportunity to teach kids creationism but it was fairly inevitable under the circumstances.

</comment></comment></comment></comment><comment><USER15> Politics. Religion. Valence issue. Why is this on the front page of HN? It shouldn't be; I flagged it.

<comment><USER10> I'm not sure education counts as an entirely political issue.

It's obviously an area that interests the HN community quite a lot - there's a bias towards science and engineering here, and everybody interested in those fields should find the teaching of creationism in a scientific context to be abhorrent. So I think it probably warrants discussion when the education system adopts policies which are actively hostile to the fields many of us are involved in (or in this case, when there's a push back against it).

<comment><USER9> To be honest, I suspect this counts as a political issue in the US and isn't one in the UK. As this is a US dominated site I can sort of see why people don't want it debated here as it'll just upset people - which it appears to have done.

Ironically, religion doesn't play a very large part in day the day political life in the UK even though most of the country has an official established religion.

<comment><USER15> No, the problem isn't that it will "upset people" in the US. Virtually none of the readers of HN in the US see this issue as controversial.

</comment></comment></comment></comment><comment><USER16> Scientists tend to exclude God, and creationists tend to exclude science. It would benefit all of us for each side to recognize that they can live in harmony. Science can provide insight into how God's creation works, but it can never exclude God. If religious interpretation of scripture flies in the face of provable, observable science, then perhaps our interpretation of that scripture is wrong. I'm tired of this ridiculous standoff between the two side.

<comment><USER17> It is ironic that the very same creationists tend to exclude Gods from other religions. Why do they firmly exclude the Mayan God, or the Hindu Gods? Why are their scriptures true but not the others? If there are contradictions in the scriptures of the various religions in the world, then perhaps the creationists "interpretation of that scripture is wrong".

The following quote comes to mind:

"I contend we are both atheists, I just believe in one less god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours." —Stephen F Roberts

<comment><USER18> I had to engage with the Roberts quote because it made me think.

I think he's making a false equivalency. A jump from believing in one god to two gods seems much less significant than a jump from zero to one. ([https://en.wikipedia.org/wiki/Zero_One_Infinity](https://en.wikipedia.org/wiki/Zero_One_Infinity))

Further, I'm not sure that _Roberts_ understands why the religious reject other gods. Like most things people do, there are a variety of reasons:

\- Both Judaism and Islam have explicit commandments or statements of faith that reject other gods

\- Suspicious of foreigners? Deride their religion as unreasonable and obviously contrafactual

\- Wary of talk of the divine being used as justification for a mortal power play? (And you should be) Add a bias for rejection into your calculations

\- And of course, extraordinary claims and extraordinary evidence

</comment></comment></comment><comment><USER19> I never understood why people get so worked up over this issue. Is the job of education to only ever let a child hear the one thing we believe to be most factual and never hear anything else? How boring would life be?

I grew up in a place that valued multiculturalism. We heard about creation, AND evolution, and Indian creation myths, and Egyptian creation myths, and more. Pthe idea was that we had these people around us with this rich history and tradition and us learning it made us understand others better, and feel closer to them. We knew where they were coming from!

So why not teach creationism in schools, as long as at least one group of people are telling their kids, then that's something we should tell all of our kids so they all understand. I don't see the harm.

What if learning origins stories was an exploration of history or anthropology, instead of being framed as 'science'.

<comment><USER20> It'd be a waste of children's time and energy. I understand that, at least in the US, the purpose of schools is _not_ education but babysitting, but if you're going to spend time teaching anyway, perhaps teaching children real science instead of pseudoscience might be a better option not only for them but for society as a whole. Societies that believe school's primary purpose is education don't even have the excuse above for the miseducation you refer to.

It's not about teaching children what we believe to be most factual, it's about _not_ teaching them what we _know_ is false.

</comment></comment><comment><USER21> I posted this link as a new thread, but i think it is worth posting this also here,

[http://www.elisoriano.com/blog/new-truths-belie-evolution- ev...](http://www.elisoriano.com/blog/new-truths-belie-evolution-even-more/)

Would love to hear what the HN community thought on the arguments.

<comment><USER22> I am a bioinformatician with a background in genetics.

The argument against evolution in the article, mainly the piltdown man hoax and new sequencing data on neanderthal is extremely weak.

I don't think a single example of scientific fraud is enough to discredit the entire community. I actually think the fact that the fraud was found out as a hoax shows that evidence is constantly being scrutinized and re-examined; which is exactly what science should be all about.

The point about sequence similarity/dis-similarity being not the ultimate evidence for common ancestry is actually an insightful point; however, I doubt the author of the article realized the insight. He was probably just parroting a statement he read in another article. I don't think you can make a strong statement about homology between genomes using only 65,000 bases of sequence from potentially heavily degraded sample. I think it is just an interesting starting point for further analysis with more data.

The rest of the article dealt with interpreting biblical statements to fit with current undeniable understanding of the universe. IE. Man is made from dust is consistent with humans being consisted of elements found in dust (crust) of the earth. I am sure it sounds nice to people who believe in the bible. But it makes me wonder what these interpretations will look like in a hundred years. Are these interpretations going to change with new understandings of the universe? Is the bible just full of vague statements that can constantly adapt to new understanding of the world? What good is that really?

I've always wondered what a creationist view of biology would look like. There are plenty of attacks against evolution, but never any clear explanation of how their belief system is in accordance with current data. Do new species suddenly pop into existence from nothing by god? Do god specifically implant new species into the womb of a surrogate specie? Why does god invent bunch of new species in the first place? Why not modify the environment to suit the species rather than modify species to suit the environment? I think creationism hides behind a wall of hand-wavy and foggy ideas that breaks down when explicitly examined.

<comment><USER21> "The rest of the article dealt with interpreting biblical statements to fit the current undeniable understanding of the universe.", (How do i correctly put a quote here in the replies?)

In Isaiah 40:22 It is he that sitteth upon the circle of the earth…

This is written before any scientist can confirm it. Thats not interpretation, its a clearly stated fact, "circle". And he points out if other religion gets it wrong.

<comment><USER23> The Earth is a sphere, not a circle. That's not a nitpick either. They thought the Earth was a flat disk back then.

Regardless. Even if you were dumbly granted that the Earth was a flat disk, how would that have any barring on the rest of the Bible's arguments?

Plato was right about a lot of things, but does that mean he was also right about the elemental nature of the universe? (Everything being created from the base elements of fire, earth, wind and water)

Your argument is bad even if it were correct.

<comment><USER24> > The Earth is a sphere, not a circle.

The earth is an oblate spheroid, not a sphere.

<comment><USER25> > The earth is an oblate spheroid

To a first order approximation, such as would be suitable for a discussion on an Internet forum, the earth is basically a sphere...</comment></comment></comment></comment></comment></comment>


An analysis of unclear lessons in video games (2019) - <AUTHOR> https://arstechnica.com/gaming/2019/10/when-easy-mode-isnt-enough-an-analysis-of-unclear-lessons-in-video-games/ <comment><USER2> I think the best games are the ones not outright telling you how stuff works. Figuring this out is part of the experience and then, when you learn a new mechanic you can go play the game again and feel how powerful that knowledge really is. Like the wall jumps in Metroid III (SNES).

Unfortunately game designers are often lazy, just printing some instructions on the screen instead of making the game in a way that the player will naturally learn these things.

<comment><USER3> I forgot the name but there was this game released in .. 2017? A metroidvania in which you have all the tools at your disposition from the beginning of the game, but aren't taught how to use them / know they exist until later in the game. So a player who has already finished the game could refinish it very fast.

Game Maker's toolkit made a video on it.

<comment><USER4> Could you try to hunt this down, I'd love to know.

I looked through Game Maker's Toolkit's YT videos, but without knowing quite what I was looking for, I couldn't find it.

<comment><USER3> (copying my other comment): Just found it, it's Toki Tori 2. [https://www.youtube.com/watch?v=084BUNlI7Gk](https://www.youtube.com/watch?v=084BUNlI7Gk)

</comment></comment></comment></comment><comment><USER5> I was hoping for more actual lessons here.

For those interested in game dev lessons, I wrote up some of the things I learned from making Flash games a decade ago:

[http://web.eecs.utk.edu/~azh/blog/8lessons8games.html](http://web.eecs.utk.edu/~azh/blog/8lessons8games.html)

</comment><comment><USER6> I really recommend clicking through and watching the referenced embedded video that forms the basis for this article. It's very well done and much more substantive than this summary.

[https://www.youtube.com/watch?v=ax7f3JZJHSw](https://www.youtube.com/watch?v=ax7f3JZJHSw)

</comment><comment><USER7> The summary: Some games are simple and intuitive, some are not; that is the only lesson.</comment>


Unbounded Tail Recursion in Python with Lambdak - <AUTHOR> https://github.com/yawaramin/lambdak/wiki/Unbounded-Tail-Recursion-with-Lambdak

<comment><AUTHOR> A nice 'free' feature of my combinator library for writing anonymous function expressions in Python,[1] is that tail recursion can be turned into iteration. This is a 'tutorial' style article. Would welcome feedback.

[1] [https://github.com/yawaramin/lambdak](https://github.com/yawaramin/lambdak)</comment>


Army Conducting Black Hawk Operation Around Washington D.C - <AUTHOR> https://www.bloomberg.com/news/articles/2019-07-22/army-lets-slip-that-it-s-conducting-secret-operation-around-d-c <comment><USER2> The US army trains to protect the political nerve center of the US.

In other shocking news when it rains the ground gets wet.</comment>


Staging, Manipulation and Truth in Photography - <AUTHOR> http://lens.blogs.nytimes.com/2015/10/16/staging-manipulation-ethics-photos <comment><USER2> The title should really use "Photojournalism" instead of "Photography," IMO. Outside of photojournalism, staging and manipulation are a large part of photography.</comment>