yoklov

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)

This... Loses that.

No real reason to call nintendo out here, every console i know of has been that way for many generations.

What are your recommendations for japanese, out of curiosity

It is something I miss a great deal when on other OSes

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?

a single existing implementation is a problem, not a feature for the web platform

Can you not disable wasm? That seems like an oversight that should be fixed if so.

GURPS is way to crunchy (numbers focused) for me, personally, but I'm seconding the Sprawl recommendation.

Hack The Planet is another great modern cyberpunk RPG, based on the Forged in the Dark rule set.

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.

For anyone else who was a little confused, this seems to be entirely unrelated to https://en.m.wikipedia.org/wiki/Unum_(number_format)

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.

disclosure: I work at mozilla, but not on this.

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.

Glad you're satisfied other than that!

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.

They use it for some Azure things, IIRC.

I think this is mainly an issue on macOS if you use a vertical sidebar, having to do with supporting it's translucency.

I think there's away to turn this off too, but I don't remember how, sorry.

Sure, but you can't really avoid rerendering every frame with OpenGL.

(Not without a lot of tricky caching, at least, which has it's own costs).

Not saying this is impractical (Personally, I wouldn't bet on it, but I'm sure it's fine for some things), so much as that the cost model here is fundamentally different.

http://cbloomrants.blogspot.com/2018/06/zstd-is-faster-than-... is versus zstd 1.3.3. There are others too on that blog.

Oodle and zstd are both very impressive, it's a shame the former is not free.

There are precision issues with -1...1. 0...1 is actually the right choice IMO.

This is exactly what I meant to convey, thanks.

Yep, this. Python is a headache for this sort of thing IME. (Nothing against the language though, although I don't know it)

You can still write hacky temp code in Rust, although it does take some experience to get familiar with the ways you can do this without hitting borrow checker errors and etc (well, short of reaching for unsafe, which is generally not a good way to do this).

That said, for getting code written fast, Rust for me has been better than C++ for a while now, even though for most of that I was better at C++ than Rust. The reason for this was largely Cargo, which eliminates the pain points of dependency and build management that plague C++.

IIUC, for typical programs, most of Rust compilation time is spent waiting for LLVM to spit out results.

There's a plan to use https://github.com/CraneStation/cranelift for debug builds instead of LLVM, which would make them faster at the cost of supporting fewer targets, and producing worse code.

Often when people [0] discuss the difficulty of writing linked lists in Rust compared to C++, they mean intrusive linked lists.

These are still very difficult in Rust. I've heard pinning being stabilized makes them possible safely, but I haven't looked further.

[0]: At least, when I was starting Rust, this is what I would mean when I complained about linked lists.

https://github.com/cbreeden/fxhash is reasonably widely used. It doesn't have the security benefits of SipHash, however they are rather dubious in practice -- 64 bits of state is simply not enough to be secure, no matter the hash function (not to mention, real tables will not use the vast majority of those bits).