Readit Newsl1k commented on What the internet looked like in 1994 fastcompany.com/91140068/... · Posted by u/skilled
Some of the sites that went online around 1994 are still there:
I believe Carl Malamud (Internet Multicasting Service) was behind these.
The audio files are in Sun Audio format, which all browsers supported natively back then. Chromium apparently no longer does, requires saving and opening in VLC.
l1k commented on Even a laptop can run RAM externally thanks to CXL techradar.com/pro/even-a-... · Posted by u/ashvardanian
Who's using this? What company doesn't already have a rack they can add a few more sticks of RAM in for their workloads?
If you need a lot of RAM, usually you need to buy servers with multiple CPUs to which you can attach the memory. Because the amount of DRAM you can attach to one CPU is limited.
If you don't have the need for all the extra CPUs, just being able to attach more memory to a single CPU through CXL may be cheaper.
l1k commented on Bookworm – the new version of Raspberry Pi OS raspberrypi.com/news/book... · Posted by u/sohkamyung
I'm always confused by Raspberry Pi OS. It feels like Debian with a pre-set of packages, and a few additional software to control the board and bootloader.
Why not maintain these additional pieces of software packaged in debian, and provide a prebuilt image for the Raspberry Pi? Why maintain an entire different apt repository? Why publish new version months after the upstream debian is already released?
The original Raspberry Pi SoC (BCM2835) is ARMv6 with VFP2 Hard Float support.
Debian's "arm" architecture is ARMv7 with VFP3. It doesn't support BCM2835.
Debian's "armel" architecture is ARMv4. It doesn't use BCM2835 to its full potential.
So the BCM2835 is awkwardly positioned in-between Debian's two stock ARM 32-bit architectures, which motivated the decision to recompile all packages for a BCM2835-specific "armhf" distribution.
In a sense, it's a historic artifact.
I question whether it's wise to launch a new product before the supply chain issues which have plagued Raspberry Pi for years have been fully resolved.
Granted, the situation has improved slightly over the past few months. But you will still find Pi 4s out of stock more often than not.
The CEO said last year not to expect a Pi 5 in 2023, because they wanted to take the time to recover. Why the u-turn?
https://www.theverge.com/2022/12/21/23520400/raspberry-pi-5-...
The point here is likely to pull the rug out from under scalpers' feet.
With the Raspberry Pi 5 out in two weeks, all the held-back inventory of older models will be dumped, prices will plummet, availability will become a non-issue.
In that sense it's a wise move.
l1k commented on iAPX432: Gordon Moore, Risk and Intel’s Super-CISC Failure thechipletter.substack.co... · Posted by u/klelatti
One difference is that, according to the article, Intel actually learned quite a bit technically from the 432 even though it was a commercial flop. It's hard to see much of a silver lining in IA64/Itanium for either Intel or HP--or, indeed, for all the other companies that wasted resources on Itanium if only because they felt they had to cover their bases.
A lot of RISC CPU arches which were popular in the 1990's declined because their promulgators stopped investments and bet on switching to IA64 instead. Around the year 2000, VLIW was seen as the future and all the CISC and RISC architectures were considered obsolete.
That strategic failure by competitors allowed x86 to grow market share at the high end, which benefited Intel more than the money lost on Itanium.
It sounds like the pause/unpause might be the way to fix this properly, since trying to be heuristically smarter sounds like a recipe for never-ending corner case bugs like the OP’s issue.
The patch for pausing and unpausing seems quite reasonable, except that it does require driver support (unsurprising - you’re literally reallocating the resources used by the driver!). I suppose if you had at least a few movable devices then you should be ok in the event of a hotplug event, so you’d have to hope that enough drivers bother to support the feature.
I wonder what is necessary to get people to care about the patch enough to fix it up and mainline it? I suppose the problem it fixes is still niche enough that not so many people are clamoring for the fix.
The PCI resource allocation code is fairly intricate and everyone is scared that changing it may cause regressions. Sergei's patch set is quite intrusive and it would be necessary to somehow break it up into smaller pieces that are slowly fed into mainline over several release cycles, always watching out for regression reports. So, the problem is known, but the engineers working on PCI code in the kernel are given higher priority stuff to work on by their employers, hence the issue hasn't gotten the attention it deserves.
Actually I forgot to mention there's another solution: A PCIe feature called Flattening Portal Bridge (PCIe Base Spec r6.0 section 6.26). That was introduced with PCIe 5.0. It's more likely that FPB support is added in mainline than the pause/unpause feature. It's supported by recent Thunderbolt chips and it's an official feature of the PCIe standard, so companies will prefer dedicating resources to it rather than some non-standard approach.
DW = DesignWare