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.)
The IBM System/38 and its descendants (AS/400 which was renamed to iSeries, then i5, now just the horribly unsearchable IBM i) sort of did/does this, except 'newer things' ported over like modern web stuff generally use the Unix portability layer, so it's not enforced. Also, it has a SQL database built-in at the OS level..
The original/legacy OS is quite interesting and high level. It's Object Based. You can only use the objects built-in methods e.g. you can't WRITE arbitrary bytes to an Application object, or a User Object. They are accessed as a giant Single address space, and whether they are on disk or in RAM is transparent to higher layers, i.e. if an object isn't in ram it will page it in..
The designer of System/38 etc. Frank Soltis wrote a couple of interesting books on it - Inside The AS/400 and its 2nd edition Fortress Rochester: Inside the iSeries. They're out of print and expensive unfortunately, I wish I hadn't gave my copy away.
> It is - until you want to do something interesting, then it's all ioctl(), recv(), and the various gather calls!
Indeed, Plan9 and inferno don't have ioctls. For special operations ("control"), there is often a file named "ctl" to which you can write commands. So you open the file, write some text, see if the write succeeds, and close the file. E.g. to make a tcp connection, to flush a write buffer to disk, etc. The commands are typically just plain ascii. That's easy for scripting and there is no need to import C struct types into that new programming language you are using/developing. Of course, the commands have to be parsed (for kernel devices, this happens in the kernel), typically done with some simple tokenization functions. When the commands become complicated, you could still choose to write binary data, or even straight C structs...
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.
> 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.
I think the OS should begin with a lower level abstraction - object capabilities, and build out from there.
Rather than a loss of control, capabilities enable fine-grained control over authorization, because a capability is both designates a resource and provides authority to use it.
But pathnames are not useful as capabilities, because they can be easily forged. So at best a pathname could serve to discover resources for which you could then request a capability to access.
Windows does not have the kind of capabilities I'm referring to.
With proper capabilities, the capability itself provides the authority. There's no need to have separate access control lists or some kind of central resource broker. Each process manages its own capabilities, can create new capabilities and can delegate them to others. And importantly, capabilities can always be revoked, at any time.
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.
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
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?
in response to the unfortunately flagged sibling comment, the planned vaguely-rio-like windowing system for yeso is called wercam, but there is only a prototype implementation of it in the repo so far
i decided that probably write() and read() is not a good way to send a large volume of pixels to the display hardware because, say, 2048×1080 32bpp at 60Hz is 530 megabytes a second, and that's a significant fraction of typical bandwidths to main memory, so it is important to strictly minimize the number of memory copies. indeed, even today, i think this is a primary driving concern in the design of usably efficient graphics systems
if you write() some pixel data to a socket, the semantics of write() imply that you can overwrite it (for example with the next frame) as soon as write() returns; and the semantics of read() mean that the pixel data read from the socket by the display server needs to get put in the display server's memory space at a buffer aligned where the display server allocated the buffer. moreover, if the pixel data is intermixed in the same byte stream with control and framing data (such as the w×h dimensions of the following chunk of pixel data, for example) that will also tend to misalign it
so wercam allocates the pixel data in shared memory, on unix in the form of a memory-mapped file, and then transfers the ownership of the shared memory space from the drawing application to the display server — ideally this would be done in such a way that the display server automatically knows that the drawing application cannot continue overwriting it, but on unix that is impossible, so they share access. when the display server is done with the pixel data buffer, it returns it to the drawing application for reuse
writing this, though, i am struck by the realization that you can probably avoid the extra memory copy with write() and read() by the simple expedient of allocating the write() and read() buffers at page boundaries and in multiples of the page size, so that a sufficiently smart kernel can handle write() by marking the written pages copy-on-write rather than actually copying the data, and handle read() by adding a (copy-on-write) mapping for the same pages to the receiving process's address space. then the misalignment induced by the control and framing data is inconsequential, and possibly even helpful, if the framing data is a multiple of the cache line size and potential simd register size, so that the pixel data is cache-line aligned and less likely to create cache contention with whatever framebuffer the display server eventually copies it into
— ⁂ —
as for moving to argentina, it's a good idea to have officially certified copies, made within the last year, of all your immigration-relevant documents; apostilles for those documents; a lot of money, ideally in bitcoin or 100-us-dollar bills (smaller bills and the old bills with a smaller benjamin franklin face trade at a discount, and bitcoin trades at a wide spread); fluency in spanish; a small number of easily salable electronic gadgets that you nevertheless actually use, such as macbooks, iphones, and recent phones or tablets from xiaomi, samsung, or motorola (compatible with the frequency bands we use here!), along with powerbanks and bluetooth earbuds; and enough of your savings to live on the form of 18-karat gold jewelry worn under your clothes
you can't legally bring pepper spray on the plane, but you should probably buy some as soon as you arrive. expect to get robbed about once a week during the first part of your stay, including from your checked luggage before you arrive, so don't be too attached to your possessions
withdrawing money from a dollar bank account at argentine atms does work but you only get about 45% of the money you withdraw thanks to the fake exchange rate; some expats have reported success in sending themselves money with western union, which doesn't use the fake exchange rate, but only scales up to about 200 dollars at a time, and may trigger investigations by the tax authorities
because voip on cell data is illegal, voip accounts from companies with a nexus in argentina will not work, at least on cellphone data (which is quite cheap, but i think signing up for a cellphone line will require an argentine citizen or permanent resident to vouch for you). this means google fi doesn't work at all, but for example voip.ms works fine with sipphone, and so does jitsi. also most cafes, restaurants, hotels, etc., have free wifi for customers, secured with a wpa psk key that changes every year or two
once you have a place to live that isn't a hotel or hostel, leave your passport there so that if you get robbed at least you won't lose your passport. unless armed robbers escort you at knifepoint to your house and demand entry in order to loot your house, which is a thing that happened to a couple of friends of mine. still you can probably hide your passport somewhere that they won't find it, and tell them that you lost it and are waiting for a replacement if they ask. a usa driver's license is generally enough to satisfy cops who demand to see your papers, and in 17 years that has happened to me only once, while i've been robbed on the street several times
don't expect to get a job! we're in the middle of the worst economic crisis we've had since 02001, so you'll probably have to live off your savings (or earnings from working for overseas clients) indefinitely; also keep in mind that living in the middle of an economic crisis can be depressing and anxiety-inducing, which can exacerbate any mental health problems you may have
with respect to the memory bandwidth thing, typically with ddr4 ram you get 30 or 40 gigabytes a second, jason cook tells me. a single main memory copy at 530 megabytes a second eats up one of those 30 or 40. if it's 4k (3840x2160), four times that, 10% of the computer, or 20% at 120 hertz. if you go from one copy per frame to two copies per frame, instead of using 20% of the computer's memory bandwidth just to update the screen, you're using 40%. or 50% if you are also writing that memory before it goes through the two copies
if you're trying to do something else on the computer, even on a different core, that's bottlenecked on memory bandwidth (as opposed to cpu or i/o or something) that's like using 50% of the computer, which means the whole computer is effectively half as fast
i think it's worth a significant amount of complexity to get your display system to suck up 30% of your computer instead of 50%, even when you're doing something that updates the full screen every frame, such as smooth scrolling, a 3d fps, or watching a movie, and that's why I think it's important to try to minimize copies in the pixel paper path
also keep in mind that many people dual-wield monitors these days, and 3840x2160, though common, is not as big as they get
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.
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.
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.
$ 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?
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.
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.)