ArchOversight

I know a ton of embedded shops that are running x86 (including some actual i386 still) in production, and will likely for years to come. That stuff was bullet proof, cheap and still runs today.

Some of these things have long lifetimes.

14.x-RELEASE if you still need i386 support, 15.x-RELEASE if you are installing new and want the longest longevity.

This is the same as when you get a phone through a mobile carrier. T-Mobile doesn't care that I got mugged, they want their money.

The linked Github also states that updating to 26.6 works.

Do you have more information on this?

It's not that it's that complex to need all of this. It's about ease of use. Home Assistant OS makes life simpler for users (such as myself), it makes it easy to use adding that run as additional docker containers, it makes plugging in USB z-wave/zigbee devices a breeze.

While it is technically no longer supported, you can still install the whole kit and caboodle using pip in a Python virtual environment, but why would you?

The insurance companies primarily... secondary the people with bombs that can sink ships attempting to use the waterways.

That's why Matter and Thread are IPv6. You don't need IPv4 at all... and if you run out of IPv6 address space, I'd love to see just how many devices/sensors you have in your home.

Which sellers? I have been looking for custom ones because I have some weird window sizes.

FedEx in my case paid the bill to customs, shipped me my item, and then secondary sent me a bill to pay for the customs fees after I had already received the item.

They don't want shipments stuck in port because storage there is expensive.

That assumes the server has a lot of additional CPU power to serve the content as HTML (and thus do the templating server side), whereas with XSLT I can serve XML and the XSLT and the client side can render the page according to the XSLT.

The XSLT can also be served once, and then cached for a very long time period, and the XML can be very small.

If this is the reason to remove and or not add something to the web, then we should take a good hard look at things like WebSerial/WebBluetooth/WebGPU/Canvas/WebMIDI and other stuff that has been added that is used by a very small percentage of people yet all could contain various security bugs...

If the goal is to reduce security bugs, then we should stop introducing niche features that only make sense when you are trying to have the browser replace the whole OS.

Sounds like libxslt needs more than just a small number of fixes, and it sounds like Google could be paying someone, like you, to help provide the necessary guidance and feedback to increase the usability and capabilities of the library and evolve it for the better.

Instead Google and others just use it, and expect that any issues that come up to be immediately fixed by the one or two open source maintainers that happen to work on it in their spare time. The power imbalance must not be lost on you here...

If you wanted to dive into what [3] does, you could do so, you could then document it, or refactor it so that it is more obvious, or remove the compile time flag entirely. There is institutional knowledge everywhere...