Editing Multics (section)

==Retrospective observations==
[[Peter H. Salus]], author of a book covering Unix's early years,<ref name=Salus>{{cite book|last=Salus|first=Peter H.|title=A quarter century of UNIX|year=1994|publisher=Addison-Wesley Pub. Co.|location=Reading, Mass.|isbn=978-0-201-54777-1|edition=Reprinted with corrections Jan. 1995.}}</ref> stated one position: "With Multics they tried to have a much more versatile and flexible operating system, and it failed miserably".<ref name="bbc-40yr-8205976">{{cite news|title=40 years of Unix|url=http://news.bbc.co.uk/2/hi/technology/8205976.stm | work=BBC News | date=August 20, 2009 | first = Mark | last = Ward | access-date = April 27, 2010}} Quoting Peter Salus.<span class="plainlinks"></span></ref> This position, however, is said to have been discredited in the computing community because many of Multics' technical innovations are used in modern commercial computing systems.<ref name="Myths about Multics"/>{{Better source needed|reason=Citation is a Multics enthusiast site, not representative of the entire computing community|date=June 2022}}

The permanently resident kernel of Multics, a system derided in its day as being too large and complex, was 135&nbsp;KB of code.{{citation needed |reason=KB is kilobytes yet the GE 645 was not a byte-oriented machine|date=March 2022}} The first [[MIT]] [[GE 645|GE-645]] had 512 kilowords of memory (2&nbsp;MiB), a truly enormous amount at the time, and the kernel used a moderate portion of Multics main memory.

The entire system, including the operating system and the complex PL/I [[compiler]], user commands, and subroutine libraries, consists of about 1500 source modules. These average roughly 200 lines of source code each, and compile to a total of roughly 4.5&nbsp;MiB of procedure code, which was fairly large by the standards of the day.

Multics compilers generally optimise more for [[code density]] than CPU performance, for example using small sub-routines called ''operators'' for short standard code sequences, which makes comparison of object code size with modern systems less useful. High code density is a good optimisation choice for Multics as a [[multi-user]] system with expensive main memory.

During its commercial product history, it was often commented internally that the Honeywell Information Systems (HIS) (later Honeywell-Bull) sales and marketing staff were more familiar with and comfortable making the business case for Honeywell's other computer line, the [[Honeywell Level 6|DPS 6]] running [[General Comprehensive Operating System|GCOS]]. The DPS-6 and GCOS was a well-regarded and reliable platform for inventory, accounting, word processing, and vertical market applications, such as banking, where it had a sizeable customer base. In contrast, the full potential of Multics’ flexibility for even mundane tasks was not easy to comprehend in that era and its features were generally outside the skill set of contemporary business analysts.{{citation needed|date=March 2021}} The scope of this disconnect was concretized by an anecdote conveyed by Paul Stachour, CNO/CSC:
<blockquote>
When American Telephone and Telegraph was changing its name to just AT&T in 1983, a staffer from Honeywell’s legal department showed up and asked a Multician if he could arrange to have the name changed in all of their computerized documents. When asked when the process could be completed, the Multician replied, "It's done." The staffer repeated that he needed ''hundreds perhaps thousands'' of documents updated. The Multician explained that he had executed a global search and replace as the staffer was speaking, and the task was in fact completed.{{citation needed|date=March 2021}}</blockquote>