The Linux Thread - The Autist's OS of Choice

  • 🐕 I am attempting to get the site runnning as fast as possible. If you are experiencing slow page load times, please report it.
Reminds me, strong recommendation for QDiskInfo:
1750578500014.webp
Its basically CrystalDiskInfo for Linux.
Makes it really easy to view SMART information for your drives.
 
Last edited:
ntfs was added to the Linux kernel a while ago, so they should function fine. No more hacky FUSE workarounds needed anymore.
You should be able to move them to ext4 drives once you are in Linux no problems.
I had files failed to write for some reason when a directory was compressed when using kernel NTFS drivers on an external USB drive, but works when using ntfs3g. Good thing I have options.
 
  • Informative
Reactions: YoRHa No. 2 Type B
FAT remarkably is still the safest option for general compatibility. If you look at the instructions with BIOS updates by USB on modern MBs there's typically a warning that the USB has to FAT32 formatted.

I've switched a PC from W10 to linux (for the obvious reason) and the issue arises about what should I do with the NTFS formatted data drives. They will work with linux but to remove a point of failure I've backed them up to exFAT formatted external drives and will reinstall to the original drives reformatted to ext4. Probably unnecessary but at least I end up with another set of backups.
FAT has a single point of failure, the file allocation table. If a single bit goes wonky there, you could lose the entire thing.
I would recommend you use a modern journaling file system for your backup drive, these have redundancies, or even better a COW system with checksumming, since these can actually tell you if a file has become corrupted.
 
I figured out that the SSD on this Linux system is still being written to at about a rate of 1 MB per minute, constantly. Could "swap space" be responsible for this huge BS?

I haven't seen swap very active though, and the various processes are usually only a few dozens or hundreds of kilobytes at a time. Or maybe it is those processes after all?
 
Last edited:
I figured out that the SSD on this Linux system is still being written to at about a rate of 1 MB per minute, constantly. Could "swap space" be responsible?
Use lsof and drill down.

https://github.com/OpenPrinting/cups-sharing/issues/4 ( a ) -- Here's the issue where the applefags are discussing the sabotage of working printing on Linux. "Yes, use this as an open discussion thread" in 2021, locked as too contentious in 2024.
 
Last edited:
Use lsof and drill down.
Thanks. Much of that writing seems to be to "/usr/lib/x86_64-linux-gnu/", but also rarely it is to "/memfd:mozilla-ipc (deleted)" and some firefox folder in "user/lib" also.

(seems System Monitor doesn't track all the writes)
 
Much of the writing seems to be to "/usr/lib/x86_64-linux-gnu/"
Sounds like you've got a Trannyware package updater going on like packagekitd or something. Nothing should ever write to /usr, save for package updates. It's supposed to be mountable as read-only.
 
Not "malware", no. packagekitd comes installed by default on typical GNOMEware. I've got packagekitd on the brain because I set my dad up with a Raspberry Pi out at his farmsite and the stupid thing interfered with me updating it last time I was out. I know nothing about your system, not even the files that are being written to, so IDK more than that. Post a full lsof run and I might find something, or I might not.
 
  • Informative
Reactions: ToroidalBoat
Thanks. Much of that writing seems to be to "/usr/lib/x86_64-linux-gnu/", but also rarely it is to "/memfd:mozilla-ipc (deleted)" and some firefox folder in "user/lib" also.

(seems System Monitor doesn't track all the writes)
lsof shows you all the files opened by processes, including read-only and file descriptors. It's likely that anything in /usr/lib/ is just the dynamically linked libraries being pulled for their respective programs. MemFD is a file descriptor for memory, it's not an actual file on your hard drive. Linux in general has a lot of files that aren't actually files. Very convenient for scripting, but don't get confused by it.
 
lsof shows you all the files opened by processes, including read-only and file descriptors. It's likely that anything in /usr/lib/ is just the dynamically linked libraries being pulled for their respective programs.
Yeah, I presupposed he'd know more about lsof than that, given his explanations. Good point. lsof lists reads and writes ("ls" "o"pen "f"ile).
 
Post a full lsof run and I might find something, or I might not.
I don't want to post a full run now, but here's samples of recurring patterns:

[deleted, see post further down:]

Thanks. So looks like the biggest offender is some kind of logging, with "systemd-jornald" and "rsyslogd"...

There's also "jbd2" doing some constant writing, though not as much. So what's this BS and how do I stop it?
(just ran systemctl stop packagekit and systemctl disable packagekit BTW)

edit 1: Still chugging away at 1 MB per minute. That's like 2 CDs a day. Even when offline.
edit 2: Also, whatever these mysterious writes are, they may not show up in System Monitor.
edit 3: And whatever these mysterious writings are, they do not change the available space.
 
Last edited:
I would ask this in the other Linux thread but this one seems more active so I'm going to ask here. I've been running KDE neon for years now. I'm running the one based on ubuntu's 22.04 version. I fucked up snap a while ago trying to move it when I realized I didn't allocate enough space to /var and I was trying to get wine working recently when I ran into a problem that's pretty specific to the version of KDE neon I'm running. I'm trying to decide between updating KDE Neon to the latest version, switching back to Kubuntu or switching to OpenSUSE. I'm kind of sick of ubuntu's bullshit that only seems to get more annoying and worse every time I update and KDE Neon breaks ubuntu in random annoying ways that seem to change with every version.

I like KDE, i'm happy with the way it works and I don't want to fuck around with different desktop environments or spend an unreasonable amount of time fucking around with terminals to configure things. OpenSUSE seems to be fairly highly recommended as an out of the box KDE distro and it seems like it'll work alright for most of what I do on a computer.

The thing I'm not sure about is audio production. I've mostly stuck with Ubuntu for so long because of the kxstudio repositories. They make it very easy and straightforward to setup a full linux audio production environment which can be a massive pain in the ass otherwise.

How difficult is it to set up a working audio production environment in an arch based distro? I've read that openSUSE doesn't offer a real time kernel so that's already a bit of a hurdle. How much fucking around is it to get JACK, alsa and pulseaudio to work together?
 
I would ask this in the other Linux thread but this one seems more active so I'm going to ask here. I've been running KDE neon for years now. I'm running the one based on ubuntu's 22.04 version. I fucked up snap a while ago trying to move it when I realized I didn't allocate enough space to /var and I was trying to get wine working recently when I ran into a problem that's pretty specific to the version of KDE neon I'm running. I'm trying to decide between updating KDE Neon to the latest version, switching back to Kubuntu or switching to OpenSUSE. I'm kind of sick of ubuntu's bullshit that only seems to get more annoying and worse every time I update and KDE Neon breaks ubuntu in random annoying ways that seem to change with every version.

I like KDE, i'm happy with the way it works and I don't want to fuck around with different desktop environments or spend an unreasonable amount of time fucking around with terminals to configure things. OpenSUSE seems to be fairly highly recommended as an out of the box KDE distro and it seems like it'll work alright for most of what I do on a computer.

The thing I'm not sure about is audio production. I've mostly stuck with Ubuntu for so long because of the kxstudio repositories. They make it very easy and straightforward to setup a full linux audio production environment which can be a massive pain in the ass otherwise.

How difficult is it to set up a working audio production environment in an arch based distro? I've read that openSUSE doesn't offer a real time kernel so that's already a bit of a hurdle. How much fucking around is it to get JACK, alsa and pulseaudio to work together?
I've heard SUSE's Zipper package manager is very slow in America because they don't have any mirrors over here, so that's something worth considering. Also from what you're saying Fedora is probably what you're looking for.
 
I've heard SUSE's Zipper package manager is very slow in America because they don't have any mirrors over here, so that's something worth considering. Also from what you're saying Fedora is probably what you're looking for.
Is that all of north America or just America? I don't live in America. I've never really looked into fedora all that much to be honest. It always felt like a really corporate distro even back in the day. Is there some kind of RPM equivalent to kxstudio?

Edit:I should have googled better.

I found this for opensuse that looks promising
 
Last edited:
Dox .bashrc aliases

Bash:
function emacs() {
    { command emacs --init-directory="$HOME/.emacs.d/" "$@" > /dev/null 2>&1 & } 2>/dev/null
    disown
}

alias emacsclient='emacsclient -c -a ""'
alias emacst='command emacs -nw --init-directory=$HOME/.emacs.d'

alias glst="eza --git --git-ignore --group-directories-first -T -L 3"
alias gcom='git commit -m '
alias gadd='git add '
alias glog='git log --oneline --graph --decorate'

alias resource='source ~/.bashrc && echo ".bashrc reloaded"'

alias clock='tty-clock -c -C 2 -b -s'
 
Is that all of north America or just America? I don't live in America. I've never really looked into fedora all that much to be honest. It always felt like a really corporate distro even back in the day. Is there some kind of RPM equivalent to kxstudio?

Edit:I should have googled better.

I found this for opensuse that looks promising
OpenSUSE is to SUSE what Fedora is to Red Hat, but SUSE is worse than Red Hat, with OpenSUSE calling conservatives rotten flesh. Fedora is a rolling release distro like Arch and is known for being easy to use (even if they like to push things before they're ready so Red Hat can test them), which is why I recommended it.
 
edit 1: Still chugging away at 1 MB per minute. That's like 2 CDs a day. Even when offline.
edit 2: Also, whatever these mysterious writes are, they may not show up in System Monitor.
edit 3: And whatever these mysterious writings are, they do not change the available space.
Hard to say. What are you actually using on your computer.

Also maybe consider the system journal or logs. If they aren't just being kept in memory. I don't actually keep track of how much is being read and written daily or by the minute. So I don't know what is an actual reasonable amount. But everything is a file on Linux. So things are going to be reading. Things are going to be writing to caches. Storing things in files. Could even be something like graphics driver. Which could make sense.
 
FAT has a single point of failure, the file allocation table. If a single bit goes wonky there, you could lose the entire thing.
I would recommend you use a modern journaling file system for your backup drive, these have redundancies, or even better a COW system with checksumming, since these can actually tell you if a file has become corrupted.
It's more complicated. Recovery is easy if only the File Allocation Table is corrupted and the root directory still exists. It can be rebuilt with modern tools. (I remember FAT also has 2 copies of the table).

If only the root directory is destroyed but you still have FAT intact, it will be somewhat harder but still possible to recover because you know how the clusters are grouped. However you will lose the filenames, folder hierarchy and metadata.

If both FAT and Root Directory gets corrupted, it will be pretty difficult, but not impossible to retrieve data and use heuristics to detect a docx, pdf etc. It might be way way too hard to recover everything (like some txt files or fragmented files). You have to guess where the clusters end and begin for a file if the file has no header, and fragmentation makes it much more difficult.
 
Last edited:
Back