Foresight Linux is an OS for your computer/laptop. And here is some info about Foresight Linux:

• Rolling updates
• Rollback feature
• Conary as package manager
• Standalone, not based on any other Linux dist.
• Easy to create own packages [2], maintain packagers and create a own repository address to use/share.
• 32bit and 64bit always available. i686 system.

i686 is a much more modern architecture. It includes practically every processor that’s Pentium II or better. x86_64 is a 64 bit extension to the x86 architecture. x86_64 processors can still run 32 bit operating systems (e.g. i386) if you so choose, but they’re also capable of running 64 bit operating systems.

Watch the presentation that Michael Johnson gave at FOSDEM 2008 (follow along with his slides)

Watch how fast a user in Foresight can update a package to newer version.

That’s little info in generally. Let’s dig little deeper now.

At anytime an update fails Conary will rollback to the previous job leaving your system dep complete and fully functional.

How Conary Organizes Packages

If you use debian or rpm repositories…you know that inside a repository directory “stable” (as an example) are all the stable packages for your distribution. The packages are versioned according to their upstream version (if the repository maintainers are sane) and maybe arch and revision number. This is done by hand. It is managed by hand. If developers/packagers cross names between repositories you are brought into dependency problems. To illustrate this concept, if you and I both packaged firefox3 and named it accordingly…and someone used both your and my repository…our versions would conflict because the packaging system wouldn’t know which one to install.

Conary takes the manual operation from this…if you use a Conary based system, yourrepositories ARE VERSIONED. In other words, the repositories aren’t static directories that contain a bunch of packages…they are versioned branches that contain components of software.

These components (packages) are also versioned according to upstream version…but revision is handled automatically by Conary…no manual process. This eliminates the possibility of having two packages named the same exact thing in different repositories. In other words, if Joe Schmoe is packaging Liferea for his apt.joeschmoe.com repository and names his package the same thing as say Joe Smith’s package for Liferea in his apt.joesmith.com repository we run into problems. With conary this NEVER WILL HAPPEN…EVER. This kills about 90% of dependency problems all together.

But what about arch? Arch is architecture…32bit or 64bit…PPC and more. Once again, you’re bit by the possibility of conflicting names across repositories. You’re also limited in the name because a developer has to put the architecture INSIDE THE NAME. Take a look at liferea as an example: liferea-1.2.2-2.el5.rf.x86_64.rpm. Is this easy for an end user to understand? Is it the same as liferea-1.2.2-2.el5.rf.x86-64.rpm?

Conary takes a different approach. Each package has a ‘flavor’ that it is ‘cooked’ (committed) in. There may be a 64bit flavor, 32bit flavor, Xen flavor, and so on. This flavor is visible to the user only if the user requests to see it…and it is NOT inside the name of the package. The package is still called, simply enough, liferea. Revision number, arch, upstream version, etc…are all handled automatically by Conary.

You can see how creating and maintaining software would rely less on a manual process and more on automatic source controlled one with Conary. You can also see how organized Conary is with its packages. (this chapter comes from devnet)

Conary treats packages as change-sets and not as a bundle of files. This means that when updating a package, Conary communicates with the repositories to determine what needs to change on the system to install the new package and only downloads the bits needed for that change. There are many advantages to this approach, but most visible to the user is the efficiency in bandwidth and speed.

When updating a large package for the first time, you will essentially download the full package, however, when updating in the future the downloads could be significantly smaller. Here is an example: installing Abiword 2.2.6 on a system for the first time would be approximately a 15MB download, however updating to Abiword 2.2.7 is only 2.4MB.

How can I be sure things still work if I remove a component from my system?

First, Conary warns you if you are about to remove a component that is used to resolve a dependency elsewhere on the system. Conary keeps track of these dependencies for you. Second, you can use the –deps option to display dependency-related information. Furthermore, you can also use –file-deps to list component dependencies at the file level. Results display what the trove “requires” to resolve its own dependencies and “provides” to resolve other packages’ dependencies. You don’t have to track this information unless you really want to do so; trusting Conary’s warnings is usually enough to prevent mistakes when installing and removing software.

What’s that colon for? Is “chromium:runtime” different than the “chromium” package?

It is different, but part of the same package. When the package name is followed by a colon and another name,

such as “chromium:runtime” and “chromium: doc,” this references a component.

When the package is first built, Conary separates out the files into components.

Each component represents some logical grouping of files within the package,

such as everything needed to run the software or the documentation for how to use the software.

This gives the flexibility for other packages to resolve dependencies by bringing in components rather than entire packages.

It also gives users the freedom to uninstall components that are just taking up space without removing an entire package.

But, enough about how awesome Conary can be.

So unlike other packaging systems, where you might have 2 packages, firefox and firefox-devel, Conary would have one package with the devel headers split into firefox: devel. This is a great thing, you no longer end up installing -devel packages from random repos in your sources.list just because it looks like a newer version. The devel headers are just part of the same package, you just don’t have to have them installed. These components combined with rich dependancy information really shines.

Info about some packages

There is few applications that makes a user happy with a Linux dist, so here is a few that works perfectly with Foresight:

Chromium: Updates almost every week. Flash, embedded trailers works out of the box.

Nvidia/ATI: Easy to install, but legazy drivers is little harder. But works to get them in too.

Gnome-Shell: Stable gnome-shell available and latest git gnome-shell can be easily installed. (very easy to go back to stable when testing unstable)

Wine: When installed, everything works as it should with wine. 32bit and 64bit works fine from start.

Create own packages

Maybe sounds hard, but think again. It’s very easy.

1: Setup environment

2: Full packaging example

And as you saw in the video earlier in this post, an update of a package can go really fast

What do you really get from creating own packages?

First of all, very easy to maintain and update. Usually updating before every linux dist out there. Very easy to uninstall a package. Very easy to switch from stable repo of a package to unstable and back again. Easy to change parameters for a package and repack it for your needs.

And as soon you see a new application, like radiotray, you can easily make a package and test it. As soon you are done testing, unistall it as it never was installed. Or even better, let Foresight users also use it and suggest it to be added in Foresight repo. (can offcourse be installed from your personal repo too)

Download

Test iso files:

If you want to use test iso, then after installation and first time you boot up Foresight, you need to change installation label in it. To make it use “test” repo instead of stable repo.

Open terminal and write:

sudo sed -i -e 's/fl:2/fl:2-qa/g' /etc/conary/config.d/foresight

To get started with Foresight Linux:

Look at foresight userguide at system > Foresight userguide

To get common codecs, open terminal and write: sudo conary update group-codecs

To install Nvidia drivers: sudo conary update nvidia nvidia-kernel

sudo nvidia-xconfig

To install ATI drivers: sudo conary update ati-fglrx ati-fglrx-kernel

sudo aticonfig --initial --input=/etc/X11/xorg.conf

Search after applications or browse after applications: rBuilder online

Some known problems:

Packagekit, the gui for conary isnt working as it should.

This is also holding up the new release of a new iso for stable repo.

First time when trying to update system can fail, a restart of system will fix it.