https://bugzilla.novell.com/show_bug.cgi?id=239630 ------- Comment #19 from webclark@rochester.rr.com 2007-02-21 19:47 MST ------- Warning, this is long. But I think/hope I make some good points. I will try to convey difficulties I see with the current situation and explain how I believe it can be fairly easily addressed. Please forgive me if I come across as being excited... I am! I am anxious for Linux to be usable by "normal" people, and I feel that there is a very thin barrier, the main barrier being an assumption by Linux people that the user knows how Linux works on the inside, and that if they don't, too bad, they better go learn. I believe the concepts you need to convey are are easy and the functionality you need to provide is minimal. What does do a "minimal installation without add-ons first" mean? That I can do anything I want with the base, just don't do any add-ons? Or should I also just accept the default to minimize changes (which generate logs)? Or should I cut down the package list to minimize what is installed? And will this work with 256MB? You specify 512MB, but I feel that 256MB is a magic number because Linux does not run too bad in 256MB for a single user, and I have 6 machines with that constraint. But can I install? People's old windows machines are becoming less and less functional, and they balk at pouring money into a new machine and XP or Vista. They just need reason to hope that it is going to work and not be a hassle. This is a real opportunity for Linux. Having read the "Installation with Little Memory" guidance on the wiki, these are written for someone who is familiar with the Linux and/or Suse boot process. This is probably obvious to the author, but not to your average user. This is good for one set of users who wants to know, but not most who want to get it installed. I am no dummy, and have been using and installing various version of UNIX, SunOS, and Linux for 30 years. I can understand almost anything, but I don't know the implementation details of the linux boot process (although I am learning). And everyone does not WANT to understand, or have time to understand.
But before it is made more usable, there is something more important, whether you do anything about helping people with low memory or not:
[1] Enable the installer to monitor space or detect when it runs out of memory BEFORE it malfunctions. Put up a message and stop, even if very ungracefully. Rule number one is to not continue working in a corrupted state. Currently you get corrupted during package selection and continue, partitioning and continue, etc. Stuff I put in disappears, and I just keep recirculating in the menus hoping it will stick and I can get an install. Sometimes I can! If I get through, what confidence do I have that it worked right? What about if I have enough memory that I have no apparent problems? Can I trust that there are no hidden problems that are going to cause unexplained problems to chase later? Something that fell off of the end of the shell variable assignment on a boundary that happened to not cause a problem? What if it appears to work and I load all my data on but something is not right? I need to have 100% confidence that *IF* I get through the install smoothly, that it worked correctly, as I specified. As for dealing with low memory: [2] You indicate that one can do the add-ons later. I was not sure if there were trade offs between doing it up front vs. later, and I was not aware that selecting it used a substantial amount more memory. A list of 10,000 50 character package names would only take 512K of memory. It is not that simple? I do not have visibility into your implementation details. Inform me of the constraints and provide functionality or information to deal with them. Explain/define up-front on a screen, or in the installation instructions, the behaviors which result in the minimum RAM being used during install. It is only fair to leave out stuff that can be delayed until later with reasonable ease and without consequence. For example, you have a great integration of md and lvm. I expect that if it is possible at all that it would be much more difficult to set up my mirrored partitions and logical volumes later. A question I have after reading all of your comments above is whether minimum memory requirements are achieved with minimum package installation or minimum deviation from the default install! This could be a critical point. It would only take a couple sentences to convey what is needed. Regarding the "reduced memory" advise, does the text mode installer provide the full/same functionality as the graphical? I should not have to take the time to experiment. Please just tell me what the tradeoffs are so I can choose the correct direction without trial and error. This is yes/no and perhaps a short list of generalizations to tell me how it is different. I don't know what a linuxrc parameter is. Can you tell me in a sentence or two what to do rather than refering me to a generalized writeup on a Linux subsystem? "When it says this, type any of the following separated by a space". Addition of this single sentence would have made the wiki "Installation with Little Memory" write up much more useful, useful for anybody! Or better yet, you could add a screen up front with buttons and text boxes to toggle these things for the user. You don't want to have the installation dominated by this memory stuff, but I am sure you could identify 2-3 key options to present or communicate that would get the user 95% of the possible benefit. I am guessing that these are parameters on the boot process... Yet some look like parameters for YAST, and so could be set in the first screen. Perhaps others could do a "reboot" to set them as the user specifies? With regard to the specific linuxrc recommendations, what does adding swap do for me in a practical sense (Yes, I understand the concept AND implementation of paging in extreme detail, but I DON'T understand how this relates to YOUR installation scripts!). Does this completely eliminate memory concerns? End of problem, especially if I can swap on a flash drive (Although older PCs do not have a USB interface). But will this wear out a flash drive in one install? If an installation would result in more than a new hundred write cycles perhaps this would be an appropriate warning. We are not dumb, we just don't want to read the source for the installer to understand how to install! Finally, I understand that the user's behavior affects the memory needed. But you could present a small number of concrete examples at key points in the continuum (NOTE TO an uninvolved reader: The statements below are NOT correct, they are examples of the KIND of statements or options that might be provided!!!!) * Two memory requirements in each of the examples below are given with/without logging enabled. A log enables Suse to debug problems should they occur. If you disable logging and encounter problems, it will be impossible to help you. * If you accept the xyz default and go with a single partition it will install with xxx/yyy MB. You can then add and remove packages later using YAST. * If you pick the "Minimum Package Set" button you will be able to install with the minimum amount of RAM (currently 192/yyyMB). Adding additional packages later using YAST will work identically to the installer and result in an indistinguishable installation". * Performing a complex partitioning scheme requires more memory during installation. For example a system with 4 disks, 8 partitions on each, mirroring and setting up LVM would require an incremental 64/yyyMB over a simple single disk/single partition installation. This means for example that you should expect to be able to do an install with 256/yyyMB of memory if you select the minimal package set yet have a very complex partitioning scheme. * Every menu action results in more memory being needed due to logging. Your mileage will vary as your actions vary. (This gives the user a reference point, and tells him how to minimize requirements.) [ ] Check box to disable all logging to eliminate memory size dependence on navigation and browsing during installation. * "512MB should be sufficient for all installations, although excessive menu navigation during package selection or partitioning could require more memory." I also question if the default should be with logging enabled. Problems are presumably rare, and of those cases it is probably rare to send the logs to someone who can read them. Normally logging is disabled, and people are instructed to enable it in case of problems. In this case, the very act of logging appears to be causing the system to not be functional. This is not good. --- I personally am left with the question as to whether I can trust the result if I put in 384MB and it seems to work, or 256MB and select less packages and it seems to work. And I don't know if I should de-select packages to minimize the number or just run with the default to minimize changes. I wish I could make more concrete suggestions instead of beating around the bush, but I don't know enough. I believe a few key additions to configure the installer and a few simple statements of explanation would go a very long way to enabling users to install Suse with the minimum of memory. If you got this far, thank you for listening, and I hope this helps you to make a better installer. If you can help me understand what to do in the short term, that would be appreciated too. I know you are not tech support, perhaps I can learn by listening to you through this thread. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.