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'.  As for who's going to 
depend on it, that remains to be seen, as the development isn't finished 
yet.

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

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.

It's all just data.  To say otherwise is just silly.  By definition, that 
blob of data has to mean something to *someone*, unless it's just random 
bytes strung together.

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

I've seen plenty of better filesystems than what's on a typical PC.

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

I'm good at that. ;)

But I'm not saying that because structure can be assigned to it, it's not 
useful.  I'm just pointing out the axiom that data is data is data is 
data.

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

Sure, the dev who builds the package has to define the dependencies 
correctly.  That's true on any platform.  On Windows (or an AS/400, or a 
Mac) if you link the wrong version of a shared library, badness can 
happen if the dev is depending on the unique behaviour of a function in a 
specific version of the library.

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

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.

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.

My BS meter is going off. ;)

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

Win 7 did twice, IIRC.

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

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

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

That made me laugh.  Another area where Linux was ahead in the game 
(arguably, a minor one, but since we're trading barbs. <g>)

Jim

Post a reply to this message