Gregory's ServerAnd ssh-via-AF_VSOCK is precisely what we are doing in systemd v256: a small new unit generator (i.e. a plugin that extends systemd's unit tree dynamically) detects if AF_VSOCK is available and sshd is installed, and if so binds AF_VSOCK/port 22 to sshd, via socket activation. Or in other words: in environments where AF_VSOCK is a thing, sshd will now *just* work, without any extra configuration and at minimal cost of resources (because lazy socket activation rocks).
|
3 comments
 @ska dunno, this is free software, do whatever you want with our software. Use it or don't. It's all LGPL. Hacking up the ssh thing within our framework was easy, I wrote the generator and the proxy in 1h or so, since the building blocks are all there already. If you care about other OSes and so on, that's entirely OK by me. Take our code, or take inspiration from it, or take nothing at all. It's all entirely fine, but please don't pretend that we just did this within our own framework out… @ska … of malice. We just did it because it's easy given all the building blocks we need already exist in our framework, ready to use. I mean, there's a reason you have your own C library with tools, because you don't want to write all the basic building blocks from scratch either all the time. If you did that then this 1h job takes a *lot* longer. We do not share the same goals, so much is obvious, but always implying we do everything out of malice, is just getting badly on my nerves. |
@pid_eins So. A thread.
Here we have yet another perfect example of the systemd modus operandi:
1. Take a genuinely good core idea, e.g. take advantage of the genericity and simplicity of Unix design and the willingness of Linux to follow it.
2. Add some low-value functionality to make it look like only systemd can provide the good core idea, and tie it in with existing systemd functionality, in as integrated a fashion as possible.
3. Profit: now, people who want to use the new functionality are locked in with systemd!
This is why systemd is so successful, why it has so much adoption despite having been so controversial for more than a decade. This is how it works: doing good things, but the systemd way. If you want the good things, you need to opt into the whole model. And since lots of people use systemd, it snowballs: people won't bother writing other ways of using the good things because systemd already provides them! And so, a monoculture is born, and people who question it are marginalized: what's wrong with you, don't you like good things?
Yes, Janet, I do like good things, and I wish I could get them and *only* them. So, let's analyze this example to see how this could be done.
@pid_eins So. A thread.
Here we have yet another perfect example of the systemd modus operandi:
1. Take a genuinely good core idea, e.g. take advantage of the genericity and simplicity of Unix design and the willingness of Linux to follow it.
2. Add some low-value functionality to make it look like only systemd can provide the good core idea, and tie it in with existing systemd functionality, in as integrated a fashion as possible.