TUHS

tuhs@tuhs.org

20 participants
6516 discussions

GNU vs BSD before the lawsuit and before Linux

by Doug McIlroy

> Many of the gnu tools started life as BSD code that was hacked on and > rebranded with the GPL. I have seen Gnu code likewise adopted from AT&T. Doug

8 years, 2 months

pathalias and sendmail experience?

by Warren Toomey

I know it's a long shot. Does anybody remember how to use the output of pathalias in sendmail.cf? Specifically, we have set up 4.3BSD with uucp-only e-mail, and we have a map file which pathalias digests and outputs fine. I can't find any useful documentation on putting this output into sendmail. There's part of a book in Google books, but two pages are hidden. I also threw out my old bat book ages ago. I have a PDF of Sendmail_4th_Edition_Oct_2007.pdf but it doesn't mention pathalias. Thanks in advance! Warren

8 years, 2 months

Re: [TUHS] X, Suntools, and the like

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" >>> I think most people will attribute the desktop metaphor to Xerox. >> Strictly speaking, to Smalltalk (from PARC) ^^^^ > I beg to differ. The Star not only pioneered the WISIWYG application > presentation PARC _was_ Xerox. The Star was a product based on the Alto, but much of the Star stuff was pioneered on the Alto. For instance, WYSIWYG was one of the modes that the Alto's Bravo editor could be run in; it definitely pre-dates the Star. > also the concept of the desktop. Depending on exactly what you mean by 'desktop', that also pre-dated the Star. I heard the multiple overlapping windows of Smalltalk (an Alto application) likened to a collection of sheets of paper on a desktop (which is where the term came from); clicking on one with the mouse brought it to the top, just like pulling a particular sheet of paper out from the ones on a physical desktop. > The whole conscept of dropping documents as icons on the desktop appears > to have orginated there. Yes, as I mentioned: >> things like Bravo, and the basic user command interface on the Alto >> [the Exec, my brain finally coughed up the name - can't find my Alto >> manual at the moment] didn't have any concept of windows/desktop The concept of having a graphical front end as the main user interface was not from the Alto, and the Alto didn't have icons either; both came later (I'll let the Lisa people and Star people argue that one out). Noel

8 years, 2 months

Re: [TUHS] X, Suntools, and the like

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > I think most people will attribute the desktop metaphor to Xerox. Strictly speaking, to Smalltalk (from PARC); things like Bravo, and the basic user command interface on the Alto (I forget what its name was), didn't have any concept of windows/desktop (although Bravo did use the bitmap screen). Noel

8 years, 2 months

Re: [TUHS] System Economics

by Doug McIlroy

"Open" was certainly not a work heard in the Unix lab, where our lawyers made sure we knew it was a "trade secret". John Lions was brought into the lab both because we admired his work and because the lawyers wanted to reel that work back in-house. Out in the field, the trade secret was treated in many different ways. Perhaps the most extreme was MIT, whose lawyers believed it could not be adequately protected in academia and forbade its use there. I don't know what eventually broke the logjam. Doug

8 years, 2 months

Re: [TUHS] System Economics (was is Linux "officially branded UNIX")

by Norman Wilson

William Pechter: VMS source fiche was very common of sites owned by large corporations. Their IT staff used it to research bugs... and as sample code for writing their own drivers etc... ===== Indeed, I used the VMS source microfiche to learn how to handle various sorts of errors (machine checks, memory errors) better in UNIX. Stock VAX systems at the time just crashed on any error, but it turned out that many of them admitted recovery: some errors were transient, others could be ridden over by disabling some piece of the hardware. This led to an amusing event on the VAX-11/750 that at the time handled e-mail as uucp node research!. (Its internal name on our datakit node was grigg.) People noticed that the system was running slowly. I checked and discovered that the CPU itself seemed to be a bit slower. Then I checked logs and discovered that a week earlier, there had been a cache error; my new recovery code had turned off the failing half of the cache, logged the error, and forged ahead. At the next convenient time, we took the system down and ran DEC's standalone diagnostics. (Contrary to the rude stories one hears, those diags were in fact pretty thorough.) The problem didn't show up, so we booted grigg back up again, secure in the knowledge that if the problem was persistent, my code would let us know without crashing. (I don't think it ever showed up again.) We also learned to pay more attention to console messages! Norman Wilson Toronto ON

8 years, 2 months

Re: [TUHS] System Economics

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Do you know the time frame of the banishment? Noel any memories of what > allowed it be used? Sorry, this is something I know nothing of; it must have happened while I was still an early undergrad. The first Unix I knew of at MIT was the one in the DSSR/RTS group in LCS, which arrived (I think) roughly around the start of my sophmore year (so early '76 or so) - I have a memory of one of my friends (who was an undergrad working in that group) telling me about it, and showing it to me. (I remember being totally blown away with the way you could write a command 'foo', compile it, and jut say 'foo' to run it...) Actually, it may have shown up well before that - perhaps they had it well before I first saw it. Certainly by the time I showed up at LCS (fall of '77) it had already spread to CSR; they had an 11/40 with Unix on it, cloned from the DSSR system. Again, I don't know if there was any paperwork that had to happen, or if that system was already covered under whatever license the DSSR machine was under. Of course, this was all DARPA-funded work, and there may have been something there that allowed it. We certainly passed Unix source around with other DARPA projects (e.g. at BBN) without, AFAICR, worrying much about paperwork. > we had a sign a document with the university stating something that we > understood it was AT&Ts IP I don't recall anything like that at MIT; maybe in the very early days, there was something, but certainly not by '77. If it's important to know what happened, I can ask (e.g. Prof. Ward, head of DSSR). Noel

8 years, 2 months

Re: [TUHS] attachments: MIME and uuencode

by jnc＠mercury.lcs.mit.edu

> From: Random832 > I think he means the fact that MIME specifies the type of the main > message body (not just attachments), so you can have a message with *no* > text parts. Right, that I could discern; what I couldn't get with an definitiveness was _why_ that was particularly a problem. (Another possibility, other than the one I previously gave, is perhaps that there simply is no text part, which one can peruse, ignoring the rest?) Noel

8 years, 2 months

"Xenix 2.2.3c Restoration" articles by Michael Casadevall

by Josh Good

Hello. Perhaps you haven't been made aware yet of these series of --IMHO-- very interesting articles about Xenix 386, entitled "Xenix 2.2.3c Restoration", by Michael Casadevall, a.k.a. NCommander at the geek site https://soylentnews.org (of which he is one of the founders): Part 1: https://soylentnews.org/article.pl?sid=17/03/03/1620222 Part 2: https://soylentnews.org/article.pl?sid=17/03/07/1632251 Part 3: https://soylentnews.org/article.pl?sid=17/03/11/2014253 I wish Bela Lubkin, ex- kernel engineer at "classic" SCO, would have joined the list to comment on those articles and pour some light into the more obscure points. I sent an email to Bela some time ago telling him about the TUHS mailing list, but I didn't hear back from him. -- Josh Good

8 years, 2 months

Re: [TUHS] X, Suntools, and the like

by Nick Downing

Hmm yes although perhaps controversially I see this as a bad feature and one area where Microsoft actually gets it right. Despite the old issues of "DLL Hell" which have largely been resolved by standardizing all DLLs and in newer code by using assemblies... you have to admit that they provide a direct, local API (indeed ABI) to every subsystem you would want to use, here I am thinking of GDI, but also lots of things that would require ioctls (CD burning, say) or domain specific languages (such as Postscript) on Linux. This makes it really easy for Windows developers to use the feature and the interface is fast and reliable. And where a domain specific language is actually NEEDED (printing to a Postscript printer on Windows, or RDP-type desktop remoting etc) it is easy to insert a proxy DLL or object or device driver that does the necessary scrambling and unscrambling. It is not so easy to go the other way as it requires extensive emulation (think of ghostscript driving my Canon non-PS printer). I wrote about this issue earlier using some examples like an "ESC [" capable terminal as opposed to a memory mapped local console, or an "AT" capable external modem as opposed to an internal "WinModem" that just exposes its D/A and A/D converters with minimal signal processing and needs the host to do the heavy lifting. Same thing applies to a graphics terminal. Of course it should be programmed at a high level by specifying shapes, etc to be drawn, regions to be blitted, clipping regions and pens etc, a font manager, and it should be possible to load bitmaps, etc, into its offscreen memory and/or create offscreen drawing buffers, if these features are used correctly by applications then it is of course trivial to add a remoting proxy driver similar to Microsoft's RDP, or indeed X Windows. But the difficulty with X Windows is that the remoting layer is always there, even though it is almost completely redundant today. This hurts performance but more importantly it requires extensive workarounds as you described, which add enormous extra complexity and in my view sharply increase the learning curve and setup costs. Having said that, Xlib does offer a decent API/ABI so if we just code to that it's not TOO bad, I would like to see the rest of it deprecated though, and vendors encouraged to implement Xlib with whatever backend seems appropriate. The ridiculous thing here is that X setup is so damn convoluted and incestuously tied in with the window, session and display managers, THAT IT IS IMPOSSIBLE TO RUN X REMOTELY ANYMORE AND HAVE A FULL FEATURED DESKTOP, I have tried many times and have had various tries at thin clients and terminal serving in my home network and it basically fell over because environments like Gnome do not support multiple sessions of the same home directory, not to mention numerous other problems that mean if you login remotely you basically just get a blank screen with a default X cursor and maybe a context menu that can run an Xterm. Bleh! In my experience you have to use a remoter like VNC and guess what that does, tricks X into thinking it's running locally and then intervenes further up in the display stack to do the actual remoting. It's a complete dog's breakfast and frankly could never compete with Windows in any realistic way. I use it because it is the least bad of the available options (no way am I having advertising in my start menu and my computer loaded with bloatware and spyware before I even open the box, and no way am I putting up with vague messages like "Something went wrong" or "Windows is making some checks to optimize your experience" or whatnot), and because my computer is so fast despite being 6yrs old that X only feels borderline sluggish, i.e. is tolerable. But so much better would be possible with a redesign. CUPS is also a dogs breakfast and hugely unreliable, Windows GDI printing just wins hands down for all the same reasons. End rant. Nick On Mar 15, 2017 5:49 AM, "Ron Natalie" <ron(a)ronnatalie.com> wrote: Nice thing about X was that it would talk to remote displays. I still remember sitting in the Pentagon demonstrating that the Suntools screen lock wasn't particularly secure. Then there was NeWS. This was Gosling's first attempt at a deployable language. However PostScript (even with Owen Densmore's class extensions), while a reasonable intermediary language is really sucky to actually develop. Java was a bit more refined. Of course, lots of things either implement X under the native window system or backdoor X with local extensions. We got around doing high frame rate image work on X via the SharedMemoryExtension and the ability to flip buffers on the retrace interval (both extensions, but commonly implemented by many servers).

8 years, 2 months

Re: [TUHS] System Economics (was is Linux "officially branded UNIX")

by Arthur Krewat

Sorry, in this context, SunOS means 4.1.4 - not Solaris SVR4 I run Solaris myself, and love it. On 3/15/2017 11:48 AM, Joerg Schilling wrote: > Arthur Krewat <krewat(a)kilonet.net> wrote: > >> You make a valid point, and re-reading what I wrote, I find that I >> pushed the example too far :) >> >> The subject was originally that SunOS at it's end-of-life did not have >> the features that Linux now does, and comparing their development >> lengths brings up an interesting question. What would SunOS have become > So you believe that SunOS-5.11 is no longer alive? > > There is an Oracle based version and a OpenSolarisd based version developed by > the community. > > Jörg >

8 years, 2 months

Does this mean Linux is now "officially branded UNIX"?

by Josh Good

Hello all. I was perusing the list of officially branded UNIX systems, according to the "UNIX 03" specification and tests done by the Open Group, and I found there listed something called "Huawei EulerOS 2.0". https://www.opengroup.org/openbrand/register/xy.htm Intriguing, ain't it? So I went to Wikipedia, to see what it has to say about such a beast. https://en.wikipedia.org/wiki/Single_UNIX_Specification#EulerOS And I quote: "EulerOS 2.0 for the x86-64 architecture were certified as UNIX 03 compliant. The UNIX 03 conformance statement shows that the standard C compiler is from the GNU Compiler Collection (gcc), and that the system is a Linux distribution of the Red Hat family." So, Linux (some variety of it, very closely resembling Red Hat) is now a "officially branded" UNIX. I think Mr. Stallman can now say: mission accomplished. GNU *is* now UNIX. (Linux the kernel might not be a FSF project, but it certainly is under the GNU General Public License.) -- Josh Good

8 years, 2 months

Howdy Folks, and Internet Hall of Fame

by John S Quarterman

How are y'all? And greetings from the piney woods of south Georgia. If anybody wants to help get an Internet innovator into the Internet Hall of Fame, please drop me a note at jsqmobile(a)gmail.com. No rush; deadline is tomorrow. He's not a Unix person, but you'll recognize him. Hint: early ISP. -jsq

8 years, 2 months

Re: [TUHS] System Economics (was is Linux "officially branded UNIX")

by Clem Cole

On Tue, Mar 14, 2017 at 3:48 PM, Arthur Krewat <krewat(a)kilonet.net> wrote: > So what I'm hearing is Linux's timeline, which includes things that were > not developed just for Linux, extends further out than SunOS does. > Mumble... the problem of course is the under those rules, SunOS goes back to research which goes back to V0.... > > > ... > All I'm saying is comparing Linux's timeline to something like SunOS has > to include everything that went into both because they both relied on > precursors. > Except for any possible legal reasons....why differentiate ? Looks like a Duck, Quacks Like Duck or from a Turing Test.... I'm mostly can not tell the difference. > > Side note: I'm a bit of a bitch when it comes to Linux - which doesn't > mean I don't think Linux is "UNIX" - it just means I think it's the > Coherent of today's UNIX ;) > I guess it doesn't matter to me that much. Some of the changes are gratuitous and annoying, which brings out my inner curmudgeon as its make its tough to type to sometimes. But the fact is, UNIX, Linux, Macos are pretty much the same thing - much more so than winders. They are way more similar than different and I can be productive with all three. To me its like ethnicity in people. It says a little about some of how you might look at something, what some of you shared positions/starting points are, but we are way more alike than different and I would rather learn from the differences than fight them or try to inflict my wishes. We are better with diversity. Clem

8 years, 2 months

Re: [TUHS] System Economics (was is Linux "officially branded UNIX")

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > rms had access to Masscomp b= ox we gave him fairly early on. > ... > I'm sure the MC-500 was not the first 68000 he had access. I think he > was using HW in Steve Ward's lab that the Trix guys were developing > with TI and he might have had access to an Apollo system. > ... > Noel do you remember how that went down? Sorry, no. From the end of '82 to early '84 I was out of the US, waiting for my permanent residency to come through, so I missed a chunk of events in that time period. Maybe one of the DSSR/RTS (Steve Ward, or someone) could clarify what access RMS had to their 68K machines? Noel

8 years, 2 months

X, Suntools, and the like

by Ron Natalie

Nice thing about X was that it would talk to remote displays. I still remember sitting in the Pentagon demonstrating that the Suntools screen lock wasn't particularly secure. Then there was NeWS. This was Gosling's first attempt at a deployable language. However PostScript (even with Owen Densmore's class extensions), while a reasonable intermediary language is really sucky to actually develop. Java was a bit more refined. Of course, lots of things either implement X under the native window system or backdoor X with local extensions. We got around doing high frame rate image work on X via the SharedMemoryExtension and the ability to flip buffers on the retrace interval (both extensions, but commonly implemented by many servers).

8 years, 2 months

Re: [TUHS] attachments: MIME and uuencode

by Doug McIlroy

Allowing more or less arbitrary attachments was a real convenience. But allowing such stuff to serve as the message proper was dubious at best. Not only did it require recipients to obtain special software to read some messages; it also posed a security threat. I still use mailx precisely because it will only display plain text. With active text such as HTML, it is all too easy to mistakenly brush over a phishing link. Outfits like Constant Contact do their nonprofit clients a disservice by sending stuff that I won't even peek at. And it's an annoying chore when companies I actually want to deal with send receipts and the like in (godawful) HTML only. Doug

8 years, 2 months

Re: [TUHS] attachments: MIME and uuencode (fwd)

by Dave Horsfall

I think this was supposed to go public... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ---------- Forwarded message ---------- Date: Mon, 13 Mar 2017 11:39:45 +0000 From: Steve Simon <steve(a)quintile.net> To: dave(a)horsfall.org Subject: Re: [TUHS] attachments: MIME and uuencode I still actively fight office. I wrote docx2troff and xlsx2txt. The former can extract txt or troff source from modern (DOCX / OPC) document as can the latter though, by their nature excel tables don't map well to tbl(1). These are written for plan9 and so the libraries are a bit different, but they could be ported to unix without too much pain. Shout if anyone is interested. -Steve

8 years, 2 months

Quick question: earliest Unix system with mail, uucp and bangpaths?

by Warren Toomey

As I go to bed, I wonder. Which was the earliest system that used uucp to send mail through multiple systems to a remote user? I see V7 has uucp/sdmail.c, but the comment says: This is only implemented for local system mail at this time. Ditto 32V and 3BSD. 4BSD has delivermail. Its uucp has a README which says: The ``mail'' command has been modified, so that it may only be used to send mail, when it is invoked under a name beginning with 'r'. 3BSD has the same uucp. http://minnie.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/cmd/uucp/README Ah, but 32V's mail.c checks for 'r': http://minnie.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/cmd/mail.c and so does V7: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mail.c So I guess I've just answered my question. It also looks like delivermail from 4.1BSD could compile on V7, so it might be fun to try and bring a V7 system up on uucp+mail. But will it (delivermail?) do bang paths?! Cheers, Warren

8 years, 2 months

attachments: MIME and uuencode

by Mary Ann Horton

I just heard from a historian named Piotr Klaban with an interesting historical sidelight. Apparently today 3/11/17 is being publicized as the 25th anniversary of the email attachment, citing Nat Borenstein's MIME. Piotr points out that uuencode predates MIME, and he's right. I checked and, while I don't have any email archives from that time frame at Berkeley, I was able to find the 4BSD archive on minnie that dates the uuencode.1c man page at 6/1/80. We didn't call them attachments back then, just sending binary files by email. (Prior to then it was common to just include the text of the file raw in the email, which only worked for ASCII files.) It was a few years later when cc:Mail and Microsoft Mail started calling uuencoded files embedded in email "attachments". When MIME came out in 1992 I became a champion of SMTP/MIME as a standard - it was a big improvement. But uuencod predated MIME by 12 years. Mary Ann

8 years, 2 months

Re: [TUHS] attachments: MIME and uuencode

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > Allowing more or less arbitrary attachments was a real convenience. But > allowing such stuff to serve as the message proper was dubious at > best. Sorry, I'm not sure I'm completely clear what you mean there? Do you mean 'non-ASCII-text objects were processed by the mail system without being told to do so explicitly, by the user'? That, combined with the below, is indeed a problem. > it also posed a security threat. The problem isn't really so much the ability to have attachments, as that people defined attachment types with open-ended capabilities, up to and including what I call 'active content' - i.e. content which includes code which is to be run. (Yes, yes, I know - even without that, it's possible to feed 'dumb' applications bad data, and do an intrusion; I seem to recall there was one of those with JPEG's, so even plain images were not perfectly safe. And someone just provided an example of an with plain ASCII. But those holes are much harder to find/use, whereas active content is a security hole the size of a trans-Atlantic liner.) Without an _incredibly_ secure OS (something on the order of late-stage Multics, when the security had been beefed up even over the original design [the jargon to search for is 'AIM', if you're interested], or better), bringing in 'active content' from _outside_ the system, and running it, is daylight madness - it's an invitation to disaster. This is true no matter _how_ such content comes in: via HTTP, with a Web browser; via SMTP, with e-mail, whatever. Dave Moon coined a phrase, based on an old anti-drug movie: 'TECO madness: A moment of convenience, a lifetime of regret.' These active contents all, to me, fall into that category. They _seem_ like a good idea, and provide interesting capabilities - until some cracker uses one to wipe your hard drive. > With active text such as HTML, it is all too easy to mistakenly brush > over a phishing link. HTML email is another of my pet peeves/hot buttons - it's just another vector for active conent. So, for the 'convenience' of being able to send email in multiple fonts ('eye candy', I derisively call it), we get to let malefactors send in viruses that can wipe a hard drive. To me, this kind of thing is professional malpractice, on a par with building cars that catch on fire, or buildings that collapse. People need to suffer incredibly severe penalties for propogating this kind of nonsense; maybe then software engineers will stop valuing convenience over regret. Noel

8 years, 2 months

Re: [TUHS] Help request: uucp, mail on 4.2BSD

by Clem Cole

On Tue, Mar 7, 2017 at 10:23 AM, Dave Horsfall <dave(a)horsfall.org> wrote: > It's been ages since I delved into UUCP; first was the > > "original", then HoneyDanBer. > Actually this is a great question for this list .. how many implementations were created? 1.) The original 1978 version that shipped with V7 and 32/V (BSD 4.1 and 4.2) 2,) PC-UUCP for DOS came next -- I never knew how much was ripped off from the original, because at the time, the Chesson's G protocol was not well specified. The authors claimed to have reverse engineered it - I will say it worked. 3.) Honey-Dan-Ber rewrite - most popular for a long time 4.) Taylor UUCP first real clone that I know of that I do think was done with out looking at other's source. G protocol had been publicly documented by then and the Trailblazer in fact was shipping with the protocol imbedded in it. Any others that folks know about and how well were they used? Did things like Coherent have a UUCP? Linux and FreeBSD were able to use to Taylor UUCP because it became available by then. Whitesmith's Idris lacked anything like UUCP IIRC (but was based on V6). Same with Thoth originally at Waterloo, but by the time they shipped it as the QNX product it was V7 compliant but I do not remember a UUCP being included in it. Minux lacked a UUCP as I recall, but I'm hazy on that has Andy's crew wrote a lot of the user space. Coherent was a "full" V7 clone and include things like the dev tools including yacc/lex and was released much, much before the Taylor version came out -- so what do they use for uucp if at all? Does anyone remember any other implementations? Clem

8 years, 2 months

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

by jnc＠mercury.lcs.mit.edu

On 10 March 2017 at 03:04, Erik E. Fair <fair-tuhs(a)netbsd.org> wrote: > See https://en.wikipedia.org/wiki/Multi-Environment_Real-Time I'd love to get ahold of a copy of PDP-11 MERT (which surely holds no significant trade secrets by now) to play with, since it seems like a very historic, and possibly influential (given what was published about it in the BSTJ, and elsewhere), but so far I have not been able to find it. I had a lead to one of the authors (who's now in a very different line of work), but so far I have yet to find the time to try and run that one down, to see if anything came of it. If anyone knows of such, please let me know! Noel

8 years, 2 months

Re: [TUHS] attachments: MIME and uuencode

by Andy Valencia

> Back in the day plain ASCII wasn't really secure, either. No need to use the past tense. I had a need to assess how much damage one could do if allowed to feed arbitrary text into xterm. I came away sobered. Do not--ever--use a mail agent which will plumb unfiltered text through to an xterm. nmh, for one: http://savannah.nongnu.org/bugs/?36056 Andy

8 years, 2 months

Was 5ESS built on UNIX?

by Nemo

I have looked at the papers published in the AT&T Technical J. in 1985 and found no mention of UNIX. N.

8 years, 2 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