3 ms·

Counterpoint: Plan 9 is supposed to be the ultimate realization of the Unix philosophy. One important aspect of the Unix philosophy is composable software. In

Counterpoint: Plan 9 is supposed to be the ultimate realization of the Unix philosophy. One important aspect of the Unix philosophy is composable software. Instead of large, feature-rich programs where functionality is often siloed off from other programs, users have a toolbox of small, composable programs that “do only one thing and do it well” and that they could connect together using pipes and other inter-process communication primitives. Composable software is something I’m highly interested in. There were efforts in the 1990s to make desktop software more composable, such as COM from Windows and OpenDoc from Apple, but the desktop world is still dominated by large applications such as those that constitute Microsoft Office and the Adobe Creative Suite. It would have been a wonderful opportunity for the Linux desktop world to embrace components, but, alas, the community embraced OpenOffice, GIMP, and other large applications.

nrr 2y ago
The irony is that Acorn's RISC OS arguably came the closest to this ideal with any pragmatism. The way that file choosers worked effectively allowed one to pipe a saved file from one application to another and then do it again through the same workflow in the next application and so on.
- foul 2y ago
  This kind of IPC lurks in every major OS, drag to an app window is supported by Xorg Mac and Windows.
  - nrr 2y ago
    I suppose this is IPC in the loosest possible sense? It's more like GetOpenFileName() and GetSaveFileName() in Win32 but getting handed a HANDLE outright instead of an LPCSTR to pass to CreateFile() later.
flomo 2y ago
Agreed. And one could argue that Unix wasn't really popular because of the "philosophy", but because it would get out of the way and let you run big monolithic applications like OracleDB or CAD software or even Emacs and etc. So no popular application using "Plan 9 philosophy" ever emerged.
- linguae 2y ago
  I agree, but I believe the fact there are no popular applications that fully embrace the Unix/Plan 9 philosophy is the point of the philosophy. Generic tools that can be composed versus end-to-end applications. Both have their advantages and disadvantages, though component-based software doesn’t preclude the development of end-to-end applications using these components. In my opinion I believe the reason end-to-end applications are dominant is because it’s easier for companies to sell and market products over tools. Part of the reason OpenDoc failed was because companies that made a living selling end-to-end applications (like Adobe) didn’t want to adopt component-based software where the product (application) isn’t the main focus. Imagine if users could construct their own Photoshop out of discrete elements.
  - pjmlp 2y ago
    There were plenty of ActiveX lego components to build Photoshop like applications on Windows during the 1990's, back when buying libraries was a thing professionals would care about.
- hakfoo 2y ago
  I suspect the appeal of the Unix Philosophy is strongest at the earliest phases of the system's evolution. Once you've written some very basic boostrap tools, the "second generation" of stuff that adds convenience and flexibility are a lot simpler. A trivial example: 20 seconds after you wrote "directory listing", someone will say "I want a directory listing, but sorted by date, and it would be awesome if it didn't immediately scroll past the end of my screen." With Unix Philosophy tools, you might already have have a "sort" and "paginate" command, so it's just piping stuff together. They can do it themselves, or it will take 20 seconds to explain. Without it, you're going to have to add additional options to "directory listing" (or parallel commands) to handle the sorting and pagination features. The tools get bigger and buggier for the same functionality. Early Unix machines weren't much bigger than mid-80s PCs-- 512K of memory or less-- but offered a very rich command line experience compared with DOS machines of similar sizes. Programs like database or CAD packages probably go monolithic because they're more "state dependent" than your usual command-line tools. "sort" and "more" can take their inputs from stdin and feed them out to stdout, and when they're done, forget everything with no damage. That wouldn't work well for other packages. You could probably make a database or CAD system that worked as composable units, like `echo db.sql | db-query "select username from accounts where credit < 0" | xargs delete-account` or `echo image.dxf | add-circle -x 200 -y 400 -r 60 > image.dxf` But you'd spend a lot of time reloading and reparsing the same files. A persistent monolith that keeps the data file open and in whatever internal representation is most efficient is going to perform better. Some use cases also have limited composability, because the user can only plan a few moves ahead. Tools that encourage interactive/experimental usage, like drafting software, might involve the user stopping every step or two to make sure they're staying on plan, and queuing up a series of commands could wreak havoc. Some of these packages ended up simulating composable tools through internal macro/scripting languages which still avoided the penalty of having to rely on the OS to orchestrate every single action.
pjmlp 2y ago
That would be Inferno, not Plan 9. COM is everywhere on Windows, specially since Vista, as the WinDev regained the control they thought Longhorn was going to take away from them. One of Powershell strengths is the easy access to COM, just like .NET, frameworks. Linux could do the same with D-Bus, but alas so is the distributions wars, and hate on anything like proprietary OSes, that it only has a minor role on systemd, GNOME and KDE.
- bboygravity 2y ago
  Intuitively this sounds like asking for dependency and API hell? Imagine writing a huge complex program that is dependent of communication between smaller existing programs. Either you use the default programs that where shipped with all the different versions of OS'es with different distro's (never going to work, too many different versions of programs and their communication interfaces) or you ship certain fixed versions of all of the small programs that form your bigger program. In case of the latter: why not just use libraries? It's basically the same thing with an easier API? Maybe I'm missing something...
  - pjmlp 2y ago
    Components are libraries, which aren't stuck in a C view of UNIX world.
  - Philip-J-Fry 2y ago
    These programs are effectively libraries. They implement a known interface. Except at the end of the day, the interface can be as simple as a stream of bytes over a socket. If I want a h264 decoder in my application I could just pipe a stream to a specific program made to decode it. That could be written in Python, in Rust, in C, in Go, etc. whereas dynamic libraries don't give you that freedom as you have to abide by the ABI defined by the host application.
  - mananaysiempre 2y ago
    A “program that is dependent on communication between smaller existing programs” is essentially the definition of a shell script, and those are usually not as problematic as your describe until you go out and try different independent implementations of the tools as opposed to mere versions. Compatibility problems definitely happen, but not as often as you seem to expect. I’d guess the trick is that you’re not thinking small enough. GNU coreutils, etc. are not minimal by any means, but compared with even late-90s graphical desktop software they are still fairly compact, and you’re rarely using each and every tool at once. And the smaller the tool and the problem it targets, the more likely it is that the problem is mostly a solved one, so interface churn is less necessary. I’m not sure every problem area is amenable to this—GUIs and things best expressed as GUIs seem particularly stubborn. (It would be sad if OLE/ActiveX was the best possible solution.) But some are, and few enough people are trying to expand the simplicity frontier for their real-world tasks in recent years that I don’t believe the state of the art of the 1980s is the farthest it can reach, either.
sillywalk 2y ago
Both KDE and GNOME started out with components. GNOME was originally the GNU Network Object Model Environment and KDE had KParts.

nrr 2y ago

The irony is that Acorn's RISC OS arguably came the closest to this ideal with any pragmatism. The way that file choosers worked effectively allowed one to pipe a saved file from one application to another and then do it again through the same workflow in the next application and so on.

foul 2y ago
This kind of IPC lurks in every major OS, drag to an app window is supported by Xorg Mac and Windows.
- nrr 2y ago
  I suppose this is IPC in the loosest possible sense? It's more like GetOpenFileName() and GetSaveFileName() in Win32 but getting handed a HANDLE outright instead of an LPCSTR to pass to CreateFile() later.

flomo 2y ago

Agreed. And one could argue that Unix wasn't really popular because of the "philosophy", but because it would get out of the way and let you run big monolithic applications like OracleDB or CAD software or even Emacs and etc. So no popular application using "Plan 9 philosophy" ever emerged.

linguae 2y ago
I agree, but I believe the fact there are no popular applications that fully embrace the Unix/Plan 9 philosophy is the point of the philosophy. Generic tools that can be composed versus end-to-end applications. Both have their advantages and disadvantages, though component-based software doesn’t preclude the development of end-to-end applications using these components. In my opinion I believe the reason end-to-end applications are dominant is because it’s easier for companies to sell and market products over tools. Part of the reason OpenDoc failed was because companies that made a living selling end-to-end applications (like Adobe) didn’t want to adopt component-based software where the product (application) isn’t the main focus. Imagine if users could construct their own Photoshop out of discrete elements.
- pjmlp 2y ago
  There were plenty of ActiveX lego components to build Photoshop like applications on Windows during the 1990's, back when buying libraries was a thing professionals would care about.
hakfoo 2y ago
I suspect the appeal of the Unix Philosophy is strongest at the earliest phases of the system's evolution. Once you've written some very basic boostrap tools, the "second generation" of stuff that adds convenience and flexibility are a lot simpler. A trivial example: 20 seconds after you wrote "directory listing", someone will say "I want a directory listing, but sorted by date, and it would be awesome if it didn't immediately scroll past the end of my screen." With Unix Philosophy tools, you might already have have a "sort" and "paginate" command, so it's just piping stuff together. They can do it themselves, or it will take 20 seconds to explain. Without it, you're going to have to add additional options to "directory listing" (or parallel commands) to handle the sorting and pagination features. The tools get bigger and buggier for the same functionality. Early Unix machines weren't much bigger than mid-80s PCs-- 512K of memory or less-- but offered a very rich command line experience compared with DOS machines of similar sizes. Programs like database or CAD packages probably go monolithic because they're more "state dependent" than your usual command-line tools. "sort" and "more" can take their inputs from stdin and feed them out to stdout, and when they're done, forget everything with no damage. That wouldn't work well for other packages. You could probably make a database or CAD system that worked as composable units, like `echo db.sql | db-query "select username from accounts where credit < 0" | xargs delete-account` or `echo image.dxf | add-circle -x 200 -y 400 -r 60 > image.dxf` But you'd spend a lot of time reloading and reparsing the same files. A persistent monolith that keeps the data file open and in whatever internal representation is most efficient is going to perform better. Some use cases also have limited composability, because the user can only plan a few moves ahead. Tools that encourage interactive/experimental usage, like drafting software, might involve the user stopping every step or two to make sure they're staying on plan, and queuing up a series of commands could wreak havoc. Some of these packages ended up simulating composable tools through internal macro/scripting languages which still avoided the penalty of having to rely on the OS to orchestrate every single action.

pjmlp 2y ago

That would be Inferno, not Plan 9. COM is everywhere on Windows, specially since Vista, as the WinDev regained the control they thought Longhorn was going to take away from them. One of Powershell strengths is the easy access to COM, just like .NET, frameworks. Linux could do the same with D-Bus, but alas so is the distributions wars, and hate on anything like proprietary OSes, that it only has a minor role on systemd, GNOME and KDE.

bboygravity 2y ago
Intuitively this sounds like asking for dependency and API hell? Imagine writing a huge complex program that is dependent of communication between smaller existing programs. Either you use the default programs that where shipped with all the different versions of OS'es with different distro's (never going to work, too many different versions of programs and their communication interfaces) or you ship certain fixed versions of all of the small programs that form your bigger program. In case of the latter: why not just use libraries? It's basically the same thing with an easier API? Maybe I'm missing something...
- pjmlp 2y ago
  Components are libraries, which aren't stuck in a C view of UNIX world.
- Philip-J-Fry 2y ago
  These programs are effectively libraries. They implement a known interface. Except at the end of the day, the interface can be as simple as a stream of bytes over a socket. If I want a h264 decoder in my application I could just pipe a stream to a specific program made to decode it. That could be written in Python, in Rust, in C, in Go, etc. whereas dynamic libraries don't give you that freedom as you have to abide by the ABI defined by the host application.
- mananaysiempre 2y ago
  A “program that is dependent on communication between smaller existing programs” is essentially the definition of a shell script, and those are usually not as problematic as your describe until you go out and try different independent implementations of the tools as opposed to mere versions. Compatibility problems definitely happen, but not as often as you seem to expect. I’d guess the trick is that you’re not thinking small enough. GNU coreutils, etc. are not minimal by any means, but compared with even late-90s graphical desktop software they are still fairly compact, and you’re rarely using each and every tool at once. And the smaller the tool and the problem it targets, the more likely it is that the problem is mostly a solved one, so interface churn is less necessary. I’m not sure every problem area is amenable to this—GUIs and things best expressed as GUIs seem particularly stubborn. (It would be sad if OLE/ActiveX was the best possible solution.) But some are, and few enough people are trying to expand the simplicity frontier for their real-world tasks in recent years that I don’t believe the state of the art of the 1980s is the farthest it can reach, either.

sillywalk 2y ago

Both KDE and GNOME started out with components. GNOME was originally the GNU Network Object Model Environment and KDE had KParts.