Comments by "Lawrence D’Oliveiro" (@lawrencedoliveiro9104) on "Private Security Patching Is A Nightmare In Open Source" video.

After the patch is done, you admit it was a fix for a security vulnerability, not before. The Samba project recently went through this. They had a fundamental problem involving symlinks, that took a year or more of rearchitecting the code to fix. Only when the job was done did they admit what the real purpose of those fixes was.
7
wget does bulk downloads better, curl does form uploads better. curl also implements a whole load of unnecessary protocols.
2
Curl is just unnecessarily complex. Most of the protocols it implements already have their own perfectly good clients. It should stick to HTTP/HTTPS.
1
@Fs3i Like I said, most of the complexity is unnecessary. There is no need to support protocols that already have their own purpose-built clients.
1
I had a look at the source code. Counting up the number of lines in files in subdirectories called “lib” and “src” for both projects, curl comes in at about 190,000 lines, while wget is only slightly smaller at about 180,000 lines. So while wget handles fewer protocols, it has more functions for working with them. Like in order to do recursive mirroring of a website, it has to do some HTML parsing. I would say, all the other protocols that curl implements, that wget does not, are unnecessary. For example, media streaming: what is the point, when ffmpeg is purpose-built not only for handling the connections, but also the necessary media packaging? Why bother with SCP/SFTP, when SSH clients already include that? Or SMB, when you have smbclient? And Telnet, of all things--what is the point with that?
1
@Fs3i I use those other protocols too, so don’t say I don’t. I just prefer the more advanced forms supported by their native tools, not the jack-of-all-trades-master-of-none versions in curl.
1
@Fs3i That’s why I don’t see the point in duplicating their functionality in curl.
1