So it's kind of like A/UX in reverse (and yes, it will run on 68ks).A1. What is MachTen?
... The UNIX operating system runs in concert with the Macintosh operating system. When MachTen is running, you still have access to the Macintosh Finder desktop and Macintosh applications ...
Even though MachTen gives the appearance of being just another Macintosh application, its operation is more like that of a co-resident operating system. MachTen and MacOS share the processor -- when MachTen has control, it pre-emptively multitasks the UNIX applications; when MacOS has control, it runs the Mac applications using its cooperative sharing.
Since MachTen runs on top of MacOS, there is no need to partition the hard drive or to install separate MachTen-specific device drivers. MachTen maps the UNIX file system to the MacOS file system and uses the MacOS device drivers. This means that there is a single, consistent file system and that third party devices, such as network controller boards, automatically run with MachTen...
MachTen is a full-fledged operating system that, for portability reasons,
uses as much of the device driver software that's available in the
Macintosh. Where necessary, it will operate directly with the hardware.
A13. What add-on hardware is supported?
Because MachTen sits on top of the Macintosh file system and interoperates
with the Finder, all add-on hardware should work under MachTen. MachTen has
been used with Syquest drives, Bernoulli drives, Zip drives, accelerators,
multiport serial cards, ethernet cards (NuBus, SCSI, PCI) and video cards,
among others. In cases where MachTen takes control of the hardware (e.g., to
implement virtual memory), there could be incompatibilities.
Darn itF2. Can I use third party accelerators with MachTen?
CPU accelerators tend to make use of Apple's memory management hardware.
Therefore, in general, you can usually use accelerator boards as long as you
are not using MachTen VM. DayStar boards are generally not compatible with
MachTen.
And it's available for downloadD3. Why is Tenon's X so much faster than eXodus or MacX?
... Tenon sends the output of the X commands
directly to the Macintosh hardware screen buffers instead of using
QuickDraw. ...
Tenon's X is said to be the fastest on the Mac market. X11perf benchmarks on
a 25MHz 68040 Centris yield an XMark of 1.1 -- better than a SPARCStation 1!
On a 40MHz Quadra 840av, the X performance rivals a SPARCStation 2. XMark
ratings are not yet available for the native X performance on a Power Mac,
but Tenon's architectural advantage carries over to that platform as well.
Don't know why you would want to do that, but to each their own. The resulting file would be a text file, not an html file. And there are much easier ways of doing the same thing with basic shell commands. Why script for something that doesn't need to be scripted?I'd love to have MachTen on my SE/30, but only so I could do things like 'for i in `ls`; do echo "" >> file.html'; done![]()
I concur.If you really need UNIX on your 68k you probably want Linux or BSD; MachTen is only useful to let you do UNIX-isms in MacOS, IMHO.
Err. A HTML file IS a text file. It'd just be a matter of putting the header and footer in, then you'd have something a browser could parse. And you could easily put that in the script as well (as in $ echo "" >> file.html).Don't know why you would want to do that, but to each their own. The resulting file would be a text file, not an html file.so I could do things like 'for i in `ls`; do echo "" >> file.html'; done![]()
What's your idea of 'basic shell commands'? ls, echo and >> is about as basic as it gets! And a script is nothing but a list of shell commands.And there are much easier ways of doing the same thing with basic shell commands. Why script for something that doesn't need to be scripted?
$ ls >> file.html
You might. Or you could run a regular Mac HTTP server but do stuff like this in MachTEN. I think that's one of the uses for it...But you wouldn't be running an html server in MachTEN. Would you?
Remember that Mac OS uses cooperative multitasking. This means that the application in the front gives up time to other tasks. If the application in the front decides not to give up time, it can effectively monopolize the CPU (ignoring certain interrupts, etc), so performance probably isn't that bad and might actually surprise you. In some cases, cooperative multitasking gives better performance than preemptive multitasking, and I wouldn't be surprised at all if applications like this or emulators like VPC actually perform better on earlier systems than OS X. In fact, one of the early performance improvements that was commonly practiced for early versions of VPC was to make a specific System Folder for VPC and replace the Finder with Virtual PC with a few ResEdit mods to make it launch at startup. That guaranteed that only system tasks could interrupt VPC.I would be very surprised if this worked well even with an 040 if you are running other apps in your MacOS at the same time.