• 2 Posts
  • 79 Comments
Joined 1 year ago
cake
Cake day: June 8th, 2023

help-circle




  • It sounds like nobody actually understood what you want.

    You have a non-ZFS boot drive, and a big ZFS pool, and you want to save an image of the boot drive to the pool, as a backup for the boot drive.

    I guess you don’t want to image the drive while booted off it, because that could produce an image that isn’t fully self-consistent. So then the problem is getting at the pool from something other than the system you have.

    I think what you need to do is find something else you can boot that supports ZFS. I think the Ubuntu live images will do it. If not, you can try something like re-installing the setup you have, but onto a USB drive.

    Then you have to boot to that and zfs import your pool. ZFS is pretty smart so it should just auto-detect the pool structure and where it wants to be mounted, and you can mount it. Don’t do a ZFS feature upgrade on the pool though, or the other system might not understand it. It’s also possible your live kernel might not have a new enough ZFS to understand the features your pool uses, and you might need to find a newer one.

    Then once the pool is mounted you should be able to dd your boot drive block device to a file on the pool.

    If you can’t get this to work, you can try using a non-ZFS-speaking live Linux and dding your image to somewhere on the network big enough to hold it, which you may or may not have, and then booting the system and copying back from there to the pool.








  • You’re probably going to run into the problem that people didn’t anticipate your strategy if you try to run a model on a GPU with way more memory than the host system. I’m not sure many execution frameworks can go straight from disk to GPU RAM. Also, storage speed for loading the model might be an issue on an SOC that boots off e.g. an SD card.

    An eGPU dock should do CUDA just as well as an internal GPU, as far as I know. But you would need the drivers installed.



  • Like, each user is individually kicked off the PDS in reaction to some bad thing they did? Or labeling is reactive in that it labels bad stuff already posted, and each user has to pick labelers to listen to themselves?

    I’m not sure if Bluesky’s front-end defaults to using some particular labelers. I know there’s some moderation going on for you as soon as you log in, done by someone.

    But yes, each user has to choose whose moderation decisions they want to use, and they can’t rely on everyone they can see also seeing exactly the same space they themselves are seeing. But I’m not sure it’s possible or even desirable to get rid of the requirement/ability to choose your mods. I should be able to be in a community that has mods I trust, and the community chatting to itself and determining that so-and-so is a great mod who we should all listen to, and then all listening to them, sounds like a good idea to me.

    Being able to see and talk to people who aren’t in the same space I’m in might not be as good?



  • No?

    An anthropomorphic model of the software, wherein you can articulate things like “the software is making up packages”, or “the software mistakenly thinks these packages ought to exist”, is the right level of abstraction for usefully reasoning about software like this. Using that model, you can make predictions about what will happen when you run the software, and you can take actions that will lead to the outcomes you want occurring more often when you run the software.

    If you try to explain what is going on without these concepts, you’re left saying something like “the wrong token is being sampled because the probability of the right one is too low because of several thousand neural network weights being slightly off of where they would have to be to make the right one come out consistently”. Which is true, but not useful.

    The anthropomorphic approach suggests stuff like “yell at the software in all caps to only use python packages that really exist”, and that sort of approach has been found to be effective in practice.