SliTaz SliTaz Forum

You are not logged in.

#1 2013-12-27 04:47:44

HelpfulCust
Member
Registered: 2013-12-27
Posts: 2

Prioritizing Slitaz development

Info: I'm using SliTaz 4.0, on a one year old Samsumg Notebook with an Intel Dual Core i-3 processor, from the LiveCD. 

First of all let me start by saying I think StliTaz is a very promising system and well designed in many aspects I've seen (it has great functionality and a simple layout) which is why I chose to use it.  But, calling SliTaz 4.0 a "stable" version is very dishonest... it looks like its still cooking to me. 

If you want people to use your system, the first priority should be getting people past the first boot screen quickly and easily.  This means ironing out all the boot bugs, AND making sure the CreateUSB or LiveCD functions work normally.    Both are not true.

The CreateUSB function created a USB and copied all the files, but put them in the wrong directory.  That could be found and fixed in the most basic test of the program (does my CreateUSB program make a functional USB?).   You folks seem plenty smart and I assume have tested the features, then how could something like this happen?

Secondly, to boot up in generally is tragically buggy, I have to specify the language pack first, because trying to boot without the language back configured first will stall the program before loading the desktop (so essentially no desktop and half a working OS). 

With so many bugs on start up, it is only appropriate to call SliTaz 4.0 "still cooking".

I recommend re-releasing 4.0 and thoroughly going through all the main boot options manually to work out the strange little bugs that exist there.  Again, getting in the door, that initial boot up, is hugely important, it must take a higher priority in coding.

As an example, look at the Tor browser.  It is so good it doesn't even need an install, and works right out of the extracted files, with Mozilla, HTTPSeverything, ect, all right there and working in no time.  People trying a product like that are going to be using in long into the future. 

ps (I know you folks do this for free, but you do make your product for other people, and I assume you want people to use it.  So don't crap all over me for giving you some criticism)

Offline

#2 2013-12-27 11:24:42

Guest
Guest

Re: Prioritizing Slitaz development

I'm not a developer, only an occasional user of SliTaz, & whilst you are using SliTaz 4.0, there is a new version being worked on.

All 'bugs' are, no doubt, greatfully received by the developers, but I think it is more helpful if you could state your machine's specifications along with specific problems that you are experiencing.

(I think SliTaz 4.0 may have been developed before the emergence of Intel i3 processors.)

Just as you have, probably, only got an Intel i3 based machine, each of the developers may only have one machine, so you can see the complexity of getting it to work on every machine ever made.

#3 2013-12-28 11:24:27

HelpfulCust
Member
Registered: 2013-12-27
Posts: 2

Re: Prioritizing Slitaz development

@ fatmac  here is an update and further details

specifically, using the CreateUSB in Slitaz 4.0 creates files in a folder name that is not looked for on bootup.  The folder that is looked for is called "isosystem", located in "boot" so I simply changed this file name to the correct name and voila.

but unfortunately, the bugs weren't stopping there.  so I switched to "cooking" to see if some of these bugs were fixed.  Some were, great.  In cooking the screen for language choice now comes before booting up, thus ending the glitch of a bootup then failure when asking for a language choice after the fact. 

however, cooking has a new bug of changing the mouse curser into a black square and putting black squares all over my desktop.  that was all I could stand.  despite how pretty SliTaz is, I'll have to pass for now, I need a more stable windows replacement right away. though I'm  still not happy getting a giant all in one OS.  might try switching to 3.0 in the future, for more stability, even if less features.   

can't give any more machine specs, I'm using another computer, and too lazy to look at my other system today, lol.  thanks for the reply.

Offline

#4 2013-12-28 12:07:12

Guest
Guest

Re: Prioritizing Slitaz development

Sorry you are still having problems trying to use SliTaz, it is a very good distro running from ram.

Looking at your post, may I suggest you take a look at AntiX as a small usable system.

http://antix.mepis.org/index.php?title=Main_Page

I use AntiX base for nearly all my personal computing; very light on ram usage & Debian based.

#5 2013-12-28 13:40:14

Trixar_za
Administrator
Registered: 2011-03-29
Posts: 1,506

Re: Prioritizing Slitaz development

Why was SliTaz 4 released in a rush without a lot of testing? Well, there hadn't been a release for 2 years back then - partially caused by an ex-developer with some weird ideas creating an unstable build environment and breaking several key packages. And then he disappeared when he was called out for it. It was decided that we should try releasing what we had - so we released 3 release candidates which was not tested by a lot of people - probably because people are lazy. So when we released it, it was with only the developer found bug fixes, suddenly the lazy individuals bothered to test it. Hence the untested nature and unstable nature of SliTaz 4.

The trouble with comparing an OS with an application is like comparing a motorcycle to a bicycle. While both may have two wheels, the motorcycle is infinitely more complex and relies on several parts to work. Same with an OS - there is a lot of working parts that is needed to make it work. Why is that bad? Because a single person can't test every part in all circumstances. Testers are important for bug fixes. Lazy people are not.

So maybe you should stop being Lazy and actually try to be a Tester and bug reporter instead.

Offline

Registered users online in this topic: 0, guests: 1
[Bot] ClaudeBot

Board footer

Powered by FluxBB
Modified by Visman

[ Generated in 0.016 seconds, 7 queries executed - Memory usage: 1.54 MiB (Peak: 1.77 MiB) ]