jack12

There's an update about a hearing yesterday that has more details about the server setup and what the concerns on both sides were: https://current.org/2026/08/judge-sets-framework-for-nine-pb...

With the stuff about "corruption" and losing the data if the server is shut down, I wonder if part of the concern is about losing in-memory decryption keys.

> POWER-powered low cost SOCs akin to Arduino

More in the range of the arduino than the pi, you could get a Colorlight 5A-75b for ~$15 on AliExpress and reprogram its FPGA to run an OpenPOWER core. It's a board meant for driving LED panels, but it has a Lattice ECP5-25F FPGA with a JTAG header easily accessible plus dual gigabit ethernet MACs and 4MB of SDRAM. The downside is all the rest of the IO is stuck behind one-way buffers since it's only designed to push data out to 5V LED panels. But it's been well reverse-engineered by the chubby75 project, the FPGA is well-supported by the open-source yosys+nextpnr FPGA toolchain, it's supported by the litex SoC builder (which also includes microwatt core support, though maybe not colorlight+microwatt?), and it looks like some have had success getting OpenPOWER cores to boot on it: https://twitter.com/antonblanchard/status/123177893988802969...

For some value of "capable": https://github.com/torvalds/linux/blob/master/arch/riscv/con...

It hadn't occurred to me that PATA/IDE could be so simple to speak. Now I'm excited about the possibility of being able to dump a 25 or 30-year-old IDE drive I have that my USB adapter doesn't want to talk to (via another SATA-to-IDE adapter).

The README says this option relies on the kernel's "ATA framework" (presumably for the protocol/non-interfacing logic?). Is that part of the "talking to a drive" stack very much to have to implement? Or do you know of any existing code for microcontrollers?

> are open hardware.

Are they? I only see PDFs of schematics on their website, and no claims of being open. Of course with a breakout board like that there isn't really any secret sauce in the "source", just the expertise, trials and errors, and grunt work of layout.

At that same level of "schematics available" dev boards, another option for a XC7A35T and 256MB DDR3 are the ones on aliexpress for $50, https://github.com/ChinaQMTECH/QM_XC7A35T_DDR3, though I don't think they have the transceiver pins exposed and are bring-your-own-jtag-programmer. All the IO is via 0.1" headers, which are going to be lower integrity but a LOT easier and cheaper to use.

There's also a $99 XC7A100T board, https://github.com/ChinaQMTECH/QM_XC7A100T_WUKONG_BOARD, with 256MB DDR3, a gigabit ethernet phy, hdmi port, 0.1" headers and PMOD headers, and with some transceiver pins exposed.

It sounds like the solution was always left as an exercise for the reader in the day-to-day dealings of the group even among the members: "Each participating country was supposed to perform its own decryptions. This is common practice in the intelligence community in order to prevent being fed cooked-up information." and "The cryptanalytical part of the cooperation involved exchanges of algorithms used in various (deliberately weakened) cryptographic devices used by target countries. It was then left up to the Maximator participants themselves to find out how to exploit weaknesses in the algorithms of these devices. Such exploitations are also called ‘solutions’."

Anyone getting an air quality monitor specifically because of an interest in CO2 needs to be a bit wary, a lot of them claim to have a CO2 sensor but are actually just predicting CO2 levels based on other sensors designed to measure human occupancy. CO2 sensors are/were very popular for HVAC systems to use as a proxy reading of human occupancy levels and general air quality to meet air quality requirements. Now more modern (cheaper) air quality sensors are available which measure a mix of VOCs exhaled by people instead of CO2 but have an output mode that emulates the reading from a CO2 sensor at a similar occupancy level so that HVAC systems wouldn't have to redesign their control systems / formulas, usually marketed as "equivalent CO2" (or eCO2) readings.

Because they're called eCO2 sensors while being cheaper and lower power than real CO2 sensors, many air quality monitors have been using them and then surfacing their readings as "CO2 levels" under the mistaken belief that they can use the sensor to measure CO2. But it won't measure environmental CO2 at all, just predict the amount of CO2 the humans in a room would typically generate. Which is all you need for air quality monitoring, but just be aware you're not actually measuring CO2 if that's what you're curious about.

There are monitors with real CO2 sensors, but you'll want to look for a teardown to see what sensor is actually being used before you purchase. The Awair 2 seems to have a real NDIR CO2 sensor (Telaire T6703), for example: https://wiki.liutyi.info/display/CO2/Awair+2+inside#Awair2in...

Seems like there's a bit of room for confusion in the stuff surrounding the two. Would you guess "PYNQ - Python Productivity for ZYNQ" is a set of python bindings for this Zynq's API or for the FPGA? Especially seems like it could be related to this startup with its site being at pynq.io, at least until you see the photos of the pink PCBs :)

Yeah, a 16K Spartan 6, 64MBytes of DDR3 RAM, and an FX2LP USB High-Speed controller is a pretty terrific repurposed FPGA dev board in the vein of the chubby75 or panologic, even if the high-speed ADC turns out to have too many limitations / too weird signal conditioning (i.e. is too VGA-focused) to be very useful (but VGA probably at least means a pair of I2C pins is exposed on the DSUB-15, right?). Considering the FX2LP is already wired up to load the bitstream to the FPGA, and expects to on every power-up, that's a huge bonus for a dev board. Even if the binary blob of FX2LP firmware provided in the manufacturer's drivers does checksums, signature checks, etc. to make changing the bitstream data difficult, it would be pretty simple to write a new firmware to allow uploading of any custom bitstream (see: fx2lib), since it's such a well-known and widely-hacked chip -- maybe you can even manage to trick Xilin's ISE into believing it's a real Xilinx "USB Platform Cable" (FPGA JTAG programmer) since at least some of them use an FX2 for their USB interface. With a generic bitstream uploader utility for the FX2 you wouldn't even need to deal with any hardware modifications or even need to buy and connect a JTAG programmer if you were just starting out. And with everything being uploaded on every reset of the devboard, you don't have to worry about bricking anything either, since you just power-cycle the devboard to bring the programmer AND FPGA back to their default waiting-for-firmware/"rescue" mode.

But while the article says he got a lot of them (at least 3 from the photo) for $25 total, it looks like they're more typically ~$50+S/H each on ebay, which is less exciting.

The same company seems to have moved on to 'av.io'-branded USB3 devices now, which from a quick glance/binwalk of the downloadable firmware package (inspired by this article) appears to have FX3 USB Super-Speed controllers, and Spartan FPGAs. But it's designed to store the FX3 firmware and FPGA bitstream on the device itself (to allow it to boot up as a UVC webcam with no drivers required on the host, like this article was hoping would be the case for the older device), so it would require a bit more reverse engineering to figure out how to kick the FX3 into firmware update mode to replace the FX3 firmware with a custom bitstream uploader. But it's a ton more expensive, and who knows what generation and size of FPGA or how much and what sort of memory it would have.

There's not a lot of reason to stick with micro USB even for hobbyist projects. You can get USB-C "charging" receptacles that only breakout 6 contacts in any combination of SMD/PTH on the contacts and the mounting pins. Even in tiny quantities they're less than $0.10/ea on aliexpress. If you just want 5V you don't need to deal with PD, just stick 5K1 resistors to GND on each of the CC1 and CC2 pins (don't cheap out like the Raspberry Pi4 did and tie the CC pins together to save on a second resistor, or you'll end up with the same problems as they did).

They should be just as easy to route and hand-solder and the footprint should be just as compatible with low-end pcb services as any micro-usb connector, and it will allow you to use a better USB-C cable as your power connector.

If you also want the USB2 D+/D- lines broken out you can get USB-C connectors with 16-contact pinouts (everything but the SS pins).

I know the concern is about parcels specifically, but doesn't this agreement also cover all international mail?

Is the US going to be essentially cut off from international mail delivery until the USPS can negotiate pricing and a contract with each individual country's postal service (i.e., not in place over Christmas)?

Hmm, that $100K stretch goal is pretty much required for me to be able to use this instead of a yubikey. I wonder how likely it is to be met?

The whole "we have to avoid GPL3 code so we're able to keep 'normal' people 'safe'" angle feels pretty icky. But I know lots of people believe in the whole 'trusted' movement. And I suppose having a 'hacker' version /available/ is at least a bit better than what yubico offers.

The Pocket Operators are just a generic DAC+amp chip, the Cirrus CS42L52. The DAC is driven by a 48MHz MCU with just 32K of RAM. If it were purely a question of technical / hardware capabilities it would all fit into an app ten times over.

http://hackingthepo.weebly.com/ has a terrifically detailed teardown of a PO-16. Or SiLabs (the MCU's manufacturer) did a marketing video / interview with one of the Pocket Operator's designers about the hardware design: https://www.youtube.com/watch?v=ZjrOnlMkJHU

As your parent says, the Pi 4 doesn't support USB or network booting yet. From your link:

> Support for these additional bootmodes will be added in the future via optional bootloader updates

I believe they need to write (bootloader) drivers for the PCIe host and for the new USB3 chip before USB boot can be supported by the bootloader, while netboot requires a driver for the new gigabit ethernet core.

Nice, I've subscribed to the RSS feed. A little weird to see such old software versions being used in an article with 'modern' in its title, but I suppose you have to pick a point that's 'modern enough' to have something the majority of people can follow along with when they're all running old software too.

I wish it covered error handling a bit more than just 'exit(EXIT_FAILURE)'. FreeType must have some sort of error code or error message function.

But that's all just minor nitpicking. I like the simple and direct walkthrough of the FreeType API (and promising to include friends from the ecosystem in the future). I hope the blog series will continue!

> but to my knowledge no browser implements it

Firefox does, though I don't know how much they check beyond just the dNSName constraints. Here's the unit test making sure it stays working: https://github.com/mozilla/gecko-dev/blob/b8157dfaafc42deb3b...

My understanding is that A2 cards are generally slower than A1 cards IF you don't have host-side support for managing the volatile-RAM caching that A2 requires.

So if the Pi 4 only allows you to run in A1 mode anyway, you're better off buying the A1 card and both saving money and getting a faster card. I don't know if that lack of support is true of the Pi 4, but it does seem to be true of most other SBCs according to https://github.com/ThomasKaiser/Knowledge/blob/master/articl...

> I'm kind of amazed he was able to fly a plane like that at 50 hours. A turbo-charged engine requires an extra certification step right?

The wikipedia page for the Beechcraft Bonanza says: "The NTSB investigation revealed Wozniak did not have a "high performance" endorsement (making him legally unqualified to operate the airplane)" and links to https://web.archive.org/web/20121019022620/http://www.ntsb.g...

The credits at the end of the post thank folks who worked on the CYW43455 integration, which matchs up with the raspberry expectation of being a (former) Broadcom part.

I don't understand the change. If I understand the history correctly, previously commercial usage restrictions only applied to official binaries downloaded from their site, and now:

>Going forward, only commercial use of ... the download page ... requires a subscription

So now you're allowed to commercially use the official binaries without buying a license, but you're not allowed to acquire them without that license? I don't really understand how that's a distinction with any difference.

Is the expectation that (non-commercial) 3rd-parties will mirror the official binaries, and that's why it's a useful change?

Probably because they don't care if it's made by STMicroelectronics or by GigaDevice. Most likely it is made by GigaDevice, but maybe they thought calling it a GD32F103C8T6 would be meaningless to many people and calling it an STM32F103 would be dishonest and so this was a compromise. Or maybe they found a third source that would have an even less recognized name.

How did things work back in the day of (official) second-sourcing? Did you just refer to a MC68000 even if you meant generically any of MC68000/HD68000/MK68000/etc? I guess it helped that it had such a unique model number and any of them could just be referred to as a 68000. I guess calling this a 32F103 would be the equivalent in this case.

Only after you've agreed to it does it popup the text "This development board can be only used for prototyping, it cannot be built into a product for commercial distribution. It cannot be re-sold or used as part of a production environment."

I suspect adding anything about restrictions was a last-minute job for Seeed, and it's probably not something given too much effort on their part. Realistically, an $85 devboard isn't going to end up being built into production items. And they're probably going to be a low enough quantity item for Seeed that they can manually look into any instances where someone has ordered more than 3 or 4 and just stop sending any more to them if it really rises up to being enough of a problem for Microsoft to complain.

It requires you to click a checkmark box for "I agree to the restrictions" to add it to your cart. I suppose that's what they consider to be restricting your usage to their approved use cases, not copyright.

I think the blog post is saying that, especially in the quote that started this thread. The post portrays ad-blocking browser extensions as not worth the risk, discussing both the questionable value of blocking all ads and also the possible risk of the extension being sold to a malware creator. It then presents Pi-hole as a safe alternative to browser-based blockers.

[1] says there was no headset, though who knows where they're getting that information from. The photos in the article do kind of look like the pilot is bare-headed.

1: http://www.criticalpast.com/video/65675069507_evacuation-of-...

https://www.republicservices.com/ is a site with a non-EV Symantec-branded certificate from August 2017 and it still works in Chrome 69 (and is blocked in Chrome 70 with a NET::ERR_CERT_SYMANTEC_LEGACY error).

www.McDonalds.com is another site with a non-EV certificate that will be blocked by Chrome 70, albeit with the GeoTrust brand instead of Symantec directly. Surely McDonalds has a large enough IT division to have noticed and updated by now if Chrome had been blocking their site since April.

https://youtu.be/lQZzm9z8g_U?t=1565 seems to be the same talk delivered at another instance of this conference. He does claim one statistic that an unnamed "top 3" cloud provider told him that fewer than 10% of their customers install company-based kernels and over 90% install community-based kernels like debian or kernel.org code.

He is not limiting "the majority" to just Debian, though. He is comparing installs of distributions backed by companies (like Red Hat+Canonical+SuSE) as "the minority" vs. every possible non-corporate-backed distribution or source.

Lithium ion batteries are another example of this. Used batteries 're-wrapped' in counterfeit labeling to look like some particular brand/model are probably more common than genuine products on Amazon.

More often than not, buying batteries through Amazon is literally paying someone to ship their e-waste to you.

I read it as meaning Adafruit-branded products purchased via Amazon from 3rd parties.

With the software-only approach (e.g. usbmon), the interface is even more like Wireshark :) https://wiki.wireshark.org/CaptureSetup/USB