Install Blender 2.83 LTS

[Grahm]

I was using a version of Blender from Discover and found out that it is 2.82, which is an old version and lacks some packages. I then searched for Blender in Discover and found out that another version available is 2.9x. This version is also not a long term support one. LTS is 2.83.x

Currently, I downloaded the tar.gz from Blender.org and is double-clicking the executable file each time when I need to run Blender. No option to ask it to Task Bar or an icon on Desktop. It would be nice to know whether it is possible to install the LTS version 2.83.x the conventional way. Thanks.

Wish you all a great 2021

[Bings]

If you right click the application (start) menu button and click "edit applications" It brings up kde menu editor for you to add custom applications to the menu. Select the sub menu you want it in and click "new item" and you have the following fields to fill in the name and description of the application you want to enter. You can also set an icon. In the "Command" field you want to write the path to the blender file for example /home/USERNAME/blender folder/blender When you are finished, click the Save button. It's very important not to forget to do this or you'll get annoyed at having to start again... so I'm told.

Once it's in the application menu, you can right click it there to add to desktop and panel. It will also come up in your program searches.

If you want to remove the entry at a later date, you go to the editor and delete it there. Don't forget to press save then either.

[Bings]

Another option is to install it via flatpak https://flathub.org/apps/details/org.blender.Blender

Edit: Actually, you want a specific version, to that's not going to be what you want.

[Grahm]

Thanks. Adding icon is working great :thumbsup

[claydoh]

You can get it as a Snap, no one seems to make debs or flatpaks for this version afaik.
I don't use snaps, actually removed the system from my installs, but if I recall, in Discover, one could choose the desired release of a snap package to install. I could be wrong though.

In any case, this page leads to their official Snap page, which if you click on the version drop down box on the upper right side of the page, will give you all the available versions (Many!) and the command to use to install that specific version if you can't choose it in Discover.

[GreyGeek]

Or, using an AppImage, you can use Blender 2.90!

[claydoh]

Or, using an AppImage, you can use Blender 2.90!

The OP wants Blender's LTS version, and to have something managed by the system for menu entries etc.

[Grahm]

Thanks +claydoh, +GreyGeek

I would like to stay with LTS release because there is a lot of how-to videos for it on YouTube. There is community support as well. App image is surely a brilliant idea.

Snap has an LTS version, might get updates as well. I will have to try.

I do not know much about Flatpak. Is it beneficial to install it on 20.04 ? Appreciate all your comments

[claydoh]

Flatpak and Snap are 'competitors' for the new style of self-contained, sandboxed, distro-agnostic application packaging systems.
Many hardcore Linux fans don't like them, and there are valid reasons not to. A potential for bloat in terms of drive space due the included system files and libraries. Extra services running in the background, it's something new and different , etc.


But they are not harmful, and are a boon to 'normal' users, providing newer versions with common (and known) dependencies included.
Individual projects are able to provide their own packaging easier than needing to build things for each of the major distro's packaging systems, or relying on someone else to do this for each one.

Of course all the extra choices makes things possibly more confusing or cumbersome, though they are updated via Discover so multiple tools are not required.

[Grahm]

Thanks. I will try to stay with normal Kubuntu for now.

[GreyGeek]

Thanks +claydoh, +GreyGeek

I would like to stay with LTS release because there is a lot of how-to videos for it on YouTube. There is community support as well. App image is surely a brilliant idea.

Snap has an LTS version, might get updates as well. I will have to try.

I do not know much about Flatpak. Is it beneficial to install it on 20.04 ? Appreciate all your comments

Downloading a tar file isn't exactly "staying with the LTS"! But, to each their own.

A lot of folks, me included, do not like snap because while you may not often run Discovery, or muon or synaptic (or do the manual apt commands) the Snap Store keeps a daemon permanently running on your machine as a service. There is no practical reason to do that unless that daemon had other, additional, purposes.

I, maybe once, twice or three times a year, run the free version of TeamViewer to connect to other computers to help their owners debug a problem. When you install TeamViewer it installs a daemon, teamviewerd, which runs as a service 24/7/365 (or as long as your machine has power). Since TeamViewer has limits on what it can do based on whether you are running the free or commercial version, the teamviewerd is there to monitor your usage to make sure you are using it within the constraints of the license you chose. Can it spy as well? Of course. Does it spy and call home with information (the way M$ and Apple do?). Not on my machine. I used Systemctl to disable the teamviewerd.service so that it does not start automatically when I turn on my laptop. When I run the GUI the daemon is also started. When I am done running the GUI I also disable the daemon.

Canonical has started a software store to which snapd connects. Some of the software it dispenses is commercial and, just like TeamViewer, Canonical needs to monitor the usage of proprietary apps to make sure the user is remaining within the license they've agreed to. Can snapd spy on your other computer usages, collect login names and passwords just like Google and M$ do? Of course. But not on my machine because I uninstalled snapd. And, I am not running M$ software, and I do not have a Google (hence YT) account. Ditto for FB and TW.

To further block pixel bots, tracking cookies and encoded URLs I installed a hosts and a hosts.deny file which sends their domain names or IP addresses to the infinite bit bucket in the sky ( 0.0.0.0 ). Those two files are here:
https://github.com/Ultimate-Hosts-Bl...osts.Blacklist

Here is the line counts:
$ wc -l /etc/hosts
94094 /etc/hosts
$ wc -l /etc/hosts.deny
139967 /etc/hosts.deny

I use AppImages because:
1) Each image is complete. It carries with it all of its dependencies and doesn't require any libraries from your system.
2) It is run by giving the AppImage file an execute permission AS THE USER, NOT ROOT. Then one can either double click on it to start it or create a link in the KDE menu structure.
3) When you close a program run from its AppImage it does not leave any detritus on your system. If your program creates files you can save them either inside the AppImage or in an external directory. If outside then the file, say a CAD file, is accessible to other applications without running the AppImage.
4) When you want to remove the program you merely delete the AppImage.
5) There is an app called AppImageUpdater but I don't use it.

I retired in 2008 after about 40 years of programming/teaching/business and haven't written a serious application since then. Only trivial scripts.

It's still generally the rule that there are two ways to compile a program from the source code: 1) static or 2) dynamic.

A dynamically compiled program expects to see the library (and the correct version of it) in the system libraries directories and makes function calls to it. Since it does not contain any libraries within its executable the executable can be very small. This was important two or three decades ago, or before, when HDs were small and expensive. Ditto for RAM.

A statically compiled program, for every library it makes calls to, pulls the entire library into the final executable. This can make executable very large. During execution calls to the library are handled by the internal copy. One app I wrote, when compiled dynamically, took 53Kb of space. The static version about 20X as much.

Today, computers have much more memory and storage space than they did before 2005, and they cost a LOT less. It is not a necessity to compile programs dynamically anymore because disk and RAM real estate is abundant and cheep. Ergo, I use AppImages when ever I can. I currently have 18 AppImages on my system.

My ancient 2012 Acer Aspire V3-771G has 16GB of RAM and two 500GB SSD's and one 750GB spinner. It's 4 core 8 thread i7 CPU runs at 3GHz. My first PC was an Apple ][+ with 64Kb of RAM and two 225KB Disk][+ floppy drives. The 6502 CPU ran at 1Mh. Using a compiled UCSD Pascal program it took 48 minutes to create a single frame of a Julia fractal. Today, I can run fraqtive and zoom down through the frames at over 30 frames per second, which is 86,000 times faster.

Statically compiled programs makes using firejail and other sandboxing programs easier to use and your system much safer.

Sooner or later, as disk size and cores continue to increase, all apps will be compiled statically. Programs dynamically compiled will diminish in number until OS and system developers decide to eliminate those libraries.

[Bings]

You don't need to compile the blender download though, it runs from the folder you extract it to.

[GreyGeek]

You don't need to compile the blender download though, it runs from the folder you extract it to.

True, but that doesn't change the dynamic-static dichotomy. The ELF executable permission was set before it was tarred and that permission remains after it is untarred. The size of the executable still depends on whether it was compiled dynamically or statically. If dynamically, then the issue of library version comes into play. In the 22 years I've been using Linux I have on many occasions compiled source code, or unpacked pre-compiled apps, which required a specific version of a specific library. If my system didn't have a version the source code didn't like then either the compile would fail, or the app would fail when I tried to run it. Sometimes, when I sought to upgrade the library (or downgrade it) to a version that worked the new version was incompatible with other software already on my system which expected to see the previous version, thus breaking them. This was a common problem before distribution repositories became common. When I was running SuSE I'd frequently download rpm files from the website "rpm.bone.net". It was hit or miss if the rpm file would integrate well into SuSE because the RPM files were compiled on many other distros that also used the RPM manager. Statically compiled source code avoids that problem. So does installing all your apps from a distro based repository. Apps in the repository are vetted to work against existing libraries in the repository or on your system. I can't remember the last time I had a program installed from the repository that had a library compatibility problem and failed to run.

[Grahm]

Ok. I am not sure whether I said anything wrong here. By " Staying with LTS ", I meant using 2.83.x LTS series of Blender. I use default Kubuntu and whatever " Discover " store provides me. Unless you count a couple of icon packs.

App images are better than tar.gz file for Blender ? Considering Blender is Open Source, I used one of their official (in-site) LTS tar.gz download file. As a matter of fact, there is only one option for Linux 64 bit on their website for LTS version.

[GreyGeek]

Ok. I am not sure whether I said anything wrong here. ...

You can't say "anything wrong" on this forum, unless you are spamming. Political persuasion, gender, faith, profession ... none of it matters here. What matters is being kind, considerate, and willing to courteously help the next person who asks the same question you answered 235 times in the past!

Oh, we are somewhat of a family forum so keeping postings PG13 is always appreciated.