From will.senn at gmail.com Sun Jun 2 11:59:42 2024 From: will.senn at gmail.com (Will Senn) Date: Sat, 1 Jun 2024 20:59:42 -0500 Subject: [TUHS] Old documentation - still the best Message-ID: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> A small reflection on the marvels of ancient writing... Today, I went to the local Unix user group to see what that was like. I was pleasantly surprised to find it quite rewarding. Learned some new stuff... and won the door prize, a copy of a book entitled "Introducing the UNIX System" by Henry McGilton and Rachel Morgan. I accepted the prize, but said I'd just read it and recycle it for some other deserving unix-phile. As it turns out, I'm not giving it back, I'll contribute another Unix book. I thought it was just some intro unix text and figured I might learn a thing or two and let someone else who needs it more have it after I read it, but it's a V7 book! I haven't seem many of those around and so, I started digging into it and do I ever wish I'd had it when I was first trying to figure stuff out! Great book, never heard of it, or its authors, but hey, I've only read a few thousand tech books. What was really fun, was where I went from there - the authors mentioned some bit about permuted indexes and the programmer's manual... So, I went and grabbed my copy off the shelf and lo and behold, my copy either doesn't have a permuted index or I'm not finding it, I was crushed. But, while I was digging around the manual, I came across Section 9 - Quick UNIX Reference! Are you kidding me?!! How many years has it taken me to gain what knowledge I have? and here, in 20 pages is the most concise reference manual I've ever seen. Just the SH, TROFF and NROFF sections are worth the effort of digging up this 40 year old text. Anyhow, following on the heels of a recent dive into v7 and Ritchie's setting up unix v7 documentation, I was yet again reminded of the golden age of well written technical documents. Oh and I guess my recent perusal of more modern "heavy weight" texts (heavy by weight, not content, and many hundreds of pages long) might have made me more appreciative of concision - I long for the days of 300 page and shorter technical books :). In case you think I overstate - just got through a pair of TCL/TK books together clocking in at 1565 pages. Thank you Henry McGilton, Rachel Morgan, and Dennis Ritchie and Steve Bourne and other folks of the '70s and '80s for keeping it concise. As a late to the party unix enthusiast, I greatly value your work and am really thankful you didn't write like they do now... Later, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Jun 2 12:31:41 2024 From: will.senn at gmail.com (Will Senn) Date: Sat, 1 Jun 2024 21:31:41 -0500 Subject: [TUHS] Proliferation of book print styles Message-ID: Today, as I was digging more into nroff/troff and such, and bemoaning the lack of brevity of modern text. I got to thinking about the old days and what might have gone wrong with book production that got us where we are today. First, I wanna ask, tongue in cheek, sort of... As the inventors and early pioneers in the area of moving from typesetters to print on demand... do you feel a bit like the Manhattan project - did you maybe put too much power into the hands of folks who probably shouldn't have that power? But seriously, I know the period of time where we went from hot metal typesetting to the digital era was an eyeblink in history but do y'all recall how it went down? Were you surprised when folks settled on word processors in favor of markup? Do you think we've progressed in the area of ease of creating documentation and printing it making it viewable and accurate since 1980? I didn't specifically mention unix, but unix history is forever bound to the evolution of documents and printing, so I figure it's fair game for TUHS and isn't yet COFF :). Later, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.martin.yardley at gmail.com Sun Jun 2 12:44:59 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Sun, 2 Jun 2024 12:44:59 +1000 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <4CED5BE6-75C1-4A4B-B730-AF2A79150426@gmail.com> Hi, My early days were spent in the electronics industry. I can remember receiving 3 pallets of data books from National Semiconductor. This happened every year. The Internet and the availability of on line documentation put a stop to that. It was a revolution. > On 2 Jun 2024, at 12:31 PM, Will Senn wrote: > > Today, as I was digging more into nroff/troff and such, and bemoaning the lack of brevity of modern text. I got to thinking about the old days and what might have gone wrong with book production that got us where we are today. > > First, I wanna ask, tongue in cheek, sort of... As the inventors and early pioneers in the area of moving from typesetters to print on demand... do you feel a bit like the Manhattan project - did you maybe put too much power into the hands of folks who probably shouldn't have that power? > > But seriously, I know the period of time where we went from hot metal typesetting to the digital era was an eyeblink in history but do y'all recall how it went down? Were you surprised when folks settled on word processors in favor of markup? Do you think we've progressed in the area of ease of creating documentation and printing it making it viewable and accurate since 1980? > > I didn't specifically mention unix, but unix history is forever bound to the evolution of documents and printing, so I figure it's fair game for TUHS and isn't yet COFF :). > > Later, > > Will Peter Yardley peter.martin.yardley at gmail.com From lm at mcvoy.com Sun Jun 2 12:53:58 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Jun 2024 19:53:58 -0700 Subject: [TUHS] Old documentation - still the best In-Reply-To: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> References: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> Message-ID: <20240602025358.GC30164@mcvoy.com> Good writing is an art form. I used to be awful, then I met Udi Manber and did some work with him. When I told him I struggled to write a good paper (I was either a senior or a grad student, so not a lot of practice) he was flabbergasted and said "writing papers is easy". I said "do tell". Here is what he told me: A) You have to know what you are writing about, no amount of writing chops will cover up a lack of knowledge. B) You have to have a good outline. Organize what you want to tell people and get it in the right order and with the right level of detail. The outline is like the skeleton of a ship. Once you have that, you are just nailing on boards. Same thing for a paper. A good outline and good knowledge, now you are just typing and filling in the details. But to get back to your point, Will, great writing is all of that but just enough words, no more, no less. You need skill to do that but you also need to care about what you are writing, it's easy to write crap if you don't care. It's hard to write well, even with all skills, I used to call writing being mentally constipated, the good stuff didn't come out easily. The early Unix papers were very well written. The Bell Labs technical journal papers about Unix are fantastic in my opinion. On Sat, Jun 01, 2024 at 08:59:42PM -0500, Will Senn wrote: > A small reflection on the marvels of ancient writing... > > Today, I went to the local Unix user group to see what that was like. I was > pleasantly surprised to find it quite rewarding. Learned some new stuff... > and won the door prize, a copy of a book entitled "Introducing the UNIX > System" by Henry McGilton and Rachel Morgan. I accepted the prize, but said > I'd just read it and recycle it for some other deserving unix-phile. As it > turns out, I'm not giving it back, I'll contribute another Unix book. I > thought it was just some intro unix text and figured I might learn a thing > or two and let someone else who needs it more have it after I read it, but > it's a V7 book! I haven't seem many of those around and so, I started > digging into it and do I ever wish I'd had it when I was first trying to > figure stuff out! Great book, never heard of it, or its authors, but hey, > I've only read a few thousand tech books. > > What was really fun, was where I went from there - the authors mentioned > some bit about permuted indexes and the programmer's manual... So, I went > and grabbed my copy off the shelf and lo and behold, my copy either doesn't > have a permuted index or I'm not finding it, I was crushed. But, while I was > digging around the manual, I came across Section 9 - Quick UNIX Reference! > Are you kidding me?!! How many years has it taken me to gain what knowledge > I have? and here, in 20 pages is the most concise reference manual I've ever > seen. > > Just the SH, TROFF and NROFF sections are worth the effort of digging up > this 40 year old text. > > Anyhow, following on the heels of a recent dive into v7 and Ritchie's > setting up unix v7 documentation, I was yet again reminded of the golden age > of well written technical documents. Oh and I guess my recent perusal of > more modern "heavy weight" texts (heavy by weight, not content, and many > hundreds of pages long) might have made me more appreciative of concision - > I long for the days of 300 page and shorter technical books :). In case you > think I overstate - just got through a pair of TCL/TK books together > clocking in at 1565 pages. > > Thank you Henry McGilton, Rachel Morgan, and Dennis Ritchie and Steve Bourne > and other folks of the '70s and '80s for keeping it concise. As a late to > the party unix enthusiast, I greatly value your work and am really thankful > you didn't write like they do now... > > Later, > > Will > > > > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sun Jun 2 13:02:46 2024 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Sat, 1 Jun 2024 22:02:46 -0500 Subject: [TUHS] Old documentation - still the best In-Reply-To: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> References: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> Message-ID: On 6/1/24 20:59, Will Senn wrote: > ... "Introducing the UNIX System" by Henry McGilton and Rachel Morgan Would you please share the ISBN for the book? It looks like there may be two different covers and I'm curious which one you're referring to. -- Grant. . . . -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4033 bytes Desc: S/MIME Cryptographic Signature URL: From will.senn at gmail.com Sun Jun 2 13:12:47 2024 From: will.senn at gmail.com (Will Senn) Date: Sat, 1 Jun 2024 22:12:47 -0500 Subject: [TUHS] Old documentation - still the best In-Reply-To: References: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> Message-ID: <5671fc3a-31b4-4087-b2ec-f209c1054332@gmail.com> On 6/1/24 10:02 PM, Grant Taylor via TUHS wrote: > On 6/1/24 20:59, Will Senn wrote: >> ... "Introducing the UNIX System" by Henry McGilton and Rachel Morgan > > Would you please share the ISBN for the book? > > It looks like there may be two different covers and I'm curious which > one you're referring to. > > > 0-07-045001-3 1983 - McGraw Hill Black cover, gray and white text, orangegish boxes: https://www.goodreads.com/book/show/2398130.Introducing_the_UNIX_System Mine doesn't have the "A BYTE BOOK" or "McGraw-Hill Software Series for Computer Professionals headings" printed on the top, but otherwise it's the same book -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Sun Jun 2 14:03:47 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 1 Jun 2024 21:03:47 -0700 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: On Sat, Jun 1, 2024 at 7:31 PM Will Senn wrote: > > Today, as I was digging more into nroff/troff and such, and bemoaning the lack of brevity of modern text. I got to thinking about the old days and what might have gone wrong with book production that got us where we are today. > > First, I wanna ask, tongue in cheek, sort of... As the inventors and early pioneers in the area of moving from typesetters to print on demand... do you feel a bit like the Manhattan project - did you maybe put too much power into the hands of folks who probably shouldn't have that power? > > But seriously, I know the period of time where we went from hot metal typesetting to the digital era was an eyeblink in history but do y'all recall how it went down? Were you surprised when folks settled on word processors in favor of markup? Do you think we've progressed in the area of ease of creating documentation and printing it making it viewable and accurate since 1980? > > I didn't specifically mention unix, but unix history is forever bound to the evolution of documents and printing, so I figure it's fair game for TUHS and isn't yet COFF :). > > Later, > > Will I think your other topic is closely related but I chose this one to reply to. I own something well north of 10,000 technical and engineering books so I will appoint myself as an amateur librarian. When I was younger, I had the false notion that anything new is good. This attitude permates a lot of society. Including professional libraries. They have a lot of collection management practices around deciding what and when to pitch something and a big one is whether the work is still in print, while a more sophisticated collection will also take into account circulation numbers (how often it is checked out). A lot of that is undoubtedly the real costs surrounding storing and displaying something (an archived book has a marginal cost, a publically accessible displayed book presumably has a higher associated cost) as well as the desire to remain current and provide value to the library's membership. >From what I have seen, there isn't much notion of retaining or promoting a particular work unless it remains in print. As an example, K&R C is still in print and would be retained by most libraries. The whole thing becomes a bit ouroboros because that leads to more copies being printed, and it remaining in collections, and being read. Obviously, this is a case of a great piece of work benefiting from the whole ordeal. But for more niche topics, that kind of feedback loop doesn't happen. So the whole thing comes down in a house of cards... the publisher guesses how many books to print, a glut of them are produced, they enter circulation, and then it goes out of print in a few years. A few years later it is purged from the public libraries. As an end user, one benefit to this collapse is that used books are basically flooded into the market and you can get many books for a fraction of their retail price used.. but it becomes difficult to know _what_ to get if you don't have an expert guide or somewhere to browse and select for yourself. So why does this all matter to your more meta question of why less great books? There is less to no money in it nowadays for authors. The above example of library circulation represented a large number of guaranteed sales to wealthy institutions (academic and government = wealth, don't let them pretend otherwise). Except now many libraries have downsized their physical collections to make room for multimedia or just lower density use of space. So there are less guaranteed sales. Another facet of the same coin, one reason printed books are great has to do with the team surrounding their production. If you look near the colophon, you will often find a textbook will have quite a few people involved in moving a manuscript to production. This obviously costs a lot of money. As things move more to ebook and print on demand, it's an obvious place to cut publishing expenses and throw all the work directly onto the author. That may result in cheaper books and maybe(?) more revenue for the author, but it won't have the same quality that a professional publishing team can bring to the table. As to my deliberate decision to accumulate the dead trees and ink, it's because although online docs are great I find my best learning is offline while I use the online docs more like mental jogs for a particular API or refamiliarizing myself with the problem domain. I have some grandeur ambitions that first involve a large scanning project but that will have to await more self funding. Regards, Kevin From tuhs at tuhs.org Sun Jun 2 14:34:51 2024 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Sat, 1 Jun 2024 23:34:51 -0500 Subject: [TUHS] Old documentation - still the best In-Reply-To: <5671fc3a-31b4-4087-b2ec-f209c1054332@gmail.com> References: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> <5671fc3a-31b4-4087-b2ec-f209c1054332@gmail.com> Message-ID: On 6/1/24 22:12, Will Senn wrote: > 0-07-045001-3 > 1983 - McGraw Hill > Black cover, gray and white text, orangegish boxes: > https://www.goodreads.com/book/show/2398130.Introducing_the_UNIX_System Thank you. > Mine doesn't have the "A BYTE BOOK" or "McGraw-Hill Software Series for > Computer Professionals headings" printed on the top, but otherwise it's > the same book :-) -- Grant. . . . -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4033 bytes Desc: S/MIME Cryptographic Signature URL: From tuhs at tuhs.org Sun Jun 2 17:28:06 2024 From: tuhs at tuhs.org (Scot Jenkins via TUHS) Date: Sun, 02 Jun 2024 03:28:06 -0400 Subject: [TUHS] Old documentation - still the best In-Reply-To: <5671fc3a-31b4-4087-b2ec-f209c1054332@gmail.com> References: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> <5671fc3a-31b4-4087-b2ec-f209c1054332@gmail.com> Message-ID: <202406020728.4527S7YV006057@sdf.org> Will Senn wrote: > On 6/1/24 10:02 PM, Grant Taylor via TUHS wrote: > > On 6/1/24 20:59, Will Senn wrote: > >> ... "Introducing the UNIX System" by Henry McGilton and Rachel Morgan This is a great book, and much of it is still relevant today. The editor tutorials and the document formatting chapters are outstanding. > > Would you please share the ISBN for the book? > > > > It looks like there may be two different covers and I'm curious which > > one you're referring to. > > > > > > > 0-07-045001-3 > 1983 - McGraw Hill > Black cover, gray and white text, orangegish boxes: > https://www.goodreads.com/book/show/2398130.Introducing_the_UNIX_System > > Mine doesn't have the "A BYTE BOOK" or "McGraw-Hill Software Series for > Computer Professionals headings" printed on the top, but otherwise it's > the same book FWIW, my copy does have the "A BYTE BOOK" and the "McGraw-Hill Software Series for Computer Professionals" headings, and has the same ISBN and publish date (1983), 556 total pages including the index. The book doesn't appear to have any printing version on the copyright page, just this above the ISBN, which I have no idea what it means: 12 13 14 15 DODO 898765 scot From mrochkind at gmail.com Sun Jun 2 18:08:08 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Sun, 2 Jun 2024 11:08:08 +0300 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: True enough, Kevin, but with the decline of printed books and the increase in online docs, I rarely find what I'm looking for in a printed book and, when I think I have, the price is very high for what may turn out to be a bad guess. Browsing a bookstore for serious computer books is no longer possible, except maybe in very large cities. For example, for an upcoming project I need up-to-date and authoritative information on Kotlin and AWS S3 APIs. Living in the past, I find, is no help! Marc Rochkind (author of the first book on UNIX programming) On Sun, Jun 2, 2024, 7:12 AM Kevin Bowling wrote: > On Sat, Jun 1, 2024 at 7:31 PM Will Senn wrote: > > > > Today, as I was digging more into nroff/troff and such, and bemoaning > the lack of brevity of modern text. I got to thinking about the old days > and what might have gone wrong with book production that got us where we > are today. > > > > First, I wanna ask, tongue in cheek, sort of... As the inventors and > early pioneers in the area of moving from typesetters to print on demand... > do you feel a bit like the Manhattan project - did you maybe put too much > power into the hands of folks who probably shouldn't have that power? > > > > But seriously, I know the period of time where we went from hot metal > typesetting to the digital era was an eyeblink in history but do y'all > recall how it went down? Were you surprised when folks settled on word > processors in favor of markup? Do you think we've progressed in the area of > ease of creating documentation and printing it making it viewable and > accurate since 1980? > > > > I didn't specifically mention unix, but unix history is forever bound to > the evolution of documents and printing, so I figure it's fair game for > TUHS and isn't yet COFF :). > > > > Later, > > > > Will > > I think your other topic is closely related but I chose this one to reply > to. > > I own something well north of 10,000 technical and engineering books > so I will appoint myself as an amateur librarian. > > When I was younger, I had the false notion that anything new is good. > This attitude permates a lot of society. Including professional > libraries. They have a lot of collection management practices around > deciding what and when to pitch something and a big one is whether the > work is still in print, while a more sophisticated collection will > also take into account circulation numbers (how often it is checked > out). A lot of that is undoubtedly the real costs surrounding storing > and displaying something (an archived book has a marginal cost, a > publically accessible displayed book presumably has a higher > associated cost) as well as the desire to remain current and provide > value to the library's membership. > > From what I have seen, there isn't much notion of retaining or > promoting a particular work unless it remains in print. As an > example, K&R C is still in print and would be retained by most > libraries. The whole thing becomes a bit ouroboros because that leads > to more copies being printed, and it remaining in collections, and > being read. Obviously, this is a case of a great piece of work > benefiting from the whole ordeal. But for more niche topics, that > kind of feedback loop doesn't happen. So the whole thing comes down > in a house of cards... the publisher guesses how many books to print, > a glut of them are produced, they enter circulation, and then it goes > out of print in a few years. A few years later it is purged from the > public libraries. As an end user, one benefit to this collapse is > that used books are basically flooded into the market and you can get > many books for a fraction of their retail price used.. but it becomes > difficult to know _what_ to get if you don't have an expert guide or > somewhere to browse and select for yourself. > > So why does this all matter to your more meta question of why less > great books? There is less to no money in it nowadays for authors. > The above example of library circulation represented a large number of > guaranteed sales to wealthy institutions (academic and government = > wealth, don't let them pretend otherwise). Except now many libraries > have downsized their physical collections to make room for multimedia > or just lower density use of space. So there are less guaranteed > sales. > > Another facet of the same coin, one reason printed books are great has > to do with the team surrounding their production. If you look near > the colophon, you will often find a textbook will have quite a few > people involved in moving a manuscript to production. This obviously > costs a lot of money. As things move more to ebook and print on > demand, it's an obvious place to cut publishing expenses and throw all > the work directly onto the author. That may result in cheaper books > and maybe(?) more revenue for the author, but it won't have the same > quality that a professional publishing team can bring to the table. > > As to my deliberate decision to accumulate the dead trees and ink, > it's because although online docs are great I find my best learning is > offline while I use the online docs more like mental jogs for a > particular API or refamiliarizing myself with the problem domain. I > have some grandeur ambitions that first involve a large scanning > project but that will have to await more self funding. > > Regards, > Kevin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sun Jun 2 22:39:44 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 2 Jun 2024 08:39:44 -0400 Subject: [TUHS] Proliferation of book print styles Message-ID: > Were you surprised when folks settled on word processors in favor of markup? I'm not sure what you're asking. "Word processor" was a term coming into prominence when Unix was in its infancy. Unix itself was sold to management partly on the promise of using it to make a word processor. All word processors used typewriters and were markup-based. Screens, which eventually enabled WYSIWYG, were not affordable for widespread use. Perhaps the question you meant to ask was whether we were surprised when WYSIWYG took over word-processing for the masses. No, we weren't, but we weren't attracted to it either, because it sacrificed markup's potential for expressing the logical structure of documents and thus fostering portability of text among distinct physical forms, e.g. man pages on terminals and in book form or technical papers as TMs and as journal articles. WYSIWYG was also unsuitable for typesetting math. (Microsoft Word clumsily diverts to a separate markup pane for math.) Moreover, WYSIWYG was out of sympathy with Unix philosophy, as it kept documents in a form difficult for other tools to process for unanticipated purposes, In this regard, I still regret that Luca Cardelli and Mark Manasse moved on from Bell Labs before they finished their dream of Blue, a WYSIWYG editor for markup documents, I don't know yet whether that blue-sky goal is achievable. (.docx may be seen as a ponderous latter-day attempt. Does anyone know whether it has fostered tool use?) Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Jun 2 22:45:45 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 02 Jun 2024 06:45:45 -0600 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <202406021245.452Cjjmj319179@freefriends.org> Douglas McIlroy wrote: > In this regard, I still regret that Luca Cardelli and Mark > Manasse moved on from Bell Labs before they finished their dream of Blue, a > WYSIWYG editor for markup documents, I don't know yet whether that blue-sky > goal is achievable. lyx does this for LaTeX. It's been around for a long time. See lyx.org. Arnold From will.senn at gmail.com Sun Jun 2 22:55:45 2024 From: will.senn at gmail.com (Will Senn) Date: Sun, 2 Jun 2024 07:55:45 -0500 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <554ffdbc-dd5a-43d2-92aa-11d5d73ed715@gmail.com> On 6/2/24 7:39 AM, Douglas McIlroy wrote: > > Perhaps the question you meant to ask was whether we were surprised > when WYSIWYG took over word-processing for the masses. No, we weren't, > but we weren't attracted to it either, because it sacrificed markup's > potential for expressing the logical structure of documents and thus > fostering portability of text among distinct physical forms, e.g. man > pages on terminals and in book form or  technical papers as TMs and as > journal articles. WYSIWYG was also unsuitable for typesetting math. > (Microsoft Word clumsily diverts to a separate markup pane for math.) > Yup, that's what I was really meaning to ask and what I was hoping to hear about. > Moreover, WYSIWYG was out of sympathy with Unix philosophy, as it kept > documents in a form difficult for other tools to process for > unanticipated purposes, In this regard, I still regret that Luca > Cardelli and Mark Manasse moved on from Bell Labs before they finished > their dream of Blue, a WYSIWYG editor for markup documents, I don't > know yet whether that blue-sky goal is achievable. (.docx may be seen > as a ponderous latter-day attempt. Does anyone know whether it has > fostered tool use?) > Interesting, I was wishing for something along those lines after using TeX Studio for a while. A quick preview side by side is nice, but wouldn't it be great to be able to work on the preview side of the pane while the markup side changes (as minimally as possible) showing your changes as you make them and being able to switch back and forth? Personally, I prefer troff to tex, but just idea of markup and WYSIWYG is enticing. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Jun 2 23:13:43 2024 From: will.senn at gmail.com (Will Senn) Date: Sun, 2 Jun 2024 08:13:43 -0500 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <46e3144e-7cc8-47e7-a262-483bb21c7bcf@gmail.com> On 6/1/24 11:03 PM, Kevin Bowling wrote: > I think your other topic is closely related but I chose this one to reply to. > > I own something well north of 10,000 technical and engineering books > so I will appoint myself as an amateur librarian. > > When I was younger, I had the false notion that anything new is good. > This attitude permates a lot of society. Including professional > libraries. They have a lot of collection management practices around > deciding what and when to pitch something and a big one is whether the > work is still in print, while a more sophisticated collection will > also take into account circulation numbers (how often it is checked > out). A lot of that is undoubtedly the real costs surrounding storing > and displaying something (an archived book has a marginal cost, a > publically accessible displayed book presumably has a higher > associated cost) as well as the desire to remain current and provide > value to the library's membership. > > From what I have seen, there isn't much notion of retaining or > promoting a particular work unless it remains in print. As an > example, K&R C is still in print and would be retained by most > libraries. The whole thing becomes a bit ouroboros because that leads > to more copies being printed, and it remaining in collections, and > being read. Obviously, this is a case of a great piece of work > benefiting from the whole ordeal. But for more niche topics, that > kind of feedback loop doesn't happen. So the whole thing comes down > in a house of cards... the publisher guesses how many books to print, > a glut of them are produced, they enter circulation, and then it goes > out of print in a few years. A few years later it is purged from the > public libraries. As an end user, one benefit to this collapse is > that used books are basically flooded into the market and you can get > many books for a fraction of their retail price used.. but it becomes > difficult to know _what_ to get if you don't have an expert guide or > somewhere to browse and select for yourself. > > So why does this all matter to your more meta question of why less > great books? There is less to no money in it nowadays for authors. > The above example of library circulation represented a large number of > guaranteed sales to wealthy institutions (academic and government = > wealth, don't let them pretend otherwise). Except now many libraries > have downsized their physical collections to make room for multimedia > or just lower density use of space. So there are less guaranteed > sales. > > Another facet of the same coin, one reason printed books are great has > to do with the team surrounding their production. If you look near > the colophon, you will often find a textbook will have quite a few > people involved in moving a manuscript to production. This obviously > costs a lot of money. As things move more to ebook and print on > demand, it's an obvious place to cut publishing expenses and throw all > the work directly onto the author. That may result in cheaper books > and maybe(?) more revenue for the author, but it won't have the same > quality that a professional publishing team can bring to the table. > > As to my deliberate decision to accumulate the dead trees and ink, > it's because although online docs are great I find my best learning is > offline while I use the online docs more like mental jogs for a > particular API or refamiliarizing myself with the problem domain. I > have some grandeur ambitions that first involve a large scanning > project but that will have to await more self funding. > > Regards, > Kevin Thanks. This is really clear and while I'd had similar thoughts, I hadn't thought through the entire supply chain like this. The publishing side is one thing, but the library's role in things. I gotta think some more about that - the Mattew Effect, acquisitions, and weeding... Seriously, I never thought about the library's outsized influence on supply. Duh! As for digital materials, I'm pretty sure no one on the list is unaccustomed to vast amounts of reading digital materials so would qualify as experienced consumers at the least, producers most likely, and some even experts on the subject. I, for one, read many many pdf (or convertable to pdf) works every week. Still, I vastly prefer print for serious reading or study. I have learned the value of marking up my text and I find myself writing voluminously alongside much of what I read. It seems like I have to work much harder, cognitively, to retain material that I view online and having my notes disconnected from the corresponding material is frustrating. Gotta print important stuff, no way around it for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Jun 2 23:50:02 2024 From: will.senn at gmail.com (Will Senn) Date: Sun, 2 Jun 2024 08:50:02 -0500 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <8d091003-2e75-45f1-a233-1a577265c3d7@gmail.com> Marc, it and its successors are great books for sure, thanks for writing them! I like having access to digital works, no complaints about access other than I wish I had access to everything ever written and some way to sort through it all quickly and easily. I'm more inclined to gripe about the quality of the work than it's medium. Both the writing quality and the production quality. If the target is pdf, make it a good pdf that when printed is a space considerate, easy to read, and efficient to process work, and when it's target is screen, do the same. My only real gripe about the medium, is the disconnect between quality writing and production, and the unavoidable but hidden nature of proportions that are inherent in the virtual medium. A crazy example... I recently got out my 8086 handbook because I was doing x64 assembly work and couldn't locate what I was looking for in the x64 equivalent 10 volume set online. A quick flip through the pages found what I needed and I was on my way. So, being a thoughtful person ;), I figured it was just a matter of having the book on hand, so I order one up... a week later, my x64 "manual arrived", all 10 volumes in a box about 14 inches tall, and 8 1/2 by 11 and weighing, well, I only picked it up once, but it was friggin' heavy as in bend the knees heavy. Anyhow, I dutifully opened it up, pulled out the relevant "book", volume 3 part 3 or something and flipped and flipped and flipped some more and found the 8 pages discussing the same thing covered in a paragraph in the 8086 book. Now, I realize that parallel pipelines of AVR 512 SIMPLEX/42 has some impact on the REPNZ command in situations where the quarf rejects the quam, but really pages for a paragraph and not because it required pages, they could have single spaced the document, proportioned the margins to a readable width, put the base cases in prominent positions and put the quarf and quam notes in separate appendices. They didn't - they just keep adding and adding and adding and the page count just keeps growing and growing. Why? Because they can and because folks are hungry for information. I appreciate that they put it out there, but is it ok for me to wish it were of higher quality and to note that the old stuff was better? BTW, I didn't read the 8086 manual back in the day, when it was printed, I read it the day after I went looking at the x64 docs. Will On 6/2/24 3:08 AM, Marc Rochkind wrote: > True enough, Kevin, but with the decline of printed books and the > increase in online docs, I rarely find what I'm looking for in a > printed book and, when I think I have, the price is very high for what > may turn out to be a bad guess. Browsing a bookstore for serious > computer books is no longer possible, except maybe in very large cities. > > For example, for an upcoming project I need up-to-date and > authoritative information on Kotlin and AWS S3 APIs. > > Living in the past, I find, is no help! > > Marc Rochkind > (author of the first book on UNIX programming) > > On Sun, Jun 2, 2024, 7:12 AM Kevin Bowling > wrote: > > On Sat, Jun 1, 2024 at 7:31 PM Will Senn wrote: > > > > Today, as I was digging more into nroff/troff and such, and > bemoaning the lack of brevity of modern text. I got to thinking > about the old days and what might have gone wrong with book > production that got us where we are today. > > > > First, I wanna ask, tongue in cheek, sort of... As the inventors > and early pioneers in the area of moving from typesetters to print > on demand... do you feel a bit like the Manhattan project - did > you maybe put too much power into the hands of folks who probably > shouldn't have that power? > > > > But seriously, I know the period of time where we went from hot > metal typesetting to the digital era was an eyeblink in history > but do y'all recall how it went down? Were you surprised when > folks settled on word processors in favor of markup? Do you think > we've progressed in the area of ease of creating documentation and > printing it making it viewable and accurate since 1980? > > > > I didn't specifically mention unix, but unix history is forever > bound to the evolution of documents and printing, so I figure it's > fair game for TUHS and isn't yet COFF :). > > > > Later, > > > > Will > > I think your other topic is closely related but I chose this one > to reply to. > > I own something well north of 10,000 technical and engineering books > so I will appoint myself as an amateur librarian. > > When I was younger, I had the false notion that anything new is good. > This attitude permates a lot of society.  Including professional > libraries.  They have a lot of collection management practices around > deciding what and when to pitch something and a big one is whether the > work is still in print, while a more sophisticated collection will > also take into account circulation numbers (how often it is checked > out).  A lot of that is undoubtedly the real costs surrounding storing > and displaying something (an archived book has a marginal cost, a > publically accessible displayed book presumably has a higher > associated cost) as well as the desire to remain current and provide > value to the library's membership. > > From what I have seen, there isn't much notion of retaining or > promoting a particular work unless it remains in print.  As an > example, K&R C is still in print and would be retained by most > libraries.  The whole thing becomes a bit ouroboros because that leads > to more copies being printed, and it remaining in collections, and > being read.  Obviously, this is a case of a great piece of work > benefiting from the whole ordeal.  But for more niche topics, that > kind of feedback loop doesn't happen.  So the whole thing comes down > in a house of cards... the publisher guesses how many books to print, > a glut of them are produced, they enter circulation, and then it goes > out of print in a few years.  A few years later it is purged from the > public libraries.  As an end user, one benefit to this collapse is > that used books are basically flooded into the market and you can get > many books for a fraction of their retail price used.. but it becomes > difficult to know _what_ to get if you don't have an expert guide or > somewhere to browse and select for yourself. > > So why does this all matter to your more meta question of why less > great books?  There is less to no money in it nowadays for authors. > The above example of library circulation represented a large number of > guaranteed sales to wealthy institutions (academic and government = > wealth, don't let them pretend otherwise).  Except now many libraries > have downsized their physical collections to make room for multimedia > or just lower density use of space.  So there are less guaranteed > sales. > > Another facet of the same coin, one reason printed books are great has > to do with the team surrounding their production.  If you look near > the colophon, you will often find a textbook will have quite a few > people involved in moving a manuscript to production.  This obviously > costs a lot of money.  As things move more to ebook and print on > demand, it's an obvious place to cut publishing expenses and throw all > the work directly onto the author.  That may result in cheaper books > and maybe(?) more revenue for the author, but it won't have the same > quality that a professional publishing team can bring to the table. > > As to my deliberate decision to accumulate the dead trees and ink, > it's because although online docs are great I find my best learning is > offline while I use the online docs more like mental jogs for a > particular API or refamiliarizing myself with the problem domain.  I > have some grandeur ambitions that first involve a large scanning > project but that will have to await more self funding. > > Regards, > Kevin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Mon Jun 3 00:31:20 2024 From: aek at bitsavers.org (Al Kossow) Date: Sun, 2 Jun 2024 07:31:20 -0700 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <78afa540-b09a-5f62-2764-c17aa9f4aec3@bitsavers.org> On 6/2/24 5:39 AM, Douglas McIlroy wrote: >> Were you surprised when folks settled on word processors in favor of markup? I was disappointed the world tolerates the fugly typography of web pages. Hundreds of years of readability knowledge thrown out the window. From stuff at riddermarkfarm.ca Mon Jun 3 00:48:28 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Sun, 2 Jun 2024 10:48:28 -0400 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: On 2024-06-02 08:39, Douglas McIlroy wrote (in part): > Perhaps the question you meant to ask was whether we were surprised when > WYSIWYG took over word-processing for the masses. No, we weren't, but we > weren't attracted to it either, because it sacrificed markup's potential > for expressing the logical structure of documents and thus fostering > portability of text among distinct physical forms, e.g. man pages on > terminals and in book form or  technical papers as TMs and as journal > articles. WYSIWYG was also unsuitable for typesetting math. (Microsoft > Word clumsily diverts to a separate markup pane for math.) I liken suffering through WYSIWYG for math to searching through drawers of movable type pieces for the desired piece. Some time ago, I read a nice article titled "What you see is all you get" but I cannot find the link (and Google fails me miserably). Found this, though: What has WSYIWYG done for us: https://web.archive.org/web/20050207015413/http://www.ideography.co.uk/library/seybold/WYSIWYG.html S. From e5655f30a07f at ewoof.net Mon Jun 3 01:21:43 2024 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 2 Jun 2024 15:21:43 +0000 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <80313ef5-2617-4150-8869-7c09c35e20aa@home.arpa> On 2 Jun 2024 08:39 -0400, from douglas.mcilroy at dartmouth.edu (Douglas McIlroy): > In this regard, I still regret that Luca Cardelli and Mark > Manasse moved on from Bell Labs before they finished their dream of Blue, a > WYSIWYG editor for markup documents, I don't know yet whether that blue-sky > goal is achievable. (.docx may be seen as a ponderous latter-day attempt. > Does anyone know whether it has fostered tool use?) Does Markdown count? Especially when combined with LaTeX support for typesetting math, it's probably quite good enough for most peoples' needs outside of niche applications; and there are WYSIWYG editors (not just text editors with a preview, but actual WYSIWYG editors) which use Markdown as the storage format. Of course, what Markdown very specifically does _not_ even try to do is provide any strong presentation guarantees. In that sense, it's quite a lot like early HTML. (And that, naturally, results in people doing things like using different heading levels not to represent the document outline, but rather because the result renders as what they feel is an "appropriate" text size at that point in the document.) -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From douglas.mcilroy at dartmouth.edu Mon Jun 3 01:52:52 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 2 Jun 2024 11:52:52 -0400 Subject: [TUHS] Old documentation - still the best Message-ID: I keep Lomuto and Lomuto, "A Unix Primer", Prentice-Hall (1983) on my shelf, not as a reference, but because I like to savor the presentation. The Lomutos manage to impart the Unix ethos while maintaining focus on the title in a friendly style that is nevertheless succinct and accurate. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Mon Jun 3 03:44:31 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 02 Jun 2024 18:44:31 +0100 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <20240602174431.561FC1F9AA@orac.inputplus.co.uk> Hi S., > Some time ago, I read a nice article titled "What you see is all you > get" but I cannot find the link (and Google fails me miserably). Could it have been ‘Text processing vs word processors’ from Peter Schaffter, the author of the troff mom macros. It starts with ‘When you use a word processor, your screen persistently displays an updated image of the finished document. Word for word, line for line, What You See Is What You Get.’ — https://schaffter.ca/mom/mom-02.html His -mom, have to be careful here, covers a lot of ground. https://schaffter.ca/mom/mom-01a.html -- Cheers, Ralph. From ake.nordin at netia.se Mon Jun 3 06:22:39 2024 From: ake.nordin at netia.se (=?UTF-8?Q?=C3=85ke_Nordin?=) Date: Sun, 2 Jun 2024 22:22:39 +0200 Subject: [TUHS] Proliferation of book print styles In-Reply-To: <80313ef5-2617-4150-8869-7c09c35e20aa@home.arpa> References: <80313ef5-2617-4150-8869-7c09c35e20aa@home.arpa> Message-ID: On 2024-06-02 17:21, Michael Kjörling wrote: > On 2 Jun 2024 08:39 -0400, from douglas.mcilroy at dartmouth.edu (Douglas McIlroy): >> In this regard, I still regret that Luca Cardelli and Mark >> Manasse moved on from Bell Labs before they finished their dream of Blue, a >> WYSIWYG editor for markup documents, I don't know yet whether that blue-sky >> goal is achievable. (.docx may be seen as a ponderous latter-day attempt. >> Does anyone know whether it has fostered tool use?) > Does Markdown count? > > Especially when combined with LaTeX support for typesetting math, it's > probably quite good enough for most peoples' needs outside of niche > applications; and there are WYSIWYG editors (not just text editors > with a preview, but actual WYSIWYG editors) which use Markdown as the > storage format. > > Of course, what Markdown very specifically does _not_ even try to do > is provide any strong presentation guarantees. I haven't really participated in any real publishing endeavors since the times of waxed sheets and scalpels, so I have precious little firsthand experience with e.g. markdown, but I've read quite the severe critique of its shortcomings. A prime example is https://undeadly.org/cgi?action=article&sid=20170304230520 by Ingo Schwarze, the main developer of mandoc together with Kristaps Dzonsons. This makes me believe that any WYSIWYG editor using markdown as its storage format really uses some quite strict subset of it, combined with its own incompatible extensions. MfG, -- Åke Nordin , resident Net/Lunix/telecom geek. Netia Data AB, Stockholm SWEDEN *46#7O466OI99# From kevin.bowling at kev009.com Mon Jun 3 07:21:32 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 2 Jun 2024 14:21:32 -0700 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: On Sun, Jun 2, 2024 at 1:08 AM Marc Rochkind wrote: > > True enough, Kevin, but with the decline of printed books and the increase in online docs, I rarely find what I'm looking for in a printed book and, when I think I have, the price is very high for what may turn out to be a bad guess. Browsing a bookstore for serious computer books is no longer possible, except maybe in very large cities. Agreed, bookstores are more or less dead. I used the Internet Archive a lot to inform my pre-purchasing decisions but the copyright enforcement has caught up there. > For example, for an upcoming project I need up-to-date and authoritative information on Kotlin and AWS S3 APIs. I believe there are decent Kotlin books out. There are some "fast" publishers like Manning, Apress, and Packt (maybe in rough order of quality..) that put out a lot of ephemeral literature but occasionally have some fairly good works. There aren't a lot of consistent bangers like Prentice-Hall PTR was putting out back in the day although I am generally impressed with some of the work Pearson is putting out. No Starch is also generally a winner, although a little less hard sciency and more pop. S3 is, as a user, so trivial I am not sure it warrants a book. In the past "cookbook" style books were common and maybe even useful. When I was getting started, I was thirsty for easy copy+paste solutions so that I didn't have to strain much thought to get results. I believe Large Language Models are good enough to subsume some of that now. On the other hand, a good book on building applications in a cloud-native way definitely will shave a year or two off the learning curve. What and why seem to be more enduring than how. > > Living in the past, I find, is no help! I don't think I live in the past, I am working on similar technologies you mention to earn a living in the present. One thing I failed to mention in my post, and I think related to all this is the utility of Large Language Models. In your example above, the best current LLMs would be helpful for S3 and a little less so (but not useless) for Kotlin. However, LLMs still can't really help with the synthesis of good overall design and taste while an enduring book will impart both on an intrepid reader that should outlive the details being discussed. No doubt, whatever you are doing now is informed by your past. One other anecdote, in my recent passion of learning digital logic design, I find even the most recent textbooks are well referenced to papers and books of the past which is a bit of a contrast to programming literature. Most will go back to Boole's "Studies of Logic & Probability" as the basis. Lots of papers referenced from the 40s and books from the 70s and 80s still have authority if you are serious about the subject - Quine, McClusky, RK Richards, etc had a lot to say early on and it is very much still valid. > > Marc Rochkind > (author of the first book on UNIX programming) Yes, I recognized your name and have your books. > > On Sun, Jun 2, 2024, 7:12 AM Kevin Bowling wrote: >> >> On Sat, Jun 1, 2024 at 7:31 PM Will Senn wrote: >> > >> > Today, as I was digging more into nroff/troff and such, and bemoaning the lack of brevity of modern text. I got to thinking about the old days and what might have gone wrong with book production that got us where we are today. >> > >> > First, I wanna ask, tongue in cheek, sort of... As the inventors and early pioneers in the area of moving from typesetters to print on demand... do you feel a bit like the Manhattan project - did you maybe put too much power into the hands of folks who probably shouldn't have that power? >> > >> > But seriously, I know the period of time where we went from hot metal typesetting to the digital era was an eyeblink in history but do y'all recall how it went down? Were you surprised when folks settled on word processors in favor of markup? Do you think we've progressed in the area of ease of creating documentation and printing it making it viewable and accurate since 1980? >> > >> > I didn't specifically mention unix, but unix history is forever bound to the evolution of documents and printing, so I figure it's fair game for TUHS and isn't yet COFF :). >> > >> > Later, >> > >> > Will >> >> I think your other topic is closely related but I chose this one to reply to. >> >> I own something well north of 10,000 technical and engineering books >> so I will appoint myself as an amateur librarian. >> >> When I was younger, I had the false notion that anything new is good. >> This attitude permates a lot of society. Including professional >> libraries. They have a lot of collection management practices around >> deciding what and when to pitch something and a big one is whether the >> work is still in print, while a more sophisticated collection will >> also take into account circulation numbers (how often it is checked >> out). A lot of that is undoubtedly the real costs surrounding storing >> and displaying something (an archived book has a marginal cost, a >> publically accessible displayed book presumably has a higher >> associated cost) as well as the desire to remain current and provide >> value to the library's membership. >> >> From what I have seen, there isn't much notion of retaining or >> promoting a particular work unless it remains in print. As an >> example, K&R C is still in print and would be retained by most >> libraries. The whole thing becomes a bit ouroboros because that leads >> to more copies being printed, and it remaining in collections, and >> being read. Obviously, this is a case of a great piece of work >> benefiting from the whole ordeal. But for more niche topics, that >> kind of feedback loop doesn't happen. So the whole thing comes down >> in a house of cards... the publisher guesses how many books to print, >> a glut of them are produced, they enter circulation, and then it goes >> out of print in a few years. A few years later it is purged from the >> public libraries. As an end user, one benefit to this collapse is >> that used books are basically flooded into the market and you can get >> many books for a fraction of their retail price used.. but it becomes >> difficult to know _what_ to get if you don't have an expert guide or >> somewhere to browse and select for yourself. >> >> So why does this all matter to your more meta question of why less >> great books? There is less to no money in it nowadays for authors. >> The above example of library circulation represented a large number of >> guaranteed sales to wealthy institutions (academic and government = >> wealth, don't let them pretend otherwise). Except now many libraries >> have downsized their physical collections to make room for multimedia >> or just lower density use of space. So there are less guaranteed >> sales. >> >> Another facet of the same coin, one reason printed books are great has >> to do with the team surrounding their production. If you look near >> the colophon, you will often find a textbook will have quite a few >> people involved in moving a manuscript to production. This obviously >> costs a lot of money. As things move more to ebook and print on >> demand, it's an obvious place to cut publishing expenses and throw all >> the work directly onto the author. That may result in cheaper books >> and maybe(?) more revenue for the author, but it won't have the same >> quality that a professional publishing team can bring to the table. >> >> As to my deliberate decision to accumulate the dead trees and ink, >> it's because although online docs are great I find my best learning is >> offline while I use the online docs more like mental jogs for a >> particular API or refamiliarizing myself with the problem domain. I >> have some grandeur ambitions that first involve a large scanning >> project but that will have to await more self funding. >> >> Regards, >> Kevin From sjenkin at canb.auug.org.au Mon Jun 3 08:35:14 2024 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Mon, 3 Jun 2024 08:35:14 +1000 Subject: [TUHS] Old documentation - still the best In-Reply-To: References: Message-ID: <957B629A-6ABE-4647-86F9-946A54BDE795@canb.auug.org.au> For those playing along at home, Internet Archive have a scanned copy to borrow. The cover is unique & thoughtful. Can read the Table of Contents without ‘borrowing’. > On 3 Jun 2024, at 01:52, Douglas McIlroy wrote: > > I keep Lomuto and Lomuto, "A Unix Primer", Prentice-Hall (1983) on my shelf, not as a reference, but because I like to savor the presentation. The Lomutos manage to impart the Unix ethos while maintaining focus on the title in a friendly style that is nevertheless succinct and accurate. > > Doug -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Mon Jun 3 19:53:20 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 03 Jun 2024 10:53:20 +0100 Subject: [TUHS] Proliferation of book print styles In-Reply-To: <78afa540-b09a-5f62-2764-c17aa9f4aec3@bitsavers.org> References: <78afa540-b09a-5f62-2764-c17aa9f4aec3@bitsavers.org> Message-ID: <20240603095320.6ED3B21E8C@orac.inputplus.co.uk> Hi Al, > I was disappointed the world tolerates the fugly typography of web > pages. Hundreds of years of readability knowledge thrown out the > window. PDFs of books have declined too, and with that the book held in the hand. It's as if no aesthetic judging of each page's appearance has occurred; whatever the program produces is correct. Probably because many books are about technologies with little lifespan; either it will wane or version 2.0 will need a new book. Books on topics with a longer life are dragged down. Full justification is still often used. No breaks around the start/stop parenthetical em dash causes the very long ‘word’ to start the next line; the line before becomes 40% space. Sentences which start ‘I’ end a line. Or page. Sans serif used so that ‘I’ is as thin as can be and the font, to my eyes, generally lacks flow. When there's the choice, I skim the PDF and if it's good, go with that. Otherwise, I pluck for the worse-looking EPUB, HTML under the covers, because I can unpack it with bsdtar(1), tinker with the HTML and CSS to fix the worst of the appearance, and then return it to foo.epub for reading. -- Cheers, Ralph. From jcapp at anteil.com Tue Jun 4 02:47:59 2024 From: jcapp at anteil.com (Jim Capp) Date: Mon, 3 Jun 2024 12:47:59 -0400 (EDT) Subject: [TUHS] Old documentation - still the best In-Reply-To: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> Message-ID: <7801272.555.1717433279940.JavaMail.root@zimbraanteil> Does it happen to Nicole's, or anyone else's extension or just yours? From: "Will Senn" To: "TUHS" Sent: Saturday, June 1, 2024 9:59:42 PM Subject: [TUHS] Old documentation - still the best A small reflection on the marvels of ancient writing... Today, I went to the local Unix user group to see what that was like. I was pleasantly surprised to find it quite rewarding. Learned some new stuff... and won the door prize, a copy of a book entitled "Introducing the UNIX System" by Henry McGilton and Rachel Morgan. I accepted the prize, but said I'd just read it and recycle it for some other deserving unix-phile. As it turns out, I'm not giving it back, I'll contribute another Unix book. I thought it was just some intro unix text and figured I might learn a thing or two and let someone else who needs it more have it after I read it, but it's a V7 book! I haven't seem many of those around and so, I started digging into it and do I ever wish I'd had it when I was first trying to figure stuff out! Great book, never heard of it, or its authors, but hey, I've only read a few thousand tech books. What was really fun, was where I went from there - the authors mentioned some bit about permuted indexes and the programmer's manual... So, I went and grabbed my copy off the shelf and lo and behold, my copy either doesn't have a permuted index or I'm not finding it, I was crushed. But, while I was digging around the manual, I came across Section 9 - Quick UNIX Reference! Are you kidding me?!! How many years has it taken me to gain what knowledge I have? and here, in 20 pages is the most concise reference manual I've ever seen. Just the SH, TROFF and NROFF sections are worth the effort of digging up this 40 year old text. Anyhow, following on the heels of a recent dive into v7 and Ritchie's setting up unix v7 documentation, I was yet again reminded of the golden age of well written technical documents. Oh and I guess my recent perusal of more modern "heavy weight" texts (heavy by weight, not content, and many hundreds of pages long) might have made me more appreciative of concision - I long for the days of 300 page and shorter technical books :). In case you think I overstate - just got through a pair of TCL/TK books together clocking in at 1565 pages. Thank you Henry McGilton, Rachel Morgan, and Dennis Ritchie and Steve Bourne and other folks of the '70s and '80s for keeping it concise. As a late to the party unix enthusiast, I greatly value your work and am really thankful you didn't write like they do now... Later, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcapp at anteil.com Tue Jun 4 02:52:49 2024 From: jcapp at anteil.com (Jim Capp) Date: Mon, 3 Jun 2024 12:52:49 -0400 (EDT) Subject: [TUHS] Old documentation - still the best In-Reply-To: <7801272.555.1717433279940.JavaMail.root@zimbraanteil> Message-ID: <4305347.562.1717433569021.JavaMail.root@zimbraanteil> Sorry folks, please ignore that one! From: "Jim Capp" To: "Will Senn" Cc: "TUHS" Sent: Monday, June 3, 2024 12:47:59 PM Subject: Re: [TUHS] Old documentation - still the best Does it happen to Nicole's, or anyone else's extension or just yours? From: "Will Senn" To: "TUHS" Sent: Saturday, June 1, 2024 9:59:42 PM Subject: [TUHS] Old documentation - still the best A small reflection on the marvels of ancient writing... Today, I went to the local Unix user group to see what that was like. I was pleasantly surprised to find it quite rewarding. Learned some new stuff... and won the door prize, a copy of a book entitled "Introducing the UNIX System" by Henry McGilton and Rachel Morgan. I accepted the prize, but said I'd just read it and recycle it for some other deserving unix-phile. As it turns out, I'm not giving it back, I'll contribute another Unix book. I thought it was just some intro unix text and figured I might learn a thing or two and let someone else who needs it more have it after I read it, but it's a V7 book! I haven't seem many of those around and so, I started digging into it and do I ever wish I'd had it when I was first trying to figure stuff out! Great book, never heard of it, or its authors, but hey, I've only read a few thousand tech books. What was really fun, was where I went from there - the authors mentioned some bit about permuted indexes and the programmer's manual... So, I went and grabbed my copy off the shelf and lo and behold, my copy either doesn't have a permuted index or I'm not finding it, I was crushed. But, while I was digging around the manual, I came across Section 9 - Quick UNIX Reference! Are you kidding me?!! How many years has it taken me to gain what knowledge I have? and here, in 20 pages is the most concise reference manual I've ever seen. Just the SH, TROFF and NROFF sections are worth the effort of digging up this 40 year old text. Anyhow, following on the heels of a recent dive into v7 and Ritchie's setting up unix v7 documentation, I was yet again reminded of the golden age of well written technical documents. Oh and I guess my recent perusal of more modern "heavy weight" texts (heavy by weight, not content, and many hundreds of pages long) might have made me more appreciative of concision - I long for the days of 300 page and shorter technical books :). In case you think I overstate - just got through a pair of TCL/TK books together clocking in at 1565 pages. Thank you Henry McGilton, Rachel Morgan, and Dennis Ritchie and Steve Bourne and other folks of the '70s and '80s for keeping it concise. As a late to the party unix enthusiast, I greatly value your work and am really thankful you didn't write like they do now... Later, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From frew at ucsb.edu Tue Jun 4 07:42:37 2024 From: frew at ucsb.edu (James Frew) Date: Mon, 3 Jun 2024 14:42:37 -0700 Subject: [TUHS] Proliferation of book print styles In-Reply-To: <4CED5BE6-75C1-4A4B-B730-AF2A79150426@gmail.com> References: <4CED5BE6-75C1-4A4B-B730-AF2A79150426@gmail.com> Message-ID: <9854affc-bc27-42fb-a294-3b0e7ea4d28d@ucsb.edu> In 1988 I checked a Sun-3 workstation as baggage on a flight from LA to Beijing (long story...) The airline shrink-wrapped the whole shmodz onto a pallet for customs reasons, but I remember the second-heaviest (i.e. expensive) component, after the monitor, was the box of printed manuals... Online is wonderful. Cheers, /Frew On 2024-06-01 19:44, Peter Yardley wrote: > I can remember receiving 3 pallets of data books from National Semiconductor. This happened every year. The Internet and the availability of on line documentation put a stop to that. It was a revolution. From dave at horsfall.org Tue Jun 4 14:26:01 2024 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 4 Jun 2024 14:26:01 +1000 (EST) Subject: [TUHS] Proliferation of book print styles In-Reply-To: <20240603095320.6ED3B21E8C@orac.inputplus.co.uk> References: <78afa540-b09a-5f62-2764-c17aa9f4aec3@bitsavers.org> <20240603095320.6ED3B21E8C@orac.inputplus.co.uk> Message-ID: On Mon, 3 Jun 2024, Ralph Corderoy wrote: > Full justification is still often used. No breaks around the start/stop > parenthetical em dash causes the very long ‘word’ to start the next > line; the line before becomes 40% space. Sentences which start ‘I’ end > a line. Or page. Sans serif used so that ‘I’ is as thin as can be and > the font, to my eyes, generally lacks flow. What he said... And let's not even talk about hyphenating the- rapist. -- Dave From will.senn at gmail.com Tue Jun 4 14:31:58 2024 From: will.senn at gmail.com (Will Senn) Date: Mon, 3 Jun 2024 23:31:58 -0500 Subject: [TUHS] Vi Quick Reference card for 4.4 BSD Message-ID: Today after trying to decipher the online help for vim and neovim, I decided I'd had enough and I opted for nvi - the bug for bug vi compatible that I've used for so long on FreeBSD. It handles cursor keys, these days (my biggest gripe back when, now I'm not so sure it's an improvement). It's in-app help pages are about 300 lines long, the docs are just four of the 4.4 docs: An Introduction to Display Editing with VI, Edit: A tutorial, EX Reference Manual, and VI-EX Reference Manual - all very well written and understandable. It does everything I really need it to do without the million and one extensions and "enhancements" the others offer. In doing the docs research, I found many, many references to a "/Vi Quick Reference card"/ in the various manpages and docs. I googled and googled some more and of course got thousands of hits (really many thousands), but I can't seem to find the actual card referenced. I'm pretty sure what I want to find is a scanned image or pdf of the card for 4.4bsd. Do y'all happen to know of where I might find the golden quick ref card for vi from back in the 4.4bsd days or did it even really exist? Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Jun 4 14:46:01 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 04 Jun 2024 04:46:01 +0000 Subject: [TUHS] Vi Quick Reference card for 4.4 BSD In-Reply-To: References: Message-ID: <4YcO7QxSRsr-EFfdZcWDr8bsnSJkpl8bgWhtvn4PYDYO1UzTHdpwYOvQXue_O3X319Nt1AY9BAyvMLbM7v0E0HJEnnN_JIgrgmRu5pC1ygA=@protonmail.com> On Monday, June 3rd, 2024 at 9:31 PM, Will Senn wrote: > Today after trying to decipher the online help for vim and neovim, I decided I'd had enough and I opted for nvi - the bug for bug vi compatible that I've used for so long on FreeBSD. It handles cursor keys, these days (my biggest gripe back when, now I'm not so sure it's an improvement). It's in-app help pages are about 300 lines long, the docs are just four of the 4.4 docs: An Introduction to Display Editing with VI, Edit: A tutorial, EX Reference Manual, and VI-EX Reference Manual - all very well written and understandable. It does everything I really need it to do without the million and one extensions and "enhancements" the others offer. > > In doing the docs research, I found many, many references to a "Vi Quick Reference card" in the various manpages and docs. I googled and googled some more and of course got thousands of hits (really many thousands), but I can't seem to find the actual card referenced. I'm pretty sure what I want to find is a scanned image or pdf of the card for 4.4bsd. > > Do y'all happen to know of where I might find the golden quick ref card for vi from back in the 4.4bsd days or did it even really exist? > > Will Perhaps this?  https://imgur.com/a/unix-vi-quick-reference-Nw0sfTH Pardon the quality and host, not in a place to do a more thoughtful scan and archival right now. That was in a stack of documents I received some time ago, thrown in with stuff like V6 and KSOS manuals, some BSD docs, etc. so I presume it's also "official" fare. That and no commercial indicators (TMs, copyrights, etc.) Let me know if that link doesn't work and I'll try and find my scanner and do it properly (scanner is MIA apparently...) - Matt G. P.S. I also have the AT&T branded version of this from 1984, it's a small 22 page flipbook with the same cover motif as early SVR2 binders (so the grey with some "deathstar" lines not the red with black accent dots). Once I find my scanner I'll get that on the glass. From tuhs at tuhs.org Tue Jun 4 15:47:34 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 04 Jun 2024 05:47:34 +0000 Subject: [TUHS] Vi Quick Reference card for 4.4 BSD In-Reply-To: <4YcO7QxSRsr-EFfdZcWDr8bsnSJkpl8bgWhtvn4PYDYO1UzTHdpwYOvQXue_O3X319Nt1AY9BAyvMLbM7v0E0HJEnnN_JIgrgmRu5pC1ygA=@protonmail.com> References: <4YcO7QxSRsr-EFfdZcWDr8bsnSJkpl8bgWhtvn4PYDYO1UzTHdpwYOvQXue_O3X319Nt1AY9BAyvMLbM7v0E0HJEnnN_JIgrgmRu5pC1ygA=@protonmail.com> Message-ID: On Monday, June 3rd, 2024 at 9:46 PM, segaloco via TUHS wrote: > On Monday, June 3rd, 2024 at 9:31 PM, Will Senn will.senn at gmail.com wrote: > > > Today after trying to decipher the online help for vim and neovim, I decided I'd had enough and I opted for nvi - the bug for bug vi compatible that I've used for so long on FreeBSD. It handles cursor keys, these days (my biggest gripe back when, now I'm not so sure it's an improvement). It's in-app help pages are about 300 lines long, the docs are just four of the 4.4 docs: An Introduction to Display Editing with VI, Edit: A tutorial, EX Reference Manual, and VI-EX Reference Manual - all very well written and understandable. It does everything I really need it to do without the million and one extensions and "enhancements" the others offer. > > > > In doing the docs research, I found many, many references to a "Vi Quick Reference card" in the various manpages and docs. I googled and googled some more and of course got thousands of hits (really many thousands), but I can't seem to find the actual card referenced. I'm pretty sure what I want to find is a scanned image or pdf of the card for 4.4bsd. > > > > Do y'all happen to know of where I might find the golden quick ref card for vi from back in the 4.4bsd days or did it even really exist? > > > > Will > > > Perhaps this? https://imgur.com/a/unix-vi-quick-reference-Nw0sfTH > > Pardon the quality and host, not in a place to do a more thoughtful scan and archival right now. That was in a stack of documents I received some time ago, thrown in with stuff like V6 and KSOS manuals, some BSD docs, etc. so I presume it's also "official" fare. That and no commercial indicators (TMs, copyrights, etc.) > > Let me know if that link doesn't work and I'll try and find my scanner and do it properly (scanner is MIA apparently...) > > - Matt G. > > P.S. I also have the AT&T branded version of this from 1984, it's a small 22 page flipbook with the same cover motif as early SVR2 binders (so the grey with some "deathstar" lines not the red with black accent dots). Once I find my scanner I'll get that on the glass. Looked a bit harder and found it, scanned that booklet: https://archive.org/details/unix-system-v-visual-editor-quick-reference-issue-2 The two appear different enough, although they may share a common ancestor. I hope one or the other fits what you're searching for, either specifically or at least generally as a concise vi(1) reference. I keep the AT&T booklet at my desk as a matter of fact, it's quite convenient. - Matt G. From dave at horsfall.org Tue Jun 4 15:49:29 2024 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 4 Jun 2024 15:49:29 +1000 (EST) Subject: [TUHS] Proliferation of book print styles In-Reply-To: <9854affc-bc27-42fb-a294-3b0e7ea4d28d@ucsb.edu> References: <4CED5BE6-75C1-4A4B-B730-AF2A79150426@gmail.com> <9854affc-bc27-42fb-a294-3b0e7ea4d28d@ucsb.edu> Message-ID: On Mon, 3 Jun 2024, James Frew wrote: > In 1988 I checked a Sun-3 workstation as baggage on a flight from LA to > Beijing (long story...) The airline shrink-wrapped the whole shmodz onto > a pallet for customs reasons, but I remember the second-heaviest (i.e. > expensive) component, after the monitor, was the box of printed > manuals... When working for Lionel Singer's Sun Australia (a Sun reseller), we had an entire room devoted to SunOS manuals; I wonder what happened to them (the manuals, I mean)? -- Dave From fjarlq at gmail.com Tue Jun 4 22:28:02 2024 From: fjarlq at gmail.com (Matt Day) Date: Tue, 4 Jun 2024 06:28:02 -0600 Subject: [TUHS] Vi Quick Reference card for 4.4 BSD In-Reply-To: <4YcO7QxSRsr-EFfdZcWDr8bsnSJkpl8bgWhtvn4PYDYO1UzTHdpwYOvQXue_O3X319Nt1AY9BAyvMLbM7v0E0HJEnnN_JIgrgmRu5pC1ygA=@protonmail.com> References: <4YcO7QxSRsr-EFfdZcWDr8bsnSJkpl8bgWhtvn4PYDYO1UzTHdpwYOvQXue_O3X319Nt1AY9BAyvMLbM7v0E0HJEnnN_JIgrgmRu5pC1ygA=@protonmail.com> Message-ID: Yep, that's it. The Vi Quick Reference Card dates back to the vi documentation in 2BSD: https://www.tuhs.org/cgi-bin/utree.pl?file=2BSD/doc/vi specifically the file vi.summary: https://www.tuhs.org/cgi-bin/utree.pl?file=2BSD/doc/vi/vi.summary Here's vi.summary in 4.4BSD: https://www.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/usr.bin/ex/USD.doc/vi/vi.summary A decent PDF render: https://www.mpaoli.net/~michael/unix/vi/summary.pdf On Mon, Jun 3, 2024 at 10:46 PM segaloco via TUHS wrote: > On Monday, June 3rd, 2024 at 9:31 PM, Will Senn > wrote: > > > Today after trying to decipher the online help for vim and neovim, I > decided I'd had enough and I opted for nvi - the bug for bug vi compatible > that I've used for so long on FreeBSD. It handles cursor keys, these days > (my biggest gripe back when, now I'm not so sure it's an improvement). It's > in-app help pages are about 300 lines long, the docs are just four of the > 4.4 docs: An Introduction to Display Editing with VI, Edit: A tutorial, EX > Reference Manual, and VI-EX Reference Manual - all very well written and > understandable. It does everything I really need it to do without the > million and one extensions and "enhancements" the others offer. > > > > In doing the docs research, I found many, many references to a "Vi Quick > Reference card" in the various manpages and docs. I googled and googled > some more and of course got thousands of hits (really many thousands), but > I can't seem to find the actual card referenced. I'm pretty sure what I > want to find is a scanned image or pdf of the card for 4.4bsd. > > > > Do y'all happen to know of where I might find the golden quick ref card > for vi from back in the 4.4bsd days or did it even really exist? > > > > Will > > Perhaps this? https://imgur.com/a/unix-vi-quick-reference-Nw0sfTH > > Pardon the quality and host, not in a place to do a more thoughtful scan > and archival right now. That was in a stack of documents I received some > time ago, thrown in with stuff like V6 and KSOS manuals, some BSD docs, > etc. so I presume it's also "official" fare. That and no commercial > indicators (TMs, copyrights, etc.) > > Let me know if that link doesn't work and I'll try and find my scanner and > do it properly (scanner is MIA apparently...) > > - Matt G. > > P.S. I also have the AT&T branded version of this from 1984, it's a small > 22 page flipbook with the same cover motif as early SVR2 binders (so the > grey with some "deathstar" lines not the red with black accent dots). Once > I find my scanner I'll get that on the glass. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Tue Jun 4 23:01:38 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 4 Jun 2024 09:01:38 -0400 Subject: [TUHS] Vi Quick Reference card for 4.4 BSD In-Reply-To: References: <4YcO7QxSRsr-EFfdZcWDr8bsnSJkpl8bgWhtvn4PYDYO1UzTHdpwYOvQXue_O3X319Nt1AY9BAyvMLbM7v0E0HJEnnN_JIgrgmRu5pC1ygA=@protonmail.com> Message-ID: It's not a card, but it's brief: vi(1) in the v10 manual covers vi, ex, and edit in three pages. On Tue, Jun 4, 2024 at 1:47 AM segaloco via TUHS wrote: > On Monday, June 3rd, 2024 at 9:46 PM, segaloco via TUHS > wrote: > > > On Monday, June 3rd, 2024 at 9:31 PM, Will Senn will.senn at gmail.com > wrote: > > > > > Today after trying to decipher the online help for vim and neovim, I > decided I'd had enough and I opted for nvi - the bug for bug vi compatible > that I've used for so long on FreeBSD. It handles cursor keys, these days > (my biggest gripe back when, now I'm not so sure it's an improvement). It's > in-app help pages are about 300 lines long, the docs are just four of the > 4.4 docs: An Introduction to Display Editing with VI, Edit: A tutorial, EX > Reference Manual, and VI-EX Reference Manual - all very well written and > understandable. It does everything I really need it to do without the > million and one extensions and "enhancements" the others offer. > > > > > > In doing the docs research, I found many, many references to a "Vi > Quick Reference card" in the various manpages and docs. I googled and > googled some more and of course got thousands of hits (really many > thousands), but I can't seem to find the actual card referenced. I'm pretty > sure what I want to find is a scanned image or pdf of the card for 4.4bsd. > > > > > > Do y'all happen to know of where I might find the golden quick ref > card for vi from back in the 4.4bsd days or did it even really exist? > > > > > > Will > > > > > > Perhaps this? https://imgur.com/a/unix-vi-quick-reference-Nw0sfTH > > > > Pardon the quality and host, not in a place to do a more thoughtful scan > and archival right now. That was in a stack of documents I received some > time ago, thrown in with stuff like V6 and KSOS manuals, some BSD docs, > etc. so I presume it's also "official" fare. That and no commercial > indicators (TMs, copyrights, etc.) > > > > Let me know if that link doesn't work and I'll try and find my scanner > and do it properly (scanner is MIA apparently...) > > > > - Matt G. > > > > P.S. I also have the AT&T branded version of this from 1984, it's a > small 22 page flipbook with the same cover motif as early SVR2 binders (so > the grey with some "deathstar" lines not the red with black accent dots). > Once I find my scanner I'll get that on the glass. > > Looked a bit harder and found it, scanned that booklet: > > > https://archive.org/details/unix-system-v-visual-editor-quick-reference-issue-2 > > The two appear different enough, although they may share a common > ancestor. I hope one or the other fits what you're searching for, either > specifically or at least generally as a concise vi(1) reference. I keep > the AT&T booklet at my desk as a matter of fact, it's quite convenient. > > - Matt G. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jun 4 23:06:54 2024 From: will.senn at gmail.com (Will Senn) Date: Tue, 4 Jun 2024 08:06:54 -0500 Subject: [TUHS] Vi Quick Reference card for 4.4 BSD In-Reply-To: References: <4YcO7QxSRsr-EFfdZcWDr8bsnSJkpl8bgWhtvn4PYDYO1UzTHdpwYOvQXue_O3X319Nt1AY9BAyvMLbM7v0E0HJEnnN_JIgrgmRu5pC1ygA=@protonmail.com> Message-ID: <344f26f0-b258-49a0-8b39-b82538f48d21@gmail.com> Thanks Matt & Matt :). This is what I was looking for and thanks for the background, too. Oh, and duh, it didn't occur to me to go looking for the source. Off to see about rendering my own from source! Will On 6/4/24 7:28 AM, Matt Day wrote: > Yep, that's it. > > The Vi Quick Reference Card dates back to the vi documentation in > 2BSD: https://www.tuhs.org/cgi-bin/utree.pl?file=2BSD/doc/vi > specifically the file vi.summary: > https://www.tuhs.org/cgi-bin/utree.pl?file=2BSD/doc/vi/vi.summary > > Here's vi.summary in 4.4BSD: > https://www.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/usr.bin/ex/USD.doc/vi/vi.summary > A decent PDF render: https://www.mpaoli.net/~michael/unix/vi/summary.pdf > > On Mon, Jun 3, 2024 at 10:46 PM segaloco via TUHS wrote: > > On Monday, June 3rd, 2024 at 9:31 PM, Will Senn > wrote: > > > Today after trying to decipher the online help for vim and > neovim, I decided I'd had enough and I opted for nvi - the bug for > bug vi compatible that I've used for so long on FreeBSD. It > handles cursor keys, these days (my biggest gripe back when, now > I'm not so sure it's an improvement). It's in-app help pages are > about 300 lines long, the docs are just four of the 4.4 docs: An > Introduction to Display Editing with VI, Edit: A tutorial, EX > Reference Manual, and VI-EX Reference Manual - all very well > written and understandable. It does everything I really need it to > do without the million and one extensions and "enhancements" the > others offer. > > > > In doing the docs research, I found many, many references to a > "Vi Quick Reference card" in the various manpages and docs. I > googled and googled some more and of course got thousands of hits > (really many thousands), but I can't seem to find the actual card > referenced. I'm pretty sure what I want to find is a scanned image > or pdf of the card for 4.4bsd. > > > > Do y'all happen to know of where I might find the golden quick > ref card for vi from back in the 4.4bsd days or did it even really > exist? > > > > Will > > Perhaps this? https://imgur.com/a/unix-vi-quick-reference-Nw0sfTH > > Pardon the quality and host, not in a place to do a more > thoughtful scan and archival right now.  That was in a stack of > documents I received some time ago, thrown in with stuff like V6 > and KSOS manuals, some BSD docs, etc. so I presume it's also > "official" fare.  That and no commercial indicators (TMs, > copyrights, etc.) > > Let me know if that link doesn't work and I'll try and find my > scanner and do it properly (scanner is MIA apparently...) > > - Matt G. > > P.S. I also have the AT&T branded version of this from 1984, it's > a small 22 page flipbook with the same cover motif as early SVR2 > binders (so the grey with some "deathstar" lines not the red with > black accent dots).  Once I find my scanner I'll get that on the > glass. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Tue Jun 4 23:22:20 2024 From: marc.donner at gmail.com (Marc Donner) Date: Tue, 4 Jun 2024 09:22:20 -0400 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: The history of markup and WSYWYG (or, as a friend said, WYSIAYG - what you see is all you get) is fascinating. The early markup systems (runoff and its derivatives like troff, nroff, IBM's SCRIPT) focused on manipulation of representation. Normal, bold, italic, font size, justification and centering, and so on, were the vocabulary of the old systems. These systems, to me, were assembler language for contemporary phototypesetters. In the late 1970s and early 1980s we began to get systems that, as Douglas noted, could express the logical structure of documents. GML and SCRIBE were my first exposures to this way of thinking and they made life much much better for the writer. The standards work that created SGML went a bit overboard, to my taste. The only really serious adopters of SGML that I can think of were the US military, but there may have been others. Along the way were some fascinating attempts at clever hybrids. Mike Cowlishaw built a markup system for the Oxford University Press back in the early 1980s on secondment from IBM. It had a rather elegant ability to switch between markup mode and rendering mode so you could peek at how something would look. I know that it was used by OUP for the humongous task of converting the OED from its old paper-based production framework to the electronic system that they use today, though I have no idea what the current details are. The hybrid model is not dead, by the way. The wikimedia system adopts it ... you may edit either in markup mode or in WSYWYG mode, though I find the WSYWYG mode to be frustrating. Sadly, the markdown stuff used by wikimedia is pretty annoying to work with and the rendering is buggy and sometimes incomprehensible (to me, at least). Making a strong system that includes inline markup editing AND WSYWYG editing with clean flipping between them would be fascinating. Sadly, the markup specifications are flimsy and the ease of creating crazy markup like

blah blah

in edit mode makes for some difficult exception handling problems. Marc ===== nygeek.net mindthegapdialogs.com/home On Sun, Jun 2, 2024 at 8:40 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > Were you surprised when folks settled on word processors in favor of > markup? > > I'm not sure what you're asking. "Word processor" was a term coming into > prominence when Unix was in its infancy. Unix itself was sold to management > partly on the promise of using it to make a word processor. All word > processors used typewriters and were markup-based. Screens, which > eventually enabled WYSIWYG, were not affordable for widespread use. > > Perhaps the question you meant to ask was whether we were surprised when > WYSIWYG took over word-processing for the masses. No, we weren't, but we > weren't attracted to it either, because it sacrificed markup's potential > for expressing the logical structure of documents and thus fostering > portability of text among distinct physical forms, e.g. man pages on > terminals and in book form or technical papers as TMs and as journal > articles. WYSIWYG was also unsuitable for typesetting math. (Microsoft Word > clumsily diverts to a separate markup pane for math.) > > Moreover, WYSIWYG was out of sympathy with Unix philosophy, as it kept > documents in a form difficult for other tools to process for unanticipated > purposes, In this regard, I still regret that Luca Cardelli and Mark > Manasse moved on from Bell Labs before they finished their dream of Blue, a > WYSIWYG editor for markup documents, I don't know yet whether that blue-sky > goal is achievable. (.docx may be seen as a ponderous latter-day attempt. > Does anyone know whether it has fostered tool use?) > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Tue Jun 4 23:56:46 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 04 Jun 2024 14:56:46 +0100 Subject: [TUHS] vi(1) in 10th Ed. (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: <4YcO7QxSRsr-EFfdZcWDr8bsnSJkpl8bgWhtvn4PYDYO1UzTHdpwYOvQXue_O3X319Nt1AY9BAyvMLbM7v0E0HJEnnN_JIgrgmRu5pC1ygA=@protonmail.com> Message-ID: <20240604135646.A1BB821EDB@orac.inputplus.co.uk> Hi, Doug wrote: > It's not a card, but it's brief: vi(1) in the v10 manual covers vi, > ex, and edit in three pages. I went looking for it. The source is https://www.tuhs.org/cgi-bin/utree.pl?file=V10/man/man1/vi.1 The TUHS wiki, https://wiki.tuhs.org/doku.php?id=publications:manuals:research#tenth_edition links to a 10th Ed. PDF, but beware it isn't a scan of the manual. Instead, as the blurb on scrolling down says, the man pages were formatted with BSD's mandoc so not a lot of chance of the output matching the original. Page 389 of 992 is the start of vi(1). The .2C two-column output split by a tab character hasn't been honoured which is why it starts to look garbled by the second page. .PP .de fq \&\f5\\$1\fR───→\\$2 \\$3 \\$4 \\$5 \\$6 .. .de fz \&\f5\\$1 \fI\\$2\fR───→\\$3 \\$4 \\$5 \\$6 .. .ta \w'\f5:e + file'u File manipulation .2C .fq :w write back changes .fz :w file write \fIfile\fR .fz :w! file overwrite \fIfile\fR A scan of an authentic 10th Ed. manual would be handy. If it already exists, then the wiki would be better pointed at that. -- Cheers, Ralph. From lm at mcvoy.com Wed Jun 5 00:15:29 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 4 Jun 2024 07:15:29 -0700 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <20240604141529.GI5878@mcvoy.com> I've been using this hybrid for decades, it re-renders every time you write out the file: #!/usr/bin/perl # Run the command into PS.$USER # go into a loop watching the file and rerun command whenever the file # has changed. use POSIX ":sys_wait_h"; $usage = "usage: $0 comand -args -args file [file ...]\n"; foreach $file (@ARGV) { next unless -f $file; push(@files, $file); } die $usage unless $#files > -1; $cmd = "@ARGV > PS.$ENV{USER}"; $gv = "gv --spartan --antialias --media=letter PS.$ENV{USER}"; system "$cmd"; $pid = fork; if ($pid == 0) { exec $gv; die $gv; } # Read all the files looking for .so's so we catch the implied list. # I dunno if groff catches nested .so's but we don't. foreach $file (@files) { $stat{$file} = (stat($file))[9]; open(F, $file); while () { next unless /^\.so\s+(.*)\s*$/; $stat{$1} = (stat($1))[9]; } close(F); } while (1) { select(undef, undef, undef, .2); $kid = waitpid($pid,&WNOHANG); exit 0 if (kill(0, $pid) != 1); $doit = 0; foreach $f (keys %stat) { if ($stat{$f} != (stat($f))[9]) { $stat{$f} = (stat($f))[9]; $doit = 1; } } if ($doit) { system $cmd; kill(1, $pid); } } From clemc at ccc.com Wed Jun 5 00:32:25 2024 From: clemc at ccc.com (Clem Cole) Date: Tue, 4 Jun 2024 10:32:25 -0400 Subject: [TUHS] Vi Quick Reference card for 4.4 BSD In-Reply-To: References: Message-ID: On Tue, Jun 4, 2024 at 12:32 AM Will Senn wrote: > Do y'all happen to know of where I might find the golden quick ref card > for vi from back in the 4.4bsd days or did it even really exist? > Matt Day pointed you to the source, but in a small but slightly assuming addition. Your comment made me check my archives. Indeed, while the version on imgur.com is not golden, it is close. The copies I have are printed on "sunflower yellow" card stock. By the way, there was a firm called "Specialized Systems Consultants" of Seattle, Washington, that in the early 80s had a business printing and selling pocket reference cards and other SW and Services. They had a pretty good vi reference, which is ISBN 0-916151-19-0. It was printed on white card stock with black and blue letters for highlights and boxes around some of the text. Also, while looking for the vi cards, I turned up two wonderful artifacts that I'll try to get scanned and added to TUHS at some point. When you purchased V7 from AT&T, you got one copy of the printed docs and a small "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry compiled. Also, when DEC released V7M-11, they printed a small flip-binding 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is similar but different. > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake1024 at gmail.com Wed Jun 5 00:42:58 2024 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 4 Jun 2024 09:42:58 -0500 Subject: [TUHS] Vi Quick Reference card for 4.4 BSD In-Reply-To: References: Message-ID: How about this one? https://wiki.arahant.com/Wiki.jsp?page=Vi On Mon, Jun 3, 2024 at 11:32 PM Will Senn wrote: > Today after trying to decipher the online help for vim and neovim, I > decided I'd had enough and I opted for nvi - the bug for bug vi compatible > that I've used for so long on FreeBSD. It handles cursor keys, these days > (my biggest gripe back when, now I'm not so sure it's an improvement). It's > in-app help pages are about 300 lines long, the docs are just four of the > 4.4 docs: An Introduction to Display Editing with VI, Edit: A tutorial, EX > Reference Manual, and VI-EX Reference Manual - all very well written and > understandable. It does everything I really need it to do without the > million and one extensions and "enhancements" the others offer. > > In doing the docs research, I found many, many references to a "*Vi Quick > Reference card"* in the various manpages and docs. I googled and googled > some more and of course got thousands of hits (really many thousands), but > I can't seem to find the actual card referenced. I'm pretty sure what I > want to find is a scanned image or pdf of the card for 4.4bsd. > > Do y'all happen to know of where I might find the golden quick ref card > for vi from back in the 4.4bsd days or did it even really exist? > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Wed Jun 5 00:48:36 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 04 Jun 2024 15:48:36 +0100 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <20240604144836.EEA0821C4E@orac.inputplus.co.uk> Hi Mark, > Mike Cowlishaw built a markup system for the Oxford University Press > back in the early 1980s on secondment from IBM.  It had a rather > elegant ability to switch between markup mode and rendering mode so > you could peek at how something would look. I think that's his LEXX editor which did live parsing and could be initialised with parsing tables. LEXX — A programmable structured editor DOI:10.1147/rd.311.0073 https://www.researchgate.net/publication/224103825_LEXX-A_programmable_structured_editor https://en.wikipedia.org/wiki/LEXX_(text_editor) > I know that it was used by OUP for the humongous task of converting > the OED from its old paper-based production framework to the > electronic system that they use today Collins, a rival in dictionaries, used troff for a long time to produce theirs. Don't know what they do now. The University of Nottingham chose device-independent troff for their examination papers over TeX because the PDP-11 was affordable compared to the VAX. The troff source licence cost £4,000 around ’82. https://www.researchgate.net/publication/28692919_In-house_Preparation_of_Examination_Papers_using_troff_tbl_and_eqn > Sadly, the markup specifications are flimsy For markdown, the CommonMark folk have been improving this for a while. ‘We propose a standard, unambiguous syntax specification for Markdown, along with a suite of comprehensive tests to validate Markdown implementations against this specification. We believe this is necessary, even essential, for the future of Markdown. ‘That’s what we call CommonMark.’ — https://commonmark.org > the ease of creating crazy markup like

blah blah

in > edit mode makes for some difficult exception handling problems. Just treat it as an error rather than attempt recovery? Although the rendered version could be flipped to, or viewed in parallel, it would be read only and only get so far; the bug would need fixing in the mark-up view. -- Cheers, Ralph. From imp at bsdimp.com Wed Jun 5 00:53:54 2024 From: imp at bsdimp.com (Warner Losh) Date: Tue, 4 Jun 2024 08:53:54 -0600 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: At the risk of venturing too far off into the weeds (though maybe it's too late for that) What do people think of the newer markup languages like Markdown or ASCII Doctor? They seem more approachable than SGML or docbook, and a bit easier to understand, though with less control, than troff, LaTeX or TeX. To me they seem to be clever in that they infer the type of thing from the extra context marking that you give it, and the marking is more intuitive than the old-school markups (though still with some twists and sharp edges). Warner On Tue, Jun 4, 2024 at 7:22 AM Marc Donner wrote: > The history of markup and WSYWYG (or, as a friend said, WYSIAYG - what you > see is all you get) is fascinating. > > The early markup systems (runoff and its derivatives like troff, nroff, > IBM's SCRIPT) focused on manipulation of representation. Normal, bold, > italic, font size, justification and centering, and so on, were the > vocabulary of the old systems. These systems, to me, were assembler > language for contemporary phototypesetters. > > In the late 1970s and early 1980s we began to get systems that, as Douglas > noted, could express the logical structure of documents. GML and SCRIBE > were my first exposures to this way of thinking and they made life much > much better for the writer. > > The standards work that created SGML went a bit overboard, to my taste. > The only really serious adopters of SGML that I can think of were the US > military, but there may have been others. > > Along the way were some fascinating attempts at clever hybrids. Mike > Cowlishaw built a markup system for the Oxford University Press back in the > early 1980s on secondment from IBM. It had a rather elegant ability to > switch between markup mode and rendering mode so you could peek at how > something would look. I know that it was used by OUP for the humongous > task of converting the OED from its old paper-based production framework to > the electronic system that they use today, though I have no idea what the > current details are. > > The hybrid model is not dead, by the way. The wikimedia system adopts it > ... you may edit either in markup mode or in WSYWYG mode, though I find the > WSYWYG mode to be frustrating. Sadly, the markdown stuff used by wikimedia > is pretty annoying to work with and the rendering is buggy and sometimes > incomprehensible (to me, at least). > > Making a strong system that includes inline markup editing AND > WSYWYG editing with clean flipping between them would be fascinating. > Sadly, the markup specifications are flimsy and the ease of creating crazy > markup like

blah blah

in edit mode makes for some difficult > exception handling problems. > > Marc > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Sun, Jun 2, 2024 at 8:40 AM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> > Were you surprised when folks settled on word processors in favor of >> markup? >> >> I'm not sure what you're asking. "Word processor" was a term coming into >> prominence when Unix was in its infancy. Unix itself was sold to management >> partly on the promise of using it to make a word processor. All word >> processors used typewriters and were markup-based. Screens, which >> eventually enabled WYSIWYG, were not affordable for widespread use. >> >> Perhaps the question you meant to ask was whether we were surprised when >> WYSIWYG took over word-processing for the masses. No, we weren't, but we >> weren't attracted to it either, because it sacrificed markup's potential >> for expressing the logical structure of documents and thus fostering >> portability of text among distinct physical forms, e.g. man pages on >> terminals and in book form or technical papers as TMs and as journal >> articles. WYSIWYG was also unsuitable for typesetting math. (Microsoft Word >> clumsily diverts to a separate markup pane for math.) >> >> Moreover, WYSIWYG was out of sympathy with Unix philosophy, as it kept >> documents in a form difficult for other tools to process for unanticipated >> purposes, In this regard, I still regret that Luca Cardelli and Mark >> Manasse moved on from Bell Labs before they finished their dream of Blue, a >> WYSIWYG editor for markup documents, I don't know yet whether that blue-sky >> goal is achievable. (.docx may be seen as a ponderous latter-day attempt. >> Does anyone know whether it has fostered tool use?) >> >> Doug >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Jun 5 01:29:21 2024 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Tue, 4 Jun 2024 10:29:21 -0500 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <61959090-8c09-7357-25b3-8efa47724947@tnetconsulting.net> On 6/4/24 9:53 AM, Warner Losh wrote: > What do people think of the newer markup languages like Markdown or > ASCII Doctor? They seem more approachable than SGML or docbook, and a > bit easier to understand, though with less control, than troff, LaTeX or > TeX. I find Markdown et al. leaving me wanting. I personally prefer basic HTML for structure and function. If I care enough I'll add some CSS on top for appearance candy. -- Grant. . . . unix || die From tuhs at tuhs.org Wed Jun 5 05:23:22 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 4 Jun 2024 15:23:22 -0400 Subject: [TUHS] Mike Karels has died Message-ID: <58f15238-c5f3-4e51-920b-c718ff616cff@case.edu> Sad, horrible news. https://www.facebook.com/groups/BSDCan/permalink/10159552565206372/ -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From fjarlq at gmail.com Wed Jun 5 05:23:40 2024 From: fjarlq at gmail.com (Matt Day) Date: Tue, 4 Jun 2024 13:23:40 -0600 Subject: [TUHS] Vi Quick Reference card for 4.4 BSD In-Reply-To: References: Message-ID: My favorite vi reference for ages is Maarten Litmaath's, available here: https://www.ungerhu.com/jxh/vi.html Contributors to that include Rich Salz and Diomidis Spinellis. On Tue, Jun 4, 2024 at 8:33 AM Clem Cole wrote: > > > On Tue, Jun 4, 2024 at 12:32 AM Will Senn wrote: > >> Do y'all happen to know of where I might find the golden quick ref card >> for vi from back in the 4.4bsd days or did it even really exist? >> > Matt Day pointed you to the source, but in a small but slightly assuming > addition. Your comment made me check my archives. Indeed, while the version > on imgur.com is not golden, it is close. The copies I have are printed on "sunflower > yellow" card stock. > > By the way, there was a firm called "Specialized Systems Consultants" of > Seattle, Washington, that in the early 80s had a business printing and > selling pocket reference cards and other SW and Services. They had a pretty > good vi reference, which is ISBN 0-916151-19-0. It was printed on white > card stock with black and blue letters for highlights and boxes around some > of the text. > > Also, while looking for the vi cards, I turned up two wonderful artifacts > that I'll try to get scanned and added to TUHS at some point. When you > purchased V7 from AT&T, you got one copy of the printed docs and a small > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > similar but different. > >> ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jun 5 05:25:06 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 4 Jun 2024 15:25:06 -0400 Subject: [TUHS] Fwd: [ih] Mike Karels has died In-Reply-To: References: Message-ID: FYI, this just got passed by Vint Cerf. Very sad news. ---------- Forwarded message --------- From: vinton cerf via Internet-history Date: Tue, Jun 4, 2024 at 3:18 PM Subject: [ih] Mike Karels has died To: internet-history Mike Karels died on Sunday. I don’t have any details other than: https://www.facebook.com/groups/BSDCan/permalink/10159552565206372/ https://www.gearty-delmore.com/obituaries/michael-mike-karels Mike was deeply involved in the Berkeley BSD releases as I recall, after he inherited the TCP/IP implementation for Unix from Bill Joy (am I remembering that correctly?). RIP v -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history From imp at bsdimp.com Wed Jun 5 05:36:09 2024 From: imp at bsdimp.com (Warner Losh) Date: Tue, 4 Jun 2024 12:36:09 -0700 Subject: [TUHS] Fwd: [ih] Mike Karels has died In-Reply-To: References: Message-ID: He died of what appears to have been a heart attack while waiting for the train to go to the airport after BSDcan in Ottawa. I believe those details can be shared, but an official obituary will be forthcoming with more details. He was in good spirits for the conference, and I'm in shock. I am glad that I did get to chat with him about all things BSD during the closing social... But I'm also very sad. Warner On Tue, Jun 4, 2024 at 12:25 PM Dan Cross wrote: > FYI, this just got passed by Vint Cerf. Very sad news. > > ---------- Forwarded message --------- > From: vinton cerf via Internet-history > Date: Tue, Jun 4, 2024 at 3:18 PM > Subject: [ih] Mike Karels has died > To: internet-history > > > Mike Karels died on Sunday. I don’t have any details other than: > https://www.facebook.com/groups/BSDCan/permalink/10159552565206372/ > https://www.gearty-delmore.com/obituaries/michael-mike-karels > > Mike was deeply involved in the Berkeley BSD releases as I recall, after he > inherited the TCP/IP implementation for Unix from Bill Joy (am I > remembering that correctly?). > > RIP > v > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefftwopointzero at gmail.com Wed Jun 5 06:20:02 2024 From: jefftwopointzero at gmail.com (Jeffrey Joshua Rollin) Date: Tue, 4 Jun 2024 21:20:02 +0100 Subject: [TUHS] [ih] Mike Karels has died In-Reply-To: References: Message-ID: <687B90EA-C9E8-4FB7-A52C-6F38A43063D8@gmail.com> Sad news indeed :-( > On 4 Jun 2024, at 20:25, Dan Cross wrote: > > FYI, this just got passed by Vint Cerf. Very sad news. > > ---------- Forwarded message --------- > From: vinton cerf via Internet-history > Date: Tue, Jun 4, 2024 at 3:18 PM > Subject: [ih] Mike Karels has died > To: internet-history > > > Mike Karels died on Sunday. I don’t have any details other than: > https://www.facebook.com/groups/BSDCan/permalink/10159552565206372/ > https://www.gearty-delmore.com/obituaries/michael-mike-karels > > Mike was deeply involved in the Berkeley BSD releases as I recall, after he > inherited the TCP/IP implementation for Unix from Bill Joy (am I > remembering that correctly?). > > RIP > v > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From akosela at andykosela.com Wed Jun 5 06:35:53 2024 From: akosela at andykosela.com (Andy Kosela) Date: Tue, 4 Jun 2024 22:35:53 +0200 Subject: [TUHS] Mike Karels has died In-Reply-To: <58f15238-c5f3-4e51-920b-c718ff616cff@case.edu> References: <58f15238-c5f3-4e51-920b-c718ff616cff@case.edu> Message-ID: On Tuesday, June 4, 2024, Chet Ramey via TUHS wrote: > Sad, horrible news. > > https://www.facebook.com/groups/BSDCan/permalink/10159552565206372/ > > He was the BSD giant. Rest in Peace. I remember one particular Computer Chronicles episode from 1989 which featured Mike. https://youtu.be/lkyyAKTvmx0?si=9fKp2pmF_e7HeVpk --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Jun 5 07:46:51 2024 From: athornton at gmail.com (Adam Thornton) Date: Tue, 4 Jun 2024 14:46:51 -0700 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: On Tue, Jun 4, 2024 at 6:22 AM Marc Donner wrote: > The standards work that created SGML went a bit overboard, to my taste. > The only really serious adopters of SGML that I can think of were the US > military, but there may have been others. > > Bookmaster (an IBM product, and I think what they used for their published docs in the 90s into the 2000s?) was SGML based, if I remember correctly. Writing in it was kind of lovely, and the traintrack diagrams for command syntax were exceptionally well-done. It made nice-looking docs (e.g. https://distribution.sinenomine.net/opensolaris/install2.pdf). Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Jun 5 08:54:59 2024 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 5 Jun 2024 08:54:59 +1000 (EST) Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: <4CED5BE6-75C1-4A4B-B730-AF2A79150426@gmail.com> <9854affc-bc27-42fb-a294-3b0e7ea4d28d@ucsb.edu> Message-ID: On Tue, 4 Jun 2024, Dave Horsfall wrote: > When working for Lionel Singer's Sun Australia (a Sun reseller), we had > an entire room devoted to SunOS manuals; I wonder what happened to them > (the manuals, I mean)? Sun *Computer* Australia, of course; sigh... -- Dave From flexibeast at gmail.com Wed Jun 5 10:13:37 2024 From: flexibeast at gmail.com (Alexis) Date: Wed, 05 Jun 2024 10:13:37 +1000 Subject: [TUHS] Proliferation of book print styles In-Reply-To: (Warner Losh's message of "Tue, 4 Jun 2024 08:53:54 -0600") References: Message-ID: <8734psfdqm.fsf@gmail.com> Warner Losh writes: > What do people think of the newer markup languages like Markdown > or ASCII > Doctor? They seem more approachable than SGML or docbook, and a > bit easier > to understand, though with less control, than troff, LaTeX or > TeX. Speaking as someone who had to fight Markdown several years ago, when trying to write a converter from Markdown, and who found that programming language library authors generally seemed to assume you'd only ever want to convert to HTML ("No, we won't expose the parse tree"), this old critique by Ingo Schwarze strongly resonates with me: https://undeadly.org/cgi?action=article&sid=20170304230520 Alexis. From tuhs at tuhs.org Wed Jun 5 20:17:19 2024 From: tuhs at tuhs.org (Andrew Lynch via TUHS) Date: Wed, 5 Jun 2024 10:17:19 +0000 (UTC) Subject: [TUHS] most direct Unix descendant References: <1324869037.1755756.1717582639424.ref@mail.yahoo.com> Message-ID: <1324869037.1755756.1717582639424@mail.yahoo.com> Hi Out of curiosity, what would be considered the most direct descendent of Unix available today?  Yes, there are many descendants, but they've all gone down their own evolutionary paths.   Is it FreeBSD or NetBSD?  Something else?  I don't think it would be Minix or Linux because I remember when they came along, and it was well after various Unix versions were around. Does such a thing even exist anymore?  I remember using AT&T Unix System V and various BSD variants back in college in the 1980's.  System V was the "new thing" back then but was eventually sold and seems to have faded.  Maybe it is only available commercially, but it does not seem as prominent as it once was. Any thoughts? Thanks, Andrew Lynch -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreww591 at gmail.com Wed Jun 5 20:51:32 2024 From: andreww591 at gmail.com (Andrew Warkentin) Date: Wed, 5 Jun 2024 04:51:32 -0600 Subject: [TUHS] most direct Unix descendant In-Reply-To: <1324869037.1755756.1717582639424@mail.yahoo.com> References: <1324869037.1755756.1717582639424.ref@mail.yahoo.com> <1324869037.1755756.1717582639424@mail.yahoo.com> Message-ID: On Wed, Jun 5, 2024 at 4:17 AM Andrew Lynch via TUHS wrote: > > Hi > > Out of curiosity, what would be considered the most direct descendent of Unix available today? Yes, there are many descendants, but they've all gone down their own evolutionary paths. > > Is it FreeBSD or NetBSD? Something else? I don't think it would be Minix or Linux because I remember when they came along, and it was well after various Unix versions were around. > > Does such a thing even exist anymore? I remember using AT&T Unix System V and various BSD variants back in college in the 1980's. System V was the "new thing" back then but was eventually sold and seems to have faded. Maybe it is only available commercially, but it does not seem as prominent as it once was. > > Any thoughts? > What exactly do you mean by "most direct descendant of Unix"? Are you specifically talking about Research Unix? Both USG (SysIII/SysV) and BSD are actually more like side branches from Research Unix, and neither is really a continuation of it. After V7, Research Unix continued until V10, but was barely distributed outside Bell Labs and had relatively little direct influence on anything else; these late Research Unix versions did incorporate significant amounts of code from the side branches that took over the mainstream (especially BSD, although there may have been a bit of USG code incorporated as well). I'd say the closest thing to "the most direct modern descendant of Research Unix" would be Plan 9, which continued the development of the networking and extensibility features of late Research Unix, but significantly broke compatibility with Unix (sometimes in ways that are IMO not really worth the incompatibility). From tuhs at tuhs.org Wed Jun 5 23:46:55 2024 From: tuhs at tuhs.org (Andrew Lynch via TUHS) Date: Wed, 5 Jun 2024 13:46:55 +0000 (UTC) Subject: [TUHS] most direct Unix descendant In-Reply-To: References: <1324869037.1755756.1717582639424.ref@mail.yahoo.com> <1324869037.1755756.1717582639424@mail.yahoo.com> Message-ID: <378394076.1809602.1717595215796@mail.yahoo.com> On Wednesday, June 5, 2024 at 06:51:54 AM EDT, Andrew Warkentin wrote: On Wed, Jun 5, 2024 at 4:17 AM Andrew Lynch via TUHS wrote: > > Hi > > Out of curiosity, what would be considered the most direct descendent of Unix available today?  Yes, there are many descendants, but they've all gone down their own evolutionary paths. > > Is it FreeBSD or NetBSD?  Something else?  I don't think it would be Minix or Linux because I remember when they came along, and it was well after various Unix versions were around. > > Does such a thing even exist anymore?  I remember using AT&T Unix System V and various BSD variants back in college in the 1980's.  System V was the "new thing" back then but was eventually sold and seems to have faded.  Maybe it is only available commercially, but it does not seem as prominent as it once was. > > Any thoughts? > What exactly do you mean by "most direct descendant of Unix"? Are you specifically talking about Research Unix? Both USG (SysIII/SysV) and BSD are actually more like side branches from Research Unix, and neither is really a continuation of it. After V7, Research Unix continued until V10, but was barely distributed outside Bell Labs and had relatively little direct influence on anything else; these late Research Unix versions did incorporate significant amounts of code from the side branches that took over the mainstream (especially BSD, although there may have been a bit of USG code incorporated as well). I'd say the closest thing to "the most direct modern descendant of Research Unix" would be Plan 9, which continued the development of the networking and extensibility features of late Research Unix, but significantly broke compatibility with Unix (sometimes in ways that are IMO not really worth the incompatibility). Hi That's interesting.  I've been pondering this question for a while and suspected the answer is either "it doesn't exist" or "depends on who you ask" but I hadn't considered Research Unix.   For a long time, I considered AT&T System V to be the primary Unix descendant but have changed my mind and now not sure.  The question is simple, but the answer seems quite complicated. Thanks, Andrew Lynch -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Jun 6 03:34:58 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 05 Jun 2024 17:34:58 +0000 Subject: [TUHS] most direct Unix descendant In-Reply-To: <1324869037.1755756.1717582639424@mail.yahoo.com> References: <1324869037.1755756.1717582639424.ref@mail.yahoo.com> <1324869037.1755756.1717582639424@mail.yahoo.com> Message-ID: On Wednesday, June 5th, 2024 at 3:17 AM, Andrew Lynch via TUHS wrote: > Hi > > Out of curiosity, what would be considered the most direct descendent of Unix available today? > > ... > > Thanks, Andrew Lynch I don't think this question has one correct answer, rather, it really depends on your definition of purity. My two cents: >From a purely source code perspective, much of System V and its kin can be traced back to the Research implementations of various bits. Between V7 and V8, Research incorporated a fair deal of BSD, but at a time prior to the majority of BSD being reimplemented as unencumbered source code, so in many parts of the codebase, the actual source still very much was descended from V7, just with some BSD "accent" incorporated. To me one of the most notable userland divergences in the commercial stream is the init system, what with commercial UNIX aligning more with what is seen in CB (and allegedly USG Program Generic 3, but I have no direct proof, just speculation based on alleged manpages.) In any case, if you did a huge diff of the source code between say V7 and SVR4, you would likely find a fair deal of commonality, especially in userland. Taking an alternate viewpoint, BSD, while entirely rewritten, strove for functional compatibility with the bits that were being replaced, and in many ways BSD "behaved" more like Research, in reality and in "spirit". Again using the init system as an example, to this day the BSDs use an init system much closer to Research init than USGs run-level system. BSD also shows up in many more UNIX "places" than System V does. Indeed primarily System V distributions over time incorporate aspects of BSD due to their proliferation elsewhere in the UNIX world, much more than commercial backflow in the other direction. Given this, my humble opinion (which again this sort of thing I believe is largely a philosophical matter of opinion...) is that the BSD line captures the spirit of Research UNIX much more than System V does, while System V retains much more of the source code lineage of what most folks would consider a "pure" UNIX. Of course all of this too is predicated on treating V7 (really 32V...) as that central point of divergence. Good luck in your quest to find the answer to this question. I suspect it has no concrete answer and rather is one of those more philosophical quandaries that makes UNIX something worth pondering on this level. That all said, eventually I intend via my mandiff project to determine which of the three "last" historic UNIX manuals (SVR4, 4.4BSD, V10) has the highest parity with V7 literature, and similar work has been attempted via source code (D. Spinellis git repo[1]), so if that sort of quantitative analysis is more your cup of tea, then it may be possible to boil it down to ratios of "is and isn't V7" in codebases...but that sort of thing doesn't paint the full picture. That and the linked git repo doesn't incorporate System V for legal reasons...a bridge I haven't had to cross yet as I'm between V6 and V7 on my own analysis presently. One last disclaimer as I know this question can also stir up matters of pride, this is all opinion, and I think only can be opinion at this point, but my opinion is also only based on observations from afar. I wasn't a key player in this stuff, those folks' thoughts carry much more weight than mine do, but I also suspect, like good parents, folks with more heft to their involvement in things know the value in not playing favorites and letting their issue stand on their own. - Matt G. P.S. Can you tell this is one of my favorite questions to ponder :) [1] - https://github.com/dspinellis/unix-history-repo/branches/all?page=9 From will.senn at gmail.com Thu Jun 6 03:51:19 2024 From: will.senn at gmail.com (Will Senn) Date: Wed, 5 Jun 2024 12:51:19 -0500 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: <1324869037.1755756.1717582639424.ref@mail.yahoo.com> <1324869037.1755756.1717582639424@mail.yahoo.com> Message-ID: On 6/5/24 12:34 PM, segaloco via TUHS wrote: > On Wednesday, June 5th, 2024 at 3:17 AM, Andrew Lynch via TUHS wrote: > >> Hi >> >> Out of curiosity, what would be considered the most direct descendent of Unix available today? >> >> ... >> >> Thanks, Andrew Lynch > snip > Given this, my humble opinion (which again this sort of thing I believe is largely a philosophical matter of opinion...) is that the BSD line captures the spirit of Research UNIX much more than System V does, while System V retains much more of the source code lineage of what most folks would consider a "pure" UNIX. Of course all of this too is predicated on treating V7 (really 32V...) as that central point of divergence. When I saw this thread appear, I was of two minds about it, but this lines up with where my thoughts were headed. I've done a lot of delving into the v6/v7 environments over the last 10 years or so and it feels much closer in kinship to BSD derivatives than to SysV... source code lineages aside. Also, I get more mileage out of my BSD books and docs than those treating SysV. I'd vote for *BSD as sticking closest to the unix way, if there is still such a thing... I say this as I just typed 'kldload linux64' into freebsd's terminal so I could run sublime alongside nvi... sometimes I wish I was a purist, but I'm way too fond of experimentation :). Will From rminnich at gmail.com Thu Jun 6 04:02:16 2024 From: rminnich at gmail.com (ron minnich) Date: Wed, 5 Jun 2024 11:02:16 -0700 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: <1324869037.1755756.1717582639424.ref@mail.yahoo.com> <1324869037.1755756.1717582639424@mail.yahoo.com> Message-ID: You could argue that the most direct descendant is the one in which all resources are presented and accessed via open/read/write/close. If your kernel has separate system calls for reading directories, or setting up network connections, or debugging processes, then you may not be a direct descendant, at least philosophically (and, yes, I know about ptrace ...) But your kernel might be Plan 9, which at least to me, is the direct descendant. :-) On Wed, Jun 5, 2024 at 10:51 AM Will Senn wrote: > On 6/5/24 12:34 PM, segaloco via TUHS wrote: > > On Wednesday, June 5th, 2024 at 3:17 AM, Andrew Lynch via TUHS < > tuhs at tuhs.org> wrote: > > > >> Hi > >> > >> Out of curiosity, what would be considered the most direct descendent > of Unix available today? > >> > >> ... > >> > >> Thanks, Andrew Lynch > > snip > > Given this, my humble opinion (which again this sort of thing I believe > is largely a philosophical matter of opinion...) is that the BSD line > captures the spirit of Research UNIX much more than System V does, while > System V retains much more of the source code lineage of what most folks > would consider a "pure" UNIX. Of course all of this too is predicated on > treating V7 (really 32V...) as that central point of divergence. > When I saw this thread appear, I was of two minds about it, but this > lines up with where my thoughts were headed. I've done a lot of delving > into the v6/v7 environments over the last 10 years or so and it feels > much closer in kinship to BSD derivatives than to SysV... source code > lineages aside. Also, I get more mileage out of my BSD books and docs > than those treating SysV. I'd vote for *BSD as sticking closest to the > unix way, if there is still such a thing... I say this as I just typed > 'kldload linux64' into freebsd's terminal so I could run sublime > alongside nvi... sometimes I wish I was a purist, but I'm way too fond > of experimentation :). > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefftwopointzero at gmail.com Thu Jun 6 04:22:36 2024 From: jefftwopointzero at gmail.com (Jeffrey Joshua Rollin) Date: Wed, 5 Jun 2024 19:22:36 +0100 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: Following this line of thought, - and with the disclaimer that my own personal existence begins roughly where what has been called “The Last True UNIX” [Seventh Edition] ends, I’d say that, if ESR - who I know can be controversial - is correct, “BSD won in the marketplace, but System V won the standards wars” or words to that effect. With that in mind, and given that NetBSD was forked from 386BSD and in turn gave rise to the other BSDs around today, it would be my candidate for “most direct descendant available today,” particularly if we’re talking wide availability. (Whilst V1-6 and beyond were of course only available to users of business and academic mainframes and minicomputers, I’d argue that the other two contenders, Solaris and HP-UX, are sufficiently rare in comparison to the availability even of the open source BSD’s that the word “available” would be doing some rather heavy lifting if I were to include them.) The BSDs (except macOS and whatever SCO’s cash cow is called this evening) are also open source, of course, which is inline with the spirit of early Unix. I’ve not done an audit - and am not qualified to - but I suspect the main objection to this line of thinking is that despite the fact it still runs on VAX, it would not surprise me in the least to find that (excluding comments, perhaps), not a single line of code remains the same in NetBSD 10 (and indeed several versions prior) to the equivalent in V7 - and again, I’ve no idea how much of V1 remains in V7, nor (other than knowing it was written in assembly) how closely early PDP-11 versions resembled PDP-7 versions. By then, I suspect we really are getting into the Ship of Theseus problem - as the ancient Greeks would have been familiar with the issue, by the time every single plank of Theseus’ Ship has been replaced because the old ones have decayed, is it really the Ship of Theseus anymore? Plus of course, though it’s more a legal issue than a philosophical one, not only at least one version of Mach-based macOS, but also one distribution of Linux - which is known not to contain either Minix or UNIX code - have been certified as UNIX by The Open Group. My 2c Jeff Sent from my iPhone > On 5 Jun 2024, at 18:51, Will Senn wrote: > > On 6/5/24 12:34 PM, segaloco via TUHS wrote: >>> On Wednesday, June 5th, 2024 at 3:17 AM, Andrew Lynch via TUHS wrote: >>> >>> Hi >>> >>> Out of curiosity, what would be considered the most direct descendent of Unix available today? >>> >>> ... >>> >>> Thanks, Andrew Lynch >> snip >> Given this, my humble opinion (which again this sort of thing I believe is largely a philosophical matter of opinion...) is that the BSD line captures the spirit of Research UNIX much more than System V does, while System V retains much more of the source code lineage of what most folks would consider a "pure" UNIX. Of course all of this too is predicated on treating V7 (really 32V...) as that central point of divergence. > When I saw this thread appear, I was of two minds about it, but this lines up with where my thoughts were headed. I've done a lot of delving into the v6/v7 environments over the last 10 years or so and it feels much closer in kinship to BSD derivatives than to SysV... source code lineages aside. Also, I get more mileage out of my BSD books and docs than those treating SysV. I'd vote for *BSD as sticking closest to the unix way, if there is still such a thing... I say this as I just typed 'kldload linux64' into freebsd's terminal so I could run sublime alongside nvi... sometimes I wish I was a purist, but I'm way too fond of experimentation :). > > Will From imp at bsdimp.com Thu Jun 6 04:41:16 2024 From: imp at bsdimp.com (Warner Losh) Date: Wed, 5 Jun 2024 11:41:16 -0700 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: On Wed, Jun 5, 2024, 11:23 AM Jeffrey Joshua Rollin < jefftwopointzero at gmail.com> wrote: > Following this line of thought, - and with the disclaimer that my own > personal existence begins roughly where what has been called “The Last True > UNIX” [Seventh Edition] ends, I’d say that, if ESR - who I know can be > controversial - is correct, “BSD won in the marketplace, but System V won > the standards wars” or words to that effect. > > With that in mind, and given that NetBSD was forked from 386BSD and in > turn gave rise to the other BSDs around today, That is not true. FreeBSD imported the 386BSD plus patchkit patches into its CVS tree. It did not inport NetBSD's source, though NetBSD did import the same sources into their CVS repo days (or maybe weeks) earlier. Much of this early history, though, is not widely available as the early NetBSD and FreeBSD CVS repos are not available in their original form due to the AT&T lawsuit. And then the redo of these groups of the 4.4BSD import, the 4.4BSD-lite and lite 2 rebased both projects further muddy the waters since they now were both based on approximately the same pure from CSRG sources, rendering the earlier messiness perhaps moot. Or perhaps not, but not a point that has universal agreement, even among those involved in doing the work. It also gets muddy because of the original patchkit authors also spintered to for both NetBSD and FreeBSD in a way that's most kindly described as messy, so much spin was broadcast to characterize who was first or best. The truth is that the split was messy and definitive statements around this are troublesome at best. Warner it would be my candidate for “most direct descendant available today,” > particularly if we’re talking wide availability. (Whilst V1-6 and beyond > were of course only available to users of business and academic mainframes > and minicomputers, I’d argue that the other two contenders, Solaris and > HP-UX, are sufficiently rare in comparison to the availability even of the > open source BSD’s that the word “available” would be doing some rather > heavy lifting if I were to include them.) The BSDs (except macOS and > whatever SCO’s cash cow is called this evening) are also open source, of > course, which is inline with the spirit of early Unix. > > I’ve not done an audit - and am not qualified to - but I suspect the main > objection to this line of thinking is that despite the fact it still runs > on VAX, it would not surprise me in the least to find that (excluding > comments, perhaps), not a single line of code remains the same in NetBSD 10 > (and indeed several versions prior) to the equivalent in V7 - and again, > I’ve no idea how much of V1 remains in V7, nor (other than knowing it was > written in assembly) how closely early PDP-11 versions resembled PDP-7 > versions. By then, I suspect we really are getting into the Ship of Theseus > problem - as the ancient Greeks would have been familiar with the issue, by > the time every single plank of Theseus’ Ship has been replaced because the > old ones have decayed, is it really the Ship of Theseus anymore? > > Plus of course, though it’s more a legal issue than a philosophical one, > not only at least one version of Mach-based macOS, but also one > distribution of Linux - which is known not to contain either Minix or UNIX > code - have been certified as UNIX by The Open Group. > > My 2c > > Jeff > > Sent from my iPhone > > > On 5 Jun 2024, at 18:51, Will Senn wrote: > > > > On 6/5/24 12:34 PM, segaloco via TUHS wrote: > >>> On Wednesday, June 5th, 2024 at 3:17 AM, Andrew Lynch via TUHS < > tuhs at tuhs.org> wrote: > >>> > >>> Hi > >>> > >>> Out of curiosity, what would be considered the most direct descendent > of Unix available today? > >>> > >>> ... > >>> > >>> Thanks, Andrew Lynch > >> snip > >> Given this, my humble opinion (which again this sort of thing I believe > is largely a philosophical matter of opinion...) is that the BSD line > captures the spirit of Research UNIX much more than System V does, while > System V retains much more of the source code lineage of what most folks > would consider a "pure" UNIX. Of course all of this too is predicated on > treating V7 (really 32V...) as that central point of divergence. > > When I saw this thread appear, I was of two minds about it, but this > lines up with where my thoughts were headed. I've done a lot of delving > into the v6/v7 environments over the last 10 years or so and it feels much > closer in kinship to BSD derivatives than to SysV... source code lineages > aside. Also, I get more mileage out of my BSD books and docs than those > treating SysV. I'd vote for *BSD as sticking closest to the unix way, if > there is still such a thing... I say this as I just typed 'kldload linux64' > into freebsd's terminal so I could run sublime alongside nvi... sometimes I > wish I was a purist, but I'm way too fond of experimentation :). > > > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefftwopointzero at gmail.com Thu Jun 6 05:17:51 2024 From: jefftwopointzero at gmail.com (Jeffrey Joshua Rollin) Date: Wed, 5 Jun 2024 20:17:51 +0100 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From andreww591 at gmail.com Thu Jun 6 09:07:50 2024 From: andreww591 at gmail.com (Andrew Warkentin) Date: Wed, 5 Jun 2024 17:07:50 -0600 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: <1324869037.1755756.1717582639424.ref@mail.yahoo.com> <1324869037.1755756.1717582639424@mail.yahoo.com> Message-ID: On Wed, Jun 5, 2024 at 12:02 PM ron minnich wrote: > > You could argue that the most direct descendant is the one in which all resources are presented and accessed via open/read/write/close. > > If your kernel has separate system calls for reading directories, or setting up network connections, or debugging processes, then you may not be a direct descendant, at least philosophically (and, yes, I know about ptrace ...) > > But your kernel might be Plan 9, which at least to me, is the direct descendant. :-) > Even Plan 9's model is more like "all I/O is a file" and not "literally everything is a file", since regular process memory is still anonymous and fork()/rfork() are still system calls. I've never seen an OS that puts together the "all memory is a file" of Multics and the "all I/O is a file" of Plan 9. I think the one I'm working on is probably the first. Its public "system call" API (actually a jump table into a static shared library; the real microkernel system calls will be considered a private implementation detail) will just consist of read()/write()/seek()-like calls plus a few support functions to go with them; even things like open() and close() will be RPCs over a permanently-open channel file, and process/thread creation and memory allocation will be done through /proc (there will of course be a library interface over this that implements regular Unix APIs). From tuhs at tuhs.org Thu Jun 6 09:21:35 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 05 Jun 2024 23:21:35 +0000 Subject: [TUHS] Wiki Page on UNIX Standards Message-ID: Good day everyone, I just wanted to share that I've put up a bit of info as well as some book covers concerning UNIX standards that were published from the 80s til now: https://wiki.tuhs.org/doku.php?id=publications:standards I did my best to put down a bit of information about the /usr/group, POSIX, SVID, and SUS/Open Group standards, although there's certainly more to each story than what I put down there. Still, hopefully it serves to lay out a bit of the history of the actual standards produced over time. I'm kicking myself because one of the things I could've produced a picture of but didn't save at the time is the cover of IEEE 1003.2, a copy of this popped up on eBay some time in the past year and for reasons I can't recall I didn't order it, nor did I save the picture from the auction at the time. In any case, if anyone has any published standards that are not visually represented in this article, I'm happy to add any photos or scans you can provide to the page. Also pardon if the bit on spec 1170/SUS may be shorter than the others. Admittedly even having most of this on the desk in front of me right now, I'm fuzzy on the lines between POSIX, the Single UNIX Specification, the "Open Group Specification", spec 1170, etc. or if these are all names that ultimately just refer to different generations of the same thing. Part of getting this information put down is hoping someone will be along to correct inaccuracies :) Anywho, that's all for now. Feel free to suggest any corrections or additions! - Matt G. From tuhs at tuhs.org Thu Jun 6 09:47:33 2024 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Wed, 5 Jun 2024 16:47:33 -0700 Subject: [TUHS] Mike Karels has died In-Reply-To: <58f15238-c5f3-4e51-920b-c718ff616cff@case.edu> References: <58f15238-c5f3-4e51-920b-c718ff616cff@case.edu> Message-ID: <323e5137-236c-4d88-9d2a-2ff2356effaa@oracle.com> On 6/4/24 12:23, Chet Ramey via TUHS wrote: > Sad, horrible news. > > https://www.facebook.com/groups/BSDCan/permalink/10159552565206372/ For those who prefer non-Facebook links: https://io.mwl.io/@mwl/112558631795149050 https://freebsdfoundation.org/mike_karels/ https://twitter.com/cperciva/status/1798436210261823543 -alan- From ralph at inputplus.co.uk Thu Jun 6 19:55:02 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 06 Jun 2024 10:55:02 +0100 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: <20240606095502.AD4EE210F4@orac.inputplus.co.uk> Hi, There's a chart of the connections between Unix versions at https://en.wikipedia.org/wiki/List_of_Unix_systems, though I dislike the lack of direction given there are some arcs with little incline. It says it's based on https://www.levenez.com/unix/ where Éric notes his chart is not limited to just source-code transfer. -- Cheers, Ralph. From steffen at sdaoden.eu Fri Jun 7 05:49:01 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 06 Jun 2024 21:49:01 +0200 Subject: [TUHS] most direct Unix descendant In-Reply-To: <20240606095502.AD4EE210F4@orac.inputplus.co.uk> References: <20240606095502.AD4EE210F4@orac.inputplus.co.uk> Message-ID: <20240606194901.F5bDRUkh@steffen%sdaoden.eu> Ralph Corderoy wrote in <20240606095502.AD4EE210F4 at orac.inputplus.co.uk>: |There's a chart of the connections between Unix versions at |https://en.wikipedia.org/wiki/List_of_Unix_systems, though I dislike the |lack of direction given there are some arcs with little incline. |It says it's based on https://www.levenez.com/unix/ where Éric notes his |chart is not limited to just source-code transfer. I also admire that FreeBSD and NetBSD keep on maintaining the bsd-family-tree (and in the original form, not that dots thing, or how it was called). So that starts with First Edition (V1) | Second Edition (V2) | Third Edition (V3) | Fourth Edition (V4) | Fifth Edition (V5) | Sixth Edition (V6) -----* \ | \ | \ | Seventh Edition (V7)----|----------------------* \ | | \ 1BSD | 32V | | \ 2BSD---------------* | \ / | | \ / | | \/ | | 3BSD | | | | | 4.0BSD 2.79BSD | | | | 4.1BSD --------------> 2.8BSD <-* | | 4.1aBSD -----------\ | | \ | 4.1bBSD \ | | \ | *------ 4.1cBSD --------------> 2.9BSD / | | Eighth Edition | 2.9BSD-Seismo | | | +----<--- 4.2BSD 2.9.1BSD ... and says Multics 1965 UNIX Summer 1969 DEC PDP-7 First Edition 1971-11-03 [QCU] DEC PDP-11/20, Assembler Second Edition 1972-06-12 [QCU] 10 UNIX installations Third Edition 1973-02-xx [QCU] Pipes, 16 installations Fourth Edition 1973-11-xx [QCU] rewriting in C effected, above 30 installations Fifth Edition 1974-06-xx [QCU] above 50 installations Sixth Edition 1975-05-xx [QCU] port to DEC Vax Seventh Edition 1979-01-xx [QCU] 1979-01-10 [TUHS] first portable UNIX .. with a nice Bibliography with falsely underscored headline plus URL: https://cgit.freebsd.org/src/tree/share/misc/bsd-family-tree It also covers the system most of you are using (later). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Fri Jun 7 15:00:09 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 07 Jun 2024 05:00:09 +0000 Subject: [TUHS] CSRC Involvement in Non-UNIX AT&T Software Projects Message-ID: I'm reading about the Automatic Intercept System as discussed in BSTJ Vol. 53 No. 1 this evening. It is a stored program control call handling system designed to respond to calls with potential forwarding or disconnection messages. Reading through the description of the operating system for AIS got me wondering: What with the growing experience in the CSRC regarding kernel technologies and systems programming, was there ever any crossover regarding UNIX folks applying their developments to other non-UNIX AT&T systems projects or vice versa, perhaps folks who worked primarily on switching and support software bringing things over to the UNIX development camp? In other words, was there personnel cross-pollination between Bell System UNIX programmers and the folks working on stuff like AIS, ESS switching software, etc.? Or were the aims and implementation of such projects so different that the resources were relatively siloed? I would imagine some of these projects were at least developed using UNIX given the popularity and demands of PWB. That's just my hunch though, some BSTJs also describe software development and maintenance taking place on S/360 and S/370 machines and various PDPs. Indeed the development process for AIS mentioned above, as of late 1971, involved assembly via S/360 software and then system maintenance and debugging via an attached PDP-9. - Matt G. From kevin.bowling at kev009.com Fri Jun 7 15:32:40 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 6 Jun 2024 22:32:40 -0700 Subject: [TUHS] CSRC Involvement in Non-UNIX AT&T Software Projects In-Reply-To: References: Message-ID: On Thu, Jun 6, 2024 at 10:00 PM segaloco via TUHS wrote: > > I'm reading about the Automatic Intercept System as discussed in BSTJ Vol. 53 No. 1 this evening. It is a stored program control call handling system designed to respond to calls with potential forwarding or disconnection messages. Reading through the description of the operating system for AIS got me wondering: > > What with the growing experience in the CSRC regarding kernel technologies and systems programming, was there ever any crossover regarding UNIX folks applying their developments to other non-UNIX AT&T systems projects or vice versa, perhaps folks who worked primarily on switching and support software bringing things over to the UNIX development camp? In other words, was there personnel cross-pollination between Bell System UNIX programmers and the folks working on stuff like AIS, ESS switching software, etc.? Or were the aims and implementation of such projects so different that the resources were relatively siloed? https://en.wikipedia.org/wiki/Alexander_G._Fraser bio is an example of what you seem to be after > I would imagine some of these projects were at least developed using UNIX given the popularity and demands of PWB. That's just my hunch though, some BSTJs also describe software development and maintenance taking place on S/360 and S/370 machines and various PDPs. Indeed the development process for AIS mentioned above, as of late 1971, involved assembly via S/360 software and then system maintenance and debugging via an attached PDP-9. > > - Matt G. From arnold at skeeve.com Fri Jun 7 17:32:24 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 07 Jun 2024 01:32:24 -0600 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: Message-ID: <202406070732.4577WO39691963@freefriends.org> Warner Losh wrote: > At the risk of venturing too far off into the weeds (though maybe it's too > late for that) > > What do people think of the newer markup languages like Markdown or ASCII > Doctor? They seem more approachable than SGML or docbook, and a bit easier > to understand, though with less control, than troff, LaTeX or TeX. Having written books in troff, DocBook (SGML and XML), Texinfo and AsciiDoc, I can say that the latter two are much more pleasant that the former two. AsciiDoc is quite nice once you get to used to it, but sometimes getting it to layout things exactly the way you want can be difficult. Also, there aren't good free software toolchains for it to produce really nice output. The production process for the AsciiDoc book went AsciiDoc --> HTML --> Proprietary Formatter (Antenna House) --> PDF. I have not written much MarkDown, but I agree that it's too sparse for serious (book length) work. My two cents, Arnold From peter.martin.yardley at gmail.com Fri Jun 7 17:58:32 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Fri, 7 Jun 2024 17:58:32 +1000 Subject: [TUHS] Proliferation of book print styles In-Reply-To: References: <4CED5BE6-75C1-4A4B-B730-AF2A79150426@gmail.com> <9854affc-bc27-42fb-a294-3b0e7ea4d28d@ucsb.edu> Message-ID: <03F9B732-9EB0-4A02-9D35-C1E57A16E6F4@gmail.com> I can remember using Interleaf and Mentor Graphics “Doc”. Semi wysiwyg systems, both a pleasure to use once you got used to them. Interleaf was quite advanced and was used by a few publishing houses. Chapters were in separate files (helped at the time) brought together by an index file. Doc was used by Boeing and was designed to produce military grade SGML. It had multiple revision streams, potentially by different authors, which could be coloured to highlight changes. I wan’t trying to do any mathematics tho. > On 5 Jun 2024, at 8:54 AM, Dave Horsfall wrote: > > On Tue, 4 Jun 2024, Dave Horsfall wrote: > >> When working for Lionel Singer's Sun Australia (a Sun reseller), we had >> an entire room devoted to SunOS manuals; I wonder what happened to them >> (the manuals, I mean)? > > Sun *Computer* Australia, of course; sigh... > > -- Dave Peter Yardley peter.martin.yardley at gmail.com From douglas.mcilroy at dartmouth.edu Fri Jun 7 21:44:02 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 7 Jun 2024 07:44:02 -0400 Subject: [TUHS] CSRC Involvement in Non-UNIX AT&T Software Projects Message-ID: > was there ever any crossover regarding UNIX folks applying their developments to other non-UNIX AT&T systems Besides Sandy Fraser's long-term effort to advance digital communication (as distinct from digital transmission), there was TPC; see TUHS https://www.tuhs.org/pipermail/tuhs/2020-April/020802.html and other mentions of TPC in the TUHS archives. Ken Thompson did considerable handholding for early adopters of Unix for applications within the Bell System, notably tracking automatic trouble reports from switching systems and managing the workflow of craftspeople in a wire center. Bob Morris's intimate participation in a submarine signal-processing project that Bell Labs contracted to produce for the US Navy set him on a career path that led to becoming chief scientist at NSA's National Computer Security Center. Gerard Holtzmann collaborated to instill model-checking in switching and transmission projects. Andrew Hume spent much time with AT&T's call records. Lorinda Cherry single-handedly automated the analysis of call centers' notes on customer contacts, This enabled detection of significant human-engineering and public-relations problems. An important part of my role as a department head was to maintain contacts with development labs so that R and D were mutually aware of each other's problems and expertise. This encouraged consulting visits, internships, and occasionally extended collaboration or specific research projects as recounted above. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Jun 8 00:44:33 2024 From: will.senn at gmail.com (Will Senn) Date: Fri, 7 Jun 2024 09:44:33 -0500 Subject: [TUHS] diving into vi (nvi) - some observations from a slow learner Message-ID: Well, I really dove into using vi by way of nvi this past week and I have to say... the water's fine. It turns out that vi is a much simpler editor to understand and use (but no less powerful) than it's great grandchild, vim. To be fair, vim is an interesting editor and having used it off and on since the mid '90s, it's very familiar... but its powers? difficult to attain. vim stands as an excellent example of just how far you can take a product that works, keeping its core, but expanding it in all directions. No matter how much I tried to grasp its essence, it alluded me. The online help files seemed inscrutable to me, mixing environment settings, ex commands, ex mode commands, vi motions, insert mode commands in ways that seemed quite confusing to me. I know that I'm probably among a select few vim users that love it without really having a clue as to how it works. My best resource has been the web and search, but of late I've been wanting more. That's what drove me on this quest to really dig in to how things used to work and nvi is the best surrogate of the old ways that I could find (well, excluding heirloom vi, the traditional vi, which I've confirmed works pretty much the same way as nvi, with lisp support and without a few nice-to-haves nvi has). Anyway, here's something I worked out, after much travail - vi appears to be all about modes, movement, counts, operators, registers, and screens (which I found very weird at first, but simple in retrospect)... with these fundamentals down, it seems like you can do anything and I mean anything... and all of the other functions are just bolted on for the purpose of making their specific tasks work. Getting this out of the existing documentation was a mess. Thankfully the nvi docs (based on the 4.4 docs) are much slimmer and better organized. Even so, they make assumptions of the reader that I don't seem to fit. Take motions as prolly the most glaring example - all of the docs I've ever seen organize these by logical units of text (words, paras, etc), personally and apparently persistently, I think of motion as directed, so it took me a lot of experimentation, head scratching, and writing things out several times in several different ways to realize I could represent the idea on a single notecard as (some commands appear in multiple lines): Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H Rightward Movement - l|SP, e, E, w, W, $, ), }, ]] Upward motions - 1G, ^B, H, ^U, -, k | ^P Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N Absolute - | G Relative - %, H, M, L Marks - m, ', `, '', `` Keeping in mind that movements left-to-right are - section, para, sentence, line, text, word and endword (big, and small), and letter. And up and down are - file, screen, in screen (HML), half-screen, chars-in-line, and line. For me, this inversion from units of motion to direction of motion put forty some-odd commands in much closer reach for me. Looking back at the vim documentation, I see how its sheer volume and the way it is organized got in the way of my seeing the forest. Thankfully, in nvi, there are two incredibly useful ex commands to help - exu[sage] and viu[sage]. I simply printed these out and worked with them making the experimental assumption that they would serve as a baseline that represented the full capabilities of vi... and sure enough, after working and working with them, I am pretty confident they are sufficient for any editing task.  Wow, who knew? I loved vi, but now, I'm starting to really appreciate it's simplicity?! I can't believe those words are coming out of my mouth. I never thought of it as simple... those movement commands were far too numerous as I understood them. Are there things I miss from vim? Sure, I miss command line completion in ex mode, I want my help text to appear in a window where I can search, I would like better window control. But, I think I'll stick with nvi a while until I really nail it down. Then all of the cool stuff that vim offers, or neovim, will seem like icing on the cake that is vi. Thanks to Ken Thompson for writing a work of art that serves as the true core of this editor,  to Bill Joy for his great work in extending it, again to Bill Joy for bringing vi to life, and to Mary Ann for the macros and making it accessible to the rest of us, and others who contributed. It's 2024 and I still can't find a better terminal editor than vi... as it existed in the late '80s or as it exists today as nvi/vim/neovim. Amazing piece of software. Off to figure out tags!! Arg, seems like it oughtta be really useful in my work with source code, why can't I figure it out?! Sheesh. Will From ralph at inputplus.co.uk Sat Jun 8 01:41:20 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 07 Jun 2024 16:41:20 +0100 Subject: [TUHS] diving into vi (nvi) - some observations from a slow learner In-Reply-To: References: Message-ID: <20240607154120.08031210F3@orac.inputplus.co.uk> Hi Will, > But, I think I'll stick with nvi a while until I really nail it down. Something I used to do was to look at each key on the keyboard and think what it would do, e.g. d, D, and ^D. Most do at least one thing. > Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H > Rightward Movement - l|SP, e, E, w, W, $, ), }, ]] You're missing these handy six: f F t T ; , > Upward motions - 1G, ^B, H, ^U, -, k | ^P > Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N There's also keeping the cursor on the same line but moving the window over the text: z ^E ^Y > Off to figure out tags Understand the format of the tags file first; built by ctags(1). ^] on a word looks it up and goes there. Where you were is pushed on to the ‘tagstack’. When you wish to exit that rabbit hole, ^T pops the top of the stack and goes there which returns you to where you pressed ^]. $ func='foo bar xyzzy' $ printf "%s: $func"'\n' $func >src $ cat src foo: foo bar xyzzy bar: foo bar xyzzy xyzzy: foo bar xyzzy $ grep -n '[^:]*' src | awk -F: '{print $2 "\tsrc\t" $1}' >tags $ sed -n l tags foo\tsrc\t1$ bar\tsrc\t2$ xyzzy\tsrc\t3$ $ vi src, move to a word, ^] and it will move you to the ‘definition’ line. Imagine each line is a function definition with calls to other functions. You're wandering down and up a ‘call tree’, following possible execution paths. -- Cheers, Ralph. From will.senn at gmail.com Sat Jun 8 02:20:35 2024 From: will.senn at gmail.com (Will Senn) Date: Fri, 7 Jun 2024 11:20:35 -0500 Subject: [TUHS] diving into vi (nvi) - some observations from a slow learner In-Reply-To: <20240607154120.08031210F3@orac.inputplus.co.uk> References: <20240607154120.08031210F3@orac.inputplus.co.uk> Message-ID: <05302a0e-58b6-450c-8554-4546a409d603@gmail.com> Thanks for the tips, Ralph. I definitely learned the 6, but put 'em on a card with searching. Here's my motion card, including the scrolling commands, mark movement and a couple odd balls, to see how my mind works :) : https://decuser.github.io/assets/img/vi/motions-notecard.jpg On another note, I was reminded in an offline discussion that QED was the predecessor to ed - my history of tech always seems to glitch at the genesis of Unix. Of course the Unix pioneers didn't say "Let there be Unix and so mote it be" even though it may seems so to some of us. A lot of intellectual blood, sweat, and tears went into what came before and Ken Thompson definitely stood on the shoulders of Lampson, Deutsch, Kleene and others to create his masterpiece. Ritchie's partial history of QED https://www.bell-labs.com/usr/dmr/www/qed.html Deutsch & Lampson's work https://dl.acm.org/doi/pdf/10.1145/363848.363863 Thompson's innovation https://dl.acm.org/doi/pdf/10.1145/363347.363387 Kleene's indirect contribution (Automata<->Regular Expression) https://www.logicmatters.net/tyl/booknotes/kleene-metamath/ Later, Will On 6/7/24 10:41 AM, Ralph Corderoy wrote: > Hi Will, > >> But, I think I'll stick with nvi a while until I really nail it down. > Something I used to do was to look at each key on the keyboard and think > what it would do, e.g. d, D, and ^D. Most do at least one thing. > >> Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H >> Rightward Movement - l|SP, e, E, w, W, $, ), }, ]] > You're missing these handy six: f F t T ; , > >> Upward motions - 1G, ^B, H, ^U, -, k | ^P >> Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N > There's also keeping the cursor on the same line but moving the window > over the text: z ^E ^Y > >> Off to figure out tags > Understand the format of the tags file first; built by ctags(1). > ^] on a word looks it up and goes there. > Where you were is pushed on to the ‘tagstack’. > When you wish to exit that rabbit hole, ^T pops the top of the stack and > goes there which returns you to where you pressed ^]. > > $ func='foo bar xyzzy' > $ printf "%s: $func"'\n' $func >src > $ cat src > foo: foo bar xyzzy > bar: foo bar xyzzy > xyzzy: foo bar xyzzy > $ grep -n '[^:]*' src | awk -F: '{print $2 "\tsrc\t" $1}' >tags > $ sed -n l tags > foo\tsrc\t1$ > bar\tsrc\t2$ > xyzzy\tsrc\t3$ > $ > > vi src, move to a word, ^] and it will move you to the ‘definition’ > line. Imagine each line is a function definition with calls to other > functions. You're wandering down and up a ‘call tree’, following > possible execution paths. > From akosela at andykosela.com Sat Jun 8 02:58:14 2024 From: akosela at andykosela.com (Andy Kosela) Date: Fri, 7 Jun 2024 18:58:14 +0200 Subject: [TUHS] diving into vi (nvi) - some observations from a slow learner In-Reply-To: <05302a0e-58b6-450c-8554-4546a409d603@gmail.com> References: <20240607154120.08031210F3@orac.inputplus.co.uk> <05302a0e-58b6-450c-8554-4546a409d603@gmail.com> Message-ID: On Friday, June 7, 2024, Will Senn wrote: > Thanks for the tips, Ralph. I definitely learned the 6, but put 'em on a > card with searching. Here's my motion card, including the scrolling > commands, mark movement and a couple odd balls, to see how my mind works :) > : > > https://decuser.github.io/assets/img/vi/motions-notecard.jpg > > The best thing about vi/nvi/vim is that you do not need to know all the arcane commands for it to be usable. You can get along quite happily using just a small subset of them. The beauty of vi lies in the interface minimalism and ubiquity. It is still my favorite editor after all these years and still using it on Linux/*BSD/MS-DOS/AmigaOS. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrochkind at gmail.com Sat Jun 8 03:29:29 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Fri, 7 Jun 2024 11:29:29 -0600 Subject: [TUHS] diving into vi (nvi) - some observations from a slow learner In-Reply-To: References: Message-ID: For me, my introduction to vi came with my introduction to working on a CRT (which is what I think we called screens) after years with paper terminals and ed. Wow, it was so great! But, vi has a fundamental flaw: It's modal. For example, typing an "a" might enter the character "a", or it might initiate append mode. Having worked with computer beginners for about 50 years, I can say with assurance that this is very difficult to learn. We encountered this as early as the mid-1970s when we were trying to get mainframe programmers to use the Programmers Workbench. Other editors didn't work that way. I think emacs was non-modal, although I never used it. (Could be wrong.) That said, there's no question but that vi could be learned and, once learned, that it was extremely productive. If a program operates consistently, it can always be learned no matter how poor the UI is. This is not to diminish Bill Joy's accomplishment and not to acknowledge that he was severely limited by the hardware available to him. (Richard Stallman had a much better terminal.) But, sadly, vi continued to be promoted long after the hardware improved. It's very hard to dislodge something so entrenched! Much of UNIX was that way: Criticisms of its UI (notably Don Norman in 1981 or thereabouts) were refuted by those who had already learned UNIX. I recall that it was Mike Lesk who responded directly to Don Norman. (My memory is really stretching here.) Easy-to-learn and easy-to-use are very different, as we now all know. Marc On Fri, Jun 7, 2024 at 8:44 AM Will Senn wrote: > Well, I really dove into using vi by way of nvi this past week and I > have to say... the water's fine. It turns out that vi is a much simpler > editor to understand and use (but no less powerful) than it's great > grandchild, vim. To be fair, vim is an interesting editor and having > used it off and on since the mid '90s, it's very familiar... but its > powers? difficult to attain. > > vim stands as an excellent example of just how far you can take a > product that works, keeping its core, but expanding it in all > directions. No matter how much I tried to grasp its essence, it alluded > me. The online help files seemed inscrutable to me, mixing environment > settings, ex commands, ex mode commands, vi motions, insert mode > commands in ways that seemed quite confusing to me. I know that I'm > probably among a select few vim users that love it without really having > a clue as to how it works. My best resource has been the web and search, > but of late I've been wanting more. That's what drove me on this quest > to really dig in to how things used to work and nvi is the best > surrogate of the old ways that I could find (well, excluding heirloom > vi, the traditional vi, which I've confirmed works pretty much the same > way as nvi, with lisp support and without a few nice-to-haves nvi has). > > Anyway, here's something I worked out, after much travail - vi appears > to be all about modes, movement, counts, operators, registers, and > screens (which I found very weird at first, but simple in retrospect)... > with these fundamentals down, it seems like you can do anything and I > mean anything... and all of the other functions are just bolted on for > the purpose of making their specific tasks work. > > Getting this out of the existing documentation was a mess. Thankfully > the nvi docs (based on the 4.4 docs) are much slimmer and better > organized. Even so, they make assumptions of the reader that I don't > seem to fit. Take motions as prolly the most glaring example - all of > the docs I've ever seen organize these by logical units of text (words, > paras, etc), personally and apparently persistently, I think of motion > as directed, so it took me a lot of experimentation, head scratching, > and writing things out several times in several different ways to > realize I could represent the idea on a single notecard as (some > commands appear in multiple lines): > > Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H > Rightward Movement - l|SP, e, E, w, W, $, ), }, ]] > Upward motions - 1G, ^B, H, ^U, -, k | ^P > Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N > Absolute - | G > Relative - %, H, M, L > Marks - m, ', `, '', `` > > Keeping in mind that movements left-to-right are - section, para, > sentence, line, text, word and endword (big, and small), and letter. And > up and down are - file, screen, in screen (HML), half-screen, > chars-in-line, and line. For me, this inversion from units of motion to > direction of motion put forty some-odd commands in much closer reach for > me. Looking back at the vim documentation, I see how its sheer volume > and the way it is organized got in the way of my seeing the forest. > > Thankfully, in nvi, there are two incredibly useful ex commands to help > - exu[sage] and viu[sage]. I simply printed these out and worked with > them making the experimental assumption that they would serve as a > baseline that represented the full capabilities of vi... and sure > enough, after working and working with them, I am pretty confident they > are sufficient for any editing task. Wow, who knew? I loved vi, but > now, I'm starting to really appreciate it's simplicity?! I can't believe > those words are coming out of my mouth. I never thought of it as > simple... those movement commands were far too numerous as I understood > them. > > Are there things I miss from vim? Sure, I miss command line completion > in ex mode, I want my help text to appear in a window where I can > search, I would like better window control. But, I think I'll stick with > nvi a while until I really nail it down. Then all of the cool stuff that > vim offers, or neovim, will seem like icing on the cake that is vi. > > Thanks to Ken Thompson for writing a work of art that serves as the true > core of this editor, to Bill Joy for his great work in extending it, > again to Bill Joy for bringing vi to life, and to Mary Ann for the > macros and making it accessible to the rest of us, and others who > contributed. It's 2024 and I still can't find a better terminal editor > than vi... as it existed in the late '80s or as it exists today as > nvi/vim/neovim. Amazing piece of software. > > Off to figure out tags!! Arg, seems like it oughtta be really useful in > my work with source code, why can't I figure it out?! Sheesh. > > Will > -- *My new email address is mrochkind at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Jun 8 08:12:30 2024 From: tuhs at tuhs.org (Scot Jenkins via TUHS) Date: Fri, 07 Jun 2024 18:12:30 -0400 Subject: [TUHS] diving into vi (nvi) - some observations from a slow learner In-Reply-To: References: Message-ID: <202406072212.457MCUTa002433@sdf.org> Will Senn wrote: > vim stands as an excellent example of just how far you can take a > product that works, keeping its core, but expanding it in all > directions. vim has a *lot* of knobs to twist, all of which must be in just the right position for it to be comfortably usable, in my opinion. I got annoyed with many of the default features, like the auto indenting and getting stuck in comment mode. Start a comment in vim and try to get out of that mode. I found I spent too much time trying to figure out how to turn off these things so I generally went back to straight vi as my daily editor. I use ed(1) a lot too for quick edits. vim is great for the syntax highlighting when coding or editing HTML though. It makes it easy to spot errors. > Off to figure out tags!! Arg, seems like it oughtta be really useful in > my work with source code, why can't I figure it out?! Sheesh. I think the best way to learn vi/vim features is from watching someone else use it. You pick up a lot of useful tricks. Mike Shah has many great videos; here are a couple vi/vim related ones. 1. Why I'm Still using Vim in 2024 - A Brief Introduction and Demo https://www.youtube.com/watch?v=e4E6nQpd7Xs This is a good quick into to using vi/vim. 2. [Dlang Episode 31] D Language - ctags with dscanner for VIM (and ctags with phobos demonstration) https://www.youtube.com/watch?v=vMF7NxF_HFY While he uses the D programming language for this video, it is a great demo of how to use ctags. The principle is the same for other programming languages, ctags supports many, run: "ctags --list-languages" to view the full list. scot From dave at horsfall.org Sat Jun 8 14:44:48 2024 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 8 Jun 2024 14:44:48 +1000 (EST) Subject: [TUHS] diving into vi (nvi) - some observations from a slow learner In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024, Marc Rochkind wrote: > Other editors didn't work that way. I think emacs was non-modal, > although I never used it. (Could be wrong.) As the saying goes, EMACS is for people who can't remember what mode they're in :-) -- Dave From imp at bsdimp.com Sat Jun 8 14:50:55 2024 From: imp at bsdimp.com (Warner Losh) Date: Fri, 7 Jun 2024 22:50:55 -0600 Subject: [TUHS] diving into vi (nvi) - some observations from a slow learner In-Reply-To: References: Message-ID: On Fri, Jun 7, 2024, 10:45 PM Dave Horsfall wrote: > On Fri, 7 Jun 2024, Marc Rochkind wrote: > > > Other editors didn't work that way. I think emacs was non-modal, > > although I never used it. (Could be wrong.) > > As the saying goes, EMACS is for people who can't remember what mode > they're in :-) > One less thing helps us focus on ond more thing that actually matters :) Warner -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Sat Jun 8 11:58:02 2024 From: woods at robohack.ca (Greg A. Woods) Date: Fri, 07 Jun 2024 18:58:02 -0700 Subject: [TUHS] Old documentation - still the best In-Reply-To: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> References: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com> Message-ID: At Sat, 1 Jun 2024 20:59:42 -0500, Will Senn wrote: Subject: [TUHS] Old documentation - still the best > > Just the SH, TROFF and NROFF sections are > worth the effort of digging up this 40 > year old text. You might be interested in this one by the same author too: Title: Typesetting Tables on the UNIX System Author: Henry McGilton; Mary McNabb (With) Publisher: Trilithon Press Date: 1990-04 ISBN: 9780962628900 / 0962628905 https://archive.org/details/typesettingtable0000mcgi/mode/2up I found it invaluable back when I was using troff frequently, and it too is, IMHO, very well written. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From robpike at gmail.com Sat Jun 8 16:22:32 2024 From: robpike at gmail.com (Rob Pike) Date: Sat, 8 Jun 2024 16:22:32 +1000 Subject: [TUHS] diving into vi (nvi) - some observations from a slow learner In-Reply-To: References: Message-ID: https://9p.io/magic/man2html/1/vi is the manual for Plan 9's vi. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Sat Jun 8 20:19:12 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 08 Jun 2024 11:19:12 +0100 Subject: [TUHS] POSIX ed(1)'s exit status. (Was: diving into vi...) In-Reply-To: <202406072212.457MCUTa002433@sdf.org> References: <202406072212.457MCUTa002433@sdf.org> Message-ID: <20240608101912.3F8EF21FBE@orac.inputplus.co.uk> Hi, Will Senn wrote: > I use ed(1) a lot too for quick edits. Me too. I've heard others who have told crontab(1) or their mail program to use ed have been bitten by the exit status varying between 0 and 1. ed(1p) explains: EXIT STATUS The following exit values shall be returned: 0 Successful completion without any file or command errors. >0 An error occurred. This behaviour is surprising. Here's GNU ed: $ ed /tmp/foo /tmp/foo: No such file or directory a foo . wq 4 $ echo $? 0 $ ed /tmp/foo 4 /bar ? $a bar . wq 8 $ echo $? 1 $ I assume POSIX made it the default behaviour to be useful when ed isn't talking to mankind. Perhaps they think that's the default these days. GNU ed added -l: -l, --loose-exit-status exit with 0 status even if a command fails >From https://man.netbsd.org/ed.1, I don't think BSD ed has a similar option. Probably, because it doesn't need it as my quick skim of http://bxr.su/NetBSD/bin/ed/main.c#220 suggests it will exit(0) even if an earlier search found nothing. There is a list of BSD's differences to POSIX, e.g. ‘z’ for scrolling, amidst the source, http://bxr.su/NetBSD/bin/ed/POSIX, but it doesn't mention the exit status. -- Cheers, Ralph. From beebe at math.utah.edu Sun Jun 9 09:43:25 2024 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Sat, 8 Jun 2024 17:43:25 -0600 Subject: [TUHS] [tuhs] Early statistical software in Unix Message-ID: The book ``S: An Interactive Environment for Data Analysis and Graphics'' (Wadsworth, 1984), by Richard A. Becker and John M. Chambers, and an earlier Bell Labs report in 1981, introduced the S statistical software system that later evolved into the commercial S-Plus system (now defunct, I think), and the vibrant and active R system (https://cran.r-project.org/) that we use at Utah in our statistics courses. Almost 21,000 open-source packages for R are available, and they appear to be the dominant form of statistical software package publication, based on extensive evidence in our bibliography archives that completely cover numerous journals in probability and statistics. I'm interested in looking into the early S source code, if possible, to see how some statistical software that I am freshly implementing for high-precision computation was handled at Bell Labs more than four decades ago. Does anyone on this list know whether the original S system was ever distributed in source code to commercial sites, and academic sites, that licensed Unix from Bell Labs in the 1980s? Does that code still exist (and is openly accessible), or has it been lost? As with the B, C, D, and R programming languages, it is rather hard for Web search engines to find things that are known only by a single letter of the alphabet. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From egbegb2 at gmail.com Sun Jun 9 18:00:53 2024 From: egbegb2 at gmail.com (Ed Bradford) Date: Sun, 9 Jun 2024 03:00:53 -0500 Subject: [TUHS] most direct Unix descendant In-Reply-To: <20240606194901.F5bDRUkh@steffen%sdaoden.eu> References: <20240606095502.AD4EE210F4@orac.inputplus.co.uk> <20240606194901.F5bDRUkh@steffen%sdaoden.eu> Message-ID: Excellent responses here. Brings back so many great memories. My 1 cent would be to ask the question: Which of today's Unix variants (Linux, BSD, AIX, Cygwin, ...) is closest to the philosophy of the Ken-Denis-Doug versions of V6 Unix? All the variants I see today suffer from "complexification" - a John Mashey term. Documentation of commands today has grown 5 to 10 fold for each command in /usr/bin. V7 had less than 64 well documented system calls. Today's Linux, AIX, and others have how many? I don't know. The concept of producing a stream of text as the output of a program that does simple jobs well has been replaced by "power-shell" thinking of passing binary objects rather than text between program - a decidedly non-portable idea. Passing "objects" requires attaching to a dynamically linked library (that will change or even disappear with the next release of the OS or the object library). With Research Unix, I could pipe the output of a Unix program running on an Intel 486 to another program running on a Motorola 68000 or a Zilog Z80000 or an IBM AIX machine. IPhones, iPads, and my Android tablet don't have a usable text editor. All non-Unix text editors seem to struggle to offer a fixed width font. (Ever try to make columns line up on an iPhone or Android tablet?) Complexification rears its ugly head. I still use vi on both my Mac and PC (Cygwin). (I can't find a usable gvim for Mac and Macvim is weird but doesn't seem to know what a mouse is.) Unix brought automation to the forefront of possibilities. Using Unix, anyone could do it - even that kid in Jurassic Park. Today, everything is GUI and nothing can be automated easily or, most of the time, not at all. Unix is an ever shrinking oasis in a desert of non-automation and complexity. It is the loss of automation possibilities that frustrates me the most. (Don't mind me, I'm just outgassing for no good reason.) Ed On Thu, Jun 6, 2024 at 3:06 PM Steffen Nurpmeso wrote: > Ralph Corderoy wrote in > <20240606095502.AD4EE210F4 at orac.inputplus.co.uk>: > |There's a chart of the connections between Unix versions at > |https://en.wikipedia.org/wiki/List_of_Unix_systems, though I dislike the > |lack of direction given there are some arcs with little incline. > |It says it's based on https://www.levenez.com/unix/ where Éric notes his > |chart is not limited to just source-code transfer. > > I also admire that FreeBSD and NetBSD keep on maintaining the > bsd-family-tree (and in the original form, not that dots thing, or > how it was called). So that starts with > > First Edition (V1) > | > Second Edition (V2) > | > Third Edition (V3) > | > Fourth Edition (V4) > | > Fifth Edition (V5) > | > Sixth Edition (V6) -----* > \ | > \ | > \ | > Seventh Edition (V7)----|----------------------* > \ | | > \ 1BSD | > 32V | | > \ 2BSD---------------* | > \ / | | > \ / | | > \/ | | > 3BSD | | > | | | > 4.0BSD 2.79BSD | > | | | > 4.1BSD --------------> 2.8BSD <-* > | | > 4.1aBSD -----------\ | > | \ | > 4.1bBSD \ | > | \ | > *------ 4.1cBSD --------------> 2.9BSD > / | | > Eighth Edition | 2.9BSD-Seismo > | | | > +----<--- 4.2BSD 2.9.1BSD > ... > > and says > > Multics 1965 > UNIX Summer 1969 > DEC PDP-7 > First Edition 1971-11-03 [QCU] > DEC PDP-11/20, Assembler > Second Edition 1972-06-12 [QCU] > 10 UNIX installations > Third Edition 1973-02-xx [QCU] > Pipes, 16 installations > Fourth Edition 1973-11-xx [QCU] > rewriting in C effected, > above 30 installations > Fifth Edition 1974-06-xx [QCU] > above 50 installations > Sixth Edition 1975-05-xx [QCU] > port to DEC Vax > Seventh Edition 1979-01-xx [QCU] 1979-01-10 [TUHS] > first portable UNIX > .. > > with a nice Bibliography with falsely underscored headline plus > > URL: https://cgit.freebsd.org/src/tree/share/misc/bsd-family-tree > > It also covers the system most of you are using (later). > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sun Jun 9 21:34:46 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 9 Jun 2024 07:34:46 -0400 Subject: [TUHS] most direct Unix descendant Message-ID: Eloquently put. Amen! doug > Unix brought automation to the forefront of possibilities. Using Unix, > anyone could do it - even that kid in Jurassic Park. Today, everything > is GUI and nothing can be automated easily or, most of the time, > not at all. > Unix is an ever shrinking oasis in a desert of non-automation and complexity. > It is the loss of automation possibilities that frustrates me the most -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.phillip.garcia at gmail.com Sun Jun 9 21:59:00 2024 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sun, 9 Jun 2024 07:59:00 -0400 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: On Sun, Jun 9, 2024, 7:35 AM Douglas McIlroy wrote: > Eloquently put. Amen! > > doug > > > Unix brought automation to the forefront of possibilities. Using Unix, > > anyone could do it - even that kid in Jurassic Park. Today, everything > > is GUI and nothing can be automated easily or, most of the time, > > not at all. > > > Unix is an ever shrinking oasis in a desert of non-automation and > complexity. > > > It is the loss of automation possibilities that frustrates me the most > Do I have to be that guy? I hate windows. I love Unix. But the above isn't really true. MS has actually done a good job of catching up in that department. All major apps have Powershell libraries. I envy some features of Powershell, but I still won't use it unless I have to. One example is PowerCLI, which is very useful for vSphere automation. Easier to use than their other language APIs, in my opinion. I could go on with other examples (Active Directory, MSSQL, Exchange), but I think the point is made... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Sun Jun 9 22:31:55 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 09 Jun 2024 13:31:55 +0100 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: <20240609123155.7C72220152@orac.inputplus.co.uk> Hi A. P., > All major apps have Powershell libraries. I envy some features of > Powershell, but I still won't use it unless I have to. > > One example is PowerCLI, which is very useful for vSphere automation. > Easier to use than their other language APIs, in my opinion. The grandfather of your post address Powershell earlier on. https://www.tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/message/QZVFRCYM2MEJ4VNZPORBUAKIS6WG6LIY/ > The concept of producing a stream of text as the output of a program > that does simple jobs well has been replaced by "power-shell" thinking > of passing binary objects rather than text between program > - a decidedly non-portable idea. > > Passing "objects" requires attaching to a dynamically linked library > (that will change or even disappear with the next release of the OS or > the object library). With Research Unix, I could pipe the output of > a Unix program running on an Intel 486 to another program running on > a Motorola 68000 or a Zilog Z80000 or an IBM AIX machine. -- Cheers, Ralph. From a.phillip.garcia at gmail.com Mon Jun 10 00:06:00 2024 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sun, 9 Jun 2024 10:06:00 -0400 Subject: [TUHS] most direct Unix descendant In-Reply-To: <20240609123155.7C72220152@orac.inputplus.co.uk> References: <20240609123155.7C72220152@orac.inputplus.co.uk> Message-ID: On Sun, Jun 9, 2024, 8:40 AM Ralph Corderoy wrote: > Hi A. P., > > > All major apps have Powershell libraries. I envy some features of > > Powershell, but I still won't use it unless I have to. > > > > One example is PowerCLI, which is very useful for vSphere automation. > > Easier to use than their other language APIs, in my opinion. > > The grandfather of your post address Powershell earlier on. > > > https://www.tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/message/QZVFRCYM2MEJ4VNZPORBUAKIS6WG6LIY/ > > The concept of producing a stream of text as the output of a program > > that does simple jobs well has been replaced by "power-shell" thinking > > of passing binary objects rather than text between program > > - a decidedly non-portable idea. > > > > Passing "objects" requires attaching to a dynamically linked library > > (that will change or even disappear with the next release of the OS or > > the object library). With Research Unix, I could pipe the output of > > a Unix program running on an Intel 486 to another program running on > > a Motorola 68000 or a Zilog Z80000 or an IBM AIX machine. > > -- > Cheers, Ralph. > Thank you, I hadn't seen that. He's right, of course. It's kludgy, but you can always use text, or some structured form of it like json or xml, to communicate between different machines. Does windows have something like netcat/socat? I honestly don't know. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egbegb2 at gmail.com Mon Jun 10 15:13:08 2024 From: egbegb2 at gmail.com (Ed Bradford) Date: Mon, 10 Jun 2024 00:13:08 -0500 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: Hi A.P., I agree powershell supports automation. However, it so complex and non-portable that even learning about it and how to use it takes considerably longer than learning about Unix automation. It puts a significant burden on developers to document their DLL's and make the interfaces permanent. Complexity produces more expensive and less reliable software. BTW, what about the non-major apps? From your view, they are simply excluded from automation. In PS, type "help cmdlet" to see the complexity of each and every command. PS does allow automation, but it is very expensive because most people will be daunted when trying to learn how to solve problems with it, people who know how to write stuff in PS are more expensive employees, and development time for asking a simple question like "Show me the last 5 files read in a directory tree" can require days or more of research and experimentation. A help page on almost any cmdlet produces a full page-width pages of options, many of which lead to further questions about usage. Yes, PS automates Windows -- but at what cost? Ed PS: I should write my book of "Why Windows is not my favorite operating system" (paraphrasing a famous BTL TM). PS2: Speaking of complexity and documentation, here is the start of the printout on an up-to-date MacOS of the command man ls | less *NAME ls – list directory contents SYNOPSIS ls [- at ABCFGHILOPRSTUWabcdefghiklmnopqrstuvwxy1%,] [--color=when] [-D format] [file ...]* and the same question about "ls" on Windows 11 powershell: help ls | less # typed in PS [image: image.png] How did we let this happen? On Sun, Jun 9, 2024 at 6:59 AM A. P. Garcia wrote: > > > On Sun, Jun 9, 2024, 7:35 AM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> Eloquently put. Amen! >> >> doug >> >> > Unix brought automation to the forefront of possibilities. Using Unix, >> > anyone could do it - even that kid in Jurassic Park. Today, everything >> > is GUI and nothing can be automated easily or, most of the time, >> > not at all. >> >> > Unix is an ever shrinking oasis in a desert of non-automation and >> complexity. >> >> > It is the loss of automation possibilities that frustrates me the most >> > > > Do I have to be that guy? I hate windows. I love Unix. But the above isn't > really true. MS has actually done a good job of catching up in that > department. All major apps have Powershell libraries. I envy some features > of Powershell, but I still won't use it unless I have to. > > One example is PowerCLI, which is very useful for vSphere automation. > Easier to use than their other language APIs, in my opinion. I could go on > with other examples (Active Directory, MSSQL, Exchange), but I think the > point is made... > >> -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 86182 bytes Desc: not available URL: From g.branden.robinson at gmail.com Mon Jun 10 15:25:50 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 10 Jun 2024 00:25:50 -0500 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: <20240610052550.5waad35xzozzipwz@illithid> At 2024-06-10T00:13:08-0500, Ed Bradford wrote: > PS2: Speaking of complexity and documentation, here is the start > of the printout on an up-to-date MacOS of the command > > man ls | less [...] > How did we let this happen? When "everything is a file", a lot gets packed into one's file abstraction. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dave at horsfall.org Mon Jun 10 18:39:40 2024 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 10 Jun 2024 18:39:40 +1000 (EST) Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: On Mon, 10 Jun 2024, Ed Bradford wrote: > [...] people who know how to write stuff in PS are more expensive > employees, and development time for asking a simple question like > >   "Show me the last 5 files read in a directory tree" Likely a one-liner in Unix :-) -- Dave From marc.donner at gmail.com Mon Jun 10 19:36:32 2024 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 10 Jun 2024 05:36:32 -0400 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: The architectural alternative to powershell-style extension has been around in various guises for a while. In particular things like TCL and Lua are engineered to be add-on extension languages. Integrating them just involves adding a few callouts (dispatch a “program”, scan directories in a designated “path” for programs, render internal structures into text). This style of design has been around for a long time - all Unix shells, EMacs, many video games. It enables an elegant approach to performance management - build it first as a script and only reimplement it as a binary if needed. Doing this enables automation, but it does require the designers and product managers to want automation. Marc ===== nygeek.net mindthegapdialogs.com/home On Mon, Jun 10, 2024 at 4:39 AM Dave Horsfall wrote: > On Mon, 10 Jun 2024, Ed Bradford wrote: > > > [...] people who know how to write stuff in PS are more expensive > > employees, and development time for asking a simple question like > > > > "Show me the last 5 files read in a directory tree" > > Likely a one-liner in Unix :-) > > -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Mon Jun 10 22:33:27 2024 From: will.senn at gmail.com (Will Senn) Date: Mon, 10 Jun 2024 07:33:27 -0500 Subject: [TUHS] PID 0 and the scheduler Message-ID: <8d74aed5-957d-493b-9aab-0c647dd64018@gmail.com> All, There's an interesting dive into PID 0 linked to from osnews: https://blog.dave.tf/post/linux-pid0/ In the article, the author delves into the history of the scheduler a bit - going back to Unix v4 (his assembly language skills don't go to PDP variants). I like the article for two reasons - 1) it's clarity 2) it points out the self-reinforcing nature of our search ecosystem. I'm left with the question - how did scheduling work in v0-v4? and the observation that search really sucks these days. Later, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsc at swtch.com Tue Jun 11 03:02:56 2024 From: rsc at swtch.com (Russ Cox) Date: Mon, 10 Jun 2024 13:02:56 -0400 Subject: [TUHS] PID 0 and the scheduler In-Reply-To: <8d74aed5-957d-493b-9aab-0c647dd64018@gmail.com> References: <8d74aed5-957d-493b-9aab-0c647dd64018@gmail.com> Message-ID: On Mon, Jun 10, 2024 at 8:33 AM Will Senn wrote: > There's an interesting dive into PID 0 linked to from osnews: > https://blog.dave.tf/post/linux-pid0/ > In the article, the author delves into the history of the scheduler a bit > - going back to Unix v4 (his assembly language skills don't go to PDP > variants). > I like the article for two reasons - 1) it's clarity 2) it points out the > self-reinforcing nature of our search ecosystem. > I'm left with the question - how did scheduling work in v0-v4? and the > observation that search really sucks these days. > It's an interesting and well-written article, but I think it's not quite correct. It links to sched in the V4 code [1] but there's nothing there about pid 0. The right place to link would be the code in main that installs the "system process" into the process table [2]. So yes, in V4, the scheduler is a process in a meaningful sense, but I don't think pid 0 is a meaningful process identifier for it. Nothing actually *identifies* the scheduler by using the number 0. After a process has exited and its parent has called wait, its process table entry is set to p_pid = 0 [3]. Surely pid 0 does not also identify those processes at the same time that it identifies the system process. If there are many processes in the table with pid 0, it's difficult to see pid 0 as any kind of identifier at all! Instead it seems pretty clear that pid 0 represents the concept "no pid". This makes sense since the kernel memory started out zeroed, so using the zero pid for "nothing here" avoided separate reinitialization. The same is true for process status 0 meaning "unused". Similarly, inode 0 is "no inode" (useful to mark the end of a directory entry list), and disk block number 0 is "no block" (useful to mark an unallocated block in a file). (Go's emphasis on meaningful zero values is in the same spirit.) Reading the V1 sources seems to confirm this hypothesis: V1 does not have a process table for any kernel process, and yet it still uses pid 1 for the first process [4]. In V1 the user struct has a u.uno field holding the process number as an index into the process table. That field too is 1-indexed, because it is convenient for u.uno==0 to mean "no process". In particular, swap (analogous here to V4 swtch) understood that if called when u.uno==0 the process is exiting and need not be saved for reactivation [5]. The kernel goes out of its way to use u.uno==0 instead of u.uno==-1: all the code that indexes an array by u.uno has to subtract 1 (or 2 for words) from the address being indexed to account for the first entry being 1 and not 0. Presumably this is because of wanting to use zero value as "no uno". (And it's not any less efficient, since the -1 or -2 can be applied to the base address during linking.) The obvious question to ask then is not why pids start at 1 but why, in contrast to all these examples, uids start at 0. My guess is that there was simply no need for "no uid" and in contrast having the zero value mean "root" worked out nicely. Perhaps Ken will correct me if I'm reading this all wrong. As to the question of how scheduling worked in V1, the swap code is walking over runq looking for the highest priority runnable process [6]. Every process image except the one running was saved on disk, so the only decision was which one to read back in. This is in contrast to the V4 scheduler, which is juggling multiple in-memory process images at once and split out the decisions about what to run from the code that moved processes to and from the disk. Best, Russ [1] https://github.com/dspinellis/unix-history-repo/blob/Research-V4/sys/ken/slp.c#L89 [2] https://github.com/dspinellis/unix-history-repo/blob/Research-V4/sys/ken/main.c#L55 [3] https://github.com/dspinellis/unix-history-repo/blob/Research-V4/sys/ken/sys1.c#L247 [4] https://github.com/dspinellis/unix-history-repo/blob/Research-V1/u0.s#L200 [5] https://github.com/dspinellis/unix-history-repo/blob/Research-V1/u3.s#L40 [6] https://github.com/dspinellis/unix-history-repo/blob/Research-V1/u3.s#L9 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Jun 11 05:40:53 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 10 Jun 2024 21:40:53 +0200 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: Message-ID: <20240610194053.JfHirqmk@steffen%sdaoden.eu> Marc Donner wrote in : |The architectural alternative to powershell-style extension has been around |in various guises for a while. In particular things like TCL and Lua are |engineered to be add-on extension languages. Integrating them just |involves adding a few callouts (dispatch a “program”, scan directories in a |designated “path” for programs, render internal structures into text). | |This style of design has been around for a long time - all Unix shells, |EMacs, many video games. | |It enables an elegant approach to performance management - build it first |as a script and only reimplement it as a binary if needed. | |Doing this enables automation, but it does require the designers and |product managers to want automation. Let me be the one who feed the silent head shakers with the Rob Pike quote "[just] make it strings". Of course lua hooks are faster, and i am looking forward myself, but other than that textual input/output communication with a program is language-neutral and somehow humanic. So now the time has come to point to an influential -- for me -- manual from 2001, that goes into assembler programming for x86: https://docs.freebsd.org/en/books/developers-handbook/x86/ And there you read things like A.12. One-Pointed Mind As a student of Zen, I like the idea of a one-pointed mind: Do one thing at a time, and do it well. This, indeed, is very much how UNIX® works as well. While a typical Windows® application is attempting to do everything imaginable (and is, therefore, riddled with bugs), a typical UNIX® program does only one thing, and it does it well. The typical UNIX® user then essentially assembles his own applications by writing a shell script which combines the various existing programs by piping the output of one program to the input of another. When writing your own UNIX® software, it is generally a good idea to see what parts of the problem you need to solve can be handled by existing programs, and only write your own programs for that part of the problem that you do not have an existing solution for. And going over A.13.2. Excursion to Pinhole Photography we come to the A.13.3.1. Processing Program Input which was a stunning read for me (the 15+ years before i came via Commodore 64 and its Basic, over Windows 3.1 and Windows 95 and, alongside, DOS, later 4DOS (then perl etc.)), because when doing really, really important things like calculating the cubic capacity of ones penis' in cubic millimeters (to end up with large numbers, say), i would never have thought by myself that the program accept and parse running text! (There you see that something "big" can actually be pretty "small" indeed.) Personally, I like to keep it simple. Something either is a number, so I process it. Or it is not a number, so I discard it. I do not like the computer complaining about me typing in an extra character when it is obvious that it is an extra character. Duh. Plus, it allows me to break up the monotony of computing and type in a query instead of just a number: What is the best pinhole diameter for the focal length of 150? There is no reason for the computer to spit out a number of complaints: Syntax error: What Syntax error: is Syntax error: the Syntax error: best Et cetera, et cetera, et cetera. And this (assembler!) then goes to % pinhole Computer, What size pinhole do I need for the focal length of 150? 150 490 306 362 2930 12 Hmmm... How about 160? 160 506 316 362 3125 12 Let's make it 155, please. 155 498 311 362 3027 12 Ah, let's try 157... 157 501 313 362 3066 12 156? 156 500 312 362 3047 12 That's it! Perfect! Thank you very much! ^D which is not even handled by GNU getopt with its argument-resorting behaviour! But it is likely that you all do not need that no more anyway, since you likely just speak out (silently at "Hal" level) "Hey computer bla bla", and the AI does the rest itself. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From marc.donner at gmail.com Tue Jun 11 06:09:47 2024 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 10 Jun 2024 16:09:47 -0400 Subject: [TUHS] most direct Unix descendant In-Reply-To: <20240610194053.JfHirqmk@steffen%sdaoden.eu> References: <20240610194053.JfHirqmk@steffen%sdaoden.eu> Message-ID: Totally correct - in the words of the immortal Beatles - "Strings is all you need." ===== nygeek.net mindthegapdialogs.com/home On Mon, Jun 10, 2024 at 3:40 PM Steffen Nurpmeso wrote: > Marc Donner wrote in > : > |The architectural alternative to powershell-style extension has been > around > |in various guises for a while. In particular things like TCL and Lua are > |engineered to be add-on extension languages. Integrating them just > |involves adding a few callouts (dispatch a “program”, scan directories > in a > |designated “path” for programs, render internal structures into text). > | > |This style of design has been around for a long time - all Unix shells, > |EMacs, many video games. > | > |It enables an elegant approach to performance management - build it first > |as a script and only reimplement it as a binary if needed. > | > |Doing this enables automation, but it does require the designers and > |product managers to want automation. > > Let me be the one who feed the silent head shakers with the > Rob Pike quote "[just] make it strings". > > Of course lua hooks are faster, and i am looking forward myself, > but other than that textual input/output communication with > a program is language-neutral and somehow humanic. > > So now the time has come to point to an influential -- for me -- > manual from 2001, that goes into assembler programming for x86: > > https://docs.freebsd.org/en/books/developers-handbook/x86/ > > And there you read things like > > A.12. One-Pointed Mind > > As a student of Zen, I like the idea of a one-pointed mind: Do > one thing at a time, and do it well. > > This, indeed, is very much how UNIX® works as well. While > a typical Windows® application is attempting to do everything > imaginable (and is, therefore, riddled with bugs), a typical > UNIX® program does only one thing, and it does it well. > > The typical UNIX® user then essentially assembles his own > applications by writing a shell script which combines the > various existing programs by piping the output of one program to > the input of another. > > When writing your own UNIX® software, it is generally a good > idea to see what parts of the problem you need to solve can be > handled by existing programs, and only write your own programs > for that part of the problem that you do not have an existing > solution for. > > And going over > > A.13.2. Excursion to Pinhole Photography > > we come to the > > A.13.3.1. Processing Program Input > > which was a stunning read for me (the 15+ years before i came via > Commodore 64 and its Basic, over Windows 3.1 and Windows 95 and, > alongside, DOS, later 4DOS (then perl etc.)), because when doing > really, really important things like calculating the cubic > capacity of ones penis' in cubic millimeters (to end up with large > numbers, say), i would never have thought by myself that the > program accept and parse running text! (There you see that > something "big" can actually be pretty "small" indeed.) > > Personally, I like to keep it simple. Something either is > a number, so I process it. Or it is not a number, so I discard > it. I do not like the computer complaining about me typing in an > extra character when it is obvious that it is an extra > character. Duh. > > Plus, it allows me to break up the monotony of computing and > type in a query instead of just a number: > > What is the best pinhole diameter for the focal length of 150? > > There is no reason for the computer to spit out a number of complaints: > > Syntax error: What > Syntax error: is > Syntax error: the > Syntax error: best > > Et cetera, et cetera, et cetera. > > And this (assembler!) then goes to > > % pinhole > > Computer, > > What size pinhole do I need for the focal length of 150? > 150 490 306 362 2930 12 > Hmmm... How about 160? > 160 506 316 362 3125 12 > Let's make it 155, please. > 155 498 311 362 3027 12 > Ah, let's try 157... > 157 501 313 362 3066 12 > 156? > 156 500 312 362 3047 12 > That's it! Perfect! Thank you very much! > ^D > > which is not even handled by GNU getopt with its > argument-resorting behaviour! > But it is likely that you all do not need that no more anyway, > since you likely just speak out (silently at "Hal" level) "Hey > computer bla bla", and the AI does the rest itself. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Jun 11 06:19:15 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 10 Jun 2024 22:19:15 +0200 Subject: [TUHS] most direct Unix descendant In-Reply-To: References: <20240610194053.JfHirqmk@steffen%sdaoden.eu> Message-ID: <20240610201915.vRvGE93Y@steffen%sdaoden.eu> Marc Donner wrote in : |Totally correct - in the words of the immortal Beatles - "Strings is all |you need." Sounds a bit like a somewhat pissed younger John Lennon? Iggy's "put some strings, you know" on some of those photograph seamy American carpets. (Of course -- i have no idea of what i am talking about.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From frew at ucsb.edu Tue Jun 11 13:15:29 2024 From: frew at ucsb.edu (James Frew) Date: Mon, 10 Jun 2024 20:15:29 -0700 Subject: [TUHS] Likely a one-liner in Unix In-Reply-To: References: Message-ID: OK, I'll bite (NB: using GNU find): find "$directory_tree" -type f -printf "%A+ %p\n" | sort -r | cut -d' ' -f2 | head -5 Cheers, /Frew On 2024-06-10 01:39, Dave Horsfall wrote: > On Mon, 10 Jun 2024, Ed Bradford wrote: > >> [...] people who know how to write stuff in PS are more expensive >> employees, and development time for asking a simple question like >> >>   "Show me the last 5 files read in a directory tree" > Likely a one-liner in Unix :-) > > -- Dave From tuhs at tuhs.org Tue Jun 11 16:06:37 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 11 Jun 2024 06:06:37 +0000 Subject: [TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001) Message-ID: Good evening, while I'm still waiting on the full uploads to progress (it's like there's a rule any >100MB upload to archive.org for me has to fail like 5 times before it'll finally go...) I decided to scrape out the UNIX RTR manual from a recent trove of 5ESS materials I received and tossed it up in a separate upload: https://archive.org/details/5ess-switch-unix-rtr-operating-system-reference-manual-issue-10 This time around I've got Issue 10 from December 2001. The last issue of this particular manual I found on another 5ESS disc is Issue 7 from 1998 which I shared previously (https://ia601200.us.archive.org/view_archive.php?archive=%2F12%2Fitems%2F5ess-switch-dk5e-cd-1999-05%2F5ESS-DK5E.zip&file=5EDOCS%2F93447.PDF) The manual is in "DynaText" format on the CD in question, unlike Issue 7 which was already a PDF on its respective CD. I used print-to-PDF to generate the above linked copy. Given that the CD itself is from 2007, this may point to UNIX RTR having no significant user-visible changes from 2001 to 2007 that would've necessitated manual revisions. In any case, I intend to upload bin/cue images of all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the administrative and maintenance points of view. Once I get archive.org to choke these files down I also intend to go back around to the discs I've already archived and reupload them as proper bin/cue rips. I was in a hurry the last time around and simply zipped the contents from the discs, but aside from just being good archive practice, I think bin/cue is necessary for the other discs as they seem to have control information in the disc header that is required by the interactive documentation viewers therein. All that to say, the first pass will result in bin/cues which aren't easily readable through archive.org's interface, but I intend to also swing back around on these new discs and provide zips of the contents as well to ensure the archives are both correct (bin/cue) and easily navigable (zip). As always, if you have any such documentation or leads on where any may be awaiting archival, I'm happy to take on the work! - Matt G. From kevin.bowling at kev009.com Tue Jun 11 16:59:38 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 10 Jun 2024 23:59:38 -0700 Subject: [TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001) In-Reply-To: References: Message-ID: On Mon, Jun 10, 2024 at 11:06 PM segaloco via TUHS wrote: > > Good evening, while I'm still waiting on the full uploads to progress (it's like there's a rule any >100MB upload to archive.org for me has to fail like 5 times before it'll finally go...) I decided to scrape out the UNIX RTR manual from a recent trove of 5ESS materials I received and tossed it up in a separate upload: > > https://archive.org/details/5ess-switch-unix-rtr-operating-system-reference-manual-issue-10 > > This time around I've got Issue 10 from December 2001. The last issue of this particular manual I found on another 5ESS disc is Issue 7 from 1998 which I shared previously (https://ia601200.us.archive.org/view_archive.php?archive=%2F12%2Fitems%2F5ess-switch-dk5e-cd-1999-05%2F5ESS-DK5E.zip&file=5EDOCS%2F93447.PDF) > > The manual is in "DynaText" format on the CD in question, unlike Issue 7 which was already a PDF on its respective CD. I used print-to-PDF to generate the above linked copy. Given that the CD itself is from 2007, this may point to UNIX RTR having no significant user-visible changes from 2001 to 2007 that would've necessitated manual revisions. > > In any case, I intend to upload bin/cue images of all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the administrative and maintenance points of view. Once I get archive.org to choke these files down I also intend to go back around to the discs I've already archived and reupload them as proper bin/cue rips. I was in a hurry the last time around and simply zipped the contents from the discs, but aside from just being good archive practice, I think bin/cue is necessary for the other discs as they seem to have control information in the disc header that is required by the interactive documentation viewers therein. > I have some of these CDs already and can compare notes with you: DK5E-CD from 2004, OA&M from 2008. I think you can just copy the SGML files to a HDD once you have DynaText installed, so whatever is funky about the CDs is not terribly important for use aside from the fidelity of your archival. Some of my CDs also use something called Eloquent Presenter which seems like a HyperCard style program. All the docs that aren't SGML are PDF, including most of the schematics, plenty which look like scans of originals. > All that to say, the first pass will result in bin/cues which aren't easily readable through archive.org's interface, but I intend to also swing back around on these new discs and provide zips of the contents as well to ensure the archives are both correct (bin/cue) and easily navigable (zip). > > As always, if you have any such documentation or leads on where any may be awaiting archival, I'm happy to take on the work! FWIW I have a fully working 5ESS that I turned off last week (actually a 7 R/E - 3B21D, CM3 (Global Message Server), 20k lines a mix of POTS, ISDN, PRI trunks) and it is coming home with me at the end of the month. Small matters of loading, unloading, AC PDU and getting a sizable DC power plant and unbounded wiring are in my future. Why? I dunno but full send. I need to have a think on how to be public with all this going forward, I do want to share the system and the goal is historical preservation and learning with interested parties. > - Matt G. From ralph at inputplus.co.uk Tue Jun 11 18:05:06 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 11 Jun 2024 09:05:06 +0100 Subject: [TUHS] Likely a one-liner in Unix In-Reply-To: References: Message-ID: <20240611080506.73D7B21309@orac.inputplus.co.uk> Hi James, > > >   "Show me the last 5 files read in a directory tree" Given sort(1) gained -u for efficiency, I've often wondered why, in those constrained times, it didn't have a ‘-m n’ to output only the n ‘minimums’, e.g. ‘sed ${n}q’. With ‘-m 5’, this would let sort track the current fifth entry and discard input which was bigger, so avoiding both storing many unwanted lines and finding the current line's location within them. > OK, I'll bite (NB: using GNU find): I think the POSIX way of getting the atime would be ‘LC_CTIME=C ls -lu’ and then parsing the two possible date formats. So non-POSIX find is simpler. Also, GNU find shows me the sub-second part but ls doesn't. Neither does GNU ‘stat -c '%X %n'’. > find "$directory_tree" -type f -printf "%A+ %p\n" | sort -r | cut -d' ' -f2 | head -5 - I'd switch the atime format to seconds since epoch for easier formatting given it's discarded. - When atimes tie, sort's -r will give file Z before A so I'd add some -k's so A comes first. - I'd move the head to before the cut so cut processes fewer lines... - But on so few lines, I'd just use sed to do both in one. find "$@" -type f -printf '%A@ %p\n' | sort -k1,1nr -k2 | sed 's/^[^ ]* //; 5q' Remaining issues... If tied entries bridge the top-five border then this isn't shown. Is the real requirement to show files with the five most recent distinct atimes? awk '{t += !s[$0]; s[$0] = 1; print} t == 5 {exit}' Though this might give many lines. Instead, an ellipsis could show a tie bridged the cut-off. awk 't {if ($0 == l) print "..."; exit} NR == 5 {l = $0; t = 1} 1' Paths can contain linefeeds and some versions allow handling NULs to be tediously employed. find "$@" -type f -printf '%A@ %p\0' | sort -z -k1,1nr -k2 | sed -z 's/[^ ]* //; 5q' | tr \\0 \\n David Wheeler has a nice article he maintains on unusual characters in filenames: how to cope, and what other systems do, e.g. Plan 9. Fixing Unix/Linux/POSIX filenames: control characters (such as newline), leading dashes, and other problems David A. Wheeler, 2023-08-22 (originally 2009-03-24) https://dwheeler.com/essays/fixing-unix-linux-filenames.html As he writes, Linux already returns EINVAL for some paths on some filesystem types. A mount option which had a syscall return an error on meeting an insensible path would be useful. It avoids any attempt at escapement and its greater risk of implementation errors. I could always re-mount some old volume without the option to list the directory and fix up its entries. The second-best day to plant a tree is today. -- Cheers, Ralph. From g.branden.robinson at gmail.com Tue Jun 11 20:51:20 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 11 Jun 2024 05:51:20 -0500 Subject: [TUHS] Draft: London and Reiser's UNIX/32V paper, reconstructed Message-ID: <20240611105120.k3jpky7fvmuc7wjy@illithid> Hi folks, Reiser and London's paper documenting their preparation of UNIX/32V, a port of Seventh Edition Unix to the VAX-11/780, is an important milestone in Unix development--as much I think for its frank critique of C as "portable assembly" as for the status of the system documented: the last common ancestor of the BSD and System V branches of development. Because the only version I've ever seen of this paper is a scan of, possibly, a photocopy several generations removed from the original, I thought I'd throw an OCR tool at it and see about reconstructing it, not just for posterity but to put the groff implementation of mm to the test. So even if someone has a beautiful scan of this document elsewhere, this exercise remains worthwhile to me for what it has shown me about Documenter's Workbench mm and groff's mostly compatible reimplementation thereof. Please find attached my first draft of the reconstruction as an mm document as well as a PDF rendered by bleeding edge groff. I did not attempt to fix _any_ typos, solecisms, or non-idiomatic *roff usage (like the employment of hyphens as arithmetic signs or operators) in this document. I may have introduced errors, however, due to human fallibility or incorrect inferences about what lay beneath scanning artifacts. Hence its draft status. I welcome review. Assuming this reconstruction survives peer scrutiny, I aim to put it up on GitHub as I did Kernighan & Cherry's "Typesetting Mathematics" paper.[1] For the casual reader, I extract my documentary annotations below. For groff list subscribers, I will add, because people are accustomed to me venturing radical suggestions for reforms of macro packages, I suggest that we can get rid of groff mm's "MOVE" and "PGFORM" extensions. They're buggy (as the man page has long conceded), and I don't think anyone ever mastered them, not even their author. I rewrote "0.MT", essential to rendering of this document, without requiring them at all. I _tried_ to use them, but "MOVE" in particular introduced baffling errors in vertical spacing. When I threw it aside to attack head-on the layout problems facing me, things got easier. Further, simple caching and restoration of `.i` and `.l` register values (when multiple changes were being made to them within a macro) obviated `PGFORM`. I'm not sure that it is tractable to idiot-proof manipulations of basic layout parameters like these, as these macros seem to have tried to do. If a document author wants to seize control of page layout from a full-service macro package and reach deep into the guts of the formatter, they should glove up and put things back where they found them. My opinion. .\" London & Reiser's UNIX/32V porting paper .\" .\" Reconstruction in groff mm (but DWB 3.3 mm compatible) .\" from scanned/OCRed text by G. Branden Robinson, June 2024 .\" .\" The original scan shows no evidence of superscript usage, except on .\" the cover sheet where "TM" superscripts "UNIX". .\" .\" Some differences may arise due to changes in the mm macro package .\" itself from its PWB incarnation (ca. 1978) and DWB 3.3 (July 1992). .\" Thanks to Dan Plassche for the history. .\" https://www.tuhs.org/pipermail/tuhs/2022-March/025545.html .\" .\" The groff reimplementation of mm was undertaken mostly from .\" 1991-1999 (by Juergen Haegg), based on the DWB documentation. It .\" added features but also parameterized many aspects of package .\" behavior, for example to facilitate easy localization. Later, .\" Werner Lemberg and G. Branden Robinson contributed enhancements, bug .\" fixes, and improvements to the groff_mm(7) man page. .\" .\" I anticipate adding further parameters to groff mm to better .\" emulate the old version of mm used by this paper. (For example, the .\" format of the caption applied to the reference page differs between .\" PWB mm and DWB 3.3.) Where this document exercises such extensions, .\" they should be prefixed with a `do` request so that AT&T troff will .\" ignore them. .\" Override: "By default, ... bold stand-alone headings are printed .\" in a size one point smaller than the body." .\" XXX: The cover "page" (more like a header block) is a mess when .\" typeset with groff mm, and outright horrific in nroff mode. GBR has .\" fixes for these pending for push to GNU Savannah's Git repository. .\" .\" XXX: Original scan capitalizes "Subject:"; DWB 3.3 renders it in .\" full lowercase. .\" .\" XXX: Original scan bears a "TM:" heading for the technical .\" memorandum number(s). DWB 3.3 lacks this. .\" .\" Memorandum captions may have changed from PWB to DWB 3.3 mm. groff .\" mm has changed in Git (June 2024) to use the captions documented in .\" the DWB 3.3 manual. We override the default for authenticity. .\" XXX: Original scan sets reference marks as a typewriter might, at .\" normal size on the baseline between square brackets. DWB 3.3 .\" converts them to superscripts but keeps the brackets(!). groff mm .\" should add a "Rfstyle" register to control this. .\" 0 = auto (nroff/troff); 1 = bracket; 2 = superscript; 3 = both. (?) \" straight quotes in original .ns \" XXX: Hack to keep `VL` from adding pre-list vertical space. \" recte: *(\-\-p+i) \" bad ellipsis spacing in original \" - missing; error in text or scanner fubar? \" recte: \-1 \" sic .\" Either `AL` worked differently in 1978 mm, or didn't exist, or .\" somebody wanted this list _just so_. .\"AL "" 5 .\" XXX: Scan has signatures set farther to the right, not centered as .\" DWB 3.3 mm sets them. groff mm follows DWB here. .\" .\" XXX: PWB and DWB 3.3 put the signature names in bold; groff mm sets .\" them at normal weight. Bug. .\" .\" XXX: Scan has a couple of vees between the signature line and the .\" flush left secretarial annotation. groff mm sets the annotation on .\" the same line as the last author but also puts its information in .\" the cover page header as DWB 3.3 does, described next. DWB 3.3: (1) .\" omits the secretarial annotation altogether, putting it up in the .\" cover page header under the authors' names; (2) does not use author .\" initials (in the cover header) for this memorandum type; (3) puts .\" the department number after "Org." on the line under the author .\" name; (4) puts the abbreviated AT&T site name below that. Should we .\" consider a `Sgstyle` register for groff mm? .\" .\" XXX: groff mm organizes the department and site name differently .\" from DWB 3.3 in the cover head, and I don't see any reason for it .\" to. Fix this. .\" XXX: Scan only breaks between notations; DWB 3.3 and groff put 1v .\" between them. Should we consider an `Nss` register for groff mm? .\" XXX: Scan has references caption set flush left, in mixed case and .\" bold (just like `HU`). DWB 3.3 and groff center it and set it in .\" full caps in italics (at normal weight). If there were a way to .\" dump the accumulated reference list independently of rendering the .\" caption, that would give the author much more flexibility. .\" .\" XXX: The numbered reference list does not look like one produced .\" with `RL` nor with `AL`. The numeric tag is left-aligned within the .\" paragraph indentation. groff mm aligns it to the right. .\" .\" DWB 3.3 and Heirloom mm don't seem to honor `.RP 2` as the DWB .\" manual documents. They start the table immediately after the .\" reference list and go haywire boxing the table. Bug. Regards, Branden [1] https://github.com/g-branden-robinson/retypesetting-mathematics -------------- next part -------------- A non-text attachment was scrubbed... Name: unix-32v-reconstructed.mm Type: text/troff Size: 54267 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unix-32v-reconstructed.pdf Type: application/pdf Size: 103558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ralph at inputplus.co.uk Wed Jun 12 00:05:38 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 11 Jun 2024 15:05:38 +0100 Subject: [TUHS] Draft: London and Reiser's UNIX/32V paper, reconstructed In-Reply-To: <20240611105120.k3jpky7fvmuc7wjy@illithid> References: <20240611105120.k3jpky7fvmuc7wjy@illithid> Message-ID: <20240611140538.6F6D8220BB@orac.inputplus.co.uk> G. Branden Robinson wrote: > For groff list subscribers, I will add, because people are accustomed > to me venturing radical suggestions for reforms of macro packages, > I suggest that we can get rid of groff mm's "MOVE" and "PGFORM" > extensions. They're buggy (as the man page has long conceded), and > I don't think anyone ever mastered them, not even their author. I have quite a lot of old troff -mm source containing lines like .PGFORM 21c-2i 29.7c-1.5i 1i 1 and they worked fine for me. Part of troff's attraction is it has reached an age where it doesn't have breaking changes. Perhaps they should be in a fork of groff. gbroff? Though I'd have though an entirely new formatter would give much more freedom for experimentation given modern input and output formats and greater processing power. Meanwhile, Werner's earlier groff is still available and other troffs exist. -- Cheers, Ralph. From beebe at math.utah.edu Wed Jun 12 03:42:54 2024 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 11 Jun 2024 11:42:54 -0600 Subject: [TUHS] [tuhs] Early statistical software in Unix Message-ID: Doug McIlroy kindly sent me contact information for John Chambers, co-author of the cited book about the S system. I have just heard back from John, who offered a link to his summary paper from the 2020 HOPL conference proceedings S, R, and data science https://doi.org/10.1145/3386334 and reported that S was licensed to AT&T Unix customers only in binary form, and that the original source code may no longer exist. That is a definitive answer, even if not the one that I was hoping to find. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From steffen at sdaoden.eu Wed Jun 12 07:01:02 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 11 Jun 2024 23:01:02 +0200 Subject: [TUHS] Likely a one-liner in Unix In-Reply-To: <20240611080506.73D7B21309@orac.inputplus.co.uk> References: <20240611080506.73D7B21309@orac.inputplus.co.uk> Message-ID: <20240611210102.P8tiuiAL@steffen%sdaoden.eu> Ralph Corderoy wrote in <20240611080506.73D7B21309 at orac.inputplus.co.uk>: .. |>>>   "Show me the last 5 files read in a directory tree" ... |Neither does GNU ‘stat -c '%X %n'’. Unfortunately "stat" is not portable. ... |David Wheeler has a nice article he maintains on unusual characters in |filenames: how to cope, and what other systems do, e.g. Plan 9. | | Fixing Unix/Linux/POSIX filenames: control characters (such as | newline), leading dashes, and other problems | David A. Wheeler, 2023-08-22 (originally 2009-03-24) | https://dwheeler.com/essays/fixing-unix-linux-filenames.html | |As he writes, Linux already returns EINVAL for some paths on some |filesystem types. A mount option which had a syscall return an error on |meeting an insensible path would be useful. It avoids any attempt at |escapement and its greater risk of implementation errors. I could |always re-mount some old volume without the option to list the directory |and fix up its entries. The second-best day to plant a tree is today. dash is currently implementing $'' quotes (that will be part of the next POSIX i think). I want to mention again, eh, please let me just paste something of mine from ossec from may, as i really think in $'' could lie sanity also for such things: While here please let me back the not yet gracefully supported shell escape mechanism $''. The current approach seems to be to be as atomic as possible: # touch $(printf 'a\rb\tc\a') # ll -> -rw-r----- 1 steffen steffen 0 May 3 00:46 'c'$'\a' -rw-r----- 1 steffen steffen 0 May 3 00:46 'a'$'\r''b' (GNU coreutils). Isn't that just terrible? In (the development version of) my mailer tab-completion leads to #..mbox? /tmp/ $'a\rb' $'c\a' which i find at least a little bit better. (Do not even think about looking in its implementation though, look ICU or what.) And even though currently unsupported, it should be said that with "grapheme clusters" and in general things like ligatures and other such language-specific constructs which need to look at surroundings -- in general interfaces like towupper() etc are not useful in global context, entire sentences have to be looked at as a whole due to this! --, shell quotes should be extended to the largest possible range possible. Ie, all the iconv(3)s that are currently used because of a lack of other interfaces should be enabled to see the longest possible (sub)string, not the most atomar, as seen above. Anyhow, with proper $'' quoting that also offers \$VAR/\${VAR} for example (which acts like "$VAR" in double quotes; and \c@==NUL, xx) there would be a way to a have a holistic quoting mechanism. Some more complaining of an idiot who does not understand why ISO C and more standardized holes in the \U and \u (Unicode code point, hexadecimal) ranges. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From frew at ucsb.edu Wed Jun 12 10:26:22 2024 From: frew at ucsb.edu (James Frew) Date: Tue, 11 Jun 2024 17:26:22 -0700 Subject: [TUHS] [tuhs] Early statistical software in Unix In-Reply-To: References: Message-ID: <8b0285c2-ce2d-4f92-ac74-5dc62f16a6fa@ucsb.edu> Well, at least one copy of the source code escaped: I compiled and ran it on a Sun-3 server at UCSB ca. 1980. As I recall it was a formidable wad of Fortran. Alas, it's long gone: any backups extant would be on media likely too deteriorated to read, even if we had the hardware to read it. Cheers, /Frew On 2024-06-11 10:42, Nelson H. F. Beebe wrote: > Doug McIlroy kindly sent me contact information for John Chambers, > co-author of the cited book about the S system. I have just heard > back from John, who offered a link to his summary paper from the > 2020 HOPL conference proceedings > > S, R, and data science > https://doi.org/10.1145/3386334 > > and reported that S was licensed to AT&T Unix customers only in binary > form, and that the original source code may no longer exist. > > That is a definitive answer, even if not the one that I was hoping to > find. From jim at deitygraveyard.com Wed Jun 12 11:37:42 2024 From: jim at deitygraveyard.com (Jim Carpenter) Date: Tue, 11 Jun 2024 21:37:42 -0400 Subject: [TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001) In-Reply-To: References: Message-ID: On Tue, Jun 11, 2024 at 2:06 AM segaloco via TUHS wrote: > In any case, I intend to upload bin/cue images of all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the administrative and maintenance points of view. Once I get archive.org to choke these files down I also intend to go back around to the discs I've already archived and reupload them as proper bin/cue rips. I was in a hurry the last time around and simply zipped the contents from the discs, but aside from just being good archive practice, I think bin/cue is necessary for the other discs as they seem to have control information in the disc header that is required by the interactive documentation viewers therein. Bin/cue is a PITA. You've checked that a simple raw image isn't adequate? Perhaps the viewer was just checking the volume label? Jim From tuhs at tuhs.org Wed Jun 12 13:34:22 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 12 Jun 2024 03:34:22 +0000 Subject: [TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001) In-Reply-To: References: Message-ID: On Tuesday, June 11th, 2024 at 6:37 PM, Jim Carpenter wrote: > On Tue, Jun 11, 2024 at 2:06 AM segaloco via TUHS tuhs at tuhs.org wrote: > > > In any case, I intend to upload bin/cue images of all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the administrative and maintenance points of view. Once I get archive.org to choke these files down I also intend to go back around to the discs I've already archived and reupload them as proper bin/cue rips. I was in a hurry the last time around and simply zipped the contents from the discs, but aside from just being good archive practice, I think bin/cue is necessary for the other discs as they seem to have control information in the disc header that is required by the interactive documentation viewers therein. > > > Bin/cue is a PITA. You've checked that a simple raw image isn't > adequate? Perhaps the viewer was just checking the volume label? > > > Jim What would you suggest? My main point of reference is years and years of being in the console video game scene, bin/cue is the most accessible of the high fidelity formats I've seen for things, compared with say cdi and mdf/mds. Does a plain old iso suffice for all relevant data from the media? Frankly I've never done dumps on a UNIXy computer with an optical drive, only Windows boxen, so can't say I'm hip to the sort of disc image you get doing a dd from an optical /dev entry, maybe I just need to get a UNIX of some kind on my old beater game machine with an optical drive to do these dumps going forward. Either way, open to suggestions on what format is the ideal combination of capturing everything that matters from optical media while not using too onerous or closed up of an image format. This is not an area I'm "with the times on", I just went straight to what was customary for myself over a decade ago when I was last diligently interacting with optical media preservation. - Matt G. From andreww591 at gmail.com Wed Jun 12 15:43:13 2024 From: andreww591 at gmail.com (Andrew Warkentin) Date: Tue, 11 Jun 2024 23:43:13 -0600 Subject: [TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001) In-Reply-To: References: Message-ID: On Tue, Jun 11, 2024 at 9:41 PM segaloco via TUHS wrote: > > What would you suggest? My main point of reference is years and years of being in the console video game scene, bin/cue is the most accessible of the high fidelity formats I've seen for things, compared with say cdi and mdf/mds. Does a plain old iso suffice for all relevant data from the media? Frankly I've never done dumps on a UNIXy computer with an optical drive, only Windows boxen, so can't say I'm hip to the sort of disc image you get doing a dd from an optical /dev entry, maybe I just need to get a UNIX of some kind on my old beater game machine with an optical drive to do these dumps going forward. > The vast majority of non-game software was distributed on discs that were formatted with a single data track and no special formatting. These can be safely imaged in flat (ISO) format. The main reason to use the lower-level formats is for discs with disc-based copy protection or multiple tracks (usually one data track and multiple audio tracks), both of which are very uncommon for non-game software. BeOS install CDs are the one exception I can think of; these have an ISO-format boot track followed by one or two BFS-format system tracks (separate system tracks are used for x86 and PPC), although even these aren't actually dependent on multiple tracks and can be run from a CD with just the system track if a boot floppy is used. Most dumping programs should be able to show you how the discs are formatted; if they only have a single track each, ISO format should be sufficient. From wobblygong at gmail.com Wed Jun 12 17:01:44 2024 From: wobblygong at gmail.com (Wesley Parish) Date: Wed, 12 Jun 2024 19:01:44 +1200 Subject: [TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001) In-Reply-To: References: Message-ID: On 12/06/24 17:43, Andrew Warkentin wrote: > On Tue, Jun 11, 2024 at 9:41 PM segaloco via TUHS wrote: >> What would you suggest? My main point of reference is years and years of being in the console video game scene, bin/cue is the most accessible of the high fidelity formats I've seen for things, compared with say cdi and mdf/mds. Does a plain old iso suffice for all relevant data from the media? Frankly I've never done dumps on a UNIXy computer with an optical drive, only Windows boxen, so can't say I'm hip to the sort of disc image you get doing a dd from an optical /dev entry, maybe I just need to get a UNIX of some kind on my old beater game machine with an optical drive to do these dumps going forward. >> > The vast majority of non-game software was distributed on discs that > were formatted with a single data track and no special formatting. > These can be safely imaged in flat (ISO) format. The main reason to > use the lower-level formats is for discs with disc-based copy > protection or multiple tracks (usually one data track and multiple > audio tracks), both of which are very uncommon for non-game software. > BeOS install CDs are the one exception I can think of; these have an > ISO-format boot track followed by one or two BFS-format system tracks > (separate system tracks are used for x86 and PPC), although even these > aren't actually dependent on multiple tracks and can be run from a CD > with just the system track if a boot floppy is used. > > Most dumping programs should be able to show you how the discs are > formatted; if they only have a single track each, ISO format should be > sufficient. FWIW, I've successfully dd'ed cds and cd-roms into iso files and burnt copies. I've never made use of the bin/cue setup, and wouldn't know how to work it. Wesley Parish From ralph at inputplus.co.uk Wed Jun 12 18:12:04 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 12 Jun 2024 09:12:04 +0100 Subject: [TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001) In-Reply-To: References: Message-ID: <20240612081204.670F21FBE4@orac.inputplus.co.uk> Hi Andrew, > Most dumping programs should be able to show you how the discs are > formatted; if they only have a single track each, ISO format should be > sufficient. Presumably, it's fairly simple to look at the text-file cue-sheet, if bin/cue had been used, to see an ISO would have been good enough? https://en.wikipedia.org/wiki/Cue_sheet_(computing)#Cue_sheet_syntax And then perhaps there's a command to extract the ISO from the bin/cue files. -- Cheers, Ralph. From tuhs at tuhs.org Wed Jun 12 18:41:45 2024 From: tuhs at tuhs.org (Arno Griffioen via TUHS) Date: Wed, 12 Jun 2024 10:41:45 +0200 Subject: [TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001) In-Reply-To: <20240612081204.670F21FBE4@orac.inputplus.co.uk> References: <20240612081204.670F21FBE4@orac.inputplus.co.uk> Message-ID: On Wed, Jun 12, 2024 at 09:12:04AM +0100, Ralph Corderoy wrote: > And then perhaps there's a command to extract the ISO from the bin/cue > files. 'bchunk' is one that does exactly that. Also 'fuseiso' allows mouting a BIN/CUE file/image as a regular filesystem to read the files if you just want to use them as-is. Bye, Arno. From ralph at inputplus.co.uk Wed Jun 12 19:01:01 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 12 Jun 2024 10:01:01 +0100 Subject: [TUHS] [tuhs] Early statistical software in Unix In-Reply-To: References: Message-ID: <20240612090101.DB4811FBE4@orac.inputplus.co.uk> Hi Nelson, > [John] reported that S was licensed to AT&T Unix customers only in > binary form, and that the original source code may no longer exist. Given your point about ‘S’ being an awkward search term, does John Chambers recall a colloquial longer name, perhaps for when context was needed? Also, any fragments of filenames he can recall, whether source or binary distribution. Given Bell Labs long history of inventions, it presumably had an archive of material and an archivist or librarian back in the '70s. Back then, contemporary data on disc and tape was impractical to archive — too much of it, to expensive to duplicate, and difficult to predict what would be worth keeping — but paper was their trade. An archival print of source to match a licensed release would have been possible. Perhaps even preferred by the lawyers. I'm surprised they weren't considering how to archive ‘today’. -- Cheers, Ralph. From tuhs at tuhs.org Thu Jun 13 02:30:48 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 12 Jun 2024 16:30:48 +0000 Subject: [TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001) In-Reply-To: References: <20240612081204.670F21FBE4@orac.inputplus.co.uk> Message-ID: On Wednesday, June 12th, 2024 at 1:41 AM, Arno Griffioen via TUHS wrote: > On Wed, Jun 12, 2024 at 09:12:04AM +0100, Ralph Corderoy wrote: > > > And then perhaps there's a command to extract the ISO from the bin/cue > > files. > > > 'bchunk' is one that does exactly that. > > Also 'fuseiso' allows mouting a BIN/CUE file/image as a regular filesystem to > read the files if you just want to use them as-is. > > Bye, Arno. bchunk is likewise my tool of choice for that sort of thing. I think what I'll go with is the bin/cue for completeness but also a zip of the contents composited together. Someone who specifically needs the disc image data can probably figure out bchunk and then an archive will be present in a form navigable through archive.org's interface with the composite pieces from each collection (i.e. a merge of the discs for a multi-disc set). That should hopefully satisfy various needs. - Matt G. From sauer at technologists.com Fri Jun 14 00:56:04 2024 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Thu, 13 Jun 2024 09:56:04 -0500 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= Message-ID: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> https://www.theregister.com/2024/06/13/version_256_systemd/ I don't see the boast at https://github.com/systemd/systemd/releases/tag/v256, but ... Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer From crossd at gmail.com Fri Jun 14 01:33:30 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 13 Jun 2024 11:33:30 -0400 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: On Thu, Jun 13, 2024 at 10:56 AM Charles H Sauer (he/him) wrote: > https://www.theregister.com/2024/06/13/version_256_systemd/ > > I don't see the boast at > https://github.com/systemd/systemd/releases/tag/v256, but ... That "boast" seems to come from a random mastodon post? - Dan C. From lm at mcvoy.com Fri Jun 14 01:35:29 2024 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 13 Jun 2024 08:35:29 -0700 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: <20240613153529.GO8271@mcvoy.com> "The new alternative does no such sleight of hand. Instead, it just gets the systemd daemon to run the command for you, using a special form of the existing systemd-run command." Sounds like a new path for exploits. We'll see if Mr Systemd has to eat some crow in the future. Said by a guy who _hates_ systemd. On Thu, Jun 13, 2024 at 09:56:04AM -0500, Charles H Sauer (he/him) wrote: > https://www.theregister.com/2024/06/13/version_256_systemd/ > > I don't see the boast at > https://github.com/systemd/systemd/releases/tag/v256, but ... > > Charlie > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/Twitter: CharlesHSauer -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From clemc at ccc.com Fri Jun 14 01:39:12 2024 From: clemc at ccc.com (Clem Cole) Date: Thu, 13 Jun 2024 11:39:12 -0400 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: Thank Charlie. But I just threw up after I read it. Sadly, UNIX's "prime directive" was to "keep it simple." Or, as someone else describes it, create "small tools that did one job well." On the PDP-11, the lack of address space somewhat enforced this. With the 32-bit vax, we see cat -v and the like. I think "frameworks" are just a modern term for IBM's "access methods" of the 1960s. John Lions observed that the entire documentation set for UNIX V6 could be kept in a 3-ring binder, and, as his book showed, given the size, anyone could understand all of the kernel and the core systems ideas. FWIW, Linux is not the first to fail. Years ago, I pointed out to Dennis that the System V Release 3 bootloader for the 3B was larger than the entire V6 kernel. I have not looked at the size of systemd, but do you want to bet that it fails the same test? But I digress. Someone (Henry Spencer, maybe) once said, "Good Taste is subjective. I have it, and you don't seem to." IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas. Sigh ... Clem ᐧ ᐧ On Thu, Jun 13, 2024 at 10:56 AM Charles H Sauer (he/him) < sauer at technologists.com> wrote: > https://www.theregister.com/2024/06/13/version_256_systemd/ > > I don't see the boast at > https://github.com/systemd/systemd/releases/tag/v256, but ... > > Charlie > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/Twitter > : > CharlesHSauer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ads at salewski.email Fri Jun 14 01:41:48 2024 From: ads at salewski.email (Alan D. Salewski) Date: Thu, 13 Jun 2024 11:41:48 -0400 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <20240613153529.GO8271@mcvoy.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <20240613153529.GO8271@mcvoy.com> Message-ID: On Thu, Jun 13, 2024, at 11:35, Larry McVoy wrote: > "The new alternative does no such sleight of hand. Instead, it just gets the > systemd daemon to run the command for you, using a special form of the existing > systemd-run command." > > Sounds like a new path for exploits. We'll see if Mr Systemd has to eat > some crow in the future. Said by a guy who _hates_ systemd. Eating sudo, eating crow...I guess systemd is /still/ hungry: https://i.kym-cdn.com/photos/images/original/000/925/966/8d2.gif -Al From usotsuki at buric.co Fri Jun 14 01:55:40 2024 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 13 Jun 2024 11:55:40 -0400 (EDT) Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <20240613153529.GO8271@mcvoy.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <20240613153529.GO8271@mcvoy.com> Message-ID: On Thu, 13 Jun 2024, Larry McVoy wrote: > "The new alternative does no such sleight of hand. Instead, it just gets the > systemd daemon to run the command for you, using a special form of the existing > systemd-run command." > > Sounds like a new path for exploits. We'll see if Mr Systemd has to eat > some crow in the future. Said by a guy who _hates_ systemd. systemd is the thing that should not be. If I had successfully gotten my project up (trying to get a standalone kernel/libc/clang build environment up and running - either Linux/musl or NetBSD) it would run a rewrite of the SysV init system (not "sysvinit", that's GPL). -uso. From tuhs at tuhs.org Fri Jun 14 02:47:02 2024 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Thu, 13 Jun 2024 18:47:02 +0200 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: On 13 Jun 2024, at 17:39, Clem Cole wrote: > IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas. Binary logs, ’nuff said. Good sysadmins live & die by grep and being able to visually detect departures from the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal window now. Yours disgusted since v1 of that abomination. Arrigo From tuhs at tuhs.org Fri Jun 14 04:39:13 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 13 Jun 2024 18:39:13 +0000 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: On Thursday, June 13th, 2024 at 9:47 AM, Arrigo Triulzi via TUHS wrote: > On 13 Jun 2024, at 17:39, Clem Cole clemc at ccc.com wrote: > > > IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas. > > > Binary logs, ’nuff said. > > Good sysadmins live & die by grep and being able to visually detect departures from the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal window now. > > Yours disgusted since v1 of that abomination. > > Arrigo Part of what irks me is the lack of choice. Just like many outlets will use GNU extensions to otherwise POSIX components, leaving the rest of the world out in the rain, several bits of the Linux ecosystem have backed systemd as the one true way and are hobbled if even usable at all with other init systems out there. User software shouldn't have any attachment to a particular init system, it isn't meant to provide "services" beyond run this script at this time based on the conditions of boot, manage terminal lines, and maybe offer some runlevels to compartmentalize operating environments. I've seen it said elsewhere that the amount of surface area being shoved into PID 1 can only lead to disaster. Are there any known attempts in the modern age to roll Linux with something resembling research/BSD init? That would be a nice counter to the proliferation of systemd. Even if it doesn't make a dent in the actual uptake, at least it'd feel cathartic to have an alternative in the opposite direction. - Matt G. From falcon at freecalypso.org Fri Jun 14 04:45:09 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Thu, 13 Jun 2024 10:45:09 -0800 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: <20240613184520.3ED803740153@freecalypso.org> Matt G. wrote: > Are there any known attempts in the modern age to roll Linux with something > resembling research/BSD init? That would be a nice counter to the > proliferation of systemd. I use Slackware and will never give it up. It uses sysvinit, which isn't as good as research/BSD init, but a helluvalot better than systemd! There is also Devuan, a sans-systemd fork of Debian, for those who aren't hard-core enough to go full Slackware. M~ From crossd at gmail.com Fri Jun 14 04:54:51 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 13 Jun 2024 14:54:51 -0400 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: On Thu, Jun 13, 2024 at 2:39 PM segaloco via TUHS wrote: > On Thursday, June 13th, 2024 at 9:47 AM, Arrigo Triulzi via TUHS wrote: > > On 13 Jun 2024, at 17:39, Clem Cole clemc at ccc.com wrote: > > > IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas. > > > > Binary logs, ’nuff said. > > > > Good sysadmins live & die by grep and being able to visually detect departures from the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal window now. > > > > Yours disgusted since v1 of that abomination. > > Part of what irks me is the lack of choice. Just like many outlets will use GNU extensions to otherwise POSIX components, leaving the rest of the world out in the rain, several bits of the Linux ecosystem have backed systemd as the one true way and are hobbled if even usable at all with other init systems out there. User software shouldn't have any attachment to a particular init system, it isn't meant to provide "services" beyond run this script at this time based on the conditions of boot, manage terminal lines, and maybe offer some runlevels to compartmentalize operating environments. I've seen it said elsewhere that the amount of surface area being shoved into PID 1 can only lead to disaster. I agree about the lack of choice, but I think the reasoning here shows a bit of an impedance mismatch between what systemd is, and what people think that it should be. In particular, it left merely being an "init system" behind a long time ago, and is now the all-singing, all-dancing service and resource management platform for the system. That's not a terrible thing to have, if the goal of your system is to be able to, well, run services and manage resources. But is systemd, as an expression of that idea, a good thing? I don't really think so. My arguments here tend to be somewhat vague, but I do believe that there is valid criticism beyond just, "It's new! It's different! I hate it!!" Portability is a good argument. Where I think many of the arguments against systemd break down is by dismissing the real problems that it solves; off the top of my head, this may include automatically restarting dependent services when a daemon crashes and is restarted. But again, just because a tool solves a real problem doesn't mean that it's a good tool, or even a good tool for solving that problem. I suspect much of the rush to systemd is driven less by enthusiasm for how it does things, and more for it being the only thing out there that solves some problem that the distro maintainers consider important (ie, that they get asked about frequently). > Are there any known attempts in the modern age to roll Linux with something resembling research/BSD init? Alpine Linux may come closest? And of course the BSDs still exist. > That would be a nice counter to the proliferation of systemd. Even if it doesn't make a dent in the actual uptake, at least it'd feel cathartic to have an alternative in the opposite direction. There are still some Linux distributions that don't ship with systemd, but I think they're just delaying the inevitable. On a more meta point, there are big differences between production server systems, user-oriented systems, and research systems. Systemd feels very much like it comes from the first of those, to me; very mainframe-y. - Dan C. From woods at robohack.ca Thu Jun 13 05:29:28 2024 From: woods at robohack.ca (Greg A. Woods) Date: Wed, 12 Jun 2024 12:29:28 -0700 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' The Register In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: At Thu, 13 Jun 2024 14:54:51 -0400, Dan Cross wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > I agree about the lack of choice, Personally I don't see any lack of choice. There are more than three good BSD derived systems that together cover almost any imaginable set of requirements. The sheep will follow the herd though..... > this may include automatically restarting dependent services when a > daemon crashes and is restarted. If your daemon's are crashing and in need of restarting so often that a tool is needed to restart them then you have a myriad of other far more pressing problems you should be dealing with first! > being the only thing out there that solves some problem that the > distro maintainers consider important (ie, that they get asked about > frequently). If it were so simple I would expect that claim to be more widely advertised, yet we fall back on "it restarts daemons that crash". Personally I think systemd trying to solve the rather high demands and diverse requirements of mobile laptop systems and is trying to meet or match MS Windows in this regard. (personally I think macos has them both beat by a country mile!) It sure as heck isn't of any use in production server environments! If it were more about servers then it would look more like SMF, or maybe launchd, and it's code wouldn't look like it was written by a grade school student. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From ads at salewski.email Fri Jun 14 05:37:57 2024 From: ads at salewski.email (Alan D. Salewski) Date: Thu, 13 Jun 2024 15:37:57 -0400 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote: [...] > Are there any known attempts in the modern age to roll Linux with > something resembling research/BSD init? That would be a nice counter > to the proliferation of systemd. Even if it doesn't make a dent in the > actual uptake, at least it'd feel cathartic to have an alternative in > the opposite direction. > > - Matt G. I'm interested in hearing about other options in this space, too. The ones that I'm aware of include: 1. Slackware http://www.slackware.com/ 2. Debian, with sysvinit-core or some other init https://www.debian.org/doc/manuals/debian-faq/customizing.en.html#sysvinit https://wiki.debian.org/Init 3. Devuan (for a Debian derived system w/o systemd) https://www.devuan.org/ The most no-fuss, just-works-out-of-the-box-without-systemd approach would probably be to use Slackware. Debian can be easily customized to run without systemd, once you know the formulas[0]. I did not include Alpine Linux[1] in the above list because it includes lots of tools in a single executable (possibly "init").[2] It does not use systemd by default, though. I mention Devuan only because I'm aware of it -- I've never used it in anger. -Al [0] Even on a systemd-infected host, it isn't much more complicated than: * install the 'sysvinit-core' package (and friends) * pin the 'systemd-sysv' package to '-1' (never install) * reboot * purge most (or all) packages with 'systemd' in their name [1] https://www.alpinelinux.org/about/ [2] It's great in certain circumstances, though -- it's my go-to distro base for most of my small-footprint-scenarios work with Linux containers. From crossd at gmail.com Fri Jun 14 06:03:30 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 13 Jun 2024 16:03:30 -0400 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' The Register In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: On Thu, Jun 13, 2024 at 3:18 PM Greg A. Woods wrote: > [snip] > > this may include automatically restarting dependent services when a > > daemon crashes and is restarted. > > If your daemon's are crashing and in need of restarting so often that a > tool is needed to restart them then you have a myriad of other far more > pressing problems you should be dealing with first! I may be in a bit of a grumpy mood, so forgive me if this is snarkier than I intend, but statements like this bother me. First, there are a number of reasons that programs crash in the real world, in production environments. Often, the people in charge of keeping them running are not the people who wrote the software; nevermind that sometimes the reason for a crash has nothing to do with the software itself; hardware soft-failures, for instance (that is, where a momentary hardware blip kills a process on some machine but isn't serious enough to drain the computer and reschedule the work elsewhere; particularly where the OS can partition off a bad component, such as a disk or a chunk of RAM or a CPU). When you actually run systems at scale, you engineer them under an expectation of failure and to be resilient. That means automatically restarting services when they crash, among many other things. Second, there are many reasons beyond just "lol it crashed" that you may want to restart dependent services; for example, perhaps you are upgrading a system and part of the upgrade process is restarting your dependents. Having a system that does things like that for you is useful. > > being the only thing out there that solves some problem that the > > distro maintainers consider important (ie, that they get asked about > > frequently). > > If it were so simple I would expect that claim to be more widely > advertised, yet we fall back on "it restarts daemons that crash". See above. > Personally I think systemd trying to solve the rather high demands and > diverse requirements of mobile laptop systems and is trying to meet or > match MS Windows in this regard. (personally I think macos has them > both beat by a country mile!) > > It sure as heck isn't of any use in production server environments! That's not an argument, it's an assertion, and one that isn't well supported. > If it were more about servers then it would look more like SMF, or maybe > launchd, and it's code wouldn't look like it was written by a grade > school student. Sorry, but this is exactly the sort of overly dismissive attitude that I was referring to earlier. You undermine your own argument by mentioning SMF (which can automatically restart services when the crash), for example. - Dan C. From clemc at ccc.com Fri Jun 14 06:05:28 2024 From: clemc at ccc.com (Clem Cole) Date: Thu, 13 Jun 2024 16:05:28 -0400 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> Message-ID: Except ... My primary Linux instances are on my growing family of Raspberry PIs or equiv (I have a couple of BananaPIs and Libre boards). It's based enough on Raspian which like Henry's line WRT 4.2, is just like Debian only different. Frankly, dealing with those issues when you leave the fold is a huge PITA. The problem for me, I really don't have a choice as I can not run a *BSD on them easily to do what I want to do - which is typically to control HW (like my PiDP's or a some "homecontrol" stuff I have). As I have said, it all about economics (well and ego in this case). You have to make something better to make it valuable. Replacing how the system init worked always struck me as throwing out the baby with the bathwater. SysV init was not at all bad, moving from Research/BSD init to it was not a huge life. That said, I agree with Dan, adding a resource system is a good idea and probably was a "hole." Years ago, the CMU Mach team created their nanny system, but it ran in cooperation with init - it did not try to replace init (remember Mach was trying to be a superset of BSD -- they had learned the lessons with Accent of being completely different). When Apple picked up Mach, their engineers eventually combined them to create launchd - which is what I think opened up the world to "getting rid of init" and thus systemd being considered possible by some Linux folks. Of course, the Linux developers could not settle for using launched (NIH) .... so, sadly, https://xkcd.com/927/ applies here - that's the ego part. ᐧ ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.phillip.garcia at gmail.com Fri Jun 14 06:06:39 2024 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Thu, 13 Jun 2024 16:06:39 -0400 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> Message-ID: On Thu, Jun 13, 2024, 3:38 PM Alan D. Salewski wrote: > On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote: > [...] > > Are there any known attempts in the modern age to roll Linux with > > something resembling research/BSD init? > > I'm interested in hearing about other options in this space, > too. > https://nosysyemd.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Jun 14 06:26:00 2024 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 14 Jun 2024 06:26:00 +1000 (EST) Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: On Thu, 13 Jun 2024, Arrigo Triulzi via TUHS wrote: > Binary logs, ’nuff said. Ugh... > Good sysadmins live & die by grep and being able to visually detect > departures from the norm by just looking at the “shape” of logs > scrolling down a screen (before), terminal window now. Which is exactly what I do: one window with "tail -F /var/log/maillog" and another with "tail -F /var/log/httpd-access.log"; I've spotted lots of attacks that way (followed by a quick update to my firewall). -- Dave From jcapp at anteil.com Fri Jun 14 06:26:55 2024 From: jcapp at anteil.com (Jim Capp) Date: Thu, 13 Jun 2024 16:26:55 -0400 (EDT) Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: Message-ID: <1403506.1536.1718310415450.JavaMail.root@zimbraanteil> https://nosystemd.org/ From: "A. P. Garcia" To: "Alan D. Salewski" Cc: "TUHS (The Unix Heritage Society)" Sent: Thursday, June 13, 2024 4:06:39 PM Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register On Thu, Jun 13, 2024, 3:38 PM Alan D. Salewski wrote: On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote: [...] > Are there any known attempts in the modern age to roll Linux with > something resembling research/BSD init? I'm interested in hearing about other options in this space, too. https://nosysyemd.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jun 14 06:31:54 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Thu, 13 Jun 2024 13:31:54 -0700 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> Message-ID: <9B073245-B042-42B0-8C2D-1CE62B05322E@iitbombay.org> On Jun 13, 2024, at 1:05 PM, Clem Cole wrote: > > My primary Linux instances are on my growing family of Raspberry PIs or equiv (I have a couple of BananaPIs and Libre boards). It's based enough on Raspian which like Henry's line WRT 4.2, is just like Debian only different. Frankly, dealing with those issues when you leave the fold is a huge PITA. The problem for me, I really don't have a choice as I can not run a *BSD on them easily to do what I want to do - which is typically to control HW (like my PiDP's or a some "homecontrol" stuff I have). (at least) FreeBSD works on Pis (though support will usually lag or be non-existent for various "HATs"). And plan9 has worked for much longer, not to mention it's more flexible. Both have gpio drivers. Writing drivers for plan9 should be far easier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Jun 14 07:35:44 2024 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 13 Jun 2024 14:35:44 -0700 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> Message-ID: <20240613213544.GB28495@mcvoy.com> On Thu, Jun 13, 2024 at 04:06:39PM -0400, A. P. Garcia wrote: > On Thu, Jun 13, 2024, 3:38???PM Alan D. Salewski wrote: > > > On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote: > > [...] > > > Are there any known attempts in the modern age to roll Linux with > > > something resembling research/BSD init? > > > > > > I'm interested in hearing about other options in this space, > > too. > > > > https://nosysyemd.org Doesn't resolve for me? -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From flexibeast at gmail.com Fri Jun 14 10:27:29 2024 From: flexibeast at gmail.com (Alexis) Date: Fri, 14 Jun 2024 10:27:29 +1000 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> (Alan D. Salewski's message of "Thu, 13 Jun 2024 15:37:57 -0400") References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> Message-ID: <87cyokpdvy.fsf@gmail.com> "Alan D. Salewski" writes: > I'm interested in hearing about other options in this space, > too. i'm currently running Gentoo+OpenRC as my daily driver, with OpenRC an 'official' Gentoo option. https://www.gentoo.org/ Previously i was running Void+s6/66, after having been running Void+runit, with runit being Void's default system (at least at the time). https://voidlinux.org/ Artix is an Arch-based non-systemd distro, with support for OpenRC, runit, s6 and dinit. https://artixlinux.org/ Obarun is an Arch-based distro using 66, which is roughly a 'wrapper' for s6, providing declarative syntax for service definition. https://wiki.obarun.org/ Not a distro, but the s6-overlay project allows using s6 as PID 1 in Docker containers: https://github.com/just-containers/s6-overlay The developer of nosh has a page outlining the know problems with Sys V rc: https://jdebp.uk/FGA/system-5-rc-problems.html The developer of dinit has written a nice comparison of various non-systemd systems providing init / service supervision / service management: https://github.com/davmac314/dinit/blob/master/doc/COMPARISON The developer of s6 has pages: * explaining his perspective on various non-systemd systems: https://skarnet.org/software/s6/why.html * providing a general overview of s6 itself: https://skarnet.org/software/s6/overview.html * discussing s6's approach to 'socket activation', which uses file descriptors: https://skarnet.org/software/s6/socket-activation.html (s6 is the system i'm most familiar with in this space, not least because i'm the porter and maintainer of mdoc(7) versions of the documentation for various parts of the s6/skaware ecosystem.) Alexis. From lm at mcvoy.com Fri Jun 14 10:59:02 2024 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 13 Jun 2024 17:59:02 -0700 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <87cyokpdvy.fsf@gmail.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> <87cyokpdvy.fsf@gmail.com> Message-ID: <20240614005902.GD28495@mcvoy.com> This is all well and good but what I, and I suspect other boomers like me, are looking for, is something like Ubuntu without systemd. I'm a xubuntu guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, everything works there. So is there an "Everything just works" distro without systemd? A guy can hope but I suspect not. I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my effort on fishing on the ocean, I'm not some young guy that wants to put in a ton of hours on my Linux install, I like Linux because it is Unix and it is trivial to install. Windows? Hours and hours of finding drivers after you find some USB network connector that Windows knows? No thanks. *BSD - have you installed one of those? It's a trip back to the 1980s, those installers are fine for BSD developers but just suck compared to Linux. Mainstream Linux just works. On Fri, Jun 14, 2024 at 10:27:29AM +1000, Alexis wrote: > "Alan D. Salewski" writes: > > >I'm interested in hearing about other options in this space, > >too. > > i'm currently running Gentoo+OpenRC as my daily driver, with OpenRC an > 'official' Gentoo option. > > https://www.gentoo.org/ > > Previously i was running Void+s6/66, after having been running Void+runit, > with runit being Void's default system (at least at the time). > > https://voidlinux.org/ > > Artix is an Arch-based non-systemd distro, with support for OpenRC, runit, > s6 and dinit. > > https://artixlinux.org/ > > Obarun is an Arch-based distro using 66, which is roughly a 'wrapper' for > s6, providing declarative syntax for service definition. > > https://wiki.obarun.org/ > > Not a distro, but the s6-overlay project allows using s6 as PID 1 in Docker > containers: > > https://github.com/just-containers/s6-overlay > > The developer of nosh has a page outlining the know problems with Sys V rc: > > https://jdebp.uk/FGA/system-5-rc-problems.html > > The developer of dinit has written a nice comparison of various non-systemd > systems providing init / service supervision / service management: > > https://github.com/davmac314/dinit/blob/master/doc/COMPARISON > > The developer of s6 has pages: > > * explaining his perspective on various non-systemd systems: > > https://skarnet.org/software/s6/why.html > > * providing a general overview of s6 itself: > > https://skarnet.org/software/s6/overview.html > > * discussing s6's approach to 'socket activation', which uses file > descriptors: > > https://skarnet.org/software/s6/socket-activation.html > > (s6 is the system i'm most familiar with in this space, not least because > i'm the porter and maintainer of mdoc(7) versions of the documentation for > various parts of the s6/skaware ecosystem.) > > > Alexis. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From luther.johnson at makerlisp.com Fri Jun 14 11:11:39 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Thu, 13 Jun 2024 18:11:39 -0700 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <20240614005902.GD28495@mcvoy.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> <87cyokpdvy.fsf@gmail.com> <20240614005902.GD28495@mcvoy.com> Message-ID: I believe there is a Debian package you can install after installing Debian that reverts to sysvinit, removes systemd. There is also a configuration that leaves systemd in place but lets you use the sysvinit scripts and forget (well for most people, most uses) that systemd is there. I have the latter style of installation on my server, but I was thinking of going the full no-systemd route sometime. On 06/13/2024 05:59 PM, Larry McVoy wrote: > This is all well and good but what I, and I suspect other boomers like me, > are looking for, is something like Ubuntu without systemd. I'm a xubuntu > guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, > everything works there. > > So is there an "Everything just works" distro without systemd? A guy can > hope but I suspect not. > > I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my > effort on fishing on the ocean, I'm not some young guy that wants to > put in a ton of hours on my Linux install, I like Linux because it is > Unix and it is trivial to install. Windows? Hours and hours of finding > drivers after you find some USB network connector that Windows knows? > No thanks. *BSD - have you installed one of those? It's a trip back > to the 1980s, those installers are fine for BSD developers but just suck > compared to Linux. Mainstream Linux just works. > > On Fri, Jun 14, 2024 at 10:27:29AM +1000, Alexis wrote: >> "Alan D. Salewski" writes: >> >>> I'm interested in hearing about other options in this space, >>> too. >> i'm currently running Gentoo+OpenRC as my daily driver, with OpenRC an >> 'official' Gentoo option. >> >> https://www.gentoo.org/ >> >> Previously i was running Void+s6/66, after having been running Void+runit, >> with runit being Void's default system (at least at the time). >> >> https://voidlinux.org/ >> >> Artix is an Arch-based non-systemd distro, with support for OpenRC, runit, >> s6 and dinit. >> >> https://artixlinux.org/ >> >> Obarun is an Arch-based distro using 66, which is roughly a 'wrapper' for >> s6, providing declarative syntax for service definition. >> >> https://wiki.obarun.org/ >> >> Not a distro, but the s6-overlay project allows using s6 as PID 1 in Docker >> containers: >> >> https://github.com/just-containers/s6-overlay >> >> The developer of nosh has a page outlining the know problems with Sys V rc: >> >> https://jdebp.uk/FGA/system-5-rc-problems.html >> >> The developer of dinit has written a nice comparison of various non-systemd >> systems providing init / service supervision / service management: >> >> https://github.com/davmac314/dinit/blob/master/doc/COMPARISON >> >> The developer of s6 has pages: >> >> * explaining his perspective on various non-systemd systems: >> >> https://skarnet.org/software/s6/why.html >> >> * providing a general overview of s6 itself: >> >> https://skarnet.org/software/s6/overview.html >> >> * discussing s6's approach to 'socket activation', which uses file >> descriptors: >> >> https://skarnet.org/software/s6/socket-activation.html >> >> (s6 is the system i'm most familiar with in this space, not least because >> i'm the porter and maintainer of mdoc(7) versions of the documentation for >> various parts of the s6/skaware ecosystem.) >> >> >> Alexis. From flexibeast at gmail.com Fri Jun 14 11:42:32 2024 From: flexibeast at gmail.com (Alexis) Date: Fri, 14 Jun 2024 11:42:32 +1000 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <20240614005902.GD28495@mcvoy.com> (Larry McVoy's message of "Thu, 13 Jun 2024 17:59:02 -0700") References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> <87cyokpdvy.fsf@gmail.com> <20240614005902.GD28495@mcvoy.com> Message-ID: <878qz8paev.fsf@gmail.com> Larry McVoy writes: > This is all well and good but what I, and I suspect other > boomers like me, > are looking for, is something like Ubuntu without systemd. I'm > a xubuntu > guy (Ubuntu with a lighter weight desktop), but whatever. > Ubuntu is fine, > everything works there. > > So is there an "Everything just works" distro without systemd? > A guy can > hope but I suspect not. Mm, well, i guess that depends on what one's "everything" is. i used Ubuntu years ago - having moved from Mandriva - and was pleased by how everything "just worked". But over time i started experiencing various issues where things _didn't_ just work (i can't remember what now; i think printing might have been one thing), which became increasingly frustrating. So i moved to Debian, and had a much more "just works" experience. But then Debian moved to systemd, and i started getting frustrated again in various ways, and so i moved to Void. Void's a binary distro, and i don't recall having any more issues with it than i ended up having with Ubuntu. And for experienced *n*x users, the installation process is trivial (even if the installer is text-based, rather than involving snazzy graphics). > I'm not trying to be a pain in the ass but I'm 62, I prefer to > spend my > effort on fishing on the ocean, I'm not some young guy that > wants to > put in a ton of hours on my Linux install Fwiw, i'm a 50-year-old woman. :-) My first distro was RedHat 5.2, around the end of '97. To me, this is a "bubbles in wallpaper" thing. i've spent the time setting up Gentoo because i'm now at the point where i'm clear on what i do and don't need/want (in general), and i'm trying to minimise the extent to which i'm beholden to having to deal with breaking changes to subsystems / libraries / software that i don't need/want, or with breakages i don't know how to immediately fix or workaround. Because i have _many_ other life commitments myself, and i've never distro-hopped just for the fun of it; i've always been driven to do so, for various reasons. My distro is merely a means to an end, not the end in itself. (i've taken on s6 documentation stuff because although there's no shortage of people wanting alternatives to systemd, there are far fewer people volunteering to do even small amounts of the work necessary for that.) Alexis. From rminnich at gmail.com Fri Jun 14 14:22:03 2024 From: rminnich at gmail.com (ron minnich) Date: Thu, 13 Jun 2024 21:22:03 -0700 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <878qz8paev.fsf@gmail.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> <87cyokpdvy.fsf@gmail.com> <20240614005902.GD28495@mcvoy.com> <878qz8paev.fsf@gmail.com> Message-ID: well, it depends on what you want, but tinycorelinux has worked well for me, and it fits in about 24M On Thu, Jun 13, 2024 at 6:42 PM Alexis wrote: > Larry McVoy writes: > > > This is all well and good but what I, and I suspect other > > boomers like me, > > are looking for, is something like Ubuntu without systemd. I'm > > a xubuntu > > guy (Ubuntu with a lighter weight desktop), but whatever. > > Ubuntu is fine, > > everything works there. > > > > So is there an "Everything just works" distro without systemd? > > A guy can > > hope but I suspect not. > > Mm, well, i guess that depends on what one's "everything" is. i > used Ubuntu years ago - having moved from Mandriva - and was > pleased by how everything "just worked". But over time i started > experiencing various issues where things _didn't_ just work (i > can't remember what now; i think printing might have been one > thing), which became increasingly frustrating. So i moved to > Debian, and had a much more "just works" experience. But then > Debian moved to systemd, and i started getting frustrated again in > various ways, and so i moved to Void. > > Void's a binary distro, and i don't recall having any more issues > with it than i ended up having with Ubuntu. And for experienced > *n*x users, the installation process is trivial (even if the > installer is text-based, rather than involving snazzy graphics). > > > I'm not trying to be a pain in the ass but I'm 62, I prefer to > > spend my > > effort on fishing on the ocean, I'm not some young guy that > > wants to > > put in a ton of hours on my Linux install > > Fwiw, i'm a 50-year-old woman. :-) My first distro was RedHat 5.2, > around the end of '97. > > To me, this is a "bubbles in wallpaper" thing. i've spent the time > setting up Gentoo because i'm now at the point where i'm clear on > what i do and don't need/want (in general), and i'm trying to > minimise the extent to which i'm beholden to having to deal with > breaking changes to subsystems / libraries / software that i don't > need/want, or with breakages i don't know how to immediately fix > or workaround. Because i have _many_ other life commitments > myself, and i've never distro-hopped just for the fun of it; i've > always been driven to do so, for various reasons. My distro is > merely a means to an end, not the end in itself. > > (i've taken on s6 documentation stuff because although there's no > shortage of people wanting alternatives to systemd, there are far > fewer people volunteering to do even small amounts of the work > necessary for that.) > > > Alexis. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ama at ugr.es Fri Jun 14 16:54:13 2024 From: ama at ugr.es (Angel M Alganza) Date: Fri, 14 Jun 2024 08:54:13 +0200 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <878qz8paev.fsf@gmail.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> <87cyokpdvy.fsf@gmail.com> <20240614005902.GD28495@mcvoy.com> <878qz8paev.fsf@gmail.com> Message-ID: On 2024-06-14 03:42, Alexis wrote: > Mm, well, i guess that depends on what one's "everything" is. i used > Ubuntu years ago - having moved from Mandriva - and was pleased by how > everything "just worked". But over time i started experiencing various > issues where things _didn't_ just work (i can't remember what now; i > think printing might have been one thing), which became increasingly > frustrating. So i moved to Debian, and had a much more "just works" > experience. But then Debian moved to systemd, and i started getting > frustrated again in various ways, and so i moved to Void. I used Debian for 27 years, until ascii (the last release without the nasty systemd), which I upgraded to Devuan ascii. The upgrade process was flawless with everything working without problems for me (I don't use disgusting DEs like Gnome or KDE, of course). In several systems, I've kept upgrading release after release of Devuan, changing every part of the hardware in the way, and it keeps working great. In the BSDs, I much prefer the more classic text installers, where I'm in control, but NomadBSD and GhostBSD have graphical installers which seem to be much simpler and easier to use than the Ubuntu one. Cheers, Ángel From dave at horsfall.org Fri Jun 14 17:04:29 2024 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 14 Jun 2024 17:04:29 +1000 (EST) Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <20240614005902.GD28495@mcvoy.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> <87cyokpdvy.fsf@gmail.com> <20240614005902.GD28495@mcvoy.com> Message-ID: On Thu, 13 Jun 2024, Larry McVoy wrote: > This is all well and good but what I, and I suspect other boomers like > me, are looking for, is something like Ubuntu without systemd. I'm a > xubuntu guy (Ubuntu with a lighter weight desktop), but whatever. > Ubuntu is fine, everything works there. I'm looking for something like Debian for its Amateur radio ("ham") stuff for a laptop, but without the "systemd" monstrosity; I've seen a reference to "Devuan" (?) which might suit me. > So is there an "Everything just works" distro without systemd? A guy > can hope but I suspect not. Hopefully... > I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my > effort on fishing on the ocean, I'm not some young guy that wants to put > in a ton of hours on my Linux install, I like Linux because it is Unix > and it is trivial to install. Windows? Hours and hours of finding > drivers after you find some USB network connector that Windows knows? No > thanks. *BSD - have you installed one of those? It's a trip back to > the 1980s, those installers are fine for BSD developers but just suck > compared to Linux. Mainstream Linux just works. Only 62? I turn 72 in a few months :-) And I *don't* like Linux precisely because it is *not* Unix (too many irritating differences), but I need something for the aforesaid lapdog (with some proprietary hardware, but 3rd-party drivers exist). As for *BSD, yes, many times; I started with SunOS, used OpenBSD/NetBSD/FreeBSD (the latter is my current server), and I really don't see any problem. Heck, even my Mac runs FreeBSD (albeit on steroids)... I have to say though that the SunOS graphical installer was beautiful :-) -- Dave From arnold at skeeve.com Fri Jun 14 17:33:06 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 14 Jun 2024 01:33:06 -0600 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <20240614005902.GD28495@mcvoy.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> <87cyokpdvy.fsf@gmail.com> <20240614005902.GD28495@mcvoy.com> Message-ID: <202406140733.45E7X6vn408140@freefriends.org> I'm with Larry on this one. I'm 64, I been running Ubuntu Mate for ~8 years or so, and even though it's systemd, and yeah, systemd IS an abomination, I don't care enough to go looking for something else. I still have $DAYJOB, kids living at home, Free Software to maintain, books to write, etc., etc., etc. https://wiki.ubuntu.com/SystemdForUpstartUsers#Permanent_switch_back_to_upstart looks like it might do the trick, but it also looks like it's a little old, and I don't want to brick my production systems. I may try to spin up a VM and see if the instructions work before doing it for real. Arnold Larry McVoy wrote: > This is all well and good but what I, and I suspect other boomers like me, > are looking for, is something like Ubuntu without systemd. I'm a xubuntu > guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, > everything works there. > > So is there an "Everything just works" distro without systemd? A guy can > hope but I suspect not. > > I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my > effort on fishing on the ocean, I'm not some young guy that wants to > put in a ton of hours on my Linux install, I like Linux because it is > Unix and it is trivial to install. Windows? Hours and hours of finding > drivers after you find some USB network connector that Windows knows? > No thanks. *BSD - have you installed one of those? It's a trip back > to the 1980s, those installers are fine for BSD developers but just suck > compared to Linux. Mainstream Linux just works. From akosela at andykosela.com Fri Jun 14 17:34:41 2024 From: akosela at andykosela.com (Andy Kosela) Date: Fri, 14 Jun 2024 09:34:41 +0200 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <20240614005902.GD28495@mcvoy.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> <87cyokpdvy.fsf@gmail.com> <20240614005902.GD28495@mcvoy.com> Message-ID: On Friday, June 14, 2024, Larry McVoy wrote: > This is all well and good but what I, and I suspect other boomers like me, > are looking for, is something like Ubuntu without systemd. I'm a xubuntu > guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, > everything works there. > > So is there an "Everything just works" distro without systemd? A guy can > hope but I suspect not. > > I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my > effort on fishing on the ocean, I'm not some young guy that wants to > put in a ton of hours on my Linux install, I like Linux because it is > Unix and it is trivial to install. Windows? Hours and hours of finding > drivers after you find some USB network connector that Windows knows? > No thanks. *BSD - have you installed one of those? It's a trip back > to the 1980s, those installers are fine for BSD developers but just suck > compared to Linux. Mainstream Linux just works. > Larry, in that case I think you will be best with sticking to Xubuntu or Debian. These distros just work. And although I am also from anti-systemd camp after years of using systemd in production environments -- pretty much it has been a standard since rhel 7 -- I conclude that systemd is not the end of the world like some purported back in the days. Mostly it just works too. Switching to some esoteric distro maintained by a couple of university students that will most likely disappear in three years is probably not the best option. Debian is stable and been there from the beginning. All the packages are also there just one simple command away. These days I am also not that interested in kernel development anymore or debugging low level stuff. It was fun when Linux or FreeBSD kernels were much smaller and less complex. I am mostly into retro computing and retro games these days; still playing and enjoying old classics like "The Secret of Monkey Island" from LucasArts on period correct hardware. For daily tasks I am using Macbook which also just works and have a terminal, so I can run my stuff from there. I can control my k8s clusters from the terminal. I am still mostly CLI oriented. Command line will always remain the most elegant and beautiful interface to speak with machines. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Jun 14 17:44:22 2024 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 14 Jun 2024 17:44:22 +1000 (EST) Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> <87cyokpdvy.fsf@gmail.com> <20240614005902.GD28495@mcvoy.com> Message-ID: On Fri, 14 Jun 2024, Andy Kosela wrote: > For daily tasks I am using Macbook which also just works and have a > terminal, so I can run my stuff from there. I can control my k8s > clusters from the terminal. I am still mostly CLI oriented. Command line > will always remain the most elegant and beautiful interface to speak > with machines. What he said... -- Dave From ralph at inputplus.co.uk Fri Jun 14 18:59:39 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 14 Jun 2024 09:59:39 +0100 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <20240613184520.3ED803740153@freecalypso.org> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <20240613184520.3ED803740153@freecalypso.org> Message-ID: <20240614085939.0D1F421A59@orac.inputplus.co.uk> Hi, The Arch Linux wiki if often useful for non-Arch systems. It has details of alternative init systems to systemd, including s6 mentioned elsewhere in the thread: https://wiki.archlinux.org/title/Init -- Cheers, Ralph. From katolaz at freaknet.org Fri Jun 14 21:31:57 2024 From: katolaz at freaknet.org (Vincenzo Nicosia) Date: Fri, 14 Jun 2024 11:31:57 +0000 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register In-Reply-To: <20240614005902.GD28495@mcvoy.com> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <4f7a96cc-2d96-4547-952c-b414a773b62a@app.fastmail.com> <87cyokpdvy.fsf@gmail.com> <20240614005902.GD28495@mcvoy.com> Message-ID: On Thu, Jun 13, 2024 at 05:59:02PM -0700, Larry McVoy wrote: > This is all well and good but what I, and I suspect other boomers like me, > are looking for, is something like Ubuntu without systemd. I'm a xubuntu > guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, > everything works there. > > So is there an "Everything just works" distro without systemd? A guy can > hope but I suspect not. TL;DR: Devuan (https://devuan.org) works more or less fine as a daily drive, both as a desktop and on servers, and it gives choice of sysvinit, runit, openrc, and lately also s6 I believe (but I haven't tried it). If you need something that "kinda works" without systemd, well, Devuan is still "kinda usable", and possibly one of the best options around. Personal rant follows. You are not expected to read this ;P Linux is probably broken beyond repair now, and I am saying that with a heavy heart, having used exlusively Linux and all the other *BSD in the last 26 years, and having advocated its adoption strongly, in different environments. In many ways, Linux is not unix, not any more, to any sensible measure, and since a good while ago. These days Linux can only provide a somehow-lightly-unixy-flavoured system that "kinda works", provided that you do things as the distro decided, and do not look under the hood, ever. I personally believe Linux was at its top around 10-12 years ago, even in terms of how well everything worked in it and how easy it still was to do things your own way, if you wanted to do so. It was still simple enough, yet it provided a full-featured computing experience, from desktops to high-end servers. Nowadays if you decide to use Linux you must accept that far too many things "do happen" to your computer, and neither you nor anybody else knows why they do, or why they shouldn't, or how to alter their behavious or avoid them altogether. There is so much complexity everywhere that there is almost no space left for KISS, anywhere. Linux has eaten itself alive plus a whole bunch of additional bloat, many times, recursively. I have already moved all the servers away of Linux in the last 6-7 years, and I am currently in the last phase of moving my desktops away from it as well. It's a sad farewell, but a necessary one. You can't be totally fed up and keep carrying on for long, can you? :) My2Cents Enzo -- From e5655f30a07f at ewoof.net Fri Jun 14 21:32:27 2024 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Fri, 14 Jun 2024 11:32:27 +0000 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: <22508b22-db5f-491e-bc02-2d4ab4d33cd9@home.arpa> On 14 Jun 2024 06:26 +1000, from dave at horsfall.org (Dave Horsfall): >> Good sysadmins live & die by grep and being able to visually detect >> departures from the norm by just looking at the “shape” of logs >> scrolling down a screen (before), terminal window now. > > Which is exactly what I do: one window with "tail -F /var/log/maillog" and > another with "tail -F /var/log/httpd-access.log"; I've spotted lots of > attacks that way (followed by a quick update to my firewall). journalctl -f -u 'postfix*' or journalctl -f -u 'exim*' or journalctl -f -u 'smtpd' or whatever else might map to the SMTP server software you're running. (Sure, it gets slightly more complicated if you don't know what SMTP server software is in use, but in that case I think a case can be made for why do you even care about its logs?) To filter, one can either add -g 'pcre-expression'; or pipe the output through grep -P for the same effect. Or you can use something like --output=json (or -o json) and pipe the output of that through, say, jq. And I'm pretty sure most web servers still log to text files in typical configurations, so that plain "tail -F" should still work there. Is systemd perfect? Of course not. I have my gripes with it myself, but not enough to actively fight it. And nobody is _forcing_ anyone to use systemd; plenty of examples have already been posted in this thread, from specially-made Linux distribution derivatives to ones that have opted to not include systemd to *BSDs to links to instructions for how to get rid of systemd from more mainstream Linux distributions that have opted to use it as a default. Also, the subjectular headline from The Register seems like something someone has dreamed up; I certainly don't see anything like that in the actual release announcement at . Also using multiple different search engines to try to find it only brought up the _The Register_ article and a handful of places regurgitating that quote as a real representation of a statement from the systemd maintainers. I don't see anything resembling it anywhere on either systemd.io or github.com. Until I see someone posting a link to something like that quote posted by a systemd maintainer in representation of _any_ systemd release, let alone v256, I'm going to treat that one as hearsay at best, and actively malicious at worst. As much as I can appreciate the architectural simplicity of early UNIX, how about not ignoring the fact that today's systems are quite a bit more complex both at the hardware and the software level than they were in the late 1960s, and that to some extent, this complexity _itself_ (unfortunately) drives complexity in other areas. Also that much of that simplicity was also out of necessity. There's a reason why most software these days isn't written directly in assembler or even C. None of which negates the accomplishments of either UNIX or C. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From a.phillip.garcia at gmail.com Fri Jun 14 22:21:17 2024 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Fri, 14 Jun 2024 08:21:17 -0400 Subject: [TUHS] =?utf-8?q?Version_256_of_systemd_boasts_=2742=25_less_Uni?= =?utf-8?q?x_philosophy=27_=E2=80=A2_The_Register?= In-Reply-To: <22508b22-db5f-491e-bc02-2d4ab4d33cd9@home.arpa> References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> <22508b22-db5f-491e-bc02-2d4ab4d33cd9@home.arpa> Message-ID: On Fri, Jun 14, 2024, 7:42 AM Michael Kjörling wrote Also, the subjectular headline from The Register seems like something > someone has dreamed up; I certainly don't see anything like that in > the actual release announcement at > . Also using > multiple different search engines to try to find it only brought up > the _The Register_ article and a handful of places regurgitating that > quote as a real representation of a statement from the systemd > maintainers. I don't see anything resembling it anywhere on either > systemd.io or github.com. Until I see someone posting a link to > something like that quote posted by a systemd maintainer in > representation of _any_ systemd release, let alone v256, I'm going to > treat that one as hearsay at best, and actively malicious at worst. > https://fosstodon.org/@bluca/112600235561688561 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Jun 15 00:17:38 2024 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Fri, 14 Jun 2024 09:17:38 -0500 Subject: [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' The Register In-Reply-To: References: <73819d1a-395a-4b74-a20c-0123fbed56bd@technologists.com> Message-ID: On 6/13/24 15:03, Dan Cross wrote: > I may be in a bit of a grumpy mood, so forgive me if this is snarkier > than I intend, but statements like this bother me. ;-) > Second, there are many reasons beyond just "lol it crashed" that > you may want to restart dependent services; for example, perhaps you > are upgrading a system and part of the upgrade process is restarting > your dependents. Having a system that does things like that for you > is useful. It's my understanding that systemd as a service lifecycle manager is starting to take on some aspects of what cluster service managers used to do. E.g. - Are all the other dependencies this service needs up and running -> is it okay to start this service on this system? - Is the service running and responding like it should be? -> periodically check to make sure the system is returning expected results; is DNS answering queries / can I send a test email - Stop the service when it's operating outside acceptable parameters (read: failing). - Notify other related services that this service has been stopped. I'm anti-systemd *cough*Master Control Program*cough* and it's associated suite of utilities for many reasons. But I've come to accept that systemd is not just an init system. It's role of a service life cycle manager is a superset of what an init system does. It's a relatively new world (at least comparatively). I also have seriouis doubts about systemd's stability as a services life cycle manager. I've seen too many times when systems get into a wedged state that require a power fail / reset (or sys request if enabled) to recover. I've seen too many times when a systemd based system won't shut down because of some circular configuration it's gotten itself into. Without the complication of NFS servers being unreachable after taking down the network. -- Grant. . . . -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4033 bytes Desc: S/MIME Cryptographic Signature URL: