A veces me toca retocar el frontend que corre en la intranet interna de la empresa, y una vez me regañaron por poner íconos como ☰ ⋮ ⋯ + en el dashboard que ven los directivos. Me preguntaban dónde se había ido tal o cual función, y cuando les decía que había que presionar ese botón, respondían que no se veía, que mejor lo pusiera simplemente como texto y me reclamaban por eso... Al final hubo una vez en que lo regresé a la interfaz de los años 2000 que usábamos antes. Supongo que, como con todo, el frontend es difícil.
Parece que tanto Tesla como Rivian también van por el camino de fabricar sus propios chips. Claro, después de este anuncio la acción cayó nada menos que un 10%.
No he podido probar una Rivian, solo me senté dentro, pero la calidad de fabricación sí me pareció realmente buena.
Aquí también registraron ya la marca y las patentes en 2021, pero no se ha oído nada sobre su lanzamiento.
Si alguien afirma que tiene una gallina de los huevos de oro, creo que deberíamos poder verificar si esos huevos realmente son de oro, si de verdad los puso esa gallina y qué se está obteniendo a cambio de esos huevos de oro.
Yo leo en ese sentido el argumento de Stallman de que, para que la computación sea confiable, debe haber acceso al código fuente.
Recientemente hubo un caso en el que se encontró un micrófono en un producto llamado nanokvm, lanzado por sipeed, un fabricante chino de plataformas embebidas.
Entiendo que existe cierta inquietud de que los productos embebidos fabricados en China sean débiles en términos de seguridad o incluso puedan usarse para operaciones de seguridad del gobierno.
Así que, quizás reflejando ese prejuicio, hace poco también salió este artículo sobre ese producto: 중국산 NanoKVM에서 숨겨진 마이크를 발견한 과정
Pero creo que sipeed pudo aclarar el malentendido como un simple incidente porque tanto ese hardware como el desarrollo del software se llevaron adelante como open source: https://x.com/lexifdev/status/1999340940805439775
Tengo entendido que, en la época de Stallman, en este tipo de discusiones el lugar que hoy ocupa el gobierno chino lo ocupaban el gobierno de Estados Unidos en tiempos todavía marcados por el macartismo y la NSA.
Hubo casos de puertas traseras de la NSA que parecían teorías conspirativas pero luego se comprobaron, y también cosas como los printer tracking dots (https://en.wikipedia.org/wiki/Printer_tracking_dots).
Aunque hoy en día, más que las teorías conspirativas con participación del gobierno, lo que está de moda es hablar de empresas cuyo principal ingreso es la publicidad y que supuestamente espían el micrófono del smartphone para hacer publicidad dirigida.
Y creo que, en las empresas de tecnología de software, el código fuente por supuesto cumple un papel importante, pero la comodidad general, la capacidad de operar servicios y la confianza cumplen un papel todavía mayor.
Aunque un competidor tardío consiguiera todo el código fuente de OpenAI, no podría alcanzar fácilmente su marca ni asegurar y operar de forma estable la infraestructura necesaria para sostener a una enorme cantidad de usuarios.
Hay bastantes casos de productos principales operados como open source, con muchísimos forks, que aun así no perdieron la iniciativa.
Se me ocurren de inmediato casos como Chrome y VS Code.
Por supuesto, también están casos en que sí se perdió esa iniciativa, como Elastic o Redis, con los conflictos por las licencias open source a causa de AWS, pero igualmente yo creo que eso ocurrió porque ambas empresas estaban relativamente por detrás de AWS en comodidad, capacidad de operación de servicios y confianza.
Bueno, todo esto también puede verse, de algún modo, como una discusión política e ideológica. Así que agrego una experiencia personal.
Desde la posición de alguien que trabaja principalmente desarrollando software y que por hobby trastea con hardware embebido, enfrentarse a cajas negras sin código fuente ni esquemas realmente hace que desarrollar y dar mantenimiento sea muy, muy difícil.
Cuando intento desarrollar usando alguna biblioteca de software o cierto hardware, si puedo obtener el código fuente o los planos, o al menos si la documentación de especificaciones está bien organizada, el desarrollo se vuelve muchísimo más llevadero; si no, de verdad termina siendo un dolor de cabeza.
Últimamente en el extranjero se habló bastante del derecho a reparar, y una de las cosas que más me impresionó fue escuchar que antes, al abrir la tapa de los dispositivos electrónicos, venía dibujado el diagrama de cableado para que sirviera de referencia al repararlos. (Últimamente se dice que Apple proporciona esquemas a los técnicos de reparación).
Ese tipo de experiencias influye mucho en cómo se forma la confianza hacia esos productos. Hoy, cuando elijo una tecnología o compro un producto, lo primero que evalúo es si, cuando se rompa o surja algún problema, voy a poder entenderlo con facilidad y repararlo, seguir usándolo o al menos encontrar una alternativa por mi cuenta.
Debería rechazarse su uso porque realizar el cómputo en servidores ajenos vulnera la libertad informática del usuario.
¿Pero esto no es básicamente sostener que habría que rechazar no solo los LLM, sino también todos los servicios en la nube y los servicios externos...? ¿La traducción está mal?
Creer que al programar con un modelo de lenguaje va a inventar por arte de magia expresiones cercanas a la máquina es tener mentalidad de abusivo.
Cuantas más restricciones haya, mejor trabaja dentro de esas restricciones.
Últimamente, para que una ponencia tenga sentido, parece que tendría que centrarse en consejos sobre IA, pero es una pena sentir que la esencia de dar una charla se va volviendo cada vez más cómoda y se va desdibujando.
Solo ha salido un libro sobre el tema del coreano, pero lamentablemente, como la forma de usar Rust en el kernel de Linux pasó por varios cambios incompatibles, ya no es totalmente compatible con los kernels actuales. Ojalá se pueda complementar a través de GitHub y otros medios.
Aunque la IA escriba el código, la responsabilidad por el servicio igual debería recaer en el desarrollador. No sé si uno realmente pueda hacerse responsable de un código que ni siquiera entiende.
Aun así, creo que sí debe haber métricas significativas. En especial, me parece que sería más efectivo que hubiera alguien responsable de dos indicadores opuestos al mismo tiempo. Desde la perspectiva de SRE, uno puede alegrarse de haber reducido la cantidad de incidentes, pero por andar tanteando demasiado antes de cruzar el puente, los despliegues pueden retrasarse y el desarrollo de funcionalidades volverse más lento. Y desde la perspectiva de Dev, uno puede alegrarse de haber desarrollado muchas funcionalidades, pero eso también podría aumentar la cantidad de incidentes.
También creo que métricas como p99 latency, tasa de éxito de respuesta, costo por solicitud, MTTR y cantidad de incidentes son buenos indicadores difíciles de manipular. (Claro que también podrían manipularse, pero parece que el beneficio de rastrearlos y gestionarlos sería mayor que el costo...)
Siempre me había parecido que presumir resultados en porcentajes no tenía sentido, y creo que este texto termina de completar esa idea.
No se trata de decir que contribuiste a un aumento del 5% en las ventas, sino de explicar cuánto subieron durante cierto período y qué tan más pronunciado fue ese crecimiento en comparación con antes de tu contribución.
Lo cambié rapidísimo, pero parece que así terminó publicándose afuera :(
A veces me toca retocar el frontend que corre en la intranet interna de la empresa, y una vez me regañaron por poner íconos como ☰ ⋮ ⋯ + en el dashboard que ven los directivos. Me preguntaban dónde se había ido tal o cual función, y cuando les decía que había que presionar ese botón, respondían que no se veía, que mejor lo pusiera simplemente como texto y me reclamaban por eso... Al final hubo una vez en que lo regresé a la interfaz de los años 2000 que usábamos antes. Supongo que, como con todo, el frontend es difícil.
El título quedó como
kills... jajajajaParece que tanto Tesla como Rivian también van por el camino de fabricar sus propios chips. Claro, después de este anuncio la acción cayó nada menos que un 10%.
No he podido probar una Rivian, solo me senté dentro, pero la calidad de fabricación sí me pareció realmente buena.
Aquí también registraron ya la marca y las patentes en 2021, pero no se ha oído nada sobre su lanzamiento.
Gracias por entender.
Si alguien afirma que tiene una gallina de los huevos de oro, creo que deberíamos poder verificar si esos huevos realmente son de oro, si de verdad los puso esa gallina y qué se está obteniendo a cambio de esos huevos de oro.
Yo leo en ese sentido el argumento de Stallman de que, para que la computación sea confiable, debe haber acceso al código fuente.
Recientemente hubo un caso en el que se encontró un micrófono en un producto llamado
nanokvm, lanzado por sipeed, un fabricante chino de plataformas embebidas.Entiendo que existe cierta inquietud de que los productos embebidos fabricados en China sean débiles en términos de seguridad o incluso puedan usarse para operaciones de seguridad del gobierno.
Así que, quizás reflejando ese prejuicio, hace poco también salió este artículo sobre ese producto: 중국산 NanoKVM에서 숨겨진 마이크를 발견한 과정
Pero creo que sipeed pudo aclarar el malentendido como un simple incidente porque tanto ese hardware como el desarrollo del software se llevaron adelante como open source: https://x.com/lexifdev/status/1999340940805439775
Tengo entendido que, en la época de Stallman, en este tipo de discusiones el lugar que hoy ocupa el gobierno chino lo ocupaban el gobierno de Estados Unidos en tiempos todavía marcados por el macartismo y la NSA.
Hubo casos de puertas traseras de la NSA que parecían teorías conspirativas pero luego se comprobaron, y también cosas como los printer tracking dots (https://en.wikipedia.org/wiki/Printer_tracking_dots).
Aunque hoy en día, más que las teorías conspirativas con participación del gobierno, lo que está de moda es hablar de empresas cuyo principal ingreso es la publicidad y que supuestamente espían el micrófono del smartphone para hacer publicidad dirigida.
Y creo que, en las empresas de tecnología de software, el código fuente por supuesto cumple un papel importante, pero la comodidad general, la capacidad de operar servicios y la confianza cumplen un papel todavía mayor.
Aunque un competidor tardío consiguiera todo el código fuente de OpenAI, no podría alcanzar fácilmente su marca ni asegurar y operar de forma estable la infraestructura necesaria para sostener a una enorme cantidad de usuarios.
Hay bastantes casos de productos principales operados como open source, con muchísimos forks, que aun así no perdieron la iniciativa.
Se me ocurren de inmediato casos como Chrome y VS Code.
Por supuesto, también están casos en que sí se perdió esa iniciativa, como Elastic o Redis, con los conflictos por las licencias open source a causa de AWS, pero igualmente yo creo que eso ocurrió porque ambas empresas estaban relativamente por detrás de AWS en comodidad, capacidad de operación de servicios y confianza.
Bueno, todo esto también puede verse, de algún modo, como una discusión política e ideológica. Así que agrego una experiencia personal.
Desde la posición de alguien que trabaja principalmente desarrollando software y que por hobby trastea con hardware embebido, enfrentarse a cajas negras sin código fuente ni esquemas realmente hace que desarrollar y dar mantenimiento sea muy, muy difícil.
Cuando intento desarrollar usando alguna biblioteca de software o cierto hardware, si puedo obtener el código fuente o los planos, o al menos si la documentación de especificaciones está bien organizada, el desarrollo se vuelve muchísimo más llevadero; si no, de verdad termina siendo un dolor de cabeza.
Últimamente en el extranjero se habló bastante del derecho a reparar, y una de las cosas que más me impresionó fue escuchar que antes, al abrir la tapa de los dispositivos electrónicos, venía dibujado el diagrama de cableado para que sirviera de referencia al repararlos. (Últimamente se dice que Apple proporciona esquemas a los técnicos de reparación).
Ese tipo de experiencias influye mucho en cómo se forma la confianza hacia esos productos. Hoy, cuando elijo una tecnología o compro un producto, lo primero que evalúo es si, cuando se rompa o surja algún problema, voy a poder entenderlo con facilidad y repararlo, seguir usándolo o al menos encontrar una alternativa por mi cuenta.
Lo viste correctamente.
Stallman también sostiene que no deberíamos usar SaaS.
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
Parece una vibra de cerámica.
La gráfica del aumento de mi salario ha estado en 0% durante 5 años.
Puede que no sea fácil generalizar, pero por ahora está claro que sin duda es la mejor herramienta para convencer a la dirección.
Debería rechazarse su uso porque realizar el cómputo en servidores ajenos vulnera la libertad informática del usuario.
¿Pero esto no es básicamente sostener que habría que rechazar no solo los LLM, sino también todos los servicios en la nube y los servicios externos...? ¿La traducción está mal?
Creo que vi este texto hace muchísimo tiempo... pero volvió a ser un texto que me motivó otra vez. Gracias por subirlo.
Creer que al programar con un modelo de lenguaje va a inventar por arte de magia expresiones cercanas a la máquina es tener mentalidad de abusivo.
Cuantas más restricciones haya, mejor trabaja dentro de esas restricciones.
Últimamente, para que una ponencia tenga sentido, parece que tendría que centrarse en consejos sobre IA, pero es una pena sentir que la esencia de dar una charla se va volviendo cada vez más cómoda y se va desdibujando.
Una vez más sentí lo difícil que es delegar el trabajo.
Pero, para ser algo así, ¿no se bajaron varios maintainers?
Solo ha salido un libro sobre el tema del coreano, pero lamentablemente, como la forma de usar Rust en el kernel de Linux pasó por varios cambios incompatibles, ya no es totalmente compatible con los kernels actuales. Ojalá se pueda complementar a través de GitHub y otros medios.
Aunque la IA escriba el código, la responsabilidad por el servicio igual debería recaer en el desarrollador. No sé si uno realmente pueda hacerse responsable de un código que ni siquiera entiende.
Aun así, creo que sí debe haber métricas significativas. En especial, me parece que sería más efectivo que hubiera alguien responsable de dos indicadores opuestos al mismo tiempo. Desde la perspectiva de SRE, uno puede alegrarse de haber reducido la cantidad de incidentes, pero por andar tanteando demasiado antes de cruzar el puente, los despliegues pueden retrasarse y el desarrollo de funcionalidades volverse más lento. Y desde la perspectiva de Dev, uno puede alegrarse de haber desarrollado muchas funcionalidades, pero eso también podría aumentar la cantidad de incidentes.
También creo que métricas como
p99 latency, tasa de éxito de respuesta, costo por solicitud, MTTR y cantidad de incidentes son buenos indicadores difíciles de manipular. (Claro que también podrían manipularse, pero parece que el beneficio de rastrearlos y gestionarlos sería mayor que el costo...)Entonces, probablemente ese gráfico tenga una alta probabilidad de contaminarse.
Ley de Goodhart: "En el momento en que una métrica se convierte en objetivo, deja de ser una buena métrica"
Siempre me había parecido que presumir resultados en porcentajes no tenía sentido, y creo que este texto termina de completar esa idea.
No se trata de decir que contribuiste a un aumento del 5% en las ventas, sino de explicar cuánto subieron durante cierto período y qué tan más pronunciado fue ese crecimiento en comparación con antes de tu contribución.