schmichael

Thanks! I think this is a really insightful comment because Nomad is more opinionated than I think we let on. The subtle interactions between signals, service discovery, health checks, templates, etc. all have a big impact on the reliability of the system as a whole. I've always wanted to do a "HashiCorp Validated Nomad App Design" kind of doc to outline these best practices, but it's always proved too big of a lift. Maybe now is the time!

> I am sad to see you go.

I'm not going anywhere! My grammar isn't always the best, so I apologize for the confusion.

<3

> Nomad allowed us to build out a large fleet of servers with a small team

I really love these stories. Our customers constantly shock me with how large of clusters they're able to manage with just a few people. >10k nodes by <10 people isn't uncommon although we are not good at rigorously collecting data on this.

Nomad is far from perfect, but we really strive to ease the pains of managing your compute substrate.

Thanks! We have kept an explicit community rotation and issue triage policy for Nomad's entire life. Definitely one of my hard lines.

I know we aren't perfect. In fact it's my turn this week, and I've utterly failed at keeping up with triage!!

We get tremendous joy and value from engaging with our community. Thanks for your patience (with me in particular!)

Glad to hear Nomad is working well for you! It always means a lot. We as the dev team spend all day staring at bugs and missing features, so it's nice to be reminded of what's working well! No one files an issue for a happy cluster. :)

I joined HashiCorp in 2016 to work on Nomad and have been on the product ever since. Definitely a lot of feelings today. When I joined HashiCorp was maybe 50 people. Armon Dadgar personally onboarded us one at a time, and showed me how to use the coffee maker (remember to wash your own dishes!). There have been a lot of ups (IPO) and downs (BUSL), but the Nomad team and users have been the best I've ever gotten to work with.

I've only ever worked at startups before, but HashiCorp itself left that category when it IPO'd. Each phase is definitely different, but then again I don't want go back to roadmapping on a ridiculously small whiteboard in a terrible sub-leased office and building release binaries on my laptop. That was fun once, but I'm ready for a new phase in my own life. I've heard the horror stories of being acquired by IBM, but I've also heard from people who have reveled in the resources and opportunities. I'm hoping for the best for Nomad, our users, and our team. I'd like to think there's room in the world for multiple schedulers, and if not, it won't be for lack of trying.

Don’t worry: we’re indirectly thinking about Rome by thinking about their perception of ancient Sparta. Rome is the Kevin Bacon of western historical thought: we’re never more than 6 hops away.

This is absolutely true! I haven’t stared at a JVM GC graph is over 8 years.

Go optimizing for latency over throughput means the GC very rarely interferes with my applications SLO at the cost (literally $) of presumably requiring more total compute than a GC that allows more fine tuned tradeoffs between latency and throughput.

As someone who is not directly paying the bills but has wasted far too much of my life staring at JVM GC graphs and carefully tuning knobs, I vastly prefer Go’s opinionated approach. Obviously not a universally optimal choice but I’m so thankful it works for me! I don’t miss pouring over GC docs and blog posts for days trying to save my services P99 from long pauses.

I think the difference is that what VSCode is doing is not an SSH Session like you get in a terminal with the ssh command or putty.

VSCode is installing a remote agent on the target machine that happens to use ssh as its transport protocol, and offers to share that transport with the user.

Is this a problem? Not if it only does things you want it to do. However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh.

Alternative title: antitrust works.

It didn't kill Microsoft. Microsoft isn't dead. However Microsoft does now have competitors. The takeaway here is that antitrust is fantastic for consumers and innovation.

> Why spend 2-10x as much to live in one of four coastal metros

I think you answered your own question: it’s not (entirely) an economic decision. Weather, culture, nature, civic amenities. There’s a lot in life that money can’t buy. Sure I could own a McMansion on a palatial plot of prairie, but what if the square footage of my house and acreage of my yard isn’t what’s important to me?

There are many religious questions people probably are scared to ask a human. Imagine any closeted gay or trans kid wanting to know if the way they feel is “wrong.” Just asking the question to your parents or a faith leader could raise suspicions and be dangerous.

So while I wish the world were one in which people didn’t have a reason to be scared to ask questions, that’s not the world we live in. Are LLMs an answer? I have no idea, but I understand the impulse to try.

Nuclear requires an extremely mature bureaucracy to handle the serious longterm risks efficiently. Here in the USA I'm just not sure our government is mature enough for the task. Every 4 years we may have someone come in to slash safety regulations or erect impossible regulatory barriers, not to mention all of our defense treaty obligations and their churn. Every year (or less!) our congress may decide to let the government shutdown and stop paying critical contractors. Trains carrying spent or unspent fuel may derail thanks to inefficient regulation. etc etc.

One of the massive benefits of wind and solar is that it can be scaled down to a size even a consumer can deploy. This makes it relatively resilient to regulatory whims compared to massive undertakings like nuclear. I'm not a nuclear engineer, but I suspect the recent emphasis on smaller nuclear plants has more to do with navigating regulatory hurdles and uncertainty than efficiency.

All that to say I am quite jealous of countries with mature bureaucratic regimes that can efficiently manage nuclear!

I’ve never understood the use of SSE over ndjson. Builtin browser support for SSE might be nice, but it seems fairly easy to handle ndjson? For non-browser consumers ndjson is almost assuredly easier to handle. ndjson works over any transport from HTTP/0.9 to HTTP/3 to raw TCP or unix sockets or any reliable transport protocol.

The article goes into great detail about the benefits of an opaque api vs open structs. Somewhat unintuitively open structs are not necessarily the “fastest” largely due to pointers requiring heap allocations. Opaque APIs can also be “faster” due to lazy loading and avoiding memcpy altogether. The latter appears in libraries like flat buffers but not here IIRC.

A quick search of “c++” on HN shows many C++ related posts explicitly mention the language. I would assume many other language specific posts also name the language they’re using to save uninterested parties a click. There’s really nothing particularly interesting about this: it’s a fairly natural pattern in a multilingual community like HN.

The prices are just one click deeper. Hardly a nefarious dark pattern.

Yes, from the README:

> Bocker runs as root and among other things needs to make changes to your network interfaces, routing table, and firewall rules. I can make no guarantees that it won't trash your system.

Linux makes it quite hard to run "containers" as an unprivileged user. Not impossible! https://github.com/rootless-containers/rootlesskit is one approach and demonstrates much of the difficulty involved. Networking is perhaps the most problematic. Your choices are either setuid binaries (so basically less-root as opposed to root-less) or usermode networking. slirp4netns is the state of the art here as far as I know, but not without security and performance tradeoffs.

Trucking is definitely not an efficient way of moving salmon past dams: https://www.opb.org/article/2023/10/31/willamette-river-salm...

The government, local, state, or federal, should have the opportunity to nationalize unused infrastructure like this. Give Chevron an opportunity to tear it down or turn it on, but otherwise pay a market rate just like with eminent domain and let the turbines spin.

I'm guessing this was just some greenwashing by Chevron to avoid being forced to actually cleanup their nuclear waste.

Chevron is an oil and natural gas company, not an electricity production company. Directly producing green energy is a bit like Apple selling Windows PCs.

The author appears to be solidly millenial from their resume.

As an Elder Millennial myself I hope HN and our industry is free of ageism against young and old. Comments like yours don’t help.

Just post your source. Benchmarks should be reproducible.

Flagged because without code or even binaries there's no way to learn anything from this. Is the code memory safe? Does it gracefully handle error conditions? What tradeoffs were chosen?

Plenty of OSS "simple redis clones" exist with performance better than Redis. I think it would be more useful to re-post those than share this.

Also a fully remote company worker since pre-COVID, and I vastly prefer calls with the video on. It's the norm at our company. Facial expressions convey enormous amounts of information. Also our team silently claps for people which is admittedly quite silly but hey, we like it.

I'm rarely on calls without video, but when I am I find it jarring when voices just appear out of the ether with only a little flashing icon to indicate who it is I'm listening to.

To each their own!

You misunderstand: the keyword in that quote is “project.”

GitHub projects are boards, not repositories. I don’t know if there’s a limit on the number of issues repositories can have (nomad is over 5k).

I’m not actually sure how valuable a board with over 1k items on it is in practice.

Why send agents with flipper zeros when American consumers willingly buy millions of consumer electronics from China every year that could be part of a supply chain attack?

It’s really bizarre that you bring up physical border security when Israel just demonstrated that’s not at all necessary.

> Does Telegram let them see it: I don't think so.

This is exceptionally naive. Even if he was arrested for not sharing with the French, what about for other countries? Was he arrested for not ever sharing or not sharing enough? Even if he, personally, has never shared, that doesn’t say anything about his employees who have the same access to these systems.

Your data is not private with Telegram. You are trusting Telegram. It is a trust-based app, not a cryptographically secure app.

If you trust telegram, that’s your choice, but just because a person says the right words in interviews doesn’t mean your data is safe.