This is the person "p" walk:
The p started looking into the source-> got some hours trying to find the documentation->he found it->but forgot it because of the lack of organization into this source package->he made patches to organize the layout and some little fixes of some basic functionalities of Makefile files(install, uninstall, doc,lib)->he got some problems because its not his job, its developers job, ok(utopia)-> he got the program working fine, made the package, but->a new version came, and the p had to start all things over again, ...
Sad story, isn't it?
The Unix, old one that lead us make a lot of descendents based on him, has a standard(not good because its based on compatibility, not a clean and good design, just the principle is nice, share, un-shared data, variable and unvariable data.) today, how many people apply, administrators only i guess, only in servers using just one feature of read-only, mostly in some areas i believe like web services to not get script kiddies kidding with their webpage and databases.
Ok, it's good, at least we known where to find things like documentation, binaries.
Hmmm, lets think a bit, does make sense differentiate sbin than bin?
Thats a difference based on purpose, we have about 1M of for each software.
Why not tag it and just put all those things under some essencial divisions?
And more... somethings doesn't get used, so here it's my blog, here it's my opinion about some "layouts".
Filesystem layout
- /bin:all binaries or stand alone executables.
- /doc:all the documentation(just html or xml).
- /cfg:global and specific configuration for each software(could be in xml).
- /data:everything thats not in others directories.
/<software-name>
This keep with the usual names people give to compiled software(bin), documentation(doc), cfg( configuration, that what we should find in the /etc) and the temporary and storage area for each software/application(data).
Source package layout
- /src:all the source code.
- /doc:all the documentation(just html or xml), this includes things like COPYING, README, etc.
- /cfg:global ans specific configuration for each software(could be in xml).
- /data:everything thats not in others directories.
prevent future stupid bugs because of the grow of unorganization and lack of common sense.
What have to be different must be the features of the software, not its organization, if no, how others will start coding and enhancing these softwares?
Today we have a lot of open source softwares, look for example the sourceforge one of the main repository for open source software, think about some years, 10, look the Debian database, this will be a problem in the future for the maintainers, the the effort to make things better is comming just from the distributions.
Come on developers, lets make that source a bit better, we love your software, we just want you do the basic when you want publish you nice software ;)
No comments:
Post a Comment