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 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.

Yeah, devices pull power.

The charger periodically tells the car the maximum power it can provide, and the car knows to not ask for more than that (plus the charger will just cap it at its max).

Apart from that, it's mostly like a regular electrical outlet. If you plug in a 50W desk fan, it'll only pull 50W, even though the outlet can provide 1800+W

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.

Some of the high power ones have batteries that they essentially use as a buffer. Recharge them when idle, then use them as extra capacity when charging cars.

Apart from that, I'm not sure. Probably the same way other consumers are handled How much peak power does a large apartment building, office, or factory use?

1.5MW, not kW.

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.

Why does Apple feel they deserve a 30% cut? In cases like this, Apple aren't providing any value at all.

• Apple aren't providing the content - the creator is.
• Apple aren't providing a platform for the content - Patreon is.
• Apple aren't providing a platform for discovery - people aren't finding Patreon creators solely via Apple products.

Sure, Apple are providing a payments platform, but why do they deserve 10x what Stripe charges?

These days, apt is for humans whereas apt-get is for scripts. apt's output is designed for humans and may change between releases, whereas apt-get is guaranteed to remain consistent to avoid breaking scripts.

apt combines several commands together. For example, you can use it to install packages from both repos and local files (e.g. apt install ./foo.deb) whereas apt-get is only for packages from repos and you'd need to use dpkg for local packages.

and you shouldn't be using any of those, since the order can and will change. The numbers are based on the order the devices and device drivers are initialized in, not based on physical location in the system. The modern approach (assuming you're using udev) is to use the symlinks in /dev/disk/by-id/ or /dev/disk/by-uuid/ instead, since both are consistent across reboots (and by-id should be consistent across reinstalls, assuming the same partitioning scheme on the same physical drives)

This is also why Ethernet devices now have names like enp0s3 - the numbers are based on physical location on the bus. The old eth0, eth1, etc. could swap positions between Linux upgrades (or even between reboots) since they were also just the order the drivers were initialized in.