3 ms·

I wish L4 had taken off for general purpose computing. That and Plan9 are things I'd really like to try out but I don't have space to fit operating systems in a

I wish L4 had taken off for general purpose computing. That and Plan9 are things I'd really like to try out but I don't have space to fit operating systems in amongst the other projects. They both strike me as having the Unix nature, either "everything is messages in userspace processes" or "everything is a file."

jodrellblank 3y ago
I don't think I've ever seen an argument for why "everything is a file" is a desirable thing. It seems like a kitchen where "everything is a bowl". Fine when you want to eat cereal, mix a cake, do some handwashing up, store some fruit; tolerable when you want to bake a cake in the oven. Intolerable when you've got a carrot in a bowl-shaped chopping board and you've got to peel and cut it using a bowl. Why in principle should everything we do on computers behave and beshaped like a file?
- plagiarist 3y ago
  I don't think the metaphor applies because kitchen utensils' forms are dictated are their purpose, but software interfaces are abstractions. A fairer analogy would be if everything in the kitchen was bowl-shaped, but you could do bowl-like actions and get non-bowl behavior. Drop the carrot in the peelbowl and it is peeled, drop the carrot in the knifebowl and it is diced, drop the cubes in the stovebowl and they are cooked. Every manipulation is placing things in bowls. Every bowl is the same shape which means you can store them however is intuitive to you (instead of by shape).
  - jodrellblank 3y ago
    The counter would be that different tasks are different and that's why everything isn't bowl shaped. Analogously, programming languages which are strongly opinionated (purely functional, array-based, strictly static) are far less generally popular than programming languages which are multi-paradigm and flexibly typed. People have access to user-mode filesystems and FUSE, people could have made everything have a file-like interface by now if that was desirable - apparently it isn't. And because different tasks are different, it makes sense that they would fit different abstractions and interfaces, wouldn't it?
    - plagiarist 3y ago
      The function defines the shape of the kitchen utensil, yes. That's not a counter, those are physical objects. In software, we have far more flexibility as to what "shapes" are available. Having a common interface for working with things is indeed why the flexibly-typed languages are popular. Everything is an object. You call methods on every object in the same way. You don't need to figure out how to interact with the network card, someone has written a library to make that into objects. You don't need to figure out how to interact with a file system, someone has figured out to make that into objects. Bringing up popularity of programming languages is an argument in favor of "'everything is a file' is a useful abstraction." Either people will write FUSE plugins or they don't want consistent interfaces is a false dichotomy. When you are interacting with programs, you use mostly keyboards and mice. Why not create a bespoke hardware interactions for each program so they can behave more like kitchen utensils? Deleting a file is a different action than creating one, so I should have to shake my computer like an Etch-a-Sketch to delete images and rub the trackpad like an eraser to remove text files.
- baq 3y ago
  the file is inconsequential. it could be any other universal abstraction, e.g. HTTP POST. it's just something that every program running on a computer knows how to do, so why bother with special APIs you have to link against if you can just write to a file? (note you can still develop those layers if you wish, but you can also write a device driver in sh if you wish, because why not?)
  - thfuran 3y ago
    >the file is inconsequential. it could be any other universal abstraction Bad abstractions are notoriously problematic, and no abstraction is fit for every purpose.
    - PrimeMcFly 3y ago
      What are some ways the file abstraction has been problematic for Unix?
  - kybernetikos 3y ago
    So everything-is-a-file is a bit like REST - restrict the verbs, and move the complexity that causes into the addressing scheme and the clients.
- MisterTea 3y ago
  > I don't think I've ever seen an argument for why "everything is a file" is a desirable thing. A file system is a tree of named objects. These objects are seamlessly part of the OS and served by a program or kernel driver called a file server which can then be shared over a network. Security is then handled by file permissions so authentication is native through the system and not bolted on. It fits together very well and removes so much pointless code and mechanisms. A great example is a old uni demo where a system was built to control X10 outlets and switches (early home automation gear). Each device was a file in a directory tree that represents a building with sub directories for floors and rooms - e.g. 'cat /mnt/admin-building/2fl/rm201/lights' would return 'on' or 'off' (maybe it's a dimmer and its 0-255, or an r,g,b, value or w/e, sky's the limit, just put the logic in the fs). To change the state of the lights you just echo off >/mnt/admin-building/2fl/rm201/lights. Now you can make a script that shuts all the lights off in the building by walking directories and looking for "lights" then writing off to those files. Maybe it's a stage, all your lights are on DMX and you like the current settings so then you 'tar -c /mnt/auditorium/stage/lighting|gzip >student_orientation_lighting_preset.tar.gz' and do the reverse over-writing all the archived settings back to their respective files. You could even serve those files over smb to a windows machine and turn lights on and off using notepad or whatever. And the file data doesn't have to be text, it could be binary too. It's just that for some things like the state of lights, temperature or w/e can easily be stored and retrieved as human readable text. That is the beauty and power of 9p - its removes protocol barriers and hands you named objects seamlessly integrated into your OS which you can read/write using regular every day tools. It's a shame so many people can't grasp it.
  - jodrellblank 3y ago
    I like the example and the detailed explanation but "it works in some scenarios" is only enough to say that some things work well as files, it's not enough to convince that everything should be a file (or that everything should be the same, whatever the same is). > "sky's the limit, just put the logic in the fs" You can, but why is it better to do that? "just" put the logic in a Python script seems much simpler than putting it in a low level pretend filesystem driver, on the other side of an arbitrary interface you had to come up with to satisfy an ideology that everything should have to go through this interface, right? Over Christmas I set some LED displays running, controlled by an RS-232 serial port. It would be possible to echo a line of text to a pretend filename and have it appear on the sign, but there is a command for whether the text is static or scrolling and one for whether the text appears on the top line or bottom line. That information has to be somewhere, either as different paths in the filesystem e.g. /mnt/sign/static/row/top vs /mnt/sign/scrolling/row/top or as formatted content inside the file, or both. There's a command to change the colour of the subsequent text, which can be used anywhere in the message, many times over - so that can't easily go in the filesystem path so now there needs to be some intermediate structure which both the shell script and the filesystem driver speak, to be able to pass this command through the file interface. With a COM port in Windows, if one script opens it and another script tries to open it then there's a clear error that the port is in use. If a usermode filesystem driver held the com port open, what would happen if two scripts tried to write to these files? Does one get a mysterious "write failed" filesystem error to catch and debug instead of a proper relevant error message? Do they have to proxy error messages through /mnt/sign/meta/error ? This is one of the most trivial things a computer can do, sending a short text, which is possible with echoing to a com port /dev/ttyS0, and the abstraction idea of making it a file is already creaking under the weight of the task, adding the burden of arbitrary path decisions and data formatting and task-specific escape codes and control sequences, and bodgy-error handling, while assisting with basically nothing - while you can find /mnt/* you get no help with that, no link to any documentation, no further discovery, no interactivity like you get from a command line binary program interface. Much much easier to put the sign's commands directly in a short Python script, isn't it? And other more complex tasks just get more and more intense, as the "plain text" files in /etc/ are an ad-hoc mix of formats and data types and parsing rules and symbolic links to /opt/ and other random places. As I say in another comment, usermode filesystems never became the default or popular way to do things, why not?

jodrellblank 3y ago

I don't think I've ever seen an argument for why "everything is a file" is a desirable thing. It seems like a kitchen where "everything is a bowl". Fine when you want to eat cereal, mix a cake, do some handwashing up, store some fruit; tolerable when you want to bake a cake in the oven. Intolerable when you've got a carrot in a bowl-shaped chopping board and you've got to peel and cut it using a bowl. Why in principle should everything we do on computers behave and beshaped like a file?

plagiarist 3y ago
I don't think the metaphor applies because kitchen utensils' forms are dictated are their purpose, but software interfaces are abstractions. A fairer analogy would be if everything in the kitchen was bowl-shaped, but you could do bowl-like actions and get non-bowl behavior. Drop the carrot in the peelbowl and it is peeled, drop the carrot in the knifebowl and it is diced, drop the cubes in the stovebowl and they are cooked. Every manipulation is placing things in bowls. Every bowl is the same shape which means you can store them however is intuitive to you (instead of by shape).
- jodrellblank 3y ago
  The counter would be that different tasks are different and that's why everything isn't bowl shaped. Analogously, programming languages which are strongly opinionated (purely functional, array-based, strictly static) are far less generally popular than programming languages which are multi-paradigm and flexibly typed. People have access to user-mode filesystems and FUSE, people could have made everything have a file-like interface by now if that was desirable - apparently it isn't. And because different tasks are different, it makes sense that they would fit different abstractions and interfaces, wouldn't it?
  - plagiarist 3y ago
    The function defines the shape of the kitchen utensil, yes. That's not a counter, those are physical objects. In software, we have far more flexibility as to what "shapes" are available. Having a common interface for working with things is indeed why the flexibly-typed languages are popular. Everything is an object. You call methods on every object in the same way. You don't need to figure out how to interact with the network card, someone has written a library to make that into objects. You don't need to figure out how to interact with a file system, someone has figured out to make that into objects. Bringing up popularity of programming languages is an argument in favor of "'everything is a file' is a useful abstraction." Either people will write FUSE plugins or they don't want consistent interfaces is a false dichotomy. When you are interacting with programs, you use mostly keyboards and mice. Why not create a bespoke hardware interactions for each program so they can behave more like kitchen utensils? Deleting a file is a different action than creating one, so I should have to shake my computer like an Etch-a-Sketch to delete images and rub the trackpad like an eraser to remove text files.
baq 3y ago
the file is inconsequential. it could be any other universal abstraction, e.g. HTTP POST. it's just something that every program running on a computer knows how to do, so why bother with special APIs you have to link against if you can just write to a file? (note you can still develop those layers if you wish, but you can also write a device driver in sh if you wish, because why not?)
- thfuran 3y ago
  >the file is inconsequential. it could be any other universal abstraction Bad abstractions are notoriously problematic, and no abstraction is fit for every purpose.
  - PrimeMcFly 3y ago
    What are some ways the file abstraction has been problematic for Unix?
- kybernetikos 3y ago
  So everything-is-a-file is a bit like REST - restrict the verbs, and move the complexity that causes into the addressing scheme and the clients.
MisterTea 3y ago
> I don't think I've ever seen an argument for why "everything is a file" is a desirable thing. A file system is a tree of named objects. These objects are seamlessly part of the OS and served by a program or kernel driver called a file server which can then be shared over a network. Security is then handled by file permissions so authentication is native through the system and not bolted on. It fits together very well and removes so much pointless code and mechanisms. A great example is a old uni demo where a system was built to control X10 outlets and switches (early home automation gear). Each device was a file in a directory tree that represents a building with sub directories for floors and rooms - e.g. 'cat /mnt/admin-building/2fl/rm201/lights' would return 'on' or 'off' (maybe it's a dimmer and its 0-255, or an r,g,b, value or w/e, sky's the limit, just put the logic in the fs). To change the state of the lights you just echo off >/mnt/admin-building/2fl/rm201/lights. Now you can make a script that shuts all the lights off in the building by walking directories and looking for "lights" then writing off to those files. Maybe it's a stage, all your lights are on DMX and you like the current settings so then you 'tar -c /mnt/auditorium/stage/lighting|gzip >student_orientation_lighting_preset.tar.gz' and do the reverse over-writing all the archived settings back to their respective files. You could even serve those files over smb to a windows machine and turn lights on and off using notepad or whatever. And the file data doesn't have to be text, it could be binary too. It's just that for some things like the state of lights, temperature or w/e can easily be stored and retrieved as human readable text. That is the beauty and power of 9p - its removes protocol barriers and hands you named objects seamlessly integrated into your OS which you can read/write using regular every day tools. It's a shame so many people can't grasp it.
- jodrellblank 3y ago
  I like the example and the detailed explanation but "it works in some scenarios" is only enough to say that some things work well as files, it's not enough to convince that everything should be a file (or that everything should be the same, whatever the same is). > "sky's the limit, just put the logic in the fs" You can, but why is it better to do that? "just" put the logic in a Python script seems much simpler than putting it in a low level pretend filesystem driver, on the other side of an arbitrary interface you had to come up with to satisfy an ideology that everything should have to go through this interface, right? Over Christmas I set some LED displays running, controlled by an RS-232 serial port. It would be possible to echo a line of text to a pretend filename and have it appear on the sign, but there is a command for whether the text is static or scrolling and one for whether the text appears on the top line or bottom line. That information has to be somewhere, either as different paths in the filesystem e.g. /mnt/sign/static/row/top vs /mnt/sign/scrolling/row/top or as formatted content inside the file, or both. There's a command to change the colour of the subsequent text, which can be used anywhere in the message, many times over - so that can't easily go in the filesystem path so now there needs to be some intermediate structure which both the shell script and the filesystem driver speak, to be able to pass this command through the file interface. With a COM port in Windows, if one script opens it and another script tries to open it then there's a clear error that the port is in use. If a usermode filesystem driver held the com port open, what would happen if two scripts tried to write to these files? Does one get a mysterious "write failed" filesystem error to catch and debug instead of a proper relevant error message? Do they have to proxy error messages through /mnt/sign/meta/error ? This is one of the most trivial things a computer can do, sending a short text, which is possible with echoing to a com port /dev/ttyS0, and the abstraction idea of making it a file is already creaking under the weight of the task, adding the burden of arbitrary path decisions and data formatting and task-specific escape codes and control sequences, and bodgy-error handling, while assisting with basically nothing - while you can find /mnt/* you get no help with that, no link to any documentation, no further discovery, no interactivity like you get from a command line binary program interface. Much much easier to put the sign's commands directly in a short Python script, isn't it? And other more complex tasks just get more and more intense, as the "plain text" files in /etc/ are an ad-hoc mix of formats and data types and parsing rules and symbolic links to /opt/ and other random places. As I say in another comment, usermode filesystems never became the default or popular way to do things, why not?