Lamer friendly DSLForum: DSL Ideas and Suggestions Topic: Lamer friendly DSL started by: JohnH Posted by JohnH on Mar. 09 2006,15:38
Consider presenting the DSL modularity in a very obvious user interface.For example in a starting-from-nothing situation: 1. Download and burn DSL CD from a working system 2. Attach pen drive to target machine 3. Boot DSL on the target machine with cd from step #1 4. A pen drive icon shows up on the desktop 5. Right clicking on the pen drive gives a menu that includes "make this drive bootable" option. 6. If needed a floppy drive icon also appears on the desktop and has "make pen drive boot disk" option with a right click. 7. reboot and system comes up on pen drive (shows toram if selected during step#5) 8. pen drive again appears on desktop 9. user can open pen drive and manage files via click and drag with mouse. There is a folder with applications (firefox, xmms, beaver...). Another folder holds absolute base system (all hardware id and cinfigs, networking, ...) 10. To add programs user clicks on MyDSL icon, selects program and downloads to applications folder on pen drive. 11. system reboot 12. new application is now available using the rightclick on desktop action. For a program upgrade the user should be able to open the applications folder delete the old program, download the new and reboot then have the new program available. DSL is very close to doing this already it seems. I have no skill in the area of configuring such a system but would do a lot of testing for it... In general DSL's strength seems to be it's simplicity and customization potential. I'd like to see that extended by making it super easy to add or remove programs. By setting the basic programs in a folder on the desktop clickable pen drive where they could be easily added , removed or relplaced would streamline the customization process for us not-so-savy DSL fans. Sure it would be easy to totally kill a system like this but so-what! Just take 10 minutes and set up a whole new install on the pen drive. Posted by mikshaw on Mar. 09 2006,16:59
5-7: I'm only guessing here, but it's my understanding that booting from usb is something that is hardware-specific, and I don't think there is any way to determine from within the operating system whether or not it can be done (at least not easily).11: In Linux, a system reboot is generally unnecessary in any situation short of a kernel change. In DSL the reboot typically restores the system to its default state....having things added through a reboot is contrary to this concept. Posted by JohnH on Mar. 09 2006,18:53
Not having to reboot would be cool.What I am suggesting though is to have an extreemly intuitive , minimum number of clicks, no-brainer type of program management that is at the same time very clean and keeps individual programs as independent as possible. This is contrary to the general trend of total system integration but isn't part of DSL is about maximizing low resource hardware? It seems that making it easy to strip any paticular DSL to only the needed parts is within the DSL character and goals. Posted by mikshaw on Mar. 09 2006,20:45
I agree with you that the ability to strip it down to bare necessities (if this is what you are saying?) is a good thing, but there are some issues with this that would make it difficult to incorporate nto DSL without rebuilding the fundamental structure of DSL...1) DSL, according to what the creator himself has said, is intended to be a general-purpose desktop distribution, putting as much typical desktop utility into 50mb as possible. Stripping it further, as part of DSL's functionality, is contrary to this goal. Remastering the filesystem is possible, but it is up to the individual user to do this. 2) DSL's focus is primarily on liveCD/frugal/embedded (running it from a compressed filesystem), making the core of the system uncorruptible and giving the user the ability to return to the original system at any time with a simple reboot. Once you get into making changes to that compressed filesystem, this quality of being bulletproof is gone. Again, The user still has the option to remaster if he wants to change the base. 3) The process of making "an extreemly intuitive , minimum number of clicks, no-brainer type of program management" is also contrary to the basic goals of DSL. For one, package management is virtually pointless in anything but a traditional debian-style installation, which as mentioned is not really the focus of DSL. Second, anything that is made to be "no-brainer" is inherently going to be more complex to create, and ultimately more bloated than simple text files and small-but-needing-some-knowledge programs. The result is that the developers will have less time to focus on improving DSL (killing bugs, improving hardware support, etc) and the user will have fewer applications to use (there's still that 50mb limit). To be honest, DSL has been steadily becoming more user-friendly, in the gui sense. Roberts in particular has been adding a growing number of gui scripts to help the user configure and use DSL. Compared to what DSL was a year ago, I'm really surprised at how much more no-brainer it has become, while still staying tiny. I'm not sure if i ranted enough here...I went for a coffee halfway through...maybe i left something hanging. Anyway, this is mostly just my opinion...not meant to be fact, except for the "focus" part, which we've heard from the DSL devs more than a couple of times. Posted by doobit on Mar. 09 2006,21:53
Mikshaw,I wanted to add my two cents here by saying that I agree with what you said! Robert and John and you too have made many good GUIs for useful scripts in the last year that have made DSL a lot more fun to operate from the Window Manager. That icon tool was a great add. Posted by JohnH on Mar. 10 2006,01:53
Oh dont get me wrong here. DSL is my favorite and probaly will be my primary distribution. The small-versatile-powerful combination that is very impressive.I'd just like to be able to click and drag programs to and from the pendrive. The mount-unmount process for linux in general is pretty cumbersom compared to the Mac-Windows world of click and drag. Streamlining file management into a GUI wouold break down one more barrier to getting that big rush of people to drop windows and go linux. I intend ofn making a lot of DSL disks and passing them out to high school computer class students. It would be nice if configuration and file management in general were a no-brainer. Anyway back on topic. Maybe what I have suggested might better be called "Lamer friendly custom distribution"? Posted by brianw on Mar. 10 2006,19:40
mikshaw, I would also like to add that DSL can be installed to a hard drive and either chopped down or expanded at the users will. Doing this though will eventually lead to a reinstall if you continue to play with options (I know I have done that several times). As mikshaw stated for most the beauty of DSL is that it can just be rebooted and have a clean OS with a desktop OS that serves the prupose of most people. If an extension has been added that causes problems or that the user does not want they simply remove it or put it in the /optional directory of their persistent storage and they have their system back the way they want. DSL gives stability and expandability (with a base system that is very usable) while also providing us adventurous people with an OS that is fast and can be "played with". When I trash my install by adding/stripping things it only takes me a short while to get my system back the way I started (keep apt and DSL downloads on a seperate partition so I can rebuild quickly). Something that should be noted is that windows users don't have this security. When a windows install is trashed (notice I didn't say if) it takes a while to get it back and they don't have the option of a live boot to work with in the mean time (unless they have DSL or another linux laying around). The traditional DSL install (imagine, I have been involved with DSL enough now to call the frugal/live CD install a traditional install) provides users full security with expandability and a complete OS that provides almost everything one could need "out of the gate". DSL is quite small now and giving it the ability to be that customizable would probably increase it's size considerably and make it very hard to maintain. As mikshaw stated that would require a debian style package system with full dependancy checking. The only other real option would be to make all apps MyDSL extensions and only have a base system in the core KNOPPIX filesystem. In my opinion DSL is a very good basic OS at this stage and for most is very user friendly (and also gives people like me freedom to play). Posted by JohnH on Mar. 11 2006,13:52
You said it better than I did! That is exactly what I am advocating. It would make DSL even more streamlined and better fit into it's small-fast-simple focus. Posted by cbagger01 on Mar. 12 2006,07:21
If you want drag-n-drop GUI file management, grab the Rox filer from the MyDSL repository.
Posted by JohnH on Mar. 13 2006,03:13
Ok Thats closer to what I want, thanks.I installed ROX and can open two instances of it but I dont know how to open as super user. I cant make a directory in /CDROM Posted by doobit on Mar. 13 2006,15:52
I missed which type of pendrive install you did. Anyway, I've been finding, with the 2.3rc1 version that writing to /cdrom can be a little tricky. Because Of the way I want DSL to boot up (persistant apps) I've been saving them to the top directory and then adding the mydsl=sda1 cheatcode when I boot up. That way they load automatically. Robert explained that the toram chat code changes everything because you want sda1 to be unmounted after everything is loaded to ram. Then when you shutdown, the pendrive is remounted using the backup script before shutting down. The reason for that is to minimize writing to the pendrive. However, if you put mydsl=sda1 in the boot options, then sda1 is mounted at bootup to look for the mydsl apps and load them. It doesn't appear that it is then unmounted. That leaves it open for user dsl to save files to the top directory. I don't know how advisable this is because I corrupted a file system or two in the past by doing this. Anyway, I've been doing this with the 2.3RC1 pendrive HDD install on my mini-itx system and so far no problems.
Posted by roberts on Mar. 13 2006,20:51
Looks like there is still confusion with pendrive and toram. It actually works the same as a mydsl.iso created liveCD.First anytime extensions are store on the base directory of a boot device they will be autoloaded. Having mydsl=sda1 is not necessary. This is true whether using toram or not. Using toram does not save from excessive writing on the pendrive. Whether you use toram or not, the ramdisk is used for writing. There is no writing occuring back into the compressed image on the pendrive. Then what is the difference? Using toram, if you have the memory, will give somewhat faster performance, as it reads from ramdisk not pendrive. Also it sllows one to remove the pendrive and stick in another one. Just like it does with the liveCD. The only effect toram has on extension loading, is the use of the /optional directory. Since using toram unmounts the pendrive, you cannot click on the optional directory to load optional extensions, unless the pendrive is mounted. The other area that is different is when not using toram, the pendrive is mounted at /cdrom so you can easily copy extensions there. If you use to toram, it is not mounted. So then you must mount the pendrive and copy extension to its mountpoint, typically /mnt/sda1 Posted by mikshaw on Mar. 13 2006,21:00
Although I can't say this from experience, it's my assumption that another issue with using auto-loaded extensions and toram is when one or more extensions is uci. This type is mounted rather than installed, so the partition containing the extension cannot be umounted until the extension itself is umounted.
Posted by doobit on Mar. 13 2006,21:05
OK, I think I get it. I have enough memory for toram, and I specified it in the boot options when I installed to the pendrive, so I need to mount /mnt/sda1 to copy newly downloaded extentions to the base directory. I have found it necessary to have mydsl=sda1 to make them autoload however. Maybe I corrupted something again, or as I just noticed Mikshaw's post, sda1 remains mounted after the boot because the extentions in the base directory are .uci extentions.Is it possible to change boot options and make them persistant after the install? Posted by roberts on Mar. 13 2006,21:10
mikshaw, you are right. Once a UCI is used the device is mounted and therefore cannot be unmounted.doobit, I have see a post that stated the toram option is ignored when entered via the frugal install script. It has only been tested at the boot prompt. It can be verified if a mount display /dev/shm is mounted on /cdrom Posted by doobit on Mar. 14 2006,03:13
OK Robert, I had a chance to test this, and I definately need to put mydsl=sda1 to get them to load automatically, and toram works for me in the HDD install script for the pendrive in dsl-2.3rc1. Also, I wasn't sure if you saw it, but the wireless save script writes a new /opt/myprism.sh line in the /opt/bootlocal.sh everytime I make a change. These multiple entries results in the wireless connecting and disconnecting several times. Still I think these scripts wil make things easier and solve a couple of the big questions that many newcomers to DSL have.
Posted by roberts on Mar. 14 2006,06:09
Yep, using toram does require the mydsl=xxx option.I am currently working on further automation of mydsl loading. It will be in RC2. The multiple copies of the wirless does not happen within a single session. It is added to the save scripts only upon exit and with a yes answer to the prompt question. Also, this only needs to be done once for it is not the individual parameters that is added, it the the script names. Therefore, should you decide to re-setup your wireless, do would not want to save the scripts again. A no answer would be appropriate. Maybe, I am trying to do too much automation? I suppose I could scan for it already, but like I said it is not the parameters, instead it is the name of the script that contains the paramters. Like a link or pointer to the file that contains the parameters. But, then too, field testing and feedback provides further insight as to how it is used. Posted by JohnH on Mar. 16 2006,02:45
Wolvix Linux is working with pen drive issues. They might be worth exchanging ideas with.
|