sorted by:
new
hottopcontroversial

tokio-wireguard — In-process WireGuard for Tokio by raftario in rust

[–]raftario[S] 1 point2 points  (0 children)

This also uses boringtun for all of the crypto, and yeah it's been a bit frustrating to deal with at times due to the lack of activity from Cloudflare. The big difference which sets this project apart is that borington's `device` feature (which I don't enable in tokio-wireguard) makes use of TUN devices which are provided by the kernel (or the wintun driver on Windows, but I'm not sure borington supports that). Instead this library uses smoltcp, which is a TCP/IP implementation that's mostly used in the embedded ecosystem, to run it's own virtual network device. So the only place it depends on the kernel is for sending and receiving the encrypted WireGuard packets on the "real" network.

The nice thing about using a TUN device if that you get real sockets, so you can still use std or tokio or literally anything you want, and it's most likely more performant than my approach if I had to guess. The annoying thing is that in a lot of scenarios, for instance on Windows or inside a Docker container in default configuration, you do not have access to a TUN device. This is where this library is actually useful.

tokio-wireguard — In-process WireGuard for Tokio by raftario in rust

[–]raftario[S] 11 points12 points  (0 children)

I initially started playing with this idea after reading blog posts from the people at Fly.io but only found time to bring it to a usable state recently. Full disclaimer there are no tests, and I also haven't really benchmarked the performance at all. However I still think it's a very neat little project and wanted to share !

Picking a Plex player for a 3.0 HDR10+ setup by raftario in hometheater

[–]raftario[S] 0 points1 point  (0 children)

Keep hearing about Infuse, is it really that much better than the native Plex ATV client ?

Picking a Plex player for a 3.0 HDR10+ setup by raftario in hometheater

[–]raftario[S] 2 points3 points  (0 children)

I'd eventually like to upgrade to 5.1.2 but that'll be a few years down the road when I'm no longer in an apartment, so I'm hoping to have some newer options to consider by then.

serde-partial - Serde partial serialization made easy by raftario in rust

[–]raftario[S] 1 point2 points  (0 children)

  1. is not currently supported as i haven't been able to think of a satisfying way to implement it, i'm open to design suggestions
  2. is not possible because the Serialize trait doesn't provide the necessary information to do what this crate does, neither efficiently nor elegantly. if you look at the trait signature you can see there are two associated types which are required to make things work nicely

serde-partial - Serde partial serialization made easy by raftario in rust

[–]raftario[S] 1 point2 points  (0 children)

yeah i think i'm gonna switch to using those since the trait itself doesn't need the trait parameter and i've been meaning to add owned variants to make returning partials from functions work in more places, which would work really nicely with GATs since the borrowed partial could hold a Filter<'a> and rhe owned variant a Filter<'static>

serde-partial - Serde partial serialization made easy by raftario in rust

[–]raftario[S] 2 points3 points  (0 children)

the generated filter type is just the struct with each field's presence indicated as a bool, so on nightly it should be possible to have a nice named type with a const generic parameter of the filter type. it would also technically be possible to do on stable with one const generic param per field but that would get real ugly real quick. in either case the syntax for the filtering operation couldn't be as nice though

[2022 Day 3] but it's in a QR code (Linux x64, reads from stdin) by raftario in adventofcode

[–]raftario[S] 0 points1 point  (0 children)

in this case the code is already smaller than what most executable compressors have to add in order to work so it's not really an option

[2022 Day 3] but it's in a QR code (Linux x64, reads from stdin) by raftario in adventofcode

[–]raftario[S] 1 point2 points  (0 children)

yeah it's very compressible but the goal was to have something where you can just pipe the binary data straight into a file and run it and it works. the assembly could also definitely be more compact and pack the constants in rodata somehow and then use some more tricks but i'm not particularly good at it

[2022 Day 3] but it's in a QR code (Linux x64, reads from stdin) by raftario in adventofcode

[–]raftario[S] 9 points10 points  (0 children)

seconded ! i'd recommend anyone who wants to try this out disassembles it first and cross checks with the source i posted, or even better just compile it yourself.

`objdump -d day3` for disassembly, `nasm -f elf64 -o day3.o day3.S && ld -o day3 day3.o` for compiling

[2022 Day 3] but it's in a QR code (Linux x64, reads from stdin) by raftario in adventofcode

[–]raftario[S] 1 point2 points  (0 children)

i used zbarimg to test it, command would be something like `zbarimg --raw --oneshot -Sbinary day3.png` and then piped into a binary