I've started thinking about the ideal desktop OS and these questions sprung up in my head.
they aren't really specific to linux, just general OS/software design questions, but I thought some of you here would be good at answering them:

what makes files and executables different?
what's the advantage of defining them differently?

what's the definition of a file?
why do we divide data up into files

what makes files and executables different?

A file is a collection of bits and bytes that is treated as a whole entity. A file can be a binary executible, or a simple text file, or a picture, or music file, and the list goes on. Usually by executable we mean a binary colection of bits put together by a compiler. This is machine language, and for the most part not human readable. Of course you can have script files, and thoes are a higher level "language" and you could consider them executable also. Non executables are used by some program, like an mp3 file to play music.

what's the advantage of defining them differently? Not sure there is one, other than a way we humans try to classify everything in order to understand it.

what's the definition of a file?

A file is a collection of bits and bytes that is treated as a whole entity.

why do we divide data up into files

The simple answer here is to make it possible for programs to know where the beginning and end of the data they want to work with is.

All files are really just ones and zeros. A compiled executable file not to be confused with a BASH or perl script for linux uses the ELF format. In a nutshell tells the OS specific information on how to run the program.
http://www.linuxjournal.com/article.php?sid=1060

So if the file does not contain the ELF header it isn't a compiled executable file. The difference between compiled and script files like BASH or perl is that they are called interpreted languages. i.e there is a compiled executable in the case of perl called perl that parses and executes the commands line by line. Compiled executables are faster then interpreted languages.

Text files are still ones and zeros but the difference is that each byte of data is usually between 32 and 127. A particular byte value corresponds to a printable character.
http://www.asciitable.com/

A binary file can contain any byte value between 0 - 255.

A simple difinition would be a collection of data.

Tough question.

UNIX (of which linux is a clone) is historically remembered for the fact that, from an executing program's perspective, everything is a file. For example, the keyboard is a file, and when you type on it a program percieves this as data coming in from a file. The screen is a file, and so to a program it is no different to be writing to an actual file on disc, a printer, a network socket, or the console screen. Perhaps most interestingly, programs even perceve each other as files, and passing data between processes in memory is nothing more than one of them writing to an abstract file, and another one reading from an imaginary file.

If you look inside /proc, you will see various hardware and kernel information represented as, you've guessed it, files. And of course, there is everyone's favourite device, /dev/null, the bit bucket from which no datum ever returns, invented to give you somewhere to pipe any program output that you don't want to know about.

This concept was carrited even further in the successor to UNIX, Plan9.

Where it gets interesting is in considering how future technology wiill alter the necessary metaphors. For example, hard disc are inexorably growing in size, and to Microsoft's new OS, Longhorn, will treat the filesystem as something more like a database than a tree of directories, which is the current prevalent metaphor. The sadly doomed BeOS also experimented with this idea.

One final point: on linux executables are files, they merely have the "eXecutable" bit set by the chmod command. Check out "ls -l ".

ok that helps a little

I'm really just trying to see here if those things we take for granted are really necessary and if there's possibly a better way of doing things. I always tend to think as outside of the box as possible, so that's why.


ok so the reason for files (of any type, including executables and folders) is to give a chunk of data on the storage medium an identifier that's easier for programs (and people) to work with than just a physical address and to define where a chunk begins and ends.
I dunno...maybe this doesn't make sense, but it seems to me that it should be possible to have a desktop environment without files at all. I mean and I guess the computer needs files in order to know what chunk of data to look at....but does it really to look at a specific chunk of data? couldn't it theoretically look at ALL the data? so what really is the purpose of the chunks? I'm sorry if I'm not making any sense

as far as files vs executables:
I'm thinking maybe you could say that non-executables are files that don't actually contain *commands* that the hardware can understand. in that case, a script wouldn't be an executable because the hardware doesn't understand those commands; an executable (the interpereter) has to convert the commands in the script to commands that the hardware can understand.
do you think that's a good (accurate and all encompssing) definition?

If you want to access specific data, you need to know where it is. That's why you need files. Granted, there's plenty of possible ways of organizing a file system (e.g. as a relational database rather than as a simple directory hierachy), but at the very least it must have the ability to separate and catalogue different chunks of data.

Alex