Jeremy Huntwork wrote:
make HELPSUBLOC=/usr/share/doc/vim-6.3 -C src
make HELPSUBLOC=/usr/share/doc/vim-6.3 -C src install
The above could be replaced with a sed:
sed -i 's:$(VIMRTLOC)$(HELPSUBDIR):/usr/share/doc/vim-6.3:' src/Makefile
./configure ...
make
make install
That sed also change
On 8/4/05, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
> The LFS-6.1 book creates the /usr/lib/libcurses.so -> libncurses.so
> symlink during ncurses installation. A possible problem is that ldconfig
> also looks at that symlink. So after running the following commands as root:
>
> cd /usr/li
Hi all,
Attached is a patch which can be applied to trunk (and other branches
as well, I think) which will provide instructions to run the Module Init
Tools test suite and fix BZ #1597.
I read in the bug where Matt was concerned about providing two set of
instructions, this patch provides instruc
Randy McMurchy wrote:
Hi all,
Attached is a patch which can be applied to trunk (and other branches
as well, I think) which will provide instructions to run the Module Init
Tools test suite and fix BZ #1597.
Thanks a lot. It seems to address my concerns nicely!
+If you wish to run the test s
Matthew Burgess wrote these words on 08/04/05 13:01 CST:
> Randy McMurchy wrote:
>
>>+If you wish to run the test suite for Module-Init-Tools, download the
>>+separate tarball and unpack it along with the source tarball.
>
> What tarball? Now, as it's optional, do we link to it from
> chapter03
Randy McMurchy wrote these words on 08/04/05 13:11 CST:
> Well, I thought about that, but because the version number of the
> testsuite tarball and the source tarball are the same (unlike the
> Bash tarball and the Bash Docs tarball) and the fact they are
> downloaded from the same directory (poin
On 8/4/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
>
> Incidentally, in Tush's original report he mentioned that "Additionally,
> running make check messes up the built executables". 2 questions
> related to that then:
>
> 1. What exactly is "messed up" about them? and
> 2. Are they similarly
Hi all,
Noted in the NEWS file for the Shadow package is that that mkpasswd
program was removed in the 4.0.10 version. I cannot confirm this as
I am updating to 4.0.11.1. You may want to check and see if this
program exists. If not, the book should be updated to reflect this.
http://ftp.pld.org.p
Randy McMurchy wrote:
Hi all,
Noted in the NEWS file for the Shadow package is that that mkpasswd
program was removed in the 4.0.10 version. I cannot confirm this as
I am updating to 4.0.11.1.
Thanks Randy. I'll deal with this during the next shadow upgrade. I'm
now thinking we may as well
Hi all,
Something I've thought about for a long time, and now that CrackLib
is a maintained and stable package, I would like to propose that the
community consider adding this package to Chapter 6 in the LFS build.
Here are some things to consider.
1) A system is not secure if strong passwords a
It's an addon, not a required package. I just don't think it's place is
in LFS or Cross-LFS. I think BLFS is the perfect place, since it's an
optional package.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/l
Jim Gifford wrote these words on 08/04/05 17:10 CST:
> It's an addon, not a required package. I just don't think it's place is
> in LFS or Cross-LFS. I think BLFS is the perfect place, since it's an
> optional package.
I agree with you in that it is optional. However, there are lots of
packages
Jim Gifford wrote:
It's an addon, not a required package. I just don't think it's place is
in LFS or Cross-LFS. I think BLFS is the perfect place, since it's an
optional package.
I'm not so sure. We have a lot of packages that aren't actually
*required* for the build (autotools, mktemp, zlib
Matthew Burgess wrote these words on 08/04/05 17:29 CST:
> http://sourceforge.net/projects/cracklib (Randy's proposal)
> http://www.fifi.org/doc/cracklib2/ (A debian package)
> http://www.crypticide.com/users/alecm/ (The original library and until
> now the only cracklib I knew of!)
For the reco
On 8/4/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
>
> I'm not so sure. We have a lot of packages that aren't actually
> *required* for the build (autotools, mktemp, zlib, readline, etc.). I
> think, as time goes on, that's becoming an increasingly poor criteria to
> assess a package on. I'm
Alexander E. Patrakov wrote:
> lrwxrwxrwx 1 root root 12 Jun 23 12:14 libncurses.so.5 -> libcurses.so
>
> Note the last symlink (created by ldconfig).
Hmmm, well spotted. I'd never noticed it before..
> I don't know if it is a
> real problem (but it sometimes shows e.g. in ldd /bin/bash o
Tushar Teredesai wrote these words on 08/04/05 17:59 CST:
> I would like to propose that before adding/removing packages from the
> book, we should formalize what packages can be included in the book
> (Jeroen had already started the process of formalizing the process
> before he left, maybe that
Randy McMurchy wrote:
Hi all,
Something I've thought about for a long time, and now that CrackLib
is a maintained and stable package, I would like to propose that the
community consider adding this package to Chapter 6 in the LFS build.
Here are some things to consider.
1) A system is not secu
Randy McMurchy wrote:
However, LFS history has shown that we cannot count on such a document
to become formalized.
I'm not sure if a formal set of rules is in fact possible. If we
consider the packages that are in the book at the moment, they can be
broken down into roughly these areas:
1
Matthew Burgess wrote:
room to manouevre
Ack! Brit-speke!
/me runs screaming. ;)
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Jeremy Huntwork wrote these words on 08/04/05 18:18 CST:
> Is it a common enough (ie, several mainstream distros include it by
> default) package to mandate that every LFS user build and install it?
I really don't know, Jeremy. I don't mess around enough with other
Distros to be qualified to an
There any many different methods for user authentication and password
setup. If it's just about creating a secure password, we should add
npasswd. http://www.utexas.edu/cc/unix/software/npasswd
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
ht
On Thu, Aug 04, 2005 at 01:31:56PM -0500, Tushar Teredesai wrote:
>
> By messed up I meant that if you use the normal way of running tests:
>./configure --prefix=/usr &&
>make &&
>make -k check || true &&
>make install
>
> The make check will run configure again (twice actually) a
Jim Gifford wrote these words on 08/04/05 18:33 CST:
> There any many different methods for user authentication and password
> setup. If it's just about creating a secure password, we should add
> npasswd. http://www.utexas.edu/cc/unix/software/npasswd
Not to argue your position on this Jim, but
Archaic wrote these words on 08/04/05 18:30 CST:
> Perhaps I'm being to anal about it, but I see little to no value in
> building binaries, testing them, then wiping them and building new
> binaries. IOW, it doesn't test anything other than the _possibility_
> that the next binaries _might_ be goo
On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Jim Gifford wrote these words on 08/04/05 18:33 CST:
> > There any many different methods for user authentication and password
> > setup. If it's just about creating a secure password, we should add
> > npasswd. http://www.utexas.edu/cc/unix/so
On 8/5/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote:
> > Hi all,
>
> Is it a common enough (ie, several mainstream distros include it by
> default) package to mandate that every LFS user build and install it?
> Are there any disadvantages to including it in the LFS book?
>
On Aug 4, 2005, at 6:18 PM, Jeremy Huntwork wrote:
Randy McMurchy wrote:
Are there any disadvantages to including it in the LFS book?
There's at least one -- it's extra junk that gets in the way if you
use any other library that provide password complexity checking.
After fighting to make
Zachary Kotlarek wrote these words on 08/04/05 19:04 CST:
> Another issue is that cracklib only helps you enforce whatever
> password policies cracklib likes. So if your password complexity
> policy doesn't match the one that cracklib enforces it's again just
> extra junk that gets in the wa
Randy McMurchy wrote these words on 08/04/05 19:12 CST:
> This is a stretch. To the best of my knowledge, all the CrackLib
> library does is check that the password a user enters during the
> password changing routine does not match something in the user's
> entry in /etc/passwd and the password d
On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote these words on 08/04/05 19:12 CST:
>
> > This is a stretch. To the best of my knowledge, all the CrackLib
> > library does is check that the password a user enters during the
Regardless, if the end user doesn't like/want
Randy McMurchy wrote:
Should we only do what other Distros do? Can LFS not be innovative
and take a lead in something, and have other Distros follow us?
That's not really what I meant to imply. Of course I'm not all about
just doing what everyone else is doing - if I were I wouldn't be
associ
On 8/4/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Is it a common enough (ie, several mainstream distros include it by
> default) package to mandate that every LFS user build and install it?
Gentoo includes it by default (i.e. no use flags when compiling shadow).
--
Tushar Teredesai
mail
steve crosby wrote:
Regardless, if the end user doesn't like/want the policy, all that's
required is to skip this package installation, much the same as people
can currently skip things like gettext, module-init tools, etc.
Well, add it without question then. As long as the book mentions that
steve crosby wrote these words on 08/04/05 19:56 CST:
> Regardless, if the end user doesn't like/want the policy, all that's
> required is to skip this package installation, much the same as people
> can currently skip things like gettext, module-init tools, etc.
I'm not sure about that. My testi
On 8/4/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote:
>
> > However, LFS history has shown that we cannot count on such a document
> > to become formalized.
>
> I'm not sure if a formal set of rules is in fact possible. If we
> consider the packages that are in the book a
On 8/4/05, steve crosby <[EMAIL PROTECTED]> wrote:
> On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> > Randy McMurchy wrote these words on 08/04/05 19:12 CST:
> >
> > > This is a stretch. To the best of my knowledge, all the CrackLib
> > > library does is check that the password a user enter
On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> steve crosby wrote these words on 08/04/05 19:56 CST:
>
> > Regardless, if the end user doesn't like/want the policy, all that's
> > required is to skip this package installation, much the same as people
> > can currently skip things like gett
On 8/5/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote:
> On 8/4/05, steve crosby <[EMAIL PROTECTED]> wrote:
> > On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> > > Randy McMurchy wrote these words on 08/04/05 19:12 CST:
> > >
> > > > This is a stretch. To the best of my knowledge, all the Cr
steve crosby wrote these words on 08/04/05 20:12 CST:
> Even using --with-libcrack, if no cracklib is found, configure and
> make merrily proceed without error and build the binaries - I'm not
> able to test the resulting binaries are workable for a few hours
> however ;)
This is good to know. I
Tushar Teredesai wrote these words on 08/04/05 20:09 CST:
> The problem is that BLFS assumes that you have built *all* package in
> LFS. So if you skip a package, you are a pariah when you post to
> BLFS-support :-)
>
> That is one reason I don't prefer packages being added to LFS, it
> takes awa
Nice discussion. 30 messages in just over 3 hours!
Now, this is what this list is all about!
--
Randy
rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3]
[GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686]
20:28:00 up 124 days, 20:01, 2 users, load average: 0.30, 0.38,
Jeremy Huntwork wrote these words on 08/04/05 20:03 CST:
> steve crosby wrote:
>
>>Regardless, if the end user doesn't like/want the policy, all that's
>>required is to skip this package installation, much the same as people
>>can currently skip things like gettext, module-init tools, etc.
>
> We
DJ Lucas wrote these words on 08/04/05 21:10 CST:
> As the bug report shows, add
> 'PATH DEFAULT=/usr/local/bin:/usr/bin:/bin:... OVERIDE=${PATH}' to
> /etc/security/pam_env.conf to create a valid user path. For a default
> root (superuser) path, create a valid /root/.bashrc that contains the
> o
DJ Lucas wrote:
> Randy McMurchy wrote:
>
>>ECI wrote these words on 08/04/05 10:04 CST:
>>
>>
>>
>>>I'm using a LFS 5.1.1 with cracklib + pam + shadow. I have recently upgraded
>>>PAM (0.80) and shadow (4.0.10) and cracklib according to the BLFS dev book
>>>and have a problem with su and PATH var
Jeremy Huntwork wrote:
Well, add it without question then. As long as the book mentions that
you can skip it if you want.
If that's the case it's not needed then.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/m
Jim Gifford wrote these words on 08/04/05 21:19 CST:
> Jeremy Huntwork wrote:
>
>>Well, add it without question then. As long as the book mentions that
>>you can skip it if you want.
>>
>
> If that's the case it's not needed then.
With all due respect Jim, your contributions have so far been
wo
Randy McMurchy wrote:
What are you saying is not needed?
Jeremy's suggestion that the package can be skipped, or the
installation of the package altogether?
If a package is going to be added with the note that's it's not needed
or can be skipped, it does not belong in LFS.
--
--
[EMAI
Jim Gifford wrote these words on 08/04/05 21:34 CST:
> If a package is going to be added with the note that's it's not needed
> or can be skipped, it does not belong in LFS.
Exactly. That is why I came back on Jeremy's message about this.
However, he has not replied, so I don't know what to thin
Randy McMurchy wrote:
You say this as if the LFS book as it is, is the way it should be,
and never be enhanced or changed to become better.
I did? Hmmm. I don't recall thinking that. But nice of you to explain to
me what I meant.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
Randy McMurchy wrote:
This can be applied to many of the LFS packages. It is a meaningless
suggestion, as this is not the way it is done in LFS.
Perhaps salting a baboon would be a good idea.
Now that's a meaningless suggestion. Mine however, was not.
There are already precedents in the LFS
Jeremy Huntwork wrote these words on 08/04/05 22:21 CST:
> There are already precedents in the LFS book where items are shown to be
> at least somewhat optional. Read section 7.1. Also, the entire idea
> behind LFS is to customize the system to fit your needs - to be able to
> be in full contro
Randy McMurchy wrote:
>
> What I believe this thread is about is adding this package to LFS,
> "Yes" or "No". There really is no middle ground.
>
I'm for it. As requested, a simple "YES". This is a good thing as we
get to mention login.defs and give a quick intro to what it provides.
The defa
Randy McMurchy wrote:
There is no middle ground. LFS recommends a build method. We don't
sit on the fence and say, "well, if you really don't want this
package, you don't need to install it". This would need to be
added into several of the LFS package instructions. Is this what
we should do?
I
On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Jeremy Huntwork wrote these words on 08/04/05 22:21 CST:
>
Here is some suggested text for the cracklib library package
The Cracklib library provides a mechanism to check passwords against a
dictionary, and identify if a particular passwor
Justin R. Knierim wrote:
Randy McMurchy wrote:
There is no middle ground. LFS recommends a build method. We don't
sit on the fence and say, "well, if you really don't want this
package, you don't need to install it". This would need to be
added into several of the LFS package instructions. Is t
On Thu, Aug 04, 2005 at 09:46:03PM -0500, Randy McMurchy wrote:
>
> What I believe folks should do is too simply agree with the proposal,
> or provide an argument against it. So far, there's only been
> positives, folks sitting on the fence not contributing a rebuttal
> notwithstanding.
Here is a
On Fri, Aug 05, 2005 at 01:14:44PM +1200, steve crosby wrote:
>
> Ah, but if you feel you have the skillset to decide if you can skip a
> package in LFS, you should also have the skillset to fix (or at least
> make intelligent comment about) issues related to skipping that
> package in BLFS ;)
Th
Justin R. Knierim wrote these words on 08/04/05 23:25 CST:
> I was not aware of LFS being so strict. There are cases where the user is
> given a choice, for example with regard to System-V or BSD style init (notes
> in psmisc about a symlink and 7.1 with a link to the BSD init hint). I don't
Archaic wrote these words on 08/04/05 23:32 CST:
> Here is an argument, then: it isn't needed for a base development system
> as proven by 6 years of its absence. There is no valid technical reason
> to include it or exclude it. It's merely a choice.
This can be said for many of the LFS packages.
On Thu, Aug 04, 2005 at 11:36:46PM -0500, Randy McMurchy wrote:
>
> You are entitled to your opinion, thanks for offering it. Though I
> cannot see why you think that by installing *one* simple library, and
> the accompanying dictionary, is something that we would not want to
> suggest in the defa
On Thu, Aug 04, 2005 at 11:39:06PM -0500, Randy McMurchy wrote:
>
> This can be said for many of the LFS packages. Please provide an
> opinion on whether it should be added to the default LFS build.
Link to BLFS only.
--
Archaic
Want control, education, and security from your operating system?
Chris Staub wrote these words on 08/04/05 19:30 CST:
> I agree. All that's needed is to add a link to that section of BLFS in
> the Shadow instructions. Besides, I thought tight security was what HLFS
> existed for - the base LFS is mostly just to teach people how to create
> a system that work
Archaic wrote these words on 08/04/05 23:42 CST:
> On Thu, Aug 04, 2005 at 11:39:06PM -0500, Randy McMurchy wrote:
>
>>This can be said for many of the LFS packages. Please provide an
>>opinion on whether it should be added to the default LFS build.
>
> Link to BLFS only.
There would be no link
On Thu, Aug 04, 2005 at 06:50:36PM -0500, Randy McMurchy wrote:
>
> It's the best we've got. One of two things has to happen to close the
> bug. Run the test suite the only way we can (which, by the way, is a
> very good indication that the package builds in the manner intended by
> the author), o
Randy McMurchy wrote:
Chris Staub wrote these words on 08/04/05 19:30 CST:
I agree. All that's needed is to add a link to that section of BLFS in
the Shadow instructions. Besides, I thought tight security was what HLFS
existed for - the base LFS is mostly just to teach people how to create
a
On Thu, Aug 04, 2005 at 11:46:46PM -0500, Randy McMurchy wrote:
>
> There would be no link that we could offer in LFS that could assist
> the user in configuring Shadow to work with CrackLib. BLFS does not
> have such a configuration.
If BLFS cannot create such a situation, then a hint would sure
Randy McMurchy wrote:
There really is no choices given in LFS Chapter 5 or 6, unless you want
to consider the text in the Vim instructions to be a choice. We suggest
a build method. It is up to the reader to follow, or not follow the
suggestions.
Ok, I can see what you mean.
You are entitl
Chris Staub wrote these words on 08/04/05 19:50 CST:
> Then perhaps the BLFS instructions should be modified.
No, the BLFS instruction do exactly as they are intended. To
provide instructions to recompile Shadow if Linux-PAM is installed.
My suggestion is to add CrackLib to LFS so that Shadow it
Archaic wrote these words on 08/04/05 23:52 CST:
> On Thu, Aug 04, 2005 at 11:46:46PM -0500, Randy McMurchy wrote:
>
>>There would be no link that we could offer in LFS that could assist
>>the user in configuring Shadow to work with CrackLib. BLFS does not
>>have such a configuration.
>
> If BLFS
Justin R. Knierim wrote these words on 08/04/05 23:59 CST:
> Glad to offer my opinion. Secure passwords are important, agreed.
> However the users of the LFS system are varying. A user who built LFS
> for the educational value or who wants a different password library or
> who uses it on a s
Randy McMurchy wrote:
Chris Staub wrote these words on 08/04/05 19:50 CST:
Then perhaps the BLFS instructions should be modified.
No, the BLFS instruction do exactly as they are intended. To
provide instructions to recompile Shadow if Linux-PAM is installed.
My suggestion is to add CrackLi
Randy what educational value does cracklib add if it's used with Shadow
in LFS?
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the a
Jim Gifford wrote these words on 08/05/05 00:07 CST:
> Randy what educational value does cracklib add if it's used with Shadow
> in LFS?
Glad you asked Jim.
Installing the CrackLib library and having Shadow link against it
shows folks how to set up and use a word dictionary to guard against
weak
On Fri, Aug 05, 2005 at 12:01:16AM -0500, Randy McMurchy wrote:
>
> I respect your opinion that it isn't needed, however, it would be
> much easier to understand if you gave just *one* reason why you
> think it wouldn't be a good thing.
I have already stated it. There is no *technical* reason for
Chris Staub wrote these words on 08/05/05 00:05 CST:
> That's what I mean - modify (or add to) the BLFS instructions so that it
> explains how to use cracklib with shadow but without PAM.
So what Chris, we should modify the Shadow instructions to include
some instructions on how to compile if Li
On 8/4/05, Greg Schafer <[EMAIL PROTECTED]> wrote:
>
> IMHO it looks like a problem in Glibc ie: ldconfig, albeit a minor one.
> These 2 threads are relevant (I think):
>
> http://sources.redhat.com/ml/libc-alpha/2003-07/msg00098.html
> http://sources.redhat.com/ml/libc-alpha/2003-08/msg00120
Randy McMurchy wrote:
But can't the same thing be said for many of the LFS packages. :-)
Heh, you are correct sir. :)
It is hard to give good arguments for this question. I cannot argue
that it isn't a useful library, and I use cracklib on every LFS system I
build, but I install pam as we
On Fri, Aug 05, 2005 at 12:18:09AM -0500, Randy McMurchy wrote:
>
> So what Chris, we should modify the Shadow instructions to include
> some instructions on how to compile if Linux-PAM is not installed?
Why not? BLFS is the home of optionally do this or optionally do that.
> What is the point i
Archaic wrote these words on 08/05/05 00:18 CST:
> I have already stated it. There is no *technical* reason for including
> it in a base development system.
That is not a reason to not include it. The technical reason I state
is that it provides a mechanism to enforce strong passwords on the
syst
Randy McMurchy wrote:
Archaic wrote these words on 08/05/05 00:18 CST:
BTW, out of the 70-odd boxes I manage, I would use (and do use) cracklib
on exactly one of them. That box also uses PAM, so even it would be
moot.
I'm sorry. What keeps users from setting their passwords to "password"?
BT
Justin R. Knierim wrote these words on 08/05/05 00:23 CST:
> It is hard to give good arguments for this question. I cannot argue
> that it isn't a useful library, and I use cracklib on every LFS system I
> build,
Yet you give a -1 for the simple addition of a single little old
library (and its
Randy McMurchy wrote:
Archaic wrote these words on 08/05/05 00:18 CST:
I have already stated it. There is no *technical* reason for including
it in a base development system.
That is not a reason to not include it.
/me blinks. about:kitchensink!
I'm sorry. What keeps users from setting
Chris Staub wrote these words on 08/05/05 00:28 CST:
> Why keep them from setting their passwords to "password" if that's what
> they want to do?
They still can. :-)
However, should LFS install the mechanism to provide such an absolutely
poor security model?
I don't think so. And I can't imagi
On Fri, Aug 05, 2005 at 12:24:54AM -0500, Randy McMurchy wrote:
>
> That is not a reason to not include it. The technical reason I state
> is that it provides a mechanism to enforce strong passwords on the
> system. This is the *technical* reason I'm standing for.
No, you are standing for a featu
Randy McMurchy wrote:
Yet you give a -1 for the simple addition of a single little old
library (and its dictionary) to LFS. Please provide something concrete,
else I'll think you are just disagreeing for the fun of it. :-)
Randy, that's hardly fair. Several times in this thread people *have*
Randy McMurchy wrote:
Yet you give a -1 for the simple addition of a single little old
library (and its dictionary) to LFS. Please provide something concrete,
else I'll think you are just disagreeing for the fun of it. :-)
I was giving my honest opinion. Just because I use cracklib in all my
Randy McMurchy wrote:
Chris Staub wrote these words on 08/05/05 00:28 CST:
Why keep them from setting their passwords to "password" if that's what
they want to do?
They still can. :-)
However, should LFS install the mechanism to provide such an absolutely
poor security model?
I don't thin
Randy McMurchy wrote:
I don't think so. And I can't imagine anyone else thinking so also,
unless they simply just want to disagree with the suggestion.
And therein lies the problem. Either unable or unwilling to allow for
different thinking.
--
JH
--
http://linuxfromscratch.org/mailman/listi
Matthew Burgess wrote:
> Randy McMurchy wrote:
>
>> However, LFS history has shown that we cannot count on such a document
>> to become formalized.
>
>
> I'm not sure if a formal set of rules is in fact possible. If we
> consider the packages that are in the book at the moment, they can be
> br
Jeremy Huntwork wrote these words on 08/05/05 00:39 CST:
> Randy, that's hardly fair. Several times in this thread people *have*
> offered you reasons and you come back and say they aren't valid,
That is simply not true. Please, Jeremy, provide just one time someone
offered a reason, other than
Tushar Teredesai wrote:
> The problem is that BLFS assumes that you have built *all* package in
> LFS. So if you skip a package, you are a pariah when you post to
> BLFS-support :-)
>
> That is one reason I don't prefer packages being added to LFS, it
> takes away the options.
>
I don't follow
Chris Staub wrote these words on 08/05/05 00:40 CST:
> That's right, I don't have a technical reason against it. I just have a
> problem in general with forcing someone to do something (like pick a
> "strong") password "for their own good". Same reason why I don't think
> seatbelt laws should e
Randy McMurchy wrote:
Chris Staub wrote these words on 08/05/05 00:40 CST:
That's right, I don't have a technical reason against it. I just have a
problem in general with forcing someone to do something (like pick a
"strong") password "for their own good". Same reason why I don't think
seatb
Randy McMurchy wrote:
Jeremy Huntwork wrote these words on 08/05/05 00:39 CST:
The choice is still up to the reader to install the package or not.
That's not a valid reasoning, particulary since it was you who said
earlier that no package in LFS should carry a "this is optional"
disclaimer
On Fri, Aug 05, 2005 at 12:59:37AM -0500, Randy McMurchy wrote:
>
> Why shouldn't LFS do something that has such a sound technical
> reason, with really nothing that can be said against it, other than
> "I don't want to".
This is going around in circles. Your opinions have been clearly noted.
At
On Fri, Aug 05, 2005 at 07:04:32AM +0100, Richard A Downing wrote:
>
> I don't follow this. Isn't blfs-support the place for all beyond LFS
> support questions. It's not limited to BLFS packages, so why should
> there be a 'complete' lfs assumption.
Because the book assumes it and always has. S
On Fri, Aug 05, 2005 at 01:09:05AM -0500, Randy McMurchy wrote:
>
> However, you wear your seatbelt, I'm sure. Regardless of the law.
> Because it is the *smart* thing to do.
Perhaps statistically it is, but try telling that to the countless
people who would have perished if they were wearing a s
Chris Staub wrote these words on 08/05/05 01:19 CST:
> Randy McMurchy wrote:
>>The choice is still up to the reader to install the package or not.
>
> That's not a valid reasoning, particulary since it was you who said
> earlier that no package in LFS should carry a "this is optional"
> disclaim
Archaic wrote these words on 08/05/05 01:27 CST:
> On Fri, Aug 05, 2005 at 01:09:05AM -0500, Randy McMurchy wrote:
>
>>However, you wear your seatbelt, I'm sure. Regardless of the law.
>>Because it is the *smart* thing to do.
>
> Perhaps statistically it is, but try telling that to the countless
1 - 100 of 106 matches
Mail list logo
