Haha, well it's not only X11, but it's one of the main reasons. Other reasons are that for my usage and work, it just "works", no hours of configuration in dotfiles. Also it's convenient as a cross platform developer, since I can just crosscompile to Linux and Windows(mingw) via Docker. However, without the Mac, you'll have to break some licenses with a hackintosh. I think the project is cool, but in work related situations I can't do that because of legal reasons.

This also reminds me about a cool project I've found, but not had time to test yet; https://github.com/shinh/maloader

Yeah. Linux is not like that any more.

Try Linux Mint. The only configuration you will do is to enter your username and password.

And then again when their site gets subverted and you have to reinstall since you might have a rootkitted binary. I loved Mint for its incredible usability. Just can't recommend a supplier whose security was that bad.

Nah. You can't hold a 'maintainer transgression' which happened two years ago against them forever.

They have indeed implemented solid checks and offer a Shaxxx-sum file for every iso file they publish. Not only that, bt publicly "soul searched" and went to great lenghts to assure the community and its users that such mistakes would not be repeated. Now verifying the authenticity of the iso file actively encouraged, on the download page.

They made a mistake, took solid steps to improve, and the show has moved on. You should too, instead of smearing the project far far down the line. (I'm being retorical, I know)

The project's security sucked across the board. They didn't care or know how to do it. One hacker here even appeared to hack them in mid-discussion and post database credentials that showed they were using defaults. They then implemented a mitigation after bad press and soul searching. The thing I'm doing isn't smearing the project: it's letting people know not to trust its security without 3rd party verification (esp pen tests). That's because (a) it's a sane default for any project and (b) this one failed hard on the basics at least once.

So, I advise caution until I see a 3rd party evaluation showing their security is good now. You apparently followed them carefully. Did any security professionals look at their site/db/whatever after the fixes and give independent confirmation? That's all I'd need to stop reminding people of this.

Fully aware of it, but I prefers the custom (e.g awesomewm and fluxbox), my problem is just that I don't have time for all that fun anymore :)

The graphical user interface has almost nothing to do with ease of configuration. And yes, ease of configuration is worth a lot.

Related anecdote: I started a friend of mine on Ubuntu, but she hated all the configuration via endless clicking. She immediately took to Archlinux---there's still configuration, but it's simpler and since it's all text, it's much easier to just read everything on the Archwiki instead of having to follow pictures (or descriptions of pictures).

Kdrive isn't bad if you don't mind 100% framebuffer X (which is fast enough to watch videos, run vim, play old videogames and emulators etc)

Never heard of Kdrive, thanks for the tip! I will check it out for sure.

I guess a proper stack for doing 3D graphics, instead of the gimmicks that X has had over the years?

I lost count how many times I sat at FOSDEM X room, seeing the improvements that would eventually come (some day).

The Mesa/DRM stack is significantly better than Apple's, because the OpenGL implementation actually works, and Vulkan is supported on at least some hardware.

At the protocol level, X isn't involved that much with the 3D graphics stack anyhow these days. Xorg simply speaks DRI3, which is just a way to marshal file descriptors representing graphics buffers over the connection. It isn't involved in the rendering happening at either end (application and compositor).

At least Khronos will be creating Meta API for Metal, Directx and Vullan to address the difference, I hope that would just work and solve around Vulkan fragmentation and complexity that cant fit into all Apple SDK.

Metal is fine and supported by all relevant engines, thanks.

As the name says, DRI3 was yet another attempt to improve the whole performance stack on Linux.

As mentioned, I did my share of FOSDEM sessions.

> Metal is fine and supported by all relevant engines, thanks.

thanks for the laugh

Professional game developers have a different opinion regarding graphics APIs, even those that have been strong OpenGL apologists in the past:

"John Carmack: Its still OpenGL, although we obviously use a D3D-ish API [on the Xbox 360], and CG on the PS3. Its interesting how little of the technology cares what API you're using and what generation of the technology you're on. You've got a small handful of files that care about what API they're on, and millions of lines of code that are agnostic to the platform that they're on."

http://fd.fabiensanglard.net/doom3/pdfs/johnc-interviews.pdf

AAA studios already adopted Metal on their engines, Vulkan only matters on GNU/Linux among those having supported graphics cards.

On Android, it is only available as optional graphics API in 10% of devices available worldwide.

On Windows, it is only supported on legacy Win32, it isn't and it won't be supported on UWP.

On Nintendo Switch, there is the option to use the more lower level API NVN instead.

So laugh at will, lets see which APIs game studios care about.

I do graphics professionally, and I would much prefer to just see Vulkan everywhere. Metal has essentially nothing to recommend itself over Vulkan; it's just a worse API. Things I've dealt with:

- Tessellation is weird in Metal, as you don't have hull shaders and have to wedge it into the compute pipeline.

- I haven't found a good way to disable multisampling while rendering into a multisample texture, something that is trivial in OpenGL. This can be useful for various effects.

- Switching command encoders is really slow.

- There is no good way I have found to be able to get good timing information inside the app as opposed to the profiler. The info is available on iOS, but not macOS. This is important for telemetry, etc.

Studios are obviously just going to choose the API that's supported on the platforms they're shipping to. Usually there's only one "blessed" API, and so that's the one they pick. It doesn't say anything about the quality of those APIs.

> AAA studios already adopted Metal on their engines

Genuine question : Do AAA studio really care about metal ? Is gaming on Mac a thing now ?

Not only gaming is a thing on Mac, more than on GNU/Linux or even BSD combined, it is also a thing on iPhone, iPad and Apple TV, all with Metal support.

Also Apple's augmented reality is based on Metal, and they had Valve on stage praising it at WWDC, with native support on SteamVR SDK.

Finally, many of the frameworks that made use OpenGL, including the window manager, are now working on top of Metal.

Apple is using Metal because it's a modest improvement over OpenGL (in some areas; it's a regression in others) and, more importantly, their OpenGL implementation is extremely buggy.

You haven't said anything about Vulkan vs. Metal, and you can't, because Vulkan is a better API for the reasons I described upthread.

I can't say anything good about Vulkan, because I am not going to buy a new laptop or a Google Pixel just to try it out.

Then please stop saying it's a bad API.

Full disclosure: I have colleagues and friends on the Khronos standards group, and I don't like seeing their work bashed without specific technical reasons.

Where have I said it is a bad API?

I have said it has insignificant market share and that share won't get better outside GNU/Linux for the foreseeable future.

That has nothing to do with quality.

A good few of the major engines now support it.

Gaming on the Mac is a thing to some extent. See Steam for MacOS.

Game engine vendors also care a great deal about iOS, since they have a large number of customers who do, so that's also driving support for Metal in those engines.

But Wayland is that exact same 3d graphics stack.

Kind of, because it is built on top EGL so everything is done via the 3D stack.

On X there is a mixture of X protocol, 3D stack and the interactions among all possible combinations.

X11 is also responsible for some of the sluggishness of the Linux desktop, like resizing windows.

With compositing enabled that doesn't really matter.