Well, having read Hans Reiser's The Naming System Venture I'm thinking the file system should be much higher level. I don't like the whole file/folder concept and think an object database would be better for the end user.
mmm, interesting... I will share with you some, I have a lot of docs, readed and not readed, for specific purpouse and all that things, projects, software, things that I read at middle, some favorite reads and suchs things.... a like database but not that high, maybe will help more, also some other things... the idea is a app that let me have a real organization... not only tyhe selections by folders....
this is not only the called "myDocuments", "MyPrograms", and in lin, "src" folders and such things, I will like enable a option in the filesystem for more organization, mark the docs, not have duplicated documents (some times happend to me), etc...
This is, you use the filse system for store asll your data... but the file system only serve in realuty for that "simple" thing, basic thing... example.... thing in a office, you have a girl/guy, you give documents for save they, ok he save they eficientely, use well the space and such things, but when become the real organization, is you the one that really need say the girl/guy where to put the things, maybe this is good, in some cases, in my case with a large bunch of documents to read, is not good this, for my... that is desorganization!!!, and I dont recibe help from the file system!!!, it only save and retrueve the data... not more.
That is all that have for now.. in fact.. when I write my OS.. will have some more advanced that "file systems", because for me dont serve for me well, also other things that I see that fail in the OSs.....
I will read the link provided....
Have a nice day or night.
this is not only the called "myDocuments", "MyPrograms", and in lin, "src" folders and such things, I will like enable a option in the filesystem for more organization, mark the docs, not have duplicated documents (some times happend to me), etc...
This is, you use the filse system for store asll your data... but the file system only serve in realuty for that "simple" thing, basic thing... example.... thing in a office, you have a girl/guy, you give documents for save they, ok he save they eficientely, use well the space and such things, but when become the real organization, is you the one that really need say the girl/guy where to put the things, maybe this is good, in some cases, in my case with a large bunch of documents to read, is not good this, for my... that is desorganization!!!, and I dont recibe help from the file system!!!, it only save and retrueve the data... not more.
That is all that have for now.. in fact.. when I write my OS.. will have some more advanced that "file systems", because for me dont serve for me well, also other things that I see that fail in the OSs.....
I will read the link provided....
Have a nice day or night.
I like the idea of an object-oriented file system.
I really hate the Unix "suffix" (DOS/Windows "extension") method of selecting applications, after dealing with two or more apps sharing them (with different file formats, of course).
I really hate the Unix "suffix" (DOS/Windows "extension") method of selecting applications, after dealing with two or more apps sharing them (with different file formats, of course).
I am interested into this area also
Since i am designing SolOS's own file system.
However i dislike the "OOP for everything" kind of ideas
I was not born with folders:
-i have used filesystems where there was no filename (just numbers for each file)
-i have used filesystems that had 8.3 names but did NOT have folders
etc
Lets start from the start and advance understanding all aspects... without becoming too emotional or OPP involved IF it is not necessary. For example i will be devils advocate going to the minimalis/simple approach, and you can have your arguments in the opposite direction ... and maybe we will all become much wiser :grin:
1)So for a start lets understand that the HDD is organized as in TRACKS/HEADS/CYLYNDERS/SECTORS
The minimum block accessible is 512bytes as we stand today. Having it as a stream will make it very slow and inefficient :P
2)because manufacturers choosed to use variable numbers of sectors on each track there has been an "improvement": aka the LBA style that treats the whole HDD a linear vector of sectors from 0 up to maximum sector available on disk.
Please note that this has gained us an easyer programming but has made us forget and/or ignore the physycal aspects that could make things faster/clearer.
Losing features is never a good idea no matter how nice "the advance" is presented.
For example we could calculate if its better to jump to a diffrent sector than 1 when changing tracks... we have lost this option now and we have to believe that the HDD is doing this the best way he can :grin:...
However HDD can not understand if i will be using a huge file for multimedia or a large number of small access for database indexes :P but i can...
This way sooner somebody will cook your food elsewhere and design you clothes and decide what you should do because "they know better and you have to trust them and it is far more easy to programm this way" dont you think?
Now the exact next level after plain sectors 512 bytes in size is what?
Files of course.
They are just a collection of plain 512bytes sectors...
Files have to have names (or do you prefer numbers?) and it will be nice to have a type, size and other atributes as well.
We like long names but we can not have them unlimited or we will be wasting space and/or slow down system very much.
Of course the names have to be kept into a separated table and/or file. So here it comes the folder
Or do you prefer a fixed root size like in CP/M? (was pretty ok/valid a LOT of time)
Also theoretically we have to keep the array of blocks that compose a file into some place also. So here it comes the FAT or INODES linked lists or CP/M's FCB arrays
And there will be needed/nice to have a location to keep track of the free blocks/space on HDD so we can create/allocate new files/space in a fast way...ie not scanning the whole HDD for empty new space.
So here it comes the SUPERNODE and allocation bitmaps in CP/M. FAT is multifunctional :tongue:
I might have loost some concepts while writting... but with above stuff in mind... variouse OS/filesystems designers have choosen some implementations, mainly CP/M, FATxx, INODE/Unix style and some minor variations...
Lets see how and what can we do better...
IMHO OOP is a thing for structuring your applications after ages of experience and NOT a propaganda for others that might wrongly use it as a panaceea... while they do NOT have the needed experience... OOP has its advantages but also many dissadvatages IMHO... but propaganda works on kids all the time...
SO what could we do better to a new filesystem tha is simple, fast and not wasting preciouse access times and CPU?
The .EXTENSION is a pretty good ideea.... and its the programmers fault not work together in fair ways to avoid colisions. Remember that today the extension can be long also?
AFAIK MAC and other filesystems use a magic number for this but nevertheless colisions exist and as everybody can change an extension also everybody can change a "magic ID number".
Tools will fast emerge to do that...no advance here just obfuscation IMHO. besides magic numbers are smaller than "long" extensions.
I am not aiming to create OS/filesystems for FOULS because this kind of design will generate and harvest FOULS all over the world.
We should try and find the most helping logical stuff and keep it extra simple.
I do not care IF a user decides to change a file's extension just to "play" with it. He/She are either knowing what they are doing...so who am i to stop them in this case? ...or playing with "fire" and they might get "burned" and learn a lesson and become more inteligent in the process...
I favour simple things (as simple as it is needed to get the job done).
I consider over complicated things a clear sign of mind problems.
I do not hate neither or love filesystems
i just keep analyse them :P to understand the real truth. SO i can not hate Unix/DOS/Windows filesystems nor i love them. I will try to make my own with better implementations.
Imho OOP and databases should be build ON TOP of base filesystem, because today OOP is fashionable, but we can not force it inside filesystem or risk to lose the flexibility to design OTHER ideas and algorithms...and we will loose a LOT of speed this way also.
So what can we do with a bunch of 512 bytes building blocks?
Since i am designing SolOS's own file system.
However i dislike the "OOP for everything" kind of ideas
I was not born with folders:
-i have used filesystems where there was no filename (just numbers for each file)
-i have used filesystems that had 8.3 names but did NOT have folders
etc
Lets start from the start and advance understanding all aspects... without becoming too emotional or OPP involved IF it is not necessary. For example i will be devils advocate going to the minimalis/simple approach, and you can have your arguments in the opposite direction ... and maybe we will all become much wiser :grin:
1)So for a start lets understand that the HDD is organized as in TRACKS/HEADS/CYLYNDERS/SECTORS
The minimum block accessible is 512bytes as we stand today. Having it as a stream will make it very slow and inefficient :P
2)because manufacturers choosed to use variable numbers of sectors on each track there has been an "improvement": aka the LBA style that treats the whole HDD a linear vector of sectors from 0 up to maximum sector available on disk.
Please note that this has gained us an easyer programming but has made us forget and/or ignore the physycal aspects that could make things faster/clearer.
Losing features is never a good idea no matter how nice "the advance" is presented.
For example we could calculate if its better to jump to a diffrent sector than 1 when changing tracks... we have lost this option now and we have to believe that the HDD is doing this the best way he can :grin:...
However HDD can not understand if i will be using a huge file for multimedia or a large number of small access for database indexes :P but i can...
This way sooner somebody will cook your food elsewhere and design you clothes and decide what you should do because "they know better and you have to trust them and it is far more easy to programm this way" dont you think?
Now the exact next level after plain sectors 512 bytes in size is what?
Files of course.
They are just a collection of plain 512bytes sectors...
Files have to have names (or do you prefer numbers?) and it will be nice to have a type, size and other atributes as well.
We like long names but we can not have them unlimited or we will be wasting space and/or slow down system very much.
Of course the names have to be kept into a separated table and/or file. So here it comes the folder
Or do you prefer a fixed root size like in CP/M? (was pretty ok/valid a LOT of time)
Also theoretically we have to keep the array of blocks that compose a file into some place also. So here it comes the FAT or INODES linked lists or CP/M's FCB arrays
And there will be needed/nice to have a location to keep track of the free blocks/space on HDD so we can create/allocate new files/space in a fast way...ie not scanning the whole HDD for empty new space.
So here it comes the SUPERNODE and allocation bitmaps in CP/M. FAT is multifunctional :tongue:
I might have loost some concepts while writting... but with above stuff in mind... variouse OS/filesystems designers have choosen some implementations, mainly CP/M, FATxx, INODE/Unix style and some minor variations...
Lets see how and what can we do better...
IMHO OOP is a thing for structuring your applications after ages of experience and NOT a propaganda for others that might wrongly use it as a panaceea... while they do NOT have the needed experience... OOP has its advantages but also many dissadvatages IMHO... but propaganda works on kids all the time...
SO what could we do better to a new filesystem tha is simple, fast and not wasting preciouse access times and CPU?
The .EXTENSION is a pretty good ideea.... and its the programmers fault not work together in fair ways to avoid colisions. Remember that today the extension can be long also?
AFAIK MAC and other filesystems use a magic number for this but nevertheless colisions exist and as everybody can change an extension also everybody can change a "magic ID number".
Tools will fast emerge to do that...no advance here just obfuscation IMHO. besides magic numbers are smaller than "long" extensions.
I am not aiming to create OS/filesystems for FOULS because this kind of design will generate and harvest FOULS all over the world.
We should try and find the most helping logical stuff and keep it extra simple.
I do not care IF a user decides to change a file's extension just to "play" with it. He/She are either knowing what they are doing...so who am i to stop them in this case? ...or playing with "fire" and they might get "burned" and learn a lesson and become more inteligent in the process...
I favour simple things (as simple as it is needed to get the job done).
I consider over complicated things a clear sign of mind problems.
I do not hate neither or love filesystems
i just keep analyse them :P to understand the real truth. SO i can not hate Unix/DOS/Windows filesystems nor i love them. I will try to make my own with better implementations.
Imho OOP and databases should be build ON TOP of base filesystem, because today OOP is fashionable, but we can not force it inside filesystem or risk to lose the flexibility to design OTHER ideas and algorithms...and we will loose a LOT of speed this way also.
So what can we do with a bunch of 512 bytes building blocks?
BogdanOntanu, yeah, yeah, I used all those systems, too. Logic doesn't solve everything.
Extension is BAD idea. To assume you can define all the attributes of a file by a string of letters is so 1980's. ;) And to require the OS to manage the functionality based on the these extensions is a kludge to patch the failing design of the file system. Furthermore the design doesn't help when transfering files to others (forces them to setup their OS the same as yours to have the same functionality with the same files).
What about compression and encryption?
Some files would not have/need names - pictures for example! You ever try to name a folder of pictures - I always fall back to PIC00001, PIC00002, etc...because I want to type a description for what I'm looking at and no words are sufficient! Then what purpose do those names serve - none.
I don't want to make robots out of computers users - I want to make computers able to represent some of the dynamics of humanity.
Extension is BAD idea. To assume you can define all the attributes of a file by a string of letters is so 1980's. ;) And to require the OS to manage the functionality based on the these extensions is a kludge to patch the failing design of the file system. Furthermore the design doesn't help when transfering files to others (forces them to setup their OS the same as yours to have the same functionality with the same files).
What about compression and encryption?
Some files would not have/need names - pictures for example! You ever try to name a folder of pictures - I always fall back to PIC00001, PIC00002, etc...because I want to type a description for what I'm looking at and no words are sufficient! Then what purpose do those names serve - none.
I don't want to make robots out of computers users - I want to make computers able to represent some of the dynamics of humanity.
I have the riser file system running under linux
it is FAST and it packs the files tight the same install would need twice the space because the riser file system dosen't use blocks per-se a 100 byte file tacks up 100 bytes not one block
bitRAKE
the mount command for nix may provide some insight into how to run more than one file system at a time like compression and encryption
it is FAST and it packs the files tight the same install would need twice the space because the riser file system dosen't use blocks per-se a 100 byte file tacks up 100 bytes not one block
bitRAKE
the mount command for nix may provide some insight into how to run more than one file system at a time like compression and encryption
It's 'Reiser', not 'riser'.
Compression... I think the NTFS way of doing it is pretty good - you don't get the best compression ratios, but you get fine speed, and since the compression is done at FS level, you don't get the memory waste like you would with executable packers (dirty pages and all).
As for encryption, it depends on your needs. I don't fancy the NTFS way of doing this, I think it's better to put a filter driver between the block device and the FS driver. Loop-AES works pretty well for linux, and do have a look at GBDE (GEOM Based Disk Encryption) for BSD, that's some pretty funky stuff.
Compression... I think the NTFS way of doing it is pretty good - you don't get the best compression ratios, but you get fine speed, and since the compression is done at FS level, you don't get the memory waste like you would with executable packers (dirty pages and all).
As for encryption, it depends on your needs. I don't fancy the NTFS way of doing this, I think it's better to put a filter driver between the block device and the FS driver. Loop-AES works pretty well for linux, and do have a look at GBDE (GEOM Based Disk Encryption) for BSD, that's some pretty funky stuff.
To assume you can define all the attributes of a file by a string of letters is so 1980's.
Many systems already abandoned extensions in the 80s, like Mac, C64, Amiga... Also, caps-only was abandoned on these systems, in general.
So it's more like 1970s, except if you're a PC-person, they're always a few decades behind with old technology.
Mind you, prefixes or suffixes do make it easy to sort files of the same type, both for humans and computers. That is ofcourse, assuming you have no other system available, like meta-info/icons/etc.
Also what I say in my post:
I say some like a real organizer.. if you look carrefully at the name "Explorer" yea, you are only using a explorer of the sile system, what I whant say in my post, is that I dont whant a appkication that let me explore, but I whant a "organizer", also for that I put the example of the secretary and the office site... by the way.. for what I will need explore? my office, is good know where I have my things, but I think some maybe is failing.. at the way... that If I have a secretary that only save the documents, retrive it, but not organize them and know what is happening (I say what is a graphic, what is a card, what have restricted access, etc... something is falling with the work of the secretary, is incomplete... I think.
Dont you think that?, also like you say.... or more.. like I say... this in some way can be done with a app that do this, but maybe a file system can help this app, also actually I am thinking in some things about this, you know that there are some things that simulate this, but they are not part of the file system... like the "story", "recent files" and other things....
Also when you search you only need normally search for the readable data in your computer, not for the executable or parts of the executable.. (maybe some times .ini files or others, but the files of no editable ini files is a fail of the application.. you really dont need modify nothing about a programm, the programm need be amigable at this way....), in the case that you search for executable, is better have this separated, also maybe a "problem" where will be when you are creating a programm, htat you mix normally data files, with executable ones, but this can be done well with redirect the output to a folder of programm test or some, and you sstill dont mixin this data with executable data, also mix produced files, with the folders of applications is bad, bnecause you will drive a not centralized data storage (and a centralized... is good in the case of data in computers... less redundancy and others things), the files that the executable produce and are stored in the application folder need be only for internall use of the application, not like a output for the user of the application.
Also see that change the viewpoint of the filesystem also drive a little how the OS look, and how the applications thread is internal data and output files, when you modify this really inside (like I think), I think you modify the enviroment.
I will still thinking in this.
Have a nice day or night.
the idea is a app that let me have a real organization... not only tyhe selections by folders....
I say some like a real organizer.. if you look carrefully at the name "Explorer" yea, you are only using a explorer of the sile system, what I whant say in my post, is that I dont whant a appkication that let me explore, but I whant a "organizer", also for that I put the example of the secretary and the office site... by the way.. for what I will need explore? my office, is good know where I have my things, but I think some maybe is failing.. at the way... that If I have a secretary that only save the documents, retrive it, but not organize them and know what is happening (I say what is a graphic, what is a card, what have restricted access, etc... something is falling with the work of the secretary, is incomplete... I think.
Dont you think that?, also like you say.... or more.. like I say... this in some way can be done with a app that do this, but maybe a file system can help this app, also actually I am thinking in some things about this, you know that there are some things that simulate this, but they are not part of the file system... like the "story", "recent files" and other things....
Also when you search you only need normally search for the readable data in your computer, not for the executable or parts of the executable.. (maybe some times .ini files or others, but the files of no editable ini files is a fail of the application.. you really dont need modify nothing about a programm, the programm need be amigable at this way....), in the case that you search for executable, is better have this separated, also maybe a "problem" where will be when you are creating a programm, htat you mix normally data files, with executable ones, but this can be done well with redirect the output to a folder of programm test or some, and you sstill dont mixin this data with executable data, also mix produced files, with the folders of applications is bad, bnecause you will drive a not centralized data storage (and a centralized... is good in the case of data in computers... less redundancy and others things), the files that the executable produce and are stored in the application folder need be only for internall use of the application, not like a output for the user of the application.
Also see that change the viewpoint of the filesystem also drive a little how the OS look, and how the applications thread is internal data and output files, when you modify this really inside (like I think), I think you modify the enviroment.
I will still thinking in this.
Have a nice day or night.