Seriously, I have no interest in crc16 at all, and I don't think your 15 years of experience in cryptography deserves my respect. These are all old technologies. I just want to help people who have problems in Nuttx. I also hope that every time someone asks about the implementation of crc16, you can reply to them as soon as possible instead of hiding behind emails.
I won't reply to any messages from you anymore, I wish you all the best, thanks. BRs, Sebastien Lorquet <sebast...@lorquet.fr> 于2025年4月9日周三 17:17写道： > Why are you so unwilling to change your opinion? > > You are ready to break nuttx just for your comfort, in whatever way it may > take to advance your own agenda. That is very political. > > I dont like that. > > We need a consensus, and a majority of this thread is against the change > you want to make. So it should be cancelled. > > Rememeber this thread is a vote. My vote is No. Close the pull request. Do > another one that has chances to be consensually accepted. Let's vote again. > > > I will paste the quote that Greg posted in the thread about the modlib > change: > > > Rules for voting are a little different for code changes. > > The required Apache voting process is here: > https://www.apache.org/foundation/voting.html > > For code changes, that document says: "Votes on code modifications follow > consensus > approval<https://www.apache.org/foundation/glossary.html#ConsensusApproval> > <https://www.apache.org/foundation/glossary.html#ConsensusApproval>. In this > scenario, a negative vote constitutes a > veto<https://www.apache.org/foundation/voting.html#Veto> > <https://www.apache.org/foundation/voting.html#Veto>, which the voting group > (generally the PMC of a project) cannot override. Again, this model may be > modified by a lazy > consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> > <https://www.apache.org/foundation/voting.html#LazyConsensus> declaration > when the request for a vote is raised, but the full-stop nature of a negative > vote does not change. Under normal (non-lazy consensus) conditions, the > proposal requires three +1 votes and no -1 votes in order to pass; if it > fails to garner the requisite amount of support, it doesn't. Then the > proposer either withdraws the proposal or modifies the code and resubmits it, > or the proposal simply languishes as an open issue until someone gets around > to removing it." > And "For code-modification votes, +1 votes are in favour of the proposal, but > -1 votes are vetos<https://www.apache.org/foundation/voting.html#Veto> > <https://www.apache.org/foundation/voting.html#Veto> and kill the proposal > dead until all vetoers withdraw their -1 votes. > Unless the proposer declares that the vote is using lazy > consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> > <https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 votes > are required for a code-modification proposal to pass." > > > > > Sebastien > > > On 09/04/2025 10:20, chao an wrote: > > I like your second option, so could we remove the implementation of both > crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart? > > BRs, > > Sebastien Lorquet <sebast...@lorquet.fr> 于2025年4月9日周三 16:00写道： > >> Hello, >> >> once again, the number of usage is unimportant and irrelevant. >> >> The ONLY thing that matters is that when I call function POOP, it always >> does POOP. Not something else. >> >> Because users you are unaware of expect this function to do POOP and they >> may not be able to change their code. >> >> If you want different crc functions, use something else. >> >> >> A better example than the building: the zip format >> >> zip uses adler32 which is not even a proper crc and is largely suboptimal. >> >> zip developers NEVER changed this in decades, even if they know it's bad. >> Why? because otherwise, old zip files would become completely unusable. >> >> We have the same issue. >> >> The default crc is bad? OK, deal with it. Add better functions. Document >> everywhere that the default crc is deprecated and should not be used >> because more accurate functions are available. >> >> But dont change the damn thing. >> >> I am against changing the default implementation of the legacy function >> silently. >> >> I would be less mad if you REMOVED the old function rather than silently >> changing its behaviour. (that would still be bad, however) >> >> Sebastien >> >> >> On 09/04/2025 05:12, chao an wrote: >> >> I can empathize. But we just don't want to fill this regret again in the >> new building. >> The lack of standards is currently the biggest issue hindering the >> promotion of this proposal. >> Another interesting thing, I'd like to share another data from github: >> if we search for the lookup table of crc16 on GitHub, you'll find that >> CRC-16/IBM with a higher use rate: >> >> CRC-16/IBM: 3.1k >> >> https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code >> [image: image.png] >> >> CRC-16/XMODEM: 304 >> >> https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code >> >> [image: image.png] >> >> BRs, >> >> Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道： >> >>> On Wed, Apr 9, 2025 at 3:45 AM chao an <magicd...@gmail.com> wrote: >>> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lwa...@gmail.com> >>> wrote: >>> > > > > An open source project's ability to innovate should not be >>> > > > > held up by your preferences. >>> > > > >>> > > > The last sentence is completely wrong. Its not about "preference" >>> but >>> > > > impacting self-compatibility and long term maintenance. Messing the >>> > > > foundations and defaults is not innovation. Try building a home >>> when >>> > > > the project constantly changes during the process, when you have 10 >>> > > > floors ready and suddenly you need to change pavements. Innovation >>> is >>> > > > when you create new functionality and give users a choice without >>> > > > breaking existing working stuff. >>> > >>> > So you think it's more important to maintain your current 10 floors >>> > building, and it's none of your business if a 100 floors skyscraper >>> appears >>> > in the future? so could you afford all the developer time spent on this >>> > kind of problem? >>> >>> Anchao, what I meant was to finish 10 floor building as planned >>> (development), let people live inside that building (maintenance), and >>> move development resources to 100 floor building as planned, without >>> changing plans in the middle of construction, not getting stuck on 10 >>> floor building construction because plans change all the time and >>> never getting to that 100 floor building. Its good to have solid >>> immutable tools that you can depend on. Imagine there are devices >>> already deployed out there that may not be possible to update, yes >>> maintenance (in terms of keeping them inter-operational) may be the >>> priority in that case, because replacing all devices may wipe out the >>> company and leave owner with ubearable financial debt. >>> >>> I know this CRC is an important and quite hard problem, and I hope >>> there can be a win-win solution where users have choice when they need >>> one, thank you for bringing this up to the attention.. to be honest I >>> have no clue what is the best solution here if there is no standard to >>> relay on :-) >>> >>> -- >>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>> >>
