4 ms·

As a consumer of source code, I do not use a graphical web browser to search and download from Sourceforge. A relatively simple http/https client will do. (Oc

As a consumer of source code, I do not use a graphical web browser to search and download from Sourceforge. A relatively simple http/https client will do. (Occasionally I have used cvs or svn if that is the only access.) Despite any changes in Sourceforge's ownership/management, I have not experienced any problems retrieving source code. I have not tried to use a graphical browser on Sourceforge since the 1990's. No need. As an end user of source code, I access Github the same way, without graphics. I do not need to use a web browser or any git executable to fetch a .zip or .tar.gz archive. Will this sort of easy access continue under the new management? I guess time will tell. Sourceforge still hosts a substantial quantity of what I consider educational/useful software. Of course, Github hosts exponentially more. Out of curiousity, using archived Github data, I am making a list of Github users and will be monitoring changes as the acquisition progresses. Will they lose many users? Where will the users who leave put their code? I am debating whether to also construct CSV files with repo names and descriptions for a personal Github database to aid in software discovery. I expect it might not be as easy to compile such a database in the future. I could be wrong, but it is impossible to predict what will happen. Time will tell.

exikyut 8y ago
> As a consumer of source code, I do not use a graphical web browser to search and download from Sourceforge. A relatively simple http/https client will do. One caveat: all the file download links end in .../download, so if I throw the URL at wget it will save "download?verylongblahblah=blahblah1234567890". I have to use `wget --content-d` (short for content-disposition) to actually save the name correctly. It's really annoying, but a behavior that has existed for many years. GitHub fixed this with everything, from release downloads to raw gist links, by putting the "download" attribute further back in the URL, and having everything after the final slash be the uploaded file's filename. Now THAT's nice.
- textmode 8y ago
  "Now THAT's nice." Yes it is. There is a certain consistency/uniformity to the url and site structure with Github that Sourceforge does not have, for whatever reason. Not to mention the absence of the mirror choosing routine. I really appreciate the ease and simplicity of Github downloads, which is precisely why I am concerned about the future.

exikyut 8y ago

> As a consumer of source code, I do not use a graphical web browser to search and download from Sourceforge. A relatively simple http/https client will do. One caveat: all the file download links end in .../download, so if I throw the URL at wget it will save "download?verylongblahblah=blahblah1234567890". I have to use `wget --content-d` (short for content-disposition) to actually save the name correctly. It's really annoying, but a behavior that has existed for many years. GitHub fixed this with everything, from release downloads to raw gist links, by putting the "download" attribute further back in the URL, and having everything after the final slash be the uploaded file's filename. Now THAT's nice.

textmode 8y ago
"Now THAT's nice." Yes it is. There is a certain consistency/uniformity to the url and site structure with Github that Sourceforge does not have, for whatever reason. Not to mention the absence of the mirror choosing routine. I really appreciate the ease and simplicity of Github downloads, which is precisely why I am concerned about the future.