Luis.F.Correia wrote: >Hi Natanael! > > > >>-----Original Message----- >>From: Natanael Copa [mailto:[EMAIL PROTECTED] >>Sent: Thursday, August 25, 2005 3:08 PM >>To: [EMAIL PROTECTED] >>Cc: Mike Noyes; [EMAIL PROTECTED]; >>leaf-devel@lists.sourceforge.net >>Subject: Re: [leaf-devel] 2.6.x kernel support? >> >> >>[EMAIL PROTECTED] wrote: >> >> >> >>>Evolution is also (slowly) making things better by >>> >>> >>developers filling >> >> >>>up gaps (like webconf), provide missing packages, making "proof of >>>concepts" for new technology or creating a new package format like >>>Nathaneal did. But in the end it would be nice to bring it >>> >>> >>all together >> >> >>>instead of abbandon branches. >>> >>> >>> >>> > >To start it's 'Bering' not 'Bearing' :))) > >
lol ... *blushes* :) whatever... >>Personally I think the bearing *concept* is very interesting. >>Load runtime modules (lrp's) and run from RAM. After the >>enlightening discussion about tmpfs I think it have become >>even more interesting. >> >>Some people that I work with is interesting in pushing this >>concept futher. What if we run squid from RAM (actually we >>already do this)? what if we run a mailserver from RAM? what >>if run LDAP, SQL etc etc, things you might want to do in >>bigger environments. >> >> > >There is an RFC that strictly forbids the use of mail queues >that run in a ramdisk, search the ML archives for the proper >document. > > Yes. I have been through that discussion (we are currently using mail-proxies from RAM with no spooling om RAM disk), but the idea with running mail/sql/ldap server from RAM is this: run the services from RAM. Run the database/spools on any kind of backen storage harddisk/raid/lvm/nfs/ifs/whatever. the server goes down. (cpu burns up, the power burns up, the building burns up (backend storage could be ouside building)) Now, how long time does it take to get that server up and run again? Well... grab the nearest available server hardware, burn a new cd image (or floppy or usb stick or whatever) and get a copy of the latest configuration of that server. (Since the server runs from RAM you need some kind of backup that survives reboots anyway) Boot it up and connect to the backend storage and you are up and running again. Since we also run from RAM there are no moving parts that increases risk for hardware failure. Since the executables are loaded into RAM during boot, instead of running from a loopdevice mouned on cdrom, there are never any delays caused by the cdrom spinning up. The run-from-RAM concept is interesting. >>Suddenly we are in the possition where we look for using this >>run-from-RAM concept for solving other problems, targeting >>other goals than LEAF/Bering is supposed to. >> >> > >No objections there, of course! > > > >>Now, I agree completely that forking and abbandon branches is >>generally a bad thing, but sometimes the goals changes and >>sometimes it changes fast. I dont expect that the >>LEAF/Bearing team should change their goals just because the >>needs in my environment changes. >> >> > >That was not my intention at all, i guess a lot of things I >wrote were misinterpreted. > > Maybe. Anyway.. I believe most of us agree on things. We just see things from different angles. >>So instead of pushing my needs/goals to the current projects, >>I start looking for other distros and projects. If there is >>no-one suitable, I create something new or fork and while >>doing so, I do everything that is in my power to make sure >>that others have the possibility to benefit from my stuff. >> >> > >You can join LEAF with your GNAP based distro, as it is not >that far apart from what we have now. And maybe we in a not >So distant future can benefit from the things you have discovered >and fixed in the meantime. > > Thanks. Things are really floating here right now and I'm not sure if joing LEAF is the way to go. And I can asure you that you already have been benefited from things related to this project, even if it not is directly from me. btw its based on Gentoo not GNAP. Its more a sibling to GNAP than a child of it. -- Natanael Copa ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
