Ars Technica article
Chris
bsd-lists at BSDforge.com
Mon Apr 13 21:45:30 UTC 2020
On Mon, 13 Apr 2020 10:49:52 +0000 Grzegorz Junka list1 at gjunka.com said
> > OK I've bit my tongue as long as I can on this...
> > How is importing yet more Linux code into FreeBSD a better thing? Or how
> > is it *fixing* anything regarding FreeBSD. For clarity; I don't dislike
> > Linux. I just prefer to use (Free)BSD. I'm frankly alarmed with the
> > apparent
> > volume that Linux code is entering the FreeBSD code base. I noticed
> > much of
> > the UEFI bits are also converted Linux bits. I suppose for a quick needed
> > stop-gap solution it might be reasonable. But it appears that a
> > tremendous
> > amount of time, and effort has gone into all this, and given the
> > previously
> > mentioned lack of man-power. It seems unlikely that any of this will be
> > replaced with a FreeBSD equivalent. I'm not blowing smoke here. I
> > earmarked
> > some time that I wouldn't be taking contracts so that I could invest some
> > time on FreeBSD concerning "nits" I had that I thought could improve
> > things
> > a bit. I looked into taking the time to make it nearly/fully POSIX
> > complaint.
> > Browsing the code. It was clear I wouldn't stand a chance unless I
> > started
> > at ~9.x where it starts to go sideways in fairly rapid succession. So I
> > decided to look elsewhere. I've had some nits with the Graphics dept. so
> > I thought I'd look to see where I could best spend my efforts. Then
> > the new
> > Xorg landed. Well that's going a *completely* different direction than it
> > was, and I don't think I want to participate in that new direction.
> > I've finally landed on working on bolstering sc/syscons in an effort to
> > provide graphics mode switching and detection to it.
> >
>
> Thankfully, Linux code can't enter FreeBSD base because of different
> licensing.
>
> I hope you don't advocate for re-implementing drivers for FreeBSD? What
> about NVidia drivers that aren't even distributed with source code?
> Surely, they provide binary packages for FreeBSD, but without support
> for Vulkan for example. Without any documentation of the hardware ports
> how this could be even achieved?
>
> Besides, I am happy when I see a vendor or developer supports Linux,
> apart from the usual Windows or Mac, not even mentioning FreeBSD. Many
> don't even differentiate beyond Linux, listing support for FreeBSD under
> Linux and other distro sections!
>
> I think we need to be pragmatic about it. Neither AMD nor NVidia will
> provide FreeBSD drivers and FreeBSD can't implement those drivers,
> either for objective reasons (man power) or because it's not feasible
> (NVidia). If we can reuse existing drivers that the manufacturers are
> releasing and updating frequently, and only focus on the compatibility
> layer, then why not?
Agreed. The challenges are many. How? How have we managed so far? Yes.
We've been (seemingly) forced to import video blobs for some (G|A)PUs. But
what of the others? What of the French driver project; Nouveau? How have
they managed? Granted it *too* is Linux based. But they got there *somehow*.
Would it be a worthy venture to start a project like that that either
imports && recobbles that project into "native" code? Or? I've been at this
for over 50yrs, and I've amassed more hardware than you could imagine. Need
to get FreeBSD on a Mac SE dsdd? NP. a PDP? Oh wait, that was done l-o-n-g
ago. But I've got several models available -- just in case.
I'm serious. I'm willing to participate in whatever capacity I can. But
IMHO importing Linux stuff isn't really "keeping ahead of the curve".
>
> --GrzegorzJ
>
>
--Chris
--
UNIX is like Ice Cream. It comes in several flavors.
But in the end, it's still Ice Cream.
More information about the freebsd-x11
mailing list