Snowden is quoted on Greenwald's new book "No Place to Hide" as wanting to both spark a debate over the use of surveillance and to get software developers to adopt and create better encryption:
While I pray that public awareness and debate will lead to reform, bear in mind that the policies of men change in time, and even the Constitution is subverted when the appetites of power demand it. In words from history: Let us speak no more of faith in man, but bind him down from mischief by the chains of cryptography.
The shock of this initial period [after the first revelations] will provide the support needed to build a more equal internet, but this will not work to the advantage of the average person unless science outpaces law. By understanding the mechanisms through which our privacy is violated, we can win here. We can guarantee for all people equal protection against unreasonable search through universal laws, but only if the technical community is willing to face the threat and commit to implementing over-engineered solutions.
Last week Matthew Green asked:
So has Snowden succeeded? Have developers 'created better encryption' since his leaks?— Matthew Green (@matthew_d_green) May 14, 2014
Only time will be able to answer whether as a community the tech world can devise better and simpler tools for normal users to have their privacy protected by default.
Snowden has succeeded in starting an important discussion and having software developers and their patrons react to the news.
At Xamarin we build developer tools for Android and iOS developers. It is our job to provide tools that developers use on a day to day basis to build their applications, and we help them build these mobile applications.
In the last year, we have noticed several changes in our developer userbase. Our customers are requesting both features and guidance on a number of areas.
Developers are reaching to us both because there is a new understanding about what is happening to our electronic communications and also response to rapidly changing requirements from the public and private sectors.
Among the things we have noticed:
Sometimes developers can use the native APIs we provide to achieve the above goals, but sometimes the native APIs on Android and iOS make this very hard or do not expose the new desired functionality, so we need to step in.
Posted on 21 May 2014
Some great announcements today from the Microsoft world.
The first one is that Microsoft's next generation web stack (ASP.NET vNext) is open source from the ground up, and runs on Mono on both Linux and Mac.
There are plenty of other design principles in this new version of ASP.NET. I provide a translation from Microsoft speak into Unix speak in parenthesis:
Update: And the software is live at http://github.com/aspnet
They are shipping a number of new components to talk to their online services, and they all have a license suitable for being used from platforms other than Windows.
Posted on 12 May 2014
As promised, we are now tracking the Unix-friendly Roslyn port on Mono's GitHub Organization.
We implemented a few C# 6.0 features in Mono's C# compiler to simplify the set of patches required to compile Roslyn.
So you will need a fresh Mono (from git).
Posted on 28 Apr 2014
The team has put together some beautiful getting started documentation for our iOS User Interface Designer.
In particular, check a couple of hot features on it:
Posted on 14 Apr 2014
We have been working with a few PlayStation 4 C# lovers for the last few months. The first PS4 powered by Mono and MonoGame was TowerFall:
We are very excited about the upcoming Transistor, by the makers of Bastion, coming out on May 20th:
Mono on the PS4 is based on a special branch of Mono that was originally designed to support static compilation for Windows's WinStore applications .
 Kind of not very useful anymore, since Microsoft just shipped static compilation of .NET at BUILD. Still, there is no wasted effort in Mono land!
Posted on 14 Apr 2014
Last week, Microsoft open sourced Roslyn, the .NET Compiler Platform for C# and VB.
Roslyn is an effort to create a new generation of compilers written in managed code. In addition to the standard batch compiler, it contains a compiler API that can be used by all kinds of tools that want to understand and manipulate C# source code.
Roslyn is the foundation that powers the new smarts in Visual Studio and can also be used for static analysis, code refactoring or even to smartly navigate your source code. It is a great foundation that tool developers will be able to build on.
I had the honor of sharing the stage with Anders Hejlsberg when he published the source code, and showed both Roslyn working on a Mac with Mono, as well as showing the very same patch that he demoed on stage running on Mono.
The source code as released contains some C# 6.0 features so the patches add a bootstrapping phase, allowing Roslyn to be built with a C# 5.0 compiler from sources. There are also a couple of patches to deal with paths (Windows vs Unix paths) as well as a Unix Makefile to build the result.
Sadly, Roslyn's build script depends on a number of features of MSBuild that neither Mono or MonoDevelop/XamarinStudio support currently , but we hope we can address in the future. For now, we will have to maintain a Makefile-based system to use Roslyn.
Our patches no longer apply to the tip of Roslyn master, as Roslyn is under very active development. We will be updating the patches and track Roslyn master on our fork moving forward.
Currently Roslyn generates debug information using a Visual Studio native library. So the /debug switch does not work. We will be providing an alternative implementation that uses Mono's symbol writer.
Our goal is to keep track of Roslyn as it is being developed, and when it is officially released, to bundle Roslyn's compilers with Mono .
But in addition, this will provide an up-to-date and compliant Visual Basic.NET compiler to Unix platforms.
Our plans currently are to keep both compilers around, and we will implement the various C# 6.0 features into Mono's C# compiler.
There are a couple of reasons for this. Our batch compiler has been fine tuned over the years, and for day-to-day compilation it is currently faster than the Roslyn compiler.
The second one is that our compiler powers our Interactive C# Shell and we are about to launch something very interesting with it. This functionality is not currently available on the open sourced Roslyn stack.
In addition, we plan on distributing the various Roslyn assemblies to Mono users, so they can build their own tools on top of Roslyn out of the box.
Roslyn really shines for use in IDEs.
We have started an effort to adopt Roslyn in MonoDevelop/Xamarin Studio. This means that the underlying NRefactory engine will also adopt Roslyn.
This is going to be a gradual process, and during the migration the goal is to keep using both Mono's C# compiler as a service engine and bit by bit, replace with the Roslyn components.
We are evaluating various areas where Roslyn will have a positive impact. The plan is to start with code completion  and later on, support the full spectrum of features that NRefactory provides (from refactoring to code generation).
While not related to Roslyn, I figured it was time to share this.
For the last couple of months, the ECMA C# committee has been working on updating the spec to reflect C# 5. And this time around, the spec benefits from having two independent compiler implementations.
Our goal is to contribute fixes to the Roslyn team to make sure that Roslyn works great on Unix systems, and hopefully to provide bug reports and bug fixes as time goes by.
We are very excited about the release of Roslyn, it is an amazing piece of technology and one of the most sophisticated compiler designs available. A great place to learn great C# idioms and best practices , and a great foundation for great tooling for C# and VB.
Thanks to everyone at Microsoft that made this possible, and thanks to everyone on the Roslyn team for starting, contributing and delivering such an ambitious project.
 Roslyn uses a few tracing APIs that were not available on Mono, so you must use a newer version of Mono to build Roslyn.
 We even include the patch to add french quotes that Anders demoed. Make sure to skip that patch if you don't want it :-)
 From Michael Hutchinson:
<Reference Include="Microsoft.Build, Version=$(VisualStudioReferenceAssemblyVersion), Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
AllowNonModulatedReferencemetadata on some references and it's completely undocumented, so I have no idea what it does and what problems might be caused by not handling it in xbuild.
 Since Roslyn is much better at error recovery and has a much more comprehensive support for code completion than Mono's C# compiler does. It also has much better support for dealing with incremental changes than we do.
private. They use
private everywhere, and that is just plain ugly.
 We will find out a way of selecting which compiler to use,
mcs (Mono's C# Compiler) or Roslyn.
Posted on 09 Apr 2014
Herb Sutter from the ISO C++ group, reached out to the Cairo folks:
We are actively looking at the potential standardization of a basic 2D drawing library for ISO C++, and would like to base it on (or outright adopt, possibly as a binding) solid prior art in the form of an existing library.
we are focused on current Cairo as a starting point, even though it's not C++ -- we believe Cairo itself it is very well written C (already in an OO style, already const-correct, etc.).
Congratulations to the Cairo guys for designing such a pleasant to use 2D API.
But this would not be a Saturday blog post without pointing out that Cairo's C-based API is easier and simpler to use than many of those C++ libraries out there. The more sophisticated the use of the C++ language to get some performance benefit, the more unpleasant the API is to use.
The incredibly powerful Antigrain sports an insanely fast software renderer and also a quite hostile template-based API.
We got to compare Antigrain and Cairo back when we worked on Moonlight. Cairo was the clear winner.
We built Moonlight in C++ for all the wrong reasons ("better performance", "memory usage") and was a decision we came to regret. Not only were the reasons wrong, it is not clear we got any performance benefit and it is clear that we did worse with memory usage.
But that is a story for another time.
Posted on 04 Jan 2014
Few guys have approached us recently about doing remote debugging of a Mono process. Typically this involves an underpowered system, or some kind of embedded system running Mono, and a fancy Mac or PC on the other end.
These are the instructions that Michael Hutchinson kindly provided on how to remotely debug your process using either Xamarin Studio or MonoDevelop:
Remote debugging is actually really easy with the Mono soft debugger. The IDE sends commands over TCP/IP to the Mono Soft Debugger agent inside the runtime. Depending how you launch the debuggee, you can either have it connect to the IDE over TCP, or have it open a port and wait for the IDE to connect to it.
For simple prototyping purposes, you can just set the
MONODEVELOP_SDB_TESTenv var, and a new "Run->Run With->Custom Soft Debugger" command will show up in Xamarin Studio / MonoDevelop, and you can specify an arbitrary IP and port or connect or or listen on, and optionally a command to run. Then you just have to start the debuggee with the correct
--debugger-agentarguments (see the Mono manpage for details), start the connection, and start debugging.
For a production workflow, you'd typically create a MonoDevelop addin with a debugger engine and session subclassing the soft debugger classes, and overriding how to launch the app and set up the connection parameters. You'd typically have a custom project type too subclassing the DotNetProject, so you could override how the project was built and executed, and so that the new debugger engine could be the primary debugger for projects of that type. You'd get all the default .NET/Mono project and debugger functionality "for free".
You can get some inspiration on how to build your own add-in from the old MeeGo add-in. It has bitrotted, since MeeGo is no more, but it is good enough as a starting point.
Posted on 29 Oct 2013
I am hiring software developers.
We are growing our Xamarin Studio/MonoDevelop, Visual Studio, iOS and Android teams.
Ideally, you are a C# programmer and ideally, you relocate to Boston, MA. But we can work with remote employees
Posted on 22 Aug 2013
Check their home page on GitHub with cute videos!
PlayScript is a superset of ActionScript and it was based on Mono's C# 5.0 compiler. PlayScript is ActionScript augmented with C# 5.0 features.
Zynga's PlayScript allows developers that have some ActionScript/Flash code to bring their code to any platform that supports the ECMA Intermediate Language (Microsoft .NET and Mono) and blend it with other .NET languages.
But the PlayScript has a fabulous feature, it allows mixing code in both C# and PlayScript in the same compilation unit. For example, you can use the compiler like this:
# Compile the C# source foo.cs into foo.exe $ mcs foo.cs # Compile the Playscript source bar.play into bar.exe $ mcs bar.play # Compile both C# and Playscript into a single executable $ mcs foo.cs bar.play
On a larger scale, you can see this in action in the pscorlib library. This library contains a blend of PlayScript and C# source code compiled into a single binary.
They have also an add-on for Xamarin Studio that you can use to get IDE support for it.
Just like Unity's UnityScript, developers will be encouraged to use strong types to improve the performance of their applications.
Update: Some background on Playscript.
Posted on 20 Aug 2013