Forum: Site News
Topic: DSL v4.3
started by: roberts
Posted by roberts on April 22 2008,05:38Change Log for DSL v4.3
* Updated Firefox browser to v2.
* Updated murgaLua to v0.6.8.
* Updated nano-tiny to v2.0.7.
* Updated and consolidation of mydslBrowser with new mydslBrowser.lua.
* New picture puzzle added to Games collection.
* New calculator.lua replaces calcoo.
* Optomized minirt24.gz - much smaller.
* New background and theme for both JWM and Fluxbox.
* Updated 'noicons' boot option to suppress icons in JWM.
* Fixed removal of mydsl extensions on traditional hard drive installations.
* Dropped SCSI modules for needed space - available in the modules section.
* Fixed CD recording scanbus device error by adding scsi/sg.o module
* Updated editor.lua - menu issue resolved for new murgaLua version.
* Updated dmix.lua to support multiple sound card channels with 3-way toggle on sync button.
* Dropped mixer_common.lua - not needed with new dmix.lua program.
* Updated exit.lua - added support for environment variable BACKUP=0.
* Removed unsupported 'groups' command and moved to gnu-utils.
* Corrected permissions on fusermount so normal user can use sshfs.
* New mydslSqlSearch.lua, a personal tool that some may find of intrest.
* New icons for xpdf and files-exec.
* Fixed mydsl-wget from using /var/tmp s/b /tmp.
* Added perl sigtrap.pm
Thanks goes to many community members for ideas, suggestions, and contributions.
Files that have been updated that are likely in your backup.
Posted by meo on April 22 2008,08:35Hello Robert!
I've just finished a quite extensive remaster of the new DSL 4.3. The remaster includes: flex-bison-libtool, gnu-utils, gcc1-with-libs and I also compiled the GNU debugger into it from source-code etc. It seems to work well so thanks for all your hard work with this release!
As always have fun out there,
Posted by Juanito on April 22 2008,10:12
Posted by jaapz on April 22 2008,14:16cool release! will be trying it soon
hmm, first thing i see is that 60%/70% of the taskbar is dominated by buttons with text. plz remove that text! text is for the menu, not for simple quickstart buttons.
Posted by doobit on April 22 2008,14:30It's a beautiful thing!
Posted by lucky13 on April 22 2008,14:56
No, don't! Most icons don't render cleanly enough to be included on the tray.
Change it in your own settings. I think it's better as a system default to make things as clear as possible. With trays usually 24 pixels or smaller, the icons just aren't clear enough for most (and especially new) users to sort out. Users are free to reconfigure to suit their own tastes and thresholds for bloat.
If anything needs to be done to reduce the amount of space taken up by the buttons, just truncate the names: "browse" is shorter than firefox, "files" is shorter than emelfm, etc. I need to download and give it a spin.
Posted by jaapz on April 22 2008,17:02
i've already changed it in my own settings ;)
but you're indeed right about the fact that it should be as clear as possible, but then give the user a simple way to get those buttons outta there. this brings me back to making a add-button-to-jwm-tray-in-lua-thingy, i was thinking of that earlier. would be a great learning process
and what you say about that the xpm's aren't rendered well (or something), thats rubbish. roberts even made the taskbar bigger, its now 38 at default (i changed it to 24 myself), so you can see the icons well enough
i was thinking, maybe we could set popup texts as default in stead of labels on the buttons itself. (you know, that yellow thingy that always pops up when u stay to long above something with your mouse.)
then the buttons will be smaller, and they will be clear
Posted by lucky13 on April 22 2008,17:11There's already an easy way to add or remove tray buttons:
edit: It's not rubbish. The more jwm scales the icons, the worse they look.
Posted by florian on April 22 2008,18:54Hi!
Thanks for a new DSL release!
I'm having some problem with sshfs: this happens after I'm asked for password: "fusermount: mount failed. Operation not permitted.".
This happens with my normal usr and this doesn't work with root user either.
As for the discussion about the "quick launch" buttons: indeed, on my 800x600 screen, the buttons take up half of the jwm taskbar. Could someone tell me what jwm config file(s) i should edit to modify the aspect of those buttons?
Posted by lucky13 on April 22 2008,19:03
Posted by lucky13 on April 22 2008,19:50I'm running 4.3 now.
Aesthetics: This is *really* way dark and the wallpaper is a bit noisy for transparent terminals. I concede the buttons take up too much space. I've changed to a smaller font (edit theme's tray and tasklist sections to 10 from 12) and removed the icons (jaapz: the tray is 28) to get a little more space back.
My biggest complaints are related to firefox. The size difference between 2.0 and current 18.104.22.168 probably isn't too drastic, especially considering the severity of the interim security updates.
Screenshot of my tray changes and unflattering comments on the choice of routing Google searches through damnsmalllinux.org:
< http://lucky13linux.wordpress.com/2008/04/22/dsl-43-released/ >
Posted by jaapz on April 22 2008,20:55(im sure the default tray is 38, ill check tomorow)
I do like the black theme, and i think it does fit DSL in the way of h4x0rs, if u know what i mean.
And anyway, thats the costomizing left to the user, like u said before ;)
I think ur right about the search-engine thingy. The DSL search just sucks. I am quite sure that John wont see any of our searches at all (i tried this stuff too on my site) but i dont like this anyway.All those ads everywhere, it just sucks...
Posted by JohnJS on April 22 2008,21:10With 4.3 and the new Firefox do I need a new flashplayer plugin?.
Have been using Flash7 with previous releases.
Posted by lucky13 on April 22 2008,21:16
I'm positive it's not 38 because I did a clean frugal install (CD-less at that) and that was the first thing I checked once I had it set up. Unless there's a difference between the default .jwmrc-tray and the one in /etc/skel that I copied over.
As far as 'h4xors' go, poseurs and profilers and wannabes are the ones compelled to do things in certain ways for the sake of style rather than substance. Dark backgrounds and themes don't give you any bad-@$$ computing cred anymore than wearing dark clothes and having a funny haircut will make you a vamp or goth.
Shades of grey from black to white can work if done sensibly. I ended up changing the background to a pleasant gradient and my aterm foreground to a color I could see without my eyes frying. I think it should be the other way around: let the 'h4x0rs' set up vile, illegible dark themes on their own rather than by default. DSL should be use-able by default. It always has been. Profile as a 'h4x0r' on your own time. ;)
Robert: I saw some .old files in /etc. I didn't pay close attention and had to get back to work. I think one was for modules.conf?
Posted by lucky13 on April 22 2008,21:17
Continue using Flash 7.
Posted by roberts on April 22 2008,22:21
Thanks for the feedback.
Got wrong perms on /usr/local/bin/fusermount s/b rwsr-x--x root root
Posted by roberts on April 22 2008,22:24
The wallpaper has been in the RCs without comment or complaints.
The default tray height is 28, see /etc/skel/.jwmrc-tray.
Posted by roberts on April 22 2008,22:30Text was added to buttons to support the noicons boot option.
Tray and wallpaper choice is mostly personal and not everyone can be pleased.
They can easily be changed and will persist if in your backup.
I am always open to suggestions on eye candy.
Personally I use a solid color background because of my poor vision. For me eye candy = eye strain.
I even turn off syntax colors in vim. Too many colors blurs my vision.
Posted by roberts on April 22 2008,22:35
John would have to address your comments/concerns. I have no knowledge on how this is working. I do know that it is a long and tideous process to 'slim' down a firefox release. With so frequent releases of firefox it must be an never ending process. I am not familiar with XUL as used in FF and therefore cannot comment further. I will pass along these comments and concerns to John.
Posted by BobH on April 23 2008,01:33
The comments about the backgrounds, fonts, and icons have provided insight into the cleaning up both "the look" as well as freeing up a lot of memory. (Maybe I've been reading lucky13's blog too much!) Critical posts provide both food for thought as well as a lot of information.
roberts, thanks for the comments on syntax colors in vim. While my vision is still correctable (with glasses), I'm color blind and sometimes have a heck of a time with certain color combinations. Thanks to all for the new release.
Posted by lucky13 on April 23 2008,01:43
Interested in a high contrast theme?
Posted by meo on April 23 2008,05:29Hello guys!
I'm using fluxbox and I would really get rid of those small windows (4 in a row) that are found to the right of the taskbar (down in the right corner). I have done it by changing the .xinitrc but that affected the Mydsl entry in the menu. So the question is: can it be done in another way? Thankful for any hints.
Have fun with this new version of DSL,
Posted by andrewb on April 23 2008,05:41RobertS:
The version of DMIX in v4.3 is not the latest one I advised of during the RC process. There is an error in line 286 of the code that results in a problem when the left volume is set higher than the right. When set like this & 'lock' mode is used & the right slider is adjusted the right volume is not restricted when the left volume reaches 100 (& attempts are made to set the left volume to values >100). The revised code is in the file dmix-loc.tar.gz (file date 10/4/08) at users.tpg.com.au/cramond/zydas.
Having problems with Firefox (runing DSL under Innotek VirtualBox on WinXP). Clicking the icon, or starting from an aterm results in CPU usage rising & the falling back. no windows opened. The mozilla directory is created in home. Firefox has worked OK under these conditions before.
Posted by ^thehatsrule^ on April 23 2008,06:02
Having the new mydslbrowser.lua included is great - thanks mikshaw.
- the menus in jwm too dark IMO, but the rest were fine (I mainly use fluxbox anyways)
- the new buttons in jwm do look like they might take up too much space. Is it necessary to have these by default?
- afaik the preferred short form of Firefox is Fx
- I agree that Firefox could be an updated version, unless there is a reason... (pending response from John I suppose)
Posted by meo on April 23 2008,06:32Thanks a lot "hats"!
I've just rebooted after uncommenting fluxter and now finally I have a clean window, just like I want. Is there by any chance a way to make fluxbox the primary wm without using bootcodes? That would be a help. Thanks again!
Keep on having fun with DSL,
Posted by ^thehatsrule^ on April 23 2008,07:44
Or you could edit .desktop
Posted by meo on April 23 2008,10:16Hi again "hats"!
The desktop file already contained fluxbox and icons=0 so I just added it to the filetool.lst and saved it in my backup. So now it starts with fluxbox and without icons even if I havent used any bootcodes for that purpose. Thanks for leading me on the right track!
Have fun and enjoy this fine distro everybody,
Posted by lucky13 on April 23 2008,11:47
I would recommend "www" but that's already taken by dillo. Is it necessary to put both in the tray? How about just "term" for the terminal? "Files" for emelfm?
I think reducing the font to 10 for the tray and taskbar will also help a little.
Short of running a separate trayrc for noicons, I don't see how else to make this work for everyone. Maybe that's the solution, perhaps a jwmrc-tray-noicons without any buttons. Or remove them from the tray altogether by default and leave it to users to set them up and comment where they would go like xload.
Posted by Nigadoo on April 23 2008,16:09As always, great job.
I would think the tray works best for noobs. Let the experts (and the want-to-be's, with comments) customize to the hilt.
Posted by rspadim on April 24 2008,02:27
a very good tool in firefox 2.0 is fasterfox, could we put it in dsl as default?
< https://addons.mozilla.org/pt-BR/firefox/addon/1269 >
Posted by andrewb on April 24 2008,02:29
Checked the download & md5sum - all OK. Tried 4.3RC2 again under the same conditions - Firefox works OK. Still not working under 4.3.
Posted by lucky13 on April 24 2008,03:19
Such things really should be left to user choice.
Posted by andrewb on April 24 2008,05:43
OK, If I load gtk2-0705.unc & then try firefox-gtk2-1.0.4.uci - this version of firefox works! All I get with the default installation is about 5 instances of firefox-bin & one of firefox running (as shown by ps).
After doing this & closing the 1.0.4 version of Firefox - the default (2.0) version fires up OK?!?!?
Posted by andrewb on April 24 2008,06:35OK,
Solved the problem. I am behind a firewall/proxy server. If I run any other version of firefox (I tried the gtk2 v1.0.4 & nongtk v22.214.171.124 versions mounted as uci's) & set the proxy server the default version of firefox runs ok. If I remove the proxy server from the settings using one of these versions the default version hangs. The default version of firefox (2.0) obviously needs to access something during loading & is hanging during the initialization phase. This presumably means that you MUST have an active internet connection with no proxy server on it to be able to run this version of firefox as it is set up in DSL - surely not what John intended?
EDIT: After some more testing:
When the default Fx runs it opens a page at dslos.com/start. If the start page is then set to blank the next time it is run it displays a blank page. However.... if another version of Fx is run (e.g. 126.96.36.199) then the next time the default version is run it opens 2 tabs - one with dlsos.com./start & one being the blank page.
Now: Once the default version is running all is ok, unless another version is run, in which case it tries to open the dslos.com site & hangs if it can't get an answer (e.g. not active internet connection or proxy not set properly) & you can't get in to change the settings, unless you can remember how to edit the prefs.js file.
This customized version of Fx really sucks & needs removing. It is certainly not a good advert for DSL (sorry to be so harsh, but I like DSL & really don't like what John is trying to do here - push up website traffic).
EDIT2: The default version will eventually start - some-time after 2 minutes from clicking the icon (normal, unhindered startup of the default Fx on this system is <1 sec)
Posted by meo on April 24 2008,07:54Hello guys!
Is it possible to make the backgrounds scale to the right dimension when changing style, as they did in DSL v. 3.xx? If so I'm eager to know how to accomplish this. Please give me a hint!
Have fun with this new version of the best linux distro (in my opinion),
Posted by struppi on April 24 2008,11:03i love the new mydsl-browser! great job!
Posted by curaga on April 24 2008,14:10About that fasterfox extension: those tweaks are the same as in Swiftfox, and the patch from Swiftfox would be a better way to have them than adding an extension to load.
Posted by mikshaw on April 24 2008,14:38Extensions are external by design, just as mydsl extensions are. There is absolutely no reason to include Firefox extensions in DSL base when 1) they are easily added by the user who wants them, 2) many are updated frequently so you'll end up downloading them anyway, and 3) they are typically directed toward a specific user base. You should never assume that what one person considers useful is going to be useful to the general public. Personally most of the applications I find most useful seem to be disliked or ignored by the general population.
I have only 42% of 4.3 downloaded so far.....blasted middle-of-nowhere dialup grumble grmmbrr....
Posted by lucky13 on April 24 2008,15:26
This is especially true of extensions that prefetch things like fasterfox does. That can bog down slower computers; it also creates unnecessary traffic on slower servers by causing all their links to load whether or not visitors actually click on them. So it can slow everyone down -- users and servers.
Hey, come on. I wrote I'd give dwm a week on my laptop. It's now been longer and I'm using it on both desktop and laptop except for making the jwm contrast theme last night. I'm open to more of your suggestions and ideas.
Posted by curaga on April 24 2008,15:52I haven't tried fasterfox; but it seemed to include the same configuration tweaks also found in these forums as well as in Swiftfox, none of which enables prefetching, so they (the speed tweaks) should be OK in the base.
Posted by roberts on April 24 2008,18:24
Sorry of the confusion, likely because the name was changed to dmixloc? I have updated dmix with this change:
dsl@silent:~$ diff /usr/local/bin/dmix dmixloc
< elseif vr[n] < vl[n] and vr_d > vr[n] and (vl[n] + (vr[n] - vr[n])) > 100 then
> elseif vr[n] < vl[n] and vr_d > vr[n] and (vl[n] + (vr_d - vr[n])) > 100 then
Posted by mikshaw on April 25 2008,15:30Another note about Firefox extensions: They are not necessarily dependable, even ones that work fine in other versions of Firefox.
I just tried out Paste Quote in Bon Echo, which I've been using regularly in Firefox 2 on another distro. Bon Echo froze completely as soon as I copied some text. I'm assuming this may have some connection to Firefox being severely stripped down for DSL.
It might be useful to keep a thread about Firefox extensions that cause problems in DSL's Bon Echo.
Posted by kuky on April 25 2008,15:53ok with ver 4.3 but the exit box done partial problems in hd install it said to... install media etc with no checkbox done...
a aesthetic view.... the screen is Thorny i prefer another, how i send to robert months ago with a ray in the middle of the night in my village or crazy chickens in a car...all are available to dsl community...
beers to all
pdta some help is needed in cool things to create the first dsl virtual Brewery
Posted by roberts on April 25 2008,18:33Re: background
It is always easy to criticize the work of others; I know this very well, as I get alot of criticism of my code contributions.
If you don't like this background then post something in the ideas and suggestions.
High resolution digital images are too big. Keep in mind the size of the current background.
We can always use more ideas for backgrounds and themes. This sort of thing is not my area. I write code better than I do art and I have enough critics of my code that I stay away from even trying to do art.
Posted by roberts on April 25 2008,18:58
John is aware of the comments and concerns. I am holding this issue in abeyance pending John's action/decision.
Posted by mikshaw on April 25 2008,22:48
If you set your cookies to "Ask me every time", something gets broken. The dialog you get when a site asks to set a cookie is incomplete...it doesn't show the domain that wants to set the cookie. Worse than that, though, is the "deny" button doesn't work. All you can do is cancel the dialog, which accepts the cookie.
Posted by WDef on April 26 2008,20:05Sorry, OT very briefly
(back in your remaster post early in the thread).
I'd be grateful if you could please build and post an updated gdb extension.
The one I put in the repo is just an unpacked Woody deb and is as old as the hills.
Posted by kuky on April 26 2008,21:30
This post is to excuse to me if the previous post has been understood as negative critique, is only an aesthetic opinion, to which only want to add my help with screens if is possible. I have never criticized Robert's work and collaborators of dsl, i have learned linux in this forum and the web of dsl, and always I have wanted to give a tone of humor to the post and to reinforce the living together of the community dsl.
So well I differ in the opinion on that the technical work is not an art, I am an engineer of formation and my ideal one on the question is to be like Leonardo da Vinci who was designer of machines, do paints , works of sculpture and study the human body....
IN SHORT DSL IS MODERN ART
Posted by meo on April 27 2008,14:33Hi Wdef!
Well it's true that I did remaster in the gnu debugger into my remaster of the DSL v. 4.3. But if you look in the huge Remaster-Howto ... thats located in "Other help topics" you'll see that I never made any attempts to make an extension of it first. I have made several extensions (OpenOffice 2.4 in Swedish, English and Spanish; also Firefox-188.8.131.52 in Swedish and also Thunderbird-1.0.012 in my native tung) but none of them fulfill the requisites of being a fullfledged uci-extension since I haven't bothered with making an icon and menuentry (I just hack the fluxbox menu to execute theese programs). I am considering making it though but time and strength doesn't always suffice for all I want to do. I will also consider your request since to me it seems reasonable that if DSL can compile source code it should also be able to debug it. I just take a day at the time for now, so let's see what happens.
P.S. Sorry Robert if this is a little bit off topic D.S.
As always I hope you enjoy and have fun with DSL,
Posted by lucky13 on April 27 2008,16:11
I don't think gdb needs a menu entry. If you compiled it so it's in the appropriate directory structure (/usr/), just make a standard dsl or unc. You can do that directly from your remaster.
< http://www.damnsmalllinux.org/wiki...._source >
Posted by roberts on April 27 2008,16:48This thread has been hijacked.
Please use the proper thread for < Extension Development >
You can start a new topic in that area.
Posted by meo on April 27 2008,20:13Hello Robert!
I can tell you that I switched to DSL v. 4.3 as my production environment a few days ago. Unfortunately I had to change back to DSL v. 3.3 that according to me is the best version I have tested (and I have tested most all of them). That leads to the question: Why? For one thing v. 4.3 is much slower in certain aspects. Changing from jwm which is the default wm to fluxbox takes a while because it takes quite a while for the options window to appear. First you see only the top bar and after some time the whole window. This seems to be the case with other applications like the control panel under certain circumstances. But the thing that made me take this decision was that certain extensions doesn't work with DSL v. 4.3 but they work flawlessly with DSL v. 3.3. An exampel of such an extension is bittorrent-gui but I'm quite convinced that it's the same with some other extensions. I just doesn't neither have the time or want to make an extensive test in this matter. So even if DSL v. 4.3 seems very solid it is also about 4 times slower (give or take a little) if you have a lot of extensions in /mydsl/optional it seems. Besides that we have the problem with the windows appearing in a strange way. I just tried the extension mentioned before with DSL-embedded (adding the norestore option) in original shape (not remastered in any way) and the cpu didn't even react when I tried to start the loaded extension. So even if slowness doesn't matter too much to me I really want the extensions I'm accustomed to use to work. So therefore I switched back to DSL v. 3.3. Even if I don't use the most recent version of DSL I shurely can use the latest software extensions (even if I build them in my own manner). Well I think I'd let you know about these drawbacks with the new DSL version.
But thank you for your hard work and have fun with DSL,
P.S. I was going to shut down and it took like 7 seconds for the exit options window to complete D.S.
Posted by roberts on April 27 2008,21:58Mostly what you indicated would point to murgaLua,. i.e, the change wm options, the control panel, the exit options, etc. While it is true that murgaLua is growing in features, I have heard that John Murga will be doing more optimizations in the next, or near future, release that will address this issue.
Ultimately users will use what they want. But complaints about a slightly larger murgaLua only gives me pause when there is so much demand for a 2.6 kernel, gtk2, flash9 etc, etc, etc.
It is a shame that you will miss out on the many new features, already notable, is mikshaw's mydslBrowser.lua which deploys many of the new features in murgaLua. It is hot!
BTW, Some have said the version 0.5.3 is the best version. It is ultimately your choice. This is so very true when deploying on old hardware.
[EDIT] Also be aware, as I had mentioned in the Firefox poll, that Firefox v2 is HUGE! It's memory foot print will only add to the slowness and on top of that it is running from within a compressed image.
Posted by meo on April 27 2008,22:47Thanks Robert for a swift reply!
I didn't know what caused the things I described but I forgot to mention that DSL v. 4.3 uses about the double of the computers memory compared to DSL v. 3.3. And that is with the KNOPPIX-file remastered the same way. It also seems to handle memory worse (as in occupying the memory even with all the programs turned off) than DSL v. 3.3 that cleans the RAM pretty fast. This is no critic because I know that you are working hard with this excellent distribution. It is just an observation. I'll finalize with a question: Will fluxbox disappear with the DSL 5.xx series? I will be sorry if that is a fact but maybe it can be fixed somehow. Who knows???
Thanks for all you have done and continue having fun with DSL.
EDIT: If I remember right most voters wanted to remove Firefox completely. Am I wrong? Personally I use the latest version that I have built as an uci-extension and that one works very fine.
Posted by WDef on April 28 2008,17:41
Apologies, my fault Robert.
Posted by tikbalang on April 28 2008,18:15i just recently switched to v4.3 from v3.4.11,
1. what happened to the mount tool in the lower right hand corner?
2. how can i access the root of the cd that dsl booted from? i added some folder/files there using ultraiso.
Posted by ^thehatsrule^ on April 28 2008,19:121. read about the changes
2. regular livecd? see /cdrom
Posted by roberts on April 28 2008,23:45
Right Click on any desktop icon and you will find a mount menu.
Posted by roberts on April 28 2008,23:53meo posted:
I don't see this. I booted both DSL v3.4.11 and DSL v4.3.1 in Qemu 128M and closed Dillo and checked free command. It shows < 4.x > uses less (58284) memory than < 3.x > (65864)
Of course you were talking about remasters, so YMMV.
Posted by jls legalize on April 29 2008,10:21I like the fact that we have /etc/skel, but in this directory there aren't
so in order to upgrade I have to do a norestore boot.
legalize cannabis, coke...
Posted by mikshaw on April 29 2008,10:51/etc/skel is used by the system when a new user is created. Its contents are limited to what will go into the user's home directory.
I assume you've got a persistent opt directory if your files aren't being upgraded? You can find the /opt/* files in /KNOPPIX/opt
Posted by jls legalize on April 29 2008,16:50I don't have a persistent /opt but I have some /opt files in my .filetool.lst
Posted by jls legalize on April 29 2008,16:58after loading gnu-utils.unc it is possible to mount and umount the devices like hard disks, pendrive, etc. only as user root.
Posted by roberts on April 30 2008,15:36
That is really an extension issue not 4.3.
However, it is a good issue to bring up.
First I was using busybox mount command, therefore Knoppix/Debian mount was made available in gnu-utils.
Then around v3.4 and thanks to a suggestion from Wdef, I compiled a new mount command which allowed normal user to umount.
So, when gnu-utils was loaded you were retuning to the old mount command.
I have removed the mount/umount commands from gnu-utils.
Thanks for reporting.
Posted by jpjacobs on May 01 2008,09:05Hi,
sshfs still doesn't work.
Now the permissions are good (like in any other distro), but the group isn't set correctly, the DSL user should be in the group which owns the fusermount binary.
So in debian, fuse has its own group, fuse, and if a user wants to use it, he must be member of the fuse group.
So either add a fuse group, and add the DSL user to it, or add the DSL user to the staff group (which 'owns' fusermount).
Posted by roberts on May 01 2008,13:28Already reported. Extra group not needed. I posted the fix to permissions on fusermount earlier in this thread.
Posted by florian on May 01 2008,14:12
This is the workaround as indicated by Robert:
sudo chown root:root /usr/local/fusermount
sudo chmod u=rws,g=rx,o=x /usr/local/fusermount
works great after that!
Posted by jls legalize on May 01 2008,20:09I cannot download anything with firefox. I changed in the bon echo main preferences the download section to download the files to /home /dsl, and the I tryed "always ask me where to save the files", but nothing.
Posted by roberts on May 01 2008,20:58
No problems with download when booted with base norestore options.
Perhaps an old Firefox preferences issue?
Posted by MakodFilu on May 02 2008,15:26Two things:
a) Applying Fl:scheme("plastic") as in calculator.lua to everything written in MurgaLua takes away the major complaint against DSL
b) While I think the only function of "Run.." in Windows is to launch CMD and thus is redundant in DSL as the term button is there, I must report that flRun broke.
With no history file, trying to browse for a command results in a segmentation fault. I have traced the issue to input:value when associated to a Fl_Input_Browse widget. You can test it by launching flrun.lua from command line with --preload dillo and it will fail to show it in the input box.
I have yet to solve the issue if that is my fault. Otherwise, I should notify the bug as a murgaLua one.
Posted by mikshaw on May 02 2008,19:00
< http://damnsmalllinux.org/cgi-bin....t=19979 >
On the subject of flrun, you're attempting to set the value of a menu to a string, when it requires an integer. If you change input:value() to input:add(), it adds the command to the menu. Is that what you wanted?
Also, the browse callback tries to work with fl_file_chooser directly. This is reliable only if fl_file_chooser always returns a useable value, which is never a certain bet. It's generally a good idea to check whether or not the chooser returns something before doing anything with the result. For example:
Posted by roberts on May 02 2008,19:58
Daniel's script used to work. Not sure when it no longer. But many changes and enhancements to murgaLua over the last several releases.
Thanks for the suggestion of scheme "plastic" and thanks to mikshaw for the quick fix to this useful script and of course his suggestion of using LUA_INIT.
Posted by florian on May 02 2008,21:32
I personally find it frustrating that MurguaLua is getting bigger and slower with each release. Copas, XML, md5, ... do we need all of that in DSL? Also murgaLua binary is over 600K and yet has been packed with UPX. UPX combined with the DSL compressed image makes the DSL lua tools slower to start on older hardware.
MurgaLua seems like a real pain to compile because of all the 3rd-party libs and dependencies, but I might try to have a look at it during the weekend. I think we ought to try to build murgaLua for DSL instead of including the standard static build, because some libraries required by murgaLua are already present in DSL (zlib and libsqlite). With our own build, we may get a faster (and perhaps even smaller?) murgaLua even with all the features included. As an added bonus, a non-static build could make the fltk toolkit also available for C/C++ programs.
Posted by mikshaw on May 02 2008,23:51
Posted by florian on May 03 2008,01:26
Yes, perhaps. But as of this weekend, I'm not going to modify murgaLua. I'll just recompiling it into a non-static build and re-use the libs already present in DSL.
By the way, the latest available version on Murgalua site seems to be 0.6.4, but in DSL the latest version is 0.6.8. How can one get the latest version?
Posted by mikshaw on May 03 2008,02:25Check the murgaLua forum. The front page is not always kept updated.
Posted by florian on May 04 2008,22:21The murgaLua project really is about providing lua with plenty of libs in one static build. Actually it is actually pretty tough to make a "dynamic build" of murgaLua as I had planned. I'll continue working on this and will post results in a dedicated thread.
Posted by roberts on May 05 2008,16:21
Your efforts are appreciated.
With Firefox v2 and murgaLua v0.6.8 we are suffering from feature bloat, and mostly features that we do not need.
murgaLua in 3.x is 370072
murgaLua in 4.x is 636624
That is upx'ed figures. Actually murgaLua is about 2MB!
I suppose I can try to cut more to make room and run murgaLua uncompressed, or fall back to an earlier version.
Something has got to give.
murgaLua seems to be going in the direction of Lua All In One project. They just use a different GUI widget set.
I would prefer to use standard Lua and use "require" for those elements that are needed for that particular script, sockets, xlm, fltk, etc.
I had wanted to use Lua as a general scripting language. But that would mean to double up with an all-in-one murgaLua + standard Lua just to achive that.
Posted by mikshaw on May 05 2008,18:33John Murga had said a few days ago that he was thinking of rebuilding murgaLua specifically for DSL, because "the one DSL currently has is about 200k bigger than it needs to be".
Posted by roberts on May 06 2008,18:23I have un-upx'ed murgaLua in KNOPPIX image for testing and it may be equally or worse than before. Seems when upx version is used, the first invocation is slow, but after that not too bad. When using the un-upx'ed in KNOPPIX, seems every invocation is slow. 2MB is far from 500k.
Seems like with 4.3 I am waiting on two Johns.
Posted by florian on May 07 2008,00:40I compiled fltk toolkit as shared libs (~500Kb), a plain-vanilla lua interpreter (~100Kb), and I also compiled the fltk binding from murgaLua as its own separate extension to lua (argh! it's 700+ Kb)
Running a C app with those fltk shared libs worked well. But when it comes to lua, the interpreter doesn't let me load modules with the loadlib function for some reason (maybe i didn't compile lua with right options), so I can't check yet if the fltk bindings works well or not.
Well, it's bed time here. If I have time I'll continue tomorrow.
Posted by florian on May 10 2008,02:10I have finally managed to invoke the bindings from some scripts in a standard lua interpeter. I have tried three scripts from DSL: calculator.lua, editor.lua, and stats.lua. The editor script is having problems; I don't know why. So it still needs to be checked if most other DSL scripts are able to run this way or not.
I have posted a tarball here:
< http://florian.cauvin.free.fr/tmp/lua_fltk.tar.gz >
This archive contains the standard lua interpreter and the needed shared libs for fltk and for the separated murgaLua bindings to fltk.
- header files and tools useful for compilation of C/C++ programs using lua or fltk
- examples of compiled fltk program and of lua scripts using the libraries. (make sure to set up a correct LD_LIBRARY_PATH)
Everything is compiled with compile-3.3.5.uci under DSL.
Posted by roberts on May 10 2008,04:02WOW! What an improvement in runtime. Now even simple (non-gui) lua scripts run fast. And the GUI Fltk scripts are much faster as well. And the added bonus is to have the Fltk library for C++ programmers.
Note: libhistory was not used in murgaLua and is therefore not in core DSL. I had to mydsl-load compile-3.3.5.uci to get the missing library. After that it was smooth sailing. libhistory provides command history within the Lua interpreter.
I have tested several scripts with no problems so far.
Posted by curaga on May 10 2008,10:25Which version of fltk is there?
Posted by roberts on May 10 2008,12:43The only issues I have found are:
1. Fltk menu as already noted. Only concerns two programs, editor.lua and iconView.lua. For the second a work-around is possible. If we have to for go editor.lua for now, then that is OK.
2. Some Lua scripts are using lfs. Personally I don't use lfs, as I have written isDir, readDir, and getDirs using standard Lua and popen (see functions5.lua). So, I am sure that lfs could be dropped and the standard functions be used.
3. We do use Lua sockets. There is no work-around for sockets. So we need to have a lua sockets be able to be "require"d or loadlib'ed.
Posted by florian on May 10 2008,12:48
This is version 1.1.9, which the latest "stable" release of fltk.
As per my understanding, 1.1.9 might be the end of the 1.1.x line. Current development is 1.3.x and 2.x.
1.3 is adding unicode, printing, and a few new widget. And 2.x is refactoring the API (ie, no backward compatibility) to support C++ namespace, themable ui skins, and other stuff.
Posted by florian on May 10 2008,13:50
Good catch. I haven't noticed the dependence as I had the compile extension loaded all along. Tonight, I'll check if it's possible to compile the lua interpreter without libhistory.
I don't know why fltk menus aren't working as I have only compiled the murga's bindings, not made any change to code. Maybe some C++ name mangling or other obscure linkage issues are causing this? I'll give a try at recompiling the bindings with different settings, but I'm not sure it'll work better.
Ok, I will also give a shot at compiling the LuaSockets extension
(either from murgaLua distro or directly from there: < http://www.tecgraf.puc-rio.br/~diego/professional/luasocket/). >
Posted by mikshaw on May 10 2008,19:51
On the subject of 4.3 as it is, I seem to be having an issue with Bon Echo, which is a bit more serious than that cookie thing I mentioned earlier. Every time I use it for a while, even if it just stays open doing nothing, eventually my entire system becomes flakey. Bon Echo RAM use goes up steadily until it is no longer responsive around about 40mb. At this point any applications that are opened fail to respond. X will close, but the linux console will not echo anything. I can force a login prompt, but it is not useable. Ctrl+Alt+Delete begins to shut down, but hangs. Alt+SysRq+b will successfully reboot. This happens every time I have Bon Echo open for more than a brief session, and hasn't happened since I stopped using it.
My system has 512mb ram, so i'm not running low there.
Posted by roberts on May 10 2008,21:55[quote=mikshaw,May 10 2008,16:51]
Interesting. Mine has been up for 34 hours and counting with 4 tabs always open. 512MB noswap running from a frugal pendrive. What else might be in the mix, plugins, flash, etc?
Posted by mikshaw on May 11 2008,01:50no flash...I'm currently morally opposed to it =o) No other multimedia plugins either.
But maybe there's an issue with extensions. I had been using NoScript and Save Text Area in DSL 3.2 without trouble. When using Bon Echo, Save Text Area became a firefox killer, so I disabled it. Perhaps there is an issue with NoScript as well.
Posted by mikshaw on May 11 2008,03:23Sorry. It's apparently not Firefox after all. Although I hadn't had any trouble in the last few days since switching to Opera, I just got hit a few minutes ago. The only other new application I've been using recently is wget 1.11.2 (I had no troubles from a couple weeks of using 1.11.1 every day), so maybe you should not post that one for now. Other than that, I can only guess it might be hardware failure, although I'd assume that would completely freeze the system rather than just mess up all my applications.
Posted by curaga on May 11 2008,09:23Perhaps it's corrupted ram; try running memtest86+ through.
Posted by kuky on May 11 2008,10:10solved to close and exit with repetitive window " in mount media."...there was a traitor pendrive with an old backup and dsl sda-instaled that change the options to close...(i supoused)....if you can solved to newbes or advice in windows to close can be apreciated...
an observation is that the notepad lua (in editors portfolio)runs ok to type accents, diaresis in spanish keyboard, with es keyboard selected in control panel, and no tricks with xmodmap, if these feature can be done to others writters apps can be useful to internationalize dsl with no xfree and anothers tricks that bloat dsl..
Posted by mikshaw on May 11 2008,11:15
I get an actual error message if I happen to be in linux console at the time: "Unable to handle kernel paging request at virtual address 0008000", so maybe it is a memory problem.
EDIT: I let memtest86+ run for a couple of hours (6 passes), and no error, so maybe it's not ram. Temperatures seem to be staying around 30C, so that shouldn't be an issue either.
I'm back to using DSL 4.2 for a while. If I continue to have problems I'll know it's something hardware related.
EDIT2: Same trouble with 4.2, so I know it's not DSL. Sorry to trouble you.
Posted by florian on May 12 2008,01:49
This helps, Thanks! The callbacks to register the menu bindings are done in a lua file within murgaLua. By including those callbacks, I am now able to run editor.lua and iconView.lua without any problems. I will post a revision of the tarball within the next few days.
And speaking of editor.lua ... in the fltk-1.1.9 distro there is nice tiny editor made with fltk. I got it compiled in less than 15Kb. Similar than editor.lua but more polished and more useful for programmers (use a fixed-font and does C/C++ syntax highlighting). I'm including it in the examples.
Posted by roberts on May 13 2008,04:25florian wrote:
I went ahead and compiled sockets and have it working using the latest luasocket v2.0.2 and working with your standard lua binary. Tested with sample tests and gettime.lua.
Looking forward to your update on the murga bindings so that menus will work. Then it is time to adopt this into core and thereby regain much needed speed.
Posted by florian on May 13 2008,20:20Hi! I have just updated the tarball
Here are the main changes:
* Further optimized the binaries (incl. libraries) for smaller size. Recompiled C++ code with '-no-exceptions -no-rtti' in addition to -Os flag for some extra reduction in binary size. All C code is -Os. All executables are stripped and also sstripped (sstrip utility is included in compile/bin). All shared libraries are stripped with 'strip --strip-unneeded'.
* Extracted the previously-missing bindings for FTLK menus and events from MurgaLua 0.6.8 (see new file share/lua/5.1/fltk.lua). With this setup, I have also hidden the akward loadlib'ing, so that you can just use a require("fltk") from your scripts. This is a more "standard" way to load the extension.
* Added Lua Socket 2.0.2 extension. < http://www.tecgraf.puc-rio.br/~diego....ce.html > (Robert, I have just seen that you have also compiled this extension too. But since I have stripped those, maybe this version is smaller)
* Compiled Lua-Sqlite3 (http://luaforge.net/projects/luasqlite/) and the extension is fairly small once optimized (27k). This is in a separate dir, because very unfortunately the extension fails to load as some functions that are not found from the libsqlite3.so shipped with DSL (most probably because sqlite in DSL is too old). What do you think: Will/do we need database access in Lua? Should sqlite be upgraded?
* Updated examples of apps and scripts. Maybe some of those are worthy of inclusion in DSL?
* Recompiled lua without libhistory.so. The linkage worked ok without the library, but I actually wonder why the Lua makefile attempts to link to it. Hopefully libhistory really isn't required.
Posted by florian on May 13 2008,20:56Just a little Lua tip I've just found: the -l flag allows to specify require'd lua modules directly from the command line. So in order to verify that the DSL scripts are still working well with the new lua system, we can do something like this:
$ lua -lsocket /usr/local/bin/gettime.lua
$ lua -lfltk /usr/local/bin/iconView.lua
Also, -l could be used also inside the first line of a script. So a script can start like this:
instead of explicitely using a require("fltk") statement
Posted by roberts on May 14 2008,16:37Thanks for this. It is very much needed. I am going to incorporate it into the next version of DSL v4.4. To recap some of the benefits this provides:
1. Stand a lone Lua scripting runs much faster as only the Lua interpreter is loaded.
2. Using Lua for web scripting also benefits as above.
3. Lua Fltk runs much faster as many other libraries in the current static build are not loaded.
4. We gain a separate fltk library for C/C++ programmers.
5. Any other Lua libraries can be used in a typical way, i.e, load (require) only when needed,
Posted by roberts on May 15 2008,19:40Thanks to florian, with our new open lua fltk, I was easily able to add the latest lua filesystem library (v0.3). I found two lua scripts that rely heavily on lfs.
lfs is very small and provides some nice features, so I have included it in DSL. I now an alpha cut of DSL v4.4 and the overall speed improvement is very noticeable. All lua and lua fltk scripts are running fine. Expect a release candidate within a few days...
Posted by roberts on May 15 2008,19:46The latest sqlite is huge in comparision to our current version. I don't think I can accomodate the latest sqlite into core. There has been much discussion on the merits of moving to the latest sqlite. Currently DSL only has one script that interfaces to sqlite and it is not a required script. It was something I was doing and using for my personal needs. Possibly a library can be built to support our current version of sqlite. Or perhaps someone can shed light on a compelling reason to require the latest sqlite.
Posted by meo on May 15 2008,21:07Hi Robert!
That sounds very promising. I can hardly wait. Thanks for all your good work!
As always have fun,
EDIT: I was referring to your post before this last one
Posted by MakodFilu on May 15 2008,23:35
Maybe. Gonna test. I remember when first using fl_input_browse widget I didn't know of any examples of its use (or even edible ones in C), so I didn't know how to deal with it: as fl_input_box or as fl_browse. It seemed to work as fl_input_box, so I went that way. Wrong on my part for not checking changelogs.
I remember checking it to see if an intermediate variable was needed. I saw fl_input indulged happily being assigned a nil value so I dispensed the caution in the script. It worked, but you are again right that it is against best coding practices.
Extra-nice Gonna play with that.
Posted by roberts on May 16 2008,02:40The LUA_INIT is used by all Lua scripts. With the new open lua fltk, not all Lua scripts are GUI, nor would you want such scripts to have to require the fltk widget set. Therefore LUA_INIT would not be such a good choice. One can still have themeable lua fltk by using, say, a dofile pointing to your .murgaLuarc.
Then only those lua scripts that need GUI, having the require('fltk") could also have a dofile("/home/dsl/.murgaLuarc"). Then editing the .murgaLuarc would cause all such lua fltk gui scripts to have the specified theme, fonts, etc.
Posted by mikshaw on May 16 2008,13:30I wonder if it might be easier to do a check for fltk in the LUA_INIT file before running any fltk commands. This assumes that -lfltk is being used as part of the interpreter as mentioned earlier, and that -lfltk loads fltk before LUA_INIT is read, neither of which I know at this point. In any case, if it works, I think either method could be used. I only mention sticking with LUA_INIT because it would allow you to skip running dofile in every fltk-enabled script.
On the previous subject of my hardware issue, I'm still not certain what the problem is, but it's looking like it might be CPU failure (swapping the ram out didn't help). My cousin just gave me his "old" mobo, which includes twice the ram i had before, and a comparable processor (1.6ghz Athlon compared to my previous 1.8ghz Pentium4). So after a few days without computing, I guess I can continue now =o)
The fans are really loud, though.
Posted by lucky13 on May 16 2008,14:31
Swap them out with your old ones if they're quieter and in decent shape.
Posted by roberts on May 16 2008,16:09mikshaw wrote:
I have found the best place for such dofile, in a single location, is /usr/local/share/lua/5.1/fltk.lua, the inititalization for the murgaLua fltk bindings. This way the non-gui lua scripts are not penalized with any extra processing to determine to further process fltk only commands.
Posted by florian on May 16 2008,16:49
I was going to suggest the same. In fact you could perhaps add the following line just after the invokation of the murgaLua shared lib (the package.loadlib call):
This would then automatically execute a ".luafltrc" lua file from the user's directory if such file exists.
Posted by florian on May 16 2008,17:00Yes this works. I have all my scripts running with the plastic theme by putting Fl:scheme("plastic") in ~/.luafltkrc
Posted by roberts on May 16 2008,17:49I agree, pcall is better than just a dofile. Will implement.
BTW slight typo missing close ) after "HOME")
Posted by meo on May 16 2008,20:26Hi Robert!
Just a quick note following a hunch I got. I checked out k3b.dsl in mydsl repository and found that a change ocurred late last year on everything but the info file. So I guessed it was just conformed to the standards of DSL 4.x. I made an .unc extension (since I'm low on ram) and it works flawlessly in DSL 4.3 with even when gtk+-2.12.9 is set up. Just think I'd let you know. I can see that you are busy with more important things right now. Thanks for your good work!
As always have fun with DSL,
Posted by lucky13 on May 18 2008,19:40I have a question about the new "open lua fltk" and how separate this is from murgalua. Does it function under murga's muddled licensing or is it completely separate and therefore will function under the sum of (less restrictive and much clearer) licenses of its parts?
Edit: by less restrictive:
lua = MIT license
lua socket and lua filesystem = same (?)
fltk = LGPL (which isn't as restrictive as GPL)
zlib = free (Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the productd ocumentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.)
sqlite = public domain
By clearer, see the murgalua "compiler license" which is hardly a license and apparently wasn't written by a lawyer. While DSL users may or may not care about using these tools for commercial purposes, Murga forbids what the sum of his parts allow: "To fit into the filosofy behind murgaLua you may not encrypt, obfuscate or otherwise further restrict the accessibility of code compiled within applications produced by the murgaLua compiler."
He's certainly entitled to his "filosofy" (sic) but so are the authors of the other projects he's built his upon and they don't force users to behave according to certain precepts and conditions like Murga does. Freedom is a two way street, else it's not really freedom.
Posted by roberts on May 18 2008,21:43As each part is now separate, each is under their original license.
Why I call this open lua fltk, is because, one can download the individual parts and use them as most lua libraries are intended.
Many of the parts recently added to murgaLua binary are not used or needed in DSL. zlib for example. I am really only interested in the lua to fltk bindings. John Murga has done this and florian has compiled the fltk bindings into murgalua-0.6.8.so. together with some glue code in /usr/local/share/lua/5.1.fltk.lua.
Other lua supported libraries provide their own bindings, and hence their own license. For example, independently, I was able to compile and use the latest lua-socket and lau-filesystem without regard to the fltk bindings. Which, is what it should be, IMHO. Why would I need to be burdened with the fltk widget set, if my intended use is for a command line only filesystem and/or socket interface lua script?
Many of the other libraries and hence, bindings embedded in the murgaLua binary are not in the version in DSL. I also have no intention to use or include the murgaLua compiler. It is only the fltk that I have an interest in. That has been the case since I started with Jay Carlson's lua fltk bindings.
Because it is open the developer can choose to "require" only those parts necessary to the task at hand.
Posted by mikshaw on May 19 2008,08:48
All that said, I've never had any interest in compiling scripts anyway =op
I'm still torn about this open version, but i'll have to reserve judgement until after trying it. My main concern is how existing murgaLua scripts work (or don't work) with it...whether they all require some level of modification. Switching from Lua-FLTK to murgaLua was ultimately a very good idea, but the transition was a bit of a pain.
Essentially I prefer the concept of a smaller faster runtime, with the option of adding modules since that feature is already part of Lua. On the other hand, a modular interpreter can theoretically become a bigger pain than a monolith when it comes to dependencies for the end user, as is demonstrated by Perl.
Posted by florian on May 19 2008,13:13
Well, in fact it's not anymore a problem for proprietary software to use interpreted language! This is because modern interpreters first compile source into bytecode (which is then run on a virtual machine) and therefore also happily accept some pre-compiled bytecode as input instead of a plain readable script.
Of course, the "valid" reason to use bytecode over source is to make script invocation faster. For example, if a Lua script is to be invoked repeatedly from a shell script's loop, you might want to compile it before the loop, store the bytecode in a tmp directory, and only use the bytecode form from within the loop.
A Lua byte code compiler (luac) is included in the official Lua distribution or one can use the bare bones tiny version below:
Posted by W6LQR on May 30 2008,05:14Will the "dot.pup" applications work with all versions of DSL, if not are there seperate web sites for additions to each ?
Posted by curaga on May 30 2008,10:29Umm.. Those are Puppy extensions, they won't work on DSL.
Posted by W6LQR on May 30 2008,12:09Yes, I have been working with both distrobutions and meant to ask -
Will myDSL Applications, at "My DSL Repository" work with all versions of DSL ?
Posted by curaga on May 30 2008,12:28Yes, unless the info file says otherwise.
Posted by roberts on May 31 2008,20:21W6LQR, please post general use questions in the proper topic area. Your posts are not Site News.
Posted by roberts on June 19 2008,02:48Re-opening this topic.
Posted by meo on June 21 2008,18:18Hi Robert!
I was just about to post some questions in the "4.4.1" topic when I realized that it was locked. My concern is about the further development of DSL. Will there be a "new" DSL 4.4.1 according to the changed circumstances? I liked the "old" one a lot but now it seems that it has gone to the history. Are any decisions taken about the tiny core yet? Well that kind of sums up what I would like to know. I'm very sorry for the turn things have taken lately but I hope everything will turn out good in the end.
Hopefully you can have fun keeping up your appreciated work in spite of what has happened,
Posted by roberts on June 21 2008,20:32DSL v4.4.2 will implement "the murga agreement" as well as replace whiptial with dialog-1.1-20080316 and a new dialog theme.
Tiny Core's GUI environment will continue to have the standard ftlk libraries available as well as the dialog mentioned above.
Tiny core will be delayed due to the conversion effort now underway.
Posted by meo on June 21 2008,20:39Hi again Robert!
Thank you for a quick response! It's nice to see that DSL is moving forward even if it has taken a bit of a turn.
Have fun and be assured that your efforts are most appreciated,