[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ltib] ltib or not ltib?
From: |
Stuart Hughes |
Subject: |
Re: [Ltib] ltib or not ltib? |
Date: |
Thu, 31 May 2007 16:48:56 +0100 |
Hi Andrea,
Please see inline (trimmed back):
On Thu, 2007-05-31 at 15:41 +0100, address@hidden wrote:
>
> > LTIB is really intended to complement "real" distros like
> > Debian/Fedora etc, never to be an alternative.
>
> Could you please elaborate a little bit more on this
> concept? What do you exactly mean for "complement"? Do you
> mean that source packages being built with ltib are supposed
> to come from "real" distro source pools?
>
What I mean is that LTIB covers something that the "real" distros don't,
that is the ability to scale back to < 1MB rootfs.
> > After that point I figure that you may as well
> > use a proper distribution.
>
> This approach is fearing me a little bit. Modern "robust"
> distros appear to be more PC oriented and would require some
> heavy customization to be squeezed on a small storage
> device. Some small-size distros are available but sometime
> they do still require customization and the process to do so
> is not well under control as with ltib's approach. More than
> this they are sometime poorly supported and not really
> up-to-date as mainline distros.
I think the idea would be to look for a small desktop distro (tinylinux?
etc) that fits your need.
>
> > It is possible to add higher order packages. Recently
> > I've been working on the gstreamer set which has resulted
> > in LTIB being able now to work with pkg-config and the
> > like to handle the more complex inter package interface
> > issue.
>
> That sounds interesting... I don't know very much about
> gstreamer. Is gstreamer requiring any graphic toolkit behind
> it? If so I argue you may have been playing with something
> not that far from what I need in terms of complexity. What
> was your system's architecture?
Gstreamer itself is not graphic, but it does have a lot of
direct/indirect package dependencies which are representative of more
desktop like packages. The work itself was not architecture specific.
Regards, Stuart