On Sun, 09 Oct 2011 13:23:03 -0700, Darren New wrote:

> On 10/9/2011 10:24, Jim Henderson wrote:
>> On Sat, 08 Oct 2011 18:53:14 -0700, Darren New wrote:
>>
>>> On 10/8/2011 14:28, Jim Henderson wrote:
>>>> Depends on the filesystem in question.  I think the new upcomer
>>>> 'btrfs' is supposed to be transactional.
>>>
>>> True. I heard recently that one is coming out for Linux. Now, how many
>>> programs will actually depend on it? And will it be a half-solution
>>> like disk snapshots are in Linux? :-)
>>
>> Not sure what you mean about 'disk snapshots'.
> 
> The ability to take a consistent snapshot of the disk while it's still
> active, and (for example) make a backup of it, without disturbing people
> trying to write to drives you're backing up.
> 
> http://www.howtoforge.com/linux_lvm_snapshots

OIC.  Not being a user of LVM, it makes sense that I'd not have heard of 
that.

>> It doesn't really matter if they've got recognizable records in them.
>> Those records are still "blobs" that have to be interpreted by a
>> program.
> 
> Well, sure. OK, I'm missing your point, then.  Files are more than just
> blobs of data, or they wouldn't be useful, as you say. They have a
> meaning for the data, even if that meaning isn't stored within the data.
> But I'm not sure what your point is.

The point was that Andy said that binary blob data could be stored in the 
registry and not a Linux configuration file.  Point is, it could be 
stored in a Linux data file, but since it's common to change 
configuration items with an editor in Linux, it's not common to use a 
binary format (though the timezone file is an exception to that IIRC).

>> So rather than stop the installation and reboot, it seems it would be
>> better to queue those things together so a single reboot deals with
>> them all.
> 
> I think that's basically what they started doing, yes. Remember how
> often NT3.5 rebooted during install?

It's been a while, but yeah.  It reboots fewer times now, but still too 
frequently.  The old joke about "You've moved your mouse and now must 
restart your computer" doesn't hold as well as it used to, though. ;)

>> But more to the point, what you're essentially saying is that Windows
>> has to reboot because the hardware vendor's poor design means their own
>> driver can't determine the device correctly unless it's been freshly
>> reset.
> 
> Possibly. I've read that about some of the hardware. That's part of the
> whole "unified driver" thing going on.

So it's still bad behaviour because of poor design.  Design that 
Microsoft could have some say in, given that they do still hold the 
largest market share.  But instead they certify drivers for hardware that 
suffers from poor design.

>> Of course, Microsoft stole the idea of a progress bar that makes no
>> sense from Novell.  Just like BSOD (which they embraced, and then
>> 'enhanced' by making it 'blue' instead of 'black'). ;)
> 
> Machines have had BSOD since long before MS-Dos was around. :-)

Sure, but I don't think it was called that.

>> That made me laugh.  Another area where Linux was ahead in the game
>> (arguably, a minor one, but since we're trading barbs.<g>)
> 
> Barbs? Trading barbs would imply I care whether Windows is better than
> Linux or vice versa. :-)  Neither is my program, so I don't really care.

Well, in the end, I don't really care either, but it bugs me to see the 
same old myths recycled about Linux....just as it seems to bug you to see 
the same old myths recycled about Windows. ;)

Jim

Post a reply to this message