Portada
mis comunidades
otras secciones
#42:
El día que Microsoft tenga un producto que no se cuelgue será cuando fabriquen perchas.
#8:
Dios mío y de dónde voy a copiar yo ahora todos mis desarrollos y cobrarlos a mis clientes como si los hubiese programado yo...
#2:
Normal, Microsoft no puede estar a todo, o hacen chips o mantienen GitHub
#7:
Para quien quiera hacer seguimiento de la incidencia...
https://www.githubstatus.com/incidents/d60fmldlvw48
https://www.githubstatus.com/incidents/d60fmldlvw48
#5:
Ay a los que dependan de "la nube"
Marronazo
Marronazo
#10:
Eso es por cambiar master a primary
Comentarios
Normal, Microsoft no puede estar a todo, o hacen chips o mantienen GitHub
#2 Los de IT están ayudando a meter las nuevas XBOX en las cajas.
#2 Si eso les mantiene apartados de poner actualizaciones a Windows 10 casi mejor.
#12 Eso es de lo mas preocupante, saber que tendremos que adelantar nuestros despertadores media hora para que se puedan actualizar los chips antes de iniciar el dia
#13 Actualizando sus chips, no se despierte todavía....... no hemos podido actualizarle, deshaciendo cambios.
Microsoft respuestas: ejecute sfc... dism... (da igual lo que preguntes).
#2 Chips & fish
#26 chiss uns fisss
#2 Chips Microsoft ?.
#36 Para las vacunas del 5G
#36 Claro. Los que introducen en las vacunas para controlarnos remotamente.
#2 Querrás decir chis.
Las fuerzas del mal, las fuerzas del mal, nos quieren controlar con un chis. con un chis, con un chis chis chis.
#2 Hoy apenas se ha caido un par de horas. Si siempre que se cae lo tenemos en portada tendríamos más noticias de Github que de Vox...
Dios mío y de dónde voy a copiar yo ahora todos mis desarrollos y cobrarlos a mis clientes como si los hubiese programado yo...
#8 Mientras las licencias sean libres y se lo expliques a los clientes, si el precio les parece correcto para el soft y soporte que reciben no habría ni que poner la cara de troll.
El día que Microsoft tenga un producto que no se cuelgue será cuando fabriquen perchas.
#42 me has hecho reír cabrón ja ja ja
Ay a los que dependan de "la nube"
Marronazo
#5 no soy muy partidario de la nube, al menos de las controladas por terceros. Pero en tecnología siempre hay dependencias, en un entorno sin nube o de nube privada se pueden romper switches, balanceadores de carga, u otras tantas cosas que también te fastidian el trabajo.
#32 La diferencia es que la rotura de un switch en una nube privada te jode a ti; la misma ruptura en "la nube" jode a miles de usuarios.
#57 Git es distribuido; si los desarrolladores saben usarlo bien, el único problema será el acceso a documentación o issues, y eso debería bastar para no quedarse bloqueados durante la caída, que no durará mucho previsiblemente.
Si no puedes trabajar sin un servicio remoto, algo está mal en el pipeline.
#80 Hombre, sí... git es distribuido... a nivel de la parte de código. Pero las listas de bugs, por ejemplo, eso está en el servidor. Y más cosas.
#5 En este caso no veo en que te afecta, git es distribuido y no necesita para nada conectarse a otro sitio para poder trabajar, así que lo de que deja a miles sin desarrolladores sin repositorios es una exageración de cuidado.
#58 Pasar cambios de un usuario a otro pasa de ser fácil a engorroso de cuidado si no has previsto una alternativa.
Siempre puedes hacer un targz con el repo y mandarlo por email, pero es algo coñazo
#69 No lo veo viable en proyectos medianamente serios. En proyectos de juguete, pues si.
#70 tan no-viable que muchas empresas lo hacen. Instancia "nube" de bitbucket e instancia "in-house" del mismo software. Sincronizados entre si.
Por poner ejemplo que use cada día.
(En este caso no es "barato" por eso de que son miles de usuarios, no cientos )
#75 #71 Se que hay muchas chapuzas por ahí y muchas empresas lo hacen, sin duda. Tampoco quería decir que no sea viable, técnicamente, pero es que un procedimiento de extracción manual de código y enviado en un zip o un tar a un email me parece cuanto menos peligroso. Desde luego que todo se podría automatizar vía Scripts y así le daría un voto de confianza, pero eso de tar, y luego adjuntar al email y luego el otro abriéndolo, no lo veo. Seguro que en no demasiado tiempo habría inconsistencias, descontrol en las versiones etc, etc...
#82 No es una chapuza, es como está pensado el proceso por el que inventó git y es como se usa en los repositorios de Linux. Git, el binario, tiene comandos para hacer eso, format-patch te crear el parche en el formato apropiado, send-email lo envía, y am aplica un patch desde un mailbox. El flujo no es enviar un correo, que alguien lo reciba y lo aplique a mano, el cliente de git lo gestiona todo.
#69 Distribuir un repositorio git que tengas es trivial, para eso está el git daemon, si quieres hacerlo ligeramente más complica usar claves SSH son un par de comandos más, así que no debería llevar más de 5 minutos reemplazar GitHub por otra máquina, sea de un desarrollador u otra que se tenga a mano. Una vez que tienes eso puedes hacer pull request, push o lo que se decida con los mismos comandos git, cambiando el remoto por supuesto. Yo lo he hecho un par de veces cuando el repositorio "principal" dejaba de funcionar por la razón que fuera y como solución de emergencia funciona perfectamente y es rápida de aplicar.
Si quieres hacer un tar.gz no lo haces del repositorio, lo haces con un patch, que también lo soporta nativamente git, por ejemplo se usa en los repositorios de Linux para enviar parches, y bueno, se inventó para eso y el tipo que lo inventó lleva las dos cosas, así que digamos que es un flujo más que probado y aceptado.
#70 Dudo mucho que haya mucha gente que trabaje en proyectos más grandes y descentralizados que Linux y usan parches para distribuir cambios, solo tienes que ir a la lista de correo del kernel y buscar PATCH para encontrarlos. Y no creo que Linux se pueda calificar precisamente como proyecto de juguete.
#69 o montar otro servidor de git y estar listo en minutos
#5 Si tu solo eres capaz de administrar un servidor fisico para tener un uptime del 99% te felicito pero la mayoria no puden https://www.githubstatus.com/uptime
#60 y no nos olvidemos, con millones de usuarios.
#62 #60
Tener un mirror local/Corporativo en un servidor que apenas tiene un centenar de usuarios para cuando "la nube peta" no sólo es fácil. Es fácil y barato.
Usar "la nube" no quita curràrtelo un poco para no quedar en bragas.
Para quien quiera hacer seguimiento de la incidencia...
https://www.githubstatus.com/incidents/d60fmldlvw48
Eso es por cambiar master a primary
Lo moverían a Azure...
Que prueben con AWS
#16 Tengo entendido que Azure no es tan malo. Yo de Azure lo único que he usado es su servicio Cognitive para detección de lenguas de textos.
#25 ahora usan Linux azure así que normal que no sea tan desastre.
#16 Yo he trasteado poco con esos servicios pero los compañeros que tengo siempre me han dicho que Azure va bastante bien. En parte si AWS tiene más cuota es porque salió antes y como funciona bien suele haber pocos motivos para asumir costes de migración.
Warning: este comentario se basa en opiniones de terceros, puede no ser 100% correcto
#37 En realidad es un "disclaimer", no un "warning"...
#56 Independientemente del tamaño del proyecto y como absoluto mínimo, cuando cambias la rama principal de este, deberías tener un procesado completamente automatizado que coja esa rama, la compile, la despliegue y pase todos los tests, y ya de paso que haga todas las tareas posteriores (como por ejemplo actualizar el paquete en npm si se trata de una libreria o desplegar directamente a staging o incluso a prod si es un proyecto personal que no va a afectar a nadie).
Yo eso no me lo saltaría ni en un proyecto donde solo trabaje yo, porque no hay ninguna garantía de que no la vaya a cagar haciendolo a mano o se me olviden cosas.
#59 +100
¿Por una caida temporal ya tenemos noticia en portada?
Si pusiéramos todas las de bitbucket íbamos a colapsar Meneame.
#40 Lo raro con bitbucket es que estén todos los servicios en marcha
#67 >99.5 de UpTime o eres un cuñado y has venido aquí a decir 4 palabrejas e ir de guay, o eres un cuñado que no sabe relativizar y como alguien dependa de tus sandeces...
Seguro que consigues mejor UpTime que GitHub/GitLab/BitBucket, segurísimo.
Por otra parte ya me dirás quien os quita tener repos propios en remoto y que se pusheen los cambios a ambos remote
#76 Yo no he dicha que lo haga yo. Me refería que quiere echarles y contrata una empresa más seria y con más experiencia básicamente.
#84 pero que empresa más seria, no te montes películas que caídas las tiene cualquier otro servicio. Lo único que puedes hacer es redundar con algún mirror para evitar caídas de... ¿Un par de horas y muy puntuales? Ya lo tienes que justificar bien justificado en esa junta de accionistas
#76 Ahí tienes un 99.81% sin ir mas lejos, https://atlas.ripe.net/probes/18273/#!tab-network, en los últimos casi 6 años.
Salu2
#89 no entiendo a qué viene el enlace
#94 Normal
#95 sí, porque es un manzanas traigo de manual
#96 No me digas? Es una sonda Atlas del Ripe, da información del SLA entre otras cosas de forma pública de muchos proveedores de servicio y de quien pida una, son gratuítas, y es mas del 99,5 que mencionas como que es imposible. Te demuestro que no lo es, si te he entendido mal, disculpa.
Salu2
#97 Nadie ha dicho que sea imposible dar más de un 99.5%, de hecho el mismo GitHub del que se está hablando lo hace en la práctica totalidad de los meses (no conozco el % historico de los últimos 5 años pero me imagino que estará por encima del 99.8 viendo los historicos mensuales que son por lo general un 100% desde 2014).
La conversación iba de servicios de control de versiones y contestaba a otro usuario porque me pareció muy graciosa su intervención de "ya lo decía yo en las juntas de directivos, que era malo tener las cosas en GitHub, si por mi fuera estarían todos despedidos". Simplemente le señalaba que GitHub tenía más del 99.5% (99.5 porque es ligeramente peor que el peor de los últimos meses de GitHub: 99.67) y que me parecía un ejercicio de fantochería supina su intervención, como si fuese a conseguir un Up Time claramente mejor que GitHub con otra solución o fuese un motivo relevante para desperdiciar el dinero que supone migrar a otro sistema de control de versiones en una organización.
#98 Gracias por tomarte el tiempo en aclararloaclararlo, pero no veo porqué no puede tener un uptime mejor si se lo curra.
#99 No digo que no pueda, repito, no iba por ahí el mensaje. Estaba dirigido hacia el "oh dios mío, llevo años diciendo que no era buena idea tener todo en GitHub y los jefes de proyecto no me hacían caso, cambiaré a todos los equipos de desarrollo y contrataré a otros más competentes" que dijo el otro usuario, como si GitHub hubiese tenido una caida de varios días o como si la caida puntual de una hora un mes justificase su "¡te lo dijeeeeeeee!".
Mira que hay razones para no tener el código en GitHub (privacidad, por ejemplo) pero no creo que el Up Time sea una de ellas.
A esta hora, sigue off..
#1 a mi me va...
https://i.imgur.com/aiWH2vZ.png
https://i.imgur.com/xFrFTTk.png
#3 pues será por zonas... he renovado todo lo renovable, DNS, Caché... tocará esperar pues.
#6 no se, me va tanto en local (movistar) como en remoto (ovh francia)
#1 Ahora (13:15h) a mi me va...
https://github.com/mcwhorpj/demoImages
#1 #17 A mi también me chuta ya, pero me ha dado una mañanita...
#45 Ironía de la vida pero esa noticia me hara ganar algo mas de pasta este mes o el que viene.
Si me dejan hacerlo, muchos acabarán despedidos por irresponsables e ignorantes sin ninguna duda.
Hace años que aviso a muchas empresas que no es buena idea tenerlo todo en GitHub. Los jefes de desarrollo siempre me han llevado la contraria.
A ver cómo lo defiende en la siguiente junta de directivos,
#67 Tampoco creo que tener un sistema propio te libre de estas cosas... de todas formas mi organización es tan bestia (en tamaño) que cambiar eso es utópico
#73 Este es el principal problema.
#73 No te libra, simplemente manejas tu el riesgo y el impacto
#73 No sería utópico, simplemente sería (jodidamentr) caro
#67 me temo que como tu mayor argumento sea esta noticia los jefes de desarrollo van a seguir llevandote la contraria. Lo siento por tu cuenta corriente.
#67 Se trata de un problema de service continuity... has hecho muy bien reportando que confiar en un tercero para la provisión de un servicio entrañaba un riesgo, lo que pasa que tal como lo has planteado queda un poco “cutre”: “No es una buena idea”.
Vamos a presentarlo un poco decente pues...
Existe un riesgo de impacto en las tareas de ¿desarrollo? Y se recomienda establecer el servicio de “xxxx?” por medios propios mediante el aprovisionamiento de “?”
A1-. Coste de Licencias: xxxxxxx mil euros/año
A2- Coste de infraestructura: xxxxxx mil euros/año
A3- Coste en personal desarrollo, implantación y mejora continua: xxxxxx mil euros/año
B1- Coste en personal operaciones: xxxxx mil euros/año
B2- Coste en formación y transición: xxxxx mil euros/año
C1- MTBF: xx días
C2- MTTR: xx horas
Z- Coste por hora de interrupción
Coste servicio: Sum(Ai) + Sum(Bi) + ( f(Z, C1, C2) ) euros/año
Si realmente se han aterrizado estos números para la solución actual de tu empresa, y tu propuesta alternativa, siendo claramente favorables estos números en tu alternativa, y no se ha optado por ella, no es que vayas a ganar mucho dinero, es que realmente deberías irte ya, porque tu empresa está abocada a la ruina.
Suerte con ello!
#91 Gracias por tu respuesta. Es normal que parezca un poco cutre para alguien que controla del tema.
Lo que quiero es cambiarlos porque digamos que les falta algo de experiencia y de visión.
Y no es que lo diga yo, lo consulte con otros profesionales del sector y me han puesto algunos ejemplos de errores básicos. Llevan muchos años con nosotros pero profesionalmente no han crecido al mismo ritmo que la empresa.
Cual es el error ¿Un BSoD en verde o en azul?
#15 En Azure, siempre en Azure
Que pena... hace tiempo que me cambie a gitlab
#27 Como si Gitlab no se cayese bastante más que GitHub.
P.S. Yo también trabajo con gitlab, aunque mis repositorios personales aún siguen y seguirán en GitHub.
#31 cuestión de gustos. Solo era un chascarrillo
#27 Bueno, gitlab sigue conservando su puesto en el top de caídas míticas con su rm -rf en producción
https://www.theregister.com/2017/02/01/gitlab_data_loss/
Pues sera casualidad ,pero nuestro servidor de gitlab local en la empresa estuvo tambien tontorron hoy , y la unica manera de que nos dejara conectar era conectar en remoto al server donde estaba alojado y hacer un ping a la maquina cliente , y a partir de ahi , a funcionar el interfaz web tan pichi...
GitHub se cae y… no, no deja sin repositorios a los desarrolladores porque los repositorios de Git son locales.
Vamos, que los desarrolladores van a poder seguir trabajando sin ningún problema. Lo que ha dejado de funcionar son los pull requests (peticiones para mezclar código), cosa que se puede hacer por infinidad de otros medios (por correo, como hacen con Linux, por ejemplo), y alguna que otra característica como los builds/deploys automáticos.
¿Que es una putada que GitHub se caiga? Por supuesto. Pero ni de coña impide trabajar a los desarrolladores ni estos se quedan sin repositorios.
#14 El paquete que viene en Debian es "firmware-realtek", pero no viene soportada la tarjeta de la wifi que me vino en el HP.
https://packages.debian.org/bullseye/firmware-realtek
Editado. Este modelo no funciona con firmware-realtek:
$ lspci | grep Wireless
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter
Pero con el driver que encontré en GitHub funciona bien, perfecto.
#30 Pues ya sabes no formatees ni reinstales el driver hasta que funcione github, y haz backup del instalador, tar.gz etc...
Pd: A veces en Debian testing suelen quitar paquetes, no sé si es porque tienen muchos bugs o rompen algo, generalmente drivers o firmware.(Y por una vez parece librarse nvidia).
-Pasó algo muy malo
+¿Se ha caído stackoverflow?
-No
+¿Se ha caído github?
-Sí
+¿Pero a stackoverflow no le pasa nada?
-Ahá
+Entonces no importa
#41 Continuous Integration
#43
Me has dejado igual. A ver, a no ser que sean megaproyectos si 2 menganos estan programando pueden seguir igual hasta que tengan que subir el codigo y les toque ver los posibles conflictos. Sin saber mucho de git.
Dejarían el mantenimiento al departamento de actualizaciones de Windows 10...
Salu2
https://nimbleindustries.io/2020/06/04/has-github-been-down-more-since-its-acquisition-by-microsoft/
Primer dia de la migración de github a servidores con windows....
Mejor eso a que los dejen sin supositorios...
(Perdón).
Estamos locos? Los programadores vamos a tener que resolver nuestros propios problemas!!!
Las ventajas de la nube...
Pues mejor para la humanidad.
Es hora de tener otro espacio a git
algo tenía que aportar Microsoft...
¿GitHub es de Microsoft? Pues ahora me entero. No hace mucho usé ese sitio para descargar un driver y así poder usar Wi-Fi con GNU/Linux Debian Bullseye ya que no está en el repositorio oficial.
https://github.com/tomaspinho/rtl8821ce
#11 Juraría que hay un paquete para realtek (rtlwifi) o tu wifi es muy nueva o muy rara. ¿Usb?
#11 GitHub nació de forma independiente en 2008, y hace dos años, en 2018, fue comprado por Microsoft, aunque ya llevaba bastantes años siendo el repositorio de la mayoría de proyectos de software libre.
#11 Desde hace 2 años. 7500 milloncetes
Microsoft confirma la compra de GitHub por 7.500 millones de dólares
Microsoft confirma la compra de GitHub por 7.500 m...
hipertextual.comPero se supone que mientras no tengas que subir los cambios con la copia local de tu equipo tiras no?
#22 Sí
#22 La CI acostumbra a tirar de la versión del repo.
#29 La que?
Seguro que los servidores están mostrando la pantalla azul de la muerte. Aún estarán reiniciándolos... (o instalando la ultima actualización de Windows 10).
Vamos a ver. Muy mastuerzo has de ser para no poder centrarte 2-3 horas en el repositorio local. Yo hoy no me he enterado.
Ya son ganas de buscar el click fácil. Vaya notición
Realmente parece que fué algo de caché de IPs v4. Yo cambiando la Ip de salida me funcionó (6 A.M.). Sigo ok.