Looks like there is currently no RDMA support for thunderbolt, so it's a much higher latency connection. Apple has RDMA over thunderbolt working, so I wonder if it's possible on Strix Halo.
There is one obscure product that actually did use the feature. The Sharp Famicom Titler (or Famicom Editor) was a full Famicom that could show an external video input behind the Famicom graphics.
It doesn't seem that bad to me? Most of the problems that I see in that video look like recording issues where the camera isn't handling max brightness well. Recording CRTs is notoriously difficult!
Generally pixel art created for LCDs also looks good on CRTs, with tiny text being an obvious exception.
On top of this, I find ads on app store search results to be particularly bad. It's a business model that comes with all sorts of perverse incentives. It's so bad for users and legitimate developers.
The Mac Studio, in some ways, is in a class of its own for LLM inference. I think this is Apple leaning into that. They didn't add RDMA for general server clustering usefulness. They added it so you can put 4 Studios together in an LLM inferencing cluster exactly as demonstrated in the article.
> many people have never actually seen the colour "violet" which is a single wavelength of visible light
The violet seen in a rainbow (in nature, not a photo) is legit single wavelength violet. Same with the rainbows created from shining white light through a prism.
It's true that you don't really get to see it in isolation very often though. Maybe some flowers, birds, or butterflies? Or maybe the purple glow you get from UV lights?
The patent on the lockout mechanism has expired and clean software implementations of the algorithm have been created. So the old legal protections no longer apply.
And while Nintendo still aggressively enforces their copyright on their old games, they probably don't care very much about unlicensed games being created for their very old hardware. It's just not commercially relevant to them.
> But this means his pro and con opinions don't match typical opinions and this makes him polarizing. And hence some people will flag his articles reflexively or post reflexive dismissals. And Hacker News is heavily weighted to downrank polarizing articles.
I suspect this is it. A subset of users flag and/or downvote daringfireball on sight if it reaches the front page and the HN algorithm treats that as a strong single
I've seen the same. I don't think it's the reboot. My understanding is that NAND undergoes wear-leveling even when it is read only. The card shuffles data around its storage even when it hasn't been written to. And the firmware is unreliable.
> Why mount the SD card read/write. Why not mount read-only.
I have seen dozens of name brand SD cards fail while mounted read only in a medium sized deployment of Pis. The problems mostly come from firmware bugs, not from nand wear.
> I've long wondered why it remains the problem only on Raspberry Pi.
SD card firmware is often buggy and only heavily tested with windows. Camera manufactures will specify SD cards that are know to work with their cameras for this reason.
Upper right quadrant would be an 8-bit (or maybe 16-bit) CPU paired with a 3D graphics capable GPU. SNES + the SuperFX chip is the closest example I can think of. Similarly, there is the Genesis/Mega Drive + SVP chip.
I can't name a fully 8-bit machine with a 3d focused graphics chip. Maybe there are arcade boards?
Windows 95 was a big step forward though because it had actual process isolation and preemptive multitasking. While it wasn't very stable compared to Linux or NT, for the most part an application crash wouldn't bring down the whole machine the way it typically happened on classic Mac OS or Windows 3.1.
Larrabee was mostly x86 cores, but it did have sampling/texturing hardware because it's way more efficient to do those particular things in the 3d pipeline with dedicated hardware.
Modern retro computer designs run into the problem of generating a video signal. Ideally you'd have a tile and sprite based rendering. And you'd like to support HDMI or at least VGA. But there are no modern parts that offer this and building the functionality out of discrete components is impractical and unwieldy.
A FPGA is really just the right tool for solving the video problem. Or some projects do it with a micro-controller. But it's sort of too bad as it kind of undercuts the spirit of the whole design. If you video processor is orders of magnitude more powerful than the rest of the computer, then one starts to ask why not just implement the entire computer inside the video processor?
The ability to use a PC as a USB device opens up lots of fun possibilities. It's a little bit tragic that the required xDCI option is there in the hardware on this device, but it's not exposed and requires firmware hacking to access.
The hardware is capable, but the vendor has just turned it off and locked away the controls.