There's also plenty of Server Frameworks with First class support for Mono:
I'm apart of the core team that delivers http://www.servicestack.net (A REST, RPC, SOAP + MQ Service framework) which we've been hosting for years on Linux, initially on CentOS and we're now on a Hetzner Ubuntu vServer which worked out to be 11x cheaper than a lower speced instance on Azure!:
There are other traditional Windows/.NET companies exploring deploying on Linux/Mono since it allows them to scale at $0 licensing cost, here's a post from 7digital showing how they deploy on Nginx/FastCgiMono using Capistrano: http://blogs.7digital.com/dev/2012/09/25/atomic-mono-deploym...
NancyFx (http://nancyfx.org) and SignalR (http://signalr.net) are other great .NET frameworks with Mono CI builds and first-class Linux Support.
I'm going to throw a possibly unpopular view on the table here: sticking all this on Linux is purely about cutting costs but saves nothing.
The administrative overhead of deploying all this stuff is incredible as are the disparate infrastructure and software models. You might be saving 11x on an Azure instance, but your ops time and staffing requirements will cost more than that. Throwing something on Azure is really cheap with respect to time and effort. If you need to scale past that or cost becomes a limitation, you might as well fish out for a Rackspace or other dedicated package.
We're at the £50k hosting budget a month mark now (1x production DC, 1x hot spare DC, 2x packed 42U racks in each) and 2 meat based products to manage it all. Not much of that cost is software licenses.
Note: I have nothing against servicestack - in fact it's rather good (we use servicestack.text)
For ref, I turned down a position at 7digital a couple of years ago as I though they were smoking crack when stuff like this was mentioned.
Unless you're new to the web, you'll be surprised to learn that most of the Internet runs on Linux. It runs because it's a commodity server, because it has first-class support for most NoSQL data stores, caches, proxies, etc. because its highly configurable, because it's much more automatable where everything is scriptable with simple unix commands.
Going to call BS on Azure being cheaper. All of ServiceStack's live demos are deployed using simple bash scripts. There's none of these admin overhead costs, I check-in on my dev box and run a remote script to deploy straight from the Git repo. The projects are also un-touched ASP.NET or stand-alone Console hosts (which I host behind an nginx reverse proxy). I've no doubt that it would be at least 11x more expensive if I decided to host servicestack.net on Azure, even more if I decided to use SQL Server (PostgreSQL/MySQL is free to use on Linux). And I'll also miss out on cool linux utils like rsync which is how we migrated GB's of content onto the new vServer.
The indexable "world wide web" of startups, big tech brands, VC, video sites, porn and blogs about cats falling out of windows, yes.
When it comes to the deep web i.e. corporate applications, business tools etc, it's just not seen at all. These are the things that produce a lot of value and solve a lot of problems. I'd argue they are cumulatively more valuable than the above.
EsEnt, AppFabric, IIS7 ARR, PowerShell cover your concerns above all of which are scriptable and automatable.
When you consolidate your time across the year spent on developing a backup methodology for your server, managing updates etc, monitoring, testing, where does that leave you? I know Linux inside out (I've been a professional user on and off since 1998) and I know you hit the same number of roadblocks as windows along the way.
Also your deployment model sounds odd. Do you check in your production artifacts/dlls and configuration? Do you build on your production boxes? Also your demonstration applications are tiny. A single deployment we throw out has 95Mb of release compiled DLLs across 48 assemblies...
We use NHibernate and have a test harness for MySQL already so we're not bothered about SQL pricing (anyway it's still plenty affordable as our product is valuable and pays for the licensing).
I was using rsync on Windows 2000 back in 2002 to sync press image libraries so that's a moot point really.
Azure cuts it for the ramp up phase of your product if you factor in the above. We did a proper cost analysis.
>> I'd argue they are cumulatively more valuable than the above.
If you're trying to suggest Windows Enterprise applications have more cumulative value than everything else that's running on Linux than I think this is more telling of your limited world view than any kind of reality. Java ranks nearly 3x higher than .NET on the latest TIOBE Programming Community Index http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... and that doesn't include all the other languages running on the JVM platform. In the Open Source space, .NET doesn't even make it on the top 10. How you've concluded Windows provides more cumulative value should provide great content for a MS Facts whitepaper.
>> EsEnt, AppFabric, IIS7 ARR, PowerShell cover your concerns above all of which are scriptable and automatable.
These options pales in comparison to what's available on Unix, which are much more popular and require much less tooling and are more scriptable. Big tooling falls down when you need to do something that's not supported out of the box.
Let's identify big companies that rely on Windows? and I'll come up with a few names that host on Linux. We can start with the worlds most valuable companies and work our way down.
>> Also your deployment model sounds odd. Do you check in your production artifacts/dlls and configuration? Do you build on your production boxes?
We use the repos as they are on Git, every project on Git is self-hosting either in NuGet /packages or contained in the top-level /lib folder (we're moving to NuGet for all future projects). We're currently building with xbuild on our servicestack.net server but as we've recently got Mono/Windows TeamCity CI Builds for ServiceStack's projects, we'll be switching to CI deployments. Also unless it's not perfectly clear, because we deploy from Git only the delta's are pulled in each deployment, so libs that don't change aren't pulled.
>> Azure cuts it for the ramp up phase of your product if you factor in the above. We did a proper cost analysis.
I'm still not buying it. Maybe it makes sense for a Windows-only .NET dev team, but factoring all costs Azure would still cost us at least 11x more.
Well.. I can state that Wells Fargo Bank, Intel, and American Express all have .Net development in-house... As do a lot of other fortune 500 organizations. In fact, I'd be willing to wager that 90% of the F500 list uses Windows, Linux, .Net, Java and other development. The pissing match is moot anyhow. I will say that I feel that Windows + .Net is a much friendlier environment to develop in/with than Java.
That said, the more I "get stuff done" with Node.js, the more I absolutely like it. Many small parts working together, integrating with other systems, and deployable on disparate platforms... It may not be "enterprise" and the tooling may not be there yet.. but doing with a 100-line script what takes a couple of projects in typical "enterprise" fashion is really nice. Our email spool handler is an 84 line node script. Our API service is 122 lines in Node.js (on top of some data migration scripts).
That said, Mono offers a lot... You can run your EXISTING applications on new platforms with minimal retooling, and reduced licensing costs... if you already have nix environments it's less costly all around. If you're new to nix, then sticking with .Net/Windows has other advantages.
Used in conjunction with other platforms is a far cry of being cumulatively more valuable then everything else put together. But I digress.
Agreed Mono does offer a lot of value, it's improved leaps and bounds since Xamarin's split from Novell, they're now well staffed and more focused on delivering their leading best-of-class products. I've witnessed tonnes of improvements to MonoDevelop since their focus on MonoTouch and OSX. From what I've seen at MonkeySpace Xamarin's got plenty more exciting announcements up their sleeve for next year.
With that said, it's making a lot more sense to depend on well supported Mono-compatible libraries so you always have an easy escape option out of the expensive Windows-only cloud provider lock-ins. You'll also have the option to use any of the exciting Linux cloud initiatives on the horizons like: Google Compute Engine / OpenStack.
1. Tiobe is a load of rubbish. Scraping the search engines doesn't give useful statistics - just a talking point. It also backs up my point about the dark web. There are huge swathes of professional software engineers who don't participate in blogs and the open source movement. Also lots of old stale information is out there clogging up the web.
2. Have you ever had to manipulate a heavily nested apache or nginx configuration file with sed/awk? (even with debian's nice sites-available/sites-enabled structure?). The only hope is to write a script to regenerate the files on demand. Chef/puppet make this easier but it's still a pain in the butt. In fact I'd say compared to appcmd, it's an absolute nightmare. I can think of many examples like this.
3. Name 20 companies that are Linux only. I can name 50 in the FTSE100 that are windows only. There is more market value in the companies below the top 100 than there are in the top 100 in most exchanges (do the stats).
4. Thanks for the build clarification. We use TeamCity as well and do integration builds from our VCS master but we publish from team city artefact drops, not from our VCS. We don't use NuGet as it only started to support dependency materialization recently.
I can name 50 in the FTSE100 that are windows only.
Define "windows only". I've worked at several large "windows only" companies, and one thing they all had in common was that lots of people all through the company where using Linux for all kinds of things.
Than pick your vendor neutral index. What non-MS sponsored stats shows Windows server deployments is greater than everything else combined? C# doesn't touch Java let alone anything else that gets deployed on Linux.
>> 2. Have you ever had to manipulate a heavily nested apache or nginx configuration file with sed/awk?
With sed/awk? No why would I need to? Especially for multiple sites / virtual hosts I've found nginx is a lot easier to configure than IIS. Isolated virtual host configs make it easy to maintain. Removing a site becomes as easy as taking down a sym link. Common tasks like Reverse proxying, Url rewriting are a synch.
>> 3. Name 20 companies that are Linux only. I can name 50 in the FTSE100 that are windows only.
Great, this might be our chance to finally get some facts out of you - Looking forward to your "50 in the FTSE100 that are windows only" list.
Re. 2: Have you ever tried to edit windows registry by using regular expressions on the file itself? No... because it's a silly idea to begin with / strawman argument. Store the data in some kind of data base and generate the configuration from templates. Better yet - use modules that just pull the configuration directly from somewhere (ldap for example).
To what level are we going with 3? Really all it takes is a single router / phone / storage appliance / ... and you're not windows only anymore. I guess it depends on your environment and preference too - I tend to run into companies which either don't see a reason to use Windows or use it only in some departments where it makes sense (support for example).
The linux / windows -only company is a strange concept these days anyway. Even Canonical is not a linux-only company in the end, since they have to make sure installer plays well with Windows and they have to develop Wubi.
Re registry editing, it's easy and you can edit it in windows with any script based tools as the registry is a filesystem in powershell. Enumeration example - google the rest:
PS C:\> cd hklm:
PS HKLM:\> cd ./SOFTWARE/Microsoft/windows
PS HKLM:\software\Microsoft\windows> gci
I use C# w/ Windows Server for game servers but I'm in the process of migrating to Linux. Why? Because everything else I have runs Linux so managing an extra OS is a lot of overhead. And Windows Server automation is hugely painful compared to Linux. With Linux automation for example, you can go from Ansibel which is a wrapper around SSH to Chef/Puppet that are very very powerful but much more complicated. With Windows, you get crappy Chef/Puppet support and the MS automation tools (from what I've seen) are too complicated for most people. Even setting up remote Powershell access is painful compared to setting up sshd. In short, there's monetary reasons for running Mono as well.
We're a pretty quiet bunch. There are lots of us - if not thousands. We're not hiring at the minute unfortunately. I've got your email address - will drop you an email if an opportunity comes up.
> We've gotten great up-time with Linux where our last server reached 480+ days up-time before we switched hosts
I'd worry about reliability and security of any service with that kind of uptime. Security if the uptime was achieved by not applying kernel updates, or reliability if some kind of hack to update a running kernel without a reboot was used.
The latter is a reliability problem because rebooting after a major update serves a purpose other than just loading the new kernel. It also serves the purpose of showing that the update has not broken configurations or dependencies required to boot. It's a heck of a lot better to discover that an update has left your system non-bootable right after the update, rather than finding out months later when some hardware failure takes down the server and then you find it doesn't boot and you've got to go back through months of changes trying to figure it out.
...I imagine that "showing that the update has not broken configurations or dependencies required to boot" would be addressed by having testing the configuration on an exact mirror of the production server, including rebooting, right? (of course, after a reboot the testing server is technically no longer a mirror of the production one...)
...of course, the OP should enlighten us about whether this is how they did things
Well, i don't agree here.
You have the exact same system to test updates first, before rolling out on production!
Just rebooting "because there may be something, let's see if it still works".. nahh, we're not running Windows here ;)
By the way, I have had servers running several years on the internet, without problems, one FreeBSD which topped all until some hardware maintenance was necessary.
I love Miguel et al. but I tried for a long time to make a public ASP.Net (MVC2) site work. It would run fine for a few days but inevitably would become unstable where the Mono Apache process would runaway and put the CPU beyond 100% usage (how is that even possible?). After a year of doing weekly restarts I couldn't take it anymore and moved back to Windows. The extra $30 / month in Windows licensing on Racksapce more than paid for itself in the IT headaches (and expenses) it saved.
Things may have since changed - this was back in v2.12 days - and / or other stacks (like service stack) may be more stable, but it's just easier for me to stick with Windows.
With all this said, however, I have had fun trying the MonoTouch toolkit demos. I hope to find some time to build a real iOS app (one that works with the aforementioned website, in fact). Fingers crossed things will work out better this time for me and Mono.
You're going to always have a better experience from Web Frameworks that officially support and have tested their stuff on Mono.
We've added special normalizing support to match the behaviour of IIS/ASP.NET where we can, e.g. imitate redirects + case-insensitive file paths, etc. This reduces the differences when porting your ASP.NET app across to run on Linux.
Now that it's open source and MVC is accepting patches, MVC3 might be more stable on Mono.
I think the problem here specifically is mod-mono and the fastcgi server (basically the xsp-derived glue). I've seen a number of people complain about memory leaks and instability and having to restart apache. It's not readily reproducible but it's enough to make people too nervous to deploy.
Those sub-projects appear to be unmaintained and queries about their status on the mailing list go unanswered. Without some solid info there, it unfortunately makes the open source MVC stuff rather moot.
I concluded (perhaps wrongly?) that web wasn't a priority for mono and chose another technology for that part. On the other hand, mono makes a great socket server stack, and I still use it extensively there.
With the craziness that's leading to WPF / Silverlight being deprecated in favour of a sand-boxed Metro UI, it seems like MonoMac is looking like the best place to create full-featured Desktop apps with.
Played with MonoMac on the weekend, it was super easy to get going and the bindings are nicely polished in idiomatic C# (uses same technology as used in MonoTouch). The bindings end up a close match to the official Obj-C APIs. Easy to translate Cocoa docs to C# APIs (which end up being nicer IMHO). It was also seamless to create UIs in XCode and access them in C#.
Word, monomac isn't too bad, as long as you remember to do all your work within monodevelop (notably modifying xib's / setting up outlets - monodevelop impressively sets up a fake project to 'sync' changes with xcode 4).
Ideally I'd expect to see more CAD/Drawing/Creation-focused apps using monomac. I actually keep wondering if rhino3d is using it since that's a .net-based application.
Mono seems to be becoming what Java could have been if Sun had been sensible--a VM-based garbage collected system with a lot of high level portable libraries that gives you a lot of cross platform capability, BUT that is happy to let you write a Windows program or a Mac program or a Linux program if that's what you want.
I'm told it's gotten a lot better in Java land, but back in the early days invoking native code was quite a pain. There were whole books available on how to deal with this dark art.
The main thing, though, was simply attitude. Sun's attitude was that Java was a separate platform. You write for Java. It is an inconvenient truth that any given instance of Java happens to be running on Windows, or Linux, or Mac, or whatever--don't worry about that and you just stick to the Java platform. If you wanted to have a native interface with Java computations code, you were thinking heretical thoughts. So, Java came with AWT and Swing. It would have been inconceivable for Sun to include a GUI meant just for Windows, and one meant just for Mac, and so on.
You want to do that in Mono. They are fine with that. They include a GUI interface for Mac that only works on Mac. They include a WinForms interface for developing Windows native stuff (although they do somewhat support it on non-Windows so people can use it to port Windows stuff).
The Mono developer's attitude seems to be more toward providing useful tools to programmers, so we can do what we want, rather than trying to provide a platform that we should leave our native platforms for.
To put it succinctly, if you said "I want to write a Windows program" or "I want to write a Mac program", Sun would have said "Write a Java program instead!". The Mono people say "Cool. We've got some neat tools you can use for that!".
Also the difference between using .NET's P/Invoke (DllImport) interface versus Java's JNI is about as big as can be in terms of developer pain and overhead.
Have a look at JNA. It's about as easy to use as P/Invoke.
Of course Java's days on the desktop are kind of numbered with the various browser and OS vendors getting visibly concerned about the security of the JRE, but that's a different matter.
Unfortunately it's still a huge pain to use JNA with stuff that returns unions (or a pointer to different type depending on the usage context). That makes things like X libraries wrappers really difficult to write in a clean way.
At last week's MonkeySpace I sat in an awesome demo of Don Syme (Mr F#) show casing F#'s 3.0 type providers support in Mono on OSX! MonoDevelop had run-time intelli-sense of Type Providers and he was running code inside the built-in F# REPL in MonoDevelop.
Extremely happy that Mono is doing so great recently.
Politics aside, the MSR people did a beautiful job designing the system and it's very saddening how it's currently misused by the mother corporation. It's good that it gets a chance to thrive beyond their suffocating grasp.
Yes, and it's cool, but not as awesome as the demos make it seem.
There are basically three major downsides:
1) It's another at least $399 x 2 as a single developer to use (but you can develop against it for free and only buy the license when you want to deploy). Professional licenses are more expensive than that.
2) The runtime can take a long time to load. 3-5 seconds for some apps. You can create a splash screen to mitigate this, but it's a *t experience when you do an a/b comparison on a native app and a mono app (this time is basically while it loads the runtime).
3) 3rd party library support sucks. It just doesn't really exist; if you're used to pulling nunit, ninject, shouldly, nhibernate, nsubstitute, etc. into your project, forget it. A handful of libraries have been ported to the touch and android runtimes, but most of things you'll look at either won't work or you'll have to recompile manually (to be fair there are a fair few that are easy drop ins; Dapper works like a charm for example).
That said, you get some pretty cool stuff: you can separate your core application logic, including database access into its own library and share the code between your various projects. Fix once, fix everywhere.
You can have common unit tests that you can run on a non-windows server.
It's vastly more productive (than writing two code bases in objective c and java).
You can develop without using visual studio~ <3 (some people see this as a downside; it's not to me. VS2010 is rubbish as far as I'm concerned; it crashes, freezes, loses my work all of the time. For all that I love resharper, I'll take monodevelop in a second thanks).
You said Dapper works on MonoTouch—did you make any changes to it? I've read[1] there are quite a few problems with it so I had to choose Sqlite over it. I also found this[2], not sure if it helps. What's your experience with Dapper/MT?
We're in the process of porting our Flight Simulator (Infinite Flight - http://infinite-flight.com) from iOS to Android. We originally developed it on Windows Phone.
Porting from WP7 to iOS took a few months, mostly because MonoGame didn't have any 3D support (we added it). We have been slowly porting to Android, it's been pretty good so far, the framework makes it easy and we've had very little issues making external libraries build on MonoDroid.
Xamarin's also been very responsive to our questions and issues.
I'm surprised you're so high on MonoGame, though I guess if you started with XNA it makes a lot of sense for you.
I find the project to be deeply hurt by being tied to the XNA ecosystem (the content pipeline is a mess, especially as you can't build content stuff in MonoGame itself, and Android support is atrocious--dealing with a destroyed context is insanely messed up). I'm also pretty disappointed in the lack of professional behavior--no CI, few/no automated tests, and few/no code reviews have led to some serious WTFs that sneak in that are really unsettling. There's a lack of project leadership, too, in that if you'd like to contribute there are no real designated maintainers or developers with responsibility over submodules (I've tried myself, multiple times, to no real success).
I think the best way forward for Mono and games would be a library, starting with MonoGame or not, that followed better practices and didn't try to make square pegs fit in round holes. There are a lot of areas where it makes sense for Mono to ape the .NET APIs but this doesn't seem like one of them.
If I could possibly offer an alternative to MonoGame, perhaps try libgdx game framework with MonoTouch. Libgdx is a very well developed framework for Java, but the creator has also put together guides on how to use it with Monotouch.
I like Mario a lot, and I use libgdx for some of my stuff (and am looking at contributing some gamepad stuff to it when I get around to writing it), but despite its quality--which is very good, and the primary developers are professionals who know what they're doing--it is not in the same conversation as MonoGame.
No Metro support (and I find it very unlikely Microsoft will allow Java apps in their Metro store, and almost definitely not on ARM devices) and a reliance on IKVM on one of the major mobile platforms makes it a poor choice for greenfield development if you care about those platforms.
It's really, really great for desktop and Android, though.
There were lots of demos showing cross-platform Android / iOS and even OSX! (with MonoMac :).
I met the creators of iCircuit and TouchDraw at MonkeySpace they said it was really easy to get going and you just needed to design your library so the UI was decoupled from the main code-base (which you could effectively re-use as-is). Several of techniques of structuring your code-base was described in @gshackles talk, some of the slides are here:
MonoGame (https://github.com/mono/MonoGame) is an implementation of XNA which allowed games like Bastion and Infinite Flight (A C# Flight Simulator) to run cross-platform.
I've been using it for Android development for about 8 months and I've got no complaints so far. App startup time hasn't been a problem, and I'm getting good levels of code reuse across Windows and Android.
I'm impressed by how quickly they've been able to add much of the significant features of C# 5.0 and .NET 4.5 -- in particular, async/await. Visual Studio 2012 has only been out for one month.
I've been using Node.js more and more for simple services, scripts etc.. and that's on Windows. Have some data migration process scripts in Node.js because going from a flat structure across many database tables (with weird joins etc), to a hierarchical object structure was far easier in Node.js. The output was dumping to .json.gz files to be called from a simple service, in addition to a statuslist.json file... the partner wanted a filter... was faster/lighter to re-use the node.js implemented parts, and re-implement the 4 api calls in node using ARR as a reverse proxy from IIS.. works great, and now handles the edge cases better... Was under 3 hours of work.
I know this isn't Mono, of which I've been a big fan, and it's my first go-to for building certain applications cross platform, but have to admit that Node.js seems to be a better workflow, when you want to get a small task done. No spooling up a new project in VS, with build efforts. It just works.
Now if only more people would use Mono and more community .NET projects. Everyone who wants to use .NET feels that if it's not Entity Framework, SQL Server(Azure), Windows Azure, .NET 4.5 that it's not worth even considering.
We recently switched to PostgresSQL after we had some very disturbing performance issues using floppy drives with MongoD... oh... Mono 3.0.. uh, nevermind.
I'm apart of the core team that delivers http://www.servicestack.net (A REST, RPC, SOAP + MQ Service framework) which we've been hosting for years on Linux, initially on CentOS and we're now on a Hetzner Ubuntu vServer which worked out to be 11x cheaper than a lower speced instance on Azure!:
https://speakerdeck.com/mythz/what-is-the-servicestack?slide...
We've gotten great up-time with Linux where our last server reached 480+ days up-time before we switched hosts: http://www.servicestack.net/mythz_blog/?p=838
There are other traditional Windows/.NET companies exploring deploying on Linux/Mono since it allows them to scale at $0 licensing cost, here's a post from 7digital showing how they deploy on Nginx/FastCgiMono using Capistrano: http://blogs.7digital.com/dev/2012/09/25/atomic-mono-deploym...
NancyFx (http://nancyfx.org) and SignalR (http://signalr.net) are other great .NET frameworks with Mono CI builds and first-class Linux Support.