Expert developer, Buddhist

  • 0 Posts
  • 55 Comments
Joined 1 year ago
cake
Cake day: June 21st, 2023

help-circle

  • I think I need more info. It seems like userspace is very hackable, so thus kernel level anti-cheat was born to control stuff like synthetic inputs and manipulation of memory / frame analysis. This anti-cheat would be held together by the fact that the kernel/drivers are proprietary and not very easy to edit. Obviously still possible because it’s on your own computer, but challenging and invasive. Do I have that right?

    In which case I don’t see how going back to userspace would help. What is the solution? There probably isn’t one outside of hardware (buying a hacking chip and soldering it in is annoying for most)

    When I was doing game dev we focussed on AI-style analytics of user behavior. Of course a good enough bot could always look human. A real cat and mouse game wasting lots of time













  • Lung@lemmy.worldtoLinux@lemmy.ml“Systemd is the future”
    link
    fedilink
    arrow-up
    12
    arrow-down
    2
    ·
    5 months ago

    I guess reading the history, systemd did a better job of dependency resolution and parallel loading of startup services. Then some less interesting stuff like logins, permissions, and device management - which definitely seems out of scope. There’s been like 15 alternatives since it was made, but none of them got critical mass, and now pretty much every mainstream distro can’t run without it. Sad face

    While I’m here complaining, I really miss the days when Arch was configured from a single global file that handled many things like setting your hostname, locale, etc. I think it was dropped bc of maintenance & being not unixy enough. Kinda ironic


  • Lung@lemmy.worldtoLinux@lemmy.ml“Systemd is the future”
    link
    fedilink
    arrow-up
    69
    arrow-down
    1
    ·
    edit-2
    5 months ago

    I mean that argument is ridiculous, saying that things are “documented” when the thing is literally called tmpfiles.d and the man page starts with the following explanation:

    It is mostly commonly used for volatile and temporary files and directories (such as those located under /run/, /tmp/, /var/tmp/, the API file systems such as /sys/ or /proc/, as well as some other directories below /var/).

    So basically some genius decided that its a good idea to reuse this system for creating non-tmp directories. Overall my opinion of systemd is reluctant acceptance though I always wondered why the old way was a problem. Need a service started on boot? Well, we had crontab and sysvinit with some plain files. Need a service shut down? Well that’s the kill command. I guess I don’t really know why systemd was made