Date: Sun, 9 Jul 2000 21:32:14 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Jamie Jones" <jamie@bishopston.net> Cc: <advocacy@FreeBSD.ORG>, <chat@FreeBSD.ORG> Subject: RE: Emulation: eg WordPerfect (was Re: No port of Opera? (Was: ((FreeBSD : Linux) :: (OS/2 : Windows)))) Message-ID: <NCBBLIEPOCNJOAEKBEAKOENLJJAA.davids@webmaster.com> In-Reply-To: <200007092106.WAA97669@bishopston.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > So why worry about running linux binaries under FreeBSD, something > > which works an order of magnitude better than wine? If one can get > > companies to support that officially, that certainly looks like a big > > gain to me. Aiming to remove linux compatibility is not only > > unrealistic but extremely undesirable. > If the product is officially supported, then that is a big plus. If a > product *is* supported under emulation completely, wouldn't it be easier > for the company to release a FreeBSD version too, so that they don't end > up supporting the emulator in the process ? :-) I tend to agree. I would imagine that officially supporting a version that runs under emulation would tend to be used as a stopgap measure. It's just too unprofessional and likely to be difficult to maintain. > Anyway, although you aren't actually impying this, I'd just like to point > out that I'm *not* in favour of removing the Linux emulation - my point is > that I'd be more likely to part cash for a native version than the Linux > version. Fair enough. A person trying to sell me a version to run under emulation would have to convince me of the stability and reliability of more pieces. The last time I ported a major project that compiled under Linux to FreeBSD, the vast majority of the work was dealing with missing functions like 'nanosleep' and 'poll'. Now that those functions exist, it's hard for me to imagine what difficulties could be encountered porting a program that works under Linux to FreeBSD. Even if you used real Linux-isms like details about proc, kernel modules, or something like that, you'd have to have a way to do those things on other OSes. Odds are one of those methods would work with minimal fuss under FreeBSD. The only issues I see are those related to stocking another product, supporting another platform, compiling more builds, and so on. I don't think there are technical issues left. (Thus, on to Jordan's post): > 2. If they do a FreeBSD version, and to any reasonable standard of > "commercial correctness", they also have to deploy FreeBSD in > the development, QA and support organizations so that the FreeBSD > version can be developed, tested and, once shipping, supported in the > field. I've had more than one ISV tell me, in response to my > assertion that a native FreeBSD version would not be hard for them > to do since FreeBSD is a pretty standard platform to port to and > all that, that porting is the LEAST of their worries. It's having > to add yet another platform to their development, testing and > support structures that incurs the real expense in internal > training and hours invested. > - Jordan If that's the issue, then nothing that you can do to FreeBSD technically will make any difference. Emulator, no emulator, portable ABI, or not -- it's purely a matter of whether there's enough people who want to run FreeBSD to justify the expense. If that's the major problem, then the solution is popularity and noise. The company I work for currently maintains _three_ FreeBSD builds of our products, one for FreeBSD2, one for FreeBSD3, one one for FreeBSD4. We're about to drop the FreeBSD2 build because it stopped working. That means we have to build and test two or three more versions before each release. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NCBBLIEPOCNJOAEKBEAKOENLJJAA.davids>