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.
George P Boutwell wrote:
> On 9/13/06, Henry Nestler <Henry.Ne@arcor.de> 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
> 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
Hm. This would be complicated. The installer is not known the unpacked
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
coLinux-devel mailing list