fstokesman

Author here. CNLohr already did it better than I could 10+ years ago: https://www.youtube.com/watch?v=mwcvElQS-hM

Author here - the reason is pretty underwhelming: These are the parts I had on hand when I decided to start on the project. Using a chip with a builtin Ethernet peripheral would definitely make more sense (though I'd be trading any complexity of configuring the W5100 for the complexity of configuring STs peripheral). The networking code already abstract the actual chip itself into a driver interface (think read/write/ioctl), so porting the code would be pretty straightforward.

I'll look into the STM32F407 for the main series. Thanks

If you can only capture 60FPS, you cannot accurate measure a signal of 40Hz, since it is below the Nyquist frequency. (I know you mentioned the slow-mo camera which probably does have the bandwidth).

This is a very first-world opinion. Low-end (second hand) smartphones are some of the only available computing devices available for a large part of the world.

> There's something more constricting about there being one function to bootstrap everything than there is about one file.

The trickiest thing is that main() is not even the bootstrap function. The actual entry point of a program is usually generated by libc, and is called generally called _start (though it can be anything).

> ...remote biometric identification systems in publicly accessible spaces, biometric categorisation systems (e.g. categorizing by gender, race, ethnicity, citizenship status, religion, political orientation) and the use of AI for predictive policing.

> AI systems which can influence voters in political campaigns and by use of suggestion systems on very large platforms...

> New transparency and risk assessment requirements for providers of (generative) foundation models like GTP.

> Clarified exemptions for research.

Putting these kinds of restrictions in place is absolutely a good thing. While they might not get everything right, this is a step in the right direction. Our laws and understanding as a society has been lagging behind technological development for decades now. That fact has enabled a large amount of exploitation to take place, which has (in the last decade especially) had a large hand in massively undermining our democracies.

This is the most use that board has and would have gotten in the last 10+ years. I like to think it laying down its FTDI chip for a greater cause was an honour for it.

Indeed - I know I could have also popped out the DIP micro on the board and used it directly, but I choose not to for two reasons:

1. Its so much bulkier, and I wanted something that was the same form factor as my old unit 2. It seemed way more fun to do things this way, and I was pretty sure I could do the whole operation in less than an hour

Totally fair point. One of the videos I'm going to get around to making on my channel at some stage is a UART transceiver on an FPGA. Definitely not the "easier in a pinch" I was originally going for, but hey, if you've got the hardware hanging around!

You're absolutely right, I don't know why I had attributed the name to the full duplex nature. And of course, there is also USART, where you can have a separate clock line, which allows you to omit the start and stop bits too. At that point, you're essentially turning your UART into a single connection SPI bus.

She* - this is Julia Evans blog.

People can blog about whatever they want. I think people on HN and other platforms often forget: Just because the content ended up here, doesn't mean it was written for here.

I think the authors point is that dd is a specialised command, and for most common tasks (where the precise details don't matter), it's often not the best tool for the job. I didn't come away with the impression that you should never use it.

I can't think of any type of job that is both vilified AND one that you could take on the cusp of destitution.

And at least for me personally, setting the example to my kids of integrity being one of the most important characteristics you can develop, is a top priority. Taking a position in an evil industry doesn't top that.

Heard about a great floating point implementation bug just today. When nintendo released Super Mario 64 for the Wii virtual console, they essentially just made their own emulator that plays a single ROM. The emulator is pretty accurate, though they made a mistake when implementing floating point operation rounding: All operations end up rounding upwards to the next floating point number (as opposed to alternating, depending on the result). A consequence of this was that some of the moving platforms in the game that had a periodic up/down pattern would slowly (over the course of literal days) creep upwards. Ended up being exploited in a speedrun category where the player attempts to press the A button as little as possible.

If you code to a standard, this is less of a problem. If you implement AES in a way that produces a different output to someone elses implementation, then you by definition haven't implemented AES.

From a binary trust perspective, this is maybe a good way of ensuring that you're running the code you really think you are - but really you just kick the can down the road. You didn't build the hardware, and thus you don't know it's doing with your data once the instructions start executing. Is it storing them off to a side-buffer? Is the CPU detecting AES-like behaviour and triggering some surreptitious path? Who knows. This is where projects like precursor (https://player.vimeo.com/video/677854277?h=8ad58eece9) are really interesting. To be really, super sure that your code is running as expected, you have to build the world from the ground up.

I put the warnings in the title and the first few paragraphs, but also implicitly at the end, where the reader checks the comments to see a great deal of reiterations of the message

If someone copy-pastes this code in spite of the warnings, I consider them to be very much in own-risk territory. Sucks if they end up getting burned, but I don't consider myself responsible.