SliTaz Forum
You are not logged in.
The following is a wishlist for a new flavor of slitaz 5, once it's finished. I think it could be made as the main flavor for slitaz, although making it the main flavor isn't essential; simply making it downloadable via tazlito list-flavors is also sufficient. I find that a new flavor/changed list of installed programs is however essential, as the core flavor of slitaz has too much programs, and the gtk+ and justx versions are missing important slitaz-specific programs for changing settings, ... A new version that has just enough programs, keeping the essential control programs is really needed for the community (especially beginners), as adding more programs is rather easy, but deleting them isn't (at least not when making a customised slitaz version using tazlito). Hence the request. Besides the programs, I would also like to suggest that changes are immediatelly done to the boot menu (allowing persistence when booting from writable media). Also, the flavor should be a simple flavor, not having multiple in one flavors (for convenience and simplicity; especially when the user needs/want to customise the distro further and add additional programs for making a modified flavor/iso; (this way, there are no additonal gz files present).
Please note that my suggestions are just my own thoughts of how the main flavor of the new slitaz version should look like, and other people may have different thoughts. So, anyone that wants to see some things differently, please mention it here, and webmaster: please make this post a sticky post so we can discuss things thoroughly and have everyone had their say.
Some prior posts/ideas that led my to post this request can be found via http://forum.slitaz.org/topic/slitaz-5-rc2-problems
http://forum.slitaz.org/topic/making-user-and-root-account-at-splash-screen
Features requested:
single boot screen on startup; currently in the RC2 and cooking versions there are 3; one where you select language, then a screen where you can type extra parameters in (disappears quickly) and then another screen to select whether one wishes to start the justx, core, or another flavor, or a memtest, ... Only the last screen should be kept and preferably made to show:
* log in as root
* log in as root + persistence
* log in as user (tux)
* log in as user (tux) + persistence
* install SliTaz to HD
* help and options
* Command line
* PXE boot
Note that, obviously, the login accounts with persistence will only be of use with writable media (so not when booting from livecd (cd-r))
That said, if the user wants to only use it with non-writable media, he can easily remove these login accounts and make an updated new Slitaz LiveCD. The same goes when the user has installed slitaz to HD and wants to remove the "install to hard disk function".
no slim login manager; instead when logging out, the user should get back to the DOS-like login screen (aka the screen that displays "Welcome to your box", ... This change would allow using FAT32 as a filesystem for slitaz liveusbs.
Instead of lxpanel, adeskbar. Adeskbar is equally lightweight, but sits in the center, looking more as a "dock". It's also better for people that have screen troubles (video driver troubles) as the apps have less the chance of being "out of screen" then. In addition to the new taskbar, we also then need a pager to allow people to switch desktops easily. The pager can be placed at the top of the screen (center), whereas the taskbar can remain at the bottom center.
For the programs to include, see the text file in annex. The program list was composed looking at slitaz 4 (core live), but will probably be similar to how it is with slitaz 5 now, so the required changes should be minimal. Note btw that the mountbox isn't standard with slitaz 5 RC2, this really needs to be included again; it's listed in the text file as well.
Additional packages to avoid graphics problems; note that these were standard in slita 4 final yet there are not standardly present in slitaz5 RC2:
* xorg-xf86-video-intel
* xorg-libXvMC
* xorg-libXv
* mesa-dri-intel
* mesa
* mesa-dri-ati
For the keyboard, a 2 year old problem seems to persist in the current slitaz 5 RC 2 version, I hope this can be solved by the final slitaz 5 version (see http://forum.slitaz.org/topic/how-to-switch-a-keyboard-layout-in-slitaz ).
One other thing to add would be the ability to add the parameter "xforcevesa" at the boot screen. That eliminates the need of having a seperate flavor of slitaz with only vesa drivers (there is one such flavor made for slitaz 3 I remember). Ubuntu linux has/had a similar thing at his boot screen btw (also using xforcevesa), it was called "safe graphics mode".
Let me break this down in reverse order:
1. SliTaz already uses vesa for it's LiveCD and initial install. Adding that option would be redundant.
2. The keyboard issue has more to do with Busybox that SliTaz. Still a reboot to change it is reasonable.
3. Adding too many video packages - especially if they're not needed - just bloats the iso.
4. Adeskbar is not a reasonable replacement for replacement lxpanel. It needs python and extra packages - in total it will add ~15Mb to the iso's size.
5. The term your looking for is CLI - command like interface. It's older than DOS. Also to use it for login instead of SLIM would be bad for the very fact that after login the user will have to type startx each time to get into SliTaz. This could probably be automated, but this will break virtual terminals and if X.org ever breaks, you'll be completely screwed.
6. FAT32 really isn't a very good filesystem and fragmentation prone. It also has limits. Just use ext2 instead. It'll wear out your flash disk less.
7. Persistance with an compressed iso image - it will need about 15 minutes to shut down every time and will have to rewrite the WHOLE image each time with a CD-Rs. Waste of time and space IMO.
8. You really can't use LiveCD boot menus like that. You cannot login using a cheat code either. So it's unlikely to happen.
The one flavour idea is pretty good though.
Another thing to note is that adding packages expands the iso image and the RAM required to boot SliTaz. It dumps EVERYTHING into your RAM - so the bigger it is, the more RAM it'll take at boot. Just remember that.
Offline
>This change would allow using FAT32 as a filesystem for slitaz liveusbs.
One can already use FAT32 as a filesystem for SliTaz liveUSBs.
I know I'm using it and it works like a charm.
>Adeskbar is equally lightweight,
No, it's not.
>but sits in the center, looking more as a "dock".
Which is another reason not to include it. If I want a "dock" - I can install Mac OS X.
For the keyboard layout thingy, see: http://forum.slitaz.org/topic/romanian-keyboard-layout-on-slitaz
It works without reboot. It's exactly the same method used in Lubuntu (or LXLE).
Another reason not to implement it. If I want a "dock" - I can install Mac OS X.
As this thread exists;
What I want to see in the next release.
A decent web browser (Firefox), file manager (Emelfm), music player (Xmms), picture viewer (Gthumb) & as many wifi firmwares as can be included,
This setup allows for people to install it, play their music, get online, & download any other software that they want.
(I personally would like to see a command line version also; including elinks, mc, moc, feh, & perhaps mutt,)
Regarding the panel:
if adeskbar isn't suitable, then there might be some others that are as lightweight as lxpanel, yet aren't part of the LXDE project. See http://antix.freeforums.org/viewtopic.php?f=49&t=5368
Some alternatives are SimDock, BBDock, fbpanel, PyPanel, SimDock, Wbar, Avant Window Navigator, Docky, Apwal, Tablaunch, tabble, WMdrawer, ...) I mostly like BBDock and Apwal as second choices, Wbar is also suitable yet more difficult to customise.
Xforcevesa might be used for initial install and livecd, but it isn't standardly shown as a boot option (using it as the main driver for inside slitaz after logging in). I still found that when using a not supported graphics card, slitaz defaults to the tty1 login screen and only text mode is available (no x). There should be the option to still login, get the drivers installed and working and then reboot and run without safe graphics option (xvesa) at the boot screen.
In addition to the above, the following apps might also be added standardly:
GDebi Package Manager (for installing packages not available from Tazweb update manager, without hassles encountered with manual installs -ie dependency errors)
The system-config-printer utility, as also present with Crunchbang.
Let me show my opinions too.
@fatmac: I think that including all these packs into the iso could make the file "too fat". One of goals of Slitaz is to be a small distro. If someone wants these programs into the distro, just download and install them with tazpkg.
But if the packs are not available at the moment at repositories, well, we could ask developers to include them.
Slitaz Doc has a page called "Recommended software Packages", but it's empty now. Maybe someone could write some tips there... to recommend Firefox, Xmms, etc...
The link: http://doc.slitaz.org/en:guides:recommended
Offline
Regarding the size of the iso file: I actually thought about that issue myself a while ago (see http://antix.freeforums.org/viewtopic.php?f=49&t=5361 ). To be honest, I think this issue can be solved rather easily, simply by making both use of frugal booting and harddisk space to save programs and files. The idea is to just install slitaz frugally (frugal install to harddisk) and then run slitaz in RAM, and have all demanding (in terms of CPU usage) run in RAM, but run large programs (which are not demanding in terms of CPU usage or can be run at slower access rates without problem) on the harddisk. Let me give an example: if you were to run a 3D program like SketchUp, you would run both the program and the 3D models you're working on in RAM, whereas say openoffice or libreoffice can be placed on and run from the harddisk.
Especially for computers with slow harddisks (say E-IDE harddisks), this can make otherwise unworkable programs (like SketchUp) still run well (well assuming that the rest of the PC has moderate specifications, ie atleast low-end 3D card needs to be present, a moderate amount of RAM, ...).
The changes needed to the new SliTaz version would also be minor; the only main thing would be that you would need to be able to install programs and files to a specific destination; namely the harddisk (in case for non RAM-run files/programs) or the location where the slitaz frugal install is placed, so that it can be loaded, along with the rest of slitaz to RAM at bootup.
Regarding the new page for slitaz suggestions; I'll add a page and link to this forum post. People can then read the posts and the text file in annex to one of the posts. Perhaps also of use could be these links for more suggestions:
http://en.wikiversity.org/wiki/Linux_adaptations_for_UMPC_design
http://en.wikiversity.org/wiki/Improved_UMPC_design
actually, I would have preferred this topic started by an admin.. which would have meant that finally a *stable&working* release of V5 is ready
But, ok, will wait, still using glorious v4.. 
Fyi, I boot v4 from a fat32 syslinux usb key, loading my own matrioskas, and work *only* in live RAM.
Once there I open all file systems (ext,ntfs,fat,fat32,...) in all disks (ide,sata,..) internal and usb, compile and/or run any program I wish, loading it from any filesystem.
So for me, the matrioskas dimensions must be the smallest the possible, exactly because then I must be able to load later heavy programs I need in live RAM.
An important feature which should be conserved from v4 to v5 is the complete *updated* gcc and external libraries set, so to be able to compile *any* external source code.
Of course gcc and libraries and so on must keep staying only on net repository.
Plus would be very nice to (still) have other kind of updated precompiled packages on the repository, about those heavy applications notoriously difficult to compile for the user, such as Firefox, Wireshark, lalala, ...
Please, if you won't remove staffs from v5, at least keep the default matrioskas dimensions as of the size in the v4, not more, thanks
Firefox isn't really lightweight - there has to be something lighter. with panels stick to compiled binaries with low library dependencies. Less than ~1Mb with dependenes added to the ISO size is better than ~15Mb.Deadbeef > XMMS too.
Suggesting a Debian package manager is a bad idea. SliTaz isn't Debian or based on it. How they structure programs are different and we use none of the debian tools. So using a debian package manager would have a 100% chance of breaking SliTaz.
The iso is compressed. If you want to know how much you'll be adding to it's size, look at the size of the packages. The compression they use are the same. LZMA is really slow to compression (but lightning fast with decompression), so a Puppy-like persistance will share the same slowness so it's unlikely to be added any time soon.
Feel free to post fixes to the packages here. One of the maintainers would most likely apply them if supplied. There's just too many packages for a handful of maintainers to keep up to date on their own.
Offline
Regarding GDebi PM: you're right (I didn't think of this). However, it doesn't need to be GDebi really, even a terminal-like tool specific to slitaz is also fine. The main thing it needs to be able to do is find and install the additional dependencies needed to run the package you want to install and it needs to be able to be launched directly from PCMan FM, by right clicking (rather than needing to type in commands via terminal). I give an example here: skype-for-linux: http://www.skype.com/en/download-skype/skype-for-linux/ ;after downloading the debian package and having converted it with the tazpkg convert command, it should need to be automatically installable by right clicking on it via PCMan.
The other thing I find that would also be handy is taking over the conky data (shortcuts list) and the shortcut configurations themselves put into openbox as too present in Crunchbang. This seems trivial but it speeds up working with any linux OS tremendously, and not everyone takes the time to put in the shortcuts to openbox.
Regarding firefox finally, something comparable like Iceweasel/Icecat, Qupzilla, ... or something else entirely (see http://en.wikipedia.org/wiki/Comparison_of_web_browsers ) can be used. However, midori is too restricted (even google mail doesn't work). Also, printing needs to be possible too (i.e. with the Light web browser that too is cut out). So, whatever is chosen, it needs to allow basic functionality at least, which midori doesn't currently provide.
... sorry, forgot to add about those notorious heavy applications: most of them are now impossible to compile in v4.
That's also why I'm really looking forward to the final v5 ... hehe
Something like what Puppy's Ubuntu flavors do for a few select packages, huh? It uses the same busybox commands that tazpkg's convert does, except it also tracks missing dependencies which converts and installs auto-magically too. Mind cause trouble with some packages though, so that's probably why Puppy restricts it's usage.
Offline
>A decent web browser (Firefox), file manager (Emelfm), music player (Xmms), (...)
I was looking into Slitaz repositories and I saw that we have Firefox package available to install. Also, we have Audacious, wich is a Xmms-based music player. All available at TazPkg.
Furthermore, if one want to install Xmms (wich is not been developed anymore), one can go to Xmms website, download and manually install it.
Offline
The title says 'wishlist'. These are my regular programs.
It is up to the developers to decide what actually goes into the distro, & I will go along with what they do, I can add & remove packages to my hearts content, as can anyone else.
Some of the above discussion about loop mounting compressed programs is how it is done in TinyCoreLinux, another very lightweight distro that I am using/playing with. 8)
it'd be good to have some frugal-install issues solved, like allowing rootfs.gz files larger than 500MB.
Offline
i have not yet found a wish except more self documentation maybe?
this is the most epic linux i have found, but it's possibly little stuff like some UI thing that turns on and off the settings in inetd.conf to create an ftp server, i think this thing about this distro is it is leet and never compromises, but anyone should be able to use it
otherwise don't change it
Offline
) "more self documentation" ? puppy! hahaha )
... sorry couldnt resist...
There's one extra thing that might best be done as well: looking into BusyBox.
SliTaz has just implemented the entire BusyBox, but I think that there are too much commands/tools in BusyBox: see http://www.busybox.net/downloads/BusyBox.html#commands
For example, there's the dpkg and the rpm command in there, and I heard that installing such packages would break slitaz (which uses tazpkg). dpkg could be handy still for downloading say debian packages after which they can be converted to tazpkg packages, but then again most debian packages you'll need would probably be downloadable from the main project sites anyway, and you could always still use a different PC (with debian on it) to download such packages and then simply transfer (via ethernet or external drive). There are much other commands that can be scrapped in BusyBox as well I believe; which are not used in SliTaz currently and/or can be avoided (for example, in stead of rmdir, one could use the rm command with the -r option. To do all this, I was thinking of a script making BusyBox into "BusyBox light". Perhaps that some commands can also be added, such as the locate command and the rename command (see http://www.tecmint.com/rename-multiple-files-in-linux/ ) Also, I was thinking that BusyBox's init and mdev could immediately be used to replace systemd, as proposed by Trixar_za (see http://forum.slitaz.org/topic/buildroot-slitaz )
Lastly, I was thinking that our current slitaz setup, which has both tty and pseudoterminals is overkill. In the programs text I added at the beginning of this post, I mentioned dropping one terminal -like sakura- in favor of another one (like xterm). Since we also have 7 tty's running however, I'm thinking that even this is still overkill as the tty's can also take over the function of the pseudoterminal, and we also don't even need 7 ttys running anyway (2 would do, one for running in X, the other for the terminal/command-line function). Switching between command line and X would then be done via Ctrl+Alt+F1/F2. If this seems unsuitable for most, the alternative would be to simply remove tty/getty from BusyBox and not use any tty's at all. I guess that it is then also be there's no slim installed neither, so that logging into X can be done by the "startx" command. This way, even if there are graphic driver problems, there is still the option of fixing that via command-line. It also avoids the slim/fat32 problem.
In regards to the taking over of the conky data of crunchbang (all ready mentioned somewhere on this post): it would be best that we also include the used bandwith (this connection) and used bandwith (this month). That's handy for say reducing your bandwith use -for example if you're surfing via a internet connection where there's a limit on the bandwith, or where payment occurs per MB downloaded)
Why cripple SliTaz for no real gain?
Those package extracting example commands you mentioned is actually what makes tazpkg's convert works. Busybox is already slim as you're going to get. Stripping out commands will save you kilobyte values in the single digits for every couple of commands while the user loses out on scripts and programs that needed them (a good example would be Sakis3g).
SliTaz is already using init for boot and I don't think mdev is really useful beyond experimentation. Dropping udev just comes with really big hits. Both with software (like usb_modeswitch) and drivers (intel) that needs it to work and the loss of support for 95% of laptops, tablets and netbooks. So it's really not worth the couple of megabytes we save.
Those tty doesn't really take up any resources and it fills the spaces until you get to the 7th one - which is where xorg is. So reducing it to two would leave you with nothing at F3 to F6, with the removal of the 7th one breaking xorg.
I still think the startx recommendation is needlessly complicated and born from your misunderstanding of an SliTaz issue. It's not slim that breaks the booting on fat32. It's how the filesystem is compressed on the iso and how the kernel is compiled. It's aimed and made for ext2 (or better). Using any other filesystem breaks the expectation of the compressed filesystem, which makes it's applications freak out in the process. You just see slim fail, but it's a deeper level of breaking - xorg and the kernel is broken or in the process of breaking in that instance. All because you don't match the expected filesystem. Your purposed fix won't change that. However if the expected filesystem is changed at the kernel compilation and iso compression time, then maybe fat32 can be used (actually, you'll ONLY be able to use fat).
Offline
>SliTaz is already using init for boot
Well, it can be improved a little)
> Dropping udev just comes with really big hits
Works with no problem, actually. The issue is to configure it properly.
Offline
Yes, but it comes with it's own host of problems - as outlined here: https://github.com/slashbeast/mdev-like-a-boss
We'll lose evdev which will force the addition of mouse drivers especially if you want to use a touchpad. There's also several applications like chrome/chromium that will just refuse to work without libudev and lsusb will lose the ability to show device names. The only way around it is to actually include or create a udev that's just an inactive library - possibly stripped down too. Another loss would be auto-mounting through udisks (like with XFCE), but this can also be worked around using pmount and some clever mdev conf hacking.
Honestly, it was just way too much effort for me the first time around which is why I never bothered with it beyond basic testing.
Offline
>Yes, but it comes with it's own host of problems
Sure. There's no silver bullet.
Guys, when we gonna start updating core packages (gcc, glibc, kernel)?
Offline
In my opinion, as SliTaz is one of the most smart distros, it continue to contains to much redundancy!
e3, nano, beaver, leafpad... why? vi is a must in all distros or link to a compatible editor for vi. as vim is operable as well as console as as xwindow application, and compatible with the key mode of xombrero (highly compatible with TazWEB a frontend of the same browser engine and, very important, secure! I did test the actual version in SliTaz: marvellous! Fast and complete comfort of other high performance browsers...) I would give logicaly the preference to only one, vim (vim is one editor with a great sortiment of plugins and is able to open and include text modules recorded as external files into texts, the decisive step to make professionell text processing out text modules!) and install in the console mode «SliTaz base» only vi! it is easy in SliTaz to add what you wish else, nano, geany or what you can prefer!
SliTaz did have other preferences being more important in the past like retawq, rhapsody, clex, mplayer and firefox, and doesn't pre install that any more! why also a lot of not needing apps making it more fat as it would be the case according more attention to redundancy?
I see that SliTaz 5.0 seems to be about ready!
I would thing about what SliTaz 6.0 can eventually be after that! I would wish a distro prepared to compile itself automatic through a (set of) script(s), and perhaps a «compile panel» as front end: The daily build would be only the result of that processing...
Why? SliTaz is one of the smallest distros. Compile an elephantic distro is possible, distributors do it! But (the most) private persons can only do that in limited size and I see SliTaz as the predestined for it as it is so smart and so small and did offer in version 4., 3. etc. the different steps for it as «SliTaz base», etc.
This will say: The tools would have to be optimal yet in SliTaz Version 5.0 as a good platform to do more.
Kind regards
Offline
Some preferential applications is required. I prefer nano over vi (which is incidentally provided by BusyBox), but I would admit that inclusion of pico is a bit redundant. Geany is my favorite graphical editor, but it might not be as easy for people to use like a stripped down editor like leafpad or a simplified code editor like beaver. The thing is you can't expect a beginner to know (or even like) vi's commands. Some level of redundancy in editors help ease the transition for people new to SliTaz or micro-distros in general.
I would agree that the inclusion of some applications would be good while reducing the ones we don't need. Personally, I think we should include mplayer, deadbeef, document editor (like abiword), a small web browser (not Midori) and a simple IRC client (not rhapsody) to the mix. I would like it to be slim, but functional. Somewhere between stripped down to the bare minimum like a base version and Puppy's insane 'one application that does one thing good' philosophy that translates into 3 apps that does the exact same thing, but in different ways.
Xombrero looks interesting though. Does it use a similar switching scheme to irssi or weechat?
devl547: I really should get my ass back on SliTaz and helping out with the updates.
Offline
[ Generated in 0.016 seconds, 7 queries executed - Memory usage: 1.61 MiB (Peak: 1.77 MiB) ]