|
|
>>> The standard command interpreter in Windows (cmd.exe, not powershell)
>>> does pretty much suck. bash/tcsh are *far* more powerful. :)
>>> But part of the suckage that is the Windows CLI is the registry. Linux
>>> using text files for most configuration means that using the CLI to
>>> make changes actually makes a lot of sense.
> Like you said, it's an extra install. sed/grep/awk/perl/vim are standard
> tools in most Linux installs.
>
> I can edit text files without installing tools that are non standard.
1.
Unix was explicitly designed to be an OS for computer experts. It
assumes you know what you're doing. It provides no help or assistence of
any kind. Commands print status messages only in the event of a problem.
Success is indicated by silence. There are few warning prompts or
confirmation messages.
Windows is explicitly designed to be used by morons. The kind of people
who shouldn't even be let near anything more complicated than a
doorbell. The sort of people who will double-click
"Natasha_Beddingfield_Naked.jpg.exe" because they want to see it. The
kind of people who probably shouldn't be allowed to handle sharp objects
either.
These people need to be protected from accidentally hurting themselves.
Any command button that might do something bad needs three confirmation
boxes. Anything more complicated than "start program" and "stop program"
needs to be hidden away under an "advanced" configuration menu. When a
Unix program crashes, it says "fatal: invalid IOCTL at 34FB-340A". When
a Windows program crashes, it says "an error has occurred; please
contact support". We don't want to confuse the poor dears, after all.
2.
To configure a Unix program, you must manually edit text files. To
configure a Windows program, you use an actual options screen, which
does things like prevent you selecting invalid combinations of features,
refering to non-existent paths, and so on. In the main, this is /easier/
than editing text files. You don't have to worry about mistyping things,
for example.
You want to configure something from the CLI? Why do you want to do that
in the first place? Given that it's generally harder than just using the
GUI (and it's not like Windows /has/ a CLI-only mode), what are you
trying to accomplish?
Possible answers include:
- I want to configure something that lacks a GUI entry.
- I want to configure a dozen machines the same way.
- I want to change the default settings for all users.
- I want to automatically generate large chunks of configuration data
(e.g., for multiple projects or something).
- I want to configure one program from another program.
If you are doing any of these things, you are not a typical computer
luser. You are a computer expert. And to do these things, you will have
to install computer expert's tools. Windows defaults to assuming you are
a moron. It keeps all the sharp tools as seperate downloads, to stop
morons hurting themselves. If you /are/ an expert, you know where to
find these tools, how to set them up, and what they're for.
3.
CMD.EXE is for backwards compatibility only. For new applications, you
want to be using some powerful scripting language, or writing a full
compiled binary program.
4.
It is perfectly possible to programmatically edit the Registry. Indeed,
it's /easier/ than manipulating text files. You don't have to figure out
where the hell the file is stored and learn /yet another/ file format.
You just issue a couple of Win32 calls. All programs store their
configuration data in a single, common format - the registry.
On the down side, registry settings tend to be completely undocumented.
But usually, if you can figure out where the root key for your
application is, just deleting the whole let will reset everything to
defaults. And there are tools that let you watch the registry. You can
go into your application, change some settings, and then see what
registry changes happened. You can then apply those changes to a dozen
machines remotely, for example. Try doing that with diff and patch...
5.
There are even tools to automate some of this. With just a factory
default install of a Windows server OS, I can press a few buttons in a
GUI and apply configuration settings to every Windows machine on the
network. With Unix, I'd have to go off and script something.
For example, where I work:
- Every PC has the screensaver set to come on after 2 minutes. You must
use a password to unlock it. Users cannot turn this setting off.
- Every PC has Windows Update permanently turned on. The guys at HQ
decide which individual updates to install.
- Every PC has its time synchronised to the same timesource. Users
cannot change the system time.
In addition, at the touch of a button, the guys at HQ can make every PC
on the network (or just certain groups of them) install a specific piece
of software.
If you wanted to do any of this with Linux, you would have a whole bunch
of scripting ahead of you. Under Windows, it just takes a few button
presses to set up. You just can't do it from the end-user versions of
Windows; it requires a server OS. (Three guesses why those cost so much
more.)
In summary:
You can configure Windows just as easily as, if not /more/ easily than a
Unix system. Linux may come with sed and store its configuration in text
files, but a Windows server controlling several Windows clients can do
all the same stuff, and usually without you having to actually develop a
suite of sed scripts all by yourself.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|