`1cpy` is a single-memcpy (assumes message size divides buffer size evenly)
`2cpy` is the split memcpy (which supports other message sizes)
`funny` is single-memcpy with the double-memmapped buffer
and:
`mod` uses `head %= buffer_size`
`and` uses `head &= buffer_size`
`sub` uses `if (head >= buffer_size) head -= buffer_size`
The tl;dr here is that the doubly memmapped buffer performs the same as the 1-memcpy implementation that doesn't do anything funny and significantly better than all 2-memcpy implementations except `and`. Since your page size is gonna be a power of 2 anyway, this means this trick is not really worthwhile and indeed you should just use `and`. But, compared to the other wrapping implementations it does still provide a tangible improvement. That may just come down to how the compiler was able to optimize it, but I don't feel like nitpicking the generated code to figure out why right now.
What is a "super segment hybrid display"? Looks cool, has VFD vibes, but I assume it's just an OLED with an overlay or something based off in the Verge article "Most of the KO II’s parts are just off-the-shelf components, including the display"
> Like Hysteria, Brutal is designed for environments where the user knows the bandwidth of their connection, as this information is essential for Brutal to work.
They don't quite say that this is a bad idea for use over WAN. If they intentionally avoided ruling out such usage in this qualification, they're making an implicit assumption here that either the last-mile connection or the endpoints themselves are going to be the bottleneck. If some router in between is having a bad day, it would definitely make its day worse.
edit: I wasn't familiar with Hysteria but now that I'm reading those docs, I guess the intent is for this to be used on the internet. In that case, it does seem pretty like it'd be pretty adversarial to run this. I bet if it saw widespread adoption it'd make ISPs pretty upset.
edit 2: Going slightly off-topic now, but I wonder if the bandwidth profile of Hysteria compromises its HTTP/3 masquerade?
Yeah, I agree full DIY is not for everyone, but SMT assembly is pretty affordable even in small batches these days. I just placed an order for 5x of a 60% unibody ortho board and it came out to roughly $40 a piece before switches, case, etc.
The layout is eerily similar to one I designed last year [1]. I may be biased, but I'm not sure if it is worth the $365 price point. That being said, it is a bit more refined and has some nice accessories bundled.
I may pick one up for comparison. But, just noting that there is a comparable open source design available. ;)
I use a service called Plausible for this - they are privacy focused (do not even use cookies) but there are some drawbacks (like not being able to really know MAU since user identifiers reset daily)
> * A replacement front-end for "ffmpeg", see above
I have one of these too... It's kind of frightening how hard ffmpeg is to use without some kind of custom frontend. I have probably dozens of bash/python scripts to invoke ffmpeg for different common tasks.
- One to extract audio
- One to extract all the individual streams from a container
- A couple different transcoding scripts
- One specifically for gifs
- One to crop video
- A few that I can't remember the purpose of... and can't tell from reading the source
I quite easily set up a DNS blacklist on my USG. Still not quite what I'd call consumer friendly, but only a couple of console commands as opposed to setting up the entire pi. Instructions here: https://community.ui.com/questions/HowTo-Ad-blocking-using-d...
1000000 iterations, buffer 8192, message 128
i9-13900K, gcc 13.3, -O3, kernel 6.8.0-49, glibc 2.39
byte-mod: 0.117353 us/iter
byte-and: 0.065379 us/iter
byte-sub: 0.027865 us/iter
1cpy-mod: 0.001143 us/iter
1cpy-and: 0.001100 us/iter
1cpy-sub: 0.001098 us/iter
2cpy-mod: 0.008140 us/iter
2cpy-and: 0.001100 us/iter
2cpy-sub: 0.007711 us/iter
funny-mod: 0.001145 us/iter
funny-and: 0.001101 us/iter
funny-sub: 0.001100 us/iter
where:
`byte` is per-byte copy
`1cpy` is a single-memcpy (assumes message size divides buffer size evenly)
`2cpy` is the split memcpy (which supports other message sizes)
`funny` is single-memcpy with the double-memmapped buffer
and:
`mod` uses `head %= buffer_size`
`and` uses `head &= buffer_size`
`sub` uses `if (head >= buffer_size) head -= buffer_size`
The tl;dr here is that the doubly memmapped buffer performs the same as the 1-memcpy implementation that doesn't do anything funny and significantly better than all 2-memcpy implementations except `and`. Since your page size is gonna be a power of 2 anyway, this means this trick is not really worthwhile and indeed you should just use `and`. But, compared to the other wrapping implementations it does still provide a tangible improvement. That may just come down to how the compiler was able to optimize it, but I don't feel like nitpicking the generated code to figure out why right now.