I heard a while back, that the reason that Microsoft has avoided *ix so
meticulously, was that back when they sold Xenix to SCO, as part of the
deal Microsoft signed a noncompete agreement that prevented them from
selling anything at all similar to *ix.
True?
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.3047766https://arxiv.org/abs/2008.06537https://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/ -
-------------------------------------------------------------------------------
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
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
> 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.
> 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.
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
> 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
There is some information and demos of the early 8086/80286 Xenix,
including the IBM rebranded PC Xenix 1.0 on pcjs.orghttps://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
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