2021-07-30
Hardware and (Linux) driver quality can be invisible to non-specialists
We have been happy with Intel network hardware for a long time, especially under Linux. We've had a long and happy relationship with various generations of Intel 1G networking chipsets and cards, and then a more recent good history with Intel 10G-T chipsets, in our current generation of fileservers and some other machines (usually via add-on cards). Intel 10G-T cards have also been mostly problem free on various versions of OpenBSD (we had a weird issue or two with older OpenBSD versions).
Today I learned that Intel's high-speed networking hardware and possibly their Linux driver software is not all that well regarded by people with direct deep knowledge of it, courtesy of this tweet and its accompanying HN comment, which was in turn sparked by a blog post on hunting a serious Intel i40e driver bug. This wasn't a total surprise to me, because I think I've heard some prior grumbling to this effect, but it's certainly broadly surprising. But, not withstanding our experiences, I don't have any reason to doubt it.
The truth is that hardware and driver quality is hard for most people to observe outside of situations where things utterly fail. If Intel's 10G chipsets or drivers were utter unreliable trash, we and other people would have noticed long ago and they hopefully wouldn't be integrated on motherboards by various reasonably well regarded companies and so on. But this doesn't mean that the hardware and driver are good, just that they've been made to work in common situations. In other words, one reason that Intel's 10G-T chipsets have worked well for us is that we haven't been putting them under particular stress.
(We did test to see that Linux could manage more or less 10G line rate in artificial tests. But we didn't run these for hours or days, and in actual usage there are enough other overheads that I doubt we sustain close to 10G rates for more than a few seconds at a time.)
Does our ignorance matter? Well, maybe. Our Intel 10G-T environment works for us today without visible problems, but that doesn't mean it will work tomorrow or that there aren't 'invisible' problems we aren't noticing (we've had those before). Unfortunately becoming well educated about this sort of thing is a lot of work in the aggregate; there's a lot of drivers and hardware we'd have to dig into, and it's not clear how we could do it.
(The people who have educated opinions are those who do things like write drivers or put the hardware under significant stress in high powered environments.)
XHTML pages cause problems for some Firefox addons
These days, XHTML is pretty much a dead issue on the web. But browsers still support it and some people do serve real XHTML web pages (for example). What I've noticed on the occasions that I visit these web pages is that their being XHTML can cause problems for some of my Firefox addons. The most common addon that I notice problems with is FoxyGestures, partly because I believe it has to inject things in order to draw gesture trails and partly because I use it all the time.
(With FoxyGestures, the typical symptoms are that it will draw the gesture trails but no other UI elements, and then when I complete a gesture nothing happens. The web developer console reports XHTML errors.)
On the one hand, this is understandable. It's quite easy to create markup that's valid (or accepted) HTML but not valid XHTML, and Firefox does still insist on your XHTML being valid as far as I know. For content modification addons to work on XHTML pages as well as HTML pages, they need to first be aware of the issue (and care about it) and then either craft markup that works on both or detect XHTML pages and use different markup. There are probably plenty of Firefox addons that quietly don't work on XHTML pages.
(This is part of why I haven't reported this as an issue to the FoxyGestures developer.)
On the other hand, that this issue exists is another suggestion that real XHTML pages are quite uncommon on the web today. If XHTML pages were common, people using addons would be running into them frequently enough for things like this to get reported and then probably fixed. Or alternately, the XHTML issue would be well enough known among addon developers that they'd program around it as a matter of course. Sometimes where bugs exist and persist is a sign of where the dark corners are.
(I've never been a fan of XHTML, but it's been a dead issue for some years, cf.)
PS: Another issue for an addon interacting with a real XHTML web page is that apparently the XHTML DOM isn't the same as the HTML DOM, so some DOM manipulation may fail or produce unexpected results (which may then lead the addon to making alterations that aren't valid XHTML).