On Tue, 2 Apr 2024 at 08:18, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
On Di, 02.04.24 14:04, Petr Menšík (pemensik@xxxxxxxxxx) wrote:
> Could be even smaller library libsystemd-notify linked from libsystemd,
> which would allow end applications to explicitly declare they need more
> limited set of functions?
Why link? I'd really just suggest people to implement the trivial
client on their own. It's a trivial protocol for a reason: so that
people can implement it natively in their language and framwork
without bothering with our upstream libsystemd.
I think because enough people have learned that anything which is listed as a 'trivial protocol' tends to get messed up if you don't really understand it. Many developers have also learned that if you mess up a 'trivial protocol' you tend to get blamed for being an idiot or worse so it is better to just find something which already implements it, is tested and known to work and move on with your day. I think the two combined with some other social reasons are why various modern languages (go, python, java, rust, etc) have grown giant ecosystems where packages focus on implementing a trivial thing and you are to include just that versus a library of other things. [Of course you then end up with 30 ways to implement the same trivial thing which pull in various other trivial things...]
I am not saying this is good behaviour or what should be done, but it seems expected these days.
use libsystemd if you link against it anways and hack in C, or if you
really don't are about the extra dep for a single function, but
otherwise, why would you use the lib?
It *literally* is just sending a text string "READY=1" in an AF_UNIX
datagram to a socket whose path is provided to you in the
$NOTIFY_SOCKET env var. Anyone with a moderate understanding of UNIX
APIs should be able to hack that up in a a few lines of code. It's a
protocol I can summarize and explain in *one* frickin' sentence.
sshd upstream understood this btw:
https://bugzilla.mindrot.org/show_bug.cgi?id=2641
Lennart
--
Lennart Poettering, Berlin
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
