On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat &lt;krewat(a)kilonet.net <mailto:krewat@kilonet.net>> wrote: https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni… Leaving licensing and copyright issues out of this mental exercise, what would we have now if it wasn't for Linux? Not what you'd WANT it to be, although that can add to the discussion, but what WOULD it be? I'm not asking as a proponent of Linux. If anything, I was dragged kicking and screaming into the current day and have begrudgingly ceded my server space to Linux. But if not for Linux, would it be BSD? A System V variant? Or (the horror) Windows NT? BSD was in decent enough shape at the time to run on PCs. Though it fragmented early through no fault of Linux. And the AT&T lawsuit created a lot of FUD in the area without actually protecting System V. It's unclear if another thing would have popped up to fill the void... Linux flourished in the confusion, but without it, it's hard to know if something else would have been developed before the AT&T lawsuit settled. Warner I do understand that this has been discussed on the list before. I think, however, it would make a good late-summer exercise. Or late winter depending on where you are :) art k.

On 8/26/2019 7:56 PM, William Pechter wrote: Here, here!

I always thought Research 10th Edition was fantastic. Even the 8th edition was an improvement on most of its successors. But things flowed another way, with muddy streams mixing in. -rob

Hey Rob, I followed Bell Labs through the papers, the Lions doc, but I didn't get any insight into Research after v7 or so. Can you tell us what you liked about the later versions? I don't want to be a total suck up but I've been a fan of your insight ever since you said something like "if you think you need threads your processes are too fat". I've had long discussions with Linus about how to make that statement 100% true (partial page table sharing across processes, how do you make that work in general). We didn't come to an answer but we both agreed that processes should be as cheap as threads and mmap is the way to share data. On Tue, Aug 27, 2019 at 10:58:54AM +1000, Rob Pike wrote: edition -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

I always thought Research 10th Edition was fantastic. Even the 8th edition was an improvement on most of its successors. But things flowed another way, with muddy streams mixing in.

I always thought Research 10th Edition was fantastic. Even the 8th edition was an improvement on most of its successors. But things flowed another way, with muddy streams mixing in.

On 28/08/19, Jason Stevens wrote: v8/v9. I never noticed the vax boot stuff as it was buried in the tree. It’s possible that it’s buildable. Or it could be incomplete like the Mach 2.5 VAX missing system headers…. if it’s like v8/v9 which needed a BSD machine to bootstrap. Check out "Setting Up a Research UNIX System" by Norman Wilson. troff sources are in v10.

[snip]

As for what mmap() doesn't do right, I started using memory mapped files back in the early 80s on VMS on a VAX-11/780 when I and a colleague were converting a database from TOPS-10 to VMS. Perhaps I am misunderstanding your dislike for mmap() but please, enlighten me. It was my understanding at the time that it was akin to swapping/virtual-memory using an MMU. The difference was that instead of using the main paging area, the kernel would use an actual file. Why would mmap() be a bad thing, when it's hooked into the kernel, and possibly hardware, at such a low point?

Which was that the page cache is *the* cache. There is nothing else.

On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: I might be making too big of a deal about it. mmap semantics mattered a lot when SMPs first showed up and main memory was small. It meant that you could have multiple CPUs seeing and working on the same chunk of data at the same time. It's very similar to way that IOMMUs are exposed to user space these days, enabling virtual machines direct access to the I/O devices. ZFS breaks that model, the data is all in the ARC and if you mmap it they have to bcopy the data out of the ARC, into the page cache and now they have a consistency problem, you could modify stuff via mmap or write and they have to manage that. That consistency problem is the main reason that Sun almost completely killed the buffer cache (it still was used for inodes and directories but that was it). That consistency problem is a pain in the rear, all sorts of race conditions and it tended to bit rot. Jeff and Bill are smart people so I suspect they got it right but I'm still stunned that they took such an architecturally bad approach. And even more stunned that the oversight people approved it. There is zero chance that the Sun I worked at would have allowed that. --lm

Wait, are you arguing for STREAMS over sockets? Dear god, please no. Have you ever used STREAMS (not Ritchies streams, those were OK)? I have. I ported Lachman's STREAMS based TCP/IP stack twice, once to a long since defunct super computer called the ETA-10 and then to SCO Unix. I've got way more STREAMS experience than most people and I can tell you that sockets are WAY WAY better. I get the "it should have just been file I/O" except that I don't. I tried to write a library that let you open up /net/tcp/$host:$port and do I/O like it was a file descriptor. That works for a lot of stuff but I ran into problems quickly. A networking connection is not a file handle. You can make some stuff work but I couldn't figure out how to do all of it. You end up having to do ioctls to handle the stuff that doesn't fit well into the file system name space. I think plan 9 did this sort of thing, maybe Rob can prove me wrong or remember where it didn't match. I do know that STREAMS came back to Solaris, some VP inked a shitty deal with Lachman and bought the rights to the stack. It was slow as molasses in the winter and customers absolutely hated it. Sun got Mentat to redo it for perf but customers still hated it, they understood sockets, everyone else had sockets, they wanted sockets and they got them. Sun put them back and nobody ever asked about STREAMS again. On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

streams were OK but Dennis himself told me he didn't intend them for networking. They were a simple mechanism for pushing line disciplines onto tty drivers. I can't remember exactly what he said, this was back in ~1988 or so and I was talking to him about the STREAMS stuff. He wasn't very happy with it and I'm pretty sure he said something like streams weren't design to mux multiple sources or network connections. I think he sort of grudgingly gave credit that they made it work but he seemed to think that it was twisting streams more than they should be twisted. On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: realized mattered meant chunk these completely directories I'm http://www.mcvoy.com/lm -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

streams were OK but Dennis himself told me he didn't intend them for networking. They were a simple mechanism for pushing line disciplines onto tty drivers. I can't remember exactly what he said, this was back in ~1988 or so and I was talking to him about the STREAMS stuff. He wasn't very happy with it and I'm pretty sure he said something like streams weren't design to mux multiple sources or network connections. I think he sort of grudgingly gave credit that they made it work but he seemed to think that it was twisting streams more than they should be twisted. On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: realized mattered meant chunk these completely directories I'm http://www.mcvoy.com/lm -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

I find it hard to believe what you remember Dennis saying. The point of dmr's streams was to support networking research in the lab and avoid the myriad bugs of the mpx interface by stepping around them completely. Perhaps it's out of context. -rob On Wed, Aug 28, 2019 at 9:00 AM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: > streams were OK but Dennis himself told me he didn't intend them for > networking. They were a simple mechanism for pushing line disciplines > onto tty drivers. > > I can't remember exactly what he said, this was back in ~1988 or so > and I was talking to him about the STREAMS stuff. He wasn't very > happy with it and I'm pretty sure he said something like streams > weren't design to mux multiple sources or network connections. > I think he sort of grudgingly gave credit that they made it work > but he seemed to think that it was twisting streams more than they > should be twisted. > > On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: > > oh maybe I meant "streams" not "STREAMS" I always got confused if the > > original ritchie spec was upper or lower case. Charles Forsyth coded > > it into the York Uni Vaxen, worked fine. I left shortly after to do > > stuff at UCL, it only came back into my life when at UQ in Australia > > we got an ICL "certified" SYSV host and along side dead technology > > like RFS up it popped (I think ICL had coded an OSI stack we were > > testing) > > > > -G > > > > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: > > > > > > Wait, are you arguing for STREAMS over sockets? Dear god, please no. > > > Have you ever used STREAMS (not Ritchies streams, those were OK)? > > > I have. I ported Lachman's STREAMS based TCP/IP stack twice, once > > > to a long since defunct super computer called the ETA-10 and then > > > to SCO Unix. I've got way more STREAMS experience than most people > > > and I can tell you that sockets are WAY WAY better. I get the "it > > > should have just been file I/O" except that I don't. I tried to > > > write a library that let you open up /net/tcp/$host:$port and do > > > I/O like it was a file descriptor. That works for a lot of stuff > > > but I ran into problems quickly. A networking connection is not > > > a file handle. You can make some stuff work but I couldn't figure > > > out how to do all of it. You end up having to do ioctls to handle > > > the stuff that doesn't fit well into the file system name space. > > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > > > or remember where it didn't match. > > > > > > I do know that STREAMS came back to Solaris, some VP inked a shitty > > > deal with Lachman and bought the rights to the stack. It was slow > > > as molasses in the winter and customers absolutely hated it. Sun > > > got Mentat to redo it for perf but customers still hated it, they > > > understood sockets, everyone else had sockets, they wanted sockets > > > and they got them. Sun put them back and nobody ever asked about > > > STREAMS again. > > > > > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: > > > > BSD, but with the original STREAMS semantics, not sockets. > > > > > > > > DARPA did us no favours accepting sockets in place of simple file I/O > > > > semantics for networks. > > > > > > > > Newcastle connection put the namespace into > > > > /.../remote-part/path/to/thing which I felt was also good. > > > > > > > > So for me, 7 -> BSD -> got worse for some values of worse > > > > > > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: > > > > > > > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: > > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: > > > > > > > Which was that the page cache is > > > > > > >*the* cache. There is nothing else. > > > > > > Yeah, I re-read what you wrote a few times after I replied, and > realized > > > > > > what you meant ... eventually ;) > > > > > > > > > > I might be making too big of a deal about it. mmap semantics > mattered > > > > > a lot when SMPs first showed up and main memory was small. It > meant > > > > > that you could have multiple CPUs seeing and working on the same > chunk > > > > > of data at the same time. > > > > > > > > > > It's very similar to way that IOMMUs are exposed to user space > these > > > > > days, enabling virtual machines direct access to the I/O devices. > > > > > > > > > > ZFS breaks that model, the data is all in the ARC and if you mmap > > > > > it they have to bcopy the data out of the ARC, into the page cache > > > > > and now they have a consistency problem, you could modify stuff > > > > > via mmap or write and they have to manage that. > > > > > > > > > > That consistency problem is the main reason that Sun almost > completely > > > > > killed the buffer cache (it still was used for inodes and > directories > > > > > but that was it). That consistency problem is a pain in the rear, > > > > > all sorts of race conditions and it tended to bit rot. > > > > > > > > > > Jeff and Bill are smart people so I suspect they got it right but > I'm > > > > > still stunned that they took such an architecturally bad approach. > > > > > And even more stunned that the oversight people approved it. There > > > > > is zero chance that the Sun I worked at would have allowed that. > > > > > > > > > > --lm > > > > > > -- > > > --- > > > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm >

On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: Rob - this syncs with what Dennis I had talked about too *i.e.* Using streams for the serial interface; as the line disciplines stuff was a mess by that point. I cannt say I remember talking to him about using streams for networking.

oh maybe I meant "streams" not "STREAMS" I always got confused if the original ritchie spec was upper or lower case. Charles Forsyth coded it into the York Uni Vaxen, worked fine. I left shortly after to do stuff at UCL, it only came back into my life when at UQ in Australia we got an ICL "certified" SYSV host and along side dead technology like RFS up it popped (I think ICL had coded an OSI stack we were testing) -G

Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of one. OSI's dead and hardly mourned these days, but did anyone in the Unix world ever get beyond the 4.4BSD fragmentary implementation?

I have OSF/1 1.0 running on gxemul … Any idea on where/ how to configure OSI? OSF/1 Release 1 (OSFMIPS) console login: root Last login: Thu Aug 29 06:03:07 on console DEC OSF/1 V1.0 (Rev. 166); Sun Jun 07 19:23:34 CDT 1970 DEC OSF/1 V1.0 Worksystem Software (Rev. 161) # find / -name 'osi*' -print # *From: *Peter Jeremy &lt;peter(a)rulingia.com&gt; *Sent: *Wednesday, August 28, 2019 2:47 PM *To: *Wesley Parish &lt;wobblygong(a)gmail.com&gt; *Cc: *TUHS main list &lt;tuhs(a)minnie.tuhs.org&gt; *Subject: *Re: [TUHS] If not Linux, then what? On 2019-Aug-28 18:19:21 +1200, Wesley Parish &lt;wobblygong(a)gmail.com&gt; wrote: There was ISODE (https://en.wikipedia.org/wiki/ISO_Development_Environment) I recall experimenting with it but didn't actually use it in anger. I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack - we had customers who wanted/used FTAM and I was surprised to find it came with the OS. -- Peter Jeremy

On Wed, 28 Aug 2019 at 10:05, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: OSF/1 for MIPS wasn't actually a beta but it might as well have been. It was slow, it was buggy, and DEC dropped support for it fairly quickly after it was released. It was never ported to any of the R4k machines.

Perhaps Clem can shed some light on why DEC did a MIPS machine?

On 2019, Aug 28, at 2:56 PM, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy &lt;lm(a)mcvoy.com <mailto:lm@mcvoy.com>> wrote: Perhaps Clem can shed some light on why DEC did a MIPS machine? I did not work for DEC at the time and obviously, I was not in the room, so this is what I can say I picked up. Supnik would be a better person to ask. That said, some things I do know about the time/and behinds the scene. Jupiter and Prism had been canceled. Alpha did not yet exist (and would not for another 2 years) Cutler had left for Microsoft etc.. Sun was clearly on its game The VAX on a Chip just was not cutting it RISC architectures were the hot item Here is where I get fuzzy on details. I believe a prototype (i.e. skunk works) MIPS was running at WRL in Palo Alto running Ultrix and DEC windows, I think using some sort of cheap ??PC?? chassis. But the performance of the prototype was excellent and cost was cheaper than the current vax products. Somebody sr, maybe Bob, shows this to Sr management and got the money to productize it. The issue as making an official Ultrix for it was I know a big one. Ultimately, DEC farmed that work out to us at LCC (with us eventually taking over all of Ultrix - MIPS and Vax).

There was ISODE (https://en.wikipedia.org/wiki/ISO_Development_Environment ). I recall experimenting with it but didn't actually use it in anger.

I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack - we had customers who wanted/used FTAM and I was surprised to find it came with the OS.

and I can tell you that sockets are WAY WAY better. I get the "it should have just been file I/O" except that I don't. I tried to write a library that let you open up /net/tcp/$host:$port and do I/O like it was a file descriptor. That works for a lot of stuff but I ran into problems quickly. A networking connection is not a file handle. You can make some stuff work but I couldn't figure out how to do all of it. You end up having to do ioctls to handle the stuff that doesn't fit well into the file system name space. I think plan 9 did this sort of thing, maybe Rob can prove me wrong or remember where it didn't match.

On Tue, Aug 27, 2019 at 04:16:18PM -0700, Bakul Shah wrote: I dunno. I can't look at that and know what it means. So it means I have

to toss (by the time this came out) a decade or more worth of knowing how to use sockets and learn this new model that may or may not go anywhere.

That would have made a huge difference. The problem with Unix is it is largely good enough. All sorts of warts appeared over the years but you can get your job done. Plan 9 was such a big departure that it never gained traction. Having it conform to Posix or pick the most popular Unix (SunOS? BSD?) and conform to that. I'm biased but even if I wasn't I'd have picked SunOS, virtually all open source back in the day compiled out of the tarball on SunOS. Everyone else had to tinker or run configure or whatever.

In re: the socket() thing... I remember getting into something (forget what) back in the early 90's, writing something (again, I forget what) and realizing what I needed to do to open a socket to a remote endpoint. I remember thinking "wait, I can't just open("hostname:port", O_TCP); ???"

And, horror of all horrors, I need to deal with little/big endian things? ntohs(), htons(), et al?

On Mon, Aug 26, 2019 at 7:28 PM Warner Losh &lt;imp(a)bsdimp.com&gt; wrote: But what really allowed Linux to take off the AT&T vs. UCB/BSDi lawsuit. At the time Linux, didn't have networking much less a window manager etc... so lot of people, mysef included (incorrectly thinking is was a copyright case) thought we were going to lose a UNIX for our inexpensice (i.e. 'cheap' 386 based systems) so we all started started to hack on Linux 0.99xxx [my first real serious taste was an early Slackware version on a billion floppies fairly soon after Linus made it available and Patrick pulled together his first distribution]. But ... (and as I have point out elsewhere - see http://technique-societe.cnam.fr/la-recherche-sur-les-systemes-des-pivots-d…] .... if AT&T had won the case, all the other UNIX flavors (Linux included would have had to have been pulled from the market). So in many ways, this question is not really a fair one. AT&T lost the case, and Linux got the ball and ran for it. That said, I'll drop into the hypotheical, if AT&T had lost and Linux had not been there ..... then... I do think some flavor of BSD would have been the winner. The two wild cards are from Sun and OSF/CMU. As Larry says is what about SunOS and Solaris, although the legals of Sun doing that I wonder. The other question is Mach/OSF (I know Larry does not like the codebase). But one of the *BSD, Mach or an FOSS Sun code base would have had the most legs. Clem

On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote: It's really hard to answer these what-if questions. The *BSD's suffered from some really toxic politics which resulted in the fragmentation, but it also no doubt turned away some developers. I had friends at MIT who were urging me to quit the "toy" Linux and switch to the more "Real" Unix efforts. But I got to meet at least one very toxic personality in person which immediately turned me away from that offer --- and I got my start on BSD 4.3 with Project Athena. (For all that people used to like to complain about Linus's e-mail persona, I *much* preferred to work with Linus than with some of the personalities in the *BSD/HURD communities.) People are very fond of blaming the *BSD's failure to become popular on the AT&T lawsuit, and that no doubt didn't help. But it's not at all clear to me that was the only, or even the primary, reason.

On Aug 26, 2019, at 7:39 PM, Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: On Mon, Aug 26, 2019 at 10:16:58PM -0400, Theodore Y. Ts'o wrote: But I got to meet at least one very toxic personality in person which immediately turned me away from that offer --- and I got my start on BSD 4.3 with Project Athena. (For all that people used to like to complain about Linus's e-mail persona, I *much* preferred to work with Linus than with some of the personalities in the *BSD/HURD communities.) I agree with Ted and I'm seeing it to this day, I hang with some BSD folks and they spend way too much time complaining about people. Yeah, this. I don’t know about these days, but…. End of the 90s, early 2000s, I was deeply involved in the Linux port to System/390 and then zSeries. Sometime, probably ’99, maybe ’00, I went to a Linux conference in Atlanta; I talked a little about Linux on S/390 and the things we were looking for help with. And I went to the NetBSD booth. I mean, even then, NetBSD’s thing was that it ran on all sorts of architectures. So I introduced myself, to say, “hey, if you guys want a development environment to hammer out a S/390 port, I can probably hook you up.” What I got was a btiter rant about Linux’s “so-called portability” and I was basically told to FOAD. That was…quite a surprise, having been working in a mostly-supportive community, albeit one in which the manufacturer was pretty dubious about the port. Adam

On another note, and to get back to the original question, I'm a little surprised that nobody here seems to have mentioned something like an outgrowth of Minix.

One point/ direction nobody seems to have mentioned was “what if Linus found out about BSD on PC hw”? From what I’ve read he wasn’t aware of it, so perhaps a very different outcome could have been

removing the caustic personalities ) or at worst forked it.

possible components of answer regarding animation/CGI: o SGI/MIPS/IRIX would have fared better/longer o Jobs would have pushed Pixar towards Mach o P4+NVIDIA would still have been disruptive (https://secure2.linuxjournal.com/ljarchive/LJ/099/6011s1.html) o Gates would have done more Windows had usable TCP/IP, at least starting with Windows 3, from Trumpet, Chameleon and others. I found/find the Microsoft 32 bit implementation preferable running Mosaic and Netscape, but had to do some work with 16 bit Trumpet a few years ago for a client that needed me to make some things work in DOS outside of Win 3.1.

I think the biggest difference would have been no git and therefore no github, etc.

On Mon, 26 Aug 2019 at 19:14, Arthur Krewat &lt;krewat(a)kilonet.net&gt; wrote: I can make a firm "dunno" sound :-) Some facts can come together to point away from a number of possibilities... - If you look at the number of hobbyist "Unix homages" that emerged at around that time, it's clear that there was a sizable community of interested folk willing to build their own thing, and that weren't interested in Windows NT. (Nay, one should put that more strongly... That had their minds set on something NOT from Microsoft.) So I think we can cross Windows NT off the list. - OS/2 should briefly come on the list. It was likable in many ways, if only IBM had actually supported it... But it suffers from something of the same problem as Windows NT; there were a lot of folk that were only slightly less despising of IBM at the time than of Microsoft. - Hurd was imagined to be the next thing... To borrow from my cookie file... "Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5." -- Andrew Tanenbaum, 1992. % "You'll be rid of most of us when BSD-detox or GNU comes out, which should happen in the next few months (yeah, right)." -- Richard Tobin, 1992. [BSD did follow within a year] % "I am aware of the benefits of a micro kernel approach. However, the fact remains that Linux is here, and GNU isn't --- and people have been working on Hurd for a lot longer than Linus has been working on Linux." -- Ted T'so, 1992. Ted has been on this thread, and should be amused (and slightly disturbed!) that his old statements are being held here and there, ready to trot out :-). In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was enough going on that there was plenty of room for them to have done so anyways. I'm not sure what to blame on whatever happened post-1992, though I'd put some on Microsoft Research having taken the wind out of Mach's sails by hiring off a bunch of the relevant folk. In order for Hurd to "make it," Mach has to "make it," too, and it looked like they were depending on CMU to be behind that. (I'm not sure I'm right about that; happy to hear a better story.) Anyway, Hurd *might* have been a "next thing," and I don't think the popularity of Linux was enough to have completely taken wind out of its sails, given that there's the dozens of "Unix homages" out there. - I'd like to imagine Plan 9 being an alternative, but it was "properly commercial" for a goodly long time (hence not amenable to attaching waves of hackers to it to add their favorite device drivers), and was never taken as a serious answer. Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that? mid or late '90s?) but only from afar. - FreeBSD is the single best answer I can throw up as a possibility, as it was the one actively targeting 80386 hardware. And that had the big risk of the AT&T lawsuit lurking over it, so had that gone in a different direction, then that is a branch sadly easily trimmed. If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ... something else, I'd think. I don't know which to suggest. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"

I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic marketing, and their close-to-outright-hostility to 3rd-party developers didn't help.  But what killed it, really, was how damn good its 16-bit support was.  It *was* a better DOS than DOS and a better Windows than 3.11fW.  So no one wrote to the relatively tiny market of 32-bit OS/2.

I have a hypothesis about Linux's ascendance too, which is a personal anecdote I am inflating to the status of hypothesis.  As I recall, the *BSDs for 386 all assumed they owned the hard disk.  Like, the whole thing.  You couldn't, at least in 1992, create a multiboot system--or at least it was my strong impression you could not.  I was an undergrad.  I had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and Windows to write my papers (I don't know about you, but I wanted to write in my room, where I could have my references at hand and be reasonably undisturbed; sure Framemaker was a much better setup than Word For Windows 1.2 but having to use it in the computer lab made it a nonstarter for me).  Papers, and, well, to play games.  Sure, that too.

On 8/28/2019 4:27 PM, Adam Thornton wrote: OS/2 was slick and if they could've kept the W\indows 3.x compatibility (the Win32S was a sliding target that Microsoft kept changing. There was a pretty decent Unix work-alike ported to the top of OS/2 that made most of the public domain and open source (the term didn't exist yet) stuff available. I could telnet into the box and run a pretty slick Unix work-alike shell.

On Aug 28, 2019, at 4:27 PM, Adam Thornton &lt;athornton(a)gmail.com&gt; wrote: I was an ardent OS/2 supporter for a long time. Sure, IBM's anemic marketing, and their close-to-outright-hostility to 3rd-party developers didn't help. But what killed it, really, was how damn good its 16-bit support was. It *was* a better DOS than DOS and a better Windows than 3.11fW. So no one wrote to the relatively tiny market of 32-bit OS/2. I fear that had Linux not made the leap, MS might well have won. It's largely the AOL-fuelled explosion of popularity of the Internet and Windows ignoring same until too late that opened the door enough for Linux to jam its foot in. Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not going to be a contender, I guess because it was about cool research features rather than running user-facing code. I kept waiting for a usable kernel to go with what Linux had already shown was a quite decent userspace, but eventually had better things to do with my life (like chase BeOS). It was like waiting for Perl 6--it missed its moment. Plan 9 and Amoeba were both really nifty. I never used Sprite. Neither one of them had much of a chance in the real world. Much like Unix itself, Linux's worse-is-better approach really worked. I have a hypothesis about Linux's ascendance too, which is a personal anecdote I am inflating to the status of hypothesis. As I recall, the *BSDs for 386 all assumed they owned the hard disk. Like, the whole thing. You couldn't, at least in 1992, create a multiboot system--or at least it was my strong impression you could not. I was an undergrad. I had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and Windows to write my papers (I don't know about you, but I wanted to write in my room, where I could have my references at hand and be reasonably undisturbed; sure Framemaker was a much better setup than Word For Windows 1.2 but having to use it in the computer lab made it a nonstarter for me). Papers, and, well, to play games. Sure, that too. Linux let me defragment my drive, non-destructively repartition it, and create a dual-boot system, so that I could both use the computer for school and screw around on Linux. I'm probably not the only person for whom this was a decisive factor. Adam > On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne &lt;cbbrowne(a)gmail.com&gt; wrote: >> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat &lt;krewat(a)kilonet.net&gt; wrote: > >> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni… >> >> Leaving licensing and copyright issues out of this mental exercise, what >> would we have now if it wasn't for Linux? Not what you'd WANT it to be, >> although that can add to the discussion, but what WOULD it be? >> >> I'm not asking as a proponent of Linux. If anything, I was dragged >> kicking and screaming into the current day and have begrudgingly ceded >> my server space to Linux. >> >> But if not for Linux, would it be BSD? A System V variant? Or (the >> horror) Windows NT? > > I can make a firm "dunno" sound :-) > > Some facts can come together to point away from a number of possibilities... > > - If you look at the number of hobbyist "Unix homages" that emerged at around that time, it's clear that there was a sizable community of interested folk willing to build their own thing, and that weren't interested in Windows NT. (Nay, one should put that more strongly... That had their minds set on something NOT from Microsoft.) So I think we can cross Windows NT off the list. > > - OS/2 should briefly come on the list. It was likable in many ways, if only IBM had actually supported it... But it suffers from something of the same problem as Windows NT; there were a lot of folk that were only slightly less despising of IBM at the time than of Microsoft. > > - Hurd was imagined to be the next thing... > > To borrow from my cookie file... > > "Of course 5 years from now that will be different, but 5 years from > now everyone will be running free GNU on their 200 MIPS, 64M > SPARCstation-5." -- Andrew Tanenbaum, 1992. > % > "You'll be rid of most of us when BSD-detox or GNU comes out, which > should happen in the next few months (yeah, right)." -- Richard Tobin, > 1992. [BSD did follow within a year] > % > "I am aware of the benefits of a micro kernel approach. However, the > fact remains that Linux is here, and GNU isn't --- and people have > been working on Hurd for a lot longer than Linus has been working on > Linux." -- Ted T'so, 1992. > > Ted has been on this thread, and should be amused (and slightly disturbed!) that his old statements are being held here and there, ready to trot out :-). > > In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was enough going on that there was plenty of room for them to have done so anyways. > > I'm not sure what to blame on whatever happened post-1992, though I'd put some on Microsoft Research having taken the wind out of Mach's sails by hiring off a bunch of the relevant folk. In order for Hurd to "make it," Mach has to "make it," too, and it looked like they were depending on CMU to be behind that. (I'm not sure I'm right about that; happy to hear a better story.) > > Anyway, Hurd *might* have been a "next thing," and I don't think the popularity of Linux was enough to have completely taken wind out of its sails, given that there's the dozens of "Unix homages" out there. > > - I'd like to imagine Plan 9 being an alternative, but it was "properly commercial" for a goodly long time (hence not amenable to attaching waves of hackers to it to add their favorite device drivers), and was never taken as a serious answer. Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that? mid or late '90s?) but only from afar. > > - FreeBSD is the single best answer I can throw up as a possibility, as it was the one actively targeting 80386 hardware. And that had the big risk of the AT&T lawsuit lurking over it, so had that gone in a different direction, then that is a branch sadly easily trimmed. > > If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ... something else, I'd think. I don't know which to suggest. > -- > When confronted by a difficult problem, solve it by reducing it to the > question, "How would the Lone Ranger handle this?"

It probably was the partition/slice confusion that, well, confused me, then.  My experience, such as it was, was from the DOS world.

Although the period I am thinking of was way pre-slackware.  You had a boot floppy and a root floppy and that was about it, I think.  I think the kernel had MFM/RLL disk drivers for an ISA bus interface?  I remember that I could boot the thing on the MCA machines in the lab but not actually install it (even had I been allowed to), and I think installation was pretty much fdisk/mkfs, extract the tarball...I don't remember how you installed the bootloader...which I guess was already LILO at that point? Probably just dding the bootsector to the first physical sector of the disk?  Version 0.08 or so, maybe?

It was quite a while ago, and I was drunk for most of college, so....memory is imprecise at best. On Wed, Aug 28, 2019 at 3:28 PM Clem cole &lt;clemc(a)ccc.com <mailto:clemc@ccc.com>> wrote: Not true 386BSD used fdisk.  It shared the disk just fine.  In fact I liked the way it sliced the disk much better than Slackware in those days. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. On Aug 28, 2019, at 4:27 PM, Adam Thornton &lt;athornton(a)gmail.com <mailto:athornton@gmail.com>> wrote: > I was an ardent OS/2 supporter for a long time. Sure, IBM's > anemic marketing, and their close-to-outright-hostility to > 3rd-party developers didn't help.  But what killed it, really, > was how damn good its 16-bit support was.  It *was* a better DOS > than DOS and a better Windows than 3.11fW.  So no one wrote to > the relatively tiny market of 32-bit OS/2. > > I fear that had Linux not made the leap, MS might well have won.  > It's largely the AOL-fuelled explosion of popularity of the > Internet and Windows ignoring same until too late that opened the > door enough for Linux to jam its foot in. > > Hurd was, by the time of the '386 Unix Wars and early Linux, > clearly not going to be a contender, I guess because it was about > cool research features rather than running user-facing code.  I > kept waiting for a usable kernel to go with what Linux had > already shown was a quite decent userspace, but eventually had > better things to do with my life (like chase BeOS).  It was like > waiting for Perl 6--it missed its moment. > > Plan 9 and Amoeba were both really nifty.    I never used > Sprite.  Neither one of them had much of a chance in the real > world.  Much like Unix itself, Linux's worse-is-better approach > really worked. > > I have a hypothesis about Linux's ascendance too, which is a > personal anecdote I am inflating to the status of hypothesis.  As > I recall, the *BSDs for 386 all assumed they owned the hard > disk.  Like, the whole thing.  You couldn't, at least in 1992, > create a multiboot system--or at least it was my strong > impression you could not.  I was an undergrad.  I had one '386 at > my disposal, with one hard disk, and, hey, I needed DOS and > Windows to write my papers (I don't know about you, but I wanted > to write in my room, where I could have my references at hand and > be reasonably undisturbed; sure Framemaker was a much better > setup than Word For Windows 1.2 but having to use it in the > computer lab made it a nonstarter for me).  Papers, and, well, to > play games.  Sure, that too. > > Linux let me defragment my drive, non-destructively repartition > it, and create a dual-boot system, so that I could both use the > computer for school and screw around on Linux.  I'm probably not > the only person for whom this was a decisive factor. > > Adam > > On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne > &lt;cbbrowne(a)gmail.com <mailto:cbbrowne@gmail.com>> wrote: > > On Mon, 26 Aug 2019 at 19:14, Arthur Krewat > &lt;krewat(a)kilonet.net <mailto:krewat@kilonet.net>> wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni… > > Leaving licensing and copyright issues out of this mental > exercise, what > would we have now if it wasn't for Linux? Not what you'd > WANT it to be, > although that can add to the discussion, but what WOULD > it be? > > I'm not asking as a proponent of Linux. If anything, I > was dragged > kicking and screaming into the current day and have > begrudgingly ceded > my server space to Linux. > > But if not for Linux, would it be BSD? A System V > variant? Or (the > horror) Windows NT? > > > I can make a firm "dunno" sound :-) > > Some facts can come together to point away from a number of > possibilities... > > - If you look at the number of hobbyist "Unix homages" that > emerged at around that time, it's clear that there was a > sizable community of interested folk willing to build their > own thing, and that weren't interested in Windows NT.  (Nay, > one should put that more strongly...  That had their minds > set on something NOT from Microsoft.)  So I think we can > cross Windows NT off the list. > > - OS/2 should briefly come on the list.  It was likable in > many ways, if only IBM had actually supported it...  But it > suffers from something of the same problem as Windows NT; > there were a lot of folk that were only slightly less > despising of IBM at the time than of Microsoft. > > - Hurd was imagined to be the next thing... > > To borrow from my cookie file... > > "Of course 5  years from now that will be different,  but 5 > years from > now  everyone  will  be  running  free  GNU on  their  200 >  MIPS,  64M > SPARCstation-5."  -- Andrew Tanenbaum, 1992. > % > "You'll be  rid of most of us  when BSD-detox or GNU  comes > out, which > should happen in the next few months (yeah, right)." -- > Richard Tobin, > 1992. [BSD did follow within a year] > % > "I am aware of the benefits  of a micro kernel approach.  > However, the > fact remains  that Linux is  here, and GNU  isn't --- and >  people have > been working on Hurd for a lot longer than Linus has been > working on > Linux." -- Ted T'so, 1992. > > Ted has been on this thread, and should be amused (and > slightly disturbed!) that his old statements are being held > here and there, ready to trot out :-). > > In the absence of Linux, perhaps hackers would have flocked > to Hurd, but there was enough going on that there was plenty > of room for them to have done so anyways. > > I'm not sure what to blame on whatever happened post-1992, > though I'd put some on Microsoft Research having taken the > wind out of Mach's sails by hiring off a bunch of the > relevant folk.  In order for Hurd to "make it," Mach has to > "make it," too, and it looked like they were depending on CMU > to be behind that. (I'm not sure I'm right about that; happy > to hear a better story.) > > Anyway, Hurd *might* have been a "next thing," and I don't > think the popularity of Linux was enough to have completely > taken wind out of its sails, given that there's the dozens of > "Unix homages" out there. > > - I'd like to imagine Plan 9 being an alternative, but it was > "properly commercial" for a goodly long time (hence not > amenable to attaching waves of hackers to it to add their > favorite device drivers), and was never taken as a serious > answer.  Many of us had admired it from afar via the Dr Dobbs > Journal issue (when was that?  mid or late '90s?) but only > from afar. > > - FreeBSD is the single best answer I can throw up as a > possibility, as it was the one actively targeting 80386 > hardware.  And that had the big risk of the AT&T lawsuit > lurking over it, so had that gone in a different direction, > then that is a branch sadly easily trimmed. > > If we lop both Linux and FreeBSD off the list of > possibilities, I don't imagine Windows NT or OS/2 bubble to > the top, instead, a critical mass would have stood behind ... > something else, I'd think.  I don't know which to suggest. > -- > When confronted by a difficult problem, solve it by reducing > it to the > question, "How would the Lone Ranger handle this?" >

On 8/28/2019 6:48 PM, Adam Thornton wrote:

Sounds like SLS -- Soft Landing System -- which later was pretty much replaced with Slackware. I used the early MCA stuff on PS/2's at IBM for a while. Most of the PS/2 stuff we had was SCSI. The boot loader was lilo. It could go in the partition space or disk mbr. See:https://www.ibm.com/developerworks/library/l-bootload/index.html

I fear that had Linux not made the leap, MS might well have won. It's largely the AOL-fuelled explosion of popularity of the Internet and Windows ignoring same until too late that opened the door enough for Linux to jam its foot in.

The GPL makes it harder to monetize Linux --- although, as we've seen, certainly not impossible --- and if you take a look at the most of the senior technical people at Linux, none of us have made off as well as, say, Bill Joy. I'm still a working stiff, and don't have enough to retire. (That's OK; I'm perfectly happy being part of the 99%. :-)

: Arthur Krewat &lt;krewat(a)kilonet.net&gt; Except for the Ferrari (which would be around $160K in today's US dollars), the other three are pretty much bargain-basement sports cars ;)

|Today however not in the 80ths. Inn those days all 4 cars were Richie \ |Rich cars. And only the Mazda had that wonderful smooth engine which replaces pounding pistons with nice chuckling triangles.

On Wed, Aug 28, 2019 at 04:07:39PM -0400, Christopher Browne wrote: That's "Ts'o" :-), and that quote wasn't my arguing that Hurd would be the next thing. It was people had been working on the Hurd for *years* (starting 1984) and it still wasn't real. If it wasn't going to be real after eight years, another eighty probably wouldn't have helped.

And a lot of this was because was because RMS was hard to work with, and he was a purist. Pretty much very *definition* of the perfect should always be the enemy of the "good enough". In fact, at one point Thomas Bushnell, one of the senior Hurd developers pushed to have the Hurd switch to using BSD 4.4-Lite, and Stallman refused[1]. “RMS was a very strong believer, wrongly, I think, in a very greedy algorithm approach to code reuse issues,” Thomas Bushnell later remembered. “My first choice was to take the BSD 4.4-Lite release and make a kernel. I knew the code, I knew how to do it. It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today. RMS wanted to work

were interested, but some seem to have been deliberately dragging their feet: and the reason now seems to be that they had the goal of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI.” As Bushnell describes it, Stallman came to the conclusion that “Mach is a working kernel. 4.4-Lite is only partial. We will go with Mach.” [1] https://web.archive.org/web/20121228225905/http://www.linuxuser.co.uk/featu…

That's probably one of the other things that may have hampered BSD. The BSD license made it easier (or at least made easier business models) for monetizing BSD, and some of the most talented people went off to make a buck off of BSD. BSDI, Sun, NetApp, Wasabi Systems, etc. Nothing wrong with that of course, and if people like Bill Joy were able to make bank based on BSD, more power to them. But it probably removed from the leadership pool people who might have had better leadership, and technical architect skills who might have led one of the *BSD's to greater success. The GPL makes it harder to monetize Linux --- although, as we've seen, certainly not impossible --- and if you take a look at the most of the senior technical people at Linux, none of us have made off as well as, say, Bill Joy. I'm still a working stiff, and don't have enough to retire. (That's OK; I'm perfectly happy being part of the 99%. :-) Given who called the shots (and it wasn't the key people actually doing most of the technical work, such as Bushnell) I actually think it's not very likely Hurd could have succeeded. RMS actually tried to recruit me to work on the Hurd as well, and I refused, because of project leadership concerns. (Again, feel free to hate on Linus's management style, but there were far worse ones in the open source OS world at the time.) - Ted