8,752 karma · joined July 3, 2014
Actually even the Fedora package's specfile only says Python 3, so I'm not sure why the README says that it still needs Python 2.
Edit: Okay, the explanation is in this commit message: https://github.com/boltgolt/howdy/commit/305e42fc79ef38f66c5... . The dep on Python 2 is from Fedora's PAM module package, not from howdy itself. On OpenSUSE the corresponding PAM module package depends on Python 3 already.
You're confusing Microsoft's first-party Linux distro Azure Linux (nee CBL-Mariner) that is intended as a regular MS-supported OS for containers, VMs, servers, etc, with various Windows-like skins for Linux DEs that people have made for years.
For example a RISC-V CPU implementing the Zkt extension is required to implement a whole bunch of logical and arithmetic integer operations with operand-independent timing. This includes the two "branchless move" instructions from the Zicond extension, czero.eqz and czero.nez.
A simple example is that the CPU might support running two specific instructions better if they were adjacent than if they were separated by other instructions ( https://en.wikichip.org/wiki/macro-operation_fusion ). So the optimizer can try to put those instructions next to each other. LLVM has target features for this, like "lui-addi-fusion" for CPUs that will fuse a `lui; addi` sequence into a single immediate load.
A more complex example is keeping track of the CPU's internal state. The optimizer models the state of the CPU's functional units (integer, address generation, etc) so that it has an idea of which units will be in use at what time. If the optimizer has to allocate multiple instructions that will use some combination of those units, it can try to lay them out in an order that will minimize stalling on busy units while leaving other units unused.
That information also tells the optimizer about the latency of each instruction, so when it has a choice between multiple ways to compute the same operation it can choose the one that works better on this CPU.
See also: https://myhsu.xyz/llvm-sched-model-1/ https://myhsu.xyz/llvm-sched-model-1.5/
If you don't do this your code will still run on your CPU. It just won't necessarily be as optimal as it could be.
Incidentally the fact that it took them 4 days to respond to that issue is why I'll be wary of getting 6-day certs for them. The only reason it wasn't a problem there was that it was a 30d cert and had plenty of time remaining, so I was in no rush. (Also ideally they'd have a better support channel than an open forum where an idiot "Community Leader" who doesn't know what he's talking about wastes your time, as happened in that thread.)
This doesn't work when the error is already MyError so you want to make sure that `context` contains everything you might want to know about the call stack. Eg if you're writing a web server application you might have an error at the network layer, the HTTP layer, the application layer or the DB layer. So your context can have four Option fields and each layer can populate its field with whatever context makes sense for it.
With C++ the existence of such "extended integer" types is implementation defined. clang at least supports the same _BitInt construct for C++ too. gcc seems to not support it.
So, for the 256 case on x86_64, both clang and gcc seem to only generate the simple adc ripple version: https://gcc.godbolt.org/z/nxoEda3q5 https://gcc.godbolt.org/z/bYf4bor3f
I don't know if they still pronounce it that way or not.
Although it's old and its dependencies are old, it doesn't have a dependency on cargo (it spawns cargo as a subprocess instead of via cargo API directly), so it might still work fine with latest toolchain. I haven't tried myself.
https://datatracker.ietf.org/doc/html/rfc8555#section-8.4
>2. Query for TXT *records* for the validation domain name
>3. Verify that the contents of *one of the TXT records* match the digest value
(Emphasis mine.)
I also wrote up a digested description of the issuance flow here: https://www.arnavion.dev/blog/2019-06-01-how-does-acme-v2-wo... It's not a replacement for reading the RFCs, but it presents the information in the sequence that you would follow for issuance, so think of it like an index to the RFC sections.
If you don't have even one user willing to do that for the distro they use, you probably weren't going to have users on that distro anyway.
ARM Windows laptops only use ACPI because Windows has no interest in DTs, but under Linux these devices are still booted using DT. I don't know for sure, but the usual reason is that these ACPI implementations are hacked up by the manufacturer to be good enough to work with Windows, so supporting them on Linux requires more effort than just writing up the DT.