TUHS

tuhs@tuhs.org

17 participants
6470 discussions

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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