perl

Perl is a family of high-level, general-purpose, interpreted, dynamic programming languages. The languages in this family include Perl 5 and Perl 6.[4]

Though Perl is not officially an acronym,[5] there are various backronyms in use, such as: Practical Extraction and Reporting Language.[6] Perl was originally developed by Larry Wall in 1987 as a general-purpose Unix scripting language to make report processing easier.[7] Since then, it has undergone many changes and revisions. The latest major stable revision of Perl 5 is 5.18, released in May 2013. Perl 6, which began as a redesign of Perl 5 in 2000, eventually evolved into a separate language. Both languages continue to be developed independently by different development teams and liberally borrow ideas from one another.

The Perl languages borrow features from other programming languages including C, shell scripting (sh), AWK, and sed.[8] They provide powerful text processing facilities without the arbitrary data-length limits of many contemporary Unix tools,[9] facilitating easy manipulation of text files. Perl 5 gained widespread popularity in the late 1990s as a CGI scripting language, in part due to its parsing abilities.[10]

In addition to CGI, Perl 5 is used for graphics programming, system administration, network programming, finance, bioinformatics, and other applications. It’s nicknamed “the Swiss Army chainsaw of scripting languages” because of its flexibility and power,[11] and possibly also because of its perceived “ugliness”.[12] In 1998, it was also referred to as the “duct tape that holds the Internet together”, in reference to its ubiquity and perceived inelegance.[13]

Perl was originally named “Pearl”. Wall wanted to give the language a short name with positive connotations; he claims that he considered (and rejected) every three- and four-letter word in the dictionary. He also considered naming it after his wife Gloria. Wall discovered the existing PEARL programming language before Perl’s official release and changed the spelling of the name.[36]

When referring to the language, the name is normally capitalized (Perl) as a proper noun. When referring to the interpreter program itself, the name is often uncapitalized (perl) because most Unix-like file systems are case-sensitive. Before the release of the first edition of Programming Perl, it was common to refer to the language as perl; Randal L. Schwartz, however, capitalized the language’s name in the book to make it stand out better when typeset. This case distinction was subsequently documented as canonical.[37]

There is some contention about the all-caps spelling “PERL”, which the documentation declares incorrect[37] and which some core community members consider a sign of outsiders.[38] The name is occasionally expanded as Practical Extraction and Report Language, but this is a backronym.[39] Other expansions have been suggested as equally canonical, including Wall’s own humorous Pathologically Eclectic Rubbish Lister.[40] Indeed, Wall claims that the name was intended to inspire many different expansions.[41]

The Comprehensive Perl Archive Network (CPAN) currently has 121,260 Perl modules in 27,769 distributions, written by 10,733 authors, mirrored on 270 servers.

The archive has been online since October 1995 and is constantly growing.

CPAN, the Comprehensive Perl Archive Network, is an archive of over 114,000 modules of software written in the Perl programming language, as well as documentation for them.[1] It has a presence on the World Wide Web at www.cpan.org and is mirrored worldwide at more than 200 locations.[2] CPAN can denote either the archive network itself, or the Perl program that acts as an interface to the network and as an automated software installer (somewhat like a package manager). Most software on CPAN is free and open source software.[3] CPAN was conceived in 1993, and the first web-accessible mirror was launched in January 1997.[4]

Like many programming languages, Perl has mechanisms to use external libraries of code, making one file contain common routines used by several programs. Perl calls these modules. Perl modules are typically installed in one of several directories whose paths are placed in the Perl interpreter when it is first compiled; on Unix-like operating systems, common paths include /usr/lib/perl5, /usr/local/lib/perl5, and several of their subdirectories.

Perl comes with a small set of core modules. Some of these perform bootstrapping tasks, such as ExtUtils::MakeMaker, which is used for building and installing other extension modules; others, like CGI.pm, are merely commonly used. The authors of Perl do not expect this limited group to meet every need, however.

The CPAN’s main purpose is to help programmers locate modules and programs not included in the Perl standard distribution. Its structure is decentralized. Authors maintain and improve their own modules. Forking, and creating competing modules for the same task or purpose is common. There is no formal bug tracking system, but there is a third-party bug tracking system that CPAN designated as the suggested official method of reporting issues with modules. Continuous development on modules is rare; many are abandoned by their authors, or go years between new versions being released. Sometimes a maintainer will be appointed to an abandoned module. They can release new versions of the module, and accept patches from the community to the module as their time permits. CPAN has no revision control system, although the source for the modules is often stored on GitHub. Also, the complete history of the CPAN and all its modules is available as the GitPAN project, allowing to easily see the complete history for all the modules and for easy maintenance of forks. CPAN is also used to distribute new versions of Perl, as well as related projects, such as Parrot.

The CPAN is an important resource for the professional Perl programmer. With over 23,000 modules (containing 20,000,000 lines of code) as of July 2011, the CPAN can save programmers weeks of time, and large Perl programs often make use of dozens of modules. Some of them, such as the DBI family of modules used for interfacing with SQL databases, are nearly irreplaceable in their area of function; others, such as the List::Util module, are simply handy resources containing a few common functions.

Files on the CPAN are referred to as distributions. A distribution may consist of one or more modules, documentation files, or programs packaged in a common archiving format, such as a gzipped tar archive or a ZIP file. Distributions will often contain installation scripts (usually called Makefile.PL or Build.PL) and test scripts which can be run to verify the contents of the distribution are functioning properly. New distributions are uploaded to the Perl Authors Upload Server, or PAUSE (see the section Uploading distributions with PAUSE).

In 2003, distributions started to include metadata files, called META.yml, indicating the distribution’s name, version, dependencies, and other useful information; however, not all distributions contain metadata. When metadata is not present in a distribution, the PAUSE’s software will usually try to analyze the code in the distribution to look for the same information; this is not necessarily very reliable.

With thousands of distributions, CPAN needs to be structured to be useful. Distributions on the CPAN are divided into 24 broad chapters based on their purpose, such as Internationalization and Locale; Archiving, Compression, And Conversion; and Mail and Usenet News. Distributions can also be browsed by author. Finally, the natural hierarchy of Perl module names (such as “Apache::DBI” or “Lingua::EN::Inflect”) can sometimes be used to browse modules in the CPAN.

CPAN module distributions usually have names in the form of CGI-Application-3.1 (where the :: used in the module’s name has been replaced with a dash, and the version number has been appended to the name), but this is only a convention; many prominent distributions break the convention, especially those that contain multiple modules. Security restrictions prevent a distribution from ever being replaced, so virtually all distribution names do include a version number.

There is also a Perl core module named CPAN; it is usually differentiated from the repository itself by using the name CPAN.pm. CPAN.pm is mainly an interactive shell which can be used to search for, download, and install distributions. An interactive shell called cpan is also provided in the Perl core, and is the usual way of running CPAN.pm. After a short configuration process and mirror selection, it uses tools available on the user’s computer to automatically download, unpack, compile, test, and install modules. It is also capable of updating itself.

More recently, an effort to replace CPAN.pm with something cleaner and more modern has resulted in the CPANPLUS (or CPAN++) set of modules. CPANPLUS separates the back-end work of downloading, compiling, and installing modules from the interactive shell used to issue commands. It also supports several advanced features, such as cryptographic signature checking and test result reporting. Finally, CPANPLUS can uninstall a distribution. CPANPLUS was added to the Perl core in version 5.10.0.

Both modules can check a distribution’s dependencies and can be set to recursively install any prerequisites, either automatically or with individual user approval. Both support FTP and HTTP and can work through firewalls and proxies.

Install all dependent packages for CPAN

sudo apt-get install build-essential

Invoke the cpan command as a normal user

cpan

Once you hit on enter for “cpan” to execute, you be asked of some few questions. To make it simple for yourself, answer “no” for the first question so that the latter ones will be done for you automatically.

Enter the commands below

make install
install Bundle::CPAN

Now all is set and you can install any perl module you want.

Type o conf init to reconfigure cpan.

The Best Perl Programmers Use Modern Perl

by chromatic

In 1987, Perl 1.0 changed the world. In the decades since then, the language has grown from a simple tool for system administration somewhere between shell scripting and C programming to a powerful, general purpose language steeped in a rich heritage.

Even so, most Perl 5 programs in the world take far too little advantage of the language. You can write Perl 5 programs as if they were Perl 4 programs (or Perl 3 or 2 or 1), but programs written to take advantage of everything amazing the worldwide Perl 5 community has invented, polished, and discovered are shorter, faster, more powerful, and easier to maintain than their alternatives.

They solve difficult problems with speed and elegance. They take advantage of the CPAN and its unparalleled library of reusable code. They get things done.

This productivity can be yours, whether you’ve dabbled with Perl for a decade or someone just handed you this book and said “Fix this code by Friday.”

Modern Perl is suitable for programmers of every level. It’s more than a Perl tutorial—only Modern Perl focuses on Perl 5.12 and 5.14, to demonstrate the latest and most effective time-saving features. Only Modern Perl explains how and why the language works, to let you unlock the full power of Perl.

Hone your skills. Sharpen your knowledge of the tools and techniques that make Perl so effective. Master everything Perl has to offer.

When you have to solve a problem now, reach for Perl. When you have to solve a problem right, reach for Modern Perl.

Visit the companion website at Modern Perl Books or read Modern Perl: the Book online.

Modern Perl installations include two clients to connect to, search, download, build, test, and install CPAN distributions, CPAN.pm and CPANPLUS. For the most part, each of these clients is equivalent for basic installation. This book recommends the use of CPAN.pm solely due to its ubiquity. With a recent version (as of this writing, 1.9800 is the latest stable release), module installation is reasonably easy. Start the client with:

    $ cpan

To install a distribution within the client:

    $ cpan
    cpan[1]> install Modern::Perl

… or to install directly from the command line:

    $ cpan Modern::Perl

Eric Wilhelm’s tutorial on configuring CPAN.pm http://learnperl.scratchcomputing.com/tutorials/configuration/ includes a great troubleshooting section.

Eclipse, herramienta universal – IDE abierto y extensible

Eclipse: una herramienta profesional al alcance de todos Pese a que Eclipse está escrito en su mayor parte en Java (salvo el núcleo) y que su uso más popular sea como un IDE para Java, Eclipse es neutral y adaptable a cualquier tipo de lenguaje, por ejemplo C/C++, Cobol, C#, XML, etc. La característica clave de Eclipse es la extensibilidad. Eclipse es una gran estructura formada por un núcleo y muchos plug-ins que van conformando la funcionalidad final. La forma en que los plug-ins interactúan es mediante interfaces o puntos de extensión; así, las nuevas aportaciones se integran sin dificultad ni conflictos.

Eclipse fue producto de una inversión de cuarenta millones de dólares de IBM en su desarrollo antes de ofrecerlo como un producto de código abierto al consorcio Eclipse.org que estaba compuesto inicialmente por Borland e IBM. IBM sigue dirigiendo el desarrollo de Eclipse a través de su subsidiaria OTI (Object Technologies International), creadora de Eclipse. OTI fue adquirida por IBM en 1996 y se consolidó como gran empresa de desarrollo de herramientas orientadas a objeto (O.O.) desde la popularidad del lenguaje Smalltalk. OTI era la división de IBM en la que se generaron los productos Visual Age, que marcaron el estándar de las herramientas de desarrollo Orientado a objetos. Muchos conceptos pioneros en Smalltalk fueron aplicados en Java, creando Visual Age for Java (VA4J). VA4J fue escrito en Smalltalk. Eclipse es una reescritura de VA4J en Java. La base para Eclipse es la Plataforma de cliente enriquecido (del Inglés Rich Client Platform RCP). Los siguientes componentes constituyen la plataforma de cliente enriquecido:

Plataforma principal – inicio de Eclipse, ejecución de plugins OSGi – una plataforma para integrar distribuciones. El Standard Widget Toolkit (SWT) – Un widget toolkit portable. JFace – manejo de archivos, manejo de texto, editores de texto El Workbench de Eclipse – vistas, editores, perspectivas, asistentes

Los widgets de Eclipse están implementados por un herramienta de widget para Java llamada SWT, a diferencia de la mayoría de las aplicaciones Java, que usan las opciones estándar Abstract Window Toolkit (AWT) o Swing. La interfaz de usuario de Eclipse también tiene una capa GUI intermedia llamada JFace, la cual simplifica la construcción de aplicaciones basada en SWT. El entorno integrado de desarrollo (IDE) de Eclipse emplea módulos (plug-in) para proporcionar toda su funcionalidad al frente de la plataforma de cliente rico, a diferencia de otros entornos monolí­ticos donde las funcionalidades están todas incluidas, las necesite el usuario o no. Este mecanismo de módulos es una plataforma ligera para componentes de software. Se provee soporte para Java y CVS en el SDK de Eclipse. En cuanto a las aplicaciones clientes, eclipse provee al programador con frameworks muy ricos para el desarrollo de aplicaciones gráficas, definición y manipulación de modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework – Framework para la edición gráfica) es un plugin de eclipse para el desarrollo de editores visuales que pueden ir desde procesadores de texto wysiwyg hasta editores de diagramas UML, interfaces gráficas para el usuario (GUI), etc. El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un IDE con un compilador de Java interno y un modelo completo de los archivos fuente de Java. Esto permite técnicas avanzadas de refactorización y análisis de código. El IDE también hace uso de un espacio de trabajo, en este caso un grupo de metadata en un espacio para archivos plano, permitiendo modificaciones externas a los archivos en tanto se refresque el espacio de trabajo correspondiente. Núcleo: su tarea es determinar cuales son los plug-ins disponibles en el directorio de plug-ins de Eclipse. Cada plug-in tiene un fichero XML manifest que lista los elementos que necesita de otros plug-ins así­ como los puntos de extensión que ofrece. Como la cantidad de plug-ins puede ser muy grande, solo se cargan los necesarios en el momento de ser utilizados con el objeto de minimizar el tiempo de arranque de Eclipse y recursos. Entorno de trabajo: maneja los recursos del usuario, organizados en uno o más proyectos. Cada proyecto corresponde a un directorio en el directorio de trabajo de Eclipse, y contienen archivos y carpetas. Interfaz de usuario: muestra los menús y herramientas, y se organiza en perspectivas que configuran los editores de código y las vistas. A diferencia de muchas aplicaciones escritas en Java, Eclipse tiene el aspecto y se comporta como una aplicación nativa. Esta programada SWT (Standard Widget Toolkit) y Jface (juego de herramientas construida sobre SWT), que emula los gráficos nativos de cada sistema operativo. Este ha sido un aspecto discutido sobre Eclipse, porque SWT debe ser portada a cada sistema operativo para interactuar con el sistema gráfico. En los proyectos de Java puede usarse AWT y Swing salvo cuando se desarrolle un plug-in para Eclipse. Para descargar Eclipse existen distribuciones con diferentes combinaciones de plug-ins dependiendo del uso que se le quiera dar a la herramienta. Un problema que se presenta con estas distribuciones es que en Windows XP el descompresor integrado a veces falla y es preferible usar un programa externo como 7-zip, WinZIP, o info-zip

La reutilización de código

Ahora, como antes, más que antes, como siempre, la reutilización de código se presenta como un valor fundamental en el desarrollo de sistemas. Uno de sus aspectos es la interoperabilidad de los códigos. Por decirlo de alguna manera, la compatibilidad de una aplicación con diferentes versiones de un sistema operativo y con diferentes sistemas operativos.

Por un lado Microsoft, por otro los demás. El imperio contra los rebeldes republicanos y los feudos vecinos. Pero dentro del mismo imperio se hablan distintas lenguas y los rebeldes tienen diferentes agendas.

Una aplicación que trabaja en Windows 95 no necesariamente funciona en Windows XP, Visual Basic 6 y Visual Basic .Net son animales distintos. Una aplicación Linux que funciona en la distribución Red Hat no necesariamente funciona en la distribución SuSe. La frase platform independent source en la practica marca una prueba de iniciación para hechiceros.

En el caso de Microsoft, algunas de estas incompatibilidades son de origen mercadológico. ¿Cuál es la diferencia entre Windows XP Home Edition y Windows XP Pro? Limitaciones artificiales en la versión casera con respecto a la versión profesional. Desde el punto de vista de Microsoft este modelo funciona, Vista no tiene 2 versiones distintas sino n, cada una definida por un segmento de mercado. Las utilidades de MS aumentaron 65% con respecto al año pasado y podemos esperar más de lo mismo por lo menos en el corto plazo.

En el caso del movimiento Open Source las incompatibilidades son de origen sociocultural. Distintos grupos trabajan con combinaciones distintas de herramientas y enfoques metodológicos. Estos herramentales se yuxtaponen unos con otros y las combinaciones son infinitas. La versión de gcc pude ser la diferencia clave para que un paquete se construya correctamente.

Una iniciativa que no termino de entender es Mono. El concepto es bueno, pero ya va un par de veces que trato de construir una aplicación .Net para fallar miserablemente. Al revisar la letra chiquita del readme aparece que la aplicación es Mono ¿Cuál es el caso de incluir archivos de solución y proyecto de Visual Studio si VS no puede construir la aplicación? ¿Si se requiere reproducir el ambiente de trabajo del desarrollador con librerí­as y variables de entorno porque no documentar esas dependencias? Entiendo que son pecadillos del bien intencionado pero se me escapa la motivación fundamental del chango.

http://www.go-mono.com/docs/
http://www.codeproject.com/cpnet/hellomono.asp

Un aspecto problemático del desarrollo í­nter plataforma son las interfaces graficas de usuario (GUI). Cada sistema operativo tiene su look-and-feel caracterí­stico y el manejo eficiente de ventanas requiere el uso del API nativo correspondiente.

Un enfoque que se puede tomar es agregar una capa intermedia entre la aplicación y el sistema operativo que abstraiga la interacción entre la capa lógica y la interfase grafica a cambio de una penalización en el rendimiento. Algunos problemas que se pueden presentar con librerí­as de este tipo:

  • El uso de una capa intermedia adicional disminuye el rendimiento de la aplicación.
  • La librerí­a necesaria para soportar la funcionalidad adicional de múltiples sistemas operativos aumenta le tamaño de las aplicaciones más alla de lo que se justifica con la funcionalidad de la aplicación misma. Por lo mismo el soporte para plataforma móvil no es adecuado
  • La apariencia de la aplicación no corresponde a la de una aplicación nativa y los diálogos son distintos a los que los usuarios usan normalmente.
  • La necesidad de definir un mí­nimo común denominador hace que se pierda la oportunidad de usar las características más avanzadas de un sistema operativo en particular.
  • El uso de librerí­as fuera de la esfera de influencia del sistema operativo anfitrión saca a la aplicación del ciclo de vida del mismo y dificulta el proceso de mantener alineadas las actualizaciones de la aplicación con cambios en el sistema operativo.

La tabla siguiente muestra un comparativo de librerí­as para desarrollo ínter plataforma.

Liberarí­a Tamaño (MB) Tamaño comprimido (MB)
Java 30+ 15
GTK+ 9+ 4
QT 4+ 2
wxWidgets <1 <.5

Java es una norma abierta que funciona bien como propuesta í­nter plataforma. La maquina virtual de java (JVM) aísla la aplicación del sistema operativo anfitrión y esta disponible normalmente en todas partes. Sin embargo las aplicaciones de java tienden a ser chupa recursos. Si revisas los procesos en una estación XP con Firefox instalado, Firefox es normalmente el campeón en memoria utilizada.

GTK+ es un grupo importante de bibliotecas o rutinas para desarrollar interfaces gráficas de usuario (GUI) para principalmente los entornos gráficos GNOME, XFCE y ROX de sistemas Linux. GTK+ es la abreviatura de GIMP toolkit (conjunto de rutinas para GIMP). Es software libre (bajo la licencia LGPL), multiplataforma y parte importante del proyecto GNU. Inicialmente fue creado para desarrollar el programa de manejo de imágenes GIMP, sin embargo actualmente es muy usada por muchos otros programas en los sistemas GNU/Linux. Cabe mencionar que Qt es una alternativa a GTK que también es muy utilizada (en el entorno KDE, por ejemplo).

GTK+ se ha diseñado para permitir programar con lenguajes como C, C++, Java (Sun), Perl o Python.

GTK ha sido portada a Windows pero el look-and-feel no es nativo.

Qt es una biblioteca multiplataforma para desarrollar interfaces gráficas de usuario. Fue creada por la compañía noruega Trolltech. Qt es utilizada en KDE, un entorno de escritorio para sistemas como GNU/Linux o FreeBSD, entre otros. Utiliza el lenguaje de programación C++ de forma nativa y además existen bindings para C, Python (PyQt), Java (Qt Jambi), Perl (PerlQt) y Ruby (QtRuby) entre otros. El API de la biblioteca cuenta con métodos para acceder a bases de datos mediante SQL, así­ como uso de XML y una multitud de otros para el manejo de ficheros, además de estructuras de datos tradicionales. Inicialmente Qt apareció como biblioteca desarrollada por Trolltech (en aquel momento “Quasar Technologies”) en 1992 siguiendo un desarrollo basado en el código abierto, pero no libre. Se usó activamente en el desarrollo del escritorio KDE (entre 1996 y 1998), con un notable éxito y rápida expansión.

Qt cuenta actualmente con un sistema de doble licencia: una GPL para el desarrollo de software de código abierto (open source) y software libre, y otra de pago para el desarrollo de aplicaciones comerciales. Las librerí­as Qt son también liberadas bajo licencia GPL para Windows y Mac.

wxWidgets son unas bibliotecas multiplataforma, freeware/Open Source para el desarrollo de interfaces gráficas programadas en lenguaje C++. Es una librería pequeña que encapsula en una interfase común llamadas al API nativo de cada sistema operativo.

wxWidgets usan una licencia GPL, concretamente la licencia L-GPL, similar a la GPL con la excepción de que el código binario producido por el usuario a partir de ellas, puede ser propietario, permitiendo desarrollar aplicaciones empresariales sin coste.

Las WxWidgets proporcionan una interfaz gráfica basada en las bibliotecas ya existentes en el sistema (nativas), con lo que se integran de forma óptima y resultan muy portables entre distintos sistemas operativos. Están disponibles para Windows, MacOS, UNIX/Linux, OpenVMS y OS/2. También pueden ser utilizadas desde otros lenguajes de programación, aparte del C++: Java, Javascript, Perl, Python, Smalltalk, Ruby

Ubuntu Unity .desktop

In order to add your launcher to the Unity Launcher on the left, you have to place your .desktop file at /usr/share/applications/ or at ~/.local/share/applications/. After moving your file there, search for it in the Dash (Windows key -> type the name of the application) and drag and drop it to the Unity Launcher. Now your launcher (.desktop file) is locked on the Unity Launcher! If your desktop file cannot be found by doing a search from the Dash, you may need to read on…

To be more certain that your .desktop file will work properly, use the desktop file validator, which will notify you of any errors or omissions. If there are no errors, desktop-file-validator will exit silently.

Once the file validates correctly, install it to the default location (probably /usr/share/applications) using the desktop-file-install program. This step may require superuser privileges. The desktop-file-install program may add some lines of its own to your .desktop file. There is no need to have the .desktop file be executable by anyone.

Please note that desktop-file-validate tends to be oversensitive at times, which means that it can output error messages on perfectly working .desktop files. Those error messages should be better seen as warnings rather than anything else. For more information on desktop entry specification please refer to http://standards.freedesktop.org/desktop-entry-spec/latest/

To create a simple custom .desktop you will need to add these entries to a .desktop file of your choice in ~/.local/share/applications/

nano ~/.local/share/applications/your_application_name.desktop
[Desktop Entry]
Name=the name you want shown
Comment=
Exec=command to run
Icon=icon name
Terminal=false
Type=Application
StartupNotify=true

For extra options for your .desktop file you can visit this site. All the options available are very well described there.

You can also copy a existing application’s .desktop file from /usr/share/applications/to your ~/.local/share/applications/ and edit it to fit your needs.

ie: this will copy gedit .desktop file to the folder where the .desktop files should be saved for a user

cd ~/.local/share/applications
sudo cp /usr/share/applications/gedit.desktop .

After that open that location using nautilus ~/.local/share/applications/ and drag n drop the file you have just created to the Unity launcher.

Has an option instead of drag n dropping the file you can open dconf-editor (install it with sudo apt-get install dconf-tools or look for it in the USC) and navigate to desktop.unity.launcher and edit the key favorites by double clicking on the entries to the right of the key.

To add your custom launcher add it at the position you want with this format ‘/home//.local/share/applications/.desktop’. Don’t forget to respect the , and the spaces in that line and make sure that the line starts and ends with [ and ]respectively.

With this method you will need to log off and back in for the change in favorites to take effect. This will make it appear in the dash

gpg4usb

To say it straight in only one sentence: gpg4usb is a very easy to use portable-application, which combines a simple text-editor with a GnuPG-frontend to write, encrypt and decrypt your text-messages and files. gpg4usb should work on almost any computer you’re working on, should it be a Linux-machine or even one with a Microsoft-OS running.

Almost the only thing required is an available usb-port you are allowed to access. With this application you can write safe and encrypted messages anywhere you are: should it be an internet-cafe, at work or somewhere else on holiday… and you always have the encryption-keys available for usage!

The usage of gpg4usb should be highly self-describing, since the user-interface and all the options it offers are clear cut: Simply execute the binary on your usb-pendrive and start typing e.g. the Mailtext you want to be encrypted. If you’re done, choose the right gpg/pgp-key for the person you are writing to and hit the encrypt-icon at the top of the application-window. The resulting encrypted text you can save as a text-file to send it as mail-attachment, or copy it directly into your mail-user-agent or webmail-website. To make sure, you can read this message by yourself afterwards, encrypt it for the recipient and to yourself at the same time – if you want, you can mark as much keys as you want to encrypt for.

You want to add a gpg/pgp-key to your mobile keyring? Nothing’s easier than that: just hit the crypto-menue-entry and choose Import Key from File or Import Key from Editor. This means that it’s possible to import an ascii-armored pubkey via file-dialog, or via copy&paste into your editor-window. If you find a key e.g. on a website, just copy it, paste it into the gpg4usb-editor and hit Import Key from Editor – that’s it, and the key shows up on your keyring!

Pasted from <http://gpg4usb.cpunk.de/about.html>

Download

You can get our latest Release v0.3.2 by clicking the download link below. Since v0.2.4 the included executables are upx-compressed by default.

Filename Size* sha1
gpg4usb-0.3.2-1.zip 14.8MB / 18.6MB efeeaeff2883ded6abfe6378113c219e5e897bb0

* Size zipped / unzipped

Just download the zip-File and unzip it onto your usb-pendrive. Then simply change into the folder gpg4usb at your usb-drive, and execute the binary in there:

start_linux or start_windows.exe – should be easy to determine, which one’s yours 😉

Since gpg4usb is free software, licensed under the GNU General Public License (GPL), you can use it on as many machines as you want. Copy it, modify and redistribute it, give gpg4usb to as many people as possible! 

Pasted from <http://gpg4usb.cpunk.de/download.html>

Eclipse, herramienta universal – IDE abierto y extensible

Eclipse: una herramienta profesional al alcance de todos Pese a que Eclipse está escrito en su mayor parte en Java (salvo el núcleo) y que su uso más popular sea como un IDE para Java, Eclipse es neutral y adaptable a cualquier tipo de lenguaje, por ejemplo C/C++, Cobol, C#, XML, etc. La característica clave de Eclipse es la extensibilidad. Eclipse es una gran estructura formada por un núcleo y muchos plug-ins que van conformando la funcionalidad final. La forma en que los plug-ins interactúan es mediante interfaces o puntos de extensión; así, las nuevas aportaciones se integran sin dificultad ni conflictos.

Eclipse fue producto de una inversión de cuarenta millones de dólares de IBM en su desarrollo antes de ofrecerlo como un producto de código abierto al consorcio Eclipse.org que estaba compuesto inicialmente por Borland e IBM. IBM sigue dirigiendo el desarrollo de Eclipse a través de su subsidiaria OTI (Object Technologies International), creadora de Eclipse. OTI fue adquirida por IBM en 1996 y se consolidó como gran empresa de desarrollo de herramientas orientadas a objeto (O.O.) desde la popularidad del lenguaje Smalltalk. OTI era la división de IBM en la que se generaron los productos Visual Age, que marcaron el estándar de las herramientas de desarrollo Orientado a objetos. Muchos conceptos pioneros en Smalltalk fueron aplicados en Java, creando Visual Age for Java (VA4J). VA4J fue escrito en Smalltalk. Eclipse es una reescritura de VA4J en Java. La base para Eclipse es la Plataforma de cliente enriquecido (del Inglés Rich Client Platform RCP). Los siguientes componentes constituyen la plataforma de cliente enriquecido:

Plataforma principal – inicio de Eclipse, ejecución de plugins OSGi – una plataforma para integrar distribuciones. El Standard Widget Toolkit (SWT) – Un widget toolkit portable. JFace – manejo de archivos, manejo de texto, editores de texto El Workbench de Eclipse – vistas, editores, perspectivas, asistentes

Los widgets de Eclipse están implementados por un herramienta de widget para Java llamada SWT, a diferencia de la mayoría de las aplicaciones Java, que usan las opciones estándar Abstract Window Toolkit (AWT) o Swing. La interfaz de usuario de Eclipse también tiene una capa GUI intermedia llamada JFace, la cual simplifica la construcción de aplicaciones basada en SWT. El entorno integrado de desarrollo (IDE) de Eclipse emplea módulos (plug-in) para proporcionar toda su funcionalidad al frente de la plataforma de cliente rico, a diferencia de otros entornos monolí­ticos donde las funcionalidades están todas incluidas, las necesite el usuario o no. Este mecanismo de módulos es una plataforma ligera para componentes de software. Se provee soporte para Java y CVS en el SDK de Eclipse. En cuanto a las aplicaciones clientes, eclipse provee al programador con frameworks muy ricos para el desarrollo de aplicaciones gráficas, definición y manipulación de modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework – Framework para la edición gráfica) es un plugin de eclipse para el desarrollo de editores visuales que pueden ir desde procesadores de texto wysiwyg hasta editores de diagramas UML, interfaces gráficas para el usuario (GUI), etc. El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un IDE con un compilador de Java interno y un modelo completo de los archivos fuente de Java. Esto permite técnicas avanzadas de refactorización y análisis de código. El IDE también hace uso de un espacio de trabajo, en este caso un grupo de metadata en un espacio para archivos plano, permitiendo modificaciones externas a los archivos en tanto se refresque el espacio de trabajo correspondiente. Núcleo: su tarea es determinar cuales son los plug-ins disponibles en el directorio de plug-ins de Eclipse. Cada plug-in tiene un fichero XML manifest que lista los elementos que necesita de otros plug-ins así­ como los puntos de extensión que ofrece. Como la cantidad de plug-ins puede ser muy grande, solo se cargan los necesarios en el momento de ser utilizados con el objeto de minimizar el tiempo de arranque de Eclipse y recursos. Entorno de trabajo: maneja los recursos del usuario, organizados en uno o más proyectos. Cada proyecto corresponde a un directorio en el directorio de trabajo de Eclipse, y contienen archivos y carpetas. Interfaz de usuario: muestra los menús y herramientas, y se organiza en perspectivas que configuran los editores de código y las vistas. A diferencia de muchas aplicaciones escritas en Java, Eclipse tiene el aspecto y se comporta como una aplicación nativa. Esta programada SWT (Standard Widget Toolkit) y Jface (juego de herramientas construida sobre SWT), que emula los gráficos nativos de cada sistema operativo. Este ha sido un aspecto discutido sobre Eclipse, porque SWT debe ser portada a cada sistema operativo para interactuar con el sistema gráfico. En los proyectos de Java puede usarse AWT y Swing salvo cuando se desarrolle un plug-in para Eclipse. Para descargar Eclipse existen distribuciones con diferentes combinaciones de plug-ins dependiendo del uso que se le quiera dar a la herramienta. Un problema que se presenta con estas distribuciones es que en Windows XP el descompresor integrado a veces falla y es preferible usar un programa externo como 7-zip, WinZIP, o info-zip

La reutilización de código

Ahora, como antes, más que antes, como siempre, la reutilización de código se presenta como un valor fundamental en el desarrollo de sistemas. Uno de sus aspectos es la interoperabilidad de los códigos. Por decirlo de alguna manera, la compatibilidad de una aplicación con diferentes versiones de un sistema operativo y con diferentes sistemas operativos.

Por un lado Microsoft, por otro los demás. El imperio contra los rebeldes republicanos y los feudos vecinos. Pero dentro del mismo imperio se hablan distintas lenguas y los rebeldes tienen diferentes agendas.

Una aplicación que trabaja en Windows 95 no necesariamente funciona en Windows XP, Visual Basic 6 y Visual Basic .Net son animales distintos. Una aplicación Linux que funciona en la distribución Red Hat no necesariamente funciona en la distribución SuSe. La frase platform independent source en la practica marca una prueba de iniciación para hechiceros.

En el caso de Microsoft, algunas de estas incompatibilidades son de origen mercadológico. ¿Cuál es la diferencia entre Windows XP Home Edition y Windows XP Pro? Limitaciones artificiales en la versión casera con respecto a la versión profesional. Desde el punto de vista de Microsoft este modelo funciona, Vista no tiene 2 versiones distintas sino n, cada una definida por un segmento de mercado. Las utilidades de MS aumentaron 65% con respecto al año pasado y podemos esperar más de lo mismo por lo menos en el corto plazo.

En el caso del movimiento Open Source las incompatibilidades son de origen sociocultural. Distintos grupos trabajan con combinaciones distintas de herramientas y enfoques metodológicos. Estos herramentales se yuxtaponen unos con otros y las combinaciones son infinitas. La versión de gcc pude ser la diferencia clave para que un paquete se construya correctamente.

Una iniciativa que no termino de entender es Mono. El concepto es bueno, pero ya va un par de veces que trato de construir una aplicación .Net para fallar miserablemente. Al revisar la letra chiquita del readme aparece que la aplicación es Mono ¿Cuál es el caso de incluir archivos de solución y proyecto de Visual Studio si VS no puede construir la aplicación? ¿Si se requiere reproducir el ambiente de trabajo del desarrollador con librerí­as y variables de entorno porque no documentar esas dependencias? Entiendo que son pecadillos del bien intencionado pero se me escapa la motivación fundamental del chango.

http://www.go-mono.com/docs/
http://www.codeproject.com/cpnet/hellomono.asp

Un aspecto problemático del desarrollo í­nter plataforma son las interfaces graficas de usuario (GUI). Cada sistema operativo tiene su look-and-feel caracterí­stico y el manejo eficiente de ventanas requiere el uso del API nativo correspondiente.

Un enfoque que se puede tomar es agregar una capa intermedia entre la aplicación y el sistema operativo que abstraiga la interacción entre la capa lógica y la interfase grafica a cambio de una penalización en el rendimiento. Algunos problemas que se pueden presentar con librerí­as de este tipo:

  • El uso de una capa intermedia adicional disminuye el rendimiento de la aplicación.
  • La librerí­a necesaria para soportar la funcionalidad adicional de múltiples sistemas operativos aumenta le tamaño de las aplicaciones más alla de lo que se justifica con la funcionalidad de la aplicación misma. Por lo mismo el soporte para plataforma móvil no es adecuado
  • La apariencia de la aplicación no corresponde a la de una aplicación nativa y los diálogos son distintos a los que los usuarios usan normalmente.
  • La necesidad de definir un mí­nimo común denominador hace que se pierda la oportunidad de usar las características más avanzadas de un sistema operativo en particular.
  • El uso de librerí­as fuera de la esfera de influencia del sistema operativo anfitrión saca a la aplicación del ciclo de vida del mismo y dificulta el proceso de mantener alineadas las actualizaciones de la aplicación con cambios en el sistema operativo.

La tabla siguiente muestra un comparativo de librerí­as para desarrollo ínter plataforma.

Liberarí­a Tamaño (MB) Tamaño comprimido (MB)
Java 30+ 15
GTK+ 9+ 4
QT 4+ 2
wxWidgets <1 <.5

Java es una norma abierta que funciona bien como propuesta í­nter plataforma. La maquina virtual de java (JVM) aísla la aplicación del sistema operativo anfitrión y esta disponible normalmente en todas partes. Sin embargo las aplicaciones de java tienden a ser chupa recursos. Si revisas los procesos en una estación XP con Firefox instalado, Firefox es normalmente el campeón en memoria utilizada.

GTK+ es un grupo importante de bibliotecas o rutinas para desarrollar interfaces gráficas de usuario (GUI) para principalmente los entornos gráficos GNOME, XFCE y ROX de sistemas Linux. GTK+ es la abreviatura de GIMP toolkit (conjunto de rutinas para GIMP). Es software libre (bajo la licencia LGPL), multiplataforma y parte importante del proyecto GNU. Inicialmente fue creado para desarrollar el programa de manejo de imágenes GIMP, sin embargo actualmente es muy usada por muchos otros programas en los sistemas GNU/Linux. Cabe mencionar que Qt es una alternativa a GTK que también es muy utilizada (en el entorno KDE, por ejemplo).

GTK+ se ha diseñado para permitir programar con lenguajes como C, C++, Java (Sun), Perl o Python.

GTK ha sido portada a Windows pero el look-and-feel no es nativo.

Qt es una biblioteca multiplataforma para desarrollar interfaces gráficas de usuario. Fue creada por la compañía noruega Trolltech. Qt es utilizada en KDE, un entorno de escritorio para sistemas como GNU/Linux o FreeBSD, entre otros. Utiliza el lenguaje de programación C++ de forma nativa y además existen bindings para C, Python (PyQt), Java (Qt Jambi), Perl (PerlQt) y Ruby (QtRuby) entre otros. El API de la biblioteca cuenta con métodos para acceder a bases de datos mediante SQL, así­ como uso de XML y una multitud de otros para el manejo de ficheros, además de estructuras de datos tradicionales. Inicialmente Qt apareció como biblioteca desarrollada por Trolltech (en aquel momento “Quasar Technologies”) en 1992 siguiendo un desarrollo basado en el código abierto, pero no libre. Se usó activamente en el desarrollo del escritorio KDE (entre 1996 y 1998), con un notable éxito y rápida expansión.

Qt cuenta actualmente con un sistema de doble licencia: una GPL para el desarrollo de software de código abierto (open source) y software libre, y otra de pago para el desarrollo de aplicaciones comerciales. Las librerí­as Qt son también liberadas bajo licencia GPL para Windows y Mac.

wxWidgets son unas bibliotecas multiplataforma, freeware/Open Source para el desarrollo de interfaces gráficas programadas en lenguaje C++. Es una librería pequeña que encapsula en una interfase común llamadas al API nativo de cada sistema operativo.

wxWidgets usan una licencia GPL, concretamente la licencia L-GPL, similar a la GPL con la excepción de que el código binario producido por el usuario a partir de ellas, puede ser propietario, permitiendo desarrollar aplicaciones empresariales sin coste.

Las WxWidgets proporcionan una interfaz gráfica basada en las bibliotecas ya existentes en el sistema (nativas), con lo que se integran de forma óptima y resultan muy portables entre distintos sistemas operativos. Están disponibles para Windows, MacOS, UNIX/Linux, OpenVMS y OS/2. También pueden ser utilizadas desde otros lenguajes de programación, aparte del C++: Java, Javascript, Perl, Python, Smalltalk, Ruby

Minimalist GNU for Windows

MinGW o MinGW32 (Minimalist GNU for Windows) es una implementación de los compiladores GCC para la plataforma Win32, que permite migrar aplicaciones GNU a entornos Windows. Es un derivado de Cygwin en su versión 1.3.3.

MinGW incluye un conjunto de la api de Win32, permitiendo un desarrollo de aplicaciones nativas para esa plataforma, pudiendo generar ejecutables y librerí­as usando la API de Windows.

MinGW fue creado por Colin Peters, el 1 de julio de 1998, compilándolo con Gygwin. La primera versión nativa de MinGW fue realizada por Jan-Jaap van der Heijden, quien también tuvo participación en el proyecto GCC. Mumit Khan estuvo a cargo del mantenimiento del proyecto e incluyo al compilador algunas características propias de Windows. Los archivos de cabecera del API de Windows fueron provistos por Anders Norlander.

Una de las desventajas de MinGW es que los ejecutables que genera son de tamaño más grande que los generados por otros compiladores. Esto ocurre cuando se incluyen los archivos de cabecera estándares de C++ (por ejemplo, #include ), y se debe a que el compilador vincula todas las librerí­as dentro del archivo ejecutable de manera estática.

MinGW incluye MSYS (Minimal SYStem) un shell POSIX/Bourne para ejecutar scripts de configuración usados por make y ./configure

Después de descargar MinGW y MSYS, incluyendo mingw-runtime, w32api, binutils y gcc, gdb y mingw32-make se pueden expandir los archivos de dos formas. Poner el directorio de MinGW dentro de MSYS o instalarlos en directorios distintos y modificar el archivo MSYS /etc/fstab para agregar un apuntador al directorio donde mingw esta instalado.

Para probar la instalación se puede correr el shell de msys y probar el comando de línea

gcc –v

Para habilitar el soporte de IDEs agregar lib a la variable de entorno LIBRARY_PATH y los subdirectorios bin de y a la variable de entorno PATH
Aplicación de consola:

En un archivo con el nombre hello.c poner el siguiente código:

#include

int main(int argc, char **argv)
{
printf (“Hellon”);
return (0);
}

y compilar con

gcc -c hello.c

y después

gcc -o hello hello.o

Alternativamente

gcc -o hello hello.c

En un archivo con el nombre hello.cpp poner el siguiente código:

#include
int main(int argc, char **argv)
{
std::cout return (0);
}

y compilar con

g++ -c hello.cpp
g++ -o hello hello.o
Aplicación Windows

En un archivo con el nombre hello.c poner el siguiente código:

#include

int WINAPI WinMain (HINSTANCE hInstance,
HINSTANCE hPrevInstance,
PSTR szCmdLine,
int iCmdShow)
{
MessageBox (NULL, “Hello”, “Hello Demo”, MB_OK);
return (0);
}

para crear el ejecutable usar los comandos de linea

gcc -c hello.c

y

gcc -o hello hello.o -mwindows

el parametro -mwindows es necesario para que se incluyan las librerias necesarias para un programa Windows.
dll

En un archivo con el nombre dllfct.h poner el siguiente código:

#ifdef BUILD_DLL
// the dll exports
#define EXPORT __declspec(dllexport)
#else
// the exe imports
#define EXPORT __declspec(dllimport)
#endif

// function to be imported/exported
EXPORT void tstfunc (void);

En un archivo con el nombre dllfct.c poner el siguiente código:

#include
#include “dllfct.h”

EXPORT void tstfunc (void)
{
printf (“Hellon”);
}

En un archivo con el nombre Hello.c poner el siguiente código:

#include “dllfct.h”

int main ()
{
tstfunc ();
return (0);
}

Para crear una dll y un ejecutable que lo use:

gcc -c hello.c
gcc -c -DBUILD_DLL dllfct.c
gcc -shared -o tst.dll -Wl,–out-implib,libtstdll.a dllfct.o
gcc -o hello.exe hello.o -L./ -ltstdll

Se puede especificar el directorio a usar para los includes durante la compilación con

-I/path/to/headers

y las librerias para link:

-L/usr/lib/library

Usualmente no hay necesidad de andar moviendo las librerias.
Archivo .def para un dll

Si tiene un dll llamado file.dll y quiere crear un archivo .def con el nombre file.def,

echo EXPORTS > file.def
nm file.dll | grep ‘ T _’ | sed ‘s/.* T _//’ >> file.def

Para crear una biblioteca con el nombre file.a :

dlltool –def file.def –dllname file.dll –output-lib file.a

Construyendo bzip2 con mingw

bzip2 es una rutina de compresión de código libre. bzip2 es competitivo con las mejores técnicas estadí­sticas (PPM) en términos de compresión pero mucho más rápido. El código de bzip2 esta escrito en ansi c y no tiene dependencias, así­ que quise usarlo para probar varios enfoques para construir los ejecutables en Windows XP siendo una aplicación cuyo ambiente natural es Linux.

mingw

Una diferencia en el modelo de archivos entre Windows y Unix es como se determina si un archivo es ejecutable o no.

En unix los privilegios de ejecución de un archivo están definidos dentro de la estructura interna del archivo y existen utilerí­as como chmod que permiten manipular los privilegios de ejecución.

En Windows, la extensión de un archivo determina si es un ejecutable o no. los archivo ejecutables en Windows tiene la terminación .exe. Existen otras terminaciones de archivos ejecutables, pero si el archivo tiene un terminación que no este en la lista entonces no es un ejecutable. Dicho de otra manera, En Windows, la terminación de un archivo determina que aplicación (ejecutalbe) esta asociada con él.

Para crear el ejecutable de bizp2 usando mingw

Bajar las fuentes de bzip2
Modificar el archivo Makefile quitando las lineas que contengan la instrucción
chmod a+x
En el shell de msys ir al directorio de los fuentes de bzip2 y ejecutar el comando
make install

Visual Studio 2005 command prompt

En el shell de comandos de Visual Studio 2005 ir al directorio de los fuentes de bzip2 y ejecutar el comando
nmake -f makefile.msc

Al ejecutarse el nmake hay algunos warnings pero los ejecutables se generan bien

Visual Studio 2005 Proyecto Visual C++ win32

Abrir un nuevo proyecto del tipo libreria estatica con el nombre de salida libbz2.lib
Agregar los archivos

blocksort.c
huffman.c
crctable.c
randtable.c
compress.c
decompress.c
bzlib.c
bzlib.h
Construir la libreria
Abrir un nuevo proyecto del tipo consola
Agregar el archivo
bzip2.c
Agregar la referencia a libbz2.lib en los archivos de entrada del linker
construir el ejecutable