Is it time to reconsider putting Pale Moon browser in Puppy versions

[mikewalsh]

@geo_c :-

Re: just residing as a folder. Yes, of course it could! I was trying to think of a way to include one of the portable browsers without necessarily including another "x_drv".

It's all in its own directory anyway. I'm glad you're around to point out the obvious, mate, 'cos I'm one of these idiots who, if there's a "hard" or "awkward" way to do summat, I usually manage to find it.....

Mike.

[gyrog]

Unfortunately, I have to concur with Oz on this one. I know folks who have done this, and at a personal, individual, one-off level, it can be done (with a lot of patience).

Interresting.
Virtually limitless "?drv" sfs files has been done at least twice before, viewtopic.php?p=29811#p29811.

[ozsouth]

@gyrog - I know when I edited files in initrd.gz, init alone had dozens of entries (I just followed the pattern within init). There were, iirc, 3 other files needing editing. If you've found a way to bypass that, great!
Anyway, I think (for newbies especially) having Palemoon in a replaceable adrv to start with is simple enough & sufficient.

[greengeek]

If the browser is to reside in an "x-drv" it would be nice if it could be a "bdrv" - leaving adrv for personalisations (as i think adrv is the top level in most pups...?)

My version of geo_c 's idea would be to have several browsers in a bdrv. Either as pets, sfs, portables or appimages etc etc.
One of those browsers would be simple Dillo style for displaying Puppy's internal html stuff, and the others for the more complex online stuff.

I have found Palemoon a perfectly usable browser for standard helpfile/ html file display and it handles most of my online needs - especially in cutdown pups.

Will give the latest Palemoon a whirl.

[peebee]

(as i think adrv is the top level in most pups...?)

viewtopic.php?t=5818

The adrv, bdrv and ydrv read-only layers are located between the read-write layer and the Puppy layer and all take precedence over all the layers below them. The only difference between these 3 layers is their position, and hence precedence, in the stack - the order being adrv -> ydrv -> bdrv -> Puppy

[dimkr]

For years, the Puppy community has been debating the SFS stacking order (instead of reading the code or mount output, which tell the truth), debating the "intended purpose" of each SFS and posting "unofficial" patches that lift various arbitrary limitations (like the restriction to specific names for auto-loaded SFSs or the stacking order).

This is the init script. If you made any modifications to reduce its limitations and slowness, you can contribute your changes to woof-CE so every Puppy ships with an init script that makes everyone happy and nobody needs to replace and tweak it manually anymore.

If you don't want to push some of the patches floating around the forum, want to write something new and need some inspiration, this is a modified version I created that's used in Vanilla Dpup 11.0.x development builds. It's a stripped-down init script that removes some functionality (see README), like SAVEMARK or pdrv=, but it's smaller, faster and not stubborn about SFS names. It auto-loads *.sfs from the partition root or psubdir (SFSs can have any name, and user doesn't have to "queue" SFSs for loading) while retaining the stacking order of the "traditional" SFSs like adrv (backward compatibility with today's init script) and giving the user more control (SFSs with "non-traditional" names are sorted by name before loading so user can decide the stacking order). It's much faster and more scalable compared to the existing init script because it lists all SFSs in one sweep and loads all SFSs found in the correct order, instead of searching for the SFS on disk and loading it, for each SFS in the stacking order. The "search" part happens only once even if you have 50 SFSs to load, and this can make a big difference with a slow flash drive.

[ozsouth]

@dimkr - I like this init approach. Only issue for me is that I label all my partitions & use pdrv=(label). This means the working partition is found regardless of how many usb sticks I plug in or what order (I also specify hard drive partitions by label).

[dimkr]

@dimkr - I like this init approach. Only issue for me is that I label all my partitions & use pdrv=(label). This means the working partition is found regardless of how many usb sticks I plug in or what order (I also specify hard drive partitions by label).

You can use UUIDs instead of labels, I don't see the problem.

[gyrog]

Re: the 'init' script.

I agree, Puppy could use a new 'init' script.

But one without any "searching" at all.
You know the location when you install it.
You know the location when you boot it.
So, why should 'init' have to "guess".
There should be a boot parameter to define the partition, and another to define the relative directory of the install directory being booted, these could be "pdrv=" and "psubdir=" or even something else.

There should be a list of layers to mount into a read-only stack, in stack order.
Each layer could be specified by "<partition>:<relative path><filename>"
If the specification defines a ".sfs" file it's mount-point is used as the layer.
If the specificatioin defines a directory, it is used as the layer.
There are no default names, only a default/release list.
It would be easy to implement the current Puppy stack within this definition.

Then a save layer is added to the top of this read-only stack to produce the read/write / overlay.

I am prepared to work on such a project.

[greengeek]

The adrv, bdrv and ydrv read-only layers are located between the read-write layer and the Puppy layer and all take precedence over all the layers below them. The only difference between these 3 layers is their position, and hence precedence, in the stack - the order being adrv -> ydrv -> bdrv -> Puppy

So if I had a puppy which had an adrv or ydrv that contained Palemoon (or other browser) - could I simply rename that adrv / ydrv as "bdrv" and it would remain functional? (Allowing me to use adrv for my personalisations such as timezone, locale etc)?

[peebee]

The adrv, bdrv and ydrv read-only layers are located between the read-write layer and the Puppy layer and all take precedence over all the layers below them. The only difference between these 3 layers is their position, and hence precedence, in the stack - the order being adrv -> ydrv -> bdrv -> Puppy

So if I had a puppy which had an adrv or ydrv that contained Palemoon (or other browser) - could I simply rename that adrv / ydrv as "bdrv" and it would remain functional? (Allowing me to use adrv for my personalisations such as timezone, locale etc)?

Yes (dependent on the age of the Pup - i.e. recent Pups that support bdrv) - easiest is to do the quick and simple test.

[gyrog]

The 'init' script does not care about the contents of the various ?drv's, the names define only the order that they appear in the stack.
It's only limitation is that there must be a 'puppy_....sfs' file (no matter what it contains), all the others are optional.

[houndstooth]

Yes (dependent on the age of the Pup - i.e. recent Pups that support bdrv) - easiest is to do the quick and simple test.

Is there an account for the beginnings of bdrv support? I can see it mentioned in posts, e.g. LxPupSC, but not the first distros supporting. Fossa64? Bionic32? FocalPup32?

There's your browser.

Anyone?

[houndstooth]

I couldn't figure out how to disable cookies in Windows Firefox, so I just tried standalone Pale Moon for Windows & was impressed. I'm in Linux v31 Ethernet & just scored a speed diagnostic comparable to Chromium.

Pale Moon is an alphabet drive for the win.

UPDATE: Firefox cookies are disabled in the "Custom" privacy settings, after standard & "Strict", iow, you have to be looking for them. I guess Pale Moon is kind of the same, but I'm used to them. Neither are like Chromium.

[Narvic]

thanks to my time using puppy linux....I still use Seamonkey Browser everyday at work on my Windows machine.
Continues to do all I need it to do

[trawglodyte]

I kind of like when a Puppy distro comes with Pale Moon. It gets the job done, usually gives itself a quick update. Then people can get whatever browser they like or are commited to, and for most people it's not a bad thing to have Pale Moon as a backup or 2nd browser. If it came with Google Chrome, or really most others, I'd feel like I had to either uninstall it or go through settings and make sure it's "features" are shut off. I don't worry about Pale Moon, if I need it it's there and if I don't it's not bothering me.

Although it can be convenient to have a favorite browser with an account, passords, history, and so on.... it can also be REAL handy to have another one with none of that on it.

[houndstooth]

Is weight & distro size as important as website compatibility?

Should we assume all users will add a second browser?

Those are questions assuming a builtin browser, as badly as god wants us to let it go.

(v33 is released)

hack fix: viewtopic.php?p=112264#p112264