maximusdrex

Yeah, I read that note and stopped looking further. I was hoping that maybe the hardware-specific code was in a different project and just wanted to be nice in case. I just don’t get the point of making AI slop out of something like a toy RTOS, which is inherently a learning project more than anything else. There’s nothing even fun about doing it if you won’t even try to get it to run on an STM32 or something.

Looks like a fun project, but I’m curious what you actually tested on. There’s real numbers for estimated context switch timing, and you mentioned implementing context switching, but I can’t find any actual implementations of the context switching routine in your code. You don’t need to do this yourself, but it’s weird to talk about it if you haven’t.

> It is precisely to avoid running Linux and the "wealth of drivers".

Why not? I understand not wanting to deal with unnecessary complexity as a hobbyist, but you'll find yourself creating far more complexity trying to implement all of this yourself (and vendors certainly don't want to support you in this). Secondly, I think the number of customers for chip vendors who are uncomfortable with setting up an embedded Linux environment, but perfectly confident in routing DDR and PCIe signals is approximately 0.

> What I am trying to point out is that there is a huge market gap.

> i.MX8 is not realtime and the support for running bare metal code is very much non existent.

This isn't quite true and is what I'm trying to get at. Most of these embedded SoCs contain a Cortex-M and a Cortex-A (not all but there are quite a lot). High performance DRAM, external PCIe devices, and large internal caches are fantastic for compute performance but most of the things you want to do with a PCIe device (networking, asynchronous compute) don't require cycle-accurate determinism. Generally there isn't much you need to do with such stringent timing requirements, so you can offload that work to secondary Cortex-M33 core with a shared memory interface to the main core and get the best of both worlds.

I see so many systems trying to take advantage of the impressive compute power of modern MCUs (which is really cool!) but often end up just re-inventing the cooperative multitasking OS, but worse.

Calling this "hardware-based security" is somewhere between disingenuous and dangerously naive. Hardware-based security normally implies hardware with a dedicated secure element with cryptographic identities which are impossible to spoof. Security based on USB serial numbers can be defeated by any adversarial device claiming to use the same serial device as a device you have registered. There's no secure signatures or anything backing a USB serial number.

This is so, so much worse than that though, because the code doesn't even do what the AI-hallucinated documentation describes, because as far as I can tell the actual "serial number" is returned by the following line: Ok(Some(format!("{:?}", device.product_id()))) So the "serial number" is actually the USB product id, which generally corresponds to the "model", not even unique per-device. So you didn't even test this with multiple identical flash drives.

I actually agree with that completely. I just want it to be clear that this is a conscious business decision that apple is making and not the result of technical challenges. I think the distinction is important because I don’t love the tradeoffs apple chose to make, but I continue to buy an iPhone because at the end of the day my phone is mostly about being social and it’s a frustrating experience trying to communicate with friends and family who all have iPhones which make interoperability with other messaging ecosystems frustrating. If iPhone RCS support worked as well as native messaging I’d switch to an android in a heartbeat.

Again there is no technical rigor behind these notions. Video providers didn’t like the idea of untrusted HDMI devices scraping video from DRM protected content so they came up with HDCP, which allows anyone to develop and certify solutions as trusted software/hardware. There’s no reason apple can’t do something similar, it doesn’t have to be completely open vs. completely closed. There are always alternative solutions to the problems that people think apple’s walled garden approach is solving; which makes it clear what the real purpose is.

I truly don’t understand how these types of comments keep appearing under any discussion of apple’s blatantly anti-competitive behavior with messages. This doesn’t even make sense on technical grounds; it would be trivial to require such message passing to be encrypted/signed securely if that’s your real concern. After all, the Apple Watch does exist and does have these capabilities, so it’s clearly possible to do it and maintain the “security boundaries” you’re so concerned with. Then every single one of these comments inevitably turn towards spam messages which no longer even makes sense since iMessage has been filled with spam lately. I really don’t see how allowing smartwatch manufacturers to also interface with iMessage (in the same way Apple Watches do) will inevitably increase spam on the platform which can’t be detected/mitigated in other ways. I’d love to see some technically rigorous explanation for why apple can’t support any third-party anything instead of hand wringing about “security” with no real explanation but I have a feeling I’ll be waiting a long time.

While I agree with the ultimate conclusion of the article, that FAA regulations need to be modernized for commercial use of sUAS systems, it completely fails to analyze any of the other relevant dynamics facing the American drone industry. There are a plethora of American companies building drones for commercial and/or defense purposes (I work at one) but this article reads like the author knows only about the most publicized one and another company they heard about on a podcast. The article would benefit from an understanding of the Probably the most major blocker for the authors dreams of swarms of millions of American military drones is the following: jet engines and rocket motors can be produced in the US profitably, the American economy just isn’t set up to build drones motors, props, etc. in an economically efficient manner. Because of this, the cost-optimized drones developed for the commercial sector will never be acceptable for the us military. Secondly, the author seems to think that self-organized systems are a brand new innovation and would trivially port to a battlefield environment. However, these techniques rely on 5G connectivity and gps, whereas military sUAS systems need GPS-denied autonomy and the ability to communicate in a heavily jammed environment.

I’d love to see some data supporting this argument because I’ve heard it over and over from people all over the political spectrum the past few years but it just doesn’t line up with any data. You act like they’re quoting abstract numbers which are meaningless compared to people’s “lived experience” but unemployment is a large part of people’s experience. Furthermore, inflation adjusted wages are up (with the highest gains in the lowest 50% of earners). If these statistics aren’t fully capturing people’s experiences, I’m sure every economist in the world would love to know what metrics are better. Instead it seems perceptions about the state of the economy have become more tightly coupled to the media atmosphere than anything measurable.

What a disaster for ARM. Qualcomm building out new chips targeting the pc market should have been a victory lap for ARM, not the source of a legal battle with their largest customer. Now potential customers might be a little more wary of ARMs licensing practices compared to the free RISC-V ISA.

Your understanding is not correct. Chevron deference never meant agencies can just make up and pass law; it was a legal doctrine which merely stated that in places where the law is ambiguous (say a law declares water must be clean of pollutants, or bans pistol braces) that courts should look at any guidance from relevant agencies for guidance, since supposedly they should know more about the subject than the courts. It never allowed agencies to circumvent congress or prevented congress from further clarifying law. For example, the DEA doesn’t have the power to schedule drugs due to chevron, Congress includes provisions for the AG to reschedule drugs, which the AG historically has delegated to the DEA, the point being this was a power explicitly granted by congress. While it may sound nice to you right now that the Supreme Court did away with chevron due to your gripes with the ATF, now the definitions of machine guns or pistols or anything else are up to the whims of any judge in any jurisdiction, which could be better or, given that judges likely have even less knowledge of the subject than the ATF, probably worse and more inconsistent.

Everyone else is missing the point here. SMIC (China’s main semi fab) isn’t the company manufacturing these chips. They haven’t broken into anything close to 3nm-class chips yet. This just means that TSMC is going to manufacture a 3nm chip for Xiaomi. The important part for China here is this proves that they can design modern chips, not they necessarily have the manufacturing capability yet.

Clearly, I'm surprised there isn't a spam filter that detects this obvious attack.

I bought one of the M5Stack's devices expecting it would work out of the box with my ESP-IDF code, I was quite disappointed to realize that I had to adapt their code myself. I'm hopeful that this merger encourages M5Stack to build their software into the ESP-IDF framework.