Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: C99
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Rodrigo s via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 23 Sep 2022 16:07:22 -0300
This comment may be very off-topic, this is just my curiosity:
My question is WHY???
Why does the old system need the new version of curl? Why just don't use
the last version that supports it? You can say that some protocols update
over time and it needs to be used. OK, I understand. But... Servers can
have backward compatibility and will understand older versions of the
protocols. So, why is it important for someone using DOS, Minix, MiNT
(Atari) and other operating systems I never hear about to have the latest
version? I really can't understand why someone is using it today. Maybe
some crazy youtube video. But.. Not anything real...
Can someone show a scenario where the last up-to-date curl can be useful
for their end-of-life operation system without any more support?
In the same way, I think this discussion is so bizarre. Change from C89 to
C99 makes... no sense... Why not jump to C17, the last standard version.
Why in 33 years have you never changed? And, so... Why now? Why not in 5
years in the future?
This kind of retro compatibility makes now sense in my world! :)
Em sex., 23 de set. de 2022 às 04:23, Dan Fandrich via curl-library <
curl-library_at_lists.haxx.se> escreveu:
> On Thu, Sep 22, 2022 at 10:02:04AM -0500, Kevin R. Bulgrien via
> curl-library wrote:
> > By advocating for "our responsibility" to avoid backwards compatibility
> > because it "promotes irresponsibility", comes off to some of us as, well,
> > so sad to be you, a responsible person, because we are going to rip away
> > your ability to be responsible, because we despise the actions of others
> > and because it makes our lives easier. Mind you, having done these hard
> > things, I appreciate making lives easier, but I also greatly appreciate
> > the additional effort by others to make my life easier too.
>
> I'm glad that my C89 fixes to curl (as well as those of countless other
> contributors) have helped over the years, as they also helped me, but it's
> not
> the 20th century any more. Sorry, you're not entitled to a free program
> that
> meets your every need indefinitely into the future. Most curl developers
> do
> this work on curl not because they have to, but because they want to. 24
> years
> ago, they wanted to (perhaps by default) maintain compatibility with a 9
> year
> old language standard. Today, there are fewer who want to maintain
> compatibility with a 33 year old language.
>
> > So essentially, if I follow the logic here, I am actually, an
> irresponsible
> > person because I have empowered someone to continue to run an old system
> -
> > as if I was irresponsible myself, even though, by doing what I am, there
> > has been a reduction in potential negative impact of a decision I have no
> > ultimate control over. So, yeah, I don't want any part of that kind of
> > thinking. I actually doubt that is what was intended, but that is how it
> > reads.
>
> If an ancient system you're working, despite the hard effort you're
> putting in
> to make it secure, gets hacked, added to a botnet then DDoSes one of my
> servers, then yes, you bear a part of the responsibility for allowing that
> foreseeable result to happen. I maintain it's impossible to harden a
> ancient,
> closed-source system to make it impervious to attack. It's awfully hard to
> do
> so in a modern, open-source system, but you can at least get a lot closer,
> a
> lot easier. And arguing that you're only following the orders of your
> employer
> to do so doesn't absolve you.
>
> But, this isn't the only or even the main reason to drop C89 support.
> Please
> don't fixate on it.
>
> > Please don't accuse someone that
> > patched libssh2, openssl 3.0.3, submitted patches to curl, and made this
> > thing, of actually being irresponsible for doing so without first
> engaging
> > at a level that can help you see what kind of person I actually am and
> what
> > I actually do with respect to placing pressure toward or away from good.
>
> I don't know you I don't recall looking at your patches, and I'm not
> passing
> judgement on you or your code. Clearly, you've considered some of the
> risks of
> maintaining legacy systems on the Internet already. My main point is that
> there's comes a time to raise the bar for the minimal system that a modern
> curl
> needs to run on and that making extra effort to help the few legacy legacy
> systems out there is no longer worthwhile.
>
> Dan
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
>
Date: Fri, 23 Sep 2022 16:07:22 -0300
This comment may be very off-topic, this is just my curiosity:
My question is WHY???
Why does the old system need the new version of curl? Why just don't use
the last version that supports it? You can say that some protocols update
over time and it needs to be used. OK, I understand. But... Servers can
have backward compatibility and will understand older versions of the
protocols. So, why is it important for someone using DOS, Minix, MiNT
(Atari) and other operating systems I never hear about to have the latest
version? I really can't understand why someone is using it today. Maybe
some crazy youtube video. But.. Not anything real...
Can someone show a scenario where the last up-to-date curl can be useful
for their end-of-life operation system without any more support?
In the same way, I think this discussion is so bizarre. Change from C89 to
C99 makes... no sense... Why not jump to C17, the last standard version.
Why in 33 years have you never changed? And, so... Why now? Why not in 5
years in the future?
This kind of retro compatibility makes now sense in my world! :)
Em sex., 23 de set. de 2022 às 04:23, Dan Fandrich via curl-library <
curl-library_at_lists.haxx.se> escreveu:
> On Thu, Sep 22, 2022 at 10:02:04AM -0500, Kevin R. Bulgrien via
> curl-library wrote:
> > By advocating for "our responsibility" to avoid backwards compatibility
> > because it "promotes irresponsibility", comes off to some of us as, well,
> > so sad to be you, a responsible person, because we are going to rip away
> > your ability to be responsible, because we despise the actions of others
> > and because it makes our lives easier. Mind you, having done these hard
> > things, I appreciate making lives easier, but I also greatly appreciate
> > the additional effort by others to make my life easier too.
>
> I'm glad that my C89 fixes to curl (as well as those of countless other
> contributors) have helped over the years, as they also helped me, but it's
> not
> the 20th century any more. Sorry, you're not entitled to a free program
> that
> meets your every need indefinitely into the future. Most curl developers
> do
> this work on curl not because they have to, but because they want to. 24
> years
> ago, they wanted to (perhaps by default) maintain compatibility with a 9
> year
> old language standard. Today, there are fewer who want to maintain
> compatibility with a 33 year old language.
>
> > So essentially, if I follow the logic here, I am actually, an
> irresponsible
> > person because I have empowered someone to continue to run an old system
> -
> > as if I was irresponsible myself, even though, by doing what I am, there
> > has been a reduction in potential negative impact of a decision I have no
> > ultimate control over. So, yeah, I don't want any part of that kind of
> > thinking. I actually doubt that is what was intended, but that is how it
> > reads.
>
> If an ancient system you're working, despite the hard effort you're
> putting in
> to make it secure, gets hacked, added to a botnet then DDoSes one of my
> servers, then yes, you bear a part of the responsibility for allowing that
> foreseeable result to happen. I maintain it's impossible to harden a
> ancient,
> closed-source system to make it impervious to attack. It's awfully hard to
> do
> so in a modern, open-source system, but you can at least get a lot closer,
> a
> lot easier. And arguing that you're only following the orders of your
> employer
> to do so doesn't absolve you.
>
> But, this isn't the only or even the main reason to drop C89 support.
> Please
> don't fixate on it.
>
> > Please don't accuse someone that
> > patched libssh2, openssl 3.0.3, submitted patches to curl, and made this
> > thing, of actually being irresponsible for doing so without first
> engaging
> > at a level that can help you see what kind of person I actually am and
> what
> > I actually do with respect to placing pressure toward or away from good.
>
> I don't know you I don't recall looking at your patches, and I'm not
> passing
> judgement on you or your code. Clearly, you've considered some of the
> risks of
> maintaining legacy systems on the Internet already. My main point is that
> there's comes a time to raise the bar for the minimal system that a modern
> curl
> needs to run on and that making extra effort to help the few legacy legacy
> systems out there is no longer worthwhile.
>
> Dan
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
>
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-23