It looks like BitCoin is getting huge popularity nowadays. This virtual currency is now traded at around $970 per 1 BTC. I'm experimenting with bitcoins myself too. Do you have some spare bitcoins? Are you willing to donate a fraction of BTC? If so, I will be very grateful so I could experiment more :)
My address is: 12AvcKxo6KfHYH3njGkxKnUMhApeQU9uRo (click to see the transactions log, if any)
Thank you very much! :)
No I'm just kidding, Slax will be based on Slackware forever :) However, I'm now just working on interesting project which aims to build a Live OS by using Debian and Linux Live Kit (the software which I wrote to produce Slax out of Slackware). This will help improve Linux Live Kit to be more compatible with debian-based distros, and the best part is that I'm going to be paid for that work :)
I tried to make new Slax version a week ago (using Slackware as a base, of course), but found (again) some problems which I wasn't happy to fix myself (those are mostly related to KDE task bar, which makes crazy things if pre-configured and started on different screen sizes).
I am more and more thinking about GETTING RID OF THE FUCKING KDE ENVIRONMENT since I don't like it any longer! (Sorry for the rude language, you know me, I say everything straight.) KDE is at the moment the best desktop I know about, but some other ones are (in my opinion) starting to be very close to KDE (like Gnome3 or Cinnamon) so switching to something else might be an option for the future. Or maybe wait for KDE5, who knows :)
Lots of people reported that network manager doesn't work on Slax 7.0.9 beta and thus makes them some problems connecting to internet. It has been also noticed that installing dhcp package fixed the issue.
I can see that the same problem has been addressed in Slackware current today. From Slackware's changelog:
n/NetworkManager-0.9.8.2-x86_64-2.txz: Rebuilt. Switched back to dhcpcd instead of dhclient as the default DHCP client in the NetworkManager.conf file. Either one will work, but it's probably better to use dhcpcd by default to avoid a nasty surprise for people who didn't install the dhcp package since they aren't running a DHCP server.
I'm happy that the fix made its way into official Slackware, which means easier maintenance for me :)
I tried to boot Slax on a MAC computer from USB stick long time ago and I wasn't successful, it seemed that MAC computers don't boot from USB at all. Few weeks ago the makeuseof website published an article about making a Linux distro bootable from USB on MAC. The article is here:
I'm not able to test this myself, since I don't have MAC (and definitely will not buy one in near future), so I would appreciate if there is anybody who has MAC computer and is willing to give it a go and try to boot Slax from USB on MAC, with or without the help of the utility mentioned in the article. I'd be mostly interested in how to make an USB drive with Slax which could be universal to boot on both MAC and regular PCs, that could be beneficial for all Slax users. I'll be happy for you suggestions! :) Thank you.
Hello everybody. After few months of silence, the Beta release of Slax 7.0.9 is now available for testing. It features Linux Kernel 3.9.7, KDE 4.10.4 and FireFox 22.0. It is a bit bigger than usual, since FireFox started to require icu4c for some strange reason, which is 7MB packed (!) ... I have to find out if this dependency can be dropped.
In the mean time, please feel free to test this beta release and let me know if you recognize anything unusual. Your feedback will help make Slax better. Thank you very much for using Slax! :)
Slackware has recently upgraded to Linux kernel 3.9.5 and KDE 4.10.4 I'm currently busy by some other interesting work so just writing a short message here that you do not expect to get a new Slax release this week :) In all cases, I should have lots of time at the end of June, so all Slax components should be updated during that time. As usual, thank you for your patience :)
I've moved the build server for Slax modules to a different hosting. Due to that, all updates to Slax modules were put on hold for some time. Now it is running again.
How does it work? In general, I needed entire Slax running on the server. Furthermore I needed 32bit and 64bit versions at the same time. Thus the ideal solution was to purchase just one machine, and run virtualbox in it, which holds both 32bit and 64bit Slax versions running together. All modules are built in both virtuals on a freshly rebooted Slax, and once each module is built, the OS reboots to ensure that the currently finished (compiled) module won't affect the next one.
So, there are few modules still in the queue. Will be built soon. If your module is yet still missing within a day, feel free to contact me. Thank you.
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: email@example.com
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:
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.
- 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.