My idea is to build a SLES binary-compatible distribution completely supported by the community (and optionally supported by companies which are willing to do so) - most of you will probably see lots of similarities with CentOS in this way - And in fact: This is exactly what I intend it to be.
Why?
Another question: how ?
If you want it to be binary compatible with SLES, you will obviously need to get ahold of the source RPMs of SLES. So you need a SLES subscription.
Sorry, but this is not true. Take SLES DVD2-images - there you are. We are talking here about OSS, how do you think CentOS did it? GPL clearly states that you somehow must deliver the sources.
Do you plan to just copy over the source RPMs of SLES (including the SPs and security updates), hack the artwork, and rebuild?
No, as said before: We need to check out the license of each and every package. This actually gives the resultset of what is possible to be used. Since most of it _is_ OSS, I (at least at the moment) don't see any regulatory problems. My intention is to start with SLES11SP1 Images and work upwards. As GPL clearly states that redistribution _must_ be done (in short), updates should not be an issue. But, yes I have some SLES subscriptions, so at the moment this is not the breaking point. The short term agenda would be: - Build up secondary OBS infrastructure - Clean rebuild (non-public for the initial work) of the packages including original artwork (For example original opie rpm-rebuild results in a compile error) - Replace all Artwork, Deep check all packages - Create ISO-Builder Process - And lots of other tasks (just writing the list)
[...]
- Yes, I do know about openSUSE Evergreen, but it lacks some points I've mentioned above like "Enterprise Features", 1-on-1-("binary")compatibility with SLES and the great quality work by SUSE to get SLES certified by OEM's etc. - and no one really points its OBS tree to build against Evergreen, it points it to major channels like SLES11, SLES11SP1, oS11.4, etc.
Not having the many repositories in OBS build against Evergreen 11.1 or 11.2 is indeed an issue. But something that can be taken care of independently of your approach.
Is it about "LTS" or is it about binary compatibility? Or both?
Both.
If so, why do you want binary compatibility with SLES?
Fairly simple, if you as a system engineer want to install/upgrade/test something you traditionally test your stuff _somewhere_. _Why_ should somebody buy a SLES for such tasks? And why is it a bad idea to also be capable of using OBS SLES11-rpms on such a clone? Or let me turn this question: What is so bad about it?
- No, I do not want to work "against" SUSE or anything like
This discussion has taken place already ~ 2 years ago. I took it up to discuss this matter with Gerald Pfeifer.
The situation back then, and I don't think it has changed, is that SUSE makes a non negligible part of its income through the subscription-only licenses -- that is, just the software, without support.
I guess you are talking about the upgrade subscription, right? However, as GPL clearly states that you cannot charge anything for the Software itself, you actually pay for the "service around packaging, power, ethernet - simply infrastructure and update service".
I don't have numbers, and I don't want to, nor would I get them ;), but if there is a free of charge, binary compatible clone of SLES out there, it could potentially hurt the income of SUSE (at least as far as SLES is concerned).
Why should it? Would you just switch over to SLES? At least I wouldn't. Critical and business related systems ("production systems") should never run on such "only community-supported" OS, not even CentOS. Even Canonical provides professional support for Ubuntu - This lets them also be a viable solution - But Debian for example: Well _if_ you use Debian on production systems you traditionally have the qualified staff to handle the problem. A colleague of mine _is_ debian maintainer and I was suprised that in Etch 4.0 there was a _major_ bug with the openssl-lib in combination with perl. Bad stuff. For us not too bad, since he could get that upstream pretty fast. For customers: Have fun. With SLES and RH you have support, somebody on the phone or via mail, you have first class engineers to your availability, doesn't matter how deep you are in package "a", "b" or "c". This is the reason where I think that SLES is too cheap (just my thought). However it shouldn't be too much higher since RH offers free RHN which also gives you a brief overview of all systems managed (which can only be reconstructed with SUSE Manager (SUSE)~=Spacewalk (OSS)~=Satellite (RH)~=Red Hat Network (RHN). If I want a system to test software (before setting them up on production systems), binary compatibility is the winner. People wanting to redistribute a solid "LTS" variant of the distro they like would then probably also see SUSE more strategical. As I've been doing this business now for a while I can tell you: There are more people moving from SLES to RHEL than the other way round (And this somewhat hurts badly, really). (_Also_) one large reason is that there _is_ CentOS. Believe me, RH benefits from CentOS as well. And I guess (though I don't know) there could be a break-even on loss/profit because of it.
Gerald made it very clear that, because of those reasons, SUSE would not support such an effort in any way, at all. They probably cannot prevent it, but you get the picture.
So you might not want to "work against SUSE", but, effectively, you might actually do so.
I can understand this point. However I'm open to any discussion with any SUSE employee in this topic. SUSE shall not give support on it - but now it comes: They _could_! This is something you also won't hear from RH officially, but there is a division at Red Hat which exactly does support CentOS as well ("Professional Services"). Believe it or not. I hope a former colleague of mine (now at RH) is also reading this list - He could confirm what I'm talking about. In fact, SUSE could even have higher rates for support of this one ("if you really need it") - so you could then upsell even better. To keep this short: I've been thinking a long time about this one (really, really, really did) - and all your thoughts have bugged me more than once as well.
Personally, after that discussion and after reporting about it on the list, I opted out of that initiative because I don't want to risk a single layoff at SUSE because of something like that.
Nor would I want to do any harm. But to be clear: We are talking OSS, SUSE also profits from developers around the world as well. SUSE Manager is in fact an upstream patched Spacewalk with SUSE extensions (a bit simple, but I guess you get the point...)
I'm not saying you shouldn't, you do whatever you want, but you might want to consider what I wrote above. And maybe check back with some people (e.g. with Gerald) to have their opinion -- at least, as long as you don't want to "work against SUSE".
I clearly do. Gerald: I invite you also for a beer so we could also discuss this one... Nuremberg? Munich? You tell. Maybe cdegen is a good option as well.
that. The complete opposite is the case: Without SUSE this would not work well. In fact I really think SUSE also can profit from a community base around the SLES packages. Take a
Well, without SUSE this would not work well. So why reuse their work without them having a financial retribution? You said yourself that the subscription-only licenses are really cheap.
As I've written: They _could_ have financial retribution, if they want to - maybe not for the updates, but very much likely for support (which should be more expensive of course) and professional implementations (consultants at the customer, etc.). Yes, they are. For server-systems you just want deployed somewhere. Customers are willing to pay, this is what I can say so far. You wouldn't get the hardcore gentoo/debian-fanatics - they live in their own tombstones (just kidding) - but if customers would realize if they would have to pay more in case of something _not_ working with _no direct_ support attribution (calls, tickets, etc., typical: you broke it - you fix it stuff) - they will see the value added to SLES and still buy it. It won't be much of a difference from openSUSE in that way.
look at CentOS - Does it really hurt RHEL? I don't think so,
Ha, you don't *think* so :)
Well, I'm sorry, I don't have my crystal ball with me right at the moment, so I really _can't_ foresee the future. ;)
Look, we probably all believe that CentOS is very beneficial to Redhat. It certainly has been in the past, and people from Redhat have also been saying that off the record.
Jup. Agree.
*But* there is no proof whatsoever that it has been the case, or that it would be the case for an "open SLES clone". No proof, no numbers, nobody can tell.
Well, why should they have a problem? http://linux.slashdot.org/comments.pl?sid=349751&cid=21234239 - ok - yes - 4 years ago - but what should have changed since then? RH is just like SUSE a company not just investing as also taking profit from the whole open source model. I agree: Nobody can tell for real, since we simply don't have the possibility to take a look at parallel timelines for specific events .... ;)
And, actually, nowadays, Redhat isn't really all that fond of CentOS anymore.
Well, as far as I've been working with them I can simply say: They tolerate each other very well, since (please read the link in terms of "Gateway drug"). They might not never communicate on their relationsship to each other deeply, but I guess tolerating each other (now over YEARS) is not a bad thing. _If_ RH would have had any problems with CentOS in the past I think they would have done something. In fact I never heard some RH associate speaking bad about CentOS either behind the doors or in front of a customer. And RH being also willing to support CentOS ("in extreme cases" or "more expensive" or "only through professional services") is something which is a good model.
at least not to a major extent. Lets get the facts straight: If you are in a corporate environment you _will_ (or at least you _should_) buy a SLES. Reasons: Support, Updates, Faster upstream process, tracking, direct contact, etc. But: If you want to build a steady home system which you do not want to upgrade less than every year in a major way or you might want to build a distro fork for special purpose (like for system integrators, etc.) you (probably) wouldn't want to go with the fully blown SLES.
Why binary compatibility with SLES then ?
As I've written: Appliances, Release Cycle, Perfect Test-Platform, and some other reasons as well.
- Yes, I see this as lots of work. Please let me know if you are willing to help. ;)
Do you believe it is more work than Evergreen ? Or less ?
(Re-)Building SLES "from scratch" is by far way more work. Especially when you want to provide ISO's with some installer, etc. You need to repackage everything, Evergreen is so far more "value added", not base.
Don't you think that, instead, contributing to Evergreen has at least the potential of creating much more synergies, as it is part of the openSUSE project, on the same infrastructure as the rest of the project (build.o.o) ?
("Sorry Wolfgang"): Take a look at Evergreen, if this would have been accepted that much, this wouldn't only be a one-man-show, and he would have received way more support for this.
I know very well that the current situation of Evergreen is not all that great, because there are barely any people who are contributing to it (and kudos again to Wolfgang). Why would that be different with a fork of SLES ? Why not, instead, try to revigorate Evergreen and contribute there ?
see above.
If you create a fork of SLES, you will not be able to use build.opensuse.org, and you probably won't be able to even _link to it.
hmmm... this one really freaks me out. Since when...? In OBS I can see Debian, Fedora, Red Hat, Mandriva, <you name it>. Why whould a natively compatible distro be handled so differently? - mike -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org