I tried to make another Slax update, following the progress of KDE, Xorg and other software, but I got some issues again with KDE's task bar not being drawn properly. I have to admit that this drives me crazy :) So I guess it will be better to wait for another KDE update.
There is one project which Slax depends on, it's AUFS. AUFS is created and maintained by Junjiro Okajima, a friend of mine from Japan. Thanks to Junjiro's AUFS, Slax can support read-only modules with read-write 'changes' in RAM or on USB drive. The entire Slax future depends on Mr. Okajima's survival. So from time to time I donate some spare money to AUFS to contribute something back.
Today I sent my next donation, and I would like to kindly ask you to do the same. Please donate some spare money to AUFS, be it $5 or $500, every amount counts.
If you wish to make a donation, send money by PayPal to: sfjro@users.sourceforge.net
Thank you!
Edit: I've updated this blog post to provide working PayPal which can receive money.
One Slax user, with nickname dajiangtang, notified me regarding a problem of chrome module. It had root directory permissions set to 0744 instead of 0755. When such module was added to Slax root filesystem, it changed Slax's root directory permissions so unpriviledged (non-root) user couldn't login. That was actually just part of the problem, I got several other notices that after chrome module was activated, some other strange things started to happen.
I've fixed that and chrome module is rebuilt. If you had any troubles with Slax after using chrome module in the past, please upgrade to the new module now. Thank you for understanding.
I've deleted 181 broken modules which were autogenerated from Slackware's packages but didn't work on Slax due to some missing dependency or any other reason. There were already some users waiting for that action in order to be able to upload own build scripts for some of the software, so now it is your chance :) Thank you, and I'm sorry it took me so long.
Some of you will hate me for this :) I've just released yet another Slax version. This one should fix the plasma task bar finally. If not, then I'll give up :) Anyway, if you do not like to download new Slax each two days, feel free to use 7.0.6 or 7.0.7 and just resize the taskbar manually to full screen width if you need.
What is the problem with the plasma bar anyway? The root of the issue is in the way how the settings are stored for it. If a height is to be specified, which I need for slax, then a width must be specified as well. If a width is specified which is smaller than user's desktop size, it sometimes adapts the task bar to full width, but sometimes it doesn't. However I found out that if really big width is set, which is bigger than the screen, it adapts to actual screen width properly. So I set there 8000 pixels, in the hope that all Slax users will have smaller screen :)
If you just downloaded 7.0.6 and noticed that new Slax 7.0.7 is released, you may download a tiny diff bundle. It is a 4KB big module for Slax which will add all newly changed files to your Slax. Download it and put it in /slax/modules/. The diffbundle is located here:
http://www.slax.org/upload/99-diff-706-707.sb
I didn't even test it, but it should work. It adds all the plasma-related config files so the panel no longer makes any problems. However I think you will need to remove changes.dat file in your Slax since most likely your existing Slax already overwrote the plasma*rc files and the diffbundle wouldn't have any effect (your changes would overide it). Alternatively you may unsquash the bundle to /slax/rootcopy.
For me, a 200MB download doesn't make any problem, so I would rather just download new fixed version in full. Now lets see if the fix really fixes the taskbar for all users. It is pretty tricky.
Maybe we will have 7.0.8 very soon :)
In order to fix the strange issues with task bar, I've pushed out a new version of Slax, numbered 7.0.7. Furthermore I've been able to identify strange problem which happened to Slax Turkish version - it never worked at all. The reason for that was somehow unclear to me till now.
Each release of Slax (for all languages) is about 50GB. But I do not upload all the 50GB of data to Slax server, instead I upload just two ISOs (32bit and 64bit) with English language and all the other languages as separate modules (it's like 800MB or so in total only). Then I run a script at the server to generate all the ISOs with all the supported translations. And that script was using LANG variable to store currently processed language. I didn't realize that LANG actually is a variable which has some special meaning for some programs, including mkisofs, which was simply not able to generate correct ISO image when LANG=Turkish was set. Anyway, this has now been fixed (LANG renamed to MYLANG in my script) and Turkish people can enjoy Slax on CD too! :)
I got several notices about the taskbar in new Slax. For some users it is really broken. I can reproduce the problem only when I resize screen to a bigger resolution, but for some people it happens even on clean Slax startup.
Will have to digg into it somehow deeply, this should really never happen.
I've removed twitter sign in to Slax website and I've added email sign in. How it works? If you wish to sign in, choose "Sign in with Email" from the available options. You'll be asked for your name and email, fill that in and click Submit.
You will receive a link in email which will sign you in automatically. Next time you will need to visit that link to sign in again, it serves as a password for you. Alternatively, you may request new sign-in link each time you wish to login, it doesn't matter.
I'd like to announce the next update of Slax Live Linux version 7.0.6. The main change is new Linux kernel 3.8.2 and updated KDE to 4.10.1. It was a bit harder than I expected, mostly due to some really odd changes made by KDE developers, which I had to work around to get the same functionality like we are used to.
Raw changelog:
- Upgraded Linux Kernel to version 3.8.2
- Upgraded KDE to version 4.10.1
- Fixed missing notification when module is activated or deactivated
- Upgraded all packages to reflect changes in Slackware-current
- Updated FireFox to 19.0.2
- Show date on taskbar under current time
- The device notifier in KDE is now hidden since it was showing on mad positions.
Slax size has been increased by about 3MB due to new stuff provided by KDE software compilation, I'm going to reduce that somehow in the next release. There are some svg icons and some other files which are not necessary at all.
New version of Slax is almost done. While testing the new kernel 3.8 I noticed it has some "improved" support for DRM, that is Direct Rendering Management, do not confuse with Digital Rights management :)
The thing is, it blocks console output on some devices, making it effectively impossible to start Slax on console only (without X). To fix this, one has to use vga=normal instead of vga=773 boot parameter which is used to start 1024x768 framebuffer on Slax on boot. I got several notices from users with 1024x600 screens that they see an error when starting Slax since it tries to setup a bigger framebuffer than their screen supports, so I finally decided to use vga=normal as a default parameter for Slax.
Google has recently released a new open-source compression algorithm called Zopfli (thanks Thiago Silvino for the notice). From the four page paper which is authored by Google, Zopfli has better compression ratio than gzip, 7-zip, and kzip, while the compression time is slower - it gets increased by about 10000% (!!). Actually we do not care about compression time at all since that is done just once, when Slax is made. So, could this new algorithm be used in Slax with any benefit?
To answer that question we need to understand what data are we comparing. Slax is using LZMA2 (XZ) compression, which was introduced by 7-zip. LZMA2 is by far the best compression available nowadays. Yet Zopfli claims to provide better compression than 7-zip. It could really seem it is better. But there is a catch. The catch is, Zopfli compression generates data backward compatible with DEFLATE algorithm. When the benchmarks were made, they all compressed some test data to a format which is backward compatible with DEFLATE too. Even when 7-zip application was used, it didn't compress by LZMA2, it did compress by DEFLATE (that is the format you are using in ZIP archives).
So, the answer is no. We can't use Zopfli in Slax, since the compression is insufficient for our needs. But I am sure Zopfli will find its way to the web, where static html pages may be compressed using the improved algorithm, while being still uncompressible with all the existing DEFLATE decompressors used in web browsers.
I've been somehow busy with other stuff lately, but we had to wait for AUFS for Linux Kernel 3.8 anyway. It's now available, and KDE has released bugfix version 4.10.1, so there is everything we need for the next Slax update release. It should be finished this week, or at the beginning of the next week.
I think that getting flu may be good for something. For example you have to lie in bed all the time, since you do not have enough strength for anything else. And while lying, you can only cough and think. That is what I did. And besides all my pessimistic thoughts that I can't possibly survive this flu since it brings inexpressible pain and is so hugely devastating for my body, I had one more idea, more useful one. Ha Ha. :)
It all starts with the skype module. Microsoft, the current owner of skype, refuses to release 64bit version for Linux. I'm not sure if that is due to Microsoft programmers being so stupid, or rather thanks to some undisclosed secret internal policies, but it's how it is. Since Slax 64bit is a real 64bit system, it can run neither 32bit skype nor any other 32bit application. I think it is a pity. So I googled a bit and noticed that it is possible to include both 32bit and 64bit libraries in one system and make both 32bit and 64bit applications usable in 64bit Slax. The method is called multiarch and is widely used by many 64bit Linux distributions.
I prefer to ship the 64bit version of Slax just like it is, as a purely 64bit system. I have no plans for including multiarch in Slax at all. But I understand it may be useful for some users, so I made a module for it. You may try it for yourself, just slax activate multiarch-libs. It will essentially download a 20MB module file which will let you run Skype and many other 32bit applicaions in 64bit Slax. The module itself consists of preselected 32bit libraries, so if you find a software which doesn't work with multiarch-libs (complains about some other missing libraries), just feel free to use ldd to find out what libs are missing and mail me so I will include them in this module too.
Some time ago I wrote that my wife and kids got flu, while I was miraculously immune. Well I guess my time has come, and I just noticed that I am infested infected too! :) Terrible experience, I must say.
By the way, kernel 3.8 has been released just yesterday, so as soon as I can, and as soon as aufs is available for this kernel, I will compile it and release new Slax version with KDE 4.10 :)
Last week I've added a download counter for all modules, so each time a module is activated or downloaded, its counter gets incremented. This way we will be able to see module popularity in the future. The counter required some rewrite_rules on apache, and just today I noticed that one of the rules was somehow broken. Nothing really serious, but as a result, the build server was unable to read build scripts in queue, and no buildscripts were processed. It's now fixed (16 builds scripts still in queue). It was my mistake, I'm sorry for that.
I wasn't quite happy with the search button at modules page, so I rewrote it to be somehow better. You can now choose from a dropdown menu which category are you willing to search through, furthermore you can also choose to search in all modules.
I've compiled KDE 4.10 for Slax. It has somehow different look (using Air style instead of Oxygen), and it has some noticable problems such as strange Device notifier placement. I guess I am going to wait for 4.10.1 which will hopefully address the issues I encountered, or I may try to workaround them myself if there is some time. Last two weeks were really problematic for me, my wife and two kids got flu at the same time, and it's almost impossible to do anything under that circumstances. I wonder how is that possible that I didn't get infected as well till now :) Most likely it was thanks to the drugs (vitamins) I consume :) Anyway, they are all fine now so I'm looking forward to fully resume my work on Monday.
I noticed several comments regarding the 'feature' that Slax deletes the .sb module file on deactivation. Currently it works this way, since module is automatically downloaded (created) on slax activate, so it's also deleted (destroyed) on slax deactivate. The situation is a bit different if you deactivate the module by giving full path to the .sb file as a parameter, in that case the file is kept.
Some users may activate modules which they downloaded beforehand and they do not like the module file to be deleted on deactivation. At the same time they do not like to use full path to the module file as a parameter. So I'd like to ask you here for your opinion regarding this.
I think that at some point Slax should delete the module file on deactivation, especially if it was activated online (downloaded automatically to /slax/modules/). The reason for that is if the module is not deleted, then it will get activated the next time you boot. I think it is correct to delete it in this case.
Do you think that the correct behavior should be different? Should Slax somehow remember what modules were downloaded automatically and delete only those, while keeping the others? Or do you think that sufficient solution could be to delete only module files if they reside in /slax/modules/ on the USB disk, or in /mnt/live/memory/modules/ in memory, but preserve them if .sb files are in any other locations?
I've hired a person to check and fix buildscripts in Slax module repository. His name is Michal and he will be responsible for correct module categories, proper descriptions, and for screenshots. Furthermore he will check if the modules are working fine and will eventually provide advice to the module maintainer in order to make his module better (eg. by correcting menu entries, and so on).
Michal has full rights to modify all build scripts submitted to Slax website, but he will mostly just fix the categories and descriptions at the beginning. If your buildscripts are properly written then there will be no changes made to them at all. In all cases, if you're going to update any buildscript which you previously uploaded, then I'd like to kindly ask you to re-download it and make your changes to it afterwards, to make sure you're editing the newest version. Use slax buildscript download [name] to download your buildscript.
There was some confusion recently regarding how does the post-install feature work in Slax modules. So here is a short desscription. If you activate a module, it does this:
1) mount the module
2) add to aufs union to merge with current root filesystem
3) execute ./run/activate.sh from the module
If your module A requires other module B, it works this way:
1) mount module A
2) mount module B
3) add module B to aufs union
4) run ./run/activate.sh from module B
5) add module A to aufs union
6) run ./run/activate.sh from module A
So in general, the activation script is called for every module after it gets merged with the aufs unioned root. And in general, every module is added to aufs union only after all dependencies are firstly activated. It's recursive.
Hello everybody, a new version of Slax has been released yesterday. Slax 7.0.5 updates KDE to version 4.9.5 and FireFox 18.0.1, furthermore it provides new feature which lets you upload screenshot of any application to Slax website in order to assign it to a module of your choice.
Sorry I didn't publish the release announcement sooner, I wanted to get Software Center prepared so I can show you some screenshot. Here you go :)

If you wish to get your module listed in Top Picks, feel free to send me a nice 128x128px icon and I will add it there.
Vmware users will notice better mouse support thanks to updated UDEV rules, so the mouse will grab and ungrab automatically for you, no need to do that manually anymore.
The acitvate / deactivate functionality has been improved, you can now activate a module by single click (through the software center) and all dependencies will download automatically.
As Slax users upload more and more build scripts to create Slax modules, it is needed to also have a good and easy method of taking screenshots of the applications. So I've prepared a simple wrapper for this task. Since Slax 7.0.5 you will be able to select Share Image option in ksnapshot's Send To menu, which uploads the screenshot to Slax server. You will be also asked which module you wish to assign the screenshot to. It will be also (of course) necessary to moderate the uploaded screenshots in order to protect teenage children from seeing inappropriate content uploaded by other teenage children :) (a mature human being will keep the porn for himself, she will not share it with others!) :)

So you will be able to just hit PrntScrn on your keyboard to launch the ksnapshot application, click the button Take a new snapshot to make a screenshot of just the application window you click on in the next step, and then you select Send To -> Share Image. The screenshot will be uploaded as soon as you enter a name for the module you wish to assign the screenshot to. Some autodetection will be in place to offer reasonable default value, so for example if you started supertux and then you're attempting to upload a screenshot, it will offer 'supertux' as a default value for the name, so it should be simply enough in most cases to just confirm the default value by clicking OK. The screenshots uploaded this way will appear at the module detail page, as can be seen here, here or here.
I'm going to publish few words from time to time about interesting modules made for Slax. For today, I've selected two games, two office packages and some firmwares.
Abiword is a word processing program similar to Microsoft Word.
abiword module page
A GNOME spreadsheet app, similar to Microsoft Excel.
gnumeric module page
SuperTux is a classic 2D jump'n run sidescroller game. In a style similar to the original Super Mario games, featuring 9 enemies and 26 playable levels, supertux game ensures long lasting fun.
supertux module page
Crack Attack is roughly based on the Super Nintendo game Tetris Attack. Slowly, your stack of colored blocks grows from the bottom, and you've got to make sure it never reaches the top. If it does, you lose. To eliminate blocks from the stack, line up at least three of one color, horizontally or vertically. Once you do, those blocks disappear, and put off slightly your inevitable demise.
crack-attack module page
And finally, firmware drivers, you probably know them, those are important if you wish to use some hardware which doesn't have the driver included in Slax natively. Kernel firmware is somehow big and bloated, contains lots of fw drivers from many sources. B43 firmware is a special tiny package with only broadcom wifi firmware drivers. module page for kernel-firmware and module page for b43 broadcom wifi firmware
You can now sign in to Slax website using Yahoo! or Twitter account.
I was trying to implement twitter sign in using OAuth (since this very same method should work on some other social networks too, such as yahoo). I've followed the instructions given at the official documentation and was getting 401 Unauthorized response all the time, I couldn't even get the oauth_token. Yet finally I found it. As a part of the OAuth request, there is a timestamp transferred. It must not be in the past. It can be years in the future, but not in the past. The OAuth protocol is Crap.
So we should see twitter and yahoo and maybe some others sign in options hopefully soon.
Why am I spending so much time on this? Actually the reason is that I am planing to make some of the features of this website for signed users only. Thus I need as many supported sign in providers as possible, to make life easier for everybody.
I noticed that many other Linux distributions can detect if they are running in vmware virtual box and automatically configure X to grab / ungrab the mouse cursor. You probably know what I am talking about if you ever tried Slax in vmware, you had to press Ctrl+Alt to release mouse cursor from the guest, and you had to click inside the vmware window to grab the cursor in the virtual machine again. That may be annoying. I thought that vmware tools are needed for automatic grab/ungrab to work, but today I learned it can work out of the box without vmware tools at all.
Xorg has vmmouse driver for long time. It even provides /usr/bin/vmmouse_detect binary, which is a tiny program which detects if the moduse is to be handled by the vmmouse driver. Yet the package xf86-input-vmmouse contains only HAL rules to autodetect vmware mouse, and since HAL is no longer included in Slackware since version 14, X falls back to evdev driver or something like that. The following can be seen in Xorg.log.0:
Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled
So how to make Xorg use the vmmouse driver? The following udev rule makes the trick, and will be included in Slax:
ACTION=="add|change", ENV{ID_INPUT_MOUSE}=="?*", ATTRS{description}=="i8042 AUX port", KERNEL=="event[0-9]*", PROGRAM="/usr/bin/vmmouse_detect", ENV{ID_INPUT.tags}="vmmouse"This is in debian for very long time, but didn't make its way to the official xorg input driver nor to Slackware. I'm going to submit this upstream as well since this tiny change makes a big difference for vmware users.
New version of Slax pocket operating system has been released. Improvements and fixes include:
I've extended the documentation for best practices by the followint paragraphs. Feel free to share your opinion about them. Thanks!
If you're writing build scripts to produce Slax modules, always bear in mind that there will be other users using your module. Here are some of the best practices you should follow in order to make your modules smaller, easier to install, and more useful for Slax users:
Use minimum runtime dependencies. If the software you're compiling requires other libraries, which are not absolutely essential for the software to run properly, always check if there are some compile-time options to compile it without the given dependency. If the compilation requires perl or python or other module but the software itself runs without it, make sure to distinguish compile-time dependencies and do not include those in regular dependency list.
Write good descriptions. The better description you write for your module, the easier it will be for the user to find your module (by fulltext search) and to understand what is it useful for.
That is all what I can think of for now. I will add this to the documentation section and I will be happy for your suggestions what you feel is a good practice for building modules (writing build scripts). Thank you.