Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Rainer Weikusat  writes:

[...]

> continue to be runtime-linked with the library version it was compiled
> with.

Since I (IMHO justifiedly) complained about this, I shouldn't be using
this particular statement myself: Compiling and linking an application
doesn't result in any "implicit relation" to any particular dynamic
library (file) beyond recording a soname determined in the way I
described in the resulting binary.

The compiled application will depend on a specific set of interface
definitions (however acquired), but that's a whole different can of
worms I don't plan to dive into right now.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Hendrik Boom]

On Tue, Mar 01, 2016 at 03:05:10PM +, Rainer Weikusat wrote:
> 
> But this already exists. Eg, the machine I usually use for development
> (Debian 6 based) has the following version of libdb installed:
> 
> ii  libdb4.2 4.2.52+dfsg-5 Berkeley v4.2 Database Libraries 
> [runtime]
> ii  libdb4.5 4.5.20-13 Berkeley v4.5 Database Libraries 
> [runtime]
> ii  libdb4.6 4.6.21-16 Berkeley v4.6 Database Libraries 
> [runtime]
> ii  libdb4.7 4.7.25-9  Berkeley v4.7 Database Libraries 
> [runtime]
> ii  libdb4.8 4.8.30-2  Berkeley v4.8 Database Libraries 
> [runtime]
> ii  libdb4.8-dev 4.8.30-2  Berkeley v4.8 Database Libraries 
> [development]
> 
> That's just a matter of using a different soname whenever something
> changes in a backward incompatible way. Even for cases where the soname
> is fixed 'for political reasons' aka 'glibc', the issue is supposed to
> be handled transparently via symbol versioning.

It seems to me that a decade or more ago, I read that this was the standard
Linux way to name multiple versions of libraries.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

"T.J. Duchene"  writes:
> On 2016-03-02 16:20, Rainer Weikusat wrote:
>> The soname mechanism already provides an opportunity for having multiple
>> version of the same library installed as these cane use different
>> sonames but provide the same set of symbols. In addition to this, the
>> symbols themselves can be versioned which enables a single library to
>> provide different versions of a function with the same name, eg
>>
>
> Yes. All true.
>
> Libraries are installed and then linked using sonames that are
> symlinked rather than using the full soname.  This is the proper way,
> so that you don't have to recompile and re-link every single time when
> a minor update is made.  The full length sonames aren't used on a
> day-to-day basis.   It is possible that a short form (symlinked)
> soname  can get re-pointed from the distributions chosen version to
> whatever version was installed last.  It's a human oversight, but it
> can cause problems with the linker.

You seem to be somewhat confused re: How this works and what it's
supposed to accomplish. The soname is a property of a particular library
file, eg, using libdb4 as example,

[rw@duesterwald]/usr/lib $readelf -d libdb-4.8.so | grep -i son
 0x000e (SONAME) Library soname: [libdb-4.8.so]

and that's one the runtime linker cares about: When handling a NEEDED
entry in an ELF binary, it searches for a file with a matching SONAME
entry. The soname will usually be identical to/ reflected in the
filename but it doesn't have to be in this way. The prominent
counterexample would be the C libary whose soname has been fixed as
libc.so.6 regardless of the actual library version:

[rw@doppelsaurus]/lib#readelf -d /lib/x86_64-linux-gnu/libc-2.13.so | grep -i 
son
 0x000e (SONAME) Library soname: [libc.so.6]
(example is for the actual C library file of a Wheezy install)

But that's just one side of the issue, the one concerned with locating a
library when starting an application. The other would be 'locating a
library when compiling/ linking one'. The information the
linker is supplied with will usually just be the proper name of the
library, the first part of the filename minus the leading lib,
eg, in order to link with the Berkeley DB library, one would usually
pass an argument of

-ldb

to the linker (driver). The linker will then search for a file named

lib.so

in its library search path. This will usually be a symlink to most
recent installed version of a library, eg,

[rw@duesterwald]/usr/lib $ls -l libdb.so
lrwxrwxrwx 1 root root 12 Oct  9  2013 libdb.so -> libdb-4.8.so

and the soname in this file will then end up in a NEEDED section.

The idea behind this is that someone compiling an application will want
to associate it with the most recent version of "a certain libray", eg,
the Berkeley DB library, while an already compiled application should
continue to be runtime-linked with the library version it was compiled
with.

> That is what I was referring to when I made my earlier comment about
> the linker becoming "confused."  It's not a correct answer in
> programming terms, but it is a very human one.

You've omitted a few steps on the path to the ultimate disaster: It will
usually also involve trying to "update the system" by copying random
stuff compiled from sources over some set of system-provided files
(especially effective for the C library as this will cause all running
applications to crash once they try to call into it and may prevent
starting new ones :-) and/ or trying to fixup the links manually based
on a half-cocked understanding of their purpose.

But handling this correctly is really not that difficult, even when
doing it manually: Provided a library file named in a suitable way has
been deposited in a library directory, eg, /usr/local/lib, invoking
ldconfig (as root, obviously) will take care of the rest, including
updating the runtime linker cache.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Edward Bartolo]

Hi,

I think, multiple libraries can still reside in an installation of
Debian/Devuan, provided some preparation is done before attempting to
run programs that may require conflicting library version. The only
limitation is the kernel which has to be compatible with all used
libraries.

I would workaround such a problem as follows:
a) copy all executables to the same directory including all .so files
b) use a script to run the executable by using the command:
ld-2.19.so or whatever version is installed on the system

This particular .so file is in a reality an executable that loads and
prepares an executable file linking it with all its required libraries
before running it. The command would specify the executable to be run
and the path to its libraries as follows:

/lib/x86_64-linux-gnu$ ./ld-2.19.so --library-path . /bin/ls

In this example I used ld-2.19.so to run ls.


Edward


On 02/03/2016, T.J. Duchene  wrote:
>
> Perhaps my greatest error was assuming that anyone one the list would
> need or even want a "dumbed down" explanation.  In that case, it is most
> certainly a "mea culpa" on my part.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[T.J. Duchene]

Perhaps my greatest error was assuming that anyone one the list would 
need or even want a "dumbed down" explanation.  In that case, it is most 
certainly a "mea culpa" on my part.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Joel Roth]

Hi Rainer,

Rainer Weikusat wrote:
> As I already wrote twice, program's aren't "linked" to dynamic libraries
> at all. At link time, the sonames of required dynamic libaries are
> recorded in the binary,
> 
> [rw@doppelsaurus]~#readelf -d /bin/bash | grep -i needed
>  0x0001 (NEEDED) Shared library: [libtinfo.so.5]
>  0x0001 (NEEDED) Shared library: [libdl.so.2]
>  0x0001 (NEEDED) Shared library: [libc.so.6]

[more good stuff]

> In case you really care about the technical details, a good description
> is available here:
> 
> https://www.akkadia.org/drepper/dsohowto.pdf

Thanks for this and other contributions! Your clear
explanations and code snippets add a lot to the (high IMO)
level of discussion here. It's a pleasure to learn more 
about how various parts of the Debian/Devuan/Linux OS works.

Cheers,

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Hendrik Boom  writes:
> On Wed, Mar 02, 2016 at 12:45:22PM +1300, Daniel Reurich wrote:

[libdb4 & Bitcoin]

>> The risk is that issues that have been fixed in later libdb versions
>> remain broken in the version that bitcoin statically links in.  So there
>> is a trade off either way, and what is the better approach... fix
>> bitcoin or forever hold onto an obsolete library for one package where
>> the maintainers refuse to switch to a newer version.
>
> It's probably the job of the bitcoin developers to watch deveopments 
> in that other library and decide when it is safe or necessary to change 
> versions.

There's an obvious, alternate option: libdb is (certainly at least until
4.8) BSD-licensed. This means "the right version" can just be
integrated into the Bitcoin code at the expense of the developers having
to maintain it themselves.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Hendrik Boom  writes:
> On Tue, Mar 01, 2016 at 11:41:46PM +, Rainer Weikusat wrote:
>> "T.J. Duchene"  writes:
>> > On 2016-03-01 20:22, Rainer Weikusat wrote:
>> 
>> And I disgree with your assessment of this being "a simplified"
>> description, instead of a fairly complicated and seriously deceptive
>> one.
>> 
>> >> As single example: Applications aren't "compiled with" dynamic
>> >> libraries, they're combined with them at runtime which happens in the
>> >> same way regardless of the system they were compiled on.
>> >
>> > I am not trying to be rude or condescending, but if you prefer a more
>> > qualified answer to show that I know what I am talking about, then I
>> > must disagree with you.  They are not "combined" with anything except
>> > a set of calls,
>> 
>> Oh, they are. Try running pmap -d $$ in a shell to see this.
>
> As I once understood it, programs are linked to a stub.  When the 
> dynamic shared libraries are loaded, the stub s filled in with the 
> addresses of the real library entry points.

As I already wrote twice, program's aren't "linked" to dynamic libraries
at all. At link time, the sonames of required dynamic libaries are
recorded in the binary,

[rw@doppelsaurus]~#readelf -d /bin/bash | grep -i needed
 0x0001 (NEEDED) Shared library: [libtinfo.so.5]
 0x0001 (NEEDED) Shared library: [libdl.so.2]
 0x0001 (NEEDED) Shared library: [libc.so.6]

and at runtime, the runtime linker locates libraries 'claiming' the
needed sonames by searching through a certain set of directories (it's
actually using a cache but I am trying to simplify things). It maps the
corresponding shared objects into the address space of the process and
use the information in them to connect calls made in the applications
with actual routines available in these libraries based on searching for
'symbols' needed by an application in the set of 'symbols' provided by
the libraries, eg, the bash binary requests of of the following symbols
(that's a subset),

[rw@doppelsaurus]~#nm -D /bin/bash  | grep 'U dl'
 U dlclose
 U dlerror
 U dlopen
 U dlsym
 
by recording them as 'undefined' (U) and the libdl library provides
symbols with these names,

[rw@doppelsaurus]~#nm -D /usr/lib/x86_64-linux-gnu/libdl.so | grep 'T dl'
15e0 T dladdr
1600 T dladdr1
0ff0 T dlclose
13c0 T dlerror
1640 T dlinfo
1850 T dlmopen
0eb0 T dlopen
1030 T dlsym

The soname mechanism already provides an opportunity for having multiple
version of the same library installed as these cane use different
sonames but provide the same set of symbols. In addition to this, the
symbols themselves can be versioned which enables a single library to
provide different versions of a function with the same name, eg

[rw@doppelsaurus]~#objdump -T  /lib/x86_64-linux-gnu/libc.so.6 | grep 
pthread_cond_signal
000eaac0 gDF .text  0026  GLIBC_2.3.2 
pthread_cond_signal
00115890 gDF .text  0026 (GLIBC_2.2.5) 
pthread_cond_signal

In case you really care about the technical details, a good description
is available here:

https://www.akkadia.org/drepper/dsohowto.pdf
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[T.J. Duchene]

On 2016-03-02 03:19, Hendrik Boom wrote:
.
>
> Thanks.

You're welcome! =)

From this it looks as if there's a table of addresses for the
> external references, not a table of call instructions, as I had
> previously thought. This would seemm to indicate that the coopilers
> generating the code must know whether a reference is to a shared
> ilbrary or not, or else that all external references are done by such
> a
> table, whether to a static or a dynamic library.
>
If I recall correctly (and I am far from an expert on compilers), ELF 
uses a loading stub for whatever libraries are needed for execution.  
They are loaded into RAM and then the "calls"  I referred to in previous 
posts are made as needed.  As you can see in the document, Rainer's 
right in that there are more mechanisms involved than simple 
instructions to execute code.  I respect Rainer's desire for exactness. 
I just don't see the necessity in posting that to what I've always 
considered a "user list."


Perhaps, I am in the wrong on that regard.

Have a wonderful evening!
T.J.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Hendrik Boom]

On Tue, Mar 01, 2016 at 08:09:18PM -0600, T.J. Duchene wrote:
> 
> http://www.ibm.com/developerworks/library/l-dynamic-libraries/
> 
> Sorry the link didn't get through the first time.  I hope you find
> it useful, Hendrik.

Thanks.  From this it looks as if there's a table of addresses for the 
external references, not a table of call instructions, as  I had 
previously thought.  This would seemm to indicate that the coopilers 
generating the code must know whether a reference is to a shared 
ilbrary or not, or else that all external references are done by such 
a 
table, whether to a static or a dynamic library.

-- hendrik
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[T.J. Duchene]

http://www.ibm.com/developerworks/library/l-dynamic-libraries/

Sorry the link didn't get through the first time.  I hope you find it 
useful, Hendrik.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[T.J. Duchene]

On 2016-03-02 01:23, Hendrik Boom wrote:

> Perhaps it is worth going in to more detail. Or providing links to a
> more complete description.
>
> -- hendrik
>

This may be useful to you, and better than my explanation.  Like 
yourself, I know the basics, but not the exact details of every 
implementation.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Hendrik Boom]

On Wed, Mar 02, 2016 at 12:45:22PM +1300, Daniel Reurich wrote:
> On 26/02/16 05:01, Ivan J. wrote:
> > Hello DnG.
> > 
> > Is there interest in Devuan supporting multiple versions of leveldb?
> 
> It is possible, but is it necessary??
> It would should be relatively easy to forward port the libdb4.8 package
> from squeeze.
> 
> > Why I am wondering is because of Bitcoin and its code. Currently Bitcoin
> > statically links db-4.8 and it is used for having wallet support in
> > Bitcoin Core. 
> Are you talking about bitcoin in general or bitcoin in debian|devuan?
> 
> Are we talking about leveldb or berkely db (package libdb-??
> You ask about leveldb and then refer to berkely db versions...
> 
> > Where the problem arises is when you try to build Bitcoin Core yourself.
> 
> > You need to compile with db-4.8 libraries, and we all know distros have
> > dropped it in favor of 5.x... Using system leveldb on distros requires
> > higher QA for leveldb than typical.
> 
> Can it not be made to build against db-5.3?  If not, why not?
> 
> > What I am proposing is Devuan to support multiple versions of leveldb
> > and tie Bitcoin packages to the right one. Another option is to never
> > push updates to leveldb until they are known consensus-safe. It would be
> > awesome if Devuan could be the second distro to meet the higher
> > standards required for the Bitcoin code; for example, a bugfix to
> > leveldb could cause serious security problems with Bitcoin. (This is why
> > it's statically linked for almost every distro).
> 
> Sure, but the question this raises in my mind is; Is their a proven
> issue with db-5.3 that has been introduced that breaks bitcoin-core or
> adds security threats?
> 
> The risk is that issues that have been fixed in later libdb versions
> remain broken in the version that bitcoin statically links in.  So there
> is a trade off either way, and what is the better approach... fix
> bitcoin or forever hold onto an obsolete library for one package where
> the maintainers refuse to switch to a newer version.

It's probably the job of the bitcoin developers to watch deveopments 
in that other library and decide when it is safe or necessary to change 
versions.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Hendrik Boom]

On Tue, Mar 01, 2016 at 11:41:46PM +, Rainer Weikusat wrote:
> "T.J. Duchene"  writes:
> > On 2016-03-01 20:22, Rainer Weikusat wrote:
> 
> And I disgree with your assessment of this being "a simplified"
> description, instead of a fairly complicated and seriously deceptive
> one.
> 
> >> As single example: Applications aren't "compiled with" dynamic
> >> libraries, they're combined with them at runtime which happens in the
> >> same way regardless of the system they were compiled on.
> >
> > I am not trying to be rude or condescending, but if you prefer a more
> > qualified answer to show that I know what I am talking about, then I
> > must disagree with you.  They are not "combined" with anything except
> > a set of calls,
> 
> Oh, they are. Try running pmap -d $$ in a shell to see this.

As I once understood it, programs are linked to a stub.  When the 
dynamic shared libraries are loaded, the stub s filled in with the 
addresses of the real library entry points.  There must be more to the 
story, because this obviously won't work for addresses of data.

Perhaps it is worth going in to more detail.  Or providing links to a 
more complete description.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[T.J. Duchene]

On 2016-03-01 23:41, Rainer Weikusat wrote:
> "T.J. Duchene"  writes:
> > On 2016-03-01 20:22, Rainer Weikusat wrote:
> >> "T.J. Duchene"  writes:
> >> > On 03/01/2016 08:15 AM, dng-request@??? wrote:
> >>
> >> [...]
> >>
> >>
> >> > I'd just like to offer my opinions on the subject of Debian/Devuan
> >> > libraries, linking and so on. This is just an opinion, so no one has
> >> > to agree by any stretch of the human imagination, nor do I feel it
> >> > necessary to defend it.
> >>
> >> It's not "just an opinion", it asserts quite a few things which are at
> >> least worded in a very scarily sounding and vague way, if not outright
> >> wrong.
> >
> > I am sorry you took it that way. I was just keeping it "simple" as I
> > said. =)
>
> And I disgree with your assessment of this being "a simplified"
> description, instead of a fairly complicated and seriously deceptive
> one.

I've mentioned that it was possible to support multiple versions of the 
same library.  The exact mechanics of why or how do not matter in saying 
so on this list. I see no reason to stray further from that.


You are naturally entitled to think whatever you wish. If you have 
reasons that you would like to share with me, I invite you to do so.  I 
would ask that you do so off of the list as so not to annoy others. I 
consider the discussion regarding it closed until then.


Take care,
T.J.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Adam Borowski]

On Tue, Mar 01, 2016 at 10:13:34PM +, Noel Torres wrote:
> THIS is an example of how to do it properly. But you can not (currently)
> version virtual packages.

Why not?

-- 
A tit a day keeps the vet away.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Daniel Reurich]

On 26/02/16 05:01, Ivan J. wrote:
> Hello DnG.
> 
> Is there interest in Devuan supporting multiple versions of leveldb?

It is possible, but is it necessary??
It would should be relatively easy to forward port the libdb4.8 package
from squeeze.

> Why I am wondering is because of Bitcoin and its code. Currently Bitcoin
> statically links db-4.8 and it is used for having wallet support in
> Bitcoin Core. 
Are you talking about bitcoin in general or bitcoin in debian|devuan?

Are we talking about leveldb or berkely db (package libdb-??
You ask about leveldb and then refer to berkely db versions...

> Where the problem arises is when you try to build Bitcoin Core yourself.

> You need to compile with db-4.8 libraries, and we all know distros have
> dropped it in favor of 5.x... Using system leveldb on distros requires
> higher QA for leveldb than typical.

Can it not be made to build against db-5.3?  If not, why not?

> What I am proposing is Devuan to support multiple versions of leveldb
> and tie Bitcoin packages to the right one. Another option is to never
> push updates to leveldb until they are known consensus-safe. It would be
> awesome if Devuan could be the second distro to meet the higher
> standards required for the Bitcoin code; for example, a bugfix to
> leveldb could cause serious security problems with Bitcoin. (This is why
> it's statically linked for almost every distro).

Sure, but the question this raises in my mind is; Is their a proven
issue with db-5.3 that has been introduced that breaks bitcoin-core or
adds security threats?

The risk is that issues that have been fixed in later libdb versions
remain broken in the version that bitcoin statically links in.  So there
is a trade off either way, and what is the better approach... fix
bitcoin or forever hold onto an obsolete library for one package where
the maintainers refuse to switch to a newer version.


-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

"T.J. Duchene"  writes:
> On 2016-03-01 20:22, Rainer Weikusat wrote:
>> "T.J. Duchene"  writes:
>> > On 03/01/2016 08:15 AM, dng-request@??? wrote:
>>
>> [...]
>>
>>
>> > I'd just like to offer my opinions on the subject of Debian/Devuan
>> > libraries, linking and so on. This is just an opinion, so no one has
>> > to agree by any stretch of the human imagination, nor do I feel it
>> > necessary to defend it.
>>
>> It's not "just an opinion", it asserts quite a few things which are at
>> least worded in a very scarily sounding and vague way, if not outright
>> wrong.
>
> I am sorry you took it that way.  I was just keeping it "simple" as I
> said. =)

And I disgree with your assessment of this being "a simplified"
description, instead of a fairly complicated and seriously deceptive
one.

>> As single example: Applications aren't "compiled with" dynamic
>> libraries, they're combined with them at runtime which happens in the
>> same way regardless of the system they were compiled on.
>
> I am not trying to be rude or condescending, but if you prefer a more
> qualified answer to show that I know what I am talking about, then I
> must disagree with you.  They are not "combined" with anything except
> a set of calls,

Oh, they are. Try running pmap -d $$ in a shell to see this.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[T.J. Duchene]

On 2016-03-01 20:22, Rainer Weikusat wrote:
> "T.J. Duchene"  writes:
> > On 03/01/2016 08:15 AM, dng-request@??? wrote:
>
> [...]
>
>
> > I'd just like to offer my opinions on the subject of Debian/Devuan
> > libraries, linking and so on. This is just an opinion, so no one has
> > to agree by any stretch of the human imagination, nor do I feel it
> > necessary to defend it.
>
> It's not "just an opinion", it asserts quite a few things which are at
> least worded in a very scarily sounding and vague way, if not outright
> wrong.

I am sorry you took it that way.  I was just keeping it "simple" as I 
said. =)



> As single example: Applications aren't "compiled with" dynamic
> libraries, they're combined with them at runtime which happens in the
> same way regardless of the system they were compiled on.


I am not trying to be rude or condescending, but if you prefer a more 
qualified answer to show that I know what I am talking about, then I 
must disagree with you.  They are not "combined" with anything except a 
set of calls, with parameters usually placed on the stack, in a specific 
order when the calls are executed. The order and exact methods depend on 
the language and what type of scoping and binding is used.  They are 
linked via an ABI, with the operating system's linker accessing the 
relevant object code.


If you meant every Linux system that uses ELF binaries, I might agree 
with you. They are compiled roughly the same way on the existing 
versions of Linux certainly, but not "regardless of the system they were 
compiled on."  There are several different methods of creating 
executables used in the world, and I was speaking more in generic terms.


All of this is exactly the "gobblety-gook" I was trying to avoid.  I see 
no reason to mention it further, unless it is needful.




>
> It could go into more detail here but judging "recent events", that
> would probably just again cause someone to become very angry

I admit, my first thought was annoyance, but I think that is a natural 
reaction from anyone who works in a technical field and is told "You are 
wrong."  I think we are all adults here and can refrain from sarcasm and 
"flame wars." if you have some objections, I'd be genuinely interested 
in hearing your concerns.



Take care!
t.j.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Noel Torres]

Rainer Weikusat  escribió:


Noel Torres  writes:

Let's forget what is NOT important

"Ivan J."  escribió:
[...]

What I am proposing is Devuan to support multiple versions of leveldb
and tie Bitcoin packages to the right one. Another option is to never

[...]

This is not only an issue with so-called leveldb. It happens a lot
that two packages you need request different versions of the same
library, not always co-installable. Mostly if you go beyond "stable".
Or even if you got stuck on oldstable and try to install some simple
new package.

And this is a good amount of the "dependency hell" when it comes to
Desktop users.

So, I think that having some way of installing multiple versions of
the same library would be a useful feature.


But this already exists. Eg, the machine I usually use for development
(Debian 6 based) has the following version of libdb installed:

ii  libdb4.2 4.2.52+dfsg-5 Berkeley v4.2 Database  
Libraries [runtime]
ii  libdb4.5 4.5.20-13 Berkeley v4.5 Database  
Libraries [runtime]
ii  libdb4.6 4.6.21-16 Berkeley v4.6 Database  
Libraries [runtime]
ii  libdb4.7 4.7.25-9  Berkeley v4.7 Database  
Libraries [runtime]
ii  libdb4.8 4.8.30-2  Berkeley v4.8 Database  
Libraries [runtime]
ii  libdb4.8-dev 4.8.30-2  Berkeley v4.8 Database  
Libraries [development]


That's just a matter of using a different soname whenever something
changes in a backward incompatible way. Even for cases where the soname
is fixed 'for political reasons' aka 'glibc', the issue is supposed to
be handled transparently via symbol versioning.


THIS is an example of how to do it properly. But you can not  
(currently) version virtual packages.


Regards

Noel
er Envite


bin4suoQ1wpzh.bin
Description: Clave PGP pública
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Noel Torres]

Didier Kryn  escribió:


Le 01/03/2016 11:37, Noel Torres a écrit :
It happens a lot that two packages you need request different  
versions of the same library, not always co-installable. Mostly if  
you go beyond "stable". Or even if you got stuck on oldstable and  
try to install some simple new package.


And this is a good amount of the "dependency hell" when it comes to  
Desktop users.


So, I think that having some way of installing multiple versions of  
the same library would be a useful feature. Heck, even windows does  
that in (some) right way.


I hesitated to reply because I know my answer is politically  
incorrect. "dependency hell" is the consequence of dynamic linkage.  
I understand that dynamic linkage is a necessity for distros, but if  
the concern is about one package, this very one can be linked  
statically. Just search for "static" in synaptic and you'll see that  
many Debian packages, including bash and zsh have static versions,  
therefore it is not so politically incorrect. Therefore nothing  
prevents bitcoin from being statically linked - only glibc remaining  
dynamic.


Didier


My concern is not about one package, but about any situation in which  
upgrading any single package gives you a hell.


Regards

Noel
er Envite


binlt5ZVhLUKa.bin
Description: Clave PGP pública
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

"T.J. Duchene"  writes:
> On 03/01/2016 08:15 AM, dng-requ...@lists.dyne.org wrote:

[...]


> I'd just like to offer my opinions on the subject of Debian/Devuan
> libraries, linking and so on.  This is just an opinion, so no one has
> to agree by any stretch of the human imagination, nor do I feel it
> necessary to defend it.

It's not "just an opinion", it asserts quite a few things which are at
least worded in a very scarily sounding and vague way, if not outright
wrong. As single example: Applications aren't "compiled with" dynamic
libraries, they're combined with them at runtime which happens in the
same way regardless of the system they were compiled on.

It could go into more detail here but judging "recent events", that
would probably just again cause someone to become very angry.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[T.J. Duchene]

On 03/01/2016 08:15 AM, dng-requ...@lists.dyne.org wrote:

Message: 6
Date: Tue, 1 Mar 2016 15:15:05 +0100
From: Didier Kryn<k...@in2p3.fr>
To:dng@lists.dyne.org
Subject: Re: [DNG] leveldb support proposal
Message-ID:<56d5a3e9.3060...@in2p3.fr>
Content-Type: text/plain; charset=utf-8; format=flowed

Le 01/03/2016 11:37, Noel Torres a écrit :

>It happens a lot that two packages you need request different versions
>of the same library, not always co-installable. Mostly if you go
>beyond "stable". Or even if you got stuck on oldstable and try to
>install some simple new package.
>
>And this is a good amount of the "dependency hell" when it comes to
>Desktop users.
>
>So, I think that having some way of installing multiple versions of
>the same library would be a useful feature. Heck, even windows does
>that in (some) right way.

  I hesitated to reply because I know my answer is politically
incorrect. "dependency hell" is the consequence of dynamic linkage. I
understand that dynamic linkage is a necessity for distros, but if the
concern is about one package, this very one can be linked statically.
Just search for "static" in synaptic and you'll see that many Debian
packages, including bash and zsh have static versions, therefore it is
not so politically incorrect. Therefore nothing prevents bitcoin from
being statically linked - only glibc remaining dynamic.

  Didier


I'd just like to offer my opinions on the subject of Debian/Devuan 
libraries, linking and so on.  This is just an opinion, so no one has to 
agree by any stretch of the human imagination, nor do I feel it 
necessary to defend it.  That said, it has been my experience that 
dynamic linking is a two-edged sword.  It's "the best thing ever" for 
operating systems, but it has some rather ugly limitations. I'll try to 
keep it simple, for everyone who is not an engineer.


It is very easy for Linux to become "confused" which library is the 
right one.   Software can, and will crash if it can't figure out which 
library is the one it was compiled with.  At the very least, your system 
will display erratic behaviour, even if there are no serious bugs in the 
source code. Virtually all Linux distributors dodge the linking issues, 
by refusing to support more than one version of a program/library in a 
given release.


There is no technical reason that you can't support multiple versions of 
the same library (or any other software) in the same release. It is very 
possible to make it work.  I know, because I have done it. There are 
different ways to solve this problem. Symlinks are most often used to 
give one version of a library as a "default."  Another is using a 
wrapper script with LD_LIBRARY_PATH, and a third is to use a chroot.


The greatest stumbling block to implementing it system-wide on a 
day-to-day basis in Devuan is the Debian package system.  It is designed 
to resolve packages based on a single chain of binary dependencies setup 
by the Debian release team.  When it was designed, Debian did not 
consider it a necessity for you to be able to install multiple 
versions.  Fixing it would take a lot of convincing and a few years 
worth of coding.


This same issue has come up before.  It's not new.  That is why Ubuntu 
is considering Snappy instead of the Debian package system.



Cheers!
T.J.


P.S.

Just for a sense of completeness, Microsoft gets a mention.  It resolves 
the problem in a different way: the Registry combined with something 
called COM, which I am not going to get into here.  If anyone really 
wants to know more about that sort of thing, I humbly suggest personal 
research or asking me off-list.  It's not an easy topic to delve into, 
and generally not a welcome one on a Linux list.  I mention it, because 
it is possible to use the COM standard on Linux. Personally, I am glad 
no one does.





___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Hendrik Boom]

On Tue, Mar 01, 2016 at 10:37:30AM +, Noel Torres wrote:
> Let's forget what is NOT important
> 
> "Ivan J."  escribió:
> [...]
> >What I am proposing is Devuan to support multiple versions of leveldb
> >and tie Bitcoin packages to the right one. Another option is to never
> [...]
> 
> This is not only an issue with so-called leveldb. It happens a lot
> that two packages you need request different versions of the same
> library, not always co-installable. Mostly if you go beyond
> "stable". Or even if you got stuck on oldstable and try to install
> some simple new package.
> 
> And this is a good amount of the "dependency hell" when it comes to
> Desktop users.
> 
> So, I think that having some way of installing multiple versions of
> the same library would be a useful feature. Heck, even windows does
> that in (some) right way.
> 
> Aptitude would, of course, take care of the not-anymore-needed versions.
> 
> So, forget Bitcoin for a moment and think: is this something it
> would be worth having for Devuan as a whole?

Doesn't zeroinstall do something like this using massive numbers of 
symbolic links?  Though I feel like there should be a better way.

Or do I have it mixed up with another system?

-- hendrik

> 
> Noel
> er Envite

> pub  1024D/EEC7C372 2004-03-19 Noel Torres (Envite) 
> uidNoel David Torres Taño (Envite) 
> 
> uidNoel Torres (Envite) 
> uidNoel David Torres Taño 
> uidNoel David Torres Ta\xf1\x6f (Departamento de 
> Astronom\xed\x61 y Astrof\xed\x73ica) 
> sub  2048g/40100883 2004-03-19




> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Didier Kryn  writes:
> Le 01/03/2016 11:37, Noel Torres a écrit :
>> It happens a lot that two packages you need request different
>> versions of the same library, not always co-installable. Mostly if
>> you go beyond "stable". Or even if you got stuck on oldstable and
>> try to install some simple new package.
>>
>> And this is a good amount of the "dependency hell" when it comes to
>> Desktop users.
>>
>> So, I think that having some way of installing multiple versions of
>> the same library would be a useful feature. Heck, even windows does
>> that in (some) right way.
>
> I hesitated to reply because I know my answer is politically
> incorrect. "dependency hell" is the consequence of dynamic linkage.

The term 'dll hell' which gave birth to the other originally referred to
different Windows applications bundling different version of the same
system DLL such that installing an application could break unrelated
applications because these weren't compatible with the system DLL
version bundled with the new application.

But that's a problem which simply doesn't exist on Linux-based systems
because which application will be runtime linked with which libraries
can be controlled in various ways both for applications compiled on a
system and applications shipped as binaries[*]. That's just a matter of
application authors documenting their depedencies and trusting on
sysadmins/ users to meet them. 

[*] One of the less-than-pleasant things I had to do in the past was get
a proprietary "Linux application" which was compiled for "Linux" aka
"some unknown, dated version of Fedora" to work on a much newer
Ubuntu "short-term" release. This was intricate enough to require
running the program in a chroot environment providing compatible
library versions.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Noel Torres  writes:
> Let's forget what is NOT important
>
> "Ivan J."  escribió:
> [...]
>> What I am proposing is Devuan to support multiple versions of leveldb
>> and tie Bitcoin packages to the right one. Another option is to never
> [...]
>
> This is not only an issue with so-called leveldb. It happens a lot
> that two packages you need request different versions of the same
> library, not always co-installable. Mostly if you go beyond "stable".
> Or even if you got stuck on oldstable and try to install some simple
> new package.
>
> And this is a good amount of the "dependency hell" when it comes to
> Desktop users.
>
> So, I think that having some way of installing multiple versions of
> the same library would be a useful feature.

But this already exists. Eg, the machine I usually use for development
(Debian 6 based) has the following version of libdb installed:

ii  libdb4.2 4.2.52+dfsg-5 Berkeley v4.2 Database Libraries 
[runtime]
ii  libdb4.5 4.5.20-13 Berkeley v4.5 Database Libraries 
[runtime]
ii  libdb4.6 4.6.21-16 Berkeley v4.6 Database Libraries 
[runtime]
ii  libdb4.7 4.7.25-9  Berkeley v4.7 Database Libraries 
[runtime]
ii  libdb4.8 4.8.30-2  Berkeley v4.8 Database Libraries 
[runtime]
ii  libdb4.8-dev 4.8.30-2  Berkeley v4.8 Database Libraries 
[development]

That's just a matter of using a different soname whenever something
changes in a backward incompatible way. Even for cases where the soname
is fixed 'for political reasons' aka 'glibc', the issue is supposed to
be handled transparently via symbol versioning.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Noel Torres]

Let's forget what is NOT important

"Ivan J."  escribió:
[...]

What I am proposing is Devuan to support multiple versions of leveldb
and tie Bitcoin packages to the right one. Another option is to never

[...]

This is not only an issue with so-called leveldb. It happens a lot  
that two packages you need request different versions of the same  
library, not always co-installable. Mostly if you go beyond "stable".  
Or even if you got stuck on oldstable and try to install some simple  
new package.


And this is a good amount of the "dependency hell" when it comes to  
Desktop users.


So, I think that having some way of installing multiple versions of  
the same library would be a useful feature. Heck, even windows does  
that in (some) right way.


Aptitude would, of course, take care of the not-anymore-needed versions.

So, forget Bitcoin for a moment and think: is this something it would  
be worth having for Devuan as a whole?


Noel
er Envite


bin9RxzNlPAVi.bin
Description: Clave PGP pública


pgpQOwRAgBQWq.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Rainer Weikusat  writes:
> Go Linux  writes:

[...]

>>> why would I care to impress you
>>> with anything . . . ?
>>> 
>>
>> And therein is the crux of your attitude.
>
> You conjectures about "my attitude" happen to be wrong.

I was planning to let this rest here as this subthread is obviously
quite useless. However, since Mr "Go Linux" has now resorted to send
harrassing, personal mails, I feel that I can't: Whatever "my attitude"
happens to be (and it's certainly not "impressing" random, internet
pseudonyms who use this cover of darkness to behave towards others in a
way which might get them in trouble weren't they hiding their real
identity), it shouldn't matter for the qualities of any arguments I
might make or not make: These can either stand on their own or they
can't (I certainly don't claim that I'm necessarily right on
anything). In the latter case, shooting them down ought to be easy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Ivan J.]

On Mon, 29 Feb 2016, aitor_czr wrote:

>On 02/25/16 20:12, Rainer Weikusat [1]
>wrote:
> 
>  "Ivan J." [2] writes:
> 
>  > Is there interest in Devuan supporting multiple versions of leveldb?
>  > Why I am wondering is because of Bitcoin and its code. Currently Bitcoin
>  > statically links db-4.8 and it is used for having wallet support in
>  > Bitcoin Core.
> 
>  libdb is usually the BerkerleyDB library.
> 
>Are yout talking about libdb or leveldb (fast key-value storage library)
>???

In debian it's BerkeleyDB, yes. Packages called libdb4.8-dev and
libdb4.8++-dev in Debian.


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[aitor_czr]

On 02/25/16 20:12, Rainer Weikusat  wrote:

"Ivan J."  writes:

>Is there interest in Devuan supporting multiple versions of leveldb?
>Why I am wondering is because of Bitcoin and its code. Currently Bitcoin
>statically links db-4.8 and it is used for having wallet support in
>Bitcoin Core.

libdb is usually the BerkerleyDB library.


Are yout talking about libdb or leveldb (fast key-value storage library) ???

  Aitor.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Go Linux <goli...@yahoo.com> writes:
> 
> On Mon, 2/29/16, Rainer Weikusat <rainerweiku...@virginmedia.com> wrote:
>
>  Subject: Re: [DNG] leveldb support proposal
>  To: dng@lists.dyne.org
>  Date: Monday, February 29, 2016, 10:01 AM
>  
> Go Linux <goli...@yahoo.com> writes:
>
>> 
>> On Mon, 2/29/16, Jaromil <jaro...@dyne.org> wrote:
>>
>>  Subject: Re: [DNG] leveldb support proposal
>>  To: dng@lists.dyne.org
>>  Date: Monday, February 29, 2016, 7:37 AM
>>>
>>> I am not the only one to perceive Rainer's contributions as rather
>>> questionable for the conversations here. However, be it propaganda or
>>> not, what is really annoying is that it goes quite far off-topic, by
>>> abstracting a specific issue into a general political consideration of
>>> how history goes.
>>>
>>
>> I have considered filtering Rainer's posts. They are overly verbose.
>> And to what end other than to provide a vehicle for him to parade his
>> intellectual/technical 'superiority'?
>
>> 
>> why would I care to impress you
>> with anything . . . ?
>> 
>
> And therein is the crux of your attitude.

You conjectures about "my attitude" happen to be wrong.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Go Linux]

On Mon, 2/29/16, Rainer Weikusat <rainerweiku...@virginmedia.com> wrote:

 Subject: Re: [DNG] leveldb support proposal
 To: dng@lists.dyne.org
 Date: Monday, February 29, 2016, 10:01 AM
 
Go Linux <goli...@yahoo.com> writes:

> 
> On Mon, 2/29/16, Jaromil <jaro...@dyne.org> wrote:
>
>  Subject: Re: [DNG] leveldb support proposal
>  To: dng@lists.dyne.org
>  Date: Monday, February 29, 2016, 7:37 AM
>>
>> I am not the only one to perceive Rainer's contributions as rather
>> questionable for the conversations here. However, be it propaganda or
>> not, what is really annoying is that it goes quite far off-topic, by
>> abstracting a specific issue into a general political consideration of
>> how history goes.
>>
>
> I have considered filtering Rainer's posts. They are overly verbose.
> And to what end other than to provide a vehicle for him to parade his
> intellectual/technical 'superiority'?

> 
> why would I care to impress you
> with anything . . . ?
> 

And therein is the crux of your attitude.  I have no interest in being 
'impressed' and imagine others on this list feel much the same.

golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Go Linux <goli...@yahoo.com> writes:
> 
> On Mon, 2/29/16, Jaromil <jaro...@dyne.org> wrote:
>
>  Subject: Re: [DNG] leveldb support proposal
>  To: dng@lists.dyne.org
>  Date: Monday, February 29, 2016, 7:37 AM 
>> 
>> I am not the only one to perceive Rainer's contributions as rather
>> questionable for the conversations here. However, be it propaganda or
>> not, what is really annoying is that it goes quite far off-topic, by
>> abstracting a specific issue into a general political consideration of
>> how history goes.
>> 
>
> I have considered filtering Rainer's posts. They are overly verbose.
> And to what end other than to provide a vehicle for him to parade his
> intellectual/technical 'superiority'?

I'm not responsible for any opinion you may have about me. Further,
considering that I not only don't know you beyond that you hide behind a
pseudonym and attack other people indirectly (me, at least) for voicing
opinions you apparently disagree with, why would I care to impress you
with anything in such a doomed-to-fail way?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

"Ivan J."  writes:

[...]

>  You aren't really contributing with any of your emails, if you can not
>  help the Devuan developers on a technical level regarding my subject,
>  please refrain from further mailing on this list. What you are doing is
>  just derailing, nothing more.

You wrote

,
| Is there interest in Devuan supporting multiple versions of leveldb?
| Why I am wondering is because of Bitcoin and its code. Currently Bitcoin
| statically links db-4.8 and it is used for having wallet support in
| Bitcoin Core. Currently, this is the way it's done for binary distros.
| Where the problem arises is when you try to build Bitcoin Core yourself.
| You need to compile with db-4.8 libraries, and we all know distros have
| dropped it in favor of 5.x... Using system leveldb on distros requires
| higher QA for leveldb than typical.
| What I am proposing is Devuan to support multiple versions of leveldb
| and tie Bitcoin packages to the right one. Another option is to never
| push updates to leveldb until they are known consensus-safe. It would be
| awesome if Devuan could be the second distro to meet the higher
| standards required for the Bitcoin code;
`

It's still unclear if this refers to 'leveldb' (a Google project) or to
what is usually known as 'libdb', namely, the 'Berkeley Database
Libraries'. What you propose above is basically allowing the bitcoin
developers to veto updates to the Berkeley DB shared library (insofar I
understand this correctly), based on the assertion that "the higher
standards of Bitcoin code" ought to be an overriding concern.

And I disagree with this proposal.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Go Linux]

On Mon, 2/29/16, Jaromil <jaro...@dyne.org> wrote:

 Subject: Re: [DNG] leveldb support proposal
 To: dng@lists.dyne.org
 Date: Monday, February 29, 2016, 7:37 AM 
> 
> I am not the only one to perceive Rainer's contributions as rather
> questionable for the conversations here. However, be it propaganda or
> not, what is really annoying is that it goes quite far off-topic, by
> abstracting a specific issue into a general political consideration of
> how history goes.
> 

I have considered filtering Rainer's posts. They are overly verbose.  And to 
what end other than to provide a vehicle for him to parade his 
intellectual/technical 'superiority'?  Is he actually participating in the 
Devuan project?  Or just adding his self-inflated noise to the list?

> 
> and BTW thanks everyone for the bitcoins donated so far: they are
> useful, we have started using them and the next financial report will
> have details on that.
> 

A financial report would be very welcome (and is looong overdue IMO).

:)

golinux


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Ivan J.]

On Mon, 29 Feb 2016, Rainer Weikusat wrote:

> Jaromil  writes:
> 
> > On Mon, 29 Feb 2016, poitr pogo wrote:
> >
> >> On 2/25/16, Rainer Weikusat  wrote:
> >> (...)
> >>
> >> > Considering that shared objects and dynamic linking were
> >> > originally a MULTICS feature (dating back to about 1965) and
> >> > introduced to UNIX(*) with SunOS 4.0 in 1988, the best course of
> >> > action to deal with people who are so afraid of changes that they
> >> > keep rejecting "useful new features" for 51/ 28 years in a row is
> >> > "roundly ignore them". Especially if they claim to be
> >> > 'modernizers' because the ancient technology they're so wedded to
> >> > is so seriously ancient that large groups of people meanwhile
> >> > forgot about that ...  ___
> >> 
> >> Is this some kind of pro systemd propaganda ? :D
> >
> > I am not the only one to perceive Rainer's contributions as rather
> > questionable for the conversations here. However, be it propaganda or
> > not, what is really annoying is that it goes quite far off-topic, by
> > abstracting a specific issue into a general political consideration of
> > how history goes.
> 
> In case you want it specific: 'libdb must not be updated because nameless
> "Bitcoin developers" are afraid that this may introduce "issues" for
> them is a red herring'. The same applies to any other software on the
> system which could possibly interact with "bitcoin software", eg,
> prominently, the kernel.
> 
> I consider the sentiment behind this request based on irrational fear
> about the unknown, for the stated reasons, as this "opinion" has never
> been gone unvoiced for long ever since dynamic linking was introduced.
> 
> > I think we should be concerned by specific issues rather than such
> > generic and political debates.
> 
> Sometimes, 'specific questions' ("Should bitcoin developers get 'special
> protection' against measures users of bitcoin software might employ, eg,
> as specifically mentioned, library security updates"?) have answers
> depending on general considerations ("no more than the other 500 less
> prominent developers who considered that de rigueur for their own,
> mental well-being before").
 
 You aren't really contributing with any of your emails, if you can not
 help the Devuan developers on a technical level regarding my subject,
 please refrain from further mailing on this list. What you are doing is
 just derailing, nothing more.

 ~ parazyd


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Jaromil  writes:

> On Mon, 29 Feb 2016, poitr pogo wrote:
>
>> On 2/25/16, Rainer Weikusat  wrote:
>> (...)
>>
>> > Considering that shared objects and dynamic linking were
>> > originally a MULTICS feature (dating back to about 1965) and
>> > introduced to UNIX(*) with SunOS 4.0 in 1988, the best course of
>> > action to deal with people who are so afraid of changes that they
>> > keep rejecting "useful new features" for 51/ 28 years in a row is
>> > "roundly ignore them". Especially if they claim to be
>> > 'modernizers' because the ancient technology they're so wedded to
>> > is so seriously ancient that large groups of people meanwhile
>> > forgot about that ...  ___
>> 
>> Is this some kind of pro systemd propaganda ? :D
>
> I am not the only one to perceive Rainer's contributions as rather
> questionable for the conversations here. However, be it propaganda or
> not, what is really annoying is that it goes quite far off-topic, by
> abstracting a specific issue into a general political consideration of
> how history goes.

In case you want it specific: 'libdb must not be updated because nameless
"Bitcoin developers" are afraid that this may introduce "issues" for
them is a red herring'. The same applies to any other software on the
system which could possibly interact with "bitcoin software", eg,
prominently, the kernel.

I consider the sentiment behind this request based on irrational fear
about the unknown, for the stated reasons, as this "opinion" has never
been gone unvoiced for long ever since dynamic linking was introduced.

> I think we should be concerned by specific issues rather than such
> generic and political debates.

Sometimes, 'specific questions' ("Should bitcoin developers get 'special
protection' against measures users of bitcoin software might employ, eg,
as specifically mentioned, library security updates"?) have answers
depending on general considerations ("no more than the other 500 less
prominent developers who considered that de rigueur for their own,
mental well-being before").

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Jaromil]

On Mon, 29 Feb 2016, poitr pogo wrote:

> On 2/25/16, Rainer Weikusat  wrote:
> (...)
>
> > Considering that shared objects and dynamic linking were
> > originally a MULTICS feature (dating back to about 1965) and
> > introduced to UNIX(*) with SunOS 4.0 in 1988, the best course of
> > action to deal with people who are so afraid of changes that they
> > keep rejecting "useful new features" for 51/ 28 years in a row is
> > "roundly ignore them". Especially if they claim to be
> > 'modernizers' because the ancient technology they're so wedded to
> > is so seriously ancient that large groups of people meanwhile
> > forgot about that ...  ___
> 
> Is this some kind of pro systemd propaganda ? :D

I am not the only one to perceive Rainer's contributions as rather
questionable for the conversations here. However, be it propaganda or
not, what is really annoying is that it goes quite far off-topic, by
abstracting a specific issue into a general political consideration of
how history goes.

I think we should be concerned by specific issues rather than such
generic and political debates. I also wish this list calms down on the
general "propaganda wars" and focuses on more concrete matters.

Please take this not as a moderation attempt, rather than an educated
opinion: we would have never got anywhere with Devuan if we would have
indulged so far in such conversations.

This thread is putting forward a specific issue for Devuan and other
readers that may be brewing their own distros.

So, back to it:

I for one am incline to keep libdb4.8 in Devuan and will study the
strategy to make it possible. It won't be really hard for our CI.

Parazyd is a Bitcoin expert working with us in Amsterdam, he has been
in touch with Luke-jr on the issue, who is the author of the miner
software most used around the world (bfgminer). We will follow up in
person on this, as we can easily relate to security concerns he or
Luke-jr may have regarding the distribution of bitcoin software
binaries.

and BTW thanks everyone for the bitcoins donated so far: they are
useful, we have started using them and the next financial report will
have details on that.


ciao


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Tomasz Torcz  writes:
> On Mon, Feb 29, 2016 at 07:10:28AM -0500, Steve Litt wrote:
>> On Mon, 29 Feb 2016 12:14:25 +0100
>> Didier Kryn  wrote:
>> 
>> >  I think it is different for Systemd supporters:
>> > 
>> >  - shut up, we know better than you
>> >  - you have no choice but do as we tell you
>> 
>> Yeah, and how's that working out for them, now that Docker has switched
>> to an OpenRC distribution, Devuan is going strong, and there are
>> seemingly more sans-systemd distros popping up every day?
>> 
>> Have you guys noticed you don't hear as much chatter from BSD guys
>> about "writing a systemd-like init for BSD"?
>
>   They tend just to do the work, not blabber around:

... as they have their minions for that ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Tomasz Torcz]

On Mon, Feb 29, 2016 at 07:10:28AM -0500, Steve Litt wrote:
> On Mon, 29 Feb 2016 12:14:25 +0100
> Didier Kryn  wrote:
> 
> >  I think it is different for Systemd supporters:
> > 
> >  - shut up, we know better than you
> >  - you have no choice but do as we tell you
> 
> Yeah, and how's that working out for them, now that Docker has switched
> to an OpenRC distribution, Devuan is going strong, and there are
> seemingly more sans-systemd distros popping up every day?
> 
> Have you guys noticed you don't hear as much chatter from BSD guys
> about "writing a systemd-like init for BSD"?

  They tend just to do the work, not blabber around:

https://github.com/mheily/relaunchd

http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html

http://www.daemonspawn.org/2016/01/a-comparison-of-alternatives-to-init8.html

-- 
Tomasz Torcz   72->|   80->|
xmpp: zdzich...@chrome.pl  72->|   80->|

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

poitr pogo  writes:

> On 2/25/16, Rainer Weikusat  wrote:
> (...)
>> Considering that shared objects and dynamic linking were originally a
>> MULTICS feature (dating back to about 1965) and introduced to UNIX(*)
>> with SunOS 4.0 in 1988, the best course of action to deal with people
>> who are so afraid of changes that they keep rejecting "useful new
>> features" for 51/ 28 years in a row is "roundly ignore them". Especially
>> if they claim to be 'modernizers' because the ancient technology they're
>> so wedded to is so seriously ancient that large groups of people
>> meanwhile forgot about that ...
>
> Is this some kind of pro systemd propaganda ? :D

I've purposely used the phrase to highlight that a large part of systemd
is really not 'modern' at all but about bringing back seriously ancient
stuff certain 'usual suspects', in particular, Microsoft/ Windows
never parted with. Eg, in this case, the idea that all code making up an
application has to be under the exclusive control of the guy who
designed the logo (intentional hyperbole) because all this 'code' is
seriously scary stuff and one better doesn't take any risks with that,
especially if this mean 'users' could change something (they're surely
not supposed to !!, eg, fix bugs in libraries).

After all, diskspace is not only cheap nowadays but paid for by someone
else and that someone else can surely by for decreased developer
uneasiness by having 150 broken copies of everything installed on his
machine. Conveniently, any security problems caused by that will also
only affect 'users'.

Heads, developer wins, tails, user loses.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[poitr pogo]

On 2/25/16, Rainer Weikusat  wrote:
(...)
> Considering that shared objects and dynamic linking were originally a
> MULTICS feature (dating back to about 1965) and introduced to UNIX(*)
> with SunOS 4.0 in 1988, the best course of action to deal with people
> who are so afraid of changes that they keep rejecting "useful new
> features" for 51/ 28 years in a row is "roundly ignore them". Especially
> if they claim to be 'modernizers' because the ancient technology they're
> so wedded to is so seriously ancient that large groups of people
> meanwhile forgot about that ...
> ___


Is this some kind of pro systemd propaganda ? :D

--
regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[hellekin]

On 02/25/2016 04:01 PM, Ivan J. wrote:
> Hello DnG.
> 
> Is there interest in Devuan supporting multiple versions of leveldb?
>

The case of Bitcoin warrants some attention.  Moreover, applications
derived from Bitcoin may have the same issue.  E.g., Twister compiles
fine with db-5.3, but it may lead to the same kind of security issues
that are supposed to happen if you do so with Bitcoin (honestly I have
no clue...  Anyone?)

==
hk

-- 
 _ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng