[TUHS] unix "awesome list"

[TUHS] unix "awesome list"

[A. P. Garcia]

Hi,

There's a unix "awesome list". It mentions TUHS's wiki, as well as this quote:

"This is the Unix philosophy: Write programs that do one thing and do
it well. Write programs to work together. Write programs to handle
text streams, because that is a universal interface." - Douglas
McIlroy, former head of Bell Labs Computing Sciences Research Center

https://github.com/sirredbeard/Awesome-UNIX

[TUHS] unix "awesome list"

[Dave Horsfall]

On Mon, 7 May 2018, A. P. Garcia wrote:

> "This is the Unix philosophy: Write programs that do one thing and do it 
> well. Write programs to work together. Write programs to handle text 
> streams, because that is a universal interface." - Douglas McIlroy, 
> former head of Bell Labs Computing Sciences Research Center
>
> https://github.com/sirredbeard/Awesome-UNIX

Sadly, Penguin/OS appears to have forgotten this, as it becomes more like 
Windoze every day...

-- Dave

[TUHS] unix "awesome list"

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

Some would argue that it was well on its way to being forgotten by
BSD.  The problem with that statement is that the deployment of mice
and touchscreens meant that the base premise (universal interface) was
no longer true.  Fonts and markup completed the job.

When I first used Unix, I wrote several ed scripts every day, and
several shell scripts each week.  Glass terminals made ed scripts
obsolete without any similar abstraction being available for doing
similar text operations on several related files.
I still write shell scripts from time to time, but I always feel a
little guilty that I'm not writing a simple GUI that would be much
clearer and easier to use, but take an order of magnitude longer to
write...

Steve

----- Original Message -----
From: "Dave Horsfall" <dave@horsfall.org>
To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Cc:
Sent:Tue, 8 May 2018 07:10:55 +1000 (EST)
Subject:Re: [TUHS] unix "awesome list"

 On Mon, 7 May 2018, A. P. Garcia wrote:

 > "This is the Unix philosophy: Write programs that do one thing and
do it 
 > well. Write programs to work together. Write programs to handle
text 
 > streams, because that is a universal interface." - Douglas McIlroy,

 > former head of Bell Labs Computing Sciences Research Center
 >
 > https://github.com/sirredbeard/Awesome-UNIX

 Sadly, Penguin/OS appears to have forgotten this, as it becomes more
like 
 Windoze every day...

 -- Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180507/a55e4950/attachment.html>

[TUHS] unix "awesome list"

[Steve Nickolas]

On Tue, 8 May 2018, Dave Horsfall wrote:

> On Mon, 7 May 2018, A. P. Garcia wrote:
>
>> "This is the Unix philosophy: Write programs that do one thing and do it 
>> well. Write programs to work together. Write programs to handle text 
>> streams, because that is a universal interface." - Douglas McIlroy, former 
>> head of Bell Labs Computing Sciences Research Center
>> 
>> https://github.com/sirredbeard/Awesome-UNIX
>
> Sadly, Penguin/OS appears to have forgotten this, as it becomes more like 
> Windoze every day...
>
> -- Dave
>

I blame people like Lennart Poettering who seem to be hellbent on erasing 
Linux's origins...

-uso.

[TUHS] unix "awesome list"

[Andy Kosela]

On Monday, May 7, 2018, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:

> Hi,
>
> There's a unix "awesome list". It mentions TUHS's wiki, as well as this
> quote:
>
> "This is the Unix philosophy: Write programs that do one thing and do
> it well. Write programs to work together. Write programs to handle
> text streams, because that is a universal interface." - Douglas
> McIlroy, former head of Bell Labs Computing Sciences Research Center
>
> https://github.com/sirredbeard/Awesome-UNIX
>

IMHO this "list" is strangely not distinguishing enough between SYSV and
BSD.  It seems to put every UNIX into the magical AT&T umbrella.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180507/a7660712/attachment.html>

[TUHS] unix "awesome list"

[Mutiny]

>I blame people like Lennart Poettering who seem to be hellbent on erasing Linux's origins...I don't think so. Red Hat does a extremely good job moving *nix/linux to the 3rd millennia.-uso.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/ffb79674/attachment.html>

[TUHS] unix "awesome list"

[Theodore Y. Ts'o]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote:
> Some would argue that it was well on its way to being forgotten by
> BSD.  The problem with that statement is that the deployment of mice
> and touchscreens meant that the base premise (universal interface) was
> no longer true.  Fonts and markup completed the job.
> 
> When I first used Unix, I wrote several ed scripts every day, and
> several shell scripts each week.  Glass terminals made ed scripts
> obsolete without any similar abstraction being available for doing
> similar text operations on several related files.

While true, that's only part of the story.  There was also the issue
that what users wanted to *do* with computers got more complex.
Consider spreadsheets and relational databases --- how do they get
implemented in "the Unix way"?  There was rdb, but it was a bit of a
disaster from a performance perspective and only worked for toy
databases.  And this wasn't unique to Unix.  In the VMS world,
ALL-IN-1 offered group scheduling/calendaring and other "office
software" features.  You *could* implemnt a group scheduling system
using sed, awk, grep, cat, and pipelines --- but would you want to?
Is that the best way to go about doing things?

And on the hardware side, the advent of hot-pluggable hardware devices
and much more complex UI devices (sound, video cameras, etc.) that
need to be made accessible to the logged-in user sitting in front of a
particular console, put a lot more pressure on the simple login and
/dev model of historical Unix.

So sure, it's easy to criticize "PenguinOS" for departing from the
Unix ideal.  But what's the alternative?  Can the criticis design
something better that matches the needs and requirements of the users
(who don't like big question marks on dashboards as "user friendly"
error reporting) and the realities of modern hardware and modern user
interface?

And if so, would those critics care to implement it and contribute it
under a BSD-style license?  (Or some other Open Source License)?
After all competing with the user friendliness of GNOME should be that
hard --- and it's been getting easier over the years as GNOME cuts
feature after feature from their system.  :-)

					- Ted

[TUHS] unix "awesome list"

[Bakul Shah]

On Tue, 08 May 2018 08:24:29 -0400 "Theodore Y. Ts'o" <tytso at mit.edu> wrote:
Theodore Y. Ts'o writes:
> On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote:
> > Some would argue that it was well on its way to being forgotten by
> > BSD. The problem with that statement is that the deployment of mice
> > and touchscreens meant that the base premise (universal interface) was
> > no longer true. Fonts and markup completed the job.
> > 
> > When I first used Unix, I wrote several ed scripts every day, and
> > several shell scripts each week. Glass terminals made ed scripts
> > obsolete without any similar abstraction being available for doing
> > similar text operations on several related files.
> 
> While true, that's only part of the story.  There was also the issue
> that what users wanted to *do* with computers got more complex.
> Consider spreadsheets and relational databases --- how do they get
> implemented in "the Unix way"?  There was rdb, but it was a bit of a
> disaster from a performance perspective and only worked for toy
> databases.  And this wasn't unique to Unix.  In the VMS world,
> ALL-IN-1 offered group scheduling/calendaring and other "office
> software" features.  You *could* implemnt a group scheduling system
> using sed, awk, grep, cat, and pipelines --- but would you want to?
> Is that the best way to go about doing things?
> 
> And on the hardware side, the advent of hot-pluggable hardware devices
> and much more complex UI devices (sound, video cameras, etc.) that
> need to be made accessible to the logged-in user sitting in front of a
> particular console, put a lot more pressure on the simple login and
> /dev model of historical Unix.
> 
> So sure, it's easy to criticize "PenguinOS" for departing from the
> Unix ideal.  But what's the alternative?  Can the criticis design
> something better that matches the needs and requirements of the users
> (who don't like big question marks on dashboards as "user friendly"
> error reporting) and the realities of modern hardware and modern user
> interface?
> 
> And if so, would those critics care to implement it and contribute it
> under a BSD-style license?  (Or some other Open Source License)?
> After all competing with the user friendliness of GNOME should be that
> hard --- and it's been getting easier over the years as GNOME cuts
> feature after feature from their system.  :-)
> 
> 					- Ted

Great response! Agree with a lot of this (except GNOME!).

Shell was a good glue language in that it allowed easy
composition of programs that fit its model from simpler
programs. A similar model exists for services composed from
microservices but now the 'pipes' are often not unidirectional
or simple lines of text. And dynamic scaling is required. etc.
But we do not have a similar easy to use glue language.
Graphical interfaces get used but except in special fields
they are not compositional. Graphical languages remained
researchy. in other areas existing solutions are rejected as
being not efficient enough or hard to integrate in the unix
model. Example: capabilities. Unix file descriptors are in
fact capabilities but they are still file/dir/device or socket
descriptors, mainly confined to individual processes.
Experiments in pure capability based OSes havent gone far. In
FreeBSD we have capsicum but that has added complexity, not
removed it. And we are still writing concurrent programs using
mutexes. No practical progress in 40 years.

If you think about it, most all the new things added in last 3
decades haven't had the cohesion of design like the original
unix design. And yet, I think extending the unix model is quite
possible.

[TUHS] unix "awesome list"

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5521 bytes --]

I'll take a slight different road on this topic.  I think we are dealing
with the paradox of progress. I don't blame Linux's developers any more
than I blame BSDs or anyone else.   Really it was hardware progress/Moore's
law that changed the rules :-)

As much as I wax a bit for the simplicity of the Fifth, Sixth, and Seventh
Editions of my youth, the truth is I would not want to try to use them
today.   My needs are now different and I think the is true for most people
also which is why a modern UNIX implementation is different from the
original ideas or maybe I should say ideal.  That said, a lot of what I did
then, ands like Steve, I still do use and many of the 'classic solutions' I
find are better for me (*i.e. *troff *vs.* MS-Word)

Pike's '*cat -v harmfu*l' paper foretold where we would get.   On the
PDP-11 with a limited address, a programmer was constrained so you had to
keep things simple.   The programming model of small simple programs that
did one thing well, was easier to 'enforce.'   The ideas that formed UNIX
make sense, and yoiu could build an extremely power 'system' from simple
and small things.   At the time, that was almost heretical.    But once HW
dropped in price and the address space issues relaxed the size of a program
that could be written, people did.  The cast was out of the bag, and there
was no going back.    I'm not saying all of the new BSDism of the time were
right, but they certainly made many things easier/more approachable for
many users and many/most live in modern UNIX definition.

I think Ted makes an excellent point, that *BSD and Linux, by their nature
of being 'open' and 'available' pushed the code along and that needs to
continue to be the high order bit.  Open and freely available had a huge
positive effect, because many of these new feature (like X-Windows,
Networking) were 'useful' and the cost to add them was accessible -- so
people added them.   But .... slowly the system changed and the
*expectations* of the users with them.

I admit, I'm torn.   I do think Pike was right and many of the new
features/frameworks *et al* are pretty lame (useless IMHO) and the
simpler/cleaner methods of old, are being ignored. Dave Pressotto and I
were talking a week or so ago and Dave made the observation that he's not
sure he knows how write a modern program now with all these frameworks,
IDEs, *etc* and I completely agree.  But that is the old guy in me talking;
but I really do want to see progress and the new generation make its mark.
I'm sure they will do wonderful things.

Bakul's observation of little >>practical<< progress is an interesting
one.   In many ways I agree, in others I'm not so sure.  I think Ted knows
that my major gripe with some of the Linux (and Gnu style) community has
been a focus on reimplementing things that were already there instead of
using what could have been taken from somewhere else such as BSD, or
replacing subsystems just because they could without really adding anything
(*i.e.* the whole systemd argument).

But over all, as much as I respect and think Ken and Dennis did amazing
work at the time, I do tend to love when new ideas/things have been done
beyond the original ideas from Ken and Dennis.  For instance, just as BSD
can take credit (or blame) or sockets and making UNIX really a 'networked
OS', Sun really gave us multiple file systems with the VFS, but  I strongly
credit Linux for really making kernel modules a reality (yup Solaris had
them, as did a few other systems - but it was really Linux that made it
wide spread).   I wish Linux had taken the idea of a modular kernel a tad
farther, and picked up things like Locus vproc work, because I personally
think modularity under the covers is better than the containers mess we
have today (and I agree with Tannenbaum that uKernel's make more sense to
me in the long run - even if they do cost something in speed).

it's also why I liked Plan 9 and have high hopes that a new OS, maybe
written is something like Rust might finally appear.   But I don't want it
re-implement UNIX or Linux.   Grab from them the subsystems that you need
to duplication, but don't re-invent.


Warren - at the risk of being political -- I think the paradox we have it
larger than just UNIX, although it is simple.  We can wallow and say
everything is bad, it was simpler in 1959 -- which exactly what some folks
in my country seem to be doing in other areas.  I personally can say my
world was simple in those days and I certainly have fond memories [read
Bill Bryson's
https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378
which parrots many of my own memories of those times ], but UNIX, like the
world, has grown up and changed and is a lot more complicated.   I like
progress we have now.  I don't want the world the way it was any more than
I want run Fifth Edition on my Mac for day-2-day work.

Yes, I would like us to look at the good from the past and see if we can
have some of the good things again; but if it means giving up what gained
too, then we have gone backwards.  The problem is how to decide what was
good and what was bad?   What is real progress and what is just 'showing
off your money' to use a Forest Gump concept.

I suspect we will argue for a long time about what qualifies as progress
from the core idea of UNIX and what does not.

Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/00c6ae79/attachment.html>

[TUHS] unix "awesome list"

[Jon Steinhart]

Here's an excerpt from the book on which I'm working (thanks to Clem for
proofreading) that is my take on how things got to be the way that they
are today.  BTW, I was coming into work one evening when Ken was heading
out the door for his sabbatical.  I remember him just waltzing past the
security guard with an armload of mag tapes and thinking wow, there aren't
that many people who could get away with that.

Jon


A long time ago people made money selling computers.  Software was written
and given away in order to help sell computers.  There was a culture of
sharing and working together to improve software.  More and more people
wrote and shared software as computers became more accessible.

The Multics operating system was collaboratively developed in the 1960s
by Bell Telephone Laboratories, General Electric, and the Massachusetts
Institute of Technology.  Bell pulled out of the project, and some of
the people (most notably Ken Thompson and Dennis Ritchie) there who had
worked on it decided to make a more practical version that ran on the
smaller minicomputers produced by the Digital Equipment Corporation (DEC).
It was the first portable operating system which means that it could run on
more than one type of computer.  This innovative operating system, UNIX,
embodied a new minimalist and modular philosophy for software that we'll
discuss shortly.

Ken Thompson took a copy of UNIX with him in 1975 when he took a sabbatical
year to teach at the University of California, Berkeley.  This had a huge
effect that still reverberates today.  Students had access to a real
working system.  They could examine the code to see how things worked,
and they could make changes.  Not only that, but they were exposed to the
philosophy.  Berkeley produced its own version of UNIX, BSD for Berkeley
SPoftware Distribution.

Students added many new important features to the system.  The networking
code that is the foundation of the Internet was written for UNIX at Berkeley.
Berkeley graduates started companies such as Sun Microsystems that made
commercial UNIX-based systems.

Personal computers changed this.  All of a sudden the people writing
software weren't the people selling computers, so they needed to charge
for it.  But there was still an attitude of ``it's great that we make
a living doing this cool stuff''.  This changed dramatically when Bill
Gates came on the scene.  As is evident from numerous court depositions,
his focus was on making money.  If he had to do something cool to make money
he would, but his priorities were opposite those of others in the industry.
How did this change things?

Software development began to be driven more by politics, lawyers, and
underhanded behavior than engineers.  Much of this focused on suppressing
innovation that competed with existing products.  For example, Microsoft
started with MS-DOS, a program that they bought from its developer Tim
Paterson.  Microsoft let it languish as they were making plenty of money
from it.  A company called Digital Research came out with an improved
version called DR-DOS.  When Microsoft came out with Windows, the original
version of which ran on top of DOS, they included a hidden, encrypted piece
of code that checked to see if the system was running MS-DOS or DR-DOS, and
generated phony errors if it found DR-DOS.  This made DR-DOS unsuccessful in
the marketplace even though it was a arguably better product for the money.

It wasn't just Microsoft.  Apple also sued Digital Research for copying their
user interface in a product called GEM.  Digital Research would probably
have prevailed eventually, but would have gone bankrupt in the process
because Apple had much deeper pockets.  Somewhat absurd when you realize
that the Apple user interface was substantially copied from the Xerox Alto.

Unfortunately, this mindset continues today with threatened big players
resorting to the courts instead of innovating their way out of their
difficulties.  Examples abound such as SCO versus IBM, Oracle versus Google,
Apple versus Samsung, Samsung versus Apple, Intellectual Ventures shell
companies versus the world, etc.

Personal computers started becoming popular in the mid-1980s.  It wasn't
practical to run UNIX on them because the hardware lacked a memory management
unit although there was a variant called Xenix that did run on PCs.

Colleges starting using personal computers to teach computer science because
they were cheaper.  However, unlike the UNIX-era graduates from Berkeley,
students did not have the ability to look at the code of the system that
they were using.  And the system with which they became familiar was
considerably less advanced than UNIX.  As a result graduates from this
era were not generally of the same quality.

In part as a reaction to this, Richard Stallman started the GNU (Gnu's Not
Unix) project in 1983.  Among other things, the goal was to create a free,
open-source version of UNIX.  Stallman created the copyleft, a variant
of the copyright used by others to protect their software.  The copyleft
essentially said that others were free to use and modify the code as long
as they made their modifications available under the same terms.  In other
words, we'll share our code with you if you share yours with everyone else.
The GNU project did a great job of recreating the UNIX utilities such as cp.
But it was slow to create the operating system itself.

Linus Torvaldis began work on what is now known as the Linux operating
system in 1991 because there was no GNU operating system.  To a large degree
this work was made possible by the existence of the GNU tools such as the
C compiler.  Linux has become extremely popular.  It's used heavily in
data centers (the cloud), it's the underlying software in Android devices,
it's in many appliances.  This book was written on a Linux system.

Large companies were originally skeptical about using open source software.
Who would fix the bugs?  Somewhat ludicrous; if you've ever reported a
bug to Microsoft, Apple, or any other large company you know how much
attention it gets.  In 1989, John Gilmore, David Henkel-Wallace, and
Michael Tiemann founded Cygnus Support to provide commercial support for
open source software.  It's existence greatly increased the willingness
of companies to use open source software.

In many ways Linux and GNU have brought us a new golden era similar to the
Berkeley UNIX days.  It's not quite as shiny because some of the people from
the PC era are making changes without really understanding the philosophy.

[TUHS] unix "awesome list"

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7369 bytes --]

Well, as I look to the future I see the whole approach we have to
software running into a dead end.  In fact, I think software is
holding us back.   It wasn't always true.  In the old days,
software ideas (like floating point, index registers, caches, etc.)
proved their worth and were put into hardware to make them faster.  I
think around 1980 this stopped happening.  Instead, hardware gave us
20 years of Moore's law, with ever faster and cheaper processors. 
 The increase in performance pretty much hid the inefficiency that
the software bloat introduced.

Starting about 2000, this changed.  Hardware was no longer offering
increased speed.  But what it was offering was massive parallelism. 
The response was to cling to the one instruction at a time model,
introducing multicore and its attendant hardware complexity to try to
cling to the previous model of programming.   The hardware to make
this possible is expensive and does not scale.

My company, Wave Computing, has built a chip with 16,000 8-bit
processors on it.  And we have plans to build systems with up to a
quarter million processors.  We are breaking ground in new ways to
use hundreds of processors to solve problems very quickly.  It's a
new way of thinking, and it makes your brain hurt.  But is is what
the hardware is giving us, and there is at least another order of
magnitude ahead before this trend starts running out of steam.

And it's exciting...

Steve

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Bakul Shah" <bakul at bitblocks.com>
Cc:
"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:
Tue, 8 May 2018 10:53:16 -0400
Subject:
Re: [TUHS] unix "awesome list"

I'll take a slight different road on this topic.  I think we are
dealing with the paradox of progress.
 I don't blame Linux's developers any more than I blame BSDs or
anyone else.   Really it was hardware progress/Moore's law that
changed the rules :-)

As much as I wax a bit for the simplicity of the Fifth, Sixth, and
Seventh Editions of my youth, the truth is I would not want to try to
use them today.   My needs are now different and I think the is true
for most people also which is why a modern UNIX implementation is
different from the original ideas or maybe I should say ideal.  That
said, a lot of what I did then, ands like Steve, I still do use and
many of the 'classic solutions' I find are better for me (_i.e. _troff
_vs._ MS-Word)

Pike's '_cat -v harmfu_l' paper foretold where we would get.   On
the PDP-11 with a limited address, a programmer was constrained so you
had to keep things simple.   The programming model of small simple
programs that did one thing well, was easier to 'enforce.'   The
ideas that formed UNIX make sense, and yoiu could build an extremely
power 'system' from simple and small things.   At the time, that was
almost heretical.    But once HW dropped in price and the address
space issues relaxed the size of a program that could be written,
people did.  The cast was out of the bag, and there was no going
back.    I'm not saying all of the new BSDism of the time were
right, but they certainly made many things easier/more approachable
for many users and many/most live in modern UNIX definition.

I think Ted makes an excellent point, that *BSD and Linux, by their
nature of being 'open' and 'available' pushed the code along and that
needs to continue to be the high order bit.  Open and freely
available had a huge positive effect, because many of these new
feature (like X-Windows, Networking) were 'useful' and the cost to add
them was accessible -- so people added them.   But .... slowly the
system changed and the _expectations_ of the users with them.

I admit, I'm torn.   I do think Pike was right and many of the new
features/frameworks _et al_ are pretty lame (useless IMHO) and the
simpler/cleaner methods of old, are being ignored. Dave Pressotto and
I were talking a week or so ago and Dave made the observation that
he's not sure he knows how write a modern program now with all these
frameworks, IDEs, _etc_ and I completely agree.  But that is the old
guy in me talking; but I really do want to see progress and the new
generation make its mark.  I'm sure they will do wonderful things. 

Bakul's observation of little >>practical<< progress is an interesting
one.   In many ways I agree, in others I'm not so sure.  I think
Ted knows that my major gripe with some of the Linux (and Gnu style)
community has been a focus on reimplementing things that were already
there instead of using what could have been taken from somewhere else
such as BSD, or replacing subsystems just because they could without
really adding anything (_i.e._ the whole systemd argument).

But over all, as much as I respect and think Ken and Dennis did
amazing work at the time, I do tend to love when new ideas/things have
been done beyond the original ideas from Ken and Dennis.  For
instance, just as BSD can take credit (or blame) or sockets and making
UNIX really a 'networked OS', Sun really gave us multiple file systems
with the VFS, but  I strongly credit Linux for really making kernel
modules a reality (yup Solaris had them, as did a few other systems -
but it was really Linux that made it wide spread).   I wish Linux
had taken the idea of a modular kernel a tad farther, and picked up
things like Locus vproc work, because I personally think modularity
under the covers is better than the containers mess we have today (and
I agree with Tannenbaum that uKernel's make more sense to me in the
long run - even if they do cost something in speed).

it's also why I liked Plan 9 and have high hopes that a new OS, maybe
written is something like Rust might finally appear.   But I don't
want it re-implement UNIX or Linux.   Grab from them the subsystems
that you need to duplication, but don't re-invent.

Warren - at the risk of being political -- I think the paradox we have
it larger than just UNIX, although it is simple.  We can wallow and
say everything is bad, it was simpler in 1959 -- which exactly what
some folks in my country seem to be doing in other areas.  I
personally can say my world was simple in those days and I certainly
have fond memories [read Bill Bryson's
https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378
[1] which parrots many of my own memories of those times ], but UNIX,
like the world, has grown up and changed and is a lot more
complicated.   I like progress we have now.  I don't want the world
the way it was any more than I want run Fifth Edition on my Mac for
day-2-day work.

Yes, I would like us to look at the good from the past and see if we
can have some of the good things again; but if it means giving up what
gained too, then we have gone backwards.  The problem is how to
decide what was good and what was bad?   What is real progress and
what is just 'showing off your money' to use a Forest Gump concept.

I suspect we will argue for a long time about what qualifies as
progress from the core idea of UNIX and what does not.

Clem

ᐧ



Links:
------
[1]
https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/a6959a50/attachment.html>

[TUHS] unix "awesome list"

[Michael Parson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

On 2018-05-08 07:24, Theodore Y. Ts'o wrote:
> On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote:
>> Some would argue that it was well on its way to being forgotten by
>> BSD.  The problem with that statement is that the deployment of mice
>> and touchscreens meant that the base premise (universal interface) was
>> no longer true.  Fonts and markup completed the job.
>> 
>> When I first used Unix, I wrote several ed scripts every day, and
>> several shell scripts each week.  Glass terminals made ed scripts
>> obsolete without any similar abstraction being available for doing
>> similar text operations on several related files.
> 
> While true, that's only part of the story.  There was also the issue
> that what users wanted to *do* with computers got more complex.
> Consider spreadsheets and relational databases --- how do they get
> implemented in "the Unix way"?  There was rdb, but it was a bit of a
> disaster from a performance perspective and only worked for toy
> databases.  And this wasn't unique to Unix.  In the VMS world,
> ALL-IN-1 offered group scheduling/calendaring and other "office
> software" features.  You *could* implemnt a group scheduling system
> using sed, awk, grep, cat, and pipelines --- but would you want to?
> Is that the best way to go about doing things?
> 
> And on the hardware side, the advent of hot-pluggable hardware devices
> and much more complex UI devices (sound, video cameras, etc.) that
> need to be made accessible to the logged-in user sitting in front of a
> particular console, put a lot more pressure on the simple login and
> /dev model of historical Unix.
> 
> So sure, it's easy to criticize "PenguinOS" for departing from the
> Unix ideal.  But what's the alternative?  Can the criticis design
> something better that matches the needs and requirements of the users
> (who don't like big question marks on dashboards as "user friendly"
> error reporting) and the realities of modern hardware and modern user
> interface?
> 
> And if so, would those critics care to implement it and contribute it
> under a BSD-style license?  (Or some other Open Source License)?
> After all competing with the user friendliness of GNOME should be that
> hard --- and it's been getting easier over the years as GNOME cuts
> feature after feature from their system.  :-)
> 

For me, it's not really the proliferation of servers (rdbms, web 
servers, collaboration back-ends, etc), desktop apps (spreadsheets, word 
processors, etc), but more of the 'traditional' unix cli utils that have 
grown beyond the 'do one thing' mantra.

Going beyond 'cat -v considered harmful', things like ifconfig, route, 
and netstat being considered 'deprecated' and replaced with the 'ip' 
tool.  Same with syslog, cron, init, and who knows what else, being 
replaced with systemd and journald.  This doesn't even cover how vim has 
become way more than just a GNU re-implementation of vi.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

[TUHS] unix "awesome list"

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]

On Tue, May 8, 2018 at 11:31 AM, Steve Johnson <scj at yaccman.com> wrote:

> Well, as I look to the future I see the whole approach we have to software
> running into a dead end.  In fact, I think software is holding us back.
>
​You might be right here, but where we disagree I think is economics.​  The
problem is that we can not afford to replace SW.   As I like to point out,
Fortran still pays my salary -- why because all the data and codes that use
that data written since the late 1950s.

Its just worse in the commercial side.  Word and Lookout/Exchange sucks -
but people use them and they are not going away.  Think about the LISP
Machine or the CM1 - lots of people though they were 'better' for some
concept of goodness.  But they failed in the end.






>
> ​...​
>
> Starting about 2000, this changed.  Hardware was no longer offering
> increased speed.  But what it was offering was massive parallelism.  The
> response was to cling to the one instruction at a time model, introducing
> multicore and its attendant hardware complexity to try to cling to the
> previous model of programming.   The hardware to make this possible is
> expensive and does not scale.
>
​I agree but ... IMO its going to take a real Christensen disruption with a
new customer base.   I just don't see that happening any time soon.
 Without a new customer base to support the new technology, the economics
of the keeping the old running has and will continue to go forward.​




>
> And it's exciting...
>
​I agree and I'm a fan and cheering from the sidelines .... but I'm
skeptical of success because the economics don't play to success..​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/facfc5f5/attachment-0001.html>

[TUHS] unix "awesome list"

[Larry McVoy]

On Tue, May 08, 2018 at 11:31:37AM -0500, Michael Parson wrote:
> Going beyond 'cat -v considered harmful', things like ifconfig, route, and
> netstat being considered 'deprecated' and replaced with the 'ip' tool.  Same
> with syslog, cron, init, and who knows what else, being replaced with
> systemd and journald.  This doesn't even cover how vim has become way more
> than just a GNU re-implementation of vi.

I'm not thrilled with the systemd stuff either, I still don't see that it is
solving anything that wasn't solved.  But somebody must like it, it's a big
change.

vim, on the other hand, oh do I love me some vim.  It's pretty faithful to
the original vi but you get split windows, infinite undo, it remembers 
stuff from one invocation to the next, it's pretty sweet.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] unix "awesome list"

[Theodore Y. Ts'o]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3279 bytes --]

On Tue, May 08, 2018 at 08:31:43AM -0700, Steve Johnson wrote:
> Well, as I look to the future I see the whole approach we have to
> software running into a dead end.  In fact, I think software is
> holding us back.

What's holding us back is our human minds' ability to manage
complexity.

> Starting about 2000, this changed.  Hardware was no longer offering
> increased speed.  But what it was offering was massive parallelism. 
> The response was to cling to the one instruction at a time model,
> introducing multicore and its attendant hardware complexity to try to
> cling to the previous model of programming.   The hardware to make
> this possible is expensive and does not scale.
> 
> My company, Wave Computing, has built a chip with 16,000 8-bit
> processors on it.  And we have plans to build systems with up to a
> quarter million processors.  We are breaking ground in new ways to
> use hundreds of processors to solve problems very quickly.  It's a
> new way of thinking, and it makes your brain hurt.

And that's the problem.  If we can't program the new machines, whether
it's Sun's attempt at large number of weak cores with their Niagra
chips, or your company's vast number of 8-bit processors --- as the
old saying goes, without software, it's just a doorstop.

Moving the discussion back to Unix, the problem is that we don't have
a lot of solutions to the complexity wall.  The most common one seems
to be deny the existence, or the validity of the requiremnts.  (e.g.,
"Teach them all English; if 7-bit ASCII was good enough for K&R, it's
good enough for me." or "Text files are all you need; why do you need
new-fangled things like group calendaring or spreadsheets"?)

Or you can just build on top of pre-existing systems, but then you get
complaints about kludge towers and overly complex systems.

Or you can give up on generality, and build a bespoke system that only
addresses the problem you are paid to solve.  Which may or may not be
cheaper than using the more general solution and brute-forcing the
problem by throwing more hardware on it, on the theory that hardware
is cheaper than software engineering skills.

> ... In the old days, software ideas (like floating point, index
> registers, caches, etc.)  proved their worth and were put into
> hardware to make them faster.  I think around 1980 this stopped
> happening. 

This is not strictly true.  A counter-example would be Google's Tensor
Processing Units[1].  That's an example of custome hardware replacing
what had previously been doing in pure software, or using more general
hardware units (e.g., GPU's).  Another example would be AES and
SHA-256 acceleration being done in hardware in multiple CPU
architectures, and in the data path between the CPU and the eMMC flash
on some cell phones.

[1] https://techcrunch.com/2017/05/17/google-announces-second-generation-of-tensor-processing-unit-chips/

I think it is true we have hit the point of diminishing returns, in
that as software gets more complex, finding things which are commonly
used enough, and which have enough of a benefit that it is worth the
engineering effort and cost of moving that functionality into hardware
is much harder now compared to a few decades ago.

   	       	   	       	     	     - Ted

[TUHS] unix "awesome list"

[Michael Parson]

On Tue, 8 May 2018, Larry McVoy wrote:
> On Tue, May 08, 2018 at 11:31:37AM -0500, Michael Parson wrote:
>> Going beyond 'cat -v considered harmful', things like ifconfig,
>> route, and netstat being considered 'deprecated' and replaced with
>> the 'ip' tool.  Same with syslog, cron, init, and who knows what
>> else, being replaced with systemd and journald.  This doesn't even
>> cover how vim has become way more than just a GNU re-implementation
>> of vi.
>
> I'm not thrilled with the systemd stuff either, I still don't see that
> it is solving anything that wasn't solved.  But somebody must like it,
> it's a big change.

I'm not thrilled with it either, but it seems to be how things are
going, so, I've been forced to learn how to use it.

> vim, on the other hand, oh do I love me some vim.  It's pretty
> faithful to the original vi but you get split windows, infinite undo,
> it remembers stuff from one invocation to the next, it's pretty sweet.

I resisted it for a long time, installed nvi on my penguin boxes so I
could have something resembling the vi I was raised on, but I've come to
appreciate a few of its features.  It just took some time to reprogram
my fingers for some of the features.  I find 'vimdiff' extremely useful,
but it's not really 'the unix way'. :)

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

[TUHS] unix "awesome list"

[Theodore Y. Ts'o]

On Tue, May 08, 2018 at 11:31:37AM -0500, Michael Parson wrote:
> Going beyond 'cat -v considered harmful', things like ifconfig, route, and
> netstat being considered 'deprecated' and replaced with the 'ip' tool.

For better or worse, *networking* has gotten much more complicated.
So there are many more ways of specfying a routing rule than just a IP
subnet, a mask, and a weight.  After a while, trying to add new
functionality to old interface just simply gets too hard.

Again, what's the solution?  You can deny the legitimacy of the new
features, and the requirements that caused those new featuers to be
designed and implemented.  Or you can accept that there's going to be
a new interface that is designed to be more extensible, and the old
interfaces will be maintained for backwards compatibility --- but if
you want to do something fancy, you'll need to use the new interfaces.

I still often used ifconfig myself, truth be told.  But there are
times when I will use the new interfaces, because I need to use the
new features.

As far as the question of using a multiplexed command --- e.g., "ip
route" versus "route", "ip link" versus ifconfig, that's really more
of a sylistic change to me.  "ip route" is a command line tool.  The
fact that there is a space in it doesn't offend me.  In fact, that
someone has attempted to design some level of user interface
consistency between "ip route" and "ip link" and "ip tunnel" is
actually something I consider to be a feature, and the fact that there
is single command, "ip", makes discovery of all of the types of
network configuration that one might want to do much easier.

This style of interface --- also used with "git", "hg", and many
others, is arguably nicer in terms of avoiding polluting the command
line namespace than the old MH approach of appropriating separate
commands, "show", "reply", "next", "prev", "reply", etc.

		      	       	     	     - Ted

[TUHS] unix "awesome list"

[William Cheswick]

It is amazing how well pipes fit into this model, up to a point.  I once wrote a program
to generate and collate hundreds of thousands of images.  I used the  sed/grep/awk model,
with all the ease of attendant text I/O processing.

I was surprised one day to find it running twice as fast as usual.  They had doubled the number of
CPUs in the machine, and my program Just Worked.  Not bad for an idea that was 35 years old.

Of course, your fleet of processors will require different programming (CSP with go?).  I look forward
to see if your solutions are even remotely as easy and useful as the originals.  

BTW, will those processors basically be 8051s?

ches


> On 8May 2018, at 11:31 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> My company, Wave Computing, has built a chip with 16,000 8-bit processors on it.  And we have plans to build systems with up to a quarter million processors.  We are breaking ground in new ways to use hundreds of processors to solve problems very quickly.  It's a new way of thinking, and it makes your brain hurt.  But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam.
> 
> And it's exciting...
> 
> Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/8ca0a25e/attachment.html>

[TUHS] unix "awesome list"

[Dave Horsfall]

On Tue, 8 May 2018, Larry McVoy wrote:

> vim, on the other hand, oh do I love me some vim.  It's pretty faithful 
> to the original vi but you get split windows, infinite undo, it 
> remembers stuff from one invocation to the next, it's pretty sweet.

Oh, I love VIM too, but I wish it had an "idiot" mode i.e. ignore any 
fumbled keys that did something strange and how do I get out of here 
because suddenly I see two windows when I meant to simply quit...

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)

[TUHS] unix "awesome list"

[Bakul Shah]

On May 8, 2018, at 7:53 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> I'll take a slight different road on this topic.  I think we are dealing with the paradox of progress. I don't blame Linux's developers any more than I blame BSDs or anyone else.   Really it was hardware progress/Moore's law that changed the rules :-)

Agree about the paradox of progress. Success slowed down further
evolution.

While h/w speed and number of gates increased tremendously
the particular *direction* processor architecture took is
heavily influenced by prevailing software. So I think it is
really software that is to blame :-) Intel did add callgates
for better containment but they didn't get used much.

> I think Ted makes an excellent point, that *BSD and Linux, by their nature of being 'open' and 'available' pushed the code along and that needs to continue to be the high order bit.  Open and freely available had a huge positive effect, because many of these new feature (like X-Windows, Networking) were 'useful' and the cost to add them was accessible -- so people added them.   But .... slowly the system changed and the expectations of the users with them.

The price of success.  It is easier to bolt-on solutions to new
problems on existing platform than refine the platform. Plan9
tried that. That it failed has more to do with non-tech reasons.

> Bakul's observation of little >>practical<< progress is an interesting one.   In many ways I agree, in others I'm not so sure.  I think Ted knows that my major gripe with some of the Linux (and Gnu style) community has been a focus on reimplementing things that were already there instead of using what could have been taken from somewhere else such as BSD, or replacing subsystems just because they could without really adding anything (i.e. the whole systemd argument).

The lack of progress I am talking about has to do with
the devil's bargain of trading simplicity for "efficiency".
The 16bit CPU running at 5Mhz, with 256K of RAM and 5MB of disk
in 1981 is replaced with a 64 bit processor with 16 cores,
64GB of RAM, with 10TB of disk space, with HDMI screen and
1GB/s network port (and is cheaper in terms of 1981 dollars).
And yet we continue making this bargain.

Pipes provided a perfect way to modularize programs. But we
use shared memory and threads - mainly for squeezing out more
performance. We have known about microkernels for over 30
years. CSP for over 40 years. Capability systems for over
50 years. Yet these are largely absent. Even Go provides
unsafe shared memory access in spite of providing channels.


> But over all, as much as I respect and think Ken and Dennis did amazing work at the time, I do tend to love when new ideas/things have been done beyond the original ideas from Ken and Dennis.  For instance, just as BSD can take credit (or blame) or sockets and making UNIX really a 'networked OS', Sun really gave us multiple file systems with the VFS, but  I strongly credit Linux for really making kernel modules a reality (yup Solaris had them, as did a few other systems - but it was really Linux that made it wide spread).   I wish Linux had taken the idea of a modular kernel a tad farther, and picked up things like Locus vproc work, because I personally think modularity under the covers is better than the containers mess we have today (and I agree with Tannenbaum that uKernel's make more sense to me in the long run - even if they do cost something in speed).

Plan9 did a much cleaner job of adding filesystems and networking.
May be the 9p protocol doesn't scale so well but that could've been
fixed once it was used in production systems.

A capability system would obviate the need for containers.
If all external communication a process did was via capabilities,
it doesn't matter if they directly access some physical device or
virtual device, a local server or a remote server, a real file or
a synthetic file. Microkernels and caps are a good match. But they
too haven't been used enough in practice and will need evolution.

> it's also why I liked Plan 9 and have high hopes that a new OS, maybe written is something like Rust might finally appear.   But I don't want it re-implement UNIX or Linux.   Grab from them the subsystems that you need to duplication, but don't re-invent.
> 
> 
> Warren - at the risk of being political -- I think the paradox we have it larger than just UNIX, although it is simple.  We can wallow and say everything is bad, it was simpler in 1959 -- which exactly what some folks in my country seem to be doing in other areas.  I personally can say my world was simple in those days and I certainly have fond memories [read Bill Bryson's https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378 which parrots many of my own memories of those times ], but UNIX, like the world, has grown up and changed and is a lot more complicated.   I like progress we have now.  I don't want the world the way it was any more than I want run Fifth Edition on my Mac for day-2-day work.
> 
> Yes, I would like us to look at the good from the past and see if we can have some of the good things again; but if it means giving up what gained too, then we have gone backwards.  The problem is how to decide what was good and what was bad?   What is real progress and what is just 'showing off your money' to use a Forest Gump concept.
> 
> I suspect we will argue for a long time about what qualifies as progress from the core idea of UNIX and what does not.

I think it is possible to gain equivalent feature comforts using
simpler systems. But my guess is "compatibility" requirement is
what will hold us back.

[TUHS] unix "awesome list"

[Bakul Shah]

On May 8, 2018, at 8:31 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> My company, Wave Computing, has built a chip with 16,000 8-bit processors on it.  And we have plans to build systems with up to a quarter million processors.  We are breaking ground in new ways to use hundreds of processors to solve problems very quickly.  It's a new way of thinking, and it makes your brain hurt.  But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam.

This sounds like a software equivalent of an FPGA! You probably
have similar to "EDA" tools for placement and routing and 
mapping a program written in "HDL" to the underlying technology.
Mapping APL to this could be fun (APL programs have a similar
brain hurting side-effect!).

Somewhat relevant: A retrospective on 30 years of FPGA technology:

https://ieeexplore.ieee.org/document/7086413/#full-text-section

[TUHS] (early parallel/concurrent computing) (was: unix "awesome list")

[Lyndon Nerenberg]

> On May 8, 2018, at 8:31 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> My company, Wave Computing, has built a chip with 16,000 8-bit processors on it.  And we have plans to build systems with up to a quarter million processors.  We are breaking ground in new ways to use hundreds of processors to solve problems very quickly.  It's a new way of thinking, and it makes your brain hurt.  But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam.

This might be going a bit out-of-bounds for the mailing list, but ...

How does what you are doing compare with the work the Myrias folks were doing in the mid-late 1980s with their n-way 680x0(?) parallel machines?  Didn't they make it to 256 processors before it collapsed?  I'm not aware of any papers that came out of their work, although I would think there must have been at least a few.  (Dan Wilson, are you on this mailing list?)

I didn't have the opportunity to see what Myrias was putting together as their OS.  But I did get to play with an indirect off-shoot of their work: a massive scale (for the time) file server, based on some of that parallel processing technology.  It mimicked the Plan9 Venti in some ways.  It was very block-oriented in its external API, and I used that lowish-level API to write a backend file store for the big-a** IMAP servers we were developing at the time.  I'm sure it would have kicked NetApp and friends around the block, but this was the late 1990s, and we were limited by 100 Mb/s Ethernet, so there was no real way to tell.

--lyndon

[TUHS] (early parallel/concurrent computing) (was: unix "awesome list")

[Ron Natalie]

BRL had contracted with the Denver Electronics Corporation (Denelcor) to
build a fluid dynamic platform.   Early plans were for an analog and then
hybrid computer, but this quickly evolved into the all-digital Heterogenous
Element Procesor.   The computer was MIMD and could run 40 or so threads
simultaneously while hardware scheduling 256 times that.   Each memory
location in the main memory had a "full-empty" bit which allowed you to to
execute instructions like "Wait until Full, then Store", and the processor
handled all that.

Of course, this was about the time Mike Muuss and his band were becoming
real firecrackers in the labs.    Mike shot his mouth off  that we could put
UNIX on it (our answer to everything) and the lab management took us up on
the offer.    Perhaps, with the exception of some of the MultibusII stuff,
one of the nicest UNIX architectures around.

Mike immediately set to work.   He did the C compiler while Doug Kingson did
the assembler.   I did the loader I think.   We then started on the kernel.
Mike doing the low level stuff and the guts of the kernel and me doing all
the IO (the "dmr" directory traditionally).      About the time we got the
thing running I realized that the IO performance was terrible.    The thing
had a sidecar unit with 32 distinct unibuses which  really should have been
fast enough, except the latency to start the I/Os was about ten ops/sec.
Me and the HEP designer, Burton Smith sat down at the Golden Corral
steakhouse in Aberdeen and designed a new processor that sat on the main
memory bus.   It was built out of spare HEP parts and a PDP-11/34 that I had
lying around as the control processer.   I through in the LOS operating
system (No time for sharing -- Uniprocessor system) scavenged from my BRL
Gateway code to drive it.   In two days we had drastically increased the IO
performance.

The thing ran parallizable apps, notably Mike's BRL ray tracing "CAD"
package.    We pretty much used it to generate a movie of a shell's eye view
of a collision with a tank.   The system was replaced with a Cray XMP.

Amusingly in our machine room, awaiting arrival of the HEP were taped out
markings where all the cabinets went around a central building pillar.
Visiting the machine in the factor, it was laid out around a taped marking
showing the location of our post.

-Ron

[TUHS] (early parallel/concurrent computing) (was: unix "awesome list")

[Kurt H Maier]

On Tue, May 08, 2018 at 08:25:08PM -0400, Ron Natalie wrote:
> 
> Of course, this was about the time Mike Muuss and his band were becoming
> real firecrackers in the labs.    Mike shot his mouth off  that we could put
> UNIX on it (our answer to everything) and the lab management took us up on
> the offer.    Perhaps, with the exception of some of the MultibusII stuff,
> one of the nicest UNIX architectures around.
> 

A gentleman at ARL during my time there once mentioned they had some
"real nice parallel systems" until someone "ruined them with unix"... I
never did get details on which system he would have preferred pristine.

khm

[TUHS] unix "awesome list"

[Grant Taylor]

On 05/08/2018 01:37 PM, Dave Horsfall wrote:
> I'll bet my website (about a few feet away from me) is smaller still :-)

Props for hosting your own site.

> But yeah. I've been told that I *need* HTTPS, even though the damned 
> site is purely passive...

I think /need/ may be a strong word.

I *strongly* believe in the various cache ability aspects of unencrypted 
HTTP.

That being said, I understand and believe in the two following reasons 
for supporting encrypted HTTPS:

1)  Encryption (from a verifiable source) makes it next to impossible 
for malicious actors to inject things into your site's traffic.  (Think 
about the various JavaScript injection techniques used for ads / 
tracking / malware / crypto mining / etc.)
2)  Creating more noise for someone with higher value signal to hide in 
when they really need to.

Finally, things like Let's Encrypt and other free cert providers make it 
much less expensive to use encrypted HTTPS.

I'm perfectly fine with people running unencrypted HTTP and encrypted 
HTTPS side by side.  Even if you don't do a redirect from unencrypted 
HTTP to encrypted HTTPS.

It's really up to each site administrator.  I'm 60% for and 40% against 
encrypted HTTPS everywhere.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/fbee360f/attachment.bin>

[TUHS] unix "awesome list"

[Dave Horsfall]

On Tue, 8 May 2018, Arthur Krewat wrote:

> I have a (very) small website in http that has a few TOPS-10 items for 
> download. That doesn't need to be https, but for some reason, I've heard 
> that Google will lower my rankings because I'm not using https. What 
> tomfoolery is this?

I'll bet my website (about a few feet away from me) is smaller still :-)

But yeah. I've been told that I *need* HTTPS, even though the damned site 
is purely passive...

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)

[TUHS] unix "awesome list"

[Arthur Krewat]

On 5/8/2018 11:17 AM, Noel Chiappa wrote:
>    
> There's a certain irony in people complaining that ukernel's have more
> overhead - while at the same time time mindlessly, and almost universally,
> propogating such pinheaded computing hogs as '_mandating_ https for everything
> under the sun' (even things as utterly pointless to protect as looking at
> Wikipedia articles on mathematics), while simultaneously letting
> Amazon/Facebook/Google do the 'all your data are belong to us' number; the
> piling of Pelion upon Ossa in all the active content (page after page of
> JavaScript, etc) in many (most?) modern Web sites that does nothing more than
> 'eye candy'; etc, etc.
>

Part of the https wave is the fact that the Tin Foil Hat Society thinks 
they are being maliciously monitored by the gov't. The move towards 
privacy on the Internet is fostered by this conspiracy-minded 
thoughtlessness. Meanwhile, it just adds another step to any entity 
wanting to figure out what you've been doing online. Either monitor your 
browser (ala telemetry), or the websites themselves. If one were to see 
https traffic to a website that's known for it's racist content, then 
that pretty much defines what you've been doing without having to 
decrypt the actual packets. Much less get your search history from 
Google in the first place.

I've heard this very same privacy concern from what I consider 
moderately intelligent people I associate with.

I have a (very) small website in http that has a few TOPS-10 items for 
download. That doesn't need to be https, but for some reason, I've heard 
that Google will lower my rankings because I'm not using https. What 
tomfoolery is this?

ak

[TUHS] unix "awesome list"

[Warner Losh]

On Tue, May 8, 2018 at 9:17 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Clem Cole
>
>     > I agree with Tannenbaum that uKernel's make more sense to me in the
> long
>     > run - even if they do cost something in speed
>
> There's a certain irony in people complaining that ukernel's have more
> overhead - while at the same time time mindlessly, and almost universally,
> propogating such pinheaded computing hogs as '_mandating_ https for
> everything
> under the sun' (even things as utterly pointless to protect as looking at
> Wikipedia articles on mathematics), while simultaneously letting
> Amazon/Facebook/Google do the 'all your data are belong to us' number; the
> piling of Pelion upon Ossa in all the active content (page after page of
> JavaScript, etc) in many (most?) modern Web sites that does nothing more
> than
> 'eye candy'; etc, etc.
>

But I want sshd on my pdp11 so that I can securely log in :(

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/b5d6685a/attachment.html>

[TUHS] unix "awesome list"

[Noel Chiappa]

    > From: Clem Cole

    > I agree with Tannenbaum that uKernel's make more sense to me in the long
    > run - even if they do cost something in speed

There's a certain irony in people complaining that ukernel's have more
overhead - while at the same time time mindlessly, and almost universally,
propogating such pinheaded computing hogs as '_mandating_ https for everything
under the sun' (even things as utterly pointless to protect as looking at
Wikipedia articles on mathematics), while simultaneously letting
Amazon/Facebook/Google do the 'all your data are belong to us' number; the
piling of Pelion upon Ossa in all the active content (page after page of
JavaScript, etc) in many (most?) modern Web sites that does nothing more than
'eye candy'; etc, etc.

	Noel