They already recovered a ship from that one time they accidentally landed one in the ocean. SpaceX got to have a lot of heatshield endurance data by now.
Unironically a gift. On your own home network, the one most likely to MITM you is yourself. And eMudhra's fuckup allows for a nice attack on a few devices you'd otherwise have to disassemble to pwn.
Yeah, I have a couple cheap Tuya devices you can't necessarily re-assemble easily once disassembled (IoT light bulbs, outlets that are plastic welded/glued). Pretty sure they use mqtt over tls
The fact that made up issues like water use or waste heat, complete with faked research papers, are being used to push the issue? It does make one suspicious.
There is a lot of the broader anti-AI sentiment, so it's possible that the entire thing is just "people want to hear AI bad, so there's market in saying AI bad" - with media and politicians both recognizing the opportunity. But it wouldn't surprise me at all if some of it turned out to be coordinated influence campaigns.
thats what it kinda feels like to me. My intuition tells me the average non tech person has a very worried view of the future due to AI-- I mean, what industry out there says their industry has a non zero chance of ending life as we know it! So that in mind, people look for reasons to shore up their concerns. Datacenters = AI, therefore they are bad for all these reasons-- Reasons which could be applied to many industries.
I agree with all your points. As with the rest of the anti-AI movement, I think the key is in the likely consequences. Slowing down the buildout and regulating AI in the West won't affect it elsewhere. At best it's tilting at windmills, so I think it's reasonable to suspect the worst.
Not a great comparison because people lose and break charging cables all the time, so there's a much better profit angle there.
I suppose it's possible to lose Switch Docks, and some must break, but it's such a rare thing to happen that it doesn't really justify the razor-and-blades model.
Usually the docks outlast the tablet itself (this has happened to me once, so I actually have a spare Switch 1 dock)
re "profit angle"... our Switch 1 stopped working last week, I assumed a charging port failure. No amount of trying to hard reset or leave on charge for days could nudge the little red battery off empty. I have to assume it's 5 years old at this point. So we sent it back to Nintendo to find out if it's salvageable at all. They told us today that it's the main board, and they'll replace it under warranty (what warranty?!) and we'll have it back Monday.
They don't seem to be one of those companies that's trying to squeeze maximal money out of their customers at every opportunity.
Every USB cable that can carry more than 3A, or that can signal above the baseline 480mbps, must have the e-marker. That isn't weird in any way. It's how USB works.
GP is talking about a proprietary Apple thing that just marked that the manufacturer paid the MFi royalty, not the thing that standard USB uses for legitimate reasons.
> Apple used to e-mark every single charging cable, and even ban unauthorized ones
Do you have information on what “ban unauthorized ones” means? Are you talking about the pre-USB-C days with lightning or something? I’m not aware of any restriction besides perhaps max charge speed on their USB-C implementation if you used a mediocre cable.
you seem new to the game, then. for years, and years, iPhone software (firmware) upgrades would kill 3rd party lightning cables. obviously not USB-C. Third party iPod cables were very hit and miss, too.
I would appreciate it if you don't assume I'm "new". We're talking in the context of USB-C hence the question. I'm well aware of the history with Lightning and 30-pin cables.
> Third party iPod cables were very hit and miss, too.
That was probably because the cables were crap, not because Apple was doing anything to disable them. As far as I'm aware, the iPod 30-pin connector never did any sort of handshaking.
Yep. His affairs cast a long shadow over his push for "restricting AI accelerators is bad, we should just sell all the GPUs we want to China".
Was it driven by this, as opposed to what everyone thought at the time: pure shortsighted profit-seeking? We don't know. But no one likes that it's even a thing to be concerned about.
Right lol, i didn't know we'd built a machine that was capable of getting critical level security deterministically correct. That's not me, at least...
The truth is that those are just niche items. Having a need for both a Linux-grade CPU and a real time MCU-like core is not that common. It tends to show up in projects too advanced for most to attempt.
That's untrue. Almost all the products I worked with in my last company had such architecture - which we leveraged (this was Ag industry). It's very easy to work as they have shared memory to talk to each other.
That's at least a tier more advanced than mainstream.
And if by "very easy to work" you mean "just allocate a shared memory block and put a mailbox in there for the Linux userspace and the RT MCU to talk to each other", you may have inflated expectations of what an average developer using an SBC can easily do. It's "very easy" in the same way rolling your own PCBs or writing your own drivers is very easy. Seasoned developers do it without thinking twice, and then stand dumbstruck when they see entry level developers avoid that like the plague.
Not like we're lacking for the offerings. Plenty of modern SoCs have MCU-like real time cores in them - intended for low power operation, real time control, or both. Even the mainstream RPi 5 boards ship spare PIO and MCU cores - in the RP1 chip. The vendor just couldn't be bothered to document that.
There’s whole sectors of industrial and automotive using these AMP SoMs. And relative to these RPi only recently began providing options that you could design into an embedded product at all. Their FAE and supply presence is way behind.
By "mainstream" I mean "the bulk of development work done", not "the bulk of units shipped".
The boards that people reach for when they roll their first projects, the hardware that ends up in early prototypes and one-off devices, the hardware that gets targeted by open source projects. The chips that return more than a "databrief" 8 pages long and a single page on a vendor site inviting you to visit the snake pit with "contact sales for more information". The boards you can actually buy with a fixed price tag and a delivery to door, and can find writeups on how to use them for specific things.
If you know what "FAE" is, let alone can get into a meeting with one, you're deep in the trenches, and are pretty much expected to wrangle an extremely poorly documented MCU core that happens to be shipped in a SoC as an afterthought into submission.
There's multiple embedded companies, NXP i.MX, TI AM355x, STMicro STM32MP1 and MP2, Xilinx Zynq... that offer either Linux-CPU + realtime MCU, or Linux-CPU + FPGA. If we include Rasp. Pi PIO, there's even more companies offering main processor + coprocessor (including ESP32).
Those are just the ones off the top of my head. I'm sure there's more if I used Google to search. And of those companies, there's *multiple* lines of chips that offer these capabilities.
Its... pretty mainstream in the embedded world. The fact is that Linux is very bad for realtime, so adding a non-Linux coprocessor is one of the easiest ways to solve the problem. Run Linux for "regular" code, and then run the hard-realtime code on a dedicated chip (either Cortex M4 or some other MCU... or maybe a Cortex-R(something)). Or in the case of Xilinx, run the realtime stuff in FPGA-land.
Alternatively, you spend a ton of money on an OS that's well suited for hard-realtime (ex: VxWorks or something), but that also requires a processor with some guarantees (usually L1-like cache that's reserved by the programmer, some "always active" hard-realtime memory). This is more difficult in practice compared to just having a 2nd MCU or FPGA handle the realtime tasks though in a coprocessor like arrangement.
-------
I dunno what you're arguing for. Are you trying to say that the world of Linux capable core + Realtime core is somehow... niche?
The parts are there, but the support and the usage? Very much not. It took years for vendors to even start shipping remoteproc support in some of the parts.
Calling it niche is overlooking "product" needs. People have been needing a smaller MCU for doing anything meaningful with a bigger SoC. This is due to complex power sequencing for powering the SoC + desire for realtime IO on these "products". Offering combined solution makes it easier.
--
> support
You are 100% right on this aspect. AMP based SoCs fall in weird range - some with great documentation, better isolation, and software support. While others basically feel like rotting in hell.
--
On that note, I picked STM32MP1 for my grad project for a Embedded Linux course for exactly this reason - "how interesting and challenging would it be for developing on a SoC like this". Kudos to ST for making it easier than others!
NXP's i.MX 7 was released in 2013 with Cortex-A7 + Cortex-M4 and well supported back then. And there probably were earlier chips.
Yeah Linux is slow at developing features for embedded systems. That's why embedded programmers run code outside of Linux. Fortunately, Linux has kernel modules to make it easy to do things like that.
Historically, Linux isn't even a proper embedded OS. Linux continues to get better-and-better for embedded but I'd expect that 2013-era was dominated by VxWorks or other embedded OSes with a better featureset for embedded. It was _LINUX_ that was the problem in my experience, at least back then.
But then WindRiver (makers of VxWorks) added a bunch of features to the Linux kernel and now today Linux is acceptable for embedded. I dunno exactly when the switchover from majority VxWorks embedded systems -> WindRiver Linux -> and now each manufacturer has their own BSP / Linux support... but a lot of what you're complaining about was software development.
Even then, a ton of older embedded crap ran their own custom versions of Linux 2.4 or whatever and just maintained a separate branch. I'm guessing these older embedded systems got their start in the early 00s and just had issues upgrading past the Linux 2.4 -> Linux 2.6 jump.
Or in other words: it was far more likely that Linux wouldn't support Chip X, rather than Chip X was unable to support Linux. Or maybe a chip did support Linux but most of the codebase was stuck on Linux 2.4. Or if Linux support existed, it was effectively proprietary custom kernel modules that individual teams wrote for themselves rather than a community-driven internet-based workflow. Etc. etc. Linux was harder back then.
But the stuff you're talking about is early 2010s, if not 00s. Damn well over a decade, might be closer to TWO decades (and the only reason I don't know that is because I was a wee-little ignorant student back then and don't really know things older than 2010s....)
The days of VxWorks, vendor-specific paid-for IDEs, licensed compilers and proprietary BSPs pinned to a 2.x Linux kernel are long behind us - and thank fuck for that.
Back then, the way you were supposed to get into embedded development was "don't".
Things have changed since. You can now buy a bunch of microcontroller and SoC boards and get something to work just by following a simple tutorial you found online. Accessibility and ease of use have advanced in leaps and bounds.
But all of those secondary MCU-like cores? They're still in the old embedded hell. Things are getting better, but they are getting better very slowly.
> Back then, the way you were supposed to get into embedded development was "don't".
Hmmmmmm. I dunno, it feels like people today could do everything we did back then. That's how we all got into it, and back then we mostly were excited for how easy it was in the 00s or 10s compared to the 90s.
It's a weird thing but maybe it doesn't feel that hard in retrospect.
Virtually all big computers (mainframes, workstations, rackmount servers, PCs, laptops, tablets, cellphones, and e-readers) use this architecture: the Linux-grade CPU doesn't directly drive things like the USB port, the HDMI signal, the SSD's flash translation layer, or the hard disk head movements. Instead, real-time MCU-like cores do it.
The only difference is that a lot of them are on separate chips.
Probably programming a computer is too advanced for most to attempt, so that doesn't seem like a legitimate criticism.
FractalDB proves that "synthetic data useful for training AI" can be produced by a very small program.
There is "no room" in DNA for a full dataset, or a full snapshot of model weights. But there's plenty of room for "this one little trick cuts the data required to learn a desirable thing X in half" reproduced thousands of times for different X. Low Kolmogorov complexity, but high performance gains.
That "raw sensor input" is massively, hideously spatially and temporally redundant.
Even the shallow encoding patterns of AV1 can easily crush a raw video stream down by a factor of 10^3 without losing either spatial coherence or semantic loading.
Humans live in self-similar environments and perform self-similar activities. Any practical training dataset has the "natural human data" beat on diversity by a crushing amount. And a system that can learn deeper patterns makes the sensor streams more redundant, not less.
reply