<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: maginx</title><link>https://news.ycombinator.com/user?id=maginx</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Fri, 17 Apr 2026 22:51:37 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=maginx" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by maginx in "A 10x Faster TypeScript"]]></title><description><![CDATA[
<p>I'm curious about the 10x via implementation in Go - couldn't it have been realized otherwise? Finding the hotspots, reimplementing them using better algorithms, if necessary move a few critical paths to native etc. Or even improving the JIT itself which might benefit all programs. Just wondering because I wouldn't think that the JIT-overhead was that much that you could gain 10x just reimplementing in Go (or C, assembly etc)... that is something I would only have expected if going from an interpreted context.</p>
]]></description><pubDate>Thu, 13 Mar 2025 19:43:05 +0000</pubDate><link>https://news.ycombinator.com/item?id=43356599</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=43356599</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43356599</guid></item><item><title><![CDATA[New comment by maginx in "It is not a compiler error (2017)"]]></title><description><![CDATA[
<p>That's not my experience - I've found a handful of accepted and verified bugs in major commercial compilers and all were in the codegen/backend, and the code to be generated was quite simple. In one case it was basically an array copy in Java byte code that got erroneously translated into what was effectively a "copy until zero termination" error.</p>
]]></description><pubDate>Mon, 24 Feb 2025 20:19:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=43164460</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=43164460</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43164460</guid></item><item><title><![CDATA[New comment by maginx in "It is not a compiler error (2017)"]]></title><description><![CDATA[
<p>Around 10 years ago I found a JIT bug in a JDK from a big Java vendor. A new version of a web application server had been applied. The production application crashed after around 30 minutes of running, almost simultaneously on both production sites. It was an internal checksum calculation in the application that failed - an obscure error never seen before. The upgrade was rolled back immediately. I was assigned to the case and of course didn't suspect a JIT error. But within a week of investigation I started suspecting it must be (but I didn't dare tell anyone!) and I eventually managed to show this and reproduce it consistently. The vendor confirmed and made a temporary workaround via switches that disabled some new optimizations. Later a real fix was shipped.<p>I've also found 3-4 JavaScript JIT compiler errors in major browsers, all confirmed. I was a developer on what was for its time a quite complicated JavaScript solution, so we tended to encounter obscure JavaScript errors before others.</p>
]]></description><pubDate>Mon, 24 Feb 2025 17:44:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=43162473</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=43162473</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43162473</guid></item><item><title><![CDATA[New comment by maginx in "S1: A $6 R1 competitor?"]]></title><description><![CDATA[
<p>I agree  - I don't know what field it formally is, but computer science it is not. It is also related to information retrieval aka "Google skills", problem presentation, 'theory of mind', even management and psychology. I'm saying the latter because people often ridicule AI responses for giving bad answers that are 'too AI'. But often it is simply because not enough context-specific information was given to allow the AI to giving a more personalized response. One should compare the response to "If I had asked a random person on the internet this query, what might I have gotten". If you write "The response should be written as a <insert characteristics, context, whatever you feel is relevant>" it will deliver a much less AI. This is just as much about how you pose a problem in general, as it is about computer science.</p>
]]></description><pubDate>Thu, 06 Feb 2025 20:47:09 +0000</pubDate><link>https://news.ycombinator.com/item?id=42966331</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42966331</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42966331</guid></item><item><title><![CDATA[New comment by maginx in "Bzip3: A spiritual successor to BZip2"]]></title><description><![CDATA[
<p>Agreed - I've worked with PKI in many years, and know why the various systems work...in terms of "why you can decrypt again", not in terms of why it is secure (no other way to decrypt) which no one really knows. But if we assume for a moment the systems are secure, it is truly fascinating when thinking about it in abstract terms: Who would have thought, it is possible to give someone an exact recipe to follow that scramble a message to be sent... we can consider e.g. an encryption routine where the public key is inline so it is really just a standalone scrambling problem. Even though it is completely public, it can only be used to scramble and not unscramble. The sender who literally went through the steps to scramble the message, cannot undo what they just did. (the sender could have saved the original before scrambling!). And it is not because data is thrown away it can't be unscrambled - all the information is there there, fully recoverable, but only by the person who made the scrambling-recipe and there's no practical way to deduce this unscrambling recipe from the scrambling recipe.</p>
]]></description><pubDate>Sun, 02 Feb 2025 18:00:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=42910348</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42910348</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42910348</guid></item><item><title><![CDATA[New comment by maginx in "Bzip3: A spiritual successor to BZip2"]]></title><description><![CDATA[
<p>I feel exactly the same, and have also implemented it backwards and forwards. I've thought about it in my sleep, trying to recall how it REALLY works. Happens every few years ;-) I always thought it was probably obvious to everyone else what the "magic" is.</p>
]]></description><pubDate>Sun, 02 Feb 2025 17:41:51 +0000</pubDate><link>https://news.ycombinator.com/item?id=42910210</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42910210</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42910210</guid></item><item><title><![CDATA[New comment by maginx in "UK's hardware talent is being wasted"]]></title><description><![CDATA[
<p>Probably what was built was a Fusor. There's tons of instructions how to build one (<a href="https://fusor.net/board/" rel="nofollow">https://fusor.net/board/</a>) and seemingly there's a lot of focus on how "young" the builders of such are. Just google: fusion reactor teenager. In some of the stories it become apparent the fusor was never actually even finished but just along the way.<p><a href="https://newsforkids.net/articles/2024/09/04/16-year-old-student-builds-nuclear-fusion-reactor/" rel="nofollow">https://newsforkids.net/articles/2024/09/04/16-year-old-stud...</a>
<a href="https://online.kidsdiscover.com/quickread/arkansas-teen-builds-nuclear-reactor-in-garage" rel="nofollow">https://online.kidsdiscover.com/quickread/arkansas-teen-buil...</a>
<a href="https://interestingengineering.com/energy/nuclear-fusion-reactor-by-teenager-achieved-plasma" rel="nofollow">https://interestingengineering.com/energy/nuclear-fusion-rea...</a>
...</p>
]]></description><pubDate>Mon, 20 Jan 2025 18:22:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=42771501</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42771501</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42771501</guid></item><item><title><![CDATA[New comment by maginx in "AI in the 80s? How a Simple Animal Guessing Game Pioneered Machine Learning"]]></title><description><![CDATA[
<p>Yes the whole tone of voice is typical of LLM's as well.</p>
]]></description><pubDate>Sun, 12 Jan 2025 21:46:31 +0000</pubDate><link>https://news.ycombinator.com/item?id=42677262</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42677262</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42677262</guid></item><item><title><![CDATA[New comment by maginx in "AI in the 80s? How a Simple Animal Guessing Game Pioneered Machine Learning"]]></title><description><![CDATA[
<p>I don't think so. Consider <i>"It didn’t just attempt to guess the chosen animal but also learned from its mistakes, adding new questions and answers to its knowledge base. What’s more, it had the ability to save progress and load it during the next run."</i>. Data persistence across trials is already implied by the first sentence, so what would the next <i>"What's more, ..."</i> part refer to - it mentions "saving" and "loading"? Even if we grant "saving" to mean updating the in-memory data structure, what would "loading" refer to? Also note the later <i>"No ability to save progress"</i> which directly contradicts <i>"It had the ability to save progress"</i>. These sentences, both clearly referring to the original, are in direct contraction with each other and use the exact same terms. Inspection of the code shows that it clearly only saves the memory and not to disk.</p>
]]></description><pubDate>Sun, 12 Jan 2025 19:13:31 +0000</pubDate><link>https://news.ycombinator.com/item?id=42675991</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42675991</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42675991</guid></item><item><title><![CDATA[New comment by maginx in "AI in the 80s? How a Simple Animal Guessing Game Pioneered Machine Learning"]]></title><description><![CDATA[
<p>In two places the article states that the original game had the ability to save the updated tree ("it had the ability to save progress and load it during the next run" and "It is an amazing example... of how, even with such a simple language, ... and the ability to save new questions").<p>The later part says the opposite - that the original implementation had "No ability to save progress" and that this is new in the C++ implementation.<p>I can't help but wonder (also due to other language features) if the author ran the article through an AI to 'tidy up' before posting... because I've often found ChatGPT etc. to introduce changes in meaning like this, rather than just rewriting. This is not to dismiss either the article or the power of LLM's, just a curious observation :)</p>
]]></description><pubDate>Sun, 12 Jan 2025 08:35:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=42672128</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42672128</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42672128</guid></item><item><title><![CDATA[New comment by maginx in "US newspapers are deleting old crime stories, offering subjects a 'clean slate'"]]></title><description><![CDATA[
<p>I also think search engines sometimes remove results based on subject requests - at least I've seen such notices in Google search results, that some hits were removed due to 'right to be forgotten' policies.<p>Unpopular opinion (it seems): I think it is OK to some extent. Not for serious crimes (violence, murder etc.) but there's an awful lot of 'lesser crimes' reported with full names where I think subjects might deserve a clean slate or where people have some right to privacy. In the extreme case, everything court-related and all infractions could be public and subject to auto-generated news, and forever searchable: traffic fines, civil cases, neighbor complaints (either way) etc. All parts of an immutable record for everyone to look up by name. I personally think that is a violation of privacy, so it has to be balanced. Maybe the best balance is not to write the names to begin with.<p>In Denmark where I'm from, court cases are almost always public and the subject names are read aloud as well; however the names are not listed on the court lists or in the publicly accessible version of the verdicts. In order for the media to learn the name, a journalist has to physically go and see the trial. This already prevents automation and ensures prioritization by the media. Furthermore, most news media have a policy of only writing the subject's name after a guilty verdict has been found and even then only if the verdict was of some severity (unless it is a public person). I just checked on media outlet and their policy was to only write the name in case of a custodial sentence of at least 24 months. If it weren't for such policies, even relatively small cases would be reported with full name and be searchable forever.</p>
]]></description><pubDate>Sat, 04 Jan 2025 21:41:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=42597886</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42597886</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42597886</guid></item><item><title><![CDATA[New comment by maginx in "In Memoriam: Noah Gibbs"]]></title><description><![CDATA[
<p>I think it’s very human to be curious about the cause, but it can also be inappropriate, though some ways are more harmful than others. I've seen people ask very direct questions where it seemed their real interest was to assess whether the cause posed a risk to themselves or was something they could avoid. While this reaction is natural, it is also prioritizing personal concerns over the needs of those grieving, who don't have the possibility of changing the circumstances.<p>Furthermore, such questions can sometimes come across—or even be—blameful. For instance, asking 'What cancer did they die of?', 'Were they a smoker?', 'Were they obese?', or 'Did they work with chemicals?' might suggest judgment or responsibility, even if that’s not the intent. And as mentioned, sometimes it actually IS the intent (trying to find a way the person caused this on themselves), even if the person asking tries to cloak this, perhaps also to themselves. This can add unnecessary pain to those grieving.</p>
]]></description><pubDate>Fri, 03 Jan 2025 23:28:05 +0000</pubDate><link>https://news.ycombinator.com/item?id=42590618</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42590618</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42590618</guid></item><item><title><![CDATA[New comment by maginx in "Benchmarking RSA Key Generation"]]></title><description><![CDATA[
<p>The size/computational complexity of usage also only grows as a polynomial with RSA. But even with this in mind, a quantum computer that can crack in polynomial time is still problematic. While you can increase the key size, the operator of the quantum computer could enlarge his computer, a true cat-and-mouse game. Unlike the current situation where usage complexity grows as a polynomial, while cracking grows exponentially. This difference is the reason why we can pick key sizes where signing/decryption takes a millisecond while cracking it takes (presumably) billions of years.</p>
]]></description><pubDate>Fri, 03 Jan 2025 22:33:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=42590183</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42590183</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42590183</guid></item><item><title><![CDATA[New comment by maginx in "Benchmarking RSA Key Generation"]]></title><description><![CDATA[
<p>Encountering this by chance is exceedingly unlikely of course, if p and q are randomly generated. In probability terms it amounts to the first half of p (or q) all being zero (apart from a leading 1) so roughly 2^(-n/4) where n is the bit size of n. So for RSA 2048 the probability of this happening is on the order of 2^-512, or in base-10 terms 0.0000000...0000001, with roughly 150 zeros before the one!</p>
]]></description><pubDate>Fri, 03 Jan 2025 22:24:02 +0000</pubDate><link>https://news.ycombinator.com/item?id=42590102</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42590102</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42590102</guid></item><item><title><![CDATA[New comment by maginx in "Benchmarking RSA Key Generation"]]></title><description><![CDATA[
<p>I've seen many implementations that relied on iterating (or rather, they used a prime sieve but it amounts to the same thing in terms of the skewed distribution). While maybe not a problem in practice I always hated it - even for embedded systems etc. I always used pure rejection sampling, with a random one in each iteration.</p>
]]></description><pubDate>Fri, 03 Jan 2025 22:17:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=42590046</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42590046</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42590046</guid></item><item><title><![CDATA[New comment by maginx in "Benchmarking RSA Key Generation"]]></title><description><![CDATA[
<p>As I understand it, the number of rounds needed (for a given acceptable failure probability) goes down the larger the number is. Note (very importantly) that this is assuming you are testing a RANDOM integer for primality. If you are given an integer from a potential malicious source you need to do the full number of rounds for the given level.</p>
]]></description><pubDate>Fri, 03 Jan 2025 22:15:02 +0000</pubDate><link>https://news.ycombinator.com/item?id=42590020</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42590020</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42590020</guid></item><item><title><![CDATA[New comment by maginx in "Benchmarking RSA Key Generation"]]></title><description><![CDATA[
<p>I still see a lot of RSA especially for encryption. While ECC can be used for encryption it is more convoluted and much less supported in hardware, software etc. than RSA decryption/encryption.</p>
]]></description><pubDate>Fri, 03 Jan 2025 22:13:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=42590003</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42590003</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42590003</guid></item><item><title><![CDATA[New comment by maginx in "Benchmarking RSA Key Generation"]]></title><description><![CDATA[
<p>The performance of this can matter in some scenarios. In embedded systems, smart cards etc., generating the primes can take a significant amount of time (15-20 seconds typical) even with the 'low' number of iterations. Higher iterations means the user will have to wait even longer. Actually, in such systems it is not unusual to see occasional time-out errors and such when the smart card is unlucky with finding the primes. The timeout value may be a fixed, general value in a part of the stack difficult to change for the specific call.<p>Another case is short-term keys/certificates, where a fresh key pair is generated, and cert issues, for each and every signature. This setup makes revocation easier to handle (the certificate typically has a lifetime of a few minutes so it is 'revoked' almost immediately).<p>There are also scenarios where the keys are generated on a central system (HSM's etc.) to be injected into a production line or similar. There performance can matter as well. I worked on a system where the HSM's were used for this. They could typically generate an RSA key in 1-2 seconds, so 12 HSM's were needed to keep up with demand - and this was again with the reduced number of rounds.</p>
]]></description><pubDate>Fri, 03 Jan 2025 22:11:51 +0000</pubDate><link>https://news.ycombinator.com/item?id=42589996</link><dc:creator>maginx</dc:creator><comments>https://news.ycombinator.com/item?id=42589996</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42589996</guid></item></channel></rss>