Ben Matthews

  • New here on lemmy, will add more info later …
  • Also on mdon: @benjhm@scicomm.xyz
  • Try my interactive climate / futures model: SWIM
  • 0 Posts
  • 73 Comments
Joined 2 years ago
cake
Cake day: September 15th, 2023

help-circle
  • 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 ?





  • In principle I’d like to see specific permissions - so for example playing with gui enhancements should be a lower trust barrier than adjusting and running code, but afaik (correct me if wrong) neither js nor rust have a built-in security architecture that could implement this. Maybe certain types of extensions could just be custom script language without filesystem access, but that’s harder to do.

    About source code linking, last time I heard (maybe they fixed it?) it seemed that trick vscode extensions can link to arbitrary (safe-looking) source repos, which didn’t actually produce the extension.

    I’m less convinced about slowly accumulating publisher trust, as this could be a barrier to honest new contributors, while big actors with a longterm profit or geopolitical motive could game such a system anyway (as they do for social media).

    I do trust the scala tools (build Mill, lang-server Metals, compiler) which adjust my code, having seen them evolve over many years.
    and like the separation of functions (lang-server / editor), so we are less dependent on any one big-tech solution. So I suppose a fundamental issue is what to trust less - big corps with a reputation but lock-in power, or an ecosystem of small contributors which might include tricksters. No perfect balance.


  • It seems so far Zed is cautious, providing api only for specific extensions - i.e. language servers and gui themes.

    add a line … right before you run it

    I run stuff from the command line using a trusted build tool (Mill, in scala), or via a local server (where js is sandboxed).
    But indeed, a tricky language server or AI tool (I don’t use yet) might inject code where I don’t inspect before running it. That’s a risk even with java-based IDEs - java has security permissions, not in js (vscode) or rust (zed), but are they applied…? As for audits, a problem with vscode is the marketplace got too big, so many extensions, many lookalikes, nobody can check them all…







  • Fine map, good to see the old names. But some of these routes are pretty impassable even today - for example I doubt the Wakhan corridor was ever a major route, even the bottom of that narrow valley rises above 4000m. And note Torugart pass (been there…) is north of Kashgar on the way to Issyk Kul (missing lake), not on the way to Osh. So, considering the mountains, I guess a larger fraction than indicated crossed the steppe further north - horses wouldn’t need roads or cities, but it’s easier.





  • OK so I read "Here the key concept is that some of the effects of the large herbivores, such as eradicating trees and shrubs or trampling snow, will result in a stronger cooling of the ground in the winter, leading to less thawing of permafrost during summer and thereby less emission of greenhouse gases".
    I know the big impact of trees and shrubs on albedo - in spring they absorb sunlight and shake off snow, which remains on flat grassland. But regarding trampling - compaction- I’m not convinced. Winters are long and summers short, so accelerating cooling by some weeks wouldn’t make so much difference, as accelerating warming in the summer - that’s when the gases are released.
    Anyway what we do urgently need is global science cooperation to try to save the carbon and ecosystems of that permafrost, in that spirit such projects might help to thaw geopolitical obstacles.