From owner-freebsd-current@FreeBSD.ORG Tue Apr 1 10:40:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 967C6BDE for ; Tue, 1 Apr 2014 10:40:25 +0000 (UTC) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp-sofia.digsys.bg", Issuer "Digital Systems Operational CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3583CFC0 for ; Tue, 1 Apr 2014 10:40:24 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [193.68.6.1]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.6/8.14.6) with ESMTP id s31AGpdc068980 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 1 Apr 2014 13:16:55 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <533A9213.40806@digsys.bg> Date: Tue, 01 Apr 2014 13:16:51 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Leaving the Desktop Market References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 10:40:25 -0000 Hice April 1st piece, Let's see what I could contribute :) On 01.04.14 08:46, Eitan Adler wrote: > Hi all, > > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can > be a worthwhile read to see what life is like when using FreeBSD as a > desktop. In short, it is an educational experience. While FreeBSD > can be coerced to do the right thing, it is rarely there by default > and often doesn't work as well as we would expect. There is no platform that can do everything as you please. In fact,=20 there can't be any such thing with computers, because they are not=20 humans and only do what we humans instruct (program) them to do, not=20 what we believe we programmed them to do. A slight difference, but=20 important to see things in perspective. > > The following are issues I haven't brought up in the past: > > Battery life sucks: it=E2=80=99s almost as if powerd wasn't running. = Windows > can run for five hours on my laptop while FreeBSD can barely make it > two hours. I wonder what the key differences are? Likely it=E2=80=99s= that > we focus so much on performance that no one considers power. ChromeOS > can run for 12 hours on some hardware; why can't we make FreeBSD run > for 16? Who said we can't? We did, do and will do that. On a case by case=20 solution. This is strictly hardware specific issue and of course, no=20 other OS can claim good power management on "any" hardware. > Sound configuration lacks key documentation: how can I automatically > change between headphones and external speakers? You can't even do > that in middle of a song at all! Trust me that you never want to be > staring at an HDA pin configuration. I'll bet you couldn't even get > sound streaming to other machines working if you tried. Lack of documentation has always been the "weak" part of any enthusiast=20 work. For people care more about getting the work done, than writing=20 long essays. I would not go that far to say you can't switch audio=20 outputs in a middle of a song (or why not, a movie?). After all, this is = strictly hardware specific issue and of course, no other OS can claim=20 good audio management on "any" hardware. > FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't > released a client for FreeBSD. Nvidia Optimus doesn't function on > FreeBSD. Can you imagine telling someone to purchase a laptop with > the caveat: "but you won't be able to use your graphics card"? Purchasing specialized hardware (a laptop), without being aware what=20 software will drive it is always a very bad idea. As for those vendor's=20 proprietary technologies, they don't function on many other modern=20 platforms, not only FreeBSD. Then, there is choice -- you could use=20 other vendor's technologies, if that suits you. Or, if (say) CUDA=20 requires OS XYZ, use that instead of FreeBSD. Not that this has=20 anything to do with "desktop". > > In any case, half of our desktop support is emulation: flash and opera > only works because of the linuxulator. There really isn't any reason > for vendors to bother supporting FreeBSD if we are just going to ape > Linux anyways. If you will remember, most of this is because of different licensing=20 restrictions imposed by those vendors. I am absolutely confident, Adobe=20 will produce a very good Flash Player for FreeBSD, once you convince=20 them there is money in that. > > That is why on this date I propose that we cease competing on the > desktop market. FreeBSD should declare 2014 to be "year of the Linux > desktop" and start to rip out the pieces of the OS not needed for > server or embedded use. FreeBSD is not sold. There is no such thing as "market" for FreeBSD.=20 Neither in Desktop, Server or whatever other arbitrary "segments". In=20 fact, FreeBSD is not even a product -- it is more of a toolkit, which=20 you use to build your very own OS for your very own "segment". Yes, 2014 might very well turn out to be the year of Linux, but that is=20 not because of FreeBSD -- Microsoft are helping much more with their=20 insistence to kill Windows XP. > > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the > Linux world? > You mean, all those short lived species will arrive in hordes and=20 destroy the Dragon? Might be, might be not. The dragon has seen=20 thousands of those already come and go. Having fun is most important in the process. :) Daniel