> It always seems to lead to ArchLinux for me, since I do consider myself a power user
don't overthink it. by the time you have enough familiarity to have an informed preference it will also be trivial for you to switch distros. it is even possible to replace one distro with another by installing it over the top on the fly (do take a backup first)
start with something straightforward and mainstream. debian, fedora, or a derivative like mint
> Can someone just briefly enlighten me as to how it is of importance what filesystem the Linux boot partition is?
when the system boots, the firmware has to load something. in the MBR days that was a very tiny segment at the start of the disk. it then loaded stuff from /boot so the filesystem had to be amenable to that (ie simple). other people on here know far more than me about this sort of stuff so I'll leave it at that
with UEFI you need an ESP. that can be any filesystem your firmware is capable of reading. in practice that means FAT32 because it's required by the standard so it's guaranteed to work with any compliant implementation
so with UEFI the filesystem used for /boot can be anything supported by your preferred bootloader. or in the case of a unified kernel image literally anything supported by your OS (with a few caveats regarding layered volumes) since the necessary drivers get baked into the initramfs
that means it doesn't really matter and you don't even need a separate /boot partition unless you prefer that for whatever reason (if you have to ask you'll probably already know). if you go with something like ext4 that will guarantee flexibility since most tools should support it. fat32 isn't so great because it doesn't support all the posix file attribute feature things that are taken for granted by all the tooling
stuff like this is why I debootstrap. lay the disk out however I want, assemble the bind mounts for the chroot, and then fill out the fstab accordingly
/boot/efi should be fat32 but I run ext4 /boot and btrfs /
> Especially since I'd have to make my own initrd which I'd really rather not have to deal with.
I generally set systems up using debootstrap after booting from an image. actually I ended up authoring my own isolinux image so that my ssh keys and other stuff are burned into it. I've never had to make my own initrd since installing the kernel and grub (or an equivalent) takes care of that for you on debian
I did try out dracut on debian one time and that was painful to get configured due to some driver issues and it erroring out before I had video output. I am using it on the one system tho
for alpine it looks like there's an apk-tools-static utility that might be a debootstrap equivalent? not sure tho, never used alpine before. actually I've been meaning to try it but just haven't got to it
@r000t@NEETzsche@coin@iron_bug@r000t they're mad about this because their views on the topic are inconsistent and this brings those inconsistencies to a head
they want their stuff to be open and easy to view for the right sort of people in the manner that they imagined it would be viewed or interacted with when they posted it. they don't want people doing unexpected things with it and they don't want the wrong sort of people doing things with it. of course "don't want" is mutually exclusive with "open and easy to view"
to my mind it mirrors how I consistently find the "open" and "accepting" contingent to be far less so than the supposedly hateful bunch, at least when it comes to the open discussion of ideas
@Soy_Magnus@l0ngyap@Terry@icedquinn no. no one is going to be any better. it is utterly unrealistic to expect a service operator to shield you from the local authorities. what are they supposed to do, take up arms against their local government to avoid turning over your IP when there's a formal court order to do so?
why would anyone expect strangers who legally sell you things on the open market to burn themselves protecting your (allegedly) illegal activity?
the only question is what, if anything, they are legally required to log given the jurisdiction they operate in. and what, if anything, they voluntarily choose to log for whatever reason. you can't be compelled to turn over evidence that you never had in the first place
the best you can do is a service operator in a jurisdiction with lenient logging policies (USA for example) who clearly states what they don't log, and who has been formally audited by a third party to verify these claims
but realistically, if you are worried about being targeted by a state level actor then forget about clearnet entirely and use tor/i2p/etc