Brave 'portable' - 64-bit only - now includes manual updater from Fred...

[fredx181]

The installation that has problems (and maintains previous bookmarks and settings) is here:
/mnt/nvme0n1p4/Brave browser/Brave-portable64

Just to mention, don't know if it's a typo, the path to Brave-portable64 cannot contain space(s) (Brave<space>browser)
Better remove the space, so becomes e.g. /mnt/nvme0n1p4/Bravebrowser/Brave-portable64 .

edit: Try what williwaw said, perhaps the profile folder that you copied is the profile folder from the older setup on FAT32 ? (I'd really advice to forget about the settings you earlier made and start "fresh")

[Governor]

@fredx181

I downloaded a "fresh" copy of Brave and installed it on an ext4 partition. It ran fine.
I copied the fresh Brave installation to another folder on the same ext4 drive and the peculiar message is back............

Not only that, but my settings and bookmarks from the previous installation are present. How is this possible?

you broke something in your profile when you moved the app?
rename the profile folder and see if the app will create a new one.

I deleted this folder: /mnt/nvme0n1p4/Brave browser/Brave-portable64

And I copied this folder: /mnt/nvme0n1p4/Downloads/Browsers/Brave-portable64
to: /mnt/nvme0n1p4/Brave browser/ (to take its place).

The installation that has problems (and maintains previous bookmarks and settings) is here:
/mnt/nvme0n1p4/Brave browser/Brave-portable64

I deleted the profile folder:
/mnt/nvme0n1p4/Brave browser/Brave-portable64/PROFILE/spot/Brave-Browser

I then ran the launch script here:
/mnt/nvme0n1p4/Brave browser/Brave-portable64/LAUNCH

Although a new profile was created (which is empy), there is no change.

I get the same result as before

Meanwhile the installation I copied from runs without error.
/mnt/nvme0n1p4/Downloads/Browsers/Brave-portable64/LAUNCH

[fredx181]

@Governor

Just to mention, don't know if it's a typo, the path to Brave-portable64 cannot contain space(s) (Brave<space>browser)
Better remove the space, so becomes e.g. /mnt/nvme0n1p4/Bravebrowser/Brave-portable64 .

Again, remove the space in the folder name, change (rename) "Brave browser" to "Bravebrowser" (or whatever, but should be without space(s) ).
The problem will probably be solved then.. (edit: better late than never )
(it's a limitation, I know, the LAUNCH script would need a change to support path with spaces, in the meantime it should work fine without the space(s) in the path).

edit:

Meanwhile the installation I copied from runs without error.
/mnt/nvme0n1p4/Downloads/Browsers/Brave-portable64/LAUNCH

Exactly, because that path is without spaces.

[Governor]

@Governor

Just to mention, don't know if it's a typo, the path to Brave-portable64 cannot contain space(s) (Brave<space>browser)
Better remove the space, so becomes e.g. /mnt/nvme0n1p4/Bravebrowser/Brave-portable64 .

Again, remove the space in the folder name, change (rename) "Brave browser" to "Bravebrowser" (or whatever, but should be without space(s) ).
The problem will probably be solved then.. (edit: better late than never )
(it's a limitation, I know, the LAUNCH script would need a change to support path with spaces, in the meantime it should work fine without the space(s) in the path).

edit:

Meanwhile the installation I copied from runs without error.
/mnt/nvme0n1p4/Downloads/Browsers/Brave-portable64/LAUNCH

Exactly, because that path is without spaces.

Wow. That worked.
Thanks!

I am not even going to ask about why spaces are sometimes allowed and sometimes not allowed.

[fredx181]

@Governor
Ok, nice, finally solved !

I am not even going to ask about why spaces are sometimes allowed and sometimes not allowed.

Will try to explain anyway (no rocket science )
The trick to support path with spaces is to add double quotes around all instances of $HERE (in this case $HERE is where the LAUNCH script is located)
If the last block of the LAUNCH script would be as below code, then a path with spaces will be supported.
(changed e.g. --user-data-dir=$HERE/PROFILE/spot/Brave-Browser (originally without quotes around $HERE) to --user-data-dir="$HERE"/PROFILE/spot/Brave-Browser)

Code: Select all

### fredx181, 2024-05-10 Add double quotes around all instances of $HERE
### so no problems when running from a path containing spaces
if  grep -q 'Quirky April64' /etc/DISTRO_SPECS
then
	LD_LIBRARY_PATH="$HERE"/:"$HERE"/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
	run-as-spot "$HERE/brave/brave" --user-data-dir="$HERE"/PROFILE/spot/Brave-Browser --disk-cache-size=5000000 --media-cache-size=5000000 --allow-outdated-plugins "$@"
else
	run-as-spot "$HERE/brave/brave" --user-data-dir="$HERE"/PROFILE/spot/Brave-Browser --disk-cache-size=5000000 --media-cache-size=5000000 --allow-outdated-plugins --test-type "$@"
fi

[geo_c]

The trick to support path with spaces is to add double quotes around all instances of $HERE (in this case $HERE is where the LAUNCH script is located)

This bit of information is HUGELY helpful to a big scripting project I'm currently working on!

[rockedge]

@fredx181 That's a really cool observation....very useful

[geo_c]

The trick to support path with spaces is to add double quotes around all instances of $HERE (in this case $HERE is where the LAUNCH script is located)

And does this work for $variables in general? like one created by a read -p input?

EDIT: YES IT DOES!

[Governor]

@Governor
Ok, nice, finally solved !

I am not even going to ask about why spaces are sometimes allowed and sometimes not allowed.

Will try to explain anyway (no rocket science )
The trick to support path with spaces is to add double quotes around all instances of $HERE (in this case $HERE is where the LAUNCH script is located)
If the last block of the LAUNCH script would be as below code, then a path with spaces will be supported.
(changed e.g. --user-data-dir=$HERE/PROFILE/spot/Brave-Browser (originally without quotes around $HERE) to --user-data-dir="$HERE"/PROFILE/spot/Brave-Browser)

Code: Select all

### fredx181, 2024-05-10 Add double quotes around all instances of $HERE
### so no problems when running from a path containing spaces
if  grep -q 'Quirky April64' /etc/DISTRO_SPECS
then
	LD_LIBRARY_PATH="$HERE"/:"$HERE"/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
	run-as-spot "$HERE/brave/brave" --user-data-dir="$HERE"/PROFILE/spot/Brave-Browser --disk-cache-size=5000000 --media-cache-size=5000000 --allow-outdated-plugins "$@"
else
	run-as-spot "$HERE/brave/brave" --user-data-dir="$HERE"/PROFILE/spot/Brave-Browser --disk-cache-size=5000000 --media-cache-size=5000000 --allow-outdated-plugins --test-type "$@"
fi

Ok, I get that. It is very similar to Windows.
Thanks.

I still think it odd that with the broken folder name (unquoted with encapsulated space), my previous Brave browser settings and bookmarks showed up, even though the profile folder was empty.

[mikewalsh]

@geo_c :-

I think you can also use 'round' brackets - not 'square' or 'curly' - like the following example. It's part of a script from my CamRecord 'portable'.....where it sets up variables for the final 'exec' line, calling these from wee text files saved within the app itself:-

Code: Select all

HERE="$(dirname "$(readlink -f "$0")")"
AUDIO=$(cat $HERE/SOURCES/CONFIG/audio.txt)
VIDEO=$(cat $HERE/SOURCES/CONFIG/cam.txt)
FRAME=$(cat $HERE/SOURCES/CONFIG/frame.txt)
RESOLUTION=$(cat $HERE/SOURCES/CONFIG/res.txt)

I think that's right in THIS context....?

Mike.

[fredx181]

Code: Select all

HERE="$(dirname "$(readlink -f "$0")")"
AUDIO=$(cat $HERE/SOURCES/CONFIG/audio.txt)
...

If there are one or more space(s) in the $HERE path, cat cannot find audio.txt, so should be with quotes around $HERE e.g. AUDIO=$(cat "$HERE"/SOURCES/CONFIG/audio.txt)

[fredx181]

I still think it odd that with the broken folder name (unquoted with encapsulated space), my previous Brave browser settings and bookmarks showed up, even though the profile folder was empty

Could be in /root/.config/BraveSoftware/ (default) , as brave couldn't successfully use the PROFILE folder (because of the space in path) , it creates (and reads from) the default location.

[Governor]

I still think it odd that with the broken folder name (unquoted with encapsulated space), my previous Brave browser settings and bookmarks showed up, even though the profile folder was empty

Could be in /root/.config/BraveSoftware/ (default) , as brave couldn't successfully use the PROFILE folder (because of the space in path) , it creates (and reads from) the default location.

Thanks. I figured it had to be somewhere.
I rebooted since then, and the space in path problem is fixed, and /root/.config/BraveSoftware/ is not there now.

[mikewalsh]

Code: Select all

HERE="$(dirname "$(readlink -f "$0")")"
AUDIO=$(cat $HERE/SOURCES/CONFIG/audio.txt)
...

If there are one or more space(s) in the $HERE path, cat cannot find audio.txt, so should be with quotes around $HERE e.g. AUDIO=$(cat "$HERE"/SOURCES/CONFIG/audio.txt)

Oh, I agree Fred....absolutely. I learnt that lesson years ago, and never put spaces into anything that I build myself. If I want to separate things, I always use an underscore these days ( _ ) or a dash ( - ).

About the only time I need to use quotes round anything is in the launcher scripts for my Windows apps running under WINE.....because it insists on mirroring the Windows layout - I guess it HAS to! - vis-a-vis, "Program Files" (with a space in between).

It's good advice, and worth learning. Even for the average Puppian who simply uses their system, and never does anything like compiling or packaging.....because there ARE the odd few Linux apps that pull the same stunt. (Master PDF Editor comes to mind; one of the config directories is named "Code Industry"...)

(*shrug...*)

Mike.

[FeodorF]

Hello @mikewalsh , hello @fredx181 .

I gave your Brave-portable64 a spin (updated to v. 1.69.168). Video and sound works fine on Bookworm64-10.0.7 but sound fails on EasyOS-6.3 . The reason is that Bookworm uses pipewire were as EasyOS uses pulseaudio. Any idea how to solve this problem?

Regards,
Feodor

EasyOS-6.3:
/etc/alsa/conf.d/50-pulseaudio.conf

Code: Select all

  # Add a specific named PulseAudio pcm and ctl (typically useful for testing)

pcm.pulse {
	@args [ DEVICE ]
	@args.DEVICE {
		type string
		default ""
	}
	type pulse
	device $DEVICE
	hint {
		show {
			@func refer
			name defaults.namehint.basic
		}
		description "PulseAudio Sound Server"
	}
}

ctl.pulse {
	@args [ DEVICE ]
	@args.DEVICE {
		type string
		default ""
	}
	type pulse
	device $DEVICE
}

/etc/alsa/conf.d/99-pulseaudio-default.conf

Code: Select all

# Default to PulseAudio

pcm.!default {
    type pulse
    hint {
        show on
        description "Default ALSA Output (currently PulseAudio Sound Server)"
    }
}

ctl.!default {
    type pulse
}

[mikewalsh]

@FeodorF :-

If I could help with this one, I would.....but I think Fred might be better placed to help here (or indeed, anyone that understands these two). I'm a "straight" ALSA man; I've always hated PulseAudio (so have never become proficient with its quirks).....and I don't know the first thing about PipeWire, because I've never used it.

So as you can see, I couldn't help even if I wanted to. This has got nothing to do with the browser, per se.....it's to do with the audio subsystem. Although I can help with a lot of things, the intricacies of the Linux audio subsystem are not one of them.....

Sorry about that.

Mike.

[fredx181]

@FeodorF
Not sure, but I think running Brave as spot (as Mike's setup is) has working sound on BookwormPup because it has Pipewire running as spot, difference with EasyOs may be that Pulseaudio is running as root and therefore that sound doesn't work .
Anyway, if you want, you can try running Brave-portable as root, good chance that sound works, then change content of the LAUNCH script to this:

Code: Select all

#!/bin/sh
# Launcher for 'portable' Brave browser (fredx181, change, running as root with --no-sandbox option, instead of running as spot)

HERE="$(dirname "$(readlink -f "$0")")"

mkdir -p "$HERE/PROFILE"

"$HERE/brave/brave" --user-data-dir="$HERE"/PROFILE --disk-cache-size=50000000 --media-cache-size=50000000 --allow-outdated-plugins --no-sandbox --disable-infobars --test-type "$@"

@mikewalsh

.....and I don't know the first thing about PipeWire, because I've never used it.

If you ever have used BookwormPup (and played any sound), you are guilty of having used pipewire

[mikewalsh]

@mikewalsh

.....and I don't know the first thing about PipeWire, because I've never used it.

If you ever have used BookwormPup (and played any sound), you are guilty of having used pipewire

@fredx181 :-

Hah! In that case, yup; "guilty as charged", mate.......but only briefly, 'cos I HAVE only taken a "look-see" thus far.

I'm typically a very late adopter with new Pups; they're usually between 3-4 yrs old before I make them a "daily driver".......and with the current crop, there's not just a few changes, there's TONS of 'em (all at the same time.....and many leading back to what I was trying very hard to get away from when originally coming to Puppy a decade ago).

Much of it I am familiar with.....but a lot of it I don't like. I absolutely hate Synaptic, for one thing; it was a PITA to use 10 yrs ago, and it's STILL a PITA today. I CAN use it - I know how to - but I will never like it.

I'm a dinosaur, mate. So sue me....!! (I mean, look how long it took me to finally admit that shinobar's Grub2config was probably "okay"......after lots of "encouragement" from many others in the community. I have bad recollections of many of these tools from my early Linux days.....and I have a LONG memory, at that.)

(*shrug...*)

Mike.

[fredx181]

Hah! In that case, yup; "guilty as charged", mate.......but only briefly, 'cos I HAVE only taken a "look-see" thus far.

Ah. ok, you didn't "inhale", well... then you are "clean".

I'm a dinosaur, mate. So sue me....!!

No, we won't prosecute you any further. Why? Because it's a human right to be conservative IMO and... even if you persist being conservative your whole remaining life, no matter what !!

P.S. I'm really conservative too in some ways, btw, but some new stuff I do like, and one of them is pipewire, it has some advantages compared to plain alsa (and specially for music production, I think), but needs to be configured well, as it is on BookwormPup (and on KLV too).

[FeodorF]

Hi @fredx181 ,

you are right, root rights are needed to be able to plug in to the pulse socket.
Thank you very much for that info and your shell script.
Sound works well now with EasyOS-6.3 . (Problem solved)

YouHaveToRunAsRoot.png (53.25 KiB) Viewed 756 times

[BarryK]

you are right, root rights are needed to be able to plug in to the pulse socket.
Thank you very much for that info and your shell script.
Sound works well now with EasyOS-6.3 . (Problem solved)

@fredx181 @FeodorF
All of the browsers in EasyOS run as their own user, for example Chromium runs as user "chromium", and sound works.

Look at script /usr/local/clients/create-client-environment, at line 59:

Code: Select all

if [ ! -e ${PREFIXDIR1}/home/${APPname}/.config/pulse/client.conf ];then #20211103
 #pulseaudio to work in non-root client...
 mkdir -p ${PREFIXDIR1}/home/${APPname}/.config/pulse
 #see also /etc/pulse/default.pa
 echo 'default-server = unix:/tmp/pulse-socket' > ${PREFIXDIR1}/home/${APPname}/.config/pulse/client.conf
 #$PULSE_RUNTIME_PATH=/run/pulse and this is where apps expect the socket, and named "native"
 # .../etc/pulse/default.pa creates two sockets.
fi

[TC-21-32]

Is there a mirror site for this portable? I'd like to see if it runs but my browsers are too old to get into the mega.nz site.
Thank you.
Du.

[mikewalsh]

@TC-21-32 :-

Try here, at my MediaFire a/c:-

https://www.mediafire.com/folder/7r6l49 ... e-portable

You're not the first with MEGA.nz woes. The site IS pretty fussy about access via "latest versions", etc.....

Mike.

[FeodorF]

you are right, root rights are needed to be able to plug in to the pulse socket.
Thank you very much for that info and your shell script.
Sound works well now with EasyOS-6.3 . (Problem solved)

@fredx181 @FeodorF
All of the browsers in EasyOS run as their own user, for example Chromium runs as user "chromium", and sound works.

Look at script /usr/local/clients/create-client-environment, at line 59:

Code: Select all

if [ ! -e ${PREFIXDIR1}/home/${APPname}/.config/pulse/client.conf ];then #20211103
 #pulseaudio to work in non-root client...
 mkdir -p ${PREFIXDIR1}/home/${APPname}/.config/pulse
 #see also /etc/pulse/default.pa
 echo 'default-server = unix:/tmp/pulse-socket' > ${PREFIXDIR1}/home/${APPname}/.config/pulse/client.conf
 #$PULSE_RUNTIME_PATH=/run/pulse and this is where apps expect the socket, and named "native"
 # .../etc/pulse/default.pa creates two sockets.
fi

Thank you very much @BarryK !

By looking at /home/spot shouldn't the entry /home/spot/.config/pulse/client.conf exist by default for this user 'spot'?

Regards,
Feodor

This is the original script from Brave-portable64

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' Brave browser
#
HERE="$(dirname "$(readlink -f "$0")")"
#
mkdir "$HERE/PROFILE" 2> /dev/null
mkdir "$HERE/PROFILE/spot" 2> /dev/null
mkdir "$HERE/PROFILE/spot/Brave-Browser" 2> /dev/null
#
chown -R spot:spot "$HERE/brave"
chown -R spot:spot "$HERE/lib"
chown -R spot:spot "$HERE/PROFILE/spot"
#
if  grep -q 'Quirky April64' /etc/DISTRO_SPECS
then
	LD_LIBRARY_PATH=$HERE/:$HERE/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
	run-as-spot "$HERE/brave/brave" --user-data-dir=$HERE/PROFILE/spot/Brave-Browser --disk-cache-size=50000000 --media-cache-size=50000000 --allow-outdated-plugins "$@"
elif grep -q 'puppy_tahr64' /etc/os-release
then
	LD_LIBRARY_PATH=$HERE/:$HERE/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
	run-as-spot "$HERE/brave/brave" --user-data-dir=$HERE/PROFILE/spot/Brave-Browser --disk-cache-size=50000000 --media-cache-size=50000000 --allow-outdated-plugins "$@"
elif grep -q 'puppy_xenialpup' /etc/os-release
then
	LD_LIBRARY_PATH=$HERE/:$HERE/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
	run-as-spot "$HERE/brave/brave" --user-data-dir=$HERE/PROFILE/spot/Brave-Browser --disk-cache-size=50000000 --media-cache-size=50000000 --allow-outdated-plugins "$@"
elif grep -q 'puppy_xenialpup64' /etc/os-release
then
	LD_LIBRARY_PATH=$HERE/:$HERE/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
	run-as-spot "$HERE/brave/brave" --user-data-dir=$HERE/PROFILE/spot/Brave-Browser --disk-cache-size=50000000 --media-cache-size=50000000 --allow-outdated-plugins "$@"
else
	run-as-spot "$HERE/brave/brave" --user-data-dir=$HERE/PROFILE/spot/Brave-Browser --disk-cache-size=50000000 --media-cache-size=50000000 --allow-outdated-plugins "$@"
fi

Now I have added to it: (to keep it a portable version)
#
if grep -q 'EasyOS Scarthgap64' /etc/DISTRO_SPECS
then
#
if [ ! -e /home/spot/.config/pulse/client.conf ];then #20211103
mkdir -p /home/spot/.config/pulse
echo 'default-server = unix:/tmp/pulse-socket' > /home/spot/.config/pulse/client.conf
fi
#

@fredx181 I have updated the original LAUNCH script so it will work with EasyOS-Scarthgap running as spot.

LAUNCH.False.gz

(2 KiB) Downloaded 14 times

[esos]

I did not usually pay attention much about ram memory usage.
Last night I found that braveportable has memory usage problem on VoidPup64-22.02-241006.
- Memoryusage idle ~ 1082 Mb
- Memoryusagebyrunningbraveportable ~ 1827 Mb
- Memoryusageafterclosingbraveportable ~ 1600 Mb
After closing the braveportable the memory usage does not go back down near to previous idle.

I tested also on S15pup-system and the memory usage after closing the braveportable went back down near to previous idle.

I am not sure which the problem is, the browser or the OS?

[bigpup]

If you look at what is in the memory buffers/cache after running and closing the browser.

you will see that this amount is not changing very much.

The OS's kernel memory controller is keeping some stuff still loaded in buffers/cache.
This is not locked into memory.
If this memory is needed for something else, it will be used.

buffers/cache is being used here to already have parts of the Brave browser in memory, if you start it up again.

This is normal operation of memory control.

S15pup is using a different kernel and it's memory controller.
By your report, seems to not be keeping stuff in buffers/cache, after closing a program.

How the memory controller works, is constantly changing, with each new version of the Linux kernel.
A kernels config settings can also affect this.
It is almost a black art on how to config settings in a kernel, when it is compiled.

The only time you can get any real idle memory reading, is when booting to a working desktop, and nothing is running.
After that, the kernel memory controller is going to control memory usage, as it determines is needed.

[esos]

Thanks Bigpup for quick reply.
Sorry, Hard for me to understand.
Brave.sfs on the same system VoidPup64-22.02-241006 used only ~ 1355 Mb instate of ~ 1827 Mb.
After closing the brave.sfs the memory usage goes back down near to previous idle.
In my understanding portable application can be bigger size and more memory usage, but after closing it should free the memory back down to near the idle situation. Please correct me if I am wrong. Thanks.

[Jasper]

@esos

If you want to clear the 'Buff/Cache' column, try running the attached script.

clear-ram-script.png

Extract it first!!

You can see the results via top.