Solved Did anybody else notice that FreeBSD 12 only has an 18-month lifespan?

[scottro]

Heh, I miss Oko, he would constantly point out how FreeBSD devs used Mac but OpenBSD used their own. (Though, I guess none had a laptop like mine or they wouldn't have changed the usual startx to xenodm, but I may be the only one complaining. ) But as you see lots of folks use it. I do,for example, as a workstation so that I might be prepared for update X when we use it on our servers.

 

[Nasrudin]

I see you complained about having to fix a problem every time you installed FreeBSD, then said certain mailing lists were closed. Why wouldn't you use the regular mailing lists that are open to users. They usually address things. Bug reports are also open for reporting such things.

Open source communities don't need stuck up attitudes, that you think people should drop what they're doing on your whim.

In my opinion, this debate is ageless and this is because it has no resolution.

On one hand, there are plenty of examples of serious questions, issues, and problems that go unanswered for years. FreeBSD "management" (for lack of a better term) tends to be needlessly opaque with respect to decisions and data that affect users and is often declarative rather than communicative. Political issues, as in most human endeavors, sometimes win out over technical ones, even in FreeBSD land. To attempt to assert "you get what you pay for" or "we dont need stuck up attitudes" in response to any user's frustration with these issues will ultimately result in dishonor ... even if it is indirectly. People who use FreeBSD will always need developer support, regardless of your opinions about whether they should demand it. No one knows it all and even experts need help occasionally.

On the other hand, open source is free and so is the compensation for maintaining it. Many geeks have financial lives and cannot drop paying work for non-paying work, contrary to the assumed expectations of some people. It is specious to presume that anyone is owed any support at all. Sometimes "fixing it correctly" means 10 times the work it is to "patch it so users will be quiet". Developers doing work for free (or even the ones getting compensation for working on FreeBSD) need freedom to work. That's how you get high quality software. Alienating developers isn't good for any ecosystem, and you'll almost certainly alienate developers you demand work or policy changes form.

These are two sides of an eternal argument. No one is more right or wrong than anyone else on either side. What we really need is understanding and cooperation on both sides. It would be good for developers to stop being annoyed by users, and users to stop being annoyed by developers. I wish that could happen universally, but that's a post on a different board.

For example, I completely agree that FreeBSD OS versions should have a longer support cycle. However, FreeBSD "management" has generally not listened to any argument along these lines that I have seen. So...I could make some long post about it, but why? Their unwillingness to listen is on them, not me. Instead of berating them (even if I somehow determine they "need" it) or asking politely (a difference in presentation but not usually in effect), I spend those cycles supporting myself and my clients instead. I don' t generally bother devs, in the spirit of cooperation. I do file bug reports, in that same spirit. I haven't yet found anything I couldn't (eventually) work around in FreeBSD despite my warranted or unwarranted annoyance at some faceless dev who unknowingly broke something I have to fix.

If you consider any of the alternatives, they aren't much different in the basic ideas outlined above. Using proprietary software generally means you have -less- say on subjects like support cycles than you do here and you are much more forced to do things (upgrade OSes, adopt technologies you don't want, etc). At least with open source, if you have to, you can fork or patch. The other thing open source gives you is the license and/or forum to express your opinion and the chance to be heard by those people that matter. I would humbly suggest people use that with care.

Please remember that software (especially these days) is not simple and not easy.

Thanks for reading.

 

[sidetone]

There is a potential case for NGO's or non-profits needing a longer lifespan. Their operations can be helped by FreeBSD, but profit to them is limited.

 

[mark_j]

This all come down of who (the professional quality) is using the OS. Netflix run -CURRENT into production.

Right, so it's called NetflixBSD now? Maybe the foundation should re-read its charter?

 

[Terry_Kennedy]

The issue in my original post was specific to an issue with the planned lifecycle of FreeBSD 12, and the issue has been solved. Therefore I've marked the post "Solved" and I request that if you want to discuss the more general issue of FreeBSD's management, that you do so in a new topic with a relevant title that will expose it to more people than my narrow FreeBSD 12 question. Thanks!

 

[chrcol]

To add a voice here - I've been running FreeBSD on my servers since the mid 90s. There are a variety of reasons for electing to do this over alternative OS options, options that have come and gone, but one of the primary drivers has been stability. Over the decades I've watched enthusiastic developers embrace the latest model/language/process of the month as if it were the future of computing and then quietly flame out. All the while FreeBSD has incrementally improved, become more stable, more useful. I am tremendously appreciative of that. A critical, perhaps the critical, characteristic of FreeBSD that differentiates it is solid, stable, secure performance.

I find Terry_Kennedy's concerns resonate with me. If there weren't security flaws, I'd probably never update. I don't run FreeBSD as an experiment or a hobby, but as a tool to get something done. And while I appreciate the "you get what you pay for" argument dismisses any claims of "rights," it also is extremely dismissive of the commitment of particpatory users. While I'm not suggesting this is actually the core attitude, it comes across as "this is our toy, not yours" and risks alienating users who are peripheral contributors to the FreeBSD ecosystem.

A big part of this contribution is discovering and sometimes fixing subtle flaws or feature omissions, a process that takes years and the use and attention of large numbers of not completely inexpert users who are willing to make the effort to work toward resolution and improvement. I do not see how alienating those users is to the benefit of the project.

I fully appreciate structural changes that have the effect of improving support and reducing any unnecessary overhead for the hard-working developers that make the project successful, but there is a legitimate need for extended support for use cases that have historically been central to FreeBSD's mission. I suggest that need be taken seriously, not dismissed as "what do you want for free," and weighed in the determination of resource allocation to provide appropriate support periods some very dedicated users need.

This is an outstanding post that deserves more than just a like.

I like yourself am a very long time user of FreeBSD, I have on many occasions been pressured either by employers or colleagues to move machines to Linux, because of various flaws, a lot of these flaws stemming from decisions been made (policy) rather than the code itself.

I have ridden that out, but I am increasingly getting more and more concerned, I already dislike the new minor release EOL policy, for me the base of the OS should be a relatively stable platform, and its the ports (packages) on top of that which should be what's updated frequently, actual security issues that 'need' patching in base are fairly infrequent. The problem is there is now an enforced policy of making people update the base frequently, no more extended minor releases, and if you decide to keep base outdated then you will probably end up unable to use the ports tree, and its the ports tree that is important. So effectively the ports tree is been used as a means to make people comply with a more rapid update schedule.

On the subject of not wanting to support 3 or 4 major branch's of FreeBSD at the same time there was another solution, simply release less often. Most minor updates actually update very little, they do silly trivial things like a minor update to openssl or base ssh. There is of course many intermediate patches fixing bugs, which leads to another problem, that when I first started using FreeBSD it was best practice to follow RELEASE+patch branch. Now its best to follow STABLE because the vast majority of bug fixes never make it to RELEASE+patch. So the biggest benefit aside from been able to keep using the ports tree on updating to a new minor release from a previous one is getting all these undocumented bug fixes. I say undocumented because they never in the release notes. Documentation is a problem as well, today I am considering whether to update a now outdated 11.2 based STABLE server to 12.x or move to 11.3. Trying to find a list of detailed changes in 12.x led to me stumbling across this thread, a guy used to maintain detailed lists of changes but ended up giving up and the official developers still will not document changes other than silly things like "package" is now X version. I know there is a lot more changes than what's on the release simply by examining the GENERIC kernel, lots of new things in there that have no documentation. Which brings me on to my next point.

Something the developers don't understand or maybe they do but just don't care, is what people managing machines have to do when making decisions on updating. In some cases the process of updating a machine is month's of work, involving planning, assessing code changes, compatibility, compliance with company policy and affects on software been run on the machine. A developer who perhaps updates their base daily, perhaps thinks its just a few commands and bam you updated, the real world isn't that simple. My first reaction when I read the first post of this thread (before reading they backtracked), was that's it I am done with FreeBSD, and this is a promise if any developers are reading this, if you think a 18 month support lifetime for a major release is suitable, for me you wrong, I will be done with the OS.

I think your comment about developers jumping on a new thing like its an exciting toy is bang on the money, we used to see no changes to compiler version during a major branch, now it does change. Port's used to wait until EOL upstream before updating, now they tend to move the moment a new version is announced. We used to see multiple branches of ports allowing freedom for sys admin to choose, now this is massively stripped down.

Ultimately over the years what essentially has happened is this. The developers at one point catered the OS and the ports system for the users, thy acted like they work for the users. Now its more like they work for themselves and their employees only, the OS is designed around that (shorter support lifetimes, rapid releases etc.) and its a case of if you don't like it move on. Now to be fair this new developer attitude applies to many projects now, its most definitely not an exclusive thing to FreeBSD, I even have developers who I pay money to even flat out tell me, they are in charge of what's been developed not me the bill payer. I never had developers acting like that 10 years ago. It is what it is tho the old days are not coming back, the best we can hope is they show some remorse and back down on some things so it becomes more bearable again. Not everyone wants to be on cutting edge untested code.

 

[shkhln]

simply release less often

That's a good way to keep developers engaged.

 

[PMc]

This is an outstanding post that deserves more than just a like.

I like yourself am a very long time user of FreeBSD, I have on many occasions been pressured either by employers or colleagues to move machines to Linux, because of various flaws, a lot of these flaws stemming from decisions been made (policy) rather than the code itself.

Sorry, but now You mix up to things which are very different.

The posting You have quoted talks about the "you get what you pay for" as being dismissive to 'peripherial contributors'. That is a psychological consideration. Anyway, I am exactly one of these 'peripherial contributors' - I'm running FreeBSD since Rel. 2.1.0 because it is just damned good, fullstop.

Now what You bring up here is a business concern. Business is about companies, and, according to business science, the only reason for companies to even exist is, to make money. So, "you get what you pay for" is the correct stance in that regard, as it talks the only language that is spoken.

The psychological consideration from above is something entirely different: it talks about people and their feelings. There is a rather new current in the western world, that each and every thing gets considered that it might be somehow offensive to whomever, that it might hurt somebodies feelings, or whatever else. This is bad enough, it's a nuisance and a plague and I basically ignore such approaches.

But when it comes to evil, that is, when that new hysterical attitide gets exploited in a place where the actual concerns are business concerns, which, as we just learned, are only about money and don't care about people's feeling (unless it is for their own profit).

Most likely You didn't construct that line of argueing consciously - it is one of the evil habits that have become trendy. But anyway, i think it very important to keep these things sorted out.

when I first started using FreeBSD it was best practice to follow RELEASE+patch branch. Now its best to follow STABLE because the vast majority of bug fixes never make it to RELEASE+patch.

That is another matter, and the reason is that people are totally focused on tjhe "security" issue. And if it weren't about "security", people could run any version for as long as they like, disregarding official support schemes.
So, "security" gathers all the avaliable attention, and the other things go unnoticed. There is not only fixes that do not appear in the RELEASE tree, there is more things that never get fixed, there is features documented in the manpages which were never implemented, etc. Whenever I have a close look into the source, I wish I were in command of the dwarfs army of ancient Moria to have them tidyup all these things...

I even have developers who I pay money to even flat out tell me, they are in charge of what's been developed not me the bill payer

Oh, welcome to the new Agile socialism. *veg*
The famous psychologist Adler wrote already a hundred years ago about the psychological defects of a former factory owner who was not happy about being disposessed and put to the assembly line by the socialists. It's not a new attitide.

 

[tingo]

You can't have both progress (new things, new versions, new standards) and that everything stays familiar, unchanging at the same time.
So either you come along (grumbling, even) into the future, or you stay separated, alone with your old, outdated systems (hey, I collect vintage computers, I know a litte bit about running old operating systems in today's world). As was said earlier in this thread: the old days are not coming back. Nope, never gonna happen.

 

[CraigHB]

Things do need to move forward, but over the years I've noticed release cycles have compressed in the whole of the software industry. It does make things harder to manage as a user. I think it serves the developers more so than the users.

To make their job easier developers want all their users on the latest release of a product, but that means more trouble for the users. I'd love to have all the hours back I've lost on problems introduced by product updates. More and more products are forcing updates. I strongly dislike that trend myself. Either they think their work is without fault or they just don't care about causing grief for their users.

In general it seems consumers have lost rank in industry. Products are catering more to the producer with less consideration for the user. Quality, product support, and documentation have been on the decline for some time now. These trends have been continually eroding standards and consumer expectations.

 

[tingo]

The "compressed release cycles" is not limited to the software industry, or any industry at all. It is a "feature" of the way we (humans) run our society today; we have access to information from all over the world 24/7 (ok, almost all the world), and as a result we want everything else to happen at the same speed too (example: order something on the internet, and complain (internally or externally) that it takes several days / weeks to show up). IMHO, once internet access became pervasive this was inevitable.

You can't force the society to change; you can only change yourself. Don't let yourself be run by external events or tools; make sure that you run the tools.

Consumers don't have a rank at all; they exist solely to consume whatever the industry produces. This hasn't changed at all.
Customers and potential customer on the other hand can "vote with their wallet"; choose to buy or not. They can also make their voice heard in other ways.

Unfortunately, that doesn't solve the "compressed release cycle" problem.

 

[chrcol]

Things do need to move forward, but over the years I've noticed release cycles have compressed in the whole of the software industry. It does make things harder to manage as a user. I think it serves the developers more so than the users.

To make their job easier developers want all their users on the latest release of a product, but that means more trouble for the users. I'd love to have all the hours back I've lost on problems introduced by product updates. More and more products are forcing updates. I strongly dislike that trend myself. Either they think their work is without fault or they just don't care about causing grief for their users.

In general it seems consumers have lost rank in industry. Products are catering more to the producer with less consideration for the user. Quality, product support, and documentation have been on the decline for some time now. These trends have been continually eroding standards and consumer expectations.

Exactly, I think it is a developer thing, I have even developed my own stuff, and I will hold my hand up to state its easier if you only maintaining one code which typically is the latest code, its a conflict of interests of which the developers have won out on because now in the current software industry the developers are very powerful, I witness developers even telling their own employers what to do.

As you said its not just about release cycles either, its about the features of the product and how those features work, its something that used to be dictated by the end user and now is typically dictated by the developer. Its a very alarming trend that people who have been using software for at least a couple of decades have noticed.

Interestingly I am also seeing bizarre things like this.

tcptrace in the ports tree had a maintainer update on the 9 october, then apparently on the 16 october it was unamaintable and unfetchable so deleted from the ports tree, I think they have some kind of automated system purging many useful tools. Simply because simple updates are not been done to update download url's. Untar was also deleted, so now FreeBSD has no tcptrace and no untar lol.

 

[sidetone]

It's in the best interest of developers to simply things, so they wouldn't have to repeat updates and maintain different versions of LLVM for example. Also, to have 3 different versions of LLVM required, plus their compile times.

 

[LakeCowabunga]

Wrong. I have it on good authority from a Parallels customer, that any software, especially if purchased, should work and be supported for the lifetime of the user, without having to upgrade. (Oh, and to continue to work, even through voluntary OS upgrades.)

 

[CraigHB]

"Should" is the operative word, rarely the case. I do have some very old software I still use, but every time I update software required to support it I half expect it to quit working. I expect it will stop working eventually.

It's always a battle for me to keep "everything" working through software updates. No other appliance is like that. If I buy a refrigerator I expect it will work for as long as the mechanicals hold up and barring premature failures it won't give my any trouble until then.

From a personal standpoint computers require constant upkeep and updates continually create new issues to deal with. I've been able to deal with them and resolve problems, but it's time I feel is stolen from me. I really don't know how the average person puts up with this, maybe they don't care, I don't know.

I feel like the producers of software could not care less how much of my time they consume. Having a wife that suffers some chronic health issues I feel the same way about health care and have the same complaint. To me it's a lack of consideration for the consumer that just keeps getting worse over time.

 

[SirDice]

tcptrace in the ports tree had a maintainer update on the 9 october,

Not a maintainer update. The port didn't have a maintainer. The update on the 9th was a removal of a defunct category and was done on every port that had it. It was marked as BROKEN on the 5th of August.

then apparently on the 16 october it was unamaintable and unfetchable so deleted from the ports tree,

No. It was never maintained in the first place. And it was marked as BROKEN on 5 August 2019, probably because it had been throwing unfetchable errors for some time. Which means it got removed several months after it broke and there was plenty of time for anyone to step up and submit a patch. Nobody did, so it got removed.

I think they have some kind of automated system purging many useful tools.

Yes, build errors, fetch errors, any errors are automatically mailed to the maintainer. Which this port didn't have. There are also several tools running checking everything. Those tools don't care if it's a "useful" tool or not (how could it possibly know?). It's a port, it has errors. That's it.

Simply because simple updates are not been done to update download url's.

That is the maintainer's responsibility. Again, this port didn't have a maintainer. If it was something simple why didn't you submit a patch on, lets say, 6 August? You do know anyone can submit patches? Even for ports that do have a maintainer (maintainer does need to approve it before it can be applied).

Untar was also deleted,

Similar story, no maintainer (never did), marked as broken on 3 Aug., marked as deprecated on 15 Sept. and eventually removed on 21 Oct.


And perhaps I'm stating the obvious here but the support schedule is for the base OS only.

 

[Oclair]

upgrading 12.0 to 12.1 is really no big deal
keep your system up to date!

 

[PMc]

Exactly, I think it is a developer thing, I have even developed my own stuff, and I will hold my hand up to state its easier if you only maintaining one code which typically is the latest code, its a conflict of interests of which the developers have won out on because now in the current software industry the developers are very powerful, I witness developers even telling their own employers what to do.

As you said its not just about release cycles either, its about the features of the product and how those features work, its something that used to be dictated by the end user and now is typically dictated by the developer. Its a very alarming trend that people who have been using software for at least a couple of decades have noticed.

If you occasionally stumbled over some of my rather cynical comments on the so-called "agile" culture, well, that's quite what there is about it.

I don't even know what these "developers" are supposed to be. I only notice that there is a strong emphasis nowadays to distinguish between them "developers" and the mere NPCs (aka "users"). I don't like that.

In the old time, I think there were no "developers" at all. There were coders, and there were engineers. The coders were very competent in handling their programming languages, they did produce the working code. And the engineers were those who made it run, that is, care about all the integration issues: compatibility, networking schemes, backup&recovery schemes, performance, security, ... all the systems-management stuff. The guys who had solid grounds on the broad scale, from down at the hardware to up at the planetary network, and were able to do educated guesses on what they didn't know.

But now we have these "developers" who do not want to be called coders, but do not have solid systems-management skills either. And for everything else we have so-called "architects", who usually know a lot about business plans and ITIL, but also not much about integration.
And, due to the general rise of IT, we have quite a lot of them "developers" - enough to make an impact and dictate the rules (mainly concerning what they don't want to care about, that is, everything else than some "container" running on some linux in some cloud).
I think the reason is that younger people are coming into the business, and they grew up with smartphones; they were no longer forced to grab a soldering iron to build the computers the wanted to use, and so they are lacking the practical experience with the solid roots of the trade, but take it for granted that the machines work and they can do what they want - to be discerned only from the NPCs who cannot do what they want.

 

[PMc]

That is the maintainer's responsibility. Again, this port didn't have a maintainer. If it was something simple why didn't you submit a patch on, lets say, 6 August? You do know anyone can submit patches?

I doubt that. (I used to type sendbug to submit a patch. That doen't work anymore, and when I checked what had happened, I was asked for a password.)
But even it it is true, then, well, anybody can submit patches - but there is no notion about what happens afterwards - if anything at all.

I happen to run into malfunctioning ports. (Recently I came across a port that does build, that does install - and then the only function appears to be printing a message that FreeBSD is not a supported OS. So much about integration, eh.)

Certainly, I create patch for such. Because, obviousely, I need the port functioning (otherwise I wouldn't look into it). And if I had a blog here, I would post them on that blog. (It doesn't seem to be so very welcome to post patches in the forum; it seems rather intended for Q&A.)