Give it a more charitable reading. But I think there is truth to it, CSS was never that great with just describing what you want, it was always more like arcane spells and tricks you learn to achieve a specific goal. Historically just trying to center something or achieve equal spacing would send you down a deep rabbit hole of quirks, browser support, layout modes and so on.
You might both be. China is focused on adoption and distilling is a cost-effective way to get there right now. If the conditions change they might well decide that they have to start training their own frontier models.
That said, China cannot make its own 2nm chips even though they definitely would like to. So I guess there are limits to what they can do sometimes.
do you also count eg published results of very expensive physics experiments? because once the costs of things like these are taken into account, we are way over 10 billions.
Thoughtfully and coherently factorized, abiding a set of architectural rules (i.e: we compose "this" way here, re-evaluated as we go) and following up-to-date framework conventions. LLMs are terrible at this.
Chosing OOP or FP is irrelevant, fundamentals matter more
Remark half-way in the rant they are using dendrite, an experimental matrix server implementation that has been abandonned. Thus ranting about it is cheeky at best.
I have been using synapse for years with little issue.
> Dendrite is kind of deprecated as a homeserver these days, at least it doesn't seem to be the main focus of development and most recent commits are mere dependency bumps. Years ago, when the server was set up, choosing Dendrite seemed like a good decision, because it was easier to deploy and maintain than Synapse and there was a promise for a bright future for the first 2nd generation homeserver implementation. Unfortunately, migrating between Matrix homeserver implementations remains a problem with no satisfying solution, so we're kind of stuck on slowly rotting foundations.
Dendrite may or may not have been a good choice for a Matrix homeserver at the time the decision to start it was made, years ago. But the real problem, as the blog post points out, is that there is no good way to change that decision. Migrating to a new homeserver implementation is equivalent to destroying the old server and creating a new one from scratch - which also has the implication that any user whose account was on the old server loses that account and has to create a new one, because Matrix user accounts are tied to some homeserver (a bad design decision, I think). Tying system identity to someone else's server - and that server's domain name - is the cardinal sin of federated identity systems, the ActivityPub ecosystem has exactly the same problem.
There is no technical reason why migrating between homeserver software doesn't work, there just is no tooling for it. Someone could build a Dendrite-to-Matrix exporter+importer. The protocol itself doesn't really care about what server software you're using.
I don't know any good messenger that doesn't tie their accounts to something portable. Plus, I think the ability to reset your password/passkey/whatever if you forgot it is way more important than having users manage their own identity roots for any serious messenger. The alternative is very cool, technology wise, but not really something I would care to use and maintain.
For users migrating accounts, there was a tool (not sure why it died) on the Matrix website that would log in to both accounts, go through each room and where possible invite the new account, and leave with the old account. As long as you have invite/join permissions, that's all you need to do for most chat rooms. 1-on-1 chats need some extra commands to set the metadata right so clients recognise them for what they are, but even they can be ported over, mostly. It's not a perfect solution, but it's lots better than nuking your entire account and starting over from scratch.
That is also an unfortunate design on Matrix' part. I had no problem migrating data when changing from ejabberd to Prosody. Because they are open source, so it's not really a problem to export to ad-hoc text and import again.
But Matrix closely follows proprietary products in its design, and the database is treated like some internal affair that you are not to meddle in. You'd have to reverse engineer the data format from source code, which is not practical for hobbyists.
> Years ago, when the server was set up, choosing Dendrite seemed like a good decision
> Unfortunately, migrating between Matrix homeserver implementations remains a problem with no satisfying solution, so we're kind of stuck on slowly rotting foundations.
I'm part of the sysadmin team who studied the migration paths for the Dendrite in question in this blog post and unfortunately as a volunteer it's hard to find the time to invent migration paths (even if we have the knowledge) and make it happen while there's also many other needs unaddressed elsewhere.
Given that you seem expert in the matter, would you like to help and own the migration? That'd be awesome!
I worked on Dendrite for a number of years, activity on it pretty much fell off a cliff after I left Element but there seems to be a fork called Zendrite that has carried on with development more recently. There is a migration path from a standard Dendrite installation: https://zendrite.pat-s.me/administration/migration-from-dend...
Such an uninsightful comment.
reply