but that IS the *UNIX standard to keep all the config files in/etc!!!! its is the fault of the program maintainers to not put things in there.... regardless of where a program is installed, it's configs shoudl still go in/etc. you have just shown another reason why the *NIX structure is logical;-)
a "single standard"?? what, as in "military intelligence"... standards are adopted by everyone; i hardly call yet another distro making yet another FS hierarchy change "standardises" anything!
i think you will find "OS A", she will she her home directory, which the distro will clearly mark out as looking the same as OS B. you seem to be confusing several issues here... we are all talking about the SYSTEM FS hierarchy, and you are talking about the USER'S!
in fact, libraries are a new thing... in those days everything was statically linked. i really dont see how this relates to RAM being cheap though... or how you see gobo as being 'logical' when the *NIX filesystem is the perfect example of a logical FS heirarchy. if you dont see it as logical, then you don't understand it.
but you gotta ask... why would anyone WANT to know where the program they installed went? they have an RPM GUI or something which has a "(Un)Install Program" botton, which is all they need. also, the GUI will list where everything is if they really want. people coming from windows must realise that GNU/Linux does not require you to KNOW where anything is installed... it just works. you have YOUR files in your home directory, and the system takes care of how the programs work
i have seen this "where are the programs" effect when i put GNU/Linux on my dad's machine; he spent the first few days looking for where mozilla etc. was installed and i had to keep tellign him "look, you dont need to leave your home directory. if you want to run mozilla; click the button, or just type `mozilla` on the command line". it took him a while to get used to it, but he eventually realised that he could get on with gettign used to the new programs and gettgin some work done!! (i kept hearing cries of "that looks much better than it did under windows!"); but, i did spend a bit of time setting up the blackbox menus for programs i knew he would use more often; and calling them obvious names like "email" and "spreadsheet".
you clearly didnt install it yourself, so you use something like redhat package manager then? why didnt you just ask IT to tell you?
or more effeciently, you could type `whereis realplayer` or `locate realplayer`. there was no need to do a full system find. GNU/Linux is a type of UNIX, so these commands are there. use them, or use windows. (BTW there are GUI's available, maybe use them instead...)
/programs is only more understandable to you becuase you speak english. what about non-english speakers? and/bin is a lot easier becuase the binary be in there, whereas gobo has the actual binaries in "/programs/name/version/bin", achieving nothing...
Why is it really necessary to "getting used to a new filesystem"? Do you really want to waste time doing this?
no, you don't; becuase under any *NIX, the system is kept seperate form the user's files, so whether a binary is kept in/usr/local/bin or/packages/some arb pakage/version/binaries (reminds me of devfs:-/), the user doesnt need to know when they open up the file manager to ~/ (or "My Documents" as they may call it) or click an icon that points to said binary. btw, your system is not very good for non-english speakers!
no actually, that would be your equivalent of my/opt/mozilla/plugins. if you run winXP i know for a fact that if you install plugins for yourself, not system-wide (winXP is multiuser, right?) then mozzy will install those plugins EXACTLY where i said:
default/*.slt/plugins
relative to your personal mozzila directory. 'personal program settings' data (as opposed to "My Documents" etc.) under windows are always in some arbitrary location in the directory structure for a given program. all *NIX store personal data in the user's home directory. i typed this in without even looking at my FS; can you tell me where yours is? bet you can't, without using file-manager...
users DO NOT see the system directory structure, that is the difference with windows... the / is for `root` (or `gobo`) to worry about, all the user sees is ~/
only the curious will go looking for where programs are kept, and there is plenty of documentation on the subject. it is also very sensible and much more intuitive than gobo's method... how can you easily tell how big a directory is in 'gobo' if everything is a symlink.. how can you ensure you are running the right versions of everything... when upgrading anything, how can you check all the symlinks have been updated... how often should i check for dead symlinks?? how do i lockdown the system this way? just about every HOWTO and man/info page ever written is now redundant... and what exactly has it achieved?
do these newbies not have a package manager to handle all these things for them? when was the last time YOU ever had to go looking in/usr/local for ANYTHING?? and if you did, why? i run LFS and if i install a program which requires users to go lookign in $prefix/share for anything; then as an extreme, i make a local ~/.package folder in which i symlink the data, and make sure that program opens up its file browser in that directory.
how exactly is this improving it? the article claims "no more compatibility problems" becuase everythign is all in the same place... how was this ever an in-compatibility problem?? the dynamic linker looks in all the folders and uses the one it sees first... not a user problem at all. it also ADDS incompatibility, because now i cant have multiple versions of certain libs (with identical names) lying around, so that i can choose which set i want to link to. this IS an issue with some commercial code, compiled against older libraries; normally the link path can be changed automatically in a script file. this new FS hierarchy would have many MANY lines in that script file to change the LD_LIBRARY_PATH for a set of libraries.
and i really do have to say "if it's not broke, don't fix it!" not because it ISNT broken (which it isnt anymore thanks to the LSB) but becuase it has been refined many times over... and is very sensible. my system-wide mozilla plugins are saved in/opt/mozilla/plugins, (i thought that was intuitive..) and if users want their own without installing system-wide, they install them in ~/.mozilla/default/*.slt/plugins... EXACTLY where macOS and windows users save them as well!!
dont be ridiculous... those FS are designed with efficiency in mind, and careful refining of 30+ years of UNIX experience. just becuase the FS hierarchy is different from windows is not a good enough reason to change it. people worry too much about how these 'newbies' are goign to think about GNU/Linux, when in the end, getting used to a new filesystem is not a hard thing, with some form of "intro to GNU/Linux" book in front of you you can learn the basics in a day. add on top of that, end-users (non-root accounts) do not even NEED to see the FS hierarchy, they see/home/$USER and that is easy-peesy to understand.
/usr and/usr/local are entirely different things, and not the worry of users. they are also very intuitive./usr is standard system stuff,/usr/local is locally hacked stuff, so i can place 'my' hacked version of any program in/usr/local and override the system one (if i were the sysadmin).
this whole FS reshaping is a rediculous idea and goes against everything the LSB has been tryig to fix, since there are so many deviants of GNU/Linux. i hope this distro dies off damn quickly... (how to lose all your karma in 10 seconds)
Linus Torvalds wants to incoroporate DRM, yet many others don't.
actually, you have taken it a little out of context... linus wants to code the ability for end users and distros to use DRM in the kernel; which may be a good thing for security (opposed to M$ reasons for DRM). he is not 'enabling' it. if i build a kernel, i can most certainly turn it off, and even if i run a DRM'ed redhat distro, i can STILL recompile and turn it off. in fact, i wont even need to turn it off, since off will be the default.
as to who is a representative, well we need more than one... RMS is willing, linus is not, and there are more movements than just GNU... open source groups also have head honchos and commities, and it is their job to sort it out.
the reason why these organisations (eg GNU, OSI) were set up was to allow them to take care of political and legal stuff in the big picture. if someone is really a part of the community, they will just keep coding and let those guys sort it out...
the optimisation really only comes in to play if the whole system has been optimised for a particular host. often just changing gcc to a more modern version is enough; changing i386 even to pentium4 with mmx/sse/sse2 has not given me much of a performance increase for everyday use (except in numerical code), but gcc-3.2 (on LFS) was resposible for insane speedups over my old mandrake!
is not JUST a GNU/Linux installion method, that is why it is not completley intuitive to everyone... the "configure" part is cross platform, setting up everything for any variation of UNIX or even for apple/M$ in certain cases.
IMHO GNU did a great job of creating this wonderful "configure make install" method for cross platform compilation, and compilation of programs really would be easy if authors just stuck to this technique instead of writing their own totally weird compilation methods. we do not need a new installion method... we just need authors to stick to the already existing standards!
besides, to most end users, they will only see RPM/DEB files, and lets face it... they are trivial to install; if a program isnt compiled on your version of redhat/mandrake or whatever, just issue an `rpm --rebuild ` and it'll build the file for you. with `man rpm` at hand, you cant get any more intuitive than that. your vendor will even set up galeon/konqueror/mozzy to load the package management tool when you click to download an RPM/DEB file. this article is looking for answers in all the wrong places...
KDE, which was previously "not free as in freedom".
i dont understand why RMS would be angry at the KDE team at all now... they use the GPL (and so does the QT library, despite popular belief). whereas GTK+ (which GNOME is built on) uses the LGPL . it seems ironic that RMS would therefore support GNOME over KDE, when KDE use his 'favourite' licence...
also, there was no need for RMS to ask such a redundant question as "GNU/Linux or Linux?" to the team, he could have looked here;-)
does anyone have a mirror of this story? the server has been totally slashdotted...
i agree completely... a standard [insert big brand gnulinux/*BSD here] distro has, what, a few thousand different packages. if each program has even ONE credit given to it, we are talking about so many names in the CREDITS on the back of the box that you wont be able to tell what the product is anymore!!!
everyone who writes a gnu/oss program knows what they are gettign into before they start. RMS may seek credit everywhere he goes... but he wants credit given to GNU, not for himself! Reiser, on the other hand, even called his FS after himself...
with GNU/OSS, any author is fully able to place a "Help->About" window in, or "--version" flag. by this method, i ALREADY know the names of the main authors of all the programs i use every day... with an exception to Maple (which along with java are the only non-OSS/GNU apps i have...)
i though you were saying that the OpenBSD team had gone through and written man pages for programs which did not have man pages:-/. as you say, and as i also mentioned; it really would be ridiculous to just place these straight into a gnu/linux distro, i was hoping i could seperate the docs they wrote for gnu apps and possibly bundle them with LFS. but no, this is not possible. LFS is far too small a 'distro' to write the missing man pages, that should really be left to a binary-only distro which has reached osme level of stability and has time to write the docs. or hope the individual authors write some... (never gonna happen)
thankyou for that, however, you do realise that even
man pam_smb.conf man pine.conf man printconf.local man profile
do not work under OpenBSD. i guess even openbsd haven't done this job correctly.
i tried looking at this and the man page width needs editing somewhat to get them to display. also, reformating the pages to the linux man is going to take some time; let alone the time it would take to remove unwanted man pages (such as those already existing and thigs like `man pkg_create`). also we would be left with some programs which are not even the same version, eg `man tar`
basically i think this is more trouble than it is worth and it is best to wait until the OpenBSD team feed back any changes they made to GNU (or opensource) packages in due course.
rather than crafting yet another from-scratch compilation
I think LFS is the only such option (besides the optional PLFS hacks) for makign a distro from scratch. it has been around since about, actually i dont know! but before distros like mandrake anyway....
Slashdot Mirror
but that IS the *UNIX standard to keep all the config files in /etc!!!! its is the fault of the program maintainers to not put things in there.... regardless of where a program is installed, it's configs shoudl still go in /etc. you have just shown another reason why the *NIX structure is logical ;-)
a "single standard"?? what, as in "military intelligence"... standards are adopted by everyone; i hardly call yet another distro making yet another FS hierarchy change "standardises" anything!
i think you will find "OS A", she will she her home directory, which the distro will clearly mark out as looking the same as OS B. you seem to be confusing several issues here... we are all talking about the SYSTEM FS hierarchy, and you are talking about the USER'S!
in fact, libraries are a new thing... in those days everything was statically linked. i really dont see how this relates to RAM being cheap though... or how you see gobo as being 'logical' when the *NIX filesystem is the perfect example of a logical FS heirarchy. if you dont see it as logical, then you don't understand it.
i have seen this "where are the programs" effect when i put GNU/Linux on my dad's machine; he spent the first few days looking for where mozilla etc. was installed and i had to keep tellign him "look, you dont need to leave your home directory. if you want to run mozilla; click the button, or just type `mozilla` on the command line". it took him a while to get used to it, but he eventually realised that he could get on with gettign used to the new programs and gettgin some work done!! (i kept hearing cries of "that looks much better than it did under windows!"); but, i did spend a bit of time setting up the blackbox menus for programs i knew he would use more often; and calling them obvious names like "email" and "spreadsheet".
or more effeciently, you could type `whereis realplayer` or `locate realplayer`. there was no need to do a full system find. GNU/Linux is a type of UNIX, so these commands are there. use them, or use windows. (BTW there are GUI's available, maybe use them instead...)
but only for one folder... very crudely i might add.
/programs is only more understandable to you becuase you speak english. what about non-english speakers? and /bin is a lot easier becuase the binary be in there, whereas gobo has the actual binaries in "/programs/name/version/bin", achieving nothing...
i dont see many people using it...
no, you don't; becuase under any *NIX, the system is kept seperate form the user's files, so whether a binary is kept in /usr/local/bin or /packages/some arb pakage/version/binaries (reminds me of devfs :-/), the user doesnt need to know when they open up the file manager to ~/ (or "My Documents" as they may call it) or click an icon that points to said binary. btw, your system is not very good for non-english speakers!
no actually, that would be your equivalent of my /opt/mozilla/plugins. if you run winXP i know for a fact that if you install plugins for yourself, not system-wide (winXP is multiuser, right?) then mozzy will install those plugins EXACTLY where i said:
default/*.slt/plugins
relative to your personal mozzila directory. 'personal program settings' data (as opposed to "My Documents" etc.) under windows are always in some arbitrary location in the directory structure for a given program. all *NIX store personal data in the user's home directory. i typed this in without even looking at my FS; can you tell me where yours is? bet you can't, without using file-manager...
mkdir ~/My\ Documents
users DO NOT see the system directory structure, that is the difference with windows... the / is for `root` (or `gobo`) to worry about, all the user sees is ~/
only the curious will go looking for where programs are kept, and there is plenty of documentation on the subject. it is also very sensible and much more intuitive than gobo's method... how can you easily tell how big a directory is in 'gobo' if everything is a symlink.. how can you ensure you are running the right versions of everything... when upgrading anything, how can you check all the symlinks have been updated... how often should i check for dead symlinks?? how do i lockdown the system this way? just about every HOWTO and man/info page ever written is now redundant... and what exactly has it achieved?
do these newbies not have a package manager to handle all these things for them? when was the last time YOU ever had to go looking in /usr/local for ANYTHING?? and if you did, why? i run LFS and if i install a program which requires users to go lookign in $prefix/share for anything; then as an extreme, i make a local ~/.package folder in which i symlink the data, and make sure that program opens up its file browser in that directory.
and i really do have to say "if it's not broke, don't fix it!" not because it ISNT broken (which it isnt anymore thanks to the LSB) but becuase it has been refined many times over... and is very sensible. my system-wide mozilla plugins are saved in /opt/mozilla/plugins, (i thought that was intuitive..) and if users want their own without installing system-wide, they install them in ~/.mozilla/default/*.slt/plugins... EXACTLY where macOS and windows users save them as well!!
this whole FS reshaping is a rediculous idea and goes against everything the LSB has been tryig to fix, since there are so many deviants of GNU/Linux. i hope this distro dies off damn quickly... (how to lose all your karma in 10 seconds)
Linus Torvalds wants to incoroporate DRM, yet many others don't.
actually, you have taken it a little out of context... linus wants to code the ability for end users and distros to use DRM in the kernel; which may be a good thing for security (opposed to M$ reasons for DRM). he is not 'enabling' it. if i build a kernel, i can most certainly turn it off, and even if i run a DRM'ed redhat distro, i can STILL recompile and turn it off. in fact, i wont even need to turn it off, since off will be the default.
as to who is a representative, well we need more than one... RMS is willing, linus is not, and there are more movements than just GNU... open source groups also have head honchos and commities, and it is their job to sort it out.
the reason why these organisations (eg GNU, OSI) were set up was to allow them to take care of political and legal stuff in the big picture. if someone is really a part of the community, they will just keep coding and let those guys sort it out...
the optimisation really only comes in to play if the whole system has been optimised for a particular host. often just changing gcc to a more modern version is enough; changing i386 even to pentium4 with mmx/sse/sse2 has not given me much of a performance increase for everyday use (except in numerical code), but gcc-3.2 (on LFS) was resposible for insane speedups over my old mandrake!
is not JUST a GNU/Linux installion method, that is why it is not completley intuitive to everyone... the "configure" part is cross platform, setting up everything for any variation of UNIX or even for apple/M$ in certain cases.
IMHO GNU did a great job of creating this wonderful "configure make install" method for cross platform compilation, and compilation of programs really would be easy if authors just stuck to this technique instead of writing their own totally weird compilation methods. we do not need a new installion method... we just need authors to stick to the already existing standards!
besides, to most end users, they will only see RPM/DEB files, and lets face it... they are trivial to install; if a program isnt compiled on your version of redhat/mandrake or whatever, just issue an `rpm --rebuild ` and it'll build the file for you. with `man rpm` at hand, you cant get any more intuitive than that. your vendor will even set up galeon/konqueror/mozzy to load the package management tool when you click to download an RPM/DEB file. this article is looking for answers in all the wrong places...
i dont understand why RMS would be angry at the KDE team at all now... they use the GPL (and so does the QT library, despite popular belief). whereas GTK+ (which GNOME is built on) uses the LGPL . it seems ironic that RMS would therefore support GNOME over KDE, when KDE use his 'favourite' licence...
also, there was no need for RMS to ask such a redundant question as "GNU/Linux or Linux?" to the team, he could have looked here ;-)
does anyone have a mirror of this story? the server has been totally slashdotted...
5.8.1??? i thought the latest stable was 5.8.0
http://archive.linuxfromscratch.org/mail-archives/ lfs-dev/2003/05/0089.html
sorry, couldnt be bothered with formatting :-)
try any of these:
or if it has a GUI, go to "Help->About"everyone who writes a gnu/oss program knows what they are gettign into before they start. RMS may seek credit everywhere he goes... but he wants credit given to GNU, not for himself! Reiser, on the other hand, even called his FS after himself...
with GNU/OSS, any author is fully able to place a "Help->About" window in, or "--version" flag. by this method, i ALREADY know the names of the main authors of all the programs i use every day... with an exception to Maple (which along with java are the only non-OSS/GNU apps i have...)
i though you were saying that the OpenBSD team had gone through and written man pages for programs which did not have man pages :-/. as you say, and as i also mentioned; it really would be ridiculous to just place these straight into a gnu/linux distro, i was hoping i could seperate the docs they wrote for gnu apps and possibly bundle them with LFS. but no, this is not possible. LFS is far too small a 'distro' to write the missing man pages, that should really be left to a binary-only distro which has reached osme level of stability and has time to write the docs. or hope the individual authors write some... (never gonna happen)
do not work under OpenBSD. i guess even openbsd haven't done this job correctly.
i tried looking at this and the man page width needs editing somewhat to get them to display. also, reformating the pages to the linux man is going to take some time; let alone the time it would take to remove unwanted man pages (such as those already existing and thigs like `man pkg_create`). also we would be left with some programs which are not even the same version, eg `man tar`
basically i think this is more trouble than it is worth and it is best to wait until the OpenBSD team feed back any changes they made to GNU (or opensource) packages in due course.
I think LFS is the only such option (besides the optional PLFS hacks) for makign a distro from scratch. it has been around since about, actually i dont know! but before distros like mandrake anyway....