Portada
mis comunidades
otras secciones
#3:
Yo creo que habria que distinguir desarrollar en windows para entornos windows, y en windows para entornos multi-SO, o utilizando lenguajes que nacieron en unix y ahora han sido abrazados por la M.
Yo empece con Debian, bash, perl y python bajo el brazo, y en ese mundo hostil, Windows era Stalingrado.
Pero por azares del destino di con mis huesos en una empresa que requiere niveles ridiculos de certificaciones y de capas de seguridad. Ahi es cuando te das cuenta que al final para defenderte contra LDAP lo mejor es abrazarlo, suma a esto certificados, credenciales, firmas y servidores... y resulta que la manera mas facil es tirar de C# y Visual Studio, donde ahora Python y NodeJS campan a sus anchas.
La cosa ha cambiado tanto desde que Nadella aterrizo en M$, que ahora es mas facil desarrollar en Python para Linux desde M$ Visual Studio (que dicho sea de paso, es el mejor entorno de desarrollo para hacer tu vida facil, diametralmente opuesto a Eclipse).
Yo empece con Debian, bash, perl y python bajo el brazo, y en ese mundo hostil, Windows era Stalingrado.
Pero por azares del destino di con mis huesos en una empresa que requiere niveles ridiculos de certificaciones y de capas de seguridad. Ahi es cuando te das cuenta que al final para defenderte contra LDAP lo mejor es abrazarlo, suma a esto certificados, credenciales, firmas y servidores... y resulta que la manera mas facil es tirar de C# y Visual Studio, donde ahora Python y NodeJS campan a sus anchas.
La cosa ha cambiado tanto desde que Nadella aterrizo en M$, que ahora es mas facil desarrollar en Python para Linux desde M$ Visual Studio (que dicho sea de paso, es el mejor entorno de desarrollo para hacer tu vida facil, diametralmente opuesto a Eclipse).
#12:
Obvio, aunque todo esto es muy subjetivo y depende mucho del workflow al que estés acostumbrado.
Yo llevo varios años programando en y para Unix, y estoy acostumbrado a ciertas dinámicas que fuera de Unix no se dan. En particular, mi experiencia personal en Windows es con Visual Studio, y lo detesto toda mi alma. Entre lo que comenta #11 y que la terminal de Windows es muy limitada,
programar en y para Windows es bastante cansino.
Luego hay otras cosas superdivertidas como que la depuración sólo se puede hacer desde el IDE (si las máquinas de compilación están en remoto no sabes tú lo gracioso que es esto), y si la compilación sucede remotamente dentro de un make a veces el compilador abre una ventana de error esperando a que alguien (desde las 4 de la mañana) haga clic para continuar, parándolo todo.
Otra cosa que me parece bastante estúpida por parte de Windows es la inexistencia de una biblioteca estándar de C (msvcrt no cuenta), y que te obligue o bien a instalar las dlls con tu binario, o bien a crear un binario estático de tropiecientos KiB.
Luego están las pequeñas tonterías que, sin ser críticas, son muy molestas. Por alguna razón, la compilación es extremadamente lenta (comparando un Windows en nativo con un Linux virtualizado en la misma máquina, este último siempre irá más rápido). Otra cosa bastante problemática es que las herramientas que yo uso en Unix para depurar (sobre todo las de valgrind) o no existen en Windows, o son de pago. Luego, en x86 puedes meter inline assembly, pero en x64 no. ¿Por qué? Etc , etc.
Es posible que todas estas cosas tengan arreglo (o no), pero lo que me tira para atrás a la hora de programar para Windows es que no tienen arreglo fácil.
CC #1
Yo llevo varios años programando en y para Unix, y estoy acostumbrado a ciertas dinámicas que fuera de Unix no se dan. En particular, mi experiencia personal en Windows es con Visual Studio, y lo detesto toda mi alma. Entre lo que comenta #11 y que la terminal de Windows es muy limitada,
programar en y para Windows es bastante cansino.
Luego hay otras cosas superdivertidas como que la depuración sólo se puede hacer desde el IDE (si las máquinas de compilación están en remoto no sabes tú lo gracioso que es esto), y si la compilación sucede remotamente dentro de un make a veces el compilador abre una ventana de error esperando a que alguien (desde las 4 de la mañana) haga clic para continuar, parándolo todo.
Otra cosa que me parece bastante estúpida por parte de Windows es la inexistencia de una biblioteca estándar de C (msvcrt no cuenta), y que te obligue o bien a instalar las dlls con tu binario, o bien a crear un binario estático de tropiecientos KiB.
Luego están las pequeñas tonterías que, sin ser críticas, son muy molestas. Por alguna razón, la compilación es extremadamente lenta (comparando un Windows en nativo con un Linux virtualizado en la misma máquina, este último siempre irá más rápido). Otra cosa bastante problemática es que las herramientas que yo uso en Unix para depurar (sobre todo las de valgrind) o no existen en Windows, o son de pago. Luego, en x86 puedes meter inline assembly, pero en x64 no. ¿Por qué? Etc , etc.
Es posible que todas estas cosas tengan arreglo (o no), pero lo que me tira para atrás a la hora de programar para Windows es que no tienen arreglo fácil.
CC #1
#11:
Dependencies. Unlike *nix, there is no standard path(s) to look up libraries.
Esto, para mí es básicamente esto. Ahora me está tocando compilar una serie de proyectos en C++ y CMake con Visual Studio, y me estoy cagando en su puta madre. En Linux haces mkdir build && cd build && cmake .. && make && sudo make install y a correr. En Windows peléate con ocho mil rutas porque cada cosa está donde le sale de las pelotas
Y luego están los scripts. Como dice el artículo, Bash es feísimo, pero los ficheros batch de Windows son la cosa más cutre inventada en siglos.
Esto, para mí es básicamente esto. Ahora me está tocando compilar una serie de proyectos en C++ y CMake con Visual Studio, y me estoy cagando en su puta madre. En Linux haces mkdir build && cd build && cmake .. && make && sudo make install y a correr. En Windows peléate con ocho mil rutas porque cada cosa está donde le sale de las pelotas
Y luego están los scripts. Como dice el artículo, Bash es feísimo, pero los ficheros batch de Windows son la cosa más cutre inventada en siglos.
Comentarios
porque eres un incompetente, si te resulta exasperante dedícate a otro oficio
#1
Claro, por eso está en Cisco
#2 He entrado a la noticia porque he oído el zasca a #1 desde la portada
#5 has debido ser el único
#2 precisamente por eso , si fuera competente no estaría ahí
#7
Ya, seguro
#2 ¿Y?
Que yo sepa, y a no ser que hayan cambiado mucho las cosas, los routers de Cisco tienen varias categorías, siendo la más alta gobernada por un Sistema Operativo propio de Cisco, y a partir de ahí, hacia los modelos inferiores, comandados por una suerte de lenguajes Linux.
El hecho de que este hombre haya dicho que programa en Linux y que trabaja para Cisco indica, y repito que a no ser que haya cambiado bastante las cosas desde que me enteré del funcionamiento de los routers de Cisco, que no está ni de lejos en lo más alto de la programación en esa empresa.
Vamos, que es como el que dice "Yo trabajo para el Gobierno de España" y resulta que es el funcionario que está de lunes a viernes en la ventanilla 7A de la tercera planta de la Delegación Territorial de Murcia de la Administración Central. Sí, trabaja para el Gobierno de España, pero no es de lejos tan importante y relevante para el funcionamiento de este país.
#18 Tiene usted mucho tiempo libre para suponer cosas, y para preocuparse por la vida de los demás.
#28 Es lo que tiene ser meneante, que quieras o no, al escribir, estás interactuando con lo plasmado por otras personas, y durante unos instantes influyes en sus vidas.
Es más, si tienes amigos y demás por estos lares, es mucho más normal preocuparse por precisamente esas vidas.
Y por último... lo de "mucho tiempo libre para suponer cosas"... digamos que soy un comprador antiguo de artículos de Cisco y que, aunque no poseo muchas cosas en mi favor (por eso de que son de grandísima calidad y tardan en estropearse un montón), procuro informarme previamente de todo lo que me pueda interesar antes de adquirir un router o un ratón (el ratón de otra marca, que Cisco no los fabrica)... Y he ahí que uno descubre cosas como lo que ponen de Sistema Operativo en las diferentes categorías, y que precisamente hace que, si en la actualidad todo sigue igual, el "Zasca ultra-sonoro" que supuestamente #2 ha hecho sobre #1 ya no es sino un "zasquita" o incluso menos.
#29
No es necesario que vengas a contarnos tu vida.
Obvio, aunque todo esto es muy subjetivo y depende mucho del workflow al que estés acostumbrado.
Yo llevo varios años programando en y para Unix, y estoy acostumbrado a ciertas dinámicas que fuera de Unix no se dan. En particular, mi experiencia personal en Windows es con Visual Studio, y lo detesto toda mi alma. Entre lo que comenta #11 y que la terminal de Windows es muy limitada,
programar en y para Windows es bastante cansino.
Luego hay otras cosas superdivertidas como que la depuración sólo se puede hacer desde el IDE (si las máquinas de compilación están en remoto no sabes tú lo gracioso que es esto), y si la compilación sucede remotamente dentro de un make a veces el compilador abre una ventana de error esperando a que alguien (desde las 4 de la mañana) haga clic para continuar, parándolo todo.
Otra cosa que me parece bastante estúpida por parte de Windows es la inexistencia de una biblioteca estándar de C (msvcrt no cuenta), y que te obligue o bien a instalar las dlls con tu binario, o bien a crear un binario estático de tropiecientos KiB.
Luego están las pequeñas tonterías que, sin ser críticas, son muy molestas. Por alguna razón, la compilación es extremadamente lenta (comparando un Windows en nativo con un Linux virtualizado en la misma máquina, este último siempre irá más rápido). Otra cosa bastante problemática es que las herramientas que yo uso en Unix para depurar (sobre todo las de valgrind) o no existen en Windows, o son de pago. Luego, en x86 puedes meter inline assembly, pero en x64 no. ¿Por qué? Etc , etc.
Es posible que todas estas cosas tengan arreglo (o no), pero lo que me tira para atrás a la hora de programar para Windows es que no tienen arreglo fácil.
CC #1
#12 ¡Este es el año de linux en la estación de trabajo!
Y lo de msvcrt... Normal que te de problemas, ¡es un controlador para monitores antiguos! (MicroSoft driVer for CRTs)
#13 voy a quedar como un imbécil, pero te juro que no sé si tu comentario es irónico o no.
#17 de imbécil nada, que a mi me pasa continuamente. O lo mismo soy imbécil también...
Y lo del msvcrt iba en broma
#19 he visto cosas que no creerías.
#12 Yo ahora trabajo con Visual Studio cada día, y para .Net es una pasada de entorno, pero para C/C++... en fin. El compilador se actualiza a paso de tortuga, ayer descubrí que incluso VS2017 sólo soporta OpenMP 2, cuando la versión 3 salió hace casi 10 años. La gente lleva años pidiéndolo, y al equipo de desarrollo le resbala, te dicen que te instales ICC o Clang. Y luego está MSBuild, que es un puto cáncer, para cualquier proyecto mínimamente complejo te tiras la hostia de tiempo configurándolo. Y como eso muchas otras cosas.
Yo creo que habria que distinguir desarrollar en windows para entornos windows, y en windows para entornos multi-SO, o utilizando lenguajes que nacieron en unix y ahora han sido abrazados por la M.
Yo empece con Debian, bash, perl y python bajo el brazo, y en ese mundo hostil, Windows era Stalingrado.
Pero por azares del destino di con mis huesos en una empresa que requiere niveles ridiculos de certificaciones y de capas de seguridad. Ahi es cuando te das cuenta que al final para defenderte contra LDAP lo mejor es abrazarlo, suma a esto certificados, credenciales, firmas y servidores... y resulta que la manera mas facil es tirar de C# y Visual Studio, donde ahora Python y NodeJS campan a sus anchas.
La cosa ha cambiado tanto desde que Nadella aterrizo en M$, que ahora es mas facil desarrollar en Python para Linux desde M$ Visual Studio (que dicho sea de paso, es el mejor entorno de desarrollo para hacer tu vida facil, diametralmente opuesto a Eclipse).
#3 Uh, para Python lo mejor es Jupyter Notebook.
#4 ¡Muy interesante! No lo conocía, me lo apunto.
#4 Lo veo mas apropiado para uso personal que para un entorno de trabajo profesional, pero... Carayo que buena pinta tiene!
#22 Es para entornos científicos, pero se le puede dar un uso empresarial perfectamete
Pero claro, no es lo mismo mi entorno de sysadmin que mascar numericos y ecuaciones, que es lo que veo Jupyter más adecuado...
De hecho se usa muchísimo en redes neuronales
Pero claro, Python tiene un módilo WMI, como han dicho antes que será util para LDAP, así que oye, eso + gráficas y tablas: perfecto para análisis.
#23 De hecho el WMI ha sido implementado por M$!
La verdad es que me gusta mucho, y supongo que en mas poco que mucho tiempo, github acabe haciendo de esto un frontend.
Ya que eres un BOFH, sabras que los entornos empresariales utilizan marketing futurista para vender software anticuado basado en tecnologias arcaicas, para resolver problemas subsanados. No espero Jupyter en mi empresa hasta dentro de 10 primaveras
He vuelto a Windows tras ocho años usando Mac, y es desesperante, angustioso y me llena de odio a Microsoft.
Para usar un IDE como un mono entrenado, es mejor Windows. Si vas a usar un ecosistema de herramientas en las que un terminal con la shell es central a todas ellas tienes que usar Linux o Mac. Si valoras la libertad, debes usar GNU/Linux.
Dependencies. Unlike *nix, there is no standard path(s) to look up libraries.
Esto, para mí es básicamente esto. Ahora me está tocando compilar una serie de proyectos en C++ y CMake con Visual Studio, y me estoy cagando en su puta madre. En Linux haces mkdir build && cd build && cmake .. && make && sudo make install y a correr. En Windows peléate con ocho mil rutas porque cada cosa está donde le sale de las pelotas
Y luego están los scripts. Como dice el artículo, Bash es feísimo, pero los ficheros batch de Windows son la cosa más cutre inventada en siglos.
#11 el día que veas powershell se te caen los ojos
#27 He intentado usarlo y no sé muy bien que pensar... Pero vamos, shell bonita no hay ninguna, cada vez que tengo que escribir un script de bash me quiero tirar por la ventana.
#2Cisco no es ejemplo de una compañía amigable solo la competencia de huawei antigua 3com les ha puesto en su sitio.
#15
Firefox tiene H.264 por donación de Cisco.
No digo que sea una empresa modelo porque siguen haciendo mucho software privativo. Pero tampoco es Microsoft.
Microsoft es el mayor contribuidor a proyectos open source en github. Siguen haciendo mucho software privativo, pero al menos no son Amazon
Windows es una sopa de APIs incoherentes y recargadas escritas por una familia de simios donde para hacer las cosas bien te has de preocupar de un montón de cornercases y mantener compatibilidad hacia atrás con versiones de hace 15 años