<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: aforwardslash</title><link>https://news.ycombinator.com/user?id=aforwardslash</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Tue, 07 Apr 2026 07:17:52 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=aforwardslash" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by aforwardslash in "Claude Code is unusable for complex engineering tasks with the Feb updates"]]></title><description><![CDATA[
<p>Its not about prompting; its about planning and plan reviewing before implementing; I sometimes spend days iterating on specification alone, then creating an implementation roadmap and then finally iterating on the implementation plan before writing a single line of code. Just like any formal development pipeline.<p>I started doing this a while ago (months) precisely because of issues as described.<p>On the other hand,analyzing prompts and deviations isnt that complex..  just ask Claude :)</p>
]]></description><pubDate>Mon, 06 Apr 2026 20:02:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=47666218</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47666218</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47666218</guid></item><item><title><![CDATA[New comment by aforwardslash in "Issue: Claude Code is unusable for complex engineering tasks with Feb updates"]]></title><description><![CDATA[
<p>That is generically my experience as well. Claude half-assing work or skipping stuff because "takes too much time" is something I've been experiencing since I started using it (May 2025). Forcing it to create and review and implementation plan, and then reviewing the implementation cross-referenced with the plan almost always produces consistent results in my case.</p>
]]></description><pubDate>Mon, 06 Apr 2026 19:47:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=47665974</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47665974</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47665974</guid></item><item><title><![CDATA[New comment by aforwardslash in "Why I love FreeBSD"]]></title><description><![CDATA[
<p>Right, because linux security == init system used by some distros. My experience with FreeBSD may be somewhat dated (I've used it since the 4.x days, provided commercial support for it for more than 15 years), an that is not my experience -  at all. Obviously, it depends on the threat model you are considering and how far you want to go. The default install does not have (or had) sane security defaults, at least comparing to your random $ystemd linux distro; try installing both and give local shell to a red team and see how fast they get root access.</p>
]]></description><pubDate>Tue, 17 Mar 2026 08:22:19 +0000</pubDate><link>https://news.ycombinator.com/item?id=47409925</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47409925</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47409925</guid></item><item><title><![CDATA[New comment by aforwardslash in "Why I love FreeBSD"]]></title><description><![CDATA[
<p>Rule of thumb, its not. Common stuff like address randomization is a recent default, afaik still doesnt have random process ids, and the base permissions arent stellar. However I would prefer jails any day of the week vs the clusterf** that are namespaces and cgroups.</p>
]]></description><pubDate>Mon, 16 Mar 2026 22:33:02 +0000</pubDate><link>https://news.ycombinator.com/item?id=47405913</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47405913</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47405913</guid></item><item><title><![CDATA[New comment by aforwardslash in "Why I love FreeBSD"]]></title><description><![CDATA[
<p>I don't want to be <i>that</i> guy, but zfs on freebsd was kind-of-experimental until around 2012;AFAIK in 2012 (Freebsd 9) root on zfs was a manual process, and not that easy to upgrade. Root on zfs is somewhat "recent"- it took years to get to the installer. My company at the time was basically a bsd shop (openbsd and freebsd), and the opensolaris(12?) version was still quite ahead. Still have my opensolaris tshirt of "first 5000" :)</p>
]]></description><pubDate>Mon, 16 Mar 2026 22:20:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=47405784</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47405784</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47405784</guid></item><item><title><![CDATA[New comment by aforwardslash in "10% of Firefox crashes are caused by bitflips"]]></title><description><![CDATA[
<p>10% of 1000 isnt 10; its 100.And no, its not reasonable - the main reason is that you cannot reliably tell if something is a bit flip or not remotely, because bitflips affect both code and data. Also, 10% of a semi-obscure specific category of failures seems to indicate that the population submitting crashes isn't random enough. I'm a layman in statistics, but this doesn't seem correct, at least not without concrete details on the kinds of bugs being reported and the methodology used. Claiming 10% and being able to demonstrate 10% are different things - and the tweet thread indicates that is this clickbait - something in the lines of "may potentially be a bit-flip". Well, every error may be a bit flip.</p>
]]></description><pubDate>Fri, 06 Mar 2026 13:23:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=47274620</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47274620</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47274620</guid></item><item><title><![CDATA[New comment by aforwardslash in "10% of Firefox crashes are caused by bitflips"]]></title><description><![CDATA[
<p>I experience them in several different devices; On my main device, I have hundreds of chrome tabs and often many workloads running that would be completely corrupt with random bit flips. I'm not discarding the possibility of faulty RAM completely, I just take the measurement of the tweet with a huge grain of salt - after all, I still remember when the FF team constantly denied - for more than half a decade - that the browser had serious memory leak problems, so its not like there isn't a history of pointing out other causes for FF crashes.</p>
]]></description><pubDate>Fri, 06 Mar 2026 13:15:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=47274547</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47274547</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47274547</guid></item><item><title><![CDATA[New comment by aforwardslash in "10% of Firefox crashes are caused by bitflips"]]></title><description><![CDATA[
<p>Thing is, every reported bug can be a bit flip. You can actually in some cases have successful execution, but bitflips in the instrumentation reporting errors that dont exist.</p>
]]></description><pubDate>Fri, 06 Mar 2026 00:55:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=47269378</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47269378</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47269378</guid></item><item><title><![CDATA[New comment by aforwardslash in "10% of Firefox crashes are caused by bitflips"]]></title><description><![CDATA[
<p>> In some cases we have even seen crashes in non-memory instructions (e.g. MOV ZR, R1), which implicates misexecution: a fault in the CPU (or a bug in the telemetry bookkeeping, I suppose).<p>Thats the thing. Bit flips impact everything memory-resident - that includes program code. You have no way of telling what instruction was actually read when executing the line your instrumentation may say corresponds to the MOV; or it may have been a legit memory operation, but instrumentation is reporting the wrong offset. There are some ways around it, but - generically - if a system runs a program bigger than the processor cache and may have bit flips - the output is useless, including whatever telemetry you use (because it is code executed from ram and will touch ram).</p>
]]></description><pubDate>Fri, 06 Mar 2026 00:30:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=47269169</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47269169</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47269169</guid></item><item><title><![CDATA[New comment by aforwardslash in "10% of Firefox crashes are caused by bitflips"]]></title><description><![CDATA[
<p>ECC are traditionally slower, quite more complex, and they dont completely eliminate the problem (most memories correct 1 bit per word and detect 2 bits per word). They make sense when environmental factors such as flaky power, temperature or RF interference can be easily discarded - such as a server room. But yeah, I agree with you, as ECC solves like 99% of the cases.</p>
]]></description><pubDate>Fri, 06 Mar 2026 00:18:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=47269084</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47269084</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47269084</guid></item><item><title><![CDATA[New comment by aforwardslash in "10% of Firefox crashes are caused by bitflips"]]></title><description><![CDATA[
<p>Just updated with a comment. I see firefox crash routinely, so apparently our experiences are quite different :)</p>
]]></description><pubDate>Fri, 06 Mar 2026 00:12:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=47269038</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47269038</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47269038</guid></item><item><title><![CDATA[New comment by aforwardslash in "10% of Firefox crashes are caused by bitflips"]]></title><description><![CDATA[
<p>I forgot to mention - yes Im assuming 100% of firefox instances crash, if run long enough; I (still) use firefox as a second browser.</p>
]]></description><pubDate>Fri, 06 Mar 2026 00:11:19 +0000</pubDate><link>https://news.ycombinator.com/item?id=47269026</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47269026</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47269026</guid></item><item><title><![CDATA[New comment by aforwardslash in "10% of Firefox crashes are caused by bitflips"]]></title><description><![CDATA[
<p>Going to be downvoted, but I call bullshit on this. Bitflips are frequent (and yes ECC is an improvement but does not solve the problem), but not <i>that</i> frequent. One can either assume users that enabled telemetry are an odd bunch with flaky hardware, or the implementation isnt actually detecting bitflips (potentially, as the messages indicate), but a plathora of problems. Having a 1/10 probability a given struct is either processed wrong, parsed wrong or saved wrong would have pretty severe effects in many, many scenarios - from image editing to cad. Also, bitflips on flaky hardware dont choose protection rings - it would also affect the OS routines such as reading/writing to devices and everything else that touches memory. Yup, i've seen plenty of faulty ram systems (many WinME crashes were actually caused by defective ram sticks that would run fine with W98), it doesnt choose browsers or applications.</p>
]]></description><pubDate>Fri, 06 Mar 2026 00:06:31 +0000</pubDate><link>https://news.ycombinator.com/item?id=47268982</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47268982</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47268982</guid></item><item><title><![CDATA[New comment by aforwardslash in "Will vibe coding end like the maker movement?"]]></title><description><![CDATA[
<p>Coding is just one of many possible skills you use as a maker; do you think everyone into 3d printing is a stm32 programmer or designs and manufactures their own pcb's? Of course not. Software is just a component. If your kick is software, great; but it doesnt need to be. Also, just because you use an LLM it doesnt mean one is not learning; how do you think you learned how to speak?</p>
]]></description><pubDate>Fri, 27 Feb 2026 18:46:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=47184016</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47184016</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47184016</guid></item><item><title><![CDATA[New comment by aforwardslash in "Will vibe coding end like the maker movement?"]]></title><description><![CDATA[
<p>>You have no idea what codebases I've seen and worked in, so don't assume I have not.<p>Why not? You've been quite confortable assuming things so far, without actually contributing anything of substance to the conversation. Your opinions may even be well-formed, but if they are, your communication skills clearly aren't.<p>So, how has been your experience using LLMs as a maker (the actual topic) or in the context of IoT development (the topic I was replying to)? Mine has been quite positive, ranging from ensuring specific blocks of assembly code are deterministic (instead of having to check dozens of pages in a manual, and count instructions at every adjustment), to building both code, test fixtures and build infrastructure, to generating documentation, to actually hunt and fix security and logic issues on older codebases.<p>When people read "vibecode" they assume a clueless intern operating Cursor without any idea of what he's doing (in part because of the overhype of misshaps of LLM-generated code), opposed to the old fox with decades of experience that knows every detail by heart. Thing is, the clueless intern will produce much better code with LLMs than without (and fewer defects, too), and the old fox will produce much more because it will delegate some tasks to coding agents instead of less senior team mates,and have results in hours, not weeks.</p>
]]></description><pubDate>Fri, 27 Feb 2026 06:22:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=47177194</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47177194</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47177194</guid></item><item><title><![CDATA[New comment by aforwardslash in "Will vibe coding end like the maker movement?"]]></title><description><![CDATA[
<p>Sure, and if it didn't is not complicated to add a new module. Thing is, the module does not support DMA. So, for the specific use case I gave, its not a good fit.</p>
]]></description><pubDate>Thu, 26 Feb 2026 19:20:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=47170743</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47170743</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47170743</guid></item><item><title><![CDATA[New comment by aforwardslash in "Will vibe coding end like the maker movement?"]]></title><description><![CDATA[
<p>I don't think it has slowed down; in fact,I think it has grown in the last few years. Sure, it is a niche - and will probably always be - but one never had such a low barrier of entry to build stuff and be creative; you have plenty of very powerful chips, somewhat usable SDKs, a ton of COTS ready to use components ranging from gps sensors to rotary encoders, and you can design your own pcbs and order them cheap from China; you can also design enclosures and 3d print parts in your own home with precision that was only accessible to specialized companies 15 years ago. LLMs are a great help not only on the code generation part, but also on the design part - as an example, I sometimes use ChatGPT to generate openscad functions, and it isn't half-bad.</p>
]]></description><pubDate>Thu, 26 Feb 2026 19:14:08 +0000</pubDate><link>https://news.ycombinator.com/item?id=47170664</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47170664</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47170664</guid></item><item><title><![CDATA[New comment by aforwardslash in "Will vibe coding end like the maker movement?"]]></title><description><![CDATA[
<p>Yes, because human-made code is risk-free. I suggest you actually look at a codebase of a proprietary device before forming a proper opinion.</p>
]]></description><pubDate>Thu, 26 Feb 2026 18:39:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=47170194</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47170194</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47170194</guid></item><item><title><![CDATA[New comment by aforwardslash in "Will vibe coding end like the maker movement?"]]></title><description><![CDATA[
<p>The other day I built a quick PoC to control 1024 rgb leds using RMT (esp32) and a custom protocol I was developing. Im pretty sure micropython would suck for that.<p>The other day I also developed a RGB-RGBW converter using a rp2040; claude did most of the assembly, so instead of taking a couple of days, it took a couple of hours.<p>I don't prefer no code; my point is software is a barrier on embedded systems, and if I - someone who can actually program in c/c++, python and assembly, see huge benefits in using LLMs, for someone at an entry level it is a life changer.</p>
]]></description><pubDate>Thu, 26 Feb 2026 18:36:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=47170133</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47170133</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47170133</guid></item><item><title><![CDATA[New comment by aforwardslash in "Will vibe coding end like the maker movement?"]]></title><description><![CDATA[
<p>So, because you don't see value in it, you assume its the same for everyone. Got it.<p>Also, its not about if there are better or more reliable options; that's the opposite of the maker mentality - you do it because it is useful, it is fun or just because you enjoy doing it.<p>Such as designing some light fixture, printing it, and illuminating it with an esp32 and some ws2812 leds. Yah you could spend an afternoon coding color transitions. Or use claude code for that.</p>
]]></description><pubDate>Thu, 26 Feb 2026 18:27:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=47169992</link><dc:creator>aforwardslash</dc:creator><comments>https://news.ycombinator.com/item?id=47169992</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47169992</guid></item></channel></rss>