Date: Wed, 26 Apr 95 20:25:23 MDT From: terry@cs.weber.edu (Terry Lambert) To: ddunbar@ipxpress.aws.waii.com (Don Dunbar) Cc: questions@FreeBSD.org Subject: Re: linux Message-ID: <9504270225.AA11339@cs.weber.edu> In-Reply-To: <199504270040.AA02827@ipxpress.aws.waii.com> from "Don Dunbar" at Apr 26, 95 07:40:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> My dad's office telles him that FreeBSD is not AT&T UNIX compatible and it > can't run SunOS 4.1.3 binaries like Linux can. Is this true? Does FreeBSD > use 'ports' like Linux? This "feels" as if it were being asked rather tongue-in-cheek, but I'll answer it seriously anyway. Linux can not run SunOS 4.1.3 binaries; in fact, I believe the only hardware capable of that is Sun hardware, an Linux doesn't run there. SunOS 4.1.3 is not AT&T UNIX compatible in any case, so your information is confused. I do believe that NetBSD on Sun hardware can actually run the majority of SunOS 4.1.3 programs, however. Currently, FreeBSD is not ported to multiple platforms (it's Intel specific), but since NetBSD and FreeBSD are "sisters", it would probably be a trivial "port" that would mostly involve integrating code fron NetBSD into FreeBSD and offending peoples political sensabilities in the process (I suspect). The major issue would be the changes to the source tree organization that would be needed to do this. If you know someone who has a Sun machine supported by NetBSD and are willing to do the work (and will be careful to credit the NetBSD authors), I don't think anyone would complain too loudly. I think a Linux port to SPARC would be a lot more difficult, both because of their VM and tasking code being highly Intel-centric (though this has been changing) and because it would be difficult to take the NetBSD code wholesale and comply with the UCB syle copyright restrictions that say you don't have to give away source code and the Linux GPL restrictions that say you do. There is also the issue of GPL requiring "no additional restrictions", and the UCB style copyright demanding credit in published materials being in conflict. I don't know about Sun 386i binaries -- I believe that Linux can *not* run them; FreeBSD can't, but NetBSD might be able to. Maybe this is what "your dad's office" meant when they said that. Neither Linux nor any of the BSD's are truly AT&T UNIX compatible. To claim compatability, you would have to pass a validation suite for SVID, the System V Interface Definition. It's humerous to note that UnixWare, which is the current "real UNIX" is not SVID compliant. It fails on gettimeofday(RT), getitimer(RT), setitimer(RT), and select(S). This is not anything that anyone in the industry doesn't already know if they've tried to use these interfaces. The system timer deficiencies that cause this failure are the main reason UnixWare does not support QIC-80 tapes prior to release 2.0, and supports them badly in the current release. There is a binary compatability mode for SVR3 using COFF format. Most SVR4 binaries are still distributed this way, including things like Sybase and other commercial databsed software. The compatability mode is called IBCS2, which stands for Intel Binary Compatability Standard, version 2. Linux, FreeBSD, and NetBSD all partially comply with IBCS2, although there are areas where one is more compliant than another. Where none of them comply is the installation mechanisms. Generally, the shell script and package management tools are not IBCS2 compliant on these machines. You're local "Barnes and Noble" or other computer bookstore will have a copy of IBCS2 as part of the SVR3/SVR4 manual set published by "UNIX Press". If you can fight the install process sufficiently, the IBCS2 packages will mostly run on all three systems. I have personally run a binary distribution of Lotus 123 on both FreeBSD and NetBSD. I have also run Micorsoft Word for SCO UNIX, and SCO Foxbase (also for SCO UNIX) on FreeBSD. I have run Sybase on FreeBSD after integrating the Linux /dev/socket driver, which is part of their IBCS2 code. Linux will not run Sybase, though, and neither will NetBSD (NetBSD for trivial reasons that I forget, and Linux from some protocol stack and signal issues). I did not contribute this integration back because it's relatively easy to do, because of the GPL on the driver contaminating the BSD kernel viability, and because of the fact that Novell claims to own any UNIX work I did on my own time after they bought USL and I was employed by Novell when I did the actual work (in other words, don't ask me for it, you won't get it). The FreeBSD "ports" collection is probably the most advance of any of the operating systems in question, since they are all packaged for easy installation by a novice user. The NetBSD ports collection uses the same software (with only slight changes) so as long as you have the FreeBSD shared libraries and ld.so available, the programs should run on NetBSD as well. NetBSD is also maintaining a growing ports collection. Linux has arguably more precompiled software for it, but it is also arguably in a less easy to install form. The install process is often the hardest part of getting a port running unless you are compiling it yourself, so this is a big factor for some people. On the other hand, Linux CDROM collections tend to have a top-down install for what's on the CDROMS, although the Linux tools are much less robust if you want to try something out then later get rid of it. None of the OS's install tools are compatable with any commercial operating system's install tools. Looking over this message prior to sending it, I note that it seems to give a preferability order of NetBSD, FreeBSD, and last Linux. This has more to do with the specific questions you asked than it does to do with my personal preferences, or the capability of the OS's. If you ask different questions, I'd probably give you a different order. If you asked straight out which is better and why, I'd just say that they are different and they each have different strength, and the answer you get depends on what you single out. That is, a comparison made that way will be about as fair as your average slanted benchmark. Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504270225.AA11339>