Re-Imagineering Unix

Oluseyi Sonaiya · 2003-07-10T00:20:22

Reapplying the Unix Philosophy I think that the 9 Tenets of the Unix Philosophy by Mike Gancarz and a brief exposition of the nine tenets, as well as the ten lesser tenets are solid principles for the design and implementation of software in general and operating systems in particular. Today we encounter more and more accusations of Unix not being "user-friendly" or being "difficult"; while Unix enthusiasts generally shrug of such comments with disdain, pointing to the simple elegance of the system and the power it provides, how can we fundamentally improve Unix? How can we maintain its power and expressiveness while making it easier to use? No, just throwing a GUI on top is not enough. GUI and CLI Inadequacy The big flaw of the graphical user interface is that it leads to the construction of applications with captive user interfaces and a lot of code redundancy. In addition, no one so far has been able to conceive an intuitive way to string GUI applications together to create powerful custom tools the way we can with CLI utilities. The big flaw of the command-line interface, OTOH, is that unless you already know what they do or where to look for documentation, you''re screwed. GUIs can take advantage of exploration and recognition to make themselves more usable while CLIs can''t. Is the solution to make GUI tools front ends to CLI utilities? To supposedly get the "best of both worlds" by making applications usable in multiple modalities? I don''t think so. Concept: Micro-Services CLI utilities fall into two categories in terms of their data input and output properties: generators and filters. A utility that "consumes" data - accepts input and generates no output - is a virus. Utilities that we are all familiar with include ls, cp, rm and find. I''ve been wondering whether it is not possible to convert the vast majority of system utilities, and even many third-party utes, into "micro-services" - headless applets of a System daemon that perform the core processing and return results to whatever application is requesting them. CLI and GUI utilities alike would use the same processing, meaning that less code - including glue - would need to be written for each of them (we''ll get to revamping CLIs and GUIs themselves in a sec). As an example, CLI ls would simply pass the filename pattern to System:ls and display the results while a GUI filebrowser would do the same, but then render icons or fill out detail tables based on the data returned (System:ls would return a pair of unordered lists of files and directories respectively by default, but could be instructed to return more information). Thus, the interface tool focuses on interfacing while the functionality is made a system-accessible service of sorts. Any other application that seeks to obtain a list of files simply makes a request to System:ls. Now how is this better than calling an API function? The invocation mechanism is the same whether you''re calling System:ls, System:cp or Oluseyi:Discombobulate - akin to a network send/recv session - and thus there''s no special libraries or binding involved. Furthermore, applications would be able to direct one microservice to pass its output to another microservice, thus emulating the commandline''s piping and redirection features whether in CLI or GUI apps (less of a big deal for CLIs, but fairly significant IMO for GUIs). Concept: I/O Abstraction The concept here is that almost every application needs to perform some kind of file I/O sooner or later; the more applications you have that can read and write the same file format (except for plain text), the more copies of functionally equivalent code you have on your disk. Data falls in relatively few categories (one of which is a hedge, basically for "unclassifiable" data): Text, Image, Audio, Video and Application - the basic MIME types. By structuring I/O hierarchically underneath these headings - thus obtaining text/plain, text/html, text/xml, audio/mp3, audio/ogg, video/divx, video/mpeg4, image/gif, image/png and so forth - it is conceptually possible to create a system where applications deal with the high-level type (eg Image) and system codecs deal with converting from a specific format (eg image/png) to the high-level type. The upsides of such a system are 1) less identical or functionally equivalent code on your system, which can be telling when totalled; and 2) the addition of a codec can potentially allow all applications that deal with the associated high-level type to read the specific format - adding a PNG codec means that Adobe PhotoShop, Internet Explorer, Microsoft Word, MS Paint and all other apps that render and/or write images (using Windows examples) can now read and write PNGs. Essentially, I/O becomes another system API or shell script that everyone can use in developing their app, and continue to gain from even after their app is shipped. Developers no longer need to focus on inanities like supporting obscure formats, and users can use their favorite editor with their favorite format even if the editor''s developer didn''t support the format by adding a codec to their system as a whole. Concept: GUI Assembly Taking a page from graphical flow process tools like National Instruments various instrumentation lab simulators and coupling with the micro-service concept (especially when our micro-services return structured information about themselves upon request), a GUI app could be written that allows for the rapid graphical construction of CLI-style piping and redirection-laden custom tools/utilities. It''s not as efficient as the real thing, but it allows users unfamiliar with the system to reap many of the same functionality benefits even if they don''t do it at the same speed as CLI wizards. These aren''t very concrete ideas, but I just wanted to share and see what others think or come up with.

Everything Unix Technical

Started by Oluseyi July 02, 2003 01:11 AM

22 comments, last by Oluseyi 21 years, 7 months ago

SabreMan

504

July 03, 2003 11:04 AM

quote:
Original post by CoffeeMug
OLE is an old (about 1994) term for COM (Component Object Model).

No it isn''t. OLE is built on top of COM, and comprises a bunch of COM interfaces that components must implement in order to be linkable and embeddable. OLE is more like an old term for ActiveX, which has now evolved into dotNet.

CpMan

532

July 03, 2003 02:02 PM

.NET holds an interesting prospect for scripting. Since it includes, natively, a couple of languages (VB and Jscript.NET that I know of) with bindings to all .NET languages, and the scripts are JIT''d, any application that wishes to script their components can, and very easily. Say I have a C# program that has a bunch of functionality, but I want to be able to manipulate it through scripts. I build my C# program and provide simple (it''s not more than 25 lines of code) for running a script. I add references in a given script to my C# assembly, perhaps a few more .NET assemblies, and there I have it, fulyly scriptable. It doesn''t get much simpler than that.

Gamedev for learning.
libGDN for putting it all together.
An opensource, cross platform, cross API game development library.

VSEDebug Visual Studio.NET Add-In. Enhances debugging in ways never thought possible.

CoffeeMug

852

July 03, 2003 04:18 PM

quote:
Original post by SabreMan
OLE is built on top of COM, and comprises a bunch of COM interfaces that components must implement in order to be linkable and embeddable. OLE is more like an old term for ActiveX, which has now evolved into dotNet.

Yes, OLE and ActiveX can be used interchangably. However, as you said above OLE is based on COM and according to Eller (he was responsible for MS systems group at some point, forgot his first name) Microsoft decided to drop marketing OLE (and ActiveX) in favor of marketing the underlying technology - COM. You're correct though, my statement that OLE and COM can be used interchangably was misleading. Sorry about that.

[edited by - CoffeeMug on July 3, 2003 5:20:13 PM]

defmacro.org

Shannon Barber

1,684

July 10, 2003 12:20 AM

quote:
Original post by Flarelocke
Why doesn''t anyone on windows actually use OLE (besides Microsoft, of course) already? As you say, the advantages are obvious with Office.

Or do they and just never tell me about it?

COM is the next-generation of OLE - everyone uses it. (and .Net the next-generation there-after-that).

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

Re-Imagineering Unix

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Re-Imagineering Unix

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines