But the presentation does not show how it resolves conflicts. For the first example, Git has the 3 way-merge that shows the same kind of info. And a conflict is not only to show that two people have worked on a file. More often than not, it highlight a semantic changes that happened differently in two instances and it's a nice signal to pay attention to this area. But a lot of people takes merge conflicts as some kind of nuisance that prevents them from doing their job (more often due to the opinion that their version is the only good one).
I really think something like Xet is a better idea to augment Git than LFS, though it seems to pretty much only be used by HuggingFace for ML model storage, and I think their git plugin was deprecated? Too bad if it ends up only serving the HuggingFace niche.
Of course, the rule of 3 is saying that you often _can't tell_ what the shared concept between different instances is until you have at least 3 examples.
It's not about copying identical code twice, it's about refactoring similar code into a shared function once you have enough examples to be able to see what the shared core is.
But don’t let the rule of 3 be an excuse for you to not critically assess the abstract concepts that your program is operating upon and within.
I too often see junior engineers (and senior data scientists…) write code procedurally, with giant functions and many, many if statements, presumably because in their brain they’re thinking about “1st I do this if this, 2nd I do that if that, etc”.
This is wonderful news, and my sincere thanks to the author.
I remember coming upon this algorithm several years ago, and thinking it was extremely elegant and very appealing, but being disappointed by the patent status making it unusable for FOSS work. I really appreciate the author's choice to dedicate it to the public domain after a reasonable amount of time, and congratulations on the success it had while proprietary!
Now if I ever get around to writing that terminal emulator for fun, I'll be tempted to do it with this algorithm for the code's aesthetic appeal.
> I was granted a patent for the Slug algorithm in 2019, and I legally have exclusive rights to it until the year 2038. But I think that’s too long. The patent has already served its purpose well, and I believe that holding on to it any longer benefits nobody. Therefore, effective today, I am permanently and irrevocably dedicating the Slug patent to the public domain.
Yes, now that SDF font rendering is the industry's preference, he drops the software patent. That is, he is dropping the patent because it isn't a commercially viable piece of software, not because he is ethically opposed to it. Great virtue signaling though.
Seems more like he had the patent long enough to build a sustainable business from his own work, and now he’s been able to earn enough from it that others’ implementations aren’t a risk to him.
Which is kind of the entire point of patents, just that they last way too long relative to the speed of technological progress
He said "holding on to it any longer benefits nobody", implicitly including himself. He may believe that it's to his advantage for the patent to be more widely used.
Which makes sense--I don't doubt that he is a subject matter expert where this patent is concerned. If this algorithm continues to be widely used or its use increases, then that would be likely be good for him.
SDF font rendering was common long before Slug, and Slug is supposed to be the better solution (I haven't used it though, so cannot comment on its pros and cons vs SDF, but one obvious disadvantage of SDF is that you still need a font atlas texture, and that can get very big if you need to render some East Asian character sets).
SDF font rendering has been around 20+ years though? Valve really popularized in their 2007 SIGGRAPH paper and Chlumský developed MSDF font rendering in a 2015 thesis.
SDF font rendering was an industry standard maybe from 2007-2010. and you probably won’t believe what happened to OpenGL since then. Don’t even look into at what people are doing with GPUs these days, you won’t like it one bit!
My feeling is that copyrights should be infinitely renewable, with say a 20 year term, but the renewal fee should double with each term so that Disney can have their infinite copyright on Snow White but at an ever-increasing cost so that they will need to make a decision about whether it makes sense to keep it.
My utopian vision: First registration is free and automatic. Copyright holders get an automated notification of expiring copyright and renewal is, say $1000 for the first term (adjusting for inflation) and doubling thereafter (also adjusting for inflation, so you don’t get a $2000 renewal but more like $4400 with 4% inflation). For corporate-held and posthumous extensions, the term would be 10 years.
The thing here is the exponentially increasing cost of renewing the copyright, with the inflation-adjustment I proposed and the 10-year term for a corporate or posthumous copyright, in 90 years, that $1000 renewal fee goes to $256000 in inflation-adjusted dollars. 110 years it’s a million dollars, 210 years it’s a billion dollars. If a work is worth spending that kind of money on renewing the copyright, why not let them keep it?
(Xpost from my lobsters comment since the Author's active over here):
I really disagree with this article - despite protestation, I feel like their issue is with Yjs, not CRDTs in general.
Namely, their proposed solution:
1. For each document, there is a single authority that holds the source of truth: the document, applied steps, and the current version.
2. A client submits some transactional steps and the lastSeenVersion.
3. If the lastSeenVersion does not match the server’s version, the client must fetch recent changes(lastSeenVersion), rebase its own changes on top, and re-submit.
(3a) If the extra round-trip for rebasing changes is not good enough for you, prosemirror-collab-commit does pretty much the same thing, but it rebases the changes on the authority itself.
This is 80% to a CRDT all by itself! Step 3 there, "rebase its own changes on top" is doing a lot of work and is essentially the core merge function of a CRDT. Also, the steps needed to get the rest of the way to a full CRDT is the solution to their logging woes: tracking every change and its causal history, which is exactly what is needed to exactly re-run any failing trace and debug it.
Here's a modified version of the steps of their proposed solution:
1. For each document, every participating member holds the document, applied steps, and the current version.
2. A client submits (to the "server" or p2p) some transactional steps and the lastSeenVersion.
3. If the lastSeenVersion does not match the "server"/peer’s version, the client must fetch recent changes(lastSeenVersion). The server still accepts the changes. Both the client and the "server" rebase the changes of one on top of the other. Which one gets rebased on top of the other can be determined by change depth, author id, real-world timestamp, "server" timestamp, whatever. If it's by server timestamp, you get the exact behavior from the article's solution.
If you store the casual history of each change, you can also replay the history of the document and how every client sees the document change, exactly as it happened. This is the perfect debugging tool!
In conclusion, the article seems to be really down on CRDTs in general, whereas I would argue that they're really down on Yjs and have written 80+% of a CRDT without meaning to, and would be happier if they finished to 100%. You can still have the exact behavior they have now by using server timestamps when available and falling back to local timestamps that always sort after server timestamps when offline. A 100% casual-history CRDT would also give them much better debugging, since they could replay whatever view of history they want over and over. The only downside is extra storage, which I think diamond-types has shown can be very reasonable.
I know it seems that way, but it's actually not 80% of the way to a CRDT because rich text CRDTs are an open research problem. Yjs instead models the document as an XML tree and then attempts to recreate the underlying rich text transaction. This is much, much harder than it looks, and it's inherently lossy, and this fundamental impedance mismatch is one of the core complaints of this article. Some progress is being made on rich text CRDTS, e.g., Peritext[1]. But that only happened a few years ago.
Another important thing is that CRDTs by themselves cannot give you a causal ordering (by which I mean this[2]), because definitionally causal ordering requires a central authority. Funnily enough, the `prosemirror-collab` and `prosemirror-collab-commit` do give you this, because they depend on an authority with a monotonically increasing clock. They also also are MUCH better at representing the user intent, because they express the entirety of the rich text transaction model. This is very emphatically NOT the case with CRDTs, which have to pipe your transaction model through something vastly weaker and less expressive (XML transforms), and force you to completely reconstruct the `Transaction` from scratch.
Lastly for the algorithm you propose... that is, sort of what `prosemirror-collab-commit` is doing.
I'm big into DnD podcasts, so Dragon Friends (Australian comedians doing DnD), The Adventure Zone (McElroy boys & dad doing DnD), Not Another DnD Podcast, etc.
Matt Levine's Money Stuff has a podcast with his friend and reporter Katie Greifeld, which is a lot of fun chatting about Money Stuff in an informative way.
I go through cycles of being obsessed with Blank Check (which goes through director's filmographies), and often more specifically, The Phantom Podcast (and sequels) where they watched The Phantom Menace over and over again under the guise of it being the only Star Wars movie.
I have a radical solution - it should not be possible to contact someone unsolicited.
All phone calls, SMS, emails, and instant messages should be blocked unless the other party is in my contacts or I have reached out to them first (plus opt-in contact from contacts of contacts, etc). Ideally, cryptographically verified.
I would argue this is the real solution to spam and scamming - why on earth are random people allowed to contact me without my consent? Phone numbers or email addresses being all you need to contact me should be an artifact of an earlier time, just like treating social security numbers as secret.
I realize this isn't super practical to transition existing systems to (though spam warnings on email and calls helps, I suppose, and maybe it could be made opt-in). I dearly hope the next major form of communication works this way, and we eventually leave behind the old methods.
I have an even more radical solution. The real root of the problem is that we use this "money" concept to represent value. If money didn't exist there wouldn't be any reason to steal, hack, or scam.
What do we replace it with? Haha, idk man. How about water? More difficult to hoard in ridiculous quantities, better spend it before it evaporates, and it occasionally falls from the sky (UBI). That's what I call a liquid asset!
For sure, getting rid of money would help if we had an alternative.
I am actually pitching an alternative though that doesn't seem that out there to me. I'm honestly surprised it isn't already an option in mainstream messengers (or at least Signal).
Ah, I should have elaborated a bit more - the strict solution is out-of-band only, namely in person or allowing contacts-of-contacts to reach out.
I think practically you'd want to be able to create time-limited, otherwise uncorrelated invite tokens/addresses that you could freely give out and deactivate later.
I believe that the rename to OpenClaw happened after the cutoff date for pretty much all model's training data, so unless you say something that causes them to look it up they'll get it wrong and assume it's about the old PC game. I was messing around trying to get different models to setup an OpenClaw NixOS VM for me and had to disambiguate for most of the models I tried.
reply