Menu
Hi mojo, i tried this but 'tazpkg.convert' was looking for the file /etc/slitaz/tazpkg.conf. Apparently, 'tazpkg extract tazpkg-3.4.tazpkg' doesn't create this file in /etc/slitaz. I then tried directly installing tazpkg-3.4.tazpkg in slitaz 2.0 and it installed this time (if my memory serves me right, this didn't use to install as it is a slitaz 3.0 package; maybe this is an updated version-i didn't take careful note of the version that i previously tried to install). Also, tazpkg.conf was also created in /etc/slitaz/tazpkg.conf after installing tazpkg-3.4.tazpkg. I eventually had two ways of calling 'tazpkg convert', either as itself or as 'tazpkg.convert'.
It's probably better to install tazpkg-3.4.tazpkg as it is now installable in slitaz 2.0 (i'm not sure if this became installable after i extracted tazpkg-3.4.tazpkg and followed the steps you indicated). Much thanks for your expertise!
Hi Aleksej What is mysterious for you? I suppose the built-in ability to manage correctly some little things like Debian does (ar and dpkg). I suppose that SliTaz did get that performance from busybox? In the past, it was possible to start correctly debootstrap in SliTaz (debootstrap did require two operators: ar and wget) and get a operable Debian basic core. As I never use some usb stick and have no CD any more (only very old CD's, so I can start SliTaz from Web but Debian; and it is not possible any more to start a Debian installation from Mini-CD using it 'frugal' as the boot file are in the second tree level and Grub can't operate with file in second tree level, I did try to install with debootstrap out a running SliTaz. It did not success. I suppose that our bash / shell are today becoming to be too different!).
I am sorry but it is not a profit for SliTaz to become more isolated from all the other major distribution. It would be a great advantage to be able to complete the own system with Debian or Slackware packages (or Redhat, but this part of the Linux world did become to commercial for me.). It was an error to introduce a own packaging system and not to copy as a slave a preexistent one! Intercompatibility is always an advantage for all!
Why not directly.deb's (or Slackware packages)? Kind regards.
Hi oui, I just can't understand which part of Debian (possible, small part) SliTaz uses. I'm with SliTaz not from scratch — first SliTaz version I've use was SliTaz 3.0.
Ubuntu Debian Packages
And I've not found Debian parts there. Last year I started SliTaz versions 1.0 and 2.0, just out of curiosity. It was too fast to see details, so maybe some Debian goodies was used in that SliTaz versions? As for 'ar' — this type of archive used to 'glue together' static libraries and its configuration files, and you'll find them in the.-dev packages (something like /usr/lib/.a).
I don't knew it's Debian. As for 'dpkg' — yes, it is Debian packages installer. But it is just one of Busybox applet.
I've experimented with it a bit, and it can help to install local.deb package, and remove it. Also, it uses own packages database. But, but — it is not a package manager — it is just a tool that install and remove already download files with.deb format. Seems, SliTaz not uses it at all. But I think it is very promised feature — just to install.deb package in a time of second rather than unpack.deb, then pack.tazpkg, then unpack.tazpkg to install it — it's so long and consumes alot of CPU.
As for SliTaz own packages format — I think we need it as long as SliTaz lives. Own format, own packages allows SliTaz maintainers to control all the compilation and packaging stages of making a package. It allows to have small and fast packages with less unwanted dependencies. Also, it allows to be conservative, and not to switch to the latest 'things', usefullness of that I think, is under question — GTK3, Python3, Qt5, Systemd. And, of course, if you need to install 'alien' package in to SliTaz — you can do it in most cases — Pascal added a large formats support into TazPkg. Oui, thank you for discussion. Hi oui, Sorry, I don'd know your name.
I understand you in general, though not to the end. My English is not very good. Oh, these human destinies! Not everything is subject to us; not everything we can to change; not everything we can choose. Once choosing a destiny, we stay with it forever.
And you have to work for 70–85 hours per week. And no free time. For nothing Oh, fear and terror! But there is something for which this destiny was chosen?! To each his own.
Even not all people have a goal in life. Important, large, the real goal. I really respect people who know what they want in life, people who have a goal and go for it, those who are in daily routine do not lose sight of the distant goal. I respect your son and daughter in law. And I'm just a human being is a pity that they have absolutely no free time. And I understand that you want to show them something.
Professional medical software, right? SliTaz developers have always gone to meet the wishes of users. Just write here on the forum, what programs would you like to see in SliTaz. Point to official site. We are a small number of developers, and we are trying to do what we can. But not all wishes are achievable.
And achieving these desires should be interesting! It's not my job, it does not bring me money, it takes my free time, but it gives me special pleasure. The old Linux slogan — “Just for fun” is the best explains the situation.
This is not a job, spending my free time for SliTaz, I rest. There are too few SliTaz developers. Those who makes changes to SliTaz packages, can be seen in hg.slitaz.org/wok.
Truly the main developer — Pascal, a real professional, a man of deep knowledge in computer subjects. And a few more people who sometimes, from time to time make changes to the packages. Now no orders for new packages, so everyone is doing what he is interested, having received their portion of fun. It's a pity some of the new program is now impossible to compile. A large number of programs to upgrade is not within our power I can try to help, I can do the new software packages for SliTaz, but my possibilities are limited. Since you called one of the programs — gramps — then for sure I decided to make a package.
The package is ready, but it is unlikely it will work. We have pygobject. I did discover an heavy medical free and really high professional software made in France in the web. Also this software is not available at SliTaz. But how to do if I am not a developer to add it in SliTaz? You can start to write the receipt in like that: # SliTaz package receipt. PACKAGE='ThePackageName' VERSION='TheVersion' SHORTDESC='Something from the web site.'
WEBSITE='WGETURL='the download link to the sources' Not sure it will take hours. Nobody will help you without some information about your expected packages. Hi Thank you very much for above very positive answer to my comment (the topic was not my;-); I did require nothing there, only comment the relation between 2 very different distros.). I miss myself geographic applications. On this field, SliTaz offers nothing. Merkaartor is a Belgian application and as it being to be supported by the Francophone community of SliTaz. Unfortunately Merkaartor did be away in the last year for long month but since 15.
March 2015 someone did reinstalle the site: and. Merkaartor is not only a tool for openstreetmap (but is one! Especially for old hardware and little distributions as it does not need java and PC power for heavy java app's) and it allow to produce very good maps of the own environment completely independently of openstreetmap, or to integrate them in openstreetmap. The second Geographic app able to run in SliTaz would be Marble, a kind of 'google earth'.
Today the EU commission did intervene against Google. But, what else?
If you refuse Google, actually, nothing else. No translator, no maps, a poor world because nobody take care to help other producer of software like Marble (Marble is free and open source and participate to the KDE project but is also available as a QT4 app outside of KDE) to acquire a good place in the stage of the software. The third need I meet in SliTaz are spell checking dictionaries. If I use Xombrero in Kubuntu (is the old version xxxterm, but it is the same, see history of upgrades of Xombrero) I can use in the same text dictionaries for 1, 2 or perhaps more languages at the same time. It is the only one Linux program where I am knowing this performance (I am not expert but I did never meet such an offer in other programs!) at writing time! I don't know which spelling dictionaries Xombrero is using. But, as in SliTaz with the same xombrero.conf no spell checking happens, I suppose that SliTaz uses other dictionaries (::).
I did install in SliTaz those I did found in the list of applications being available (aspell as well as aspell-fr, aspell-ru, aspell-etc etc.). I suppose that nobody did take care on this uncomplete but really important mater (for this reason I am writing this message out XXXTERM in Kubuntu else I normaly start my PC in SliTaz! My wife uses only SliTaz since weeks as she only uses German web and is really good in her language and does normally not need some spelling control.
But it is different for me as I am writing in 2 languages being foreing languages for me, English and German!). I find the support for orthography and grammar control is not enough in SliTaz and it is today an important figures of really good software (also here I use Google (again!!!) if I am not certain! We can't live any more without Google because the EU, for us in West Europe, did sleep and do nothing all this time!).
For those not familiar with it, is a very light weight and reasonably fun distribution of Linux that runs well from a Live-CD. I’ve used it on several machines from time to time. My only complaint has been that the main (old) version I’ve run has a horrid orange motif to the desktop (then again, I’ve been too lazy to bother to change it and in Fall it fits right in;-) Well, I found that they have a.
So downloaded it. They also have a version that you can install as a ‘.deb’ package in Raspbian and make the machine dual boot with the SliTaz using the R.Pi SD card but just loading itself into memory. Kinda just what I want some times. Boot to memory, don’t hit the card, but let me access it if desired.
So I decided to try that. ( It is called “dual boot” on this page: ) The install was darned easy. Here I list the files in my download directory prior to the actual install command. The “pilfs” group is the Pi-Linux-From-Scratch that does the compile and build on your box. While that takes 12 hours on the Pi (but might be faster on the Pi.M2) it also means the compile time choices can inspect your hardware and make better choices (like, oh, using hardware random generator or using hardware floating point better or) No, not all builds do that, but some are smart enough to look around and adapt.
So on the “someday todo” is a LFS build. It also means you have YOUR source code to inspect and make sure it isn’t different from the copy you downloaded at that Starbucks back when Then there is the “slitaz” group where you can see the choice of a ‘base’ version (no windows manager) and the “desktop” version that does “do windows”, along with one that ends in armhf.deb file suffix. That’s the one that makes it dual boot. Installing it is near trivial (as seen in the next line with the dpkg command). Took maybe 2 minutes? Simon: Sorry, not following. I didn’t say anything about programming in C.
FWIW, I program in anything that’s needed. Heck, I’d even use FORTH if it was the best fit;-) While C isn’t my favorite, nor my strongest, it’s an OK language.
(Beats the pants of APL and PL/1 and COBOL and even Pascal IMHO. All of which I’ve used to some, often small, degree.) But this posting is about installing a compiled.deb package (that was made from a script, per the web page) and not about writing a C program.
I also have no idea what language was used for the obliquely referenced Intel GPU driver and would not be surprised to find it in C, or not. Finally: No condolences needed, please keep them for those who would benefit I’m pretty much a language agnostic; but I do have “novelty seeking behaviour”, and that means that I like to take a “language dip” into other languages, often. On one occasion that lead me to take a dip into FORTH (enjoyable, if a bit low level for most of what I do) and having learned to program on an Burroughs B6700 that is a stack machine, the stack approach is attractive.
(Also having started with an HP programmable calculator using RPN, I backwards think to tend.;-) so found the approach charming in FORTH). But the world is dominated by register boxes and RPN is not to be found anymore in any common places. Similarly, the use of languages best suited to those machines and the problems they solve tends to larger wordier languages.
FWIW, most of what I do has a significant amount of “shell script wrapper” around it. It is a “threaded interpretive language” where you build up a library of words over time Familiar?;-) In any case, the last “C” I wrote was about a decade back, I think. Since then I’ve mostly just compiled the work of others and occasionally read some of it. But take heart, the JAVA VM is a stack (with one notable exception) machine and Java is pervasive. (But I’ve never needed to learn it and the idea of running a Java VM inside a real OS on a VM instance inside shared hardware in a rack well, it just offends my sense of efficiency) Meanwhile, back at the R.Pi. I’m going to give the chip a try in the R.Pi B+ later tonight (when I don’t need the DNS service, Bittorrent server, etc. That it’s doing now) and see if it works there.
If so, that would make the “fix” easier. (That is highly unlikely to involve C, but very likely to involve scripts and config files). Very interesting post thanks for the update.
I must make time for playing with a Raspberry Pi — maybe soon. I’ve tried a few Linuxes but not Slitaz yet, it looks interesting as it has my favorite desktop of Openbox as it’s standard. May try it over the next few days. So far I have stayed with as it is a simple rolling release that just works for me, (yes I’ve had to hack it a bit to make it fit to my ancient hardware but that’s Linux).
No video player enabled on this box as it just burns-up the Pentium III in this old box, as does commenting on WordPress! Sound works fine via alsa. The other good thing about this Linux release is the people maintaining it are quite conservative about what and how up-dates/upgrades are done (KISS principle and plenty of hand-holding for newbies via their forum). I can’t imagine you would change to it but I thought I’d ‘put it out there’ just in case others were looking for a reliable Linux to try.
OK, I’ve recovered “the chip” to a run-able state again. Basically, I just compared the recently date stamped files on the 8 GB chip that I’d configured first, the 64 GB chip that I installed a half dozen systems onto, and the one that was broken by the slitaz.deb. Then I made a “good guess” about how it worked, and what was likely the broken / missing bit. After looking at a bunch of things, it looks like when you have more than one OS installed, the boot is somewhat different (some things are put in directories named for the OS) and the “conversion” broke the ability of a native R.PiB+ to just boot the regular kernel while at the same time not having a kernel that would work with the R.PiM2. In particular: The kernel run by the Pi B+ (and, one presumes, A and etc.) is named kernel.img. That run by the R.PiM2 is named kernel7.img.
Lol Dual Boot often results in problems. Multi Boot even worse. For those of us not so well versed, a deal killer.
I would think changing the SD chip would be a better way for more normal people to change OS on a RasPi. The SD chip should only contain the OS and needed applications to do the service intended for the device. Thumb Drives for all other files. The computers and chips are inexpensive enough to be dedicated devices.
Keyboards and Monitors are now the main expense. I’m glad you are poking under the hood and I am working on my farming;-).pg. @P.G.: Well, yes and no;-) Since part of my goal is to become versed in “under the hood” I go out deliberately looking for dragons (Better advertising if you can put “Dragon Slayer” on your shield and mean it;-) so when there is a “Here There Be DRAGONS!!” sign out, my response is “Oh Boy! Wax the lance and sharpen the sword, boys, we’re going Dragon Hunting!”.
So, for example, on the 6 way boot chip, I wanted to play with the different OS types and see what they were like. Why blow off 6 chips I I can just use one? And avoid all the chip swapping? IFF it doesn’t work, I can have a little dragon hunting time, and if it does work, I can put “Made 6 way Boot Raspberry Pi just for fun” on the shield and calling card.;-) But it did work, just fine.
Install Debian From Usb
Now when I went to “production”, I did use a different 64 GB card with only the one target OS on it and called it done. At least for a while. (The idea being to build a PXE boot server on the chip and have about 40 GB of “OS of the day” I could PXE boot the Evo to be) But The SliTaz site went out of their way to say that the.deb was designed from the get go to just boot the SliTaz kernel and load their apps into RAM disk and use the Raspbian part of the chip as the file system So more of “boot and a 1/2” than dual boot Well, by definition that needs the Raspbian to be there (They also have a stand alone version that could be a more normal dual boot but I chose the “safe” option.
Lucky me) That, then, mucked up my “production” chip. ( I’d thought of trying it first on the 8 GB stand alone Raspbian that I’d gotten in the kit but was too lazy to swap to it I’d say “lesson learned”, but ) That kind of gave me two choices. 1) Fix the chip. 2) Re-run the build script (with accumulated changes) and re-install all data and customizing. Since #2 is The Microsoft Way, I have trouble choosing it just on principle and since #1 puts more fun stuff on the calling card /.
Shield Well, hey, wouldn’t like another dragon head on the wall Besides, I might learn something. Maybe even to be less lazy and use the experimental chip for experiments Best Practices Per “best practices” for using a R.Pi as a server, I’d basically agree with what you were saying. Blixt v blixt.
Mine had 1 purpose: PXE boot server with the attendant DHCP, DNS, and FTP servers that support it (and are expected to be on the same server). My mistake was do do the “play with Slitaz” function (or “service”) on that chip, instead of swapping to the “play with OSs” chip. I spent the early part of today moving my home directory onto a USB thumb drive (for performance testing – so far noticeably slower than the rotating real disk USB disk but probably the slow cheap PNY USB thumb drive I’m using) That same separation of OS from Data. Yet that data source could just as easily be an FTP or NFS server. (Eventually it will be an NFS server hidden) In that way the OS is a generic thing. And the data unplugs and moves with you.
My early conclusion is that I’ve had faster service from SD cards in an adapter (where the speed is on the chip) and much faster from a “Monster” brand USB thumb drive that I’m likely to move onto later. Find out the speed and reputation of the USB thumb drive before moving onto it; speed varies a lot, as does write wear. (PNY had a couple of ‘talking dirt’ comments on one Linux board. But I had this one already so figured why not test it Hey, even a small dragon counts! ) Later today I’m going to use a 4 GB chip to make a regular R.PiM2 SliTaz system (they have a M2 distro on the site) and try again. I’ll also be making one or two other “dedicated purpose” chips. At least one of them to be a “Live-CD” like “load all into RAMdisk and forget it when done” on the way to a full on TAILS port.
As “someday” I’d like RaTails to integrate into the regular R.Pi build / boot process, time spent on this was just “motivated learning” of what I need to learn anyway Summary: I have a working single boot chip for the PXE server (again). I leaned a bit early things I’ll need for R.PiM2 boot integration anyway.
The intent is to have a few stand alone chips for specific purposes. The multi-boot chip has served the purpose, and will likely be overwritten (now that I know I’m not going to run RISCos or most of the others though only after I evaluate the Fedora and Arch Linux on it a bit more). A home directory on USB stick is done, and will be tested on various systems (likely to be kept, but only after moving to a faster stick on the Evo Chrome browser say s “waiting for cache” a bit too often that is in the.cache directory in your home directory where Chrome packrats pages) The NFS file server is 1/2 done, to eventually provide most systems their more generic spaces. Dividing the world into compute servers, remote provisioned OS copies (locked down), and separately stored data and file systems is the general model.
Everything with a duplicate, backup, or replacement. Eventually data stores to be encrypted media and useless without the right magic sauce For simple uses, like, say, a DHCP / DNS / Time server; just putting it all on one dedicated chip with a backup copy in an EMP proof can is likely more than enough. Since you need DHCP, DNS, and Time to get the other boxes up, it kind a needs to be stand alone. If this is the PXE server, you also get FTP too and your core is built with one chip. (Plus hub or router). The others can then be segmented more into compute hw, remoted OS, remote data (or “cloud” in the new jargon, even if a local personal cloud).
Have you ever seen a longer way of saying: “Yup.”? @Beng135: The “issue” is the way sticks do writes. Large blocks of bits are written in one go, due to the way the chips work (not exactly random access RAM). So if you change one byte in a log file somewhere, you might end up with a 10,000 byte block being re-written. Multiply that by a chatty thing like Chrome browser cache and you can have 100,000 byte blocks read / writing all the time.
That then puts you into ‘wear leveling’ land To prevent wearing out one byte or bit, as some part of the chip get more ‘wear’ than others, the stick starts to move idle blocks to where active had been and vice versa. Now you have more 100,000 bytes of moves going on.
All this makes them a bad choice for things with truly random and frequent accesses for write, like much of the Unix /. The “fix” for this is to make a very compact Linux (definitely NOT a description of Ubuntu or Mint) and pull all the active bits into a “RAMdisk” only flushing through the “union file system” to the backend stick occasionally. That’s what systems like Puppy and Knoppix try to do. BTW, the way to test it is just to compare “running from stick” to running from disk or CD. I’m using a single CPU 2 GB memory 2.5 GHz box right now. From disk, it’s just dandy.
With JUST my home directory on the stick, it is still Just Dandy except Both Chrome (that has a.cache fetish) and IceWeasel (that isn’t telling me where it’s writing bits) have sporadic hangs as they try to dump a load of “something” into “somewhere” and end up waiting on the stick. “Top” shows that system in “wait” state for IO as the typing in the comment window hangs and in Chrome it puts up a line of text at the bottom of the screen saying “waiting for.cache” that is in my home directory So this has told me I either need a much faster stick, or use a RAMdisk build.
FWIW, I was using a 64 GB SD Class 10 chip as my home directory including Outlook Mail when forced to live on a Windowz box and it was just fine. Don’t think Windows is any less chatty, so I suspect it is either a different write method, or just a much faster chip. Later today I’ll be trying a “Monster” stick with fast I/O rating and then, if needed, that 64 GB chip on Linux. Aren’t you glad I’m doing this and not you?;-) As it is, the “annoyance” is more than I’d want for a regular experience, but livable for a system where I wanted to be able to “pull the plug” in a hurry.
I’ve also run distros from USB built with RAMdisk / ufs and found them very comfortable. Several Live-CD versions too. And on much slower machines than yours. So I suspect it was the distribution of Linux you used and not your computer, and then a slow stick.
(Since they don’t advertise their speed ratings, some are quite slow for small file read / writes. Then when they do put speed, it is often XX/Mb/second and doesn’t say if that’s for ONE 1 MB file, or 1000 small file random writes and that matters.) Eventually we’ll get really fast really random USB sticks suited to this use. For now, it’s a mixed bag and “go fish”. @Beng135: Details in: You are most welcome! (And glad you got a chuckle) It is important in programming / sys admin to keep a sense of humor; otherwise you start thinking about what 2 KV at a few dozen KVA can do;-) Per the “tangled mess”: Happens to us all.
When I have that “hit the wall” moment, I stop and have a cup of coffee or tea. If that doesn’t work after a couple of tries, I have a glass of wine or beer. If that doesn’t work after a few tries, it’s tomorrow and I’ve forgotten what was the problem and have a whole new outlook on the task since everything from before is now lost to distant mists 8- And it IS an adventure and like all adventures not always what was expected at the start.
Recent Posts. Recent Comments on on on Larry Ledwick on Larry Ledwick on David A on Larry Ledwick on on Tony Hansen on Larry Ledwick on. Categories. (69). (180). (52).
(40). (296). (57). (16). (9). (11). (44).
(159). (352). (70). (46). (75). (1).
(10). (111). (14). (64). (12). (67). (296).
(43). (15). (3). (86).
(102). (7). (44). (465).
(23). (212). (3). (19). (11). (281).
(27). (9). (10).
(65). (86). Postings By Date.
TazPkg is a Linux package manager used. Learn how to install, list, download, update or remove precompiled packages with this cheat sheet for TazPkg. List List packages installed on the server. # tazpkg list # tazpkg list cat categories # tazpkg list blocked xhtml-list The xhtml-list command creates a XHTML list of all the packages installed on the server: # tazpkg xhtml-list # tazpkg xhtml-list list-name.html list-mirror List packages available on the mirror: # tazpkg list-mirror # tazpkg list-mirror -diff info Display any information available for the package: # tazpkg info busybox desc Description of the package (if it exists): # tazpkg desc busybox list-config Lists the system configuration files.
The –box option displays in table format: # tazpkg list-config # tazpkg list-config -box list-files List all files installed with a package: # tazpkg list-files bc search Search for packages by owner or package name: # tazpkg search gcc search-file The search-file command allows you to search for a file among the files installed by the packages: $ tazpkg search-file libnss install This command allows the installation of a local package with the.tazpkg extension.