4 ms·

That's not what I said.

rhizome 10y ago
It's not your exact words, but I don't think it's an unfair characterization, if the excuse is simply that they'll be reading it on a desktop machine anyway. I took that image from a non-laptop desktop machine, by the way.
- nilliams 10y ago
  > It's not your exact words, but I don't think it's an unfair characterization You ignored the half of the sentence following the 'or'. To me, that's unfair. > if the excuse is [...] It's not an excuse, it's context. The performance is a low priority compared to the content, when the site is a developer resource.
  - rhizome 10y ago
    And for me it speaks to credibility.
    - nilliams 10y ago
      Perf is not important for a dev resource. If a dev had spent a ton of time optimising that they'd have wasted their time. Why does wasting their time make them more credible?
      - shakna 10y ago
        I disagree. In many places, perf is still important, and one of the reasons, I believe, that GNU offers its manuals in various formats: [0] I know of a few devs that work for web, but due to their nations economics, work: * On a smartphone * Via a satellite connection Despite being in a first world country, I've had to do both at various times whilst working from remote areas. The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies. caniuse.com is a SPA, but they load damn fast. I'm not saying that this page is insanely slow, but that it is slow at all is still a surprise. And not every dev in the world gets to have broadband. [0] http://www.gnu.org/software/libc/manual/ http://www.gnu.org/software/libc/manual/
        flukus 10y ago
        > The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies. Do all GNU projects keep there documentation i one big file? I wanted to contribute some recently but got lost in a complex help file.
        shakna 10y ago
        Most GNU manuals I've seen come as: * HTML - entirely on one web page. * HTML - one web page per node. * HTML compressed (gzipped tar file) - with one web page per node. * Info document (gzipped tar file). * ASCII text compressed (gzipped). * TeX dvi file (gzipped). * PDF file. * Texinfo source (gzipped tar file). If the one big file (great for grepping) was too confusing, you probably want to opt for HTML, with one file per node. For example, the Sockets/Local Namespace page for glibc: [0] [0] http://www.gnu.org/software/libc/manual/html_node/Local-Namespace.html#Local-Namespace http://www.gnu.org/software/libc/manual/html_node/Local-Name... Edit: And it appears the help files are seperate inside the source code as well. [1] [1] https://sourceware.org/git/?p=glibc.git;a=tree;f=manual;h=71b7180db43b98223bf9b18f821554745b48fbf8;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=tree;f=manual;h=71...
        flukus 10y ago
        > And it appears the help files are seperate inside the source code as well. Thanks. It appears that this wasn't the case for make.
        shakna 10y ago
        Ow. Make's manual is a 10,000 line texi file. That really sucks.
        deleted 10y ago
        [deleted]
    - kaishiro 10y ago
      As another random anecdote from another random developer, I find the site's content far outshines any purported credibility loss - which just seems like a very silly argument to make.

It's not your exact words, but I don't think it's an unfair characterization, if the excuse is simply that they'll be reading it on a desktop machine anyway. I took that image from a non-laptop desktop machine, by the way.

nilliams 10y ago
> It's not your exact words, but I don't think it's an unfair characterization You ignored the half of the sentence following the 'or'. To me, that's unfair. > if the excuse is [...] It's not an excuse, it's context. The performance is a low priority compared to the content, when the site is a developer resource.
- rhizome 10y ago
  And for me it speaks to credibility.
  - nilliams 10y ago
    Perf is not important for a dev resource. If a dev had spent a ton of time optimising that they'd have wasted their time. Why does wasting their time make them more credible?
    - shakna 10y ago
      I disagree. In many places, perf is still important, and one of the reasons, I believe, that GNU offers its manuals in various formats: [0] I know of a few devs that work for web, but due to their nations economics, work: * On a smartphone * Via a satellite connection Despite being in a first world country, I've had to do both at various times whilst working from remote areas. The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies. caniuse.com is a SPA, but they load damn fast. I'm not saying that this page is insanely slow, but that it is slow at all is still a surprise. And not every dev in the world gets to have broadband. [0] http://www.gnu.org/software/libc/manual/ http://www.gnu.org/software/libc/manual/
      - flukus 10y ago
        > The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies. Do all GNU projects keep there documentation i one big file? I wanted to contribute some recently but got lost in a complex help file.
        shakna 10y ago
        Most GNU manuals I've seen come as: * HTML - entirely on one web page. * HTML - one web page per node. * HTML compressed (gzipped tar file) - with one web page per node. * Info document (gzipped tar file). * ASCII text compressed (gzipped). * TeX dvi file (gzipped). * PDF file. * Texinfo source (gzipped tar file). If the one big file (great for grepping) was too confusing, you probably want to opt for HTML, with one file per node. For example, the Sockets/Local Namespace page for glibc: [0] [0] http://www.gnu.org/software/libc/manual/html_node/Local-Namespace.html#Local-Namespace http://www.gnu.org/software/libc/manual/html_node/Local-Name... Edit: And it appears the help files are seperate inside the source code as well. [1] [1] https://sourceware.org/git/?p=glibc.git;a=tree;f=manual;h=71b7180db43b98223bf9b18f821554745b48fbf8;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=tree;f=manual;h=71...
        flukus 10y ago
        > And it appears the help files are seperate inside the source code as well. Thanks. It appears that this wasn't the case for make.
        shakna 10y ago
        Ow. Make's manual is a 10,000 line texi file. That really sucks.
        deleted 10y ago
        [deleted]
  - kaishiro 10y ago
    As another random anecdote from another random developer, I find the site's content far outshines any purported credibility loss - which just seems like a very silly argument to make.