<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: xintron</title><link>https://news.ycombinator.com/user?id=xintron</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Fri, 29 May 2026 18:21:24 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=xintron" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by xintron in "Claude Opus 4.8"]]></title><description><![CDATA[
<p>Based on personal experience, seeing how Opus 4.6 still provides better (more nuanced, less totalitarian) answers than 4.7 - it's difficult to get exited for 4.8. Is this another "money grab" from Anthropic? Similar output between 4.6 and 4.7 yet 40x tokens. What's the value proposition from 4.8?</p>
]]></description><pubDate>Thu, 28 May 2026 21:44:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=48315952</link><dc:creator>xintron</dc:creator><comments>https://news.ycombinator.com/item?id=48315952</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48315952</guid></item><item><title><![CDATA[New comment by xintron in "I see a future in jj"]]></title><description><![CDATA[
<p>I see your point, but this feels like a difference in workflow philosophy, especially with AI-assisted coding becoming more common.<p>With jj, your working copy is always a commit. This encourages a "commit often and messy, clean up later" approach. You can rapidly iterate with or without AI, letting jj automatically save every change without stopping to craft perfect atomic commits.<p>Later, you use a simple jj squash to combine all those small, iterative changes into logical, clean commits before you share it. The atomicity is created retroactively, not upfront. For a finely-tuned magit workflow this might feel wrong, but for rapid, exploratory and AI-driven iteration, it's a more natural fit.</p>
]]></description><pubDate>Thu, 23 Oct 2025 07:02:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=45679025</link><dc:creator>xintron</dc:creator><comments>https://news.ycombinator.com/item?id=45679025</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45679025</guid></item><item><title><![CDATA[New comment by xintron in "Ghostty 1.0 Is Coming"]]></title><description><![CDATA[
<p>A good reason for Lua would be the example at the bottom of this page: <a href="https://wezfurlong.org/wezterm/config/launch.html#the-launcher-menu" rel="nofollow">https://wezfurlong.org/wezterm/config/launch.html#the-launch...</a><p>Custom settings depending on the environment you're in, here setting up PowerShell on windows only. Allowing the same flexibility through JSON/YAML would not be as easy and simple.</p>
]]></description><pubDate>Wed, 23 Oct 2024 14:35:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=41925444</link><dc:creator>xintron</dc:creator><comments>https://news.ycombinator.com/item?id=41925444</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41925444</guid></item><item><title><![CDATA[New comment by xintron in "Abandoning Gitflow and GitHub in favour of Gerrit"]]></title><description><![CDATA[
<p>I know they've talked about implement something similar. Since the Open letter to GitHub a lot have changed and I wouldn't be surprised to see GitHub support most of what Gerrit has (and more) in a near future.</p>
]]></description><pubDate>Tue, 05 Apr 2016 13:54:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=11430343</link><dc:creator>xintron</dc:creator><comments>https://news.ycombinator.com/item?id=11430343</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=11430343</guid></item><item><title><![CDATA[New comment by xintron in "Abandoning Gitflow and GitHub in favour of Gerrit"]]></title><description><![CDATA[
<p>We've been using it since May 2015. Vetos work well for us. We push new releases every week and often there are dependencies between the reviews (front-end waiting for a vetoed back-end review) which results in them being a non-issue (discussions happen frequently and updates are coming in quickly).</p>
]]></description><pubDate>Tue, 05 Apr 2016 13:51:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=11430331</link><dc:creator>xintron</dc:creator><comments>https://news.ycombinator.com/item?id=11430331</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=11430331</guid></item><item><title><![CDATA[Dealing with releases of single page applications]]></title><description><![CDATA[
<p>Article URL: <a href="http://www.beepsend.com/2016/03/10/dealing-releases-single-page-applications/">http://www.beepsend.com/2016/03/10/dealing-releases-single-page-applications/</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=11266158">https://news.ycombinator.com/item?id=11266158</a></p>
<p>Points: 10</p>
<p># Comments: 12</p>
]]></description><pubDate>Fri, 11 Mar 2016 12:27:00 +0000</pubDate><link>http://www.beepsend.com/2016/03/10/dealing-releases-single-page-applications/</link><dc:creator>xintron</dc:creator><comments>https://news.ycombinator.com/item?id=11266158</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=11266158</guid></item><item><title><![CDATA[New comment by xintron in "Static site generation on python"]]></title><description><![CDATA[
<p>For HTML generation Markdown is much easier for most people to get used to and understand. When needing to provide output in various formats reST is more suited but also have a bit of a steeper learning curve.<p>It depends on what you're doing. For documentation I'm always running reST but for articles for sites etc (with a static site generator) I will turn to Markdown.</p>
]]></description><pubDate>Thu, 14 Feb 2013 07:59:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=5218353</link><dc:creator>xintron</dc:creator><comments>https://news.ycombinator.com/item?id=5218353</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=5218353</guid></item></channel></rss>