KIT had a project on this (Project KAMINA) which looks like it is also cited in the linked paper.
They had a spin off SMELLDECT GmbH which sells a kit but not exactly a order from DigiKey thing. I imagine you will need to send an RFQ and go through the motions with their sales team.
Fair, but if you look at most tools for Static Code Analysis they will have equal or worse performance with regards to false positives and are still seen as added value.
If this is inexpensive (in terms of cost/time) it will likely make business sense even with false positives.
But that isn’t the claim. The claim is an agentic pen tester “trounced” human testers. Static analysis tools are already trivial and cheap to automate, why would you need an agent in the loop?
I agree with your point that the claim is exagerated. My counterpoint is even if they are subpar, they will still make business sense if they are inexpensive, much in the same way that Static code analysis tools aren't great but because they are inexpensive they still make sense during development.
Even if they don't brick them explicitly they will no longer provide security updates for them.
I'm on the same boat, smart TV has never been online, all content is just cast from media server/phone/tablet straight to chromecast. It works, no fuss, glitch free, and of course they will kill it.
Even if they were to provide security updates, a few platforms no longer work with them. At the very least, now Disney+ refuses to stream to my original chromecast dongle.
Slightly off topic but that lab book made me a bit envious.
I doubt my mental bandwith could cope without org mode and digital formats in general. But that penmanship and the general neatness really shows a focus and an intentionality that makes me feel that something has fallen off the wayside in this digital transition.
> Who out there is programming these chips in pure C using open source compilers and bootloaders?
The gcc-arm-none-eabi toolchain is pretty much what you are asking for at least for ARM targets. You can literally use a text editor and gcc-arm-none-eabi, that's it.
And if you want something really bare bones avr-gcc still targets the whole atmel family including those ATtiny chips which are also a lot of fun.
I don't know the state of it nowadays but 'Mbed' is probably worth looking into. The project had _a_lot_ of Middleware libraries to abstract hardware, a few levels below, makes embedded development a little less datasheet dependent, specially if you are just hacking something as a hobbyist.
You can also ditch the space consumed by a bootloader and save the UART for something productive in your designs. This is makes it feasible to use the smaller capacity chips and have more headroom on the larger ones. AVR programmers are cheap and the latest serial port based protocol requires the barest of hardware to support.
I've been using Anthropic's models with gptel on Emacs for the past few months. It has been amazing for overviews and literature review on topics I am less familiar with.
Surprisingly (for me) just slightly playing with system prompts immediately creates a writing style and voice that matches what _I_ would expect from a flesh agent.
We're naturally biased to believe our intuition 'classifier' is able to spot slop. But perhaps we are only able to stop the typical ChatGPTesque 'voice' and the rest of slop is left to roam free in the wild.
Perhaps we need some form of double blind test to get a sense of false negative rates using this approach.
That's definitely true, but keep in mind the economics of cranking out AI slop. The whole point is that you tell it "yo ChatGPT, write 1,000 articles about knitting / gardening / electronics and organize them into a website". You then upload it to a server and spend the rest of the day rolling in $100 bills.
If you spend days or weeks fine-tuning prompts to strike the right tone, reviewing the output for accuracy, etc, then pretty much by definition, you're undermining the economic benefits of slopification. And you might accidentally end up producing content that's actually insightful and useful, in which case, you know... maybe that's fine.
Yes one should write flesh out rather than flush out. However, as someone who uses English as a second language, the concept of phrasal verbs is the single most non-intuitive thing (with the very real risk for severe faux pas).
From your own words, to flesh out implies to me as a non-native that I remove flesh from said thing, when in reality the expression is to mean that you "add" flesh to bones. Very confusing.
> the concept of phrasal verbs is the single most non-intuitive thing
I once said that a person seemed pretty "turned on" when I meant "switched on". Luckily it was on a private conversation with a friend who laughed and took the mickey out of me but then explained the situation so no harm done.
They do move 'naturally' in the right direction if you think of a cell and it's membrane it can be loosely abstracted as a dielectric material and like any other dielctric can be polarized.
The issue with diabetes is that over time periphery blood supply becames problematic which means healing takes way longer, sometimes never healing at all leading to necrosis (dead tissue).
So you could argue that 'accelerated healing' tissue is a poorer grade tissue by some metric, e.g. connective tissue is not as flexible or strong etc. But in diabetic wounds the alternative to 'accelerated healing' tissue could literally be an amputated limb.
Most of these e-ink solutions are great for reading (mostly static) content but still feel like a compromise for productive work.
I wish there was a bigger market and interest for 'unsexy' RLCD transflective displays, at the moment all the RLCD solutions feel very constrained for user side modding and just generally overpriced.
Something like the old Pixel Qi 10" Display modules in a bigger form factor would be ideal.
Well the project description seems to hint at to their motivation:
> 1000 Hz polling rate
> No multiplexing, no ghosting
> FPGA-based, VHDL only, no ALU
It looks like a pure HW 'described' keyboard with no running software meaning it is fully parallel (plus some serialization when reaching the USB device/interface).
So arguably on top of true parallelism the only ceiling for the latency of the whole thing will be the clock period configured in the design and the physics and electrical behaviour of the switches themselves + circuitry.
Probably someone who enjoys working close to hardware and wants to optimize performance.
Most MCU-based keyboards have a 1000Hz polling rate - and some mainstream gamer-focused keyboards are even going for 8000Hz these days.
Getting rid of multiplexing is a result of having a high number of IO pins: an MCU like the STM32F429BE also has enough pin for direct-attach switches. Ghosting hasn't been an issue for ages, even with a traditional keyboard matrix it's just a matter of adding per-key diodes.
In theory it has a sliiightly lower latency than an MCU-based keyboard using the same USB interface, but I doubt the difference is big enough to even be measurable in real-world scenarios. We're talking about, at most, a few thousand cycles of an MCU running at a few hundred megahertz - and that's only relevant when you press the key right before a polling request arrives. That's the difference between an average input latency of 0.500 ms and 0.505 ms. Meanwhile on the output side, your fancy 480Hz monitor is only showing one frame every 2.1 milliseconds...
The optimization here is somewhat theoretically specially when you take into account the USB bottleneck as well as real-world Human reaction times and Perception.
But it appears from the project description that the author's motivation was indeed performance (irrespective of merit). A neat VHDL + HW project nevertheless.
In that light, it's odd that they specify a polling rate at all, since they use direct-attached key pins linked to an 48MHz clock. There is no grid/matrix sensing period, which is usually what is meant by polling rate. And the claimed value of 1kHz is doubly weird since the debouncing logic uses a period of 5ms, which means they can at most mimic a 200Hz polling rate:
entity Debouncer is
generic (
FILTER_DURATION: delay_length := 5 ms
);
edit: looked up what the typical bounce time is for a keyboard switch, and 5ms seems to be pretty standard. It's also the default that QMK uses. It seems quite excessive to me, I'd have expected bouncing times to be closer to tens of microseconds than multiple milliseconds.
They had a spin off SMELLDECT GmbH which sells a kit but not exactly a order from DigiKey thing. I imagine you will need to send an RFQ and go through the motions with their sales team.
reply