4 ms·

A small suggestion about resources: try using NixOS/Guix System instead of containers to deploy home services, you'll discover that in a fraction of resources y

by kkfx 2y ago

A small suggestion about resources: try using NixOS/Guix System instead of containers to deploy home services, you'll discover that in a fraction of resources you get much more, stability, documentation and easy replication included. Containers now, like full-stack virtualization on x86 are and was advertisement stuff pushed because proprietary software vendors and cloud providers need them, other do not need them at all and devs who works for themselves and generic users should learn that: if you sell VPS et al. obviously you need them, if you made your own infra from bare metal adding them it's just wasting resources and add dependencies instead of simplify life.

snowpalmer 2y ago
I agree that removing the container would be better on resources. However, most self-hosted software is already "pre-packaged" in Docker containers. It's much easier to grab that "off-the-shelf" than have to build out something custom.
- transpute 2y ago
  NixOS improves the reproducibility of both self-hosted software and configuration state.
- kkfx 2y ago
  In NixOS/Guix System there is no need of such package, the configuration language/package manager takes care of anything, configuration included. Let's say you want Jellyfin? jellyfin = { enable = true; user="whatyouwant"; }; # jellyfin under services and you get it. You want a more complex thing, let's say Paperless? paperless = { enable = true; address = "0.0.0.0"; port = 58080; mediaDir = "/var/lib/paperless/media"; dataDir = "/var/lib/paperless/data"; consumptionDir = "/var/lib/paperless/importdir"; consumptionDirIsPublic = true; settings = { PAPERLESS_AUTO_LOGIN_USERNAME = "admin"; PAPERLESS_OCR_LANGUAGE = "ita+eng+fra"; PAPERLESS_OCR_SKIP_ARCHIVE_FILE = "with_text"; PAPERLESS_OCR_USER_ARGS = { optimize = 1; pdfa_image_compression = "auto"; continue_on_soft_render_error = true; invalidate_digital_signatures = true; }; # PAPERLESS_OCR_USER_ARGS }; # settings }; # services.paperless Chromium with extensions etc? chromium = { enable = true; # see Chrome Web Store ext. URL extensions = [ "cjpalhdlnbpafiamejdnhcphjbkeiagm" # ublock origin "pkehgijcmpdhfbdbbnkijodmdjhbjlgp" # privacy badger "edibdbjcniadpccecjdfdjjppcpchdlm" # I still don't care about cookies "ekhagklcjbdpajgpjgmbionohlpdbjgc" # Zotero Connector # ... ]; # extensions # see https://chromeenterprise.google/policies/ extraOpts = { "BrowserSignin" = 0; "SyncDisabled" = true; "AllowSystemNotifications" = true; "ExtensionManifestV2Availability" = 3; # sino a 06/25 "AutoplayAllowed" = false; "BackgroundModeEnabled" = false; "HideWebStorePromo" = false; "ClickToCallEnabled" = false; "BookmarkBarEnabled" = true; "SafeSitesFilterBehavior" = 0; "SpellcheckEnabled" = true; "SpellcheckLanguage" = [ "it" "fr" "en-US" ]; }; # extraOpts }; # chromium Etc etc etc. You configure the entire deploy and get it generated, a custom live? With auto-partitioning and auto-install? Idem. A set of hosts in a network similar (NixOps/Disnix) and so on. The configuration language do all, fetching sources and build if a pre-built binary is not there, setting up a DB, setting up NGINX+let's encrypt SSL certs, there are derivation (package) per derivation options you can set, some you MUST set, defaults etc., it's MUCH easier than anything else, only issue is how many ready-made derivations are there, and in packaging terms Guix is very well placed, NixOS is more than Arch, even if something will be always not there or incomplete as long as devs do not learn alone the system and start using Nix/Guix also to develop, so deps are really tested in dedicated environments and so on, and users always get a clean system, can change and boot in a previous version and so on.
  - stackskipton 2y ago
    Sigh Nix users. I need to run uptime kuma, Here is Docker Compose: https://github.com/louislam/uptime-kuma/blob/1.23.X/docker/docker-compose.yml https://github.com/louislam/uptime-kuma/blob/1.23.X/docker/d... What is equivalent in Nix?
    - zarzavat 2y ago
      Nix/NixOS and Docker work in fundamentally different ways so you have to decide which method of operation is most suitable for your use case. If you use Docker then each container requires its OS image, which is fine if you’re running on a server and running other people’s software, but if you want to develop your own containers on a laptop then that convenience becomes an inconvenience. Nix is more lightweight.
    - kkfx 2y ago
      services.uptime-kuma = { enable = true; appriseSupport = true; settings = { ... } # settings }; These are examples, you have to write down the system configuration, meaning picking uptime-kuma, choose what deps you want and so on. No need to "run a oneliner" on a homeserver than ssh and do things by hand to tweaks, with no reproducibility or hoping someone else have already made them in something ready-made. Doing the pick-a-oneliner is a classic developer in Silicon Valley mode move which cause a classic set of disasters, like wasting gazillion of resources for nothing, not seen an image with someone else ssh authorized key, keep running vulnerable software and so on because he/she just need a oneliner, no matter if it pull down 10 images, consuming 1Tb of storage, having stellar CPU requirements etc because you are in SV-mode, you do not care and anyway you do not pay for the iron because it's a company one or it's a cloud service you do not even see how much loads you generate, AWS bill will go to someone in accounting. On the other side of course IT business like that, because they can sell you a ready made image, selling just few line of code can't be priced much, while selling a service who provide a big file set might be priced well. Also selling a VPS and so on "hey devs, you literally just need to click here and we do the rest" pay very well. Those who sell of course. Aside such mindset create an enormous amount of layers who in the long run create so heavy and complex infra no one knows them. Just try to see what Home-assistant do. By default their devs suggest to run it on a dedicated machine (!) so they imaging you buy a single-board computer juts to run a damn app, ending up with this model with a gazillion of single board computer scattering around. Second option containers. So to run HA you need let's say 1-3Gb of stuff, nearly no mention to the simplest pip install. Zero mention that unlike pip install NixOS does not need to download a gazillion of binary basic stuff for python deps, if you have them on your /nix/store you just link them on as many pkgs needs them, keeping just one copy. In the end you craft your system, as a single application, a single configuration, which demand 1/10 of resources used otherwise, have much less thing who can breaks, it's easy to know entirely etc. You might state that's a classic operation vs devs.
- pxc 2y ago
  > However, most self-hosted software is already "pre-packaged" in Docker containers. It's much easier to grab that "off-the-shelf" than have to build out something custom. Imo, the quality and documentation level of an application's build system is a valuable signal in determining its overall health and competency. It usually (though not always) ends up being that well-maintained software written for modern runtimes is very easy to build from source and run. Even if I do end up using the developer's container image, I generally want to check out their manual deployment documentation.
otter-in-a-suit 2y ago
We use nix at work. I'm not a huge fan - I find it too opinionated. Appreciate it for what it is, though, and understand its fans. Since at $work, we run K8s + containers in some shape or form (as well as in... basically all previous jobs), using the tech that I use in the "real world" at home is somewhat in line with my reasoning about why the time investment for self hosting is worth it as a learning exercise.
VTimofeenko 2y ago
Containers allow running software that does not have a nix package available and one could not be bothered to write. My lab is fully on NixOS, but a couple of services are happily chugging along as containers in podman.
- kkfx 2y ago
  So you prefer manually handling such containers, that you probably do not really know enough, perhaps even for serious usage, instead of writing a derivation? No reproducibility etc For quick testing something, nothing to say, but for real, albeit personal homelab, usage...
  - pxc 2y ago
    An escape hatch like that can be really nice for trying software out on a temporary basis, before you know if you care about it enough to write a package and a service module. Given time limitations, I can imagine living with some applications like that for quite some time, their packaging sitting at the bottom of a long todo list. :)
    - kkfx 2y ago
      Now dream, it's a dream, but perfectly feasible technically, where most devs have found and understood the NixOS/Guix System way to develop and manage whole deploy. We would have various distro with different configuration languages like Nix and Guix, and some less diverse, since all devs simply "package", meaning describing, their code in their own distro how hard could be port the derivation/description? Try also compute how hw requirement for whole infra plunge thanks to an immense overhead avoided on scale. The sole unhappy? Those who sell services, because for that they do need containers. This would push another evolution: built-in easy to tune isolation from a config, so they can sell instead of a VPS a system where you upload just your config, they import it, producing an isolated FHS for you, something we already have (i.e. FHSUserEnv) but with tunable system isolation. You would get your VPS, configured with just few SLoC instead of manually/in wrapped ways via SSH, and they can sell much more on the same iron, with much better performances as well. All of the above is perfectly possible TODAY, it's only a matter of mass knowledge or lack thereof.
apitman 2y ago
I've heard good things about Nix's dependency management. Does it seamlessly handle the case where you have 3 different apps that all require 3 different version of python with different python dependencies? Also, does it offer any isolation between apps and between apps and the OS, especially the filesystem?
- Arelius 2y ago
  > Does it seamlessly handle the case where you have 3 different apps that all require 3 different version of python with different python dependencies? Ohh yes! That is exactly what it does on a repeatable and documented way.. But it also does a lot of work to do this. And doesn't hide the systems of that so much. So that means you're likely to have yo care about how it does all that work. And if you start doing something weird, might have to do a lot of work yourself..
- granra 2y ago
  The first, yes. The second, you can do this by setting certain options in the systemd service for your apps, but this is true for any systemd distro.
- kkfx 2y ago
  Yes by design, meaning you do not have an FHS structure where "installing" means copy this in /usr/share, this in /usr/lib ... Alla packages just see a small "virtual" root tree, meaning a network of symlinks. You can choose for package A to se package B and C, but not D, different versions means simply different packages because you have package alone, let's say the current stable version but also package_major_minor for various supported major or minor version. As well as you can choose to fetch sources from a specific commit from a public repo, build them and link them in the system. Every package is not "isolated" in the container self, like small userlands on a common kernel, but in the sense of "having different views of the common system", so you avoid wasting gazzilion of storage and ram and CPU plus anything is still from the upstream or yourself, there are no outdated forgotten deps left around. Plus being anything configured in the config (well, not mandatory, but that's the typical way) you have a fully reproducible system, maybe not binary-reproducible meaning "packageA now is version x.y" when you rebuild the system, but anything could be rebuild in the current state of nixpkgs/guix states from few kb of text, typically versioned in a repo. Every update does not overwrite anything, if put some new versions in a special tree /nix/store o /gnu/store and updates symlinks accordingly, if it does not work you restore the previous state instead/before garbage collection. Practically it do the same of IllumOS with IPS (the package manager) integrated with zfs (and the bootloader), here instead of zfs clones and snapshots you have a poor man's version with symlinks. There is no isolation by default, meaning it's a single system, but you can "portion" the system in various ways. Of course on Linux there are no IllumOS zones of FreeBSD jails, the state of paravirtualisation it's very behind those unices.

by kkfx 2y ago

snowpalmer 2y ago

I agree that removing the container would be better on resources. However, most self-hosted software is already "pre-packaged" in Docker containers. It's much easier to grab that "off-the-shelf" than have to build out something custom.

transpute 2y ago
NixOS improves the reproducibility of both self-hosted software and configuration state.
kkfx 2y ago
In NixOS/Guix System there is no need of such package, the configuration language/package manager takes care of anything, configuration included. Let's say you want Jellyfin? jellyfin = { enable = true; user="whatyouwant"; }; # jellyfin under services and you get it. You want a more complex thing, let's say Paperless? paperless = { enable = true; address = "0.0.0.0"; port = 58080; mediaDir = "/var/lib/paperless/media"; dataDir = "/var/lib/paperless/data"; consumptionDir = "/var/lib/paperless/importdir"; consumptionDirIsPublic = true; settings = { PAPERLESS_AUTO_LOGIN_USERNAME = "admin"; PAPERLESS_OCR_LANGUAGE = "ita+eng+fra"; PAPERLESS_OCR_SKIP_ARCHIVE_FILE = "with_text"; PAPERLESS_OCR_USER_ARGS = { optimize = 1; pdfa_image_compression = "auto"; continue_on_soft_render_error = true; invalidate_digital_signatures = true; }; # PAPERLESS_OCR_USER_ARGS }; # settings }; # services.paperless Chromium with extensions etc? chromium = { enable = true; # see Chrome Web Store ext. URL extensions = [ "cjpalhdlnbpafiamejdnhcphjbkeiagm" # ublock origin "pkehgijcmpdhfbdbbnkijodmdjhbjlgp" # privacy badger "edibdbjcniadpccecjdfdjjppcpchdlm" # I still don't care about cookies "ekhagklcjbdpajgpjgmbionohlpdbjgc" # Zotero Connector # ... ]; # extensions # see https://chromeenterprise.google/policies/ extraOpts = { "BrowserSignin" = 0; "SyncDisabled" = true; "AllowSystemNotifications" = true; "ExtensionManifestV2Availability" = 3; # sino a 06/25 "AutoplayAllowed" = false; "BackgroundModeEnabled" = false; "HideWebStorePromo" = false; "ClickToCallEnabled" = false; "BookmarkBarEnabled" = true; "SafeSitesFilterBehavior" = 0; "SpellcheckEnabled" = true; "SpellcheckLanguage" = [ "it" "fr" "en-US" ]; }; # extraOpts }; # chromium Etc etc etc. You configure the entire deploy and get it generated, a custom live? With auto-partitioning and auto-install? Idem. A set of hosts in a network similar (NixOps/Disnix) and so on. The configuration language do all, fetching sources and build if a pre-built binary is not there, setting up a DB, setting up NGINX+let's encrypt SSL certs, there are derivation (package) per derivation options you can set, some you MUST set, defaults etc., it's MUCH easier than anything else, only issue is how many ready-made derivations are there, and in packaging terms Guix is very well placed, NixOS is more than Arch, even if something will be always not there or incomplete as long as devs do not learn alone the system and start using Nix/Guix also to develop, so deps are really tested in dedicated environments and so on, and users always get a clean system, can change and boot in a previous version and so on.
- stackskipton 2y ago
  Sigh Nix users. I need to run uptime kuma, Here is Docker Compose: https://github.com/louislam/uptime-kuma/blob/1.23.X/docker/docker-compose.yml https://github.com/louislam/uptime-kuma/blob/1.23.X/docker/d... What is equivalent in Nix?
  - zarzavat 2y ago
    Nix/NixOS and Docker work in fundamentally different ways so you have to decide which method of operation is most suitable for your use case. If you use Docker then each container requires its OS image, which is fine if you’re running on a server and running other people’s software, but if you want to develop your own containers on a laptop then that convenience becomes an inconvenience. Nix is more lightweight.
  - kkfx 2y ago
    services.uptime-kuma = { enable = true; appriseSupport = true; settings = { ... } # settings }; These are examples, you have to write down the system configuration, meaning picking uptime-kuma, choose what deps you want and so on. No need to "run a oneliner" on a homeserver than ssh and do things by hand to tweaks, with no reproducibility or hoping someone else have already made them in something ready-made. Doing the pick-a-oneliner is a classic developer in Silicon Valley mode move which cause a classic set of disasters, like wasting gazillion of resources for nothing, not seen an image with someone else ssh authorized key, keep running vulnerable software and so on because he/she just need a oneliner, no matter if it pull down 10 images, consuming 1Tb of storage, having stellar CPU requirements etc because you are in SV-mode, you do not care and anyway you do not pay for the iron because it's a company one or it's a cloud service you do not even see how much loads you generate, AWS bill will go to someone in accounting. On the other side of course IT business like that, because they can sell you a ready made image, selling just few line of code can't be priced much, while selling a service who provide a big file set might be priced well. Also selling a VPS and so on "hey devs, you literally just need to click here and we do the rest" pay very well. Those who sell of course. Aside such mindset create an enormous amount of layers who in the long run create so heavy and complex infra no one knows them. Just try to see what Home-assistant do. By default their devs suggest to run it on a dedicated machine (!) so they imaging you buy a single-board computer juts to run a damn app, ending up with this model with a gazillion of single board computer scattering around. Second option containers. So to run HA you need let's say 1-3Gb of stuff, nearly no mention to the simplest pip install. Zero mention that unlike pip install NixOS does not need to download a gazillion of binary basic stuff for python deps, if you have them on your /nix/store you just link them on as many pkgs needs them, keeping just one copy. In the end you craft your system, as a single application, a single configuration, which demand 1/10 of resources used otherwise, have much less thing who can breaks, it's easy to know entirely etc. You might state that's a classic operation vs devs.
pxc 2y ago
> However, most self-hosted software is already "pre-packaged" in Docker containers. It's much easier to grab that "off-the-shelf" than have to build out something custom. Imo, the quality and documentation level of an application's build system is a valuable signal in determining its overall health and competency. It usually (though not always) ends up being that well-maintained software written for modern runtimes is very easy to build from source and run. Even if I do end up using the developer's container image, I generally want to check out their manual deployment documentation.

otter-in-a-suit 2y ago

We use nix at work. I'm not a huge fan - I find it too opinionated. Appreciate it for what it is, though, and understand its fans. Since at $work, we run K8s + containers in some shape or form (as well as in... basically all previous jobs), using the tech that I use in the "real world" at home is somewhat in line with my reasoning about why the time investment for self hosting is worth it as a learning exercise.

VTimofeenko 2y ago

Containers allow running software that does not have a nix package available and one could not be bothered to write. My lab is fully on NixOS, but a couple of services are happily chugging along as containers in podman.

kkfx 2y ago
So you prefer manually handling such containers, that you probably do not really know enough, perhaps even for serious usage, instead of writing a derivation? No reproducibility etc For quick testing something, nothing to say, but for real, albeit personal homelab, usage...
- pxc 2y ago
  An escape hatch like that can be really nice for trying software out on a temporary basis, before you know if you care about it enough to write a package and a service module. Given time limitations, I can imagine living with some applications like that for quite some time, their packaging sitting at the bottom of a long todo list. :)
  - kkfx 2y ago
    Now dream, it's a dream, but perfectly feasible technically, where most devs have found and understood the NixOS/Guix System way to develop and manage whole deploy. We would have various distro with different configuration languages like Nix and Guix, and some less diverse, since all devs simply "package", meaning describing, their code in their own distro how hard could be port the derivation/description? Try also compute how hw requirement for whole infra plunge thanks to an immense overhead avoided on scale. The sole unhappy? Those who sell services, because for that they do need containers. This would push another evolution: built-in easy to tune isolation from a config, so they can sell instead of a VPS a system where you upload just your config, they import it, producing an isolated FHS for you, something we already have (i.e. FHSUserEnv) but with tunable system isolation. You would get your VPS, configured with just few SLoC instead of manually/in wrapped ways via SSH, and they can sell much more on the same iron, with much better performances as well. All of the above is perfectly possible TODAY, it's only a matter of mass knowledge or lack thereof.

apitman 2y ago

I've heard good things about Nix's dependency management. Does it seamlessly handle the case where you have 3 different apps that all require 3 different version of python with different python dependencies? Also, does it offer any isolation between apps and between apps and the OS, especially the filesystem?

Arelius 2y ago
> Does it seamlessly handle the case where you have 3 different apps that all require 3 different version of python with different python dependencies? Ohh yes! That is exactly what it does on a repeatable and documented way.. But it also does a lot of work to do this. And doesn't hide the systems of that so much. So that means you're likely to have yo care about how it does all that work. And if you start doing something weird, might have to do a lot of work yourself..
granra 2y ago
The first, yes. The second, you can do this by setting certain options in the systemd service for your apps, but this is true for any systemd distro.
kkfx 2y ago
Yes by design, meaning you do not have an FHS structure where "installing" means copy this in /usr/share, this in /usr/lib ... Alla packages just see a small "virtual" root tree, meaning a network of symlinks. You can choose for package A to se package B and C, but not D, different versions means simply different packages because you have package alone, let's say the current stable version but also package_major_minor for various supported major or minor version. As well as you can choose to fetch sources from a specific commit from a public repo, build them and link them in the system. Every package is not "isolated" in the container self, like small userlands on a common kernel, but in the sense of "having different views of the common system", so you avoid wasting gazzilion of storage and ram and CPU plus anything is still from the upstream or yourself, there are no outdated forgotten deps left around. Plus being anything configured in the config (well, not mandatory, but that's the typical way) you have a fully reproducible system, maybe not binary-reproducible meaning "packageA now is version x.y" when you rebuild the system, but anything could be rebuild in the current state of nixpkgs/guix states from few kb of text, typically versioned in a repo. Every update does not overwrite anything, if put some new versions in a special tree /nix/store o /gnu/store and updates symlinks accordingly, if it does not work you restore the previous state instead/before garbage collection. Practically it do the same of IllumOS with IPS (the package manager) integrated with zfs (and the bootloader), here instead of zfs clones and snapshots you have a poor man's version with symlinks. There is no isolation by default, meaning it's a single system, but you can "portion" the system in various ways. Of course on Linux there are no IllumOS zones of FreeBSD jails, the state of paravirtualisation it's very behind those unices.