DragonFly 4.8 has been updated to 4.8.1, bringing in a lot of small fixes. Improved Intel video support and the virtio_scsi driver will be of most interest, I think. The 4.8.1 tag commit has all the details. You can update the normal way, and if you need an install image, I’ve uploaded them and they should appear at your local mirror.
12 Replies to “DragonFly 4.8.1 released”
Comments are closed.
What’s dragonfly support policy?
Are particular releases ever LTS?
Are bug fixes ever backported to older versions?
Or do you basically just need to run whatever the latest release is to get bug fixes?
There’s a stable and a development branch. Stable gets bug fixes backported from development. Anything crazy goes on in development – that being said, DragonFly’s development version very rarely breaks.
Releases are roughly every 6 months. Backports are usually only from development to stable, though depending on timing, the release before the current stable will get fixes too – i.e. just after a release, or an additional bugfix release to capture any further updates that are on the branch but from after the last tag.
So – 4.9 is development right now. 4.8 is stable. Fixes found in 4.9 get brought back to 4.8, and occasional retaggings happen to make sure there’s a release that contains them, as in 4.8.1. Note that it’s just a ‘git tag’ operation, so you don’t have to wait for the 4.8.1 release to get the bugfixes; they are available on the next ‘git pull’ for that branch.
There’s been discussion of long-term branches before, and I like the idea, but adding another release branch is time-intensive; you have to have someone willing to do backports of operating system fixes, which historically has been difficult because of the major surgery DragonFly has had under the hood. Also, someone has to be willing to sit and patch all of dports to work with that older release too. That is very time consuming work.
Justin. Thanks for the reply
@Justin
So if I’m reading your comment correctly, essentially unless your on stable which has a new release ever 6 months – you won’t get updates.
Question: how is that even feasible for people to run production servers on if your having to up the OS ever 6 months just to stay on a release that will get bug fixes?
Francis – there hasn’t been anyone needing long term support for a specific release for periods of years to do that sort of backporting. Like I said, I’d like to see it, but it’s intensive in terms of time commitment, and it so far has been more work than anyone has committed to, vs. a system update.
It’s probably a chicken & egg problem.
No one wants to use dragonfly in production because of no LTS.
But no one is willing to devote time to supporting a LTS release, because no one is using dragonfly in production.
For what it’s worth, I’ve seen exactly nobody say “I want to use DragonFly but I need a long term support version to do it” in the last decade+. So there may be people for whom that is a need, but they are either very rare or not at all vocal.
@justin
Counter point: can you name any big companies running dragonfly ?
I see where you are going; that you want a long-term support release and that you think it’s necessary to get corporate buy-in on DragonFly as a product and that the reason I haven’t seen anyone ask for it is because there’s nobody in that use type that is running it.
That very well might be the case, but we can’t prove that need one way or another. It’s a moot point unless someone wants to devote the time to backporting fixes and supporting dports for an older release. The reason it doesn’t happen now is because of time needed, not because anyone is actively rejecting the idea.
Arguably, one creates the other – if a company is using an operating system (any system, not just DragonFly), the company has an incentive to support that system at the release that they need – which is where companies like Red Hat make a lot of cash, selling that support.
How these things usually (as in what I’ve seen, so very subjective) are adopted is like this:
* Project gains interest from developers.
* These developers work at a company, where it would solve a problem.
* They see the lack of LTS as a problem.
* Either the developer decides to invest the free time or the company pays the developer to do this – or they pay an existing developer to do so. So basically donations.
* Other developers and companies jump in every once in a while and work on making LTS easier.
The critical point there is someone starting LTS. It can be someone that simply wants to contribute and has interest or experience with release engineering or it’s someone having a pressing enough need.
However, regardless of all of this there is many companies, yes, even enterprise class ones that don’t need LTS. A famous FreeBSD user, Netflix actually uses (or used) CURRENT. I think they are not the only ones.
The real need for LTS tends to come from people that don’t contribute so much back. This isn’t meant to be negative. It’s just that someone making the decision on using an OS that is not hugely popular usually is someone with enough technical expertise and the means to make such a decision, convince people, etc. So in that case – again if the current release cycle isn’t enough – it’s rather likely that the reason to use a certain OS outweighs the cost of basically doing release engineering on your own. And sometimes some form of release engineering starts in-house and the decision to make it part of a project/public is to lower the cost, since other developers and the project usually are grateful and work in support of it.
But again, that’s just my personal perception and I am very certain that there are different ways.
LTS early usually only comes from project big with financial interests that say something like “We want people to buy our OS and use it in classical enterprises, so we have to have someone working on Release Engineering”.
Or there is some Foundation, but in that case the founders of such a foundation have that very interest.
See also RedHat. They did the same thing with Linux. Linux fans made the whole stable release engineering thing a business. Debian did something similar, with the non-business approach.
Of course that doesn’t mean everyone contributes back a lot either. There might be hidden users.
But if there is no company behind it, using an open source project really is a very hands-on thing. People sometimes forget that. Just like they sometimes overestimate the cost of doing things, thinking that it would have been done, if it was easy. However, people have only so much time. They are not going to invest it just because someone else says “it would be cool if…”, unless they feel the same.