|
spankmeister posted:I recently found out systemd timers are a thing lol there's a "the virgin cronie vs. the chad systemd.timer" meme here with OnCalendar=daily Persistent=true on the chad side
|
#
?
May 5, 2020 02:47
|
|
|
|
| # ? Jun 4, 2024 00:04 |
|
|
spankmeister posted:I recently found out systemd timers are a thing lol yeah, that whole "systemctl list-timers" thing is terribly hard to use
|
|
#
?
May 5, 2020 03:38
|
|
|
Used a systemd path unit for the first time the other week (triggers when a specific path changes, using inotify). Worked fine and saved me writing more code or installing some other tool 👍🏿
|
|
#
?
May 5, 2020 03:48
|
|
|
I’ve written a few systemd files; needs suiting
|
|
#
?
May 5, 2020 03:54
|
|
|
The_Franz posted:yeah, that whole "systemctl list-timers" thing is terribly hard to use also systemd-analyze calendar --iterations=N
|
|
#
?
May 5, 2020 04:06
|
|
|
Rufus Ping posted:Used a systemd path unit for the first time the other week (triggers when a specific path changes, using inotify). Worked fine and saved me writing more code or installing some other tool 👍🏿 sounds good op
|
|
#
?
May 5, 2020 08:15
|
|
|
Notorious b.s.d. posted:the article this links to is really good tho mostly it well documents that, all technology opinions left aside, poettering is indeed an rear end in a top hat.
|
|
#
?
May 5, 2020 08:47
|
|
|
eh, he was when he started the thing. he's a lot better now.
|
|
#
?
May 5, 2020 08:50
|
|
|
Notorious b.s.d. posted:don't worry there is now systemd-cron, which parses crontabs and twiddles dbus bits to create systemd timer units what, you wish systemd wouldn’t try to be backwards compliant with legacy apps?? (sometimes I just don’t get at all the Unix philosophy of wanting simple things to do their job badly) (like now)
|
|
#
?
May 5, 2020 14:19
|
|
|
Notorious b.s.d. posted:don't worry there is now systemd-cron, which parses crontabs and twiddles dbus bits to create systemd timer units lmao
|
|
#
?
May 5, 2020 15:57
|
|
|
"why is all this functionality in pid 1, why not split it out and have it talk some sort of socket protocol like unix apps do" *creates separate daemon, uses private unix socket connection to talk to pid 1* "wtf is all this dbus junk" seriously the dbus here is just a serialization protocol. it was standardized before msgpack and if there was a json parser in pid1 you would be complaining about that too
|
|
#
?
May 5, 2020 16:36
|
|
|
unless you think that the way that things should talk to pid1 would be, like, inotify and the filesystem in which case hoo boy if youve ever used that even once you know it basically never works lmao
|
|
#
?
May 5, 2020 16:37
|
|
|
they should just make syscalls, op, but systemd-kerneld isn’t quite ready yet
|
|
#
?
May 5, 2020 16:48
|
|
|
Soricidus posted:they should just make syscalls, op, but systemd-kerneld isn’t quite ready yet remember kdbus lol
|
|
#
?
May 5, 2020 16:49
|
|
|
systemd owns and you can tell who's never had to do what it does in anger or has thousands of lines of bespoke shell scripts that are wrong in subtle ways
|
|
#
?
May 5, 2020 16:50
|
|
|
Notorious b.s.d. posted:remember kdbus lol it's called bus1 now
|
|
#
?
May 5, 2020 16:51
|
|
|
Malcolm XML posted:systemd owns and you can tell who's never had to do what it does in anger or has thousands of lines of bespoke shell scripts that are wrong in subtle ways systemd is a lot better than what it replaced but man is it covered in warts
|
|
#
?
May 5, 2020 16:51
|
|
|
ah yes, that famous example of perfect design and true un-warty-ness, unix
|
|
#
?
May 5, 2020 16:52
|
|
|
Malcolm XML posted:it's called bus1 now i wouldn't hold my breath for bus1 to make it into the kernel either
|
|
#
?
May 5, 2020 16:52
|
|
|
Suspicious Dish posted:ah yes, that famous example of perfect design and true un-warty-ness, unix well the bar to clear here is smf systemd is a lot better than a shitheap of shell scripts but it's still not as good as smf was
|
|
#
?
May 5, 2020 16:53
|
|
|
Malcolm XML posted:systemd owns and you can tell who's never had to do what it does in anger or has thousands of lines of bespoke shell scripts that are wrong in subtle ways
|
|
#
?
May 5, 2020 16:58
|
|
|
Notorious b.s.d. posted:well the bar to clear here is smf bullshit
|
|
#
?
May 5, 2020 16:58
|
|
|
its even goofier than that. after kdbus died out, kay sievers and harald hoyer went and did varlink, which replaces the custom serialization with json and removes almost all useful parts of dbus. then kay quit red hat and i think they now just make music gadgets full-time, so harald's the only one working on varlink now and it's kinda dead. david herrman and tom gundersen did bus1 which broke a lot of dbus stuff but they plan on putting it back with dbus-broker kinda, i'm not sure the latest state of bus1 i think theres a third ipc project somewhere too, can't remember where it is. basically all of this is an attempt at working around the insane lack of good ipc & messaging primitives in the kernel. kdbus was a really good attempt and would have worked if it wasnt for groups of uninformed completely misunderstanding the system and making large, repeated harassment campaigns
|
|
#
?
May 5, 2020 17:02
|
|
|
kdbus didn't make very much sense as a set of primitives, and it wasn't faster or notably better than userspace dbus literally the only thing kdbus had to offer was avoiding the boot-time dependency loop for systemd. that was the only use case. it should not be surprising that it went unmerged which is not to say no new ipc mechanism will ever be added to the linux kernel, just, i don't think it's gonna be kdbus or bus1
|
|
#
?
May 5, 2020 17:05
|
|
|
why do we need all these different ipc mechanisms anyway. http works fine, just use that. it’ll get a lot easier when they merge khttpd so you can manage everything with systemd-chromiumd
|
|
#
?
May 5, 2020 17:08
|
|
|
systemd-npm install linux-kernel-6.6.6
|
|
#
?
May 5, 2020 17:15
|
|
|
Notorious b.s.d. posted:kdbus didn't make very much sense as a set of primitives, and it wasn't faster or notably better than userspace dbus the goal was to eliminate a large number of race conditions, and it did that just fine. the goal wasn't purely speed, it was to build a comprehensive ipc system where you don't have the problem "pids can get reused so theres tons of TOCTOU bugs and security issues". not a slight against dbus, it's impossible to do in userspace correctly, and still is to the best of my knowledge the interface it exported was very minimal and was basically a new set of ipc primitives based on device nodes. google said they could easily replace binder with it.
|
|
#
?
May 5, 2020 17:26
|
|
|
Truga posted:systemd-npm install linux-kernel-6.6.6 don't give webdevs ideas, there's a lot of them and they have a lot of sinecures
|
|
#
?
May 5, 2020 18:00
|
|
|
imho just fork mach and call it linux 5.7, ipc mechanism problem solved forever.
|
|
#
?
May 5, 2020 18:27
|
|
|
too bad the hipster-cool init system is runit - hoo boy is that codebase terrible it features: - bespoke custom build system - hard-coded install to oddball paths - no real way to cross-compile it - lots of runtime feature checks during compilation - most of the code is K&R C, which will be uncompilable in the next release of the C standard - plenty of type warnings from using int for everything - uses obsolete utmp features - cargo-cults a bunch of djb stuff, which is reason enough to know it's bad - abandoned by the author like 10 years ago Poopernickel fucked around with this message at 18:39 on May 5, 2020 |
|
#
?
May 5, 2020 18:30
|
|
|
Truga posted:systemd-npm install linux-kernel-6.6.6 close to the metal
|
|
#
?
May 5, 2020 18:35
|
|
|
You want bad? GCC10 is breaking all sorts of packages because of two new cool things: -fno-common libsanitizer Buildroot is now choking pretty hard on building some host packages because Fedora32 comes with GCC 10 by default. 
|
|
#
?
May 5, 2020 18:44
|
|
|
Also another pain in the rear end thing: Firewalld requires pretty much every nftable option enabled in the kernel. Over 175 config options.
|
|
#
?
May 5, 2020 18:45
|
|
|
ratbert90 posted:Also another pain in the rear end thing: who cares? seriously, why does it matter which modules you enable in the kernel, they're only loaded if needed or are you trying to wrangle in firewalld in some embedded thing (nftables will be deprecated sooner or later anyway)
|
|
#
?
May 5, 2020 19:40
|
|
|
Suspicious Dish posted:the goal was to eliminate a large number of race conditions, and it did that just fine. the goal wasn't purely speed, it was to build a comprehensive ipc system where you don't have the problem "pids can get reused so theres tons of TOCTOU bugs and security issues". not a slight against dbus, it's impossible to do in userspace correctly, and still is to the best of my knowledge i mean there's pidfds now, and memfds were originally part of kdbus Tankakern posted:who cares? seriously, why does it matter which modules you enable in the kernel, they're only loaded if needed bpf in every orifice
|
|
#
?
May 5, 2020 21:31
|
|
|
oh, pidfds were accepted? hell yea, that's a nice way to beat the race then
|
|
#
?
May 5, 2020 21:41
|
|
|
Next what we need is some way to create a new process ex nihilo and load memory mappings, threads, seccomp policy, and fds into it. Retrofit some sort of actual capability-based security on top of POSIX.
|
|
#
?
May 5, 2020 21:45
|
|
|
Tankakern posted:who cares? seriously, why does it matter which modules you enable in the kernel, they're only loaded if needed Embedded.
|
|
#
?
May 5, 2020 21:53
|
|
|
ratbert90 posted:Embedded. lmaoing forever at the thought of using Python-based anything in an embedded application
|
|
#
?
May 5, 2020 21:56
|
|
|
|
| # ? Jun 4, 2024 00:04 |
|
|
Sapozhnik posted:lmaoing forever at the thought of using Python-based anything in an embedded application ? Python works fine in the embedded Linux world. Why wouldn't Python work?
|
|
#
?
May 5, 2020 22:05
|
|