Well of course you can do it quickly with vim. Regardless, my suspicion is that OP deleted the lines manually, hence the need to mention it a couple of times. Otherwise, why would they even mention something you can do with grep in a literal second.

you mentioned it twice so I fear the worst, please tell me you didn’t remove 14000 lines manually using a text editor.

this is not audio specific but just an FYI, reinstalling does nothing on an updated system unless the program files were corrupted somehow, which is not normal.

to really reinstall a program from scratch you have to use apt-get purge or apt purge to ensure that global configurations files are removed, and pay attention to the logs printed out because some files may not be removed.

then, you have to manually delete your user configuration files for those programs, or create a new user un your computer to test it out first to see if user config files are generating any troubles.

just test it out.

some setups will work fine with wayland and some will work better with xorg.

there are of course ways solve those issues, but it’s easier to test both and use the one that works best for you.

wayland is the future, but the present is whatever works best for you.

yeah I got a fancy lab power supply but stopped at oscilloscopes, those things are expensive.

it’s still cheap and fun to do a lot of stuff, but now I wanna build a sound-card based oscilloscope.

probably this: https://www.oracle.com/news/announcement/ciq-oracle-and-suse-create-open-enterprise-linux-association-for-a-collaborative-and-open-future-2023-08-10/

dd is good if the destination disk is equal or bigger, unless you are brave enough to shrink the source partition.

if you are moving to a smaller disk for whatever reason (hdd to sdd) then you need to fallback to a different method, which takes us back to cp/rsync.

why not? sudo cp -ax foots the bill.

I assume people prefer rsync because you may need to run it twice, but unless you tick all the boxes rsync won’t copy capabilities (see getcap /usr/bin/rsh)

sudo cp -ax is short and sweet and does everything right.

it’s not the recommended way but it’s how I’ve been doing.

you format the new drives and just cp -a -x from the running os to the destination, update the destination fstab, then treat the new drives as an os with a broken boot and continue from there.

a simple explanation but not 100% correct is that even if your code is made to run in parallel using threads, it will never use more than 1 core in your computer.

getting rid of the GIL will let it use all the cores in the processor.

the multiprocessing module “solved” this problem by forking processes instead of threads, but it’s not ideal for a lot of workloads.