3 ms·

Unlikely. Squashfs-tools-ng is not a fork but written from scratch after reverse engineering the format. I started it in early 2019 after being annoyed with va

Unlikely. Squashfs-tools-ng is not a fork but written from scratch after reverse engineering the format. I started it in early 2019 after being annoyed with various shortcomings in squashfs-tools and after trying to make sense out of the spaghetti source code to not only fix problems I ran into, but also add features I needed for a particular project. I saw the complete lack of activity on the official website and official git tree, from which I concluded it was pretty much dead. Of course I wanted to ask on the mailing list first (also pretty dead), but then I saw a thread from early 2018 talking about a release. Since the thread got a response that I interpreted as rather angry[1] and the release didn't happen a year later either, I concluded that the project is pretty much dead and decided to publish my own efforts and for lack of a better name simply named it "*-ng". Other people seemed to have drawn similar conclusions[2][3]. We all later found out that the squashfs-tools git tree was simply moved to GitHub (without updating the kernel docs or "official" website to indicate this). But even there, activity fixing bugs only picked up after I already made 3 or 4 releases and announced them on the squashfs mailing list. At which point I finally got a response in the form of a few somewhat unfriendly words[5][6][7] (IMO to some extent understandable, but still...). But after that, squashfs-tools version 4.4 fixed a bunch of issues that I publicly complained about and this release got apparently quite busy copying features that I found useful (and set squashfs-tools-ng apart, e.g. converting tarballs directly). Given the distinct source trees and, lets call it "competitive nature", I'd say a merge is unlikely and I will continue maintaining my package. I wrote it to solve some specific problems I had and it IMO does that job quite well. It's nice if other people find it useful and I'm also proud to have ended up indirectly contributing to the official squashfs-tools development by providing new motivation :-). [1] https://sourceforge.net/p/squashfs/mailman/message/36298345/ https://sourceforge.net/p/squashfs/mailman/message/36298345/ [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965 [3] https://news.ycombinator.com/item?id=20518019 https://news.ycombinator.com/item?id=20518019 [4] https://lkml.org/lkml/2019/8/1/1154 https://lkml.org/lkml/2019/8/1/1154 [5] https://github.com/AgentD/squashfs-tools-ng/issues/10 https://github.com/AgentD/squashfs-tools-ng/issues/10 [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#29 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#29 [7] https://lkml.org/lkml/2019/8/1/565 https://lkml.org/lkml/2019/8/1/565

ktm5j 5y ago
Honestly I think you could be a little more respectful of the project that inspired yours. I'd be angry too if someone reworked a project of mine with a similar name and made direct statements about my project (true or not) to try and sway people to your project. And you plagiarized part of his readme. Definitely understandable. And here you're still saying negative things, like pointing out shortcomings (that you don't describe) and calling it spaghetti code (which isn't immediately verifiable). Maybe he wouldn't be so angry at you if you didn't do these things.
- Osiris 5y ago
  Is it plagiarism if the license of the original source allows such copying and the author complied with the license? Isn't this outcome an expected one in which source code is made available to the public?
  - j16sdiz 5y ago
    plagiarism is about a mix of ethics, etiquette and respect. "comply with the license" is the minimal legal requirement. They are related, but it is not the same.
- zozbot234 5y ago
  > Honestly I think you could be a little more respectful of the project that inspired yours. Forking a poorly maintained project is the foremost kind of respect in the FLOSS community. Way too much useful code ends up bitrotting beyond recovery simply because of not enough people being willing to put in the challenging work involved in rescuing it. Note that there's absolutely no blame involved in describing a project as "poorly maintained" by commonly accepted standards. (In this case, the original author themselves describes suffering from severe burnout and other challenging circumstances which took a serious toll on their willingness to work on that codebase. So their situation is understandable indeed! Good FLOSS stewardship relies on other people being willing to step up promptly when these situations arise, regardless of the underlying causes.)
- st_goliath 5y ago

ktm5j 5y ago

Honestly I think you could be a little more respectful of the project that inspired yours. I'd be angry too if someone reworked a project of mine with a similar name and made direct statements about my project (true or not) to try and sway people to your project. And you plagiarized part of his readme. Definitely understandable. And here you're still saying negative things, like pointing out shortcomings (that you don't describe) and calling it spaghetti code (which isn't immediately verifiable). Maybe he wouldn't be so angry at you if you didn't do these things.

Osiris 5y ago
Is it plagiarism if the license of the original source allows such copying and the author complied with the license? Isn't this outcome an expected one in which source code is made available to the public?
- j16sdiz 5y ago
  plagiarism is about a mix of ethics, etiquette and respect. "comply with the license" is the minimal legal requirement. They are related, but it is not the same.
zozbot234 5y ago
> Honestly I think you could be a little more respectful of the project that inspired yours. Forking a poorly maintained project is the foremost kind of respect in the FLOSS community. Way too much useful code ends up bitrotting beyond recovery simply because of not enough people being willing to put in the challenging work involved in rescuing it. Note that there's absolutely no blame involved in describing a project as "poorly maintained" by commonly accepted standards. (In this case, the original author themselves describes suffering from severe burnout and other challenging circumstances which took a serious toll on their willingness to work on that codebase. So their situation is understandable indeed! Good FLOSS stewardship relies on other people being willing to step up promptly when these situations arise, regardless of the underlying causes.)
st_goliath 5y ago