Todo el mundo dice estar sorprendido y el Gobierno de Rajoy dice que no queda más remedio que eliminar 9 canales de televisión.

Y yo digo que es mentira.

En realidad no se tiene porqué borrar ningún canal.

La sentencia del Tribunal Supremo declara nulo el reparto anterior, con lo cual, la lógica dice que hay que hacer un nuevo reparto. El quid de la cuestión es quién se llevaría los canales con ese nuevo reparto:

• Los que hasta hoy son dueños de esos multiplex (Mediaset, Antena 3, NetTV, etc) querrán que el concurso se haga a su medida para que el nuevo reparto sea, oh casualidad, exactamente el mismo que el antiguo
• Los que hasta hoy están alquilando canales a los dueños de los multiplex (Paramount, Disney, etc) querrán que el concurso se haga a su medida para que les den el canal y así ahorrarse el alquiler

Tema aparte es que el Estado ha cobrado a los operadores de Telecomunicaciones (Movistar, Vodafone, Orange, etc) un dinero por el espacio radioeléctrico que va a quedar libre (el “dividendo digital”) :

• Ese dinero, de acuerdo con la normativa anterior (y la nueva) y la Directiva Europea en la mano, tiene que destinarse a ayudas para adaptar las antenas
• Sin embargo, como el Estado no tiene un duro (bueno, lo tiene, pero se va en sobres, Olimpiadas, EREs, trajes, etc), quieren quedarse con el dinero y no darlo para adaptar antenas
• Para poder quedarse con el dinero sin que al ciudadano de a pie le cueste dinero, lo que se les ha ocurrido es anular la adjudicación anterior y no hacer una nueva adjudicación. Al no haber nuevos multiplex, no hay canales en frecuencias nuevas, y por tanto, no tenemos que adaptar las antenas. Más propio de Austin Powers que de un Gobierno decente.

Explicado para niños:

1. Pepito tiene una manzana, Pedrito una pera y Jaimito una naranja
2. Pepito dice “Pedrito, si le das tu pera a Jaimito, yo te doy mi manzana” y “Jaimito, si me das tu naranja, Pedrito te dará una pera”
3. Pedrito le da su pera a Jaimito, Jaimito le da su naranja a Pepito y Pepito NO le da su manzana a Pedrito
4. Pedrito protesta y Pepito, para no aguantar quejas por incumplir su parte del trato, mata a Pedrito y esconde el cuerpo

Lo gracioso del asunto es que tanto Gobierno como propietarios de los multiple se declaran sorprendidos.

Sorprendidos, ¿de qué?

Todos conocían al dedillo la ley y presionaron para que los canales se asignaran por adjudicación directa en lugar de por concurso, sabiendo que violaban la ley. ¿Esperaban que quien no se llevó multiplex se quedara de brazos cruzados?

Recapitulando:

Una vez más: relee lo que escribí ayer

• La sentencia anula el reparto anterior de canales, pero NO prohíbe hacer un nuevo reparto de esos canales. Es más, es justo al contrario: la sentencia dice que los canales hay que darlos, pero por concurso, no por adjudicación directa. Es el Gobierno Rajoy quien quiere hacernos creer que la sentencia obliga a eliminar canales
• Efectivamente, el Gobierno Zapatero ingresó un dinero de las empresas de móviles y NO se lo gastó. Ese dinero era para darlo en la segunda mitad de 2012 y todo 2013 para adaptar antenas. Es el Gobierno Rajoy quien ha decidido quedarse con el dinero y no darlo para adaptar antenas.
• Es más, lo de quedarse el dinero y NO darlo para adaptar antenas lo decidieron MUCHO antes de que se supiera nada de esa sentencia que anulaba el reparto anterior (puedes tirar de hemeroteca y cualquier antenista del foro te lo puede confirmar)
• En definitiva: otro engaño más de Rajoy. Y van…

Si yo fuera Movistar, Vodafone, Orange o Yoigo, estaría muy pendiente de lo que ocurre ahora. Si el Gobierno NO convoca un concurso para dar los multiplex, inmediatamente reclamaría la devolución de mi parte de los 1800 millones de euros que el Estado ingresó en concepto de ayuda a la reantenización. Al fin y al cabo, si no hay nuevos multiplex, no hace falta reantenizar, y por tanto, no las operadoras móviles no tienen porqué pagar.

De hecho, la solución más sensata para este problema después de la sentencia sería:

1. Convocar concurso público con plazo límite 30 de junio
2. A 15 de agosto se publica la resolución (quién obtiene multiplex y quién no). Sí, mucha gente se va a quedar sin vacaciones. Una pena.
3. Hasta el 15 de septiembre para alegaciones
4. El 30 de septiembre, alegaciones resueltas
5. El 15 de diciembre cesan las emisiones por parte de los antiguos dueños de los multiplex. Esto da 75 días a los antiguos y a los nuevos dueños para negociar alquiler de canales, en caso de que entre algún nuevo jugador y salga uno de los antiguos, sin necesidad de que haya corte en las emisiones.
6. ¿Por qué el 15 de diciembre y no el 31, que sería lo más lógico? Porque está Navidad, que es una época de gran audiencia, y además algún canal puede querer retransmitir las campanadas y no vas a hacer que justo cuando suena la última campanada, se apague 

Pero claro, hace falta voluntad, y el Gobierno actual lo que quiere es eliminar los canales y quedarse con 1800 millones de euros por la cara. Unos sinvergüenzas.

(Actualizado con mi propuesta de plan de transición no traumático)

Jonathan Mark says that Canonical Kubuntu is not taking care of the Ubuntu community.

Consider for a minute, Jonathan Mark, the difference between our actions.

Canonical Kubuntu, as one stakeholder in the Ubuntu community, is spending a large amount of energy to evaluate how its actions might impact on all the other stakeholders, and offering to do chunks of work in support of those other stakeholder needs.

You, as one stakeholder in the Ubuntu community, are inviting people to contribute less to the broader project [all the X and Wayland -based desktops], and more to one stakeholder [Unity and Mir].

Hmm. Just because you may not get what you want is no basis for divisive leadership.

Yes, you should figure out what’s important to Kubuntu Ubuntu Unity and Mir, and yes, you should motivate folks to help you achieve those goals. But it’s simply wrong to suggest that Canonical Kubuntu isn’t hugely accommodating to the needs of others, or that it’s not possible to contribute or participate in the parts of Ubuntu which Canonical Kubuntu has a particularly strong interest in. Witness the fantastic work being done on both the system and the apps to bring Ubuntu Plasma to the phone and tablet. That may not be your cup of tea, but it’s tremendously motivating and exciting and energetic.

See Mark? I only needed to do a little search and replace on your words and suddenly, meaning is completely reversed!

Canonical started looking only after its own a couple of years ago and totally dumped the community. Many people have noticed this and written about this in the past two years.

How dare you say Jonathan or anyone from Kubuntu is proposing contributing less to the broader community? The broader community uses X and/or Wayland.

Canonical recently came with Mir, a replacement for X and Wayland, out of thin air. Incompatible with X and Wayland.

No mention of it at all to anyone from X or Wayland.

No mention of it at FOSDEM one month ago, even though I, as the organizer of the Cross Desktop DevRoom, had been stalking your guy for months because we wanted diversity (and we got it: Gnome, KDE, Razor, XFCE, Enlightenment, etc, we even invided OpenBox, FVWM, CDE and others!). I even wrote a mail to you personally warning you Unity was going to lose its opportunity to be on the stand at FOSDEM. You never answered, of course.

Don’t you think Mir, a whole new replacement for X and Wayland, which has been in development for 8 months, deserved a mention at the largest open source event in Europe?

Come on, man.

It is perfectly fine to say “yes, Canonical is not so interested in the community. It’s our way or the highway”.

But do not pretend it’s anything else or someone else is a bad guy.

In fact, is there any bad guy in this story at all!? I think there is not, it’s just people with different visions and chosen paths to achieve them.

Maybe Mir and Unity are great ideas, much better than X and Wayland. But that’s not what we are talking about. We are talking about community, and Canonical has been steadily destroying it for a long time already. If you cannot or do not want to see that, you’ve got a huge problem going on.

We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperativity amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience.

Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, Windows, Mac OS X, general desktop matters, applications that enhance desktops and web (when related to desktop).

Talks can be very specific, such as developing mobile applications with Qt Quick; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2012 schedule might give you some inspiration:
https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html

Please include the following information when submitting a proposal:

• Your name
• The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects)
• Short abstract of one or two paragraphs
• Short bio
• Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified.

The deadline for submissions is December 14th 2012. FOSDEM will be held on the weekend of 2-3 February 2013. Please submit your proposals to crossdesktop-devroom@lists.fosdem.org (subscribtion page for the mailing list: https://lists.fosdem.org/listinfo/crossdesktop-devroom )

– The CrossDesktop DevRoom 2013 Organization Team

PS: Qt and KDE people are starting to organize for the booth, devroom, Saturday & Sunday night, etc. If you want to help, join kde-promo and add yourself to the wiki.

That’s obviously not true and it’s certainly not what I think.

It’s my opinion there is room for HTML5 and there is room for native applications and the decision on what to use should not be taken lightly.

Here are a few questions that may help you to make a wise decision.

Target user

Is it corporate? Is it consumer?

Corporate devices are usually under control and users may not be able to install software.

Or traffic may be filtered and users cannot browse to your website to use your webapp and getting the authorization will take months, therefore they give up before they have even started using it.

Or they may be on a slow Internet connection and using that HTML5 webapp that took years to develop and add all those nice effects is hardly possible due to megabytes of JavaScript and images needing to be downloaded.

As for consumers, despite having full control of their systems, it’s not roses either: not all consumers know how to install software and/or they may be scared by UAC dialogs (hint: always sign your software with a certificate whose signature chain reaches VeriSign).

Target device

Is it a computer? Smartphone? Tablet? Web browser?

If a computer, is it a PC running Windows? Linux? Mac? All of them? Are you trying to reach as many platforms as possible?

How old of a computer are you targeting? Pentium 4? Core 2 Duo? Core i5? How much RAM? Try a fancy website with a lot of HTML5 niftiness on an old computer and you’ll probably be surprised at how slow HTML5 can be, even on modern browsers.

Deployment

Deploying native applications in corporate environments is a bit of a nightmare due to different operating system versions, hardware, etc

Deploying native applications in consumer computers is only a problem if you are targeting low-skilled users.

HTML5 is easy to deploy, provided that you can get the user to use a proper version of the browser. This is workable with consumers but often impossible with corporate, so if you go for HTML5 for a corporate application, make sure you support everything from at least down to Internet Explorer 8.

For mobile devices (smartphones and tablets), it doesn’t really matter whether it’s an HTML5 or native application: it has to be installed on the device, the device goes with the user everywhere and when the user moves to another device, re-installing all the applications is a matter of accessing the Apple Store, Android Market or equivalent and say “download it all”.

Performance

If you need high performance, then native is going to be the best choice in most cases.

There are a lot of HTML5 libraries, frameworks and toolkits but HTML5 is still far from native performance-wise on all the platforms where a native (or almost native*) SDK is available (which is all of them).

* almost native = .NET on Windows Phone 7, for instance.

UI

If you need your application to melt into the platform, then native is the best path: native applications call the platform-specific API, which may have changed from one version of the operating system to another. But it will certainly look as it should. Always.

HTML5 may or may not look good. It may look good today but may not with the next update to the operating system. You may find yourself in need to update to a newer version of the HTML5 framework just to get the application to look native, i. e. no new functionality but a lot of work and cost just to make the application look good in iOS 7.0 or Android 5.0. It’s one of the dangers I described in “HTML5 for everything?” back in January.

Connectivy

Applications running fully on device, no matter whether they are native or HTML5, need no data connection.

Applications which access an external server (website, database and/or alike) need a data connection and this may be a problem, especially if the user is out of his area. Roaming charges are steep.

On the other hand…

DRM

Native applications can use all kind of tips and tricks, especially on computers (Windows, Mac, Linux, etc)

HTML5 applications running “on device” are quite limited in that regard. You are essentially limited to what the Store or Market provide.

Applications which access an external server (website, database and/or alike) are in the best position for copy-protection: the only way users have to not pay is to find a hole in your authentication system, account creation mechanism, etc. Difficult.

Future-proof

Native code is native and that’s good. Dynamically-linked native code always calls the native APIs and those APIs do the right thing when a new version of the operating system is available.

On mobile platforms, HTML5 is almost native these days but supporting several versions of browsers and/or browser engines is becoming a hassle. It will become a very serious problem soon. Wrapping HTML5 around a WebKit to have a “native” application (like PhoneGap does) gives you the advantage of supporting only a few browser engines, although you still have the

On desktop platforms, HTML5 is not native by any means and the pace at which browsers are being updated make is almost impossible to adapt to. Even if you are using libraries (jQuery, ExtJS, Kendo), frameworks (Rails, CodeIgniter, Wicket), etc

There is a third approach some libraries (such as Unity 3D) are taking: use a plugin. Be it a “private plugin” (Unity Web Player) or a “generally available plugin” (Flash). In my opinion, both of them are a recipe for trouble and should only be used as a last-resort mechanism to reach a platform quick.

Resources

Human resources, I mean.

If you want to be native on each platform, do you have enough developers to reach all the platforms you want to reach?

If you don’t, can you afford them?

Are your developers skilled enough? If they have to learn each platform’s technology on the spot, your project may be too late.

HTML5 toolkits allow to you develop a single application for all platforms. They may not look perfect but you shouldn’t dismiss HTML5 if you are tight on resources.

Time to market

Time to market is everything. If your application is too late, you may lose all your potential business to some competitor.

Do you want to release for all the platforms at the same time? As each platform’s application is ready? Maybe first use HTML5 to quickly reach all platforms, then replace that with native applications on mobile platforms?

It might even be the case you can afford (both on money and technical criteria) to reach all the platforms at the same time but you want to do some A/B testing (using one platform as A and the other as B), therefore you want slightly different applications?

Download size

There are two things to consider here: application size and toolkit size.

The application size may vary depending on whether you use native toolkits (be it native code or the platform-blessed HTML5 toolkit) or a cross-platform toolkit, but that’s generally not important.

Applications developed with cross-platform toolkits are usually a bit smaller because those toolkits usually provide a lot of functionality you don’t need to code yourself.

Problem is the cross-platform toolkit size.

If you use Cocoa on iOS, Silverlight on WP7 and Java on Android, then you don’t need to download anything in addition to your application:

But if you use a cross-platform toolkit, if it’s the first time the user downloads an application that requires that toolkit, there is an additiona download involved. And that download may be in the tens of megabytes, which is a lot over 3G, which means users will only purchase your application when on wifi.

Footprint

A second problem caused by cross-platform toolkits is your application will need more space on disk (installation size) and more memory (RAM) than if you develop an application specifically for one device.

If you want to reach the users running the first smartphones, which had only 192 MB of RAM or even less, using a cross-platform toolkit is almost immediately a no-no.

If you are thinking in static linking to reduce the download size and/or footprint, better think about it twice: some app stores may not allow it.

Maintenance

How long will your application live?

Is it a one-off application that will reach its peak, you make money and forget about it? Or do you intend to provide updates and/or keep adding features for a long time?

If the former, maintenance is not a big hurdle: you have essentially decided there will be little or none.

If the latter, then you better consider maintenance.

As I said above, HTML5 applications suffer from the “web moves too fast” syndrome and you may find yourself in need of releasing a new version of the application just because a new version of some browsing engine is available. Sooner or later that will boil down to releases which add no new features but just fix the behavior for a new version of WebKit or Trident. Wrapping your HTML5 application into a native WebKit wrapper provided by you (via a cross-platform toolkit such as Qt) may be an option worth considering: it “freezes” the browser engine your application will use.

Native applications may also suffer from changing APIs but when that happens is usually due to a bug or change in app store policy. There is more stability in the native world.

If you are going to keep adding new features to your application, using a cross-platform toolkit ensures you will only need to add them once (maybe with some platform-specific code some times). Instead of implementing the same feature for iOS, Android, BlackBerry 10, Windows Phone 8 and Symbian, you can implement it once in Qt.

Licensing

Vendor-provided toolkits are generally free: iOS SDK, Android SDK/NDK, a variety of SDKs for BlackBerry, etc.

Most HTML5 and cross-platform native toolkits are available for free (support being available only via forums, mailing lists, IRC, etc) and also offer a paid version which includes support. You are in fact essentially paying for premium support, something some vendor SDKs do not offer.

If support in the form of a guaranteed response in a reasonable time is important for you, you should know using a third-party development toolkit offers you this possibility. Prices are usually around US $1,000/developer/platform/year.

My advice

If you can afford it

• Native mobile app for iOS using iOS SDK
• Native mobile app for Android using Android SDK/NDK
• Native mobile app for Windows Phone 7 using .NET
• Native mobile app for BlackBerry using the Qt SDK (Cascades)
• Native mobile app for Symbian using Qt
• Native desktop app for Windows, Mac and Linux/Unix using Qt
• Web app using Wt and Kendo widgets (check their grid)

You will be able to share code in all the Qt versions (at least the backend, maybe some UI stuff too).

You may also be able to reuse some of the code from the Qt version in the web version via the wtwithqt library.

Depending on how old the Symbian device you are targeting, you may be limited to Qt 4.6. Check the support table over at qt-project.org.

If you are tight on money

• Native mobile app for iOS, Android, BlackBerry and Symbian using Qt (useful links: Qt for iOS, Qt for Android)
• Native desktop app for Windows, Mac and Linux/Unix using Qt
• Web app using Wt and Kendo widgets (check their grid)

The main problem with Qt on iOS and Android is the download size and the footprint. If you are targeting first generation devices, this may not be possible.

No, I have not forgot about Windows Phone in this “category”. But it’s such a niche market that deciding on developing something for WP7 requires careful study on ROI. As for WP8, very little is known about the SDK yet, but Qt support for WP8 (via WRT) is expected soon.

If you are really tight on money

HTML5 version for everybody using PhoneGap or similar (consider making it native by adding a WebKit wrapper)

or

Web app for everybody using Wt and Kendo (this will require network access, so it may not be an option unless your application can require network access for some feature)

If you need a something done quickly

Use Flash or something like Unity 3D for every platform (including the web: Unity Web Player).

You need to be aware anything that requires a plugin is quickly getting deprecated and/or may even not be available to a large segment of users (e. g. Android 4.0 no longer includes Flash, neither Unity nor Unity Web Player are available for Linux, etc). If you intend your application to live long, you may need to replace it later with one of the recommendations I’m giving above.

In case you are not familiar with Vivaldi, here’s a quick recap: the idea is to have a tablet running Linux (Mer, the continuation of Maemo and MeeGo) and Plasma Active. Apparently the easiest and cheapest way to achieve this was to get all the sources code for the software running on one of the many tablets which are sold with Android (which is, after all, a variation of Linux).

But then problems arise: those tablets run Android and vendors often provide only binary drivers, which is useless for Mer (or any other distribution of Linux). Once they finally got enough source to move Vivaldi forward, the board (electronics) changes and back to square 1 (or almost).

According to Aaron, it seems this time they have found a partner which is willing to provide the device and the source. Grea!

However, since the beginning of the Vivaldi Project (back when it was called Spark), there is one thing there is one thing I have always wondered.

Why Mer? In fact, why a Linux distribution? I know, I know, Plasma Active needs Linux to run.

But what about taking a completely different approach?

Instead of trying to get Mer and Plasma Active running on a tablet which is meant to run Android, why not taking a less radical approach?

We have Necessitas (Qt for Android).

So why not taking the opposite approach?

Instead of adapting Mer (operating system) + Plasma Active (“desktop environment”) to a tablet (the “device”) which is meant to run Android

what about this:

Port Plasma Active (desktop environment) to Android (operating system), which is already running on the tablet (the “device”).

Then create KDE’s own “CyanogenMod” that can be installed on top of many tablet devices. And sell those devices: you get to choose 7”, 9.7”, 10.1”, etc

Or maybe even sell Plasma Active and the application in the Android Market, if that’s possible (I don’t know enough about Android and the Market Terms and Conditions to know whether it’s possible technically and legally to replace the desktop).

Yes, that’s a different business and it’s probably not what Make·Play·Live had in mind.

With this approach, the business is no longer about selling hardware + software but mainly only about selling software. How to make that profitable is a topic for another post.

And there are technical limitations: Bionic, the amount of linked libraries, applications may need tablet-specific details (not unexpected, even with Mer), etc

But at least it’s something that we know how to do: it’s code, not hardware, and there is no need to deal with people who will promise source code and then won’t deliver. It will work on top of Android, and we just need to create our own distribution.

It’s just one more platform for KDE: first it was Linux, then other Unices, Mac, Windows… next Android.

Am I too crazy or dumb?

Rsync

Rsync is mainly useful when you want to synchonize a list of files, or directories, between two servers. It will only download the new files and files which have changed. It will even delete or backup the files which have been removed at the original site. Nice.

For a project I was involved until recently at work we had a slightly different problem: we generate a huge file (an ISO image) which contains about 6 GB of data. This ISO image contains the daily build of our application. It contains only a handful of files. Problem is some of them are generated and GB in size, yet from day to day only maybe 100-150 MB have changed (and it would be even less if it were not because of this “feature” of .NET that never generates identical binaries even if using exactly the same source code)

Rsync was not useful in this case: it would download the whole file, gigabytes! (some of the people downloading the ISO are on a slow link in India)

zsync

This is exactly the case zsync targets: zsync will only download the changed parts of the file thanks to the rolling checksum algorithm.

Best of all: no need for an rsync server, opening port TCP 873 (which requires months of arguing with BOFHs in some companies), or anything special: HTTP over port 80 and you are done. Provided that you are not using Internet Information Server, which happens to support only 6 ranges in an HTTP request (hint: configure nginx in reserve proxy mode).

But I’m digressing.

Cool. Great. Awesome. Zsync. The perfect tool for the problem.

Hello Windows

Except for this project is for Windows, people work on Windows, they are horrified of anything non-Windows, and zsync is only available for Unix platforms.

Uh oh.

In addition to that, the Cygwin port suffers from many connection error problems on Windows 7 and does not work on a cmd.exe prompt, it wants the Cygwin bourne shell prompt.

So I started to port zsync to Windows natively.

Native port howto

The starting point was:

• C99 code
• autotools build system
• No external dependencies (totally self-contained)
• Heavy use of POSIX and Unix-only features (such as reading from a socket via file descriptors, renaming a file while open, deleting a file while open and replacing it with another file yet still use the same file descriptor, etc)

To avoid breaking too much, and because I wanted to contribute my changes upstream, my intention was to do the port step by step:

1. Linux/gcc/autotools
2. Linux/gcc/CMake
3. Cygwin/gcc/CMake
4. MSYS/MinGW gcc/CMake
5. Visual C++/CMake

Autotools

Autotools was the first stone in the path.

With some work (calling MSYS from a DOS prompt, etc) it would have been possible to make it generate a Visual C++ Makefile but it would have been painful.

Plus the existing autotools build system did not detect the right configuration on MinGW.

Step 1: replace autotools with CMake. On Linux. This was relatively easy (although time consuming) and did not require any change in the code.

Cygwin

The second step was to build zsync on Windows using Cygwin (which provides a POSIX compatibility layer) and CMake.

No code changes were required here either, only a few small adjustments to the CMake build system. I tested on Linux again, it worked fine.

At this point, I had only made a pyrrhic progress: zsync was still Unix only, but with a cross-platform build system.

MinGW

My next step was a serious one: port zsync to use MinGW, which generates a native Windows application with gcc.

That means using Winsock where required.

5And hitting Microsoft’s understanding of “POSIX-compliant”: the standard Windows POSIX C functions do not allow to treat sockets as files, rename open files, temporary files are created in C:\ (which fails on Windows Vista and newer), etc. And that’s when the functions do exist. In many cases (mkstemp, pread, gmtime_r…) those functions were outright inexistent and I needed to provide an implementation.

Plus adapting the build system. Fortunately, I was still using gcc and Qt Creator provides great support for MinGW and gdb on Windows, and decent support for CMake.

Some other “surprises” were large file support, a stupid “bug” and the difficulties of emulating all the file locking features of Unix on Windows.

Regarding LFS, I took the easy path: instead of using 64-bit Windows API directly, I used the mingw-w64 flavor of gcc on Windows, which implements 64-bit off_t on 32-bit platforms transparently via _FILE_OFFSET_BITS.

Visual C++ misery

Porting to Visual C++ was the last step.

This was not strictly required. After all, all I had been asked for as a native version, not a native version that used Visual C++.

Yet I decided to give VC++2010 a try.

The main problem was lack of C99 support (though you can partially workaround that by compiling as C++) and importing symbols due to lack of symbol exports in the shared library (attributes for symbol visibility were introduced in gcc4.0, but many libraries do not use them because gcc does its “magic”, especially MinGW, which will “guess” the symbols).

Porting to Visual C++ 2010 required either to give up some C99 features in use (e. g. moving variable declarations to the beginning of the functions) or adding a lot of C++-specific workarounds (extern “C”).

I was a bit worried upstream would not accept this code because it didn’t really provide any benefit for the application (for the developer, use of a great IDE and very powerful debugger), therefore I didn’t finish the Visual C++ port. Maybe some day if Microsoft decides to finally provide C99.

The result (so far) is available in the zsync-windows space in Assembla.

Pues es un sueldo bajo, mira por donde.

Los sueldos de los políticos

Hace unos días, el Gobierno de Mariano Rajoy aprobó un proyecto de ley por el que el sueldo máximo de concejales y alcaldes será el mismo que un diputado: no llega a 69.000 EUR al año.

El Presidente del Gobierno cobra algo más, unos 78.000 EUR.

Casos reales

El señor Pizarro ganaba unos 10 millones de euros al año en Endesa. Cuando fue elegido diputado por el Partido Popular pasó a ganar unos 65.000 EUR al año. En los 2 años que fue diputado, Manuel Pizarro perdió, en números redondos, 20 millones de euros. Probablemente más, porque no estamos contando los paquetes de acciones, opciones sobre acciones, jubilaciones, etc.

Luis de Guindos, actual Ministro de Economía, cobraba más de 300.000 EUR al año como consejero de varias empresas. Ahora gana la cuarta parte, es uno de las personas más odiadas de España y no sé cómo duerme por las noches.

Hay más casos: Pedro Morenés (Ministro de Defensa del Gobierno Rajoy, ex-presidente de MDBA), Pedro Argüelles (Secretario de Estado de Defensa, ex-presidente de Boeing España), etc

Pero son raros

Visto que en la empresa privada se gana mucho más que en la política, lo normal es que el cambio vaya en sentido contrario: pasar de la política a la empresa privada.

Casos hay muchos: Felipe González, José María Aznar, Elena Salgado, Pedro Solbes, Eduardo Zaplana, Jordi Sevilla, Josu Jon Imaz, Josep Piqué, en fin, mil.

Gestores inútiles

Visto lo visto, ¿a alguien le extraña que estemos gobernados por inútiles? ¡Es la evolución natural!

• Si uno es bueno en su trabajo, gana mucho más en la empresa privada que en la política
• Si uno es un inútil, en la empresa privada no se va a “comer un torrao”, así que se mete a política.

Corolario

Los inútiles se meten en política, hacen contactos y con su gestión destrozan la economía. Al poco de dejar la política, pasan a la empresa privada, donde ganarán mucho dinero en empresas a las que “casualmente” beneficiaron mientras estaban en política.

La solución

Menos políticos, muchos menos, pero mucho mejor pagados: ¿cómo vamos a encontrar un ministro de Economía capaz si sólo pagamos 69.000 EUR al año?

Los únicos dispuestos a aceptar un cargo así son unos pocos gestores buenos que tienen vocación política (se cuentan con los dedos de una mano), o una caterva de políticos inútiles que quieren usar el cargo como lanzadera para irse luego a la empresa privada y ganar mucho más. Abundan los segundos.

(Todo lo dicho sobre ministros y presidentes del gobierno se aplica idéntico a concejales, alcaldes, diputados autonómicos, presidentes autonómicos, etc)

El Protocolo de Kioto sobre el cambio climático2 es un protocolo de la CMNUCC Convención Marco de las Naciones Unidas sobre el Cambio Climático , y un acuerdo internacional que tiene por objetivo reducir las emisiones de seis gases de efecto invernadero que causan el calentamiento global: dióxido de carbono (CO2), gas metano (CH4) y óxido nitroso (N2O), además de tres gases industriales fluorados: Hidrofluorocarbonos (HFC), Perfluorocarbonos (PFC) y Hexafluoruro de azufre (SF6), en un porcentaje aproximado de al menos un 5%, dentro del periodo que va desde el año 2008 al 2012, en comparación a las emisiones al año 1990.

La realidad

Bueno, esa era la intención. Lo que ha sucedido en realidad ha sido:

1. Muy pocos países han conseguido reducir las emisiones de CO2
2. Se creó un mercado de “aire limpio”, en el cual los países que excedían en sus emisiones de CO2 compraban “no emisiones” a los países que sí cumplían. Un anglosajón diría que literalmente hemos creado un mercado “out of thin air“. Yo lo completaría con un “out of thin clean air”

En cuanto al primer punto, hay que destacar que España es uno de los países más idiotas del Protocolo de Kioto: asumimos unos compromisos irrealizables, a los que en realidad nadie nos obligaba, y en lugar de abandonar el Protocolo, como hicieron el resto de países que no iban a cumplir (Estados Unidos, Canadá, etc), seguimos y hemos pagado y vamos a pagar un dineral.

En cuanto al segundo punto, en realidad los países “contaminadores” no están comprando a países “limpios”, sino (mayoritariamente) a países subdesarrollados, que simplemente no contaminan más porque no tienen industria, no porque su industria sea eficiente.

¿Y España?

España ha fracasado absolutamente en todo: no hemos cumplido con las emisiones, y en lugar de abandonar, seguimos porque somos “buenrrollistas”, y como consecuencia vamos a pagar unos 800 millones de euros por el periodo 2008-2012.

Ya es demasiado tarde para ahorrarnos esos 800 millones de euros (la fecha límite era el 31 de diciembre de 2011), pero lo que sí podemos hacer “darnos de baja” del “club post-Kioto“.

¡Contaminador! ¡Antiecológico! ¡Asesino de la Naturaleza!

Para el carro.

Me gustaría que cumpliéramos con Kioto, con Durban y con Bali, pero ya que no vamos a poder hacerlo, y ya que tenemos la economía hecha trizas, lo mejor es que nos borremos y que lo hagamos lo mejor que podamos.

Y sin pagar estúpidas sanciones autoimpuestas.

Prefiero destinar esos 800 millones de euros a mil cosas más importantes.

The architecture of D-Bus is pretty simple: there is a dbus-daemon server process which runs locally and acts as a “messaging broker” and applications exchange messages through the dbus-daemon.

But of course you already new that because you are supersmart developers and/or users.

D-Bus on Windows

What you may not know is how much damage is D-Bus making to open source software on Windows.

A few years ago I tried to introduce kdelibs for a large cross-platform project but I got it rejected, despite some obvious advantages, mainly due to D-Bus.

Performance and reliability back then was horrible. It works much better these days but it still scares Windows users. In fact, you may also replace “it scares Windows users” with “it scares IT departments in the enterprise world*”.

The reason?

A dozen processes randomly started, IPC with no security at all, makes difficult to upgrade/kill/know when to update applications, and many more. I’m not making this out, this has already happened to me.

* yes, I know our friends from Kolab are doing well, but how many KDE applications on desktop have you seen out of that “isolation bubble”

D-Bus on mobile

One other problem is D-Bus is not available on all platforms (Android, Symbian, iOS, etc), which makes porting KDE applications to those platforms difficult.

Sure, Android uses D-Bus internally, but that’s an implementation detail and we don’t have access to it). That means we still need a solution for platforms where you cannot run or access dbus-daemon.

Do we need a daemon?

A few months ago I was wondering: do we really need this dbus-daemon process at all?

What we have now looks like this:

As you can see, D-Bus is a local IPC mechanism, i. e. it does not allow applications to communicate over the network (although technically, it would not be difficult to implement). And every operating system these days has its own IPC mechanism. Why create a new one with a new daemon? Can’t we use an existing one?

I quickly got my first answer: D-Bus was created to expose a common API (and message and data format, i. e. a common “wire protocol”) to applications, so that it’s easy to exchange information.

As for the second answer, reusing an existing one, it’s obvious we cannot: KDE applications run on a variety of operating systems, every one of them has a different “native” IPC mechanism. Unices (Linux, BSD, etc) may be quite similar, but Windows, Symbian, etc are definitely very different.

No, we don’t!

So I though let’s use some technospeak buzzword and make HR people happy! The façade pattern!

Let’s implement a libdbusfat which offers the libdbus API on one side but talks to a native IPC service on the other side. That way we could get rid of the dbus-daemon process and use the platform IPC facilities. For each platform, a different “native IPC side” would be implemented: on Windows it could be COM, on Android something else, etc

Pros

The advantage of libdbusfat would be applications would not need any change and they would still be able to use DBus, which at the moment is important for cross-desktop interoperability.

On Unix platforms, applications would link to libdbus and talk to dbus-daemon.

On Windows, Android, etc, applications would link to libdbusfat and talk to the native IPC system.

By the magic of this façade pattern, we could compile, for instance, QtDBUS so that it works exactly like it does currently but it does not require dbus-daemon on Windows. Or Symbian. Or Android.

QtMobility?

QtMobility implements a Publish/Subscribe API with a D-Bus backend but it serves a completely different purpose: it’s not available glib/gtk/EFL/etc and it’s implemented in terms of QtDBUS (which in turn uses dbus-daemon for D-Bus services on every platform).

It’s, in fact, a perfect candidate to become a user of libdbusfat.

Cons

A lot of work.

You need to cut dbus-daemon in half, establish a clear API which can be implemented in terms of each platform’s IPC, data conversion, performance, etc. Very interesting work if you’ve got the time to do it, I must say. Perfect for a Google Summer of Code, if you already know D-Bus and IPC on a couple of different-enough two platforms (Linux and Windows, or Linux and Android, or Linux and iOS, etc).

Summary

TL;DR: The idea is to be able to compile applications that require DBus without needing to change the application. This may or may not be true on Android depending on the API, but it is true for Windows.

Are you brave enough to develop libdbusfat it in a Qt or KDE GSoC?

The idea: add support for the Microsoft compiler and linker and Visual Studio projects and solutions (.sln, .vcproj, et)c in KDevelop, at least in the Windows version.

QtCreator has suport for the first part (compiler and linker).

For the the second part (solutions and projects), code can probably be derived (directly or indirectly) from MonoDevelop‘s and CMake‘s. The starting point would be MSBuild support, as it’s what VS2010 is based on.

Bonus points if you add C#/.NET support (Qyoto/Kimono).