Suggestion for the upcoming puppy 1.0.5
Suggestion for the upcoming puppy 1.0.5
Hi Barry,
looking forward to the release of 1.0.5 (because printing seems to be broken in alpha2..).
I really see 1.0.5 as a major new release. It has usr_devx.sfs compile environment. It has a new desktop design and layout and so many other new and/or improved things...
What I would like to avoid is, that just after 1.0.5 is released, some really anoying bugs are found .. and the cure is to wait for 1.0.6 .. that fixes these and introduces some new ones .. that takes us to 1.0.7 .. and so on and so on..
I know that you are really working hard to avoid that situation.. but isn't it
time to think about some beta testing..?
I mean when you are ready for the release of 1.0.5, name it beta and
ask people on the forum to stress test it and report any problems found,
so we have some time - app. 2-3 weeks to get as much as possible bugs out, before the stable release of 1.0.5!
We could even think of, after the release of 1.0.5, when working started already on 1.0.6, that we collect bug reports, patches and work arounds for 1.0.5.
What do you/the others think?
PS
looking forward to the release of 1.0.5 (because printing seems to be broken in alpha2..).
I really see 1.0.5 as a major new release. It has usr_devx.sfs compile environment. It has a new desktop design and layout and so many other new and/or improved things...
What I would like to avoid is, that just after 1.0.5 is released, some really anoying bugs are found .. and the cure is to wait for 1.0.6 .. that fixes these and introduces some new ones .. that takes us to 1.0.7 .. and so on and so on..
I know that you are really working hard to avoid that situation.. but isn't it
time to think about some beta testing..?
I mean when you are ready for the release of 1.0.5, name it beta and
ask people on the forum to stress test it and report any problems found,
so we have some time - app. 2-3 weeks to get as much as possible bugs out, before the stable release of 1.0.5!
We could even think of, after the release of 1.0.5, when working started already on 1.0.6, that we collect bug reports, patches and work arounds for 1.0.5.
What do you/the others think?
PS
Have fun :)
Puppy 1.0.5 beta/release
Barry,
As anxious as I am to get a copy of the Puppy 1.0.5 release, I have to agree with PeterSieg. How about a 1.0.5 Beta, a week or so after "wifi week"?
After trying most of the "live-CD" distros over the last 2-3 weeks, I've laid them all aside except for Puppy 1.0.4. I've settled on Fvwm95, and I hope it will be included in 1.0.5.
I'm something of a newbie myself, and one other distro that appealed to me was BeatrIX, primarily because of its simple (short) menu. Have you considered a "skinny" Puppy - with a set of your choice of "best-of" applications/tools/utilities? If someone prefers a different text editor (or whatever _________ application), that's available as a PupGet or DotPup.
BTW - the multisession live-cd is great! I can put Puppy on my desktop system, and carry just what I need with me on a CD!!
Thanks for a *great* user-friendly distro!
HE
As anxious as I am to get a copy of the Puppy 1.0.5 release, I have to agree with PeterSieg. How about a 1.0.5 Beta, a week or so after "wifi week"?
After trying most of the "live-CD" distros over the last 2-3 weeks, I've laid them all aside except for Puppy 1.0.4. I've settled on Fvwm95, and I hope it will be included in 1.0.5.
I'm something of a newbie myself, and one other distro that appealed to me was BeatrIX, primarily because of its simple (short) menu. Have you considered a "skinny" Puppy - with a set of your choice of "best-of" applications/tools/utilities? If someone prefers a different text editor (or whatever _________ application), that's available as a PupGet or DotPup.
BTW - the multisession live-cd is great! I can put Puppy on my desktop system, and carry just what I need with me on a CD!!
Thanks for a *great* user-friendly distro!
HE
Re: Puppy 1.0.5 beta/release
I'm with HdE. Please do include it. please please pleaseHdE wrote:I've settled on Fvwm95, and I hope it will be included in 1.0.5.
I once used Beatrix and I like its simplicity. Web Browser, Email Client, Messenger, Word Processor & Some commandline utilities. The "Skinny" idea is a good one.HdE wrote: one other distro that appealed to me was BeatrIX, primarily because of its simple (short) menu. Have you considered a "skinny" Puppy - with a set of your choice of "best-of" applications/tools/utilities?
Printing problem in 1.0.5a2?
Hi.
Testpage works. I last printed with John Murgas 50m Opera+ Textmaker
version...
I didn't setup a printer through the wizard, because there is no such entry
of a 'generic postscript' printer?!
I entered a new printer through xpdg and there choosed 'generic postscript'
printer on local parallel port (/dev/lp0).
Printing from abiword showed an entry wihle xpdq was running and status
went to printed (If I remember right..).. but the printer didn't print anything?
I then saved a file from abiword (standard abiword format) and called
the file from xpdq to print. This time a empty page was 'printed'..?
PS
I have a lexmark 4039 laser printer, that understands postscript directly.What's wrong with printing in alpha2?
Testpage works. I last printed with John Murgas 50m Opera+ Textmaker
version...
I didn't setup a printer through the wizard, because there is no such entry
of a 'generic postscript' printer?!
I entered a new printer through xpdg and there choosed 'generic postscript'
printer on local parallel port (/dev/lp0).
Printing from abiword showed an entry wihle xpdq was running and status
went to printed (If I remember right..).. but the printer didn't print anything?
I then saved a file from abiword (standard abiword format) and called
the file from xpdq to print. This time a empty page was 'printed'..?
PS
Have fun :)
I agree with the "Release Early, Release Often" approach, which I think is happening with these 2 alphas...a beta would complement this nicely as I gather from 'News' that various changes have been made...
Personally I prefer JWM to FVWM95 - seems far more intuitive.
- keeping an alternative in Unleashed (as with alpha2) makes perfect sense to me.
The (optional) Dev environment, to me, is a great thing, so keep up with that too!
F
Personally I prefer JWM to FVWM95 - seems far more intuitive.
- keeping an alternative in Unleashed (as with alpha2) makes perfect sense to me.
The (optional) Dev environment, to me, is a great thing, so keep up with that too!
F
Some suggestions for changes to the startup scripts...
I'd like to see the introduction of a 'site' directory, specifically, /etc/rc.d/site (which, generally refers to /root/.etc/rc.d/site).
When any upgrades are done to Puppy, all that will be changed will be the contents of /etc/rc.d (which, generally, the contents of which we probably shouldn't fiddle with manually), for example, rc.local0, rc.sysinit, etc. This would mean anything stored in /etc/rc.d/site would be untouched through the upgrades.
As part of this, rc.local0 would be modified thus (untested shell script):
In a similar manner, all of the startup scripts would include a similar construct, for example:
This means the site-specific startups can be modified/customized and won't break when an upgrade is done.
There should also be something as the very first line(s) of each startup script that announces that it is running, for example:
Technically, I'd also like to see something where the ANSI attributes are also used, a la a lot of the other major Linux distributions, as this makes these 'milestones' of scripts starting a lot more obvious on the console during startup. These attributes are already used in portions of Puppy's rc.sysinit (remember seeing those little green 'done' messages on startup?)... but this change isn't as important as getting 'upgrade-proof' user-defined startup scripts.
These are all fairly minor additions to the startup scripts... but I reckon they would be very useful and informative for people using Puppy.
I'd like to see the introduction of a 'site' directory, specifically, /etc/rc.d/site (which, generally refers to /root/.etc/rc.d/site).
When any upgrades are done to Puppy, all that will be changed will be the contents of /etc/rc.d (which, generally, the contents of which we probably shouldn't fiddle with manually), for example, rc.local0, rc.sysinit, etc. This would mean anything stored in /etc/rc.d/site would be untouched through the upgrades.
As part of this, rc.local0 would be modified thus (untested shell script):
Code: Select all
if [ ! -d /etc/rc.d/site ]; then
echo "Creating site-specific startup directory, /etc/rc.d/site ..."
mkdir /etc/rc.d/site
fi
if [ -f /etc/rc.d/site/rc.local ]; then
# ...create a basic rc.local
fi
. /etc/rc.d/site/rc.local
Code: Select all
if [ -f /etc/rc.d/site/rc.network ]; then
. /etc/rc.d/site/rc.network
fi
There should also be something as the very first line(s) of each startup script that announces that it is running, for example:
- logger "Running /etc/rc.d/rc.local0 ..."
- echo "Running /etc/rc.d/rc.local0 ..."
Technically, I'd also like to see something where the ANSI attributes are also used, a la a lot of the other major Linux distributions, as this makes these 'milestones' of scripts starting a lot more obvious on the console during startup. These attributes are already used in portions of Puppy's rc.sysinit (remember seeing those little green 'done' messages on startup?)... but this change isn't as important as getting 'upgrade-proof' user-defined startup scripts.
These are all fairly minor additions to the startup scripts... but I reckon they would be very useful and informative for people using Puppy.