From owner-freebsd-hackers Fri May 24 12:57:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA22603 for hackers-outgoing; Fri, 24 May 1996 12:57:20 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA22598 for ; Fri, 24 May 1996 12:57:18 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA01623; Fri, 24 May 1996 12:56:56 -0700 From: Terry Lambert Message-Id: <199605241956.MAA01623@phaeton.artisoft.com> Subject: Re: Mac Linux: Nothing to worry about :-) To: jehamby@lightside.com (Jake Hamby) Date: Fri, 24 May 1996 12:56:56 -0700 (MST) Cc: hackers@FreeBSD.org, fred@lightside.com, adam@lightside.com In-Reply-To: from "Jake Hamby" at May 24, 96 11:28:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 1) No shared libraries. None! These are ELF binaries by the way. > Everything is statically linked. For X programs this is particularly > disgusting, e.g. xlogo is a 1.2MB executable. I can only guess that > either a limitation of Linux's ELF support or a limitation of the GNU > development tools prevented the developers from porting shared lib support > to PowerPC for this release. I plan to inquire further about this > oversight since the PowerMac I tested on is short of disk space, and I > consider shared libs a _necessity_ for any modern Unix. I have had to hack the GNU utilities for PIC. The changes are not significant, but there is a requirement for not flushing the cache. I typically handle this by post-processing the object files, since the difference is one bit and the target value. > The lack of shared libraries, and the decision to bundle in crap like > Emacs, however, seem unexcusable, even for an early developer release. Emacs is the default editor for the Linux PPC PowerStac port as well; with a broken console raw mode, it is, in fact, unusable without an external terminal. > There is one fortunate thing out of all this: The OSF and Apple-developed > source code to the Mach kernel and Linux server are all freely available > and covered under a standard BSD-style copyright! Whoohoo! This means a > Free/NetBSD port to PowerMac is now feasible! Unfortunately I lack the > PPC assembly language and kernel hacking knowledge to undertake such a > beast, however I sincerely hope somebody else (Terry?) decides to take > this on. There are a number of Apple 6100's for sale for ~$2000 in one of the news groups. I'm going to check Circuit City for pricing this weekend, and see how it compares (they have a $150 off sale on all computers). If they get as cheap as a BeBox anywhere, I'll probably grab one (yeah, that's what I need, another computer. 8-)). > The question is: Would it be best to build a BSD "personality" > server on top of a Mach kernel, as MkLinux is built, or scrap that idea > and build a traditional BSD kernel? OSF claims the advantage of Mach > lies in SMP, real-time, and portability (port the microkernel to a new > architecture, then simply recompile the Linux server), but obviously this > is going to use more RAM and CPU than a "native" BSD kernel. Comments? If I do anything at all with the PowerMac, it will be a native port; the reasoning here is that the unified VM/Buffer cache and other advantages are unavailable in Mach. I also have a model for running x86 ABI modules for running things like NetScape under non-x86 processors, which would pretty much see a x4 slowdown on a hosted OS (like a Mach multiserver, if I started with that code). I would also like to share the PCI architecture bits, as well as other platform independent architectural attributes between systems. I still have some issues left over from the DEV Alpha days here; the Motorolla Ultra 603/604 (PowerStac) machines use a more traditional PC architecture, but the Mac PCI is not bridged from ISA (just like the Alpha PCI), so the code needs to be dual-mode -- it isn't. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.