I was thinking of some file types that afaik don't exist.
One is filesystem entries of files stored in memory from disk files, updated when the disk file modification time changes. This would be a big disk-access optimization in some cases.
The in-memory entry permissions would be ignored, and writing to it would write to the disk file.
Another one is dynamic files that (only) have the name of a executable, which when opened would be executed by the kernel, creating a process child of init with its standard output piped to the file descriptor obtained by opening the dynamic file.
Here reading would depend on both the dynamic file's read permission and the named executable's execute permission. The idea is that it's transparent to the reading process.
Whether they could change the file to which they point to without deleting it would depend on the implementation, I think. (https://en.wikipedia.org/wiki/Symbolic_link#Variable_symbolic_links)
Unix sucks.
>>2
Unix is programmable, you can change it not to suck.
Everything else sucks more, and you're stuck.
Yeah, you can spend your tine and effort on trying to graft usability onto a crusty design built to run mainframes in the 70s, like the Linux fags have been trying and failing at for the past two decades, or you could try to make an OS that actually makes sense for desktop use instead.
>>4
I was gonna make an OS that like totally made sense super intuitive wouldve changed the desktop forever but I got stuck at implementing jishin/kashin.
The first type is called mmap, and caching like that is done automatically by the kernel.
The second type, if I understand correctly, is a script glued to a fifo.
Oh yeah kernel caching.
>The second type, if I understand correctly, is a script glued to a fifo.
That's rather rudimenary. For that you could just serve virtual files. My idea was that the writer and reader programs didn't have to know about this, but, now that I think about it, that just reading might execute something is probably too wild.
Oh, I see. So opening the file would implicitly start its target program, and read/write operations on the file would redirect to stdi/o. How would you change the target program?
Perl uses this idea - opening a subprocess is identical to opening a file, but the filename begins with a pipe.
>How would you change the target program?
Similar to changing other files, probably.
>Perl uses this idea - opening a subprocess is identical to opening a file, but the filename begins with a pipe.
Kinda like the POSIX popen interface, yeah. But having to use special interfaces or languages falls short of transparency.
RAM is really expensive though.
>>4
OS development is a major undertaking, it's not the sort of thing you can do in a weekend, especially considering it requires low-level programming techniques that are avoided in modern application development. The appeal of things like Linux and BSD is that the hard work is already done for you, but unlike Windows or Apple operating systems you have the freedom to modify the user interface (which is all most people really care about, messing around "under the hood" is really only called for when working with embedded systems or mainframes, where you need to get every last bit of performance out of the machine - and only low level programming specialists really have the ability to effectively optimize in those areas, anyway). And the UNIX architecture, although rather old, wasn't really made for "mainframes", one of its main advantages at the time was that it could run on lower-end systems.
>>14
All sort of things require low-level programming.
>>10
I think I understand your idea.
How about a daemon that handles that stuff? You give the daemon the name of a script and of a fifo. Your daemon calls inotify on the fifo and waits. When one of the registered fifos is open, the daemon triggers the script with it's output descriptor directed to the fifo.
>>16
It is an idea that has already been implemented at the socket level: inetd[1]. It is a system that spawns a specified process when a connection to a port/socket has been opened. No fancy inotify crap.
Also, systemd supports all of this, including FIFOs.[2]
1: https://en.wikipedia.org/wiki/Inetd
2: http://0pointer.de/public/systemd-man/systemd.socket.html
> Unix domain sockets use the file system as their address name space. Processes reference Unix domain sockets as file system inodes,
[b][o][u][i]Meta-Circular Evaluation[/i][/u][/o][/b]
>>15
Is that supposed to make it any simpler?
UNIX and C are highly overrated. They were made popular by commie students who liked to share software.
There were systems prior and after UNIX which were made better - MULTICS, IBM MVS, DEC VMS, etc
Systems for personal computers have nothing to do with unix too.
And for programming language C is nothing special. It has a lot of undefined behavior and ways to shoot your leg. And it's nothing but little impoved BCPL, nothing really new. There were better languages(ada, algol, fortran, lisps, etc, etc)
And Windows NT based on VMS. The only thing came from unix(not original unix but bsd) is sockets, but there were other solutions.