Notices by Adrian Cochrane (alcinnz@floss.social), page 30

Got some serious Haskell issues I seriously need help with.

I've got a dependency conflict. I know what dependency is causing the conflict & code's fixed, it's just not on Hackage yet (I am in communication there).

Unrelatedly I've started investigating a segfault with my collaborator. I haven't quite confirmed yet, but I suspect it's a GC bug.

:boost_love:

It’s all seen through the lens of capitalism and economic value.

Goal: increase market share.
Solution: build an Apple/Google-style app store.

The “Remaining Barriers” section is interesting.

That one has to be in a privileged position to contribute to free software in their spare time is unquestionable.

But how is writing an “app” for a few bucks (unless you’re the lucky one, assuming a Gaussian distribution for app revenue) any different?

“Flatpak has […] solved the largest technical issue which has held back the mainstream growth and acceptance of Linux on the desktop […] for the past 25 years”
https://discourse.flathub.org/t/flathub-in-2023/3808

One issue it did solve is excess modesty.

“To make a bigger mark on the world, as a community, we need to get out more.”

Call me an idealist, but that’s not the kind of mark I’d like to make on the world.

@aseva Repeatedly being told we're technophobe "luddites" for caring about performance & web best practices. For not getting excited about the latest JavaScript framework or AI model? When that's <5% of the top 10 million sites.

https://www.spicyweb.dev/the-great-gaslighting-of-the-js-age/

I guess the only real reason this is frustrating is because recruiters buy the line... The Problem is Capitalism!

So I know it’s only been like two or three people so far, but sighted developers asking how to use Orca on Linux to test for accessibility, shows that the time is fast approaching where accessibility is going to matter on Linux. I don’t know if it’s gonna be the explosion of the SteamDeck, or FOSS communities, or the rising interest in non-corporate computing and social networking and stuff. But this is already trickling down. Developers are needing to know about accessibility. They use Linux. I’m so glad to see KDE working on accessibility, and I hope that, one day, blind people can boot up a Linux installer, be told how to enable a screen reader, be guided through setup and onboarding after installation (with no unlabeled buttons please even though it’s just a slideshow Gnome (And an accessible Internet accounts adding process)). Shoot I’d even be glad to write tutorial information for it, like I did for QuickDocs in Fedora. But the time is now to focus on it, not when accessibility hits the FOSS community like a train. And I appreciate every single developer that comes to me, wanting to learn and understand. It’s miles, **miles** better than not giving a damn.

#accessibility #foss #linux

@Ulan_KA I guess @notjustbikes felt tired of making this argument you wished to see (that's basically what all his other videos are), & felt like changing things up by arguing that these are a direct downgrade in every way.

@alcinnz @phire one reason is that it picks sensible defaults for you. You can do next to nothing and your UI will look 'decent'. It's a reasonable subset of CSS that JustWorks and papers over the oddities. Basically what jQuery used to be for JS

@gotofritz @phire For me it's more bemusement. Though I don't trust the mindset it reinforces to create pages which sound decent in my auditory browser.

Personally my goto for most of the benefits of Tailwind would be Simple.CSS & the `style` attribute.

Because I do admit that the CSS defaults are stuck back in the day of standard-resolution desktop monitors, due to backwards compatibility. CSS frameworks have a place, it's just rare to find one I like.

@gotofritz @phire Fair enough!

@gotofritz @phire I still struggle to understand how Tailwind is any different to the CSS `style` attribute... Or any easier to learn...

@gotofritz @phire I'll concur to the extent that it would've been better if we could've gotten more predictability over this sooner... But you know what they say about hindsight!

What I defend is having a separation between semantics & style, since that allows your pages to be displayed in unexpected places. As long as we have the separation the cascade helps make it more predictable!

P.S. The PlayStation1 GPU just rendered triangles, with no depth-buffer. There was a seperate co-processor for floating-point multiply-adds. Devs had to depth-sort triangles, which was less efficient & couldn't always be done perfectly.

That's where its iconic quirks come from.

4.5/4 Truly fin!

These triangles typically cover only a couple of tiles, so processing them involves deciding whether to render them & dispatching to the appropriate tiles, one at a time.

After completing interpolation, possibly subsampling the registered texture if any, & maybe running a fragment-shader we need to merge the results.

An output-tile cache could significantly reduce reads/writes. Clustering each tile's processing could help, as could loosely-sorting the tile processing order.

4/4 Fin for now!

I'm not a fan of TikTok. But as far as I'm concerned, these bipartisan efforts to "ban TikTok" (and some other widely used Chinese services/products) based on "spying" concerns are essentially based on political bull. That's not to say that China doesn't spy (as does the U.S.) -- but going after these widely examined products and services is -- as far as I'm concerned -- nonsense. They're almost certainly not how China does their spying!

Once the vertices are pipelined through the vertex-shader (which may be preceded by a stage to programatically generate them), that data needs to be routed to the appropriate triangle.

This could be done by storing the vertex-indices for each triangle in some dedicated memory, including circuitry to populate it with an incrementing sequence. Once each vertex finishes it'd be tested each of those indices to set a flag, indicating when to emit the triangle to the next stage.

3/4?

That tiling helps being allowing output to be parallelized per-tile, & by making improving data-locality when fetching neighbouring pixels. Also there was often hardwired decompression to reduce memory needs.

---

Again the interesting bits, the transitions between the steps, is not public knowledge. So I'm echoing some educated guesses.

The GPU's input comes via a queue dispatching to the appropriate destination. Though Nintendo tasked this queue with more than outputting to the GPU.

2/?

How did we hardware-parallelise 3D (depth-buffered) graphics before we could stuff that hardware full of compute units?

How we assembled the different steps from multiply-adders is fairly straightforward, I'll leave that to your imagination. Though some early chips like in the PlayStation didn't include all the steps, as a cost-cutting measure.

The image data is split into tiles (who's pixels are ordered a space-filling curve) to simplify its processing.

1/?

@tbernard maybe I'm misunderstanding how the pixel grid works though