Everything is a file - Psychology, Philosophy, and Licenses
venam
Hello fellow nixers,
This thread is about Unix philosophy and files.

Quote:Everything is a file

I haven't really understood the principle behind this until yesterday.
I suddenly woke up in the middle of the night wondering:
Quote:But what's not a file?

Like someone that has lived in a cocoon for too long I was so accustomed to have everything as a file that I completely forgot about the rest.

I opened the Wiki and refreshed my mind. Then I casually browsed the internet and found threads such as this one.

I forgot about Operating systems where all the configurations are stored right inside the program itself, where to access the hardware or to interact with it you have to fight with a mountain of documents, where most of the important stuff happening is stored in memory and volatile.

Let's respect this philosophy and fight against any software in the Unix community that doesn't respect it!

Bump this thread with your opinion on files and your own stories.
sulami
I think EIAF is an incredibly elegant solution to a problem that only became really relevant decades later. I cannot believe how people are actually programming systems which expose super-simple stuff via complicated syscalls and other APIs. It is (one of) the basis for the effectiveness of shell-scripting, one of the huge benefits of UNIX, enabling easy access to the heart of the machine, both soft- and hardware. It promotes choice of tools, because there is no need for elaborate client-side libraries that need to pre-exist.
ninjacharlie
I really think that its cool who easy it is to create your own FUSE filesystem for whatever wacky way you want to expose your code through files. One of my recent ideas (haven't yet had a chance to implement it), was to create a FUSE filesystem where you would mount a video file, and would have access to each frame as a file. Then you could do standard image editing stuff with whatever software you wanted *on each frame*. Didn't work out quite how everything would work, but I thought it was a cool idea.
Houseoftea
(17-12-2015, 10:26 AM)ninjacharlie Wrote: Then you could do standard image editing stuff with whatever software you wanted *on each frame*. Didn't work out quite how everything would work, but I thought it was a cool idea.

very cool!
And people say that linux doesn't have powerful video editors.
z3bra
Well, it doesn't exist yet :P
pranomostro
One thing that bugs me is that
computer networks (and especially the internet)
are not filesystems, if you look at modern
unices.

What if I want to download all images from an
instagram account? It is unfortunately not
as simple as
Code:
mount www.instagram.com/testaccount /net/insta
and then just use
Code:
cp *.png *.jpg /tmp/img
to copy the images.
Instead, I can do two things: spend one and a half hours
reading the wget manpage to find out how to this, or write
a small script with an ad-hoc parser using curl.
But if I want to reuse this another time, I will have
to write another parser.

My main complaint here is that we could treat data
on servers as filesystems that could easily be mounted into
the local file system (this is, obviously, what plan 9 does).

One could argue that there are FUSE systems for that, but
this argument does not count. Why?
Because FUSE systems are specialised, and can mostly be used only
for one website. For another website, somebody will have
to write another FUSE. I can't accept this as a viable solution.

Imagine what e-mail would look like in a world where you
can mount servers as file-systems. You log into that server,
ls your inbox, mount another server, go to your friends directory,
edit a mail for him, save it on the other server, unmount the two
servers again and then proceed. I don't know how you feel about this,
but I wish so much that this could come true.
z3bra
This is what gopher is for.
pranomostro
Gopher or 9P.
But we are not using Gopher
and Markdown for websites,
we are using CSS3, HTML5 and Javascript,
things that are not content, but
style descriptions, and which have to be parsed out.

There are more simple solutions, but we are not
using them.
Wildefyr
That's because the 'simple solutions' are not what consumers want nowadays for the web.
apk
(19-12-2015, 05:56 PM)Wildefyr Wrote: That's because the 'simple solutions' are not what consumers want nowadays for the web.
User friendliness has and always shall supersede simplicity in any regard.
What's easier to drive, an auto or a stick?
Yet such concepts should be a reality, since people like us could benefit greatly from them.




Members  |  Stats  |  Night Mode