TUHS

tuhs@tuhs.org

47 participants
6502 discussions

[tuhs] fuzz testing of Unix-family utilities

by Nelson H. F. Beebe

I first encountered the fuzz-testing work of Barton Miller (Computer Sciences Department, University of Wisconsin in Madison) and his students and colleagues in their original paper on the subject An empirical study of the reliability of UNIX utilities Comm. ACM 33(12) 32--44 (December 1990) https://doi.org/10.1145/96267.96279 which was followed by Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services University of Wisconsin CS TR 1264 (18 February 1995) ftp://ftp.cs.wisc.edu/pub/techreports/1995/TR1268.pdf and An Empirical Study of the Robustness of MacOS Applications Using Random Testing ACM SIGOPS Operating Systems Review 41(1) 78--86 (January 2007) https://doi.org/10.1145/1228291.1228308 I have used their techniques and tools many times in testing my own, and other, software. By chance, I found today in Web searches on another subject that Milller's group has a new paper in press in the journal IEEE Transactions on Software Engineering: The Relevance of Classic Fuzz Testing: Have We Solved This One? https://doi.org/10.1109/TSE.2020.3047766 https://arxiv.org/abs/2008.06537 https://ieeexplore.ieee.org/document/9309406 I track that journal at http://www.math.utah.edu/pub/tex/bib/ieeetranssoftwengYYYY.{bib,html} [YYYY = 1970 to 2020, by decade], but the new paper has not yet been assigned a journal issue, so I had not seen it before today. The Miller group work over 33 years has examined the reliability of common Unix tools in the face of unexpected input, and in the original work that began in 1988, they were able to demonstrate a significant failure rate in common, and widely used, Unix-family utilities. Despite wide publicity of their first paper, things have not got much better, even from reprogramming software tools in `safe' languages, such as Rust. In each paper, they analyze the reasons for the exposed bugs, and sadly, much the same reasons still exist in their latest study, and in several cases, have been introduced into code since their first work. The latest paper also contains mention of Plan 9, which moved bug-prone input line editing into the window system, and of bugs in pdftex (they say latex, but I suspect they mean pdflatex, not latex itself: pdflatex is a macro-package enhanced layer over the pdftex engine, which is a modified TeX engine). The latter are significant to me and my friends and colleagues in the TeX community, and for the TeX Live 2021 production team http://www.math.utah.edu/pub/texlive-utah/ especially because this year, Don Knuth revisited TeX and Metafont, produced new bug-fixed versions of both, plus updated anniversary editions of his five-volume Computers & Typesetting book series. His recent work is described in a new paper announced this morning: The \TeX{} tuneup of 2021 TUGboat 42(1) ??--?? February 2021 https://tug.org/TUGboat/tb42-1/tb130knuth-tuneup21.pdf Perhaps one or more list members might enjoy the exercise of applying the Barton-group fuzz tests (all of which are available from a Web site ftp://ftp.cs.wisc.edu/paradyn/fuzz/fuzz-2020/ as discussed in their paper) to 1970s and 1980s vintage Unix systems that they run on software-simulated CPUs (or rarely, on real vintage hardware). The Unix tools of those decades were generally much smaller (in lines of code), and most were written by the expert Unix pioneers at Bell Labs. It would of interest to compare the tool failure rates in vintage Unix with tool versions offered by commercial distributions, the GNU Project, and the FreeBSD community, all of which are treated in the 2021 paper. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

4 years, 1 month

Re: [TUHS] (no printed copy) (was (no subject))

by Norman Wilson

I'm not sure why people, even in a group devoted to history like ours, focus so much on whether a journal is issued in print or only electronically. The latter has become more and more common. On one hand, I too find that if something is available only electronically I'm more likely to put off reading it, probably because back issues don't pile up as visibly. On the other, in recent years I've been getting behind in my reading of periodicals of all sorts, and so far as I can tell that has nothing to do with whether a given periodical arrives on paper. If anything, electronic access makes it more likely I'll be able to catch up, because it's easier to carry a bunch of back issues around on a USB stick or loaded into a tablet or the like than to lug around lots of hardcopy. The biggest burden has been that imposed by PDF files, which are often carefully constructed to be appallingly cumbersome to read unless viewed on a letter-paper/A4-sized screen (or printed out). HTML used to be better, though the ninnies who design web pages to look like magazine ads have spoiled a lot of that over the years. Since I often want to read PDF files when travelling (e.g. conference proceedings while at the conference) I finally invested in a large-screened tablet. Even so, I have a big pile of back issues of ;login:, CACM (until ACM's policies, having little to do with the journal, recently drove me away), Rail Passenger Association News, and Consumer Reports waiting to be read. And sometimes I'm months behind on this list. My advice to those who find electronic-only publications cumbersome is to invest in either a good tablet or a good printer. I have and use both. There's no substitute for a large, high-quality screen, and sometimes there's no substitute for paper that I can flip back and forth, but I'm fine with supplying those myself. I'm still looking for a nice brass-bound leather tablet case, though. Norman Wilson Toronto ON

4 years, 1 month

XXDP formatter RX50 floppy needed

by Tom Ivar Helbekkmo

I'm having a bit of trouble with a couple of RD52 drives, and I suspect that I need a newer formatting program. The formatter floppy in my XXDP kit includes ZRQC-C-0 (ZRQCC0.BIC), and I understand that revision C is really old, and I should be running at least F, preferably H. Does anyone have (or can make) an image of a newer version of the RX50 formatter floppy? I've got an RX50 drive in my 11/83 with 2.11BSD, so it would be a simple matter to make a bootable floppy there if I just had the bits to write... :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay

4 years, 1 month

PC Unix

by Paul Ruizendaal

> IBM famously failed to buy the well-established CP/M in > 1980. (CP/M had been introduced in 1974, before the > advent of the LSI-11 on which LSX ran.) By then IBM had > settled on Basic and Intel. I do not believe they ever > considered Unix and DEC, nor that AT&T considered > selling to IBM. (AT&T had--fortunately--long since been > rebuffed in an attempt to sell to DEC.) > > Doug Besides all the truth or legend around flying and signing NDA’s, I think there were clear economic reasons for ending up with Microsoft’s DOS, and the pre-cursor to that: picking the 8088. [1] By 1980 there were an estimated 8,000 software packages for CP/M available, many aimed at small business. IBM was targeting that. The availability of source level converters for 8080 code to 8088 code made porting economically feasible for the (cottage) ISV’s. This must have been a strong argument in favour of picking the 8088 for the original PC. [2] In line with their respective tried and tested business models, Digital Research offered CP/M-86 with a per-copy license structure. Microsoft offered QDOS with a one-off license structure. The latter was economically more attractive to IBM. I don’t think either side expected clones to happen the way they did, although they did probably factor in the appearance of non-compatible work-alikes. Although some sources suggest that going with the 68000 and/or Unix were considered, it would have left the new machine without an instant base of affordable small business applications. Speed to market was a leading paradigm for the PC's design team.

4 years, 1 month

PC Unix / early Xenix

by Paul Ruizendaal

> There is some information and demos of the early 8086/80286 Xenix, > including the IBM rebranded PC Xenix 1.0 on pcjs.org > > https://www.pcjs.org/software/pcx86/sys/unix/ibm/xenix/1.0/ > > And if you have a modern enough browser you can run them from the browser as > well! > > It's amazing that CPU's are fast enough to run interpreted emulation that is > faster than the old machines of the day. That is a cool link. At the bottom of the page are two images of floppy disks. These show an ISC copyright notice. Maybe this is because the floppies contained “extensions” rather than Xenix itself. === Note that "IBM Xenix 1.0" is actually the same as MS Xenix 3.0, and arrived after MS Xenix had been available for 4 years (initially for the PDP-11 and shortly after for other CPU's): http://seefigure1.com/2014/04/15/xenixtime.html Rob Ferguson writes: "From 1986 to 1989, I worked in the Xenix group at Microsoft. It was my first job out of school, and I was the most junior person on the team. I was hopelessly naive, inexperienced, generally clueless, and borderline incompetent, but my coworkers were kind, supportive and enormously forgiving – just a lovely bunch of folks. Microsoft decided to exit the Xenix business in 1989, but before the group was dispersed to the winds, we held a wake. Many of the old hands at MS had worked on Xenix at some point, so the party was filled with much of the senior development staff from across the company. There was cake, beer, and nostalgia; stories were told, most of which I can’t repeat. Some of the longer-serving folks dug through their files to find particularly amusing Xenix-related documents, and they were copied and distributed to the attendees. If memory serves, it was a co-operative effort between a number of the senior developers to produce this timeline detailing all the major releases of Xenix. I have no personal knowledge of the OEM relationships before 1986, and I do know that there were additional minor ports and OEMs that aren’t listed on the timeline (e.g. NS32016, IBM PS/2 MCA-bus, Onyx, Spectrix), but to the best of my understanding this hits the major points. Since we’re on the topic, I should say that I’ve encountered a surprising amount of confusion about the history of Xenix. So, here are some things I know: Xenix was a version of AT&T UNIX, ported and packaged by Microsoft. It was first offered for sale to the public in the August 25, 1980 issue of Computerworld. It was originally priced between $2000 and $9000 per copy, depending on the number of users. MS owned the Xenix trademark and had a master UNIX license with AT&T, which allowed them to sub-licence Xenix to other vendors. Xenix was licensed by a variety of OEMs, and then either bundled with their hardware or sold as an optional extra. Ports were available for a variety of different architectures, including the Z-8000, Motorola 68000, NS16032, and various Intel processors. In 1983, IBM contracted with Microsoft to port Xenix to their forthcoming 80286-based machines (codenamed “Salmon”); the result was “IBM Personal Computer XENIX” for the PC/AT. By this time, there was growing retail demand for Xenix on IBM-compatible personal computer hardware, but Microsoft made the strategic decision not to sell Xenix in the consumer market; instead, they entered into an agreement with a company called the Santa Cruz Operation to package, sell and support Xenix for those customers. Even with outsourcing retail development to SCO, Microsoft was still putting significant effort into Xenix: • Ports to new architectures, the large majority of the core kernel and driver work, and extensive custom tool development were all done by Microsoft. By the time of the Intel releases, there was significant kernel divergence from the original AT&T code. • The main Microsoft development products (C compiler, assembler, linker, debugger) were included with the Intel-based releases of Xenix, and there were custom internally-developed toolchains for other architectures. Often, the latest version of the tools appeared on Xenix well before they were available on DOS. • The character-oriented versions of Microsoft Word and Multiplan were both ported to Xenix. • MS had a dedicated Xenix documentation team, which produced custom manuals and tutorials. As late as the beginning of 1985, there was some debate inside of Microsoft whether Xenix should be the 16-bit “successor” to DOS; for a variety of reasons – mostly having to do with licensing, royalties, and ownership of the code, but also involving a certain amount of ego and politics – MS and IBM decided to pursue OS/2 instead. That marked the end of any further Xenix investment at Microsoft, and the group was left to slowly atrophy. The final Xenix work at Microsoft was an effort with AT&T to integrate Xenix support into the main System V.3 source code, producing what we unimaginatively called the “Merged Product” (noted by the official name of “UNIX System V, r3.2” in the timeline above). Once that effort was completed, all Intel-based releases of UNIX from AT&T incorporated Xenix support; in return, Microsoft received royalties for every copy of Intel UNIX that AT&T subsequently licensed. It will suffice, perhaps, to simply note that this was a good deal for Microsoft.” It would be so cool if these early (1980-1984) Xenix versions were available for historical examination and study.

4 years, 1 month

Zombified SCO comes back from the dead, brings trial back to life against IBM

by Josh Good

I read the news, and I could not believe it. It's April 1st, ain't it? But then, this looks like is dated March 31. So it could be for real. Behold: https://www.theregister.com/2021/03/31/ibm_redhat_xinuos/ The PDF also is dated March 31: https://regmedia.co.uk/2021/03/31/xinuos_complaint.pdf It's hard to believe someone would go to the trouble of writing 57 pages of legalese just to make a damn joke. " Xinuos, formed around SCO Group assets a decade ago under the name UnXis and at the time disavowing any interest in continuing SCO's long-running Linux litigation, today sued IBM and Red Hat for alleged copyright and antitrust law violations. "First, IBM stole Xinuos' intellectual property and used that stolen property to build and sell a product to compete with Xinuos itself," the US Virgin Islands-based software biz claims in its complaint [PDF]. "Second, stolen property in IBM's hand, IBM and Red Hat illegally agreed to divide the relevant market and use their growing market powers to victimize consumers, innovative competitors, and innovation itself." The complaint further contends that after the two companies conspired to divide the market, IBM then acquired Red Hat to solidify its position. SCO Group in 2003 made a similar intellectual property claim. It argued that SCO Group owned the rights to AT&T's Unix and UnixWare operating system source code, that Linux 2.4.x and 2.5.x were unauthorized derivatives of Unix, and that IBM violated its contractual obligations by distributing Linux code. That case dragged on for years, and drew a fair amount of attention when SCO Group said it would sue individual Linux users for infringement. Though SCO filed for bankruptcy in 2007 and some of the claims have been dismissed, its case against IBM remains unresolved. There was a status report filed on February 16, 2018, details remaining claims and counterclaims. And in May last year, Magistrate Judge Paul Warner was no longer assigned to oversee settlement discussions. But SCO Group v. IBM is still open. " Either way, some one if fooling us hard. PS: OK, it seems it's for real: https://www.xinuos.com/xinuos-sues-ibm-and-red-hat/ I need to check my stock of pop corn, then... My take: it's obvious they want to be a nuisance so that IBM settles the case, so they then can go back home with some fresh cash. I hope IBM goes ballistic on them to the bitter end, and finally sends the zombie back to its grave. But then, IBM now has its new RedHat business to protect, so it can get interesting. -- Josh Good

4 years, 1 month

(no subject)

by M Douglas McIlroy

> I had been debating leaving Usenix for several years already; > the move to soft copy ;login: clinched it for me. I have been a loyal nonmember of ACM ever since the CACM was converted from a journal to a magazine. Usenix didn't strike quite such a decisive blow when it abandoned Computing Systems. ;login: remains as a Cheshire grin. It remains to be seen whether I'll continue to scan it in its non-tactile form. Doug

4 years, 1 month

Re: [TUHS] PC Unix (had been How to Kill a Technical Conference

by Jason Stevens

There is some information and demos of the early 8086/80286 Xenix, including the IBM rebranded PC Xenix 1.0 on pcjs.org https://www.pcjs.org/software/pcx86/sys/unix/ibm/xenix/1.0/ And if you have a modern enough browser you can run them from the browser as well! It's amazing that CPU's are fast enough to run interpreted emulation that is faster than the old machines of the day. -----Original Message----- From: Clem Cole To: M Douglas McIlroy Cc: TUHS main list Sent: 4/7/21 1:09 AM Subject: Re: [TUHS] PC Unix (had been How to Kill a Technical Conference Doug -- IIRC IBM private-labeled a Microsoft put out a version of Xenix, although I think it required an PC/AT (286) <https://mailfoogae.appspot.com/t?sender=aY2xlbWNAY2NjLmNvbQ%3D%3D&type= zerocontent&guid=6f435ae6-0f2c-4fbd-bfe2-adcbf3edac32> ? On Tue, Apr 6, 2021 at 11:36 AM M Douglas McIlroy < m.douglas.mcilroy(a)dartmouth.edu <mailto:m.douglas.mcilroy@dartmouth.edu> > wrote: > I wonder. IBM introduced the IBM PC in August of 1981. > That was years after a non-memory managed version of > Unix was created by Heinze Lycklama, LSX. Is anyone > on this list familiar with Bell Labs management thoughts > on selling IBM on LSX rather than "dos"? IBM famously failed to buy the well-established CP/M in 1980. (CP/M had been introduced in 1974, before the advent of the LSI-11 on which LSX ran.) By then IBM had settled on Basic and Intel. I do not believe they ever considered Unix and DEC, nor that AT&T considered selling to IBM. (AT&T had--fortunately--long since been rebuffed in an attempt to sell to DEC.) Doug

4 years, 1 month

Re: [TUHS] My favorite Usenix papers

by Norman Wilson

Rich Salz: > > Honeyman: "Pathalias, or the care and feeding of relative addresses" Dave Horsfall: > Are you sure that peter honeyman wrote "Pathalias" and not "pathalias"? > He seemed to have an aversion to using his shift key. Dan Cross: He actually wrote it as, "PATHALIAS _or_ The Care and Feeding of Relative Addresses". Plenty of shift to go around. :-) ==== Peter probably had a graduate student hold the caps key for him. Norman Wilson Toronto ON Used to honey bitching

4 years, 1 month

My favorite Usenix papers

by Richard Salz

Honeyman: "Pathalias, or the care and feeding of relative addresses" Ousterhout: "Why aren't operating systems getting faster as fast as hardware"

4 years, 1 month

Whither Usenix [was How To Kill A Technical Conference]

by norman＠oclsc.org

Arnold: But for several years now I have been increasingly dissatisfied with the research nature of most of the articles. Very few of them are actually useful (or even interesting) to me in a day-to-day sense. === I guess it depends on your interests, and also on what you look at. I've got way behind in reading ;login:, but have been regularly attending conferences: the Annual Technical Conference (ATC) and some workshops (HotStorage, HotCloud) that are usually co-located; LISA. I still find plenty to interest me, both in talks and in the hallway tracks, though LISA has been drying up over the years (and it's clear that USENIX know that too and are working on whether it should just be subsumed into the already-burgeoning SREcons). As I say, interests differ, but I've learned plenty of new things about OS and networking design and implementation tradeoffs, security at many levels, file systems, and storage devices. Thanks to COVID, USENIX-sponsored conferences have all been online for the past year and are expected to stay so through the end of 2021. For obvious reasons that greatly reduces the expenses of the conferences, so the registration fees are about 10% of normal. Thanks to that, I've been able to sample conferences I've never had time or money to travel to, like Security and FAST (file systems and storage). It's been well worth my time and money even though the money comes out of my own pocket. UNIX history is not part of the mainstream USENIX world these days, alas--I was disappointed that there was no official 50th- birthday party two years ago in Seattle (though the not-officially- sponsored one at LCM organized by Clem and others was a fine time, and USENIX had no objection to hosting announcements of it). I should point out that the only time I've met Our Esteemed Leader and Listrunner in person was at a USENIX conference, where he held a session to show off his reconstructed very-early PDP-11 UNIX from the tape Dennis found under the floor of the UNIX Room. I too would like to see the organization harbour some less-formal meetings or publications. The way to make that happen would be to run for the Board and to actively sponsor such stuff (with care about who is selected for the real work to avoid the problems Ted describes). Maybe that's a good idea, or maybe it's better to let the Linux and BSD worlds do their own thing. Either way I think what USENIX does is worth while. I've been a member for 40 years this year, and although it's not the same organization as it was in the early 1980s, neither is it the same world it lives in. I still think they do worth while work and I am proud to continue to support them, even though I'm not a published academic researcher, just an old-style systems hack and sysadmin from the ancient days when those were inseparable. Norman Wilson Toronto ON

4 years, 1 month

Data structures in Unix editors

by David C. Brock

All of the great discussion on this list about editors has made me curious about the data structures used in the various Unix editors. I found a great discussion of this for sam in Rob Pike’s publication “The Text Editor sam.” I’d like to read similar discussions of the data structures for ed, em, ex/vi. If anyone has suggestions of references, they would be very welcome! Similarly, if there are any pointers to references on some other data structures in editors like TECO, QED and E, I’d welcome them as well. All the best, David ........... David C. Brock Director and Curator Software History Center Computer History Museum computerhistory.org/softwarehistory<http://computerhistory.org/softwarehistory> Email: dbrock(a)computerhistory.org Twitter: @dcbrock Skype: dcbrock 1401 N. Shoreline Blvd. Mountain View, CA 94943 (650) 810-1010 main (650) 810-1886 direct Pronouns: he, him, his

4 years, 1 month

30th Anniversary of most epic netnews post

by Ron Natalie

>From spaf(a)cs.purdue.EDU Thu Apr 4 23:11:22 1991 Path: ai-lab!mintaka!mit-eddie!wuarchive!usc!apple!amdahl!walldrug!moscvax!perdue!spaf From: spaf(a)cs.purdue.EDU (Gene Spafford) Newsgroups: news.announce.important,news.admin Subject: Warning: April Fools Time again (forged messages on the loose!) Message-ID: <4-1-1991(a)medusa.cs.purdue.edu> Date: 1 Apr 91 00:00:00 GMT Expires: 1 May 91 00:00:00 GMT Followup-To: news.admin Organization: Dept. of Computer Sciences, Purdue Univ. Lines: 25 Approved: spaf(a)cs.purdue.EDU Xref: ai-lab news.announce.important:19 news.admin:8235 Warning: April 1 is rapidly approaching, and with it comes a USENET tradition. On April Fools day comes a series of forged, tongue-in-cheek messages, either from non-existent sites or using the name of a Well Known USENET person. In general, these messages are harmless and meant as a joke, and people who respond to these messages without thinking, either by flaming or otherwise responding, generally end up looking rather silly when the forgery is exposed. So, for the few weeks, if you see a message that seems completely out of line or is otherwise unusual, think twice before posting a followup or responding to it; it's very likely a forgery. There are a few ways of checking to see if a message is a forgery. These aren't foolproof, but since most forgery posters want people to figure it out, they will allow you to track down the vast majority of forgeries: o Russian computers. For historic reasons most forged messages have as part of their Path: a non-existent (we think!) russian computer, either kremvax or moscvax. Other possibilities are nsacyber or wobegon. Please note, however, that walldrug is a real site and isn't a forgery. o Posted dates. Almost invariably, the date of the posting is forged to be April 1. o Funky Message-ID. Subtle hints are often lodged into the Message-Id, as that field is more or less an unparsed text string and can contain random information. Common values include pi, the phone number of the red phone in the white house, and the name of the forger's parrot. o subtle mispellings. Look for subtle misspellings of the host names in the Path: field when a message is forged in the name of a Big Name USENET person. This is done so that the person being forged actually gets a chance to see the message and wonder when he actually posted it. Forged messages, of course, are not to be condoned. But they happen, and it's important for people on the net not to over-react. They happen at this time every year, and the forger generally gets their kick from watching the novice users take the posting seriously and try to flame their tails off. If we can keep a level head and not react to these postings, they'll taper off rather quickly and we can return to the normal state of affairs: chaos. Thanks for your support. Gene Spafford, Net.God (and probably tired of seeing this message)

4 years, 1 month

Re: [TUHS] Data structures in Unix editors

by jnc＠mercury.lcs.mit.edu

> From: David C. Brock > I'd like to read similar discussions of the data structures for ed, em, > ex/vi. ... Similarly, if there are any pointers to references on some > other data structures in editors like TECO, QED and E, I'd welcome them > as well. I don't have any discussions I can point you at, but I do have source - for two things which are somewhat older than most of the ones you mention (ex/vi/etc). The first is a TECO from the fourth floor V6 machine (DSSR/RTS) at Tech Sq at MIT: http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco There's some rudimentary documentation in there, in teco.doc, but don't expect too much. You'll have to rely on the source, which is in MACRO-11 - but it seems to be reasonably well commented. This actually predates V6; it was originally written for an MIT OS called DELPHI, which ran on an -11/45 which was the main EECS undergrad machine. At some point (probably post the Unix port), it was modified to have '^R mode', which was a WYSIWYG display mode a lot like the one in the ITS TECO in which EMACS was first written. I have also put up the Montgomery Emacs for Unix: http://ana-3.lcs.mit.edu/~jnc/tech/unix/emacs This is the version we were running on the 5th floor MIT V6 machine (CSR), which by that point have absorbed a few V7isms (e.g. some ioctl() stuff). So don't expect to be able to compile and run it, without a fair amount of work. (I vaguely recall that it needs I+D space, so maybe not on a /23 at all.) But at least the source is in C, so you can read it. I don't think there's an un-modified version online (i.e. the original Montgomery source), alas. Noel

4 years, 1 month

[tuhs] ACM Turing Award for 2020: Unix roots

by Nelson H. F. Beebe

This just came in: ACM has named Alfred Vaino Aho and Jeffrey David Ullman recipients of the 2020 ACM A. M. Turing Award https://awards.acm.org/about/2020-turing for fundamental algorithms and theory underlying programming language implementation and for synthesizing these results and those of others in their highly influential books, which educated generations of computer scientists. Most of us probably have several of their books on the shelf; I certainly do! ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

4 years, 1 month

Re: [TUHS] Remember the ed thread?

by John Cowan

I missed the fact that Posix and Linux ed support s/foo/bar/3 (as opposed to s3/foo/bar); ex does not, unfortunately. We need a Great Unification of Line Editors.

4 years, 1 month

Re: [TUHS] Remember the ed thread?

by norman＠oclsc.org

John Cowan: We need a Great Unification of Line Editors. ==== A standard for the standard editor? I thought the nice thing about standards was that there were so many of them. Norman Wilson Toronto ON

4 years, 1 month

Remember the ed thread?

by Larry McVoy

I had *.clients.your-server.de crawling mcvoy.com in violation of my robots.txt. For whatever reason, the tty settings (or something) made vi not work, I dunno what the deal is, stty -tabs didn't help. So I had to resort to ed to write and debug the little program below. It was surprisingly pleasant, it's probably the first time I've used ed for anything real in at least a decade. My fingers still know it. +1 for ed. It's how many decades old and still useful? #!/usr/libexec/bitkeeper/bk tclsh int main(void) { FILE log = popen("/var/log/apache2/dns.l", "r"); string buf, ip; string dropped{string}; fconfigure(log, buffering: "line"); while (buf = <log>) { unless (buf =~ /([^ ]+\.your-server\.de\.) /) continue; ip = $1; if (defined(dropped{ip})) continue; dropped{ip} = "yes"; warn("DROP ${ip}\n"); system("/sbin/iptables -I INPUT -s ${ip} -j DROP"); } }

4 years, 1 month

Re: [TUHS] Remember the ed thread?

by arnold＠skeeve.com

Andy Kosela <akosela(a)andykosela.com> wrote: > On 3/29/21, arnold(a)skeeve.com <arnold(a)skeeve.com> wrote: > > Andy Kosela <akosela(a)andykosela.com> wrote: > > > >> If ed(1) had cursor positioning and full screen capabilities along > >> with line oriented editing (similar to Atari 8-bit default editor) it > >> would be perfect. I still love it though and use it pretty often. > > > > Try out the 'se' editor, see www.se-editor.org. > > Thanks. It is a nice editor, but it actually resembles ex(1) when > using visual mode. Maybe I am missing something but it appears you > cannot actually use cursor keys to visually edit lines in the upper > area of the screen in se -- you can only edit cmd line. > > As far as I know there is no editor in the Unix land which gives you > the ability to work in the ed(1) line oriented mode BUT also allowing > to freely move cursor keys in all directions. I gave example of the > Atari editor[1] which does exactly that. I believe to accomplish it > on Unix one would need to hack ed(1) and add ncurses(3) cursor > positioning. > > --Andy > > [1] https://youtu.be/c9o92l5gupI

4 years, 1 month

Re: [TUHS] Remember the ed thread?

by M Douglas McIlroy

> the hammer fired to make an impression the ribbon on the paper, which was > caused the noise people associated with computer printers. GE outdid the printer with a fantastically fast pneumatic card reader. The make and break of the suction on each card repeated at aural frequency and so loud that I hied off to the instrument stockroom to borrow a noise meter. It was 90db at the operator's position.

4 years, 1 month

Re: [TUHS] Remember the ed thread?

by norman＠oclsc.org

ed is the standard editor, they say. The b command (stands for browse) came from late-1970s U of T; rob probably brought it to 1127. There were a handful of other syntactic conveniences, like being allowed to leave off the final delimeter of an s command, and declaring that a missing address means 1 before the comma or semicolon and $ after, so 3,s/fish/&head works over all lines from 3 to the last, and , standing alone addresses the whole buffer. Also the idea that s followed by a digit N means start with the Nth instance of the pattern: s3/fish/&head/ affects only the third fish, and s3/fish/&head/g every fish after the second. I have all those tweaks, plus a few others, embedded in my fingers from the qed produced by the same Toronto hacks. I contracted it from the copy rob left behind at Caltech, which means it has been my editor of choice for 40 years now (with sam as an alternate favourite since its inception 35 years or so ago). That qed has a lot of cryptic programming stuff that I have mostly forgotten because it was never that useful, but what really hooked me was a. Multiple buffers, with the ability to move and copy text between them reasonably smoothly (both with the m and t commands and with an interpolate-into-input magic character); b. The > < | commands, which respectively send the addressed lines to a shell command (default ,), replace the addressed lines or append after the single addressed line the standard output of the shell command (default .), and replaced addressed lines with what you get by sending them (default ,) to the shell command, replacing them with its standard output. The last operators make qed into a kind of workbench, both for massaging data and for constructing a list of commands to send to the shell. I gather current Linux/BSD eds have > and <, spelled r ! and w !, but without | it just ain't the same, rather like the way | revolutionized the shell. I believe the credit for U of T ed and qed go mainly to Rob Pike, Tom Duff, Hugh Redelmeier, and the (alas now late) David Tillbrook. David remained an avid user of qed, continuing to add stuff to it. Norman Wilson Toronto ON PS: this message, as most of my e-mail, composed by typing it into qed, editing as needed, then running >mail tuhs(a)tuhs.org

4 years, 1 month

Re: [TUHS] Soft hyphens

by M Douglas McIlroy

> When hyphenation is disabled, soft (discretionary) hyphens are > interpreted. In pre-Unix roff hyphenation mode 0 turned off all breaking of words. The original troff, however, behaved as described above, and alsowant broke genuinely hyphenated words in mode 0. If you t really wants to break words one day, you may use

4 years, 1 month

Re: [TUHS] ching in Unix

by Norman Wilson

Noel Hunt: Who in the Unix world today writes, would even be able to write, a manual entry like that. ==== Doug McIlroy is still around, though (alas) he doesn't write many manual entries these days. Norman Wilson Toronto ON

4 years, 1 month

Re: [TUHS] [TUHS} .ss paragraph-style-footnote example, then and now

by M Douglas McIlroy

As the example came through in my mail reader--in a different, proportionally spaced font, the effect of .ll in the examples was hard to figure out. Which of the two line lengths in the new case is actually operative? Why are the inch lengths in the old and new examples so different? The new example is ticklish, since it depends on the peculiar AI that identifies sentence endings. Suppose reference 1 is naively broken after "Soc." I prefer the old example because it's clean to read, isn't mixed up with AI, and incidentally illustrates a nontrivial use for .nop. Doug > The example itself originally read: > > .ll 4.5i > 1.\ This is the first footnote.\c > .ss 48 > .nop > .ss 12 > 2.\ This is the second footnote. > > RESULT: > > 1. This is the first footnote. 2. This > is the second footnote. > > The new version of this example is: > > .ie n .ll 50n > .el .ll 2.75i > .ss 12 48 > 1. J. Fict. Ch. Soc. 6 (2020), 3\[en]14. > 2. Better known for other work. > > RESULT: > > 1. J. Fict. Ch. Soc. 6 (2020), 3-14. 2. Better > known for other work.

4 years, 2 months

Transfer of Plan 9 to the Plan 9 Foundation

by arnold＠skeeve.com

FYI, folks. Arnold > Date: Tue, 23 Mar 2021 06:06:49 -0700 > From: a(a)9srv.net > To: 9fans(a)9fans.net > Subject: [9fans] Transfer of Plan 9 to the Plan 9 Foundation > > We are thrilled to announce that Nokia has transferred the copyright of > Plan 9 to the Plan 9 Foundation. This transfer applies to all of the > Plan 9 from Bell Labs code, from the earliest days through their final > release. > > The most exciting immediate effect of this is that the Plan 9 Foundation > is making the historical 1st through 4th editions of Plan 9 available > under the terms of the MIT license. These are the releases as they > existed at the time, with minimal changes to reflect the above. > > 1st and 2nd edition were never released as open source software, and > both (but especially 1st edition) were only available to a very small > number of people. 3rd and 4th were previously available as open source, > but under a license which was problematic for some people (especially > the 3rd edition). We think making these available under the MIT license > is something that's going to be a significant benefit for all projects > using Plan 9 code. While this doesn't automatically change the license > on any downstream projects, and you're welcome to keep using the LPL if > you like, you now have the option of switching to MIT, which we think > most everyone will find preferable. > > Obviously, for folks in the Plan 9 community, there isn't a way to say > "thank you" to Bell Labs, and its various parent organizations, that's > really adequate. None of us would be talking about any of this if it > weren't for the work done there for decades. All of us here at the Plan > 9 Foundation express our sincerest thanks to the team at Nokia who made > this possible, the Plan 9 alumni who supported the effort, and the Plan > 9 community who have kept kernels booting and the userland useful. > > The historical releases are available right now at: > https://p9f.org/dl/ > > You can read Nokia's press release on the transfer here: > https://www.bell-labs.com/institute/blog/plan-9-bell-labs-cyberspace/ > > Thank you for your time, > Anthony Sorace > Plan 9 Foundation > > ------------------------------------------ > 9fans: 9fans > Permalink: https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M63f81768e4ffdfa4… > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

4 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS