Date: Wed, 16 Sep 2015 13:02:16 +0200 From: Polytropon <freebsd@edvax.de> To: FreeBSD FreeBSD <freebsd-questions@freebsd.org> Subject: Re: 10.2 graphics problem Message-ID: <20150916130216.ec82e5f3.freebsd@edvax.de> In-Reply-To: <20150916054530.310f1eeb@seibercom.net> References: <8F541F88-2EAE-434C-B52C-43A744F54ADD@slsware.net> <alpine.BSF.2.20.1509151329030.76298@wonkity.com> <E6FDE819-14B8-4906-8E9C-F297341781E7@slsware.net> <867fnr1lwy.fsf@WorkBox.Home> <D5276C30-F75D-4C2B-9C21-F80502CFA30D@slsware.net> <20150915225637.05c1ffad.freebsd@edvax.de> <alpine.BSF.2.20.1509151906420.69660@wonkity.com> <20150916095120.9a44b05a.freebsd@edvax.de> <55F931FC.40000@freebsd.org> <20150916054530.310f1eeb@seibercom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Sep 2015 05:45:30 -0400, Jerry wrote: > On Wed, 16 Sep 2015 10:10:20 +0100, Matthew Seaman stated: > > > Although I do wonder why the Linuxers seem to feel the need to throw > > away their existing solutions and start again from scratch quite so > > often. DBus always struck me as quite a good piece of software. > > No exactly my field, but I have spoken to power programmers before who have > said that it is often far easier to start from scratch than it is to try and > throw a band-aid over old and/or obsoleted programs. I was surprised to > find that many older programs that have undergone extensive rewrites have > hundreds and sometimes thousands of lines of code that sit there doing > nothing. In effect, commented out. This sounds a lot like what I know from "business solutions" at "corporate scale"... ;-) > There is an ongoing development of "kdbus" that aims to reimplement D_Bus as > a kernel-mediated peer-to-peer inter-process communication mechanism, which > would offer performance improvements and system integration. This would be a great advantage on Linux, but I fear that all programs relying on this mechanism will have problems being compiled on FreeBSD, because our kernel won't have it that quickly. Until that point, ported applications (especially in the desktop environment domain, I assume) will lack some functionality. When you review history and the claims like "it is documented and can be embedded and extended easily" or "just write a module for it, it's easy", you'll see that it didn't help HAL to survive. DBus will probably be seen in a similar light, as its successor also will, sooner or later, and so on. Of course this is a natural course of development: If you want to support something new, carrying around old stuff might be a stupid thing to do; but if you try to keep "the same" stuff running, iterating and re-implementing it over and over probably is just burning resources. Please note that I'm not a Linux kernel developer, so I could have missed a point - just as you stated: that there are situations where is better to start from scratch than to duct-tape around lagacy code... > Since FreeBSD tends to be a "follower" rather than a "leader" in software > development, if linux does eventually adopt this, then sooner-or-later, > probably later, FreeBSD will do so also. And when the point is reached where it works flawlessly, a new solution will pop up, and kdbus will be obsoleted. At least this observation could be made for many other things during the last decades: "It works - discard it." FreeBSD is a leader when it comes to its own desktop environment which still is in an early stage of development. Maybe native applications will show up later on, such as a web browser, an office suite, e-mail client, multimedia center or image editing. Natively developed applications, intended for FreeBSD (instead of Linux-centrically developed applications ported over) could be an advantage. But I'm not brave enough to try to make any "economical" assumptions about such a decision course. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150916130216.ec82e5f3.freebsd>