scaled_dot_product_attention isn’t CUDA specific, it even works on TPUs.

I’ve been using this for visualizing some computer vision data/model prediction and it has been great.

The remote client/server streaming has a bit to go, but just the option to use it in a browser is a game-changer. All the previous web-based tools that I’ve come across have been either very limited, or require significant manual setup.

Super glad to hear that!

What are some things you're missing on the client/server streaming? I'm aware that there is much to do but would love to hear your specific issues

Honestly most of the things I would like food are very oriented toward research/sharing use-cases, which I realize that is distinct from a lot of your users, but can mean:

- Working with large remote datasets/clusters - Needing to share visualizations with others [both interactive, and pre-recorded/controlled] - Being able to easy switch between N runs to look at data/results over time

Concretely:

- Currently it seems you need to forward multiple ports, and for each new session you need to re-connect. My memory is foggy but I found it was a lot of hassle to just connect a thin-desktop client to a remote backend.

- The support for baked-html is great, but it has limits (namely I was hitting some size limitations) and it would be cool to have a server that can read rr files from disk and stream them on-demand [e.g., point to a directory and let the user select]

- Generally speaking, I found the workflow difficult to integrate to the typical ML setup. Obviously not a priority for rerun but I think a little improvement [like the point above] could help a lot.

- A built-in screen recording feature would be great. I spent a lot of time screen recording and re-sharing clips.

Again, these are mainly nitpicks, love the tool overall and have recommended it to several people.

Thanks a lot I really appreciate you writing this out! I'd say most of your requests are things we'd like to address in the future. Built in screen recording is a common request and something I think makes sense for the open source project. A lot of the other requests require a central service of some kind to achieve high performance and/or a smooth user experience so those fall into the bucket of what will go into our commercial offering.

Down for me as well. Thought my SSH agent was broken.

Does this have faster startup times than cpython?

Every time I want to rewrite a shell function in python, I always hesitate due to the slow startup.

How fast does it really need to be? On my M2 macbook air:

    $ time A=1 B=1 python -c "import os; print(int(os.getenv('A'))+int(os.getenv('B')))"
    2

    real 0m0.068s
    user 0m0.029s
    sys 0m0.026s

Eh. Once you start using imports, python slows down dramatically.

So I guess it really just depends what your scripts use.

Regarding import cost, as it’s doing heavy IO traversing the file system, the cost heavily depends on how fast you can do IO in the hardware, and also the file system (and the OS).

So a fast SSD will help, and somewhat surprisingly putting it inside docker helps (in an HPC context, not so sure it’s implications here as we’re talking about a short scripts.)

But the context here is to port shell scripts to Python, I’m not sure how huge amounts of imports matters.

And it is probably an intrinsic problem of the language, unless we start talking about compiling (and somehow statically) not interpreting the Python program, whichever implementation of the language probably won’t help the situation.

Lastly, if high startup costs of the script becomes relevant, perhaps it is orchestrating wrong. This is an infamous problem of Julia, and their practice is then just keep the Julia instance alive and use it as “the shell”. Similarly, you can do so in Python. Ie rather than calling a script from the shell acting on millions of things, write a wrapper script that start the Python instance once. Memory leak could be a problem if it or its dependencies are not well written but even in that case you have ways to deal with that.

>But the context here is to port shell scripts to Python, I’m not sure how huge amounts of imports matters.

Never question the modern developers ability to import 1500 heavy libraries to accomplish something that only takes 10 lines of code.

I curious why you would think so, since CPython is already written in C

Well CPython has a lot of backwards compatibility to deal with that RustPython doesn't, so "import subprocess" might result in very different behavior.

Haven’t read the paper (or looked at the code), but not sure there’s a general obligation to cite anything that’s not a pre-print/published. If they knew of and used the code, that would be a different story, but otherwise it seems okay, if understandably frustrating for the person that wrote the code.

This is especially the case for something like this where it’s a relatively obvious idea and the evaluation matters more.

I'm not sure if there is obligation to cite anything. It's a question of ethics.

A claim of proposing a novel method should be corrected in a scientific publication if shown false. Otherwise the author is knowingly adding falsehoods into the body of scientific knowledge, and their institution is allowing it.

Adobe can either (A) charge the full year up front, or (B) specify the full year cost and give customers the option to pay that monthly (like the buy now, pay later plans).

The issue is that their current wording is deceptive.

"Annual billed monthly" is deceptive? I just disagree I guess.

I thought it was pretty well used pre-covid, especially when the rides were sometimes 50% of a regular ride.

At least I personally used it a lot, and knew several people that did.

The implementation seems to be pretty clean and modular here where transformers (and diffusers) isn’t, unless you take their modules standalone.

This repo has a lot of handy utilities but also a bunch of clean implementations of common models, metrics, etc.

In other words, this is more for writing new models rather than inference.

As someone who works on both, this is just not the case. If you're talking about general automotive R&D, sure.

If you're talking about the total employee makeup of a current self-driving company, the number might be ~10-50%, depending on the company.

But if you take the subset of employees that work on software, this number is much much larger. There's lots of typical SW dev needed for GenAI (think data pipelines) but a good chunk of ML-folks doing self-driving work can be useful on GenAI as well.

I think you misunderstood the NLRB article entirely. The change is that in cases of election violations, the default remedy is now forced bargaining. There don’t appear to be any open elections, only the increased possibility that a union is formed by default.