Date: Thu, 28 Feb 2019 18:35:14 -0600 From: Doug Kirk <dbkirk@gmail.com> To: sgk@troutmask.apl.washington.edu Cc: FreeBSD X11 mailing list <freebsd-x11@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: DRM removal soon Message-ID: <CAGhTqAVmrRedSpRf0w9zBgfzEpcLpxb=1wZjZ6%2Bdrm7E%2B2gM7A@mail.gmail.com> In-Reply-To: <20190228230701.GA59003@troutmask.apl.washington.edu> References: <sgk@troutmask.apl.washington.edu> <20190228194929.GA18747@troutmask.apl.washington.edu> <201902282034.x1SKYWMi006337@slippy.cwsent.com> <20190228210635.GA31257@troutmask.apl.washington.edu> <CAGhTqAXx-xBM6yP33DW5QRYVzexURy7asCd4HJgfCOShGPO4rw@mail.gmail.com> <20190228230701.GA59003@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm not FreeBSD developer, I don't want you thinking I am and blame them. But you've beat this horse dead already. No reason to rehash it again. I also value a high S/N ratio, as otherwise it's just wasting my time. On Thu, Feb 28, 2019, 5:07 PM Steve Kargl <sgk@troutmask.apl.washington.edu> wrote: > On Thu, Feb 28, 2019 at 03:53:53PM -0600, Doug Kirk wrote: > > On Thu, Feb 28, 2019 at 3:07 PM Steve Kargl < > > sgk@troutmask.apl.washington.edu> wrote: > > > > > > > > Seems our experiences are exact opposites. :( > > > > > > I suppose it is the bane of those of who cannot afford > > > new hardware every 2 or 3 years. > > > > > > > > Hmm, because amd64 has only been available for the last 2 or 3 years? It > > was added to FreeBSD as experimental in 5.1-RELEASE (June 2003) and > > standard in 5.2-RELEASE (January 2004). > > I have a amd64 system with > > CPU: AMD FX(tm)-8350 Eight-Core Processor (4018.33-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 > > Guess what? Yep, it uses drm-legacy-kmod because the radeon video > card (drmn0: <Caicos [Radeon HD 6450]>) I have is sort of not supported > by drm-current-kmod. When I tried to use drm-current-kmod, I watched > /var/log/message fill up with some error message about waiting for a > mfence memory barrier. I was advised by the graphics team to use > drm-legacy-kmod. > > Sure, I can just run out an buy a shiny new video card, which will > be obsolescence in a few years and fall off the support video list. > At which point, I can rinse and repeat. > > > Jeff Atwood commented on desktop adoption of x86-64 in 2007 here: > > https://blog.codinghorror.com/is-it-time-for-64-bit-on-the-desktop/ , > and > > it even mentions that graphics cards don't like 32-bit limits. > > > > If you bought an x86-32 system within the last 2-3 years, why is that > > anybody else's fault that your graphics-based computer was obsolete when > > you bought it? > > You have completely missed the point. I didn't buy the laptop > in the last 2 or 3 years. It is several years old. The system > was working just fine until the PAE vs non-PAE merge was committed > (which surprise effects i386 systems). > > It is the system on which I work out the bits for libm, where the i387 > FPU is set such that long double only has 53-bits of precision. Yep, > I know, no one uses i386-class systems for numerical work. Given the > condition of libm and the crickets on freebsd-numerics@, it seems very > few people do any numerical research with freebsd. > > > Please stop whining on the mailing list, you're just adding noise by > > setting up straw-man arguments. > > I suppose pointing out that "the emperor has no clothes" can > be considered whining. When I commit a patch to the gcc tree, > if it affects others, I work to fix the problem. I don't shoot > the messenger. At one point in time, FreeBSD developers cared > about the quality of their work. > > -- > Steve >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGhTqAVmrRedSpRf0w9zBgfzEpcLpxb=1wZjZ6%2Bdrm7E%2B2gM7A>