share anaconda folder between different Linux installation - linux

On my laptop I have two Linux distribution installed: Fedora 25 and Arch.
For purpose of saving disk space I would like to use only one instance of Miniconda shared between these two installation.
Question: Is such solution safe or are there any known problems that can occur in such situation?
Update
It seems that there should be no problem with that: Google Group Thread

Related

How to create a Bootable GTK Application?

Hi i have an application written in GTK and i would like to make it into an bootable ISO file.
I have tried many options but have failed and being sent in many directions using cmake and make by following several tutorials which did not work.
Does anybody know how to create an bootable ISO file for / from an GTK based application on linux / ubuntu?
I am currently using ubuntu to develop the bootloading application yet i would prefer the GTK application to startup when the computer starts up, and have no operating system running if possible?
GTK requires an operating system kernel (a Linux kernel...) to be running, and some display server, e.g. Xorg.
So you need to actually make your custom Linux distribution.
I would prefer the GTK application to startup when the computer starts up, and have no operating system running
This is not possible
But you could study the source code of source based Linux distributions like Gentoo and work for several months to make your own Linux distribution.
You probably would need help and address many issues you did not even thought of (e.g. AZERTY keyboard layout, computers with only USB disks, laptops with only Wifi network connections, etc...)
Notice that Debian & Ubuntu can be configured to boot some (open source) GTK based installation procedure. I guess you could study in details their implementation (since it is open source)
It's not possible to boot a GTK application without operating system, as Basile Starynkevitch said.
However, you can use Linux to display only your GTK distribution, without any additional programs and I think it can be done easier, than Starynkevitch's method.
You can try to use the tool Systemback or similar to create a bootable live Linux distribution. Systemback is not maintained anymore but there is a github fork made by BluewhaleRobot that appears to be more up-to-date.
You can install a light Linux distribution, for example Xubuntu, and remove all unnecessary packages and programs. You can set the wallpaper, remove or leave the taskbar/menu start etc. Then, install your GTK application, add it to autorun and use Systemback's "Live system create" function.
The ISO image should be created and your program should be already installed in it with autorun.
It's not a perfect and stable solution, however, it seems to be the easiest way to achieve what you want.

Universal installers on Linux

I think its a fairly common problem, but I need to have community opinion and so I am posting this question.
Use case: I am trying to create a single package (32bit) for all the linux distros (32bit, 64bit) that I want to support.
Problem: The INSTALLER
Needs to be able to run pre/post install scripts.
Should be able to run on both 32bit and 64 bit machines
Should be able to support older and newer distros (Centos 6 and above)
Should have an online repository for updating packages.
Should be able to run without X server
Should not have any dependency on a software that cannot be installed using standard yum/zypper/apt commands. Should not depend on any non standard repository.
I came across this link:
https://www.reddit.com/r/linux/comments/4ohvur/nix_vs_snap_vs_flatpak_what_are_the_differences/
It lists many alternatives, but none of them seems to satisfy all the above requirements. (Or have I overlooked something)
In addition I looked at the following two alternatives:
QT installer Fwk (needs X to run, if I am right)
self-extracting scripts with tars bundled.
The only solution that fits all the needs is "self-extracting scripts with tars bundled". But it requires a lot of work, effectively managing all the installation/upgrade stuff myself. Before I go ahead with this alternative, can anyone please confirm if he/she has any success in creating a single package for many distros?
I don't believe in the concept of rolling one's own installer with a self-extracting archive overly much. Every distro is different, and should be addressed using their own installation mechanisms. Also, writing your own installer is re-inventing the wheel.
I'd advertise using the packaging methods of all the distros you're targetting. Essentially, one SPEC file is typically enough to support CentOS 6,7, and all modern Fedora versions. Use mock or the copr service to generate all the binary packages for the distros you're targeting; then a debian rules file should be enough to generate Debian, Ubuntu and Mint packages. Add a pacman script if you want to support Arch Linux, too (it's pretty easy).
Admittedly, this way, you end up with a whole bunch of different packages, and not one. However, now you have an installer for each system that actually fits that system, is linked against the libraries available on that distro, and thus, you don't have to include all the dependencies like in a flatpack etc.
Installation from Distribution-specific packages is almost always "smoother" than installation through some self-extracting archive that wasn't actually designed for my specific distro version, so this is probably a big plus for your users. Also, having packages usually makes it very easy and stable to offer an update path, should you decide your software needs patches later on.

Accessing ubuntu files from windows

I have two computers and installed ubuntu in one computer and windows7 in one computer. I would like to access ubuntu files from windows7.
How can i access ubuntu files from windows7?
There are several solutions you can use, like this two:
Ext2Fsd
Ext2Read
Second solution doesn't even have to be installed - you can just run .exe file and access partitions you want.
However, this solutions are 100% safe only for reading. If you need to read and write to Ubuntu partition often, you should create shared NTFS partition which you could access from both operating systems.

how to save a linux kernel and modules for use in other distro

Long story short, I bought a pre-installed linux laptop and would like to be able to run other linux distros, but use the same linux drivers w/ other distro so as to have all my hardware work flawlessly as it does with the custom linux Ubuntu 14.04 LTS.
If I could save or copy all of my hardware drivers someplace to reinstall once I've got a new linux distro installed.
So far I think the answer lays in compiling a linux kernel and modules from my running linux laptop, and try to get flashed in my new linux distro that I'm installing. Not sure if that will work? or is the easiest method.
Any help or ideas would be greatly appreciated.
i just want my linux workstation hardware to work as good as it does w/ Ubuntu 14.04, with any linux distro I choose to try.
Thanks in advance
A bit weired, but, as far as I gnow:
you can do the thing you ask for to customize the same distribution.
"Compiling a linux kernel and modules from my running linux laptop": You said the running one, so You can pick it instead directly from "/boot/vmlinuz-KERNEL_VERSION
"If I could save or copy all of my hardware driver": You can copy the content of "/lib/modules/KERNEL_VERSION" folder in the same emplacement in the target. This folder contains kernel modules, among others, device drivers.
After having these in place, you can make the drivers working with "modprobe", you should have a list for all modules (you might use "lsmod" in the original system) and load them one by one or find a way that manage to load them all at once for you; in CentOS, there is a scrpit "/etc/rc.d/rc.sysinit" that can among other stuffs, do that for you.
I really wonder why you are worried about drivers on Linux distributions, coz, as far as I know, they are really good when it comes to device drivers.

Best linux distribution to do Kernel Module programming

I want to do kernel module programming. But, all sources tell that linux distributions patch the original kernel and that module codes might not run on them. If this is true, what should i do.I tried making lfs using ubuntu but errors cropped up at almost every step. I saw somewhere that arch, gentoo, Ubuntu Server without any packages selected during the installation, slackware, susestudio etc. are vanilla distributions. So, can i use them for module programming?
Please suggest keeping in mind that i need a GUI in the distribution.
Can this be followed?
PS: I have a intel core i3 processor and will be running the distros on vmware workstation.
If you want to program kernel modules then it doesn't matter which distribution you choose. You will need to be able to recompile the kernel from source and install a new kernel yourself. Even just for a kernel module you'll want to be able to compile the latest kernel and develop against that, otherwise you won't be able to get the module accepted in to mainline.
An alternative if the module is not to be released is to develop against a particular kernel version. In this instance then the choice of distribution should be chosen based on the target for the module - not the development environment.
So pick a distribution based on what you like:
1) Desktops - (GNOME, KDE, other)
2) Ease of use - (Ubuntu, Fedora, etc vs Arch, Gentoo)
3) Cutting edge vs Stable (Arch, Fedora vs Ubuntu vs Debian, Red Hat, CentOS)
Then head off to kernelbewbies to learn a bit about getting started with kernel programming (where to get the source, how to compile it). Then read Greg Kroah-Hartman's excellent book on linux device drivers. The interfaces will have changed (it's written about version 2.6 of the kernel and version 3.6 is currently being worked on). It can be found online here
You'll also want to learn how to use git. And more importantly how to use git to generate a patch and email it without messing it up! I don't have a website for this but a bit of googling will help.

Resources