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
1
0
0

김치 드세요, 두 번 아니 세 번 드세요💪

자고로 엄마 할머니 말만 잘들어도
자다가도 떡이 나온다규🙈

김치는 세포 수준에서 면역력을 미세하게 조절하는 것으로 밝혀졌습니다.

획기적인 인체 임상 시험에서 연구진은 최첨단 단일 세포 유전자 분석을 활용하여 김치가 면역 체계에 미치는 영향을 조사했습니다. 12주 동안 과체중 성인들에게 위약 또는 두 가지 종류의 김치 분말을 섭취하게 했습니다. 연구 결과는 김치가 면역 방어력을 강화할 뿐만 아니라 면역 체계의 조절에도 도움을 준다는 것을 보여줍니다.

세계김치연구소의 과학자들은 김치를 섭취한 참가자들이 세균이나 바이러스 같은 병원체를 식별하는 데 중요한 역할을 하는 항원 제시 세포(APC)의 활동이 증가하는 것을 관찰했습니다. 동시에 CD4+ T 세포는 위협에 맞서 싸우는 효과기 세포와 과잉 반응을 방지하는 조절기 세포를 모두 포함하는 더욱 균형 잡힌 프로필을 나타냈습니다. 이러한 이중 효과는 면역 체계가 유해한 염증을 피하면서 효과적인 반응을 일으킬 수 있도록 해줍니다.

이번 임상시험에서는 단일 세포 RNA 시퀀싱(scRNA-seq)이라는 정밀한 기술을 활용하여 개별 면역 세포의 유전자 발현을 분석함으로써 일반적인 혈액 검사로는 감지할 수 없는 미묘한 변화를 밝혀냈습니다.

발효 방식이 결과에 영향을 미쳤다. 자연 발효 김치와 스타터 배양 김치 모두 유익한 효과를 나타냈지만, 스타터 배양 김치가 항원 검출 능력 향상 및 불필요한 면역 신호 감소 등 더 우수한 효과를 보였다.

이는 김치의 면역 조절 작용이 유전적 수준에서 세계 최초로 임상적으로 입증된 사례로, 과민성 면역 질환 관리에 대한 김치의 가능성을 보여줍니다.

["Single-cell RNA sequencing reveals that kimchi dietary intervention modulates human antigen-presenting and CD4⁺ T cells." npj Science of Food, 2025]

0
0
0
1
1
1
0
1
0
0
0
2
1
0
1
1
1

One thing I really want to stop putting off and actually do in 2026 is setting up my own infrastructure (some VPSes, etc) and move away from the long term academic sysadmin mistake of running everything through work because it's convenient.

(But running my own servers is a pain. And I do it professionally.)

0
1
1

🕐 2026-02-20 00:00 UTC

📰 クラウド型コーディングエージェントの時代がまた来る (👍 88)

🇬🇧 Local coding agents hit cognitive limits. Cloud-based agents poised for comeback as they better handle complexity & reduce developer load.
🇰🇷 로컬 코딩 에이전트가 인지 한계에 도달. 클라우드 기반 에이전트가 복잡성을 더 잘 처리하며 재부상할 것.

🔗 zenn.dev/ubie_dev/articles/925

0
1
0
0
0
0
1
0
1

"殺生ヒュッテは、もともと「殺生小屋」という名称で建てられた小屋ですが、その後「殺生ヒュッテ」に改名した歴史がありますので、元の名称に戻すこととなります。"

施設名称の変更について | あるじの視線 | 槍ヶ岳山荘グループ yarigatake.co.jp/view/17317/

0

I just found out it's illegal to mod your EV to have custom engine noises. For "safety reasons." But realistically, how enforceable is that? If you get pulled over when your car plays a looped sample of Snoop Dogg saying "this Volt is in reverse," what's to stop you from claiming that Snoop Dogg was in the passenger seat doing live commentary, and ran off on foot?

0
0
1
0
1
1
2
0

"수십 년간 땀 흘려서 농사를 지으면서 우리 사회에 기여한 점을 감안하여 감형한다"거나 혹은 "산업재해와 저임금에도 불구하고 수십 년간 땀 흘려 일하면서 이 나라 산업을 이만큼 발전시키는 데 기여한 공로가 있는 노동자이므로 감형을 한다" 이런 예를 본 적이 없습니다. 혹시 보신 적 있습니까?" 공직(같은 소리한다) x 고위 공무원, 정치인 대상 평등하지 않은 법 적용 반드시 때려잡아야 한다. 안 그러면 다들 판검사님한테 칼부터 들이댈 거니까.

0
0
0
2
0
1

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.

@hongminhee洪 民憙 (Hong Minhee) :nonbinary: from the point of view of someone who is "maintaining" a JSON-LD processing fedi software and has implemented their own JSON-LD processing library (which is, to my knowledge, the fastest in it's programming language), JSON-LD is pure overhead. there is nothing it allows for that can't be done with

1. making fields which take multiple values explicit
2. always using namespaces and letting HTTP compression take care of minimizing the transfer

without JSON-LD, fedi software could use zero-ish-copy deserialization for a majority of their objects (when strings aren't escaped) through tools like serde_json and Cow<str>, or
System.Text.Json.JsonDocument. JSON-LD processing effectively mandates a JSON node DOM (in the algorithms standardized, you may be able to get rid of it with Clever Programming)

additionally, due to JSON-LD 1.1 features like @type:@json, you can not even fetch contexts ahead of time of running JSON DOM transformations, meaning all JSON-LD code has to be async (in the languages which has the concept), potentially losing out on significant optimizations that can't be done in coroutines due to various reasons (e.g. C# async methods can't have ref structs, Rust async functions usually require thread safety due to tokio's prevalence, even if they're ran in a single-threaded runtime)

this is
after context processing introducing network dependency to the deserialization of data, wasting time and data on non-server cases (e.g. activitypub C2S). sure you can cache individual contexts, but then the context can change underneath you, desynchronizing your cached context and, in the worst case, opening you up to security vulnerabilities

json-ld is not my favorite part of this protocol
0