Everyone can easily create his own version of Fedora with the re-spin tool Revisor. OpenSuse also develops a tool with a similar purpose, KIWI.
The idea of creating customized versions of an existing distribution is not new, but Fedora 7 took this idea to a next level by introducing an easy-to-use GUI and a wizard-like walk through for the single steps in the form of Revisor.
A similar GUI was now developed for OpenSuse’s tool KIWI. As Revisor KIWI is mainly developed to produce re-spins in various forms. While it is said to be distribution independent it is mainly used for OpenSuse. The best known application yet is arguable the KDE Four Live spin featuring an OpenSuse with a recent KDE 4 svn version installed.
Now the first screenshots of a GUI (in early development ) were revealed. Everyone who is used to Yast will feel at home immediately as it looks like.
Nice to see that other distributions plan to give their users similar possibilities as Revisor gives. Also, this competition shows the parts where Revisor could be extended. For example I pretty much like the idea that the OpenSuse installer can create images for a variety of virtual machines: Xen, VMware and Qemu (I miss virtual box here!).
Combined with some kind of automatic build system every developer could distribute test images for virtual machines to test new introduced features or changes. That would make testing much easier since no one would have to change a running system.
The next step would be to be able to create system snapshots out of an existing machine – PCLinuxOS supports this with the help of a Debian script afaik. That makes it even easier to distribute specific, dedicated appliances.
/home/liquidat 
NIH strikes again. 😦
I’ve seen a lot of NIH going on between Fedora and OpenSUSE lately: depsolver NIH, build system NIH, respin tool NIH. It’s a bit sad that even though they’re solving the exact same problems at essentially the same time, they’re not solving them together.
there’s been a workshop between fedora and suse at linuxtag this year including max spevack and others. I may be mistaken but I think this workshop was exactly about working more closely together in the future. they even showed their build systems to each other afaik.
we’ll see what’ll happen in the future.
Kevin: While I do agree that there is much too much “not invented here” in the area of important system tools (init system improvement, system control tools, etc.) I doubt that this re-spin technique is that important.
The re-spin tools are simple applications like screen recorders. nothing more. You usually don’t build upon them, so it doesn’t matter how many there are or how much fragmentation you have.
What’s even sadder is that this is all about 1.5 years behind the concept that rPath has been pioneering with rBuilder Online. The difference is that while forked distros from Fedora and OpenSuse would be nice for having people spin a distro…once they fork, they have to keep up with updates upstream and most of the time, they won’t give back to Fedora as a whole or OpenSuse as a whole. Using conary has HUGE benefits over this type of model since a fork allows contribs to flow both upstream and downstream and everyone benefits…more forks = better.
devnet: The main topic this post covers is the GUI which was now added – does rBuilder feature such a GUI?
I would love to test out rPath (read lots about it), but at the moment I’dont have the hardware to do so at all – because of KDE 4 svn my laptop hard disk is running out of space…
FYI, Mandriva has its (own, once again) tool for this called “draklive”.
But afaik draklive also does not feature a GUI – that was the new information about KIWI.
From what I’ve seen KIWI has a far larger range of capabilities (both in design and in current implementation), but one thing to note is that KIWI (just like the openSUSE Build Service and other tools openSUSE make) is by no means distro-specific. In fact, openSUSE go out of their way to make things such as the OBS and KIWI non-distro specific (i.e. OBS allows builds of Mandriva, Fedora, Debian etc).
Similarly with KIWI, it works with Smart package management (http://smartpm.org) which is a package management tool supporting virtually all metadata formats (debian’s pool, yum metadata, yast2 metadata, local RPM dirs, etc).
Furthermore, the plan with KIWI is to also integrate it with the build service. So you can roll your own ISOs or images (live, qemu, vmware, etc) directly from the website. This is really fantastic news, and quite an exciting project.
As Francis put is so well, comparing KIWI with simple tool like revisor doesn’t even start to describe what KIWI can do.
It creates following images for technically any Linux distribution:
Live
Xen
VMware
Qemu
PXE Installation images of all types (Thin clients/Fat clients)
Network Installation Source
LTSP5 chroot image
If you ask me, two most innovative technologies for Linux in recent times are KIWI and Compiz/Xgl thanks to great SUSE engineering teams.
CyberOrg: First of all regarding the GUI part Revisor has more to offer because that GUI is already available and tested, while the KIWI GUI is in a very early development state. Still, I did mention in the post that KIWI has more functions to offer in the way which outputs can be created.
Second, while I do appreciate the Compiz/Xgl development very much the base technology of today and tomorrow at least is not Xgl, which was more a proof-of-concept, but AIGLX, which was mainly driven by Red Hat.
Francis: I know the OBS pretty well – simply check for related articles here at this blog. However, the OBS is only partially distribution “independent” in the way of providing packages for more than one distribution.
Also, I *did* mention in the post that Kiwi is theoretically distribution independent – but at the moment there are only OpenSuse packages available (actually there are not even source packages available, but SVN access), and there is no information at all available how to set up KIWI on other distributions.
For both of you: please point me to a Howto ro an experience report how KIWI was run on other distributions – I would like to read it.
Hi
I apologise if you felt my response felt harsh, just pointing out the capabilities of KIWI, and answering some posts that seemed to have misunderstood the purpose of KIWI.
I thank you for getting the news about this technology to everyone, that is one of the way developers from other distributions may pick up the KIWI code and get it working on their distro and also write a documentation that will enable users to get this wonderful tool.
Cheers
-J
Cyberorg, I didn’t take your response harsh, don’t worry. I just wanted to make my point clear 🙂
> However, the OBS is only partially distribution “independent” in the way of providing packages for more than one distribution.
Even if this was only the case it would still be pretty awesome in-and-of-itself. Having a full and open build system is incredibly difficult (hence virtually no other distribution has a similarly free and open one), but getting packages built for multiple distributions and versions is anything but a trivial task.
Even so, the openSUSE Build Service (the software for it) _is_ available and working for all distributions. In fact, openSUSE even package it for all those other distributions. See http://software.opensuse.org/download/openSUSE:/Tools/
With respect to KIWI, I was suggesting that it was technically possible (and an eventual goal) to get it working for all distributions, as you said as well. That’s why specifically work started with the Smart package manager (supporting virtually all metadata formats), instead of just using libzypp which SUSE developers created and maintain themselves.
Revisor will certainly be more tested and stable, but even so — the YaST GUI for KIWI, even now, has a lot more capabilities. Selecting different patterns (selections/groups of packages) is so trivial, and even there you can easily select a qemu image, live usb, etc. You can also create the fileystem tree instead to i.e. change your default background, change any other configurations, and then generate the image. You are completely right that it is still in development however. Hopefully we’ll have some good, very stable stuff to show for 10.3 🙂
Even if you dismiss Xgl as not being THE solution (as Zack famously said), it would be odd to undermine its influence, or even to undermine the play of Compiz in the OSS world (even now). This is really exciting stuff. KDE’s composite manager, kwin_composite, is also likely to be the eventual technology of KDE and even that’s being developed primarily by an openSUSE developer.
Francis: Thanks for the information, I didn’t now that OBS repository, looks interesting.
And I do know how difficult it is to build distribution independent packages – therefore the OBS is an awesome tool, and I would really wish more people would start using it to create packages.
However: the OBS has the same problem as all other solutions available today: you can only provide so many different distribution packages. There is no real distribution independent way, except maybe for LSB-RPM, which have their own problems.
For me the gold solution would be creating single packages in the way the LSB once suggested, with a shared packager API. But that’s not realistic atm., sadly.
But please understand that this is nothing against the OBS – I wrote much too many posts and howtos about the OBS to not like it. Acutally, since there are now the packages available, I might try to test it with some of the packages I build for Fedora… Is there a irc channel somewhere where I can get help?
About Xgl, again, please understand that I do like it, and that I do think it was revolutionary and a very important thing when it was released. It is certainly one of the most important FLOSS releases of that year! I just added that Xgl was from the beginning planned as a technical experiment to show what could be possible.
And of course Compiz is *the* composition manager today on Linux desktops. I never said anything else!
I did not try to undermine that, and I don’t want to.
Again, I wrote much too many posts about these technologies, the possibilities and even how to install them on other systems.
I have the feeling that you think I have something against OpenSuse – I’m far away from. I wrote many important howtos for OpenSuse 10.0 and 10.1 and wrote background articles about the different software managers available in both (which were many). Also, (afaik) I was the first one who wrote an article how to set up the alternative software managers yum and smart up on these systems, and even when I switched back from Suse to Fedora I continued writing articles about OpenSuse, helped Ted with some things (and was rewarded with an SLED licence for free, btw.), wrote about the OBS, made screenshots series of Xgl, wrote a *very* popular review of iFolder, and so on.
I hope this clears out some misunderstandings 🙂
I concur with all your sentiments about the package management situation in Linux.
> Acutally, since there are now the packages available, I might try to test it with some of the packages I build for Fedora… Is there a irc channel somewhere where I can get help?
You can apply for an account right now! It should be approved pretty soon (give enough information in the description), and then you can start building packages for any/all distributions.
There’s the #opensuse-buildservice channel which is frequented by some of the openSUSE developers where you can get the additional help; even more so on the opensuse-buildservice mailing list; check http://lists.opensuse.org. Information on http://opensuse.org/Build_Service should also be of help. There’s also a decent vmware image floating around with the build service which you might like to play with. See http://lists.opensuse.org/archive/opensuse-buildservice/2007-06/msg00021.html
I’m sorry if it came across in any way that I thought you had a negative attitude to openSUSE. My thoughts were far from it! I regularly enjoy the well-informed articles written from you on Linux (and openSUSE in particular), so thank you very much on that front :).
Thanks for the links!
At the moment I’m tempted to start experimenting with the VMWare image to see how the entire system works and how difficult it is to set it up for example on my own machine. But we’ll see, I keep you up2date 🙂