Exactly -- just re-read Will's question. 2 spaces after punctuation is a
fix-size typeface solution to the 1.5 typographer layout.
I was referring to why typed papers were traditionally double spaced
between the lines.
On Fri, Nov 6, 2020 at 11:02 AM Chris Torek <torek(a)elf.torek.net> wrote:
> >I use single spaces between sentences, but my ancestors
> >used 2... who knows why? :).
>
> Typewriters.
>
> In typesetting, especially when doing right-margin justification,
> we have "stretchy spaces" between words. The space after end-of-
> sentence punctuation marks is supposed to be about 50% larger than
> the width of the between-words spaces, and if the word spaces get
> stretched, so should the end-of-sentence space. Note that this is
> all in the variable-pitch font world.
>
> Since typewriters are fixed-pitch, the way to emulate the
> 1.5-space-wide gap is to expand it to 2.
>
> Chris
>
[ Moving to COFF (if your MUA respects "Reply-To:") ]
On Fri, 6 Nov 2020, Larry McVoy wrote:
> But I'm pretty old school, I write in C, I debug a lot with printf and
> asserts, I'm kind of a dinosaur.
You've never experienced the joy of having your code suddenly working when
inserting printf() statements? Oh dear; time to break out GDB...
-- Dave
[Following clemc's example and moving to COFF]
On Friday, 6 November 2020 at 7:19:24 -0800, Chris Torek wrote:
>> I'm lazy.
>
> I am too, but I still use a big screen: I just fit a lot of smaller
> windows in it.
Agreed. There's a second issue here: for reading text, 70 to 80 n
widths is optimal. For reading computer output, it should be much
wider. I've compromised by fitting two 120 character wide xterms on
my monitors, left and right. I still display only 70-80 characters
for text.
> I'd like to have a literal wall screen, especially if I'm in an
> interior, windowless (as in physical glass windows) room, so that
> part of the wall could be a "window" showing a view "outside" (real
> time, or the ocean, or whatever) and other parts of the wall could
> be the text I'm working on/with, etc.
The issue there is perspective. I could do that (modulo cost) in my
office, but I'd have a horizontal angle of about 90°, and that's
uncomfortable.
> (But I'll make do with these 27" 4k displays. :-) )
Yes, that's about the widest I find comfortable, and it took me a
while to adapt.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
I'd be curious to hear from the folks a few years older than I (I started
in the later 60s with the GE-635), but my own experiences of having lived
through some of it, I personally think it was more to do with all of the
systems of the time switching from cards to the Model 28 and later the 33
then Unix or AT&T. Unix was just one of the systems that we used at the
time of the transition from cards. But the other timesharing systems of
those days began to transition to the tty's requirements.
On Fri, Nov 6, 2020 at 12:27 PM Stephen Clark <sclark46(a)earthlink.net>
wrote:
> On 11/6/20 12:13 PM, Adam Thornton wrote:
> > I’m going to chime in on pro-80-columns here, because with the text a
> comfortable size to read (although this is getting less true as my eyes
> age), I can read an entire 80-column line without having to sweep my eyes
> back and forth.
> >
> > I can’t, and never could, do that at 132.
> >
> > As a consequence, I read much, much faster with 80-column-ish text
> blocks.
> >
> > I also think there is something to the “UNIX is verbal” and “UNIX nerds
> tend to be polyglots often with a surprising amount of liberal arts
> background of one kind or another,” argument. That may, however, merely be
> confirmation bias.
> >
> > Adam
> May have had to do with the first terminal commonly used with UNIX.
>
> The Model 33 printed on 8.5-inch (220 mm) wide paper, supplied on
> continuous
> 5-inch (130 mm) diameter rolls and fed via friction (instead of, e.g.,
> tractor
> feed). It printed at a fixed 10 characters per inch, and supported
> 74-character
> lines,[13] although 72 characters is often commonly stated.
>
>
Hey all, I was browsing my small corner of the fediverse, when I came
across a post that said:
> @pastelpunkbandit@hellsite.site
> i wonder if people from the 70s would make fun of us for still using vi
It got me wondering -- what /was/ the view of the future of computing,
by people working deeply with the systems of the time? I know that
people worked on what they felt was the future -- and returned bearing
the gifts of Smalltalk. Prolog, etc ad nausem. Surely there was the
expectation that things would be improved, but what form did those
expectations take?
Incidentally, if there /were/ jokes about people using $program in the
future -- I think that would be of interest too :)
Thanks!
--
"Too enough never much is!"
Just watched this the other day.
The original story is from 1958 written by Isaac Asimov, the short
movie was made in 1978
All the Troubles of the World
https://youtu.be/svIXTDeZzDg
Nothing to do with UNIX, but a reminder that occasionally long thought
lost manuals still pop-up.
"Researchers will be able to gain a deeper understanding of what’s
considered the world’s oldest surviving (digital) computer after its
long-lost user manual was unearthed. The Z4, which was built in 1945,
runs on tape, takes up most of a room and needs several people to
operate it. The machine now takes residence at the Deutsches Museum in
Munich, but it hasn’t been used in quite some time."
https://www.engadget.com/oldest-computer-manual-zuse-z4-161214346.html
I finally got around to tidying up a little shell tool I wrote that turns a network interface you specify into a bridge, and then creates some tap devices with owning user and group you specify and attaches them to that bridge.
This gets around having to run emulated older systems under sudo if you want networking to work.
It’s mostly intended for the PiDP-11/simh, but it also works fine with klh10 and TOPS-20.
Maybe it will be useful to someone else.
https://github.com/athornton/brnet <https://github.com/athornton/brnet>
Adam
Moving to COFF
On Mon, Sep 21, 2020 at 7:56 PM John Cowan <cowan(a)ccil.org> wrote:
> Rereading that made me wonder: if someone retargeted an old compiler (pcc,
> say) to produce i386 code,
>
I thought SVR3's was PCC (maybe PCC2). But I thought I remember that is
had a i386 code. Certainly by SVR4 time.
IIRC, the time frame of SVR3's front end would have been original ANSI
(i.e. White Book V2).
> how much faster would it run than a VAX?
>
In the time frame of the SVR3 (mid/late 80s), the Intel processors was
faster than the 1MIP (780 circa 1977) in raw computes. The issue was
always I/O. Most PC did not have the same amount of I/O HW that much
earlier Vaxen.
> I see that there is a pcc derivative at <http://pcc.ludd.ltu.se/>, but
> supposedly it has been heavily rewritten for C99 compliance and other
> things.
>
And my point is that by the time of C99, it was a different language than
the early 1970s when Dennis created fit or the original PDP-11/20 he and
Ken used for the first UNIX kernel and tools implementations.
"When I read commentary about suggestions for where C should go, I often
think back and give thanks that it wasn't developed under the advice of a
worldwide crowd." dmr
In the early 1970s, when computing capabilities were tiny, tiny, tiny
compared to even a cell phone today, and those resources were typically
time-shared across multiple users, queueing network models became a
primary tool to analyze and improve system performance. Queueing models
had been studied for years before regarding communication systems and
other systems, but networks of queues seemed especially apropos for
understanding time-sharing systems.
Computer Systems Performance Modeling, which Professor K.M. Chandy and I
wrote in 1978-9, previously published by Pearson Education, Inc. is now
out of print. We are making PDF copies of lightly edited versions
available under a Creative Commons license.
https://notes.technologists.com/notes/2020/08/25/computer-systems-performan…
Ed MacNair and I published two books based on The Research Queueing
Package, RESQ: Simulation of Computer Communication Systems and Elements
of Practical Performance Modeling. Those books, previously published by
Pearson Education, Inc. are now out of print. We are making PDF copies
of lightly edited versions available under a Creative Commons license.
Though we have written two prior articles about RESQ history, those did
not cover subsequent development, so another recap seems appropriate
now. https://notes.technologists.com/notes/2020/08/25/remembering-resq/
(Mainstream Videoconferencing: A Developer’s Guide to Distance
Multimedia, which Joe Duran and I wrote from 1994-96, became available
again in 2008:
https://notes.technologists.com/notes/2008/02/14/mainstream-videoconferenci…)
--
voice: +1.512.784.7526 e-mail: sauer(a)technologists.com
fax: +1.512.346.5240 web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer
--
voice: +1.512.784.7526 e-mail: sauer(a)technologists.com
fax: +1.512.346.5240 Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer