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've read a couple of books about Sun (maybe I should say, "both books about Sun") and my memory is that NeWS was considered significantly more elegant than X11 by many people who understood the problem space, and Sun was set on trying to make it an open standard as they did for NFS.
However, Sun (and again this is just my memory) had left many in the industry feeling burned on its last big standards push, I believe this was around NFS, and I don't recall the details of why. But there was so much bad blood that NeWS had an uphill battle. And I recall clearly (from these books) that there was a conscious effort when Java came along to help it avoid the fate of NeWS. Also as Wikipedia notes the actual Sun implementation of NeWS carried a licensing fee; mind you, they had a fairly open posture toward licensing the source but they did charge, whereas MIT gave away X11 code.
Anyway maybe someone can tell me how wrong I am here!
Notice how NeWS and NFS are spelled almost the same (except for that pesky little "e") -- that was on purpose to draw a parallel between NFS and NeWS (whose original name was SunDew, which I always thought they should have stuck with). Unfortunately that got a lot of bad attention and drew a lot of fire from other companies like DEC who didn't want to see Sun pull another NFS.
Here's "The NeWS Book"! It was written during the transition from NeWS 1.1 to X11/NeWS, so it has a chapter about porting NeWS to other platforms (like the Parallax live video graphics card, and SGI's 4Sight, the port of NeWS to the SGI Iris, as well as the port of NeWS to OS/2. It also has a forward-looking chapter on X11/NeWS architecture (X11/NeWS Design Overview).
I think SunDew is definitely the better name ... unless your goal is to make people forget the technology came from Sun. Of course, that didn’t happen anyway, so maybe they should have just stuck with SunDew!
When I did a computer vision course during the final years of my CS degree ('87/'88) we actually did the development on HLH Orion minis but could only view stuff by printing it out!
Edit: We did get a demo of 2D Fourier analysis stuff on a Sun - which, of course, we thought was amazingly cool.
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?)...
Here's a paper I wrote in 1989 about The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines: a visual programming and debugging interface for NeWS PostScript
That's the old Sun 4/200 brochure I saved, that we just scanned and uploaded it to http://archive.org! Here's my favorite one, the runway shot (click the image to see it in its full glory and splendor -- twitter cropped the best part!):
Sun had nice offices back in those days. Except for the open seating on the airport runway. And that was before the invention of noise cancelation headphones.
I managed to come full circle. I interned at Sun in the mid-90s and now work for Facebook. It was a surreal experience to walk on the same, yet totally different campus over 25 years later.
I tried it in the 90's, at a company that would have been a potential customer. It didn't work on the Linux boxes or the Windows boxes that had a commercial X server. We dropped it almost immediately, because Sun's solution was "buy SparcStations". Which was crazy expensive at the time. So the network was NOT the computer. McNealy was a smart, but confused duck.
McNealy is batshit crazy. He's a foaming-at-the-mouth Libertarian Trump supporter who hosts $50,000-per-plate Trump Reelection Campaign fundraising parties at his mansion, he praises Trump for his "spectacular job" handling the Coronivirus crisis, which he doesn't think is a big deal, because he's anti-self-isolation and a menace to society, who thinks "freedom" means the country should open back up and people should go out and congregate in crowds as soon as possible.
>Trump held fundraiser at former Sun CEO Scott McNealy’s Silicon Valley house on Tuesday.
>Protesters found out and lined the road, including raising a “baby Trump” balloon.
>President Trump held a campaign fundraiser at the home of Sun Microsystems co-founder Scott McNealy Tuesday, marking Trump’s first fundraiser in the Bay area since being elected president. A giant inflatable baby Trump was not far behind.
>The details of the $1,000 to $50,000-per-plate event were held quite tightly by local GOP officials, as attendees were reportedly asked to arrive at a remote location before being shuttled to McNealy’s mansion.
>McNealy was also known for being strongly against government regulation, poo-pooing worries about consumer privacy by saying, "You have zero privacy, get over it."
>Former Sun Micro CEO Scott McNealy, known for his provocative quotes, says Trump is doing a 'spectacular job' amid the coronavirus crisis. That's not how many tech experts see it.
>Scott McNealy, former CEO of Sun Microsystems who was famous for his provocative statements, praised President Trump's handling of the coronavirus crisis saying, "He's doing a spectacular job."
>McNealy also said he is glad a business leader is in charge, arguing that, "The worst CEO is 1,000 times better than the best politician."
>McNealy also expressed concerns about the duration of the shelter-in-place policy in California where he lives, arguing it could lead to the erosion of individual rights.
>McNealy was quickly rebuked by veteran tech experts. "I don't want politicians running my companies," Stanford professor Paul Saffo told Business Insider. "And I also don't want businessmen in political offices. They're two entirely different kinds of skills. That has been demonstrated again and again and again."
>Swim at your own risk. Drive at your own risk. Play hockey at your own risk. Skateboard at 65 at your own risk. Have someone hold your beer at your own risk. Smoke weed and drink while obese at your own risk. Freedom.
>xardox @xardox Replying to @scottmcnealy
>@BillGates is such a better, smarter, more humanitarian, well respected man than you are, Scott. For one thing, he kicked your ass and wiped the floor with it, & handed it to you on a platter, LOSER. For another thing, he's not a delusional MENACE TO SOCIETY like you are. Idiot.
>James Gosling @errcraft Replying to @scottmcnealy
>But if you smoke weed or drink, and then get behind the wheel of your car, you put everyone at risk. Some freedoms have to be curtailed to preserve other freedoms. Freedom is a balancing act, and that balance is one of the core reasons that We The People have a government.
I remember this news item clearly. When it hit /r/politics afterwards, I wrote that I wish I had known in advance, as I live close by and firebombing McNealy's parking lot with Molotov cocktails (since Trump loves Russia so much) would have made for an enjoyable evening. I got banned for six months for suggesting violence. (I sorta was, but not against people! Just their cars...). It was worth it.
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.
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.
Do you trust that, say, Amazon or Domino's would really have your best interests for your computer in mind? Websites win for commerce and for reading because of trust; the sandboxing browsers have may not be good, but they provide some reasonable assurance that McDonald's won't be checking your active programs and sending a list of them to somewhere they shouldn't be.
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.
Also, you'll have to update the software, publish it to app stores/package repos, pester users of outdated versions, deal with security vulnerabilities...
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.
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.
Blame Flat UI. Thanks to Flat UI, native apps don't have a special look & feel. To the user this means native apps don't look any different from Web/Electron apps. So users don't know to demand native apps.
If users can't tell, why as a developer would you invest in a native app and only get a slice of the market, when you could use web technologies and have your app work on all platforms?
> native apps don't look any different from Web/Electron apps
But they feel way better. Electron apps have insane resource overhead and many minor imperfection in behavior. I have never been willing to sacrifice aesthetics and ergonomics for performance yet Electron feels bloated beyond all reason even to me. The reasons I believe I could prefer a native app to a browser-based web app are performance and intuitiveness. Browser based often are too slow and have hard-to-find parts. Obviously wrapping a web app in Electron doesn't solve that.
Perhaps that means somebody at Microsoft has found a way to optimize the Electron runtime for VS Code. The VS Code fronted mostly is about displaying text - obviously there is a huge lot of inefficiencies you can optimize by excluding whole blocks of logic unnecessary for this kind of tasks.
I think the previous commenters are missing the forest for the trees.
You would have these tools if the APIs were open and existed! RSS is a great example where there are many awesome native clients.
This pizzatool was not made in coordination with any pizza shop. It was not made with a subscription model, or some high end software team.
It was made by hackers because they realized they could send a fax. It's why CLI programs exist and interoperate so well, but gui's always seem to be islands of their own.
Those are pretty much the wrong kind of apps for me: I'd prefer a web page for almost all of those. I'd considered building a news reader app for HN (in the lineage of "trn"), but only because I spend too much time here.
Web apps can be hyperlinked. Apps basically can't. So if it's for "documents", give me a hypertext browser interface. Web pages over PDFs for almost every purpose, although I can sort of see the use for things like datasheets and documents which are both paginated (why?) and have a very high page count.
Application sandboxing is definitely not a solved problem on the desktop OSs, unless you count the tiny Windows store. So each application downloaded is like a trip outside during quarantine: am I going to get infected?
Only "creation" interfaces really benefit enough from the flexibility and performance of native - especially the access to the real filesystem. The downside of creative web apps is that they are cloud-native.
- Cross-platformness; if you have a decent webapp, you cover all major platforms and operating systems, plus mobile if you make it responsive. If you go native you may need to create separate apps for windows, macos, linux, android and iOS. Cross-platform toolkits that aren't browser based just aren't good enough. I mean you mention WPF / Cocoa already which aren't cross-platform so you need two teams to build two apps that do the same thing.
- Customizability; it's harder to make an app look and feel the same across platforms. Granted, for best UX you don't actually want that, but at the same time the branding department says you should, people don't want to have to maintain documentation and screenshots for multiple platforms, etc.
I mean I hear you and personally I much prefer the responsiveness and efficiency of native apps, but we don't live in an ideal world.
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.
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.
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. :-)
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.
It was truly an amazing time. Some of us keep wandering, trying to find our way back to those days. But the people who made this environment have moved on.
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!”
> 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 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.
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!)
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.
"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."
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.
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!
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).
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]
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]
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. [...]
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.
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:
>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.
"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.