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? :-)

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

Nope. All files are represented as binary blobs, at least in Linux and 
Windows. Name me three types of files that don't have recognizable records 
in them.

Lots of mainframes had much more sophisticated file systems. PR1ME had SQL 
tables as their basic file system entity. The fact you've never seen an OS 
that has a better file system doesn't mean they don't exist.

And, indeed, files in Linux and Windows are *not* represented the way they 
are on disk. Both represent files as arrays of bytes with a length accurate 
to the byte. But there's also ACLs, alternate streams (under Windows), 
directories, etc etc etc. If you want to see a language and OS that 
represents files the way they really are, look at FORTH, which represents 
disks as arrays of blocks, and it's up to you to decide which files go with 
which blocks. Or CP/M, the progenitor of our so-wonderful ^Z-is-end-of-file 
custom for text files.

Memory is a flat array of bytes too. That doesn't mean a language with 
hashtables built in isn't useful.

(Sorry. You touched a peeve there. ;-)

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

It also assumes that packages which rely on that updated library declare 
that they do, and that the package tells you how to restart the service. If 
you update something in glibc, does Linux know that the apache service will 
run something different?

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

You know, part of it is the fact that Windows takes better advantage of lots 
of hardware (in the sense that Windows device drivers written by the 
hardware vendor tend to know more about the hardware). Sometimes hardware is 
designed that you can only detect some bits immediately after a reset, so 
rebooting is required to select the right driver out of many.

And, honestly, I don't think Windows (Vista) rebooted more than once during 
the last install I did either.

> But Windows has never been good at telling the user how long
> something's going to take

Very true.  Indeed, it bugs me that'll show a progress bar progressing even 
if you're copying over the network and you just pulled out the cable or 
something.  No, really, it's not progressing. Stop flying pages from one 
folder to the next. You've gotten reliable enough that things can break 
without taking down the system to the point where GIF animations stop 
animating just because the network cable is unplugged.

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

Heh.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message