Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

OpenBSD Linux Emulation Howto 16

Posted by michael from the information-wants-to-be-free dept.
evilviper writes: "BSDToday has a great article on how to run Linux binaries under OpenBSD. The article's already been picked up by sites like RootPromt and others so it's obviously as good of a tutorial as it gets. It's short and sweet, while covering everything from installing the OpenBSD linux package, as well as getting and installing the Linux libs for those of those without a Linux box to steal files from."
This discussion has been archived. No new comments can be posted.

OpenBSD Linux Emulation Howto More

OpenBSD Linux Emulation Howto

Comments Filter:
  • Even though it is short, it tells the things you need to implement this.
  • The article mentions that OpenBSD 2.9 will have a bunch of improvements in Linux binary emulation. Anyone running -current care to give some feedback on their experiences?

    O.T. How does FreeBSD's Linux binary emulation compare? Pros, cons, etc.

  • Really, I'm not flaming or trolling, but there's something I just don't understand. If Linux copies UNIX, and if *BSD copies UNIX (and AIX, and HPUX, and Solaris, and etc. all copy UNIX), then why can't "UNIX" applications run on any of them?

    OK, I know why. But really, as someone pointed out the other day, the Open Group [opengroup.org] will certify NT as a "UNIX" OS if it meets their criteria, so why isn't the real goal to get *BSD certified as an official "UNIX" (and, similarly, to get Linux certified as well)? If my suspicions are correct and the certification does not mean apps are portable, then we need better UNIX certification, not abandonment of the only available certification.

    I also wonder how many people are scrambling to run *BSD binaries on their Linux boxes... Again, not to flame or troll, but I wonder about market share and how it affects software developers. Anyone know off-hand how many apps cleanly compile for both *BSD and Linux? (and yes, I know the story is about compatible binaries, not compatible source).

    Hell, how many binaries run on all Linux distros (hopefully the Linux Standard Base [linuxbase.org] will help)? So are we talking getting Red Hat binaries to run on BSD, or are we talking about Debian binaries, or does it matter?

    Finally, it seems to me that it would be better to put the effort into making compiling the source so easy (transparent) that we don't care about binaries anymore. One real advantage of UNIX isn't that I can copy a binary file from my HPUX box and run it on my Solaris box, but rather that I can compile the same source on both boxes. This allows you to run UNIX on virtually any hardware and still find applications that will work -- you just have to compile them! Users new to UNIX have to learn all sorts of things that are different from the VAX/OS2/DOS/Windows/Amiga/Mac world they came from; why shouldn't compiling code be another thing all UNIX users learn?

  • gnome vs. KDE

    Simple... XFce [xfce.org]. The only full-featured desktop that only takes up 4 megs of RAM, and is the most intuitive thing since NeXT.

  • My problem with this article is that it didn't really explain how the emulation was achieved. I'm a FreeBSD user myself and I have no idea if OpenBSD uses a similare method to FreeBSD or not (I would suspect it would). At any rate, if you want more information about the FreeBSD side of things go here: http://www.freebsd.org/doc/en_US.ISO_8859-1/books/ handbook/linuxemu.html The "advanced topics" section really explains how the emulation is pulled off, which of course isn't really emulation, just an implementation of an application binary interface (ABI).
  • It gives people enough information to get it up and running with very nominal difficulty. If you want a detailed explanation, man linux_compat works great, or visit openbsd.org to see the man pages online.
  • However, the superior method (if you have access to a linux machine) of using a linux machine's 'ldd' command to divine all the libraries required is mentioned in the man page but not in the HOWTO.

    With programs that call other programs, and programs that wont work unless called from scripts, and so on, ldd rarely works.

    Your next statement is great... You say that developers keep their documentation up to date and fill with all need information, but now we have to go to mailing lists to get answers.

    What bothers me most, honestly, is having a secondary source that doesn't make it clear that 1) it is a secondary source, 2) where to find primary sources.

    It is a howto... That by itself denotes a secondary source of information. Very often condensed to make it simple and targeted to make it trivial to setup. Does the man page point to other information? Could it? Online information changes so fast that no references can be maintained. If any static document makes a reference, it should be included. Why tell someone where they can get other information that tells them the same things anyhow?

    The beginning user who reads this and finds it inadequate has no guidance of where to go for further, possibly updated, help.

    And if this how-t wasn't written, the beginners would have nowhere to go in the first place. Does that statement of yours really make sense to you? How would you think they are going to come upon it in the first place and do you think it's the only document they'd find when looking for help?
  • It is just a simple beginners tutorial to get people up and running. If you know how to do that already, why are you reading it in the first place?
  • It is GNU/Linux emulation. You think you could run Linux apps without the GNU libraries and utilities? The BSD kernel already does the Linux kernel emulation, meanwhile, you need to install GNU packages to get the applications to actually work. But of course you knew that right...
  • With programs that call other programs, and programs that wont work unless called from scripts, and so on, ldd rarely works.

    Any program that doesn't work unless called from a script is fundamentally broken, sorry. Admittedly, ldd won't always show one everything necessary, but why not find out all the first-level dependencies at once rather than iteratively?

    Your next statement is great... You say that developers keep their documentation up to date and fill with all need information, but now we have to go to mailing lists to get answers.

    Developers keep their information up-to-date, but that information is only delivered to typical users at release dates, twice a year. It's not uncommon in mailing lists for people to speak up with problems that were previously unknown; when you don't have the infinite userbase of linux, those exotic problems aren't all going to get covered in the pre-release stage.

    And if this how-to wasn't written, the beginners would have nowhere to go in the first place.

    man -k linux. It returns exactly one hit: the compat_linux manpage. Not knowing "man -k" is no excuse when the first piece of mail delivered to root directs the user to read and understand the man manual page. Or if you miss that, /usr/bin/help displays an introductory manpage which also explains the importance of the man command.

    How would you think they are going to come upon it in the first place and do you think it's the only document they'd find when looking for help?

    I don't know, but since the other types of documentation are only available on the web as the results of cgi queries (archived mailings, man pages), a web search might just return only howto's such as this one.

  • UNIX:
    The Open Group's specification isn't something they bless you with for free. It's like ISO-9001; you can follow the standard like a nazi, but it won't get your "certified" unless you pay to get the tests done and approved.

    Better Source:
    See the (Net|Free|Open)BSD port systems. Lots of smallish singular apps do compile cleanly on most any unix. But complex ones (do you realize how many dependencies Gnome has??) are just a pain in the ass. Don't get me started on GNU ``portability tools'' like libtool. The ports tree allows all BSD users to benefit from just a few people's porting efforts. And it doesn't depend on the goodwill of the software authors to incorporate patches, although that's always preferred.

    Which Distro?:
    The usual barrier to cross-distribution binaries, afaik, is library versions and/or config file placement. The emulation layer is distro-agnostic in that respect.

    The emulation layer itself doesn't do much but support syscalls and convert kernel structures to what linux binaries expect. But in addition, every linux binary running sees an alternate version of the filesystem -- one in which the contents of "/emul/linux" override the rest. If "/emul/linux/foo" exists, linux binaries will access it rather than "/foo". That's how the linux_lib port works.

    Gripe:
    This is actually quite a disappointing document if you ask me. It doesn't say anything that's not easily available elsewhere. I know you linux types love having your hand held, but this question has been answered many times on OpenBSD's mailing lists, which are archived and searchable. And a more detailed explanation is available at my fingertips with the command man compat_linux. Or to the rest of you at OpenBSD's online manual pages [openbsd.org].

  • I thought it was quite annoying how he constantly calls it Gnu/Linux emulation. This is the Linux kernel that's being emulated, not Gnu userspace. After all, the Gnu stuff can be compiled to native BSD binaries. All in all, I'd have to say it's a pretty poor article that added nothing that wasn't already in OpenBSD's compat_linux (8) man page.
  • Yes, you are correct, it would be nice to see UNIX apps as opposed to "linux" or "AIX" or "BSD" applications.

    The X86 market tried to get together X86Open [x86open.org]. After a bit, allmost everyone in the group has a "Linux Emulation/Compatibility" layer. So, Linux-ELF was declared a "standard", and the group all went home, claiming victory.

    Given the lack of progress of LSB, the lack of progress of the great UNIX unification, and the desire of frims to carve out thier own hunk o money, asking for UNIX programs will always be an uphill battle.
  • One thing to add about the which-distribution question is that the linux_lib port is based on RedHat. Strictly speaking, that port isn't part of the "emulation layer", but it's biases matter to anyone who doesn't want to spend time gathering their own libraries.
  • First, on further study, I will grant that there is one new thing not mentioned in the man page: suggesting the iterative process of library hunting. However, the superior method (if you have access to a linux machine) of using a linux machine's 'ldd' command to divine all the libraries required is mentioned in the man page but not in the HOWTO.

    On the other hand, there was recently a question (and answer [sigmasoft.com], make that answers [sigmasoft.com]) on the mailing list about a linux emulation error, but no mention of the possible trip-up (which novices might well encounter) in the HOWTO.

    The OpenBSD developers spend a lot of effort making sure their documentation is clear, up to date, and accurate; it's an extension of their security focus in the sense of: "code should always do exactly and only what the documentation says it does".

    What bothers me most, honestly, is having a secondary source that doesn't make it clear that 1) it is a secondary source, 2) where to find primary sources.

    The beginning user who reads this and finds it inadequate has no guidance of where to go for further, possibly updated, help.

  • I just hope that our continued improvement of Linux binary support will ease the transition from Linux to OpenBSD. These components will help people realize that they can still run all of their commercial Linux applications without having to worry about doing so on a cobbled together and insecure operating system.

    Thus, you will less and less of phenomena such as the Ramen Worm and other stupid security issues in the future when commerce sites switch over to OpenBSD while still running such things as Oracle 8i and other applications that have a Linux port but no OpenBSD binaries.

Slashdot Top Deals

You knew the job was dangerous when you took it, Fred. -- Superchicken

Close