Some places where I think that Unix is incomplete or imperfect

January 25, 2013

A commentator on Unix needs to grow asked for some examples of what I had in mind and, well, the resulting comment got away from me.

This is a very incomplete list written off the top of my head (and is in no particular order). All of these issues are from the perspective of 'traditional Unix', the Unix on static servers that most everyone agrees is more or less fully Unixy. While modern Unixes have dealt with a number of them it's often not in ways that people really think are Unixy, so I consider them open problems that still need work.

  • hotplug hardware (on basically everything), including issues like how /dev entries for new devices show up.

  • on multi-user workstations (and then desktops), making it so that only the user on the console could use various bits of local hardware like the audio device. Pranking people by ssh'ing in to their workstation and then playing loud music is all well and good, but let's not.

    (A genuine multi-head environment makes this even less clear.)

  • allowing the console user to access things like CD-ROMs, DVDs, USB memory sticks, and so on that they plug in to the hardware. Even apart from the inconvenience, 'su to root and run mount' is not a viable answer because in a multi-user workstation environment the console user may not have the root password. This needs to be controllable (some environments don't want to allow this) and is made more complicated because there are many different sorts of access that are needed beyond just mounting a filesystem (eg burning a DVD).

  • dealing with the variable networking environment that a laptop or other mobile device sees as it moves around. Again, 'su to root' is a terrible answer here. This is more than just basic changes in network devices, IP addresses, and so on; it ripples through into user programs, DNS resolution, and any number of other areas.
  • in general, handling various sorts of 'on-demand' and transient network connections.

  • suspending and unsuspending machines, especially since there are often user-space things you want to do both on suspend and on unsuspend. This used to be just a laptop issue but is now also interesting for things like virtual machines.

  • many aspects of networking in general. For example, what is a Unixy approach to firewalling, NAT, and so on, or does Unix have nothing to say about the right way to approach this? What is the right Unixy API for programs to use the network?

    (Note that the Bell Labs answer to this looks nothing like the BSD sockets API.)

  • password and key management at both the system and user layer. This is especially important if encrypted filesystems start becoming pervasive. Current solutions are ad-hoc large blobs (Plan 9 had some ideas here). This interacts with things like networking, especially on shared machines; if you hand your laptop to your friend to use temporarily (with a guest account or a just-created account), you probably don't want them to be able to bring up your VPN connection to work.

  • coordinating system and user choices for things like 'how do you view a web page' or 'what shows pictures'.
  • can you make a general (program) configuration and options system that feels Unixy and is easily manipulated in a Unixy way, or are we doomed to things that look uncannily like the Windows registry?

    (I sure hope the answer is not 'yes'. Note that dotfiles are not the answer; they are ad-hoc single program solutions.)

  • general structured interprocess communication. Many of the other problems involve programs learning about changes to the world or telling the world about changes and some of them have programs talking to other programs. They can all do this in a giant anarchy of program and problem specific mechanisms, but shouldn't there be some more general, more Unixy approach to the whole issue? Ideally one that made it easy to write little programs and shell scripts that plugged into the whole system.

  • how do you process structured data in Unix pipelines and store it in 'flat' text files? Are there general mechanisms or conventions that Unix should adopt or are we doomed to a bunch of ad-hoc solutions for specific problems (such as 'a grep for json')?

  • the graphical environment equivalent of the shell and shell scripts.

  • what I called a good Unix glue language, something that is better than shell scripts for what shell scripts are good for while feeling right and being just as convenient. A better shell is not necessarily the right model for this.

  • fair share resource allocation on multi-user or multi-use machines.

  • a better permissions and restrictions model. It's become obvious that the current basic Unix model of separating and confining things by UID is not a great fit for the modern world, especially with the current set of Unix access restrictions. What is a better Unixy way to both confine processes and to give them extra permissions?

    (For example, it's absurd that you must run Apache as root in order for it to bind to port 80 and 443 and equally absurd that Apache needs to either keep root permissions or run all CGIs/etc as the same UID that is running the main web server.)

    A really well done system would allow programs to take advantage of this for handling things that they want access restricted. For example, it would be nice if the printing system didn't need its own ad-hoc private system for managing who can manipulate particular printer queues.

  • integrating Unix machines in clusters and other larger network systems. My view is that none of the existing components really feel all that Unixy (NIS, LDAP, automounter, etc).

  • if one of the big Unix ways of handling things is 'virtual filesystems', Unix needs to make them easier. Plan 9 argues that you can do a lot with very Unixy results but also that you need a way to make them accessible to users in order to tap their full power. What does a Plan 9 like approach look like on Unix, if it can be made to work at all? How do you integrate user-owned, user-mounted filesystems with the Unix permissions model and also not make a multi-user system explode when everyone is mounting flaky filesystems?

  • /tmp on multi-user machines. This could be an entire entry by itself but /tmp is both a source of problems and a useful feature. How do you get rid of the problems while keeping the good stuff?

  • what is the Unixy way to handle disk storage feature sets like ZFS and btrfs? The current approach is to shove everything from RAID on up into one huge blob, which is not really the traditional Unix way. Does Unix need some sort of fundamental shift in the underlying model of how filesystems interact with disk storage, one that will enable splitting ZFS, btrfs, etc up into nice logical multi-layered things?

    (This is more than just ZFS/btrfs. For example, I haven't seen a logical volume management system that actually feels Unixy.)

Many of these are large, abstract problems. I don't think any of them have easy or obvious answers; for some of them it's not even clear how you'd start dealing with the problem or if it's actually possible to have a 'Unixy' solution. Where current Unix systems deal with these, people often find the answers unsatisfying and non-Unixy (as I mentioned).


Comments on this page:

From 216.16.225.194 at 2013-01-25 20:06:48:

I have questions about points 2 and 3. For instance, why can't I use ssh to remote control a media player? And how do you differentiate between local and non-local hardware? Eg, can I ssh into a machine and access an external drive that's mounted via a thunderbolt connection?

Can an administrator configure what can be accessed from where? If so, how do you make that relatively simple?

By cks at 2013-01-25 20:20:23:

There are policy and general questions tied up in many of these; I don't pretend to have the answers to them.

For the audio device issue, it's clear that the traditional Unix model of static ownership and permissions (where you and I have constant group memberships and a device has a fixed group and permissions) simply doesn't allow for a situation where both you and I can log in to the console and have access to the audio device but not have access to the audio device while we are ssh'd in and the other person is on the console. Somehow you need a mechanism for dynamically granting and revoking audio access based on who is logged in on the console.

(Once you have that mechanism you can build many policies on top of it, including more liberal ones.)

From 213.47.133.111 at 2013-02-05 05:57:48:

You should write down what Unixy really means to you, on a detailed level, and what is just an implementation detail of a Unix you like.

Having that, evaluate what a typical installation of a current 'Unix' provides. Many of the items on your list have been solved one way or another (esp. the console user permission/policy issues), but it's not clear whether the current implementations are Unixy to you, or if not, why not.

-C

By cks at 2013-02-05 10:35:16:

I don't think very many people have that clear a vision of what Unix is to them; certainly I don't. Unixness is something that I know when I see it and to some degree that I become persuaded of over time because some bit seems to fit in well with other bits.

Written on 25 January 2013.
« Unix needs to grow and a consequence of that
User mode servers versus kernel mode servers »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Fri Jan 25 12:04:43 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.