From crossd at gmail.com Wed Jun 12 10:51:24 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 11 Jun 2024 20:51:24 -0400 Subject: [COFF] Lynn Conway, RIP Message-ID: There seems to be some confusion, but I've heard enough sources now that I believe it to be confirmed. Notably, faculty at UMich EECS have shared that it was passed to them internally. RIP Lynn Conway, architect of the VLSI revolution and long-time transgender activist. She apparently died from heart failure; she was 86. http://www.myhusbandbetty.com/wordPressNEW/2024/06/11/lynn-conway-january-2-1938-june-9-2024/ - Dan C. From lm at mcvoy.com Wed Jun 12 11:47:47 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 11 Jun 2024 18:47:47 -0700 Subject: [COFF] Lynn Conway, RIP In-Reply-To: References: Message-ID: <20240612014747.GE8271@mcvoy.com> I did not know about the trans part of the story. Go her. It's a loss for all of us. I can relate to the MOSIS part of the story. And I think it brings in John Ousterhout's work on Magic. We used Magic at Wisconsin where I and another student laid out, simulated, and had fabbed at MOSIS, a cache controller. We did _everything right, we simulated it, it worked, sent it off to get fabbed, it came back and it did not work. I looked and looked and looked and what it was? I did not pull ground to a pad. The simulator just assumed that you did that and did not test for that. Live and learn. Mead and Conway were the bible at that point in time. Much respect to both of them. On Tue, Jun 11, 2024 at 08:51:24PM -0400, Dan Cross wrote: > There seems to be some confusion, but I've heard enough sources now > that I believe it to be confirmed. Notably, faculty at UMich EECS have > shared that it was passed to them internally. > > RIP Lynn Conway, architect of the VLSI revolution and long-time > transgender activist. She apparently died from heart failure; she was > 86. http://www.myhusbandbetty.com/wordPressNEW/2024/06/11/lynn-conway-january-2-1938-june-9-2024/ > > - Dan C. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Wed Jun 12 12:55:28 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 11 Jun 2024 19:55:28 -0700 Subject: [COFF] Lynn Conway, RIP In-Reply-To: <20240612014747.GE8271@mcvoy.com> References: <20240612014747.GE8271@mcvoy.com> Message-ID: <20240612025528.GH8271@mcvoy.com> Reading more about her, what a substantial person, I knew that in the 1980's but what a force. On Tue, Jun 11, 2024 at 06:47:47PM -0700, Larry McVoy wrote: > I did not know about the trans part of the story. Go her. It's a loss > for all of us. > > I can relate to the MOSIS part of the story. And I think it brings > in John Ousterhout's work on Magic. We used Magic at Wisconsin where > I and another student laid out, simulated, and had fabbed at MOSIS, a > cache controller. We did _everything right, we simulated it, it worked, > sent it off to get fabbed, it came back and it did not work. > > I looked and looked and looked and what it was? I did not pull ground > to a pad. The simulator just assumed that you did that and did not > test for that. > > Live and learn. Mead and Conway were the bible at that point in time. > Much respect to both of them. > > > On Tue, Jun 11, 2024 at 08:51:24PM -0400, Dan Cross wrote: > > There seems to be some confusion, but I've heard enough sources now > > that I believe it to be confirmed. Notably, faculty at UMich EECS have > > shared that it was passed to them internally. > > > > RIP Lynn Conway, architect of the VLSI revolution and long-time > > transgender activist. She apparently died from heart failure; she was > > 86. http://www.myhusbandbetty.com/wordPressNEW/2024/06/11/lynn-conway-january-2-1938-june-9-2024/ > > > > - Dan C. > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From sjenkin at canb.auug.org.au Wed Jun 19 15:24:47 2024 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Wed, 19 Jun 2024 15:24:47 +1000 Subject: [COFF] Unix Philosophy + Networks == Plan 9 [ LONG ] Message-ID: <57714BB7-92B1-4C67-8C2D-4E8D03F3351F@canb.auug.org.au> This report [link at end ] about a security issue with VMware Vsphere, stemming from the design/ architecture, resonated with me and the recent TUHS “Unix Philosophy” thread. Many of the criticisms of Unix relate to not understanding it’s purpose and design criteria: A platform on which to develop (other) Software. Which implies ‘running, profiling, testing & debugging’ that code. Complaining that Unix tools/utilities are terse and arcane for non-developers & testers, needing a steep Learning Curve, is the same as complaining a large truck doesn’t accelerate or corner like a sports car. Plan 9, by the same core team twenty years later, addresses the same problems with modern hardware & graphics, including with Networking. The system they developed in 1990 would’ve been proof against both vSphere attacks because of its security-by-design: No ‘root’ user, hence no ’sudo’ and no complex, heavyweight RPC protocol with security flaws, instead the simple, lightweight & secure 9P protocol. It seems Eric Raymond’s exposition on the “Unix Philosophy” is the basis of much of the current understanding / view. In the ESR & other works cited on Wikipedia, I see a lot about “Userland” approaches, nothing about the Kernel, Security by Design and innovations like ’shells’, ‘pipes’ and the many novel standard tools, which is being able to Reuse standard tools and ’stand on the shoulders of giants’ [ versus constantly Reinventing the Wheel, poorly ] ESR was always outside CSRC and from his resume, not involved with Unix until 1983 at best. He’s certainly been a mover & shaker in the Linux and associated (GNU led) Open Source community. ESR baldly states "The Unix philosophy is not a formal design method”, which isn’t strictly untrue, but highly misleading IMHO. Nor is the self-description by members of CSRC as having “good taste” a full and enlightening description of their process. There’s not a general appreciation, even in Research & Academic circles, that “Software is Performance Discipline”, in the same way as Surgery, Rocketry, Aviation, Music, Art and physical disciplines (dance, gymnastics, even rock climbing) are “Performance” based. It requires both Theory and Practice. If an educator hasn’t worked on at least one 1M LOC system, how can they teach “Programming in the Large”, the central problem of Software Engineering? [ an aside: the problem “golang” addressed was improving Software Engineering, not simply a language & coding. ] There’s a second factor common to all high-performance disciplines, why flying has become cheaper, safer and faster since the first jet & crashes in 1950’s: - good professionals deliberately improve, by learning from mistakes & failures and (perhaps) adopting better practices, - great professionals don’t just ‘improve’, they actively examine how & why they created Errors, Faults & Failures and detect / remove root causes. The CSRC folk used to hate Corporate attempts at Soft Skills courses, calling them “Charm School”. CSRC's deliberate and systematic learning, adaption and improvement wasn’t accidental or incidental, it was the same conscious approach used by Fairchild in its early days, the reason it quickly became the leader in Silicon devices, highly profitable, highly valued. Noyce & Moore, and I posit CSRC too, applied the Scientific Method to themselves and their practices, not just what their research field. IMO, this is what made CSRC unique - they were active Practitioners, developing high-quality, highly-performant code, as well as being astute Researchers, providing quantifiably better solutions with measurable improvements, not prototypes or partial demonstrators. Gerard Holtzman’s 1127 Alumni page shows the breadth & depth of talent that worked at CSRC. The group was unusually productive and influential. [ though I’ve not seen a ‘collected works’ ] CSRC/1127 had a very strong culture and a very deliberate, structured ‘process’ that naturally led to a world-changing product in 1974 from only ~30 man-years of effort, a minor effort in Software Projects. perfective “iterative design”, rigorous testing, code quality via a variation of pair-programming, collaborative design with group consultation / discussion and above all “performant” code - based first on ‘correct’ and ’secure’, backed by Doug McIlroy’s insistence on good documentation for everything. [ It’s worth noting that in the original paper on the “Waterfall” development process, it isn’t "Once & Done”, its specifically “do it twice”, ] [ the Shewhart Cycle, promoted by Deming, Plan - Do - Check - Act, was well known in Engineering circles, known to be very Effective ] Unix - the kernel & device drivers, the filesystem, the shell, libraries, userland and standard tools - weren’t done in hurry between 1969 & 1974’s CACM article. It was written and rewritten many times - far more than the ‘versions’, derived from the numbering of the manuals, might suggest. Ken’s comment on one of his most productive days, “throwing away 1,000 lines of code”, demonstrates this dynamic environment dominated by trials, redesign and rewriting - backed by embedded ‘instrumentation’ (profiling). Ken has also commented he had to deliberately forget all his code at one point (maybe after 1974 or 77). He was able to remember every line of code he’d written, in every file & program. I doubt that was an innate skill, even if so, it would’ve improved by deliberate practice, just as in learning to play a musical instrument. There’s a lot of research in Memory & Recall, all of which documents ‘astonishing’ performance by ‘ordinary’ people, with a only little tuition and deliberate practice. CSRC had a scientific approach to software design and coding, unlike any I’ve seen in commercial practice, academic research or promoted “Methodologies”. There’s a casual comment by Dennis in “Evolution of Unix”, 1979, about rewriting the kernel, improving its organisation and adding multiprogramming. By one person in months.. A documented, incontestable level of productivity, 100x-1000x programmers practising mainstream “methodologies”. Surely that performance alone would’ve been worthy of intensive study as the workforce & marketplace implications are profound. Perhaps the most important watershed occurred during 1973, when the operating system kernel was rewritten in C. … The success of this effort convinced us that C was useful as a nearly universal tool for systems programming, instead of just a toy for simple applications. The CSRC software evolution methodology is summed by perfectly in Baba Brinkman’s Evolution Rap: "Performance, Feedback, Revision” Website: ABC Science Show, 2009, 54 min audio, no transcript This is the performance Baba gave at the Darwin Festival in Cambridge England, July 2009. Ken also commented that they divided up the work coding, seemingly informally but in a disciplined way, so that there was only ever one time they created the same file. [ "mis-coordination of work”, Turing Award speech ] To prove they had well defined coding / naming standards and followed them, the two 20-line files were identical… ——————— There’s a few things with the “Unix Philosophy” that are critical and not included in the commentaries I’ve read or seen quoted: - The Unix kernel was ‘conservative’, not inventive or novel. It deliberately used only known, proven solutions, with a focus on small, correct, performant. “Just Worked”, not “Worked, Just”. Swapping was used, while Virtual Memory not implemented because they didn’t know of a definitive solution. They avoided the “Second System Effect” - showing how clever they were - working as professional engineers producing a robust, reliable, secure system. - Along with Unix (kernel, fsys, userland), CSRC developed a high-performance high-quality Software Development culture and methodology, The two are inseparable, IMO. - Professionals do not, can not, write non-trivial code in a “One and Done” manner. Professional quality code takes time and always evolves. It takes significant iterative improvement, including redesign, to develop large systems, with sufficient security, reliability, maintainability and performance. [ Despite 60 years of failed “Big Bang” projects using “One & Done”, Enterprises persist with this idioticy, wasting billions every year ] - Unix was developed to provide CSRC with a great environment for their own work. It never attempted to be more, but has been applied ‘everywhere’. Using this platform, members of the team developed a whole slew of important and useful tools, now taken as a given in Software Development: editors, type settings, ‘diff’ and Version Control, profile, debug, … This includes the computer Language Tools, now core to every language & system. - Collaboration and Sharing, both ways, was central to the Unix Philosophy developed at CSRC. Both within the team, within Bell Labs and other Unix installations, notably USENIX & UCB and it’s ARPA-IPTO funded CSRG. The world of Software and Code Development is clearly in two Eras, “Before Unix” and “After”. Part of this is “Open Source”, not just shared source targeted for a single platform & environment, but source code mechanically ported to new platforms. This was predicated on the original CSRC / Bell Labs attitude of Sharing the Source… Source was shared in & out, directly against the stance of the Legal Dept, intent on tightly controlling all Intellectual Property with a view of extracting “revenue streams” from clients. Later events proved CSRC’s “Source Code Sharing” was far more powerful and profitable than a Walled Garden approach, endlessly reinvesting the wheel & competing, not cooperating with others. Senior Management and the old school lawyers arguably overestimated their marketing & product capability and wildly underestimated the evolution of computing and failed to understand completely the PC era, with Bill Gates admonisment, “You guys don’t get it, it’s all about Volume”. In 1974, Unix was described publicly in CACM. In 1977, USG then later Unix System Labs was formed to work on and sell Unix commercially, locking day the I.P., with no free source code. In 1984, AT&T ‘de-merged’, keeping Bell Labs, USL and Western Digital - all the hardware and software to “Rule the World” and beat IBM. In 1994, AT&T gave up being the new IBM and sold its hardware and software divisions. In 2004, AT&T was bought by one of its spinoff’s, SBC (Southern Bell), who’d understood Mobile Telephony (passing on to customers savings from new technology), merged and rebranded themselves as “A&T”. The “Unix Wars” of the 1990’s, where vendors bought AT&T licenses, confusing “Point of Difference” with “Different & Incompatible”. They attempted Vendor lock-in, a monopoly tactic to create captive markets that could be gouged. This failed for two reasons, IMO: - the software (even binaries) and tools were all portable, the barriers to exit were low. - Unix wasn’t the only competitor Microsoft used C to write Windows NT and Intel-based hardware to undercut Unix Servers & Workstations by 10x. Bill Gates understood ‘Volume’ and the combined AT&T and Unix vendors didn’t. ================ VMware by Broadcom warns of two critical vCenter flaws, plus a nasty sudo bug VMware's security bulletin describes both of the flaws as "heap-overflow vulnerabilities in the implementation of the DCE/RPC protocol” … DCE/RPC (Distributed Computing Environment/Remote Procedure Calls) is a means of calling a procedure on a remote machine as if it were a local machine – just the ticket when managing virtual machines. ================ CHM, 2019 As Ritchie would later explain: “What we wanted to preserve was not just a good environment to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied from remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication.” ================ Ken Thompson, 1984 Turing Award paper Reflections on Trusting Trust To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software. That brings me to Dennis Ritchie. Our collaboration has been a thing of beauty. In the ten years that we have worked together, I can recall only one case of mis-coordination of work. On that occasion, I discovered that we both had written the same 20-line assembly language program. I compared the sources and was astounded to find that they matched character-for-character. The result of our work together has been far greater than the work that we each contributed. ================ The Art of Unix Programming by ESR Basics of the Unix Philosophy ================ Wiki ESR Unix Philosophy ================ -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From dave at horsfall.org Wed Jun 19 16:49:03 2024 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 19 Jun 2024 16:49:03 +1000 (EST) Subject: [COFF] Supervisor mode on ye olde PDP-11 Message-ID: Sort of between kernel and user mode, Unix [zillion trademarks etc] never used it. but did RSX-11? I used the latter long enough to hate it until Edition 5 arrived at UNSW, and I still remember being blown away by the fact that there was nothing privileged about the Shell :-) -- Dave From imp at bsdimp.com Wed Jun 19 17:48:54 2024 From: imp at bsdimp.com (Warner Losh) Date: Wed, 19 Jun 2024 01:48:54 -0600 Subject: [COFF] Supervisor mode on ye olde PDP-11 In-Reply-To: References: Message-ID: On Wed, Jun 19, 2024, 1:37 AM Dave Horsfall wrote: > Sort of between kernel and user mode, Unix [zillion trademarks etc] never > used it. but did RSX-11? > 2.11BSD used a mode between kernel and user for the TCP stack to get more effective address space... Warner I used the latter long enough to hate it until Edition 5 arrived at UNSW, > and I still remember being blown away by the fact that there was nothing > privileged about the Shell :-) > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From milovelimirovic at gmail.com Wed Jun 19 21:11:20 2024 From: milovelimirovic at gmail.com (=?utf-8?Q?Milo_Velimirovi=C4=87?=) Date: Wed, 19 Jun 2024 06:11:20 -0500 Subject: [COFF] Supervisor mode on ye olde PDP-11 In-Reply-To: References: Message-ID: > On Jun 19, 2024, at 1:49 AM, Dave Horsfall wrote: > > Sort of between kernel and user mode, Unix [zillion trademarks etc] never > used it. but did RSX-11? I don’t know about RSX-11. Back to UNIX: Supervisor mode probably never ran any code, but its memory management registers were used in m45.s in functions copyseg and clearseg. —Milo From grog at lemis.com Thu Jun 20 15:20:24 2024 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 20 Jun 2024 15:20:24 +1000 Subject: [COFF] cmake (was: Version 256 of systemd boasts '42% less Unix) philosophy' The Register In-Reply-To: <5d991bcb-0bac-50f1-ba8e-4c9c561499c9@makerlisp.com> References: <202406200501.45K5118a028500@sdf.org> <5d991bcb-0bac-50f1-ba8e-4c9c561499c9@makerlisp.com> Message-ID: [Moved to COFF. Mercifully this really has nothing to do with Unix] On Wednesday, 19 June 2024 at 22:09:11 -0700, Luther Johnson wrote: > On 06/19/2024 10:01 PM, Scot Jenkins via TUHS wrote: >> "Greg A. Woods" wrote: >> >>> I will not ever allow cmake to run, or even exist, on the machines I >>> control... >> >> How do you deal with software that only builds with cmake (or meson, >> scons, ... whatever the developer decided to use as the build tool)? >> What alternatives exist short of reimplementing the build process in >> a standard makefile by hand, which is obviously very time consuming, >> error prone, and will probably break the next time you want to update >> a given package? >> >> If there is some great alternative, I would like to know about it. > > I just avoid tools that build with CMake altogether, I look for > alternative tools. The tool has already told me, what I can expect from > a continued relationship, by its use of CMake ... That's fine if you have the choice. I use Hugin (https://hugin.sourceforge.io/), a panorama stitcher, and the authors have made the decision to use cmake. I don't see any useful alternative to to Hugin, so I'm stuck with cmake. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From coff at tuhs.org Sat Jun 22 10:33:38 2024 From: coff at tuhs.org (Warren Toomey via COFF) Date: Sat, 22 Jun 2024 10:33:38 +1000 Subject: [COFF] Thank you all for your civility Message-ID: All, recently I saw on Bruce Schneier "Cryptogram" blog that he has had to change the moderation policy due to toxic comments: https://www.schneier.com/blog/archives/2024/06/new-blog-moderation-policy.html So I want to take this opportunity to thank you all for your civility and respect for others on the TUHS and COFF lists. The recent systemd and make discussions have highlighted significant differences between people's experiences and opinions. Nonetheless, apart from a few pointed comments, the discussions have been polite and informative. These lists have been in use for decades now and, thankfully, I've only had to unsubscribe a handful of people for offensive behaviour. That's a testament to the calibre of people who are on the lists. Cheers and thank you again, Warren P.S. I'm a happy Devuan (non-systemd) user for many years now.