-
Notifications
You must be signed in to change notification settings - Fork 73
universal Linux executable #83
Comments
@ivocavalcante wrote the following on the Curv mailing list (synopsis). Hi all, I'm working on a Snap package for Curv. I just have the name "Curv" reserved on Snapcraft store (which I'll gladly hand, if you decide to manage Snapcraft) and uploaded first release. It can be installed using "sudo snap install curv". Curv is now live on Snap store: https://snapcraft.io/curv |
I (@doug-moen) am having problems with the Snappy package. First problem: it is built with "strict confinement", which means that Curv cannot open files outside of my home directory. This is a problem for me, since I keep all of my Curv source on a ZFS volume outside of my home directory. The error message doesn't tell me what was going wrong, and Ivo had to explain the home directory restriction to me. That's a support problem.
This could be fixed by disabling strict confinement. Second problem, Curv cannot use OpenGL for rendering.
Ivo asked for
This shows that Curv has an OpenGL slot, so OpenGL should work. Ivo asked for
Note that the snap version of Curv is reporting OpenGL 1.4. For rendering, Curv 0.4 attempts to create an OpenGL context with a version 3.3 core profile, and it is this specific configuration that is failing on my system. |
Why can't Curv use OpenGL on my system? I looked around to see if other open source OpenGL projects are running into similar issues. OpenSCAD has a snappy package, but they recommend that people do not use it, because of "known display issues". The OpenSCAD snap doesn't work on my machine -- it opens a window, but the window stays black. OpenSCAD also distributes an AppImage, and this is the format that they recommend that people use on Linux machines. The OpenSCAD AppImage works fine on my machine. |
I downloaded blender from the Snap store, and it works on my machine. So it is possible for snap packages to work on my machine. One problem. When I installed blender initially, I got this error message:
This error message is not a good user experience for Curv users. The standard Linux distribution for Blender (downloaded from blender.org) is a tar file that expands into a directory containing an executable, plus subdirectories containing plugins and other data files. The blender executable is somehow distro-independent. Most libraries are statically linked (with the exception of low level libraries, such as X11, OpenGL and libc). It's not an AppImage. Blender provides 2 Linux downloads: 64 bit, and 32 bit. There is also a snap store link lower down the page (but snap doesn't support 32 bit). The reason that Blender is normally distributed as a directory: This allows you to install multiple versions of Blender and switch between them. Blender allows you to install 3rd party plugins, and the directory distribution format allows each version of blender that you have installed to have its own plugins, which avoids version conflict. |
The main reason I didn't go for classic confinement was the message you saw. I still believe we can have Curv working on strict - it works on my machine, and the machines I tested at work, including a Quadro FX5800 -, but we would adopt the strategy of having a confined and classic tracks for Curv; user selects whatever he finds best. We could look into other formats too; I'm more favorable to Flatpak instead of AppImage. Will give it a try, once done with Snap. |
Snappy won't work for all users. Here are the problems I see:
AppImage doesn't have these drawbacks. I use AppImage packages and haven't had a problem with them. AppImage packages are just files, so they are really easy to deal with. If you want to have several versions of Curv installed, it's trivial with AppImage. AppImage supports optional sandboxing, and in-place updating is available if you use AppImageUpdate, so it has feature parity with Snappy and FlatPak. I am not a fan of Canonical being a middleman between the Curv project and its users. I'd prefer users to download Curv executables directly from a Curv controlled web site. The Blender strategy also seems attractive, because it doesn't introduce any new dependencies (on Snappy, AppImage or FlatPak). Just statically link as many dependencies as you can. It's a bunch of work to statically link all my remaining dependencies, but I'm going to have to do a lot of that work anyway to build a WebAssembly module (needed for Sebastien's visual programming environment). So I am considering this as a future option. I know little about FlatPak, so I don't have an opinion about it right now. |
I can see that. :-) Well, I understand your point. Thing is, I prefer having some sort of system managing the packages I have on my machine than having a bunch of AppImage files stored; that's a matter of taste, so no point in debating. AppImage is really convenient (I use some myself, notably PrusaSlicer), but I have my share of problems with it (maybe due to some misuse of mine). Anyway, it's perfectly understandable your prefence in using it. Since I was already working with Snap, I prefer to finish the job - either have a fully working version or abandon it, after trying all options. Hope you haven't a problem with it - since the package is under my credentials, it won't be seen as an official release, I expect. Anyway, when I finish, I can take a look at AppImage, if you already haven't. |
Meanwhile, could you please test a new version I uploaded to beta channel? I hope it works in your computer.
or, if it's already installed,
|
The new version you uploaded to beta channel has the same problem as before: OpenGL doesn't work. Since blender works, why not look at how blender does their snap build. It might provide clues why their snap works on my machine: |
Here's the contents of /snap/blender/33/meta/snap.yaml on my system:
Why not try giving me a version of curv with classic confinement, and see if that fixes the problem? |
I'm looking for more snaps that both use OpenGL, and work correctly. No luck so far. My theory is that snappy's model of how to perform OpenGL confinement is buggy, and doesn't work for all configurations. I tried I tried |
Using classic confinement isn't straightforward; the snap must go through a vetting process, to ensure (from what I read):
That being said, I can provide you a binary package with classic confinement - or you could build it yourself, the recipe is here, on snap dir (master branch): https://github.com/ivocavalcante/curv I agree that OpenGL interface is broken, should be easier to use. |
I've updated the store page, stating that the package isn't related to the project and there are know issues with some NVIDIA setup. |
All of my previous testing was using Intel integrated graphics. I just switched to my nVidia GTX 1050, and now it works. Maybe it's a problem specific to the Intel driver. Or maybe it's a problem with system configurations where there are multiple GPUs available. Maybe the snap opengl implementation makes a mistake in detecting which GPU is active, for example. |
Probably. Snap team seems to be drafting better GPU support (including CUDA, Vulkan, etc.), but for now, that's what we have. I intend to keep package on store, since it works for me (and others, prob.). Do you have a problem with it? |
I understand the attraction of making Curv available in a popular Linux app store: ease of installation, automatic updates, centralized management of your installed apps. My main issue with the snappy package is that it is broken on my system in multiple ways. It's probably broken on other people's systems, the bugs can't be fixed, and I don't want to have to support it. The conflict between Curv and snappy's confinement system might get worse in the future. I'll be switching to Vulkan at some point to support faster and fancier rendering. A package manager will need network access and a place to cache packages. The forthcoming visual programming system might need plugins. If the goal is to put Curv onto a popular app store, then flatpak and flathub look like a better solution. From what I've read about FlatPak so far, the sandboxing creates problems (like Snap), but it's easier for developers to disable, and most flatpaks are shipped with sandboxing disabled. So, a Curv flatpak should work correctly. (Note, I haven't tried flatpak yet.) If you want to keep the snap store version of Curv around, I want it made clear that the graphics are broken on some systems, and it isn't officially supported. If you find yourself unable to update the snappy package in the future, due to personal circumstances, or due to changes to Curv that break the snappy package on all systems, I would appreciate it if you could remove the package at that time. Or notify me by email if that isn't possible. |
Hi, I am actually interested in trying curv, but a bit intimidated by the build process and does not want to "soil" my nice pristine server with all the required packages without knowing it will work for me. |
Well, you can try the Snap package, for a start. It's available here: There are some limitations, inherent to the technology, but you might get an ideia. |
You can try the Snap store version of Curv created by Ivo. There are a couple of reasons why you might not want this. You might not want to install Snap on your system for social reasons (some Linux distros, like Mint, are advising people to avoid Snap). Or the Curv snap package might not run properly (it doesn't work properly on my system). But if you are running Ubuntu anyway, then it is easy to try the snap package. I think the best alternatives to Snap are Flatpak and Appimage. Unlike Snap, Curv packaged with these technologies could be made to run without technical limitations on any modern Linux system. Nobody has packaged Curv using either of these technologies, but I would consider adding support. Nobody has reported making a docker image, and docker is not a general solution that would work for everybody. The problem with docker, AFAIK, is that Curv requires GPU-accelerated rendering (otherwise the rendering is noticeably slower), and accessing the GPU from docker is difficult. AFAIK it is only possible if you have an nvidia GPU, and then you need a special docker driver from nvidia. Here is a github project for packaging Blender in a docker package (the challenges are similar to packaging Curv): https://github.com/jtomori/docker_blender_gpu |
Working with gpu in docker is actually easier than outside of docker... i
am dealing a lot with deep learning and docker is by far the most heavily
used technology to overcome all the cuda drivers incompatibilities.
I'll give it a try and see.
…On Fri, Jul 31, 2020, 01:04 Doug Moen ***@***.***> wrote:
You can try the Snap store version of Curv created by Ivo.
There are a couple of reasons why you might not want this. You might not
want to install Snap on your system for social reasons (some Linux distros,
like Mint, are advising people to avoid Snap). Or the Curv snap package
might not run properly (it doesn't work properly on my system). But if you
are running Ubuntu anyway, then it is easy to try the snap package.
I think the best alternatives to Snap are Flatpak and Appimage. Unlike
Snap, Curv packaged with these technologies could be made to run without
technical limitations on any modern Linux system. Nobody has packaged Curv
using either of these technologies, but I would consider adding support.
Nobody has reported making a docker image, and docker is not a general
solution that would work for everybody. The problem with docker, AFAIK, is
that Curv requires GPU-accelerated rendering (otherwise the rendering is
noticeably slower), and accessing the GPU from docker is difficult. AFAIK
it is only possible if you have an nvidia GPU, and then you need a special
docker driver from nvidia. Here is a github project for packaging Blender
in a docker package (the challenges are similar to packaging Curv):
https://github.com/jtomori/docker_blender_gpu
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC7IWCYI3HJUB6CZHPO7EZTR6FVVPANCNFSM4IMSYS3Q>
.
|
Thanks for the tip about using CUDA inside of docker. I may need to use that at some point. |
My docker works nicely, just having problems with display but it works
without it... Working on it...
…On Sat, Aug 1, 2020, 10:17 Doug Moen ***@***.***> wrote:
Thanks for the tip about using CUDA inside of docker. I may need to use
that at some point.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC7IWCZVTOZSEUMV2HQTDMTR6M7HXANCNFSM4IMSYS3Q>
.
|
this is the docker file. I am running it on a remote headless server so it was a bit of a pain to get X to work but for everyone else it shouldn't be bad following https://medium.com/@l10nn/running-x11-applications-with-docker-75133178d090 or similar advice. I couldn't check it as I have no display connected to this host
to build: good luck! |
+1 for AppImage for universal package. What's really important, user don't need to install anything on the system to use it. Most distributions do not ship with snap or flatpak managers/runtimes. I don't have any need to install them on my Arch Linux system. |
I agree that AppImage is the best choice for some users. I personally prefer AppImage for some of the software I use. Also, there can be more than one distribution method! Not everyone has the same requirements. If someone wants to create a github actions script to build an AppImage for Curv, I would accept that as a contribution. |
I just made an AppImage build script for curv and integrated it to github actions. I tested the build script locally (Linux Mint 20.2) as well as in github actions and was able to produce a working AppImage. Here is the latest build artifacts from github actions. The AppImage doesn't contain all the standard metadata requirements yet - it is made to 'just work' for now but maybe it can already be a useful start. @doug-moen , will you accept a PR? |
@A-G-D Thanks! Please submit a PR. |
Thanks to @A-G-D we now have a Curv AppImage build in github actions. Due to the nature of AppImage, this will only run on "sufficiently recent" versions of "major" distros. It may not work on niche distros or on older versions of popular distros. It doesn't work on Ubuntu 18.04, for example. The workaround is to upgrade your distro or compile your own binary. Right now, the most universal app distribution format is Flatpak. Flatpak apps run on a wider range of Linux systems than AppImages because Flatpak has its own runtime, and doesn't rely on the base system having a sufficiently recent glibc etc. And Flatpak is supported by a wider range of distros than Snap (28 for Flatpak, vs 22 for Snap). |
@doug-moen , while I have a lot of respect for the work you've done with Curv - I was looking for something with better performance than OpenSCAD, and Curv has that and much more - I really can't avoid myself from coming here and saying that your statements about Snaps are not true. Nonetheless, I have absolutely no intention or desire for starting a package format debate. I've always felt uncomfortable in maintaining my Curv package given your opinions against Snap. This statement just reinforced this feeling, therefore I'll unlist the package from the store. Hope you can find time to create a Flatpak version yourself, or somebody jumps in and fill the gap. |
Whoops, sorry @ivocavalcante, I should not have posted something inflammatory to the discussion. I edited the comment to make it more factual. And yes, it's true that I have allowed my antipathy towards Snap to colour my decisions in running the Curv project. Probably not the best idea, since I don't really want to insult and alienate people. Although I don't use Snap myself, I don't really want to prevent other people from using it. You don't need to unlist Curv from the Snap store on my behalf. For what it's worth, I will accept Snap-related PRs. The caveat is that I won't be testing these changes manually, due to my local setup, although it might possible to test using github actions. |
Can we close the issue? |
The Curv project should provide pre-built Linux executables, so that users don't need to build their own executables.
The 3 main alternatives for distribution-independent, universal Linux executables are AppImage, FlatPak, and Snappy.
@ivocavalcante has started experimenting with Snappy builds.
The text was updated successfully, but these errors were encountered: