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

息子のためにgpt-imageでt2i生成する簡単なWebアプリを作ってあげたのだが、自分のiPadやiPhoneの待受を作るために楽しそうに使ってくれている。生成過程をチェックすると、プロンプトでそこそこ指定できるようになってきた。
下書きをアップロードする機能もつけてあげるとしよう。

0

[공유] 베네수엘라에 대한 미국의 군사개입에 대한 국제 노동조합 성명서 모음 nodong.org/statement/79... 베네수엘라를 공습하고 마두로 대통령을 체포한 미국을 규탄하는 국제노동조합들의 목소리가 높습니다. 국제노동조합들의 성명서를 공유합니다.

[공유] 베네수엘라에 대한 미국의 군사개입에 대한 국제...

0
1
0
0

LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(**)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.

문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 **는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다. 여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 **<보통 글자> 꼴이거나 <공백>**<기호> 또는 <기호>**<기호> 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 **마크다운**은 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 이 **"마크다운"** 형식은 같이 기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 **마크다운(Markdown)**은을 해석해 보면 뒷쪽 **의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.

CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 **이런 **식으로** 중첩되어** 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 **이런 ** 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에, 이런 식으로 어느 연속된 구분자가 왼편인지 오른편인지 추론하는 데 한계가 있다는 것이다. 단순히 <보통 문자>**<기호>도 왼편으로 해석하는 식으로 해서 **마크다운(Markdown)**은 같은 걸 허용한다 하더라도, このような**[状況](...)**は 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.

* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [강조 처리된 "비숍(Ba5)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]

As Markdown has become the standard for LLM outputs, we are now forced to witness a common and unsightly mess where Markdown emphasis markers (**) remain unrendered and exposed, as seen in the image. This is a chronic issue with the CommonMark specification---one that I once reported about ten years ago---but it has been left neglected without any solution to this day.

The technical details of the problem are as follows: In an effort to limit parsing complexity during the standardization process, CommonMark introduced the concept of "delimiter runs." These runs are assigned properties of being "left-flanking" or "right-flanking" (or both, or neither) depending on their position. According to these rules, a bolded segment must start with a left-flanking delimiter run and end with a right-flanking one. The crucial point is that whether a run is left- or right-flanking is determined solely by the immediate surrounding characters, without any consideration of the broader context. For instance, a left-flanking delimiter must be in the form of **<ordinary character>, <whitespace>**<punctuation>, or <punctuation>**<punctuation>. (Here, "ordinary character" refers to any character that is not whitespace or punctuation.) The first case is presumably intended to allow markers embedded within a word, like **마크다운**은, while the latter cases are meant to provide limited support for markers placed before punctuation, such as in 이 **"마크다운"** 형식은. The rules for right-flanking are identical, just in the opposite direction.

However, when you try to parse a string like **마크다운(Markdown)**은 using these rules, it fails because the closing ** is preceded by punctuation (a parenthesis) and it must be followed by whitespace or another punctuation mark to be considered right-flanking. Since it is followed by an ordinary letter (), it is not recognized as right-flanking and thus fails to close the emphasis.

As explained in the CommonMark spec, the original intent of this rule was to support nested emphasis, like **this **way** of nesting**. Since users typically don't insert spaces inside emphasis markers (e.g., **word **), the spec attempts to resolve ambiguity by declaring that markers adjacent to whitespace can only function in a specific direction. However, in CJK (Chinese, Japanese, Korean) environments, either spaces are completly absent or (as in Korean) punctuations are commonly used within a word. Consequently, there are clear limits to inferring whether a delimiter is left or right-flanking based on these rules. Even if we were to allow <ordinary character>**<punctuation> to be interpreted as left-flanking to accommodate cases like **마크다운(Markdown)**은, how would we handle something like このような**[状況](...)は**?

In my view, the utility of nested emphasis is marginal at best, while the frustration it causes in CJK environments is significant. Furthermore, because LLMs generate Markdown based on how people would actually use it---rather than strictly following the design intent of CommonMark---this latent inconvenience that users have long felt is now being brought directly to the surface.

* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [The emphasized portion `비숍(Ba5)` is surrounded by unrendered Markdown emphasis marks `**`.]
14
2
1

eg bsky post format obviously can’t be “source of truth” for your posts. since it’s 300 characters max. so at most you could use bsky for announcements about posts already on your site leaflet as a format on the other hand could actually be your source of truth if you wanted.

0
0
0
0
0
0
0

lmk if these questions make sense! the answer depends on what you want the flow to be (what’s the place where you write and hold source of truth), what format your source of truths is, and which apps you want to “see” your records

0
0
0
0

it’s like state in react is your site’s content derived from state that lives in PDS? or are you creating stuff in PDS per each thing on site re: format the question is — do you want to link to your stuff (like bsky post), duplicate it (leaflet w/ same content), or unify (record = source of truth)

0

“한국 태어나 살며 교육세도 내는데 왜···” 무상급식 15년, 화교들이 말하는 ‘차별’ www.khan.co.kr/article/2026... "이중한 한국화교협회총연합회·한성(서울)화교협회 회장은 “억울하다”는 말부터 했다. “말만 화교지 아버지도 나도 한국에서 태어났고, 우리 가족은 100년을 여기서 살았어요. 한국 영주권자(F-5) 화교들은 교육세와 주민세, 소득세와 재산세를 다 냅니다. 납세 의무를 한국 국적 사람과 똑같이 이행합니다. 낼 거는 다 내고, 받을 거는 다 못 받으니 억울하죠.”"

“한국 태어나 살며 교육세도 내는데 왜···” 무상급식...

0
0
0
0
0
0
0
0
0
0
0

what you want to figure out is just - what is the source of truth (PDS can act as one, and your blog would serves content from it — or — you could do it the other way around and just create PDS record for each thing on your site) - what format your records are in (bsky post? leaflet? your own?)

0
0
0
0

LOL les infos d'incidents sur les lignes de métro, trains de banlieue et RER aujourd'hui, à croire que la neige est un phénomène complètement imprévu l'hiver 🤪

0

이메일 허브 역할하던 구글 지메일…1월부터 POP 메일 가져오기 지원 중단

구글은 2026년 1월부터 지메일(Gmail)의 POP(포스트 오피스 프로토콜) 기반 메일 가져오기 기능과 ‘Gmailify’ 기능을 중단한다고 밝혔다. 이번 조치는 보안을 강화하고 최신 이메일 접근 방식을 표준화하기 위한 결정이다. n.news.naver.com/mnews/article

1
0
0
0
0
0
0

이메일 허브 역할하던 구글 지메일…1월부터 POP 메일 가져오기 지원 중단 구글은 2026년 1월부터 지메일(Gmail)의 POP(포스트 오피스 프로토콜) 기반 메일 가져오기 기능과 ‘Gmailify’ 기능을 중단한다고 밝혔다. 이번 조치는 보안을 강화하고 최신 이메일 접근 방식을 표준화하기 위한 결정이다.

이메일 허브 역할하던 구글 지메일…1월부터 POP 메일...

0

이메일 허브 역할하던 구글 지메일…1월부터 POP 메일 가져오기 지원 중단

구글은 2026년 1월부터 지메일(Gmail)의 POP(포스트 오피스 프로토콜) 기반 메일 가져오기 기능과 ‘Gmailify’ 기능을 중단한다고 밝혔다. 이번 조치는 보안을 강화하고 최신 이메일 접근 방식을 표준화하기 위한 결정이다. n.news.naver.com/mnews/article

1
0
0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

自分の作品にデジタル署名することは今でもできるんだけどこのままじゃオレオレ証明書なんよね。
-----BEGIN PGP SIGNATURE-----

iQG2BAEBCAAgGRx6dW5kYSA8enVuZGFuQGdtYWlsLmNvbT4FAmlcxkAACgkQtWwg
MW1ugnkNuQv9GDkEa8pJoe0sNScTW75ml2Gxt8y1p1HtCtzJSMkkNf4hX6wwprnt
jIvUC09TI4nEyQCIEPoVp+Y+To7wNiZCA3sb5ejv+QE3InsEZw4vnI4zJfqgbcU8
qAoBxc8Q3OF6mjb4el80eHqoyW3Jun+nFMpMoN26RwUzjCnj+fDqpVG4IpVqKCRB
mE4Q9QG/fluI1zXiquf4LRgMI8HR196QnE9uV73fRyVO7xC21J6FwJPEbCvWaBHI
IDVc/1MfOxAiq+KCYM5mHjh7PYOV30qIOLGo6BQRqB6Tidcoc2Q7GP5MN46fNGDj
wcnj7pvq13i/J1EBLK02lVHJkyiCkkhjs6yIOpzXax/Y0LIHrnQifvrG7syJARpg
1YLJJVcsH7Z44JlVdO9uOyS0jmYY2GVJKeYIgmwk8fYk3/uH0vbZPktmvqfHX47i
43pIUFnCgo04xo/wc9CCNMuESvxt1T3EdnzE7uuHv8EurktRMsA15SB7aaHXz0C6
gttdwhvyKwen
=8+mE
-----END PGP SIGNATURE-----

0
0
0
1
0
0
0
0

AIのおはなし

雑ーにネットサーフィンしてたら、なんかAIでキャラとチャットするサービスがあって、それ用にAIでキャラのイラストとか生成してる人がおり、そのレベルになるとちょっとこれ手描きと区別つかねえ感じまで作り込むので「はーんほーんへー」してたんだけど、「画像剽窃された最悪!!」いうてて「はーんほーんへー」になった

いやこの「そのレベルまで作り込まれててキャラ設定ももりもりで当人にとっては頑張って作ったうちの子の絵!!」と「しかしそれは他人の画像を元にして作った奴では」の間のこの感覚にほーんというしかないやつね。

1