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