8 ms·

The Readme says that things such as network interface is abstracted as files, but isn't Linux the same way?

stonogo 3y ago
It isn't. A network interface on linux is a special creature, traditionally named something like eth0, and it doesn't appear in a filesystem. You have to use tools like ip to interact with it.
- hulitu 3y ago
  > a special creature, traditionally named something like eth0, and it doesn't appear in a filesystem. /dev/eth0 ?
  - MobiusHorizons 3y ago
    If you have one that corresponds to each of the network devices that show up in ip, that is unusual in my ~15y of Linux experience. The other half of the argument above is that even when such devices exist there is a lot of configuration for the device that uses ioctl to put it in the correct mode. Very little of the code treats that device as something to read from or write to.
  - justeleblanc 3y ago
    $ ip addr show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:15:5d:23:d8:89 brd ff:ff:ff:ff:ff:ff inet 172.27.50.201/20 brd 172.27.63.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::215:5dff:fe23:d889/64 scope link valid_lft forever preferred_lft forever $ ls /dev/eth0 ls: cannot access '/dev/eth0': No such file or directory And besides, what would it even mean for eth0 to "be" a file? What happens when you try to read it, what happens when you write to it?
    - stonogo 3y ago
      In Inferno (and Plan 9) it appears that network devices are filesystems -- e.g. there's a /net/ether0 directory which contains files with access semantics corresponding to various configuration and throughput tasks. I've read that it's even possible to 'mount' a remote network device on top of a local one, effectively tunneling traffic through the remote system. It's an interesting concept but I'm not sure of its utility, having never really used it.
interroboink 3y ago
Linux isn't quite the same way, no. Though over the years, it is true that Linux has incorporated various Plan9 concepts (Plan9 is the progenitor of Inferno, roughly). In Linux, you often use sockets to communicate over the network, perhaps with sendmsg[1] to send data. On Inferno (as I understand it), everything is done via the standard filesystem operations of open/read/write/close. And that includes everything on the system - printers, mouse+keyboard, even the entire windowing system. [1] https://linux.die.net/man/2/sendmsg https://linux.die.net/man/2/sendmsg
drpixie 3y ago
It is - until you want to do something interesting, then it's all ioctl(), recv(), and the various gather calls! I'd like to see an OS that drops the concept of files. Files are very low level (generally a stream of bytes) - the app has to interpret it as config, or data, etc "manually". An OS should be providing higher-level data management, and insisting that is what is used. (And please not SQL. It's only a little higher level that raw data, and has serious interface problems that permit prompt injection ... the db equivalent of buffer overflows.)
- MobiusHorizons 3y ago
  The purpose of a good primitive is that it can be cleanly composed. Both files and streams of bytes have these properties, because the primitive allows code written by different people / teams / orgs to interact due to the common primitives. The higher level your primitives, the larger your api surface, and the less likely they are to be composable. Do you really want that? I certainly don’t.
- Technotroll 3y ago
  > An OS should be providing higher-level data management, and insisting that is what is used. This assertion seems normative. Could you please expand upon how higher-level data management improve the overall performance and efficiency of the system? Or could you point me in the direction of some good sources? Also what are the benefits of an OS providing higher-level data management instead of relying on lower-level data management solutions? Doesn't abstraction lead to less fine control? That is to say, how does insisting on using higher-level data management provided by an OS affect the development and maintenance of applications? I've seen some object-centric systems adopt this approach and find it very interesting.
  - drpixie 3y ago
    You seem to be answering your own questions :) Of course, "abstraction lead[s] to less fine control" - at the the lowest (assembly) level, you can do almost anything - and make all the mistakes imaginable. Sometimes you want to genuinely maximise performance, or do things otherwise difficult - fine, use assembly and hit the hardware. But most of the time, software is made to be read, to be trouble free, to build on other's work, and to be written easily - that's when abstraction is valuable.
kragen 3y ago
no, in inferno or plan9, if a fileserver exports the part of its filesystem that contains its network interface, you can mount that on your filesystem and use its network interface. instant vpn! (except 9p isn't encrypted, oops) the plan9 window system also worked this way, so you could access a window on someone else's display if you mounted it locally; this was how you would run a graphical program on a remote server, by mounting your desktop display in its container on the remote server linux is not like this at all; you have to use separate protocols for graphics, vpning, and filesharing
- zamnos 3y ago
  > except 9p isn't encrypted, oops could you somehow mount or pipe the openssl library on top of the network interface via a helper program and then access it that way to encrypt it?
  - jacquesm 3y ago
    In a word: yes, that's the essence of this system.
    - deleted 3y ago
      [deleted]
- afunctionof 3y ago
  Do you have any plans on making a Rio clone for yeso? Also, unrelated, do you have any advice for a very short-sighted and poorly thought out move to Argentina, assuming the person you're talking to is completely set on it?
  - kragen 3y ago
    (cf. https://news.ycombinator.com/item?id=35693474 https://news.ycombinator.com/item?id=35693474 for the response; unfortunately the parent comment was flagged at the time i wrote it)
unixhero 3y ago
It was. Now we have systemd, and there are magical kernel subsystems which you don't always see anywhere represented as a file.

It isn't. A network interface on linux is a special creature, traditionally named something like eth0, and it doesn't appear in a filesystem. You have to use tools like ip to interact with it.

hulitu 3y ago
> a special creature, traditionally named something like eth0, and it doesn't appear in a filesystem. /dev/eth0 ?
- MobiusHorizons 3y ago
  If you have one that corresponds to each of the network devices that show up in ip, that is unusual in my ~15y of Linux experience. The other half of the argument above is that even when such devices exist there is a lot of configuration for the device that uses ioctl to put it in the correct mode. Very little of the code treats that device as something to read from or write to.
- justeleblanc 3y ago
  $ ip addr show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:15:5d:23:d8:89 brd ff:ff:ff:ff:ff:ff inet 172.27.50.201/20 brd 172.27.63.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::215:5dff:fe23:d889/64 scope link valid_lft forever preferred_lft forever $ ls /dev/eth0 ls: cannot access '/dev/eth0': No such file or directory And besides, what would it even mean for eth0 to "be" a file? What happens when you try to read it, what happens when you write to it?
  - stonogo 3y ago
    In Inferno (and Plan 9) it appears that network devices are filesystems -- e.g. there's a /net/ether0 directory which contains files with access semantics corresponding to various configuration and throughput tasks. I've read that it's even possible to 'mount' a remote network device on top of a local one, effectively tunneling traffic through the remote system. It's an interesting concept but I'm not sure of its utility, having never really used it.

interroboink 3y ago

Linux isn't quite the same way, no. Though over the years, it is true that Linux has incorporated various Plan9 concepts (Plan9 is the progenitor of Inferno, roughly). In Linux, you often use sockets to communicate over the network, perhaps with sendmsg[1] to send data. On Inferno (as I understand it), everything is done via the standard filesystem operations of open/read/write/close. And that includes everything on the system - printers, mouse+keyboard, even the entire windowing system. [1] https://linux.die.net/man/2/sendmsg https://linux.die.net/man/2/sendmsg

drpixie 3y ago

It is - until you want to do something interesting, then it's all ioctl(), recv(), and the various gather calls! I'd like to see an OS that drops the concept of files. Files are very low level (generally a stream of bytes) - the app has to interpret it as config, or data, etc "manually". An OS should be providing higher-level data management, and insisting that is what is used. (And please not SQL. It's only a little higher level that raw data, and has serious interface problems that permit prompt injection ... the db equivalent of buffer overflows.)

MobiusHorizons 3y ago
The purpose of a good primitive is that it can be cleanly composed. Both files and streams of bytes have these properties, because the primitive allows code written by different people / teams / orgs to interact due to the common primitives. The higher level your primitives, the larger your api surface, and the less likely they are to be composable. Do you really want that? I certainly don’t.
Technotroll 3y ago
> An OS should be providing higher-level data management, and insisting that is what is used. This assertion seems normative. Could you please expand upon how higher-level data management improve the overall performance and efficiency of the system? Or could you point me in the direction of some good sources? Also what are the benefits of an OS providing higher-level data management instead of relying on lower-level data management solutions? Doesn't abstraction lead to less fine control? That is to say, how does insisting on using higher-level data management provided by an OS affect the development and maintenance of applications? I've seen some object-centric systems adopt this approach and find it very interesting.
- drpixie 3y ago
  You seem to be answering your own questions :) Of course, "abstraction lead[s] to less fine control" - at the the lowest (assembly) level, you can do almost anything - and make all the mistakes imaginable. Sometimes you want to genuinely maximise performance, or do things otherwise difficult - fine, use assembly and hit the hardware. But most of the time, software is made to be read, to be trouble free, to build on other's work, and to be written easily - that's when abstraction is valuable.

kragen 3y ago

no, in inferno or plan9, if a fileserver exports the part of its filesystem that contains its network interface, you can mount that on your filesystem and use its network interface. instant vpn! (except 9p isn't encrypted, oops) the plan9 window system also worked this way, so you could access a window on someone else's display if you mounted it locally; this was how you would run a graphical program on a remote server, by mounting your desktop display in its container on the remote server linux is not like this at all; you have to use separate protocols for graphics, vpning, and filesharing

zamnos 3y ago
> except 9p isn't encrypted, oops could you somehow mount or pipe the openssl library on top of the network interface via a helper program and then access it that way to encrypt it?
- jacquesm 3y ago
  In a word: yes, that's the essence of this system.
  - deleted 3y ago
    [deleted]
afunctionof 3y ago
Do you have any plans on making a Rio clone for yeso? Also, unrelated, do you have any advice for a very short-sighted and poorly thought out move to Argentina, assuming the person you're talking to is completely set on it?
- kragen 3y ago
  (cf. https://news.ycombinator.com/item?id=35693474 https://news.ycombinator.com/item?id=35693474 for the response; unfortunately the parent comment was flagged at the time i wrote it)

unixhero 3y ago

It was. Now we have systemd, and there are magical kernel subsystems which you don't always see anywhere represented as a file.