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 455 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.