I’ve only recently stumbled across this paper.
It gives the answer to one question I’ve had:
Why did Linux become more popular than everything that came before it?
There were surprises.
The “Dot Boom” then “Dot Bust” along with Y2K.
Microsoft developed an architecture, Active Directory, designed to support Enterprise scale deployments.
Everything Good in A.D. is Old (LDAP, Kerberos, DNS)
everything badly done is New (replicated DB’s & ???).
Other surprises is the rise of “Internet Scale” datacentres, Social Media and Smartphones & Tablets.
All of which are dominated by Linux or Unix derived solutions.
And Virtual Machines on Intel.
IA-64 was in the far future :(
And ARM CPU’s made a big comeback.
==========
The Sourceware Operating System Proposal
9 November 1993
Revision: 1.8
<https://www.landley.net/history/mirror/unix/srcos.html>
==========
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
I remember being told back in the 1980s that vi would set the terminal
to "cooked mode" when vi was in "insert mode", so as to reduce expensive
context switching for each character typed. Only vi's "command mode"
would set the terminal to "raw mode" so as to provide immediate feedback
on each (command) character typed. This would be a clever system
performance optimization, and would also explain designing vi around
distinct insert and command modes.
However, I can't find such evidence even as far back as BSD 1. It seems
that in insert mode ESC was processed like any other character.
https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Develop…
Cooked mode was only entered when scrolling in order to receive interrupts.
https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Develop…
Also, for this scheme to work ESC would need to be mapped to an
interrupt key, so as to allow exiting the cooked mode through the
corresponding signal handler. Again, grepping for ESC, did not show me
any such code.
I also remember being told that this optimization was what allowed
twenty students to concurrently perform interactive editing on a VAX
11/780 (running 4.2BSD and then 4.3BSD), and that Emacs was not provided
to students because it was always operating in raw mode.
Was I misled? Was there perhaps a hacked version of vi that worked in
this way?
-Diomidis
> From: Diomidis Spinellis
> I remember being told back in the 1980s that vi would set the terminal
> to "cooked mode" when vi was in "insert mode", so as to reduce expensive
> context switching for each character typed.
> ...
> However, I can't find such evidence even as far back as BSD 1.
Maybe you're thinking of Multics Emacs, which had such a capability:
https://multicians.org/mepap.html
Noel
Hi all, I'll be attending the Usenix SREcon22 Asia/Pacific Conference
which is being held in Sydney, Australia on the 7-9 December. Is anybody
else attending? If so, it'd be nice to catch up with some other TUHSers :-)
https://www.usenix.org/conference/srecon22apac/program
Cheers, Warren
> Touch typists can spot an illtyperate programmer from a mile away.
> They don't even have to be in the same room.
I once thought of touch typing as employment of all fingers. Then I met
Fred Grampp. Using only four fingers, he typed as fast as most good
programmers. He knew where to hit, with a kinesthetic sense that had
progressed beyond dependence on "home keys". It was an athletic
performance, astonishing to watch.
Doug
Some of you may recall my friend Jim Joyce, who was an early proponent of Unix. IIRC, he taught the first course on Unix at UCB. Later on, he started and ran mail-order bookstores and seminars specializing in Unix-related topics, helped to found Unix Review, etc.
In any event, I have about a cubic foot of early Unix papers, saved from Jim's files after his death. It's quite likely that all of these papers are already available in collections, but I'd like to make sure that any exceptions don't get lost. Also, the printed copies may have some independent historical merit. Suggestions?
-r
Larry McVoy reports today:
>> People like Sunview's api enough that there was an Xview toolkit which
>> was Sunview ported to X10/X11.
The interface was nicely documented in three editions of a book (I
have no entry for the second edition):
@String{pub-ORA = "O'Reilly \& {Associates, Inc.}"}
@String{pub-ORA:adr = "981 Chestnut Street, Newton, MA 02164, USA"}
@Book{Heller:1990:XPM,
author = "Dan Heller",
title = "{XView} Programming Manual",
volume = "7",
publisher = pub-ORA,
address = pub-ORA:adr,
pages = "xxviii + 557",
year = "1990",
ISBN = "0-937175-38-2",
ISBN-13 = "978-0-937175-38-5",
LCCN = "QA76.76.W56 D44 v.7 1990",
bibdate = "Tue Dec 14 22:55:18 1993",
bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib",
acknowledgement = ack-nhfb,
}
@Book{Heller:1991:XPM,
author = "Dan Heller",
title = "{XView} Programming Manual",
volume = "7A",
publisher = pub-ORA,
address = pub-ORA:adr,
edition = "Third",
pages = "xxxvii + 729",
month = sep,
year = "1991",
ISBN = "0-937175-87-0",
ISBN-13 = "978-0-937175-87-3",
LCCN = "QA76.76.W56 H447 1990",
bibdate = "Mon Jan 3 17:55:53 1994",
bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib",
series = "The Definitive guides to the X Window System",
acknowledgement = ack-nhfb,
}
I have the first edition on a shelf near my campus office chair, and
continue to use olvwm as my window manager on multiple O/Ses, for 30+
years.
Every window manager designed since seems to fail to understand the
importance of user customizable, and pinnable, menus, which I exploit
to the hilt. The menu customization goes into a single, easy to edit,
text file, $HOME/.openwin-menu.
Compare that to the Gnome desktop, with hundreds of files, many of
them binary, stored in hidden directories under $HOME, and for which
any corruption breaks the window system, and prevents login (except
via a GUI console).
Also. olvwm does not litter a default desktop with icons for
applications that many of use would never use: just a simple blank
desktop, with menu popups bound to mouse buttons.
With olvwm, you can have any number of virtual desktops, not just the
2 or 4 offered by more modern window manaugers, and unlike some of
those, windows can be dragged between desktops.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
