externals

[Randall Lee Reetz]

> hours
> I think the "real time" requirement is too demanding; a suitable  
> time scale for scanning file events must be found that compromises  
> between reliability and system availibility.
>
> best regards,
> 	François


This is THE big bugaboo in computing today... how to deal TOO much  
information, to deal TOO much interaction, with heterogeneous multi- 
node (and multi-core) processing environments running multiple  
simultaneous and competing but interdependent processes in real  
time.  Gone are the days of protected isolated single process single  
entity programming.  Thank god!  It is way past time we started  
building living systems of great and increasing complexity.  That  
will mean programming towards fail-safe algorithms that expect  
unknown conditions and (off the scale) parameters.   A fire hose of  
data should not in and of itself present a problem... just means one  
has to learn to write their interface to that stream in such a way as  
to sample the data as per available processing and storage  
resources... it means writing code that ignores data that it can not  
handle and drinks in data when it can.  Let the fire hoses run!  How  
great to have the problem of too much data!  That we would have to  
learn how to deal with this problem is such a luxury.  We have to  
this point lived such a simple and boring life of exclusion and  
forced simplicity. It is a shock to connected to a world too rich and  
complex for our usual methods.  A shock to be relished.  A new  
challenge.  But it forces a new flexibility to our algorithms, a new  
way of living within and part of a larger and unpredictable system.

Before Quicktime came around, I was working on a way to show a series  
of image frames as video.  The problem was that computers were not  
always (mostly not) capable of keeping up with the processing demands  
of displaying these images as quickly as required by the frame rate  
required.  At the same time, many people faced with this challenge,  
chose to work on reducing the data load (compression, frame size,  
even frame rate).  Instead I just wrote a little repeat loop that  
said, "what time is it?  What ratio of time has passed vs. the  
duration of the film clip I am playing?  I will just show that frame  
that corresponds to that same ratio of all of the frames in this  
clip."  Simple!  This solution works independent to machine capacity  
and frame rate and frame size and resolution and color depth, etc.

This is the kind of thinking required in this new connected and  
networked world where what my code must work with and beside is not  
knowable before it is run.  In stead of actively restricting our  
environment, we must instead choose algorithms that welcome the  
unknowable.  Too much data?  Cool!  To much interaction with unknown  
entities with unknown agendas?  Even better.  We have till this point  
lived in an information and interaction impoverished world... it  
would be ridiculous if our reaction to this new connected and data  
rich environment to choose self-imposed isolation and avoidance.

Turn all the fire hoses on!   And now that they are, lets learn how  
to get the most of this wild new world of access and potential!

Randall


On Jan 23, 2009, at 3:21 AM, François Chaplais wrote:

>
> Le 23 janv. 09 à 11:31, Thierry a écrit :
>
>> Hi  Randall,
>>
>>> Here is a reposting of a link to a page describing the files  
>>> system events reporter fslogger:
>>> http://osxbook.com/software/fslogger/
>>>
>>> If anyone has the inkling or the hankering to fuse this source  
>>> into an external for xTalk on the Mac...
>>> please please please let me know.
>>>>
>>
>> From fslogger Doc :
>>
>> Caveat:
>>
>> The interface that fslogger uses is private to Apple.
>> Currently, there is a caveat regarding the use of this interface  
>> by third parties (including fslogger).  <.....>
>> fslogger is meant to be a learning tool. If you use it, you must  
>> understand the aforementioned caveat.
>> ---------------
>>
>> I had a look at the C source, and will be able to do a quick  
>> external Demo, but with the information above,
>> well, it seems a bit of a tricky path to go there !  What do you  
>> think ?
>>
>> Regards,
>> Thierry
>>
>
> from what I have read, fslogger relies on a private API which is  
> used by spotlight. On the other hand, FSEvent, I think, is a public  
> API. I think it is interesting to have a look on a review of Time  
> Machine
> http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/14
> which (Time Machine), incidentally, relies on FSEvents. The  
> interesting part lies in the compromises that the Apple engineers  
> had to made in order
> a) not constantly monitoring the file system activity, which can  
> bring the system to a virtual halt
> b) select the right granularity both in time and in files to have a  
> working backup which does not fill the backup disk in a few hours
> I think the "real time" requirement is too demanding; a suitable  
> time scale for scanning file events must be found that compromises  
> between reliability and system availibility.
>
> best regards,
> 	François
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>