<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: Cieric</title><link>https://news.ycombinator.com/user?id=Cieric</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sun, 11 Oct 2026 13:02:24 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=Cieric" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by Cieric in "OKI Develops 124-Layer PCB Technology"]]></title><description><![CDATA[
<p>Interesting, thanks for the info.</p>
]]></description><pubDate>Sat, 03 Oct 2026 05:01:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=49941475</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49941475</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49941475</guid></item><item><title><![CDATA[New comment by Cieric in "OKI Develops 124-Layer PCB Technology"]]></title><description><![CDATA[
<p>Shouldn't that have already been do-able? I know the The MOnSter 6502 is a thing. The 386 I have no idea about though, that's to far out of my wheel house.<p><a href="https://monster6502.com/" rel="nofollow">https://monster6502.com/</a></p>
]]></description><pubDate>Sat, 03 Oct 2026 04:03:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=49941268</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49941268</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49941268</guid></item><item><title><![CDATA[New comment by Cieric in "Factorio that you can touch"]]></title><description><![CDATA[
<p>I'm (hopefully) getting a G1X soon, so I think I'm going to put it to work printing this stuff out. I'm now excited for this as a use case and I kind of hope someone builds something to convert an existing factorio world into a 3d model, though it might be to big to actually print so maybe a way to take a section would be even better.</p>
]]></description><pubDate>Fri, 25 Sep 2026 15:29:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=49845976</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49845976</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49845976</guid></item><item><title><![CDATA[New comment by Cieric in "C++26: Standard Library Hardening Experiments"]]></title><description><![CDATA[
<p>Yeah, that sounds like the system I rediscovered. The only other thing I'm adding to try and lean more into that system are assertions(?) that are in the middle of a function, that can basically break it up into blocks on their own where the first block proves it true and the second block assumes it's true. So effectively the same thing as breaking it into 2 smaller functions. My main thing right now is, I'm fairly certain there is something wrong with my compiler, I'm a basically a novice in contracts, I'm intermediate in compilers, I'm a novice on SMT proofs, and I wrote the whole thing at this point using AI just to test an idea. So I'm just trying to throw everything I can at it to try and break it. I need to start building it again from scratch (without AI) so I can truly understand where it might break and what doesn't work.</p>
]]></description><pubDate>Tue, 01 Sep 2026 05:51:09 +0000</pubDate><link>https://news.ycombinator.com/item?id=49518411</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49518411</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49518411</guid></item><item><title><![CDATA[New comment by Cieric in "C++26: Standard Library Hardening Experiments"]]></title><description><![CDATA[
<p>Ah damn, okay. Long functions with a lot of sub calls is a known problem. I've been able to work around some of the issues tried to them by making every function an independent "compile unit." and then solving them each individually in the SMT solver. My experience in contract based programming is still relatively light, I won't lie there. The most I've had to do with contracts was ada, and even then it wasn't much. Everything else has been self enforced in languages without explicit support (and hence no compile time checking.)</p>
]]></description><pubDate>Mon, 31 Aug 2026 19:06:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=49513634</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49513634</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49513634</guid></item><item><title><![CDATA[New comment by Cieric in "C++26: Standard Library Hardening Experiments"]]></title><description><![CDATA[
<p>You sounds like you have more experience than me in this space (specifically contracts). I'm curious if you have any examples right off hand that would need whole program analysis. I need more examples to throw at my toy language that's not just another lock free work stealing queue.</p>
]]></description><pubDate>Mon, 31 Aug 2026 16:15:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=49511494</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49511494</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49511494</guid></item><item><title><![CDATA[New comment by Cieric in "C++26: Standard Library Hardening Experiments"]]></title><description><![CDATA[
<p>Yeah, I heard spark was used on a small component in the nvidia gpu firmware so others seemingly agree. I'm mainly in the user mode driver space so my ideas have been around having a kernel mode driver that (assuming a correctly functioning pc) can't crash and user mode drivers that can't be exploited (at least in the rop chain sense). I'm kind of picking ideas from other languages that I like zig's error handling, ada's contracts, rust's lifetimes (hopefully soon to be replaced with more contracts instead), and things like how you can use "gas" in lean to prove a loops will terminate. I'm mainly building it up with AI right now for experimentation, but I also can't really trust it to be correct either because of using AI. Once I settle on the syntax more and pump out a lot more tests, I'm probably going to rewrite the compiler by hand (hopefully in the custom language itself.)</p>
]]></description><pubDate>Mon, 31 Aug 2026 16:11:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=49511442</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49511442</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49511442</guid></item><item><title><![CDATA[New comment by Cieric in "C++26: Standard Library Hardening Experiments"]]></title><description><![CDATA[
<p>There is a small hint of it at the end, but I really hope compile time contract assertions become more common. I know some languages like spark, dafny and a few others do it and generate implicit contracts for things like divide by 0. I've been experimenting with my own custom language that do these things and going back to c++ every day at work is actually a slight let down because of it.</p>
]]></description><pubDate>Mon, 31 Aug 2026 15:49:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=49511185</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49511185</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49511185</guid></item><item><title><![CDATA[New comment by Cieric in "Better Gaussian Splatting in Julia"]]></title><description><![CDATA[
<p>It's been a while since I've tried to run it, but it's a mix of Nvidia and AMD GPUs and only AMD CPUs (everything portable is all AMD though and that's where my gripes are.) I'm sure the opencl backend has gotten better over time, but it always seems to drag behind the cuda backend. At this point I wish we could just have a vulkan backend and be done with it.<p>Thanks for bringing that up though, after a quick search that I guess I haven't done in a long time, it appears that colmap does now have a hip backend. So I guess that's going to be my weekend now.</p>
]]></description><pubDate>Sat, 15 Aug 2026 01:01:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=49306481</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49306481</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49306481</guid></item><item><title><![CDATA[New comment by Cieric in "Better Gaussian Splatting in Julia"]]></title><description><![CDATA[
<p>I'm sorry, but the article doesn't cover anything about the preprocessing steps that are required for 90% of gaussian splat implementations. That preprocessing step is almost always colmap which takes pictures or videos and uses SfM to figure out the camera parameters and their position in the 3d scene, it then does basic point reconstruction and dense point reconstruction. That info is what gaussian splats take in, it converts the points from a colmap project into gaussians and then optimizes them through differentiable rendering using backprop to optimize the gaussians to better match the images at the calculated positions of the camera from colmap. Looking over the project files also shows that they consume colmap projects, my question wasn't about the gaussian splat implementation, it was about the defacto standard colmap preprocessing step that is also required.</p>
]]></description><pubDate>Thu, 13 Aug 2026 20:26:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=49291389</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49291389</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49291389</guid></item><item><title><![CDATA[New comment by Cieric in "Better Gaussian Splatting in Julia"]]></title><description><![CDATA[
<p>Thanks, I've been exploring a lot of the papers and seeing what I can get working. Some of it really has been interesting, but I just never seem to be able to get it to work well. I might just need to throw myself at it all a bit more. Thanks for the links though, I'll check them out.</p>
]]></description><pubDate>Thu, 13 Aug 2026 19:22:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=49290721</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49290721</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49290721</guid></item><item><title><![CDATA[New comment by Cieric in "Better Gaussian Splatting in Julia"]]></title><description><![CDATA[
<p>I'm still very fascinated by gaussian splatting, but the issue I always run into is the need to use colmap to generate the camera positions and get the initial point cloud. Which colmap effectively still needs Nvidia for dense point clouds last I checked. I'm curious though does anyone have anything else they've tried that worked well? I've tried a few different things (most of the time getting stuck on just compiling the thing) so I'm curious if anyone has any suggestions that I should focus more heavily on getting working. I have some poor quality videos I'd like to try and use and I'm willing to put in some manual work, but it feels like it's all automatic or nothing. Thanks for any suggestions that any of you have.</p>
]]></description><pubDate>Thu, 13 Aug 2026 17:53:41 +0000</pubDate><link>https://news.ycombinator.com/item?id=49289589</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49289589</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49289589</guid></item><item><title><![CDATA[New comment by Cieric in "I stopped trusting USB-C cable labels and started testing them"]]></title><description><![CDATA[
<p>Oh yeah, I do think it's the shielding. I was just kind of surprised by it since I've never bought a cable that's done that.</p>
]]></description><pubDate>Sat, 08 Aug 2026 03:02:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=49218545</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49218545</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49218545</guid></item><item><title><![CDATA[New comment by Cieric in "I stopped trusting USB-C cable labels and started testing them"]]></title><description><![CDATA[
<p>They also crackle out of the package, or at least the 5 I got did. Kind of sound like the thin glow sticks a bit.</p>
]]></description><pubDate>Fri, 07 Aug 2026 00:09:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=49204377</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49204377</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49204377</guid></item><item><title><![CDATA[New comment by Cieric in "Writing a Debugger from Scratch"]]></title><description><![CDATA[
<p>I feel like it's good to note since I missed it. This post is from Feb 13, 2023. He has up to 8 posts on this at this point which don't appear to be linked to from this post. I think linking to all of them would be a bit much, but they're all currently listed on his main page [1].<p>[1] <a href="https://www.timdbg.com/" rel="nofollow">https://www.timdbg.com/</a></p>
]]></description><pubDate>Fri, 24 Jul 2026 15:44:09 +0000</pubDate><link>https://news.ycombinator.com/item?id=49037345</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49037345</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49037345</guid></item><item><title><![CDATA[New comment by Cieric in "Introduction to Formal Verification with Lean Part 1"]]></title><description><![CDATA[
<p>Just in case anyone else decides to write along like the article suggests. I chose to use the live.lean-lang.org link, but it seems to default to a newer version of lean where the simp[xor] actually returns both sides still wrapped in the lambdas so the next simp[add_comm] will actually fail. The way to get around it is changing the version to v4.32.0 which the article doesn't seem to mention.</p>
]]></description><pubDate>Wed, 22 Jul 2026 17:53:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=49010726</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=49010726</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49010726</guid></item><item><title><![CDATA[New comment by Cieric in "Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK"]]></title><description><![CDATA[
<p>Yes, thanks for saying it more concisely/clearly than I did. Just cause I understand something doesn't mean I'm good at explaining it.</p>
]]></description><pubDate>Tue, 14 Jul 2026 17:59:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=48910686</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=48910686</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48910686</guid></item><item><title><![CDATA[New comment by Cieric in "Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK"]]></title><description><![CDATA[
<p>As someone who is in the rendering space for work. Having a higher framerate does help, but in a weird way. Basically the start of the frame rendering is what mostly dictates where objects are rendered. By getting a higher framerate the position of objects that you see in game are much closer to their "real" position. So it's less about seeing more frames at that point and more about seeing the most up to date information possible. Technically it could be possible to render the frame in sync with the framerate and just offset the rendering so it finishes right before it's pushed to the screen, but if you're slightly wrong you'll get really bad stuttering and the execution time of gpus and the cpu submitting the work isn't really deterministic.</p>
]]></description><pubDate>Tue, 14 Jul 2026 17:36:00 +0000</pubDate><link>https://news.ycombinator.com/item?id=48910311</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=48910311</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48910311</guid></item><item><title><![CDATA[New comment by Cieric in "Show HN: Getting GLM 5.2 running on my slow computer"]]></title><description><![CDATA[
<p>Being fully stopped at a stop light isn't putting my or anyone else's life in danger. If I have a phone in my hand the car is not moving. I also finished the comment before the light turned green so the phone also was no longer in my hand when I needed to start moving.</p>
]]></description><pubDate>Sat, 11 Jul 2026 01:17:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=48867540</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=48867540</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48867540</guid></item><item><title><![CDATA[New comment by Cieric in "Show HN: Getting GLM 5.2 running on my slow computer"]]></title><description><![CDATA[
<p>Let me know if you want to hear anything specific about it. It kind of works, so it's not something I recommend doing if it can be avoided, but as Roxxik pointed out there is much room for improvement since this was just a naive just get it to run experiment.</p>
]]></description><pubDate>Fri, 10 Jul 2026 15:11:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=48861054</link><dc:creator>Cieric</dc:creator><comments>https://news.ycombinator.com/item?id=48861054</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48861054</guid></item></channel></rss>