
Sun Microsystems PizzaTool (2018) - zdw
https://medium.com/@donhopkins/the-story-of-sun-microsystems-pizzatool-2a7992b4c797
======
russellbeattie
I had to look up NeWS because I was bewildered at how Sun was writing
PostScript by hand to create a whole GUI. Wikipedia has a nice summary
comparing it to Display PostScript used in the NeXT:

"Sun Microsystems took another approach, creating NeWS. Instead of DPS's
concept of allowing PS to interact with C programs, NeWS instead extended PS
into a language suitable for running the entire GUI of a computer. Sun added a
number of new commands for timers, mouse control, interrupts and other systems
needed for interactivity, and added data structures and language elements to
allow it to be completely object oriented internally. A complete GUI, three in
fact, were written in NeWS and provided for a time on their workstations.
However, the ongoing efforts to standardize the X11 system led to its
introduction and widespread use on Sun systems, and NeWS never became widely
used."

I miss Sun. They were fun.

~~~
arethuza
I would argue that the best NeWS interface toolkit wasn't even built by Sun -
HyperNeWS|HyperLook:

[https://news.ycombinator.com/item?id=20182294](https://news.ycombinator.com/item?id=20182294)

Edit: Writing PostScript by hand was actually rather good fun - it's actually
quite a nice language.

~~~
rbanffy
> Edit: Writing PostScript by hand was actually rather good fun - it's
> actually quite a nice language.

Part of the fun was that the most powerful computer in the office, for quite
some time, was in the laser printer.

~~~
jacobush
Ah, there was some C64 software which used the CPU (same as in the C64) in the
diskette drive for something. :)

~~~
rbanffy
How many 1541a could you daisy chain to a C64? If sending problem data and
getting results is faster than doing the calculations on the C64 itself, we
can have some net gains.

I don't think Bitcoin mining is viable, but rendering fractals may be...

I remember one PostScript printer (AMD 29K-based) that rendered a Mandelbrot
set much faster than my modest Mac LC 2 (or 3?)...

------
squarefoot
The good ol' days, when UI designers put handles on windows corners, so that
users weren't forced to find the right pixel to resize them.

~~~
beamatronic
UIs reached their peak with Motif and it's been downhill ever since.

------
petilon
I used to have a Sun workstation back in the 90's. They were awesome. My
workstation had 16MB of memory and ran SunOS, Sun's version of Unix based on
BSD.

With 16MB of memory the system was a pleasure to use, and had an excellent UI
(OpenLook, as seen in the screenshots of the PizzaTool.)

25 years later we have machines that are many times more powerful with many
times more memory. But is the overall experience better? Not really. Windows
10 has a sucky UI, and despite more powerful machines, doesn't run much better
than my 16MB Sun Workstation used to.

------
qwerty456127
Why don't people make native apps for everything today? Modern frontends use
talk to web APIs for data and business logic anyway, Qt/WPF/Cocoa are better
than web front-ends. I'd enjoy having desktop apps for instead of many of the
websites I use - to order pizza, to buy stuff, to read/comment news or
anything.

~~~
muro
You'll need apps for each platform; testing is much more expensive;
discoverability is a challenge; people (myself included) trust websites much
more than native apps; you'll need a browser version anyway.

~~~
qwerty456127
> You'll need apps for each platform

For many apps that's not hard. E.g. a pizza app like that is hardly going to
take more than some hours to implement with whatever a toolkit. Almost every
other app which is bloat-free and made to do just one job is going to be a
similar case.

> people (myself included) trust websites much more than native apps

Because websites are sandboxed and updated. Right? Both things are already
addressed in all the major OSes although there still is a huge lot of room for
improvement.

> you'll need a browser version anyway.

Sure but as a user I can name quite a list of heavyweight websites which are
pain to use and could fit a native app perfectly.

~~~
cube00
Fast to create but a long term drain on resources, bugs roll in, libraries
need security updates, need to keep people around with the skill sets for all
those platforms.

~~~
MisterTea
Everything you just said applies to mobile/webdev as well.

------
zeruch
These kinds of tools were all over Sun when i was there in the late 90s. Sun
really tried to make simple, focused tools for seemingly everything back then.
They simply needed to work cleanly and be easy to use.

------
myrandomcomment
Most importantly the pizza place is still around.

[http://www.tonyandalbaspizza.com/](http://www.tonyandalbaspizza.com/)

~~~
DrScump
They long since closed in Mountain View (we used to eat there on Sundays after
volleyball) and are now in better digs on Stevens Creek Blvd near Winchester.

------
arethuza
I remember playing with this in the early 1990s - although I was pretty
confident that the "Send Fax" button wouldn't do anything (the machines
weren't connected to the Internet let alone being able to fax) I didn't want
to run the risk of having to pay the delivery fees to get a pizza to
Edinburgh. :-)

------
buzzert
Tony and Alba’s in Silicon Valley is still around, too! The first time I read
this I went with a couple of nerdy friends, and we kept asking their staff
about their computer system. Eventually after confusing enough of the staff we
spoke to a really nice guy who has been there for a long time and remembers
the fax system. “Have a slice day!”

------
beamatronic
“ Cellular Pizza Fax (CPF), in which fax machines would be places inside
roving pizza trucks to reduce the mean time between order and delivery.”

They might get a chuckle at how accurate this turned out to be.

------
ornornor
This makes me wish I worked in software back in the 90s. Looks like they were
having a blast!

~~~
lokedhs
I worked for Sun until the early 2000's. It was a nice place to work. I liked
the openness internally, regardless of what team/country you were working in.

I don't know where you could work these days that has the same kind of
atmosphere.

~~~
kyuudou
There were legendary stories of elaborate pranks, also:

[https://tech.gaeatimes.com/index.php/archive/april-fool-
pran...](https://tech.gaeatimes.com/index.php/archive/april-fool-pranks-in-
sun-microsystems-over-the-years/)

------
flobosg
This reminded me of Adobe's burrito ordering program
([http://www.mit.edu/afs.new/sipb/user/marthag/postscript/burr...](http://www.mit.edu/afs.new/sipb/user/marthag/postscript/burritos)).

> _Tired of standing in line at La Costena? This file documents an automatic
> facility for sending a fax to La Costena that orders 1 or more burritos,
> quesadillas, tacos, and whatever. The command will compose the fax, and send
> it to your favorite PostScript fax printer, for direct transmission to La
> Costena, and no paper at this end will be generated. Then, when you get
> there, your food will be waiting. No worries._

~~~
DonHopkins
I love La Costeña! I posted these about it earlier:

[https://news.ycombinator.com/item?id=12478422](https://news.ycombinator.com/item?id=12478422)

DonHopkins on Sept 12, 2016 | parent | favorite | on: Dynamic Programming: The
Name (1984)

The story I heard was that Adobe's Type 1 font encoding [1] used obscure names
like BlueValues, OtherBlues, FamilyBlues, FamilyOtherBlues, BlueScale,
BlueShift, and BlueFuzz, so that Adobe employees could discuss their
proprietary font hinting algorithms in public while they were in line for
burritos at La Costeña [2]. That way nobody from Apple or Sun or SGI who was
standing in line next to them could understand what they were talking about.

Yes THAT World Famous La Costeña: Guiness Record Holder for the World's
Largest Burrito! [3] On May 3rd, 1997 La Costeña of Mountain View, California
created the world's largest burrito. The burrito weighed in at 4,456.3 pounds
and was measured at 3,578 feet long. It was created at Rengstorff Park in
Mountain View.

[1]
[https://partners.adobe.com/public/developer/en/font/T1_SPEC....](https://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF)

[2] [http://www.costena.com](http://www.costena.com)

[3] [http://www.costena.com/famous.html](http://www.costena.com/famous.html)

[https://news.ycombinator.com/item?id=20852875](https://news.ycombinator.com/item?id=20852875)

DonHopkins 7 months ago | parent | favorite | on: Amazon’s “two-pizza teams”:
The ultimate divisiona...

How huge could a "One-Burrito" Team possibly be?

[http://www.costena.com/famous.html](http://www.costena.com/famous.html)

On May 3rd, 1997 La Costeña of Mountain View, California created the world's
largest burrito. The burrito weighed in at 4,456.3 pounds and was measured at
3,578 feet long. It was created at Rengstorff Park in Mountain View.

(So big they had to photograph it from an airplane!)

[http://www.supersizedmeals.com/food/article.php/200604112036...](http://www.supersizedmeals.com/food/article.php/2006041120363213)

[https://twitter.com/xardox/status/997942006872764416](https://twitter.com/xardox/status/997942006872764416)

xardox @xardox

I finally found the whole story behind the World's Largest Burrito that La
Costeña made in Rengstorff Park in 1997! 4453.3 pounds, 3578 feet long!!! Also
set that day was the world record for largest number of porta-potties filled.

[http://supersizedmeals.com/food/article.php/2006041120363213](http://supersizedmeals.com/food/article.php/2006041120363213)

"Despite the hearty appetites of everyone involved, a substantial amount of
food was left over. Soon people were filling enormous paper boxes with foot-
long lengths destined for the freezer. A couple groups carried six-foot
lengths like fire hoses to waiting pickup trucks."

------
randomstring
I worked at Sun in the late 90s. I Never used pizza tool, but I did order
burritos with the command line burrito tool. It would fax your order to
Burrito Real in Mountain View. By the time you arrived at Burrito Real, your
burrito would be waiting and you could skip the line, get your burrito and
pay.

------
wicket
I hope the pizza arrived in a SPARCstation! ;)

~~~
em-bee
i got a SPARCstation pizzabox, but when i opened it, there was no pizza inside
:-(

it's actually sad that pizzabox style computer cases are very rare nowadays

~~~
DrScump
I remember when my Sparcstation was replaced with the Sparcstation IPC. "How
in the hell is my monitor going to fit on top of _that?_ "

~~~
DonHopkins
At least it wasn't a Sparcstation SLC ("Silly Little Computer")!

------
anthk
I wonder if Don Hopkins could adapt the infamous z-machine interpreter written
in PostScript to read v5 games.

~~~
DonHopkins
Yikes! ;)

I wrote a terminal emulator in PostScript. Maybe somebody could port that so
it runs in the laser printer, so you can record an emacs sessions running on a
VT-100, send it to the printer, and print out an animated flip-book of it!

[https://donhopkins.com/home/archive/NeWS/tnterm.ps](https://donhopkins.com/home/archive/NeWS/tnterm.ps)

~~~
anthk
[https://rec.arts.int-
fiction.narkive.com/SpMHXFdN/z-machine-...](https://rec.arts.int-
fiction.narkive.com/SpMHXFdN/z-machine-in-postscript)

Not mine. It runs up to v3 games, thus, z3 extension. An old version of Curses
(and of course Zork) will run fine.

[http://mirrors.ibiblio.org/interactive-
fiction/games/zcode/](http://mirrors.ibiblio.org/interactive-
fiction/games/zcode/)

Example:

gs -DNODISPLAY -- ./advent.z3

It works on GhostScript, but it may be adapted fast for any PostScript
interpreter with a prompt.

------
fortran77
I remember playing with this at Adobe when it was in two buildings in Mountain
View back in 1990 or so....

------
qwerty456127
Looks beautiful. I wish I could use an app like this to order a pizza now.

~~~
tmh88j
Not an app, but Domino's website has a pizza builder that shows the toppings
being added onto a pizza as you select them.

------
teddyh
Too bad that NeWS was a proprietary system designed to replace X11.

~~~
DonHopkins
NeWS wasn't designed to replace X11, which didn't exist yet when NeWS was
designed. At the time NeWS was designed, it was called SunDew. X10 existed,
which David Rosenthal worked on (one of the authors of NeWS, and later he
wrote the X11 ICCCM window management protocol), and Gosling and Rosenthal
also worked on CMU's Andrew window system (long before Andrew was ported to
X11).

[https://en.wikipedia.org/wiki/David_S._H._Rosenthal](https://en.wikipedia.org/wiki/David_S._H._Rosenthal)

I posted this earlier, which goes into lots of details, which I'll excerpt:

[https://news.ycombinator.com/item?id=13783967](https://news.ycombinator.com/item?id=13783967)

Here is one of Gosling's earlier papers about NeWS (originally called
"SunDew"), published in 1985 at an Alvey Workshop, and the next year in an
excellent Springer Verlag book called "Methodology of Window Management" that
is now available online for free. [1]

[1] [http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/overview.htm)

Methodology of Window Management

F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams

29 April 1985

This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon
that took place from 29 April 1985 until 1 May 1985. It was input into the
planning for the MMI part of the Alvey Programme.

The Proceedings were later published by Springer-Verlag in 1986.

Chapter 5: SunDew - A Distributed and Extensible Window System, by James
Gosling [2]

[http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p005.htm)

5\. SunDew - A Distributed and Extensible Window System

James Gosling

SunDew is a distributed, extensible window system that is currently being
developed at SUN. It has arisen out of an effort to step back and examine
various window system issues without the usual product development
constraints. It should really be viewed as speculative research into the right
way to build a window system. We started out by looking at a number of window
systems and clients of window systems, and came up with a set of goals. From
those goals, and a little bit of inspiration, we came up with a design.

GOALS

A clean programmer interface: simple things should be simple to do, and hard
things, such as changing the shape of the cursor, should not require taking
pliers to the internals of the beast. There should be a smooth slope from what
is needed to do easy things, up to what is needed to do hard things. This
implies a conceptual organization of coordinated, independent components that
can be layered. This also enables being able to improve or replace various
parts of the system with minimal impact on the other components or clients.

Similarly, the program interface probably should be procedural, rather than
simply exposing a data structure that the client then interrogates or
modifies. This is important for portability, as well as hiding implementation
details, thereby making it easier for subsequent changes or enhancements not
to render existing code incompatible. [...]

~~~
teddyh
OK, sorry; “designed” was an inappropriate word choice. I should have said
“meant” to replace X11, as that what it was meant to do, at least later when
it was indeed competing with X11.

~~~
DonHopkins
NeWS wasn't "meant" to replace X11 either, which as I mentioned didn't exist
when it was designed. And it wasn't meant to replace X10 either, which hardly
anyone used at the time.

It might be slightly more historically accurate to say that NeWS was "meant"
to replace SunView or Andrew, but that wasn't its goal either.

From the horse's mouth, NeWS was "meant" to be viewed as "speculative research
into the right way to build a window system", and its definition and goals
didn't depend on its relationship to any version of X, but instead on
PostScript as a Turing-complete extensible network protocol.

As the SunDew paper by Gosling and Rosenthal that I referred you to said,
these were the goals of NeWS, an none of them had anything to do with
replacing X10 or X11:

[http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p005.htm)

>GOALS

>A clean programmer interface: simple things should be simple to do, and hard
things, such as changing the shape of the cursor, should not require taking
pliers to the internals of the beast. There should be a smooth slope from what
is needed to do easy things, up to what is needed to do hard things. This
implies a conceptual organization of coordinated, independent components that
can be layered. This also enables being able to improve or replace various
parts of the system with minimal impact on the other components or clients.

>Similarly, the program interface probably should be procedural, rather than
simply exposing a data structure that the client then interrogates or
modifies. This is important for portability, as well as hiding implementation
details, thereby making it easier for subsequent changes or enhancements not
to render existing code incompatible.

>Retained windows: a clean programmer interface should completely hide window
damage from the programmer. His model of a window should be just that it is a
surface on which he can write, and that it persists. All overlap issues should
be completely hidden from the client. I believe that the amount of extra
storage required to maintain the hidden bitmaps on a black and white display
is negligible - based on the observation that people generally do not stack
windows very deeply. The situation is somewhat different with colour, but
there are games to be played. Retained windows is one way of hiding window
damage, but we do not want to commit to a particular solution to this problem
at this time.

>Flexibility: users need to attach devices, change menu behaviours and
generally modify almost all components of the system. For example, the menu
package ought to be independent of the particular format or contents of the
menu, thereby allowing the user to develop his own idioms without having to
reimplement the entire system.

>Part of flexibility is device independence: SUN provides a spectrum of
display devices to which clients need consistent and transparent interfaces.
This leads directly to portability, which we also need to achieve.

>Users should be able to make various tradeoffs differently than in the
standard system, because of either particular hardware or performance
requirements. For example, if the system provides retained windows because we
believe that the cost in terms of memory usage is worth the performance
improvements, a user should be able to make this tradeoff differently, for
example if he has less memory.

>This extreme flexibility might appear to be at odds with having a clean,
simple, well-abstracted programmer interface, but we do not believe that it
is.

>Remote access to windows: in the kind of distributed networked environment
that SUN promotes, it is natural to want to be able to access windows on
another machine as naturally as the NFS promises to support accessing remote
files. We believe that this will fall out of any reasonably designed system.

>Powerful graphical primitives: the primitives that the Macintosh provides
should be considered as a lower bound. Curves and colour need to be well
integrated. Attention should also be paid to what CGI [30], GKS [28], CORE
[24] and PHIGS [6] need. A consequence of an emphasis on power and flexibility
is the ability to emulate other window systems, eg it would be very valuable
to be able to provide an emulation of the Macintosh toolbox.

>Exploit the hardware: in particular, none of the systems mentioned above deal
well with colour. In the future, colour is going to play an even larger part
in display design. One can view black and white as a temporary technological
stopgap, just as happened with television. Besides, SUN makes some pretty good
colour displays, so the window system should exploit them. One implication of
this is that the font file format must completely hide the details of the
representation of characters, since we might eventually want to support
antialiased text, and even illuminated monastic typefaces.

>Perform well: the performance of the current window system should be
considered as the minimum acceptable level. Performance in the common cases is
especially critical. The new system should perform faster than the current
system on such common operations as repainting and scrolling of text.

And years later after that was written, X11/NeWS didn't try to replace X11
with NeWS -- just the opposite: Sun put a huge amount of effort into
integrating them together and supporting them both. If Sun meant to replace
X11 with NeWS, they would have kept on developing NeWS instead of making
X11/NeWS.

NeWS was actually able to complement and improve X11 by implementing superior
window management, by wrapping X11 client windows in NeWS window frames, which
could be arbitrarily shaped, with tabs, pie menus, etc.

[https://news.ycombinator.com/item?id=8042726](https://news.ycombinator.com/item?id=8042726)

[https://news.ycombinator.com/item?id=15327339](https://news.ycombinator.com/item?id=15327339)

[https://news.ycombinator.com/item?id=19748582](https://news.ycombinator.com/item?id=19748582)

[https://news.ycombinator.com/item?id=22455722](https://news.ycombinator.com/item?id=22455722)

