Portada
mis comunidades
otras secciones
![GitHub caido. Los desarrolladores de todo el mundo declaran hoy dia de nieve.[ENG]](https://cdn.mnmstatic.net/cache/26/f8/media_thumb_2x-link-2553981.jpeg?1453944966)
#9:
La nube no es más que un ordenador en casa de otra persona.
Seguro que al final se arregla
#16:
El problema es más serio de lo que parece, y merece la pena reflexionar sobre él. Montamos sistemas distribuidos, autoescalables, lo que queramos.... que dependen para aprovisionarse de un punto único de fallo. Si tienes una configuración de autoescalado y te llega un arreón de tráfico, que no te pille GitHub por los suelos, o tus máquinas igual empiezan a aparecer con una versión antigua del software.
Ahora bien, también merece la pena reflexiona sobre la contingencia y su solución, que igual te añade una complejidad que no merece la pena para una incidencia que sucede de higos a brevas.
Ahora bien, también merece la pena reflexiona sobre la contingencia y su solución, que igual te añade una complejidad que no merece la pena para una incidencia que sucede de higos a brevas.
#72:
#70 no te puedo decir porque no desarrollo en Mac, pero como usuario de Debian por más de 10 años, te diré que para programar, en el caso más sencillo, solo tengo que hacer un "sudo apt-get install eclipse-cdt build-essential", y aquí los que se pegan para dejar funcionando un compilador son mis compañeros que no salen de Win7
#62:
#17 #21 Hola, soy yo
Ahora mismo no tengo claro cuánto estoy autorizado a comentar (todo pasó mientras yo dormía y no estaba yo de guardia, así que me estoy poniendo al día de la situación) pero ya estamos recuperados casi al 100%. Imagino que habrá un post-mortem oficial a lo largo del día, ya lo enlazaré por aquí cuando se publique.
Ahora mismo no tengo claro cuánto estoy autorizado a comentar (todo pasó mientras yo dormía y no estaba yo de guardia, así que me estoy poniendo al día de la situación) pero ya estamos recuperados casi al 100%. Imagino que habrá un post-mortem oficial a lo largo del día, ya lo enlazaré por aquí cuando se publique.
#20:
Ah... el viejo mantra de Internet de "no bases recursos criticos en servicios de terceros".
Nunca es tarde para aprender esa valiosa lección.
Nunca es tarde para aprender esa valiosa lección.
#37:
Je, que cachondo, he mirado y "karma: 404" 
Comentarios
La nube no es más que un ordenador en casa de otra persona.
#9 La nube es cool
#9 Un ordenador que no tienes que mantener, que mantiene gente muy especializada en ello, y mucho más barato por que el precio se comparte entre los diferentes clientes.
#43 Si, y que si le pasa algo no puedes controlar en absoluto.
Ventajas y desventajas, como siempre.
#44 es que ¿para qué quieres controlarlo? Para eso están los tecnicos de github que lo saben hacer mucho mejor que tu y que les pagas para ello.
Quiero decir, claro que son ventajas y desventajas, pero en este caso las ventajas son mucho más importantes que las desventajas.
#48 Para poder seguir trabajando, nosotros tenemos nuestro propio servidor de GIT, con backups y demas.
Eso de que saben hacerlo mucho mejor que yo... saben mantener SUS ENTORNOS mejor que yo, pero si me monto lo mio propio seguro que sabre yo mejor mantenerlo que ellos.
#51 Primero, es lo suyo mantener un servidor propio como plan B, eso ya lo he dicho antes, hacéis lo correcto (en mi opinión, en la de mi CEO, no merece la pena la inversión).
Segundo, claro que no sabrán mantener tus sistemas mejor que tu, pero estoy bastante convencido de que saben mantener bastante mejor sus servidores que tu los tuyos. Y no digo que tu los mantengas mal.
#67 #51 La parte contratante de la primera parte...
#48 No te tomes a mal este comentario, no olvides que estás contestando a alguien que te dice "ventajas y desventajas". Y es exactamente eso, ganas algo pero pierdes en otras cosas...
Sobre que las ventajas sean más importantes que las desventajas es algo que cada uno debe evaluar en cada situación particular. Me parece importante resaltar que es verdad, con la nube pierdes muchas cosas, y eso hay que tenelo presente.
¿para qué quieres controlarlo? A ti que te importa, cada uno tiene sus necesidades.
#44 Une también la ventaja de la seguridad. En la nube no sabes si tus datos lo están por mucho que digan.
#43 Gente muy especializada en ello... ains que me parto.
Normalmente una empresa compra el "software" para montar una cloud. Cuando falla la cloud, esta empresa tiene que "abrir ticket" con el soporte del fabricante y pasar los niveles de soporte 1 y 2 para que te atienda alguien que sabe de lo que le estás hablando y que su solucion no sea: "apague y encienda el router o reinicie su computadora".
Es lo que da la ignorancia (no te estoy llamando ignorante, no van por ahi los tiros), pero en todas las casas cuecen habas.
#57 Hombre, si contratas una empresa de mierda, pues recibes mierda. Github no es precisamente una empresa de mierda, y responde muy bien. Llevo años trabajando en una conocida eshop internacional con más de 60 developers en sus oficinas de Barcelona y bien considerada en el mundillo dev. Y tenemos nuestro código en github, e intentamos externalizar todo lo que sea infrastructura. Y nos va mejor desde que lo hacemos así. No te hablo desde la ignorancia.
#59 lo que dice #57 es verdad. Incluso con ProSupport en empresas como Dell o HP, tienes que perder el tiempo haciendo comprobaciones rutinarias para que eleven la incidencia a ingeniería y no te pidan que apagues y enciendas. Incluso cuando llamamos desde sistemas nos toman por lelos.
#59 Tampoco estoy de acuerdo, mientras más grande eres más tienes que estandarizar procedimientos internos. Tampoco digo que no sea mejor, pero vamos, ya digo en otro comentario que estoy muy deacuerdo en que es un tema de compromisos y de qué necesitas.
#57 Tienes que dejar de contratar empresas españolas.
#9 ¡Bienvenido a mi casa!
P.D. los 29 votos a favor son de hipsters
#9 ¿Que te parece mi equipo de aire acondicionado?
#61 Aficionados
#74 je je... por un momento he dudado que esa foto fuera mía... Ver el logo de HP es lo que me ha sacado de dudas.
#74 Mucho reírse, pero aquí tengo uno de estos:
#9 Pues eso.☝
#9 lo mihmo, un ordenador que en muchos casos son varios servidores almacenando la informacion de forma redundante tanto en el mismo lugar como en diferentes lugares del mundo.
#4 parece que ha funcionado, gracias!
#7
#11 ¡Hala! ¡Ha dicho pullear/pushear! ¡A la RAE vas!
#13 Pues no es de lo más bárbaro que he oído/leído, mira a #19 con su "deploy basado en un script de fabric que hiciera un upload" ¡Anglicismos, anglicismos everywhere!
http://ctrld.blogspot.com.es/2006/05/breviario-de-spanglish-tcnico.html
#47 Será más divertido cuando se empiecen a mezclar más idiomas, que divertido será que aparezcan tecnicismos indios/chinos.
#47 Yo hace años que curro sólo en inglés. Ahora no sabría hablar de informática en castellano.
#13 Recuerdo cuando puse bitbucket en castellano. Joder que puto horror!
Centralized Hosting for Distributed Software (tm)
#5 La comodidad a la larga se paga. Muchos programadores de software libre que conozco tienen macs Así que con los servidores, nada de autogestión.
#5, #6 lo chachi de Git es precisamente que es descentralizado y aún con github caído podrías clonar/pullear/pushear por ssh de una máquina a otra.
#11 Sólo cayó el servicio web? Pero mejor sería tener un equipo de sistemas para llevarlo y no una empresa
De todas formas, mil gracias al proyecto, desde luego. Sólo ha estado caido como media hora desde que se colgó la noticia.
#12 pues, si ha sido media hora desde que se colgo la noticia, se ha tirado caido un monton de horas.
[02:20:29] https://gyazo.com/240069c4d087934d8a02dd29dfa94087
Edito: por lo que veo puede ser de 2 a 5?
https://status.github.com
http://i.imgur.com/6IwYkcI.png
#32 Lo puedes comprobar en la diferencia de hora con los hilos. En la noticia creo haber leido hace un rato que fueron dos horas.
#11 ¿Eres mejicano por algun chance wey?
#11 O puedes trabajar en local durante unas horas y compartirlo cuando vuelva a funcionar.
#6 ¿ Y que tiene que ver que tengan macs con esto ?
#26 Pues que mac no es muy abierto ¿no?
#27 ¿ Desde cuando usar absolutamente todas las herramientas open source es un requisito para desarrollar código libre ? Muchos de grandes desarrolladores de software libre usan mac, como el creador de Gnome.
#35 No es un requisito, naturalmente, pero sería ser más consecuente porque si sólo apoyas el soft, pero no el sistema operativo ni el hardware (esto es mucho más dificil), pues la libertad es más reducida ¿no?
#89 No te voy a negar que se puede ver como dices, pero creo que olvidamos que en la realidad tenemos que vivir con todo tipo de contradicciones y en cierta forma eso es lo que nos hace humanos.
Tampoco creo que sea mejor o peor, no llevar una ideología hasta las últimas consecuencias, al final tendrías que vivir como stallman.
#96 Totalmente de acuerdo con el tema consecuente. Pero el SO no es tan gran esfuerzo. El hardware sí. Y el SO es software...
#89 Si eres Stallman si .
Yo no creo en los "talibanismos", se puede ser pro-software libre y no utilizarlo para todo. Mismamente teniendo un movil con Android ya estarías rompiendo esos principios.
#89 Que desarrolles software libre no quiere decir que seas un caballero del software libre o que estés en contra del software propietario. Es como decir que no puedes escribir recetas vegetarianas por que comas carne.
#27 desde que mac es Unix, es más cómodo desarrollar en mac que en Linux, y años luz que en Windows. Tanto en la nube, cómo en local, como en virtual. Y hace mucho ya que es Unix. He probado mucho las 3 plataformas, y Mac gana con diferencia.
(Por cierto, por si no lo sabes, que sea Unix implica que puedes hacer pracricamente lo mismo por consola en Mac que en Linux en lo que a entorno de desarrollo se refiere).
#40 Colaboro en un proyecto open source, y de lejos, el mas coñazo es OSX, despues la cosa varia entre algunos linux (archlinux) y Windows y el mas facil los linux basados en debian (mientras no quieras usar clang en ubuntu 15.10).
Eso si, para programar, donde este el Visual Studio que se quiten los demas IDEs.
#52 Dime más. Cuentame por qué es más coñazo Mac.
Yo te cuento por qué creo que es mejor para un dev.
- Tienes el sistema listo para trabajar en una hora aprox con sencillos pasos a traves de consola (incluyendo IDEs, BDD, herramientas de consola, entornos virtuales...).
- En todas las puestas a punto del entorno que he hecho en mac todo ha funcionado a la primera (en linux era más bien lo contrario, y no hable de hace mucho).
- Las actualizaciones de Mac dificilmente dan problemas.
-Es mucho más rápido que un Linux, y desarrollando proyectos grandes con un IDE con analizador de código automático, se nota y mucho.
Se me ocurren estas de momento. Linux esta muy bien, y IOS se basa eb Unix como él, pero para un desarrollador no es ni de lejos la opción más eficiente. La más barata si. La más "libre" si. Pero no aporta el mismo valor al negocio de la empresa.
Y repito, no soy un fanboy Mac, he trabajado mucho en Linux y estaba convencido de que era lo mejor, hasta que prpbé Mac y vi como mi eficiencia crecía exponencialmente.
#63 estás intentando iniciar un flame
#66 para nada. Simplemente me ha resultado curioso lo de "Mac es el más coñazo", así por que si. Me interesa saber qué razones tiene para pensar lo contrario que todos los devs que conozco.
#70 no te puedo decir porque no desarrollo en Mac, pero como usuario de Debian por más de 10 años, te diré que para programar, en el caso más sencillo, solo tengo que hacer un "sudo apt-get install eclipse-cdt build-essential", y aquí los que se pegan para dejar funcionando un compilador son mis compañeros que no salen de Win7
#72 No se, yo no veo la dificultad en dejar funcionando Visual Studio, otra cosa es que un proyecto requiera X o Y librerias y quieran usar Visual Studio Express teniendo Visual Studio Community totalmente gratis.
#70 El tener que dar soporte a 100s de personas y los que mas problemas porcentualmente al numero de usuarios han tenido en el proyecto en el colaboro han sido los de *BSD y despues los de OSX.
#63 En mi caso por:
https://trinitycore.atlassian.net/wiki/display/tc/Requirements + https://trinitycore.atlassian.net/wiki/display/tc/Core+Installation
#78 para eso está homebrew (que viene a funcionar igual que apt)
#80 https://community.trinitycore.org/topic/10515-howto-compile-trinitycore-on-mac-os-x-using-homebrew/
y aun asi la gente tiene problemas.
#63 ¿Por qué desarrollas en software libre?
#52 A mí Eclipse me da todo lo que necesito en Java y Python, y apostaría a que en C++ también. En mi curro la gente se tira los trastos a la cabeza por que unos usan VS 2008 y otros 2013.
#52 #40 No sólo me refiero a la eficiencia y comodidad, si no a la filosofía del sofware libre en el sistema operativo.
Ah... el viejo mantra de Internet de "no bases recursos criticos en servicios de terceros".
Nunca es tarde para aprender esa valiosa lección.
#20 No olvidemos la otra parte de ese mantra, que es "no bases recursos críticos en servicios propios"
Por suerte git permite usar servicios de terceros (GitHub, Bitbucket, etc) junto con servicios propios (GitLab, git local, etc) para no tener que depender ni de unos ni de otros.
De paso, diría que la noticia es bastante sensacionalista.
Je, que cachondo, he mirado y "karma: 404"
#37 Karma not found!
#37 jajajaja Karma de Nieve
El problema es más serio de lo que parece, y merece la pena reflexionar sobre él. Montamos sistemas distribuidos, autoescalables, lo que queramos.... que dependen para aprovisionarse de un punto único de fallo. Si tienes una configuración de autoescalado y te llega un arreón de tráfico, que no te pille GitHub por los suelos, o tus máquinas igual empiezan a aparecer con una versión antigua del software.
Ahora bien, también merece la pena reflexiona sobre la contingencia y su solución, que igual te añade una complejidad que no merece la pena para una incidencia que sucede de higos a brevas.
#16 Hace tiempo bitbucket nos hizo una jugada parecida (en realidad lleva varias) y nos vimos con una mano delante y otra detrás en un momento jodido con una aplicación en producción que no podíamos actualizar. Decidimos desarrollar un plan b para estos caso, un deploy basado en un script de fabric que hiciera un upload del codigo fuente en la maquina local hacia la remota, para no depender exclusivamente del pull en el repo remoto.
Y si, cuando te suceden estas cosas la palabra "descentralizado" la puedes usar de papel del vater.
#19 no bastaría con añadir un servidor remote temporal y hacer el pull desde el nuevo?... Nunca me ha pasado eso pero está bien saber.
#29 Podría ser otra posibilidad y seguro hay más, pero donde añades ese remote? te lo montas tú o pagas un privado de github? Usamos fabric para otras cosas así que esta solución era sencilla de llevar a cabo sin tener que lidiar con otros servicios de terceros.
#19 No sabías que hablaras élfico en su variante yiddish-informático
#41 Mi madre me enseño a hablar así, que quieres que le haga... Eso sí, la fonética castellana, como mandan los dioses.
#19: ¿Qué es el "código fuente"? ¿No te estarás refiriéndote al "source code", verdad?
#93 Lo siento, source code no es mainstream
#19 "Y si, cuando te suceden estas cosas la palabra "descentralizado" la puedes usar de papel del vater."
O mejor no, no sea que encima no puedas ni aprovechar el tiempo muerto ni para cagar.
#16 En realidad si trabajas en un programa con git, sí que puedes trabajar aunque el servidor esté caído. Lo que no podrás hacer será enviar tus cambios o descargar los cambios que haya hecho otro.
#16 lo de 'igual tus servidores aparecen con una versión antigua del software' me ha matado. Hemos entendido que es Github? Porque ninguna aplicación se conecta a Github en tiempo de ejecución para descargar una librería. Lo peor que te puede pasar como dice #31 es que no puedas hacer pull/push, pero puedes seguir trabajando, que para algo es descentralizado.
#38 Creo que se refiere a que hay alguna gente muy "lista" que apunta sus configuraciones de VMs directamente a GitHub, así que como justo dé la casualidad de que GitHub esté caído en el momento en que sus sistemas de auto-escalado de VMs intenten crear VMs nuevas, se quedan con un palmo de narices.
#86 Esto mismo, no es que la app tire de GitHub en tiempo de ejecución, es que durante el escalado las imágenes descargan los repos de GitHub. Lo de "listo" no sé si es un cumplido, pero desde luego no hemos dado con nada más simple. Ahora se me ocurre que podríamos subir a S3 la última versión del repo con un post-commit hook o algo parecido y que el despliegue tire de S3, a quien no he visto tostarse nunca.
#38 Fijate como funcionan cosas como heroku o deis.
Personalmente me parece absurdo como github, un servicio cerrado y centralizado, se convirtio en un pilar de la comunidad de software libre. Esto con Stallman no pasaba.
#31 Si, eso mismo he pensado yo. Hasta que he dicho: "voy a ver que ticket empiezo... oh, wait."
#16 si el mismo problema te ocurre en local, muy dificilmente te saldrá más barato y rápido arreglarlo. El problema es que incluso muchas empresas grandes no tienen un plan B para cuando cae
#16 De todas maneras GitHub es centralizado, pero la filosofía de Git no. Lo suyo es que trabajes sobre tus copias locales y "ya si eso" mandes los cambios a un repo remoto. Esto no es subversion.
Suerte que tenía copia de seguridad en diskettes
#15 ¿Albert?
#1 Que así no se arregla un servidor caido. Claro que entiendo que si tienes que opositar y tienes allí el código, estés desesperado
#2 por si acaso voy a seguir intentándolo, que soy español
Seguro que al final se arregla
#3
Te ayudo, sólo por solidaridad.
Ya está funcionando, no? Vaya día de nieve: ni nieve, ni github caído ni na!
Aviso, tenemos que hacer algunas operaciones de mantenimiento dentro de poco. Esperamos que no haya otra caída del servicio, pero ahora puede ser un buen momento para que todos los que lo necesitéis hagáis pull y push
#87 Operaciones de mantenimiento finalizadas, todo está bien de momento.
GitHub ha vuelto. ¡A currar!
#53 Por eso solo usamos paquetes. Si el paquete no existe, lo creamos. Y se guarda en un repositorio privado que nosotros controlamos. Tambien es una buena practica tener todo esto documentado y usar 'baselines' para definir versiones de la combinacion de SO + middleware + aplicacion, y luego las configuraciones aparte, con algun gestor de configuraciones.
Que sea opensource o no es irrelevante. Es simplamente una buena practica, en mi opinion.
Desde Gitlab, cuando un proyecto esta listo para ser liberado, siempre se puede hacer el repositorio publico. Todo es cuestion de visibilidad y luego de que capacidad tengas.Incluso tal vez algunas cosas se pueden poner en github, pero nunca nada de lo que dependan tus operaciones deberia ser gestionado por terceros, salvo que las garantias sean muy altas y con contrato, y asumiendo el posible riesgo y si es posible tener un plan para mitigarlo.
Mi equipo y yo trabajamos con nuestro propio servicio de gitlab.
Practicamente todo lo que usamos lo hospedmos nosotros mismos, en nuestros servidores.
#30 Exacto. Github está bien para proyectos OpenSource, pero para lo privado de verdad, prefiero tirar de mi propio servidor Git.
Aún así, que github se caiga es un problema. Por ejemplo, no puedes actualizar las dependencias de un proyecto symfony o similar.
Me encanta la traducción: "Dia de Nieve"
#10 ¿Día de coca?
#10 Pa'traducir mal, mejor no traducir las cosas.
http://www.wordreference.com/es/translation.asp?tranword=snow%20day
#68 la fnac? maldito acomodado burgués.
Que esperen que aviso a mi cuñao que él es muy de arreglar todas estas cosas con un buen reinicio del ordenador.
Aquí en Meneame había algun trabajador de GitHub , no recuerdo su nombre
#17 no creo que tenga el día para conversar pero sería muy interesante que nos contará los que o los porque y como correr en circulo con los brazos en alto
#17 #21 Hola, soy yo
Ahora mismo no tengo claro cuánto estoy autorizado a comentar (todo pasó mientras yo dormía y no estaba yo de guardia, así que me estoy poniendo al día de la situación) pero ya estamos recuperados casi al 100%. Imagino que habrá un post-mortem oficial a lo largo del día, ya lo enlazaré por aquí cuando se publique.
#62 me alegro cuando puedas haz un resumen de lo sucedido gracias
#64 #120 El post-mórtem sigue en preparación por lo que he podido averiguar, pero hay una pequeña entrada en el blog explicando lo que pasó: https://github.com/blog/2101-update-on-1-28-service-outage
#62: op will deliver...
Yo para los proyectos privados uso un gitlab que montamos en la empresa en un contenedor con docker. Nada que envidiar a github. Para los públicos los tengo por duplicado en los dos sitios.
A mí me funciona.
Trabajo en mí gogs (me gusta más que gitlab)
Comparto en github.
Ya ha vuelto. Qué Github esté caído es algo irrelevantísimo, ya que siempre podemos seguir trabajando con nuestro repositorio local, as usual. Y cuando vuelva el servicio, subimos los cambios y punto. As usual.
Voto irrelevantísima.
#68 jajajaja, DVD o Bluray?
Por aquí ya está funcionando de nuevo. Pero sí, un GitHub caído a día de hoy durante mucho tiempo es algo que resultaría en un impacto mucho mayor del que mucha gente se cree. Por ejemplo, hoy quería estudiar un proyecto alojado allí y si no estuviera up de nuevo me habría quedado de brazos cruzados...
#18 Cierto, es comparable al cierre de Megaupload, yo me quede a mitad de una serie.
#24 y qué hiciste después?
#36 Me compré la serie completa en FNAC al cabo de unos años, ¿Qué alternativa tenía?