The differences in regional prices are interesting to me. From a recent article comparing BYD's offerings [1]:
> The BYD Dolphin EV sells for the equivalent of around $16,500 in China, while in Germany, with the same battery pack, it’s over $37,400, or more than double the price. The Seal costs around $30,300 in China, while a similar version currently on sale in Germany is over $48,000. Reuters found Dolphin prices outside China between 39% and 178% higher, while those for the Seal ranged between 30% and 130% higher.
Affordable EVs are here already, though access to them is not evenly distributed.
$30/mo is $360/yr, which for most people is a prohibitively large sum of money. That would make Bluesky access more expensive than even the most expensive Netflix subscription; closer to the cost of a cellular plan.
For comparison: for my Mastodon account I pay $5/mo or $60/yr to a dedicated hosting provider. This puts it in the same ballpark as paying for a private email host or a VPN subscription.
This makes sense, but a Relay isn't something you'd expect a normal user to run.
It doesn't meaningfully make you "more independent" because all Relays are trivial (they're just dumb re-broadcasters of a stream) and it makes sense to use one run by somebody else — a company or a community that's pooling resources.
Aren't the entities who manage relays the ones who broker access to the network? E.g. if you subscribe to a relay, you must also subscribe to their moderation decisions.
Say if Bluesky (the company) bans someone, that person could still have the keys to their data, but their feeds will no longer be "re-broadcast" by that company's servers - right?
Relays aren't really user-facing, so most relay operators would probably only censor a user on the relay if there is some legal or network reason to do so, say content illegal in their jurisdiction or excessive spam.
If an app is concerned that a relay is censoring some user that they care about, the easiest solution is just to host their own relay. It's probably cheaper to operate than their app is. But if they really wanted to, they could listen to multiple relays to "cover the gap" or just manually listen to the event stream from specific users' PDSs directly whenever they notice censorship (effectively operating a partial relay in addition to listening to a full but censored one). But, again, in reality they'd just host their own relay and not bother complicating things.
The hardest problem of relays censoring content is to notice it happening, but once you notice you can easily verify it and switch to a different relay.
The PDS is closer to the Mastodon account and will run you the same amount of money. The relay or appview is what takes the load when one of your posts goes viral, whereas in mastadon your $5 VPs has to handle that spike in traffic. Been several a story about how AP has DDoS'd a small server because there is no equivalent to the relay
It's hard to tell honestly. I studied psychology for two years in uni, and I dropped out rather disillusioned about the field. Some of my least favorite aspects included:
- Acknowledgement by our professors that P-hacking (pruning datasets to get the desired results) was not just common, but rampant
- One of our classes being thrown in limbo for several months after we found out that a bunch of foundational research underpinning it was entirely made up (See: Diederik Stapel).
- Experiencing first-hand just how unreproducible most research in our faculty was (SPSS was the norm, R was the exception, Python was unused).
- Learning that most psychology research is conducted on white psychology students in their early/mid-twenties in the EU and US. But the findings are broadly generalized across populations and cultures.
- Learning that the DSM-IV classified homosexuality as a mental disorder. Though the DSM-V has since dropped this.
The DSM-V is still incredibly hostile towards trans people through a game of internal power politics and cherry-picked research. It's really bad honestly.
Though I do generally hold psychologists in high regard (therapy is good), I'm not particularly impressed by psychology as a science. And in turn don't necessarily trust the DSM all that much.
> Experiencing first-hand just how unreproducible most research in our faculty was (SPSS was the norm, R was the exception, Python was unused).
How did you experience this? Did you fail to reproduce the same results when doing the research again while using R? This is how I interpret your statement, but I think it's not what you mean.
If SPSS was the norm, R or SciPy shouldn't have made a difference in reproducibility as the statistics should be more or less the same. I did social science with SPSS fine; T-Tests, MANOVA, Cronbach's alpha, Kruskall-Wallis, it's all in there. It seems you suggest that using SPSS inherently makes for bad and irreproducible science, it's similar to saying using Word instead of an open source package like LaTeX makes research unreproducible even if the data, methodology and statistics are openly accessible. This is not the case. What i mean is that while I agree there can be friction between using Word and SPSS and
Open Science and FAIR principles because of the proprietary formats, this isn't inherently a problem as people can use the dataset (csv or sqlite) and do the mentioned statistical tests outlined in the published pdf (or even an imported docx) in any statistical language.
>One of our classes being thrown in limbo for several months after we found out that a bunch of foundational research underpinning it was entirely made up (See: Diederik Stapel).
That's mild. In one of Chile's largest and most prestigious universities, Jodorowsky "psychomagic" is teached as a real therapeutic approach.
As someone with zero knowledge of psychology, I'm biased against it. Partly because of my vague impression that psychology tries to fit people to models, rather than viewing models as limited approximations.
For a while I've thought it would be nice to know what results the field of psychology actually has that are trusted.
Was there anything at all in the taught content which you liked?
I didn't realise the DSM-V was that bad. If research on trans people can be cherry-picked, then does that mean that some reliable research exists?
> As someone with zero knowledge of psychology, I'm biased against it.
Then you are biased against "the science of mind and behavior"[0] by definition.
> For a while I've thought it would be nice to know what results the field of psychology actually has that are trusted.
Perhaps that people who seek out and engage in therapy with qualified professionals can (but not always) improve their lived experience?
Or that by studying the mind and human behavior, mental illness is now considered a medical condition, worthy of treatment, and has much less social stigma than years past?
> One of our classes being thrown in limbo for several months after we found out that a bunch of foundational research underpinning it was entirely made up (See: Diederik Stapel).
I wonder if you can sue for fraud over this. The researcher knowingly deceived academia, and it's foreseeable that students would then pay to study the the false research.
Yes, that's the summary of the incentive system. It's not a highly remunerative profession although the rockstars can do quite well (usually through side gigs).
Practitioners of economics accept many types of scarcity and currency. Consider, for example, the marketplace of ideas paid for with attention, belief, energy spent spreading our favorites.
We are more or less trying to solve this exact problem with Wasm Components [1]. If core WebAssembly is a portable instruction format, WebAssembly Components are a portable executable/linkable format.
Using them is unfortunately not yet quite as easy as using repr(wasm)/extern "wasm". But with wit-bindgen [2] and the wasm32-wasip2 target [3], it's not that hard either.
I love WASM and WASI, but it's not nearly the same, unfortunately. Performance takes a hit, you can't use async in a straightforward way, launching hundreds of thousands of tasks is problematic etc. WASM is great for allowing to extend your app, but I don't see it as a replacement for an ABI anytime soon
Hey all, today the Azure Core Upstream team has open sourced Wassette: a WebAssembly-based runtime that allows Wasm Components to connect to AI agents using the Model Context Protocol. Wassette’s main contribution to the MCP space is efficient sandboxing: because if you’re going to run untrusted third-party tools locally, it’s probably a good idea to proactively restrict which system resources it can access.
In this post we explain what Wassette is, how to set it up locally, and finally walk through an example that exercises Wassette’s capability system. What we don’t cover in the post is how to write Wasm Component-based tooling for Wassette, but we have some docs for that in the README [1].
Anyway, I hope this interesting to folks here! I’ll be around for a couple of hours here to answer questions folk might have. And if I don’t know the answer, I can probably find an engineer who does. Thanks!
`await-tree` seems to be able to output to JSON. As long as all keys are unique, it should be straightforward to convert it into the Collapsed Stack Format most flame graph tools natively ingest.
As a reference: I wrote a Dhat-JSON to Flamegraph conversion tool a while ago for fun. Adapting this to instead convert from the await-tree JSON format probably shouldn't take long:
A study published just yesterday [1] showed that just two airborne diseases [2] were responsible for approximately 85% of all sicks days in Greece during 2023-2024. Disregarding the common-sense argument that reducing collective suffering is a good thing overall - even by the cold hard logic of capital, being able to reduce company sick days by up to 85% is a huge opportunity.
Imo we're way overdue standards and controls for clean indoor air that are on par with standards for drinking water and food. Like this article shows, we have the tech to provide clean air today. All we're missing is policy to uniformly deploy it.
Might this be related to the fact that Greeks tend not to take sick days compared to other European countries[1]? Not coming to work because you have covid is far more culturally accepted (and maybe expected) than a common cold.
I agree about what your concerns about complexity, but the way I see what we're
encapsulating is almost entirely essential. To draw analogies with native binaries:
- Wasm is a (virtual) instruction format for programs to be compiled into (think: x86).
- Wasm Components are a container format and type system that wrap Core Wasm instructions into typed, hermetic binaries and libraries (think: ELF).
- WASI is a reserved namespace for a collection of standardized Wasm component interfaces (think: POSIX header files).
To reach our goal of having shared, portable binaries that aren't locked into
any one vendor we need all three. A standard instruction set, standard calling
convention, and standard syscalls. Wasm Components and WASI might not be
necessarily be perfect, but at a minimum they're targeting the right scope. And that carries essential complexity.
I agree that some things are essential, and there's value in specifications. The question is how likely is the current tragectory to follow what happened with browsers? The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it?
Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? Because that's how you end up in the situation where the "user agent" with majority market share starts gutting ad blockers.
I'm not saying I'm predicating this will happen with WASM or even think it's very likely. I don't know enough to have a real opinion on that. I'm just saying I really really don't want it to happen.
> Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation?
The big change going from WASI 0.1 to WASI 0.2 is that we decoupled the calling convention (Wasm Components) from the actual syscall APIs (WASI). That enabled us to make the various syscall APIs modular and composable.
Because CDN functions probably shouldn't know about TCP; and CLI applications probably don't care about blob storage. And now they don't need to. Take a look at the WASI Proposals page [1] for an overview of all WASI APIs.
>The question is how likely is the current tragectory to follow what happened with browsers?
What happened to browsers? Few vendors implementing them? There are still 3 major vendors supporting an open source runtime or two (Google and MS on Blink), and a good open implementation (Mozilla). Better than 20 competing engines, does anybody miss IE's own engine?
And with WASM it's way easier for multiple implementations to be written, if need be, as it's a language runtime. These have 1/100th the scope of a browser (which is 99 other very hard to implement things PLUS a WASM runtime).
>The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it?
Because "let third parties define and write basic libraries" (and sockets and http are very basic) has been a disaster every time. You get a fragmented ecosystem, several popular libs fighting it out, and users either stay away or suffer the consequences.
At least with an official spec implementations will be compatible, and we'll get some reference one.
I think it makes a lot of sense to have a standard HTTP interface. I mean, HTTP is well defined and the interface matches the spec pretty closely. Allowing implementers to use whatever underlying protocols is sensible, specially in cloud environments.
You can also have a standard web assembly component that simply implements wasi-http on top of wasi-sockets.
I suspect that Wasm on the web mostly just works and so we don't hear too much
about it. It is occasionally mentioned in passing though, usually as part of
another announcement. Well-known production users of Wasm on the web include
Dropbox [1], Adobe [2], Figma [3], and 1Password [4].
That reminds me of the time when Java applets had their high time.
I think that WASM in the browser will either largely replace JavaScript or will wither away like Java applets did. I fear there is no in-between and if it is only because no one will support two languages and ecosystems in parallel and in the long run. Not the big companies and certainly not the small ones.
There is an in-between, which is the world we live in right now.
JavaScript and TypeScript are great languages with excellent Web integration, whereas wasm is focused on pure computation (forcing it to bundle its standard library, for example). But wasm has predictable performance that is close to native builds, and sometimes you need that.
Very few web pages use only wasm. Most uses of wasm on the wasm are as part of a JavaScript site, for the parts where wasm makes sense.
I'd bet the current state is not sustainable and we will see a consolidation one way or another.
The danger for WASM is that JavaScript doesn't stand still either and we might as well see improvements that make the gap to WASM's selling points smaller.
JavaScript is being developed with the assumption that wasm will continue to exist. For example, JS is unlikely to get SIMD support because wasm can do SIMD in a cleaner way than JS can. (I am one of the people developing JavaScript.)
Rather, what we're likely to see is work which makes integration between wasm and JS easier - see, for example, the wasm string builtins proposal [1], the proposal for native support for importing wasm from JS [2], or the proposal for fixed-layout JS objects which would allow directly reflecting wasm-GC objects in JS [3].
> The BYD Dolphin EV sells for the equivalent of around $16,500 in China, while in Germany, with the same battery pack, it’s over $37,400, or more than double the price. The Seal costs around $30,300 in China, while a similar version currently on sale in Germany is over $48,000. Reuters found Dolphin prices outside China between 39% and 178% higher, while those for the Seal ranged between 30% and 130% higher.
Affordable EVs are here already, though access to them is not evenly distributed.
[1]: https://insideevs.com/news/718036/byd-major-ev-markup-prices...