rkt isn't built around systemd. It does use it internally and integrates well with it.
Inside of rkt there is an internal logical separation between the tool that sets up the container filesystems and the one that executes them. We call those things stages[1].
Now inside of rkt we have a few different "stage1" options today:
- systemd: this means that your container has a real init system
- clear containers: execute the container inside of a virtual machine with lkvm.[2]
- direct execution w/ fly: no init system is involved for special privileged containers.[3]
If someone wanted to contribute a stage1 that used a different init system that would be great. But, today systemd works fine and is generally an implementation detail. We also get some bonuses by using systemd on systemd systems like machinectl integration, and journald integration.
Also, I should note that rkt should work on non-systemd systems as well. Again, because, systemd is an internal detail.
Why the systemd hate? Because it's a big monolithic project that takes over your system? You do realize that Docker is much more monolithic and opinionated than systemd, right?
When you ask questions, especially leading ones, it causes a good deal of confusion around the topic at hand. The reasons behind this are complex, but they have something to do with our tendency to double bind each other.
Someone has the right to say why something is "disqualified" for them, even if it is devoid of context. What is awesome here is that the leading expert for this topic is replying directly to the negative (empty) opinion and actually presents a (rich) alternate opinion.
How does you asking unanswerable questions contribute to resolving the conversation to something we can all learn from?
Regardless of their nature, questions are definitely a burden. However, I think the way some questions are put can cause a disproportionate amount of burden when they contain hidden meanings or agendas.
If someone is having issues being direct and use techniques to "hide" how they feel about something in a question, they effectively load the question with intent. I think sometimes those questions can be viral in nature, causing angry memes like what they mention in "This Video Will Make You Angry": https://www.youtube.com/watch?v=rE3j_RHkqJc
Logic would dictate that we should learn to avoid questions which cause excessive amounts of processing with little return in their answers. A simple way to filter on these is to ask if the question conflicts itself when answered in a given way.
Yes, but I will never have to use docker if I don't want to. For that matter, docker doesn't try to be cron, it doesn't want to handle mounting, didn't subsume udev, and doesn't encourage other project to link against it, and to drop all compatibility with non-linux systems. Systemd does, did, and is doing that right now.
Install deps, configure it, done. Looks straightforward, if a tad undocumented.
The thing is, the inside of a docker container is by definition indistinguishable from a regular linux install. Discourse isn't dependent on Docker, not the same way GNOME is dependent on systemd: It just encourages you to use it.
I'm curious what you mean by debug. If you mean monitor all of our apps send metrics, health checks, and logs over the wire I'm sure that is independent.
What would docker allow you over the unikernel especially given the best practice push for docker images to only run one thing in a container?
IMO with Unikernel Xen aka Hypervisors are the container holders instead of docker.
With a Docker container, I can exec into it and run strace, ltrace, gdb etc.. With a unikernel it all depends on what you have built into the unikernel. That might provide everything I need, or not. The issue is that we will need a lot of toolking to put unikernels on a sufficiently equal footing vs. being able to run decades worth of Linux tools directly in the containers.
The issue I have with that is the tooling you mention while stable and mature is actively being replaced by cloud tools because you really can't just debug a single machine in production when you have a cluster.. not to mention it is production so debug symbols might not even be available.
I understand your point of the maturity w/ tooling but I see it as a serious failure if you have to log into a machine in production and run gdb or IMO any tool. Your app can and should provide healthchecks/monitoring so that you can see if there is a problem (this includes even a thread stack dump).
I'm probably just biased and jaded as I have had some serious technical debt lost to Docker. It just feels like a VM on top of a VM on top of a VM of continuous things to break/learn... I want baremetal :)
Opinionated, yes. Monolithic, no. Huge mess of everything that deeply integrates in any system — of course not, your containers don't need to know anything about Docker and host system, you are absolutely free in choices. It's even possible to run (gasp!) multiple services with supervision inside Docker.
That's the first time I ever heard anybody argue that Docker isn't monolothic. It does everything inside it's single daemon executable. Compare against Rocket, which doesn't use a daemon, and uses separate executables for different tasks and stages.
Docker is monolithic, probably more so than it should be, but designed quite well, allowing for things like triton to exist. Systemd is monolithic, but does far more than docker, and really more than it should.
Rocket is not limited to Linux containers. It can also run in VMs. Incidentally there are also solutions to run Docker containers in VMs (Rocket itself should able to, but there are others as well, like hyper.sh)
That is true, however jails lose a lot of power without VIMAGE. VIMAGE is not enabled by default yet, and it's pretty unstable (I use it). I really wish VIMAGE would mature, but we're not there yet.
Technology isn't that important here, it's what stems from it is. Adoption, infrastructure, tools, community.
There's also a price for doing it differently. And believe you me, using BSD nowadays is the definition of doing things differently. What for? What I'm getting for losing my time and reinventing the tools that are already available and much more polished?
Dockerfiles can be replicated. Docker Hub can be replicated. Missing things can be compiled from sources, probably. But all that costs time for little to no gain.
You do realise that "different" platforms can still be popular enough to have a lot of the same ecosystems. Hell, Docker itself used to be the "alternative"; not even that long ago in fact.
FreeBSD might only have a fraction of the community that Linux does, but that's still a pretty large number of developers and sysadmins in real world terms.
There are also some interesting systems build on top of jails. I'm starting to use iocage, which uses both ZFS and jails to manage and create systems with great ease. Better or worse than Docker? It's different. It does some things docker does not, and vice versa. I'm currently in the evaluation stage, and it's likely I'll be using it to replace hand built jails running PostgreSQL, builds and other single-purpose tasks.
Well if someone is competent enough to create a Docker image then it's not a great stretch to assume many of them would also be competent enough to create a jail. And FreeBSD is just as easy to use as Linux (actually, I generally find it easier to administrate than Linux since things are more rigorously laid out. But a lot of that is also down to my own personal preference).
At the end of the day, both Jails and Docker are well documented. So even the people only interested in blindly copying and pasting commands should be able do the basics.
The real problem FreeBSD and jails face isn't with support nor accessibility but rather dumb prejudice. Much like why many Windows users think Linux is difficult. If you spend your whole time shouting that your way of doing things is the best then you're never going to give anything else a fair chance.
Have you used both jails and Docker? Saying docker is a much more polished option doesn't match my experience. Yes, it has more features, but with these features come more bugs. Some of them are minor annoyances. Some are of the "our infrastructure is fucked until we switch our storage driver" kind.
I'm not comparing Docker and jails, I'm talking about things around. Stackoverflow.com coverage, blogs posts and guides, github repos, publicly available images, etc.
> And believe you me, using BSD nowadays is the definition of doing things differently.
... although people like Florian Haas argue that the way that one does things on the BSDs is actually the way that makes sense to do things with Docker, as well, and the way that you think to be "different" is actually the sensible way overall.
Choosing BSD instead of Linux is "doing things differently". I'm talking about popularity and what it means in this whole comment tree, not about technical merits.
That's basically the argument to use Windows and Windows-based technology and not Linux. Everything you can do on any of the UNIX boxes, you can do with Windows. It might be different, but it is still a more popular / supported platform.
Since I'm not a Windows fan, I find value in doing it differently, and so have Linux fans. I think you will find FreeBSD and SmartOS users find the cost in time to bring a large enough gain to satisfy their business requirements.
> That's basically the argument to use Windows and Windows-based technology and not Linux.
Not today it isn't. Years, maybe decades ago it could be.
What Linux containers do is help to remove the barrier that various distributions introduced, it makes things more accessible and it's more lightweight than using virtualization. Centos, Alpine, Ubuntu, whatever. As long as it is in a container I can work with it. I can even run some Windows binaries with Wine inside a container. rkt is largely compatible with Docker infrastructure, so that too is fine.
But what jimktrains2 suggesting is complete opposite of that, it reduces options.
> But what jimktrains2 suggesting is complete opposite of that, it reduces options.
Personally I'd consider having familiarity with more than one platform would increase one's options.
But ultimately having other solutions on the market is a good thing. Not only because no one solution is the best at every metric (be it stability, security, speed, memory usage, nor any specific requirements), nor because different solutions can appeal to different personalities. But mostly because different solutions might solve a problem in a unique way that the competing solutions may not have considered - often in ways that can ported and thus benefit the competitors and wider community.
So I wouldn't be so quick to dismiss anything that's outside your field of expertise.
They don't have to embrace the change they have other options. What bothers me is they chose to shoot down everything and anything that has systemd in it out in the public. Just leave the fight and just embrace your choice and allow others to have their choice and don't pee on their parade.
Exactly that is your choice. I am concerned about the drama of systemd by people that don't like systemd always peeing on every and anything that mentions systemd.
It is in the old rpm vs deb, vim vs emacs, python vs perl dram of the past.
No, it isn't. Nobody is going to try to nuke my emacs install, and install vi on my machine instead. If vi started deleting emacs, or using non-utf8 encodings on all text for some reason, or otherwise made using emacs impossible, the vi developers would fix it, or the community would say, "What the FUCK!?" and probably fork it.
The concept of the community is an abstraction and in this case a bad one. There is no community. There are a million different individuals and within that thousands of communities each composed of some subset of those individuals.
There is no reason each subset or each individual even shouldn't have their own opinion and based their actions upon it.
The very foundation of Open Source / Free Software Movement is 100% community. The very foundation of Closed Source is "There is no community." Community isn't an abstraction but is what has built Linux.
To quote RMS (Who I disagree most of the time but highly respect)
>Tens of millions of people around the world now use free software; the public schools of some regions of India and Spain now teach all students to use the free GNU/Linux operating system. Most of these users, however, have never heard of the ethical reasons for which we developed this system and built the free software community, because nowadays this system and community are more often spoken of as “open source”, attributing them to a different philosophy in which these freedoms are hardly mentioned. http://www.gnu.org/philosophy/open-source-misses-the-point.e...
> There is no reason each subset or each individual even shouldn't have their own opinion and based their actions upon it
100% my point move to your choice and don't pee on systemd every time it is brought up. Your opinion is different then the majority in regards to systemd and you can use those options and not have to discount everyone else's choice.
Inside of rkt there is an internal logical separation between the tool that sets up the container filesystems and the one that executes them. We call those things stages[1].
Now inside of rkt we have a few different "stage1" options today:
- systemd: this means that your container has a real init system
- clear containers: execute the container inside of a virtual machine with lkvm.[2]
- direct execution w/ fly: no init system is involved for special privileged containers.[3]
If someone wanted to contribute a stage1 that used a different init system that would be great. But, today systemd works fine and is generally an implementation detail. We also get some bonuses by using systemd on systemd systems like machinectl integration, and journald integration.
Also, I should note that rkt should work on non-systemd systems as well. Again, because, systemd is an internal detail.
[1] https://coreos.com/rkt/docs/latest/devel/architecture.html#s... [2] https://coreos.com/blog/rkt-0.8-with-new-vm-support/ [3] https://coreos.com/blog/rkt-0.15.0-introduces-rkt-fly.html