[Mono-dev] Top again

Wed May 29 19:28:53 UTC 2013

'I love this project, and want to see it succeed in more than just mobile.'

I share these sentiments! :)

At first glance, this seems like a big opportunity. There is likely to be a
lot of ASP.NET/WebAPI/socket based enterprise server software currently
running on IIS via MS-CLR where the company wants to get out of that
expensive MSDN vendor lock-in to an open source solution, given several
free/open source competitors (including some Apache/MIT licensed options).
However, these companies seem to be more inclined to move to a JVM based
solution, as there seems to be robust support for servers on that side of
the fence, rather than simply porting their existing .net code to Mono.

Unfortunately, I've heard it said that paid support plans for open source
projects have not had a great history of producing significant revenue - at
least not at the levels needed to put some full-time engineers to it. You'd
have to have people on it full-time, and have priority consideration for
bugs/pull requests/etc... to make it worth paying for, at the very least.
It's unclear how well the economics of it would play out in practice.

On Wed, May 29, 2013 at 1:03 PM, Rafael Teixeira <monoman at gmail.com> wrote:

> 'I love this project, and want to see it succeed in more than just mobile.'
>
> Very well said!
> Rafael Teixeira
> O..:.)oooo
>
>
> On Wed, May 29, 2013 at 1:52 PM, Jeremiah Gowdy
> <jeremiah.gowdy at freedomvoice.com> wrote:
> > Has Xamarin considered offering professional support plans for the other
> > major consumer of Mono, those of us who want to use C# to develop our
> > service applications but would prefer to host them on Linux for obvious
> > reasons?
> >
> >
> >
> > As a representative of one of the aforementioned companies who is trying
> to
> > run production services on Mono+Linux, I’m concerned that we’re building
> a
> > model that’s dependent on a runtime supported by a company which is
> focused
> > on mobile naturally because that’s where the revenue is.  Unfortunately,
> we
> > have no way to change that.  If Xamarin were to offer support for
> > enterprises, perhaps we could become a larger part of the overall revenue
> > stream and our bugs would get better prioritization.
> >
> >
> >
> > I don’t think this would be bad for the project, since the classes our
> > applications rely on are the core classes of .NET.  Nothing fancy, just
> > Sockets, Threads, collections, etc.
> >
> >
> >
> > The bugs we’ve experienced are:
> >
> >
> >
> > The Socket.Send and Socket.BeginSend in blocking mode returning without
> > finishing the entire send, which we had to fix in our code by not using
> > async and looping on blocking Send() until the entire send is actually
> > complete.  Work that by spec should be done by Send and BeginSend.  It
> > works, but it’s Mono-specific and/or Linux-specific hacks that aren’t
> needed
> > on Windows+CLR.
> >
> >
> >
> > Mono’s BlockingCollection<T> performance as a producer consumer queue
> for a
> > pool of threads is really really bad.  As the number of threads waiting
> on
> > the collection goes up, the thrashing rapidly gets out of control.
>  There is
> > no such issue on Windows+CLR.  I ended up copying Mono’s
> > BlockingCollection.cs, copying it into my project as
> > MonoBlockingCollection.cs and rewriting parts of it to make the
> performance
> > reasonable.  We finally changed the design of the service so we could
> remove
> > the custom class, and it works fine that way, but our goal is to
> minimize or
> > eliminate any Mono specific changes to our code because we aren’t yet
> > convinced that the project considers service applications a first class
> > consumer of the platform.
> >
> >
> >
> > We have to choose between running Boehm GC and hitting too many roots
> > failures, or running sgen and getting crashes due to bugs.  We are
> > constantly testing running our application on different nodes in either
> mode
> > in the hopes that one will prove more stability than the other.  We have
> > also had to modify our code significantly in ways that seem less likely
> to
> > reproduce either crash.
> >
> >
> >
> > Now we are certainly a fault here too.  The send bug is reported in bug
> > 3844, but we don’t have a test case that reproduces it.  It’s difficult
> to
> > reproduce, because it happens under load, in a multithreaded socket
> server.
> > But it seems like it would be very easy to add a check if we’re in
> blocking
> > mode and if Send doesn’t honor the spec, loop until we’re done sending so
> > that consumers get expected behavior.  I should write that patch and
> submit
> > it.  I’m pretty sure I haven’t written a bug for the
> BlockingCollection<T>
> > performance issue, nor have I submitted my improved version.  I’m
> capable of
> > contributing to Mono, and I should do so since it’s relevant to my
> interests
> > and business.
> >
> >
> >
> > That being said, giving companies with different business models a way to
> > contribute to the bottom line and thus get more attention for their needs
> > seems like it would help everyone.  Considering what Mono saves us on
> > administrative overhead and licensing costs, there’s no reason my
> business
> > and other businesses wouldn’t consider such a support agreement if it had
> > value.
> >
> >
> >
> >
> >
> > I love this project, and want to see it succeed in more than just mobile.
> > Thanks!
> >
> >
> >
> > From: mono-devel-list-bounces at lists.ximian.com
> > [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Greg
> Young
> > Sent: Wednesday, May 29, 2013 9:09 AM
> > To: mono-devel-list at lists.ximian.com
> > Subject: [Mono-dev] Top again
> >
> >
> >
> > So we have reproduced bugs even with suggestions given (and documented)
> >
> >
> >
> > How do we move forward from this point? We have shown in the past that we
> > don't mind bounties but we are at a point of giving up and saying mono is
> > not acceptable as a server platform. The issues we have will affect
> anyone
> > who wants to build a tcp server.
> >
> >
> >
> > How can we move forward? We have provided failing cases. We have
> provided a
> > fix that has a theoretical deadlock (never actually happened in billions
> of
> > tests).
> >
> >
> >
> > I understand that the core business has moved and tcp servers are not
> common
> > with mobile devices but really? I would expect this kind of issue to be a
> > top priority.
> >
> >
> >
> > Greg
> >
> >
> >
> > --
> > Le doute n'est pas une condition agréable, mais la certitude est absurde.
> >
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130529/48ef9610/attachment-0001.html>