Okay, here's why I've been quiet for a few days...
(very) Experimental 'RawPup'
becoming concerned with how bloated Puppy has become. Yes, I know 98MB
is still small, but the size is big enough to prevent loading totally
into RAM on older hardware.
So, in a mad moment I decided to
reinvent Puppy from scratch. Please do note though, this is just an
experiment, it does not invalidate the current puppy3 series, which
certainly has it's place. I'm working on this as a parallel project.
used T2, their 'trunk' branch, which has the latest packages, and
compiled a basic system with only the minimum required packages. Some
major decisions: GTK2 and QT4 only, no Tcl/Tk, no GTK1. Xvesa only. I
considered every package in Puppy, and ruthlessly threw it out if I
considered it not essential.
Raffy posted some information
awhile back about a site with many Qt applications, that mostly need
Qt4, and I was pleasantly surprised at how many there are. I considered
creating a Qt4-only Puppy, no GTK2, but that isn't practical (yet) as
we have so many utility programs that need GTK2. So, I'm using GTK
2.12.1 and Qt 4.3.2. Xorg is 7.3, but using only the Xvesa (or Xfbdev)
servers from that package.
I'm not happy about the size of the
'zdrv' file either. Although it does not have to load into RAM, it
still makes the live-CD bigger. It has a lot of stuff that is very
esoteric, and I have created an option in Unleashed to cut it down
somewhat -- from 18MB to 9MB (note: all networking drives are retained,
as well as firmware). The bigger file could still be made available
separately -- if placed on the hard drive at same place as the
'pup_save' file, Puppy will use it.
My daughter bought me a
digital camera for Father's Day, a Fuji Finepix, and despite the online
FAQ, this particular model appears not to have a standard USB mass
storage interface. So, I need the 'libgphoto' package, plus one of the
GUI apps that go with it.
I also want scanning out-of-the-box, so I threw in the 'sane' package.
I have built right now is a 70.5MB live-CD. It has SeaMonkey 1.1.4,
GTK2, Qt4, libgphoto, sane, MPlayer, CUPS, flashplayer, perl, and all
the usual libraries such as ffmpeg, sqlite, etc.
What is missing are
some major applications like Abiword, Gnumeric, etc. -- I'll put some
of those in later. I will be considering some Qt alternatives.
Abiword and Gnumeric, with all the plugins, would add about 5MB. So, if
I add those two apps, the iso file goes up to 75.5MB. The Qt4 package
is about 4MB. If I have those two apps and remove Qt, we would get
about 71.5MB. A final usable Puppy would need graphics, chat and other
smaller apps, perhaps adding another 3-5MB. SeaMonkey is about 13MB,
Opera about 7MB, so very roughly, a iso with Qt and Opera, no
SeaMonkey, Abiword, Gnumeric, some extra apps, would be about 72.5MB --
the 'pup_xxx.sfs' file that loads into RAM would only be 72.5-9-1 =
62.5MB. I'm aiming to get this pup to load into RAM on a 128MB PC, with
enough space left over for the apps to run, just like the old days.
now I'm waiting on the Opera developers to make a Qt4-build available.
They do have such a beast, just haven't uploaded it yet. Then we'll see
what size we get, with Opera instead of SeaMonkey! Probably if we
wanted to get down to 50MB, taking out libgphoto and sane also would
help very much.
I haven't actually tested this thing yet. Righto, I'll keep playing!
soon I'll create an actual working live-CD and will upload it. The
'devx' file has been created and I'll make that available also. This
first RawPup is codenamed 'piglet' (my daughter's dog Vincent has
acquired the nickname piglet).
I would miss Xorg, no hardware video acceleration :( , no synaptics touch pad driver.
the size of the zdrv file; is download size that big of a factor? Some
other reason? Personaly I wouldn't mind seeing more included in the
ISO, like sane, libgphoto, and now maybe Xorg. Just loaded on demand,
otherwise left on the CD. Mainly the kind of stuff you need to get all
of your hardware working.
I like Seamonkey, but the 40MB package does seem rather big. Don't think you'll beat Abiword and Gnumeric.
Current Puppy using Slack packages is appealing in many ways, but I
don't think small and efficient was on the mind of the Slackware
Anyway, sounds like fun!
Great direction to take, Barry!
am entirely unconcerned about the size of zdrv. It after all was
supposed to hold everything but the kitchen sink, and has nothing to do
with the size of a running Puppy.
Glad to see the experimentation with Opera even though I know little about it. Bloat in Seamonkey is irritating me too.
I think gnumeric and abiword are essential.
could get along just fine without Xorg; worked for a long time just
using Xvesa and can't really tell the difference in my computer, except
for that minor irritation with capslock. Maybe my eyes are bad!
is encryption still in it? Leaving it out would be a deal-breaker for
me. As to Gtk2, Qt4, etc. I have no clue what makes sense.
when things were starting to get boring. Though without Xorg it would
be useless to me, so it would be nice were an Xorg PETget available
(assuming that the package from 3.xx isn't compatible).
Congratulations on grasping the nettle! Always a good idea to stand
well back and see the big picture. No big deal if a few kiddies with
the go-faster stripes on a proprietary box can't live with progressive
thought. 50M may be more of a magic target than a magic number!
I don't think the 100MBish size is a problem until you combine it with
a roughly six-eight week release cycle. I realise that's your decision
and that's fair enough too, like many others I just DL every fourth or
fifth one if it looks interesting and everyones happy. But if I were to
keep up then 'maintaining' puppy would require a lot more downloading
than Windows Update, which doesn't make sense to me in a minidistro.
I have been using puppy a little while, long enough that if I was going
to do my own derivative I have a bit of an idea of what I would try.
That said though, I'm still very much a linux noobie so maybe it's not
all technically feasible. It's basically another 'rearrange the sfses'
scheme but I think some parts are new - sorry if they're all old news,
hopefully some of it will be interesting to you.
So [i]if[/i] I had the time and knowledge this is what I would do...
1. Puppy would be three sfses
a. PuppyCore_###.sfs. (30MB loaded in RAM?) Absolute core kernel,
libraries, scripts, network, Xvesa. In other words something like the
various Barebones type puplets that have X but no applications.
b. PuppyZDrivers_###.sfs. (20MB loaded on demand?) As is now, maybe enlarged for more complete kit.
c. PuppyApplications.sfs (50MB loaded on demand when RAM is low?)
Basically all the applications, resources etc that are currently in
pup_###.sfs but didn't make it to PuppyCore
2. Puppy Petget would be enhanced
a. Petget Manager would live in PuppyCore.
b. Anything new the user installed by Petget would go into PuppyApplications.sfs.
c. Petget settings would also be in PuppyApplications, and it's
Installed Applications list would include [i]all standard ones that
were in the original distro[/i] so you could easily remove them if you
wanted to (currently things like seamonkey and all the other standards
are not in the installed list).
d. Distributing applications by
sfs would be discouraged, but Petget would have ability to install and
uninstall 'metasuites' (collections of apps, data like devx)
It would have a feature, where whenever you upgraded PuppyCore it would
check status of all registered applications and advise/help to upgrade
them as needed.
3. Finally pup_save.#fs would become more portable between puppy versions (I think you are doing this anyway)
a. I think at the moment when a user installs an app it goes into
pup_save(?), so maybe there would be issues with putting them into a
b. It is likely that PuppyCore and PuppyApplications
would both contain stuff that would go into common directories like
/usr/bin etc. I don't know if unionfs would allow this?
If the above were possible it would cut the downloading significantly, because to keep up to date it would just mean
* DLing PuppyCore frequently
* DLing PuppyZDrivers occasionally (eg for major releases or kernel changes)
* DLing PuppyApplications rarely, because it would basically become
your own set of applications that you could just plug into any puppy
version within reason.
Also it would be possible to have several
flavours of puppy or alternate puplets easily maintained, because it
would just mean having a series of different PuppyApplications.sfses
that don't need changing for every update.
Anyway that's my 20c, hope you find some of it worth reading, if not I guess I'll have to try myself one day
think it's great you're thinking "lean & mean". I'll bet 95% of the
Puppy users spend most of their time surfing the net anyway. IMO, John
Murga's 50mb "Mean Puppy", is, pound for pound, the best flavor of
Puppy for that purpose. And it still has alot of applications in it!
Anything else can always be added to the "save file". Personally, I
need the extra video codecs and I like my games.
a very,very nice thought! making an Qt base puppy! I'm sure a lot of
puppy enthusiasts will simply love it...and from now on will be a big
pressure to develop both GTK & Qt puppy and this could double the
work! So maybe it is time to consider DavidBell' idea to split puppy in
SFS files: to have an common core & zdrv sfs file , same for Qt
& GTK with kernel and all hardware stuff and common libraries, and
different sfs for Qt & GTK branch of applications and libraries.
The startup and kernel of puppy will be the same, will differ only the
applications family running, selected simply by Boot Manager.Of course
Remaster Puppy live-CD will allow any user to create one monolithic
slim puppy after his own choice.
experiment! Right now Puppy versions 2.17 and 3.0+ can use sfs by one
click. This is very similar to the way AppDir is used (the AppDir
method is used in Puppy: /usr/local/apps). With this method,
applications can be used as one-click/no-install packages.
Liberation fonts work well as TTF substitute in Puppy, and I have not missed the Vera fonts. :)
Sounds great to try a tangent that is stripped down with a possible
change to Opera. i prefer firefox, but it can be a cpu hog so i like ur
idea for Opera Your getting dangerously close to DSL size too. I agree
with Pizza about xorg pup. Being able to add what you want with an easy
pet, pup or sfs would be the icing on the cake that makes it small but
flexible. Some complain it will be missing stuff, but that can be
customized for the individual. If you have video drivers, easy to add
options, and internet i think that fills the basic bill of kick a$$
distro. i think what has been commented in the users forum about being
able to easily select sfs pre complete boot would throw it over the
top. it should not matter how small you get it as long as its easy to
add what you need! great idea Barry!
[b]Bloating:[/b] A medical symptom (accumulation of excessive
quantities of hot air). It is commonly associated with a known
bacterial inflammation usually called [b][i]"Redmonditis"[/i][/b]
It is hard to choose :
doesnt work well for my pc, but maybe it gets better ? There are some
alternatives to xorg : FBUI and Xynth but not sure if they are easy to
Abiword and gnumeric are essential and still small.
Which one is lighter : seamonkey or opera ? this has to be tested live to really know.
Maybe vlc is better than mplayer or xine because it doesnt need those big codecs, but this needs confirmation too.
You are on the right track for making puppy smaller and faster. Thanks.
Perhaps 2 versions....one stripped right down to the lightest
browser....and around 50 megs?
The other with the standard Puppy inclusions...ready to go.
Personally I have no issues with Mozilla.
Opera is not for me and Firefox has been going downhill for years.
Whichever way it comes out....I'll hold onto my hat for the ride.
Thanks for the fun....variety....off the rail variations that you
include with Puppy.
i think DavidBell is onto something. theres alot of wisdom in what he says.
it's great that your still able to step back and trim the fat
keep up the good work
Wow...Barry, you ROCK! Keep thinking outside the box.
first thing I do when I get the new distro's is to strip out Abiword,
Gnumeric, SeaMonkey, and Xorg which gives me a pup of approx 53MB
Then I have 3 sfs which I can choose to load or not
WINE - 11MB (I use SoftMaker and K-Melon and TC in WINE)
OperOffice - 13MB (Abiword;Gnumeric and Opera)
QTpref - 18MB (Qt and games and some specialist codecs)
normally run with just Wine which gives me a 64MB load, but sometiimes
I go for the OperOffice which is a 66MB load - and on rare occasion I
play games and movies and use a 71MB load
I find it works out really well for me doing it this way and provide the flexibility I need
would add that my pup_save even with icewm and customnizations is only
16MB with this config and in the 20 or so months i have been using it I
have had bery few issues except with 2.17 which I could just not get my
hands around for whatever reason.
Look forward to testing the prototype
Good points, David and Vern. Let me share one possibility in using a small Puppy "core" via humongous initrd creation.
trick for separating the "core" and loading it to RAM will be to use a
humongous initrd - this is usually part of unleashed, but if it is used
to build a Puppy "core", the remaster script can be modified
The init scripts may have to be adjusted, too...
previous post I suggested a 'wish' to see puppy more modularized for
more flexibility, in the way Davidbell and Vern are suggesting also. I
talked about engine (== core) etc... but especially keeping per-machine
config apart from common sfs and user's data files. (maybe identifying
it on the kernel's command line at the start or whatever better
logic behind this, (and after trying different puppys on different
generations of machines at the same time), was to use unique user's
data on all the machines, regardless of puppy's version, and avoid
upgrading and probing and detecting and configuring unnecessarily the
same machine each time I start.
I've found excellent for example
the devx.sfs, zdrv.sfs, splitting. I ended up by asking my self why we
cannot do the same for apps too, a kind of SLAX approach. (by the way I
never used it like puppy, KDE-allergy maybe;..)
Four years now I'm keeping more and more puppy in my pocket. thank's to you all, and to you Barry,keep on the good work.
to note that 'slackwar-ing' puppy conceptually is a good try (opening
towards a bigger number of available apps),but the older approach
worked better for me.
may be certain merit in the various modular suggestions, but users,
especially refugees from you-know-what, just want something small, fast
and preconfigured. Multiple choices, extra driver files, etc. are the
domain of those more skilled or more experienced in the art.
I'm not only just a "refugee from you-know-what", but even more, I'm
also a convinced militant for open source and it's spread all around, I
do the same for puppy, effectively.
I feel so much concerned about puppy staying mean and lean.
is not against ease of usage. In the contrary it can answer the need of
many of us using it, now and in the future, regardless of computer
experience and needs. (One other good side can be: help avoiding the
need of different puppys' flavors just because one added differently
other apps, when these can be packaged in different flavors together in
apps_sfs files instead, and used with one unique core).
end the core (==engine), is the same, preserving *compatibility*, and
it's up to the user to choose it's apps/packs freely according to his
own use, either will it be a standard (Barry's) or not).
know what I really like in open source, that one cannot stay etern ally
a newbie (unless...) : knowledge is not only preserved but extended.
But what I don't like, and feel it's a loss, when we reinvent the wheel: energy is dissipated!
last word as an example, why other distros have a rich choice of apps
and just two ways to add them (src and pckg) and in puppy we need
three, or maybe more?
(I'm using now a 2.14 version, works
great, only needed the nvidia proprietary drivers to get 3D working
correctly with xorg :) )
ago I did some Unix sys admin - back in the days of Solaris 1 - and a
conventional setup in those days went along these line :-
A dedicated swap file, plus seperate partitions for: / (i.e. root); /boot; and /usr.
kernel and essentials for the boot process went in /boot, apps and
config in /; and then all user and apps data went in /usr. The
advantage of this was that each subset could be kept seperate and could
often be maintained without interfering with the other.
I haven't worked on Unix for 10+ years so this may be old hat now as Solaris has developed.
new RAW Puppy direction comes quite near that by using .sfs files
rather than partitions, and has elegance and flexibility. I like the
sound of it!
There'll be plenty of lively arguments/dicussions
around what to include in what package, but as long as the core package
has the tools that enable the "bolt-ons" to self-configure (or upgrade)
then it sounds spot-on.
Although Puppy is designed for older
low-spec systems in reality lots of us have more modern kit where the
memory limits aren't an issue and would welcome a way of nominating
which apps load into memory at boot-up. Likewise; many systems have
graphics cards which need pretty heavy-weight (and often propriety)
drivers. Would these work under xvesa? Could XORG plus the relevant
drivers be packaged together and used instead of xvesa if necessary?
further "thought"; it's based on personal circumstance but may trigger
more generic solutions. I have 2 modern laptops where I run Puppy. Both
have Windoze as their primary system as both come via my work where
'doze is corporate polcy, and one of them has encrypted hard drives
which Puppy cannot see at all. So I use a USB flash drive and can
ignore all the MS stuff. One has a fancy graphics card but the other
hasn't and each operates at a different screen resolution. At the
moment I don't know how to set up a single USB flash drive that will
work on both and switch automatically into the appropriate xorg.conf
file. My ideal would be one installation that detected which was
appropriate and started X accordingly. Any chance?
Nick2109, I wonder the same thing. Puppy lends itself to carrying
around your data and the OS on a flash drive, using it in different
computers. But there is a setup exercise each time you move from one
computer to another. I wonder if we can create computer profiles and
have our setup info for each computer in each of those, and the boot
script somehow detects which computer it is running on and selects the
appropriate profile automatically?
on the codec thing, is it possible to load NO codecs by default; then
when you click on a link that needs a codec to play, it automatically
digs the appropriate one out of zdrv and adds that to Puppy? So we
don't have every codec under the sun, but only those few for the sites
we visit? Might keep the size down...
other thing, why have Opera or Seamonkey as default browser at all? Use
dillo (or its replacement, whatever that is) to go out and get the main
browser sfs file or dotpet. That is, have only dillo in Puppy by
default. Of course it will have to be carefully documented for newbies
that a real browser has to be loaded, and how to do that...
unless i am mistaken texas flood boot accel is designed to do harware
detection at boot time every time and it is really fast....if it can be
done while other things that have to be done are done and that require
hardware io then there is no overhead to hardware detection.....in the
end there is probably a little overhead yet to be seen how much there
will be with texas flood boot accel.
PaulBx 1 Opera is So Much More than Just a WebBrowser, it's fEMail, News Client, IRC Chat, FullFeatured etc..
I prefer GTK+2 over Qt, because Qt isn't GPL. (sorry if GPL is my philosophy).
For the sfs divisions, only testing can show if things will work out
Especially, please dont give up support for very old PCs !
fltk puppy anyone at least it would support all the murgalua apps....
that Microsoft is planning a 40MB version of Windows, although it
doesn't have a graphical user interface so in a sense it's not really
"Windows". But it does put the typical bloated statements about
Microsoft in doubt. The article compares it with DSL indicating that
DSL has significant extra features. Puppy would be even more so, but it
is a lot bigger than DSL.
hahahaahah put MS bloated statments about ms in doubt I laugh yet again
hahhhaaha you must realise that it has NO graphical interface so how
big will it be after they add that? at least another 100-200 mb
it stands it sound equivalent to DOS only half as functional and last
time I checked DOS fit on a floppy.....as does even a modern linux
kernel (lacking a few drivers but all the essential ones and probably
better than DOS) the kernel in puppy is only ~2 mb is it not?
or flat, M$ runs where $ are: typically each new version imply a buy of
a new machine; Linux don't. Linux runs on 'nearly' any generation of
any GPL'd staff must be favored. It's a simple matter of support to the
open source and all the energy and devotion all these people are
putting in. Is puppy one of them? no? read more then... otherwise we'll
be checking now our bank accounts...
Smart cookies will use distros developed outside the USA. RoW doesn't
permit patenting of SW. (Crazy idea - any road up, I claim I thought of
all of it first back in 1964 - prove I didn't!).
Just my 3penceworth.
I agree with Barry, that a standard Puppy should boot on a 128MB PC.
The absolute max size of the iso should be 100MB.
there is really a possibility to make only one version with a
core(inluding opera,maybe even netsurf is not needed) and the
possibilitiy to add easely only needed packages.
I am using puppy version 2.17.1 and I think there is really a need of speed up the booting time in comparison to windows.
if we put opera in then we have to have QT - so I think that the core shd not include Opera
I agree, keep seamonkey and GTK+2 and remain GPL.
I would like 100% GPL puppy if possible
the way, a list of all puppy applications would be useful, so we can
find which can go away and which to replace with something lighter ?
But Sea.Munkey is Twice th' Size! !
"I would like 100% GPL puppy if possible"
GNU libraries are LGPL, so that would only work if you count LGPL as
GPL. Thing is, there is a very significant difference. With LGPL, you
can use (but not modify) the library/app/whatever within another
project, without the GPL "infecting" your project and forcing you to
release the entire thing as GPL. Having all the basic libraries GPL'ed
would be enough for me to dump Linux for BSD.
Even if you
ignored LGPL, it still wouldn't work. Xorg is neither GPL nor LGPL. I
uses the X11 license, also known as the MIT license.
GPL is not
the only free license. Just because something isn't GPL doesn't mean it
can't be just as free and open as something GPL, if not even more free
(due to fewer restrictions on its use; the GPL forbids things);
I had any issues with Opera, it would be that it isn't open source. But
it doesn't really bother me. It's not a key component of the operating
system itself and we aren't forced to use it.
After all the aim is to stay free like a bird.
But which freedom we're talking about:
1- freeing the source and let the door open,
2- freeing just the usage,
4- freeing the price?
7- Or better free them all?
Of course the license that answers no 7 is the best choice for the user.