On Wed, 2005-08-24 at 20:39, David Douthitt wrote:
> Mike Noyes wrote:
> > Just the leaf guide collection, or the individual guides too?
> >
> > Note: this will take me a while to generate locally. I'm not
> > setup currently for pdf generation.
>
> What format are these in again?
Mike Noyes wrote:
On Wed, 2005-08-24 at 05:33, Luis.F.Correia wrote:
Mike, can you please try to re-generate the PDF versions of all our
documentation?
Luis,
Just the leaf guide collection, or the individual guides too?
Note: this will take me a while to generate locally. I'm not
On Wed, 2005-08-24 at 15:51, Martin Hejl wrote:
> In the end, I tend to agree with Luis. I'm not going to tell anybody to
> stop discussing new possibilities - but discussion without the
> ability/willingness to actually do more than just discuss things is
> pretty much what I contribute to managem
Hi Charles,
> I'm all for modular. Not being able to (easily) backup the initramfs image
> is (in my opinion) not a serious problem, assuming the boot process changes
> as well. I envision the initramfs as containing only that code required to
> build a root filesystem image, or roughly incorper
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luis.F.Correia wrote:
| Is this whole conversation about loading to ram, using initramfs or any
| other kind relevant
| to the current branches of LEAF?
Sure! If nothing else, the discussion of tmpfs and duplication of data in
RAM is (hopefully) en
Charles
Charles Steinkuehler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
..
With pretty much any other filesystem, this is *NOT* the case, and you'll
have two copies of any data (the copy on the filesystem and the copy in the
page cache). This is because tmpfs is the only filesyste
Hello Mike,
It seems that my mails are currently bounced at the list, probably because
of a wrong mail setting at my site. Please forward to the list.
>> Can you tell us what your intentions are? By reading your comments it
>> seems like you are trying to force the creation of new branches.
>
> E
Hello Mike,
Can you tell us what your intentions are? By reading your comments it
seems like you are trying to force the creation of new branches.
>> We don't want to loose the modular design we have now. Not being able
>> to backup the initramfs for example is not a very nice thing.
>
> Agreed
Erich Titl wrote:
> I just don't like to have all these binaries and libraries
> _unprotected_ and _uncompressed_ on RAM disk.
mount -o ro ...
should solve the unprotected part.
--
Natanael Copa
---
SF.Net email is Sponsored by the Better
Hello Erich,
>>
>> That's not true, every module is placed in modules.lrp (repository) and
>> packages are "stand-alone". A module will change with every kernel
>> upgrade, which isn't true for a package like ipsec. You will also get
>> crazy if your package has to be updated with every release, b
Op Wo, 24 augustus, 2005 11:18 am schreef Erich Titl:
> Eric
>
>
> [EMAIL PROTECTED] wrote:
>
>>
>> I don't follow you here. Why do you wan't to use loop mounted cramfs?
>> Does
>> it use RAM or ROM (Flash/HD/Floppy/..). The advantage of full RAM based
>> systems is that you can unmount the storage
Hello Erich,
>>
>> How would such a thing be implemented for all binaries? Cramfs is ro so
>> you can't populate a loop mounted cramfs. This would mean that you
>> either put all /bin, /sbin, ... binaries in seperate cfs files and don't
>> have packages anymore, put a "bin.cfs" in every package co
On Wed, 2005-08-24 at 11:07, [EMAIL PROTECTED] wrote:
> Can you tell us what your intentions are? By reading your comments it
> seems like you are trying to force the creation of new branches.
Eric,
Nothing different than I've always espoused. Nor am I trying to force
anything. However, I still be
On Wed, 2005-08-24 at 08:45, Luis.F.Correia wrote:
> Is this whole conversation about loading to ram, using initramfs or any
> other kind relevant to the current branches of LEAF?
Luis,
No, but it may be relevant to future LEAF branches.
> The way I see it, the team i'm part of has already analys
On Wed, 2005-08-24 at 05:33, Luis.F.Correia wrote:
> Mike, can you please try to re-generate the PDF versions of all our
> documentation?
Luis,
Just the leaf guide collection, or the individual guides too?
Note: this will take me a while to generate locally. I'm not
setup currentl
Hi!
> -Original Message-
> From: Erich Titl [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 4:25 PM
> To: Natanael Copa
> Cc: leaf-devel@lists.sourceforge.net
> Subject: Re: [leaf-devel] 2.6.x kernel support?
>
>
> Natanael Copa wrote:
> > Erich Titl wrote:
> >
> ..
> >
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erich Titl wrote:
| Natanael Copa wrote:
|> Erich Titl wrote:
|>
| ..
|>
|> I dont have time for reading about memory management in Linux right now,
|> but AFAIK the executables and libraries are mmap'ed.
|
| This would mean, that an executable would
Natanael Copa wrote:
Erich Titl wrote:
..
I dont have time for reading about memory management in Linux right now,
but AFAIK the executables and libraries are mmap'ed.
This would mean, that an executable would onle be mapped to memory, but
copied as soon as the memory page it resides on is
Erich Titl wrote:
>Natanael Copa wrote:
>
>
>>Are you really sure about that? I am not really familiar with how the
>>tmpfs or ramfs works, but to me sounds logical that when you execute
>>something on a tmpfs dist, the memory is never copied from ramdisk to
>>RAM, because it is already in ram.
[EMAIL PROTECTED] wrote:
Hello Erich,
..
That's not true, every module is placed in modules.lrp (repository) and
packages are "stand-alone". A module will change with every kernel
upgrade, which isn't true for a package like ipsec. You will also get
crazy if your package has to be updated w
Eric
[EMAIL PROTECTED] wrote:
...
>
> How would such a thing be implemented for all binaries? Cramfs is ro so
> you can't populate a loop mounted cramfs. This would mean that you either
> put all /bin, /sbin, ... binaries in seperate cfs files and don't have
> packages anymore, put a "bin.cfs" in
Hi!
> -Original Message-
> From: Mike Noyes [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 1:32 AM
> To: leaf-devel@lists.sourceforge.net
> Subject: Re: [leaf-devel] Re: Guides
>
>
> On Tue, 2005-08-23 at 15:00, KP Kirchdoerfer wrote:
> > I still don't see that bucu-upnpd
Natanael Copa wrote:
> Erich Titl wrote:
>
>
>>Eric
..
>>
>>
>
>
> Are you really sure about that? I am not really familiar with how the
> tmpfs or ramfs works, but to me sounds logical that when you execute
> something on a tmpfs dist, the memory is never copied from ramdisk to
> RAM, because
Erich Titl wrote:
>Eric
>
>[EMAIL PROTECTED] wrote:
>
>
>>I don't follow you here. Why do you wan't to use loop mounted cramfs? Does
>>it use RAM or ROM (Flash/HD/Floppy/..). The advantage of full RAM based
>>systems is that you can unmount the storage media. Besides the footprint
>>of Bering-uC
Eric
[EMAIL PROTECTED] wrote:
>
> I don't follow you here. Why do you wan't to use loop mounted cramfs? Does
> it use RAM or ROM (Flash/HD/Floppy/..). The advantage of full RAM based
> systems is that you can unmount the storage media. Besides the footprint
> of Bering-uClibc with base packages i
Hello Erich,
>> LEAF runs in RAM, so it's not only a matter of 16 Mb storage but also
>> the availability of internal RAM. This shouldn't be a problem in most
>> cases, but if LEAF is ported to other architectures with limited RAM
>> this could become a problem.
>
> Indeed, and I am surprised noon
[EMAIL PROTECTED] wrote:
> Mike, Homer,
>
>
>>>Yea, but might give some ideas on the conversion. Though, asides from a
>>> floppy, what can you buy today that wouldn't hold a 16MB image?
>>
>>Homer,
>>Not much.
>>
>
> LEAF runs in RAM, so it's not only a matter of 16 Mb storage but also the
> av
27 matches
Mail list logo
