5 ms·

> How many Linux technologies have not been able to surpass their counterpart technologies after years of iterating? Two are top of mind: epoll and btrfs. I'm

> How many Linux technologies have not been able to surpass their counterpart technologies after years of iterating? Two are top of mind: epoll and btrfs. I'm saying epoll is an example of a technology which has not been able to surpass its Solaris or Windows equivalents.

pjmlp 4y ago
Ah sorry, got it the other way around.
ajross 4y ago
Seems like there's a semantic problem here. epoll won. It clearly "surpassed" its competitors by most definitions. Arguments against it aren't grounded in epoll's capability or performance. They're about aesthetics. People used to kqueues think epoll is ugly. Well, OK. I think that's fair. But being beautiful isn't sufficient to declare a software feature as having "surpassed" another, again by conventional definitions. It's just a way to win an argument. Really the epoll nonsense is a perfect microcosm of exactly this kind of argument. For 30 years the BSD folks have been making fundamentally aesthetic arguments into a market that demands practical solutions. And... losing, kinda. FWIW: I think the btrfs argument is rather stronger on a technical level. The problem there is that people stopped caring about local storage filesystems about 10-15 years ago. Local devices are a solved problem, and all the innovation in storage technology is happening in the cloud today, in front of software layers that are only vaguely understood as "filesystems" in the Unix sense.
- mustache_kimono 4y ago
  I agree there is a semantic distinction to be made re: epoll, but also an unstated premise: Worse is better when you can iterate to good enough. What is good enough? Well I think you may forget another metric: developer experience and ease of building a correct product. Say you're building a web framework or server, how long is that going to take do that correctly with epoll compared to the alternatives?
  - ajross 4y ago
    > Say you're building a web framework or server, how long is that going to take do that correctly with epoll compared to the alternatives. This is still making too much of the subject. Every major server framework was epoll-capable within a few months of the feature landing. Again, epoll won. It's fine. It's more than fine, it's actually pretty great. It's not hard to use, at all (at least relative to other technologies in the same space). It's just not as subjectively pretty as kqueues.
    - mustache_kimono 4y ago
      > Again, epoll won. epoll didn't win? Linux won. Which was one point of my post (that you're nitpicking). Linux wins for reasons which mostly have nothing to do with design philosophy ("worse is better"), or technical superiority.
      - ajross 4y ago
        I still think you're being way too general here by deploying hyperbole like "technical superiority" or "surpass" to subjects that are just about aesthetics. Adapting it to your frame here, my point was something to the effect of: if kqueues were clearly superior technically, then applications[1] which rely heavily on widely-multiplexed kernel notifications would naturally have migrated to the superior solution. (Ditto for zfs/btrfs, etc...) And... there really are none. For all the yelling, in fact epoll works great. It still works great. Claiming something is "technically superior" to a product that clearly works great in the market is a red flag that you're probably not arguing about technology. [1] Which are MANY! The whole cloud runs on epoll!
        mustache_kimono 4y ago
        > if kqueues were clearly superior technically, then applications which rely heavily on widely-multiplexed kernel notifications would naturally have migrated to the superior solution. I get it -- you don't like the way I phrased my point. More power to you. But you keep shadowboxing a straw man. My point was: It doesn't matter if kqueue is clearly superior technically or aesthetically or otherwise, Linux (not epoll) wins for reasons that have nothing to do with that. In order to actually make your point re: aesthetics, you have to make a much stronger case, which is that epoll actually is at least the technical equal of kqueue, not merely your feeling that apps would have naturally migrated, etc. Instead of -- people chose Linux (again not epoll) because of ... inertia, herd mentality, knowledge base, app availability, etc. Good luck.

pjmlp 4y ago

Ah sorry, got it the other way around.

ajross 4y ago

Seems like there's a semantic problem here. epoll won. It clearly "surpassed" its competitors by most definitions. Arguments against it aren't grounded in epoll's capability or performance. They're about aesthetics. People used to kqueues think epoll is ugly. Well, OK. I think that's fair. But being beautiful isn't sufficient to declare a software feature as having "surpassed" another, again by conventional definitions. It's just a way to win an argument. Really the epoll nonsense is a perfect microcosm of exactly this kind of argument. For 30 years the BSD folks have been making fundamentally aesthetic arguments into a market that demands practical solutions. And... losing, kinda. FWIW: I think the btrfs argument is rather stronger on a technical level. The problem there is that people stopped caring about local storage filesystems about 10-15 years ago. Local devices are a solved problem, and all the innovation in storage technology is happening in the cloud today, in front of software layers that are only vaguely understood as "filesystems" in the Unix sense.

mustache_kimono 4y ago
I agree there is a semantic distinction to be made re: epoll, but also an unstated premise: Worse is better when you can iterate to good enough. What is good enough? Well I think you may forget another metric: developer experience and ease of building a correct product. Say you're building a web framework or server, how long is that going to take do that correctly with epoll compared to the alternatives?
- ajross 4y ago
  > Say you're building a web framework or server, how long is that going to take do that correctly with epoll compared to the alternatives. This is still making too much of the subject. Every major server framework was epoll-capable within a few months of the feature landing. Again, epoll won. It's fine. It's more than fine, it's actually pretty great. It's not hard to use, at all (at least relative to other technologies in the same space). It's just not as subjectively pretty as kqueues.
  - mustache_kimono 4y ago
    > Again, epoll won. epoll didn't win? Linux won. Which was one point of my post (that you're nitpicking). Linux wins for reasons which mostly have nothing to do with design philosophy ("worse is better"), or technical superiority.
    - ajross 4y ago
      I still think you're being way too general here by deploying hyperbole like "technical superiority" or "surpass" to subjects that are just about aesthetics. Adapting it to your frame here, my point was something to the effect of: if kqueues were clearly superior technically, then applications[1] which rely heavily on widely-multiplexed kernel notifications would naturally have migrated to the superior solution. (Ditto for zfs/btrfs, etc...) And... there really are none. For all the yelling, in fact epoll works great. It still works great. Claiming something is "technically superior" to a product that clearly works great in the market is a red flag that you're probably not arguing about technology. [1] Which are MANY! The whole cloud runs on epoll!
      - mustache_kimono 4y ago
        > if kqueues were clearly superior technically, then applications which rely heavily on widely-multiplexed kernel notifications would naturally have migrated to the superior solution. I get it -- you don't like the way I phrased my point. More power to you. But you keep shadowboxing a straw man. My point was: It doesn't matter if kqueue is clearly superior technically or aesthetically or otherwise, Linux (not epoll) wins for reasons that have nothing to do with that. In order to actually make your point re: aesthetics, you have to make a much stronger case, which is that epoll actually is at least the technical equal of kqueue, not merely your feeling that apps would have naturally migrated, etc. Instead of -- people chose Linux (again not epoll) because of ... inertia, herd mentality, knowledge base, app availability, etc. Good luck.