noahdesu

Worked on a project with similar goals [0]. By no means a production level implementation, but much of the system exists as a proof-of-concept.

[0]: https://makedist.com/projects/cruzdb/

I can sympathize with this take. Although I'm generally fine with either async or sync--whichever is most efficient--it seems that individuals don't usually know which is right for them.

I'll take this further: I think that bad commit messages breed resentment. It's highly context dependent, but needing to understand some code and its historical context is already a big challenge. git-blaming your way back through time only to encounter brain dump commit messages full of ambiguity and non-essential information is excruciating. Writing good commit messages--like any technical writing--is more art than procedure, and it's hard to do well without feedback and revision. I believe that commit messages should be subject to the same level of review as the code they are presumably documenting.

This is such an important feature that has a direct impact on code quality and time savings that I'm not sure why it isn't a priority feature. As a reviewer, having to choose between "review everything again" or "trust the submitter didn't introduce extra changes in the revised pr" is such a terrible choice to have to make.

Migrating away from a development model based on attaching patches to bugzilla tickets is sure to improve the development experience, especially for new contributes. Good move switching.

This sounds really similar to some of the work coming out of Vectorized on Redpanda [0]. They're building a Kafka API compatible system in C++ that's apparently achieving significant performance gains (throughput, tail latency) while maintaining operational simplicity.

[0]: https://vectorized.io/redpanda

I'm working on Rook+Ceph at Red Hat. Rook 1.0 was just released last week which added support for the very latest Nautilus release of Ceph.

If you are thinking about starting a Seastar project, definitely check out SMF [0]. It's a highly optimized RPC framework that uses Seastar, and makes it easy to build high-performance servers and clients. Seastar itself is RPC agnostic, and this project has a great implementation of functionality most developers will eventually need.

[0]: https://github.com/smfrpc/smf

In the latest release (0.9) Ceph in Rook has been declared stable.

This seems to serve a purpose similar to Rook [0] for deploying distributed (or non-distributed) storage systems, including database. For example, Rook can deploy CockroachDB and also Ceph, which would have a lot of the same challenges as deploying some of the databases supported by KubeDB.

[0]: https://rook.io

disclaimer: red hat employee working some on rook.

Been using the cloud native version for about a year now, and I'm debating if I should renew. What are you using now if not YNAB?

the experience you have described that occurs after about 2 weeks is a very distinct state of mind. I find that I can to a certain extent reliability reproduce it (1) whenever I have a deadline and I'm procrastinating, (2) occasionally after smoking some marijuana (3) and on long distance runs.

This is the type of project announcement that gets me excited to work on my own open-source efforts. Congrats Drew, this is great.

Thanks. Our team is also remote, so we don't use whiteboards for collaboration. It seems like, at least here in SF, every room in any company that I go to has a whiteboard. One might then conclude they are indispensable, but I would really like to figure out how to put a number on it.

I'm curious about how expensive the restructuring is, and importantly, can that be "scheduled": can i violate some conditions and then do the expensive restructuring at a time that is convenient?

I enjoyed reading this article. But at the beginning the author has this to say about objections to the MWI that are based on feeling:

> "This objection is rightly dismissed by saying that an affront to one’s sense of propriety is no grounds for rejecting a theory. Who are we to say how the world should behave?"

But really at the end of the article the conclusion about the problems with MWI feel similar:

> "But an idea that, when we pursue it seriously, makes that view inchoate and unspeakable doesn’t fulfill the function of science."

I've been doing the exact same thing. And I think there is a lot of potential with google docs if combined with some of the google docs scripting capabilities to create a personal cms.

I _cannot_ wait to start playing around with this. It really does seem to tick off all the boxes I've been looking for. Do you have any plans / strategy / tips for handling video? I tend to watch a lot of conference talks and lectures on YouTube, and find that I'd like to take some notes while watching. Having a single personal knowledge base handle that (or at least the notes aspect) instead of a one-off solution for other types of media would be useful to avoid fragmentation.

I'd be interested in some more detail on this. What's the process look like and what are some common cases that this is useful.

You can export Ceph through NFS [0].

[0]: http://docs.ceph.com/docs/master/cephfs/nfs/

are you using mutt's built-in imap functionality, or something like offlineimap?

I think they are [0]:

> "Using pharmacokinetic modeling and DMT blood sampling data, we demonstrate that the unique pharmacological characteristics of DMT, which also include a rapid onset and lack of acute tolerance to its subjective effects, make it amenable to administration by target-controlled intravenous infusion. This is a technology developed to maintain a stable brain concentration of anesthetic drugs during surgery."

[0]: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4944667/

edit: I guess that isn't a drip. I know nothing about this sort of thing :)

One thing people talk about is the short-lived effects of DMT, and how they would like more time in the the DMT space. But as I understand it, your body doesn't build up a resistance to it. The DMTx [0] project is seeking to exploit this property and created extended-state DMT experiences using some basic medical techniques. Also, they are looking for volunteers.

[0]: https://www.dmtx.org

Thanks for this write-up. I can't wait to see what comes out of the Legion projects next. One of the most exciting things I think that is going on.

It's hard to deny that there is at least some influence there. Like LogDevice, the zlog project [0] is influence by CORFU (separate sequencer, write striping), but both use different storage interfaces / strategies.

[0]: https://github.com/cruzdb/zlog

This is really cool. We are doing something similar with CruzDB [0], but we are using red-black trees. What made you choose the radix tree? We've looked at several persistent data structures, and continue to look for alternatives.

[0]: https://nwat.xyz/blog/2018/02/15/cruzdb-architecture-part-1-...

Nice! I have fond memories of studying the mechanics of futexes when PREEMPT_RT was under heavy development.

It's been a long time since I thought about the kernel futex implementation, but IIRC, one of the most interesting aspects was that the kernel would actually navigate a linked list that existed entirely in userspace. I believe this was called, or related to, robust futexes [0].

[0]: https://www.kernel.org/doc/Documentation/robust-futexes.txt

The only up-to-date information I've found so far regarding the storage system for this beast is:

* 250 PB GPFS

* 2.5 TB/s

I'd like to find some information on the burst buffer that is sitting between compute and the capacity storage system.

Yeh, same location for me. It's not a great situation.

You could always pick something you don't know much about but are interested in, then blog about your learning process. Chances are you'll present it in a way that helps someone else learn it, who either appreciates your presentation style, or couldn't find answers to issues they faced on their learning path.