What about tortoisegit

The equivalent to Plex is Jellyfin I think, Plex can be used as a media server for Kodi.

Apart from security and upgrades, there might arise situations where you want to change aspects of the underlying operating system, and these changes might require changes to the source code.

Also if you remember Stuxnet, those computers were also airgapped not connected to the internet.

One goal of ReactOS is to run Windows drivers, which Wine can’t do. There are old specialized devices with Windows exclusive drivers still running in production requiring something like Windows XP or 2000. You can’t replace these with Linux and Wine. It makes sense for Russia to sponsor it; they probably depend on these old installations in either their refineries or somewhere in their nuclear program.

Fuck Russia but I wouldn’t interpret too much into this

careful there buddy

While still not correct with that in mind, the “initially” refers to a sound server a that sits above ALSA. There were others before Pulse, for example the aRts daemon and ESD. However, these were mostly used within their respective Desktop Environment while the rest used ALSA directly, so Pulse being the first Sound Server being widely used under Linux is one way to look at it. JACK on the other hand never left the (semi)professional niche I think.

In fairness to Pulse, Pipewire built heavily on its foundation; in fact, is initially was only supposed to be “Pulseaudio for video”, and Pulse led to huge improvements in ALSA and audio drivers. Pipewire simply couldn’t have worked as well back then as it does today if it had been released when Pulse was initially.

Rust is dead. Haven’t you heard? We’re rewriting everything in Zig now.

I don’t think the broader zig community has the rewrite spirit that the rust community has. For Rust, this mentality was also motivated by an increased security, which zig does improve over plain C, but not to the extent Rust does.

To preface anything that follows, I’m not a developer, so this is little-informed opinion.

Writing in rust just doesn’t seem very enjoyable. It’s a language with security in mind, which is a good thing. However, zig also isn’t inherently insecure (though it doesn’t provide the same security guarantees) and coding in it just seems so much more pleasant. To me, the language makes more sense, which is also something I like about Go. Even manual memory allocation looks well-designed. At no point did I look at zig and thought “oh, that’s an odd choice”.

The language isn’t frozen yet though, so everything you write in it may require changes later on, so I wouldn’t recommend it for anything in production. Notably, there’s no built-in async or something comparable. If you’re fine with these limitations, go ahead and try it out, and if you feel like it, maybe even rewrite an existing tool in it.

ncdu for example is such a tool where the original author rewrote it in zig for version 2.

You can also track the progress at https://nixpk.gs/pr-tracker.html?pr=367042, is already part of nixos-unstable-small at the time of writing, though this is probably not what a lot of people use. I’ll see when it hits nixos-unstable and let you know, but don’t know when I used my machine the coming days

I have opened a pull request at https://github.com/NixOS/nixpkgs/pull/367042, there might be more changes needed as I had an error in the meta section of the package which I rectified according to the reviewers proposed changes. Not sure this is the end of it, but the request is open

No, Cargo.lock is the only relevant optional one for Rust packages and that is already there, so we should be good. I’ll request it tomorrow if someone else doesn’t beat me to it ;)

No, but I will try to incorporate the nixpkgs update script into it now that the metadata is fixed for the release. I’m not a nixpkgs maintainer (yet) though but usually this is close to automatic.

If you want, you can also submit and maintain the package, or I can put us both as maintainers

It’s rather simple in good cases, here’s my version:

{
  lib,
  fetchFromGitHub,
  rustPlatform,
  perl,
}:

let
  pname = "managarr";
  version = "0.4.1";
in

rustPlatform.buildRustPackage {
  inherit pname version;
  src = fetchFromGitHub {
    owner = "Dark-Alex-17";
    repo = pname;
    rev = "df9bba32cb1628fe0bdf33c71089d7ae085066d4";
    hash = "sha256-2KWuqv0nxMc+H+lmuNQ0lbEm5yE2akuZTa7PT5JcvBs=";
  };

  cargoHash = "sha256-hB4uRgVUp6YngMoXqd03U/n+HdlcYdL5bwvTxI4xCLE=";

  nativeBuildInputs = [ perl ];

  meta = {
    description = "A TUI and CLI to manage your Servarrs";
    homepage = "https://github.com/Dark-Alex-17/managarr";
    license = lib.licenses.mit;
    maintainers = [ ];
  };
}

No worries, I look forward to using this in the future :) (though probably rarely, I don’t use my *arr stack often)

Once you have pushed your next release, I’ll submit the package definition I wrote to nixpkgs, currently worked around the ordering by checking out two commits after the tag, but since there’s no rush to push this, I’ll wait for the next release.

So I’m currently building the package, and there’s one thing that irks me a bit about it, which is that you first tagged your release as 0.4.1 and then changed your Cargo.toml… which means that if you check out that tag on GitHub, the information is always one release behind. This also seemed to be the case with other releases (0.4.0 shows as 0.3.7, 0.3.7 as 0.3.6…). From the commit history, this also seems to affect Cargo.lock, so we’re always getting the lock file for the previous release when checking out the tag. Not ideal

An issue with the program itself: it will always show servers for both radarr and sonarr, regardless if you have them configured or not. Switching to an unconfigured one will yield an error for missing configuration. The program itself looks nice, though I’d prefer if there was the option to respect my shell’s color theme.

Cool stuff, thanks.

Now if Sonarr didn’t depend on a .NET version that is EOL… recently deactivated it for that reason

Haha I still remember finding that out

Good how dumb

Realistically, no.

Theoretically, if you enable Secure Boot and a boot password through UEFI, it might be OK for some purposes, as an attacker clearing your Secure Boot settings would also reset the boot password, which you’d probably notice.

If you’re concerned about Evil Maid attacks, use Secure Boot with a TPM. If your only concern is getting the device stolen with you losing access, Secure Boot from my point of view is only a convenience feature for stuff like easier unlocking

EDIT: it should be mentioned that technically, Secure Boot doesn’t require the TPM and just checks the signatures. However, you’d need to check on each boot whether it’s actually enabled with the correct settings and that your device has not been reset. The automation of this is sometimes called Measured Boot, which the TPM is used for. Secure Boot by itself doesn’t protect you against sophisticated physical attackers. But the boot measurement gets thrown into the term because it makes sense.

At least that’s my understanding.

Clearing CMOS clears it, but you will lose the TPM attestation, which indicates tampering

I was about to write something similar. You’re just pushing the problem down the stack, and argon2 doesn’t fix that particular one anyways.

The facts are:

1. You always need an unencrypted entry point, so encryption can’t be your secure anchor (though it could never be anyways, you’re looking for authenticity there, not confidentiality)
2. As the original post states, making sure an attacker never has physical access to your boot or EFI partition works against that particular evil maid attack. It won’t protect from other threats however and isn’t very practical.
3. You need to authenticate your whole boot chain for actual protection, including initrd, which the linked article also rightfully points out
4. The only system available to normal users to provide authenticity protection mechanisms is Secure Boot (with implementations not always perfect)
5. In practice, you need to enroll your own keys to sign your initrd and have a mechanism to actually check it, or use something like a signed UKI
6. In your actual system, make sure your boot partition is only available to root - EFI mandates vFAT which doesn’t support owner attributes, so put on a restrictive mask (0077)
7. Your UEFI needs to be protected by password so that an attacker can’t just disable Secure Boot and replace your protected files

With all these in place, you should set up booting from an encrypted partition where they key is loaded from the TPM with sufficient PCRs bound and a PIN or something similar. I’m unaware of current solutions to easily have a kernel check against the registers during boot, so in case your system won’t decrypt with the PIN as your input alone, you know that your boot process has been altered (not necessarily malicious, could be a firmware update, but still).

Real security is hard, there is no easy solution if the vendor doesn’t control the hardware (which both Apple and Microsoft do), most users don’t care that much that distribution would push for it. You rather still have the unhealthy “open source is secure and TPM / secure boot is a Microsoft tool to lock out other operating systems” attitude.

PS. this is not meant as a guide for setting up a secure system, just some considerations when considering the approach.