I cannot shake off the feeling that the core developers standing behind systemd, pulseaudio, Gnome desktop spend a lot of time using macOS, and like it better than Linux.
This would explain why they imitate or copy many of its features (and misfeatures), and seemingly tend to replace the Unix ways with entirely different approaches. Effectively forcing things on users, as it was with pulseaudio and systemd, is also a very macOS thing to do.
I'm not opposed to replacing Unix with different approaches, as long as they keep playing on its key strengths, and do not remove modularity and composability. That is, Plan 9 is fine with me. Much of what Red Hat does, sadly, no.
I've heard this a lot, but having used Gnome briefly and MacOS fairly extensively, I just don't see it. Also, have you seen KDE's Dolphin? If ever there was a Finder clone, it's Dolphin. With regards to copying MacOS, Dolphin devs have wiped the floor clean with Gnome.
Besides Dolphin specifically, KDE in general is flexible enough that making it look and feel like MacOS is pretty easy. Gnome though? It's not particularly MacOS-y by default, and Gnome devs have naked contempt for customization, so good luck if you want to try anyway.
However, I share your suspicion that most Gnome developers do not actually use Gnome as their daily driver.
Yes, that naked contempt to customization is what I find more macOS-y than any exact copy of the visuals. KDE in this regard is pretty safe: you can bend and shape it to taste pretty thoroughly.
Interestingly, classic MacOS, at the times of 6.5 or 7, was somehow more customizable, and seemed to have more power-user features. Just like, well, Gnome back in the day %)
Interesting that you found Dolphin to be a Finder clone. It may well be, I just didn't see it besides some superficial UI similarities.
I think Dolphin is one of the very best Linux apps out there while I found Finder to be very clunky, often so unintuitive and useless that I resorted to command line instead. To be honest, it would probably have been fine if I took the time to learn the Mac idiosyncrasies like missing cut/paste, but Finder was one of my main gripes when I had to use Mac for work.
To be frank I find both Finder and Dolphin to be generally unsatisfactory. Finder is worse though, it's riddled with bugs and weird shit. I could never get Finder to show preview thumbnails of symlinks pointed to files on network mounts (while the Dock's folder view could always thumbnail those same symlinks just fine.) Or, when you mount a network drive, Finder can take dozens of seconds to recognize the mount has succeeded, while in a terminal next to finder you can clearly see it succeeded instantly. In Finder, thumbnailing sometimes breaks and completely stops working, with no indication of why. `qlmanage -r` usually fixes it, but what is the point of using macos if I have to waste my time fixing janky shit in a terminal? It's worse than the modern linux desktop experience.
Dolphin just has weird omissions; for instance try to sort a directory of symlinks by the time those symlinks were created. As far as I can tell, you can't do this because Dolphin follows the links and sorts by the dates of targets (contrast with `ls -ltr` and Finder, which sort by the dates of the links.)
Gnome is one of the most customizable DEs around. You can customize almost every aspect of it via the extension mechanism. I'm even running a full tiling WM right now that is coded as a Gnome extension (PaperWM).
The customization in the desktop of GNOME itself is still there, but it has mostly moved to shell extensions. If you're willing to deal with that, you can change quite a bit of functionality.
The apps are a different story, those tend not to go for a lot of customization and will usually just focus on optimizing for one or two use cases. If you have other use cases, the suggestion there would probably be to make a separate app.
GNOME would be fine and was fine up until the attempt at tablet integration happened, and it's been total chaos since then.
The problem is they hopped aboard the same bandwagon Microsoft did with Windows 8, where every started throwing tablet/touch style UI onto desktop interfaces.
For the life of me, I don't understand why there wasn't a happy middle ground of "or we'll render the main menu as a regular menu bar".
But at this point it's not a GNOME criticism so much as an entire UI/UX industry criticism.
This is a common thing I hear but it's not true. The hamburger menus were done to save space and reduce clutter, not out of any desire to be a tablet app. I sympathize with your criticism but it wasn't done for that purpose, it's just a coincidence. Also I should note, there are many non-tablet laptops that happen to have touch screens. These are not exactly rare these days, and AFAIK that was also a hardware segment that Microsoft was targeting, not just tablets. They weren't just making touch interfaces to sell the odd Surface or two. Sadly I don't know of any more elegant solution to this than what they're already doing, apps that want to work well here always have to straddle an awkward line where they have to support both traditional mouse and keyboard operation, as well as touch screens, at the same time. It's not an easy thing to design apps for.
To actually make good native touch/tablet apps in GNOME, you need to use a separate library called libhandy (renamed libadwaita for GTK4), and the app needs to be designed in a different way. You can usually tell the difference with an app made specifically for touch screens because it will totally de-emphasize the keyboard and mouse. I see more and more of these type of apps but only in the last couple of years, and it's mostly not to target tablets but to target the new open source phones e.g. Librem, Pinephone, etc.
>The hamburger menus were done to save space and reduce clutter, not out of any desire to be a tablet app.
"Save space"? That's a laugh. Reducing clutter is ill defined and probably subjective, but saving space? Saving it for what? The default window decorations, widgets, etc are bloated, not slim and compact (as they would be, if they were saving space.) Everything has huge margins, big buttons, and empty voids. "Saving space" is not a principle Gnome cares about.
Do you know what huge margins and big buttons are actually good for? Touchscreen interfaces designed for fat fingering. That's what Gnome cares about.
Again, what you are saying is not correct. You may be comparing their designs to other apps developed for other desktops using other toolkits, but that's not what is influencing GNOME. The space is saved compared to previous designs that were used by GNOME. Please consider comparing an old style GTK app with a new style GTK app:
The old style has four bars at the top (titlebar, menubar, toolbar, secondary toolbar). The new style merges them all into one bar and moves the menus into the hamburger menu. The margins may be bigger in the new style but ultimately, space is saved and the UI chrome is reduced. Also, GNOME Builder is not an application designed totally around touch screens -- it's a text editor, for typing into.
I sympathize if you don't like this style of app (and I encourage you to use different apps if you were used to having a lot of menus and toolbars, and you don't like the new style of GNOME apps), but what you are saying about the design goals and motivations does not match what the developers are actually doing.
If plan 9 is what you want, I would encourage you to use 9front. I can't see why you would use Linux if you didn't like Red Hat, they have been a key contributor in Linux land for a long time, employing many long-time kernel developers.
I'm not sure if 9front can be a daily driver yet; say, it does not seem to be able to run Emacs. Would be nice though.
Not that I don't like Red Hat. They are the poster child of a successful open-source company, and did and keep doing a ton of great things. I only don't like certain directions of development of certain userspace things which happen to be done under their corporate umbrella. These things, systemd in particular, were quite noticeable on the Linux landscape as of recently, both in the tiny desktop niche, and the huge server sector. Nobody's perfect, you know.
I have to say, that seems like a strange requirement: I have never really considered Emacs (or Lisp) to be particularly Unix-like at all! I think the plan 9 people would probably tell you to ditch Emacs and use acme (Me personally, I say use whatever you want).
Emacs inside is very unixy, under a particular angle. Everything is a list, a ton of small composable functions doing one thing well, one common language that unifies all key interfaces, and the general lack of a predefined final construction, but rather a bucket of Lego blocks around a kernel which does the heavy lifting.
Acme us interesting, but pretty different; its automation is apparently written in the shell language using normal OS commands. AFAICT the Plan 9 shell lacks structured data types comparable to Lisp's: it has lists, but not nested lists, so such constructs are a bit less robust. Also, AFAICT, Acme actively wants mouse operations; I hope reasonable keyboard equivalents exist.
I'll explore more of it in my copious free time (sigh).
Having a lot of small composable functions and a lot of singly linked lists describes most functional programming languages though. I think that's only one part of the traditional Unix design. Though to me it was always seemed like the inspiration goes the opposite way -- it seems like Unix was in some ways designed as a "Lisp-like," where the shell works as a somewhat restricted version of functional programming that only operates on one data type.
This would explain why they imitate or copy many of its features (and misfeatures), and seemingly tend to replace the Unix ways with entirely different approaches. Effectively forcing things on users, as it was with pulseaudio and systemd, is also a very macOS thing to do.
I'm not opposed to replacing Unix with different approaches, as long as they keep playing on its key strengths, and do not remove modularity and composability. That is, Plan 9 is fine with me. Much of what Red Hat does, sadly, no.