On Sat, 08 Oct 2011 09:34:06 -0700, Darren New wrote:

> On 10/8/2011 3:52, Jim Henderson wrote:
>> In Windows, you have the entire ecosystem to support it.  It's called
>> "Windows".
> 
> Plus, the tendency is to bundle all that stuff together with the
> program, because you can't rely on the people having access to a
> "repository". So every install disk has IE6, Adobe Acrobat, mvcrt.dll,
> and DX9 on it, along with the program.

Windows could benefit from implementing something akin to a Linux 
software repository for stuff like this.  Getting the software makers to 
agree might take some work, but then again, Adobe has Acrobat Reader in 
most distributions' official repositories.

>> That's because in Windows you have one desktop environment, and one set
>> of dependencies.  Choice comes with a cost.  If you don't want the
>> choices, use Windows.  Or Mac.
> 
> Oh, and because people programming Windows know you don't have a
> repository, so they either bundle specifically what they need, or they
> don't reuse code they could because of dependencies, or they buy a
> version to include with their code that doesn't have the dependencies
> they want to avoid, or etc.
> 
> Why do you think the initial install of Windows takes so long and
> reboots so often? It's installing a bunch of stuff that you'd otherwise
> have to grab from a repository during installs of other stuff. You get
> .NET even if you're not going to use it, because you might in the
> future.

Yep, same reason some libraries are installed on a default Linux 
installation unless you're using Gentoo or LFS.

>>> or had my entire Windows installation completely cease functioning to
>>> the point where I have to reinstall.
>>
>> "Orchid XP v8" - you once said that the "v8" indicated how many times
>> you had reinstalled Windows XP.  So I call BS. ;)
> 
> Bazinga.

LOL

Jim

Post a reply to this message

On Sat, 08 Oct 2011 12:34:21 -0700, Darren New wrote:

> On 10/8/2011 7:32, Jim Henderson wrote:
>> Just like on Windows it used to depend on whether the developer wrote
>> an INI file or used the registry.
> 
> More precisely, it's a question of whether the developer wrote his own
> code to frob INI files, or whether he used the Windows API to do so.
> Because when the registry came out, the Windows API was later changed to
> stor INI files in the registry.

Yes, that's more or less what I meant.

>>> [Let's not even get into the fact that the registry is transactional,
>>> while text files aren't. Or that it supports storing binary blobs
>>> relatively efficiently...]
>>
>> Transactionality is a function of the filesystem, and I use a journaled
>> filesystem.
> 
> The Linux file system isn't transactional. It's just journaled. There's
> no way to update three files at once and ensure nobody sees only one of
> them updated. There's no way to save six files full of Apache config and
> ensure the backup program running in the background hasn't backed up
> three of the new ones and three of the old ones.

Depends on the filesystem in question.  I think the new upcomer 'btrfs' 
is supposed to be transactional.

>> And I've yet to see anything more effective than a binary blob as a
>> file.
> 
> I'm curious what this sentence is supposed to mean. Binary blobs are the
> lowest common denominator, but almost no files actually store a binary
> blob.

All files are binary blobs.  Some have restricted character sets, but 
when it comes down to it, a file is nothing more than a collection of 
bytes.

>> Sometimes distros choose that route because it's just easier than
>> educating the user.  I would prefer if they educated the user instead.
> 
> Or because it's more reliable.  If you update half an installation
> without actually restarting the programs using the DLLs and config files
> you just updated, you could be pretty screwed down the line.  Happened
> all the time to me when (for example) the sys admin would update a
> running server but not save the configuration to outlast a reboot, and
> then the machine would get rebooted and all the software depending on
> that new configuration would fail.

Well, it's more reliable with users who don't have the education on how 
to restart the service rather than rebooting the system.

>> Doing the same on my openSUSE boxes, it's one reboot.  Period.  *If*
>> there's a kernel update.
> 
> Out of curiosity, why would you care how many boots it takes to install
> the OS? It's not like there's other things running while you're trying
> to install, right?

It's a matter of design elegance in my book.  Yes, it doesn't really 
matter if the system reboots a hundred times during the installation.  
Well, except that I'm used to dealing with a single reboot on OS 
installs, so each time the system reboots, I stop what I'm working on 
because I think it's done, and it turns out it's not.

If I spent more time installing Windows, I'm sure I'd become more used to 
it.  In this case, it's a question of being used to going "Oh, it's not 
done yet".  But Windows has never been good at telling the user how long 
something's going to take (to the point that I guess in Win 8, they're 
going to stop trying to predict things like how long a multiple file copy 
is going to take to complete).

Jim

Post a reply to this message

On Sat, 08 Oct 2011 15:59:14 +0100, Orchid XP v8 wrote:

>>> Under Unix, the primary way to control most software is through
>>> configuration files. These days Linux has added pretty front-ends to
>>> some of these systems, but they tend to be designed only for the
>>> people who aren't smart enough to use the "real" interface - i.e.,
>>> edit the text fails manually.
>>
>> Well, yes and no.  Users of SUSE products (openSUSE and SLE*) often do
>> know how to do the manual edits, but prefer using YaST anyways.
> 
> If you pull up the documentation for (say) Apache, it won't tell you how
> to use the Apache YaST module. It will tell you how to edit the
> underlying text file. And if something doesn't work right, and you can't
> figure it out from YaST, you'll have to look under the covers to see
> what it's written in the configuration file, to see why Apache isn't
> doing what you want.

If you use openSUSE for configuration, you use the openSUSE documentation 
to see how to use YaST to make those configuration changes.  And if that 
doesn't get you where you need to be, you ask a question in the community.

OSS is big about community.

>>> Under Windows, the GUI is the "real" interface. The configuration data
>>> is stored in the registry, but you're not supposed to edit it
>>> directly.
>>
>> Except for when there's no other way.
> 
> Except that this almost never happens. That's the entire point. Most
> Linux front-ends seem to be tacked on afterwards, whereas on Windows,
> the GUI is the primary focus.

I guess I imagined all those Technet articles that have the warning I 
sited earlier about how editing the registry can screw your system up.  
That must be it, because of course Microsoft would *never* recommend you 
do something that might bork your system.

>> In openSUSE and SLE, there are in fact several files that are
>> explicitly commented with "DO NOT EDIT THIS FILE DIRECTLY".
> 
> I thought that's just code for "this file is autogenerated from some
> other configuration file - you should go edit that instead".

Configuration files don't autogenerate other configuration programs.  
Configuration programs do, and in those instances, the warning is there 
to tell you to use the proper configuration program.

>>> It's just about where the developers focus their attention. Under
>>> Unix, the configuration file is the definite interface.
>>
>> Well, again, on Linux it depends.
> 
> OK. But certainly most Linux uses seem to have the opinion of "GUI? Pah!
> We don't need that. That's just for n00bs who don't know what they're
> doing..." (Whether this attitude applies to most /developers/ is more
> debatable.)

Obviously you don't know many Linux users.  I know at least 5,000, and 
many of them not only love and use the GUI, but tend to have religious 
wars over which GUI is better.

Of course, that's most certainly an attitude taken by people who think 
GUIs suck, right?

>>> Oh yeah, but /all/ platforms have crappy software.
>>
>> Well, look at OpenOffice or LibreOffice.  Those are not programs
>> designed for the geek, they're designed for the casual user.  You can't
>> lump all programs on Linux in one category and all programs on Windows
>> in the other - there's crossover.
> 
> Sure. But most programs seem to be primarily Unix or primarily Windows.

Which doesn't actually address the underlying point.

>>> You've misparsed what I wrote.
>>
>> OK, I guess I did.  Hey, it was 7:15 AM here and I've been up all
>> night. ;)
> 
> This is not a good thing.

Not generally, no.  I've had some sleep now, but next week is going to 
see me needing to be up early every morning for the first time in months. 
(this is a good thing) :)

>>> Interesting. I'm pretty sure I had to send SIG_HUP (or whatever it is)
>>> to sshd to get it to notice that I just turned off password
>>> authentication...
>>
>> Just like in Windows, it depends on the program, and how long ago.  You
>> may have noticed that Linux development isn't exactly stagnant.
> 
> I notice that there's always a lot of stuff "happening" with Linux. I'm
> never sure what the hell any of it actually /does/. As far as I can
> tell, the difference between each release of any given Linux distro is
> that the colour scheme is different, and some of the default options
> have changed. I'm sure there must be more to it than that, but...

Linux (and most OSS software) evolves rather than going through discrete 
cycles.  The downside is that it can be difficult to peg a specific 
'stable' release unless that's built into the release schedule (of a 
distro or a particular piece of software).  The upside is that bug fixes 
and enhancements (particularly the latter) tend to find their way into 
incremental releases a bit quicker.

Commercial software tends to hold back on incremental improvements (new 
features) for a major release so they can get customers to buy it.

No market pressure for cashflow means a more flexible release schedule 
for incremental enhancements.

>> Transactionality is a function of the filesystem, and I use a journaled
>> filesystem.
> 
> Doesn't stop two scripts both trying to update the same config file at
> the same time. If you do that with the registry, it works. Because it's
> a proper database engine, not just a flat file.

I'm not sure how "proper" that database engine is - IIRC, it's JET, and 
most DBAs that I know would say that's certainly not a proper database 
engine.

>>> That's just ironic. Doing something defective because that's how
>>> Windows does it. Ha!
>>
>> Sometimes distros choose that route because it's just easier than
>> educating the user.  I would prefer if they educated the user instead.
> 
> I guess it isn't just MS that makes poor choices in the name of keeping
> users...

Indeed.

>>> AFAIK, you boot the CD, do the text-mode bit, reboot into GUI mode,
>>> reboot one final time, and you're done. That's, like, 2 reboots.
>>> Hardly excessive...
>>
>> But then start applying patches on Windows.  To get 2008R2 current,
>> that's probably 2-3 more reboots.
> 
> OK, fair enough.
> 
> Personally, I'm not very impressed by the Windows Update system. Like,
> it'll install a bazillion updates for IE6 in the same session as it also
> installs IE8. And then you go back and it wants to install a bunch of
> IE8 updates. Um, why couldn't you do that the first time around??

Yep, I've been frustrated by that as well.

>> Slightly different situation when the manufacturer is extorting OEMs to
>> pre-install Windows on every machine they ship (and charge for a
>> license regardless of whether they ship Windows or not).  That actually
>> is an abuse of monopoly power; the US Antitrust trial found that, and
>> so did the EC's investigation.
> 
> I love how multiple courts have proved that what MS is doing is illegal,
> and as a result they have received NO PUNISHMENT OF ANY KIND. That's
> such a big motivation for them to stop casually disregarding the law...

Oh, I don't know, having to admit that Firefox is a reasonable browser to 
use and they should change Windows architecturally to decouple IE from it 
(or at least loosen the coupling) is a pretty significant sanction.  
Microsoft wanted to prove that IE was a core part of Windows that 
couldn't be removed (because it removed part of their competitive 
advantage - or at least they thought it did), and the EC told them "do it 
anyway", so they had to create a special version of Windows for Europe 
that had that change in place.

Maintaining multiple versions of an entire operating system can be time 
and resource intensive.

Jim

Post a reply to this message

On Sat, 08 Oct 2011 09:55:14 -0700, Darren New wrote:

> On 10/8/2011 4:08, Jim Henderson wrote:
>> 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.
> 
> echo > /etc/fstab

While it will create a problem with getting the system running, it's far 
from unrecoverable.

Windows Server 2000 as a domain controller.  If you lose your 
administrator password, you're hosed.  You're reinstalling. (I understand 
they fixed that oversight in Server 2003, but that's beside the point).

Had a lab full of machines that the power went out in once (electricians 
doing a power upgrade).  We shut everything down properly, they did some 
work, we powered everything up, and then they started their actual work 
and threw the main breaker.

Half the Windows machines wouldn't boot.  All the *nix and NetWare 
machines (and AS/400s et al) booted more or less without any issue at all.

>> 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).
> 
> Because nobody but Linux weenies care whether they have to reboot their
> system to upgrade their software?

It's an inconvenience.  An annoyance.  Something that's far too often 
required on Windows.  Yes, Windows weenies don't particularly care, 
because they've been taught not to care.  They've been taught that 
"troubleshooting" involves "did you turn it off and back on again, and 
when it came back up, did the problem recur?".

Sorry, *that's* not troubleshooting.  That's problem avoidance.

>> Trivial.  No scripting required.
> 
> These are relatively recent tools in Linux, you must admit. UNIX went 40
> years before getting such support, and only because it started to get
> targeted at less tech-savvy people.

Relatively recent being "in the last 10 years or so".  That's about 2-3 
technological generations.

I might as well name Windows faults based on experiences exclusively with 
Windows 3.1.

>>> 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.
> 
> Is it included standard in Linux? ;-)

No, but at least one of the tools is a free tool to download and use.

> But yeah, this stuff happens fine in Linux. Probably easier in Linux
> than Windows, actually. I can't imagine the kind of operations Google
> does in their data centers working on something proprietary like
> Windows.

Indeed. :)

Jim

Post a reply to this message

On Sat, 08 Oct 2011 09:48:10 -0700, Darren New wrote:

> On 10/7/2011 21:47, Jim Henderson wrote:
>> Well, no, it's more about advanced usage.  And CLI in Windows these
>> days is also for advanced users.
> 
> And for anything above the level of really simple BAT files, you're
> better off using wsh, which is much closer to bash than cmd.exe.

And a relatively recent development, no?

>> Like you said, it's an extra install.  sed/grep/awk/perl/vim are
>> standard tools in most Linux installs.
> 
> I'd argue the entire Linux install is a free, extra install. ;-)

Of course you would, coming from a Windows background.  You'd probably 
also call it 'unnecessary'. ;)

>> I can edit text files without installing tools that are non standard.
> 
> You can edit the registry without installing non-standard tools too. If
> you're going to argue that a developer having to download the free
> developer toolkit is a significant difference, then you really shouldn't
> be a developer on Windows. ;-)

Good thing I'm not a Windows developer. ;)

Point is, on most *nix systems, those are standard tools, not an 
additional download.

Jim

Post a reply to this message

On 10/8/2011 2:41 AM, Orchid XP v8 wrote:
> On 08/10/2011 05:39 AM, Darren New wrote:
>> On 10/7/2011 20:43, Jim Henderson wrote:
>>> Sounds *so* familiar. Another reason to use Linux. ;)
>>
>> How the hell would that help?
>
> Seconded.
>
>> What helped was getting him off dial-up so I could talk to him at the
>> same time he's on the net, *and* connect into his computer remotely.
>
> I bought some hardware that lets me remotely connect to my grandparent's
> PC. (Unless, you know, the problem I'm trying to troubleshoot IS the
> Internet connection...)
>
Sounds like the nForce chipset bug, where the "internet security" 
feature built in seemed to have the basic function, when turned on (and 
you can't turn it off short of uninstalling the whole security manager), 
seemed to be to slow the connection, cause packet errors, and prevent 
you successfully downloading anything over a few megs in size. Took me 
months to figure out that the problem wasn't the damn patch panels I put 
in the wall, to connect the two rooms, for my network, but the damn 
"internet security" on the motherboard of the computer that had the problem.

Post a reply to this message

On 08/10/2011 08:38 PM, Darren New wrote:
> On 10/8/2011 2:41, Orchid XP v8 wrote:
>> I bought some hardware that lets me remotely connect to my
>> grandparent's PC.
>
> Why do you need that? All that sort of thing is built into Windows.

Really? So how do I create an encrypted video connection to the target 
machine, while at the same time preventing anybody else from doing the same?

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

Post a reply to this message

On 08/10/2011 10:44 PM, Jim Henderson wrote:

> Had a lab full of machines that the power went out in once (electricians
> doing a power upgrade).  We shut everything down properly, they did some
> work, we powered everything up, and then they started their actual work
> and threw the main breaker.
>
> Half the Windows machines wouldn't boot.  All the *nix and NetWare
> machines (and AS/400s et al) booted more or less without any issue at all.

Now I'm puzzled. Why the heck would that happen? Last time we had a 
power cut at work, all 50 desktop PCs booted back up just fine afterwards...

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

Post a reply to this message

On Sun, 09 Oct 2011 01:32:08 +0100, Orchid XP v8 wrote:

> On 08/10/2011 08:38 PM, Darren New wrote:
>> On 10/8/2011 2:41, Orchid XP v8 wrote:
>>> I bought some hardware that lets me remotely connect to my
>>> grandparent's PC.
>>
>> Why do you need that? All that sort of thing is built into Windows.
> 
> Really? So how do I create an encrypted video connection to the target
> machine, while at the same time preventing anybody else from doing the
> same?

Remote Desktop + password.

Jim

Post a reply to this message

On Sun, 09 Oct 2011 01:33:11 +0100, Orchid XP v8 wrote:

> On 08/10/2011 10:44 PM, Jim Henderson wrote:
> 
>> Had a lab full of machines that the power went out in once
>> (electricians doing a power upgrade).  We shut everything down
>> properly, they did some work, we powered everything up, and then they
>> started their actual work and threw the main breaker.
>>
>> Half the Windows machines wouldn't boot.  All the *nix and NetWare
>> machines (and AS/400s et al) booted more or less without any issue at
>> all.
> 
> Now I'm puzzled. Why the heck would that happen? Last time we had a
> power cut at work, all 50 desktop PCs booted back up just fine
> afterwards...

We never actually figured out why so many of the Windows machines in the 
lab failed to boot.  They were older HP servers (this was circa 
2001/2002).  In the end, the Windows engineers ended up rebuilding the 
systems; they were lab systems after all.

All I remember is those of us who handled systems other than the Windows 
systems found it amusing that the Windows stuff was so fragile and the 
other stuff just rolled with it.

Jim

Post a reply to this message