It's worth noting that Swiftfin finally had a new release for tvOS this summer which is worth checking out if you're interested in Jellyfin on Apple TV
It is indeed badly aliased. The technique demonstrated does not take into account antialiasing in the initial render, which causes this issue. There are ways to improve it, but I would advise against this approach in general since it doesn't handle these edge cases well.
x86-64 introduced a `syscall` instruction to allow syscalls with a lower overhead than going through interrupts. I don't know any reason to prefer `int 80h` over `syscall` when the latter is available. For documentation, see for example https://www.felixcloutier.com/x86/syscall
There was a Minesweeper on here that used a SAT solver, but I cannot find it at the moment. As I recall, it never had any issue with resolving the board quickly. I think it dynamically resolved where the mines would be as you played the game, and if you clicked a square that could be a mine, it would be a mine, except, I believe, when there were no open squares that were safe.
It's more a matter of your personal preference and previous exposure to different languages. The way Rust reads is one of its super strengths in my book. I also really enjoyed Standard ML in university, and Rust picks up some of that (via OCaml).
Adding some detail to this: With three buffers, you have one front-buffer (what's currently visible on screen) and two back-buffers. Let's call them A, B and C, respectively. This lets you work on the next frame in, say, B, and when it's ready, you queue it up for presentation. At the right time, then, the roles of the buffers will be switched, making B the front-buffer and A a back-buffer.
The third buffer comes into play if you want to start working on the next frame _before_ the switch has occurred. So you start drawing in C, and if the right time should hit, the display system can still flip A and B. In this case, triple buffering gave you a head-start with drawing the frame in C.
Going further, if you complete the frame in C still before the A/B switch has happened, you queue up C as the next frame, instead of B. Then, you can start working on the next frame again in B. With this scheme, there is no sense in having more buffers than three.
That's true for normal binary encoding of integers, but I think we should understand the question in context of the post: What's the number of bits required in iterated log coding?
I have realized that there is a big design space here, as I recently did a write-up of my take, Id30. 30 bits of information encoded base 32 into six chars, eg bpv3uq, zvaec2 or rfmbyz, with some handling of ambiguous chars on decoding.
It looks like it implements hardware acceleration of the VP9 codec for some specific hardware (Rockchip VDEC and Hantro G2). This opens up playing, for example, lots of YouTube videos with less CPU usage on devices with that hardware. I can't comment on whether or not it "took so long" as I have no idea which hardware this is.
The title makes it out to be something fundamental in Linux, but this is just one driver becoming more complete.
I, too, would have appreciated slightly more documentation. Here are two questions I had, and what I figured out.
Many RSS readers are stand-alone GUI applications. I would have appreciated an up-front notice that this is a hosted solution. (Which is what I am looking for. I'd like the same view of what's read and unread on my different devices, thank you)
Different RSS readers use different storage backends. I dug through your code, and it seems to use SQLite, which is exactly what I hoped for. It's a huge difference in deployment and system administration headaches whether it uses an embedded or a hosted database.
Looks interesting! I'd also appreciate a prebuilt binary for Linux, but I understand that it's still early days. Paying attention :)
>Also encoding ampersands into a URI (URL) using HTML encoding schemes is also common, but that is incorrect.
To encode any string (for example a URL) containing & in HTML, you must HTML-encode that &. Using & in the value of the href attribute for an a-tag must result in a URL containing just & in place of the entire entity. This is a property of HTML that has nothing to do with URLs or URL encodings.
I have recently experimented with writing dependency-free JS. I ended up using Webpack and Babel, but no frameworks or libraries, and I find it quite nice to work with. These are my tips for making the best of it: https://magnushoff.com/blog/dependency-free-javascript/