Dear Peter,

Thanks for the explanation, I'm a software engineer and I know very well
how the process work. SQL is indeed a good example of a good standard
almost everyone follows. But I would bet that's an exception in software.

I raised the intended bugs thing because in recent years it had been very
common to find intended "bugs" in proprietary licensed software to steal
data or open ports to monitor usage. You never know how that will affect
your tests. When you use software that you don't know what is doing in the
background, you can't be really sure what the result will be.

Kind regards,
Maria.


El sáb., 28 jul. 2018 19:48, Peter Baumann <p.baum...@jacobs-university.de>
escribió:

> Dear Maria,
> On 25.07.2018 10:06, María Arias de Reyna wrote:
>
>
>
> On Wed, Jul 25, 2018 at 9:57 AM, Peter Baumann <
> p.baum...@jacobs-university.de> wrote:
>
>> Hi Christian,
>>
>>
>> while I could not agree more to what you say there is one point to
>> disagree with:
>>
>> On 24.07.2018 18:43, Christian Willmes wrote:
>>
>> Dear Suchith,
>>
>> I understand your point, and I also support your views on this, but this
>> is from my perspective a too personal/particular issue, as to have it as an
>> "OSGeo open letter". Also, because this is more of an ICA and not so much
>> an OSGeo issue, I think.
>>
>> First, I would keep it more general. You address a particular issue (UN
>> SDG book published by esri), and also some personal background (this should
>> not matter to the addressed subject). I would recommend you keep it from
>> being personal and denouncing proprietary GIS vendors. If a company plays
>> by the rules of science, there is nothing wrong about that company
>> publishing a scientific book. I.e. almost all book publishers are
>> commercial companies with interests somehow and somewhere.
>>
>> You need to “attack” scientific “wrong doing” by that particular company
>> in conducting the editing and publication of that book. Publishing books if
>> done correctly is not wrong, even by a vendor with vested interests. But if
>> you witness, for example, that submissions using open source GIS solutions
>> are disadvantaged against the submissions using products of the proprietary
>> GIS vendor publishing the book, that would be the point to raise and attack.
>>
>> Second, better write about how it should be done to avoid this negative
>> “Fake Science” things from happening. Here the idea of Open Science and
>> Reproducible Science is key, i.e. the most openness and transparency
>> possible. We just need more transparency in science and also in the whole
>> process of editing/reviewing and publishing a book. And this is where OSGeo
>> can contribute. Basically, real reproducible and open science is not
>> possible without open source software. If you can’t see how something is
>> implemented, you can not really reproduce the results.
>>
>>
>> No. Open science and open source software are fundamentally different
>> things. For example, if you derive stats from some data set via SQL it does
>> not matter whether it comes from open-source PostgreSQL or from proprietary
>> Oracle. Because the SQL language in its syntax and semantics is
>> standardized, and it is assured thereby that both systems will deliver the
>> same results. So standards actually are a prerequisite for science to be
>> comparable, but surely not open source.
>>
>
>
> If you use proprietary products and can't verify that the result is not
> due to a bug (even an intended bug ), you are missing an important step on
> verifiability. Open Source (as in "I can see the code") is an important
> piece of open science.
>
>
> that's not what software engineers would do normally. If you feel a tool
> has a bug you'd
> - try to isolate through a minimal failing example
> - possibly try with another tool (in the case of PostgreSQL, maybe try
> MariaDB) for verification
> - definitely contact the support list (in the case of PostgreSQL, Regina &
> friends)
>
> Unless it is some simple scripting issue you (that is: I) normally don't
> stand a chance to dive into the code. Honestly, would we / could we spot a
> bug in the source code for executing an index-only plan of a distributed
> SQL query, after heuristic and cost-based optimizers have done their work?
> I could not.
>
> Good software engineering practice is to work specification-based, not by
> trying to hack yourself into code.
>
> And both of that _can_ work well with both open-source and proprietary
> tools. Again, SQL is the shining example: a good specification says it all.
>
> BTW, why do you raise, on the fly, the accusation that there may be
> "intended bugs"? Any evidence for this? I'd like to learn more about such
> cases.
>
> cheers,
> Peter
>
>
>
>
>
>
>
> _______________________________________________
> GeoForAll mailing 
> listGeoForAll@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/geoforall
>
> --
> Dr. Peter Baumann
>  - Professor of Computer Science, Jacobs University Bremen
>    www.faculty.jacobs-university.de/pbaumann
>    mail: p.baum...@jacobs-university.de
>    tel: +49-421-200-3178, fax: +49-421-200-493178
>  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>    www.rasdaman.com, mail: baum...@rasdaman.com
>    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
> "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis 
> dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec 
> preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>
>
>
>
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/discuss

Reply via email to