I'm not sure using pytorch counts as "from scratch" anymore. I'm not saying you should avoid the stdlib or anything crazy, but at the point where you're pulling in for-purpose libraries it really doesn't seem like "from scratch" to me.
Oh, so, I recently had opportunity to play around with this some, a bit over the past week. My initial questions were along the lines of:
1. What's the point? In end-to-end encryption situations usually the concern is around data storage (perhaps), but for just sending messages typically TLS is enough (or seems it, anyway, from my perspective as a non-security engineer)
2. The codebase seems to have separate C, Rust, and Elixir versions. Are they interchangeable, or do they serve different purposes?
Of these I only have rough answers. For the first, it seems like this solves the problem where, say, a single TLS connection isn't enough to get the data all the way to where it's needed (perhaps you need to go over bluetooth, or do multiple steps of HTTP, etc).
And for the second, well, I'm not sure. I think the C implementation might be equivalent, and be being replaced by the Rust one?
Yeah, a big benefit of SQLite is the fact that it's embeddable, and easily can be communicated with from any language that can FFI out to C (which is to say, essentially any language)
Sounds like much more work than implementing a wasm vm+runtime. Besides, isn’t it owned by a company who is notoriously litigious against reimplementations?
I think it’s just pref/user_pref and such. Despite the name it is not a js file and is not parsed like one. I think the file extension is entirely vestigial.
Neither really. It doesn’t have direct access to a canvas API or to the DOM, but you can proxy calls through javascript. There’s a plan to allow avoiding this overhead, but it’s fairly early.
I think there’s a certain degree to which needing to implement spectre mitigations (e.g. site isolation) threw a wrench into some of the plans for improving the baseline of the extension apis.
I think it’s not 500 deletes, but it’s certainly not great. There is definitely an index. If you can repro this, you should file a bug for it, I’ve noticed it being slow too, but couldn’t repro it recently. If you file a bug for this, you can CC me (tcsc at mozilla dot com).
It depends on what I'm doing, but generally yes I'll write it in Rust unless I think it's a bad fit (e.g. if it's something that's better off as a shell script or whatever I'll just use that instead).
Being a global persisted key value store, about:config has a lot of things stored in it that.... do not necessarily make sense syncing, hence it being opt-in. Sync is guilty of this too, and will store things like your last sync time in about config, for example. Clearly not meaningful to sync directly.
A checkbox like you describe was actually discussed in the past, but at this point it’s unlikely. The current design of letting any synced machine change any pref on any remote machine (effectively) has dubious security implications, and has gained an additional hoop you must jump through in nightly.
Hmm, I don't think many have requested we sync user{Chrome,Content}.css. It's possible we'd accept a patch to sync them (I'd be for it, at least), but it's not trivial since we don't already have file syncing code.
Syncing them with dropbox and symlinking does sound to me to be the most reasonable.
The storage is more limited for synced extension data than for unsynced data.
IMO this is quite unfortunate, and is mostly a consequence of the implementation of extension storage sync being done separately from the rest of sync (which in retrospect was a mistake, but at the time that wasn't clear). Also, the limits are copy-pasted directly from the limits chrome places on sync, so it's possible there are compatibility concerns as well.
For config (assuming you mean prefs in about:config), you can add your own prefs to be synced with about:config. If you add a new boolean pref with a value of true using the pattern `services.sync.prefs.sync.<pref you want to sync here>` it will be synced. e.g. to sync `browser.foo.bar` you'd create `services.sync.prefs.sync.browser.foo.bar`.
Disclaimer: I work on Firefox sync.
[0]: In the future this may be more complex, and you may need to flip an additional pref to get this behavior for non-default prefs.