I used to do this as well, and tell Linux to never overcommit, but for a desktop system normal programs are not built for this scenario. Firefox will crash with 15% system ram usage because it requests a ton of virtual memory for each process on startup.
Swap can also be important if you want to get the most out of your ram because without swap, pages that are holding unimportant parts of the system can't move out of the way for a large number of data pages that need processing. My latest memory revelation is zswap, which seems to be better than actual compressed memory. So far it's served me well running ML loads on old hardware.
On an unrelated note, if someone tries to rugpull a foss license, but Claude is listed as a committer, can the license be changed? I thought licensing ai code was basically a no-go since copyright has been scrapped for ai output???? I'm sure that won't last.
Solvespace has been working for me, but I don't do complicated cad. I recommend getting familiar with solvespace if you want to try the cadsketcher blender plugin since it is basically solvespace glued into blender.
Afaik, those by-* paths are symlinks created by udev during boot (before switching to the real root fs) The kernel creates the actual device files directly in /dev. My guess is that Windows left an NTFS volume in an unmountable state or something and udev got stuck processing this disk before processing rules for your boot disk. This probably requires you to have a fstab entry for mounting your windows disk, but I'm not sure.
When you boot into a live distro again (I know you're done, but maybe someone else has this problem) check if the disk has a block device file directly in /dev. Maybe check the other disk, see if you can mount it or remove references to it in fstab or unplug the device entirely.
"This product is a civilian robot. We kindly request that all users refrain from making any dangerous modifications or using the robot in a hazardous manner."
Totally unrelated, but I just want to say that my 14 TB sas drive (exos?) was brought back to life in a 12 TB configuration after failure by using openseachest to deactivate one side of one of the platters (the failing one, it was the only one with errors) after I told it to start it took 4 days to reformat, most of that time reporting no progress, but finally finished and now it works great!
Mainly tmuxor screen keep sessions alive on the remote server, so processes don't get killed when I disconnect.
You should create a version of this with a twitch-plays-pokemon style interface to bash
run photorec on it after trashing the luks header if you want to be sure
Time to switch back to screen :P
Because sometimes (or always) you're using the terminal multiplexer on a remote machine over ssh with no graphical session
I used to do this as well, and tell Linux to never overcommit, but for a desktop system normal programs are not built for this scenario. Firefox will crash with 15% system ram usage because it requests a ton of virtual memory for each process on startup.
Swap can also be important if you want to get the most out of your ram because without swap, pages that are holding unimportant parts of the system can't move out of the way for a large number of data pages that need processing. My latest memory revelation is zswap, which seems to be better than actual compressed memory. So far it's served me well running ML loads on old hardware.
This is how mosquitoes evolve cloaking devices
Alternatively, the chickens are pets, eggs are 100% profit 😅
On an unrelated note, if someone tries to rugpull a foss license, but Claude is listed as a committer, can the license be changed? I thought licensing ai code was basically a no-go since copyright has been scrapped for ai output???? I'm sure that won't last.
I do like openscad but I must be using it wrong because it slows to a crawl when trying to array my models
Solvespace has been working for me, but I don't do complicated cad. I recommend getting familiar with solvespace if you want to try the cadsketcher blender plugin since it is basically solvespace glued into blender.
Thoughts and prayers go out to the innocent shell processes killed in the crossfire
Don't forget the poor shell process reaped along with it );
Afaik, those by-* paths are symlinks created by udev during boot (before switching to the real root fs) The kernel creates the actual device files directly in /dev. My guess is that Windows left an NTFS volume in an unmountable state or something and udev got stuck processing this disk before processing rules for your boot disk. This probably requires you to have a fstab entry for mounting your windows disk, but I'm not sure.
When you boot into a live distro again (I know you're done, but maybe someone else has this problem) check if the disk has a block device file directly in /dev. Maybe check the other disk, see if you can mount it or remove references to it in fstab or unplug the device entirely.
"This product is a civilian robot. We kindly request that all users refrain from making any dangerous modifications or using the robot in a hazardous manner."
😅
Humans are hilarious
That frog is about to have its bones drank
Totally unrelated, but I just want to say that my 14 TB sas drive (exos?) was brought back to life in a 12 TB configuration after failure by using openseachest to deactivate one side of one of the platters (the failing one, it was the only one with errors) after I told it to start it took 4 days to reformat, most of that time reporting no progress, but finally finished and now it works great!
👀
I didn't think family matters would get a reboot
TOS implies
King of the hill The next generation Starring Bobby
King of the hill Voyager Starring Luann
King of the hill Deep State 9 Starring Dale