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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
