Everyone is leaving?
zeps at ihug.com.au
Tue Jul 13 04:51:43 PDT 2004
kyle borreson wrote:
> How about we get an opinion from someone who realy doesn't have any stake in what is included into the book.
> please, no-one take any personal here, these are just my observations and opinions (which we are all alowed to have, even if we don't always agree about them)
> I've been playing with LFS for several years now. I have always loved how "I" have the final say in what is built on my system as opposed to what the distro tells me is required. In fact, even now I am not following the book exactly, no LFS user I have ever met does. It's just supposed to be a launch point for us to learn and understand what the bare minimums are for a user-box.
> One thing that always disapointed me about the old 2-tier system was how slowly it seemed to update. say version glibc-2.2.5 was released, but the book was still back on 2.2.1 (been a while folks, versions are probably a little off)
> I think that this new 3-tier is probably one of the best things to help speed up the lfs development because you guys, the developers now have a free branch to mess up with... I almost always used the cvs branch, simply because it used the newer ("flashier?") versions of the packages
> This is what I understand the 3-tiers to mean, as the "average" builder... if that term can be applied to any of us?
> Stable is the branch that has survived all of us... and is known to be, if not rock solid, then at least production-grade reliability.
> Testing is for those of us who want something a little newer maybe, for those of us who don't need quite the same level of reliability. but it is still a branch that we can Expect to compile clean and work. Here is where we find the more subtle errors/incompatibilities...
Sure testing is great, new packages and such, Thats why the cvs head
became a developers play ground.
> The Unstable Branch (my personal favorite), much like the old maps (Off the edge of the map - here there be monsters)
> unstable is the playground where the developers get to experiment, try different solutions, techniques, etc.. simply because this is the branch that can not be expeted to build out of the box 100%... It's unstable.
you mean the testing branch? with release candidates etc? yeah sure,
great for testing before a final stable book is made.
> I agree that the developers need to keep each other informed on what they are working on,not always their exact solution, although it would be nice from my perspective to see how they've tried to solve something and not always had it work.
> We sometimes learn more by what doesn't work than what does.
This is a problem for a few, Say for instance one developer calls
another on the phone, or chats about adding a new bleeding edge thing to
the cvs, Then its commited. Some are claiming that it should be put up
here to satisfy the ignorance of the few, Who are unable to do the
neccacry research or testing, and gain understanding. Infact a few of
the complains on issues have been documented with the -m command on svn,
and yet people still complain.
Bottom line, If you dont understand, Why not aproach the person who did
the commit? Or do some reading. Especilly on a Head commit. 99.9% of the
time, people who understand are avalible.
> I'm personally saddened to see the amount of people leaving LFS development (I would like to get involved in development a little more, I just don't have near the knowledge yet, but I can post the few things that I can find...)
Fantastic that you contribute were you can.
People leaving is really not that suprising to me, Ive been around quite
some time, And people come and go. Some of them leave with a bang,
others go quietly. Recently what saddens me, Is how the search for
knoledge has been lost, And spoon feeding has become a requirement. But
thats my own person beaf =)
Recently ive noticed a trend were those developers leaving, Have moved
onto book forks and system building forks. They are producing some
fantastic work still.
This is basicly what it took for the community to accept purelfs and
be-lfs into main stream, Kinda a shame a fork is required to get major
changes into LFS. But whatever needs to happen, happens.
> LFS has always been to me the guide book... If you follow the book you get a working system. If I want to leave the path, that's my risk, but I always have the book to fall back on if I make to big a mess. I don't understand everything behing the udev/hotplug difficulties yet, but from what I read on the lists, I think that hotplug might not be ready for prime-time yet, so it stays in cvs... so it can be worked on.
Udev and Hotplug are replacements for several ways of doing things.
They are infact documented in quite a few places, if you take the time
to read and ask questions.
In the most simpile form, Hotplug is a module loader, That kind of
autodetects modules based on kernel information, It can be called by the
kernel on a state change.
And udev is a device file maker also called from the kernel.
Example, you plug in a usb printer, Kernel calls hotplug, It loads the
module for the usb printer, and the kernel autoloader loads the dependancys.
Because The module has associations with a node id, It sends a call to
udev to make the relivent devices.
Both of these have seprate configureations, For example, hotplug has
sorted scripts, sorted out by device type, in /etc/hotplug/ They are
used in the proccess of working out which modules to load for the device.
Udev has settings in /etc/udev One directory for the permissions of the
devices, with the lowest number on the files having preferance. And the
other with a rules directory, stating the rules for naming and creating
devices, Also ordered with the lowest number file first taking preferance.
It also has a config file, defineing the device directory, the database
file, ownership, default permissions and log options.
The basic line of events on a hotpluged device is.
1. Plugin Device.
2. Kernel Calls Hotplug with devices information.
3. Hotplug modprobes device.
4. Kernel Notices the alias's and Details for the device.
5. Kernel calls udev to make the device's.
6. User uses the device.
Yes that means extra steps, It also means there is a chance if you try
to use the device straight after pluging it in, The device might not be
avalible straight away.
In effect that causes a race condition at times, For example, If you
attempted to load X, before the mouse module's devices are made.
Currently LFS combats this in a few ways.
And has a script for static module loading, And places the
hotplug(startup) script early in sysinit.
If you read the lfs-hackers mailing list, There is a lot of chat about it.
> Sorry about the length on this, I'm probably just rambling now, (see todays earlier posts) but I just wanted to get my two bits in on this. I would much rather see a larger group of developers who don't always agree, but are willing to work things out, than I would fewer developers who all work the exact same way...
> At least I would know that other solutions have been tried, and even if we don't have the best solution, we would at least have the best we found to date... But unfortunantly this means tha the developers have to be willing to see something they've worked on be discarded in favor of someone elses solution and realize that it is not anything against them personally, but that perhaps an easier to understand solution has been found? I know it can be hard to spend a few hours on a project, solve the problem, only to find that a slightly more appropriate solution has been found by someone else... The devlopers should be more concerned with finding solutions than with how much of the book is "theirs."
> Maybe I'm wrong, I don't know, as I said these are just MY opinions. And, as an outsider looking in, it's just what I'm seeing. It just seems to me that we have a few developers who are too interested in seeing their work be used, to the possible detriment of the project itself...
Sorry for rambleing as well, but im drinking.....Actually im not sorry lol
More information about the lfs-dev