markfeathers

I do not use books for engineering work and never will, because doing the work of thinking for myself is how I maintain the neural capacity for forming my own original thoughts and ideas no writer has seen before.

If anyone gives me an opinion from a book, they disrespect me and themselves to a point they are dead to me in an engineering capacity. Once someone outsources their brain they are unlikely to keep learning or evolving from that point, and are unlikely to have a future in this industry as they are so easily replaceable.

If this pisses you off, ask yourself why.

(You can replace AI with any resource and it sounds just as silly :P)

From my perspective they spread FUD about open source licensing. QT core is LGPL3. Many applications would be fine with using LGPL3 in commercial applications. Read QT's landing page on licensing, and fossa has a good block post on requirements.

https://www.qt.io/qt-licensing

https://fossa.com/blog/open-source-software-licenses-101-lgp...

>And everytime I end up confused about it.

I think this is the point. If you're making a real application you may pay for the licensing to avoid the uncertainty/risk.

Check out ARM SBSA / SBBR which seems aimed at solving most of these issues. https://en.wikipedia.org/wiki/Server_Base_System_Architectur... I'm hopeful RISCV comes up with something similar.

Anyone using VitualBox please be careful about the extension pack. Oracle is very litigous.

https://www.reddit.com/r/sysadmin/comments/147k6az/oracle_is... https://www.reddit.com/r/sysadmin/comments/d1ttzp/oracle_is_... https://www.theregister.com/2019/10/04/oracle_virtualbox_mer...

We banned virtualbox in our organization since vmware workstation (or virt-manager) is way cheaper than dealing with oracle.

Stock debian is 5 years with their LTS project, but they have a paid "ELTS" project that adds an additional 5 years. So 5 years for free, 10 total years as a paid support option. https://wiki.debian.org/DebianReleases

As I understand their water rights were recently revoked:

https://www.usnews.com/news/best-states/arizona/articles/202...

I switched for similar reasons, but went from Ubuntu to Fedora a couple years ago. I like Debian as well, but its a bit slower to release at every 2 years unless you stay on testing or backports. Fedora releases are every 6 months, and the kernel seems to update faster than that. I've been using docker and toolbx for things where I need vendor tools that are somewhat distro specific. Even if you use Debian I'd recommend toolbx for developers.

I'm not familiar with that definition, I typically see debouncing used as any means to filter out the state as it is changing from the mechanical action.

I've seen simple BSP debounce example code that affects latency for both press/release. For example you can make sure the IO hasn't changed in X ms before accepting it as settled and reporting the event up. This way would incur latency on both press and release. In fact, the first answer I see on google does this: https://www.beningo.com/7-steps-to-create-a-reusable-debounc...

You could report the event right away when there is an activation, and just not allow a deactivation event to be reported until the debounce time has expired. I suspect this is what you mean by debounce only applying on deactivation, but I'll bet some of the keyboards tested on that list are not doing this.

This post inspired me a few years ago to start a very impractical learning side project. Most keyboards don't overly prioritize latency. Development of a keyboard is easy using a USB stack from the manufacturer, but it might not prioritize latency.

I'm working on making my own FPGA based USB 2.0 HID device that will let me minimize any latency in the stack. PCB layout is mostly done, I'm working on a DECA FPGA board to prove out the USB hid software now. I started this pre covid though when Mach XO2s were inexpensive and available, so I have no idea who I will need to fight these days to get parts when I get to that point.

There is lots of wiggle room too in how you implement your debounce algorithm to optimize latency too. I'm excited to control the whole stack to try to make this as fast as possible. The Logitech lightspeed products came out after I started this project though and are far more practical for most people. I have one of those at home and will try to benchmark and compare them when I get there.

ptp is <1us synchronization. From my testing NTP is ~20-60us after about 10 minutes of sync, but it intentionally drifts the phase around. On average, NTP is pretty close.

If you look at the white rabbit FPGA PTP updates, its in the ns range.

Any kind of GPS + most intel nics will get you PTP with an accurate clock. If you didn't need to sync too many devices you could use a single system with a bunch of nics as your "switch".

Even so, a good RNG will make attempts to verify the quality of the entropy. For example, Intel's RNG will statistically observe bit patterns from their RNG. Eg, it fills up a FIFO and checks for the counts of certain bit patterns. If they aren't sufficiently random, it will throw away the data. Even if they dont have sufficient RNG data, unless you can predict how a PRNG is seeded it should be safe for quite some time without new true entropy.