After more successful HD-installed transplants of v1.0.6 into a pair of HP Brio 550's with only 64Mb, using a tiny swap partition, I was again amazed by the speed and accuracy of detection of Puppy. Several of us are using Barry's masterpiece to resurrect old kit. This seems to be an especially rewarding project, even though it wasn't the original intention of the live CD and more recent incarnations.
Notwithstanding, now that a more sophisticated v2 is in prospect, maybe it's worth keeping the 1.0.x series as a simple and basic option for eg demonstrations, neophytes, resurrectionists and co.? In short, is it worth complicating 1.0.8 by offering x.org, for example, when xvesa is adequate for most situations. The same applies to the content; perhaps the range of applications can remain basic? Even dispense with the USB flash and multisession options? Perhaps the first series can be kept current just with patches and updates, but without additional bloat? After that, personal preferences are still catered for by dotpup and pupget downloads.
Just a suggestion.
Which version? Which application? What Content?
release both a beta version _and_ a stable version
Posted: Sat Dec 31, 2005 12:13 pm
---
Post subject: 1.0.7 too soon out of beta status ---
Reading all the bug report headings I feel that version 1.0.7 was lifted out of beta status way too soon. Complaints make their way around faster than compliments.
---
My suggestion would be to release both a beta version _and_ a stable version that is updated from time to time during a certain period, nine months for example.
---
Post subject: 1.0.7 too soon out of beta status ---
Reading all the bug report headings I feel that version 1.0.7 was lifted out of beta status way too soon. Complaints make their way around faster than compliments.
---
My suggestion would be to release both a beta version _and_ a stable version that is updated from time to time during a certain period, nine months for example.
X.org certainly is not bloated.
The Kdrive (Xvesa) always was declared as experimental and limited by its developers.
We had many reports in the board, that lots of graficscards did not work with it.
You could of course still use Puppy 106, and add the xorg 6.8.2-dotpup just in case, if your card does not work with Xvesa (which would reduce the free space for personal documents in pup001 of course).
Also Pizzasgood currently works on a stripped down version of Puppy for experienced users, who want to build "their own customized" system.
http://www.murga.org/~puppy/viewtopic.php?t=5391
Concerning a wide variety of systems where puppy works "out of the box", I think bundling x.org by default makes sense.
Another thing:
is 60 MB really bloated?
Is there a big difference to a 40 MB-Iso?
I could understand such suggestions, if we would talk about 200 MB or more.
But just to gain 20 MB by ripping off X.org and some apps, and like this reducing functionality, does not seem to be a good idea in my eyes.
Mark
The Kdrive (Xvesa) always was declared as experimental and limited by its developers.
We had many reports in the board, that lots of graficscards did not work with it.
You could of course still use Puppy 106, and add the xorg 6.8.2-dotpup just in case, if your card does not work with Xvesa (which would reduce the free space for personal documents in pup001 of course).
Also Pizzasgood currently works on a stripped down version of Puppy for experienced users, who want to build "their own customized" system.
http://www.murga.org/~puppy/viewtopic.php?t=5391
Concerning a wide variety of systems where puppy works "out of the box", I think bundling x.org by default makes sense.
Another thing:
is 60 MB really bloated?
Is there a big difference to a 40 MB-Iso?
I could understand such suggestions, if we would talk about 200 MB or more.
But just to gain 20 MB by ripping off X.org and some apps, and like this reducing functionality, does not seem to be a good idea in my eyes.
Mark
As I understand what BarryK has revealed about his Puppy2 project it isn't intended as being more sophisticated, advanced or bloated in any way. It is just different and revolutionary... More Puppiness in other words. It will retain and expand on what is good with Puppy, run on a broader spectrum of hardware, while being more in compliance with the rest of the gnu/linux world
fake it until you make it
i made SP107 ... bugfixes for Puppy 1.0.7 ... and so far all i have found to put in it is:I feel that version 1.0.7 was lifted out of beta status way too soon
1) uncomment the RealPlayer codec path in the gxine config file
2) some of the default wrapper files had $@ instead of "$@"
3) MU's clock setter program was broken because of the differences in the new version of Busybox
other than that, i haven't found any other bugs to fix in SP107
As one can see from my punctuation, comments were intended as locutory rather than criticism. Bloat is relative, as is complexity. Those of us intent on recycling rather than sophistication can benefit from extreme conservatism in the overall package. Guidance is need in assessing the minimum necessary for viability. X.org may be a luxury too far? Were a, say 5Mb, package to become available, this could lead to the reinstatement of maybe a few more million perfectly adequate old PCs.
In a parallel but related project, reduction of HW resource requirements is a particularly worthwhile goal. An obvious first option here is to remove the ridiculous 3D video cards and replace them with ISA 500K cards or w.h.y. - all that is necessary for surfing, email, correspondence, etc. HP used some very decent 90W ATX PSUs. However, AT units need to be redeployed wherever possible as these tend to be better designed and constructed. Power reduction is critical for Africa, India, etc but the ITX option is just too expensive, and, moreover, doesn't permit recycling of entirely adequate older kit. Puppy has emerged as a very suitable candidate in this area.
In a parallel but related project, reduction of HW resource requirements is a particularly worthwhile goal. An obvious first option here is to remove the ridiculous 3D video cards and replace them with ISA 500K cards or w.h.y. - all that is necessary for surfing, email, correspondence, etc. HP used some very decent 90W ATX PSUs. However, AT units need to be redeployed wherever possible as these tend to be better designed and constructed. Power reduction is critical for Africa, India, etc but the ITX option is just too expensive, and, moreover, doesn't permit recycling of entirely adequate older kit. Puppy has emerged as a very suitable candidate in this area.
-
Pizzasgood
- Posts: 6183
- Joined: Wed 04 May 2005, 20:28
- Location: Knoxville, TN, USA
From what I understand, Xorg is neccissary to remidy bad refresh rates for some users. How useable as a computer that hurts to look at? Also, I can't take advantage of my graphics card without it.
That said, my reasoning for taking it out of empty crust is that you can put it back easy enough if you do want it. One of the reasons I made empty crust is so I can test new ideas without having to mess with a fullsized Puppy. Recompressing usr_cram.fs takes a long time on my computer, so a 30% decrease in size helps.
That said, my reasoning for taking it out of empty crust is that you can put it back easy enough if you do want it. One of the reasons I made empty crust is so I can test new ideas without having to mess with a fullsized Puppy. Recompressing usr_cram.fs takes a long time on my computer, so a 30% decrease in size helps.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
Size does matter
One issue we have to recall most of the world still has slow access to internet, a difference of 20M is very noticeable to those of us with a dailup. One thing someone said (Flash??) was the loading of a base system that would / could load the rest. Say a default system, with only vesa, mozilla, dialup tools & ethernet, something to check sound etc (like tone gen program) and multi-session ready. Load the rest as desired. Load the sets of tools into packs (squash style) multimedia pack, email gaim other internet tools pack, writing caldender help pack, dev tools pack, etc
If we can divide most of puppy into five usable packs for more practial downloading. When I use dail up the package should take four hours or less to download so that hickup could complete the download in eight hours. I would download large stuff overnight as to not tye up my phone during the daylight hours.
It took three solid days to download SP2 for windowsXP on dailup.
If we can divide most of puppy into five usable packs for more practial downloading. When I use dail up the package should take four hours or less to download so that hickup could complete the download in eight hours. I would download large stuff overnight as to not tye up my phone during the daylight hours.
It took three solid days to download SP2 for windowsXP on dailup.
I agree with Ted Dog. I have ADSL now but can still remember those 5 hours Openoffice.org downloads and I think that empty crust will be very useful Puppy.
I would like to mention another point of view. Firefox, Thunderbird, Openoffice.org and Abiword are translated to Slovenian language and I'm very glad that I can use all of them in my mother language in Puppy.
I think that one of the keys that communities like Mozilla or Openoffice.org are so successful is their flexible localization system. Each step forward in simplifying procedures to customize Puppy from a smaller core will be another step also to this kind of flexibility.
I would like to mention another point of view. Firefox, Thunderbird, Openoffice.org and Abiword are translated to Slovenian language and I'm very glad that I can use all of them in my mother language in Puppy.
I think that one of the keys that communities like Mozilla or Openoffice.org are so successful is their flexible localization system. Each step forward in simplifying procedures to customize Puppy from a smaller core will be another step also to this kind of flexibility.
Does this statement hint or imply that EmtpyCrust will include a set of command line pupget package management tools? For systems where Kdrive does not work, a user without Xorg would (I think!) be unable to use a GUI tool to download Xorg and add it to their remastered "NotQuiteSoEmptyCrust" CDPizzasgood wrote:That said, my reasoning for taking it out of empty crust is that you can put it back easy enough if you do want it.
So command line tools for this would be needed, as far as I can see.The emphasis on GUI tools in Puppy is great for ease of learning for newcomers. It's the right way to go in general. However, it does make Puppy more dependent on a working X server, unless those GUI tools are actually wrappers for command line tools, or alternative command line tools exist. I'm not convinced that removing the more general X server (with support for more video cards) is wise, unless there is a good way for ordinary users to "put it back" using command line tools. Is that currently practical for non-expert Puppy users? Is how to do it documented somewhere?
Part of my reason for asking is that I'm building some CLI package management tools (very simple ones) for my own use already... they might get released to the public one day... if someone already has a released set of such tools for handling Pupget and Dotpup files, I'd like to avoid duplicating their work.
Jonathan
Nothing wrong with CLI, except that, as far as console commands are concerned, we have a couple of generations brought up on the DR/M$DOS structure.
Time to step back and take a wider view. Pizzasgood probably has the right idea?
The power of an underlying kernel is priceless. M$ copied this for its W3x/9x series but then lost the plot with its network series with NTFS and WinFS.
As for the command line, a very, very basic set of commands is required that work in every single distro in every single situation. These should probably be limited to a dozen? They need to include the ls/dir, cat/type, scandisk/fsck AND a basic, universal 'edit', which doesn't seem to exist in Linux at present (forget vi and the like - reminiscent of edlin). These should be directed to simple, essential tasks to maintain and fix the system - nothing else (at least, not in the basic set). More important is to have this basic command set repeated ad nauseum at every opportunity, and in full, until world+dog has assimilated them. Detailed advice on how they can be used needs to accompany each and every exposure; it cannot be assumed that this will be known, except amongst the tiny group of IT professionals.
Turning to the GUI, some kind of 'Safemode' with basic all pervading drivers is mandatory. Once one can obtain the picture on the screen - anything is possible: the corollary is unthinkable. On this basis, I would support a VESA only approach (I don't have a lot of sympathy for folk who waste money on proprietary hardware, especially laptops - this technology thrives on generics).
Again, the GUI mode should default to the l.c.d., which is probably a two colour 640x480 picture, on the basis that once this is reliably and reproducibly achieved, everything can be tweaked. At this stage, sound, multimedia, disc burning, etc are luxuries that can be added later. The dotpup/pupget systems are perfect for customising. Principle shortcomings crying out for attention are hardware swapping and system upgrading. These should be manageable from within or without the GUI.
In short, initial efforts need to be directed towards getting a system running - that's all. Across the extensive range of current hardware, this is no mean feat. From what I read, many of these aspirations are included in the wonderful efforts of Barry and the team.
Time to step back and take a wider view. Pizzasgood probably has the right idea?
The power of an underlying kernel is priceless. M$ copied this for its W3x/9x series but then lost the plot with its network series with NTFS and WinFS.
As for the command line, a very, very basic set of commands is required that work in every single distro in every single situation. These should probably be limited to a dozen? They need to include the ls/dir, cat/type, scandisk/fsck AND a basic, universal 'edit', which doesn't seem to exist in Linux at present (forget vi and the like - reminiscent of edlin). These should be directed to simple, essential tasks to maintain and fix the system - nothing else (at least, not in the basic set). More important is to have this basic command set repeated ad nauseum at every opportunity, and in full, until world+dog has assimilated them. Detailed advice on how they can be used needs to accompany each and every exposure; it cannot be assumed that this will be known, except amongst the tiny group of IT professionals.
Turning to the GUI, some kind of 'Safemode' with basic all pervading drivers is mandatory. Once one can obtain the picture on the screen - anything is possible: the corollary is unthinkable. On this basis, I would support a VESA only approach (I don't have a lot of sympathy for folk who waste money on proprietary hardware, especially laptops - this technology thrives on generics).
Again, the GUI mode should default to the l.c.d., which is probably a two colour 640x480 picture, on the basis that once this is reliably and reproducibly achieved, everything can be tweaked. At this stage, sound, multimedia, disc burning, etc are luxuries that can be added later. The dotpup/pupget systems are perfect for customising. Principle shortcomings crying out for attention are hardware swapping and system upgrading. These should be manageable from within or without the GUI.
In short, initial efforts need to be directed towards getting a system running - that's all. Across the extensive range of current hardware, this is no mean feat. From what I read, many of these aspirations are included in the wonderful efforts of Barry and the team.
Then you would'nt even need xvesa.
A simple dialog-based script to allow xorg or xvesa as an unleashed package would be sufficient.
But this would require to rewrite some wizards for internet-access as dialog-based applications.
So you could install xvesa, and if it fails with your graficscard, remove it, and install xorg instead.
Again,that might be problematic concerning the size of pup001.
Having the Xserver in usr_cram.fs helps keeping the wholesystem small due to the high compression.
Mark
A simple dialog-based script to allow xorg or xvesa as an unleashed package would be sufficient.
But this would require to rewrite some wizards for internet-access as dialog-based applications.
So you could install xvesa, and if it fails with your graficscard, remove it, and install xorg instead.
Again,that might be problematic concerning the size of pup001.
Having the Xserver in usr_cram.fs helps keeping the wholesystem small due to the high compression.
Mark
I used to feel disdain for laptops, because they were expensive and non-standard -- I would never buy one new!
Now I have opposite feelings. They are readily available used, sometimes free. They are the most efficient use of space and materials. They avoid the evils of lead-based CRTs. Their capabilities are "good enough" for most purposes.
I am mostly just sorry they did not become dominant and cheaper sooner, and it is too bad they are not more generic/standardized.
For most purposes, if you want a Puppy computer that uses as little power as possible, and you want to spend as little as possible, a salvaged/used laptop is the answer.
Now I have opposite feelings. They are readily available used, sometimes free. They are the most efficient use of space and materials. They avoid the evils of lead-based CRTs. Their capabilities are "good enough" for most purposes.
I am mostly just sorry they did not become dominant and cheaper sooner, and it is too bad they are not more generic/standardized.
For most purposes, if you want a Puppy computer that uses as little power as possible, and you want to spend as little as possible, a salvaged/used laptop is the answer.
Heck you do not need either X
On one rescue CD the graphical display is gkt. Better than ncurses, Mozella can run just on gkt2. For a truely minial system.
Gtk is a widget-set, so it still needs a xserver.
With ncurses (dialog) you would not need the xserver, and could choose to download xvesa or xorg, depending on your needs.
But as I said, I see no advantage.
You would get a smaller usr_cram.fs, but after the installation of a xserver this solution would use more MB on your harddisk, as pup001 is not compressed. So especially for old hardware / usb-sticks such a solution is less good imho.
So I think it makes more sense, to leave the xservers in usr_cram.fs.
Mark
With ncurses (dialog) you would not need the xserver, and could choose to download xvesa or xorg, depending on your needs.
But as I said, I see no advantage.
You would get a smaller usr_cram.fs, but after the installation of a xserver this solution would use more MB on your harddisk, as pup001 is not compressed. So especially for old hardware / usb-sticks such a solution is less good imho.
So I think it makes more sense, to leave the xservers in usr_cram.fs.
Mark
Or usr_more.sfs. I've seen it run (older version) with just a framebuffer (ok very small type xserver) and no window manager. works very much like I remember just full screen/ no other apps visible)
Code: Select all
xwin mozilla