Monochrome? It still works.

They really are turning the frogs gay

Maybe I just haven’t encountered any bugs that took a long time to fix. It’s been pretty reliable for me.

I’m a software developer that focuses on front end development (full-stack but I like frontend more) so I’m pretty picky about UI/UX. Boost feels very nice and polished.

I like Boost.

Last time I said this, I got shunned for recommending a closed-source app. I generally try to stick to open-source, but Boost has a good UI, works well, and bugs are fixed quickly.

I started looking into it for radio - unifying paid SiriusXM, free TuneIn, and free Shoutcast/Icecast powered radio stations, in a single system.

My idea was to show a list of our favourite radio stations on a dashboard tablet, with buttons to play them on particular media players (Google speakers, etc)

I set it up and started making a Home Assistant dashboard that shows the list. It took a while to figure out how to properly display the list of all the stations, but I ended up figuring it out using the flex table card component: https://community.home-assistant.io/t/dynamic-buttons-based-on-template-sensor/917207

I didn’t end up finishing the project though, and put it on hold while working on other things. I’ll revisit it one day.

It can also pull from Plex, but I haven’t tried that. At the moment, I usually cast from Plexamp to my speakers when I want to play something.

If you’re fine pulling with legit services then https://monochrome.tf/ is probably the easiest to use (or their backend service if you want to automate it).

Musicbrainz is fine; it’s just Lidarr’s usage of it that’s a problem. Lidarr uses its own mirror of Musicbrainz, plus its own custom search code, and it’s not as reliable.

Other apps that use Musicbrainz data, like Beets and Picard, don’t have the same issues that Lidarr has.

Yes, unstructured. Every script is its own special snowflake that does things a bit differently.

There’s no guarantee of the verbs that the script implements. start, stop and restart are common, but the implementation is up to each individual script. I’m most familiar with Debian where some service (but not all) implemented it with start-stop-daemon, but other distros and OSes handled it differently.

Basic, commonly needed functionality, like restarting a crashed service after waiting for some delay, need to be implemented per app.

When sysvinit was widespread, there was a reason a lot of people used systems line supervisord to deploy services, rather than dealing with sysvinit scripts. It was a pain.

Systemd units were a logical progression from supervisord services.

Thanks for the info. It looks like there’s no way to migrate from Conduit. If I reinstall from scratch using the same domain, and create an account again, will everything still work properly including federation with other servers?

My server is just for myself.

What did you end up doing? I’m still running Conduit at the moment.

Do you have any actual problems with systemd, or do you just want SysV init scripts to stick around forever?

Maybe systemd isn’t the best, but it’s way better than a bunch of mostly unstructured shell scripts, and more secure (it’s pretty easy to reduce privileges, sandbox the filesystem, restrict syscalls, etc per service just by editing the unit file)

I use chezmoi and chezmoi_modify_manager to keep my dotfiles (including some KDE configs) in a Git repo, and it works well enough.

I like Pushover too. I’ve been using it for over 10 years now.

Maybe they’ve cast Jack Black as Ganondorf lol

Chrome’s had it for five years, and I don’t recall any Webserial-specific vulnerabilities in it (but I could be wrong!)

not dependent on the server

It doesn’t have to be - a developer could also provide a HTML file that the user can download and open locally.

And to be honest, if someone had to build a user-friendly cross-platform GUI app for connecting to some sort of serial device, they’d probably just end up using web technologies (Electron or Tauri) anyways. May as well avoid the extra overhead of Electron.

You can completely disable the API in Chrome… I assume Firefox will allow this too.

IMO it’s fine since you need to explicitly grant permission for the site to use it, and also explicitly choose a device to allow it to communicate with. You can also configure your browser to always reject requests to use the API, if you never want to use it.

WebSerial is useful for the developer as they can build their webapp once and it’ll work consistently across platforms, and it’s useful for the user since the same interface will work across all OSes.

I prefer it over the other common approach for communicating with serial devices, which is often to only make a Windows app and to have some convoluted setup process involving sketchy-looking drivers, which then breaks when you have different devices that require different versions of the flashing software or drivers.

Why install a native app when a website can do it?