[HN Gopher] Varlink - IPC to replace D-Bus gradually in systemd
___________________________________________________________________
Varlink - IPC to replace D-Bus gradually in systemd
Author : synergy20
Score : 59 points
Date : 2024-09-29 13:51 UTC (9 hours ago)
(HTM) web link (varlink.org)
(TXT) w3m dump (varlink.org)
| c0balt wrote:
| That looks interesting, I especially appreciate the intentional
| design decision for documentation and schemas. While it didn't
| work quite well with dbus Ime it is still a good idea to make
| APIs more accessible.
| newpavlov wrote:
| So Varlink requires a proper specification of message types, but
| then uses god damn JSON to serialize messages? Why would you do
| that?
|
| Apparently, we don't have enough wasted cycles in modern
| software, just add a bunch more in a fundamental IPC
| infrastructure.
| nbbnbb wrote:
| Lets take it a level up. I'm still not sure why we even need a
| message bus in there in the first place. The whole Linux boot,
| init, systemd pile is a Rube Goldberg machine that is very
| difficult to understand at the moment. The only reason I
| suspect most people aren't complaining is that our abstraction
| level is currently a lot higher (docker / kubernetes etc) and
| machines are mostly ephemeral cattle and few people go near it.
|
| As for JSON, please don't even start me on that. It is one of
| the worst serialisation decisions we ever made as a society.
| Poorly defined and unreliable primitive types, terrible schema
| support and expensive to parse. In a kernel, it does not
| belong! Give it a few months and varlink will be YAML over the
| top of that.
| otabdeveloper4 wrote:
| > I'm still not sure why we even need a message bus in there
| in the first place.
|
| Because traditional POSIX IPC mechanisms are absolute
| unworkable dogshit.
|
| > It is one of the worst serialisation decisions we ever made
| as a society.
|
| There isn't really any alternative. It's either JSON or "JSON
| but in binary". (Like CBOR.) Anything else is not
| interoperable.
| nbbnbb wrote:
| This is a quite frankly ridiculous point. Most of that garb
| came from the HPC people who built loads of stuff on top of
| it in the first place. It's absolutely fine for this sort
| of stuff. It's sending the odd little thing here and there,
| not on a complex HPC cluster.
|
| As for JSON, are you really that short sighted that it's
| the only method of encoding something? Is _" oh well it
| doesn't fit the primitive types, so just shove it in a
| string and add another layer of parsing"_ acceptable? Hell
| no.
| otabdeveloper4 wrote:
| > ...it's the only method of encoding something?
|
| If you want something on the system level parsable by
| anything? Yes it is.
| nbbnbb wrote:
| protobufs / asn.1 / structs ...
|
| Edit: hell even XML is better than this!
| baq wrote:
| Thank goodness they didn't pick YAML though.
| nbbnbb wrote:
| Yet!
| RandomThoughts3 wrote:
| Structs are a part of C semantic. They are not an ipc
| format. You can somewhat use them like one if you take a
| lot of precaution about how they are laid out in memory
| including padding and packing but it's very brittle.
|
| Asn.1 is both quite complicated and not very efficient.
|
| They could certainly have gone with protobufs or another
| binary serialisation format but would it really be better
| than the current choice?
|
| I don't think the issue they are trying to solve is
| related to serialisation anyway. Seems to me they are
| unhappy about the bus part not the message format part.
| dfox wrote:
| ASN.1 BER/DER is more or less the same thing as CBOR. The
| perceived complexity of ASN.1 comes from the schema
| language and specifications written in the convoluted
| telco/ITU-T style (and well, the 80's type system that
| has ~8 times two different types for "human readable
| string").
| jchw wrote:
| There are a world of serialization formats that can offer a
| similar interoperability story to JSON or JSON-but-binary
| formats. And sure, implementing them in every language that
| someone might be interested in using them in might require
| complication, but:
|
| - Whatever: people in more niche languages are pretty used
| to needing to do FFI for things like this anyhow.
|
| - Many of them already have a better ecosystem than D-Bus.
| e.g. interoperability between Protobuf and Cap'n'proto
| implementations is good. Protobuf in most (all?) runtimes
| supports dynamically reading a schema and parsing binary
| wire format with it, as well as code generation. You can
| also maintain backwards compatibility in these formats by
| following relatively simple rules that can be statically-
| enforced.
|
| - JSON and JSON-but-binary have some annoying downsides. I
| really don't think field names of composite types belong as
| part of the ABI. JSON-like formats also often have to try
| to deal with the fact that JSON doesn't strictly define all
| semantics. Some of them differ from JSON is subtle ways, so
| supporting both JSON and sorta-JSON can lead to nasty side-
| effects.
|
| Maybe most importantly, since we're not writing software
| that's speaking to web browsers, JSON isn't even
| particularly convenient to begin with. A lot of the
| software will be in C and Rust most likely. It helps a bit
| for scripting languages like Python, but I'm not convinced
| it's worth the downsides.
| otabdeveloper4 wrote:
| Sorry, but bash isn't a "niche language" and it doesn't
| have an FFI story.
| jchw wrote:
| I don't know how to tell you this, but, you don't need to
| implement an RPC protocol in bash, nor do you need FFI.
| You can use CLI tools like `dbus-send`.
|
| I pray to God nothing meaningful is actually doing what
| you are insinuating in any serious environment.
| eep_social wrote:
| Behold, FFI for bash: https://github.com/taviso/ctypes.sh
| jchw wrote:
| I think it doesn't have to be a message _bus_ per-se, that
| design decision is mostly just because it 's convenient. Even
| D-Bus can actually be used without the bus, if you really
| want to.
|
| D-Bus is just a bus so it can solve a bunch of different IPC
| problems at the same time. e.g. D-Bus can handle
| ACLs/permissions on RPC methods, D-Bus can handle multiple
| producers and multiple consumers, and so on. I think
| ultimately all that's really needed is IPC, and having a
| unified bus is just to allow for some additional use cases
| that are harder if you're only using UNIX domain sockets
| directly.
|
| If there are going to be systemd components that have IPC,
| then I'd argue they should probably use something standard
| rather than something bespoke. It's good to not re-invent the
| wheel.
|
| Not that I think Varlink is any better. It seems like at
| _best_ it 's probably a lateral move. I hope this does not go
| forward.
| nbbnbb wrote:
| _> If there are going to be systemd components that have
| IPC, then I 'd argue they should probably use something
| standard rather than something bespoke. It's good to not
| re-invent the wheel._
|
| This is my point.
|
| My favourite DBus situation a number of years ago was a
| CentOS 7 box that reboot stopped working on with a cryptic
| DBus error that no one has ever seen before. I had to sync
| it, power cycle the node from the ILO card and cross my
| fingers.
|
| I really don't give a shit about this. I just wanted to run
| my jobs on the node, not turn into a sysadmin due to
| someone else's dubious architectural decisions.
| jchw wrote:
| Yes but the systemd developers don't want to implement
| their own protocols with e.g. ACL checking, and given
| some of their track record I kind of think you don't want
| them to, either. I'm pretty sure the error conditions
| would be even more bespoke if they "just" used UNIX
| domain sockets directly. Don't get me wrong, there's
| nothing particularly wrong with UNIX domain sockets, but
| there's no "standard" protocols for communicating over
| UDS.
| amluto wrote:
| This is systemd we're talking about. A service manager
| that _already_ mucks with mount namespaces.
|
| It would be quite straightforward to map a capability-
| like UNIX socket into each service's filesystem and give
| it a private view of the world. But instead...
|
| > Public varlink interfaces are registered system-wide by
| their well-known address, by default
| /run/org.varlink.resolver. The resolver translates a
| given varlink interface to the service address which
| provides this interface.
|
| ...we have well known names, and sandboxing, or replacing
| a service for just one client, remains a mess. Sigh.
| nbbnbb wrote:
| Well there sort of is but people don't tend to know or
| use it. If it's within the same machine and architecture,
| which should be the case for an init system, then a fixed
| size struct can be written and read trivially.
| jchw wrote:
| C structs are a terrible serialization format, since they
| are not a serialization format at all. Nothing guarantees
| that you will get consistent struct behavior on the same
| machine, but also, it only really solves the problem for
| C. For everything else, you have to duplicate the C
| structure exactly, including however it may vary per
| architecture (e.g. due to alignment.)
|
| And OK fine. It's not _that_ bad, most C ABIs are able to
| work around this reasonably OK (not all of them but sure,
| let 's just call it a skill issue.) But then what do you
| do when you want anything more complicated than a
| completely fixed-size type? Like for example... a string.
| Or an array. Now we can't just use a struct, a single
| request will need to be split into multiple different
| structures at the bare minimum.
|
| And plus, there's no real reason to limit this all to the
| same machine. Tunneling UNIX domain sockets over the
| network is perfectly reasonable behavior and most* SSH
| implementations these days support this. So I think
| scoping the interoperability to "same machine" is
| unnecessarily limiting, especially when it's not actually
| hard to write consistent de/serialization in any
| language.
|
| * At least the ones I can think of, like OpenSSH[1], Go's
| x/crypto/ssh[2], and libssh2[3].
|
| [1]: https://www.openssh.com/txt/release-6.7
|
| [2]: https://pkg.go.dev/golang.org/x/crypto/ssh#Client.Li
| stenUnix
|
| [3]: https://github.com/libssh2/libssh2/pull/945
| nbbnbb wrote:
| Note within the domain of this problem was the point.
| Which means on the same machine, with the same
| architecture and both ends being C which is what the init
| system is written in.
|
| You are adding more problems that don't exist to the
| specification.
|
| As for strings, just shove a char[4096] in there. Use a
| bit of memory to save a lot of parsing.
| jchw wrote:
| > You are adding more problems that don't exist to the
| specification.
|
| D-Bus does in fact already have support for remoting, and
| like I said, you can tunnel it _today_. I 'm only
| suggesting it because I have in fact tunneled D-Bus over
| the network to call into systemd specifically, already!
|
| > As for strings, just shove a char[4096] in there. Use a
| bit of memory to save a lot of parsing.
|
| OK. So... waste an entire page of memory for _each
| string_. And then we avoid all of that parsing, but the
| resulting code is horribly error-prone. And then it still
| doesn 't work if you actually _want_ really large
| strings, and it also doesn 't do much to answer arrays of
| other things like structures.
|
| Can you maybe see why this is compelling to virtually
| nobody?
| bsder wrote:
| > As for strings, just shove a char[4096] in there.
|
| For the love of God, use a proper slice/fat pointer,
| please.
|
| Switching over to slices eliminates 90%+ of the issues
| with using C. Carrying around the base and the length
| eliminates a huge number of the overrun issues
| (especially if you don't store them consecutively).
|
| Splitting the base and the offset gives a huge amount of
| semantic information and makes serialization _vastly_
| easier.
| therein wrote:
| Yeah, how will number/float serialization go? Are we going to
| serialize them as strings and parse them? That abstraction
| isn't handled the same way across multiple languages.
| jchw wrote:
| Unfortunately I concur.
|
| There _are_ a lot of problems with D-Bus, but that it wasn 't
| using JSON wasn't one of them.
|
| The tooling for D-Bus is terrible. It has composite types but
| they are very primitive, e.g. you can't name fields in a
| structure without extensions (there's like three different
| extensions for this.) A lot of the code generators can't
| actually handle real-world schemas.
|
| Now I understand that D-Bus _itself_ is also a problem (as in,
| the protocol design beyond serialization) but varlink looks
| like a very solid step backwards. In any single individual use
| case JSON serialization is unlikely to be a huge bottleneck,
| but in practice if this will be used for all kinds of things it
| will add up.
|
| I really wish the Linux desktop would coalesce around something
| like Cap'n'proto for serialization.
|
| P.S.: It'd probably be possible to shoehorn in multiple formats
| but I think that's a mistake too. Something like capnp will
| have a strong impedance mismatch with JSON; mixing formats with
| different degrees of self-describability is unwise. But then
| formats like MsgPack and BSON which are direct JSON analogues
| miss out on the best benefits of using binary serialization
| formats, which makes them almost the worst of both worlds, and
| you'd probably be better off with using a highly-optimized JSON
| library like simdjson.
| arianvanp wrote:
| CBOR is the obvious choice here.
|
| I've suggested it before and the systemd folks didn't seem
| completely opposed to it. Also because cbor parser is already
| in the dependencies due to FIDO2 disk unlocking
| theamk wrote:
| What is the data rate (messages, bytes) that you expect for
| this "D-Bus replacement protocol"?
|
| Which fraction of CPU will JSON ser/des will take to
| justify using CBOR?
| akira2501 wrote:
| I genuinely dislike CBOR. Formats which require me to
| calculate the length of the message before sending it lead
| to bad library design which often leads to easily
| compromised code. Add in an "indefinite length" option and
| you've got potentially unbounded client memory usage to
| watch out for. As if that wasn't enough you get extensible
| tags so the meaning of any message is entirely dependent on
| the context it was sent in.
|
| It gives you a lot of decent protocol wire design and then
| flatly ignores everything we've learned about these types
| of designs in the last 3 decades. Be on the lookout for
| client libraries to slowly add in all of these checks as
| the vulnerabilities are discovered in them.
| formerly_proven wrote:
| That'd be "I can't believe it's not msgpack with extra
| design flaws and the name changed to my own name" CBOR?
| nly wrote:
| It's not the data format that is important, but the
| tooling, code generation and binding quality.
| deivid wrote:
| There was a Varlink talk[0] a few days ago at All Systems Go,
| in that talk, Lennart mentioned that JSON is unfortunate
| (primarily due to no 64 bit ints) but it has the surprising
| benefit of being able to understand the bus messages when using
| `strace` for debugging.
|
| [0]:
| https://www.youtube.com/watch?v=emaVH2oWs2Y&list=PLWYdJViL9E...
| gmokki wrote:
| I do not understand where the 64bit integers not working with
| JSON comes from.
|
| JSON the format had no limit on integer size. And all Java
| JSON libraries I know can handle arbitrary prevsion integers
| (BigInt) and 32/64bit int/long types when serializing and
| deserializing.
|
| Quick googling shows that also JavaScript has proper support
| for 64bit integers with their BigInt type, and it can be used
| to deserialize incoming data correctly with the default
| parser, albeit requiring a bit more work to annotate the
| fields.
|
| Personally I often explicitly make sure that the integers I
| return in trust environments as identifiers in REST APIs are
| by default longer than 52bits so that buggy parser libraries
| are caught early.
| GrayShade wrote:
| Qt refused for almost a decade to support deserializing
| 64-bit integers from JSON because of compatibility
| concerns.
| Spivak wrote:
| jq couldn't handle them until relatively recently. This
| isn't a few bad parsers. You can't assume a json parser
| will handle bigints correctly and when you're angling to
| be low-level plumbing and work with every language and
| software that hasn't been recompiled in years you have to
| be pretty conservative in what you send.
| capitainenemo wrote:
| The number type in JSON is 64 bit float, limiting integers
| without loss of precision to 253-1.
|
| BigInt is a new concept and not technically supported. So
| whether it works in your random library of choice is
| probably a potshoot. "Use within JSON: Using
| JSON.stringify() with any BigInt value will raise a
| TypeError, as BigInt values aren't serialized in JSON by
| default. " https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| IshKebab wrote:
| That's not true. The number type in JSON is an arbitrary
| sized number. You're thinking of JavaScript which is not
| the same thing.
| capitainenemo wrote:
| https://datatracker.ietf.org/doc/html/rfc7493#section-2.2
| No.
| theamk wrote:
| If you fully work within a trusted environment, why bother
| with JSON? Use your favorite binary serialization with
| codegen.
|
| The whole point of JSON is almost every programming
| language can read and write it - and if you want this to be
| the case, stringify anything unusual, like large integers.
| anotherhue wrote:
| With this logic (oft repeated) we should be sending TCP as
| JSON. { sourcePort: 443, destinationPort: 12345,...}
|
| Debugability is important but the answer is to build
| debugging tools, not to lobotomise the protocol for the
| vanishingly tiny fraction of packets that are ultimately
| subject to debugging.
| brookst wrote:
| I love your TCP over JSON idea. Maybe we can implement
| layer 2 that way as well, with CSMA/CD:
| {startTime:2024-09-29T13:56:21.06551,
| duration:00:00:00.0024, packet: ...}
| jsnell wrote:
| I've done similar things in the past (json over udp-to-
| localhost, with a schema description used to generate the code
| for both parsing and generating on each end). It's a totally
| reasonable point in the design space, and I literally never saw
| a reason to revisit the decision to use json for that system.
|
| You'd do that because everything under the sun knows how to
| generate and parse json. Performance looks like a total non-
| issue for this use case. The messages are tiny, local and
| infrequent. You wouldn't want to do this on some kind of a high
| performance application on the data plane, but on the control
| plane it's totally fine.
|
| Even if you expect that all production use cases will use some
| kind of higher level library that does schema validation, it
| can still be quite nice during debugging to a) be able to
| inspect the messages on the wire when debugging, b) to be able
| to hand-write and inject messages.
| ptx wrote:
| > _Performance looks like a total non-issue for this use
| case._
|
| The presentation brings up performance as one of the problems
| with the D-Bus though, so it seems like it is an issue.
| jsnell wrote:
| Fair. What I meant is that the performance delta between
| JSON and any other interchange data format should be a non-
| issue in this context. I would be quite surprised to hear
| that any performance problems systemd has with D-Bus was
| with serialization/de-serialization.
| IshKebab wrote:
| Yeah... it's easy to say JSON won't be an issue. It's
| difficult to switch from JSON when it turns out you were
| wrong.
|
| https://raphlinus.github.io/xi/2020/06/27/xi-
| retrospective.h...
|
| Given how central this is going to be why would you skip
| the tiny bit of extra work needed to use a binary format?
| dinosaurdynasty wrote:
| The performance problem with D-Bus is the increased number
| of context switches over Varlink, not serialization.
| Asooka wrote:
| To be honest I don't see why they don't use the existing IPC
| mechanism created for Android - binder and ashmem. It has been
| tested and developed in real world scenarios for over a decade
| by now.
| RandomThoughts3 wrote:
| Varlink was specifically designed to be available as early as
| possible when the kernel is booting and requires virtually
| nothing apart from good old sockets. But yes, definitely
| getting yet another one vibe from this.
|
| Then again, Dbus is not really what I would call an
| incredible piece of software - we are very much in the
| adequate territory if even - so anything shaking up the
| status quo can't be too bad.
| AshamedCaptain wrote:
| Same reason Android (or PalmOS) didn't decide to use any of
| the existing IPC mechanisms, and why then Luna/webOS also
| didn't decide to use Binder even though they had experience
| with it and reinvent something else.
|
| That urge that forces every developer to reinvent RPC every
| other week.
| altfredd wrote:
| Not really.
|
| Binder solves a real-world problem -- priority inversion.
| It is also the only IPC on Linux that allows to perform a
| blocking call from process A to process B (and have process
| B synchronously call back to process A if needed).
|
| D-Bus, Varlink and other "IPC solutions" on top of sockets
| can not do those things. Android uses synchronous Binder
| calls for 90% of it's application APIs, so there is clearly
| a real use case for it.
|
| Incidentally, Binder itself does not specify message
| format. A message is a simple memory buffer. Android
| runtime uses a custom binary serialization format, but you
| can use JSON or whatever. Binder is an alternative to
| sockets/pipes, not D-Bus or other wrappers on top of them.
| AshamedCaptain wrote:
| Binder was not even designed for Linux. The primary
| reason it is used is that (at the time) they wanted to
| abstract from Linux. "They" here is not Android/Google.
|
| Binder also specifies a message format -- even if not
| fully, since the kernel is going to peek into your
| message for things like FDs, binder objects, etc. Or your
| userspace is going to need to "special treat" these
| fields somehow.
|
| It competes in the same space as D-Bus no doubt. If the
| story of Android had been different, with the companies
| spinning off some years later, it may have very well
| ended up using Luna RPC
| (https://www.webosbrew.org/pages/luna-service-bus.html )
| (which is practically indistinguishable from D-Bus, bar
| the JSON) or anything else, really.
|
| > D-Bus, Varlink and other "IPC solutions" on top of
| sockets can not do those things.
|
| WTF? Sure you can do on top of even pipes. Even XDR
| could...
|
| "Synchronous" is a very loose word here if you mean to be
| interrupted in the middle of a RPC call, anyway.
| tadfisher wrote:
| Binder was invented at Be, Inc. for BeOS, and many Be
| refugees joined Android in the early days. (I just
| learned this recently on HN, so congratulations!)
| altfredd wrote:
| > WTF? Sure you can do on top of even pipes. Even XDR
| could...
|
| Of course, you "can". Implement message-based
| communication on top of streaming. Emulate blocking calls
| on top of non-blocking socket API. Implement
| authentication via ancillary data (try not to throw up in
| process). Use some clever tricks to solve priority
| inversion. Somehow distinguish your fds from all others
| file descriptors to ensure that no confused deputy
| problems arise.
|
| Congratulations! You have reached feature parity with
| Binder.
|
| > Binder was not even designed for Linux.
|
| Neither are Berkeley sockets.
| hi-v-rocknroll wrote:
| Sigh. Cap'n Proto already exists. Reinventing the wheel yet
| again because NIH.
| NekkoDroid wrote:
| (Varlink also isn't something new)
| IshKebab wrote:
| CapnProto is kind of awful though. I had to use it for
| several years and the API is extremely unfriendly.
| theamk wrote:
| Sigh.
|
| Varlink is designed for IPC, so the expected data rate is maybe
| hundreds of messages per second in the worst case.
|
| JSON can be parsed at 3 Gigabytes/second [0]. Even unoptimized
| stdlib parsers in scripting languages get 50 MB/sec.
|
| That's more than enough, standard library support is much more
| important for a project like this.
|
| And if there is ever a reason to send tar archive or video
| data, there is always "upgrade" option to switch to raw TCP
| sockets, with no JSON overhead at all.
|
| [0] https://news.ycombinator.com/item?id=19214387
|
| [1] https://github.com/TeskaLabs/cysimdjson
| edelbitter wrote:
| But what is the excuse to start from scratch? Rather than a
| compat layer that convinces the world that raw your interfaces,
| libraries and clients are so much nicer to work with that the
| other thing should be demoted to compat layer eventually?
| jmclnx wrote:
| Does this mean Lunux will need both Dbus and varlink if using
| systemd ? I ask because I believe Firefox uses Dbus.
|
| https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future
| NekkoDroid wrote:
| systemd has been using varlink for a while now along side dbus,
| its not something just now being introduced. They don't have a
| problem living side-by-side.
| arianvanp wrote:
| Accompanying talk from Lennart Poettering a few days ago:
|
| https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-
| 6SixTy wrote:
| So does this mean I can shove SQLite databases into the file
| structure, abstract away an entire SQLite engine into a single
| header that you are forced to use, and declare that IPC? And you
| know, since we _are_ already hiding databases within the file
| structure, why not use it to also unify configuration and
| installation files too? What could go wrong?
| RandomThoughts3 wrote:
| I'm having trouble following what you mean.
|
| Yes, you can certainly send a whole SQLite database using any
| binary communication protocol as a way to exchange data today.
| You can even compress it before if you feel like it.
|
| It will not make for a good ipc format because, well, it's not
| designed to be one but it would most definitely work.
|
| What's your point?
| 6SixTy wrote:
| My point is, what's stopping me from creating yet another IPC
| standard?
| Xylakant wrote:
| Nothing. It might not see adoption, but you can create as
| many IPC standards as you desire.
| dfox wrote:
| There is this one somewhat widely deployed niche system that
| uses sqlite databases as RPC serialization format. The
| original idea behind that was limited virtual address space
| of the CE-based embedded devices, but the design got stuck.
| dang wrote:
| Related. Others?
|
| _AllSystemsGo: Varlink Now [video]_ -
| https://news.ycombinator.com/item?id=41670431 - Sept 2024 (2
| comments)
|
| _Varlink: Interface description format and protocol for humans
| and machines_ - https://news.ycombinator.com/item?id=25621936 -
| Jan 2021 (5 comments)
|
| _Varlink - A plain-text, type-safe, discoverable, self-
| documenting interface_ -
| https://news.ycombinator.com/item?id=20950146 - Sept 2019 (10
| comments)
| ptx wrote:
| Setting the serialization format issue aside, why is the D-Bus
| broker an issue?
|
| Why was it designed that way in the first place if all we need
| (supposedly) is a socket and a simple request/response protocol?
| If it wasn't needed, why does D-Bus have it? And if it _is_
| needed, what will replace it when systemd switches to Varlink?
| greatgib wrote:
| Systemd is really like a cancer in Linux system, spreading from
| one component of the system another. Until you have a single
| monolithic object OS like Windows, without modularity or elegance
| but controlled by Poettering and friends.
| nmz wrote:
| Poettering does work for microsoft.
| LooseMarmoset wrote:
| "but its just an init system, you don't have to use these
| pieces!"
|
| /s
|
| Here's a vote for Devuan - you don't have to accept systemD if
| you don't want to. I didn't.
| nly wrote:
| Why don't they just adopt the same fundamental IPC design as
| Wayland? Swap out the root wl_display singleton object for
| something dbus appropriate and away you go?
|
| https://wayland.freedesktop.org/docs/html/apb.html
|
| https://wayland-book.com/protocol-design/wire-protocol.html
___________________________________________________________________
(page generated 2024-09-29 23:01 UTC)