Puppy Remaster Program needs updated from 18th Century

What features/apps/bugfixes needed in a future Puppy
Message
Author
musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#21 Post by musher0 »

Burn_IT wrote:As I said to start with, it IS a community project so stop complaining and do something yourself, or with friends??!!!
Of course anything you do produce will need to be approved before being adopted officially.
Very true. Thanks for the reminder, Burn_IT.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

Remastering a Personalised Pup for Users

#22 Post by davids45 »

G'day musher0,

I've been using the Remaster option in the Set Up menu quite a bit recently with the frequent deltas for BionicPup isos from peebee.

First I add my application pets and sfs, and various links as configs for personalising the new Pup. Mostly these are included in the remastered iso, just a few StartUp scripts tend to not work the first time - I suspect I overload the pinboard with icons so timing is awry.

I find BK's script in BionicPup is fairly easy to use with good explanations of the process. But it is a long process (on the Puppy time dimension, more like what I remember of the Windows world speed for doing something such as this).

A post in another thread by forum member willypuppy said he replaced the /root and /etc in /tmp prepared by the Remaster script with the versions on his computer (just copied them across to /tmp). I've been doing this and it is simple and seems OK.

However some of the changes I make to each new Puppy occur in other directories, not just in /etc & /root so I need to re-do these few changes in each remastered iso. Whether extra stops/steps to offer editing other directories is worth changeing in the Remaster program is doubtful.

While doing these almost daily BionicPup remasters lately, I was wondering about doing something with the Save-file as this has everything I need as far as I know and should pick up all my additions and changes, regardless of the directory involved.

So the idea to simply add the personalised Pup's Save-file to the presently-ignored-by-me 'a-drive' sounds very interesting. Almost worth a Homeric 'Doh!' And could be much quicker?

Any links for prior trials, etc of this approach?

Thanks,

David S.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

Re: Remastering a Personalised Pup for Users

#23 Post by musher0 »

davids45 wrote:G'day musher0,

I've been using the Remaster option in the Set Up menu quite a bit recently with the frequent deltas for BionicPup isos from peebee.

First I add my application pets and sfs, and various links as configs for personalising the new Pup. Mostly these are included in the remastered iso, just a few StartUp scripts tend to not work the first time - I suspect I overload the pinboard with icons so timing is awry.

I find BK's script in BionicPup is fairly easy to use with good explanations of the process. But it is a long process (on the Puppy time dimension, more like what I remember of the Windows world speed for doing something such as this).

A post in another thread by forum member willypuppy said he replaced the /root and /etc in /tmp prepared by the Remaster script with the versions on his computer (just copied them across to /tmp). I've been doing this and it is simple and seems OK.

However some of the changes I make to each new Puppy occur in other directories, not just in /etc & /root so I need to re-do these few changes in each remastered iso. Whether extra stops/steps to offer editing other directories is worth changeing in the Remaster program is doubtful.

While doing these almost daily BionicPup remasters lately, I was wondering about doing something with the Save-file as this has everything I need as far as I know and should pick up all my additions and changes, regardless of the directory involved.

So the idea to simply add the personalised Pup's Save-file to the presently-ignored-by-me 'a-drive' sounds very interesting. Almost worth a Homeric 'Doh!' And could be much quicker?

Any links for prior trials, etc of this approach?

Thanks,

David S.
Hello David.

nic007 has evolved his own approach and script for this -- hopefully he will chime in
and answer you as well.

As for me, this is how I did it on the xenial-7.0.6:

Code: Select all

#!/bin/sh
# /opt/local/bin/psave2adrv.sh
# Alternately, you can save this script in: 
# /root/my-applications/bin/psave2adrv.sh
#

##########
# Usage: 
# First, enter the directory where your Pup is located and 
# open a terminal there. Then, type: 
# psave2adrv.sh name-and-version-of-your-Pup
#
# Example: psave2adrv.sh xenial_7.0.6 
#
# You have to change this variable to match the Pup's
# name and version.
####

ReceivingDir="adrv_$1"

# 1st part: copy
mkdir -p $ReceivingDir

cd $ReceivingDir
rsync -avz /initrd/pup_rw/* . # Don't forget the dot!
wait # optional; to make sure the copy is finished before
# we start squashing

# 2nd part: squash
cd ..
mksquashfs $ReceivingDir/ $ReceivingDir.sfs -noappend -all-root -b 1048576 -comp xz -Xdict-size 100% 
# The last part of this line < -b 104... etc. > insure pretty much maximum 
# compression of the sfs file. # It takes a minute or so, depending on the size.
# Careful ! If you already have an adrv sfs in the directory, it will be destroyed 
# and replaced with this new one.

echo -e "\n\tDone!\n
You should now reboot your Puppy to activate your new adrv sfs.
Important: make sure your originating pupsave has been renamed.\n"

exit
###########################

# To double-check: (optional)
# diff -q $ReceivingDir /initrd/pup_rw | more 
# 
# All the sub-dirs should have the mention "identical", except
# some "wh.*" files and possibly file .usb-drive-log-probedisk
# in # /initrd/pup_rw only. This is normal. 
Please read the comments in the script beforehand.
If you follow the instructions, it should be fool-proof.
Any question, please ask.

Enjoy!
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#24 Post by musher0 »

Hello again all.

A new version, which, compared to the above, hopefully adds all necessary
safeguards. Feel free to comment or pinpoint shortcomings.

Maybe a note about why I do not squash directly to the adrv sfs file: FWIW,
I think having an intermediate folder offers a safer and more adaptable solution.
If you ever want to change something directly in the adrv directory, it's there,
whereas pup_rw is read only. Of course, in this new version you can erase it,
but still.

Enjoy!

Code: Select all

#!/bin/bash
# /opt/local/bin/psave2adrv.sh
# Alternately, you can save this script in:
# /root/my-applications/bin/psave2adrv.sh
#

##########
# Usage:
# First, enter the directory where your Pup is located and
# open a terminal there. Then, type:
# psave2adrv.sh name-and-version-of-your-Pup
#
# Example: psave2adrv.sh xenial_7.0.6
#
# You have to change this variable to match the Pup's
# name and version.
####

if [ "$1" = "" ];then
     echo -e "\n\t\e[33m\e[4mPlease restart with the name and version of\e[24m
     \e[4myour Pup as the first parameter after the command.\e[24m
          E.g.:      psave2adrv.sh \e[4mxenial_7.0.6\e[0m\n"
     exit
fi

ReceivingDir="adrv_$1"

# 1st part: copy
mkdir -p $ReceivingDir

cd $ReceivingDir
rsync -avz --exclude .wh.* /initrd/pup_rw/* . # Don't forget the dot!
wait # To make sure the copy is finished before we start squashing.

# 2nd part: squash
cd ..

if [ -f $ReceivingDir-bis.sfs ];then # Precaution
     echo -e "
     \e[33m\e[4mIf we continue, the existing $ReceivingDir-bis.sfs\e[24m
        \e[4mfile will be destroyed (erased). -- Is this ok? --\e[24m

        \e[4mType 'n' or 'N' to exit; any other key to continue.\e[0m
     "
     read Answer1
     case "$Answer1" in
          n|N)exit ;;
     esac
fi

mksquashfs $ReceivingDir/ $ReceivingDir.sfs -noappend -all-root -b 1048576 -comp xz -Xdict-size 100%
# The last part of this line < -b 104... etc. > insure pretty much maximum compression
# of the sfs file. It takes a couple of minutes, depending on the size of the pupsave file.

echo -e "\n     \e[33m\e[4mRemove $ReceivingDir/ ?\e[24m
\t\e[4mType 'y' or 'Y' for 'yes', any other key for 'no'.\e[0m"
read Answer2
case "$Answer2" in
     y|Y)rm -rf $ReceivingDir
          # rmdir $ReceivingDir
          ;;
esac

echo -e "\n     \e[33m\e[4mDone!\e[24m
\t\e[4mYou should now reboot to activate your new adrv sfs.\e[24m
\t \e[4mImportant -- \e[4mMake sure to store ALL pupsave files\e[24m
\t     \e[4mOUT OF THE WAY to be able to start afresh.\e[0m\n"

exit # Anything after this, bash ignores. #
###########################

# To double-check: (optional)
# diff -q $ReceivingDir /initrd/pup_rw | more
#
# All the sub-dirs should have the mention "identical", except
# some "wh.*" files and possibly file .usb-drive-log-probedisk
# in # /initrd/pup_rw only. This is normal.
Attachments
Sample-run.jpg
(94.74 KiB) Downloaded 674 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

Manually made adrv remaster

#25 Post by davids45 »

G'day musher0,
Thanks for your scripts to automate the process of adding a fully optioned Save-file into a Pup's a-drive.

Your post yesterday made me try to do it as a non-scripting 'beginner'. My steps, as I recall... :oops: ...:
in a safe place, expanded a backed-up tar file of a Save-file (most recent BionicPup update) which gave me the Puppy-iconed save-file
opened a new directory in another safe place (a temp directory on my data partition)
started a sub-directory there called 'adrv_ubbpup_18.03"
copied the files (retaining the path structure) of the expanded tar into this new 'adrv_ubbpup_18.03' directory
in Muppy-Filer, navigated to the directory containing the empty 'adrv_ubbpup_18.03'
opened a 'shell' in Muppy
entered 'mksquashfs adrv_ubbpup_18.03 adrv_ubbpup_18.03.sfs'
this gave me the test adrv sfs to try

on my main Frugals partition, I started a new directory (BionicAdrvTest)
into this, I copied all the Bionic+12 iso files for a Frugal Pup, except its adrv.sfs which I now substituted with the fresh adrv sfs
added the approriate lines to my Frugal partition's menu.lst to offer this new Pup
booted up to it, and it worked, and is still working now after several re-boots (screenshot) :shock: - a Save-file was created on first boot which is presently about 9MB.

I still find each start-up leaves some icons 'unfinished' on the pinboard but a restartX fixes this. All links are there and working.

All my personalisations (added apps, configs, etc) are operative including linking my tray-reported internet use to the sns on my data partition which recent normal remasters tended to miss.

I feel this a-drive has produced a faster Pup than the other methods :D but need to try this with some other Pups. Those coming with an a-drive option, anyway.

So I will give your script a try out or three, and let you know how it goes.

Thanks again,

David S.
Attachments
very-manual-adrv-remaster.jpg
BionicPup+12 pinboard: remastered by adding the all-apps-added Save-file into the adrv sfs
(111.51 KiB) Downloaded 636 times

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#26 Post by musher0 »

Thanks for your report, Davids45.

Good to hear!

Now, since the beaver is the animal emblem of Canada, as a dutiful Canadian, I will
have to present an official objection to the authors of BionicBeaver and BionicPup,
who no doubt where on LSD or mescaline when they drew that logo:
beavers are reddish brown in color, never green!!! :lol:

As proof! Image
That is a Canadian beaver, do not pay any attention to the file name. :lol:
Shucks, I will have to present an official objection to the Wikipedia photographer too!
Last edited by musher0 on Sun 01 Apr 2018, 07:32, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

hamoudoudou

Remaster tool included in ISO needs some renew.

#27 Post by hamoudoudou »

"Hence, the Puppy remaster script IS outdated and very not user friendly given it cannot simply, for example, via one click, include ALL Personalization of a user's system."

My feed-back : i am used to remterize Puppies to create my puplets at home. It's quite an evidence that all these pets and scripts created apart somewhere in our forum are the proof thait remaster tool included in ISO needs some renew.
Ramsfs never tried
Remaster x is one i use.
When you are happy with a pupsave, after having used it long time, you can consider about remaster.. But pay attention to remaster only importants changes.. Just copying what is in RAM will be very big ISO. Start a new pupsave with just what you like and immediately remasterize it.
I was never deceived by 0_pupbuild_tools, and ISO is bootable..
About Bionic, each day Ubuntu remasterize it, because they are building it for apr26, date of release. in fact puppy has nothing of Ubuntu Bionic (systemd d, kernel, gnome desktop), Puppy has access to multiverse and universe repositories, which are users ones

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

Re: Remaster tool included in ISO needs some renew.

#28 Post by nic007 »

hamoudoudou wrote:"Hence, the Puppy remaster script IS outdated and very not user friendly given it cannot simply, for example, via one click, include ALL Personalization of a user's system."

My feed-back : i am used to remterize Puppies to create my puplets at home. It's quite an evidence that all these pets and scripts created apart somewhere in our forum are the proof thait remaster tool included in ISO needs some renew.
Ramsfs never tried
Remaster x is one i use.
When you are happy with a pupsave, after having used it long time, you can consider about remaster.. But pay attention to remaster only importants changes.. Just copying what is in RAM will be very big ISO. Start a new pupsave with just what you like and immediately remasterize it.
I was never deceived by 0_pupbuild_tools, and ISO is bootable..
About Bionic, each day Ubuntu remasterize it, because they are building it for apr26, date of release. in fact puppy has nothing of Ubuntu Bionic (systemd d, kernel, gnome desktop), Puppy has access to multiverse and universe repositories, which are users ones
The builtin puppy remaster script works quite well but isn't as user friendly as it should be. That is why I made a remaster suite based on the builtin script with user friendly options. One of the scripts in the suite is an automatic option where NO user input is required (the default action there is to personalize for the same computer). So, you select the automatic one and the remaster will be done without user input. BTW - RemasterX is exactly the same as the builtin puppy remaster script just with another/easier GUI. I've made an effort to improve on and add to the actual script. The link for my remaster suite pet has already been posted in this thread, you can download and try if you like.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#29 Post by musher0 »

Hello all.

I have uploaded a French version of my script here.

TWYL
~~~~~~~~~~~~~~~~~~
Bonjour à tous.

J'ai enligné une version française de mon script ici.

À+
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#30 Post by bigpup »

I will assume the Remasterpup2 that is being talked about is the latest version in Woof-CE.
https://github.com/puppylinux-woof-CE/w ... masterpup2
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

Musher0's script

#31 Post by davids45 »

G'day,

I have made two a-drives from Pup save-files using musher0's script.

These were oldish recent Pups which had no a-drive by default, just puppy- and z- sfs and a save-file. So I didn't know if the a-drive would work since there wasn't one to begin with.

First mistake I made was to try running the script from another Pup - found I needed to be in the Pup itself to convert the save-file to an a-drive :oops: .

Once 'in the Pup', everything went quickly and smoothly. Well, when I got it right.

Second mistake was to not quite get the words after 'adrive-' right so the new a-drive file was ignored at booting :oops: :oops: .

For each test, once I had the a-drive sfs created in the particular Pup's /root/myapplications/bin, I made a new Frugal sub-folder of the Pup and copied the usual files from the iso and added the just-made a-drive.

Adding this new Pup to my Frugals menu.lst, I booted up each new Pup with its a-drive and each had the wanted applications from the new a-drive (pinboard screenshots). On closing down each new Pup, I made a save-file as normally required. Rebooting was normal.

Pets & sfs for applications
All my applications (as per icons on the pinboards) are added to a new Pup as pets made of symlinks to the program files stored on my data partition. Except gimp which I still add as an sfs. Initially I found gimp was not being included in the a-drive although the pinboard icon was still there, albeit as a missing file icon (!).

Adding an extra sfs
I found MU's sfs-combiner pet from 10 years ago and tried combining the gimp sfs with the just-made a-drive sfs. The new combined sfs (re-named as needed to be the a-drive sfs) I now used in place of the initial a-drive sfs and now each a-drive also loaded up the sfs of gimp :D .

So a good result for me and what I think I'm trying to achieve by remastering my Pups - I'm not really certain why, but that's life :shock: .

I'll keep on trying with other Pups and adding applications, missing libs, etc., as needed in each Pup.

Thanks again, musher0.

David S.
Attachments
puduan-adrive-allapps.jpg
Puduan-Pup pinboard with icons of applications from the script-made a-drive (gimp from a combining of sfs files - a-drive and gimp.sfs)
(98.63 KiB) Downloaded 571 times
stretchdeluxe-adrivelinks.jpg
DPup-Stretch-Deluxe running with a script-made a-drive
(105.94 KiB) Downloaded 560 times

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#32 Post by nic007 »

Hi, Davids45. Older Puppys don't support the adrv, ydrv, etc. but only the zdrv. However, one can still use the "adrv" method by renaming your big, base sfs to that of the zdrv and renaming your newly created "adrv" to that of the base sfs.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#33 Post by musher0 »

nic007 wrote:Hi, Davids45. Older Puppys don't support the adrv, ydrv, etc. but only the zdrv. However, one can still use the "adrv" method by renaming your big, base sfs to that of the zdrv and renaming your newly created "adrv" to that of the base sfs.
EEEEchch!!! :lol:

If you rename the zdrv, you lose it, nic007! And bye-bye to AA-LL-LL your drivers!

IIRC, that was a technique evolved by much respected Albertan compatriot and
forum member "mrb" shortly after he created a Puppy-4.12 that could load +/- 60
sfs's without blinking : it worked for him, but never for me!!!

I'll try to find the thread with his comments and mine. (It may take some "real" ;)
research since that was quite a few years ago.)

~~~~~~~~~~~~
Edit --

Removed the "pdrv" script after discussion with nic007 below. Also because sfs_load
messes up a number of things. Some day or other, I'll try to make a version that does
not need sfs_load.

On the other hand, the script above psave2adrv.sh workds well on recent Puppies,
provided you do not already have an adrv.

BFN
Last edited by musher0 on Mon 02 Apr 2018, 15:50, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#34 Post by nic007 »

musher0, you will find that most of the older puppys do not actually use a seperate zdrv as all the drivers have already been packaged into the base sfs. I use puppy 412, Wary and Racy and none of them have an operating zdrv for the drivers/extra drivers by default. So the "adrv method" to replace and act like an existing running savefile works perfectly for me with the name switching as suggested (my script is different of course to make this easy). Even if I had a seperate zdrv for drivers in this scenario, I would have merged the contents of the zdrv and the base sfs and called it the zdrv (no drivers are getting lost here). This option is normally available too when one does a remaster. I'm not quite sure I follow your suggestions if one has an old puppy and want to use the "adrv method". The thing is, one has limited options when working with an old puppy. You basically have the base sfs, zdrv and extra sfs's you can work with. The order of loading an old puppy would be in order of layers (preference) - savefile, base sfs, zdrv, extra sfs's. So if you want to replace the savefile with an sfs to load your changed configurations, etc. in the top layer, the name of that sfs MUST be the name of the original base sfs according to the booting sequence. The zdrv then follows and then extra sfs's. Creating an extra sfs for additional drivers may or may not work, depending upon whether those drivers are required during the bootup process. As a matter of interest and clarity: what is the name of your "adrv" replacing your savefile when dealing with an old puppy that does not support the adrv?

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#35 Post by musher0 »

Hi nic007.

In the new version of my script, it is "pdrv". P being sort of the typical letter for
anything Puppy. psave to pdrv, it is easy to remember what it does.

About the order thing, is it that important? In my mind, sfs layers are more like
slices of swiss cheese, with holes in them, and the full parts of one slice may or
may not cover the holes of other layers.

Let's say that you have icewm in one sfs, but not in any other "slice" or sfs: it will
work regardless of which slice or layer it is in. But if you compile and include a
more recent version of the fsck utility in an "extra" sfs, it will sit over the old
version, it will block the access to the old version and be used instead.

So that theory of layers, of what gets executed first depending on the layer, is not
absolute, as I understand it. Anyway, you do it your way, through remaster, and I
do it my way, ok?

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#36 Post by nic007 »

musher0 wrote:Hi nic007.

In the new version of my script, it is "pdrv". P being sort of the typical letter for
anything Puppy. psave to pdrv, it is easy to remember what it does.

About the order thing, is it that important? In my mind, sfs layers are more like
slices of swiss cheese, with holes in them, and the full parts of one slice may or
may not cover the holes of other layers.

Let's say that you have icewm in one sfs, but not in any other "slice" or sfs: it will
work regardless of which slice or layer it is in. But if you compile and include a
more recent version of the fsck utility in an "extra" sfs, it will sit over the old
version, it will block the access to the old version and be used instead.

So that theory of layers, of what gets executed first depending on the layer, is not
absolute, as I understand it. Anyway, you do it your way, through remaster, and I
do it my way, ok?

BFN.
The order of layers (preference) is most important. That's why we have the savefile at the very top to override everything loaded thereafter. Your pdrv won't work as suggested because it's loaded as an extra sfs and lower priority as the base sfs and zdrv. So you can do it your way but it won't work as replacement for the savefile or advr in older puppys. You will have to rename it to the name of the base sfs so that your configuration changes or whatever takes preference. I don't need to remaster anything. Now take a deep breath.... :wink:

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#37 Post by musher0 »

Why should I? I'm secure in what I produce, man!

Please try my script before bad-mouthing it! As long as your puppy has shinobar's
sfs_load, rsync and mksquasfs, it will work. And of course a pupsave file?! :twisted:

Now you take a deep breath! :)
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#38 Post by nic007 »

musher0 wrote:Why should I? I'm secure in what I produce, man!

Please try my script before bad-mouthing it! As long as your puppy has shinobar's
sfs_load, rsync and mksquasfs, it will work. And of course a pupsave file?! :twisted:

Now you take a deep breath! :)
You are missing the point my friend. It has NOTHING to do with your script (which I'm sure works for producing your adrv and your pdrv, etc.). The discussion is about what is going to work for older puppys which do not support the adrv. And now I'm going to repeat myself. Making a pdrv or any other extra sfs with sfs_load, will load LAST in order of preference at bootup. Same files in the base sfs or zdrv sfs will take preference because they have higher preference (like the contents of a savefile has). I'm not going to try to explain this to you further but will leave you with this thought to test your OWN theory. Bootup an older puppy like Racy. Save your configuration changes (like a change to background) to a pdrv.sfs as you suggest. Then bootup your base sfs and zdrv (if you have one)... and your pdrv.sfs with sfs_load and see if your configuration changes have been effected. Then please report back your results. Thanks and cheers.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#39 Post by musher0 »

Ok, let's play who's the most stubborn. If you're not going to test my script, I'm not
going to re-install some old Pup. Even if I do I won't tell you. So there. This is
silly. Whatever the theory of it is.

You try to help people, to get co-operation and confirmation on tests and either you
get a lecture or you get flak or you get misplaced pride.

When it's not shinobar's sfs_load f...g up your PuppyPin. Or a French rsync by
busybox. You people want to be spoon-fed with pre-cooked scripts and not
participate in the tests, and play "blame the developer" when things do not go as
expected and you do not get perfection the first time. davids45 excepted.

Enough. Where's the nearest bridge? I think I'll go there and jump off.

I just saw a flight in V formation of about 200 wild geese heading NW back home
along the Ottawa River. Now, they know the meaning of co-operation.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#40 Post by nic007 »

musher0 wrote:Ok, let's play who's the most stubborn. If you're not going to test my script, I'm not
going to re-install some old Pup. Even if I do I won't tell you. So there. This is
silly. Whatever the theory of it is.

You try to help people, to get co-operation and confirmation on tests and either you
get a lecture or you get flak or you get misplaced pride.

When it's not shinobar's sfs_load f...g up your PuppyPin. Or a French rsync by
busybox. You people want to be spoon-fed with pre-cooked scripts and not
participate in the tests, and play "blame the developer" when things do not go as
expected and you do not get perfection the first time. davids45 excepted.

Enough. Where's the nearest bridge? I think I'll go there and jump off.

I just saw a flight in V formation of about 200 wild geese heading NW back home
along the Ottawa River. Now, they know the meaning of co-operation.

BFN.
Your script has nothing to do with the matter. :D :D :D If I haven't known you better from this forum, I might have concluded that you are, well, dumb, (okay, let's rather say stubborn). But I'm sure that's not the case..but I'm starting to wonder. You seem to be insecure about your script which is NOT under attack at all. :D :D :D

Post Reply