Working on F96_4-radky5-CE to Finalize a Release Version

[mikeslr]

Consider this a ‘Proof of Concept’.

What to do about a web-browser which will be immediately available to new Users. Perhaps the easiest approach was that previously taken: include a small web-browser. Often Lite-Browser, a fork of firefox, was chosen. But it is now rather old. Fortunately, oscartalks has more recently compiled Netsurf for fossapup, viewtopic.php?p=21655&hilit=netsurf+fossapup#p21655. It weighs in a 1482 Kg, soaking wet. I added a couple things to the config file, and an html and some pngs to /root/my-doucuments. The result is that when it opens that html is its home page, and the text and illustrations explain why and how to obtain web-browsers using one of the provided Bookmarks named “Browsers and Internet - Puppy Linux Discussion Forum”. That Bookmark opens to the Forum’s Section bearing that name.

I don’t know where I could just upload html and pngs so that you can view the effect. So I’ve provided the ‘modified’ pet here,
https://www.mediafire.com/file/pdgexesi ... d.pet/file.

If you don’t care to download and install the pet I think you can see the effect by downloading, and extracting the attached deploy.tar.gz, copying the contents of the ‘my-documents’ folder to /root/my-documents and opening ‘Welcome-to-netsurf.html’ in your default html viewer.

deploy.tar.gz

(111.48 KiB) Downloaded 26 times

The netsurf folder within ‘deploy’ are my customizations to netsurf’s config files. Installation of the pet would write that folder to /root/.config. Installation of the pet would also make netsurf the default html viewer. [Don’t ask. I didn’t do it. It just happens. ]

As I wrote, this is offered as a Proof of Concept. Something similar could likely be accomplished with ‘Lite’ or any other web-browser. I’ll probably remove the pet from mediafire in a month or so.

I created the html using a bluegriffon AppImage under F-96, my first attempt at creating html files. Someone who know what (s)he’s doing should not hesitate to revise it. Or the text.

[Marv]

Installed to test on:

Code: Select all

Computer Profile:
 Machine                    FUJITSU LIFEBOOK S761 (version: NA)
 Mainboard                  FUJITSU FJNB225 (version: NA)
 • BIOS                     FUJITSU // Phoenix Technologies Ltd. Version 1.17 | Date: 03/14/2012 | Type: Legacy
 • CPU                      Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (2 cores)
 • RAM                      Total: 5779 MB | Used: 961 MB (16.6%) | Actual Used: 234 MB (4.0%)
 Graphics                   Resolution: 1366x768 pixels | Display Server: X.Org 1.20.13
 • device-0                 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
 Audio                      PulseAudio
 • device-0                 Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 04)
 Network                    wlan0
 • device-0                 Network: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) [168c:002e] (rev 01)
 Printers                   CUPS installed
 • device-0                 DefaultPrinter CUPS-PDF
 • device-1                 Printer Officejet_4500_G510g-m
 Drives                     Total: 232.8G
 • sda                      ID-0: Samsung_SSD_850_EVO_250GB (232.9G)
 Partitions                 Mounted-FS      Size  Used Avail Use%
 • sda2                     /dev/sda2       210G   69G  130G  35%

Fresh install first, with stock kernel (6.0.12-FP), bdrv and ydrv (no fdrv, Atheros wifi cards support built-in to kernel). Clean boot, clean dmesg, good glxgears FPS, very low idle resource use, gtkconman connection slick and very fast, touchpad parameters set up normal, Palemoon on board and seems fine. If I have any nit, it's miniscule -I preferred the previous freememapplet icon in the tray-

Then the leap. Hid the bdrv and the stock ydrv, swapped in @peebees' 6.1.1 kernel, and my ydrv from radky4. Reboot and I'm running exactly as I was in that install. Links all ok, linked PCManFM-pup trashcans ok, Menus, tray, themes, wallpaper, Look'n'feel are all preserved. One PCManFM setting item needed setting and that only because I hadn't found where it was saved to transfer it to my ydrv. Posting from the portable Slimjet on my data partition, symlinked to my ydrv along with all the other portables.

Minimal use as yet but by me it's a good -and good looking- OOTB pup, and easily customized to boot

Thanks!

[mikeslr]

Comment regarding my last post. I worked on the pet and post early in the day, then had to go out before posting it. Posted without having read radky's last post, nor examining the latest version of F96. I'll have to digest its changes.

Thanks, radky for continuing to improve what was already an excellent operating system.

[amethyst]

So what can one do with only loading the base sfs (what essential components and applications are included in the base sfs)? Also - are there any .file entries for the applications included in the ydrv (similar to the buitin applications files found in the builtin_files directory like with other Puppys) when loaded (shown in /var/packages). If so, it could be useful to extract individual applications with a utility of mine and rebuild it as an sfs file.

[wizard]

@radky
@rockedge

Testing F96_4-CE_radky6.iso

Revisited all previous issues on the f96-4issues.xls sheet, all fixed and working.

As a side note, F96_4-CE is now able to run SimpleScreenRecorder and capture both video and audio without extra configuration (a result of it using pulse audio).

Thanks
wizard

[radky]

So what can one do with only loading the base sfs (what essential components and applications are included in the base sfs)? Also - are there any .file entries for the applications included in the ydrv (similar to the buitin applications files found in the builtin_files directory like with other Puppys) when loaded (shown in /var/packages). If so, it could be useful to extract individual applications with a utility of mine and rebuild it as an sfs file.

@amethyst

Unfortunately, this is a question that has no answer that will satisfy all users. Applications that some users consider essential may be of little value to other users. The current base sfs is relatively 'bare' as often requested by those who prefer a modular baseline Puppy that is easily customized, with no need to remove applications they might consider non-essential. On the other hand, if the Puppy community prefers a base sfs with more built-in applications than currently available, certainly this is possible but who will determine the essential nature of each application?

Concerning the current /var/packages/builtin_files, I can provide /var/packages/ydrv_files (or something similar) that would list the package and corresponding files of the default ydrv as shown below. Would this be useful for the sfs-rebuild function of your utility suite?

[amethyst]

@radky

My point is that with all (most) applications provided in one additional drive, the position is basically the same as if all applications were builtin because if one is to use say only one application in the ydrv one has to load the ydrv containing all the applications anyway. So not really all that modular. To make it a truly modular system, each application will have to be available and provided on its own separately. Extracting and rebuilding a package from this ydrv with my existing extracting tool should be possible provided that the application file lists have the same structure as those listed in traditional Puppys (like one would see in the builtin_files folder in /var/packages). So in theory: (temporary) symlinking the file list of a package in the ydrv (as shown in your image) to the builtin_files folder and then running my extracting and rebuilding tool, should produce an sfs file of the chosen application. The packages shown in your ydrv do mostly seem the "usual suspects" that we see traditionally built into Puppys. Personally (just my preference), I would have built it into the base sfs or just merged the contents with that of the base sfs. Most of these applications are so small anyway. With the existing remove builtin packages tool, a user can then either temporary "hide" a package that he does not want to use or remove it permanently doing a remaster.

[greengeek]

I added the bdrv in the first stages of F96 for demonstration purposes and I wanted to have a 2 pane file manager so the two fit together. The main test being how the bdrv interacts and performs in F96. I envisioned using it to add on tools and utilities that may not be desired by every user of F96 and could be removed from the boot stages and they would be fully removed from the system.

Maybe we look at creating manager GUI for dealing with the alphabet drives excluding the fdrv and zdrv as kernel core images and remain read-only.

Actually, that's a good way to use bdrv. But I'd suggest applications which are less useful than xfe*. For example, how many people still need DVD/CD burners? Or for that matter, printers. I need a printer about once a year, about the same time as I think about setting up a local area network so I don't have to lug a USB-Key from my computer to my wife's which can be connected to the printer with a cable. A bdrv with those applications, renamed 0bdrv, could just sit there until needed; at which time it would be a name change and reboot away.

Changing an adrv to a ydrv is just a name change. Using Save2SFS, if bdrv is first changed to ydrv, a new ydrv could include both the current contents of adrv and bdrv.

In moving to 64bit pups I have seen some benefits and flexibility in the *drv structure but there are some complexities that are unnecessarily clouded for the end user.

Why are alphabetical codes used if they are not very clear?? (eg adrv bdrv ydrv)

Why not something that is more clear in terms of priority - such as 1drv, 2drv, 3drv?? or topdrv, 2nddrv, 3rddrv, bottomdrv?

Or why not call the highest priority - "personal.drv" ?? So it is clear which .drv contains personalisations.

Why even call it ".drv" ? What does that mean? Why not top_layer, 2nd_layer, 3rd_layer, base_layer, etc etc
Taersh had a system where unlimited sfs were possible and (more or less) unlimited layers were possible. How did this fail to become part of puppy?

In my view - the gains made in 64bit pups could be much improved by clarifying the labelling and usage of the individual layers. Make it simple for users to understand where to make their personal changes.

Or maybe - would it be possible to modularise in a different way - ie browser.drv speaks for itself, so does wordprocessor.drv, or graphics,drv.

Maybe a different .drv for each menu section??

• Setup
• Graphic
• Document
• Internet