11.2-RELEASE-p9 End-of-Life

  • +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.
 
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.)
 
+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.

+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.
 
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
 
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.
 
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.
 
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*
 
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.
 
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.
 
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.

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.
 
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
 
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.
 
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.
 
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.
 
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.-
 
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.
 
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.
 
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.
 
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.
 
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.
 
Back
Top