> Ok Guys, should we start a new topic and try drawing
> in the devs so we can start working on a SliTaz 5 RC?
But if producing a RC and eventually a SliTaz 5 release later this year is the plan, then the priorities should be on fixing/stabilizing what is there and not on fancy new stuff like Lua/Nimrod/Vala rewrites of tried & tested applications and scripts that work perfectly. Things are complicated enough as they are. Without identifying and focussing (!) on issues that need fixing or improving the plan to produce SliTaz 5 might fail.
So, what’s needed? From my amateur(ish) perspective there are a few points …
I was shocked to see what’s been going on regarding the SOURCE variable in the receipts. One guy removes the variable without much asking, another guy reverses the removal without much explaining … really, guys, you should communicate before doing things that affect the work of others! In a project like this, asking questions, giving answers, discussing and explaining things are as important as hacking code.
I don’t know why the boot procedure is in such a messy and convoluted state. I guess it’s a “Baustelle” and someone’s working on it? I hope that eventually it will be a single screen with options to select the system language, the keyboard layout, and a field for entering kernel parameters (as it was in SliTaz 4). The boot screen should also be completely removed from ISOs that have been created with TazLito or TazUSB.
Xorg / Hardware
With my old-fashioned Nvidia 7300 SE graphics card all the recent Rolling releases booted straight into the desktop using the proper resolution. Great! One tiny fly in the soup is this …
… something I have never encountered in previous SliTaz releases, whether I was using the proprietary Nvidia driver or Nouveau. I’m not even sure the fragments of selected desktop areas have anything to do with Xorg. Maybe it’s Openbox?
To me the biggest issue in the SliTaz Rolling releases is SpaceFM, which has multiple severe problems and is in its current state of development not very comfortable to use …
- no “Open in Terminal”
- setting internal drives to “visible” is constantly forgotten or reset to “invisible”
- some global preferences can only be set by right-clicking on folders in the side-pane
- internal drives can only be mounted as “root” which, strangely, makes the whole drive inaccessible for ordinary users
- selecting files and folders doesn’t automatically de-select previous files and folders, which is irritating and dangerous
One serious issue I came across some days ago was this: in a Live session I selected and copied a file in SpaceFM, then went to a mounted internal drive, selected a folder and pasted the file into that folder. There was no error message, but the file didn’t arrive in the target folder. I repeated the procedure and was then asked if I wanted to overwrite the file. When I accepted the overwrite the file was still not to be found in that folder. But on both occasions I could clearly hear the write access on my 20 year old Seagate drive. So, I looked around and eventually found the file one hierarchy level up in another folder. What a horror!
I think that SpaceFM isn’t quite ‘there’, yet. For the time being it is probably best to stick with PCManFM, which also has its flaws but still works a lot better than SpaceFM. Just make sure not to use the dumbed-down and crippled version 1.1.0 currently in Cooking, which hasn’t even got a tree view in the side-pane. The original 0.5.x or PCManFMmod, the de-bugged version the Ignorant Guru made a while back, would be ideal until SpaceFM works reliably.
Quality Of Packages
Obviously, I cannot say anything about the vast majority of packages in Cooking. But there are some odd things I’ve come across: There seem to be bits missing in Midori 0.5.0 and moc (music on console) has an unnecessarily long rat-tail of dependencies including perl (!) …
moc deps Slitaz 3
moc deps Slitaz 5