Re: [coLinux-devel] Roadmap from Devel -> Stable

[Bill C. R. <do...@fr...>]

Sorry, brain fart.  Assuming something like 3:1 for a filesystem is probably
only a reasonable high estimate if the filesystem is being extracted to NTFS
with holes...  Maybe it would just be better to recommend to the user they
have at least 4GB of free disk space available.  If they want to try it with
less, they can.

Bill


On 9/15/06, Bill C. Riemers <do...@fr...> wrote:
>
> This could probably be done just by assuming a high compression ration
> like 3:1 and offering the option to continue even if the check fails.
>
> Bill
>
>
>
> On 9/15/06, Henry Nestler <Hen...@ar...> wrote:
> >
> > George P Boutwell wrote:
> > > On 9/13/06, Henry Nestler <Hen...@ar...> wrote:
> > >> > 3) Re-Write the README for 0.7.x, Ideally I'd like the new README
> > to
> > >> > be short and brief and give folks pointers where to go for most of
> > the
> > >> > information that's in there now.
> > >>
> > >> Add a text file or html as manual, that shows the parameter, the
> > config
> > >> options and some samples.  Currently it's scattered in various files
> > >> (RUNNING, doc/colinux-daemon, doc/cofs) with unsorted samples.
> > >
> > > Is was thinking basically that we get the colinux-daemon to dump it
> > > out (more or less does now), or like you suggest provide an 'man page'
> >
> > > in text file that ships with colinux.
> >
> > Not a real man page.
> >
> > Yes, the dumps where gets from colinux-daemon starts without parameter
> > should put into the text file.  Think, nobody would run this daemon to
> > get the parameter.
> >
> > One text file with a list of all parameters.  And a sample to that
> > parameter.  In the same text file the config parameters and one or more
> > samples.  Remove the text file doc/cofs.
> >
> > >> > 4) Update/Create an 0.7.x Known Issues/Problems page that could be
> > >> > pointed to from the README
> > >>
> > >> If we can not solve the DEP/Noexecute bug: The instaler should show
> > an
> > >> extra page with a warning and a "howto change the boot.ini ...".  The
> > >> installer should sheck the CPU for typical candidate for crashing
> > >> (Intel, >1GB RAM + SP2 + PAE enabled + boot.ini has an entry
> > >> noexecute=OptIn)
> > >
> > > Hmm... I'm ok with that.  I'd rather track down the problem and fix
> > > it, though if we could.
> > > I'm trying to recall... does the coLinux installer crash during the
> > > install (probably the colinux-daemon --install-driver), if it does not
> > > only would we have to display the message, but we'd have to 'abort'
> > > the install or skip the colinux-daemon --install-driver & inform the
> > > user of how to run it.
> >
> > No, the installer is not crashing in the "colinux-daemon
> > --install-driver".  It's later on first running Linux.
> >
> > >
> > >> > 5) Create 0.7.x default colinux config which uses initrd.gz & SLiRP
> > to
> > >> > have a running 'very limited' but internet connected coLinux at the
> > >> > end of the install.
> > >>
> > >> I'm preferred to use the first network with slirp (eth0).  Power
> > users
> > >> should use the second network (eth1) for additional types (tap,
> > >> Pcap-bridged).  We should clear about this before changing the
> > images,
> > >> so all images have similar networks on startup.
> > >
> > >  I think we are in agreement here more or less.  But for me power
> > > users are free to 'take over' eth0 and not use slirp at all if that's
> > > what they wish to do... Just the installer & images are going to be
> > > initially set-up that way.
> >
> > Yes, that I mean.
> >
> > >
> > >> > 6) Update install to make TAP optional install and require that it
> > be
> > >> > specifically selected.
> > >>
> > >> Very good idea.  The Pcap-Bridged in same.
> > >
> > > Yes, if Pcap-Bridge is not already this way it should be this way.
> > > Except that PCap's actuall driver needs to be a seperate install like
> > > it is now.  This is a request from the PCap project's developers.
> > >
> > >> The installer should have two or more "InstType".  For sample
> > Standard,
> > >> Full and User.  The Standard should be the typical installation with
> > >> Slirp only and a Debian (or ArchLinux) image.
> > >
> > > I'm not targetting this situation in this release of coLinux, but I'm
> > > not against it either.
> >
> > OK.  Stike it out.
> >
> > >> The installer should uncompressing the image file, selectable by a
> > >> checkbox "yes/no".
> > >
> > > Again, I'm not targetting this for this release of coLinux.  If we do
> > > something like this, I feel that if at all possible, we should do a
> > > free space check that includes this file uncompressed... otherwise we
> > > are just inviting users to be frustrated when they download coLinux
> > > run the install and it dies uncompressing because it ran out of disk
> > > space.
> >
> > Hm.  This would be complicated.  The installer is not known the unpacked
> >
> > size.
> >
> > --
> > Henry Nestler
> >
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services,
> > security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >
> > _______________________________________________
> > coLinux-devel mailing list
> > coL...@li...
> > https://lists.sourceforge.net/lists/listinfo/colinux-devel
> >
>
>