What is Hackers' Pub?

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

0
0
0

Since some people have asked me if I they could collaborate on my rust IPS work, I decided to publish the Repo now on @Codeberg
codeberg.org/Toasterson/ips

Note: illumos is the main OS using this package manager but we should make this available for many operatingsystems as we can,

Happy if someone makes ipsOS based on linux aswell. (Please choose a better name though)

The Goal is to bring the IPS innovations to as many people as possible.

0
0

ICE told nurses this Minneapolis man “purposefully ran headfirst into a brick wall.” What actually happened is that they pulled him from a car, beat him so viciously with a steel baton that he had 8 skull fractures, 5 life-threatening brain hemorrhages, and couldn’t remember he had a daughter.

MINNEAPOLIS (AP) — Alberto Castañeda Mondragón says his memory was so jumbled after a beating by immigration officers that he initially could not remember he had a daughter and still struggles to recall treasured moments like the night he taught her to dance.

But the violence he endured last month in Minnesota while being detained is seared into his battered brain.

He remembers Immigration and Customs Enforcement agents pulling him from a friend’s car on Jan. 8 outside a St. Paul shopping center and throwing him to the ground, handcuffing him, then punching him and striking his head with a steel baton. He remembers being dragged into an SUV and taken to a detention facility, where he said he was beaten again.

He also remembers the emergency room and the intense pain from eight skull fractures and five life-threatening brain hemorrhages.
0
0
0
0
0
0

What is your personal "Killer App"? You can choose only one.

0
0
0

소망: 서두르지 마라, 머지않아 이루어진다 기다리는 사람: 장애가 있어 오지 않는다 잃어버린 물건: 찾기 어려움, 아래에 있음 여행: 여의치 않으니 보류하라 장사: 사는 것은 손해니 자제하라 학문: 안심하고 면학에 힘쓰라 시세: 팔아라, 큰 이익이 있다 다툼: 때를 기다리지 않으면 이길 수 없다 연애: 장래에 행복해진다 이사: 움직이지 않는 편이 좋다 출산: 순산이나 조심하라 질병: 생각보다 중함 혼담: 갑작스럽게 성사되기 어려움. 기다리면 좋은 인연을 만난다

0

(인간 OCR + Kagi 번역) 제27번 み吉野は 요시노는 山もかすみて 산도 안개 끼어 白雪の 흰 눈이 ふりにし里に 내린 마을에 春は來にけり 봄은 찾아왔구나 (후지와라노 요시쓰네) 운세 「중길」 처음에는 근심거리가 있겠으나, 놀라거나 방황할 필요는 없습니다. 나중에는 모든 것이 평화롭게 가라앉습니다. 마음을 차분하고 바르게 가지면 행복이 오래 지속될 것입니다.

0
0
0

.NET IDE의 핵심은 벤더 락인에 묶여 있고, GUI 프레임워크는 Windows에 치중되어 있습니다. 저는 이 문제를 AI 코딩 에이전트의 힘을 빌어 풀어보기 위해 저와 같이 닷넷데브 운영진으로 활동하시는 송영재 님께서 만든 크로스플랫폼 UI 프레임워크 MewUI로 오픈소스 .NET IDE, LibraStudio를 만들기 시작했습니다.

그러나 난관은 AI가 이 프레임워크를 전혀 모른다는 것. 제가 만든 HandMirror MCP로 어셈블리를 직접 검사해 AI에게 정확한 API 정보를 제공하여, 첫 빌드만에 오류 단 3개로 빠르게 구현을 마칠 수 있었습니다. 그 과정을 정리하여 공유합니다.

👉 https://devwrite.ai/ko/posts/why-i-use-handmirror-mcp/

0
0
0
0
0
0
0
0
0
0

Today's my birthday and I just received the most wonderful gift ever. My children spent the past two weeks writing and drawing stuff, and I had no idea what they were toiling on. Turns out they wrote a D&D adventure, complete with pre-rolled characters, for me to play. They've used the Old School Essentials rule book and little else. They'll be the ones mastering, of course. I can't wait.

0
0
0
0
0
0
0
0
0
0
0
0

I have deeply mixed feelings about 's adoption of JSON-LD, as someone who's spent way too long dealing with it while building .

Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.

But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.

Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.

Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.

2
12
1
0
1
0
0
0

上星期日揪伴侶去看古蹟,早上嫌冷不去(但他自己去做運動…
下午他又要回家了

這個星期他說他會去,但現在一樣冷而且還下雨了 :ablobdundundun:

0

I have deeply mixed feelings about 's adoption of JSON-LD, as someone who's spent way too long dealing with it while building .

Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.

But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.

Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.

Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.

2
12
1
0
0
0
0
0
0
0
0
0
0