moosingin3space

Apparently Numba can (kind of) do this. It JITs Python/Numpy/Scipy code through the LLVM-based toolchain for CUDA.

[1] http://numba.pydata.org/numba-doc/latest/cuda/kernels.html [2] http://numba.pydata.org/numba-doc/latest/cuda/reduction.html...

This seems to be a common practice in documenting exploits -- to purposefully leave out details that would make it able to cause actual damage in the wild.

A while ago, when this project had just started, I filed an issue to discuss the windowing/GUI system: https://github.com/Wilfred/remacs/issues/25

Xi isn't vi-like, although it is on their roadmap.

Rocket uses compiler plugins to do its magic, and compiler plugins aren't stable.

Especially nice is the Rustler tooling for building a NIF.

Is this the generalization of the Pathfinder text renderer?

It would be awesome if Reason/OCaml had a backend for the Erlang BEAM VM -- could make things like Nuxt.js in OCaml possible. Full-stack type safety benefits would be awesome!

This is one of the best comments I've ever read on this matter. Please link that blog post when you write it!

I always had a difficult time understanding applicatives. Do you know of any good resources for understanding them?

I used to like embedded DSLs a lot too, but then I realized they (mostly) were just the builder pattern + a lot of "extra" syntax (never written anything large enough in a Lisp or Haskell). The builder pattern feels more readable and has fewer context switches when writing code.

I'd argue most languages are agnostic about (im)mutability. It's libraries that aren't.

That blog post suggests that credit cards are in scope:

> Before release:

> * Support for credit cards

I really like Mozilla's work, however, it is difficult for me to recommend Firefox as long as it has a poor sandbox relative to Chrome. This is disappointing, especially as Firefox becomes better, but a casual user needs to be protected from malicious websites as much as possible. Until this situation changes, in good conscience I can only recommend Chrome with uBlock Origin and Privacy Badger.

It is my hope that adoption of Rust helps improve this, although more integration with OS sandboxing features would also be excellent in making the case for Firefox.

Seems to have been resolved -- this status page shows it up (as of 10:30 Eastern).

This is why I personally like the Vue/React way of scoped CSS -- it promotes loading a simple baseline CSS (like Skeleton) for the full page and specializing in the individual component layer. It's easy to refactor in the case of changing requirements (if the same across components, move style into global CSS, if not, move into component).

I did say "there's no hard proof". This was purely an analysis of incentives.

Moxie Marlinspike's reputation is dependent on his ability to deliver a secure product. Signal/Signal Protocol development is funded by donations and grants from groups like the Freedom of the Press Foundation, EFF, etc, and those groups desire a secure messaging product. Moxie has staked his reputation on WhatsApp's implementation of the Signal Protocol multiple times on the OWS blog, which he would not do if he disapproved of WhatsApp's implementation. There's no hard proof (except what can be gained through analysis of the executables), but there's no incentive for Moxie to lie, therefore, WhatsApp's implementation should be reasonably secure.

Why is that important? Especially considering Tails has worked fine using systemd in their previous version based on Jessie. Additionally, Tails has used systemd's service namespacing functionality as part of a defense-in-depth strategy. Switching to Devuan makes little to no sense based on this track record.

I'm curious -- if this is basically a scheduler for tabs onto system processes (which it seems to be), what's the impact on input latency? I've read in multiple places that Chrome's input latency is worse than it could be because of multiprocess, so I'm really interested to see some input latency benchmarks.

Additionally, how are tabs sharing the same process isolated from one another? Chrome uses Linux namespaces for each of its processes, and this keeps tabs separated by a sandbox that requires a kernel exploit to break out of, how does Firefox's sandboxing work within a process?

Maybe this?

    yes | pv > /dev/null

Yeah, the remarkable thing about this (for me) is that this particular case isn't actually a language soundness flaw, demonstrating that the general approach Rust takes is a useful one. The author puts it nicely on the /r/rust thread [1].

[1]: https://www.reddit.com/r/rust/comments/6gavfe/how_mutexguard...

This is an interesting concept for storing keys. I may end up using something similar in a proof-of-concept I've been thinking about.

This is a good point, and part of the problem with the way the average computer user (and far too many above-average users) treat their passwords.

I believe Google is playing long-term here -- if they make it really easy for someone to do ML research using their frameworks, they'll collect rent from the researcher and possibly get something more innovative out of their work later.

Not everything they do is about short-term data plays.

The C Abstract Machine looks like a generic machine based on the Von Neumann architecture, so it "feels" like it should be fundamental. Add in some sunk-cost fallacy, and a lot of people end up with the belief that C is fundamental to computing, despite the existence of systems that do not use any C.

Yes, but there is a research project here that replaces LLVM for codegen: https://github.com/stoklund/cretonne

Counterexample: Rust compiler is written in Rust.

Is LinuxKit's core system based on Alpine?

Shared-memory threads are something I hope lands in WASM, since they're part of the reason you'd want to drop down to WASM in an application in the first place.