A good first approximation.
So where in this setup would you mount a network share? Or am additional hard drive for storage? The latter is neither removable nor temporary. Also /run is quite more than what this makes it seem (e.g. user mounts can be located there), there is practically only one system path for executables (/usr/bin)…
Not saying that the graphic is inherently wrong or bad, but one shouldn’t think it’s the end all be all.
You think bland vegetables are your ally? You merely adopted them. I was born in them, molded by them. I didn’t taste flavored veggies until I was already a man, by then they were nothing to me but delicious!
The only hint at the other topic I see is this:
(not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit)
I guess this is about https://www.reddit.com/r/bcachefs/comments/1em2vzf/psa_avoid_debian/, and while I think the title is too broad, the actual message is
If you’re running bcachefs, you’ll want to be on a more modern distro - or building bcachefs-tools yourself.
I don’t consider Kent’s reasoning (also further down the thread) a rant - it might not be the most diplomatic, but he’s not the only one who has problems with Debian’s processes. The xscreensaver developer is another one for similar reasons.
I think, in fairness, bcachefs and Debian currently aren’t a good fit. bcachefs is also in the kernel so users can rest it and report, but it wasn’t meant to be stable; it’s meant to not lose data unrecoverably.
Anyhow, while I think that he’s also not the easiest person on the LKML, I don’t consider him ranting there; and with the author’s and my judgement differing in these points, I’m led to believe that we might also disagree on what qualifies as hostile.
Lastly, while I’m not a big fan of how Rust packaging works, it ensures that the program is built exactly the same on the developer’s and other machines (for users and distributors); it is somewhat ironic to see Debian complain about it, since they do understand the importance of reproducibility.
You must have missed the last half of the post then. Especially the last two paragraphs.
There’s isn’t much more to that issue than that sentence, while all other paragraphs cover the packaging. It’s tangential at best.
The OP is about packaging issues with userspace utilities due to version pinning in Rust. It’s an issue with Rust in general. Kent is not obligated to lock dependencies in any particular fashion. He could loosen the dependencies, but there is no obligation, and Debian has no obligation to package it.
This is different from the thread you linked in which the bcachefs kernel code and the submission process is discussed, and on which there was a thread here as well in the last days. But your criticism, as valid as it is, only applies there, not in a thread about tooling packaging issue.
Which is a completely different issue than what the post is about, hence my question
Submitting something that is generally problematic and yelling about how it will EVENTUALLY be good is a good way to get your shit tossed out.
What are you hinting at regarding this specific news?
Thanks for posting peertube content, it’s time people stop using YouTube
Technically correct, but the settings in there are not service specific. However, if there’s something worthy of reworking it’s probably the Authelia part
Well, a lot of it is just trying stuff out, but let’s say you want to setup Navidrome because you read about it somewhere. My first step is always to go to https://search.nixos.org/options? and search for it, it’ll show you the options available. If you want to know how it’s implemented under the hood, press the “Declared in” link where it shows you the source code of the module, this can sometimes be helpful.
Other than that, read the wiki for examples, and remember that nix is a full language and not just a configuration, so you can keep it flexible.
Thanks for the answer; I do have at least one module in my config, but usually, I don’t enable or disable services like that, it was more of an example of how the configuration is split up and what the advantage of that is. In the end, if the only option is to enable the module, you’re not gaining that much if you need to import and enable it instead of just importing the configuration straight is my opinion.
You can measure anything in nanograms, but a typical LSD dose starts at about 100ug with the threshold at about 25ug or so. Still not much, but not what you’d usually measure in nanograms.
Even when using in a basic way, I think it has one very tangible advantage: the fact that you can “compartmentalize” different aspects of your configuration.
Let’s say I set up a specific web service that I want to put behind a reverse proxy, and it uses a specific folder that doesn’t exist yet, like Navidrome which is a web-based audio player. It requires a set of adjustments of different system parts. My nix file for it looks like this:
{ config, ... }:
let
domain = "music." + toString config.networking.domain;
in
{
services.navidrome = {
enable = true;
settings = {
Address = "127.0.0.1";
Port = 4533;
MusicFolder = "/srv/music";
BaseUrl = "https://" + domain;
EnableSharing = true;
Prometheus.Enabled = true;
LogLevel = "debug";
ReverseProxyWhitelist = "127.0.0.1/32";
};
};
services.nginx = {
upstreams = {
navidrome = {
servers = {
"127.0.0.1:${toString config.services.navidrome.settings.Port}" = {};
};
};
};
};
services.nginx.virtualHosts."${domain}" = {
onlySSL = true;
useACMEHost = config.networking.domain;
extraConfig = ''
include ${./authelia/server.conf};
'';
locations."/" = {
proxyPass = "http://navidrome";
recommendedProxySettings = false;
extraConfig = ''
include ${./authelia/proxy.conf};
include ${./authelia/location.conf};
'';
};
};
systemd.tmpfiles.settings."navidrome-music-dir"."${toString config.services.navidrome.settings.MusicFolder}" = {
d = {
user = "laser";
mode = "0755";
};
};
systemd.services.navidrome.serviceConfig.BindReadOnlyPaths = ["/run/systemd/resolve/stub-resolv.conf"];
security.acme.certs."${config.networking.domain}".extraDomainNames = [ "${domain}" ];
}
All settings related to the service are contained in a single file. Don’t want it anymore? Comment it out from my main configuration (or whereever it’s imported from) and most traces of it are gone, the exception being the folder that was created using systemd.tmpfiles. No manually deleting the link from sites-available or editing the list of domains for my certificate. The next generation will look like the service never existed.
And in my configuration, at least the port could be changed and everything would still work – I guess there is room for improvement, but this does what I want pretty well.
Just to clarify, I wouldn’t recommend putting everything in a single file, but rather modularize the configuration.
I also came from Arch, but have since abandoned it, and I don’t think I want to use distributions for myself that use the the classic imperative concept. One you get a better understanding of it, it makes so much more sense.
Their militia’s (which Wagner group is) strategy is bullying civilians
Encryption? Also you’re assuming there’s only one block device…
assuming the person before did not just mean partitioning, but also all other storage-related tasks
This is the opposite of me. I always get nervous when I don’t have precise control over how the disk layout looks. I explicitly decided for the non-graphical installer when I first downloaded NixOS
Does it? I have two VMs on remote VPS servers that use GRUB because of no UEFI and I had no issues
I use
/mnt/$proto/$server, though that level of organization was probably overkill. Whatever…