(very) Experimental 'RawPup'
Saturday, October 20, 2007, 09:46 PM
Okay, here's why I've been quiet for a few days...
I'm
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.
I
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.
What
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.
Note,
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.
Right
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!
Hopefully
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).
kirk
Saturday, October 20, 2007, 10:51 PM
Very interesting.
I would miss Xorg, no hardware video acceleration :( , no synaptics touch pad driver.
Cutting
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.
The
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
developers.
Anyway, sounds like fun!
PaulBx1
Saturday, October 20, 2007, 11:53 PM
Great direction to take, Barry! 
I
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.
I
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! 
Say,
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.
Pizzasgood
Sunday, October 21, 2007, 01:54 AM
Just
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).
Sage
Sunday, October 21, 2007, 02:13 AM
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!
DavidBell
Sunday, October 21, 2007, 03:01 AM
Hi Barry
First
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.
Anyway
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)
e.
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)
4. Pitfalls?
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
.sfs?
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
DB
Yogi
Sunday, October 21, 2007, 03:11 AM
I
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.
ferikenagy
Sunday, October 21, 2007, 05:56 AM
It is
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.
Raffy
Sunday, October 21, 2007, 07:41 AM
Great
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.
Raffy
Sunday, October 21, 2007, 08:10 AM
Liberation fonts work well as TTF substitute in Puppy, and I have not missed the Vera fonts. :)
mbutts
Sunday, October 21, 2007, 08:47 AM
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!
JohnRoberts
Sunday, October 21, 2007, 12:11 PM
[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]
linuxcbon
Sunday, October 21, 2007, 12:50 PM
Very nice
It is hard to choose :
xvesa
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
include.
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.
cthisbear
Sunday, October 21, 2007, 06:48 PM
Barry:
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.
Regards ......Chris
melmo
Sunday, October 21, 2007, 07:53 PM
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
melmo
Subito Piano
Monday, October 22, 2007, 12:19 AM
Wow...Barry, you ROCK! Keep thinking outside the box. 
vern72023
Monday, October 22, 2007, 12:33 AM
Interesting Barry
The
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)
I
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
I
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
George
Raffy
Monday, October 22, 2007, 02:01 AM
Good points, David and Vern. Let me share one possibility in using a small Puppy "core" via humongous initrd creation.
One
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
accordingly.
The init scripts may have to be adjusted, too...
amadus
Monday, October 22, 2007, 03:23 AM
In a
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
solution);
The
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.
Just
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.
Sage
Monday, October 22, 2007, 05:06 AM
There
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.
amadus
Monday, October 22, 2007, 06:25 AM
Sage
Because
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.
Modularity
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).
At the
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).
You
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!
My
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 :) )
Monday, October 22, 2007, 06:35 AM
Years
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.
The
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.
Barry's
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?
One
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?
PaulBx1
Monday, October 22, 2007, 12:36 PM
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?
Also
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...
PaulBx1
Monday, October 22, 2007, 12:40 PM
One
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...
cb88
Monday, October 22, 2007, 01:15 PM
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.
Max Headroom
Monday, October 22, 2007, 04:51 PM
PaulBx 1 Opera is So Much More than Just a WebBrowser, it's fEMail, News Client, IRC Chat, FullFeatured etc..
linuxcbon
Monday, October 22, 2007, 05:34 PM
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 !
cb88
Monday, October 22, 2007, 05:58 PM
fltk puppy anyone at least it would support all the murgalua apps....
Jeffrey
Monday, October 22, 2007, 08:15 PM
I see
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.
http://www.computing.co.uk/vnunet/news/
cb88
Monday, October 22, 2007, 09:59 PM
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
as
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?
winmin=BloatDOS
amadus
Tuesday, October 23, 2007, 03:37 AM
mini
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
computers.
Yes,
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...
my 3cents
Sage
Tuesday, October 23, 2007, 04:01 AM
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.
Frank
Tuesday, October 23, 2007, 04:32 AM
I agree with Barry, that a standard Puppy should boot on a 128MB PC.
The absolute max size of the iso should be 100MB.
Maybe
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.
vern72023
Tuesday, October 23, 2007, 12:30 PM
if we put opera in then we have to have QT - so I think that the core shd not include Opera
linuxcbon
Tuesday, October 23, 2007, 01:52 PM
I agree, keep seamonkey and GTK+2 and remain GPL.
I would like 100% GPL puppy if possible
By
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 ?
Me
Tuesday, October 23, 2007, 02:45 PM
But Sea.Munkey is Twice th' Size! !
Pizzasgood
Tuesday, October 23, 2007, 05:27 PM
"I would like 100% GPL puppy if possible"
Most
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);
If
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.
amadus
Wednesday, October 24, 2007, 03:45 AM
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.
|
Puppy developer news: 
… he did get puppy downloaded and has found it to be different than he exprected not a bad thing though…
The "help" page wasn't much help, implying you should edit the template files by hand.
Sage
Monday, November 5, 2007, 09:58 AM
“And now for something weird”. Opera might kill two stones with one bird? Dillo is the fallback, either way.
Sage
Monday, November 5, 2007, 10:22 AM
Everything except ‘Play’ in ..21 works for me - including the ‘munster. HardInfo is a distinct improvement, although SystemStats may be smaller and has dmesg OP.
Henry
Monday, November 5, 2007, 11:02 AM
Truly impressive, Barry,
I have upgraded more or less successfully from 3.01 with k21.
Temporarily of course. The Halloween color is a bit unnerving!
Lobster
Monday, November 5, 2007, 11:17 AM
desktop background can not be changed with wallpaper changer
processor system info much better
Have added a thread in forum under cutting edge
wii info and Puppy 4 page added
A lot to explore
Is there any way to get the res in xvesa higher? I am stuck at 800*600 I am sure there is but have not figured it out yet . . .
Lobster
Monday, November 5, 2007, 11:19 AM
wii=wiki - oops . . .
vern72023
Monday, November 5, 2007, 12:26 PM
in order to get icewm to work I had to impoprt an earlier version of IMLIB apart from that and the wallpaper changer issue that Lobster mentions wine46 works okay so taht is my largest concern
magerlab
Monday, November 5, 2007, 12:31 PM
will the packages from raw pup work in puppy 3.01?
Bob Bagwill
Monday, November 5, 2007, 12:32 PM
Will gslapt be include in the standard rawpup?
mdisaster2
Monday, November 5, 2007, 02:15 PM
What about Slackware compatibility ?
linuxcbon
Monday, November 5, 2007, 04:59 PM
It’s great, just testing the new beta.
So far I am very pleased with all your changes, colors are cool, menu is simpler, xvesa works good (screen refreshing rate is not high but this can be changed).
Still some bugs to be corrected like chat icon doesn’t work or mplayer not displayed ?
It is on the good way to be a terrific 4.0
BarryK
Monday, November 5, 2007, 06:19 PM
Sage, ah, yes, the ‘play’ icon. You have to edit /usr/local/bin/defaultmediaplayer and change “mplayer” to “gmplayer” — that was a bug.
Lobster, ah, the wallpaper setter assumes the existence of directory /root/.config/tmp — manually create it, then wallpaper setter works. But, it still has issues — is supposed to know the current setting at startup but doesn’t. Anyone a wiz at setting up ROX-Filer and can fix this?
Lobster, regarding higher resolution, have you run the Video Wizard (in the Setup menu)?
magerlab, packages from RawPup may not work in 3.01 as they use the very latest versions of libraries. Also answering mdisaster2, the reverse is probably okay, Slackware packages will work in RawPup, except maybe some missing dependencies. Bob, no, Gslapt will be a PET package, at least in the main ‘official’ Puppy, at least that’s my thinking for now. Gslapt should work fine, and should automatically determine any extra dependencies that would need to be installed.
linuxcbon, see above note about mplayer. The chat icon: RawPup has Pidgin and that should be working. Hm, I just tried ‘pidgin’ in a terminal, and it crashed with a segfault and a message to report this to the developers. Well, I did have pidgin working before, so I’ll look into it. Perhaps I left something vital out of the PET package. Sometimes, just leaving out an icon causes an app to crash at startup. RawPup has pidgin version 2.2.1.
…of course, if you’re keen, you could compile it.
BarryK
Monday, November 5, 2007, 06:41 PM
Note, I have fixed the old blog, existing comments were not displaying.
cthisbear
Monday, November 5, 2007, 08:28 PM
Barry:
You never cease to surprise and amuse me.
Do we call this Sandy Desert colour?
No this is good.
Shock the hell out of the detractors.
Strangely couldn’t mount C:\ Drive to delete Windows temps etc.
Other drives OK to delete recycle bin etc.
Maybe just a one off…I will reboot and see.
And you are still King of the Castle.
Have a good day…………………….Chris
cthisbear
Monday, November 5, 2007, 08:54 PM
” Strangely couldn’t mount C:\ Drive to delete Windows temps etc.”
Now testing on a HP Pavillion 772a….never a favourite.
NTFS has the same problem as my regular computer.
Sees Fat32 and writes to them
Sees NTFS and it’s Red Alert….cannot write to the drive.
Is it a newer version….because since Puppy 2.10,
fixing hard drives is a pleasure with Puppy….but not today.
And of course this is where Puppy shines.
Why I use Puppy to tuneup XP
http://www.murga-linux.com/puppy/viewtopic.php?t=20312
Chris
cb88
Monday, November 5, 2007, 10:23 PM
I wonder how this version of puppy will compare to say 1.9 or 2.02 and 2.12 as far as speed and efficiency…. would be nice to see some numbers
Lobster
Tuesday, November 6, 2007, 01:21 AM
“Lobster, regarding higher resolution, have you run the Video Wizard (in the Setup menu)?”
Yes I have. Not used xvesa in a long time. The max resolution offered in the wizard is 800×600 24 bit It is possible that 1280×1024 is not possible in xvesa with the Nvidia Geforce I am using. I might try the inbuilt graphics card on this board. In the early xvesa you could manually set with options such as #0×011a - not sure if that is possible? After trying to config varous ‘x files’ I had to reboot and run “puppy pfix=purge” - enabling me to boot up again into xvesa.
I am glad this has turned from an ‘Experiment’ into a full ‘Alpha 4′ (I am using the code name PAL (Puppy Advanced Linux) for Puppy 4. That should bring in some interest
In particular the use of SVG is welcome and may even be possible to use
icons, superimposed or shadowed or blurred to generate infinite
background abstractions with very little code . . .
What tools are used to generate SVG? Ah . . . inklite . . . built into Puppy. Onward to the magic castle . . .
Raffy
Tuesday, November 6, 2007, 05:21 AM
That high resolution is supported by default in my test PC - this is SiS600+ integrated graphics card.
PAL - Beware, Lobster, ‘coz PAL could stick and finally make the connection between Puppy’s name and the advanced features of Linux. Good thinking out of the blue (ocean, that is).
(To the script: No, am human - timeout did not go away with this new version.
Dougal
Tuesday, November 6, 2007, 08:37 AM
Wasn’t this blog supposed to be commentless?
Anyway, RE: volume applet.
If you are referring to AbsVolume, then, the way I understand the README, it’s not a volume applet — just a volume control app that’s supposed to be launched from a panel-button.
Sage
Wednesday, November 7, 2007, 04:58 AM
Big problems with network connection on full install, reported here:
http://www.murga-linux.com/puppy/viewto
- and, yes, timeout defect remains on this board!
Sage
Wednesday, November 7, 2007, 06:22 AM
BK list No.3 :”just click on zdrv_390.sfs”
Failed mounting or unmounting
Is this related to the network failure?
Whatever, dumbos like me would need an expanded explantion of the above proposed fix (if it were working!)
Sage
Thursday, November 8, 2007, 12:30 PM
vide supra - just lobbed the /lib/modules from the (pfixed) liveCD onto the HD install and entered the addresses manually. Amazing - it worked. Guess this is what BK will do for alpha2, anyway?
Reporting here as John’s board is down again.