|WikiProject Computing||(Rated C-class)|
- 1 Licensing
- 2 Pronunciation
- 3 Avie Tevanian, etc.
- 4 BeOS
- 5 size of traditional kernels in lines of code
- 6 POV, confusing sentences, and historical information
- 7 IPC performance
- 8 Missing citations
- 9 Long-winded, repetitive, and in some ways confusing
- 10 uname
- 11 virtual memory management system
- 12 Mach in a 64-bit environment
Under what license(s) might the Mach kernel be acquired? There's no indication of this in the article, and a cursory Google search has yielded no information for me. If someone has this information, it should be added. -- Apotheon 20:32, 19 May 2007 (UTC)
- I had the same question. It appears to have it's own license, if you follow the links through to the official project page, but I don't feel comfortable add information about the license to the article, I don't think I have a great grasp on the material. Here's the link though, in case someone else can make sense of it and make the change. --Balleyne (talk) 22:35, 20 March 2008 (UTC)
How is the word "Mach" pronounced? Like "match", or like "mac", or like "mash", or like German "Bach"?
This info is missing in this article. It should be included. In fact, there has been quite a bit of discussion about this question.
- I've always presumed it was named after Austrian physicist Ernst Mach, and was pronounced the same as his name (like Bach). Qwertyus 16:13, 21 March 2006 (UTC)
- I always figured it was pronounced as in "Mach number", which is pronounced like Ernst Mach's name. – Mipadi 16:21, 21 March 2006 (UTC)
- But then some webpages say it is pronounced like "mack"? Any other opinions out there? Let us know.
- I said I had it was named after Mach. I'm not sure and have removed this unverified info from the page. It may also have been named after him indirectly, via the Mach number. That page says: "Mach number (pronounced "mack" in British English and "mock" in American English)". Qwertyus 00:06, 23 March 2006 (UTC)
- Thank you, Qwertyus. OK! Now, is there anybody around who knows how (and why so) it is pronounced? Somebody should know! After all, one has to talk about it not only write.... :-) Thank you in advance.
- I add here a link to the discussion on the pronunciation on the Mach number page. Maybe we get some info in that way.
- Okay. I know for sure that in US English it is pronounced "mock".--20pxMac Lover Talk 17:24, 10 August 2006 (UTC)
- I add here a link to the discussion on the pronunciation on the Mach number page. Maybe we get some info in that way.
I worked on the Mach project at CMU in the 80s. It's pronounced "mock." (Well, maybe more "mawck") When Rick was thinking about naming the system, there were a number of tentative names floating around, one of which was "muck." He was discussing real names with a colleague, Dario Guise, who has an Italian accent. Dario asked him what the working name was, and Rick said "muck." Dario said, "Ah, mach!" (mispronouncing it with his Italian accent), Rick loved it and it stuck. Other possible names were "Moose" (favored by Mike Young) and "Melange" (from Bob Baron, and which I was very fond of because Mach was in some sense a union of the old Spice project with Unix, "melange" was the spice from the Dune books, and "melange" means mixture). Since I'm an original source for this, I don't know if I should edit the page with it, so I'll just leave it in discussion for now.--Bill Bolosky —Preceding unsigned comment added by 188.8.131.52 (talk) 03:27, 10 February 2010 (UTC)
Avie Tevanian, etc.
Perhaps we should mention Avie Tevanian here, too. ("Tevanian was an important figure in the development of the Mach kernel while at Carnegie-Mellon.") I think it's very interesting that two important Mach developers are now at top positions in Apple (Mac OS) and Microsoft (research).
- Quite a few members of the Mach team came to Microsoft when Rick Rashid started Microsoft Research. Rich Draves, Joe Barrera, Alessandro Forin and me (Bill Bolosky), as well as Bob Fitzgerald, who'd worked on Mach's predecessor, Accent.
Is it still correct to state that the GNU Hurd is the biggest Mach project to date? Darwin's pretty popular as far as kernels in commercial OSes go. BonzoESC 00:04, 4 Dec 2004 (UTC)
- I don't have an actual source, but didn't Apple say at one point that there were the biggest seller of desktop Unix now? AlistairMcMillan 02:12, 4 Dec 2004 (UTC)
- The article actually needs a quite a bit of work. At one time it was thought that Mach would slowly take over the entire operating system universe, but this has not happened. Except that the most popular operating system in use right now (Windows NT/2K/XP) uses a kernel based partially on the work done on the Mach project. AlistairMcMillan 02:12, 4 Dec 2004 (UTC)
- I do not believe this is true. NT uses a classic monokernel, does not use IPC for much of anything, does not make extensive use of user-space servers, and is millions of lines long. NT was a development of VMS, not Mach. Maury 12:50, 23 Mar 2005 (UTC)
Is it true, that MACH stands for Microkernel Architectures Considered Harmful?
- That's more of a [backronym] than anything else. That's like if FORD stood for Found On Road Dead, Fix Or Repair Daily, or anything that's not some dead dude's name. BonzoESC 18:59, 23 Dec 2004 (UTC)
- No, it definately is not true. Since Mach is a microkernel, it wouldn't make sense for that to be the acronym. "Mach" isn't an acronym at all, and shouldn't be spelled in all caps. See my comments on the name in the pronounciation section above. --Bill Bolosky
There is at least one more microkernel system that's left out of the article and that had decent performance: BeOS. Unfortunately I don't know much details, but the system had a real microkernel and servers like input server, application server, media server, net server, etc. In addition, it was and is very fast and responsive, in some cases faster than a Linux system. (Purely from user perspective.) It should be worthwhile to try and dig information about it, as it seemed to be a succesful microkernel based OS. --W-ber
- the categorization of the BeOS kernel was discussed extensively on the Kernel article. The documentation describes it as a microkernel, while the developers described it as "modular monolithic." Eventually we reached a compromise and decided to place it under hybrid kernels unless a clear source shows otherwise. MFNickster
size of traditional kernels in lines of code
- As the capability of computers grew, Unix became increasingly cluttered with code; while early kernels might have had 100,000 lines of code, modern kernels have much more. For example, Linux, a Unix successor, has over 33 million lines.
The comparison with Linux is off-key because back when the first Mach was released, Linux did not exist. We need a number of lines of code in a SVr4 kernel or similar. --Joy [shallot] 22:17, 18 Jun 2005 (UTC)
POV, confusing sentences, and historical information
I think the sentence The ultimate "classic" operating system is Unix, so any discussion of more modern systems must start with that one is useless and seriously POV. How does one define "classic" and "modern"? I don't want to enter the debate of what has Unix invented, but this claim is dubious; secondly, even if we admit that Unix is "the ultimate classic OS" (whatever that means, and I really have no clue what it means), it's not clear one can infer "any discussion of more modern systems must start with that one" from that. I suggest either rephrasing that as "Unix being one of the major modern operating systems, we shall start our discussion with it", or something along these lines. Or, we could simply remove this sentence, which IMO does not provide any information about the subject at hand.
Also, I don't understand what is meant by Another ongoing issue was properly handling computing resources: users spend most of their time staring at the screen instead of actually using their computers' resources, and the time share system should give the CPU time to an active user during these periods. What are these periods? To me, this sentence actually describes a non-timesharing system, and such description is unappropriate in this paragraph which is supposed to describe the problems of this era's timesharing systems.
And finally, I don't think that Unix invented pipes; ITS does have pipes (used by accessing the CLA, CLI, CLO and CLU devices), in all versions I have used, and they are described in the revised ITS reference manual, section 3.4.3 (July 1969). Unfortunately, I have been unable to determine from what version on pipes were implemented in ITS, so I cannot be sure which system had them first; anyway I seriously doubt ITS' pipes were implemented after seeing Unix's pipes; more likely the two systems developed pipes independently; oh, and note ITS's pipes worked across the network (since ITS's filesystem is nertwork transparent, it is not really surprising). Well, the article does not claim Unix invented pipes, but it does imply that the fact one can manipulate files through many little programs was invented by Unix; perhaps Unix was the first system to be described as having this philosophy, but one could and would definitely manipulate files using many small utilities under ITS, so I think this needs a rephrase. Sam 17:39, 29 December 2005 (UTC)
Roughly paragraph 10 under "Mach concepts" starts with a sentence that sounded weird and redundant the first few times I read it, "Performance of the IPC system was an initial performance problem..." It seems like the word performance shouldn't be in there twice. —Preceding unsigned comment added by 184.108.40.206 (talk • contribs) 18 april 2006 21:42
Does anyone have sources for the citations that are missing from this page? There are a lot of statements that read as if they are facts but without citations who knows.
Long-winded, repetitive, and in some ways confusing
IMNSHO the entire article could do with an overhaul. It's long-winded and repetitive, particularly in the latter sections. Also, a better way to show the history of Mach (rather than writing it as a short story at the top) would be to display it in a table.
Also, am I alone in feeling that the article looks like it is going to come to some conclusion on whether or not Mach is a good thing? Reading through the article, I got the idea that the author had some sort of opinion, but it seems to flip-flop from criticising Mach for its IPC overhead through to enthusing about how the IPC bottleneck doesn't have to be that bad (e.g. for L4).
It's always read as a technical paper written by someone in the Mach community with it spending more time comparing Mach with other microkernels rather than just flatly describing Mach. This definitely requires fixing. --220.127.116.11 20:54, 16 May 2006 (UTC)
- A description of Mach as just "a UNIX kernel" would be somewhat incomplete and misleading. There's a core Mach kernel, the kernel interfaces to which are described by the MACH Kernel Interface Manual, which provides (to quote the paper):
- basic message primitives and support facilities,
- port and port set management facilities,
- task and thread creation and management facilities,
- virtual memory management functions,
- operations on memory objects.
- It does not implement, for example, any file systems or network protocols, nor does it implement any UNIX system calls. Of those, the paper only says:
- In addition to the facilities provided directly by the kernel, MACH also provides for complete emulation of all 4.3bsd functions as described in the 4.3bsd manual. This emulation is completely transparent to user programs and requires no special libraries or other utilities. On all VAX hardware MACH is binary compatible with 4.3bsd.
- In the original Mach, those were, I think, implemented by kernel-mode code that ran atop the Mach primitives; they could also have been implemented by, for example, user-mode servers making system calls that directly invoke Mach kernel primitives.
- 4.3BSD didn't even have uname, as I remember; uname came from the PWB/UNIX strain of UNIX, not the Research Unix strain, and BSD came more from the Research UNIX strain. As such, I doubt there was a "uname return-value" in the original Mach. (Eventually, uname made it into the BSDs, etc., for compatibility.)
- A number of Unix-like systems were built atop Mach; the "Operating systems based on Mach" section of the article lists some of them. At least some of them had or have uname, but the output isn't the same between, for example, Mac OS X and DEC OSF/1^W^WDigital UNIX^W^WTru64 UNIX. I don't know whether NEXTSTEP had uname, but, if it did, its output wasn't the same as Mac OS X's output (OS X reports "Darwin" as the system name, but "Darwin" didn't exist, as such, before Apple bought NeXT).
- In addition, some systems that weren't solely Unix-like, such as IBM Workplace OS, were built atop a (modified) Mach kernel; Workplace OS, according to the article, had a BSD personality, which might or might not have uname, but the MS-DOS and OS/2 personalities almost certainly didn't have uname, as the OSes they emulated didn't have uname.
- So, unless the 4.3BSD-compatible Mach had uname - and, as indicated, I doubt it did - it's impossible for somebody to add its uname output to the article, as it didn't have uname output. Guy Harris (talk) 02:22, 14 March 2008 (UTC)
virtual memory management system
I found the quote:
- The Mach virtual memory management system was also adopted by the BSD developers at CSRG
The problem I find with this quote is that there isn't enough information how Mach influenced today's BSD. Since Mach kernel is a microkernel, is the Mach's virtual management system really compatible to the monolithic BSD derivatives? I don't know but in the article there needs to be more clarification about the virtual memory management system in Mach and BSD. —Preceding unsigned comment added by Komitsuki (talk • contribs) 09:38, 4 June 2009 (UTC)
Mach in a 64-bit environment
This article mostly discusses the performance hit in a Mach microkernel due to context switching. However, it makes no mention of a 64-bit environment in which context switching should no longer be necessary (for example, Snow Leopard running a 64-bit kernel can accommodate 32-bit/64-bit user apps plus the 64-bit kernel w/o context switching). Here's a link since I can't explain this correctly: http://www.appleinsider.com/articles/08/09/04/road_to_snow_leopard_twice_the_ram_half_the_price_64_bits.html —Preceding unsigned comment added by 18.104.22.168 (talk) 12:32, 9 November 2009 (UTC)
- If I understand, there is less PMMU context switching necessary as there is more address space and the kernel VM space can be mapped in the same address space. It does not mean no context switch, but a lighter context switch. This also does not solve the issue of syscalls where userland must trap (or use the special syscall instruction when available) for a switch to kernel/supervisor mode and stack. I guess that yes, some microkernel IPC designs could benefit from a larger address space in some circumstances to reduce the overhead. The overhead is still lower in a single unprotected address space though, as it was in AmigaOS (only need to switch messages among queues using node pointers). Now consider the following scenario, on PMMU isolated components: some user task invokes a file system operation, sending a message to a file system task, sending itself a message to a block layer I/O and strategy task, itself sending a message to a HD device task... each possibly expecting an error back, so using synchronous messages for which a reply is expected. You can probably understand the performance implications, comparatively to a syscall (a type of hardware-assisted synchronous message) on a monolithic-type kernel, with the internal operation consisting of direct function calls between all the internal layers (other than the interrupt service routines)... Darwin (the OSX kernel) can be considered to be a hybrid kernel, with a Mach layer and a more traditional monolithic layer (similarily to running a Linux kernel under an L4 task). These hybrid kernels can have components organized around a small microkernel, with the more complex systems provided by large tasks handling most other operations with less overhead. 22.214.171.124 (talk) 06:25, 1 July 2012 (UTC)