pixx@rl_dane @OpenComputeDesign @AnachronistJohn @kabel42
agreed, other than the part where you started by saying "firefox is good" /snark
R.L. Dane 
🍵 
@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
Bad Opinion Guy@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@OpenComputeDesign @rl_dane @pixx @AnachronistJohn
when I use chromium it it usually is pretty ok except for roll20 that somehow manages to crash the waylands session
when I use chromium it it usually is pretty ok except for roll20 that somehow manages to crash the waylands session
@kabel42 @rl_dane @pixx @AnachronistJohn
Too be fair, wayland is also absolute _crap_ :P
@OpenComputeDesign @rl_dane @pixx @AnachronistJohn
Yes and an app crashing the whole session is defenetly a wayland problem
Yes and an app crashing the whole session is defenetly a wayland problem
@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
Bitslingers-R-Us@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.
@AnachronistJohn @OpenComputeDesign @pixx @rl_dane
I think since the NT days a lot of windows bluescreens were bad drivers. Not sure if thats 10% or 70%
I think since the NT days a lot of windows bluescreens were bad drivers. Not sure if thats 10% or 70%
@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
@OpenComputeDesign @AnachronistJohn @pixx @rl_dane no drivers is gonna suck, but something more modern than vesa would be great
@kabel42 @AnachronistJohn @pixx @rl_dane
What possible downsides could there be to no drivers?
@pixx @OpenComputeDesign @AnachronistJohn @rl_dane
You could have a standard for that, you just probably need a new one for every new codec :)
You could have a standard for that, you just probably need a new one for every new codec :)
@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
@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.
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
@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
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
@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.
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
@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.
@OpenComputeDesign @pixx @rl_dane @AnachronistJohn that might have been true a few decades ago, but a lot of drivers in the linux kernel are now partly written by the manufacurer
@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.
@OpenComputeDesign @pixx @rl_dane @AnachronistJohn
yes, you can use the linux drivers directly, or as documentation, or reverse engeneer yourselve. What other option do you think there could be?
yes, you can use the linux drivers directly, or as documentation, or reverse engeneer yourselve. What other option do you think there could be?
@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.
@OpenComputeDesign @pixx @rl_dane @AnachronistJohn
You sure about that, I've heard people refering to the linux kernal as an example of how to manage large code bases.
You sure about that, I've heard people refering to the linux kernal as an example of how to manage large code bases.
@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.
@OpenComputeDesign @pixx @rl_dane @AnachronistJohn
Thats why the gnu project is developing a micro kernel and usung Linux only as a temporary solution untill that is usable
Thats why the gnu project is developing a micro kernel and usung Linux only as a temporary solution untill that is usable
@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
No no no
That's totally wrong
Plenty of hobby kernels progress waaaay faster than hurd
Gnu is just bad at everything lol
@OpenComputeDesign
I'm almost certain you're more competent than gnu lmao
It's hard not to be xD
@pixx @kabel42 @rl_dane @AnachronistJohn
*looks at my piles of ruined projects* er... I don't think I'm more competent than _anyone_