LFS will not fix the parent's problem any more than anything else, because the answer in LFS even moreso than from RedHat and co. is "write it yourself if you want it!"
actually, the 'other poster' has changed his stance on this... now he says "please tell me how we can get the excellent OpenBSD man pages (for common packages) which you reccomend!"; if you can give me details, i will see how this would go down on the LFS lists.:-D
this is of course a short-term solution, as i hope OpenBSD are feeding their docs back to the respective program authors, and that those docs will be implemented in due course...
I agree wholeheartedly that it is the distro's job to fill in the cracks
yes, suse/redhat/debian/mandrake may indeed have resources to fill in the gaps, and i also believe it is their job to do so and feed it back to the authors, after all they get payed to do it! but LFS is not a distro in the traditional sense. it is a means to produce a distro from the sources, for what you need it to do. if you want man pages for all the commands... go ahead and write them! or why not download the OpenBSD ones and insert them into your own distro!
only a big distro company like mentioned before can (realistically) put time and manpower (no pun intended) into touching up the docs, besides the authors. if all programs had a full man page, i would be oober-happy!
Compare the man page for some random package/command on OpenBSD to the *very same one* on Linux
I really hope OpenBSD are feeding back to the program authors with regards man pages.
you seem to always be thinking of LFS as a massive binary distribution, and are complaining about the problems with generic gnu/linux distrubutions. you are missing the point that LFS is just a means to make your _own_ distro... if you find a way to pull the excellent OpenBSD man pages you mention, then please write a hint and let the community know how you did it! LFS certainly doesnt discourage such things.
however, i agree that the doc issue should sorted out; in a perfect world, all programs would have amazing man pages shipped with them. but it is not a perfect world and people are faced with many ways to write and read docs (i think info is mostly to blame for this dissociation of documentation). it needs a project in it's own right to work alongside common packages, and ensure the docs are always in check. they should feed back their work to the programs affected.
The naysayers to your problems are ignoring the fact that distributions change things all the time
yes they do... but LFS is letting you choose how to do things, and pointing you in the direction of the FHS all the time; which is about as standards compliant as possible. no distro knowingly removes man pages on purpose; it is becuase the docs were never written by the authors! it is up to individual contributors, or resource rich companies (such as the big distros) to make the difference; each program has to 'play ball'.
i think i understand your metaphor... proving that if anyone says anything random at all, a little bit of imagination can make it mean whatever you want it to say. ahh, the wonders of a semi-human mind...:-D
How do I find out what program "profile" is documented under?
you make a valid point; lots of programs havent pothered making good documentation. a good program has a man page for every binary, every function call and every.conf file it needs. an almost-good one has all the details under the one man page. a workaround would be to run
man -K "/etc/profile"
which will search all the man pages giving you an option to display the matching pages, but if the authors of a program haven't done a good job of the docs, there is not much anyone can do, short of fixing the docs themselves (only big companies like redhat/mandrake/suse haev the man power to actually do this, LFS is small and is concerned mainly with setups, not documentation content). man is indeed the place to implement this, a good example is `man lilo.conf` where the lilo people HAVE bothered to use what is available to them, everyone always forgets the man5 directory. writing another program to deal with this will not solve anything, and info, well, info is just a big pile of poo, isnt it?
You claim that a distribution cannot manage user authentication, but then who exactly DOES? The sudo folks say it's pam's job. The pam folks say it's ssh's job. ssh says it's sudo's job....
yes, this is a sad case... LFS is not a true distro, it is the means to make a distro from the program sources, which is a lot more than `make install`, believe me! (you must use *BSD, lucky you;-).) short of editing the source code, this cannot be implemented by anyoen other than the program authors. if it were possible to pass a configure flag to each of these programs, such as `./configure --authstyle=keybased`, then YES, it would be up to the distro to implement the interoperability system-wide. but this is not the case, and these programs just do not work with each other. this is not any distro's problem (unless they have coders available to work with pam/ssh people). if the problem is as bad as you say it is; the PAM/ssh/sudo people better get their fingers out. i have never experienced the problems you are mentioning... i would put the blame on PAM, as i have had lots of problems with it before. i eventually gave up when i realised everything i needed done security wise could be implemented with traditional unix permissions. i have never seen any great benefit in using sudo: `chmod u+s file `works fine for me, i just `chmod o-xrw file` and make the file group owned.
Packaging a distribution is about creating a working system out of the parts provided and any other glue that needs to be added, not about typing "make install" and walking away.
you are right, but the 'glue' in this exmaple is AFAI can tell, a complete rewrite of these 3 programs. that is hardly ' some glue'.
You make the point that paths can be edited... well, yes, but the WHOLE system needs to know that you can have files in multiple locations.
Yes, and here is something which you CAN implement quite easily system-wide on an LFS system:-D this is indeed a distro thing, not like your other points, and LFS does it well. when builidn LFS, if you are looking to implement this, you will see what needs editing along the way; but LFS is much more FHS compliant than most, and even puts large packages such as GNOME and KDE into/opt. i evcen have a/opt/non-gnu which contains (obviously) non-gnu compatible files, and i link them if a program is stubborn in requiring them to be in a particular place, but mostly i can edit any program's search path. what you ask is already implemented on my machine.
i've never understood why people put the name of the kernel in the distribution name
its only because linux sounds cool;-) if i were using the HURD as my kernel, i would most likely call it just 'gnu', but even gnu sucks as a name. bsd sucks as a name as well, and nacho... do we need to mention nacho? no we dont.
ok, i can only answer 2 of your points, but i think you are complaining about lack of support in individual programs, not somethign which a distro can take care of.
There should be a way to say "fetch documentation for x" where x is a path name to any non-user file.
surely man already does this? my man pages are valid for any command, library call or setup file on my system, are yours not? do you have an example for me, as i clearly misunderstand what you are asking. granted if i were to type `man/bin/rm` i would get rubbish becuase man would be trying to open/bin/rm as a formatted man page, but why is `man rm` not good enough for you?? if you install a new `rm` command, in say/usr/local/bin, then if you want the man page to THAT command to appear when you type `man rm`, then you can set the man path to search/usr/local/share/man first. do you mean mayeb that some of your programs are missing man pages? however, info does suck and is a project which should never have been started.
A heirarchical installation model that allows for a/usr,/opt and/usr/local which are applied to all system paths and configurations in reverse order
this can easily be implemented by editing your $PATH,/etc/ld.so.conf,/etc/man.conf and others along the way. and is this not the FHS anyway?? its certainly the way my system is set up! (and i use LFS)
A set of management tools for pam that runs the spectrum from adding a user to choosing a password hashing format to setting up an LDAP server based on an existing source
this is not something a distro can take care of.. it is a request for a program which does not exist. a distro is a collection of existing programs, if you want a program such as this, why not try the PAM email lists; im sure someone out there is either willing to write one or to help you write one. i do agree there is a lack of good user-admin programs out there, which are standalone (ie not requiring kde or linuxconf or somethign equally massive and prone to bloat).
sudo, ssh, and pam all have different views on what it means to authenticate. These views need to be merged at the distribution level into a single means of authenticating.
it seems to me like you are asking for individual applicatiosn to work together better... not something a distro can do unless the apps themselves have not reasched that maturity. all a distro is, is a compilation of already existing packages.
you seem to be asking LFS to rewrite or write individual programs... and i suggest the place you ask these questions are on the mailing lists of those programs. the problems you have are not at the level of a distribution. all a distribution can do in the end is choose which version of a program to run, which toolchain to build it with and to choose its optional dependencies. if PAM and ssh dont work together regardless, how the hell is a distro supposed to fix this?
then I have to ask if the authors of these tools are even scratching their own itch?!
again, you seem to think the people making the distro are the same people makign the programs... THEY ARE NOT THE SAME PEOPLE!!!
Since it's a set of intrustructions on how to get and use parts, I don't think you should be calling it GNU/Linux since that implies, for example, that you will not use the BSD file utilities, the Intel C compiler and many other components that are not GNU.
actually, you must still use the GNU toolchain to build most of the components; you can certainly add icc afterward if you want; but you are askign for trouble if you want to get rid of gcc from the start. of course.. be my guest to try; you can even call it BSD/Intel/LFS/BLFS if you want.
err... may i suggest `man rm` to you? (after you check out `tar --help` of course...) becuase that is effectively what redhat's package management is doing. you dont need gcc lying around if you dont use anything else! (ok, granted you probably need cpp around if you install X, as it uses the cpp to preprocess a lot of its runtime configs... but cpp is tiny). you can have a web/email server running in less than 20MB; can you do THAT with redhat? (more importantly... would you want to? disk space nowadays is so cheap its not worth the hassle).
probably! i know people have tried this kind of thing from various *BSDS, with varying levels of success. if you are informed enough to give it a go, then try your best and report your findings back to the lists! (in fact, try search.linuxfromscratch.org first)
the pdf probably says that becuase a cygwin or *BSD walkthrough would involve a lot more writing, and also the lists are getting an increasing number of idiots who dont read the intro and think that this is maybe a good way to introduce themselves to this thing called linux...
ajs; LFS is exactly what you have argued needs done. it is a set of build instructions and text on how a system works, you build EVERYTHING yourself, from source! you are in COMPLETE control over what goes in and what doesnt, you are in complete control over what the system is used for. you are in complete control over what autenticates, the hierarchy, the docs. it is NOT a make-your-own-server distro; it is a make-your-own-ANYTHING-distro. servers just happen to be able to run on GNU/Linux:-/
IMHO, LFS is the only truly unique distro out there... the rest have good points and bad points but are ultimately all the same thing, a binary distribution of GNU/Linux; LFS/BLFS is just a book.
yes, but unfortunately a lot of people are concentrating on the BLFS book now and neglecting the the hints.
i have been part of the LFS community for a few years now, just helping out on the lists and writing a few hints. The sad thing is not that BLFS exists, but that it has become more of a 'copy and paste the commands' textbook for building a system. the hints were more of a walkthrough which taught you what you were doing at each step and explained in some detail setups for larger programs. dont get me wrong, i love BLFS, but i think it has lost some of what the hints had.
another sad thing about LFS is that the punters seem to WANT copy and paste instructions... lately i have unsubscribed from the lists because new posters are always asking FAQ questions or not checking the archives. a while ago, only those keen to learn GNU/Linux in more detail (and were not afraid of the `man` command) used LFS; nowadays we just get a bunch of kids wanting us to hold their hand while they build their own distro to increase their geek factor. and new hint subissions are all silly GNU style (configure ; make install) stuff which doesnt need documented. i personally think if you want to run LFS, you have to be prepared to write a few patch files yourself for dodgy programs, involving some level of programming experience.
for the record, i still use LFS, i think it kicks ass, and the speed difference with any distro is VERY noticable (i have had others confirm this, its not just propoganda). but then, it is an addiction; you have to reach a stage where you say "ok, this is stable, i am not going to upgrade it anymore!" or you lose your real life.
the parent is not saying it is... you are the moron! he is saying that bochs can be run on debian's netbsd (running on a SPARC!!) which will run i386 operating systems.. such as MS-DOS, or just general i386-specific code. (albeit very slowly)
short version: you can run MS-DOS on a SPARC
i am sure bochs runs on any *BSD anyway, so the original post was a little redundant, but you seem to have missed the point regardless.
this is ridiculous and it will only hold back progress for everyone, even the military themselves!
trying to get 'one over' on the enemy's intelligence has always been a way for researchers to do the impossible; remember the enigma machine? they said that was impossible to crack and was of grave danger, but if the secret services had taken such a defeated attitude (which they did actually; until a polish genius showed them it was likely) would they have gotten that upper hand on the advancing nazi army? i think not...
even the claim that terrorists use open source software (especially really geeky and amazing stuff like OpenBSD) is a complete joke... i come form northern ireland and i can assure you that the sight of a computer only rings bells of "how much can i sell that on for?" in the hearts of terrorists. (oh wait! arnt we the perfect model for peace and we dont have terrorists anymore, silly me...)
yet again america needs to get a grip on itself and take a good dose of reality...
well, im sure there is some really obscure section of society which could benifit from this (see other reply in air traffic control), but i dont see what all the fuss is about either... everyone keeps talking about 'real' transparency and so forth; personally i dont see any difference between this 'real' transparency (windows users brag about this??) and the 'fake' one i get by alpha blending my aterm so it feels like i am writing my console messages on the root window... but, self admittedly, that is just desktop masterbation.
back in the day when i used the ever-bloated kde or gnome desktops, i used to be able to make my browser transparent, it just got on my nerves... resizing windows is a much easier solution to seeing things at once... and IMHO desktop elegance can only be achieved by using virtual desktops, thus reducing the general need to ever put more than one app in a desktop anyway...
whatever we are missing jm91509, i dont think its very important...
Slashdot Mirror
actually, the 'other poster' has changed his stance on this... now he says "please tell me how we can get the excellent OpenBSD man pages (for common packages) which you reccomend!"; if you can give me details, i will see how this would go down on the LFS lists. :-D
this is of course a short-term solution, as i hope OpenBSD are feeding their docs back to the respective program authors, and that those docs will be implemented in due course...
yes, suse/redhat/debian/mandrake may indeed have resources to fill in the gaps, and i also believe it is their job to do so and feed it back to the authors, after all they get payed to do it! but LFS is not a distro in the traditional sense. it is a means to produce a distro from the sources, for what you need it to do. if you want man pages for all the commands... go ahead and write them! or why not download the OpenBSD ones and insert them into your own distro!
only a big distro company like mentioned before can (realistically) put time and manpower (no pun intended) into touching up the docs, besides the authors. if all programs had a full man page, i would be oober-happy!
Compare the man page for some random package/command on OpenBSD to the *very same one* on Linux
I really hope OpenBSD are feeding back to the program authors with regards man pages.
you seem to always be thinking of LFS as a massive binary distribution, and are complaining about the problems with generic gnu/linux distrubutions. you are missing the point that LFS is just a means to make your _own_ distro... if you find a way to pull the excellent OpenBSD man pages you mention, then please write a hint and let the community know how you did it! LFS certainly doesnt discourage such things.
however, i agree that the doc issue should sorted out; in a perfect world, all programs would have amazing man pages shipped with them. but it is not a perfect world and people are faced with many ways to write and read docs (i think info is mostly to blame for this dissociation of documentation). it needs a project in it's own right to work alongside common packages, and ensure the docs are always in check. they should feed back their work to the programs affected.
The naysayers to your problems are ignoring the fact that distributions change things all the time
yes they do... but LFS is letting you choose how to do things, and pointing you in the direction of the FHS all the time; which is about as standards compliant as possible. no distro knowingly removes man pages on purpose; it is becuase the docs were never written by the authors! it is up to individual contributors, or resource rich companies (such as the big distros) to make the difference; each program has to 'play ball'.
i think i understand your metaphor... proving that if anyone says anything random at all, a little bit of imagination can make it mean whatever you want it to say. ahh, the wonders of a semi-human mind... :-D
wow! that pic made it seem a lot larger than i had figured from the original article!
just imagine how cool this would be!! 3dWM
you make a valid point; lots of programs havent pothered making good documentation. a good program has a man page for every binary, every function call and every .conf file it needs. an almost-good one has all the details under the one man page. a workaround would be to run
man -K "/etc/profile"
which will search all the man pages giving you an option to display the matching pages, but if the authors of a program haven't done a good job of the docs, there is not much anyone can do, short of fixing the docs themselves (only big companies like redhat/mandrake/suse haev the man power to actually do this, LFS is small and is concerned mainly with setups, not documentation content). man is indeed the place to implement this, a good example is `man lilo.conf` where the lilo people HAVE bothered to use what is available to them, everyone always forgets the man5 directory. writing another program to deal with this will not solve anything, and info, well, info is just a big pile of poo, isnt it?
You claim that a distribution cannot manage user authentication, but then who exactly DOES? The sudo folks say it's pam's job. The pam folks say it's ssh's job. ssh says it's sudo's job....
yes, this is a sad case... LFS is not a true distro, it is the means to make a distro from the program sources, which is a lot more than `make install`, believe me! (you must use *BSD, lucky you ;-).) short of editing the source code, this cannot be implemented by anyoen other than the program authors. if it were possible to pass a configure flag to each of these programs, such as `./configure --authstyle=keybased`, then YES, it would be up to the distro to implement the interoperability system-wide. but this is not the case, and these programs just do not work with each other. this is not any distro's problem (unless they have coders available to work with pam/ssh people). if the problem is as bad as you say it is; the PAM/ssh/sudo people better get their fingers out. i have never experienced the problems you are mentioning... i would put the blame on PAM, as i have had lots of problems with it before. i eventually gave up when i realised everything i needed done security wise could be implemented with traditional unix permissions. i have never seen any great benefit in using sudo: `chmod u+s file `works fine for me, i just `chmod o-xrw file` and make the file group owned.
Packaging a distribution is about creating a working system out of the parts provided and any other glue that needs to be added, not about typing "make install" and walking away.
you are right, but the 'glue' in this exmaple is AFAI can tell, a complete rewrite of these 3 programs. that is hardly ' some glue'.
You make the point that paths can be edited... well, yes, but the WHOLE system needs to know that you can have files in multiple locations.
Yes, and here is something which you CAN implement quite easily system-wide on an LFS system :-D this is indeed a distro thing, not like your other points, and LFS does it well. when builidn LFS, if you are looking to implement this, you will see what needs editing along the way; but LFS is much more FHS compliant than most, and even puts large packages such as GNOME and KDE into /opt. i evcen have a /opt/non-gnu which contains (obviously) non-gnu compatible files, and i link them if a program is stubborn in requiring them to be in a particular place, but mostly i can edit any program's search path. what you ask is already implemented on my machine.
i've never understood why people put the name of the kernel in the distribution name
its only because linux sounds cool ;-) if i were using the HURD as my kernel, i would most likely call it just 'gnu', but even gnu sucks as a name. bsd sucks as a name as well, and nacho... do we need to mention nacho? no we dont.
ok, i can only answer 2 of your points, but i think you are complaining about lack of support in individual programs, not somethign which a distro can take care of.
There should be a way to say "fetch documentation for x" where x is a path name to any non-user file.
surely man already does this? my man pages are valid for any command, library call or setup file on my system, are yours not? do you have an example for me, as i clearly misunderstand what you are asking. granted if i were to type `man /bin/rm` i would get rubbish becuase man would be trying to open /bin/rm as a formatted man page, but why is `man rm` not good enough for you?? if you install a new `rm` command, in say /usr/local/bin, then if you want the man page to THAT command to appear when you type `man rm`, then you can set the man path to search /usr/local/share/man first. do you mean mayeb that some of your programs are missing man pages? however, info does suck and is a project which should never have been started.
A heirarchical installation model that allows for a /usr, /opt and /usr/local which are applied to all system paths and configurations in reverse order
this can easily be implemented by editing your $PATH, /etc/ld.so.conf, /etc/man.conf and others along the way. and is this not the FHS anyway?? its certainly the way my system is set up! (and i use LFS)
A set of management tools for pam that runs the spectrum from adding a user to choosing a password hashing format to setting up an LDAP server based on an existing source
this is not something a distro can take care of.. it is a request for a program which does not exist. a distro is a collection of existing programs, if you want a program such as this, why not try the PAM email lists; im sure someone out there is either willing to write one or to help you write one. i do agree there is a lack of good user-admin programs out there, which are standalone (ie not requiring kde or linuxconf or somethign equally massive and prone to bloat).
sudo, ssh, and pam all have different views on what it means to authenticate. These views need to be merged at the distribution level into a single means of authenticating.
it seems to me like you are asking for individual applicatiosn to work together better... not something a distro can do unless the apps themselves have not reasched that maturity. all a distro is, is a compilation of already existing packages.
you seem to be asking LFS to rewrite or write individual programs... and i suggest the place you ask these questions are on the mailing lists of those programs. the problems you have are not at the level of a distribution. all a distribution can do in the end is choose which version of a program to run, which toolchain to build it with and to choose its optional dependencies. if PAM and ssh dont work together regardless, how the hell is a distro supposed to fix this?
then I have to ask if the authors of these tools are even scratching their own itch?!
again, you seem to think the people making the distro are the same people makign the programs... THEY ARE NOT THE SAME PEOPLE!!!
Since it's a set of intrustructions on how to get and use parts, I don't think you should be calling it GNU/Linux since that implies, for example, that you will not use the BSD file utilities, the Intel C compiler and many other components that are not GNU.
actually, you must still use the GNU toolchain to build most of the components; you can certainly add icc afterward if you want; but you are askign for trouble if you want to get rid of gcc from the start. of course.. be my guest to try; you can even call it BSD/Intel/LFS/BLFS if you want.
on a more helpfull level, i point you to an absolute minimal LFS hint
damn right; now why did i get modded down for saying the same thing? hmm...
the pdf probably says that becuase a cygwin or *BSD walkthrough would involve a lot more writing, and also the lists are getting an increasing number of idiots who dont read the intro and think that this is maybe a good way to introduce themselves to this thing called linux...
ajs; LFS is exactly what you have argued needs done. it is a set of build instructions and text on how a system works, you build EVERYTHING yourself, from source! you are in COMPLETE control over what goes in and what doesnt, you are in complete control over what the system is used for. you are in complete control over what autenticates, the hierarchy, the docs. it is NOT a make-your-own-server distro; it is a make-your-own-ANYTHING-distro. servers just happen to be able to run on GNU/Linux :-/
IMHO, LFS is the only truly unique distro out there... the rest have good points and bad points but are ultimately all the same thing, a binary distribution of GNU/Linux; LFS/BLFS is just a book.
i have been part of the LFS community for a few years now, just helping out on the lists and writing a few hints. The sad thing is not that BLFS exists, but that it has become more of a 'copy and paste the commands' textbook for building a system. the hints were more of a walkthrough which taught you what you were doing at each step and explained in some detail setups for larger programs. dont get me wrong, i love BLFS, but i think it has lost some of what the hints had.
another sad thing about LFS is that the punters seem to WANT copy and paste instructions... lately i have unsubscribed from the lists because new posters are always asking FAQ questions or not checking the archives. a while ago, only those keen to learn GNU/Linux in more detail (and were not afraid of the `man` command) used LFS; nowadays we just get a bunch of kids wanting us to hold their hand while they build their own distro to increase their geek factor. and new hint subissions are all silly GNU style (configure ; make install) stuff which doesnt need documented. i personally think if you want to run LFS, you have to be prepared to write a few patch files yourself for dodgy programs, involving some level of programming experience.
for the record, i still use LFS, i think it kicks ass, and the speed difference with any distro is VERY noticable (i have had others confirm this, its not just propoganda). but then, it is an addiction; you have to reach a stage where you say "ok, this is stable, i am not going to upgrade it anymore!" or you lose your real life.
short version: you can run MS-DOS on a SPARC
i am sure bochs runs on any *BSD anyway, so the original post was a little redundant, but you seem to have missed the point regardless.
or a VIC-20 on a C64 emulator on an amiga emulator on x86 emulator (bochs) within an x86 emulator on 1.5Ghz... :-D
from bedford, or london... luton sucks
sorry, couldnt find a page which had all the optional answers... anybody?
didnt you mean:
Why don't they release XXX on IMax instead
how the hell did they get a .org??? they are clearly commercial!!
trying to get 'one over' on the enemy's intelligence has always been a way for researchers to do the impossible; remember the enigma machine? they said that was impossible to crack and was of grave danger, but if the secret services had taken such a defeated attitude (which they did actually; until a polish genius showed them it was likely) would they have gotten that upper hand on the advancing nazi army? i think not...
even the claim that terrorists use open source software (especially really geeky and amazing stuff like OpenBSD) is a complete joke... i come form northern ireland and i can assure you that the sight of a computer only rings bells of "how much can i sell that on for?" in the hearts of terrorists. (oh wait! arnt we the perfect model for peace and we dont have terrorists anymore, silly me...)
yet again america needs to get a grip on itself and take a good dose of reality...
Nietzche is God -- (dead)
Neitzche is dead. (God)
back in the day when i used the ever-bloated kde or gnome desktops, i used to be able to make my browser transparent, it just got on my nerves... resizing windows is a much easier solution to seeing things at once... and IMHO desktop elegance can only be achieved by using virtual desktops, thus reducing the general need to ever put more than one app in a desktop anyway...
whatever we are missing jm91509, i dont think its very important...
... just to say "42"!
head in hands at ignorance of parent.. i hope you were being sarcy!
haha, i though someone had re-nicknamed him "piracy *yawn*", since that is how you pronounce jon in dutch, maybe the same in norsk?