Just replying to keep the vibes going.

OK, Satan.

I still remember the bad old days of stale repositories and compiling from scratch. Never again.

I just had an issue with the vscodium flatpak, been using it for two months with no issue in an online course, got to learning GUIs, import module, doesn't exist. I couldn't figure out why it wasn't there, installed three different python versions of it three different ways, still nothing. Couldn't even get vscodium to point to a different interpreter that I knew was there (yet it doesn't say it's not there, just that some things won't work). Still nothing. Three hours later, after trying everything I could think of, I realized that it was because I installed the flatpak version when it clicked that it worked in Geany and I didn't have python 3.13 in my repos, yet that was the only one I could see in vscodium.

That's disgusting, I prefer furry-hostile tabs!

The depicted character has a snout and cat ears

Thought it was more a prison thing.

Frankly, this should be implemented with something like a combination of:

https://github.com/QazCetelic/lemmy-know

Lemmy Know (let me know) is a lightweight CLI application / Docker service that monitors Lemmy for reports on posts and comments and sends notification. These can be sent to a Discord channel with a webhook or as MQTT messages (schema), which is useful for more complex setups with e.g., Node-RED.

https://www.home-assistant.io/

Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts.

https://www.home-assistant.io/integrations/mqtt/

MQTT (aka MQ Telemetry Transport) is a machine-to-machine or “Internet of Things” connectivity protocol on top of TCP/IP. It allows extremely lightweight publish/subscribe messaging transport.

https://github.com/DevelopmentalOctopus/ha-buttplug

Buttplug.io Integration for Home Assistant

https://intiface.com/central/

Intiface® Central is an open-source, cross-platform application that acts as a hub for intimate haptics/sensor hardware access

Some collection of hardware devices from:

https://iostindex.com/?filter0Availability=Available,DIY&filter1Connection=Digital&filter2ButtplugSupport=4

That'd permit for, say, having message events drive a state machine to control devices or something like that.

Put your phone on vibrate, etc...

Being able to assign a nameserver per interface with a domain wildcard is a fucking godsend. I use it every day with a hook script because my job uses some private domains but I don't want to send my entire DNS history through the VPN. Now ~job.com goes to tun0 and that's the end of it.

systemd-resolved is not perfect but with libnss's overly rigid nature the only alternative for my use-case would be to recreate similar functionality to resolved with dnsmasq – which is just objectively worse especially when you want to use DHCP sometimes but not always. Why reinvent the wheel? resolved does its job and does it well. I had some issues with it a few years ago but have been using it for the past couple years without complaint.

What is the benefit of specifically doing that in init?

What's the alternative?

Also who loves systemd-resolved?

I don't think I will ever love anything DNS-related, but it's still the best solution I've used for name resolution on a system with many interfaces.

twitter doesn’t work for me rn)

https://nitter.space/moschino_bunny/status/1457773412957376530

tysm❤️

Oh trust me I have. resolvconf and openresolve are awful too but for different reasons

People wanting the highly deterministic, but slower behavior of the rc scripts.

This is literally it for me. I got to work on an alpine system and it was like a breath of fresh air - I could edit the service script files directly. So easy, so little abstraction

That is a self-inflicted wound caused by how Wayland was designed, particularly the part where they offloaded so much responsibility onto the different compositors.

I'm more frustrated with GNOME devs...

Say no more!

Part of the problem with it is that it is very difficult not to use it, for instance if your code uses dbus, that makes systemd a dependency and almost all of the tools are like this. Want to use alternate software with systemd init? A-OK! want to use systemd tools without systemd init? Too bad! This inter-dependence is what I think makes it break the unix philosophy, its components dont like to be replaced or used outside of the "intended" environment of systemd init, keeping it from being replaced without breakage on lot of systems.

On my install for instance, systemd is roped in by xdg-user-dirs (and hence steam), flatpak, fcitx5, and cups. And that is just a few. So the init system isnt a problem to me, the lack of drop-in replacements for its suite of tools is.

So you're saying systemd is the emacs of init?

The first rule of FUDposting club.