81–90 of 152 posts
Earlier quoted context omitted.
Why did you opt for WASI for plugins instead of native compiled code?
Webassembly makes a lot of sense for plugins. * sandboxing, so plugins don't need to be as trusted * Easy cross-platform distribution with a single build artifact * plenty fast (if written in a language like Rust/C++ and paired with a good runtime)
Why don't plugins "need to be as trusted"? Obviously bad-actor plugins would be less effective and capable of inflicting any sort of attack on your development OS, but surely the development environment is the perfect vector for attacking the runtime environments that run your artifacts get deployed into?
Not to mention the potential for secrets-harvesting due to sloppy boot-strapping dev-env habits or other bad habits we often engage in during the early development process?
Or does WASI somehow provide protection from these issues?
Author here. I didn't expect this will go on Hacker News. Although the editor has been my daily drive for almost one year now, it's really rough on the edges. The plugin system as described in the README hasn't been implemented yet.
Hi, thanks for writing some free software! I'm not a Rust person, how do you install this? Is it something like "rustc install" or something like that? Thanks!
Earlier quoted context omitted.
Seems like Atom and VSCode picked the wrong tool for the job.
Both work fairly well, are popular and performance is satisfactory (unless you try to paste an 80k line JSON file into either of them, that doesn't work). Considering their success, wide availability and vibrant ecosystems, I'd say they picked the right tool for the job.
Earlier quoted context omitted.
If I escape vscode I'd rather it be to something lighter rather than heavier. I used sublime before vscode and I'm tired of my editor using up half my ram.
I think above comment is about jetBrains fleet. VSCode alternative written in kotlin
Earlier quoted context omitted.
Webassembly makes a lot of sense for plugins. * sandboxing, so plugins don't need to be as trusted * Easy cross-platform distribution with a single build artifact * plenty fast (if written in a language like Rust/C++ and paired with a good runtime)
Apologies for lack of my lack of knowledge in this area, but... Why don't plugins "need to be as trusted"? Obviously bad-actor plugins would be less effective and capable of inflicting any sort of attack on your development OS, but surely the development environment is the perfect vector for attacking the runtime environments that run your artifacts get deployed into? Not to mention the potential for secrets-harvesti…
The code is running inside a virtual machine rather than natively on the host.
Earlier quoted context omitted.
Webassembly makes a lot of sense for plugins. * sandboxing, so plugins don't need to be as trusted * Easy cross-platform distribution with a single build artifact * plenty fast (if written in a language like Rust/C++ and paired with a good runtime)
Apologies for lack of my lack of knowledge in this area, but... Why don't plugins "need to be as trusted"? Obviously bad-actor plugins would be less effective and capable of inflicting any sort of attack on your development OS, but surely the development environment is the perfect vector for attacking the runtime environments that run your artifacts get deployed into? Not to mention the potential for secrets-harvesti…
Some advanced linters might want network access but you can show this to the user, so they can make an informed decision about whether to trust that linter and their author with this power.
This isn't airtight security to protect against obviously-malicious authors. This is about creating a system that can deal with the reality that "trust" in an app store entails "a million shades of gray". I might trust a plugin enough to check for errors in my code, but not enough to actually modify my code.
Earlier quoted context omitted.
Why did you opt for WASI for plugins instead of native compiled code?
Webassembly makes a lot of sense for plugins. * sandboxing, so plugins don't need to be as trusted * Easy cross-platform distribution with a single build artifact * plenty fast (if written in a language like Rust/C++ and paired with a good runtime)
WASM + WASI means a single binary has near-native performance, but can run on any CPU architecture and any OS.
Earlier quoted context omitted.
yep, it crashes on Archlinux as well Just wonder, what is the point of promoting something as "being written in Rust", if at the end it crushed the same way as "being written in C/C++/whatever".
To attract contributors who want to learn more rust by collaborating on something they care about.