On Thu, 31 May 2018 17:34:18 +0200, Joe Maloney <jmalo...@ixsystems.com>
wrote:
I personally wish that more drivers, and firmware were separated from
base.
For example wireless firmware:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
That was a ticket which I chimed in on about a firmware I needed to make
my
wireless adapter work. I went through numerous efforts on IRC, and
elsewhere to try to bring attention that ticket in order to attempt to
get
that firmware backported for several 10.x releases in a row without
success. The firmware worked perfectly fine in PC-BSD where it was
cherry
picked for numerous 10.x releases.
I would support an idea that the FreeBSD project only delivers CURRENT
(and one periodic release with security fixes) and parties like PC-BSD
maintain stable branches and support for companies.
I read about this somewhere a while ago and the idea sticks. Backporting
to code 2+ years old is not the best use of human volunteer resources IMHO.
Regards,
Ronald.
Technically since I was using PC-BSD, and was a committer for that
project
I had no real dire need to reach out to FreeBSD about the issue. I was
simply trying to help anyone else who might be encountering the same
issue
trying to use stock FreeBSD because it was a simple backport. If my
effort
had turned out to be more fruitful I would have spent more time pursuing
tickets, diffs, or whatever to get more things back-ported when I found
them. I am not sure where the breakdown was which did not allow that to
happen. Anyways I don't want to bikeshed, or anything but I just wanted
to
point out how I think having more drivers, and firmware in ports could be
helpful to enhance compatibility for end users.
Having a separate port for legacy drm could definitely make things easier
to providing installation options for end users, and automating the post
install action chosen in TrueOS, GhostBSD, and future derivative projects
tailored for the desktop use case. For example for TrueOS we boot the
installer in failsafe mode with either VESA, or SCFB depending on whether
or not BIOS, or EFI is booted. Then we could simply make a checkbox for
legacy intel, or skylake + to install the correct package then the module
path for either driver can more or less remain the same. Eventually with
something like devmatch maybe that can even be fully automatic.
Joe Maloney
On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen <deisc...@freebsd.org>
wrote:
On Thu, 31 May 2018, Konstantin Belousov wrote:
On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
We're not replacing anything. We are moving the older drm1 and drm2
from
kernel to ports to make it easier for the majority of the users to
load
the
correct driver without conflicts.
You do understand that you increase your maintainence load by this
move.
dev/drm and dev/drm2 use KPIs which cannot be kept stable even in
stable
branches, so you will need to chase these updates.
I agree. One argument previously made was that it's easier
to maintain in ports. One data point from me - I rarely
update my ports, I update my OS much more frequently. In
fact, some times my ports get so out of date I just
(take off and) nuke /usr/local (from orbit, it's the only
way to be sure).
Also, are we trying to solve a problem by moving drm[2] to
ports that won't be a problem when base is pkg'ized? If
drm[2] is a package unto itself, then you don't have this
problem of ports conflicting with it, at least not so
much. You can either not install the base drm[2] package
or deinstall it to make way for a conflicting port. Once
drm[2] is pkg rm'd, it's not going to be reinstalled
again when you update the base OS.
And don't we have the same problem with sendmail and a
few other base services?
--
DE
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
