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.

ST seems to consistently put out faster chips [1]. I think the better question is why bother though? The real reason to use a Cortex-M is determinism in hard real-time systems. I'm sure DDR3 and PCIe would be cool in an MCU and people would certainly make some interesting things with it, but at that point you either aren't making a hard real-time system and would benefit greatly from an MPU, allowing you to run Linux and benefit from the wealth of drivers available for these interfaces, or your real-time deadlines are so tight an FPGA would be a better choice. The real advantage of the Cortex-Ms is that they can be manufactured on ancient process nodes for next to nothing. The moment you don't care about that, why not upgrade to an i.MX8?

[1] https://www.st.com/content/st_com/en/campaigns/stm32v8-high-...

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.

For what it's worth I'm not either and absolutely agree with your point, it just felt like that was the more important argument but not the one people were engaging with.

It feels like every comment on this article didn’t read past the first paragraph. Every comment I see is talking about how they likely barely made any money on the transition once all costs are factored in, but they explicitly stated a critical business rationale behind the move that remains true regardless of how much money it cost them to transition. Since they needed to function even when AWS is down, it made sense for them to transition even if it cost them more. This may increase the cost of running their service (though probably not) but it could made it more reliable, and therefore a better solution, making them more down the line.

I find your reaction intriguing since I had nearly the opposite reaction. Especially when it comes to the second piece I had little to critique about it technically (maybe a little from a structural standpoint but not as much grammatically), but I found it incredibly dull due to its complete lack of any real point. With your musical analogy, it felt to me like a piece where all of the instruments were played perfectly, but failed to make a song I actually would care to listen to again.

> But they will be good helpers for people like me, who can get suggestions, improvements and illustrations just for the price of my 4090 and time to tinker with models.

This I agree with; for someone who may not be as gifted a writer, but still has something interesting to say, generative models could help with that. I just hope that people don’t lean on these models for generating ideas because if that story was any indication, that’ll just lead to a proliferation of boring, soulless works.

Oh absolutely, I agree. I just wanted to make certain it was clear that it isn’t as simple as classifying images as words.

It’s not really, ASL is it’s own distinct language from English, like most sign languages. ASL is most closely related to French Sign Language, which still isn’t anything related to French and has its own linguistic features and independent development. Because of this translating ASL to English (or any other language) is no easier than translating to or from any other spoken language.

> I just can't express my architecture in such an abstract form whose logic-level simulations (without considering delays, area, routing, power and clock rate) will give a clear indication of win.

Why not? There are plenty of open source RISC-V soft CPUs available for you to run on the same FPGA to benchmark against. If its the architecture which is special it doesn't matter if it competes against top of the line chips, just that it beats out everything comparable. You don't need to prove that your design will beat out a similarly designed chip on advanced silicon, just that your design implemented in the slow FPGA is better at something (not necessarily everything) than a CPU trying to emulate the same behavior. Having the PDKs won't help you much either, since on top of that it will take hundreds of thousands of dollars (minimum) in software costs and teams of people to help fine-tune and simulate such a large design. Doing this without the intention to eventually tape-out that design is a massive waste of resources.

I understand where you're coming from but the point of getting access to those PDKs isn't for rapid prototyping. The value proposition of your design must already be clear before beginning to design for a specific process. If you can't prove that your design has significant advantages that no chip in the next few years can possibly compete with, then there's just no point in attempting to design, synthesize, and simulate it on advanced nodes. That process is a significant investment in itself and if you're unsure enough about the potential benefits that you need to know exactly what it would look like in reality, then it's just too risky to spend the years it will take to get a working chip which may already be outclassed by the time your first chips come off of the line.

> Sure, but I specifically want to research the optimal intermediate point between classical CPU architectures and classical FPGA architectures.

That sounds cool, but this makes it sound like you're a really long way off from considering the specific characteristics of a given process node. Focus on designing an architecture which does something better than current designs can possibly do, such that the value of implementing it in a chip will be unquestionable.

General purpose processors and FPGAs are entirely different and share very few components or architectural characteristics.

Setting that aside, if you have some revolutionary design for an architecture, that should already be abundantly clear from emulating your designs on FPGA. If you aren’t completely sure (and have evidence to prove) that your design is significantly better than anything that has been made before, you’re not at the stage where you should be thinking about manufacturing a chip with modern hardware. As was said elsewhere, making a chip is a phenomenally capital intense process so if you’re planning on competing with any existing hardware you’re going to need to justify that investment with radical gains, not incremental improvements. If you have an idea which you think could speed up existing hardware, your best bet is to work with/sell IP to companies which already design that hardware since it’s just not worth the investment needed to start a whole new chip company for a potentially 10% better CPU/FPGA.

Yea that's my mistake, but not really the point I was trying to make.

Not necessarily, the issue here isn't that training on public code should be illegal, it's merely that the models trained on such data should be considered derivative works under the licenses which the code is released under. GPL code must also be released under GPL, so Copilot must not charge users to use a model that is trained on and regurgitates GPL code.

> We should be striving to make copyright less draconian, not more. Agreed, and I'm not sure why you think forcing GPT and Copilot to respect open licenses will make them illegal instead of more open.