Port 144 carries one of the great "what if" stories of computing. It was originally registered for NeWS, the Network extensible Window System,1 a windowing protocol so technically advanced that its only real weakness was the company that owned it.
What Ran on Port 144
Port 144 was assigned to NeWS (registered as the service name news in the IANA port registry, not to be confused with Usenet's NNTP on port 119).2 NeWS was a network-transparent windowing system built on PostScript, the same page description language that powered laser printers. But where PostScript on a printer produced static pages, NeWS on port 144 produced live, interactive, programmable graphical interfaces.
The protocol allowed client programs to send PostScript code to a display server, which would execute it to render windows, handle mouse input, and manage the entire graphical environment. The server didn't just display pixels. It ran programs.
Today, the port's IANA assignment has been transferred to UMA (Universal Management Architecture), a largely obscure protocol. The NeWS registration, listed under the contact [JAG] in RFC 1060 and RFC 1340, is a historical artifact.34
How NeWS Worked
The key insight behind NeWS was programmability at the display server level. In the mid-1980s, workstations and networks were slow. If every mouse movement required a round trip across the network to the application and back, the interface would be unusable.
NeWS solved this by sending PostScript programs to the server. Those programs could respond to user input locally, without a network round trip. The server ran a cooperative multitasking PostScript interpreter, managing multiple windows simultaneously, each running its own PostScript context.5
To support real GUI widgets, NeWS extended PostScript into a full object-oriented programming language with inheritance. You could write a complete interactive application entirely in PostScript and send it down the wire to run on the display server. No C code required. No compilation step. Just PostScript describing what the window should look like and how it should behave.
This was, by the standards of 1986, astonishing.
The Story: James Gosling and the Window Wars
In September 1985, David Rosenthal arrived at Sun Microsystems to work with James Gosling on a windowing system for Sun's workstations.6 The two had previously collaborated on the Andrew window system at Carnegie Mellon University.
They identified three requirements for a Unix windowing system that could succeed:
- A higher-level imaging model than raw pixels, so applications wouldn't break at different screen resolutions. PostScript, which had just appeared on the Apple LaserWriter, was the obvious choice.
- Network transparency, so applications could run on one machine while displaying on another. In an era of slow CPUs, splitting the work across two machines was a practical necessity.
- Programmability, so that user interaction could be handled locally on the display server without network latency.
They built NeWS (originally codenamed "SunDew") to satisfy all three. And technically, it worked. Compared to the X Window System, NeWS was "vastly more powerful."5
But X had something NeWS didn't: freedom.
MIT released X11 under what became the MIT License in September 1987. Anyone could use it, modify it, ship it. Sun charged a licensing fee for NeWS source code.5 In the ecosystem of Unix workstation vendors who were already nervous about Sun's growing dominance, this mattered enormously.
Even David Rosenthal, one of NeWS's creators, recognized the reality: "it was more important for the company that the Unix world standardized on a single window system than that the standard be Sun's NeWS system."6
Sun tried to compromise. They released OpenWindows in 1989, a hybrid server called "xnews" that ran both X11 and NeWS protocols simultaneously.7 The compromise pleased no one. It degraded NeWS performance and wasn't a particularly good X11 server either.
By 1993, with Solaris 2.3, Sun quietly dropped NeWS and shipped a standard X11 server.7 The window wars were over.
The Java Connection
Here is the detail that makes port 144 genuinely remarkable: James Gosling, the [JAG] listed as the IANA contact for port 144, went on to create Java.8
The ideas that animated NeWS, network transparency, platform independence, code that travels across the wire to execute on another machine, reappeared in a different form. Java applets did for the web browser what NeWS PostScript programs did for the display server: they sent executable code across the network to run where the user was.
The object-oriented extensions Gosling built for NeWS's PostScript echoed in Java's class hierarchy. The lightweight component architecture of Java Swing descended from the same design philosophy.
Port 144 didn't just carry a windowing protocol. It carried the prototype of an idea that would reshape how the world writes software.
The Lesson
NeWS lost the window wars for a reason that has repeated across the history of computing: technical superiority does not overcome closed licensing. The X Window System was not better than NeWS. It was free. And free, in a world of competing Unix vendors who needed a neutral standard, was enough.
This lesson would echo through the open source movement for decades. Linux over proprietary Unix. Apache over commercial web servers. The pattern is consistent: when the technology is good enough and the license is open, open wins.
Port 144 Today
Port 144 sits in the well-known port range (0-1023), meaning binding to it on Unix-like systems requires root privileges.9 Its current IANA assignment is UMA (Universal Management Architecture), a protocol with minimal adoption.
In practice, port 144 is quiet. You are unlikely to find anything listening on it.
How to Check What Is Listening on Port 144
Linux:
macOS:
Windows:
If something is listening on port 144 and you didn't put it there, investigate. Unassigned well-known ports used without explanation are a potential indicator of unauthorized software.
Security Considerations
Port 144 has no widely deployed modern service. Its well-known port status means it requires elevated privileges to bind, which provides a minimal barrier against casual misuse. However, the obscurity of the port can work both ways: legitimate administrators are unlikely to monitor it, making it a potential candidate for covert communication channels.
Standard practice: if you're not running a service on port 144, firewall it.
Frequently Asked Questions
Was this page helpful?