Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Disruption with Some GitHub Services – Resolved

githubstatus.com

Post reply on HN
Print view View original

141–150 of 176 posts

Re: Disruption with Some GitHub Services – Resolved

#141

Post by Etheryte »

caust1c wrote: post #69
shepardrtc wrote: post #44

Fun read about Azure and having 173 agents running a node: https://isolveproblems.substack.com/p/how-microsoft-vaporize... Probably just a coincidence that Github started to have issues after beginning their move to Azure at the end of last year.

Azure's going to suffocate github. I'm curious to see what's next. Will self-hosting the code repository come back in vogue or will another social-coding platform take off?

To be honest, I'm very much surprised Amazon hasn't eaten Microsoft's lunch here. Offer out-of-the-box AWS instances with Gitlab, SLAs, backups and the works, should be straightforward.

Re: Disruption with Some GitHub Services – Resolved

#142

Post by spockz »

timcambrant wrote: post #137
tonyhart7 wrote: post #109

Earlier quoted context omitted.

I hording my tab in case I need them later (I don't, 99% of the case) but I always have sense of fear that I might need it someday

Every 3-6 months I purge all my tabs, but always dump all URLs to an html file in case I will need them in the future. You never know!

That is just called your browser history?

Re: Disruption with Some GitHub Services – Resolved

#143

Post by spockz »

dijksterhuis wrote: post #118
hosh wrote: post #104

Earlier quoted context omitted.

If people are happy with Actions API, that sounds great. I’m not happy with the Actions API. I think Gitlab’s cicd design is much better, and I’m not fighting it all the time when I use it.

i'll echo this sentiment. historically there's been a lot more flexibility with GL CI yaml syntax, including real yaml anchors https://frenck.dev/github-actions-yaml-anchors-aliases-merge... sys-admin-ing gitlab can be a bit of a maze of web menus tho.

What do you need real anchors for? Sharing of pipelines?

Maybe I’ve been burned too much by pipeline maintenance (because we didn’t have yaml anchors?) but I rather have builds defined in make /bazel/etc than in yaml. So the only thing the pipeline does is optionally restoring caches, kicking off the build system, uploading PR validation results, and saving cache. Pushing artifact etc is all done from inside the build system.

There is no “setup” like installing packages because we make the build image seperately.

Re: Disruption with Some GitHub Services – Resolved

#144

Post by embedding-shape »

timcambrant wrote: post #135
embedding-shape wrote: post #121

Earlier quoted context omitted.

> "Why would you recommend extensions to do this?" This is not my complaint though, my complain is: Why would you recommend extensions you haven't tried nor even read about yourself? The goal isn't to pick apart the message to piss someone off, the goal is prevent someone else than the author from getting hacked because they install some random extension, not understanding what kind of access you're giving others whe…

They didn't recommend the extensions. They linked them because they were "merely sharing to build on for this discussion". Is all content in HN supposed to be professional and serious, or are humorous comments in fact allowed when discussing a market leading company who has had regular outages for a year and a half? (Yes, I know the actual reasons why GitHub are struggling.)

> Is all content in HN supposed to be professional and serious

No

> are humorous comments in fact allowed

Yes

Neither is what's going on here. It's reckless to share stuff you haven't even looked at yourself, that's fairly basic thing to care about. Sharing "here's a bunch of random GitHub repositories" isn't humor (I think?) nor would it been different if the text was "more professional and serious", whatever that means.

Why you so mad about someone trying to help others from getting hacked? Install all extensions you want, based on what someone recommend or what you find randomly on YouTube, but let others be educated about what that means for their own security, not sure who that hurts and why you'd wanna stop it.

Re: Disruption with Some GitHub Services – Resolved

#145

Post by swozey »

anvuong wrote: post #102
caust1c wrote: post #69

Earlier quoted context omitted.

Azure's going to suffocate github. I'm curious to see what's next. Will self-hosting the code repository come back in vogue or will another social-coding platform take off?

I used to work in a small independent team of 30 people within a large corp, half of which was dev. We used to run our own gitlab on-prem, our CI/CD was also on-prem. It worked perfectly, never had down time, devops guy could configure them on-demand to our needs. Me (and some other guys) also jumped in times to times to help (mostly just ssh into the servers for health check, disk partition, etc.). Then we grew (the…

PMs deciding software infrastructure over the dev teams that the dev teams use, is wild.

Re: Disruption with Some GitHub Services – Resolved

#146

Post by donmcronald »

zaik wrote: post #52
tomw1808 wrote: post #36

Things can go wrong, but really, its been a lot and we're normalizing that to an unhealthy degree... I wonder if it was down that much, if users would get credits the way we pay when we use the services - its kind of ridiculous for a critical service to be down that much and all we do is "ah okay, its just github". Like, as if that was normal to be down that much...

I think the authors of SMTP had a healthy attitude towards server uptimes: Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4....

I saw an application once about 25 years ago that was built on SMTP for communication. I think it was an inter library loan system, but can't remember for sure. I was a pretty smart way of not having to worry much about redundancy in the communications.

Re: Disruption with Some GitHub Services – Resolved

#147

Post by denkmoon »

VladVladikoff wrote: post #134
sandermvanvliet wrote: post #126

Earlier quoted context omitted.

As a joke I built an extension to the GitHub CLI called “omens” so you can run “gh omens” before you’re planning to use GitHub and it’ll tell you if it’s likely to work in idiomatic Aussie. As an example: $> gh omens reckon github's about to go full bin chicken —- You can find it here: https://github.com/sandermvanvliet-stack/gh-omens

>go full bin chicken LOL is this really something Aussie's say? That’s hilarious!

Bin chicken is local slang for these horrible birds ( https://en.wikipedia.org/wiki/Australian_white_ibis ), and “go full x” is also a common utterance, but I’ve never heard them said together like that.

Re: Disruption with Some GitHub Services – Resolved

#148

Post by FridgeSeal »

denkmoon wrote: post #147
VladVladikoff wrote: post #134

Earlier quoted context omitted.

>go full bin chicken LOL is this really something Aussie's say? That’s hilarious!

Bin chicken is local slang for these horrible birds ( https://en.wikipedia.org/wiki/Australian_white_ibis ), and “go full x” is also a common utterance, but I’ve never heard them said together like that.

Ibis’ are fantastic creatures, and don’t deserve the scorn you’ve heaped upon them!

Their bin-chicken status is testament to their adaptability, but it’s essentially our fault they’re that way.

Re: Disruption with Some GitHub Services – Resolved

#149

Post by vinnymac »

dijksterhuis wrote: post #118
hosh wrote: post #104

Earlier quoted context omitted.

If people are happy with Actions API, that sounds great. I’m not happy with the Actions API. I think Gitlab’s cicd design is much better, and I’m not fighting it all the time when I use it.

i'll echo this sentiment. historically there's been a lot more flexibility with GL CI yaml syntax, including real yaml anchors https://frenck.dev/github-actions-yaml-anchors-aliases-merge... sys-admin-ing gitlab can be a bit of a maze of web menus tho.

I find this recommendation funny, because I completely agree from a sysadmin perspective.

I used to use Gitlab at work, and small teams would run into so many footguns with CI that we had to throw up guardrails to prevent mistakes. Far too many links to gitlab issues that were not fixed even after >8+ years of being open ended up biting us. With GHA I haven't had that experience, and same for all of my self hosted Forgejo instances. I used to hate using GHA from about ~2018 to 2021, but they've fixed a lot of things I disliked since then.

Re: Disruption with Some GitHub Services – Resolved

#150

Post by timcambrant »

spockz wrote: post #142
timcambrant wrote: post #137

Earlier quoted context omitted.

Every 3-6 months I purge all my tabs, but always dump all URLs to an html file in case I will need them in the future. You never know!

That is just called your browser history?

The browser history contains a lot of junk and I don't want that saved forever. Curated tab history is a bit different. It's stupid for sure, but also a bit comforting to keep the most important articles and such. For anything I really care about, there's always ArchiveBox.
Post reply on HN