SliTaz Forum
You are not logged in.
Hi,
I have been held a HP Omnibook 6000 with a PIII Coppermine, 796 Mhz, with 192 MB Ram (not upgradable). The GPU is a ATI Rage 3.
The machine had already a Slitaz, as of 2011. I could not get a tty : it was triggering a kernel panic, with messages related to the GPU driver : mach64.
I rebooted and I tried to update the repos, it didn't work, even changing the main repos. I tried to update, it broke, therefore I installed the Slitaz 4.0 after I reformatted the root partition. Then I thought it would be all ok, but it was not.
First thing, it messed badly with the video, and therefore I tried to reboot to live Slitaz, which was working, chroot, change driver. No go. It was still not working. I had consulted the wiki, used the tips and tricks provided, still hoping to get it to work, it worked perhaps during one session and the next not anymore. Before and after that, I had tried to boot to init 1, or init 3, when I realized (reading the wiki, seeking for information) that the init levels have been removed ! Wao, what a progress !
I therefore removed slim from the daemons, in order to get to a prompt after boot, instead of getting a black screen, but for unknown reason then tazkpkg would not work anymore. I ended breaking the system by trying to switch to cooking (from within the live and chroot), and sparing you the details (I also tried to restore slim as daemon but after that the boot was still finishing on a tty prompt, which I wanted only for a temporary solution), after several days of this struggle, I decided to give up, and try antiX which was about to release the version M12. antiX has done all well, has normal runlevels, working well, a hardware detection which didn't fail, and everything, except little details easy to fix, works normally.
Just before installing antiX, I had a doubt : was the problem coming from the machine, or from the distro ? I had used Slitaz before, and as long as I would not update the cooking after install, it would work. But after I installed antiX, I realized that the machine could perfectly work, session after session, without presenting strange inconsistencies (ie : a slight change in the lxpanel made me loose the menu button, which I had to reinstall and never got the same as the original one, and in the live could not find where the config files where located, so that I could not restore it as it was before, even from a live in chroot). Again, I will spare the multiple weird issues I met with during about 3 days.
I could have gone to my blog, or any place where people report about their experience with a distro, but I preferred to come here because I have known Slitaz since a few years now, and with the brilliant start it has had, I am expecting it to become better, not to regress the way it has.
I hope the next versions will provide normal init runlevels so that if something goes wrong it can be fixed in a classic manner, and I hope all will also be more consistent. What use is it to sell spider usb sticks if the distro inside is not reliable ?
Regards,
Mélodie
PS I had an account back in 2008, but it has been erased since...
Offline
You probably won't read this, but here goes:
Currently there are about 7 people working on SliTaz in an official manner - have a look at http://hg.slitaz.org/ if you don't believe me. Normally the main developers are pankso, erjo and bellard and sometimes godane. Bug fixes and new packages are also added by mojo, dev and Aleksej.
Since SliTaz is made from scratch (as in based on NO prior Linux Distribution), that's means there is only a handful of people for 3500+ packages, the Linux Kernel and X.org Drivers. We pretty much have to learn and relearn how to do each of these as they come up. It's a daunting task. When a problem comes up, it's generally only one person that works on it. SliTaz has also only been in existence about 4 years.
What does this have to do with anything you ask? Well, take AntiX for example. It's based on Debian who has over 10 000+ developers world wide, with SEVERAL people working on problems as they arise. Debian is easily one of the oldest Linux distributions, having been around for 19 years. Thus the AntiX people didn't have to lift a finger to get most things to work right - which Debian kindly provided for them.
Now ask yourself: Is what you have to say against SliTaz fair?
No, it's not. You are comparing something so young with few developers to something that was piggybacked off an 19 year old mature Linux with 10 000+ developers.
We also aim to be simple and not specialized. This is also our failing, considering technical people tend to flock to a micro-linux that does try to be like this. TinyCore for example, gets this right very well.
Even our support sucks. On IRC it's normally just me answering questions and here on the forum it's normally just me, Aleksej, mojo and the developers that answer any questions. Everybody else is just to interested in their own issues to help others with theirs.
I even had plans to make my own easy, out of the box, fork of SliTaz, but it's posts like this that just make me depressed and not want to try. We're fighting to save this Distro and then people like you come comparing us to something we just don't have the man power or experience to beat.
But use what works for you. Just don't call it's SliTaz's failure that we can't compare because we're young.
Offline
Hi Trixar_za,
You are right on one point : I am not fair. You are wrong if you consider all what I wrote as unproductive. Let me tell you why and how in few simple points :
I could or should have reported each issue I met with with details, but the problem is that it would have been a huge task, and it would have needed to be performed while working on a machine which is not even mine, and which I will have to hand back in a few days. So the above reports what can be reported with fresh memory about the process.
Another point I would like you to consider is that I didn't just do a fast test and give up : I tried in an uninterrupted way (I mean several hours per day and evenings) to get it to work properly (in a way which the machine can be used daily without the user suffering with "1001 issues"). Above is a really short summary. And I repeat again I am not coming elsewhere to rant at Slitaz, but here where people can read and with a little chance, maybe change it for the better.
The main sentence which I would like you to notice (then you can forget the rest of my post) is this one: "I hope the next versions will provide normal init runlevels so that if something goes wrong it can be fixed in a classic manner, and I hope all will also be more consistent."
You have helped me as well as you could on the chan, and I thank you a lot for this. I am happy that you are the one who answered to me here. I wish you don't stay with a bad feeling towards me or towards my report.
If you fork Slitaz, I will be very please to test your alpha/beta and rc candidates for you, and to promote it to other willing testers.
When a new future version of Slitaz will be out again I will again test it as well carefully.
(Please take not that I didn't use the word "failure", but the expression "no go", which is different and talked about what failed it the process, so I didn't append a word such as "failure" to Slitaz).
Offline
with only 192 MB i would try slitaz V2
V3 was a no go on a laptop with "only" 256 MB (V2 runs happily on it)
With V3, the video was a nightmare on my C400 which is KNOWN for being problematic from a video point of view, but getting the video conf from an ubuntu which installed it properly solved it instantly (with almost no hassle)
Offline
Ubuntu is still a Debian fork. Hell, even Ubuntu has been around for 10 years. Just Saying 
Yes, melodie, what we need is bug reports. However we need people that can co-ordinate and solve problems more. To me trying to find solutions and providing your work and solutions if found is more useful than vague compliants. I'm sorry if I'm sounding hurtful, but I truely feel that SliTaz needs more people that help than those that jump ship at the first trouble. It's a community that makes a Linux better, not the developers alone.
Offline
I was meaning that i booted from ubuntu then copied the xorg conf from ubuntu to slitaz to make it work within seconds, -- after a few hours unsucessfully spent on the web trying to understand how to do a manual customisation of my own. Which was close to hopeless, since the video driver to use was a different one and the few hints i had found where deprecated.
Offline
Lol, now you know how we feel. Xorg is a horrible beast to automated 
Offline
Trixar_za, I gave my point of view about runlevels, in my two posts. When Slitaz will integrate them again, I will consider contributing at least a few days with bug reports, and then promoting Slitaz again. I have promoted Slitaz many times, and even if you don't know it, even if I didn't come here to say about it, it is a form of contribution. Having removed the runlevels is imho a very serious mistake.
http://tldp.org/LDP/sag/html/run-levels-intro.html
"A run level is a state of init and the whole system that defines what system services are operating. (...)"
About Xorg : I don't mind automation but I am glad it is still possible to make use of a xorg.conf file.
While I am here : tinyX has disappeared from the repositories ?
Offline
As to why TinyX disappeared, I don't know. If you mean pankso's fork of Xorg with just vesa loaded, then it's still possible to use it. As for Xvesa, development for it has stopped nearly 3 years ago. You also don't understand. Xorg is pushing us to automate configurations at boot. Some of the most annoying bugs with SliTaz 4 is directly related to this. This is what I meant with relearning stuff in my previous post.
As for run levels, by their description it seems they add a level of complexity to the boot command and the structure of the system. It adds five rc boot files instead of one. It's the hardest solution to a simple problem. IMO, It's the opposite of KISS, which is what we aim for here. Why not just use screen=text or the others found at http://doc.slitaz.org/en:handbook:livecd ? Is that really a viable reason not to use something? That it lacks a complicated and badly designed 'feature' that can't be changed in other Linuxes now because it's become 'standard'?
Promotion is always good. I promote SliTaz to everybody. The programming language Nimrod too. But we need help more. We need documentation writers, packagers, Kernel and Xorg experts. We need support people here and on IRC.
You see where I'm going here?
Offline
i am guessing ubuntu or debian sources are freely available ?
why not just use that here (for xorg) instead of trying to reinvent the wheel) ?
I do not feel there should be much possible improvement here, or am i wrong ... ?
Offline
Sometimes reinventing the wheel is a good thing. Ubuntu's and Debian's sources are, to reuse the wheel analogy, Reuleaux triangles in shape. It works well as a wheel replacement, but you'll have to have specialized car to be able to use it. Using a Reuleaux triangle for a wheel does conserves momentum better and uses less resources to produce IF you have a car that has variable wheel base and flywheel. That's why Debian/Ubuntu/Other Forks work so well with it. They're all of the same model of car designed to work with Reuleaux Triangle wheels.
This is where it gets tricky for SliTaz. Our Car is designed to use our own ROUND wheel design of wheel. We pretty much have to rebuild the whole car just so it can use the Reuleaux triangle type of wheel provided by Debian. See what I mean? To rebuild SliTaz to use Debian's core, we pretty much have to remake SliTaz from scratch to BE like Debian - otherwise it won't work.
Offline
dont make it look like debian. >:-o
was just hoping that this specific part would be further up the food chain
Offline
It's never that simple. Several packages need to be compiled against the Debian's Linux kernel and Xorg. We'll probably have to patch the Linux kernel to work with our compressed iso method and we'll have to strip it down to save space. We'll also have to adapt to it's boot scripts and install the applications it uses for auto-detection.
Doesn't sound alot, but it'll be a hit and miss thing in the beginning. It's really just easier to fix our own core than integrated another one. With bigger Linuxes anyway. This may work with smaller cores like used with Puppy and TinyCore because both focuses on simplicity.
Offline
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.57 MiB (Peak: 1.77 MiB) ]