개인적으로 쿠버네티스를 편하게 쓰기 위한 공부를 어느 정도 마친 상태에서 보면 "아 이거 쿠버 하나만 떠 있으면 편하게 이것저것 띄우고 할 수 있는데 괜히 귀찮게 세팅해야 하네"라는 생각이 들기도 하지만 😅 쿠버네티스 잘 모르는 상태에서는 참 막막하겠다 싶긴 합니다....

RE: https://hackers.pub/@xt/01961970-a29f-78ff-baaf-1db2056a78e1

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

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

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

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

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

Hackers' Pub의 에모지 반응 기능은 Mastodon의 좋아요, Misskey 계열, Pleroma 계열, kmyblue 및 Fedibird의 에모지 반응 기능과 호환됩니다. 기술적으로는 기본 에모지인 ❤️는 Like 액티비티로 표현되며 그 외 나머지 에모지는 EmojiReact 액티비티로 표현됩니다. Mastodon, kmyblue, Fedibird의 좋아요는 ❤️ 에모지 반응으로 변환됩니다 (Misskey의 동작과 유사). 또한, Misskey 계열과 달리 한 사람이 한 콘텐츠에 여러 에모지 반응을 남길 수도 있습니다 (Pleroma 계열의 동작과 유사). Hackers' Pub 사용자가 남길 수 있는 에모지 반응은 ❤️, 🎉, 😂, 😲, 🤔, 😢, 👀 이렇게 7종이며, 그 외의 에모지 및 커스텀 에모지는 보낼 수는 없고 받는 것만 됩니다.

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

Update: 이제 합니다!

https://www.prisma.io/blog/prisma-orm-6-6-0-esm-support-d1-migrations-and-prisma-mcp-server

RE: https://hackers.pub/@bgl/01960fc7-4502-777d-9761-01bfe6b87ed7

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

홍민희에게서 보기 힘든 말투다 욱기네
https://hackers.pub/@hongminhee/019613cb-d1ce-7826-a289-918fb81655d4

패치 릴리스할 때 되도록이면 많은 버그 수정을 하나의 릴리스에 담고 싶은 충동.

@hongminhee洪 民憙 (Hong Minhee) ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

그러네

음 더 길어야 하나

문득 alt text가 매우 길어지면 UI 상으로 어떻게 보일지 궁금해짐

코드:

test("streaming ssr", async () => {
    const Comp = (props) => {
        const data = createAsync(() => props.promise);
        return (
            <Suspense fallback="Loading...">
                <span>Data: {data()}</span>
            </Suspense>
        );
    };
    const stream = await run$("server", async (ctx) => {
        const { promise, resolve } = Promise.withResolvers();
        ctx.set("resolve", resolve);
        return renderToStream(() => <Comp promise={promise} />);
    });
    await run$("client", async () => {
        hydrate(stream, document.body);
    });
    await expect$("client").element(page.getByText("Loading...")).toBeInTheDocument();
    await run$("server", async (ctx) => {
        const resolve = ctx.get("resolve");
        resolve(42);
    });
    await expect$("client").element(page.getByText("Data: 42")).toBeInTheDocument();
    await expect$("client").element(page.getByText("Loading...")).not.toBeInTheDocument();
})

Vitest에 이상한 거 제안하는 중

@hongminhee洪 民憙 (Hong Minhee) 컼 너무 미어터지는데 깃허브처럼 별도 row로 두고 0은 숨기도록 하면 어떨까요

@darkenpengpenguin 저도 뭔가 여기는 개발 얘기만 써야 할 것 같다는 생각이 들더라구요 ㅋㅋㅋㅋㅋㅋ

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

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

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

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

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

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

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

JavaScript에 Object.map() 같은 함수 하나 있었으면 좋겠다. 맨날 Object.fromEntries(Object.entries(obj).map(...)) 하기 귀찮다. (게다가 TypeScript에서 타입도 보존이 안 되어서 as 키워드 써야 함…)

@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng require(ESM)은 CJS에서 ESM을 갖다 쓰는 상황을 위한 거라서 이런 경우에 도움이 되지는 않습니다 🥲 ESM에서 CJS를 가져다 쓰려면 default import로 export 객체 전체를 import해서 쓰거나, createRequire()로 require 함수를 직접 만들어서 써야 하는데, 둘 다 영 편한 방법은 아닙니다 😇

@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng 리액트/릴레이도 CJS 빌드밖에 없습니다 ㅋㅋㅋㅋㅋ

Gemini Pro 2.5 엄청 똑똑하다... 기존 모델들은 대화가 길어지고 내용이 깊어지면 그냥 뻔한소리를 반복하기 시작하던데, 얘는 계속 생각해서 아이디어를 살려준다.

러스트에서 SIMD 코드 짜기 너무 고통스럽다 어떻게 좀 해달라... Rust 2024에선 unsafe_op_in_unsafe_fn 때문에 더 고통스러워졌다...

액펍 특성상 완전한 삭제는 매우 어렵습니다 (삭제 액티비티가 전달되지 않는 서버가 있을 수 있음)

일본에 Fediverse Linux Users Group이라는 모임이 있는데, 거기서 〈국한문혼용체에서 Hollo까지〉라는 이상한 주제로 오늘 발표를 합니다…

RE: https://hollo.social/@hongminhee/019603c7-b5ef-7d81-bbd4-4c37d46edce9

가끔 보면 Misskey는 ActivityPub을 마지못해 지원하는 것 같다니까요. (실제로 만든 사람이 그런 뉘앙스의 얘기도 몇 번 했었고.)

Servo vs Ladybird

https://thelibre.news/servo-vs-ladybird/

Hackers' Pub의 소스 코드 저장소를 제 개인 계정에서 hackers-pub 조직 계정으로 옮겼습니다.

https://github.com/hackers-pub/hackerspub

Hackers' Pub에 이제 알림 기능이 생겼습니다. 우상단 프로필 사진 바로 왼쪽에 알림 아이콘이 추가되었고, 이제 읽지 않은 알림이 있을 경우 그 위에 빨간 동그라미가 표시됩니다. 알림의 종류는 현재 다음 다섯 가지입니다:

• 누가 날 팔로했을 때
• 누가 날 언급했을 때
• 누가 내 글에 답글을 달았을 때
• 누가 내 글을 인용했을 때
• 누가 내 글을 공유했을 때

지금 Hackers' Pub에는 Fresh 2.0 알파를 쓰고 있는데, 여러 가지 아쉬운 점이 많지만 그 중 하나가 아일랜드 컴포넌트로 콘텍스트가 전달이 안 된다는 것. 현재 아일랜드 컴포넌트에는 로캘 같은 정보를 일일히 프랍(prop)으로 넘겨줘야 한다…

RE: https://hackers.pub/@kodingwarrior/0195f94d-61f3-7cab-8a34-f2a8ab0f9a4a

사실 Hackers' Pub은 저희 집 홈 서버인 Mac mini M4 깡통 모델에서 돌아가고 있을 뿐만 아니라, 배포도 compose.yaml 파일의 image: 필드를 매번 손으로 고친 뒤 docker compose up -d를 치는 전근대적인 방식으로 이뤄지고 있습니다… 뭔가 자동화를 하고 싶긴 한데 귀찮은 마음이 커서 아직까지 이대로 살고 있네요.

쿨엔조이 M.2 SSD 방열판 벤치마크 4년이 넘은 글이긴 한데...

• 제조사에서 권장하는 방식을 유유히 비웃으며 직접 이상한 짓(서멀패드를 끼워줬는데 버리고 다른 서멀패드를 쓴다든지)을 해야 실측 결과 더 좋게 나오는 제품이 수두룩... 하긴 M.2 SSD의 표면 요철 형상까지는 표준화가 안 되어 있으니
• 방열 성능만 따지면 서멀패드보다 서멀그리스가 우월한 것은 어쩔 수 없는 듯
• "조이쿨 JH-M.2 SSD 30MM"은 당시 6570원이었고 "조이쿨 M.2 SSD 히트파이프 쿨러"는 무려 16000원으로 두 배도 훨씬 넘는 가격이었는데, 6570원짜리가 더 성능 우수. 심지어 같은 회사인데
• RGB LED 달고 있으면 성능 폭락 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

인용한 글의 내용과는 상관 없는 이야기인데, 현재는 단문에서는 단문이든 게시글이든 인용할 수 있는 반면, 게시글에서는 단문도 게시글도 인용을 못 하게 되어 있다. 별 생각을 안 하고 그렇게 만든 거긴 한데, 잘 생각해 보니 오히려 인용 기능은 게시글에서 더 유용할 것 같다.

하루 빨리 게시글에서도 인용이 가능하게 개선을 하도록 하겠습니다…

RE: https://hackers.pub/@xt/2025/stackage-why

@xtjuxtapose ActivityPub의 한계는 아닌데 Mastodon을 비롯한 주요 구현들이 지원을 안 하는 건 사실입니다. 음… SVG를 업로드하면 Hackers' Pub 내부에서는 SVG로 보여주고 ActivityPub으로는 래스터화해서 보내는 식으로 편법을 쓸 수는 있을 것 같네요.

많은 부분 Hackers' Pub에서 이미 사용하고 있는 패턴들. 그리고 기본 키를 uuid로 했을 때 지역성(locality)가 떨어져서 성능상 손해를 보는 문제는 UUIDv7을 쓰면 해결된다.

RE: https://sns.lemondouble.com/notes/a61hofry16

레트로 웹 마니아 @limeburstJihyeok Seo 가 만든 호스팅 플랫폼 나루(https://naru.pub/)에 나도 2005년 감성의 홈페이지를 하나 깎아서 띄워볼까 함…(2005년인 이유: 내 html, css, js 지식이 20년 전에 멈춰있음)

많은 분들이 인용 방법을 혼란스러워 하셔서, 인용 버튼을 추가했습니다. 게시글이나 단문 아래의 아이콘들 중에 왼쪽에서 세 번째 아이콘을 누르시면 해당 콘텐츠를 인용한 글들이 나열되고, 그 위에 인용 글 입력란이 뜨게 됩니다. 거기서 인용 글을 쓸 수 있습니다. 아, 종래의 인용 UI도 그대로 사용하실 수 있습니다.

참고로 인용 아이콘은 @xtjuxtapose 님께서 수고해 주셨습니다. 감사합니다.

RE: https://hackers.pub/@xt/0195eb06-9f50-763d-85c8-5600ec78c539

요즘 주의 깊게 보고 있는 두 언어:

• Gleam: Erlang의 OTP 런타임에서 돌아간다는 점에서 Elixir와 비슷한데, 처음부터 정적 타입 언어로 설계되었다. 아, JavaScript 타깃도 지원한다. Haskell의 타입클래스(typeclass)나 Rust의 트레이트(trait)에 해당하는 기능이 없다는 게 개인적으로는 조금 아쉬운 점.

• MoonBit: 중국 쪽에서 주도해서 만들고 있는 WebAssembly 타깃 언어로, 이지 모드 Rust에 가까워 보인다. 다만 개발 과정이 완전히 오픈 소스는 아니고, (오픈 소스 라이선스이긴 하지만) 소스만 공개하는 형태라 거버넌스 측면에서 아쉬움이 있다.

We're incredibly honored to announce that #Ghost (@indexBuilding ActivityPub) has become a formal sponsor of Fedify through Open Collective!

This is a significant milestone for our project, and we're deeply grateful to @johnonolanJohn O'Nolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.

Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.

If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:

https://opencollective.com/fedify

Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️

Wine을 이용해서 Windows 실행 파일을 곧바로 실행할 수 있는 Linux 배포판이 필요하다는 주장. 황당하긴 한데, 이유를 들어보면 말은 된다. Linux 실행 파일들은 죄다 libc를 링크해서 시스템 콜을 직접 하기에 실행 파일들이 불안정(unstable)한 반면, 사유 소프트웨어인 Windows는 처음부터 실행 파일이 직접 시스템 콜을 하게 하지 않고 user32.dll 같은 시스템에서 제공되는 라이브러리를 동적 링크하여 쓰도록 하기 때문에 Windows 95 시절의 실행 파일도 Windows 11에서 실행할 수 있을 만큼 실행 파일이 안정적(stable)이다. 따라서 Linux에서 안정적으로 배포할 수 있는 유일한 실행 파일 형식은 Wine을 통한 Windows 실행 파일 뿐인 셈이 된다.

나도 비슷한 까닭으로 15년 넘게 Vim/Neovim 써 오다가, 몇 해 전부터 VS Code를 써 왔고, 요즘엔 Zed를 함께 쓰고 있다. Zed가 조금만 더 발전하면 Zed를 메인으로 쓰게 될 날이 올 듯…!

RE: https://yuri.garden/notes/a5zx8jmbwl

언젠가 해커스펍 오프라인 밋업 같은 거 하면 사진기사 겸 봉사자로 놀러가고 싶음

ActivityPub 효율적으로 익히려면 그냥 fedify 문서 첨부터 끝까지 읽으면 되는듯요

연합우주에 새 계정 만들기 (즐겁다)

컼 점점 중간에 ㅌㅌ할 수 없게 되어버린다

RE: https://hackers.pub/@hongminhee/0195e0f7-8c44-76c6-8c60-4f1978e5f4a2

@kodingwarriorJaeyeol Lee @curry박준규 알림은 조만간 구현 예정이고, Mastodon API는 아마도 구현 안 될 것 같아요. 대신 @xiniha 님 주도로 GraphQL API가 생길 예정!

오에카키 커뮤니티 오이카페를 오픈 소스로 공개했습니다.

Rust, Axum, MiniJinja, HTMX 등으로 만들었고, 그림판은 PaintBBS NEO와 tegaki.js를 지원합니다.

많은 관심 부탁드립니다!