On Fri, Dec 10, 2004 at 12:50:13PM +0100, Michael Banck wrote:
*** The interested parties of the LCC should pick Debian as a base and
Debian should make this possible. ***
Rather than everybody just throwing all their stuff in together and
mixing it up.
Of course, this would also mean for
Hello Debian developers,
It seems to me than one of the main value of Debian is in the quality of
its core distribution. One of the reason of the quality is that it
is not developed for itself but as a platform for the 10^4+ packages
and the 10+ architectures in Debian. For example the compiler
On Friday 10 December 2004 15.35, Steve Langasek wrote:
we don't exactly have a strong history of being able to pull off
timely releases
Did Debian even try?
I didn't follow the woody release too closely, being a Debian newbie at the
time, so I don't know. But - this was my impression - from
Hi,
* We should commit to strict release cylces of a base system others
(and Debian itself) can build value upon.
* We should proabably also commit to a set of core architectures which
*need* to be bug-free on release, while the rest *should* be, but
would not delay the
On Thu, 09 Dec 2004 13:59:10 -0500, Jim Gettys [EMAIL PROTECTED] wrote:
That being said, certainly UNIX's disunity was a major aid to Microsoft.
Repeating that history would not be good.
I must agree with Jim. From the stand-point that Debian is losing
developers to other Linux platforms and
On Fri, Dec 10, 2004 at 04:04:22PM +0100, Bill Allombert wrote:
As a practical matter, what if the Debian gcc team decide to release
etch with gcc 3.3 because 3.4 break ABI on some platforms and gcc-4.x is
not stable enough on all the platforms ? Will LCC follow ? If not, how
are we going to
Adrian von Bidder dijo [Fri, Dec 10, 2004 at 04:38:10PM +0100]:
we don't exactly have a strong history of being able to pull off
timely releases
Did Debian even try?
I didn't follow the woody release too closely, being a Debian newbie at the
time, so I don't know. But - this was my
On Fri, Dec 10, 2004 at 04:38:10PM +0100, Adrian von Bidder wrote:
On Friday 10 December 2004 15.35, Steve Langasek wrote:
we don't exactly have a strong history of being able to pull off
timely releases
Did Debian even try?
No, not since I've been around.
I didn't follow the woody
On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote:
The main technical effect that I see would be that the names of some
dynamic libraries would change. And compatibility with the old names
could be maintained indefinitely if necessary.
?!??!?!?!?!?!?!PO!(*!$*_(!$*($*!(*$_*!*$(
That is
Hi everyone,
Let me first say unequivocally that the LCC is very interested in
getting Debian involved. The question has always been: How do we do
that? It's one thing for a bunch of companies that can push down
decisions from the top and that already have a great deal in common
(Red Hat lineage,
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
There's only one preconceived notion: that we need a single set of
binaries, because that's what ISVs and IHVs require for the result to be
viable. The LCC doesn't mandate the use of RPM (only to the extent the
What makes you think
On Thu, 2004-12-09 at 09:07 +0100, Scott James Remnant wrote:
On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote:
The main technical effect that I see would be that the names of some
dynamic libraries would change. And compatibility with the old names
could be maintained indefinitely
William Ballard wrote:
What makes you think you'll be any more successful than when the Unix
Consortium tried to do the same thing for Unix?
The members considered that they had proprietary value at the level at
which they were collaborating. We conclusively do not, because of the
Open
Bruce,
The history there is much more complex that that; you are
oversimplifying. In fact, with my perspective, the failure occurred
before that, but (un)intended consequences of the Consortium agreement,
which disenfranchised the flourishing community we had built. Pay for
say, and centralized
Jim Gettys wrote:
Pay for say, and centralized development teams funded by such payers, are a major trap.
Let's make sure to keep giving OSDL that message.
Thanks
Bruce
smime.p7s
Description: S/MIME Cryptographic Signature
Name changes are a superficial design flaw that obscures the
fundamental design flaw in this proposal -- sharing binaries between
Linux distributions is a bad idea to begin with.
Fixing ABI forks, and articulating best known practices about managing
ABI evolution going forward, that's a good
Michael K. Edwards wrote:
Fixing ABI forks, and articulating best known practices about managing
ABI evolution going forward, that's a good idea. Building an open
source test kit that exercises the shared ABIs, validating that the
test kit builds substantially the same on each distro, and helping
companies
to run away with commercial Linux via ISV/IHV certification lock-in.
Disclaimer: I have not gone looking for any information about the Linux
Core Consortium outside of this thread. It would have been nice to
include a link:
http://www.mandrakesoft.com/lcc
Of course, there's not much
On Dec 09, Ian Murdock [EMAIL PROTECTED] wrote:
Let me first say unequivocally that the LCC is very interested in
getting Debian involved. The question has always been: How do we do
that?
As usual: by sending patches.
How does Debian benefit from LCC? It's a route to the ISV and IHV
On Thu, 2004-12-09 at 11:23 -0800, Michael K. Edwards wrote:
Name changes are a superficial design flaw that obscures the
fundamental design flaw in this proposal -- sharing binaries between
Linux distributions is a bad idea to begin with.
Fixing ABI forks, and articulating best known
Daniel Jacobowitz writes:
Using binaries from LCC would also run against the Debian principle of
always building Debian packages from their source before uploading them.
That's a big deal.
Big enough that I think common binaries should be completely out of the
question for that reason alone.
On Thu, 2004-12-09 at 21:17 +0100, Marco d'Itri wrote:
On Dec 09, Ian Murdock [EMAIL PROTECTED] wrote:
Let me first say unequivocally that the LCC is very interested in
getting Debian involved. The question has always been: How do we do
that?
As usual: by sending patches.
So, the flow
If ISVs want exactly the same, they are free to install a chroot
environment containing the binaries they certify against and to supply
a kernel that they expect their customers to use. That's the approach
I've had to take when bundling third-party binaries built by people
who were under the
|| On Thu, 09 Dec 2004 15:51:15 -0500
|| Ian Murdock [EMAIL PROTECTED] wrote:
And which I doubt we will get with LCC, since the kernel is the most
important piece which needs to be certificated.
im The common core will include a common kernel. See the FAQ at
im
- or will.
What are they doing about them?
Well, for one, we're trying to open a dialog with the Debian
community. :-)
Are the other companies listed as supporting the Linux Core
Consortium interested in this common binaries plan? Their support
quotes only explicitly support the Linux Standard Base
The most high and most honorable Ian Murdock wrote:
Hi everyone,
Hi Back at you.
Let me first say unequivocally that the LCC is very interested in
getting Debian involved. The question has always been: How do we do
that? It's one thing for a bunch of companies that can push down
decisions
Ian Murdock [EMAIL PROTECTED] writes:
On Thu, 2004-12-09 at 09:07 +0100, Scott James Remnant wrote:
On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote:
The main technical effect that I see would be that the names of some
dynamic libraries would change. And compatibility with the old
On Thu, Dec 09, 2004 at 04:42:29PM -0500, Ian Murdock wrote:
Second, the common core will have a release schedule corresponding to
the release schedule of the LSB standard (roughly every 12-18 months),
and the members' release schedules will be synchronized to match that.
So given that
Ian Murdock [EMAIL PROTECTED] writes:
On Thu, 2004-12-09 at 21:17 +0100, Marco d'Itri wrote:
On Dec 09, Ian Murdock [EMAIL PROTECTED] wrote:
How does Debian benefit from LCC? It's a route to the ISV and IHV
certifications that Debian has always lacked, and it is the lack of
And which I
Greg Folkert wrote:
I will strongly oppose any shared binaries. I don't want any RPM shoved down my
throat.
One is not equal to the other. It's entirely possible to have a single
package source that builds into both RPM and DEB.
I would like to use see a shared usage of the same Source Core
Steinar H. Gunderson wrote:
So given that Debian's release schedule once again slips past 18 months, do
we have to wait another 18 months to get etch out?
I don't see why, we don't do that for X or GNOME or anything else.
But some of us don't want to see Debian's release schedule slip again. I
Patrz w ekran, a to Goswin von Brederlow pisze do mnie:
Don't get me wrong, I think a common kernel would be great. I just
don't think Debians standards will go well with the commercial
distributions.
Not necessary. If the common kernel would not suit best for the debian it
would always be
On Thu, Dec 09, 2004 at 02:25:28PM -0800, Bruce Perens wrote:
So given that Debian's release schedule once again slips past 18 months, do
we have to wait another 18 months to get etch out?
I don't see why, we don't do that for X or GNOME or anything else.
Then I don't see what you mean by
Steinar H. Gunderson wrote:
Then I don't see what you mean by synchronization.
You use the LCC version available to you at the time you release,
whatever that is. It may make sense for you to schedule your release to
come some months after the LCC's, but I can't see that you have to do
On Thu, 2004-12-09 at 14:33 -0600, John Hasler wrote:
Daniel Jacobowitz writes:
Using binaries from LCC would also run against the Debian principle of
always building Debian packages from their source before uploading them
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
I can imagine many of you are thinking, What difference does it
make if Debian has the support of proprietary software vendors?
Ok. If attracting ISV and IHV support to Debian isn't a worthwhile
goal in itself, how about helping
On Thu, Dec 09, 2004 at 03:10:52PM -0500, Daniel Jacobowitz wrote:
We would never have a common kernel with these vendors anyway - they
No does Debian with itself :P
On Thu, Dec 09, 2004 at 02:33:30PM -0600, John Hasler wrote:
Why don't standard ABIs suffice?
Not that I'm necessarily arguing in favour of a set of common packages, but
defining an ABI is not a sufficient condition to ensure compatibility.
Consider a function int s(int, int) -- you can have
On Thu, Dec 09, 2004 at 03:51:15PM -0500, Ian Murdock wrote:
The common core will include a common kernel. See the FAQ at
http://componentizedlinux.org/lsb/: Importantly, the LCC platform
will include a common kernel, eliminating one of the largest sources
of incompatibilities between Linux
Matthew Palmer writes:
Consider a function int s(int, int) -- you can have two ABI-compatible
versions of this, one that adds it's arguments and one that multiplies
them. ABI compatible, but different results.
And different APIs. Is that really a serious risk?
...who's to say that some
On Thu, 09 Dec 2004 17:20:00 -0600, Ron Johnson [EMAIL PROTECTED] wrote:
libfoo 1.7 fixes a non-security bug in v1.6. bar segfaults when
running libfoo 1.6. But libfoo 1.6 is in Sarge, and the bug won't
be fixed because it's not a security bug.
Having a formal GNU/Linux Distro Test Kit
Bruce Perens [EMAIL PROTECTED] writes:
You use the LCC version available to you at the time you release,
whatever that is. It may make sense for you to schedule your release to
come some months after the LCC's, but I can't see that you have to do
everything modulo 18 months.
I think this is
On Thu, Dec 09, 2004 at 07:08:48PM -0800, Russ Allbery wrote:
Bruce Perens [EMAIL PROTECTED] writes:
I think that tying core Debian packages to the Red Hat boat anchor is a
horrible, horrible idea.
I tend to agree with sentiments like this, but didn't Bruce mention
that we could participate
On Thu, Dec 09, 2004 at 04:42:29PM -0500, Ian Murdock wrote:
On Thu, 2004-12-09 at 15:10 -0500, Daniel Jacobowitz wrote:
As one of the maintainers involved in Debian's toolchain, I think this
is a terrible idea. Our needs are different than other distributions,
we already know that from
John Goerzen dijo [Thu, Dec 09, 2004 at 09:40:51PM -0600]:
I think that tying core Debian packages to the Red Hat boat anchor is a
horrible, horrible idea.
I tend to agree with sentiments like this, but didn't Bruce mention
that we could participate in this organization even if we didn't
Ian Murdock dijo [Thu, Dec 09, 2004 at 04:42:29PM -0500]:
We would never have a common kernel with these vendors anyway - they
don't even have a common kernel with each other. My experience tells
me that would be a big barrier to certification of any kind.
The LCC core will include a
Greg Folkert wrote:
Many reasons people come to Debian... Distributed Binaries is not one of
them.
If you think this isn't a reason to use Debian, I, as a long-time user, will tell you that
you're dead wrong. I use Debian because there exist packages for most every popular piece
of free software
The Linux Core Consortium would like to have Debian's involvement. This
organization has revived what I originally proposed to do as the LSB -
to make a binary base for Linux distributions that could be among
several distributions who would share in the effort of maintaining
certain packages
On Wed, Dec 08, 2004 at 02:59:10PM -0800, Bruce Perens wrote:
The main technical effect that I see would be that the names of some
dynamic libraries would change. And compatibility with the old names
could be maintained indefinitely if necessary.
How in the world does changing the names of
On Wed, 08 Dec 2004, Steve Langasek wrote:
On Wed, Dec 08, 2004 at 02:59:10PM -0800, Bruce Perens wrote:
The main technical effect that I see would be that the names of some
dynamic libraries would change. And compatibility with the old names
could be maintained indefinitely if necessary.
Steve,
Henrique answered your question. There has been some divergence between
various distributions regarding the naming and especially the
versioning of these libraries. We would heal that fork to increase
compatibility. Doing that means that some names and version tags are
going to change
Bruce,
On Wed, Dec 08, 2004 at 04:49:13PM -0800, Bruce Perens wrote:
Henrique answered your question. There has been some divergence between
various distributions regarding the naming and especially the versioning
of these libraries. We would heal that fork to increase compatibility.
* Bruce Perens ([EMAIL PROTECTED]) wrote:
Henrique answered your question. There has been some divergence between
various distributions regarding the naming and especially the versioning
of these libraries. We would heal that fork to increase compatibility.
Doing that means that some names
On Wed, 2004-12-08 at 17:41 -0800, Steve Langasek wrote:
Bruce,
On Wed, Dec 08, 2004 at 04:49:13PM -0800, Bruce Perens wrote:
[snip]
I'm skeptical to begin with of the benefits LCC has to offer Debian -- being
bound not just to an external *standard*, but to an external
*implementation*
Steve Langasek wrote:
Changing library *names*, OTOH, is something quite different -- and in the
first case, providing "compatibility with the old names" totally defeats the
purpose of *having* sonames, whereas in the second case, it still sounds
like gratuitous change to me.
Steve,
I
101 - 155 of 155 matches
Mail list logo
