Same email for everything is fine if you use subaddressing. My email service, Port87, makes it super easy.

Nephele with SERVE_LISTINGS turned on and a read only mount.

It shows listings in the browser, just like Apache, but can also be accessed with a file browser, because it’s a WebDAV server.

Flatpaks are awesome. Flathub is awesome. :)

The driver for your mouse occupies a few kilobytes. The shitty app and AI garbage bloatware occupies the rest.

It’s their machine. It’s a front door.

That’s not a vulnerability. That’s intended and desired behavior. It was really useful in this case too.

I should mention that the WebDAV share is password protected, so only he has access to do that.

Something really fun I found out recently, when my friend lost all access to his system except for a single WebDAV share by accidentally turning off all his remote admin access:

If you write “b” to /proc/sysrq-trigger, it will immediately reboot the system (like holding down the reset button, so inherently a bit dangerous).

He was running Nephele with / mounted as the share, so luckily he just uploaded that file with a single “b” in it, and all his remote admin stuff came back up after the reboot.

This absolutely can happen to stable projects. This has happened with Mastodon many times, and Mastodon has been stable for years.

It also has happened with Nextcloud many times, and again, Nextcloud has been stable for years.

It’s not a stability thing, it’s an automation thing. We as devs can only automate so much. At a certain point, it becomes up to you, as the administrator, to manually change things. Things like infrastructure changes, and database migrations, where the potential downtime if we automate it is something we need to consider.

This is very cool, but also very dangerous. Many projects release versions that need some sort of manual intervention to be updated, and automatically updating to new versions on docker can lead to data loss in those situations.

Here’s a recent example from Immich:

https://github.com/immich-app/immich/releases/tag/v1.133.0

It is my humble opinion that teaching newbies to do automatic updates will cause them to lose data and break things, which will probably sour them from ever self hosting again.

Automatic OS updates are fine, and docker update notifications are fine, but automatic docker updates are just too dangerous.

I take it you’ve never even tried Linux before. Both of those things are not things that will hold you back. My mom uses Linux, and she barely knows what “right click” means.

With regard to your Steam games, as long as you don’t play games that use restrictive anticheat, you’ll be fine.

I have all Reolink cameras and they’re awesome. They have both indoor and outdoor cameras. They’re really expensive compared to other similar cameras, but the software is really good, and there’s no subscription. You don’t even need to log in. Everything is only stored locally, on either SD cards in the camera or a separate “home hub” (or both). They have motion and object detection built into the cameras.

The way I have them set up is every indoor camera is plugged into a smart outlet that disconnects their power through Home Assistant when either me or my wife are home.

The outdoor ones are connected to solar power, so I didn’t even have to run any wires.

I’d highly recommend them.

So, Jellyfin is one of those apps where the Docker documentation is really lacking. I’m gonna give you my docker-compose.yml file in case it helps:

services:
  jellyfin:
    image: jellyfin/jellyfin
    user: 0:0
    restart: 'unless-stopped'
    ports:
      - '8096:8096'
    environment:
      #- JELLYFIN_CACHE_DIR=/var/cache/jellyfin
      #- JELLYFIN_CONFIG_DIR=/etc/jellyfin
      - JELLYFIN_DATA_DIR=/var/lib/jellyfin
      - JELLYFIN_LOG_DIR=/var/log/jellyfin
    volumes:
      - ./config:/config
      - ./cache:/cache
      - ./data:/var/lib/jellyfin
      - ./log:/var/log/jellyfin
      - /data/jellyfin:/data/jellyfin
    devices:
      - /dev/dri

For me /data/ is my RAID array, which is why my jellyfin data directory is there. Everything else goes in the same directory as the compose file. My system has a graphics card that does transcoding (Arc A380), so I have /dev/dri under devices.

You should learn a lot about Docker Compose, because it will help you tremendously. I use Jellyfin behind an Nginx Proxy Manager reverse proxy. I’d highly recommend it. Here’s my compose file for that:

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    network_mode: "host"
    #ports:
    #  - '80:80'
    #  - '81:81'
    #  - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Running in “host” mode is important, instead of just forwarding ports, because it lets you forward things to localhost, like pointing https://media/.[mydomain]/ to http://127.0.0.1:8096/ for Jellyfin.

Anyway, best of luck to you, and I hope that helps!

Use Portainer if you don’t want anything to be portable. There are other issues too. Just use Docker Compose.

Is there a reason you’re not using Docker?

Aw, they’re sharing their bottles of soda with each other. And it’s definitely not anything other than that.

Because the Android SDK is owned and controlled by Google. They’ve consistently made decisions to make it harder to stay out of their ecosystem (like the new “Integrity” API).

As consumers, we would vastly benefit from having another choice that isn’t controlled by one of the biggest tech companies in the world.

I like how their idea of entry level is a 16GB RAM phone for €890.

Probably because they never thought to change it to FUCKBOI.

We honestly should rename GIMP. It’s a bad name. I think a new and better acronym would substantially improve brand recognition. Something like:

Free Utility for Creative Kits, Brushes, Overlays, & Imaging

FUCKBOI

Fedora