* Re: [TUHS] SunOS code? @ 2018-08-30 19:41 Noel Chiappa 2018-08-30 19:46 ` Larry McVoy ` (3 more replies) 0 siblings, 4 replies; 73+ messages in thread From: Noel Chiappa @ 2018-08-30 19:41 UTC (permalink / raw) To: tuhs; +Cc: jnc > From: Clem Cole > The problem is finding some at Oracle that would care Well, I've got a nephew who's been at Oracle for like 20+ years; he can probably point us at the right person. > and finding a proper distribution tape to officially release. Why do we need that? Can't they say 'any and all versions of SunOS', and that term ('SunOS') is sufficiently well defined in real-world documents (e.g. Sun licenses) that that should be 'good enough'. It sounds like the _actual code_ is reasonably available, we wouldn't need Oracle to go looking around for it, would we? Noel ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 19:41 [TUHS] SunOS code? Noel Chiappa @ 2018-08-30 19:46 ` Larry McVoy 2018-08-30 20:04 ` Warner Losh ` (2 subsequent siblings) 3 siblings, 0 replies; 73+ messages in thread From: Larry McVoy @ 2018-08-30 19:46 UTC (permalink / raw) To: Noel Chiappa; +Cc: tuhs On Thu, Aug 30, 2018 at 03:41:06PM -0400, Noel Chiappa wrote: > It sounds like the _actual code_ is reasonably available, we wouldn't need > Oracle to go looking around for it, would we? I'd really like the SCCS history. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 19:41 [TUHS] SunOS code? Noel Chiappa 2018-08-30 19:46 ` Larry McVoy @ 2018-08-30 20:04 ` Warner Losh 2018-08-30 20:22 ` Larry McVoy 2018-08-30 20:37 ` Clem Cole 2018-08-31 5:49 ` Lars Brinkhoff 3 siblings, 1 reply; 73+ messages in thread From: Warner Losh @ 2018-08-30 20:04 UTC (permalink / raw) To: Noel Chiappa; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1617 bytes --] On Thu, Aug 30, 2018 at 1:41 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > > and finding a proper distribution tape to officially release. > > Why do we need that? Can't they say 'any and all versions of SunOS', and > that > term ('SunOS') is sufficiently well defined in real-world documents (e.g. > Sun > licenses) that that should be 'good enough'. > > It sounds like the _actual code_ is reasonably available, we wouldn't need > Oracle to go looking around for it, would we? > The trouble, as I was given to understand when I worked at Solbourne, was that SunOS wasn't just AT&T + BSD 4.2 + 4.3 + awesome hacking at SMI. There were a number of third party bits and pieces in there that could not be relicensed, even 28 years ago when things were fresh. Good luck getting those third party permissions now... Sun's paid-up Unix license they did for Solaris would cover any bits of AT&T code that was in there. A quick grep of something that fell off an http server suggests that the number of these is quite limited. However, the files they are on have no other license, even though latter-day versions are available of hack, hunt, indent and pax are available (though to be fair, the latter two do give permission explicitly, and a good case can be made for hunt). I have no way of knowing, however, if there are other IP issues, not limited to unmarked sources, copyright notices that aren't 'well formed', code that's been hacked by third parties under a contract granting them copyright ownership and sun just a license, etc. It's that quagmire that efforts like this will run up against. Warner [-- Attachment #2: Type: text/html, Size: 2035 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 20:04 ` Warner Losh @ 2018-08-30 20:22 ` Larry McVoy 2018-08-30 20:33 ` Clem Cole 2018-08-30 20:38 ` Warner Losh 0 siblings, 2 replies; 73+ messages in thread From: Larry McVoy @ 2018-08-30 20:22 UTC (permalink / raw) To: Warner Losh; +Cc: TUHS main list, Noel Chiappa On Thu, Aug 30, 2018 at 02:04:10PM -0600, Warner Losh wrote: > On Thu, Aug 30, 2018 at 1:41 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> > wrote: > > > > and finding a proper distribution tape to officially release. > > > > Why do we need that? Can't they say 'any and all versions of SunOS', and > > that > > term ('SunOS') is sufficiently well defined in real-world documents (e.g. > > Sun > > licenses) that that should be 'good enough'. > > > > It sounds like the _actual code_ is reasonably available, we wouldn't need > > Oracle to go looking around for it, would we? > > > > The trouble, as I was given to understand when I worked at Solbourne, was > that SunOS wasn't just AT&T + BSD 4.2 + 4.3 + awesome hacking at SMI. > There were a number of third party bits and pieces in there that could not > be relicensed, even 28 years ago when things were fresh. So I've been down this path, it was STREAMS and RFS, and maybe a couple of drivers. I pulled all that crud out, put back the BSD tty code, and I had a SunOS we could have given away. It was back when I was writing this: http://mcvoy.com/lm/bitmover/lm/papers/freeos.pdf and I needed to be able to show that what I was asking for was possible. > A quick grep of something that fell off an http server suggests that the > number of these is quite limited. However, the files they are on have no > other license, even though latter-day versions are available of hack, hunt, > indent and pax are available (though to be fair, the latter two do give > permission explicitly, and a good case can be made for hunt). So you are including userland. I'm not sure you need to. Yeah, there was some unicode work done there but quite frankly, I'd just have /usr/gnu/bin /usr/bsd/bin /usr/sun/bin and dump anything questionable in sun/bin. It's the kernel that was the most interesting, next would be the run time loader and shared libraries. /usr/bin wasn't that exciting, the BSD purists might want that but I gotta believe that BSD has caught up to Sun in 25 years (right???). ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 20:22 ` Larry McVoy @ 2018-08-30 20:33 ` Clem Cole 2018-08-30 20:36 ` Larry McVoy 2018-08-30 20:38 ` Warner Losh 1 sibling, 1 reply; 73+ messages in thread From: Clem Cole @ 2018-08-30 20:33 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list, Noel Chiappa [-- Attachment #1: Type: text/plain, Size: 1001 bytes --] On Thu, Aug 30, 2018 at 4:22 PM Larry McVoy <lm@mcvoy.com> wrote: > > > So I've been down this path, it was STREAMS and RFS, and maybe a couple > of drivers. I pulled all that crud out, put back the BSD tty code, > and I had a SunOS we could have given away. It was back when I was > writing this: > > http://mcvoy.com/lm/bitmover/lm/papers/freeos.pdf > > and I needed to be able to show that what I was asking for was possible. > Good to know you think it was possible. I know in the case of Ultrix and HP-UX lots of external folks licenses small things like Mentat, MIPS etc. For instance, one of the Ultrix and Alpha bug-a-boos was the MIPS compiler, which leaked into the IP stream along the way. As far as I remember from my Locus days when we had just about everybody's sources from IBM to Sun, the problem was the license was not just the OEM and AT&T, there was always the sub-licenses from some deal or another that the OEM had cut at some point. Clem ᐧ [-- Attachment #2: Type: text/html, Size: 1994 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 20:33 ` Clem Cole @ 2018-08-30 20:36 ` Larry McVoy 2018-08-30 20:40 ` Clem Cole 0 siblings, 1 reply; 73+ messages in thread From: Larry McVoy @ 2018-08-30 20:36 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list, Noel Chiappa On Thu, Aug 30, 2018 at 04:33:06PM -0400, Clem Cole wrote: > On Thu, Aug 30, 2018 at 4:22 PM Larry McVoy <lm@mcvoy.com> wrote: > > So I've been down this path, it was STREAMS and RFS, and maybe a couple > > of drivers. I pulled all that crud out, put back the BSD tty code, > > and I had a SunOS we could have given away. It was back when I was > > writing this: > > > > http://mcvoy.com/lm/bitmover/lm/papers/freeos.pdf > > > > and I needed to be able to show that what I was asking for was possible. > > Good to know you think it was possible. I know in the case of Ultrix and > HP-UX lots of external folks licenses small things like Mentat, MIPS etc. At this point, Linux has won, I don't think anyone would care if we got the whole pile. As Rob Gingell once said "Bits rot. Unmaintained source quickly becomes worthless". ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 20:36 ` Larry McVoy @ 2018-08-30 20:40 ` Clem Cole 2018-08-30 20:43 ` Larry McVoy 0 siblings, 1 reply; 73+ messages in thread From: Clem Cole @ 2018-08-30 20:40 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list, Noel Chiappa [-- Attachment #1: Type: text/plain, Size: 447 bytes --] On Thu, Aug 30, 2018 at 4:36 PM Larry McVoy <lm@mcvoy.com> wrote: > > As Rob Gingell once said "Bits rot. Unmaintained source quickly becomes > worthless". > Yep. So the question goes back to what is SunOS 4.x.y. You seem to be thinking in terms of looking at the kernel from those days (which is a fine definition), but others said - hey I want to run this on my X or Y system. That's a different definition I think. Clem ᐧ [-- Attachment #2: Type: text/html, Size: 1377 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 20:40 ` Clem Cole @ 2018-08-30 20:43 ` Larry McVoy 0 siblings, 0 replies; 73+ messages in thread From: Larry McVoy @ 2018-08-30 20:43 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list, Noel Chiappa On Thu, Aug 30, 2018 at 04:40:49PM -0400, Clem Cole wrote: > On Thu, Aug 30, 2018 at 4:36 PM Larry McVoy <lm@mcvoy.com> wrote: > > > > > As Rob Gingell once said "Bits rot. Unmaintained source quickly becomes > > worthless". > > > Yep. So the question goes back to what is SunOS 4.x.y. You seem to be > thinking in terms of looking at the kernel from those days (which is a fine > definition), but others said - hey I want to run this on my X or Y system. > That's a different definition I think. I suspect that if SunOS got any traction it would be the kernel plus maybe their shared libs and the Linux user space. And it would need to be ported to x86_64. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 20:22 ` Larry McVoy 2018-08-30 20:33 ` Clem Cole @ 2018-08-30 20:38 ` Warner Losh 2018-08-30 20:42 ` Larry McVoy 1 sibling, 1 reply; 73+ messages in thread From: Warner Losh @ 2018-08-30 20:38 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list, Noel Chiappa [-- Attachment #1: Type: text/plain, Size: 2326 bytes --] On Thu, Aug 30, 2018 at 2:22 PM Larry McVoy <lm@mcvoy.com> wrote: > On Thu, Aug 30, 2018 at 02:04:10PM -0600, Warner Losh wrote: > > On Thu, Aug 30, 2018 at 1:41 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> > > wrote: > > > > > > and finding a proper distribution tape to officially release. > > > > > > Why do we need that? Can't they say 'any and all versions of SunOS', > and > > > that > > > term ('SunOS') is sufficiently well defined in real-world documents > (e.g. > > > Sun > > > licenses) that that should be 'good enough'. > > > > > > It sounds like the _actual code_ is reasonably available, we wouldn't > need > > > Oracle to go looking around for it, would we? > > > > > > > The trouble, as I was given to understand when I worked at Solbourne, was > > that SunOS wasn't just AT&T + BSD 4.2 + 4.3 + awesome hacking at SMI. > > There were a number of third party bits and pieces in there that could > not > > be relicensed, even 28 years ago when things were fresh. > > So I've been down this path, it was STREAMS and RFS, and maybe a couple > of drivers. I pulled all that crud out, put back the BSD tty code, > and I had a SunOS we could have given away. Why would STREAMS and RFS be a problem post OpenSolaris? > It was back when I was > writing this: > > http://mcvoy.com/lm/bitmover/lm/papers/freeos.pdf > > and I needed to be able to show that what I was asking for was possible. > > > A quick grep of something that fell off an http server suggests that the > > number of these is quite limited. However, the files they are on have no > > other license, even though latter-day versions are available of hack, > hunt, > > indent and pax are available (though to be fair, the latter two do give > > permission explicitly, and a good case can be made for hunt). > > So you are including userland. I'm not sure you need to. Yeah, there was > some unicode work done there but quite frankly, I'd just have > > /usr/gnu/bin > /usr/bsd/bin > /usr/sun/bin > > and dump anything questionable in sun/bin. It's the kernel that was the > most interesting, next would be the run time loader and shared libraries. > /usr/bin wasn't that exciting, the BSD purists might want that but I gotta > believe that BSD has caught up to Sun in 25 years (right???). > grep -r was easy :). Warner [-- Attachment #2: Type: text/html, Size: 3254 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 20:38 ` Warner Losh @ 2018-08-30 20:42 ` Larry McVoy 2018-08-30 20:43 ` Clem Cole 0 siblings, 1 reply; 73+ messages in thread From: Larry McVoy @ 2018-08-30 20:42 UTC (permalink / raw) To: Warner Losh; +Cc: TUHS main list, Noel Chiappa On Thu, Aug 30, 2018 at 02:38:39PM -0600, Warner Losh wrote: > > I pulled all that crud out, put back the BSD tty code, > > and I had a SunOS we could have given away. > > Why would STREAMS and RFS be a problem post OpenSolaris? That was then, this is now. Back then they were definitely a problem. I nuked all the AT&T Sys V stuff in the kernel because that had perceived value to AT&T, they still thought Sys V was going to rule the world. So I took us back to BSD + Sun's work. Which was a more pleasant place anyway IMO. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 20:42 ` Larry McVoy @ 2018-08-30 20:43 ` Clem Cole 0 siblings, 0 replies; 73+ messages in thread From: Clem Cole @ 2018-08-30 20:43 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list, Noel Chiappa [-- Attachment #1: Type: text/plain, Size: 208 bytes --] On Thu, Aug 30, 2018 at 4:42 PM Larry McVoy <lm@mcvoy.com> wrote: > > So I took us back to BSD + Sun's work. Which was a more pleasant place > anyway IMO. > Certainly easier to understand ;-) ᐧ [-- Attachment #2: Type: text/html, Size: 1021 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 19:41 [TUHS] SunOS code? Noel Chiappa 2018-08-30 19:46 ` Larry McVoy 2018-08-30 20:04 ` Warner Losh @ 2018-08-30 20:37 ` Clem Cole 2018-08-31 5:49 ` Lars Brinkhoff 3 siblings, 0 replies; 73+ messages in thread From: Clem Cole @ 2018-08-30 20:37 UTC (permalink / raw) To: Noel Chiappa; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1116 bytes --] below... On Thu, Aug 30, 2018 at 3:41 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > > From: Clem Cole > > > The problem is finding some at Oracle that would care > > Well, I've got a nephew who's been at Oracle for like 20+ years; he can > probably point us at the right person. > > > and finding a proper distribution tape to officially release. > > Why do we need that? Can't they say 'any and all versions of SunOS', and > that > term ('SunOS') is sufficiently well defined in real-world documents (e.g. > Sun > licenses) that that should be 'good enough'. > > Two issues: 1.) what consitutes release X or Y and 2) sublicenses. For the former, Sun did have source distributions, typically for Universities and certain OEMs. Stellar had a 4.x license for the Sun3s but I can not tell you which one (we used Sun3's as the porting base and wanted the basic Sun3 support from SunOS to support it as we developed Stellix). For the later, we need to make sure you have the whole thing. Most OEM's had stuff from other firms, from compilers to whole subsystems. ᐧ [-- Attachment #2: Type: text/html, Size: 2210 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 19:41 [TUHS] SunOS code? Noel Chiappa ` (2 preceding siblings ...) 2018-08-30 20:37 ` Clem Cole @ 2018-08-31 5:49 ` Lars Brinkhoff 2018-08-31 9:50 ` Dave Horsfall 3 siblings, 1 reply; 73+ messages in thread From: Lars Brinkhoff @ 2018-08-31 5:49 UTC (permalink / raw) To: tuhs I have something called sunos-414-source.tar.gz. It expands to a solaris_112 directory. There are sources for kernel, etc, bin ucb, 5bin, usr.bin... Looks to be sun4 only, no 68k. No version history. Free to a good home. (I sent a copy to Kossow years ago.) ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 5:49 ` Lars Brinkhoff @ 2018-08-31 9:50 ` Dave Horsfall 2018-08-31 11:01 ` Gregg Levine 0 siblings, 1 reply; 73+ messages in thread From: Dave Horsfall @ 2018-08-31 9:50 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Fri, 31 Aug 2018, Lars Brinkhoff wrote: > I have something called sunos-414-source.tar.gz. It expands to a > solaris_112 directory. There are sources for kernel, etc, bin ucb, > 5bin, usr.bin... Looks to be sun4 only, no 68k. No version history. > > Free to a good home. (I sent a copy to Kossow years ago.) Umm, this message is a bit confusing... Is it a single physical medium that you happened to have, or software that you are willing to distribute upon some sort of an agreement, or what? At the very least, it ought to find its way into Warren's hands... -- Dave ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 9:50 ` Dave Horsfall @ 2018-08-31 11:01 ` Gregg Levine 2018-08-31 11:05 ` Lars Brinkhoff 0 siblings, 1 reply; 73+ messages in thread From: Gregg Levine @ 2018-08-31 11:01 UTC (permalink / raw) To: Tuhs Hello! Of course I am interested. I am as they say, always interested. But I also agree with Dave there as well. A copy should be delivered to Warren. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again." On Fri, Aug 31, 2018 at 5:50 AM, Dave Horsfall <dave@horsfall.org> wrote: > On Fri, 31 Aug 2018, Lars Brinkhoff wrote: > >> I have something called sunos-414-source.tar.gz. It expands to a >> solaris_112 directory. There are sources for kernel, etc, bin ucb, 5bin, >> usr.bin... Looks to be sun4 only, no 68k. No version history. >> >> Free to a good home. (I sent a copy to Kossow years ago.) > > > Umm, this message is a bit confusing... Is it a single physical medium that > you happened to have, or software that you are willing to distribute upon > some sort of an agreement, or what? > > At the very least, it ought to find its way into Warren's hands... > > -- Dave ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 11:01 ` Gregg Levine @ 2018-08-31 11:05 ` Lars Brinkhoff 0 siblings, 0 replies; 73+ messages in thread From: Lars Brinkhoff @ 2018-08-31 11:05 UTC (permalink / raw) To: Gregg Levine; +Cc: Tuhs > Hello! > Of course I am interested. I am as they say, always interested. But I > also agree with Dave there as well. A copy should be delivered to > Warren. Ok, sounds great! ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? @ 2018-09-04 17:58 Noel Chiappa 2018-09-06 0:39 ` Dave Horsfall 0 siblings, 1 reply; 73+ messages in thread From: Noel Chiappa @ 2018-09-04 17:58 UTC (permalink / raw) To: tuhs; +Cc: jnc > From: Henry Bent > just because you can find source (or binaries, or CD images, etc.) on > the internet, that doesn't make it the least bit legal. ... The concept > of "abandonware" has no legal footing whatsoever. True; but if all the copies of a particular item are discarded, one can make all the lawyers on the planet as happy as clams, and it won't do a bit of good. Save the bits, _then_ work out the legal issues, is my thinking on priorities. Noel (PS: 'Internet' is spelled with a capital; there are many internets, but only one Internet, just as there are many white houses, but only one White House. If the technical community, which _does_ understand the difference, can't get it's act together, how can we expect the media, etc, to do the right thing?) ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-04 17:58 Noel Chiappa @ 2018-09-06 0:39 ` Dave Horsfall 0 siblings, 0 replies; 73+ messages in thread From: Dave Horsfall @ 2018-09-06 0:39 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Tue, 4 Sep 2018, Noel Chiappa wrote: > (PS: 'Internet' is spelled with a capital; there are many internets, but > only one Internet, just as there are many white houses, but only one > White House. If the technical community, which _does_ understand the > difference, can't get it's act together, how can we expect the media, > etc, to do the right thing?) Thank you. Thank you. Thank you. At every technical lecture I do, I insist upon Internet, but the younger generation these days think that they invented it because of Google browsing etc. -- Dave, in a grouchy mood having having three teeth pulled out ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? @ 2018-08-30 21:34 Noel Chiappa 2018-08-31 1:59 ` Kevin Bowling 0 siblings, 1 reply; 73+ messages in thread From: Noel Chiappa @ 2018-08-30 21:34 UTC (permalink / raw) To: tuhs; +Cc: jnc > From: Warner Losh > The trouble, as I was given to understand when I worked at Solbourne, > was that ... There were a number of third party bits and pieces in there > that could not be relicensed ... if there are other IP issues, not > limited ... It's that quagmire that efforts like this will run up > against. Oh, we'll just ask Oracle for a license 'for all parts of SunOS for which they have the ability to grant a licence'. There's no way I'd want them to have to chase down all the corner cases, that's just a way to guarantee it will never happen. I'd want to ask for the bare minimum of time/effort on their part. Anything above that, probably the SCCS stuff would be next on the priority list, sounds like. Noel ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 21:34 Noel Chiappa @ 2018-08-31 1:59 ` Kevin Bowling 2018-08-31 21:34 ` Cág 0 siblings, 1 reply; 73+ messages in thread From: Kevin Bowling @ 2018-08-31 1:59 UTC (permalink / raw) To: Noel Chiappa; +Cc: TUHS main list The effects of copyright on abandonware have been discussed pretty widely in other communities. The primary issue is the contracts and right don't simply expire and it's rare for a company to completely shutter (i.e. assets including these copyrights are acquired or given to creditors). Oracle would need to establish that they have providence over the files and code, and that exceptions for Novel and other code were covered by the OpenSolaris rights reviews. I imagine it might cost low hundreds of thousands of dollars to do lawyers being what they are and commercial *nix being such a melting pot of sources. Since there is no conceivable revenue stream and Oracle isn't much for goodwill I am highly skeptical. Sun releasing OpenSolaris when they finally did and under the CDDL was pretty tone deaf to what was going on in the market with Linux, but you have to admire the amount of contract review and legal work that must have taken. Regards, Kevin On Thu, Aug 30, 2018 at 2:34 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > > From: Warner Losh > > > The trouble, as I was given to understand when I worked at Solbourne, > > was that ... There were a number of third party bits and pieces in there > > that could not be relicensed ... if there are other IP issues, not > > limited ... It's that quagmire that efforts like this will run up > > against. > > Oh, we'll just ask Oracle for a license 'for all parts of SunOS for which they > have the ability to grant a licence'. > > There's no way I'd want them to have to chase down all the corner cases, > that's just a way to guarantee it will never happen. I'd want to ask for the > bare minimum of time/effort on their part. > > Anything above that, probably the SCCS stuff would be next on the priority > list, sounds like. > > Noel ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 1:59 ` Kevin Bowling @ 2018-08-31 21:34 ` Cág 2018-08-31 21:39 ` Clem Cole ` (2 more replies) 0 siblings, 3 replies; 73+ messages in thread From: Cág @ 2018-08-31 21:34 UTC (permalink / raw) To: TUHS main list Kevin Bowling wrote: > Sun releasing OpenSolaris when they finally did and under the CDDL was > pretty tone deaf to what was going on in the market with Linux, but > you have to admire the amount of contract review and legal work that > must have taken. How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway? Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is community- -supported, and another is commercially. -- caóc ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 21:34 ` Cág @ 2018-08-31 21:39 ` Clem Cole 2018-08-31 21:47 ` Arthur Krewat 2018-08-31 21:57 ` Warner Losh 2018-08-31 21:58 ` Larry McVoy 2 siblings, 1 reply; 73+ messages in thread From: Clem Cole @ 2018-08-31 21:39 UTC (permalink / raw) To: TUHS main list, Cág [-- Attachment #1: Type: text/plain, Size: 472 bytes --] On Fri, Aug 31, 2018 at 5:36 PM Cág <ca6c@bitmessage.ch> wrote: > How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway? > Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is > community--supported, and another is commercially. > Yikes -- this is like Rolls Royce cutting a deal with GM and produce a new car based on the Chevy Sububuran, painting it, adding a few details and calling it a Silver Ghost. SunOS != is not Solaris ᐧ [-- Attachment #2: Type: text/html, Size: 1301 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 21:39 ` Clem Cole @ 2018-08-31 21:47 ` Arthur Krewat 0 siblings, 0 replies; 73+ messages in thread From: Arthur Krewat @ 2018-08-31 21:47 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 289 bytes --] On 8/31/2018 5:39 PM, Clem Cole wrote: > SunOS != is not Solaris > > ᐧ Confusion may arise because the last released SunOS 4.1.4 was called "Solaris 1.1.2". Solaris nor SunOS were ever "community supported" although one could make the case that SunOS was more generally liked ;) [-- Attachment #2: Type: text/html, Size: 1183 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 21:34 ` Cág 2018-08-31 21:39 ` Clem Cole @ 2018-08-31 21:57 ` Warner Losh 2018-08-31 21:58 ` Larry McVoy 2 siblings, 0 replies; 73+ messages in thread From: Warner Losh @ 2018-08-31 21:57 UTC (permalink / raw) To: TUHS main list, ca6c [-- Attachment #1: Type: text/plain, Size: 940 bytes --] On Fri, Aug 31, 2018 at 3:36 PM Cág <ca6c@bitmessage.ch> wrote: > Kevin Bowling wrote: > > > Sun releasing OpenSolaris when they finally did and under the CDDL was > > pretty tone deaf to what was going on in the market with Linux, but > > you have to admire the amount of contract review and legal work that > > must have taken. > > How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway? > Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is community- > -supported, and another is commercially. > No. Not even close. SunOS is BSD based (first 4.2 then 4.3 then with some small amount of System V code) with a written from scratch vm. Solaris is sun's do-over based on System V Release 4. It's great leap backwards. It was a huge slap in the face of the old SunOS crew by inept management. The final indignity was SunOS 4.1 being rebranded Solaris 1.0, which was pure marketing... Warner [-- Attachment #2: Type: text/html, Size: 1313 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 21:34 ` Cág 2018-08-31 21:39 ` Clem Cole 2018-08-31 21:57 ` Warner Losh @ 2018-08-31 21:58 ` Larry McVoy 2018-08-31 22:02 ` Warner Losh ` (3 more replies) 2 siblings, 4 replies; 73+ messages in thread From: Larry McVoy @ 2018-08-31 21:58 UTC (permalink / raw) To: TUHS main list, C??g On Fri, Aug 31, 2018 at 04:34:51PM -0500, C??g wrote: > Kevin Bowling wrote: > > > Sun releasing OpenSolaris when they finally did and under the CDDL was > > pretty tone deaf to what was going on in the market with Linux, but > > you have to admire the amount of contract review and legal work that > > must have taken. > > How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway? > Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is community- > -supported, and another is commercially. SunOS was based on the BSD code, the entire system was frequently described as "a bug fixed BSD". It was, of course, a lot more than that, Sun dis shared libs, a new (much, much better) VM system, invented the vnode interface that virtualized file systems, BSD had none of that. Lots of Usenix papers describing that work here: SunOS felt very much like BSD, all the stuff you thought would work, usually did, the user space was very BSD like. http://mcvoy.com/lm/papers/ Solaris was Sys Vr4 (which, if I recall correctly, differed from r3 largely due to some stuff being ported over from SunOS). Both the kernel and user space went to a Sys V compat system, it no longer felt anything like BSD. So why would Sun take something that everyone loved and replace it with that steaming pile of Sys V garbage? Only the top execs actually knew the real reason, I'm 99% sure my boss, Ken Okin (VP of all server hardware), did not know the real reason. Which was, Sun was in some financial trouble, I don't know the details, but AT&T bought $200M of Sun stock at 35% over market to bail them out. In return, Sun had to drop SunOS and go with Sys V. AT&T was betting that Sun would make Sys V as popular as SunOS. Didn't happen. Not even close. A lot of people just bailed, trying to work with Sys V was miserable. It put us backwards at least 10 years and I'd argue more than that. The engineers loved SunOS and tons of work got done on the system that management never asked for, the engineers really drove the agenda. When all that work was yanked away, it took the heart out of engineering. A bunch of people stuck around and tried, they really did and I applaud them for it but the damage was done. I was gone by the time ZFS came out so I have no idea how that passed through the formal vetting process that Sun had in place. When I was there, if I had proposed a file system that wouldn't use the page cache, you'd have to copy from the buffer cache into the page cache to get mmap to work, I would have been kicked out of the room and probably kicked out of the kernel group. We had spent SO FRIGGING MUCH TIME getting rid of the buffer cache, precisely because trying to maintain coherency between the page cache (mmap) and the buffer cache (read/write), it was clear that you wanted a unified model. Yet the wise heads in charge approved ZFS. It boggles my mind. Yeah, I get it, it's got lots of nice features. But at the expense of breaking one of the cornerstones of the kernel design. The only thing I can think of is that the people who could see the whole kernel architecture had left, I can't imagine Kleiman, Gingell, Rosenthal, Powell, any of the old school distinguished engineers, tolerating that for 1 second. So my guess is they were gone and nobody in the vetting process saw the whole picture any more. If anyone is lurking on the list and was there for the ZFS work, I'd love to hear your take on it. I'm speculating. It just blows my mind that something that was one of the main design points for the previous 10-15 years, was ignored. We're not talking about some obscure device driver, we're talking about mmap(), which was one of the reasons Sun ran circles around the other guys, they all had crappy mmap() implementations that copied. ZFS went back to that. Weird. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 21:58 ` Larry McVoy @ 2018-08-31 22:02 ` Warner Losh 2018-08-31 22:19 ` Cág ` (2 subsequent siblings) 3 siblings, 0 replies; 73+ messages in thread From: Warner Losh @ 2018-08-31 22:02 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 885 bytes --] On Fri, Aug 31, 2018 at 3:59 PM Larry McVoy <lm@mcvoy.com> wrote: > A bunch of people stuck around and tried, they really did and I applaud > them for it but the damage was done. I was gone by the time ZFS came out > so I have no idea how that passed through the formal vetting process that > Sun had in place. When I was there, if I had proposed a file system that > wouldn't use the page cache, you'd have to copy from the buffer cache > into the page cache to get mmap to work, I would have been kicked out > of the room and probably kicked out of the kernel group. We had spent > SO FRIGGING MUCH TIME getting rid of the buffer cache, precisely because > trying to maintain coherency between the page cache (mmap) and the buffer > cache (read/write), it was clear that you wanted a unified model. > It's reason #1 why Netflix can't use ZFS: the double copy problem... Warner [-- Attachment #2: Type: text/html, Size: 1222 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 21:58 ` Larry McVoy 2018-08-31 22:02 ` Warner Losh @ 2018-08-31 22:19 ` Cág 2018-08-31 22:23 ` Jon Forrest 2018-08-31 22:20 ` Cág 2018-08-31 23:02 ` Arthur Krewat 3 siblings, 1 reply; 73+ messages in thread From: Cág @ 2018-08-31 22:19 UTC (permalink / raw) To: TUHS main list Larry McVoy wrote: > SunOS was based on the BSD code, the entire system was frequently > described as "a bug fixed BSD". > Solaris was Sys Vr4 [...]. Both the kernel and user space went to a > Sys V compat system, it no longer felt anything like BSD. I find it kinda weird, considering what Bill Joy did for BSD and, obviously, for Sun. I wonder what he himself thinks about it. Shout out to Bill if he reads the list. Also, I'm using the original vi (ex-vi that is from Heirloom), not nvi, as my development platform. Another weird thing: his original vi never made it to any BSD distribution. -- caóc ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 22:19 ` Cág @ 2018-08-31 22:23 ` Jon Forrest 2018-08-31 22:30 ` Cág 0 siblings, 1 reply; 73+ messages in thread From: Jon Forrest @ 2018-08-31 22:23 UTC (permalink / raw) To: tuhs On 8/31/2018 3:19 PM, Cág wrote: > Also, I'm using the original vi (ex-vi that is from Heirloom), not nvi, > as my development platform. Another weird thing: his original vi never > made it to any BSD distribution. Are you quite sure? I remember using BSD on a VAX in about 1978 when vi just came out. I'm pretty sure Bill Joy wrote the man page and other documentation. Maybe it depends on what you mean by "his original vi". Jon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 22:23 ` Jon Forrest @ 2018-08-31 22:30 ` Cág 2018-08-31 22:34 ` Jon Forrest 2018-09-01 10:46 ` Donald ODona 0 siblings, 2 replies; 73+ messages in thread From: Cág @ 2018-08-31 22:30 UTC (permalink / raw) To: tuhs Jon Forrest wrote: > Are you quite sure? I remember using BSD on a VAX in about 1978 > when vi just came out. I'm pretty sure Bill Joy wrote the man > page and other documentation. *Open-source BSD distribution. I think it had some license restrictions when the Jolitzes made the 386 port, so they had to put an alternative. Then it was Elvis, nvi was written later on. -- caóc ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 22:30 ` Cág @ 2018-08-31 22:34 ` Jon Forrest 2018-09-01 10:46 ` Donald ODona 1 sibling, 0 replies; 73+ messages in thread From: Jon Forrest @ 2018-08-31 22:34 UTC (permalink / raw) To: tuhs On 8/31/2018 3:30 PM, Cág wrote: > Jon Forrest wrote: > >> Are you quite sure? I remember using BSD on a VAX in about 1978 >> when vi just came out. I'm pretty sure Bill Joy wrote the man >> page and other documentation. > > *Open-source BSD distribution. I think it had some license restrictions > when the Jolitzes made the 386 port, so they had to put an alternative. > Then it was Elvis, nvi was written later on. Those of us who used pre-open-source BSD probably have a different recollection of what BSD was like than those who came later. Jon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 22:30 ` Cág 2018-08-31 22:34 ` Jon Forrest @ 2018-09-01 10:46 ` Donald ODona 1 sibling, 0 replies; 73+ messages in thread From: Donald ODona @ 2018-09-01 10:46 UTC (permalink / raw) To: tuhs At 31 Aug 2018 22:32:06 +0000 (+00:00) from "Cág" <ca6c@bitmessage.ch>: > Then it was Elvis, nvi was written later on. "It was originally derived from the first incarnation of elvis, written by Steve Kirkendall, as noted in the README file included in nvi's sources. " https://en.wikipedia.org/wiki/Nvi#Credits_and_distribution ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 21:58 ` Larry McVoy 2018-08-31 22:02 ` Warner Losh 2018-08-31 22:19 ` Cág @ 2018-08-31 22:20 ` Cág 2018-08-31 23:02 ` Arthur Krewat 3 siblings, 0 replies; 73+ messages in thread From: Cág @ 2018-08-31 22:20 UTC (permalink / raw) To: TUHS main list Forgot to add: thanks for the good read, Larry! -- caóc ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 21:58 ` Larry McVoy ` (2 preceding siblings ...) 2018-08-31 22:20 ` Cág @ 2018-08-31 23:02 ` Arthur Krewat 2018-09-01 1:57 ` Larry McVoy 2018-09-01 16:27 ` Kevin Bowling 3 siblings, 2 replies; 73+ messages in thread From: Arthur Krewat @ 2018-08-31 23:02 UTC (permalink / raw) To: tuhs On 8/31/2018 5:58 PM, Larry McVoy wrote: > > Solaris was Sys Vr4 (which, if I recall correctly, differed from r3 > largely due to some stuff being ported over from SunOS). Both the kernel > and user space went to a Sys V compat system, it no longer felt anything > like BSD. > I would be very interested in anyone's recollections of how Solaris eventually turned out performance-wise, say version 9+, compared to other operating systems. SunOS, Linux, AIX, etc. I find it's about equal, and even exceeds Linux in terms of it's NUMA support and multi-processor support. I need to move some systems away from Solaris and off to Linux, and I find it's NUMA support lacking in certain ways. ak ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 23:02 ` Arthur Krewat @ 2018-09-01 1:57 ` Larry McVoy 2018-09-01 3:23 ` Theodore Y. Ts'o 2018-09-01 16:27 ` Kevin Bowling 1 sibling, 1 reply; 73+ messages in thread From: Larry McVoy @ 2018-09-01 1:57 UTC (permalink / raw) To: Arthur Krewat; +Cc: tuhs On Fri, Aug 31, 2018 at 07:02:36PM -0400, Arthur Krewat wrote: > On 8/31/2018 5:58 PM, Larry McVoy wrote: > > > >Solaris was Sys Vr4 (which, if I recall correctly, differed from r3 > >largely due to some stuff being ported over from SunOS). Both the kernel > >and user space went to a Sys V compat system, it no longer felt anything > >like BSD. > > > > I would be very interested in anyone's recollections of how Solaris > eventually turned out performance-wise, say version 9+, compared to other > operating systems. SunOS, Linux, AIX, etc. I did some updating of lmbench [*] when I was dancing with Netflix. I need to check that in and publish that because the bits have rotted since 1995. I have no idea if that will measure what you want, it's a bunch of microbenchmarks that measure bandwidth and latency of everything I could think of: network, disks, file systems, caches, memory, etc. It's interesting but might not be so to you. If you want to know if Solaris is at the same place as Linux, I can pretty much promise it is not in the "getting out of the way of the application". Solaris was known as Slowaris for a reason. Yeah, I know it sucked harder in the beginning, but those were order of magnitude suckages. Linus always cared about performance, he had a big hand in lmbench, we both cared. Linus was about performance like I am about code size. I ran the BitKeeper dev team for almost 20 years. I loved a changeset that removed more lines than it added. We got up to about 120K lines of code in the core and then we stayed there for the next decade, added so much more stuff but always found a way to delete stuff so we didn't get bloated. But all that said, you need to be specific about what perf you care about. These days the kernel is far more complicated, NUMA etc, and you might care about parallel make (I doubt it) or you might care about Oracle or something like that. --lm [*] http://mcvoy.com/lm/papers/lmbench-usenix.pdf ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 1:57 ` Larry McVoy @ 2018-09-01 3:23 ` Theodore Y. Ts'o 2018-09-01 16:29 ` Kevin Bowling 0 siblings, 1 reply; 73+ messages in thread From: Theodore Y. Ts'o @ 2018-09-01 3:23 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Fri, Aug 31, 2018 at 06:57:41PM -0700, Larry McVoy wrote: > > But all that said, you need to be specific about what perf you care > about. These days the kernel is far more complicated, NUMA etc, > and you might care about parallel make (I doubt it) or you might care > about Oracle or something like that. It wouldn't surprise me if Solaris was more scalable for gazillion dollar SMP machines with a huge number of cores. That was one of the reason as I recall why Solaris had a reputation of being slow; being scalable to big (and much more profitable) servers was considered more important than the smaller systems that were probably more numerous (but not nearly as profitable). - Ted ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 3:23 ` Theodore Y. Ts'o @ 2018-09-01 16:29 ` Kevin Bowling 2018-09-01 16:35 ` Larry McVoy 0 siblings, 1 reply; 73+ messages in thread From: Kevin Bowling @ 2018-09-01 16:29 UTC (permalink / raw) To: Theodore Y. Ts'o; +Cc: TUHS main list I am surprised how good Sun's technical marketing was for you to think this. Linux has scaled better since the early 2000s. The Solaris x86-64 port has some real gaffes in it to this day at least as visible in the OpenSolaris derivative codebases, serialization in the locking primitives kind of things. On Fri, Aug 31, 2018 at 8:23 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote: > On Fri, Aug 31, 2018 at 06:57:41PM -0700, Larry McVoy wrote: >> >> But all that said, you need to be specific about what perf you care >> about. These days the kernel is far more complicated, NUMA etc, >> and you might care about parallel make (I doubt it) or you might care >> about Oracle or something like that. > > It wouldn't surprise me if Solaris was more scalable for gazillion > dollar SMP machines with a huge number of cores. That was one of the > reason as I recall why Solaris had a reputation of being slow; being > scalable to big (and much more profitable) servers was considered more > important than the smaller systems that were probably more numerous > (but not nearly as profitable). > > - Ted ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 16:29 ` Kevin Bowling @ 2018-09-01 16:35 ` Larry McVoy 2018-09-01 19:32 ` Clem Cole 0 siblings, 1 reply; 73+ messages in thread From: Larry McVoy @ 2018-09-01 16:35 UTC (permalink / raw) To: Kevin Bowling; +Cc: TUHS main list On Sat, Sep 01, 2018 at 09:29:31AM -0700, Kevin Bowling wrote: > I am surprised how good Sun's technical marketing was for you to think > this. Linux has scaled better since the early 2000s. The Solaris > x86-64 port has some real gaffes in it to this day at least as visible > in the OpenSolaris derivative codebases, serialization in the locking > primitives kind of things. I think the SPARC bias was very apparent. Sun loved their own chips, to their detriment IMO. I have no personal knowledge of the x86_64 efforts, but I do know about the Sun i386 efforts. That was very looked down upon by the powers that were, the main kernel group, etc. Those poor guys had an uphill battle to get anything integrated, nobody wanted it. So it would not surprise me in the slightest if the x86_64 was a half assed effort without a lot of attention to stuff like performance. I don't think they wanted Solaris/x86 to be a success, they wanted SPARC to be a success. It was that kind of attitude that has pissed me off at every company I have ever worked for. I'm fine with marketing to customers but I hate it when people believe their own marketing. Internally, I think you should be very skeptical, judgemental, critical, whatever you want to call it, if your code sucks or your hardware sucks, don't pretend it doesn't, own it and fix it. That's how you win. > On Fri, Aug 31, 2018 at 8:23 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote: > > On Fri, Aug 31, 2018 at 06:57:41PM -0700, Larry McVoy wrote: > >> > >> But all that said, you need to be specific about what perf you care > >> about. These days the kernel is far more complicated, NUMA etc, > >> and you might care about parallel make (I doubt it) or you might care > >> about Oracle or something like that. > > > > It wouldn't surprise me if Solaris was more scalable for gazillion > > dollar SMP machines with a huge number of cores. That was one of the > > reason as I recall why Solaris had a reputation of being slow; being > > scalable to big (and much more profitable) servers was considered more > > important than the smaller systems that were probably more numerous > > (but not nearly as profitable). > > > > - Ted -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 16:35 ` Larry McVoy @ 2018-09-01 19:32 ` Clem Cole 0 siblings, 0 replies; 73+ messages in thread From: Clem Cole @ 2018-09-01 19:32 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 521 bytes --] below... On Sat, Sep 1, 2018 at 12:35 PM Larry McVoy <lm@mcvoy.com> wrote: > > It was that kind of attitude that has pissed me off at every company > I have ever worked for. I'm fine with marketing to customers but I > hate it when people believe their own marketing. Internally, I think > you should be very skeptical, judgemental, critical, whatever you want > to call it, if your code sucks or your hardware sucks, don't pretend > it doesn't, own it and fix it. That's how you win. > Amen.... ᐧ [-- Attachment #2: Type: text/html, Size: 1245 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-31 23:02 ` Arthur Krewat 2018-09-01 1:57 ` Larry McVoy @ 2018-09-01 16:27 ` Kevin Bowling 2018-09-01 17:17 ` Arthur Krewat 1 sibling, 1 reply; 73+ messages in thread From: Kevin Bowling @ 2018-09-01 16:27 UTC (permalink / raw) To: Arthur Krewat; +Cc: TUHS main list On Fri, Aug 31, 2018 at 4:02 PM, Arthur Krewat <krewat@kilonet.net> wrote: > On 8/31/2018 5:58 PM, Larry McVoy wrote: >> >> >> Solaris was Sys Vr4 (which, if I recall correctly, differed from r3 >> largely due to some stuff being ported over from SunOS). Both the kernel >> and user space went to a Sys V compat system, it no longer felt anything >> like BSD. >> > > I would be very interested in anyone's recollections of how Solaris > eventually turned out performance-wise, say version 9+, compared to other > operating systems. SunOS, Linux, AIX, etc. Linux started pulling away fast even on high end systems by the early 2000s. IBM and SGI dumped a ton of money, knowledge, and talent into this. By Linux kernel 2.6 the race was entirely won. After this HP-UX, AIX, and Solaris persist mainly in mainframe-like vertical stacks used mainly to host mission critical applications that are sold in bundles or "solutions" > I find it's about equal, and even exceeds Linux in terms of it's NUMA > support and multi-processor support. I need to move some systems away from > Solaris and off to Linux, and I find it's NUMA support lacking in certain > ways. This is pure fantasy. To understand Linux performance on high core count and multi-socket machines is to have at least passing knowledge of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3] and on Linux. IBM bought Sequent, made a favorable patent grant of RCU for Linux, and the rest history. There is a single feature I have seen in Solaris NUMA that should be implemented elsewhere. It does a micro-benchmark on boot to figure out the inter-core latency map. On stupid technology like Intel's ACPI and Xeon Cluster-on-Die and Sub-NUMA-Clustering, you get bogus data back in the SRAT table describing where the cores are on the on chip network it just chops things in half and doesn't reflect where the cores actually were fused off for yield or binning reasons which is statistically almost always asymmetric. On better engineered technology like IBM's POWER8/9 and OPAL firmware, you get the real locality information of where cores and cache groups actually are. Solaris' neat little micro-benchmark would work optimally even on the brain damaged data from Intel. [1] http://www2.rdrop.com/~paulmck/RCU/ [2] http://www2.rdrop.com/~paulmck/scalability/ [3] http://www2.rdrop.com/~paulmck/techreports/stingcacm3.1999.08.04a.pdf Regards, Kevin ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 16:27 ` Kevin Bowling @ 2018-09-01 17:17 ` Arthur Krewat 2018-09-01 22:19 ` Theodore Y. Ts'o 0 siblings, 1 reply; 73+ messages in thread From: Arthur Krewat @ 2018-09-01 17:17 UTC (permalink / raw) To: Kevin Bowling; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 962 bytes --] On 9/1/2018 12:27 PM, Kevin Bowling wrote: >> I find it's about equal, and even exceeds Linux in terms of it's NUMA >> support and multi-processor support. I need to move some systems away from >> Solaris and off to Linux, and I find it's NUMA support lacking in certain >> ways. > This is pure fantasy. To understand Linux performance on high core > count and multi-socket machines is to have at least passing knowledge > of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3] > and on Linux. IBM bought Sequent, made a favorable patent grant of > RCU for Linux, and the rest history. Thanks :) - I'm basing this on Oracle database performance, for the most part, and it's weird way of supporting NUMA on Linux in a bass-ackwards sort of way. Nothing I see in the latest RedHat/CentOS tells me it even cares about NUMA, but maybe that's more of their "we know better than you" mentality and it's all hidden under the covers somewhere. ak [-- Attachment #2: Type: text/html, Size: 1407 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 17:17 ` Arthur Krewat @ 2018-09-01 22:19 ` Theodore Y. Ts'o 2018-09-02 5:05 ` Kevin Bowling 0 siblings, 1 reply; 73+ messages in thread From: Theodore Y. Ts'o @ 2018-09-01 22:19 UTC (permalink / raw) To: Arthur Krewat; +Cc: TUHS main list On Sat, Sep 01, 2018 at 01:17:59PM -0400, Arthur Krewat wrote: > On 9/1/2018 12:27 PM, Kevin Bowling wrote: > > > I find it's about equal, and even exceeds Linux in terms of it's NUMA > > > support and multi-processor support. I need to move some systems away from > > > Solaris and off to Linux, and I find it's NUMA support lacking in certain > > > ways. > > This is pure fantasy. To understand Linux performance on high core > > count and multi-socket machines is to have at least passing knowledge > > of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3] > > and on Linux. IBM bought Sequent, made a favorable patent grant of > > RCU for Linux, and the rest history. > > Thanks :) - I'm basing this on Oracle database performance, for the most > part, and it's weird way of supporting NUMA on Linux in a bass-ackwards sort > of way. Nothing I see in the latest RedHat/CentOS tells me it even cares > about NUMA, but maybe that's more of their "we know better than you" > mentality and it's all hidden under the covers somewhere. It wouldn't surprise me if Linux's NUMA performance is pretty weak compared to Solaris. There was an attempt to try to make NUMA work well on Linux, with a lot of the effort coming from IBM and SGI, but that effort was overtaken by events. Back in Sequent's day, the remote to local memory latency was ten to one, so making the system NUMA aware was critical. But by early 2000's, the remote to local ratio was under 3:1 (or 2:1) for 4 socket systems, and with AMD's "Sufficiently Uniform Memory Organization" (SUMO), the ratio was under 1.5:1 or less. The main reason for this was that Windows was (and as far as I know, still is) NUMA oblivious. So x86 chip and motherboard designers solved the problem, by brute foruce, in hardware. So by 2003 or 2004, the Linux Scalability Effort had more or less petered out. (You can see the leftover remnants at http://lse.sourceforge.net) Fundamentally, the economics of 4 socket and higher machines was such that for many workloads, scale out was much cheaper than scale up. So why buy super-expensive IBM X440, x450, and x460 servers, which were huge cabinets connected by one or more "scalability cables" (sometimes referred to as the "scalability bottleneck"), when most of the time, you could just buy a rack of 2U x86 servers which would be much, much cheaper? There were certainly workloads this wasn't applicable, of course. But when Sun was selling Sun 10k's to web startups during the dot com boom, and they were using it to serve web traffic, they probably had too much VC money to burn, because that was *not* the most cost effective way to do things. Don't get me wrong; the Read Copy Update (RCU) technique was certainly very important, and is responsible for much of Linux's SMP scalability today. But these days, when you can get up to 28 cores (56 threads) on a single socket, the need for more than 2 socket systems is already somewhat niche, and by the time you get to more than 4 sockets, it's positively microscopic. As a result, NUMA support on Linux is certainly not as strong as it could be, and it wouldn't surprise me that Solaris has developed much better ways of handling the behemoths such as Sun Enterprise 10k. - Ted P.S. IBM made the RCU patent available for any GPL code, well before Sun decided on the CDDL for Solaris. So if Sun management had chosen GPL, they could have used RCU.... ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 22:19 ` Theodore Y. Ts'o @ 2018-09-02 5:05 ` Kevin Bowling 2018-09-02 19:43 ` Theodore Y. Ts'o 2018-09-05 0:10 ` Tony Finch 0 siblings, 2 replies; 73+ messages in thread From: Kevin Bowling @ 2018-09-02 5:05 UTC (permalink / raw) To: Theodore Y. Ts'o; +Cc: TUHS main list On Sat, Sep 1, 2018 at 3:19 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote: > On Sat, Sep 01, 2018 at 01:17:59PM -0400, Arthur Krewat wrote: >> On 9/1/2018 12:27 PM, Kevin Bowling wrote: >> > > I find it's about equal, and even exceeds Linux in terms of it's NUMA >> > > support and multi-processor support. I need to move some systems away from >> > > Solaris and off to Linux, and I find it's NUMA support lacking in certain >> > > ways. >> > This is pure fantasy. To understand Linux performance on high core >> > count and multi-socket machines is to have at least passing knowledge >> > of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3] >> > and on Linux. IBM bought Sequent, made a favorable patent grant of >> > RCU for Linux, and the rest history. >> >> Thanks :) - I'm basing this on Oracle database performance, for the most >> part, and it's weird way of supporting NUMA on Linux in a bass-ackwards sort >> of way. Nothing I see in the latest RedHat/CentOS tells me it even cares >> about NUMA, but maybe that's more of their "we know better than you" >> mentality and it's all hidden under the covers somewhere. > > It wouldn't surprise me if Linux's NUMA performance is pretty weak > compared to Solaris. There was an attempt to try to make NUMA work > well on Linux, with a lot of the effort coming from IBM and SGI, but > that effort was overtaken by events. Back in Sequent's day, the > remote to local memory latency was ten to one, so making the system > NUMA aware was critical. But by early 2000's, the remote to local > ratio was under 3:1 (or 2:1) for 4 socket systems, and with AMD's > "Sufficiently Uniform Memory Organization" (SUMO), the ratio was under > 1.5:1 or less. Sorry this is just bogus about being weak compared to Solaris. Are you looking back with rosy glasses or have you scanned the code in the past couple years? I have and there is nothing particularly special about Solaris internals here or elsewhere. In fact, there are a lot of pessimization all over the place. As Larry said, a lot of folks in the Linux community clearly cared about performance. Although the Solaris code is fairly clean It's not clear Sun valued performance at all. A stroll through arch/*/include/asm/ was enough to convince me of Larry's claims. I'm not a Linux fanboy but credit goes where it's due. Solaris has lgroups, which are a clean design but that is the extent of its NUMA support, one shot at placement and scheduling. Linux has a NUMA allocator, aware scheduler, NUMA-optimized spinlocks and mutexes, various subsystems correctly use the primitives, and can use cgroups to contain or gang things. There is a userland policy tool called numad that tries to add some additional runtime affinity and movement policy decisions. I agree that architecturally Linux NUMA is nowhere near where Sequent and especially SGI was. And the reasons you cite are valid, Linux implementation is good for maybe 8-16 sockets of modern core count with a much tighter off chip network than the big dogs were building. Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16 sockets, 768 threads) for dedicated Linux use which have similar north/south and east/west off chip networks. They have a lot of very talented people on the firmware, kernel, compilers to make these things work fast, including Paul. > The main reason for this was that Windows was (and as far as I know, > still is) NUMA oblivious. So x86 chip and motherboard designers > solved the problem, by brute foruce, in hardware. So by 2003 or 2004, > the Linux Scalability Effort had more or less petered out. (You can > see the leftover remnants at http://lse.sourceforge.net) Windows' NUMA support is on par with Solaris insofar as there is domain aware memory allocator and scheduler hierarchy that takes the domain (and SMT etc) into account. What Windows lacks is the finely tuned concurrency primitives and everything else Linux has done.. which Solaris lacks as well. I'm not even talking about RCU (or epoch based reclamation or proxy collection or hazard pointers, at least one of which is not patent encumbered), I'm just talking about the quality of primitives like spinlocks and mutex and rwlock. There are big tradeoffs to the implementations of these in terms of fairness, progress guarantees, and thread scalability. Linux leads the pack by a long shot in this department. Where you start going beyond Linux-like NUMA IMO is when you get Irix-like features of page copying, migration, and multiple advanced placement policies. > Fundamentally, the economics of 4 socket and higher machines was such > that for many workloads, scale out was much cheaper than scale up. So > why buy super-expensive IBM X440, x450, and x460 servers, which were > huge cabinets connected by one or more "scalability cables" (sometimes > referred to as the "scalability bottleneck"), when most of the time, > you could just buy a rack of 2U x86 servers which would be much, much > cheaper? Agreed, this is why x86 has dominated the server market for a long time. > There were certainly workloads this wasn't applicable, of course. But > when Sun was selling Sun 10k's to web startups during the dot com > boom, and they were using it to serve web traffic, they probably had > too much VC money to burn, because that was *not* the most cost > effective way to do things. Agreed. Those big margins must have caused them to take their eye off what mattered right at the time Linux was getting some momentum from the big HW vendors. > Don't get me wrong; the Read Copy Update (RCU) technique was certainly > very important, and is responsible for much of Linux's SMP scalability > today. But these days, when you can get up to 28 cores (56 threads) > on a single socket, the need for more than 2 socket systems is already > somewhat niche, and by the time you get to more than 4 sockets, it's > positively microscopic. As a result, NUMA support on Linux is > certainly not as strong as it could be, and it wouldn't surprise me > that Solaris has developed much better ways of handling the behemoths > such as Sun Enterprise 10k. The E10k was only a 64-core machine on a tight backplane compared to other large systems. It didn't have any of the pressing needs that Sequent and SGI did with multi-drawer interconnects to drive excellence in NUMA. These are strange times. Intel's been putting out some real doozy chips. The mesh in Skylake is a partial improvement over the dual rings of Haswell (though they did some goofy things to increase latency in undesirable ways), and they aren't going to continue to brute force it like IBM did with their 17 metal layer process node.. many SKUs in Cascade Lake will be a dual die design and cost a hilarious amount of money. AMD's EPYC is really bad in this department too, one EPYC behaves identically to a 4 socket system with extremely poor inter-die latency [1]. I think POWER9 is universally better and the high bin chips (22 core, 88 thread, mega cache) are only around $2500 compared to Skylake's absurd $12,000. POWER9 is a single on chip NUMA domain for 24 cores. Google publicly stated they are using it for GPU servers, and that all their monorepo is built for multiple ISAs. Through the grapevine I've heard gmail is running on POWER9 as well now. That is pretty competent, the reason Intel is sucking so bad is because people allowed themselves such lock in. A hyperscaler should be able to change between a couple ISAs as needed between purchasing cycles. > - Ted > > P.S. IBM made the RCU patent available for any GPL code, well before > Sun decided on the CDDL for Solaris. So if Sun management had chosen > GPL, they could have used RCU... True. There is also at least one unencumbered strategy such as epoch based reclamation which was known about around that time [2] [1] https://www.servethehome.com/amd-epyc-infinity-fabric-latency-ddr4-2400-v-2666-a-snapshot/ [2] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf Regards, Kevin ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-02 5:05 ` Kevin Bowling @ 2018-09-02 19:43 ` Theodore Y. Ts'o 2018-09-04 11:47 ` Kevin Bowling 2018-09-05 0:10 ` Tony Finch 1 sibling, 1 reply; 73+ messages in thread From: Theodore Y. Ts'o @ 2018-09-02 19:43 UTC (permalink / raw) To: Kevin Bowling; +Cc: TUHS main list On Sat, Sep 01, 2018 at 10:05:06PM -0700, Kevin Bowling wrote: > > Sorry this is just bogus about being weak compared to Solaris. Are > you looking back with rosy glasses or have you scanned the code in the > past couple years? I have and there is nothing particularly special > about Solaris internals here or elsewhere. I haven't looked at Solaris code; I had just *assumed* that if they were selling million dollar E10k's, they would have had NUMA support at *least* as good as SGI's Irix. And it would have been an excuse for their pathetic performance on UP and 2-4 SMP systems. > Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16 > sockets, 768 threads) for dedicated Linux use which have similar > north/south and east/west off chip networks. They have a lot of very > talented people on the firmware, kernel, compilers to make these > things work fast, including Paul. > ... > Where you start going beyond Linux-like NUMA IMO is when you get > Irix-like features of page copying, migration, and multiple advanced > placement policies. One thing to consider is that IBM really only cared about optimizing hardware for DB2, Oracle, and Webshpere. That's one of the reason why you didn't see much in the way of innovative file system work, ala ZFS. There was no business justification for pouring 100+ engineer years to develop a next-generation file systesm --- and they had already done that once already for GPFS, a cluster file system. As far as local disk file system was concerned, the only real business value it had was to serve as a program loader for DB2 and Websphere. :-) (I'm exagerating a little for effect, but *only* a little.) So as far as NUMA was concerned, there was almost certainly not have been much perceived business value in having sophisticated auto-migration for arbitrary workloads in the kernel. Something basic which was good enough for Oracle, DB2, etc., was all that would be needed. (And if you needed to hire consultants from IBM Global Services to mind-meld with the configuration documentation in order to get the best out of your Rockhopper.... well, shucks, darn. :-) At IBM the business people really did make the funding decisions of what to work on. ZFS could have never happened at IBM because no one would have thought that a even a tiny number of IBM's current or potential customer base would abandon AIX or Linux and switch to Solaris, or buy Sun hardware instead of IBM hardware --- just for the sake of ZFS. And that's how decision-makers at IBM really thought. (And to be fair to those decision-makers, IBM is still in business as a free-standing business --- and Sun is not.) - Ted ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-02 19:43 ` Theodore Y. Ts'o @ 2018-09-04 11:47 ` Kevin Bowling 2018-09-04 17:39 ` Gilles Gravier 0 siblings, 1 reply; 73+ messages in thread From: Kevin Bowling @ 2018-09-04 11:47 UTC (permalink / raw) To: Theodore Y. Ts'o; +Cc: TUHS main list On Sun, Sep 2, 2018 at 12:43 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote: > On Sat, Sep 01, 2018 at 10:05:06PM -0700, Kevin Bowling wrote: >> >> Sorry this is just bogus about being weak compared to Solaris. Are >> you looking back with rosy glasses or have you scanned the code in the >> past couple years? I have and there is nothing particularly special >> about Solaris internals here or elsewhere. > > I haven't looked at Solaris code; I had just *assumed* that if they > were selling million dollar E10k's, they would have had NUMA support > at *least* as good as SGI's Irix. And it would have been an excuse > for their pathetic performance on UP and 2-4 SMP systems. One would hope so, but that was the strategy that got them eaten by a grue. Another funny anecdote about this aloofness.. Linux on sparc64 uses the Relaxed Memory Order mode that the hardware offers . Solaris.. Total Store Order. There are tons of things like this in the code that blow my mind. I would have been pissed if I were on the hardware side of SPARC. > >> Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16 >> sockets, 768 threads) for dedicated Linux use which have similar >> north/south and east/west off chip networks. They have a lot of very >> talented people on the firmware, kernel, compilers to make these >> things work fast, including Paul. >> ... >> Where you start going beyond Linux-like NUMA IMO is when you get >> Irix-like features of page copying, migration, and multiple advanced >> placement policies. > > One thing to consider is that IBM really only cared about optimizing > hardware for DB2, Oracle, and Webshpere. That's one of the reason why > you didn't see much in the way of innovative file system work, ala > ZFS. There was no business justification for pouring 100+ engineer > years to develop a next-generation file systesm --- and they had > already done that once already for GPFS, a cluster file system. As > far as local disk file system was concerned, the only real business > value it had was to serve as a program loader for DB2 and Websphere. :-) > > (I'm exagerating a little for effect, but *only* a little.) Hmm, I think they've been pretty earnest at wanting to be 2+ years ahead of the general market with POWER for as long as I can see, lots of HPC money has been subsidizing that. Depends on the workload but bus and memory bandwidth right now with PCIe Gen4 and NvLink can really cut down on server sprawl. I've met with the GM/chief architect and they see OpenPOWER positioned as a full frontal competitor to Intel Xeon. I'm fairly disappointed in my contemporaries for not recognizing the value of a completely open source firmware and on chip controller stack; especially after the recent snafu where Intel changed the microcode license to disallow benchmarks and claimed it was an accident. Your statements make sense to me with respect to AIX, as Linux has been the main effort since the 2000s. GPFS looks neat, I wish it were open or at least internals documented well enough to study the implementation academically. > > So as far as NUMA was concerned, there was almost certainly not have > been much perceived business value in having sophisticated > auto-migration for arbitrary workloads in the kernel. Something basic > which was good enough for Oracle, DB2, etc., was all that would be > needed. (And if you needed to hire consultants from IBM Global > Services to mind-meld with the configuration documentation in order to > get the best out of your Rockhopper.... well, shucks, darn. :-) That's probably the dirty little secret. It's long been profitable to carefully plan software interrupt handlers, user threads, and memory allocation even on pedestrian servers if they are running a fixed function. I guess Google's Borg and the new workalikes could do semi-automagic things with cgroups these days. There is evidence of people getting pretty crazy with it when we see things like Intel cache allocation features. > At IBM the business people really did make the funding decisions of > what to work on. ZFS could have never happened at IBM because no one > would have thought that a even a tiny number of IBM's current or > potential customer base would abandon AIX or Linux and switch to > Solaris, or buy Sun hardware instead of IBM hardware --- just for the > sake of ZFS. And that's how decision-makers at IBM really thought. > (And to be fair to those decision-makers, IBM is still in business as > a free-standing business --- and Sun is not.) Agreed, one of these companies is doing pretty well with a fat dividend yield, that other has basically been dismantled for all but a couple remaining desirable platform control points like Java and MySQL. Many things in tech are happy accidents and a small number of motivated people at the right place and time. A Sun engineer admitted on some video I've seen that the green light was really given for ZFS because they got stumped by some UFS bugs.. once enough of ZFS was written to test the end to end checksumming features they found out some of these heisenbugs were LSI HBA and disk firmware issues :o) Surveying some of these filesystems.. JFS2 is a decent, nowhere near the capabilities of ZFS but even today it's not in dire need of replacement.. I suspect another issue complementary to your point is the standalone storage business is many $B of revenue. ESS/DS8000 and the like are preferred revenue. IBM and HP were more in the SAN game than Sun and SGI who let the customers configure systems themselves be used as storage (Sun was using VxFS for a long time, SGI had some CXFS things IIRC). Tru64 had a pretty interesting filesystem on paper, curious if you ever looked at its design since they open sourced it. Regards, Kevin ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-04 11:47 ` Kevin Bowling @ 2018-09-04 17:39 ` Gilles Gravier 2018-09-04 17:45 ` Henry Bent 0 siblings, 1 reply; 73+ messages in thread From: Gilles Gravier @ 2018-09-04 17:39 UTC (permalink / raw) To: kevin.bowling; +Cc: TUHS [-- Attachment #1: Type: text/plain, Size: 6720 bytes --] This link : https://vetusware.com/download/SunOS%20Source%20Code%204.1.3/?id=13475 seems to have the right file (registration required, but it's free, use a disposable email). Beats my having to find a SCSI adaptor, a QIC-150 drive, and trying to read my old QIC-150 tape with the source code on it... Gilles Le mar. 4 sept. 2018 à 13:48, Kevin Bowling <kevin.bowling@kev009.com> a écrit : > On Sun, Sep 2, 2018 at 12:43 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote: > > On Sat, Sep 01, 2018 at 10:05:06PM -0700, Kevin Bowling wrote: > >> > >> Sorry this is just bogus about being weak compared to Solaris. Are > >> you looking back with rosy glasses or have you scanned the code in the > >> past couple years? I have and there is nothing particularly special > >> about Solaris internals here or elsewhere. > > > > I haven't looked at Solaris code; I had just *assumed* that if they > > were selling million dollar E10k's, they would have had NUMA support > > at *least* as good as SGI's Irix. And it would have been an excuse > > for their pathetic performance on UP and 2-4 SMP systems. > > One would hope so, but that was the strategy that got them eaten by a > grue. Another funny anecdote about this aloofness.. Linux on sparc64 > uses the Relaxed Memory Order mode that the hardware offers . > Solaris.. Total Store Order. There are tons of things like this in > the code that blow my mind. I would have been pissed if I were on the > hardware side of SPARC. > > > > >> Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16 > >> sockets, 768 threads) for dedicated Linux use which have similar > >> north/south and east/west off chip networks. They have a lot of very > >> talented people on the firmware, kernel, compilers to make these > >> things work fast, including Paul. > >> ... > >> Where you start going beyond Linux-like NUMA IMO is when you get > >> Irix-like features of page copying, migration, and multiple advanced > >> placement policies. > > > > One thing to consider is that IBM really only cared about optimizing > > hardware for DB2, Oracle, and Webshpere. That's one of the reason why > > you didn't see much in the way of innovative file system work, ala > > ZFS. There was no business justification for pouring 100+ engineer > > years to develop a next-generation file systesm --- and they had > > already done that once already for GPFS, a cluster file system. As > > far as local disk file system was concerned, the only real business > > value it had was to serve as a program loader for DB2 and Websphere. :-) > > > > (I'm exagerating a little for effect, but *only* a little.) > > Hmm, I think they've been pretty earnest at wanting to be 2+ years > ahead of the general market with POWER for as long as I can see, lots > of HPC money has been subsidizing that. Depends on the workload but > bus and memory bandwidth right now with PCIe Gen4 and NvLink can > really cut down on server sprawl. I've met with the GM/chief > architect and they see OpenPOWER positioned as a full frontal > competitor to Intel Xeon. I'm fairly disappointed in my > contemporaries for not recognizing the value of a completely open > source firmware and on chip controller stack; especially after the > recent snafu where Intel changed the microcode license to disallow > benchmarks and claimed it was an accident. > > Your statements make sense to me with respect to AIX, as Linux has > been the main effort since the 2000s. GPFS looks neat, I wish it were > open or at least internals documented well enough to study the > implementation academically. > > > > > So as far as NUMA was concerned, there was almost certainly not have > > been much perceived business value in having sophisticated > > auto-migration for arbitrary workloads in the kernel. Something basic > > which was good enough for Oracle, DB2, etc., was all that would be > > needed. (And if you needed to hire consultants from IBM Global > > Services to mind-meld with the configuration documentation in order to > > get the best out of your Rockhopper.... well, shucks, darn. :-) > > That's probably the dirty little secret. It's long been profitable to > carefully plan software interrupt handlers, user threads, and memory > allocation even on pedestrian servers if they are running a fixed > function. I guess Google's Borg and the new workalikes could do > semi-automagic things with cgroups these days. There is evidence of > people getting pretty crazy with it when we see things like Intel > cache allocation features. > > > At IBM the business people really did make the funding decisions of > > what to work on. ZFS could have never happened at IBM because no one > > would have thought that a even a tiny number of IBM's current or > > potential customer base would abandon AIX or Linux and switch to > > Solaris, or buy Sun hardware instead of IBM hardware --- just for the > > sake of ZFS. And that's how decision-makers at IBM really thought. > > (And to be fair to those decision-makers, IBM is still in business as > > a free-standing business --- and Sun is not.) > > Agreed, one of these companies is doing pretty well with a fat > dividend yield, that other has basically been dismantled for all but a > couple remaining desirable platform control points like Java and > MySQL. > > Many things in tech are happy accidents and a small number of > motivated people at the right place and time. A Sun engineer admitted > on some video I've seen that the green light was really given for ZFS > because they got stumped by some UFS bugs.. once enough of ZFS was > written to test the end to end checksumming features they found out > some of these heisenbugs were LSI HBA and disk firmware issues :o) > > Surveying some of these filesystems.. JFS2 is a decent, nowhere near > the capabilities of ZFS but even today it's not in dire need of > replacement.. I suspect another issue complementary to your point is > the standalone storage business is many $B of revenue. ESS/DS8000 and > the like are preferred revenue. IBM and HP were more in the SAN game > than Sun and SGI who let the customers configure systems themselves be > used as storage (Sun was using VxFS for a long time, SGI had some CXFS > things IIRC). Tru64 had a pretty interesting filesystem on paper, > curious if you ever looked at its design since they open sourced it. > > Regards, > Kevin > -- *Gilles Gravier* - Gilles@Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key : 0x8DE6D026 <http://pgp.mit.edu:11371/pks/lookup?search=0x8DE6D026&op=index> [-- Attachment #2: Type: text/html, Size: 8889 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-04 17:39 ` Gilles Gravier @ 2018-09-04 17:45 ` Henry Bent 2018-09-05 6:31 ` Gilles Gravier 0 siblings, 1 reply; 73+ messages in thread From: Henry Bent @ 2018-09-04 17:45 UTC (permalink / raw) To: Gilles Gravier; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 815 bytes --] On Tue, Sep 4, 2018, 13:40 Gilles Gravier <gilles@gravier.org> wrote: > This link : > https://vetusware.com/download/SunOS%20Source%20Code%204.1.3/?id=13475 > seems to have the right file (registration required, but it's free, use a > disposable email). > > Beats my having to find a SCSI adaptor, a QIC-150 drive, and trying to > read my old QIC-150 tape with the source code on it... > > Gilles > I feel like we've been through this before on this list, but perhaps it bears repeating: just because you can find source (or binaries, or CD images, etc.) on the internet, that doesn't make it the least bit legal. That is clearly the case here. Sadly, there are even higher profile sites like the Internet Archive that have this problem too. The concept of "abandonware" has no legal footing whatsoever. -Henry [-- Attachment #2: Type: text/html, Size: 1420 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-04 17:45 ` Henry Bent @ 2018-09-05 6:31 ` Gilles Gravier 2018-09-05 12:55 ` Arthur Krewat 2018-09-05 23:40 ` Dave Horsfall 0 siblings, 2 replies; 73+ messages in thread From: Gilles Gravier @ 2018-09-05 6:31 UTC (permalink / raw) To: Henry Bent; +Cc: TUHS [-- Attachment #1: Type: text/plain, Size: 2345 bytes --] (Henri, you're in copy of this again, because first time I did a Reply instead of Reply to list/all. Sorry.) Le mar. 4 sept. 2018 à 19:45, Henry Bent <henry.r.bent@gmail.com> a écrit : > > > On Tue, Sep 4, 2018, 13:40 Gilles Gravier <gilles@gravier.org> wrote: > >> This link : >> https://vetusware.com/download/SunOS%20Source%20Code%204.1.3/?id=13475 >> seems to have the right file (registration required, but it's free, use a >> disposable email). >> >> Beats my having to find a SCSI adaptor, a QIC-150 drive, and trying to >> read my old QIC-150 tape with the source code on it... >> >> Gilles >> > > I feel like we've been through this before on this list, but perhaps it > bears repeating: just because you can find source (or binaries, or CD > images, etc.) on the internet, that doesn't make it the least bit legal. > That is clearly the case here. Sadly, there are even higher profile sites > like the Internet Archive that have this problem too. The concept of > "abandonware" has no legal footing whatsoever. > > -Henry > Oh I definitely know the sources aren't officially accessible. By the way, I had copies of them (my QIC tape) when I was a student. I still have the QIC. It's the common example that I use to tell people that opensourcing software makes it more secure because the good guys have access to the source code at the same time as the bad guys, which gives them a fair chance to fix bugs before the bad guys use them. With closed source (SunOS, VMS...) the good guys don't have access to the source code... but the bad guys will always (either by paying somebody enough to make a copy for them, or by finding them on some non legitimate place). As a student I had the source of SunOS (4.1.3) but also VMS (on a few TK-50 tapes). For me, that vetusware site is certainly not legitimate... but since I have the QIC tape at home, I just used it as an easy alternative to having to get the hardware to read my tape back in working order... I certainly do not consider it a legally approved way of distributing code which is, as we all agree, NOT open source. Gilles -- *Gilles Gravier* - Gilles@Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key : 0x8DE6D026 <http://pgp.mit.edu:11371/pks/lookup?search=0x8DE6D026&op=index> [-- Attachment #2: Type: text/html, Size: 4483 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-05 6:31 ` Gilles Gravier @ 2018-09-05 12:55 ` Arthur Krewat 2018-09-05 15:26 ` Warner Losh 2018-09-05 23:40 ` Dave Horsfall 1 sibling, 1 reply; 73+ messages in thread From: Arthur Krewat @ 2018-09-05 12:55 UTC (permalink / raw) To: tuhs On 9/5/2018 2:31 AM, Gilles Gravier wrote: > It's the common example that I use to tell people that opensourcing > software makes it more secure because the good guys have access to the > source code at the same time as the bad guys, which gives them a fair > chance to fix bugs before the bad guys use them. Bash/Shellshock kinda proves that premise incorrect, although it's pretty much the worst-case example, but still... ;) Announced in 2014, it goes back to September 1989 (according to a wikipedia article, so I'm not sure about that date's accuracy). https://en.wikipedia.org/wiki/Shellshock_(software_bug) https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/17/IBM-AIX.html?vendor_id=14 https://www.cvedetails.com/product/20/HP-Hp-ux.html?vendor_id=10 https://www.cvedetails.com/product/19755/Oracle-Solaris.html?vendor_id=93 It could be argued that the above CVE results are either under-reported (closed-source), or over-reported (open-source). Or vice-versa ;) ak ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-05 12:55 ` Arthur Krewat @ 2018-09-05 15:26 ` Warner Losh 2018-09-05 15:36 ` Chet Ramey 2018-09-05 15:43 ` Arthur Krewat 0 siblings, 2 replies; 73+ messages in thread From: Warner Losh @ 2018-09-05 15:26 UTC (permalink / raw) To: Arthur Krewat; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 815 bytes --] On Wed, Sep 5, 2018 at 6:55 AM Arthur Krewat <krewat@kilonet.net> wrote: > > > On 9/5/2018 2:31 AM, Gilles Gravier wrote: > > It's the common example that I use to tell people that opensourcing > > software makes it more secure because the good guys have access to the > > source code at the same time as the bad guys, which gives them a fair > > chance to fix bugs before the bad guys use them. > > > Bash/Shellshock kinda proves that premise incorrect, although it's > pretty much the worst-case example, but still... ;) > I'm not sure it does. It proves that bugs aren't instantly found, true. It doesn't provide perfection, but does make it easier to find / fix bugs before the bad guys. How long would such a bug have languished it if were buried inside of DCL.B32 instead of being out in the open? Warner [-- Attachment #2: Type: text/html, Size: 1181 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-05 15:26 ` Warner Losh @ 2018-09-05 15:36 ` Chet Ramey 2018-09-05 15:43 ` Arthur Krewat 1 sibling, 0 replies; 73+ messages in thread From: Chet Ramey @ 2018-09-05 15:36 UTC (permalink / raw) To: Warner Losh, Arthur Krewat; +Cc: TUHS main list On 9/5/18 11:26 AM, Warner Losh wrote: > On 9/5/2018 2:31 AM, Gilles Gravier wrote: > > It's the common example that I use to tell people that opensourcing > > software makes it more secure because the good guys have access to the > > source code at the same time as the bad guys, which gives them a fair > > chance to fix bugs before the bad guys use them. > > > Bash/Shellshock kinda proves that premise incorrect, although it's > pretty much the worst-case example, but still... ;) > > > I'm not sure it does. It proves that bugs aren't instantly found, true. It > doesn't provide perfection, but does make it easier to find / fix bugs > before the bad guys. How long would such a bug have languished it if were > buried inside of DCL.B32 instead of being out in the open? It proves that if there is someone who has an idea, or who thinks about a thing in new ways, he can verify his suspicions without too much trouble. The barrier to investigation is lowered. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-05 15:26 ` Warner Losh 2018-09-05 15:36 ` Chet Ramey @ 2018-09-05 15:43 ` Arthur Krewat 1 sibling, 0 replies; 73+ messages in thread From: Arthur Krewat @ 2018-09-05 15:43 UTC (permalink / raw) To: Warner Losh; +Cc: TUHS main list On 9/5/2018 11:26 AM, Warner Losh wrote: > > I'm not sure it does. It proves that bugs aren't instantly found, > true. It doesn't provide perfection, but does make it easier to find / > fix bugs before the bad guys. How long would such a bug have > languished it if were buried inside of DCL.B32 instead of being out in > the open? It depends on how it was found in the first place. A quick Google doesn't tell me much about exactly how it was discovered initially. Nor is there any background information that says it wasn't (or was) exploited before the announcement. Was it discovered because someone (Stéphane Chazelas) was just reading open source code? Or was he trying to do something innocent and it broke in such a way that it was obvious bash was doing something bad? Or was he investigating a break-in and found the vector? Serious questions, I'd love to hear from anyone who knows more. My original point remains: Open Source doesn't necessarily mean more secure if a really bad exploit was allowed to exist for 25 years. No offense intended to anyone on this list. ak ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-05 6:31 ` Gilles Gravier 2018-09-05 12:55 ` Arthur Krewat @ 2018-09-05 23:40 ` Dave Horsfall 1 sibling, 0 replies; 73+ messages in thread From: Dave Horsfall @ 2018-09-05 23:40 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 5 Sep 2018, Gilles Gravier wrote: > (Henri, you're in copy of this again, because first time I did a Reply > instead of Reply to list/all. Sorry.) One of my pet hates is people who use "Reply All" because either they are too lazy to edit the Reply (and they top-post, too), or the list is set up that way. I really don't need my own personal copy, as well as a list copy. Oh, and people who are too lazy to trim their replies too, because they are encouraged to top-post. -- Dave ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-02 5:05 ` Kevin Bowling 2018-09-02 19:43 ` Theodore Y. Ts'o @ 2018-09-05 0:10 ` Tony Finch 1 sibling, 0 replies; 73+ messages in thread From: Tony Finch @ 2018-09-05 0:10 UTC (permalink / raw) To: Kevin Bowling; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1272 bytes --] > On 2 Sep 2018, at 06:05, Kevin Bowling <kevin.bowling@kev009.com> wrote: > > The E10k was only a 64-core machine on a tight backplane compared to > other large systems. It didn't have any of the pressing needs that > Sequent and SGI did with multi-drawer interconnects to drive > excellence in NUMA. When I started work at Cambridge in 2002 our central supercomputer was being replaced with a cluster of Sun Fire E15K machines with a fancy interconnect - it topped out at position 199 on the top500 list https://www.top500.org/list/2003/06/?page=2 with a 300 core configuration. It looks like they never managed to get the whole thing working as a single cluster since the other two thirds of the installation had positions 200 and 201! (The Nov. 2002 top500 list has it in 6 x 144 core shards.) Here’s a news item about it: https://www.cnet.com/news/sun-expands-supercomputer-effort/ > True. There is also at least one unencumbered strategy such as epoch > based reclamation which was known about around that time [2] > > [2] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf The big benchmarks in this lovely thesis were run on one of the E15K supercomputer boxes :-) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at [-- Attachment #2: Type: text/html, Size: 2256 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? @ 2018-08-30 19:54 Noel Chiappa 2018-08-30 20:05 ` Earl Baugh 0 siblings, 1 reply; 73+ messages in thread From: Noel Chiappa @ 2018-08-30 19:54 UTC (permalink / raw) To: tuhs; +Cc: jnc > From: Larry McVoy > I'd really like the SCCS history. Any idea if that even still exists, or did it get shredded somewhere along the way? Anyway, should I spin up my nephew on trying to find the right person to put out a historic, personal-use license? Noel ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-30 19:54 Noel Chiappa @ 2018-08-30 20:05 ` Earl Baugh 0 siblings, 0 replies; 73+ messages in thread From: Earl Baugh @ 2018-08-30 20:05 UTC (permalink / raw) To: Noel Chiappa; +Cc: tuhs I’d be interested. Especially for my Sun 1/100 Earl. Sent from my iPhone On Aug 30, 2018, at 3:54 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: >> From: Larry McVoy > >> I'd really like the SCCS history. > > Any idea if that even still exists, or did it get shredded somewhere along the > way? > > Anyway, should I spin up my nephew on trying to find the right person to put > out a historic, personal-use license? > > Noel ^ permalink raw reply [flat|nested] 73+ messages in thread
* [TUHS] Research UNIX on the AT&T 3B2? @ 2018-08-24 15:13 Seth Morabito 2018-08-24 16:06 ` Clem Cole 0 siblings, 1 reply; 73+ messages in thread From: Seth Morabito @ 2018-08-24 15:13 UTC (permalink / raw) To: TUHS main list After the past several years of focusing on 3B2 preservation and emulation, I've begun to wonder whether 3B2 hardware was used very much inside of Bell Labs. Has anyone ever heard whether Research UNIX was ever ported to the WE32100? I've certainly never seen anything that would suggest it was, but I'd love to be proven wrong. -Seth -- Seth Morabito Poulsbo, WA web@loomcom.com ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] Research UNIX on the AT&T 3B2? 2018-08-24 15:13 [TUHS] Research UNIX on the AT&T 3B2? Seth Morabito @ 2018-08-24 16:06 ` Clem Cole 2018-08-27 15:54 ` Mary Ann Horton 0 siblings, 1 reply; 73+ messages in thread From: Clem Cole @ 2018-08-24 16:06 UTC (permalink / raw) To: Seth Morabito; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2583 bytes --] On Fri, Aug 24, 2018 at 11:13 AM Seth Morabito <web@loomcom.com> wrote: > ... > I've begun to wonder whether 3B2 hardware was used very much inside of > Bell Labs. > I'd be curious to hear of people that actually used it. AT&T forced you to buy one with SVR3 as the porting base (I'd have never had bought the one we had a Stellar otherwise). The only time I ever knew anyone run one, was to check to see the behavior of some code/validation testing of RFS *etc*... The HW as pretty slow/inflexible compared to 68020/68030 which came out around the same time, so it was just not interesting - *i.e.* 'JAWS' - Just another work station' and it did not have a display. IIRC, it was a server and pretty inflexible in the I/O subsystem for that use. Sun would quickly produce the first Sparcs, which as Larry has pointed out, kicked butt and were cheaper . The MIPS chip would emerge with lots of designs, and for that matter the 040 and the 386 would appear soon their after , too. I've always felt that the 3Bx series was an example of fighting the previous war; other than 3B4000 (which had high reliability but other issues in practice to use it), there was never anything that made them special - compared to everyone else. The only 'successful' product that I can remember that used the WE32100 was the second version (*a.k.a.* product version) of the Blit (Bart's first version was 68000 IIRC). Does anyone know of another product? I think I was told the 5ESS changed the SLICs design from the original 68000 design to WE32100 but I was no longer associated with anyone working on it by then, so I don't know. Dennis once remarked to a couple of us that the WE32100 was an example of AT&T wanting to make sure it had its own recipe to make processors, but it was not clear it was worth it. BTW: around the same time both AT&T and HP were making their own DRAM too. It was common thinking in management at tech companies - telling folks that they needed to be 'vertically integrated.' But in the case of both HP and AT&T there internally produced DRAM chips cost 2-3 times what the merchant market cost; so besides the investment in the fab (which was huge) it was a pretty expensive insurance policy. That said, this was also the end times for the idea of the 'second source.' Chip manufacturers would be required to license their designs to some one else (for instance AMD was originally Intel's second source). I think HP was using a second source license for their memory, but IIRC AT&T had developed its own because they had higher reliability standards. [-- Attachment #2: Type: text/html, Size: 6115 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] Research UNIX on the AT&T 3B2? 2018-08-24 16:06 ` Clem Cole @ 2018-08-27 15:54 ` Mary Ann Horton 2018-08-27 17:33 ` Clem Cole 0 siblings, 1 reply; 73+ messages in thread From: Mary Ann Horton @ 2018-08-27 15:54 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 3267 bytes --] Inside AT&T (but outside research) there was considerable pressure to use AT&T products (3B, System V, BLIT/5620, Datakit) rather than the externally developing Sun/Ethernet/TCP suite, especially in the mid-late 1980s. We all (mostly) hated them and wanted Suns, but we were told "eat your own dog food." The 3B20 and 3B5 were awful, but the 3B2 had potential. Once we got a working TCP/IP network in Bell Labs the tide turned in favor of Suns. On 08/24/2018 09:06 AM, Clem Cole wrote: > On Fri, Aug 24, 2018 at 11:13 AM Seth Morabito <web@loomcom.com > <mailto:web@loomcom.com>> wrote: > > ... > I've begun to wonder whether 3B2 hardware was used very much > inside of Bell Labs. > > I'd be curious to hear of people that actually used it. AT&T forced > you to buy one with SVR3 as the porting base (I'd have never had > bought the one we had a Stellar otherwise). > The only time I ever knew anyone run one, was to check to see the > behavior of some code/validation testing of RFS /etc/... > > The HW as pretty slow/inflexible compared to 68020/68030 which came > out around the same time, so it was just not interesting - /i.e./ > 'JAWS' - Just another work station' and it did not have a display. > IIRC, it was a server and pretty inflexible in the I/O subsystem for > that use. > Sun would quickly produce the first Sparcs, which as Larry has pointed > out, kicked butt > and were cheaper > . The MIPS chip would emerge > with lots of designs, > and for that matter the 040 and the 386 would appear soon their after > , too. > > I've always felt that the 3Bx series was an example of fighting the > previous war; other than 3B4000 (which had high reliability but other > issues in practice to use it), there was never anything that made them > special - compared to everyone else. > > The only 'successful' product > that I > can > rememberthat used the WE32100 > was the > second version (/a.k.a./product version) of the Blit (Bart's first > version was 68000 IIRC). Does anyone know of another product? I > think I was told the 5ESS > changed > the SLICs > design > from the original 68000 design to WE32100 but I was no > longer associated with anyone working on it by then, so I don't know. > > Dennis once remarked to a couple of us that the WE32100 was an example > of AT&T wanting to make sure it had its own recipe to make processors, > but it was not clear it was worth it. BTW: around the same time both > AT&T and HP were making their own DRAM too. It was common thinking in > management at tech companies - telling folks that they needed to be > 'vertically integrated.' But in the case of both HP and AT&T there > internally produced DRAM chips cost 2-3 times what the merchant market > cost; so besides the investment in the fab (which was huge) it was a > pretty expensive insurance policy. > > That said, this was also the end times for the idea of the 'second > source.' Chip manufacturers would be required to license their > designs to some one else (for instance AMD was originally Intel's > second source). I think HP was using a second source license for > their memory, but IIRC AT&T had developed its own because they had > higher reliability standards. [-- Attachment #2: Type: text/html, Size: 9318 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] Research UNIX on the AT&T 3B2? 2018-08-27 15:54 ` Mary Ann Horton @ 2018-08-27 17:33 ` Clem Cole 2018-08-28 0:24 ` Dave Horsfall 0 siblings, 1 reply; 73+ messages in thread From: Clem Cole @ 2018-08-27 17:33 UTC (permalink / raw) To: Mary Ann Horton; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1736 bytes --] below... On Mon, Aug 27, 2018 at 12:04 PM Mary Ann Horton <mah@mhorton.net> wrote: > Inside AT&T (but outside research) there was considerable pressure to use > AT&T products (3B, System V, BLIT/5620, Datakit) rather than the externally > developing Sun/Ethernet/TCP suite, especially in the mid-late 1980s. We > all (mostly) hated them and wanted Suns, but we were told "eat your own dog > food." > That was always my impression. IIRC Mt. Xinu made a poster (and Kolstad made a series of buttons) stating "4.2 > V" I remember somebody (ber probably) had it hanging in Whippany and certain supervisors were not amsussed. The 3B20 and 3B5 were awful, but the 3B2 had potential. > It was not so much they we awful IMO, is that they were nothing special - too little too late. The 3B20 (the only computer I even knew with a 'pull starter'), was basically a 1MIP 780 and took the same resources (machine room, multiple 19" cabinets, etc); when a 68020 based Masscomp, Apollo or Sun was at 4-5 MIPS and fit under your desk. As I said, fighting the last war. The 3B2 got the size and performance more inline, but the SW was still behind and by them it was arguable if a BLIT over a serial line could compete with the builtin graphics. For the former, did the 3B2 only run SRV3 and SRV4? The others ran SVR0-2 which was not even close to BSD. By SVR3 the OS finally got better. BILT had some great stuff, but I think the shear volume of programmers using X-Windows, particularly once it ran on super cheap HW (*i.e.* Wintel based) it was tough. > Once we got a working TCP/IP network in Bell Labs the tide turned in favor > of Suns > Although by the time of its release, the default system for SRV4 was Wintel. Clem [-- Attachment #2: Type: text/html, Size: 3696 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] Research UNIX on the AT&T 3B2? 2018-08-27 17:33 ` Clem Cole @ 2018-08-28 0:24 ` Dave Horsfall 2018-08-28 0:30 ` Larry McVoy 0 siblings, 1 reply; 73+ messages in thread From: Dave Horsfall @ 2018-08-28 0:24 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 555 bytes --] On Mon, 27 Aug 2018, Clem Cole wrote: > That was always my impression. IIRC Mt. Xinu made a poster (and > Kolstad made a series of buttons) stating "4.2 > V" I remember somebody > (ber probably) had it hanging in Whippany and certain supervisors were > not amsussed. I remember seeing a photo of that button. Somewhere (I think) I have a PS/PDF (or was it a sticker?) of "Intel outside" which I stuck to my SparcStation. Unfortunately the latter part of my career was having to support SysVile and pretending that I liked it... -- Dave ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] Research UNIX on the AT&T 3B2? 2018-08-28 0:24 ` Dave Horsfall @ 2018-08-28 0:30 ` Larry McVoy 2018-08-28 6:01 ` arnold 0 siblings, 1 reply; 73+ messages in thread From: Larry McVoy @ 2018-08-28 0:30 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society On Tue, Aug 28, 2018 at 10:24:12AM +1000, Dave Horsfall wrote: > Unfortunately the latter part of my career was having to support SysVile and > pretending that I liked it... I don't think anyone really liked it. Maybe Roger Faulkner. And there are the Joyent crew. Even they, when I told them I had tried it and wasn't impressed, asked if I had /opt/GNU/bin in my path first? Huh? Decades have gone by, Sun is gone, and they are still cleaning to the compatibilty argument for /usr/bin? SunOS was the system that everyone used because they wanted to, Solaris was what people used because they had to. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] Research UNIX on the AT&T 3B2? 2018-08-28 0:30 ` Larry McVoy @ 2018-08-28 6:01 ` arnold 2018-08-28 22:33 ` Dave Horsfall 0 siblings, 1 reply; 73+ messages in thread From: arnold @ 2018-08-28 6:01 UTC (permalink / raw) To: lm, dave; +Cc: tuhs Larry McVoy <lm@mcvoy.com> wrote: > Decades have gone by, Sun is gone, and they are still cleaning [sic] to the > compatibilty argument for /usr/bin? As hard as it is to believe in this day and age, there are still plenty of places where that compatibility is what sells systems. > SunOS was the system that everyone used because they wanted to, Solaris > was what people used because they had to. Nicely put! Arnold ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] Research UNIX on the AT&T 3B2? 2018-08-28 6:01 ` arnold @ 2018-08-28 22:33 ` Dave Horsfall 2018-08-29 0:36 ` Harald Arnesen 0 siblings, 1 reply; 73+ messages in thread From: Dave Horsfall @ 2018-08-28 22:33 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Tue, 28 Aug 2018, arnold@skeeve.com wrote: > Larry McVoy <lm@mcvoy.com> wrote: [...] >> SunOS was the system that everyone used because they wanted to, Solaris >> was what people used because they had to. > > Nicely put! Signature material, in fact! I loved SunOS 4.1.4, and had to eat a shit sandwich when they went to Solaris (but continue to run BSD-like systems at home; first BSDi, then FreeBSD; the MacBook is at least vaguely BSD-ish, and the only reason that I also have Debian is to see what the penguins have broken this time). -- Dave ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] Research UNIX on the AT&T 3B2? 2018-08-28 22:33 ` Dave Horsfall @ 2018-08-29 0:36 ` Harald Arnesen 2018-08-29 0:46 ` Larry McVoy 0 siblings, 1 reply; 73+ messages in thread From: Harald Arnesen @ 2018-08-29 0:36 UTC (permalink / raw) To: tuhs Dave Horsfall [2018-08-29 00:33]: > Signature material, in fact! I loved SunOS 4.1.4, and had to eat a shit > sandwich when they went to Solaris (but continue to run BSD-like systems > at home; first BSDi, then FreeBSD; the MacBook is at least vaguely > BSD-ish, and the only reason that I also have Debian is to see what the > penguins have broken this time). So you don't think MacOS has broken more than the penguins have? -- Hilsen Harald ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] Research UNIX on the AT&T 3B2? 2018-08-29 0:36 ` Harald Arnesen @ 2018-08-29 0:46 ` Larry McVoy 2018-08-29 5:29 ` [TUHS] SunOS code? arnold 0 siblings, 1 reply; 73+ messages in thread From: Larry McVoy @ 2018-08-29 0:46 UTC (permalink / raw) To: Harald Arnesen; +Cc: tuhs On Wed, Aug 29, 2018 at 02:36:47AM +0200, Harald Arnesen wrote: > Dave Horsfall [2018-08-29 00:33]: > > > Signature material, in fact! I loved SunOS 4.1.4, and had to eat a shit > > sandwich when they went to Solaris (but continue to run BSD-like systems > > at home; first BSDi, then FreeBSD; the MacBook is at least vaguely > > BSD-ish, and the only reason that I also have Debian is to see what the > > penguins have broken this time). > > So you don't think MacOS has broken more than the penguins have? MacOS is based on Mach and Mach was a big steaming mess of promises that were not so much. Easy for me to say, I haven't written a VM system from scratch and they did, so credit them for that. But I've been in a VM system that was oh so much easier to read and understand, the SunOS 4.x VM system done by Joe Moran (mojo@sun.com). That guy had crazy skills, well beyond mine or anyone else I can think of. When he quit the story is that Bill Joy stopped him in the parking lot and offered him crazy amounts of money to stay. So I'd go with MacOS is not a fun kernel. It's pretty close to BSD and I recently wandered through that VM system and I was not impressed. I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't multi processor friendly but someone would have fixed that. The penguin stuff, it's OK. Not as clean as SunOS by a long shot. ^ permalink raw reply [flat|nested] 73+ messages in thread
* [TUHS] SunOS code? 2018-08-29 0:46 ` Larry McVoy @ 2018-08-29 5:29 ` arnold 2018-08-29 14:40 ` Larry McVoy 2018-08-29 14:43 ` Warner Losh 0 siblings, 2 replies; 73+ messages in thread From: arnold @ 2018-08-29 5:29 UTC (permalink / raw) To: skogtun, lm; +Cc: tuhs Changed the subject line. Larry McVoy <lm@mcvoy.com> wrote: > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > and I recently wandered through that VM system and I was not impressed. > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't > multi processor friendly but someone would have fixed that. > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. So, is the SunOS code available in a way that would let people hack on it? They had ported it to 386 (roadrunner?), so maybe it'd be possible to revive it and bring it into the 21st century. Just a thought, Arnold ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-29 5:29 ` [TUHS] SunOS code? arnold @ 2018-08-29 14:40 ` Larry McVoy 2018-08-29 14:41 ` Dan Cross 2018-08-29 14:43 ` Warner Losh 1 sibling, 1 reply; 73+ messages in thread From: Larry McVoy @ 2018-08-29 14:40 UTC (permalink / raw) To: arnold; +Cc: tuhs Sun never open sourced it. On Tue, Aug 28, 2018 at 11:29:15PM -0600, arnold@skeeve.com wrote: > Changed the subject line. > > Larry McVoy <lm@mcvoy.com> wrote: > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > and I recently wandered through that VM system and I was not impressed. > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't > > multi processor friendly but someone would have fixed that. > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > So, is the SunOS code available in a way that would let people hack > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > possible to revive it and bring it into the 21st century. > > Just a thought, > > Arnold -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-29 14:40 ` Larry McVoy @ 2018-08-29 14:41 ` Dan Cross 2018-08-29 14:44 ` William Pechter 2018-08-29 14:45 ` Clem Cole 0 siblings, 2 replies; 73+ messages in thread From: Dan Cross @ 2018-08-29 14:41 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1135 bytes --] I wonder if they would consider doing it now. Oracle, I mean; the Solaris code was opened up and an argument could be made that SunOS would be useful for historical examination. On Wed, Aug 29, 2018 at 10:41 AM Larry McVoy <lm@mcvoy.com> wrote: > Sun never open sourced it. > > On Tue, Aug 28, 2018 at 11:29:15PM -0600, arnold@skeeve.com wrote: > > Changed the subject line. > > > > Larry McVoy <lm@mcvoy.com> wrote: > > > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > > and I recently wandered through that VM system and I was not impressed. > > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it > wasn't > > > multi processor friendly but someone would have fixed that. > > > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > > > So, is the SunOS code available in a way that would let people hack > > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > > possible to revive it and bring it into the 21st century. > > > > Just a thought, > > > > Arnold > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > [-- Attachment #2: Type: text/html, Size: 1816 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-29 14:41 ` Dan Cross @ 2018-08-29 14:44 ` William Pechter 2018-08-29 14:46 ` Warner Losh 2018-08-29 14:45 ` Clem Cole 1 sibling, 1 reply; 73+ messages in thread From: William Pechter @ 2018-08-29 14:44 UTC (permalink / raw) To: Dan Cross, tuhs Didn't they un-open Solaris 11? -----Original Message----- From: Dan Cross <crossd@gmail.com> To: Larry McVoy <lm@mcvoy.com> Cc: TUHS main list <tuhs@minnie.tuhs.org> Sent: Wed, 29 Aug 2018 10:42 Subject: Re: [TUHS] SunOS code? I wonder if they would consider doing it now. Oracle, I mean; the Solaris code was opened up and an argument could be made that SunOS would be useful for historical examination. On Wed, Aug 29, 2018 at 10:41 AM Larry McVoy <lm@mcvoy.com> wrote: > Sun never open sourced it. > > On Tue, Aug 28, 2018 at 11:29:15PM -0600, arnold@skeeve.com wrote: > > Changed the subject line. > > > > Larry McVoy <lm@mcvoy.com> wrote: > > > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > > and I recently wandered through that VM system and I was not impressed. > > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it > wasn't > > > multi processor friendly but someone would have fixed that. > > > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > > > So, is the SunOS code available in a way that would let people hack > > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > > possible to revive it and bring it into the 21st century. > > > > Just a thought, > > > > Arnold > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-29 14:44 ` William Pechter @ 2018-08-29 14:46 ` Warner Losh 0 siblings, 0 replies; 73+ messages in thread From: Warner Losh @ 2018-08-29 14:46 UTC (permalink / raw) To: pechter; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1630 bytes --] They didn't release the sources to Solaris 11. Anything released prior, though, remains free. Warner On Wed, Aug 29, 2018 at 8:44 AM William Pechter <pechter@gmail.com> wrote: > Didn't they un-open Solaris 11? > > -----Original Message----- > From: Dan Cross <crossd@gmail.com> > To: Larry McVoy <lm@mcvoy.com> > Cc: TUHS main list <tuhs@minnie.tuhs.org> > Sent: Wed, 29 Aug 2018 10:42 > Subject: Re: [TUHS] SunOS code? > > I wonder if they would consider doing it now. Oracle, I mean; the Solaris > code was opened up and an argument could be made that SunOS would be useful > for historical examination. > > On Wed, Aug 29, 2018 at 10:41 AM Larry McVoy <lm@mcvoy.com> wrote: > > > Sun never open sourced it. > > > > On Tue, Aug 28, 2018 at 11:29:15PM -0600, arnold@skeeve.com wrote: > > > Changed the subject line. > > > > > > Larry McVoy <lm@mcvoy.com> wrote: > > > > > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > > > and I recently wandered through that VM system and I was not > impressed. > > > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it > > wasn't > > > > multi processor friendly but someone would have fixed that. > > > > > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > > > > > So, is the SunOS code available in a way that would let people hack > > > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > > > possible to revive it and bring it into the 21st century. > > > > > > Just a thought, > > > > > > Arnold > > > > -- > > --- > > Larry McVoy lm at mcvoy.com > > http://www.mcvoy.com/lm > > > [-- Attachment #2: Type: text/html, Size: 2704 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-29 14:41 ` Dan Cross 2018-08-29 14:44 ` William Pechter @ 2018-08-29 14:45 ` Clem Cole 1 sibling, 0 replies; 73+ messages in thread From: Clem Cole @ 2018-08-29 14:45 UTC (permalink / raw) To: Dan Cross; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1365 bytes --] The problem is finding some at Oracle that would care and finding a proper distribution tape to officially release. On Wed, Aug 29, 2018 at 10:42 AM Dan Cross <crossd@gmail.com> wrote: > I wonder if they would consider doing it now. Oracle, I mean; the Solaris > code was opened up and an argument could be made that SunOS would be useful > for historical examination. > > On Wed, Aug 29, 2018 at 10:41 AM Larry McVoy <lm@mcvoy.com> wrote: > >> Sun never open sourced it. >> >> On Tue, Aug 28, 2018 at 11:29:15PM -0600, arnold@skeeve.com wrote: >> > Changed the subject line. >> > >> > Larry McVoy <lm@mcvoy.com> wrote: >> > >> > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD >> > > and I recently wandered through that VM system and I was not >> impressed. >> > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it >> wasn't >> > > multi processor friendly but someone would have fixed that. >> > > >> > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. >> > >> > So, is the SunOS code available in a way that would let people hack >> > on it? They had ported it to 386 (roadrunner?), so maybe it'd be >> > possible to revive it and bring it into the 21st century. >> > >> > Just a thought, >> > >> > Arnold >> >> -- >> --- >> Larry McVoy lm at mcvoy.com >> http://www.mcvoy.com/lm >> > [-- Attachment #2: Type: text/html, Size: 2337 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-29 5:29 ` [TUHS] SunOS code? arnold 2018-08-29 14:40 ` Larry McVoy @ 2018-08-29 14:43 ` Warner Losh 2018-08-29 14:45 ` Warner Losh ` (2 more replies) 1 sibling, 3 replies; 73+ messages in thread From: Warner Losh @ 2018-08-29 14:43 UTC (permalink / raw) To: arnold; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1293 bytes --] On Tue, Aug 28, 2018 at 11:29 PM <arnold@skeeve.com> wrote: > Changed the subject line. > > Larry McVoy <lm@mcvoy.com> wrote: > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > and I recently wandered through that VM system and I was not impressed. > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't > > multi processor friendly but someone would have fixed that. > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > So, is the SunOS code available in a way that would let people hack > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > possible to revive it and bring it into the 21st century. > The Googles tells me there's a dozen download places. SunOS 4.1 doesn't have 386 support in it. It was removed after SunOS 4.0. The Sun RoadRunner wasn't really IBM PC compatible. It had a fair number of incompatible bits included in it. It also had a weird BIOS. There's a lot that's happened in x86 since then. It's unclear how much benefit there would be to having the sources. It looks like you'd be much better off starting with one of the latter-day BSD implementations to do the port, though significant differences exist with the infrastructure so it would be far from a drop-in. Warner [-- Attachment #2: Type: text/html, Size: 1829 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-29 14:43 ` Warner Losh @ 2018-08-29 14:45 ` Warner Losh 2018-08-29 14:53 ` Larry McVoy 2018-08-29 23:09 ` David Arnold 2 siblings, 0 replies; 73+ messages in thread From: Warner Losh @ 2018-08-29 14:45 UTC (permalink / raw) To: arnold; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1783 bytes --] On Wed, Aug 29, 2018 at 8:43 AM Warner Losh <imp@bsdimp.com> wrote: > > > On Tue, Aug 28, 2018 at 11:29 PM <arnold@skeeve.com> wrote: > >> Changed the subject line. >> >> Larry McVoy <lm@mcvoy.com> wrote: >> >> > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD >> > and I recently wandered through that VM system and I was not impressed. >> > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't >> > multi processor friendly but someone would have fixed that. >> > >> > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. >> >> So, is the SunOS code available in a way that would let people hack >> on it? They had ported it to 386 (roadrunner?), so maybe it'd be >> possible to revive it and bring it into the 21st century. >> > > The Googles tells me there's a dozen download places. > > SunOS 4.1 doesn't have 386 support in it. It was removed after SunOS 4.0. > The Sun RoadRunner wasn't really IBM PC compatible. It had a fair number of > incompatible bits included in it. It also had a weird BIOS. > > There's a lot that's happened in x86 since then. It's unclear how much > benefit there would be to having the sources. It looks like you'd be much > better off starting with one of the latter-day BSD implementations to do > the port, though significant differences exist with the infrastructure so > it would be far from a drop-in. > Also, a huge difference is that there's *NO* MP support for SunOS. Solbourne produced OS/MP which was SunOS with fine-grained locking added (I forget the degree to which it was, but IIRC, there were 'funnels' that used locks around the different subsystems (so not one big giant lock), not fine-grained in the sense we use it today. *THAT* source is harder to find online... Warner [-- Attachment #2: Type: text/html, Size: 2537 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-29 14:43 ` Warner Losh 2018-08-29 14:45 ` Warner Losh @ 2018-08-29 14:53 ` Larry McVoy 2018-09-01 11:43 ` Steve Mynott 2018-08-29 23:09 ` David Arnold 2 siblings, 1 reply; 73+ messages in thread From: Larry McVoy @ 2018-08-29 14:53 UTC (permalink / raw) To: Warner Losh; +Cc: TUHS main list On Wed, Aug 29, 2018 at 08:43:09AM -0600, Warner Losh wrote: > On Tue, Aug 28, 2018 at 11:29 PM <arnold@skeeve.com> wrote: > > > Changed the subject line. > > > > Larry McVoy <lm@mcvoy.com> wrote: > > > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > > and I recently wandered through that VM system and I was not impressed. > > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't > > > multi processor friendly but someone would have fixed that. > > > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > > > So, is the SunOS code available in a way that would let people hack > > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > > possible to revive it and bring it into the 21st century. > > > > The Googles tells me there's a dozen download places. > > SunOS 4.1 doesn't have 386 support in it. It was removed after SunOS 4.0. > The Sun RoadRunner wasn't really IBM PC compatible. It had a fair number of > incompatible bits included in it. It also had a weird BIOS. > > There's a lot that's happened in x86 since then. It's unclear how much > benefit there would be to having the sources. It looks like you'd be much > better off starting with one of the latter-day BSD implementations to do > the port, though significant differences exist with the infrastructure so > it would be far from a drop-in. The BSDs have a less than optimal VM system. Having SunOS opened up would at least let people see what they are missing. Maybe I have rose colored glasses on but it was the only kernel that came into focus for me and you could see the architecture from the code. Everything else seems like a mess to me. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-29 14:53 ` Larry McVoy @ 2018-09-01 11:43 ` Steve Mynott 2018-09-01 13:50 ` Andy Kosela 2018-09-01 15:01 ` Larry McVoy 0 siblings, 2 replies; 73+ messages in thread From: Steve Mynott @ 2018-09-01 11:43 UTC (permalink / raw) To: lm; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 956 bytes --] On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm@mcvoy.com> wrote: The BSDs have a less than optimal VM system. Having SunOS opened up > would at least let people see what they are missing. Maybe I have > rose colored glasses on but it was the only kernel that came into > focus for me and you could see the architecture from the code. > Everything else seems like a mess to me. > That may have been true in the late 80s and even early 90s but I'd have thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. I've vague recollections that these all originally used the VM from Mach which did have problems at first. I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 or so. I think the latter two use UVM and FreeBSD improved their Mach one (which has a SunOS kvmish API anyway). I've not seen complaints about modern BSD. S -- Steve Mynott <steve.mynott@gmail.com> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 [-- Attachment #2: Type: text/html, Size: 1537 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 11:43 ` Steve Mynott @ 2018-09-01 13:50 ` Andy Kosela 2018-09-01 14:32 ` Warner Losh 2018-09-01 15:01 ` Larry McVoy 1 sibling, 1 reply; 73+ messages in thread From: Andy Kosela @ 2018-09-01 13:50 UTC (permalink / raw) To: Steve Mynott; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1232 bytes --] On Saturday, September 1, 2018, Steve Mynott <steve.mynott@gmail.com> wrote: > > > On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm@mcvoy.com> wrote: > > The BSDs have a less than optimal VM system. Having SunOS opened up >> would at least let people see what they are missing. Maybe I have >> rose colored glasses on but it was the only kernel that came into >> focus for me and you could see the architecture from the code. >> Everything else seems like a mess to me. >> > > That may have been true in the late 80s and even early 90s but I'd have > thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. > > I've vague recollections that these all originally used the VM from Mach > which did have problems at first. > > I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 > or so. > > I think the latter two use UVM and FreeBSD improved their Mach one (which > has a SunOS kvmish API anyway). I've not seen complaints about modern BSD. > > Wasn't the whole FreeBSD VM rewritten by John Dyson and David Greenman in the mid-late 90's? And then further improved by Matthew Dillon. Unfortunately they are not affiliated with the project anymore. All three had exceptional coding skills. --Andy [-- Attachment #2: Type: text/html, Size: 1878 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 13:50 ` Andy Kosela @ 2018-09-01 14:32 ` Warner Losh 2018-09-04 9:39 ` Andy Kosela 0 siblings, 1 reply; 73+ messages in thread From: Warner Losh @ 2018-09-01 14:32 UTC (permalink / raw) To: Andy Kosela; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2657 bytes --] On Sat, Sep 1, 2018 at 7:50 AM Andy Kosela <akosela@andykosela.com> wrote: > > > On Saturday, September 1, 2018, Steve Mynott <steve.mynott@gmail.com> > wrote: > >> >> >> On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm@mcvoy.com> wrote: >> >> The BSDs have a less than optimal VM system. Having SunOS opened up >>> would at least let people see what they are missing. Maybe I have >>> rose colored glasses on but it was the only kernel that came into >>> focus for me and you could see the architecture from the code. >>> Everything else seems like a mess to me. >>> >> >> That may have been true in the late 80s and even early 90s but I'd have >> thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. >> >> I've vague recollections that these all originally used the VM from Mach >> which did have problems at first. >> > Yes. CSRG used Mach VM because it was available, not because it was awesome. The folks at CSRG approached Sun to have them donate their VM to BSD, and there were serious talks about doing this until the lawyers got involved and explained that would require a serious write down on their quarterly report so that nixed the whole thing. > I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 >> or so. >> > It used to be downright aweful. > I think the latter two use UVM and FreeBSD improved their Mach one (which >> has a SunOS kvmish API anyway). I've not seen complaints about modern BSD. >> > OpenBSD and NetBSD both moved to uvm. > Wasn't the whole FreeBSD VM rewritten by John Dyson and David Greenman in > the mid-late 90's? And then further improved by Matthew Dillon. > > Unfortunately they are not affiliated with the project anymore. All three > had exceptional coding skills. > With the exception of David, it's not unfortunate at all. Although they were good for the project's code, they weren't good for the project. They didn't work well with others and caused much more grief than the code they contributed. There comes a time when there's just too much drama and the rest of the code gets much much better when you aren't always fighting drama :(. It was a tough decision to make when I was on the core team to show Dillon the door. One not made lightly, nor without a lot of effort to work through the issues. In the end, though, we had to part ways. Dillon has done well with DragonFly, however. In the last 10 years or so there's been a number of people that have stepped up and replaced them, most notably Allan Cox and Mark Johnston who have mad coding skills and can play well with others. Though I'm sure I'm slighting several people by not mentioning them. Warner [-- Attachment #2: Type: text/html, Size: 4270 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 14:32 ` Warner Losh @ 2018-09-04 9:39 ` Andy Kosela 0 siblings, 0 replies; 73+ messages in thread From: Andy Kosela @ 2018-09-04 9:39 UTC (permalink / raw) To: Warner Losh; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2775 bytes --] On Saturday, September 1, 2018, Warner Losh <imp@bsdimp.com> wrote: > > > On Sat, Sep 1, 2018 at 7:50 AM Andy Kosela <akosela@andykosela.com> wrote: > >> >> >> On Saturday, September 1, 2018, Steve Mynott <steve.mynott@gmail.com> >> wrote: >> >>> >>> >>> On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm@mcvoy.com> wrote: >>> >>> The BSDs have a less than optimal VM system. Having SunOS opened up >>>> would at least let people see what they are missing. Maybe I have >>>> rose colored glasses on but it was the only kernel that came into >>>> focus for me and you could see the architecture from the code. >>>> Everything else seems like a mess to me. >>>> >>> >>> That may have been true in the late 80s and even early 90s but I'd have >>> thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. >>> >>> I've vague recollections that these all originally used the VM from Mach >>> which did have problems at first. >>> >> > Yes. CSRG used Mach VM because it was available, not because it was > awesome. The folks at CSRG approached Sun to have them donate their VM to > BSD, and there were serious talks about doing this until the lawyers got > involved and explained that would require a serious write down on their > quarterly report so that nixed the whole thing. > > >> I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 >>> or so. >>> >> > It used to be downright aweful. > > >> I think the latter two use UVM and FreeBSD improved their Mach one (which >>> has a SunOS kvmish API anyway). I've not seen complaints about modern BSD. >>> >> > OpenBSD and NetBSD both moved to uvm. > > >> Wasn't the whole FreeBSD VM rewritten by John Dyson and David Greenman in >> the mid-late 90's? And then further improved by Matthew Dillon. >> >> Unfortunately they are not affiliated with the project anymore. All >> three had exceptional coding skills. >> > > With the exception of David, it's not unfortunate at all. Although they > were good for the project's code, they weren't good for the project. They > didn't work well with others and caused much more grief than the code they > contributed. There comes a time when there's just too much drama and the > rest of the code gets much much better when you aren't always fighting > drama :(. It was a tough decision to make when I was on the core team to > show Dillon the door. One not made lightly, nor without a lot of effort to > work through the issues. In the end, though, we had to part ways. Dillon > has done well with DragonFly, however. > Well, there are certainly as many sides to this story as there are people involved. Same with NetBSD/OpenBSD split. Let's leave it as that as I don't believe we have mentioned people on this list so they can't defend themselves. --Andy [-- Attachment #2: Type: text/html, Size: 4490 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 11:43 ` Steve Mynott 2018-09-01 13:50 ` Andy Kosela @ 2018-09-01 15:01 ` Larry McVoy 2018-09-01 15:20 ` Warner Losh 1 sibling, 1 reply; 73+ messages in thread From: Larry McVoy @ 2018-09-01 15:01 UTC (permalink / raw) To: Steve Mynott; +Cc: TUHS main list On Sat, Sep 01, 2018 at 12:43:52PM +0100, Steve Mynott wrote: > On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm@mcvoy.com> wrote: > The BSDs have a less than optimal VM system. Having SunOS opened up > > would at least let people see what they are missing. Maybe I have > > rose colored glasses on but it was the only kernel that came into > > focus for me and you could see the architecture from the code. > > Everything else seems like a mess to me. > > > > That may have been true in the late 80s and even early 90s but I'd have > thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. I wandered through the FreeBSD VM recently. Perhaps I'm just old and tired but it looked pretty messy to me. Still Mach based and the Mach VM system, which came about at about the same time as the SunOS VM system, doesn't remotely compare. Sun had some exceptional talent at the time, there was a reason I fought hard to join that group, I wanted to work with people who were better than me. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 15:01 ` Larry McVoy @ 2018-09-01 15:20 ` Warner Losh 2018-09-01 18:24 ` Steve Mynott 0 siblings, 1 reply; 73+ messages in thread From: Warner Losh @ 2018-09-01 15:20 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2968 bytes --] On Sat, Sep 1, 2018 at 9:01 AM Larry McVoy <lm@mcvoy.com> wrote: > On Sat, Sep 01, 2018 at 12:43:52PM +0100, Steve Mynott wrote: > > On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm@mcvoy.com> wrote: > > The BSDs have a less than optimal VM system. Having SunOS opened up > > > would at least let people see what they are missing. Maybe I have > > > rose colored glasses on but it was the only kernel that came into > > > focus for me and you could see the architecture from the code. > > > Everything else seems like a mess to me. > > > > > > > That may have been true in the late 80s and even early 90s but I'd have > > thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. > > I wandered through the FreeBSD VM recently. Perhaps I'm just old and > tired but it looked pretty messy to me. Still Mach based and the > Mach VM system, which came about at about the same time as the SunOS > VM system, doesn't remotely compare. Sun had some exceptional > talent at the time, there was a reason I fought hard to join that > group, I wanted to work with people who were better than me. > It is still technically mach based, but it's fixed most of the scalability issues Mach had (and that MacOS still has). There's much clutter in the VM, and there's areas that could stand to be rewritten, or to get at least a good cleaning. The SunOS vm was far superior in its day, and likely is still cleaner than what's in FreeBSD. But it can't scale like FreeBSD's vm (or NetBSD's or even MacOS's) because it hasn't had the same care and feeding for the last 25 years. It's still single threaded and hasn't had the care and feeding to make it perform well in MP situations. Solbourne spent years hacking it to make it scale better, but even with 16 processors that was the high end for them, and they were barely 10x faster than a uniprocessor for many work loads due, in part, to vm contention limiting scalability. We had 2 8 CPU machines that could build our software ~20% faster (with netmake) than the 1 16 CPU machine the OS group had, for example... I recall many discussions with Dave Barak who did the fine-grained work on the 4.0 SunOS kernel complaining about how many of the clever tricks in different subsystems that worked great on UP were terrible for MP... I don't doubt we'd be in an even better place today if we'd started with the SunOS vm system in 4.4BSD rather than mach. Don't get me wrong. And I'll not be the first in line to defend its elegance or clarity of design (in fact, it has many design issues that took a decade to recode to properly scale, and we're still not done). And lord knows even though I'm not close to the foremost expert in the vm, I could easily put together an hour or two talk on how all the areas of the VM that are holding us back. Yet even with all that, I think that the ugly, warty, co-evolved code we have in FreeBSD performs better than the SunOS vm code on any objective benchmark you could have. Warner [-- Attachment #2: Type: text/html, Size: 3570 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 15:20 ` Warner Losh @ 2018-09-01 18:24 ` Steve Mynott 2018-09-01 18:38 ` Larry McVoy 0 siblings, 1 reply; 73+ messages in thread From: Steve Mynott @ 2018-09-01 18:24 UTC (permalink / raw) To: Warner Losh; +Cc: TUHS main list There is a paper on the SunOS 4 VM available at <https://web.archive.org/web/20000817230720/http://www.sun.com/smcc/solaris-migration/docs/postscript/vm-impl.ps> (for some reason I always forget the ghostview binary is actually called gv the rare time I use it!) Some basic grepping suggests at least some of the tags in the paper were still in use in Open Solaris at: <https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/vm> There is a paper on UVM as well. <https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf> This says the original 4.4BSD Mach VM suffered from "swap memory leak deadlock" and claims of its sibling (at least in 1999) that although the FreeBSD VM is improved that "it still suffers from the object chaining model it inherited". The FreeBSD VM was documented before 2013 in <https://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/article.html> "Much of the apparent complexity of the FreeBSD design, especially in the VM/Swap subsystem, is a direct result of having to solve serious performance issues that occur under various conditions." -- Steve Mynott <steve.mynott@gmail.com> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-09-01 18:24 ` Steve Mynott @ 2018-09-01 18:38 ` Larry McVoy 0 siblings, 0 replies; 73+ messages in thread From: Larry McVoy @ 2018-09-01 18:38 UTC (permalink / raw) To: Steve Mynott; +Cc: TUHS main list All of those papers are here: http://mcvoy.com/lm/papers/ SunOS.nvram.pdf SunOS.shlib.pdf SunOS.smoosh.pdf SunOS.tfs.pdf SunOS.ufs_clustering.pdf SunOS.vfs_arch.pdf SunOS.vm_arch.pdf SunOS.vm_impl.pdf If you have pointers to a paper that is Sun related that I don't have I'd like to see that. > <https://web.archive.org/web/20000817230720/http://www.sun.com/smcc/solaris-migration/docs/postscript/vm-impl.ps> > > There is a paper on UVM as well. > > <https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf> That's interesting, reading. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [TUHS] SunOS code? 2018-08-29 14:43 ` Warner Losh 2018-08-29 14:45 ` Warner Losh 2018-08-29 14:53 ` Larry McVoy @ 2018-08-29 23:09 ` David Arnold 2 siblings, 0 replies; 73+ messages in thread From: David Arnold @ 2018-08-29 23:09 UTC (permalink / raw) To: Warner Losh; +Cc: TUHS main list [-- Attachment #1.1: Type: text/plain, Size: 1136 bytes --] > On 30 Aug 2018, at 00:43, Warner Losh <imp@bsdimp.com> wrote: > On Tue, Aug 28, 2018 at 11:29 PM <arnold@skeeve.com <mailto:arnold@skeeve.com>> wrote: > Changed the subject line. > > Larry McVoy <lm@mcvoy.com <mailto:lm@mcvoy.com>> wrote: > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > and I recently wandered through that VM system and I was not impressed. > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't > > multi processor friendly but someone would have fixed that. > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > So, is the SunOS code available in a way that would let people hack > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > possible to revive it and bring it into the 21st century. > > The Googles tells me there's a dozen download places. I found both 4.1.4 (aka Solaris 1.1.2) and 4.1.3 (which still has the m68k, sun2, and sun3 bits in it). It’d be quite fun to walk through Bill & Lynne Jolitz’ Dr Dobbs 386BSD articles but with one of these as the starting point. d [-- Attachment #1.2: Type: text/html, Size: 2143 bytes --] [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
end of thread, other threads:[~2018-09-06 0:40 UTC | newest] Thread overview: 73+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-30 19:41 [TUHS] SunOS code? Noel Chiappa 2018-08-30 19:46 ` Larry McVoy 2018-08-30 20:04 ` Warner Losh 2018-08-30 20:22 ` Larry McVoy 2018-08-30 20:33 ` Clem Cole 2018-08-30 20:36 ` Larry McVoy 2018-08-30 20:40 ` Clem Cole 2018-08-30 20:43 ` Larry McVoy 2018-08-30 20:38 ` Warner Losh 2018-08-30 20:42 ` Larry McVoy 2018-08-30 20:43 ` Clem Cole 2018-08-30 20:37 ` Clem Cole 2018-08-31 5:49 ` Lars Brinkhoff 2018-08-31 9:50 ` Dave Horsfall 2018-08-31 11:01 ` Gregg Levine 2018-08-31 11:05 ` Lars Brinkhoff -- strict thread matches above, loose matches on Subject: below -- 2018-09-04 17:58 Noel Chiappa 2018-09-06 0:39 ` Dave Horsfall 2018-08-30 21:34 Noel Chiappa 2018-08-31 1:59 ` Kevin Bowling 2018-08-31 21:34 ` Cág 2018-08-31 21:39 ` Clem Cole 2018-08-31 21:47 ` Arthur Krewat 2018-08-31 21:57 ` Warner Losh 2018-08-31 21:58 ` Larry McVoy 2018-08-31 22:02 ` Warner Losh 2018-08-31 22:19 ` Cág 2018-08-31 22:23 ` Jon Forrest 2018-08-31 22:30 ` Cág 2018-08-31 22:34 ` Jon Forrest 2018-09-01 10:46 ` Donald ODona 2018-08-31 22:20 ` Cág 2018-08-31 23:02 ` Arthur Krewat 2018-09-01 1:57 ` Larry McVoy 2018-09-01 3:23 ` Theodore Y. Ts'o 2018-09-01 16:29 ` Kevin Bowling 2018-09-01 16:35 ` Larry McVoy 2018-09-01 19:32 ` Clem Cole 2018-09-01 16:27 ` Kevin Bowling 2018-09-01 17:17 ` Arthur Krewat 2018-09-01 22:19 ` Theodore Y. Ts'o 2018-09-02 5:05 ` Kevin Bowling 2018-09-02 19:43 ` Theodore Y. Ts'o 2018-09-04 11:47 ` Kevin Bowling 2018-09-04 17:39 ` Gilles Gravier 2018-09-04 17:45 ` Henry Bent 2018-09-05 6:31 ` Gilles Gravier 2018-09-05 12:55 ` Arthur Krewat 2018-09-05 15:26 ` Warner Losh 2018-09-05 15:36 ` Chet Ramey 2018-09-05 15:43 ` Arthur Krewat 2018-09-05 23:40 ` Dave Horsfall 2018-09-05 0:10 ` Tony Finch 2018-08-30 19:54 Noel Chiappa 2018-08-30 20:05 ` Earl Baugh 2018-08-24 15:13 [TUHS] Research UNIX on the AT&T 3B2? Seth Morabito 2018-08-24 16:06 ` Clem Cole 2018-08-27 15:54 ` Mary Ann Horton 2018-08-27 17:33 ` Clem Cole 2018-08-28 0:24 ` Dave Horsfall 2018-08-28 0:30 ` Larry McVoy 2018-08-28 6:01 ` arnold 2018-08-28 22:33 ` Dave Horsfall 2018-08-29 0:36 ` Harald Arnesen 2018-08-29 0:46 ` Larry McVoy 2018-08-29 5:29 ` [TUHS] SunOS code? arnold 2018-08-29 14:40 ` Larry McVoy 2018-08-29 14:41 ` Dan Cross 2018-08-29 14:44 ` William Pechter 2018-08-29 14:46 ` Warner Losh 2018-08-29 14:45 ` Clem Cole 2018-08-29 14:43 ` Warner Losh 2018-08-29 14:45 ` Warner Losh 2018-08-29 14:53 ` Larry McVoy 2018-09-01 11:43 ` Steve Mynott 2018-09-01 13:50 ` Andy Kosela 2018-09-01 14:32 ` Warner Losh 2018-09-04 9:39 ` Andy Kosela 2018-09-01 15:01 ` Larry McVoy 2018-09-01 15:20 ` Warner Losh 2018-09-01 18:24 ` Steve Mynott 2018-09-01 18:38 ` Larry McVoy 2018-08-29 23:09 ` David Arnold
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).