SliTaz Forum
You are not logged in.
Pages: 1
I'm working on my own SliTaz version that I'm building with the help of buildroot. I'm planning to do the following (so far, more updates to come):
1. Compile it against eglibc to maintain binary compatibility with the SliTaz packages while reducing build sizes.
2. Use the latest Linux kernel it supports with as many functionality enabled as possible. This will also include the building of several modules into it like dialup, wifi and bluetooth.
3. Use Xorg with the majority of drivers include for input and video.
4. Use Busybox for the majority of command line utils.
5. Use Busybox's init and mdev instead of systemd and udev.
6. Drop SpaceFM in favour of something else, possibly ROX-Filer.
7. It will include the latest (working) copies of the SliTaz scripts and programs (like Tazpanel) with possible modifications by Aleksej.
It's still a work in progress so any suggestions will be helpful.
EDIT: Added the bit about Xorg
Offline
May I suggest being as simple and stable, as slitaz 2.0?)
Offline
That's the plan. Not exactly from scratch, but I'm planning to drop all the 'junk' out of my version to keep it lean, configurable and simple.
Offline
... an excellent plan, and surely something to look forward to. So, if I understand you right, binary compatibility means you won't need to maintain your own repo because the v4.0/v5.0 packages will (mostly) work with the new kernel and the new environment? Shame about SpaceFM though, but in its current state it really isn't working reliably. I wonder what has happened to the Ignorant Guru? He's vanished from the surface of the earth, it seems. But ROX-Filer instead of SpaceFM? Uhhh! I guess it's a matter of taste and many people are happy with it, but I always found ROX-Filer way too primitive and awful to use. What about the nohal version of the Guru's PCManFMmod?
Offline
The main goal is to keep binary compatibility with packages compiled using either glibc or eglibc, which should keep us mostly compatible with the SliTaz packages while keeping the ability to convert packages from other distros.
I did some research and it's one of the few file managers that will work without hal while still managing the desktop - I still have to see how compatible it will be with mdev though. The other choice was Thunar, but then I'll have to drag most of XFCE4 along to make it work properly. The same is true for the current pcmanfm which has gotten way too heavy to keep around.
Offline
Hi, Trixar!
You thought something interesting.
Sorry, I never liked it when some "little Linux" developers fled in different directions, offering their own solutions. This happened with PuppyRus Linux. I walked away from their team. I have come here. I believe that we need stick to a single line of development. I think that we have too few developers to have left us one of them.
But, after all, if you do not try something, you do not know is it bad or good. In the Linux world things are changing quite often. Sometimes you have to try different things before settling on any one. So I can tell you only one thing: good luck!
My rework you will see on hg.slitaz.org. Now everyone is in a very raw form. But after a few days, everything will be a little better than it was before. Basically, there will be no radical changes. It will be a little easier to support projects, both for developers and for the translators.
devl547,
I definitely need to try SliTaz 2.0, to understand what is this simplicity which all talk so much here. Such a thing, I like the convenience, beauty, and only then — simplicity. A matter of fact, I very like to write scripts. After learning some sequence of actions, I will teach script to do the same thing, but without my participation. And now, for example, to connect to the internet, I ran a script called MTS. It called wvdial, giving the necessary settings, and when the connection is established, corrected file permissions for /etc/ppp/resolv.conf and /etc/resolv.conf. I would just run wvdial by hands, and just as easy to change the permissions on a pair of files. At first, I did so. But I like the convenience, so the script was written. It is — still simplicity, or already — no?
It seems that I also want to make my own version of SliTaz. It will be a "fat" version with GTK+2 and GTK+3, and Marlin as filemanager 
Offline
Aleksej: This isn't a fork or a split off from SliTaz. This is my effort to get SliTaz up to date and out there without having to fix a base that has been broken since before SliTaz 4 came out. That's why I'm using buildroot to do the heavy lifting since it's a proven solution for embedded systems. This is going to be my SliTaz 5 and hopefully a replacement base for the current rolling since cooking is a mess. This is why I'm making such an effort to stay binary compatible with SliTaz.
My plans however require the reduction in file sizes and using more of BusyBox's functionality like we're already doing with httpd and init - mdev is just the next logical step. Why is that important? I don't have a new system with a lot of RAM so size is IMPORTANT, but so is the need for it to look good. It must be simple, small and elegant. Not a mess like Puppy or anally sparse like TinyCore. It needs to be SliTaz.
Offline
Trixar_za, I applaud your efforts. Sadly, I am not a coder so can only really offer opinions and moral support. 4.0 is certainly in need of updates but must be done with the same philosophy. Personally, I don't use GUI much, but the features of small, light, and simple are very important to me. I love the idea of SliTaz and look forward to seeing the results of your work. Thank you for trying to keep it going.
Offline
@Trixar_za - just some thoughts....
first I thought rolling is compiled against eglibc - thats from a mail I got from pankso:
"I based my work on Eglibc and ther documentation. Like I read in emb-Gentoo doc "Glibc suck at life" so in
SliTaz we use Eglibc as main C library, from the time I understound that, cross-compilation is easier"
related: http://hg.slitaz.org/wok/file/cb4299f34f9d/glibc-base/receipt
You say - "I don't have a new system with a lot of RAM so size is IMPORTANT" - 2) and 3) are against this wish -
it just blows up the kernel and increases the iso. For me it would be much more intersting to find a tool to build a default kernel for evry computer - something similar to tazx....
using mdev instead of udev is also against your wish to include all video drivers - intel and evdev is depending on udev - see the getoo doku: https://wiki.gentoo.org/wiki/Mdev
and I find the combination of spacefm and udevil a good compromise. The only thing, that is not working at the moment is eject.
I think it is more intersting to look at the work of the new version - 2.1 of porteus, where they do not mount devices in /media - they mount it in /mnt
http://forum.porteus.org/viewtopic.php?f=35&t=2412
Offline
kultex: Didn't know about the fact that we're already using eglibc, so that does simplify a few things. Maybe it will be simpler to use vesa like we've been doing and allow the ability to install the drivers that are needed later. I don't know how configurable xorg is within Buildroot, so I'll have to check.
BusyBox's modprobe does allow the use of compressed modules (even xz ones), so we should be able to get a more complete kernel without taking up too much extra space. A more complete kernel will mean less trouble dealing with 'missing modules' issues like someone forgetting to include linux-sound...
I don't like SpaceFM. Compared to PCManFM-Mod, it's a mess and it's author has gone missing. If it was pcmanfm with udev/mdev support then I would use it.
I like the idea of mdev because it's yet another functionality provided by BusyBox, which saves us the space that udev would normally take. I have read the mdev entry on Gentoo Wiki and it does provide a pretty good example base: https://github.com/slashbeast/mdev-like-a-boss - I may fall back to udev, but I'll have to create proper config files for it.
I'd rather not do something just because Porteus, TinyCore or Puppy does it. We should set our own example considering we are the only Linux of our kind.
Offline
>Such a thing, I like the convenience, beauty, and only then — simplicity.
And how about stability?
Offline
Whew! I forgot about the stability.
This is exactly the same as forgetting that the air I breathe, forget that my heart is beating. Every second. In a 24/7. Without getting tired.
Maybe it's a strange thing, but I am staying in stability since SliTaz 4.0. No hangs, no side effects.
In SliTaz 3.0 my screen periodically "blinking" every minute. And sooner or later, the system simply showed a black screen. Sometimes this was a half-hour, and sometimes — a few seconds after loading the desktop.
It will be interesting to see SliTaz 2.0.
Offline
@Trixar_za
I dont want to quarrel with you, I just do not want that SliTaz is loosing another developer...
Please lets make a working 5.0 iso and I do not care, if it is pcmanfm or spacefm, udevil ur udisks - just after 1.5 years finish something. And your idea - "but I'll have to create proper config files for it (udev)" - is the only way I see now - and of course it should be the SliTaz way. But before, perhaps its worth to see left and right, because it perhaps saves time and energy.
For me the future of SliTaz is qt as all the lightwight linux apps seem to go in the direction qt, as gtk+2 is depricated.
LXDE goes qt - http://blog.lxde.org/?p=1026
PCmanFM goes qt - http://blog.lxde.org/?p=990 - and there are alternatives:
Andromeda - http://qt-apps.org/content/show.php/?content=146592
qtfm - http://qt-apps.org/content/show.php/?content=146352
Openshot goes qt - http://www.openshotvideo.com/2013/04/development-update-schedule-and-funds.html
Browsers: qupzilla http://www.qupzilla.com/ or maybe qtweb http://qtweb.net/
VLC is qt
apps planed by LXDe-qt http://wiki.lxde.org/en/LXDE-Qt
I think pankso saw already this direction, when he built the first SliTaz with Razer-Qt - http://forum.slitaz.org/topic/your-qt-desktop-in-38mb and I think we need evry developer for this change.
And stability is a matter of hardware - I am addicted to low energy used computers - and the current rolling is the first Slitaz version, that works perfect on my Portege R100 and my Futro A250
Offline
Yeah, I've been thinking about the Qt direction too which is why I excluded GTK2 from my list. It's sad that in GTK2 only ROX-Filer is the closet thing to meeting my needs.
Another thing I'm considering is the use of connman as our connection/network manager.
EDIT: Look at all those pretty Qt apps: https://github.com/Razor-qt/razor-qt/wiki/3rd-party-applications
Offline
>but I am staying in stability since SliTaz 4.0
1. Take latest rolling.
2. Try to install it.
...
4. Destroy all humanity.
// And I'm not talking about strangely done desktop settings (mainly lxpanel), lack of tazpkg autoremoval feature and outdated kernel.
Offline
You know, I just figured out something. I can make a traditional version and a lighter one which I can call SliTaz lite.
Offline
@devl547
installation works fine, if you use tazinstall and choose the iso installation
and I am using rolling (frugal) on my 12" Portege R100 for dayli work and I really love it - the lxpanel settings was strange at the beginning, but in combination with wbar its really cool on the small monitor. And the kernel is not outdated - and I will give you tomorrow a testing iso with kernel 3.2.50, which came out 02.08.2013, sowhere it is outdated.....
@Trixar_za
and I think we also could start to make Razor-qt version of slitaz with current rolling......
Offline
Just a User's view..
I like the idea to keep it simple and not ignoring older Hardware.
I'm using Sz4.0 on my 12 years old box (1ghz cpu/1Gb ram) and I don't miss
anything.
Maybe we should have a Slitaz-"legacy" for older Hardware which do not
need to have all the stuff needed for new Pc's.(lastest Kernel,PAE etc.)
imho a slightly updated Sz4 would fit the needs of mostly all of the old-Hw-users
On the other Hand the "regular"-Sz-version would not have to struggle with compatibility anymore.
and oldfashioned as I am...If a (additional) program-version-xx fits my needs, then there is no need for a bloated version xxx
Offline
I was wrong and I'll tell you why in a minute. I've been struggling to make a 'good' Buildroot SliTaz because Buildroot gives you A LOT of options to play with, which means there is a lot of trial and error involved. But Buildroot has a single flaw: You can't generate packages from it. This means anything I include will most likely not be the same as the one in the package repository. This also means the one in the package repository will break the Buildroot system if it's ever installed. It's also an overwhelming amount of work to decide what goes into a Linux system and what will be needed and what won't be.
That is why my goal of rebuilding SliTaz in Buildroot will never work.
My original goal was to redo the kernel, udev and xorg so it was an usable base to install SliTaz packages on to fill in the other requirements. That's should work and only add a few packages to the block list of tazpkg.
So my new goal is to build the kernel, udev, xorg and busybox with Buildroot, then install the slitaz-tools and add the packages we already have in SliTaz to it. Once that's done, I'll generate the iso with our own tools with maybe a few tweaks here and there to fix compatibility. Once I'm back, I'll start updating the packages so we can have a more stable SliTaz to release. I will also match the versions we already have in the repository so we can have better compatibility.
Offline
I'm reviving this with buildroot on my own system. I'll also revive my previous project to create a way to convert buildroot packages into slitaz one.
I would like to thank the group of people that have started to openly ignore me here in an effort to make me feel unwelcome. Making me angry just motivates me more - so keep it up.
Offline
Pages: 1
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.58 MiB (Peak: 1.77 MiB) ]