On Sat, 08 Oct 2011 11:33:28 +0100, Orchid XP v8 wrote:

>>>> 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.

Well, yes and no.  It was designed for people who work with computers, 
yes.  It does have plenty of warning prompts and confirmation messages, 
but it does vary from program to program.

> 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.

Ironically, Windows until recently has done a pretty piss poor job of 
actually keeping people from injuring themselves.  Why?  Because Gates' 
initial specifications were for no security.  Windows since WinNT has had 
to deal with backwards compatibility, and is *finally* getting to a point 
where it's harder for a user to aim the bazooka at their foot and pull 
the trigger.

UAC is a pain in the ass for advanced users.  It's a necessary component 
for the average user.

> 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.

No.  Many UNIX programs have GUIs now.  You may well have heard of CDE, 
KDE, GNOME, LXDE, Unity - all GUIs.  You may also have heard of YaST, 
Webmin, and other GUI-based (and web-based) admin tools that don't 
require you edit text files and do let you select from a predefined list.

> 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?

Why do I want to configure something from the CLI?  My server is 
headless, and dedicating memory to the GUI sucks resources.  So I have a 
server that I run without a GUI at all.  CLI editing is faster *if you 
know what you're doing*.

> 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.

CMD.EXE is quite useful.  I still use it on Windows Server 2008R2 and 
Windows 7 to perform filesystem operations.  Why?  Because I can do many 
of those things faster with a command prompt than with a mouse.  Removing 
my hand from the keyboard and using the mouse slows me down.  Time is 
money.  Wasted time is lost money.

> 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.

Hmmm, so writing a program to edit the registry is faster than going to /
etc/apache2 and editing httpd.conf?  I don't think so.

And of course tweaking a configuration item in IIS is usually a bit more 
complicated than editing a single registry key.  Which of course you have 
to find where the key is stored.  What part of the hive is it in?

> On the down side, registry settings tend to be completely undocumented.

Oh, and more than that, Microsoft routinely warns people *not* to edit 
the registry if they don't know what they're doing, and most of the 
Technet articles I've seen that include editing the registry include a 
"proceed at your own risk" disclaimer in case you totally fuck the system 
over with your change.

I have yet to see a text file change on a Linux system that can hork the 
system up as badly as Microsoft wants you to believe Windows can be 
messed up with a single registry change.

Because with Linux it's pretty rare to have to reboot to affect the 
change.  It's sometimes easier, but to this day, I continue to be amazed 
at how frequently a Windows system has to be restarted.  Twice during 
installation, and if you're applying system updates, sometimes multiple 
times to get everything current (certainly with XP, later versions are 
somewhat better).

> 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...

And of course you can't possibly ever do that on a *nix system, ever.

Oh, wait, yes you can.  You've pretty much always been able to. :P

> 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.

Wrong.

With openSUSE, for example, I can do an installation and at the end of 
the installation, the installer asks if I want to create an autoyast file 
so I can clone the system or do identical installs for multiple servers.

Trivial.  No scripting required.

> 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.)

Wrong, again on the Linux front.  I personally know people who administer 
*thousands* of Linux servers.  I worked for a company that has a product 
to apply updates on a schedule to remote Linux systems.

> 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.

Nope, and to state this is pretty much an uninformed opinion based on a 
deep(er) knowledge of Windows and a lack of knowledge about modern Linux 
systems and how they're deployed in corporate environments.

Jim

Post a reply to this message