Context: I've been using linux for 20 years, and do currently at my job. "Linux has many, fully flexible user interfaces that can be customized however you like." feels like a "you're holding it wrong", or "chose the wrong distro".
I don't want to go into the details, but I regularly experience UX problems in Ubuntu. Even things like reading/writing a USB port requires sudo, or editing system config files, which is wild to me. And adding a trailing newline to the config file in question will prevent your GUI from booting. Adding an item to the PATH is a combo of unintuitive, or filled with incorrect instructions (Including Go's home page CAO yesterday...).
Or, software I write can't be launched without using having the user go to the CLI, or creating a GUI-specific config file and placing it in a certain location. This leads to the line I hear regularly "You should publish your software on the distro-specific app store", or "You should only install software from the app store". Which immediately leads me to think I have a use-case mismatch.
> I don't want to go into the details, but I regularly experience UX problems in Ubuntu. Even things like reading/writing a USB port requires sudo, or editing system config files, which is wild to me. And adding a trailing newline to the config file in question will prevent your GUI from booting. Adding an item to the PATH is a combo of unintuitive, or filled with incorrect instructions (Including Go's home page CAO yesterday...).
None of this sounds like anything I've experienced, or heard described, in 3 years of using the Ubuntu-derived Mint.
> Or, software I write can't be launched without using having the user go to the CLI, or creating a GUI-specific config file and placing it in a certain location.
How exactly are you distributing it? If the problem is e.g. that your users download an AppImage and it isn't executable, they can most likely change the permissions from the GUI. I don't know what you mean about GUI-specific config files. I had thought that https://specifications.freedesktop.org/desktop-entry-spec/la... was pretty widely recognized.
Distros don't generally have "app stores" but rather package repositories, modulo branding. Publishing there isn't about making your launcher work; it's about letting the system handle dependencies and letting the distro maintainers patch (and build trust in) your code.
To launch an executable in windows, you double click the icon in the GUI. To launch the same programmed compiled for Linux, you can't always do that depending on the distro's GUI layer. What you do in Gnome, for example, is create a .Desktop file, and place it in a certain location. Then it will show in your quick launch.
> None of this sounds like anything I've experienced, or heard described, in 3 years of using the Ubuntu-derived Mint.
To be more specific on those anecdotes I mentioned due to having hit them recently:
- Create an embedded device that talks to a PC over USB-serial. (Here you are not constrained to the whims of a GPOS! RTOSs are a dream in comparison, or forego entirely and use bare metal)
- Write PC software that talks to it (gets data from sensors etc)
- Try to run the program without Sudo on Linux. The USB won't work unless. I've heard the justification for this is that the USB might be a storage device, and storage devices should be restricted by the OS etc.
The PATH (and other environment-vars) in Linux are shell-specific. You regularly read instructions (I saw this in Go's official instructions yesterday) indicating to use the EXPORT command. This only works until you reboot; you have to hand-edit a sudo-protected file (bashrc, .profile etc), and there's a learning curve to it. I don't remember the details, but I've screwed it up multiple times.
> The PATH (and other environment-vars) in Linux are shell-specific.
PATH works the same way in Bash, sh, zsh etc. etc. Various shells do offer some additional ways to manipulate environment variables, but you can rely on things like export.
If you meant "specific to a shell process", then yes:
> You regularly read instructions (I saw this in Go's official instructions yesterday) indicating to use the EXPORT command. This only works until you reboot
See https://stackoverflow.com/questions/1158091 . The export command is essential. But of course settings that persist between sessions, between reboots etc. will be stored in a file. How else could it work? The point is that you aren't forced to use a GUI and you can examine the file as plain text and comprehend it.
> you have to hand-edit a sudo-protected file (bashrc, .profile etc), and there's a learning curve to it.
It's only root-owned (what I guess you mean by "sudo-protected") if it's system-wide. Per-user settings only require that user's rights, exactly as one would expect. That's not different from having to be an admin user on Windows to change system environment variables. Most of these config files are actually auto-run scripts, and understanding the system is an important part of familiarizing yourself with Linux as a developer. Trust me, Bash is much more pleasant to program in than Windows Batch files.
> I don't remember the details, but I've screwed it up multiple times.
If you want a wrapper for the process, it's not hard to make one if you can't already find one. It's strange to me how many developers don't seem to have any interest in building or customizing their own toolchain.
I suspect I understand our disconnect! I am looking at the GPOS as a tool for scheduling, driver interfaces, providing threads, and a GUI etc. I want it to get out of the way and let me run software. It's not something I'm intrinsically interested in, or want to tinker with, or config in a way that lets me break it.
We choose which things we want to tinker with and improve, and which we would like to use as-is for that and other goals. For me, the OS is in the latter category.
I'm afraid I don't understand why you see the things that you do as "tinkering". To me, automation is just what you do with a computer (and operating with plain text files makes that much easier than being forced through GUIs for everything), and before you can do that you need to figure out what you find annoying enough to automate.
Got it, but those are more Ubuntu specific qualms that you have, not arguments against Linux in general.
I use NixOS and I don't have UX problems because my UX is fully customized to work exactly how I want.
Plus, for every but of friction you may experience in Linix, the cons of Microsoft are much greater. They have no concern for your privacy, and exploit their workers and the environment.
Last time I used Microsoft (~8 years ago) I couldn't get that malware OS to stop forcefully suggesting and using their cloud services automatically.
There are many things that MS does that are just unacceptable.
I don't think that would be enough: adding those people to a team won't matter if the overall vision isn't there.
It needs, and I'm about to choke on my words here, a Steve Jobs at the helm saying "No, it needs to be like this".
Yes, I know that won't achieve perfection but there needs to be a coherent vision of what the OS is trying to be, or who it is aiming for.
Linux, right now is pure techie-driven. There isn't any vision at all! Every distro is subtly different and reflects the wants of the team that work on it.
It needs a company to take a distro and pick a direction, e.g. Linux for normies would have to remove almost all traces of command line, hard disk partitions, configs, package managers etc. All that shit would have to be hidden away, still in the background and available if wanted, but to use the OS it should not be a requirement.
> Now do the same in Windows. Messing with system files, without knowing what you are doing, is a recipe to disaster.
I think I didn't communicate something clearly: My concern isn't that misediting a system file causes disaster. It's that you need to edit system files to do routine things.
On Windows, the solution is simple: USB/serial works without editing system files or requiring launching the program via CLI with sudo. You double-click the program in GUI, and it works.
I don't want to go into the details, but I regularly experience UX problems in Ubuntu. Even things like reading/writing a USB port requires sudo, or editing system config files, which is wild to me. And adding a trailing newline to the config file in question will prevent your GUI from booting. Adding an item to the PATH is a combo of unintuitive, or filled with incorrect instructions (Including Go's home page CAO yesterday...).
Or, software I write can't be launched without using having the user go to the CLI, or creating a GUI-specific config file and placing it in a certain location. This leads to the line I hear regularly "You should publish your software on the distro-specific app store", or "You should only install software from the app store". Which immediately leads me to think I have a use-case mismatch.