BionicPup32 (UPupBB) (27 June 2020)

[bigpup]

peebee,

The Distrowatch announcement is out about Puppy 8 release.
https://distrowatch.com/?newsid=10501
They have the info about Bionicpup64 8.0, but not your Bionicpup32 8.0

Give them some info!

Oh, I see, if you go to some of their links you get 32bit info.

A download link on that first Puppy Linux topic for the 32bit would be good to have.
Plus a few words about there being a 32bit version.

You have made it to osdisc.com
https://www.osdisc.com/products/puppy
That is better than Distrowatch
They too seem to need a little info update about Bionicpup32 8.0

[peebee]

The Distrowatch announcement is out about Puppy 8 release.

I don't know who wrote the DW words - I certainly wasn't asked to contribute....

I suspect that a new thread authored by "Lobster" has been used..........
http://www.murga-linux.com/puppy/viewtopic.php?t=115733

[bigpup]

Someone at Distrowatch usually does the info statements, but they base it on what they are given when you submit a new Linux OS for them to consider posting about.

Probably 666philb gave them info for Bionicpup64 8.0

You as the developer of Bionicpup32 8.0 need to give them info for it.

Distrowatch Distribution Submission info page.
https://distrowatch.com/dwres.php?resource=submit
I would make sure you tell them this is the 32bit version of Puppy Linux 8.

[B.K. Johnson]

Just an observation! No response necessary.
But the logic escapes me. upupbb goes through the entire testing phase from upupbb-18.05+0 to upupbb-18.05+28 with k4.9.96.
Testing is done, bionicpup32-8 and bionicpup64-8 (the post test versions) are released with k4.9.163 (no testing). Hmmm!

[Marv]

Don't know quite where to put this as it is a cross-pup cross kernel comparison but it started with upupbb so my ramble goes here... Ok to move it or I can just delete it if it's inappropriate.

Hardware: My usual i5 based laptop, Grub4Dos installs on a Samsung 850 evo SSD. 4Gb memory.

Observation triggering testing. Over a number of kernels and pups tested pretty thoroughly over time (4.9.96, 4.9.134, 4.9.163 (32b), 4.20.xx through 5.04 (64b) in upupbb, upupcc, LxPupBionic, LxPupSc, and LxPupSc64 a consistent pattern began to emerge wrt perceived SFS load times. In particular my 76 Mb Slimjet ones. LxPupSc64 always seemed fastest (no real surprise) and upupbb always slowest by a lot. upupcc always felt 'snappier' than upupbb, but the timed difference between those two was another surprise. hdparm results over a long time have been pup and kernel invariant and the memory is tested and the same in all cases.

Today I timed the first loads (roughly counting seconds). I then tested disk and memory throughput using dd in each of the above pups with most of the above kernels swapped in. I had been doing dd tests manually but found a script which matches my manual times pretty well and really speeds up the testing. It is attached as a false gz, Author credits at top of script.

Two surprises. One, that results were very nearly kernel invariant. Two, that the big differences were in HDD throughput, not memory throughput. ie:

Code: Select all

     Pup         SFS load time       Mem I/O Gb/s     HD I/O Gb/s

LxPupSc64        4 sec                    2.3                    2.2
LxPupSc          4 to 5 sec               2.3                    2.2
upupcc            9 sec                      2.2                    2.1
LxPupBionic      NA                        2.15                  1.2
upupbb            17 sec                   2.0                    1.15

Several reps and several kernels represented in each of the above rows. Variability on repeat tests was 0.1 or less as was the kernel-to-kernel variability within a pup.

I have no clue at all as to the why, nor do I expect one. What it does for me is to quantify my gut feeling and give me an excuse to ride the faster horse It also gave more time mashing the kernels above, all of which remain rock solid on my pups and hardware.

[glene77is]

UpupBB Bionicpup32 ok here.
Interesting code work in UpupBB.
More organized than prior versions of puppy.
Using the # 2 8 version of .ISO.
The run-time is longer during "sysinit".
The run-time is longer during "save2flash"


I enjoy tracing the running code ...
to wit, I wrote a short "signature" into the header of
"rc.sysinit", "rc.shutdown", "sfs_load", "fixmenus".
Like this:

### === Signature

lcMsgStr="rc.sysinit $1"

/bin/echo -e "\\033[13G\\033[1;37m * \\033[1;31m $lcMsgStr \\033[0;39m" > /dev/console

### end: Signature

This little trace shows during startup and shutdown,
and there are many dozens of other little tracers like this
ticking-up and displaying the real-time / colorful flow of the code.
Back in 1979, I wrote in four different assembler languages,
and 'tracers' like this were the only way to survive !

Have Slacko, Tahr, UpupBB installed and running identically.
Early on, I wrote these tracing "flow notes"
into a progressive log file with the real-time date-time-stamp .
I found the log files interesting to review,
and helped me keep tabs on the time required
to run through "sfs_load" and "fixmenus".

I notice that "fixmenus" run
may be called 3 times during the system init.

I noticed that "sfs_load" may be called multiple times,
and now ( in # 2 8 ) there are two "exit" checks
in the header of "sfs_load".

[ When I run and watch the tracing on Tahrpup,
I notice that "sfs_load" may be called after the last line of code
in "rc.sysinit".
But, No such curiosity flushing a stack with UpupBB. ]

In UpupBB, "sfs_load" ,
there are two short blocks of code doing
an "exit" check in the header of "sfs_load".
"sfs_load" is called and may "exit" for two different reasons.
The tracer showed each time "sfs_load" started,
and another showed each time it did an "exit".
Other tracer lines showed exactly what was being loaded
and the progression of initializing during "sfs_load"
and the interplay with "fixmenus" .

I noticed in UpupBB that the audio player intro plays most of the time.
This is a neat way to cover the long initialization routines
that occur after "sysinit" has finished its code run.
When I introduced this type of audio code at the tail-end of "sysinit"
it played sometimes.

Next are two Little , and Non-Fatal, problems.

Little Problem (1)
"pmcputemp" does not work properly.
My PC is a 2005 HP and does not do temp monitoring. .
On initial "bootup" the "pmcputemp" pops up
with an error message.
I use File Find to locate and rename the offending script.
Will only come up again
IF I revise the systems files from a new .ISO.
Guess I should write a little script to rename the file.

Little Problem (2)
Executing "save2flash" will cause a little "green" window
in the bottom tray to start flashing "red",
This which means that
(1) the savefile has been renamed during run-time
or
(2) has become 'unknown'.
In testing this little problem,
the savefile is not disconnected ... just flashes red.
Sometimes, like right now ,
the little "red" flashing window has disappeared.
This is not "fatal" as I know about the integrity of the "savefile",
and maintain progressive backups of the "savefile" .

To PeeBee, you have a lot of talent.
Thanks for this latest version.

[bigpup]

BionicPup32 on SourceForge

BionicPup32 on Ibiblio

It would appear that the ibiblio and SourceForge base ISOs are different (8.0-uefi vs 8.0+0-uefi) and the ibiblio one is not "updatable". Is this the case?
I do not know if this indeed is the case and if it is intentional but does not sound very nice if true. Specially if the one in ibiblio has know bugs.

Intentional.
The Ibiblio version will always be the latest with all known bugs squashed - i.e. curently is 8.0+1 so indeed different to 8.0+0 which is the "base" iso.....there is a text file on ibiblio that gives the md5s

The ibiblio version is not directly updateable - the base iso would be needed from SF - or the ibiblio iso can be renamed and a "reverse-update" applied.

I am not seeing what you say here.

The Ibiblio version will always be the latest with all known bugs squashed - i.e. currently is 8.0+1

The iso at ibiblio is bionicpup32 8.0-uefi.iso

The ibiblio version is not directly updateable

True, but it never seems very long before they get the update posted at ibiblio.
Usually within 24 hours of giving them the new version iso, program pet, changed software, etc.....

If you are going to offer a delta that is going to change the iso name.
ibiblio should now be offering that newly named iso for download.
The older iso should no longer be listed at ibiblio.

Ibiblio is being used as the official Puppy repository.

[bigpup]

Bionicpup32 8.0+1

menu>System>System Update

A information window pops up, but does not stay visible long enough to read it.
Could it be made to start the browser and go to the update web page, after you click on the OK button on this info window

[peebee]

Bionicpup32 8.0+1

menu>System>System Update

A information window pops up, but does not stay visible long enough to read it.
Could it be made to start the browser and go to the update web page, after you click on the OK button on this info window

Will do:
/usr/bin/sys_update_upupbb.sh

line 2: remove -timeout 6
line 13: remove &

[glene77is]

PeeBee,
Thanks for including the FireFox "U-Light" Browser.

(1) I extracted your code into a file.sfs
(2) now have it installed and running in
UpupBB, and Tahr 605, and Slackopup 632.
(3) I placed it at /root.

cul
Glen

[tosim]

I'm assuming the info-see screenshot, was typo errors, as dl shows proper info???

[bigpup]

Bionicpup32 8.0+1

WIFI does not work. No wireless devices detected.

This is the network setup on this computer:

Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter [10ec:b822]
• Kernel Driver: r8822be
• Memory Used: 768.00 KB
• Path: /lib/modules/4.19.23/kernel/drivers/staging/rtlwifi/r8822be.ko

The firmware for RTL8822BE is not in Bionicpup32 8.0+1


When first doing network setup.
A info window opens giving info on where to get more firmware and how to find out what is needed.
If you close that window.
There seems to be no way to reopen it, to read again.

This info is in a txt file /opt/upup/upup-hints.txt

Strongly suggest make some easy way to re-access this info.
Maybe by applications>Help

[wanderer]

hi peebee and everyone

i am using bp32 and it is a great distro
i have not encountered any issues yet

i did do a few fun things

i downloaded fredx firefox and unzipped it in home
then started it
it worked fine and updated
and i now have the latest firefox
posting from it now

i also downloaded firefox-esr from debian
and it runs fine from a directory as well

i also really like the light browser

anyway

thanks for making this
very useful and fun

wanderer

[Ether]

.

i also downloaded firefox-esr from debian and it runs fine from a directory as well

Hi Wanderer.

Would you please explain the steps for doing that? I would like to try it.

Thank you.

.

[wanderer]

hi ether

go to debian site
download deb for 32 bit 386 firefox-esr

unzip into a directory with uextract
in bp32 home in save file on hard drive

go into the directory
to the usr/bin directory
open a terminal
and type ./firefox-esr

and it will just run

wanderer

[Ether]

.

unzip into a directory with uextract in bp32 home in save file on hard drive

I don't understand that part.

I don't have a save file. I have a save folder.

/mnt/home/Bpup32 is the folder that contains the system files and the save folder.

.

[wanderer]

hi ether

if you have a home directory
just uextract the deb there

and then go into the unzipped firefox-esr directory
to usr/bin
and type ./firefox-esr in a terminal

wanderer

[bigpup]

Bionicpup32 8.0+1

WIFI does not work. No wireless devices detected.

This is the network setup on this computer:

Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter [10ec:b822]
• Kernel Driver: r8822be
• Memory Used: 768.00 KB
• Path: /lib/modules/4.19.23/kernel/drivers/staging/rtlwifi/r8822be.ko

The firmware for RTL8822BE is not in Bionicpup32 8.0+1

Update info and can anyone offer any help
I have found and installed the needed firmware (r8822befw.bin), but I still need the kernel driver r8822be.ko.

The kernel in Bionicpup32 8.0 does not have the r8822be.ko driver in the kernel.
So, just having the needed firmware is not enough.
If the kernel was 4.14.xx or newer. The driver would be in the kernel.

I am having problems getting the kernel driver downloaded and compiled.
There are some at Github:
https://github.com/search?q=rtl8822be
None of them will compile.

(YES I HAVE EVERYTHING NEEDED TO COMPILE)

I am new to trying to get kernel drivers compiled.

Any ideas?

[OscarTalks]

Hello bigpup,

The source from the "wsyco" github page compiles in my Bionicpup32 to produce a driver module named 88x2be although the package does appear to be rtl8822be so not sure if it is compatible or not. I just ran make and make install in the driver sub-directory.
Kernel version here is 4.9.163 though.

[peebee]

If the kernel was 4.14.xx or newer. The driver would be in the kernel.
Any ideas?

Try kernel 4.14.91 or 4.19.13 from:
https://sourceforge.net/projects/lxpup/ ... e-kernels/

??