16 ms·

That approach works so well that a program written in '70s is so well abstracted away from the intricacies of the system that it can input data from a network s

That approach works so well that a program written in '70s is so well abstracted away from the intricacies of the system that it can input data from a network socket, a pipe, a file, or output to whatnot, and doesn't need to be touched for all that to work. A plain program reading from stdin and writing to stdout can be turned into a network service via inetd or similar by just redirecting file descriptors. But for the contemporary software coders the ingenious idea is of course rubbish. They would replace everything by node_modules.

01HNNWZ0MV43FF 3y ago
They say io_uring is faster. The cost of modularity is often overhead.
bluetomcat 3y ago
It was originally developed as a multi-user time-sharing system. Multiple users would access the system simultaneously via the attached teletype terminals. The "shell" program handled such an interactive user session. All IO was blocking, and programs were written in a sequential manner. Piping enabled them to feed the standard output of one process to the standard input of another. It's a good framework for text-based computing, but nowadays we have so much more problems to cope with. This original idea never addressed networking, binary versioning and control, configuration management, async IO, multithreading, GUI, etc.
jeffbee 3y ago
It's great that it is easy to do simple things with ancient tools, and it's completely true that you can inetd and CGI your way to covering numerous use cases on small systems. The problem is the lack of innovation holds us back from solving complex use cases. The sockets API in particular is a gigantic mess, because the protocols are more complicated than people imagined forty years ago. For example it is simple to send a datagram. What if you want to get notified of the timestamp when the datagram hits the wire? Now you will 1) read a lot of man pages, 2) write 100s of lines of gross C code, 3) read the source code of the Linux kernel to figure out which parts of the manual were lies, then 4) fix your program with some different code and a long, angry comment. None of they would be necessary if the last quarter-century of network features hadn't been jammed into the ioctl and setsockopt hack interfaces. In other words there's plenty of room for operating systems to reconsider interfaces in light of the systems and protocols we have now, instead of Space Age imaginary use cases.
- gpderetta 3y ago
  Reading timestamps is indeed a clusterfuck, but are you sure that whoever came up with that mess would have done better with a deprogramming model? Edit: I won't elevate the Unix model to a pedestal, but in his favour I will say that the relative simplicity of the model and it's inherent difficulties to extensibility helped limit scope creep and overengineering.
- jiveturkey 3y ago
  > read the source code of the Linux kernel to figure out which parts of the manual were lies my daily job :(
  - jeffbee 3y ago
    Same, Turkey. Same :-( Most recent horror I discovered: `mincore` is intentionally broken, always returns positive results when the calling task is running in a mount namespace. Because the hallowed unix file abstraction is fundamentally bad.
    - jiveturkey 3y ago
      Shall we start a new competitor to readthedocs.io? ignorethedocs.io
- jjav 3y ago
  > The problem is the lack of innovation holds us back from solving complex use cases. Innovation is awesome, when it is in the pursuit of achieving something better. (Better, not just newer for the sake of rewriting everything Yet Again.) What burns me out about this industry is that a huge amount of "innovation" is just a pursuit to create complexity for the sake of complexity and resume-driven development. Thus we get to classics like the "Command-line Tools can be 235x Faster than your Hadoop Cluster" (a well-known one, but countless similar scenarios play out everywhere continuously). To all of you setting up your 20 node cassandra cluster behind your enormous kubernetes setup, all just to serve your 100rps app: you're not innovating, you're doing it wrong. (Not "you" you. The whole software engineering industry.)
duped 3y ago
The devil is in the details. You can't turn really a command from the 70s into a webservice because its input are command line options/arguments and not query params or RPC arglists, and its output is probably intended for humans to read or parse easily with a regex/sed/awk. Web services speak in structured data for their input and output over protocols that can't be abstracted as file i/o. Because they're not just files. There are additional semantics and concerns that you cannot abstract away with read/write calls. You also need ioctls, you need send/recv, you need parsers on top to do something useful with the data, and so on. The reason that the simple model dies out is because it's not as useful as it seems in practice.
- gpderetta 3y ago
  CGI is already forgotten?
  - joquarky 3y ago
    I try to explain the elegant simplicity of CGI to peers and get blank stares
  - bigbillheck 3y ago
    CGI was a simple model that died out as better alternatives came along.

01HNNWZ0MV43FF 3y ago

They say io_uring is faster. The cost of modularity is often overhead.

bluetomcat 3y ago

It was originally developed as a multi-user time-sharing system. Multiple users would access the system simultaneously via the attached teletype terminals. The "shell" program handled such an interactive user session. All IO was blocking, and programs were written in a sequential manner. Piping enabled them to feed the standard output of one process to the standard input of another. It's a good framework for text-based computing, but nowadays we have so much more problems to cope with. This original idea never addressed networking, binary versioning and control, configuration management, async IO, multithreading, GUI, etc.

jeffbee 3y ago

It's great that it is easy to do simple things with ancient tools, and it's completely true that you can inetd and CGI your way to covering numerous use cases on small systems. The problem is the lack of innovation holds us back from solving complex use cases. The sockets API in particular is a gigantic mess, because the protocols are more complicated than people imagined forty years ago. For example it is simple to send a datagram. What if you want to get notified of the timestamp when the datagram hits the wire? Now you will 1) read a lot of man pages, 2) write 100s of lines of gross C code, 3) read the source code of the Linux kernel to figure out which parts of the manual were lies, then 4) fix your program with some different code and a long, angry comment. None of they would be necessary if the last quarter-century of network features hadn't been jammed into the ioctl and setsockopt hack interfaces. In other words there's plenty of room for operating systems to reconsider interfaces in light of the systems and protocols we have now, instead of Space Age imaginary use cases.

gpderetta 3y ago
Reading timestamps is indeed a clusterfuck, but are you sure that whoever came up with that mess would have done better with a deprogramming model? Edit: I won't elevate the Unix model to a pedestal, but in his favour I will say that the relative simplicity of the model and it's inherent difficulties to extensibility helped limit scope creep and overengineering.
jiveturkey 3y ago
> read the source code of the Linux kernel to figure out which parts of the manual were lies my daily job :(
- jeffbee 3y ago
  Same, Turkey. Same :-( Most recent horror I discovered: `mincore` is intentionally broken, always returns positive results when the calling task is running in a mount namespace. Because the hallowed unix file abstraction is fundamentally bad.
  - jiveturkey 3y ago
    Shall we start a new competitor to readthedocs.io? ignorethedocs.io
jjav 3y ago
> The problem is the lack of innovation holds us back from solving complex use cases. Innovation is awesome, when it is in the pursuit of achieving something better. (Better, not just newer for the sake of rewriting everything Yet Again.) What burns me out about this industry is that a huge amount of "innovation" is just a pursuit to create complexity for the sake of complexity and resume-driven development. Thus we get to classics like the "Command-line Tools can be 235x Faster than your Hadoop Cluster" (a well-known one, but countless similar scenarios play out everywhere continuously). To all of you setting up your 20 node cassandra cluster behind your enormous kubernetes setup, all just to serve your 100rps app: you're not innovating, you're doing it wrong. (Not "you" you. The whole software engineering industry.)

duped 3y ago

The devil is in the details. You can't turn really a command from the 70s into a webservice because its input are command line options/arguments and not query params or RPC arglists, and its output is probably intended for humans to read or parse easily with a regex/sed/awk. Web services speak in structured data for their input and output over protocols that can't be abstracted as file i/o. Because they're not just files. There are additional semantics and concerns that you cannot abstract away with read/write calls. You also need ioctls, you need send/recv, you need parsers on top to do something useful with the data, and so on. The reason that the simple model dies out is because it's not as useful as it seems in practice.

gpderetta 3y ago
CGI is already forgotten?
- joquarky 3y ago
  I try to explain the elegant simplicity of CGI to peers and get blank stares
- bigbillheck 3y ago
  CGI was a simple model that died out as better alternatives came along.