Getting rid of installation...
Getting rid of installation...
the thing that I think is most annoying about most any OS out there today is all the programs must be installed! I can see compressing it for bandwidth, and then having to uncompress it somewhere...but installations are so messy!
I really am not completely for sure on hwo to go about doing this...
The main problem is global configuration stuff..
It's just not easy to copy it, but it's also not easy to form a relocatable way to handle it..
anyone have any ideas?
I really am not completely for sure on hwo to go about doing this...
The main problem is global configuration stuff..
It's just not easy to copy it, but it's also not easy to form a relocatable way to handle it..
anyone have any ideas?
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
On OpenBSD it's rather simple, You can use ports or binary packages.. All your personal settings are stored in your home folder..
For example, ~/.mozilla/firefox has all my Firefox settings & preferences.. Which is all that is required to backup..
Even if I accidentally deleted the installation of Firefox, My settings would still be safe.. And I would just reinstall the package. (Or if using ports, Just change into the firefox tree and type make install..)
And one should rarely use global config files, Any system specific settings would go into /etc and any application specific settings would go into the users home directories..
I can't really see the point you're trying to make though.. Must be your bad experiences on Windows. (With the insanity that is "Registry")
For example, ~/.mozilla/firefox has all my Firefox settings & preferences.. Which is all that is required to backup..
Even if I accidentally deleted the installation of Firefox, My settings would still be safe.. And I would just reinstall the package. (Or if using ports, Just change into the firefox tree and type make install..)
And one should rarely use global config files, Any system specific settings would go into /etc and any application specific settings would go into the users home directories..
I can't really see the point you're trying to make though.. Must be your bad experiences on Windows. (With the insanity that is "Registry")
Last edited by Brynet-Inc on Sat May 19, 2007 12:59 pm, edited 1 time in total.
PC-BSD uses this through its PBI system.Crazed123 wrote:Ports-type systems require someone to actually maintain the ports tree. I personally like some mix of the Mac and Windows solutions: have a directory like Program Files where you can simply drop and unzip packages to install them.
C8H10N4O2 | #446691 | Trust the nodes.
How about keeping system-wide data in a settings file alongside the executable, and user-specific data in the user's home directory. Then, to migrate you just need the application directories and the home directory.
The question is how you want to support shared libraries. If you just place them all in /usr/lib then that's something else you might need to copy. Deleting it may affect other programs...
Regards,
John.
The question is how you want to support shared libraries. If you just place them all in /usr/lib then that's something else you might need to copy. Deleting it may affect other programs...
Regards,
John.
- AndrewAPrice
- Member
- Posts: 2300
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
I like the idea of the entire program being contained in a single file (with the exception of user settings).
I thought there were two ways around this:
- Use a file format that supports adding, removing, and modifying attached resources.
- Place the executable and all resources into one archive, and make sure all necessary files are inside the archive, then run the program from within the archive (done in the background by the system of course!) Then when the program wants to access or modify one of it's resources, it's modifying it within the archive.
If you go with b) you could make the archive read only, and rather than having to 'install' or 'modify' itself. It couldl have access to a local file.
e.g.
You have a burning frontend inside a tarbal (stored on a read only media) along with all the back ends and libraries.
When you double click the tarball, the front end loads, it can access its own files within its archive, and if it needs to configure (say, detect the path to CD burner) then it can save its global settings under as /etc/[program name] and local settings under /usr/[user]/[program name]. It would be easy if the program only wrote to a file with the same name as its name, then from within the a you could have a "Remove config files" and it will only have to delete (at most) 2 files!
I thought there were two ways around this:
- Use a file format that supports adding, removing, and modifying attached resources.
- Place the executable and all resources into one archive, and make sure all necessary files are inside the archive, then run the program from within the archive (done in the background by the system of course!) Then when the program wants to access or modify one of it's resources, it's modifying it within the archive.
If you go with b) you could make the archive read only, and rather than having to 'install' or 'modify' itself. It couldl have access to a local file.
e.g.
You have a burning frontend inside a tarbal (stored on a read only media) along with all the back ends and libraries.
When you double click the tarball, the front end loads, it can access its own files within its archive, and if it needs to configure (say, detect the path to CD burner) then it can save its global settings under as /etc/[program name] and local settings under /usr/[user]/[program name]. It would be easy if the program only wrote to a file with the same name as its name, then from within the a you could have a "Remove config files" and it will only have to delete (at most) 2 files!
My OS is Perception.
-
- Posts: 21
- Joined: Tue Jul 24, 2007 1:19 am
.net programs can be just copied to their destination (once you have the framework installed of course ) and resources can be embedded inside the executable file (I never really examined the technique but I know it can be done, as the splash screen for a project I am working now was built inside the executable)
Computer science: all about things that "should" work