Mi:dm ollama 변환하긴 했는데, 그냥 평소에도 코드 에이전트 말고는 안쓰다보니, 뭐 시켜볼지 모르겠다 😂

hyperclovax think 14B모델도 올라왔길래 변환 해보려고 하니까 지원 안하는 architecture라고 한다. claude한테 변환 스크립트 고쳐보라고 시켜봐야지

단위가 'µg/m³'로 변경되었으며, 이전에 저장된 단위인 'μg/m^3'으로 변환할 수 없습니다.

네...?

결국 컨테이너로 돌리던 HomeAssistant는 HomeAssistant OS로 대체를 했고, OpenWrt 설치된 라우터에 caddy를 올렸다. 그리고 겨어어얼국에는 Matter + Thread 장치를 연결하는데 성공했다. 이름을 잃어버린 zigbee장치들이나 찾아서 복구해야지...

대충 이런 상황입니다...

호옥시 RF replay 하기 위한 설정 아시는 분 계실까요?

요구사항은 447.675MHz 리모컨의 신호를 rpi에서 복제하고 싶은데... 찾아보면 다들 443MHz만 쓰고 있고, 447.675는 모르겠단 말이죠...

그냥 traefik을 계속 써왔는데, 이제는 docker연동도 쓸데 없고 router에 올리기에는 바이너리가 너무 거대해서, caddy로 옮겨가보려고 합니다. 하지만 시작부터 문제 발생... dns-challenge만 할 수 있는 환경인데 이건 직접 빌드 해야할 듯 하네요... 온라인 빌더가 실패...

matter over thread 설정하려다가 zigbee설정 날려버렸는데...

zigbee/thread multi protocol로 돌리려면 rpi를 아예 밀어야 된다는 결론에 도달했다.

일단 zigbee설정을 백업 해둔 것으로 살렸지만, HA내에서의 장치 구분 정보는 날라간 상태라 정체 불명인 344개의 Entity가 되어버렸다... 아니... 왜 이건 백업 안된거야...

거의 느낌이 더 좋다는 이유만으로 rootless컨테이너를 시도했고, 이후에는 갈아엎기 귀찮다는 이유로 계속 써왔다. uid를 외부랑 일치 시키면 이미지가 권한 관련 문제를 일으키기도 하고, 자동으로 이미지내 파일 소유를 바꿔주는 기능은 첫 실행 시 너무 느리기나 하고... 자동 재시작은 systemd랑 엮어서 쓸 수 있다고 알고 있기는 한데 어쨌든 별도의 시스템이라 아직도 안쓰고 있다. 아마 별 일 없으면 계속 이렇게 쓰겠지...?

사랑하는 연합우주 가좍 여러분..
전할 말씀이 있습니다...

한국 연합우주 개발자 모임(https://fedidev.kr)이 파이콘 한국 2025에 커뮤니티 후원을 하게 되었는데요. 이를 통해 총 세 분께 이벤트로 파이콘 한국 2025 티켓을 드릴 수 있게 되었습니다..

파이콘 한국 2025에 참가하고 싶은 분들은!!! 이벤트에 응모해주시면 됩니다!!

[응모 자격]
연합우주 누구나

[응모 기한]
7월 27일 (일) 자정까지

[응모 방법]
이 글에 멘션으로 본인이 만든 페디버스 앱 자랑하기

개인이 사이드 프로젝트로 만든 mastodon/misskey/pixelfed 등등등 클라이언트,
액티비티펍 서비스의 API를 활용한 프로젝트(ex. quesdon)
액티비티펍 연동 라이브러리

등등등 어떤 것이든 좋습니다!!

--
응모하신 분 중 세 분을 선정하여 파이콘 한국 2025 티켓을 드리도록 하겠습니다.

많은 관심 부탁드려요~~

연합우주의 여러분을 파이콘 한국 2025에 초대합니다!

안녕하세요. Hackers' Pub이 이번 파이콘 한국 2025에 커뮤니티 후원을 하게 되었는데요. 이를 통해 총 세 분께 이벤트로 파이콘 한국 2025 티켓을 드릴 수 있게 되었습니다.

파이콘 한국 2025에 참가하고 싶었던 분들은, 이벤트에 응모해 주세요! 이벤트 응모 방법은 다음과 같습니다.

응모 자격

연합우주의 누구나

응모 기한

7월 27일(日) 자정까지

응모 방법

다음 주제어들 중 하나로 N행시를 멋지게 지어서, 인용 또는 답글로 달아주세요! (Mastodon의 경우에는 인용이 안 되므로 답글만 가능합니다.)

• 파이콘/파이컨
• 파이썬/파이선
• 해커스퍼브/해커즈퍼브/해커스펍/해커즈펍

예:

• 파이썬이 좋아서
• 이번에는 꼭 파이
• 콘에 가고 싶습니다!

응모하신 N행시 중 멋진 작품을 제출하신 세 분을 선정하여 파이콘 한국 2025 티켓을 드리도록 하겠습니다!

많은 참여 부탁드립니다!

금방전에 쇼핑몰에서 비회원 주문 하는데, "추가정보 입력으로 가입 함께하기"라는 체크박스가 있고, 체크 해보니 이메일, 아이디, 비밀번호만 추가 요구 하길래 가입을 했다. 꽤 깔끔한 가입 권유 흐름인 것 같다.

내 프로젝트에 이제 js dot org 도메인이 붙기 시작했다.

설치 프로그램이 설치할 프로그램보다 더 높은 버전의 glibcxx를 요구하는 것 같다... 불합리해...

Diffsitter – A Tree-sitter based AST difftool to get meaningful semantic diffs

Link: https://github.com/afnanenayet/diffsitter
Discussion: https://news.ycombinator.com/item?id=44520438

내가 예민한건가. LLM이 "여기서 as any 한 번 정도는 괜찮아요"라며 구슬린다

한쪽은 신기능 백엔드 구현 및 프론트엔드 붙이기 작업. 한쪽은 149개 파일을 하나하나 다 건드리는 국제화 노가다 작업..

쿼드코어 바이브코딩은 여기서도 빛을 발휘한다..

Node.js 커뮤니티는 환경 변수를 너무 좋아하는 것 같다. 거의 라이브러리 API의 일부로 생각하는 듯?

Deno만 해도 환경 변수는 --allow-env 플래그를 통해 명시적으로 허용하지 않으면 접근 못하고, Haskell에서도 getEnv는 String이 아니라 IO String을 반환하게 되어 있다.

반면 Node.js에서는 process.env로 너무 쉽게 접근 가능해서 그런가, 환경 변수 접근이 입출력이라는 생각을 아예 안 하는 모양이다.

Claude code가 trait설명 안 읽고는 구현 해달라는 곳에 TODO만 남기길래 문서 좀 읽어! 라고 했더니 열심히 크롤링하고는 틀린 코드를 작성해줬다...

한때 이 문제에 대한 해법으로, 텍스트로 된 소스 코드가 아닌 문법 트리를 직접 편집하는 식의 IDE를 구상한 적이 있었다. 그런데 이제 대 LLM 시대가 와서 AI도 텍스트를 주로 다루잖아. 우린 안 될 거야 아마.

𝑾𝒉𝒚𝒓𝒂𝒏𝒐...

역시 LLM은 숫자를 모른다.

GCC의 name mangling에는 글자수가 있는데, 3가지 name mangling 요청한 것 중 2개가 글자수가 틀려서 잘못된 결과물이 나왔다. 하지만 MSVC 스타일에는 글자수가 없어서 그동안 너무 잘해줬고...

COMPILING!

이 글을 보고, Windows에서 Git Bash를 통해서 Claude Code를 쓰고 있는데, 일단 동작이 큰 문제 없이 되는 것만으로도 만족스럽습니다.

몇가지 문제사항이 있기는 합니다.

• IDE 통합 기능이 동작안하는 것
• 페이지 스크롤링 관련된 동작이 한번씩 오동작 하면서 이상한 곳을 보여준다던가...

하지만 전반적으로 잘 동작합니다.

@hongminhee洪 民憙 (Hong Minhee)

그런 거 쓸 거면 Python 안 쓰죠

프로그래밍 언어의 언권?투사가 되게 만드는 발언이군요. 어떤 프로그래밍 언어든 저런 취급을 받아선 안됩니다. 설령 PHP, 아니 Brainfuck이라고 하더라도 린터와 포매터는 갖추고 살아야합니다.

막상 API 문서에서 쓰는 것과 다르게 인자를 쓰니가 별 문제 없네...? 그냥 써야지

https://crates.io/crates/borrow 를 나름 만족스럽게(?) 쓰고 있는데, 지금 보니까 진짜 인기 없다.

partial borrow가 필요한 경우를 위한 성가신 코드 작성을 피하고 unsafe 를 직접 작성하는 것을 피하는 용도이긴한데, 그냥 직접 작성할만하기는 하니 인기가 없는 것 아닌가 싶다.

어쨌든... 나만 잘 쓰면 되는 것 아니냐 싶지만, 최신 clippy를 쓰면 macro내부에서 에러가 발생해서 계속 쓸지 말지 약간 고민이 된다.

@jarm정아름 세계최초 티셔츠로 전파되는 악성코드(

검색을 해 봤는데 https://sci.tea-nifty.com/blog/2025/05/post-7f3fa2.html 라고 하더라구요

대학원 연구실 홈페이지 생성기를 만들었습니다. Jekyll은 Ruby니까, 이번엔 Python을 좀 써보자 싶어서 Pelican으로 구현했습니다. Article을 일종의 DB처럼 사용해서 멤버나 논문, 뉴스, 강의 등의 데이터를 관리하는 방식입니다.

솔직히는 하루이틀이면 끝날줄 알았는데 만드는데 거의 full-time으로 일주일이 걸렸네요. macro에서 왜 context가 전달이 안되는지, filter에서는 왜 안되는지, GitHub Action은 왜 맨날 뻑이 나는지... branch 규칙도 여러번 수정하고 github pages로 내보낼때만 fork me 리본 달아주고 등등... 왤케 자잘하게 할게 많은지ㅠ

Pelican 자체는 쓸만하더라구요. 필요한 기능이 거의 다 있습니다. 근데 없는것처럼 보여요. 근데 다 있긴 합니다.

암튼... 구경와주세요

https://github.com/theeluwin/pelican-labsite

어플리케이션에게 주어진 권한을 프로그램을 새로 빌드해도 유지하려면 codesign을 수행해야 합니다. 안그러면 설정 UI에서는 권한이 주어진 것으로 보이지만 권한이 없는 난감한 상황을 봐야만 합니다.

https://github.com/Perlmint/ARISU UI라고 할 것도 없지만 claude덕에 rust로 mac 어플리케이션 UI작성과 서버 실행/정지를 구현했습니다. 전에 문제였던 과도하게 친절한 단축키 맵핑은 아무래도 클라가 문제라, 이렇게 된 이상 클라도 만든다라는 방법 밖에 없지만, 일단 만들기 시작한 서버... 다 만들고 나중에 생각하려 합니다.

개인용으로 Claude Pro를 구매했고, 여전히 내 간섭은 많이 필요하지만, 최소한 주고 받으면서 내가 힌트주면 그 때 그 때, 제대로 작성하는 것 같다.

JS에서 Promise는 await으로 값을 읽는 것 외에, 현재 pending 상태를 읽는 등의 동작을 허용하지 않는다. 이거 왜 안되냐고하면 Promise의 의미론과 배경 철학이 어쩌구저쩌구하는 대답이 돌아온다. 내 생각에 그건 틀렸다. 이유는

간단한 대답: 가능하면서 왜 안해줌?

약간더 복잡한 대답

그 제약 조건은 Promise가 callback과 같은 의미의 다른 표현일때는 성립한다. callback이 전달하는 값은 특정시점 = t에 존재하는 것이다. t이후에 그 값을 사용하기위해선 따로 저장을 해놓던가해서 값의 존재시기를 >= t 로 바꾸어야한다.

그런데 Promise는 await을 여러번 하는걸 허용한다. await x; await x; 이런식으로. 값이 없으면 기다리고, 값이 한번 들어오면 그걸 계속해서 돌려준다. 여기서 Promise가 callback이랑 다른게 드러난다. 그리고 실제로 callback과 다르게 동작하기위해 값의 여부 등을 내부 상태로 갖고있을수 밖에 없다.

요약하면, callback과 완전히 상호호환될때 정당화되는 제약을 callback이 아니면서 강요하니까 문제란 얘기다.

연구원한테도 연구에 어려움은 없니? 가 아니라 네 수익률이 얼마나 되니? 묻는 나라에서 무슨 싸울 전사가 없다고 그래. 당연히 없지

https://v.daum.net/v/20250706062405889

회사 맥북 교체 안해도 될 것 같은데... 하니까 알 수 없는 이유로 RDP터미널로 쓰는데도 메모리 부족으로 전체 시스템이 죽어가면서 교체를 스스로 권한다...

맥스 가격은 그만큼 안쓸 것 같은데 프로는 꽤 탐나는 가격이다.

이제 Claude code를 써봤고, 어차피 계속 정정해야 할 것, 변경사항마다 바로 개입 가능한 점이 잘 맞다

요즘 트위터에 하스켈 관련 계정들보면 Go를 가장 싫어하는 언어로 꼽는 경우를 자주 본다. C/C++/Java 등은 역사적인 맥락을 고려해 예우해주고, Python/JS 등등의 이상한 기능은 뭘 몰라서 잘못 만들었다고 이해해주는 반면, Go는 하스켈러들이 중요하게 여기는 가치들을 일부러 다 무시하고 만들기 때문에 괘씸가중치 x10 정도를 적용받는 듯하다.

I think the @fedifyFedify: ActivityPub server framework project has now reached full maturity. What this means is that all the low-hanging fruit has been addressed, and only the difficult problems remain. 😂

...?? 오늘따라 Claude가 말을 징그럽게 안듣는 것 같은데... 하지 말라고 명시한 일 자꾸 하고, 정지명령도 안먹고

Rust 1.88.0 has been released! ✨🎊 🦀

This release brings you let chains, naked functions, automatic Cargo cache cleaning, Cell::update, proc_macro span locations, various as_chunks methods on slices, and more!

Check out the blog post and release notes for all the details: https://blog.rust-lang.org/2025/06/26/Rust-1.88.0/

[ 特許侵害で。東京地方裁判所「Pixel 7」販売禁止命令 – Jetstream ]
https://jetstream.blog/archives/200731

미국 구글이 한국 팬택의 LTE 기술 특허를 침해한 소송에서, 도쿄 법원이 팬택의 주장을 인정하고 일본 국내에서 구글 픽셀 7의 판매를 금지하는 판결을 내렸습니다.

@bglbgl gwyng 윽... 미안하다 인간이 잘 못 했다...!

Claude야. 오류나면 일단 주석 쳐서 지워버리고, 상수 그냥 다시 정의하는건 어디서 배워왔니

사용자의 실수였다고 한다. (미안해요. 구글.)

gemini-cli 이것저것 만져보는 중인데, gemini-2.5-pro 의 코드 수정능력이 생각보다 괜찮아서 좀 더 써볼 것 같다. VSCode 의 Gemini Code Assist 보다는 만족감이 더 높다. 다만 이미지 분석 용도는 아닌 것 같고. 코딩 용도로 쓰면 괜찮을 것 같다.

유닛 테스트를 짜기 위해서 유닛 테스트 인프라를 만들어야한다... 일단 손수 테스트하고 후속작업으로 하자...

오픈소스 프로젝트에 여러분의 gemini cli(등등)의 무료 사용량을 기여하세요

오픈소스 소프트웨어라는 소프트웨어 개발 방법은 그동안 대성공을 거두어 오고 있습니다. 여기에는 여러 요인이 있지만, 중요한 요인 중 하나는 이것입니다. 상업 소프트웨어든 오픈소스 소프트웨어든 공평하게 프로그래머의 시간을 들인 만큼 개발된다는 것이지요. 능력 있는 소프트웨어 개발자가 시간을 기여하면 오픈소스 소프트웨어는 상업 소프트웨어만큼이나 빠르게 성장할 수 있었습니다.

하지만 AI 프로그래밍의 시대가 빠르게 다가오고 있습니다. 앞으로 소프트웨어 개발은 프로그래머의 시간만으로 개발되지 않습니다. 상업소프트웨어는 AI 프로그래밍을 적극적으로 사용하여 이전과 다른 생산성으로 개발되기 시작할 것입니다. 상업 소프트웨어와 달리 오픈소스 소프트웨어는 언제나 그럴 수는 없습니다. 프로젝트의 성장과 유지를 위해 훌륭한 프로그래머들의 시간을 들이는 것을 넘어서, 훌륭한 프로그래머들이 시간에 더해 비용까지 들여야 한다면요.

상업 소프트웨어와 오픈소스 소프트웨어 사이의 불균등한 생산성의 시대가 코앞까지 다가오고 있습니다.

새로운 기여자 확보의 문제

문제는 여기서 그치지 않습니다. 오픈소스 프로젝트는 새 기여자를 얻기 더 힘들어져가고 있습니다. 왜냐하면 이제 'good first issue'라는 것은 의미가 없기 때문입니다. 그 정도로 쉬운 일은 새로운 기여자 대신 로봇이 해결할 가능성이 높고, 그 로봇은 새로운 기여자의 로봇일 수도 있습니다. 결국 AI 프로그래밍으로 기여하는 새 기여자는 이 프로젝트에 대해 거의 배우지 못하게 됩니다.

전통적인 오픈소스 생태계에서 'good first issue'는 단순히 쉬운 문제를 해결하는 것이 아니었습니다. 새로운 기여자가 프로젝트의 코드베이스를 이해하고, 개발 프로세스를 익히며, 커뮤니티와 소통하는 법을 배우는 학습 과정이었습니다. 하지만 AI가 이런 단순한 작업들을 대신 처리하게 되면, 새로운 기여자들은 진입 기회를 잃게 됩니다.

AI 프로그래밍의 현재 위치

AI 프로그래밍은 완벽하지 않습니다. 숙련된 전문가가 숙련된 도메인에서 작업하는 것만큼 잘하지는 못합니다. 하지만 비숙련된 프로그래머가 처음 보는 프로젝트에서 작업하는 것보다는 잘할 때가 많습니다.

그러나 많은 오픈소스 소프트웨어는 바로 이런 비숙련 기여가 성장의 한 축을 차지합니다. 처음 프로젝트에 참여하는 개발자들의 작은 기여들이 모여 거대한 프로젝트가 됩니다. 그리고 이런 비숙련 기여의 일부는 손쉽게 AI가 대체할 수 있는 기여입니다.

다행히도 지금은 AI 프로그래밍의 초창기입니다. Gemini CLI가 무료 사용량을 제공하듯이, 앞으로 여러 회사들이 비슷한 기회를 제공할 것입니다. Claude, ChatGPT, Copilot 등 다양한 AI 도구들이 개인 사용자에게 무료 크레딧을 제공하고 있습니다.

이것은 오픈소스 프로젝트에 기여할 새로운 기회로 삼을 수 있을까요?

주의: 이 글은 아무 프로젝트에나 방문해서 AI로 적당한 코드를 생성한 다음 패치를 보내라는 뜻이 아닙니다.

AI 프로그래밍은 (아직은) 마법이 아닙니다. "이 프로젝트를 겁나 멋지게 만들 기능을 추가해주세요"라고 한다고 해서 그런 패치가 나오는 식으로는 동작하지 않습니다.

이상적인 경우: AI 친화적 프로젝트

가장 좋은 방법은 프로젝트가 AI 친화적으로 준비되는 것입니다. 바로 작업할 수 있을 만큼 잘 정의된 이슈들이 있는 프로젝트라면, "nnn 번 이슈에 대해 작업해 주세요"라는 요청만으로도 누구나 기여할 수 있을 것입니다.

하지만 (적어도 아직은) 그런 프로젝트가 많지는 않을 것입니다.

현실적인 접근: AI가 잘하는 일들에 집중

대신 AI는 인간과 비대칭적으로 잘하는 기능이 있습니다.

이를테면 이슈에 minimal reproducible case가 보고되어 있지만 아직 구체적으로 발생하는 원인이 밝혀져 있지 않은 경우를 생각해봅시다. 버그를 고치는 사람이 해야하는 지루한 작업 가운데 하나는, 이 문제를 어떻게 수정할지를 생각하기에 앞서 이 문제가 어디서 발생하는지 찾는 것입니다. 디버거를 써야 할 수도 있고, 코드에 많은 trace log를 남겨야 할 수도 있습니다.

하지만 AI 코딩 에이전트는 테스트가 재현 가능하기만 하다면, 문제를 발생시키는 정확한 줄을 찾아내는 데 탁월합니다. 지치지 않고 정석적인 지루한 방법으로 꾸준히 로그를 추가하고 테스트를 다시 실행하면서 문제를 찾아내거든요.

어쩌면 문제의 원인이 아주 단순해서, 문제를 바로 수정할 수 있을지도 모릅니다! 그렇다면 패치를 제출해도 좋겠지요. 하지만 바로 수정하기까지는 어렵더라도 괜찮습니다. 버그 리포트와 실제 코드의 문제를 매핑하는 것은 그 자체로 지루하고 시간이 걸리는 일입니다. 이것을 대신하는 것으로도 큰 작업을 대신하는 것입니다.

주의: 모든 프로젝트가 AI 기여를 환영할 리는 없습니다. 충분히 유용하게 다듬어지지 못한 유형의 AI 기여는 스팸처럼 느껴질 가능성이 있음을 유의해야 합니다.

미래

사실 누구나 자기 라이브러리를 뚝딱 만들어낼 수 있게 되었다는 점에서 오픈소스 프로젝트에 참여하는 사람들의 동기와 기여 방식 자체가 크게 뒤바뀔 가능성이 높습니다.

AI 프로그래밍을 누구나 거의 무료로 사용할 수 있는 시대가 올까요? 아마 어느 정도의 사용량까지는 그럴 것입니다. 그것이 얼마나 많은 양일지에 따라서 오픈소스 프로젝트의 미래는 크게 바뀌겠지요.

만일 정말로 AI 프로그래밍을 누구나 무제한적으로 사용할 수 있다면, 대규모가 아닌 대부분의 오픈소스 프로젝트에는 더이상 협력이 필요하지 않을 것입니다. 진정으로 '어떻게'보다 '무엇을'이 더 중요한 시대가 온다면, 프로젝트의 목표를 확고하게 가진 사람이 극한의 완성도까지 프로젝트를 밀어붙이는 편이 훨씬 좋은 결과를 만들겠지요.

그런 시대가 올지 오지 않을지 모르겠습니다. 하지만 그 전까지는, AI 프로그래밍이 누구에게나 주어지는 기회이지만 프로젝트를 단숨에 완성할만큼 주어지지는 않는 시대가 유지되는 동안에는, 다음 세대의 오픈소스 기여의 방법은 AI 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.

새롭게 다시 태어난, 또 만들어버린 boilerplate. 이제는 진짜 monolithic 하고 Pocket Galaxy라는 이름에 걸맞는 boilerplate입니다.

Django + Vue(Vuetify) 조합이구요, nginx가 이것저것을 다 처리합니다.

백엔드는 /api에서 서빙하고, 기타 기본적인 static 캐싱이나 로깅 등 전부 기초적인건 제공합니다.

간단한 웹사이트 하나 만들겠다는게 어쩌다 여기까지 왔는지.... 암튼 이제는 진짜 최소한의 웹사이트 만들때 뚝딱 하면 만들수 있을것 같습니다 제발...

내부용 툴 만들때 애용해보세요.

https://github.com/theeluwin/pocket-galaxy