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