Vadim Goncharov wrote: > Oliver Fromme wrote: > > [...] > > > > The xorg packages on disc1 occupy 54 MB. Not really all > > > > that much, I think. The linux base, perl and python occupy > > > > another 50 MB together. The rest are small utility things > > > > and dependencies (only a few MB). > > > But that is still valuable if geom_ugz is in use. > > Have you actually tried it? Providing hard numbers is > > more useful than just talking about it. :-) > > I've used Frenzy LiveCD many times (http://frenzy.org.ua), a > Portable SysAdmin Tool. It is 200Mb minicd with MANY useful > packages. It has X Window and many graphical and console > utilities (about 600MB uncompressed). It proved to be stable > and not-so-slow. Nice. Looks very interesting and useful. Maybe there should be a link to it somewhere on freebsd.org. :-) Would be interesting to know how it performs on rather slow and resource-limited machines, i.e. slow processor and low RAM. It's important to keep in mind that many novices who want to give FreeBSD a try will install it on an older spare machine. So the installer and live FS should run well on older hardware. It's for the advocacy reasons that you mentioned. ;-) > The less for /boot should be compensated by 16K cluster size. But those > numbers are for utilities - are there any docs on ISO ? My numbers were only for the "fixit" live FS. It doesn't contain any docs except manpages and info files. > > > [the new installer] > > > This will surely not be finished before 8.0, > > I'm not so sure. > > May be. But it definitely won't be bug-free and default installer > before 8.0. True, that's unlikely. > > Users who refuse to read docs will also refused to read > > docs that are directly available on the CD. > > Users unwilling to read docs cannot be cured by technical > > measures. It's a user problem, not a FreeBSD problem. > > When you say so, you lose a number of users. I'm not afraid of losing users who refuse to read docs. > > Note that you cannot use that menu entry once the actual > > installation has started, though. You can only abort the > > installation, then go back to the menu, read the docs, > > and then begin a new installation. That's a pain, too. > > Of course, once the installation has progressed so far > > that the docs have been installed on the harddisk, you > > can read them on the shell that's opened on Alt-F4. > > That's a drawback. True. > I think there should be another sysinstall's console on > which docs are always available. I completely agree that sysinstall could need a few improvements regarding docs, packages and other things. Unfortunately, patches don't come from thin air. Someone has to write them. :-) > > Still, it's best to read the Installation chapter in > > advance, or even better, have a printed copy on paper. > > It is not ethical to require users to print docs before. I don't mean it should be a requirement. But it's not a bad idea to do it. Or have the online copy open on a second machine. Or even buy the printed Handbook. (Some vendors offer a bundle of the Handbook + DVD.) > Yes, but DVD is still in the future. I don't quite understand. Most PCs have a DVD drive. You can buy DVD-ROM drives for $20. Sure, there are old boxes that still have CD drives only. I'm not saying that FreeBSD should stop making CD ISO images. But it doesn't have to be the main focus anymore. The majority of people do have DVD drives, so the focus should move to providing a DVD ISO image, getting rid of various problems (space constraints, CD shuffling annoyance). "Legacy" CD ISO images could still be provided, but it's lower priority. > > Such comparisons are bogus anyway. I've installed SuSE > > linux before, and I think the graphical installer is > > terribly annoying. It's worse than Windows. It took > > me a lot longer to get a usable system installed, and > > even then it installed different sets than the ones I > > selected (I have no idea why). In my opinion, FreeBSD's > > installation wins big time. > > I've not said anything about graphics installer - but features/functional > only. Yes, my point was about features and functionality. I don't care if the installer runs in text mode or graphics mode, as long as it still supports text mode e.g. for installation via serial console, and as long as the design of the graphical installer does not interfere with usage. For example, when the animated files images that fly from the CD icon on the left to the harddisk icon on the right during installation take 75% CPU time on a slow machine, doubling the installation time, then something is clearly wrong. > > > Imagine a review like this: > > > "That SuSe or Debian are wonderful with great number of software instantly > > > available and with this FreeBSD I must wait for download and then compile?! > > > Such shit! Don't use it, if they can't do this, they can't do other usable > > > things!" > > Such a review is worthless and shouldn't be taken serious. > > I really don't worry about that. > > You don't, but a number of users can be lost. Advocacy, again. You cannot do anything against clueless reviews. There will always be reviews from people who don't get the facts right and draw wrong conclusions. And from people who are opposed to FreeBSD in the first place. ("So, lets see if the FreeBSD dumbheads did it any better this time, but I really doubt it. Nothing beats Dubian Linux anyway.") > > > And what about at least shell and some other tools? > > A shell and a few tools (very few, admittedly) are included > > in the MFS image in the /boot directory. > > And there's also the shell opened on Alt-F4 once the > > installation has started. For anything else there is > > the "fixit" live FS. > > That's shells are almost useless because even "ls" don't work. echo * > > OK, here are the results of 7.0-RELEASE/i386: > > 348 MB gzip'ed (default) > > 297 MB bzip2'ed > > So the space saving is 51 MB (14.7%). It took 45 minutes > > on my machine to create the bzip2-compressed files. Here > > are the decompression times: > > 0:57 for the gzip'ed sets > > 7:20 for the bzip2'ed sets > > So it takes almost 8 times as long to decompress. The > > machine was otherwise idle, and the times were reproducible > > with good accuracy. > > OK, agreed. But bzip2 can be left as option to the future for some system prts > not in default install, if sizes will grow... Yes, I agree, that option might be explored in the future, especially for other architectures, for example ona md64 bzip2 isn't as bad as on i386. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris TorekReceived on Tue Mar 18 2008 - 13:33:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:29 UTC