a7b3fa's comments

I agree with you, and I also think that their interpretation of example 6.2.1 in the RFC is somewhat nonsensical. It states that “The difference in ordering of the RRs in the answer section is not significant.” But from the RFC, very clearly this comment is relevant only to that particular example; it is comparing two responses and saying that in this case, the different ordering has no semantic effect.

And perhaps this is somewhat pedantic, but they also write that “RFC 1034 section 3.6 defines Resource Record Sets (RRsets) as collections of records with the same name, type, and class.” But looking at the RFC, it never defines such a term; it does say that within a “set” of RRs “associated with a particular name” the order doesn’t matter. But even if the RFC had said “associated with a particular combination of name, type, and class”, I don’t see how that could have introduced ambiguity. It specifies an exception to a general rule, so obviously if the exception doesn’t apply, then the general rule must be followed.

Anyway, Cloudflare probably know their DNS better than I do, but I did not find the article especially persuasive; I think the ambiguity is actually just a misreading, and that the RFC does require a particular ordering of CNAME records.

(ETA:) Although admittedly, while the RFC does say that CNAMEs must come before As in the answer, I don’t necessarily see any clear rule about how CNAME chains must be ordered; the RFC just says “Domain names in RRs which point at another name should always point at the primary name and not the alias ... Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed”. So actually I guess I do agree that there is some ambiguity about the responses containing CNAME chains.

RemNote seems like a close match to what you're describing: https://www.remnote.com

The authors actually do briefly mention this concern in the section titled 3.7 Algorithm extensions (under Log truncation):

> However, in practice it is easy to truncate the log, because apply_op only examines the log prefix of operations whose timestamp is greater than that of the operation being applied. Thus, once it is known that all future operations will have a timestamp greater than t, then operations with timestamp t or less can be discarded from the log.

The main issue seems to be that we need to know about all the replicas that we want to be able to synchronize with - but I guess there isn't really a way around this.

My understanding[1] is that you would not use only a Lamport timestamp but rather a tuple (Lamport, actor ID), where the actor ID is a globally unique per-node ID (say, a UUID), which would then be used as a tiebreaker in cases where comparing by the Lamport timestamp alone would give an ambiguous ordering.

This should not be problematic, since the Lamport timestamps are only equal in cases where there is guaranteed to be no causal relationship between the events (i.e. the user did not see the effects of one event before submitting the next event), so it's fine to pick the ordering arbitrarily.

[1] Based on reading the Rust implementation (https://docs.rs/crdt_tree/latest/src/crdt_tree/clock.rs.html...), since I had the same question :)

The full quote is:

> This is because sub-par VR technology (e.g. the Quest 2) is simply not good enough for someone wanting to work several hours per day in a VR Computer instead of their laptop -- even if most people don't realize this yet.

Do you mean that the Quest 2 is good enough to do, say, programming work on for several hours a day, or just that it's a decently good gaming headset?

The last VR headset I tried was the Oculus Rift, and that was nowhere near being usable for work. I'm really curious about the SimulaVR, but it's a bit outside my price range. So if you use the Quest 2 for work, I'd love to hear about your experience with it -- what software do you use, is the resolution good enough for working with text for hours at a time, etc.

I was wondering how it compares to Syncthing[0], which I currently use to sync files between my phone and PC.

It looks like the main difference is that Recall doesn't require you to install anything on the receiving device. You can just install Recall on your phone, and then download files via a web page. So basically you get the privacy of Syncthing with the convenience of Dropbox. That's really cool!

[0] https://syncthing.net/

Neat! I enjoyed your thoughts about choosing a data structure and editor component. I'm also building something in this space (https://thinktool.io/, https://github.com/c2d7fa/thinktool), and I decided on a somewhat different data structure, with pros and cons.

Instead of having pages that contain blocks inside of them (like Roam), I decided to have just one type of item. These items can have other items as children and parents, and they also contain text content which can link (bidirectionally) to other items.

The main advantage of this approach is that items can have multiple parents. So in practice, you never have to think about whether a note should be its own page or just a block inside a different page. This just feels more elegant than Roam's approach to me.

The main disadvantage is that you're now working with a graph rather than a tree. You can end up with funky situations like an item that's its own parent. Since I still want the user to interact with the app through a tree-based UI, I have to add an intermediary data structure representing what the user can actually see. This data structure needs to be built lazily as the user expands and collapses items, so we don't try to represent an infinite loop.

Whenever the user does something (adds an item, edits it, creates a link, etc.), we need to update both the intermediary data structure and the persistent data -- and ensure that these changes are kept in sync. For example, adding a link is a simple change in the graph, but it may require multiple updates to the tree.[1]

I also ended up going with ProseMirror for the editor component (after trying Quill, Slate, an input-based approach and using contenteditable directly). I'm really happy with ProseMirror, even though integrating it wasn't entirely pain-free.[2]

---

[1] You can see the code for the tree-representation here if you're interested, although it's not necessarily written for public consumption: https://github.com/c2d7fa/thinktool/blob/master/src/client/s...

[2] The editor code is here: https://github.com/c2d7fa/thinktool/blob/master/src/client/s... -- same disclaimer as above.

Jonesforth is insanely cool. The linked mirror seems to be missing 'jonesforth.f'. Maybe try check out this one[1] for the full implementation.

I recently tried porting Jonesforth to UEFI[2], so I could run it directly on my hardware without needing an operating system. I was actually surprised by how easy it turned out to be.

Okay, admittedly I ended up rushing a bit towards the end, and the final result is very bare-bones - it can do "Hello, World!", Fibonacci numbers, and then that's pretty much it. Still, it was a lot of fun, and I would totally recommend a project like this, especially if you don't usually work with "low-level" development.

I also ended up writing a blog post[3] to help people get started writing assembly for UEFI. The best resource is probably the OS Dev wiki, though. It has a ton of great resources.

[1]: https://github.com/nornagon/jonesforth

[2]: https://github.com/c2d7fa/jonasforth

[3]: https://johv.dk/blog/bare-metal-assembly-tutorial.html

[4]: https://wiki.osdev.org/Expanded_Main_Page

Try '-nographic'. It can be a bit wonky IME, but good enough for the basics.

I like to think about software that helps you think. Knowledge management, wikis, outliners, task managers, mind-mapping tools, and so on. There's a piece of software called TheBrain (https://thebrain.com/) which I really like; it does a great job of letting you make connections between different topics that are connected in your mind.

However, I prefer the usability of an outliner. So I'm making a web app that is basically TheBrain but visualized as an outliner instead of a mind-map.

There's a prototype available here if the concept sounds interesting to anyone else: https://thinktool.io/

I found this article really useful. It's important to note that the author is explicitly talking about what you do in your leisure time, not what you do for work.

I have often found myself trying to start side-projects that I didn't really care about, because I had some abstract, perhaps irrational idea that I "should" be working on this particular thing. Usually it's something that will teach me a new skill.

Recently, I've gotten a lot better about evaluating whether or not something is worth doing in my free time, but I still don't really have a good criterion for when I should pick one thing over another: When should I spend my free time learning about X, and when should I learn about Y instead?

One suggestion may be to pick whatever is the most useful or the most likely to help you earn money in the future, and indeed this is more or less the rule I have been using in the past.

I posted this article because I thought it gave some remarkably actionable advice for picking between different side-projects, namely:

> The basic idea of personal energy management is that you should focus on increasing your personal energy and lifting up your mood in your leisure time, instead of working on things that drain your personal energy. Hobbies should lift your mood, not drain you. This makes you better perform all the other tasks.

This is a different outlook from what you usually hear, but it makes a lot of sense to me when presented in those terms.

This seems like a cool take on a personal organizer.

I especially like the habit tracking. Not a lot of similar products have a feature like that, and the fact that it breaks down the process of creating a habit for you is really neat. I actually read The Power of Habit a while ago, but never really succeeded at putting it into practice.

If I want to put my important data into an app like this, I want to be confident that I'm not going to lose it. One feature that I missed from the demo is the ability to undo actions. For example, I accidentally marked a habit as done when I meant to click the "+1" button; then I had a "fake" habit in the Achievements tab and had to manually remake the habit. It would be nice if I could just press Ctrl-Z instead.

However, I love how easy it is to get started. The fact that you can just start using the app right in the browser and then sign up when you're ready is exceptional UX!

I signed up for the newsletter, and would definitely check this out again when it's a little bit more robust. I hope you get to keep working on it!

Based on the introduction, that looks like a great book which I definitely wouldn't have found on my own, so thanks for the suggestion! I'll have to give it a try when I have some time.

I'm reasonably competent in Haskell and am interested in checking out OCaml. Can anyone recommend any good resources (books, tutorials, etc.) for someone like me to get started?

Racket is a great language. I got introduced to it through reading "How to Design Programs" (https://www.htdp.org/), which is a really beautiful introduction to programming that focuses on big-picture program design, rather than just writing code, but in a way that is accessible even to people who are new to programmers.

I recently got a chance to use it for a medium-sized personal project, and it is one of the most enjoyable programming languages that I have ever used. Unfortunately, its performance, and especially the start-up time, is not that great. (At least this was true last time I checked.)

As someone who hasn't been following Racket news, I'm not sure if the new Chez Scheme backend is expected to improve performance. I found this blog post (https://blog.racket-lang.org/2018/01/racket-on-chez-status.h...), which seems to indicate that it is not, but that may be quite outdated. What is the goal of porting Racket to CS?