TL;DR - if you just put the car in drive and let the auto box have its own way you will always be in the wrong gear on bends, and have a lurching wobbly uncomfortable drive - and not to mention dangerous.
Strangely, many of us seem quite capable of delivering a smooth, safe drive in our automatics, even around corners.
If braking into a corner is "dangerous" for you, then you're driving inappropriately for the conditions. The road is not your personal racetrack.
I had too much money to burn and bought a dual-processor Pentium II back when they came out, so I had to run NT 3.5 (no SMP in the DOS-based line), and I swear I was still laughing at my friends running 98SE -- as much as that improved over 95, it still looked like something from the dollar store next to any version of NT.
If you had a dual Pentium II, then you would have been using NT 4.0, which replaced NT 3.51 (the replacement for NT 3.5) about two years before your machine would have been on the market.
That's probably Adobe's fault, not Microsoft's, but to suggest that Microsoft has provided flawless backward compatibility for apps in every new version of Windows is a bit misleading.
I don't see anyone saying it's flawless (though for a properly written program - ie: to the published APIs - it's probably damn close). They're just saying that it's well and truly amongst the best, and that in the chaos of the PC market, Microsoft deserves some kudos for that.
Re: the user directory path. I agree that it took far too long to settle on a simple path. That said, I think the location of that directory is actually fairly irrelevant for the day-to-day activities of most Windows users.
It's irrelevant to everyone. It should be referenced with the environment variable %USERPROFILE% (or a suitable API call), because it *could* be anywhere.
Without having seen the video I wonder what type of hardware is able to run all these versions of MS OS?
He used a VMware VM, but I suspect if you grabbed a decent machine from around ~2003 (old enough to just still have windows 95 drivers, new enough to be capable of running Vista and 7) you'd be able to do it all on a single box.
I thought of ME, however he could not use it since there is no upgrade path from ME to anything, it is a dead end.
Pretty sure you can upgrade from ME to XP.
Using Windows 2000 was, IMHO, inappropriate. He was examining the "consumer" line of Windows, and 2000 wasn't part of that lineup. He should have used ME instead of 2000, then upgraded to XP.
A similar progression from Windows NT 3.1 to 7 would also be interesting to watch as an encore.
Um, the semantic minutiae is an unfortunate obstacle that anyone who needs to use a CLI needs to overcome to benefit from it, not the point of the thing.
My point is that CLIs have a significant appeal to those kinds of people, even when a GUI would serve them just as well, if not better.
However, CLIs have several advantages that GUIs can't match (at least without mimicking or indirectly using CLIs). They're extremely easy to program for as the user interface is simple and extremely consistent...
I have to disagree with some of that that. Most CLIs - *especially* UNIX ones - are horribly inconsistent, with syntax (same switches to commands doing different things, different switches to do the same things, different ways of taking arguments, etc) being the most obvious area where that is true.
At no point have I even suggested that CLIs are not useful, should be deprecated, or anything similar. My complaint is with the near ubiquitous belief that only CLIs are used for "serious" or "non-trivial" work, and anyone using (or preferring) a GUI is inherently stupid and/or incapable.
Further, an app that would GUI-tize the full capabilities of this CLI utility would probably be more difficult to use.
Why ? There is no inherent reason it must be.
That's simply because a good GUI will generally have some level of confirmation and error-checking, and will also limit the user's ability to make wrong choices.
Why do you think error and sanity checking is not an equally useful feature for both advanced and ignorant users ?
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
Ie: if Microsoft distributes the binary, they must also distribute the source code (either with it or on request).
(Note that (c) is not applicable as the app store is "commercial distribution".)
Also potentially problematic is:
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. [...]
I expect the app store has its own licensing restrictions that would classify as "sublicensing" a GPLed work. From memory, this is the one Apple cited when they nixed some GPLed software from their app store.
You "wouldn't have noticed" if I had more explicitly spelled it out instead of relying on your ability to interpret something within the given context.
No, I "wouldn't have noticed" if you'd said something _different_.
That's because if I had done that, it would have left you no room to make an assumption. So I left you a bit of wiggle room there. What did you do with that? Did you at least ask me if that's really what I meant? No, you instantly attribute to me a statement I did not make even though it flies in the face of basic reasoning (a claim that such a user would have terminals for non-trivial tasks is not a claim that a GUI cannot perform a non-trivial task).
It most certainly, however, is a strong implication of that. Particularly in the context of the post it was in.
People have egos, in other words. Egos are quite ingenious at worming their way into a discussion while appearing superficially reasonable.
Indeed, which is why in the context of a whole bunch of other comments clearly suggesting that CLIs are awesome and GUIs suck, the implication that GUIs are only used for trivial tasks (and its corollary - only the inexperienced and ignorant who have trivial tasks to do, use GUIs) was pretty clear.
If you had said "the terminal is for tasks best done in a CLI", then I wouldn't have even noticed.
Sure, but a lot of users don't poke at things "in case they break something". To them, it's the magical mystery machine.
That's not really relevant.
Doing a good user interface, whether a CLI or a GUI, is difficult. It requires thinking about what users actually do and how they actually think. The advantage that many CLIs have is merely that the people developing them are part of the target community of users. (That's a huge advantage!)
The advantage that many CLIs have is that the people using them often take *pride* in how difficult they are to use, and boast about their mastery of various arcane and complicated uses of same.
It's difficult to beat the economy of expression and precision the command line offers to those who know how to use it. It's really difficult to beat the ease of automation.
It's difficult to beat the interactiveness and feedback presented in a graphical interface, to say nothing of the density and depth of information available, or its ability to behave dynamically based on context.
My comment acknowledges that there is often a trade-off to be made. It also accepts the reality that it is far easier for a person to adapt to the needs of a machine than it is for a machine to adapt to the needs of a person.
Yet the whole point of having the machine in the first place is to free up the person from mundane and unproductive tasks so they can do something useful with their time. We should absolutely be trying to adapt interfaces to people, not vice versa.
Those diverse trades you mention have one thing in common: people who are unskilled at them don't generally try to do them.
Most people who are not technicians do use computers.
Most people who are not mechanics drive (some even for fun or competition). Most people who are not farmers eat. Most people who are not doctors need medical attention. That's exactly what makes using a computer just like all those other things - you do not need to know how a steak gets from a cow to your supermarket to eat it.
If someone who has never driven a car before and does not understand how to drive safely gets behind the wheel and causes an accident, no one finds that surprising. No one blames that on the car being too difficult to use. They understand that as a machine it is only doing what the driver told it to do. If someone who is equally unskilled and lacks basic competency operates a computer and has problems, we blame the computer.
No, the computer is blamed when people who do have basic competency have problems. Similarly with things like cars, planes, and other devices that are designed to remove certain aspects of required expertise.
I'm not aware of anyone who would blame "the computer" if someone who had literally never touched one sat down and didn't know how to use it. I do know lots of people blame "the computer" when they have learnt the basics but they run into problems because the interface is poorly designed, inconsistent, or simply non-existant.
I think you missed the "system administration" part, I don't think anyone is suggesting that graphic design turtle necks should be CLI-ing their illustrations.
Things like interconnections and dependencies between, say, virtualisation hosts, networking equipment and storage systems are _vastly_ easier to see and understand in graphical form.
I have no problem with a GUI interface for applications that are rarely used. What I do have a problem with is that for many applications intended for constant use *coughMicrosoftOfficecough* there is no expert/CLI mode to eliminate the hugely redundant pointing and clicking it takes to get anything done.
Your example is ridiculous. Office, along with pretty much every other Microsoft product, has extensive keyboard accessibility, both in the form of direct keyboard shortcuts and via the menus.
While there's a certain truth to this, GUIs are in general a lot less "intuitive" than people tend to believe. Without documentation and training, most users are unaware of most of their GUI's capabilities, and have great difficulty in learning much more than the basics.
Sure, but the point is with a CLI and no understanding of its syntax and semantics, you're pretty much dead in the water from the get-go. You could have a deep understanding of networking, but if you're unfamiliar with the syntax of iptables, you're not going to be able to configure a Linux firewall.
Your scrollbar example is actually a good one, because it highlights the key differences between a GUI and a CLI. In a GUI, there is both a visual indicator that the content is larger than a single page, positive feedback from the UI element if the user tries to interact with it (ie: it reacts to a mouse click), and secondary feedback that the UI element is important even if it is triggered "accidentally" (ie: it moves if the user presses page down, space, or in some other way makes the page scroll).
In a CLI, you would simply be presented with a single page of text. Advancing to the next page would require knowing which key(s) to press to do so. If you don't know the key, you're screwed. Some CLIs may present a "press space to continue", or similar, message, but that's starting to blur the line between CLI and GUI, IMHO.
Further, the new knowledge those users have about the scrollbar is now applicable to pretty much any GUI they use in the future, even ones running on completely different OSes (I recognise this doesn't apply to all UI elements, but the fundamentals - buttons, menus, scrollbars, selection boxes, etc - are pretty consistently implemented in similar ways across the board). The knowledge they have gained about the CLI interaction is probably specific to that CLI only (how many different ways in different CLIs do you know of to trigger a page down ?).
Examples like this abound in GUI design. Many of the common widgets are not at all intuitive to most people. Even if they accidentally poke at things and trigger the actions, it's often difficult to grasp what the effect was. You see things change, but the changes don't make sense, and have no obvious relation to the icon that you clicked on. Often the icons don't look like anything that most users can name. The result is that most of the GUI is unusable to most of the users.
Sure, but the point is that there *ARE* things there to "poke at" and there is feedback that something actually happened. A CLI has neither - you need to know the commands in advance to do anything, and often the only feedback from a command is to indicate an error (and frequently said feedback is not useful at all in understanding what the error was).
Human cognition is highly depend on visualisation, context and feedback. A CLI interface lacks - or typically has very minimal implementations of - all of those.
For example, Linux is extremely easy to use -- if you understand it. Windows is a hell of a lot easier to learn but knowing all about it won't make it much easier to use.
That, is entirely a matter of opinion.
Your comment there describes what is easy to learn.
No, it doesn't. Your comment assumes that an interface should *have* to be learnt, to be easy to use.
The CLI appeals to people who are willing to learn, who like learning new things and consider it worthwhile.
No, the CLI appeals primarily to people who like to focus on memorising semantic minutiae and believe that doing so is, in and of itself, a productive endeavour.
The terminal is for non-trivial tasks.
The implication that GUIs are only used for "trivial" tasks is ridiculous on its face.
The average Windows user who views learning as an unreasonable burden that should never be expected of anyone who wants to use a complex machine... they avoid the up-front investment of learning to understand the system. Instead, they can jump in and start using the system right now. But they continuously pay for it over time in the form of enjoying few or none of those advantages.
There is nothing unique to Windows, or even computers, about this. Do you know the intricacies of how your car works ? How about your blender or oven ? Could you fabricate a new bed or sofa from raw materials, and without modern tools ? Do you grow your own produce ? Could you butcher a cow or chicken ? Could you set a complex fracture or create your own painkillers ? Can you brew your own beer ?
It's like the difference between people who live within their means and use plastic only as a form of payment, saving up until they can actually afford something before they purchase it, versus those who live all the time on credit. The person living on credit gets the stuff they want right now but ultimately pays quite a bit more for it and can quickly find themselves in over their head. The discipline and delayed gratification that the latter is trying so hard to avoid is something that the former considers to be virtues worth cultivating.
No, it's nothing like that at all. One is an example of financial irresponsibility and the other is simply realising that you do not need a deep and intricate understanding of a given thing to use or take advantage of the services or benefits it provides.
Well part of it too is that nobody gives a fuck if your Etsy-inspired e-store is working well. The beards are there for critical systems.
"Critical systems" are the ones *most likely* to be simply nuked and reimaged, because they're the ones where minimising downtime is more important than messing about for hours trying to find some obscure cause to a problem that crops up maybe once every 6 months.
Slashdot Mirror
How ?
I don't need to, I've driven around in Scotland myself.
Yes, that is why. You're driving too fast for the conditions, like I said earlier.
Strangely, many of us seem quite capable of delivering a smooth, safe drive in our automatics, even around corners.
If braking into a corner is "dangerous" for you, then you're driving inappropriately for the conditions. The road is not your personal racetrack.
If you had a dual Pentium II, then you would have been using NT 4.0, which replaced NT 3.51 (the replacement for NT 3.5) about two years before your machine would have been on the market.
I don't see anyone saying it's flawless (though for a properly written program - ie: to the published APIs - it's probably damn close). They're just saying that it's well and truly amongst the best, and that in the chaos of the PC market, Microsoft deserves some kudos for that.
It's irrelevant to everyone. It should be referenced with the environment variable %USERPROFILE% (or a suitable API call), because it *could* be anywhere.
And there shouldn't have been. The upgrade from ME was to XP.
Windows 2000 didn't belong in that video.
He used a VMware VM, but I suspect if you grabbed a decent machine from around ~2003 (old enough to just still have windows 95 drivers, new enough to be capable of running Vista and 7) you'd be able to do it all on a single box.
Because he's British.
Pretty sure you can upgrade from ME to XP.
Using Windows 2000 was, IMHO, inappropriate. He was examining the "consumer" line of Windows, and 2000 wasn't part of that lineup. He should have used ME instead of 2000, then upgraded to XP.
A similar progression from Windows NT 3.1 to 7 would also be interesting to watch as an encore.
So, how do you propose fixing the problem ?
All of them.
My point is that CLIs have a significant appeal to those kinds of people, even when a GUI would serve them just as well, if not better.
I have to disagree with some of that that. Most CLIs - *especially* UNIX ones - are horribly inconsistent, with syntax (same switches to commands doing different things, different switches to do the same things, different ways of taking arguments, etc) being the most obvious area where that is true.
At no point have I even suggested that CLIs are not useful, should be deprecated, or anything similar. My complaint is with the near ubiquitous belief that only CLIs are used for "serious" or "non-trivial" work, and anyone using (or preferring) a GUI is inherently stupid and/or incapable.
That's kind of missing the point.
Why ? There is no inherent reason it must be.
Why do you think error and sanity checking is not an equally useful feature for both advanced and ignorant users ?
No, distribute. From the GPLv2:
Ie: if Microsoft distributes the binary, they must also distribute the source code (either with it or on request).
(Note that (c) is not applicable as the app store is "commercial distribution".)
Also potentially problematic is:
I expect the app store has its own licensing restrictions that would classify as "sublicensing" a GPLed work. From memory, this is the one Apple cited when they nixed some GPLed software from their app store.
No, I "wouldn't have noticed" if you'd said something _different_.
It most certainly, however, is a strong implication of that. Particularly in the context of the post it was in.
Ain't that the truth.
That's a mighty big "if", and the problem is in many CLIs, the answer is "it doesn't".
Indeed, which is why in the context of a whole bunch of other comments clearly suggesting that CLIs are awesome and GUIs suck, the implication that GUIs are only used for trivial tasks (and its corollary - only the inexperienced and ignorant who have trivial tasks to do, use GUIs) was pretty clear.
If you had said "the terminal is for tasks best done in a CLI", then I wouldn't have even noticed.
That's not really relevant.
The advantage that many CLIs have is that the people using them often take *pride* in how difficult they are to use, and boast about their mastery of various arcane and complicated uses of same.
It's difficult to beat the interactiveness and feedback presented in a graphical interface, to say nothing of the density and depth of information available, or its ability to behave dynamically based on context.
Yet the whole point of having the machine in the first place is to free up the person from mundane and unproductive tasks so they can do something useful with their time. We should absolutely be trying to adapt interfaces to people, not vice versa.
Most people who are not mechanics drive (some even for fun or competition). Most people who are not farmers eat. Most people who are not doctors need medical attention. That's exactly what makes using a computer just like all those other things - you do not need to know how a steak gets from a cow to your supermarket to eat it.
No, the computer is blamed when people who do have basic competency have problems. Similarly with things like cars, planes, and other devices that are designed to remove certain aspects of required expertise.
I'm not aware of anyone who would blame "the computer" if someone who had literally never touched one sat down and didn't know how to use it. I do know lots of people blame "the computer" when they have learnt the basics but they run into problems because the interface is poorly designed, inconsistent, or simply non-existant.
Things like interconnections and dependencies between, say, virtualisation hosts, networking equipment and storage systems are _vastly_ easier to see and understand in graphical form.
Your example is ridiculous. Office, along with pretty much every other Microsoft product, has extensive keyboard accessibility, both in the form of direct keyboard shortcuts and via the menus.
That's before even getting into VBA...
Sure, but the point is with a CLI and no understanding of its syntax and semantics, you're pretty much dead in the water from the get-go. You could have a deep understanding of networking, but if you're unfamiliar with the syntax of iptables, you're not going to be able to configure a Linux firewall.
Your scrollbar example is actually a good one, because it highlights the key differences between a GUI and a CLI. In a GUI, there is both a visual indicator that the content is larger than a single page, positive feedback from the UI element if the user tries to interact with it (ie: it reacts to a mouse click), and secondary feedback that the UI element is important even if it is triggered "accidentally" (ie: it moves if the user presses page down, space, or in some other way makes the page scroll).
In a CLI, you would simply be presented with a single page of text. Advancing to the next page would require knowing which key(s) to press to do so. If you don't know the key, you're screwed. Some CLIs may present a "press space to continue", or similar, message, but that's starting to blur the line between CLI and GUI, IMHO.
Further, the new knowledge those users have about the scrollbar is now applicable to pretty much any GUI they use in the future, even ones running on completely different OSes (I recognise this doesn't apply to all UI elements, but the fundamentals - buttons, menus, scrollbars, selection boxes, etc - are pretty consistently implemented in similar ways across the board). The knowledge they have gained about the CLI interaction is probably specific to that CLI only (how many different ways in different CLIs do you know of to trigger a page down ?).
Sure, but the point is that there *ARE* things there to "poke at" and there is feedback that something actually happened. A CLI has neither - you need to know the commands in advance to do anything, and often the only feedback from a command is to indicate an error (and frequently said feedback is not useful at all in understanding what the error was).
Human cognition is highly depend on visualisation, context and feedback. A CLI interface lacks - or typically has very minimal implementations of - all of those.
That, is entirely a matter of opinion.
No, it doesn't. Your comment assumes that an interface should *have* to be learnt, to be easy to use.
No, the CLI appeals primarily to people who like to focus on memorising semantic minutiae and believe that doing so is, in and of itself, a productive endeavour.
The implication that GUIs are only used for "trivial" tasks is ridiculous on its face.
There is nothing unique to Windows, or even computers, about this. Do you know the intricacies of how your car works ? How about your blender or oven ? Could you fabricate a new bed or sofa from raw materials, and without modern tools ? Do you grow your own produce ? Could you butcher a cow or chicken ? Could you set a complex fracture or create your own painkillers ? Can you brew your own beer ?
No, it's nothing like that at all. One is an example of financial irresponsibility and the other is simply realising that you do not need a deep and intricate understanding of a given thing to use or take advantage of the services or benefits it provides.
"Critical systems" are the ones *most likely* to be simply nuked and reimaged, because they're the ones where minimising downtime is more important than messing about for hours trying to find some obscure cause to a problem that crops up maybe once every 6 months.