Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Tuesday, November 1, 2011

More thinking on software bundles for Linux

The post Rethinking the Linux distibution made me revisit some of the ideas which I had in the past trying to address which in my opinion are major limitations in the current main packaging systems:
  • No support for multiple versions of the same software
  • No support for rollbacks
A software bundle composed of the application and all it's "non core" dependencies can  also add some other benefits:
  • Cross Linux distribution delivery
  • Fine grain control of libraries and options used by an application
  • Reduced complexity with the removal of dependencies management
The disadvantages are:
  • Increase on Disk and RAM usage from software containing different versions of common libraries
  • Applying security fixes  on dependencies requires re-creating/re-distributing every affected bundle
Possible approach for implementation:

Compiling
Adapt an existing source base build system like Arch's "makepkg", with the following changes:
  • Run time prefix must be set to /opt/bbundle
  • Build definitions for dependencies must be contained in the master build definition (this will lead to build definitions redundancy across bundles but will remove the risk of breaking builds by sharing dependencies building rules) 

Bundling
The bundle file format should be a commonly used archive format, since tar does not provide indexing, .zip is a better option. Having an indexed archive will allow to reduce download sizes by inspecting the bundle  contents prior to the download and skipping the download for common files found at installed bundles. In order to save on-disk space, the bundle installer should check for identical files across bundles and use hard links instead of duplicating files.

Installing
Bundles installation should be as simply as extracting the bundle archive into /usr/local/bbundle/bundle_name. A watching service must identify .desktop and other exportable resources and make them available from the host desktop environment.

Friday, March 4, 2011

First day with Fedora 14

I am starting my adventure searching for a new FOOS project to get involved with. I still think that a Linux distribution is one of the most interesting type of projects. We have so much Free Software that is not reaching yet those who would benefit from it.

Yesterday I have switched from Ubuntu 10.10 to Fedora 14 I have chosen to try Fedora because it has an open governance model with a clear leadership. While there are a clear special capacities from the sponsor (RedHat), at the highest level the project is managed by an Executive Board, the board is composed with a mix of RH appointed and community elected members.

Now back to my first day experience, I was afraid that it would be an hard experience, I use Linux for my primary workstation so it really needs to work.
The install was smoothly, I did found a bug on a specific case of setting up an user with an existing home dir containing invalid symbolic links, nothing serious.

I was able to install all my job required tools using Fedora 64 bits thanks to the multiarch supports which allows to install both 32 and 64 package versions, this is something I could not achieve with Ubuntu 64 bits, ia32libs is not sufficient for my case.
All the software that I needed was available from repositories or as an .rpm from upstream: Filezilla, KeepassX, Zim, X-Chat, Skype, VirtualBox, gnomedo, tsocks, eclipse, cairo-dock, geany. dropbox, pidgin .

During a full work day I have found no significant usability differences between Fedora an Ubuntu.

The only issue I had so far was related yum repository errors, this is one of my next steps, to understand Fedora repository types and package building.

I will also try to understand if the distribution itself is effectively governed as documented.