sysmark@physics.utoronto.ca (Mark Bartelt) (02/15/91)
Earlier this week I wrote ... > We recently got A/UX for one of our MacIIs, and were appalled to discover > that the C compiler isn't X3J11 compliant. The guy who uses that system > sent me the following last night: > > | Horror of horrors! After converting all my beautifully prototyped > | mac interface programs to port over to AUX, I find that the AUX > | compiler is some prehistoric monster that doesn't respect the ANSI > | 'standard'. [ ... ] > [H]ow does > Apple expect to be taken seriously if a recent major release of their > UNIX product doesn't even contain an X3J11 compliant compiler? ... to which Kent Sandvik from Apple replied ... > Well, most of the basic Unix workstation system C compilers are 'prehistoric > mosters' originating from the terrifying, Tyrannosaurus pcc from > the continent of AT&T. Um, I beg to differ. Of the three UNIXes I use most often, two (IRIX from SGI; Ultrix from DEC) provide ANSI compliant C compilers. I can't vouch for the fact that they're 100% in conformance with X3J11, but they do at least support function prototypes. IRIX has had this *at least* since version 3.2, which is copyrighted 1988; I have no idea how long Ultrix has had it. And the two non-UNIX C compilers that I've been using a lot (Microsoft C for (yuck) MS-DOS; Avocet C cross compiler for the 68HC11) are also ANSI compatible. > With the advent of System V.4 AT&T is *finally* > shipping an ANSI C compliant C compiler as part of the UNIX system > release. Righto. But there's no reason Apple has to sit around waiting for AT&T to get its act together, as other vendors have demonstrated. My real concern is more general than just a complaint about A/UX's cc. I get the feeling that Apple doesn't really have much of a commitment to UNIX. Ten or so years ago, DEC had a small (tiny!), but talented and dedicated UNIX group, before the company even had an "official" UNIX product. And they had a couple of managers with the foresight to realize that the company should push forward with UNIX, and the sooner the better. Unfortunately, most of DEC's management spent most of their energy trying to fight and suppress the UNIX groundswell (coming both from customers and from within their own company), rather than making a strong and unequivocal commitment to supporting UNIX. Finally, Ultrix seems to have succeeded, despite the attitude of DEC's upper management. But it was a long time coming, and during the 1980s DEC lost a lot of sales, due largely to a perception on the part of its customers and its potential customers that the company lacked a strong commitment to provide a top-quality UNIX product. My worry is that this is exactly the position that Apple is in now. I don't doubt that the A/UX group has some really good people in it, both techies and managers. But I can't shake the nagging suspicion that they're both unappreciated by the rest of the company, and most likely badly underfunded as well. After all, the fact that A/UX 2.0 (a *recent* product) arrived lacking a modern C compiler is certainly symptomatic of something. I hope that my fears are unfounded, and that someone from Apple can reassure me. But if my suspicion is correct, it's bad news for those people who want to use A/UX, since it means that a lack of internal support for the folks who write, improve, maintain, and document A/UX will ensure that Apple's UNIX product will always lag behind the others. Mark Bartelt 416/978-5619 Canadian Institute for sysmark@cita.toronto.edu Theoretical Astrophysics sysmark@cita.utoronto.ca
coolidge@cs.uiuc.edu (John Coolidge) (02/15/91)
sysmark@physics.utoronto.ca (Mark Bartelt) writes: >> Well, most of the basic Unix workstation system C compilers are 'prehistoric >> mosters' originating from the terrifying, Tyrannosaurus pcc from >> the continent of AT&T. >Um, I beg to differ. Of the three UNIXes I use most often, two (IRIX from >SGI; Ultrix from DEC) provide ANSI compliant C compilers. I can't vouch >for the fact that they're 100% in conformance with X3J11, but they do at >least support function prototypes. IRIX has had this *at least* since >version 3.2, which is copyrighted 1988; I have no idea how long Ultrix >has had it. I've been using about 7 major and semi-major unix variants for the last few years; most are still using pcc-derived compilers as their base. I agree that the time to ANSI-fy is now; I'm very tempted to say that people shouldn't worry about compilers anymore and just use GCC (or produce an even better freely available compiler :-)); the time for single-vendor compilers is mostly long gone (there are exceptions, such as the excellent MIPS compiler DEC provides with Ultrix, but I suspect that eventually even they will be passed by a compiler that literally hundreds of talented people are banging on). >My real concern is more general than just a complaint about A/UX's cc. >I get the feeling that Apple doesn't really have much of a commitment >to UNIX. Ten or so years ago, DEC had a small (tiny!), but talented >and dedicated UNIX group, before the company even had an "official" >UNIX product. And they had a couple of managers with the foresight to >realize that the company should push forward with UNIX, and the sooner >the better. Unfortunately, most of DEC's management spent most of their >energy trying to fight and suppress the UNIX groundswell (coming both >from customers and from within their own company), rather than making >a strong and unequivocal commitment to supporting UNIX. My opinion is that this is what's been going on in Apple (of course, I'm on the outside looking in, and the people at Apple may see things differently). From what I've seen, A/UX has gone through three distinct stages: 1.0: "The Feds want Unix, and we'll give it to 'em - grudgingly!" I used 1.0 for a very short while; it was quite painful to use for lots of things, and fortunately 1.1 came along quickly. 1.1: "Well, if we have to do it let's at least do it right." A/UX 1.1 (probably should have been 2.0 - it was that much better than 1.0) was a very usable Unix platform. It ran rings around systems from Unix-only vendors and was easily the best OS I've ever seen with a 1.x version number. 2.0: "OK, if we're going to do it right let's go all the way". 2.0 added scads of features to 1.1; the most useful, I think, have been the MacOS mode (I tend to use lots of MacOS tools as well as Unix), shared libraries, and the UFS file system. Unfortunately, as with any feature-driven release, there have been problems. Hopefully 2.0.1 will fix them. Basically what this boils down to is that the A/UX project started off as, basically, a quick hack to comply with federal purchasing requirements. After a while, it turned out that people were actually buying it and using it, and things had to be made usable, so money and people got added to the project and things evolved a bit. Then, after a bit more settling, someone decided that A/UX was a good idea after all and 2.0 was born. If you'd been in the Bay Area last summer, you would have seen full-page advertisements from Apple looking to fill gobs of positions in the A/UX group. Based on that evidence, and the amount of activity and support I've seen on the net, it looks like Apple has decided to make a major, long-term commitment to A/UX. But my guess would be that that commitment started somewhere in early 1989; that's really not a long time to make major steps in upgrading a product. Even as things go, though, our findings have pretty much been that A/UX 2.0 is the most interoperable Unix platform (outside of SunOS, which pretty much for better or for worse sets the standard) we've seen. It works well in a network environment, is very usable and (mostly) stable, and provides a mostly good set of tools. Of course, I also don't touch cc anymore, pretty much ignore as, use the Gnu fileutils since I can't stand some of the SYSVisms, and so forth. But that's also not much of a slam --- I've found at least one or two commands and "features" in other Unixes that I've replaced as soon as possible. All in all, I suppose the biggest complaint we have about A/UX is that it only runs on Apple platforms (:-)) --- there are a lot of faster boxes around here that no one will use unless forced to (and we're not talking MacOS fanatics here, either --- about half of them are Unix-only types who don't like Macs). A/UX is better than most of the Unixes I've seen out there; with some time and effort, I believe it will be one of the best, maybe even _the_ best. --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1991 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well.
kevinh@cmi.com (Kevin Hegg) (02/15/91)
Mark Bartelt writes My real concern is more general than just a complaint about A/UX's cc. I get the feeling that Apple doesn't really have much of a commitment to UNIX. Ten or so years ago, DEC had a small (tiny!), but talented.... I am also concerned about Apple's commitment to Unix. They are very much behind the rest of the Unix community. The feeling I get from Apple these days is "Don't worry, we know whats best for you". That attitude is fine when you can keep pace with the rest of the community. However, over the last couple of years Apple seems less and less capable of doing this. Another concern I have is Apple's suppresion of information on Mach for the Mac. Here's what I have heard. CMU ported Mach to all Mac II's except the ci and fx. Apple took it from there and is possibly negotiating with mt. xinu for distribution rights. OK Apple, what are you going to do? Are we going to see a commercial product with Mach? If not, how about relaxing your stranglehold on Mach. I started using the Mac about 6 years ago because you could feel that it was going to have a strong impact on the computer world. It was fun to be involved with something that was towards the leading edge. I think a lot of people gravitated towards the Mac for this reason. I think a lot of people will gravitate away from the Mac if this ceases to be true. Solving problems that the rest of the Unix community has already solved doesn't top my list of fun things to do. I don't mean to make this an Apple bashing session. There are a lot of things that I like about Macs. I still use the Mac as my primary computer, but I find myself using other ones more and more. Kevin Hegg, EDS Corp - Center for Machine Intelligence 2001 Commonwealth Blvd., Ann Arbor, Michigan 48105 Phone: (313) 995-0900 Internet: kevinh@cmi.com Applelink: D5990
jim@jagubox.gsfc.nasa.gov (Jim Jagielski) (02/16/91)
Hell, I might as well put my 2 cents worth in... In article <8570@etsu.CMI.COM> kevinh@cmi.com (Kevin Hegg) writes: }Mark Bartelt writes } My real concern is more general than just a complaint about A/UX's cc. } I get the feeling that Apple doesn't really have much of a commitment } to UNIX. Ten or so years ago, DEC had a small (tiny!), but talented.... } }I am also concerned about Apple's commitment to Unix. They are very much }behind the rest of the Unix community. Well, I wouldn't say that they are "very much behind" the others. True, A/UX is based on V.2, but it DOES have alot of the functionality of V.3 due to its "enhancements." I personally believe that if worked on a straight V.2 or V.3 machine (or straight BSD), you'd miss some of A/UX's perks. IMHO A/UX is a very nice merging of the two systems with minimal fuss. As a point of record, AIX (IBM RISC UNIX :) also is a nice marriage; I don't like the MIPS approach which is simply to have two sets (AT&T and BSD) of libraries, executables, etc... I LIKE the MacOS interface, so as far as GUI's are concerned, I feel that Apple is at-the-least trying to keep pace. Although it is true that many GUI's are very jazzy (SGI for one) in a lot of way's it's a personal preference. } The feeling I get from Apple these }days is "Don't worry, we know whats best for you". That attitude is fine }when you can keep pace with the rest of the community. However, over the }last couple of years Apple seems less and less capable of doing this. As far as A/UX is concerned, I think that they fulfilled A LOT of wishes with 2.0. I DO wish that Apple had higher-powered platforms, so in this case, they are lagging behind the other Unix boxes. } }Another concern I have is Apple's suppresion of information on Mach for }the Mac. Here's what I have heard. CMU ported Mach to all Mac II's except }the ci and fx. Apple took it from there and is possibly negotiating with }mt. xinu for distribution rights. OK Apple, what are you going to do? Are }we going to see a commercial product with Mach? If not, how about relaxing }your stranglehold on Mach. Yeah, it's hard to remember that this is the same company that included the entire ROM code of the Apple][ IN THE MANUAL! And just look at OnBoard... } }I started using the Mac about 6 years ago because you could feel that it }was going to have a strong impact on the computer world. It was fun to be }involved with something that was towards the leading edge. I think a lot }of people gravitated towards the Mac for this reason. I think a lot of }people will gravitate away from the Mac if this ceases to be true. Solving }problems that the rest of the Unix community has already solved doesn't }top my list of fun things to do. I don't mean to make this an Apple }bashing session. There are a lot of things that I like about Macs. I still }use the Mac as my primary computer, but I find myself using other ones }more and more. Well, there are times when I need more performance too, and that's when I hit a SGI or VAX or whatever. But I also use my Mac (running A/UX) for about 98% of my work... Once the 68040 Mac comes out, that should be close to 100%. Hard to believe that I've got the equivalent of several 780's on my desk and just a few years ago (okay, maybe 7 or so) I thought the speed of a VAX was incredible! Man, I remember running Unix on a PDP-11/45 (64K, of course :) and LOVING it! What "problems" that have been solved in the community but not on the Mac are you speaking about? If you mention them then: 1. The may have been fixed, either by Apple or elsewhere and therefore be available to you 2. The problem will be known and then it can be worked on Have you tried porting stuff to the IBM-6000? Or Next? In ALL cases, there will be problems that need to be resolved and other cases which shouldn't even be problems... alas, nothing's perfect. Now don't get me wrong, I'm not an Apple employee in disguise :). I wish that the Macs were cheaper and faster and more powerful. Not everything that Apple does sits well with me. But, God Help Me, I really enjoy my Mac and I am impressed with A/UX. Yeah, I got a "wish list" of improvements and a list of "grudges", but I'd have that with ANY machine. But, I choose my Mac. I simply like it. It does what I want, the way I want and doesn't get in my way too often... for me, that's enough. Boy oh boy... am I gonna get feedback about this :):):) -- ======================================================================= #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagubox.gsfc.nasa.gov Greenbelt, MD 20771 "Exploding is a perfectly normal medical phenomenon. In many fields of medicine nowadays, a dose of dynamite can do a world of good."
ksand@Apple.COM (Kent Sandvik) (02/16/91)
In article <1991Feb14.204018.4351@helios.physics.utoronto.ca> sysmark@cita.utoronto.ca writes: >My worry is that this is exactly the position that Apple is in now. >I don't doubt that the A/UX group has some really good people in it, >both techies and managers. But I can't shake the nagging suspicion >that they're both unappreciated by the rest of the company, and most >likely badly underfunded as well. After all, the fact that A/UX 2.0 >(a *recent* product) arrived lacking a modern C compiler is certainly >symptomatic of something. Gosh, I hope someone read the last cryptic sentence in my earlier entry... >I hope that my fears are unfounded, and that someone from Apple can >reassure me. But if my suspicion is correct, it's bad news for those >people who want to use A/UX, since it means that a lack of internal >support for the folks who write, improve, maintain, and document A/UX >will ensure that Apple's UNIX product will always lag behind the others. Speaking from experience from another company where I started working with UNIX, in which the word 'UNIX' was considered a dirty word (won't mention the company but it has nowadays unfortunately to do with the power of two), it takes an awful long time before the concept of UNIX and open systems are accepted in the whole-whole company, from bottom up. We speak about 6-10 years usually. Compared with the other company the UNIX people inside Apple have relatively free hands and a good budget, but these are my own opinions based on experiences about politics inside American computer companies. Regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++ is a write-only language, I can write programs in C++ but I can't read any of them".
shwake@raysnec.UUCP (Ray Shwake) (02/19/91)
kevinh@cmi.com (Kevin Hegg) writes: >Another concern I have is Apple's suppresion of information on Mach for >the Mac. Here's what I have heard. CMU ported Mach to all Mac II's except >the ci and fx. Apple took it from there and is possibly negotiating with >mt. xinu for distribution rights. OK Apple, what are you going to do? Are >we going to see a commercial product with Mach? If not, how about relaxing >your stranglehold on Mach. The A/UX operating environment is far more comprehensive than simply providing a kernel and utilities. Its ability to support both UNIX and Mac applications simultaneously without resort to emulation is certainly remarkable. Unless the alleged Mach ports can offer something comparable there's little reason to choose it over A/UX. As to the "suppression of information" and "stranglehold on Mach" I can only suggest you try to control your paranoia. Unless you can provide evidence to the contrary, consider that superior technology usually wins out in the end. ----------- uunet!media!ka3ovk!raysnec!shwake shwake@rsxtech
d88-jwa@byse.nada.kth.se (Jon W{tte) (02/20/91)
In article <250@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >simply providing a kernel and utilities. Its ability to support both >UNIX and Mac applications simultaneously without resort to emulation is >certainly remarkable. Unless the alleged Mach ports can offer something >comparable there's little reason to choose it over A/UX. Well, from what I've heard, the Mach port actually DID support mac apps - and as separate processes per app, at that ! Oh, and this "virtual" mac wasn't as doggy as A/UX is (My fx feels like a II :-( macwise. Jon "The IM-IV file manager chapter documents zillions of calls, all of which seem to do almost the same thing and none of which seem to do what I want them to do." -- Juri Munkki in comp.sys.mac.programmer
abm@alan.aux.apple.com (Alan Mimms) (02/21/91)
In article <1991Feb20.082410.20817@nada.kth.se>, d88-jwa@byse.nada.kth.se (Jon W{tte) writes: |> In article <250@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: |> |> >simply providing a kernel and utilities. Its ability to support both |> >UNIX and Mac applications simultaneously without resort to emulation is |> >certainly remarkable. Unless the alleged Mach ports can offer something |> >comparable there's little reason to choose it over A/UX. |> |> Well, from what I've heard, the Mach port actually DID support mac |> apps - and as separate processes per app, at that ! Oh, and this |> "virtual" mac wasn't as doggy as A/UX is (My fx feels like a II :-( |> macwise. .Would you like to expound on what you found "doggy"? I use an FX on System 6.0.5, System 7.0, and A/UX 2.0.1, and find them all to be comparable in performance. (This is allowing for the A/UX filesystem cache to be initialized -- second and third times through are quite fast.) Perhaps you're trying to run A/UX on a tiny memory machine (4MB is not really the best light to view A/UX in)? I'm not trying to be combative -- I (we) would like to know what's wrong so we can fix it or help you to use it in a way that shows off A/UX's best qualities... |> |> Jon |> |> "The IM-IV file manager chapter documents zillions of calls, all of which |> seem to do almost the same thing and none of which seem to do what I want |> them to do." -- Juri Munkki in comp.sys.mac.programmer -- Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally A/UX X group | pretty worthless, but Apple Computer | they *are* my own... "Laugha whila you can, monkey boy..." -- John Whorfin in Buckaroo Banzai "Never rub another man's rhubarb" -- The Joker in BatMan
steveg@ni.umd.edu (Steve Green) (02/21/91)
In article <12183@goofy.Apple.COM> abm@alan.aux.apple.com (Alan Mimms) writes: >[deleted] >I'm not trying to be combative -- I (we) would like to know what's wrong >so we can fix it or help you to use it in a way that shows off A/UX's best >qualities... >[deleted] I have heard that before. Before this turns into a flame-a-thon, I will say that I love A/UX and I defend it often but this area is a sore point to me. Last time I heard the "tell us what is wrong" song, I did and I still cant use NFS reliably. (9 months ago I reported the problem in 2.0b9) Maybe its just me but I feel that a faulty NFS implementation is a MAJOR problem. (Hey Bob, remember me?) aux.support.apple.com:aux.patches/ USE IT! -- Silica gel -- No not eat. steveg@ni.umd.edu
d88-jwa@dront.nada.kth.se (Jon W{tte) (02/22/91)
In article <12183@goofy.Apple.COM> abm@alan.aux.apple.com (Alan Mimms) writes: >.Would you like to expound on what you found "doggy"? I use an FX on >System 6.0.5, System 7.0, and A/UX 2.0.1, and find them all to be The 24bit environment under A/UX, compiling using THINK C, is slower than on an SE/30 - _definately_ slower than on a "plain" IIfx. (FYI: this was while compiling the TCL, lots of tiny files including lots of headers, though the headers stay the same all the time) >Perhaps you're trying to run A/UX on a tiny memory machine (4MB is not >really the best light to view A/UX in)? 8MB, and from what I see (and hear :-) there+s no paging nor (gosh) swapping. >I'm not trying to be combative -- I (we) would like to know what's wrong >so we can fix it or help you to use it in a way that shows off A/UX's best >qualities... Oh, and this is using Berkley file systems on two quantum 80 megs - fast search, not-so-fast transfer. But anyway, I don't think memory is the problem here. >Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally Maybe splitting the project file in two files would speed things up. How slow is the "apple single" format ? h+ "The IM-IV file manager chapter documents zillions of calls, all of which seem to do almost the same thing and none of which seem to do what I want them to do." -- Juri Munkki in comp.sys.mac.programmer
abm@alan.aux.apple.com (Alan Mimms) (02/22/91)
In article <1991Feb21.031529.4498@ni.umd.edu>, steveg@ni.umd.edu (Steve Green) writes: |> In article <12183@goofy.Apple.COM> abm@alan.aux.apple.com (Alan Mimms) writes: |> >[deleted] |> >I'm not trying to be combative -- I (we) would like to know what's wrong |> >so we can fix it or help you to use it in a way that shows off A/UX's best |> >qualities... |> >[deleted] |> |> I have heard that before. |> |> Before this turns into a flame-a-thon, I will say that I love A/UX and I |> defend it often but this area is a sore point to me. |> |> Last time I heard the "tell us what is wrong" song, I did and I still cant |> use NFS reliably. (9 months ago I reported the problem in 2.0b9) Maybe its |> just me but I feel that a faulty NFS implementation is a MAJOR problem. |> (Hey Bob, remember me?) aux.support.apple.com:aux.patches/ USE IT! Excuse me, Steve, but I want to find out if there is something strange about your NFS usage. We here (as you might expect) have several HUNDRED A/UX machines, all happily using NFS to mount things from a Cray, several VAXen, a Solbourne, several Suns, DECstations, R6000s, Motorola Unix boxes, and a host of others (including, of course, lots of A/UX machines). I haven't heard anyone complain that NFS is unreliable in A/UX 2.0 or 2.0.1. Is it possible there's something unusual about your site or how you're using NFS that causes problems? I'm NOT trying to debug your problem, although I will happily attempt it if you contact me. I AM trying to say that A/UX NFS is NOT FLAKEY. I value HIGHLY feedback from customers about things we can do better -- MacX 1.1 is a LOT better than MacX 1.0 and future versions will address lots of other issues customers have raised "that would be nice". BUT, I don't want people who are considering using or buying A/UX to get the idea that EVERYONE has trouble with NFS on A/UX: it just ain't so. |> -- |> Silica gel -- No not eat. steveg@ni.umd.edu -- Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally A/UX X group | pretty worthless, but Apple Computer | they *are* my own... "Laugha whila you can, monkey boy..." -- John Whorfin in Buckaroo Banzai "Never rub another man's rhubarb" -- The Joker in BatMan
ksand@Apple.COM (Kent Sandvik) (02/22/91)
>In article <1991Feb21.031529.4498@ni.umd.edu>, steveg@ni.umd.edu (Steve Green) writes: >|> Last time I heard the "tell us what is wrong" song, I did and I still cant >|> use NFS reliably. (9 months ago I reported the problem in 2.0b9) Maybe its >|> just me but I feel that a faulty NFS implementation is a MAJOR problem. >|> (Hey Bob, remember me?) aux.support.apple.com:aux.patches/ USE IT! Hi, speaking as a former tech support person, questions like these are very hard to follow up - without any kinds of examples/tests/proof/ configuration and so on. For instance, what kind of load do you have on the network? Is it the server or the client side that's bad? What revisions on Ethernet cards? Apple Ethernet cards? What kind of network configutation do you have, what kinds of machines/OS are connected to the network? Broadcast storms? Issues such as this would certainly give a better answer on c.u.aux. Regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++ was given to mankind, so that we might learn patience"
steveg@ni.umd.edu (Steve Green) (02/22/91)
Alan Mimms (alan@apple.com) writes: >Excuse me, Steve, but I want to find out if there is something strange >about your NFS usage. We here (as you might expect) have several HUNDRED >A/UX machines, all happily using NFS to mount things from a Cray, several >VAXen, a Solbourne, several Suns, DECstations, R6000s, Motorola Unix boxes, >and a host of others (including, of course, lots of A/UX machines). >I haven't heard anyone complain that NFS is unreliable in A/UX 2.0 or >2.0.1. Is it possible there's something unusual about your site or how >you're using NFS that causes problems? Not one bit possible. Could it be that the problem is fixed in-house but not made available to customers?? >I'm NOT trying to debug your problem, although I will happily attempt it >if you contact me. I AM trying to say that A/UX NFS is NOT FLAKEY. YES IT IS!!!! A/UX NFS is very flakey. I cannot reliably compile ANYTHING on an NFS disk. >[deleted] I am totaly insulted by your response. I have sent countless messeges to reports@renew with problem descriptions and scripts that demonstrate the problem. I have mail from someone on the A/UX development team that confirms the problem I complained about and said "we are looking into a fix for this". As well, Some time ago, John L. Coolidge coolidge@cs.uiuc.edu writes: >I've got this one... most of the time. When compiling to disks from >the Encore server, I get bad links (the link finishes cleanly, but >the resulting image is damaged, often in strange and interesting >ways). On the other hand, when the remote server is a Sun or an A/UX >machine, I've never seen this problem. > >The problem doesn't happen with small programs: hello world works >10 out of 10. Big programs (nn, gcc, g++, etc) always fail. What else do you want to know? -- Silica gel -- No not eat. steveg@ni.umd.edu
urlichs@smurf.sub.org (Matthias Urlichs) (02/22/91)
In comp.unix.aux, article <250@raysnec.UUCP>,
shwake@raysnec.UUCP (Ray Shwake) writes:
<
< The A/UX operating environment is far more comprehensive than
< simply providing a kernel and utilities. Its ability to support both
< UNIX and Mac applications simultaneously without resort to emulation is
< certainly remarkable. Unless the alleged Mach ports can offer something
< comparable there's little reason to choose it over A/UX.
<
It offers something better -- one process (thread, whatever) per Mac program,
not all Mac applications running under MultiFinder and blocking each other.
"Real Multitasking", and all that.
Calling WaitNextEvent between sending/receiving every message is just too
slow for some classes of distributed applications.
Remember that Mach is a new OS which has lots of very interesting features.
You probably won't ever find these features on SysV- or BSD-based Unixes.
Read comp.os.mach for details.
< As to the "suppression of information" and "stranglehold on Mach"
< I can only suggest you try to control your paranoia. Unless you can provide
< evidence to the contrary, consider that superior technology usually wins
< out in the end.
<
So please would someone tell what happened, what the current status is,
and what's been done about it?
Without that information, I'll stick to the paranoia theory. :-)
Actually, what I'd like to do is take the Mach 3.0 kernel that's freely
available, combine it with the Mach 2.5 Unix server and the [object or,
preferably, source] code to make it run on the Mac, and hack away.
This seems to be possible with some other Mach versions, so I honestly don't
see what the problem is. Someone "in the know" please enlighten me...
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) (02/23/91)
In article <1991Feb21.202509.11608@ni.umd.edu> steveg@ni.umd.edu (Steve Green) writes: >Alan Mimms (alan@apple.com) writes: >>Excuse me, Steve, but I want to find out if there is something strange >>about your NFS usage. We here (as you might expect) have several HUNDRED >>A/UX machines, all happily using NFS to mount things from a Cray, several >>VAXen, a Solbourne, several Suns, DECstations, R6000s, Motorola Unix boxes, >>and a host of others (including, of course, lots of A/UX machines). >>I haven't heard anyone complain that NFS is unreliable in A/UX 2.0 or >>2.0.1. Is it possible there's something unusual about your site or how >>you're using NFS that causes problems? > >Not one bit possible. Could it be that the problem is fixed in-house but >not made available to customers?? > Isn't it possible that Steve is using NFS in an entirely legitimate and not very unusual manner that the A/UX group has not replicated? Alan, your position seems tantamount to the claim that the A/UX group has replicated and thoroughly tested every legitimate and non-unusual NFS usage and found no problems. I don't believe you actually mean that. >>I'm NOT trying to debug your problem, although I will happily attempt it >>if you contact me. I AM trying to say that A/UX NFS is NOT FLAKEY. > >YES IT IS!!!! A/UX NFS is very flakey. I cannot reliably compile >ANYTHING on an NFS disk. Well, I won't say "flakey" since the word isn't very precise and is highly incendiary, but: I work with several other programmers on an X windows application that currently runs on Macintoshes w/ A/UX, DECstations, VAXstations, Sun 3/xx's, Sun SPARCstations, RISC/6000s, and PS/2s w/ AIX. The only way to maintain this application is to use the same source files for all of these different platforms, and to NFS-mount the source directory wherever it is needed. Currently, the source resides on a DECstation hard disk. Below the source directory is a subdirectory for each platform; compiler output (i.e. `.o' files) and the linked application go into the appropriate subdirectory. This strategy works admirably for every machine but (you guessed it) the Macintosh. In order to get the Macintosh version to work, I must compile and link on a non-NFS disk. (Actually, I've never tried compiling on NFS disks and then linking on local disk, too much work.) My conclusion is that A/UX 2.0's NFS is in some way incompatible with NFS on the DECstation, but I don't know enough about NFS to be more precise. I've had several people offer impromptu explanations/rationalizations, but nothing I felt was truly definitive. I have reported this before, but I will do so again if requested. Ken Lindahl lindahl@violet.berkeley.edu Advanced Technology Planning, Information Systems and Technology University of California at Berkeley
abm@alan.aux.apple.com (Alan Mimms) (02/23/91)
In article <1991Feb21.202509.11608@ni.umd.edu>, steveg@ni.umd.edu (Steve Green) writes: |> Alan Mimms (alan@apple.com) writes: |> >Excuse me, Steve, but I want to find out if there is something strange |> >about your NFS usage. We here (as you might expect) have several HUNDRED |> >A/UX machines, all happily using NFS to mount things from a Cray, several |> >VAXen, a Solbourne, several Suns, DECstations, R6000s, Motorola Unix boxes, |> >and a host of others (including, of course, lots of A/UX machines). |> >I haven't heard anyone complain that NFS is unreliable in A/UX 2.0 or |> >2.0.1. Is it possible there's something unusual about your site or how |> >you're using NFS that causes problems? |> |> Not one bit possible. Could it be that the problem is fixed in-house but |> not made available to customers?? |> |> >I'm NOT trying to debug your problem, although I will happily attempt it |> >if you contact me. I AM trying to say that A/UX NFS is NOT FLAKEY. |> |> YES IT IS!!!! A/UX NFS is very flakey. I cannot reliably compile |> ANYTHING on an NFS disk. Steve, I was NOT trying to contest that YOU are having trouble with NFS on A/UX. I was trying to say that NOT EVERYONE DOES. I don't. I routinely compile and link every part of the X Window System, which is VERY LARGE, via NFS on my A/UX machine and I never see any problems at all. |> >[deleted] |> |> I am totaly insulted by your response. I have sent countless messeges |> to reports@renew with problem descriptions and scripts that demonstrate |> the problem. I have mail from someone on the A/UX development team that |> confirms the problem I complained about and said "we are looking into a |> fix for this". As well, I'm sorry you feel insulted. That was NOT my intention. I wanted to try to make sure both sides of the story got told -- you can't possibly know that A/UX NFS works for some people, and people who just read your story won't know either. I was not aware of the conversations you have had with our technical support folks or with the internal developer person. |> Some time ago, John L. Coolidge coolidge@cs.uiuc.edu writes: |> >I've got this one... most of the time. When compiling to disks from |> >the Encore server, I get bad links (the link finishes cleanly, but |> >the resulting image is damaged, often in strange and interesting |> >ways). On the other hand, when the remote server is a Sun or an A/UX |> >machine, I've never seen this problem. |> > |> >The problem doesn't happen with small programs: hello world works |> >10 out of 10. Big programs (nn, gcc, g++, etc) always fail. |> |> What else do you want to know? |> |> -- |> Silica gel -- No not eat. steveg@ni.umd.edu Let's try to solve your problem -- apparently several sites are having it. I'm not an NFS guru, but I sit next to one. Maybe I can help. I WANT TO. First, what type of Ethernet card are you using? What board revision level is it? What kind of CPU and what version of A/UX? What, exactly, are the circumstances (i.e., server machine type, etc.) under which you see a failure? How much memory do you have? What other useful information can you supply about the problem? What kinds of operations fail to work properly? PLEASE DON'T GIVE UP ON APPLE AND A/UX. Just because you sent in a bug report and DIDN'T get satisfaction DOESN'T mean you CAN'T get satisfaction. This is (unfortunately) a big company and we DO make mistakes (boy, do we ever) sometimes. Gimme some details and I promise I'll do my damnedest. To reiterate, though, under at least all of the circumstances under which I have EVER used A/UX NFS, it works just FINE for me doing just the kinds of things you described. If you have troubles, let's find out why and fix 'em. Again, I'm sorry you were insulted, Steve -- that is never my intent. I want to HELP, not piss you off. I'm also sorry you didn't get any help from whomever you talked to at Apple. Sometimes people get a little BUSY around here, and things get lost... I also want to make sure the story is COMPLETELY told, and you have only one set of circumstances and only one viewpoint. Folks with an A/UX NFS problem should send me email. Posting all your grievances might be temporarily spleen-venting, but it wastes bandwidth. I will summarize after about a week or so, and hopefully come back with some solutions. Don't bother to complain if you can't include details like the ones requested above, though. "It failed miserably on Christmas Eve, 1942" is not a bug report anyone can do anything with... >>>>>> steps onto soapbox PLEASE PLEASE PLEASE people. Don't assume that Apple is JUST a big money-grubbing don't-care kinda company. MOST of us care a lot about getting your problems solved and making our stuff work for you. I personally feel strongly that Apple can make the world a better place for people to do creative work -- that's nearly my sole reason for working here. If our hardware and software don't work for you, and we can't find a way to fix it, then I have to quit. Like any big company, though, there are lots of ways for your complaint to get lost or fall on deaf ears. KEEP TRYING. You wouldn't give up easily in dealing with the Phone Company (the ultimate evil in the universe), would you? >>>>>> steps off soapbox with a heavy sigh and wipes brow -- Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally A/UX X group | pretty worthless, but Apple Computer | they *are* my own... "Laugha whila you can, monkey boy..." -- John Whorfin in Buckaroo Banzai "Never rub another man's rhubarb" -- The Joker in BatMan
abm@alan.aux.apple.com (Alan Mimms) (02/23/91)
In article <1991Feb21.175045.26404@nada.kth.se>, d88-jwa@dront.nada.kth.se (Jon W{tte) writes: |> In article <12183@goofy.Apple.COM> abm@alan.aux.apple.com (Alan Mimms) writes: |> >.Would you like to expound on what you found "doggy"? I use an FX on |> >System 6.0.5, System 7.0, and A/UX 2.0.1, and find them all to be |> |> The 24bit environment under A/UX, compiling using THINK C, is slower |> than on an SE/30 - _definately_ slower than on a "plain" IIfx. |> (FYI: this was while compiling the TCL, lots of tiny files including |> lots of headers, though the headers stay the same all the time) This almost certainly due to the fact that you're access zillions of teeny Mac files from a Unix filesystem. If you use a real HFS file system you'll win performance-wise. As in any emulation, making one kind of filesystem appear to be another, while maintaining complete transparency of operation, takes some time -- especially when the files are OPENED, which you do a lot when you access zillions of tiny files with LSC. |> >Perhaps you're trying to run A/UX on a tiny memory machine (4MB is not |> >really the best light to view A/UX in)? |> |> 8MB, and from what I see (and hear :-) there+s no paging nor (gosh) |> swapping. Yes, I do not believe that's the problem here now. |> >I'm not trying to be combative -- I (we) would like to know what's wrong |> >so we can fix it or help you to use it in a way that shows off A/UX's best |> >qualities... |> |> Oh, and this is using Berkley file systems on two quantum 80 megs - |> fast search, not-so-fast transfer. But anyway, I don't think memory |> is the problem here. |> |> >Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally |> |> Maybe splitting the project file in two files would speed things up. |> How slow is the "apple single" format ? AppleSingle is just fine if the resource fork never changes size. If you ARE changing the resource fork a lot (which you ARE on LSC project files), you want to make it Apple Double. Or move to an HFS disk partition. |> h+ |> "The IM-IV file manager chapter documents zillions of calls, all of which |> seem to do almost the same thing and none of which seem to do what I want |> them to do." -- Juri Munkki in comp.sys.mac.programmer -- Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally A/UX X group | pretty worthless, but Apple Computer | they *are* my own... "Laugha whila you can, monkey boy..." -- John Whorfin in Buckaroo Banzai "Never rub another man's rhubarb" -- The Joker in BatMan
ksand@Apple.COM (Kent Sandvik) (02/25/91)
In article <1991Feb22.175718.6395@agate.berkeley.edu> lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) writes: >In article <1991Feb21.202509.11608@ni.umd.edu> steveg@ni.umd.edu (Steve Green) writes: > I work with several other programmers on an X windows application that > currently runs on Macintoshes w/ A/UX, DECstations, VAXstations, Sun > 3/xx's, Sun SPARCstations, RISC/6000s, and PS/2s w/ AIX. The only way > to maintain this application is to use the same source files for all > of these different platforms, and to NFS-mount the source directory > wherever it is needed. Currently, the source resides on a DECstation > hard disk. Below the source directory is a subdirectory for each > platform; compiler output (i.e. `.o' files) and the linked application > go into the appropriate subdirectory. This strategy works admirably > for every machine but (you guessed it) the Macintosh. In order to get > the Macintosh version to work, I must compile and link on a non-NFS > disk. (Actually, I've never tried compiling on NFS disks and then > linking on local disk, too much work.) > >My conclusion is that A/UX 2.0's NFS is in some way incompatible with NFS on >the DECstation, but I don't know enough about NFS to be more precise. I've >had several people offer impromptu explanations/rationalizations, but >nothing I felt was truly definitive. I would like to personally know if this only happens with the object files residing on the DECStation. Is it OK with the Sparcstation used as the source server? Nota Bene the NFS code is pure Sun NFS code, so the implementation should be the same as the Sun specs. Most of the problems I've seen with NFS are Yellow Pages configuration problems concerning access. If in this case you have access to the binaries/ object code, and something does not work, is there maybe some dependencies of files that have to be accessed from other filesystems? As you see it's quite hard to define the problem without having a little bit more evidence and configuration information. Well, back to work. Kent -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++ was given to mankind, so that we might learn patience"
jjwcmp@isc.rit.edu (Jeff Wasilko) (02/25/91)
In article <49501@apple.Apple.COM> lantz@Apple.COM (Bob Lantz) writes: > >Hmm, well you probably know that MachTen is (I believe) available from >Tenon Intersystems in Santa Barbara. It is interesting in that it apparently >runs on Macs without MMU's, e.g. the SE. I think their number is 1-800-mach- >ten. This isn't an endorsement of their product, but merely a pointer to >a third-party implementation of Mach. I haven't tried it. ;-) > know this is comp.unix.aux, but I haven't seen any info on the net about MachTen here or in comp.os.mach. I've received their info pack, but I'm looking for people that have used it. Anyone? Anyone? Jeff -- | RIT VAX/VMS Systems: | Jeff Wasilko | RIT Ultrix Systems: | |BITNET: jjwcmp@ritvax +----------------------+ INET:jjwcmp@ultb.isc.rit.edu| |INTERNET: jjwcmp@ritvax.rit.edu |____UUCP:jjwcmp@ultb.UUCP____| |Ask me about the Desktop Publishing Mailing list -- All platforms welcome. |
ksand@Apple.COM (Kent Sandvik) (02/26/91)
In article <5097@lure.latrobe.edu.au> CCHD@lure.latrobe.edu.au (Huw Davies - La Trobe University Computer Centre) writes: >Having nothing better to do (I'm waiting for it to get cooler before riding >home - it's 40 degrees outside....Oh that's about 104 of those other >degrees), I thought I'd try some simple experiments with NFS mounted >file systems from my Mac. I have NFS mounted from both our MIPS M120/5 >systems running RISC/os 4.5.1 and our DECstation-2100 running Ultrix >4.0. My Mac is running A/UX v2.0 on a IIcx. > >I copied the source of the xlock program to both the Mips and DECstation >and compiled it with gcc in both cases. There are no compilation warnings >and the program runs correctly from the MIPS NFS filesystem. From the >DECstation I get a core dump, even if I copy the executable back to >the hard disk on the Mac and run it from there. Someone correct me if I'm wrong - I'm no DECStation expert - but wasn't there some fuzz with byte ordering on the DECStation that separates the file system design from the MIPS implementation. I'll remember reading something about LSB byte ordering switching so the DECStation would be compatible with the rest of the VAX systems. So there could be something special in the NFS implementation on the DEC side. Then again XDR should make the byte ordering canonical. All in all, this is just speculation. Kent >PS Hi to Kent! PSS: Hi Huw! -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++ was given to mankind, so that we might learn patience"
lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) (02/26/91)
In article <49580@apple.Apple.COM> ksand@Apple.COM (Kent Sandvik) writes: >In article <1991Feb22.175718.6395@agate.berkeley.edu> lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) writes: >>In article <1991Feb21.202509.11608@ni.umd.edu> steveg@ni.umd.edu (Steve Green) writes: >> I work with several other programmers on an X windows application that >> currently runs on Macintoshes w/ A/UX, DECstations, VAXstations, Sun >> 3/xx's, Sun SPARCstations, RISC/6000s, and PS/2s w/ AIX. ... Oops, that's a little confusing. I (Ken Lindahl) wrote that paragraph, not Steve Green. I take full responsibility and/or blame, if you can catch me. >> ... The only way >> to maintain this application is to use the same source files for all >> of these different platforms, and to NFS-mount the source directory >> wherever it is needed. Currently, the source resides on a DECstation >> hard disk. Below the source directory is a subdirectory for each >> platform; compiler output (i.e. `.o' files) and the linked application >> go into the appropriate subdirectory. This strategy works admirably >> for every machine but (you guessed it) the Macintosh. In order to get >> the Macintosh version to work, I must compile and link on a non-NFS >> disk. (Actually, I've never tried compiling on NFS disks and then >> linking on local disk, too much work.) >> >>My conclusion is that A/UX 2.0's NFS is in some way incompatible with NFS on >>the DECstation, but I don't know enough about NFS to be more precise. I've >>had several people offer impromptu explanations/rationalizations, but >>nothing I felt was truly definitive. > >I would like to personally know if this only happens with the object files >residing on the DECStation. Is it OK with the Sparcstation used as >the source server? Nota Bene the NFS code is pure Sun NFS code, so the >implementation should be the same as the Sun specs. An interesting question -- we've never tried using the SPARCstation as the source server because there isn't enough disk space. However, I can dummy up a test and let you know later. Followups by mail, unless enough people tell me they want to see it here. >Most of the problems I've seen with NFS are Yellow Pages configuration >problems concerning access. If in this case you have access to the binaries/ >object code, and something does not work, is there maybe some dependencies >of files that have to be accessed from other filesystems? As you see >it's quite hard to define the problem without having a little bit more >evidence and configuration information. For what it's worth, we're not using Yellow Pages, excuse me, NIS on any of the machines in question. I'm can't quite understand what you're suggesting. Since we're talking about compiling and linking here, access problems should be pretty obvious, no? If you want more specifics about the configuration, I can certainly provide them. I never intended my posting to be problem report -- I was merely offering some corroboration to Steve Green's posting describing problems with NFS. >Well, back to work. You mean this isn't work? Damn, I thought it was. >Kent > >-- >Kent Sandvik, Apple Computer Inc, Developer Technical Support >NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo >Zippy++ says: "C++ was given to mankind, so that we might learn patience" Ken Lindahl lindahl@violet.berkeley.edu Advanced Technology Planning, Information Systems and Technology University of California at Berkeley
liam@cs.qmw.ac.uk (William Roberts;) (02/26/91)
In <1991Feb21.202509.11608@ni.umd.edu> steveg@ni.umd.edu (Steve Green) writes: >Alan Mimms (alan@apple.com) writes: >>Excuse me, Steve, but I want to find out if there is something strange >>about your NFS usage. We here (as you might expect) have several HUNDRED >>A/UX machines, all happily using NFS to mount things from a Cray, several >>VAXen, a Solbourne, several Suns, DECstations, R6000s, Motorola Unix boxes, >>and a host of others (including, of course, lots of A/UX machines). >>I haven't heard anyone complain that NFS is unreliable in A/UX 2.0 or >>2.0.1. Is it possible there's something unusual about your site or how >>you're using NFS that causes problems? >Not one bit possible. Could it be that the problem is fixed in-house but >not made available to customers?? We have problems as well. Whenever I ask "Are there any known or reported problems with NFS and A/UX?" I get no answer at all (not even a definite No). Mots of the people on comp.unix.aux who actively port things have reported this problem (look in the archives). It is a subtle timing problem because it isn't 100% repeatable, and it only affects certain combinations. Our Sequent Balance 21000 can be persuaded to do it (Dynix V3.0.14), and we have narrowed down the problem to using ld to write an a.out file onto the remote file system: no-one complains but you often get holes full of zeros in your a.out file. A file such as the qdsamp.c demo is big enough to suffer regularly. >>I'm NOT trying to debug your problem, although I will happily attempt it >>if you contact me. I AM trying to say that A/UX NFS is NOT FLAKEY. >YES IT IS!!!! A/UX NFS is very flakey. I cannot reliably compile >ANYTHING on an NFS disk. What machine are you using for a fileserver? Name, rank and OS serial number required. Has anyone else seen this problem on something up-to-the minutes, like a Sun machine running SunOS 4.1.1 say? I have recently reported a bug, shown up by NFS in particular, whereby a slow machine (A/UX on a Mac II) using a Kinetics EtherPort II card will hang up talking to a Sun4 server. If you lower the rsize to 1024 the problem goes away, so the bug is provoked by NFS if not actually hidden in the NFS code. Contact UK.DTS if you can't locate this report. Someone mentioned 2.0b9 - we hit very, very, serious NFS bugs in 2.0b10, but these were fixed in the 2.0 release. BTW, I am still waiting for a response on what was changed between b10 and the release to solve this problem... -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)
CCHD@lure.latrobe.edu.au (Huw Davies - La Trobe University Computer Centre) (02/27/91)
In article <49611@apple.Apple.COM>, ksand@Apple.COM (Kent Sandvik) writes: > > Someone correct me if I'm wrong - I'm no DECStation expert - but > wasn't there some fuzz with byte ordering on the DECStation that > separates the file system design from the MIPS implementation. I'll > remember reading something about LSB byte ordering switching so the > DECStation would be compatible with the rest of the VAX systems. Yes - the DECstation is little-endian (like a VAX!) whilst the MIPS systems are configured big-endian (like almost everything else :-). I have just completed testing an IBM RS/6000 system with NFS, using the (patented :-) test of compiling and attempting to run the xlock application. Well, it failed too. The score so far: A/UX to Mips 120/5 (Risc/OS 4.5.1) OK DECstation-2100 (Ultrix V4.0) No IBM RS/6000 (AIX 3.1) No Given that the DECstation and the IBM are different-endian, I assume (hope :-) that endianism is not the problem. I wonder if there are subtle problems with the A/UX implementation? I am _not_ having a go at Apple nor the A/UX team. In my opinion they have done a much better job at their first port of Unix than other companies I could name.... I would just like to see A/UX get better and better.
urlichs@smurf.sub.org (Matthias Urlichs) (03/06/91)
In comp.unix.aux, article <49501@apple.Apple.COM>,
lantz@Apple.COM (Bob Lantz) writes:
< Matthias, You wrote:
<
Umm, yes I did...:
< >Actually, what I'd like to do is take the Mach 3.0 kernel that's freely
< >available, combine it with the Mach 2.5 Unix server and the [object or,
< >preferably, source] code to make it run on the Mac, and hack away.
<
< Hmm, well you probably know that MachTen is (I believe) available from
< Tenon Intersystems in Santa Barbara. It is interesting in that it apparently
< runs on Macs without MMU's, e.g. the SE.
Yes I know, but that doesn't help.
I want MacOS running on top of Mach, not Mach running on top of MacOS, for
the very simple reason that when MacOS on the former crashes, the whole
machine has to be rebooted. On the latter, you kill the MacOS process(es) and
start over.
When you're trying to use the machine with multiple tasks (say, program
development, major UUCP node, and reading NetNews while the compiler is
busy -- incidentally that's exactly what my fx is doing right now), you start
to realize the difference pretty fast.
< I might also point out that Apple is a member of OSF, as well as
< Unix International.
<
Fine, but that doesn't answer my question either.
To repeat: What happened to the CMU Mach port and why can't people like me
get it? It is available for machines with 80386 CPUs...
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/