From imp at bsdimp.com Fri Jun 3 12:09:55 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 2 Jun 2022 20:09:55 -0600 Subject: [TUHS] Historical application software In-Reply-To: <9F17E4E7-37F3-43B7-A090-CEAFB2F51EDF@eschatologist.net> References: <64EEED76-2EBB-4D55-ADE4-DEDFAC391322@planet.nl> <66ae3ff2-bd07-e192-a00f-f9c701d857c8@spamtrap.tnetconsulting.net> <9F17E4E7-37F3-43B7-A090-CEAFB2F51EDF@eschatologist.net> Message-ID: On Thu, Jun 2, 2022, 8:00 PM Chris Hanson wrote: > On May 28, 2022, at 5:57 PM, Warner Losh wrote: > > > > HP-UX had a weird form of COFF in the early days. IBM AIX had its own > thing that wasn't quite COFF, nor was it quite a.out. Apollo also had a > variation on COFF that wasn't quite standard. I wrote a symbol mangler for > all of these in the early 90s and each one was its own special snowflake. > > HP initially used its own object file format for 32-bit PA-RISC, whether > running HP-UX or MPE. I believe it's still the format the ROM expects for > anything bootable, at least it is for my MPE-capable A400. > > IBM's COFF for AIX on POWER and PowerPC was XCOFF, which was also used as > the initial object file format (though not executable format) for the Power > Macintosh. Apple's Preferred Executable Format was essentially a mechanical > translation away from IBM's XCOFF; the initial toolchains produced .o files > and then a "final" binary in XCOFF format, and then ran a MakePEF tool on > that to produce the PEF binary for an executable or shared library. I > believe Be, due in part to their heritage and toolchains, also used PEF for > BeOS on PowerPC. > > And then there's the "b.out" format used by i960… > There were a number of b.out formats used by PC C compilers... Warner -- Chris > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jun 4 08:19:45 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 3 Jun 2022 16:19:45 -0600 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220603202330.f4spdxyn34uiyy5v@illithid> Message-ID: On Fri, Jun 3, 2022 at 3:21 PM Tom Ivar Helbekkmo via TUHS wrote: > Clem Cole writes: > > > Some of us on this list remember the original BDSi fight, the 386BSD > > to FreeBSD, then NetBSD and OpenBSD (I was friends with both sides of > > many of these wars). > > Irrelevant to the topic, I know, but I'd just like to point out, since > you call these things "wars", that NetBSD grew out of 386bsd in a quiet, > friendly fashion, and then FreeBSD out of NetBSD just as quietly. (BSDi > growing out of 386bsd was a completely separate affair that I know very > little about, and the OpenBSD fork from NetBSD was mostly just a > personal animosity thing, Theo de Raadt having made enemies in both the > NetBSD and FreeBSD camps -- but it has left no bad blood behind it.) > My recollection was that FreeBSD grew out of the patch kits in parallel to NetBSD growing out of the patch kits, but with the CVS repos hosted on the same host before each project got their own hosting... The CVS history shows FreeBSD started with NET/2 and then added in the patchkit changes added to it. I know that the family tree file says otherwise, but I've not seen convincing evidence that is really how things happened (either as an outsider observing at the time, nor via extant artifacts that would show such a relationship). NetBSD did ship their first release before FreeBSD, however. My recollection from the time of the collegiality of the split differs somewhat from yours, however. > In other words, no wars that I know of. > There were a number of shenanigans (like moving the license text to the end of files) at the time. And you never got a call at 4am from Theo demanding that you stop a FreeBSD user from saying bad things about OpenBSD... So maybe not "wars," as such, but it wasn't all sweetness and light... > That being said, I sincerely wish you all the best working out a > solution that can allow the amazingly good simh project to continue! > Yes. This looks nothing at all like the early BSD days. this looks to be a proactive attempt to take the sprawling number of forks that have happened and bring some order to it so that they don't proliferate too much. As a long-time open source governance wonk in the FreeBSD project, I like what I see. Warner > -tih > -- > Most people who graduate with CS degrees don't understand the significance > of Lisp. Lisp is the most important idea in computer science. --Alan Kay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jun 4 08:26:54 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 3 Jun 2022 16:26:54 -0600 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: <20220603213215.GO10240@mcvoy.com> References: <20220603202330.f4spdxyn34uiyy5v@illithid> <20220603213215.GO10240@mcvoy.com> Message-ID: On Fri, Jun 3, 2022 at 3:32 PM Larry McVoy wrote: > On Fri, Jun 03, 2022 at 11:20:58PM +0200, Tom Ivar Helbekkmo via TUHS > wrote: > > Clem Cole writes: > > > > > Some of us on this list remember the original BDSi fight, the 386BSD > > > to FreeBSD, then NetBSD and OpenBSD (I was friends with both sides of > > > many of these wars). > > > > Irrelevant to the topic, I know, but I'd just like to point out, since > > you call these things "wars", that NetBSD grew out of 386bsd in a quiet, > > friendly fashion, and then FreeBSD out of NetBSD just as quietly. (BSDi > > growing out of 386bsd was a completely separate affair that I know very > > little about, and the OpenBSD fork from NetBSD was mostly just a > > personal animosity thing, Theo de Raadt having made enemies in both the > > NetBSD and FreeBSD camps -- but it has left no bad blood behind it.) > > > > In other words, no wars that I know of. > > Umm, were you there? I was a BSD guy before I turned to Linux and I > turned to Linux because of those wars. There is no good reason to have > {386,Free,Net,Open,DragonFly}bsd other than, as Linus stated, "Nobody > could decide who would drive the big red fire truck so now they each > have their own toy fire truck that they drive around". > > BSD would have won if there was a Linus for BSD. There was not so you > got all this replicated effort, the BSD community effectively divided > and conquered themselves. > > It was, and is, a train wreck. It's the poster child for how not to > manage a project. > > I did BitKeeper for Linus because he refused to use any crappy source > management solution and people like Dave Miller were threatening to > fork just so they had some solution. I did that because a forked Linux > would turn into the same mess of {386,Free,Net,Open,DragonFly}bsd which > is obviously not remotely close to ideal. Far from it. > 386BSD died because its founder couldn't deal with collaboration. He tried to be dictator and that failed because he didn't accept other people's collaboration out of worries he couldn't sell 386BSD. NetBSD and FreeBSD took up the charge for a free and open system. I'll agree it was unfortunate that there was a split since NetBSD focused on portability and FreeBSD focused on fastest possible i386/i486 code. I'd suggest, though, that the USL lawsuit cast a huge pall on things and introduced enough uncertainty to further derail things. Had it not been for that additional blow, things would have turned out differently. OpenBSD and Dragonfly BSD didn't split until years later and also represented differences of opinion on where to take the focus of the system (OpenBSD thought the NetBSD folks didn't take security seriously enough and the DFBSD folks thought the efforts to make a parallel kernel in FreeBSD were off track and should be done completely differently). > I lived through all of that, I was an active kernel developer at Sun, > SGI and elsewhere. I would have loved to have seen the SunOS VM system > ported to 4.x BSD and that been the default answer for a kernel. Instead > we got Linux, which has it's positive points for sure, but it also has > decided to let every feature imaginable into the kernel. > We wound up with MACH in BSD because when Sun tried to donate their VM code to Berkeley, the corporate lawyers said no. It was giving away too much shareholder value, and would result in a huge write-off which would, one would presume, negatively affect the stock price. Had this donation actually transpired, 386BSD would have had a bigger advantage from the get go... Oh well Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jun 4 08:33:00 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 3 Jun 2022 16:33:00 -0600 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220603202330.f4spdxyn34uiyy5v@illithid> <20220603213215.GO10240@mcvoy.com> <20220603214032.GQ10240@mcvoy.com> Message-ID: On Fri, Jun 3, 2022 at 4:17 PM Tom Ivar Helbekkmo via TUHS wrote: > Larry McVoy writes: > > >> I do not agree. Linux won because BSD was embroiled in litigation. > > > > Like I said, we experienced that differently. In my opinion, people lean > > on the litigation excuse when they don't want to admit that *BSD was not > > a good way to do operating system development. > > What were the differences? The BSD projects were: > > - 386bsd: run by Jolitz, with no input from anyone else > - NetBSD: forked from 386bsd, run by Chris de Metriou as a > cooperative effort between a host of indviduals (me included) > - FreeBSD: forked from NetBSD almost immediately, by a group of > contributors who felt that performance and device support on the Intel > platform was more important than maintaining hardware portability > The FreeBSD 1.x CVS tree shows that it started from NET/2 with the patchkit added on. It didn't start from the NetBSD tree that I've been able to find (and I've studied the early CVS history for the git migration extensively). And oral history from many of the founders who were also patchkit contributors also matches this recounting... Though I guess a lot turns on whether you consider the patchkit early NetBSD or not... I do agree with the rest of this, though. > - OpenBSD: forked from NetBSD after de Raadt established a kind of > record by being kicked off both the NetBSD and FreeBSD mailing lists. > OpenBSD forked from NetBSD after Theo had a personality dispute with the NetBSD folks. It had little to do with the FreeBSD lists judging from his email at the time and my early interactions with that project. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jun 4 08:52:52 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 3 Jun 2022 16:52:52 -0600 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: <20220603223014.GS10240@mcvoy.com> References: <20220603202330.f4spdxyn34uiyy5v@illithid> <20220603213215.GO10240@mcvoy.com> <20220603214032.GQ10240@mcvoy.com> <20220603223014.GS10240@mcvoy.com> Message-ID: On Fri, Jun 3, 2022 at 4:30 PM Larry McVoy wrote: > On Sat, Jun 04, 2022 at 12:16:49AM +0200, Tom Ivar Helbekkmo wrote: > > Larry McVoy writes: > > > > >> I do not agree. Linux won because BSD was embroiled in litigation. > > > > > > Like I said, we experienced that differently. In my opinion, people > lean > > > on the litigation excuse when they don't want to admit that *BSD was > not > > > a good way to do operating system development. > > > > What were the differences? The BSD projects were: > > > > - 386bsd: run by Jolitz, with no input from anyone else > > - NetBSD: forked from 386bsd, run by Chris de Metriou as a > > cooperative effort between a host of indviduals (me included) > > - FreeBSD: forked from NetBSD almost immediately, by a group of > > contributors who felt that performance and device support on the Intel > > platform was more important than maintaining hardware portability > > - OpenBSD: forked from NetBSD after de Raadt established a kind of > > record by being kicked off both the NetBSD and FreeBSD mailing lists. > > > > I'm open to contradicting arguments, but I do feel that the BSD platform > > was a much better starting point back then, and ought to have won - but > > Linux, while inferior, was available and non-threatening. > > Dude, I was there. Jolitz used to work for me at Sun, Theo's Sun 4/470 > was given to him by me, I know most of the players. > > I agree BSD was a better starting point if there was one BSD. > > The problem is there was {386,Net,Free,Open,DragonFly}BSD where there > should have just been "BSD". One, not a bunch. > Except from 1993-1996 there were only two of those BSDs. NetBSD and FreeBSD forked in 1993 due to the inability of the patchkit to adequately cover the problems in 386BSD governance. OpenBSD didn't fork until late 1995 or early 1996 depending on when you count such things (Theo's firey email, or the first release). Drangonfly BSD didn't fork until a decade later in 2004 due to a dispute in how to make FreeBSD's kernel SMP. And 386BSD stopped being a thing in 1993 when Jolitz disappeared from public view and NetBSD/FreeBSD filled the free vacuum that created and BSDi with BSD/386 filled the commercial space. > Where do you think Linux would be if there was {A,B,C,D,E,F,G}Linux? > There is one kernel. One and only one. With everyone working on that > one kernel. > Except there never really was only one kernel. There have been hundreds of forks of the Linux kernel over the years. Most of them have been commercial of some flavor (Redhat, Debian, OpenSUSE, MontaVista, WindRiver, Android etc) had hundreds or thousands of patches on the base Linux kernel for a long time and trying to move from one to another if you also had patches was a nightmare. Kernel.org has kept going, and many of the chanages from these systems were lost. Some were not as good as what came in upstream, while others were encumbered by commercial contracts that made them unappealing to upstream. True, many of them did wind up in kernel.org, but to say there aren't forks in Linux is stretching reality a bit... > If you can't see the difference, I don't know what to tell you. Are you > seriously going to take the position that BSD is better off because > it has all these variants and replicated effort? Because if you are, > this conversation is over, at least from my point of view. > I think Linux's greatest strengths were the different distributions, though at times it causes a great deal of duplicated effort. They allowed different communities the room to customize things in an easy way. I believe that, more than one kernel, has been a driver of innovation. But honestly, the litigation was a deal killer for many BSD users in the early days, and that gave Linux room to grow. Had the BSDs not faced the competition from Linux and had similar resources poured into them, the NetBSD/FreeBSD split would have been good competition, much as there's good competition between Debian, Redhat, Suse, Canonical, etc today in the Linux space which helps to drive innovation. Even today, with the benefit of hindsight, it's hard to pin which of these facts on the ground was the biggest driver for most people... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jun 4 08:56:51 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 3 Jun 2022 16:56:51 -0600 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220603202330.f4spdxyn34uiyy5v@illithid> <20220603213215.GO10240@mcvoy.com> <20220603214032.GQ10240@mcvoy.com> Message-ID: On Fri, Jun 3, 2022 at 4:40 PM Tom Ivar Helbekkmo wrote: > Warner Losh writes: > > > The FreeBSD 1.x CVS tree shows that it started from NET/2 with the > > patchkit added on. It didn't start from the NetBSD tree that I've been > > able to find (and I've studied the early CVS history for the git > > migration extensively). > > Yeah, I guess it might be better to say that after Chris took the > initiative to create a fork, which he named NetBSD, of Jolitz's 386bsd, > it was decided that there would be two forks; NetBSD and FreeBSD, with > slightly differing objectives. > Yea, there were a number of folks that contributed to the patchkit as well. Chris did a good thing to try to bring order to that chaos, there is no doubt, but Nate Williams, Paul Richards and others were big contributors to the patchkit and the lines of what happened where were somewhat blurry at the time as people discovered they were working at cross purposes and/or had issues working with some people.... Thankfully, for the most part the high levels of animosity that developed in the early 90s between the BSD projects have largely faded away as new groups of developers have joined the projects... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jun 4 10:10:46 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 3 Jun 2022 18:10:46 -0600 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: <20220603234822.GV10240@mcvoy.com> References: <20220603202330.f4spdxyn34uiyy5v@illithid> <20220603213215.GO10240@mcvoy.com> <20220603214032.GQ10240@mcvoy.com> <20220603223014.GS10240@mcvoy.com> <20220603234822.GV10240@mcvoy.com> Message-ID: On Fri, Jun 3, 2022, 5:48 PM Larry McVoy wrote: > On Fri, Jun 03, 2022 at 04:52:52PM -0600, Warner Losh wrote: > > > The problem is there was {386,Net,Free,Open,DragonFly}BSD where there > > > should have just been "BSD". One, not a bunch. > > > > > > > Except from 1993-1996 there were only two of those BSDs. NetBSD and > FreeBSD > > forked in 1993 due to the inability of the patchkit to adequately cover > the > > problems > > in 386BSD governance. > > Um, so there were 3: 386, Net and Free. That's already 2 too many. > No. 386BSD died before then. > > Where do you think Linux would be if there was {A,B,C,D,E,F,G}Linux? > > > There is one kernel. One and only one. With everyone working on that > > > one kernel. > > > > Except there never really was only one kernel. There have been hundreds > > of forks of the Linux kernel over the years. Most of them have been > > commercial > > of some flavor (Redhat, Debian, OpenSUSE, MontaVista, WindRiver, Android > > etc) > > had hundreds or thousands of patches on the base Linux kernel for a long > > time > > and trying to move from one to another if you also had patches was a > > nightmare. > > So I had a successful commercial product that ran on all of those variants > without issue. I supported linux on everything from ARM to IBM's z-system > mainframes and all the arches inbetween. I think I have one #ifdef SPARC > in there because there was a cache flush bug but that was a hardware issue, > not a software issue. > > I also supported {Free,Net,Open}BSD and I had way more problems with them > than I did with Linux. > > > Kernel.org has kept going, and many of the chanages from these systems > were > > lost. > > Some were not as good as what came in upstream, while others were > encumbered > > by commercial contracts that made them unappealing to upstream. True, > many > > of > > them did wind up in kernel.org, but to say there aren't forks in Linux > is > > stretching > > reality a bit... > > There is one kernel development stream that matters. RedHat knows that > if they don't get their stuff into Linus' tree, they have a nightmare > on their hands. That's why RedHat paid so many of the kernel developers. > > Sure, there are forks, but there is one tree that matters, and that is > Linus' tree. You can't say that about BSD and that is the problem in > it's entirety. If I want to change BSD, which one? > By your standards, only FreeBSD matters... so that's easy.. but you already said Redhat is all that matters... and that kernel differs somewhat from Linus'. Ditto if you are dealing with Android... it's not just one Linux and never has been. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Jun 6 11:02:33 2022 From: imp at bsdimp.com (Warner Losh) Date: Sun, 5 Jun 2022 19:02:33 -0600 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220603213215.GO10240@mcvoy.com> <20220603214032.GQ10240@mcvoy.com> <20220603223014.GS10240@mcvoy.com> <20220603234822.GV10240@mcvoy.com> <20220604010543.GZ10240@mcvoy.com> Message-ID: On Sun, Jun 5, 2022 at 6:32 PM Theodore Ts'o wrote: > On Fri, Jun 03, 2022 at 06:05:43PM -0700, Larry McVoy wrote: > > > > So in all of this, the thing that keeps getting missed is Linux won. > > And it didn't win because of the lawsuit, it didn't get crushed by the > > GPL that all the BSD people hate so much, it won on merits. And it > > won because there was one Linux kernel. You could, and I have many, > > many times, just clone the latest kernel and compile and install on > > any distribution. It worked. The same was never true for all the BSD > > variants. Tell me about the times you cloned the OpenBSD kernel and > > it worked on FreeBSD. I'm maybe sure there was maybe one point in time > > where that worked but then for all the other points in time it didn't. > > So in essence what you're saying is that OpenBSD and FreeBSD weren't > ABI compatible, and that's your definition of when two OS's are > different. And so when Warner says that there are hundreds of forks > of the Linux kernel, to the extent that the ABI's are compatible, they > really aren't "different". > Yes. The forks might not have been bad, and there's always some logical fallacy presented to say they are somehow the "same" because of some artificial criteria. And I'm not convinced all the forks are bad, per se. Just that the narrative that says there's only one is false and misleading in some ways because there always was a diversity of 'add in' patches for different distributions, both commercial and hobbyist... Much, but by no means all, of that wound up upstream, though not always the best and the reasons for rejection could be arbitrary at times, or just made too hard to bother trying to upstream at others. There was something in the diversity, though, that I'll readily admit was beneficial. > Part of this comes from the the fact that the Linux kernel, C library, > and core utilities are all shipped separately. The BSDs have often > criticized this, claiming that shipping all of the OS in a single > source control system makes it easier to rollout new features. There > is no doubt upsides from having a single source tree; but one of the > advantages of keeping things separate is that definition of the kernel > <-> userspace interface is much more explicit. > > That being said, I will note that this always hasn't been true. There > was a brief period where an early Red Hat Enterprise Linux version > suffered from the "legacy Unix value-add disease", where Red Hat had > added some kernel changes that impacted kernel interfaces, which > didn't make it upstream, or made it upstream with a changed interface, > such that when users wanted to use a newer upstream kernel, which had > newer features, and newer device driver support, it wouldn't work with > that version RHEL. Red Hat has criticized *heavily* for that, both by > the upstream development community and by its users, and since then it > has stuck to a "usptream first" policy, especially where new system > calls, or some other kernel interface is concerned. > I suffered through MontaVista Linux which definitely wasn't ABI compatible. And all of their board support packages were based on different versions of Linux, making it a nightmare to support lots of architectures... > One of the reasons why that early RHEL experience kept Red Hat in line > was because none of the other Linux distributions had that property > --- and because the core development in upstream hadn't slacked off, > so there was a strong desire to upgrade to newer kernels on RHEL, and > when that didn't worked, not only did that make customers and > developers upset, but it also made life difficult for Red Hat > engineers, since they now need to figure out how to forward port their > "value add" changes onto the latest and greatest kernel release. > > > An interesting question is if CSRG had been actively pushing the state > of the art foreward, would that have provided sufficient centripetal > force to keep the HP/UX, SunOS, DG/UX, etc., from spintering? After > all, it's natural to want to get a competitive advantage over your > competition by adding new features --- this is what I call the "Legacy > Unix value-add disease". But if you can't keep up with the upstream > developments, that provides a strong disincentive from making > permanent forks. For that matter, why was it that successive new > releases of AT&T System V wasn't able to play a similar role? Was it > because the rate of change was too slow? Was it because applications > weren't compatible anyway due to ISA differences? I don't know.... > CSRG's funding dried up when the DARPA work was over. And even before it was over, CSRG was more an academic group than one who had a desire to impose its will on commercial groups that it had no leverage over. And AT&T had become all about monetization of unix, which meant it imposed new terms that were unfavorable, making it harder for old-time licensees to justify pulling in the new code that would have kept the world from Balkanizing as badly as it did. So there were complex issues at play here as well. > One other dynamic might be the whole worse is better is worse debate. > As an example of this, Linux had PCMCIA support at least a year or two > before NetBSD did, and in particular Linux had hot-add support where > you could insert an ethernet PCMCIA into your laptop after the OS had > booted, and the ethernet card would work. However, if you ejected the > ethernet card, there was a roughly 1 in 4 chance that your system > would crash. NetBSD took a lot longer to get PCMCIA support --- but > when it did, it had hot-add and hot-remove working perfectly, while > Linux took a year or two more after that point before hot-remove was > solidly reliable. > Except FreeBSD's PAO project had PCMCIA support about two years before NetBSD did, and hot plug worked on it too.. So that's a bit of an apples to oranges comparison. To be fair, the main FreeBSD project was slow to take up changes from PAO and that set back PC Card and CardBus support a number of years. > So from a computer science point of view, one could argue that NetBSD > was "better", and that Linux had a whole bunch of hacks, and some > might even argue was written by a bunch of hacks. :-) However, from > the user's perspective, who Just Wanted Their Laptop To Work, the fact > that Linux had some kind of rough PCMCIA support first mattered a lot > more than a "we will ship no code before its time" attitude. And > some of those users would become developers, which would cause a > positive feedback loop. > At the time, though, FreeBSD ran on the busiest FTP server on the internet could handle quite a bit more load than an equivalent Linux box at the time. And NetBSD was much more in the "no code before its time" camp than FreeBSD, which tried to get things out faster and often did a good job at that. Though it did well with networking, it didn't do so well with PC Card, so it's rather a mixed bag. The only reason I keep replying to this thread is that the simple narratives that people keep repeating often times aren't so simple and the factors going into things tend to be much more complex and nuanced. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Jun 6 12:15:44 2022 From: imp at bsdimp.com (Warner Losh) Date: Sun, 5 Jun 2022 20:15:44 -0600 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: References: Message-ID: On Sun, Jun 5, 2022, 7:40 PM Warren Toomey via TUHS wrote: > Hi all, we have a new addition to the Unix Archive at: > https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ > > This is the documentation for Unix 4.0 which preceded System V. The > documents were provided by Arnold Robbins and scanned in by Matt Gilmore. > Shiny. New things to read... never thought we'd see this... Must resist the urge to ask about boot tapes. :) Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Tue Jun 7 09:28:14 2022 From: davida at pobox.com (David Arnold) Date: Tue, 7 Jun 2022 09:28:14 +1000 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220603213215.GO10240@mcvoy.com> <20220603214032.GQ10240@mcvoy.com> <20220603223014.GS10240@mcvoy.com> <20220603234822.GV10240@mcvoy.com> <20220604010543.GZ10240@mcvoy.com> <20220606011511.GG10240@mcvoy.com> Message-ID: > On 7 Jun 2022, at 00:53, Henry Bent wrote: > > On Sun, 5 Jun 2022 at 21:41, Dan Cross > wrote: > > The other day, I needed a Linux machine for work. I grabbed another > NUC and put Arch on it. A vastly different experience: much more akin > to installing 7th Edition than Windows or macOS. Oh! And I missed a > step, so I had to pull some shenanigans to fix that. > > Gentoo is even more arcane, but that's essentially an "I want to do everything myself" distribution. I suppose my point is that there exist a full range of distributions, from the truly masochistic Linux From Scratch to the most hands-off/static ChromeOS Flex. I don't believe that any other "OS" has such a wide range of offerings. This is obviously both a wonderful feature and a confusing nightmare, depending on your audience. Lest it be thought that all is sweetness and light in Linux-land, there were years of fairly intense competition involved in getting installers to the point that you can start with a downloaded image, burn it to a USB, boot it, run it, and (optionally) make it persist over a reboot, all with very minimal need to understand or care about the many, many things going on under the hood. More recently, installation has become more-or-less settled technology (and so things like Arch have arisen that specialise away from that experience), and there’s increasing competition around the end-user experience. Distributions like ChromeOS or https://elementary.io/ or (from the BSD world!) https://hellosystem.github.io/, are attempting to provide a more seamless user experience than the standard GNOME-or-KDE duopoly that has until recently focused on being competitive with decades old Windows/macOS. Perhaps that’s something OpenSIMH could take from this history: a focus on painless installation and a decent UI! d -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Wed Jun 8 00:30:14 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Tue, 7 Jun 2022 10:30:14 -0400 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: Message-ID: On Tue, Jun 07, 2022 at 09:28:14AM +1000, David Arnold wrote: > Lest it be thought that all is sweetness and light in Linux-land, > there were years of fairly intense competition involved in getting > installers to the point that you can start with a downloaded image, > burn it to a USB, boot it, run it, and (optionally) make it persist > over a reboot, all with very minimal need to understand or care > about the many, many things going on under the hood. On Sun, Jun 05, 2022 at 09:40:44PM -0400, Dan Cross wrote: > > But every distribution has its own installer, and they vary wildly. The key is I think *competition*. Distributions were competing to attract a user base, and one of the ways they could do that was by improving the install experience. There were people who reviewed distributions based on which one had the better installer, and that helped users who were Windows refugees choose the ones that had the better installer. The other advantages of having a many distributions is that gave more people to opportunity to exercise leadership --- you can "drive the big red firetruck" by founding a distro like Debian or Slackware, and the people who are interested in improving a distribution can be different from those who drive kernel development. This is one of the things that I've learned from my rector at my church, who had a background in community organizing. One of the big differences between community organizing compared to the corporate world is that it's more important to give more people --- volunteers --- opportunities to contribute, and very often this is far more important than efficiently organizing a corporate-style team to get some job done. Was it inefficient to have multiple teams competing on installer development, and release engineering? Sure, but it also drew more people into the Linux ecosystem. > The ABI compatibility thing breaks down, too. A colleague was trying > to get the host-side of a Salae logic analyzer working on Arch, and it > doesn't. They more or less require Ubuntu 18.something, and that's > not what he runs. As far as most end-users are concerned, your > distribution of choice is "Linux", and distributions vary in all kinds of > ways. There are three different things that's worth separating. One is a consistent kernel<->user space interface, this is what Linus Torvalds considers high priority when he says, "Thou shalt not break userspace". This is what allows pretty much all distributions to replace the kernel that was shipped with the distribution with the latest upstream kernel. And this is something that in general doesn't work with *BSD systems. The second is application source-level compatibility, and this is what allows you to download some open source application, and recompile it on different Linux distributions, and it should Just Work. In practice this works for most Linux and *BSD users. And the third is application *binary* level compatibility. And this is what is important if you have some binary that you've downloaded, or some commerical application which you've purchased, and you want to run it on Linux distribution different from the one which is originally designed. Static linking solves most of the problems, but if the user needs to use proprietary/commercial binaries, if they stick to RHEL, Fedora, Ubuntu/Debian, they will generally not have issues. - Ted From crossd at gmail.com Wed Jun 8 01:08:34 2022 From: crossd at gmail.com (Dan Cross) Date: Tue, 7 Jun 2022 11:08:34 -0400 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: Message-ID: On Tue, Jun 7, 2022 at 10:30 AM Theodore Ts'o wrote: > On Tue, Jun 07, 2022 at 09:28:14AM +1000, David Arnold wrote: > > Lest it be thought that all is sweetness and light in Linux-land, > > there were years of fairly intense competition involved in getting > > installers to the point that you can start with a downloaded image, > > burn it to a USB, boot it, run it, and (optionally) make it persist > > over a reboot, all with very minimal need to understand or care > > about the many, many things going on under the hood. > > On Sun, Jun 05, 2022 at 09:40:44PM -0400, Dan Cross wrote: > > > > But every distribution has its own installer, and they vary wildly. > > The key is I think *competition*. Distributions were competing to > attract a user base, and one of the ways they could do that was by > improving the install experience. There were people who reviewed > distributions based on which one had the better installer, and that > helped users who were Windows refugees choose the ones that had the > better installer. My point is that this is something that varies from distro to distro; it is therefore inaccurate to claim that "Linux solved it" since many different distros that have widely varying installation processes fall under the very large "Linux" umbrella. > The other advantages of having a many distributions is that gave more > people to opportunity to exercise leadership --- you can "drive the > big red firetruck" by founding a distro like Debian or Slackware, and > the people who are interested in improving a distribution can be > different from those who drive kernel development. This is one of the > things that I've learned from my rector at my church, who had a > background in community organizing. One of the big differences > between community organizing compared to the corporate world is that > it's more important to give more people --- volunteers --- > opportunities to contribute, and very often this is far more important > than efficiently organizing a corporate-style team to get some job > done. Was it inefficient to have multiple teams competing on > installer development, and release engineering? Sure, but it also > drew more people into the Linux ecosystem. That's an interesting angle and one that I think bears more on the topic at hand than many folks are willing to let on: the barrier to contribution is, in a lot of important ways, lower in the Linux ecosystem than it is in the BSD world. At least historically speaking, and perhaps still true. Anecdotally, I was able to get a patch into the KVM unit tests (not precisely Linux but related) in pretty short order recently while the OpenBSD people simply ignored my problem report and patch. YMMV. > > The ABI compatibility thing breaks down, too. A colleague was trying > > to get the host-side of a Salae logic analyzer working on Arch, and it > > doesn't. They more or less require Ubuntu 18.something, and that's > > not what he runs. As far as most end-users are concerned, your > > distribution of choice is "Linux", and distributions vary in all kinds of > > ways. > > There are three different things that's worth separating. One is a > consistent kernel<->user space interface, this is what Linus Torvalds > considers high priority when he says, "Thou shalt not break > userspace". This is what allows pretty much all distributions to > replace the kernel that was shipped with the distribution with the > latest upstream kernel. And this is something that in general doesn't > work with *BSD systems. Eh? I feel like I can upgrade the kernel on the various BSDs without binaries breaking pretty easily. Then again, there _have_ been times when there were flag days that required rebuilding the world; but surely externalities are more common here (e.g., switching from one ISA to another). > The second is application source-level compatibility, and this is what > allows you to download some open source application, and recompile it > on different Linux distributions, and it should Just Work. In > practice this works for most Linux and *BSD users. This, I think, is where things break down. Simply put, the way people build applications has changed, and "source-level" compatibility means compatibility with a bunch of third-party libraries; in many ways the kernel interfaces matter much, much less (many of which are defined by externally imposed standards anyway). If a distro ships a too-old or too-new version of the dependency, then the open source thing will often not build, and for most end users, this is a distinction without a difference. > And the third is application *binary* level compatibility. And this > is what is important if you have some binary that you've downloaded, > or some commerical application which you've purchased, and you want to > run it on Linux distribution different from the one which is > originally designed. Static linking solves most of the problems, but > if the user needs to use proprietary/commercial binaries, if they > stick to RHEL, Fedora, Ubuntu/Debian, they will generally not have > issues. Yup. But then that you're running Linux is mostly immaterial; it could be Windows and the same would be true. - Dan C. From lm at mcvoy.com Wed Jun 8 01:25:19 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 7 Jun 2022 08:25:19 -0700 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: Message-ID: <20220607152519.GN15041@mcvoy.com> On Tue, Jun 07, 2022 at 11:08:34AM -0400, Dan Cross wrote: > On Tue, Jun 7, 2022 at 10:30 AM Theodore Ts'o wrote: > > The key is I think *competition*. Distributions were competing to > > attract a user base, and one of the ways they could do that was by > > improving the install experience. There were people who reviewed > > distributions based on which one had the better installer, and that > > helped users who were Windows refugees choose the ones that had the > > better installer. > > My point is that this is something that varies from distro to distro; > it is therefore inaccurate to claim that "Linux solved it" since many > different distros that have widely varying installation processes > fall under the very large "Linux" umbrella. Yeah, there are a large number of distros but I'm willing to bet that Debian, RedHat and Ubuntu variants account for the vast majority of installs. > > There are three different things that's worth separating. One is a > > consistent kernel<->user space interface, this is what Linus Torvalds > > considers high priority when he says, "Thou shalt not break > > userspace". This is what allows pretty much all distributions to > > replace the kernel that was shipped with the distribution with the > > latest upstream kernel. And this is something that in general doesn't > > work with *BSD systems. > > Eh? I feel like I can upgrade the kernel on the various BSDs > without binaries breaking pretty easily. Then again, there _have_ > been times when there were flag days that required rebuilding > the world; but surely externalities are more common here (e.g., > switching from one ISA to another). Try installing an OpenBSD kernel on FreeBSD, that's what we mean by compat. I'm more than willing to believe that you can pull head on the FreeBSD source tree and build & install it on FreeBSD. Much less willing to believe that that works Open/Free or Net/Free. With Linux, on pretty much any distro, you can pull Linus' tree and build and install it without drama. If you are running some ancient release you might have to update your toolchain but that's about it. Linus is super careful to not break the syscall table. It's extend only, which makes it a mess, but a binary compat mess. > > The second is application source-level compatibility, and this is what > > allows you to download some open source application, and recompile it > > on different Linux distributions, and it should Just Work. In > > practice this works for most Linux and *BSD users. > > This, I think, is where things break down. Simply put, the way > people build applications has changed, and "source-level" > compatibility means compatibility with a bunch of third-party > libraries; in many ways the kernel interfaces matter much, much > less (many of which are defined by externally imposed standards > anyway). If a distro ships a too-old or too-new version of the > dependency, then the open source thing will often not build, and > for most end users, this is a distinction without a difference. Yes, you are correct, I've experienced that as well with sort of newer complex apps. From rich.salz at gmail.com Wed Jun 8 01:55:22 2022 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 7 Jun 2022 11:55:22 -0400 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: Message-ID: > > Lest it be thought that all is sweetness and light in Linux-land, I don't think anyone has thought or said that about Linux ever. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Wed Jun 8 02:03:41 2022 From: will.senn at gmail.com (Will Senn) Date: Tue, 7 Jun 2022 11:03:41 -0500 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: <20220607152519.GN15041@mcvoy.com> References: <20220607152519.GN15041@mcvoy.com> Message-ID: Interesting crossover from Linux to Linux Distros... Debian's my personal fave (in the form of Mint, MX, or even Ubuntu), mostly cuz apt seems to just work (for me, ymmv) and rpm sucks :). However, all of these run on the same kernel and generally provide the same userland (core-utils, etc). I constantly switch from Mac (Mojave) to FreeBSD to Linux (Mint, usually, but occassionally opensuse) and other than minor differences in switches, they are all reminiscent of v7, from a user perspective, outside of GUIs. Except for ZFS, which will keep FreeBSD in my environment until it's added to the Linux Kernel - is hell freezing over yet? -w On 6/7/22 10:25 AM, Larry McVoy wrote: > On Tue, Jun 07, 2022 at 11:08:34AM -0400, Dan Cross wrote: >> On Tue, Jun 7, 2022 at 10:30 AM Theodore Ts'o wrote: >>> The key is I think *competition*. Distributions were competing to >>> attract a user base, and one of the ways they could do that was by >>> improving the install experience. There were people who reviewed >>> distributions based on which one had the better installer, and that >>> helped users who were Windows refugees choose the ones that had the >>> better installer. >> My point is that this is something that varies from distro to distro; >> it is therefore inaccurate to claim that "Linux solved it" since many >> different distros that have widely varying installation processes >> fall under the very large "Linux" umbrella. > Yeah, there are a large number of distros but I'm willing to bet that > Debian, RedHat and Ubuntu variants account for the vast majority of > installs. > >>> There are three different things that's worth separating. One is a >>> consistent kernel<->user space interface, this is what Linus Torvalds >>> considers high priority when he says, "Thou shalt not break >>> userspace". This is what allows pretty much all distributions to >>> replace the kernel that was shipped with the distribution with the >>> latest upstream kernel. And this is something that in general doesn't >>> work with *BSD systems. >> Eh? I feel like I can upgrade the kernel on the various BSDs >> without binaries breaking pretty easily. Then again, there _have_ >> been times when there were flag days that required rebuilding >> the world; but surely externalities are more common here (e.g., >> switching from one ISA to another). > Try installing an OpenBSD kernel on FreeBSD, that's what we mean by > compat. I'm more than willing to believe that you can pull head on > the FreeBSD source tree and build & install it on FreeBSD. Much less > willing to believe that that works Open/Free or Net/Free. > > With Linux, on pretty much any distro, you can pull Linus' tree and > build and install it without drama. If you are running some ancient > release you might have to update your toolchain but that's about it. > Linus is super careful to not break the syscall table. It's extend > only, which makes it a mess, but a binary compat mess. > >>> The second is application source-level compatibility, and this is what >>> allows you to download some open source application, and recompile it >>> on different Linux distributions, and it should Just Work. In >>> practice this works for most Linux and *BSD users. >> This, I think, is where things break down. Simply put, the way >> people build applications has changed, and "source-level" >> compatibility means compatibility with a bunch of third-party >> libraries; in many ways the kernel interfaces matter much, much >> less (many of which are defined by externally imposed standards >> anyway). If a distro ships a too-old or too-new version of the >> dependency, then the open source thing will often not build, and >> for most end users, this is a distinction without a difference. > Yes, you are correct, I've experienced that as well with sort of > newer complex apps. From imp at bsdimp.com Wed Jun 8 02:38:57 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 7 Jun 2022 10:38:57 -0600 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220607152519.GN15041@mcvoy.com> Message-ID: On Tue, Jun 7, 2022, 9:03 AM Will Senn wrote: > Interesting crossover from Linux to Linux Distros... Debian's my > personal fave (in the form of Mint, MX, or even Ubuntu), mostly cuz apt > seems to just work (for me, ymmv) and rpm sucks :). However, all of > these run on the same kernel and generally provide the same userland > (core-utils, etc). But not the same binaries. I've run into a lot of issues trying to run a binary for Debian on red hat or vice Vera due to shared libraries not being completely compatible... kinda makes the whole system call argument moot since there is always significant version skew... Warner I constantly switch from Mac (Mojave) to FreeBSD to > Linux (Mint, usually, but occassionally opensuse) and other than minor > differences in switches, they are all reminiscent of v7, from a user > perspective, outside of GUIs. Except for ZFS, which will keep FreeBSD in > my environment until it's added to the Linux Kernel - is hell freezing > over yet? > > -w > > > > On 6/7/22 10:25 AM, Larry McVoy wrote: > > On Tue, Jun 07, 2022 at 11:08:34AM -0400, Dan Cross wrote: > >> On Tue, Jun 7, 2022 at 10:30 AM Theodore Ts'o wrote: > >>> The key is I think *competition*. Distributions were competing to > >>> attract a user base, and one of the ways they could do that was by > >>> improving the install experience. There were people who reviewed > >>> distributions based on which one had the better installer, and that > >>> helped users who were Windows refugees choose the ones that had the > >>> better installer. > >> My point is that this is something that varies from distro to distro; > >> it is therefore inaccurate to claim that "Linux solved it" since many > >> different distros that have widely varying installation processes > >> fall under the very large "Linux" umbrella. > > Yeah, there are a large number of distros but I'm willing to bet that > > Debian, RedHat and Ubuntu variants account for the vast majority of > > installs. > > > >>> There are three different things that's worth separating. One is a > >>> consistent kernel<->user space interface, this is what Linus Torvalds > >>> considers high priority when he says, "Thou shalt not break > >>> userspace". This is what allows pretty much all distributions to > >>> replace the kernel that was shipped with the distribution with the > >>> latest upstream kernel. And this is something that in general doesn't > >>> work with *BSD systems. > >> Eh? I feel like I can upgrade the kernel on the various BSDs > >> without binaries breaking pretty easily. Then again, there _have_ > >> been times when there were flag days that required rebuilding > >> the world; but surely externalities are more common here (e.g., > >> switching from one ISA to another). > > Try installing an OpenBSD kernel on FreeBSD, that's what we mean by > > compat. I'm more than willing to believe that you can pull head on > > the FreeBSD source tree and build & install it on FreeBSD. Much less > > willing to believe that that works Open/Free or Net/Free. > > > > With Linux, on pretty much any distro, you can pull Linus' tree and > > build and install it without drama. If you are running some ancient > > release you might have to update your toolchain but that's about it. > > Linus is super careful to not break the syscall table. It's extend > > only, which makes it a mess, but a binary compat mess. > > > >>> The second is application source-level compatibility, and this is what > >>> allows you to download some open source application, and recompile it > >>> on different Linux distributions, and it should Just Work. In > >>> practice this works for most Linux and *BSD users. > >> This, I think, is where things break down. Simply put, the way > >> people build applications has changed, and "source-level" > >> compatibility means compatibility with a bunch of third-party > >> libraries; in many ways the kernel interfaces matter much, much > >> less (many of which are defined by externally imposed standards > >> anyway). If a distro ships a too-old or too-new version of the > >> dependency, then the open source thing will often not build, and > >> for most end users, this is a distinction without a difference. > > Yes, you are correct, I've experienced that as well with sort of > > newer complex apps. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Jun 8 02:45:53 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 7 Jun 2022 09:45:53 -0700 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220607152519.GN15041@mcvoy.com> Message-ID: <20220607164553.GU15041@mcvoy.com> On Tue, Jun 07, 2022 at 10:38:57AM -0600, Warner Losh wrote: > On Tue, Jun 7, 2022, 9:03 AM Will Senn wrote: > > > Interesting crossover from Linux to Linux Distros... Debian's my > > personal fave (in the form of Mint, MX, or even Ubuntu), mostly cuz apt > > seems to just work (for me, ymmv) and rpm sucks :). However, all of > > these run on the same kernel and generally provide the same userland > > (core-utils, etc). > > > But not the same binaries. I've run into a lot of issues trying to run a > binary for Debian on red hat or vice Vera due to shared libraries not being > completely compatible... kinda makes the whole system call argument moot > since there is always significant version skew... Yep, shared libraries can screw you but that's true anywhere. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From blake1024 at gmail.com Wed Jun 8 02:46:53 2022 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 7 Jun 2022 11:46:53 -0500 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220607152519.GN15041@mcvoy.com> Message-ID: On Tue, Jun 7, 2022 at 11:39 AM Warner Losh wrote: > > But not the same binaries. I've run into a lot of issues trying to run a > binary for Debian on red hat or vice Vera due to shared libraries not being > completely compatible... kinda makes the whole system call argument moot > since there is always significant version skew... > That's why God created static linking. Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jun 8 02:57:15 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 7 Jun 2022 10:57:15 -0600 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: <20220607164553.GU15041@mcvoy.com> References: <20220607152519.GN15041@mcvoy.com> <20220607164553.GU15041@mcvoy.com> Message-ID: On Tue, Jun 7, 2022, 9:45 AM Larry McVoy wrote: > On Tue, Jun 07, 2022 at 10:38:57AM -0600, Warner Losh wrote: > > On Tue, Jun 7, 2022, 9:03 AM Will Senn wrote: > > > > > Interesting crossover from Linux to Linux Distros... Debian's my > > > personal fave (in the form of Mint, MX, or even Ubuntu), mostly cuz apt > > > seems to just work (for me, ymmv) and rpm sucks :). However, all of > > > these run on the same kernel and generally provide the same userland > > > (core-utils, etc). > > > > > > But not the same binaries. I've run into a lot of issues trying to run a > > binary for Debian on red hat or vice Vera due to shared libraries not > being > > completely compatible... kinda makes the whole system call argument moot > > since there is always significant version skew... > > Yep, shared libraries can screw you but that's true anywhere. > Kinda my point: you brag of a misleading compatibility and then attack others that decide to slice things up differently and don't have that, these days useless, talking point. Warner -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Wed Jun 8 02:57:59 2022 From: cowan at ccil.org (John Cowan) Date: Tue, 7 Jun 2022 12:57:59 -0400 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: <202206060920.2569KNx6016227@freefriends.org> References: <20220606022655.GI10240@mcvoy.com> <202206060920.2569KNx6016227@freefriends.org> Message-ID: On Mon, Jun 6, 2022 at 5:20 AM wrote: > There's a lot of stuff there that's familiar, straight from V7. > But yes, there's also a lot of stuff that's unique to USG Unix of the time. > As a non-insider, here's what I see that's unfamiliar: In Volume 1: - -mv macros for viewgraphs and slides - the *full* C reference manual (oopsie!) without the "late K&R" addendum - make(1) with E.G. Bradford's changes - the sdb(1) debugger In Volume 2: - an SCCS front end (not the same as the BSD one) - a bunch of graphics commands - ged(1g), a graphics editor - stat, tools for analyzing data - vpm, the Virtual Protocol Machine for outboard comms - Unix RJE - Stand-Alone I/O Library for bare-metal programs - Equipment Test Package -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Jun 8 03:00:40 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 7 Jun 2022 13:00:40 -0400 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220607152519.GN15041@mcvoy.com> Message-ID: On 6/7/22, Warner Losh wrote: > > But not the same binaries. I've run into a lot of issues trying to run a > binary for Debian on red hat or vice Vera due to shared libraries not being > completely compatible... kinda makes the whole system call argument moot > since there is always significant version skew... Part of my last job was to maintain a suite of software development and testing tools for our product across three different operating system platforms: Windows, Mac OS X, and Linux. The suite had to run on several versions of four or five Linux distributions. It is all user mode, unprivileged code. Windows and OS X rarely had problems with upward compatibility (newer versions able to run executables built for older versions), but Linux was living hell. Shared library compatibility was the biggest problem. Not only were shared libraries often incompatible between different Linux distributions, they were sometimes incompatible even between different versions of the same distribution. The problem of keeping shared libraries upward compatible from release to release was solved circa 1975 by the engineers who designed the VAX/VMS ABI. If not before that. It's not rocket science, but it does require a degree of discipline, care, and attention to detail when adding new or incompatible changes to an existing library. That bit of developer culture seems to be absent from Linux and the pieces of GNU that supply Linux's fundamental libraries (libc, etc.). To bring this back closer to TUHS, I don't know if the Unix distributions that support shared libraries suffer from the same problem. -Paul W. From lm at mcvoy.com Wed Jun 8 03:05:34 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 7 Jun 2022 10:05:34 -0700 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220607152519.GN15041@mcvoy.com> <20220607164553.GU15041@mcvoy.com> Message-ID: <20220607170534.GW15041@mcvoy.com> On Tue, Jun 07, 2022 at 10:57:15AM -0600, Warner Losh wrote: > On Tue, Jun 7, 2022, 9:45 AM Larry McVoy wrote: > > > On Tue, Jun 07, 2022 at 10:38:57AM -0600, Warner Losh wrote: > > > On Tue, Jun 7, 2022, 9:03 AM Will Senn wrote: > > > > > > > Interesting crossover from Linux to Linux Distros... Debian's my > > > > personal fave (in the form of Mint, MX, or even Ubuntu), mostly cuz apt > > > > seems to just work (for me, ymmv) and rpm sucks :). However, all of > > > > these run on the same kernel and generally provide the same userland > > > > (core-utils, etc). > > > > > > > > > But not the same binaries. I've run into a lot of issues trying to run a > > > binary for Debian on red hat or vice Vera due to shared libraries not > > being > > > completely compatible... kinda makes the whole system call argument moot > > > since there is always significant version skew... > > > > Yep, shared libraries can screw you but that's true anywhere. > > > > Kinda my point: you brag of a misleading compatibility and then attack > others that decide to slice things up differently and don't have that, > these days useless, talking point. > > Warner OK, Warner knower of all things, I'm sure you are right. It's not like I've done the things I've talked about, I'm actually an AI bot programmed to annoy you. From paul.winalski at gmail.com Wed Jun 8 03:26:01 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 7 Jun 2022 13:26:01 -0400 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220607152519.GN15041@mcvoy.com> Message-ID: On 6/7/22, Blake McBride wrote: (regarding shared library incompatibility between Linux versions) > > That's why God created static linking. I assume you're being at least partly facetious. Maintaining upward compatibility for shared libraries has been a solved problem for about 50 years. Many OSes other than Linux do/have solved the problem. There's no excuse for it other than laziness or ignorance. -Paul W. From g.branden.robinson at gmail.com Wed Jun 8 05:32:33 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 7 Jun 2022 14:32:33 -0500 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: References: <20220606022655.GI10240@mcvoy.com> <202206060920.2569KNx6016227@freefriends.org> Message-ID: <20220607193233.3qh2lu3hzpa42zcj@illithid> At 2022-06-07T12:57:59-0400, John Cowan wrote: > As a non-insider, here's what I see that's unfamiliar: > > In Volume 1: [...] > - the *full* C reference manual (oopsie!) without the "late K&R" addendum By that addendum do you mean the "Recent Changes to C" 1-page memo dated 1978-11-15 that appears with some copies of Seventh Edition Unix documentation? For those who don't have it handy, it documents structure assignment and introduces enum types. Or is there another piece of samizdat I should keep an eye out for? :) Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From blake1024 at gmail.com Wed Jun 8 06:09:19 2022 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 7 Jun 2022 15:09:19 -0500 Subject: [TUHS] Fwd: [simh] Announcing the Open SIMH project In-Reply-To: References: <20220607152519.GN15041@mcvoy.com> Message-ID: On Tue, Jun 7, 2022 at 12:26 PM Paul Winalski wrote: > On 6/7/22, Blake McBride wrote: > (regarding shared library incompatibility between Linux versions) > > > > That's why God created static linking. > > I assume you're being at least partly facetious. Maintaining upward > compatibility for shared libraries has been a solved problem for about > 50 years. Many OSes other than Linux do/have solved the problem. > There's no excuse for it other than laziness or ignorance. > > -Paul W. > And there is the rub - laziness or ignorance. Unlike closed systems like Windows and macOS, it is harder to enforce rules with so many random developers. Further, Linux has so many developers that it changes far more often. Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Jun 8 08:26:13 2022 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 8 Jun 2022 08:26:13 +1000 Subject: [TUHS] Please move the SIMH discussion to COFF Message-ID: Hi all, I think it's time to move the (no longer) SIMH discussion over to the COFF mailing list. The S/N ratio is dropping and we are straying too far away from the Unix side of things. Many thanks! Warren From cmhanson at eschatologist.net Wed Jun 8 09:41:06 2022 From: cmhanson at eschatologist.net (Chris Hanson) Date: Tue, 7 Jun 2022 16:41:06 -0700 Subject: [TUHS] [simh] Announcing the Open SIMH project In-Reply-To: References: <20220607152519.GN15041@mcvoy.com> Message-ID: <931C40D7-F780-454F-B51B-747C713CD31C@eschatologist.net> On Jun 7, 2022, at 10:00 AM, Paul Winalski wrote: > > Windows and OS X rarely had problems with upward compatibility (newer > versions able to run executables built for older versions), but Linux > was living hell. Shared library compatibility was the biggest > problem. Not only were shared libraries often incompatible between > different Linux distributions, they were sometimes incompatible even > between different versions of the same distribution. That's because, at least when it comes to macOS (nee OS X, nee Mac OS X, nee OPENSTEP/Mach, nee NEXTSTEP in various capitalizations) we treat treat binary compatibility as something for the operating system as a whole to maintain, not just the kernel or the kernel userspace. Linux's ABI compatibility is itself kind of bare-bones; it achieves userspace compatibility by having a fixed set of system call numbers with well-specified calling sequences that get compiled into every binary for a particular architecture, and it doesn't even attempt to provide the kernel ABI compatibility needed by commercial driver vendors. We handle userspace ABI compatibility in macOS by actually putting the syscalls on the other side of a shared library (libSystem.dylib) so the calling sequences and syscall numbers are entirely hidden from userspace. We've historically taken a different approach to kernel ABI compatibility but have provided it too, though not to the same extent as userspace. As an example of where this helps, things like Linux-derived containers would be much faster on non-Linux platforms if the container system could swap in its own "libsyscall.so" instead of having to run atop a VM of some sort to handle the Linux syscall traps. -- Chris From silas8642 at hotmail.co.uk Thu Jun 9 09:15:55 2022 From: silas8642 at hotmail.co.uk (silas poulson) Date: Wed, 8 Jun 2022 23:15:55 +0000 Subject: [TUHS] blast from the past In-Reply-To: <39D6E93C-B6CD-444B-B320-93FA7060E7D7@humeweb.com> References: <39D6E93C-B6CD-444B-B320-93FA7060E7D7@humeweb.com> Message-ID: Ah, an excellent reminder! I tend to watch it every now and again to enthuse myself Silas On 6 Jun 2022, at 16:43, Andrew Hume > wrote: this is an old video, new to me, but i’m sure others on this list have seen it. its a little long, but has al aho, jon bentley, bjarne, ken&denis, plan 9 amongst others. https://www.youtube.com/watch?v=IFfdnFOiXUU&t=2s -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Fri Jun 10 08:19:22 2022 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Thu, 9 Jun 2022 23:19:22 +0100 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: <20220607193233.3qh2lu3hzpa42zcj@illithid> References: <20220606022655.GI10240@mcvoy.com> <202206060920.2569KNx6016227@freefriends.org> <20220607193233.3qh2lu3hzpa42zcj@illithid> Message-ID: On Tue, Jun 07, 2022 at 02:32:33PM -0500, G. Branden Robinson wrote: > > By that addendum do you mean the "Recent Changes to C" 1-page memo dated > 1978-11-15 that appears with some copies of Seventh Edition Unix > documentation? > > For those who don't have it handy, it documents structure assignment and > introduces enum types. > > Or is there another piece of samizdat I should keep an eye out for? :) Have a look here: https://www.bell-labs.com/usr/dmr/www/cchanges.pdf DF From egbegb2 at gmail.com Fri Jun 10 16:47:43 2022 From: egbegb2 at gmail.com (Ed Bradford) Date: Fri, 10 Jun 2022 01:47:43 -0500 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: References: Message-ID: Hi Warren, Thank you for the amazing Unix documetation. Do you know if there is a source code for SCCS anywhere on the net? Ed Bradford On Sun, Jun 5, 2022 at 8:40 PM Warren Toomey via TUHS wrote: > Hi all, we have a new addition to the Unix Archive at: > https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ > > This is the documentation for Unix 4.0 which preceded System V. The > documents were provided by Arnold Robbins and scanned in by Matt Gilmore. > > Cheers, Warren > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Jun 10 17:31:48 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 10 Jun 2022 01:31:48 -0600 Subject: [TUHS] Source code for SCCS (was Re: Re: Documentation for Unix 4.0) In-Reply-To: References: Message-ID: <202206100731.25A7Vm29022762@freefriends.org> The GNU project has CSSC, which is an SCCS clone. HTH, Arnold Ed Bradford wrote: > Hi Warren, > > Thank you for the amazing Unix documetation. > Do you know if there is a source code for SCCS anywhere on the net? > > Ed Bradford > > On Sun, Jun 5, 2022 at 8:40 PM Warren Toomey via TUHS wrote: > > > Hi all, we have a new addition to the Unix Archive at: > > https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ > > > > This is the documentation for Unix 4.0 which preceded System V. The > > documents were provided by Arnold Robbins and scanned in by Matt Gilmore. > > > > Cheers, Warren > > > > > -- > Advice is judged by results, not by intentions. > Cicero From m at mbsks.franken.de Fri Jun 10 18:38:17 2022 From: m at mbsks.franken.de (Matthias Bruestle) Date: Fri, 10 Jun 2022 10:38:17 +0200 Subject: [TUHS] Source code for SCCS (was Re: Re: Documentation for Unix 4.0) In-Reply-To: <202206100731.25A7Vm29022762@freefriends.org> References: <202206100731.25A7Vm29022762@freefriends.org> Message-ID: On Fri, Jun 10, 2022 at 01:31:48AM -0600, arnold at skeeve.com wrote: > The GNU project has CSSC, which is an SCCS clone. I had a look what SCCS. I know it now, found CSSC, but also http://sccs.sourceforge.net/ and that Wikipedia points me to https://publications.opengroup.org/ as the official repository, where I don't find anything about SCCS. Matthias -- When You Find Out Your Normal Daily Lifestyle Is Called Quarantine From arnold at skeeve.com Fri Jun 10 20:03:47 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 10 Jun 2022 04:03:47 -0600 Subject: [TUHS] Source code for SCCS (was Re: Re: Documentation for Unix 4.0) In-Reply-To: References: <202206100731.25A7Vm29022762@freefriends.org> Message-ID: <202206101003.25AA3lie013752@freefriends.org> Matthias Bruestle wrote: > On Fri, Jun 10, 2022 at 01:31:48AM -0600, arnold at skeeve.com wrote: > > The GNU project has CSSC, which is an SCCS clone. > > I had a look what SCCS. I know it now, found CSSC, but also > http://sccs.sourceforge.net/ That is what you're looking for, the source to SCCS. > and that Wikipedia points me to > https://publications.opengroup.org/ as the official repository, > where I don't find anything about SCCS. That site has the POSIX standards which describe how SCCS is supposed to work, not the source code for it. HTH, Arnold From clemc at ccc.com Sat Jun 11 00:22:40 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 10 Jun 2022 10:22:40 -0400 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: References: Message-ID: The original Marc Rochchild/John Mashey and team code from PWB 1.0 can be found: http://tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz In the directory: sys/source/sccs4 The man pages are in the same archive but mixed with the rest of the commands in usr/man/man* That said, there is Gnu version of same written C++ if IIRC: https://www.gnu.org/software/cssc/ And there's more ... but I'll Larry offer details here other than point out his: http://www.bitmover.com/bitsccs/ [which is of BitKeeper] is a more modern implementation still] ᐧ On Fri, Jun 10, 2022 at 2:48 AM Ed Bradford wrote: > Hi Warren, > > Thank you for the amazing Unix documetation. > Do you know if there is a source code for SCCS anywhere on the net? > > Ed Bradford > > On Sun, Jun 5, 2022 at 8:40 PM Warren Toomey via TUHS > wrote: > >> Hi all, we have a new addition to the Unix Archive at: >> https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ >> >> This is the documentation for Unix 4.0 which preceded System V. The >> documents were provided by Arnold Robbins and scanned in by Matt Gilmore. >> >> Cheers, Warren >> > > > -- > Advice is judged by results, not by intentions. > Cicero > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Jun 11 05:24:13 2022 From: cowan at ccil.org (John Cowan) Date: Fri, 10 Jun 2022 15:24:13 -0400 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: References: Message-ID: On Fri, Jun 10, 2022 at 10:23 AM Clem Cole wrote: That said, there is Gnu version of same written C++ if IIRC: > https://www.gnu.org/software/cssc/ > ... which stands for Compatibly Stupid Source Control. > > And there's more ... > > In particular, the Heirloom Toolkit at < https://sourceforge.net/projects/heirloom/> contains the Solaris version of SCCS, and SRC source control provides a modern-style front-end over either RCS or SCCS; it is designed for maintaining single files, possibly in the same directory, without entangling their versioning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egbegb2 at gmail.com Sat Jun 11 14:34:58 2022 From: egbegb2 at gmail.com (Ed Bradford) Date: Fri, 10 Jun 2022 23:34:58 -0500 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: References: Message-ID: Thank you, Clem. You link didn't work but the other information on cssc worked fine. Ed On Fri, Jun 10, 2022 at 9:23 AM Clem Cole wrote: > The original Marc Rochchild/John Mashey and team code from PWB 1.0 can be > found: http://tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz > In the directory: sys/source/sccs4 > The man pages are in the same archive but mixed with the rest of the > commands in usr/man/man* > > That said, there is Gnu version of same written C++ if IIRC: > https://www.gnu.org/software/cssc/ > > And there's more ... but I'll Larry offer details here other than point > out his: http://www.bitmover.com/bitsccs/ [which is of BitKeeper] is a > more modern implementation still] > ᐧ > > On Fri, Jun 10, 2022 at 2:48 AM Ed Bradford wrote: > >> Hi Warren, >> >> Thank you for the amazing Unix documetation. >> Do you know if there is a source code for SCCS anywhere on the net? >> >> Ed Bradford >> >> On Sun, Jun 5, 2022 at 8:40 PM Warren Toomey via TUHS >> wrote: >> >>> Hi all, we have a new addition to the Unix Archive at: >>> https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ >>> >>> This is the documentation for Unix 4.0 which preceded System V. The >>> documents were provided by Arnold Robbins and scanned in by Matt Gilmore. >>> >>> Cheers, Warren >>> >> >> >> -- >> Advice is judged by results, not by intentions. >> Cicero >> >> -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sat Jun 11 20:09:17 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 11 Jun 2022 12:09:17 +0200 Subject: [TUHS] Source code for SCCS Message-ID: It would seem that a Spinellis-like exercise for SCCS is possible: PWB1.0 (1978): https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/sccs4 SysIII (1980): https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/sccs SysVr1 (1983): https://www.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/cmd/sccs SysVr2 (1984): https://github.com/ryanwoodsmall/oldsysv/tree/master/sysvr2-vax/src/cmd/sccs SysVr3 (1987): https://github.com/ryanwoodsmall/oldsysv/tree/master/sysvr3/301/usr/src/cmd/sccs SysVr4 (1988): https://github.com/ryanwoodsmall/oldsysv/tree/master/sysvr4/svr4/cmd/sccs Ultrix3.1 (1988): https://www.tuhs.org/cgi-bin/utree.pl?file=Ultrix-3.1/src/cmd/sccs I did not find SCCS sources included with the BSD sources on TUHS, but there is a front-end “sccs” command. For sure, SCCS was used for BSD development. Kirk McKusick’s DVD has a directory "CSRG/historic1/sccscmds”, but I did not look into this further. From here the trail probably continues with Solaris, GNU and Bitmover -- all very much outside my timeframe of research. Paul > The original Marc Rochchild/John Mashey and team code from PWB 1.0 can be > found: http://tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz > In the directory: sys/source/sccs4 > The man pages are in the same archive but mixed with the rest of the > commands in usr/man/man* > > That said, there is Gnu version of same written C++ if IIRC: > https://www.gnu.org/software/cssc/ > > And there's more ... but I'll Larry offer details here other than point out > his: http://www.bitmover.com/bitsccs/ [which is of BitKeeper] is a > more modern implementation still] From clemc at ccc.com Sun Jun 12 00:43:59 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 11 Jun 2022 10:43:59 -0400 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: References: Message-ID: Your welcome. What do you mean by the first link did not work. It’s a tarball that has to be decoded and then look inside for the original code. It’s there. I just tried it. On Sat, Jun 11, 2022 at 12:35 AM Ed Bradford wrote: > Thank you, Clem. You link didn't work but the other information on cssc > worked fine. > > Ed > > > On Fri, Jun 10, 2022 at 9:23 AM Clem Cole wrote: > >> The original Marc Rochchild/John Mashey and team code from PWB 1.0 can be >> found: http://tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz >> In the directory: sys/source/sccs4 >> The man pages are in the same archive but mixed with the rest of the >> commands in usr/man/man* >> >> That said, there is Gnu version of same written C++ if IIRC: >> https://www.gnu.org/software/cssc/ >> >> And there's more ... but I'll Larry offer details here other than point >> out his: http://www.bitmover.com/bitsccs/ [which is of BitKeeper] is a >> more modern implementation still] >> ᐧ >> >> On Fri, Jun 10, 2022 at 2:48 AM Ed Bradford wrote: >> >>> Hi Warren, >>> >>> Thank you for the amazing Unix documetation. >>> Do you know if there is a source code for SCCS anywhere on the net? >>> >>> Ed Bradford >>> >>> On Sun, Jun 5, 2022 at 8:40 PM Warren Toomey via TUHS >>> wrote: >>> >>>> Hi all, we have a new addition to the Unix Archive at: >>>> https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ >>>> >>>> This is the documentation for Unix 4.0 which preceded System V. The >>>> documents were provided by Arnold Robbins and scanned in by Matt >>>> Gilmore. >>>> >>>> Cheers, Warren >>>> >>> >>> >>> -- >>> Advice is judged by results, not by intentions. >>> Cicero >>> >>> > > -- > Advice is judged by results, not by intentions. > Cicero > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From egbegb2 at gmail.com Sun Jun 12 15:45:51 2022 From: egbegb2 at gmail.com (Ed Bradford) Date: Sun, 12 Jun 2022 00:45:51 -0500 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: References: Message-ID: [image: image.png] On Sat, Jun 11, 2022 at 9:44 AM Clem Cole wrote: > Your welcome. What do you mean by the first link did not work. It’s a > tarball that has to be decoded and then look inside for the original code. > It’s there. I just tried it. > > On Sat, Jun 11, 2022 at 12:35 AM Ed Bradford wrote: > >> Thank you, Clem. You link didn't work but the other information on cssc >> worked fine. >> >> Ed >> >> >> On Fri, Jun 10, 2022 at 9:23 AM Clem Cole wrote: >> >>> The original Marc Rochchild/John Mashey and team code from PWB 1.0 can >>> be found: http://tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz >>> In the directory: sys/source/sccs4 >>> The man pages are in the same archive but mixed with the rest of the >>> commands in usr/man/man* >>> >>> That said, there is Gnu version of same written C++ if IIRC: >>> https://www.gnu.org/software/cssc/ >>> >>> And there's more ... but I'll Larry offer details here other than point >>> out his: http://www.bitmover.com/bitsccs/ [which is of BitKeeper] is a >>> more modern implementation still] >>> ᐧ >>> >>> On Fri, Jun 10, 2022 at 2:48 AM Ed Bradford wrote: >>> >>>> Hi Warren, >>>> >>>> Thank you for the amazing Unix documetation. >>>> Do you know if there is a source code for SCCS anywhere on the net? >>>> >>>> Ed Bradford >>>> >>>> On Sun, Jun 5, 2022 at 8:40 PM Warren Toomey via TUHS >>>> wrote: >>>> >>>>> Hi all, we have a new addition to the Unix Archive at: >>>>> https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ >>>>> >>>>> This is the documentation for Unix 4.0 which preceded System V. The >>>>> documents were provided by Arnold Robbins and scanned in by Matt >>>>> Gilmore. >>>>> >>>>> Cheers, Warren >>>>> >>>> >>>> >>>> -- >>>> Advice is judged by results, not by intentions. >>>> Cicero >>>> >>>> >> >> -- >> Advice is judged by results, not by intentions. >> Cicero >> >> -- > Sent from a handheld expect more typos than usual > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 188213 bytes Desc: not available URL: From tuhs at tuhs.org Sun Jun 12 16:41:00 2022 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 12 Jun 2022 16:41:00 +1000 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: References: Message-ID: On Sat, Jun 11, 2022 at 12:35 AM Ed Bradford <[2]egbegb2 at gmail.com> wrote: > Thank you, Clem. You link didn't work but the other information on cssc > worked fine. All, it turns out that this was my fault. I'd moved the A record for www.tuhs.org over to the new IP address, but I hadn't moved the A record for tuhs.org over to that new IP address. I've just done so, but it will take a while for the DNS records to proagate. Apologies! Warren From tuhs at tuhs.org Mon Jun 13 23:18:24 2022 From: tuhs at tuhs.org (Jay Logue via TUHS) Date: Mon, 13 Jun 2022 06:18:24 -0700 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: References: Message-ID: <165512630943.1470.17753618581265860679@minnie.tuhs.org> On 6/11/2022 11:41 PM, Warren Toomey via TUHS wrote: > All, it turns out that this was my fault. I'd moved the A record for > www.tuhs.org over to the new IP address, but I hadn't moved the A record > for tuhs.org over to that new IP address. Maybe make www.tuhs.org a CNAME for tuhs.org? --Jay From norman at oclsc.org Tue Jun 14 01:49:38 2022 From: norman at oclsc.org (Norman Wilson) Date: Mon, 13 Jun 2022 11:49:38 -0400 (EDT) Subject: [TUHS] Documentation for Unix 4.0 Message-ID: <8845BDF5A20243F3CD8C296C36066BB3.for-standards-violators@oclsc.org> Maybe make www.tuhs.org a CNAME for tuhs.org? Surely a site devoted to the history of UNIX should use a real link, not a symbolic one. Norman `Old Fart' Wilson Toronto ON From michael at kjorling.se Tue Jun 14 02:39:13 2022 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Mon, 13 Jun 2022 16:39:13 +0000 Subject: [TUHS] Documentation for Unix 4.0 In-Reply-To: <8845BDF5A20243F3CD8C296C36066BB3.for-standards-violators@oclsc.org> References: <165512630943.1470.17753618581265860679@minnie.tuhs.org> <8845BDF5A20243F3CD8C296C36066BB3.for-standards-violators@oclsc.org> Message-ID: <54cd67b2-78f3-4ad3-a3c0-d0b885e67970@home.arpa> On 13 Jun 2022 11:49 -0400, from norman at oclsc.org (Norman Wilson): >> Maybe make www.tuhs.org a CNAME for tuhs.org? > > Surely a site devoted to the history of UNIX should use a > real link, not a symbolic one. Surely a site that aims to collect information should have a single canonical name, not multiple ones that lead to the same content on the same host. I would suggest to pick either www.tuhs.org or tuhs.org as the HTTP hostname, and make the other redirect to the first (or remove HTTP service from the not-chosen one entirely) only so as to not break existing links from elsewhere. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”