Date: Tue, 10 Nov 1998 17:10:09 +1030 (CST) From: Kris Kennaway <kkennawa@physics.adelaide.edu.au> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: Nate Williams <nate@mt.sri.com>, dnelson@emsphone.com, rivers@dignus.com, hackers@FreeBSD.ORG Subject: Re: linux software installation and uname Message-ID: <Pine.OSF.4.05.9811101703120.10232-100000@spectrum.physics.adelaide.edu.au> In-Reply-To: <199811100634.WAA12678@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Nov 1998, Steve Kargl wrote: > According to Nate Williams: > > > > Ahh, but what happens when I have to run the same applications in the > > > > same shell? Do I have to modify my environment everytime I run a > > > > different application? Do I have to remember which 'emulated OS' the > > > > application runs? > > > > > > That's where the proposed "commercial ports" category would come in. Someone > > > could provide wrappers for installation, executing, etc, which handle all the > > > messy work of setting environment variables and so forth to get the thing to > > > run, for things which require a 'tweaked' emulation environment. > > > > Is there an echo in the room? Isn't this what I initially proposed as a > > better alternative to hacking up the uname(1) sources? > > > > There's no echo, just a bunch of deaf hackers. > > I happen to disagree with the viewpoint that writing custom scripts > for each commerical vendor is a better solution. There may be only > a handful of scripts to write this month, but next month we will have > more custom scripts. If linux continues to gain in popularity among > commerical vendors, then we'll have to maintain a large collection of > scripts. There is a point of "diminishing returns" with respect to > maintain a large collection of scripts, particularly when a 4 line > change to uname(1) will accommodate the majority of the vendor supplied > scripts. I'm not sure we do disagree. Your 4-line change to uname(1) was to have it respect an environment variable and return it as the result of uname(1), correct? Someone pointed out at some point in this somewhat confused discussion that that would require people to repeatedly change their environment variables before running different emulated binaries, each of which looks for uname(1) at runtime. My suggestion was for a script wrapper which performs this environment-setting automatically, and then calls the emulated binary. This is probably a 2-line script itself, so is trivial to do, but makes it transparent for users who obtain the wrappers from a skeleton port for the "Mumbulator for Linux" commercial software (or freeware, but binary-only, etc). This ties in with the "FreeBSD certification program" which was proposed on -advocacy the other week: wherein a group of "us" would have the job of working out which software works with FreeBSD under emulation, documenting any caveats, providing the vendor with an appropriate "certificate" if they wish to use it, and creating the necessary "wrapper port" which will let people trivially install and run the software they obtain or purchase, under our emulation. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.05.9811101703120.10232-100000>