MODH Monóxido de dihidrógeno

http://www.dhmo.org/facts.html

http://inciclopedia.wikia.com/wiki/MODH

¿Cuáles son los peligros asociados al MODH? Editar sección

El MODH mostrando su cara más destructiva

Cada año, el MODH está implicado en millares de muertes y es causante de pérdidas de miles de millones de euros en daños materiales y daños medioambientales. Algunos efectos nocivos del MODH son:

• Muerte asociada a la inhalación del MODH, incluso en cantidades relativamente pequeñas.
• Una exposición prolongada al MODH en estado sólido causa quemaduras graves y necrosis agudas.
• Contribuye de manera importante a la erosión del suelo y a la desertización.
• Es causante de corrosión y oxidación en muchos metales. Sólo tratamientos específicos pueden impedir la degradación de estructuras como puentes, edificios y objetos cotidianos metálicos.
• Su exposición a sistemas electrónicos produce cortocircuitos, que se pueden traducir en pérdidas multimillonarias.
• Su presencia reduce notablemente la efectividad de los sistemas mecánicos, en especial los frenos de los automóviles.
• Se ha encontrado en numerosas biopsias de tumores y lesiones precancerosas.
• Está asociado a huracanes y ciclones en el Atlántico y el Pacífico.
• Variaciones térmicas del MODH están tras el fenómeno de El Niño
• El MODH es un causante de las tormentas tropicales, que anualmente provocan pérdidas de millones de euros.
• Es útil para librarse de vecinos indeseables, e incluso los que no lo son tanto.
• Un exceso en su uso en agricultura puede provocar la pérdida de cosechas enteras.
• Es uno de los más importantes gases de efecto invernadero, asociados con el cambio climático.
• Su ingesta excesiva llena la cavidad digestiva, de forma que las personas sienten menos necesidad de consumir sustancias beneficiosas para el organismo, como por ejemplo el whisky.
• Es mortal por inhalación.

El canon digital y la contradicción

http://blogs.rtve.es/retiario/2011/3/24/el-canon-digital-y-contradiccion

El canon digital, cuyo reglamento acaba de tumbar la Audiencia Nacional, provoca sentimientos encontrados. A los intermediarios de la industria cultural, como la SGAE y otras entidades de gestión, les produce intenso placer por su recaudación, pero aborrecen su justificación. Los usuarios abominamos del canon, que encarece los productos electrónicos y por tanto dificulta la llegada de la Sociedad de la Información, pero nos encanta y queremos conservar su razón de ser. Porque el famoso y generalmente mal comprendido canon digital tiene su origen en la copia privada, un derecho que reconoce explícitamente la legislación de Derecho de Autor por el cual el propietario legítimo de una obra puede realizar copias para su uso personal. El canon digital compensa a los autores por la (hipotética) pérdida de ingresos que les supone este derecho que tenemos todos los consumidores.

En efecto, el canon digital no compensa la llamada 'piratería' de obras protegidas. Tampoco justifica la copia indiscriminada al grito de ‘yo ya he pagado’. Su justificación es llevar al extremo una lógica jurídica concreta: la de que el autor debe autorizar (y por tanto cobrar) cada una de las copias que se realicen de su trabajo. Es el presupuesto subyacente a todo el andamiaje de la llamada ‘propiedad’ intelectual: el cobro por copia, en la que todas y cada una de las reproducciones devengan un derecho al autor. Incluso las copias que realice para su uso privado el comprador de una obra cultural. Incluso las que están almacenadas en bibliotecas, que generan su propio (y separado) canon. Unos pocos autores, representados por aún menos entidades de gestión, que cobran por cada copia realizada de su trabajo: éste es el universo en el que se mueve el Derecho de Autor y el Copyright. Un universo que la sentencia no pone en duda, ya que no cuestiona ni el derecho de copia privada ni que éste genere un canon: tan sólo impugna el modo de cobrarlo por defectos de forma en su aprobación.

La contradicción, entonces, permanece. Para el sector más radical de los autores y para las entidades de gestión el canon es un efecto secundario deseable de un derecho indeseable: el permiso explícito de hacer copias fuera de su control. Los consumidores quieren el derecho a hacer copias privadas, que a cambio acarrea la desagradable necesidad de pagar un canon mal estructurado. Autores y entidades de gestión desearían eliminar la copia privada, pero quieren el canon; los consumidores acabarían con el canon, pero quieren preservar la copia privada. Ambas partes viven en la contradicción de una lógica absurda. Porque lo que está mal son los presupuestos en los que se basa todo el sistema.

En la Era Digital todos somos autores y todos somos consumidores. Si lo justo es que el canon se reparta entre los creadores de obra susceptible de ser copiada deberían cobrar no sólo los afiliados a la SGAE, sino los autores de todos los vídeos de YouTube, todos los blogueros y hasta los prolíficos trolls que abundan en los comentarios. ¿Porqué unos autores, los afiliados, reciben su porción y otros no? En Internet no hay una separación diáfana entre autores y lectores, entre creadores y consumidores; todos tendemos a crear y todos tendemos a disfrutar lo creado. Todos pagamos el canon, en tanto que consumidores de cultura, y según la cultura se muda al formato digital cada vez pagaremos más. Pero todos deberíamos cobrar el canon, ya que participamos en múltiples formas de creación en la Red, y cada vez lo hacemos más. A lo mejor lo más sencillo era evitarnos los gastos de gestión y perdonarnos mutuamente pagos y cobros. Claro que habría perjudicados: las entidades que viven de esos gastos de gestión. Ni los autores ni la cultura, los intermediarios son los únicos beneficiarios reales del sistema.

En la Era Digital, además, toda propagación de una obra se hace mediante copias 'tecnicas'. Internet es una inmensa máquina de copiar: la transmisión de cualquier mensaje implica copiarlo decenas o centenares de veces. Ya no es posible controlar cuántas copias se hacen de una obra, por lo que no resulta posible cobrar por cada una. Es más, es indeseable, dado que la economía nos dice que cuanto mayor es el precio menor es la demanda. Esto implica que si cobramos por las copias estaremos favoreciendo que haya menos de ellas, y reduciremos el impacto de esa obra en la cultura. En un mundo donde la sobredosis de información disponible hace cada vez más difícil conseguir audiencias reducir el impacto de una obra puede convertirla en irrelevante. El cobro por copia es imposible e indeseable en el mundo de Internet, para artistas y para consumidores. Nuevamente sólo las entidades de gestión, los intermediarios, se ven favorecidos por un mecanismo que perjudica al resto del mercado.

La lógica de la actual protección del Derecho de Autor se ha quedado obsoleta y debe ser reemplazada. Por eso aparecen los conflictos actuales y las abiertas contradicciones. El canon no es una enfermedad, sino un síntoma: una prueba más de que las raíces de lo que se ha dado en llamar ‘propiedad’ intelectual están podridas. Es hora de empezar de nuevo, y de dotar a la creación de una plataforma de compensación acorde con los tiempos que corren en la que no aparezcan absurdos como los que provoca la copia privada y su canon. El problema va mucho más allá de arreglar el reglamento de una ley: hay que rehacer la defensa entera de la creación intelectual y la cultura. Porque defendiendo a unos intermediarios por medio de una lógica absurda estamos echando a perder el futuro.

ssh rápido

http://www.linuxnix.com/2010/03/how-to-reduce-delay-getting-ssh-login-prompt.html


sudo kate /etc/ssh/sshd_config

Añadir o modificar la entrada UseDns

UseDns no


En ubuntu...

sudo /etc/init.d/ssh restart

fedora o redhat

service sshd reload

como cambiar extensión a múltiples ficheros en Linux/bash

for f in $(find . -name '*.impl'); do git mv $f ${f/\.impl/.cxx}; done

Linus Tordvalds opina

https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129

Linus Torvalds 2010-11-30 20:50:25 EST

(In reply to comment #128)

>

> In Adobe's software.

>

> > I'm no great fan of flash but it's an essential part of life on the web these

> > days and I had thought that the Fedora project had finally put its days of

> > broken flash support behind it.

>

> Fedora's flash support is fine. Adobe's software is broken.

Quite frankly, I find your attitude to be annoying and downright stupid.

How hard can it be to understand the following simple sentence:

THE USER DOESN'T CARE.

Pushing the blame around doesn't help anybody. The only thing that helps is

Fedora being helpful, not being obstinate.

Also, the fact is, that from a Q&A standpoint, a memcpy() that "just does the

right thing" is simply _better_. Quoting standards is just stupid, when there's

two simple choices: "it works" or "it doesn't work because bugs happen".

Standards are paper. I use paper to wipe my butt every day. That's how much

that paper is worth.

Reality is what matters. When glibc changed memcpy, it created problems. Saying

"not my problem" is irresponsible when it hurts users.

And pointing fingers at Adobe and blaming them for creating bad software is

_doubly_ irresponsible if you are then not willing to set a higher standard for

your own project. And "not my problem" is not a higher standard.

So please just fix it.

The easy and technically nice solution is to just say "we'll alias memcpy to

memmove - good software should never notice, and it helps bad software and a

known problem".

goldmand sachs y erlang

Goldan Saschs tenía un sistema de trading automático con el que ganaba mucho dinero

Este sistema se basa en un error conceptual de mercados en EEUU

En estos mercados, había varios tipos de clientes y conexiones.

Los de pata negra (que pagan bien) podían ver las órdenes un pelín

antes de que fueran inyectadas al resto de gorrinos rositas

Entonces goldman montó un sistema (con un hacker ruso muy bueno) para

ganar dinero

Consistía en tener una máquina tan rápida, que fuera capaz de ver el

cruce en nuevas posiciones, y generar ambas contrapartidas ganando el

diferencial

Si lo hacían con suficiente velocidad, ya no habría en el mercado más

agresiones "a la cola" que no fueran de Goldmand

El caso es que les fue muy bien, pero el ruso se marchó porque le

pagaban el triple y Goldmand le acusó de robarles su programa que

parece que sí lo robó

Fue en ese momento cuando se descubrió el pastel

En mi opinión, a los gestores del mercado y a Goldmand les deberían

haber sancionado (no sólo al ruso)

Lo que hacía Goldmand, era una pura maniobra especulativa ¿Para eso

queremos los mercados electrónicos? ¿No se suponía que ofrecían

limpieza y transparencia? ¿O al menos no deberían intentar hacerlo?

El caso y lo que quería contar...

¿En qué estaba escrito ese super programa de automatic trading?

Hasta la fecha el más complejo y mejor programa en el sector

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

http://en.wikipedia.org/wiki/Erlang_(programming_language)

intentando explicar la virtualización

Permíteme intentar explicar un poco de que va eso de la virtualización.

Un ordenador es hierro (la parte que se puede tocar) y programas.

Uno de los programas es un programa especial, es el sistema operativo (que puede ser Windows, Linux, AIX, Solaris y muchos otros)

Este programa es especial porque es el único que habla con las partes “hierro” (las partes físicas)

El resto de programas le dicen al sistema operativo, escribe en disco tal cosa, pinta en la pantalla tal cosa, escribe en el cable de red tal cosa, etc…

Y es el sistema operativo el que le dice a las aplicaciones, “oye tú, han pulsado tal tecla, y ahora han movido el ratón, etc…)

Por tanto, cada ordenador tiene instalado un sistema operativo para interactuar con el hardware (la parte física)

Ahora supongamos que hacemos un programa mentiroso, y este programa, engaña a otro programa (que es un sistema operativo), haciéndole creer que está hablando con una máquina real, cuando en realidad es un programa mentiroso

Conseguimos de esta forma que un programa diseñado para hablar con la parte física del ordenador, en realidad hable con otro programa, pero sin saberlo, ha sido engañado.

Es como matrix pero al revés (el engañado es un programa)

Una vez dado este paso, es trivial engañarle varias veces. Podemos tener varios sistemas operativos ejecutándose al mismo tiempo en una sola máquina real

¿Para qué sirve esto?

En el pasado se utilizó para probar programas y especialmente probar sistemas operativos mientras estos se están creando.

Ahora se están haciendo populares por ahorro de costes.

Se ahorran costes comprando menos máquinas y no menos importante, se ahorran costes de mantenimiento.

AHORRO POR COMPRA DE MÁQUINAS

Sin extenderme mucho, los programas no son capaces de sacarle jugo a toda la máquina (y en el futuro podrán menos, todo por culpa de una decisión en los años 60)

Además, salvo en contextos específicos, las máquinas están tocándose las narices esperando que le pidan que haga algo.

Por estas dos razones, podrías comprar menos máquinas y compartir los recursos físicos de las máquinas creando máquinas virtuales dentro de la máquina principal.

No hay recursos suficientes para que todos demanden el 100% de la máquina al mismo tiempo, pero… eso no suele pasar; y si sucediera, supondría un comportamiento más lento durante unos segundos de las máquinas. Si eso no es un problema, se ahorra mucho (comprando menos máquinas, uso más eficiente, menos consumo eléctrico)

AHORRO MANTENIMIENTO

Supongamos que se rompe una máquina, hay que comprar otra, reinstalar el sistema operativo y todos los programas, recuperar todos los documentos, configuraciones, etc…

Es una tarea pesada.

Supongamos que hay que cambiar la máquina porque es antigua o le falta memoria o disco duro o…

Lo mismo, muy pesado en tiempo y propenso a problemas (especialmente la parte de resintalación y recupareración de datos y configuraciones)

Para todo esto es necesario sacar copias de seguridad de todo. Esto debería de verificarse periódicamente (casi nunca se hace por lo pesado que es).

Por cierto, todo sistema de contingencia no verificado periódicamente, es peor que ningún sistema de contingencia (crea una falsa sensación de seguridad)

O simplemente hace falta una máquina nueva

¿Cómo sería con un sistema virtualizado?

La máquina virtual con TODO, está en un fichero.

¿Copia de seguridad? Es tan sencillo como copiar el fichero (la máquina virtual).

¿Una máquina necesita más disco duro o memoria?

Pues se le da VIRTUALMENTE, sin necesidad de abrir ninguna caja.

Máquina nueva… copia de fichero, ajustes de configuración y voalá

Se cambia una máquina física y nadie se entera, siendo además un proceso muchísimo más sencillo, sólo hay que copiar un fichero por cada máquina (virtual).

Se pueden virtualizar servidores y ordenadores de trabajo (workstations con su Windows Excel y resto de programas)

Esta es la virtualización de máquinas, pero hay otra cosa llamada virtualización de aplicaciones, que también es muy, muy interesante.

Para sistemas de alto rendimiento o tiempo real (son cosas diferentes), la virtualización es un problema delicado, pero todo depende de los niveles de exigencia que hay que valorar con el ahorro de costes.

La virtualización es algo que los usuarios deberían tener en casa para reducir también costes de mantenimiento (que generalmente un usuario no sabe hacer), pero seguramente llegue antes la nube para ayudar a los usuarios (google tiene un proyecto muy ambicioso en este sentido y los usuarios necesitan mucha ayuda)

De la nube, si quieres te cuento en otro momento, pero te anticipo que suele haber virtualización de máquinas (engañar al programa sistema operativo), virtualización de aplicaciones (engañar a un programa “normal”), sistemas distribuidos (las cosas están por ahí vs las cosas están ahí)

Espero que no hay sido muy aburrido y ojalá haya podido ayudar a que entendáis mejor esto

hablamos

Nada nuevo bajo el sol eclipsado del Copyright

http://reyero.net/es/rick_falkvinge/nada_nuevo_bajo_el_sol_eclipsado_del_copyright

Nada nuevo bajo el sol eclipsado del Copyright

Esto es una traducción de Nothing New Under The Copyright-Eclipsed Sun, de Rick Falkvinge.

La industria del copyright ha utilizado los mismos trucos y retórica a lo largo de 500 años, además de ser aficionados a intentar reescribir la historia. Pero el relato de los libros de historia difiere claramente de lo que la industria del copyright está intentando pintar.

Cuando la imprenta llegó en 1453, copista era una profesión en gran demanda. La Peste Negra había causado un gran número de bajas en los monasterios, que no habían sido cubiertas todavía, de ahí que la copia de libros fuera cara.

Retirar a los antiguos copistas no era una opción que le gustase a la Iglesia Católica, quién intento prohibir la imprenta con crueles castigos, incluida la pena de muerte por usarla para copiar libros.

“¿Cómo cobrarán los monjes?”, argumentaban para justificarlo. Aún así, ni siquiera la pena de muerte pudo parar el copiado.

Desde luego, el problema no era el sueldo de los monjes que en realidad, a la Iglesia Católica no podía importarle menos. Todo tenía que ver con el control del conocimiento y la cultura. Una vez que la mayor parte del pueblo hubiese aprendido a leer, la Iglesia perdería su dominio para siempre.

Inglaterra eligió un camino distinto. Viendo que ni la pena de muerte había funcionado, la reina María I necesitaba un aliado dentro de la industria de la impresión. Adjudicó el monopolio de la impresión al gremio de impresores de Londres, la London Company of Stationers, a cambio de poder censurar cualquier cosa antes de ser publicada.

El monopolio fue adjudicado el 4 de mayo de 1557. Fue llamado copyright.

Esta alianza entre la industria y el Gobierno funcionó bien para suprimir las disputas. Pasados 138 años, la censura dejó de ser algo moderno. El Parlamento británico dejó expirar el monopolio del copyright en 1695, y los impresores perdieron un lucrativo monopolio. Solicitaron recobrarlo por un periodo de 15 años.

Finalmente, el Parlamento fue persuadido. Los impresores y distribuidores reclamaron que nada pudiese ser impreso o distribuido sin un monopolio. (Obsérvese que esto es muy, muy diferente a que nada seacreado sin un monopolio.) Pero ellos sugirieron que este monopolio tuviese su origen en el autor y fuese clasificado como propiedad, así podía ser vendido a un impresor.

Haciendo esto, los impresores mataron tres pájaros de un tiro. Uno, consiguieron cumplir el requisito del Parlamento de que no hubiese otro punto centralizado de censura, para que así reconsiderasen el monopolio. Dos, los impresores tendrían todavía el monopolio de hecho ya que los autores estarían obligados a vender el monopolio a los impresores. Tres, clasificaron artificialmente el monopolio como “propiedad” pudiendo inscribirlo dentro del Derecho Consuetudinario (Ley Común) mejor que en la Jurisprudencia, dándole un estatus legal mucho más fuerte.

El monopolio del copyright fue sancionado de esta forma en 1709, y tomó efecto el 10 de abril de 1710, en el llamado “Estatuto de Anne”.

Los Estados Unidos adoptaron un pasaje similar en su posterior Constitución, pero con una justificación más clara, que el único legítimo beneficiario del monopolio del copyright es el público.

Avanzando hasta el advenimiento de las bibliotecas, el monopolio de los editores, ahora fuertes en su creencia casi religiosa de que ellos tenían derecho a dictaminar cómo la gente podía leer, intentaron prohibir el préstamo de libros. “No puedes permitir a la gente leer sin pagar por su propia copia”, argumentaban. Cuando los políticos consideraron las bibliotecas públicas, el monopolio de los editores puso el grito en el cielo.

“¡No puedes dejar que nadie lea ningún libro gratuitamente! ¡Ni un solo libro será vendido nunca más! ¡Nadie podrá vivir de sus escritos! ¡Ningún autor volverá a escribir un solo libro si se aprueba esta ley!”

Sin embargo, el Parlamento en el S. XIX era más sensato que hoy en día, y se dio cuenta exactamente del por qué de la rabieta del monopolio del copyright. Decidieron que el acceso público al conocimiento y a la cultura tenía un gran valor para la sociedad, más que un monopolio que pretendía ser pagado cada vez que un libro fuera abierto, y así, la primera biblioteca pública del Reino Unido abrió en 1850. Y como todos nosotros sabemos, claro está, ni un solo libro más ha sido escrito desde entonces. Oh, espera. Se están escribiendo más libros que nunca en la historia. Quiero decir, el argumento usado es tan falso cuando se usa hoy en día como lo era entonces.

Después de internacionalizar el monopolio del copyright en 1886, la música se convirtió en algo cada vez más interesante. La industria discográfica fue invitada a Roma en 1933 por la Confederazione Generale Fascista dell'Industria Italiana con la intención de corporativizar el monopolio del copyright un poco más. La IFPI fue creada en esta reunión de Roma. La ambición tuvo éxito con el advenimiento de la Convención de Roma en 1961, cuando a la industria discográfica se le concedió un monopolio del copyright-idéntico llamado “derechos conexos”.

Uno se da cuenta aquí de que el monopolio de la industria discográfica es tan reciente como de 1961. No la imagen que ellos pintan.

En la actualidad, los Estados Unidos están intentando intimidar al resto de los países para que respeten los cada vez más fuertes privilegios del monopolio del copyright. Publican todos los años la "Lista especial 301" (Special 301 list), que se supone es la lista negra de los peores "delincuentes" del mundo. La mayoría de la población mundial está en la lista. España y Canadá también han llegado a la lista este año. Para mí, una meta política personal es devolver a Suecia a su lugar en la lista.

En resumen, la batalla sobre quién controla el conocimiento y la cultura se ha extendido a lo largo de 500 años. Las mismas justificaciones han sido utilizadas a lo largo de esos 500 años. Pero aprendiendo de la historia, podemos ver como el movimiento de estrangulación de la Iglesia Católica fue vencido. Debemos repetir ese mismo curso de la acción con el monopolio del copyright hoy. Enseña a todo el mundo a compartir. Haz que todos experimenten cómo es tener todo el conocimiento y la cultura de la Humanidad en sus manos. Una vez obtenida, no les podrán robar esta experiencia, igual que hace 500 años no se podía hacer que la gente "desaprendiese" a leer.

---

Rick Falkvinge es columnista habitual en TorrentFreak, donde comparte sus pensamientos de vez en cuando. Es el fundador del Partido Pirata Sueco, un aficionado al whisky, y un piloto de motocicleta de baja altitud. Su blog en http://falkvinge.net se centra en la política de la información.

Sigue a Rick Falkvinge en Twitter en @Falkvinge y en Facebook como /rickfalkvinge.

---

Traducción al castellano realizada por María Goretti Glez Pacios y Jose A. Reyero.

el a-gilismo metodología ágil desarrollo software

http://queridointernet.wordpress.com/2011/03/02/descubriendo-metodologias-agiles-el-a-gilismo/



Descubriendo metodologías ágiles: el a-gilismo
Publicado el 02/03/2011 por David Viruega
Rate This


Am I stupid?


Querido Internet:
Esta es mi definición de agilismo

(de a-, gilí e -ismo)

a-
(Del gr. ἀ-, priv.).
1. pref. Denota privación o negación. Acromático. Ateísmo. Ante vocal toma la forma an-. Anestesia. Anorexia.

gilí.
(Del caló jili, inocente, cándido, der. de jil, fresco).
1. adj. coloq. Tonto, lelo. U. t. c. s.

-ismo.
(Del lat. -ismus, y este del gr. -ισμός).
1. suf. Forma sustantivos que suelen significar doctrinas, sistemas, escuelas o movimientos. Socialismo, platonismo, impresionismo.

En resumen, significa dejar de hacer el gili. Y es que después de varios años involucrado en la dirección técnica de equipos y proyectos desde distintos departamentos, una de las cosas que más he echado en falta es una forma de dirigir poyectos que esté basada en el comportamiento real de las personas.

Y tras descubrir las metodologías ágiles hace algún tiempo me dí cuenta que llevabamos muchos años haciendo en los proyectos lo que dice la definición de arriba, el lelo.


¿Cuántos de vosotros os habéis encontrado con un cliente que una vez comienza un proyecto decide cambiar de idea sobre lo que quiere, o solicita cambios de alcance o de orientación? En estas circunstancias las metodologías predictivas de gestión de proyectos se centran en encorsetar al cliente, impedir los cambios o reducirlos al máximo, o hacer que estos cambios resulten muy caros para el cliente.

¿Y en qué nos escudamos? Decimos que el cliente no sabe lo que quiere, que cambia de opinión, que no lo tiene claro, que nos pide imposibles y que todo lo que hemos ido haciendo no vale para nada y tenemos que volver a empezar tras cada reunión de seguimiento del proyecto. “Es normal que los proyectos se retrasen, si cada semana se nos piden cosas diferentes así no hay quien se aclare”.

Como project managers sabemos que es nuestra responsabilidad ejecutar los proyectos con el tiempo, alcance y coste definidos, pero la realidad nos dice que solamente un tercio de los proyectos se pueden considerar exitosos. Esto hace que el trabajo de project manager sea muy frustrante, estresante y muchas veces poco reconocido.

Y aquí es cuando descubres las metodologías ágiles de desarrollo de software, y te das cuenta que es lo que has estado buscando desde hace mucho tiempo, por varios motivos:

El cambio de especificaciones no solamente hay que dejar de intentar evitarlo, sino que además se considera bueno y enriquecedor para el proyecto. A medida que avanza el desarrollo de un proyecto el cliente sabe más sobre él y lo que quiere obtener, y sus peticiones pueden cambiar.
Las metodologías ágiles definen un rol específico que representa al cliente, en el caso de Scrum es el Product Owner. En las metodologías predictivas el cliente solamente se representa mediante el catálogo de requisitos, pero no hay una persona con un rol específico que lleve la voz del cliente.
De todas las funcionalidades que se desarrollan en un proyecto, el 64% no se usa nunca, el 16% se usa raras veces y el 20% restante es verdaderamente útil. Demos prioridad a las tareas que aporten valor al negocio y el resto ya veremos si es realmente necesario implementar.
En la mayoría de proyectos tenemos como condicionante el coste (precio cerrado) y el plazo de entrega, y en muchos también el alcance. Las metodologías ágiles (bien implementadas) gestionan este problema bastante bien.
Porque es el equipo de desarrollo el que decide hasta donde puede hacer en cada iteración, y se compromete a cumplirlo, y ellos son los que más saben del día a día del desarrollo del proyecto.
Porque permite controlar de forma más eficiente las posibles desviaciones del proyecto, haciendo que la vida del gestor de proyecto sea más fácil.
Y por último, aunque con toda seguridad lo más importante, porque la satisfacción del cliente es mayor cuando está involucrado y tiene poder de decidir sobre el proyecto, y además recibe entregables incrementales y perfectamente funcionales de forma periódica.
El carácter latino nos invita además a este tipo de comportamientos. Siempre preferimos empezar a andar y mientras tanto abrir el mapa, y ya vamos viendo poco a poco cómo vamos hacia donde queremos ir. Scrum y otras metodologías ágiles aprovechan este comportamiento en favor del producto final y de la satisfacción del cliente.

No olvidemos que Scrum como tal no define una forma concreta de desarrollar, sino unas serie de mecanismos para organizar equipos de trabajo en entornos ágiles, y de hecho esta metodología de organización de personas se tiene que complementar con otras que son puramente de desarrollo. Scrum habitualmente se combina con eXtreme Programming, pero también da buenos resultados con otras.

Hay gran cantidad de información en Internet sobre Scrum y metodologías ágiles en general, pero yo creo que es de obligada lectura la obra de Henrik Kniberg “Scrum y XP desde las trincheras”, traducida al castellano por uno de los grandes conocedores y “evangelizadores” de la agilidad, Angel Medinilla.

¿Qué otras fuentes de información recomendarías tú?

Suyo afectísimo.

The memory cache on windows eat all the RAM

SYMPTOMS

You experience performance issues in applications and services in various versions of Windows XP, of Windows Vista, of Windows Server 2003, and of Windows Server 2008. Additionally, you notice the following symptoms:

Available memory is almost exhausted.

The system file cache consumes most of the physical RAM.

There is a continuous and high volume of cached read requests to the hard disk.

Back to the top

CAUSE

Memory management in Microsoft Windows operating systems uses a demand-based algorithm. If any process requests and uses a large amount of memory, the size of the working set (the number of memory pages in the physical RAM) of the process increases. If these requests are continuous and unchecked, the working set of the process will grow to consume all the physical RAM. In this situation, the working sets for all the other processes are paged out to the hard disk. This behavior decreases the performance of applications and services because the memory pages are continuously written to the hard disk and read from the hard disk.

This behavior also applies to the working set of the system file cache. If there is a continuous and high volume of cached read requests from any process or from any driver, the working set size of the system file cache will grow to meet this demand. The system file cache consumes the physical RAM. Therefore, sufficient amounts of physical RAM are not available for other processes.

On 32-bit versions of Microsoft Windows operating systems earlier than Windows Vista, the working sets of the system file cache have a theoretical memory limit of less than1 GB. The limitation of the virtual address range prevents the working sets of the system file cache from exhausting the physical RAM.

On 32-bit versions of Windows Vista operating systems, kernel resources are allocated dynamically. The working set of the system file cache increases to consume the virtual address range of the kernel mode at the expense of other kernel resources. The limitation of this memory range is less than 2 GB. If the computer has more than 2 GB of physical RAM, the cache cannot exhaust all the physical RAM. However, the cache can exhaust the virtual address space in the kernel. This can cause allocation failures for other kernel components.

On 64-bit versions of Windows operating systems, the size of the virtual address range is typically larger than the physical RAM. In this situation, the working set for the system file cache can increase to consume most of the physical RAM.

Back to the top

WORKAROUND

To work around this issue, use the GetSystemFileCacheSize API function and the SetSystemFileCacheSize API function to set the maximum or minimum size value for the working sets of the system file cache. The use of these functions is the only supported method to restrict the consumption of physical memory by the system file cache.

The Microsoft Windows Dynamic Cache Service is a sample service that demonstrates one strategy to use these APIs to minimize the effects of this issue.

Installing and using the Microsoft Dynamic Cache Service does not cause the exclusion of support for Microsoft Windows. This service and its source code are provided as an example of how to use the Microsoft supported APIs to reduce the growth of the file system cache.

The service and source code can be downloaded from the following link in the Microsoft Web site:

http://www.microsoft.com/downloads/details.aspx?FamilyID=e24ade0a-5efe-43c8-b9c3-5d0ecb2f39af&displaylang=en

Discurso Álex de la Iglesia

El día de hoy ha llegado porque hace 25 años, doce profesionales de nuestro cine, en medio de una crisis tan grave como la nuestra, caminaron juntos a pesar de sus diferencias. Quiero empezar este discurso felicitando a los fundadores de la Academia.

No sólo ellos, sino todos los que me han precedido en esta institución, vicepresidentes, miembros de las juntas directivas y el conjunto de los académicos, nos han traído esta noche aquí, al Teatro Real, para celebrar el 25 aniversario de la Academia de las Artes y las Ciencias Cinematográficas y la existencia misma de los premios Goya. A todos, muchísimas gracias. Puede parecer que llegamos a este día separados, con puntos de vista diferentes en temas fundamentales. Es el resultado de la lucha de cada uno por sus convicciones. Y nada más. Porque en realidad, todos estamos en lo mismo, que es la defensa del cine.

Quiero por ello felicitar y agradecer a todos los que estáis aquí, por caminar juntos en la diferencia, y hasta en la divergencia. Hacemos mucho ruido, pero es que esta vez, hay muchas nueces. El choque de posturas es siempre aparatoso y tras él surge una nube de humo que impide ver con claridad. Pero la discusión no es en vano, no es frívola y no es precipitada. No podemos olvidar lo más importante, el meollo del asunto. Somos parte de un Todo y no somos nadie sin ese todo. Una película no es película hasta que alguien se sienta delante y la ve. La esencia del cine se define por dos conceptos: una pantalla, y una gente que la disfruta. Sin público esto no tiene sentido. No podemos olvidar eso jamás.

Dicen que he provocado una crisis. Crisis, en griego, significa “cambio” y el cambio es acción. Estamos en un punto de no retorno y es el momento de actuar. No hay marcha atrás. De las decisiones que se tomen ahora dependerá todo. Nada de lo que valía antes, vale ya. Las reglas del juego han cambiado. Hace 25 años, quienes se dedicaban a nuestro oficio jamás hubieran imaginado que algo llamado internet revolucionaría el mercado del cine de esta forma y que el que se vieran o no nuestras películas no iba a ser sólo cuestión de llevar al público a las salas. Intenet no es el futuro, como algunos creen. Internet es el presente. Internet es la manera de comunicarse, de compartir información, entretenimiento y cultura que utilizan cientos de millones de personas. Internet es parte de nuestras vidas y la nueva ventana que nos abre la mente al mundo.

A los internautas no les gusta que les llamen así. Ellos son ciudadanos, son sencillamente gente, son nuestro público. Ese público que hemos perdido, no va al cine porque está delante de una pantalla de ordenador. Quiero decir claramente que no tenemos miedo a internet, porque internet es, precisamente, la salvación de nuestro cine. Sólo ganaremos al futuro si somos nosotros los que cambiamos, los que innovamos, adelantándonos con propuestas imaginativas, creativas, aportando un nuevo modelo de mercado que tenga en cuenta a todos los implicados: Autores, productores, distribuidores, exhibidores, páginas web, servidores, y usuarios.

Se necesita una crisis, un cambio, para poder avanzar hacia un nueva manera de entender el negocio del cine. Tenemos que pensar en nuestros derechos, por supuesto, pero no olvidar nunca nuestras obligaciones. Tenemos una responsabilidad moral para con el público. No se nos puede olvidar algo esencial: hacemos cine porque los ciudadanos nos permiten hacerlo, y les debemos respeto, y agradecimiento. Las películas de las que hablamos esta noche son la prueba de que en este país nos dejamos la piel trabajando. Sin embargo, el mismo esfuerzo o mayor hicieron tantas otras películas que no han llegado a los sobres de las candidaturas. Ellos tambien se merecen estar aqui, porque han trabajado igual de duro que nosotros.

Quiero despedirme en mi última gala como presidente, recordando a todos los candidatos a los Goya tan solo una cosa: qué más da ganar o perder si podemos hacer cine, trabajar en lo que más nos gusta. No hay nada mejor que sentirse libre creando, y compartir esa alegría con los demás. Somos cineastas, contamos historias, creamos mundos para que el espectador viva en ellos. Somos más de 30.000 personas que tienen la inmensa suerte de vivir fabricando sueños.

Tenemos que estar a la altura del privilegio que la sociedad nos ofrece. Yo creo, con toda humildad, que si queremos que nos respeten, hay que respetar primero.

Y por último, me gustaría contarle algo al próximo Presidente de la Academia, que ya me cae bien, sea quien sea: estos han sido los dos años más felices de mi vida. He conocido gente maravillosa de todos los sectores de la industria. He visto los problemas desde puntos de vista nuevos para mí, lo que me ha enriquecido y me ha hecho mejor de lo que era. He comprobado que trabajar para los demás es una experiencia extraordinaria por muy duro que resulte en un principio, y sobre todo: han pasado 25 años muy buenos, pero nos quedan muchos más, y seguro que serán mejores.

SONY PS3

http://crysol.org/es/node/1448

Interesantísimo artículo publicado en crysol

Si los ingenieros de tu empresa son unos inútiles: contrata buenos abogados

:: historia Mié, 2011-01-12 16:26 — int-0

Hola buenas, hoy voy a hablaros sobre un tema que vengo siguiendo desde hace tiempo relativo a la libertad de los usuarios sobre los cacharros que se compran. Por poner un nombre os hablaré de Sony y de la PS3.

Sony y su PS3

Todos aquellos que tengáis una PS3 (y la uséis) os habréis dado cuenta que se trata de un "cacharro" bastante jugoso y lleno de posibilidades. Cuando salió al mercado Sony estaba dispuesto a que la gente hiciera buen uso de él mediante una increíble "feature" llamada OtherOS. Además de esa "feature" se incluían otras como: compatibilidad con PS1 y compatibilidad con PS2 (primero por HW y posteriormente por SW). Pues bien... de repente en una actualización desaparece la compatibilidad con PS1 y PS2 (de aquellas consolas que lo hacían por SW). Se supone que las actualizaciones deben añadir funcionalidades o corregir errores. Desde luego no creo que emular el hardware de una PS2 sea un error.

La gente inquieta (que forman el 90% de la llamada scene) vivían alegres y felices con el OtherOS ya que permitía usar la consola con los propósitos originales de Sony además de poder hacer lo que tú quisieras con ella sin incurrir en la ilegalidad. No todo era color de rosa: desde OtherOS se vetaba el acceso a un SPU (uno de los procesadores del sistema) y desde luego nada de RSX (el chip gráfico y de sonido denominado "Sintetizador de Realidad"). Con esto se aseguraban que nadie fuera a sacar juegos para el OtherOS que compitiesen con los juegos "habituales" de PS3, es decir, los de empresas licenciadas que habrían pagado una pasta a Sony para que esto fuese así.

Y allí donde alguien pone una barrera alguien desea saltarla.

Apareció un individuo llamado Geohot (conocido por realizar el primer jailbreak de iPhone) que mediente un simple puente en la placa de la consola era capaz de acceder a toda la memoria de la consola, es decir, dentro y fuera del OtherOS. Imaginad que desde la máquina virtual de Java pudiérais acceder a direcciones de memoria del sistema real... Ese avance permitió acceder al RSX y por tanto a una futura implementación de OpenGL dentro del OtherOS que usase el RSX... esto resultó inadmisible para Sony que decidió cortar por lo sano: una actualización del firmware eliminaba la opción OtherOS de la consola. Una opción que aparecía en la misma publicidad de las consolas hasta el momento vendidas. A todas luces esto es ilegal (o al menos según la ley europea) y mucha gente fue la que intentó interponer demandas conjuntas contra Sony. Tal revuelo se formó que Sony decidió hacer frente a las críticas: "que los clientes presenten reclamaciones a los vendedores". Impresionante: evitan a los clientes y "enmarronan" a quien vende su producto...

Con la eliminación del OtherOS llegó la tormenta: demasiada gente muy curiosa ahora no podía usar la PS3 como ellos querían, de hecho como Sony había dicho en un principio que se podía usar. Así la gente comenzó a mirar "dentro" de la (hasta ese momento) "consola más segura del mercado". Y apareció el primer bug: una filtración de un manual de Sony revelaba que la consola, antes de arrancar, podía autenticarse con un dispositivo especial mediante el USB de forma que en el servicio técnico pudieran trabajar con ella, arreglarla, restaurarla, etc. En este proceso de autenticación Sony cometió un error en la reserva de memoria de los descriptores USB. Si el dispositivo que se enchufaba pedía tamaños extravagantes para alojar descriptores de dispositivo, el driver símplemente lo hacía. Mediante un ataque de heap overflow se consiguió inyectar código en la consola antes de que arrancase el GameOS. Las primeras copias de seguridad de juegos podían empezar a usarse después de varios años de vida de la consola. Nunca antes se había tardado tanto en "piratear" una consola, el motivo símplemente era que los "curiosos" podían usar la consola para sus propósitos sin necesidad de "cacharrear" nada.

Aquí el "castigo" de Sony también fue ejemplar: la siguiente actualización de firmware corregía el bug en el driver de USB, además (y de regalo) impedía usar ningún dispositivo USB que no fuera oficial: ni mandos para la consola no oficiales, ni adaptadores de mandos de PS2 a PS3, ni adaptadores de memory card de PS2 a PS3... nada. Si esto no es una acción monopolística, ¿entonces qué es?.

Hasta ahora empezaba el clásico juego de sceners encuentran bugs, empresa publica firmware que corrige bugs. Ya era posible arrancar copias de seguridad pero resultaba un engorro, los juegos nuevos eran más difíciles (o imposibles) de arrancar y era imposible usar la conexión a internet o los servicios del PSN. Pero había un problema: usar GNU/Linux seguía siendo imposible y la alternativa AsbestOS (aplicación casera) resultaba engorrosa de usar. Entonces llegó el 27C3 y su sección Console Hacking 2010 titulada: "Sony PS3: Epic Fail".

Los autores de AsbestOS no estaban dispuestos a renunciar al OtherOS así que se fijaron como objetivo crear el suyo propio. Para ello se pusieron a investigar sobre los últimos bugs de la consola y descubrieron alguno nuevo. En el congreso dieron una animada y divertida charla donde presentaron su trabajo. Fue tal la expectación que resultaba casi imposible conectar a los servidores dedicados del congreso. Al final de la charla revelaron el "Epic Fail" de Sony que explico a continuación:

Imaginemos que disponemos de un sistema de autenticación basado en clave asimétrica. Dentro de la consola, en algún lugar, se encuentra la clave pública. Los programas que se cargan en la consola se cifran mediante una clave privada en las oficinas de Sony. Ambas claves, la privada y la pública, se generaron a partir de una clave maestra. Para mantener la clave maestra a salvo (esta clave se encuentra en las oficinas de Sony bajo máxima seguridad) se generan los pares de claves mediante una función de ofuscación y un número cualquiera. De esta manera, por muchas claves que conozcamos nos será imposible (o computacionalmente imposible) calcular la clave maestra. Y aquí está el problema: los ingenieros de Sony utilizaron SIEMPRE el mismo número aleatorio en lugar de calcular uno cada vez. Si eliminamos la aleatoriedad de la función de ofuscación la convertimos ahora en una constante y por tanto fácilmente computable. Buscando dentro del firmware de la consola las claves públicas podremos recolectar las suficientes como para poder calcular las claves privadas y finalmente la maestra.

Bueno, las consecuencias de esto no se hicieron esperar: se publicó en Google Docs una hoja de cálculo con todas las claves públicas y privadas del sistema, así como la clave maestra. El equipo de AsbestOS sólo se ocupó de la parte necesaria para crear un paquete con firma oficial que permita volver a cargar Linux en la consola (está actualmente en desarrollo) pero abrió la puerta a todos aquellos que deseaban "customizar" el firmware de la consola. Ahora cualquiera podría crear firmwares o paquetes para GameOS con firma oficial. De hecho existen herramientas caseras para hacer esto.

Si os preguntáis qué puede hacer Sony para evitar esto la respuesta es fácil: desde el punto de vista técnico nada, porque si publicasen un firmware con una nueva clave maestra todo el software publicado hasta el momento dejaría de funcionar y si tiene una clave nueva pero se permite la antigua seguiríamos igual. Así que Sony ha decidido ponerse las pilas y ha movido baza: pretende llevar a juicio a todas las personas que han intervenido de alguna forma en el desarrollo de la scene de PS3. La lista de denuncias contra los "hackers" es increíble, incluso acusan de extorsión.

Ahora mi opinión: un error tan grave en el sistema va a intentar ser corregido en los tribunales. Los mismos tribunales que han permitido a Sony eliminar features de su consola. Y es que Sony hace muy buenos productos, pero los gestiona muy mal debido a su grandísimo afán recaudatorio. Intenta exprimir al máximo a todos sus usuarios llegando incluso a emplear técnicas ilegales para ello (¿no recordáis ya el rootkit de Sony Music?). Así que Sony, va siendo hora de que aprendas que la gente compra las cosas para usarlas como más les guste y que a nadie le gusta que le fuercen a nada y menos pagando por ello. La piratería de vuestra consola la creásteis vosotros al piratearnos a nosotros el OtherOS. Pero no aprenderán...

Si os preguntáis qué les va a pasar a los "hackers", bueno, GeoHot no violó ningún término de uso puesto que su aplicación para extraer las claves corría dentro del OtherOS. Por otro lado, Marcan, principal investigador dentro de AsbestOS (grupo Overfl0w) es español y aquí la ley le ampara a él puesto que nunca aceptaron donaciones y su trabajo únicamente sirve para correr Linux dentro de la consola.

Si aún no os habéis aburrido con todo este rollo, aquí van algunos enlaces interesantes:

Charla Console Hacking del Caos Congress 2010: http://events.ccc.de/congress/2010/Fahrplan/events/4087.en.html

Sony toma acciones legales contra sceners: http://www.ps3news.com/PS3-Hacks/sony-takes-legal-action-against-infamou...

Respuesta a Javier Bardem

Hay explicaciones clásicas muy buenas como la de compartir una manzana.

"Si comprato una manzana contigo, como media manzana. Pero si compato una idea contigo, tu y yo tenemos una idea, no dos medias ideas"

Esta respuesta a un comentario tonto de Javier Bardem es otra reflexión muy bien planteada

http://www.meneame.net/c/7526472

Javier Bardem: Dejémonos de estupideces, ¡es robar!

#63 Pongamos el mismo ejemplo.

Javier Bardem quiere «comprar un tomate fresco». Para usar el paralelismo con la industria cultural, Javier debería acudir a una tienda en la que tras pasar por sucesivas manos, el tomate ha incrementado su valor de manera artificial, repercutiendo en el horticultor en menos del 0,1 % de su valor de venta. Son otros, los intermediarios, los que han cobrado más, en muchos casos tan solo por cambiar la pegatina que viene puesta en el tomate. Algo que, por desgracia, no dista mucho de la realidad del mercado de la agricultura --y de la pesca, y de la ganadería...--.

Pero ahora viene la gracia. Javier Bardem no puede compartir ese tomate que acaba de comprar con nadie más, pues de lo contrario la Sociedad General de Agricultores y Especuladores se cabreará con él y lo llamará ladrón: «¡Quien quiera un tomate que se lo compre! ¿Qué es eso de compartir?».

Tampoco puede alterarlo en cualquier forma que no haya sido expresamente autorizada por el horticultor. De hecho, su intención de usarlo para hacer gazpacho se considera un uso no autorizado, y la Sociedad General de Agricultores y Especuladores la condena, llegando a denunciar al comprador si se hace pública la manipulación no autorizada: «El gazpacho, como resultado de la manipulación del tomate entre otros productos, es algo que sólo nosotros, como creadores del tomate original podemos realizar, ya que ese derecho es nuestro. Cualquier manipulación realizada por terceros sin nuestra autorización es una violación de nuestros derechos, y debe ser castigada».

Para colmo, Javier Bardem tampoco puede comerciar con el tomate que acaba de comprar. Si fuera el caso de que tuviera un restaurante donde sirviera ensaladas de tomate --plato que debería contar con la autorización de la Sociedad General de Agricultores y Especuladores--, debería pagar otra vez al horticultor por el lucro cesante que le supone que los clientes de su restaurante vayan a comer un tomate allí, en lugar de comprar otro para ellos. Incluso si el horticultor acuerda no cobrar por este uso, la Sociedad General de Agricultores y Especuladores le cobrará una compensación por tal uso no autorizado.

Por si esto fuera poco, al día siguiente Javier Bardem descubre que tiene que seguir pagando por el tomate que compró ayer, pues los derechos que reconocen el esfuerzo del horticulor estipulan que hay que pagarle por este trabajo hasta más allá de su muerte. Al fin y al cabo él trabajó para producir ese tomate, él plantó la semilla, y día tras día cuidó del crecimiento de la planta, alimentándola cuando lo necesitaba, protegiéndola cuando se debía, hasta el momento de poder recoger su fruto: el tomate. Y ese trabajo debe ser recompensado toda la vida, porque al fin y al cabo, una vez que Javier Bardem ha consumido ese tomate, su organismo se ha beneficiado de él, y ese beneficio para Javier Bardem puede durar años.

Por supuesto este pago Javier Bardem no lo tiene que realizar directamente. No es un impuesto, sino un cobro de derechos, en lo que todo aquello que esté relacionado con el tomate que compró ayer incluirá el pago al horticultor.

De hecho, para proteger el trabajo del horticultor, se ha prohibido que cualquiera pueda producir tomates iguales o razonablemente parecidos a los que compró al horticultor. Por eso no se venden semillas de tomates de ese tipo. Y como aun así es posible que Javier Bardem las obtenga del propio tomate, para reducir el perjuicio ocasionado al horticultor, la Sociedad General de Agricultores y Especuladores ha logrado que se apruebe la inclusión de un canon compensatorio en todos aquellos productos que pudieran facilitar que cualquiera produjera tomates similares a título privado. Este canon se puede encontrar en el abono, el agua, las mangueras, las regaderas, los maceteros, los tiestos, los sistemas de aspersión, las palas, los rastrillos, las carretillas, las azadas y en general cualquier herramienta de agricultura y jardinería, los plásticos y estructuras de posible uso para la construcción de invernaderos, etc.

Por suerte para Javier Barden hay un grupo de personas que consideran que esta situación es un abuso, y han creado sus propias huertas, donde venden los tomates sin todas las restricciones que se han citado, permitiendo su uso y consumo como mejor le parezca al comprador, y destinando prácticamente todo el dinero cobrado al propio horticultor.

Otras personas han creado huertas públicas, donde el cuidado y el mantenimiento de los productos de la huerta es responsabilidad solidaria de todos, y todos pueden disfrutar libremente de los resultados.

En algunos casos las tomateras son el producto de las semillas de los tomates obtenidos a través de la compra a los horticultores tradicionales, y eso ha cabreado a la Sociedad General de Agricultores y Especuladores, porque dicen que eso es piratería, que se están aprovechando del trabajo de sus horticultores, e incluso están en algunos casos obteniendo beneficios por ello.

Así, la Sociedad General de Agricultores Y Especuladores, junto con otros colectivos afectados como Proagripescae, han denunciado en varias ocasiones a los que mantienen dichas huertas. En algunos casos incluso han tratado de crear la idea de que su actividad es más delictiva si cabe porque cobran por otros servicios a quienes acceden a sus huertos a por los productos que allí se disponen gratuitamente.

Por fortuna los jueces, que aun tienen algo de sentido común, siempre han sentenciado a favor de las personas encargadas de las huertas. Esto ha molestado a las sociedades mencionadas, que han movilizado a los horticultores para que protesten y presionen con el objetivo de aprobar una ley que permita cerrar esas huertas sin necesidad de que lo ordene un juez.

¿Qué piensa Javier Bardem de que un colectivo que es parte del conflicto pueda decidir si cierra o no una huerta pública sin requerir la acción de un juez?

crear herramientas de programación

El balace de las herramientas que me he estado preparando o estudiando

en estas últimas semanas para programar, es buenísimo y creo que con

el tiempo se percibirá aún mejor.

He estado programando al mismo tiempo en c++, python, generando

gramáticas para mis dos lenguajes y defininiendo con los mismos.

Las herramientas están maduras. Aunque el generador de mensajes y el

warper del sistema de comunicaciones no están acabados, todo está lo

suficientemente avanzado como para demostrar que son piezas muy

útiles.

Y eso me lo he demostrado haciendo programas de verdad.

La situación es clara y sencilla, pero hacerlo y conseguir un punto de

maduración de las herramientas adecuado, es duro.

1.- La productividad al escribir código es importante

2.- Es aún más importante el poder mantener y ampliar el código

¿Cómo conseguir estos dos puntos? también es fácil saberlo.

1. Reutilización de código.

2. Hay que separar el qué se quiere hacer del cómo.

3. Sistemas separados en piezas definiendo qué hace cada pieza, su

entrada, su salida y su diagrama de estados.

4. Las piezas se conectan con un middleware.

5. Diseñar sistemas distribuidos, lo que implica que sean asíncronos

(lo que aporta también un paralelismo potencial y por tanto una

escalalibidad enorme).

6. El código corto, es más fácil de leer y por tanto, de mantener y ampliar.

7. Tratar de separar lo mínimo la documentación y el código.

Las herramientas y lenguajes de programación no ayudan mucho en ningún punto.

1. Reutilización de código.

Es lo que todos los lenguajes pretenden y dicen conseguir.

Pero sólo se consigue en lenguajes de tipado dinámico.

En los lenguajes de tipado estático, se consigue poco o son técnicas

complejas que no se suelen dominar ni utilizar.

Exceptuando contadísimos casos, tratar de hacer código realmente

reutilizable es muy costoso en rendimiento y complejo de escribir.

2. Hay que separar el qué se quiere hacer del cómo.

Si eres MUY metódico y MUY organizado, puedes intentarlo con los

lenguajes habituales (C++, C, Java, C#, VisualBasic, etc...)

Los lenguajes imperativos se centran en el cómo y el fracaso en la

separación dle qué y el cómo es casi seguro.

Para esto es mucho mejor utilizar lenguajes declarativos.

Si es así, ¿porqué los lenguajes declarativos están infinitamente

menos extendidos?

No es del todo cierto. Entre programadores de categoría, los lenguajes

declarativos son muy utilizados en tareas complejas.

Pero los programadores de bajo nivel, que somos una enorme mayoría

(más de 95%) sólo sabemos trabajar con lenguajes imperativos.

3. Sistemas separados en piezas definiendo qué hace cada pieza, su

entrada, su salida y su diagrama de estados.

Aquí no hay ninguna ayuda.

4. Las piezas se conectan con un middleware.

Hay unos cuantos middlewares, hay que aprender y utilizarlos.

Los lenguajes de propósito general, se pueden conectar a un middleware

o a crear ventanas, o a conectar con una base de datos...

Lo malo es que no son buenos haciendo ninguna de esas cosas

5. Diseñar sistemas distribuidos, lo que implica que sean asíncronos

(lo que aporta también un paralelismo potencial y por tanto una

escalalibidad enorme).

Las hebras y el paralelismo dentro de un proceso son una trampa

mortal. No utilizar salvo situaciones muy específicas y justificadas.

Sólo algunos lenguajes declarativos tienen una buena solución para este punto.

El lenguaje de referencia en este punto es Erlang

6. El código corto, es más fácil de leer y por tanto, de mantener y ampliar.

Los lenguajes de propósito general, también son un enemigo de este punto.

Los programadores de bajo nivel, símplemente nos acostumbramos a que

las cosas son así y nos cuesta imaginar que hay otras soluciones

infinitamente mejores.

7. Tratar de separar lo mínimo la documentación y el código.

Si separamos el qué del cómo y tenemos una buena sintáxis (sencilla y

clara), conseguido.

Inconvenientes, la separación en lenguajes imperativos es casi imposible.

La sintáxis clara para un problema específico utilizando un lenguaje

de propósito general... complicado

Lo que he preparado (en un estado muy avanzado y probado con un caso

real no trivial) ayuda muchísimo (si no da una solución decente) en

todos estos puntos.

¿Cómo?

Para empezar con un par de lenguajes específicos del problema a resolver.

Uno es la gestión del estado de la aplicación. BASTA YA DE HACERLO

MANUALMENTE y lo que es peor, improvisar una solución fácil de

escribir pero imposible de leer cada día.

Otro lenguaje para conectar nuestro lenguaje de propósito general, en

este caso C++ con la entrada y salida y por tanto, con el middleware.

En estos lenguajes, sólo se dice el qué y de forma muy concisa. No son

sólo código que se "compilará" para generar un programa, son

documentación.

Estoy contento porque el objetivo era ambicioso y complejo (montar y

probar un sistema así no era nada fácil para mi) pero he pasado el

punto de inflexión crítico.

De haberme quedado un poco más atrás, todo el trabajo podría haber

quedado en un gran esfuerzo pero una idea no utilizable

Mis 10 comandos más utilizados

ejecutando la siguiente línea en la consola...

history | awk ‘{print $2}’ | sort | uniq -c | sort -rn | head -10

Te sale la lista de comandos que más utilizas

Mi resultado en el SO en el que desarrollo es...

178 ls

176 cd

136 make

59 git

52 rm

35 bg

33 valgrind

25 find

24 ./qpid-config

24 kcachegrind

Nada raro ni especial.

ls ver el contenido de directorios

cd cambiar de directorio

make compilar

git el gestor de versiones que utilizo

rm borrar

bg, mandar a segundo plano

valgrind máquina virtual para verificación de programas y rendimiento

find buscar algo, aunque en realidad lo utilizo combinado con xargs

para ejecutar un comando en varios ficheros

qpid-config, es una herramienta de configuración del middleware con el

que estoy trabajando

kcachgrind una herramienta visual para ver algunos de los brutales

informes generados por valgrind (temas de rendimiento, que empecé a

mirar hacer 3 días)

¿Y a ti que te sale?

Herramientas de programación

El balace de las herramientas que me he estado preparando o estudiando

en estas últimas semanas para programar, es buenísimo y creo que con

el tiempo se percibirá aún mejor.

He estado programando al mismo tiempo en c++, python, generando

gramáticas para mis dos lenguajes y defininiendo con los mismos.

Las herramientas están maduras. Aunque el generador de mensajes y el

warper del sistema de comunicaciones no están acabados, todo está lo

suficientemente avanzado como para demostrar que son piezas muy

útiles.

Y eso me lo he demostrado haciendo programas de verdad.

La situación es clara y sencilla, pero hacerlo y conseguir un punto de

maduración de las herramientas adecuado, es duro.

1.- La productividad al escribir código es importante

2.- Es aún más importante el poder mantener y ampliar el código

¿Cómo conseguir estos dos puntos? también es fácil saberlo.

1. Reutilización de código.

2. Hay que separar el qué se quiere hacer del cómo.

3. Sistemas separados en piezas definiendo qué hace cada pieza, su

entrada, su salida y su diagrama de estados.

4. Las piezas se conectan con un middleware.

5. Diseñar sistemas distribuidos, lo que implica que sean asíncronos

(lo que aporta también un paralelismo potencial y por tanto una

escalalibidad enorme).

6. El código corto, es más fácil de leer y por tanto, de mantener y ampliar.

7. Tratar de separar lo mínimo la documentación y el código.

Las herramientas y lenguajes de programación no ayudan mucho en ningún punto.

1. Reutilización de código.

Es lo que todos los lenguajes pretenden y dicen conseguir.

Pero sólo se consigue en lenguajes de tipado dinámico.

En los lenguajes de tipado estático, se consigue poco o son técnicas

complejas que no se suelen dominar ni utilizar.

Exceptuando contadísimos casos, tratar de hacer código realmente

reutilizable es muy costoso en rendimiento y complejo de escribir.

2. Hay que separar el qué se quiere hacer del cómo.

Si eres MUY metódico y MUY organizado, puedes intentarlo con los

lenguajes habituales (C++, C, Java, C#, VisualBasic, etc...)

Los lenguajes imperativos se centran en el cómo y el fracaso en la

separación dle qué y el cómo es casi seguro.

Para esto es mucho mejor utilizar lenguajes declarativos.

Si es así, ¿porqué los lenguajes declarativos están infinitamente

menos extendidos?

No es del todo cierto. Entre programadores de categoría, los lenguajes

declarativos son muy utilizados en tareas complejas.

Pero los programadores de bajo nivel, que somos una enorme mayoría

(más de 95%) sólo sabemos trabajar con lenguajes imperativos.

3. Sistemas separados en piezas definiendo qué hace cada pieza, su

entrada, su salida y su diagrama de estados.

Aquí no hay ninguna ayuda.

4. Las piezas se conectan con un middleware.

Hay unos cuantos middlewares, hay que aprender y utilizarlos.

Los lenguajes de propósito general, se pueden conectar a un middleware

o a crear ventanas, o a conectar con una base de datos...

Lo malo es que no son buenos haciendo ninguna de esas cosas

5. Diseñar sistemas distribuidos, lo que implica que sean asíncronos

(lo que aporta también un paralelismo potencial y por tanto una

escalalibidad enorme).

Las hebras y el paralelismo dentro de un proceso son una trampa

mortal. No utilizar salvo situaciones muy específicas y justificadas.

Sólo algunos lenguajes declarativos tienen una buena solución para este punto.

El lenguaje de referencia en este punto es Erlang

6. El código corto, es más fácil de leer y por tanto, de mantener y ampliar.

Los lenguajes de propósito general, también son un enemigo de este punto.

Los programadores de bajo nivel, símplemente nos acostumbramos a que

las cosas son así y nos cuesta imaginar que hay otras soluciones

infinitamente mejores.

7. Tratar de separar lo mínimo la documentación y el código.

Si separamos el qué del cómo y tenemos una buena sintáxis (sencilla y

clara), conseguido.

Inconvenientes, la separación en lenguajes imperativos es casi imposible.

La sintáxis clara para un problema específico utilizando un lenguaje

de propósito general... complicado

Lo que he preparado (en un estado muy avanzado y probado con un caso

real no trivial) ayuda muchísimo (si no da una solución decente) en

todos estos puntos.

¿Cómo?

Para empezar con un par de lenguajes específicos del problema a resolver.

Uno es la gestión del estado de la aplicación. BASTA YA DE HACERLO

MANUALMENTE y lo que es peor, improvisar una solución fácil de

escribir pero imposible de leer cada día.

Otro lenguaje para conectar nuestro lenguaje de propósito general, en

este caso C++ con la entrada y salida y por tanto, con el middleware.

En estos lenguajes, sólo se dice el qué y de forma muy concisa. No son

sólo código que se "compilará" para generar un programa, son

documentación.

Estoy contento porque el objetivo era ambicioso y complejo (montar y

probar un sistema así no era nada fácil para mi) pero he pasado el

punto de inflexión crítico.

De haberme quedado un poco más atrás, todo el trabajo podría haber

quedado en un gran esfuerzo pero una idea no utilizable

Además he unido esto a la utilización de un middleware nuevo para mi

(y para todos) llamado qpid y basado en la especificación abierta AMQP.

Y también a la creación de interfaces visuales con Qt, que tampoco tengo

mucha experiencia.

citas de Carl Sagan

http://alt1040.com/2010/11/carl-sagan-citas-frases


Afirmaciones extraordinarias requieren siempre de evidencia extraordinaria.

Si quieres salvar a tu hijo del polio puedes rezar o puedes vacunarlo… Aplica la ciencia.

Vivimos en una sociedad profundamente dependiente de la ciencia y la tecnología en la que nadie sabe nada de estos temas. Ello constituye una fórmula segura para el desastre.

El primer pecado de la humanidad fue la fe; la primera virtud la duda.

A veces creo que hay vida en otros planetas y a veces creo que no. En cualquiera de los dos casos la conclusión es asombrosa.

La ausencia de prueba no es prueba de ausencia.

Para hacer una tarta de manzana primero tienes que crear un universo.

En algún sitio algo increíble espera ser descubierto.

Somos el medio para que el Cosmos se conozca a sí mismo.

El universo no fue hecho a medida del hombre; tampoco le es hostil: Es indiferente.

La ciencia es más que un simple conjunto de conocimientos: es una manera de pensar.

Somos polvo de estrellas.

En la Ciencia la única verdad sagrada, es que no hay verdades sagradas.

Hemos averiguado que vivimos en un insignificante planeta de una triste estrella perdida en una galaxia metida en una esquina olvidada de un universo en el que hay muchas mas galaxias que personas.

La Tierra es un lugar más bello para nuestros ojos que cualquiera que conozcamos. Pero esa belleza ha sido esculpida por el cambio: el cambio suave, casi imperceptible, y el cambio repentino y violento. En el Cosmos no hay lugar que esté a salvo del cambio.

optimización c++

http://en.wikibooks.org/wiki/Optimizing_C%2B%2B

kwallet

Me gusta mucho kwallet

El inconveniente es que sólo es válido para aplicaciones de kde, pero es un gran programa


kwallet se encarga de guardar las contraseñas de todos los programas de kde


Eso es bueno, porque si cada programa lo hace por su cuenta, tienes varios inconvenientes


¿Lo hace bien?
Quiero decir, ¿guarda las contraseñas encriptadas o en texto plano?
Alguno podría hacerlo bien y otro mal, quien sabe.

¿Dónde se guardan?
Cada uno lo guardará donde le convenga

¿Dónde y cómo se administran las contraseñas guardadas?
Si quieres ver, borrar, modificar una contraseña, tendrás una forma de hacerlo por cada programa (si es que la tienes)


kwallet te ofrece un lugar de acceso a tus contraseñas, protegido con una única contraseña


Puedes tener más de un wallet, pero yo nunca lo he hecho.

El caso, es que un programa kde que requiera contraseña, le informará a kwallet y este preguntará al usuario si quieres utilizar kwallet para gestionar la contraseña de ese programa


Dependiendo del nivel de seguridad, quizá convenga cambiar algunas configuraciones por defecto de kwallet


Si no me equivoco, kwallet viene configurado para que la "wallet" (cartera) no se cierre nunca una vez que se ha abierto.
Sería más razonable que se cierre después de 15 minutos de inactividad de la misma, por ejemplo.
Eso habría que combinarlo con un bloqueo de pantalla cada x minutos también por inactividad

Hay otras opciones sencillas de entender en la solapa de configuración


Un caso práctico.


En el trabajo, en la intranet (recién estrenada), me asignaron un usuario y una contraseña.
La contraseña caduca y tengo que meter una nueva que cumpla unas condiciones.
Cuando la contraseña caduca, me pide la anterior y la nueva. Pero nunca recuerdo la anterior porque el navegador (utilizando kwallet) la recuerda por mi.
Pero a la hora de cambiar la contraseña, los id de los cuadros de entrada están cambiados (eso es un detalle no relevante de mala programación) y me obliga a introducir una contraseña que no recuerdo.

La solución es fácil.

Me meto en kwallet, la busco, copio, pego y a correr


Tengo suscripciones a varios foros de cuestiones técnicas, contraseñas de acceso remoto a equipos windows, acceso ftp, etc...

Todas están en mi kwallet

Supongamos que cambias de ordenador y no recuerdas la contraseña de uno de los foros a los que te has suscrito
¿Te das de alta otra vez?

Pues no, abres el kwallet, lo buscas y punto.
Es más, puedes exportar (inseguro pero práctico, hacer con cuidado) toda la lista de contraseñas a un xml para verlas o simplemente importarlas



kwallet es genial, pero tiene algún INCONVENIENTE


El gran inconveniente, es que es para apliaciones de kde

Firefox, chromium-browser y los programas de gnome no lo utilizan

Lo que me disgustaba mucho del navegador arora (que está hecho con qt, pero no es kde) es que no se integraba con kwallet


¿Existe algo parecido en windows o gnome?


Si no es así, YA VA SIENDO HORA

Igual que en su día el sistema de comunicación de kde dcop/kparts fue un éxito superior a bonobo de gnome (que era una copia de COM de windows y ambos demostraron ser muy inferiores a dcop/kparts de kde) y la comunidad se planteó unificar en un único sistema de comunicación (llamado dbus), se podrían plantear tener un repositorio de contraseñas de escritorio común.

Por un kwallet único para todos


Mientras tanto, no tengo mucho problema porque utilizo mayoritariamente aplicaciones de kde




saludos

Fecha del ordenador

Se puede saber la fecha de un ordenador por la fecha de la BIOS

sudo dmidecode -s bios-release-date