HN user

kilobaud

55 karma
Posts1
Comments30
View on HN

Eh there are also decades worth of audio electronics designs which use the 741 and the decision of which actual part to use is often an aesthetic one. (i.e., assuming all other parameters are compatible then just use your ears). There are always new (hobbyist) designs being drafted around specific parts that are otherwise obsolete simply due to the musical character of certain parts

(Disclaimer: on religion I try to be respectful, as an agnostic atheist) I do think our ability to “build tools that create life” is incredible, but to me has a limited argumentative impact on what I guess you could call the “prime mover” question: _But how did everything start?_ Does that seem reasonable or am I downplaying the implications you mentioned?

Thanks for helping us launch LocalXpose however many years ago. I know it seems like product promotion is (rightfully) something to always be wary of, but I appreciate the forums you’ve provided startups hoping to find early adopters. We are (relatively speaking) successful nobodies, but I wonder if you have any memories of sites that “blew up” after being added on BetaList?

And your starter “production” deployment of the Nomad/Consul/Vault stack is literally 12 VMs, comprising three independent Raft clusters. There is no decent way to do zero-downtime instance replacement without building your own orchestration layer, but also they’ve had a years-long track record of shipping bad upgrades and following up with only manual remediations or workarounds instead of a fix.

As someone who has productionized and maintained truly hundreds of those clusters across several jobs, it is hard at this point for me to recommend Consul, Nomad, or Vault to anyone serious about building reliable applications. Too many broken upgrades and manual click-ops tasks just to keep them online. (…and I’ve said nothing of the actual product!)

I think the main idea is that MOSFET chips don’t sink or source much current on their own (“fundamental” seeming to mean the way that current does not propagate into the gates, and most designs only really draw current during transitions)

OTOH some chips (amplifiers for example) may indeed have current flowing through them and therefore the power consumption of the “chip” would equal the sum of heat loss and output power. At least that’s my interpretation of the framing “how they operate at a fundamental level”. I could be wrong too, I’m not a working EE

Thanks, I can relate to the parent poster, and this is a really profound comment for me. I appreciate the way you framed this. I’ve felt compelled to fact check my own LLM outputs but I can’t possibly keep up with the quantity. And it’s tempting (but seems irrational) to hand the results to a different LLM. My struggle is remembering there needs to be input/query/calculation/logic validation (without getting distracted by all the other shiny new tokens in the result)

Tunnl.gg 8 months ago

Probably not an exciting answer but my work focused on stability and performance. There are indeed a lot of cool alternatives. I think Localxpose is for businesses who aren't interested in self-hosting and just need a service that will reliably handle production traffic. I don't know if that's unique (or cool, lol)

Tunnl.gg 8 months ago

Can you share more details? I know Hetzner offers unlimited bandwidth in some cases but I thought it limited only to servers with the 1Gbs uplink

Tunnl.gg 8 months ago

The tunnel host appears to be a Hetzner server, they are pretty generous with bandwidth but the interesting thing I learned about doing some scalability improvements at a similar company [0] is that for these proxy systems, each direction’s traffic is egress bandwidth. Good luck OP, the tool looks cool. Kinda like pinggy.

[0] https://localxpose.io

I've worked in companies that do this internally, e.g., managed pull-through caches implemented via tools like Artifactory, or home-grown "trusted supply chain" automation, i.e., policy enforcement during CI/CD prior to actually consuming a third-party dependency.

But what you describe is an interesting idea I hadn't encountered before! I assume such a thing would have lower adoption within a relatively fast-moving ecosystem like Node.js though.

The closest thing I can think of (and this isn't strictly what you described) is reliance on dependabot, snyk, CodeQL, etc which if anything probably contributes to change management fatigue that erodes careful review.

Well I'm pretty sure the oscillator bank in the VS does use wavetables, it would have no other way of supporting 127 different voices (including user-provided voices). (But you're correct that the approach to modulating sounds on a VS is fundamentally different to, say, a PPG wavetable synth.)

I was excited to read this but sadly the author provides hardly any examples to support their statements, and several of their complaints are desirable properties of a provisioning lifecycle management tool (e.g., the complaint that multiple users of a shared terraform component need to contend with a state lock -- hint: this is a good thing...)

Seismically active regions (e.g. California) absolutely have more earthquake experts than other places... I am not sure why that metaphor is singled out when the rest of the article is pretty clear its about finding the difference between a burning building and a building-set-on-fire.

Firefighters don't just read about fires, they practice with actual flames, too.

The past two years should've made it clear that public education and the workforce increasingly depend on having access to bandwidth. Of course this was already a trend, but the pandemic accelerated it, affecting entire household bandwidth consumption at once. I disagree with the implication that wanting (needing?) fiber is somehow equivalent to whining.

Sorry for the off-topic comment here but I cant help but tell you that your username reminds me of a user who posted on a couple gaming forums I used to frequent in the early 2000s.

I dont automate CI/CD because I'd rather be sword-fighting on roller chairs, I automate because I value the cost of my own work time and truly would rather spend it on a more interesting problem. (To say nothing of the fact its all too easy to make mistakes where processes arent automated, and I dont enjoy making mistakes)

I dont disagree with your observations, just saying "productivity" gain is pretty far down the list of benefits to me personally

Hope this isnt too pedantic but as "noise" is commonly perceived as higher freq (ignoring aliasing) I think low-pass is meant to imply removing the "noise" in your pipeline. Your interpretation makes sense if freq == quality, but statistically a high pass output has higher variance, so sounds like the opposite of the intended effect