Lot of people mentioning kde connect. I’m going to take a moment to clarify, kde connevts functionality is modular. you need the sshfs package for it to mount the phones filesystem over ssh. Once you’ve done that, it works pretty normally.
Lot of people mentioning kde connect. I’m going to take a moment to clarify, kde connevts functionality is modular. you need the sshfs package for it to mount the phones filesystem over ssh. Once you’ve done that, it works pretty normally.
This is speculation:
I think a lot of it is temporarily leased or loaned. i was watching a retrobytws video recently, cant remember the exact name. but it was about this console that was ‘designed for girls’ (read what old men in suits think teenage girls want). He said a lot of.yputubers have made videos on it, but console is actually pretty rare. One or two people own pne amd loan it out to others for their videos.
Also auctioning. I gotta imagine some of it can be flipped.
Maybe donated to a museum.
That’s just me speculatong tho.
tbh why not jsut set them up with an ssh key that doesn’t have an associated passphrase? Besides that, if you don’t care about encrypting like you say, then you could replace all calls to ssh with telnet.
At least that’s my immediate thoughts.
bcache is inherently designed to be an ssd cache that sits in front of slower bigger disks. Bcachefs is an extension of this into it’s own filesystem. iirc the words of the bcache creator were: ‘we’ve implemented 80% of a filesystem here, might as well go the rest of the way’. So how much it thrashes a disk is based on what position you give it in the architecture. The caching ssds are going to be used heavily, taking advantage of their fast random access to manage all random accesses, while sequential operations generally go to the slower disk that’s set as the background device. The background disks will tend to be accessed less.
So yeah, it’s based on what kind of disk and position in the bcache, and what caching options you enable. If you want to look into it further, bcache is fs agnostic, so if you can find some tests that have been done for bcache enabled for classic linux filesystems, like ext4 and xfs, that include hardware degradation info, you’ll probably end up with similar usage and hardware wear with the actual bcachefs.
Finally, I’ve been waiting forever for this. btrfs is a mess and zfs in oracle jail forever. Finally we cna have good COW on linux without stupid hoops.
tbh I always go with env variables, usually $SHELL or $zsh are set
I’m glad it’ working well for you, but I don’t think it’ true to say that btrfs gets beyond its fair share of flak. It gets the exactly correct amount of flak for what it is. Every place I have worked at that wanted to deploy a COW fs on like, a NAS or server, has always gone with zfs. btrfs is such a mess it never even enters the conversation. Even if it can have its bugs ironed out, the bcache dev was right in pointing out that its on disk formats are poorly designed for their job, and cannot be revised except in a new version of the entire fs. I hope bcachefs gets merged into the kernel next year, that’s a filesystem I would actually trust with my data.
tbh you should prolly use pgrep instead of piping ps into grep