@icedquinn@wolf480pl@dragoonaethis Was kind of doomed to happen, Telephony/MobileData/Bluetooth/… on linux without systemd is quite a mess and the "rewrite all of QtMobile in Gnome instead" headed by Librem likely didn't help at all.
@icedquinn@wolf480pl@dragoonaethis Yeah, because if you'd want to actually have an alternative, then you'd need to do a lot of work and get things right enough that it's a compelling enough alternative to systemd for third-party software to support your stuff.
@icedquinn@dragoonaethis@wolf480pl It's quite like how you had PulseAudio pretty much ruling over until PipeWire, because the alternatives were significantly worse. (Or even "you live like this?" with alsa)
@icedquinn@wolf480pl@dragoonaethis Yeah, because you don't change well over 10+ years of usage instantly.
So yeah a systemd alternative would need some adapters, but in the case of things like udev they ended up worse, I think seatd is the only one where it's better and significantly so.
@lanodan@wolf480pl@dragoonaethis its that classical problem of stuff like photoshop where you ask people what they would accept for an alternative and everyone just says "something that works exactly like this" to which they are basically admitting no alternative is possible.
you'd have to reimplement the entire interface including the bad ideas :/
It's quite impressive what it can do, and I'm sure a lot of work went into it.
Still, the code is full of weird object-oriented boilerplate with factories and stuff, which I find painful to read. I'm told people who are used to reading gstreamer source code find this easier. Still, pulseaudio code is way more readable in comparison.
@wolf480pl@dragoonaethis@lanodan main issue i have with a lot of get-what-you-are-given language comes down to that. once you've determines some set of stanzas is indeed how you want to handle all of your objects... in TCL or Lisp you just make a macro. Now you move on with your lives.
in C you have to bloat the code up with the same stanzas all the time. even though we already know this is what a gobject does, this is how we iterate the iterators, and so on, but the language doesn't afford us a way to agree on that and move on.
so.. yeah. i can see that. gstreamer is one of those APIs that looks like dogshit because the bookkeeping can't be abstracted in a sensible way. (there is going away with OOP stuff entirely, but that carries... other costs. in something like nim or rust i don't really have to choose though.)
@icedquinn@wolf480pl@dragoonaethis All programming languages have constraints and you need to work well in those.
Don't be Stephen R. Bourne (of Bourne Shell fame) and transform C into a bastard version of ALGOL.
@lanodan@wolf480pl@dragoonaethis if i had anything to do with a language these days, it would look more like terralua: running an interpreter that builds up code objects and then ejects them out as a binary once its all said and over with.
the base language wouldn't give you much more than what ANSI C already did, and then just let people import constructs after the fact.
did you have a double-linked-list anywhere in the code?
Normally in Linux kernel when you need a list, you include struct list_head inside your struct that you want to keep on the list.
Then when you retrieve something from the list, you get a pointer to the struct list_head, and you use container_of to get at your own struct that contains the list_head
@wolf480pl@dragoonaethis@lanodan didn't need them. i decoded packets from a USB stream and translated them to evdev events and pushed them out the other side.
I think its design is bad in principle, but the only practical concer I see is that a lot of software will start relying on its APIs. Judging by the postmarketOS blogpost, that ship has already sailed.
Add comment