On Thu, Jul 11, 2002 at 08:06:25AM -0500, Brad Felmey wrote: > I don't fret over this the same way I don't lose sleep because some guy > with a 386/SX16 and 4MB of RAM can't get minimal Mandrake installed (for > at least two reasons). Or a 286, or an 8088, or....
You're missing the point. We're not talking about really old 386's or machines with 4MB of RAM. As it stands now I believe the installer takes about 62 MB of RAM (I may be wrong here if so someone chime in with the correct number). A lot of that is used for the 2nd stage's ram disk. The 2nd stage has to be loaded into RAM so that the CD can be changed and to support network installs. Right now the RAM requirements means you can do an installation on any machine with at least 64 MB of RAM. However, /usr/lib/qt3 current takes up 18MB of disk space. That means about 7 MB of more ram to be used by the installer for it's ram disk. Which raises the bar to 69MB of RAM just for an installer. That ridiculous. Once you get over 64MB you start dropping a lot of machines. Further the i586 decision was made for a good reason. The vast majority of machines out there now that people are using for desktops do meet this requirement. Plus keeping support for i386 or i486 would seriously hamper performance. So you gain performance for that trade off. But you don't really gain anything by just switching to qt for the toolkit. Sure maybe QT looks prettier in KDE. But ultimately the tool does the same job. We aren't talking about something that people use everyday. We're talking about configuration tools for the most part. Somehow I doubt most people care if they follow their KDE themes when they use a configuration tool. They just want it to work right. > Many of these tools already have console interfaces. Mousedrake, > harddrake, urpmi, etc. If a toolkit has to be installed for > drooly-pointy-clicky anyway, then what difference does it make which > one? Because of a small difference in size of the toolkits? I will be > glad to tell you with a straight face your argument is weak. We are not > talking about 10MB HDDs here, or 640KB/RAM. A point has to be chosen > below which isn't worried about. Mdk has already decided that 586 is it, > for instance. Should they then be worried about a couple of MB toolkit > size for GUI tools? No. The solution is there for anyone who wants to code it to do it. But the fact is that there is not very good support for qt bindings in perl at the moment and you don't really gain a lot by making the switch. So somehow I doubt anyone is going to expend the effort to do it. Frankly I'd rather Mandrake spend their time fixing bugs or making new functionality than just making a few ocassional use configuration tools prettier. And for anyone that wonders this is how I got my numbers: [breser@occipital breser]$ du -sh `rpm -ql libqt3` 4.0K /etc/profile.d/qtxft3.csh 4.0K /etc/profile.d/qtxft3.sh 18M /usr/lib/qt3 7.1M /usr/lib/qt3/lib 0 /usr/lib/qt3/lib/libeditor.so.1 0 /usr/lib/qt3/lib/libeditor.so.1.0 228K /usr/lib/qt3/lib/libeditor.so.1.0.0 0 /usr/lib/qt3/lib/libqt-mt.so.3 0 /usr/lib/qt3/lib/libqt-mt.so.3.0 6.7M /usr/lib/qt3/lib/libqt-mt.so.3.0.4 0 /usr/lib/qt3/lib/libqui.so.1 0 /usr/lib/qt3/lib/libqui.so.1.0 216K /usr/lib/qt3/lib/libqui.so.1.0.0 The 18 MB in /usr/lib/qt3 is accounted for by the fact that I have the devel package installed. So ignore the directory total for /usr/lib/qt3. But the directory total for /usr/lib/qt3/lib is very telling. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org We tend to see all wars through the lens of the current conflict, and we mine history for lessons convenient to the present purpose. - Brian Hayes
