O/T: Nibbling on an Apple

On Fri, 09 Aug 2013 12:07:31 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

But it still relies on files unless you can name a computer which
doesn't rely on files.

you're mistakenly assuming computers will always rely on files forever
and ever.

this is a very bad assumption.

I take that despite your bluster you can't name a computer which
doesn't use files.

today, no. in the future, who knows.

and as i said, the newton didn't use files.

Rubbish.

nothing rubbish about it. soups != files.

http://www.roughlydrafted.com/RD/Q4....C253F5337.html
"Rather than using a more conventional file system, Newton data was
stored in soups: object oriented databases."

Notice it doesn't say that Newton doesn't use a file system. It says
Newton did not use a more conventional file system. That it made use
of object oriented databases does not make it any less of a file
system.
--

Regards,

Eric Stevens

On 8/9/2013 3:17 PM, Savageduck wrote:
On 2013-08-09 11:15:51 -0700, Sandman said:

In article ,
PeterN wrote:

If you're not using Lightroom to deal with images in quantity you
probably don't need it to begin with.

Bingo!
I shoot between 30 & 400 images on a shoot. They are viewed and probably
over 90% discarded. That does not make for processing a lot of images.
LR is great for some photographers, but I foundit does nothing for me.

Actually, Lightroom makes the entire review and discard phase much much
easier, especially if you have up to 400 shots in a session.

Agreed.
With Lightroom, particularly after a shoot where I have 300+ shots or
after a day at Laguna Seca, or some other target rich event where I am
looking at around 1200 shots, the first thing I do is a quick
review(with the thumbnails at a reasonable size). During this initial
review I will reject the obvious rejects, and "Star rate" (from zero to
five stars) the others. I will flag those I want to work on immediately.
This gives me the ability to filter on a rating or flag so that all I
see are those shots which meet that filter criteria. So out of a 300+
shot day, I might have 25 flagged shots and 200+ with different star
ratings. I can also recheck the reject group to see if there is anything
to recover, or trash those beyond redemption.

As I said earlier, Bridge performs that function well enough for me.


(Disclaimer: I use Aperture, the above assumes that Lightroom at least
has a comparable review and discard process as Aperture)

Probably very similar.





--
PeterN

On 8/9/2013 7:19 PM, Tony Cooper wrote:


snip

How is that any different from Bridge? What is Lightroom "much much
easier" than?

I see I forgot that Lightroom has the "reject" tag. Still, it's
like a number tag in that you have to go up to Photodelete and then
discard all. It is a small benefit, but very small.





bridge also has that feature. But, I haven't used it. I am perfectly
happy with using the trash bin for a final did I "mess up,' review


--
PeterN

On 8/9/2013 6:41 PM, Sandman wrote:
In article ,
Tony Cooper wrote:

If you're not using Lightroom to deal with images in quantity you
probably don't need it to begin with.

Bingo!
I shoot between 30 & 400 images on a shoot. They are viewed and probably
over 90% discarded. That does not make for processing a lot of images.
LR is great for some photographers, but I foundit does nothing for me.

Actually, Lightroom makes the entire review and discard phase much much
easier,

Easier than what? He didn't state how he discards images. You've
just automatically assumed he does it the hard way.

Yes, in a discussion of the merits of automated software over the file
system and him saying "Bingo!" to the notion of not using Lightroom I
assumed that he meant that he used the file system. If he meant
otherwise, I will certainly apologize for misunderstanding.



Apology accepted.


--
PeterN

On 8/9/2013 7:38 PM, Tony Cooper wrote:
On Fri, 09 Aug 2013 21:20:04 +0200, Sandman wrote:

What me and nospam have been saying for a couple of days is that some
day file systems will disappear (or rather, evolve) to something else,
where the data storage is not done using the concept currently called
"files", but by using a database and a database only.

So what you have been doing is talking about what *might* be the case
in the future even though it's not the case now? And you've just come
around to telling us?

This is a mind-boggling revelation! How long has this been going on?

Were nospam's in-flight market share surveys something he *intended*
to do sometime in the future?

Was that funding commitment you made to that Kickstart thing something
that would *evolve* into an investment a few years down the road?

Is it possible that my workflow is perfectly correct and ordinary
today, but you were warning me that it could morph into something
hilarious in the future?

Just as an aside, but not a flame, we *currently* use "nospam and I"
in that context. Someday, if enough kids use iPads as their tutors,
your usage may be entirely acceptable, though.


I think they are referring to quantum computing concepts, which are not
yet in general use.

--
PeterN

On 8/9/2013 7:47 PM, nospam wrote:
In article , Tony Cooper
wrote:

What me and nospam have been saying for a couple of days is that some
day file systems will disappear (or rather, evolve) to something else,
where the data storage is not done using the concept currently called
"files", but by using a database and a database only.

So what you have been doing is talking about what *might* be the case
in the future even though it's not the case now? And you've just come
around to telling us?

still don't understand, i see.


Some of us believe that Einstein is correct when he states, in
substance, that if you can't explain a concept to a small child, you
really don't understand it yourself.


--
PeterN

On Fri, 09 Aug 2013 12:06:53 +0200, Sandman wrote:

In article ,
Eric Stevens wrote:

unless you can name a computer which doesn't rely on files.

Wtf? I've never said there are *COMPUTERS* that doesn't rely on files.
I've said that there are database engines that doesn't rely on files. I
have explained how this is done several times to you now. Please go back
and read what I wrote again.

Then you are evading the question at issue. Even database engines
can't work in the absence of a file management system.

Yes, they can.

Step out of this thread. You do not have the prerequisite knowledge to
participate.

A database engine can operate without an external file management
system only when the database engine is the sole user of the device
and when it embodies the file management system.
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 10:36:55 +0200, Sandman wrote:

In article ,
Martin Brown wrote:

Incorrect. The most common way for a DB engine today is to store their
databases in a file in the file system, but it's far from a requirement
and stating it like it's a rule is incorrect.

Whilst it is possible that your data might be sat in a "cloud" somewhere
the data physically is and probably always will be sat on a hard drive
of some sort using a classical filesystem to find it again. It may be
that SSDs will overtake moving magnetic platters or that 3D holographic
laser storage media will become mainstream but in all cases you need
something to keep track of where things are stored.

Correct, but that can be done without a disk file system. Currently
Oracle, Postgres and MySQL support loading DB storage directly from a
volume without an intermediate (classical) file system. You need kernel
support for mounting it, and you can't browse the volume using the shell
(it appears empty) but the DBMS can load directly from the volume.

At last you are making sense. For one of the few times in this thread
the particular file management system has been specified: first, the
disk file system and then 'an intermediate (classical) file system'.
Much of the argument has arisen from conflicts over which particular
aspect of file management system is meant.

It's obvious that kernel support is required with any storage device
and this is typically done through system calls or similar. This is
all aprt of the file management system.

In the example you have just given DB storage appears empty for the
reason that there is nothing there upon which the operating system can
get a handle (except, possibly, the root directory)

The filesystem datastructure *IS* a database consisting of where to find
each file that it has been asked to store.

It could be called a database, but isn't by neither developers or file
system engineers. It's a database in the same sense an Excel file is a
database. Plus, the data structure is just one small part of what makes
out the file system, so to claim that "a file system is a database" is
incorrect either way.

Once again that's an argument over definitions. Is a flat file table a
database? To most users it can be.

It can be. it also can be "held" in other ways.

OK. Lets see you demonstrate some photographic image data that is not
ultimately held in files

http://dev.mysql.com/doc/refman/5.1/en/blob.html

You can store and retrive photographic image data in this field type
without storing it in a file in the file system.

You're welcome.

A blob is a data type used to specify types of data to be stored in
the associated fields within records. You may pour the entire contents
of an image file into a blob field and as far as the user is concerned
the blob contains the file.

The program may organize the data in the database in different arrays,
but it depends on the files that contain the data.

No it doesn't. How the program organizes the data in the database has
nothing to do with the files that contain that data. This is 100%
incorrect.

It depends on the database.

No.

Most of the methods around now that let you
annotate and index photographic images work by pointing to the original
file even if they keep some kind of local thumbnail(s) internally.

Which isn't in conflict with what I wrote above.

There are also databases that make such a wholesale rearrangement of the
source data that they bear no resemblance internally to it although they
do contain all the information content of the original but in a form
that is either much smaller or much faster to use.

No, there are no such databases. Databases do nothing more than what the
software tells them to do. There may be *applications* that rearrange
the source files, but the database does not.
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:07:34 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

Without the file(s) that contain the entered data, there is
no database.

That isn't necessarily true. The database could use an entirely
different representation of its content to the original source files.

Quite true,

so you agree a database does not have a file system.

If the original source files are to be recovered the database will
have to have a structure of some kind and a system to recover the
particular original source file. No matter what else you may call it,
it is still a file management system.

but the data is still stored in a unit of storage called a
'file' for the purpose of discussion.

so what?

what's inside the database does not.

Incorrect. The most common way for a DB engine today is to store their
databases in a file in the file system, but it's far from a requirement
and stating it like it's a rule is incorrect.

Whilst it is possible that your data might be sat in a "cloud" somewhere
the data physically is and probably always will be sat on a hard drive
of some sort using a classical filesystem to find it again. It may be
that SSDs will overtake moving magnetic platters or that 3D holographic
laser storage media will become mainstream but in all cases you need
something to keep track of where things are stored.

It doesn't have to be a classical file system: merely a file system.

in other words you're being sloppy with the terminology.

I'm recognising that you have to be flexible (and maybe careful) with
terminology.

There are also databases that make such a wholesale rearrangement of the
source data that they bear no resemblance internally to it although they
do contain all the information content of the original but in a form
that is either much smaller or much faster to use.

But they still have to extract it from files of some kind, and this
needs a file management system.

no.
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:04:46 +0200, Sandman wrote:

In article ,
Eric Stevens wrote:

I expect you to answer 'blob' or similar. How is the blob stored and
how is the data located from within the blob?

My god you're clueless. BLOB is a field type in most SQL engines. There
is no "within the blob" anymore than there is a "within the file". You
retrive the data from the BLOB field, just as you retrive the data from
a file. The result is X bytes of data in both cases.

There is a 'within the blob' if the blob is used to store a gazillion
photographs.

IT ISN'T. Stop using "if" when you don't know what you are talking about.

Are you saying blobs are not used to store multiple photographs?

Step out of this thread. You do not have the prerequisite knowledge to
participate.
--

Regards,

Eric Stevens