TUHS

tuhs@tuhs.org

28 participants
6556 discussions

by jnc＠mercury.lcs.mit.edu

> From: Wesley Parish > I think the best thing for all would be the release of the Unix SysV > source trees under a suitable open source license. You may think that; I may think that, we _all_ may think that. But in the legal world, that, and $2 (or whatever the going rate is these days) will get you a cup of coffee. Unless someone is prepared to chivvy a rights-holder into actually _doing_ something, any talk is ... just that. Any volunteers to make something actually happen? Noel

8 years, 5 months

Data recovery from magtapes, we're on hackaday! :)

by asbesto

Hi there, in case of someone is in need of data recovery, we managed to do some nice work :) http://hackaday.com/2017/03/03/raiders-of-the-lost-os-reclaiming-a-piece-of… love all -- [ ::::::::: 73 de IW9HGS : http://museum.freaknet.org :::::::::::: ] [ Freaknet Medialab :: Poetry Hacklab : Dyne.Org :: Radio Cybernet ] [ NON SCRIVERMI USANDO LETTERE ACCENTATE - NON MANDARMI ALLEGATI ] [ *I DELETE* EMAIL > 100K, ATTACHMENTS, HTML, M$-WORD DOC and SPAM ]

8 years, 5 months

SCO OpenDesktop 386 2.0.0

by Rudi Blom

The 'oldest' I have is a set of SCO UNIX 3.2V4.0 and V4.2 Mail me if you're interested Cheers, rudi > Message: 1 > Date: Sat, 25 Feb 2017 16:55:25 -0800 > From: Cory Smelosky <b4(a)gewt.net> > To: tuhs(a)minnie.tuhs.org > Subject: [TUHS] SCO OpenDesktop 386 2.0.0 > Message-ID: > <1488070525.154368.892915216.18B7F7A4(a)webmail.messagingengine.com> > Content-Type: text/plain; charset="utf-8" > > Hey, > > Does anyone have any of the floppies for OpenDesktop 2.0.0? Mine got > damaged in a dehumidifier failure before they got to California. The > only survivor was of all things...the QIC-24 tape (which I have read > fine) > > sco-tape> tar tf file0 | more > ./tmp/_lbl/prd=odtps/typ=u386/rel=2.0.0a/vol=1 > > Anyone know a good starting point for attempting to install it in to a > VM? ;) > -- > Cory Smelosky > b4(a)gewt.net

8 years, 5 months

Re: [TUHS] Source code abundance?

by Nick Downing

Yes. And I just want to point out the systems vendor's worst nightmare: Competition from an earlier version of their own product. History is littered with examples where something was deliberately left to wither and die for this reason. Apple II and IIgs: We all know that the IIgs was deliberately crippled, and then discontinued in favour of the IIc+, as it presented a viable alternative to the 68000-based Macs. 680x0 Macs: Apparently some licensees had 68060 Macs and accelerators in the works, but Apple refused access to the ROMs to add the 68060 support code, because it would have been a viable alternative to the PowerPC 603. IBM OS/2: Was heavily DOS based (I believe it used the INT 21h API with modifications for protected mode), but in fact was eclipsed by later versions of DOS/Windows that were retrofitted with things like DPMI support, hacky but effective in providing a viable alternative to OS/2. BSD and SysIII: For a while it looked like the 32V-derived BSDs were going provide a viable alternative to AT&T's official developments of the same, and it took some heavy handed legal and political manouevring and backroom deals to make sure that did not happen in the end. AMD64 and Itanium: Enough said, a very expensive egg on face episode for Intel. 8086/8088 and iAPX432: Same thing except it was actually Intel's own product that provided a viable alternative to the "official" new version rather than a competitor's development of it. Of course a similar story can be told about 8080/Z80/8085/8086, Intel faced stiff competition from an enhanced version of their own product before wresting back control with the much improved 8086. A nightmare for them. That's the real reason vendors won't open source. Nick On Mar 4, 2017 12:02 PM, "Henry Bent" <henry.r.bent(a)gmail.com> wrote: On 3 March 2017 at 18:56, Wesley Parish <wes.parish(a)paradise.net.nz> wrote: > > And since the central Unix source trees have been static - I don't think > Novell was much more than a > caretaker, correct me if I'm wrong - and the last SysVR4 release of any > consequence was Solaris - has > Oracle done anything with it? - I think the best thing for all would be > the release of the Unix SysV > source trees under a suitable open source license. There was an SVR5, even if it was not nearly the popular product that its predecessors were. While development certainly slowed, it contained some amount of technological progression. Obviously at this point development has stopped completely and it probably does make sense to open source that code base. > (I've made a similar argument for the IBM/MS OS/2, > DEC VAX VMS, and MS Windows and WinNT 3.x and 4.x source trees on various > other Internet forums: > the horse has bolted, it's a bit pointless welding shut the barn door now. > Better to get the credit for > being friendly and open, and clear up some residual bugs while you're at > it ... ) Equating VMS, old versions of Windows, etc. isn't quite the same. Even old versions of those products may well include source that contains, or is believed by its owners to contain, novel ideas or novel implementations of existing ideas that may have survived relatively unchanged in newer versions. And because there is at least a reasonably sized user base for all of the products you mentioned, corporate customers have an interest in protecting their investment, and the software creators have an interest in responding to the desires (or perceived desires) of their customers. Don't get me wrong - I'd love to see a legal release of the VMS 5 source, or Windows 3 source, or classic Macintosh source. I'm just not holding my breath. I think the community's time would be better spend advocating for source releases of products that are truly dead or all but dead. -Henry

8 years, 5 months

Re: [TUHS] AIX/370 Questions

by Clem Cole

On Wed, Mar 1, 2017 at 9:13 PM, Jason Stevens < jsteve(a)superglobalmegacorp.com> wrote: > Slightly off or on topic, but since you seem to know, and I've never seen > aix 370 in the eild, did it require VM? > It could boot on raw HW. > Did it take advantage of SNA, and allow front ends, along with SNA > gateways and 3270's? > Not sure how to answer this. It was an IBM product and could be used with a lot of other IBM's products. Generally speaking it was aimed at the Educational market, although there were some commercial customers, for instance Intel was reputed to do a lot of the 486 simulation on a TCF cluster (I don't know that for sure, that was before I worked for Intel). > > Or was it more of a hosted TCP/IP accessable system? > Clearly, if you had a PS/2 in the cluster, that was your access point. I think it was all mixed up in the politics of the day at IBM between Enterprise, Workstations, and Entry systems. TCP/IP and Ethernets were not something IBM wanted to use naturally. But the Educational market did use it and certainly some folks at IBM saw the value. UNIX was needed for the Education market as was TCP/IP so that going to be the pointed head of the stick.

8 years, 5 months

Un-released/internal/special UNIX versions/ports during the years?

by Arno Griffioen

Hi! Some of the stories on here reminded me of the fact that there's also likely a whole boat-load of UNIX ports/variants in the past that were never released to customers or outside certain companies. Not talking about UNIX versions that have become obsolete or which have vanished by now like IRIX or the original Apple A/UX (now *that* was an interesting oddball though..) and such, but the ones that either died or failed or got cancelled during the product development process or were never intended to be released to the outside ar all. Personally I came across one during some UNIX consultancy work at Commodore during the time that they were working on bringing out an SVR4 release for the Amiga (which they actually sold for some time) Side-note.. Interestingly enough according to my contacts at that time inside CBM it was based on the much cheaper to license 3B2 SVR4 codebase and not the M68k codebase which explained some of the oddities and lack of M68k ABI compliance of the Amiga SVR4 release.. However.. It turned out that they had been running an SVRIII port on much older Amiga 2000's with 68020 cards for some of their internal corporate networking and email, UUCP, etc. and was called 'AMIX' internally. But as far as I know it was never released to the public or external customers. It was a fairly 'plain jane' SVRIII port with little specific 'Amiga' hardware bits supported but otherwise quite complete and pretty stable. Worked quite well in the 4MB DRAM available on these cards. The later SVR4 didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!) 16MB. It was known 'outside' that something like this existed as the boot ROM's on the 68020 card had an 'AMIX' option but outside CBM few people really knew much about it. It may have been used at the University of Lowell as they developed a TI34010 based card that may already have had some support in this release. Still.. This does make me wonder.. Does anyone else know of these kinds of special 'snowflake' UNIX versions that never got out at various companies/insitutes? (and can talk about it without violating a whole stack of NDA's ;) ) No special reason.. Just idle curiosity :) Likely all these are gone forever anyway as prototypes and small run production devices and related software tends to get destroyed when companies go bust or get aquired. Bye, Arno.

8 years, 5 months

Re: [TUHS] Un-released/internal/special UNIX versions/ports during the years?

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > Another acronym is Esc Meta Alt Ctl Shift... Good one! And there was a pretty funny fake Exxx error code - I think it was "EMACS - Editor too big"? I was never happy with the size of EMACS, and it had nothing to do with the amount of memory resources used. That big a binary implies a very large amount of source, and the more lines of code, the more places for bugs... And it makes it harder to understand, for someone working on it (to make a change/improvement). Noel

8 years, 5 months

Re: [TUHS] Was 5ESS built on UNIX?

by Rudi Blom

>Date: Tue, 28 Feb 2017 14:11:24 -0500 >From: Nemo <cym224(a)gmail.com> >To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> >Subject: [TUHS] Was 5ESS built on UNIX? >Message-ID: ><CAJfiPzyDkUP7aAfxQTv51MF61a4CjKSSMxduQaW+Yp0cW00y5w(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >>I have looked at the papers published in the AT&T Technical J. in 1985 >and found no mention of UNIX. > >N. My Prentice Hall "UNIX(R) System V Release 4, Programmer's Guide: Streams" lists AT&T copyrights from 1984 - 1990 and UNIX Systems Laboratories, Inc. 1991-1992. Rudi

8 years, 5 months

Also, PC/IX and SCO Xenix System V 2.1.3

by Warren Toomey

There's a PC Emulator here with PC/IX and SCO Xenix System V 2.1.3 images: http://www.hampa.ch/pce/download.html Cheers, Warren

8 years, 5 months

Re: [TUHS] Was 5ESS built on UNIX?

by Doug McIlroy

As Corey said, administrative computers in switching centers ran Unix, but the call-processing machines ran an unrelated operating system. The Unix lab did influence that operating system. Bob Morris instigated, and Joe Condon, Lee McMahon, Ken Thompson and others built TPC (the phone company), a switching system controlled by a PDP-11. This system actually ran the phones in CS Research for several years. ESS5 adopted some of TPC's architecture, though none of its code. Doug

8 years, 5 months

Re: [TUHS] Mach for i386 / Mt Xinu or other

by Norman Wilson

Dave Horsfall: And if my failing memory serves me correctly, [Henry Spencer] wrote C-News in conjunction with Geoff Collier, as B-News was starting to show its age and limitations. ==== Your failing memory is correct, except that his name is spelt Collyer, not Collier. Norman Wilson Toronto ON

8 years, 5 months

troff, flo

by Steve Simon

Hi, On the subject of Troff, this package seems to have disappeared: flo—A Language for Typesetting Flowcharts Anthony P. Wolfman and Daniel M. Berry Computer Science, Technion, Haifa 32000, ISRAEL 1989 The paper about it is available but the code has gone. Anyone have an archive of it? -Steve

8 years, 5 months

Re: [TUHS] Emacs and undump

by Johnny Billquist

On 2017-02-27 08:26, Lars Brinkhoff <lars(a)nocrew.org> wrote: > Tim Bradshaw wrote: >>> David wrote: >>> I remember that GNU Emacs launched the first time and then dumped >>> itself out as a core file. Each subsequent launch would then ‘undump’ >>> itself back into memory. All this because launching emacs the first >>> time required compiling all that lisp code. >> It still works like that. Indeed that's the conventional way that >> Lisp systems tend to work for delivering applications > Emacs came from ITS, and many Lisps derive from Maclisp which also came > from ITS. In ITS, it was common for applications to be dumped into a > loadable core image, even if they were written in assembly language. Not only i ITS. This is how things work in OS/8, for example. I believe it is also how things work in TOPS-10 and quite possible also in TOPS-20. Not sure about RT-11, but I wouldn't be surprised if that's the way there too. Essentially, the linker leaves the image in memory. It does not write it to a file. And then, the command decode have a command for dumping your memory to disk, as a runable image. There is some information kept around that the linker sets up, which means you don't normally have to tell the command decoder which parts of memory to save, or what the start address is, and so on. But you can also give that information in your save command. One of the nice things of this approach is that you can load an image into memory, and then use the debugger to look around in it, change it, or run it. And if the program exists, it is still in memory, including all data, which means you can check the state of everything at exit time. And of course, if you want to, you can load a program, patch around in it, in memory, and then run it. And, of course, you can load a program, run some part of it, and dump it to disk at that stage, so all initializations have been done. Your memory is always around, and is not tied to a process that comes and goes. Of course, the back side of that is that you can't really run several programs at once. But it's not hard to see that RMS and GNU Emacs (coming from these systems) wanted the same thing again. It do have some points. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

8 years, 5 months

mt Xinu tapes

by Deborah Scherrer

Sorry, the search has failed to dig up any old mt Xinu tapes. None of us were smart enough to save them... Sorry. Debbie

8 years, 5 months

Re: [TUHS] Emacs and undump

by Nick Downing

Hmm well I am more interested in the ancient code, I am not averse to adding improvements but I want to do so in a controlled way. Also I prefer not to use any Sys3~5 interfaces in my current project which is exclusively BSD. Haha, well I de-algoled /bin/sh twice so far, first time was for my uzi to Z180 port about 10yrs back, and second time was for my 4.3BSD to Linux porting library project last month. In the intervening time I became quite a sed wizard and my latest de-algolizer is completely automated and produces very nice results. Could possibly be improved by astyle's removal of braces around single statements, I considered this too risky at the time but I have since realized I can compare the stripped executables to convince myself that it does not change the logic, indeed I should check the basic de-algolizer in this way also. Lately I have been thinking of running all of 4.3BSD through astyle but I hesitate to do unnecessary changes, one always regrets them when doing any bisecting or rebasing stuff... Nick On Feb 28, 2017 3:43 AM, "Joerg Schilling" <schily(a)schily.net> wrote: Derek Fawcus <dfawcus+lists-tuhs(a)employees.org> wrote: > How about applying Geoff Collyer's change to the shell memory management > routine available here: > > http://www.collyer.net/who/geoff/stak.port.c Depends on what shell you are talking about. The code named by you only works with a very old Bourne Shell that can be retrieved from the server of Geoff Collyer. If you are interested in the recent Bourne Shell (SVr4 + Solaris changes), you better use my Bourne Shell sources that can be found inside the schily-tools: http://sourceforge.net/projects/schilytools/files/ The code from above will not work in a recent Bourne Shell without changes in both, Geoff Collyer's stak.c and the rest of the Bourne Shell. Jörg -- EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/ projects/schilytools/files/

8 years, 5 months

Re: [TUHS] Emacs and undump

by Johnny Billquist

Ooo. Fun. We're talking PDP-10s on a Unix list... :-) On 2017-02-27 16:13, Arthur Krewat <krewat(a)kilonet.net> wrote: > In TOPS-10, you could detach from your current job, login again, and > keep going. Then, attach to the previous job, and go back and forth > endlessly. Right. But that is a different thing. Each terminal session only have one job. The fact that you can detach that, and log in as a new session is a different concept. > As for keeping memory around, it was very common on TOPS-10 to put code > in a "hiseg" that would stick around, and was shareable between "jobs". Yes. Again, that is a different thing as well. Hisegs are more related to shared memory. I assume you know all this, so I'm not going to go into details. But having the memory around for a program, even if it is not running, is actually sometimes very useful. If ITS could handle that, while treating them as separate processes, all associated to one terminal, and let you select which one you were currently fooling around in, while the others stayed around, that is something I don't think I've seen elsewhere. > For something like EMACS, it would be very efficient to have the first > person run it "compile" all the LISP, leave it in the hiseg, and other > jobs can then run that code. That would work, but it would then require that all other users be suspended until the first user actually completes the initialization, and after that, all the memory must be readonly. > Not knowing anything about EMACS, I'm not sure that compiled code was > actually shareable if it was customized, just thinking out loud. You can certainly customize and save your own image. But the general bootstrapping of Emacs consists of starting up the core system, and then loading a whole bunch of modules and configurations. All that loading and parsing of those files into data structures in memory is quite cpu intensive. Once all that processing is finished, you can start editing. Each person essentially wants all that work done, no matter what they'd like to do later. So, Emacs does it once, and then saves the state at the point where you can start editing. But it does not mean that the memory is shareable. It's full of various data structures, and code, and that will change as you go along editing things as well. > But even without leveraging the hiseg capability, it was relatively easy > to save an entire core image back to a .SAV or .LOW or later a .EXE. I > don't remember how easy it was to do that programmatically, but it was > easy from the terminal and if it saves a lot of processor time (and > elapsed time) people would have been happy to do it manually. Indeed. Like I said, Tops-10 have the same concept as Emacs does today. But there it was essentially what you always did. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

8 years, 5 months

Emacs and undump

by David

I ported GNU Emacs to the Celerity product line mostly because most of the programmers there wanted it over vi. Not me, I’m a vi guy. I remember that GNU Emacs launched the first time and then dumped itself out as a core file. Each subsequent launch would then ‘undump’ itself back into memory. All this because launching emacs the first time required compiling all that lisp code. Does anyone else remember this? David

8 years, 5 months

Re: [TUHS] The size of EMACS, and what hides in kLOCs

by Nemo

On 26 February 2017 at 12:28, Andy Kosela <andy.kosela(a)gmail.com> wrote: [...] > Are you sure it was emacs? Most probably it was pico, which was the default > editor for pine. We used pine/pico for all email at our university in the > 90's. It was wildly popular. Ah well, I am not sure -- that betrayed my emacs bias. I saw ^X^C and assumed emacs. N.

8 years, 5 months

Re: [TUHS] BSDi Imaging

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer > On 2/25/17 11:25 AM, Cory Smelosky wrote: >> MtXinu is something I really want. > I worked there for 10 years (eventually becoming President). I'll try > to dig up a tape. Say what you will about RMS, but he really did change the world of software. Most code (except for very specialized applications) just isn't worth much anymore (because of competition from open source) - which is part of why all these old code packages are now freely available. Although I suppose the development of portabilty - which really took off with C and Unix, although it had existed to some degree before that, q.v. the tools collection in FORTRAN we just mentioned - was also a factor, it made it possible to amortize code writing over a number of different types of machines. There were in theory portable languages beforehand (e.g. PL/1), but I think it probably over-specified things - e.g. it would be impossible to port Multics to another architecture without almost completely re-writing it from scratch, the code is shot through with "fixed bin(18)"'s every other line... Noel

8 years, 5 months

Re: [TUHS] The size of EMACS, and what hides in kLOCs

by Nemo

On 26 February 2017 at 07:46, Michael Kjörling <michael(a)kjorling.se> wrote: > On 26 Feb 2017 07:39 -0500, from jnc(a)mercury.lcs.mit.edu (Noel Chiappa): >> I was never happy with the size of EMACS, and it had nothing to do with the >> amount of memory resources used. That big a binary implies a very large amount >> of source, and the more lines of code, the more places for bugs... > > But remember; without Emacs, we might never have had _The Cuckoo's > Egg_. Imagine the terror of that loss. Hhhmmm.... I must dig my copy out of storage because I do not remember emacs in there. As for emac uses, my wife was on (non-CS) staff at a local college affiliated with U of T. At the time, DOS boxes sat on staff desks and email was via a telnet connection to an SGI box somewhere on campus. A BATch file connected and ran pine but shelled out to an external editor. What was the editor? Well, I saw her composing a message once and ending the editor session by ^X^C. N.

8 years, 5 months

Re: [TUHS] SCO OpenDesktop 386 2.0.0

by Rudi Blom

Wasn't the default FS type S51K? Limitations like 14 chars directory names only. No symbolic link ? >Date: Sun, 26 Feb 2017 11:13:25 -0500 >From: Arthur Krewat <krewat(a)kilonet.net> >To: Cory Smelosky <b4(a)gewt.net>, Jason Stevens > <jsteve(a)superglobalmegacorp.com>, tuhs(a)minnie.tuhs.org >Subject: Re: [TUHS] SCO OpenDesktop 386 2.0.0 >Message-ID: <f5a1d513-3cc1-6a4d-64a3-669b49d7226f(a)kilonet.net> >Content-Type: text/plain; charset="utf-8"; Format="flowed" > >What filesystem type does it use for root/boot/whatever? > >Install operating system "X" that supports that filesystem type in the >virtual guest, create a new disk, newfs/mkfs it, arrange the bits from >the tape, take the newly-assembled disk and move to another VM and try >to boot it. > >Not remembering anything about how SVR3.2 boots (I think that's what >Opendesktop is?) that's the end of my help on the subject :)

8 years, 5 months

SCO OpenDesktop 386 2.0.0

by Cory Smelosky

Hey, Does anyone have any of the floppies for OpenDesktop 2.0.0? Mine got damaged in a dehumidifier failure before they got to California. The only survivor was of all things...the QIC-24 tape (which I have read fine) sco-tape> tar tf file0 | more ./tmp/_lbl/prd=odtps/typ=u386/rel=2.0.0a/vol=1 Anyone know a good starting point for attempting to install it in to a VM? ;) -- Cory Smelosky b4(a)gewt.net

8 years, 5 months

Re: [TUHS] The size of EMACS, and what hides in kLOCs

by Mutiny

> On 26 Feb 2017 07:39 -0500, from jnc(a)mercury.lcs.mit.edu (Noel Chiappa):>> I was never happy with the size of EMACS, and it had nothing to do with >> the amount of memory resources used. That big a binary implies a very >> large amount of source, and the more lines of code, the more places for >>bugs...GNU Emacs 26.0.50, GTK+ Version 3.22.8) of 2017-02-25 (Fedora25, Kernel: 4.9.11:Virtual: 794.6Resident:  36.8 

8 years, 5 months

Re: [TUHS] Mach for i386 / Mt Xinu or other

by jnc＠mercury.lcs.mit.edu

> From: Joerg Schilling > He is a person with a strong ego and this may have helped to spread > Linux. Well, I wasn't there, and I don't know much about the early Linux versus UNIX-derivative contest, but from personal experience in a similar contest (the TCP/IP versus ISO stack), I doubt such personal attributes had _that_ much weight in deciding the winner. The maximum might have been that it enabled him to keep the Linux kernel project unified and heading in one direction. Not inconsiderable, perhaps, if there's confusion on the other side.,, So there is a question here, though, and I'm curious to see what others who were closer to the action think. Why _did_ Linux succeed, and not a Unix derivative? (Is there any work which looks at this question? Some Linux history? If not, there should be.) It seems to me that they key battleground must have been the IMB PC-compatible world - Linux is where it is now because of its success there. So why did Linux succeed there? Was is that it was open-source, and the competitor(s) all had licensing issues? (I'm not saying they did, I just don't know.) Was it that Linux worked better on that platform? (Again, don't know, only asking.) Perhaps there was an early stage where it was the only good option for that platform, and that's how it got going? Was is that there were too many Unix-derived alternatives, so there was no clarity as to what the alternatives were? Some combination of all of the above (perhaps with different ones playing a key role at different points in time)? Noel

8 years, 5 months

BSDi Imaging

by Cory Smelosky

All, I'm dumping as much BSD/OS stuff as I can tonight. This includes: SPARC, sources, and betas. Unable to dump any floppies, however. -- Cory Smelosky b4(a)gewt.net

8 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS