I chose it at the start of the project 🤷

Update on this: I got the feature work done this weekend, so now I’ll be testing it a bunch for upgrades and storage migrations

I am aware of garage, but haven’t tested it yet with pict-rs. It’s a cool project for sure

Yes. It uses sha256 rather than perceptual hashing, but that’s Good Enough™️

I’m not against including an ipfs layer in pict-rs, but the complexity would go way up. Federating an image between lemmy servers would require sending the ipfs uri between servers via activitypub, and then each receiving server sending that uri to pict-rs. pict-rs would then need to decide, on each server, if the ipfs-stored image matches that servers’ image requirements (max filesize, max dimensions, etc), and if it does, then that pict-rs server would request to pin the image. I don’t know exactly how ipfs pinning works, but ideally it would only be stored locally if it isn’t already stored in at least N other locations. If the remote image doesn’t match the local server’s configuration, it could either be rejected or downloaded & processed (resized etc).

Serving ipfs-stored images that aren’t replicated locally might also be slow, but I won’t know for sure unless I actually try building this out.

I can only say “when it’s ready.” I think most of what I want to include in 0.4 is there, but I don’t have a ton of time to work on it currently. I might see if I can get my last feature changes in this weekend, then it will be a matter of ensuring the 0.3 -> 0.4 upgrade is smooth, and that storage migration is solid

pict-rs doesn’t keep track of how often it serves different images, so there’s not a good metric for pruning old images. That said, 0.4 will introduce functionality for cleaning up processed images (e.g. resizes/thumbnails), removing their files & metadata. If they are viewed again, they will be re-generated.

0.4 will also include the ability to scale down images on upload, rather than storing the original resolution. This is not yet implemented, but it’s on my roadmap.

All this said, it is already possible to use pict-rs with object storage (s3-compatible), rather than block storage. That’s a good option if your hosting provider offers it

what I noticed personally is that my pict-rs server had eaten 1,200MB of RAM, which is the limit I allowed that container. it was still working and it automatically restarted on crash so I didn’t notice it oops

after I fixed the problem, my pict-rs server has been running at about 29MB for the last 12 hours. Significant improvement I’d say

for context: I am the pict-rs developer

Problem:

I gave tokio-console a buffer way too big

Fix:

Update pict-rs to at least v0.3.0-rc.7, which doesn’t enable console by default

how long does it take for pict-rs to use up this memory?

Yes

If you don’t know what OpenTelemetry is but you’re having OpenTelemetry errors in your logs, it likely means that you have an opentelemetry_url set in your config when you shouldn’t. You can get rid of the error by deleting that line, which will disable opentelemetry exports

Lemmy and pict-rs support optionally exporting opentelemetry spans, and setting up Jaeger to capture those is a nice way to manage traces without shipping data to third parties

Plugin is likely lewis6991/gitsigns.nvim

playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=39a1c5c855a4c3d5d537f446c3b72783

i might try

let res = collection.into_iter().map(|item| item.fallible_operation()).fold(Ok(Vec::new()), |acc, res| {
    match (acc, res) {
        (Ok(mut vec), Ok(item)) => {
            vec.push(item);
            Ok(vec)
        }
        (Err(mut vec), Err(error)) => {
            vec.push(error);
            Err(vec)
        }
        (Ok(_), Err(error)) => Err(vec![error]),
        (acc, _) => acc,
    }
});

Maybe expand it with

pub trait Evert<T, E> {
    fn evert(self) -> Result<Vec<T>, Vec<E>>;
}

impl<I, T, E> Evert<T, E> for I
where
    I: IntoIterator<Item = Result<T, E>>,
{
    fn evert(self) -> Result<Vec<T>, Vec<E>> {
        self.into_iter().fold(/* implementation from above */)
    }
}

fn main() {
    let result = vec![Ok(1), Err(3), Ok(4), Err(8)].evert();
    assert_eq!(result, Err(vec![3, 8]));
}

elementary OS

With these examples I think the correlation is a little loose. Dr Lutchmedial died two weeks after his third shot. Claiming the vaccine was a direct cause when the only available evidence is a two week timespan is weak.

The other example provided doesn’t demonstrate harm caused by a vaccine. It sucks that a deadly virus is deadly, and it sucks that the vaccine didn’t help in this case. It’s not a good argument against getting a vaccine.

I’m a sponsor on github for spacejam (github user) and elementary OS, and I’m a patron of Hector Martin on patreon.