Bill's LFS Login
lfsbill at nospam.dot
Sun May 23 10:54:42 PDT 2004
On Sat, 22 May 2004, DJ Lucas wrote:
> Matthew Burgess wrote:
> Now one for you. What known LFS goals and policies are we to reference?
> I chose http://www.linuxfromscratch.org/lfs/view/cvs/prologue/audience.html
*Without* meaning to side-track, ISTM that the organization docs
"Policies" should contain this. If not, then org docs should be scrapped
- it's not proved useful;
- several major teams did not do mission statements;
- lack of "Policies" gives rise to the need for ad-hoc docs such as
- it also constantly causes discussions such as this one.
> Now lets take a look.
> Education = Depends..will the user learn more on his own by first using
> static devices, or by learnig dynamic devices as taught in the book.
It's possible there would be no difference. It depends on what text and
refs are included. Just because something happens "magically" doesn't
mean it is "uneducational". That determination depends solely on if we
choose to impart knowledge that is not inherent in the use of the
component itself. E.g. a brief discussion of what major and minor
numbers represent, how they are manipulated to find drivers, etc.,
applies to all the various ways that devices are created. Udev/hotplug
inclusion just demands a few more lines of text that describes the
functionality added to the equation.
> Compact/Minimalist = HELL NO! Another package.
Irrelevant if it replaces one.
> Optimized = No. Another proggy running in the backround when a static
> device would suffice.
If optimized includes better utilization of i-nodes and disk space,
"Yes". Remember that CPU/RAM usage is not the only criteria for
"optimized". It is always a balance of tradeoffs. With CPU/RAM/HD being
what they are today, I think the application of the platform will be
the primary factor.
> And a couple of more questions....
> So, now the question is wether education outweighs the other two goals
> as I believe it does. If so, then does dynamic devices take away from
> education in comparison to creating the soon outdate static devices?
As I say above, that is our choice.
> While I would really like to see dynamic devices supported, the answer
> clearly seems the opposite to me. I certainly hope this finally lays
> the argument to rest.
Having read *all* the posts to-date, it does. But probably not in the
way you thought IMO. See below.
> -- DJ Lucas
First, I discount Jeroen's package selection criteria. Why? Only for two
reasons. It is not a part of the organization docs and has not been
proposed as such, discussed, amended and incorporated. I believe in the
org docs because many individuals took the time to work on them as an
attempted solution to problems. One of those problems that would be
solved would be the one under discussion. Jeroen's proposal is good,
useful and needed. It should be a part of the organization docs
Second, without the completion of the "Policies" section in the org
docs, how can we know if Jeroen's proposals conflict with the org goals,
policies, ...? So, that leaves us pulling snippets from parts of the
book, old posts, people's (mis)understanding of goals, etc. to justify
the selection criteria.
That leaves me free to apply an arbitrary set of selection criteria that
I devise. The fact that mine happen to incorporate most of Jeroen's
proposed criteria is irrelevant.
Here's my take on udev inclusion.
1. Udev violates none of the 7 principles listed here
As make-devices is justified by 1,2 in that document, so is udev.
Therefore, there is nothing in that document that precludes udev
(including that subsequent comments, AFAICT).
2. Arguments against udev then fall back on other things like
"long-standing policies", phrases from the book, etc. Presuming
those are valid justifications (which really should not be
presumed, they should be in written "Policies" in the org docs), we
can examine them.
3. "Stable packages": we have used the traditional meaning for this. LFS
has grown. We have more expertise, official/wider testing, advanced
technical investigation/experimentation and a larger group of folks
that consistently monitor (and *may* *commit* to do so if they ever
write their mission statements) lists. I think it would be reasonable
for the dev/testing teams to formally designate the "stability" of
a package vis-a-vis LFS inclusion. We have advanced, to some degree,
beyond having to rely on other distros actions and developer
"blessing" exclusively as the standards we use, although monitoring
of their lists and results would still be a primary input for the
LFS teams to consider.
If this is considered valid, then an assertion by the dev and test
folks that the package is stable for LFS use should be sufficient.
If they take that duty seriously, and suppress their natural desire
to always have the "latest and greatest", we should have good
4. "Educational": no component, or our install activities for that
component, should be *viewed* as inherently educational or not. It
*always* requires us to ask "do we need some discussion of ...".
Where justified, we add it. So udev should not be discounted/accepted
either way using this criteria of "educational".
5. "Not required": consider all the arguments about this from other
posts as re-hashed here. My POV, as stated many times, is that LFS is
more than a minimal required platform for continuing effort. It
should also provide a *little* extra in the way of a "comfortable"
environment for what may be attempted in following activities. If
this is a valid consideration, and if we acknowledge the existence of
the need for udev/hotplug on an ever-increasing number of our user
platforms, then we should, at a minimum, strongly consider _at_least_
offering this as a choice. Further, if it is decided that not a
choice, but a requirement is appropriate, an alternative like
make_devices can be referenced for those who deem udev/hotplug
inappropriate for their scenario. Either way, appropriate educational
text or references should be provided.
Also, as mentioned, udev/hotplug will be required as much as
MAKEDEV/make_devices is currently. We need not provide either of
those two (mknod educational text and commands could be used instead)
but we do. So we can/should consider udev/hotplug in
6. Not ready for prime time: as mentioned elsewhere, we now have the
technical resources available in the dev/test area to make that
determination independently of other distro's judgments and with
full consideration and weight given to the udev/kernel developers'
opinions. All that is required is that we have: confidence in the
judgment of our dev/test teams; that we trust them to put aside their
lust for blood and that they will consider mission-critical
applications as part of their target audience and make qualifying
statements appropriate for those situations.
If we have those confidences, we are then in a position to assure
ourselves that "official release", "not needed yet", "not stable
enough" (as deduced from outside sources like other distros) are no
longer the *primary* factors in LFS's selection of a package for inclusion.
7. Either the organization effort started last year has paid dividends
that make the above considerations valid or it has not. If it has,
then we should proceed on that basis. If not, then ...
In summary, ISTM that the true question is *not* udev or not, but what
policy shall we adopt in making such determinations. Jeroen's proposal
was a start, but begs the question of the level of confidence we
can/should place in the resources now available to the LFS project.
NOTE: I'm on a new ISP, if I'm in your address book ...
Fix line above & use it to mail me direct.
More information about the lfs-dev