From owner-freebsd-x11@freebsd.org Sat Dec 31 23:41:56 2016 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AA1CC99FF7 for ; Sat, 31 Dec 2016 23:41:56 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CDAC81F13 for ; Sat, 31 Dec 2016 23:41:55 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1483227706982797.3095603885415; Sat, 31 Dec 2016 15:41:46 -0800 (PST) Date: Sat, 31 Dec 2016 15:41:46 -0800 From: Matthew Macy To: "Beeblebrox" Cc: "O. Hartmann" , "freebsd-x11@freebsd.org" 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> Subject: Re: End of year Xorg status rant MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 23:41:56 -0000 > > 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