F96-CE_4 Latest Stable Release

[rockedge]

@vtpup no worries! We'll keep F96-CE_4 going strong and thanks for the head's up on the Java.

This we'll need to fix. I use Vassal to play board war games which relies on Java and I have it running but I installed Java manually.

[wiak]

I note that Focal Fossa reaches end of life in April 2025 so will no longer be supported(?).

Really I know nothing about this kind of stuff. Question I have is: are the repos for that distribution still available long term anywhere?

If not, would it not be a good idea if someone mirrored the Fossa repos for future use by this forum? (unless not necessary); perhaps package apt-mirror can do that (per the link I give at bottom of this post).

Seems to me that a problem with old distros is unavailable packages, and this is a problem when a user wants to keep a really old machine running reasonably well.

Yes, I know security updates re web use are problematic, but sometimes we just need a running computer for the likes of Libreoffice or okular (my needs) and can use a different computer for browsing (maybe via vnc or rdp).

I don't have space or time to mirror repos anyway, but did notice this document about doing so: https://kc.jetpatch.com/hc/en-us/articl ... untu-18-04

I just think it would be great to keep old fossa distros running forever with access to suitable old repos despite those who warn of security issues involved.

The likes of KLV distros can be made in either 32bit or 64bit form, but these are rolling release distros so won't end up fast on old machines. I suppose it would be possible to mirror a snapshot of Void's repos, but too late now for old ones anyway... We can however still access current Ubuntu Fossa repos, and maybe there are archives of the old repos of other distro releases too?

We do of course have the apt sfs capability I produced for Fossapup some years ago (via a FirstRib mod) and there is also Fossadog that works with apt natively in case any of the above apt-mirror stuff is relevant. I'll leave it to those who know about such matters to tell us if such measures would be needed to keep forum Fossa distros running longterm (yeah... despite security considerations, which we are most all well aware of...).

[peebee]

Question I have is: are the repos for that distribution still available long term anywhere?

Focal will be moved at EOL to:
https://old-releases.ubuntu.com/ubuntu/dists/

[ozsouth]

Fossa might wind up here, where Xenial & Bionic are: https://mirror.linux.org.au/ubuntu-rele ... buntu.com.

[rockedge]

With UPUP Raring 3.9.9.2 and Lucid the repo's were moved to archive.ubuntu.com.

I will have to double check if that's the correct format but it does start with archive

We can look at the oldforum for the topic. There's the exact instructions on how to do it.

[wiak]

Question I have is: are the repos for that distribution still available long term anywhere?

Focal will be moved at EOL to:
https://old-releases.ubuntu.com/ubuntu/dists/

So I presume that means the repos can still be used. That's good to know.

[rockedge]

Yes peebee has the URL correct!

[mikeslr]

@wiak , the problem encountered by Puppys when its binary-compatible distro reaches end of life is not with what is included in the ISO but that Package Managers no longer have access to archived repositories: not Puppy Package Manager, not Apt, not synaptic, not pkg-cli. Even if you could configure them to add an archive repository where 'old' applications are now located, there would be no dependency checking; or with say pkg-cli, if checked no automatic download. Say 'My-package' has five dependencies. You can obtain 'My-package' from the archive. But then you'd have to run ListDD to determine what depedencies it has; and seperately obtain each dependency. And that process is further complicated because applications in the archives are not grouped by distro-version but only alphabetically: the xyz package which was used in Trusty Tahr is in the same folder as that for Bionic Beaver, each distinguished by its numeric suffix.

Forunately with Puppys by the time EOL is reached, our devs and fans have packaged and made available applications which were not included in an ISO; and most portables can be used until the new version of a porable demands a glibc higher than that provided by a Puppy. By EOL many applications may have been packaged as self-contained AppImages and portables.

IMHO, the best thing to do in preparation of EOL is to decide what 'accessory' applications not otherwise available may be desired in the future, construct them and/or make them available. See my preparation of Bionic Beaver's EOL with publication of Bionicpup64-Revival, https://www.forum.puppylinux.com/viewto ... 994#p90666 and the discussion under its thread of Applications I chose not to include in its ISO, https://www.forum.puppylinux.com/viewto ... 994#p90668

Nothing lasts forever. My 'guestimate' is that 5 Human-Years translates to 85 Computer-Years. No matter how much we may irrationally love an operating system eventually it will have to be 'put out to pasture'. On rare occasions I still ride 'Bionicpup64-Revival'. But F-96 has become my daily driver. And I suspect in view of FossaFocal's approaching EOL, I'll have to eventually transition to NoblePup64 despite that It can't display analog clocks under PWidgets.

[Clarity]

Today, we discuss EOL which constantly occurs. Some, here on the thread, share concerns and approaches for archival needs that might be needed for an EOL distro.

Couple important things are brought out, I think.

• Package dependency for something 'new' (at least to the running EOL system) to be added to the running EOL system(s).

• Lack of a desire to want to change/upgrade from an EOL to newer version.

@mikeslr, to me, adds 2 great concepts:

1. extensions needed beyond just the archive

2. And "No matter how much we may irrationally love an operating system eventually it will have to be 'put out to pasture'."

I've often wondered in the past, If on a distro's forum thread, the distro builder should "Announce" when the foundation for that distro is at EOL and will no longer be actively maintained. This way, it would alert its users to know to seek a pathway forward at that time. It might be very useful for several reasons to do so as it offers mutual benefit to the current user as well as the developer who, too, has probably moved on to the newer supported foundation.

[wiak]

@wiak , the problem encountered by Puppys when its binary-compatible distro reaches end of life is not with what is included in the ISO but that Package Managers no longer have access to archived repositories: not Puppy Package Manager, not Apt, not synaptic, not pkg-cli. Even if you could configure them to add an archive repository where 'old' applications are now located, there would be no dependency checking...

Well, if that is the case, I remain concerned. If access to archived repos is so convoluted that is not encouraging. If so, I would again suggest the creation of our own repo mirror for the likes of Fossapup via apt-mirror package. On the otherhand, if the ubuntu archive can be used directly by apt and PPM all would be fine, but won't be if that approach will not deal with dependencies, which generally is a core job of efficient/useful package management. My concerns aren't just for fossapup distro of course.

Some may find it odd that wiak would care about legacy distros, but these people simply don't understand my wider distro views. My main philosophy in that domain is that legacy distros would be most useful (and sometimes importantly so) if kept 'alive', which primarily means that they continue to have some efficient/dynamic package management support (which is preferably able to resolve package dependencies).

Legacy distros, being small and fast are also potentially useful for use in a network of virtual machines; for example in education, which remains a huge market for Linux since Linux dominates the server world.

Would have been great to keep the likes of Bionicpup 'alive' in that sense, and fossa really is a current 'sweetspot' in terms of longtime useful facility and resource efficiency.

[Clarity]

Hello @wiak I agree with your raising the concern for continuing a PM mechanism 'after' a mainline distro goes EOL.

But the reasons for EOL is so that the building entity has only so much resources. Thus, the lack the funding, staffing, resources to continue developing and supporting, the past, when they have moved on to newer products. We have seen this addressed this way over the past century in everything.

It will take a supporting team (1/more people) for each mainline distro to keep the old products continuing operations not to mention what to do when new apps are upgraded replacing the old.

I dont have an future answer for EOLs, but I am aware of why things have moved in the traditional way they have, thus far.

[wiak]

It will take a supporting team (1/more people) for each mainline distro to keep the old products continuing operations not to mention what to do when new apps are upgraded replacing the old.

That's why I talk of choosing some special cases that are particularly important in terms of forum distro releases. But I was in particular thinking about FocalFossa reaching End of Standard Support this coming April.

However, my own understanding of what I read is that archived repos (and later old-releases repos) will in fact allow for dependency resolution via apt, but I'm not sure about that so was asking if anyone knew for sure. Here is one of many links about archived use: https://askubuntu.com/questions/1188970 ... leases-rel

My understanding from the above (if still applicable) is that old-releases url isn't the relevant one at first. Rather it will be https://archive.ubuntu.com and, for the case of FocalFossa anyway, https://old-releases.ubuntu.com will not become relevant till much later. I might be wrong..., but main issue would be if @mikeslr is correct in saying these mechanisms will not provide dependency resolution - but my reading suggests that isn't correct and all should work fine (???). It is important, I feel, to be sure about all this though.

[fredx181]

Don't know much about it but it seems to me from looking here: https://ubuntu.com/about/release-cycle that 2030 is the "real" EOL.
"Expanded Security Maintenance (extra 5 years)" from 2025-2030

edit: and as you can see here; https://old-releases.ubuntu.com/ubuntu/dists/ is that even Bionic isn't in the list of old-releases (as it is supported with expanded security updates until april 2028).
edit2: and Xenial until 2026.

[mikeslr]

Either I forgot, or was never aware of, the extended release repository referred to on the post Wiak noted: "Ubuntu 18.04 LTS has 5 years of standard support so is supported until 2023-April, then moves to ESM or extended support before finally having it's repositories moved from archive.ubuntu.com to where you're file is looking - old-releases.ubuntu.com."

I don't know if the extended support repository is publically available, or only available to those who obtained (purchased?) special editions of a distro-version.

Chosen at random, the following screenshot shows an archived folder, obtained by 'burrowing' into the sub-sub-folder designated 'e':

Snapshot of EOL Folder.png (127.86 KiB) Viewed 2760 times

Note that it includes debs from 2014 and 2024 which bear different numeric designations. I doubt they are interchangable and wonder if even apt can distinguish between them.

Has anyone (perhaps familiar with debiandogs) ever installed archived debs using apt/synaptic?

The impression I have is that organizations such as Ubuntu publish Operating Systems and the applications to be used under them targeted at 'reasonably' current computers outfitted with the then-to-be-expected hardware. With ever more powerful CPUs and RAM being inexpensive, concerns for efficiency fall by the wayside. The QT5 framework replaces QT4, in turn to be replaced by QT6. The portable design of Puppys, KL's and 'debiandogs' --requring only their own folders-- make it compartively easy to upgrade to a newer operating system: keep the old while transitioning to the new having your datafiles available to both. All of which is great except if you own and can not replace a computer lacking the resources necessary to manage newer CPU-and-RAM demanding applications.
It is where preserving the extendability of the old puppys serves a utilitarian purpose. When I built Bionicpu64-revival I 'thew in the kitchen sink' but left out 'microwaves and air-fryers', distinguishing between what was likely to be wanted by 'everyohe' from spplications filling special needs. That's not efficient. But I could not just upgrade the 'core' leaving the potential user to his/her resources to obtain generally desired applications because there was no repository for anything I left out of the 'core'.

I agree that the best case would be to have a repository for applications postentially useful under F96, but not genereally required by 'everyone' running it; and a team effort to stock that repo. But specifically what applications meet that criterior? Should that question be raised under this thread, or opened to a broader audiance under the User Section or elasewhere?

[fredx181]

Either I forgot, or was never aware of, the extended release repository referred to on the post Wiak noted: "Ubuntu 18.04 LTS has 5 years of standard support so is supported until 2023-April, then moves to ESM or extended support before finally having it's repositories moved from archive.ubuntu.com to where you're file is looking - old-releases.ubuntu.com."

I think "finally" is in 2030 for Focal Fossa that it's repositories will be moved from archive.ubuntu.com to old-releases.ubuntu.com .

Note that it includes debs from 2014 and 2024 which bear different numeric designations. I doubt they are interchangable and wonder if even apt can distinguish between them.

Sure, apt (and PPM too, I guess) knows exactly what distribution you run and in case of e.g. Fossa, it doesn't even know about the existence of an older package version from 2014 (as in your screenshot, probably for Trusty Tahr)
It takes the newest package version to install that is designed for a particular distro release.

[Sky Aisling]

Hello,
What site do I use to find the most current download of F96-CE .ISO?
Thank you in advance.
Sky

[bugnaw333]

1st page please...

[rockedge]

Hello,
What site do I use to find the most current download of F96-CE .ISO?
Thank you in advance.
Sky

As mentioned in the previous post, look at the first post of this topic or directly from the F96-CE website -> https://f96.puppylinux.com/

[Sky Aisling]

@rockedge

Hello rockedge,

The download F96-CE_4.iso appears unable to be extracted by pExtract.
The link used was https://f96.puppylinux.com/.
Sky

pExtract Error1.png (59.88 KiB) Viewed 1685 times

[rockedge]

@Sky Aisling,
Looking at the last screenshot it appears that the .zio file never completed it's download. The file with the .part extension is a piece of what is missing in the zip. So the zip file is corrupted and will not expand.

Download the ISO file separately here -> https://mega.nz/folder/j0JQ2RaZ#Uiw3eA8 ... e/f9wCWTAb
and then go back to -> https://mega.nz/folder/j0JQ2RaZ#Uiw3eA8MBOhOxHnwxqRKNg and download the files you need individually.

Otherwise you will have to allow the zip package of all the files to download completely before attempting to expand the zip archive file.

[Sky Aisling]

@rockedge @mikewalsh @bigpup
Succesful download of current F96-CE_4.iso.
Succesful creation of a frugal puppy usb stick of F96-CE.
HOWEVER ...
This "current" .iso download contains a considerably old version of Firefox FF 102.9Oesr(64-bit) set as the built-in browser.

This throws us back to the unfortunate issue which took MikeWalsh and I much work to correct.

Notice from Firefox 116.0.2 browser 'will stop working soon' [REVISED][SOLVED]

https://www.forum.puppylinux.com/viewtopic.php?t=13779

Sky

[rockedge]

I will see if I can put a newer Firefox into F96-CE_4

[Sky Aisling]

@rockedge @mikewalsh
How about a portable browser?
Mike Walsh has a new Google drive library space for portables.
Edit: that link I posted seems broken, sorry.

Sky

[rockedge]

I went ahead and performed the steps to update the Firefox ESR portable included in F96-CE_4 rootfs to version 128.7.0.

I am calling the system F96-CE_4.5 but don't know if it makes sense to release it.

For anyone willing to test out the ISO it is here for download -> F96-CE_4.5

I am toying with the idea while I have a decompressed version of the rootfs at the ready, I could upgrade several app utilities like PackIt and UExtract and perhaps a few other items. Since F96-CE_4 was designed to be a bridge between Fossapup64-9.5 and the future Ubuntu based Puppy Linux's like Noblepup64 that use the usrmerge rootfs system structure and have the APT package manager onboard, it probably does not make much sense to attempt to upgrade F96-CE major components.

[wizard]

@Sky Aisling

Have F96-CE_4 and using Mikes portables just fine. Easy way to stay updated.

wizard

[rockedge]

I am wondering now if I should take F96-CE_4 and remove the Firefox ESR portable from the /opt directory in the rootfs and move it outside of the file system and next to the system SFS's. Making a F96-CE version that has no built in browser and instead uses portable browsers from outside of the root file system.

[Sky Aisling]

@rockedge @mikewalsh

Mike's portables make downloading these pesky browser so much easier.
Mike, if you are listening can you give us your current Google Drive download site link for all your pbrowsers that you've created? Thank you in advance.

Sky

[Sky Aisling]

@rockedge
MenuReadMe from OPTS

The *recommended* location for this portable application is in /mnt/home. If you place your portable in /mnt/home, when adding the MenuEntry it will sym-link the 'LAUNCH' script into /usr/bin, place a .desktop entry in /usr/share/applications, and an icon in /usr/share/pixmaps. It will then restart "X", in order that the MenuEntry will show up in the Menu.

Specific advice for Chromium-based browsers:-
------------------------------------------------------------

CAUTION: make sure to use the appropriate 'MenuAdd' script for your Puppy. 'MenuAdd-Old' is for Bionicpup64 and older; 'MenuAdd-New' is for Fossapup64 and newer. This ensures the correct 'LAUNCH' script is sym-linked into /usr/bin.

It should launch without issue.

However; IF you wish to place the portable application in a different location, that's not a problem. First, use the 'MenuRemove' script to remove the existing MenuEntry. Let the desktop settle after "X" has restarted, then move the portable to the desired location. Finally, re-add the MenuEntry with the appropriate 'Menu-Add' script.

The MenuEntry removal/re-adding steps are necessary because Linux does not, under normal circumstances, permit the migrating of links from one location/file-system to another. 'Soft' links will lose their 'target', and hard links can no longer locate the specified inode. Therefore, the MenuEntry needs to be re-created from its new location.

None of these steps take long to perform, and add another layer of convenience, since with a .desktop file you can also add the application to the QuickLaunch area of the tray, etc.

[rockedge]

@Sky Aisling It is difficult to do because of the fact how F96-CE_4 is distributed as an ISO file. Meaning it is a snapshot image of a root file system with the components needed to install in a directory on a mounted partition or USB drive. The portable would be placed outside of the layered system in the ISO and look like this:

Screenshot_2025-02-21_18-10-04.jpg (38.03 KiB) Viewed 763 times

To actually have the Firefox-portable in /mnt/home it would have to be moved there either manually or by a script, otherwise it will be in alongside the system SFS's and other components.

[Sky Aisling]

@rockedge

I am at this moment running F96-CE_4 frugally on a flash stick with the Firefox 128.7.Oser(64) located in /OPT as you have it currently set. Everything is running smoothly. I am assuming that FirefoxOser will auto update to a newer version as needed. Yes, I have 'auto update' marked in Firefox settings.

The only thing I would do now for myself is to set another browser portable such as Palemoon or Opera so that there is a backup browser available in case FirefoxOser(64) develops an issue.

Sky