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.
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.
Jesus fucking christ this is a hell of a project, Ill finish reading when I get home today.
Hats off to you for pulling it off. Why is it that every time I read something by a NixOS person I get the inpressiom that they are very smart but are completely mad.
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.
I have made a python script and ran it on a clone of your git repo to confirm it works, simply run it at the root directory of wherever the files are, it will walk through and find module.json and do the replace.
#!/usr/bin/env python3
import re
import os
import fileinput
pattern = re.compile(r'(?P\.+)\"compatibility\":{\"minimum\":\"(?P\\d+)\",\"verified\":\"(?P\\d+)\"},(?P\.+)')
def make11(match):
if match.groupdict().get('min', None) and match.groupdict().get('ver', None):
return f"{match.groupdict()['pre']}\"compatibility\":{{\"minimum\":\"11\",\"verified\":\"11\"}},{match.groupdict()['post']}"
for root, dirs, files in os.walk("."):
for file in files:
if file == "module.json":
for line in fileinput.input(f"{root}/{file}", inplace=True):
print(re.sub(pattern, make11, line))
edit: lemmy is fucking with the formatting and removing the fucking regex group names, which will bork it. I’ve tried fixing it, dm me if you want me to send a downloadable link to the script
I also agree sed and some regex is your best bet
I recommend formatting the regex with regex101.com, I’m down to help you if you post some examples
Additionally there is a cli tool, I think jq or something like that, for processing json on the command line
I have foundry too, let me see if I can find the files that need to be updated
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