• 1 Post
Joined 3Y ago
Cake day: Feb 19, 2021


I had always used Windows for the longest time. I used a certain cloud service and was impressed with how easy it was to manage services with docker. Fast forward a couple of years and I got a small mini-PC with Windows. I tried to install docker on it but Windows back then had no way of using Docker without virtualizing it with Hyper-V, a Pro feature. I thought let me give this another try. I tried to replicate the same setup with NSSM tools. It kinda worked eventually but it was a dirty hack at best and I did not like this solution.

I thought to myself, why would I pay Microsoft to use a feature I can use for free with Linux and get better performance while at it.

Here we are 7-8 years later.

Gnome’s window sizing has always looked comical on my display. So I fix it with Orchis gtk compact theme. Also GSconnect is an irreplaceable utility for me.

Not a single mention of secure boot? Weird.

I would say you are already secure enough if you are using software from official/trusted repositories and updating them on a regular basis.

That said, if you want extra security. Drop all software that cannot run on Wayland and go even further by isolating all desktop applications with the Flatpak sandbox. This is made extremely easy with Flatseal. Maximum points if you setup secure boot.

If you are talking about the arch installer. It’s still a commandline. Nothing like the popular calamares GUI installer. Anyone can follow steps to an install easy. The real juice is in maintenance of the installation.

Check out a few videos on how to install Arch Linux. It will cover all your needs and then some.

Use whatever software your peers are using, the way they are using them. The importance of software compatibility cannot be overstated.

I’ve broken installations many many times. But here’s a recent one that comes to mind.

I was playing around with audit and some file was not responding as I wanted it to. Somehow my pea brain got the great idea to remove all config, uninstall audit then have the new install refresh the configs. Did this straight through the warnings and effectively broke sudo, a dependency of audit. Good thing arch-chroot exists.

I’ve done rm -rf / twice on Fedora installs.

Aside from the fact that I’ve used it long enough without encountering any breaking issues or bugs, it is very powerful and highly customizable.

Flatpak for all *possible installs of user apps. But if there’s an app I respect most, it has to be MPV.

You can pin the Nvidia driver with flatpak mask appname and update the rest of your apps.

Great. I like being able to deny apps permission to my home folder with a simple flick via Flatseal. Only issue I have with it is the slow update times, flathub seriously need to get more mirrors.

Hehehe. What about RPM users? This fragmentation in Linux packaging robs users of choice.

Would rather have Firefox setup a repository for the nightly channel, after all they official maintain the stable channel on Flathub.

That way everyone benefits from the utility.

It’s okay dude. You got to learn a new vocabulary today.

Use whatever distro looks shinier to your eyes.

I’m never ever going to use a distro that forces telemetry on its unsuspecting users.

Let it rest.

Maybe you should look up the definition of the word and come back to your previous comments.

No amount of gaslighting by you or excusing telemetry for good reason will change my opinion on opt-out telemetry.

Opt-out telemetry has never been the standard for Linux distros.

If we have to bash Ubuntu for telemetry, we have to bash Fedora with the same stick.

I’m not saying you shouldn’t use Fedora. I’m saying I wouldn’t.

No matter how tempting, I wouldn’t use Fedora since it ships with opt-out telemetry.

Red Hat has a right to shoot itself in the foot as many times as it wants. Ubuntu, OpenSUSE and Oracle will gladly take over their business without skipping a beat.

Aside from all the things Flatpaks get right, a sandbox framework built right into the design is a major win and in my case, it’s one of the big reasons I went with it.

You can also modify the build script for any flatpak’s manifest and create packages with flatpak-builder. May not be as easy as PKGBUILDs but it’s certainly possible.

The problem of bad software defaults is easily solved with Flatseal. My point is that, it takes a few clicks to deny permissions to Flatpak applications as opposed to sandboxing a traditional app yourself.

Writing sandbox profiles for apparmor or something similar is usually a complex elaborate affair. And even when you do finally manage to get a working profile, it still requires maintenance to keep the sandbox functional as the target software updates. You won’t face any of these problems with Flatpak’s bubblewrap.

I love Flatpaks and have embraced them totally on my desktop. They just make sense for sandboxing applications with Flatseal. Distro maintainers also ship software with bad defaults. I want to be able to easily control that.

Yeah. Came across it when it was released. It’s still considered experimental.

And am sure NixOS is great but it definitely is a weird operating system.

My (maybe flawed?) thoughts: Why bother with full disk encryption if one could just boot the notebook to undo the encryption?

If it were that easy to do, we wouldn’t have even bothered with doing disk encryption in the first place. And it’s not like cracking TPMs is a walk in the park.

Using my yubico fido 2 key in combination with a small PIN I can easily decrypt my LUKS drive and know nobody else can decrypt it as long as I have my yubico with me.

This definitely could help in a scenario where an attacker has only your notebook but for it to make a difference your attacker must not be able to access your Yubikey and/or compel you to hand it over.

As long as your LUKS drive is encrypted (TPM or not, Yubikey or not), you are relatively safe from an unauthorized party trying to access your data. Either of these attestation tools add a layer of defense for your encrypted drive.

Would love to get systemd-boot entries for BTRFS snapshots (openSUSE is currently working on an implementation of this). But my current strategy is arch-chroot when things go haywire (recently broke sudo). And local + cloud backups of my home folder should the situation demand it.

Arch. Some of its users take this distro for granted a lot of times but it only goes downhill from here once you start looking at other distros.

Tumbleweed. Solid, Automated QA testing.

Chimera Linux. Security-related compilation flags go brrr. No systemd.

Maybe we’ll see SerpentOS sometime before this decade ends but who knows.

On a side note. Aeon 1.0 if/when released, can’t wait to see how it all turns out. Especially if they manage to integrate BTRFS snapshots with systemd-boot entries.

Am already sold on immutable distros as the future of desktop Linux. 8/10 applications that I use today are flatpaks or dockers. That remaining 20% of the work to be done on immutable is what am anxious about.

This summary should cover my main concerns with current secure boot implementations on the major distros. Ignore everything else other the linked part. I also would not want to be forced to use grub as the bootloader.

Curious. What did you not like about using TPM to store keys in your setup? I use TPM for secure state validation & automatic decryption of my LUKS drive, it’s great and also acts as a tripwire for secureboot state.

I could build a custom version of Silverblue (u-Blue) to replicate what I already have setup, but none of this would be supported configuration. All this is not entirely to blame on on immutable distros (traditional distros don’t give a damn about secure boot either way), just that to mess around within /etc is a no-no in such a model so to get multiple pre-configured options for secureboot configs/keys that work seamlessly would be a great experience for me.

RedHat & Debian family desktop distros use a key that is signed by Microsoft for supporting secure boot. For compatibility reasons mostly as some hardware will brick when the MS signed keys are not found. But I prefer to sign my own keys and enroll them as I currently do with sbctl. I have no need for extra kernel modules/drivers as Nvidia users would (seems like a hacky workaround if the kernel can’t ship the drivers and signing your own kernel makes the situation even more complicated).

However I have been meaning to try Distrobox, if I get around to trying out immutable I will give it a good run.

If you are tired of Arch, why not give Tumbleweed a chance.

Go with MicroOS. SUSE’s products are criminally underrated for how well designed they are. Plus at some point you are bound to face a brick wall when trying to use software that is not musl compatible on alpine.

Why do all these immutable distros not support use of secure boot and/or TPM. If there was one that made it a breeze to configure this and made using my AURs easy as well I probably could give immutable a chance. But ATM it all looks like I’ll have to wait until a major corp like Ubuntu made & supported an immutable version so we can get these quirks hashed out.

nothing against endeavour, it is a fine distro and it eventually got me to dip my toes into arch further;

but the arch installer is all you need.

Flatpaks are to distros what Alpine is for docker containers. A base for creating distro agnostic desktop applications. It’s really cool and has picked up quite some good support within the Linux community.

You should listen to the advice from Distro Chooser. Arch fits the bill. You’ll just have to take care not to convolute the system too much with workarounds & all sorts of packages and it will take care of you.

That’s a feature not a bug. Under flathub, the original author of the software (for verified apps at least) knows what is the best configuration to ship for their package.

ATM. You are not trusting flathub when installing a flatpak. You are trusting the application’s author. Maybe in the future, flathub would introduce restrictions on certain permissions but we would be speculating at that point.

PSA: Recent AMD fTPM fixes introduced regressions in stable and LTS kernels that are breaking TPM, presumably for everyone
https://bugzilla.kernel.org/show_bug.cgi?id=217804#c41 From [6.4.9](https://bugs.archlinux.org/task/79366) onwards, TPM is broken as is LTS 6.1.46. A step downgrade from these versions restores TPM.