Authoritative zones are not concerned with the DNSKEYs of their parent zones, so I doubt that's the reason. Root zone key rollovers are only really important for resolvers.
The detection process basically boils down to 'server admins need to check CT themselves'. A CA also doesn't have to be malicious; a non-CA malicious actor could also exploit a vulnerability in the verification process of an honest CA. Depending on the severity of the situation that's unlikely to get them removed from the root stores.
Interesting example: last year Cloudflare found out that a CA had been (incorrectly) issuing certs for 1.1.1.1. They only found out 1.5 years after the first cert had been issued. The CA didn't do it with malicious intent, and as far as I know they're still in business. https://blog.cloudflare.com/unauthorized-issuance-of-certifi...
Certificate transparency doesn't prevent misissuance, it only makes detection easier after the fact. Someone still needs to be monitoring CT and revoke the cert. I actually believe most HTTP stacks on Android don't even check cert revocations by default.
If you use the flake system (which is technically still experimental, but everyone is already using it anyway), all your flake 'inputs' are automatically pinned in a flake.lock file that can be committed to git for reproducibility. So if you add nixpkgs as a flake input, your nix expressions will always be referring to the same exact package versions until you update the lock file.
The downside is that flake inputs refer to other flakes, not individual packages, so if you update the nixpkgs input it will upgrade all of your packages at once. For some packages such as Python, nixpkgs tracks multiple major versions so you can loosely pin to that version. You can also include nixpkgs as an input multiple times under different git tags/commits and only use that input for some of your packages to effectively pin them. You could keep using one nixpkgs but override the package's source to build it for a specific version/commit, but this setup could break in the future, because the derivation (and therefore build instructions) will keep evolving while your package's version will not. Or, if you really wanted to, you could straight up just copy the derivation from nixpkgs into your local repository and use that instead.
Nix is quite flexible so there's more options than just these, it just takes a little getting used to to find out what's possible. I don't use devenv myself, but some quick googling reveals it works just fine with flakes, so I would try that to see if it suits your needs.
That's a relatively recent development. Repairability has been very poor for quite a while, but now they're finally starting to improve the situation somewhat.
You can (partially) blame Microsoft for that. I still don't understand why it's seemingly OK for device manufacturers to distribute such crapware through Windows update. New keyboard? Oops, spyware. Printer on your LAN? Here, let me install these 16 utilities for you. Just give me a driver without any GUI tools. Or at the very least prompt me before installation.
Oh I'm getting so tired of this. Lately there appears to have been an uptick in this kind of marketing spam too, there's so many companies trying to advertise their AI products this way. At least it's a good indicator of which companies I should avoid at all costs, and it provides me with an email address I can use to direct my angry emotions towards.
They're getting more aggressive at it too. Just yesterday I received an email from Alignerr (not YC affiliated I think) saying that my sign-up was complete and cheerfully welcoming me to their platform. I had never even heard of them. An automated "job opportunity!" email didn't arrive until 3 hours later, but by then I had already directed some angry words towards their support email.
Other, even less respectable projects are also regularly enrolling my GitHub projects into their platforms, and I have to actively reach out to them to remove it.
I'm so tired of this man. Can someone go and take away these organizations' ability to send emails?
Yes! YoWASP is fantastic. In fact, that extension came to be after we contracted the dev to create NPM packages for the WebAssembly bundles they're maintaining. We use the exact same bundles if the extension detects that it is running in a browser (or if the user explicitly wants to use them). However, if possible we prefer to download and maintain native tool bundles for performance reasons.
Their VSCode extension is a lot more basic than ours, but it might be more suitable for advanced users. It's basically just a wasm tool runner that you pass command line options into, whereas we also include things such as project management and various visualization options. Which one to use depends on what your needs are, really.
I agree, this won't be for everyone. But if you're trying to learn how to use FPGAs, I think it helps a lot to have a tool like the one we're building. The learning process is also inherently very visual: it helps a lot to see what the individual steps look like, how Yosys synthesizes your Verilog code, where Nextpnr places the elements, what the chip looks like, what exactly your testbench is doing...
People who want to stick to the command line can always just use the tools directly. The extension tries to stay close to the tools by allowing users to directly modify the command line arguments and making invocations visible to the user. Heck, you could even use our standalone 'edacation' tool to run tasks defined in project config files (although admittedly I haven't tested that in a long time, so it might not really work that well)
Our intention has never been to build a one-size-fits-all solution. We want to show people that these fantastic OSS tools exist and can provide a viable alternative to Big FPGA's tools. We hope to be(come) a source of inspiration for what the scene could look like if we just let go of these massive toolchains that nobody really likes to use.
I know exactly what you mean and I share your frustrations with academic software. In our case I think it helps that our main goal is to provide a good user experience: we're not reinventing toolchains from scratch, but rather making existing ones available in a user-friendly way. Especially in the past year or so I've spent a lot of effort on reducing tech debt, modernizing the underlying architecture and squashing bugs. We've gone through several UI iterations just to see what would be most intuitive. Compare that to most pieces of academic software that should technically work, but are so difficult to use that nobody except the developers really know how to utilize it.
Our intention has never been to build a full alternative to e.g. Quartus Prime or Vivado that suits everyone's needs. Our main intention is to show people that FPGA toolchains don't have to be so difficult to get started with, and that alternatives are possible. And yes, I agree, that absolutely means good documentation on several levels to allow other people to continue working on the project. Good thing that's part of our mission, so it will be done; just takes a little bit of time ;)
Ha yeah, I agree the website isn't great. I set it up a while ago just so we have something to fill up the void. Right now it's just me and a professor of previously mentioned course who are actively involved in the project, so we've been mostly focused on the technical part.
That said, functionally speaking the extension is 90% of the way there. Synthesis, PnR, simulation, visualization and more all work for ECP5 & iCE40 FPGAs, and to limited extent some others as well. We have a few more features that we're working on, but a very solid basis already exists.
For technical reasons we have a bit of a deadline on finishing the project, which is likely in around ~6-7 months. So by then we intend to have a 1.0 release and very solid documentation out.
One big issue with FPGAs is how annoying it is to learn how to use them. I did a course on embedded systems a few years ago and nobody could truly get to enjoy it because we spent most of our time downloading and installing huge toolchains, waiting for synthesis and PnR to complete and debugging weird IDE issues. We need to open up the space to allow people to develop better solutions than what these companies are forcing down our throats.
There already exist fantastic open source tools such as Yosys, Nextpnr, iverilog, OpenFPGALoader, ... that together implement most features that a typical hardware dev would want to use. But chip support is unfortunately limited, so fewer people are using these tools.
We decided to build a VSCode extension that wraps these open source tools (https://edacation.github.io for the interested) to combat this problem. Students are already using it during the course and are generally very positive about the experience. It's by no means a full IDE, but if you're just getting started with HDL it's great to get familiar with it. Instead of a mess of a toolchain that nobody truly knows how to use, you now get a few buttons to visualize and (soon) program onto an FPGA.
There's also Lushay Code for the slightly more advanced users. But we need more of these initiatives to really get the ball rolling and make an impact, so I'd highly recommend people to check out and contribute to projects like this.
Technitium is great. Rock solid, plenty performant and it has more features than you'll ever need. Pretty wild when you consider it's being maintained by a single dev.