Getting start with ublue: looking for recomended way to install non-flatpak software

Hi everybody!

I am considering switching to ublue (probably Aurora), but I have some questions regarding how to install some types of software in a image based os. I have used mostly Kubuntu/Ubuntu in the past, but I am really a novice (although I have been using linux for ~10 years). Linux is just something I use because the updates are less annoying than in windows.

I understand most software in ublue is supposed to be installed via flatpaks. But I need some programmes that cannot (I believe) be installed in that way. Namelly:

  • I need Libreoffice with the TexMaths addon (to write math equations using Latex). This addon does not work in the flatpak or snap versions of Libreoffice. How can I install this? Via rpm-ostree or should I create a container for this?

  • I also need to install the Mathematica proprietary software. There are only .deb and .rpm versions of it. Again, how should I install this? Container?

  • I also use the pcloud cloud storage. The ploud sync app is distributed via appimage. Do these work in ublue?

  • I am not a develloper, but I do some coding and run some simulations using the Julia programming language. I also use jupyter notebooks. How should these be installed? In a container or via brew? Should I install the bluebin-dx or aurora-dx versions bacause of this, or are the “standard” images suficient?

Finally, what distro should be used for the containers (if that is the way to go)? Does running a simulation (for me that is a bunch of linear algebra) inside a container impact performance? Are some distros more efficient than others when running inside containers?

On a seperate question: do apps installed via brew live in their own seperate container? Can GUI apps be installed via brew? (I am thinking of the Jupyper Lab Desktop app which is available in brew)

I first heard about ublue in Linux After Dark and then in Tech Over Tea. The idea of having even less annoying upgrades really appealed to me!

I really appreciate any help on this topic.

best

Probably container, since it doesn’t seem to need host’s root access. Nix is also an option, if you want.

Yeah, just throw it in a container. There’s BoxBuddy to make container easier to create via GUI, but Distrobox isn’t really hard to understand.

Of course, you can still use rpm-ostree install like you would with any normal distro package manager. It’s not recommended, but you can do it if you want. Though, if you install a lot of stuff, then consider putting them on your own GitHub repo image builder. The recipe’s in yaml, so it’s not a hard process unless you’re doing something really extensive.

They should, but as usual with AppImage, beware of dependencies issues. Again, you can simply use a container to run it in an older Ubuntu version or something, if it doesn’t work when run directly.

Container should work fine - a while back I installed Anaconda and ran jupyter notebook just fine on a Fedora container. Still, there’s no harm in using either normal or -dx variant – you can just switch around with an rpm-ostree rebase {image-url} command.

From my experience, they all should be the same. I think Arch might start out smaller than other Distrobox images, but it’s just a few dozens of MBs of difference (and stops mattering once you got a few packages added).

The only point of consideration would be the version of packages in each containers. Just run Arch if you want AUR, and run Ubuntu LTS if you want LTS version of packages – same consideration as choosing a distro, only you can just create and destroy as many as you need or don’t need.

Oh, that said, I recall that only some distro have been verified for systemd init in the container, but that shouldn’t matter unless you want to run like a VM inside the distrobox.

Never tried out brew, but it probably follows the typical scheme of Brew on any other distro / macOS. The containerization should follow whatever container the terminal’s in.

1 Like

Brew is not installed inside a container. It’s installed in your system. In the folder /home/linuxbrew/.linuxbrew/. Ublue already have brew installed (maybe just the dx version of ublue). If is not installed you can install using:

ujust install-brew

For texmath you can install the extension here. Then you can install texlive using brew:

brew install texlive

Then you need to configure texmath to use latex from brew’s texlive. See my screenshot (in portuguese):

Basically, you need to set latex and dvipng paths:

  • /var/home/linuxbrew/.linuxbrew/bin/latex (for latex)
  • /var/home/linuxbrew/.linuxbrew/bin/dvipng (for dvipng)

You can fill other fields too. Look for the executables inside /var/home/linuxbrew/.linuxbrew/bin/.

About julia and jupyter you can install them using brew too:

brew install julia jupyterlab
2 Likes

Hi @Bruno_Amorim ,

I would say that Mathematica may be a problem, whether in a container or not. I’ve attempted this before in distrobox, and the .deb file attempts to install packages to access the kernel that just don’t work in a container.

That being said, I’d imagine the .rpm won’t work with rpm-ostree, but I no longer have my license to test, because rpm-ostree does act differently than yum or dnf, and since you don’t have either, it might run scripts that call for those binaries that don’t exist… Again, the way they work is different, so it might expect it can run a few scripts to install stuff to the OS level in real-time (without a reboot), then get confused if that stuff doesn’t exist. It may be worth a try, but I’m fearful it wouldn’t work… This is because of Mathematica’s attempts to detect system changes (Essentially DRM stuff). This doesn’t really take Atomic Fedora distros into account… :frowning:

There are alternatives, with their own learning curves though, like jupyter, julia, sympy, scipy, numpy, and a myriad of other python libraries that play together beautifully and provide a lot of the same functionality, albeit in a python environment (or ipython notebook, if you use jupyter). If you need Mathematica syntax, there is also Mathics, which is an open-source clone of Mathematica, but this may be insufficient as not everything is implemented as of yet.

Good luck, I hope you find a solution that works for you!

  • Dan
1 Like

Thank you for all the feedback!

Obrigado! In my current install of Ubuntu I tried to setup TexMaths in the flatpak version of LibreOffice (I assume flatpaks will work the same in any distro). I tried to set the paths to latex in the configurations of the TexMaths addon.

These are the same paths automatically setup by TexMaths in the .deb version of Libreoffice. However, this does not work. I get the warning “The program latex was not found, please check its path”. I assume this must be because of sandboxing of flatpaks. I tried to change the permissions of the LibreOffice flatpak using FlatSeal:

But without success. It was proposed here flathub/org.libreoffice.LibreOffice to use the --devel flag. But I also had no success with that.

So for LibreOffice+TexMaths it seems that container or rpm-ostree is the way to go.

Regarding Mathematica, I found this Wolfram Research official docker image to run Wolfram Engine (the backend of Mathematica). So It seems that Mathematica / Wolfram Engine can be run from a Docker image. Do distrobox containers work the same way as docker images?

Also notice the Wolfram Engine can now the used for free! Wolfram Engine. Its can be used within Jupyter Notebooks/Lab using a kernel also provided by Wolfram WolframLanguageForJupyter

That’s because latex isn’t installed in libreoffice flatpak. It’s installed in your system (host). To access host files inside the flatpak app go to the folder /var/run/host/. Just prepend /var/run/host to the paths. In your case you can set latex to /var/run/host/usr/bin/latex.

I looks like pcloud is a binary, I would just download it (pCloud - File Security Made Simple | pCloud), put it in ${HOME}/bin, make sure the path is set to use that dir in .bashrc or similar and use it that way; no install or appimage needed, unless I’m missing something. I haven’t used pcloud but it’s one I’ve looked at (I use Wasabi atm)

Also, if you search in Software you’ll find this app that works with pcloud: GitHub - hwittenborn/celeste: GUI file synchronization client that can sync with any cloud provider

I write a decent amount of Julia for work. If you just need something quick. Install juliaup and Jupyter from brew. On the -dx systems vscode with the Julia extension should be good to go.

I also have Jupyter server running in podman using: GitHub - jupyter/docker-stacks: Ready-to-run Docker images containing Jupyter applications

I used that container for pretty much all of my python Jupyter needs.

Thank you for all the suggestions! So I installed Aurora in a spare machine I have (an Asus T102ha, this is an old 2-in-1, with
an Intel Atom x5-Z8350 and 4GB of RAM, that was severelly underpowered even when it was brand new). Here is my experience:

Since it is an Asus machine I went with the aurora-asus-latest image. I am not sure if this was necessary or if I could have gone with the standard image. Instalation went smoothly (but I finally understood why people complain about Fedora installer, its organization is a bit weird).

What worked

Installing the pcloud Appimage

This worked with no problem. First I installed the Gear Lever App from flathub. (This is unncesessary step). Downloaded the pcloud AppImage opened with Gear Lever and pcloud was working! I image installing any other appimage is just as easy.

Installing Julia and Jupyter

This was super easy:

brew install juliaup
brew install jupyterlab

And everything worked!

Installing LibreOffice + TexMaths (Latex)

Making TexMaths + Libreoffice work was a bit trickier. I couldn’t make any of the suggestions to make TexMaths work with flatpak-LibreOffice work. So I went with a container:

  1. Using BoxBoddy I created a Fedora container.
  2. Then used dnf to install LibreOffice, TexLive and TexMaths. And it worked!
  3. Since TexLive is a heavy dependency, I also installed in the same container other programs I use that rely on TexLive. So, I installed Lyx and Xournal++ also with dnf.
  4. Then I used BoxBoddy to export Libreoffice, Lyx and Xournal++. Then I could launch all these apps as I would in other one desktop. Success!

What didn’t work

Wolfram Engine + Jupyter

As antecipated by some, Wolfram Engine was the more challenging to install. The problem was not so much the installation of Wolfram Engine per se, but of its Jupyter kernel. This is what I tried:

First try:

I tried to install Wolfram Engine in my home folder, instead of the default installation folder. My guess was that if I install it on a folder with write permissions, installing on a atomic os should not make a difference.

I followed the instructions from https://support.wolfram.com/46072, but when prompted to indicate the installation folder, instead of accepting the default I indicated a folder in /var/home. This worked!

After the installation I was prompted if I wanted to integrate wolframscript in the system. I said yes. This failed. I wondered if the installation had succeded and only the creation of some shortcuts add failed. So I manually added an alias to the .bashrc file poitint to WolframKernel executable in the folder I choose for instalation. This also worked! After that, from a command line typing wolframscript would start a Wolfram command line interface.

The I tried to install the Jupyter kernel for Wolfram Engine using Method 1 from: https://github.com/WolframResearch/WolframLanguageForJupyter. This didn’t work, even after I tried to change the first line of the script configure-jupyter.wls to point to where WolframEngine was installed.

Second try

Then I decided to install WolframEngine in a container. For this I started an Ubuntu container with BoxBuddy.

Then inside the container I installed WolframEngine following
https://support.wolfram.com/46072. This worked with no problems. (wolframscript also integrated without any problem)

Next, I tried to install the WolframEngine Jupyter Kernell. To do so I first installed jupyter inside the container. I first tried to install pip using apt. This apparently worked, but when calling pip from the container, it complained it was not available. I tried several variations python-pip, pip3, python3-pip. None worked. This might be some weird interplay between the container and the host system. But I was not able to diagnose it.

Then I tried to install jupyter directly using apt. This worked!

Then I installed the WolframEngine kernel for Jupyter using Method 1 from https://github.com/WolframResearch/WolframLanguageForJupyter. This apparently worked. But some weird things happened:

The wolfram Engine kernel was shown when running

jupyter kernelspec list

both from the container (which I expected), and also the host (which I didn’t expect). As a matter of fact, all the jupyter kernels I had installed were shown, irrespective of whether then ahd been installed on host or container.

I tried to launch jupyter from the container. This worked. I add the option to select the WolframEngine as one of the available Kernels. However, the connection to the Kernel always failed. I do not understand why.

Any suggestions? (maybe install Wolframengine in the host and use Method 2 of https://github.com/WolframResearch/WolframLanguageForJupyter to install the juyter kernel)

Pleasant surprises

Aurora Plasma 6.1 works really well on a touchscreen of 2-in-1. Better then ChromeOSFlex (which didn’t have automatic screen rotation and screen brighness contral didn’t work) and Ubuntu with Gnome (screen brighness contral didn’t work)

Less pleasant surprises

The startup is really slow.

Now this is a slow machine, and there are no miracles. But Aurora startup is slower than CromeOSFlex, Ubuntu and even Windows10.

This might partially be a subjective experience: the Grub menu is shown, then disapears, then shows up, then the SDDM login screen appears, I type my passoword, Grub is shown again, and finally I am in the desktop.

Updates are also really slow.

Running ujust update takes forever. (again a slow machine)

2 Likes