If Unix treats everything (nearly) as a file, couldn't every file be
treated as a potential filesystem?

Then you just unify everything behind a query based interface.

On Saturday 10 October 2009 03:40 in alt.os.linux, somebody identifying
as Anti Vigilante wrote...

> If Unix treats everything (nearly) as a file, couldn't every file be
> treated as a potential filesystem?

I'm afraid you are misinterpreting things. UNIX treats everything like
a stream of bytes, and every stream of bytes is seen as a file. Why
would it need to treat files or streams as filesystems?

> Then you just unify everything behind a query based interface.

Parser error - cannot compute.

--
*Aragorn*
(registered GNU/Linux user #223157)

On Sat, 2009-10-10 at 03:57 +0200, Aragorn wrote:
> On Saturday 10 October 2009 03:40 in alt.os.linux, somebody identifying
> as Anti Vigilante wrote...
>
> > If Unix treats everything (nearly) as a file, couldn't every file be
> > treated as a potential filesystem?
>
> I'm afraid you are misinterpreting things. UNIX treats everything like
> a stream of bytes, and every stream of bytes is seen as a file.

It's a stream when it is accessed, but when it is found and located it
is a file.

> Why
> would it need to treat files or streams as filesystems?

Because it's a common abstraction that should be standardized already.

Libraries and gzips should be accessible without having to think about
them. Function calls would be files for example.

>
> > Then you just unify everything behind a query based interface.
>
> Parser error - cannot compute.
>

Files and their filesystems would be accessible through one interface
that treated them nearly the same way.

On Saturday 10 October 2009 06:09 in alt.os.linux, somebody identifying
as Anti Vigilante wrote...

> On Sat, 2009-10-10 at 03:57 +0200, Aragorn wrote:
>
>> On Saturday 10 October 2009 03:40 in alt.os.linux, somebody
>> identifying as Anti Vigilante wrote...
>>
>> > If Unix treats everything (nearly) as a file, couldn't every file
>> > be treated as a potential filesystem?
>>
>> I'm afraid you are misinterpreting things. UNIX treats everything
>> like a stream of bytes, and every stream of bytes is seen as a file.
>
> It's a stream when it is accessed, but when it is found and located it
> is a file.
>
>> Why would it need to treat files or streams as filesystems?
>
> Because it's a common abstraction that should be standardized already.

"Should?"

> Libraries and gzips should be accessible without having to think about
> them. Function calls would be files for example.

Why would you needlessly add another layer of complexity to access
functions? Libraries all work in a similar way, so one does not "need
to think about it".

>> > Then you just unify everything behind a query based interface.
>>
>> Parser error - cannot compute.
>
> Files and their filesystems would be accessible through one interface
> that treated them nearly the same way.

What do you think */dev* is? Or */proc,* or */sys?*

--
*Aragorn*
(registered GNU/Linux user #223157)

On Sat, 2009-10-10 at 12:55 +0200, Aragorn wrote:
> On Saturday 10 October 2009 06:09 in alt.os.linux, somebody identifying
> as Anti Vigilante wrote...
>
> > On Sat, 2009-10-10 at 03:57 +0200, Aragorn wrote:
> >
> >> On Saturday 10 October 2009 03:40 in alt.os.linux, somebody
> >> identifying as Anti Vigilante wrote...
> >>
> >> > If Unix treats everything (nearly) as a file, couldn't every file
> >> > be treated as a potential filesystem?
> >>
> >> I'm afraid you are misinterpreting things. UNIX treats everything
> >> like a stream of bytes, and every stream of bytes is seen as a file.
> >
> > It's a stream when it is accessed, but when it is found and located it
> > is a file.
> >
> >> Why would it need to treat files or streams as filesystems?
> >
> > Because it's a common abstraction that should be standardized already.
>
> "Should?"
>
> > Libraries and gzips should be accessible without having to think about
> > them. Function calls would be files for example.
>
> Why would you needlessly add another layer of complexity to access
> functions? Libraries all work in a similar way, so one does not "need
> to think about it".

Because with every new language (except derivatives like Scala and
Groovy) there has to be the same library rewritten: php-mysql, cl-mysql,
python-mysql. I realize where there's a VM this might not be avoidable
but then again...

The same thing happens with gui toolkits as well. There's an incredible
amount of redundancy and reinventing of the wheel.

> >> > Then you just unify everything behind a query based interface.
> >>
> >> Parser error - cannot compute.
> >
> > Files and their filesystems would be accessible through one interface
> > that treated them nearly the same way.
>
> What do you think */dev* is? Or */proc,* or */sys?*

I want /query/dev and /query/proc. Or maybe query:///dev.

On Oct 9, 9:40*pm, Anti Vigilante <antivigila...@pyrabang.com> wrote:
> If Unix treats everything (nearly) as a file, couldn't every file be
> treated as a potential filesystem?

Yes.

Unix (and Linux) treat raw block-special files (i.e. disk-like
devices) as files /and/ as filesystems, simultaneously.

Additionally, in Linux systems (I don't know about Unix or POSIX, but
I suspect them also), you can format a file with a filesystem format,
and use the "loopback" mount to access those files /as/ as
filesystems.

So, yes, in Unix and Linux, files are potential filesystems.

> Then you just unify everything behind a query based interface.

Non sequitur.

On Sat, 2009-10-10 at 07:53 -0700, Lew Pitcher wrote:
> On Oct 9, 9:40 pm, Anti Vigilante <antivigila...@pyrabang.com> wrote:
> > If Unix treats everything (nearly) as a file, couldn't every file be
> > treated as a potential filesystem?
>
> Yes.
>
> Unix (and Linux) treat raw block-special files (i.e. disk-like
> devices) as files /and/ as filesystems, simultaneously.
>
> Additionally, in Linux systems (I don't know about Unix or POSIX, but
> I suspect them also), you can format a file with a filesystem format,
> and use the "loopback" mount to access those files /as/ as
> filesystems.
>
> So, yes, in Unix and Linux, files are potential filesystems.

Why not make a standardized API with urls like:

file:///home/user/image.png#@dimension/height

the @ implies a context

the raw image then would be file:///home/user/image.png#@raw/content

you could also literally do in place file conversion by using virtual
contexts like {@gif} or {@jpg#@option/quality/75%}#@formatted

file:///home/user/image.png#{@gif}#@formatted

Now some people will argue that it belongs in userspace. But I would say
that the ability to abstract and apply filters is very basic.

the filters would of course be in userspace.

> > Then you just unify everything behind a query based interface.
>
> Non sequitur.

There is an important difference between a container and its format. See
above. What I was suggesting is that the difference can be blurred and
eliminated by the query interface.

Anti Vigilante wrote:
> On Sat, 2009-10-10 at 12:55 +0200, Aragorn wrote:
>> On Saturday 10 October 2009 06:09 in alt.os.linux, somebody identifying
>> as Anti Vigilante wrote...
>>
>>> On Sat, 2009-10-10 at 03:57 +0200, Aragorn wrote:
>>>
>>>> On Saturday 10 October 2009 03:40 in alt.os.linux, somebody
>>>> identifying as Anti Vigilante wrote...
>>>>
>>>>> If Unix treats everything (nearly) as a file, couldn't every file
>>>>> be treated as a potential filesystem?
>>>> I'm afraid you are misinterpreting things. UNIX treats everything
>>>> like a stream of bytes, and every stream of bytes is seen as a file.
>>> It's a stream when it is accessed, but when it is found and located it
>>> is a file.
>>>
>>>> Why would it need to treat files or streams as filesystems?
>>> Because it's a common abstraction that should be standardized already.
>> "Should?"
>>
>>> Libraries and gzips should be accessible without having to think about
>>> them. Function calls would be files for example.
>> Why would you needlessly add another layer of complexity to access
>> functions? Libraries all work in a similar way, so one does not "need
>> to think about it".
>
> Because with every new language (except derivatives like Scala and
> Groovy) there has to be the same library rewritten: php-mysql, cl-mysql,
> python-mysql. I realize where there's a VM this might not be avoidable
> but then again...

It's not a library rewritten, it's a module for a language so it can use the
library written in C/C++ without the need of building a mysql written entirely
in that language. Groovy and scala uses the java dbc functionality and I
wouldn't call those for languages but java libraries.


> The same thing happens with gui toolkits as well. There's an incredible
> amount of redundancy and reinventing of the wheel.

Thats quite natural as you are doing the same thing, regardless of which GUI
you use, point and click, but there are big differences how things are handled
and kind of the beauty that you can pick your least hated GUI instead of
forced to use a completely crappy one.


None of this are good arguments to make yet another layer for the fun to make
yet another layer for how to handle files, and in a way you can already do
what you ask for, for you can use image files which are file systems.

>>>>> Then you just unify everything behind a query based interface.
>>>> Parser error - cannot compute.
>>> Files and their filesystems would be accessible through one interface
>>> that treated them nearly the same way.
>> What do you think */dev* is? Or */proc,* or */sys?*
>
> I want /query/dev and /query/proc. Or maybe query:///dev.

mkdir /query && ln -sfn /dev /query && ln -sfn /proc /query

or was it something else you wanted to do?

--

//Aho

Anti Vigilante wrote:

> Why not make a standardized API with urls like:
>
> file:///home/user/image.png#@dimension/height
>
> the @ implies a context
>
> the raw image then would be file:///home/user/image.png#@raw/content
>
> you could also literally do in place file conversion by using virtual
> contexts like {@gif} or {@jpg#@option/quality/75%}#@formatted
>
> file:///home/user/image.png#{@gif}#@formatted
>
> Now some people will argue that it belongs in userspace. But I would say
> that the ability to abstract and apply filters is very basic.
>
> the filters would of course be in userspace.

This has really nothing to do with the file system but with the tool you use
to browse the file system with, it's all up to you to patch a current file
browser or write your own from scratch to use a syntax like that to do
different actions. One problem you will get with your suggested system is that
#, @, {, }, (, ) and % are valid characters in file names and can cause your
file browser to mess things up.

I would believe most people here uses console/terminal for file manipulation,
so I don't think you will get may supporters when you can do with a shorter
command line than your uris.

--

//Aho

On Sat, 2009-10-10 at 18:55 +0200, J.O. Aho wrote:
> Anti Vigilante wrote:
>
> > Why not make a standardized API with urls like:
> >
> > file:///home/user/image.png#@dimension/height
> >
> > the @ implies a context
> >
> > the raw image then would be file:///home/user/image.png#@raw/content
> >
> > you could also literally do in place file conversion by using virtual
> > contexts like {@gif} or {@jpg#@option/quality/75%}#@formatted
> >
> > file:///home/user/image.png#{@gif}#@formatted
> >
> > Now some people will argue that it belongs in userspace. But I would say
> > that the ability to abstract and apply filters is very basic.
> >
> > the filters would of course be in userspace.
>
> This has really nothing to do with the file system but with the tool you use
> to browse the file system with, it's all up to you to patch a current file
> browser or write your own from scratch to use a syntax like that to do
> different actions. One problem you will get with your suggested system isthat
> #, @, {, }, (, ) and % are valid characters in file names and can cause your
> file browser to mess things up.

First of all the uri is not a filename. Second of all these can be
escaped. Slashes and spaces are constantly needing escaping.

> I would believe most people here uses console/terminal for file manipulation,
> so I don't think you will get may supporters when you can do with a shorter
> command line than your uris.
>

An operating system should be able to have a description of a file
format which any application can access. A jpeg is a jpeg.

Like AMIGA datatypes.

On October 10, 2009 17:38, in alt.os.linux, Anti Vigilante
(antivigilante@pyrabang.com) wrote:
[snip]
> An operating system should be able to have a description of a file
> format which any application can access. A jpeg is a jpeg.
>
> Like AMIGA datatypes.

The designers of Unix disagree with you, and I (and many others) agree with
them.

Unix was designed so that the operating system was file format agnostic; to
it, each file is a series of binary octets, without special meaning or
interpretation.

This gives the OS incredible flexibility: it doesn't care whether a file is
a JPEG or a text because it doesn't need to care. Only the applications
that manipulate the data must care, and even then, most don't. If cp(1)
cared what sort of file it copied, then we'd have a much more complex
cp(1), or a family of separate cp(1)'s, one for each filetype. And heaven
help us if someone builds a filetype not yet known to the utility.

Indeed, I can write a program that builds and manages it's own data. If the
OS were required to "know" (have a description of the file format) my
filetype, I'd effectively have to build a new OS each time I changed my
program. Multiply that by thousands of unique file formats for thousands of
independantly developed programs, and you have an unmanagable mess on your
hands. BTW, what ever happened to the AMIGA OS? Is it still around?

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

On Sat, 2009-10-10 at 18:54 -0400, Lew Pitcher wrote:
> On October 10, 2009 17:38, in alt.os.linux, Anti Vigilante
> (antivigilante@pyrabang.com) wrote:
> [snip]
> > An operating system should be able to have a description of a file
> > format which any application can access. A jpeg is a jpeg.
> >
> > Like AMIGA datatypes.
>
> The designers of Unix disagree with you, and I (and many others) agree with
> them.

I'm not suggesting the kernel has to manage them. I'm only suggesting
the kernel have a basic scheme that applications can use.

> Unix was designed so that the operating system was file format agnostic; to
> it, each file is a series of binary octets, without special meaning or
> interpretation.

Right. The kernel should be agnostic.

> This gives the OS incredible flexibility: it doesn't care whether a file is
> a JPEG or a text because it doesn't need to care. Only the applications
> that manipulate the data must care, and even then, most don't. If cp(1)
> cared what sort of file it copied, then we'd have a much more complex
> cp(1), or a family of separate cp(1)'s, one for each filetype. And heaven
> help us if someone builds a filetype not yet known to the utility.

But so many applications reinvent the wheel. The kernel has an interface
for getting the same results no matter what video driver you are using.

This would allow you to download format drivers and every application
would benefit from improvements. Also because of the use of format
drivers or as the AMIGA calls them datatypes every application can
access the format without extra work. Everything from the text editor to
the presentation app could be able to open the files.

> Indeed, I can write a program that builds and manages it's own data. If the
> OS were required to "know" (have a description of the file format) my
> filetype, I'd effectively have to build a new OS each time I changed my
> program. Multiply that by thousands of unique file formats for thousands of
> independantly developed programs, and you have an unmanagable mess on your
> hands. BTW, what ever happened to the AMIGA OS? Is it still around?

I'm suggesting something external to both kernel and app and precisely
something not buried in a library for only one language.

The AMIGA OS is constantly being reimplemented, badly... Just like unix.

Anti Vigilante wrote:
> On Sat, 2009-10-10 at 18:55 +0200, J.O. Aho wrote:
>> Anti Vigilante wrote:
>>
>>> Why not make a standardized API with urls like:
>>>
>>> file:///home/user/image.png#@dimension/height
>>>
>>> the @ implies a context
>>>
>>> the raw image then would be file:///home/user/image.png#@raw/content
>>>
>>> you could also literally do in place file conversion by using virtual
>>> contexts like {@gif} or {@jpg#@option/quality/75%}#@formatted
>>>
>>> file:///home/user/image.png#{@gif}#@formatted
>>>
>>> Now some people will argue that it belongs in userspace. But I would say
>>> that the ability to abstract and apply filters is very basic.
>>>
>>> the filters would of course be in userspace.
>> This has really nothing to do with the file system but with the tool you use
>> to browse the file system with, it's all up to you to patch a current file
>> browser or write your own from scratch to use a syntax like that to do
>> different actions. One problem you will get with your suggested system is that
>> #, @, {, }, (, ) and % are valid characters in file names and can cause your
>> file browser to mess things up.
>
> First of all the uri is not a filename. Second of all these can be
> escaped. Slashes and spaces are constantly needing escaping.

How do you know where the #@ is art of the file name or the action you want to
apply to the file, as you don't need escape those characters in the file
browser as you would do need to do in terminla.

>> I would believe most people here uses console/terminal for file manipulation,
>> so I don't think you will get may supporters when you can do with a shorter
>> command line than your uris.
>>
>
> An operating system should be able to have a description of a file
> format which any application can access. A jpeg is a jpeg.
>
> Like AMIGA datatypes.
>

Datatypes wasn't a part of the kernel in AmigaOS, it was a part of workbench,
so we are back on the level of the desktop environment and works like file
associations for your file browser, with the major difference that a file
association can easily be change to use another application for the action
while changing how a datatype works requires you to build a new datatype and
replace the old one. As before, you are free to implement a datatype style of
system for your favorite file browser.


--

//Aho

Lew Pitcher wrote:

> BTW, what ever happened to the AMIGA OS? Is it still around?

AmigaOS has been quite dead after Gateway bought the pieces from what was left
of Commodore.

There been a number of hacks to the AmigaOS, which didn't do much more than
provide some new libraries (nothing new on the kernel level).

Then there was a alternative version for PowerPC which was originally thought
for the PowerPC expanded Amigas, but which got it's own more up to date
hardware from Genesi and was called MorpOS, it's backwards compatible with
AmigaOS, so you could run old applications for MC68k.

Then there was another AmigaOS for PowerPC with the name AmigaOS4, had some
quite crappy PowerPC hardware without DMA, later on at a desperate time the
AmigaOS4 was made to work on the Genesi hardware.

Then we have the open sourced project AROS, which tries to make an x86 version
of AmigaOS and which is the only one which has any new hardware to run the OS on.

There is a lot of bad blood between the MorphOS and AmigaOS4 groups, which
more or less has destroyed the Amiga community.

--

//Aho

Anti Vigilante wrote:
> On Sat, 2009-10-10 at 18:54 -0400, Lew Pitcher wrote:

>> This gives the OS incredible flexibility: it doesn't care whether a file is
>> a JPEG or a text because it doesn't need to care. Only the applications
>> that manipulate the data must care, and even then, most don't. If cp(1)
>> cared what sort of file it copied, then we'd have a much more complex
>> cp(1), or a family of separate cp(1)'s, one for each filetype. And heaven
>> help us if someone builds a filetype not yet known to the utility.
>
> But so many applications reinvent the wheel. The kernel has an interface
> for getting the same results no matter what video driver you are using.
>
> This would allow you to download format drivers and every application
> would benefit from improvements. Also because of the use of format
> drivers or as the AMIGA calls them datatypes every application can
> access the format without extra work. Everything from the text editor to
> the presentation app could be able to open the files.

Still datatypes aren't at kernel level, even AmigaOS would have become utterly
slow if it had been on the kernel level. Don't forget that there was loads of
different implementation of gif, jpeg, png and sound datatypes, but you can
only have one of those installed and working at one time and how many
different image displaying application didn't there exist anyhow

http://uk.aminet.net/gfx/show
http://uk.aminet.net/util/dtype

>> Indeed, I can write a program that builds and manages it's own data. If the
>> OS were required to "know" (have a description of the file format) my
>> filetype, I'd effectively have to build a new OS each time I changed my
>> program. Multiply that by thousands of unique file formats for thousands of
>> independantly developed programs, and you have an unmanagable mess on your
>> hands.
>
> I'm suggesting something external to both kernel and app and precisely
> something not buried in a library for only one language.

You still would need java-datatypes, c-datatypes, php-datatypes,
python-datatypes. perl-datatypes and so on or else you wouldn't be able to use
the datatypes in the language you like to code in. And don't forget that the
datatypes where a part of the workbench, not the kickstart and there was other
alternatives to datatypes, like the file association used in dopus which
allowed you to have multiple actions.


--

//Aho