Docker Raises $23M
docker.com
docker.com
But they seem to have lost the production environment race to Kubernetes, at least for now. They are the biggest player in the dev-machine market, but more alternatives are popping up making it even harder to monetise. And containerd isn't a part of Docker (Inc) any more.
They do have Docker Hub, and its privileged position as the default registry of all Docker installs. But I don't really see why paying (i.e enterprise) customers would pick Docker Hub over their friendly neighbourhood cloud provider registry where they already have contracts.
Will Docker start rate limiting the public free repos even harder? Maybe making big orgs pay for the privilege of being hosted in the default docker registry? Charging to have the images "verified"?
Anyways, I hope Docker find some viable business model, it would be sad to see them fail commercially after arguably succeeding in changing the (devops) world.
There's also a lot of things they aren't tapping. Just from a security POV alone, a "dependabot for Docker" would probably do a lot for the ecosystem, but hasn't yet happened.
Just like any tool that doesn't offer more than an abstraction layer over OS features, eventually it becomes irrelevant as OS tooling improves.
> This is a Virtual Vault release of HP-UX, providing enhanced security features. Virtual Vault is a compartmentalised operating system in which each file is assigned a compartment and processes only have access to files in the appropriate compartment and unlike most other UNIX systems the superuser (or root) does not have complete access to the system without following correct procedures.
It's cgroup + chroot, in the closest form.
I took it as a very technically incorrect implication with "I was already doing containers with HP-UX Vaults in version 11 back in 1999." Docker is an development product that removes OS as the core concept from application development process. This is at least a milestone as fundamental as VMware's VM tech.
The commercial failure of Docker container is unfortunate.
But if the technology community cannot appreciate its significance, and let the VM-driven mindset belittle it, that's a true tragedy that puts off the drive to innovate.
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en...
And Tru64, Solaris, BSD also had similar capabilities on the UNIX linage, and naturally IBM and Unisys also had their own versions of the theme on their platforms.
You'd think. But I think what we're seeing here is the opposite side of the coin flip of that thread that smug idiots like to continually link here where people were saying Dropbox could be implemented in a day using basic Linux tools. Those people in the thread were always correct (I mean, this is "Hacker" news, so people will approach every problem with their hammer... shocking).
Dropbox just happened to get lucky. Docker, not so much. Both have serious competitors, including Google.
Actually, I believe one text file is the docker killer feature.
It doesn't work bare metal for the new macs, and it is extra bloat instead of making use of macOS capabilities.
Too bad apple didn't help out docker with a macos native version.
FROM macos:10.13.3
RUN xcode-build
Also start making pull requests for a Kubernetes killing feature in the Linux kernel - distributed cgroups and ulimits.
That said, I agree about a higher level PaaS-style offering being a better fit for most companies.
You can use it if you’re not “at scale” completely fine and reap all the benefits as if you were.
Idk it’s because people hate Google, so they hate Kubernetes, whether they’re “get off my lawn” DevOps heads who want to maintain their complicated walled garden deployments they hand-rolled to maintain job security or what but it’s frankly embarrassing.
Doing maintenance on the cluster isn't. Debugging routing issues with it isn't either, configuring a production worthy routing to begin with isn't easy either. it's only quick if you deploy weave-net and call it a day.
I would strongly discourage anyone using k8s in production unless it's hosted or you have a full team whose only responsibility is it's maintenance, provisioning and configuration
It should be also known that all "run your code on machines" platforms (like ECS) have similar issues. I remember using ECS pre-fargate and dealing with a lot of hardware issues with the instance types we were on. It was a huge time sink.
> it's only quick if you deploy weave-net and call it a day
That's exactly the benifit of kube. If something is a pain you can walk up to one of the big players and get an off-the-shelf solution that works and spend very little time integrating it into your deployment. No cloudformation stacks or other mess. Just send me some yaml and tell me some annotations to set on my existing deployments.
> I would strongly discourage anyone using k8s in production unless it's hosted or you have a full team whose only responsibility is it's maintenance, provisioning and configuration
If you have compute requirements at the scale where it makes sense for you to manage bare metal it should be pretty easy for you to find budget for 2 to 5 people to manage your fleet across all regions.
Plus disrupting all the developers.
So far every large scale implementation i have seen has cost the developers a year in productivity.
It’s not F500 scale, but it’s over 100 CPU scale. Confident I have a ton of room to scale this.
1. Off the shelf software (even from major vendors [0])
2. Hireable skill set: You can now find engineers who have used kubernetes. You can't find people who've already used your custom shell scripts.
3. Best practices for free: zero-downtime deploys can now be a real thing for you.
4. Build controllers/operators for your business concepts: rather than manually manage things make your software declaratively configured.
[0] - https://cloud.netapp.com/blog/cvo-blg-kubernetes-storage-an-...
Unless you are at a scale that you can employ a full-time Kubernetes team, you probably don't need Kubernetes, and if you insist on using it for production anyway, you absolutely should use one of the many managed offerings (DO is probably cheapest, I have no affiliation with them), or shrinkwrapped product like Tanzu.
Bootstrapping from scratch on bare metal remains non-trivial and an in-place upgrade is an order of magnitude harder.
Probably didn't need it, but whatever, it worked and I had to learn something new anyways.
Managing a kubernetes cluster has so many possibilities to shoot yourself in the foot without realizing it. There are dozens of tutorials online how to set up a simple linux/nignx/python/postgres cluster (including lots of results for common error google searches) while routing problems of your legacy php application that is behind an istio controlled ingress running on a specific kubernetes version will leave you for yourself.
Sure you won't be able to scale indefinitely. Switching a solid containerized project running on your self-managed machines to a kubernetes setup will be quite easy (if you heeded devops best practices).
The truth is, Kubernetes is awesome, it brings many features to the table. But it also requires ~10% additional very expensive headcount, ~20% more tasks overall, and prolongs the release cycle by ~20%. Figures are from my experience. Those drawbacks are rarely ever discussed - it's just dumped onto existing teams on top of their existing responsibilities, leading to struggle and frustration.
At my job, we went from overly complex Elasticbeanstalk deployments to pushing out new releases via Helm charts into k8s...deployment time vastly improved as did cognative load on what was actually happening.
I'd never go back.
I think you'd find ECS or similar as easy to work with as k8s and all of them will be faster than beanstalk.
Beanstalk is ALWAYS purposefully slow, this is by design. It mimics how amazon deploys internally, slow and steady wins the race to safety. It also has some really bad issue if from from a bad deploy back to a broken app; eg you can wedge it pretty bad.
Anyway at this point I don't think Beanstalk is a fair thing to compare to. It's good you moved off.
GAE, on the other hand, is dreamy compared to K8s. I once moved some infrastructure to K8s because it was costing too much on GAE; I ended up moving it back because it was worth it. We've subsequently moved it to Digital Ocean's PaaS but that's a different story...
I don't think this is some oversight on behalf of the technical writers. They don't lack the ability to explain it in simple terms, they're putting up a warning sign. If you want to join Kubernetes, it's going to mean your entire way of doing things will now be the Kubernetes way, it's not just going to be a few lines of code you add to a Make file.
A lot of people are wary of these heavyweight systems, because it's going to end up a fairly hard dependency.
Some corporate customers have bare-metal servers, some OpenStack, some run in AWS, some on VMWare, some on Azure, more exotic options are not rare either.
Kubernetes smooths out the differences, letting you develop an application against a standard, google-able API that is deployable anywhere.
It if had a sustainable business model it would be deploying it now.
This is underscored for me by the fact that their latest end-user (dev) tools aren't even free software any longer. They started off being unixy as hell, doing one thing and doing it well (and being hackable in the process), and now they ship closed-source spyware under the exact same brand.
As someone who loves the feature set of Docker for development but grows increasingly disillusioned with its performance on Mac, would you mind elaborating what these alternatives are?
https://github.com/VMwareFusion/vctl-docs/blob/master/docs/g...
Looks like it supports doing some kubernetes stuff using a `kind` cluster.
I've had pretty good experiences with Fusion, so, yeah, there's some real Docker alternatives up and coming. I think Docker's great, though, and I feel that we'd never have seen a `vctl` on a mac without it's existence.
Docker is a good example of a company that (IMHO) should never have raised so much capital. It just doesn't have the moat to justify the valuation.
HN has posted several submissions (eg [1]). Containers aren't new. Anyone can do it. So where is the moat? Possibilities include orchestration (which they lost to Google's Kubernetes). There's no barrier to creating images or even having a public registry of images.
It always seemed tike containers were just going to be another feature on cloud platforms. Don't get me wrong: I think containers are a really good technology, for building, testing, deployment and so on.
Docker never had a clear value add and over the years has failed to develop one.
What's more, Github became the engine for dependency management. Go springs to mind here. I actually thought this was a terrible system (eg putting repo owner names in import strings) but it speaks to ubiquity of Github.
But what are Docker images? Maybe a few hundred lines of Dockerscript at the end of the day.
Losing in orchestration I think was the obvious big fail. But they had an uphill battle here anyway because you really need to integrate such a thing with cloud platforms.
I'm really not sure what Docker could've done differently here.
Completely agree, it’s trickier than GitHub. But this is why founders of these companies can potentially make billions: if it were easy, everyone could do it.
I think they realized the CI/CD potential far too late. In another universe you push to GitHub, Docker builds and tests your images and deploys to your provider of choice. Their potential was probably not directly tied to containers but tied to their position in the engineering process between commit and before deploy.
I think they should have realized orchestration was “the” thing for production much sooner. It’s not like you can’t integrate with cloud vendors on your own; there are plenty of managed service providers where you can get hybrid cloud solutions, Docker could have bet big on this.
Instead they came with swarm, which was focused too much on self-managed “on-prem”, while people really wanted something more complex, managed and with a healthy ecosystem of service providers.
Docker got stuck with being a software vendor, but they should have pivoted to being a service provider much, much sooner.
1. Offer open-source 100% free product that's absolutely ground breaking, unlike anything else.
2. Get a shitload of users and free PR machine gets rolling. Network effects kick in.
3. Go to investors with your active user count in excess of millions.
4. Investors go bonkers and their eyes swell up with all the ways they can exploit these addicted-to-free user base.
5. Company has trouble monetizing the users. Users are pissed.
6. We all wonder why they couldn't make billions.
It just happened to Elastic search a couple of months ago when Amazon swiped the rug from under them. Good. This should be a lesson to all the companies that want to follow this pattern. Without Step 1, Docker would have had a much more difficult time to get traction and would have to compete on a level ground. So, they short circuit this competition by going full 100% free product route.
I have zero empathy for these companies and their investors.
The key point is to get users addicted to free.
Uber did this by undercutting the entire taxi industry at a loss. Ever wondered why your rides were so cheap!? Jio did the same in India, offer free unlimited internet on their phone service and wipe out the competition.
Docker is popular because it’s free. A lot of people would be upset if they take down their free hosting repositories.
As a user, I want to pay for stuff to sustain companies. They can still be open source.
My understanding (as a complete outsider) is that they raised a $10+ million series A for their PaaS. The PaaS then presumably wasn't successful enough to raise a subsequent round, but one of their technologies (Docker) was, despite the monetization path for it not being clear yet. So they pivoted to focus on that.
I'm not sure what other outcome could plausibly happen in this scenario. If they stuck with the PaaS as their main focus, they would have gone out of business many years ago.
Wow, imagine being so hateful towards amazing open-source tools
How is that being hateful? I am looking out for the community in this sense.
What's not working well?
I wonder what's next for Elastic. And mongodb etc. And all their users and customers
When open-source companies invite more contributions from their community, haters will complain that they’re “harassing the community for monetization”.
Simply put, some people will never be happy no matter what Docker does, and clearly you are one of them.
> I have zero empathy for these companies and their investors.
Are you trolling? Or do you want to see all amazing open source tech move behind closed doors and payed walled gardens?
F/OSS software works best when it's not a revenue source of the business that develops it. "Hey, I ran into $problem at $work and created $project to fix it! I'm giving it away so that it might solve your problem too! Hit me up on $mailing_list if you want to contribute." Red Hat is pretty much the poster child of this model. They make $0 on all the FOSS software they develop and release to the world but they dogfood it into their own products to collect dividends.
Containers existed for decades as a concept and for years on Linux (using lxc or VirtSquare and later nspawn)
Are we pissed?
Docker hasn't started showing me ads or spewing MOTDs asking for donations.
I haven't run into limitations that would have me purchase an upgrade.
It hasn't been bought by a proprietary company that would make me start worrying about its licencing.
It's a solid workhorse that's been at all my previous jobs and will be at all my future jobs for the foreseeable future.
Most criticisms of it boil down to "there are other container technologies".
I guess some of the reasons for the popularity of Kubernetes could be:
- Kubernetes had Google as a big name behind it, so there was a lot of development resources put into it and eventually, lots of learning resources available, in addition to overall publicity; for example, i don't think anything like this exists for Docker Swarm https://www.katacoda.com/courses/kubernetes
- in addition to the marketing and PR, it got picked up as a solution for many managed offerings by cloud hosts (managed Docker Swarm has almost none), a bit like what happened with serverless and AWS Lambda
- Kubernetes allows for CRDs, has a pretty good API and has a large ecosystem built around it, to help manage its complexity (even distros like K3s and MicroK8s could be mentioned), as well as many to implement additional functionality (Istio + Kiali come to mind)
- this further snowballed into turn-key offerings like Rancher and OpenShift that had financial incentives behind them, the idea of building a new distro that vendor locks clients into a particular company's offering, resources, support etc.
- almost everyone (oftentimes incorrectly) believes that they need to be able to scale a lot and therefore chased the hype
- FOMO further motivated a whole bunch of developers to use Kubernetes for their projects, instead of looking at the alternatives like Docker Swarm or Nomad
- however, knowing Kubernetes can help to be more easily onboarded and to work with deployments in many different companies (except for when it isn't), the skills carry over nicely
Personally, i think something between Docker Swarm, Nomad and K3s would be the sweet spot for containerized app deployments and orchestration, but personally i just like the Docker Compose manifests more than i do Kubernetes' and it feels like the popularity of Helm (or Kustomize) supports this line of reasoning.
Ideally we wouldn't even need containers and something like FreeBSD jails with a user friendly API around it would be sufficient. But the popularity that Docker gained seems to highlight that perhaps something was missing from those older technologies.
I would put money on it being the Dockerfile and the developer UX around that.
I don't honestly find it any more slick to use than e.g. FreeBSD jails, but I've lived in unix for long enough that that's because I was re-using lots of knowledge I already had.
There's a comparison here to the fact that I'm perfectly comfortable writing SysV rc scripts (though BSD rc scripts are vastly more pleasant to put together) but I've watched enough people struggle their way to something that only mostly worked that I can see why for many people writing a systemd unit file instead is a vast improvement.
Pretty much every other option was more closed and with no extensibility, plus docker swarm was plagued (at least from my PoV) with stories of instability... and I dunno about others, but I and various people I talked with were burned with running docker in production, something that k8s nicely repackaged removing a lot of the things that were problematic.
All this went into giving some serious base beyond marketing and PR - the closest I've seen from other players is classic Rancher and Nomad, and especially the latter seems much less capable.
I do ask the same question for all those other systems, or the meta-question: "How is it that the bloated monstrosity of Kubernetes somehow became the de-facto container orchestration tool?"
Is this just sysadmins buying themselves job security?
I could use docker swarm, or nomad, but I have to manage infrastructure, write my own integrations, manage the underlying hardware.
Or I can run az aks create and be off to the races
But how did it get to that point? How did something so big and unwieldy that even billion-dollar cloud providers can't do upgrades on it properly (*cough* looking at you, EKS) become the go-to standard for running apps in containers?
Devs chose K8s, I think the evangelism phrase was “developer dopamine”. It felt like the Rails of DIY infra, where devs could inherit an opinioned pattern for doing n>1.
There’s still decades of resentment of devs being gated by IT.
I'm not seeing anything in their comment that would imply this.
I used it extensively at a job for deploying production replicas for developers and full-integration testing (the plan was to eventually deploy prod the same way). It was SO nice to use. If you could use docker-compose, then docker-swarm was a natural next step.
I can't remember the details (it's been a few years), but the biggest hangup I had was the default network "mesh" wasn't stable. But I was able to work around that by using a different implementation (i think it was the network mesh that came out of k8s at the time. Used etcd).
That and, unfortunately, the cloud vendors could fully deploy k8s for free because swarm was a hybrid enterprise product.
I'd expect the valuation to be lower also, but that's based on their revenue prospects, not their the $ amount of investments.
Because they received an insane valuation years ago and probably aren't even worth break-even on their funding rounds. Google already has far more K8s knowledge internally than anyone at docker, so what would be their gain?
MS did try to buy them back in 2016 but Docker pulled an Jerry* Yang and said no [1]. I don't see why MS would bother at this point, they are also headed down the k8s path, and anything they needed from an expertise perspective they likely already received through their partnership agreement [2].
[1] https://www.sdxcentral.com/articles/news/sources-microsoft-t...
[2] https://www.docker.com/blog/docker-microsoft-partnership/
*I incorrectly said Andrew Yang initially, my apologies for my bad memory and any confusion it may have caused. Thank you Hexcles for the correction.
[1] https://www.cnet.com/news/yahoo-rejects-microsofts-bid/
[2] https://www.forbes.com/sites/briansolomon/2016/07/25/yahoo-s...
*I incorrectly said Andrew Yang initially, my apologies for my bad memory and any confusion it may have caused. Thank you Hexcles for the correction.
As a founder post Series B you probably have at least 10% of the business, that's a nice $400MM payout coming your way.
But if the VC invested at a $1B price, picks up 10% and 80% of their return goes to their LPs they are personally pocketing much less.
So it is advantageous for them to continue to shoot for the stars rather than sell short. Plus they have multiple bets going on at the same time while the founders only have one.
So a $4B acquisition nets the founder $400MM, but and the VC firm is picking up $300MM of which 80% is going back to LPs, leaving $60MM for the partnership, perhaps split 3-7 ways, with maybe a kicker for the partner that sourced and led the investment.
So let's say that's roughly $10MM going to the VC partner.
Well you got one person staring at $400MM and another staring at $10MM.
The interests aren't quite aligned.
Also survivorship bias has us focused on companies that turned down acquisition offers and made it big, like Facebook, Google, Netflix, Snapchat, and so forth, but we don't really hear about the companies that turn down the offer and then fail to meet that acquisition price later, because that story just doesn't sell as well and the company fades into irrelevance so it isn't a piece that is picked up often.
Certainly at the time it could have been a good decision given how new the market was and the potential upside, but obviously hindsight is 20/20.
It is not entrenched at all, that's their problem. You can literally drop in Podman as a replacement and alias the command it it will "just work" - and Podman has some significant advantages in many environments/use cases. Docker, the company or the product, has no concrete barriers to entry to protect itself.
Support SourceHut and pay for hosting git if people want to break away from ostensibly free services. Or pay for Github. SourceHut is also open source.
Edit: I guess I’m on grandfathered (?) GitHub Packages Docker Registry, instead of the newer GitHub Container Registry (which is still in beta?).
Here's a separate thread for "Docker Series B: More Fuel To Help Dev Teams Get Ship Done" - with a bit more info on what the plan is from Scott.
Interesting to see this news on the same day that "We don't need Docker" was also on the front page of Hacker News. I think we absolutely still need Docker in 2021.
I read it as a typical "We don't need [Complex Tool] because we don't have [Complex Tool Solutions] problems". Not trivializing it, I think those articles are valuable hype-free analysis of the latest tool-of-the-day. "They don't need Docker" and "We absolutely need Docker" are non-contradictory.
Red Hat OpenShift also switched from using Docker as its runtime with OpenShift 4 in 2019, though it was in favor of CRI-O rather than containerd.
If a critical mass of kubernetes deployments switched from containerd to cri-o, that would be more problematic for Docker, but that seems unlikely to happen. Openshift to my knowledge is the only major kubernetes distribution not based on containerd. At this stage of the adoption cycle, cri-o is unlikely to be more than a distant second to containerd.
Yes, though not produced by Docker and does not require Docker.
Better to think of these titles as "When you might need Docker" and "When you might not need Docker" so you can consider the tradeoffs rather than interpret it as a blanket statement, Docker is good/bad.
The other is "we don't need Docker because we use tools like buildah, img, or kaniko to build OCI containers, our devs use podman, and we run this stuff in prod on a someone else's k8s PaaS that under the hood is backed by containerd."
Many are anticipating scaling problems they'll never have and wasting a lot of time, effort and money in that process
Yes, it would be possible to get sucked down a rabbit hole with over-emphasizing scaling, clustering, whatever upfront, but IMO these tools are now mature enough that it's a reasonable workflow even if you're just deploying a single instance of a container with one statically-linked binary in it.
God knows how much "don't need JavaScript" gets posted...
People are also totally right to question why some new fancy tool is needed when the old way works. Its best to just view all these things as tools at your disposal rather than necessities.
This is apparently "new/restructured Docker" which did Series A in 2019. From the footnote in the article: https://www.docker.com/press-release/docker-new-direction
It does seem weird to just start the letters over like that, as if it's a new hot startup.
So, yes Docker hit the reset button and wiped out all the existing shareholders.
* The popularized containers but their core tool has been replaced by superior alternatives like Podman.
* They sold their enterprise registry which wouldve earned them actual money.
* The consumer registry has tons of free/cheaper alternatives like github's container registry, something from gitlab and on the enterprise side, there is Red Hat's quay.
* Docker Swarm is dead compared to Kubernetes.
https://www.marketwatch.com/press-release/docker-monitoring-...
1. Launch a container by specifying its image digest, not image ID [0] [1]. You can pull an image with a specific digest, but then it gets an ID that is unique to the image repository. Later deployments must use that different image ID. This makes deployment tooling needlessly complicated. And it breaks the security guarantees of the digest by allowing the repository to modify the image.
2. Copy a file into a container with docker-compose, without requiring Swarm [1].
Do financial problems explain their slowness? I wish they would just charge $100/year per seat for Docker for macOS and then fix the long-standing problems.
And sell a hosted tool to do trusted builds of docker images from hashed sources. Reproducible builds would be great, too.
[0] https://github.com/moby/moby/issues/16482#issuecomment-29782...
[1] https://windsock.io/explaining-docker-image-ids/#contentaddr...
> 2. Copy a file into a container with docker-compose, without requiring Swarm
I'm not quite sure I see why you can't get by with "docker cp" and need compose to resolve the container.
But I also were unaware of the Docker sub commands "cp" and "commit".
I think I prefer building containers and mounting config - but I see how the two could be abused, focusing on images rather than Dockerfile-s (and woe to the person that looses the carefully evolved Debian old-stable based base image that runs a mix of outdated oldstable packages and a few bits from current stable from two years ago when they were in testing, along with a custom build of node 13 and an outdated driver for a proprietary database...).
Not sure I believe it's a good idea, but now I know it's possible.
https://thenewstack.io/container-basics-how-to-commit-change...
All of this becomes so confusing.
I've started with 1 Manager/Worker only and grow from there to 3 managers/workers and later kept the 3 managers and added worker nodes to the cluster.
It made me get into Docker even though for whatever reason I hate anything Docker related.
If you can write Compose files, you can do Docker Swarm - it's so wonderfully simple!
I am increasingly nervous about Swarm support staying in Docker though, and plan to at least look into Nomad for my next project.
I figured apple would latch onto docker and get it running natively, but nobody over there thinks outside the apple ecosystem. It's all like the jackling house
Wouldn't it be cool to say:
FROM macos:10.13.4
RUN xcode-build ...Anyway, happy Docker user here. It changed the way I develop and distribute Python applications. Took me like 2 hours to learn enough to be productive. I'm sure there are better alternatives but Docker just covers my needs, it's well documented and easy to get started, everybody knows it and every cloud platform supports it.
Why? WSL or VM is stupid because it costs around 5-6GB of RAM without doing anything.
My current instance of Ubuntu 20.04 is hogging around 1200MB while running rust-analyzer and some other devtools.
As i tried, wsl need a VM to run.
But i need to spend some times with Windows softwares, too ;)
You can build an image based on a Windows base image, and run it natively in Windows.
Or issued Doggercoin
If anyone at Docker is reading this: Please reconsider your cookie banner implementation.
"Trust arc" I'd trust the site more if it had a sensible cookie policy
I give websites 5 seconds, tops.
On HN it's like - go ahead and let me cable company and cell phone company track / sell and target me on my browsing history (wildly intrusive), but random website doing pet necklaces, try to stay on top of all the popups you need to shove at your users (who will all say OK) so you can show your page.
If you can't share the data you buy up the other companies into groups and then are just using it "yourself" etc.
What is gained, SERIOUSLY, by these stupid pop-ups? I'm serious, has anyone analyzed this? It really shows how the heavy hand of govt has ZERO cost/benefit constraint or analysis. Browsing on phones is particularly painful.
I wish we could just set an accept all cookies header in our browser and govt would let these websites then stop displaying these damn notices, banners and consent boxes.
The GPDR ones (if you use euro websites) are getting even crazier.
Disclosure
I appreciate the ability to allow "required" cookies, but reject all other cookies.
I agree that I would absolutely prefer an HTTP header for cookie preferences instead of pop-ups. But the new cookie popups add some value to me, in letting me allow session authentication cookies, and reject all others.
An outright block on all local cookies tends to break authentication for many sites.
- reject all cookies
- allow only required cookies
- allow all cookies
I absolutely would prefer that to the world we have now. I'm all on board, you don't have to convince me it's a good idea.
But, that doesn't exist today. I do prefer having the stupid annoying popup that gives me the option to allow only required cookies to having no choice at all.
The new GDPR compliant cookie popups give me that option. It's a step up above not having the option at all.
I guess it's for the courts to decide if requiring the same number of clicks but letting you wait for an eternity is equally easy, but I doubt it.
And why call an opt-out endpoint at all, after all there has to be a mechanism that prevents setting the cookie before the user sees the cookie banner. Just continue using that mechanism (e.g. gtag's consent default denied).
This is all posturing. If you want to reduce tracking, use a browser that reduces the tracking. Seriously, just use total cookie protection or something on firefox.
By a corollary, some users DO care about tracking and click "no" to these popups.
Analogy would be like:
Law: you can't store someone's picture or personal data without their consent, unless it's necessary for the transaction.
Most companies: <nag you for consent to store your picture>
GitHub: We authenticate you by your face, so it's necessary to collect that, so we don't need to get your consent for it. Then, once we have it, we do whatever the fudge we want with it.
When I send the next letter, I (or my user agent) can chose to send along the cookie, or not. The server does not force me. This is why the EU cookie law regulating HTTP messages makes no sense.
Also, gdpr consent isn't that particular about implementation. Cookies aren't something special that needs consent. It's their usage.
[0] https://addons.mozilla.org/de/firefox/addon/i-dont-care-abou...
TrustARC is the most evil, dark pattern I have ever encountered. Opting out takes >10 clicks and then it displays a fake progress scanner for over 30 seconds to punish you for opting out (pro tip! just accepting all is instant!).
GDPR is good, having a choice not to be tracked is good. But the pathetic way that websites try to fool you into handing over your data should be punished hard by the EU.
"Please don't complain about website formatting, back-button breakage, and similar annoyances. They're too common to be interesting. Exception: when the author is present. Then friendly feedback might be helpful."
The upvotes are really more the problem than the comment, but please don't post such comments and then such upvotes will have no surface to stick to.
I've said it before, if you're trying to be profitable, that means there must be some part of it that is, "if you don't pay, you don't get it." What is that thing for Docker (a generally very open-sourcey thing), and will it be worth it?
Other engines you might wanna look at: rkt, lxc with an oci template, etc.
Kubernetes with cri-o runs oci containers as well.
It's not rocket science, and podman is obviously a drop-in replacement.
The ssh example is good though - so much depends on ssh, yet how much do we invest in it?