Chewy @ Chewy7324 @discuss.tchncs.de

Posts

96

Comments

1,011

Joined

2 yr. ago

It seems the Determinate Nix installer supports Fedora Atomic and SELinux.

On topic:

I really like Nix and home-manager. I've mostly switched to NixOS because it's more convenient for window manager setups than building ublue images imo.

Having to mess with containers for different dev environments and keeping the up to date is imo more annoying than creating a shell.nix

Also being able manage my dorfiles with home-manager and installing software declaratively helps in keeping the system free of clutter.

The source of the determinate nix installer has some mentions of SELinux. E.g. they have an .fc file, but I really don't know anything about SELinux.

https://github.com/DeterminateSystems/nix-installer/tree/main

Yes, that's likely the case.

The ahayzen/silverblue-nix guide uses bind mounts from /var/lib/nix to /nix. The latter being created by making / temporarily writeable with chattr +i /.

It seems the Determinate Nix installer supports Fedora Atomic with SELinux enabled.

supporting SELinux and OSTree based distributions without asking users to make compromises

https://github.com/DeterminateSystems/nix-installer

Edit:

disabling SELinux

I hope this is not a serious suggestion?

Since no nix installer supported SELinux at the time, it was the only way to use nix on Fedora Atomic. With a better option available disabling SELinux is a bad idea indeed.

https://gitlab.com/ahayzen/silverblue-nix#using-nix-on-fedora-silverblue

It's possible to install nix on Fedora Atomic by disabling SELinux and using bind mounts.

Removing nix is mostly done by deleting /nix, and removing some systemd services, as well as deleting some nix-related users or groups (iirc nixblkd)

Because almost all of nix happens in /nix it doesn't clutter much of the system.

Great to see Unified Push on the list. As well as improved Wayland input method support, whatever that exactly means.

I'm pretty sure microG isn't installed by default because of how it'd conflict with installing MindTheGapps (Google Apps).

It's great to see LMFG continuing for a while because its users would have to wipe their device to switch to LineageOS + microG.

That's awesome. Is it as simple as adding the microG repo to F-Droid and installing from there?

Adding to that, there're builds of LineageOS with microG preinstalled, which should be relatively similar to CalyxOS.

https://lineage.microg.org/

I personally prefer top level subvolumes (@, @home, @var-log, @var-cache), because it makes it easier to know which system folders are subvolumes and back them up accordingly. They are then mounted at their respective location under /.

E.g.. I do snapshots looking at the btrfs filesystem and its top level subvolumes. I'm not doing snapshots going from the mounted root filesystem. I.e. I'd do a snapshot of @home, not a snapshot of /home.

If you want to use backup/snapshot automation tooling, I'd recommend looking at how they expect the subvolumes to be set up. E.g. snapper and timeshift expect a specific layout (which can stil be done manually after OS installation, but why bother).

Immich recently changed license from MIT to AGPL. As far as I understand they can't sinply relicense to a non-free license unless they redo a good chunk of code from the last half a year.

If they still used the MIT license I'd be worried too.

I personally would be hesitant to host Immich publicly until they've done a security audit. The risk of accidentally exposing my photos publicly is too big for me.

That's why I recommend using Tailscale or Wireguard directly. Personally I'm using Wireguard for me and Tailscale for other people I want to easily access my services.

(Of course, not realistic if you have 500GB of music and no SD card slot in your phone)

That's the problem right there. SD card storage is so cheap, but the manufacturers don't include a slot for it.

It's a sad day. E.g. former MEP Felix Reda did incredible work around the time of the 2017 EU copyright reform and helped the protests through transparency.

Now with the risk of badly written laws enabling (atm. restricted) surveillance, we'd have needed them more than ever. Luckily there's still MEPs from the Czech Republic in the EU parliament.

They don't take money from investors but grow organically, which limits their resources quite a bit. With more users being on other platforms and Linux being a bit more complex when it comes to amount of possible filesystem and other combinations I see why it takes them a while. Iirc they also do e2e encryption of (meta-)data which does increase complexity.

Hopefully they'll finish it at some point, as it's been a long time since they announced Proton Drive. As I'm not paying for Proton, I understand a paying long-time subscriber might not share my acceptance of them zaking their time.

Afaik the OSTree snapshots use BTRFS deduplication [...]

Note: OSTree will transparently take advantage of some BTRFS features if deployed on it. [1]

Interesting, I didn't know OSTree takes advantage of BTRFS features.

On my current system I use ext4 instead of btrfs which I regret specifically because of the missing transparent compression and reflink copy.

[1] https://ostreedev.github.io/ostree/introduction/

I prefer to stick to defaults whenever possible.

Same goes for me.
E.g. changing vim keybindings on my local system to better suit my non-QWERTY keyboard would be annoying since they don't transfer to remote systems. That's a reason I like fish, because it's defaults are modern and useable, compared to zsh/bash which benefits strongly from plugins.

I like all editors to have as many diverse sets of keybindings as possible. Sadly most apps don't, which is a main reason why I never bothered to properly learn emacs bindings, as I wouldn't be able to use them anywhere else.

It's definitely just my opinion. Honestly did not mean to imply otherwise.

For my opinion I usually create a comment below my post to seperate my opinion and the post itself.

On-topic: I do believe it's useful to have this switch and there's nothing stopping distros to change their default. Completely replacing the default keybindings might be surprising to long time users, but I also believe it should be done at some point. For the meantime this switch can be simply added as an alias.