martes, diciembre 30, 2008

Porcentajes ¿sencillos?

http://joseluis.estebanaparicio.googlepages.com/pensarporcentajessencillos


Yo creo que los "porcentajes" no son tan sencillos como parecen



  1. ¿Porqué un tendero anuncia que los productos de la competenica son un 50% más caros?
  2. Un tendero sube el precio de las bolsas de naranjas.
    Duda entre subir un 5% el precio o reducir un 5% el peso de las bolsas
    ¿Qué es más rentable para el tendero?
  3. Tenemos 100Kg de patatas.
    Sabemos que el 99% es agua.
    Después de pasar uos días en la calle, nos informan de que se han secado un poco.
    Ahora, el 98% es agua
    ¿Cuánto pesan ahora las patatas?
  4. Un inversor nos informa de que nos cobra x de comisión.
    Inmediatamente después, se producen pérdidas en nuestra inversión.
    Le reclamamos y nos dice...
    Es cierto, has perdido dinero, pero ten en cuenta, que mi comisión ha pasado a ser el 1% de la inversión a ser el 2%.
    Evidentemente, la comisión es fija x y es la misma antes y depués de las pérdidas.
    ¿Cuánto dinero hemos perdido?

Frases célebres de la informática

Saying that Java is good because it works on all platforms is like saying anal sex is good because it works on all genders.







http://www.javahispano.org/contenidos/es/frases_celebres_acerca_de_la_programacion/



"Debugging es dos veces más difícil que escribir el código en primer lugar. Entonces si escribes el código tan astutamente como sea posible, no eres -por definición- tan listo como para debugearlo."

Brian Kernighan



"Sólo hay dos tipos de lenguajes: aquellos de los que la gente se queja y aquellos que nadie usa."

Bjarne Stroustrup



"Cualquier tonto puede escribir código que un ordenador entiende. Los buenos programadores escriben código que los humanos pueden entender."

Martin Fowler



"Hay dos formas de diseñar software: la primera es hacerlo tan simple que obviamente no hay deficiencias y la segunda es hacerlo tan complicado que no hay deficiencias obvias. La primera forma es mucho más difícil.".

C.A.R. Hoare



"Mucho del software hoy en día se parece a una pirámide egipcia: con millones de ladrillos apilados uno encima del otro, sin integridad estructural y hecho por pura fuerza bruta y miles de esclavos."

Alan Kay



"Medir el progreso de la programación por líneas de código es como medir el progreso en la construcción de aviones por el peso."

Bill Gates



"Si deseas empezar y desarrollar algo grandioso, no necesitas millones de dólares de capitalización. Necesitas suficiente pizza y Diet Coke en la nevera, una PC barata y trabajo y dedicación para realizar tu idea."

John Carmack



"Los programas deben ser escritos para que la gente los lea y sólo incidentalmente, para que las máquinas los ejecuten."

Abelson / Sussman



"Pregunta: ¿Cómo se atrasa un año un proyecto grande de software? Respuesta: Un día a la vez."

Fred Brooks



"Nadie debe empezar un proyecto grande. Empiezas con uno pequeño y trivial y nunca debes esperar que crezca; si lo haces solamente sobre-diseñarás y generalmente pensarás que es más importante de lo que lo es en esta etapa. O peor, puedes asustarte por el tamaño de lo que tu esperas que crezca. Así que empieza pequeño y piensa en los detalles. No pienses acerca de la foto grande y el diseño elegante. Si no resuelve una necesidad inmediata, seguramente está sobre-diseñado. Y no esperes que la gente salte a ayudarte, no es así como estas cosas funcionan. Primero debes tener algo medianamente usable y otros dirán "hey, esto casi funciona para mí" y se involucrarán en el proyecto."

Linus Torvalds




"Debo confesar un fuerte prejuicio en contra de la moda del código reusable. Para mí, "el código re-editable" es mucho, mucho mejor que una caja negra intocable."
Donald Knuth



"Llevo 16 años trabajando y he pasado por más de media docena de empresas, habiendo participado en proyectos pequeños, medianos y grandes, en el sector público y en el privado. Mi experiencia y la de mucha otra gente es que el método seguido habitualmente es el de tipo "Braveheart", a saber:



Te pintas la cara de azul y blanco
Te pones una falda escocesa
Coges el primer objeto contundente que tengas a mano
Corres colina abajo con el resto de tus colegas a ver cuantos ingleses puedes degollar antes de que te degollen a ti
Fin del proyecto."


"Programar es tan fácil como caminar sobre el agua... siempre y cuando tanto las especificaciones como el agua estén congeladas".

domingo, diciembre 28, 2008

Salto de la pulga

¿Cuál es la acelaración que soporta una pulga que salta 15cm?

http://joseluis.estebanaparicio.googlepages.com/saltodelapulga

viernes, diciembre 26, 2008

git vs svn

http://git.or.cz/gitwiki/GitSvnComparsion


Note: This page is currently a work in progress. It started out as a private email to someone who currently uses Subversion. I decided to make it available and try to extend it further. I'll remove this comment when the page is improved. -- Shawn Pearce

Although this page is hosted on a Git-specific Wiki it tries to provide a fair and unbiased comparison of Git and Subversion to help prospective users of both tools better evaluate their choices. This page only describes base Subversion and does not discuss the benefits and drawbacks to using SVK, a distributed wrapper around Subversion.

Some comments for consideration in the next rev: A distinct bias is evident in the pro-svn section, which attempts to mitigate git's disadvantages (e.g., it talks more about how well git UI's are progressing than how incredibly good Subversion's UI's are; likewise, but less so, in 'Shorter Revision Numbers'). Also not mentioned are Subversion's support for http(s) and WebDAV, and its excellent support for Windows (in stark contrast to git's)

Git's Major Features Over Subversion

There are a number of key features in Git that really make it stand out when compared to Subversion. Among them are the following:

Distributed Nature

Git was designed from the ground up as a distributed version control system. Being a distributed version control system means that multiple redundant repositories and branching are first class concepts of the tool.

In a distributed VCS like Git every user has a complete copy of the repository data stored locally, thereby making access to file history extremely fast, as well as allowing full functionality when disconnected from the network. It also means every user has a complete backup of the repository. Have 20 users? You probably have more than 20 complete backups of the repository as some users tend to keep more than one repository for the same project. If any repository is lost due to system failure only the changes which were unique to that repository are lost. If users frequently push and fetch changes with each other this tends to be an incredibly small amount of loss, if any.

In a centralized VCS like Subversion only the central repository has the complete history. This means that users must communicate over the network with the central repository to obtain history about a file. It also means that having 20 users does not automatically imply 20 active backups. Backups must be maintained independently of the VCS. If the central repository is lost due to system failure it must be restored from backup and all changes since that last backup are likely to be lost. Depending on the backup policies in place this could be several man-weeks worth of work.

(Note that even SVK doesn't do quite the same thing as git. SVK downloads a complete history and allows disconnected commits, but there is still a unique "upstream" repository. Two SVK users can't merge with each other and then push the changes to the upstream.)

Access Control

Due to being distributed, you inherently do not have to give commit access to other people. Instead, you decide when to merge what from whom. (There exist different mechanisms of control in case you do want to have a repository into which multiple people can push to. -not covered yet here-)

Branch Handling

Branches in Git are a core concept used everyday by every user. In Subversion they are almost an afterthought and tend to be avoided unless absolutely necessary.

The reason branches are so core in Git is every developer's working directory is itself a branch. Even if two developers are modifying two different unrelated files at the same time it's easy to view these two different working directories as different branches stemming from the same common base revision of the project.

Consequently Git:

Automatically tracks the project revision the branch started from.
Knowing the starting point of a branch is necessary in order to successfully merge the branch back to the main trunk that it came from.
Automatically records branch merge events.
Merge records always include the following details:
Who performed the merge.
What branch(es) and revision(s) were merged.
All changes made on the branch(es) remain attributed to the original authors and the original timestamps of those changes.
What additional changes were made to complete the merge successfully.
Any changes made during the merge that is beyond those made on the branch(es) being merged is attributed to the user performing the merge.
When the merge was done
Why the merge was done (optional; can be supplied by the user).
Automatically starts the next merge at the last merge.
Knowing what revision was last merged is necessary in order to successfully merge the same branches together again in the future.
This is quite contrary to Subversion's handling of branches. As of Subversion 1.3:

Automatically tracks the project revision the branch started from.
Like Git Subversion remembers where a branch originated.
Incomplete merge event record:
Although Subversion records a merge as a commit and thus associates a username and a timestamp to it (like Git) there are some serious flaws in this record.
All changes made on the branch appear to be made by the merging user.
This means that from a historical perspective every line of code modified on the branch will appear in the trunk as though it was written by the user who merged the branch. This is wrong if there were other users working on that branch.
It's impossible to see only merge related changes.
If the merging user had to modify 12 lines of code to complete the merge successfully you can't tell what those 12 lines were, or how those 12 lines differ from the versions on the branches being merged.
The user must manually record what branches were merged and what versions they were.
Unlike Git Subversion does not automatically include these details. Consequently unless the user performing the merge explicitly includes these details in the commit message it's impossible to know what exactly was merged.
Does not track merge bases.
Because Subversion does not record important details about a branch merge it cannot provide the new merge base on subsequent branch merges. What this means in practice is that users must manually track branch merge points so subsequent merges can be completed.
In short Subversion's branching implementation is significantly flawed while Git's implementation accurately records the activity and is fully automatic.

In the current Subversion release (1.5), merge tracking has been significantly improved, see http://subversion.tigris.org/merge-tracking/ for details. Would be nice if someone would update this comparison to take this into account.

Supplement: In Subversion, branches and tags all are copies, it's a smart idea, but sometimes it's not convenient, many newbies checkout the whole repository by mistake or are confused when update or merge a moved branch. Branch path and file path lie in same namespace but they have different semantics indeed and should be taken care in different way.

Performance (Speed of Operation)

Git is extremely fast. Since all operations (except for push and fetch) are local there is no network latency involved to:

Perform a diff.
View file history.
Commit changes.
Merge branches.
Obtain any other revision of a file (not just the prior committed revision).
Switch branches.
FIXME: Include actual comparisons, e.g. load Git code into both Git and SVN.

Small Space Requirements

Git's repository and working directory sizes are extremely small when compared to SVN.

For example the Mozilla repository is reported to be almost 12 GiB when stored in SVN using the fsfs backend. The fsfs backend also requires over 240,000 files in one directory to record all 240,000 commits made over the 10 year project history. The exact same history is stored in Git by only two files totaling just over 420 MiB. SVN requires 30x the disk space to store the same history.

An SVN working directory always contains two copies of each file: one for the user to actually work with and another hidden in .svn/ to aid operations such as status, diff and commit. In contrast a Git working directory requires only one small index file that stores about 100 bytes of data per tracked file. On projects with a large number of files this can be a substantial difference in the disk space required per working copy.

Line Ending Conversion

Subversion can be easily configured to automatically convert line endings to CRLF or LF, depending on the native line ending used by the client's operating system. This conversion feature is useful when Windows and UNIX users are collaborating on the same set of source code. It is also possible to configure a fixed line ending independent of the native operating system. Files such as a Makefile need to only use LFs, even when they are accessed from Windows. This can be adjusted in a global config and overridden in user configs. Binary files are checked in with a binary flag (like with CVS except that SVN does this almost always automatically) and such never get converted or keyword substituted. Although Additionally Subversion allows the user to specify line ending conversion on a file-by-file basis. But if the user does not check binary flag on adding (Subversion prints for every added file whether it recognized it as binary) binary content might get corrupted.

Whilst Git versions prior 1.5.1 never convert files and always assume that every file is opaque and should not be modified. Git 1.5.1 and onwards make this configurable. For users on Windows they should set core.autocrlf = true so that text files are automatically checked out with CRLF and checked in as LF. Git's advantage over Subversion is that you do not have to manually specify which files this conversion should be applied to, it happens automatically (hence autocrlf).


Subversion's Major Features Over Git

Subversion has some notable features that Git currently doesn't have or will never have.

User Interfaces

Currently Subversion has a wider range of user interface tools than Git. For example there are SVN plugins available for most popular IDEs. There is a Windows Explorer shell extension. There are a number of native Windows and Mac OS X GUI tools available in ready-to-install packages.

Git's primary user interface is through the command line. There are two graphical interfaces: git-gui (distributed with Git) and qgit, which is making great strides towards providing another feature-complete graphical interface. Also gitk, the graphical history browser, can be more than just a fancy log reader. git-gui and gitk usually work out-of-box for common operating systems, and qgit is being ported to Qt4, which improves its portability.

Single Repository

Since Subversion only supports a single repository there is little doubt about where something is stored. Once a user knows the repository URL they can reasonably assume that all materials and all branches related to that project are always available at that location. Backup to tape/CD/DVD is also simple as there is exactly one location that needs to be backed up regularly.

Since Git is distributed by nature not everything related to a project may be stored in the same location. Therefore there may be some degree of confusion about where to obtain a particular branch, unless repository location is always explicitly specified. There may also be some confusion about which repositories are backed up to tape/CD/DVD regularly, and which aren't.

Access Controls

Since Subversion has a single central repository it is possible to specify read and write access controls in a single location and have them be enforced across the entire project.

Binary Files

Detection and Properties

Subversion can be used with binary files (it is automatically detected; if that detection fails, you have to mark the file binary yourself). Just like Git.

Only that with Git, the default is to interpret the files as binary to begin with. If you _have_ to have CR+LF line endings (even though most modern programs grok the saner LF-only line endings just fine), you have to tell Git so. Git will then autodetect if a file is text (just like Subversion), and act accordingly. Analogous to Subversion, you can correct an erroneous autodetection by setting a git attribute.

I'm not sure why this point is here ; both git and svn process content verbatim by default. Neither git or svn will munge line-endings unless you ask them to. svn appears to have one more option for munging (CR), which won't be used often. The chief difference is that git supports path-globbing for attributes, whereas on svn they must be applied on a per-file basis, necessarily so because svn supports checkout of subtrees so you could be decapitating your attribute metadata. Otherwise, on the matter of "not screwing up your files by making assumptions about the content", they seem equal.

Marking a file with the correct mime-type is important when you do things like surf your repository with a browser (esp. for web content, a browser that respects the mime-type (IE, not IE) will by default, display all HTML as plaintext from mod_dav_svn). svn mime-type autodetection (a subset of the auto-props feature) can be configured to specify a mime-type based on filename extension, as well as the default basic detection of application/octet-stream. You could happily do this with attribute globs on git, if I read the manual right, setting the crlf attribute. One big difference I do see is that if you turn on core.autocrlf, if a file is falsely determined to be text, it will get munged for line endings. On svn you must identify each file that you want line endings munged for manually (or via a manually configured feature).

All in all, yes, git has a slightly more convenient properties feature, but scoring for or against either product on these points is marginal ; both deal with binary and text properly, both have metadata features, both let you control EOL munging in an equivalent way. I would be shy about turning on autocrlf globally for git, simply because I don't think it's necessary for the majority of projects.

Change Tracking

Seemingly minor changes to binary files, such as adjusting brightness on an image, could be different enough that Git interprets them as a new file, causing the content history to split. Since Subversion tracks by file, history for such changes is maintained.

Partial Checkout

With Subversion, you can check out just a subdirectory of a repository. Such a thing is not possible with Git.

Shorter Revision Numbers

As SVN assigns revision numbers sequentially (starting from 1) even very old projects such as Mozilla have short unique revision numbers (Mozilla is only up to 6 digits in length). Many users find this convenient when entering revisions for historical research purposes. They also find this number easy to embed into their product, supposedly making it easy to determine which sources were used to create a particular executable. However since the revision number is global to the entire repository, including all branches, there is still a question of which branch the revision number corresponds to.

Unless the last committed revision is recorded. Since revisions are global for a repository, the last committed revision makes it possible to determine which branch was used

As Git uses a SHA1 to uniquely identify a commit each specific revision can only be described by a 40 character hexadecimal string, however this string not only identifies the revision but also the branch it came from. In practice the first 8 characters tends to be unique for a project, however most users try to not rely on this over the long term. Rather than embedding long commit SHA1s into executables Git users generate a uniquely named tag. This is an additional step, but a simple one.


The Original Email

Provided as reference, until this page is cleaned up.

The key things that I like about Git are:

- It's incredibly fast.
No other SCM that I have used has been able to keep up with it, and I've used a lot, including Subversion, Perforce, darcs, BitKeeper, ClearCase and CVS.
- It's fully distributed.
The repository owner can't dictate how I work. I can create branches and commit changes while disconnected on my laptop, then later synchronize that with any number of other repositories.
- Synchronization can occur over many media.
An SSH channel, over HTTP via WebDAV, by FTP, or by sending emails holding patches to be applied by the recipient of the message. A central repository isn't necessary, but can be used.
- Branches are even cheaper than they are in Subversion.
Creating a branch is as simple as writing a 41 byte file to disk. Deleting a branch is as simple as deleting that file.
- Unlike Subversion branches carry along their complete history.
without having to perform a strange copy and walk through the copy. When using Subversion I always found it awkward to look at the history of a file on branch that occurred before
the branch was created. from #git: spearce: I don't understand one thing about SVN in the page. I made a branch i SVN and browsing the history showed the whole history a file in the branch
- Branch merging is simpler and more automatic in Git.
In Subversion you need to remember what was the last revision you merged from so you can generate the correct merge command. Git does this automatically, and always does it right. Which means there's less chance of making a mistake when merging two branches together.
- Branch merges are recorded as part of the proper history of the
repository. If I merge two branches together, or if I merge a branch back into the trunk it came from, that merge operation is recorded as part of the repostory history as having been performed by me, and when. It's hard to dispute who performed the merge when it's right there in the log.
- Creating a repository is a trivial operation:
mkdir foo; cd foo; git init-db
That's it. Which means I create a Git repository for everything these days. I tend to use one repository per class. Most of those repositories are under 1 MB in disk as they only store lecture notes, homework assignments, and my LaTeX answers.
- The repository's internal file formats are incredible simple.
This means repair is very easy to do, but even better because it's so simple its very hard to get corrupted. I don't think anyone has ever had a Git repository get corrupted. I've seen Subversion with fsfs corrupt itself. And I've seen Berkley DB corrupt itself too many times to trust my code to the bdb backend of Subversion.
- Git's file format is very good at compressing data, despite
it's a very simple format. The Mozilla project's CVS repository is about 3 GB; it's about 12 GB in Subversion's fsfs format. In Git it's around 300 MB.
Links

http://utsl.gen.nz/talks/git-svn/intro.html
http://techblog.floorplanner.com/2008/12/09/git-vs-svn-for-bosses/

git vs all

http://es.whygitisbetterthanx.com/#


Por qué Git es mejor que X

hg bzr svn perforce

Este sitio existe porque últimamente me parece que paso demasiado tiempo defendiendo a los usuarios de Git frente a acusaciones de fanatismo, seguidimo y fe ciega. Así que aquí veremos por qué la gente está pasándse de X a Git y por qué tú también deberías. Sólo haz clic en una razón para verla.
Ver todas | Cerrar todas

hg bzr svn perforce
Ramas locales sin coste
Posiblemente la razón más fuerte a favor de Git que realmente lo hace destacar de casi cualquier otro SCV es su modelo de ramas. Es totalmente diferente de todos los demás con los que lo estamos comparando, la mayoría de los cuales recomiendan que la mejor rama es básicamente una copia del repositorio en un nuevo directorio.
Pero Git no funciona así. Git te permitirá tener múltiples ramas locales que pueden ser totalmente independientes entre sí y se tarda segundos en crear, fusionar, o borrar estas líneas de desarrollo.
Lo que quiere decir que puedes hacer cosas como :
Crear una rama para probar una idea, hacer varias entregas un par de veces, volver al punto desde el cual bifurcaste, aplicar un parche y volver a donde estabas experimentado y fusionarlo.
Tener una rama que siempre contiene sólo lo que va a producción, otra en la que acumulas el trabajo para testear y varias ramas más pequeñas para el trabajo del día a día.
Crear nuevas ramas para cada una de las nuevas funcionalidades en las que estés trabajando, de forma que puedas conmutar entre ellas y borrarlas cuando su funcionalidad ha sido propagada a la rama principal.
Crear una rama en la que experimentar, darte cuenta de que no va a ninguna parte y borrarla, abandonando todo el trabajo - sin que nadie más lo vea (incluso aunque hayas entregado otras ramas mientras tanto)

Es importante el que, cuando uno entrega sus cambios a un repositorio remoto, no tienes que subir todas tus ramas: puedes compartir sólo una de tus ramas y no todas. De esta forma la gente tiende a sentirse libre para probar nuevas ideas sin preocuparse de tener un plan de cómo y cuándo van a mezclar sus cambios o compartirlos con otros.
Se pueden encontrar maneras de hacer algunas de estas cosas en otros sistemas, pero el trabajo necesario es mucho más complicado y dado a error. Git hace que este proceso sea increíblemente sencillo y cambia la forma en la que trabajan los desarrolladores que aprenden a usarlo.
svn perforce
Todo es local
Esto es básicamente cierto en todos los SCV distribuidos, pero en mi mi experiencia lo es mucho más con Git. Aparte de 'fetch', 'pull' y 'push' hay muy pocos comandos que trabajen con cualquier cosa que no sea tu disco duro.
Esto no sólo hace que todo vaya mucho más rápido que de costumbre, también te permite trabajar cuando estés sin conexión. Que a lo mejor no te parece gran cosa, pero a mí al menos me ha llegado a sorprender la cantidad de veces que realmente trabajo sin conexión. El poder hacer ramas, mezclarlas, y navegar por la historia de mi proyecto mientras se está en un avión o un tren es realmente muy productivo.

Incluso en Mercurial comandos comunes como 'incoming' y 'outgoing' tocan al servidor, mientras que con Git puedes hacer 'fetch' de toda la información del servidor antes de quedarte sin conexión y hacer comparaciones, merges, y ver logs de todos los datos que están en el servidor aunque no pertenezca a tus ramas locales.
Lo que quiere decir que es muy fácil tener copias de no sólo todas tus ramas, sino también de todas las ramas que los demás que trabajan contigo proyecto hayan ido subiendo al repositorio de Git.
bzr svn perforce
Git is Rápido
Git es rápido. Todo el mundo, hasta los más acérrimos usuarios del resto de sistemas lo reconoce. Esto se debe, comparado con SVN y Perforce, a que todas las operaciones se hacen localmente. Sin embargo cuando se compara con otros SCVs distribuidos, Git también es veloz.
Es posible que esto se deba en buena parte a que fue construido para trabajar en el kernel de Linux, lo que quiere decir que desde el primer día ha tenido que mover de manera efectiva repositorios de gran tamaño. Otra razón es que Git está escrito en C, y otra razón más es que, en mi experiencia, los desarrolladores principales de Git están muy preocupados por la velocidad.
A continuación veremos algunas pruebas que realicé en tres copias del código fuente de django en 3 sistemas diferentes: Git, Mercurial y Bazaar. También hice alguna prueba con SVN, pero creedme cuando os digo que es más lento - básicamente es añadirle la latencia de red a los números de Bazaar.


El resultado final es que para todo menos para añadir nuevos archivos, Git es el más rápido (también commits muy grandes, empatado con Git, pero la entrega que hice era tan grande que es bastante raro que alguna vez tengas que hacer algo parecido - los commits normales son mucho más rápidos en Git)
Git Hg Bzr
Inicialización 0.024s 0.059s 0.600s
Añadir 8.535s 0.368s 2.381s
Status 0.451s 1.946s 14.744s
Diff 0.543s 2.189s 14.248s
Etiquetar 0.056s 1.201s 1.892s
Log 0.711s 2.650s 9.055s
Entrega (Grande) 12.480s 12.500s 23.002s
Entrega (Pequeña) 0.086s 0.517s 1.139s
Rama (en frío) 1.161s 94.681s 82.249s
Rama (en caliente) 0.070s 12.300s 39.411s
Los tiempos de creación de rama en frío y en caliente se corresponden, respectivamente, con el tiempo empleado en la primera y segunda vez que bifurqué el repositorio - de forma que en el segundo caso la rama se hizo con la caché del disco caliente.
Nótese que aunque los números para el añadido de ficheros son mucho más elntos, se trataba de una operación masiva (más de 2000 archivos) Para lo que la mayor parte de la gente hace, el añadir cosas al repositorio sólo lleva una fracción de segundo. El resto de operaciones es bastante más indicativo de las cosas que uno realmente termina haciendo en el día a día.
No es nada difícil volver a generar estas medidas. Simplemente clona el proyecto Django en cada uno de los sistemas e intenta ejecutar los mismos comandos en cada uno
git clone git://github.com/brosner/django.git dj-git
hg clone http://hg.dpaste.com/django/trunk dj-hg
bzr branch lp:django dj-bzr
svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn
svn
Git es Pequeño
Git es realmente hábil a la hora de ahorrar espacio. En general tu repositorio Git será poco más grande que una copia de trabajo de SVN - y en algunos casos es posible que sea más pequeño (parece ser que hay un montón de cosas que acaban en los directorios .svn)
Los siguientes tamaños fueron obtenidos de copias del proyecto Django en cada uno de sus mirrors de Git semi-oficiales en algún punto de su historia.
Git Hg Bzr Bzr* SVN
Sólo el repo 24M 34M 45M 89M
Todo el directorio 43M 53M 64M 108M 61M
* el segundo número de Bzr es después de ejecutar 'bzr pack', que pensé que lo haría más pequeño pero por alguna razón lo hizo mucho mucho más grande.
hg bzr svn perforce
El área de montaje
Al contrario que otros sistemas, Git tiene lo que denomina "área de montaje", o "índice" que es un área intermedia donde puedes configurar lo que contendrá el aspecto que tendrá tu entrega antes de hacer el commit.
Lo mejor del área de montaje, y que marca la diferencia entre git el resto de herramientas, es que puedes fácilmente montar algunos de tus ficheros según terminas con ellos y después entregarlos sin tener que enviar todos los archivos modificados en tu directorio de trabajo y sin tener que listarlos en la línea de comandos durante la entrega.

Esto también te permite preparar sólo fragmentos de archivos que han sido modificados. Por ejemplo, montas para entregar sólo los cambios al principio de un archivo que has estado modificando pero no los cambios del final.
Por supuesto, Git también hace que sea fácil ignorar esta funcionalidad en caso de que no queramos tanto nivel de control - simplemente añade '-a' al commando 'commit'.

svn perforce
Distribuido
Una de las cosas más chulas de cualquier sistema distribuido de control de versiones, incluido Git, es que es distribuido. Esto quiere decir que en lugar de hacer un "checkout" de la punta del código, haces un "clon" del repositorio en su totalidad.
Lo que quiere decir que incluso si trabajas de manera centralizada, cada usuario tiene lo que en esencia es una copia completa del servidor principal, y cualquiera de ellas podría ser recuperada para reemplazarlo en caso de caída o corrupción. Básicamente, no hay un punto de fallo único con git... a no ser que haya un punto único.
Además esto tampoco ralentiza demasiado las cosas. En término medio un checkout de SVN es más rápido que cualquiera de los SCV distribuidos, pero por poco. Además, de entre los sistemas distribuidos git fue el más rápido en mis pruebas.

Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s
svn perforce
Cualquier flujo de trabajo
Una de las cosas que más sorpenden de Git es que debido a su naturaleza distribuida y a su super-sistema de ramas se puede implementar fácilmente prácitcamente cualquier flujo de trabajo que se nos ocurra.
Al estilo Subversion

Una forma de trabajo muy común, especialmente entre aquellos que se pasan de un sistema no distribuido es un flujo de trabajo centralizado. Git no permite hacer subir los cambios al servidor si alguien lo ha hecho desde la última vez que nos bajamos los últimos cambios, de forma que un modelo centralizado donde todos los desarrolladores entregan al mismo servidor funciona sin mayor inconveniente.


Al estilo Responsable de Integración

Otra forma muy común de trabajar con Git es donde exista un Responsable de Integración - una persona que entrega al repositorio 'bendecido', y después un número de desarrolladores se copian ese repositorio y hacen sus cambios en él le piden al integrador que integre sus cambios. Este es el tipo de modelo de desarrollo que se suele usar en repositorios de software abierto o en GitHub.


Al estilo Dictador y Tenientes

En proyectos más grandes, los desarrolladores pueden organizarse de forma similar a como lo hacen en el kernel de Linux, donde hay gente que está a cargo de un subsistema específico del proyecto (los tenientes) e integran todos los cambios que tienen que ver con ese subsistema. Después otro integrador (el dictador) puede recoger los cambios únicamente de sus tenientes y subirlos al repositorio principal el cual todo el mundo vuelve a clonar.


Y de nuevo Git es totalmente flexible en este aspecto de forma que uno puede mezclar y escoger el flujo de trabajo que mejor se adapte a sus necesidades.
hg bzr svn perforce
GitHub

En esto podría ser que yo no sea del todo imparcial porque trabajo en GitHub, pero quiero añadir esta sección de todas formas porque hay mucha gente que afirma que GitHub es la razón por la que escogieron Git.
Y GitHub es para muchos una razón para escoger Git porque se parece más a una red social de código que un mero sitio de alojamiento. Uno se encuentra con otros desarrolladores o proyectos que son similares a lo que está haciendo y es muy fácil bifurcar y contribuir, creándose una comunidad vibrante en torno a Git y los que proyectos en los que la gente lo usa.
Existen otros servicios, tanto para Git como para otros SCVs, pero hay pocos que estén orientados a los usuarios desde un punto de vista social, y ninguno de ellos se acerca al número de usuarios que tiene GitHub. Este aspecto social es decisivo, y esta junto con el resto de funcionalidades de arriba hace que trabajar con Git y GitHub sea una gran combinación para desarrollar rápidamente proyectos de código abierto.
Este tipo de comunidad no está disponible en ninguno de los otros SCVs. Simplemente.
perforce
Fácil de Aprender
Esto solía no ser cierto - en los comienzos de Git no era tanto un sistema de control de versiones como un puñado de herramientas que permitían hacer tareas de sistema de ficheros de manera distribuida. Sin embargo a día de hoy el conjunto de comandos y la curva de aprendizaje de Git son bastante parecidos a la de cualquier SCV, e incluso mejor en algún caso.
Como es difícil probar esto de manera objetiva sin algún tipo de estudio simplemente mostraré las diferencias entre el menú de ayuda por defecto de Mercurial y Git. He resaltado los comandos que son idénticos (o casi) entre los dos sistemas. (En Hg, si escribes 'hg help' te sale una lista de casi 40 comandos)
Ayuda de Mercurial

add add the specified files ...
annotate show changeset informati...
clone make a copy of an existi...
commit commit the specified fil...
diff diff repository (or sele...
export dump the header and diff...
init create a new repository ...
log show revision history of...
merge merge working directory ...
parents show the parents of the ...
pull pull changes from the sp...
push push changes to the spec...
remove remove the specified fil...
serve export the repository vi...
status show changed files in th...
update update working directory
Ayuda de Git

add Add file contents to the index
bisect Find the change that introduce...
branch List, create, or delete branches
checkout Checkout a branch or paths to ...
clone Clone a repository into a new ...
commit Record changes to the repository
diff Show changes between commits, ...
fetch Download objects and refs from...
grep Print lines matching a pattern
init Create an empty git repository
log Show commit logs
merge Join two or more development h...
mv Move or rename a file, a direc...
pull Fetch from and merge with anot...
push Update remote refs along with ...
rebase Forward-port local commits to ...
reset Reset current HEAD to the spec...
rm Remove files from the working ...
show Show various types of objects
status Show the working tree status
tag Create, list, delete or verify...
Antes de la versión 1.6 de Git todos los comandos estaban en el path ejecutable, lo cual confundía a mucha gente. Aunque Git sigue reconociendo todos estos comandos el único comando en el path ahora es 'git'. Así que si uno compara Git con Mercurial tienen un conjunto de comandos y sistema de ayuda muy parecido - hay poca diferencia desde el punto de vista de interfaz de usuario para un principiante.
Hoy es difícil sostener que Mercurial o Bazaar sean mucho más fáciles de aprender que Git.

martes, diciembre 23, 2008

nuevo windows 7

Mocochoft planea que Windows Vista sea uno de los SO más efímeros de
la historia.

¿Qué ofrecerá el nuevo sistema windows7?

Tienen un buen departamento de marketing y ya se les ocurrirá algo
para que no se note que la gente no quiere cambiar a vista, que los
fabricantes no quieren cambiar a vista y que vista no hizo ni un 10%
de lo que prometían cuando empezaron a hablar de él (aunque se retrasó
su fecha de salida muchísimas veces)

Vista tiene pocas novedades y no gustan (pocas y mal paridas)

¿Manejar pantallas táctiles?
¿Eso significa que con un xp o un vista no se podrá hacer? Me
parecería un robo y una estafa.

Ya veremos


La gente que piensa mal dice que windows7 se saca con precipitación
para tapar el gran fiasco de windows vista



http://www.historiasdequeso.es/2008/12/microsoft-extiende-la-vida-de-windows-xp-una-vez-mas.html

Microsoft dijo inicialmente que Windows Xp moriría a finales de este
año, pero el sistema operativo ha obtenido un indulto nuevamente. La
nueva fecha limite para la venta de licencias será el 20 de Mayo del
2009.
Esto tiene que ser difícil para Microsoft. Generalmente cuando
Microsoft lanza al mercado un nuevo sistema operativo, el antiguo deja
de ser protagonista, y es el nuevo el que se pre-instala en las
computadoras y las licencias que suelen venderse son las del sistema
en "lanzamiento". Evidentemente, los usuarios no suelen actualizar
hasta que el nuevo SO de Microsoft lleva al menos un Service Pack, ya
que, casi como norma, el nuevo SO suele ser más inestable y con más
problemas de compatibildad que el anterior.
Esta tendencia ha cambiado con el estrepitoso fracaso comercial de
Vista. Afortunadamente el sistema por lo menos ha llegado a un punto
de usabilidad gracias a su primer SP, pero el hecho es que los
principales fabricantes de PCs siguen ofreciendo Windows Xp y eso
demuestra que el mundo no está muy contento con Windows Vista.
Comparado con su hermano menor, Windows Xp funciona perfectamente bien
en una gran variedad de hardware donde Vista a dia de hoy sigue
teniendo problemas… ¿Quien sabe si Microsoft alargará la muerte de su
querido Windows Xp?
El lanzamiento de Windows 7 está previsto para el 2009, de manera que
Microsoft puede que mantenga Xp vivo hasta la llegada de 7, que seguro
esperan sea el "salvador" de esta situación.

linux y windows en el entorno doméstico

Ejemplo cercano...


A C hace tiempo que no se le rompe windows, y eso es bueno, o quizá es optimista...


Se le ocurre buscar motivos navideños para su ordenador. Busca e instala lucecitas en la pantalla y fondos de pantalla.

Yo ya se lo he explicado, hacer eso es un suicidio, pero no se le ha roto el ordenador.


Aunque el texto de los iconos ahora tienen un borde azul ¿¿?? y no le funciona el doble click.


No tiene claro desde cuando le pasa y mucho menos como "arreglarlo"

También dice que el ordenador ahora le va mucho más lento que antes. Pero eso es normal.


Todo el mundo sabe que según pasa el tiempo los ordenadores van funcionando, pero más lentos. Al final no te queda más remedio que comprar otro.


O al menos todo el mundo que usa windows sabe eso (otro efecto adicional es que cuando envejecen, los ordenadores se paran cuando quieren)

Mi profe de inglés, me contó que su madre no para de comprarse ordenadores y es debido a ese curioso efecto de envejecimiento.

Yo no sé cuanto tiempo tiene mi ordenador de sobremesa (tiene unos cuantos años, más de 3), pero cada vez va más rápido.

Paradójico para un usuario de windows.


Va más rápido porque le puse un disco duro más grande y más rápido (y se nota muchísimo). Y va más rápido porque ahora kde4 y linux en general, van más rápido.


Para que te hagas una idea... en el curro tengo un pentium4 viejo (monoprocesador sin hiperthreading) y tarda en compilar un programa en c++ 4 segundos, pero en enlazarlo tarda 17 segundos.

En casa, con mi viejo amd64 (monoprocesador y sin soporte de virtualización) tarda en compilar lo mismo 4 segundos, pero en enlazar, tarda 3 o 4 segundos (y nunca he defragmentado el disco)


Es curioso, en windows hay gente que se pasa la vida defragmentando el disco y otros recomendando que defragmentes el disco semanalmente. Ya sabes, aumento de rendimiento y esas cosas... (¿has defragmentado alguna vez tu linux? ¿sabías acaso que se puede hacer?)


Pero lo que realmente reduce el rendimiento es la instalación de basura que no se desinstala bien o simplemente no se desinstala. Los antivirus reducen muchísimo el rendimiento, pero nadie lo tiene en cuenta. Y por último, virus, troyanos, rootkits y otras lindezas...


Que cultura esta de windows en la que hasta una de las compañías más grandes y "serias" de la música, te meten rootkits en sus cds de música original y PAGADOS a dicha compañía.


Que curioso que las compañías antivirus supieran que SONY te metía un rootkit y no lo denuciaran, porque era sony ¿¿??


Que mundo este en el que es mejor comprar un disco pirata que uno original (el pirata no tiene rootkits "oficiales", y se puede escuchar en el coche, cosa que en muchos originales no se puede)


Ahora todos consideran normal comprar un ordenador con un sistema PARCIAL. No es bastante con el ordenador y el SO, tienes que comprar al menos un antivirus, que tiene un coste anual permanente.


Es increíble haber llegado a la situación en la que un antivirus es tan imprescindible como el propio ordenador.


Los ordenadores domésticos, windows y los antivirus siguen siendo un fraude.


Hay gente que utiliza su ordenador en menos del 20% por falta de conocimiento.


El timo de "esto es un electrodoméstico, lo enchufas y lo utilizas, es sencillo".


Y la gente sigue comprándose lo último de lo último, lo más caro para llegar en el mejor de los casos al 20% de la potencia de la máquina. Piensan los pobrecicos que cuanto más caro, más tiempo les durará.


Y el negocio de los antivirus es impresinante. Existen muchísimas empresas de antivirus y ganan mucho dinero. ¿Podrá parar esto de los virus alguna vez? Quizá ya esté tomando dimensiones preocupantes, en las que luego cueste mucho eliminar ese negocio.


En principio, un mundo donde no hiciera falta antivirus, parece un mundo mejor, pero con las dimensiones que está tomando este negocio (y sigue creciendo), es posible que luego la gente diga... es necesario los virus, porque sino, ¿que hacemos con todas estas empresas y empleados?


Un caso semejante a las discográficas, el boom de las ventas de coches, el boom de las ventas de casas o el boom de las .com, etc...


Cuando uno es minoría "aplastante" debe plantearse que quizá ese uno está equivocado, pero no siempre es así (¿dónde va vicente? donde val la gente y 400 millones de moscas no pueden estar equivocados, come mierda)


En la situación actual, utilizar windows como sistema doméstico por gente con poco conocimiento (que será más del 90%) es ilógico y muy tonto.


¿Qué ofrece windows?

¿Más estabilidad?

¿Más velocidad?

¿Más herramientas?

¿Más seguridad?

¿Más sencillez?

¿Más...?


No, no, no, no, no...



Sólo ofrece una cosa. Un falso estándar cosechado con técnicas monopolistas que empezaban con permitir y promover la utilización "ilegal" de sus productos.


¿Qué voy a poner? ¿Lo que me recomiende un profesional de la informática que entiende?

O lo que tiene el vecino del cuarto, y el hijo de 12 años del amigo del instituto, y lo que tiene...


curioso y triste


Y esto no lo dice un radical linuxero que no ha visto un windows en su vida. Tengo mucha más experiencia con windows que con linux.


En el trabajo empezamos hace meses un proceso de migración tecnológica que nos debería permitir desarrollar para windows/linux. Me gustaría tener un linux en el escritorio de uno de mis ordenadores del trabajo, con el correo y esas cosas diarias.


No utilizo VisualStudio aunque hay una versión gratis que tiene un autocompletar muy eficaz. No utilizo el compilador de Microchoft ni el que era de borland, aunque hay versiones gratuitas.


En su lugar utilizo productos libres y procuro que además sean multiplataforma.


Hace mucho tiempo empecé a utilizar el Borland Builder C++ y no quiero tener una experiencia semejante en el futuro (incertidumbre en tu herramienta principal de trabajo por incertidumbre en la empresa que la fabrica).

Ahora con C++ estándar y con mucho software libre, estoy mucho más tranquilo. Pero eso es otra historia

domingo, diciembre 21, 2008

git (Linus Torvalds)

Name

Linus Torvalds has quipped about the name “git”, which is British English slang for a stupid or unpleasant person: [7]

I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git.

This self-deprecation is certainly tongue-in-cheek, insofar as Torvalds was actually pressured into naming Linux after himself (see History of Linux).

The official Git wiki also gives a number of alternative explanations for the name, including "Global Information Tracker".[8]


Torvalds had several design criteria:

  1. Take CVS as an example of what not to do; if in doubt, make the exact opposite decision. To quote Torvalds, speaking somewhat tongue-in-cheek:
    “For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company [presumably Transmeta] and I hate it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN (Subversion) users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was ‘CVS done right’, or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.”[29]



miércoles, diciembre 17, 2008

computación cuántica




Hardware para la computación cuántica

Aún no se ha resuelto el problema de qué hardware sería el ideal para la computación cuántica. Se ha definido una serie de condiciones que debe cumplir, conocida como la lista de Di Vinzenzo, y hay varios candidatos actualmente.


 

Condiciones a cumplir en un computador cuántico

  • El sistema ha de poder inicializarse, esto es, llevarse a un estado de partida conocido y controlado.
  • Ha de ser posible hacer manipulaciones a los qubits de forma controlada, con un conjunto de operaciones que forme un conjunto universal de puertas lógicas (para poder reproducir a cualquier otra puerta lógica posible).
  • El sistema ha de mantener su coherencia cuántica a lo largo del experimento.
  • Ha de poder leerse el estado final del sistema, tras el cálculo.
  • El sistema ha de ser escalable: tiene que haber una forma definida de aumentar el número de qubits, para tratar con problemas de mayor coste computacional.
 
O lo que es lo mismo...
 
1* Se debe poder encender
2* Se debe poder programar
3* No se debe estropear continuamente de forma expontánea
4* Se debe obtener un resultado
5* Se debe poder hader más gordo
 
 
En general todos estos puntos son un problema en la computación cuántica, pero también son la base de la computación.
 
Imagina un ordenador que puede hacer algo, pero no cumple alguno de estos 5 puntos.
 
 
 

lunes, diciembre 08, 2008

gimp vs photoshop 4 (cinepaint)


http://www.cinepaint.org/faq.html



CinePaint Frequently Asked Questions
by Robin Rowe

1. What's CinePaint?
CinePaint is a deep paint image retouching tool that supports higher color fidelity than ordinary painting tools.
2. What Platforms run CinePaint?
Linux, FreeBSD, Macintosh (native with GTK+OSX, not X11). The Windows version was withdrawn because it was unstable, but will come back eventually.
3. Where can I download CinePaint?
SourceForge.
4. How do I get CinePaint from CVS?
CVS Linux and CVS Windows.
5. How do I build CinePaint from source?
Building from Source Tarball.
6. Why don't I see any file type but XCF in the image types list when I try to open a file? What happened to JPEG, etc.?
CinePaint isn't finding its plug-ins. (XCF isn't a plug-in.) Change your user preferences setting to point toward CinePaint's plug-ins directory.
7. Did you fork GIMP?
Back in 1998, the film industry employed some GIMP developers to enhance GIMP for 16-bit deep painting. GIMP never released that code. It was called the HOLLYWOOD branch in GIMP CVS and within the film industry it was known as Film Gimp. In 2000, the GIMP project announced a new direction, GEGL. Film Gimp was forgotten. In 2002, I discovered Film Gimp in use at the studio Rhythm & Hues while writing a story for Linux Journal. Readers wrote me for the tarball and started sending me patches. I made the patched code available on SourceForge. Film Gimp was renamed CinePaint and has evolved significantly since.
8. How do I get the film industry to sponsor my software project?
Not a CinePaint question, but something I get asked. In general, there's no chance of selling vaporware to a studio. Vendors beg studios to try their latest software and hardware for free in order to gain future business. Getting a meeting isn't easy. The time of film people is quite valuable, like a doctor or lawyer. It's so competitive that even getting to be an intern working for free at a studio is a challenge. Furthermore, it typically takes about seven years to accomplish much in the film industry. That's the typical cycle to develop and release one major movie. And remember, "Don't call us...we'll call you...."




http://www.cinepaint.org/about.html

About CinePaint

CinePaint is a deep paint image retouching tool that supports higher color fidelity than ordinary painting tools.

CinePaint is used to retouch feature films and in pro photography. CinePaint opens high fidelity image file formats such as DPX, 16-bit TIFF, and OpenEXR, and conventional formats like JPEG and PNG. It has a flipbook for movie playback of image sequences in RAM. It supports 8-bit, 16-bit and 32-bit color channels, HDR and CMS.

CinePaint is used for motion picture frame-by-frame retouching, dirt removal, wire rig removal, render repair, background plates, and painting 3D model textures. It's been used on many feature films, including The Last Samurai where it was used to add flying arrows.

For still photography, CinePaint can import bracketed HDR exposures. It has gallery-quality 16-bit per channel color printing with GutenPrint. CinePaint's high dynamic range is crucial with B&W still photography, where images only have a single channel.

Studio Users

Studios such as Sony Pictures Imageworks and many smaller studios use CinePaint. Disney, DreamWorks, and Pixar funded Crossover (Wine) to make Adobe Photoshop for Windows run nicely on Linux and that's what they use. Some studios use proprietary or internally developed tools. CinePaint is open source software. Nobody is obligated to tell us they use it. Studios use many Linux motion picture applications, not just CinePaint. This list of studios using CinePaint is just some we know about.

What's Special about CinePaint?

CinePaint is fundamentally different from other painting tools because it handles high fidelity image formats such as Kodak Cineon, SMPTE DPX, and ILM-NVIDIA OpenEXR. To do that properly requires a 32-bit per channel color engine core so that data isn't crushed into 8-bit color channels. The CinePaint core is 8-bit, 16-bit, and 32-bit as needed. It's different from GraphicsMagick which also supports different color depths but only as a compile-time switch. (GraphicsMagick has better support for film industry file formats than ImageMagick.)

As with audio editing, more bits is better. That is, provided you understand how to use them. If you can't hear the difference between transistor radio and a studio sound mixer, you may not be able see the difference between CinePaint and ordinary 8-bit paint tools either. If you're a filmmaker or professional photographer then CinePaint may be your best and only choice. Although conventional monitors are limited to 8-bit, output to motion picture film, digital cinema, gallery quality prints, or lithography is capable of significantly better.

So Why Not GIMP?

We get this question a lot. Because CinePaint handles 8-bit images in common image formats such as JPEG, TIFF, and PNG, that makes CinePaint an alternative to ordinary image editing tools. However, CinePaint has fundamentally different design goals from projects like GIMP. We have the interest, expertise, experience, professionalism, and pro users needed when developing successful software for the high-end.

Ever since CinePaint launched as a public project on SourceForge on July 4th, 2002, there's been quite a bit of hostility towards us from GIMP hackers. There seems to be a misconception that we're competitors. In our primary market, the film industry, our position is #2 and Adobe Photoshop is #1. GIMP is practically useless for filmmaking since it can't handle CIN, DPX or EXR files.

GIMP has pursued an architectural overhaul called GEGL that's a very different design from Glasgow. They've been at it since 2000. Glasgow began in 2004.

Is CinePaint a Video Editor?

CinePaint is a deep paint tool that's used for retouching movies, not a movie editor like Avid or Final Cut Pro. Avid Composer, Apple Final Cut Pro, Apple Motion, Adobe After Effects and Apple Shake are all great tools when matched to the task at hand. Our plan for CinePaint includes more features in that direction, but we're far from that now. Nobody should be asking whether CinePaint, or for that matter any other open source project, is about to equal popular movie editing tools. At best the answer is, "not soon". Other Linux studio software.




http://en.wikipedia.org/wiki/CinePaint

gimp vs photoshop 3 (mi modesta opinión)

Hace mucho tiempo que tengo curiosidad no satisfecha con gimp y photoshop (en otras cosas semejantes sí tengo suficiente información)

Estoy hasta las narices de que siempre digan en todos lados retocado con "PhotoShop"

¿Es que no hay otros programas? ¿Es un monopolio?
Sabemos que no siempre los monopolios son por calidad.

Al grano...


He estado leyendo algo de esto por curiosidad.

Siempre oigo hablar de esta guerra pero nunca consigo datos concretos (excepto el soporte de CMYK)

Me llama la atención que krita tenga soporte de más colores (16 y 32 bits por canal o el famoso CMYK y otras cosas). Me sorprende porque krita comparado con gimp es un bebé y gimp tiene una comunidad importante que no tiene krita.
Da la impresión de que gimp no tiene este soporte porque no lo consideran importante


Desde luego que quiero saber las diferencias por curiosidad, porque a mi me sobra con krita y gimp y siempre me sobrará.

He leído alguna cosa que me parece interesante


http://www.askreamaor.com/image-and-graphics/7-reasons-why-gimp-vs-photoshop-is-the-stupidest-flamewar-in-history/

En esta página dice que comparar y discutir gimp con photoshop es una tontería.
Me parece una idea muy interesante. Es posible que, como dicen esta página, no sean comparables porque son programas diferentes con objetivos diferentes.
GIMP no es ni pretende ser un Photoshop. Eso me parece interesante y revelador.




http://www.askreamaor.com/image-and-graphics/gimp-vs-photoshop/

En esta otra, dicen que la diferencia entre gimp y photoshop en cuanto a funcionalidades y cosas que pueden hacer es mínima y casi inexistente.
Afirman que la razón por la que gimp no reemplaza photoshop, es porque el interfaz de gimp es muy diferente y más incómodo para "artistas".
En muchos sitios dicen que el interfaz de gimp está mejor pensado para su objetivo. De hecho hay un gimpshop, que es el gimp con un interfaz de photoshop y no gusta mucho (nada en la comunidad gimp).

El problema que plantean es... Los diseñadores y artistas aprenden photoshop. Odian aprender como funciona y es algo que no están dispuestos a hacer nunca más.
Entonces oyen hablar de gimp, ven que tiene un interfaz diferente, lo odian y nunca le dan una oportunidad.
También afirman que el interfaz de gimp está más pensado para "geeks" y los diseñadores no lo son. Más o menos dicen que un entendido de gimp es capaz de hacer lo mismo y de formas más eficientes que otros de photoshop.
Este argumento se parece al de emacs y vi

Yo estoy convencido de que emacs es un programa fantástico. De que tiene una curva de aprendizaje dura. Y sobre todo, de que alguien que sepa manejar emacs, está en un nivel muy superior y es muchísimo más eficiente que alguien que maneje visual estudio, eclipse o similares. Pero eso es otra historia aunque el argumento es parecido.

Parece que photoshop se programa en scheme (plugins, macros, efectos y cosas así), que es un tipo de LISP. LISP probablemente es el mejor lenguaje de programación general, pero es poco popular incluso entre informáticos.



Más o menos mi conclusión es que para casi todo el mundo, GIMP es la mejor opción (e incluso krita).

Pero en este tema no tengo tantos datos como en BBDD (oracle, mokochoft sql server, sybase, db2, posgresql, mysql y firebird)


Ya me contarás como lo ves




Me olvidaba de una cosa interesante.

Estas otras páginas...

http://www.cinepaint.org/about.html
http://www.cinepaint.org/faq.html
http://en.wikipedia.org/wiki/CinePaint

Este es un programa para profesionales que compite con photoshop.

Y como verás hay profesionales, muy profesionales, que utilizan este
programa en vez de photoshop.

Este programa es un "fork" de GIMP (de hace tiempo)


Observa también que llegan a asegurar que la razón fundamental de la
existencia y evolución de wine (o de crossover) es que algunos
estudios querían un photoshop decente en linux. Y como adobe no lo
saca para linux, lo hacen por el camino indirecto. Interesante.

gimp vs photoshop 2

http://www.askreamaor.com/image-and-graphics/7-reasons-why-gimp-vs-photoshop-is-the-stupidest-flamewar-in-history/

7 Reasons Why Gimp vs Photoshop is the Stupidest Flamewar in History



1. It’s gone on long enough. A Google search for “Gimp vs Photoshop” in quotes currently shows 23,400 hits. I’ve been seeing it since the turn of the century. Much more often than I’ve seen the canonical geek flamewars of Emacs-vs-vi, Gnome-vs-KDE, and all.

2. The Gimp development team says that Gimp has nothing to do with Photoshop. As recently as Gimpcon 2006, the development team has stated “What GIMP is not: GIMP is not MS Paint or Adobe Photoshop”. They’ve had that on their home page for many versions. They also state on that same page:

…If someone comes with the request that the UI of GIMP should be like Photoshop, we can simply state: ?We are not trying to be like Photoshop, because we have a different product vision.? …

3. The Gimp development team also affirms that Gimp targets experienced users. That is another reference from the Gimpcon 2006 page. Worth bearing in mind: A lot of FOSS programs are the sophisticated tools that sophisticated users need to do what they do.

Yes, true, the development team also looks at feature requests and considers including them, but not just because Photoshop has it. They state in their TODO list that they are looking to provide a UI with a low barrier to entry, but that doesn’t mean ‘make it more like Photoshop’.

4. We already tried turning Gimp into Photoshop. It doesn’t work. Here’s Gimpshop. To quote their front page:

It shares all GIMP’s advantages, including the long feature list and customisability, while addressing some common criticisms regarding the program’s interface: GIMPshop modifies the menu structure to closely match Photoshop’s, adjusts the program’s terminology to match Adobe’s, and, in the Windows version, uses a plugin called ‘Deweirdifier’ to combine the application’s numerous windows in a similar manner to the MDI system used by most Windows graphics packages.

There you have it! It’s been there for years. So what’s up? Why are FOSS users not thundering all over to Gimpshop? Why aren’t Photoshop users snapping it up? Why do Linux distros keep including Gimp instead of Gimpshop? Because, like trying to write Visual Basic in C, trying to convert a Volkswagon into a Ferrari, and trying to come up with a recipe for chicken that will make it taste like sirloin steak, trying to stuff a Gimp into a Photoshop’s mold really isn’t a practical thing to do. You always end up with the worst of both worlds.

Or, as this unsung genius observes in a Lisp/Scheme discussion:

It is some aspect of the “let’s discard all the community effort and start
over from scratch because we’re smarter than everybody else” thing.

Each and every time someone in the Computer Science field has a Bright Idea,
the world had better be prepared to adapt, because Here Comes Genius and
everything everybody has done needs to be done differently from now on,
because This Genius Knows Best.

5. Gimp isn’t even the only game in town. There’s dozens of FOSS graphics applications out there. Here’s just a part of them. Amongst the simpler drawing utilities out there are Tuxpaint, a drawing program for kids, Xpaint, a very old-school Unix graphics application, and Inkscape, the vector-graphics editor. Inkscape is often overlooked; while being a vector graphics editor (as opposed to raster graphics, which is what Gimp is), it can be used to make many of the kinds of images that people complain that they can’t do in Gimp. 99% of the frustration people have with Gimp (the genuine frustration - see next point) comes from using the wrong tool.

Graphics editing is huge, and even Adobe doesn’t try to make one tool do everything! It is simply ridiculous to expect that you should make 16×16 icons and 3D special effects for a blockbuster movie with the same tool.

6. Gimp is just a straw-man to the trolls. Case in point: CMYK. Next time you see somebody on Digg or Slashdot complaining that Gimp doesn’t support CMYK… challenge them! Find out if they even know what it stands for and what it does. Unless you work in the printing industry (like, you design the cover of Vogue), CMYK means nothing to you. CMYK is just the letters the flamers have learned to type from seeing how other flamewars went.

If you’re actually dealing with someone who would need CMYK, refer them again to the What Gimp is… section. Let’s see, there’s “high-end photo manipulation”, “creating original art”, “producing icons, graphical elements of web pages, and art for user interface elements”, “programming cutting edge image processing algorithms”… no, it doesn’t ever claim to be for printing. So, complaints that Gimp doesn’t support CMYK are just as relevant as saying it doesn’t pick winning lottery numbers for you.

Another case in point: Pantone colors. As the talk page for Gimp educates us, Pantone’s name is trademarked, the numbers of the colors are copyrighted, and supporting it by paying the exorbitant fee to license it would render it no longer freely distributable software. This is akin to complaining that Wendy’s doesn’t serve Big Macs.

In fact, I have rarely encountered an anti-Gimp flamer online without the following conditions being true of them:

  1. Their user ID is brand new.
  2. They have no website.
  3. They have no portfolio.
  4. They couldn’t even be bothered to add an icon/avatar to their ID.
  5. They lack basic, beginner-level knowledge of graphic design. Can’t tell a vector from a raster or a serif font from a sans-serif. They make goofs like saying “an animated jpg”.

Now, I’m sure there’s exceptions to this rule out there somewhere. This is just what I’ve encountered, and I hang out on all of the major social websites. If there’s any actual employed graphic designers out there flaming about Gimp, they’re the exception, not the rule.

7. Microsoft isn’t the only evil proprietary software company. After all, Adobe has been vying to monopolize content production since the beginning. Like Microsoft, they don’t make most of their technology, they just buy it from somebody else. Yes, as that link says, the software that became Photoshop was originally free shareware. Netscape vs Internet Explorer(Mosaic), round two, anybody?

Like Microsoft, they alternate between trying to crush the rest of the market and forming shaky alliances in pursuit of goal #1. Abode Systems only broke their first billion in 1999, but have since rocketed towards the Fortune 500 (current ranking: 727, up from last year’s 817) based on revenue from - surprise! - a lot of buyouts. Like Microsoft, they have clutched a patent portfolio and sued or threatened to sue competitors before. Take a good look at Microsoft, because that’s what Adobe wants to look like in ten years.

The upshot is, Adobe has, of course, had animosity towards free and open source software. They have expressed as much, even to saying they see Linux and GNU as a threat. Considering that the shelf price of their flagship software is more than most people pay for their computer, I guess that’s pretty obvious. So, duh! of course they’d be eager to see the Gimp-vs-Photoshop flame war go on and on. If your multi-billion-dollar creative suite only had one competitor - a unique situation in itself - and it was all free/libre software, you wouldn’t rest easy, either.

Furthermore, what we’re really seeing is anger and frustration at Adobe which is then being redirected at Gimp for not being a free Photoshop clone. It simply is not Gimp’s fault that Adobe’s attitude towards their customer base ranges from lack of respect to downright hostile.

Nevertheless, it is a completely artificial flame war. People who really want to use Photoshop use it; no one is stopping them besides Adobe itself with its high price tag and restrictive licensing. People who don’t, use something else, and we develop the capabilities of that something else as best we can, given the patent minefield.

I’ve heard it pointed out that Gimp has one of the smallest developer teams in ratio to their user base. In other words - big surprise! - lots of complaining out there, very little coding anywhere. In the end, you still get what you pay for, so there’s no comparing the highest-cost graphics suite with the lowest-cost one anyway.

gimp vs photoshop

http://www.askreamaor.com/image-and-graphics/gimp-vs-photoshop/


Do you want to edit bitmap images on the home desktop? It’s surprising, but really the choice of image editing applications comes down to just two: Gimp and Photoshop. And therein lies a dilemma.

Photoshop costs around $600 these days, and Gimp is free, so of course if cost is a factor you’re going to swerve towards Gimp. But - and you knew there was a ‘but’ coming - it’s not that simple. Photoshop has two leads over Gimp: (1) patented features, and (2) the interface that everyone is used to. Most especially, Gimp is out of the running for professional print shop editing, thanks to the patent lock on industrial features such as color correction and CMYK. Gimp can emulate these features with work-arounds, or it can get sued, and that’s all there is to it.

A common misconception is that Gimp lacks many more features that Photoshop has. In fact, with the exception of features that depend on patented algorithms, Gimp is 99% on par with Photoshop in capabilities. It’s just that Photoshop users try Gimp, are immediately lost in the baroque interface, and leave in terror. Having the features doesn’t do you much good if you can’t find them!

That’s the real hanger is the user interface. Unlike other professions which happen to take place on a computer, graphics artists are almost never geeks. Geeks explore an interface, practice with it, read the manual on it, and when they discover the scripting language buried within (Gimp has scheme), they’re bowled over at how cool it is. Graphics artists aren’t like that. They’re right-brained all the way; they’re here to draw, not write programs. And when they learn one way to make the computer do what they want, that’s a sacrifice of time which they can never again be asked to do. Learning a new interface is painful for anybody, but it seems to be simply unacceptable for the graphics artist.

For instance, let’s say you want to draw a beard on a face. In both Photoshop and Gimp it is straight-forward enough to create a custom brush shaped like a few hair follicles. But to draw the beard on and have it come out looking like natural hair, in Photoshop you would open the brush dialog and change the shape and color dynamics, tweaking switches and knobs in each and setting them to randomize. In Gimp, however, you would create a layered brush (called an “image pipe”) which is similar to how you would do an animated gif, then just tell it to use the brush layers in random order. You could manually set up the brush layers to be lighter, darker, and rotated and resized - in effect giving yourself more control over the final effect. It is possible to get the exact same effect in both programs, with even some room to argue that one result looks better than the other.

But what good is that going to do if you’re used to the Photoshop interface? Nothing. In a nutshell, Photoshop is for linear thinkers, and Gimp is for lateral thinkers. Both of them can arrive at very nearly the same result, so close that it’s a neck and neck race. Bottom line, for website graphics and simple editing jobs it’s almost insane to spend the money to use Photoshop. And Gimp is likewise inadequate for the needs of a professional print shop.

Unless, of course, you’re already a geek. Then it won’t matter, because you learn new programs just for fun anyway. The only problem with that is… have you ever met a geek with good artistic skills?

miércoles, diciembre 03, 2008

Sobre la crueldad de verdaderamente enseñar ciencias de la computación




Edsger W. Dijkstra.

La segunda parte de esta charla denota algunas de las consecuencias científicas y educacionales provenientes de la idea de que las computadoras representan una novedad radical. Para darle contenidos claros a esta asunción, tenemos que ser mucho más precisos acerca de lo que queremos decir en este contexto con el uso del adjetivo "radical". Lo haremos en la primera parte de esta charla, en la cual vamos a proveer evidencia que respalde nuestra suposición.

La manera usual en la cual hoy planificamos para el mañana es en el vocabulario de ayer. Lo hacemos porque tratamos de avanzar con los conceptos que nos son familiares, los cuales han adquirido un significado en nuestra experiencia pasada. Por supuesto, las palabras y los conceptos no encajan precisamente porque nuestro futuro difiere de nuestro pasado, pero las estiramos un poco. Los lingüistas están bastante familiarizados con el fenómeno en el cual los significados de las palabras evolucionan a través del tiempo, pero también saben que este es un proceso lento y gradual.

Es el método más común cuando se trata de lidiar con la novedad: utilizando metáforas y analogías tratamos de vincular lo nuevo con lo viejo, lo novedoso con lo familiar. Bajo un cambio suficientemente lento y gradual, esto funciona razonablemente bien; en el caso de una discontinuidad aguda, sin embargo, el método colapsa: aunque podemos glorificarlo con el nombre "sentido común", nuestra experiencia pasada ya no es más relevante, las analogías se tornan muy superficiales, y las metáforas se hacen engañosas en vez de reveladoras. Esta es la situación que caracteriza a la novedad "radical".

Lidiar con una novedad radical requiere un método ortogonal. Uno debe considerar su propio pasado, las experiencias recogidas, y los hábitos formados en él como un desafortunado accidente de la historia, y debe acercarse a la novedad radical con la mente en blanco, rechazando conscientemente el intento de vincularla con lo que ya es familiar, debido a que lo familiar es desesperanzadamente inadecuado. Uno debe, con una especie de personalidad dividida, tomar una novedad radical como algo desasociado por propio derecho. Comprender una novedad radical implica crear y aprender un lenguaje extraño, el cual no puede ser traducido a nuestra lengua materna. (Cualquiera que haya aprendido mecánica cuántica sabe a lo que me refiero.) No hace falta decirlo, ajustarse a las novedades radicales no es una actividad muy popular, ya que requiere mucho trabajo. Por la misma razón, las novedad radicales no son por sí mismas bienvenidas.

A esta altura, bien se pueden preguntar por qué he prestado tanta atención y he gastado tanta elocuencia en una noción tan simple y obvia como una novedad radical. Mi razón es muy simple: las novedades radicales son tan perturbantes que tienden a ser suprimidas o ignoradas, al punto que la mera posibilidad de su existencia es generalmente negada antes que admitida.

Voy a ser breve en cuanto a la evidencia histórica. Carl Friedrich Gauss, el Príncipe de los Matemáticos pero algo cobarde, sin duda estaba al tanto del destino de Galileo –y probablemente podría haber predicho las acusaciones a Einstein– cuando decidió suprimir su descubrimiento de la geometría no Euclidiana, dejando que Bolyai y Lobatchewsky recibieran las críticas. Es probablemente más revelador ir un poco más atrás, a la Edad Media. Una de sus características era que "razonar mediante analogías" era descontrolado; otra característica era el total estancamiento intelectual, y ahora vemos porque ambas características van juntas. Una razón para mencionar esto es resaltar que, desarrollando un oído entrenado para las analogías no garantizadas, uno puede detectar una gran cantidad de pensamiento medieval hoy en día.

La otra cosa que no puedo resaltar lo suficiente es que la fracción de la población para la cuál el cambio gradual parece ser cualquier cosa menos el único paradigma de la historia es muy grande, probablemente mucho más grande de lo que esperarían. Ciertamente cuando comencé a observarlo, su número resultó ser mucho mayor de lo que esperaba.

Por ejemplo, la gran mayoría de la comunidad matemática nunca ha confrontado la suposición tácita de que hacer matemáticas va a continuar siendo básicamente el mismo tipo de actividad mental que siempre ha sido: los nuevos temas vendrán, florecerán, e irán como lo han hecho en el pasado, pero siendo lo que es el cerebro humano, nuestras formas de enseñar, aprender, y el entendimiento las matemáticas, la resolución de problemas y el descubrimiento matemático van a continuar siendo básicamente lo mismo. Herbert Robbins expone claramente por qué él descarta un salto cuántico en la habilidad matemática:

"Nadie va a correr 100 metros en cinco segundos, sin importar cuánto se invierta en entrenamiento y máquinas. Lo mismo puede decirse acerca del uso del cerebro. La mente humana no es diferente ahora de lo que era hace cinco mil años. Y cuando se trata de matemáticas, debe darse cuenta de que se trata de la mente humana a un extremo límite de su capacidad".

Mi comentario en el margen fue "¡entonces reduzca el uso del cerebro y calcule!". Usando la propia analogía de Robbins, uno puede resaltar que, para ir rápido desde A hasta B, podrían existir ahora alternativas a la de correr que son órdenes de magnitud más efectivas. Robbins rechaza de llano honrar cualquier alternativa al valioso uso del cerebro llamado "hacer matemáticas", exorcizando así el peligro de la novedad radical mediante el simple método de ajustar sus definiciones a sus necesidades: simplemente por definición, las matemáticas continuarán siendo lo que solían ser. Demasiado para los matemáticos.

Déjenme darles un ejemplo más de la desconfianza generalizada sobre la existencia de las novedades radicales y, por consiguiente, de la necesidad de aprender cómo lidiar con ellas. Es el accionar educacional que prevalece, para el cuál el cambio, casi imperceptible, parece ser el paradigma exclusivo. ¡Cuántos textos educacionales no son recomendados porque apelan a la intuición del estudiante! Constantemente tratan de presentar todo aquello que podría ser una emocionante novedad como algo tan familiar como sea posible. Conscientemente tratan de vincular el material nuevo con lo que se supone es el mundo familiar del estudiante. Ya empieza con la enseñanza de la aritmética. En vez de enseñar 2 + 3 = 5, el horrendo operador aritmético "más" es cuidadosamente disfrazado llamándolo "y", y a los pequeños niños se les dan muchos ejemplos familiares primero, con objetos claramente visibles como manzanas y peras, que lo son, en contraste al uso de objetos numerables como porcentajes y electrones, que no lo son. La misma tonta tradición es reflejada a nivel universitario en diferentes cursos introductorios de cálculo para los futuros físicos, arquitectos, economistas, cada uno adornado con ejemplos de sus respectivos campos. El dogma educacional parece ser que todo está bien siempre y cuando el estudiante no se dé cuenta de que está aprendiendo algo verdaderamente nuevo; generalmente, el presentimiento del estudiante es de hecho correcto. Considero como un serio obstáculo la falencia de una práctica educativa en preparar a la próxima generación para el fenómeno de novedades radicales. [Cuando el Rey Fernando visitó la conservadora universidad de Cervera, el Rector orgullosamente aseguró al monarca con las palabras: "Lejos esté de nosotros, Señor, la peligrosa novedad de pensar". Los problemas de España en el siglo que siguió justifican mi caracterización del problema como "serio"]. Demasiado para la adopción por parte de la educación del paradigma de cambio gradual.

El concepto de novedades radicales es de importancia contemporánea ya que, mientras estamos mal preparados para lidiar con ellas, la ciencia y la tecnología no se han mostrado expertas en influirlas sobre nosotros. Ejemplos científicos antiguos son la teoría de la relatividad y la mecánica cuántica; ejemplos tecnológicos modernos son la bomba atómica y la píldora. Durante décadas, los primeros dos ejemplos dieron lugar a un torrente de corrientes religiosas, científicas o de otra manera cuasi-científicas. Día a día podemos observar el profundo error de enfoque con el cuál los últimos dos ejemplos han sido abordados, ya sea por nuestros políticos y líderes religiosos o por el público en general. Demasiado para el daño hecho a nuestra paz mental por las novedades radicales.

Traje esto a colación debido a mi convencimiento de que las computadoras automáticas representan una novedad radical y de que sólo identificándolas como tal podemos identificar todo lo irrelevante, los conceptos errados y la mitología que las rodea. Una inspección más a fondo revelará que esto es todavía peor, a saber, que las computadoras automáticas engloban no sólo una novedad radical sino dos de ellas.

La primera novedad radical es una consecuencia directa del poder bruto de las computadoras actuales. Todos sabemos como lidiar con algo tan grande y complejo; divide y vencerás, por ejemplo vemos el todo como una composición de partes y tratamos con las partes por separado. Y si una parte es muy grande, repetimos el procedimiento. La ciudad está compuesto por barrios, que están a su vez estructurados por calles, que contienen edificios, que están hechos de paredes y pisos, que están construidas de ladrillos, etc. eventualmente llegando a las partículas elementales. Y tenemos a todos nuestros especialistas sobre el tema, desde el ingeniero civil, pasando por el arquitecto hasta el físico de estado sólido y consiguientes. Ya que, en cierto sentido, el todo es "mas grande" que sus partes, la profundidad de una descomposición jerárquica es algún tipo de logaritmo del cociente entre los "tamaños" del todo y las partes más pequeñas. Desde un bit a cien mega bytes, desde un microsegundo a media hora de cómputos nos confronta con un cociente completamente abrumador de 10^9! El programador está en la posición inigualada en la cual la suya es la única disciplina y profesión donde un cociente tan gigante, lo cual completamente sobrepasa nuestra imaginación, debe ser consolidado por una sola tecnología. Debe poder pensar en términos de jerarquías conceptuales que son mucho más profundas que todas aquellas que debió enfrentar una sola mente alguna vez. Comparado con ese número de niveles semánticos, la teoría matemática promedio es casi plana. Evocando la necesidad de profundas jerarquías conceptuales, la computadora automática nos confronta con un radical desafío intelectual que no tiene precedente histórico.

Nuevamente, debo enfatizar esta novedad radical ya que el verdadero creyente en el cambio gradual y las mejoras incrementales no puede verla. Para él, una computadora automática es algo como una familiar caja registradora, sólo que algo más grande, rápida y más flexible. Pero la analogía es ridículamente superficial: es órdenes de magnitud peor que comparar, como un medio de transporte, el avión supersónico con un bebé que gatea, ya que el cociente de velocidad es sólo de mil.

La segunda novedad radical es que la computadora automática es nuestro primer dispositivo digital de gran escala. Tuvimos un par de notables componentes discretos: Acabo de mencionar la caja registradora y podemos agregar la máquina de escribir con sus teclas individuales: con un sólo golpe podemos escribir puedes escribir una Q o una W pero, aunque las teclas están una al lado de la otra, no una mezcla de las dos. Pero tales mecanismos son la excepción, y la amplia mayoría de nuestros mecanismos son vistos como dispositivos analógicos cuyo comportamiento sobre un amplio rango es una función continua de todos los parámetros involucrados: si presionamos la punta del lápiz un poco más fuerte, obtenemos una línea levemente más gruesa, si el violinista ubica su dedo levemente fuera de su posición correcta, reproduce una nota levemente desafinada. A esto debería agregar que, al punto que nos vemos como mecanismos, nos vemos primordialmente como dispositivos analógicos: si nos esforzamos un poco más esperamos rendir un poco más. A menudo el comportamiento no es solamente una función continua sino también monótona: para ver si un martillo es adecuado sobre un cierto rango de clavos, lo probamos con el más pequeño y el más grande de los clavos del rango, y si el resultado de ambos experimentos es positivo, estamos perfectamente predispuestos a creer que el martillo será apropiado para todos los clavos intermedios.

Es posible, inclusive tentador, ver a un programa como un mecanismo abstracto, como alguna clase de dispositivo. Pero hacerlo, sin embargo, es altamente peligroso: la analogía es muy superficial debido a que un programa es, como mecanismo, totalmente diferente de todos los familiares dispositivos analógicos con los cuáles crecimos. Como toda la información digitalizada, tiene la inevitable e incómoda propiedad de que la menor de las posibles perturbaciones –por ejemplo cambios a un sólo bit– puede tener las más drásticas consecuencias. [Por completitud agrego que la situación no cambia en su esencia por la introducción de la redundancia o la corrección de errores]. En el mundo discreto de la computación, no hay métrica significativa en la cual "pequeños" cambios y "pequeños" efectos vayan de la mano, y nunca los habrá.

Esta segunda novedad radical comparte el destino usual a todas las novedades radicales: es negada, porque su verdad sería demasiado incómoda. No tengo idea lo que esta negación y descreencia específica le cuesta a los Estados Unidos, pero un millón de dólares al día parece una modesta estimación.

Habiendo descripto –en los términos más amplios posibles, lo admito– la naturaleza de las novedades computacionales, debo ahora proveer la evidencia de que tales novedades son, de hecho, radicales. Lo haré explicando una serie de fenómenos que de otra manera serían extraños por la frustrante –pero, como ahora sabemos, condenada– ocultación o negación de su aterradora extrañeza.

Cierta cantidad de estos fenómenos han sido agrupados bajo el nombre de "Ingeniería de Software". Así como la economía es conocida como "La Ciencia Miserable", la ingeniería de software debería ser conocida como "La Disciplina Condenada", condenada porque ni siquiera puede acercarse a su meta, dado que la misma es en sí misma contradictoria. La ingeniería de software, por supuesto, se presenta a sí misma como otra causa valiosa, pero es un colirio: si lee cuidadosamente su literatura y analiza lo que realmente hacen quienes se avocan a ella, descubrirá que la ingeniería de software ha adoptado como su estatuto "Cómo programar si usted no puede".

La popularidad de su nombre es suficiente para hacerla sospechosa. En lo que denominamos "sociedades primitivas", la superstición de que conocer el verdadero nombre de alguien otorga un poder mágico sobre él no es inusual. Difícilmente somos menos primitivos: ¿por qué persistimos en contestar el teléfono con el poco útil "hola" en vez de nuestro nombre? Tampoco estamos por encima de la primitiva superstición de que podemos tener cierto control sobre algún demonio malicioso desconocido llamándolo por un nombre seguro, familiar e inocente, tal como "ingeniería". Pero esto es totalmente simbólico, así como demostró uno de los fabricantes de computadoras de los EE.UU. hace unos años cuando contrató, una noche, cientos de nuevos "ingenieros de software" mediante el simple mecanismo de elevar a todos sus programadores a ese exaltante rango. Demasiado para ese término.

La práctica está impregnada de la confortable ilusión de que los programas son simplemente dispositivos como cualquier otro, la única diferencia que se admite es que su fabricación pueden requerir un nuevo tipo de expertos, a saber: programadores. Desde allí hay sólo un pequeño paso hasta medir la "productividad del programador" en términos de la "cantidad de líneas producidas por mes". Esta es una unidad de medida muy costosa, porque anima a escribir código insípido, pero hoy estoy menos interesado en qué tan tonta es una unidad, aún desde un punto de vista puramente empresarial. Mi punto hoy es que, si deseamos contar líneas de código, no deberíamos verlas como "líneas producidas", sino como "líneas gastadas": el sentido común actual es tan tonto como contabilizar esa cuenta del lado erróneo del balance.

Además de la noción de productividad, también el control de calidad sigue estando distorsionado por la confortable ilusión de que funciona con otros aparatos como lo hace con los programas. Han pasado ya dos décadas desde que se señaló que el testing de programas puede convincentemente demostrar la presencia de errores, pero nunca puede demostrar su ausencia. Después de citar devotamente este comentario bien publicitado, el ingeniero de software vuelve al orden del día y continúa refinando sus estrategias de testing, tal como el alquimista de antaño, quien continuaba refinando sus purificaciones crisocósmicas.

Un profundo malentendido es luego revelado por el término "mantenimiento de software", como resultado del cual muchas personas siguen creyendo que los programas –e inclusive los mismísimos lenguajes de programación– están sujetos a desgaste y ruptura. Su auto también necesita mantenimiento, ¿no es así? Es famosa la historia de la empresa petrolera que creía que sus programas PASCAL no durarían tanto como sus programas FORTRAN "porque PASCAL no estaba mantenido".

En el mismo sentido debo llamar la atención sobre la sorprendente facilidad con que se ha aceptado la sugerencia de que los males de la producción de software de deben, en gran medida, a la falta de "herramientas de programación" apropiadas. (Pronto aparecería la frase "banco de trabajo del programador".) Nuevamente, la chatura de la analogía subyacente se debe a la Edad Media. Las confrontaciones con las insípidas "herramientas" del tipo de "animación de algoritmos" no ha suavizado mi juicio; por el contrario, ha confirmado mi sospecha inicial de que estamos tratando principalmente con otra dimensión del negocio del aceite de serpientes.

Finalmente, para corregir la posible impresión de que la inhabilidad de enfrentar la novedad radical está confinada al mundo industrial, déjenme ofrecerles una explicación de la –al menos americana– popularidad de la Inteligencia Artificial. Uno esperaría que la gente se sintiera aterrorizada por los "cerebros gigantes de máquinas que piensan". De hecho, la atemorizante computadora se vuelve menos atemorizante si es utilizada solamente para simular una no-computadora que nos es familiar. Estoy seguro de que esta explicación seguirá siendo controvertida por bastante tiempo, dado que la Inteligencia Artificial como imitadora de la mente humana prefiere verse a sí misma como a la vanguardia, mientras mi explicación la relega a la retaguardia. (El esfuerzo de utilizar máquinas para imitar la mente humana siempre me ha parecido bastante tonto: las usaría para imitar algo mejor.)

Hasta aquí la evidencia de que las novedades computacionales son, de hecho, radicales.

Y ahora viene la segunda –y más difícil– parte de mi charla: las consecuencias educativas y científicas de lo anterior. Las consecuencias educativas son, por supuesto, las más engorrosas, por lo tanto pospongamos su discusión y quedémonos mientras tanto con las ciencias de la computación en sí mismas. ¿Qué es la computación? ¿Y de qué se trata la ciencia de la computación?

Bien, una vez que todo está dicho y hecho, la única cosa que las computadoras pueden hacer por nosotros es manipular símbolos y producir resultados de tales manipulaciones. De nuestras observaciones previas, deberíamos recordar que este es un mundo discreto y, más aún, tanto los números como los símbolos involucrados así como la cantidad de manipulaciones realizadas son varios órdenes de magnitud mayores que los que podemos concebir: desconciertan totalmente nuestra imaginación y por lo tanto no debemos tratar de imaginárnoslos.

Pero antes de que una computadora esté lista para realizar alguna clase de manipulación con sentido –o cálculo, si se prefiere– debemos escribir un programa. ¿Qué es un programa? Varias respuestas son posibles. Podemos ver a un programa como lo que transforma una computadora de propósito general en un manipulador de símbolos de propósito específico, y lo hace sin necesidad de cambiar un solo cable (Esto fue una enorme mejora respecto de las máquinas con paneles de cables dependientes del problema.) Prefiero describirlo de la otra manera: un programa es un manipulador de símbolos abstracto, que puede convertirse en uno concreto suministrándole una computadora. Después de todo, el propósito de los programas ya no es más instruir a nuestras máquinas; en estos días, el propósito de las máquinas es ejecutar nuestros programas.

Por lo tanto, tenemos que diseñar manipuladores de símbolos abstractos. Todos sabemos cómo se ven: se ven como programas o –para usar una terminología más general– usualmente fórmulas de algún sistema formal un tanto elaboradas. Realmente ayuda ver a un programa como una fórmula. Primero, pone la tarea del programador en la perspectiva correcta: tiene que derivar esa fórmula. Segundo, explica por qué el mundo de las matemáticas ha ignorado el desafío de la programación: los programas eran fórmulas mucho más largas que las usuales, al punto que ni siquiera las reconocieron como tales. Ahora, de vuelta al trabajo del programador: tiene que derivar esa fórmula, tiene que derivar ese programa. Sabemos de una única forma confiable de hacerlo, mediante la manipulación de símbolos. Y ahora el círculo está cerrado: construimos nuestros manipuladores de símbolos mecánicos mediante la manipulación de símbolos humana.

Por lo tanto, la ciencia de la computación está –y siempre estará– relacionada con la interacción entre la manipulación de símbolos mecanizada y humana, usualmente llamadas "computación" y "programación", respectivamente. Un beneficio inmediato de esta visión es que revela a la "programación automática" como una contradicción en términos. Un beneficio posterior es que nos da una clara indicación acerca de dónde ubicar la ciencia de la computación en el mapa de las disciplinas intelectuales: en la dirección de la matemática formal y la lógica aplicada, pero finalmente mucho más allá de donde se encuentra actualmente, dado que la ciencia de la computación se interesa en el uso efectivo de los métodos formales en una escala mucho, mucho mayor de la que hemos sido testigos hasta ahora. Dado que ningún emprendimiento es respetable por estos días sin una STL (Sigla de Tres Letras) propongo que adoptemos para la ciencia de la computación IMF (Iniciativa de los Métodos Formales), y, para estar del lado seguro, mejor sigamos los brillantes ejemplos de nuestros líderes y hagamos de ella una Marca Registrada.

En el largo plazo espero que la ciencia de la computación trascienda a sus disciplinas padres, matemática y lógica, efectivamente realizando una parte significativa del Sueño de Leibniz de proveer un cálculo simbólico como una alternativa al razonamiento humano. (Por favor, note la diferencia entre "imitar" y "proveer una alternativa a": a las alternativas se les permite ser mejores.)

De más está decirlo, esta visión acerca de qué trata la ciencia de la computación no es universalmente aplaudida. Por el contrario, ha encontrado oposición –y a veces hasta violenta– desde todo tipo de direcciones. Menciono como ejemplos:

(0) la comunidad matemática, que quisiera continuar creyendo que el Sueño de Leibniz es una ilusión irreal

(1) la comunidad empresarial, quienes, habiéndoseles vendido la idea de que las computadoras harían la vida más simple, no están mentalmente preparados para aceptar que sólo resolvieron los problemas más simples al precio de crear uno mucho más difícil

(2) la subcultura del programador compulsivo, cuya ética prescribe que una idea tonta y un mes de codificación frenética deberían bastar para hacerlo millonario de por vida

(3) los ingenieros en computación, quienes quisieran continuar actuando como si fuera solamente cuestión de mayor flujo de bits o más flops por segundo

(4) la milicia, quienes están hoy totalmente absorbidos por el negocio de usar computadoras para transformar partidas de miles de millones de dólares en la ilusión de seguridad automática

(5) todo tipo de ciencias para las cuales la computación ahora actúa de alguna especie de refugio interdisciplinario

(6) el negocio educativo que siente que, si tiene que enseñar matemática formal a los estudiantes de Ciencias de la Computación, también debería cerrar sus escuelas.

Y con este sexto ejemplo he alcanzado, imperceptiblemente pero también inevitablemente, la parte más engorrosa de esta charla: consecuencias educativas.

El problema con la política educativa es que es difícilmente influenciada por consideraciones científicas derivadas de los tópicos dictados, y casi completamente determinada por circunstancias ajenas a la ciencia tales como las expectativas conjugadas de los estudiantes, sus padres y sus futuros empleadores, y el enfoque prevaleciente del rol de la universidad: el acento está en formar sus graduados para los trabajos de nivel inicial de hoy o en proveer a su alumnado con el bagaje intelectual y las actitudes que perduraran por otros 50 años? ¿Le damos rencorosamente a las ciencias abstractas solo un rincón lejano en el campus, o las reconocemos como el motor indispensable de la industria de alta tecnología? Aún si hacemos esto último, ¿reconocemos una industria de alta tecnología como tal si su tecnología pertenece principalmente a las matemáticas formales? ¿Proveen las universidades a la sociedad el liderazgo intelectual que necesita o sólo el entrenamiento que demanda?

La retórica académica tradicional está perfectamente dispuesta a dar a estas cuestiones las respuestas tranquilizadoras, pero no creo en ellas. A modo de ilustrar mis dudas, en un artículo reciente en "¿Quién gobierna Canadá?", David H. Flaherty groseramente establece que "Además, la élite de los negocios descarta a los académicos e intelectuales como ampliamente irrelevantes e impotentes."

Así, si miro en mi borrosa bola de cristal hacia el futuro de la educación en ciencias de la computación, veo sobrecogedoramente la deprimente imagen del "Negocio acostumbrado". A las universidades les seguirá faltando el coraje de enseñar ciencia dura, continuará orientando mal a los estudiantes, y cada nuevo escalón de infantilización del currículum será exaltado como progreso educativo.

Hace un buen rato que tengo mi borrosa bola de cristal. Sus predicciones son invariablemente melancólicas y usualmente correctas, pero estoy bastante acostumbrado a eso y no me impiden darles unas pocas sugerencias, aún si es meramente un ejercicio vano cuyo único efecto es hacerlos sentir culpables.

Podemos, por ejemplo, comenzar limpiando nuestro lenguaje no denominando a un bug un bug, sino denominándolo un error. Es mucho mas honesto porque pone manifiestamente la culpa donde corresponde, es decir, en el programador que cometió el error. La metáfora animada del bug que se introdujo maliciosamente mientras el programador no estaba mirando es intelectualmente deshonesta ya que disfraza el hecho de que el error es propia creación del programador. Lo agradable de este simple cambio de vocabulario es que tiene un profundo efecto: mientras, antes, un programa con sólo un error solía ser "casi correcto", después de ello un programa con un error es simplemente "erróneo" (porque tiene un error).

Mi próxima sugerencia lingüística es más rigurosa. Se trata de confrontar el síndrome de "si-este-tipo-quiere-hablarle-a-ese-tipo": nunca se refieran a partes de programas o piezas de equipo en una terminología antropomórfica, ni permitan hacerlo a sus estudiantes. Esta mejora lingüística es mucho más difícil de implementar de lo que podrían pensar, y su departamento puede considerar la introducción de multas para las violaciones, digamos veinticinco centavos para estudiantes de grado, cincuenta centavos para estudiantes de postgrado y cinco dólares para miembros de la facultad: para final del primer semestre del nuevo régimen, habrán recolectado suficiente dinero para dos becas.

La razón para esta última sugerencia es que la metáfora antropomórfica –por cuya introducción podemos culpar a John von Neumann– es una enorme desventaja para cada comunidad informática que la ha adoptado. He encontrado programas que quieren cosas, saben cosas, esperan cosas, creen cosas, etc., y cada vez eso generaba confusiones evitables. La analogía que subyace a esta personificación es tan superficial que no es solamente engañosa sino también paralizante.

Es engañosa en el sentido que sugiere que podemos lidiar con el desconocido discreto en términos del familiar continuo, es decir, nosotros mismos, quod non. Es paralizante en el sentido que, debido a que las personas existen y actúan en el tiempo, su adopción efectivamente impide un despegue de la semántica operacional y fuerza así a la gente a pensar sobre los programas en términos de comportamientos computacionales, basados en un modelo computacional subyacente. Esto es malo, porque el razonamiento operacional es un tremendo desperdicio de esfuerzo mental.

Déjenme explicarles la naturaleza de ese tremendo desperdicio, y permítanme tratar de convencerlos de que el término "tremendo desperdicio de esfuerzo mental" no es una exageración. Por un breve lapso, me tornaré altamente técnico, pero no se acobarden: es el tipo de matemáticas que uno puede hacer con las manos en los bolsillos. El punto a comunicar es que si tenemos que demostrar algo respecto de todos los elementos de un conjunto grande, es desesperanzadamente ineficiente tratar con todos los elementos del conjunto individualmente: el argumento eficiente no se refiere a elementos individuales en lo absoluto y se lleva a cabo en términos de la definición del conjunto.

Consideren la figura plana Q, definida como el cuadrado de 8 por 8 del cual, en dos esquinas opuestas, han sido quitados dos cuadrados de 1 por 1. El área de Q es 62, que equivale al área combinada de 31 dominós de 1 por 2. El teorema es que la figura Q no puede ser cubierta por 31 de tales dominós.

Otra manera de exponer el teorema es que si comienza con papel cuadriculado y se cubre este ubicando cada siguiente dominó en dos nuevos recuadros adyacentes, ninguna distribución de 31 dominós dará como resultado la figura Q.

Así, una posible manera de probar el teorema es generando todas las posibles distribuciones de dominós y verificando para cada distribución que no da como resultado la figura Q.

El argumento simple, sin embargo, es como sigue. Pinte los recuadros del papel cuadriculado como un tablero de ajedrez. Cada dominó, cubriendo dos recuadros adyacentes, cubre 1 recuadro blanco y 1 negro, y , por consiguiente, cada distribución cubre tantos recuadros blancos como recuadros negros. En la figura Q, sin embargo, el número de recuadros blancos y el número de recuadros negros difiere en 2 –esquinas opuestas sobre la misma diagonal– y por consiguiente ninguna disposición de dominós da como resultado la figura Q.

No sólo es el simple argumento previo muchos órdenes de magnitud más corto que la investigación exhaustiva de las posibles distribuciones de 31 dominós, es también esencialmente más poderosa, dado que cubre la generalización de Q reemplazando el cuadrado original de 8 por 8 por cualquier rectángulo con lados de longitud par. Siendo infinito el número de tales rectángulos, el método previo de exploración exhaustiva es esencialmente inadecuada para probar nuestro teorema generalizado.

Y esto concluye mi ejemplo. Ha sido presentado porque ilustra de un tirón el poder de las matemáticas terrenales; no hace falta decirlo, la negación de explotar este poder de las matemáticas terrenales escala al suicidio intelectual y tecnológico. La moraleja de la historia es: tratar con todos los elementos de un conjunto ignorándolos y trabajando con la definición del conjunto.

Volvamos a la programación. La aseveración de que un programa dado cumple una cierta especificación escala a una aseveración sobre todos los cálculos computacionales que podrían ocurrir bajo el control de ese programa dado. Y dado que este conjunto de cálculos está definido por el programa dado, nuestra reciente moraleja dice: trate con todas los cálculos posibles bajo control de un programa dado ignorándolas y trabajando con el programa. Debemos aprender a trabajar con el texto de los programas mientras (temporalmente) se ignora que admiten la interpretación de código ejecutable.

Otra manera de decir la misma cosa es la siguiente. Un lenguaje de programación, con su sintaxis formal y las reglas de demostración que define su semántica, es un sistema formal para el cual la ejecución del programa provee solamente un modelo. Es bien conocido que los sistemas formales deberían ser tratados por derecho propio, y no en términos de un modelo específico. Y, de nuevo, el corolario es que deberíamos razonar sobre los programas sin siquiera mencionar su posible "comportamiento".

Y esto concluye mi excursión técnica en el motivo por el cual el razonamiento operacional sobre la programación es "un tremendo desperdicio de esfuerzo mental" y por qué, en consecuencia, en la ciencia de la computación debería prohibirse la metáfora antropomórfica.

No todo el mundo comprende esto suficientemente bien. Recientemente fui expuesto a una demostración de lo que pretendía ser software educativo para un curso introductorio de programación. Con sus "visualizaciones" en la pantalla era un caso tan obvio de infantilización del currículum que su autor debería ser acusado de su "menosprecio del cuerpo estudiantil", pero esto era sólo un daño menor comparado con para qué se usaban las visualizaciones: ¡se usaban para mostrar todo tipo de características de cálculos computacionales evolucionando bajo el control del programa del estudiante! El sistema remarcaba precisamente aquello que el estudiante tiene que aprender a ignorar, reforzaba precisamente lo que el estudiante tiene que desaprender. Dado que quitarse los malos hábitos, más que adquirir nuevos, es la parte más dura del aprendizaje, debemos esperar de ese sistema un daño mental permanente para la mayoría de los estudiantes expuestos.

No hace falta decirlo, ese sistema ocultaba completamente el hecho de que, por sí sólo, un programa no es más que la mitad de una conjetura. La otra mitad de la conjetura es la especificación funcional que se supone que satisface el programa. La tarea del programador es presentar las conjeturas completas como teoremas demostrados.

Antes de irnos, me gustaría invitarlos a considerar la siguiente forma de hacer justicia a las novedades radicales de la computación en un curso introductorio a la programación.

Por un lado, enseñamos algo que se parece al cálculo de predicados, pero lo hacemos de manera muy distinta a los filósofos. A fin de entrenar al programador novato en la manipulación de fórmulas sin interpretar, lo enseñamos más como álgebra booleana, familiarizando al estudiante con todas las propiedades algebraicas de los conectivos lógicos. Para romper aún más los vínculos con la intuición, renombramos los valores {verdadero, falso} del dominio booleano como {negro, blanco}

Por otro lado, enseñamos un lenguaje de programación imperativo simple y claro, con un skip y una asignación múltiple como sentencias básicas, con una estructura de bloque para variables locales, el punto y coma como operador para composición de sentencias, una bonita construcción alternativa, una bonita repetición y, si se quiere, una llamada a procedimiento. A esto agregamos un mínimo de tipos de datos, digamos booleanos, enteros, caracteres y cadenas. Lo esencial es que, para lo que sea que introduzcamos, la semántica correspondiente está definida por las reglas de demostración que la acompañan.

Desde el comienzo, y a través de todo el curso, enfatizamos que la tarea del programador no es sólo escribir un programa, sino que su tarea principal es dar una prueba formal de que el programa que propone cumple la especificación funcional (igualmente formal). Mientras se diseñan demostraciones y programas conjuntamente, el estudiante adquiere una amplia oportunidad de perfeccionar su destreza manipulativa con el cálculo de predicados. Finalmente, para hacer llegar el mensaje de que este curso introductorio a la programación es principalmente un curso en matemáticas formales, nos encargamos de que el lenguaje de programación en cuestión no haya sido implementado en el campus de manera que los estudiantes estén protegidos de la tentación de probar sus programas. Y esto concluye el esbozo de mi propuesta para un curso introductorio a la programación para estudiantes de primer año.

Esta es una propuesta seria, y sumamente sensible. Su única desventaja es que es demasiado radical para muchos, quienes, siendo incapaces de aceptarla, se ven forzados a inventar alguna justificación rápida para desestimarla, no importa cuan inválida sea. Les daré unas pocas de esas justificaciones.

No necesitan tomar mi propuesta seriamente porque es tan ridícula que estoy obviamente desconectado del mundo real. Pero ese barrilete no va a volar, ya que conozco el mundo real demasiado bien: los problemas del mundo real son principalmente aquellos con los que ustedes se quedan después de negarse a aplicar sus efectivas soluciones. Así que, probemos de nuevo.

No necesitan tomar seriamente mi propuesta porque es sumamente surrealista intentar enseñar tal material a alumnos de primer año. ¿No sería esa una salida fácil? Acaban de postular que esto sería por lejos muy difícil. Pero ese barrilete tampoco va a volar, dado que el postulado se ha demostrado falso: desde principios de los '80, se ha dado tal curso introductorio a la programación a cientos de estudiantes de primer curso de grado cada año. [Porque, en mi experiencia, decir esto no es suficiente, la sentencia previa debería repetirse al menos otras dos veces]. Así que, intentemos de nuevo.

Admitiendo renuentemente que podría quizás enseñarse a estudiantes suficientemente dóciles, todavía rechazan mi propuesta porque tal curso se desviaría tanto de lo que los estudiantes de 18 años están habituados y esperan, que inflingírselos sería un acto de irresponsabilidad educativa: sólo frustraría a los estudiantes. No hace falta decirlo, ese barrilete tampoco va a volar. Es cierto que el estudiante que nunca ha manipulado fórmulas sin interpretar se da rápidamente cuenta que se confronta con algo totalmente distinto a cualquier cosa que haya visto antes. Pero afortunadamente, las reglas de manipulación son en este caso tan pocas y simples que muy poco después hace el excitante descubrimiento de que está comenzando a dominar el uso de una herramienta que, en toda su simplicidad, le da un poder que sobrepasa sus sueños más audaces.

Enseñar a jóvenes desprevenidos el uso efectivo de los métodos formales es uno de los placeres de la vida porque es extremadamente gratificante. En pocos meses, encuentran su camino en un mundo nuevo con justificado grado de confianza, que es radicalmente novedoso para ellos; en pocos meses, su concepto de cultura intelectual ha adquirido una dimensión radicalmente novedosa. Para mi gusto y estilo, esto es de lo que se trata la educación. Las universidades no deberían temer a enseñar novedades radicales; por el contrario, es su llamado dar la bienvenida a la oportunidad de hacerlo. Su disposición a hacerlo es nuestra principal salvaguarda contra las dictaduras, sean del proletariado, del establishment académico, o de la élite corporativa.

Austin, 2 de Diciembre de 1988

prof. dr. Edsger W. Dijkstra

Departamento de Ciencias de la Computación

Universidad de Texas

Austin, TX 78712-1188

USA


Traducción: Javier Smaldone y Billy Biset.

Transcripción original: Javier Smaldone.

Última revisión: 5 de agosto de 2006 (11:45 am).

Última versión y actualizaciones: http://www.smaldone.com.ar/documentos/ewd.shtml

Nota de los traductores: La versión HTML contiene el texto original en forma de comentarios, para simplificar su corrección.