Everything is a file

didn't plan9 fix that too?

Plan 9 has some wonderful ideas, but is very much a research OS.

what that actually means is that you can use the read() and write() system calls on sockets like they are file descriptors.

>everything is really just 1s and 0s

except sockets, signals, select/poll queue, processes and threads

is unix a file?

Sockets are are files too. Are you retarded? Have you ever heard the term "file descriptor" in relation to sockets?

OP is making fun of what unix creators said not what he actually thinks...

No, it's an app in Windows store

Attached: debian-windows-store.jpg (951x632, 46K)

everything is a file = REST at the OS api level

>plan9 isn't unix
>more similar to 10th edition unix than 10th edition unix is to first edition

Attached: 1495671148126.png (429x459, 28K)

but GNU/Linux isn't unix

that's a yikes from me

Leave it to San Fagcisco nu males to ruin something good.

which means?

almost as if sockets were added 15 years after UNIX was created and by completely different people

yeah, but you have to understand that most Unices out there are based on Bell Labs UNIX 6th and 7th Editions
everything after 7th Ed. had only very limited circulation and a lot of the more advanced changes never made it to the general public
that's why Plan9 is so different from contemporary Unices even though it's heavily based on UNIX 10th Edition

Attached: 1520000912843.png (553x827, 481K)

I'm starting to have doubts about everything is a file
files are crippled objects, it's another cnile approach to emulate more advanced culture
except because of no inheritance, everything is a leaf with full API even if not supporting a basic serial I/O
it's also worse because it only supports 1:1 operations, there are limited ways to message to multiple objects
messaging is slow, sometimes you need to access raw resources (e.g. for fast rendering)
tree hierarchy is obviously not enough, we have symlinks, mount and union directories on plan 9 to go around it
stripping the interface to open/read/write/close could lead to far harder designs, it is already problematic for permissions that they are tight to address and not inode, any sandboxing would benefit from the uniqueness of resource name - which is what syscalls can provide

I really wonder what redox will do with schemes, it seem to nicely address different behavior or various non-file files.

everything is 1s and 0s

What's your fucking point.

What if it's on a ternary computer

Mine is a quadnary computer.

>no modern decimal computers
fuck this gay earth

Somebody with an actual brain?

>processes and threads
>what is /proc

you go make that OS and report back how it went
UNIX and especially "everything is a file" came to be because the alternatives were complicated and required huge amounts of boilerplate when scaled up

ok, show me how you fork by writing to a file or copying it
/proc is not a complete process interface

Sockets in Unix are considered files. They support read(), write(), close(), etc...

are you retarded?
there's literally no use case for forking a process through a file

"Everything is a file" is dumb.

Not that user, but here's my report anyway.
You can do away with "everything is a file", and instead adopt more modern primitives, such as named publish/subscribe channels and named request/reply services.

Attached: headpat please.png (1000x1050, 687K)

there would be if pid was replaced by file descriptor which copying for fork would return and waitpid would be another file operation

>named publish/subscribe channels and named request/reply services
so... uh... named pipes and D-Bus?
the former is occasionally used and the latter is a fucking trainwreck

no, you don't understand.
there's no use case for doing it through a file because forking only has meaning when done from inside the process at a specific point in the code and then you might as well use a syscall instead of writing to a file
forking by writing to a file is R E T A R D E D
there's no reason to access this facility from outside of the process

What the fuck is a computer?

>named publish/subscribe channels and named request/reply services.
How are you going to name them? You'll need to set up a namespace scheme. Maybe we can use / to separate the parts of the name. OH WAIT.

>so... uh... named pipes and D-Bus?
>the former is occasionally used and the latter is a fucking trainwreck
>no, you don't understand.
Not at all.
Pipes are a type of file, with the full file manipulatiob interface attached to it. Pubsub have a minimal interface designed specifically for their use-case.
D-bus is an userspace library, it's connection-oriented, it uses high level objects and does marshalling.
The req/rep interface I use is instead kernel-mediated, connectionless, low level (it passes raw blocks of bytes without marshalling).
Go take a class in software engineering, retard.
It's not about the naming scheme, it's about the interface they implement.

Do network sockets have inodes and unix-domain sockets have inodes?

UNIX (local) sockets do have them because the interface to them exists as a special file on the filesystem

ITT: 12 year-olds on a Cambodian knitting board who are smarter than the pioneers of computer science.

> Sockets are not files.
Brainlet detected.

Are certain combinations of ones and zeros sockets?

whats this?

Attached: 2018-08-05-200448_456x14_scrot.png (456x14, 959)

that's a UNIX socket and it's local-only
it's basically a special file that behaves like a Berkeley socket, but only for local communication
proper Berkeley sockets that you can use to communicate with outside do not have a special file interface

Fuck of unix pleb with your inferior shit os

Files were a mistake. Storage should be relational and consist of typed records.

that's basically MVS datasets... yeah, good luck with that clusterfuck