Hacker Newsnew | past | comments | ask | show | jobs | submit | xvilka's commentslogin

> Github is doing some classic big org sneaky things where they don't count degraded service fully.

Even worse example is the Travis CI. For more than a year their CI jobs sometimes get stuck or do not start for days, and, surprise-surprise, it's never shown at their status page[1] - always green. We would switch to something else entirely if not the unique offering of PowerPC and SystemZ servers/runners. Apart from that - it's the worst CI service I used so far.

[1] https://www.traviscistatus.com/history


All the more reason to donate to Forgejo/Codeberg[1][2] or contribute the code to SourceHut[3].

[1] https://liberapay.com/forgejo

[2] https://donate.codeberg.org/

[3] https://sr.ht/~sircmpwn/sourcehut/


Does it still use Zilog eZ80 (Z80-family, 24-bit) as the main CPU?

Loosely related is the exoplanets catalog (open source)[1][2].

[1] https://exodata.space/

[2] https://github.com/oiwn/exoplanets-catalog


And Azure still doesn't support IPv6, looking at the GitHub[1].

[1] https://github.com/orgs/community/discussions/10539


Perhaps they should use OpenAI models to figure out how to rollout IPv6.


Some food for thought:

  If GitHub flipped a switch and enabled IPv6 it would instantly break many of their customers who have configured IP based access controls [1]. If the customer's network supports IPv6, the traffic would switch, and if they haven't added their IPv6 addresses to the policy ... boom everything breaks.

  This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And customers hate it when things suddenly break no matter how well you go about it.
https://news.ycombinator.com/item?id=47790889


I don't get it.

For every customer which has access controls configured based on IPv4 (sounds crazy enough already), GitHub would configure a trivial DENY ALL policy for IPv6. Problem solved.


that's the scenario they want to prevent. they can't force the client to use ipv4, if they connect via ipv6, they will be served an accss denied.


Yes, exactly as they would now, when the access over IPv6 is entirely unavailable.

With that, the customers who don't use filtering by IPv4 would be able to use IPv6. Those who do use access control by IPv4 ranges would have time to sort out their IPv6 setup, without having anything broken at the moment when IPv6 is enabled.


No, if you have a dual-homed stack right now, and they only expose IPv4, you connect over IPv4, you don't attempt to connect over IPv6 and get connection denied.

That's rather the problem - there's no trivial way to mimic that policy transparently while enabling IPv6, because most stacks will default to using IPv6 if they're dual-homed and expose both, and won't fall back if IPv6 connects but gives an error. (Offhand, I think the best you could do would be to tell everyone that you're migrating to a new URI scheme to allow cloning, with IPv6 enabled, and that as part of that, you'll have to update your allow/deny rules, then, after a truly astonishingly long time and lots of nagging of anyone who never does it, make the old path an alias of the new one and let the last remaining people break.)


I suppose that customers who set up access controls based on IPv4 address ranges must be running an UPv4-first stack, most likely IPv4-only.

Now they can use Claude Code.


I was under the impression that as long as GitHub doesn't support IPv6 it is a sign that they still haven't finished their migration to Azure. Azure supports IPv6 just fine.


Supports IPv6 just fine? Absolutely not, they have the worst IPv6 implementation of the 3 large clouds, where many of their products don't support it, such as their Postgres offering. See https://news.ycombinator.com/item?id=44881803 for more.


lol GitHub doesn’t run on azure at msft

They still run their own platform.


Github CEO threatened the entire stack was in the process of migrating to Azure.

https://thenewstack.io/github-will-prioritize-migrating-to-a...


I talked to github devs last week in person, when a lot of the AzDo team was brought over years ago the migration started happening.


Well, you see, they just can't find a checkbox for ipv6 support in the IIS GUI on their ingress servers.


Rizin[1][2] does exactly this, also there is a compact hex-II[3] mode.

[1] https://rizin.re

[2] https://github.com/rizinorg/rizin

[3] https://speakerdeck.com/ange/no-more-dumb-hex


Zellij still can't hide/show the status bar on the fly[1] and doesn't support windows preview in the windows list mode. Just these two (and many more) things are enough to stop me from migrating from tmux.

[1] https://github.com/zellij-org/zellij/issues/694


You can't rebind plugin maps, so the session picker uses my preferred unlock chord to create a session. Dev had no interest in changing that.


Will this mean the end to NeoVim, whose main (one of) selling point is the tree-sitter out of the box? I hope not, as I am the long time user and supporter of the project.


Very strange attitude towards open source. One guy decides to stop working for free, leaving all of his work publicly accessible for anyone to continue to build upon, and the response is "well, I guess that's the end of that project".

I'm guessing the attitude of "users and supporters" of the project such as shushtain complaining and wanting clason to do all the work instead of just doing it themselves, was a factor in him deciding to step away from the project.


tree-sitter still works. Many features are implemented in neovim itself. This project provides an easy way to set up parsers for various languages (including installation and retrieval of necessary queries), along with some quality-of-life features. You can just fork it, and it will work perfectly fine for the 0.12 cycle (barring any underlying parser changes), or you can fork the previous version on the master branch if you want to keep using 0.11.

Considering this is a very common plugin in the neovim ecosystem, it will probably get forked and maintained by someone else, like null-ls was forked into none-ls.


More importantly, it also reduces CPU and memory load.


Nowadays we have Unicode characters and better colors though.


MS-DOS always had better colors than UNIX, a framebuffer isn't the same a vt100.

I do agree Unicode is better than code pages, or doing alt + num pad codes.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: