<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: natbobc</title><link>https://news.ycombinator.com/user?id=natbobc</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sat, 13 Jun 2026 15:07:29 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=natbobc" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by natbobc in "Building an HTML-first site doubled our users overnight"]]></title><description><![CDATA[
<p>And that is what pixel tracking is for. :)</p>
]]></description><pubDate>Wed, 10 Jun 2026 15:58:49 +0000</pubDate><link>https://news.ycombinator.com/item?id=48478312</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=48478312</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48478312</guid></item><item><title><![CDATA[New comment by natbobc in "Building an HTML-first site doubled our users overnight"]]></title><description><![CDATA[
<p>Is entirely context dependent. I can agree in some scenarios but when it’s a utility or gov site that I can’t really avoid it’s less straightforward.</p>
]]></description><pubDate>Wed, 10 Jun 2026 15:39:05 +0000</pubDate><link>https://news.ycombinator.com/item?id=48478019</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=48478019</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48478019</guid></item><item><title><![CDATA[New comment by natbobc in "Unifi Travel Router"]]></title><description><![CDATA[
<p>If this has a wifi antenna port would be very useful for marina wifi if you’re sailing around.</p>
]]></description><pubDate>Wed, 24 Dec 2025 19:57:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=46378667</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=46378667</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46378667</guid></item><item><title><![CDATA[New comment by natbobc in "EVs are depreciating faster than gas-powered cars"]]></title><description><![CDATA[
<p>The article is comparing 2 scenarios that have other explanations: a fire sale of a large fleet and Tesla which has an image problem because of its leadership.<p>I’m not saying the article is wrong I’d just like to see broader representation (Chevy bolt, lucid air, etc).</p>
]]></description><pubDate>Fri, 17 Oct 2025 12:05:32 +0000</pubDate><link>https://news.ycombinator.com/item?id=45615768</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=45615768</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45615768</guid></item><item><title><![CDATA[New comment by natbobc in "Valve confirms credit card companies pressured it to delist certain adult games"]]></title><description><![CDATA[
<p>A vocal minority are freedom loving. A significant number are hooked on consumer debt. I feel like any sweeping generalization is going to be wrong… especially when referencing the USA which is basically 50 countries and has a population exceeding all of Western Europe.</p>
]]></description><pubDate>Sat, 19 Jul 2025 12:20:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=44614909</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=44614909</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44614909</guid></item><item><title><![CDATA[New comment by natbobc in "Ask HN: Kotlin SpringBoot vs. Python Django for Min Viable Product"]]></title><description><![CDATA[
<p>> I am a backend developer using Spring Boot and Java.<p>If your goal is speed to market use what you know which is Spring Boot and Java.<p>If your aim is to learn something new then go with Django or sprinkle in some Kotlin incrementally (eg tests). I don’t think it’ll matter in the long run which you choose.<p>Conflating I want to learn something new with I want to deliver quickly will give you a suboptimal outcome for both.</p>
]]></description><pubDate>Sun, 22 Sep 2024 13:07:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=41616789</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=41616789</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41616789</guid></item><item><title><![CDATA[New comment by natbobc in "Who uses Google TPUs for inference in production?"]]></title><description><![CDATA[
<p>Feels like a bad point in the curve to try and sell them. “Oh our internal hypecycle is done… we’ll put them in the market now that they’re all worn out.</p>
]]></description><pubDate>Mon, 11 Mar 2024 22:08:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=39673799</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=39673799</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39673799</guid></item><item><title><![CDATA[New comment by natbobc in "NSQ: Open-source realtime distributed messaging, billions of messages / day"]]></title><description><![CDATA[
<p>Probably that’s the scenario. You want something simple and narrowly focused. Advanced and infinitely configurable isn’t always a virtue.</p>
]]></description><pubDate>Wed, 10 Jan 2024 03:36:45 +0000</pubDate><link>https://news.ycombinator.com/item?id=38935821</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=38935821</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38935821</guid></item><item><title><![CDATA[New comment by natbobc in "NSQ: Open-source realtime distributed messaging, billions of messages / day"]]></title><description><![CDATA[
<p>Looks like a release about 2 weeks ago but otherwise not sure.</p>
]]></description><pubDate>Wed, 10 Jan 2024 03:35:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=38935815</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=38935815</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38935815</guid></item><item><title><![CDATA[New comment by natbobc in "NSQ: Open-source realtime distributed messaging, billions of messages / day"]]></title><description><![CDATA[
<p>I find it mildly devious when numbers are inflated by changing the period from seconds to days.<p>Aeron and NSQ have slightly different design principles. Which can easily be identified in their feature list. Aeron’s origins are exchanges for fintechs and focus on predictable low latency with a tight standard deviation. NSQ puts heavy emphasis on being a distributed broker less message queue. Performance alone probably isn’t a good basis to measure their utility.</p>
]]></description><pubDate>Wed, 10 Jan 2024 03:34:51 +0000</pubDate><link>https://news.ycombinator.com/item?id=38935811</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=38935811</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38935811</guid></item><item><title><![CDATA[New comment by natbobc in "Kubernetes Needs an LTS"]]></title><description><![CDATA[
<p>It’s all swings and roundabouts has been since the broad adoption of computers. I expect in a few years time when everyone’s forgotten the pain points that drove them to decentralize there’ll be a big move to centralize again. Someone will get a gold star for coming up with the idea and being able to demonstrate the “cost savings”. Of course it’ll completely ignore the general disruption to all of the product teams as they adapt to the new world order but what’s a company without a little busy work.</p>
]]></description><pubDate>Sat, 16 Dec 2023 09:26:41 +0000</pubDate><link>https://news.ycombinator.com/item?id=38662973</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=38662973</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38662973</guid></item><item><title><![CDATA[New comment by natbobc in "Kubernetes Needs an LTS"]]></title><description><![CDATA[
<p>Everything’s benefits and tradeoffs. With this model there’s a clear ownership model. I’m not suggesting it’s right for everyone but it is a trend we’ve noticed with a number of clients over the last 2-3 years.</p>
]]></description><pubDate>Sat, 16 Dec 2023 09:09:40 +0000</pubDate><link>https://news.ycombinator.com/item?id=38662902</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=38662902</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38662902</guid></item><item><title><![CDATA[New comment by natbobc in "Kubernetes Needs an LTS"]]></title><description><![CDATA[
<p>we have hundreds of clients most on k8s or openshift. Many of them are shifting to smaller team or division oriented clusters so that they can move at their own pace in consuming capabilities, tools, security practises, etc. It also simplifies distribution of operational expenses, yea there’s tools out there to help with that but it’s a whole lot easier to hand someone a sub-account in AWS and call it a day. Additionally it reduces your fault boundary. It isn’t as sexy as saying you have a 5000 node cluster with 100k+ pods running but it can make life a whole lot less stressful when it comes to upgrades and changes.</p>
]]></description><pubDate>Tue, 05 Dec 2023 19:06:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=38535453</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=38535453</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38535453</guid></item><item><title><![CDATA[New comment by natbobc in "Kubernetes Needs an LTS"]]></title><description><![CDATA[
<p>Phone autocorrect… thanks!</p>
]]></description><pubDate>Tue, 05 Dec 2023 18:46:05 +0000</pubDate><link>https://news.ycombinator.com/item?id=38535203</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=38535203</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38535203</guid></item><item><title><![CDATA[New comment by natbobc in "Kubernetes Needs an LTS"]]></title><description><![CDATA[
<p>Comparing a single function to an entire ecosystem is crazy. Making an LTS imposes a skew of compatibility and support to all downstream vendors as well as the core team. The core team has done a great job on keeping GAed resources stable across releases. Understand there’s more to it than that but you should be regularly upgrading your dependencies as par-four the course not swallowing an elephant every 2 years or whenever a CVE forces your hand. The book Accelerate highlights this quite succinctly.</p>
]]></description><pubDate>Mon, 04 Dec 2023 19:54:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=38522270</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=38522270</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38522270</guid></item><item><title><![CDATA[New comment by natbobc in "Reliability: It’s not great"]]></title><description><![CDATA[
<p>I would even go so far as to say free users aren’t customers in a platform like this. There’s no revenue model and if it’s “run without constraint” you get some fun scaling problems but those types of issues can sometimes lead to optimizations that keep the system online in the face of many small apps but doesn’t necessarily cover the case of a large resource app.</p>
]]></description><pubDate>Tue, 07 Mar 2023 09:18:52 +0000</pubDate><link>https://news.ycombinator.com/item?id=35053316</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=35053316</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=35053316</guid></item><item><title><![CDATA[New comment by natbobc in "Ask HN: Was hired to improve company's devops, founder won't listen to my ideas"]]></title><description><![CDATA[
<p>Thanks! Was faffing with it... the "help" isn't very helpful on how it formats. Sadly can't edit now. :/</p>
]]></description><pubDate>Thu, 04 Oct 2018 10:27:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=18138619</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=18138619</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18138619</guid></item><item><title><![CDATA[New comment by natbobc in "Ask HN: Was hired to improve company's devops, founder won't listen to my ideas"]]></title><description><![CDATA[
<p>It doesn't sound like a great situation to be in. It sounds like the founder has strong opinions. I suspect he subscribes to Trunk Based Development[1] and Continuous Delivery[2]. He also likely wants to follow the practises that "leading organisations" follow in "Accelerate: State of DevOps Report"[3]. You might find it beneficial to research those subjects prior to discussions with him.<p><pre><code>  1 - https://trunkbaseddevelopment.com/
  2 - https://continuousdelivery.com/
  3 - https://cloudplatformonline.com/2018-state-of-devops.html</code></pre></p>
]]></description><pubDate>Thu, 04 Oct 2018 02:27:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=18136641</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=18136641</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18136641</guid></item><item><title><![CDATA[New comment by natbobc in "Problem Solving and Clojure 1.9 with Rich Hickey"]]></title><description><![CDATA[
<p>Agree in many cases you can do this however with point 2 the removal of a function(s) is literally the aim. The accretion of functions benefits legacy systems however its tradeoff is potential harm to users new and unfamiliar with the library. Accretion creates a cognitive overhead (even if only minor) for both the maintainer and new users. Maintainers when they return to code to update and modify behaviour. New users when they seek to understand the library through documentation, examples, and usage. I don't think it's coincidence that a number of languages and libraries acknowledge this by having "one correct way to do X".<p>Using a concrete example relating to security; libressl maintained much of the API surface that OpenSSL provides. In essence they aimed to provide a "drop-in" replacement. However there were whole families of algorithms and functions which they deemed "unsafe/unfit" for purpose (e.g. FIPS algorithms). I think that's a perfectly valid exception to the rule. It acts as a canary in the coal mine and you have options; fix your code or defer upgrading.<p>I would advocate for thoughtful deprecation cycles over ossification of poor APIs and algorithms.</p>
]]></description><pubDate>Fri, 10 Aug 2018 12:43:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=17732730</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=17732730</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=17732730</guid></item><item><title><![CDATA[New comment by natbobc in "Problem Solving and Clojure 1.9 with Rich Hickey"]]></title><description><![CDATA[
<p>I think the reference might be more in relation to OSS tooling such as docker, kubernetes, and a lot of the other stuff in the CNCF project catalogue which is often VC backed start-ups with OSS codebases.</p>
]]></description><pubDate>Fri, 10 Aug 2018 02:20:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=17730215</link><dc:creator>natbobc</dc:creator><comments>https://news.ycombinator.com/item?id=17730215</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=17730215</guid></item></channel></rss>