4 ms·
How do you live without docker containers? The fact that docker doesn’t run on BSDs is what drove me away.
by atmosx 8y ago
How do you live without docker containers? The fact that docker doesn’t run on BSDs is what drove me away.
- yellowapple 8y ago...the same way the world has managed to survive for decades without Linux containers in general (let alone specific wrappers around that like Docker is)? With OpenBSD specifically, you can get 90% of the way there with chroots, standard process isolation, and a bit of shell scripting to handle deployment automation. Yeah, Docker's cool, but it's really not that hard to run multiple applications/services on the same physical machine while keeping them from clobbering each other or the OS in general (step 1 being to make sure each service/daemon is running under its own minimally-privileged user).
- toyg 8y ago> With OpenBSD specifically, you can get 90% of the way there with chroots, standard process isolation, and a bit of shell scripting This is a classic case of "THAT HackerNews response to Dropbox" [1]. If it's that easy, why isn't there a prepackaged wrapper with simple switches, rather than leaving developers to fight for themselves among piles of custom hacks? The problem is not just deployment, the Docker differentiation is simplification of the development pipeline. OpenBSD should seriously look at their story in that area, because it's one of the few where they could still potentially compete (because Docker is still fundamentally a pile of hacks, and pretty insecure too). Unless, of course, everyone is happy to remain "the little project that could" and crack jokes like the BCHS stack. [1] https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224
- smhenderson 8y agoOpenBSD should seriously look at their story in that area, because it's one of the few where they could still potentially compete (because Docker is still fundamentally a pile of hacks, and pretty insecure too). I’m pretty sure the Open BSD developers are completely comfortable with their story. They develop this software for themselves first. If you like it and it’s useful to you you are welcome to it. If not, look elsewhere. That’s been their working philosophy all along and if you ask me that’s what makes it so great to use. Every piece of the system is carefully thought out and organized so it doesn’t suffer from nearly as much feature creep as other systems. And as far as setting up chroit and isolating processes; it’s not hard and sometimes you don’t need someone else to write a script for you when you can do it yourself in 10 steps or less.
- toyg 8y ago> I’m pretty sure the Open BSD developers are completely comfortable with their story. They were pretty comfortable with their patching story -- until enough people complained and lo, syspatch(8) appeared. Beyond the posturing, nobody likes to run a project that nobody else uses; and sometimes even lusers are right. > Every piece of the system is carefully thought out and organized I am not saying they should rush out a crap docker clone, but rather a "carefully thought out and organized" docker alternative. > you can do it yourself in 10 steps or less. It's still 5x the steps you need with docker. As I said, it's about simple reproducibility rather than just isolation. Even if it were easy to write my own docker-compose (and indeed many people argued the same, when docker first emerged, because it actually was little more than shell scripts), having one well-defined set of tools helps tremendously with kickstarting adoption and to avoid reinventing the wheel every few weeks.
- ams6110 8y agoI would be surprised if user complaints were the motivation for syspatch. More likely, the author built something he found useful, and contributed it to the project. Most of the time on the openbsd email list, when a "user" suggests a feature or asks for a change to something, the reply is something along the lines of "sounds great, where is your patch?"
- toyg 8y ago> More likely, the author built something he found useful, and contributed it to the project. It required a service set up by the project itself. And this after years (decades?) of explicitly rejecting the concept of automated patching (because it supposedly engendered "a false sense of security"). Come on.
- sverige 8y agoExactly this. Unless of course you became an Iridium level donor with the caveat that someone promised to build a Docker clone for you. Edit: And in response to toyg's comment, here is a link to a video of a talk by the developer in question, who mentions in passing that he builds things for OpenBSD that help him put it into production. This is less than a minute into his talk. Please educate yourself about the project before making ridiculous demands on the devs' time and falsely assigning wrong motives to them. It's unfriendly. https://archive.fosdem.org/2018/schedule/event/openbsd_base_system_maintenance_made_easy/ https://archive.fosdem.org/2018/schedule/event/openbsd_base_...
- yellowapple 8y ago"simplification of the development pipeline" In my experience, "simplification" and "Docker" don't really go in the same sentence. Yeah, it's (maybe) simpler if you're just plugging things together that are already Dockerized, but if you're writing your own Dockerfiles, none of the actual complexity really goes away. If anything, you're making things even more complex by containerizing things that don't actually need containerized. "why isn't there a prepackage wrapper" Because nobody's gotten around to writing one yet, or perhaps because nobody's felt the need to do so yet. Not much stopping anyone from doing so. That's where the "bit of shell scripting" comes in. Writing an rc.d script [1] (using rc.subr to do away with the boilerplate normally associated with the sorts of initscripts normally strawmanned by systemd advocates) ain't any harder than writing a Dockerfile (in my opinion it's actually much nicer/simpler). Neither is creating a user under which your app will run. Hardest part will probably be around deciding what needs to go in your chroot. Hell, if you include OpenBSD packaging [2] as part of that development pipeline, then tada, you're pretty much there. Install the package, run "rcctl enable your-app-name && rcctl start your-app-name", and you're good to go. So the trick here would then be to extend that to install and run multiple isolated copies of that package, each instance having its own configuration and chroot. Or perhaps using a single package and writing your service/app such that it does the forking/chrooting for each isolated environment (which is what quite a few OpenBSD-focused daemons already do, from what I can tell/observe). The overall point, though, is that comparing Docker to Dropbox is erroneous. Dropbox actually was simpler/easier than the "solution" posed by that comment. Compared to the OpenBSD way of doing things, Docker is not; if anything, it's more complexity. [1]: https://www.openbsd.org/faq/ports/specialtopics.html#RcScripts https://www.openbsd.org/faq/ports/specialtopics.html#RcScrip... [2]: https://www.openbsd.org/faq/ports/guide.html https://www.openbsd.org/faq/ports/guide.html
- nineteen999 8y agoPlenty of people live just fine without docker containers, even in the Linux world.
- fabioyy 8y agoPlenty of people lived just fine without the industrial revolution, scientific method, cellphones, computers, fire...
- nineteen999 8y agoNone of which were branded Docker(TM) - https://www.docker.com/legal/trademark-guidelines https://www.docker.com/legal/trademark-guidelines Don't get me wrong, sure it has its uses, but to pretend that Docker(TM) is just as big a leap (or as essential) as any of those things is laughable.