26 Aug
2019
26 Aug
'19
11:13 p.m.
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
I 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.
26 Aug
26 Aug
11:27 p.m.
On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat <krewat(a)kilonet.net> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
BSD was in decent enough shape at the time to run on PCs. Though it
fragmented early through no fault of Linux. And the AT&T lawsuit created a
lot of FUD in the area without actually protecting System V. It's unclear
if another thing would have popped up to fill the void... Linux flourished
in the confusion, but without it, it's hard to know if something else would
have been developed before the AT&T lawsuit settled.
Warner
I do understand that this has been discussed on the list before. I
think, however, it would make a good late-summer
exercise. Or late
winter depending on where you are :)
art k.
11:37 p.m.
On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote:
On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat
<krewat(a)kilonet.net> wrote:
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.
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
BSD was in decent enough shape at the time to run on PCs. Though it
fragmented early through no fault of Linux. And the AT&T lawsuit created a
lot of FUD in the area without actually protecting System V. It's unclear
if another thing would have popped up to fill the void... Linux flourished
in the confusion, but without it, it's hard to know if something else would
have been developed before the AT&T lawsuit settled. 
11:56 p.m.
On 8/26/2019 7:27 PM, Warner Losh wrote:
On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat <krewat(a)kilonet.net
<mailto:krewat@kilonet.net>> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental
exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it
to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly
ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
BSD was in decent enough shape at the time to run on PCs. Though it
fragmented early through no fault of Linux. And the AT&T lawsuit
created a lot of FUD in the area without actually protecting System V.
It's unclear if another thing would have popped up to fill the void...
Linux flourished in the confusion, but without it, it's hard to know
if something else would have been developed before the AT&T lawsuit
settled.
Warner
I do understand that this has been discussed on the list before. I
think, however, it would make a good late-summer exercise. Or late
winter depending on where you are :)
art k.
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
12:30 a.m.
On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote:
On 8/26/2019 7:56 PM, William Pechter 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.
ZFS
Here, here! 
12:48 a.m.
On Mon, Aug 26, 2019 at 7:28 PM Warner Losh <imp(a)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-d…
],
.... *if AT&T had won the case, all the other UNIX flavors* (Linux included
would have had to have been pulled from the market).
So in many ways, this question is not really a fair one.
AT&T lost the case, and Linux got the ball and ran for it.
That said, I'll drop into the hypotheical, if AT&T had lost and Linux had
not been there ..... then... I do think some flavor of BSD would have been
the winner. The two wild cards are from Sun and OSF/CMU. As Larry says
is what about SunOS and Solaris, although the legals of Sun doing that I
wonder. The other question is Mach/OSF (I know Larry does not like the
codebase).
But one of the *BSD, Mach or an FOSS Sun code base would have had the most
legs.
Clem
12:58 a.m.
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(a)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:
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.
ZFS
Here, here!
12:59 a.m.
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.
1:06 a.m.
On Mon, Aug 26, 2019 at 8:59 PM Rob Pike <robpike(a)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
1:17 a.m.
On Mon, Aug 26, 2019, 7:14 PM Arthur Krewat <krewat(a)kilonet.net> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
I 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.
1:25 a.m.
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(a)gmail.com
"This signature fought the Time Wars, time and again."
On Mon, Aug 26, 2019 at 8:49 PM Clem Cole <clemc(a)ccc.com> wrote:
On Mon, Aug 26, 2019 at 7:28 PM Warner Losh <imp(a)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-d…],
.... if AT&T had won the case, all the other UNIX flavors (Linux included would have
had to have been pulled from the market).
So in many ways, this question is not really a fair one.
AT&T lost the case, and Linux got the ball and ran for it.
That said, I'll drop into the hypotheical, if AT&T had lost and Linux had not
been there ..... then... I do think some flavor of BSD would have been the winner. The
two wild cards are from Sun and OSF/CMU. As Larry says is what about SunOS and Solaris,
although the legals of Sun doing that I wonder. The other question is Mach/OSF (I know
Larry does not like the codebase).
But one of the *BSD, Mach or an FOSS Sun code base would have had the most legs.
Clem
1:26 a.m.
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.
2:16 a.m.
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
2:39 a.m.
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:
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.
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.
2:45 a.m.
On Mon, Aug 26, 2019 at 09:26:27PM -0400, Dan Cross wrote:
On Mon, Aug 26, 2019, 9:00 PM Arthur Krewat wrote:
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.
[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.
2:53 a.m.
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(a)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
5:54 a.m.
On Aug 26, 2019, at 7:39 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
On Mon, Aug 26, 2019 at 10:16:58PM -0400, Theodore Y. Ts'o wrote:
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
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.
6:05 a.m.
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(a)gmail.com
"This signature fought the Time Wars, time and again."
On Tue, Aug 27, 2019 at 1:55 AM Adam Thornton <athornton(a)gmail.com> wrote:
On Aug 26, 2019, at 7:39 PM, Larry McVoy <lm(a)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
7:47 a.m.
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(a)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(a)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.
>
9:47 a.m.
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(a)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(a)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
2:55 p.m.
On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
On 8/26/2019 10:45 PM, Larry McVoy wrote:
I might be making too big of a deal about it. mmap semantics mattered
a lot when SMPs first showed up and main memory was small. It meant
that you could have multiple CPUs seeing and working on the same chunk
of data at the same time.
It's very similar to way that IOMMUs are exposed to user space these
days, enabling virtual machines direct access to the I/O devices.
ZFS breaks that model, the data is all in the ARC and if you mmap
it they have to bcopy the data out of the ARC, into the page cache
and now they have a consistency problem, you could modify stuff
via mmap or write and they have to manage that.
That consistency problem is the main reason that Sun almost completely
killed the buffer cache (it still was used for inodes and directories
but that was it). That consistency problem is a pain in the rear,
all sorts of race conditions and it tended to bit rot.
Jeff and Bill are smart people so I suspect they got it right but I'm
still stunned that they took such an architecturally bad approach.
And even more stunned that the oversight people approved it. There
is zero chance that the Sun I worked at would have allowed that.
--lm
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 ;) 
4:05 p.m.
New subject: Running v10
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.
4:27 p.m.
New subject: Running v10
On Tue, 27 Aug 2019 at 12:12, Angelo Papenhoff <aap(a)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.
10:30 p.m.
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(a)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:
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 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 ;)
10:40 p.m.
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(a)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
10:46 p.m.
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(a)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(a)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
10:59 p.m.
New subject: [SPAM] Re: If not Linux, then what?
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(a)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(a)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
11:10 p.m.
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(a)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:
--
Sent from a handheld expect more typos than usual
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(a)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(a)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
11:16 p.m.
On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy <lm(a)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.
11:33 p.m.
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(a)mcvoy.com> wrote:
Larry McVoy writes:
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.
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 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.
28 Aug
28 Aug
12:07 a.m.
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(a)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(a)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:
--
Sent from a handheld expect more typos than usual 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(a)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(a)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
12:21 a.m.
On Tue, 27 Aug 2019 16:33:38 -0700 Larry McVoy <lm(a)mcvoy.com> wrote:
Larry McVoy writes:
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.
On Tue, Aug 27, 2019 at 04:16:18PM -0700, Bakul Shah
wrote:
Hence the link to Presotto and Winterbottom's paper.
On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy
<lm(a)mcvoy.com> wrote:
Larry McVoy writes:
I dunno. I can't look at that and know what it means. So it means I have 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 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.
1:21 a.m.
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.
1:46 a.m.
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.
3:22 a.m.
New subject: [SPAM] Re: If not Linux, then what?
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(a)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(a)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(a)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
3:25 a.m.
New subject: [SPAM] Re: If not Linux, then what?
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(a)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(a)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(a)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(a)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
3:53 a.m.
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(a)kilonet.net> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise, what would we have
now if it wasn't for Linux? Not what you'd WANT it to be, although that can add
to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged kicking and
screaming into the current day and have begrudgingly ceded my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the horror) Windows NT?
I 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(a)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
4:05 a.m.
New subject: [SPAM] Re: If not Linux, then what?
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(a)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(a)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(a)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
4:22 a.m.
New subject: Running v10
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(a)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.
4:30 a.m.
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-anni…
Leaving licensing and copyright issues out of this mental exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
I 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.
6:19 a.m.
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(a)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 >
6:30 a.m.
On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong(a)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
7:34 a.m.
New subject: Running v10
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
9:36 a.m.
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(a)kilonet.net> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
I 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.
9:50 a.m.
On 28 Aug 2019 11:36 +0200, from angus(a)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(a)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)
10:48 a.m.
Michael Kjörling <michael(a)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
11:05 a.m.
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(a)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
11:11 a.m.
On 28 Aug 2019, at 13:05, Jason Stevens <jsteve(a)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
12:46 p.m.
On Wed, Aug 28, 2019, 12:19 AM Wesley Parish <wobblygong(a)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(a)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 >
1:52 p.m.
New subject: [SPAM] Re: If not Linux, then what?
On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy <lm(a)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
1:57 p.m.
On Wed, Aug 28, 2019 at 2:46 AM Peter Jeremy <peter(a)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
2:04 p.m.
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(a)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(a)rulingia.com>
*Sent: *Wednesday, August 28, 2019 2:47 PM
*To: *Wesley Parish <wobblygong(a)gmail.com>
*Cc: *TUHS main list <tuhs(a)minnie.tuhs.org>
*Subject: *Re: [TUHS] If not Linux, then what?
On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong(a)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
2:10 p.m.
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(a)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(a)kilonet.net> wrote:
>
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
>
> Leaving licensing and copyright issues out of this mental exercise, what
> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
> although that can add to the discussion, but what WOULD it be?
>
> I'm not asking as a proponent of Linux. If anything, I was dragged
> kicking and screaming into the current day and have begrudgingly ceded
> my server space to Linux.
>
> But if not for Linux, would it be BSD? A System V variant? Or (the
> horror) Windows NT?
>
> I 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.
>
>
2:22 p.m.
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(a)kilonet.net
<mailto:krewat@kilonet.net>> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise,
what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
I 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(a)technologists.com
fax: +1.512.346.5240 Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer
2:31 p.m.
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(a)mcvoy.com> wrote:
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.
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.
2:55 p.m.
On Wed, Aug 28, 2019 at 10:10 AM Earl Baugh <earl.baugh(a)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.
2:57 p.m.
Could be. I'm not sure I can date it,
On Wed, Aug 28, 2019 at 10:31 AM Larry McVoy <lm(a)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(a)mcvoy.com> wrote:
mess
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 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.
3 p.m.
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.
4:34 p.m.
On Wed, 28 Aug 2019 at 10:05, Clem Cole <clemc(a)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/BovGe3q…
) 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(a)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(a)rulingia.com>
*Sent: *Wednesday, August 28, 2019 2:47 PM
*To: *Wesley Parish <wobblygong(a)gmail.com>
*Cc: *TUHS main list <tuhs(a)minnie.tuhs.org>
*Subject: *Re: [TUHS] If not Linux, then what?
On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong(a)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
4:46 p.m.
New subject: Running v10
On Wed, 28 Aug 2019 at 03:41, Angelo Papenhoff <aap(a)papnet.eu> wrote:
On 28/08/19, Jason Stevens wrote:
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
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.
5:32 p.m.
On Wed, Aug 28, 2019 at 12:34:46PM -0400, Henry Bent wrote:
On Wed, 28 Aug 2019 at 10:05, Clem Cole
<clemc(a)ccc.com> 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.
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. 
5:51 p.m.
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
6:56 p.m.
On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy <lm(a)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
7:54 p.m.
On 2019-Aug-28 11:37:51 -0400, Richard Salz <rich.salz(a)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
8:05 p.m.
On Wed, 28 Aug 2019 at 15:55, Peter Jeremy <peter(a)rulingia.com> wrote:
On 2019-Aug-28 11:37:51 -0400, Richard Salz
<rich.salz(a)gmail.com> wrote:
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?"
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.
8:07 p.m.
On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat(a)kilonet.net> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
I can make a firm "dunno" sound :-)
Some facts can come together to point away from a number of possibilities...
- If you look at the number of hobbyist "Unix homages" that emerged at
around that time, it's clear that there was a sizable community of
interested folk willing to build their own thing, and that weren't
interested in Windows NT. (Nay, one should put that more strongly... That
had their minds set on something NOT from Microsoft.) So I think we can
cross Windows NT off the list.
- OS/2 should briefly come on the list. It was likable in many ways, if
only IBM had actually supported it... But it suffers from something of the
same problem as Windows NT; there were a lot of folk that were only
slightly less despising of IBM at the time than of Microsoft.
- Hurd was imagined to be the next thing...
To borrow from my cookie file...
"Of course 5 years from now that will be different, but 5 years from
now everyone will be running free GNU on their 200 MIPS, 64M
SPARCstation-5." -- Andrew Tanenbaum, 1992.
%
"You'll be rid of most of us when BSD-detox or GNU comes out, which
should happen in the next few months (yeah, right)." -- Richard Tobin,
1992. [BSD did follow within a year]
%
"I am aware of the benefits of a micro kernel approach. However, the
fact remains that Linux is here, and GNU isn't --- and people have
been working on Hurd for a lot longer than Linus has been working on
Linux." -- Ted T'so, 1992.
Ted has been on this thread, and should be amused (and slightly disturbed!)
that his old statements are being held here and there, ready to trot out
:-).
In the absence of Linux, perhaps hackers would have flocked to Hurd, but
there was enough going on that there was plenty of room for them to have
done so anyways.
I'm not sure what to blame on whatever happened post-1992, though I'd put
some on Microsoft Research having taken the wind out of Mach's sails by
hiring off a bunch of the relevant folk. In order for Hurd to "make it,"
Mach has to "make it," too, and it looked like they were depending on CMU
to be behind that. (I'm not sure I'm right about that; happy to hear a
better story.)
Anyway, Hurd *might* have been a "next thing," and I don't think the
popularity of Linux was enough to have completely taken wind out of its
sails, given that there's the dozens of "Unix homages" out there.
- I'd like to imagine Plan 9 being an alternative, but it was "properly
commercial" for a goodly long time (hence not amenable to attaching waves
of hackers to it to add their favorite device drivers), and was never taken
as a serious answer. Many of us had admired it from afar via the Dr Dobbs
Journal issue (when was that? mid or late '90s?) but only from afar.
- FreeBSD is the single best answer I can throw up as a possibility, as it
was the one actively targeting 80386 hardware. And that had the big risk
of the AT&T lawsuit lurking over it, so had that gone in a different
direction, then that is a branch sadly easily trimmed.
If we lop both Linux and FreeBSD off the list of possibilities, I don't
imagine Windows NT or OS/2 bubble to the top, instead, a critical mass
would have stood behind ... something else, I'd think. I don't know which
to suggest.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
8:23 p.m.
On 28 Aug 2019, at 20:57, Clem Cole <clemc(a)ccc.com> wrote:
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
On Wed, Aug
28, 2019 at 1:32 PM Larry McVoy <lm(a)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.
8:27 p.m.
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(a)gmail.com>
wrote:
On Mon, 26 Aug 2019 at 19:14, Arthur Krewat
<krewat(a)kilonet.net> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
I can make a firm "dunno" sound :-)
Some facts can come together to point away from a number of
possibilities...
- If you look at the number of hobbyist "Unix homages" that emerged at
around that time, it's clear that there was a sizable community of
interested folk willing to build their own thing, and that weren't
interested in Windows NT. (Nay, one should put that more strongly... That
had their minds set on something NOT from Microsoft.) So I think we can
cross Windows NT off the list.
- OS/2 should briefly come on the list. It was likable in many ways, if
only IBM had actually supported it... But it suffers from something of the
same problem as Windows NT; there were a lot of folk that were only
slightly less despising of IBM at the time than of Microsoft.
- Hurd was imagined to be the next thing...
To borrow from my cookie file...
"Of course 5 years from now that will be different, but 5 years from
now everyone will be running free GNU on their 200 MIPS, 64M
SPARCstation-5." -- Andrew Tanenbaum, 1992.
%
"You'll be rid of most of us when BSD-detox or GNU comes out, which
should happen in the next few months (yeah, right)." -- Richard Tobin,
1992. [BSD did follow within a year]
%
"I am aware of the benefits of a micro kernel approach. However, the
fact remains that Linux is here, and GNU isn't --- and people have
been working on Hurd for a lot longer than Linus has been working on
Linux." -- Ted T'so, 1992.
Ted has been on this thread, and should be amused (and slightly
disturbed!) that his old statements are being held here and there, ready to
trot out :-).
In the absence of Linux, perhaps hackers would have flocked to Hurd, but
there was enough going on that there was plenty of room for them to have
done so anyways.
I'm not sure what to blame on whatever happened post-1992, though I'd put
some on Microsoft Research having taken the wind out of Mach's sails by
hiring off a bunch of the relevant folk. In order for Hurd to "make it,"
Mach has to "make it," too, and it looked like they were depending on CMU
to be behind that. (I'm not sure I'm right about that; happy to hear a
better story.)
Anyway, Hurd *might* have been a "next thing," and I don't think the
popularity of Linux was enough to have completely taken wind out of its
sails, given that there's the dozens of "Unix homages" out there.
- I'd like to imagine Plan 9 being an alternative, but it was "properly
commercial" for a goodly long time (hence not amenable to attaching waves
of hackers to it to add their favorite device drivers), and was never taken
as a serious answer. Many of us had admired it from afar via the Dr Dobbs
Journal issue (when was that? mid or late '90s?) but only from afar.
- FreeBSD is the single best answer I can throw up as a possibility, as it
was the one actively targeting 80386 hardware. And that had the big risk
of the AT&T lawsuit lurking over it, so had that gone in a different
direction, then that is a branch sadly easily trimmed.
If we lop both Linux and FreeBSD off the list of possibilities, I don't
imagine Windows NT or OS/2 bubble to the top, instead, a critical mass
would have stood behind ... something else, I'd think. I don't know which
to suggest.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
8:56 p.m.
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(a)gmail.com
-----Original Message-----
From: Adam Thornton <athornton(a)gmail.com>
To: The Eunuchs Hysterical Society <tuhs(a)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(a)gmail.com>
wrote:
On Mon, 26 Aug 2019 at 19:14, Arthur Krewat
<krewat(a)kilonet.net> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
I can make a firm "dunno" sound :-)
Some facts can come together to point away from a number of
possibilities...
- If you look at the number of hobbyist "Unix homages" that emerged at
around that time, it's clear that there was a sizable community of
interested folk willing to build their own thing, and that weren't
interested in Windows NT. (Nay, one should put that more strongly... That
had their minds set on something NOT from Microsoft.) So I think we can
cross Windows NT off the list.
- OS/2 should briefly come on the list. It was likable in many ways, if
only IBM had actually supported it... But it suffers from something of the
same problem as Windows NT; there were a lot of folk that were only
slightly less despising of IBM at the time than of Microsoft.
- Hurd was imagined to be the next thing...
To borrow from my cookie file...
"Of course 5 years from now that will be different, but 5 years from
now everyone will be running free GNU on their 200 MIPS, 64M
SPARCstation-5." -- Andrew Tanenbaum, 1992.
%
"You'll be rid of most of us when BSD-detox or GNU comes out, which
should happen in the next few months (yeah, right)." -- Richard Tobin,
1992. [BSD did follow within a year]
%
"I am aware of the benefits of a micro kernel approach. However, the
fact remains that Linux is here, and GNU isn't --- and people have
been working on Hurd for a lot longer than Linus has been working on
Linux." -- Ted T'so, 1992.
Ted has been on this thread, and should be amused (and slightly
disturbed!) that his old statements are being held here and there, ready to
trot out :-).
In the absence of Linux, perhaps hackers would have flocked to Hurd, but
there was enough going on that there was plenty of room for them to have
done so anyways.
I'm not sure what to blame on whatever happened post-1992, though I'd put
some on Microsoft Research having taken the wind out of Mach's sails by
hiring off a bunch of the relevant folk. In order for Hurd to "make it,"
Mach has to "make it," too, and it looked like they were depending on CMU
to be behind that. (I'm not sure I'm right about that; happy to hear a
better story.)
Anyway, Hurd *might* have been a "next thing," and I don't think the
popularity of Linux was enough to have completely taken wind out of its
sails, given that there's the dozens of "Unix homages" out there.
- I'd like to imagine Plan 9 being an alternative, but it was "properly
commercial" for a goodly long time (hence not amenable to attaching waves
of hackers to it to add their favorite device drivers), and was never taken
as a serious answer. Many of us had admired it from afar via the Dr Dobbs
Journal issue (when was that? mid or late '90s?) but only from afar.
- FreeBSD is the single best answer I can throw up as a possibility, as it
was the one actively targeting 80386 hardware. And that had the big risk
of the AT&T lawsuit lurking over it, so had that gone in a different
direction, then that is a branch sadly easily trimmed.
If we lop both Linux and FreeBSD off the list of possibilities, I don't
imagine Windows NT or OS/2 bubble to the top, instead, a critical mass
would have stood behind ... something else, I'd think. I don't know which
to suggest.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
9:02 p.m.
--- Ursprüngliche Nachricht ---
Von: Arthur Krewat <krewat(a)kilonet.net>
Datum: 27.08.2019 01:13:25
An: TUHS main list <tuhs(a)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.
10:24 p.m.
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(a)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(a)gmail.com
-----Original Message-----
From: Adam Thornton <athornton(a)gmail.com>
To: The Eunuchs Hysterical Society <tuhs(a)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(a)gmail.com> wrote:
>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat(a)kilonet.net> wrote:
>
>>
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
>>
>> Leaving licensing and copyright issues out of this mental exercise, what
>> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
>> although that can add to the discussion, but what WOULD it be?
>>
>> I'm not asking as a proponent of Linux. If anything, I was dragged
>> kicking and screaming into the current day and have begrudgingly ceded
>> my server space to Linux.
>>
>> But if not for Linux, would it be BSD? A System V variant? Or (the
>> horror) Windows NT?
>
> I can make a firm "dunno" sound :-)
>
> Some facts can come together to point away from a number of possibilities...
>
> - If you look at the number of hobbyist "Unix homages" that emerged at
around that time, it's clear that there was a sizable community of interested folk
willing to build their own thing, and that weren't interested in Windows NT. (Nay,
one should put that more strongly... That had their minds set on something NOT from
Microsoft.) So I think we can cross Windows NT off the list.
>
> - OS/2 should briefly come on the list. It was likable in many ways, if only IBM had
actually supported it... But it suffers from something of the same problem as Windows NT;
there were a lot of folk that were only slightly less despising of IBM at the time than of
Microsoft.
>
> - Hurd was imagined to be the next thing...
>
> To borrow from my cookie file...
>
> "Of course 5 years from now that will be different, but 5 years from
> now everyone will be running free GNU on their 200 MIPS, 64M
> SPARCstation-5." -- Andrew Tanenbaum, 1992.
> %
> "You'll be rid of most of us when BSD-detox or GNU comes out, which
> should happen in the next few months (yeah, right)." -- Richard Tobin,
> 1992. [BSD did follow within a year]
> %
> "I am aware of the benefits of a micro kernel approach. However, the
> fact remains that Linux is here, and GNU isn't --- and people have
> been working on Hurd for a lot longer than Linus has been working on
> Linux." -- Ted T'so, 1992.
>
> Ted has been on this thread, and should be amused (and slightly disturbed!) that his
old statements are being held here and there, ready to trot out :-).
>
> In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was
enough going on that there was plenty of room for them to have done so anyways.
>
> I'm not sure what to blame on whatever happened post-1992, though I'd put
some on Microsoft Research having taken the wind out of Mach's sails by hiring off a
bunch of the relevant folk. In order for Hurd to "make it," Mach has to
"make it," too, and it looked like they were depending on CMU to be behind that.
(I'm not sure I'm right about that; happy to hear a better story.)
>
> Anyway, Hurd *might* have been a "next thing," and I don't think the
popularity of Linux was enough to have completely taken wind out of its sails, given that
there's the dozens of "Unix homages" out there.
>
> - I'd like to imagine Plan 9 being an alternative, but it was "properly
commercial" for a goodly long time (hence not amenable to attaching waves of hackers
to it to add their favorite device drivers), and was never taken as a serious answer.
Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that? mid or
late '90s?) but only from afar.
>
> - FreeBSD is the single best answer I can throw up as a possibility, as it was the
one actively targeting 80386 hardware. And that had the big risk of the AT&T lawsuit
lurking over it, so had that gone in a different direction, then that is a branch sadly
easily trimmed.
>
> If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine
Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ...
something else, I'd think. I don't know which to suggest.
> --
> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"
10:27 p.m.
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
10:28 p.m.
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(a)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(a)gmail.com> wrote:
>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat(a)kilonet.net> wrote:
>
>>
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
>>
>> Leaving licensing and copyright issues out of this mental exercise, what
>> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
>> although that can add to the discussion, but what WOULD it be?
>>
>> I'm not asking as a proponent of Linux. If anything, I was dragged
>> kicking and screaming into the current day and have begrudgingly ceded
>> my server space to Linux.
>>
>> But if not for Linux, would it be BSD? A System V variant? Or (the
>> horror) Windows NT?
>
> I can make a firm "dunno" sound :-)
>
> Some facts can come together to point away from a number of possibilities...
>
> - If you look at the number of hobbyist "Unix homages" that emerged at
around that time, it's clear that there was a sizable community of interested folk
willing to build their own thing, and that weren't interested in Windows NT. (Nay,
one should put that more strongly... That had their minds set on something NOT from
Microsoft.) So I think we can cross Windows NT off the list.
>
> - OS/2 should briefly come on the list. It was likable in many ways, if only IBM had
actually supported it... But it suffers from something of the same problem as Windows NT;
there were a lot of folk that were only slightly less despising of IBM at the time than of
Microsoft.
>
> - Hurd was imagined to be the next thing...
>
> To borrow from my cookie file...
>
> "Of course 5 years from now that will be different, but 5 years from
> now everyone will be running free GNU on their 200 MIPS, 64M
> SPARCstation-5." -- Andrew Tanenbaum, 1992.
> %
> "You'll be rid of most of us when BSD-detox or GNU comes out, which
> should happen in the next few months (yeah, right)." -- Richard Tobin,
> 1992. [BSD did follow within a year]
> %
> "I am aware of the benefits of a micro kernel approach. However, the
> fact remains that Linux is here, and GNU isn't --- and people have
> been working on Hurd for a lot longer than Linus has been working on
> Linux." -- Ted T'so, 1992.
>
> Ted has been on this thread, and should be amused (and slightly disturbed!) that his
old statements are being held here and there, ready to trot out :-).
>
> In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was
enough going on that there was plenty of room for them to have done so anyways.
>
> I'm not sure what to blame on whatever happened post-1992, though I'd put
some on Microsoft Research having taken the wind out of Mach's sails by hiring off a
bunch of the relevant folk. In order for Hurd to "make it," Mach has to
"make it," too, and it looked like they were depending on CMU to be behind that.
(I'm not sure I'm right about that; happy to hear a better story.)
>
> Anyway, Hurd *might* have been a "next thing," and I don't think the
popularity of Linux was enough to have completely taken wind out of its sails, given that
there's the dozens of "Unix homages" out there.
>
> - I'd like to imagine Plan 9 being an alternative, but it was "properly
commercial" for a goodly long time (hence not amenable to attaching waves of hackers
to it to add their favorite device drivers), and was never taken as a serious answer.
Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that? mid or
late '90s?) but only from afar.
>
> - FreeBSD is the single best answer I can throw up as a possibility, as it was the
one actively targeting 80386 hardware. And that had the big risk of the AT&T lawsuit
lurking over it, so had that gone in a different direction, then that is a branch sadly
easily trimmed.
>
> If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine
Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ...
something else, I'd think. I don't know which to suggest.
> --
> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"
10:48 p.m.
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(a)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(a)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(a)gmail.com>
wrote:
On Mon, 26 Aug 2019 at 19:14, Arthur Krewat
<krewat(a)kilonet.net> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise, what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
I can make a firm "dunno" sound :-)
Some facts can come together to point away from a number of
possibilities...
- If you look at the number of hobbyist "Unix homages" that emerged at
around that time, it's clear that there was a sizable community of
interested folk willing to build their own thing, and that weren't
interested in Windows NT. (Nay, one should put that more strongly... That
had their minds set on something NOT from Microsoft.) So I think we can
cross Windows NT off the list.
- OS/2 should briefly come on the list. It was likable in many ways, if
only IBM had actually supported it... But it suffers from something of the
same problem as Windows NT; there were a lot of folk that were only
slightly less despising of IBM at the time than of Microsoft.
- Hurd was imagined to be the next thing...
To borrow from my cookie file...
"Of course 5 years from now that will be different, but 5 years from
now everyone will be running free GNU on their 200 MIPS, 64M
SPARCstation-5." -- Andrew Tanenbaum, 1992.
%
"You'll be rid of most of us when BSD-detox or GNU comes out, which
should happen in the next few months (yeah, right)." -- Richard Tobin,
1992. [BSD did follow within a year]
%
"I am aware of the benefits of a micro kernel approach. However, the
fact remains that Linux is here, and GNU isn't --- and people have
been working on Hurd for a lot longer than Linus has been working on
Linux." -- Ted T'so, 1992.
Ted has been on this thread, and should be amused (and slightly
disturbed!) that his old statements are being held here and there, ready to
trot out :-).
In the absence of Linux, perhaps hackers would have flocked to Hurd, but
there was enough going on that there was plenty of room for them to have
done so anyways.
I'm not sure what to blame on whatever happened post-1992, though I'd put
some on Microsoft Research having taken the wind out of Mach's sails by
hiring off a bunch of the relevant folk. In order for Hurd to "make it,"
Mach has to "make it," too, and it looked like they were depending on CMU
to be behind that. (I'm not sure I'm right about that; happy to hear a
better story.)
Anyway, Hurd *might* have been a "next thing," and I don't think the
popularity of Linux was enough to have completely taken wind out of its
sails, given that there's the dozens of "Unix homages" out there.
- I'd like to imagine Plan 9 being an alternative, but it was "properly
commercial" for a goodly long time (hence not amenable to attaching waves
of hackers to it to add their favorite device drivers), and was never taken
as a serious answer. Many of us had admired it from afar via the Dr Dobbs
Journal issue (when was that? mid or late '90s?) but only from afar.
- FreeBSD is the single best answer I can throw up as a possibility, as
it was the one actively targeting 80386 hardware. And that had the big
risk of the AT&T lawsuit lurking over it, so had that gone in a different
direction, then that is a branch sadly easily trimmed.
If we lop both Linux and FreeBSD off the list of possibilities, I don't
imagine Windows NT or OS/2 bubble to the top, instead, a critical mass
would have stood behind ... something else, I'd think. I don't know which
to suggest.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
10:53 p.m.
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
11:01 p.m.
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(a)ccc.com
<mailto:clemc@ccc.com>> wrote:
Not true 386BSD used fdisk. It shared the disk just fine. In
fact I liked the way it sliced the disk much better than Slackware
in those days.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but
not quite.
On Aug 28, 2019, at 4:27 PM, Adam Thornton <athornton(a)gmail.com
<mailto:athornton@gmail.com>> wrote:
> I was an ardent OS/2 supporter for a long time. Sure, IBM's
> anemic marketing, and their close-to-outright-hostility to
> 3rd-party developers didn't help. But what killed it, really,
> was how damn good its 16-bit support was. It *was* a better DOS
> than DOS and a better Windows than 3.11fW. So no one wrote to
> the relatively tiny market of 32-bit OS/2.
>
> I fear that had Linux not made the leap, MS might well have won.
> It's largely the AOL-fuelled explosion of popularity of the
> Internet and Windows ignoring same until too late that opened the
> door enough for Linux to jam its foot in.
>
> Hurd was, by the time of the '386 Unix Wars and early Linux,
> clearly not going to be a contender, I guess because it was about
> cool research features rather than running user-facing code. I
> kept waiting for a usable kernel to go with what Linux had
> already shown was a quite decent userspace, but eventually had
> better things to do with my life (like chase BeOS). It was like
> waiting for Perl 6--it missed its moment.
>
> Plan 9 and Amoeba were both really nifty. I never used
> Sprite. Neither one of them had much of a chance in the real
> world. Much like Unix itself, Linux's worse-is-better approach
> really worked.
>
> I have a hypothesis about Linux's ascendance too, which is a
> personal anecdote I am inflating to the status of hypothesis. As
> I recall, the *BSDs for 386 all assumed they owned the hard
> disk. Like, the whole thing. You couldn't, at least in 1992,
> create a multiboot system--or at least it was my strong
> impression you could not. I was an undergrad. I had one '386 at
> my disposal, with one hard disk, and, hey, I needed DOS and
> Windows to write my papers (I don't know about you, but I wanted
> to write in my room, where I could have my references at hand and
> be reasonably undisturbed; sure Framemaker was a much better
> setup than Word For Windows 1.2 but having to use it in the
> computer lab made it a nonstarter for me). Papers, and, well, to
> play games. Sure, that too.
>
> Linux let me defragment my drive, non-destructively repartition
> it, and create a dual-boot system, so that I could both use the
> computer for school and screw around on Linux. I'm probably not
> the only person for whom this was a decisive factor.
>
> Adam
>
> On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne
> <cbbrowne(a)gmail.com <mailto:cbbrowne@gmail.com>> wrote:
>
> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat
> <krewat(a)kilonet.net <mailto:krewat@kilonet.net>> wrote:
>
>
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
>
> Leaving licensing and copyright issues out of this mental
> exercise, what
> would we have now if it wasn't for Linux? Not what you'd
> WANT it to be,
> although that can add to the discussion, but what WOULD
> it be?
>
> I'm not asking as a proponent of Linux. If anything, I
> was dragged
> kicking and screaming into the current day and have
> begrudgingly ceded
> my server space to Linux.
>
> But if not for Linux, would it be BSD? A System V
> variant? Or (the
> horror) Windows NT?
>
>
> I can make a firm "dunno" sound :-)
>
> Some facts can come together to point away from a number of
> possibilities...
>
> - If you look at the number of hobbyist "Unix homages" that
> emerged at around that time, it's clear that there was a
> sizable community of interested folk willing to build their
> own thing, and that weren't interested in Windows NT. (Nay,
> one should put that more strongly... That had their minds
> set on something NOT from Microsoft.) So I think we can
> cross Windows NT off the list.
>
> - OS/2 should briefly come on the list. It was likable in
> many ways, if only IBM had actually supported it... But it
> suffers from something of the same problem as Windows NT;
> there were a lot of folk that were only slightly less
> despising of IBM at the time than of Microsoft.
>
> - Hurd was imagined to be the next thing...
>
> To borrow from my cookie file...
>
> "Of course 5 years from now that will be different, but 5
> years from
> now everyone will be running free GNU on their 200
> MIPS, 64M
> SPARCstation-5." -- Andrew Tanenbaum, 1992.
> %
> "You'll be rid of most of us when BSD-detox or GNU comes
> out, which
> should happen in the next few months (yeah, right)." --
> Richard Tobin,
> 1992. [BSD did follow within a year]
> %
> "I am aware of the benefits of a micro kernel approach.
> However, the
> fact remains that Linux is here, and GNU isn't --- and
> people have
> been working on Hurd for a lot longer than Linus has been
> working on
> Linux." -- Ted T'so, 1992.
>
> Ted has been on this thread, and should be amused (and
> slightly disturbed!) that his old statements are being held
> here and there, ready to trot out :-).
>
> In the absence of Linux, perhaps hackers would have flocked
> to Hurd, but there was enough going on that there was plenty
> of room for them to have done so anyways.
>
> I'm not sure what to blame on whatever happened post-1992,
> though I'd put some on Microsoft Research having taken the
> wind out of Mach's sails by hiring off a bunch of the
> relevant folk. In order for Hurd to "make it," Mach has to
> "make it," too, and it looked like they were depending on CMU
> to be behind that. (I'm not sure I'm right about that; happy
> to hear a better story.)
>
> Anyway, Hurd *might* have been a "next thing," and I don't
> think the popularity of Linux was enough to have completely
> taken wind out of its sails, given that there's the dozens of
> "Unix homages" out there.
>
> - I'd like to imagine Plan 9 being an alternative, but it was
> "properly commercial" for a goodly long time (hence not
> amenable to attaching waves of hackers to it to add their
> favorite device drivers), and was never taken as a serious
> answer. Many of us had admired it from afar via the Dr Dobbs
> Journal issue (when was that? mid or late '90s?) but only
> from afar.
>
> - FreeBSD is the single best answer I can throw up as a
> possibility, as it was the one actively targeting 80386
> hardware. And that had the big risk of the AT&T lawsuit
> lurking over it, so had that gone in a different direction,
> then that is a branch sadly easily trimmed.
>
> If we lop both Linux and FreeBSD off the list of
> possibilities, I don't imagine Windows NT or OS/2 bubble to
> the top, instead, a critical mass would have stood behind ...
> something else, I'd think. I don't know which to suggest.
> --
> When confronted by a difficult problem, solve it by reducing
> it to the
> question, "How would the Lone Ranger handle this?"
>
11:04 p.m.
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(a)gmail.com
"This signature fought the Time Wars, time and again."
On Wed, Aug 28, 2019 at 6:29 PM Clem cole <clemc(a)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(a)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(a)gmail.com> wrote:
>
> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat(a)kilonet.net> wrote:
>>
>>
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
>>
>> Leaving licensing and copyright issues out of this mental exercise, what
>> would we have now if it wasn't for Linux? Not what you'd WANT it to
be,
>> although that can add to the discussion, but what WOULD it be?
>>
>> I'm not asking as a proponent of Linux. If anything, I was dragged
>> kicking and screaming into the current day and have begrudgingly ceded
>> my server space to Linux.
>>
>> But if not for Linux, would it be BSD? A System V variant? Or (the
>> horror) Windows NT?
>
>
> I can make a firm "dunno" sound :-)
>
> Some facts can come together to point away from a number of possibilities...
>
> - If you look at the number of hobbyist "Unix homages" that emerged at
around that time, it's clear that there was a sizable community of interested folk
willing to build their own thing, and that weren't interested in Windows NT. (Nay,
one should put that more strongly... That had their minds set on something NOT from
Microsoft.) So I think we can cross Windows NT off the list.
>
> - OS/2 should briefly come on the list. It was likable in many ways, if only IBM had
actually supported it... But it suffers from something of the same problem as Windows NT;
there were a lot of folk that were only slightly less despising of IBM at the time than of
Microsoft.
>
> - Hurd was imagined to be the next thing...
>
> To borrow from my cookie file...
>
> "Of course 5 years from now that will be different, but 5 years from
> now everyone will be running free GNU on their 200 MIPS, 64M
> SPARCstation-5." -- Andrew Tanenbaum, 1992.
> %
> "You'll be rid of most of us when BSD-detox or GNU comes out, which
> should happen in the next few months (yeah, right)." -- Richard Tobin,
> 1992. [BSD did follow within a year]
> %
> "I am aware of the benefits of a micro kernel approach. However, the
> fact remains that Linux is here, and GNU isn't --- and people have
> been working on Hurd for a lot longer than Linus has been working on
> Linux." -- Ted T'so, 1992.
>
> Ted has been on this thread, and should be amused (and slightly disturbed!) that his
old statements are being held here and there, ready to trot out :-).
>
> In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was
enough going on that there was plenty of room for them to have done so anyways.
>
> I'm not sure what to blame on whatever happened post-1992, though I'd put
some on Microsoft Research having taken the wind out of Mach's sails by hiring off a
bunch of the relevant folk. In order for Hurd to "make it," Mach has to
"make it," too, and it looked like they were depending on CMU to be behind that.
(I'm not sure I'm right about that; happy to hear a better story.)
>
> Anyway, Hurd *might* have been a "next thing," and I don't think the
popularity of Linux was enough to have completely taken wind out of its sails, given that
there's the dozens of "Unix homages" out there.
>
> - I'd like to imagine Plan 9 being an alternative, but it was "properly
commercial" for a goodly long time (hence not amenable to attaching waves of hackers
to it to add their favorite device drivers), and was never taken as a serious answer.
Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that? mid or
late '90s?) but only from afar.
>
> - FreeBSD is the single best answer I can throw up as a possibility, as it was the
one actively targeting 80386 hardware. And that had the big risk of the AT&T lawsuit
lurking over it, so had that gone in a different direction, then that is a branch sadly
easily trimmed.
>
> If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine
Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ...
something else, I'd think. I don't know which to suggest.
> --
> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"
11:09 p.m.
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(a)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(a)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(a)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(a)gmail.com>
wrote:
On Mon, 26 Aug 2019 at 19:14, Arthur Krewat
<krewat(a)kilonet.net> wrote:
https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni…
Leaving licensing and copyright issues out of this mental exercise,
what
would we have now if it wasn't for Linux? Not what you'd WANT it to be,
although that can add to the discussion, but what WOULD it be?
I'm not asking as a proponent of Linux. If anything, I was dragged
kicking and screaming into the current day and have begrudgingly ceded
my server space to Linux.
But if not for Linux, would it be BSD? A System V variant? Or (the
horror) Windows NT?
I can make a firm "dunno" sound :-)
Some facts can come together to point away from a number of
possibilities...
- If you look at the number of hobbyist "Unix homages" that emerged at
around that time, it's clear that there was a sizable community of
interested folk willing to build their own thing, and that weren't
interested in Windows NT. (Nay, one should put that more strongly... That
had their minds set on something NOT from Microsoft.) So I think we can
cross Windows NT off the list.
- OS/2 should briefly come on the list. It was likable in many ways, if
only IBM had actually supported it... But it suffers from something of the
same problem as Windows NT; there were a lot of folk that were only
slightly less despising of IBM at the time than of Microsoft.
- Hurd was imagined to be the next thing...
To borrow from my cookie file...
"Of course 5 years from now that will be different, but 5 years from
now everyone will be running free GNU on their 200 MIPS, 64M
SPARCstation-5." -- Andrew Tanenbaum, 1992.
%
"You'll be rid of most of us when BSD-detox or GNU comes out, which
should happen in the next few months (yeah, right)." -- Richard Tobin,
1992. [BSD did follow within a year]
%
"I am aware of the benefits of a micro kernel approach. However, the
fact remains that Linux is here, and GNU isn't --- and people have
been working on Hurd for a lot longer than Linus has been working on
Linux." -- Ted T'so, 1992.
Ted has been on this thread, and should be amused (and slightly
disturbed!) that his old statements are being held here and there, ready to
trot out :-).
In the absence of Linux, perhaps hackers would have flocked to Hurd, but
there was enough going on that there was plenty of room for them to have
done so anyways.
I'm not sure what to blame on whatever happened post-1992, though I'd
put some on Microsoft Research having taken the wind out of Mach's sails by
hiring off a bunch of the relevant folk. In order for Hurd to "make it,"
Mach has to "make it," too, and it looked like they were depending on CMU
to be behind that. (I'm not sure I'm right about that; happy to hear a
better story.)
Anyway, Hurd *might* have been a "next thing," and I don't think the
popularity of Linux was enough to have completely taken wind out of its
sails, given that there's the dozens of "Unix homages" out there.
- I'd like to imagine Plan 9 being an alternative, but it was "properly
commercial" for a goodly long time (hence not amenable to attaching waves
of hackers to it to add their favorite device drivers), and was never taken
as a serious answer. Many of us had admired it from afar via the Dr Dobbs
Journal issue (when was that? mid or late '90s?) but only from afar.
- FreeBSD is the single best answer I can throw up as a possibility, as
it was the one actively targeting 80386 hardware. And that had the big
risk of the AT&T lawsuit lurking over it, so had that gone in a different
direction, then that is a branch sadly easily trimmed.
If we lop both Linux and FreeBSD off the list of possibilities, I don't
imagine Windows NT or OS/2 bubble to the top, instead, a critical mass
would have stood behind ... something else, I'd think. I don't know which
to suggest.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
11:19 p.m.
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/featu…
That's probably one of the other things that may have hampered BSD.
The BSD license made it easier (or at least made easier business
models) for monetizing BSD, and some of the most talented people went
off to make a buck off of BSD. BSDI, Sun, NetApp, Wasabi Systems, etc.
Nothing wrong with that of course, and if people like Bill Joy were
able to make bank based on BSD, more power to them. But it probably
removed from the leadership pool people who might have had better
leadership, and technical architect skills who might have led one of
the *BSD's to greater success.
The GPL makes it harder to monetize Linux --- although, as we've seen,
certainly not impossible --- and if you take a look at the most of the
senior technical people at Linux, none of us have made off as well as,
say, Bill Joy. I'm still a working stiff, and don't have enough to
retire. (That's OK; I'm perfectly happy being part of the 99%. :-)
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
29 Aug
29 Aug
3:24 a.m.
On 2019, Aug 28, at 2:56 PM, Clem Cole
<clemc(a)ccc.com> wrote:
On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy <lm(a)mcvoy.com
<mailto:lm@mcvoy.com>> wrote:
Perhaps Clem can shed some light on why DEC did a MIPS machine?
I did not work for DEC at the time and obviously, I was not in the room, so this is what
I can say I picked up. Supnik would be a better person to ask. That said, some things I
do know about the time/and behinds the scene.
Jupiter and Prism had been canceled.
Alpha did not yet exist (and would not for another 2 years)
Cutler had left for Microsoft etc..
Sun was clearly on its game
The VAX on a Chip just was not cutting it
RISC architectures were the hot item
Here is where I get fuzzy on details.
I believe a prototype (i.e. skunk works) MIPS was running at WRL in Palo Alto running
Ultrix and DEC windows, I think using some sort of cheap ??PC?? chassis.
But the performance of the prototype was excellent and cost was cheaper than the current
vax products.
Somebody sr, maybe Bob, shows this to Sr management and got the money to productize it.
The issue as making an official Ultrix for it was I know a big one. Ultimately, DEC
farmed that work out to us at LCC (with us eventually taking over all of Ultrix - MIPS and
Vax).
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
6:37 a.m.
On 8/29/19, William Pechter <pechter(a)gmail.com> wrote:
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>
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 
10:55 a.m.
Lawrence Stewart <stewart(a)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(a)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.
11:12 a.m.
Adam Thornton <athornton(a)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(a)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.
1:31 p.m.
On Wed, Aug 28, 2019 at 7:20 PM Theodore Y. Ts'o <tytso(a)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-…
I'm not making any judgments, good or bad. It is what it is.
1:55 p.m.
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(a)mit.edu> wrote:
<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 ;)
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-…
I'm not making any judgments, good or bad. It is what it is.
6:40 p.m.
On 08/28/19 18:27, William Pechter wrote (in part):
On 8/28/2019 4:27 PM, Adam Thornton wrote:
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.
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. 
7:18 p.m.
Nemo Nusquam wrote in <8cb953ef-ef6d-fdfa-76a4-1074cf46f598(a)gmail.com>om>:
|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)
7:19 p.m.
Thomas Paulsen wrote in <004ec49789583b190ca7c302db9fbb31(a)firemail.de>de>:
|>: Arthur Krewat <krewat(a)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)
31 Aug
31 Aug
1:35 a.m.
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
3:14 p.m.
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)
4:58 p.m.
On Wed, 28 Aug 2019 at 19:19, Theodore Y. Ts'o <tytso(a)mit.edu> wrote:
On Wed, Aug 28, 2019 at 04:07:39PM -0400, Christopher
Browne wrote:
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.
- 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/featu…
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%. :-)
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?"
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
9:20 p.m.
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_bushnel…
[3]
https://www.ghacks.net/2018/01/24/google-switches-from-ubuntu-to-debian-as-…
- Ted
1697
days inactive
1702
days old
95 comments
36 participants
participants (36)
-
A. P. Garcia -
Adam Thornton -
Angelo Papenhoff -
Angus Robinson -
arnold＠skeeve.com -
Arrigo Triulzi -
Arthur Krewat -
Bakul Shah -
Charles H Sauer -
Charles H. Sauer
-
Christopher Browne -
Clem Cole -
Clem cole
-
Dan Cross -
Dave Horsfall -
Earl Baugh -
George Michaelson -
Gregg Levine -
Henry Bent -
Jason Stevens -
Jon Forrest -
Larry McVoy -
Lawrence Stewart -
Michael Kjörling -
Nemo Nusquam -
Peter Jeremy -
Richard Salz -
Rob Pike -
Steffen Nurpmeso -
Steve Nickolas -
Theodore Y. Ts'o -
Thomas Paulsen -
Tony Finch -
Warner Losh -
Wesley Parish -
William Pechter