A LuxCore Render Linux compilation – long, problematic process with a dll-hell
Repeating bugs in the process of LuxCore Render compilation, when I compiled it for approx. month of time. I mean both bugs originating from LuxCore compilation environment at the (too?) proud author(s) -site, AND the difficulty operating CMake – when there's even alternatives, and all this bisons, meson, ninja, autoconf..... and last, but not the least – QMake – I feel nervous looking at that. Much problem in Linux world was building of compiz-git package – AFTER much TIME you are being familar with the clang C++/C compiler compilation process. And a compiz dependency, the protobuf library of Google – turned to be copied to /usr/local/... or its subdir.
Similar strategy needs to be done when dealing with some other apps that depend on ICU-xx internalization library,
First, most important question - where is a point that Linux system (concretely, Arch Linux) goes?
Contantly changing of the most basic system elements – even Debian users aren't glad when they are forced to using old package versions – I tried evento „run” non-functioning App Image.
I made convenience script that replaces the ENV. to „LD.” it to old, previoulsly-copied version of ICU lib. Then I could run some programs OK, with gmrun application „activator”/runner possibilities. As in Linux world, things aren't changing so speedily, this way of operating and administering Linux system – in my opinion tends to remain.
When chaotic vision of system growth makes things complicated, and more scalable
I see it, as a repeating pattern, in process of upgrading the system. In my experience some things need to be compiled but other of course can't – I'm not fan of Gentoo user-compiled system solutions. I do compilation when it suits needs – I „omitted” one importand bug by it, so far. AppImage is not usual solution, I don't believe in it – instead of depleting system RAM, I prefer .so object sharing in RAM. And more, I prefer such techniques of optimizing application code.
If we would use Linux apps wisely, the additional CPU power would have less point of EVEN usability of too-multithreading/CPUs in the MB.
I don't need AVX, SSE3 plus, multi-multi, hyper threading – if you can't program algorithms (esp. browser HTML / +the Java runtime) with proper degree of optimization, then you should direct your time meditating on general information technology issues. One example are the criteria of automatization – you fear it, but life shows it will be necessary in future. Similar issue is to be understood when thinking about relation of internet browsers (esp. in matters of WebGL). Way you use a product implicate the calculational complexity in the main-or-GPU processor. If you make a wise applications (for example, not China/Japan pokemon-go animations in Blender –» ), •then CPU/GPU execution is simpler, and even Watts from your power supply are overall more effective (smaller energy consumption, means more $$$s, to write some of advantages).
They think maybe that pikaur helper and all this „chaotic” solves problems. No, w/o proper philosophy, it can't be done.
I rather treated Linux system as modern. How an error! Arch Linux seems to be modern, especially because of ability to complex-repair and „simplicity” of elasticity – DIY compiling things from AUR shapes system user experience into quickly-resolvable as the needs arising. But this Arch Linux typical approach does have its counterpart. Very flexible system is compromised by time spent in actualisation (including its part, compiling software). Things have some huge bugs, and this turns to be a point when disadvantage of Linux approaches. You have bugs in DE, you have bugs in LuxCore Render (disappeared when I linked whole Bfor Artists into KDbg – ONLY THAT SUFFICES! – LuxCore Render NO MORE STALLED the Blender remake, that is, Bfor Artists, suite.
But it can't be done at all times.
I'm a man, not desiring to replace system elements in an unpredictable way. And definitely, not want to await Blender „Modern” ugly pokemons in Blender / Bforartists suite. Why you must repeat China's errors, America?
Think more about philosophy and spirituality – as Robert Monroe said, you are more that your physical body. As intelliogent being, we must care about ourselves, not only this machines, PCs, smartfons (EGL library). We are NOT „pocket humans”. We are more worthy that systems that we are programming, and also, administering.
Things not need to be quicker, quicker, quicker.
OpenCL was somewhat fine, but selective. Why to make such mess in era of multiprocessor motherboards??! If it really be... fine... then, GPU would be in BIOS as another main processor option !!! But is doesn't. You should m e d i t a t e on 3D graphics rendering process, not only „eat” it mentally. That's it.
•As in life. Contemplation matters, but it mustn't be limited to external, peripheral env. Be humans, NOT the monkeys or other animals!!
•Why I don't „believe” 100% in USA when dependent on China hardware... still. Such a big problem... . But bigger problem would be if Americal even turned to [be the]China.... This 'd make the spiral, a cascade of problems – avoiding that starts certainly at clues contained in this article!