@Aleksej, Trixar: Why not use the SliTaz repository ?
Nimrod the Great(56 posts) (8 voices)
Mostly because I don't really know mercurial well. Araq and dom96 (two of the developers of Nimrod) would also like more Nimrod exposure on Github.
@erjo, for me it's the same, because I have write permissions to SliTaz Hg. Just I need separate repo in Hg. But I never seen Brenton's commits, does he have access to SliTaz Hg?
Ok, I need separate repo (make it name 'nim-tools'), where will be sub-repo with Nimrod developments (TazPanel, TazPkg, TazPkg-web, etc). I think I will rewrite them as long process with step-by-step implementing (more and more) parts of existing Shell code to Nimrod code, with keeping of work ability at any moment of development.
Btw, today I working with tazpkg-web. And it seems like we have slightly outdated code in our Hg rather than working code on pkgs.slitaz.org. @Pascal?
As far as re-writing tazpkg goes, why not base the new package manager written in nimrod on spk. We have already cleaned lots of code and broken it up into manageable chunks. I have been going through the nimrod tutorials and love it compared to sh.
@Aleksej I made like one commit to wok which fixed the ppp issue. I think I did the commit is trixarian or something though.
So yes, I do have hg access, only I rarely use it :P
Certainly Nimrod is a great tool, moreover the speed gain when running Tazpkg is amazing, but I'm very reluctant to see Tazpkg rewritten in Nimrod, mainly for philosophical reasons, there are other issues, but I'll stick to philosophical ones.
#1. Most people will lose freedom. Actually Tazpkg is written in Almquist Shell, the main benefit is that almost everybody is allowed to check its source code, understand how it works and maybe (who knows?) send patches to the developpers. If tomorrow, Tazpkg is rewritten in Nimrod, less than a handful of experts will understand how Tazpkg works and behave. All other people will not make the effort to learn Nimrod and instantly lose access to a part of SliTaz and, this is the most important issue, will also lose the freedom to learn, modify, customise SliTaz to fit their own needs.
#2. It's against the SliTaz Kiss philosophy: « Keep it simple: follow the best standards, carefully draft and write high quality documentation, provide a stable and robust system and keep the rootfs on the LiveCD light enough to run on machines with at least 128 MB RAM. It's also possible to use GTK+2, Dialog, SHell scripts, or PHP coding tools on the distribution. » (http://www.slitaz.org/en/devel/forge.php)
#3. Free Software is, like forests, atmosphere, fisheries, grazing lands, rivers, irrigation systems a common resource that is shared, used and enjoyed by all. Some people like late Elinor Ostrom spend their lifetime to define principles to manage commons in a long-term sustainable way. One of these principle is to allow most resource appropriators to participate in the decision-making process. I maybe wrong but I'm afraid it's not the case in the decision to rewrite Tazpkg in Nimrod.
It's just my own opinion, and I'm maybe wrong. I trust you and have great respect for what you do and have done for SliTaz, I just try to honestly express a different opinion without wanting to hurt anyone, please, don't call me Joseph Stalin:)
#1 Nimrod is easy to learn and it can output to C too. Most people pick Nimrod up in about a few days. Bash scripting Language itself requires you to learn it, not to mention the proper usage of awk. The source code will be open like Tazweb. Yet rewriting tazpkg will lose people their freedom? If anything it's no different than aptitude, which gets also released as a binary, but has it's source availiable.
#2 SliTaz KISS philosophy normally applies to the balance between simplicity, size and speed. If we rewrite tazpkg, the interface would be the same and we'll have the speed of a binary. Size should also be about similar. Also it's an acceptable standard to use binaries for package management.
#3 Nimrod and the new tazpkg will be GPL with source avialable that can be freely modified, so it will be free software. Simple as that :P
@domcox As far as learning a new language and code simplicity goes, sh is convoluted and does not emphasize good coding practices (3000+ line tazpkg is a testament to that). It is a good point though and one we should hold in the back of our minds when making decisions like this.
It seems that I need too to express my opinion to clarify the situation. As I see it.
@domcox , @all:
Probably I am geek. Or, a hacker ;) Most of all I love to program. I don't love anybody so much, how to write good code. Ehh…
And regardless of anyone's opinion, I'll write. And I'm writing now support procedures. Unfortunately, my vacation is over and now I can spend less time programming and project, but work will continue.
This is certainly a fork. Another question is whether it will be official? But it will be.
Our repositories have available regular kernel and kernel-libre. Perhaps we can afford the luxury — to have two versions of our projects? Judging by the initial negative evaluation, they should be called: tazpanel-official-(opensource-libre-kiss), and tazpanel-fork-(closed-evil-binary-blob). Oh, excuse me, I joking ;) Of course, in addition to the binary program itself, will be available the source code. And everyone just be able to contribute to its development.
In the world of Linux and open source is common to write in various programming languages. Write in the language that you prefer. So now we have a lot of great (and not) programs written in C, Python, Perl, PHP, Shell, Java, Mono, and others. We have TazWeb written in C…
It is considered that the language of BASH/Shell is very simple. Even if it is not, then it needs to know every self-respecting Linux users. BASH/Shell is always installed in all systems of Linux. I think that it is suitable for automation of daily activities, for any simple task, as well as for writing the drafts of any algorithms. In the case of heavy-duty cycles, is obtained that the CPU just executes unnecessary work, at a time when the same task could be performed faster and with less energy. How's about the principle of KISS? Perform the task at less cost — is KISS?
Of course, Nimrod is not ideal either for speed or size. The ideal is the assembler — language of the processor, but it is extremely difficult to develop anything. Somewhat better language C, it produces not as fast and not so little code, but it is the industry standard for writing major programs.
I am not a programmer, alas. And I do not want to spend too much time (a year or two?) to learn how to program in C. Nimrod seemed simple enough, and after a few days of my experiments with it, I had quite efficient and damn fast program. I do not consider myself to be too clever, and so I think that anyone who is familiar with programming in any language will be able to learn Nimrod.
Thank you a lot, I'll use this repo. To begin, I want to write a procedures that will be useful in any SliTaz project, for example, now I am writing a procedure for easy application of i18n.
And then, of course, will need to decide what to take first. We can divide. I personally would like to start with pkgs.slitaz.org.
The probability of receiving assistance in the development is vanishingly small (under 1% rule) regardless of the language in which we write our programs, whether it's Bash, or Nimrod.
But it seems that the three men are willing to continue right now — it's me (Aleksej), Brenton Edgar Scott (Trixar_za) and Christian Mesh (Naitsirhc). Good luck, my friends!
Don't forget that Nimrod generates C code before compiling it to a binary. So it's the power of C with the simplicity of Python. To me that's a good middle ground.
I think domcox means that we won't be able to just type leafpad /usr/bin/tazpkg to change it's code anymore. By writing it in Nimrod we're adding a few more steps to altering the code, namely having to install Nimrod (which will be about 5MB) and gcc, having to download the source code and then having to compile the changed code. This however has very little to do with Libre or Free Software, because either way complies with GPL. For KISS, learning to use Nimrod (and it's compiler) is a big hump and not the easiest thing for some. That's what I think domcox is trying to say. It's not exactly KISS friendly at first.
Yep, exactly Trixar_za,
Like when I go to/from work, I have the choice to use my assigned company vehicle or my own two feet.
If I use the car, I am warm and dry whatever the weather, I may listen to mp3 and cool! bills are payed by the company.
there are caveats though.
I have to check other drivers front, left, right, back, respect traffic lights and road signs, I'm often stuck in a traffic jam, it's also hard to find a place to park.
I'm totally dependant on other people, I focus my attention on driving: I'm dominated by the tool.
It's not the case when I walk, ok sometimes it's cold, somtimes it's hot, and I have to remove or add layers to adjust to the weather changes before going. It takes me longer, but it's time well spent as I found walks are relaxing and help me thinking and make decisions. Moreover, the motor doesn't produce emissions of air pollutants that have been shown to have negative effects on public health or the natural environment:)
I'm totally dependant on my shoes, I dominate the tool.
And this is why I gave up wheels for my own 2 Feet.
It's all about heteronomy vs autonomy.
This is where SliTaz shines, autonomy.
Haha! :D Nice story, Dominique! Please, tell me more. I seriously :-|
You forgot about one little thing — using your own legs as a means of transportation, it is important to understand their limitations.
Yes, I too can go to and from work on foot. And it is even pleasant, except when I'm tired as hell. It takes only 20–30 minutes. But once a year or two I can afford a luxury — oversleeping. And then I need URGENTLY to get to work. Have to call a taxi, can not be helped. Yes, I'm simply FORCED to take a taxi. But, on the other hand — I am happy that I managed such a small price to resolve the issue.
When I have free time and desire, I love to walk out of town and take photographs to nature. It is pleasant;)
By the way, come to me on Facebook! I have a mountain of beautiful photos!
But what to do when you need to get to the next city? When I was a student and I had not enough money to get home, I had to walk. I came home a few hours later, it was already dark, and no one waiting me. I've had plenty of time to reflect on the way ;)
The next story.
As a child I had a clone of the ZX-Spectrum (if you do not know - it's a computer with a Z80 CPU @ 3.5 MHz with 48 KB of memory, programs saved on a cassette tape and home TV was instead of monitor).
Pretty quickly I learned Basic, and then, eventually, I figured with the assembler. I liked to write quick little programs! Mmm… These were wonderful times! (And, I did not ask the question: why do I have to study this assembler? Because all you can do in Basic!)
Once I fell into the hands translated into Russian book «Graphics on the ZX Spectrum». There were all kinds of graphics, but I especially liked the program that plotted 3D surface, described by simple functions. Like these:
The program has been very slow. I do not remember exactly how much time was spent on a drawing, but it is certainly not less than half an hour. It was possible to change the position of «camera» in the 3D space, it can change viewing direction, and the function itself. And again, run the program, and again to wait half an hour ;)
After several years as a student, I worked in practice, and we have been working on IBM PC @ 33MHz, and then I learned what is QBasic. After a while I studied it and was able to adapt the old program to another Basic, to another screen resolution, for opposite directions of the axes… What can I say? The program just flew! I was pleased with the whole picture was drawn for a minute or two, and still could press PrtSc and get a picture on memory from the dot-matrix printer.
Is there forced me to learn any ZX-Basic, assembler, and QBasic, as it did in the first story? Eh?
Yes, it's my curiosity! My reluctance to accept the current situation…
The third, and last for today, story.
The story on the rational use of resources. We return to the ZX-Spectrum. The first programs, the first games for it were written mainly in BASIC with a little machine code. Frankly, they were miserable. But, every year in my hands got all the new, more beautiful game. It seems that the developers were able to squeeze everything out of this machine, but no! See the following more beautiful game, and my eyes are disclosed in surprise, and the hands are drawn to the disassembler to see how they work. And, I still stayed with CPU Z80 @ 3.5MHz and 48 kb RAM. I only added a music processor.
The developers were not lazy to improve their skills, develop new algorithms, to learn new techniques, and they really do impossible things! A user could only wonder and enjoy the benefits of progress ;)
End of story. Now the conclusions.
If you really think you are a developer, learn a new programming language, or, better, a couple. This will be an inspiration to you, you will have new ideas.
SliTaz rocks not due to its autonomy, but because it's small and fast, as though it may sound commonplace. Simplicity should be for the user. But the developer has a lot to know and be able to spend their time looking for solutions on the Internet, spend time and mental strength to develop new algorithms, with permanent self-education.
It's good when developers know Bash. They can interact with each other. But I think we have reached a certain point when using the old techniques are no longer effective. If you wish — please refute me, rewriting the TazPanel shell-code, the code that gives the packages lists. We need to do it, though not at 10 or 500 times faster, but only 2 times. Okay?
Well, finally, it seems to me that you is not seen or tried the Nimrod. Why refuse without even looking at him? Welcome to the page Nimrod Tutorial (Part I). Read a few screens, is it difficult? It seems to me, becoming acquainted with him better, is simply impossible to give it up.
I'll leave you all with this:
brenton@trixarian:~$ python -c "import this" The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
I have started work on several utilities that I think will be key to interacting with the sh config files we should continue to use. I will commit them tonight (~9hrs from now), I have to go to work.
You must log in to post.