But if BUK claims that sundial stopped because of him

No, he claimed that he saw through SunnyD before anyone else. I agree with that claim.

As a long time student of the fascinating SunnyD-Buk relationship, I'd say that SunnyD certainly did not stop coming here because of Buk -- on the contrary, SunnyD adored the attention so lovingly lavished on him by his "esteemed colleague" Buk, as indicated below:

• Re: Perl/Tk code structure: "Agreeing fully with BrowserUK's previous comments on this"
• Re: What's Wrong with program: "such ideas having already been given to you, and in great detail by experts such as BrowserUK"
• Re^4: Faster push and shift: "Quite obviously, BrowserUK very routinely processes gigantic datasets during the course of his work day. He is quite the expert on those (what are to many of us...) edge cases. Upvoted."
• Re^2: About self-invoked threads into class: "Such a thorough and well-reasoned explanation certainly should convince anyone. Upvoted."
• Re: Temp variable performace vs Inline behavior: "Apart from the performance/capacity "edge cases" that I openly acknowledge BrowserUK (in particular) deals with every day"
• Re: Concurrent Cache Pattern: "I say this in all seriousness, BrowserUK could whip one up in about three minutes"
• Re: how apply large memory with perl?: "BrowserUK's algorithm is of course more efficient, and he has the RAM."
• Re^3: Perl 5 Optimizing Compiler: "BrowserUK, I specifically acknowledge that your work is an exception to that statement, and very impressive work it certainly is."
• Re^3: var comparison: "with the notable exception of the very valid edge-cases that my esteemed colleague, BrowserUK, routinely and legitimately encounters in his daily work"
• Re: module w/ object-oriented and functional interfaces: best practices?: "Echoing BrowserUK’s comments, and after up-voting his post, ..."
• Re: Parallel processing with ForkManager: "BrowserUK’s subsequent recommendation to use temporary tables and a join-query, below, is in my view unquestionably the best approach"
• Re: Comparing sets of phrases stored in a database?: "As a slight parenthetical comment to BrowserUK’s excellent (and heavily up-voted) advice..."
• Re^3: Does IO::Select work? (Problem partially resolved): "If BrowserUK said it, yes, he is sure. And sure to be right. Seriously."
• Re: Evolving a faster filter?: "I am certain that this thread will attract the attention of BrowserUK, who is well-known about these parts to be especially expert in high-performance algorithms in high-volume situations. I especially look forward to his insights on this subject."
• Re: Threads and signals in Windows: "Excellent comments, BrowserUK. Very informative."
• Re^4: Threads and signals in Windows (invoking the name): "My response to you has been to commend your responses and to up-vote a great many of them. I have never down-voted a single one"
• Re: Does the main thread yield?: "as BrowserUK's elegant code example does by blocking the sender while the queue is too-large. (I really do think that you should put this little jewel into CPAN anyway, even if it uses an undocumented feature.)"
• Re^5: Optimization Help: "BrowserUK has a well-earned reputation for doing things like that"
• Re: Problem with Threaded Socket Server: "Adding one more thought (in case I missed it) to BrowserUK’s excellent recommendations here ... (++)x2"
• Re^4: Fastest way to download many web pages in one go?: "An excellent and well-reasoned analysis ...   “++”"
• Re^3: How to optimize CPU and Memory usage?: "You, BrowserUK, are constantly squeezing every ounce of capacity and performance out of a program ... because you quite legitimately need to, and you are obviously quite good at it."
• Re^3: Proper undefine queue with multithreads: "I simply suggest that you should follow BrowserUK’s sage advice exactly as given ... take BrowserUK’s excellent recommendations, and go"
• Re: Is 100% CPU utilisation during a procees is aproblem?: "In addition to what BrowserUK correctly suggests..."
• Re: RAM: It isn't free . . .: "Good sir, no matter how many times you throw garbage in my face, or throw gloves at my feet, I will (well, almost ...) never “downvote” any one of your posts, although I have up(!)voted quite a few"
• Re^5: RAM: It isn't free . . . (over-commit allocation -v- actual use): "A very good point ... (upvoted ... (P.S. believe it or not I don’t downvote you))."
• Re^2: Desperately need help with threaded socket: "I think that you, in particular, have an exceptionally clear “bit of clarity” to offer to in this sort of situation. I think that you are an expert whose insights will be particularly valuable here."
• Re: Multithreading How do I share hash of hash of arrays: "...as BrowserUK correctly insisted"
• Re: The Boy Scout Rule: "Hear, hear!"
• Re: Using threads to process multiple files: "Upvotes all around, sirs ... as BrowserUK excellently describes"
• Re^3: Process large text data in array: "We know that BrowserUK, in his daily $work, deals with enormous datasets in very high-performance situations. If he says what he just did about your situation, then, frankly, I would take it as a very well-informed directive to “do it that way.”"
• Re^4: write hash to disk after memory limit: "As BrowserUK noted, trying to invoke the memory-cleaner only makes this bad situation worse"
• Re^5: write hash to disk after memory limit: "I definitely want to suffix this post with all of the extremely-valid points that BrowserUK made ... As his Voice Of Experience™ says"
• Re: ithreads memory leak: "Truer words have never been spoken than what BrowserUK just so-well said"
• Re^3: Can I/O operations on the same IO::Socket be executed in different threads?: "Yes, I did up-vote (yes, I said up...) BrowserUK’s comments to this thread and to the other thread that he referred-to ... while also (intending to be) speaking very favorably of it."
• Re^5: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship: "Chuckle ... you ... actually ... said that ... to BrowserUK?! Quite obviously you have no idea that he is one of the most highly-respected Monks here ... and quite-deservedly so."
• Re^3: The problem of documenting complex modules.: "Excellent thread, BrowserUK ... very thought-provoking throughout, and showered with up-votes."
• Re^3: validate variable-length lines in one regex?: "as BrowserUK originally suggests below ... (All now liberally sprinkled with up-vote pixie-dust...)"
• Re: Perl seg fault while joining threads: "BrowserUK, you’ve had plenty of experience with both Perl threads and libraries. In your experience, does this Perl-specific COW behavior typically cause grief in cases like this one? (And, BTW, I mean that as a serious, face-value question, addressed to an expert in such things.)"
• Re^2: Looking for ideas: Converting a binary 'flags' field into something human readable: "That seems to me to be a “at least fairly genius” suggestion. Promptly upvoted."
• Re: Experimental features: autoderef vs postfix deref: "I will frankly agree with you, BrowserUK. (Upvoted.)"
• Re^6: Perl Hashes in C?: "Good sir, you responded quite brilliantly to this post, once again demonstrating your quick and well-seasoned technical skill. Every one of the posts in the thread promptly got up-votes from me as well as (I see) many others. Deservedly so."
• Re: How do you share an object(Telnet Session) between threads?: "As BrowserUK ably suggests..."
• Re: Imagination greater than reality?: "I will indeed specifically follow BrowserUK’s recommendation"
• Re: Perlish approach to parsing a binary blob: "BrowserUK is a recognized master of this sort of thing"
• Reaped: Re^2: Fastest way to lookup a point in a set: "there are IMHO very few people on this forum who have more practical experience in these matters than this respondent, BrowserUK"
• Re^3: Perl 6 on Windows 10: "I do, indeed, agree quite completely with BrowserUK’s voice of experience on this matter. (My laptop camera, if turned on, would right now confirm the presence of vigorous head-nodding on my part ...)"