Forum: Release Candidates
Topic: DSL v4.2RC1
started by: roberts
Posted by roberts on Dec. 11 2007,01:49Change log for v4.2RC1
* New mtpaint replaces xpaint.
* New folder for better support of Visual Styles for JWM .jwmrc-theme and downloadable themes.
* New setTheme.lua, drag-n-drop or double click application style.
* New folder for better support of backgrounds, downloadable "DSL Classics"
* Updated wallpaper.lua, drag-n-drop or double click application style.
* Improved support for JWM keybindings with .jwmrc-keys
* Improved support for battey names in torsmo, fetched from /proc
* Fixed "?" icon to open "Getting Started"
* Updated iconViewer for mtpaint change.
* 21 icons have been changed, updated, or replaced.
* Updated /opt/.dfmext with more associations.
* Cleanup of usused files, modules, and directories (pnp & xfs)
Files that have changed and likely in your backup.
Posted by andrewb on Dec. 11 2007,04:43First impression of 4.2rc1 - very clean & sharp looking with the new icons. Keep up the great work.
One point I have meant to raise some time ago - DMIX: it doesn't work properly with systems which have more than one mixer device. The way John coded the 'grab and stack' function in mixer_common.lua duplicates the entries for all mixer devices other than the first one. This is because the device name 'mixer' results in the command 'umix -d /dev/mixer' outputting the device list for all mixer devices, not just the first one. I haven't found the method to just list the first mixer device on it's own (called just 'mixer' when umix -q is executed, in my case the second mixer device is called mixer1). I did have a different way of resolving the problem of multiple mixers, but that was coded before DSL changed to murgalua & it gave segmentation errors under some conditions. I will try & have another look at it.
In the meantime just a note to some people that they may see some channels listed twice as they click through the devices in DMIX.
It would be useful if people could report the output of umix -q, in particular the lines at the start of each mixer section so that some common identifying feature can be found to search for to delimit between different mixer sections in the output (the last time I looked at my output the string 'OSS' was a suitable search candidate to identify the line at the start of each mixer device section in the umix -q output).
Posted by john.martzouco on Dec. 11 2007,12:21
The mixture of all those rainbow colors on the command menu is very, very disturbing. The old icons had more pizzazz at full size. The desktop looks worse now. It's funny that you replaced the good looking icons with worse ones, but all of the amateur looking set is untouched.
Why don't you completely remove the ugly little icons from the command menu? and continue using professional looking icons as you used to have? Slax has a nice variety showing up on their modules page: < pleasant icons. >
Sorry for the criticism, I wish I didn't feel this way, but it's getting worse with each iteration.
I've downloaded them all, they are in a < zip file here. >
Just so you understand, I wouldn't care so much if I didn't think this is a kick-ass product! DSL is the number one distribution in my books! I've tried a bunch of others and nothing compares to what you've produced here. As always, my congratulations on the great work done - I'll continue using the good and eventually fix the bad.
Posted by lucky13 on Dec. 11 2007,14:40
DSL isn't about eyecandy, it's about function. It's also not butt-ugly. Aesthetics is a subjective issue and something every user can choose to handle on his or her own. There are tools in and for DSL to make this easier. I think enough concession has been made in this area.
The icons in your zip are PNG and aren't uniform in size. DSL has tried to settle on a uniform 32x32 xpm. You will not get those to scale and convert to xpm and have the same level of smoothness without increasing them significantly in size. It doesn't help your case that DSL doesn't use smoothing/blurring graphics libs, so curves and diagonals are going to break and will only look pleasing on certain backgrounds depending what color the icon borders are.
Here. I scaled them down to 32x32 and converted to xpm. My ugly folders are 1.5kb each. Your pretty icons are nearly 10kb each. I'll try to get a screenshot of them after I get off this conference call. Don't be surprised if they look as crappy as the smaller ones do per what I said above.
< http://lucky13linux.files.wordpress.com/2007/12/iconhysteria.png >
EDIT: The display icon is fine, but it's 10kb. They'd look a lot better on a dark background to hide the jagged edges -- but not everyone wants a dark background. They'll look worse when force-scaled down into the tray or the menu. The default set in DSL are generally much smaller and users can find their own icons, create their own themes, etc. This is enough talk about the aesthetics. Please.
< http://lucky13linux.files.wordpress.com/2007....ves.png >
Posted by lucky13 on Dec. 11 2007,15:20
Is it necessary to leave some of those other fs modules in the base? How many people need Mac (hfs/hfs+) and BeOS (befs) filesystem support, and can't they be accomodated via module extensions? If we don't have the progs to take advantage of the modules, why retain them?
Posted by john.martzouco on Dec. 11 2007,15:31
It was prettier one iteration ago. And pettier still last major version.
There's no reason why form and function can't co-exist.
If DSL is only about function, then why not strip out all the icons from the desktop and the command menu? Then it will look crisp and austere instead of amateurish.
Posted by roberts on Dec. 11 2007,15:55
True. Good comment. I will remove them.
Posted by roberts on Dec. 11 2007,16:21john.martzouco, DSL is about size and function. I am not going to support high color jpg, png, gif, animated or not, whose sole function is eye candy.
If you think that makes DSL look dated or "amateurish" then so be it. I can't please everyone.
I have tried to accomodate the cristism of the icons, when sized down for JWM menu, by using these new more square looking icons. I very much appreciate those in the community who have contributed icons or suggested other small low color icons. And I will continue to do so.
I have also purposely used icons of low-color so that the smaller less powerful computers may acutally be able to display icons. In the past with xtdesk and the icons from 3.x some users had no option but to not use icons.
These issues likely don't affect many users with gbs of memory and ghz processors, but those of us who don't have such at least have an option (icons) that we didn't have before.
While most distros grow bigger in size and have constantly larger hardware requirements. DSL has actually difted downward not only is size of the distro but in actual hardware required to run it.
Your repeated and constants rants about eye candy is not going to make DSL to jump aboard the bloatmobile.
Your comments to drop all icons is ridiculous and extreme. I could not entertain such "logic". You have posted your opinion repeatedly, enough is enough.
Posted by curaga on Dec. 11 2007,16:51For lucky13's comment on not having programs to operate on some filesystems, we only have programs to operate on ext2/3 and still some like to mount reiserfs or whatever.. I agree with hfs and bfs being unneeded though.
Posted by lucky13 on Dec. 11 2007,17:13
Let me summarize a few basic criteria about icons, eye candy, etc.
First, the icons must be small in size because they load into RAM with jwm and dfm. Some people are using DSL with 64MB or less RAM. That doesn't need to be eaten up with 50 icons that weigh in around 10kb each -- that's half a MB.
Second, the more colors in an XPM the larger it will be. Those icons are text files and the more data they contain, the larger they get. My ugly folder icons use a very light gradient to give a mild "shiny" appearance, and the gradient I chose gives only a couple extra colors to the base color of each icon. My focus when I made them was to make them aesthetically-acceptable in as small a footprint as possible. My goal was 1kb each -- and I may try to get some in that range even if it means removing gradients so they're flatter.
Third, icons with excessive "wiggles" tend to break as they're scaled down. That means the more vertical and horizontal they are, the better; the more curves and diagonals, not the better. Boxes may not be very pretty, but imperfect squiggles get ugly very fast. When I re-scaled the icons I took from your zipfile to 16 -- which is a closer approximation to the size of the icons in my menu -- the handles on the umbrella and magnifying glass disappear; they would not be visible on darker backgrounds at all (then you might complain that there's only a blue thing with a yellow dot, a circle, and a multicolored blob on the menu). The only way around that is to make the tray and the menu settings 32, which is way too big for monitors with lower resolution and space. That would also require the use of larger fonts or else the icons would be ~3x the size of the fonts next to them. That won't work because DSL doesn't start big and work down, it starts small and can grow to what you want (modularity). Here's another shot of your icons scaled to 18 and 16 pixels to show how the handles start to disappear:
< http://lucky13linux.files.wordpress.com/2007/12/heresjohnm.png >
Finally, users are free to find what works for them. I have a jwm-menu sans icons per my anti-WIMPS project. You definitely don't want that in DSL releases. But what I'm doing to avoid a mouse/touchpad on my laptop is not the focus of DSL 4 development.
DSL 4 is not about the icons, themes, or how pretty the desktop is. Users are free to change icons, wallpaper, jwm themes, gtk themes, etc., to suit their own tastes -- it's a fairly blank canvas like that, providing the bare (damn small) essentials. DSL 4 is about the utility afforded by using a file management system that integrates applications according to data (MIME-type) relationships on the desktop. That's where our focus lies.
DSL has to stay suitable for those with less modern hardware. When building something in modular fashion, you don't start with something big and start to break it down. You start with a small, solid base and expand it as needed or desired. That's what DSL allows you to do.
Posted by lucky13 on Dec. 11 2007,17:26
There's a difference between bfs (Unix ware boot file system) and befs (BeOS). Both are in the base. I think bfs can be moved to an extension if anyone ever asks for or needs it. Dittos for some of the other less-standard filesystems (jfs).
21K ./adfs -- Acorn (RISCOS)
34K ./befs -- BeOS
14K ./bfs -- Unixware Boot File System
14K ./efs -- Enhanced File System or Irix' Extent FS?
89K ./hfs -- early Mac? or HP-UP FS?
58K ./hfsplus -- later Mac? or SCO High throughput FS?
176K ./jfs -- HP-UX, AIX, OS/2 WarpServer 5
31K ./minix -- Old Minix fs (Linux no longer needs this)
Posted by Nigadoo on Dec. 11 2007,17:46In regards to the "embedded thread" started by john.martzouco...
I think DSL's "project statement/mission/vision/you-name-it" needs a little more visibility. If I understand correctly, maximizing functionality within size contraints rules the day. DSL has given my four old laptops an extended lease on life, so I'm all for DSL's not-quite-visible-enough goals.
If DSL can make it easier to customize/extend for more pizzaz, within size constraints and without impacting functionality, I think that's great! Otherwise, forget about it.
Please, never compromise functionality for eye-candy if and when DSL necessarily needs to bust the 50MB limit! (I'm sure that day will come; let's just hope we still have Robert S. around to keep it all working!)
THANK-YOU Robert S. for your great work AND john.martzouco + all others who help make DSL better via feedback and other contributions ... users like me really appreciate it!
Posted by JohnJS on Dec. 11 2007,19:39Didn't have this error with 4.1rc3.
With 4.2rc1 at start-up at harddisk partitions..." /etc/fstab modprobe cannot locate module xfs".
Is this important?.
Everything seems to work correctly except some errors on shut-down after checking xmms tone.
libasound.so2 cannot open shared object file; no such file or directory.
/usr/lib/xmms/input/libcdread.so undefined symbol.
libmikmod.so2 cannot open...
libgl.so2 cannot open
Xmms tone works okay.
Posted by roberts on Dec. 11 2007,20:32
Same can be said about the firewall support modules. DSL does not have any support programs to use them. We have such only in an extension. I tried once before to move the modules into the extension. Doing so could also performance enhance DSL. Perhaps this is a good time to try again.
Posted by roberts on Dec. 11 2007,20:35
DSL does not have xfs support programs, so the xfs module has been dropped. Do you actually have an xfs partition? If so, how would you take advantage of it while in DSL proper?
The items mentioned with xmms have always been that way. There has been no change in modules relating to sound, nor any libraries updated or dropped.
Posted by JohnJS on Dec. 11 2007,23:09Finally got rid of the module xfs warning.
FYI tried out a friends Puppy LiveCd. That may have been the cause.
All is well now.
Thanks roberts for your info.
Posted by frankseu on Dec. 12 2007,12:32Hello,
as there will be some filesystem support obsolete (perhaps) how about a ntfs-3g support (free ntfs write/read) ?
Posted by Juanito on Dec. 12 2007,12:51I've been looking at trying to make this work on dsl in a couple of ways:
1. ntfsmount (ntfsprogs & fuse)
2. recompiled ntfs module
So far ntfsmount requires a version of the fuse module that only compiles on 2.6.x and the recompiled ntfs module gives missing symbol errors...
Posted by JohnJS on Dec. 12 2007,17:46
Question: those errors re xmms on shutdown using 4.2rc1 did not appear when using 3.4.7. on the same computer.
Did a "fresh" installation of 4.2rc1.
Posted by roberts on Dec. 12 2007,18:10This old < thread > may help explain that those libs are not needed.
Why you see them upon shutdown, may actually be from when xmms was started, especially if they appear on the console screen after X is shutdown.. They do not affect intended use.
Posted by JohnJS on Dec. 12 2007,19:06Thanks roberts.
If I start xmms from menu (dsl/apps/xmms etc..) ala 3.4.7 the error messages do not appear.
Keep up the good work.
Posted by roberts on Dec. 12 2007,19:13Yes, I was able to reproduce what you have seen.
Both JWM and Fluxbox swallow the "errors".
Dfm just as Emelfm do not.
I can add a 2>/dev/null to the startup icon from xmms in dfm.
That will make it work like both window managers menu items.
Thanks for reporting this.
Posted by roberts on Dec. 12 2007,19:26
One could easily make a unc extension of icons with the same names as those found in /usr/share/dfm/icons. Loading such an extension at boot time would allow one to have their own "customized icon set" as an overlay replacement.
Alternately, one could add icons to a directory in their home directory and then change the icon setting via dfm options. This would produce a unique .dfminfo. Since both .dfminfo and your personalized icon directory are in your home directory, they would be included in the backup/restore process.
Both are easy ways to "have it (icons) your way"
But of course, I would continue to encourage all to post screenshots so that option would remain open for possible adoption as DSL's default collection.
Posted by meo on Dec. 12 2007,20:48Hi Robert!
I haven't followed this thread (no time) but I just want to give a spontaneous comment after just taking a glance at this RC: Well done!!!
Posted by infinitycircuit on Dec. 13 2007,04:21The pendrive-usbhdd.sh script in /usr/sbin is broken. It works up until the last step, when it tries to copy the kernel and the initial ramdisk. It tries to copy /cdrom/boot/isolinux/linux24 and /cdrom/boot/isolinux/minirt24.gz but the directory /cdrom/boot does not exist. In fact, I don't know where the kernel is when I try to copy it manually.
The new release of DSL looks excellent. If not for shaky WPA support in the backported ipw2200 driver, I would be using it on my production machine.
EDIT: I believe I discovered the problem. /dev/shm is mounted on /cdrom, not /dev/cdrom1, so it only sees the KNOPPIX filesystem on /cdrom. Manually mount /dev/cdrom1 on /cdrom2 and copying the kernels is a temporary fix.
Posted by roberts on Dec. 13 2007,04:27You must have booted "toram"? I thought I had a check for that.
Nothing I can do about the limited support for 2.4 kernel and WPA, ipw, and others.
Posted by lucky13 on Dec. 13 2007,14:05
Now that I've gotten to the bottom of my XFS daemon issue, I think it makes a lot more sense to move various modules to extension. It really doesnít fit in with DSLís no-bloat philosophy to include modules that canít be used because the tools to use them arenít even in the repository. Some of those filesystem modules for which there are available progs in MyDSL can be added to those extensions. That shouldnít be too inconvenient for those who actually want to load and use them since the progs are already an extension -- e.g., combing ntfs with its progs as well as reiserfs and its progs.
I don't know how many more modules you want to remove from the base.
Posted by JohnJS on Dec. 14 2007,18:32
the modeprobe error re xfs module only appears when I attempted to add a second harddrive (with 2 ext2 partitions).
Posted by lucky13 on Dec. 14 2007,18:51
I think that's related to the issue I've had with the hotplug script shotgun-loading modules and rewriting fstab. Do you mind getting that error again and then copying and pasting the results of lsmod here to show how many fs modules load?
Posted by roberts on Dec. 14 2007,19:05The hotplug script in question is /sbin/hotplug-knoppix which is called via
This is a long standing issue even beyond Knoppix 3.4 (which DSL was last built from), into 4.02 and was never solved. From Klaus Knopper's postings it can only be solved with 2.6 kernel and udev.
Unless ext2 drives are being hot swapped I don't know how the script in question could be called.
What is meant by "add a second hard drive"? Perhaps it is hot swapping.
I don't think a 2.4 kernel is going to handle that well, if it can't handle multiple usb mounts/umounts.
Posted by JohnJS on Dec. 14 2007,19:51
Sorry haven't been able to figure out how to paste the results of lsmod. It's on my other computer. Saved it as .rtf on floppy. Tried to paste with Dillo and Firefox but not successful.
History. Computer had C and D drives from Win days. Originally when using 3.4.7 I had it installed as Frugal on hdb (D) with swap, DSL and persistent partitions. hda or C was formatted ext2 with two partitions. No problem.
When I decided to try 4.1 I did a clean install but used HDA for Frugal same three partitions. Added hdb with two partitions for extra space that's when the modprobe xfs showed up.
Edit: To clarify "added hdb" =just formatting the drive. Physically it was always connected.
Now by physically disconnecting hdb the modprobe xfs errors does not appear.
Edit: My mistake. Just ran mkfs.ext2 on hdb1 and hdb2.
Now modprobe xfs error does not appear.
Must have forgotten to do this on second harddrive..
Posted by roberts on Dec. 14 2007,21:31Several things come to mind...
I will start with what I think is the most likely:
1. an unformatted partition even though it has been labeled as ext2 will be mis-identified.
2. partitons that do not match physical and logical boundaries can cause problems. Do an fdisk -l to check.
3. partitons not in numerical cyclinder order can often confuse idetification with what the bios sees versus what the software sees.
Check with fdisk -l and look at partition number versus cyclinder order.
When I am partitioning I check all of the above. I have a dev machine with multiple hard drives with multiple editions of DSL installed without issue.
Posted by JohnJS on Dec. 14 2007,23:12Thanks roberts.
Will keep that in mind. Still learning dsl/linux.
Posted by roberts on Dec. 15 2007,00:54meo wrote in the remastering section...
Found it. It occurs when the mydsl folder is found under /cdrom.
It will be fixed in 4.2 final.
Posted by roberts on Dec. 15 2007,02:27
I am improving the handling of the modules directory placed under the mydsl directory.
This should allow for seamless modprobe capability, rather than the previous insmods. This will allow easy access to additional modules and allow me to move rarely, or much less used, runtime modules into the mydsl extension system.
Doing, so frees more ram for better performance and more useful application extensions.
Posted by roberts on Dec. 15 2007,02:41
I added the code to prevent this situation as was/is in v3.4.x..
It is always better when trying to do installations not to use 'toram'.
Leave the ram availble for quicker copying.
Thanks for reporting.
Posted by b1ackmai1er on Dec. 16 2007,12:10@roberts
Someone has uploaded this RC (and others) to LinuxTracker for downloading using a torrent client.
LinuxTracker has assigned a seperate catagory for DSL.
Can you add this link to the download page?
< http://linuxtracker.org/browse.php?cat=104 >
I have been playing with xdelta and have also uploaded a diff file for 4.1-4.2RC1 to see if this had any worth to anyone (Saves 10Meg download)
Posted by roberts on Dec. 16 2007,13:45Thanks. Done.
< http://www.damnsmalllinux.org/download.html >