gomp

My 12yo niece will come visit this summer and I'm thinking of taking her on a photowalk (or more, if she ends up enjoying it).

Should we go with just my camera or should she have her own? (and in case, should I get her a "proper" one or a simpler/compact one?)

Can you share your experience in introducing young boys/girls to photography?

I'm rebuilding my home server in nixos.

Rather that configuring the various services natively in nixos, I decided to run containers via virtualisation.oci-containers whenever possible, mostly to be able to independently update the system and the various services.

Everything is going smoothly, but whenever I (for whatever reason) do nixos-rebuild boot and reboot after adding a container instead of nixos-rebuild switch, I run into this issue where podman isn't able to resolve the host (below you see the docker hub host, but it also happened with ghcr.io):

podman-apprise-start[1352]: Trying to pull docker.io/caronc/apprise:1.1.8...
podman-apprise-start[1352]: Pulling image //caronc/apprise:1.1.8 inside systemd: setting pull timeout to 5m0s
podman-apprise-start[1352]: Error: initializing source docker://caronc/apprise:1.1.8: pinging container registry registry-1.docker.io: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io: no such host

I thought that my podman-* services were missing a dependency on network-online and that they were started before the network was available, but it is't the case:

# systemctl list-dependencies podman-apprise.service 
podman-apprise.service
● ├─system.slice
● ├─network-online.target
● │ └─systemd-networkd-wait-online.service
● └─sysinit.target
●   ├─dev-hugepages.mount
[...snip...]

Do you happen to know what the issue is?

PS: Manually running systemctl start podman-whatever once fixes the issue, of course, but I wonder if there's a more robust solution?

update:

After investigating based on balsoft input below, the issue seems to be that systemd-networkd-wait-online doesn't behave as expected (by me).

Basically, systemd-networkd-wait-online waits for network interfaces to have a carrier (working ethernet cable) and an IP address. This is what in systemd-networkd docs is called the "degraded" state (no, it doesn't mean that something got worse than before... don't think too much of what "degraded" implies in English).

In my case, I have an interface that is setup via DHCP and that also has static IPs assigned:

$ cat /etc/systemd/network/00-lan1.network 
[Match]
Name=lan1

[Network]
DHCP=ipv4
IPv6AcceptRA=no
LinkLocalAddressing=no

[Address]
Address=192.168.10.10/24

[Address]
Address=192.168.10.99/24

If you are wondering, the reason I do this is that I want static IPs for my dns server and reverse proxy, but I also want my home server to use DHCP to fetch some network-wide configuration which, critically, includes the default route.

Back to the issue: IIUC, since the interface has a non-link-local address (which systemd-networkd confusingly calls a "routable" address), it is immediately considered "routable" (a state that is moar better than "degraded") and so not only it's basically ignored by the default systemd-networkd-wait-online configuration, but even adding

[Link]
RequiredForOnline=routable

to /etc/systemd/network/00-lan1.network doesn't make a difference whatsoever.

For now, my stopgap solution is to explicitly set the default route for the "lan1" network:

[Network]
Gateway=192.168.10.1

this seems to solve the issue with podman and, while the system still thinks to be "online" before being fully configured, it will suffice until I find a more elegant/robust way (ping me in a while if you are interested).

refs:
systemd-networkd-wait-online man page
systemd-networkd docs on "RequiredForOnline"
networkctl man page

I remember a story where people asked about blobs included in Ventoy and there were no comments from the devs, leading to suspicion.

At the time it wasn't clear to me if there was any substance to the story or if it was the usual Internet exaggeration, so I resolved to ignore it for the time being and saved a reminder to look into it after a while.

Now my reminder fired off and I looked around, but couldn't find how the story ended... do you know?

I have two functions that are similar but can fail with different errors:

#[derive(Debug, thiserror::Error)]
enum MyError {
  #[error("error a")]
  MyErrorA,
  #[error("error b")]
  MyErrorB,
  #[error("bad value ({0})")]
  MyErrorCommon(String),
}

fn functionA() -> Result<String, MyError> {
  // can fail with MyErrorA MyErrorCommon
  todo!()
}

fn functionB() -> Result<String, MyError> {
  // can fail with MyErrorB MyErrorCommon
  todo!()
}

Is there an elegant (*) way I can express this?

If I split the error type into two separate types, is there a way to reuse the definition of MyErrorCommon?

(*) by "elegant" I mean something that improves the code - I'm sure one could define a few macros and solve that way, but I don't want to go there

edit: grammar (rust grammar)

I experimented with several ways to run my services:

1. "regular" systemd services (services.glance = { ... };)
2. nix containers (containers.glance = { ... };)
3. podman containers (virtualisation.oci-containers.containers.glance = { ... })

and I must say I'm starting to appreciate the last option (the least nixos-y) more and more.

Specifically, I appreciate that:

• I just have to learn the app/container configuration, instead of also backwards-translating from their config into the various nixos options (of course the .yaml or whatever configuration files are still generated from my nixos config, I just do that in a derivation instead on relying on a module doing it for me)
• Services are sometimes outdated in nixpks (even in unstable - and juggling packages between stable and unstable is yet another complication)
• I feel like it's more secure (very arguable and also of very little consequence since everything is on my homelab... it's mainly for the warm fuzzies)

Do you guys use one of the options above? Something different?

edit: for the solution, see my comment below

I'm trying to package a go application (beszel) that bundles a bunch of html stuff built with bun (think, npm).

The html is generated by running bun install and bun run and then embedded in the go binary with //go:embed.

Being completely ignorant of the javascript ecosystem, my first idea was to just replicate what they do in the Makefile

postConfigure = ''
bun install --cwd ./site
bun run     --cwd ./site build
'' 

but, since bun install downloads dependencies from the net, that fails.

I guess the "clean" solution would be to look for buildNpmPackage or similar (assuming that exists) and let nix manage all the dependencies, but... it's some 800+ dependencies (at least, bun install ... --dry-run lists 800+ things) so that's a hard pass.

I then tried to look at how buildGoPackage handles the vendoring of dependencies, with the idea of replicating that (it dowloads what's needed and then compare a hash of what was downloaded with a hash provided in the nix package definition), but... I can't for the life of me decipher how nixpkgs' pkgs/build-support/go/module.nix works.

Do you know how to implement this kind of vendoring in a nix derivation?

If I navigate to https://lemmy.ml/c/simplex the page behaves as if I'm not logged in (eg. I see the "login" and "signup" at the top-right link instead of my profile).

I visited other communities (including this one I'm posting on) and they seem fine; hard-refreshing the browser doesn't seem to have any effect, nor does logging out of lemmy and authenticating again.

Can someone try and report if it's a bug or some astral conjunction affecting my PC?

edit: It works now. No idea why.

Over the years I have accumulated a sizable music library (mostly flacs, adding up to a bit less than 1TB) that I now want to reorganize (ie. gradually process with Musicbrainz Picard).

Since the music lives in my NAS, flacs are relatively big and my network speed is 1GB, I insalled on my computer a hdd I had laying around and replicated the whole library there; the idea being to work on local files and the sync them to the NAS.

I setup Syncthing for replication and... everything works, in theory.

In practice, Syncthing loves to rescan the whole library (given how long it takes, it must be reading all the data and computing checksums rather than just scanning the filesystem metadata - why on earth?) and that means my under-powered NAS (Celeron N3150) does nothing but rescanning the same files over and over.

Syncthing by default rescans directories every hour (again, why on earth?), but it still seem to rescan a whole lot even after I have set rescanIntervalS to 90 days (maybe it rescans once regardless when restarted?).

Anyway, I am looking into alternatives.
Are there any you would recommend? (FOSS please)

Notes:

• I know I could just schedule a periodic rsync from my PC to the NAS, but I would prefer a bidirectional solution if possible (rsync is gonna be the last resort)
• I read about unison, but I also read that it's not great with big jobs and that it too scans a lot
• The disks on my NAS go to sleep after 10 minutes idle time and if possible I would prefer not waking them up all the time (which would most probably happen if I scheduled a periodic rsync job - the NAS has RAM to spare, but there's no guarantee it'll keep in cache all the data rsync needs)

edit: for the solution, see my comment below

I need/want to build aeson and its subproject attoparsec-aeson from source (it's a fork of the "official" aeson), but I'm stuck... can you help out?

The sources of attoparsec-aeson live in a subdirectory of the aeson ones, so I have the sources:

aeson-src = fetchFromGitHub {
  ...
};

and the "main" aeson library:

aeson = haskellPackages.mkDerivation {
  pname = "aeson";
  src = aeson-src;
  ...
};

When I get to attoparsec-aeson however I run into a wall: I tried to follow the documentation about sourceRoot:

attoparsec-aeson = haskellPackages.mkDerivation {
  pname = "attoparsec-aeson";
  src = aeson-src;
  sourceRoot = "./attoparsec-aeson"; # maybe this should be "${aeson-src}/attoparsec-aeson"?
                                     # (it doesn't work either way)
  ...
};

but I get

 error: function 'anonymous lambda' called with unexpected argument 'sourceRoot'

Did I fail to spot some major blunder (I am nowhere near an expert)? Does sourceRoot not apply to haskellPackages.mkDerivation? What should I do to make it work?

BTW:

IDK if this may cause issues, but the attoparsec-aeson sources include symlinks to files in the "main" attoparsec sources:

~/git-clone-of-attoparsec-sources $ tree attoparsec-aeson/
attoparsec-aeson/
├── src
│   └── Data
│       └── Aeson
│           ├── Internal
│           │   ├── ByteString.hs -> ../../../../../src/Data/Aeson/Internal/ByteString.hs
│           │   ├── Text.hs -> ../../../../../src/Data/Aeson/Internal/Text.hs
│           │   └── Word8.hs -> ../../../../../src/Data/Aeson/Internal/Word8.hs
│           ├── Parser
│           │   └── Internal.hs
│           └── Parser.hs
├── attoparsec-aeson.cabal
└── LICENSE

Lately I noticed that when I want to ssh to a server using a password I need to specify -o PubkeyAuthentication=no or I won't be asked for a password and the authentication will fail (well, for all I know, setting some other option may work too).

I use password authentication only once on freshly installed servers/vms, so it's not a huge deal, but... it still bothers me (mainly because I don't remember which option to set).

Do you guys have any idea what it may be?

Host 127.*.*.* 192.168.*.* 10.*.*.* 172.16.*.* 172.17.*.* 172.18.*.* 172.19.*.* 172.2?.*.* 172.30.*.* 172.31.*.*
  LogLevel quiet
  Stricthostkeychecking no
  Userknownhostsfile /dev/null

Host *
  ForwardAgent no
  AddKeysToAgent no
  Compression yes
  ServerAliveInterval 10
  ServerAliveCountMax 3
  HashKnownHosts no
  UserKnownHostsFile ~/.ssh/known_hosts
  ControlMaster no
  ControlPath ~/.ssh/master-%r@%n:%p
  ControlPersist no

AuthorizedPrincipalsFile none
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
GatewayPorts no
KbdInteractiveAuthentication yes
KexAlgorithms [email protected],curve25519-sha256,[email protected],diffie-hellman-group-exchange-sha256
LogLevel INFO
Macs [email protected],[email protected],[email protected]
PasswordAuthentication yes
PermitRootLogin yes
PrintMotd no
StrictModes yes
UseDns no
UsePAM yes
X11Forwarding no
Banner none
AddressFamily any
Port 22
Subsystem sftp /nix/store/78mv13w9mgh0s0rd7rnr6ff4d7a39bpd-openssh-9.7p1/libexec/sftp-server 
AuthorizedKeysFile %h/.ssh/authorized_keys /etc/ssh/authorized_keys.d/%u
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Solution:
hd-idle is the way to go (if you read their README, they explain that most drives don't support idle timers)

I've been looking into spinning down the drives of my NAS, as I use it infrequently and that brings power drain down from ~30W to ~17W.

Problem is, hdparm -S doesn't seem to do anything for these particular drives: if I set it and wait for the appropriate amount of time (eg. 5 seconds if set to 1) the drives are still reported as "active/idle" and power drain doesn't go down.

Both hdparm -y and hdparm -Y work fine, but I don't seem to be able to find settings for them in tlp (probably because they are commands rather than settings?).

Besides the caveats about disks living longer if they are kept spinning, are there reasons why I shouldn't setup a cron job (well, a systemd timer) that runs hdparm -Y every 10 minutes? (for example, could hdparm -y cause errors if run while the drive is being backed up?)

PS: According to hdparm's manpage, -y puts the drive standby mode while -Y puts it into sleep mode. Considering that in my case power drain seems the same either way, should I prefer one or the other?

(I'm just starting off with rust, so please be patient)

Is there an idiomatic way of writing the following as a one-liner, somehow informing rustc that it should keep the PathBuf around?

// nevermind the fully-qualified names
// they are there to clarify the code
// (that's what I hope at least)

let dir: std::path::PathBuf = std::env::current_dir().unwrap();
let dir: &std::path::Path   = dir.as_path();

// this won't do:
// let dir = std::env::current_dir().unwrap().as_path();

I do understand why rust complains that "temporary value dropped while borrowed" (I mean, the message says it all), but, since I don't really need the PathBuf for anything else, I was wondering if there's an idiomatic to tell rust that it should extend its life until the end of the code block.