Normas Abertas e Regulamento de Interoperabilidade (RNID)

Há cerca de um ano atrás este blog publicou um post intitulado 2 Eventos e um Futuro, em que revia os contextos nacional e europeu no que respeita à adopção das Normas Abertas.

Uma das principais conclusões foi que a situação nacional tinha evoluído bastante deste os velhos tempos da farsa do OOXML, em que Portugal se deixou envergonhar mundialmente. Concluiu-se que, após o debate e aprovação de Lei das Normas Abertas (Lei 36/2011), a discussão tinha subido de nível e quem decidia estava muitíssimo bem informado. Foi também dito que quando alguém bem informado decide mal, a razão é certamente suspeita. E o que faltava decidir? A lista de normas abertas a incluir no Regulamento Nacional de Interoperabilidade Digital (RNID).

Os piores receios não se confirmaram. Aliás, nenhum receio se confirmou. Quem decidiu conseguiu resistir aos potenciais vectores de neutralização política da Lei 36/2011: o esquecimento e a diluição.

Houve demora, é certo, mas a publicação do RNID não ficou esquecida. E a diluição, que poderia ter sido introduzida quer por uma série de mecanismos fáceis de excepção quer pela multiplicidade de normas redundantes não compareceu.

Foi publicada uma lista de normas abertas que não é exaustiva mas é mais do que suficiente para as necessidades actuais. E houve a coragem de escolher para os documentos uma norma que não só é aberta como está implementada em diversos sistemas operativos por variadas aplicações open source e proprietárias, o ODF.

Este processo envolveu os mais diversos intervenientes da política e da sociedade civil. Desde os grupos parlamentares (os do PCP e BE foram os autores dos projectos-Lei), a associações interventivas na área das TI e personalidades ligadas ao meio académico até entidades como a AMA e o actual Governo.

Todos os responsáveis por este desfecho estão de parabéns. Num momento difícil para o país é um resultado muito animador. É um resultado que a médio prazo beneficiará toda a gente, mesmo aqueles que hoje em dia se opõem ou são indiferentes a este tema.

Agora virá a implementação e com ela muitos daqueles que defenderam a via das normas abertas serão chamados a estar à altura do que propuseram. Boa sorte a todos.

Deuglifying KDE on Ubuntu 12.04 Precise

Growing and maintaining a consistent Linux distribution like Ubuntu up to date is a very serious job. Making money from it to support further developments is another one. Canonical chose GNOME at first and pushed Unity afterwards. They made a beautiful and well integrated desktop that is a pleasure to use. We are certainly thankful.

What if you like KDE? Oh well, we can't all be happy. Or can we?

The integration of KDE on Ubuntu (in fact even Kubuntu) is not exactly the most polished thing in the world (let's not mention the default wallpaper... :-) . But that can be fixed and once done doesn't seem that difficult.

The fix is made of two steps, on top of the default Ubuntu 12.04 installation:

1) Choose your KDE based applications. Remove redundant GNOME based applications

apt-get install kde-plasma-desktop khelpcenter4 kdeartwork kdeartwork-style plasma-desktopthemes-artwork kde-artwork-active kde-wallpapers kdewallpapers plasma-widgets-addons kde-l10n-pt ksnapshot gtk2-engines-oxygen gtk3-engines-oxygen libreoffice-kde kontact okular smplayer gwenview ark

apt-get remove totem empathy evince brasero evolution rhythmbox shotwell konqueror file-roller nautilus eog

This will bring you a desktop with a set of applications that work well together and nicely fit a KDE desktop.

2) Prepare the contents of .kde and install them on /etc/skel

Note: it you don't know what /etc/skel is please read a correct explanation here.

This is a surgical step that will ensure you only have to customize users once. Proceed as follows: 2.1 )backup your default .kde

cp -R .kde dot_kde

2.2) Change whatever has to be changed in the GUI (menus, panels, desktop, etc) 2.3) Detect configuration file changes

diff -qr .kde dot_kde

2.4) Sanitize the content of your configuration files

This not an algorithmic step but something to learn from inspection, trial and error. In the cleanup process is important to remove any references to the specific user you are logged in with (ex: references to Recent Files), and unnecessary geometry related references (ex: absolute dimensions of a panel) that should be calculated on the first login.

2.5) Install the modified files from .kde/share/config and .kde/share/apps under /etc/skel/.kde ...

2.6) Create a new user and login. If it's not as you want it go back to step 2.2)


3) Other configuration files

Follow the same logic for all other application configuration files. For example, if you use SMPlayer as a media player you may want  to preconfigure it on

/etc/skel/.config/smplayer/smplayer.ini. 

You may also want to configure GTK so that GTK base applications look good under KDE

/etc/skel/.gtkrc-2.0
/etc/skel/.config/gtk-3.0/settings.ini

Here is an example of settings.ini

[Settings]
gtk-theme-name=oxygen-gtk
gtk-icon-theme-name=oxygen-old
gtk-font-name=Sans 10
gtk-cursor-theme-name=DMZ-White
gtk-cursor-theme-size=0
gtk-toolbar-style=GTK_TOOLBAR_BOTH_HORIZ
gtk-toolbar-icon-size=GTK_ICON_SIZE_LARGE_TOOLBAR
gtk-button-images=1
gtk-menu-images=1
gtk-enable-event-sounds=1
gtk-enable-input-feedback-sounds=1
gtk-xft-antialias=1
gtk-xft-hinting=1
gtk-xft-hintstyle=hintfull

Once done, this will make GTK based applications use a theme that somewhat matches the looks of KDE applications, unlike the default theme that doesn't look good at all under KDE.


4) Enjoy effortless KDE installations

If things went right you can now add/remove the packages and install the skel configuration files on a post-install script. The result could look like this.

Ser Português

Procuram-se estes cromos. Se os viu reporte-os por favor ao blog mais próximo.

Ass
A Gerência.

Cristiano Ronerd

FreeQuim

Interhat Explorer

Só para quem não percebeu e não olhou para a data: este post é uma homenagem a um dos nossos melhores fornecedores de gargalhadas, o Ser Português.

.

Centralizing cross-platform applications on a Linux Terminal Server

Roughly 3 years ago we described how windows-only applications could be (almost) seamlessly delivered to a network of Linux workstations. Although Windows terminal services CALs are not seamless to whoever has to pay for them, the technical solution works very well and can be relied on for mission critical scenarios. Now we will look into what Linux can do, to centralize cross-platform applications. Previously, we stated:

In a ideal world every piece of client software is either:

• web based, with standards based cross browser development

• portable, developed with a cross platform language / toolkit (Java, Qt, Gtk+, ...)

But even when an application is cross platform, i.e. able to run on multiple desktop operating systems, it is often preferable to have it centralized if certain conditions are met:

• it is a critical business application, supported by a separate team
• it is updated very often
• it generates a lot of network traffic from the local desktops to a remote server
• ...

If the application is indeed cross platform (or if it is Linux specific), the correct choice is to centralize it on a Linux server. This "server" is in fact a remote "desktop" which allows for multiple graphical sessions. With Linux, no CALs need to be purchased and there are no limits for the number of clients connecting to the application, besides network and server performance.

The architecture is very similar to the one proposed in the previous article. In fact, we invite you to review it before moving forward on this one.

The xrdp login screen

The key pieces for doing getting the work done are:

1) a Linux distribution to run the application that needs to be centralized
2) xrdp – the open source RDP server
3 Vmware / Xen / ... - so that the Linux distribution can be installed as a virtual machine
4) rdesktop or the newer freerdp - an open source RDP client

As before, preventive measures have to be put in place on the remote machine

• no administration privileges for any regular user
  
• minimal software installation
• automatic startup of the desired application(s)

Each user must have its own startup script on ~/.xinitrc and ~/.xsession linked to it. As with Windows, the authentication can be local with generic users (usually the management applications have their own authentication...) or made against LDAP, Samba, Active Directory, etc.

Below is an example .xinitrc that launches a very simple window manager (opennbox) and a minimalistic task bar called tint2.

#!/usr/bin/env bash
setxkbmap -layout pt
xsetroot -solid rgb:3b/59/98
openbox &
tint2 &
/usr/local/bin/mount_share.sh
exec /path/to/my/application

The purpose of this script, besides doing some initial setup, is launching the centralized application on an nearly invisible desktop environment. If the users are not local this script has to be created automatically for them during the first login (eg, via /etc/skel and pam_mkhomedir).

A java application running on a Linux remote server

If you need packages for xrdp that work out of the box you can get them from the following locations:

xrdp 0.6 for Ubuntu (tested on 10.04 an 12.04)

xrdp 0.6 for Mandriva / Caixa Mágica 14

Opening a session is a simple as running

rdesktop -g 1024x768 -a 16 -k pt 192.168.0.12

from a desktop shortcut. You can also automate the login process by passing the username and password directly on the command line

rdesktop -g 1024x768 -a 16 -k pt -u User1 -p MyPassword 192.168.0.12

This means that a double click on the desktop shortcut will trigger the opening of a remote session and the startup of the centralized application. Whenever the application is closed the remote session will be terminated.

If at some point the user closes the client window, the session will remain running allowing for a later reconnection. Currently, xrdp supports automatic resize and colour depth adaptation, so it is possible to reconnect from a different device and continue the work interrupted before. It is also possible to connect from Windows clients since xrdp has been tested with at least Windows XP and Windows 7.

One thing xrdp doesn't support yet is forwarding the print jobs as the Windows terminal server component does. However, if you are on a LAN or VPN, you can have your central Linux terminal server recognize the printers from all your CUPS servers and print directly to their print queues. You can also have your users print to a PDF file on a shared folder which can accessed from the local workstation.

Xrdp is an amazing piece of Open Source software. It can used for more ambitious tasks, such as centralizing entire desktop sessions to be accessed by thin clients. That is a more complex topic which may be the subject of a future article.

VMware 2 long process names vs top: meet vmware-top

Have you noticed how VMware 2 process names are very-very-long-freight-train-long-we-could-say?

That is why when you run "top" on a VMWare 2 server you can't realize which VM is taking over great amounts of CPU or memory. On the other hand "ps" shows the complete process names but is unable to display instantaneous CPU usage.

What to do then? Interestingly, this seems to be an orphan question.

The solution is a custom script that uses both top and atop to display the list of VMware 2 processes sorted by CPU consumption. The result can be downloaded from here and looks like this.


Notes:

• you must have "top" and "atop" installed for this to work.

• the shell script is not pretty

Identidade

Numa segunda incursão na edição de video sobre Linux (a primeira foi esta) a Angulo Solido aproveita para falar daquilo para que no stress dos dias não há tempo.

Boas festas a todos os leitores deste blog!

Identidade from Caroline Pimenta on Vimeo.

Dois eventos e um futuro

Regressei de Bruxelas após o Open Forum Summit, bem a tempo de participar no Encontro Nacional sobre Tecnologia Aberta, Linux 2011. Apenas uma semana e 2000km separaram as declarações de uma vice presidente da Comissão Europeia, em Bruxelas, e do representante da Agência para a Modernização Administrativa (AMA) em Lisboa. E no entanto, as semelhanças entre a declarada estratégia europeia e a recem assumida estratégia nacional são suficientes para podermos crer que o futuro das políticas de TI está finalmente a ser pensado cuidadosamente.

O futuro, segundo ambas as instituições, passa pelas Normas Abertas, pela interoperabilidade multiplataforma e, em pelo menos alguma medida pelo software Open Source. Mas a corrida para o futuro não é a dos 100m, não é a dos 200m, nem sequer a dos 400m barreiras. Tem barreiras, de facto, e será uma prova de resistência. Essa resistência é a que qualquer instituição enfrenta ao implementar medidas que vão perturbar os primeiros 100m e permitir acelerar em força nos kms seguintes.

O que está em jogo no imediato é a obrigatoriedade do software adquirido pelo Estado estar conforme um conjunto de Normas Abertas. O que está em jogo, não finjamos o contrário, é diminuir a capacidade de lock in de todos os fornecedores, obrigando diferentes produtos a competir e os preços a ajustarem-se. Estão em risco negócios confortáveis para uma parte e ruinosos para o contribuinte. A Open Forum Europe (OFE) concluiu num estudo que 13% do concursos públicos de âmbito europeu faziam (ilegalmente) menção a marcas. A ESOP efectuou diligências em tribunal no sentido de anular o concurso de 10M EUR lançado pela DGITA com essa e outras irregularidades. Na base destes problemas está precisamente o lock in que resulta numa grande incapacidade de consultar efectivamente o mercado.

Num discurso bastante apreciado pela audiência, a vice presidente Neelie Kroes teve a frontalidade de admitir todas as lutas diplomáticas que circundaram um único parágrafo da EIF (European Interoperability Framework). Idênticas lutas de bastidores rondaram uma das alíneas da Lei 36/2011, também conhecida por Lei das Normas Abertas. Ambas as lutas, ainda que não se fale disto abertamente, se relacionam com a possibilidade de um implementador maior – e com poderoso armamento legal – aniquilar um mais pequeno, mesmo que mais talentoso, recorrendo a alegadas patentes de software (as patentes de software são as armas de destruição maciça da inovação independente). Mas, mais nuance, menos nuance, tudo isto parece ter acabado bem em ambos os textos.

A AMA, lançou para consulta pública um conjunto de Normas Abertas que pretende que sejam obrigatórias tendo sugerido como Norma Aberta para documentos editáveis o ODF (para documentos finalizados é o PDF). A decisão está certa, porque a multiplicidade de standards tornaria a Lei 36/2011 inconsequente e a interoperabilidade insuficiente. O outro candidato – o OOXML - está a milhas do ODF em termos de interoperabilidade real. Mas conhecendo Portugal, será fácil de imaginar que as pressões de terceiros se tornarão gigantescas em poucos dias.

Foi num Portugal pré-ESOP, que uma comissão “técnica” ad-hoc formada por empresas parceiras da Microsoft e presidida pela própria Microsoft, no seio de um instituto público, se preparava para submeter o voto Português sobre o OOXML à ISO sem qualquer tipo discussão. Foi nessa mesma comissão que, posteriormente, empresas de posições contrárias – a que eu integro incluída – esgrimiram inutilmente argumentos ficando o voto final decidido meramente em função do “número de espingardas”. As actas dessas reuniões, os emails trocados, os pareceres jurídicos, a lista de “apoiantes” angariados para o OOXML – incluindo nomes, nrs de telefone e cargos em instituições públicas de renome – nunca vieram a público mas são elucidativas do tipo de pressão ilegítima e sem sustentação técnica que foi possível criar. O que sempre esteve em causa foi uma norma feita à pressa que veio criar multiplicidade nos formatos documentais e por quem a principal parte interessada acabou por perder o interesse face às alterações a que a ISO obrigou. Chegou a ser estudada a correlação entre o PIB per capita dos países envolvidos nesse processo e o seu sentido de voto. E Portugal, bem como o Instituto de Informática do Ministério das Finanças, não saiu daqui bem visto.

Segue destas circunstâncias que se as louváveis intenções da AMA – evidentes das declarações públicas do seu representante – são para pôr em prática, serão precisos punhos de ferro e nervos de aço. A pressão dos interesses instalados irá certamente ser forte e Portugal, na situação em que está, não pode voltar a ficar mal visto. A única forma de lidar com o problema é a transparência: o site da consulta é público, como deverão ser todos os registos de contactos efectuados sobre esta matéria.

Uma coisa é certa: nunca até hoje se tinha visto um entendimento técnico tão profundo da parte dos decisores políticos nacionais e europeus. Isto ficou claro no Open Forum Summit e também no Encontro Nacional de Tecnologia Aberta. As declarações da AMA e da CTSSAP, ambas presentes no evento nacional, não deixam margem para dúvidas: independentemente da opinião concreta de cada uma das partes a discussão subiu de nível e agora quem decide sabe do que fala.

É neste contexto que todos devemos ficar atentos. Com decisores tão informados qualquer má decisão será suspeita.

Nota:

A ESOP participou activa e publicamente no processo discussão das Normas Abertas em Portugal tendo feito chegar a sua opinião à CTSSAP e à AMA. A posição da ESOP sobre esta matéria é conhecida e anunciada abertamente sem qualquer ambiguidade. A ESOP afirmou publicamente estar convencida de que a sua posição coincide com a do interesse geral.