>For example, I prefer to do package management from the command line, but if I'm editing partitions, I feel the urge to use a GUI like Disk Utility or gparted. For this task, GUIs feel safer for a few reasons. I feel like I can better visualize the changes being made to the drive, and it seems like there are more speed bumps to prevent dumb mistakes.
cfdisk, cgdisk.
Maybe you are afraid of parted/fdisk. Then you are right.
But well, fdisk and such are a bit "nightmarish". I had more luck using OpenBSD's disklabel to slice up it's own partitions. And the GPT editor from OpenBSD (I can't remember it's name) was pretty simple to use and preview even on text mode.
You can have both good and bad CLI/TUI's, and even horrendous GUI's, such as the Red Hat installer.
So partitioning a device is less risky with a GUI? That doesn't make sense.
EDIT: I should be more constructive:
I know that the command line scares some people, but that's just like computers in general scare most people, it's just something you have to get over with.
Another "scary" thing is the choice that exists between multiple available partitioning tools, I know it took me some time before I decided that the good old fdisk was my choice, but really, it probably doesn't matter, any should be OK. You probably won't actually do it directly from the command line anyway, e.g. fdisk is dialog driven instead.
Lastly, I doubt that it isn't possible to fire up Xorg from the Gentoo install media and then partition from a GUI tool, if that's what you want.
> Given all these great options, it's not clear to me why anyone would go back to a separate GUI tool?
You're clearly a Linux person. Or at least a command line person. I am too. Quite a few programmers at my work have never used anything but Windows and barely touch any servers. So they don't really use the command line at all, ever.
They also insist on using graphical clients for Git. This is of course horribly inefficient and leads to plenty of problems (mostly due to their choice of the Eclipse Git Client, which seems to have a lot of bugs). But they think the command line is scary and too difficult to understand.
So, my point is, there are a lot of people who have used GUIs their entire life and are used to be able to figure things out by just staring at the GUI and spending 30 minutes aimlessly clicking about. Then when they use a CLI program they have no idea what to do, and get frustrated. Because they're not used to RTFM.
> I can't imagine how Windows devs who don't know Unix can get around easily. They seem to though.
It's simple, for filesystem operations most Windows people don't use CLI.
I use Total Commander for example, which has tabs and bookmarks to quickly navigate around the filesystem.
> You don't need to memorize lots and lots of command line options.
But instead, the keyboard shortcuts for the file manager.
> Bookmarking directories (local and remote), although there are command line ways to do this.
For example zoxide. And depending on the usage pattern, it might turn out more flexible and easier to interconnect with other things.
> Say you have a directory of 100 files, and you want to copy about 15 of them elsewhere.
What is your typical use case for doing this?
I can quickly think of two situations where I needed to do that:
One I was copying a selection of photos for my uncle to a folder which I was going to burn on a CD. I am right now not sure whether his laptop still has a CD drive.
The other was I was developing some windows library and I needed to make a zip package for other people to test it, because there was still no installer.
I think I am not that unusual that generally I try to avoid making copies of the same data to different places; I try to use version control instead.
> Is it better to make up common rsync “recipes” for people to use, or is it better to let folks have access to ALL of the flags [...] and pick’n’mix what they want?
I think both. This is the hard part about GUI design -- it is pretty easy to make a list of 100 command-line options listed alphabetically on the man page, but for GUIs, people expect much more.
There should be some sort of logical grouping. One area of the screen would be options related to what is transferred, a second area is metadata, the third one is speed-only optimizations, fourth is logging and so on. Having "hardlinks" all the way on the left and "symlinks" all the way on the right does not make a good GUI.
There is a very wide variety of input elements, so checkboxes are are not the right solution all the time! For example, while having separate "--verbose" and "--quiet" options is fine for CLI, one would expect to see a drop-down or a slider in the GUI. This will decrease cognitive load because there are less things to read and there is no need to worry what happens if you check both.
Another great GUI feature is dynamicity -- take the metadata for example. A good design might have a dropdown: "everything", "nothing", "x-bit only", "custom". Most of the time, first three options would be fine, but "custom" will show entire new group of checkboxes.
... this was just my subjective design, based on how I use the program. If I were trying to do a popular product, I'd have to spend some time asking people / looking at the forums to determine which sets of features do people use. For all that I know, there is a super common case for "--group" without "--owner", and this is just me not knowing about it.
> why are your file systems sensitive to disk drives?
A couple of systems I have at home have a 16GB primary disk, so it is useful to be able to put things on an external disk. I have yet to see any package manager that can actually handle that.
> Use a layer (or more) of indirection through LVM and RAID...
Yeah, that's a great idea, just introduce more complication and abstraction to make up for a shortcoming in how Linux developers think about applications.
Or, just have your programs be self contained in a single file or folder and put them wherever it makes sense.
> Speaking as a windows-familiar but nerdy/techy guy, command lines are nowhere as good.
I mean, speaking as someone working on windows nearly every day, I hate GUI/its GUI. Every single "gui" app is some trash that I wish there were just some cmd line for (and I've been doing this sort of thing for over 10 years, its not lack of familiarity).
There are things I want/find lacking in cmd line, to be sure, but they're generally nothing that a better cli interface/script/wiki can't solve better.
> I find the idea of having a file system full of links in it a bit odd
I used to be a Mac user. Everything stored settings in resource forks and binary. When I moved to Windows, it was weird to have a registry for most things and some things used .ini files that were more useful. It was nice to have user-readable settings even if they were in obscure places and directories.
When I moved to Linux, dotfiles all made a whole lot more sense.
I've helped others learn how to Linux. Windows hides a lot of things in order to make the user experience idiot-friendly. I've had to un-teach them the crap that Windows teaches them.
> what do you mean you wanted to install applications to an external disk?
Kinda illustrates my point about this being a foreign concept to Linux Desktop people. It's pretty simple: I want to put an application on an external disk and run it from there.
> if you have a separate OS on the external drive, you could chroot in and install it.
No thanks. I'd just like to have the application stored on an external disk, and execute it on the OS I have installed.
> If you just want that one application to be on the other disk, you could mount it to wherever on the filesystem the program would be installed.
Not really, because Linux likes to have an application spread its files all over the hierarchy, so in reality I need to either use some form of union-mounting, and/or simlinks. Of course that is only sufficient if there are no library conflicts between what the application wants and what the system uses, in that case I need to use LD_LIBRARY_PATH and other tricks. In some cases I'll need to use a launch script that calls a different ld.so.
That's a lot of hoops compared to how sane operating systems do it.
> LVM to share disk space between the disks
System breaks when disk is removed. No good.
> Flatpak, Snap, Appimage and other portable format aren't really preferable. they lead to a software ecosystem that amounts to just downloading and running executable binaries off the internet, each with their own overhead.
Which is pretty much what I want, because the alternative is dealing with the bullshit I mentioned above whenever you step outside the package manager's sandbox.
> Everything for a common person should be easily accessible via a gui.
They are. Just there are many different GUIs. Each distro by definition has different ones and you can easily change them yourself etc.
There are dozens of sound GUIs, hell, I've tried 4 redshift GUIs before settling on QRedshift. It's so easy to write software for Linux that you have countless opportunities. That's why the command line is easier - it always works(ish).
>I loved developing all kinds of command line and UI tools for Windows, so I might be a little biased, but I found the Linux equivalents..well..not as easy and straightforward to say the least.
Well, I think very often commands have very not intuitive names of parameters, very often some seemingly random letters
When it comes to me,
I use Linux for server related stuff, hosting my things and stuff, also I like raw terminal Linux because there's nothing happening, so no distractions
> I disagree on not using the cli for installing things
I think that it depends on who the target audience is. For myself, I heavily prefer the command line for literally everything. But if the goal is for Linux on desktop to be beginner/non-power-user friendly then I agree with the parent comment that you should be able to do everything without opening the CLI.
For me, I will always be happier with CLI tools. :)
> I guess maybe because I started with computers before there were GUIs that is what felt normal.
For me, probably not. I did use DOS before Windows as a kid, but that was long before really learning to use a shell. Familiarity with DOS simply made me familiar enough with the idea to be unafraid of it.
When I learned to manage files, handle software, etc. I learned to do it with a GUI in Windows. When I started to use Linux, I was vaguely aware of the usefulness of a shell, and took the opportunity to really learn. To this day, I rarely even have a file manager installed, in favor of a shell environment.
> What do you do when you have to use a computer without your customization?
As someone who has used an increasingly customized *nix command-line environment for decades, I'll say that this corner-case occupies a vanishingly small amount of my time. I just doesn't make sense to optimize for it. I currently use zsh, which is frequently not available by default. This implies installing a package, and I don't see how that's any worse for fish. I freely admit that my workflow as a developer vs. (e.g.) a sysadmin provides a greater degree of relative control over my day-to-day working environments.
I do have to work in non-customized environments from time to time. I find this no worse than using Someone Else's Keyboard -- maybe there's some clumsiness at first, but you soon get the hang of it. If you switch environments frequently, the switch becomes unnoticeable.
That said, I've also put continual effort into portability and ease of deployment of my customizations over the years. I can run one command on a networked host and have my rcfiles land there and be ready to use. This is pretty easy to do with a git-managed homedir repo, especially on a provider like GitHub where you can fall back to grabbing tarball if needed. I currently use vcsh[1] & mr[2] to manage my repos -- for that I use a bootstrap script hosted in an orphan branch of the same repo.[2] An efficient setup process of this type also makes it easy to integrate with provisioning tools, e.g. Puppet, Chef, or even just shell scripts.
> I liked this workflow better when it was called DOS.
Knock it all you want, but it's obvious that people like working like this. OS X has Spotligh/Alfred, Linux has Gnome DO etc, it's basically on every OS.
> But now I realize that modern developers don't want a GUI to manage their config.
I think, like almost all software, it depends on personality and other factors like how frequently someone has worked with a language/tool/etc.
If someone has the traditional Unix "read all the man pages in their entirety" kind of brain, they'll probably never use a GUI.
If someone has more of a "learn by example, then refer to the docs to cover cases the examples didn't handle" brain, a GUI can be a much easier way to clearly expose all the potential functionality of a tool. It's much easier to understand (IMO) than e.g. a template configuration file with every possible option present but commented out.
> Every time I see a colleague using command line to do git operations I get itchy and think to myself "oh, come on! I could've done this in gui in seconds".
What operation could you possibly perform significantly faster in a gui than on the command line? I can think of tons that would be far, far slower in a gui.
> to me using a GUI is more of a mark of valuing one's time than that of a novice
I would argue the exact opposite. GUIs are there to make things accessible to non-power users. A command line is just infinitely more expressive and will let you be much more efficient if you learn to use it effectively.
With nearly every program that I use I start by depending heavily on the GUI and then transition to using almost exclusively keyboard shortcuts as I become a power user, as GUIs are fundamentally inefficient.
> If you’re building a kiosk, it’s hopefully obvious to avoid having any read-write mounted filesystems at all costs.
I wish there was support for this out of the box in linux distributions. Either by providing a (sub)set of software that doesn't need to write, and/or adding an overlay. Even for rasperries which are often used in a way where they would benefit it requires some work to set things up.
Having that kernel parameter set automatically when in that mode would be nice, too.
Or maybe I'm just not aware that distributions for this specific use-case exist.
cfdisk, cgdisk.
Maybe you are afraid of parted/fdisk. Then you are right.
But well, fdisk and such are a bit "nightmarish". I had more luck using OpenBSD's disklabel to slice up it's own partitions. And the GPT editor from OpenBSD (I can't remember it's name) was pretty simple to use and preview even on text mode.
You can have both good and bad CLI/TUI's, and even horrendous GUI's, such as the Red Hat installer.
reply