Jeremy Huntwork wrote:
Give them the basics, show them how to extend, warn about possible
pitfalls and provide an example. Doing this we're not leaving them with
a half-baked system, as some have said already - we're teaching them how
to complete the system themselves which is what LFS has alw
Joshua Murphy wrote:
Finally, from personal experience, I can say that most people who come
to LFS don't do it to have a small, clean, fast, and stable system
(which is part of what they get), but instead go through the book,
doing the build, to understand how and why it works, something you can
On 4/21/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
> In CLFS, we create all the users and groups, this will solve all issues
> if LFS will follow. It will also simplify the BLFS instructions to
> adding users to the appropriate groups. It's a plus for all, eliminates
> so of tedious work the BLFS h
Jim Gifford wrote:
In CLFS, we create all the users and groups, this will solve all issues
if LFS will follow. It will also simplify the BLFS instructions to
adding users to the appropriate groups. It's a plus for all, eliminates
so of tedious work the BLFS has to do managing users/groups and g
Bruce Dubbs wrote:
Also, you may want to rephrase your comments to not use words that some
may find offensive. Name calling is never appropriate.
What are you talking about? You lost me on that comment.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch
Jim Gifford wrote:
We should be providing all the users and groups and let the people
choose what they want to remove. Instead of just giving them the bare
minimum. We need to provide a fully functional system, not a half-baked
one.
Exactly. We had a same point. :).
William Zhou
--
http:
Jim Gifford wrote:
> We should be providing all the users and groups and let the people
> choose what they want to remove. Instead of just giving them the bare
> minimum. We need to provide a fully functional system, not a half-baked
> one.
We do provide a fully functional system. A user just ha
Archaic wrote:
On Fri, Apr 21, 2006 at 01:28:10PM -0700, Jim Gifford wrote:
There is suppose to be a master list of users/groups, I've never
seen it myself. If that was published, we could take care of it in LFS.
There basically is. Take what is in LFS and add what is in BLFS. Any
g
Bruce Dubbs wrote:
Everybody has their own way of doing things. I prefer to only have the
users/groups in my files that are necessary for the packages I install.
That way if a number comes up on a ls -l, it flags the problem right away.
You may want to do things differently. That's OK. Howeve
Archaic wrote:
On Fri, Apr 21, 2006 at 08:55:25PM +0100, William Zhou wrote:
I prefer the CLFS way and I don't have to worry about the user/group
management any more.
Which is precisely why I don't like it. You should have to worry about
it if the goal is education. Then you can devise any nu
Jim Gifford wrote:
> In CLFS, we create all the users and groups, this will solve all issues
> if LFS will follow. It will also simplify the BLFS instructions to
> adding users to the appropriate groups. It's a plus for all, eliminates
> so of tedious work the BLFS has to do managing users/groups a
On Fri, Apr 21, 2006 at 01:28:10PM -0700, Jim Gifford wrote:
>There is suppose to be a master list of users/groups, I've never
> seen it myself. If that was published, we could take care of it in LFS.
There basically is. Take what is in LFS and add what is in BLFS. Any
gaps in gid numbering a
On Fri, Apr 21, 2006 at 08:55:25PM +0100, William Zhou wrote:
>
> I prefer the CLFS way and I don't have to worry about the user/group
> management any more.
Which is precisely why I don't like it. You should have to worry about
it if the goal is education. Then you can devise any number of metho
On Fri, Apr 21, 2006 at 10:50:07AM -0700, Jim Gifford wrote:
> In CLFS, we create all the users and groups, this will solve all issues
Actually, it won't solve all issues. Remember, my focus is on the equal
weight of technical correctness and education. Adding all possible
groups and rules in one
Exactly, and the LFS book would point to this list as to keep it current.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 4/21/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
> Dan,
> There is suppose to be a master list of users/groups, I've never
> seen it myself. If that was published, we could take care of it in LFS.
That's what I mean, though. There can't be a master list in LFS
because many of the users and
Dan,
There is suppose to be a master list of users/groups, I've never
seen it myself. If that was published, we could take care of it in LFS.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 4/21/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
> In CLFS, we create all the users and groups, this will solve all issues
> if LFS will follow. It will also simplify the BLFS instructions to
> adding users to the appropriate groups. It's a plus for all, eliminates
> so of tedious work the BLFS h
Jim Gifford wrote:
In CLFS, we create all the users and groups, this will solve all issues
if LFS will follow. It will also simplify the BLFS instructions to
adding users to the appropriate groups. It's a plus for all, eliminates
so of tedious work the BLFS has to do managing users/groups an
In CLFS, we create all the users and groups, this will solve all issues
if LFS will follow. It will also simplify the BLFS instructions to
adding users to the appropriate groups. It's a plus for all, eliminates
so of tedious work the BLFS has to do managing users/groups and gives
everyone a ful
Archaic wrote:
The other example, audio devices, would basically be the same. The
devices would be created with their default permissions and group owned
by root, but would be created with the proper names and in the proper
directories. BLFS would then have the perfect forum to layout what needs
* Archaic <[EMAIL PROTECTED]> [2006-04-20 19:02]:
> Now for the philosophical debate of which book should do what with udev
> rules. The 2 forerunners in the debate are:
>
> - The existence of devices comes mainly from the kernel, so everything
> should be in LFS.
>
> - Many devices are unusabl
First, thanks to Alexander for helping me through the jungle that is
udev. It would have taken me a long time to get as good a grasp on the
abstract concepts by reading the doco and examples.
Now for the philosophical debate of which book should do what with udev
rules. The 2 forerunners in the de
23 matches
Mail list logo
