5 ms·

The 7th point: "curl sits in the boat" In the curl project we’re deliberately conservative and we stick to old standards, to remain a viable and relia

by devy 10y ago

The 7th point: "curl sits in the boat" In the curl project we’re deliberately conservative and we stick to old standards, to remain a viable and reliable library for everyone. Right now and for the foreseeable future. Things that worked in curl 15 years ago still work like that today. The same way. Users can rely on curl. We stick around. We don’t knee-jerk react to modern trends. We sit still in the boat. We don’t rock it. I see a lot of inertia in there. While it's a great record to maintain 15-year consistency but in the era of every changing InfoSec outlook, it could be a legacy and baggage if the authors resist to change. One thing we know for sure is that human will make mistakes, no matter how skillful you are. In the context of writing a fundamental piece of software with an unsafe programming language, that means we are guarantee to have memory-safety induced CVE bugs in curl in the future. Some of other points that the author raised are valid too. If there is a trade-off that we can have a safer piece of fundamental software by almost eliminating a whole category of memory safety related bugs, and with the downside of less compatibility with legacy systems, more dependencies etc., perhaps we should consider it? I believe the tradeoff is well worthy in the long run and option is ripe for explore.

cestith 10y ago
How is the author resistant to change? He specifically said new code should be written in a language that meets the priorities for that code. He specifically said someone has or would write a competitor to curl in Rust or some other safer language and that a good one will take off. He welcomed that. What he doesn't welcome is rewriting something that's had those bugs and the types of logic bugs not related to the language already worked out. There's a saying about a baby and bathwater. Not everything is a dichotomy, and you shouldn't be reading the article as if the author is against newer languages. He specifically says that given a fresh start with the availability of these languages he might use something besides C. Carefully weighing options is wise. Throwing away years of actual progress for the appearance of quick progress is foolish.
- devy 10y ago
  > How is the author resistant to change? I specially quoted the section head "curl sits in the boat" and the entire section ends with "We sit still in the boat. We don’t rock it". Now read it again, and then tell me if that's welcoming changes or resisting changes. > He specifically said someone has or would write a competitor to curl in Rust or some other safer language and that a good one will take off. He welcomed that. Sure there might already be some alternatives out there. But those are not curl, they are at most forks. > He specifically says that given a fresh start with the availability of these languages he might use something besides C. Nope, he used the word "Maybe. Maybe not." Might is a stronger word.
  - cestith 10y ago
    Having no plans to change curl within itself is not a resistance to change in general. Not everything is a dichotomy. One doesn't have to be for all change or against all change. One can choose which things need to change.
    - kelnos 10y ago
      I see "we don't rock the boat" as completely synonymous with "I am resistant to change". (Note that I suspect you think that I or the original poster are suggesting that he's resistant to all change, not just change within curl. I don't believe he's resistant to all change, but I do believe he's resistant to change within curl, which is what we're talking about here.)
      - cestith 10y ago
        He's not resistant to change in the problem space. He's resistant to very particular types of change in one very particular codebase, and for very sound reasons. He doesn't want to break the ecosystem around curl, which is huge, while getting back to feature parity and compatibility during a full rewrite. Something that comes along and replaces curl externally needn't be completely compatible and therefore is freer to leverage their new, fresh start much more fully. He welcomes a competitor, which means even a possible complete replacement. That's not a resistance to change. That's being very judicious about what one changes and why.
generic_user 10y ago
> it could be a legacy and baggage if the authors resist to change. Every few years there is a new batch of programming languages that come out and they all gain a small passionate community that tries to convince the internet how much better that language is. They inevitably use the argument that code not written in the new language is 'legacy' and 'resistant to change'. Neither of those assertions are accurate or enlightening unless you can provide a proposed replacement and prove the superiority of the new code. Simply telling other programmers to rewrite there code in xyz language with such arguments is primarily a case of armchair development. If you really think it could be done better then do it and prove it.
- devy 10y ago
  > If you really think it could be done better then do it and prove it. What I said is my believe and opinion, obviously. I don't have the skill set neither have time to do/prove it, unfortunately. But that shouldn't prevent me from speaking out my opinion, should it? Just like a lot of people really think space travel could be done better but not all of them have the capability and resources to do it and prove it.
  - generic_user 10y ago
    > I don't have the skill set neither have time to do/prove it, unfortunately. But that shouldn't prevent me from speaking out my opinion, should it? Given the fact that programming language fanboy noise is a constant problem in language threads it would be nice to see less posts of higher quality then the same arguments that are always made. Its not really going to change anyone mind that has experience and the people who do argue are usually inexperienced with vapid counter arguments. So I guess the answer is no. If you have an uninformed opinion then its better to not add noise and let the people who really know there topic enlighten us with a well argued not very noisy discussion. I think the value of NH is very much quality over quantity.
feld 10y ago
I've a wild idea: add support for pledge, capsicum, etc to your codebase so these vulns are neutralized on every OS with a good security framework
paulddraper 10y ago
> it could be a legacy and baggage if the authors resist to change Could be. Or it could not be. Somehow, Git has increased in popularity, despite its author's over-my-dead-body insistence on C.

by devy 10y ago

cestith 10y ago

How is the author resistant to change? He specifically said new code should be written in a language that meets the priorities for that code. He specifically said someone has or would write a competitor to curl in Rust or some other safer language and that a good one will take off. He welcomed that. What he doesn't welcome is rewriting something that's had those bugs and the types of logic bugs not related to the language already worked out. There's a saying about a baby and bathwater. Not everything is a dichotomy, and you shouldn't be reading the article as if the author is against newer languages. He specifically says that given a fresh start with the availability of these languages he might use something besides C. Carefully weighing options is wise. Throwing away years of actual progress for the appearance of quick progress is foolish.

devy 10y ago
> How is the author resistant to change? I specially quoted the section head "curl sits in the boat" and the entire section ends with "We sit still in the boat. We don’t rock it". Now read it again, and then tell me if that's welcoming changes or resisting changes. > He specifically said someone has or would write a competitor to curl in Rust or some other safer language and that a good one will take off. He welcomed that. Sure there might already be some alternatives out there. But those are not curl, they are at most forks. > He specifically says that given a fresh start with the availability of these languages he might use something besides C. Nope, he used the word "Maybe. Maybe not." Might is a stronger word.
- cestith 10y ago
  Having no plans to change curl within itself is not a resistance to change in general. Not everything is a dichotomy. One doesn't have to be for all change or against all change. One can choose which things need to change.
  - kelnos 10y ago
    I see "we don't rock the boat" as completely synonymous with "I am resistant to change". (Note that I suspect you think that I or the original poster are suggesting that he's resistant to all change, not just change within curl. I don't believe he's resistant to all change, but I do believe he's resistant to change within curl, which is what we're talking about here.)
    - cestith 10y ago
      He's not resistant to change in the problem space. He's resistant to very particular types of change in one very particular codebase, and for very sound reasons. He doesn't want to break the ecosystem around curl, which is huge, while getting back to feature parity and compatibility during a full rewrite. Something that comes along and replaces curl externally needn't be completely compatible and therefore is freer to leverage their new, fresh start much more fully. He welcomes a competitor, which means even a possible complete replacement. That's not a resistance to change. That's being very judicious about what one changes and why.

generic_user 10y ago

> it could be a legacy and baggage if the authors resist to change. Every few years there is a new batch of programming languages that come out and they all gain a small passionate community that tries to convince the internet how much better that language is. They inevitably use the argument that code not written in the new language is 'legacy' and 'resistant to change'. Neither of those assertions are accurate or enlightening unless you can provide a proposed replacement and prove the superiority of the new code. Simply telling other programmers to rewrite there code in xyz language with such arguments is primarily a case of armchair development. If you really think it could be done better then do it and prove it.

devy 10y ago
> If you really think it could be done better then do it and prove it. What I said is my believe and opinion, obviously. I don't have the skill set neither have time to do/prove it, unfortunately. But that shouldn't prevent me from speaking out my opinion, should it? Just like a lot of people really think space travel could be done better but not all of them have the capability and resources to do it and prove it.
- generic_user 10y ago
  > I don't have the skill set neither have time to do/prove it, unfortunately. But that shouldn't prevent me from speaking out my opinion, should it? Given the fact that programming language fanboy noise is a constant problem in language threads it would be nice to see less posts of higher quality then the same arguments that are always made. Its not really going to change anyone mind that has experience and the people who do argue are usually inexperienced with vapid counter arguments. So I guess the answer is no. If you have an uninformed opinion then its better to not add noise and let the people who really know there topic enlighten us with a well argued not very noisy discussion. I think the value of NH is very much quality over quantity.

feld 10y ago

I've a wild idea: add support for pledge, capsicum, etc to your codebase so these vulns are neutralized on every OS with a good security framework

paulddraper 10y ago

> it could be a legacy and baggage if the authors resist to change Could be. Or it could not be. Somehow, Git has increased in popularity, despite its author's over-my-dead-body insistence on C.