# 11.2-RELEASE-p9 End-of-Life



## noodlefling (Apr 27, 2019)

```
WARNING: FreeBSD 11.2-RELEASE-p9 is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.
```

I got the above warning message when doing a `freebsd-update fetch` (although no updates were needed) today.

The site says 11.2 will be good until "11.3-RELEASE + 3 months", but 11.3 isn't even out yet.

Should I just ignore the message for now?  Major version upgrades often come with unnecessary pain (I never have any interest in new features, I just don't want the system to be insecure), so I'd like to hang on to 11.x for as long as possible while the bleeding edgers beta test 12.x.


----------



## Vull (Apr 27, 2019)

According to its release schedule 11.3-RELEASE won't be released until some as-yet-to-be-announced date on or after July 9, so we should still have until some time on or after October 9.


----------



## kfv (Apr 27, 2019)

According to the FreeBSD support model, yes 11.2-RELEASE will be supported at least three months after 11.3-RELEASE so you have nothing to worry about and it's only an announcement since 11.3-RELEASE itself would not be out within two months.
To stay tuned on the release process follow the release schedule.

In the meanwhile, 12 is not considered beta and personally am using it in production environment, so give it a try if you like ;-)


----------



## noodlefling (Apr 27, 2019)

I guess it's a suggestion and not a requirement, but it's a weird error message.

Anyway, thanks for the confirmation, guys.


----------



## Chris236 (May 1, 2019)

It shows the utter absurdity of the FreeBSD support model.

Somebody needs to look at the models of CentOS or Ubuntu....  we need support frames of 5-10 years for professional environments.


----------



## hukadan (May 1, 2019)

Chris236 said:


> Somebody needs to look at the models of CentOS or Ubuntu.... we need support frames of 5-10 years for professional environments.


This is a great idea, I wonder why no one thought about it before. Maybe because, while the FreeBSD foundation is trying to raise $1,250,000, IBM agreed to acquire RedHat for $33.4 billion.


----------



## PMc (May 1, 2019)

Chris236 said:


> It shows the utter absurdity of the FreeBSD support model.



There should be no "support" model. If somebody needs support, then in any and all realms of life it is the case that they have to engage somebody to provide them with their needed support. TANSTAAFL.


----------



## Chris236 (May 1, 2019)

PMc said:


> There should be no "support" model. If somebody needs support, then in any and all realms of life it is the case that they have to engage somebody to provide them with their needed support. TANSTAAFL.


Sorry that is nonsense. The second the FreeBSD project declares a release EOL, I can not buy support for it any more.  Believe me, I have tried.  The lack of affordable commercial support for FreeBSD is staggering, and the very few vendors who can be persuaded to provide it (usually,a t much inflated prices) always categorically demand to cover only non-EOL releases. 

Oh - and I am not talking "support" support. I am talking security patches support.

And I would LOVE to throw the kind of money we throw at Redhat towards a BSD support organization - but that just does not exist, not in the US and certainly not in Europe.  The vendor catalog that used to be on the FreeBSD site (is it still there?) was always an outdated joke with most companies on it having no clue about them being there, and the rest being small consultancies or freelancers without the substance for serious support contracts. 
(And again, believe me, I tried phoning all the Central European ones at some point in the past)

And given all that, your hastily thrown down TANSTAAFL comment is outright offensive. You have no clue what you are talking about. I pay for my lunch, thank you. There is just no vendor to buy it from.


----------



## Chris236 (May 2, 2019)

hukadan said:


> This is a great idea, I wonder why no one thought about it before. Maybe because, while the FreeBSD foundation is trying to raise $1,250,000, IBM agreed to acquire RedHat for $33.4 billion.


Well, IBM is in the business of making money, not giving it away. So long term support must be a good idea., isn't it?


----------



## PMc (May 2, 2019)

Chris236 said:


> Sorry that is nonsense. The second the FreeBSD project declares a release EOL, I can not buy support for it any more.  Believe me, I have tried.  The lack of affordable commercial support for FreeBSD is staggering, and the very few vendors who can be persuaded to provide it (usually,a t much inflated prices) always categorically demand to cover only non-EOL releases.



You're welcome - I know that it is nonsense. But it is a problem, and I don't really see a solution: anywhere in life when somebody needs some kind of support, they pay for that - and in most cases they pay willingliy. But how could such a scheme be implemented into FreeBSD?



> Oh - and I am not talking "support" support. I am talking security patches support.



That makes things more complicated, but otherwise it's the same: there is the need to put deliberate effort into some work, and there are -probably- people who would pay for a proper outcome. But while we might manage to bring them together for the matter of individual support, with security patches it is a collective matter.



> And given all that, your hastily thrown down TANSTAAFL comment is outright offensive. You have no clue what you are talking about. I pay for my lunch, thank you. There is just no vendor to buy it from.



Okay, sorry for that. I never looked at it from that viewpoint, I only noticed that there is no market for *BSD. So either the userbase is too small - or people just take for free what they get for free (those who copy the code do so, that's obvious), or - I don't know. From legal terms (as I think I understand them) anybody would be free to do with *BSD the same thing as RedHat did with Linux.


----------



## SirDice (May 2, 2019)

Chris236 said:


> we need support frames of 5-10 years for professional environments.


5  year support on the base OS is actually irrelevant. The ports tree and everything it contains doesn't fall in this category. You have the exact same applications regardless of the version of the base OS. And those are the ones that are important, not the version of the OS. I mean what good does 10 year support on FreeBSD X.Y do when you're depending on PHP, MySQL or any of the other applications which don't follow that support model?

Does it really matter if you have FreeBSD 11.2 with Apache 2.4 and PHP 7.1, FreeBSD 11.3 with Apache 2.4 and PHP 7.1 or FreeBSD 16.9 with Apache 2.4 and PHP 7.1?


----------



## PMc (May 2, 2019)

The fact itself does usually not matter, but upgrading means that you need to do extensive tests concerning, _what does the new release do with the hardware._
The software packages are not so big a problem, they are data-in/data-out, and if in doubt one can look at that data. But the device drivers are data-in/electricity-out, and it is a bit more difficult to test that.


----------



## tommiie (May 2, 2019)

noodlefling said:


> Major version upgrades often come with unnecessary pain



I'm quite new to the party here at FreeBSD. I installed 11.2-RELEASE on my laptop in January 2019 and was quite reluctant to upgrade to 12.0-RELEASE, afraid I would break all kinds of things. The upgrade, however, went very smoothly. Except... that it broke my manually compiled i915kms driver which I needed as the base driver from 11.2 was too old for my hardware. That was easily fixed though by installing the base driver from 12.0.

I've also been told it would be easy to "downgrade" should you have ZFS installed. Something with snapshots and such. I haven't tried this yet but it sounds very cool. So perhaps you could give it a shot anyway on a few of your servers?


----------



## hukadan (May 2, 2019)

Chris236 said:


> Well, IBM is in the business of making money, not giving it away. So long term support must be a good idea., isn't it?


As long as you have enough money to hire people to make it happen. Such long time support does not happen in vacuum.


----------



## ralphbsz (May 2, 2019)

Let's ignore the whining about support models, and instead focus on the OP: That message is partially misleading, and partially outright wrong.  I saw the same message Friday night on my machine.  Let's analyze it:

"FreeBSD 11.2-RELEASE-p9 is approaching its End-of-Life date."
That's correct, but only if you use a very aggressive definition of end-of-life.  That date is July 5, 2019 + 3 months, or a little over 6 months away.  Given that the grace period for minor releases is 3 months, the term "approaching" is a misleading exaggeration.  But not wrong in the mathematical sense: October 2019 is indeed approaching, as is January 19, 2038, the time in a few billion years when our sun will become a red giant, and the heat death of the universe.  Showing this message in August or September would be reasonable, today it is not.

"It is strongly recommended that you upgrade to a newer release within the next 2 months."
That is simply wrong.  Within the next two months, there will be no newer 11.X release; it only shows up in 2 months + a few days.

Someone who really cares should file a PR against that message, or volunteer to get it fixed.  I don't happen to care, since I know how to read the release schedules.


----------



## noodlefling (May 3, 2019)

I appreciate that they're continuing to keep the OS active and viable, but it does seem like we are running through major versions a lot faster than we used to.

Maybe I'm just getting older and time is dilating for me, but it seems to be more of a nuisance than it used to be.


----------



## Datapanic (May 4, 2019)

This is why I went back to 11.2 from 12.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231931


----------



## sidetone (May 4, 2019)

I have a concern now.

I need to reinstall FreeBSD. If I install 11.2, it will not be supported in a few months. I downloaded 12.0 for the cd, and it doesn't fit on one cd. I'll have to go with the boot cd, but those installs usually take longer, bc it needs to download as it goes. 

When I used to install OS'es from flash drives, the flash drives usually got data or data corruptions written on them during bootups if it crashed and I had to reboot, or if for another reason. I know this is not a problem for harddrives, but it is not common to install OS'es directly from them like this. The cd is read only, so the data doesn't change no matter what. For whatever reason, the flashdrive with the install needs to be reliable indefinitely.

If 12.0 has pkgbase, the cd medium shouldn't be that big.

The data being too much for the CD medium it is meant for is usually a problem for stable releases, prereleases, on DragonFlyBSD, and in this case for FreeBSD 12.

It seems like pkgbase can be used in the future for one continueless and maybe versionless quick rollout.


----------



## recluce (May 4, 2019)

Chris236 said:


> It shows the utter absurdity of the FreeBSD support model.
> 
> Somebody needs to look at the models of CentOS or Ubuntu....  we need support frames of 5-10 years for professional environments.



Ubuntu, really?

True, every 2 years there is a LTS version that receives _some_ support for five years. Many packages are not receiving support nearly that long. In any case, you pay by having a significantly outdated OS. Once the five years are over (or if you decide to upgrade earlier, due to outdated software), the version upgrade usually breaks things to a point that a fresh install is inevitable or at least a really good idea. I haven't had a single version upgrade of Ubuntu and its flavours that worked as expected.

By comparison, unless following -CURRENT, I have never had issues with any minor version update of FreeBSD. Even with major version updates, I can't think of any serious problem. One of my servers has now gone through every version from 9.3 to 11.2 (except 10.0 and 11.0) and no issues. On a more experimental desktop, I went from 10.1 through 11.x and 12-CURRENT to 12-STABLE. CURRENT caused issues with updates, as expected. Rock stable again since 12-STABLE.

So comparing Linux updates / upgrades with FreeBSD updates is comparing apples and oranges.


----------



## ralphbsz (May 5, 2019)

sidetone said:


> I need to reinstall FreeBSD. If I install 11.2, it will not be supported in a few months.


You could just install 11.2 right now, and then upgrade it in place to 12.X if you want.


> When I used to install OS'es from flash drives, the flash drives usually got data or data corruptions written on them during bootups if it crashed and I had to reboot, or if for another reason.


Strange.  While I've had USB or SD storage fail, it tends to be complete hardware failure (they become dead), not data corruption.  I see no logical reason why a USB drive that's mounted readonly should be corrupted during a boot up.



> I know this is not a problem for harddrives, but it is not common to install OS'es directly from them like this.


Actually, why not?  Buy a cheap external hard drives (I regularly see ~TB drives at Costco in the US for $60), and use it as your install media. Would that work?


----------



## neel (May 6, 2019)

recluce said:


> Ubuntu, really?
> 
> True, every 2 years there is a LTS version that receives _some_ support for five years. Many packages are not receiving support nearly that long. In any case, you pay by having a significantly outdated OS. Once the five years are over (or if you decide to upgrade earlier, due to outdated software), the version upgrade usually breaks things to a point that a fresh install is inevitable or at least a really good idea. I haven't had a single version upgrade of Ubuntu and its flavours that worked as expected.
> 
> ...



On top of that, I found FreeBSD (including CURRENT) to be more stable than Ubuntu LTS. I had my fair share of CURRENT breaking, but nowhere near the issues with Ubuntu. I had Ubuntu 16.04 on my "school" laptop (that I use for college) until it was unable to boot (the laptop ran Fedora for two months and now runs FreeBSD 11.2 but I probably should upgrade it to 12.0)..


----------



## kfv (May 6, 2019)

sidetone said:


> I need to reinstall FreeBSD. If I install 11.2, it will not be supported in a few months.


As ralphbsz mentioned, you can upgrade to 12.X whenever you please. But please note 11.2 is a minor release of 11 branch, meaning that you could stay on 11 as long as the branch is supported - which is 2021 for stable/11.
All you need to do is upgrading to newer minor releases, for instance to 11.3 when it's out, so not a big deal mate, you're safe on 11.



Chris236 said:


> It shows the utter absurdity of the FreeBSD support model.


It's called policy, not absurdity.



Chris236 said:


> Somebody needs to look at the models of CentOS or Ubuntu


Negative. You're comparing totally different things.



Chris236 said:


> we need support frames of 5-10 years for professional environments.


Five to ten years for the base OS? Could you please give us an example when one would need a ten years of support? I think it's better to invest on more important projects and I believe FreeBSD Foundation is doing a great job.
Do you know what the cost of supporting a base OS for a decade will be? Although I disagree with you on needing a support model like linux distros, I understand your concern, but as I said earlier, you're comparing totally different things and there's a lot to consider.


----------



## sidetone (May 6, 2019)

ralphbsz said:


> Actually, why not?  Buy a cheap external hard drives (I regularly see ~TB drives at Costco in the US for $60), and use it as your install media. Would that work?


Too much hassle. To put an iso image on a harddisk, that has more space than needed, then to get the bios to recognize the drive how the data wants to be recognized.

I'll just use the boot cd install.


----------



## Chris236 (May 23, 2019)

divinelvcifer said:


> Five to ten years for the base OS? Could you please give us an example when one would need a ten years of support?


Lets introduce some reality. All numbers below are optimistic.

0 months:  a new FreeBSD release is published.
to use it I need a type acceptance and engineering -> budget
budget is requested 6-12 months in advance.
+6 months: budget for testing and release engineering available for odering
+4 months: external consultant  is purchased and onboarded for project
+3 months consultant has designed and aligned test specification,
engineered an image prototype, created a test environment
+3 months consultant has completed first full test run, documented results, fine tuned system, implemented hardening according to company guidelines, implemented and tested management integration in test field.
+1 month  Acceptance tests. I get type acceptance and release documentation and image.
+0 at this point in time, application project that actually needs the OS falls fully engineered and ready for deployment from heavens. It also ran its engineering, tests and type acceptance concurrently to the OS and there was zero interdepenance time cost for both projects running in parallel. (Miracle #1)
+0 also at this point, 50 servers are deployed in 10 unmanned tech sites all across  the country, every single one fully and error-free connected to the network and with suitable remote control hardware configured and connected.  (Miracle #2)
+1 month all 50 servers have been installed and successfully brought online with OS and loaded with various parts of application software. Management, alarming, monitoring, and logging is configured and integrated in central systems. Provisioning is activated and tested.
+3 months application engineers integrate the app, make everything work together, do test runs, find and fix issues not found before
+1 month field acceptance: operations takes over, does backup and recovery tests, bare metal restore, component failover tests, full system failover tests, does final hardening, finalizes operational documentation. Declares ready for service.
+1 month Marketing determines launch date, announces new functionality etc.  System is launched in production.
All those numbers are optimistic. Some very much so.  Still, we have the first server in production about 2 years after the release was announced. Reality is sometimes it takes longer. Now we need that stuff to just work and earn money. The 50 servers are run by a 3-man Operations team that also runs another 5-10 or so other such applications. Typical life cycle for such a piece is 5-7 years, 10 - 15 is not unheard of.

Nobody has time for frequent updates here. If any, updates are centrally scripted and deployed at substantial cost.  freebsd-update is a pretty bad customer there, as it needs serious amounts of manual intervention for a full upgrade.  The reference is is Redhat Sattelite (or maybe even WSUS)

So, yes! We need 10 years support, at least for required security patches and a functioning ports and packages framework. And, as the Redhat example has shown, people are willing to pay for it.


----------



## shkhln (May 23, 2019)

Chris236 said:


> +3 months consultant has designed and aligned test specification,



I understand an OS release can't be tested before it has been released (obviously), but why would someone postpone _designing_ tests for that? What these tests actually do?


----------



## Phishfry (May 23, 2019)

Chris236 said:


> +4 months: external consultant is purchased and onboarded for project


4 plus months to hire a consultant and "onboard" them.
Is this top secret work with extensive background checking or something?
Typically external consultants charge like lawyers. 200 bucks an hour.
If your taking 4 months to onboard a consultant your company is going under real soon.


----------



## PMc (May 23, 2019)

Chris236 said:


> Lets introduce some reality. All numbers below are optimistic.
> 
> 0 months:  a new FreeBSD release is published.
> to use it I need a type acceptance and engineering -> budget
> budget is requested 6-12 months in advance.




Hah. That's not a defect in FreeBSD, that's a defect in ITIL! This must there be fixed!

[Comment written after half an hour of rolling on the floor laughing and not getting any breath.}

So, lets geht serious - has indeed nothing improved within 25 years??

Back in 1993, two of us figured that only we two of us alone could run a whole compute center a lot easier and more efficient than these 50+ regularly employed buerocrats.

Then, dotcom appeared, and I was busy travelling the world and teaching big industry how much better computing works when going away from host+minis and embracing client-server.

Then the dotcom hoax failed, and people were worried and decided that for our further benefit we must as quickly as possible get back to the situation where nothing gets done - and so ITIL was developed to achieve this goal.

And nowadays with a great laugh I recognize about the so-called "Agile" - and with an even greater laugh I recognize about so-called "DevOps" and "Continuous-Delivery" - because there I found much of the stuff which was just self-evident 25 years ago. (Albeit now it is only half understood and badly implemented.)


----------



## PMc (May 23, 2019)

Phishfry said:


> 4 plus months to hire a consultant and "onboard" them.
> Is this top secret work with extensive background checking or something?[



No no! This is Berlin Airport.


----------



## Phishfry (May 23, 2019)

The steps sound rational but the timeline sounds vastly inflated.


----------



## tommiie (May 23, 2019)

Chris236 said:


> +6 months: budget for testing and release engineering available for odering


You know in advance that a new release will come out, e.g. with Ubuntu you know exactly when the next LTS release comes out. You can ask for budgets in advance.



Chris236 said:


> +4 months: external consultant is purchased and onboarded for project


Your internal staff is not good enough to upgrade your server park? Anyway, you can also recruit an external consultant in advance.
That will save you 10 months.


----------



## sidetone (May 23, 2019)

I bet there will be a fork of FreeBSD, for those who want long term support.

If people are willing to pay to have 1 long term release, FreeBSD should listen to them, and look into it. It's important that FreeBSD maintain the community it has.

As a casual user, I can upgrade every year or so. It's difficult, but sometimes I need to do that anyway.

Installing for a desktop is a lot harder, and requires a lot of compiling time, that it can't be that much for a console system. There is less bloat, compile time and compile options to get in the way of console systems. Xorg is a lot to compile by itself, and there are so many graphical programs that pull in bloat and have so many requirements.

Most production and server environments are or should be console systems anyway, so the compiling, dependency troubleshooting and configuring time shouldn't be that high to begin with.

For my opinion, I'm in the middle. A lot of people who say they run servers and need a long term release, they say compiling is difficult. I don't understand that, because only compiling for the graphical environment is that difficult, and production server environments shouldn't be on a graphical display, unless it's a low resource graphical implementation like FreeNAS, or something larger like OpenBSD. I can see it, if they have multiple copies of programs in multiple jails, and have plenty of applications to juggle for their server, but still most non-graphical applications don't take over 4 hours to compile. Saving seed files save a lot of work, and is a must for me to prevent reinventing the wheel over and over, and wasting time, which any one who runs FreeBSD and especially a production environment should know. I don't know if they want others to do their jobs for them. I don't know if they are just asking, and don't return, but I know that FreeBSD or any organization must keep good patronages or customers. If those who say they use FreeBSD for their company services say they would pay for it, I would like to see how many put their money where their mouth is. If some pay for convenience, and are serious about it, then it would be a benefit to FreeBSD. A problem could be that FreeBSD would have to set up an infrastructure for it that could take away staff and momentum from FreeBSD's goals. It should be thought of, if that's worthwhile. I suspect that some who ask are serious, and some aren't.

I can also see it, if someone sets up a physical system in their customers' physical location, where they don't want to have to go back every year not to merely service it, but to reinstall it from scratch. FreeNAS or something similar would do a better job for that purpose.

I know many ask and appreciate, and contribute not only in financial form, but I wouldn't be surprised if some ask and don't appreciate anything.

* edited


----------



## zirias@ (May 24, 2019)

Sorry, I don't get that argumentation at all. What is the scenario?

Operations: If you don't have the expertise in-house to support your infrastructure, you're already doomed. You should opt for cloud hosting instead, it will be cheaper in the long run.
Software development: Are you kidding me? You're supposed to be agile. A new OS release doesn't appear from nowhere, there are development branches and later betas and release candidates, and after it is released, there's still plenty of support time for the older release -> go do your work in time.


----------



## PMc (May 24, 2019)

sidetone said:


> I bet there will be a fork of FreeBSD, for those who want long term support.
> 
> If people are willing to pay to have 1 long term release, FreeBSD should listen to them, and look into it.



No. The correct medical term for such behavour would be 'co-dependence'. (That is, when a partner behaves in a way to support the alcohol addiction -or other mental illness- of their mate.)
If these folks can afford to "purchase and onboard external consultant", then they can as well hire some lean-6-sigma- or what-the-heck-consultant who would help them get rid of useless organizational waste and streamline their operations.
Certainly, messies do not want to get rid of their waste - but then that is not the business of others to cater for.

Concerning the law of the market: if there were substantial demand for LTS, then there would be some company who would take that money. Seems not to be the case.


----------



## PMc (May 24, 2019)

sidetone said:


> I bet there will be a fork of FreeBSD, for those who want long term support.
> 
> If people are willing to pay to have 1 long term release, FreeBSD should listen to them, and look into it. It's important that FreeBSD maintain the community it has.
> 
> As a casual user, I can upgrade every year or so. It's difficult, but sometimes I need to do that anyway.



And as a company, you could do just what I did this winter: write an automatic deployment scheme. Took me less than a month and supports an arbitrary number of targets.



> For my opinion, I'm in the middle. A lot of people who say they run servers and need a long term release, they say compiling is difficult. I don't understand that,



Thats quite simple: for many (of the important) people in the business, if something cannot be maintained as a business-case pie chart on an iPad, then it is difficult. That is, because the GUI of iPad is the only thing computer they would touch. *veg*


----------



## recluce (May 24, 2019)

Chris236 said:


> Lets introduce some reality. All numbers below are optimistic.



Maybe your numbers are realistic, I know some organizations like that. They have one thing in common: they are incredibly inefficient (e.g. introducing Windows 7 around 2017). Unless we talk governments or monopolies, such organizations tend to fall victim to more agile and efficient competitors in the long run.


----------



## ralphbsz (May 24, 2019)

sidetone said:


> Installing for a desktop is a lot harder, and requires a lot of compiling time, .
> There is less bloat, compile time and compile options ...


What does compiling have to do with it?  You don't need to compile anything at all to install and update FreeBSD.  I have run FreeBSD and OpenBSD for many years now, over 3 major versions, and I have yet to compile any part of the base system.  Even optional software I install 99.9% of the time from precompiled packages.


----------



## sidetone (May 24, 2019)

PMc
I started to think about unwanted influence. That, do this for me, do that for me, for support, then it loose track of what it is, and end up with systemd.



ralphbsz said:


> What does compiling have to do with it?  You don't need to compile anything at all to install and update FreeBSD.  I have run FreeBSD and OpenBSD for many years now, over 3 major versions, and I have yet to compile any part of the base system.  Even optional software I install 99.9% of the time from precompiled packages.


Much is better compiled. But in the case of CLI or non-GUI servers, most dependencies don't take long, except the compiler, which I would rather use a package when there's s secure package available. Actually without a GUI, compiling is not even needed to get an optimal system, because it's already slim from bloat.

I see too much complaining from people saying, it takes too long to compile python, perl or something. To me, this kind of claim is silly, because these compile quickly. GUI stuff takes longer to compile and it brings in lots of unnecessary bloat, and most GUI stuff wouldn't even go on a graphical server anyway. I also wouldn't be surprised if these people say they would pay for long term support, but don't mean that.

As I said earlier, I didn't understand the complaints about ports that are easy to compile, when GUI, unless it's like FreeNAS, is usually inappropriate for a server. If their business model uses FreeBSD, then shouldn't they know how to install it themselves, and not need a graphical desktop for servers and their customers? There are logical arguments, but that one that recompiling takes too long for something that doesn't require a GUI or a complex GUI doesn't make any sense.


----------



## ralphbsz (May 24, 2019)

sidetone said:


> Much is better compiled.


Why?  What advantage does it have to compile it yourself?  I don't know any in advantage in practice.


----------



## malavon (May 24, 2019)

ralphbsz said:


> Why? What advantage does it have to compile it yourself? I don't know any in advantage in practice.


I know 2:
* CPU-specific optimizations (i.e. compile for a newer architecture than just the first amd64), a really minor advantage
* different port options than the default packages, which is the reason I do it


----------



## ralphbsz (May 24, 2019)

malavon said:


> CPU-specific optimizations (i.e. compile for a newer architecture than just the first amd64), a really minor advantage


The difference in performance is very minor, probably around 1-2%.  There are rare exceptions to that statement, namely software that does specialized operations (lots of vector floating point, memory-intensive operations like IO copying, math with unusual instruction patterns like Reed-Solomon coding).  For those, just recompiling tends to not help much either; instead the source code needs to explicitly test for what features the CPU supports, and switch to different algorithms depending on the hardware.



> different port options than the default packages, which is the reason I do it


I get that.  But at that point, you have to be aware that you are no longer running a tested and "supported" version (using a suitable definition of "support", which for FreeBSD mostly means this forum and the mailing lists).  For most users this is a strong disadvantage, but for experts the situation can be different.


----------



## malavon (May 24, 2019)

ralphbsz said:


> I get that. But at that point, you have to be aware that you are no longer running a tested and "supported" version (using a suitable definition of "support", which for FreeBSD mostly means this forum and the mailing lists). For most users this is a strong disadvantage, but for experts the situation can be different.


Well, not that I need support with most of it, but I kindly disagree with that. The point of the ports system is to be able to do this, that's why not all configure --enable-X options are converted into port options.
Only the parts that the maintainer deems relevant and is willing to/capable of maintaining get port options. Some examples of what I customize:

1. remove any support for Pulseaudio or ALSA. These options generally pull in things I don't want on my system because they've broken other ports in the past:
SDL2 by default switches to Pulseaudio when it's installed, even when it's not configured. That means basically no sound in SDL2 applications. (this was important for my UE4 port).

2. remove all documentation and help files (not man pages) by default, which I do to save some space. For 90% of the ports (i.e. transitive dependencies) I'll never read the documentation anyway.

3. set higher default versions for PHP, Python, Java etc to use with all ports. I've done this in the past to fix security issues or use newer features.

4. remove X support from my headless server packages and add daemons/web interfaces where applicable. e.g. for years I built subversion twice: with svnserve wrapper for server, without for desktop

#3 is the only one that I would expect issues with. Taking out certain things of a port shouldn't be an issue (unless it's used by another port of course). Adding e.g. video codes in VLC/FFMPEG etc
also doesn't warrant not "supporting" the ports either.


----------



## ralphbsz (May 24, 2019)

I really have no problem with you doing this ... but you are clearly in the expert category.  The few times I've had to build things from source were similar to the issues you raise.  Once one has gone to build things from source, with non-standard options, the support model changes, and becomes 1-on-1 discussions with developers or maintainers.
But that discussion is not really on point for a case that we were discussing in this thread, which is a user who wants to install a pre-cooked version of the OS distribution, and is arguing that support should be guaranteed for longer.


----------



## Deleted member 9563 (May 25, 2019)

ralphbsz said:


> Why?  What advantage does it have to compile it yourself? . . .
> 
> 
> 
> ...


----------



## Chris236 (Jun 5, 2019)

shkhln said:


> I understand an OS release can't be tested before it has been released (obviously), but why would someone postpone _designing_ tests for that? What these tests actually do?


Nobody postpones designing. It is just that nobody does it, either. In a nice case, there is a testing document from the last version, which you can mostly reuse.  But even if technically everything is identical, you still need to account for changed company regulations, changed security requirements, stuff like that. And once you have updated/written all the test specifications (test setup, detailed test cases) you need to have two or three review rounds with all stakeholders. And since two years have passed, some of them will be different from the previous project, putting different emphasis on certain things.
The tests themselves are fairly basic, Installation, backup/restore, network, throughput scenarios, security and hardening, the usual. 
FWIW, most of these 3 months is needed for image engineering, as we integrate the typical applications and produce an internal BSD install image that contains all relevant apps and settings and can double as bare metal recovery medium for the more dataless use cases. And, yes, this is currently moving towards other scenarios (more external automation), but that would only shift some of the customization work to instrumenting automation platforms for the new release.-


----------



## Chris236 (Jun 5, 2019)

Phishfry said:


> 4 plus months to hire a consultant and "onboard" them.
> Is this top secret work with extensive background checking or something?
> Typically external consultants charge like lawyers. 200 bucks an hour.
> If your taking 4 months to onboard a consultant your company is going under real soon.


No top secret work. Just a large international company.

Well, I have to calculate about 6 weeks from entering the purchase into the system until the order fax reaches the vendor.  Yes, when I joined the company in the late nineties, an engineer would send a special excel sheet to the nice lady from purchasing and they usually got it to the vendor within a week. That was in the late nineties. But since then there were several projects inbetween to "streamline the purchasing process", to save cost by "outsourcing" and "offshoring" and the result is that nowadays most engineering departments (including the one I work in) employ their own full time purchasing specialist just to enter orders into the system, and communicate with the whole purchase processing chain in four countries and three continents, and if everything runs very smoothly, it needs 2-3 weeks. But usually it takes longer.  I have seen cases where simple purchases took several months.
Since the cost savers have so badly ruined our relationship with vendors, no vendor starts doing anything before actually having that written order.  Once vendor has that order he usually needs 6-8 weeks time to allocate and schedule a consultant to work for us. Since we usually know in advance whom we want to work with, it might be faster. But equally often, it takes longer because the guy in question is not available outright. 
And two weeks for onboarding is not so much either.  Ordering accounts, getting an approved company laptop, allocating lab space, getting access cards. In theory, that can all be done beforehand, In practice, I'm happy if someone is up and running within a week.  Often that takes longer.


----------



## Chris236 (Jun 5, 2019)

tommiie said:


> You know in advance that a new release will come out, e.g. with Ubuntu you know exactly when the next LTS release comes out. You can ask for budgets in advance.


Well, with FreeBSD, you often don't exactly.



> Your internal staff is not good enough to upgrade your server park? Anyway, you can also recruit an external consultant in advance.
> That will save you 10 months.


Our operations team is quite good - but they are very busy with the things they already do.  No, they can not, as a rule, upgrade a few hundred servers every year or so on their own.  And even if they could, they would not be allowed - no QA, no upgrade.  Not to mention if they had time for that, management would likely downsize them.

Folks, walk in our shoes for a moment.  The world is neither the way you want it to be nor the way it is described in textbooks.  And I'm sure I'm not alone in this. Practically all big companies deal with some version of this reality.


----------



## Chris236 (Jun 5, 2019)

PMc said:


> [Comment written after half an hour of rolling on the floor laughing and not getting any breath.}
> 
> So, lets get serious - has indeed nothing improved within 25 years??



Nope. It got worse.


----------



## tommiie (Sep 16, 2019)

Today I got the message that 12.0-RELEASE-p10 is approaching end-of-life. I really hope they build in a check to see whether a new version exists or not. It is quite misleading that I am urged to upgrade within two months given there is nowhere to upgrade to.


----------



## SirDice (Sep 16, 2019)

tommiie said:


> I really hope they build in a check to see whether a new version exists or not.


It really doesn't matter. It's not like it suddenly stops working because it's end-of-life. The message is annoying but nothing more than that.


----------



## recluce (Sep 16, 2019)

Simply ignore the message, you will still have about three months after the 12.1 release to make the switch, no matter what the message says.


----------



## sidetone (Sep 16, 2019)

It seems like that's for minor updates within the same RELENG. from a p # to the next, but within the same 12.0. Maybe it applies largely to a buildworld or to `freebsd-update`.


----------

