bothra90

Is this competing with Nessie (https://projectnessie.org/)?

That would be awesome!

Exciting work! Some questions:

1. Any plans on open-sourcing this?

2. Why not have a tiered architecture that can provide lower latency? p99 of 1s can be too high for some use-cases.

3. Related to 2, how does WarpStream compare to tiered storage in Pulsar?

[Edit 1] Added (3)

Can you share some insight on how/if Kagi is different from Neeva[1] in its approach?

[1] https://neeva.com/

By an independent board do you mean that the H1B holder cannot themselves be on the company's board? Re: 50% ownership, is 50-50 split OK, or does it have to be less than 50?

Is this solving similar problems as Ray [1]?

[1] https://www.ray.io/

How does this compare with https://github.com/linkedin/greykite?

I really wish more design docs / project reports looked like this article - talking about the whys, goals / non-goals, options considered, prototypes built, challenges, and solutions, learnings and next steps. Kudos!

Although GitHub supports the commit-based review the author is arguing for (they found it too after writing the article), I don't think it completely solves the problem - we need to be able review, test, and merge each commit individually without needing to merge the entire PR. Since GitHub doesn't have first-class support for dependent PRs, we are still "stuck" with a broken workflow. An example workaround: https://wchargin.github.io/posts/managing-dependent-pull-req.... Are there any better solutions?

https://en.wikipedia.org/wiki/Panopticon

I've wanted to write this blog for around 2 years now, but was only now able to get it out. Feedback is welcome.

The fact that PMs are empowered to be "CEOs" of their product probably doesn't help. In my mind, transparency in the 2-way communication between PMs and engineers is key. Engineers need to be motivated by the "why", but PMs also need to understand why an engineer might want to, to quote from the article, "spend months refactoring an app to make it “right”".

The design choice of hiding the entire network behind a single end-point is interesting. As mentioned in the blog, it forces pushing down complex routing logic into the networking module. I'm curious about what other options were considered and why this approach was picked.

Point taken, though I like to think of stacks as one of many ways of implementing LIFO behavior.

I've wondered the same thing about the effect of slow-accelerating trucks on stop-and-go bay area freeway traffic during rush hours. I feel that the effects are fairly non-linear as more of these vehicles are introduced. Some cities in India don't allow heavy vehicle traffic on congested roads during peak commute hours, though I'm not sure if there's been a study of traffic patterns that validates/simulates these scenarios.

Prismatic (used to be at https://getprismatic.com) - a topic/interest based newsfeed platform, but backed by an ML/AI system to learn from your reading behavior. I loved the product until it got shutdown one day :-(

The author is arguing that we can always rewrite the txn logic such that (at least in the deterministic case) if one worker decides to commit, all others will do so too. So a worker can proceed independently without other workers needing to finish their share of work and entering the commit protocol. The article doesn't go into exactly how this could work in the case of non-deterministic txns, but the linked papers may have an answer.

"Are We There Yet" - Rich Hickey (https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...)

Another article where the author thinks(confuses?) REST and CRUD have a one-to-one mapping?

Ref: https://jcalcote.wordpress.com/2008/10/16/put-or-post-the-re...

Has anyone tried blosxom(written in perl) and pyblosxom (the python alternative)? They are both pretty easy to setup and use. try :http://pyblosxom.bluesock.org/ and http://www.blosxom.com/