What are the implications of having Anaconda running at the bootloader level as an installer for Fedora WS?
What are the implications of having Anaconda running at the bootloader level as an installer for Fedora WS?
Anaconda is the installation program used by Fedora, Red Hat Enterprise Linux and some other distributions. During installation, a target computer’s hardware is identified and configured, and the appropriate file…
I've been trying Workstation recently. Python dependency issues caused me to switch to Silverblue for the last 2 years. A new machine with Nvidia got me to try WS. I just had a mystery problem with Python after booting today and that got me looking into Anaconda. I didn't know it was used under the kernel like this. I'm not sure how I feel about this level of Python integration. I would feel a lot more comfortable with a less accessible precompiled binary but I know I am likely making naïve assumptions saying this. Any thoughts or insights?
Anaconda is just an OS installer program. At least, the Anaconda that you're referring to. After installation, it's gone.
There is also Anaconda which is a Python platform/package system/whatever. Maybe you're confusing the two?
I should have searched for this first I guess. That is reassuring. I was mostly uncomfortable with the idea of the two being the same.
Still Anaconda from RH claims the software is mostly written in Python. That still makes me uneasy. I've always thought of C as very near to the hardware assembly and an interpreted language as prioritizing portability, flexibility, and access. I find it far harder to hack around with a binary written in C versus all of the python stuff I've encountered. Maybe I'm just mistaken in my understanding of how this code is running.
I look at C programs as tied more to the hardware they are compiled to run on with permanence. I look at python as a language designed to constantly depreciate itself and its code base. It feels like an extension of proprietary hardware planned obsolescence and manipulation. I don't consider programs written in Python to have permanence or long term value because their toolchains become nearly impossible to track down from scratch.
You might be even more concerned to find that your Fedora package manager, DNF, is also written in Python: https://github.com/rpm-software-management/dnf
Fact of the matter is that Python is a language that gets used all the time for system level things, and frequently you just don't know it because there is no ".py" extension.
I'm not sure I understand your concerns about python...
- Performance is worse than C, yes. But writing performance sensitive code in Python is quite silly, it's common to put that in a C library and use that within python to get the best of both worlds. DNF does this with libdnf.
- "It feels like an extension of proprietary hardware planned obsolescence and manipulation." This is very confusing to me. There has been one historic version change (2->3) which broke compatibility in a major way, and this version change had a literal decade of help and resources and parallel development. The source code for every Python interpreter version is freely available to build and tweak if you're unhappy with a particular version. Most python scripts are written and used for ages without any changes.
- "i don’t consider programs written in Python to have permanence or long term value because their toolchains become nearly impossible to track down from scratch." Again, what? As I said, every Python version is available to download, build, and install, and tweak. It's pretty much impossible for python code to every become unusable.
Anyway, people like the Fedora folks working on anaconda choose a language that makes sense for their purpose. Python absolutely makes sense for this purpose compared to C. It allows for fast development and flexibility, and there's not much in an installer program that needs high performance.
That's not to say C isn't a very important language too. But it's important to use the best tool for the job.
My understanding is that the OS Installer Anaconda is only run to install the OS, not at boot time. Python is a mature language, nothing wrong with implementing a not-often run install script in it IMHO. Especially at OS installation time the python environment is very well defined.
I think it carries over. It is embedded all throughout journal logs.
Basically, your Anaconda won't want none unless you got buns, hun. ;)
Why would you feel safer if anaconda would use another language like c instead of python, besides performance which doesnt really matter in this scenario?