nullifidian

2개월 전discuss

[deleted to avoid potential misinformation]

5개월 전discuss

I should have converted it to $' ', yes. It was posix shell compliant this way tho. (probably written when I knew more python than bash).

nullifidian

5개월 전discuss

>installing many packages

The issue is HOW MANY. This simple utility is in the 100-200 range, Zed editor is in 2000+ range. C/C++ software you find in distros is not only stabilized by the unstable/testing queue, which language repos don't have and don't plan to have, but also has 5-10x less dependencies on average.

nullifidian

5개월 전discuss

I would rather check urls with the following method:

  echo -e -n "https://іnstall.example-clі.dev" | python -c 'exec("""import sys, unicodedata\nfor ch in sys.stdin.read():\n  try:\n    print (ch, " ", unicodedata.name(ch))\n  except ValueError:\n    print ("codepoint ", ord(ch))\n""")'

instead of putting my trust in the hundreds of crates in this tool's Cargo.lock not having a supply chain attack.

nullifidian

6개월 전discuss

>Chechnya

So they invaded their own internationally recognized territory. Wonderful. By that standard Ukraine invaded Donbass after they declared themselves independent of Ukraine.

>Syria

Even more outlandish claim, considering they were invited by the government. Whether the west considered the government illegitimate or not didn't matter.

>Moldova >Georgia

in both conflicts in protection of a minority, on whose territory a larger state laid claim using Soviet drawn borders and dissolution of the USSR. Since the Ukrainian conflict started I observed lots of enthusiasm for Soviet borders on the side of Russia's detractors, which were often drawn with territories assigned as a form of favoritism, simply because communist leadership in Moscow had better a relationship with the communist leaders of one of the ethnicities in question. That way historic Armenian land of Artsakh was assigned to Azerbaijan for example -- the recent ethnic cleansing outcome of that is well known.

nullifidian

2년 전discuss

It would have made it worse, because there would be 300 crates with 250 different maintainers, all pulled in by several trivial/baseline dependencies. More dependencies = higher the probability that a malicious maintainer has gotten maintainer's rights for one of them, especially because many original authors/maintainers of rust style microdepencency crates move on with their lives and eventually seek to exit their maintainer role. At least for classic C/C++ software, by the virtue of it being very inconvenient to casually pull 300 dependencies for something trivial, there are fewer dependencies, i.e. separate projects/repos, and these tend to be more self-contained. There are also "unserious" distributions like Fedora and something like stable/testing/unstable pipeline in Debian, which help with catching the most egregious attempts. Crates.io and npm are unserious by their very design, which is focused on maximizing growth by eliminating as many "hindrances" as possible.

nullifidian

3년 전discuss

The experience will probably be hellish anyway because of the Web integrity API. Javascript compiled to asm.js could produce painted-to-canvas websites too, and it won't be any less viable especially considering the growth of the CPU scores. Webassembly is prevalent in the canvas use cases because DOM manipulation with it is slower, clunky(due to the poor browser integration) and because people want to reuse native-language codebases.

If the canvas website really was a threat we would have seen much more of it by now already, but it hasn't happened for a number of reasons -- we only see them in the dedicated desktop-app-like use cases like this one. Anything scrollable won't be viable because it would be inherently less responsive than the real deal. Fonts look different, most designers actually prefer for people to be able to select text, and be able to use browser functionality that looks native for the different OSs. Canvas websites are also more expensive in terms of blob loading and ability to cache pages. So it's not really a threat.

Most adblocking happens by the means of network/URL blocking and I don't see any potential difference between WASM and JS in this regard(unless the APIs are enshittified, but JS isn't impervious to this too). If ads can't be blocked by network, and the website proxies ad contents through its own domain(as far as I know that's not prevalent, maybe I'm ignorant -- they need to track users and clicks themselves anyway), than you could get hard to block websites with JS+DOM too -- it's possible disrupt DOM based blocking by frequent randomization/obfuscation to the degree that one would need some kind of advanced AI to even hope to find the ad DOM elements. Between WEI, web bundles, Topics API push, webassembly's supposed higher indecipherability (which isn't true, chrome "disassembles" WASM into the WAT form and it's pretty readable. More readable than wasm.js) doesn't even register.

>And for what?

To not deal with JavaScript? To be able to develop for the web in the language you want, without floats being the fundamental numeric type and other BS? Is that too fantastical of a desire?

nullifidian

3년 전discuss

that ship has sailed. Minified and optionally obfuscated js is already highly annoying to decipher. The wasm spec is surprisingly high level for what should be a low level VM, and is planned to get much more high level approaching near jvm levels, and isn't any less readable than C++ compiled to asm.js.

nullifidian

3년 전discuss

>you don't really need any (almost any?) intermediate JS anymore

I don't think that's true. You still need JS glue code that would return these externrefs. A WebAssembly module loaded through ESM integration can't as far as the current proposals access Web-APIs on its own. As far as I understand there is also a number performance issues related to the wasm spec itself that limit possible optimizations, making wasm second class to JS in terms of performance of WebAPI access.

nullifidian

3년 전discuss

Do you know anything about any WASM developments that will enable pure WASM interaction with the browser's Web-APIs at no or at a low cost without the JS layer? Sometimes I look at https://github.com/WebAssembly/proposals and it's very confusing. There are the type imports proposal(years away), the almost complete GC proposal(which is apparently only for GCd languages, but not for anything browser<->wasm), the component model(which looks and sounds as something not for the browser use case), JS String Builtins (which will provide faster JS strings, but not DOM) and ECMAScript module integration (which will turn WASM modules into ES modules, but Web-APIs aren't ES modules so no luck). Sometimes I read contributor interactions and it looks as if providing such functionality isn't their priority or even in their plans, and for the majority the WASI + component model for the cloud, crypto and similar use cases are more important.

comments