

And for context, it does this because cheaters are willing to run cheats that run at that kernel level, and the only way to detect and prevent them is if the anticheat is in your kernel first.
And for context, it does this because cheaters are willing to run cheats that run at that kernel level, and the only way to detect and prevent them is if the anticheat is in your kernel first.
then I would install one
growing it like a garden is a perfect phrase imo
because on windows or Mac it may have just worked. …until it doesn’t, or leaves your windows scaled wrong or placed on monitors that don’t exist or some other failure condition. at which point you reboot and hope for the best.
when it doesn’t work on Linux I’d check logs, actual configuration, and even the source if I need to.and then I’d hopefully improve things and make it work the way I want it to.
If adopt systems then the question is easy to answer: no, journald does everything you need.
without adopting systemd… well. Are you evaluating going without any log handling at all and maybe just dumping logs ephemerally to tty0? DIYing all log stuff like your init scripts DIY things?
Personally if I had to go without journald I’d probably go back to using syslog-ng. But I guess there’s an argument for shipping straight into something like opentelemetry-collector if you’re willing to put in a lot of work.
I dont have any specific llms to recommend but if you do want to go that route you could always run it remotely through something like Google collab.
But I don’t know if I would trust the results of an llm doing this as any mistake would make your entire resume untrustworthy