One of the things that's always fascinated me about Unix is the community
aspect; in particular, I imagine that in the early days when machines were
multiplexed among many simultaneous users, I wonder whether there was a
greater sense of knowing what others were up to, working on, or generally
doing.
I think of the /etc/motd file as being a part of this. It is, in some very
real sense, a way to announce things to the entire user community.
So what are its origins? Where did it first appear? I haven't dug into
this, but I imagine it was at Berkeley. What was it used for early on at
individual sites?
- Dan C.
> From: Dave Horsfall
> he would've been the registraNT, no?
Symbolics was the registrant.
I may have spoken too soon, Postel/ISI might not have been the registrar when
".com" was set up, so maybe it was someone at SRI/NIC. (The memory is dim.) I
don't remember how "MIT.EDU" got registered - I'm not sure if I did it. It
was definitely Jon handing out addresses, not SRI - I do recall us going to
Jon to get 128.30 & 31.
Noel
> From: Michael Kjörling
> the DNS RFCs (initially 1034, 1035) were only published in 1987...
Ah, those were later versions; the originals were:
0882 Domain names: Concepts and facilities. P.V. Mockapetris. November
1983.
0883 Domain names: Implementation specification. P.V. Mockapetris.
November 1983.
Both were updated by RFC0973 before being replaced by 1034/1035.
You might also want to look at:
0881 Domain names plan and schedule. J. Postel. November 1983.
0897 Domain name system implementation schedule. J. Postel. February 1984.
0921 Domain name system implementation schedule - revised. J. Postel. October 1984.
Note that ".com" didn't exist in the early revs.
Noel
> From: Lars Brinkhoff
> Is this "Network Unix" available?
??? This was announced here not long ago:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC
It's called 'NOSC' because that's where it came from, but it has the Illinois
NCP code in it.
Noel
hi,
im looking for Unix/Unix-like/Linux friendly hardware(desks,laps,phones,etc) free of proprietary software or compatible with free software(OS,BIOS firmware,etc) something that is easy to replace stock or something that cames with free software preinstalled and that i can replace them if i want to.
i've seen some lists that contain vendors that are Unix/Linux friendly and also the hardware endorsed by FSF which seem to be Lenovo thinkpads,etc the thing is it seems most of hardware require external flashing to replace BIOS,etc and makes the task harder..
my question are,
what are the bests Unix/Unix-like/Linux friendly hardware manufacturers?
which hardware is the best to make a computer 100% free (free BIOS and OS) and that is optimized and behave better under Unix/Unix-like/Linux based OS's?
Thank you.
Â
--
PHACT Phreakers / Hackers / Anarchists / Cyberpunks / Technologists
Back when the dinosaurs were using card readers (and yes, I've used a card
reader on Unix; I think it was a desktop CDC model, and the driver would
handle two modes: strict 80-column i.e. one 12-bit column per 16-bit word
and you got 80 of 'em on a DMA channel, or ASCII NL-terminated after last
non-blank column, and no, I have no idea whether it handled EBCDIC or CDC
etc, but I digress as usual).
Where was I? Oh yes, sleeps...
Back when sleep(3) was sleep(2) (yes, Virginia, sleep() used to be a
system call, then it became alarm()/pause(), and now it seems to be
nanosleep(), and I'm wandering again), you never called sleep(1) because
its granularity was +/-1 second (and all the way up to +infinity,
actually, on a really busy machine), thus it could return right away, with
ensuing hilarity.
So, I'm curious:
When did sleep(2) become sleep(3)? Was it V7, or some BSD? Or Babbage
help me, SysVile?
When did the caveat about sleeping for 1 second become known? I don't
think that I ever saw it documented, but was one of those "lore" things
passed around at Unix conferences and the like.
And when did it start using nanosleep() instead of alarm()/pause()? I see
that my Penguin box has a bet both ways; it "may" use SIGALRM[a] (thus
"mixing calls to alarm(2) and sleep() is a bad idea" (well, I've used
both), and also refers to nanosleep().
[a]
Alpine's spell-checker suggested "SICKROOM" here; pretty close when
dealing with timed-out reads on a TTY connection[ii] :-)
[ii]
Have you tried this with Perl? You can't rely on EINTR[3], so you have to
use eval{} blocks instead, and it starts getting pretty fugly...
[3]
And here it suggested "ENTREE".
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
>Date: Wed, 7 Mar 2018 13:54:32 -0500
>From: Paul Winalski <paul.winalski(a)gmail.com>
>To: Clem Cole <clemc(a)ccc.com>
>Cc: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
>Subject: Re: [TUHS] Sleep()y musings
>Message-ID:
> <CABH=_VTO7sdgGypp3U7zQoWdJ3HsGUUjrk->6_Rf5VE5gyNGD7g(a)mail.gmail.com>
>Content-Type: text/plain; charset="UTF-8"
>
>...
>VAX also has a Time-of-Year Clock Register (colloquially called the
>TOY clock), a 32-bit unsigned value whose LSB represents a resolution
>of 10 milliseconds (0.01 second). All VAX models except the
>VAX-11/730 provided battery backup for the TOY clock so that it
>continued to operate even when the system was powered off. A VAX can
>thus be powered off for about 497 days and still remember the
>date/time.
Also in AlphaServers we still have this TOY, the clock and the battery that is.
>From a DS10 running Digital Unix 4.0G, /var/adm/messages file, I only
removed the BEL characters
Dec 12 03:01:27 br0011 vmunix: You must reset the system time manually
Dec 12 03:01:27 br0011 vmunix: Time of year (TOY) clock returned zero
as the current time
Dec 12 03:01:27 br0011 vmunix:
Dec 12 03:01:27 br0011 vmunix:
Dec 12 03:01:27 br0011 vmunix: WARNING: preposterous time in TOY clock
-- CHECK AND RESET THE DATE!!
Dec 12 03:01:27 br0011 vmunix:
Dec 12 03:01:27 br0011 vmunix: i2c: Server Management Hardware Present
Dec 12 03:01:27 br0011 vmunix: datalink: links=128, macs=6
Dec 12 03:01:27 br0011 vmunix: NOTE: dxb_configure: Configure values:
dxb, ffffffffffffff9d, ffffffff90bfbf80, ffffffff90bf9a20
Dec 12 03:01:27 br0011 vmunix: WARNING: dxb_configure:
configure_driver error = 22
Dec 12 03:01:28 br0011 vmunix: Node ID is 00-10-64-30-ae-38 (from device tu0)
Dec 12 03:01:28 br0011 vmunix: WARNING: Time of year (TOY) clock
battery is dead, time and NVR contents ignored
Dec 12 03:01:28 br0011 vmunix:
Dec 12 03:01:28 br0011 vmunix: You must reset the system time manually
Cheers,
uncle rubl
