Circuit breakers are not one time use like fuses. You can think of them as reusable fuses. An in device fuse only protects if the fault is in the device. If you were to put metal in the outlet, to stop current, you need a fuse in the outlet or somewhere else between the outlet and makns, which is what US has. Circuit breakers are typically 20A (or 15A) and multiple outlets are connected to the same circuit breaker.

They're hanging out with the people who make off by one errors.

I'm having trouble finding the exact details of the problem, but http was supposed to be fine because it does a signature check of the package (that's what the apt keys are for), meaning even if someone were to MITM you, the signature check would fail.

If I'm understanding the Debian security announcement correctly, it says there's a way a redirect can cause a package to replace another. I don't understand why this in itself is a problem unless it's also bypassing the signature check (which I'd expect to happen as part of the installation process and after download completion, not prior to download completion), but in that case it seems to me the heart of the bug isn't using http as http allowing MITM and manipulations is a given. The actual issue is bypassing the signature check, but I've not seen any articles explain that.

EDIT: now that I think about it, you can just download .deb outside of apt and install without a key, so maybe it isn't checked as part of install and only download, but that would still mean that the root problem itself isn't on the http/redirect side, it's the bypassing of the signature check. I want to look in to how apt functions more deeply.

EDIT: I think I got it. If you download 2 packages (A and B) as part of a single apt run, package A completes and passes signature check, package B gets a redirect such that it effectively gets renamed to A, when B completes, the signature check is not rerun on the file name of A, but what B should have been. A is replaced with a file that hasn't passed signature check and gets installed without a further check. I'm not suoer confident, but this is my interpretation of the Debian security announcement. This does out the problem more in the handling of http redirects because it's not updating the file name that's used for the sig check. I think I need to look at the code to be sure.

I've also not had great luck with MOTU devices (624, 8pre-es). Granted AFAIK, they're still not supported in mainline kernel, but I found a few kernel modules on github. Those kernel modules work in that the audio interfaces are detected and I can play audio, but after a couple mins (sometimes immediately), it sounds like I'm getting buffer under runs even if I max out my buffers. If I disconnect and reconnect the devices it will sometimes work for another few mins. They work perfectly on windows. My preferred DAW is also windows only, but I can run a windows VM and do USB pass through on the either of the audio interfaces (other is connected via AVB), and it works great. So this is how I do audio, but this also means I'm using onboard audio for everything except the windows VM.

Ok, but you listed a tool outside of the editor (grep). In this game, you dont get access to tools outside of the editor except a very limited "test" command.

You are 100% correct that it is possible to write code with only a plain text editor. It's how I got started. Pico + man pages (vi didn't make sense and I couldn't exit it anyway so avoided it for a while), but even with "just a plain text editor" I still had access to other tools like a compiler and its output, etc,m but we're not talking about programming on a normal system here. It's a game inside which you type code as part of playing the game.

If you look up screen shots for the game, you'll see what looks like a shell, but it only has a very small number of commands, so you don't have the tools you would normally have outside of the text editor (like grep). Can you search multiple files in the game? Yes, switch the editor between each file one by one (it has tabs) and search. Would a better in game editor improve that experience? I'd say yes. On a normal system you could get around edutor linitations by using tools outside the editor like grep. This isn't a normal system. It's a fake computer inside of a game and you don't get the typical tools outside of the in game code editor.

There may be some tricks that a JS developer would know to use inside the game, but I'm not a JS developer. That also means i need to look up JS standard functions and syntax outside of the game. Having it in game would be a better experience for me but not a requirement. I got pretty far in the game. I'll probably go back to it as newer ADHD obsessions allow.

It sucks even more than usual in the "game" because the code editor lacks what I'd expect in terms of syntax highlighting, jumping between functions, finding references, errors, undefined variable usage and such. Maybe those features are available, but I didn't know how to access them and I'm no JavaScript expert so a proper IDE (even embedding codium) would have saved me a lot of frustration. I didn't finish it. I think I got about 2/3, but I thought it was an interesting concept. So overall, I liked the concept of EmuDevz and a different language would have probably made it a better experience (as would a better code editor).

If this is of interest, you may also like EmuDevz. It's free on steam or via browser (maybe other options). I started the steam version before finding out of the web version. Gist is you make a NES emulator, but they don't call it that exactly in the "game".

https://afska.github.io/emudevz/

I feel like I had posted screen shots through it a couple times. This was about 2-3 years ago and I may be misremembering. If you can't do that via web, then I'd not expect it to work unless I was using a Teams for Linux that wasn't a web wrapper, but I thought they all were web wrappers on Linux.

I think you should look in to MIPI from a hardware protocol perspective before committing to that route. The issue isn't the physical connector, but the complexity of the protocol. I found some open MIPI cores. idk if you're allowed to use open cores, but if they fit in your FPGA (with whatever other logic you need for your CPU and glue logic), then that may work, but if I were a student I'd probably be looking for a simpler interface where I can have the FPGA control the flow of data (like request 1 row of pixels at a time given the memory constraints).

Outputting to VGA with an FPGA is fairly easy, but depending on what you mean by "image processing", this may be too big of a project given you're the only hardware engineer or maybe all you mean is to take the video input and output it to VGA without any further processing. You did mention wishbone, so I guess if you're planning to reuse a bunch of Open Cores, that could simplify some things.

How much RAM do you have on your dev board? How long of a video do you want to do?

USB2 is fast enough for uncompressed 640x480 @ 24 fps @ 24bit color: 640 * 480 * 24 * 24 = ~177Mbit/s (plus misc overhead) USB isn't so bad to get working on an FPGA dev board (I didn't see you mention which you're using) as it probably has a transceiver chip already along with drivers available. Even if not, you could add a cheap USB interface chip (FTDI makes some popular ones, but there's many others like CP2102, etc). I'd not try to do more modern USB (3+) as it's not needed, but also higher speeds bring more problems. I'd actually try lower quality video (lower res, framerate, and not 24bit color). As you increase the amount of data you need to transfer, you have more potential for issues related to buffering the video (and the extra memory required) or timing requirements (ensuring the video is arriving by the time it needs to, but not too much before).

If I'm understanding your main concern, it's how to get the video data in to your hardware? Generally:

• camera module (that outputs uncompressed image/pixel data, idk how difficult these are to get running, drivers often abstract a lot of complexity)
• video stored on memory chip like an eeprom (may be impractical given size)
• storage device like SD, compact flash, or even an IDE hard drive (idk how difficult SATA is to work with). if you go this route, I recommend avoiding file systems.
• stream over USB2 from a laptop (whether it's pre recorded file, built in camera, some USB camera or capture device kind of doesn't matter from your hardware perspective)

Other communication interfaces (like ethernet) are probably going to be a lot more effort although I've seen a serial to ethernet interface that worked similarly to those UART <-> USB chips. idk cost or how easy they are to use though.

EDIT: I see dev board is Basys 3 (I didn't realize that's what that was, I thought that was a camera). With only 1.8Mbits of memory, you're going to need to add memory (could be complicated), drastically reduce video quality and/or have some pretty strict timing requirements for the image data entering your hardware and maybe a camera module is the way to go at that point (vs USB from laptop, but I'm thinking flash memory like SD card is going to be more practical). You had mentioned designing a CPU, so I assume you intend to run software on this, which is also going to need to use memory. Depending on what that software wants to do, adding more memory may be a hard requirement. If you're just taking the video and outputting to VGA, you wouldn't even need the CPU and could probably get it to work without extra memory, but without being able to buffer much video data, you still have to ensure your video input meets timing requirements and I'm leaning away from streaming from a laptop due to that I thought you'd be able to buffer more data.

Also this dev board only does 12bit VGA output, so you can reduce your video color bit depth, which will help some.

It's basically chromium running the web version, but it appears as though it's a stand alone app. At least that's how it worked for the couple of Teams for Linux and Outlook for Linux apps I tried. I used this as part of a contract gig for about 2 years on Ubuntu machine.

I've used Teams on Linux and it worked fine. Granted it was basically just a wrapper for the web version, similarly with Outlook for Linux. I've not used One Drive on Linux, but that is what I'd be more concerned about.