bb01100100

Agreed on both counts - excellent write-up.

I use FreeBSD jails and get a lot of value out of separate network stacks for each (vnet jails).

Would the NetBSD approach here be to lean more heavily on your lan infra to register hostnames with static addresses (pointing at NetBSD host) and then run a host proxy to forward & port-map to the relevant cell? Or is this the wrong kind of use-case for cells?

Surely you’ve come across situations where line number 10,000,021 of a 60m line CSV fails to parse because there aren’t enough fields in that line of the file…? The issue is that you can’t definitively know which of the 50 fields is missing, so you have to fail the line or worse the file.

In my experience (perhaps more niche than yours since you mentioned it has been your day job), the lack of fall back options makes for brittle integrations. Failing entire files due to a borked row can be expensive in terms of time.

Having to ingest large CSV files from legacy systems has made me rethink the value of XML, lol. Types and schemas add complexity for sure, but you get options for dealing with variances in structure and content.

Sounds useful from a mental health perspective .. am I right in thinking detractors are concerned about the loss of privacy needed to enforce the bill, or is it something else?

Nah, that's not ironic.

What would be ironic is getting RSI after you chose to write less code in order to avoid getting RSI.

Your post was very clear, nicely done!

Oh I see - thanks for clarifying. Also, apologies - I could have asked a question about AI demand instead of assuming you were slapping a "now with AI" label on your product.

I’m sure that website didn’t mention AI at all a year ago; now it seems if you’re not doing something AI you aren’t the customer they built this platform for. Strange.

I’m sure the role is meant to have some sort of value, but in the last decade I’ve only seen one human do a good job of it.

That person delivered value to the team and made a tangible difference to velocity (removing blockers) and effectiveness (retros, reminding people to apply lessons learned). As a consequence the team worked well and delivered good things.

The other Scrum Masters I’ve worked with seemed to operate on the assumption that having Master in their job title meant they knew more than everyone else.

Would it be correct to say the these client libraries provide the functionality (eg ease of transactions, once only, recovery) whereas your cloud offering solves the scaling / performance issues you’d hit trying to do this with a regular pg compatible DB?

I do a lot of consulting on Kafka-related architectures and really like the concept of DBOS.

Customers tend to hit a wall of complexity when they want to actually use their streaming data (as distinct from simply piping it into a DWH).. being able to delegate a lot of that complexity to the lower layers is very appealing.

Would DBOS align with / complement these types of Kafka streaming pipelines or are you addressing a different need?

FFS - thanks for the paywall.

Land was a productive asset, made so via farming by the people who lived on the land and did the work. Someone else will be able to point out when serfs stopped being a thing.

I would imagine it's a similar number per unit of area/yield/weight to that required to feed animals.

In both instances, the crops are harvested and transported for use in very similar ways.

I don't know whether I'd include or exclude ground crops that are eaten by livestock in situ - not sure what percentage of crops they would amount to.

What was your line of thought with this comment?

Yes! That has been my experience at a (now long since failed) start-up.

We didn't communicate top-down, or cross-functionally very well. The executive team, with lots of support from HR, rolled out a really heavy, very process-centric OKR system and assumed that by announcing that Google uses OKRs and providing a portal that we'd start aligning.

It was an abject failure - not because (IMO) OKRs are a bad idea, but because the leadership teams made the mistake of confusing process for communication.

After the big announcement, it was mentioned only ONCE ever again. Seriously.

My team (of six) and I made use of it, but it was very difficult to align it with the goals of, say, our chief revenue officer; someone we met about three times in four years. We went back to using team & personal goals, creatively using our backlog and one-on-ones because there was no input, no updates and no communication about the OKRs.

The start-up failed because it wasted time chasing tactical low-value (tangential) deals instead of delivering against a viable, sustainable strategy. Great place to learn some hard lessons!

I'd use OKRs again for sure - both for their intended purpose, to help avoid the process-as-communication-proxy trap, and to gauge the nature of the organisation implementing them.

I assume you're referring to being consistent - keeping the team focused on the (predefined) strategy, not getting distracted and going off on tangents...

Seems pretty reasonable to me.