@migratory That last one was infuriating. Someone had "fun" designing this foolproof abstraction where you could initialize a 32bit uint once, and you could add to it, but if you multiplied it even once it got transformed into another type where you couldn't add anything, just multiply, and if you did it once more you'd end up with something immutable.
I _know_ what I'm doing, let me quickly add something to the "immutable" value. A developer screamed at me for wanting to hack this for a test.
@migratory Definitely "I know what I'm doing". 1000%.
"I'm adding a 64bit uint to a 16bit uint, I know what I'm doing, this will never ever overflow, its just what my bitstream reader outputs and I'm reading 8 unsigned bits."
"I know I'm giving two 512x512 partitions of a frame to 2 different threads, I know what I'm doing, those 2 will never ever ever overread/overwrite."
"I just want to quickly hack this overloaded 32bit uint type and add something to it, I know what I'm doing, let me do it".
@superluser I'm using pelican atm and its okay, there are plenty of plugins which you can easily hack to do what you want.
It also accepts HTML input so for the cases where you need to write raw things you still get a nice themed output.
I had to hack my theme quite a bit, but I'm happy with how it turned out. I still have the option to change themes without everything breaking.
I only tried pelican because its in the debian repos and had few dependencies, so it paid off.
That's also a reason to not get POWER9, no one's written any advanced SIMD for it, so there's bound to be more bugs.
If I ever buy a CPU I'm not buying from a place that doesn't offer arbitrary refunds.
If I do get a CPU, I'm running ffmpeg and dav1d's checkasms a few hundred times and prime95 for an hour to test for SIMD bugs.
If I had a CPU with some obscure SIMD bug, I'd never ever suspect it and would instead blame literally anything else.
@sir The White Palace was tolerable. Unlike traditional platformers, you could approach it in multiple ways because of the charms you can equip.
Godhome is to me, not cannon. Its a boss rush mode that's somehow more nicely built into the game than a post-finish menu option. Running that is acquired taste, it can be fun occasionally.
@wolf480pl I did say you can live with that. 0s during syscalls.
If you can't, you still don't deserve your own special kernel and ABI.
@wolf480pl The kernel knows about mmap, so you can give it 32 bit pointers with 0x0 in the upper 32bits.
Surely you can live with that.
@wolf480pl Just define them.
The kernel knows about the mmap, it'll translate your 32 bit addresses even if you communicate with it. MMUs are a thing.
But moreover, if you're psycho enough to want 32 bit pointers to go to this effort, you deserve what you have to go through and more.
@wolf480pl Its completely pointless, an overkill that does not deserve an entirely new kernel and ABI for a theoretical gain of a few percent, if at all. All for a pointer size.
If your program has _that_ many pointers, just use mmap with MAP_32BIT as address space. Bonus: your program will still work on standard 64-bit systems.
@nivex I know, I know. I just think that anything old enough to require or auto-redirect to a www record is probably not going to work with TLS 1.2 and HSTS anyway.
@nivex It requires a www. DNS record in order to check for web server IPv6 connectivity.
How old is this thing and why doesn't it check for ActiveX, Java, IE DirectX extension and Flash versions?
You wake up at 2 in the afternoon, you have the most terrible hangover ever, you're missing work, your phone has 99 missed calls, your hands have many strange symbols drawn with a marker, one of your shoes is surgically cut in half and is glued to the ceiling, you clamber over to your laptop and as you notice by far the weirdest thing you've seen yet, you let our a shocked blood-curdling scream:
Finally got my blog in order and wrote a piece on handwriting IIR filter SIMD:
@quad I'm pretty sure the FInal Cut users would be the least likely to want to use a hardware encoder. They'll never match the quality of even a mediocre software encoder.
Prores can be cheaply done on the GPU with compute shaders, so playback and encoding won't be bad. Its anything highly serial like h264 or hevc that's a problem.
As for how fast x264 is on ARM - its beyond sluggish. Although it got some optimizations from Facebook (IIRC), its still nowhere near x86's level of optimizations.
Codec researcher, x86 assembly and Vulkan expert. As expected.
Had nothing to do with x264. Most unexpected.
A Mastodon instance for people interested in multimedia, codecs, assembly, SIMD, and the occasional weeb stuff.