oui.
For the record, Midori being a "very light" browser is an illusion. It requires LLVM and the
libgtkwebkit (99Mb's combined). Believe me if you will, but it is true.
Go double-check. Your hopes up in smoke, eh?
Puppy's big problem with woof and woof CE
-
oui
is that your first official critic against the choices taken in the last new dpup and installing midori 7 (and without solution to see youtube)?musher0 wrote:oui.
For the record, Midori being a "very light" browser is an illusion. It requires LLVM and the
libgtkwebkit (99Mb's combined). Believe me if you will, but it is true.
Go double-check. Your hopes up in smoke, eh?
I did look in my try in Upup64: Seamonkey has exactly 100 Mb UNPACKED, no external files (but no dictionaries, only links to hunspell, where they are really needing for text processing etc.), no limits concerning HTML5 or youtube etc, and offers the classic HTML4 editor with spell check, and the full email client, being, on top, needing in Midori to be really equivalent
.bad deal really as Midori 4 do the same (all the SliTaz distro is, of course squashed, only 50 Mb light, with Midori in it), and, if the developers are fit, THAT midori 4 can handel HTML5 and youtube, you have seen my print screen (today a lot of Puppy's have not the same luck...)
are you becoming an opponent to your new lovely distro buster?
Come on guys. Even pretty old computers come with a few GB of storage space. The amount of space (40MB or 400MB) a distribution occupies on that is really irrelevant (and more and more so nowadays). What remains relevant in how much RAM the distributions uses, where such RAM remains quite limited on older but still useful computers (say 1 or 2 GB RAM machines). And the other important issue is browser speed (page rendering and so on).
So, important tests are:
1. How fast does the browser render web pages.
2. How much RAM does the browser occupy before loading any pages.
But most important of all really:
3. How many tabs containing high-load pages (such as gmail pages) can a browser open before it crashing owing to physical RAM running out (note that this is likely more a problem of heavy web pages than the browsers themselves - if webpage eats memory I guess there is not a lot the browser can do about it ).
There is probably one very good reason for a small distribution to be particularly nice: it can all be loaded in limited RAM with still enough RAM left to do useful work. And even old systems work fast when programs_and_OS are already in RAM (new systems can have very fast external SSD drives anyway, so not so important to load into RAM anyway). Slitaz is great for that (it uses lots of RAM actually but that's cos all of it is, by default anyway, loaded into RAM even on quite low RAM systems). On systems with more RAM, bigger distros (like Pup or the Dogs) can also be competely loaded into RAM and still usable (though browser heavy web pages do quickly use up a lot of RAM per tab opened).
So, for me, the point/use of Slitaz and any tiny assembled distro is that it will run very fast on low RAM limited systems when a bigger distro would need slow access to external drives all the time (including often a lot of swap space usage - i.e. swapping pages in and out between RAM and external storage).
So, nice if WOOF-CE also included as tiny a Puppy as possible - I don't think that can be achieved with Pups build from straight Debian or Ubuntu repositories though - too many dependencies (including big libs) - too big compiles - too many included docs. For small systems, Slitaz currently unmatched, but persistence/save capability of Slitaz is very limited. Tazpup addresses that lack by using Puppy boot/save mechanisms, but at increase of size cost. I imagine Tazpup could be slimmed down since some Slitaz functionality not needed since has Pup alternatives. But since it uses components from current pup maybe some libs or other pup-borrowed components are bigger than they need to be? - I don't know. I can't see that Tazpup iso size needs to end up twice the size of its underlying Slitaz tho, well, except I guess Tazpup is currently providing Xorg? and full, not busybox, bash shell?
wiak
So, important tests are:
1. How fast does the browser render web pages.
2. How much RAM does the browser occupy before loading any pages.
But most important of all really:
3. How many tabs containing high-load pages (such as gmail pages) can a browser open before it crashing owing to physical RAM running out (note that this is likely more a problem of heavy web pages than the browsers themselves - if webpage eats memory I guess there is not a lot the browser can do about it ).
There is probably one very good reason for a small distribution to be particularly nice: it can all be loaded in limited RAM with still enough RAM left to do useful work. And even old systems work fast when programs_and_OS are already in RAM (new systems can have very fast external SSD drives anyway, so not so important to load into RAM anyway). Slitaz is great for that (it uses lots of RAM actually but that's cos all of it is, by default anyway, loaded into RAM even on quite low RAM systems). On systems with more RAM, bigger distros (like Pup or the Dogs) can also be competely loaded into RAM and still usable (though browser heavy web pages do quickly use up a lot of RAM per tab opened).
So, for me, the point/use of Slitaz and any tiny assembled distro is that it will run very fast on low RAM limited systems when a bigger distro would need slow access to external drives all the time (including often a lot of swap space usage - i.e. swapping pages in and out between RAM and external storage).
So, nice if WOOF-CE also included as tiny a Puppy as possible - I don't think that can be achieved with Pups build from straight Debian or Ubuntu repositories though - too many dependencies (including big libs) - too big compiles - too many included docs. For small systems, Slitaz currently unmatched, but persistence/save capability of Slitaz is very limited. Tazpup addresses that lack by using Puppy boot/save mechanisms, but at increase of size cost. I imagine Tazpup could be slimmed down since some Slitaz functionality not needed since has Pup alternatives. But since it uses components from current pup maybe some libs or other pup-borrowed components are bigger than they need to be? - I don't know. I can't see that Tazpup iso size needs to end up twice the size of its underlying Slitaz tho, well, except I guess Tazpup is currently providing Xorg? and full, not busybox, bash shell?
wiak
Last edited by wiak on Wed 27 Feb 2019, 23:30, edited 1 time in total.
-
oui
all precedent reasonings of wiak are true.
but a detail has a highly importance: how much web indirections can create the opening from only one unique web page (news paper etc. frequently a terrible number you see if the browser is build in with a strong close of that and you or the webmaster or the author crew of the browser demand your approvals for each indirection. this correspond often with the usual pre settings for Konqueror, but of course, puppyists don't really often meet konqueror in the praxis)... this depends also dramatically from use or not from somewhat like an adblockler and how strong you did have to set it on to permit to see all your prefered pages without restrictions as the redirections are, it so, the payment that the page owner require from you to supply the service financed by publicity...
what is the result?
the hidden ~/.cache subdir in your "home" grows and grows and grows!
today I did enter the web at 19 h 30. the laptop was shutdown. I did start live full in RAM with bionicpup64 version 7.9.8. and as I never use some save file or dir, no /root/.cache present at starting point (I did check it!)
following printscreen has the date today 23.37. And we did have lunch an hour between this time! The at starting point (of the browsing activity) created .cache did grow until
126 MB!
I did look into the subdir: the big content was a second hidden subdir named "mozilla" (not /root/.mozilla but /root/.cache/mozilla !)
I did look into an available full installation (as I did rapport often from SliTaz in the last hours, a full install from SliTaz: The full install did need, all included 3,3 Gb, but the /user/tux/.cache/mozilla alone
1 Gb ! (so that the real net size of the full installation was under 2,3 Gb!)
This is in my eyes a MAJOR LIMITATION for PC's working in RAM-mode only!
The function using ~.cache is highly problematic!
Is that function needing? What does it concrete FOR the user?
(Note: they are more subdir in ~.cache of the full install. for ex. fontconfig, menus, midori, mozilla, openbox, webkitgtk and readme saying ~/.cache/ - User cache directory XDG variable: XDG_CACHE_HOME. But the content of all other is low. Of course, I am not really an user of midori, In the other case, it would perhaps be different!)
but a detail has a highly importance: how much web indirections can create the opening from only one unique web page (news paper etc. frequently a terrible number you see if the browser is build in with a strong close of that and you or the webmaster or the author crew of the browser demand your approvals for each indirection. this correspond often with the usual pre settings for Konqueror, but of course, puppyists don't really often meet konqueror in the praxis)... this depends also dramatically from use or not from somewhat like an adblockler and how strong you did have to set it on to permit to see all your prefered pages without restrictions as the redirections are, it so, the payment that the page owner require from you to supply the service financed by publicity...
what is the result?
the hidden ~/.cache subdir in your "home" grows and grows and grows!
today I did enter the web at 19 h 30. the laptop was shutdown. I did start live full in RAM with bionicpup64 version 7.9.8. and as I never use some save file or dir, no /root/.cache present at starting point (I did check it!)
following printscreen has the date today 23.37. And we did have lunch an hour between this time! The at starting point (of the browsing activity) created .cache did grow until
126 MB!
I did look into the subdir: the big content was a second hidden subdir named "mozilla" (not /root/.mozilla but /root/.cache/mozilla !)
I did look into an available full installation (as I did rapport often from SliTaz in the last hours, a full install from SliTaz: The full install did need, all included 3,3 Gb, but the /user/tux/.cache/mozilla alone
1 Gb ! (so that the real net size of the full installation was under 2,3 Gb!)
This is in my eyes a MAJOR LIMITATION for PC's working in RAM-mode only!
The function using ~.cache is highly problematic!
Is that function needing? What does it concrete FOR the user?
(Note: they are more subdir in ~.cache of the full install. for ex. fontconfig, menus, midori, mozilla, openbox, webkitgtk and readme saying ~/.cache/ - User cache directory XDG variable: XDG_CACHE_HOME. But the content of all other is low. Of course, I am not really an user of midori, In the other case, it would perhaps be different!)
- Attachments
-
- cacheProblem.jpg
- (28.9 KiB) Downloaded 329 times
I'm not on Linux just now, oui, but I suspect, when system is RAM-only, that cache size will shrink and grow automatically depending on how much physical RAM system actually needs. In general cache usage tends not to be problematic for that kind of reason. In practical terms, I mean that Slitaz will not crash or slow down because of that cache growing too big.
I could well be wrong.
wiak
I could well be wrong.
wiak
-
oui
Hi wiak
I answer better here this part of your answer to me in the other thead:
where is would be important, in the field of the user languages because so much points have to be taken in consideration, the big Puppy did years along nothing and today it continue to be so, that in no one "help" from JWM menu you will find the url needing to localize your system (and only sometime at an other logic place like icon on the desk for installations complements), where SliTaz "the light" ALWAYS did propose immediately (before the installation) a choice between the 3 Swiss languages DE-FR-IT, as created first in Swiss, and, over that, EN...
to critic SliTaz because it continues to offer only a few modules for Xorg is ridiculous. It starts with the Xorg module also named Xvesa but not the old Xvesa...
If you know (my own situation!) that this will be problematic by first start (with INTEL, nobody in LINUX likes INTEL!), you add in the grub menu / .cfg at the end of the line for the kernel the command
screen=text
and you start even in pure text mode where you can immediately reinstall xorg using
tazx
(the packages list loading happens automatic...) ans select reorganize xorg!
i find it is an adequate solution not to overload the ISO and the squashed system going into the RAM, it is more important, as the most users really never will use a lot of xorg modules!
.orthography
I answer better here this part of your answer to me in the other thead:
SliTaz handles right! The full installation of all modules for xorg (or for all printers) etc. is nonsens! The installation grows (not so much as in the past, in the past it was terribly more as Xvesa was yet separate and all modules were more heavy) but, big or not, it is nonsens because on one terminal you will meet only a need for one module that most of the linuxians know before they start their installation (I, for ex., need "intel"). Same thing for CUPS and it's filters. You generally have not so different printers in use. My Brother-HL-2035-hl1250.ppd is on my HD. No need to install all the gutenprint cram...wiak wrote: Regarding distribution 'size', I still feel the use of Xorg in Puppy (and only Xvesa in Slitaz) is one major reason for difference between Pups and Slitaz - and probably cut-down lib set in Slitaz - I don't know. What Slitaz provides in such a small iso is certainly amazing (similar to what tiny core can do, albeit with a lot of tinkering required in tiny core to achieve user-quality provided by Slitaz). But more generally, I also tend to feel that distribution size isn't so important (even my 2GB 2008 machine works perfectly fine with larger distributions) - 100MB, 200MB, 500MB, doesn't make a lot of difference on most machines (and once you install larger apps/Xorg etc, size soon becomes similar...): what is important is RAM used when running apps (in terms of machine slowing down, swap being uses, or system crashing). Doesn't seem to matter what size of distribution you use in that regard - problem is the browser experience and moreso the heavy coded web pages, which suck RAM for every tab used.
wiak
where is would be important, in the field of the user languages because so much points have to be taken in consideration, the big Puppy did years along nothing and today it continue to be so, that in no one "help" from JWM menu you will find the url needing to localize your system (and only sometime at an other logic place like icon on the desk for installations complements), where SliTaz "the light" ALWAYS did propose immediately (before the installation) a choice between the 3 Swiss languages DE-FR-IT, as created first in Swiss, and, over that, EN...
to critic SliTaz because it continues to offer only a few modules for Xorg is ridiculous. It starts with the Xorg module also named Xvesa but not the old Xvesa...
If you know (my own situation!) that this will be problematic by first start (with INTEL, nobody in LINUX likes INTEL!), you add in the grub menu / .cfg at the end of the line for the kernel the command
screen=text
and you start even in pure text mode where you can immediately reinstall xorg using
tazx
(the packages list loading happens automatic...) ans select reorganize xorg!
i find it is an adequate solution not to overload the ISO and the squashed system going into the RAM, it is more important, as the most users really never will use a lot of xorg modules!
.orthography
Last edited by oui on Thu 28 Feb 2019, 13:29, edited 5 times in total.
-
oui
Hi wiak
thank you for that statement!wiak wrote:I'm not on Linux just now, oui, but I suspect, when system is RAM-only, that cache size will shrink and grow automatically depending on how much physical RAM system actually needs. In general cache usage tends not to be problematic for that kind of reason. In practical terms, I mean that Slitaz will not crash or slow down because of that cache growing too big.
I could well be wrong.
wiak
ITSMERSH wrote:There's still Plop Bootmanager to boot old Computers from CD and then to choose another boot option from the Plop Menu. That way e.g. one can boot from USB flash drive on very old computers.
As I wrote, I have some old PCs which can read a CD, a few only have early USB. I have not had money to buy new equipment, and I see no reason to throw away a working computer.
Intereresting fact? No, not really, because that is how all my live Puppys always have run. As a matter of fact, as I wrote in an earlier post, that is how Puppy was designed to run; a single user, as root, from RAM.wiak wrote:Slitaz is great for that (it uses lots of RAM actually but that's cos all of it is, by default anyway, loaded into RAM even on quite low RAM systems).
And I don't need any storage space at all to run Puppy, but the advantage of having a small HDD, is that you can have a healthy swap partition on it, which allows you to run large apps with little RAM.
But then again, I must correct myself. Earlier Puppys didn't need any storage space, because you could save your session to the multisession CD that contained the .iso, BUT THAT OPTION WAS DELETED SOME TIME AGO IN THE WOOF CEs!
True freedom is a live Puppy on a multisession CD/DVD.
-
ITSMERSH
Probably this removal is just a bug or accident.But then again, I must correct myself. Earlier Puppys didn't need any storage space, because you could save your session to the multisession CD that contained the .iso, BUT THAT OPTION WAS DELETED SOME TIME AGO IN THE WOOF CEs!
Yesterday I made a remaster of BionicPup64 7.9.6 (which I already remastered before) to try to apply some fixes from 8.0 to 7.9.6.
Accidentially I deleted /etc/rc.d/PUPSTATE and replaced it with an almost empty version from read only mounted BionicPup64 8.0. The remaster script then complained about running in PUPMODE=2, so unable to remaster.
Since the original PUPSTATE wasn't recoverable I just changed that PUPMODE=2 to PUPMODE=5 and did a remaster successful.
Though, at next boot a message appeared on the screen which said I'm NOT booting from a multi-session cd. After hit enter it booted fine, though. So, the ability to boot a multi-session cd/dvd seems to be still implemented, which makes me think it's just a bug that you can't save anymore to a multi-session cd.
My I suggest to get in contact with the woofCD stewards (I don't like this term...).
Hi, "ITSMERSH".
If you want to go to the moon, please feel free!
Well, I just ran nanolinux, and it's quite nice. And worth it, if only for the excellent PIM
called "The Daily Journal".
Funny anecdote: it is so small that when PBurn burned it to DVD, it froze -- well, maybe just
"hanged". To make sure, the copy was ok, I made another burn withAnd it too sort of did not know what to do after the first sector was burnt.
But the burn booted to desktop ok.
BFN.
If you want to go to the moon, please feel free!
Well, I just ran nanolinux, and it's quite nice. And worth it, if only for the excellent PIM
called "The Daily Journal".
Funny anecdote: it is so small that when PBurn burned it to DVD, it froze -- well, maybe just
"hanged". To make sure, the copy was ok, I made another burn with
Code: Select all
cdrskin -v dev=/dev/sr0 blank=as_needed -eject padsize=300k $1But the burn booted to desktop ok.
BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Thanks for the nanolinux pointer musher0.
I frugal'd it. Copied the cde folder inside the iso to the root hdd as folder name tce, copied the initrd (corepure64.gz) and kernel (vmlinuz64) files into /nano and I setup a grub4dos menu.lst entry for 60x480 resolution ...
title nano
root (hd0,0)
kernel /nano/vmlinuz64 loglevel=3 cde vga=0x321 showapps multivt quiet
initrd /nano/corepure64.gz
Booted, used the image viewer, loaded dillo and logged into puppy linux forum, took a screenshot ..etc. OSS playing OK (radio player and mp3's, but starts at max volume (ouch!). Also right headphone normal, left - low volume.
I frugal'd it. Copied the cde folder inside the iso to the root hdd as folder name tce, copied the initrd (corepure64.gz) and kernel (vmlinuz64) files into /nano and I setup a grub4dos menu.lst entry for 60x480 resolution ...
title nano
root (hd0,0)
kernel /nano/vmlinuz64 loglevel=3 cde vga=0x321 showapps multivt quiet
initrd /nano/corepure64.gz
Booted, used the image viewer, loaded dillo and logged into puppy linux forum, took a screenshot ..etc. OSS playing OK (radio player and mp3's, but starts at max volume (ouch!). Also right headphone normal, left - low volume.
- Attachments
-
- screenshot1.png
- (43.89 KiB) Downloaded 141 times
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
Hi rufwoof.
T'is nothing at all, don't mention it.
But here's a piece of trivia, if I may.
Nanolinux' hummingbird logo jogged my memory a bit. That's why I noticed it. There
used to be a non-Linux (?) distro called Kolibri (10 years ago?). Same concept,
everything very small. To that Kolibri distro, our BarryK contributed some Assembly
code, IIRC. Maybe some of his material is still in this Nanolinux-1.3?
It think it unlikely there would be two Assembly code programmers named Barry Kauler
with the same penchant for tinyness.
BFN.
T'is nothing at all, don't mention it.
But here's a piece of trivia, if I may.
Nanolinux' hummingbird logo jogged my memory a bit. That's why I noticed it. There
used to be a non-Linux (?) distro called Kolibri (10 years ago?). Same concept,
everything very small. To that Kolibri distro, our BarryK contributed some Assembly
code, IIRC. Maybe some of his material is still in this Nanolinux-1.3?
It think it unlikely there would be two Assembly code programmers named Barry Kauler
with the same penchant for tinyness.
BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Depends how much RAM you are talking about having on your system. Slitaz will run in RAM on very low RAM machines (maybe 256MB RAM - can't remember and can't test Slitaz again right now) - modern Puppies wouldn't fit in such a space once decompressed. As I said "even on quite low RAM systems". Of course you can run Puppy, DD, FatDog, whatever in RAM if you got plenty RAM (and can indeed use HD for swap if you have modern HD - older machine's Hard Drives mean that using swap slows your machine to a crawl... but if plenty RAM, as in relatively modern machine, why use swap anyway). So how much RAM do you have on the main machine you are loading modern Puppy into? And how old is the machine/fast is the hard drive?tallboy wrote:Intereresting fact? No, not really, because that is how all my live Puppys always have run. As a matter of fact, as I wrote in an earlier post, that is how Puppy was designed to run; a single user, as root, from RAM.wiak wrote:Slitaz is great for that (it uses lots of RAM actually but that's cos all of it is, by default anyway, loaded into RAM even on quite low RAM systems).
Anyway, maybe this is going off-topic, except I feel that it would be nice to have small distro version of Puppy (not using big distro apps etc) so that it can be run in older low RAM machines - but maybe that is the past.
wiak
-
ITSMERSH
Just checked the current "init" in woof-ce, support for pupmode=77 (Multisession CD/DVD) is still there.tallboy wrote:Earlier Puppys didn't need any storage space, because you could save your session to the multisession CD that contained the .iso, BUT THAT OPTION WAS DELETED SOME TIME AGO IN THE WOOF CEs!
But I seem to remember there being some doubt about the switch to a new CD/DVD when the current one is full, working.
gyro
This assessment is for Fatdog, but I believe Puppy will perform similarly, if not better.Anyway, maybe this is going off-topic, except I feel that it would be nice to have small distro version of Puppy (not using big distro apps etc) so that it can be run in older low RAM machines - but maybe that is the past.
Firstly, as far as I know, no 64-bit machines comes with less than 1GB of RAM, however I set my sights lower and use a hypothetical machine with 384MB with 512MB disk (harddisk, not USB flash drive).
I remaster FD with nano-initrd (kernel-modules and basesfs outside initd - similar to zdrv and pup.sfs outside of initrd in standard Puppy). These files aren't loaded into RAM (similar to pfix=nocopy).
I booted the remaster. I used gparted to partition that 512MB disk into two:
a) sda1 is 256MB swap
b) sda2 is 256MB savedir
Then I activated the swap on sda1 (swapon /dev/sda1).
I launched seamonkey (=known to be a memory hog and not exactly the swiftest browser).
I watched a movie trailer in youtube. It worked well enough. Of course there are delays, but it worked well enough for me to actually be able to watch it. In full screen.
I shutdown the machine, and then reduced the RAM to 256MB, and boot it again. I could still do the same thing, though the video became choppy at the beginning and the webpage wasn't responsive as it was being loaded; and there was noticeable delays between mouse-clicks to the action.
Now, for the record, I tested in qemu. The "harddisk" performance in qemu is probably better than the real ones; and the CPU is one of the recent ones, so I can't really claim on the responsiveness performance; however, the point is to show what is possible with modern Puppies on a very RAM-limited systems - it still can run and work.
That being said. Years ago I attempted to run Puppy 3.0.1 on 128MB Pentium 3 machine (or was it Pentium 2, can't remember). I can't remember the size of the harddisk but it was certainly not big, however big enough for me to create a 64MB (or was it 128MB) swap file. How did it perform? The word "horrible" came to mind. It was too slow to be unusable, delays with every single action. So the "good old days" isn't always as good as we remember it.
Anyway. Small OS is always interesting and has their place. But I believe they fit a very small niche nowadays, because these days small almost always means "very specific". Slitaz for example is a very polished small distro (I've looked at its build system and it does some very interesting tricks to squeeze the very last byte), however it's "key" application is a web browser. That's fine if all you want to do is browsing and using online apps. But once you need to do something else, then you start installing the packages and the size grows.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
I don't really care too much about the size distribution is taking up on my hard drive (despite my machine being from around 2008, still it has 2GB RAM and an old 80GB SSD). With XenialDog64 I basically use a remastered/swollen 01-filesystem.squashfs of size 1GB, but owing to me continually trying out programs and dev systems, it is currently taking up 2.5GB on my HD, so hardly tiny...
I also have the latest Pups on my drive, including most recent DPupBuster for testing, and also FatDog-800 final, which takes very little room on my HD (around 415MB) which is exemplary considering it includes Libre Office, gimp and more.
So yes, very small distro's are a special niche - nice to play with, and Slitaz certainly does a great job extracting every drop of utility out of the Midori version it includes.
My 80GB SSD Hard Drive certainly proves too small (I'm continually running out of space on all the partitions I've created on it. Of course I could fork out and buy a bigger drive but don't feel the need for such an 'extreme' measure. Rather, I'm currently offloading some of the junk I've accumulated (I no longer remember what much of it even is...) onto my external 1TB usb hard drive. That affords me the space to try out other distros again, and maybe even update and re-test makepup to cope with the new distros appearing on woof-CE github site (I do hope newer distro that are being woof-CE built will have their configs uploaded to woof-CE github soon though because, currently, it is a bit of a pain re-configuring makepup to know about new ones).
wiak
I also have the latest Pups on my drive, including most recent DPupBuster for testing, and also FatDog-800 final, which takes very little room on my HD (around 415MB) which is exemplary considering it includes Libre Office, gimp and more.
So yes, very small distro's are a special niche - nice to play with, and Slitaz certainly does a great job extracting every drop of utility out of the Midori version it includes.
My 80GB SSD Hard Drive certainly proves too small (I'm continually running out of space on all the partitions I've created on it. Of course I could fork out and buy a bigger drive but don't feel the need for such an 'extreme' measure. Rather, I'm currently offloading some of the junk I've accumulated (I no longer remember what much of it even is...) onto my external 1TB usb hard drive. That affords me the space to try out other distros again, and maybe even update and re-test makepup to cope with the new distros appearing on woof-CE github site (I do hope newer distro that are being woof-CE built will have their configs uploaded to woof-CE github soon though because, currently, it is a bit of a pain re-configuring makepup to know about new ones).
wiak