Foresight Linux is an OS for your computer/laptop. And here is some info about Foresight Linux:
- Rolling updates
- Rollback feature (Offline rollback feature too)
- Conary as package manager (conary manual)
- Standalone, not based on any other Linux dist.
- Easy to create own packages and maintain packagers.
- 32bit and 64bit always available. 64bit always works as good as 32bit, you don't need to choose 32bit to make it work better as other dists might do.
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 and from Antonio Miereles with 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.
On Debian or RPM based systems, when you do upgrade, then thepackagemanager will pick the latest version from all packages. That is,
if you upgraded yesterday, and i upgrade today then our systems may be different because i might have picked up a newer version of some package. In Conary, all packages that are available for install are assembled into a group. This group is created by the distribution developer. When the group is built, it stores the version of each package. As a user packages are then installed from this group.
Just like packages, the groups have versions. When a package is updated, the group needs to be rebuilt (with a simple command) and when i update my desktop then the package manager first checks for a new version of the group, and then finds out which packages are updated within the group.
To go back to the example, if you upgraded yesterday, and i upgrade today but i want a system identical to yours, i can ask you for the group version that you have and select that version explicitly. You can imagine how that simplifies testing. If a user has a problem, usually all we need to know is the version of the group. That alone will tell us every version of every single package that you have installed. Or consider corporate deployment. The best practice for RPM and Deb, as hinted in the article above, is to create a company internal repository where you can control exactly what versions are available, and then synchronize machines.
With Conary, all i need is the group version, or, the new system-model file.
System-model
A new update mechanism called “system model” is added. In this model, a file called /etc/conary/system-model describes what should be installed on the system. This file is modified by certain conary update commands, and can also be edited with a text editor. The system model allows a system to be updated relative to a search path that includes groups as well as labels, leading to more coherent sets of updated packages. It also allows re-starting updates with transient failures; the filename /etc/conary/system-model.next is reserved for storing the system target state during an update operation.
This ability is so significant that rpath, the company which develops Conary even offers RHEL and CentOS (and Ubuntu Server) repackaged in
Conary. (and apparently Conary is now available for Windows too) If you want to create a custom system for many machines, you can create your own group, inherit an existing group and make the necesary changes to it. A group can contain packages from multiple repositories, so there is no problem to mix and mach and still have full control over what is going on. This reduces the effort needed to create a derivative distribution by a huge amount.
Groups also help with automated rebuilds of the source. If a library is updated, then all packages that depend on that library can be rebuilt automatically with a single command.
Recipes for packages are astonishingly short. In most cases it only takes specifying of an URL and some dependencies in order to build a
package. Conary also remembers if i remove packages, even files, so when a group or a package is updated, then such removed files are not reinstalled.
The system model mode is intended to become the normal update mode for Conary-based systems in the future. It works by creating a set of troves that define the system, and then moving the system to that definition. It is conceptually similar to building a group into a repository and then migrating to that group. Significant differences include:
In a group, all trove references are absolute, but in a model,you can choose whether references are absolute. Migrating to a specific version of a group will always move the system to the exact set of packages referenced, but re-applying a system model will update troves that are not pinned down to a specific version. There is no group name for the set of troves.
There is no version for the set of troves. (The version operation in a system model does not provide conary versioning.) Path and version conflicts are not checked when assembling the set of troves. (No group policy is run at all.) This means that path and version conflicts will be found only while installing the packages.
A system model that installs only a single group will function similar to migrate mode. The most obvious difference is that migrate mode honors variations in byDefault settings in the system database(that is, an optional component of the trove(s) migrated to that has been installed on the system will still be installed after the migrate operation finishes), whereas a system model update honors those changes only if they are represented in the model itself.
Thanks eMBee & devnet for information......
Download Foresight Linux
Official iso 2.5.0
Foresight Linux GNOME Edition 2.5.0 x86
http://downloads.foresightlinux.org/gnome/2.5.0/foresight-2.5.0%2b2011.03.23-x86-dvd1.iso
Foresight Linux GNOME Edition 2.5.0 x86_64
http://downloads.foresightlinux.org/gnome/2.5.0/foresight-2.5.0%2b2011.03.23-x86_64-dvd1.iso
Foresight Linux XFCE Edition 2.5.0 x86
http://downloads.foresightlinux.org/xfce/2.5.0/foresight-2.5.0%2b2011.03.23-x86-dvd1.iso
Foresight Linux XFCE Edition 2.5.0 x86_64
http://downloads.foresightlinux.org/xfce/2.5.0/foresight-2.5.0%2b2011.03.23-x86_64-dvd1.iso
Testing iso 2.5.1 Only Gnome available
Regular users
32bit: http://www.rpath.org/downloadImage?fileId=43350
64bit: http://www.rpath.org/downloadImage?fileId=43354
Developer users (also newest packages available):
32bit: http://www.rpath.org/downloadImage?fileId=43360
64bit: http://www.rpath.org/downloadImage?fileId=43357
Testing iso 2.5.2 Gnome and Xfce iso
Developer iso, also from developer repo.
Gnome: foresight-2.5.2+2011.10.24-x86_64-dvd1.iso
Gnome: foresight-2.5.2+2011.10.24-x86-dvd1.iso
Xfce: foresight-2.5.2+2011.10.24-x86_64-dvd1.iso
Xfce: foresight-2.5.2+2011.10.24-x86-dvd1.iso
Also look at: Getting started with Foresight Linux - Part I