Today, the Wayland enthusiasts like to talk about how they are modernizing the Linux graphics stack. But Linux is a Unix, and in Unix, everything is meant to be a file. So any Wayland evangelists out there, tell us: where in the file system can I find the files describing a window on the screen under the Wayland protocol? What file holds the coordinates of the window, its place in the Z-order, its colour depth, its contents?
As far as I'm aware nobody has even considered extending the file metaphor to the graphics stack, and it sounds a bit ridiculous to me.
It also reminds me of this talk that suggests maybe trying to express everything as a file might not be the best idea...
I've had to give up on KISS launcher recently because of this. 95% of the time it works fine, until it scrolls right to the end of the lost and won't allow you to scroll back. Swiping left and right then also breaks and the only thing to do is force stop quickstep.
EDIT: Just tried with Niagara and got the same issue almost immediately. (Seems to be triggered by opening recent apps from the launcher itself)
For reference, I'm on a Fairphone 5 using the stock ROM
On a tangential note: got caught out be it saying "next Saturday" is the 24th. I know that this is common terminology, but to me next feels like it means soonest, and I know I'm not the only one.
I'd argue that ML is the more general term (that could even apply to computing a line of best fit, if you're an extremist). But yeah, it's just semantics at this point
I've been having a lot of fun with scheme lately (specifically guile, but I don't think it matters much). It's a very stripped down language compared to common lisp, so I felt it was easier to get started with.
I guess the argument would be that software fixes need to be implemented for each ROM separately. Which also involves the pain of decompiling. Yes FPGAs are probably a pain, but they potentially offer perfect emulation of every game.
One thing I'm not sure about is how portable FPGA logic is. If I write a NES emulator in verilog for one FPGA, can that code be reused on a later model if, for example, my FPGA goes out of production?
Well it's 400,000 accidents, so there's probably every kind of circumstance you can imagine in there.
The point is that owning a BMW shouldn't affect the chance of you finding yourself in dangerous circumstances, other than ones you create by your own actions. (Unless everyone in the UK is secretly hoping to ram BMW drivers off the road).
Whilst I agree that that's a nice option to have (more options are usually better!) I've come to love the linux way of distribution via repositories. These days I barely use the cli too: GNOME software and KDE's Discover are great. Perhaps an official nightly flatpak would be best?
But I found the comments around Redfall interesting/concerning. Even if a studio gets promised independence in one of these giant mergers, they only have to fuck up once to get that taken away.
I'm not going to defend Redfall in any way, it actually does sound like a case of mismanagement. But I worry about the stifling of creativity that occurs when every studio is trying to play it safe to avoid becoming the next Bioware
I love the concept of organic maps, and do even use it occasionally, but for now I'm mostly sticking to OSMand.
The main feature missing for me is the ability to customise the map styles. I like using map apps for hiking and organic maps default (/only) style is ugly at best and unusable at worst for this.
samc @ samc @feddit.uk Posts 1Comments 84Joined 2 yr. ago
permission denied: /dev/display/3/349/1045