Git was originally developed for the Linux kernel and is mainly for the open source community. I was interested to see JavaScript, the language of HTML 5, riding so high. PHP, C and C++ are lower than I would have guessed, Ruby and Python higher.

Here are some figures for the venerable Sourceforge:

Java (7,163)		19%
C++ (6,449)		17%
C (4,752)		13%
PHP (3,521)		10%
Python (2,694)		7%
C# (2,481)		7%
JavaScript (2,011)		5%
Perl (1,138)		3%
Shell (757)		2%
Visual Basic NET (688)		2%
Delphi/Kylix (581)		2%

This comes with a health warning. I have taken the figures from the what you get if you browse the directory and drop down Programming Languages; but the total is only about 37,000, whereas Sourceforge hosts around 324,000 projects. I am not sure what accounts for the discrepancy; it could be that language is not specified for the other projects, or they are dormant, or some other reason. But I hope the proportions indicate something of value.

Github is madly trendy, and Sourceforge ancient, so this tells us something about how open source activity has shifted towards JavaScript, Ruby and Python, and away from Java, C/C++ and C#.

Of course the overall picture of programming language usage is quite different. For example, you can get some kind of clue about commercial activity from a job board like indeed.com, which currently has 77,457 US vacancies for Java, 22,413 for JavaScript, and only 5030 for Ruby.

Nevertheless, interesting to see what languages developers on Github are choosing to work with, and perhaps an indicator of what may be most in demand on the job boards a few years from now.

Finally, looking at these figures I cannot help thinking how short-sighted Microsoft was in abandoning IronPython and IronRuby back in 2010.

Related posts:

1. PyCharm: JetBRAINS IDE for Python and Django
2. What is the best programming language for a child progressing from Scratch?
3. No more Ruby support in NetBeans – the feature was little used, says Oracle

So how do you install it? One line on Linux; but I did not want to put it on my web server and I re-purposed my spare Linux machine last year after one of my other servers broke.

I decided to run up a Debian install on a Hyper-V server that has a little spare capacity.

I then followed the setups here for setting up Node.js and npm (Node Package Manager). I also installed nginx which I have been meaning to try for a while. Linux on Hyper-V works fine, though you have to use a “Legacy” network adapter which compromises performance a bit, unless you are willing to tackle installing Microsoft’s Hyper-V integration components for Linux, which do not support Debian though it is said to work. I do not need a GUI and the legacy network adapter is OK for this.

Everything works OK, though I found that nide does not work in Internet Explorer 9. I used Google Chrome, which makes sense I guess since the same JavaScript engine is used by Node.js.

Nide is a simple affair which is essentially a file manager. Projects are displayed in a tree view, and you select a file to view or edit it. The icons at the bottom left of the screen let you create and delete files and folders.

The smartest feature is version management. Files are saved automatically and you can easily compare versions and revert if necessary. The “Go backward in time” button shows that auto-saves are quite frequent.

There is also a GUI for npm built-in. Pretty good for a competition entry, though I had a few problems.

If you are interested in web-based IDEs, another interesting one is Orion, an Eclipse project.  Executive Director Mike Milinkovich says Orion will ship a 1.0 release later this year.

Related posts:

1. Microsoft partners with Joyent to bring node.js server-side JavaScript to Windows
2. Don’t miss Ryan Dahl on Node.js
3. Getting started with VMWare Cloud Foundry

All good; but techie users are upset that the bootloader is encrypted, which means the kernel cannot be modified other than through official Asus updates.

A petition on the subject has achieved over 2000 signatures. Detailed discussion of the implications are here.

Why do vendors lock the bootloader? One reason is for support, since it increases the user’s ability to mess up their machines. On the other hand, most users who hack to this extent understand what they are doing. This comment from the petition stood out for me:

We understand that custom firmware cannot be supported by ASUS, but we consider that it is our right to customise our devices in any way we wish: once bought, the Prime is our property alone to modify if we choose.

This is something we have taken for granted in the PC era, but the tablet era is looking different, with locked-down devices that give vendors more control. The success of the Apple iPad suggests that most users do not mind if the result is a good experience. It is a profound change though, and one that makes users vulnerable to vendors who are slow or reluctant to provide updates.

Related posts:

1. Asus Transformer Prime update: Google video rental or unlocked bootloader, you choose
2. Hardware vendors chase Apple’s iPad at CES with Android, not Windows
3. Half-baked Android tablets will help Apple, give hope to Microsoft

I recall that when .NET was first announced in 2000, it was not long before de Icaza announced Mono. I was interested therefore to know his reaction to Windows 8 and the new Window Runtime which powers “Metro-style” apps. Will we get an open source implementation of Metro-style on Linux?

I don’t think so. To be honest, with Linux on the desktop, the benefits of open source have really played against Linux on the desktop in that we keep breaking things. It is not only incompatibilities between Red Hat, Unbuntu, Suse, but even between the same distribution.  Ubuntu from this week is incompatible with the one nine months ago. And then there are multiple editions, the KDE version, the Gnome edition, the one that is the new launching system.

When you count how many great desktop apps there are on Linux, you can probably name 10. You work really hard, you can probably name 20. We’ve managed to piss off developers every step of the way, breaking APIs all the time.

I’m heartbroken, that’s the bottom line.

What about compiling your Metro app for iOS or Android?

I think that Linux has a tough time on the desktop. And the desktop is starting to not matter any more. On the other hand, building WinRT is going to be a significant amount of work. A large chunk probably could be reused from Moonlight. But it is a lot of work, to be able to reuse existing Windows apps, and in the case of iOS they already have their own stack, and Mac has its own, Cocoa is really nice and we have .NET bindings for it.

So I think we’ll learn interesting lessons from Metro. There is stuff that will be useful on other platforms like the JSON reader. But I’m not going to spend any time on WinRT for other systems.

And we can speculate about how well Metro will work in the market …

They are Microsoft, it’s going to succeed. In three years they are going to have this thing on half a billion computers, so it will be out there.

It seems like they are going to use their muscle for two things. It’s going to be a tempting space [for developers], but if you want to go into the right distribution channel for that half a billion computers, you need to abide by the Metro guidelines. They are not going to give you full API access, they are going to give you the sandboxed version. Which is good, because it can finally fix the security problems on Windows. They are going to use their muscle to reset the rules for Windows.

Especially on ARM

Right, and it is needed, they definitely need to fix this mess, a lot of malware, spyware, and the fact that everybody is sysadmin, and has to reinstall their machine every so often.

I’ve heard the word “safe” a number of times.

Right, and think of an iPad, you don’t need to be a sysadmin.

Now, you could argue that by WPF not being available to everybody and being bound to .NET they limited the effect WPF would have had, whereas Metro gives this to C++ developers, but they’re saying, hey, you can’t call Win32, there is all the Win32 stuff you can’t call. You have to use Metro. So they might be repeating that [mistake], but maybe it’s eclipsed by the fact that there’s going to be a rush to the app store. It seems like there is a big enough carrot now.

How are you getting on with the Windows 8 tablet?

I have to say, I actually like Windows 8. I am not a Windows user. It’s probably the first time that I would use a Windows machine.

Miguel de Icaza is now at Xamarin, providing cross-platform tools for using C# and .NET to build apps for Apple iOS and Google Android.

Related posts:

1. Miguel de Icaza on eight years of Mono, its future, and the Silverlight desktop
2. Miguel de Icaza on ODF vs OOXML
3. Data Access in Windows 8 WinRT

We are putting Delphi (and C++Builder) everywhere this year and over the next 5 years. Today you can use Delphi for Desktop, Client/Server, Multi-Tier, Cloud, Web, Web Services (REST and SOAP). This year you will also be able to build for Macintosh and iOS. Linux is also on the roadmap for the coming years along with Android, Blackberry and Windows Phone 7.

Welcome news; though Delphi enthusiasts are all too familiar with bold promises. Two years ago I interviewed Embarcadero’s CEO Wayne Williams and he promised cross-platform Delphi in 2010; but when Delphi XE appeared last year neither Mac nor 64-bit (another longstanding request) was included.

That said, I am still a big Delphi fan. Mobile is a particularly interesting prospect. I have tried numerous cross-platform mobile toolkits and they all have problems; on the other hand they are improving fast and in a couple of years things like Appcelerator’s Titanium and  Nitobi’s PhoneGap may be hard to catch.

Update: what will Delphi’s Android support look like? I would be interested to know whether Embarcadero is working on its own compiler, or whether it is partnering with RemObjects and that what Intersimone is referring to is Project Cooper:

“Cooper” is a new and exciting research project going on in the RemObjects Software Labs, to bring the Oxygene language to the Java and Android platforms. The original Oxygene for .NET set out to bring a modern and “next generation” Object Pascal to the .NET world; Project “Cooper” is taking this endeavor to the next level, expanding the reach of Oxygene to the second big managed platform.

In other words, Project Cooper will compile Delphi code to Java.

Note that Embarcadero officially adopted Oxygene and offers it as its own product called Prism. It seems plausible that the same will happen with Project Cooper. Since Windows Phone is a .NET platform, there is also potential for Oxygene/Prism to target Microsoft’s mobile platform:

Windows Phone 7 – Microsoft’s new Windows Phone 7 uses Silverlight for application development,  and did I mention Delphi Prism does Silverlight?

says Jim McKeeth at RemObjects.

What about Delphi on the Mac and on iOS? There is also a possible Oxygene/Prism route here, via MonoMac: Delphi to .NET/Mono to Mac. However, I suspect Delphi developers would be disappointed if this turned out to be Embarcadero’s approach to Mac and iOS support. Programmers choose Delphi because they like compilation to native code.

Related posts:

1. Oxygene for Java released: develop for Android and Java runtime with Delphi language in Visual Studio
2. Prism: official Delphi language comes to Visual Studio
3. What next for Embarcadero Delphi? Roadmap with Mac, Linux support published.

To support the variety of Linux-based platforms across PCs and devices, we are prioritizing a Linux porting kit for AIR (including source code), which Open Screen Project (OSP) partners can use to complete implementations of AIR for Linux-based platforms on PCs, mobile devices, TVs and TV-connected devices. We will no longer be releasing our own versions of Adobe AIR and the AIR SDK for desktop Linux, but expect that one or more of our partners will do so. The last Adobe release of AIR for desktop Linux is AIR 2.6.

This is a curious message. OSP partners include ARM, Intel, the BBC, Google, Toshiba and other big names; but which of these might build an AIR SDK and on what sort of terms might it be supplied? Or it is more likely that, say, the BBC will deliver BBC iPlayer for LInux in a bundle that includes the AIR runtime? Or is it just wishful thinking?

Adobe’s open source evangelist Dave McAllister has a go at defending the decision, pointing out that the growing client operating systems are Android and iOS, not desktop Linux, and that AIR for Linux accounts for only a 0.5% download share. However, Linux developers observe that Adobe’s AIR for Linux effort has always been half-hearted and tricky to install, especially on 64-bit installations. AIR itself is still 32-bit, as is the Flash Player on all systems, though there is 64-bit version in preview codenamed “Square”.

Most people run Windows or Mac desktops, and will not miss AIR for Linux. That said, decisions like this do undermine confidence in the Flash platform as a cross-platform proposition. The problem is, Flash technology is not open source and ultimately whether a particular platform is supported is a matter for Adobe, with all the commercial and political factors that implies.

The risk for Adobe is that when it abandons smaller platforms, it make open standard alternatives and in particular the collection of web technologies we call HTML5 more attractive.

Related posts:

1. Adobe AIR 2.6, MonoMac 1.0, cross-platform is not dead yet
2. Adobe abandons Project ROME, focuses on apps rather than cloud
3. All-new Adobe Audition is re-written for cross-platform, some features not yet ported

Although Nokia has been an important partner to Intel and MeeGo and we are disappointed by this decision, it’s important to know that this is by no means the end of MeeGo or the end to Intel’s commitment

says Ramirez, adding that “MeeGo is not just a phone OS”.

True; but with the focus also moved away from netbooks it is getting hard to see where MeeGo will have an opportunity to shine.

Intel promises to outline its mobile strategy this week at Mobile World Congress. I will be reporting from Barcelona in due course.

Related posts:

1. Nokia Maemo, Intel Moblin gives way to MeeGo
2. MeeGo, Qt, and the new Nokia: developers express their doubts
3. MeeGo NoGo: things look bad for the Intel/Nokia Linux project

Here is what Nokia says:

Under the new strategy, MeeGo becomes an open-source, mobile operating system project. MeeGo will place increased emphasis on longer-term market exploration of next-generation devices, platforms and user experiences. Nokia still plans to ship a MeeGo-related product later this year.

Nokia is retaining MeeGo but it has moved from centre-stage to become more niche and experimental.

The snag for developers is that there are no known plans to support Qt on Windows phone. According to the letter to developers, Qt developers can look forward to the targeting low-end Symbian devices and at least one solitary MeeGo phone:

Extending the scope of Qt further will be our first MeeGo-related open source device, which we plan to ship later this year. Though our plans for MeeGo have been adapted in light of our planned partnership with Microsoft, that device will be compatible with applications developed within the Qt framework and so give Qt developers a further device to target.

Reaction from developers so far is what you might expect:

By this announcement, I’m afraid you’ve lost many faithful people (developer and consumers) like myself, who’s been a Nokia user ever since I’ve started using cellphones..

and

Wow what can I say, nokia just flat out killed any enthusiasm I had to develop on nokia platforms, I never have and never will use a windows platform. You have just killed QT, even worse killed the most promising OS out there in Meego. Elop is the worst thing that has ever happened Nokia.

and

Weak on execution, you choose to flee. What a sad day in the history of a once proud and strong company.

Nokia could fix this by demanding Qt support for Windows Phone 7.

Related posts:

1. Intel disappointed with Nokia’s Microsoft move, still backing MeeGo
2. Qt will not be ported to Windows Phone 7 says Nokia
3. Nokia Maemo, Intel Moblin gives way to MeeGo

Basically by all accounts MeeGo is stopping all work on the Netbook UX. Yup, all our hard work is now almost for nothing

This is remarkable. The original Moblin project, sponsored by Intel, was all about bringing an excellent user experience to Linux on netbooks. The first netbooks ran Linux, but met resistance from a general public familiar with Windows; yet Linux is more suitable for netbooks than Windows in its present form.

Moblin is different. It’s a friendly way to get the most out of your netbook. It doesn’t work like most other computers because it’s optimized for enjoying media, interacting with your social networks and the internet.

wrote Moblin Community Manager Paul Cooper back in 2009, when netbooks were hot.

The problem: tech trends sometimes outpace corporate planning. Moblin was a good idea in 2008, but nothing was delivered; and by the time it looked like it might be ready, the market seemed to want tablets – or Apple iPads – rather than netbooks; and whatever problem Moblin was addressing was already solved by Google Android.

Two years later, in February 2010, Moblin merged with Nokia’s Maemo, creating a new project called MeeGo. The new focus would be tablets and smartphones:

The power and capability of handhelds has reached astounding levels – netbooks have been a runaway success – and connected TVs, tablets, in-vehicle infotainment, and media phones are fast growing new markets for devices with unheard of performance. Our goal is to develop the best software to go with these devices.

said Intel’s Imad Sousou.

So where are the MeeGo smartphones? Well, maybe we will see one at Mobile World Congress next week. But Nokia is in disarray. According to a leaked memo from new CEO Stephen Elop:

The first iPhone shipped in 2007, and we still don’t have a product that is close to their experience. Android came on the scene just over 2 years ago, and this week they took our leadership position in smartphone volumes. Unbelievable.

We have some brilliant sources of innovation inside Nokia, but we are not bringing it to market fast enough. We thought MeeGo would be a platform for winning high-end smartphones. However, at this rate, by the end of 2011, we might have only one MeeGo product in the market.

Perhaps Nokia will progress MeeGo smartphones with renewed vigour; but what looks more likely is that Nokia will embrace a rival platform, maybe Google Android or Microsoft’s Windows Phone 7.

That might well be alongside MeeGo, rather than replacing it, but Nokia needs to focus its energy and I would guess that MeeGo will lose out.

It may be the beginning of the end for a promising project that has progressed too slowly.

Update: Reuters is reporting that “two industry sources close to the company” say Nokia has ended development of its first MeeGo smartphone

Related posts:

1. Nokia Maemo, Intel Moblin gives way to MeeGo
2. Intel disappointed with Nokia’s Microsoft move, still backing MeeGo
3. MeeGo, Qt, and the new Nokia: developers express their doubts

1. Install the official package with apt-get install php-apc or similar

2. Install with the PHP Extension Community Library which goes something like:

apt-get install apache2
apt-get install libapache2-mod-php5
apt-get install php-pear
apt-get install php5-dev
apt-get install make
apt-get install apache2-prefork-dev
pecl install apc

The advantage over (1) is that you get the latest stable build, version 3.1.6, instead of the Debian package which is 3.0.19

3. Download the source and do something like this to install.

I started with option (2) though I came to regret it. The first problem is that the pecl installer will build with your currently-installed Apache, and if you later upgrade Apache it might break. Sticking with the official package is safer, even though it is very out of date.

I could live with the idea of re-installing APC every time Apache was updated if necessary, but I had another problem. I was up and running with APC 3.1.6 and pleased with the results, until after a while everything stopped working and my blog became a screen full of messages saying “Unable to allocate memory for pool”.

It looks like this bug, which was said to be fixed in version 3.1.5, but if you look to the end of the comments there is one from today with the same issue, and no suggestions about how to fix it.

The ancient version, on the other hand, has performed perfectly so far.

Another point of interest: I found it challenging to discover the best settings for APC. By default the install does no more than to enable the extension; but the default setting is unlikely to be the best one. The documentation tells you what each setting does, but not how to choose the best values for those settings. Should the cache be the default 32MB, or something much greater? Another thing to note: if you compile with MMAP support, which is the default, the value of apc.shm_segments is ignored, and the value in apc.shm_size will solely determine the size of the cache.

I found this Moodle article on installing APC in Windows helpful. What you do is first to find the file apc.php which the install put somewhere like /usr/share/doc/php-apc – in my case it was also compressed -  and put this on your website, preferably in a password-protected folder. This tells you the status of the cache. The aim is to have the cache just big enough that it does not become full and highly fragmented. Here is what I get after a short run with 128MB, which may be a little too much:

Another tip is to set apc.stat to 0. This means APC will not check for changes in PHP files since they were last compiled and cached. The downside is that every time you change a file you have to restart the web server; but the benefit is better performance, which is the goal after all.

Related posts:

1. Test your DNS server for cache poisoning susceptibility
2. Amethyst from SapphireSteel: Develop Flex in Visual Studio, an alternative to Tofino
3. Installing XNA Game Studio Express on Vista