@rl_dane @OpenComputeDesign @AnachronistJohn @kabel42

agreed, other than the part where you started by saying "firefox is good" /snark

@pixx @OpenComputeDesign @AnachronistJohn @kabel42

I think that Firefox is objectively, ethically the least bad among any modern web browsers that can load a page like youtube or amazon.

Horrible bar to pass under, of course, but it is what it is.

@rl_dane @OpenComputeDesign @AnachronistJohn @kabel42

sure, it's still shit software thuogh

I'm not even talking ethics, just as a pure matter of code

it's bad code

@pixx @rl_dane @AnachronistJohn @kabel42

Bad ethics, bad code, still better in both respects to Chrome imo :P

Still don't like it, though

@OpenComputeDesign @pixx @AnachronistJohn @kabel42

I'm not so sure that Firefox is better code than Chromium. But definitely more ethical. Or at least, up until a couple years ago.

@rl_dane @pixx @AnachronistJohn @kabel42

I dunno, chromium based browsers have always been buggy as _fuck_ in my experience. Yes, even worse than firefox.

@kabel42 @rl_dane @pixx @AnachronistJohn

Too be fair, wayland is also absolute _crap_ :P

@kabel42 @rl_dane @pixx @AnachronistJohn

Hey, as we've all been told, on a preemptive multitasking system, it is _impossible_ for one crashed app to effect the rest of the system. So you must just be imagining things, anyway :P

@OpenComputeDesign @kabel42 @rl_dane @pixx That’s a bit disingenuous.

Obviously, on a Sinclair QL or an Amiga, a rogue program can take down the whole system.

On Windows, with tons of design issues and decades of bad decision history, a rogue program can take down the whole system.

With Linux and the BSDs, this shouldn’t happen, but it’s possible, and most often it happens when trusting stuff like video hardware to do its thing where the rest of the OS has not as much control over things as it does with the rest of the computer.

With Linux and the BSDs, if you can reliably crash the whole computer using a userland program, that’s a big bug and should be reported.

On the other hand, sometimes it feels good to vent, and if that’s the purpose of what you’re saying, that’s fine, but understand that your generalizations aren’t correct.

@kabel42 @AnachronistJohn @pixx @rl_dane

Ok too be fair drivers are literally the worst thing ever and it would genuinely be better for everyone if we just standardized hardware so drivers could be abolished completely

@kabel42 @AnachronistJohn @pixx @rl_dane

What possible downsides could there be to no drivers?

@kabel42
Theoretically you wouldn't even need that but really, part of the problem with standardization is that if the standard way is bad, you'll just have people ignore it

Opengl is a standard and we still need drivers.

The only way around that is what rpi and, apparently, nvidia?? are soing, where the hardware has a coprocessor in it that implements the driver and then the api on the cpu is just a proxy

Which means you still have a driver but now you're dependent on the vendor for it and it's opaque and hidden

This is not better

@OpenComputeDesign @AnachronistJohn @rl_dane

@pixx @kabel42 @OpenComputeDesign @AnachronistJohn

Disagree. If there's a single hardware standard, and the vendor's implementation is crap, then the blame is on the hardware/firmware, rather than the OS/drivers.

@rl_dane

Yeah but it doesn't *matter* who the blame is on

When the standard is implemented as a driver in software it can be _fixed_

When it's a driver in firmware then bugs are permanent the instant the vendor stops caring

A valve dev has been improving Amdgpu support for older cards recently

If the driver was in firmware then that wpuld be completely impossible

@kabel42 @OpenComputeDesign @AnachronistJohn

@pixx @rl_dane @kabel42 @AnachronistJohn

Counter point:
If there were no drivers, and everything was standardized, then there would be no moving targets, and application optimization could be perfected in perpetuity without the threat of obsoletion that currently plagues the computing world

@OpenComputeDesign

No, because now you've just shifted bugs into hardware where they're harder to fix

Drivers aren't buggy because drivers are a bad idea, it's because it's a hard problem. Implement an algorithm entirely in hardware and it's impossible to fix if the silicon is wrong.

The only possible way to have bugs be fixable is to have software controlling the hardware, so that you can route around bad or incorrect hardware. You can't just say 'well stop fucking up the hardware then,' that isn't how anything works

@rl_dane @kabel42 @AnachronistJohn

@pixx @OpenComputeDesign @kabel42 @AnachronistJohn

I dunno, I still think it's better to offer standard interfaces than have every piece of hardware work in a bespoke way.

@rl_dane

Yeah but the hardware _is_ pretty custom, and very complex, already. Pretending it's not doesn't help.

Even something as simple as "reset" requires either knowing about every block that needs reset, or having effectively a cpu on device that performs that operation.

If you have software for it anyways- and you *will* - I'd much rather that software be in the os as source code than on the device as a blob

@OpenComputeDesign @kabel42 @AnachronistJohn

@pixx @rl_dane @kabel42 @AnachronistJohn

Concept:
_Force_ on device software to be open standards as well.

Lots of drivers, even for open source operating systems, still rely on binary blobs, both written to ROM in the hardware, and embedded in the drivers. Debian not installing such drivers by default for many years was _highly_ problematic, but it sure did give a fantastic impression of just how many drivers rely on proprietary blobs.

@pixx @rl_dane @kabel42 @AnachronistJohn

And besides, sure, there _are_ lots of open source drivers. But that's _despite_ the efforts of hardware vendors. As far as big companies are concerned, open source drivers are a bug, not a feature.

@kabel42 @pixx @rl_dane @AnachronistJohn

Yeah but, every single OS now has to either borrow Linux's honestly pretty crappy drivers, or go through the exact same process an Linux did with 30 years of fighting hell.

@kabel42 @pixx @rl_dane @AnachronistJohn

Well, using Linux drivers as documentation would be a lot easier if it wasn't for the fact that Linux stuff, in general, seems to have pretty poor code readability. And also, lots of Linux drivers _still_ have proprietary blobs at their core.

@kabel42 @pixx @rl_dane @AnachronistJohn

Well, too be fair, large code bases just kinda are the very definition of nightmares. "Kernel" and "large code base" ideally would not be related terms at all.

@kabel42 @pixx @rl_dane @AnachronistJohn

Hasn't it been working on that since before Linux was even a thing?

@kabel42 @pixx @rl_dane @AnachronistJohn

Sure sure :P

One of the things that keeps me from flat out writing my own OS is remembering how the Gnu kernel is going

@OpenComputeDesign @kabel42 @pixx @AnachronistJohn

Do what #SerenityOS did: target QEMU as your "hardware."

Solves a lot of problems. Linux kernel as HAL.

@rl_dane @kabel42 @pixx @AnachronistJohn

This is simultaniously viscerally terrifying and very appealing