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.

@zkatkat the problem with "non-commercial" licenses is everyone has a different definition, and the broadest, most restrictive interpretation usually does not overlap with anyone's actual intent. it always leads to surprises when people actually read the license. mostly what happens in practice is people either avoid NC stuff on principle because it limits the use of their own project too much, or the use it anyway and often end up out of compliance on accident

0
0
0
0
1
1
1

Firefox uses on-device downloaded-on-demand ML models for privacy-preserving translation.

They're not LLMs. They're trained on open data.

Should translation be disabled if the AI 'kill switch' is active?

0
0
2

Trump: “I am pleased to announce that the Interim Authorities in Venezuela will be turning over between 30 and 50 MILLION Barrels of High Quality, Sanctioned Oil, to the United States of America. This Oil will be sold at its Market Price, and that money will be controlled by me, as President of the United States of America, to ensure it is used to benefit the people of Venezuela and the United States!”

May be a Twitter screenshot of magazine and text
0
1
0

🌕 球面貪喫蛇 (Spherical Snake)
➤ 打破平面框架,在曲面上重塑經典遊戲體驗
kevinalbs.com/spherical_snake/
這款名為《球面貪喫蛇》的專案將經典遊戲帶入三維空間。玩家在球形地圖上操控蛇體,體驗不同於平面版的空間感。遊戲介面簡潔直觀,提供即時計分與重玩功能,並支援多樣化的操作方式。開發者不僅建立了全球排行榜以提升競技樂趣,更將完整原始碼託管於 GitHub,展現了開放原始碼的分享精神,是網頁開發者學習遊戲邏輯與球體投影技術的絕佳範例。
+ 「將貪喫蛇放在球面上玩的構想很酷,空間感完全改變了遊戲的難度。」
+ 「程式碼開源在 GitHub 真的很有幫助,這對於想學習 WebGL 或球面座標運算的人來說是很好的教材。」
開源開發 JavaScript

0

Sigh. I just saw two posts here pushing the "real authors don't use em dashes, that's an AI thing" myth and I am tired. 😣

Hi. Hello. "Real author" here. I have never used AI in any part of my writing or process, ever. I use em dashes all the time. So do other real authors. In fact, there'd be a fight to the death if you tried to take our em dashes away from us. Sometimes, a semicolon just won't do, and you *need* that em dash. Other times, you *must* use an em dash (when a character gets interrupted mid-sentence or mid-word, for example).

The *reason* you see em dashes in AI slop is because those LLMs were literally built on the stolen works of real authors. Who use em dashes. All the time.

0
0
0
0
0
0
0
0
0
0
0

안성재 셰프에 대한 근거 없는 화교 드립은 단순한 '넷상의 헛소리'가 아닙니다. 이는 커뮤니티 정서의 입법화고 외국인(특히 특정 국가/집단)에 대한 적대감과 역차별 담론이 정책화 되는 과정입니다. 이는 실제 누군가의 자유나 권리를 '공정' 담론의 탈을 쓰고 제한하려는 움직임이 현실로 나타났다는 것이고, 결국 민주주의의 숙의 과정에 문제가 생겼음을 시사합니다. 이런 상황에서 우리가 할 수 있는 가장 강력한 저항은 이 현상의 배후에 있는 '커뮤니티-정치'의 연결 고리를 폭로하고 사실 관계를 끊임없이 환기하는 일이라고 생각합니다.

0

어떻게보면 넷 잉여들이 헛소리하는거에 너무 큰 의미를 실어주는 것 아니냐 할 수도 있겠지만, 이렇게 특정한 온라인 코호트에서 (인기글, 개념글이라는 이름으로) 손쉽게 게이트키핑이 가능하고, 이를 통해 여론에 넛지를 가할 수 있다는게 지금 한국 사회가 보여주는 극우화의 가장 큰 특징이자 문제라고 봐요. 진짜 문제는 한국 정치권이 이에 반응한다는겁니다. 어제 김미애 의원이 발의한 외국환거래법 뿐만이 아니에요. 입법은 사회적 합의의 산물이어야 하는데, 지금은 특정 온라인 코호트의 편향된 목소리가 필터링 없이 법안으로 직행하고 있습니다.

[단독] 김미애, 베네수엘라식 외환통제 재앙 차단 위한...

0

우리나라 청년/노령층 극우화는 지금 전 세계적으로 나타나는 현상과는 약간 차이가 있다고 보입니다. 아니, 정확히 말해서는 경제적 이슈나 역차별 등이 중점이 된 구미의 사례가 극도로 편향된 좁은 통로를 통해 들어오면서 이들이 많은 시간을 보내는 커뮤니티 자체를 일종의 고립된 집단으로 만들어버렸어요. 그러면서 계속 검증 없이 자가발전이 일어나는거죠. 보도매체가 난립하는데다 정파적/자본적 가치관을 사실보다 우선하다보니 뉴스의 신뢰성이 망가져버렸습니다. 결국 뉴스의 용도는 얼마나 자극적인가, 어그로를 끌 수 있는가로만 굳은거죠.

0

그래서 좀 찾아봤습니다. 찾다보니 이게 얼마 전 김창환 교수님이 말한 청년 극우 담론과도 밀접하게 엮인거 같더라고요. 최초 유포는 흑백요리사 시즌 2 마이너 갤러리고, 여기서 누가 화교라고 드립을 친게 퍼진것 같았습니다. 그런데 꽤나 중요한걸 찾았어요. 리플로 싸우는걸 보면 '화교는 한국에서 대학 입학전형 등 혜택을 받는다'라는 인식이 깔려있는걸 볼 수 있습니다. 이거, 중앙일보에서도 반박된 유명한 가짜뉴스입니다. 어제 웃으며 넘긴 이 '포텐으로 세상을 보시는구나' 짤 기억나시나요? 청년 극우화의 한 단면이 이거라 봅니다.

RE: https://bsky.app/profile/did:plc:y5csbf6vxv6d2jwp7r5jkx3n/post/3mbrciosya22x

0
1
0

日本のスマホ新法は、Appleに、ブラウザベンダーが日本で独自のブラウザエンジンを使うことを認めるよう義務付けています。
しかしAppleは、過去21ヶ月にわたり欧州デジタル市場法の同条項の遵守を事実上避けるために用いてきた方法を使うつもりのようです。

詳しくはこちら:
open-web-advocacy.org/ja/blog/

具体的には、Appleは独自エンジンを使いたいブラウザベンダーに対し、既存アプリの更新として提供することを認めず、既存の日本ユーザーを引き継がない全く新しいアプリとして提供することを求めています。
また、Appleは、iPadOS等のiOS派生OSにおいて、独自エンジンを使用することを認めていません。

Japan’s new Smartphone act requires that Apple allow browser vendors to use their own engines in Japan. However, Apple looks set to use the same tactic it has used in the EU to avoid complying with the same provision of the Digital Markets Act for the last twenty-one months.

Read our full analysis here:
open-web-advocacy.org/blog/how

Namely, Apple demands that browser vendors lose all their existing Japanese users and produce a brand new browser, rather than simply updating their existing users.

0
0
0
1
0
0

@zkatkat One question I have is: How are we defining (non-)commercial usage, and how is it scoped?

Example: a community group/charity does some commercial activity to generate funds for its main objectives.

Should the NC restriction forbid the entire org from using the work, or just for the actual commercial activities directly?

Or is is about the profit-making stance at the org level?

0
0
0
0
0

日本のスマホ新法は、Appleに、ブラウザベンダーが日本で独自のブラウザエンジンを使うことを認めるよう義務付けています。
しかしAppleは、過去21ヶ月にわたり欧州デジタル市場法の同条項の遵守を事実上避けるために用いてきた方法を使うつもりのようです。

詳しくはこちら:
open-web-advocacy.org/ja/blog/

具体的には、Appleは独自エンジンを使いたいブラウザベンダーに対し、既存アプリの更新として提供することを認めず、既存の日本ユーザーを引き継がない全く新しいアプリとして提供することを求めています。
また、Appleは、iPadOS等のiOS派生OSにおいて、独自エンジンを使用することを認めていません。

Japan’s new Smartphone act requires that Apple allow browser vendors to use their own engines in Japan. However, Apple looks set to use the same tactic it has used in the EU to avoid complying with the same provision of the Digital Markets Act for the last twenty-one months.

Read our full analysis here:
open-web-advocacy.org/blog/how

Namely, Apple demands that browser vendors lose all their existing Japanese users and produce a brand new browser, rather than simply updating their existing users.

0
0
0
3
0
0
0
0
1

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