very cool.
Uncategorized
27
Posts
14
Posters
0
Views
-
@lina @whitequark like that is my point here, i cannot think of any reason why a website needs to know i have 128 threads
@ariadne @lina i ship an FPGA toolchain in the browser. it can* use multithreading. it needs to know how many threads to run to not contend on resources uselessly
* currently not built in that configuration for a variety of reasons that is not specifically tied to the web
-
@ariadne @lina i ship an FPGA toolchain in the browser. it can* use multithreading. it needs to know how many threads to run to not contend on resources uselessly
* currently not built in that configuration for a variety of reasons that is not specifically tied to the web
@ariadne @lina it's not a reason to expose information useful to, like, 1 site you might maybe use, to every of them, and frankly i am not aware of any material benefit from running more than 4 of p&r threads in parallel so it could probably be capped to that. but i think this is a legitimate reason
-
@ariadne @lina it's not a reason to expose information useful to, like, 1 site you might maybe use, to every of them, and frankly i am not aware of any material benefit from running more than 4 of p&r threads in parallel so it could probably be capped to that. but i think this is a legitimate reason
@whitequark @ariadne @lina a problem is we use the web browser for two totally separate purposes: as a way of looking at transient text/image/video content; and as the only surviving application platform. we want two totally opposite things out of these two different platforms ("control the computer" vs "touch nothing"), but insist on not delineating the two website metacategories. and microsoft/apple/android are only gonna keep making it harder to offload applications back onto "computers"
-
@whitequark @ariadne @lina a problem is we use the web browser for two totally separate purposes: as a way of looking at transient text/image/video content; and as the only surviving application platform. we want two totally opposite things out of these two different platforms ("control the computer" vs "touch nothing"), but insist on not delineating the two website metacategories. and microsoft/apple/android are only gonna keep making it harder to offload applications back onto "computers"
@whitequark @ariadne @lina The era where Flash was the "escalated privilege" layer of the web, and click-to-flash plugins were common, was the only time either the developer or user permissions model here made sense
-
@whitequark @ariadne @lina a problem is we use the web browser for two totally separate purposes: as a way of looking at transient text/image/video content; and as the only surviving application platform. we want two totally opposite things out of these two different platforms ("control the computer" vs "touch nothing"), but insist on not delineating the two website metacategories. and microsoft/apple/android are only gonna keep making it harder to offload applications back onto "computers"
-
@rpgwaiter @ariadne WASM uses it (and Anubis had a bug when the machine had an odd number of cores).
-
@lina @whitequark like that is my point here, i cannot think of any reason why a website needs to know i have 128 threads
@ariadne @lina @whitequark ah. it's a spam signal. like it cuts into their profits if they treat data-center hardware as likely to have a human sitting in front of it using it as a personal device, so they try to not do that.
-
@ariadne @lina @whitequark ah. it's a spam signal. like it cuts into their profits if they treat data-center hardware as likely to have a human sitting in front of it using it as a personal device, so they try to not do that.
@ariadne @lina @whitequark apologies for using a vague "they" there; specifically it cuts into the revenue of ad networks and the various participants in ad ecosystems
-
@whitequark @ariadne @lina The era where Flash was the "escalated privilege" layer of the web, and click-to-flash plugins were common, was the only time either the developer or user permissions model here made sense
@mcc @ariadne @lina i think this is a reasonable way to view the problem domain but i don't entirely agree—i think the web is about as close to "fully granular permission model, without vendor lock-in" as we ever got and perhaps will ever get, and that it's valuable that i can give a webpage access to a USB device while denying it everything else on the computer, like "filesystem"
unfortunately, i cannot in good faith say that the fully granular permission model works. technically it could be made to work, sure, but getting people to understand the exact consequences of granting X permission is probably a lost cause—it would take someone a lot smarter than me to figure out how to do it
unfortunately#2 the actual, real-world alternative to doing that is "download and run an .exe" or "curl | bash" which is strictly worse. so i just don't know
-
@mcc @ariadne @lina i think this is a reasonable way to view the problem domain but i don't entirely agree—i think the web is about as close to "fully granular permission model, without vendor lock-in" as we ever got and perhaps will ever get, and that it's valuable that i can give a webpage access to a USB device while denying it everything else on the computer, like "filesystem"
unfortunately, i cannot in good faith say that the fully granular permission model works. technically it could be made to work, sure, but getting people to understand the exact consequences of granting X permission is probably a lost cause—it would take someone a lot smarter than me to figure out how to do it
unfortunately#2 the actual, real-world alternative to doing that is "download and run an .exe" or "curl | bash" which is strictly worse. so i just don't know
@whitequark @ariadne @lina well, but that's exactly the problem i think. we built a fully granular permissions model where we really actually wanted a bimodal permissions model. and because the granular permissions model is so *incredibly fucking complicated*, the browser vendors go way out of their way to hide it, so it's not very useful.
browser vendors snowed us with the useless notifications/locations requests, and now are terrified to add perm popups because they got bad feedback on that.
-
@whitequark @ariadne @lina well, but that's exactly the problem i think. we built a fully granular permissions model where we really actually wanted a bimodal permissions model. and because the granular permissions model is so *incredibly fucking complicated*, the browser vendors go way out of their way to hide it, so it's not very useful.
browser vendors snowed us with the useless notifications/locations requests, and now are terrified to add perm popups because they got bad feedback on that.
@whitequark @ariadne @lina why is webrtc locked behind the microphone permission. i know what the web browsers *claim* is the answer to this question but imo the real reason is that they set out to make a fully granular permissions model, immediately discovered that had downsides, and have been backpedaling ever since
(I acknowledge the fully granular model is what works best for your goal of shipping an FPGA programmer)
-
@mcc @ariadne @lina i think this is a reasonable way to view the problem domain but i don't entirely agree—i think the web is about as close to "fully granular permission model, without vendor lock-in" as we ever got and perhaps will ever get, and that it's valuable that i can give a webpage access to a USB device while denying it everything else on the computer, like "filesystem"
unfortunately, i cannot in good faith say that the fully granular permission model works. technically it could be made to work, sure, but getting people to understand the exact consequences of granting X permission is probably a lost cause—it would take someone a lot smarter than me to figure out how to do it
unfortunately#2 the actual, real-world alternative to doing that is "download and run an .exe" or "curl | bash" which is strictly worse. so i just don't know
@whitequark @mcc @ariadne @lina Flatpak has a bunch of permissions one can grant, just saying ...
-
@whitequark @ariadne @lina a problem is we use the web browser for two totally separate purposes: as a way of looking at transient text/image/video content; and as the only surviving application platform. we want two totally opposite things out of these two different platforms ("control the computer" vs "touch nothing"), but insist on not delineating the two website metacategories. and microsoft/apple/android are only gonna keep making it harder to offload applications back onto "computers"
@mcc @whitequark @ariadne @lina I want to know if anybody is working on separating the web into those two things. It can only make things better for everyone. We can get hypertext documents that load fast and look better than ever, and network-sourced applications with runtimes that are performant on a potato.
-
@ariadne @lina it's not a reason to expose information useful to, like, 1 site you might maybe use, to every of them, and frankly i am not aware of any material benefit from running more than 4 of p&r threads in parallel so it could probably be capped to that. but i think this is a legitimate reason
@whitequark @ariadne @lina This seems like a reasoning I've seen in the late 90s, where some browser would send your OS login password along to literally every web request. Sure, there *could* be some where it's useful, but they can ask for it explicitly, and I can give them permission. The default should always be not to send those things.
-
@ariadne @lina i ship an FPGA toolchain in the browser. it can* use multithreading. it needs to know how many threads to run to not contend on resources uselessly
* currently not built in that configuration for a variety of reasons that is not specifically tied to the web
@whitequark @ariadne @lina Uh - cool, but it tells me "web assembly JSPI is not enabled". After enabling it in Firefox' about:config, it still says it's not enabled. Any ideas?
-
@whitequark @mcc @ariadne @lina Flatpak has a bunch of permissions one can grant, just saying ...
@hruske @whitequark @mcc @ariadne @lina
yeah and everything just gets full read write access to your home directory making because devs are lazy and body cares -
very cool. this is why i hate the modern web.
@ariadne oh that's nothing. Check this out
-
@whitequark @mcc @ariadne @lina Flatpak has a bunch of permissions one can grant, just saying ...
@hruske @whitequark great, now you can ship your app to… desktop Linux users (but NOT to Ubuntu systems which are the most common ones)
-
@hruske @whitequark @mcc @ariadne @lina
yeah and everything just gets full read write access to your home directory making because devs are lazy and body cares@tthbaltazar @hruske @whitequark @mcc @ariadne @lina regarding fingerprint metrics imma just throw in https://amiunique.org/fingerprint
-
@whitequark @mcc @ariadne @lina Flatpak has a bunch of permissions one can grant, just saying ...
@hruske flatpak takes granular permissions but it does not make them usable. Unless you expect the user to understand what "uses a legacy window system" means in terms of permissions. Sandboxing isn't easy, nor is seamlessly injecting permission prompts into applications which weren't designed for it, but the actually hard part is the permissions model. It needs to somehow be comprehensible by ordinary folks, while not overly constricting for 'power users'.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@levelbot I feel good about myself and this number.
-
@reiver@mastodon.social knowing people in general... They will get more bug reports if they said "whom"
-
@reiver I've heard John Mastodon personally picks those out of a tall hat, for each user, individually. What a great man.
-
I'm writing this in English.
Not because English is my first language—it isn't. I'm writing this in English because if I wrote it in Korean, the people I'm addressing would run it through an outdated translator, misread it, and respond to something I never said. The responsibility for that mistranslation would fall on me. It always does.
This is the thing Eugen Rochko's post misses, despite its good intentions.
@Gargron@mastodon.social argues that LLMs are no substitute for human translators, and that people who think otherwise don't actually rely on translation. He's right about some of this. A machine-translated novel is not the same as one rendered by a skilled human translator. But the argument rests on a premise that only makes sense from a certain position: that translation is primarily about quality, about the aesthetic experience of reading literature in another language.
For many of us, translation is first about access.
The professional translation market doesn't scale to cover everything. It never has. What gets translated—and into which languages—follows the logic of cultural hegemony. Works from dominant Western languages flow outward, translated into everything. Works from East Asian languages trickle in, selectively, slowly, on someone else's schedule. The asymmetry isn't incidental; it's structural.
@Gargron@mastodon.social notes, fairly, that machine translation existed decades before LLMs. But this is only half the story, and which half matters depends entirely on which languages you're talking about. European language pairs were reasonably serviceable with older tools. Korean–English, Japanese–English, Chinese–English? Genuinely usable translation for these pairs arrived with the LLM era. Treating “machine translation” as a monolithic technology with a uniform history erases the experience of everyone whose language sits far from the Indo-European center.
There's also something uncomfortable in the framing of the button-press thought experiment: “I would erase LLMs even if it took machine translation with it.” For someone whose language has always been peripheral, that button looks very different. It's not an abstract philosophical position; it's a statement about whose access to information is expendable.
I want to be clear: none of this is an argument that LLMs are good, or that the harms @Gargron@mastodon.social describes aren't real. They are. But a critique of AI doesn't become more universal by ignoring whose languages have always been on the margins. If anything, a serious critique of AI's political economy should be more attentive to those asymmetries, not less.
The fact that I'm writing this in English, carefully, so it won't be misread—that's not incidental to my argument. That is my argument.
-
I've been checking out @inkwell , the new journaling app on the Fediverse. It looks absolutely great. Fantastic work by @stanton. If you'd like to follow me there, check out @evan@inkwell.social.
-
There is the complete list that Mastodon is suggesting I (potentially) follow.
-
Moaner's CRYING TOWELS
only 15¢ from Johnson Smith and Co (1951)
-
It's "Whom To Follow" not "Who To Follow".
I.e., WHOM not WHO.
...
Also, I wonder how Mastodon picked those choices to me to (potentially) follow.
