klangcola

joined 2 years ago
[–] klangcola@reddthat.com 1 points 2 months ago

Also it's only a tax on overnight stays. Which some small towns and rural counties overwhelmed by day-travelers are not happy about.

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

And Iceland! More islands more better

[–] klangcola@reddthat.com 3 points 3 months ago

Ugh, me neither. Bought by Snap-On according to Wikipedia:

Bahco is a Swedish brand within the hand tool industry, which is now part of SNA Europe, part of Snap-on.

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

Same for Cocraft as far as I know (Clas Ohlson white label)

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

No, full stack made in Europe. From silicon (microchips) upwards. Including cloud platforms, e-commerce, AI, and more.

Hopefully they'll funnel a lot of investment in to growing and adopting existing open source projects from Europe.
Image for example if all EU institutions used their Office 365 license fees and instead invested in LibreOffice development, and all adopted LibreOffice

[–] klangcola@reddthat.com 1 points 3 months ago

SingleFile provides a faithful representation of the original webpage, so bloated webpages are indeed saved as bloated html files.

On the plus side you're getting an exact copy, but on the downside an exact copy may not be necessary and takes a huge amount of space.

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

SingleFile is a browser addon to save a complete web page into a single HTML file. SingleFile is a Web Extension (and a CLI tool) compatible with Chrome, Firefox (Desktop and Mobile), Microsoft Edge, Safari, Vivaldi, Brave, Waterfox, Yandex browser, and Opera.

SingleFile can also be integrated with bookmark managers hoarder and linkding browser extensions. So your browser does the capture, which means you are already logged in, have dismissed the cookie banner, solved the capthas or whatever else annoyance is on the webpage.

ArchiveBox and I believe also Linkwarden use SingleFile (but as CLI from the server side) to capture web pages, as well as other tools and formats. This works well for simple/straightforward web pages, but not for annoying we pages with cookie banners, capthas, and other popups.

[–] klangcola@reddthat.com 5 points 3 months ago

Lol, I'm just over a week in to learning NixOS and this feels so true 😂

I feel like I'm just starting on the incline, luckily I don't have any sturdy rope on hand 😂

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

Reading your post again, you should start by moving your docker management from CasaOS to vanilla docker-compose files, and keep them in a git repo.

I still think you definitely should look in to NixOS and what it can offer, cause it seems like that is where your mindset is going.

But NixOS is a drastic change, you should start by just converting your individual services one by one from CasaOS management to docker-compose files. One compose file for all services is possible, but I would recommend one compose file for each service. Later you can move from Debian to NixOS while using the same docker-compose files.

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

I would like to have a system when I know what I did, what is opened/installed/activated and what is not

You sound like you need to to look in to Nix and NixOS. The TLDR is that everything is declared in a configuration file(s), which you can and should back up in git. The config files tell you exactly what you did , and the config file comments together with git commit history tell you why.

The whole system is built from this configuration file. Rollback is trivially easy, either by rebooting and selecting an older build during the boot manager, or reverting to an older git commit and rebuilding (no reboot required, so usually faster)

Now fair warning, Nix (and NixOS) is a big topic, very different from normal way of thinking about software distribution and OS. Nix is not for everyone.

You should also at the very least have a git repo for docker-compose files for your services. Again, that will declaratively tell you what you did and why.

Also, if NixOS is too extreme, you should also look in to declarative management tools like Ansible etc

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

Edit: somehow forgot that HA sell their own devices, HomeAssistant Green for 100$ and HomeAssistant Yellow which also supports the project.

Original comment: Highly recommend a used "enterprise mini PC" from Dell , HP or Lenovo. Get it from your local IT refurbisher, eBay or your local ebay-equivelent.
These are sometimes called 1L PCs for their 1 Litre size. Model names are Dell Optiplex, HP Elite desk or Prodesk, Lenovo Think centre. Prices are €100 to €1500 depending on age and specs. €150 should be more than enough for HomeAssistant.

Alternatively https://slimbook.com/en/ sells Linux PCs out of Spain, and https://www.tuxedocomputers.com/ out of Germany.

Another option is the british RaspberryPi, but that might be more hassle. You need to separately get a good power supply and cable, good SD-Card, case, maybe with fan. And its ARM not x86, but that doesn't matter for HomeAssistant unless you're doing something very exotic.

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

Not a problem when self-hosting on own hardware. Especially in winter. Overly complicated spaceheater goes brrrr

 

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 ›