Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 Dec 2016 15:41:46 -0800
From:      Matthew Macy <mmacy@nextbsd.org>
To:        "Beeblebrox" <zaphod@berentweb.com>
Cc:        "O. Hartmann" <ohartmann@walstatt.org>,  "freebsd-x11@freebsd.org" <freebsd-x11@freebsd.org>
Subject:   Re: End of year Xorg status rant
Message-ID:  <1595742b65f.1050eb06862309.1096856657498598610@nextbsd.org>
In-Reply-To: <20161231145143.18e6ac99@rsbsd.rsb>
References:  <20161230163653.54909631@rsbsd.rsb> <15952279f17.e0be0d8c34357.732964216134709731@nextbsd.org> <20161231120453.13adf858@thor.walstatt.dynvpn.de> <20161231145143.18e6ac99@rsbsd.rsb>

next in thread | previous in thread | raw e-mail | index | archive | help

 > > I think we face a political problem, not so much a man-power-driven on=
e=20
 > I'm sure the Foundation and developers have been debating whether to dro=
p desktop all together and only focus on server-side, which I would have no=
 problem with and would just migrate to some other OS. The problem as you s=
tated is that this half-assed approach is not working. Put simply, the choi=
ces are:=20
 > A. Drop all Xorg related ports, kernel modules and move on or=20
 > B. Seriously go after creating a decent (I don't need fantastic) desktop=
 experience=20
 > =20
 > We all know what option A would mean for the future of FreeBSD, but not =
my call.=20
 > If all else fails, I'm afraid I must agree with:=20
 > > Time to change paradigm, time to change OS ...=20

At this time, if you need either a) easy interoperability between ports and=
 Fortran (I say easy because I know people doing it) or b) GPGPU compute, t=
hen yes you really have no choice. I myself run Ubuntu only because of CUDA=
 and Nvidia. I've undertaken this work so that I can do GPGPU using Radeon =
Open Compute. Whether or not AMD will actually deliver, or if they do be ab=
le to successfully continue to support it the way Nvidia has is another que=
stion entirely. If at all possible I would like to do my AI/ML work on Free=
BSD. But I'm well aware that predicating anything on the success of AMD is =
very speculative.

 At least on the kernel side - "politics" is a cop out for people who don't=
 have the time/energy/ability to step up to the plate and do the work. Drag=
onfly and OpenBSD have proven this in spades. If lots of capable people sho=
wed up tomorrow to maintain the KMS drivers we could easily track Linux. Pr=
eviously there was a very very deep *technical* problem in that the increme=
ntal amount of work required to update was insurmountable. Now that the dif=
f with upstream has been reduced from 12,000-15,000+ lines below 300-400 li=
nes the "activation energy" to update has been reduced by a factor of 5-10x=
. Nonetheless, it is still several days of work by someone knowledgeable to=
 replay the DRM and driver updates and extend the linuxkpi as needed. To da=
te I have only done it for i915 because the costs were partly offset and be=
cause I see dogfooding by developers as critical to the long term health of=
 FreeBSD. It is not work I enjoy and I no longer have the time for what amo=
unts to onerous charity work. I will continue to do it for drm/amdgpu, but =
i915 is too much extra work (at least two thirds of the time for updating t=
o 4.9 was taken up by it). I have someone else lined up to do it provided h=
is work situation permits. On the ports side, there is a sociopolitical com=
ponent. There are people contributing patches that sit idly in Bugzilla ind=
efinitely. The amount of work to remain current exceeds what Koop has the t=
ime and energy for. That is why I have predicated any future bug fixing of =
i915 on having a couple of  active contributors be sponsored for a ports bi=
t. There *are* people at that level willing to do the work whose hands are =
tied by limited ports committer bandwidth. And I'm unwilling to make any fu=
rther sacrifices to make KMS work if I have to maintain a separate ports re=
po myself that may or may not ever make it in to the main package builder r=
epo.

TL;DR - Things are getting better. KMS needs continued extra help. It will =
never work as smoothly as Ubuntu.


 > Matthew:=20
 > Thanks for the info.=20
 > > .. the great work you've done as the major comitter to this project=20
 > First off, personal thanks even if I don't benefit from it directly.=20
 > =20
 > > If you care about Radeon I would welcome contributions to its upkeep.=
=20
 > > Unfortunately, the intersection set between people who care about=20
 > > radeonkms and those attending to its upkeep is currently empty.=20
 > I'll take a look, but I just don't have the coding experience/knowledge.=
 I'd have to travel pretty far to get to the point where my contributions w=
ould be productive for either side :((=20
=20

The offer stands. Once things were to reach  a "known good point" even with=
out much technical skill an individual can help greatly by simply bisecting=
 regressions. And really, one learns best by doing.

-M








Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1595742b65f.1050eb06862309.1096856657498598610>