3 ms·

> setting up your email so it's like the 80s Using email for development isn't the 80s. It is very streamlined and built into the Git code itself and mail clie

> setting up your email so it's like the 80s Using email for development isn't the 80s. It is very streamlined and built into the Git code itself and mail clients that are actively maintained like Mutt. Just because you can't imagine what life would be like without Gmail doesn't mean that these maintainers are less efficient and antiquated than you are. > Coding standards based on old tty terminals Don't even know what this means. What coding standard is based on old TTY terminals? TTY is part of Linux. > No unit testing Linux is the most widely used OS in enterprise. The internet runs on Linux. If you want unit tests for everyone then start an open source project to do this, or complain about the enterprises that aren't testing. > Toxic leaders Who is toxic? I love Linus's approach. It has allowed him to get things done without toxic people in the community trying to social engineer their way into destroying something good.

loxias 6y ago
> Don't even know what this means. What coding standard is based on old TTY terminals? TTY is part of Linux. I'm guessing they're trying to poke fun at people who care about your code being too wide, and hard to read? (But, while I no longer stick to a strict 80 column limit, like I used to, wide lines in code sucks. A proud mutt using systems engineer.)
- d110af5ccf 6y ago
  If you strictly adhere to a ~100 column width then you can easily fit 3 files side by side on a mainstream monitor. People complain about useful practices and characterize them as antiquated rather than taking the time to appreciate that not everyone uses the same workflow.
  - encryptluks2 6y ago
    Setting a fixed width is not one that I agree with. You can enable line wrapping in pretty much every text editor.
    - cerved 6y ago
      Remember that long lines aren't just a problem for display. Longer lines might indicate that the code is either nested too deep, likely too complicated. Or poorly named withUnreadableRidicouslyLongWeirdWhatsGoingOnHereName. It's also problematic if the line ends up doing too much, ie. lots of chained method, since VCS track changes per line. While editors do a good job at word wrapping, they're not always excellent. Humans may do a better job. Note that the kennels style guide isn't fixed at 80 characters but strongly preferred. "Coding style is all about readability and maintainability using commonly available tools. The limit on the length of lines is 80 columns and this is a strongly preferred limit. Statements longer than 80 columns will be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list. However, never break user-visible strings such as printk messages, because that breaks the ability to grep for them."
    - d110af5ccf 6y ago
      I'm late to respond, but automatic line wrapping completely butchers code formatting and creates a difficult to skim mess. I also don't understand why fixed width would cause any issues in practice. The only time I find myself coming anywhere near 80 characters is for API calls with way too many arguments (I'm looking at you, OpenGL). Even then, the fault arguably lies with me for my tendency to use overly descriptive variable names. And anyway, it's trivial to split such calls across multiple lines such that it actually improves the overall readability.
TeeMassive 6y ago
> . It is very streamlined and built into the Git code itself and mail clients that are actively maintained like Mutt. Just because you can't imagine what life would be like without Gmail doesn't mean that these maintainers are less efficient and antiquated than you are. You assume that there are not other tools to submit code and participate in discussion. That's obviously not true. Also the argument that "it is supported with git" is just a non-argument. > Don't even know what this means. What coding standard is based on old TTY terminals? TTY is part of Linux. You obviously don't know indeed. 80 lines comes from old teletype writers: http://www.navy-radio.com/tty.htm http://www.navy-radio.com/tty.htm And even Linus disagreed recently (http://lkml.iu.edu/hypermail/linux/kernel/2005.3/08168.html http://lkml.iu.edu/hypermail/linux/kernel/2005.3/08168.html) but the limit was only increased to 100 columns. So yeah. > Linux is the most widely used OS in enterprise. The internet runs on Linux. And? > If you want unit tests for everyone then start an open source project to do this, or complain about the enterprises that aren't testing. That's just arguing from a position of power. There is an open source project by the way, named kunit, but it's obviously left as an afterthought. Testing is left to "community testing" which is just a way of saying "compile the whole thing, test the whole thing, let's wish somebody caught most bugs", which is just the naive way of doing things before automated testing became popular in the early 2000s. > Who is toxic? I love Linus's approach. It has allowed him to get things done without toxic people in the community trying to social engineer their way into destroying something good. There are tons of other successful open source projects that do have to rely on base insults and abuse. The fact that the way the Linux kernel hasn't changed a bit for 30 years just shows how much its community is intolerant to ideas.
- tankenmate 6y ago
  > You assume that there are not other tools to submit code and participate in discussion. That's obviously not true. Also the argument that "it is supported with git" is just a non-argument. git was developed as a tool to support linux kernel development, why would you not support the right tool for the job? git was (and is) better than all the alternatives and is why kernel developers have stuck with it. I guess if git offends you could just use patch files. Or write something that is obviously so much better that people naturally switch to it.

loxias 6y ago

> Don't even know what this means. What coding standard is based on old TTY terminals? TTY is part of Linux. I'm guessing they're trying to poke fun at people who care about your code being too wide, and hard to read? (But, while I no longer stick to a strict 80 column limit, like I used to, wide lines in code sucks. A proud mutt using systems engineer.)

d110af5ccf 6y ago
If you strictly adhere to a ~100 column width then you can easily fit 3 files side by side on a mainstream monitor. People complain about useful practices and characterize them as antiquated rather than taking the time to appreciate that not everyone uses the same workflow.
- encryptluks2 6y ago
  Setting a fixed width is not one that I agree with. You can enable line wrapping in pretty much every text editor.
  - cerved 6y ago
    Remember that long lines aren't just a problem for display. Longer lines might indicate that the code is either nested too deep, likely too complicated. Or poorly named withUnreadableRidicouslyLongWeirdWhatsGoingOnHereName. It's also problematic if the line ends up doing too much, ie. lots of chained method, since VCS track changes per line. While editors do a good job at word wrapping, they're not always excellent. Humans may do a better job. Note that the kennels style guide isn't fixed at 80 characters but strongly preferred. "Coding style is all about readability and maintainability using commonly available tools. The limit on the length of lines is 80 columns and this is a strongly preferred limit. Statements longer than 80 columns will be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list. However, never break user-visible strings such as printk messages, because that breaks the ability to grep for them."
  - d110af5ccf 6y ago
    I'm late to respond, but automatic line wrapping completely butchers code formatting and creates a difficult to skim mess. I also don't understand why fixed width would cause any issues in practice. The only time I find myself coming anywhere near 80 characters is for API calls with way too many arguments (I'm looking at you, OpenGL). Even then, the fault arguably lies with me for my tendency to use overly descriptive variable names. And anyway, it's trivial to split such calls across multiple lines such that it actually improves the overall readability.

TeeMassive 6y ago

> . It is very streamlined and built into the Git code itself and mail clients that are actively maintained like Mutt. Just because you can't imagine what life would be like without Gmail doesn't mean that these maintainers are less efficient and antiquated than you are. You assume that there are not other tools to submit code and participate in discussion. That's obviously not true. Also the argument that "it is supported with git" is just a non-argument. > Don't even know what this means. What coding standard is based on old TTY terminals? TTY is part of Linux. You obviously don't know indeed. 80 lines comes from old teletype writers: http://www.navy-radio.com/tty.htm http://www.navy-radio.com/tty.htm And even Linus disagreed recently (http://lkml.iu.edu/hypermail/linux/kernel/2005.3/08168.html http://lkml.iu.edu/hypermail/linux/kernel/2005.3/08168.html) but the limit was only increased to 100 columns. So yeah. > Linux is the most widely used OS in enterprise. The internet runs on Linux. And? > If you want unit tests for everyone then start an open source project to do this, or complain about the enterprises that aren't testing. That's just arguing from a position of power. There is an open source project by the way, named kunit, but it's obviously left as an afterthought. Testing is left to "community testing" which is just a way of saying "compile the whole thing, test the whole thing, let's wish somebody caught most bugs", which is just the naive way of doing things before automated testing became popular in the early 2000s. > Who is toxic? I love Linus's approach. It has allowed him to get things done without toxic people in the community trying to social engineer their way into destroying something good. There are tons of other successful open source projects that do have to rely on base insults and abuse. The fact that the way the Linux kernel hasn't changed a bit for 30 years just shows how much its community is intolerant to ideas.

tankenmate 6y ago
> You assume that there are not other tools to submit code and participate in discussion. That's obviously not true. Also the argument that "it is supported with git" is just a non-argument. git was developed as a tool to support linux kernel development, why would you not support the right tool for the job? git was (and is) better than all the alternatives and is why kernel developers have stuck with it. I guess if git offends you could just use patch files. Or write something that is obviously so much better that people naturally switch to it.