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
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]));
}
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.
First, it doesn’t take an array as input, it takes a slice as input. You can turn a Vec<&str> into a slice &[&str] by borrowing it.
Second, the human-sort crate’s api is bad, because rarely to people have Vec<&str> or &[str] and there’s no way to produce a Vec<&str> from a Vec<String> without creating a new vector that borrows from the first.
let mut strs = Vec::new();
for s in strings.iter() {
strs.push(s);
}
human_sort::sort(&mut strs);
What human-sort should have done was accept &[T] where T: Deref<Target = str> which would allow passing a Vec of String or a Vec of &str.
Feel free to open a PR against human-sort, but it looks like it hasn’t been updated in a couple years so it might not be maintained anymore
Pawoo is a mastodon server run by the same company that owns pixiv. They’re using the default mastodon description but have also deliberately added tracking because they’re a company that doesn’t care about privacy.
I dont really know what point this post is trying to make. There are other mastodon servers you can join that wont track your activity.
I love writing rust and I’ve done all my personal projects for the last 4 or 5 years in it, but I dont think it’s a good idea for other existing languages to adopt more of Rust’s features.
Languages like Elixir or Lisp are so different it doesn’t make any sense to adopt Rust semantics or syntax, and anything with a garbage collector, Go included, doesn’t need to care about ownership, borrowing, or lifetimes (besides the usual passing references being cheaper than passing whole objects).
Languages like C or C++ can definitely be replaced in many cases with Rust, but I dont think making them more like rust is a wise decision. Adopting something like a borrow checker in c or c++ completely changes the language in a way thats not only backwards incompatible, but also probably not welcome by developers already working in those languages.
All this to say: I’d prefer more people to work in rust than to alter other languages to be more like rust, but I also think there are a number of other languages worth learning and working in. To a large extent, choosing a language is about taste.
oh I forgot to mention pict-rs is now nicely instrumented with the tracing framework and can export spans to OTLP collectors if the opentelemetry_url configuration option is set. It supports reading OpenTelemetry span information out of HTTP requests to enable tracing requests through the calling application to pict-rs and back. This is incredibly helpful for debugging.
Since lemmy is not instrumented (yet) with tracing, the benefit to lemmy admins and developers is not much, but this prepares for a future when lemmy is instrumented.
This also changes how pict-rs logs look. Hopefully admins and developers can glean more information from pict-rs logging now, especially in the event of an error.
Some general notes: I feel like blocking operations are faster now with tokio’s spawn_blocking underneath than before when it was actix-threadpool. I don’t have any benchmarks to demonstrate this, but I think I noticed an improvement when uploading files with actix-form-data + actix-fs in pict-rs while testing the upgrade.
- •
- 2Y
- •
- •
- 2Y
- •
- •
- 3Y
- •
I chose it at the start of the project 🤷