Re: Cross-distro binary compatibilty
On Sun, Jul 10, 2005 at 10:12:57PM -0400, Adam Skutt wrote: > Chris Bannister wrote: > > > > (sticks hand up from back of room) PostgreSQL OSS alternative for > > Oracle? > > > In some cases, yes. But not in a whole host of others. > > PostgreSQL is not as scalable or as fast as Oracle on the high-end. > > It's also lacking some features needed for dealing with really massive > datasets. > > There is no true OSS equivalent to the likes of Oracle and DB2, and it's > likely there will never be, unless one of them becomes open-source. After a quick search through the postgresql-doc package I found postgresql-doc/TODO.detail/performance.gz which compares Oracle + PostgreSQL. Thanks. -- Chris. == Reproduction if desired may be handled locally. -- rfc3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cross-distro binary compatibilty
Chris Bannister wrote: > > (sticks hand up from back of room) PostgreSQL OSS alternative for > Oracle? > In some cases, yes. But not in a whole host of others. PostgreSQL is not as scalable or as fast as Oracle on the high-end. It's also lacking some features needed for dealing with really massive datasets. There is no true OSS equivalent to the likes of Oracle and DB2, and it's likely there will never be, unless one of them becomes open-source. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cross-distro binary compatibilty
On Sat, Jul 09, 2005 at 10:52:57PM +0200, Thomas Steffen wrote: > Oracle > > I agree that some of them do show the typical problems of closed > software, but still they do something for which there is no equivalent > OSS alternative. (sticks hand up from back of room) PostgreSQL OSS alternative for Oracle? -- Chris. == Reproduction if desired may be handled locally. -- rfc3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cross-distro binary compatibilty
On 7/7/05, Adam Stiles <[EMAIL PROTECTED]> wrote: > As I've said before, binary compatibility is irrelevant. You have said it before, but that doesn't make the generalisation any more true. Binary compatibility is essential for most computer users, and even for most Linux users. The following binaries immediately spring to my mind: ATI graphics driver Acrobat Reader Realplayer WMV decoder Flash plugin Inter C compiler Sun JRE Opera VMware Matlab Oracle I agree that some of them do show the typical problems of closed software, but still they do something for which there is no equivalent OSS alternative. > The only reason why you would ever want to be able to run a binary not > compiled by you is if you did not have the source code; and if you don't have > the source code, it's probably because someone doesn't want you to have it. True. > If somebody doesn't want you to have the source code, then there is probably > something in it that they are ashamed to show you. That is only the paranoid explanation. The normally cited reason is that they have developed the source code, so they keep it as a means of power. Since power is money, that makes perfect sense. > I won't run software written by cowards. If there is no way to accomplish a > task using purely Open Source tools, then I'll do it by hand -- or create a > new tool and make it Open Source. Then I guess I will be to busy during the next few years to post here... :-) But I still think that the binary compatibility could be reached by a flexible extension of ld.so and libdl. rpath is the main annoyance, but it should be possible to relax the interpretation of rpath. And libdl needs more flexibility anyway. Thomas
Re: Cross-distro binary compatibilty
Adam Stiles wrote:
> As I've said before, binary compatibility is irrelevant.
No, it isn't. If it were, then why does everyone spend so much time
worrying about? And I do literally mean everyone, both within and
beyond the OSS community.
In fact, from a
> security point of view, binary _in_compatibility -- to the point where
> binaries compiled on one box would not run on any other box -- might be
> desirable, then there could never be such a thing as a virus.
This kind of nieve thinking doesn't help you.
The Apache slapper worm attacked a vulnerability in OpenSSL, a library
notorious for it's ABI-incompatilibites and managed to sucessfully
trojan a entire rash of boxes.
So no, there will still be plently of viruses.
> {Obviously
> some sort of compatibility mode would be required for initial bootstrapping
> of a system, but access could be restricted by means of something like a
> motherboard jumper, that could not be defeated by software alone.}
And just how is that going to modify the binary code provided on a CD?
> Source
> compatibility is all that really matters, and there are enough examples
> around to show that this is entirely achievable.
Yet it's not as interesting as ABI compatbility. API compatibility is
pretty easy to maintain. ABI is not. ABI is also more desirable.
ABI compatability is how KDE code from 3.0 can still run on 3.4 today.
That's a desirable thing, because it means I don't have to keep my
application up with the KDE developers if I don't want to.
ABI compatability is how programs written from kernel 2.0-era can still
run on a 2.6 kernel today, without any changes. That's also desirable.
And I'm not just talking
> about compatibility across different versions of the same distro, or even
> different Linux distributions; but Linux, the BSDs, Solaris and legacy
> systems too.
Then you don't know what you talk about. No UNIX is 100% API compatable
with any other UNIX or UNIX-alike, even along the lines of SUS and POSIX.
If you don't believe me, go look at the code for tcpdump. Or at the
Apache Portable Runtime.
> The only reason why you would ever want to be able to run a binary not
> compiled by you is if you did not have the source code; and if you don't have
> the source code, it's probably because someone doesn't want you to have it.
That's not true. Stop being so simple-minded.
What if I have 2000 webservers? Why should I take the time to compile
source on each one? Or take the time to compile the source on one box
and /distribute/ the binaries? Especially when we have groups of people
who do that, who produce products called Linux distributions.
And odds are, for any given piece of software, they're going to a better
job of packaging it up and resolving issues than any individual person
can. Doing things like more widespread testing, keeping abreast of
development issues and bugs, providing patches, and the like.
Something most people don't have time to do. Certainly something that's
just not acceptable in a production environment, where downtime == money
lost.
> If somebody doesn't want you to have the source code, then there is probably
> something in it that they are ashamed to show you.
That's simply not the case. What if the source code contains a nifty
algorithm I don't want anyone to have? What if it contains
trade-secrets that make my business process really efficent?
There are plenty of valid reasons to not want someone to have access to
your code.
Please, go read some books on software engineering, configuration
management, and quality assurance before spouting anymore of what
amounts to simple-minded nonsense. You clearly haven't considered even
remotely enough cases to give any of your suggestions merit.
Adam Skutt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cross-distro binary compatibilty
On Thu, Jul 07, 2005 at 04:56:31PM +0100, Adam Stiles wrote: > As I've said before, binary compatibility is irrelevant. In fact, from a > security point of view, binary _in_compatibility -- to the point where > binaries compiled on one box would not run on any other box -- might be > desirable, then there could never be such a thing as a virus. You're naive. Binary incompatibility won't stop macro viruses (and users _do_ want their shiny macros work when they move a document from one machine to an other). Also, AFAIK the world's first internet worm spread partly as C source code and compiled its bootstrap code on the target machine... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cross-distro binary compatibilty
Adam Stiles wrote: > As I've said before, binary compatibility is irrelevant. > [...] > Source compatibility is all that really matters, and there are > enough examples around to show that this is entirely achievable. > [...] > The only reason why you would ever want to be able to run a binary > not compiled by you is if you did not have the source code; Oh, sigh. You are forgetting two things. One is that Debian is a binary distribution, not a source distribution. (Of course two notable source distributions are Linux from Scratch and Gentoo. But Debian is neither of those.) > and if you don't have the source code, it's probably because someone > doesn't want you to have it. If somebody doesn't want you to have > the source code, then there is probably something in it that they > are ashamed to show you. > > I won't run software written by cowards. If there is no way to accomplish a > task using purely Open Source tools, then I'll do it by hand -- or create a > new tool and make it Open Source. The other thing is that an operating system is a very general purpose tool. It is not just this one thing or that one thing. An OS is many things and an enabler for many things. Section 5 of the Debian Social Contract[1] was written specifically with non-free software in mind. "We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines." And "We will not object to non-free works that are intended to be used on Debian systems" Bob [1] http://www.debian.org/social_contract signature.asc Description: Digital signature
Re: Cross-distro binary compatibilty
On Thursday 07 July 2005 15:21, Bob Proulx wrote:
> David Wood wrote:
> > On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
> > >If you don't do that you can also claim that SuSe isn't SuSe
> > >compatible as you can have exactly the same version/package skews
> > >within one distro.
> > You're right of course - even within a distro, binary compatibility isn't
> > really that great.
> Even the ones that pick rpm don't have a coherent policy document.
> This hampers compatibility considerably.
Certain distributions (*cough* Redhat *cough*) are renowned for patching
their kernel and libraries almost beyond recognition.
As I've said before, binary compatibility is irrelevant. In fact, from a
security point of view, binary _in_compatibility -- to the point where
binaries compiled on one box would not run on any other box -- might be
desirable, then there could never be such a thing as a virus. {Obviously
some sort of compatibility mode would be required for initial bootstrapping
of a system, but access could be restricted by means of something like a
motherboard jumper, that could not be defeated by software alone.} Source
compatibility is all that really matters, and there are enough examples
around to show that this is entirely achievable. And I'm not just talking
about compatibility across different versions of the same distro, or even
different Linux distributions; but Linux, the BSDs, Solaris and legacy
systems too. {Of course, there are examples of badly-written software out
there too. It's interesting that the worst offenders -- Mozilla and
OpenOffice -- actually started out as closed-source.}
The only reason why you would ever want to be able to run a binary not
compiled by you is if you did not have the source code; and if you don't have
the source code, it's probably because someone doesn't want you to have it.
If somebody doesn't want you to have the source code, then there is probably
something in it that they are ashamed to show you.
I won't run software written by cowards. If there is no way to accomplish a
task using purely Open Source tools, then I'll do it by hand -- or create a
new tool and make it Open Source.
--
AJS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cross-distro binary compatibilty
David Wood wrote: > On Wed, 6 Jul 2005, Goswin von Brederlow wrote: > >Go to snapshot.debian.net and fish out the right library versions > >suse/rh uses, install them, install the same packages (inetd/xinetd) > >suse/rh uses and voila. Compatibility. > > Even if libraries were the only issue, aren't there times when the right > version (or lib altogether) isn't packaged? And what about the effects of > "distro-proprietary" patches to important things (we've seen it all, from > major tweaks to gcc, to important paths changing)? Yes, and yes. Most of the time I can find the right libraries. But sometimes I have to get the actual other-distro library for some compatibility problem. As far as distro specific patches one of the worst in my experience was RH glibc-2.2.4 which had patches that required glibc-2.3.1 in Debian before programs needing it were completely happy. > In any case the user must figure out whatever dependency is broken, figure > out what satisfies it, go to snapshot.debian.net... etc. It is > time-consuming and impractical. Most users are excluded. In an non-software engineering lab of about 400 people there are about three of us there that routinely do this task. The others think it is too hard, won't try or give up, and ask to be converted to some other distro in order to run the app they want. That is a fairly high tech community and I would expect more people would be able to do this chasing down of dependencies. But apparently not. > >If you don't do that you can also claim that SuSe isn't SuSe > >compatible as you can have exactly the same version/package skews > >within one distro. > > You're right of course - even within a distro, binary compatibility isn't > really that great. Even the ones that pick rpm don't have a coherent policy document. This hampers compatibility considerably. > So here we have the schizophrenia of our community with relation to binary > distribution. On the one hand we sometimes casually claim that it works, > and we sometimes expect it to work. When the rubber hits the road it > becomes obvious that it's both ugly and impractical for users/developers. > Then the story switches to others saying that we are an FS/OS community, > and asking "what are you doing distributing binaries anyway?" Later you > hear that we're really only geared towards source distribution (for > distro-independent developers). Agreed. Bob signature.asc Description: Digital signature
Re: Cross-distro binary compatibilty
On Wed, 6 Jul 2005, Goswin von Brederlow wrote: Go to snapshot.debian.net and fish out the right library versions suse/rh uses, install them, install the same packages (inetd/xinetd) suse/rh uses and voila. Compatibility. Even if libraries were the only issue, aren't there times when the right version (or lib altogether) isn't packaged? And what about the effects of "distro-proprietary" patches to important things (we've seen it all, from major tweaks to gcc, to important paths changing)? In any case the user must figure out whatever dependency is broken, figure out what satisfies it, go to snapshot.debian.net... etc. It is time-consuming and impractical. Most users are excluded. The right answer is probably for the binary distributor to use the distro's package management system, but there you have it: every distro uses a different one, or worse, they use the same ones but in subtly different ways. So nobody even tries to support them all. They pick RPM (or once in a while, deb), or they don't even bother. If you don't do that you can also claim that SuSe isn't SuSe compatible as you can have exactly the same version/package skews within one distro. You're right of course - even within a distro, binary compatibility isn't really that great. So here we have the schizophrenia of our community with relation to binary distribution. On the one hand we sometimes casually claim that it works, and we sometimes expect it to work. When the rubber hits the road it becomes obvious that it's both ugly and impractical for users/developers. Then the story switches to others saying that we are an FS/OS community, and asking "what are you doing distributing binaries anyway?" Later you hear that we're really only geared towards source distribution (for distro-independent developers). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cross-distro binary compatibilty
David Wood <[EMAIL PROTECTED]> writes: > On Wed, 6 Jul 2005, Goswin von Brederlow wrote: > >>> 1) We are not that compatible to begin with >> >> In what way? We follow LSB and such. > > Different "baseline" libraries, different _available_, _packaged_ > libraries, different compiler versions, different directory structures > (for instance, important parts of etc), different apps performing > essential system functions (i.e. inetd/xinetd), and, just to make it > really fun, different package formats... Go to snapshot.debian.net and fish out the right library versions suse/rh uses, install them, install the same packages (inetd/xinetd) suse/rh uses and voila. Compatibility. If you don't do that you can also claim that SuSe isn't SuSe compatible as you can have exactly the same version/package skews within one distro. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cross-distro binary compatibilty (was multiarch/bi-arch..)
On Wed, 6 Jul 2005, Goswin von Brederlow wrote: 1) We are not that compatible to begin with In what way? We follow LSB and such. Different "baseline" libraries, different _available_, _packaged_ libraries, different compiler versions, different directory structures (for instance, important parts of etc), different apps performing essential system functions (i.e. inetd/xinetd), and, just to make it really fun, different package formats... If you like, I can refer threads I've seen by vendors distributing binaries (the video game guys maybe get the most sympathy here?) where greivances are listed. Maybe you don't care (no problem), but I don't think we should claim it (cross-distro binary compatibility) works. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
