juxtapose

If a module defines a custom exception type and throws that exception within the module, it absolutely must export that exception type as well. I'd think this is basic, but it seems a surprising number of packages declare exception types without exporting them.

@reiver@reiver ⊼ (Charles) Your reply makes me realize that we need a new property in ActivityPub, like isNotSerious or isJoke that I can mark on posts.

By the way, in case you didn't notice, the previous sentence is not serious.

I mean you've done all the hard work for free open decentralized social networking platform right?

and you're like one inch centimeter away from branding yourself this

I'm not happy with how Mastodon abbreviates Mastodon to mstdn. For me it looks like Microsoft Technical Developer Network or something

사람들이 서비스형 LLM에게 자기 내밀한 이야기 등 모든 것을 털어놓고 있다. 이게 <del>클라우드</del> 남의 컴퓨터 에 저장된다는 인식 자체가 없는 이용자가 90% 이상이 아닐까 싶다.

예상: 이러다가 어느 업체가 유출 사고 한번 거하게 칠 것이다. 절대 노출되어서는 안 되는, 한 인간에게 회복이 불가능한 피해를 입히는 심각한 비밀이 공개되어 비극적 결말로 치닫는 경우가 반드시 발생할 것이다.

참사가 예상되지만 막을 수 없다. 가까운 이들에게 경고하고 주의를 당부하는 정도가 우리의 한계다.

이이이얏호우우우!

가자! 댓글 없는 청정 사회로!

フトスト!

@hongminhee洪 民憙 (Hong Minhee) 댓글 막는 기능은 언제 들어올까요

제가 생각하는 해커즈 퍼브 기능 우선순위

1. 글 올리면서 "댓글 안 받기" 설정 (트위터 킬러 피처, 트위터 역사상 가장 훌륭한 기능 추가라고 생각)
2. 인용 (quote) 금지 설정
3. 공유 (renote) 금지 설정

😅

악용 사례가 발견되어 긴급 패치: 실존하는 위협에 벌벌 떨어야 함
악용 사례는 발견되지 않음: 존재가 확인되지 않은 위협에 벌벌 떨어야 함

해커즈 퍼브의 favicon 이야기가 나왔을 때 잠깐 생각나는 대로 대충 낙서해 본 것이 있습니다. (말 그대로 대충 낙서입니다. 이대로 쓰자는 뜻은 아닙니다. 너무 진지하게 받아들이지는 마시고, 브레인스토밍 정도로 생각해 주시길...)

• 퍼브 간판의 일반적인 형상을 가져왔습니다.
• 마실 것을 파는 장소의 간판 같은 느낌을 유지하면서, 정확히 어떤 음료인지는 의도적으로 알 수 없게 했습니다. ("퍼브"는 맥주를 주력으로 하는 장소라는 인식이 있는 것 같습니다만, 법적·의료적·종교적 여러 가지 이유로 알코올을 음용할 수 없는 사람들이 세상에는 아주 많기 때문에, 일부러 "맥주"의 이미지를 배제했습니다. 해커즈 퍼브는 술 안/못 마시는 사람도 편하게 올 수 있는 장소가 되는 것이, 행동 강령의 취지에도 부합한다는 생각이었습니다.)
• 간판 부분은 잘 보시면 "퍼브"라는 한글 표기에서 "ㅍ"와 "ㅂ"를 담고 있습니다. 가로대와 간판이 이어지는 부분이 "ㅍ"의 형상이고, 물잔이 "ㅂ"의 형상입니다. 물론 해커즈 퍼브는 한국어 전용 커뮤니티도 아니고 한글 전용 커뮤니티는 더더욱 아닙니다. 한글이 꼭 들어가야 할 이유는 없습니다. 하지만 반대로 한글을 안 쓸 이유도 없지 않은가? 뭔가를 모티브로 쓰긴 써야 하는데 그게 한글일 수도 있는 것 아닌가? 그래서 넣어 봤습니다. 😅
• "Hacker's Pub"를 구성하는 글자들을 그대로 집어넣는 것을 일부러 피했습니다. 우선, 아이콘은 "Hackers' Pub"이라는 텍스트와 병치될 가능성이 높은데, 그렇다면 "H"나 "P"가 들어 있는 것은 중복이 되고 정보 전달의 낭비가 됩니다. 그리고, favicon 으로 쓰일 가능성이 높은데, 다른 사이트들에도 알파벳을 형상화한 아이콘이 많습니다. 추상적 형상으로서 다른 아이콘들과 겹칠 여지가 적을수록 식별자로서의 기능과 효용이 극대화될 것이라는 생각이었습니다. (물론, 엄밀히 따지면, 이 아이콘도 전체 형상에는 알파벳 "h"의 구조가 숨어 있고, 그것을 의도하긴 했습니다만, 가장 먼저 눈에 들어오는 특징은 아니죠.)

다른 분들이 여러 가지 말씀을 해 주셨습니다만 저도 첨언하자면,

"의업과 약업의 현실적 관계"도 한 가지 중대한 이유입니다. 제약회사 직원이 의사에게 굽실거리다 못해 예비군 훈련을 대신 가거나, 수술을 대신 한다는 기상천외한 뉴스 다들 한번쯤 보셨을 텐데요.

원론적으로는 의사가 약에도 빠삭해야 하지만, 현실적으로는 자기 전공분야도 너무 방대하고 약학도 너무 방대해서 그러기 어렵습니다. 마치 소프트웨어 엔지니어 중에 하드웨어 덕질까지 하는 경우는 소수이고 대부분은 그냥 맥북 사는 것과 비슷하게, 의사들의 약 지식도 한계가 있는 거죠. 어떤 약을 안 쓰는 게 무슨 이유가 있어서가 아니라 진짜로 그 약의 존재를 몰라서인 경우가 허다합니다. 그러니 약 성능 똑같아도 영업에 따라 억 단위가 왔다갔다 하고, 그러니 제약회사의 영업이 엽기뉴스의 영역으로 가는 것이죠.

이런 시장환경에서 의사들에게 약 이름과 성분 이름의 대조표를 매년 새로 외우라고 하면 망하겠죠? 그래서 어떻게든 이름만 보면 성분을 알게 하려고 발버둥치는 것입니다.

그러면 반대로 성분명과 전혀 무관한 약 이름은 어떻게 나오는지도 짐작이 되시죠? 그렇습니다. "처방전 필요없는" 약은 성분명 쿨하게 버리고 일반소비자에게 호소하는 작명을 하는 경향이 있습니다. 그리고, 처방전이 필요하더라도 동일성분의 약이 많거나 저네릭 경쟁이 벌어지는 경우에도 튀는 이름으로 차별화를 꾀하는 경향이 있죠.

RE: https://serafuku.moe/notes/a6lapo16c2

저도 두 가지 쟁점 모두 동의하는 편입니다. 그리고, 별개의 이야기입니다만, $ 를 가르칠 때에는 그냥 문법이라고 가르치는 게 학습자의 이해와 응용이 압도적으로 빠르고 좋았습니다.

"이건 여기서부터 뒤로는 다 괄호로 감싸겠다는 뜻이라고 생각하세요."

이러면 한 방에 설명이 끝나고, 필요성이나 편리성에 대해서도 알아서들 납득하는 것이죠. 연산자 우선순위나 좌결합 우결합 등은 그게 되고 나서 얘기하고요. 그러면 "아, 이게 그래서 이렇게 되는 거였군요?" 하면서, 훨씬 쉽게 이해합니다. 이걸 거꾸로 좌결합 우결합 어쩌고부터 가르치려고 하면 다들 꾸벅꾸벅 졸아요... ㅋㅋ ㅠㅠ

(결국 "모나드란 무엇인가"부터 배우면/가르치면 안 된다는 주장과 같은 맥락입니다.)

RE: https://hackers.pub/@bgl/01963c3b-98fa-7432-a62f-0d2dfc0691bf

@hongminhee洪 民憙 (Hong Minhee)

@hongminhee洪 民憙 (Hong Minhee) 저는 부족하다고 생각합니다...! ㅋㅋㅋㅋㅋ 유저들이(저는) 그냥 일반적인 Yes/No 다이얼로그는 조건반사적으로 Yes 해 버리는 실수를 많이 한다고 생각합니다... ㅋㅋ ㅠㅠ

@hongminhee洪 民憙 (Hong Minhee) 방금 신기능 확인하러 들어가 봤는데, 실제 렌더링 결과를 보니 드는 생각이 있어 의견 드립니다. 그냥 🗙 를 쓰는 것은 좀 위험하지 않을까 하는... 🗙 는 단순한 "창 닫기"의 의미로도 많이 쓰이기 때문에, 팔로어 목록도 일종의 인박스("이 사람이 당신을 팔로했습니다" 같은)로 여겨서, 각각의 상자를 대수롭지 않게 🗙 를 눌러서 없애 버리려고 하는 일이 발생하지 않을까 싶습니다.

"블언블"에 해당하는 강력한 조치이니만큼, 함부로 누를 수 없게 "빨간 버튼" 급의 경고가 있어야 하지 않나 하는 생각입니다. 이상적으로는 ellipsis 메뉴 안에 숨기고, ellipsis 눌러서 메뉴를 띄우면 적어도 "빨간 버튼"에 준하는 (즉 딱 봐도 위험해 보이는) 항목으로 등장하면 좋겠네요.

읔ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

@hongminhee洪 民憙 (Hong Minhee) 트위터 같은 경우는 내가 차단한 사용자의 페이지를 퍼머링크 등으로 굳이 찾아 들어갔을 때 경고 다이얼로그 형태의 UI 를 띄우고, 거기서 확인을 누르면 비로소 내용을 보여주는 식으로 동작하더군요. 괜찮은 해법이라고 생각했었습니다.

해커즈 퍼브에서 "사용자"에 해당하는 부분에 스타일시트 적용 전후 비교

@hongminhee洪 民憙 (Hong Minhee) 이게 혹시 대상이 EmojiReact 를 받아들이는지 아닌지도 스펙에 의해 식별되는 것인가요? 만약 그렇다면 즉시 그렇게 하셔도 좋을 것 같습니다. 그런 것이 아니라 대상이 마스토돈인지 아닌지를 가지고 직접 판단을 내려야 하는, 즉 프로토콜에 없는 정보인데 하드 코딩으로 대응해야 하는 것이라면 조금 더 고민하실 여지가 있을 것 같네요...

'악플'이라는 말이 그 자체로 암시하는 바가 있다. 악글, 악메시지 같은 황당한 조어는 없다. 그러나 '악플'은 아주 당당하게 한국어 언중의 삶에서 확고한 위상을 점유하고 있다. 이 근본 없는 신조어가 뉴스 헤드라인에 박혀 있어도 아무도 토를 달지 않을 정도다.

오직 댓글만이 이럴 수 있다. 오직 댓글만이 사람을 자살로 몰고 가는 죄악의 주범으로 번번이 지목될 수 있고, 오직 댓글만이 정치 여론 조작의 혐의로 관계자들을 징역에 처할 수 있다. 자기 블로그에 글 썼다고 이렇게까지 지탄을 받거나 처벌을 받는 일은 없다. 이것은 의미심장하다. 이것은 개개인의 품성 문제가 아니다. 댓글이라는 시스템이 갖는 구조적 원인이 분명히 있는 것이다.

그런 의미에서 트위터 역사상 가장 훌륭한 기능 추가도 "댓글 안 받기" 기능이라고 생각한다. 그러므로 해커즈 퍼브에 댓글 안 받기 기능이 생기기만 기다리는 중...

@hongminhee洪 民憙 (Hong Minhee) @kodingwarriorJaeyeol Lee @lionhairdino

쿠버세란 옵스 엔지니어 연봉을 뜻한다

@hongminhee洪 民憙 (Hong Minhee) @kodingwarriorJaeyeol Lee @lionhairdino 저는 그냥 "유저"에 해당하는 부분 그 자체에 별도의 background 와 border 를 부여하는 것이 가장 일반적이면서 직관적이고 식별성도 좋다고 생각합니다만... (스크린샷은 각각 border-radius 를 사용한 경우와 box-shadow 를 사용한 경우입니다.)

쿠버네티스도 간단하게 쓸 수 있죠. 요즘 k3s 같은거 쓰면 구성도 쉽고, 사용도 그냥 kubectl apply -f deployment.yaml 하면 끝인데. 이렇게만 쓰면 도커컴포즈랑 그렇게 다르지 않습니다.

근데도 쿠버를 쓰지 말라는 이유는, '잘못 쓸 여지'가 많기 때문입니다

쿠버를 쓰다 보면, 괜히 GitOps 하고 싶어서 ArgoCD 깔고, 서비스 메시 한다고 Istio 깔고, prometheus 깔고, thanos 셋업하고, EFK 스택 만들고, 이러다보면 아무도 유지보수 못하는 쿠버네티스 클러스터가 완성됩니다. 아니면 옵스 엔지니어가 주 40시간 전체를 이거를 간신히 존속시키는데에만 다 쓰고 나머지 아무것도 못 합니다.

이런거 다 참을 수 있고 k3s로 깔고 kubectl apply -f 만 치고 살거면 쿠버 쓰셔도 됩니다.

첨부한 사진이 무슨 링크드인에 '2025년 쿠버네티스 표준 구성' 이라고 돌아다니던데, 제발 이러지 마세요.

도커컴포즈 쓰면 이런걸 아예 못 하게 되니까 오히려 장점인거죠. 잘못 쓸 여지가 없음.

@hongminhee洪 民憙 (Hong Minhee) 일곱 가지 에모지 선정은 탁월하다고 생각합니다. 널리 쓰이는 👍 나 🚀 은 의미적으로 ❤️ 와 중복되므로 넣지 않으신 걸로 이해하였습니다. 😅 와 💔 는 추가하면 어떨까요?

@sunwoo1524 그 이야기 하면 도미노피자 스쿠터를 빼놓을 수 없죠
https://www.youtube.com/watch?v=n17B_uFF4cA

똑같은 얘기를 닉스, 닉스오에스, 닉스옵스로도 할 수 있어요. "아 이거 걍 선언형으로 파일 작성하고 nixops deploy --check 하나만 때리면 알아서 이것저것 다 뜨고 다 설정될 텐데 괜히 귀찮게 왜 쿠버네티스를"

근데 현실적으로는 그냥 도커 컴포즈가 제일 삽질의 총량이 적죠...

@campanulaLuminα 축산업계에서 콩고기 등 비건고기에 아예 "고기"나 "육" 등의 말을 쓰지 못하게 해야 한다고 강력 반발하고 있다는 얘기를 봤는데요. 전통적 육류업계의 위기감은 이해하지만 도저히 대체할 만한 말이 마땅치 않을 텐데... 라는 생각이 들더라고요.

쿠버는 마세라티 문제가 맞음! 제발 쿠버 섣불리 쓰지마!
어케어케 쿠버를 쓰기로 결정했다면
istio 같은거 제발 쓰지마!!!!!!

@saschanazKAGAMI🏳️‍🌈🏳️‍⚧️ 그게 제일 바람직하다는 것에 저도 동의해요. 다만 현실적으로는 아무래도 DB라든지 MQ라든지 이것저것 같이 띄워야 하다 보니, 서비스 운영을 하려다 보면 그런 전체 형상 관리를 위한 추상화 계층이 있기는 있어야 하는 것 같아요. 물론 도커 컴포즈를 안 쓰고 앤서블로 그런 모든 것을 관리할 수도 있고, 아예 닉스나 닉스오에스를 써서 더 아름답게 할 수도 있겠습니다만... 도커 컴포즈 정도면 타협 가능한 것으로...

저, 저도 90% 이상의 경우 도커 컴포즈 정도가 적당한 추상화 수준이라고 생각해요...

실제로 쿠버네티스 쓰는 팀에서 일해 본 경험도 그렇고, 주변 이야기 들어 봐도 그렇고, 도입하면 도입한 것으로 인해 증가하는 엔지니어링 코스트가 분명히 있다는 점은 누구도 부인하지 않는 것 같은데요. 쿠버네티스를 제대로 쓰는 것 자체도 배워야 할 것도 많고, 엔지니어가 유능해야 하고, 망치도 들여야 하고... 웬만하면 전담할 팀이 필요하지 않나 싶어요. (전담할 '사람' 한 명으로 때우기에는, 그 사람 휴가 가면 일이 마비되니까.)

엔지니어만 100명이 넘는 곳이라면 확실히 도입의 이득이 더 크겠지만, 반대로 혼자 하는 프로젝트라면 도무지 수지타산이 안 나올 것이라고 생각합니다. 따라서 쟁점은 그 손익분기점이 어디냐일 텐데... "대부분의" 서비스는 대성공하기 전까지는 도입 안 해도 되지 않나, 조심스럽게 말씀드려 봅니다. 즉 쿠버네티스가 푸는 문제는 마세라티 문제인 것이죠...

특히 클라우드 남의 컴퓨터 를 쓰지 않고 베어메탈 쓰는 경우는 더더욱...

RE: https://hackers.pub/@hongminhee/019618b4-4aa4-7a20-8e02-cd9fed50caae

에모지 반응 기능이 배포되었습니다. 당분간 버그가 좀 있을 수도 있지만 양해 바랍니다. 전 이제 차단을 구현하러 가겠습니다…

@liaizonwakest ⁂ @hongminhee洪 民憙 (Hong Minhee) You made my day 😂 I'd say that's correct

@hongminhee洪 民憙 (Hong Minhee) @liaizonwakest ⁂ Also interesting is the Korean neologism 실친 which almost exclusively means "real-life friend as opposed to a cyberspace friend."

Even more interesting is 랜선인연, an antonym of 실친. A rough direct translation of 랜선인연 would be "LAN cable relationship."

이 농담보다 더 블랙 코미디 같은 현실: 한국 아직도 트럼프랑 단 한 번도 통화 못함.

https://news.jtbc.co.kr/article/NB12241795

지금 트럼프 취임 후 석 달이 돼 가는데 한국-미국 수반 간 통화 한 번도 없었음.

RE: https://planet.moe/users/SiLVER01/statuses/114277521678428010

@hongminhee洪 民憙 (Hong Minhee) (소근소근) 보는 사람들은 대개 더 잘게 쪼갤수록 좋아합니다. 체인지로그 한 덩어리가 너무 길면 읽을 엄두가 안 나서요. 더 자주 릴리스하면 더 활발하고 더 건강한 프로젝트처럼 보이게 되는 것은 덤...

@curry박준규 그냥 스팸이에요. 하도 연합우주에 자신을 "fediverse chick"이라고 소개하는 스팸을 많이 뿌리고 다녀서 유명합니다.

그리고 에모지 vs 이모지 는 규범주의뿐만이 아니라 언어의... ethnicity 라고 표현해야하나..? 와도 관련이 있습니다
에모지 는 원래 일본어입니다. 그림문자인 에모지에서 왔으니까 에모지라는 것이죠.
이걸 서양권에서 이모지라고 발음한다고 우리도 이모지라고 부르면 원어를 존중하지 않는 꼴이 됩니다
세인트 피터스버그, 워쏘우, 조안 오브 아크 등등의 예시가 있습니다
미국/영국인이 그렇게 부르는 것은 이해할 수 있지만 우리가 그걸 따라갈 필요는 없잖아요?

의견: 해커즈 퍼브에 정말로 시급한 기능은 에모지 반응 기능이 아니다. 차단 기능과, 댓글 안 받기 기능이다. 당장 스팸에 대응할 방법이 없다.

간혹 "이모지"가 아니라 "에모지"라고 쓰는 이유에 대한 질문을 받습니다. 여기다 써 두면 앞으로 링크만 던지면 되겠지?

요약: 에모지라서 에모지라고 씁니다.

"이모지"라는 표기는 아마도 "emoji"가 "emotion"이나 "emoticon"과 관련이 있다고 생각해서 나오는 것으로 보이는데요. "emoji"와 "emoticon"은 가짜동족어(false cognate)입니다. "emoji"는 일본어 絵文字(에모지)를 영어에서 그대로 받아들여 쓰고 있는 것입니다. 심지어 구성원리도 에모+지가 아니고 에+모지(絵+文字)입니다. "emotion"과 유사해 보이는 것은 순전히 우연일 뿐, 계통적으로 전혀 아무 상관이 없습니다. "이모티콘"과 "이미지"의 합성어가 아닙니다. (그랬으면 "-ji"가 아니라 "-ge"였겠죠.)

그리고 그렇기 때문에 에모지를 에모지로 표기할 실익이 생깁니다. :), ¯\_(ツ)_/¯, ^_^ 등은 이모티콘입니다. 반면 😂는 명확히 에모지입니다.

프로그래머에게 이건 정말 중요한 구분입니다. "이모티콘을 잘 표현하는 시스템"과 "에모지를 잘 표현하는 시스템"은 전혀 다른 과제이기 때문입니다. 에모지는 "그림 문자"라는 원래 뜻 그대로, 어떤 문자 집합(예를 들어 유니코드)에서 그림 문자가 "따로 있는" 것입니다. 내부 표현이야 어떻든, 적어도 최종 렌더링에서는 별도의 글리프가 할당되는 것이 에모지입니다. "무엇이 에모지이고 무엇이 에모지가 아닌가"는 상대적으로 명확합니다(문자 집합에 규정되어 있으니까).

반면 이모티콘은 "무엇이 이모티콘인가?"부터 불명확합니다. 우선 대부분의 이모티콘은 이모티콘이 아닌 문자를 조합하여 이모티콘이 만들어지는 형식입니다. 예를 들어 쌍점(:)이나 닫는 괄호())는 그 자체로는 이모티콘이 아니지만 합쳐 놓으면 :) 이모티콘이 됩니다. 하지만 조합에 새로운 의미를 부여했다고 해서 다 이모티콘이라고 부르지도 않습니다. -_- 같은 것은 대다수가 이모티콘으로 인정하지만, -> 같은 것은 이모티콘이라고 부르지 않는 경향이 있습니다.

- 문자와 > 문자에는 화살표라는 의미가 없기 때문에, -> 조합과 화살표의 시각적 유사성에 기대어 화살표라는 새로운 의미로 "오용"한 것은 이모티콘의 구성 원리에 해당합니다. 하지만 화살표는 인간의 특정한 정서(emotion)에 대응하지 않으므로 이모티콘이라고는 잘 부르지 않습니다. 그렇다고 얼굴 표정을 나타내야만 이모티콘인가 하면 그렇지도 않습니다. orz 같은 것은 이모티콘으로 간주하는 경향이 있어 보입니다. 오징어를 나타내는 <:=는 이모티콘인가? 이모티콘이 맞다면, 왜 ->는 이모티콘이 아니고 <:=는 이모티콘인가? 알 수 없습니다. ㅋㅋ과 ㅠㅠ는 둘 다 정서를 나타내는데, ㅠㅠ만이 아이콘적 성질을 가지므로 이모티콘이고 ㅋ는 이모티콘이 아닌가? 알 수 없습니다. 만약 ㅋ만 이모티콘이 아니라고 한다면, ㅋ큐ㅠ 에서 큐는 이모티콘인가 아닌가?? 알 수 없습니다. 이 알 수 없음은 이모티콘의 생래적 성질입니다. 어쩔 수 없죠.

(명언)

@hongminhee洪 民憙 (Hong Minhee) 멋진 발표 잘 해 내시길 기원합니다. 근데, 발표를 하시는군요? 전에 발표를 앞두고 고통의 메시지를 남기셨길래 발표 싫어하시는 줄 알았는데? 그것도 일본어로?

@hongminhee洪 民憙 (Hong Minhee) ご苦労様です。応援しております。そういえば、振り仮名をつけるのって「LLMに任せたら人間より迅速かつ正確にやってくれる」仕事の例ですね。原稿に振り仮名をつけるシステムは自動化する甲斐があるかもしれませんね

@hongminhee洪 民憙 (Hong Minhee) Twitterはイーロンされててもうだめだ、ActivityPub対応のアカウントが欲しい → この「ハッカーズ・パブ」がよさそうだな → 会員登録がない → 管理者に申し込み → 管理者にメッセージを送るには、ActivityPub対応のアカウントが必要

😂

ふと疑問。ここ、招待制なので、興味を示す日本語圏のハッカーさんがいても、合流できないのでは…？

すると、一般登録はまだ早いとしても、登録申し込みフォームとかが必要なのか？

創立者さんには別の計画がおられるだろうか

この「ハッカーズ・パブ」(Hackers' Pub)は、ハッカーたちが集まるネット上の場所であって、各自ブログも出来て、レスも出来て、掲示板みたいにも使えて、ユーザーの望みであればFediverseなる世界中の 変人 みんなのネットワークとも繋がりうる、言わばハッカーたちのための新しいツイッターみたいなサイトらしい。

ツイッターより優れた部分は何かというと、技術的に何時間も喋れそうだが、私が注目するのは、まずここの創立者および主任開発者である洪 民憙 (Hong Minhee)先生はイーロンなどよりかはずっとましな方で、頼れる方だということ。ユーザーの自由に関する彼の哲学、このサイトの設計思想などは信用できる。多分。なにしろ彼は今やFLOSS(Free/Libre/Open-Source Software)の開発を専業としておられるのだ。

なお、例えひょんな事で洪さんがイーロン並みに暴走する、由々しき事態でも、ここはツイッターみたいにはならないということ。この「ハッカーズ・パブ」はソースコードに限らず、プロトコルや作動原理も全部FLOSSなので。まあ洪さんの暴走なんてないでしょうけどね。

エンジニアとして生きてきた分、こういうサービスを運営する側の負担を大体把握しているので、自分ではやらないと思うし、ここが盛り上がったところで (盛り上げたところで) 自分の人生に役立つかというと、そうも言えない。が、「みんながTwitterとかFacebookとかInstagramなどを使っている」今の状態と比べれば、ハッカーズ・パブがもっと使われる未来の方が好ましいことに違いはない。そう考えると、洪さんの努力に感謝せざるをえない。

で、パブに日本語圏のユーザーをもっと招くのが創立者の方針というかご希望らしく、衝動的に参加してみる。これから機会あれば、日本語でも面白い話をここに残すのを目指してみる。自分日本語全然下手ですが。よろしく。

@hongminhee洪 民憙 (Hong Minhee) Thank you for your amazing work that just goes on and on. By the way, here's one of the reasons I think "blocking" is the first-priority feature in Hackers' Pub. (sigh)

https://hackers.pub/@rollbacks74@occm.cc/0195f7ec-5551-7df6-ba9e-b7716a9214b2

Of course, blocking alone won't really address the issue. I guess we're already being targeted by spammers...

@hongminhee洪 民憙 (Hong Minhee) 이 포스트를 해커즈 퍼브에 공유했더니, 본문에 있는 링크 중 마지막의 "실제로 ArcGIS 의 동남아시아 지진 지도를 보면" 부분의 링크만 없어지네요. 해커즈 퍼브 쪽 버그일까요?

마인어에는 지진을 뜻하는 고유어가 없다...?

마인어는 사용인구로 따지면 오스트로네시아어족의 맹주라 할 수 있는 큰손이다. 오늘날 말레이시아와 인도네시아를 비롯한 지역에서 쓰이며, 총 화자는 2억 5천만 명이 넘을 것으로 추산되니, 한국어는 명함도 내밀 수 없는 규모다. 언어학계는 마인어의 조상이 PAn(Proto-Austronesian language, 오스트로네시아조어)이라는 것을 거의 확신하고 있다.

PAn 은 수천 년 전 타이완섬에 살던 사람들이 썼을 것으로 추정되는 언어다. 이 사람들은 거대한 타이완섬에 살다가, 어째 답답했는지 아니면 거기 계속 살다가는 먼 미래에 정체자를 배워야 하는 운명을 예감한 것인지, 바다로 뛰쳐나갔다. 이들은 유유히 배를 타고 대양을 누비며 세계 곳곳에 정착한 것으로 추정된다.

전근대에 원양 항해라니 죽음을 자초하는 행위 아닌가? 게다가 타이완섬 앞으로 나가면 약속의 열대저기압 지옥태풍존이잖아? 그런데 PAn 으로부터 분화한 언어들, 오스트로네시아어족의 분포 범위를 보면 무시무시하다. 동으로는 태평양 건너 남미에서, 서로는 인도양 건너 아프리카 대륙 앞 마다가스카르에 이른다! 유럽인들이 "Age of Discovery" 운운하기보다 수천 년 전에, 나침반도 육분의도 없던 시절에, 지구에서 가장 큰 바다를 건너 다닌 비결? 현대의 학자들은 이런저런 짐작만 할 뿐이다. 이들의 항해술은 주로 문자가 아니라 구술로 전승되었기 때문이다.

그런데 아무튼 기원이 타이완섬이고, 타이완섬은 환태평양 지진대의 영향권에 있으므로, PAn 에도 "지진"을 뜻하는 어근이 있는 것은 거의 확실시된다. 현재 언어학계의 다수설은 linuʀ 이다. 여기서 많은 파생형이 발생하였는데 예를 들어 linog 만 봐도 수우우많은 오스트로네시아계 언어들이 이 말을 "지진"으로 쓰고 있음을 알 수 있다.

하지만 마인어에는 이 "linuʀ"에서 파생한, "지진"을 뜻하는 고유어가 전혀 보이지 않는다. 어떻게 된 것일까? 당장 지리적으로나 언어계통적으로나 마인어와 인접한 자바어에도 linuʀ 에서 왔음이 분명해 보이는 ꦭꦶꦤ꧀ꦝꦸ (lindhu) 가 있는데, 마인어에서는 뜬금없이 gempa bumi 라는 표현을 쓴다. 알고 보면 이것은 산스크리트어(?!) भूमिकम्प (bhūmikampa) 에서 온 것이다.

마인어의 조상인 고대 말레이어에 산스크리트어 차용 단어가 많은 것은 사실이다. 하지만 아무리 그래도 "지진"은 인간 생활에 직결되는 중요한 단어이고, 바로 근처의 다른 모든 오스트로네시아어족 정착지에서 모두 "linuʀ" 파생형을 쓰고 있는데, 왜 고대 말레이어는 "지진"의 고유어를 버리고 산스크리트어를 썼을까?

흥미로운 가설은, 하필 마인어가 분화 형성된 지역만 지진대를 멋지게 비켜 가면서, 지진이 너무 오랫동안 없었기 때문에 (!) 고유어가 사멸했다는 것이다.

마인어는 오늘날에는 말레이시아와 인도네시아 전역에서 널리 쓰이지만, 옛날에는 말레이 반도와 말레이 제도에서 주로 쓰는 언어였고, 그보다 더 아주 먼 옛날에는 보르네오 섬의 서부에서 쓰인 것으로 추정된다. 실제로 ArcGIS 의 동남아시아 지진 지도를 보면, 이 지역들만 절묘하게 지진대에서 벗어나는 것을 볼 수 있다...!

💯

#Linux