On Sat, 08 Oct 2011 13:40:07 +0100, Orchid XP v8 wrote:

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

Sure, but as the technology advances, some things have been updated when 
it was deemed appropriate.

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

Yes and no.  I worked in a computer lab at university that had boot 
diskettes for the network.  I can tell you viruses we had didn't spread 
because of the network.  They couldn't; they didn't understand INT2F 
redirection.

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

Ease of use and security often need to be balanced.  More secure = harder 
to use.  Less secure = easier to use.

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

User Access Controls, introduced in Vista IIRC.

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

Just like with Windows and the registry.  You can configure any settings 
that you want, as long as the UI has them.  The minute it doesn't, out 
comes regedit.

Sorry, that's a straw man, and you know it.

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

Hmm, and GUI frotn-ends for Windows configuration aren't anything more 
than ways of modifying the registry (or in now the rare case, an INI file 
somewhere)?  Sorry, again, you've constructed a straw man.

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

Well, Microsoft programs tend to be.  Windows programs as a whole - some 
are, some aren't.  I've seen some pretty crappy designs for Windows UIs 
in my time.  Blackberry Desktop comes to mind immediately.

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

You know, the average home user surfing the net doesn't have to do diddly 
with a Linux box either.  It isn't rocket science to install a Linux 
distribution these days (certainly not like when I started using it back 
in the 90's), and if the system is preconfigured the way a Windows one is 
(ie, installed by someone who knows what the hell they're doing), the 
average computer user can be trained how to launch Firefox or Chrome and 
surf the web.

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

But for many Windows users, it's what they're most familiar with.

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

Firing up regedit isn't "programming".  Navigating through the hives to 
find the right key is a freaking nightmare.  Even when you know the key 
you want to navigate to.

Give me a text editor and a config file *any day*.  Most of those config 
files have documentation in the comments.  Show me a full description for 
what any given registry key does *within regedit*, and then I *might* 
believe that it's "as easy as editing a config file on Linux".

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

You're simply wrong about this.  Been using Linux since the 90s, pretty 
much daily, and *never* have brought a Linux system down *instantly* by 
changing a config file.  N.E.V.E.R.

> Possibly instantly. 

On Linux?  Highly unlikely.

> (Another thing about the registry:
> changes can take effect immediately. How many Linux programs "watch"
> their configuration file(s)?)

Several do.  If I change the configuration file for vsftpd, for example, 
or sshd, the change comes into play the next time a user connects to it.  
xinetd is a wonderful thing.

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

Only if there's a kernel update.  Ubuntu may prompt more frequently 
because it's more convenient and what users coming from Windows are used 
to.

I've spent a fair amount of time recently installing Windows Server 
2008R2 and SQL Server 2008R2 for some work I've been doing.  The install 
is smoother than Server 2000 and 2003, I'll grant.  But still, it's in 
the stone ages compared to Linux in terms of reboots.

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

Fedora also has a similar tool.  I'm sure the Ubuntu Customization Kit 
also is capable of something similar.

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

The *original* Unix was built in the 60's, and much of what was true for 
that is simply not true today.  That would be like me saying Windows was 
totally insecure because it was with Windows 1.0.  Such a statement would 
be complete bullshit; so is making statements about Linux based on Unix 
developed in the 60's.

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

In reality, that is certainly true.  Because we're talking about a 
complete system, and "Linux" isn't.  A distribution is.

But then a distribution includes things that Microsoft doesn't include - 
office suites, several gigabytes of other applications, and so on.

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

Sorry, I thought the Windows management software to manage thousands of 
servers constituted a "product made by Microsoft to make managing large 
scale Windows deployments easier" was a paid for product called SMS, 
combined with some built-in directory features like GPOs (which of course 
require Windows server - but wait, that's not free, is it?).

Oh, and that company I worked for?  Also makes a tool for managing 
Windows servers that's actually quite a lot better than the Windows 
native tools (including arguably many of the paid-for add-ons).

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

Again, wrong.  And if you want to talk about Unix, Unix and Linux, while 
having some common tools, are not actually the same thing.

> 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 Unix/Linux management is hardly intractable either.  But to listen to 
you, it's freakin' impossible - because if you don't know it, it MUST be 
impossible, right?

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

Webmin is an example of one that's cross-distribution.  Oh, and the 
cost?  It's free - OSS.  Works the same regardless of which supported 
distribution it's put on.

Jim

Post a reply to this message