Mailinglist Archive: opensuse-project (194 mails)

< Previous Next >
RE: [opensuse-project] [RFC] - Attempt to build open SLES-based distro
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.


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
- 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,

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?


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

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

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? - 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, 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups