3 ms·

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 o

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.)
- jeffbee 3y ago
  Sure, but there are hundreds of thousands of people in this industry who are dealing with data problems on a scale that certainly will not be handled on your laptop with sed and awk. The needs of industry shouldn't be sacrificed to the artisanal aesthetic of small solutions.
  - jjav 3y ago
    > Sure, but there are hundreds of thousands of people in this industry who are dealing with data problems on a scale that certainly will not be handled on your laptop with sed and awk. Yes there are, but those 100k's of people doing that are working in a small handful of megacorporations. For 99+% of the companies out there, they don't need the complexity. But it gets shoehorned in because resume.

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.)

jeffbee 3y ago
Sure, but there are hundreds of thousands of people in this industry who are dealing with data problems on a scale that certainly will not be handled on your laptop with sed and awk. The needs of industry shouldn't be sacrificed to the artisanal aesthetic of small solutions.
- jjav 3y ago
  > Sure, but there are hundreds of thousands of people in this industry who are dealing with data problems on a scale that certainly will not be handled on your laptop with sed and awk. Yes there are, but those 100k's of people doing that are working in a small handful of megacorporations. For 99+% of the companies out there, they don't need the complexity. But it gets shoehorned in because resume.