Clarification please

Basically, I've been wondering why the OS seems to be based
on a top 
down approach (starting with Fedora Core 5 and stripping out
a rough 
guesstimate of whats not required) rather than a bottom up
approach 
(starting with nothing and using what parts of FC5 are
required to 
create a small, tailored OS).

 From what I recall, RedHat already has the tools to make
this possible. 
Embedded Developers Kit. I know the project isn't being
pushed by RedHat 
at the moment, but at the time it was, I was working for a
company 
called Antefacto. We were given a demo of the product. From
what I 
recall it gave a tk based UI into either the .spec files
and/or the 
files that rpm felt it needed to include in the binary rpm.
The UI 
allowed you to tailor what files where eventually installed.

http://www.redhat.com/d
ocs/manuals/edk/EDK-1.0-Manual/getting-started-guide/index_g
s.html

Using this approach would have allowed for a resulting
system that had 
rpm intact for use as the package manager and a more tightly
tailored OS.

Kind regards,

-- 
Glen Gray <glenlincor.com>              Digital Depot,
Thomas Street
Senior Software Engineer                            Dublin
8, Ireland
Lincor Solutions Ltd.                          Ph: +353 (0)
1 4893682

--
olpc-software mailing list
olpc-softwareredhat.com
https://www.redhat.com/mailman/listinfo/olpc-software

Hey Darryl,

Darryl Palmer wrote:
> It appears to be a discontinued product, see 
> http://www.re
dhat.com/docs/manuals/edk/
Yes, it has been discontinued. RedHat seemed to stop going
after the 
embedded space when RH8 came along. That URL may not even be
the product 
I was referring to though, as the docs didn't seem to
mention any of the 
rpm building stuff I remember from the presentation RedHat
gave us. We 
didn't use it simply because at that stage, I'd already
done something 
similar myself (though manually, not via a fancy tool).

Either way, RedHat would still have the code. My guess is
that the tools 
have just completely been forgotten about and no body knew 
about/thoughtof using it. The source code was available to
those who 
purchased the product IIRC.

>  I too questioned why it was chosen to use a normal
Fedora distro and 
> try to blacklist all the files to be deleted, but now
the tools to 
> build it along with the size of the image are just
about on track.
Yeah, but at quite a cost. We've lost RPM as a result of
this approach, 
plus it's never going to be as fine grained as a bottom up
approach. And 
it's still taking up 280Mb of disk space, which is greatly
reduced, but 
still seems like quite a lot for such a minimal product.

It may be that we'll only ever get a few meg off here and
there, and 
it's done now. I was just curious as to how this approach
was agreed upon.

Kind regards,

-- 
Glen Gray <glenlincor.com>              Digital Depot,
Thomas Street
Senior Software Engineer                            Dublin
8, Ireland
Lincor Solutions Ltd.                          Ph: +353 (0)
1 4893682

--
olpc-software mailing list
olpc-softwareredhat.com
https://www.redhat.com/mailman/listinfo/olpc-software

On Thu, 2006-06-01 at 09:19 +0100, Glen Gray wrote:
> Basically, I've been wondering why the OS seems to be
based on a top 
> down approach (starting with Fedora Core 5 and
stripping out a rough 
> guesstimate of whats not required) rather than a bottom
up approach 
> (starting with nothing and using what parts of FC5 are
required to 
> create a small, tailored OS).

It's not really top-down.  We start with a set of packages
that we know
we are going to need (kernel, glibc, python, gtk, etc) and
then use yum
to install those (and their dependencies) into a chroot. 
Then, further
fine-grained stripping is done (glibc locale info, etc).  We
know
[almost] exactly what the base set of packages is.  Plus,
people keep
asking for more all the time.

You have to strike a balance between a completely forked
OLPC distro,
and using an existing project's resources, like Fedora. 
Seriously,
putting Fedora together is a full-time job for quite a few
people, and
there's no reason to think that putting a forked OLPC
distro together
wouldn't be a full time job for a few people too.

These machines aren't normal laptops, and they also aren't
PocketPC-class devices either.  They are somewhere in
between.  You make
a tradeoff between the amount of effort you make in slimming
down the
distro, and how much you benefit from upstream resources (ie
Fedora).
If we fork it and go ground-up, we completely loose all the
security,
development, and distro work that Fedora is doing.  If we go
top-down,
we completely at efficiency.  You have to trade bits of one
off against
bits of another.

You have to start somewhere.

> Using this approach would have allowed for a resulting
system that had 
> rpm intact for use as the package manager and a more
tightly tailored OS.

It's unclear whether there's a need for a package manager
or not.
Updating will likely not be "rpm -Uhv xxx", but
rsyncing files from
flash drives or the school server or whatever.  We all know
the
downsides of dpkg/rpm/ipkg/yum/apt/etc, and I'm not sure
anyone really
wants to inflict those shortcomings on children.  You have
to ask, what
problems does having a package manager solve, and do
children care about
those problems that _you_ think are problems?

The only real requirement here is to allow children to
easily use
software they get from somewhere.  Note that I said
"use", not
"install."  IMHO, you shouldn't have to think
about "install", you just
get the software from a friend and use it.  And I also said
"get from
somewhere," not "pull from a yum repo." 
Because most kids aren't going
to be running synaptic, or pup, or whatever.  The software
distribution
model here needs to be _vastly_ different than what we in
the Linux
world are used to.

Dan


--
olpc-software mailing list
olpc-softwareredhat.com
https://www.redhat.com/mailman/listinfo/olpc-software

Hey Dan

Thanks for the reply. It was concise and to the point. In
fact, exactly 
the kind of answer I was looking for.

All your points make sense and as the title of the email
says, I was 
just looking for clarification on the path taken, which you
have given.

Cheers,

-- 
Glen Gray <glenlincor.com>              Digital Depot,
Thomas Street
Senior Software Engineer                            Dublin
8, Ireland
Lincor Solutions Ltd.                          Ph: +353 (0)
1 4893682

--
olpc-software mailing list
olpc-softwareredhat.com
https://www.redhat.com/mailman/listinfo/olpc-software