Posts by Bela Lubkin

PATA / IDE are still supported

This is the removal of a lot of ancient driver code specifically hard-coded for old PATA controller hardware. The same controllers are still supported with smaller, more modular drivers based on libata and presenting the drives as pseudo-SCSI devices.

So no, old 40-pin cables have not just been obsoleted. Just old device names in the /dev/hda style, which now become /dev/sda style.

l imagine there will be some exciting quirks to discover while moving to the new kernel on systems with the old hardware. You 'get to' discover all the places which have unwisely hard-coded hda-style names. (I also imagine that most of the affected systems will be VMs, here in the early 2020s...)

why go along with Google?

It's a matter of self defense.

Since manifest v3 has a lot of API changes, extension developers who port to it will be under pressure to drop v2 support. New extensions developed after v3 is widespread and fully operational will of course target the gigantic Chrome market, ignoring or only addressing as a lagging afterthought the relatively tiny v2 market.

Browsers which do not support v3 will be left behind in a shrinking pool of sad remnant extensions. Look at the state of extensions for Firefox forks which haven't picked up WebExtensions (manifest v2) support.

None of this would apply if it were truly just a different manifest format; if a single extension could easily be packaged in either 'v2' or 'v3' format with a few simple build procedure changes. The name is misleading.

The Race Is On

'tentatively starting with Chrome 94 in Q3 of 2021'

Interestingly, Firefox already releases on a 4-week cycle and currently has this schedule for mainline releases in 2021Q3:

2021-07-13 -- Firefox 91

2021-08-10 -- Firefox 92

2021-09-07 -- Firefox 93

According to the Chrome plan, Chrome will perpetually be 1, 2 or 3 releases higher than Firefox (depending when in Q3 they switch to the 4-week cycle).

Makes you go 'hmmmm'.

-- and, of course, you can use the 30-line script to inject any CSS of your own. I would cut it down to about 10 lines since the bulk of the script relates to dealing with old pre-Greasemonkey userscript injection frameworks...

serial liquid cooling

Is that picture in the article for real? They bring in cold liquid, heat it up on one TPU, pipe it to the next TPU, heat it some more, send it back to the cooling unit?

So presumably TPU #1 'mysteriously' always runs overly hot and has to throttle back, while TPU #0 gets to blithely crank along at full speed?

I think most currently shipping Intel CPUs have integrated GPUs, even if they are sold as a GPU-less model. The silicon is there, disabled for some combination of marketing & manufacture-time test failure reasons.

Even the GPUs which failed as full marketable GPUs probably work well enough to be used as background security lurkers.

... I wonder if they'll roll out a set of microcode updates which partially enable those GPUs to be used as security sidecars.

Thank you for this item of actual thoughtful introspection and analysis

THIS is what I expect from The Register. I don't even care if it's totally wrong (and I'm not saying or even trying to imply that it is). It is interesting analysis, the polar opposite of the barely-chewed press releases which constitute an unfortunately large portion of recent output.

Do it again. Keep doing it.

the important question

Will the resulting company be known as QualBroad, BroadQual, or -- for Maximum Brand Loyalty Preservation -- CommCom or ComComm?

FB and WTF aren't actually particularly 'integrated', they just provide a place where their respective chat things *can* lurk if you so choose. I don't.

The entire spectrum of Chrome extensions are usable on current releases of Opera.

I switched to it from Firefox about 2 years ago, have been reasonably satisfied since then. I have up-to-date FF and Chrome available as well, poke around with each from time to time, return to Opera without regret.

My guess: some crucial security fix which is just too difficult to backport to the ancient 11.2 code base. For this reason to make sense, there also has to be at least one gigantic paying customer or strategic partner who firmly insist on continued Linux support. This was already a necessary condition for the previous ongoing 11.2 patching, but now we know that the insisting customer is even bigger or more strategic than we might previously have imagined...

The testing burden is real

Operating system initialization is extremely CPU- and chipset-specific. Showing that your OS tests successfully in 32-bit mode on a modern 64-bit x86 CPU is not at all the same as showing that it actually works on real 32-bit hardware. I'm talking about differences in page table setup, various control registers, workarounds for ancient bugs like "f00f" and the FP divide bug, etc.

(Aside: a good rule of thumb about OS testing is: if you haven't tested it, IT DOESN'T WORK. This isn't an actual identity, but it's close. Changes *here* have unanticipated effects *there*, so it's really necessary to test every supported scenario against every release.)

So, don't make any changes to 32-bit init code? But huge swaths of the x86 code is shared between 32- and 64-bit paths. An attempt to freeze the 32-bit init code would involve changes all over the shared x86 arch part of the kernel. This would be potentially disruptive of the 64-bit path, thus nearly impossible to get merged into the mainline kernel. So now you're asking distros to maintain a forked kernel for arbitrarily long.

Init code isn't the only pain point. Even if you get the OS to boot, you'll eventually find other subtle issues leading to data corruption, panics, etc., unless you are rigorously testing on real 32-bit hardware.

Meanwhile, old hardware can continue to run the same old software that it already runs. Nothing a distro does is going to reach out and retroactively destroy existing x86_32-supporting OS releases.

Embedded users shouldn't be too bothered since they rarely use "full fat" desktop versions of any distro. Many embedded systems build their entire userland themselves and don't really rely on a "distro" at all. It is irrelevant that they can't acquire things like modern browsers able to handle the latest web site tricks. (For most embedded applications, it would be a serious security problem if it was even *possible* to install a full browser...)

not much ARM code should need to be emulated

Android apps are mostly Dalvik (cough*Java*cough) bytecode; they should run just as "fast" on x86 as on ARM.

Presumably where there's ARM code, the phone uses some sort of JIT ARM-to-x86 compiler. This stuff used to be terribly slow (10-100x penalty). These days there is no technological reason it should cost more than about 2:1. That is, *if* they cared to develop or buy the very best, the penalty shouldn't be too bad. If they just slapped something naive together then it's probably back to 10:1 or worse... Benchmarks will eventually tell the real story.

And presumably popular apps which use native ARM code will eventually be recompiled as fat binaries or separate x86 packages.

My guess is that the current generation of Atom SoCs will prove to be perfectly adequate also-rans in the cell phone CPU arena. They will not compare successfully against the latest multicore ARMs like Tegra 3, QualComm S4, etc. Atom is only barely touching the compute-per-watt range of the newer ARMs.

Gen8-alias-G8 -- yep, that all works out...