Re: Ars Technica article
Chris <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.x11 |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 13 Apr 2020 10:49:52 +0000 Grzegorz Junka [email protected] 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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to "[email protected]"