nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqmh888n5tn05wwhjls6wd897jx0m9j6fdy0ynfx8s724su5420kxsj2f40h (nprofile…f40h) Writing a daemon in traditional Unix is absolutely broken.
You need to do a dozen things that are special to daemons, and you need to implement a debug option where you do not do these things.
Double forking, disowning a terminal, log to syslog instead of stderr, rotating a logfile and/or handling SIGTERM to close and open a logfile (both syslog and logfile, or an option to choose), resource limits, locking and pid-file handling, the list goes on.
Systemd extracts these things into common code and handles it – properly written systemd code can be started in one of multiple ways the daemon does not need to know anything about. It does not need to fork, it does not need to create a port or know the port number, it logs to stderr, it does not need to know about pid-files, and so on. It is just a piece of code that runs on connect, permanently, containerized with resource limits or whatever – the code does not need to know about it at all.
And that is good. Much better than before.
Systemd does a lot of other things that init should have done, but never bothered to do. Not just daemon-handling and containerizing daemons, but also actually building the system on startup – integrating the various components, including pluggable components, whenever there is an event. For this it handles and integrates with other components that do the actual work. For this, it has to have knowledge about these things.
Systemd also gives us finally a schema for logfiles, which makes logfiles indexable and searchable. It also gives us integrity for logfiles, by treating them as the appendable Merkle tree they should have been since the concept of such trees existed.
All of that is part of the automation of sysadmin work.
https://blog.koehntopp.info/2015/03/27/go-away-or-i-will-replace-you.html
Most computers never have an operator that logs on. If they have to, that's a bug. File a report.
Ah, and regarding
the output of 'ls -l' on a large directory
We do have https://github.com/kellyjonbrazil/jc
CLI tool and python library that converts the output of popular command-line tools and file-types to JSON or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.
but despite understanding the output of hundreds of existing Unix commands and converting them to JSON, jc does not understand the output of ls. Nobody does.
That is why Linux coreutils grew stat. ls is just too broken to parse.
Kris /
npub1za…n4x69
2024-12-22 08:11:54
in reply to nevent1q…sjs9
Author Public Key
npub1zactwggqnv2xzypa7c2m4t3dzfvg2n4typ90n2fhpdjnlv700dxqdn4x69Published at
2024-12-22 08:11:54Event JSON
{
"id": "b3c5f02a96636680cb21f8b7369092327578960f4b576e15e3419abc798423b5",
"pubkey": "1770b721009b1461103df615baae2d1258854eab204af9a9370b653fb3cf7b4c",
"created_at": 1734855114,
"kind": 1,
"tags": [
[
"p",
"ddce73ce8b9be8e75e5f869cd397d233f659692d23c93498f0f2ab0e52aa7d8d",
"wss://relay.mostr.pub"
],
[
"p",
"1ace68472745b2642934c6172c5994f5f094f01deb752145d25225e637a87a50",
"wss://relay.mostr.pub"
],
[
"e",
"85eb8ae7662d8b521aa4e1aad14d093f716daf5940b15b239d2fdf8022a71d84",
"wss://relay.mostr.pub",
"reply"
],
[
"proxy",
"https://infosec.exchange/users/isotopp/statuses/113695464765405875",
"activitypub"
]
],
"content": "nostr:nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqmh888n5tn05wwhjls6wd897jx0m9j6fdy0ynfx8s724su5420kxsj2f40h Writing a daemon in traditional Unix is absolutely broken.\n\nYou need to do a dozen things that are special to daemons, and you need to implement a debug option where you do not do these things.\n\nDouble forking, disowning a terminal, log to syslog instead of stderr, rotating a logfile and/or handling SIGTERM to close and open a logfile (both syslog and logfile, or an option to choose), resource limits, locking and pid-file handling, the list goes on.\n\nSystemd extracts these things into common code and handles it – properly written systemd code can be started in one of multiple ways the daemon does not need to know anything about. It does not need to fork, it does not need to create a port or know the port number, it logs to stderr, it does not need to know about pid-files, and so on. It is just a piece of code that runs on connect, permanently, containerized with resource limits or whatever – the code does not need to know about it at all.\n\nAnd that is good. Much better than before.\n\nSystemd does a lot of other things that init should have done, but never bothered to do. Not just daemon-handling and containerizing daemons, but also actually building the system on startup – integrating the various components, including pluggable components, whenever there is an event. For this it handles and integrates with other components that do the actual work. For this, it has to have knowledge about these things.\n\nSystemd also gives us finally a schema for logfiles, which makes logfiles indexable and searchable. It also gives us integrity for logfiles, by treating them as the appendable Merkle tree they should have been since the concept of such trees existed.\n\nAll of that is part of the automation of sysadmin work.\n\nhttps://blog.koehntopp.info/2015/03/27/go-away-or-i-will-replace-you.html\n\nMost computers never have an operator that logs on. If they have to, that's a bug. File a report.\n\nAh, and regarding\n\nthe output of 'ls -l' on a large directory\n\nWe do have https://github.com/kellyjonbrazil/jc\n\nCLI tool and python library that converts the output of popular command-line tools and file-types to JSON or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts. \n\nbut despite understanding the output of hundreds of existing Unix commands and converting them to JSON, jc does not understand the output of ls. Nobody does.\n\nThat is why Linux coreutils grew stat. ls is just too broken to parse.",
"sig": "ebc691c90c2a6f34871fb51d80a98ad012ed6d4ad9586c059cdcab4d0a86e27b05458ebdd3a59fc9ecaa558775198dbdbf5837c76894f4d9a3e30ec6efa3b86e"
}