4 ms·

There's nothing vile about that, it's normal development practice. If you decide to make a code editor you're not making an app for artists, you're making an ap

There's nothing vile about that, it's normal development practice. If you decide to make a code editor you're not making an app for artists, you're making an app for developers. That's a conscious choice you make when you sat down and said "I'm going to make a code editor today." Unless you think it's stereotyping to consider that people have different skills and professions? Just think a little bit more about this in the context of your example. A user who isn't a Linux enthusiast or sysadmin isn't going to know anything about what /usr/share or /var/lib, etc is supposed to be. And a user who knows everything about that isn't going to need a fancy file manager to perform sysadmin tasks on those folders! They know how to do everything from the command line already.

int_19h 4y ago
This is a very weird dichotomy that doesn't actually work that way IRL. A power user is not necessarily a command line wizard, and even if they are, plenty of tasks are still easier and quicker to do in the GUI - provided, that is, that the GUI can actually be optimized for the needs of said power user. We used to be able to accommodate all kinds of users with customization; now it's increasingly the lowest common denominator (and often an imaginary one at that) with no escape hatch.
- QUrprUd1nCeicw 4y ago
  I actually think the reason for that is economic and it does work IRL. What you think of as "power users" actually requires a lot of training, it's expensive to produce them. Their skill set still isn't enough to offload real development tasks on them, so whatever they do is still completely dependent on having a team of engineers to support them. If you're going to be paying the engineers anyway, it's cheaper to just make something that requires less training for the users up front.
- pxc 4y ago
  Creating, testing, and updating documentation for command line tools takes a tiny fraction of the time and effort required to do the same for GUI tools. At the same time, the command line across Linux distros is subject to way less variation than all the GUIs across the same. Moreover, the fundamentals of the shell and the syntax of the CLI tools are way more stable over time than a given GUI configurator's layout, so CLI documentation will remain correct and useful longer than GUI documentation. Add to that that for many Google-able tasks, the same task may be relevant to headless servers, and you have another, independent cause for CLI documentation to be created without a GUI counterpart and for it to show up highly in search results. This means that most documentation for advanced tasks in a volunteer-maintained system where everything actually has configurability via the CLI will tend to cover and emphasize CLI methods. It is arguably possible to have knowledgeable 'power users' who do not know how to use an operating system's CLI. Longtime Windows users probably fit the bill. But on Linux, nobody who has spent enough time actually reading documentation or following tutorials (and made a reasonable effort to understand them) to become a power user is actually unable to use the CLI. The CLI-averse power user just doesn't exist on Linux due to a bit of a chicken-and-egg issue. PS: The only system directory tree users should ever 'administer' on Linux by directly manipulating files in it is /etc. The grasp of the CLI needed for this is extremely basic, and there are even nice CUA text editors for the terminal these days. There's no wizardry required to do anything that isn't as destructive or risky as confusing the operating system itself (namely the package manager) about the state of the filesystem.

int_19h 4y ago

This is a very weird dichotomy that doesn't actually work that way IRL. A power user is not necessarily a command line wizard, and even if they are, plenty of tasks are still easier and quicker to do in the GUI - provided, that is, that the GUI can actually be optimized for the needs of said power user. We used to be able to accommodate all kinds of users with customization; now it's increasingly the lowest common denominator (and often an imaginary one at that) with no escape hatch.

QUrprUd1nCeicw 4y ago
I actually think the reason for that is economic and it does work IRL. What you think of as "power users" actually requires a lot of training, it's expensive to produce them. Their skill set still isn't enough to offload real development tasks on them, so whatever they do is still completely dependent on having a team of engineers to support them. If you're going to be paying the engineers anyway, it's cheaper to just make something that requires less training for the users up front.
pxc 4y ago
Creating, testing, and updating documentation for command line tools takes a tiny fraction of the time and effort required to do the same for GUI tools. At the same time, the command line across Linux distros is subject to way less variation than all the GUIs across the same. Moreover, the fundamentals of the shell and the syntax of the CLI tools are way more stable over time than a given GUI configurator's layout, so CLI documentation will remain correct and useful longer than GUI documentation. Add to that that for many Google-able tasks, the same task may be relevant to headless servers, and you have another, independent cause for CLI documentation to be created without a GUI counterpart and for it to show up highly in search results. This means that most documentation for advanced tasks in a volunteer-maintained system where everything actually has configurability via the CLI will tend to cover and emphasize CLI methods. It is arguably possible to have knowledgeable 'power users' who do not know how to use an operating system's CLI. Longtime Windows users probably fit the bill. But on Linux, nobody who has spent enough time actually reading documentation or following tutorials (and made a reasonable effort to understand them) to become a power user is actually unable to use the CLI. The CLI-averse power user just doesn't exist on Linux due to a bit of a chicken-and-egg issue. PS: The only system directory tree users should ever 'administer' on Linux by directly manipulating files in it is /etc. The grasp of the CLI needed for this is extremely basic, and there are even nice CUA text editors for the terminal these days. There's no wizardry required to do anything that isn't as destructive or risky as confusing the operating system itself (namely the package manager) about the state of the filesystem.