The Linux Thread - The Autist's OS of Choice

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
analrapist said:
Just understand, you're making decisions about your boottime that are difficult to manage, and that's why you're in trouble.
Click to expand...
I do understand that if I just had a bare ext4 partition that I'd be making my life a lot easier. I am resistant to falling back to that because it's a laptop, however maybe the solution of just encrypting /home would be acceptable. Encrypting /, the prompt for a key is right after the kernel select - when would it prompt for key if I encrypt /home? I assume it would interrupt the sequence when /etc/fstab gets called.

The thing I'm really getting frustrated over is the fact that this same installation procedure has been incredibly smooth on three other devices. Now that I'm thinking about it, the difference has been that those systems are all AMD based. My desktop is an ASUS board with a 5900X, I have a CyberPowerPC with a Ryzen chip, and my work laptop is a Thinkpad E16 with a Ryzen chip. This new laptop is the first time I've tried to run Linux on Intel since a Pentium 3. I'm not sure if that could be the issue, or the fact that this is an MSI laptop.

As frustrated as I am about it, I'm going to keep trying because on some sick level I enjoy figuring this out. Worst case I lose my mind, live under an overpass, and rant at vehicles stopped at the intersection about how the tiny hats are infiltrating their bathrooms to put aluminum in their deodorant.
 
Susanna said:
You say “decrypt the entire disk”, but it really just decrypts files as it reads them, and modern processors integrate the hardware to do so, so the performance penalty is minimal or nonexistent.
Click to expand...
I'm not saying that because it will give a performance penalty. But because your disk is effectively not encrypted after booting, while using the computer. And a lot of the stuff that is encrypted doesn't really matter, usually the things you might care about being encrypted are going to be in your home directory, or possibly somewhere else you purposely put them.

I can't really think of anything that will put things outside of that, except some programs will open things in /tmp or the runtime directory. or keep things in /var but it really depends what you are doing. On whether that will matter, and if you are worried about things in /var specifically you could also set up those directories to be encrypted if you really wanted to. I'm not sure what would be there that is going to be that much of a concern though. And /tmp and the runtime directory should just be in memory, so they are wiped when you reboot (at least I make sure my /tmp is mounted on tmpfs), which is also another option for things that end up in var if you don't care about them being persistent, and you have the memory, mounting those in ram. So they will always be wiped.
ghastlyretard said:
I do understand that if I just had a bare ext4 partition that I'd be making my life a lot easier. I am resistant to falling back to that because it's a laptop, however maybe the solution of just encrypting /home would be acceptable. Encrypting /, the prompt for a key is right after the kernel select - when would it prompt for key if I encrypt /home? I assume it would interrupt the sequence when /etc/fstab gets called.
Click to expand...

here's a short tutorial on how you can do it with ecryptfs. The most important thing. before you attempt this, make sure you make a back up of it, especially if you have things you care about in it. Do the process, and confirm everything worked correctly before you delete the backup. And make sure you have your root account enabled, so you can actually log into it while you do this.


heres a longer more in depth article on ecryptfs, on the arch wiki.
 
I've landed on a grub install that allows me to pick between Arch or Windows, encrypted root/home, and boot/efi on their own bare fat32 partitions. So this is acceptable, but I still want to figure out what's up with this write issue preventing me from storing last used selection. I know it's finding the grubenv file because if I delete it then grub will complain that the file doesn't exist. So I recreate it with "sudo grub-editenv /boot/grub/grubenv create" to put it back and it goes right back to telling me "error: failure writing sector 0x------ to hd*"

There's also this thing where drive labels aren't consistent from boot to boot which isn't an issue because I'm doing everything by UUID, but I wonder if this is somehow related to the random-seed message systemd-boot was giving me and this issue with grub.
 
Can confirm the switch to mint is good. I switched to Mint a few weeks ago and it "Just works". Had no issues, couldnt recommend it more
 
Susanna said:
Full-disk encryption protects you from that, as well as from things like passwords being scraped from your swapfile.
Click to expand...
This isn't something that FDE protects against. If you, the user, can read a file then malware can also read the file.

For a real-world example, there was some Linux malware that used to search through your home directory for saved credit cards and addresses in your browsers and then ship them off with curl. If you cat a file it'll transparently decrypt and, well, a malicious shell script can do the exact same thing.
 
I just wanted to say how glad I am that it's very easy to debug things in linux these days, especially with systemd.
I have a ton of AI checkpoints for SDXL and Flux and they've been taking up a ton of space on my desktops. So, I thought, hey, I have a file server and 10G links. Which works ok, but is a little slow, so I went looking for cache options. I stumbled upon a blast from the past, that I don't even remember ever seeing before. FSCache, which together with Cachefilesd will cache NFS on local disk. Great.

I wanted to set it up so only the mount for the checkpoints and other big files was cached and not my normal home directory. So I set it up. Randomly at boot it would either enable caching on all nfs mounts, or none.

Adding debug logging to systemd(kernel cmdline "debug") revealed that, for once, systemd was sending the right mount command. This wasn't happening if I mounted the filesystems by hand.

So, how do you debug mount? By replacing it with a shell script that runs strace -o /root/$$.out mount-real $@
And then your system doesn't boot because strace fails when it tries to write to root before it's read-write. So, you add || mount-real $@ and the system boots. But the mount strace looks fine, the mount() syscall is also doing the right thing.

So you add debugging to dump the proc file telling you fscache status and /proc/mounts after each mount. Where you notice that fscache shows the drives before they pop-up in /proc/mounts. Then you check the timestamps and all these mounts are happening at the exact same time. There's a fucking race, maybe in the kernel, where the fscache mount options are getting corrupted. If the non-fscached mount runs first, then none get enabled, if any of the fscache volumes run first then all get enabled.

A few minutes later and:
Code: 
server:/home /serverhome nfs defaults 0 0
server:/fs1 /serverfs1 nfs fsc,x-systemd.after=/serverhome 0 0
server:/fs2 /serverfs2 nfs fsc,x-systemd.after=/serverfs1 0 0
server:/fs3 /serverfs3 nfs fsc,x-systemd.after=/serverfs2 0 0
and /serverhome doesn't have fscache and the other 3 do, consistently on every boot. Yes, thanks, that parallel mount that saved me 1 second per boot wasted several hours chasing down a bug.

I'm tempted to look at the kernel and see if I can see what's going wrong, then I realized I simply don't care.

I hate computers.
 
Froggy Fresh Sextape said:
This isn't something that FDE protects against. If you, the user, can read a file then malware can also read the file.

For a real-world example, there was some Linux malware that used to search through your home directory for saved credit cards and addresses in your browsers and then ship them off with curl. If you cat a file it'll transparently decrypt and, well, a malicious shell script can do the exact same thing.
Click to expand...
Well no, encryption is about data at rest protection, ie while the computer is powered off. While the computer is on and you’re logged on, your single encrypted folder will be just as accessible to malware running under your user as any other folder, ie fully. You use heuristics, signature databases, and application privileges to protect data from malware, they’re different problems with different solutions.

I do agree malware is a much more realistic threat than some malicious actor sneaking into your office and stealing your hard drive.
 
controversial666 said:
Programming
Click to expand...
In that case feel free to ignore anyone who tells you you aren't a "real" Linux user if you don't use whatever pet autismo distro it is they're pushing. Here you can see statistics on the top 500 (non-distributed) supercomputers in the world:
All 500 run Linux and the majority run very boring distros that you can also easily find on virtual private servers (or VPS for short). Obviously these supercomputers have to be consummate programmers' environments.
prollyanotherlurker said:
then you could basically use anything.

If you need newer versions of software, something rolling release might be a better fit. but otherwise anything should be fine.
Click to expand...
I have a few things on Mint compiled from source like R. Even if nothing else is available that should work.
 
Betonhaus said:
If you tunnel all your traffic through a VPN you could be suspected of doing something illegal and be investigated, and if they see your computers have uncrackable encryption that a digital forensics expert can't validate, they can assume you have been sharing CSAM. They likely can't arrest you on it, but they can hold you for a while and ruin your public image.
Click to expand...
I would always personally recommend running a VPN, even if you don't bother to encrypt for it's alleged performance reduction or use SecureBoot which may come with some risk of bricking your system on certain hardware if you use your own keys (esp on NVIDIA). - However using the correct VPNs have been historically proven to be very effective and does not come with any caveats or risks.

I say assess your security risks honestly and take the proper precautions wherever needed, but regardless of what you do the best security is always going to be yourself and esp your physical security. Ensure your shit is locked behind proper doors and such, watch what you say & reveal online, diversify your digital footprint, and for the love of God: Don't go running random fucking shell scripts or w/e with elevated privileges.
 
Um, hi. Would there be any interest in a thread for Unices (sp?) that aren't Linux? I just tried NetBSD recently and I know it's very portable but the initial setup was unbelievably spartan and I would say somewhat broken with $PATH not including things it ought to have. Then I tried FreeBSD, remembering an easier time with it in the past, and I have to say that it certainly started off more spartan than what I'm used to on Linux but there was much less yak shaving involved to get fish + oh-my-fish going so I'd have something better than the minimal default shell.

I'm also interested in emulating Unix operating systems that are more or less vintage using VirtualBox and where necessary QEMU.

EDIT: it looks like MAME, which is mainly for retrogaming, can also be used to run SGI Irix: https://sgi.neocities.org/installguide. Time to lock out those Velociraptors!
 
Last edited:
I was using wayfire in Vulkan mode because it got support for it recently. And I was wondering why my laptop battery was draining so fast. Apparently, the vulkan renderer forces it into D0 24/7.
Belisarius Cawl said:
Um, hi. Would there be any interest in a thread for Unices (sp?) that aren't Linux?
Click to expand...
I don't use BSD, but I would probably browse it out of interest
 
Froggy Fresh Sextape said:
Better yet, don't run them at all without verifying what they do.

All it takes is write access to a user's home directory to root them.
Click to expand...
Odds are everything you care about on the computer is either in home or some other folder the user can write to in the first place. Root stuff can be regenerated by a reinstall, your vacation photos can’t be.
 
Susanna said:
Odds are everything you care about on the computer is either in home or some other folder the user can write to in the first place. Root stuff can be regenerated by a reinstall, your vacation photos can’t be.
Click to expand...
Yeah, to be honest a lot of Linux security is just the fact that nobody bothers to target it. There's very little oversight for package maintainers, for example, since nobody wants to maintain packages in the first place much less check every single thing that's uploaded.

for a simplistic proof of concept:

Add PATH=$HOME/.local/bin:$PATH to the end of your .bashrc

Code: 
#!/bin/bash
/usr/bin/sudo echo 'lol'

Name this sudo, make it executable, put it in ~/.local/bin

Close and reopen your terminal, run sudo apt update or sudo dnf update or sudo pacman -Syu or whatever you usually do to update your system. Now imagine this pointed to a malicious binary instead.

There are other tricks you can do with stuff like LD_PRELOAD
 
You must log in or register to reply here.
Back
Top Bottom