After getting over 1250 responses to the Questionnaire published month ago, I should be able to make some conclusions. I'll describe them here.
1. Slax language translations
More than 65% of users prefer to use Slax in English only. Some users reported they voted for non-english support only because of their need to use non-US keyboard layout, which seems reasonable. So as a conclusion, taking into consideration the fact that creating and distributing 40 language mutations is a headache, I've decided that if there is a new Slax release, it will support non-US keyboard layouts, but will not provide localized translations - those should be available only as modules.
2. Slax base - keeping Slackware?
Almost 84% of all respondents do not care if Slax is based on Slackware. This means that I can do practically anything when selecting the base for Slax. To be honest I didn't decide yet if I want to switch. The problem with Slackware is that there is no way to get extra software easily. I am considering Debian and Gentoo at the moment.
3. Slax size
Only 5% of users prefer Slax to keep <200MB size. And 63% of users can accept size over 500MB. So I think targetting to ~500MB or ~700MB (to fit a regular CD) may be the best decision. I think 700MB is not such a deal nowadays. If I can put more data on file, it will mean less work for me optimizing the size.
4. Graphical desktop
Only 4% of Slax users prefer console-only OS, so graphical desktop will remain included. Only 10% of users would appreciate Gnome3. The rest of users is divided almost equally to three groups, one requesting very lightweight desktop like OpenBox, another one liking KDE, and third one appreciating desktop like XFCE. This basically mean that whatever I do, I'll piss of most users :) and it also means I can do whatever I like :) I did not decide yet. So I think that I'll select something lightweight which looks like KDE :)
5. Slax Architecture
Keeping Slax in several architectures is lots of work. I suggested a solution in one of the previous blog posts, I was thinking about the possibility to include both 32bit and 64bit kernels (appropriate kernel would load automatically) while providing only 32bit userspace binaries. This looks to me like the easiest way to make Slax working on all x86 architectures without any drawbacks. So for now I like this idea.
6. Applications in Slax and Download Format
Those questions were mostly informative for me, so I could see what's most important for users.
Modules are core of Slax. Only 17% of users do not care about modules, other users need them, either to create their own stuff or to (at least) download stuff built by others. I think the number would decrease if Slax was built on, say, Debian, since people could apt-get instead of downloading modules from the repository. In all cases, I see I have to keep the modularity.
There appears to be a very interesting possibility, which I never considered before. It is actually possible to detect - during the boot time - if you are booting the OS on a 64bit system or not, and thanks to this, the boot loader can automatically choose the right Linux Kernel image - 32bit one on a 32bit computer, and 64bit one on a 64bit computer. Furthermore, as I tested already, a pure 32bit operating system (binaries and libraries) can run without any problem on a 64bit computer while even the running kernel is 64bit (!) too. (The 64bit kernel is necessary when you want to access more than 4GB of total RAM).
To sum it up, it is actually possible to package a 32bit operating system, with two kernels (one 32bit and one 64bit) and then boot this OS in a way that it will automatically select appropriate kernel for the given machine it runs on, while all the userland processes (programs) will be 32bit (thus smaller, and loading faster, when running from CD or a flash drive).
Smaller and faster. That sounds great. What are disadvantages?
Disadvantage of having a 32bit-only system is that any process can not allocate more than a few gigabytes of RAM (if I understand this properly). For a Live OS such as Slax, we don't really need to allocate more than that for any particular process. If you do then you'll probably use some other OS anyway.
Another disadvantage may be that when the software (programs) is compiled for 32bit processors, it will not use some newer (and probably more optimal) instructions, which were added only to the newer 64bit processors and are not available for, say, i486 instruction set, thus there can be some performance penalty. I assume this will not be any significant problem for a Live OS such as Slax again, since if user really needs to gain the extra few percentages of performance, he or she will probably be using some other OS anyway.
Having only one Slax version (32bit OS, with extra 64bit kernel included, which adds only around 20MB to the total OS size), would save me around 40% of the development time needed to package and distribute two variants 32+64, so I'm definitely open to try this out. It also simplifies decision for users, who do not need to care about the architecture, and they can safely use single Slax on all their machines.
Let me know please your thoughts on this. Thank you
Build server machine (where slax modules are compiled) is down since I'm reducing costs. From now on, I will be running the module builds only locally in virtual machine, occasionally, manually, few times per week. If you feel you do not like to wait, or if I forget to run it for many days, drop me a message when you want me to run it at any particular moment. Thanks for your patience :)
Update 9th May: Guys from vpsFree.cz offered a free server for Slax, and it works very well. So from now on, all buildscripts will be compiled automatically as usual. Thanks guys! :]
Hello everybody. It was long time ago when I posted something here. I am considering to get my hands back on Slax again, but before I do so, I would like to hear your feedback. I would like to kindly ask you to fill the questionnaire which I have prepared. It should load right under this text. If it does not, you can click here. When finished, you will be able to see summary of responses. Thank you for your time!
Some time ago I wrote a post about Quantum OS, an operating system designed to follow Material Design guidelines. It has been renamed for the second time now and it's name is now Papyros.
If this works, I'm going to release new Slax with this desktop instead of KDE. This is very exciting. There is no ETA of course, it can take many months, but I think it's worth to wait.
Michael Spencer has decided to build his own operating system, called Quantum OS. What's going to be special about it? Michael decided to base the desktop design of Quantum OS on Material Design, which was introduced by Google in Android 5.0 Lollipop.
The distribution itself will be based on Arch or Ubuntu (my personal guess is Arch, but as far as I know it has not been decided yet), and the desktop framework is aiming to be built on top of the QtCompositor API, which provides a Qt framework for building a Wayland compositor.
What is the best on Michael's effort is that he's going to make Quantum Desktop in a way that it works on every Linux distribution which supports Wayland. I think that this is very good idea and I'm very excited to try to integrate it into Slax instead of KDE.
I was just recently interviewed for Czech Republic's most famous linux website root.cz. Here is a shortened (and slightly modified) version translated into English. The text is free to use at your website, if you feel the need.
The live distribution called Slax is developed by Tomas Matejicek since the year 2002. The developmend has stopped few years ago, however an article at root.cz initiated a new discussions and lead to successful restart thanks to two sponsoring companies. Now, one year later, it looks like the development is stuck again. We've asked Tomas for the current status, and plans for the future.
Just one year ago, the development of Slax has been restarted, but now it looks like it's stuck again. What happened?
I have to admit that the development is now slowed down. The reason for that is simple - the software used in Slax (mostly the KDE desktop) doesn't show any significant progress towards better usage. I'd say the opposite is rather true - with every new bugfix release of KDE, I'm finding it more and more difficult to integrate it into Slax properly. As an example, the device notifier appears on strange places during KDE startup, the task bar is not properly resized to full screen width sometimes, and so on. Furthermore I am concerned about the startup time of KDE, which is significantly faster in Slax than anywhere else, but still too slow in my opinion.
In general, KDE desktop or KDE SC (software compilation) is no longer looking like a good candidate for fast, simple and elegant desktop. It's the best time to choose something else, smaller, faster and nicer. Unfortunately I'm not a desktop programmer, I'm just putting existing things together to make Slax, things which were made by other programmers, so I'm reliant to waiting and trying, until something suitable is found. Fortunately Slax investors are not forcing me to make any hasty decisions.
How are you fulfilling the financial plan? Does Slax make any income?
The investors got already more than a half of their investment in return, so I think it's safe to assume that their investment will be fully repaid in a long term, which was the primary goal. I'd like to introduce the paid-wallpaper business model I was talking about few times, but before this is done, I prefer to rebuild Slax once more again and replace KDE by something else. Slax uses Slackware as a base, which is a great advantage on one hand (the system is clean), but may be a night mare on the other hand, since there's nothing like package pool in debian, so if you need to make any software for Slackware/Slax, you usually have to compile it from scratch by hand, while you also have to find all the dependencies, which usually depend on other dependencies, which is sometimes even recursive. Yet I'm sticking with Slackware and I have no plans to switch to any other distro. I think it makes my life a bit harder, but I'm gaining a feeling of uniqueness, since there are not much Slackware-based distributions out there. At least not as much as of those *buntu clones.
What could replace KDE in Slax?
That's a good question, but I don't have any answer for that yet. There are lots of Desktop environments, but many of those "innovative" or "progressive" ones are somehow tied to the distribution they're running on. I thought for a short time that a good replacement for KDE could be Cinnamon (Gnome's fork from Linux Mint). It was available only for Mint, but just got separated recently, however I think I don't like it any longer.
Another possible candidate for KDE replacement is Pantheon desktop, which is officially released only for Elementary OS (Ubuntu's fork). If I could make Pantheon work on Slackware with minimum of dependencies, it could be it. First attempt of integration to Slax has failed though. Today it's probably the best option to wait for Ubuntu's LTS version release, which is scheduled to April 2014, since new Elementary OS version should be released after it. The new Pantheon could have most of the components enhanced for easier integration in other Linux distributions.
What's your ideal desktop environment?
Ideal desktop environment starts within few seconds (I mean TWO) and gives the user a simple way to run programs and switch between them. That's it, it's nothing special at all. The old well known start menu can be replaced by a bubble with icons (as like slingshot in Elementary OS), taskbar doesn't necessarily have to show all the long window names (plank, used in Elementary OS, is mac-ish but otherwise very elegant), system tray at the top black line as we know it from Gnome or Ubuntu looks like a good idea as well.
In general, the technologies used in Elementary OS look inspiring. I'm convinced that the end user doesn't need anything else at all. I'm not any big fan of Activities in KDE, similarly I don't understand why whould anybody need gadgets or similar things in the base Slax.
It is essential that all the desktop components are well designed. And here, by Design, I mean the design how things work, what appears where and how, and such (for example the feature that two running terminal windows can be recognized by two dots under the terminal icon), yet it has of course have a nice design (in the meaning of "nice look" - those two dots in our example have to be "nice" somehow). Desktop effects like cube desktop or wobbly windows are awesome, but as we could see, they are not widely used anywhere, because the added value is not so significant. Sometimes less means more.
Why don't you use Xfce, Enlightenment or OpenBox?
OpenBox is mostly just a window manager, not a desktop. XFce was nice few years ago, when the last version has been released, but it's too outdated for today. (Well the whole KDE4 look a bit outdated already). Gnome 3 brought a new way of managing multiple desktops and applications, I was really excited by that, but there were some other problems, such us ugly icon of current application in top black bar, really big window decorations, or the entirely reworked app switching through the Activities menu.
Anyway, regardless of which desktop could be choosen for Slax, it will mean putting it there instead of KDE, which will also mean getting rid of most of the other KDE SC applicastions which are used in Slax today. At least of those parts from KDE SC - software compilation. Those would have to be replaced too, by some simpler and smaller equivalents using GTK.
I think it will need some time, but I believe that sooner or later something usable for Slax could be found. When that happens, it will be the best to release that as Slax version 8. Any similarity with Windows versions is purely coincidental :)
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: 1cJNsBVMy9rFYEBaTh3iK1PEo3f1xkJQn (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.