지금 페디버스에 관한 개념 이해는, "아 내 글이 공개되는 이메일 같은 거군"에서 멈춰 있습니다. 삶이 바빠 긴 개념 문서는 못보겠고, 가끔 짧게 떠먹여 주시는 것들로 차츰 채워가야겠습니다.
洪 民憙 (Hong Minhee)
@hongminhee@hackers.pub · 1017 following · 727 followers
Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub! My main account is at
@hongminhee洪 民憙 (Hong Minhee)
.
Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다. 제 메인 계정은:
@hongminhee洪 民憙 (Hong Minhee)
.
Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。私のメインアカウントは「
@hongminhee洪 民憙 (Hong Minhee)
」に。
Website
- hongminhee.org
GitHub
- @dahlia
Hollo
- @hongminhee@hollo.social
DEV
- @hongminhee
velog
- @hongminhee
Qiita
- @hongminhee
Zenn
- @hongminhee
Matrix
- @hongminhee:matrix.org
X
- @hongminhee
페디버스 지식이 얼마나 없냐 하면요. 마스토돈에서 글 쓰면, @mastodon.social이 붙고, 해커스펍에 글 쓰면 @hackers.pub이 붙는다는 걸 몰랐습니다. 양 쪽 프로필 그림으로 같은 것 쓰면서, 구별 없이, 무념으로 라이트하게 잘 쓰고 있긴 합니다.
@hongminhee洪 民憙 (Hong Minhee)
@kodingwarriorJaeyeol Lee
@gagl3 일본에는 라이브 코딩도 해주고 노트북에 붙일 스티커도 주는 「Hacker's Bar」 가 있는데, 이거 생각나고 재밌네요.
https://hackers.bar/
@noxowlSuyeong RHIE
@kodingwarriorJaeyeol Lee
@gagl3 안 그래도 지난주에 그 바에 대한 얘기가 나오기도 했었습니다!
RE: https://hackers.pub/@diarapin/0195c6a1-c2e0-722d-8b72-136ce75dcf93
@lionhairdino 말씀하신 접두사들에 덧붙여서, 이른바 "연산자 오버로딩"처럼 두 정의가 하나의 이름에 동시에 붙어 있는 경우 竝(나란히 병)을 쓰는 것도 고려함 직하다는 생각을 해 봤습니다. "병행", "병립", "병치" 등에 쓰이는... "오버레이"의 경우는 疊(겹쳐질 첩)이 먼저 떠오르네요. "중첩"이라든지 "첩첩산중" 등에 쓰이는 그거요.
그리고 꼭 한자어에는 한자 접두사를 붙여야 한다는 법이 있는 것은 아니니, 과감하게 고유어를 쓰는 것도 생각해 볼 수 있겠습니다. "겹정의"라든지, "덮정의"라든지... 아예 "겹뜻"이라든지...
@xtjuxtapose 처음 듣는다고 상상해보면, 겹정의와 병립(중복)정의를 듣고, 오버라이딩, 오버로딩 동작을 떠올리는데 무리 없어 보입니다!
개인적으로 커널-알멩이 번역처럼 한글 낱말에서 전혀 원 뜻이 느껴지지 않는 것들은 읽는데 힘들어 하지만, 겹정의는 충분히 이바닥에 자리 잡아도 되지 않을까 싶을 정도로 원 뜻이 살아 있습니다.
겹정의! 재정의보다 더 원 뜻에 가깝다고 생각이 드네요.
@gagl3 노트북에 붙였을 때 간지가 나는 Hackers' Pub 스티커를 만들고 싶다는
@kodingwarriorJaeyeol Lee 님의 말씀이 있었습니다… 😂
@hongminhee洪 民憙 (Hong Minhee)
@kodingwarriorJaeyeol Lee
@gagl3 일본에는 라이브 코딩도 해주고 노트북에 붙일 스티커도 주는 「Hacker's Bar」 가 있는데, 이거 생각나고 재밌네요.
https://hackers.bar/
오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.
만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.
재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.
닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.
널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.
@lionhairdino 말씀하신 접두사들에 덧붙여서, 이른바 "연산자 오버로딩"처럼 두 정의가 하나의 이름에 동시에 붙어 있는 경우 竝(나란히 병)을 쓰는 것도 고려함 직하다는 생각을 해 봤습니다. "병행", "병립", "병치" 등에 쓰이는... "오버레이"의 경우는 疊(겹쳐질 첩)이 먼저 떠오르네요. "중첩"이라든지 "첩첩산중" 등에 쓰이는 그거요.
그리고 꼭 한자어에는 한자 접두사를 붙여야 한다는 법이 있는 것은 아니니, 과감하게 고유어를 쓰는 것도 생각해 볼 수 있겠습니다. "겹정의"라든지, "덮정의"라든지... 아예 "겹뜻"이라든지...
Hackers' Pub 行動規範を拝見し、その根底にあるキーワードは「尊重」と「思いやり」だと強く感じた。だからこそ、僕はHackers' Pubを心から応援している。時間が経っても、その価値観がブレずに、前向きで明るいエネルギーがあふれる場所であってほしい。
それと、もうひとつだけ言うと、開発者のちょっとした日常の話とかも、もっと共有されるといいなって思う。(まずは自分から始めなきゃだけどね)
Hackers' Pub 행동 강령을 관통하는 큰 키워드가, 존중과 배려라고 느꼈고, 그래서 더욱 Hackers' Pub 을 응원하고 있는데, 오랜 시간이 흘러도 추구하는 가치에 흔들림이 없으면 좋겠고, 여기에 더해 긍정적이고 밝은 에너지가 가득한 공간이 되기를 소망한다.
한가지만 더 첨언하자면, 개발자의 소소한 일상 얘기들도 많이 공유되었으면 좋겠다. (우선 나부터도 해야겠지만)
Chrome Built-In AI (EPP)で変更
Canary 136.0.7103.0* 以降、すべての組み込み API に新しいエントリ ポイントがあります。
self.ai.* ではなく、self.* で直接 API を見つけることができるようになりました。静的
create() メソッドを使用して、これらの API をインスタンス化します。
await LanguageModel.create();
await Summarizer.create();
await Writer.create();
await Rewriter.create();
await LanguageDetector.create();
await Translator.create();
同様に、静的 availability() メソッドが追加されました。
await LanguageModel.availability();
await Summarizer.availability();
await Writer.availability();
await Rewriter.availability();
await LanguageDetector.availability();
await Translator.availability();
사실 Hackers' Pub은 저희 집 홈 서버인 Mac mini M4 깡통 모델에서 돌아가고 있을 뿐만 아니라, 배포도 compose.yaml 파일의 image: 필드를 매번 손으로 고친 뒤 docker compose up -d를 치는 전근대적인 방식으로 이뤄지고 있습니다… 뭔가 자동화를 하고 싶긴 한데 귀찮은 마음이 커서 아직까지 이대로 살고 있네요.
가끔 구글 트렌드로 "하스켈" 추이를 봅니다.
지역을 눈여겨 본 적이 없었는데, 지금 보니 "대전"이 1위, "광주"가 2위, 의외로 서울이 3위입니다.
오.. 해커스펍 가입함
@wapj승귤 안녕하세요, 어서 오세요!
오.. 해커스펍 가입함
@hongminhee洪 民憙 (Hong Minhee) 저는 지금도 좋은데..!!
@gagl3 노트북에 붙였을 때 간지가 나는 Hackers' Pub 스티커를 만들고 싶다는
@kodingwarriorJaeyeol Lee 님의 말씀이 있었습니다… 😂
Hackers' Pub 로고 공모전이라도 해야 하나… 😂
@resistanHyunjin Cho 전 아이폰 13 미니 모델 쓰고 있어서 달라지지도 않았어요. 아이폰 15 pro 이상 써야 달라진다고 하던데요. ^^;;
@paperonnetSubi Song
@resistanHyunjin Cho 저도 iPhone 15 일반 모델 쓰고 있어서 Apple Intelligence는 지원 안 되더라고요… 이거 때문에 스마트폰을 업그레이드하기도 뭐하고… 아쉽습니다.
Deno 프로젝트에서 Git 훅을 쉽게 관리하게 해주는 도구인 deno-task-hooks를 소개합니다.
인프라… 인프라 어렵군
deno-task-hooks: Git 훅을 Deno 태스크로 쉽게 관리하기
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
안녕하세요! 오늘은 제가 개발한 deno-task-hooks 패키지를 소개해 드리려고 합니다. 이 도구는 Deno 태스크를 Git 훅으로 사용할 수 있게 해주는 간단하면서도 유용한 패키지입니다.
어떤 문제를 해결하나요?
Git을 사용하는 개발 팀에서는 코드 품질 유지를 위해 커밋이나 푸시 전에 린트, 테스트 등의 검증 작업을 실행하는 것이 일반적입니다. 이러한 작업은 Git 훅을 통해 자동화할 수 있지만, 기존 방식에는 몇 가지 문제가 있었습니다:
- Git 훅 스크립트를 팀원들과 공유하기 어려움 (.git 디렉토리는 보통 버전 관리에서 제외됨)
- 각 개발자가 로컬에서 훅을 직접 설정해야 하는 번거로움
- 훅 스크립트의 일관성 유지가 어려움
deno-task-hooks는 이러한 문제를 해결하기 위해 Deno의 태스크 러너를 활용합니다. Deno 태스크는 deno.json 파일에 정의되어 버전 관리가 가능하므로, 팀 전체가 동일한 Git 훅을 쉽게 공유할 수 있습니다.
어떻게 작동하나요?
deno-task-hooks의 작동 방식은 간단합니다:
- deno.json 파일에 Git 훅으로 사용할 Deno 태스크를 정의합니다.
hooks:install태스크를 실행하면, 정의된 태스크들이 자동으로 .git/hooks/ 디렉토리에 설치됩니다.- 이후 Git 작업 시 해당 훅이 트리거되면 연결된 Deno 태스크가 실행됩니다.
설치 및 사용 방법
1. hooks:install 태스크 추가하기
먼저 deno.json 파일에 hooks:install 태스크를 추가합니다:
{
"tasks": {
"hooks:install": "deno run --allow-read=deno.json,.git/hooks/ --allow-write=.git/hooks/ jsr:@hongminhee/deno-task-hooks"
}
}
2. Git 훅 정의하기
Git 훅은 hooks: 접두사 다음에 훅 이름(케밥 케이스)을 붙여 정의합니다. 예를 들어, pre-commit 훅을 정의하려면:
{
"tasks": {
"hooks:pre-commit": "deno check *.ts && deno lint"
}
}
3. 훅 설치하기
다음 명령어를 실행하여 정의된 훅을 설치합니다:
deno task hooks:install
이제 Git 커밋을 실행할 때마다 pre-commit 훅이 자동으로 실행되어 TypeScript 파일을 검사하고 린트 검사를 수행합니다.
지원되는 Git 훅 종류
deno-task-hooks는 다음과 같은 모든 Git 훅 타입을 지원합니다:
applypatch-msgcommit-msgfsmonitor-watchmanpost-updatepre-applypatchpre-commitpre-merge-commitpre-pushpre-rebasepre-receiveprepare-commit-msgpush-to-checkoutsendemail-validateupdate
이점
deno-task-hooks를 사용하면 다음과 같은 이점이 있습니다:
- 간편한 공유: Git 훅을 deno.json 파일에 정의하여 팀 전체가 동일한 훅을 사용할 수 있습니다.
- 설정 용이성: 새 팀원은 저장소를 클론한 후 한 번의 명령어로 모든 훅을 설치할 수 있습니다.
- 유지 관리 용이성: 훅 스크립트를 중앙에서 관리하므로 변경 사항을 쉽게 추적하고 적용할 수 있습니다.
- Deno의 안전성: Deno의 권한 모델을 활용하여 훅 스크립트의 보안을 강화할 수 있습니다.
마치며
deno-task-hooks는 작은 패키지이지만, Git과 Deno를 함께 사용하는 팀의 개발 경험을 크게 향상시킬 수 있습니다. 코드 품질 유지와 개발 워크플로우 자동화를 위해 한번 사용해 보세요!
패키지는 JSR에서 다운로드할 수 있으며, GitHub에서 소스 코드를 확인할 수 있습니다.
피드백과 기여는 언제나 환영합니다! 😊
코드와 한글 [Code and Hangul]
------------------------------
# 전북대학교 이상로 교수의 연구 아카이브: 한글 코드와 기술 표준화의 기록
이상로 교수가 운영했던 웹사이트는 2000년대 초반 한국의 문자 처리 기술과 코드 변환 연구를 체계적으로 정리함으로, 한글 정보화와 국제 표준화 과정에서 중요한 역할을 했습니다. 이 사이트는 당시 컴퓨터 과학 분야의 학문적 연구와…
------------------------------
https://news.hada.io/topic?id=20085&utm_source=googlechat&utm_medium=bot&utm_campaign=3140
@hongminhee洪 民憙 (Hong Minhee) 노트북에 붙였을때 간지가 나는 디자인이면 좋을 것 같긴.. 하네요.....
@kodingwarriorJaeyeol Lee 로고 자체를 새로 만들어야… 😂
@chapdo찹도 님도 어서 오세요!
@esgdeveloper 님, 어서 오세요!
해커스펍 가로로고랑 정방사이즈 로고만 있으면 어디 부스차려서 스티커 뿌리면서 홍보하기도 괜찮을 것 같은데
@kodingwarriorJaeyeol Lee 이런 게 있긴 한데요… (둘 다 Inkscape 파일.)
일정 추산은 어려운 일이다. TWP(Two-Week Principle)는 모든 시간 참조를 표준화하는 새로운 시간 척도다. 이 제안에 따르면 시간과 관련된 모든 질문에 반사적으로 "2주"라고 응답해야 한다. https://www.rfc-editor.org/rfc/rfc9759
작년에 비하면 조금 약하다 ㅎㅎ 참고로 작년에는...
Faster than LIght speed Protocol(FLIP)은 LLM을 이용해 패킷이 수신 피어에 도착하기 전에 미래의 패킷을 예측함으로써 광속보다 빠른 전송을 달성한다. (...) 이 프로토콜 명세는 AI와 LLM을 사용하기 때문에 멍청한 인간은 이 명세를 리뷰해서는 안 된다고 여겨졌다. 대신 여러 LLM 챗 서비스의 코멘트와 제안으로 개선되어 승인받았다. https://www.rfc-editor.org/rfc/rfc9564
일정 추산은 어려운 일이다. TWP(Two-Week Principle)는 모든 시간 참조를 표준화하는 새로운 시간 척도다. 이 제안에 따르면 시간과 관련된 모든 질문에 반사적으로 "2주"라고 응답해야 한다. https://www.rfc-editor.org/rfc/rfc9759
내년 React Summit Asia는 싱가포르에서 열리는군요! 기회가 된다면 한번 꼭 가 보고 싶네요 🤩
슈티를 그냥 Misskey 클라이언트로 만들어 버릴까...
@analoggreenMTG 나.. 어쩌면.. 인싸일지도..? (웃음)
@analoggreenMTG
@kodingwarriorJaeyeol Lee 님은 인싸 맞죠…
@parksbSimon Park 헉 어떻게 하셨나요
@kodingwarriorJaeyeol Lee 심플하게 가장 가까운 .vim/config.lua 파일을 찾아서 해당 파일에 명시된 린터와 포매터 정보를 읽도록 만들었어요. 급하게 필요해서 만든거라 엉성해요 ㅎㅎ https://github.com/parksb/dotfiles/commit/ca3bc66b03a9c2ed2dc7388bedc78fe9d62dbb08
@hongminhee洪 民憙 (Hong Minhee) 행사장마다 커뮤니티 부스 차리는곳 도장깨기 갑니다 캬캬캬
@kodingwarriorJaeyeol Lee 오오오…!!
@bglbgl gwyng 어라 Cabal이 기본적으로 스냅숏 모드로 동작하나요? Stack만 쓴 지 몇 년 되어서 Cabal이 그랬던가 기억이 가물가물하긴 한데요…
@hongminhee洪 民憙 (Hong Minhee) 음 표현이 좀 잘못된거 같네요. 버전에 constraint들 명시하면 그거 resolve해서 설치하겠죠. 제가 말하려고 했던건 lock이 개별 패키지 별로 안남고 indexed-state로 스냅샷 시간을 명시하는 방식이 마음에 안든가 거였습니다. cabal.freeze 또한 암호해시가 안 남고요.
나름? 전략적으로 초대장 뿌리고 있는데 홍민희님보다 많이 초대하는 업적도 가능할듯(?)
@kodingwarriorJaeyeol Lee 저는 좋습니다. ㅎㅎㅎ
근데 cabal처럼 기본이 스냅샷 모드인건 별로 같다. cabal로 locking하려면 시간으로(스냅샷을 특정할) 해야한다;; npm같이 각 패키지 버전과 lock이 있는 편이, 일단 심리적으로 더 든든하고, 또 가장 원자적인 동작을 더 확실하게 만든단 점에서 좋다.
대신 그 위에서 스냅샷(이라고 해야하나, 다른 이름이 있던거 같기도한데)을 다시 구현할수 있다. Expo같은 경우에 expo 패키지에 따라 나머지 expo-* 들의 버전이 결정되도록 한다.
@bglbgl gwyng 어라 Cabal이 기본적으로 스냅숏 모드로 동작하나요? Stack만 쓴 지 몇 년 되어서 Cabal이 그랬던가 기억이 가물가물하긴 한데요…
남들은 바이브 코딩이다, MCP다 하고 있는데 나는 오늘 Neovim에 워크스페이스별 로컬 설정 파일을 적용하는 기능을 구현했다. 근데 어떡하나 이게 재미있는데...
불과 작년까지도, DB설계시에 uuid 를 쓰지 않는 키값은 int 보다 bigint 를 선호했으나, 이제는 로그성 데이터같은 빈번하게 등록되는 데이터가 아닌 이상 int 를 사용한다. bigint 의 사용은 당연히 미래를 위한 결정이었지만, 내가 만드는 서비스들이 웬만해서는 int 를 뛰어넘지 않는다는 것을 깨달았고 (약 20억이면 충분), 언젠가 bigint 로 마이그레이션해야 하는 서비스가 되었으면 좋겠다.
@hongminhee洪 民憙 (Hong Minhee) 프로필 사진으로 쓸 수 있는 그림 형식 중에 SVG가 없는데, 혹시 액티비티퍼브의 한계인가요? (갑자기 궁금해서)
@xtjuxtapose ActivityPub의 한계는 아닌데 Mastodon을 비롯한 주요 구현들이 지원을 안 하는 건 사실입니다. 음… SVG를 업로드하면 Hackers' Pub 내부에서는 SVG로 보여주고 ActivityPub으로는 래스터화해서 보내는 식으로 편법을 쓸 수는 있을 것 같네요.
인용한 글의 내용과는 상관 없는 이야기인데, 현재는 단문에서는 단문이든 게시글이든 인용할 수 있는 반면, 게시글에서는 단문도 게시글도 인용을 못 하게 되어 있다. 별 생각을 안 하고 그렇게 만든 거긴 한데, 잘 생각해 보니 오히려 인용 기능은 게시글에서 더 유용할 것 같다.
하루 빨리 게시글에서도 인용이 가능하게 개선을 하도록 하겠습니다…
洪 民憙 (Hong Minhee) shared the below article:
스태키지 큐레이션이 성공할 수 있었던 것은 하스켈이라는 언어와 생태계의 특징도 컸습니다.
juxtapose @xt@hackers.pub
인용: https://hackers.pub/@bgl/0195f0eb-88dd-77e3-a864-f0371e85b270
스태키지(Stackage)는 하스켈이 (의외로) 성공하여 해키지(Hackage)가 거대해지자, 그 거대함 때문에 발생하는 불편을 해소하는 한 방책으로 고안되었습니다. 그런데 당시에 해키지만큼 거대한 생태계를 갖추고 있으면서 동시에 "컴파일이 성공한다면 실행도 아마 성공할 것"이라는 훌륭한 속성을 갖는 언어는 달리 없었죠. 러스트가 있지 않으냐? 스태키지가 처음 나온 게 2012년입니다. 러스트는 아직 crates.io 도 자리잡기 전이었죠. (사실 이 시점의 러스트는 지금과는 언어 자체가 많이 다른 언어였고요.)
하스켈의 패키지 버저닝 정책에 따르면, 후방호환성 깨지는 변경은 반드시 메이저 버전을 올려야 하고, 마이너 버전만 올리는 변경은 후방호환성 유지될 때에만 가능합니다. 이런 정책 당연히 좋지만, 사람이 내용을 잘 숙지하고 지켜야 의미가 있습니다. 후방호환성을 깨면서 마이너 버전만 올리는 실수는 어떤 개발자든 할 수 있죠.
그런데 하스켈의 경우, 인간이 실수해도 기계가 잡아 줄 여지가 처음부터 매우 큰 언어이고, 예를 들어 어떤 함수가 핵미사일을 발사할 수 있는지 아닌지를 함수 실행 없이도 식별할 수 있는 언어라고들 하죠. 하스켈의 마지막 표준이 2010년에 나왔으니 2010년을 기준으로 하면, 당시 하스켈이 제공하는 "컴파일 시간 보장"의 범위는 그야말로 독보적이었습니다. (하스켈보다 더 강한 보장을 제공하는 언어들은 있었지만, 그만한 라이브러리 에코시스템이 없었고요.)
그래서 스태키지라는 모형이 의미가 있었습니다. A라는 패키지의 새 마이너 버전이 해키지에 올라오면, 스태키지에서 자동으로 가져갑니다. 스태키지는 같은 큐레이션에 포함된 다른 패키지들 중 A에 의존하는 패키지들을 추리고, 얘네한테 A의 새 버전을 먹여도 빌드가 잘 되는지 검사합니다. 이들 중 하나라도 깨지면? A 패키지는 해키지에서는 버전이 올랐으나, 스태키지에서는 버전이 오르지 않게 됩니다. 그리고 A 패키지의 제공자에게 자동으로 깃허브 멘션 알림이 갑니다!
("패키지 저자"와 "패키지를 스태키지에 제공하는 제공자"가 같은 사람이 아니어도 된다는 점도, 노동력의 효과적 분담에 한몫했습니다.)
이 모든 과정이 자동화되어 있는데, 이것만으로도 99.99%의 호환성 문제가 사라지고, 그러면서도 웬만한 라이브러리들은 충분히 최신 버전으로 쓸 수 있습니다. LTS와 나이틀리가 구분되어 있는 것도, LTS가 GHC 버전에 대응하여 여러 버전이 유지되는 것도, 실제 개발에서 아주 편리하고요.
스태키지가 개쩌는 부분은 "버저닝 정책에 완벽하게 부합하는데도 현실적으로 후방호환성 파괴를 일으키는" 변경점들도 잡아낸다는 것입니다. 아주 단순한 예시로 "많이 쓰이는 이름"이 있습니다. 예를 들어 어떤 라이브러리가 아주 널리 쓰이는데, 제공하는 네임 바인딩은 몇 개 안 되고, 그래서 대부분의 사용자가 그걸 그냥 전역 네임스페이스에 다 반입해서 쓴다고 칩시다. 어느 날 이 라이브러리가 process 라든지 f 같은 새 네임을 추가 제공하기 시작하면? 정책 규범에 따르면, 이것도 마이너 버전만 올려도 되는 변경점이 맞습니다. 하지만 현실에서는 많은 패키지들을 박살내겠죠. 언어를 막론하고 있을 수 있는 일인데, 이런 것들까지 스태키지에서 아주 높은 확률로 다 잡힙니다.
그리고... 이런 게 잘 된다는 것은 언어 그 자체의 특성도 있지만, 생태계 전체의 문화적인 특성도 있는데요. 하스켈도 라이브러리 제작자가 충분히 악독하다면, 컴파일러에게 안 잡히면서 인류문명멸망시키는 코드 변경을 얼마든지 슬쩍 끼워넣을 수 있습니다. 악의가 아니더라도 부주의로 후방호환성을 깰 수 있고요. 그런데 하스켈은 대부분의 라이브러리 설계자들이 "되도록 많은 것을 컴파일 시간에 잡고 싶다"라는 명확한 욕망으로 설계를 하는 경향이 뚜렷합니다. 그래서 호환성 문제는 웬만하면 스태키지 선에서 잡히고, 스태키지 큐레이션은 지난 10년 동안 실무상 아주 유용한 도구로 기능해 온 것이죠.
어지간하면 큐레이션만 잘 고르고 잘 갱신하면 되고, 종속성 목록에는 mypkg >= 2.1.1 && < 2.1.2 이런 거 하나도 관리 안 하고 그냥 mypkg 라고만 써도 된다는 것이, 솔직히 개짱편합니다. 다행히 지난 10년 동안 "문제의 소지는 컴파일 시간에 검출하는 게 좋다"라는 생각이 더 널리 받아들여져서, 다른 언어들도 이런 접근을 더 시도할 여지가 생긴 것 같군요.
CMake 3.20 즈음에서 add_test동작이 바뀐 것 같은데 generator expression중 conditional expression으로 인자 없음 혹은 정해진 값을 기대하는 코드가 인자 없음 대신 “”로 생성을 해버려서 동작이 완전히 틀려져버렸고, 4.0에서도 유지되고 있다. 어디서 바뀌었는지 릴리즈노트를 조금 봤는데 못 찾았다.
CMake 4.0이 나오면서 3.5미만에 대한 지원을 제거했다고 한다. 그러면서 최소 CMake 버전을 3.4로 지정되어있는 프로젝트는 스크립트를 실행해보지도 않고 실패 취급 해버린다.
퇴근도 했으니 바이오를 써보자...
허걱 대박. 초대한 사람 이제 50명째 찍음
Gemini 2.0 Flash 글 정말 못 쓴다…
스냅샷 방식이 이론적으로는 참 좋은데, 제대로 돌아가려면 사람들이 새로운 버전을 테스트하고 호환되는 버전을 업데이트하는 등의 잡다구리한 수고를 다 같이 해줘야 한다는 문제가 있(었)다. 하지만 요즘 잡다구리한 수고가 매우 저렴했으니 올바른 방법을 다시 밀고나갈수 있게되었다.
RE: https://hackers.pub/@hongminhee/0195f09a-a7d0-79aa-a819-bdcf97d6d830
@xtjuxtapose 제보 감사합니다. 🙇🏻♂️
@hongminhee洪 民憙 (Hong Minhee) 지금 "내가 팔로하지 않은 사용자를 포함해, 이 인스턴스에 올라온 모든 글 보기" 타임라인도 없는 거죠? (로그인 상태에서는)
@meWoojin Kim
@curry박준규 이럴수가... 한번더 깊게 누를수 있엇군요.
플러그인과 미들웨어의 번역어로, '냅다 꽂기'와 '슬그머니 끼워넣기'를 제안합니다. 부정적인 어감은 의도한 바입니다.
Giving up the dylib dream—이 글에서 제안하고 있는 “안정적인 crates.io 미러” (“a ‘stable’ crates.io mirror”) 아이디어를 듣자마자 Haskell의 Stackage가 떠올랐다.
Stackage는 Haskell의 패키지 저장소인 Hackage에서 상소 호환되는 패키지들을 엄선한 스냅숏(curated snapshots)을 제공한다. 이는 글에서 언급된 여러 문제들을 해결한다:
- 모든 패키지가 함께 빌드되는 것을 보장하는 장기 지원(LTS) 릴리스 제공.
- 호환 가능한 의존성의 최소 집합을 해결함으로써 “의존성 지옥”(dependency hell) 방지
- 혁신을 가능케 하면서도 생태계의 안정성도 창출
- 검증되고 호환 가능한 패키지 세트를 제공하여 배포판 메인테이너를 도움
Stackage 모델은 특히 Stack이라는 툴체인을 통해 Haskell 쪽에서 꽤 성공을 거두었는데, 생태계 안정성과 발전 사이의 균형을 맞추는 방식으로, 아마 Rust에서도 잘 작동할 수 있을 것이다.

