Expectation of when 2.1 will exit Beta?
-
From a high level and certainly not looking for anyone to commit to anything, but:
Is there a consensus of when 2.1 is expected to be ready to become the production version? I'm talking SWAG-level confidence here, not project planning! ;D "This year, next year, sometime, never… " :P
Related follow up question: There don't appear to be any major pieces of functionality outstanding from 2.1, is that correct?
-
June this year actually, for world IPv6 day. So that kind of backfired.
there is 3 more months in this year, so a new Beta, then yes, RC, maybe, release, i don't know.
-
Cool, Thanks for the update AND thanks to all who put so much into this software! :)
-
There's still a LOT of work that needs done. AFAIK, the traffic shaper doesn't work with VLAN's yet (that's kinda a big deal for some of us). Lots of packages aren't IPv6 ready. It's getting there, but I'll be shocked if it exists beta this year, TBH - just as an interested observer. I hope it does :)
-
Not as soon as we'd like, but not that far into the future either. This year for sure. We're feature-complete, but have a number of outstanding issues to address.
Packages aren't going to hold up release, they never have and never will, and have no relation to the base system in general anyway. If maintainers don't add v6 support to their packages, they won't have it.
-
There are some important things that need addressing, but they don't affect everyone.
For instance, there is an issue with NanoBSD on certain CF cards that causes a slow read-write to read-only transition. This needs fixing, but it only affects a portion of the user base. So that would hold up a release, but others may use it without issue at the same time.
We could probably at least put out a "real" beta image (BETA1, announced, with a set of images for download) with a list of known issues.
We still have to get 2.0.2 out as well…
-
And while you mentioned 2.0.2, which mpd does it have, 5.5 or 5.6 ?
Thanks! -
[2.0.2-RELEASE][root@pfs202-amd64]/root(7): mpd4 -v Version 4.4.1 (root@base-8_1-amd64.builders.pfsense.org 21:23 6-Aug-2012) [2.0.2-RELEASE][root@pfs202-amd64]/root(8): mpd5 -v Version 5.6 (root@base-8_1-amd64.builders.pfsense.org 21:23 6-Aug-2012) -
There's still a LOT of work that needs done. AFAIK, the traffic shaper doesn't work with VLAN's yet (that's kinda a big deal for some of us).
This is a big deal for me and to maybe more than just a few….
Can anyone confirm it doesn't work on the latest nightlies?
Where can I see the ticket for this? -
nanobsd ro to rw to ro is main issue, i tried the same on 3 CF cards, one MLC and 2 SLC based CF cards and its very very slow making changes when the CF is almost 80% full
-
other things which i see need to be added is making upnp avoid feeding in rules which bypass limiters and this has been pending since a very long time now
-
Yes it is a big issue, it's not 100% related to the fullness of the drive but that could be partially to blame.
I have two cards here that are good examples:
1. Sandisk 4GB - freshly imaged, 4 seconds to switch at most
2. Kingston 4GB - freshly imaged, 30+ seconds to changeSo there are multiple factors at play there.
-
what i noticed was when drive was 45% full then it was quiet useable, once i installed freeradius2 to it, usage went 82% and then in captive portal i was adding pass through mac ids and each addition would take 45-60 seconds, then i removed freeradius2 and then tried and it became faster thats y i said about the fullness stuff
-
other things which i see need to be added is making upnp avoid feeding in rules which bypass limiters and this has been pending since a very long time now
I'm not sure that's something we will see fixed in 2.1. Not sure though. It may have to wait for 2.2.
-
what i noticed was when drive was 45% full then it was quiet useable, once i installed freeradius2 to it, usage went 82% and then in captive portal i was adding pass through mac ids and each addition would take 45-60 seconds, then i removed freeradius2 and then tried and it became faster thats y i said about the fullness stuff
Oh I don't doubt it - the filesystem code in question would likely behave that way. Though it may not be the fullness but the number of concurrent open files by FreeRADIUS. It's probably all part of the same issue there.
-
has this issue come up with the new freebsd version or is it pfsense related?
