----- Original Message -----From:To:Cc:Sent: Thursday, January 15, 2009 2:25 PMSubject: Re:Hola,No entiendo el correoUna de las razones es que debemos de utilizar diferentes términos.Te explico los que nosotros utilizamosUSUARIO===========Combinado con la contraseña sirve para identificar y garantizar la identidad de las personas que acceden al sistemaEjemplos de usuarios alberto@dept1, gerardo@ent1CUENTA=========El objetivo fundamental de la cuenta es poder distribuir y organizar las operaciones realizadas a diferentes usuarios.
En ocasiones se utiliza también para identificar en la orden el usuario, el departamento, desgloses, cuestiones de backoffice... pero eso son cuestiones secundarias que dependen de las necesidades específicas y de como se hayan configurado.
A un usuario se le da permiso a diferentes servicios de la plataforma (como por ejemplo la visualización de precios)
A un usuario se le pueden asignar una o varias cuentas en una relación de usuario/cuenta/mercado/tipoPermiso
Con este esquema podemos configurar que una orden introducida por el usuario X, sea vista por alguien más o no. Incluso que otra persona pueda cancelarla o modificarla.
El modelo es muy flexible (y lógicamente no es una configuración trivial)
Hay otras cuestiones, como los grupos de cuentas, los filtros de usuario, grupos de filtros, filtros de entidad, filtros de cuenta, etc... que ya comentaremos en otro momento.
Dicho esto, te paso a explicar cuál es la configuración actual de banco pastor en MEFF (sólo la relación usuario/cuenta/mercado/tipoPermiso, no entramos en filtros ni grupos, ni permisos a nivel de entidad)
Usuarios...
===========fulanito1
fulanito2
pedrito
raulito
jaimito
Cuentas...
=========BOLSA
DIRECCION
FULANITO
Relación efectiva usuario/mercado/cuenta/tipoPermiso
(efectiva porque la configuración está representada de otra forma)
===========================================(omito el mercado porque esto es sólo para meff)
USUARIO CUENTA TIPO PERMISO bbbb BOLSA VER bbbb DIRECCIÓN VER bbb FB VER ffff BOLSA TOTAL ffff DIRECCIÓN TOTAL ffff FB TOTAL ffff BOLSA TOTAL fdddd DIRECCIÓN TOTAL fdddd FB TOTAL oooo BOLSA TOTAL oooo DIRECCIÓN TOTAL oooo FB TOTAL rrrr BOLSA TOTAL rrrr DIRECCIÓN TOTAL rrrr FB TOTAL
Esta tabla se puede definir con la siguiente expresión...
Banco Pastor tiene 3 cuentas
Banco Pastor tiene 5 usuarios
Todos los usuarios ven y pueden manipular las órdenes de todas las cuentas (lo que genera que comparten todas las órdenes, pudiendo introducir cualquier usuario con cualquier cuenta y todos ven las órdenes de sus compañeros)
EXCEPTO backoffice que sólo puede verlas (las 3 cuentas)
Supongo que en el resto de mercados será algo muy parecido.
Espero haberme explicado.
Puedes mandarme la expresión que define la configuración o mandar la modificación de la tabla
hablamos
----- Original Message -----From:To:Sent: Thursday, January 15, 2009 11:20 AMBuenos dias:Espero poder aclarar exactamente cual es la configuracion que querria Banco XX.Querrian que federico tuviera laposibilidad de acceder a la cuenta Direccion y viceversa.Querrian que la cuenta Bolsa tuviera acceso a la cuenta Direccion y viceversa.Ahora bien, tambien querrian que las cuentas federico y Bolsa fueran independientes en todos los sentidos la una de la otra.Este seria el escenario deseado.Gracias y un saludo
jueves, enero 15, 2009
solicitud alta usuarios
Ser padre en 10 lecciones
1) Para vivir la experiencia del embarazo: cuélguese una bolsa de garbanzos a la altura de la barriga, agregando un puñado todos los días durante nueve meses. Luego de los nueve meses, abra la bolsa y retire el 10% de los garbanzos.
2) Antes de lanzarse a tener hijos, busque una pareja que ya los tenga y sométalos a estudio. Critique sus métodos para imponer disciplina, su falta de paciencia, sus pésimos niveles de tolerancia, y por haber permitido que sus hijos se porten como salvajes. Sugiera maneras de mejorar el comportamiento de los niños a la hora de acostarse, ir a hacer pipí o comer. Aproveche, será la última vez que tendrá todas las respuestas.
3) Para hacerse una IDEA de cómo serán las noches, consiga un almohadón húmedo de entre 4 y 6 kilos, y recorra el salón llevándolo en brazos, sin sentarse, desde las 5 de la tarde hasta las 10 de la noche. A las 10 suelte el almohadón, ponga el despertador para que suene a las 12 y duerma.
Cuando a las 12 suene el despertador, levántese y vuelva a pasear el almohadón por el salón mientras canta canciones de cuna en la oscuridad. Repetir a las 2 AM a las 4 AM y a las 6 AM. Opcional: a las 4 AM puede dar una vuelta en coche con el almohadón. Siga esta rutina durante 5 años. Ponga siempre buena cara.
4) ¿Es posible aguantar a los niños dentro de casa? Para averiguarlo, unte nocilla en el sofá y mermelada en las cortinas. Esconda un trozo de pescado rebozado detrás del equipo de música y déjelo ahí durante todo el verano.
Meta los dedos en las macetas y luego arrástrelos por las paredes más limpias. Dibuje encima de las manchas con lápices de color. Compre 5 cachorritos de doberman y déjelos retozar en su dormitorio.
5) Vestir a un niño pequeño es simple: primero, compre un pulpo, pídale al verdulero una bolsa de red y trate de introducir el pulpo dentro de la bolsa de manera que no salga ninguno de los tentáculos por los agujeros de la red. No se aflija, le puede dedicar toda la mañana.
6) Niños en edad escolar: Guarde una caja de huevos (vacía). Usando una tijera y unos rotuladores, conviértala en un gracioso cocodrilo. Ahora junte un envase tetra-brik, una pelota de ping-pong y un paquete de cereales vacío y construya una réplica exacta de la Torre Eiffel.
Comience este trabajo a las 11 de la noche, que sería la hora en la que se entera que ES PARA MAÑANA. ¡Excelente! Ahora espere las críticas de la maestra.
7) Cambie el coche de dos puertas por una camioneta. Y no la lave nunca más. Después de todo, es un auto familiar, sin valor de reventa.
Compre un helado de chocolate y aplástelo en la guantera. Meta dos monedas de 10 cts. en el compact. Compre un paquete familiar de galletitas dulces. Macháquelas un buen rato sobre los asientos traseros. Salga del coche, y arañe ambos lados del vehículo con la llave. ¡Perfecto!
8) Vaya al supermercado. Lleve consigo lo más parecido que encuentre a un niño de menos de cuatro años (una cabra adulta es ideal). Si piensa tener más de un hijo, lleve dos cabras sueltas. Haga la compra para una semana sin perder de vista las cabras. Mantenga discusiones con los encargados de seguridad del supermercado, subiendo en el escalafón (pero siempre sin perder de vista a las cabras). Cuando llegue al gerente, cambie de supermercado.
9) Darle de comer a un niño: Compre un melón, vacíelo, y hágale un pequeño agujero en un costado. Cuélguelo del techo y dele un golpe para que se balancee. Ahora tome un plato con puré de calabaza. Trate de meter cucharadas de puré dentro del melón, mientras simula ser un avión.
Siga intentándolo hasta terminar la mitad del puré. El resto, viértalo sobre su regazo, y desparrame bastante en el suelo.
10) El aseo de la criatura: Consiga un gato adulto (preferentemente callejero o semisalvaje). Póngase su mejor traje si es hombre o medias y zapatos de tacón alto si es mujer. Llene la bañera con agua tibia y juguetes de goma. Acto seguido introduzca el gato y lávelo con
champú.. luego de enjuagarlo y secarlo con una toalla, siga el procedimiento indicado previamente con el pulpo y la bolsa de red. Repetir todas las noches durante 5 años.
Si logra superar estos pasos, usted puede tener hijos cuando lo desee.
El resto es lo mejor que le podrá pasar en su vida
lunes, enero 12, 2009
sábado, enero 03, 2009
Aprender varios lenguajes de programación
Do you have any advice for up-and-coming programmers?
Learn Lua :)
More seriously, I really subscribe to the idea that "if the only tool you have is a hammer, you treat everything like a nail". So, programmers should learn several languages and learn how to use the strengths of each one effectively. It is no use to learn several languages if you do not respect their differences.
martes, diciembre 30, 2008
Porcentajes ¿sencillos?
Yo creo que los "porcentajes" no son tan sencillos como parecen
- ¿Porqué un tendero anuncia que los productos de la competenica son un 50% más caros?
- 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? - 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? - 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
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
http://joseluis.estebanaparicio.googlepages.com/saltodelapulga
viernes, diciembre 26, 2008
git vs svn
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:
- 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
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
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
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:
- 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
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.
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.
- Amalgamated Pixels
Elf, Looney Tunes - Computer Cafe
League of Extraordinary Gentlemen - Flash Film Works
Duplex, The Last Samurai - Hammerhead
Showtime, Blue Crush, 2 Fast, 2 Furious - Rhythm & Hues
Harry Potter, Cats & Dogs, Dr. Dolittle 2, Little Nicky, Grinch, Sixth Day, Stuart Little, Planet of the Apes - Sony Pictures Imageworks
Stuart Little II, Spider-Man
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.
gimp vs photoshop 3 (mi modesta opinió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
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:
- Their user ID is brand new.
- They have no website.
- They have no portfolio.
- They couldn’t even be bothered to add an icon/avatar to their ID.
- 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?