Ben Matthews

Isn’t it technically possible to split browser functions so we can recombine as we like? - i.e. separating the rendering / js engine from everything around the side - managing all the tabs, bookmarks, cookies and passwords, workspaces and sessions, mail, notes etc. In my case, I like the workspace structure provided by Vivaldi, but don’t see why it has to be built on chromium browser. Anyway as a developer I need to test against blink, webkit and gecko, so would be nice to swap them within the same user interface structure.
By the way, I develop a “javascript-heavy” web-app (interactive climate model) and it seems to be working fine, and fast, in firefox, so I’m not convinced by complaints in the article.

Well problem with any Lemmy community as such a forum, is that current usage (not necessarily intrinsic to the software) is so ephemeral. So it’s good for discussing breaking news, but not to gradually accumulate discussion of solutions to complex problems, over years. I wish this were not the case, but doubt anybody will even notice this comment, as no longer ‘hot’, and folded away … Rather, a few weeks later the same topic will be reopened under a different post, and we start over again.

I agree with most of what you say. I’m a long-time fan of calculating more complex things client side, as you can see from my climate model (currently all calcs within web browser, evolved from java applet to scalajs).
Also, in regarding social media, keeping the data client side could make the network more resilient in autocratic countries (many), and thelp this become truly a global alternative.
On the other hand, some ‘trunk’ server interactions could also doing more not less, bundling many ‘activity’ messages together for efficiency - especially to reduce the duplication of meta-info headers in clunky json, and work of authentification-checking (which I suppose has to happen to propagate every upvote in Lemmy?).

Thanks, that makes sense if I think about it, but maybe users shouldn’t have to - i.e. the Mdon part-conversation way still seems confusing to me (despite being a climate modeler and scala dev), although haven’t used Mdon much since I found Lemmy. And I still feel that both ways seem intrinsically inefficient - for different reasons - if we intend to scale up the global numbers (relating OP).

That makes sense, to store only popular stuff, or temporarily - especially for ‘heavier’ images (although as we see with lemm.ee, that leads to issues when an instance dies). Yet I also wonder about the scalability of just the minimum meta-info, whose size does depend on the protocol design.
For example with Lemmy every upvote click propagates across the network (if i understand correctly, mastodon doesn’t propagate ‘likes’ so consistently, presumably for efficiency, but this can make it seem ‘empty’). Maybe such meta-info could be batched, or gathered by a smaller set of ‘node’ instances, from which others pick up periodically - some tree to disperse information rather than directly each instance to each other instance ?
As the fediverse grows, gathering past meta-info might also become a barrier to new entrant instances ?

Eh? The graphic shown prominently in the linked summary article suggests that cycling is much better than walking. And this seems plausible to me - cycling is not just exercise, it requires quick thinking, balancing, interacting with traffic, judgements regarding risk, speed, efficiency, etc. .

I don’t think the general architecture scales that well (think of all the duplicate storage …

That’s my hunch too, although haven’t studied in detail - so I wonder how we can fix it ?
Is there an forum that discusses this scaling issue (in general, across fediverse) ?

Since much (so-called) “AI” basic training data depends on Wikipedia, wouldn’t this create a feedback loop that could quickly degenerate ?

There are more specific ad-server / tracker IPs that can be blocked at DNS level, tools like Pi-hole work that way (although if big countries did this, I suppose they’d quickly find workarounds to blend those addresses with useful ones).

Huh. There are some good use-cases for super-computers, but promising that massive application of AI is going to “make air travel more sustainable” - could hardly choose a worse example.

Maybe eventually they should build several smaller dams instead of one big one, just enough for irrigation and water supply, considering the potential ecological balance of the whole region, rather than of just a narrow potential ‘reserve’.
It’s naturally a dry area, the south bank opposite Kherson is already almost a ‘desert’ with dunes, although with a long history - they say such ‘Pontic Steppe’ grasslands were where indo-european tribes originated.
Anyway, before grand plans, Ukraine has to control both sides of the river, so I suppose they’ll keep watching how hard the mud bakes this summer.

Well, technically the internet backbone is already controlled locally, it’s the web services - software - that are dominated by US big-tech. And for such services to be safe we need a diversity of providers, not only local ones maybe easily coerced by our own national governments, some of which might also try to turn authoritarian in future. So the problem is not that US big-tech participates, rather that we let them become almost a monopoly.

This seems highly significant (at least as a precedent that others may follow), to me great news, but if that’s so why did I only see it reported here, on a ‘local’ community in Lemmy?