rolfen/00 Ideas and notes

## 00 Ideas and notes
Related to Linux

## 02 Flexible linux packages
In Debian Linux I often find myself wanting to create quick, somewhat temporary packages.
For example, I have a project X, in the course of which I install A, B and C.
I would like to have a package X for the project, to which I attach all these dependencies, then I can just uninstall X.
Package systems are nice but they are much more useful if users can quickly create dependencies and packages.

So I'm thinking, npm can do that (`--save` flag).
Maybe I can just wrap apt package with npm.
Using post/pre/etc. install hooks I can install/delete apt packages underneath.
Then I can create dependencies on-the-fly using --save and when I uninstall the main package all dependent package get uninstalled.

However npm packages are often local Apt packages are global.

Possible solutions:
 - Force this system to be global or be a singleton (hmm).
 - Have some sort of global service that manages duplicate packages (hmmeeeh mmmno). I think npm already does that.
 - Use flatpak to containerize and deduplicate (ostree deduplication) (hmm bah).

 UPDATE: I have found the equivs-build tools which lets me quickly create virtual packages for deiban, pretty much what I was looking for!

## 03 But then why install
Seemingly the whole "install" paradigm is flawed. A software wanting to isntall itself needs to know the state of the file system (among other things). This state cannot be predicted, it changes from one computer to another.
It needs to know where to insert itself. What to overwrite, what not to overwrite, then how to remove itself.
So I am thinking it makes more sense to go the other way around.
Installing a sofware would mean just creating a new directory which contains all of it.
Then the OS would catch an FS notification and examine that directory, register the new software, etc.
The OS knows it's own state (version, what is installed, what has been modified, architecture, etc).
Also there is no risk of software not cleaning up after itself. De-installing means deleting the directory.
Again the OS can clean up anything that was pointing to this directory, and trigger/process any related events.
So it would be more of a declarative approach over imperative/procedural "installation".

And anyway, whatever the implementation, the whole install process should be transparent to the user.
The user should not know or care whether the software is installed, or where.
If there is any installation needed, it should happen in the background.
Sort of like HTTP transparent proxying and caching.

## chrome-proxied.bash
#!/usr/bin/env bash
ssh -f -N -D 9081 $1
google-chrome --proxy-server="socks5://localhost:9081"

## gistfile1.txt
Photo financing:
https://visitcenter.org/call-for-entries/
	In Debian Linux I often find myself wanting to create quick, somewhat temporary packages.
	For example, I have a project X, in the course of which I install A, B and C.
	I would like to have a package X for the project, to which I attach all these dependencies, then I can just uninstall X.
	Package systems are nice but they are much more useful if users can quickly create dependencies and packages.

	So I'm thinking, npm can do that (`--save` flag).
	Maybe I can just wrap apt package with npm.
	Using post/pre/etc. install hooks I can install/delete apt packages underneath.
	Then I can create dependencies on-the-fly using --save and when I uninstall the main package all dependent package get uninstalled.

	However npm packages are often local Apt packages are global.

	Possible solutions:
	- Force this system to be global or be a singleton (hmm).
	- Have some sort of global service that manages duplicate packages (hmmeeeh mmmno). I think npm already does that.
	- Use flatpak to containerize and deduplicate (ostree deduplication) (hmm bah).

	UPDATE: I have found the equivs-build tools which lets me quickly create virtual packages for deiban, pretty much what I was looking for!
	Seemingly the whole "install" paradigm is flawed. A software wanting to isntall itself needs to know the state of the file system (among other things). This state cannot be predicted, it changes from one computer to another.
	It needs to know where to insert itself. What to overwrite, what not to overwrite, then how to remove itself.
	So I am thinking it makes more sense to go the other way around.
	Installing a sofware would mean just creating a new directory which contains all of it.
	Then the OS would catch an FS notification and examine that directory, register the new software, etc.
	The OS knows it's own state (version, what is installed, what has been modified, architecture, etc).
	Also there is no risk of software not cleaning up after itself. De-installing means deleting the directory.
	Again the OS can clean up anything that was pointing to this directory, and trigger/process any related events.
	So it would be more of a declarative approach over imperative/procedural "installation".

	And anyway, whatever the implementation, the whole install process should be transparent to the user.
	The user should not know or care whether the software is installed, or where.
	If there is any installation needed, it should happen in the background.
	Sort of like HTTP transparent proxying and caching.
	#!/usr/bin/env bash
	ssh -f -N -D 9081 $1
	google-chrome --proxy-server="socks5://localhost:9081"