Lucid Puppy 5.2.8 - Updated ISO Version 005 - APR 05 2012
Seems to me placement of these entries are important. There is a logical order to what they are telling the boot process.
Basically where to look in this order:
PMEDIA (What device).
PDEV1 (What partition).
PSUBDIR (What directory or sub-directory).
I think all three have to be used, in a boot entry, to get the desired results.
This post is a little old, but it basically holds true to how it works.
http://www.murga-linux.com/puppy/viewtopic.php?t=35003
ICPUG,
You may want to look over this very well written info post.
Thanks for this, Helped me understand in my early days with Puppy.
Basically where to look in this order:
PMEDIA (What device).
PDEV1 (What partition).
PSUBDIR (What directory or sub-directory).
I think all three have to be used, in a boot entry, to get the desired results.
This post is a little old, but it basically holds true to how it works.
http://www.murga-linux.com/puppy/viewtopic.php?t=35003
ICPUG,
You may want to look over this very well written info post.
Thanks for this, Helped me understand in my early days with Puppy.
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
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Thanks for the link. I believe the processes are a bit more complicated then shown, but the post makes a good basis for further testing.bigpup wrote:...
This post is a little old, but it basically holds true to how it works.
http://www.murga-linux.com/puppy/viewtopic.php?t=35003
BTW - I've discovered an error in my methodology for determining which sfs was actually loaded (which provided three different desktops, one of which was not what it seemed - lupupluslibre).
It would help if I knew of a quick, simple, and certain way of determining which sfs is loaded (the two I'm using exclusively ant 582_005(standard -129MB) and lupupluslibre (353MB). All I can say for certain now is that when only one partition is automounted (red dot on icon), it means that both 2fs and sfs files were loaded from that partition, and when two are autoloaded, the one that isn't shown as /mnt/home is the one from which the sfs file was loaded.
I have come across at least two more anomalies in my testing - one is that pmedia=atahd , without further arguments, can sometimes result in a boot from sdb1 instead of sda1, even when both have intrd.gz and the sfs file.
I'll try to replicate and further define this later (my scribbled notes have proven inadequate).
The other is that when the sfs file is loaded from a different partition than the 2fs file, both are mounted, the latter as mnt/home, and writable, the former as dev_ro2 and write protected. This makes no sense to me at all, since /mnt/home is always writable when the sfs file is loaded from the same partition.
I have also discovered that pmedia=usbflash psubdir=pupsave results in a failure to find lupu_528.sfs, lockup of the system, even though pusave exists on the flash medium and both sfs and 2fs files are in it.
When pmedia=atahd psubdir=pupsave, OTOH, all pupsave directories on all partitions are shown with their 2fs files, and 528 is found and loaded successfully.
otropogo@gmail.com facebook.com/otropogo
Since my testbed seems to behave differently from that of the only other tester reporting, I'll try to limit myself to simply reporting my results, and let the readers draw their own conclusions.
All the tests below were conducted with the standard (129MB) and the(353MB) lupupluslibre Lupu_528.sfs.present. In every test, lupu was booted from a USBflash installation to an SD card inserted in an external card reader on a USB2.0 port.
The test PC has two SATA hard drives, with one partition on each drive, sda1 and sdb1. In this instance, the flash card was also partitioned (unlike the card in the previously reported tests) as sdd1. The last change made no apparent difference to response to the boot commands
The USBflash card had lupu standard and a couple of 2fs files in a folder named pupsave. And the final line of the syslinux.cfg file was edited for the test to read. The card was not edited throughout the series of tests, and I put it in write protected. But I forgot unreliability of the locking tab, and didn't check its write protect status. So it is possible that automatic processes were able to write to the card.
Sda1 contained one folder with the lupu standard sfs, and another with lupupluslibre version, and sdb1 contained one folder with lupu standard. Each folder had an initrd.gz file and was capable of loading lupu into RAM.
In the course of the testing, commands were entered at the boot command line and/or the names of the save folders modified, to assess the effects.
It was assumed at the outset that the 528 boot loader would look for and use sfs or 2fs files in priority order of drives (ie. sda1before sdb1) and folders within drives in alphabetical order (ie.sda1\ before sda1\a\ before sda1\b\), but the tests cast doubt on all of those assumptions.
Unexpected results are underlined.
Test 1. lupu std. in sda1/pupsav lupu+libre in sds1/pupsavr lupu std. in sdb1/pupsaveC
booted with alone
result: 2fs files in sdb1/pupsaveC offered for loading, on loading, sdb1 automounted, lupu standard loaded
Test 2. repeat of Test 1. no change
Test 3. entered
at boot command line
result: sda1/pupsav offered for loading, lupu standard loaded, sda1 automounted
Test 4. entered at command line
result: sda1/pupsaver offered for loading, lupu+libre loaded
Test 5. renamed sda1/pupsavr to sda1/pupsave, booted with alone
result: sdb1/pupsaveC offered for boot, lupu std loaded from sdb1
Test 6. repeat of Test 5. Same result\
Test 7. entered
at boot command line
result: sda1/pupsav offered for loading, lupu std loaded
Test 8. renamed sda1/pupsave > sda1/pusave528L, sda1/pupsav >sda1/528s and booted withonly
result: sda1/pupsave528s offered for loading, lupu std loaded
Test 9. reboot with command line entry
result: sda1/pupsave528L offered for loading, lupu+libre loaded
Test 10. reboot with only
result: sda1/pupsave528s offered for loading, lupu std. loaded
NB: this was tried with the two folders renamed variously, always placing the folder with the standard sfs in descending boot order from the lupu+libre one, but the folder with the standard sfs was always selected by the bootloader.
Test 11. renamed the two sda1 folders to sda1/528_1(2) and rebooted with alone
result: sdb1/pupsaveC offered for loading, lupu std loaded, sdb1 automounted.
Test 12 rebooted with command line entry
result: sda1/528_2 offered for loading, lupu std loaded
Test 13. renamed sda1/528_1 > sda1/pupsave, sda1/528_2 . sda/pupsave_2, sdb1/pupsaveC > sdb1/pupsave; copied lupu+libre sfs, 2fs, and initrd.gz to root directory of sda1 and rebooted with only
result: sdb1/pupsave offered for loading, lupu std loaded, both sda1 and sdb1automounted, sda1 read-only as /intitrd/mnt/dev_ro2, sdb1 as /mnt/home
Test 14. renamed sdb1/pupsave > sdb1/pupsaveC; deleted initrd.gz and lupu+libre sfs file from sda1\; copied lupu standard sfs and intird.gz from sdd1 to sda1\; booted with only pmedia=atahd
result: sdb1/pupsaveC offered for loading, loaded lupu std from sdb1
Test 15. booted with commandline entry
result: sda1/pupsave_b offered for loading, loaded lupu std from sda1
Test 16. rebooted with alone
result: sda1/pupsave_b offered for loading, loaded lupu std from sda1
Test 17. booted with commandline entry
result: both sdd1/pupsave and sda1/pupsave offered for loading, chose 2fs from sda1, loaded lupu+libre from sda1
Test 18. booted with commandline entry puppy again, but chose 2fs file from sdd1, sdd1 automounted as /mnt/home, sda1 automounted as
initrd/mnt/dev_ro_2, both writeable. Not sure which sfs version is loaded, as libre office suite is only shown as a download link in the menu, but when a libreoffice write file is left clicked, it opens in libreoffice writer...
It seems to me that these results differ significantly from the behaviour described in bigpup's link. The 528 loader seems to have a distinct preference for booting the standard sfs, an aversion to sfs in the root directory, and a preference for folders named "pup..." or "save".
There also seems to be some sort of dynamic in which having been forced once to boot in proper drive sequence by, it will then do it on reboot without the command.
I trust these notes are detailed enough that anyone with a usb-enabled PC and two hard drives will be able to replicate my tests. My notes got a little messy toward the end, so it is possible that some errors have crept in. I'd be happy to retest any results that cannot be replicated by others on a similarly configured machine.
All the tests below were conducted with the standard (129MB) and the(353MB) lupupluslibre Lupu_528.sfs.present. In every test, lupu was booted from a USBflash installation to an SD card inserted in an external card reader on a USB2.0 port.
The test PC has two SATA hard drives, with one partition on each drive, sda1 and sdb1. In this instance, the flash card was also partitioned (unlike the card in the previously reported tests) as sdd1. The last change made no apparent difference to response to the boot commands
The USBflash card had lupu standard and a couple of 2fs files in a folder named pupsave. And the final line of the syslinux.cfg file was edited for the test to read
Code: Select all
pmedia=atahd
Sda1 contained one folder with the lupu standard sfs, and another with lupupluslibre version, and sdb1 contained one folder with lupu standard. Each folder had an initrd.gz file and was capable of loading lupu into RAM.
In the course of the testing, commands were entered at the boot command line and/or the names of the save folders modified, to assess the effects.
It was assumed at the outset that the 528 boot loader would look for and use sfs or 2fs files in priority order of drives (ie. sda1before sdb1) and folders within drives in alphabetical order (ie.sda1\ before sda1\a\ before sda1\b\), but the tests cast doubt on all of those assumptions.
Unexpected results are underlined.
Test 1. lupu std. in sda1/pupsav lupu+libre in sds1/pupsavr lupu std. in sdb1/pupsaveC
booted with
Code: Select all
pmedia=atahd
result: 2fs files in sdb1/pupsaveC offered for loading, on loading, sdb1 automounted, lupu standard loaded
Test 2. repeat of Test 1. no change
Test 3. entered
Code: Select all
puppy pdev1=sda1
result: sda1/pupsav offered for loading, lupu standard loaded, sda1 automounted
Test 4. entered
Code: Select all
puppy psubdir=pupsavr
result: sda1/pupsaver offered for loading, lupu+libre loaded
Test 5. renamed sda1/pupsavr to sda1/pupsave, booted with
Code: Select all
pmedia=atahd
result: sdb1/pupsaveC offered for boot, lupu std loaded from sdb1
Test 6. repeat of Test 5. Same result\
Test 7. entered
Code: Select all
puppy pdev1=sda1
result: sda1/pupsav offered for loading, lupu std loaded
Test 8. renamed sda1/pupsave > sda1/pusave528L, sda1/pupsav >sda1/528s and booted with
Code: Select all
pmedia=atahd
result: sda1/pupsave528s offered for loading, lupu std loaded
Test 9. reboot with command line entry
Code: Select all
puppy pdev1=pupsave528L
Test 10. reboot with only
Code: Select all
pmedia=atahd
NB: this was tried with the two folders renamed variously, always placing the folder with the standard sfs in descending boot order from the lupu+libre one, but the folder with the standard sfs was always selected by the bootloader.
Test 11. renamed the two sda1 folders to sda1/528_1(2) and rebooted with
Code: Select all
pmedia=atahd
result: sdb1/pupsaveC offered for loading, lupu std loaded, sdb1 automounted.
Test 12 rebooted with command line entry
Code: Select all
puppy pdev1=sda1
Test 13. renamed sda1/528_1 > sda1/pupsave, sda1/528_2 . sda/pupsave_2, sdb1/pupsaveC > sdb1/pupsave; copied lupu+libre sfs, 2fs, and initrd.gz to root directory of sda1 and rebooted with
Code: Select all
pmedia=atahd
result: sdb1/pupsave offered for loading, lupu std loaded, both sda1 and sdb1automounted, sda1 read-only as /intitrd/mnt/dev_ro2, sdb1 as /mnt/home
Test 14. renamed sdb1/pupsave > sdb1/pupsaveC; deleted initrd.gz and lupu+libre sfs file from sda1\; copied lupu standard sfs and intird.gz from sdd1 to sda1\; booted with only pmedia=atahd
result: sdb1/pupsaveC offered for loading, loaded lupu std from sdb1
Test 15. booted with commandline entry
Code: Select all
puppy pdev1=sda1
Test 16. rebooted with
Code: Select all
pmedia=atahd
result: sda1/pupsave_b offered for loading, loaded lupu std from sda1
Test 17. booted with commandline entry
Code: Select all
puppy psubdir=pupsave
Test 18. booted with commandline entry puppy
Code: Select all
psubdir=pupsave
initrd/mnt/dev_ro_2, both writeable. Not sure which sfs version is loaded, as libre office suite is only shown as a download link in the menu, but when a libreoffice write file is left clicked, it opens in libreoffice writer...
It seems to me that these results differ significantly from the behaviour described in bigpup's link. The 528 loader seems to have a distinct preference for booting the standard sfs, an aversion to sfs in the root directory, and a preference for folders named "pup..." or "save".
There also seems to be some sort of dynamic in which having been forced once to boot in proper drive sequence by
Code: Select all
puppy pdev1=sda1
I trust these notes are detailed enough that anyone with a usb-enabled PC and two hard drives will be able to replicate my tests. My notes got a little messy toward the end, so it is possible that some errors have crept in. I'd be happy to retest any results that cannot be replicated by others on a similarly configured machine.
otropogo@gmail.com facebook.com/otropogo
Thanks for the info Otropogo and the kind comments on my previous post bigpup.
I must emphasise that the post I wrote before was written after I had flowcharted the init in series 3 pups. Hopefully, all the comments about search not being faster are negated by the init in use today. I think that was one of the reasons Barry undertook to rewrite the search routines.
I can confirm Otropogo's comment that things may well be more complicated now - the init script certainly is - 8 A4 pages of script for finding files and 12 more for loading them!
One significant difference betwen my system and Otropogo's is that I don't use usb installs. Maybe there is something in the current init scripts that is not quite right when usb is used.
I have not read Otropogo's detailed notes fully, yet, but I will make a couple of comments:
/etc/rc.d/PUPSTATE
As you can see from my comment above I have printed the init from Standard Lupu and made a start at deciphering it (with the side effect of finding some debugging boot codes I never knew/forgot about!). if I ever decipher the search scripts we can go through Otropogo's test notes to confirm them. I need to complete the decyphering in order to update that previous post of mine ...
I must emphasise that the post I wrote before was written after I had flowcharted the init in series 3 pups. Hopefully, all the comments about search not being faster are negated by the init in use today. I think that was one of the reasons Barry undertook to rewrite the search routines.
I can confirm Otropogo's comment that things may well be more complicated now - the init script certainly is - 8 A4 pages of script for finding files and 12 more for loading them!
One significant difference betwen my system and Otropogo's is that I don't use usb installs. Maybe there is something in the current init scripts that is not quite right when usb is used.
I have not read Otropogo's detailed notes fully, yet, but I will make a couple of comments:
When I was testing I simply fired up the Word Processor from the desktop icon. If I got Abiword it was standard Lupu. If I got LibreOffice Write it was Lupupluslibre. Also you can have a look at the file:It would help if I knew of a quick, simple, and certain way of determining which sfs is loaded (the two I'm using exclusively ant 582_005(standard -129MB) and lupupluslibre (353MB).
/etc/rc.d/PUPSTATE
The only thing that has to be written to is the save file. It makes sense to me that the partition with the save file has to writeable. If the sfs is on a different partition then it seems reasonable from a security viewpoint that this is not writeable.The other is that when the sfs file is loaded from a different partition than the 2fs file, both are mounted, the latter as mnt/home, and writable, the former as dev_ro2 and write protected. This makes no sense to me at all, since /mnt/home is always writable when the sfs file is loaded from the same partition.
As you can see from my comment above I have printed the init from Standard Lupu and made a start at deciphering it (with the side effect of finding some debugging boot codes I never knew/forgot about!). if I ever decipher the search scripts we can go through Otropogo's test notes to confirm them. I need to complete the decyphering in order to update that previous post of mine ...
Thanks. My method of simply looking at the start menu for libre office wasn't effective, as when booting with the 2fs file located on the flash card sdd1/pupsave, only the entry "download libreoffice" appeared. But when I opened an rtf file, it used libreoffice writer.ICPUG wrote:..
One significant difference betwen my system and Otropogo's is that I don't use usb installs. Maybe there is something in the current init scripts that is not quite right when usb is used.
...
I have not read Otropogo's detailed notes fully, yet, but I will make a couple of comments:
When I was testing I simply fired up the Word Processor from the desktop icon. If I got Abiword it was standard Lupu. If I got LibreOffice Write it was Lupupluslibre. Also you can have a look at the file:
/etc/rc.d/PUPSTATE
/etc.rc.d/PUPSTATE confirmed that the sfs file in sda1/pupsave was in use.
I have since discovered that the automounted /intrd/mnt/dev_ro2 file is not always write protected, perhaps even not usually. Unfortunately, my notes don't shed any light on the peculiarities, if any, of the two instances when it was write protected.The other is that when the sfs file is loaded from a different partition than the 2fs file, both are mounted, the latter as mnt/home, and writable, the former as dev_ro2 and write protected. This makes no sense to me at all, since /mnt/home is always writable when the sfs file is loaded from the same partition.
I don't think it's sensible to write protect an entire partition just because the 2fs file is on it. In fact, it seems to me that the system will not let one edit the copy of the sfs file in memory in any case.The only thing that has to be written to is the save file. It makes sense to me that the partition with the save file has to writeable. If the sfs is on a different partition then it seems reasonable from a security viewpoint that this is not writeable..
OTOH, this issue prompted me to try as an experiment booting using the 2fs file on the USB flash card with the write protect tab set to lock. Puppy loaded and shut down unremarkably, EXCEPT that the usual message line saying that the 2fs file was already saved didn't appear.
I would suggest that some modidication of the shut-down process would be very helpful for those using usbflash to boot - namely, that the writability of the medium should be checked, and if locked, an option should be given to the user to unlock it and save the 2fs before shutting down.
Conversely, it would be a handy option, especially for testing purposes, to be able to set the system to ask before saving the 2fs file (since not all flash media have physical write protection tabs). This is considerably more convenient than waiting for the system to back up a 1GB+ 2fs file (especially via usb2), and makes recovery from an installation disaster or running out of personal storage much easier.
Remember also that when booting from USBflash, the loader relies on the syslinux.cfg file on the flash medium, regardless of the location of the 2fs file used. If the flash card were autolocked by a given configuration, it would require booting via another means to change the boot parameters.
I have just run a few more tests and checked the results with PUPSTATE:
Test 1 with
Code: Select all
pmedia=atahd psubdir=pupsave
sdd1 automounted as /mnt/home
sda1 automounted as /initrd/mnt/dev_ro2
both writable, lupu+libre loaded from sda1/pupsave
Test 2. removed
Code: Select all
psubdir=pupsave
Result: only the content of sdb1/pupsaveC was presented for loading, and 528 standard was loaded into RAM from that directory
Test 3. rebooted and added the argument
Code: Select all
pdev1=sda1
Code: Select all
pmedia=atahd
So, why does the loader choose to use sda1/pupsave over sb1/pupsave when the boot command is
Code: Select all
pmedia=atahd psubdir=pupsave
chooses to use sb1/pupsave over both sda1/pupsave and sda1/pupsave_b, when the psubdir argument is left out?
otropogo@gmail.com facebook.com/otropogo
-
- Posts: 902
- Joined: Mon 22 Jun 2009, 01:36
- Location: Philadelphia, PA
gtkdialog 0.8.3
The newest Pmusic requires gtkdialog 0.8.3
Where is a version of gtkdialog 0.8.3 which works under Lucid puppy? My primary Puppy is Lucid 5.2.8-005
Thanks,
Sheldon
Where is a version of gtkdialog 0.8.3 which works under Lucid puppy? My primary Puppy is Lucid 5.2.8-005
Thanks,
Sheldon
I put together a package for Barrry' Kauler's Precise distro.Where is a version of gtkdialog 0.8.3
It should work for Lucid.
Try it and report back...
http://www.murga-linux.com/puppy/viewto ... 831#677831
_______________________________________
-
- Posts: 902
- Joined: Mon 22 Jun 2009, 01:36
- Location: Philadelphia, PA
gtkdialog 0.8.3 etc
Thank you very much, don570; it does indeed work.don570 wrote:I put together a package for Barrry' Kauler's Precise distro.Where is a version of gtkdialog 0.8.3
It should work for Lucid.
Try it and report back...
http://www.murga-linux.com/puppy/viewto ... 831#677831
I copied the gtkdialog4 file:
~> which gtkdialog
/usr/bin/gtkdialog
~>
~> gtkdialog -v
gtkdialog version 0.8.4 r503M (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with additional support for: Glade.
~>
Hi.
Here is my output on gtkdialog:
GtkDialog, which is a link to gtkdialog3
GtkDialog4
GtkDialog5
I have downloaded the above linked .pet and found a binary named gtkdialog4.
So, how did you get this output from a gtkdialog4 binary?
Is gtkdialog4 the right name for this binary?
Please explain...
Thanks
RSH
Here is my output on gtkdialog:
GtkDialog, which is a link to gtkdialog3
Code: Select all
sh-4.1# gtkdialog -v
gtkdialog version 0.7.21 (C) 2004, 2005, 2006, 2007 by Laszlo Pere
Code: Select all
sh-4.1# gtkdialog4 -v
gtkdialog version 0.8.0 (C) 2003-2007 Laszlo Pere, 2011 Thunor
Code: Select all
sh-4.1# gtkdialog5 -v
gtkdialog version 0.8.2 release (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
So, how did you get this output from a gtkdialog4 binary?
Code: Select all
~> gtkdialog -v
gtkdialog version 0.8.4 r503M (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with additional support for: Glade.
~>
Please explain...
Thanks
RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
-
- Posts: 902
- Joined: Mon 22 Jun 2009, 01:36
- Location: Philadelphia, PA
(portions snipped)
Clicking the pet resulted in the binary gtkdialog4 being placed into
/usr/sbin
I copied that file into /usr/bin and renamed it to gtkdialog
It was one approach to dealing with the way gtkdialog is used by Pmusic.
Thanks,
Sheldon
RSH, please excuse any unclearness.RSH wrote: I have downloaded the above linked .pet and
found a binary named gtkdialog4.
So, how did you get this output from a gtkdialog4 binary?
Is gtkdialog4 the right name for this binary?Code: Select all
~> gtkdialog -v gtkdialog version 0.8.4 r503M (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor Built with additional support for: Glade. ~>
Clicking the pet resulted in the binary gtkdialog4 being placed into
/usr/sbin
I copied that file into /usr/bin and renamed it to gtkdialog
It was one approach to dealing with the way gtkdialog is used by Pmusic.
Thanks,
Sheldon
I think you did not really understand my question the right way.
As you can see in my gtkdialog output, the gtkdialog4 binary version is 0.8.0
You posted a gtkdialog version 0.8.4 - also from a gtkdialog4 binary.
I want to know:
- is this file wrong renamed to gtkdialog4 after compiling?
- or is every new gtkdialog binary 0.8.0 and above renamed after compiling to gtkdialog4 - from now on
Thanks
RSH
Edit:
Or will this confusing all users/developers of Puppy Linux in the future and therefor adding a big minus to the related big list of minuses on installing and using applications?
As you can see in my gtkdialog output, the gtkdialog4 binary version is 0.8.0
You posted a gtkdialog version 0.8.4 - also from a gtkdialog4 binary.
I want to know:
- is this file wrong renamed to gtkdialog4 after compiling?
- or is every new gtkdialog binary 0.8.0 and above renamed after compiling to gtkdialog4 - from now on
Thanks
RSH
Edit:
Or will this confusing all users/developers of Puppy Linux in the future and therefor adding a big minus to the related big list of minuses on installing and using applications?
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
Shouldn't you guys stick to the same naming convention that
Barry Kauler uses. He hasn't advanced to gtkdialog5.
I try to stick to his methods as close as possible.
Barry likes to make gtkdialog4 the application and gtkdialog the link.
This is an image of Exprimo which does it differently.
__________________________________________
Barry Kauler uses. He hasn't advanced to gtkdialog5.
I try to stick to his methods as close as possible.
Barry likes to make gtkdialog4 the application and gtkdialog the link.
This is an image of Exprimo which does it differently.
__________________________________________
I follow the logic explained by 01micko at some time when the debate about gtkdialog naming was hot. Due to incompatilities of improved version at that time. I wont go to the details. They can be found from the gtkdialog thread.
But 01micko posted this idea, to use one improved gtkdialog binary only...and the others are symlinks. If there is incompatibility the idea was that those gtkdialog apps should be updated by the developer.
I have gone with this logic since then...as 01micko.
So....there is diversity...Barry Kauler do the naming his way....some others other way. But there has not been much problems with it,
Also....01micko and I use the latest gtkdialog version at the time. Barry updates woof slower.
But 01micko posted this idea, to use one improved gtkdialog binary only...and the others are symlinks. If there is incompatibility the idea was that those gtkdialog apps should be updated by the developer.
I have gone with this logic since then...as 01micko.
So....there is diversity...Barry Kauler do the naming his way....some others other way. But there has not been much problems with it,
Also....01micko and I use the latest gtkdialog version at the time. Barry updates woof slower.
exactly...I wish everyone was on board with this approach...but......pemasu wrote:
But 01micko posted this idea, to use one improved gtkdialog binary only...and the others are symlinks. If there is incompatibility the idea was that those gtkdialog apps should be updated by the developer.
I have gone with this logic since then...as 01micko
BTW/ update JWM-653, since it now works with java...thanks to 01micko kicking butt....
I don't know if you got around to reposting a working JRE in the SFS directory. I posted one the other board, but there's probably some new versions on the way.
-
- Posts: 902
- Joined: Mon 22 Jun 2009, 01:36
- Location: Philadelphia, PA
(portions snipped)
I had installed the one that don570 made
http://www.murga-linux.com/puppy/viewto ... 831#677831
I did the below, and Pmusic (which looks for gtkdialog) starts normally.
Thanks to all for your posts on this issue.pemasu wrote:I follow the logic explained by 01micko ..
.. to use one improved gtkdialog binary only...and the others are symlinks.
I had installed the one that don570 made
http://www.murga-linux.com/puppy/viewto ... 831#677831
I did the below, and Pmusic (which looks for gtkdialog) starts normally.
Code: Select all
/usr/sbin> ln -s gtkdialog4 gtkdialog
/usr/sbin> which gtkdialog
/usr/sbin/gtkdialog
Re: How does puppy's flash boot loader pick the sfs file?
I just saw an interesting comment from ETP regarding sfs and savefile discovery here:otropogo wrote:Have just completed a dizzying series of test with a newly configured USBflash boot card, trying to figure out how to control which version of the lupu_528.sfs file is loaded.
http://www.murga-linux.com/puppy/viewto ... &start=278
Possibly all puppies may benefit from further work/understanding in this area. Time consuming and tricky to cover all contingencies though.
Re: How does puppy's flash boot loader pick the sfs file?
Thanks for the link. Have responded to ETP's post there.greengeek wrote:I just saw an interesting comment from ETP regarding sfs and savefile discovery here:otropogo wrote:Have just completed a dizzying series of test with a newly configured USBflash boot card, trying to figure out how to control which version of the lupu_528.sfs file is loaded.
http://www.murga-linux.com/puppy/viewto ... &start=278
Possibly all puppies may benefit from further work/understanding in this area. Time consuming and tricky to cover all contingencies though.
otropogo@gmail.com facebook.com/otropogo
new backgrounds.
- Attachments
-
- lucidja20,1a.jpg
- http://www.mediafire.com/?7v1msw26s6chb
- (35.35 KiB) Downloaded 850 times
-
- lucidja20,1.jpg
- http://www.mediafire.com/?7v1msw26s6chb
- (55.63 KiB) Downloaded 847 times
regarding installing chrome, are the following two steps still required for the latest packages?
http://puppylinux.org/wikka/Chrome1. First, please uninstall any Iron, Chromium, or Chrome pets.
2. Second, install this libgconf2-4_3.1.6 pet.
libgconf2-4_3.1.6.pet
Its been soon a year since last version of this excellent Puppy was released (5.2.8.005)... Now I wonder if there are anyone around with the idea of releasing a newer version like a 006. We are then close to the 007 version, that I feel could have a slight James Bond theme:-)
I think 5.2.8 has a long life as Precise might never overcome the problematic PAE issue, that makes it useless to me, as its no longer one distro for all, but two versions of the same whereas some works on this and other on that machine. Very confusing for most users and also a small step backwards in the sense of users loosing faith in the distro as one downloads the "flagship" and it does not even boot if this and that hardware is not present.
I seem to remember that Lucid newer missed out on one single boot for as long as I can remember.
Anyhow... Anyone with ideas about a new version of Lucid?
Best
Atle
I think 5.2.8 has a long life as Precise might never overcome the problematic PAE issue, that makes it useless to me, as its no longer one distro for all, but two versions of the same whereas some works on this and other on that machine. Very confusing for most users and also a small step backwards in the sense of users loosing faith in the distro as one downloads the "flagship" and it does not even boot if this and that hardware is not present.
I seem to remember that Lucid newer missed out on one single boot for as long as I can remember.
Anyhow... Anyone with ideas about a new version of Lucid?
Best
Atle