There’s also pzip[1], which lets you create zip files and extract them in parallel.

[1] https://github.com/ybirader/pzip

Disclaimer: I’m the author

Astro is amazing. I built my blog with it, hosted on CF pages [1].

DX is great.

In most cases, ships absolutely zero JS to the client, meaning super fast load times.

[1] https://www.yusufbirader.com/

Thanks for the feedback!

There's also pzip/punzip (https://github.com/ybirader) for those wanting more performant (concurrent) zip/unzip.

Disclaimer: I'm the author.

Has anybody else used Rust for embedded?

Would be interested to hear your experience.

So far, I’ve seen mixed reviews. Some say that you can end up using unsafe a lot and so it’s better to stick with C or even use Zig.

Wondered if there was any merit to this.

> Some say that you can end up using unsafe a lot and so it’s better to stick with C or even use Zig

Using unsafe in Rust isn't inherently bad. If you're doing embedded work, using unsafe is mandatory once you get to the level of interacting with the hardware.

That doesn't mean the code is literally unsafe, just that the interactions are happening in a way that the compiler can't guarantee. That's completely expected when you're poking at hardware registers.

You still get most of the benefits of Rust, the language. I've had good success with it.

Yep I get that- it's just that using unsafe reduces the benefits you get from Rust's model.

And so I was wondering whether using it is still worth it.

Obviously, it probably still has many benefits over C but something like Zig might be simpler and better suited.

> it's just that using unsafe reduces the benefits you get from Rust's model.

No, you still get the benefits where it matters.

The "unsafe" is basically marking a boundary where you're doing things outside of what the compiler can verify. If you're poking at hardware registers, that's expected and normal.

Putting "unsafe" in a program at the hardware boundary doesn't reduce the benefits of Rust elsewhere in the program.

At the moment it doesn't- if it's something you're looking for, please open an issue.

I didn't want to go down the route of implementing a bunch of features without there being a actual need for them, especially for an initial version.

Yep the standard I refer to is Info-ZIP (zip(1)).

I will add the resulting compression sizes- there is not much between them (pzip was around 2% larger for the 10GB directory). Although, I do have some optimizations in mind which will bring this down further.

Allowing for 2% bigger resulting file could mean huge speedup in these circumstances even with the same compression routines, seeing these benchmarks of zlib and zlib-ng for different compression levels:

https://github.com/zlib-ng/zlib-ng/discussions/871

IMO the fair comparison of the real speed improvement brought by a new program is only between the almost identical resulting compressed sizes.

https://hardwary.com/ for hardware news

Thanks. I’ve reduced it.

Appreciate the feedback!

I’ve reduced the font size for small screens so the post density should be higher.

Agree that learning to solder is on the basic side but I thought it would be nice to have some posts for complete beginners.

If you have any feature requests, let me know:

https://hardwary.canny.io/hardwary-feature-requests

I would start off with catering to the people that already are well into advanced territory, beginners can learn from them by just reading and lurking. Starting off with beginner stuff will turn off the people that are way past that. Aiming for the right audience to start with is a major challenge in any kind of community, in my opinion you can't aim high enough for the starting few 100.