One of these days you should read the X section of the Unix Haters Handbook. Wayland is being built for the world as it is, X was built for a world that never was. In this case, it’s quite hard to not be better designed.

And yet it suffices to have two GPU in your system (both driven by OSS drivers) that the option of running Wayland disappears from GDM on Fedoras up to 32 at least.

The laptop in question is from the late 2016.

So much for "the world that is". My machine must be very, very otherworldly.

"One of these days you should read the X section of the Unix Haters Handbook."

I have. It was written by someone who doesn't know the difference between a "client" and a "server".

No, really. The author, whose name I can't remember at the moment, complains that X has the server/client roles reversed; that xcalc is a server and the display is a client. The usual defense is that it's "tongue in cheek", but from a networking standpoint it is simply wrong.

You login to the server and run application, that application connects to the X Server on your client.

    +----------------+     +----------------+
    | Client         +---->+ Server         |
    |                |     |                |
    | +-----------+  |     | +-----------+  |
    | |X Server   +<---------+Application|  |
    | +-----------+  |     | +-----------+  |
    |                |     |                |
    +----------------+     +----------------+

I can see how confusion may arise.

> X was built for a world that never was.

No. This is the thinking of people who can't see the utility of a use case they never personally use. It's the thinking of people who believe that "ssh -X" is "obsolete" because RDP exists, or that window managers can become obsolete because the fashion has moved on. X works, it's worked for decades, and saying that it's never worked doesn't negate that.

I find it really arrogant to claim "this software does everything I need, so it should never change", while in reality you are but an infinitesimally small part of the user base said software has to support.

Sure, all the software can stay where they are if all the developers had to serve is you. But that is just not the reality.

There isn't a magical different userbase Linux has to serve which has somehow bizarre needs not served by thoughtfully-designed older software, but which newer, poorly-designed software somehow meets.

Yes, we need a newer web browser, but that could run on old-school Linux/Unix just fine. Aside from that, there isn't anything wrong with nineties Linux which couldn't have been brought up to modern standards with a bit more discipline.

Someone decided ALSA (or OSS, it doesn't matter) was rough to deal with, so they build Pulse and JACK on top of it, rather than a modest expansion of ALSA. Someone didn't like the network layer, so they build a userspace wrapper, and someone didn't like that, so they wrapped it up in a GUI.

At the end of the day:

1) Everything is slow, requiring literally more than 100x the resources it once did.

2) Everything is complex, with layers upon layers, and text files with comments "This is managed by my hack. DO NOT EDIT THIS BY HAND. I keep the exact same data elsewhere, in my own config file, since I couldn't be bothered to read what's in the line below."

3) Everything is brittle and hard-to-understand. I knew how nineties Linux booted. Today, the logic is distributed among dozens of layers, mostly because people wanted to reinvent new things, rather than polishing/improving/fixing old ones. Different apps go for the wrong layer, and tutorials point to the wrong ones too.

Now Ubuntu is throwing its hands up at the mess, and building snap to hide all this under yet. another. layer.

As a footnote, ALSA was just about the last time this happened right, with it replacing OSS while maintaining compatibility.

Maybe you should fine community that shares your views.

I don't use pulseaudio, networkmanager, desktop environment, works perfectly in Arch Linux [1]. Arch has great wiki, it is correct. System is quite transparent.

I am fine with systemd but, for example, Void Linux [2] uses runit, Alpine Linux [3] uses OpenRC and is compiled statically.

Arch Linux pacman serves my needs perfectly, it is quick, it shows only relevant information. AUR provides ready made PKGBUILDs.

Lots of Linux distributions is its strength. It allows people with niche requirements find its home. We are far better members of societies when supporting our system than grunting.

[1] https://www.archlinux.org/

[2] https://voidlinux.org/

[3] https://alpinelinux.org/

> Lots of Linux distributions is its strength.

Unless you want to ship something, troubleshoot something, or figure out how something works without hours of googling.

> Unless you want to ship something

I have never had problems distributing binary builds for Linux. There are a number of system libraries that are backwards compatible: glibc, asound, libGL, etc. - test on the oldest you want to support and any other libs you just ship yourself. And that would not be different with only one distro either unless you only care about one release of that distro.

Would you better not able to solve at all?

Ship and troubleshoot solved by distro maintaires. Niche products solved by Flatpak and its runtimes.

I'll stick with platforms that don't require third party volunteer maintainers just to be able to run software, thanks.

See, you have choice and enjoy it. So do I.

What I find strange is sitting on the place one does not like. There are so many choices around.

A bit of poking suggests:

1) I'm not ready to jump installed systems to arch right now.

2) Next system I install will probably try arch.

Thank you!

> Arch Linux [1], Void Linux [2], Alpine Linux [3]

Gentoo is feeling left out. It's the OG distro for those who have strong opinions on how their system sould work but not strong enough to do eveything by hand.

wegs reminded me experience with Ubuntu. I've started with GNOME, tried XFCE, Openbox, system become brittle and it raised questions like "How to configure WiFi without DE?".

I've switched to Arch Linux, base install covers network configuration. It gave me stable platform, I can grow my knowledge, I can fix my system.

Void Linux and Alpine Linux are just examples of what could match voiced concerns. I lot of people recommend Manjaro, looks like a simple way to try Arch based distro. Some problems stem from upgrading release, Debian Testing could help. But I have not tried them.

I've tried Ubuntu, I don't like distribution upgrades, default theme, constant experiments on users. Gentoo is my first distro, as C++ dev at that time, compilation was fascinating. I still enjoy 3 commands joke [1], looks like it is possible to install binary packages these days. I've tried Alpine, I don't like apk, systemd and glibc are good enough for me. I've tried OpenBSD, hardware support was not as good as on Linux. I'm playing with NixOS but I am so used to Arch.

And I want to stress, each of these system has something I enjoy. It is just me who is driven by minimizing negative points.

[1] http://bash.org/?464385

> As a footnote, ALSA was just about the last time this happened right, with it replacing OSS while maintaining compatibility.

Nah, even ALSA was a needless overcomplicated mess. They should have just built on top of the super simple /dev/dsp. Instead we got new incompatible APIs wile OSS apps were left with requiring exclusive access to your sound card.

i agree with your point. however alsa needed a multiplexing layer, or the equivalent. whereas pulse was the answer i don't know.

> alsa needed a multiplexing layer

It had dmix.

I think you would enjoy OpenBSD.

Computers aren't things I enjoy. They're things I stomach. I think I'd use OpenBSD if I were confident that after setting it up, it worked reliably, without changes, for the next few decades, with transparent system upgrades.

Part of that is working Bluetooth, power management, webcams, video conferencing, OBS, and similar. Historically, OpenBSD was behind Linux on working reliably.

Debian used to do this before:

1) It fell behind on hardware support, as laptops took over desktops; and

2) Ubuntu/Fedora started putting out massive numbers of half-baked technologies, and everything building atop those.

I switched to Ubuntu, without Gnome, but increasingly, things don't work without Ubuntu's UX, and snap shows a future I don't want to head down anymore.

I'll look into arch linux, as someone suggested.

Fair enough.

Webcams and power management work fine on OpenBSD (assuming there exist drivers for your hardware), but Bluetooth isn’t supported at all.

What I like about it is the simplicity of everything. If you want to change your mouse sensitivity, you add a line to a particular file in /etc. If you want to autojoin a particular WiFi network, you add the SSID and password to a particular file in /etc. If you want to start a daemon on boot... you get the idea. No massive complex configuration systems with giant blobs of XML that nobody understands.

Unfortunately the flip side is that things move more slowly — they won’t support Bluetooth until someone writes code that meets the system’s bar for correctness, simplicity, reliability, documentation, etc. — which might be never. But the stuff that does work is fantastic.

If hardware/software support requirements tie you to more mainstream OSs, I do agree with other posters that Arch is the closest thing to what you want, but it’s still far from perfect.

On that list, I can live without Bluetooth.

Do you know if:

1) Zoom works? Linux has a blob which does.

2) OBS works? This is critical.

3) How is video support with ATI/Nvidia? Will my multimonitor setup break?

The other thing which scares me is the manual upgrade process. On my systems, I've done apt-get update/dist-upgrade for a quarter century now, with never an issue.

1) There isn’t a standalone binary, but you might be able to get the web client working in Chromium. I’m not sure.

2) I don’t know.

3) AFAIK it should work.

Using the BSDs as a workstation, rather than a server, is a bit niche. Like Linux, but even more so. So unfortunately it’s still a labor of love and a lot of modern stuff won’t be supported.

Especially in the Linux world where not asking too much of their own PC is seen as a virtue, so people are running tiling WMs from the nineties, spend their time in Emacs and say everything is fine.

Meanwhile I want my Linux system to run VR, multiple 4K displays, very demanding games and bluetooth headphones. And Linux is the worst for it, because everything feels laggy and half polished there and on the proprietary OS my setup feels MUCH faster.

Sure, it's not Linux's fault, but let's stop saying everything is fine and dandy because Emacs is still running.

No one is saying everything is fine. It's not.

What we're arguing is why everything is not fine.

SGIs ran VR, multiple displays, and very demanding apps in the nineties too. They did all sorts of wonky, complex, 3d input devices too. So did DEC Alphas. This is the stuff Unix was built for.

My claim is that nineties Linux was much closer to having the right architecture for it than 2020 Linux for this sort of stuff. The reinventions and onion layers didn't help; they hurt.

I think the only piece nineties Linux didn't anticipate was the level of hot-swapping hardware (USB, Bluetooth, displays, etc.), and the level of power management. Modern Linux never got that architected or integrated quite right, because it was built with hack upon hack upon kludge. It's split up in bizarre ways between kernel and user space which would be really tough to clean up right now.

> think the only piece nineties Linux didn't anticipate was the level of hot-swapping hardware

They did, modular kernels date back as 2.2 at least. And USB was born in that era.

If this was anticipated by the architecture:

* My USB webcams wouldn't show up in a different order each time I reboot. This works fine under Windows and Mac.

* My monitor configuration wouldn't be hardcoded in my xorg config file, or swapped around manually with xrandr. I'd have a way to code up config options for whatever is plugged in, and if something unanticipated happens, it'd do something reasonable until I coded that config in too.

* I wouldn't need to reconfigure my drawing tablet to connect to the right monitor each time I plug it in.

* The system wouldn't get into an unrecoverable, unstable state with e.g. an unreliable USB cable.

.. and so on. It's designed for a fixed set of hardware, with layers on top of that to support hotswapping. I don't have "USB 4k Logitech Webcam" on the native level. I have /dev/video3. I then have layers to map names back.

Same thing with HDDs too, actually. I refer to them as /dev/sdc4, rather than by a GUID or name or similar. Layers with onions.

You've described need for UUID but then discard it for disks, why?

    $ ls /dev/disk/by-uuid/
    266c945c-1c6d-40e7-b770-73864a5541fa

    $ cat /etc/fstab 
    UUID=266c945c-1c6d-40e7-b770-73864a5541fa       /

Mostly, because as of 2020, most things don't use UUIDs. See e.g.

1) https://www.raspberrypi.org/documentation/installation/insta...

2) man fdisk

3) man mkfs

And so on. The /dev/sd_ is primary, with UUIDs as kind of an afterthought

It ought to be the other way around, with UUIDs as the primary, proper, canonical name and interface, and a legacy backwards-compatibility layer for /dev/sd_ devices. It's even reflected in the directory structure. Yes, I CAN list disk "by-uuid," label, id, partuuid, or path, but those are special cases with sd_ as canonical.

It's kinda retrokludged in there. I never said USB/etc. didn't work. Just that it wasn't architected for it.

> Unix was really well-designed,

Not really, it is just a pile of hacks on top of hacks, starting by everything is a file until one needs to use sockets.

Unix is what you get by usually applying the "worse is better" philosophy.

And having free source code available on tapes for universities, without which would never taken off.

what isn't a pile of hacks?

unix sockets are files

Try to open() a socket.

I've heard enlightenment can be a Wayland compositor now, could you try it?

Also I think 3dfx Voodoo was the magic pixie dust, once you ever go OpenGL, you're not going back.

A developer sharing is experience working with EFL:

https://what.thedailywtf.com/topic/15001/enlightened

It sounds like the guy is way overexaggerating and basically didn't understand the library he was working with. What he describes isn't anything special - the "Evas_Object" (aside of the weird name) sounds like a HWND in Windows or Window in X. The part about layouts sounds like similar to sizers in wxWidgets which are used so that you can avoid using heavyweight native widgets just for layout that some other toolkits do. The event callback sounds like it uses a generic messaging system - again not much different than something like WndProc in Windows.

EFL is written in C so it does have to work within the limitations of C but -non-toy- GUIs are inherently object oriented so things will be a bit more complicated than Qt that can lean on C++'s support for object oriented programming. Especially since apparently EFL also supports bindings to other languages which may also make things a bit more complicated.

It definitely struck a cord when I had have to use it in a project around five years ago.

Luckily I got an opportunity to a new project. And the company in question (Samsung) ultimately dropped it IIRC.

I ran Enlightement for maybe a month or two to try it. I mostly ran twm, fvwm, and similar at the time. Those are obviously not satisfactory for a typical user.

I gave it as an example of something which ran rather sophisticated theming/compositing/effects on hardware at least 2 orders of magnitude slower than today, and something which modern Ubuntu/Fedora struggle with.

I'd encourage you to compare the specs of the 3dfx Voodoo (the "magic dust") to even bottom-barrel integrated graphics of 2020.

the buck is passed onto the compositor. so sway is fast, kde might be slow (or janky). it's not as uniform as with X/window manager.

I don't know that Wayland is slow, but Gnome was. They fixed several big performance problems recently.