https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel 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 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.
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --] On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat <krewat@kilonet.net> wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > 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. > > > [-- Attachment #2: Type: text/html, Size: 2129 bytes --]
On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote:
> On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat <krewat@kilonet.net> wrote:
>
> >
> > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
> >
> > 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.
I've always wondered what would have happened if Sun had open sourced
SunOS, I think it stood a pretty good chance of winning. Shoulda,
woulda, coulda.
[-- Attachment #1: Type: text/plain, Size: 2401 bytes --] On 8/26/2019 7:27 PM, Warner Losh wrote: > > > On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat <krewat@kilonet.net > <mailto:krewat@kilonet.net>> wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > 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. > > I ran both FreeBSD (up through at least 4.11 (and have the Tshirt) and NetBSD back in the 0.8 0.9 time frame. My final -- (I used to move between them based on stability and driver support) -- move to Linux was caused by a lack of drivers for the Lenovo Workstation that used the Marvell 88SE63XX which with 5 SAS/SATA drives on it and 3 available on the Intel SATA controller would've been a great in-house server. I really preferred the FreeBSD stability and docs back in the early 1990's -- but by 2000 my jobs were all going Linux (Red Hat Sysadmin mostly) and I figured the work was moving to supported RHEL. One of the things that often made me migrate was the support (in the early days) of all the weird interfaced cdrom drives like the Panasonic and other pre-ATAPI stuff. I'm going to revisit the ZFS on Linux stuff when Ubuntu puts it in their installer. That will finally get me what I want on the D20. Bill [-- Attachment #2: Type: text/html, Size: 4677 bytes --]
On 8/26/2019 7:56 PM, William Pechter wrote:
> ZFS
Here, here!
On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote:
> On 8/26/2019 7:56 PM, William Pechter wrote:
> >ZFS
>
> Here, here!
I really don't understand the love for ZFS. I hired Bonwick and I
hired Moore, I had high expectations but they were all dashed when I
realized ZFS doesn't use the page cache. That's so crazy busted I lost
all interest in ZFS. ZFS took us back to HP-UX mmap semantics.
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --] On Mon, Aug 26, 2019 at 7:28 PM Warner Losh <imp@bsdimp.com> wrote: > > 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. > 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-dans-l-histoire-de-l-informatique-ii-ii-988170.kjsp?RH=cdhte ], .... *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 [-- Attachment #2: Type: text/html, Size: 4687 bytes --]
[-- Attachment #1: Type: text/plain, Size: 685 bytes --] 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 On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote: > > On 8/26/2019 7:56 PM, William Pechter wrote: > > >ZFS > > > > Here, here! > > I really don't understand the love for ZFS. I hired Bonwick and I > hired Moore, I had high expectations but they were all dashed when I > realized ZFS doesn't use the page cache. That's so crazy busted I lost > all interest in ZFS. ZFS took us back to HP-UX mmap semantics. > [-- Attachment #2: Type: text/html, Size: 1055 bytes --]
On 8/26/2019 8:30 PM, Larry McVoy wrote:
>
> I really don't understand the love for ZFS. I hired Bonwick and I
> hired Moore, I had high expectations but they were all dashed when I
> realized ZFS doesn't use the page cache. That's so crazy busted I lost
> all interest in ZFS. ZFS took us back to HP-UX mmap semantics.
>
At the risk of going off-topic:
From a system-administration standpoint, and data-integrity standpoint,
ZFS was a huge step forward. In my humble opinion ;)
Besides the obvious (to me) benefits of adding mount points, adjusting
volume sizes, and all the other things that ZFS does, I have yet to find
any mainstream filesystem (if you can call ZFS "just" a filesystem) that
guarantees data integrity. I have an office server, that contains a lot
of source code and archived data that I depend on religiously. I do
copious backups to LTO tapes as well as an off-site Amazon EC2 instance.
Within the recent past few years, I had an issue with a Dell MD Raid
array where ZFS was complaining about checksum errors on a certain disk.
Data was being corrupted on the fly. It seems that the writes were being
corrupted, not reads. Thankfully, it was on a RAIDZ2 volume, where it
could correct the corruption. The corruption in question was on files
that are dated back to the early 90's.
Stopping bit-rot in it's tracks, ZFS has done me well.
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?
art k.
[-- Attachment #1: Type: text/plain, Size: 849 bytes --] On Mon, Aug 26, 2019 at 8:59 PM Rob Pike <robpike@gmail.com> wrote: > 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 > Rob - Fair enough/excellent point/I agree from a pure technology stand point, but the problem was anything from Research after Seventh Edition was the limited availability so few people out side really used it (and I'll have include Plan 9 in that family also - although you guys did get it out more widely than 8th or 10th UNIX -- funny by that point, I had read about it and seen the manuals in a book store in the UK, but I did not get the mess with the actual 10th edition code until a few years after I had a Plan 9 boot floppy that Dave gave me running in a laptop). Clem [-- Attachment #2: Type: text/html, Size: 1782 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2571 bytes --] On Mon, Aug 26, 2019, 7:14 PM Arthur Krewat <krewat@kilonet.net> wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > 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 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 :) > This is an interesting question, though of course impossible to actually answer in a meaningful way, as hypotheticals always are. But assuming one could hold all else constant and just erase Linux from the picture, it seems pretty obvious that some kind of BSD variant would have been "it." I think a more interesting question, however, might be: had Linux not happened, would that have opened the space for serious consideration of alternative system architectures, either along Unix derivative lines, or completely different? For example, perhaps something like plan 9 would have had greater penetration into the market. I saw a talk a couple of months ago that attributed the diversity of systems in the 60s and 70s to the idea that people were trying so many different things because no one knew _how_ to build systems. That may be at least partially true, but I was wondering thinking about that very thing this morning and realized that we're certainly swirling around the toilet bowl converging on some central set of things we think work pretty well (files! processes! threads!). But as time marches on and we see the environment changing around us, we don't often go back and revisit these sorts of fundamental assumptions. More's the shame, I'm afraid. One wonders what's next. People now talk about Linux with the sort of reverent tones they once discussed Windows and before that the mainframe. Too big to fail, the Last System, etc. But there are cracks there: Fuchsia is a different architecture, because that Unix model isn't going to accommodate all contemporary use cases: the security model seems to be a big driver here. Will they succeed? It'll be at least interesting to watch and see. - Dan C. [-- Attachment #2: Type: text/html, Size: 3534 bytes --]
Hello!
having run both FreeBSD and NetBSD and several different examples of
Linux, I found that FreeBSD was a bit flaky at the time. NetBSD was
good, but for my efforts, I ended up with Slackware, I started with
his three something examples, and now I have 11 running.
I have tried under SIMH most of the examples that live on the FTP site
which will boot. But I still have strong support for practically
everything SUN wrote.
-----
Gregg C Levine gregg.drwho8@gmail.com
"This signature fought the Time Wars, time and again."
On Mon, Aug 26, 2019 at 8:49 PM Clem Cole <clemc@ccc.com> wrote:
>
>
>
> On Mon, Aug 26, 2019 at 7:28 PM Warner Losh <imp@bsdimp.com> wrote:
>>
>>
>> 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.
>
>
>
> 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-dans-l-histoire-de-l-informatique-ii-ii-988170.kjsp?RH=cdhte],
> .... 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
>
[-- Attachment #1: Type: text/plain, Size: 1158 bytes --] On Mon, Aug 26, 2019, 9:00 PM Arthur Krewat wrote: >[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? I don't mean to put words in Larry's mouth, but I think he meant that ZFS bypasses the OS page cache, so that file IO and mmap use a different buffering scheme that is not mutually consistent. So a process could mmap() a file, write to it via a pointer indirection, and then invoke read() at a relevant offset and (perhaps) not see the earlier write reflected; or vice versa. It's not that mmap is a priori bad, but rather that ZFS has this unfortunate corner case related to mmap. - Dan C. [-- Attachment #2: Type: text/html, Size: 1619 bytes --]
On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote:
>
> 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.
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.
- Ted
On Mon, Aug 26, 2019 at 10:16:58PM -0400, Theodore Y. Ts'o wrote:
> On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote:
> >
> > 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.
>
> 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.
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. Sorry,
but that's my take. Maybe the world is as shitty as they say it is but
my world wasn't that great, you just roll up your sleeves and make a
difference. I dunno, it does seem different, maybe it was easy for
me and it is hard for them but I don't like the complaining.
Linus, in my opinion, is a great programmer (all you have to do is read
his rants about obscure stuff and it is clear he knows the details of a
ton of stuff), a great architect (I could be pushed back a little on
this one but he is good), and a great manager. He inspires other people
to do well, he pushes for a good code base, he hates shitty code. He
is a leader, you can argue about his faults but he leads. And I have
*never* seen all those skill sets in one person. I've said that at
least 20 years ago and it is true today.
The BSD crowd lacked that sort of leader. So
{386,Net,Open,Free,DragonFly}BSD all have their own crowd but they are
tiny crowds.
I say this with dismay, I'm a SunOS 4.x guy, that's the bugfixed BSD.
I loved BSD Unix, it was the best and it had the chance to be the
future but for whatever reason the "leaders" in BSD didn't have an
actual leader. Not one of them. Not 1/100th of the leader that
Linus is.
So Linux won. I'm not that happy about it, I could imagine a world
where BSD won and I think I'd be happier in that world but it didn't
happen.
On Mon, Aug 26, 2019 at 09:26:27PM -0400, Dan Cross wrote:
> On Mon, Aug 26, 2019, 9:00 PM Arthur Krewat wrote:
> >[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?
>
>
> I don't mean to put words in Larry's mouth, but I think he meant that ZFS
> bypasses the OS page cache, so that file IO and mmap use a different
> buffering scheme that is not mutually consistent.
Dan is right. At Sun, when Joe Moran did the 4.x VM system, he put into
place the vision that Bill Joy had. Which was that the page cache is
*the* cache. There is nothing else. We spent a bunch of time killing
the buffer cache because you couldn't mmap the buffer cache, you could
mmap the page cache.
It's hard to describe how right that was but it was right. You could
have as many processes as you wanted mmap-ing the same data and there
was a single version of the data.
What ZFS did was manage the data on their own. So if you mmap-ed a ZFS
file it had to bcopy the data into the page cache and now it is right
back to two copies of the data and you have to manage consistency.
I would have been fine if all page sized blocks were in the page cache
and ZFS managed the less than page sized blocks. But they punted on
the page cache entirely.
My mind is blown that that was allowed to ship. The Sun I worked at,
if I had proposed that design, I would have been kicked out of the
kernel group.
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: > 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 > > > On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy <lm@mcvoy.com> wrote: > > > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote: > > > On 8/26/2019 7:56 PM, William Pechter wrote: > > > >ZFS > > > > > > Here, here! > > > > I really don't understand the love for ZFS. I hired Bonwick and I > > hired Moore, I had high expectations but they were all dashed when I > > realized ZFS doesn't use the page cache. That's so crazy busted I lost > > all interest in ZFS. ZFS took us back to HP-UX mmap semantics. > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
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 ;)
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --] > On Aug 26, 2019, at 7:39 PM, Larry McVoy <lm@mcvoy.com> 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 [-- Attachment #2: Type: text/html, Size: 4706 bytes --]
Hello!
Oh dear.
At the very first Linux conference in NYC, I caught up with the NetBSD
group there, and suggested something-of-a-sort. Let's just say that
the person there is probably still active on their lists, and
sometimes comes across as someone even Larry wouldn't like very much.
I tried again after he stopped behaving like someone from a movie we
all know, and I asked again. His response was similar. I put it down
to extreme jet lag.
Adam if your interested please ask off list.
-----
Gregg C Levine gregg.drwho8@gmail.com
"This signature fought the Time Wars, time and again."
On Tue, Aug 27, 2019 at 1:55 AM Adam Thornton <athornton@gmail.com> wrote:
>
>
>
> On Aug 26, 2019, at 7:39 PM, Larry McVoy <lm@mcvoy.com> 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
I'd have liked to see Plan 9 take over the world. I think we'd all be
in a nicer place if it had.
My $.02,
Arnold
Rob Pike <robpike@gmail.com> wrote:
> 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
>
>
> On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy <lm@mcvoy.com> wrote:
>
> > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote:
> > > On 8/26/2019 7:56 PM, William Pechter wrote:
> > > >ZFS
> > >
> > > Here, here!
> >
> > I really don't understand the love for ZFS. I hired Bonwick and I
> > hired Moore, I had high expectations but they were all dashed when I
> > realized ZFS doesn't use the page cache. That's so crazy busted I lost
> > all interest in ZFS. ZFS took us back to HP-UX mmap semantics.
> >
[-- Attachment #1: Type: text/plain, Size: 2590 bytes --] V8 was the first of a series of refinements that unified things nicely, allowing programs to interact more smoothly. Nothing too dramatic, really: things like a shell that could export its environment, including functions; tweaks to how $PATH worked so we could have binaries with names like n/m1 n/m2 etc. to connect to machines m1 and m2; a push for output from programs that worked as input to the same programs (a huge deal for the shell); and so on. Lots of cleanups (db really worked, and worked well; stuff like that). Not to mention clean networking and graphics APIs that showed how easy it was to incorporate them into Unix. What is a socket for, anyway? Why do you need them when you have file descriptors? (Rhetorical question, because the answer is, you don't. But the earliest sockets didn't even implement read and write!) And so on. But we did Plan 9 after v10, so it's clear we didn't think it was perfect, yet. -rob On Tue, Aug 27, 2019 at 12:53 PM Larry McVoy <lm@mcvoy.com> wrote: > 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: > > 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 > > > > > > On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy <lm@mcvoy.com> wrote: > > > > > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote: > > > > On 8/26/2019 7:56 PM, William Pechter wrote: > > > > >ZFS > > > > > > > > Here, here! > > > > > > I really don't understand the love for ZFS. I hired Bonwick and I > > > hired Moore, I had high expectations but they were all dashed when I > > > realized ZFS doesn't use the page cache. That's so crazy busted I lost > > > all interest in ZFS. ZFS took us back to HP-UX mmap semantics. > > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > [-- Attachment #2: Type: text/html, Size: 3499 bytes --]
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
Did anyone try to get v10 running in simh yet? It's been public for a
while now and while we have two blit emulators already I haven't seen
v10 alive yet. I have to admit I haven't tried to get it running myself either.
aap
On 27/08/19, Rob Pike wrote:
> 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.
[-- Attachment #1: Type: text/plain, Size: 791 bytes --] On Tue, 27 Aug 2019 at 12:12, Angelo Papenhoff <aap@papnet.eu> wrote: > Did anyone try to get v10 running in simh yet? It's been public for a > while now and while we have two blit emulators already I haven't seen > v10 alive yet. I have to admit I haven't tried to get it running myself > either. > After a brief look at the boot and config sources it appears as though there is support for the MicroVAX II which SIMH supports and I have used. Is there an environment which is preferred for building the V10 source tree? 4.3BSD? V8? Something else? -Henry On 27/08/19, Rob Pike wrote: > > 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. > [-- Attachment #2: Type: text/html, Size: 1284 bytes --]
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 <lm@mcvoy.com> 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
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 <lm@mcvoy.com> 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
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 <lm@mcvoy.com> 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 <lm@mcvoy.com> 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
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 <lm@mcvoy.com> 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 <lm@mcvoy.com> 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
[-- Attachment #1: Type: text/plain, Size: 5961 bytes --] I had a similar conversation btw. I liked what Dennis did to clean up the tty handler but I agree as a networking interface it was wretched which is what system v did. At stellar we put in the bbn (walsh2) stack and spliced back in sockets so the bsd code still worked. That said the idea of trying to keep the everything is a file semantic was good and streams were closer. The problem sockets is they really were not quite The same. What I liked about plan 9 was breaking the control interface out so the file stuff stayed sane. But that was a bridge to far for a traditional Unix. On Tue, Aug 27, 2019 at 7:00 PM Larry McVoy <lm@mcvoy.com> 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 <lm@mcvoy.com> 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 <lm@mcvoy.com> 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 > -- Sent from a handheld expect more typos than usual [-- Attachment #2: Type: text/html, Size: 8006 bytes --]
On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy <lm@mcvoy.com> wrote: Larry McVoy writes: > 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. Plan9 does a decent enough job. cpu% ls /net/tcp /net/tcp/0 /net/tcp/1 /net/tcp/2 /net/tcp/clone /net/tcp/stats cpu% ls /net/tcp/1 /net/tcp/1/ctl /net/tcp/1/data /net/tcp/1/err /net/tcp/1/listen /net/tcp/1/local /net/tcp/1/remote /net/tcp/1/status cpu% cd /net/tcp/1 cpu% cat local remote 192.168.1.103!17010 192.168.1.11!52027 See http://doc.cat-v.org/plan_9/4th_edition/papers/net/ Replacing ioctls with writing ascii commands to ctl files was a significant improvement. For one thing you can do all this from a shell script. plan9 would've been a big improvement over *BSD or Linux. But I think a conceptual merge was needed between some sane version of Unix and plan9 so as to not throw out all the dusty decks.
On Tue, Aug 27, 2019 at 04:16:18PM -0700, Bakul Shah wrote: > On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy <lm@mcvoy.com> wrote: > Larry McVoy writes: > > 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. > > Plan9 does a decent enough job. > > cpu% ls /net/tcp > /net/tcp/0 > /net/tcp/1 > /net/tcp/2 > /net/tcp/clone > /net/tcp/stats > > cpu% ls /net/tcp/1 > /net/tcp/1/ctl > /net/tcp/1/data > /net/tcp/1/err > /net/tcp/1/listen > /net/tcp/1/local > /net/tcp/1/remote > /net/tcp/1/status 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. > plan9 would've been a big improvement over *BSD or Linux. But > I think a conceptual merge was needed between some sane > version of Unix and plan9 so as to not throw out all the dusty > decks. 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.
At the time we are talking, almost all people were using serial line
protocols, of some form, for point-to-point links. Ethernet was "new"
and I think at one level, being a good (binary) tty/serial discipline
was workable. Stacking things was possible was it not? And, the way I
understand it, The code avoided data copying so was very very
efficient across protocol stacks.
I think it was capable of being improved. Sockets is now defined by
standards. Its impossible to make it do things without huge cost.
We're comparing now, with then.. always dangerous.
-G
On Wed, Aug 28, 2019 at 9:10 AM Clem Cole <clemc@ccc.com> wrote:
>
> I had a similar conversation btw. I liked what Dennis did to clean up the tty handler but I agree as a networking interface it was wretched which is what system v did. At stellar we put in the bbn (walsh2) stack and spliced back in sockets so the bsd code still worked.
> That said the idea of trying to keep the everything is a file semantic was good and streams were closer. The problem sockets is they really were not quite The same.
>
> What I liked about plan 9 was breaking the control interface out so the file stuff stayed sane. But that was a bridge to far for a traditional Unix.
>
>
> On Tue, Aug 27, 2019 at 7:00 PM Larry McVoy <lm@mcvoy.com> 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 <lm@mcvoy.com> 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 <lm@mcvoy.com> 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
>
> --
> Sent from a handheld expect more typos than usual
On Tue, 27 Aug 2019 16:33:38 -0700 Larry McVoy <lm@mcvoy.com> wrote: Larry McVoy writes: > On Tue, Aug 27, 2019 at 04:16:18PM -0700, Bakul Shah wrote: > > On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy <lm@mcvoy.com> wrote: > > Larry McVoy writes: > > > 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. > > > > Plan9 does a decent enough job. > > > > cpu% ls /net/tcp > > /net/tcp/0 > > /net/tcp/1 > > /net/tcp/2 > > /net/tcp/clone > > /net/tcp/stats > > > > cpu% ls /net/tcp/1 > > /net/tcp/1/ctl > > /net/tcp/1/data > > /net/tcp/1/err > > /net/tcp/1/listen > > /net/tcp/1/local > > /net/tcp/1/remote > > /net/tcp/1/status > > I dunno. I can't look at that and know what it means. So it means I have Hence the link to Presotto and Winterbottom's paper. > 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. It's a simper model. It is no big deal. I was intimately familiar with sockets and the BSD networking stack (worked in a router startup from the beginning where we rejiggered the FreeBSD network stack to support N forwarding tables, additional protocols, interface types etc. etc.). > > plan9 would've been a big improvement over *BSD or Linux. But > > I think a conceptual merge was needed between some sane > > version of Unix and plan9 so as to not throw out all the dusty > > decks. > > 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. I believe not having to be compatible with Unix meant plan9 could evolve unimpeded. But IMHO it was not so far out that a merge would have been impossible. plan9 had "ape" (ansi/posix environment) for compiling posix compatible programs but that didn't go far enough. The result might've been a worse plan9 but a better Unix. The last version I used SunOS3.5 on a 4MB Sun 3/50. It was very nice in its day. Once I got a 386 (or was it 486) with 16MB of memory & BSD, the Sun machine saw less and less use.
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? jeez... :) art k.
On Tue, Aug 27, 2019 at 09:21:43PM -0400, Arthur Krewat wrote: > 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); ???" So that part is fine. > And, horror of all horrors, I need to deal with little/big endian things? > ntohs(), htons(), et al? That part is reality. You can send ascii and then pay the price for parsing that or you can send binary. These days, we have CPU cycles to burn so the ascii answer seems fine. It is, mostly, it's not when it is tons of small messages that need to be processed at millions or billions/sec. In the past, CPU cycles were not a given so lots of stuff was designed to not be parsed.
[-- Attachment #1: Type: text/plain, Size: 5567 bytes --] 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 <lm@mcvoy.com> 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 <lm@mcvoy.com> 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 <lm@mcvoy.com> 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 > [-- Attachment #2: Type: text/html, Size: 7488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 6218 bytes --] There are many things to dislike about sockets, but one of them - irrelevant now, perhaps, but hugely troublesome at the time - was the way they embedded the specific and peculiar behavior of Ethernet, such as accepting a connection before you know if it's authorized - into the networking interface. No other networking hardware worked like Ethernet at either the electrical or the software level, and yet here we are. I grump, I grump. -rob On Wed, Aug 28, 2019 at 1:22 PM Rob Pike <robpike@gmail.com> wrote: > 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 <lm@mcvoy.com> 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 <lm@mcvoy.com> 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 <lm@mcvoy.com> 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 >> > [-- Attachment #2: Type: text/html, Size: 8352 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3021 bytes --] I’m a bit taken aback by the trees (streams/sockets/file systems/paging and difficult people) of this discussion. The forest view seems clear: if not for Linux, Microsoft would have been even more dominant. If not for Microsoft mis-steps (Cairo, ME, Vista, …), Windows dominance would have been even stronger. If not for Steve Jobs return, Apple really would have cratered. Who besides Apple and Linux (including Android) have given Microsoft meaningful competition? The last couple of months or so I’ve been figuring out how to revive and sustain some early 90s PC hardware (not just JAWS but a also a slightly older ISA only i486DX2-50 machine). I’ve been making the machines multi boot a variety of environments: Windows 3.11 (with Mosaic and Netscape), Windows 95, NT 3.51 with the “new shell” (Win 95 Explorer), NEXTSTEP 3.3, Dell SVR4 2.2.1, and Red Had 5.2/6.2/7. For a “Unix person” my perspective may be unusual, but Win95/NT with new shell/Dell SVR4/Linux all seem preferable to my memory of the Unix systems I casually used when I was using those four predominantly. I helped lead AIX from 1982 to ’89 and Dell UNIX from ’89 to ’93. In ’93 I stepped away from Unix to work on Windows 95-based videoconferencing. From ’93 to ’96 I did very little with Unix. Starting in 1992, a friend endeavored to interest me in Linux, but I declined. Then in ’96 I joined a startup that was getting funding based on a prototype app based on PERL/mSQL/Apache/Linux. My task was to make the prototype a real product. My Linux advocate friend said to settle on either Slackware or Red Hat, favoring RPM, so I’ve used Red Hat/Fedora since then. But I also use Windows 10 and am composing this in TextEdit on macOS. I’ve tried the various BSD forks, other Linux distributions, OS/2, Palm OS, etc. but none of those have made me want to keep using them. Charlie > On Aug 26, 2019, at 6:13 PM, Arthur Krewat <krewat@kilonet.net> wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > 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 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. > -- voice: +1.512.784.7526 e-mail: sauer@technologists.com <mailto:sauer@technologists.com> fax: +1.512.346.5240 web: https://technologists.com/sauer/ <http://technologists.com/sauer/> Facebook/Google/Skype/Twitter: CharlesHSauer [-- Attachment #2: Type: text/html, Size: 6662 bytes --]
I could be wrong but that's my memory. What he told me was streams was for line disciplines for tty drivers. That's what I know but you were there, I was not. I'm pretty confused because what Dennis said to me was that he did not think streams would work for networking, he thought they made sense for a stream but not for a networking connection because that had multiple connections coming up through a stream. I'm happy to be wrong but can you talk more about what he was thinking? There is no way that I'm saying you are wrong, you are you, I just want to learn. If there is a way that streams made sense for networking I'd like to see that. My experience with STREAMS is that they sucked really hard for networking. My guess is I need to go learn about mpx, I don't know that. On Wed, Aug 28, 2019 at 01:22:33PM +1000, Rob Pike wrote: > 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 <lm@mcvoy.com> 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 <lm@mcvoy.com> 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 <lm@mcvoy.com> 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 > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
[-- Attachment #1: Type: text/plain, Size: 1328 bytes --] I don’t recall their being detailed installation instructions like 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…. I guess it’s worth trying on whatever should be the parallel BSD system if it’s like v8/v9 which needed a BSD machine to bootstrap. From: Henry Bent Sent: Wednesday, August 28, 2019 12:28 AM To: Angelo Papenhoff Cc: TUHS main list Subject: Re: [TUHS] Running v10 On Tue, 27 Aug 2019 at 12:12, Angelo Papenhoff <aap@papnet.eu> wrote: Did anyone try to get v10 running in simh yet? It's been public for a while now and while we have two blit emulators already I haven't seen v10 alive yet. I have to admit I haven't tried to get it running myself either. After a brief look at the boot and config sources it appears as though there is support for the MicroVAX II which SIMH supports and I have used. Is there an environment which is preferred for building the V10 source tree? 4.3BSD? V8? Something else? -Henry On 27/08/19, Rob Pike wrote: > 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. [-- Attachment #2: Type: text/html, Size: 3461 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1657 bytes --] Maybe that plan B of GNU using the 4.4BSD lite kernel would have gained traction and you would have seen a GNU BSD vs NetBSD thing. I can’t see it though gaining the kind of traction Linux got as it was all so cloistered. Much like how GNU Mach never caught on or moved despite having a NetBSD port (Lites) to it. The killer feature should have been SMP which was available early on in Mach, although it seems that the MPS 1.0 stuff didn’t work well enough or by the time 1.1 caught on it just wasn’t good enough. I think the development model of Linux is what really drove it, just like how EGCS eclipsed GCC. The other crazy thing that hits me is that no Linux means no Caldera which means no Caldera 32v license being set free... From: Arthur Krewat Sent: Tuesday, August 27, 2019 7:14 AM To: TUHS main list Subject: [TUHS] If not Linux, then what? https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel 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 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. [-- Attachment #2: Type: text/html, Size: 4027 bytes --]
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?
Wesley Parish
On 8/28/19, George Michaelson <ggm@algebras.org> 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
>
< snip >
[-- Attachment #1: Type: text/plain, Size: 623 bytes --] On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong@gmail.com> wrote: >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? 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 963 bytes --]
On 28/08/19, Jason Stevens wrote:
> I don’t recall their being detailed installation instructions like 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….
>
> I guess it’s worth trying on whatever should be the parallel BSD system 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.
aap
[-- Attachment #1: Type: text/plain, Size: 1792 bytes --] Interesting question, the alternative OS would have had to have had a good leader and I am sure maybe RMS would have created a kernel after some time. Maybe somebody would have taken 386BSD/FreeBSD/NetBSD and made something completely different. I think another question would be, if Linux was never invented, what technologies would never have happened. For instance, a bunch of animation movies where made with Linux farms, Planes use Linux within their inbuilt entertainment systems, the list goes on (I think NASA uses linux on their ISS). How many people would be interested in technology/IT sector, how many companies would have started (ie: RedHat, Thwat,etc), What features/addons would not have been added to other operating systems (Windows tcp/ip)? Would docker even be a thing, hyper-v ? I know one thing....... All the old technology would be alot more and schools would have alot more vunerabilites on their PC's. On Tue, Aug 27, 2019 at 1:13 AM Arthur Krewat <krewat@kilonet.net> wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > 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 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. > > > [-- Attachment #2: Type: text/html, Size: 2394 bytes --]
On 28 Aug 2019 11:36 +0200, from angus@fairhaven.za.net (Angus Robinson): > I think another question would be, if Linux was never invented, what > technologies would never have happened. I think that if there is a need to be filled, then something will fill that need. In our timeline, in plenty of cases that need ended up being filled by Linux -- quite possibly not in least part because it's there, it's cheap, it's reasonably well-supported, and it can be modified and extended by end users relatively easily. However, absent Linux, as long as the task still needed to be done, _something else_ would have filled the need at some point. Plenty of people got interested in the technology/information technology sector well before Linux. Maybe Linux offered a venue for some of those people to _express_ their interest, but I have a hard time seeing why Linux would be a prerequisite. 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. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor)
Michael Kjörling <michael@kjorling.se> wrote:
> 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.
Hoo boy. You can thank Andy Tannenbaum that we have Linux in the first
place (almost).
Linus used Minix as his development environment and early versions
supported the Minix filesystem.
I can't cite sources, but as I remember it, at the time (AT&T law suit)
a number of people turned to Tannenbaum to get him to open source Minix
and let people make it a "real" OS (VM, 386 support, etc.).
He wasn't interested. He only cared about teaching and he wanted to
maintain control over it. (Eventually it grew anyway, but only long
after.)
If he'd been more open, things might have indeed gone that way.
This brings up that there were other maybe viable candidates in
the research world: Sprite at UCB and Tannenbaum's Ameoba. But it seems
that those were mainly vehicles to get papers published and didn't
spread beyond their home universities.
At some point I got a CD with all the Sprite sources. Maybe I can
find that and get it to Warren.
Arnold
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --] 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 Sent: Wednesday, August 28, 2019 2:47 PM To: Wesley Parish Cc: TUHS main list Subject: Re: [TUHS] If not Linux, then what? On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong@gmail.com> wrote: >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? 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 [-- Attachment #2: Type: text/html, Size: 3427 bytes --]
On 28 Aug 2019, at 13:05, Jason Stevens <jsteve@superglobalmegacorp.com> wrote:
> I have OSF/1 1.0 running on gxemul …
>
> Any idea on where/ how to configure OSI?
I am not entirely sure it was already available on 1.0, it was around on 2.0.
You got OSI via the "DECnet Plus OSI” and I seem to recall needing a PAK for it.
eolo:~/sys/PAKs/PAKs-DECcampus/paks_unix$ ls *osi*
decnet-osi-end decnet-osi-ext
:)
Arrigo
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --] On Wed, Aug 28, 2019, 12:19 AM Wesley Parish <wobblygong@gmail.com> wrote: > 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? > The Wollongong Group has OSI for various flavors of Sustem V and System III running on the 3B* family, 386 and a few others. I recall setting them up for interop in the summer of 1989. Warner Wesley Parish > > > On 8/28/19, George Michaelson <ggm@algebras.org> 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 > > > < snip > > [-- Attachment #2: Type: text/html, Size: 1800 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2289 bytes --] On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy <lm@mcvoy.com> wrote: > I could be wrong but that's my memory. What he told me was streams was > for line disciplines for tty drivers. > 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. But I will say, I did agree that when we looked later at Stellar; but stuck with using sockets. This was for no other reason than to ensure that the BSD code 'just worked' and for a product, which where I was at the time (and I think Larry also at Sun), ensuring existing code worked (and worked efficiently), has to be the high order bit. I do hear you about many of the deficancies of 'pure joy.' It seems that it is always difficult as systems implementors to decide when to have an 'ice age' and try to kill off the old code and when to evolve it. IMHO: the code running user space that exploited the networking layer was still new enough, that evolution (*i.e.* hanging on an interface that was seemly 'good enough' - sockets) was more attractive than revolution. FWIW: we can now analyize and argue why BSD UNIX and the socket interface were what made it happen, but the historical fact is that sockets did seed the user space network code base. Also, I will observe that your comments about replacing MPX are a solid memory for me also, IIRC Greg developed MPX for datakit originally. He had sent me a copy at CMU in the late 1970s (but before V7 was out the door) and we had it in our v6++/CMU distr front -end system. I also remember messing with it in on the Teklabs system. Because I had messed with it at CMU aqnd was familar with its semantics, we we got the 3COM UNET code base (which was the first commercial IP/TCP implementation and it ran in user space unlike the later BBN Gurwitiz code base), and I rewrote some of Greg Shaw and Bruce Borden's stuff to use MPX. I'm trying to remember how their code worked before we hacked it -- (maybe Rand Pipes); but that was too many beers ago for my brain to still have it. I'm pretty sure Greg/Bruce took this back to 3Com when we were done. Sadly, the UNET stuff seems to have been lost. Clem [-- Attachment #2: Type: text/html, Size: 3323 bytes --]
[-- Attachment #1: Type: text/plain, Size: 747 bytes --] On Wed, Aug 28, 2019 at 2:46 AM Peter Jeremy <peter@rulingia.com> 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. > Ditto. > > 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. > Tru64 talked to DECnet Phase X (I don't remember which one, maybe 4 or 5), which had become an ISO/OSI stack by that point for political reasons inside of Digital (the OSI vs TCP war reminded me of the Pascal vs C and VMS vs UNIX wars - all very silly in retrospect, but I guess it was really about who got which $s for development). Clem [-- Attachment #2: Type: text/html, Size: 1854 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --] If that's the MIPs code base, it is likely to not be there. I could be forgetting something, but I remember that DECnet was released for the MIPS products. It was on Tru64 and Ultrix, but is a 'layered product' so you needed a license to install it and it needed to be a late enough version that had switched to exposing a full OSI stack. That said, I do not remember/know how well it functioned talking to any OSI stack other than DECs. On Wed, Aug 28, 2019 at 7:05 AM Jason Stevens < jsteve@superglobalmegacorp.com> wrote: > > > 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 <peter@rulingia.com> > *Sent: *Wednesday, August 28, 2019 2:47 PM > *To: *Wesley Parish <wobblygong@gmail.com> > *Cc: *TUHS main list <tuhs@minnie.tuhs.org> > *Subject: *Re: [TUHS] If not Linux, then what? > > > > On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong@gmail.com> > > wrote: > > >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? > > > > 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 > > > [-- Attachment #2: Type: text/html, Size: 3814 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2411 bytes --] 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 — what if Linus did find out about it and then ultimately took it over ( removing the caustic personalities ) or at worst forked it. I think that would have become a much preferable outcome. Just my $0.02. Earl Sent from my iPhone > On Aug 28, 2019, at 5:36 AM, Angus Robinson <angus@fairhaven.za.net> wrote: > > Interesting question, the alternative OS would have had to have had a good leader and I am sure maybe RMS would have created a kernel after some time. > Maybe somebody would have taken 386BSD/FreeBSD/NetBSD and made something completely different. > I think another question would be, if Linux was never invented, what technologies would never have happened. For instance, a bunch of animation movies where made with Linux farms, Planes use Linux within their inbuilt entertainment systems, the list goes on (I think NASA uses linux on their ISS). How many people would be interested in technology/IT sector, how many companies would have started (ie: RedHat, Thwat,etc), What features/addons would not have been added to other operating systems (Windows tcp/ip)? Would docker even be a thing, hyper-v ? > > I know one thing....... All the old technology would be alot more and schools would have alot more vunerabilites on their PC's. > > > > >> On Tue, Aug 27, 2019 at 1:13 AM Arthur Krewat <krewat@kilonet.net> wrote: >> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >> >> 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 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. >> >> [-- Attachment #2: Type: text/html, Size: 3268 bytes --]
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. On 8/28/2019 4:36 AM, Angus Robinson wrote: ... > I think another question would be, if Linux was never invented, what > technologies would never have happened. For instance, a bunch of > animation movies where made with Linux farms, Planes use Linux within > their inbuilt entertainment systems, the list goes on (I think NASA uses > linux on their ISS). How many people would be interested in > technology/IT sector, how many companies would have started (ie: RedHat, > Thwat,etc), What features/addons would not have been added to other > operating systems (Windows tcp/ip)? Would docker even be a thing, hyper-v ? > > I know one thing....... All the old technology would be alot more and > schools would have alot more vunerabilites on their PC's. > > > > On Tue, Aug 27, 2019 at 1:13 AM Arthur Krewat <krewat@kilonet.net > <mailto:krewat@kilonet.net>> wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > 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 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. > > -- voice: +1.512.784.7526 e-mail: sauer@technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer
On Wed, Aug 28, 2019 at 09:52:42AM -0400, Clem Cole wrote:
> On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy <lm@mcvoy.com> wrote:
>
> > I could be wrong but that's my memory. What he told me was streams was
> > for line disciplines for tty drivers.
> >
>
> 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.
If my memory is right, I would have talked to Dennis about it around
1987 or early 1988. Is it possible that was before they did networking
in streams?
Maybe I have the dates wrong but my guess is I talked to him about it
before the networking stuff was done in research Unix. So his view
may have evolved.
[-- Attachment #1: Type: text/plain, Size: 3433 bytes --] On Wed, Aug 28, 2019 at 10:10 AM Earl Baugh <earl.baugh@gmail.com> wrote: > 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 > A couple of items. Linus is on record as saying if he had known about the 'magic FTP site' at UCB for 386BSD code download, he would have obtained it [it is how most of us got it in those days]. The sad part is that his University was licensed for it from UCB, so *they could have gotten the code* is they had asked for it. But as Larry has pointed out, many Universities in those days took a fairly restrictive view of access to the Unix sources; so it's still now clear if Linus himself would have gotten a copy. — what if Linus did find out about it and then ultimately took it over ( > removing the caustic personalities ) or at worst forked it. > Hmmm, I fear, Linus just would have been one more personality, or his version would have been one more fork in the quickly branching, BSD tree. The real problem IMO was the lawsuit which happened shortly after 368BSD went into the wild. Let me tell you about my own experience from the time. As I said, people like myself got scared that UNIX for a PC/386 would not be available. We had Minix, but it did not use the paging HW, whereas Linus' code did and we thought, Linus code was unencumbered (it wasn't/isn't, while* it is a rewrite*, it is still based on the AT&T IP - but again that's a different part of story). I know I had personally had bought Minix myself for whatever it was (??$70 IIRC) in a 'book' of N floppies from Prentiss-Hall. I was semi-happy because it was a rewrite of Unix and was better than DOS. But .... it was originally floppy only for the 16 bit 8088 (XT not the AT) and very, slow and had quite limited in functionality (it did have a C compiler and ed but no vi, and definitely not, sockets). At the time, at work, I had a copy of the WD 1003 controller documentation - which was the disk controller IBM had used for the AT. A lot of people doing hacking on PC Unix in those days did not have that document as it turned out. So one of the first things I did, was to hack together a Minix AT/IDE driver for my system and sent it back, maybe posted it to net.noise (I've forgotten). As I had known him my UCB days, shortly thereafter it went into the wild, Joilitz contacted me. He had tried to write his AT disk driver for his version via "reverse engineering" (the BIOS ROMs I think). Bill's original code worked to a point but had some issues and he was looking for some help. I had a Wyse 32:16, which was one of the first 386 based PCs. Hence, I got my copy of Bill's work via the secret address to download. We updated his driver with missing info I gave him (FWIW: Bill references this in the DDJ articles). Anyway, now I had a 'real UNIX' and it was BSD even, Minix was not only primarily floppy-based, but it was a V7 clone so the difference was remarkable. Then lawyers showed up.... I know I got scared and so did a lot of others. Linus has recently made his post, so we all jumped. The rest is history, although as I point out, it is likely world today would have been much different it AT&T had won the lawsuit. But they did not so that is a moot point. [-- Attachment #2: Type: text/html, Size: 6449 bytes --]
[-- Attachment #1: Type: text/plain, Size: 957 bytes --] Could be. I'm not sure I can date it, On Wed, Aug 28, 2019 at 10:31 AM Larry McVoy <lm@mcvoy.com> wrote: > On Wed, Aug 28, 2019 at 09:52:42AM -0400, Clem Cole wrote: > > On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy <lm@mcvoy.com> wrote: > > > > > I could be wrong but that's my memory. What he told me was streams was > > > for line disciplines for tty drivers. > > > > > > > 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. > > If my memory is right, I would have talked to Dennis about it around > 1987 or early 1988. Is it possible that was before they did networking > in streams? > > Maybe I have the dates wrong but my guess is I talked to him about it > before the networking stuff was done in research Unix. So his view > may have evolved. > [-- Attachment #2: Type: text/html, Size: 1488 bytes --]
On Wed, 28 Aug 2019, Charles H Sauer wrote:
> 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 actually wrote an IRC client for plain DOS a few years ago - I used
WatTCP.
-uso.
[-- Attachment #1: Type: text/plain, Size: 84 bytes --] I think the biggest difference would have been no git and therefore no github, etc. [-- Attachment #2: Type: text/html, Size: 109 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3072 bytes --] On Wed, 28 Aug 2019 at 10:05, Clem Cole <clemc@ccc.com> wrote: > If that's the MIPs code base, it is likely to not be there. I could be > forgetting something, but I remember that DECnet was released for the MIPS > products. It was on Tru64 and Ultrix, but is a 'layered product' so you > needed a license to install it and it needed to be a late enough version > that had switched to exposing a full OSI stack. > > That said, I do not remember/know how well it functioned talking to any > OSI stack other than DECs. > 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. Customers were not happy. Anyway, the official release announcement ( https://groups.google.com/forum/?hl=en#!original/bit.listserv.esl-l/BovGe3q9yWE/cqlcCYfxmbAJ ) mentions a few layered products, none of which I have ever seen in the wild. No OSI implementation is mentioned. Looking through a list of layered products for Ultrix from mid-1994, I see a few OSI-related things: MIPS: DEC OSI Application 1.1 GZSAA Developer's Toolkit DECnet/OSI for ULTRIX 5.1A YT9AA OSI Application Toolkit 5.1A OSIAP_RISC VAX: DECnet/OSI for ULTRIX 5.1A 716AA OSI Application Toolkit 5.1A OSIAP_VAX If you want more documentation on any of these, contact me off-list. -Henry > On Wed, Aug 28, 2019 at 7:05 AM Jason Stevens < > jsteve@superglobalmegacorp.com> wrote: > >> >> >> 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 <peter@rulingia.com> >> *Sent: *Wednesday, August 28, 2019 2:47 PM >> *To: *Wesley Parish <wobblygong@gmail.com> >> *Cc: *TUHS main list <tuhs@minnie.tuhs.org> >> *Subject: *Re: [TUHS] If not Linux, then what? >> >> >> >> On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong@gmail.com> >> >> wrote: >> >> >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? >> >> >> >> 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 >> >> >> > [-- Attachment #2: Type: text/html, Size: 5694 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --] On Wed, 28 Aug 2019 at 03:41, Angelo Papenhoff <aap@papnet.eu> wrote: > On 28/08/19, Jason Stevens wrote: > > I don’t recall their being detailed installation instructions like > 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…. > > > > I guess it’s worth trying on whatever should be the parallel BSD system > 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. > Thanks, I hadn't found that yet. Unfortunately it assumes that you have a tape with at least a root and /usr dump, which we do not have. I have several ideas about how one might go about building the tree using existing distributions but any further discussion probably isn't appropriate for this list. If anyone would like to collaborate please feel free to contact me off-list. -Henry [-- Attachment #2: Type: text/html, Size: 1382 bytes --]
On Wed, Aug 28, 2019 at 12:34:46PM -0400, Henry Bent wrote:
> On Wed, 28 Aug 2019 at 10:05, Clem Cole <clemc@ccc.com> wrote:
>
> > If that's the MIPs code base, it is likely to not be there. I could be
> > forgetting something, but I remember that DECnet was released for the MIPS
> > products. It was on Tru64 and Ultrix, but is a 'layered product' so you
> > needed a license to install it and it needed to be a late enough version
> > that had switched to exposing a full OSI stack.
> >
> > That said, I do not remember/know how well it functioned talking to any
> > OSI stack other than DECs.
> >
>
> 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? I had
sort of stopped paying attention to them, so don't know the reasoning.
On 8/28/2019 10:32 AM, Larry McVoy wrote:
> Perhaps Clem can shed some light on why DEC did a MIPS machine? I had
> sort of stopped paying attention to them, so don't know the reasoning.
I always thought it was because the Vaxes were too slow (and too
expensive) to compete with Sun, and the Alphas wouldn't be ready
soon enough. So, going with MIPS was a relatively quick and easy
solution.
In UC Berkeley CS in the early 90s we had lots of DEC MIP-stations.
In fact, I believe that Ousterhout used them to develop Sprite.
IIRC, there weren't nearly as many Suns, which was odd, considering
that Dave Patterson was in the department. As a result of the Sequoia
2000 project we got great deals on DEC hardware.
Jon
[-- Attachment #1: Type: text/plain, Size: 3418 bytes --] On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy <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). So, I think the MIPS product was a holding pattern while DEC got it's strategy together. Alpha would really show up until later (I would leave LCC and go to DEC to be apart if that). Also note Alpha was brought up/debugged on Ultrix and of course, Prism sort of had Ultrix on it. But I think using the MIPS chip keep them in the game, when Vax was dying and RISC was the word on the street. FWIW: The issue of OSF/1 was a different one. The whole switching off Ultrix, getting to a new OS had been kicking around DEC for a while. One of the arguments for Cutler had been his new Mica system was that it could run both Unix and VMS on top of it - *i.e.* a single OS kernel. When Prism was canceled (along with Mica) and Cutler left, that was a huge hole for DEC's SW strategy. Oppose Sun Forever (OSF) as it was formed to counter the Sun/AT&T move. That gave DEC a way out. But remember, OSF/1 on MIPS was actually not a full product. What you got was what OSF had released, which is why it really more like a beta. While it started down the path to being a product; and DEC did specifically made it available (primarily to Universities/Research types), DEC management was very reluctant to release it because they did not want to support it. In fact, LCC was asked to give a bid on taking it on after we had taken over Ultrix. DEC management already saw Ultrix/MIPS as a resource drag once Alpha finally had been committed. [ FYI: this was the same behavior as IBM on AIX/360 BTW. Funny, how big companies sometimes do things like this]. I always said, asking customers (and the ISVs) to switch OS and ISA in one step was what caused a huge problem for DEC [along with the ISA being 64-bit only and ISV/customer code 32-bit dirty]. I've often wondered if a 32/64 bit OSF/1 MIPS stepping stone using the R4400 had been available, particularly with the Gem compiler suite (which they had but never released outside of DEC), it would have allowed the ISVs to move to Alpha quicker. Having to do it all in one step, cost them 3 years and more importantly, by the time the code was 64-bit clean; Sun & PPC had a 64-bit system and took the ISVs with away. Clem [-- Attachment #2: Type: text/html, Size: 7614 bytes --]
[-- Attachment #1: Type: text/plain, Size: 365 bytes --] On 2019-Aug-28 11:37:51 -0400, Richard Salz <rich.salz@gmail.com> wrote: >I think the biggest difference would have been no git and therefore no >github, etc. But there are other open SCM tools and it's likely there would be another site serving similar functionality. As an example. Google offered a code-sharing site for many years. -- Peter Jeremy [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 963 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --] On Wed, 28 Aug 2019 at 15:55, Peter Jeremy <peter@rulingia.com> wrote: > On 2019-Aug-28 11:37:51 -0400, Richard Salz <rich.salz@gmail.com> wrote: > >I think the biggest difference would have been no git and therefore no > >github, etc. > > But there are other open SCM tools and it's likely there would be another > site serving similar functionality. As an example. Google offered a > code-sharing site for many years. > I was not a particularly early adopter of Git; I was already a couple years into usage of darcs. A one-time colleage, Graydon Hoare, was one of the designers of Monotone, which definitely influenced Git. (He's more recently known for the Rust language, and presently works at Apple on their Swift language.) Arch, Bazaar (bzr), Mercurial (hg), Codeville were also out there at the time. It's rather interesting that Git happened to "win" that particular war; there were various DSCM systems with similar (and dissimilar) capabilities emerging in around 2003-2005. Various were reasonably "production worthy." Indeed, it's quite fair to say that at the time Git emerged, there was a very active set of competing distributed SCMs out there. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" [-- Attachment #2: Type: text/html, Size: 1896 bytes --]
[-- Attachment #1: Type: text/plain, Size: 4040 bytes --] On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat@kilonet.net> wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > 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?" [-- Attachment #2: Type: text/html, Size: 5191 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1272 bytes --] On 28 Aug 2019, at 20:57, Clem Cole <clemc@ccc.com> wrote: >> On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy <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. As a customer, back in 1992 in the UK: DEC sold us Ultrix DECstations running on the R3000, the R4000 upgrade and then told us the Alpha upgrade would be for peanuts. So we ran this research cluster with one Alpha 3000/600 and two Alpha 3000/400 running OSF/1 T1.0 and the DECstations on Ultrix, compiling everything on Ultrix and "mx"ing into OSF/1 until, with OSF/1 2.0 the "upgrades" showed up and we ended up with a beautiful Alpha cluster which was the envy of the college. They then spread like wildfire when engineering depts tried their code on our cluster… For us the MIPS DECstations were literally placeholders for the Alphas we'd be getting with the trade-in! One of the DECstations is still with me because it turned out that DEC did not want back the huge stack of DECstations we had piled up for the trade-in! Arrigo [-- Attachment #2: Type: text/html, Size: 1976 bytes --]
[-- Attachment #1: Type: text/plain, Size: 6511 bytes --] 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 <cbbrowne@gmail.com> wrote: > On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat@kilonet.net> wrote: > >> >> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >> >> 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?" > [-- Attachment #2: Type: text/html, Size: 8047 bytes --]
[-- Attachment #1: Type: text/plain, Size: 7016 bytes --] Actually, IIRC, you could use fdisk to split up drives in FreeBSD... I think I did that in the 1.02 days... The problem is the semantics of slices and partitions. Also *BSD, I recall, had to boot from a primary partition. I don't know if lilo cared and grub2 sure doesn't. Sent from pechter@gmail.com -----Original Message----- From: Adam Thornton <athornton@gmail.com> To: The Eunuchs Hysterical Society <tuhs@tuhs.org> Sent: Wed, 28 Aug 2019 16:28 Subject: Re: [TUHS] If not Linux, then what? 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 <cbbrowne@gmail.com> wrote: > On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat@kilonet.net> wrote: > >> >> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >> >> 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?" > [-- Attachment #2: Type: text/html, Size: 8773 bytes --]
--- Ursprüngliche Nachricht ---
Von: Arthur Krewat <krewat@kilonet.net>
Datum: 27.08.2019 01:13:25
An: TUHS main list <tuhs@minnie.tuhs.org>
Betreff: [TUHS] If not Linux, then what?
> But if not for Linux, would it be BSD? A System V variant? Or (the
> horror) Windows NT?
mainly variants of Windows, Unices in some niches.
[-- Attachment #1: Type: text/plain, Size: 7532 bytes --] Absolutely. Bill Jolitiz wrote the original version of fdisk with a very small assist from me. I used to keep a 33m dos partition on my system if for no other reason than the diags all ran on dos Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 28, 2019, at 4:56 PM, William Pechter <pechter@gmail.com> wrote: > > Actually, IIRC, you could use fdisk to split up drives in FreeBSD... I think I did that in the 1.02 days... > > The problem is the semantics of slices and partitions. Also *BSD, I recall, had to boot from a primary partition. I don't know if lilo cared and grub2 sure doesn't. > > > Sent from pechter@gmail.com > > -----Original Message----- > From: Adam Thornton <athornton@gmail.com> > To: The Eunuchs Hysterical Society <tuhs@tuhs.org> > Sent: Wed, 28 Aug 2019 16:28 > Subject: Re: [TUHS] If not Linux, then what? > > 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 <cbbrowne@gmail.com> wrote: >>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat@kilonet.net> wrote: >> >>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >>> >>> 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?" [-- Attachment #2: Type: text/html, Size: 9487 bytes --]
I tried three times to respond by phone but the lack of a decent environment for mail killed my first attempts. Anyway, without top posting: On 8/28/2019 4:27 PM, Adam Thornton 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. > 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. Unfortunately, I left IBM and IBM dumped OS/2 support and future releases. <snip> > > 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. > > I love Framemaker. I run a 2nd hand version of Windows Framemaker since I no longer have any Unix boxes that would run the Unix version unless I pull an old CD and rebuild a SunOS 4 box. Wonder if the NVRAM battery's dead in the Sparc2 or Sparc10? I did a training Unix Admin for DC/OSx course for Pyramid that could print a full doc with instructors guide (on back side of the pages) and all the pages and overheads for the class in a single Frame doc. And everyone told me it couldn't be done in Frame 1.2 or 1.3 on Pyramid OSx. Sure you can if you force it. Come here and hold my Xterminal keyboard and my beer. 8-) Anyway, I thought I had a 386 running with Win3.1 and OS/2 and FreeBSD on a single drive. I checked the FreeBSD archives and it COULD install in a primary partition (partition type 165) and share the disk with other OS types. The one thing that was a PITA was the docs --- since they used the partition term as well as "disk slices" with partitions meaning ONE thing to Unix folks and another to DOS/Windows/OS2 types. So it was explained multiple times on the FreeBSD mailing lists. I never had any issue with it and until ZFS which wants it's own drives to control (and drives are now cheap and large -- so why not splurge a bit for data protection...) Bill
[-- Attachment #1: Type: text/plain, Size: 6937 bytes --] 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 <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 <cbbrowne@gmail.com> wrote: >>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat@kilonet.net> wrote: >> >>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >>> >>> 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?" [-- Attachment #2: Type: text/html, Size: 8654 bytes --]
[-- Attachment #1: Type: text/plain, Size: 7903 bytes --] 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 <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 <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 <cbbrowne@gmail.com> > wrote: > >> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat@kilonet.net> wrote: >> >>> >>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >>> >>> 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?" >> > [-- Attachment #2: Type: text/html, Size: 9901 bytes --]
On 8/28/2019 6:27 PM, William Pechter wrote:
> I checked the FreeBSD archives and it COULD install in a primary
> partition (partition type 165) and share the disk with other OS types.
At some point, I had written a boot partition hook to select which
partition to boot, and set it as Primary on the fly by modifying the
partition table. The comments below are from a precursor to that. Sadly
I do not have the source code for the later version where I had added
the selection menu and actual partition table update to. Note the reason
I started it ;)
I know I was dual booting FreeBSD or maybe Consensys (SVR4.2) with DOS
at some point, and based on the dates on this source code, it would have
been around the second half of 1992.
PART.ASM:
Title PART - Partition table boot-up program.
Comment *
(C) 1992 Kilowatt Computing - Arthur Krewat
Started Feb 2, 1992
Initiated by the Michelangelo Virus of 1/1992 - I figured if I
have a program using sector 0 of the hard drive and something
writes
to it, it SHOULD crash - unless the virus is particularly
intelligent. And we all know writers of virii are NOT or else
they'd
be doing something INTELLIGENT with their time.
*
Later on in the file:
Partb Db 00H,"Unknown - empty",0 ;System indicators.
Db 01H,"DOS (12 bit FAT)",0
Db 02H,"XENIX",0
Db 04H,"DOS (16 bit FAT)",0
Db 05H,"DOS - extended partition",0
Db 06H,"DOS 4.0",0
Db 51H,"Ontrack extended partition",0
Db 64H,"Novell",0
Db 75H,"PCIX",0
Db 0DBH,"CP/M",0
Db 0FFH,"BBT",0
Db 0
[-- Attachment #1: Type: text/plain, Size: 10161 bytes --] On 8/28/2019 6:48 PM, Adam Thornton wrote: > It probably was the partition/slice confusion that, well, confused me, > then. My experience, such as it was, was from the DOS world. As was mine mostly 8-) I remember it from the PITA it was to translate in my head. Unix folks looked at partitions as /dev/dsk/0s0->0s7 (I think 7 was the SVR2 maximum. The "Unix" partitions fit inside the FDISK partition or dos slice... The dos guys looked at it kind of like the fdisk space disk0 partition 3 (for example) was the partition and then the BSD folks broke that in to /dev/sd0a /dev/sd0b /dev/sd0c etc. I did a little SunOS and SysV along with Dos and Windows and could make them coexist as long as there was an open primary dos partition. > > 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? > 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 > 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 <clemc@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 <athornton@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 >> <cbbrowne@gmail.com <mailto:cbbrowne@gmail.com>> wrote: >> >> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat >> <krewat@kilonet.net <mailto:krewat@kilonet.net>> wrote: >> >> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >> >> 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?" >> [-- Attachment #2: Type: text/html, Size: 17621 bytes --]
Hello!
I can certainly attest to that one. The partition methods Slackware
was using for releases before 3.0 were stranger then a lot of things.
For release 3.0 and later it all started to make sense. I had more
problems thought figuring out why several others really wanted me to
break up the disk into a batch of individual ones......
However while exploring both NetBSD and FreeBSD I did workout why they
wanted the disk broken out into those slices.
-----
Gregg C Levine gregg.drwho8@gmail.com
"This signature fought the Time Wars, time and again."
On Wed, Aug 28, 2019 at 6:29 PM Clem cole <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 <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 <cbbrowne@gmail.com> wrote:
>>
>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat@kilonet.net> wrote:
>>>
>>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>>>
>>> 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?"
[-- Attachment #1: Type: text/plain, Size: 9412 bytes --] This was pre-SLS as well. I remember vividly how excited I was when it came out in mid-92 and how much like cheating it was. A little googling and I'm sure I used the HJ Lu diskettes. I don't actually remember hand-editing the MBR but, well, I probably did. Adam On Wed, Aug 28, 2019 at 4:01 PM William Pechter <pechter@gmail.com> wrote: > On 8/28/2019 6:48 PM, Adam Thornton wrote: > > It probably was the partition/slice confusion that, well, confused me, > then. My experience, such as it was, was from the DOS world. > > As was mine mostly 8-) I remember it from the PITA it was to translate in > my head. Unix folks looked at partitions as /dev/dsk/0s0->0s7 (I think 7 > was the SVR2 maximum. The "Unix" partitions fit inside the FDISK partition > or dos slice... The dos guys looked at it kind of like the fdisk space > disk0 partition 3 (for example) was the partition and then the BSD folks > broke that in to /dev/sd0a /dev/sd0b /dev/sd0c etc. > > I did a little SunOS and SysV along with Dos and Windows and could make > them coexist as long as there was an open primary dos partition. > > > > 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? > > > 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 > > > 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 <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 <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 <cbbrowne@gmail.com> >> wrote: >> >>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat@kilonet.net> wrote: >>> >>>> >>>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >>>> >>>> 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?" >>> >> > [-- Attachment #2: Type: text/html, Size: 18094 bytes --]
On Wed, Aug 28, 2019 at 04:07:39PM -0400, Christopher Browne wrote: > > - Hurd was imagined to be the next thing... > > To borrow from my cookie file... > > "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. 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 together with people from Berkeley on such an effort. Some of them 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/features/whatever-happened-to-the-hurd-the-story-of-the-gnu-os 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%. :-) > 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. 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
[-- Attachment #1: Type: text/plain, Size: 2839 bytes --] > On 2019, Aug 28, at 2:56 PM, Clem Cole <clemc@ccc.com> wrote: > > > > On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy <lm@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). I was at the Digital Systems Research Center in Palo Alto between 1984 and 1989. Also located in Palo Alto were the Western Research Lab (run by Forest Baskett), Workstation Systems Engineering, and the West Coast Systems Lab. Steve Bourne was at one of these. All were within a few blocks of each other and easy walking distance to “Louis’” chinese restaurant, whose official name was “The Little Restaurant”. The rule was that you could not go to Louis' for lunch if you had eaten lunch there the day before. At the time, SRC was building multiprocessor research workstations with VAX chips (the Firefly, I did some of the hardware) and WRL was building an ECL RISC machine (the Titan). WSE was started, I think, to commercialize a multiprocessor VAX workstation something like the Firefly. WSL was a software group working on window systems and things like multimedia software. The WSE machines became the VAXStation 3520 and 3540, code named FireFox (showing the ancestry I guess!). The folks at WSE, I think with egging on from WRL, who were in the same building, then built the R2000 based “PMAX” and then the R3000 based “3MAX”. These were rather nice machines for 1990 and 1991. They also invented a flat attaching I/O card format “TurboChannel”. The impression I has was that the RS6000 and the PA-RISC and the various MIPS machines put a large scare into Digital. I don’t know how the politics worked for this. The west coast was a long long way from Maynard. Larry [-- Attachment #2: Type: text/html, Size: 5601 bytes --]
On 8/29/19, William Pechter <pechter@gmail.com> wrote: > On 8/28/2019 6:48 PM, Adam Thornton wrote: <snip> > > >> >> 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? >> > > 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 FWLIW, you can get a copy of my installation of SLS at https://sourceforge.net/projects/bochs/files/Disk%20Images/SLS%20Linux/ I included the floppy images so any time you can reinstall it or just work on acquiring the joys of diskswapping as we knew it back then. (It's one way to go crazy when you're tired, and get the fdisk/mkfs stage wrong, or pick up the wrong disk or ... :) > > <snip>
Lawrence Stewart <stewart@serissa.com> wrote: > > At the time, SRC was building multiprocessor research workstations with > VAX chips (the Firefly, I did some of the hardware) and WRL was building > an ECL RISC machine (the Titan). I've found a Titan System Manual from 1988 https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-86-1.pdf It's a curious machine with a number of unusual instruction set features - an 8 bit CPU process ID hooked into the virtual memory system, register banks selected using the processor status register - otherwise RISC flavoured. Did it have any successors? Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ The Minch: Southwest 5 to 7, occasionally gale 8 for a time, decreasing 2 or 3 and becoming cyclonic later. Moderate or rough. Rain or showers. Moderate or good, occasionally poor.
Adam Thornton <athornton@gmail.com> wrote: > > 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. I started work at Demon Internet in 1997. Its origins before 1992 were in SCO / Xenix consultancy, but by the time I joined the ISP systems were mostly flavours of BSD and Sun. My colleagues didn't think Linux was sufficiently good at networking, and I got the impression that was a relatively common opinion in ISP circles around 1995/6. That kind of suggests to me that Unix would have been helped by the rise of the Internet even without Linux... Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Shannon: Southwest 5 to 7, occasionally gale 8 for a time. Rough or very rough. Rain. Good, becoming moderate or poor.
On Wed, Aug 28, 2019 at 7:20 PM Theodore Y. Ts'o <tytso@mit.edu> wrote: <snip> > 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%. :-) <snip> Case in point: https://jalopnik.com/the-founders-of-sun-microsystems-their-cars-and-their-5562572 I'm not making any judgments, good or bad. It is what it is.
On 8/29/2019 9:31 AM, A. P. Garcia wrote:
> On Wed, Aug 28, 2019 at 7:20 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> <snip>
>
>> 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%. :-)
> <snip>
>
> Case in point: https://jalopnik.com/the-founders-of-sun-microsystems-their-cars-and-their-5562572
>
> I'm not making any judgments, good or bad. It is what it is.
>
Except for the Ferrari (which would be around $160K in today's US
dollars), the other three are pretty much bargain-basement sports cars ;)
>: Arthur Krewat <krewat@kilonet.net> > > <snip> > 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. > > >
On 08/28/19 18:27, William Pechter wrote (in part):
> On 8/28/2019 4:27 PM, Adam Thornton 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.
>>
> 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.
Indeed -- forgive my nostalgia here... We were developing a DOS-based
PC-Card (often incorrectly called a PCMCIA card). With OS/2, you opened
up a DOS box. If the driver crashed, you just opened up another and went
on. Under Windoze, the whole box crashed (and sometimes took the
file-system with it). We used a combination of Eberhard Mattes' emx,
the MKS toolkit, and case-sensitive file-systems to give us a reasonable
approximation.
N.
Nemo Nusquam wrote in <8cb953ef-ef6d-fdfa-76a4-1074cf46f598@gmail.com>: |On 08/28/19 18:27, William Pechter wrote (in part): |> On 8/28/2019 4:27 PM, Adam Thornton 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. |>> |> 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. |Indeed -- forgive my nostalgia here... We were developing a DOS-based |PC-Card (often incorrectly called a PCMCIA card). With OS/2, you opened |up a DOS box. If the driver crashed, you just opened up another and went |on. Under Windoze, the whole box crashed (and sometimes took the |file-system with it). We used a combination of Eberhard Mattes' emx, |the MKS toolkit, and case-sensitive file-systems to give us a reasonable |approximation. For a few holiday weeks i once worked in the IBM factory in Mainz Germany in a hard disk production line clean room. One of the gauges were driven by OS/2 which not only catched my attention but also crashed randomly up to several times per shift, causing automatic reboots (reliably). (The factory as such was not worth it, it has been closed after fifty years, in the new Heiligkreuz Viertel (holy-cross quarter) there have been build 242 flats and a supermarket in the meantime.) I liked 4DOS. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Thomas Paulsen wrote in <004ec49789583b190ca7c302db9fbb31@firemail.de>: |>: Arthur Krewat <krewat@kilonet.net> |>> <snip> |> 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. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On Thu, 29 Aug 2019, Steffen Nurpmeso wrote:
> |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.
[ Getting OT... ]
Too bad about the seals, though... They had this habit of wearing out.
-- Dave
Hello. Dave Horsfall wrote in <alpine.BSF.2.21.9999.1908311134050.37360@aneurin\ .horsfall.org>: |On Thu, 29 Aug 2019, Steffen Nurpmeso wrote: |>|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. | |[ Getting OT... ] Yes, sorry for that. |Too bad about the seals, though... They had this habit of wearing out. I do not think this is actually true. I think it was "not false" for the first series of the NSU Ro80 at the beginning of the 70s, but materials engineering is what made such unbelievable progress ever since, it always leaves me just speechless. "Not false" in that it likely was dependent on the way of driving even back then. I definitely have heard stories of people still driving Ro80 first series, original. And for later ones, say Mazda RX-8, i think it is a problem of the past, anyway. I just looked, and Mazda finally gave 100000 Miles guarantee for the seals. I mean, in the end these are industry products which compete in a surrounding market, and i do not mean this positively. For example, the Lenovo laptop i bought this year grants itself a four year lifetime (states the manual for the Russian market, for which such statements seem to be required). The problem of the Wankelmotor is the form of the combustion chamber, which is even worse than for the Otto (or Diesel) piston engine, even less spherical. Modern injection systems and electronical management can overcome this a bit. You know, i will never forget the IAA (car exhibition in Frankfurt/Main Germany) either at the end of the 80s or the beginning of the 90s, where Toyota shewed high-speed videos of the combustion process. It was rather trial-and-error before, with a lot of things tried (piston forms, multiple spark plugs, electronical spark control), but Toyota came up with diet mix engines at that time, and started to use direct injection (iirc). This is not new, i think we had that already for fighter plane engines in WWII, but it was trial and error. With those videos and better gauges the combustion process was better understood, and resulted in improved efficiency and exhaustion behaviour. I was surprised that the Atkinson engine which drives at least the Honda and Toyota Hybrid cars does not use direct injection, but rather the suction line one again, but it is the end of decades of science and exploration, right. Some Atkinson engines use a mixed injection that also includes direct injection it seems (Lexus?). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
[-- Attachment #1: Type: text/plain, Size: 5436 bytes --] On Wed, 28 Aug 2019 at 19:19, Theodore Y. Ts'o <tytso@mit.edu> wrote: > On Wed, Aug 28, 2019 at 04:07:39PM -0400, Christopher Browne wrote: > > > > - Hurd was imagined to be the next thing... > > > > To borrow from my cookie file... > > > > "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. > > 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. > Thanks, patched! :-) And yes, I agree that you weren't arguing for the impending relevance of Hurd. Nevertheless, at the time, there were people making the argument that Hurd would Real Soon Now make Linux irrelevant. > 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 together with people from Berkeley on such an effort. Some of them > 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/features/whatever-happened-to-the-hurd-the-story-of-the-gnu-os I haven't seen reference to Bushnell in a long time; looks like he has shifted to ecclesiastical matters. He was up to some interesting software things, once upon a time. The tales of Stallman being stubborn are not rare. It's interesting that perhaps BSDI was a reason for GNU avoiding 4.4-Lite. That points to why the "what might have been" is very troublesome to track down. Alternatives always interact with one another... > 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%. :-) > > > 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. > > 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 > Yeah, there's dysfunction everywhere :-). Over the years, I have heard BSD folk blasting Linux over Linus' occasional lack of tact; that is very much a road MORE travelled by a great many projects. Hurd's challenges starved it of staff, definitely unhelpful. BSD had both amicable as well as ridiculously non-amicable forks. It's not at trivial to get the right balance and plenty easy for missteps to lead to disaster. As vast overgeneralizations of the extremes, pure diplomats don't get anything done, whilst jerks don't get enough help to support upgrading to the next generation of motherboards/disk drives/graphics cards. Successful systems fall somewhere in between. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" [-- Attachment #2: Type: text/html, Size: 6991 bytes --]
On Sat, Aug 31, 2019 at 12:58:00PM -0400, Christopher Browne wrote: > > I haven't seen reference to Bushnell in a long time; looks like he has > shifted to ecclesiastical matters. He was up to some interesting > software things, once upon a time. Thomas has been working for Google for a number of years. (Brothers of Saint Gregory are expected to support themselves, and so they tend to have lay jobs in addition to their eccleiastical service.) Thomas was working on supporting the Linux desktop for Google engineers[1][2]. (At the time, Google was using Ubuntu LTS; these days, Google desktops are using Debian testing[3].) [1] https://www.youtube.com/watch?v=oGUzhiJu_Jg [2] https://events.static.linuxfound.org/images/stories/pdf/lcna_co2012_bushnell.pdf [3] https://www.ghacks.net/2018/01/24/google-switches-from-ubuntu-to-debian-as-base-for-their-in-house-os/ - Ted