확실히 오라클에 1%쯤 배신감 든 게 전에 발표에서 오라클은 설정한 유저데이터 스크립트 조회도 못하게 한다라고 욕하고 왔는데 알고보니 API로는 제공하는데 콘솔엔 없었다는게 참 테라폼 사용자들만 고객이구나... 같은 느낌 (물론 저도 이젠 테라폼을 쓰지만요...)

@akastoot악하 (개인적인 억까 평가지만) 오라클은 자기네 모든 고객이 테라폼을 사용한다는 상정이라도 하고 있는 거 같으니 이번 기회에 테라폼을 사용해보시는걸 추천드려요... https://registry.terraform.io/providers/oracle/oci/latest/docs 문서 AI에 던져주면 그래도 그럭저럭 짜더라구요

Lite-XL 일주일 사용기

최근 에디터 시장이 치열합니다. Zed와 Visual Studio Code, Helix와 Neovim, 그리고 Fleet도 있습니다.

이 중 가장 주목받는건 역시 Zed와 Visual Studio Code입니다. Visual Studio Code와 가장 비슷한 UI를 보유하면서도 강력한 확장성과 정통성을 보유한 에디터로써 Zed의 입지는 공고합니다.

특히, Zed는 Rust와 GPU 렌더링을 활용한 빠른 에디터로써 Visual Studio Code의 느린 Electron 기반이라는 점을 정확히 타격하며 높은 인기를 얻고 있습니다.

이런 GPU 가속 에디터가 높은 인기를 얻고 있는 시장에서, 제 눈에 띄인 것은 바로 Lite-XL입니다. Lite-XL은 Lite라는 GPU 가속 에디터의 포크로, 많은 기능을 추가한 Vi와 Vim의 관계와 비슷합니다.

가장 특징을 가지는 부분은 코어는 Rust나 Zig가 아닌 Pure C로만 작성되어 있으며, 런타임은 Lua를 통해 작성되어 있어 모든 부분이 Lua 스크립트로 커스텀이 가능하다는 점입니다. 매우 Emacs스러운 부분이라고 할 수 있습니다.

하지만, 어느정도 Battery Included인 Emacs와는 달리 Lite-XL은 다운로드 시 오직 코드 하이라이팅과 편집 정도만 지원합니다. 모든 기능은 전부 플러그인으로 다운로드 해야 합니다. 내장 터미널조차 없고, LSP조차 없으며, Git 기능조차 없습니다.

이를 해결하기 위하여 lpm이라는 가벼운 패키지 매니저를 지원합니다. lpm은 마치 일반 리눅스의 패키지 매니저와 같아 간단한 입력만으로 플러그인을 설치할수 있습니다.

lpm install lsp_go

이렇게 플러그인을 설치한 후의 Lite-XL은 Visual Studio Code와 비견해 매우 빠르고 강력한 에디터로 발돋움합니다. Lite-XL의 실행파일 크기는 고작 10MB밖에 되지 않으며, 반응 속도 또한 매우 빨라 실행하자마자 바로 창이 렌더링 될 정도로 빠른 점도 Pure C로 매우 가볍고 빠르게 작성된 특징에서 기인합니다.

Vibe Coding을 위한 플러그인은 없지만 Claude CLI, Gemini CLI, OpenAI Codex 등을 터미널에서 실행 가능하기 때문에 로컬 환경 개발에서는 매우 빠른 속도와 바이브 코딩의 편안함도 챙길 수 있습니다.

거의 모든 기능에 단축키를 부여할수 있으며, (저는 Ctrl-S, Ctrl-Shift-O, Ctrl-Shift-P만 사용합니다.) 컬러 스킴도 Visual Studio Code에 비교해 더욱 많은 컬러 스킴을 기본 제공합니다.

다만, 가장 아쉬운 부분으로는 Remote Working이 제대로 되지 않는다는 점에서 있는데, Visual Studio Code가 code-server에 바탕한 Code Tunnel 기능을 지원하지만, Lite-XL은 이를 지원하지 못하고, 오직 네이티브 환경과 로컬 환경에서만 작업이 가능하다는 단점이 존재합니다.

또한, 많은 LSP 서버들이 존재하지 않으며, 플러그인의 자유도와 패키지 매니저는 강력하지만 절대적으로 Zed와 Visual Studio Code와 비교해서 수가 적은 것은 단점으로 꼽을 수 있습니다.

가장 대표적인 예로, 제가 PS를 할 때 애용하는 플러그인인 CPH Problem Solver와 같은 니치한 보조 도구가 부족하며, Visual Studio Code에 내장된 Stack Trace Debugger나 Docker 통합 등 많은 기능이 부재합니다.

그럼에도 가볍게 프로그래밍 한다는 점에선 Notepad++나 Sublime Editor와 비슷한 가벼움을 가지면서도, Zed나 Visual Studio Code에 꿇리지 않는 기능과 플러그인 매니지먼트 시스템을 가진다는 점에서 저는 Lite-XL을 매우 만족스럽게 사용하고 있습니다.

클로드 코드 쓰면서 처리가 가장 오래걸리는 프롬프트: /compact

#오라클클라우드 도전...

데이터베이스 공부 중 하나로 B+트리 C로 구현하고 있는데, 포인터 사용, 정렬, 재귀 호출, DFS, 이진 탐색까지 한 번에 연습하기 좋은, 학습에 아주 훌륭한 자료구조구만.

It's Christmas, but I don't really have anything to do, so I'm just coding. (I'm not Christian.)

Upyo 0.4.0 released. Upyo is an email sending library for Node.js, Deno, Bun, and edge functions. New in this version:

• JMAP transport for modern email servers
• DKIM signing support in SMTP transport
• Message-level idempotency keys for reliable retries

https://github.com/dahlia/upyo/discussions/21

TIL: <form>에 .submit()을 하면 이벤트를 거치지 않고 검증도 안하고 냅다 제출이 된다. 이벤트를 거치게 만들려면 .requestSubmit()을 해야 된다

deno install 명령어를 실행할 때 패치 패키지가 암묵적으로 npm 패키지로 덮어쓰여지는 버그를 수정하였습니다! 😊

https://github.com/denoland/deno/pull/31711

루비, 레일즈에서 페디버스를 구현하려면 https://gitlab.com/experimentslabs/federails 이 프로젝트가 구현 정도가 잘 되어 있으나 2명이서 틈틈히 개발하고 있어서 진행 상황이 느린 상태. 컨트리뷰터가 되어야 하나 포크를 해야 하나...

크리스마스는 새 프로그래밍 언어를 공개하기에 좋은 날이죠. 아직 미완성이지만 요즘 작업하고 있던 프로젝트를 소개합니다. https://github.com/Kroisse/tribute

순수 함수형이고, 모나드는 없고, 소유권도 없고, 타입클래스나 트레잇도 없습니다. 물론 객체 시스템도 없고요. 대신 제네릭과 대수적 효과를 넣을 예정입니다. ad-hoc polymorphism을 배제하고 어디까지 갈 수 있는지 시험해보려는 게 목적 중 하나인데 생각보다 할만할 것 같아요.

그리고 매우 vibe-coded되어 있습니다. Claude Code와 Codex가 없었으면 엄두도 못 냈을 듯.

문법적으로는 Rust와 Gleam에, 의미론적으로는 Gleam과 Unison에 영감을 많이 받았습니다. 사실 Gleam과 Unison 둘 다 네이티브 바이너리로 컴파일을 아직 못 하고 있어서 시작한 프로젝트이기도 합니다. 하지만 정작 Tribute도 첫 타겟은 네이티브가 아니라 WebAssembly 3.0입니다. GC 구현을 만들기 귀찮았거든요.

크리스마스를 맞아 크리스마스 트리... 가 아닌 Hackers' Pub 초대 트리를 꾸몄습니다.

기존 초대 트리는 작은 규모에서는 충분히 제 역할을 했으나 회원이 점차 늘어나면서 구조를 파악하기 어렵고, 페이지가 너무 길어져 변화가 필요하다고 생각했습니다. 다음 개편되는 Hackers' Pub의 초대 트리 페이지에서는 초대 관계를 잘 드러내면서, 많은 회원이 한 눈에 들어올 수 있도록 만들었습니다. Hackers' Pub의 회원은 앞으로도 많이 늘어날 예정이니까요. 그렇겠죠? 내년에도 Hackers' Pub에서 많은 분들을 만날 수 있기를, 더 풍성한 초대 트리를 볼 수 있기를 기대해봅니다.

Complete! It will be included in the next release of Upyo.

https://github.com/dahlia/upyo/pull/20

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang크롸상), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang크롸상) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

크리스마스에는 모두 #오라클클라우드 에 입문해보아요

(아무도 관심없겠지만) 요거의 예시로는 tree-sitter의 파싱 테이블 + AST node 메타데이터 export가 있다. 지금은 파싱 테이블 대신 parser.c만 뱉고 중요한 메타데이터를 몇개 빼먹는다. 하는 김에 rewrite in haskell도 하면 더 좋고..

좀 웃긴 생각이 났는데, '해결해주면 나랑 친해질수 잇는 문제들'이란 목록을 만들어서 공유하고 싶다. 네임드가 되면 실제로 잘 동작하려나.

Now trying to implement a JMAP transport for Upyo…

https://news.hada.io/topic?id=25285

추상화가 강력한 더 좋은 언어를 쓰는 것 이상의 확실한 방법이 없고, 그 외에는 그냥 임시방편이라고 생각함.

내 트리를 꾸며줘!

helix/kakoune는 selection 기능 정리에 힘을 줬는데, 나는 emacs의 mark식 selection이 가장 편하다. h/k는 형식을 지키기 위해서 복잡해진 감이 있음. 통일성 없는 vi보다는 낫긴 한데.

Meta, Valve의 Steam Deck용으로 설계된 Linux 스케줄러를 대규모 서버에 사용
------------------------------
- Valve의 Steam Deck를 위해 설계된 *SCX-LAVD 리눅스 스케줄러* 가 Meta의 대규모 서버 환경에서도 효과적으로 작동한다는게 공개됨
- 이 스케줄러는 *게임 콘솔 수준의 효율적 자원 관리* 를 목표로 설계된 것인데, Meta는 이를 통해 *서버 워크로드의 성능 향상* 과 *지연 시간 최소화* 를 추구
- 휴대용 게…
------------------------------
https://news.hada.io/topic?id=25293&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

iOS에서 내가 쓸 단모음 키보드 앱을 만들고 있다.

기존에 쓰던 앱들이 있긴 했는데, 하나는 어느샌가 키보드 자판 위에 툴바를 붙이더니 월 구독 결제를 안하면 숨길 수 없게 해놨고 다른 하나는 최근 iOS 업데이트 이후로 텍스트를 지울때 단어가 망가지는 문제가 생겨서 대체제를 찾다가 마음에 드는게 없어서 결국 직접 만들기로 결정함..

직접 만들어서 테스트하다보니 유저 입장에서 어떤 부분이 불편한지 - 해소해야할지 보인다. 재미는 있는데 생각보다 신경써야 할 게 많다.

(1.x, 3.x)는 모든 조건을 만족하기 때문에 변환기를 거쳐 마이그레이션할 수 있다. (1.x, 3.x-beta)도 모든 조건을 만족한다. 반면 (3.x-beta, 1.x)는 (1), (3)을 위반하기 때문에 변환기를 사용할 수 없다. (2.x-alpha.1, 3.x-alpha.0)는 (1), (2)를 위반한다. 이렇게 출발 버전부터 시작해 a ≺ b 관계를 만족하고, b가 목적 버전이 아닌 경우 안정 버전이어야 한다는 조건을 적용해 나가면 도착 버전까지의 경로도 얻을 수 있다.

그런데 실제로 이를 조건 분기로 구현해보면 상당히 복잡해진다. 더 일반화된 방법이 필요하다. 버전 관계를 다시 정의해보자. 변환기를 기준으로 생각해보면 모든 버전 사이에 순서가 있다고 할 수는 없다. 버전을 poset으로 모델링해보면 어떨까? a ≺ b 관계가 성립하는 경우에는 b의 변환기를 이용해 a를 마이그레이션할 수 있다. 이 관계가 성립하려면 (1) a가 안정 버전이고, (2) b가 알파 버전이 아니고, (3) major(a) < major(b)이어야 한다.

오랜만에 복잡한 문제를 단순한 형태로 모델링해서 해결했다. 문제 상황은 대략 라이브러리의 메이저 버전을 위해 자동 마이그레이션을 지원하는 것이다. 각 메이저 버전에는 이전 버전의 코드를 자동으로 변환해주는 변환기가 함께 배포된다. 만약 1.x에서 3.x로 업데이트할 때는 2.x 변환기, 3.x 변환기를 순차적으로 실행해야 한다. 즉, 하위 버전에서 출발해 상위 버전에 도착하는 경로를 구해야 한다.

그런데 베타 버전(x.y-beta)과 알파 버전(x.y-alpha.z)을 고려해야 한다. 베타 버전에는 직전 버전에 대한 변환기가 있고, 알파 버전에는 변환기가 없다. 나이브하게 생각해보면 출발 버전 유형과 도착 버전 유형의 조합에 대해 모든 경우를 분기해서 경로를 구할 수 있을 것처럼 보인다.

On a related note, if you learn better by building things, @fedifyFedify: ActivityPub server framework has a step-by-step tutorial where you create a federated microblog from scratch—implementing actors, inbox/outbox, following, and posts along the way:

https://fedify.dev/tutorial/microblog

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

GUI앱을 못보니까 콘솔로 출력해서 본다는 점이 정말... 나보다 낫군

According to @tchambersTim Chambers's My 2026 Open Social Web Predictions:

Fedify will power the federation layer for at least one mid-sized social platform (500K+ users) that adds ActivityPub support in 2026. The “build vs. buy” calculation for federation shifts decisively toward “just use Fedify.”

We're honored by this recognition and will keep working hard to make #ActivityPub adoption easier for everyone. Thank you, Tim!

#Fedify #fediverse #fedidev

Here's a #TypeScript API design challenge I'm working on: adding async support to #Optique (CLI argument parser) without breaking the existing sync API.

The tricky part is combinators—when you compose parsers with object() or or(), the combined parser should automatically become async if any child parser is async, but stay sync if all children are sync. This “mode propagation” needs to work at both type level and runtime.

I've prototyped two approaches and documented findings. If you've tackled similar dual-mode API designs, I'd love to hear how you approached it.

https://github.com/dahlia/optique/issues/52

목공용 절단도면 만들어주는 프로그램 뇌 비우고 Claude Code한테 시켰더니 때깔이 좋네

Stacked Diff 관리하려고 Sapling을 찍먹해봤는데, 이건 누가 hands on 세션을 하는게 아닌 이상 익숙해지는게 좀 어려울 듯.....

https://github.com/stadia/textsearch_ko 잘 쓰고 있는 pg 확장인데 너무 오래 된 것 같아 업데이트를 해봤습니다. 원본 https://github.com/i0seph/textsearch_ko

CI 실행 시간을 1/3로 줄였음

GitHub Workflows 어렵네.. 3년 동안 새로운 걸 배워보려고 하지 않은 업보가 이렇게. 즐거운 마음으로 해야 하는데 ㅎㅎ

NextJS 처음 써보는데, 챗봇 UI처럼 인터액티브한 웹앱을 만들때 도움이 되는 부분이 뭔지를 모르겠다. 처음엔 SPA + API 서버 만드는것과 비교해, 자명한 데이터 바인딩 보일러플레이트를 줄여줄거라 생각했다. 근데, 순수 SSR로 처리할 수 없는, 클라에서 상태를 업데이트하는 약간만 복잡한 플로우에서도 전혀 도움이 안된다.

일하다 막힐 때 위키피디아, 한국민족문화대백과사전, man 페이지 설명 읽는게 머리 식히는데 좋은 것 같음

정보가 부족한 에러 메시지로 인해서 약 하루를 버렸다. 정보가 부족한 것도 있지만, 믿음(?)이 부족해서 멀쩡한 곳만 잔뜩 쳐다보고 있었다.

Claude Code에 네이티브 LSP 지원 기능 추가
------------------------------
- 터미널에서 실행되는 *AI 기반 코딩 도구* 인 Claude Code 가 최신버전에서 *LSP (Language Server Protocol) 도구* 를 추가
- 이를 통해 *정의로 이동(go-to-definition)* , *참조 찾기(find references)* , *호버 시 문서 표시* 같은 *IDE 수준의 코드 인텔리전스 기능* 제공
- /terminal-setup 명…
------------------------------
https://news.hada.io/topic?id=25269&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

NextJS + Vercel AI SDK로 챗봇 UI 만들다가 수명이 줄겠네..

Jackson: Debian’s git transition

https://lwn.net/Articles/1051580/ #LWN

State of the Art가 별건가… 서령은 예술의 경지가 맞다. 입이 귀에 걸린 채로 먹고 온 것 같다. 잘 먹었습니다!!

오픈소스 프로젝트의 커뮤니티를 어떻게 운영해야 지속적으로 사람들이 참여하게 할 수 있을까..

@hongminhee洪 民憙 (Hong Minhee) 비슷한 접근이란 것만 알고 있습니다. 남은 문제를 개선하는데 어느쪽이 더 좋은 설계를 갖고있는지는 모르겠네요. 근데 Nix가 일종의 기본 레지스트리에 해당하는 nixpkgs의 규모가 더 클거 같은데, 그러면 당장 쓰기엔 수고가 덜할거 같네요.

코드 수정 제안 반영은 해당 줄을 대치하는 방식으로 처리해도 충분했는데 이제 그래프 매칭 문제로 바꿔야겠다