* [TUHS] unix "awesome list"
2018-05-08 14:53 ` Clem Cole
@ 2018-05-08 15:23 ` Jon Steinhart
2018-05-08 15:31 ` Steve Johnson
2018-05-08 21:15 ` [TUHS] unix "awesome list" Bakul Shah
2 siblings, 0 replies; 24+ messages in thread
From: Jon Steinhart @ 2018-05-08 15:23 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] unix "awesome list"
2018-05-08 14:53 ` Clem Cole
2018-05-08 15:23 ` Jon Steinhart
@ 2018-05-08 15:31 ` Steve Johnson
2018-05-08 16:32 ` Clem Cole
` (4 more replies)
2018-05-08 21:15 ` [TUHS] unix "awesome list" Bakul Shah
2 siblings, 5 replies; 24+ messages in thread
From: Steve Johnson @ 2018-05-08 15:31 UTC (permalink / raw)
[-- 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>
^ permalink raw reply [flat|nested] 24+ messages in thread* [TUHS] unix "awesome list"
2018-05-08 15:31 ` Steve Johnson
@ 2018-05-08 16:32 ` Clem Cole
2018-05-08 17:33 ` Theodore Y. Ts'o
` (3 subsequent siblings)
4 siblings, 0 replies; 24+ messages in thread
From: Clem Cole @ 2018-05-08 16:32 UTC (permalink / raw)
[-- 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>
^ permalink raw reply [flat|nested] 24+ messages in thread* [TUHS] unix "awesome list"
2018-05-08 15:31 ` Steve Johnson
2018-05-08 16:32 ` Clem Cole
@ 2018-05-08 17:33 ` Theodore Y. Ts'o
2018-05-08 18:40 ` William Cheswick
` (2 subsequent siblings)
4 siblings, 0 replies; 24+ messages in thread
From: Theodore Y. Ts'o @ 2018-05-08 17:33 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 24+ messages in thread* [TUHS] unix "awesome list"
2018-05-08 15:31 ` Steve Johnson
2018-05-08 16:32 ` Clem Cole
2018-05-08 17:33 ` Theodore Y. Ts'o
@ 2018-05-08 18:40 ` William Cheswick
2018-05-08 21:25 ` Bakul Shah
2018-05-08 23:06 ` [TUHS] (early parallel/concurrent computing) (was: unix "awesome list") Lyndon Nerenberg
4 siblings, 0 replies; 24+ messages in thread
From: William Cheswick @ 2018-05-08 18:40 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] unix "awesome list"
2018-05-08 15:31 ` Steve Johnson
` (2 preceding siblings ...)
2018-05-08 18:40 ` William Cheswick
@ 2018-05-08 21:25 ` Bakul Shah
2018-05-08 23:06 ` [TUHS] (early parallel/concurrent computing) (was: unix "awesome list") Lyndon Nerenberg
4 siblings, 0 replies; 24+ messages in thread
From: Bakul Shah @ 2018-05-08 21:25 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [TUHS] (early parallel/concurrent computing) (was: unix "awesome list")
2018-05-08 15:31 ` Steve Johnson
` (3 preceding siblings ...)
2018-05-08 21:25 ` Bakul Shah
@ 2018-05-08 23:06 ` Lyndon Nerenberg
2018-05-09 0:25 ` Ron Natalie
4 siblings, 1 reply; 24+ messages in thread
From: Lyndon Nerenberg @ 2018-05-08 23:06 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread* [TUHS] (early parallel/concurrent computing) (was: unix "awesome list")
2018-05-08 23:06 ` [TUHS] (early parallel/concurrent computing) (was: unix "awesome list") Lyndon Nerenberg
@ 2018-05-09 0:25 ` Ron Natalie
2018-05-09 1:28 ` Kurt H Maier
0 siblings, 1 reply; 24+ messages in thread
From: Ron Natalie @ 2018-05-09 0:25 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] (early parallel/concurrent computing) (was: unix "awesome list")
2018-05-09 0:25 ` Ron Natalie
@ 2018-05-09 1:28 ` Kurt H Maier
0 siblings, 0 replies; 24+ messages in thread
From: Kurt H Maier @ 2018-05-09 1:28 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] unix "awesome list"
2018-05-08 14:53 ` Clem Cole
2018-05-08 15:23 ` Jon Steinhart
2018-05-08 15:31 ` Steve Johnson
@ 2018-05-08 21:15 ` Bakul Shah
2 siblings, 0 replies; 24+ messages in thread
From: Bakul Shah @ 2018-05-08 21:15 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 24+ messages in thread