TUHS

tuhs@tuhs.org

31 participants
6541 discussions

by jnc＠mercury.lcs.mit.edu

> From: Jon Steinhart > Probably the best person to ask is Heinz Lycklama. I checked my email log for my previous MERT enquiries, and that's the exact same advice I got from Brian Kernighan when I asked him (a couple of years back) if he had any suggestions for tracking it down. I guess I need to finally get a 'round tuit'... unless there's someone else here who knows him well, and wants to give it a go. Noel

7 years, 7 months

Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

by jnc＠mercury.lcs.mit.edu

> From: George Michaelson > I don't think this list is the right place to conduct that particular > debate. Not disagreeing; my message was a very short gloss on a very complicated situation, and I wasn't trying to push any particular position, just pointing out that work (whether the right direction, or not, I didn't opine) had been done. > Its true RSVP didn't get traction, but the economics which underpin it > are pretty bad, for the current Internet model of settlement Yes, but would _any_ resource reservation system, even one that _was_ 'perfect', have caught on? Because: > it would not surprise me if there is ... more dropped packets than > strictly speaking the glass expects. This is related to something I didn't mention; if there is a lot more bandwidth (in the loose sense, not the exact original meaning) than demand, then resource reservation mechanisms buy you nothing, and are a lot of complexity. While there were bandwidth shortages in the 90s, later on they pretty much went away. So I think the perception (truth?) that there was a lot of headroom (and thus no need for resource reservation, to do applications like voice) played a really big role in the lack of interest (or so people argued at the time, in saying IntServ wasn't needed). Noel

7 years, 7 months

Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

by jnc＠mercury.lcs.mit.edu

> From: Steve Johnson > Recently I've been attempting to Skype on a group call with 5 people in > Europe. I would LOVE to have a guaranteed bandwidth for my call. The Internet engineering community did quite a bit of work on resource guarantees. (Google 'IntServ' and 'RSVP' - the latter is the control protocol.) Unfortunately, there was never much interest in it. People started doing voice with just plain 'best effort' service, and I guess it worked 'well enough' that nobody was interested in IntServ/RSVP. Noel

7 years, 7 months

Re: [TUHS] net neutrality

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > Did you read the reddit link I sent? No, because I despise Reddit. > Because if you had you wouldn't be asking this. Now that I look at it, most of what I lists is ISP's _blocking_ sites. I _already_ said I wanted to see a rule preventing that. > unregulated businesses will do whatever they can to make more money with > absolutely no concern about the consequences Sure - like content providers. Noel

7 years, 7 months

Re: [TUHS] net neutrality

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Just like the electric company, needs to deliver electrons at some > rate/force. If you want electrons at more than X bazillion per second, you'll have to pay to have a higher-amperage service. And if you use more electrons, you pay more. What's your problem with ISPs doing the same? Noel

7 years, 7 months

Re: [TUHS] net neutrality

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > look at the history, various ISPs like Verizon, Comcast, etc, have done > stuff like block bittorrent, skype, etc Bittorrent is a complex situation, some ISPs were ordered by a court to block it. As to Skype, I agree ISPs shouldn't block sites - but if you read my message, I already said that. > The problem is I paid for the bits. Bits is bits. I paid for a rate, > that's what they got paid for, why should they get to charge a second > time for the same bits? That's exactly what they want to do. Fine, you pay your money, you get X Mbits/second. If you (or the site you're getting bits from) wants _more_ than X Mbits/second, charging you - or them, which is I gather mostly what ISPs want to do - for that privilege is a problem... how? Noel

7 years, 7 months

Re: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!

by Rudi Blom

Anyone on TUHS who made the list? Greeting from your Dutch uncle rubl For all the sound advise you don't want to hear. Date: Sun, 10 Dec 2017 13:23:13 +1100 (EST) From: Dave Horsfall <dave(a)horsfall.org> To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> Subject: Re: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! Message-ID: <alpine.BSF.2.21.1712101314210.35694(a)aneurin.horsfall.org> Content-Type: text/plain; charset=US-ASCII; format=flowed On Sat, 9 Dec 2017, Ralph Corderoy wrote: >> Yeah, but all the same, two famous people in the same industry would >> surely lengthen the odds somewhat... > > Yeah, you're pulling my leg. :-) > https://en.wikipedia.org/wiki/List_of_computer_scientists OK, it was worth a try :-) (I'm a born stirrer, and I blame my parents for that.) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

Grace Hopper

by Dave Horsfall

(At the risk of being flamed because it's not strictly Unix...) We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing Grace", she was a remarkable woman, both in computers and the Navy. She coined the term "debugging" when she extracted a moth from a set of relay contacts from a computer (the Harvard Mk I) and wrote "computer debugged" in the log, taping the deceased Lepidoptera in there as well. She was convinced that computers could be programmed in an English-like language and developed Flow-Matic, which in turn became, err, COBOL... She was posthumously awarded the Presidential Medal of Freedom in 2016 by Barack Obama. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

Happy birthday, Grace Hopper and J.F.Ossana!

by Dave Horsfall

As promised :-) Augusta Ada King-Noel, Countess of Lovelace (and daughter of Lord Byron), was born on this day in 1815; arguably the world's first computer programmer and a highly independent woman, she saw the potential in Charles Babbage's new-fangled invention. J.F.Ossanna was given unto us on this day in 1928; a prolific programmer, he not only had a hand in developing Unix but also gave us the ROFF series. Who'ld've thought that two computer greats would share the same birthday? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

Card reader on Unix

by Dave Horsfall

Something's been bothering me for a while... I've just remembered that our 11/40 with more peripherals than you could shake a stick at -- it had just about everything except a DECtape -- also had, so help me, a card reader! As I dimly recall, 'twas a slow CDC (?) model; we didn't have it for long, either because it was on loan or because it was so unreliable, I simply don't remember. Anyway, our driver handled it in two modes: you either got a raw image of each card (likely via DMA instead of column by column, but I could be wrong) i.e. 80 words with each column of 12 holes fitting nicely into a 16-bit word, or there was a half-arsed attempt at converting EBCDIC to ASCII, with trailing blanks replaced by a newline (i.e. think of it as a line printer in reverse). Or was it converting from whatever KRONOS used to ASCII? Now, what I *distinctly* remember was writing two scripts: "/etc/cdc" and "/etc/dec" which switched between the two modes, quite likely by patching the in-core kernel! I'd give a testicle to have that "CSU tape" back again (and no doubt so would Warren), but can anyone else remember this (or dare to call me a liar; yes, I'm still touchy about that)? The snag is, towards the end of the CSU before they were about to be engulfed by the admin suits and forced to support payroll programs in COBOL etc, I was the only senior Unix bod left, so it's unlikely that the CSU source code followed someone else home... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

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