<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: chmike</title><link>https://news.ycombinator.com/user?id=chmike</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sun, 24 May 2026 23:36:39 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=chmike" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[High-Temperature Superconductivity of Pure Mg Metals, UFOs and Cuprates]]></title><description><![CDATA[
<p>The retired physics professor Auguste Meessen [1] has studied the UFO phenomenon since the late 1960s. From witness reports, he concluded that these craft must use an electromagnetic propulsion system [2].<p>He then developed the Pulsed ElectroMagnetic Propulsion (PEMP) system [3]. The principle is that the vehicle generates an intense alternating magnetic field and ionises the surrounding air at precisely the right time and location. This produces a Lorentz force which, by reaction, propels the craft.<p>He went on to investigate how such an intense alternating magnetic field could be generated in practice. This led him to discover a new type of oscillator with remarkable properties — one that requires the outer shell of the craft to be superconducting [4]. This has the convenient side effect of shielding the occupants from the intense magnetic field. If correct, this implies that superconductivity at very high temperatures — well above room temperature — is not only feasible but has been mastered by whoever built these craft.<p>Professor Meessen then turned to the question of how such Very High Temperature Superconductivity (VHTS) might be physically possible. He has just completed this line of research with the publication of a new theory [5] explaining how magnesium could become such a superconductor. In the superconducting state, magnesium would form very strong bonds, which could account for the unusual physical properties reported for the Roswell fragments.<p>[1] https://www.meessen.net/AMeessen/
[2] https://www.meessen.net/AMeessen/UFO_Evidence_of_Very_Strong_Low_Frequency_Magnetic_Fields.pdf
[3] https://www.meessen.net/AMeessen/UFO_Pulsed_EM_Propulsion_of_Unconventional_Flying_Objects.pdf
[4] https://www.meessen.net/AMeessen/UFO_Production_of_EM_Surface_Waves_by_Superconducting_Spheres.pdf
[5] https://www.scirp.org/journal/paperinformation?paperid=149827</p>
<hr>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=47627331">https://news.ycombinator.com/item?id=47627331</a></p>
<p>Points: 1</p>
<p># Comments: 0</p>
]]></description><pubDate>Fri, 03 Apr 2026 14:52:44 +0000</pubDate><link>https://news.ycombinator.com/item?id=47627331</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=47627331</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47627331</guid></item><item><title><![CDATA[New comment by chmike in "Mox – modern, secure, all-in-one email server"]]></title><description><![CDATA[
<p>How does mox compare to maddy, another Go all in one mail server ? 
Does mox support antivirus addition ? Didn't see that in the docs but I may have skipped that section.</p>
]]></description><pubDate>Wed, 05 Mar 2025 06:51:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=43263638</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=43263638</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43263638</guid></item><item><title><![CDATA[New comment by chmike in "Russ Cox is stepping down as the Go tech lead"]]></title><description><![CDATA[
<p>humor: I wonder if the upvotes are cheerings that he finally stepped down or a respectful salute. I give my respectful salute.<p>Go is awesome and I hope it will continue to progress in that direction.  Thank you Russ Cox</p>
]]></description><pubDate>Fri, 02 Aug 2024 16:54:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=41140495</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=41140495</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41140495</guid></item><item><title><![CDATA[New comment by chmike in "A Dramatic Reading: I Will Fucking Piledrive You If You Mention AI Again"]]></title><description><![CDATA[
<p>While I agree that we're not there yet, I'm one of the people who assumes that it is feasible to beat humans intellectually.</p>
]]></description><pubDate>Sat, 06 Jul 2024 18:56:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=40892398</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=40892398</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=40892398</guid></item><item><title><![CDATA[New comment by chmike in "xz has shown how a dependence on unpaid volunteers can cause major problems"]]></title><description><![CDATA[
<p>The problem is not being unpaid. The problem is lack of verification and control, which itself result from lack of help and participation. You won't fix these problems by throwing money at it.</p>
]]></description><pubDate>Tue, 02 Apr 2024 16:01:49 +0000</pubDate><link>https://news.ycombinator.com/item?id=39907289</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=39907289</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39907289</guid></item><item><title><![CDATA[New comment by chmike in "AI-Generated Data Can Poison Future AI Models"]]></title><description><![CDATA[
<p>And human generated data may not ?</p>
]]></description><pubDate>Sat, 09 Mar 2024 17:06:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=39653021</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=39653021</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39653021</guid></item><item><title><![CDATA[New comment by chmike in "Falsehoods programmers believe about time zones (2020)"]]></title><description><![CDATA[
<p>What I don't understand is why computers and operating systems have not adopted the TAI as <i>time reference</i> which is monotonic, etc. Time is a complete mess.</p>
]]></description><pubDate>Tue, 13 Feb 2024 19:40:51 +0000</pubDate><link>https://news.ycombinator.com/item?id=39361883</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=39361883</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39361883</guid></item><item><title><![CDATA[New comment by chmike in "From slow to SIMD: A Go optimization story"]]></title><description><![CDATA[
<p>I would have tried parallelism just by curiosity. Split and spread the computation over multiple cores. If you have n cores you could get close to a factor n increase minus the cost of spreading the data and combining the results. That's an easy optimization right out of the box with go (no assembly required).</p>
]]></description><pubDate>Wed, 24 Jan 2024 08:12:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=39114881</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=39114881</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39114881</guid></item><item><title><![CDATA[New comment by chmike in "Caches: LRU vs. Random (2014)"]]></title><description><![CDATA[
<p>It depends on the distribution of probabilities of being used. If least recently used data has the same probability to be requested than the others, then random picking will do as well as LRU.<p>When the least recently used data does have a lower probability to be requested, than LRU will outperform random picking.<p>There is no silver bullet algorithm.</p>
]]></description><pubDate>Tue, 23 Jan 2024 07:48:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=39100620</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=39100620</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39100620</guid></item><item><title><![CDATA[New comment by chmike in "Peer review is an honor-based system (2008)"]]></title><description><![CDATA[
<p>The peer review system is definitely biased. It's ok for many articles, but there are outliers. For instance really original theories or experimental data. The publication may be stopped to avoid putting the journal's reputation at risk or because the reviewers have personal reasons to not support the article (it would shade their own pet theory, invalidate their research project, they didn't understood it, etc.).<p>The problem with publishing elsewhere is that many people unable to objectively evaluate the validity of the theory juge its value by the reputation of the journal. Also the other journal will most probably have less visibility. There is thus a higher chance that the other theory will not be reported in reviews.<p>There are many assumptions in the above comment that I can't agree with. But my experience is with physics, not computer science.</p>
]]></description><pubDate>Sun, 14 Jan 2024 07:35:19 +0000</pubDate><link>https://news.ycombinator.com/item?id=38988314</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=38988314</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38988314</guid></item><item><title><![CDATA[New comment by chmike in "Sieve is simpler than LRU"]]></title><description><![CDATA[
<p>The effectiveness really depends on the request pattern. In some use case, the LRU is the most efficient. When it is purely random, it obviously won't be the best as any value has the same probability to be selected.<p>Regarding simplicity, there is a simpler algorithm where we don't need the next and prev pointers. We simply replace the non-flagged value at the hand. This is most probably what is used in CPUs.</p>
]]></description><pubDate>Wed, 03 Jan 2024 10:45:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=38852628</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=38852628</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38852628</guid></item><item><title><![CDATA[New comment by chmike in "WebP is so great except it's not (2021)"]]></title><description><![CDATA[
<p>A close up section of the same zone in the images would make them visible. I could hardly see the artefacts in the first place as my attention was caught with the highly contrasted parts of the images.</p>
]]></description><pubDate>Fri, 15 Dec 2023 12:34:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=38653512</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=38653512</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38653512</guid></item><item><title><![CDATA[New comment by chmike in "A small warning about UDP based protocols"]]></title><description><![CDATA[
<p>I suggested the certificate solution but it's far from  being lightweight. I found a simpler solution that may fit some use cases.<p>The client sends a request, the server returns a response that may be big that also contains a random value. The client must return this random value in a thank you message.<p>If the server doesn't receive the thank you message, it slows down responses to that ip address and eventually blacklist it if it's repeated.<p>From the client perspective, the answer is obtained in one round trip time. The price to pay on the server is the need to keep track of the expected thank you messages, and the throttled or blacklisted addresses.</p>
]]></description><pubDate>Sun, 29 Oct 2023 06:53:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=38056347</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=38056347</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38056347</guid></item><item><title><![CDATA[New comment by chmike in "A small warning about UDP based protocols"]]></title><description><![CDATA[
<p>A three way handshake would be simpler and wouldn't waste cpu and energy.</p>
]]></description><pubDate>Sun, 29 Oct 2023 06:39:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=38056293</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=38056293</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38056293</guid></item><item><title><![CDATA[New comment by chmike in "A small warning about UDP based protocols"]]></title><description><![CDATA[
<p>Thank you. It's the best argument against the certificate suggestion I have read so far. It's a problem I overlooked.<p>Edit: If the server creates the certificate with a three way handshake, it will use the remote IP address. So the client doesn't have to know it's IP address</p>
]]></description><pubDate>Sat, 28 Oct 2023 16:52:44 +0000</pubDate><link>https://news.ycombinator.com/item?id=38051343</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=38051343</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38051343</guid></item><item><title><![CDATA[New comment by chmike in "A small warning about UDP based protocols"]]></title><description><![CDATA[
<p>I didn't mean to generalize the use of certificate. It would be for a specific protocol for a specific application. I just wanted to justify that we are not required to use three way handshake.<p>Revocation is indeed a weak point of this solution as it would take time, probably a transaction, to check. This problem might be mitigated by shortening the certificate validity duration.<p>I don't see why time synchronization would be critical if the validity periods are slightly overlapping.</p>
]]></description><pubDate>Sat, 28 Oct 2023 16:47:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=38051278</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=38051278</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38051278</guid></item><item><title><![CDATA[New comment by chmike in "A small warning about UDP based protocols"]]></title><description><![CDATA[
<p>In prior configuration, the UDP client must get a certificate which uses three way handshake to verify the IP address. Once a client has it's certificate, it can perform transactions with a simple two way transactions.</p>
]]></description><pubDate>Sat, 28 Oct 2023 16:33:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=38051131</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=38051131</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38051131</guid></item><item><title><![CDATA[New comment by chmike in "A small warning about UDP based protocols"]]></title><description><![CDATA[
<p>The problem result from the ability to forge a fake origin IP address. This can be avoided by adding a certificate for the IP address. It adds a processing and size overhead, but it also preserves the single round trip transaction.</p>
]]></description><pubDate>Sat, 28 Oct 2023 07:53:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=38048018</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=38048018</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38048018</guid></item><item><title><![CDATA[Introduction to the Conjugate Gradient Method Without Agonizing Pain (1994) [pdf]]]></title><description><![CDATA[
<p>Article URL: <a href="https://www.cs.cmu.edu/~quake-papers/painless-conjugate-gradient.pdf">https://www.cs.cmu.edu/~quake-papers/painless-conjugate-gradient.pdf</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=37109275">https://news.ycombinator.com/item?id=37109275</a></p>
<p>Points: 71</p>
<p># Comments: 15</p>
]]></description><pubDate>Sun, 13 Aug 2023 12:23:40 +0000</pubDate><link>https://www.cs.cmu.edu/~quake-papers/painless-conjugate-gradient.pdf</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=37109275</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=37109275</guid></item><item><title><![CDATA[Explanation of Cold Nuclear Fusion and Biotransmutations]]></title><description><![CDATA[
<p>A new theory [1] has just been published explaining cold fusion and biotransmutation.<p>Abstract<p>Low energy nuclear reactions are possible in condensed matter because of image forces. They result from induced charges at the surface of metals or very polarizable media. The height and width of the Coulomb barrier in free space can thus be reduced. Nuclear fusion requires also the formation of a compound nucleus in one of its excited states, but two deuterons yield an α particle that has 2 excited states. They are respectively accessible at high or low energies. Since the reduction of the Coulomb barrier depends on the local curvature of the interface, cold fusion becomes autocatalytic, but heat production is controllable. Even microbes, plants and animals can produce transmutations. They are also due to image forces. This solves a basic problem in nuclear physics and there are possible applications: facilitated synthesis of superheavy elements and development of a new type of energy sources. They are moderate, but safe.<p>[1] https://www.scirp.org/journal/paperinformation.aspx?paperid=125983</p>
<hr>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=36574522">https://news.ycombinator.com/item?id=36574522</a></p>
<p>Points: 2</p>
<p># Comments: 0</p>
]]></description><pubDate>Mon, 03 Jul 2023 15:42:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=36574522</link><dc:creator>chmike</dc:creator><comments>https://news.ycombinator.com/item?id=36574522</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=36574522</guid></item></channel></rss>