| gnu_srs1 | What about taking up the development of vdev? | 00:24 |
|---|---|---|
| golinux | gnu_srs: Maybe start a #vdev channel? IIUC, that is a longer term solution . . . | 00:29 |
| Arsen | there's no real incentive to do that | 00:37 |
| bb|hcb | gnu_srs1: maybe we can package it in Devuan and see how it goes, but it has one major drawback compared to eudev, the later is proven in lots of systems and is the safe way ahead | 00:53 |
| skarnet | oh boy. I just came back home and I'm exhausted so I will not elaborate right now (remind me tomorrow), but there's a lot to unpack here | 01:01 |
| skarnet | the most important thing - Arsen, netbsduser - is that when you start running behind systemd, you have to be aware that *you will never stop* | 01:02 |
| Arsen | I'd love to hear what you mean by that when you're less tired :) | 01:02 |
| skarnet | you obviously don't have to believe me, but freeinit is a red herring | 01:02 |
| skarnet | it's the perfect illustration of the wrong approach | 01:03 |
| skarnet | it is playing systemd's game and it will never win at it. systemd will always be better at being systemd than its clones. | 01:03 |
| Arsen | no, it's how you undertake and replace an established ecosystem | 01:03 |
| skarnet | 1. you will never replace it that way | 01:03 |
| Arsen | keep in mind libsystemd is a very small portion of what makes the mess of systemd what it is | 01:03 |
| skarnet | 2. even if you do, given the way systemd is architectured, what you will end up with *will not be better* | 01:04 |
| skarnet | I don't care about replacing systemd if the replacement isn't better | 01:04 |
| golinux | +1 | 01:04 |
| Arsen | that's arguably not true depending on the definition of better | 01:04 |
| Arsen | again, the interfaces in there aren't very limiting | 01:04 |
| skarnet | one of the ways systemd maintains its hegemony is by enforcing its architecture and policies by encoding them into its APIs | 01:04 |
| skarnet | if you follow systemd's APIs, including libsystemd, your replacement will look exactly like systemd | 01:05 |
| skarnet | you might have a totally independent code base, but it will be infused with poetterspirit | 01:05 |
| skarnet | It's a subtle thing, but I'm not lying when I'm saying I have *studied the thing* | 01:06 |
| netbsduser | i'm intimiately aware that systemd's public APIs are grossly leaky | 01:06 |
| skarnet | it's not only leakiness | 01:06 |
| skarnet | it's how the whole thing is designed | 01:06 |
| Arsen | I'm not sure any design went into it | 01:06 |
| Arsen | if it did, I'm not sure anyone sane was doing it | 01:07 |
| skarnet | there is a method to the madness | 01:07 |
| netbsduser | even sd-event's ridiculous two-stage loop iteration semantics are suffused with the knock-on effects of that. this is where we need to effect a kind of coup | 01:07 |
| skarnet | anyway, to answer quickly before I go take a shower and crash: | 01:08 |
| netbsduser | i see a main goal of libfreeinit as being the offering of superior APIs | 01:08 |
| skarnet | doing EEE on systemd? good luck | 01:09 |
| Arsen | (also, decouple freeinit from libfreeinit, there's a difference, the latter is a result of the former) | 01:09 |
| skarnet | even if it succeeds the result will be frankensystemd | 01:09 |
| skarnet | not something I want on my system | 01:09 |
| netbsduser | oh, sure, the odds are ill in our favour, but with things like sd-event and sd-bus, i am quite sure we can make a difference | 01:09 |
| skarnet | so | 01:10 |
| skarnet | sd_notify, as with everything systemd, is overengineered | 01:10 |
| Arsen | I'm not convinced, though, that libsystemd apis are strongly stupid enough to force internals to adjust | 01:10 |
| netbsduser | these things win by offering a particular set of useful characteristics like OOM resilience and, crucially, they are available everywhere* (where everwhere is "all the systemd-powered distros") | 01:10 |
| skarnet | blah blah | 01:10 |
| Arsen | you sure you didn't miss a word, I doubt it should be limited to only sysd-powered distros | 01:11 |
| netbsduser | libfreeinit must be low enough in cost to be similarly compelling | 01:11 |
| skarnet | I believe in OOM resilience when I see programs that don't use heap memory | 01:11 |
| skarnet | I don't think libfreeinit will do that | 01:11 |
| skarnet | anyway, to finish before I go | 01:11 |
| skarnet | - s6 provides its own notification protocol, that's simpler to implement than sd_notify | 01:12 |
| skarnet | - I have a program, sdnotify-wrapper, that can be used to wrap a daemon using the sd_notify protocol to run under s6 | 01:12 |
| skarnet | and that piggybacks sd_notify into the s6 notification system | 01:12 |
| skarnet | so anything that uses sd_notify, you can use under s6 (but it's obviously less efficient than if you use the s6 protocol directly) | 01:13 |
| Arsen | I'd hope status notifications are infrequent enough for that to not be an issue | 01:13 |
| netbsduser | and that plays right into the awful situation where daemon authors like to link against libsystemd | 01:14 |
| skarnet | continuous status notifications are useless, only readiness notification is useful | 01:14 |
| skarnet | - what systemd calls "socket activation" is a mix of several different things with different semantics so I don't like this terminology, it is unclear | 01:14 |
| netbsduser | i'd rather they link against something that will let them give systemd their status messages and suchlike, or just as well write a newline into the s6 notification fd and close it (i think i remember that as being what one does) | 01:15 |
| Arsen | yet, even with that, it underwhelms what socket activation could do | 01:15 |
| skarnet | s6 provides implementation of all these parts, but separates what is semantically different | 01:15 |
| skarnet | * it provides super-servers for inetd-style daemons | 01:16 |
| skarnet | * itr provides fd-holding for programs to store and retrieve live file descriptors such as sockets | 01:16 |
| skarnet | * it provides tools to preopen sockets, if needed, but it's a terrible idea (it cheats readiness) | 01:17 |
| skarnet | the way systemd achieves speed is by cheating readiness, preopening stuff and launching services before it's safe to do so | 01:18 |
| skarnet | s6 and s6-rc don't do that | 01:18 |
| Arsen | systemds claim about speed here are questionable frankly | 01:18 |
| Arsen | I'm very unconvinced in the argument for socket activation for performance purposes | 01:18 |
| netbsduser | i am entirely unconvinced that speed is a real merit of socket preopening | 01:18 |
| skarnet | oh, it is relatively fast - faster than anything you can achieve with a serial service manager anyway | 01:19 |
| skarnet | yeah, you're right to be unconvinced | 01:19 |
| Arsen | yes, but the word "serial" is a key part of it, nothing to do with sockets | 01:19 |
| skarnet | socket activation is only one of the ways systemd cheats | 01:19 |
| skarnet | the most crucial cheat is logging | 01:20 |
| skarnet | it starts stuff before the loggers are ready | 01:20 |
| skarnet | so if loggers eventually fails, boom, your initial logs are lost | 01:20 |
| netbsduser | i think Zarzycki who invented launchd had an interesting notion - launchd has no dependency logic whatsoever, it gets a helper daemon to preopen sockets and then one or two eagerly-started services set the ball rolling that ultimately triggers all the services to come up. but systemd in marrying that to traditional dependency-based startup gains little | 01:21 |
| skarnet | well s6-rc is faster that that without cheating :P | 01:23 |
| skarnet | https://skarnet.org/lists/supervision/2815.html shows a *slight* increase in speed when switching from systemd to s6-rc: 4-4.5% faster, which is not impressive | 01:23 |
| skarnet | but the interesting part is that with s6-rc there's no cheating at all | 01:24 |
| netbsduser | i picked up an old mac recently to port some software to, and it's certainly not going to win any awards for fast bootup | 01:24 |
| skarnet | you'll never lose logs, you'll never fake readiness | 01:24 |
| skarnet | well launchd isn't exactly lightweight | 01:24 |
| skarnet | anyway, ping me tomorrow. Good night everyone! | 01:25 |
| Arsen | sleep well | 01:26 |
| bb|hcb | :) | 01:26 |
| netbsduser | cheers. i have a lot of respect for the daemontools approach to supervision and i like how you keep that spirit with s6-rc. have a good night | 01:27 |
| joerg | Arsen: >> I don't think that's how find works<< right. would need a sh -c "weirly escaped command line". I found `rename` though, might do what I need | 01:28 |
| bb|hcb | I am leaving the old pad for kids to play with it as much as they please :) The new one is here: https://pad.dyne.org/pad/#/2/pad/edit/OxndgL71YfgX8ypl5BC2kuT9/p/ | 04:43 |
| Ariadne | hi | 17:30 |
| netbsduser | afternoon | 17:34 |
| Arsen | 0/ | 17:37 |
| Arsen | Ariadne: did you see the discussion from last night? I'd also like some Alpine insight into that | 17:38 |
| golinux | It seemed a little out of scope for this channel. | 17:49 |
| golinux | Which is to maintain eudev. | 17:50 |
| Ariadne | Arsen: about what? alpine's position is that we trust skarnet to build a good init system | 17:52 |
| netbsduser | golinux: you can't possibly regard this as having nothing to do with the broader question of breaking systemd's domination over our community | 17:57 |
| Arsen | Ariadne: right, so I imagine alpine has no interest in eudev past the point of adapting mdev? | 18:00 |
| Arsen | mdevd* | 18:00 |
| Arsen | the topic was about replacing udevs libsystemd with a standalone, portable implementation and removing other importabilities in udev itself | 18:00 |
| Ariadne | i would be in favor of that | 18:01 |
| Ariadne | but yes, alpine plans to adapt mdevd in future | 18:01 |
| Arsen | right | 18:01 |
| golinux | netbsduser: Everything has something to do with something else. For our purposes here the focus is eudev. | 18:04 |
| Arsen | another thing, the freestanding implementation (which has been dubbed libfreeinit, and is a project that netbsduser wishes to undertake) is meant to provide a bridge between systemd and saner systems, and to slowly replace libsystemd in daemons that rely on it (for instance, those that use sd-bus or sd-daemon) | 18:04 |
| Arsen | giving first class support to "alternative" init schemes | 18:05 |
| Arsen | alpine could find use in that | 18:05 |
| golinux | But take that with a grain of salt because my association with Linux is ethical and philosophical more than technical. | 18:06 |
| Arsen | golinux: there's absolutely a technical connection between eudev and such a project | 18:07 |
| golinux | Also note that bb|hcb is away for the weekend so unable to participate in this discussion. | 18:07 |
| Arsen | that is alright, so am I, I just happen to have a laptop with me :P | 18:07 |
| Arsen | anyway, when I started looking into updating eudev to be on-par with systemd-udevd, the goal I had was to minimize the maintenance effort and increase the rate at which patches can be applied to eudev from the upstream tree | 18:08 |
| * golinux is always wired | 18:08 | |
| Arsen | I managed to reduce that maintenance effort to - fixing merge conflicts, and - maintaining a libsystemd replacement in-tree | 18:09 |
| netbsduser | the crucial element being the introduction of some saner standards. systemd's LISTEN_FDS/LISTEN_FDNAMES are tedious, for example. it would be prudent to define something better | 18:09 |
| Arsen | the latter part would be put out of tree and made more universal with netbsduser's project, which came to conception a few weeks after I undertook the original effort, which was the same day (or the day after?) eudev was announced as retired | 18:09 |
| netbsduser | that's the part of libfreeinit which is really important. in the meantime, i'd like daemon authors to stop linking libsystemd and start linking a library whose purpose is to provide some more universal abstractions over the differences between various service managers, where possible | 18:10 |
| Arsen | that's the connection that makes this discussion an on-topic one | 18:10 |
| Arsen | now, of course, we don't want libfreeinit to be *just* a libsd replacement, but we don't want to cause further divergence in the ecosystem and cause issues, instead allowing for a smooth transitional path towards better apis than what systemd has to offer | 18:11 |
| Arsen | which is almost in-line with what seatd does, just a little farther, libseat doesn't provide a backwards compatible api | 18:12 |
| joerg | hmm | 19:43 |
| joerg | even closer? | 19:43 |
| skarnet | netbsduser: | 20:04 |
| skarnet | (spurious enter key) | 20:05 |
| skarnet | I'd be interested in having you over in #s6 on OFTC, in order to discuss details of the functionality you need from LISTEN_FDS and other parts of socket activation, and see if there's something missing in s6 wrt that, and maybe design a sane protocol you can implement in libfreeinit that you can add a sd_listen* stub over | 20:07 |
| skarnet | more generally if the point of libfreeinit is to ease the transition from systemd APIs to saner systems, as opposed to running behind systemd, then it's something I'm interested in and want to have technical discussions about | 20:08 |
| netbsduser | skarnet: already there ;) | 20:12 |
| skarnet | oh groovy :D | 20:13 |
| Arsen | exciting! | 20:21 |
| skarnet | Arsen: I see you're there too, and twice even XD | 20:22 |
| Arsen | the single one was taken :P | 20:23 |
| Arsen | though the person hadn't logged in in about a decade | 20:23 |
| Arsen | might ask to have it merged into my account | 20:23 |
| joerg | (re freenode->libera) is doch immer der selbe scheiss, der teufel steckt im detail http://reisenweber.net/irclogs/libera/_eudev/search?q=fooo | 23:51 |
| joerg | oops sorry, ECHAN | 23:52 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!