klangcola

joined 2 years ago
[–] klangcola@reddthat.com 7 points 1 month ago (1 children)

My gut reaction too. But their readme/faq makes a lot of sound points. Also Nextcloud is one of the main contributors, so you know it's serious. Also Proton and Ionos (which I admit I'd never heard of, but they seem big)

[–] klangcola@reddthat.com 5 points 1 month ago (2 children)

You might be interested in an immutable distro. Like Bazzite or other Silverblue / Ublue flavoured system. They are recent but not bleeding edge, deploy well tested images that apply as all-or-nothing. Very stable, very featurful :)

[–] klangcola@reddthat.com 4 points 2 months ago

For actual advice:

  • run memtest to verify RAM. Do multiple passes, at least overnight.
  • Check cooling? RAM and other things can overheat and cause locks, not just CPU.
  • Can you throw a couple of different distros on there, to try different permutations of kernel and drivers, old and new.
  • journalctl --follow (with sudo), dmesg -w. I ran these over ssh from a remote machine. Even better if you can run it on a local 2nd monitor. The point is to have them open the whole time since it's too late to change once the system is locked up
[–] klangcola@reddthat.com 7 points 2 months ago* (last edited 2 months ago) (1 children)

I had / have a similar issue that started at some point on my Ryzen 7 laptop with Kubuntu 24.04. I haven't tried REISUB yet, but otherwise same symptoms.

RAM is the usual suspect. I ran memtest for 24h++ with no errors Also tailed dmesg and journalctl to a remote machine, and checked journalctl after reboot. No errors reported. Presumably because the system hard locked before it had a chance to log the error.

I never found a root cause, but after I changed the KDE Power Profile from Eco to either Balanced or Power (I don't remember which) the random freezing reduced from 1-3 times per day to once every few weeks of continuous uptime.

So my guess is some kernel driver bug relating to power states of the CPU ( or GPU nVidia 3060 with 590 drivers)

[–] klangcola@reddthat.com 4 points 2 months ago

Doesn't work in my experience, or I'm typing it wrong. I can use the journalctl boot filter to show the current boot, the 2 boots ago, but not the previous boot where the system crashed.

So I end up filtering by time instead with --since

[–] klangcola@reddthat.com 51 points 2 months ago (1 children)

There's strong Farquaad vibes here..

Some of you may die, but that's a sacrifice I'm willing to make

[–] klangcola@reddthat.com 4 points 2 months ago

You can subscribe to a peertube channel with a Mastodon account if you want

[–] klangcola@reddthat.com 8 points 3 months ago (1 children)

Good catch, that licence does not look very Libre =\

[–] klangcola@reddthat.com 8 points 3 months ago (4 children)

That's neat :) I like the concept of a collection of warm&fuzzies symbols

How are you making the stickers? It looks like each sticker is composite of multiple snippets of art?

[–] klangcola@reddthat.com 4 points 3 months ago (1 children)

Verified just means we can believe that they are who they say they are. Doesn't mean that they're trustworthy or believable. Or to put it another way: The identity of their account is verified. The contents of their posts are not verified.

I don't agree with the point OP is trying to make in this instance regarding verification. (Letting that well documented lethally violent gang of thugs use their platform is Bluesky's actual transgression here)

[–] klangcola@reddthat.com 5 points 3 months ago* (last edited 3 months ago) (3 children)

The will to do so.

Also finding an instance to register on that won't ban them for

No incitement of violence or promotion of violent ideologies

(Rule 3 on mastodon.social)

[–] klangcola@reddthat.com 4 points 3 months ago (5 children)

Yes, though it works a bit differently.

In your mastodon bio you link to your other precenses on the web (webpage, twitter, GitHub, whatever)

On those profiles you add an (invisible) link to your mastodon profile. Mastodon can then verify that your mastodon profile and your other sites are controlled by the same entity, and get a blue tick.

 

What are the pros and cons of using Named vs Anonymous volumes in Docker for self-hosting?

I've always used "regular" Anonymous volumes, and that's what is usually in official docker-compose.yml examples for various apps:

volumes:
  - ./myAppDataFolder:/data

where myAppDataFolder/ is in the same folder as the docker-compose.yml file.

As a self-hoster I find this neat and tidy; my docker folder has a subfolder for each app. Each app folder has a docker-compose.yml, .env and one or more data-folders. I version-control the compose files, and back up the data folders.

However some apps have docker-compose.yml examples using named volumes:

services:
  mealie:
    volumes:
      - mealie-data:/app/data/
volumes:
  mealie-data:

I had to google documentation https://docs.docker.com/engine/storage/volumes/ to find that the volume is actually called mealie_mealie-data

$ docker volume ls
DRIVER    VOLUME NAME
...
local     mealie_mealie-data

and it is stored in /var/lib/docker/volumes/mealie_mealie-data/_data

$ docker volume inspect mealie_mealie-data
...
  "Mountpoint": "/var/lib/docker/volumes/mealie_mealie-data/_data",
...

I tried googling the why of named volumes, but most answers were talking about things that sounded very enterprise'y, docker swarms, and how all state information should be stored in "the database" so you shouldnt need to ever touch the actual files backing the volume for any container.

So to summarize: Named volumes, why? Or why not? What are your preferences? Given the context that we are self-hosting, and not running huge enterprise clusters.

view more: next ›