GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Untitled attachment

Download link

Notices where this attachment appears

  1. Embed this notice
    Eva Winterschön (winterschon@mastodon.bsd.cafe)'s status on Thursday, 29-May-2025 21:33:48 JST Eva Winterschön Eva Winterschön
    in reply to

    @david_chisnall agreed, and it's infuriating. I wrote a translator script many years ago,, when sysD was officially in RHEL, to handle most of the generic commands that systemctl requires, simply to avoid the nonsense. I work with the init system of servers hundreds of times per day during dev/eng/test.. so those little "death by a thousand cuts" become apparent very quickly.

    the same applies to so many package managers, I ended up writing a translator so that I could reduce context switching when moving from FreeBSD to Debian/clones to RH/clones.

    I'll post the package manager and service unification translator one of these days, it's probably the type of thing which would save a lot of people a lot of otherwise wasted/inefficient brain cycles.

    the comedy of sysD never ends, and if one looks for it, the regular "service" command and regular "rc.local" and init.d stack still persists despite all of their attempts to own the system from the ground up M$FT style. I wrote a couple of ttyS getty service handlers back in.. a few months ago.. easier and faster and more reliabkle than the sysD unit file interpreted garbage.

    In conversation about 14 days ago from mastodon.bsd.cafe permalink
  2. Embed this notice
    Red Rozenglass (rozenglass@fedi.dreamscape.link)'s status on Wednesday, 26-Mar-2025 15:34:56 JST Red Rozenglass Red Rozenglass
    @Cocoa@nekosat.work Yes. 99% of my init needs are met by running daemon[1] from rc.local at boot; the default method on Slackware. With three lines of shell script I get a named daemon, with PID file tracking, executed by its own user, optionally in a chroot, and with stdout and stderr redirected to log files.

    And for the 1% when I want something crazy, like running multiple network namespaces for different services hosted in them, connecting over specific Wireguard networks each, and isolated from seeing the actual network hardware directly, I can modify the simple networking init scripts, and make it happen myself in a couple of hours. I don't even want to imagine what it would be like to try to modify systemd and NetworkManager code to add such a feature.

    My experience with systemd was very buggy, in production, causing extended down-times, from bugs left unfixed for years. My experience with OpenRC was alright, but does not spark joy. Only caused production downtime once, due to a buggy interaction with consolekit2, but that's a track record roughly %600 times better than systemd already.

    [1]: https://libslack.org/daemon/

    In conversation about 3 months ago from fedi.dreamscape.link permalink
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.