• 7 Posts
  • 24 Comments
Joined 1 year ago
cake
Cake day: June 2nd, 2023

help-circle
  • [email protected]@beehaw.orgtoLinux@lemmy.mlD-Bus overview
    link
    fedilink
    English
    arrow-up
    8
    ·
    6 months ago

    This is an amazing article for folks interested in the low level IPC dbus. systemd, network manager, and or applications are leveraging dbus and with the new dbusbroker I expect more and more applications leverage it. It’s MASSIVELY confusing at first, but this is such a great article I hope it helps anyone interested in thr low level communications of userspace level linux applications.


  • It’s a fair point, but I don’t think I’m worthy, hence why I asked. Lol

    i’m on beehaw and they don’t just create communities, hence why I asked here. Seems like I’m getting a number if uovotes, so not sure if others are interested in my question or woukd like to see folks posting when they go live here. Any and all thoughts are appreciated.

    Obviously wondering mod and communities thoughts as well. This is all of our space imo.















  • Use tech and services outside the big tech. Just Fedi over standard social. Use Peertube instead of Youtube.

    Run Firefox.

    Set up your own servers for yourself or start a community. Matrix, Mastodon, Lemmy, etc.

    Run SearXNG as your search or help others by hosting.

    If you can work of free and open source code that helps decentralize and give the power back to the people or create something new. Even if you can code, learning a project and helping others with it or helping create docs, etc.

    Spread the word, but don’t be annoying. Help less technical folks get decentralized.

    It’s very difficult and can be disheartening, but you don’t have to cold turkey all of it. Each drip in the bucket helps until we’re all united and become a tidal wave.

    When all the power is centralized that’s when those central players think they can do whatever they want.



  • This isn’t a converstaion. This is comments be slung back and forth. I argue you can’t really have a conversation on these kinds of platforms and at this pointit’s pandering at the best and downright insulting any other way as every step the mods attempted to speak out and they ignored everything including forcing them open back up.

    Honestly i understand how these folks don’t want to walk away fron communities they helped build, but how bad does it have to get before you do walk away?

    Sadly communities rise and fall faster than the tide on the internet. Find something for you that you control and contribute to that, no some douchebag exec that sees you as a dollar sign.

    Also there were no answers or conversation there. Just 3 comments from the admin, 1 saying he’d take the feedback on the lowest scored post and then 1 refuting something and the last pointing to that refutinf post.




  • As an end user, unless you’re running a server, then no you shouldn’t have to mess with any of it.

    If you’re running a server or a sysadmin you absolutely 100% should be paying attention. Almost every single vendor I’ve seen selling their applications only have initscripts. Which then cause issues. I’ve gone to the vendors and told them and they’ve said go to Red Hat. Well Red Hat doesn’t support that vendor’s init scripts.

    Not naming an application, but it was from a BIG BLUE company and they said their only instructions are to call their script from the user. But it won’t remain running if you do that because systemd will close out the slice when the user logs out. SO it’s obvious they haven’t tried what they’re suggesting.

    And I’m not attempting to state that systemd is impressive in any way. systemd basically took what had been building over 40 years of init scripting and threw it out the window and said our way is better. I don’t think it is. I’m just saying, with a directive based unit file it’ll be simpler to parse than a bash script.


  • [email protected]@beehaw.orgtoLinux@lemmy.mlIs Systemd that bad afterall?
    link
    fedilink
    arrow-up
    18
    arrow-down
    1
    ·
    edit-2
    1 year ago

    Ok, so I have a very unique background in systemd. I worked at Red Hat supporting it basically as the primary support and I’ve worked with the developers of systemd at Red Hat directly. I no longer work there.

    So first off, it’s “systemd” all lower case. I don’t care, but for some reason Lennart Pottering (creator) does.

    systemd was a MASSIVE change. And Red Hat did a TERRIBLE job relaying it. To the point where I’m still trying to get my company to understand that it can NOT be treated like the old init systems. You can NOT just drop an init script in place and walk away and hope it works. Because a LOT of times it doesn’t. Due to forks, switch users, etc.

    systemd is NOT an init system. RHEL 5 and older had sysvinit as it’s init systemd. RHEL 6 had UpStart as it’s init system and looked exactly like sysvinit that no one even noticed. systemd again is NOT an init system. Init system is 1 part of systemd. systemd does a lot of cool things. It bundles applications together, it manages those applications and can restart them or kill children, it can do resource constraints, it separates out users from the system, and lots more.

    Because it is not an init system there is a LOT LOT LOT of bad recommendations out on the internet where someone has X problem and person suggests Y and IT WORKS! … except it doesn’t REALLY work as far as systemd is concerned and you’ll hit other issues or your application takes longer to start or stop and people just blame systemd.

    It is systemd’s fault that it has done an ATROCIOUS job of helping people adapt. It’s a great example of RTFM. systemd’s man pages are INCREDIBLE and extensive, but when you drop so much knowledge it becomes more difficult to find what you want/need. systemd.index and systemd.directives are your best bet.

    So systemd does a lot of amazing things that sysvinit never attempted to do. It’s never attempted to explain anything it expects everyone just learn magically. it’s INCREDIBLY complex, but once you understand it’s basics you can more easily get an application running, but as soon as there’s a problem it’ll just break your brain.

    To give you an example, sshd’s old init script is like 250 lines of bash. systemd’s unit file comparative is like 12. Because systemd handles a LOT of what you manually had to handle before. BUT to get to that 12 you literally have to learn EVERYTHING new.

    There is no “is it good or bad” here really imo. It’s a completely different fundamental design. Red Hat made it for themselves. Other distros picked it up. It can be argued that lots of folks followed Debian and Debian had a few Red Hat board members that were pushing it. Whether they pushed it of their own accord or because they were with Red Hat I don’t have a clue.

    What I can say is at my current company they’re suffering from a LOT of systemd issues and they don’t even realize it. I’ve been working with Red Hat to try to get Insights to alert people to the failures and we’re making progress.

    To see if you have issues just to start run the two following commands:

    # systemctl list-units --failed
    # systemd-cgls
    

    If you have any units that are failed, investigate those. If you don’t need them, disable them. As for the systemd-cgls this shows HOW systemd is grouping things. ANY application that runs as a service (or daemon or application or runs in the background or however you wanna say it) should be under system.slice. ONLY humans logging into the system (meat bags NOT applications switching to users) should be in user.slice. A LOT of times what happens is an old init script is dropped in place, they start it, it has a switch user and systemd assumes it’s a user and puts it into user.slice. systemd does NOT treat anything in user.slice the same as in system.slice and this WILL eventually cause problems.

    So again, is it good or bad? Eh. It does a lot of cool things, but they did a MASSIVE disservice to ALL of us by just expecting to relearn absolutely EVERYTHING.