OpenBSD Linux Emulation Howto 16
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."
Good article (Score:1)
2.9 improvements (Score:1)
O.T. How does FreeBSD's Linux binary emulation compare? Pros, cons, etc.
Just curious... (Score:2)
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?
Re:Linux Emulation is Difficult (Score:1)
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.
Re:2.9 improvements (Score:1)
Re:2.9 improvements (Score:1)
Re:Just curious... (Score:1)
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?Re:Just curious... (Score:1)
Re:GNU/Linux (Score:1)
Re:Just curious... (Score:1)
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.
Re:Just curious... (Score:2)
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].
GNU/Linux (Score:2)
Re:Just curious... (Score:1)
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.
additionally, (Score:1)
Re:Just curious... (Score:1)
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.
Wider adoption of OpenBSD (Score:1)
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.