I'm sorry, you need to go to an optician. I can see the pixels at a comfortable distance at 1440p.

Alternatively, you play modern games with incredibly blurry AA solutions. Try looking at something older from when AA actually worked.

You're probably looking up close at a small portion of the screen - you'll always be able to "see the pixels" in that situation. If you sit far back enough to keep the whole of the screen comfortably in your visual field, the argument applies.

Oh goodness no, I sit way further away from the screen than most people. People always drag my screens closer when they have to borrow my desk

It's the protocol that VSC made to speak to programs that do code analysis and is the basis of goto definition, autocomplete, refactorings etc.

It's used by most smaller editors so they can backpack off of the efforts languages make to be usable in VSC. (Vim, Emacs, Zed, etc)

Also diagnostics (errors, warnings), inlay hints like types and parameters, code lens (tiny embedded buttons), symbols, notifications like “document changed”, and more

It's literally not running Android though. It's a complete from scratch OS, nothing shared with the linux based world

You can rely on IDE features when GitHub's web view has them

No, it's not and we don't. The numbers we do have suggest that it's great in developing societies and terrible in developed.

Perhaps then the person you are responding to is focusing on developed societies.

The motivation is truly awful, but the result? Thank goodness. Calibri just screams unprofessional

There's still bitrot on the X.org side even if your DM is maintained

Only on systemd/logind systems. Bitrot doesn't just happen, it caused by your dependencies considering your usecases obsolete.

Oh, so only on systems running the standard stack that 90% of Linux systems run then. Nope, no bitrot here.

Always the same lies...

I see no contradiction? Bitrot is caused by some other project moving. Of course the niche projects will suffer less from it if they incorporate less innovations.

Edit: You really do like calling other people liars and fascists?

We have a liar problem, and it turns out a fascist problem, when it comes to the X vs. Wayland kerfuffle, which shouldn't even be a thing.

Your level of antagonism is unwarranted.

> All of the X11 based WMs are slowly bit-rotting.

was the statement I was replying to. In 10 years of using dwm I've not been aware of any bitrot that affects me. Certainly nome in the WM itself.

How is Asahi not native?

The drivers, while impressively reverse-engineered, are basically alpha-quality by Linux standards. Even well-studied M1 machines will have spotty support in comparison to what an OEM can provide officially.

Those that are implemented have been very reliable in my experience, I think that labeling them “alpha-quality by Linux standards” is a ridiculous claim

Then you need an Intel or AMD laptop as a frame of reference. M1 is implemented as-is with much of the silicon's onboard accelerators entirely dark. Hardware accelerated video encode/decode is a lost cause, Thunderbolt will likely never happen, NEON is your fastest SIMD accelerator and cpuidle is still not really figured out.

Those are all perfectly acceptable limitations for a POC. And the GPU drivers are particularly well-made. But it doesn't really come close to how seriously AMD and Intel take Linux.

There's a big difference between saying that many of the drivers are missing entirely, and saying that the drivers that exist are alpha-quality.

+1. Been running Asahi Linux for half a year now. Everything that's advertized as working is working great.

my dude no. https://asahilinux.org/docs/platform/feature-support/m1/#tab...

even in the m1 there are 4 WIP in the support table, 2 TBA and 10 non mainline boxes for the M1 pro

> Those that are implemented

Asahi is also still a platform with a huge pile of out of tree patches on top because the platform itself is pretty unusual, requiring for example, a 16K page size kernel which is unlike pretty much every other arm Linux platform.

Presumably OP meant a Linux distro using a normal upstream kernel?

Vulkan also runs on Apple Silicon without translation on linux

It actually requires translation everywhere. GPUs have their own internal API that Vulkan, OpenGL, DirectX, etc. translate into. That is what drivers do.

That's being disingenuous. Of course a high level api has to be implemented in terms of hardware specifics, but you're implying, hopefully unintentionally, that that hardware interface is Metal, and it's not.

You can run Vulkan on Apple Silicon as natively as you can run Metal, even if some parts of it don't map too nicely to the hardware.

We only seriously say translate when we go from one high level API to another, just like we call some compilers transpilers even though literally everything is a compiler for something.

Because that's the difference between the paid and free versions