kenrose

6 माह पहलेdiscuss

Authored by Tobi, Shopify CEO.

An on-device search engine for everything you need to remember. Index your markdown notes, meeting transcripts, documentation, and knowledge bases. Search with keywords or natural language. Ideal for your agentic flows.

kenrose

6 माह पहलेdiscuss

At 10:25am ET, HN is more up-to-date than Wikipedia (article hasn't been updated yet to reflect his passing).

kenrose

8 माह पहलेdiscuss

We did this at OpsLevel a few years back. Went from AWS managed NAT gateway to fck-nat (Option 1 in the article).

It’s a (small) moving part we now have to maintain. But it’s very much worth the massive cost savings in NATGateway-Bytes.

A big part of OpsLevel is we receive all kinds of event and payload data from prod systems, so as we grew, so did our network costs. fck-nat turned that growing variable cost into an adorably small fixed one.

kenrose

11 माह पहलेdiscuss

When mosh came out back in 2013, it solved a pretty real problem of ssh crapping out when you changed networks (like moving from in-office to home). It solves it at the app layer and uses UDP and is designed to work in high loss / latency environments. Very cool.

At the same time, in recent years, I've found that ssh running on top of Wireguard / Tailscale is way more usable than 2013 days. Those latter tools address the roaming IP issues directly at the network layer.

So while there are still issues with ssh / TCP if you're on a really crappy network (heavy packet loss, satellite link, etc), those have been less common in my experience compared to IP changes.

The “killer use case” for Mosh feels a lot less killer now.

kenrose

पिछला वर्षdiscuss

Totally fair to bring up IPv6 vs. IPv4. However, I think Tailscale’s approach might sidestep some of that pain.

Avery (Tailscale CEO) has actually written about IPv6 in the past:

    - https://apenwarr.ca/log/20170810 (2017)
    - https://tailscale.com/blog/two-internets-both-flakey (2020)

IPv6 has struggled in adoption not because it’s bad, but because it requires a full-stack cutover, from edge devices all the way to ISP infra. That’s a non-starter unless you’re doing greenfield deployments.

Tailscale, on the other hand, doesn’t need to wait for the Internet to upgrade. Their model sits on top of the existing stack, works through NATs, and focuses on "identity-first networking". They could evolve at the transport or app layer rather than rip and replacing at the network layer. That gives them way more flexibility to innovate without requiring global consensus.

Again, I don’t know what their specific plans are, but if they’re chasing something at that layer, it’s not crazy to think of it more like building a new abstraction on top of TCP/IP vs. trying to replace it.

kenrose

पिछला वर्षdiscuss

Can likewise confirm dblohm7 is a real human too :)

kenrose

पिछला वर्षdiscuss

You're not wrong to think Tailscale is primarily a software company, and yes, salaries are a big part of any software company's costs. But it's definitely more complex than just payroll.

A few other things:

1. Go-to-market costs

Even with Tailscale's amazing product-led growth, you eventually hit a ceiling. Scaling into enterprise means real sales and marketing spend—think field sales, events, paid acquisition, content, partnerships, etc. These aren't trivial line items.

2. Enterprise sales motion

Selling to large orgs is a different beast. Longer cycles, custom security reviews, procurement bureaucracy... it all requires dedicated teams. Those teams cost money and take time to ramp.

3. Product and infra

Though Tailscale uses a control-plane-only model (which helps with infra cost), there's still significant R&D investment. As the product footprint grows (ACLs, policy routing, audit logging, device management), you need more engineers, PMs, designers, QA, support. Growth adds complexity.

4. Strategic bets

Companies at this stage often use capital to fund moonshots (like rethinking what secure networking looks like when identity is the core primitive instead of IP addresses). I don't know how they're thinking about it, but it may mean building new standards on top of the duct-taped 1980s-era networking stack the modern Internet still runs on. It's not just product evolution, it's protocol-level reinvention. That kind of standardization and stewardship takes a lot of time and a lot of dollars.

$160M is a big number. But scaling a category-defining infrastructure company isn't cheap and it's about more than just paying engineers.

kenrose

5 वर्ष पहलेdiscuss

It was CNN. Around 9:45 am it was slow, by 11 am it was down / text only.

kenrose

5 वर्ष पहलेdiscuss

My own experience ([1]): the biggest different between "startup inside BigCo" and an actual startup is availability of resources.

"Startup inside BigCo" generally revolves around spinning up a new team that's product focused and delivering quickly.

Depending on which BigCo you're at, delivering quickly could be a departure from how things are normally done. e.g., You don't have to worry about writing a big up front proposal doc, going to the architectural review board, or using the standard infra tooling.

For engineers on a team, this "feels" like a startup. There are daily standups. They talk to users and have a sense of ownership on what's built. There can even be some sense of urgency to ship quickly.

While "BigCo startup" teams mimic a lot of the same procedures and activities as a startup, there is an underlying support structure at BigCo that isn't there in an actual startup. IMO, that makes the experiences substantially different.

Some examples:

- The cost of failure is different. At BigCo, if the project fails, it's generally OK. Each engineer can be reassigned to some new team at BigCo. At a startup, if the project fails, the entire company fails.

- There are more people to ask for help. At BigCo, if you're stuck on some hairy engineering issue, you have a swell of engineering talent to lean on for help and guidance. At a startup, you have StackOverflow, Google, and maybe some folks in your personal network to lean on for help.

- There's more than just product development. At BigCo, generally only the engineering / product development team is structured like a startup. After the code is "done", the regular product marketing org, marketing org, and sales org (if that's a thing), can kick into gear. At a startup, there is no such massive support structure.

- On the topic of marketing, having the brand of BigCo is a huge boon to a new product. For mobile apps, there's a lot more trust in seeing "NewProduct by BigCo" vs. just "NewProduct" in the app store. Your rockstar CEO may even tweet out the launch announcement to his millions of followers.

- And yes, at BigCo, when it's lunchtime, you can go to the cafeteria and decide if you want the steak or the coq au vin for lunch. (well, before COVID at least)

---

[1] - I've worked for really small startups (< 8 people), really big companies (I was person 2000+), and small companies that became big (joined at 20, left at 200+, now at 500+).

kenrose

7 वर्ष पहलेdiscuss

If it’s one you build yourself (e.g. Raspberry Pi with Kodi), it will be.

Submissions

Maintenance, Tech Debt, and Other Cross-Cutting Work at Scale

Oxide Computer raises $200M Series C

QMD – Quick Markdown Search

comments