3 ms·

> How many files touches some typical desktop program to display 3 pictures Not sure about typical, but here is rough estimate for the rock bottom of it: "feh"

> How many files touches some typical desktop program to display 3 pictures Not sure about typical, but here is rough estimate for the rock bottom of it: "feh" image viewer on Ubuntu/X11: $ strace -e openat -o >(wc -l) feh -F \ one.jpg two.jpg three.jpg 105

jchw 4y ago
That's not the whole story of course: there's an X server that feh is communicating with over a domain socket and usually shared memory, and X implements significant functionality on its end. Then there's drivers, and the stuff between these things.
- nousermane 4y ago
  Sure. And bloated websites aren't dropping from the race here, either. They are communicating, over HTTP (and maybe WS/SSE), with fair number of servers, that also implement significant functionality. Then, there are microservices, databases, network between those...
  - jchw 4y ago
    Ultimately, though, even the script-free HTML pages that purists generally like and do not see as a problem do all of these things just as much. The point is that people have a lot of feelings about how simple, small and self-contained different software is, but realistically if you're not on a Commodore 64 they're all nightmarishly complicated. It only feels otherwise because encapsulation can be effective.
- LtWorf 4y ago
  an X server is not implementing as much functionality as a browser, but it's anyway needed to display our initial HTML
  - jchw 4y ago
    It's a bit nitpicky to go this direction, but in general having the display server implement all of the things X does is not necessary at all, especially because most apps, certainly browsers, essentially ignore those features of the display server, because they need more functionality and better performance. That said, I would not be surprised if XFree86 was, at some point, significantly larger than contemporary web browsers, given the enormous amount of functionality that was loaded into it. Of course, modern web browsers definitely trump any old X server, so is this really relevant? I guess it depends. I get a huge sense that what people are longing for is a return to the "good ol days" when software was simple and fast, and X is a damning counter example, though it certainly doesn't mean that there's no point to be made at all, just that it is perhaps less black and white than people suggest. I am not trying to say that feh is as complex or as slow as a web browser, only that in general, people treat the division of "native code" and "browser code" such that code running in a browser is always more bloated and slow. Somehow though, this is demonstrably not true. Looking at only very simple software with intentionally very limited scope is not going to give the whole picture. When you look at fairly complex software, the additional burden of having a browser underneath can fade away compared to algorithmic complexity issues and poorly optimized code. Your text layout and font shaping routines are probably going to struggle to compete with a browser if you have a very heavy layout to handle, and if you're doing accidentally quadratic things it's going to matter more than JIT or GC overhead.
    - trasz 4y ago
      I think X was kind of like this, yeah - in the eighties and early nineties; it's got its own chapter in the Unix Haters Handbook. There's been an incredible amount of work done to fix/work around its problems, and some of them - like security - turned up to be not practically fixable at all. Rewriting it into a properly minimalist design 20 years ago, like Apple did, instead of just now, would save everyone a lot of time. And this time it's orders of magnitude worse.
      - int_19h 4y ago
        X was literally the thing they needed shared libraries for - it was too big to link statically.
the8472 4y ago
63 for me, and most of those are libraries which should already be in memory. Which is nanoseconds away from the CPU while servers are dozens to hundreds milliseconds away.
- deleted 4y ago
  [deleted]

jchw 4y ago

That's not the whole story of course: there's an X server that feh is communicating with over a domain socket and usually shared memory, and X implements significant functionality on its end. Then there's drivers, and the stuff between these things.

nousermane 4y ago
Sure. And bloated websites aren't dropping from the race here, either. They are communicating, over HTTP (and maybe WS/SSE), with fair number of servers, that also implement significant functionality. Then, there are microservices, databases, network between those...
- jchw 4y ago
  Ultimately, though, even the script-free HTML pages that purists generally like and do not see as a problem do all of these things just as much. The point is that people have a lot of feelings about how simple, small and self-contained different software is, but realistically if you're not on a Commodore 64 they're all nightmarishly complicated. It only feels otherwise because encapsulation can be effective.
LtWorf 4y ago
an X server is not implementing as much functionality as a browser, but it's anyway needed to display our initial HTML
- jchw 4y ago
  It's a bit nitpicky to go this direction, but in general having the display server implement all of the things X does is not necessary at all, especially because most apps, certainly browsers, essentially ignore those features of the display server, because they need more functionality and better performance. That said, I would not be surprised if XFree86 was, at some point, significantly larger than contemporary web browsers, given the enormous amount of functionality that was loaded into it. Of course, modern web browsers definitely trump any old X server, so is this really relevant? I guess it depends. I get a huge sense that what people are longing for is a return to the "good ol days" when software was simple and fast, and X is a damning counter example, though it certainly doesn't mean that there's no point to be made at all, just that it is perhaps less black and white than people suggest. I am not trying to say that feh is as complex or as slow as a web browser, only that in general, people treat the division of "native code" and "browser code" such that code running in a browser is always more bloated and slow. Somehow though, this is demonstrably not true. Looking at only very simple software with intentionally very limited scope is not going to give the whole picture. When you look at fairly complex software, the additional burden of having a browser underneath can fade away compared to algorithmic complexity issues and poorly optimized code. Your text layout and font shaping routines are probably going to struggle to compete with a browser if you have a very heavy layout to handle, and if you're doing accidentally quadratic things it's going to matter more than JIT or GC overhead.
  - trasz 4y ago
    I think X was kind of like this, yeah - in the eighties and early nineties; it's got its own chapter in the Unix Haters Handbook. There's been an incredible amount of work done to fix/work around its problems, and some of them - like security - turned up to be not practically fixable at all. Rewriting it into a properly minimalist design 20 years ago, like Apple did, instead of just now, would save everyone a lot of time. And this time it's orders of magnitude worse.
    - int_19h 4y ago
      X was literally the thing they needed shared libraries for - it was too big to link statically.

the8472 4y ago

63 for me, and most of those are libraries which should already be in memory. Which is nanoseconds away from the CPU while servers are dozens to hundreds milliseconds away.

deleted 4y ago
[deleted]