Home Brewed Distros

[jjmac]

People may well just observe it creating it self:

I think the organisation should be left to create itself really. I think it should be a bit like a circle, where a person can just enter at any conveniant part and do things acording to there interest and ability.. Even the gentoo thing needn't be so firm. My only idea there is that the first stage could be compiled over the top of, in that it would be convieniant, like a kind of pilot light. It's cheating really though , but at least it should allow for a console boot and then so serve as a functional base. But, by being compiled over on top, it provides a way of testing its' structure, and changing it. Such as removing things untill it breaks. Experimenting with the init process, would a dual init be to impractical. It would allow apps which are sensitive in that regard, ie; somewhat distro specific, to be installable. Wheather it actually turned into some sought of distro creation ... well, that would be amazing, but trying to start with that in mind may well be a disadvantage. There is so much that could be done just on that initial level. Like ... would it be possible to merge more than one packaging system together. Meta packages would allow rpms to be known by a dpkg based setup, but how to compliment that in the reverse. Possibly Slacks pkg system would be better. I don't think its really important to have a strict structure, at least not initially. Maybe it could tern into a strange beast that allowed any package from any distro to be installed (grin).

Once the wiki is back, that should at least provide a facility where an actual start could be made. It would just mean a base package was there that people could work on in different ways, then post it back under a different directory. Probably with a date as part of the directory name and a text file insde disclosing the culpret , primitive cvs maybe ... but, it should be fun, not a chore. If it's fun and informal, people will gradually be attracted. Especially as it starts to take on a momentum. hmmmm, obvious problem ... upload/dload og .tar.gz files. Have to see what the powers think of that i guess. About the only real block i can see so far.


jm

[Erin]

JM, agree but we still need a central committee of sorts. Free to enter and leave, by all means but if there is no-one to drive it, the risks of it petering out are far higher.

I think we have to remember, the point is not to produce a distro but to learn and as JM says, have fun. If anyone has done any OO stuff, the planning takes forever, the reviewing forever plus a day, the output, minimal time.

Looking forward to LFXC's initial meet. Maybe we need to do an IRC conference at some point soon.

Erin

[Gordon]

Could we have some pointers on using IRC first or pointers to other resources. I've tried to understand it to get to the Linux From Scratch IRC channels but I've no idea where to start.

BTW this LXFC distro is a bloody good idea. This weekend I plan to try LFS again! Of course this would be targeted at my hardware AMD Athlon 64, but if I can find out how I would like to re-do LFS but compile everything aimed at an i586 arch so others could use it.

If I'm successful would this be a good base for LXFC?

What do others think?

Gordon

[Nigel]

Looking forward to LFXC's initial meet. Maybe we need to do an IRC conference at some point soon.

I've not taken part in one of those before, so some hints would be useful...

[jjmac]

ugh, looks like i'm going to have to figure out irc now (grin). My only real worry presently is ... Will we be able to upload tarballs to the wiki when it's up . That will have to be restricted to registered users for obvious reasons. But i'm not even sure if that would be policy. Is the owner of LXF/Future going to hit the roof when he/she hears of this(grin). Hope not (grin). Seems like it might be already on its' way though.

Assuming all goes well, i'm sure it will go through waves. It will seem to die out, but then it will pick up again ... being subject to strange celestial forces as are all things . Lets not let a to strict structure get in the way though, but i guess your right really Erin, some form of guide line may be needed. But something flexible.

Maybe plan outlines on what different people think an installer actually does, or on what actually constatutes a base system , as wiki page posts, would be a good starting point. I'm sure that at least would be facininating in it self, if not somewhat embarrassing as well .

Gordon wrote:
>>
BTW this LXFC distro is a bloody good idea. This weekend I plan to try LFS again! Of course this would be targeted at my hardware AMD Athlon 64, but if I can find out how I would like to re-do LFS but compile everything aimed at an i586 arch so others could use it.
>>

Sound like a good contribution to me . And the whole point to the exercise.


jm

[Gordon]

Sooner than I thought I've now got a base Linux From Scratch system working. So I now have a sextuple boot system, SUSE 9.3, Ubuntu, Slackware 10.1, Fedora Core 4, Mandrive LE 2005 and Linux From Scratch

I now need to know how to do it again but to target the build at an i586 arch. It's probably something simple like setting CFLAGS or CPPFLAGS or something. More research is needed here.

After that I will need to do a bit of tidying up with some of the basic things from Beyond Linux From Scratch.

BTW thanks to those who've helped with my IRC bit

[towy71]

Erin has setup a channel #lxfc on irc.oftc.net and we are squatting there for now.

We should try to arrange an apropriate time for a meeting on that channel at some point.

hope to see you there

Dick

[Gordon]

I now know how to compile code for a specific architecture, thanks to LXF But how can I make sure the resultant libs and progs are for the architecture I specified. I've looked at the man pages for readelf and ojdump but I can't seem to find what I want.

Can anyone help out here?

Gordon

[jjmac]

gordon wrote:
>>
I now need to know how to do it again but to target the build at an i586 arch. It's probably something simple like setting CFLAGS or CPPFLAGS or something.
>>

CFLAGS='-mcpu=i586 -march=i586 ...'

For a P5 thats basically it. It is specific though and wont be suitable for anything less than a i586. The cpu swith governes "scheduling" issues and isn't so crucial but the arch switch will govern the type of assembler code gcc generates and so is.

>>
But how can I make sure the resultant libs and progs are for the architecture I specified.
>>

Good question , You could try compiling something for say ... an i686, and then try running it on a i586. Just checking a few things with hexedit dosen't reveal much there. Just the initial ".ELF" tag, then further in, GLIBC compatability tags ?


jm

[Android_808]

I've read all the way through this thread today and it does seem like quite a good idea. I would we willing to contribute to the project depending on time where possible. I've built several LFS systems, and countless Gentoo installations so I don't have a problem waiting for things to compile, its just my personal circumstances are liable to change shortly. Once the community has drawn up a list of features and requirements I shall look at how I can help further.

On the subject of leadership, I agree that there should be an overall project leader but I feel there should also be a committee/board to discuss major changes and implementation stratergies.

The installer could be something of an after thought. Why waste time worrying too much about an installer which doesn't yet have anything to install? You could always tar the filesystem image and make it available. Having used CoLinux, and looking at their disk images, a Gentoo stage 3 disk image is (last time I checked) about 80MB. Installation would then just be following some of the basic principle of Gentoo and Debian, where by the user needs to set up the partition information and format the disk using the standard tools like fdisk and mkreiserfs. Once testing of the initial release/few releases has been completed I would then worry about the installer.

As LXF can not guarantee the continuation of the project, why not wait until the community has created an release. We could contribute information about the building of the distro, documenting the procedures and pitfalls we encounter, giving them material that they can then work from. Whilst looking for some more information on this topic I found http://alindis.sourceforge.net/index.html which, although not updated for some time, appears to be what we are trying to achieve, a distro with documentation on how to achieve building it.

For those looking for something more than the base system talked about, it could also be possible for members of the community and users of the distro to extend the functionality, for example to include support for X and desktop environments. Therefore I don't think that we need to consider this yet, all I would worry about was building a system that complies with the Linux Standards Base.

I'm looking into building a LFS system at the moment, but want to include package management from the beginning so that all packages installed are handled by rpm/apt etc. There is a hint on the LFS site to add RPM, but it is for adding RPMs to the already made system. I've had a few ideas as to how to achieve this but could anyone give me a point in the right direction. As Debian has been mention, how to go about making .deb's and software required for package manager would be great.

If I successfully manage to achieve this I will post my method up. If I do I may then try to cure one of my major frustrations with Linux, GUI appearance. I know theres QT themes for GTK and vice versa like Bluecurve but they never quite manage to do a perfect job. What about implementing the same thing in WINE? IE looking like a KDE app? Why? To make it blend in; to make it look less of an after thought.

Sorry about the length, but I hope I've given you something to think about.

[jjmac]

>>
The installer could be something of an after thought. Why waste time worrying too much about an installer which doesn't yet have anything to install?
>>

Mainly because for people that don't have a lot of familiarity with building systems etc ... there very reliant on the installer to carry them through. Thats were it either makes or breaks. Even if there is nothing to install as such, it dosen't really need to to be developed. I'm think on something that hooks into external files to do the actual work

jm