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

I'm told part of this also dates back to the time before video displays, 
where command responses actually got printed on paper, and the 
communication was over a slow serial link.

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

Well, in the days before computer networks, security was pretty much a 
moot point. The only way to compromise a computer is to gain physical 
access. If somebody has physical access, there's not much you can do in 
software.

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

Yeah, they do tend to prioritise easy of use higher than security, which 
isn't particularly to my liking. But hey...

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

What's UAC? Is that new in Windows 7 or something? (I've only used Vista.)

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

...until you want to configure something that the GUI doesn't have an 
option for. Or you run some script which auto-configured your Apache, 
and now the shiny Apache front-end can't understand the config file any 
more and gets all confused. Or you do anything slightly advanced.

See, the configuration files are still the primary interface for 
configuring most stuff. The new GUI front-ends that most Linux 
distributions ship with now are exactly that - front-ends that make the 
thing look a bit more pretty. It's all too easy to break them though, or 
to end up with cryptic error messages and need to look under the hood to 
find the "real" error and how to fix it.

Windows programs tend to be designed around the GUI first and foremost. 
(Which isn't eithout drawbacks; it makes scripting harder, for example.)

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

Right. That isn't something that is going to worry the average home user 
who's just trying to surf the 'net. That's something only a computer 
expert would care about. And there are various tools for doing it. 
(E.g., apparently Computer Management works remotely now. And you can 
script it.)

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

The CLI /is/ superior for certain tasks. That's why it exists, after 
all. I won't dispute that. (Although CMD.EXE is a fairly week 
implementation of the concept.)

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

Firing up RegEdit and going to the appropriate key is roughly as easy as 
opening up a text editor on your program's configuration file. The only 
real difference is that configuration files usually have actual 
documentation, whereas the registry typically doesn't.

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

Looking at the registry is effectively like looking at every 
configuration file on your entire Linux box. Sure, /most/ settings that 
you could change won't do any harm. However, since the harmless ones are 
right next to the utterly critical ones, one wrong step can totally 
floor the system. Possibly instantly. (Another thing about the registry: 
changes can take effect immediately. How many Linux programs "watch" 
their configuration file(s)?)

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

Ubuntu seems to contantly want me to reboot when I install updates too. 
I think the problem is more that Windows requires updating more often.

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

You mean WITH ONE PARTICULAR LINUX it's trivial.

That's just it. Windows is one product, with one set of management 
tools. The original Unix, as best as I can tell, has almost no 
management features at all. You're supposed to roll your own. So every 
major distro builder has built their own independent system of 
management tools.

If you wanted to compare how easy this is, you can't really compare 
"Windows" to "Linux". You'd have to compare "Windows" to "Debian", 
"Ubuntu", "OpenSUSE", "Fedora", ...

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

A company that "makes a product" to enable you to do this.

Yes, almost /any/ OS can have software written for it that makes remote 
management easy. The question is how widely available that is.

>> In summary:
>>
>> You can configure Windows just as easily as, if not /more/ easily than a
>> Unix system.
>
> 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.

I think we can summarise as follows:

Unix gives you standard tools for building any kind of management 
infrastructure you can imagine. But it doesn't actually provide such an 
infrastructure by default.

Windows gives you one standard set of management tools, out of the box. 
If those tools don't quite cover what you want, you have a slightly 
harder problem then you would with Unix, but it's hardly intractable.

And, I would imagine, various individual Linux distros probably provide 
their own unique management tools. I doubt any of these work for more 
than one distro, however...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message