4 Aug
2006
4 Aug
'06
7:56 p.m.
But, one key difference between the QNX approach and
that of
most other current OS's is the microkernel architecture.
Instead of a BIG monolithic kernel with ALL the drivers
installed (or, extra glue for LKM support, etc.), a microkernel
based design treats all of these as components which can be
plugged together. And *talk* to each other (instead of being
invoked "from above").
Yes, you just have the IPC overhead, though.
Not sure if it's IPC or cheaper hardware, but large network operations on my Macintosh
(System 10) bring the machine
much closer to it's knees than any monolithic UNIX or even VMS on a VAX 4000/200. NB -
I haven't used the microkernel
based Tru64 yet.
Microkernels are neat in theory, but a well-trimmed monolithic kernel seems to do pretty
well with not too much space.
4 Aug
4 Aug
8:24 p.m.
Scott Quinn wrote:
I think the "problem" with the microkernel approach is trying
to compare apples and oranges. Getting a conventional UN*X
running on a microkernel architecture and trying to have that
compete *performance wise* with a monolithic kernel that
has been tweaked for MANY years is a no-win position.
The appeal of the microkernel approach is getting multiple
OS's to coexist on the same box (at the same time!) as well
as a cleaner conceptual design.
It also lends itself more cleanly to distributed systems
(which are difficult to implement using traditional
monolithic kernels which must make all the communications
very *visible* -- vs. their implicit roles in microkernel
approaches)
But, one key difference between the QNX approach
and that of
most other current OS's is the microkernel architecture.
Instead of a BIG monolithic kernel with ALL the drivers
installed (or, extra glue for LKM support, etc.), a microkernel
based design treats all of these as components which can be
plugged together. And *talk* to each other (instead of being
invoked "from above").
Yes, you just have the IPC overhead, though.
Not sure if it's IPC or cheaper hardware, but large network operations on my
Macintosh (System 10) bring the machine
much closer to it's knees than any monolithic UNIX or even VMS on a VAX 4000/200. NB
- I haven't used the microkernel
based Tru64 yet.
Microkernels are neat in theory, but a well-trimmed monolithic kernel seems to do pretty
well with not too much space. 
8:58 p.m.
At 9:56 PM -0500 8/4/06, Scott Quinn wrote:
Yes, you just have the IPC overhead, though.
Not sure if it's IPC or cheaper hardware, but large network
operations on my Macintosh (System 10) bring the machine
much closer to it's knees than any monolithic UNIX or even VMS on a
VAX 4000/200. NB - I haven't used the microkernel
based Tru64 yet.
Microkernels are neat in theory, but a well-trimmed monolithic
kernel seems to do pretty well with not too much space.
Don't get me started... I just want to say one thing. Compare
performance on *ANY* Mac running Mac OS X to something like an SGI o2
running IRIX. Sure, any current Mac will win on raw horsepower, but
put both systems under a heavy load, and I think you'll find even the
most pathetic of o2's will win.
I'm still not convinced Mac OS X is that big of an improvement over
my Mac OS 9 system.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
10:41 p.m.
Zane H. Healy wrote:
I'm still not convinced Mac OS X is that big of an
improvement over my
Mac OS 9 system.
Zane
Mac OS 9 is very similar to Windows 3.1 -- no memory protection,
co-operative multitasking, limited file structures, poor networking,
one-app's-bug-brings-it-all-down, etc.
Mac OS X is a fork of FreeBSD, a modern UNIX with hardware memory
management and protection, preemptive multitasking, complex file systems
and structures, a roburst netowkring API (BSD sockets), etc.
So you are saying that FreeBSD isn't much of an improvement over Windows
3.1?
In terms of function and design, that is.
--
The real problem with C++ for kernel modules is: the language just sucks.
-- Linus Torvalds
10:48 p.m.
On 8/5/2006 at 1:41 AM Segin wrote:
Mac OS 9 is very similar to Windows 3.1 -- no memory
protection,
co-operative multitasking, limited file structures, poor networking,
one-app's-bug-brings-it-all-down, etc.
The big difference is that OS 9 is a real operating system. Win3.1 is
basically a DPMI server with a bunch of APIs to implement windowing. Under
the hood, it's still MS-DOS. One boots OS 9, but not Win 3.1 (or WIn9x for
that matter)--one boots DOS.
And WIn 3.1 does have memory protection; it's just not very good.
Cheers,
Chuck
10:57 p.m.
Chuck Guzis wrote:
On 8/5/2006 at 1:41 AM Segin wrote:
I know this. I was trying to make a comparasion with the first thing
that came to mind. If you can think of something better to compare Mac
OS 9 to, I'll be glad to hear it.
Mac OS 9 is very similar to Windows 3.1 -- no
memory protection,
co-operative multitasking, limited file structures, poor networking,
one-app's-bug-brings-it-all-down, etc.
The big difference is that OS 9 is a real operating system. Win3.1 is
basically a DPMI server with a bunch of APIs to implement windowing. Under
the hood, it's still MS-DOS. One boots OS 9, but not Win 3.1 (or WIn9x for
that matter)--one boots DOS. And WIn 3.1 does have memory protection; it's just
not very good.
Not in Standard (286) mode.
Cheers,
Chuck
The real problem with C++ for kernel modules is: the language just sucks.
-- Linus Torvalds
11:19 p.m.
On 8/5/2006 at 1:57 AM Segin wrote:
Are you sure you're not thinking of Win 3.0 Real mode? 3.1 286p (standard)
mode does have protection and it's pretty easy to generate type 12 and 13
faults (STKFAULT, GPFAULT). OTOH, nothing faults in real mode--because
there's no protection.
How about comparing OS 9 to Windows 2.0 or Topview?
Cheeers,
Chuck
And WIn 3.1
does have memory protection; it's just not very good.
Not in Standard (286) mode.
11:31 p.m.
Chuck Guzis wrote:
On 8/5/2006 at 1:57 AM Segin wrote:
Are you sure you're not thinking of Win 3.0 Real mode? 3.1 286p (standard)
mode does have protection and it's pretty easy to generate type 12 and 13
faults (STKFAULT, GPFAULT). OTOH, nothing faults in real mode--because
there's no protection.
How about comparing OS 9 to Windows 2.0 or Topview?
Cheeers,
Chuck
Surely :P
--
The real problem with C++ for kernel modules is: the language just sucks.
-- Linus Torvalds
And WIn
3.1 does have memory protection; it's just not very good.
Not in Standard (286) mode. 
5 Aug
5 Aug
1:42 p.m.
Segin wrote:
Chuck Guzis wrote:
Well all I know OS/9 for the 6809 was a REAL OS!
I expect that APPLE just picked the same name for their
OS.
On 8/5/2006 at 1:41 AM Segin wrote:
I know this. I was trying to make a comparasion with the first thing
that came to mind. If you can think of something better to compare Mac
OS 9 to, I'll be glad to hear it.
Mac OS 9 is very similar to Windows 3.1 -- no
memory protection,
co-operative multitasking, limited file structures, poor networking,
one-app's-bug-brings-it-all-down, etc.
The big difference is that OS 9 is a real operating system. Win3.1 is
basically a DPMI server with a bunch of APIs to implement windowing.
Under
the hood, it's still MS-DOS. One boots OS 9, but not Win 3.1 (or
WIn9x for
that matter)--one boots DOS. And WIn 3.1 does have memory protection; it's
just not very good.
Not in Standard (286) mode.
4:05 a.m.
Segin wrote:
Mac OS 9 is very similar to Windows 3.1 -- no memory
protection,
co-operative multitasking, limited file structures, poor networking,
one-app's-bug-brings-it-all-down, etc.
Yes. MacOS "Classic" needs to die, die, die.
Mac OS X is a fork of FreeBSD, a modern UNIX with
hardware memory
management and protection, preemptive multitasking, complex file systems
and structures, a roburst netowkring API (BSD sockets), etc.
Umm...excuse me, but MacOS X is *not* a "fork of FreeBSD". It is
based on the Mach microkernel, with big chunks of FreeBSD layered on top
of that (system libraries and networking), with a healthy amount of
NetBSD (userland programs) thrown in for spice.
-Dave
--
Dave McGuire
Cape Coral, FL
10:56 a.m.
At 7:05 AM -0400 8/5/06, Dave McGuire wrote:
Yes. MacOS "Classic" needs to die, die, die.
You going to be the one to get companies like Apple to port all the
Classic apps that haven't been updated in half of forever (i.e. still
68k)? Some of us have applications that there is no modern
equivalent of. Sadly the solution needs to be a well integrated 3rd
party emulator for the newer systems :^(
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
11:25 a.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
Zane H. Healy wrote:
You going to be the one to get companies like Apple to port all the
Classic apps that haven't been updated in half of forever (i.e. still
68k)? Some of us have applications that there is no modern equivalent
of. Sadly the solution needs to be a well integrated 3rd party
emulator for the newer systems :^(
Basilisk II works just fine for me as an 020 or 040 emulator. I only
wish it would run A/UX and support virtual floppies.
There's also mini-VMac as well. The original vMac seems to have fell
off the face of the planet. Its website is still up, but you can no
longer download the packages.
see: http://basilisk.cebix.net/#download and
http://www.users.bigpond.com/pear_computers/ and
http://www.gibix.net/dokuwiki/en:projects:basilisk2#downloads ).
http://minivmac.sourceforge.net/ <- emulator here.
http://www.rolli.ch/MacPlus <- Ancient Mac OS software
I also had lots of fun with MAE 2.0 on Sun machines, though the
AppleTalk and I think a storage driver (floppy? CDROM?) doesn't work
with modern Solaris's. I was able to download MAE 3.0 before apple
killed off the MAE website, but unfortunately didn't have a serial # for
it, so it's kind of worthless.
There's also Executor which you can find here: http://www.ardi.com/
which is mostly compatible with 68K Mac OS software. It's not open
source, but there are binaries for windows and linux.
11:46 a.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
Zane H. Healy wrote:
I've head of these, but haven't tried them yet, as I'm still running
10.3.9 on a G5, so can still run my software under classic. Ideally
I'd like a PPC emulator, even a 604e would work for me.
I need something that supports networking, interfaces cleanly with
the host OS's filesystem, and gives me a decent sized screen
(1280x1024 would do nicely). Ideally PPC support, but just 68k
support would let me run the most important stuff.
I really need to check check out a modern version of Basilisk II and
mini-vMac! It might even allow me to move to Mac OS X 10.4.
You going to be the one to get companies like Apple to port all the
Classic apps that haven't been updated in half of forever (i.e. still
68k)? Some of us have applications that there is no modern equivalent
of. Sadly the solution needs to be a well integrated 3rd party
emulator for the newer systems :^(
Basilisk II works just fine for me as an 020 or 040 emulator. I only
wish it would run A/UX and support virtual floppies.
There's also mini-VMac as well. The original vMac seems to have fell
off the face of the planet. Its website is still up, but you can no
longer download the packages. There's also Executor which you can find here:
http://www.ardi.com/
which is mostly compatible with 68K Mac OS software. It's not open
source, but there are binaries for windows and linux.
Wow, I remember them well, I used the Demo 10+ years ago to write
floppies on my P90 laptop running Windows and Linux (it could access
the Internet, when I was in the US and had phone access) that could
be read on my PowerBook 520c. It was pretty cool. IIRC, the demo
was also where I got what was one of my favorite Mac OS X games :^)
To bad they're not still a functioning business.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
12:02 p.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
Zane H. Healy wrote:
I've head of these, but haven't tried them yet, as I'm still running
10.3.9 on a G5, so can still run my software under classic. Ideally
I'd like a PPC emulator, even a 604e would work for me.
...
I need something that supports networking, interfaces
cleanly with the
host OS's filesystem, and gives me a decent sized screen (1280x1024
would do nicely). Ideally PPC support, but just 68k support would let
me run the most important stuff.
I think PearPC does PPC emulation. It emulates a
G3 or G4, but very
slowly. see http://pearpc.sourceforge.net/ and this link for an
article that tells you how to configure it:
http://www.windowsdevcenter.com/pub/a/windows/2005/01/18/PearPC.html
I'm not sure if it will run OS 9.x. Basilisk will run upto OS 8.5 just
fine. (OS 9 is PPC only)
Basilisk II does have networking, and you can surf the web with ancient
Netscape Navigators. At least, there's a network module for it on
Windows. Not sure about under Mac OS X.
Wow, I remember them well, I used the Demo 10+ years
ago to write
floppies on my P90 laptop running Windows and Linux (it could access
the Internet, when I was in the US and had phone access) that could be
read on my PowerBook 520c. It was pretty cool. IIRC, the demo was
also where I got what was one of my favorite Mac OS X games :^) To bad
they're not still a functioning business.
Yeah, but if they open source it, it
has a better chance of survival, in
one form or another. Executor's 68K core seems to be very fast, so it
could be useful to lots of other emulation projects.
9:40 p.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
At 3:02 PM -0400 8/5/06, Ray Arachelian wrote:
Zane H. Healy wrote:
I'm actually looking to be able to talk classic Appletalk via an
emulator rather than TCP/IP. Mac OS X handles TCP/IP just fine, so
unless I'm trying to run my rather antiquated version of eXodus
(X-Windows) I personally don't have a need, though I could probably
find one :^)
I've head of these, but haven't tried them yet, as I'm still running
10.3.9 on a G5, so can still run my software under classic. Ideally
I'd like a PPC emulator, even a 604e would work for me.
...
I need something that supports networking,
interfaces cleanly with the
host OS's filesystem, and gives me a decent sized screen (1280x1024
would do nicely). Ideally PPC support, but just 68k support would let
me run the most important stuff.
I think PearPC does PPC emulation. It emulates a
G3 or G4, but very
slowly. see http://pearpc.sourceforge.net/ and this link for an
article that tells you how to configure it:
http://www.windowsdevcenter.com/pub/a/windows/2005/01/18/PearPC.html
I'm not sure if it will run OS 9.x. Basilisk will run upto OS 8.5 just
fine. (OS 9 is PPC only)
Basilisk II does have networking, and you can surf the web with ancient
Netscape Navigators. At least, there's a network module for it on
Windows. Not sure about under Mac OS X. Yeah, but if they open source it, it has a better
chance of survival, in
one form or another. Executor's 68K core seems to be very fast, so it
could be useful to lots of other emulation projects.
Keep in mind that it's been about 10 years since I touched it,
however, wasn't it emulating both the 68k and System 6? Or was it
System 7? It didn't actually run it.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
6 Aug
6 Aug
4:46 a.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
"Zane H. Healy" wrote:
I'm actually looking to be able to talk classic Appletalk via an
emulator rather than TCP/IP.
Mmmm. The emulator would have to patch the roms and catch the calls to
the LAP driver. At the bottom it's talking to the SCC in a way that
might make it hard to emulate. It might be possible to fool the code
into thinking everything was ok and then collect the packet bytes...
(ugg. i've worked on lap drivers talking directly to the scc. that
code was extremely timing critical.)
thinking about writing an scc chip emulator makes my head hurt.
-brad
7:27 a.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
At 7:46 AM -0400 8/6/06, Brad Parker wrote:
"Zane H. Healy" wrote:
Are you talking about Appletalk over serial? I meant over ethernet.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
I'm actually looking to be able to talk classic Appletalk via an
emulator rather than TCP/IP.
Mmmm. The emulator would have to patch the roms and catch the calls to
the LAP driver. At the bottom it's talking to the SCC in a way that
might make it hard to emulate. It might be possible to fool the code
into thinking everything was ok and then collect the packet bytes...
(ugg. i've worked on lap drivers talking directly to the scc. that
code was extremely timing critical.)
thinking about writing an scc chip emulator makes my head hurt.
-brad
12:55 p.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
"Zane H. Healy" wrote:
Yes, I ment localtalk. Sorry. I would think over ethernet would be
pretty simple.
-brad
(ugg. i've worked on lap drivers talking directly to the scc. that
code was extremely timing critical.)
thinking about writing an scc chip emulator makes my head hurt.
Are you talking about Appletalk over serial? I meant over ethernet.
7:42 a.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
Zane H. Healy wrote:
I'm actually looking to be able to talk classic
Appletalk via an
emulator rather than TCP/IP. Mac OS X handles TCP/IP just fine, so
unless I'm trying to run my rather antiquated version of eXodus
(X-Windows) I personally don't have a need, though I could probably
find one :^)
You could either get an AppleTalk to EtherTalk bridge. I think
Faralon
made those. Actually, I have one of those that I have never been able
to get working, if you want it contact me offlist and I'll try to locate
it.
Or, you could get an old IIsi with an ethernet card and run the
LocalTalk to Ethertalk bridge program. I don't have much use for
AppleTalk anymore. There aren't that many devices that I own that
use'em that don't have ethernet. I used LocalTalk back when I used an
old TI microlaser printer that had the option. It was perfect for that.
I even used a PC LocalTalk port to network to this printer. I think it
had DOS drivers, so 8.3 file names for file sharing were the thing, and
it connected on the parallel port.
I suppose I could use LocalTalk to talk to my old Mac SE or Lisa's, but
I usually don't run MacWorks on the Lisa's, and anything I transfer from
these usually works well enough over sneakernet with floppies. :-)
Besides, I'd rather fire up Basilisk or vMac instead of the SE since
it's less trouble and runs a lot faster.
May I ask, what do you want to do with LocalTalk?
Keep in mind that it's been about 10 years since I
touched it,
however, wasn't it emulating both the 68k and System 6? Or was it
System 7? It didn't actually run
Executor does seem to emulate system 7.
However, that's not its
strength. It's strength is the speedy 68040/68020 emulation and also
the rewritten Mac OS system calls. This is equivalent to the WINE
projects rewrite of the win32 API calls.
It might not be such a big deal since Basilisk II does a much better job
at emulating Mac OS, and it's likely that its JIT is better written.
8:17 a.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
At 10:42 AM -0400 8/6/06, Ray Arachelian wrote:
Zane H. Healy wrote:
When I say classic Appletalk, I'm actually talking about over
ethernet, while Mac OS X still supports Appletalk over Ethernet
they've dropped support for the classic version, and only have the
newer version (I think it dates back to about System 8). They still
support it for printers, and the newer version (I forget what it is,
I want to say Appletalk over IP).
I have some of the Appletalk to Ethertalk bridges, in fact my HP 5MP
printer is plugged into one. I actually view this as one of the
pieces of hardware that needs to be removed from my network in order
to get away from Appletalk.
I'm actually looking to be able to talk
classic Appletalk via an
emulator rather than TCP/IP. Mac OS X handles TCP/IP just fine, so
unless I'm trying to run my rather antiquated version of eXodus
(X-Windows) I personally don't have a need, though I could probably
find one :^)
You could either get an AppleTalk to EtherTalk bridge. I think
Faralon
made those. Actually, I have one of those that I have never been able
to get working, if you want it contact me offlist and I'll try to locate
it. May I ask, what do you want to do with LocalTalk?
My PowerBook 540c still runs System 7, and I don't see any reason to
upgrade it, nor is it desirable. My OpenVMS 7.3-2 is still running
Appletalk as well, it serves up Appletalk volumes and prints via
Appletalk. It is also my big reason for needing Appletalk, and the
biggest reason I really need to get off of it. If I was fully
patched, Appletalk would break, and if I upgrade it breaks.
To get off of it though I need to put an ethernet-to-parallel box in
place. I have several and have had one for at least 6+ years, the
problem here is that the existing solution simply works. Plus as
crazy as it sounds, part of the holdup is a parallel cable, I know I
have several, but am not sure where they are, and I refuse to waste
the money on another one. Still, the big problem is that Appletalk
is the best way to access the data on my VMS box from my Mac.
Neither Samba or NFS work as well. Since staying with Appletalk is
keeping me on older versions of both OpenVMS and Mac OS X, I really
need to find a good resolution to the file sharing issue.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
8:26 a.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
When I say classic Appletalk, I'm actually talking
about over
ethernet, while Mac OS X still supports Appletalk over Ethernet
they've dropped support for the classic version, and only have the
newer version (I think it dates back to about System 8). They still
support it for printers, and the newer version (I forget what it is,
I want to say Appletalk over IP).
AFP over TCP?
--
--------------------------------- personal: http://www.armory.com/~spectre/ ---
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- FORTUNE: Travel is important today. The IRS will arrive tomorrow. ----------
21 Aug
21 Aug
5:07 p.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
Ray Arachelian wrote:
see: http://basilisk.cebix.net/#download and
http://www.users.bigpond.com/pear_computers/ and
http://www.gibix.net/dokuwiki/en:projects:basilisk2#downloads ).
http://minivmac.sourceforge.net/ <- emulator here.
http://www.rolli.ch/MacPlus <- Ancient Mac OS software
I've recently run across this on OS News:
http://www.gibix.net/dokuwiki/en:projects:sheepshaver
(article about the above:
http://www.uneasysilence.com/archive/2006/08/7352/ )
It's an Open Source PowerPC Mac emulator that will run classic Mac OS
software, even on Intel machines. There are windows, Mac OS X (fat
binary) and linux builds available.
Enjoy.
10:35 p.m.
New subject: Classic Mac emulation (was Re: Microkernels (WAS RE: New to the list.))
At 8:07 PM -0400 8/21/06, Ray Arachelian wrote:
I've recently run across this on OS News:
http://www.gibix.net/dokuwiki/en:projects:sheepshaver
(article about the above:
http://www.uneasysilence.com/archive/2006/08/7352/ )
It's an Open Source PowerPC Mac emulator that will run classic Mac OS
software, even on Intel machines. There are windows, Mac OS X (fat
binary) and linux builds available.
Enjoy.
I saw that as well today, but am not sure where I have all of my
"classic" CD's. I've gotten as far as getting it to complain I was
trying to boot to old of a version of the OS. Does anyone have any
experience with it? How is the frame rate? I really like the look
of Sheepshaver, it looks to be just what I'm after. Didn't it
originally run on the Amiga? ISTR, having it on my A3000.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
5 Aug
5 Aug
5:58 p.m.
Zane H. Healy wrote:
Well it's not like your Mac is going to just stop working anytime
soon. If you really need Classic-only apps, you could even pick up an
old 7600/8600/9600-ish machine to dedicate to them.
-Dave
--
Dave McGuire
Cape Coral, FL
Yes. MacOS
"Classic" needs to die, die, die.
You going to be the one to get companies like Apple to port all the
Classic apps that haven't been updated in half of forever (i.e. still
68k)? Some of us have applications that there is no modern equivalent
of. Sadly the solution needs to be a well integrated 3rd party emulator
for the newer systems :^( 
6:01 p.m.
Dave McGuire wrote:
Zane H. Healy wrote:
Well it's not like your Mac is going to just stop working anytime
soon. If you really need Classic-only apps, you could even pick up an
old 7600/8600/9600-ish machine to dedicate to them.
Speaking of Macs...
I've inherited a beige G3 (?) and an 840AV (?).
Any suggestions as to what I should install on them?
Yes.
MacOS "Classic" needs to die, die, die.
You going to be the one to get companies like Apple to port all the
Classic apps that haven't been updated in half of forever (i.e. still
68k)? Some of us have applications that there is no modern equivalent
of. Sadly the solution needs to be a well integrated 3rd party
emulator for the newer systems :^( 
10:12 p.m.
----- Original Message -----
From: "Don" <THX1138 at dakotacom.net>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Saturday, August 05, 2006 9:01 PM
Subject: Re: Microkernels (WAS RE: New to the list.)
Speaking of Macs...
I've inherited a beige G3 (?) and an 840AV (?).
Any suggestions as to what I should install on them?
On the 840AV I guess it depends on what is installed in the unit hardware
wise and what you like to do. I have Mac OS 8.1 on my 840AV and use it for
video capture, but it will do many other 68K era tasks just fine (since it
is the fastest stock 68K Mac made).
6 Aug
6 Aug
10:49 p.m.
Teo Zenios wrote:
----- Original Message -----
From: "Don" <THX1138 at dakotacom.net>
Thanks! I'll see what it currently has installed once
I get the other machines out of the way.
Any suggestions for the G3?
Speaking of Macs...
I've inherited a beige G3 (?) and an 840AV (?).
Any suggestions as to what I should install on them?
On the 840AV I guess it depends on what is installed in the unit hardware
wise and what you like to do. I have Mac OS 8.1 on my 840AV and use it for
video capture, but it will do many other 68K era tasks just fine (since it
is the fastest stock 68K Mac made).
11:14 p.m.
----- Original Message -----
From: "Don" <THX1138 at dakotacom.net>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Monday, August 07, 2006 1:49 AM
Subject: Re: Microkernels (WAS RE: New to the list.)
I believe a beige G3 needs mac OS 8.1 or greater, check the information on
www.lownedmac.com for specs. if you like the 840av join the www.68kmla.net
forum, there are plenty of people there that use 68K and PPC apps (I am
Unknown__K on the forum).
My interests are in 68K Macs mostly, I have a couple PCI PPC Macs for
utility work.
Teo Zenios wrote:
> ----- Original Message -----
> From: "Don" <THX1138 at dakotacom.net>
>> Speaking of Macs...
>>
>> I've inherited a beige G3 (?) and an 840AV (?).
>> Any suggestions as to what I should install on them?
>
> On the 840AV I guess it depends on what is installed in the unit
hardware
> wise and what you like to do. I have Mac OS 8.1
on my 840AV and use it
for
> video capture, but it will do many other 68K era
tasks just fine (since
it
is the fastest
stock 68K Mac made).
Thanks! I'll see what it currently has installed once
I get the other machines out of the way.
Any suggestions for the G3? 
7 Aug
7 Aug
4:04 p.m.
Don wrote:
Any suggestions for the G3?
How about one of the PPC Linuxes? I run Ubuntu on mine.
I needs a bit of subterfuge to get it installed (the
installation/boot disk is meant for New World Macs),
but once it's on there, it runs really well. I used
BootX to get the installation CD to run:
http://www.gifford.co.uk/~coredump/beigeg3.htm
Darnit, I must get a photo of the machine on that page...
--
John Honniball
coredump at gifford.co.uk
4:12 p.m.
John Honniball wrote:
Don wrote:
<wrinkled nose> I would prefer to avoid the Linux world.
Any suggestions for the G3?
How about one of the PPC Linuxes? I run Ubuntu on mine. I needs a bit of subterfuge to get it installed (the
installation/boot disk is meant for New World Macs),
but once it's on there, it runs really well. I used
BootX to get the installation CD to run:
http://www.gifford.co.uk/~coredump/beigeg3.htm
Darnit, I must get a photo of the machine on that page...
Nearest I can tell, putting anything on these boxes
means you *still* need to have a MacOS partition to
boot first?
I'd prefer *not* to have to put a monitor/keyboard on
the machine...
OTOH, I think I have A/UX sitting in my archive (but that;s
only 68K... :< )
6 Aug
6 Aug
1:02 a.m.
Hi,
Don said:
old 7600/8600/9600-ish machine to dedicate to them.
Speaking of Macs...
I've inherited a beige G3 (?) and an 840AV (?).
Any suggestions as to what I should install on them?
Bernhard Baehr's PDP-8 emulator!
http://home.t-online.de/home/bernhard.baehr/pdp8e/pdp8e.html
--
Cheers,
Stan Barr stanb at dial.pipex.com
The future was never like this!
5 Aug
5 Aug
6:13 p.m.
New subject: Classic Mac OS was Re: Microkernels was Re: New to the list.
Well it's not like your Mac is going to just
stop working anytime
soon. If you really need Classic-only apps, you could even pick up an
old 7600/8600/9600-ish machine to dedicate to them.
Yes, but the old "get a separate computer just to run something specific"
solution gets annoying after awhile. My dual G4 is permanently OS 9 to run
the apps Classic won't, but there's something to be said for Classic's
integration into OS X (which, considering the graftwork necessary, is pretty
good). That's why I bought a quad G5, instead of waiting for the Mac Pro --
I still need Classic, and all my apps are PPC anyway.
--
--------------------------------- personal: http://www.armory.com/~spectre/ ---
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- There's an old proverb that says just about whatever you want it to. -------
9:53 p.m.
At 8:58 PM -0400 8/5/06, Dave McGuire wrote:
Well it's not like your Mac is going to just
stop working anytime
soon. If you really need Classic-only apps, you could even pick up
an old 7600/8600/9600-ish machine to dedicate to them.
Anymore I tend to think of three things, space, electrical
consumption, and cooling (my Sunblade 1000 fails on all counts). I
still have a PowerBook 540c (it replaced my 520c), that can run the
key app. Or I can use my 8500/180, or G4/450. The thing is, for
convenience I really need all my DTP apps on one system. At the same
time, I don't plan on moving off my G5 anytime soon, and am not sure
I'll even move off of 10.3.9.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
10:30 a.m.
Segin wrote:
Mac OS X is a fork of FreeBSD, a modern UNIX with
hardware memory
management and protection, preemptive multitasking, complex file systems
and structures, a roburst netowkring API (BSD sockets), etc.
Mac OS X is not, repeat not, a fork of any UNIX. OS X is still a
Mach OS, with a UNIX API based originally on FreeBSD code.
Doc
10:48 a.m.
At 1:41 AM -0400 8/5/06, Segin wrote:
Zane H. Healy wrote:
Run correctly, with carefully selected versions, Mac OS 9 is just as
stable as any version of Windows through the start of Windows XP.
Depending on what you're doing the cooperative multitasking is
actually better than the preemptive multitasking. Moving to Mac OS X
actually resulted in my system not being fast enough to run several
apps.
For me the only advantage to Mac OS X is that I can run the few Unix
applications I need and most of my favorite commercial apps all on
the same box (still need an Alpha for OpenVMS).
Oh, and you might want to read up on what filesystem sits under Mac OS X.
The largest problems with Mac OS X are how inefficient it is, and
it's off/on/off support of classic Appletalk (which some of us still
need, and is why I'm still on 10.3.9 even though I bought 10.4 the
day it was released).
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
I'm still not convinced Mac OS X is that big
of an improvement over
my Mac OS 9 system.
Zane
Mac OS 9 is very similar to Windows 3.1 -- no memory protection,
co-operative multitasking, limited file structures, poor networking,
one-app's-bug-brings-it-all-down, etc.
Mac OS X is a fork of FreeBSD, a modern UNIX with hardware memory
management and protection, preemptive multitasking, complex file
systems and structures, a roburst netowkring API (BSD sockets), etc.
So you are saying that FreeBSD isn't much of an improvement over Windows 3.1?
In terms of function and design, that is.
4 Aug
4 Aug
11:08 p.m.
Scott Quinn wrote:
Speaking of which (and becoming more "on topic"), does (did?) anyone
have any first-hand experience with COOL? Do any archives survive
(or was it all "proprietary"?).
But, one key difference between the QNX approach
and that of
most other current OS's is the microkernel architecture.
Instead of a BIG monolithic kernel with ALL the drivers
installed (or, extra glue for LKM support, etc.), a microkernel
based design treats all of these as components which can be
plugged together. And *talk* to each other (instead of being
invoked "from above").
Yes, you just have the IPC overhead, though.
Not sure if it's IPC or cheaper hardware, but large network operations on my
Macintosh (System 10) bring the machine
much closer to it's knees than any monolithic UNIX or even VMS on a VAX 4000/200. NB
- I haven't used the microkernel
based Tru64 yet.
Microkernels are neat in theory, but a well-trimmed monolithic kernel seems to do pretty
well with not too much space.
11:34 p.m.
On 8/4/2006 at 9:56 PM Scott Quinn wrote:
Microkernels are neat in theory, but a well-trimmed
monolithic kernel
seems to do pretty well with not too much space.
Let me try that again. NT 3.51 and earlier had the video drivers outside
of kernel mode. When 4.0 brought them in as kernel mode, things got quite
a bit faster.
Cheers,
Chuck
11:43 p.m.
Chuck Guzis wrote:
On 8/4/2006 at 9:56 PM Scott Quinn wrote:
Of course! Each time you have to cross a protection domain
you take a performance hit. There's no free lunch.
OTOH, drivers in (the equivalent of) "userland" don't crash the
*system* when they are poorly written!
I really like the microkernel approach for embedded systems.
It just makes things so much more robust (I'll gladly trade
some percentage of the CPU for that overhead and live without
"crumpled paper flying to trash cans" :> ).
And it makes things so much easier to "load balance" in a
multiprocessor design since you just move the thread to
a different processor and let the magic do its thing
(at a nontrivial cost, unfortunately).
Microkernels are neat in theory, but a
well-trimmed monolithic kernel
seems to do pretty well with not too much space.
Let me try that again. NT 3.51 and earlier had the video drivers outside
of kernel mode. When 4.0 brought them in as kernel mode, things got quite
a bit faster. 
5 Aug
5 Aug
5:06 p.m.
It was thus said that the Great Don Y once stated:
Chuck Guzis wrote:
Ten years ago I remember one of the owners of Metrolink (who implemented
and sold commecial X servers) said that the *fastest* X server they sold ran
under QNX, a microkernel.
On 8/4/2006 at 9:56 PM Scott Quinn wrote:
Of course! Each time you have to cross a protection domain
you take a performance hit. There's no free lunch. Microkernels are neat in theory, but a
well-trimmed monolithic kernel
seems to do pretty well with not too much space.
Let me try that again. NT 3.51 and earlier had the video drivers outside
of kernel mode. When 4.0 brought them in as kernel mode, things got quite
a bit faster. And it makes things so much easier to "load
balance" in a
multiprocessor design since you just move the thread to
a different processor and let the magic do its thing
(at a nontrivial cost, unfortunately).
I also worked at a software company porting Unix utilities to QNX and I
really like QNX and what can be done with it. I could use the modem on my
boss' computer to dial out without using *any* special software, just
specify the device on his computer (not only was the file system network
transparent, but you could use devices across the network). You could even
run a program on one computer, pipe the output to another program on another
computer and send the output to a third computer, all from the command line,
and all possible because QNX was built on a microkernel and had all this
functionality built in.
-spc (And the kernel on a Pentium based machine was only 8K
in size ... yes, 8192 bytes in size ... )
5:35 p.m.
Sean Conner wrote:
It was thus said that the Great Don Y once stated:
Exactly. Things are inherently "decomposed" so all you need is
a name service that lets you tag resources ("objects") and
an RPC protocol that extends the local messaging and you
"magically" have a distributed system. By extension, you
can move key threads from one machine to another depending
on how where its I/Os will be located and what percentage
of it's work is CPU bound vs. communication bound.
Sure, you can do the same in a monolithic kernel. But you
have to *add* structure to it to provide these features
and flexibility.
And it makes things so much easier to "load
balance" in a
multiprocessor design since you just move the thread to
a different processor and let the magic do its thing
(at a nontrivial cost, unfortunately).
I also worked at a software company porting Unix utilities to QNX and I
really like QNX and what can be done with it. I could use the modem on my
boss' computer to dial out without using *any* special software, just
specify the device on his computer (not only was the file system network
transparent, but you could use devices across the network). You could even
run a program on one computer, pipe the output to another program on another
computer and send the output to a third computer, all from the command line,
and all possible because QNX was built on a microkernel and had all this
functionality built in.
6:54 p.m.
Sean Conner wrote:
I also worked at a software company porting Unix
utilities to QNX and I
really like QNX and what can be done with it. I could use the modem on my
boss' computer to dial out without using *any* special software, just
specify the device on his computer (not only was the file system network
transparent, but you could use devices across the network). You could even
run a program on one computer, pipe the output to another program on another
computer and send the output to a third computer, all from the command line,
and all possible because QNX was built on a microkernel and had all this
functionality built in.
MicroKernels are very nice, and as of recently they have one huge
advantage (not speed for sure). The
bad guys are now going after flaws in device drivers. Guess what,
device drivers run with full privileges
in most OS's these days and no protection whatsoever. So if you have
some very common driver that
is known to have an exploit - say a common network driver, you'll be
owned that way. With a
microkernel, you can isolate the driver against this. Imagine a
specially crafted ethernet or WiFi frame
that triggers a buffer overlow. :-)
see: http://www.theregister.co.uk/2006/08/04/hackers_bypass_os/ and
http://www.theregister.co.uk/2006/08/03/wifi_driver_hack/
9:31 p.m.
Ray Arachelian wrote:
Sean Conner wrote:
Exactly. All the *cost* of crossing protection domains
has the implied benefit of *enforcing* those protections.
So, maybe the "wifi server" or "ethernet server" dies and
you lose that *capability* -- but the rest of the system
keeps on ticking.
I also worked at a software company porting
Unix utilities to QNX and I
really like QNX and what can be done with it. I could use the modem on my
boss' computer to dial out without using *any* special software, just
specify the device on his computer (not only was the file system network
transparent, but you could use devices across the network). You could even
run a program on one computer, pipe the output to another program on another
computer and send the output to a third computer, all from the command line,
and all possible because QNX was built on a microkernel and had all this
functionality built in.
MicroKernels are very nice, and as of recently they have one huge
advantage (not speed for sure). The
bad guys are now going after flaws in device drivers. Guess what,
device drivers run with full privileges
in most OS's these days and no protection whatsoever. So if you have
some very common driver that
is known to have an exploit - say a common network driver, you'll be
owned that way. With a
microkernel, you can isolate the driver against this. Imagine a
specially crafted ethernet or WiFi frame
that triggers a buffer overlow. :-)
see: http://www.theregister.co.uk/2006/08/04/hackers_bypass_os/ and
http://www.theregister.co.uk/2006/08/03/wifi_driver_hack/
6 Aug
6 Aug
7:28 a.m.
Don wrote:
Ray Arachelian wrote:
Exactly. All the *cost* of crossing protection domains
has the implied benefit of *enforcing* those protections.
So, maybe the "wifi server" or "ethernet server" dies and
you lose that *capability* -- but the rest of the system
keeps on ticking.
Even better, you don't lose that functionality, you restart the driver.
So maybe you lose a few packets, or maybe you have to re-establish your
WPA/WEP session to the AP, which shouldn't take all that long. So it's
the equivalent of a network burp. But likely, your applications
(perhaps even ssh sessions) will keep on working, and you don't get owned.
7:42 a.m.
Ray Arachelian wrote:
Don wrote:
ssh doesn't seem to follow the standard rules of timeouts. I have left a
ssh session idle once for over 3 days, and it still worked.
--
The real problem with C++ for kernel modules is: the language just sucks.
-- Linus Torvalds
Ray Arachelian wrote:
Exactly. All the *cost* of crossing protection domains
has the implied benefit of *enforcing* those protections.
So, maybe the "wifi server" or "ethernet server" dies and
you lose that *capability* -- but the rest of the system
keeps on ticking.
Even better, you don't lose that functionality, you restart the driver.
So maybe you lose a few packets, or maybe you have to re-establish your
WPA/WEP session to the AP, which shouldn't take all that long. So it's
the equivalent of a network burp. But likely, your applications
(perhaps even ssh sessions) will keep on working, and you don't get owned.
7 Aug
7 Aug
9:58 a.m.
ssh doesn't seem to follow the standard rules of
timeouts. I have
left a ssh session idle once for over 3 days, and it still worked.
What "standard rules of timeouts" does that not follow? TCP
connections in general don't get torn down when idle without traffic.
(Most TCP stacks have an option which applications can turn on,
requesting that idle connections get probed every few hours, but as far
as I know they all have it off by default - as is required by RFC-1122
4.2.3.6.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
6 Aug
6 Aug
9:59 a.m.
Ray Arachelian wrote:
Don wrote:
Yes, though you need a daemon watching for that specific purpose.
Ray Arachelian wrote:
Exactly. All the *cost*
of crossing protection domains
has the implied benefit of *enforcing* those protections.
So, maybe the "wifi server" or "ethernet server" dies and
you lose that *capability* -- but the rest of the system
keeps on ticking.
Even better, you don't lose that functionality, you restart the driver. So maybe you lose a few packets, or maybe you have to
re-establish your
WPA/WEP session to the AP, which shouldn't take all that long. So it's
the equivalent of a network burp. But likely, your applications
(perhaps even ssh sessions) will keep on working, and you don't get owned.
Depends on the service, of course. In my world, that service
may be running a motor that drives a leadscrew that positions
a cutting tool, etc. If it's not where it's supposed to be
*when* it's supposed to be there, there can be significant
consequences :-(
Hence the appeal of making sure some OTHER piece of code
doesn't misbehave and cause *this* process to hiccup.
Now, add to this the desire to let the *user*/purchaser
augment the system with their own code -- some of which
may need access to devices in a way that a traditional
approach would necessitate their inclusion in the
(monolithic) kernel and you see how quickly this can
turn into a fingerpointing contest (customer's code
doesn't work; the only way to PROVE that it is not
your liability -- legal or otherwise -- is to debug
his code and point out why it is crashing *your* code).
6697
days inactive
6714
days old
46 comments
17 participants
participants (17)
-
bfranchuk＠jetnet.ab.ca -
brad＠heeltoe.com -
cclist＠sydex.com -
compoobah＠valleyimplants.com -
coredump＠gifford.co.uk -
dgy＠DakotaCom.Net -
doc＠mdrconsult.com -
healyzh＠aracnet.com -
mcguire＠neurotica.com -
mouse＠Rodents.Montreal.QC.CA -
ray＠arachelian.com -
segin2005＠gmail.com -
spc＠conman.org -
spectre＠floodgap.com -
stanb＠dial.pipex.com -
teoz＠neo.rr.com -
THX1138＠dakotacom.net