C11 gives you noreturn and alignas. Alignas can be pretty useful for low-level development in particular. Just hope you don't need variable-length arrays because those got changed to optional.
> Or even why use C99 over C89?
Several very big things: Native bool, stdint.h (fixed-width int types with known sizes ahead of time), long long, snprintf, not having to declare all variables at the top of the block (and now you can do for (size_t i = 0; i < sizeof(strbuf); ++i) because of it).
You can't curb abuse in a federated model. This is an issue that's been plaguing the fediverse as well. IRC networks, though not federated, have had to each individually ban spammers and other problematic users.
Google (GMail), Yahoo, Microsoft (Live/Hotmail), Yandex, QQ Mail. That ought to be enough for everyone. EDIT: and mail.ru
Indeed, C11 and C18 don't bring a lot. I'm glad that they don't because backwards compatibility and roughly predictable development of the language is important to me.
> You also have the long, complex and constantly changing list of rules which need to be applied for each update. They are very strict about noting down the copyright of all the files, for example (which I can understand to some extent).
Tracking licensing information very strictly makes sense.
Other than that, however, the Debian packaging process is something only a lawyer could love.
Wiimmfi is closed source software, however. If you actually want to look at how the internals worked, the independent altwfc project[1] may be much more interesting.
So now that Perl 7 wants to actively remove backwards compatibility from its culture, where are people to turn now for stable/non-moving scripting languages?
Oh. I see what's going on, and I was wrong about this.
US7949129B2 expired because he didn't pay the patent fees. US8321675B2 claims priority to a patent from 2001. Claiming priority is a way to broaden an existing patent by saying “it's this, but improved”; however, this also means inheriting the expiry date of the patent claiming priority to. So yeah, that one's expiring next year already. Holy cow, thanks for making me check.
Another, related patent that he notes in the FAQ[1] is 8,107,620, which won't expire until 2029 unless IBM forgets to pay patent fees. Hard to tell if it really applies to OCB3 though.
Given there's been a recent trend about ransomware not only encrypting, but also exfiltrating data, backups won't save you from the bad PR of the leak.
For some reason (probably due to QEMU), these kinds of bootloader tutorials are still stuck in the BIOS era. UEFI remains completely under-taught, which is probably in part because it's hideously complex.
Note that modern computers are supposed to be dropping BIOS boot support this year[1].
Legal types don't like the Unlicense either as far as I can tell[1].
You'll find software that is dual licensed CC-0 and something else, too,[2,3] because anything public-domain-ish with no attribution may be perceived as too risky.
> "Just Libsodium" doesn't work on anything smaller than a Raspberry-Pi, or pretty much any embedded system out there. There are alternatives out there
And the same author provides a solution for those systems as well with libhydrogen.
Though that doesn't look so super hot anymore given the recent advances on Gimli[1,2,3], but it'll likely still hold up in practice.
> but sometimes your only choice is to code and optimise it yourself
That is a critical shortcoming of the ecosystem. If you reach that point, you should be hiring a cryptographer/experienced implementer. Your follow-up question might be “Where do the cryptographers come from, then?” and the answer to that is: “PhD programs at universities, ideally”. Curiously, however, many (most?) cryptography libraries that are used in practice appear to be written by people with barely any academic background. We should be working to rectify that one way or another (send the implementers to university or pull more people from theory into implementation practice).
> you don't need to know all the attacks to protect yourself from them. What you need to know is the relevant classes of attacks, and how to void them
Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet?
And that's before you get to protocol design, where there are new, mysterious ways to shoot yourself in the foot (use TLS, use TLS, use Noise).
EDIT: I'm already aware that the system has been exploited to death and back, so I'm mostly curious if people haven't already dumped everything.