Here is the link to the original website (an NGO that monitors blocked websites in Turkey): https://ifade.org.tr/engelliweb/distrowatch-erisime-engelledi/

And here is the Google translation of the text on that page:

The IP address of the DistroWatch platform, which provides news, reviews, rankings and general information about Linux distributions, was blocked by the National Cyber ​​Incident Response Center (USOM) on the grounds of “IP hosting/spreading malware”.

Who is this particular developer

As far as I understand from the discussions about the topic, Maxim Dounin was one of the few core developers of nginx. Looks like Wikipedia has already been updated.

The URL seems to have a typo. Correct URL is https://github.com/presslabs/gitfs

https://www.docs.bsky.app/blog/feature-bridgyfed

I know you said “self hosted”, but if you are interested in an Android app, Google Play Books does most of what you want, I think. You can upload your books, and read them on any device (with offline capabilities). But this is the Self Hosted community, so I will show myself out.

I don’t follow it very closely, but as far as I know, they are the only one implementing the open protocol they designed (which doesn’t interoperate with ActivityPub). However, there seems to be some efforts for creating a bridge: https://www.docs.bsky.app/blog/feature-bridgyfed

As you said, there are some recognizable faces and that may impact the adoption. But not being compatible with ActivityPub is a real bummer.

deleted by creator

I think single account ActivityPub implementations are addressing a weakness of the Fediverse: one’s identity (handle, username) is tied to an instance they have no control over. If that instance shuts down users lose everything. With a single account instance, you take that control back. And since it doesn’t need to scale the architecture can be much simpler and can be deployed to much cheaper infrastructure.

The demo was not straightforward, though. And I didn’t quite get how a user can follow Mastodon users, for example.

Possibly. My point is: despite having a common subset Pkl and JSON schema doesn’t seem to be solving the same problems. But, I’m just learning about it, so I may just be wrong.

I just learned about Pkl, so take this with a grain of salt. JSON Schema and Pkl seem to have some overlap. But JSON schema is not specifically designed for handling configuration and Pkl supports other formats like YAML.

This looks really interesting. Getting type safety and editor support to configuration may change quite a bit of how things are done. I don’t know if it will gain traction, but if it does, it may really help bringing some long awaited structure to all those YAML files. There appears to be examples specifically for Kubernetes (https://github.com/apple/pkl-k8s-examples).

I wasn’t aware of that. I guess it was thought to be a mod driven community. Anyway… Cool question. I hope we will see some creative solutions here.

Please also consider posting to [email protected]

deleted by creator

[email protected]

That’s explained at the end (Revisions). Fowler is probably looking for a general term that can be used to describe this specific way of debugging. Since he is aware of git bisect (and I’m sure he knows about hg bisect) there must be a reason he is not preferring “bisect debugging,” for example.

Edit: The term diff has a clear link with version control. bisect is not that obvious. It may be ambiguous/vague in debugging context. I would still call it “bisect debugging.”

Beginning in Git 2.43, Git will realize when it’s about to perform a double-revert, and instead produce the much more pleasing message

Doesn’t happen very often, but I’m glad we have a better solution to this now.

This sounds more like a Github question.

Reading the manual? That’s cheating!

Apart from the historical value, the most important part of this article now is the “Note of reflection” added 10 years after it’s inception:

If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

I don’t think this work flow is relevant any more even for teams that don’t do CD, to be honest. It was a messy work flow to begin with and I haven’t seen it applied successfully in practice.