# pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64



## byrnejb (Feb 12, 2021)

I went to upgrade some (12.1p12)  pkgs today and got this:


```
]# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching packagesite.txz: 100%    6 MiB   6.4MB/s    00:01  
Processing entries:   0%
Newer FreeBSD version for package libxfce4util:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1202000
- running kernel: 1201000
Ignore the mismatch and continue? [y/N]: n
pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories
```

Why?  And how is this resolved?


----------



## SirDice (Feb 12, 2021)

byrnejb said:


> Why? And how is this resolved?


FreeBSD 12.1 is end-of-life. Upgrade to 12.2.


----------



## byrnejb (Feb 12, 2021)

At the moment that is not desireable.  Is there a repo that contains the last quarterly upgrades for 12.1 before EOL and which I can use in the meantime?


----------



## shkhln (Feb 12, 2021)

byrnejb said:


> Is there a repo that contains the last quarterly upgrades for 12.1 before EOL and which I can use in the meantime?


No, of course not.


----------



## byrnejb (Feb 12, 2021)

Is there a url where all the pkg files are accessible directly through http or ftp?  I went to http://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/ and got a 403 forbidden error.


----------



## zirias@ (Feb 12, 2021)

The ABI didn't change, so for most packages (excluding some containing kernel modules), *ignoring the error* as hinted in the message should work. (of course NOT tested, UNSUPPORTED!)

But JUST WHY are there always people insisting on running EOL systems? What's the deal? It's not like upgrading hurts or something. Especially talking about *minor* versions.


----------



## byrnejb (Feb 12, 2021)

The deal is TIME.  There are a lot of demands and system administration is just one of them.  It is fine to say that three months is more than adequate to switch over.  And that is true, if one has little else of importance to do.  However, the current situation does not grant me the luxury of that time.

Having been bitten on several occasions by freebsd updates, I can assure you upgrades can and do hurt on occasion.  Going from 11.2 to 11.3 broke something in behyve or zfs or both such that vms that had run without problems since creation on 10.3 began to simply hang.  This became so bad that in the end we abandoned behyve altogether.  But that migration in itself consumed the better part of a year to complete.  

Then there was the move from 10 to 11 where the boot file system was screwed up and it was only pure luck that I did not bring down the system in a state where it could not reboot.  And that was after we had trialed the upgrade on a different computer and had no problems.

I can live without access to the binary packages for 12.1.  I have poudriere and if push comes to shove then I can build from ports selected by date.  As I have had occasion to do.  

I think that I need to set up my own repo,  fetch pkgs into that, and install from there.  It will take about 160G but I have the space.

And, at some point in the not two distant future I will move my development host to 12.2.  Maybe I will try beadm again. Although the last time I tried that I ended up having to recover my zfs pool using a recovery CD.

Like the White Rabbit, I am always pressed for time; and I am not looking for additional work.


----------



## Phishfry (Feb 12, 2021)

byrnejb said:


> It will take about 160G but I have the space.




```
pkg fetch -a
Number of packages to be fetched: 30172

The process will require 87 GiB more space.
87 GiB to be downloaded.

Proceed with fetching packages? [y/N]:
```

So 87 Gibibytes = 95 Gigabytes for all AMD64 packages in txz format.


----------



## SirDice (Feb 13, 2021)

byrnejb said:


> I have poudriere and if push comes to shove then I can build from ports selected by date.


Set this up permanently and always build your own repositories. Create a small script that just kicks off updates and builds during the weekend. Then each Monday morning you have a freshly updated repository. All with your specifically required versions, updates, settings, defaults and whatnot. Have all your servers get their updates from this repository. Now everything will be easily kept in sync and you're guaranteed every server will have the same package versions, defaults, etc.


----------



## byrnejb (Feb 14, 2021)

I do not know what it is about freebsd and me.  It seems that every time I try to do something some mysterious anomaly surfaces.

Today I decided to give beadm another go.  There many examples on on the web, no two of which do things the same way.  So, proceeding from one of the examples I started this way.:

```
sudo beadm create  12.1-RELEASE-p13
mkdir /mnt/beadm/12.1-RELEASE-p13
beadm mount 12.1-RELEASE-p13 /mnt/beadm/12.1-RELEASE-p13
```

At which point the instructions said 'start the jail' which was insufficiently explained for my level of expertise.  So I went to the man page.  And did this instead:

```
[root@vhost01 ~ (master)]# beadm list
BE               Active Mountpoint                   Space Created
default          NR     /                            98.7G 2020-05-20 11:25
12.1-RELEASE-p13 -      /mnt/beadm/12.1-RELEASE-p13   3.4M 2021-02-14 12:00

[root@vhost01 ~ (master)]# beadm activate 12.1-RELEASE-p13
Attempt to unmount boot environment '12.1-RELEASE-p13' mounted at '/mnt/beadm/12.1-RELEASE-p13'
Gracefully unmounted boot environment '12.1-RELEASE-p13' from '/mnt/beadm/12.1-RELEASE-p13' mount point
```

And that is where things are apparently stopped.  At least the terminal session that is being run on has not returned to a prompt.  Further, when I do this I also end up with a non-responsive session:

```
[root@vhost01 ~ (master)]# ps -auwx | beadm
^C
^C
^C
```

Nothing I have done here seems to me to be obviously wrong.  Mounting the boot environment was ultimately pointless but it is not anything that`beadm` itself could not handle.  And yet I have a system which is now in some sort of indeterminate state.  

Now, do I reboot to get out of this?  But what will rebooting actually do?  Will I end up with an un bootable system?  Will I end up reinstalling everything?

So now I am spending time that should be used to complete a project just doing maintenance on a system that was working perfectly well, it was just out of date.  

And ostensibly `beadm` is supposed to protect me from this.  I have not even started the upgrade.  

I feel like I am on a hamster wheel.  An unending cycle of upgrades.  I only upgraded to 12.1 last March.  That is 11 months ago.  That upgrade took place 11 months after 12.0.  How does one run a business when you have to update operating systems every year?  And in my case the only reason to upgrade is to maintain access to compatible packages. Is this some sort of sysadmin make-work project?

Is it really that burdensome to provide a single archive of older packages somewhere?  It  need not be mirrored everywhere.  Just leave it in some place accessible to pkg manager so that people running EOL freebsd releases can get additional software for their systems that is known to work when they encounter such a need.  I will do that for myself in future but it would be a reasonable service to the community if such was provided.  One can get older releases from the archives, just not the updated software that was provided up to their EOL.

I just do not know what I am going to do with my dev system.   I will have to assume the worst and get everything moved onto another host.  JHC this is such pointless waste of time and resources.


----------



## SirDice (Feb 14, 2021)

byrnejb said:


> How does one run a business when you have to update operating systems every year?


Try running Windows with _monthly_ update cycles.



byrnejb said:


> How does one run a business when you have to update operating systems every year?


Better plan ahead. I'll let you in on a little secret, 12.3 is probably going to be released some time in September. And 12.2 will be EoL three months later.



byrnejb said:


> Is it really that burdensome to provide a single archive of older packages somewhere?


You have a working poudriere installation. Why can't you just build and save whatever you need? 



byrnejb said:


> One can get older releases from the archives, just not the updated software that was provided up to their EOL.


You really don't understand what "end-of-life" means, do you?



> At this stage, a vendor stops the marketing, selling, or provision of parts, services or software updates for the product.








						End-of-life product - Wikipedia
					






					en.wikipedia.org
				






byrnejb said:


> Today I decided to give beadm another go.


Now. Lets give this another go. Unmount and remove the other BEs you created. I would use bectl(8) but this should be the same for beadm(1).

You start off with this:

```
root@armitage:~ # bectl list
BE      Active Mountpoint Space Created
default NR     /          6.43G 2014-02-24 23:39
```
Create a new BE, this will be your backup. 

```
root@armitage:~ # bectl create before-update
root@armitage:~ # bectl list
BE            Active Mountpoint Space Created
before-update -      -          8K    2021-02-14 21:35
default       NR     /          6.43G 2014-02-24 23:39
```
Next, run your upgrade, `freebsd-update -r 12.2-RELEASE upgrade`. Finish the whole upgrade procedure. If anything goes wrong during the upgrade, use the boot menu to select the 'before-update' BE (or use `bectl activate before-update`). If the upgrade went fine, remove the before-update BE.


----------



## byrnejb (Feb 15, 2021)

SirDice said:


> Try running Windows with _monthly_ update cycles.



The main reason that we never ran our business applications on Windows.  We started out with HP-UX, and moved to RH7 something four years later.   When RH went to RHEL we tried that for a year and gave up on it.   We then went to Whitebox Linux, to CaOS when WBL stopped being supported, to CentOS-5 though 7, which was taken over by RH and has been effectively discontinued after 8., and now to FreeBSD.

Windows is used only for desktop applications.  We do not use MS-Office but Libreoffice.  There is nothing else of importance running on them.. The primary use of our AD-DC is to simply control access to the local network.  The business applications all run on Unix, Linux, or MPE/iX systems.  

Windows updates are applied to all desktop systems at intervals which exceed monthly by a considerable margin.  It matters little due to the firewalls, file filters, and proxies used to isolate the work stations from the Internet.  We use Samba for our AD-DCs and the users profiles and Document libraries are also kept on a Samba File server.  

Running Windows without updates  is not completely without risk; what is?  None-the-less while we have been connected to the Internet since 1995 we have never had a virus or malware incident. And, because of our industry, we get hammered night and day by brute-force and phishing expeditions. 


SirDice said:


> Better plan ahead. I'll let you in on a little secret, 12.3 is probably going to be released some time in September. And 12.2 will be EoL three months later.
> 
> You have a working poudriere installation. Why can't you just build and save whatever you need?


That is what I have done in the past and no doubt will do in future.  But first I will take the advice of  Phishfry and use `pkg fetch -a` to create and maintain a complete local repository.
I am not looking for the latest and greatest.  I just need to be able to install software whenever I run into the need for it without having to upgrade the underlying system.

On the matter of rebuilding the software every weekend it is to be noted  that building the `llvm` tool chain alone, which appears to be necessary with distressing frequency, takes on the order of 16-20 hours on an otherwise unused system with 64Gb RAM and an 8-core, 16 cpu, processor, running at 3.69 GHz.  


SirDice said:


> You really don't understand what "end-of-life" means, do you?


Do not be silly.  I am not asking for support after EOL.  I only want access to what software packages that were available immediately before EOL.  This is a policy matter that has nothing to do with support or EOL.  It is simply a matter of disk space. 

I will solve this for myself if not for others by maintaining my own archives.  But, I am sure that I am not the only one that keeps systems running on software well past its arbitrary EOL date.  It is not as if it all suddenly stops working. And providing this for everyone does not appear to me to pose insurmountable, or even terribly inconvenient, difficulties.

The real question that begs to be answered is:  What is the reason the life cycle is so abbreviated to being with?  What are we racing?  Is this little more than a Chromium/Firefox thing where the goal is to have the highest version numbers?


SirDice said:


> Now. Lets give this another go. Unmount and remove the other BEs you created. I would use bectl(8) but this should be the same for beadm(1).
> 
> You start off with this:
> 
> ...



In my case I had to restart the system because I could not get anything to work in the state `beadm` left it in.  USB flash memory would not mount.  The mouse stopped responding.   Fortunately I had an unblocked terminal session running as root and could run shutdown; except that it would not.  Eventually I had to cross my fingers, power-cycle the host, and  pray that it restarted .  

This does not increase my confidence in`beadm`.  It seems to me disconcerting that software designed to protect users from errant updates behaves this way before one even gets to the stage of applying an update.  No doubt prior actions on my part set this scenario up to fail.  But really, did I do anything that self-evidently should have caused the behavior I experienced?  Was there any way for me to reasonably anticipate that this would be the result?  

It is one thing to have done something so regularly that its flaws and eccentricities are unconsciously avoided.  It is quite another to come at something which one has never successfully attempted before.  At least this time I did not have to recover the zpool from a live cd.

Fortunately, there were two BEs present at startup; And the one I had activated was indeed active.  SO the system came up, apparently none the worse for wear, in the alternate BE.  Even if my heart was in my mouth during the boot.

`bectl` and beadm show this:

```
[root@vhost01 ~ (master)]# bectl list
BE               Active Mountpoint Space Created
12.1-RELEASE-p13 NR     /          4.57M 2021-02-14 12:00
default          -      -          97.9G 2020-05-20 11:25

[root@vhost01 ~ (master)]# beadm list
BE               Active Mountpoint  Space Created
default          -      -           97.9G 2020-05-20 11:25
12.1-RELEASE-p13 NR     /            4.6M 2021-02-14 12:00
```



SirDice said:


> Create a new BE, this will be your backup.
> 
> ```
> root@armitage:~ # bectl create before-update
> ...


This evidently has been done.


SirDice said:


> Next, run your upgrade, `freebsd-update -r 12.2-RELEASE upgrade`. Finish the whole upgrade procedure. If anything goes wrong during the upgrade, use the boot menu to select the 'before-update' BE (or use `bectl activate before-update`). If the upgrade went fine, remove the before-update BE.


At the moment my plan of attack is:

First I am going to update my backups, which are done overnight every 24 hours in any case.  

Next I am going to restart the host and go back to the original BE just to satisfy myself that it can be done.

Then I will return to the alternate BE, again to satisfy myself that it can be reliably repeated.  This no doubt appears amusingly over-cautious but frankly, I have been bitten too many times by assuming that things just work as they are supposed to.

Then I will return to the default BE.

Then, and only then, I will attempt to apply the update.

Fortunately, today is a statutory holiday in my location so I have the time to myself to get this done.

My question is this: If things go badly in the update in the default BE and one re-boots into the backup, what then?  Does the alternate BE remain as the default until the next update cycle?  Or does one somehow transition the backup BE back to the default? Or what else?

And lest you think otherwise, I appreciate the help that I get here.  Not the least from yourself.  Thank you.


----------



## SirDice (Feb 15, 2021)

byrnejb said:


> On the matter of rebuilding the software every weekend it is to be noted that building the `llvm` tool chain alone, which appears to be necessary with distressing frequency, takes on the order of 16-20 hours on an otherwise unused system with 64Gb RAM and an 8-core, 16 cpu, processor, running at 3.69 GHz.


You're doing something wrong here. My lowly Core i5-3470 (4 cores, 4 threads) 3.20GHz with 16GB RAM does this in less than 3 hours. While building 3 of them at the same time (llvm90,llvm10,llvm11). I agree the constant building and rebuilding of the different LLVM versions is annoying, but it's not so bad as you're trying to portray. 



byrnejb said:


> The real question that begs to be answered is: What is the reason the life cycle is so abbreviated to being with? What are we racing? Is this little more than a Chromium/Firefox thing where the goal is to have the highest version numbers?


Every major version is supported for no less than 5 years. That's a considerable advantage over the old schedule where even numbered minor versions where supported for 2 years and everything else for only 1. Just keep up with the minor versions, really. The longer you postpone updating the bigger your problems are going to be. If you keep up they're little steps you take. When you keep pushing things forward the steps needed to be taken will get bigger and bigger. Until you get to a point where you have to invest a considerable amount of time trying to figure out everything that's changed.


----------



## shkhln (Feb 15, 2021)

byrnejb said:


> Is it really that burdensome to provide a single archive of older packages somewhere?  It  need not be mirrored everywhere.  Just leave it in some place accessible to pkg manager so that people running EOL freebsd releases can get additional software for their systems that is known to work when they encounter such a need.


Extremely burdensome, in fact. Provide any hint of support and people will demand more free shit on top of that. (There are actually a few release_<minor-number> repos around. Not sure what they are intended for and how long they stay available.)


----------



## byrnejb (Feb 18, 2021)

SirDice said:


> You're doing something wrong here. My lowly Core i5-3470 (4 cores, 4 threads) 3.20GHz with 16GB RAM does this in less than 3 hours. While building 3 of them at the same time (llvm90,llvm10,llvm11). I agree the constant building and rebuilding of the different LLVM versions is annoying, but it's not so bad as you're trying to portray.


I was wrong.  It only takes eight hours.



308llvm10-10.0.1_5devel/llvm10success07:57:16



But Libreoffice is still building fifteen hours into the process:

```
[10:02:29] [01] [00:00:00] Building editors/libreoffice | libreoffice-7.1.0.3_2
```



01libreoffice-7.1.0.3_2editors/libreofficebuild05:36:16


This is my general purpose system.  I have `ccache` enabled.  And my memory is 32 G, not 64.  I had to swap systems last fall and the new one does not have as much memory as the old.  Never noticed it before.


----------



## SirDice (Feb 18, 2021)

byrnejb said:


> It only takes eight hours.


Still about 2.5 times slower than mine, while your system should be able to do this in 2-3 hours. 

In /usr/local/etc/poudriere.conf, set ALLOW_MAKE_JOBS_PACKAGES, that should improve build times.

```
ALLOW_MAKE_JOBS_PACKAGES="pkg llvm* gcc*"
```
In your case you might want to add openjdk* and libreoffice to that list too.


byrnejb said:


> And my memory is 32 G, not 64. I had to swap systems last fall and the new one does not have as much memory as the old.


I do this with 16GB, so 32 should be fine. 64 would be nicer of course. More is always better with this kind of load.


----------



## grahamperrin@ (Mar 21, 2021)

byrnejb said:


> … There many examples on on the web, no two of which do things the same way.  So, proceeding from one of the examples I started this way.:
> 
> ```
> sudo beadm create  12.1-RELEASE-p13
> ...


Seeing use of a temporary mount point, for the boot environment that was to be upgraded, makes me wonder whether the followed example was one that intended to streamline things – through *not* requiring a restart at the stage when (according to the FreeBSD handbook) a restart is customary.

If so: please beware of shooting oneself in the foot when there's on-screen direction to fetch updates. The direction may be inappropriate (as a result of your skipping the restart); if you proceed to install what's fetched, the resulting boot environment might be a horrible mash.


----------



## tomaz (Aug 14, 2022)

zirias@ said:


> The ABI didn't change, so for most packages (excluding some containing kernel modules), *ignoring the error* as hinted in the message should work. (of course NOT tested, UNSUPPORTED!)
> 
> But JUST WHY are there always people insisting on running EOL systems? What's the deal? It's not like upgrading hurts or something. Especially talking about *minor* versions.


Why do developers insist on not understanding that users want to *use* our software and to continue using it once it's working. We don't necessarily need the newest and the fanciest features. The system not breaking is almost always more important and sometimes, the system just *must*not* break. And upgrades always break things.

People still use COBOL and floppy disks, because they have systems that solve a problem. We're *not*interested* in upgrading.

I'm having the exact same issue as the O.P. - Googling my problem brought me to this page. The system I need to install a new package on is located remotely and there is no way to get to it physically in the foreseeable future (as in, months to years). If I try to upgrade the system and the upgrade fails (as upgrades often do), the machine will become inaccessible via the network and there will be no way of resetting it - it will become a brick and there will be no way to unbrick it.

Why is it not possible to keep the packages that have already previously been made available still available, just because the system has been EOL'd?


----------



## zirias@ (Aug 14, 2022)

A minor upgrade will not break things. It _does_ deliver a few features where it won't hurt, but in general, keeping your system up to date is about keeping it secure.

For major upgrades, support cycles are _really_ long enough, so you can prepare as long as you need.

And sure, you _can_ always mess up something yourself. That's why for remote systems, you _need_ remote access to the serial console as well. Anything else is just unprofessional.


----------



## tomaz (Aug 14, 2022)

You can, of course, assume you know everything and call your users "unprofessional" when you don't know how things are deployed, why they were deployed the way they were, and what is possible and what is not. As an alternative, I would encourage you to try listening to what people are telling you. It seems from your post that what you are frustrated by what many people are telling you but unwilling to contemplate the possibility that all these people may have a point.

My remote system is inaccessible. There is ssh access - but that depends on the system being bootable. There isn't (and never was) a way to add a remotely accessible serial console. It does not matter how long I had to prepare. At the time of deployment, it was not foreseeable that the system would ever be inaccessible for this length of time, but due to changed circumstances, this is how things turned out to be.

"This *minor* upgrade will not break things, honest". "Just add this little tweak to the code, it can't break anything, there is no need to redo the Q&A, honest." Famous last words. I've seen that go wrong more times than I care to remember. Very cheap for you to say, very expensive for me to fix when it goes wrong.

When a system deployed in the field that's been designed for reliability & redundancy because it breaking would be expensive or even catastrophic, the last thing you want to do is a pointless software upgrade which adds no value but could break the system.

I've even upgraded the Linux kernel on my laptop - sitting right in front of me on my desk - before and it broke the system to such a degree that there was no option but to wipe it all out and reinstall - in one case, there was no ZFS on Linux release available yet compatible with the new kernel (rather unhelpful, since all my partitions use ZFS), in another case, there were no nVidia drivers yet compatible with the new kernel, so display was unusable. Much of the upgraded userland was incompatible with the old kernel, the new kernel would not boot, so there was no way to boot the system any more. Which kept me offline for several days while I reinstalled the (old version, of course) operating system, at a time I could ill afford it. If it had been a remote system, the situation would have been impossible.

In many cases, upgrading is just not an option, absolutely and under any circumstances. In others cases, it is a conscious choice. Maybe we just don't like a new release. Maybe it's in an embedded system which is at its limit of storage space, and there just isn't the room for an upgrade. Maybe the installed system has been carefully secured and been security audited - and an upgrade invalidates those efforts - so NOT upgrading is about keeping your system secure. Almost every time with closed source software, but also occasionally with open source software (e.g. Ubuntu) we've seen cases where an upgrade surreptitiously installed new spyware.

Many users want the option of being able to run an installed system - once it's been extensively tested to work and solve a problem - indefinitely, without ever upgrading the operating system. The fact that people are telling you that and that you're frustrated by them is proof of that. That doesn't mean we don't need to be able to install additional software packages which were known to be available for that operating system & which makes it very unhelpful if those packages suddenly disappear. I know of people who are still using NeXT computers from the 1980s to drive manufacturing machinery, there are people still running software written in COBOL and I hear there are still people using 8" floppies. Some people use computers to solve problems - not to play around with fancy new features. If you insist on forcing users to upgrade when we don't want to, many people will just conclude it's not possible to work with you because you try to force your will on other people rather than listen to user requirements.


----------



## byrnejb (Aug 15, 2022)

zirias@ said:


> A minor upgrade will not break things. It _does_ deliver a few features where it won't hurt, but in general, keeping your system up to date is about keeping it secure.


This statement is not factual.  I have personal experience with so-called minor upgrades that caused previously working software to simply stop working. I am not interested in debating how my empirical observations conflict with theoretical arguments, much less the presumptive arrogance  which stoops to name calling.


----------



## byrnejb (Aug 15, 2022)

zirias@ said:


> For major upgrades, support cycles are _really_ long enough, so you can prepare as long as you need.


This is also a theoretical argument.  Support cycles are as short as the development community believe they can get away with the majority of the community.


----------



## mer (Aug 15, 2022)

Just because updates are available does not mean one has to actually update.  And yes, I've been bitten hard by the failed remote update and heck even a failed local one.

I understand the problem of "I need to add a new package to my EoL system but it wants to update everything", because I've been there.  But I never expected the project to keep packages built against my EoL version.  Honestly, what should be kept?  The packages defined by the state of the ports tree when the base went EoL?  The last quarterly set of packages for that EoL release?  How far back should the project be expected to keep these packages?  It's all disk space, it's all costing someone real money somewhere to do that.

Lets look a MS Windows ecosystem.  I've know people that pretty much had a system running Win95 because it worked for what they needed.  Web, email, Quicken, a couple other things.  It got to the point where their *applications *got to "If you want to upgrade this application to the latest version, you need to upgrade your system from Win95 to Win-XYZ".  So wanting the supported version of the application they were forced into a system upgrade.  Not pretty (family so of course the resident "expert" gets voluntold to help), but better in the long run.

I'm telling you that simply because it is similar to what's described here:  application driving system upgrade.


----------



## cy@ (Aug 15, 2022)

mer, This reminds me of a story that was relayed to me a number of years ago. A university in Eastern Canada had an IBM mainframe application that that only ran on an ancient version of OS/MVT. (OS/MVT was the predecessor to OS/VS2, which became MVS, ... which became todays z/OS. MVT did not support paging and only operated in 24-bit mode, not 31- [yes, 31, not 32] or 64-bit mode.) They lost source code to their application. And, newer IBM mainframes were incapable of running the old MVS because new mainframes do not support bus and tag (think ISA bus on PCs -- I don't think anything except maybe NetBSD supports ISA anymore) interfaces. They spun up a z/VM (another IBM mainframe O/S) instance to emulate old hardware in order to run the old O/S which could run their old app which they had lost the source code to. These are the lengths to which people go to in order to run old software. This kind of stuff happens more often than we might think.


----------



## mer (Aug 15, 2022)

cy@ that tops just about "it does what I want why should I upgrade" stories that I have.  Father In Law may have had a Win3.x that just kept on going for longer than it should, but I was the one that had to explain the Win95 to whatever was next.


----------



## byrnejb (Aug 16, 2022)

A couple or three, (or more) points:

1.  If constraints of resources require then of course disposing of packages repositories for EOL releases can hardy be argued against.  However, I point out that with the cost of online disk storage being what it is, and considering the bandwidth demanded would likely be little more than zero, it is hard to believe that resource constraints drive this policy.  My own observation is that the current main branch of the ports tree amounts to 112Mb when downloaded as a zip file.  Granted, these are source files and not binary packages.

2. The solution that I have applied, in the absence of any change in policy (which seems to me to be very unlikely and therefore not worth discussing), is to run `pkg fetch -a` periodically and keep things in my `/var/db/cache/pkg/` directory on my workstation.  From there I can move them to any system, local or remote, that needs a particular piece of software.  I have not gone to the extent of sub-dividing the cache into OS versions, but that would be trivial to do.

3. As the ports tree is universal (in that it is not OS release specific) and is now in `git` it is possible to select a date, find the tag or commit nearest to, but before, a given date, download the packages needed from that point, and build them.  It is not entirely straight forward but it can be done with a little effort, as I discovered through experiment.  In fact, the github has quarterly branches going back to 2014.  One can simply checkout the branch desired and go from there.

4. Respecting old hardware and software:  

We have a bespoke business application system written in a 1980's 4GL. This runs on a computer host built in 1994.  We are installing an emulator for the OS used by this system to run in a Rockly Linux VM guest of a BHyve hypervisor running on FreeBSD-12.3 or 13.1 and Intel hardware.  That emulator will host the business application.

Moving the application to new hardware from the OEM requires an expenditure of more than $300,000.00 USD  just for the licence transfer fee.  And this would not solve the problem that the necessary hardware is no longer sold nor supported by the OEM.  Rewriting the software to use more current technology would cost considerably more.  We know because we tried.  The cost of the emulator software is $40,000.00 CAD installed and verified.  The Intel hardware cost ~$3,000.00 CAD.  

By taking this approach the business also avoids the costs of retraining staff and the loss of business transaction history that would necessarily follow conversion to a different application system.  It also preserves the investment in custom programming carried out over the course of ~40 years.  That is long term.  Five years is nothing.

And we have all of the source code maintained in a Git repository since October 29, 2009.


----------



## tomaz (Aug 16, 2022)

I was also puzzled by the statement that continuing to store the packages costs space which costs money, because cloud storage is so cheap these days and the amount of space required is so small (and, as you say, the amount of bandwidth consumed by old versions would be very small). I think it's more a consequence of a deliberate "c'mon upgrade, it's not like it hurts" philosophy.

But it's not just about "it works, so why upgrade". No mission critical system should ever go through a live upgrade. It runs. Then when you have an upgraded version, it's an entirely new piece of hardware, with the new software, you test it and test it, and test it, and test it some more, then you replace the old system at a time when minimal downtime is acceptable, and be ready to put the old system back in place if the transition fails. You just can't upgrade, cross your fingers and hope - and suffer days of downtime if it goes wrong.

Thank you for your suggested solution, which is really what I'm looking for. I don't have the room on my system, unfortunately, for packages I'm not going to use (it's an embedded device), nor for development tools. I guess I'm going to have to install a new copy of the old system locally and try to build the missing package and copy it to the remote system and install it that way. But building software out of the package hierarchy can be a messy process, if you miss some dependency. I guess that's the whole point of the package system. I've not built FreeBSD packages before, how feasible is it to download the source code of the old packages and build the actual package on a separate (newly installed) development system based on the same old version I have on my remote hardware and then use the package system to try to install it, then see what dependencies it comes up with, then build those and so on?


----------



## zirias@ (Aug 16, 2022)

FreeBSD won't ever support you by hosting repositories for EOL systems. End of story here.

Anyways, If you _really_ think you _absolutely_ need this, you have all the tools at hand to do it yourself. Although the common practice for "live systems" nowadays is having them multiple times, taking one instance out for update, test that, and if everything is fine be done with it (I won't describe the _whole_ process now...)

edit: I'll add my *personal, non-official* opinion why I think FreeBSD should never start supporting this. Less important, it would be an interesting oxymoron to support something not supported any more. More important, without _real_ support (by at least delivering security patches), it would be very bad reputation if some consumer of such a repository would be hit by an exploit of a previously known vulnerability.


----------



## tomaz (Aug 16, 2022)

I ran

`setenv  IGNORE_OSVERSION yes
pkg install speedtest-cli`

I was told that this required "pkg" to be also upgraded. The install of speedtest-cli failed and install ended with
`Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.15.6 to 1.16.1...
[1/1] Extracting pkg-1.16.1: 100%
You may need to manually remove /usr/local/etc/pkg.conf if it is no longer needed.
Shared object "libarchive.so.7" not found, required by "pkg"`

Now when I run "pkg", it fails with 
`Shared object "libarchive.so.7" not found, required by "pkg"`

So what now Mr Smart-Arse "minor version upgrades won't break anything"?


----------



## shkhln (Aug 16, 2022)

tomaz said:


> because cloud storage is so cheap these days


If storage is so cheap, you can probably set up a mirror yourself. (That's probably somewhere around one new HDD per week.)


----------



## Alexander88207 (Aug 16, 2022)

tomaz said:


> So what now Mr Smart-Arse "minor version upgrades won't break anything"?



I'm sure this refers to after an upgrade and not when ignoring an upgrade.


----------



## tomaz (Aug 16, 2022)

shkhln said:


> If storage is so cheap, you can probably set up a mirror yourself. (That's probably somewhere around one new HDD per week.)


No I can't because my time is not cheap. I doubt it's one HDD per week, but one HDD per week is a lot cheaper than the cost of everyone's wasted time (even my wasted time alone). At any rate, I'm not interested in arguing, I'm looking for a solution. I've already decided not to use FreeBSD in the future, but right now I'm stuck with the consequences of my past decisions. Enjoy congratulating each other in your echo chamber, I hardly think I'm alone among users in reaching the conclusion I've reached.


----------



## elgrande (Aug 16, 2022)

tomaz said:


> Now when I run "pkg", it fails with
> `Shared object "libarchive.so.7" not found, required by "pkg"`


Reminds me of this:
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you. Hard. A lot.
*/


----------



## shkhln (Aug 16, 2022)

shkhln said:


> If storage is so cheap, you can probably set up a mirror yourself. (That's probably somewhere around one new HDD per week.)


I don't want leave the question open to speculation, so

```
#!/usr/local/bin/ruby
# encoding: UTF-8

require 'json'

if not File.exist?('packagesite.yaml')
  system('fetch http://pkg.freebsd.org/FreeBSD:13:amd64/release_1/packagesite.txz && tar -xf packagesite.txz')
end

nbytes = 0

File.open('packagesite.yaml').each_line do |package|
  nbytes += JSON.parse(package)['pkgsize']
end

puts "#{nbytes.to_f / (1000 ** 3)} GB"
```
prints "only"

```
106.5492852 GB
```
Keep in mind this a snapshot of a single repo, though.


----------



## tomaz (Aug 16, 2022)

elgrande said:


> Reminds me of this:
> /*
> * Your warranty is now void.
> *
> ...


Yes, force people to either upgrade (which they don't want) or tell them to use the ignore flag, since it's only a minor version upgrade, so ABI hasn't changed so it should all work, but it's all unsupported, then when they do either thing and it goes horribly wrong, run away like a coward and hide.

Anyway, I fixed my problem. In case it helps anyone else, after the failed "pkg" upgrade, I fished out "pkg-1.15.6.txz" and "pkg-1.16.1.txz" from /var/cache/pkg. I examined the manifests. I manually deleted the files installed by the incompatible "pkg-1.16.1.txz", look what the post and pre uninstall scripts did and replicated their effect, then manually installed the contents of "pkg-1.15.6.txz" and did the same with the scripts, thus restoring my "pkg" to the known working version. For some reason, after this, pkg started working and is no longer stopping me installing new packages as it was in the same way the O.P. was prevented from installing new packages and as I was when I was first brought to this thread. I wonder why? I was then able to install "py37-speedtest-cli-2.1.2" which is the package I wanted to install. That's an out of date package known to be broken (with a known fix in 2.1.3), so I'm guessing it's not from the latest repo? Anyway, 2.1.2 can be made to work with a small patch, which I manually applied, and now everything's doing what I wanted it to - the original version of the O.S. is still there doing what it's supposed to do, and I installed my desired package.


----------



## tomaz (Aug 16, 2022)

shkhln said:


> I don't want leave the question open to speculation, so
> 
> ```
> #!/usr/local/bin/ruby
> ...


18TB WD181KRYZ is $450 on Amazon and can hold 170 such snapshots. To store the last version of each package of each EOL release surely can't be more than a few hundred releases' worth - in the entire history of FreeBSD. So the total cost of storage for everything would be about $1000. Nothing compared to even one person having to go through the hassle of manually installing their needed packages because they've been removed. The whole thing has nothing to do with the cost of storage and everything to do with control freakery.


----------



## shkhln (Aug 16, 2022)

tomaz said:


> I doubt it's one HDD per week, but one HDD per week is a lot cheaper


You'd think so, but then somebody has to buy a yet another server to put them in. The foundation operates on a very tight budget.



tomaz said:


> than the cost of everyone's wasted time (even my wasted time alone).


Would that make "everyone" angry enough to stop donating money? Otherwise that comparison doesn't make any sense.


----------



## shkhln (Aug 16, 2022)

tomaz said:


> To store the last version of each package of each EOL release surely can't be more than a few hundred releases' worth - in the entire history of FreeBSD.


I already wrote in this very thread, there are per-release snapshots of the repositories, although they aren't exactly supported and I don't think anyone actually promised to keep an archive of them.


----------



## Jose (Aug 17, 2022)

tomaz said:


> No I can't because my time is not cheap.





tomaz said:


> 18TB WD181KRYZ is $450 on Amazon and can hold 170 such snapshots. To store the last version of each package of each EOL release surely can't be more than a few hundred releases' worth - in the entire history of FreeBSD. So the total cost of storage for everything would be about $1000.



Let's summarize:

You don't want to work for it
You don't want to pay for it
You just want someone to spend their time and money and give it to you for free
Maybe it'll help if you bang your spoon on the high chair some more.


----------



## monwarez (Aug 17, 2022)

tomaz said:


> I ran
> 
> `setenv  IGNORE_OSVERSION yes
> pkg install speedtest-cli`
> ...


What is the reason to change this default, it is a default for a reason: to not shoot on your foot.
Just looking at the manpage: 


> IGNORE_OSVERSION: boolean [FreeBSD specific]
> Ignore FreeBSD OS version check, useful on -STABLE and
> -CURRENT branches.  Default: NO.


You are neither running -STABLE nor -CURRENT so enabling this settings allow yourself to shoot on your foot.


----------



## zirias@ (Aug 17, 2022)

tomaz said:


> So what now Mr Smart-Arse "minor version upgrades won't break anything"?


You didn't do the minor version upgrade but instead tried something *completely* unsupported.

I would very much prefer if you could get around without insults. It's your fault you don't upgrade your systems as you're supposed to. FreeBSD support cycles are predictable and have overlaps that should be long enough for any admin worth their money. If you still disagree, maybe look for an OS that matches your expectations better?


----------



## zirias@ (Aug 17, 2022)

monwarez said:


> You are neither running -STABLE nor -CURRENT so enabling this settings allow yourself to shoot on your foot.


Just to complete this, it allows "foot shooting" on any branch... The thing is, users of -STABLE or -CURRENT _might_ occassionally need it and are expected to know exactly what they're doing, otherwise they should run -RELEASE


----------



## mer (Aug 17, 2022)

Initial cost of media do actually do the storage is not really the issue.  There are also recurring costs for things like electricity to power the media, to power the cooling for the devices.
Cloud storage:  ok for some things but often at the mercy of whomever is providing it.  I can easily recall a few times over the past year or two where Amazon AWS had issues and put a whole bunch of websites off the air for a while.  It's not bad if the website is only hosting pictures of your cats, but if it's your online store you are losing money.

I just don't understand the argument that FreeBSD should be keeping around a copy of applications that were built against a version of base that has been end of lifed.
Nothing prevents anyone from still running that EoL'd version, heck there are probably people still running Win95.  But an expectation of applications being kept around?  My opinion, no.   
I also have a realistic expectation that it doesn't matter what I say to folks that truly believe the project should be keeping things forever.


----------



## byrnejb (Aug 23, 2022)

mer said:


> I just don't understand the argument that FreeBSD should be keeping around a copy of applications that were built against a version of base that has been end of lifed.



And yet the entire FreeBSD ports tree, containing every change ever committed, is on github going back to 2014Q1.


----------



## SirDice (Aug 23, 2022)

byrnejb said:


> And yet the entire FreeBSD ports tree, containing every change ever committed, is on github going back to 2014Q1.


It goes way further back than that. 2014 was the first year the quarterly branches were introduced. The ports tree itself existed long before that, and so does its history. The entire subversion (and CVS before that) history was merged to git too.

But just because you have a history of the ports tree, that's just how a version control system works, doesn't mean you should keep everything that it ever built around.


----------



## mer (Aug 23, 2022)

byrnejb said:


> And yet the entire FreeBSD ports tree, containing every change ever committed, is on github going back to 2014Q1.


Sure, I'll play.
Because it's the source code and it's in a SCM tool and not "built binary packages for every single architecture that was supported against every single release".

Big difference and the discussions about the "cost of storage is so cheap", well someone still has to pay for it.  If you want to pay for the storage and the recurring costs to keep a version of your desired ports tree around, then why not send a donation to the Foundation earmarked for that?


----------



## tomaz (Aug 31, 2022)

There are people - like the OP and myself - who have FreeBSD installations in the wild, which it turns out are EOL, where upgrading the O.S. is not an option, and where we need to install new applications. We already know that if we upgraded the O.S., we could have access to repositories - because the computer itself tells us this. Telling us that again is completely unhelpful because upgrading the O.S. is not an option under our circumstances, and we've made that clear.

I've been using other open source O.S.'s but I've never come across a problem like this - package repositories disappearing - before, so it's not something I was even contemplating as a possibility until I was suddenly unable to install new packages. I'm sure it's written somewhere, but I - and I am sure most users - don't have the time to read every Wiki page before setting up an appliance to solve a problem.

Contrary to what some people seem to think, our time is not free and we're not necessarily using open source software because we don't have to spend money (we certainly have to spend money on hardware and our time - which is more valuable), but for other reasons such as security, privacy, auditability etc. One of the reasons for using open source software is that you are in control of your computer and what software runs on it, rather than the computer being in control of you. Obviously if the computer forces you to "upgrade" your O.S., then you're no longer in control of your own computer. Having said that, while I'm happy to spend money, I would certainly never give a dime to an entity, commercial or otherwise, whose techies think it's OK to insult me.

If you have something helpful to tell us (e.g. some of us may be able to build the deleted packages from source, time consuming as it is, it may be the least worst option - we may have developer experience but not FreeBSD specific knowledge as to how to do this or where to look for for the correct version of source code) - then please kindly do so. Otherwise, do you really have to speak?

Obviously FreeBSD is going to continue to delete packages that had already been made available in repositories, I get that. And that's OK, it does make FreeBSD totally unfit for purpose for many people, it certainly does for me, but it's your playground, make it inhospitable to other people and play in your tiny sand pit if that floats your boat.

I won't use FreeBSD in new installs in the future, but unfortunately in the meantime, I do have a few devices in the wild which run FreeBSD and FreeBSD derivatives which I cannot replace any time soon, which I do need to maintain, where I do need to install new software from time to time and where upgrading the O.S. is n-o-t  a-n  o-p-t-i-o-n.

Thanks.


----------



## zirias@ (Aug 31, 2022)

tomaz said:


> There are people - like the OP and myself - who have FreeBSD installations in the wild, which it turns out are EOL, where upgrading the O.S. is not an option, and where we need to install new applications.


Too bad it's not supported.

Thanks.


----------



## shkhln (Aug 31, 2022)

What's next? Complaining versions of applications in the old repos (as I already said _twice_ in this thread we actually have those) are not new enough?


----------



## cy@ (Aug 31, 2022)

Let's say for example a person is running FreeBSD 8.1 (I know of a company, not mine, still running this version of FreeBSD and an old employer of mine was running 4.4.0 until recently). Let's say they want to install a port. They could,

git clone https://github.../ports.git
git checkout release/8.1.0 or git checkout release/4.4.0

With this they have the ports collection as of the day 8.1.0 was released. Just cd to the port and make install.

Anticipating someone saying, "but how do I git clone without git on the box?" Easy. Find a system that has git, Linux, FreeBSD or whatever, then ./configure and make. It's not hard to do.

Anticipating: "but that's too hard." Easy. Doing builds by hand, using ftp or schlepping files over the network should be easy for any sysadmin. When I switched careers from IBM mainframe to UNIX in 1992, all we had was ./configure, if even that. We made it work. When running old unmaintained software, these re the things a person needs to do.

As for maintaining an old EOL system, a system that will never receive security updates again on one's network. How's that secure? Think about that for a while.

As for maintaining old versions of packages for releases that are EOLed just in case some random person might want some random package years down the road is ridiculous. Think about that a little.


----------



## Phishfry (Aug 31, 2022)

cy@ said:


> With this they have the ports collection as of the day 8.1.0 was released


But not the distfiles...
What are the chances a 10 year old file exists.


----------



## zirias@ (Aug 31, 2022)

Phishfry said:


> But not the distfiles...
> What are the chances a 10 year old file exists.


Easy, just direct a similar rant towards each and every upstream project 

Seriously, this thread is getting too much attention.


----------



## SirDice (Aug 31, 2022)

Phishfry said:


> What are the chances a 10 year old file exists.


Some say "the internet never forgets". Try finding some old version of a long forgotten application and find out


----------



## Phishfry (Aug 31, 2022)

Having the name of the dist file in the Makefile is useful. That at least allows you to retrieve it manually.
The only reason I spoke up is because I spent the legwork chasing old ports and it is not reliable.
Creaky would be the adjective I use. Not because of FreeBSD ports, but the fluidity of file hostings on the internet.


----------



## covacat (Aug 31, 2022)

Phishfry said:


> But not the distfiles...
> What are the chances a 10 year old file exists.


you can find a lot 
even with MASTER_SITE_FREEBSD i could get httpd-2.2.9.tar.bz2  which is from 2008


----------



## tomaz (Aug 31, 2022)

cy@ said:


> Let's say for example a person is running FreeBSD 8.1 (I know of a company, not mine, still running this version of FreeBSD and an old employer of mine was running 4.4.0 until recently). Let's say they want to install a port. They could,
> 
> git clone https://github.../ports.git
> git checkout release/8.1.0 or git checkout release/4.4.0
> ...


Thanks. So will this get me the source code to the O.S. or also to all the latest version of all the packages for optional software for that O.S. release? How do I build a package file on a development system to then copy over to the deployment system and use "pkg" to install it? Make install will install things on my development system but will not give me a package I can copy over to the deployment system and use the installer to install there (or indeed even just a tarball which isn't ideal anyway as it doesn't warn me about missing dependencies). It will also not build all the dependencies but I guess pkg will tell me about the missing dependencies once I try to install the package and I can build those, rinse and repeat.

If you want to understand why upgrading the O.S. is not an option in my - and many other peoples' - circumstances - great. If not, that's your prerogative. I'm not trying to change your mind. I'm just trying to solve a problem. If you have something constructive to add to that end, thank you. I will not use FreeBSD on new installs, because FreeBSD policy on deleting packages for EOL systems does not work for me. In the meantime, I do have to maintain my existing installations.


----------



## SirDice (Aug 31, 2022)

tomaz said:


> How do I build a package file on a development system to then copy over to the deployment system and use "pkg" to install it?


Anything before 9.0 won't support pkg(8) aka PKGNG. Those versions used the 'old' pkg_tools. 



tomaz said:


> Make install will install things on my development system but will not give me a package


`make package` has existed since the dawn of time, or FreeBSD 3.0 in my case.


tomaz said:


> It will also not build all the dependencies but I guess pkg will tell me about the missing dependencies once I try to install the package and I can build those, rinse and repeat.


There's also `make package-recursive`, which does what you would expect.



tomaz said:


> I will not use FreeBSD on new installs, because FreeBSD policy on deleting packages for EOL systems does not work for me. In the meantime, I do have to maintain my existing installations.


I don't understand why you aren't storing those files yourself, if they're that important to you. Why are you relying on third parties to keep providing them?


----------



## cy@ (Aug 31, 2022)

SirDice said:


> Anything before 9.0 won't support pkg(8) aka PKGNG.
> 
> 
> `make package` has existing since the dawn of time.


Before there was pkgng we had pkg, as in pkg_info, pkg_install, etc. Ports needed to be installed into /usr/local, then make package would create a tarball containing all the files in pkg-plist + install scripts + the plist itself. Packages were staged on a real live FreeBSD system on infrastructure called Bento. There was a site called redports that assisted developers with package testing. I assume they had real computers (for jail was still a gleam in someone's eye).

Tools such as portmaster and portupgrade (both are still in ports) would automate this process for you.

Back in those days I'd build by hand on one of my machines and rsync /usr/local /var/db/{ports,pkg} to the various machines in my network.

The ports infrastructure was quite fragile at the and took a lot of hand holding.

So yes, a person could do this the "old way"(tm). But why? Why run old software?

During my 40+ year career on mainframe, UNIX, FreeBSD, Linux, etc. Those who choose not to upgrade or not to patch are afraid their app will break. Many of my clients over the years have felt that way. Only to panic when the situation forced them to abandon their lazy ways because of some urgent need -- usually a serious event of some kind that required them to react instead of adopting proactive habits.

Case in point. One client refused to approve O/S patching and failed to perform any application maintenance. That all changed due to meltdown. Painful lesson learned.

One can choose to sleep at night or choose a life of pain. Like everything. It's a choice.


----------



## tomaz (Aug 31, 2022)

SirDice said:


> Anything before 9.0 won't support pkg(8) aka PKGNG. Those versions used the 'old' pkg_tools.
> 
> 
> `make package` has existed since the dawn of time, or FreeBSD 3.0 in my case.
> ...


Thanks, I'll try make package-recursive.

I don't maintain full repositories of all the packages for all the versions of all the operating systems I have installed on all my systems, and keep them up-to-date. I don't know anyone who does that.

I don't think most O.S. distros delete package repositories for old O.S. versions, at least I've never come across this problem before.

But you're right, perhaps I should review which repositories of which O.S.'s are most critically important to me and mirror at least a version of them, in case some catastrophe happens and the entire Internet goes offline, etc.


----------



## tomaz (Aug 31, 2022)

cy@ said:


> Why run old software?
> 
> During my 40+ year career on mainframe, UNIX, FreeBSD, Linux, etc. Those who choose not to upgrade or not to patch are afraid their app will break.


Because it works.

Because sometimes you don't have a choice.

Because sometimes you just don't want to. Maybe the new version has some "features" you don't want on your computer. Maybe it contains spyware. Maybe it doesn't but you can't verify that. Maybe you've spent 3 years working around all the bugs in the old O.S. version and now things just about work, and you don't want to spend the next 3 years working around the bugs in the new O.S. version. And maybe you just don't want to - just because.

In my >40 years of using mainframes, Unix, FreeBSD, Linux, etc. I've found that the concerns of those who fear their app will break are often well justified.

As I said, each to his own. I'm not going to try to change your mind. I'm just trying to solve a problem.


----------



## mer (Aug 31, 2022)

SirDice said:


> `make package` has existed since the dawn of time, or FreeBSD 3.0 in my case.


I used to use portmaster when I was building things from source


----------



## zirias@ (Aug 31, 2022)

tomaz said:


> Because it works.
> [...]
> [...]


So, lots of words with not a single real answer. Well then, I guess we know what the answer is. Yes, fear is one component of it, I'll leave the others to the readers' conclusion...

A system (or even just software) past EoL with a network connection is a ticking timebomb. *That's* what you should fear, not software upgrades.

It really amazes me there are people who obvioulsy believe to do professional work and then come up with "I can't upgrade this system".

I'm used working at a larger scale company. It happens some system gets past EoL. It creates a _lot_ of drama when it happens, which could very quickly escalate up to the CISO. And this really is how it _should_ be. There's absolutely *nothing* that could ever justify the risk of running unpatched old software.


----------



## mer (Aug 31, 2022)

I have a Windows 3.3 system but I can't find any application updates to run on it.


----------



## tomaz (Sep 1, 2022)

zirias@ said:


> mer said:
> 
> 
> > I have a Windows 3.3 system but I can't find any application updates to run on it.


Much of this thread has been dominated by people like Beavis preaching to those trying to solve real world problems, delivering haughty sermons about what should and ought to be, in theory, while simultaneously demonstrating a comprehensive lack of knowledge or understanding of the real world or its constraints, or any respect for other people who have to deal with the said practical real world constraints. Is this another example of the same or do you know something the rest of us don't? I've never heard of Windows 3.3. There was 3.2 and 3.5 but AFAIK, there was no 3.3.

In theory, you're running a Windows 3.3 and can't find any application updates to run on it. In practice, you're speaking without having tested your theory in practice (or you'd know it doesn't work), you're talking in theory and those of us who do know the practice know that your "in theory" doesn't work in practice. It's a trivial point, but a pretty good illustration of what's wrong with many of the more arrogant responses in this thread.


----------



## Jose (Sep 1, 2022)

tomaz said:


> Much of this thread has been dominated by people like Beavis preaching to those trying to solve real world problems, delivering haughty sermons about what should and ought to be...


Keep whining. It's bound to work eventually.


----------



## cy@ (Sep 1, 2022)

tomaz said:


> Because it works.
> 
> Because sometimes you don't have a choice.
> 
> ...


That's what those clients, said. Especially one of clients that got pwned. Their strategy to not update software resulted in a lot more pain than they had bargained for.

I told them two weeks before they got pwned what needed to be done (in this case a $50K firewall, O/S patching, and application patching and maintenance). They replied this would cost too many $$$. They didn't want to put the work in nor did they want to spend the $$$. Oh I get it alright. It's all about the work that might not need to be done and the $$$ that might be saved. When all was set and done they spent $50M on remediation from being pwned when in fact a few $ spent proactively on a firewall, O/S patching and application maintenance would have saved millions.

But as you said, "each to his own."

This attitude keeps people like me gainfully employed.


----------



## tomaz (Sep 2, 2022)

cy@ said:


> That's what those clients, said. Especially one of clients that got pwned. Their strategy to not update software resulted in a lot more pain than they had bargained for.
> 
> I told them two weeks before they got pwned what needed to be done (in this case a $50K firewall, O/S patching, and application patching and maintenance). They replied this would cost too many $$$. They didn't want to put the work in nor did they want to spend the $$$. Oh I get it alright. It's all about the work that might not need to be done and the $$$ that might be saved. When all was set and done they spent $50M on remediation from being pwned when in fact a few $ spent proactively on a firewall, O/S patching and application maintenance would have saved millions.
> 
> ...


I'm glad your way works for you. My way works for me too. I've never had a security breach in ~45 years so I think I'll keep doing what I'm doing, thank you. Even if I, unlike our friend Beavis, don't already know everything and don't have nothing to learn from anyone else.

Your story is all very interesting but not very relevant to my situation where upgrading the operating system of this appliance is *not*possible*. It is also not necessary. It would add nothing to the security of my setup, and quite possibly could detract from it.

For the record, in my experience, performing regular software updates (= having a perpetually unstable software setup & not knowing what new bugs and security gaps and possibly even deliberate malware are constantly being introduced) is an extremely poor security practice. Unless you audit and secure your installation anew every time you update the software, which is far too much work to be practical, and even then constantly changing your software makes it much more likely you'll miss something at least once. It's much less risky to freeze your software installation - after you've made sure it is properly secured - and then leave it unchanged.

At any rate, my thanks to SirDice for his make package-recursive tip, I'll try it out if and when I have some spare time to install a development system.


----------



## elgrande (Sep 2, 2022)

tomaz said:


> For the record, in my experience, performing regular software updates (= having a perpetually unstable software setup & not knowing what new bugs and security gaps and possibly even deliberate malware are constantly being introduced) is an extremely poor security practice.



This is such nonsense, I have no words...


----------

