eslaught

But my understanding is that the large publishers mostly do this themselves (and therefore have to pay the voice actor out of the 40% cut they get). Similarly, independent authors won't get access to this level of service; in some cases they're literally reading the book themselves, but they still only get the 40% cut (and that's with exclusivity).

The reason why audiobooks are cheaper is due to the subscription model. That's the chief innovation that Amazon pioneered with Audible. Now, their clout certainly also had something to do with it, and the burgeoning Kindle ecosystem. But the issue of price is really a matter of subscriptions being stickier and keeping customers in the ecosystem longer, making it possible to make aggregate more money. It's the same business model as Netflix, Dropbox, Adobe CC, etc.

[1]: https://www.audible.com/ep/audible-originals

My understanding is that is not how this works. The author pays the voice actor, or the publisher does. Amazon is paying for hosting an audio file, basically, and the development of the player app, and that's it.

I think in the very early days, Amazon may have paid all the voice actors itself (because no one was on board with audio yet at that point), and the 40% royalty model may have made sense. But I believe that is not how it works now, and 40% royalties make a lot less sense in the world we now live in; it seems to be just purely predatory.

We eventually rewrote the profiler tool in Rust for additional speedups, but as mentioned for the verification engine, it's probably too complicated to ever do that so we really appreciate drop-in tools like PyPy that can speed up our code.

[1]: https://github.com/StanfordLegion/legion/blob/master/tools/l...

[2]: https://github.com/StanfordLegion/legion/blob/master/tools/l...

Sounds like a cool sci-fi premise.

https://en.wikipedia.org/wiki/American_Civil_War

https://theory.stanford.edu/~aiken/publications/papers/asplo...

An eclectic combination of a long-running (but infrequent) blog, technical projects, and academic papers.

There's a prayer about knowing the difference between what you can do and what you can't, and setting aside the things you can't do to focus on what you can. To me, this seems like the right way to approach this.

He actually implemented these ideas: https://djot.net/

The cores were in order. If you've never written code for in order cores, you may not appreciate exactly how heavily you're leaning on out of order to save your bacon. Things your used to just working suddenly don't.

The cores had a 2D layout, but Intel refused to tell you what it was and in practice it was impossible to optimize for. You ended up with variable (as in different on every node) latency for memory access that made programming again painful (and add this to the fact the cores are in order, so you really can't work around the latency).

Then there was the software stack that was just odd in some ways. I was researching I/O throughout, and things that just work on any other CPU (on any modern ISA) just didn't behave in a sane way.

So yeah, I was not at all sad when Intel cancelled it.

https://api.github.com/users/<userhandle>

From:

https://github.com/NixOS/nixpkgs/blob/master/maintainers/mai...

I wonder if anyone here has more experience to know how well it has worked?

One massive advantage of Rust is that they started with borrow checking from the beginning. I think one thing that often gets understated in these discussions is how much it matters to have your entire ecosystem using a set of safe abstractions. This is a major drag for C++, and I suspect that even if the language went a route like D they'd still have gaping safety holes in practical, everyday usage.

https://developer.apple.com/documentation/virtualization/run...

For example, I recently went looking into Numba for AMD GPUs. The answer was basically, "it doesn't exist". There was a version, it got deprecated (and removed), and the replacement never took off. AMD doesn't appear to be investing in it (as far as anyone can tell from an outsider's perspective). So now I've got a code that won't work on AMD GPUs, even though in principle the abstractions are perfectly suited to this sort of cross-GPU-vendor portability.

NVIDIA is years ahead not just in CUDA, but in terms of all the other libraries built on top. Unless I'm building directly on the lowest levels of abstraction (CUDA/HIP/Kokkos/etc. and BLAS, basically), chances are the things I want will exist for NVIDIA but not for the others. Without a significant and sustained ecosystem push, that's just not going to change quickly.

Sometimes you won't have a choice and you just have to put up with it. But my advice, in so far as possible, is to surround yourself with people who understand this nuance and for whom it is a goal to be compassionate (while still being honest and truthful about problems that exist).

I just wanted to mention it because some of the advice in this thread doesn't seem to make this explicit. Improving yourself is great, but life is too short to put up with jerks.

Andor comes with the distinct advantage that you don't have to slog through hours of questionable content to get to the good stuff.

Sometimes when the follow-on content is bad... it's because the follow-on content is bad.

Weld: A Common Runtime for High Performance Data Analytics

https://dspace.mit.edu/bitstream/handle/1721.1/137425/cidr_w...

As best I can tell, it doesn't protect from MITM attacks. If so, I'm confused about what the point is.

I haven't run the numbers but I have the impression that "idea people" tend to flounder without a strong technical co-founder. In contrast, technical co-founders can make it on their own, though there may certainly be challenges in doing so. Those roles are also very different in terms of what you can hire in as early employees vs what absolutely has to be a part of the founding team.

Almost everything in a big organization is a team effort, but that doesn't mean you can't tease out the relative contributions of the different parts. And I think you're undervaluing the engineering contribution substantially.

Re: the sibling comment, I had to switch the Chrome to see the button, but I don't know how patient I need to be, or what the interface is supposed to look like once it's ready.

Edit: ok, took a couple of minutes. That is way more awesome than the initial demo. The map even includes the ready room and conference room of the Enterprise D.

Maybe I'm an uncultured barbarian, but... the difference is not nearly as large as the comments here seem to suggest. I can taste the difference, but I have to think about it. And the difference honestly seems small enough that I'm not sure I'd successfully distinguish them in a blind test.

Am I missing something?

I didn't test Canvas specifically in my explorations, but I did test a few JavaScript based frameworks, and the ones I found that were efficient sat on top of WebGL, not Canvas. Ultimately I didn't pick those because they had a bunch of other stuff baked in that I didn't need or want, and were already equally non-native (sitting on top of WebGL). And I frankly didn't want to be writing JavaScript.

Going to 3d rendering via OpenGL / WebGL was one of the options I considered. But honestly, this is a boatload of complexity. Why do I need to pick up a full 3D rendering library just to draw rectangles on the screen? Plus, consider: the slot viewer (where the rectangles are shown) still needs to draw some UI components (e.g., on hoverover). I still need that UI integration there, even if it's not as performance-sensitive. So I end up needing something along the lines of egui anyway.

I definitely understand that not all UI libraries are going to be optimized for this. But I was surprised that it wasn't easy to e.g. get a high-performance canvas dropped into libraries that specifically advertised themselves as high-performance.