Comment by Blikkentrekker
1 day ago
> It is the fundamental difference in the developer's origin/experience in FOSS projects vs commercial software. However, there is an even bigger paradigm difference underneath. Academia survives on one-off projects and FOSS is often recruits students in universities who contribute as hobby, without contracts. The usual POSIX software is all about exposing things with minimal abstractions. It makes developing and iterating on software easier on the developer.
I think it's just the fundamental mentality of the kind of people it recruits and it wasn't always the case either. It felt like the old Unix guard of people who worked at Bell Labs were far better adjusted. If anything, this feels more like a social thing because you just encounter these kinds of people a lot outside of programming on say Reddit or 4chan, as in people who just completely seem to miss what goes on outside of their little bubble and I do feel certain types of FOSS have a higher chance of recruiting those people because they were the people who used to first submit patches for free on github and then rose the ranks. This does not in any way occur with say people being paid by Intel to write drivers for Linux. They seem to know perfectly well what goes on with the world because they weren't recruited through those channels that are just more likely to attract, shall we call it “terminally online” people as the kids call it nowadays?
> To illustrate the difference I'll actually compare Win32 vs X11/Wayland. Win32 is a much better abstraction and much better "narrow waist" point than X11 was. X11 was designed tightly around 80's hardware and people had to add hacks on top of hacks to actually make things like GPUs work. X11's network transparent architecture actually made implementing direct rendering harder. While Win32 already had some ideas that made into Wayland and it designed nice abstractions for allocating windows, direct rendering buffers and compositing. Win32 had baked in concepts like a window or a button or text rendering. So when the devices with HighDPI appeared or when new security boundaries needed the higher level abstractions of Win32 made it possible for Microsoft to make smaller API changes while the whole X11 started to collapse with 90s hardware and then was useless for 2010s.
Even ignoring the future though. It's just the understanding of the “now”. Things like initially libinput having no way to disable mouse acceleration and the developer at first resisting it until receiving a mountain of complaints and finally relenting because “Everyone would want mouse acceleration always on, right?”. Or just in general how these people seem to completely forget that desktop usage is largely just an afterthought for Linux and the main usages are phones, servers, small devices and supercomputers. To them Linux is really just a desktop kernel and they completely don't seem to realize that desktop usage of it is really super inconsequential in the larger scheme of things.
> Or just in general how these people seem to completely forget that desktop usage is largely just an afterthought for Linux and the main usages are phones, servers, small devices and supercomputers.
I think you're right in that most paid developers use/develop for Linux ecosystems do for server or embedded, where they use Linux out of "laziness" since it provides a basics. Then the engineering team implements everything else GUI, webservers etc on top of it. At work I'm a firmware engineer but I can also write quite complex Linux stuff and I occasionally contribute to the Yocto recipes. You really see that Linux ecosystem is really for people who prefer to dig stuff. Dig decade-old email threads, read C source the whole time. Fix and patch weird bugs and pile workaround on top of workaround by forking things. Linux ecosystem really isn't designed to scale to be deployed into wild-west PC universe and still lives in a "here is the source; good luck!" world.
> Even ignoring the future though. It's just the understanding of the “now”. Things like initially libinput having no way to disable mouse acceleration and the developer at first resisting it until receiving a mountain of complaints and finally relenting because “Everyone would want mouse acceleration always on, right?”.
I mean it can be argued where to split and keep libinput as the lower-level library for the embedded engineers (TBH I don't know if embedded engineers really care). However, what I don't understand is: if they are going to split things in a more granular way, why not provide a higher level library for DEs where functions for acceleration etc. are provided as extras.
At the same time, I have a hunch that GNOME could be the reason (AFAIK libinput dev is employed at RedHat with other GNOME devs) and GNOME likes things "lean" i.e. featureless. One of the reasons Wayland has completely surrendered window decoration and we have to use workarounds and hacks like XDG Decoration is GNOME's insistence on offloading everything to clients and vetoing every single compromise (including XDG Decoration, but Valve pushed it AFAIR).
Again I think designing Wayland as a "allocating rectangles on CPU or GPU buffers" protocol/library is okay. But why don't we have a unified higher level "Wayhill" where ex-GNOME DEs define things like what a decorated window is [^], what happens to the crashed application, unified resizing, actual display management and unified configuration so it can be shared with the login manager. Now KDE implements one thing, wl-roots implements another (wl-roots is probably closer to my "Wayhill" idea but it kind of caters to more terminal-driven stuff, I do prefer pure GUI-driven desktops) and GNOME just opposes everything.
I see this kind of "provide the lowest level abstraction, nothing else" as a paradigm in every single component in Linux. It is really tiring both as a desktop user and as a paid developer. Since it is a socio-technic concept, rather than a purely technical, I don't really see that we'll solve it with "more FOSS". The overall mindset needs to change or we need to bootstrap a new ecosystem (which is an uphill battle).
[^]: Yes Firefox and Chrome would look wacky (basically dual decorated) since they use some lower level GNOME/GTK stuff (file dialogs, cairo rendering etc, GTK themes/libadwaita), however this kind of push could have helped browsers to be more agnostic as well.