Talk:Mach (kernel)

message: 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)
replies: text: 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)
replies: text: There also appear to be some freely distributable (public domain) parts: .  I added this info to the article, but we still need to figure out the license for Mach 4 from the University of Utah.  I suspect it might be public domain. -- Beland (talk) 15:11, 6 March 2009 (UTC)
thread_title:  Licensing 

message: : 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)
thread_title:  size of traditional kernels in lines of code 

message: 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)
thread_title: POV, confusing sentences, and historical information 

message: 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 15.252.0.75 (talk • contribs) 18 april 2006 21:42
:Fixed. Next time, please be bold! Qwertyus 23:55, 18 April 2006 (UTC)
thread_title: IPC performance

message: 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. --68.142.45.140 20:54, 16 May 2006 (UTC)
thread_title:  Long-winded, repetitive, and in some ways confusing 

message: 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)
replies: text: There's not much microkernelish about the lower layers of VM system - it has page fault handlers, data structures to represent address spaces and mappings, etc..  That's what was incorporated into 4.4BSD, with the topmost layer being based on BSD system calls such as mmap() (first implemented "for real" in SunOS 4.0, and later adopted by non-BSD-derived UN*Xes as well) rather on Mach-style APIs. Guy Harris (talk) 00:54, 3 December 2014 (UTC)
thread_title:  virtual memory management system