[MonoDevelop] Review of MonoDevelop

[IBBoard]

I'll start by warning that some of this does take a bleaker and more
paranoid view than most people might take, but I'm just trying to make
it clear that there are no absolutes and that everything needs to be
considered in balance!

Also, sorry if some of this is a bit technical. I tried my best not to
for the most part :)

On 07/08/13 08:01, Mike Krüger wrote:
> Hi
> 
>> Pardon my ignorance of Linux's history and culture, I noticed early
>> days of
>> Ubuntu, mono was shipped with the distro. Then I read (forgetting which
>> version) that Mono was not part of packages being shipped
>>
>> Why is such strong hatred even though the original work was done by MS
>> but
>> Mono was built from the ECMA/ISO standard. Linux seems to embrace a
>> proprietary software platform (Java) a lot more warmly than CLR, which
>> is an
>> open standard platform.
> I don't know - it seems that some people hate anything that's related to
> MS. With the exception of the linux kernel which copies MS technologies
> (FAT) and get's direct contributions from MS devs, Samba which copies
> the Windows network code or Wine which copies Windows. But mono was 'too
> much' for them.

Having been around at the time, what I saw was a combination of
"Microsoft only opened part of C# as the ECMA standard, so be careful of
the rest of it, where as Java has had open implementations for ages so
we're comfortable with it" and the Novell/Microsoft patent agreement.
When Microsoft start making big companies sign up for patent liability
mitigation and Sun didn't for Java then it never bodes well!



>> Several things I am always edgy of using things from PPA which stems from
>> years developing in Windows world:
>> 1) How can one be sure things from PPA use all the correct platform
>> supporting modules?

I'm not quite sure what you mean by "correct platform supporting
modules", but you can't be sure that a PPA will a) include all
components (it might just include what the owner wants) or b) work on
all platforms (as the owner might not have that platform and not know
about/care about issues)

>> 2) How can one be sure if the PPA builder has not tempered with build
>> settings to get things to build - ending up with using "It-works-here"
>> yardstick? As a result a distribution from one PPA may not be the same as
>> one from another PPA.

PPAs should let you see the source, shouldn't they? If that's the case
then you should be able to see if they've patched anything (assuming you
know enough about code and have a reference code set to compare against).

That said, if it builds into an installable package then you generally
don't need to worry too much about what they did to get it to build. For
example, I'm using openSUSE's version of PPAs to rebuild someone else's
openSUSE-targeted packages for my CentOS server. I'm having to tweak
some bits because they targeted openSUSE (which has different package
names etc) but once it builds then it still works on CentOS. It just
needs me to tweak it to make it work.

>> 3) What extend of the testing these PPA has done compared to say a
>> vendor of
>> the software, e.g Xamarin? I know it is still the prefer modus
>> operandi of
>> Linux to build everything from source for anything.

It depends on the PPA. For the vast majority of PPAs, almost nothing
will be done to test it. People will build stuff so that it works for
them and that is it. There will be some more known/reputable groups that
build stuff, but my experience is that they take a "stable" version of
the software and build it, meaning that it was stable enough for the
project to work and should be okay when built in a PPA but may still
have some OS/distro-specific issues that the PPA people haven't found yet.

>> 4) Finally, not suggesting it has happened, how trustworthy are things
>> from
>> PPA that it does not introduce back doors or nasties? One of the great
>> features in CLR is the strong name assembly to prevent tempering.

It depends on the PPA! No PPA is entirely safe. No OS is entirely safe
either, TBH. While open code allows people to check for issues, it
doesn't prevent there being some obscure bit of software that is popular
but not heavily checked. PPAs run by individuals are obviously more of a
risk, unless the name is well known in the community.

But as Mark Shuttleworth said about Ubuntu (which applies to the people
running any OS): "Don’t trust us? Erm, we have root."

(http://www.markshuttleworth.com/archives/1182)

Somewhere down the line you have to trust someone. Most people trust the
community OS and key community members for specific projects. Beyond
that then it may all be safe, but it may not. You just can't know unless
you can see the source, tell it hasn't been tampered with (and that its
origin is clean of "nasties"), and can be absolutely certain that those
binaries do in fact come from that source!

As an openSUSE user with access to their version of PPAs, I do one of
two things: 1) use a non-personal 'PPA' (OBS names personal ones
"home:username:project", compared to "devel:tools:scm" for more trusted
group ones) or 2) take the .spec file and the clean sources from the
original project and build it myself in my own 'PPA' (because a spec
file is small and just tells the service how to build the app/library
from source, it doesn't generally modify anything, and it is short
enough to see exactly what it does).