Article note: I'm still an IP minimalist, and I want to make sure that individuals practically get the same (and more!) rights to engage with cultural content that the pattern-engine-as-a-service "AI" companies are being afforded by dumb semantic games and lawyer armies.
Article note: Interesting.
It really looks like MS got ThreadX while me-tooing because Amazon got control of FreeRTOS, and most of the talent left for PX5 afterwards, so this is a "setting the me-too mistake free" situation, as many things dumped on the Eclipse foundation are. At least they're doing that, and under an MIT license so folks are likely to grab it and embed it in commercial projects until it's done atrophying away from lack of contributions back. ThreadX is quite widely used and seems to have a decent dev ecosystem, so it'll probably be good for some years.
...It also doesn't look like the VideoCore version that runs on Pis is actually in the published code, which is unfortunate.
Article note: I'm typically amused by the hardware similarity of all the devices in the SBC/Media Gadget/Thin Client/Chromebook space and ...apparently Amazon thinks the same way.
It's also a super clear "Rent time on someone elses' computer" return-to-mainframe-era SaaS rentseeking situation, the shittiest feeblest VDI instances are like $25/mo.
Amazon has turned its Fire TV Cube streaming device into a thin client optimized for Amazon Web Services (AWS).
Amazon's Workspaces Thin Client also supports Amazon's Workspaces Web, for accessing virtual desktops from a browser, and AppStream.
The computer is a Fire TV Cube with a new software stack. All the hardware—from the 2GB of LPDDR4x RAM and 16GB of storage, to the Arm processor with 8 cores, including four running at up to 2.2 GHz—remain identical whether buying the device as an Alexa-powered entertainment-streaming device or thin client computer. Both the Fire TV Cube and Workspaces Thin Client run an Android Open Source Project-based Android fork (for now).
After I wrote about the possibility of programmable Mac ROM SIMMs in Quadras a couple of months ago, I suspected that there had been a way for developers at Apple in the 68k Mac era to reflash the ROM in their Macs during development, just like BIOS updates on PCs. The reason I believed this is because the ROM SIMM socket in the Quadras brought out pins for 12V (VPP) and write enable (/WE). I had verified that the write enable pin was going into the memory controller chip in several Mac models, so I was pretty confident that in-system programming was possible.
I honestly cannot believe it’s taken this long for such a tool to become available one way or the other. Classic Macs are incredibly popular in the retro community, and being able to reflash the ROMs like this is incredibly useful. It took some work and disassembly, but Doug Brown got it working.
Article note: "Your established usecase is wrooong! Supporting it would be inconsistent with purely-theoretical future UI modes!" again from the Wayland camp.
These days I basically hope we get a PipeWire to Wayland's Pulseaudio. PA was "the ultimate solution" and always horrible even though it lingered for years, but it paved the technical and social way for a good (and compatible) successor, and showed where the problem points would be so the successor actually _did_ solve the whole problem space and more.
The Wayland folks have made some terrible-looking choices, largely related to getting burnt on supporting haphazard extensions forever on X... why is why the "do everything in extensions that we'll spend a decade arguing about before giving in and supporting what was initially asked for, just restricted enough to be awkward for every program that uses it forever" design was probably a bad decision. Also around the lack of a reference compositor library (but that's probably the same thing eg. xlib). Also around things like punting on input plumbing (yes, slipping into the kernel input layer with keyd virtual devices mostly works for hotkeys and remaps, but that's hacky. No, there still isn't an elegant way to pipe text to a specified window. Yes, those should be the same feature, and should be standard across compositors with one protocol.).
It's possible there's going to either be an "un-blessed" rogue extension suite that allows a bunch of "unapproved" behavior but every useful compositor has to implement because so much desirable software assumes its presence, or a shim/protocol filter/interceptor thing that sits behind/between/around the compositor to do the critical stuff that has been deemed 'wrong.'
Article note: I take software whose preferred/only deployment method is docker to be saying "Our dependency/build/deployment situation is so out of control we can't actually build, package, and deploy this software without replicating the whole dev environment." It's not a vote of confidence, it's plumbing for canonicalizing throwing broken software in /opt with its entire dependency tree.
Article note: Interesting. It appears to be a paper tiger whose memory system can't possibly feed its execution units. There are a lot of computers where this is true to some degree (almost all GPU heavy systems have "implausible" arithmetic:memory and arithmetic:memory bandwidth ratios even with fancy later-model HBM controllers and such), but this is (1) way worse and (2) across international relations boundaries that encourage rather than discourage pointing out the BS.
Sunway’s new supercomputer therefore feels like a system designed with the goal of landing high on some TOP500 lists. For that purpose, it’s perfect, providing a lot of throughput without wasting money on pesky things like cache, out-of-order execution, and high bandwidth memory. But from the perspective of solving a nation’s problems, I feel like Sunway is chasing a metric. A nation doing well in advanced technology might have a lot of supercomputer throughput, but more supercomputer throughput doesn’t necessarily mean you’ll solve technological problems faster.
A detailed look at China’s new supercomputer. The conclusion quoted above is very well supported by the data and research concerning this new supercomputer, and the article is a great read.
Article note: The usual maxim that the larger the distance between the people selecting the software and the people using the software, the worse the outcomes will be applies, but there is some extra-special nonsense here.
The intersection of srs bsns computer security practices and actual life-critical systems makes for some really interesting should-be-obvious failure modes and workarounds, though.
Article note: As the tiny incestuous techbro world turns.
Did the old board ingest too much of their own regulatory-capture-generating fearmongering?
Did Microsoft find a new version of EEE?
Was it some sort of sabotage?
Did some dumb personal squabble just get way out of hand?
Does anything about this matter _at all_ to anyone except for investors in the hype cycle?
I got talked into going to SC again this year, as I have almost every year since 2009. It’s not really my area of focus, but it’s always interesting.
UK’s presence featured a mixture of IT/CCS types and researchers, the research end of the booth was mostly focused on ongoing Parallel Bit Pattern Computing work, featuring a new demo/visualization thing that I built much of the hardware and some of the software for in the 3 weeks before we left for the conference (the rest came from Hank modelling some printable parts, pulling the compute engine from an older demo he wrote, and building some adapter code). It was more exhausting than the conference itself, but a really fun prototyping/micomanufacturing flex. Fancy 3D printed parts, 2020 extrusion, some laser cut bits, piles of addressable LEDs, a bit of embedded electronics. There is also a partially-functional prototype backplane to link 4 EBAZ425 FPGA boards through an Aggregate Function Network as a PBP substrate that …I designed. There’s a lot of not-my-job work I did on display; I should probably start throwing more of a fit about that.
Some notes about the stuff we were showing and interesting(?) industry observations below.