What I gather from this discussion is that Windows downloads and installs updates in the background without notifying the user. I don’t like it when my computer sends and receives data without my permission, so I still much prefer the Mac OS method of bringing up available downloads and requiring me to approve each one.
IIRC, you can set it to download but not install the updates, and automatically notify you when they are available.
I’m not really sure if I would or not. My knowledge of how *nix systems is very limited. I know how to move files around in the command line, and I know where a few important system and configuration files are located, but no, I am not very qualified on *nix stuff. I just wanted to point out that knowing your way around a command line is not a requirement for knowing what you call the “basic concepts behind the application they’re using.” The CLI came first, but that’s not because a CLI is a more pure way of interacting with the computer or anything – the technology to support a GUI simply didn’t exist yet.
Might I suggest putting forward the effort to learn, before passing judgement on the ease of using a modern CLI?
It sounds like you’re saying you would only consider a computer user competent if they were well-versed in the command line. If your OS has a command line, I suppose that’s the only way to know everything about it, but it’s entirely possible to be a competent computer user without ever touching one.
You’re just a less efficient user for lacking the knowledge.
That is hard for a large number of people. An individual with a full-time job, interests, and obligations to family and friends isn’t going to look favorably upon a 28-hour time commitment over two weeks, especially if that person doesn’t find computer use particularly interesting or enjoyable, which is more likely than not. I think your judgment of what kind of computer work isn’t hard is biased.
So spread it over a month--you can get the basics down in even less time. It’s not like you need to be terribly proficient to understand how to work with pipes and redirects.
ls, grep, |, >, etc. must be second nature to you, but they are not “ubiquitous” or easy for most people.
Those are fairly base-level commands and operators, if you’re working in a *nix CLI.
I certainly like having a CLI available on occasion (although I don’t particularly like the added complexity of UNIX underpinnings), but you’ve been claiming that editing text configuration files and using the command line are the best, or at least easiest ways to do things, and I can’t agree with that.
But you’ve just said that you were unfamiliar with the environment. How can you really make a judgement about it’s ease of use, if you don’t know how to use it? Easy to use and easy to learn are, after all, two very different things.
How could that take 40 seconds? I pick an option from the File menu, type a word, and click a button.
To save it. It took time to setup and make the search itself--remember, you’re trying to get filenames including the string ‘foo’, not the name of files that include the string ‘foo’ within them. You also need to limit the search to your home directory.
It took me about 10 seconds altogether, which is about as long as I assumed it would take you to run your 3-part command. The point is that in order to run your command line search, you have to know exactly which commands and syntax are needed, with no cues from the computer, unless you count poring through manpages, which isn’t time-efficient at all.
The GUI doesn’t really offer any cues either. You still have to understand how to do something, which isn’t much different from learning a command in a CLI.
The GUI method isn’t faster, but it doesn’t have to be. What matters is that it places far less burden on the user to remember specific things just to perform a simple function.
But it places a greater burden on them when performing complex tasks. A GUI requires a specific tool for each complex task--a CLI can use many simple tools to perform the same complex task.
What exactly am I going to do with a timestamped text file listing which of my files contain the word “foo” in their name, anyway?
Nothing--but that was an *example* of the use of output piping and regular expressions. A simple example I’ve used for ages now, because it’s a clear demonstration that users of any platform can understand.
I said before why I consider GUIs easier to use. If you measure ease of use strictly in the physical mouse movements or keypresses per action, then you could call the CLI easier to use, but the fact that each action requires the user to recall specific commands and syntax from memory in order with no cue from the computer, which just sits there with a blank screen and makes you do all the thinking.
GUIs require users to memorize very complex series of operations with little logical meaning, in order to perform even moderately complicated tasks--or they require developers to write a specific utility to perform the task for them. This is much more difficult than remembering even a few hundred commands on the CLI, and understanding how to glue them together.
A GUI removes much of that burden from the user by providing them with visual cues. Humans are generally better at dealing with visual cues and spatial clutter than having to keep track of everything mentally. A CLI forces the user to do much more mental work, and therefore I cannot consider it easier to use.
It requires less mental work than a GUI does, if you’re trying to perform anything other than simple one-step tasks.
Is that undesirable?
No, it’s not--that’s why I’ve been wondering about the people insisting that hidden options are common in config files.
That’s because Mac OS X was not made for experienced *nix users; it was made for Mac OS users. Should it be at all surprising that Macintosh conventions were favored over UNIX conventions in the user interface?
I wasn’t aware that classic Mac OS even *had* conventions regarding the CLI, which is what I’m talking about.
This is a serious flaw in Mac OS X. No Mac user should be expected to mess with smb.conf just to choose SMB shares, and Apple would do well to add a Samba tab to the Sharing preference pane in the near future. I’m well aware that editing text configuration files is accepted as a matter of course in Linux, but in the Mac world, it’s not, and it shouldn’t be. What makes this even more of an outrage is that some Linux distributions have well-designed graphical Samba configuration tools, while Mac OS X advertises Samba support, yet only allows you to turn a basic Samba configuration on and off using the GUI.
I suppose they figured that desktop users would never care to change that particular setting. I can’t say I’m terribly surprised. Apple often dictates things like that. It’s one of the things that frustrates me when using OS X.
But, getting back to the original topic, why would you suggest that someone switch to Linux, if its only apparent advantages are to the kind of people who think editing text configuration files and using a command line are good things?
Those are, by no means, the only advantages. Or even priamry advantages, to users who don’t care to delve into how their platform works.
Unless there are better reasons (besides price – I want to know about the actual user experience), in which case I would love to hear them.
I can only give you my reasons--Price, ease of use, customization, and philosophical reasons. In that order. My reasons for disliking OS X are similar (it’s expensive, hard to work with, difficult to customize, and I don’t like the idea of encouraging proprietary software development).
But only if you can remember everything, which I still consider a major weakness of the command line.
I suppose it’s similar to my belief that the inherent inflexibility of GUIs is a major weakness. I just happen to think that flexibility and control is more important than a short-list of functions to memorize.
For some people, yes. Your point is learning the syntax is harder than learning a GUI, but once you learn the syntax, the actual task of using it is not difficult—it’s just typing. I think the thing is there are more opportunities for human error with CLI than GUI. The GUI is less flexible too.
I suppose, but I don’t think it’s any greater than on a CLI. You have typos in a CLI, but you can easily miss a target in a GUI. You can forget a command in a CLI, but you can also forget the process by which a function is invoked with a GUI.
What’s the syntax for assigning OS commands to specific key combos? Does that even apply?
On a CLI? I don’t think I’ve ever had cause to reassign functions for keyboard shortcuts. I wouldn’t know how. I have no doubt that there is some way to do it, even if I don’t know off the top of my head.
With a GUI, I can apply what I’ve already learned more often, I think. You have to go look up the syntax for something new and then go on. With the GUI, I don’t have to go look up Energy Saver syntax because it’s located in the same place as Display. It’s right there for me to see, and the Spotlight integration really makes it faster now to find those things.
What sort of syntax would I need to learn that you wouldn’t? I open the appropriate file, I enter the correct information. We both need to understand what is appropriate to enter--and chances are, the syntax wouldn’t even differ very much. It’s not like I need anything other than my text editor of choice to make corrections. Hell, I can even do it through the GUI if I wanted. True, I need to know how to start my favored text editor--but you need to know how to find the ‘Display’ properties with the GUI.
You can do a search too, right? But you have to know what syntax to search for, right?
Just as you do with a GUI. GUI frontends can be badly labeled, just like config files can be badly arranged.
Easier only in those situations where your current GUI is lacking, which isn’t that often in OS X, for me anyway.
In my experience, OS X’s UI has a lot of flash, but little substance. It’s difficult to work with, and nearly impossible to bend to your preferences without forking over money for tools to fix the problems.
And many times the GUI lacks a feature and the CLI can’t do it either because the OS doesn’t support the feature at a base level.
Can you provide an example of this? I can think of a few, but I’m not sure we’re thinking of the same occurance.
IIRC, you can set it to download but not install the updates, and automatically notify you when they are available.
There’s an option where it automatically installs updates when you shut down. I don’t ever deal with dialogs and just have those updates installed for me because I don’t keep anything actually important on any Windows PCs.
I wasn’t aware that classic Mac OS even *had* conventions regarding the CLI, which is what I’m talking about.
It’s general convention was that you shouldn’t have to use the CLI for anything, everything should be accessible via a GUI
The GUI doesn’t really offer any cues either. You still have to understand how to do something, which isn’t much different from learning a command in a CLI.
OK, if you were to take two windows users with no experience with linux or OS X and sat them both in front of them and asked them to change the display refresh rate who do you think would do it faster? OS X makes it easy and straight forward because it’s a GUI. Changing a system setting? Well it’s obviously going to be done via this thing called System Preferences, conveniently name so that your average user can figure it out, unlike some obscurely named text file. Then they’re changing a setting to do with the display. Well there’s a rather nice button that says display underneath, no searching through a text file for which settings relate to displays. Then there’s a drop down menu with a label “Refresh Rate” giving you all the available options. No need to read through comments to know what to put.
With Linux is the state it is, it’s going to get little more than the most advanced Windows and OS X users, but generally they are the ones who are most likely to stick with their platform.
IIRC, you can set it to download but not install the updates, and automatically notify you when they are available.
There’s an option where it automatically installs updates when you shut down. I don’t ever deal with dialogs and just have those updates installed for me because I don’t keep anything actually important on any Windows PCs.
Is it just me or does that option never work. I don’t think it’s ever worked for me in the last two years. IIRC it doesn’t even work on Vista either.
OK, if you were to take two windows users with no experience with linux or OS X and sat them both in front of them and asked them to change the display refresh rate who do you think would do it faster?
The Linux user--they’d end up using either the Screen Resolution applet in System->Preferences or the Display section of the KDE control center. Both of which are accessed in a more ‘windows-like’ manner.
OS X makes it easy and straight forward because it’s a GUI.
Both methods are available for Linux users--what I was commenting on originally was fixing a problem with xorg.conf that prevented those interfaces from working correctly.
Changing a system setting? Well it’s obviously going to be done via this thing called System Preferences, conveniently name so that your average user can figure it out, unlike some obscurely named text file. Then they’re changing a setting to do with the display. Well there’s a rather nice button that says display underneath, no searching through a text file for which settings relate to displays. Then there’s a drop down menu with a label “Refresh Rate” giving you all the available options. No need to read through comments to know what to put.
As I’ve said numberous times, there are many GUI frontends for doing this sort of thing. However, those of us who perfer or need to work with config files still have full access.
With Linux is the state it is, it’s going to get little more than the most advanced Windows and OS X users, but generally they are the ones who are most likely to stick with their platform.
I see you’ve *completely* disregarded my comments regarding new users on Linux. The whole part about having many GUI frontends, and many distributions set up to cater to those users?
How come nobody has said anything about advantages of GUI for working at the computer?
Changing screen refresh rates and other system config files is very neat for computer enthusiasts and sysadmins, but what about people who use computers not just because they like using computers, but because they work with them?
I have a voiceover file. It’s a two-hour-long monaural audio track consisting of several dozen fragments (takes). I need to edit it, clean up bloopers, apply crossfades, equalize it, and mix it with the rest of the material preserving all the timing, etc. The client wants it to be done yesterday, of course.
Do you really expect anyone in his right mind to use CLI for this job?
Most Linux users don’t really care about getting people to switch. Especially if it means changing the good things about the platform to gain the users.
But you said that you were working on a Linux advocacy presentation. What features in Linux would make it attractive? What are the good things specifically?
I think most of the substance of your posts should be reserved for your resume.
Except where that doesn’t work due to monitor detection failing. (Like my case: The only refresh rate offered is 75Hz) Mine may be a special case, but still.
Thankfully, fixing the program is simple, provided you have the monitor’s documentation and the location of xorg.conf.
Could I please draw your attention to
this
and
this
Wow… amazing, huh?
Yes, we know, but we were discussing whether or not command lines and text configuration files were superior ways of doing things. Linux GUIs are getting very good (in my opinion they surpassed Windows a while ago), but depending on the distribution, I occasionally find or hear about things that don’t have GUI yet.
Except where that doesn’t work due to monitor detection failing. (Like my case: The only refresh rate offered is 75Hz) Mine may be a special case, but still.
Thankfully, fixing the program is simple, provided you have the monitor’s documentation and the location of xorg.conf.
I just had some adventures with xorg.conf in getting ubuntu running on my iMac G3, thank you very much.
