Squeak removed from Gentoo Linux

>
> On 27 May 2010 20:37, Bert Freudenberg <[hidden email]> wrote:
>>
>> Squeak was recently removed from Gentoo Linux Ebuilds because of security issues in our bundled plugins:
>>
>>        http://bugs.gentoo.org/show_bug.cgi?id=247363
>>
>> While it is convenient for us to bundle external library sources, package maintainers do not like that practice. Is there anything we can realistically do about it?
>>
> Here's my argument:
>
> These libraries are bundled, because Squeak VM could be built on a
> system which having no such libraries provided by default.
> To ensure bit-identical behavior on all platforms, Squeak developers
> cannot rely on a platform-specific versions of these libraries,
> because they can vary from one system to another.
>

>
> On Thu, May 27, 2010 at 10:29 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 27 May 2010 20:37, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> Squeak was recently removed from Gentoo Linux Ebuilds because of security issues in our bundled plugins:
>>>
>>>        http://bugs.gentoo.org/show_bug.cgi?id=247363
>>>
>>> While it is convenient for us to bundle external library sources, package maintainers do not like that practice. Is there anything we can realistically do about it?
>>>
>> Here's my argument:
>>
>> These libraries are bundled, because Squeak VM could be built on a
>> system which having no such libraries provided by default.
>> To ensure bit-identical behavior on all platforms, Squeak developers
>> cannot rely on a platform-specific versions of these libraries,
>> because they can vary from one system to another.
>>
>
> If they're not there by default, you can still link dynamically to the
> libraries and provide them with squeak. Also, if the libraries
> provided by the distribution have the same major version as the one
> you use, you can expect compatibility, and profit from the regular
> updates.
>

>
> On 2010-05-27, at 1:36 PM, Geoffroy Couprie wrote:
>
>>
>> On Thu, May 27, 2010 at 10:29 PM, Igor Stasenko <[hidden email]> wrote:
>>>
>>> On 27 May 2010 20:37, Bert Freudenberg <[hidden email]> wrote:
>>>>
>>>> Squeak was recently removed from Gentoo Linux Ebuilds because of security issues in our bundled plugins:
>>>>
>>>>        http://bugs.gentoo.org/show_bug.cgi?id=247363
>>>>
>>>> While it is convenient for us to bundle external library sources, package maintainers do not like that practice. Is there anything we can realistically do about it?
>>>>
>>> Here's my argument:
>>>
>>> These libraries are bundled, because Squeak VM could be built on a
>>> system which having no such libraries provided by default.
>>> To ensure bit-identical behavior on all platforms, Squeak developers
>>> cannot rely on a platform-specific versions of these libraries,
>>> because they can vary from one system to another.
>>>
>>
>> If they're not there by default, you can still link dynamically to the
>> libraries and provide them with squeak. Also, if the libraries
>> provided by the distribution have the same major version as the one
>> you use, you can expect compatibility, and profit from the regular
>> updates.
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
>

>
> On 27 May 2010 23:36, Geoffroy Couprie <[hidden email]> wrote:
>>
>> On Thu, May 27, 2010 at 10:29 PM, Igor Stasenko <[hidden email]> wrote:
>>>
>>> On 27 May 2010 20:37, Bert Freudenberg <[hidden email]> wrote:
>>>>
>>>> Squeak was recently removed from Gentoo Linux Ebuilds because of security issues in our bundled plugins:
>>>>
>>>>        http://bugs.gentoo.org/show_bug.cgi?id=247363
>>>>
>>>> While it is convenient for us to bundle external library sources, package maintainers do not like that practice. Is there anything we can realistically do about it?
>>>>
>>> Here's my argument:
>>>
>>> These libraries are bundled, because Squeak VM could be built on a
>>> system which having no such libraries provided by default.
>>> To ensure bit-identical behavior on all platforms, Squeak developers
>>> cannot rely on a platform-specific versions of these libraries,
>>> because they can vary from one system to another.
>>>
>>
>> If they're not there by default, you can still link dynamically to the
>> libraries and provide them with squeak. Also, if the libraries
>> provided by the distribution have the same major version as the one
>> you use, you can expect compatibility, and profit from the regular
>> updates.
>>
>
> You seem misunderstood a key point there: bit-identical behavior.
> Which means that VM should provide same output on same input on all platforms.
> Chances that it will be so, when you using different versions of same
> library are pretty low.
> So, we can update the libraries, bundled with VM, but can't link with
> them dynamically,
> because this undermines the above.
>
> --
> Best regards,
> Igor Stasenko AKA sig.

> Cheers,
> Josh
>
>
> On May 27, 2010, at 1:42 PM, Igor Stasenko wrote:
>
>>
>> On 27 May 2010 23:36, Geoffroy Couprie<[hidden email]>  wrote:
>>>
>>> On Thu, May 27, 2010 at 10:29 PM, Igor Stasenko<[hidden email]>  wrote:
>>>>
>>>> On 27 May 2010 20:37, Bert Freudenberg<[hidden email]>  wrote:
>>>>>
>>>>> Squeak was recently removed from Gentoo Linux Ebuilds because of security issues in our bundled plugins:
>>>>>
>>>>>         http://bugs.gentoo.org/show_bug.cgi?id=247363
>>>>>
>>>>> While it is convenient for us to bundle external library sources, package maintainers do not like that practice. Is there anything we can realistically do about it?
>>>>>
>>>> Here's my argument:
>>>>
>>>> These libraries are bundled, because Squeak VM could be built on a
>>>> system which having no such libraries provided by default.
>>>> To ensure bit-identical behavior on all platforms, Squeak developers
>>>> cannot rely on a platform-specific versions of these libraries,
>>>> because they can vary from one system to another.
>>>>
>>>
>>> If they're not there by default, you can still link dynamically to the
>>> libraries and provide them with squeak. Also, if the libraries
>>> provided by the distribution have the same major version as the one
>>> you use, you can expect compatibility, and profit from the regular
>>> updates.
>>>
>>
>> You seem misunderstood a key point there: bit-identical behavior.
>> Which means that VM should provide same output on same input on all platforms.
>> Chances that it will be so, when you using different versions of same
>> library are pretty low.
>> So, we can update the libraries, bundled with VM, but can't link with
>> them dynamically,
>> because this undermines the above.
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>

>
> On 5/27/2010 1:56 PM, Josh Gargus wrote:
>>
>> I loves me my bit-identical computation, but statically linking to the
>> same version of the library doesn't necessarily give it.  For example, a
>> video decoder may check hardware capabilities, and depending on what it
>> finds decode the video on the GPU, using SSE, or just using the non-vector
>> CPU instructions.
>>
>> There are some examples where we would make the case that the library
>> needs to be statically linked in order to provide bit-identical
>> computation(eg: fdlibm for Croquet math operations), but for things like
>> JPEG I think that the argument is pretty weak.
>
> Agreed.
>

> Cheers,
>  - Andreas
>
>> Cheers,
>> Josh
>>
>>
>> On May 27, 2010, at 1:42 PM, Igor Stasenko wrote:
>>
>>>
>>> On 27 May 2010 23:36, Geoffroy Couprie<[hidden email]>  wrote:
>>>>
>>>> On Thu, May 27, 2010 at 10:29 PM, Igor Stasenko<[hidden email]>
>>>>  wrote:
>>>>>
>>>>> On 27 May 2010 20:37, Bert Freudenberg<[hidden email]>  wrote:
>>>>>>
>>>>>> Squeak was recently removed from Gentoo Linux Ebuilds because of
>>>>>> security issues in our bundled plugins:
>>>>>>
>>>>>>        http://bugs.gentoo.org/show_bug.cgi?id=247363
>>>>>>
>>>>>> While it is convenient for us to bundle external library sources,
>>>>>> package maintainers do not like that practice. Is there anything we can
>>>>>> realistically do about it?
>>>>>>
>>>>> Here's my argument:
>>>>>
>>>>> These libraries are bundled, because Squeak VM could be built on a
>>>>> system which having no such libraries provided by default.
>>>>> To ensure bit-identical behavior on all platforms, Squeak developers
>>>>> cannot rely on a platform-specific versions of these libraries,
>>>>> because they can vary from one system to another.
>>>>>
>>>>
>>>> If they're not there by default, you can still link dynamically to the
>>>> libraries and provide them with squeak. Also, if the libraries
>>>> provided by the distribution have the same major version as the one
>>>> you use, you can expect compatibility, and profit from the regular
>>>> updates.
>>>>
>>>
>>> You seem misunderstood a key point there: bit-identical behavior.
>>> Which means that VM should provide same output on same input on all
>>> platforms.
>>> Chances that it will be so, when you using different versions of same
>>> library are pretty low.
>>> So, we can update the libraries, bundled with VM, but can't link with
>>> them dynamically,
>>> because this undermines the above.
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>
>

>
>
> On 2010-05-27, at 2:06 PM, Igor Stasenko wrote:
>
>>
>> On 28 May 2010 00:02, Andreas Raab <[hidden email]> wrote:
>>>
>>> On 5/27/2010 1:56 PM, Josh Gargus wrote:
>>>>
>>>> I loves me my bit-identical computation, but statically linking to the
>>>> same version of the library doesn't necessarily give it.  For example, a
>>>> video decoder may check hardware capabilities, and depending on what it
>>>> finds decode the video on the GPU, using SSE, or just using the non-vector
>>>> CPU instructions.
>>>>
>>>> There are some examples where we would make the case that the library
>>>> needs to be statically linked in order to provide bit-identical
>>>> computation(eg: fdlibm for Croquet math operations), but for things like
>>>> JPEG I think that the argument is pretty weak.
>>>
>>> Agreed.
>>>
>>
>> I really don't wanna put that on flame.
>> Just a single word, which could say more than rest of arguments: UUID plugin.
>>
>
> The UUID plugin does not contain the UUID source code, it's a library call and expect it to use the
> system library. The fact that the system library is broken on some versions of some platforms is of course
> an issue, but frankly it's an issue for all software that uses UUID on that platform.  Also the behaviour of UUID is
> not bit identical on every platform the host operating system.
>
> Obviously this is the problem if you rely on the platform code to do the right thing, but you choice here is
> wanting to enable bit identical behaviour versus ensuring Squeak is put into various Linux distributions?
>

>
> On 5/27/2010 1:56 PM, Josh Gargus wrote:
> >
> >I loves me my bit-identical computation, but statically linking to the
> >same version of the library doesn't necessarily give it.  For example, a
> >video decoder may check hardware capabilities, and depending on what it
> >finds decode the video on the GPU, using SSE, or just using the non-vector
> >CPU instructions.
> >
> >There are some examples where we would make the case that the library
> >needs to be statically linked in order to provide bit-identical
> >computation(eg: fdlibm for Croquet math operations), but for things like
> >JPEG I think that the argument is pretty weak.
>
> Agreed.