Fair enough, at least it's still a move in the right direction. Can you please look at my comments on T837 while you're around?

@DataDrake Can you take a look at what I said above since you're around?

So I spoke to @DataDrake about this in IRC awhile back, and he said the reason you hadn't included CUDA was due to licensing issues and you were looking into CUDa docker. However, I'm reading the license and I can't find any issue with redistributing it. Programs built to use CUDA (say adobe after effects) actually are forced to include it in the package they distribute.

So the whole CUDA ecosystem is a kind of a complex shit show. You have a CUDA version (i.e. 9.1) and subversion (i.e. 9.1.2) with fixes. Each version requires a specific range of drivers, and hardware (though any modern hardware/ hardware something like solus wants to support is fine). Each program requires specific version or range of versions of CUDA, which are almost never the most current version. Most interesting things require cuDNN as AI is baked into literally everything now, and the biggest users of GPU acceleration are ML people (like myself). cuDNN has versions and subversions as well, with builds of each for the most current different versions of CUDA. Support for the newest version of cuDNN happens sometimes in mainstream software. As much as a shit show this is, for technical reasons it's justified. The only thing they could do to make things a little better is start including cuDNN by default with CUDA like they do with cuBLAS etc.

When CUDA is added please keep in mind there needs to be an easy way of handling the different versions of CUDA, and that you don't just include the most recent one. Deep learning libraries and many creative applications use very varying revisions of CUDA. Also please include cuDNN at some point.

As I said earlier and have messaged DataDrake about, the actual source is fully publicly available, and not in a tarball form. The person who submitted the original post for JDownloader2 linked to the wrong location. It's entirely hosted via SVN, and fully complies with all relevant packaging requirements for the distro.

DataDrake, can you reconsider given this it servers an important purpose without competition and the source is available? Also we should be building from the SVN they use, not the github repo

If you look here you can see the SVN, they're finished going fully source:

Redone to have a better and more comprehensive explanation of bugs:

@ikey Any thoughts? From what I gather following this project this falls into your domain and it seems important to the project given that from the best data I can find ~40% of all new laptops in the US have a touchscreen.

As an update, when UI scaling is enabled (2x) on a 4k screen, the touch keyboard randomly is too small and to the bottom left corner or behaves normally (at least in the gnome verison)

Should this be closed? I don't experience the issue

Also note that this isn't a duplicate of pip, and that pip isn't a duplicate of it. Pips offers better software support, conda provides ease of use and native virtualization. There's no clear winner for the general case, but there are major winners for specific cases, hence justifying the inclusion (and industry usage) of both.

Is there any new progress here, and has supporting cuDNN already been added to the road map, or do I need to submit a separate request?