I have one of those 2FA code generators, and used to have a different one with a business account, too.
In both cases the authorisation challenge/response involves part of the destination account number, so if the details are tampered with by malware the code won't work.
For me, Ubuntu / Gnome 2 came so close to being something tech-savvy people could recommend to non-technical friends and relatives at a time when people who were happy enough with WinXP and Win7 were being corralled into dealing with the Win8 carcrash. And instead of closing that final gap it went scampering off into the far distance again, never to recover.
> Some open source projects have also starting adopting Discord to manage their communities.
And I've chosen not to engage with more than one such community because I'm not perpared even to give Discord my phone number, let alone any kind of ID document. Luckily there's nothing on Discord I care about that much, so I'm not having to make too difficult a choice. I totally get why most people won't take such a stand.
I used a PSOC (4) for a project once, and while the chip itself was awesome the software was so bad that attempting to use the next version of the software "bricked" the devboard I was using. (Something to do with the new serial bootloader being a different size. "Bricked" in quotes, because with the right kind of expensive programming cable it could have been resurrected - but the whole point of the devboard in question was that it was cheap and self-contained, not needing an external programmer.)
Vivado offers some embedded debugging and logic analyzer infrastructure, which allows you to tap into signals within the design and monitor them from the PC. (For instance, the Memory Interface Generator will report its initialisation status to the PC and if something failed it will tell you what). This is done over JTAG, and Vivado will only support that when using a select few JTAG dongles.
If you're happy to create your own debugging infrastructure (which isn't that hard - almost all FPGAs have at least two dedicated IR scancodes specifically for user applications) then you can use any JTAG dongle supported by OpenOCD.
You'd think, wouldn't you? But in some regards they still feel less responsive than the desktop of a sub-10MHz machine from the 1980s.
(I'm not kidding - the tight coupling of quadrature-based mouse counters and hardware sprite mouse cursor - bypassing all the wireless, serial / PS/2 / USB encoding and decoding we have today - and on-screen gadgets being drawn and redrawn in the input subsystem's context without messages having to trickle through a ten foot long pipeline of frameworks and UI toolkits, all gave a sense of immediacy, of "having the computer's full attention", that's rare to find in today's world of janky semi-functional web apps.)
Interestingly, gcc-amigaos-gcc 6.5 uses dbra without having to jump through any of those contortions, as long as the optimisation level is set to at least -O1:
One thing that I heard from folks who do development for retro Atari platforms is that the 68k support in GCC has been getting worse as time has gone on, and it's very difficult to get the maintainers to accept patches to improve it, since 68k is not exactly widely used at this point.
Specifically, I heard that the 68k backend keeps getting worse, whilst the front-end keeps getting better. So choosing a GCC version is a case of examining the tradeoffs between getting better AST-level optimisations from a newer version, or more optimised assembly language output from an earlier version.
I imagine GCC 6.5 probably has a backend that makes better use of the 68k chip than the GCC 11.4 that ngdevkit uses (such as knowing when to use dbra) but is probably worse in other ways due to an older and less capable frontend.
I tried this with the old SAS/C Amiga compiler. It put addresses in A0 and then moved value into (A0) on next instruction, so the setup part was a bit more inefficient. And refused to use "dbra" no matter what I tried.
My own blog - which gets maybe a couple of posts a year these days, and almost no audience - had 59 spam comments so far today. It really is time I turned off comments.
Yosys doesn't do place-and-route - typically that part would be handled by nextpnr, and there's an experimental fork of that for Xilinx series 7 devices:
https://github.com/openXC7/ (full toolchain)
It works well enough to build a working litex RISC-V SOC capable of running Linux, for the QMTech Kintex-7 325T board.
I don't think the Cyclone V project has got as far, but I could be wrong. (It kind of slipped off my radar after I realised I was spending way too much time on Discord and purged all but a very few servers to reduce my distractions.)
In both cases the authorisation challenge/response involves part of the destination account number, so if the details are tampered with by malware the code won't work.