khalil

Just did a quick test, the certs do not bind to the port, only the domain/fqdn. So in short your reverse proxy/application is doing something wrong. Do you have the cert files? Can you test them inside a ubuntu:24.04 docker with the script bellow? (you'll need to copy two cert files). That does TLS and is the application all in one script, but it could be two scripts one acting as the reverse proxy or whatever, doesn't make a difference from the point of view of the client.

Lets Encrypt doesn't do anything in port 80/443 unless you're using the http challlenge AFAIK. And once you have the certs, they aren't really involved in the connection, thus that can't be the issue. Test by using curl against the script below, or your own infrastructure (each step/chain of it, the reverse proxy, the application ip, etc.)

But in short I think your reverse proxy configuration is just wrong, or you're accessing it the wrong way on the client side. For example, using https://example.com instead of https://example.com:5050.

# docker run --rm --net host -it ubuntu:24.04
# then install python3 and run this
import http.server
import ssl

PORT = 5201  # Change to your desired port
CERT_FILE = "/fullchain.pem"  # Path to your certificate file
KEY_FILE = "/key.pem"    # Path to your private key file

# Create a basic HTTP request handler
class SimpleHTTPRequestHandler(http.server.SimpleHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-type", "text/html")
        self.end_headers()
        self.wfile.write(b"<h1>Welcome to the secure static server!</h1>")

# Set up the HTTP server
httpd = http.server.HTTPServer(("0.0.0.0", PORT), SimpleHTTPRequestHandler)

# Set up SSL context
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.load_cert_chain(certfile=CERT_FILE, keyfile=KEY_FILE)

# Wrap the server socket with SSL
httpd.socket = ssl_context.wrap_socket(httpd.socket, server_side=True)

print(f"Serving HTTPS on port {PORT}")
httpd.serve_forever()

First and foremost, you are outright dismissing Flatpak, which accomplishes all of your goals pretty much, with a vague desire to use "plain old Linux" instead of a proper motivation. You should really stop and ask yourself, WHY not Flatpak? What do you actually want, and why is Flatpak not the answer to that?

I point this out first because then in the next paragraph you mention some tools such as Firejail. Which is attempting to do more or less the same as flatpak, but in a more crude/less polished form. And neither Flatpak or Firejail are "plain linux", they're just fancy wrappers around a whole bunch of actual "Linux features", like namespaces, seccomp, cgroups, users, chroot, filesystem permissions, and other higher-level tools such as bubblewrap (in the case of flatpak).

So, do you want to learn the underlying primitives/underlying tooling? If so, start with users, filesystem permissions, and Linux namespaces and the other Linux features I've listed.

Or do you want to just deploy applications in a sandboxed environment? If so, use Flatpak/Firejail/Snap/Linux containers such as Podman or Docker, etc. Then manage permissions using Flatseal (in the case of flatpak), and you're done.

How should I do this? I need some sources to read all about linux user accounts.

You should stick with trusted sources such as TLDP, Redhat/Fedora docs, Archlinux Wiki, Gentoo Wiki, etc. For example, regarding users:

• https://tldp.org/LDP/GNU-Linux-Tools-Summary/html/c6239.htm
• https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-managing_users_and_groups#s2-users-tools-groups-add
• https://wiki.archlinux.org/title/Users_and_groups

I recommend watching this video: https://www.youtube.com/watch?v=qbKGw8MQ0i8

AFAIK signal stil requires a phone numer for registration, however you now can add people by their username.

E-mail is horrible for privacy, spam, instant messaging, etc. PGP "works" in very limited scenarios, and e-mail is not really one of them.

Plus these two statements seem unplausible for me:

we can assume you're protected by PGP when writing to most users,

and

and with the added effect of not needing to convince anyone to install anything since from their end it's just an email.

I disagree with the first statement, most users don't know what PGP is and therefore don't have keys, so you can't encrypt anything to them. The only way most users would use PGP is if something sets it up for them, alá protonmail or my using some special client. Since you've said that from their end it is just an e-mail, how does Deltachat add any meaningful encryption?

Eu gostava muito do Soundcloud, mas ultimamente metade das músicas não está disponível no Brasil

AFAIK biometrics are only used to unlock the device's keychain. So, in other words, it's no different than using fingerprints to unlock your password manager (via the device's keychain that has your actual password).

The compression issues are true for 1080p too, any dark scene on Netflix gets some horrible color banding and artifacts.

Ironically, the pirates don't have that issue as their multi-gig torrents don't have much compression compared to the some-hundred megs stream provided by Netflix

An Amazon Fire Stick is far smaller, much quieter, draws less power and is simpler to use than a general-purpose PC.

Plus, if I'm using a PC I'd probably only use Linux, so I'd have to deal with lower quality streams because DRM... so overall the experience would be worse.

Using a more 'normie' Windows box as a streaming box could work, but that doesn't solve the noise(!) and power draw issues, that feels like a compromise rather than a choice.

I've recently bought a Fire Stick and don't regret it one bit. It's doesn't fell janky and doesn't have ads as far as I can tell. The provided remote inclues an IR emitter than can turn the TV on/off and change volume (why isn't this provided by HDMI itself is beyond me), and it's much faster than any smart tv so you can watch content without having to wait

They've violated the licenses

Did they? Because as far as I know they're complying with the GPL and other licenses, since everybody that gets their RHEL license (and the software/binaries) also gets the sources. Or am I mistaken?

I don't think the license says 'grant everybody a copy of your source code', only the ones that actually bought access to the binaries RHEL provides

I'd mostly focus on scrub, but I'll also recommend that you keep an eye on your unallocated blocks, running out of them can get you into out-of-space situations that are non-trivial to fix. My general recommendation is about 5G per device, that should give it enough breathing room that it won't -ENOSPC on most workloads. Also, please note that unallocated space is a subset of free space, that is, all unallocated space is free space but the inverse isn't true.

Getting more unallocated space is as easy as running a balance with a filter, say "btrfs balance start -dusage=10 /mountpoint". Just don't balance metadata unless you want to convert it.

Regarding defrag, I still defrag databases, system journal files, etc, even on SSDs. Those workloads tend to cause a lot of fragmentation that can impact your performance (try reading your journalctl logs before and after a defrag, as an example).