@iamemhn

EM Hernández-Novich

Ask @iamemhn

Sort by:

LatestTop

Previous

42, 42 siempre es la respuesta!

No siempre. Mis estudiantes lo saben. Pero a veces no lo saben.
No obstante, 42 es una respuesta sin pregunta. A veces la respuesta es 23.
Y la mayoría de los casos, la respuesta es 無

Por qué hay tantos artículos, pasiones, FUD y posiciones encontradas en relación a systemd? y en particular a su adopción en Debian? en qué creer si cada bando dice que el otro miente?

La filosofía Unix es que cada herramienta debe ser buena haciendo una cosa, y sólo una cosa, muy bien, siendo capaz de comunicarse con otras herramientas. La metodología para hacer herramientas en Unix indica que deben escribirse de manera que sean transparentes, silenciosas a menos que haya problemas, con instrumentación y conectables. La práctica en Unix requiere que muchos usuarios puedan tener ambientes de trabajo diferentes, y que sean independientes de la operación base.
systemd rompe con la filosofía porque trata de hacer de todo, y no sólo deja mucho que desear en cómo lo hace, sino que es poco transparente, está pobremente instrumentado e invade (de mala manera) a otras herramientas. Si se quiere tener una máquina con varios ambientes de trabajo que no sean GNOME, systemd molesta más de lo que ayuda.
Para mucha gente systemd es el "centralizador" de operaciones y eso les gusta. No es casualidad que la mayoría de los defensores de systemd suele ser gente que no ha tenido que administrar sistemas complejos y está orientada a "la experiencia del usuario".
Hay gente que argumenta su pro o contra en relación a systemd usando toda suerte de falacias argumentales ("malo porque no es tradicional", "bueno porque es revolucionario", "malo porque obliga a GNOME", "bueno porque permite diversidad"...) pero no se enfocan en las características técnicas y la práctica de administración de sistemas. Así, discusiones entre gafos siempre habrá. Los que tienen que lidiar con los deseos de los gafos tienen que aprenderlo o mejorarlo.
No es la primera vez que aparecen herramientas deleznables en el Software Libre. Se adoptan por un rato y luego desaparecen bajo su propio peso. Me parece que systemd sufrirá ese destino.
El sistema de arranque de BSD es demasiado simplista, y SystemD demasiado elaborado. El arranque SYSV, con declaración de dependencias, me parece más que suficiente. Ojalá las contadas ideas interesantes de SystemD puedan ser absorbidas.

View more

Liked by: Marcos Mora

¿Que informáticos o computista te han inspirados o han influenciado en tu carrera profesional ?

Ordenados alfabéticamente según sus apellidos.
Jorge Baralt, Enzo Chiariotti, Edsger Dijkstra, Patrick O'Callaghan, Jesús Ravelo, Roger Soler, Larry Wall, Cristina Zoltán.
Mención especial para la "esposa (computista de la USB) de un jefe", que después de indicarme usuario y clave, me dijo "si quieres llegar lejos, rápido, léete todos los manuales despacio; ahora, si quieres ser como el resto, dale copiando y pegando, y preguntando gafedades" (el primer día que me tocó usar Unix, en 1988).

Related users

Te gusta hora de aventuras?

“Sometimes you want someone and you want to kiss and be with them, but you can’t because responsibility demands sacrifice.” — Princess Bubblegum

Me gustaría aprender acerca de diseño, mantenimiento y configuración de redes de computadoras. ¿Por dónde me recomiendas comenzar? ¿Alguna bibliografía en particular o sitio web?

La capa física nunca me ha interesado, así que no puedo orientarte. En términos del sistema de operación y aplicaciones, los capítulos del RUTE relacionados con redes son básicos. Después tendrías que aprender a construir firewalls por filtrado de paquetes, IPv6 y protocolos de enrutamiento -- hay algunos 'HOWTO' para eso que están mencionados en el RUTE.

Master, is it time to learn Perl6 and drop Perl5?

Si dominas Moose y los modismos que salieron con Perl 5.22, ya sabes todo lo necesarios para usar Perl 6; sólo tienes que acostumbrarte a la nueva sintaxis.
Perl 5 va a seguir siendo útil por mucho tiempo, hasta que Perl 6 sea igual o más rápido al ejecutar y se estabilicen las herramientas alrededor. Nota que está por comprobarse en producción la eficiencia con la cual Perl 6 puede invocar a los módulos Perl 5 disponibles en CPAN, así que hasta que sean portados.
De modo que sí, es hora de aprender Perl 6, pero no es sabio abandonar Perl 5.
Liked by: Kalim Al Razif

¿Qué picante te ha regañado?

Hace veinte años, en Perú, comí una rodaja de rocoto crudo creyendo que era un pimentón rojo. Fue la primera vez que comí picante fuerte, más allá del ocasional Tabasco. Nada agradable y frustrante porque, en mi ignorancia, quise apagar el inexistente fuego con líquidos y pan, siendo absolutamente inútil. No fue un regaño, sino una tunda.
A partir de ese momento comencé a estudiar y apreciar la comida picante, aumentando la tolerancia paulatinamente después de comprender que no te estás quemando, sino que la capsaicina está jugando con tu cerebro. Combina eso con temporadas en Perú, México y la comida indonesia y china sichuan en Amsterdam, que sirvieron de entrenamiento para que no me volviera a molestar el picante.
Por otro lado, y de nuevo gracias al estudio, comprendí que debía evitar los picantes cuyo sustrato es graso (aceite vegetal denso o grasa láctea) porque esos si molestan el tracto gastrointestinal ya que superan el estómago. De modo que los picantes criollos en base a suero, o que maceran el ají en grandes cantidades de aceite, ni siquiera los pruebo.
Así, desde entonces, consumiendo picantes cuyo sustrato es jugo de fruta, extracto de ajo, agua, o picadillo de especies sin aceite, he llegado a consumir picantes en el orden de medio millón de Scovilles [1], sin molestia.
Ya he comido rocoto crudo (80k Scoville en el mejor caso) y me atrevería a probar un Habanero, pero ni Moruga ni Ghost Peppers, porque no van a tener sabor a nada: son prácticamente esponjas con capsaicina y eso no me resulta atractivo. Siempre tengo un surtido de salsa picante en diferentes tenores. Desafortunadamente se me terminó la "Dave Ultimate Insanity Sauce" (250k Scoville) así que tengo que aguantar con una "Baron West Indies Hot Sauce" (175k Scoville) mientras repongo.
Los sabores fuertes forjan el carácter y estimulan la circulación.
[1] https://en.wikipedia.org/wiki/Scoville_scale

View more

¿Alguna guía, tutorial, libro, o recomendacion para aprender administración de sistemas?

Hoy en día, es un tiro al piso.
* Lee el RUTE.
* Lee la Guía de Instalación Debian.
* Descarga Debian 8 e instálalo *sin* ambiente gráfico.
* Instala vim y completa vimtutor.
* Lee el Debian Administrator's Manual.
* Lee el RUTE.
* Configura la red.
A partir de este punto, *todo* lo tienes que hacer desde otra máquina, usando SSH. Puntos extra si configuras SSH para usar llaves digitales y nunca más usas la clave de nada. Estrellita de éxito si usas tmux o screen desde el primer día.
* Lee el RUTE.
* Configura la impresora.
* Lee el RUTE.
* Configura nginx.
* Lee el RUTE.
* Configura $ALGO_QUE_TE_INTERESE
* Lee el RUTE.
* Aprende el Debian Policy.
* Instala alguna aplicación que no esté en Debian y requiera compilar.
* Prepara un paquete Debian para dicha aplicación, que pase lintian sin quejas.
Luego repite, pero con FreeBSD, que tiene una guía similar.
Lo demás, es práctica. Dale la clave de root a alguien, pídele que rompa algo sin decirte, y arréglalo. Además, es mucho más efectivo si aprenden todas estas cosas en conjunto, cada uno trabajando con una máquina diferente.
La documentación en Unix es lo máximo porque es completa, profusa y extensa.

View more

Que hiciste el primero de enero?

Un maratón de Doctor Who con mi hijo, que quería saber qué tiene de especial. El ya es un soñador de sueños improbables, sólo le falta convencerse que los libros son las mejores armas en el mundo.
Liked by: Kalim Al Razif

Crees que racket junto a Dr racket son las herramientas que se deberían enseñar para aprender programar?

En mi opinión y experiencia fuera de la academia, la estrategia de aprendizaje a programar delineada en el libro "Structure and Interpretation of Computer Programs" [1] apoyada en Racket (antes Scheme) construye mejores prácticas de programación y de razonamiento sobre los algoritmos y como construir programas complejos, que las técnicas tradicionales basadas en lenguajes imperativos usando conceptos de estado mutable explotando imitación, y ensayo y error.
Sin embargo, la técnica propuesta por Edsger W. Dijkstra usando derivación formal de programas usando Semántica Axiomática al estilo de Hoare, como se desarrolla en el libro "Programming: the derivation of algorithms" de Anne Kaldewaij [2], también me parece efectiva siempre y cuando NO se use un lenguaje relajado. Es decir, o no usas ningún lenguaje (todo en papel, demostrado matemáticamente) o usas un lenguaje de programación suficientemente estricto como para rebotarte los programas mal derivados (decidibilidad por medio, claro). En concreto, aplicar esta técnica pero usar Python, Ruby, Pascal, Swift, C, Go, no sirve de nada.
Así, si me tocara a mi enseñar a programar a un novel total (o alguien que porque echa líneas en $LENGUAJE_DEL_MES cree que sabe programar) probablemente optaría por SICP.
Después lo llevaría al mundo de los sistemas de tipos estáticos.
Nota bene: yo no enseño a programar; para la mayoría hago latonería y pintura, y para algunos tengo la suerte de verlos volar después de su "momento ¡ajá!"
[1] https://mitpress.mit.edu/sicp/
[2] http://www.cs.utexas.edu/users/EWD/ewd04xx/EWD472.PDF

View more

¿Puedes dar una pequeña explicación de los diferentes paradigmas de programación y para que se usan haciendo referencia en cada caso a los lenguajes que consideras son los mejores, o recomendarme alguna lectura respecto al tema?

Hay dos paradigmas fundamentales: el imperativo, que requiere indicar los pasos precisos para completar un cómputo (el "cómo"); y el declarativo, que consiste en indicar las relaciones involucradas entre los datos para completar un cómputo (el "qué"). En ambos casos, el vehículo es un lenguaje de programación.
El paradigma imperativo es el más frecuente en los lenguajes de programación (C, Python, Ruby, Java, Smalltalk, ensamblable de cualquier procesador) porque imita directamente a las máquinas. Eso hace que la mayoría de la gente esté expuesta y aprenda a programar con lenguajes imperativos. Es típico de los lenguajes imperativos el concepto de "variables que cambian" (estado mutable) y de instrucciones para cambiar las variables (asignaciones) o controlar el flujo (condicionales e iteración). Esto no es necesariamente malo, pero dificulta enormemente razonar sobre los programas y componer programas complejos a partir de programas simples.
El paradigma declarativo tiene tres variantes generales: la programación funcional, que consiste en expresar el problema como una serie de funciones, que al componerse, toman un valor inicial y producen un valor final (LISP, Haskell, Erlang); la programación "lógica", que consiste en expresar el problema como una serie de relaciones entre los datos, y combinadores de inferencia para obtener el resultado (Prolog, SQL); la programación por restricciones, que consiste en expresar el problema como un grafo de dependencias que se reconstruye al cambiar valores (hoja de cálculo, Verilog). Este paradigma es mucho más matemático (no hay estado mutable, ni ciclos, sólo recursión), permitiendo razonar con mayor rigurosidad sobre los programas y facilitar la composición de soluciones. En particular, en el mundo moderno, la programación declarativa funcional es ampliamente superior para escribir sistemas concurrentes y paralelos.
Puede usarse cualquier paradigma para resolver cualquier problema, porque todos son igualmente poderosos (Tesis Church-Turing). Las ventajas de usar uno u otro dependen del problema específico, por eso no hay ningún lenguaje inherentemente mejor que los demás.
"Programming Language Pragmatics" (Scott) es un texto introductorio al tema de diseño de lenguajes de programación, en el cual se discuten los tópicos antes descritos y muchos otros relacionados con la evolución de los lenguajes de programación y su aplicabilidad.
Personalmente, para programación imperativa posiblemente orientada a objetos, prefiero usar Perl, y para programación declarativa uso Haskell, Erlang, Prolog y SQL99 como lo provee PostgreSQL.
Los lenguajes de programación son un tema de abordaje complejo, por condiciones sociológicas que son absolutamente irrelevantes para el técnico, pero fundamentales para el aficionado y las comunidades de desarrollo. No obstante, la ventaja de estudiar cómo funcionan los lenguajes, es que después es muy difícil que un lenguaje te sorprenda o te deje desarmado.

View more

¿Cuanto vale el dolar para tí?

En la práctica, lo que la gente esté dispuesta a pagar o recibir por él. El dólar, como bien privado, está sujeto a la Ley de Oferta y Demanda. Para que algo sea barato, tiene que haber mucha oferta o poca demanda.
En la teoría, comparar una moneda X con el dólar requiere un valor de referencia común. Ese valor de referencia tiene que ser un bien privado material de precio razonablemente estable y con valor intrínseco para cualquiera. En el mundo, de común acuerdo, ese bien es el oro. Entonces, se toma la cantidad de dinero emitido para la moneda X (cantidad de billetes y monedas en circulación) y se divide por el valor en dólares de la cantidad de oro que posee la nación que emitió la moneda X. La moneda de una nación vale tanto como sus reservas -- así de sencillo.
Como el oro no se puede "imprimir" y su cantidad es finita, es una referencia estable de valor.
El valor teórico sólo es una referencia, porque al final termina ganando la práctica. De modo que no se trata de preguntar cuánto vale el dólar "para mi", sino cuánto vale el dólar para un ser pensante que comprende el funcionamiento de la Ley de Oferta y Demanda sobre la comparación de valor monetario.
Para más detalles, consulta textos de economía -- no hace falta ser economista para comprender este sencillo concepto. Lo que si es necesario es no ser dogmático ni ofenderse cuando los resultados científicos contradicen "lo que uno quisiera" (que es lo que le pasa al pobre "el dólar no vale eso").

View more

¿cuál es su opinión sobre C#?

La vida es muy corta para desperdiciarla en Java, y muy divertida para entristecerla con C#
Suponiendo que me interesara utilizar un lenguaje orientado a objetos semi-estático con despacho virtual, no utilizaría ninguno de los dos porque son limitados por diseño. La programación orientada a objetos originaria (Smalltalk) era mucho más flexible y expresiva que sus variantes noventosas (C++, Java). C# sigue siendo lo mejor que los noventa puede ofrecer, sólo que lo ofrece una empresa diferente.
La programación orientada a objetos moderna, para los que continúan dependiendo de ese paradigma, prefiere la composición no jerárquica basada en roles porque conduce a mejor reutilización de código y mejora la eficiencia al simplificar la cadena de despacho dinámico. Es cierto que C# tiene mixins (como los de Ruby), que son mejores que las simples interfaces (como las de Java), pero siguen siendo inferiores a un sistema de roles completo (como los de CLOS o Perl Moose).
Así que C# en realidad me parece más C♭.

View more

Erase una vez....?

"The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents. We live on a placid island of ignorance in the midst of black seas of infinity, and it was not meant that we should voyage far. The sciences, each straining in its own direction, have hitherto harmed us little; but some day the piecing together of dissociated knowledge will open up such terrifying vistas of reality, and of our frightful position therein, that we shall either go mad from the revelation or flee from the deadly light into the peace and safety of a new dark age."

Puedo preguntarte sobre Haskell por aquí ?

Puedes hacer preguntas en Haskell.
Toma en cuenta que aquí el espacio es limitado, así que para algunas preguntas es probable que la respuesta sea "lee este enlace".
Por otro lado, existen listas de discusión que se prestan mucho mejor para el intercambio de ideas, y además son un punto de encuentro para *muchos* interesados en el tema. Mientras mayor es la cantidad de lectores, mayor es la probabilidad de que tus preguntas reciban preguntas oportuna y rápidamente. Así que, más allá de hacer preguntas por aquí, te sugiero inscribirte en Haskell Café.
Liked by: Cesar Rada

Language: English