XiNiHa's Avatar

XiNiHa

@xiniha.hackers.pub.ap.brid.gy

[bridged from https://hackers.pub/@xiniha on the fediverse by https://fed.brid.gy/ ]

3 Followers  |  1 Following  |  47 Posts  |  Joined: 26.03.2025  |  2.5005

Latest posts by xiniha.hackers.pub.ap.brid.gy on Bluesky

Fedify에 꽤 예전 버전부터 존재했던 보안 취약점(CVE-2025-54888)이 어제 저녁에 발견되어서 (Ghost 팀에서 보고해 줬다), 오늘 아침에는 각종 관련 소프트웨어에 모두 보안 패치를 적용하느라 푸닥거리를 엄청 했다.

* 일단 Fedify 1.3 버전 대부터 존재했어서, Fedify 1.3.20, 1.4.13, 1.5.5, 1.6.8, 1.7.9, 1.8.5 버전을 릴리스해야 했고…
* Hollo 0.4 버전 대부터 해당 취약점이 존재하는 Fedify 버전을 사용했어서, Hollo 0.4.12, 0.5 […]

08.08.2025 03:33 — 👍 0    🔁 2    💬 0    📌 0
Preview
Progress Report: Linux 6.16 - Asahi Linux Porting Linux to Apple Silicon

Next Asahi Linux progress report is up. We're finally below 1000 downstream patches :)

https://asahilinux.org/2025/08/progress-report-6-16/

07.08.2025 12:08 — 👍 3    🔁 3    💬 0    📌 0
Original post on hollo.social

We're thrilled to announce Fedify 1.8.1, a mega release made possible through the incredible efforts of contributors from South Korea's #OSSCA (Open Source Contribution Academy). This release marks a significant milestone in #Fedify's development, bringing major architectural changes, new […]

06.08.2025 07:50 — 👍 5    🔁 5    💬 0    📌 0
Preview
GitHub - byulmaru/kosmo Contribute to byulmaru/kosmo development by creating an account on GitHub.

Kosmo: @robin 님께서 만들고 계시는 차세대 연합우주 SNS 👀

06.08.2025 06:34 — 👍 0    🔁 6    💬 1    📌 0
네 가지 표정의 Hackers' Pub 마스코트 고양이

네 가지 표정의 Hackers' Pub 마스코트 고양이

그나저나 Hackers' Pub 마스코트 고양이에 아직 이름이 없는데, 어떤 이름을 지어 주면 좋을까요? 🤔

06.08.2025 05:08 — 👍 2    🔁 5    💬 2    📌 0

@hongminhee 해귀 한표 던져봅니다

06.08.2025 05:10 — 👍 0    🔁 1    💬 0    📌 0
Preview
Release v0.8.3 · h3js/srvx compare changes 🚀 Enhancements srvx CLI (#91, 6d9011d, 4cdd246, a30db56, 0d86c7a, 20171c2) Serve static middleware (#93) Logger middleware (#94) 📖 Documentation Updated docs (#95) 🤖 CI Enable ...

srvx에 기여했다!

https://github.com/h3js/srvx/releases/tag/v0.8.3

02.08.2025 00:51 — 👍 1    🔁 1    💬 0    📌 0

참고로 전면 개편 중인 Hackers' Pub 프런트엔드도 SolidStart 기반입니다!

30.07.2025 01:31 — 👍 1    🔁 1    💬 0    📌 0
Preview
GitHub - hackers-pub/visual-identity: Visual identity for Hackers' Pub Visual identity for Hackers' Pub. Contribute to hackers-pub/visual-identity development by creating an account on GitHub.

Hackers' Pub의 로고 디자인이 완료되었습니다! 디자인은 박은지 님(@murinono)께서 해주셨습니다.

연합우주라는 콘셉트에 맞게 고양이의 입 주변을 별 모양으로, 목 아래에도 고리(orbital ring) 모양으로 디자인했습니다. 고양이를 고른 이유는 소프트웨어 프로그래머 커뮤니티에서 다른 동물보다 유독 고양이가 사랑 받기 때문이기도 하고, 고양이가 호기심이 강하기 때문이기도 합니다.

로고 디자인은 CC-BY-SA 4.0 라이선스로 배포됩니다.

30.07.2025 04:32 — 👍 2    🔁 7    💬 0    📌 0

Solid Korea 커뮤니티 디스코드를 오픈해보았습니다! 많은 관심 부탁드려요~~~ https://discord.solid-korea.org

29.07.2025 10:12 — 👍 3    🔁 4    💬 0    📌 1

@hongminhee 아 Zod에서 영감을 받으신 거고 파라미터 파싱에 Zod를 쓰지는 않으시나보네요 😂

28.07.2025 08:59 — 👍 1    🔁 0    💬 1    📌 0

@hongminhee Standard Schema 지원 당연히 있겠죠?!

28.07.2025 06:36 — 👍 0    🔁 0    💬 1    📌 0

@hongminhee 제가 tsgo에 가장 기대하는 부분 중 하나입니다.... 😂

24.07.2025 16:25 — 👍 0    🔁 1    💬 1    📌 0
Original post on social.treehouse.systems

SMC made it just in time for the merge window! Now it's finally possible to reboot M1/M2 with an upstream kernel ;)

This also allows to enable the power gpios for e.g. wifi and allows us to upstream drivers for the power button, hardware sensors, battery status and RTC next […]

24.07.2025 10:23 — 👍 1    🔁 4    💬 0    📌 0
다음 버전의 Hackers' Pub 프런트엔드 스크린숏

다음 버전의 Hackers' Pub 프런트엔드 스크린숏

한창 개발중인 다음 버전의 Hackers' Pub입니다. 프런트엔드를 전면 개편하고 있습니다. 프레임워크도 Fresh에서 SolidStart로 아예 바꿨습니다.

24.07.2025 03:20 — 👍 1    🔁 7    💬 2    📌 0

각 enum값의 정의와 이것의 번역이 번들에 그대로 박혀들어가는 게 기분이 영 좋진 않구만

23.07.2025 12:37 — 👍 0    🔁 0    💬 0    📌 0
Preview
Relay

Hackers' Pub 전면 개편 준비하며 배우는 Relay. 배울 가치가 있는 기술 같다. 모바일 네이티브 앱 개발에도 Relay가 생겼으면.

21.07.2025 06:12 — 👍 3    🔁 2    💬 0    📌 0
Upyo 0.2.0 Release Notes We're pleased to announce the release of Upyo 0.2.0. Upyo is a cross-runtime email library that provides a unified, type-safe API for sending emails across Node.js, Deno, Bun, and edge functions. With support for multiple email providers through interchangeable transports—including SMTP, Mailgun, SendGrid, and now Amazon SES—Upyo enables seamless switching between email services without code changes. This release introduces two significant additions: Amazon SES transport support and comprehensive OpenTelemetry integration. These features expand transport options and add production-ready observability capabilities to the library. ## Amazon SES Transport Upyo now includes support for Amazon SES through the new @upyo/ses package. This transport provides AWS Signature v4 authentication with zero external dependencies, maintaining Upyo's commitment to cross-runtime compatibility. The implementation supports both AWS access key credentials and session-based authentication for temporary credentials. import { SesTransport } from "@upyo/ses"; import { createMessage } from "@upyo/core"; const transport = new SesTransport({ authentication: { type: "credentials", accessKeyId: process.env.AWS_ACCESS_KEY_ID!, secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY!, }, region: "us-east-1", }); const receipt = await transport.send(createMessage({ from: "sender@example.com", to: "recipient@example.com", subject: "Hello from SES", content: { text: "Sent via Amazon SES!" }, })); The SES transport includes regional configuration support, comprehensive IAM role integration through external credential providers, and efficient bulk sending capabilities. Like other Upyo transports, it provides the same consistent interface while leveraging Amazon's proven email infrastructure for reliable delivery at scale. Configuration sets, message tagging, and rich content features are fully supported, allowing teams to take advantage of SES's advanced tracking and analytics capabilities. The transport handles AWS authentication complexity while maintaining the simple, unified API that Upyo users expect. ## OpenTelemetry Integration The new @upyo/opentelemetry package adds comprehensive observability support to any Upyo transport through a decorator pattern. This implementation provides distributed tracing, metrics collection, and intelligent error classification without requiring changes to existing email sending code. import { createOpenTelemetryTransport } from "@upyo/opentelemetry"; import { SmtpTransport } from "@upyo/smtp"; // Wrap any existing transport with observability const transport = createOpenTelemetryTransport( new SmtpTransport({ host: "smtp.example.com" }), { serviceName: "email-service", metrics: { enabled: true }, tracing: { enabled: true }, } ); // Use exactly as before - observability is automatic await transport.send(message); The OpenTelemetry transport automatically instruments email operations with traces and metrics, tracking delivery rates, latency distributions, and categorizing failures by type. It integrates seamlessly with existing OpenTelemetry infrastructure, supporting both global providers and custom configurations for different deployment scenarios. Performance optimization features include configurable sampling rates for traces and metrics, ensuring minimal overhead in high-throughput environments. The transport provides automatic resource management through `Disposable`/`AsyncDisposable` support and includes specialized monitoring capabilities for bulk email operations, making it suitable for production workloads of any scale. ## Getting Involved We're continuously working to improve Upyo and would love to hear from the community. Whether you're trying out the new Amazon SES transport, implementing observability with OpenTelemetry, or using any of our existing transports, your feedback helps shape the library's future. If you encounter issues, have feature requests, or want to contribute, please visit our GitHub repository. We also welcome discussions about new transport implementations, documentation improvements, and integration experiences across different runtime environments.
17.07.2025 05:35 — 👍 0    🔁 0    💬 0    📌 0
ISO 3166-1 alpha-2 코드의 할당 현황이 표시되어 있는 표. AA부터 ZZ까지의 모든 경우의 수가 표 형태로 나열되어 있고, 이 중 사용 중이거나 사용 기록이 있는 코드들에 배경색으로 표기가 되어 있다.

ISO 3166-1 alpha-2 코드의 할당 현황이 표시되어 있는 표. AA부터 ZZ까지의 모든 경우의 수가 표 형태로 나열되어 있고, 이 중 사용 중이거나 사용 기록이 있는 코드들에 배경색으로 표기가 되어 있다.

이거 모든 2-letter code의 조합이 테이블 형태로 나와 있는 게 뻘하게 웃기다

14.07.2025 07:59 — 👍 1    🔁 4    💬 0    📌 0

이와 비슷하게 청개구리 스택 경로라는 것도 생각해 볼 수 있겠다. 예를 들어 Deno를 선택했으면 Fresh는 청개구리 스택 경로가 아니다. 그런데 Deno를 선택한 다음 Next.js를 선택하면 오히려 청개구리 스택 경로가 된다.



RE: https://hackers.pub/@ranolp/2025/law-of-conservation-of-niche-choices-count

11.07.2025 01:18 — 👍 0    🔁 1    💬 0    📌 0

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

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

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

10.07.2025 04:03 — 👍 0    🔁 1    💬 0    📌 0

다행히도 최신 프리뷰 릴리즈에서 수정된 것 같다

10.07.2025 01:58 — 👍 1    🔁 0    💬 0    📌 0
Preview
Controlled Tabs component doesn't work with startTransition · Issue #606 · kobaltedev/kobalte Describe the bug Applying startTransition to a controlled Tabs component doesn't apply transitions to newly rendered tab contents, resulting in the display of suspense fallbacks. To Reproduce Repro...

Kobalte 이슈를 또 하나 밟았음....... 영 맘에 안 든단 말이지 https://github.com/kobaltedev/kobalte/issues/606

09.07.2025 06:18 — 👍 0    🔁 1    💬 0    📌 0

@kodingwarrior 아 이거 Fedify package.json에 exports condition이 `import`로 되어 있어서 그런 것 같은데 @hongminhee `default`로 바꿔야 require(esm)이 돌 것 같네요 👀

09.07.2025 03:37 — 👍 0    🔁 0    💬 1    📌 0

Fresh 못 써먹겠는 많은 이유 중 하나: 가끔 빌드 결과가 Chromium 계열 브라우저에서 하이드레이션이 실패하는 형태로 나온다. 골 때리는 건 빌드 자체도 비결정적이라서 똑같은 소스 코드 그대로 다시 빌드하면 해결된다는 것…

08.07.2025 15:31 — 👍 1    🔁 1    💬 0    📌 0

@kodingwarrior Node 22부터 require(esm) 지원되는데 그걸로도 안 되나요?

09.07.2025 02:26 — 👍 0    🔁 0    💬 1    📌 0

오늘의 Zed 싱글벙글: Inlay Hint에 non-ASCII 텍스트가 있을 경우 Go to Definition하려고 커맨드 누른 채로 커서 올리면 에디터 전체 패닉 남

08.07.2025 08:01 — 👍 1    🔁 1    💬 1    📌 0

아는 친구한테 들은 얘기인데, 최근 이직한 회사에서 Python을 쓰는데 린트나 포매터 같은 것도 전혀 설정을 안 해놓고 살고 있기에 도입하자고 했더니 “그런 거 쓸 거면 Python 안 쓰죠”라는 말과 함께 제안을 거절 당했다고 한다. Python에서도 린트나 포매터는 물론이고 타입 체커까지 붙여서 살려면 살 수 있지만, 어쩐지 그런 거 신경 쓸 사람들은 최근 10년 사이에 다들 다른 언어로 넘어가 버리고 그런 거 신경 안 쓰는 사람들만 Python을 계속 쓰게 된 게 아닌가 싶은 생각이 들었다.

07.07.2025 05:43 — 👍 0    🔁 1    💬 3    📌 0
청개구리 스택 찬가 예전부터 기술 스택을 정할 때는 꼭 청개구리 같은 기술을 고르곤 했다. 2000년대 말에 Ruby로 웹 개발을 할 때에는 Rails 대신 Sinatra를 DataMapper와 함께 썼다. JavaScript 프레임워크를 쓸 때도 Prototype 대신 MooTools를 썼다. 2010년대 초반에 Python으로 웹 개발을 할 때는 Django를 안 쓰고 Werkzeug을 SQLAlchemy와 함께 썼다. 요즘에는 React와 Next.js를 안 쓰고 Solid와 SolidStart를 쓴다. 나는 요즘 이렇게 남들 쓰는 기술을 안 쓰고 꼭 삐딱하게 대안 기술만 골라서 쓰는 것을 두고 **청개구리 스택** 이라고 부르고 있다. 아마도 반댓말은 **정석 스택** 정도가 될 것이다. 청개구리 스택의 가장 큰 특징은 역시 쓰는 사람이 상대적으로 적다는 것이다. 그렇기 때문에 문제를 만날 일이 좀 더 많고, 트러블슈팅을 할 때도 다른 사람이 이미 찾은 해결책을 쓰지 못하고 직접 해결해야 할 때도 많다. 하지만 이것이 곧 그 기술, 그리고 그 기술을 너머서 그 분야에 대한 좀 더 깊은 이해를 갖추게 하는 기회가 되기도 한다. 이를테면,. Werkzeug의 추상화 수준이 높지 않아서 그 위에서 사실상 인하우스 웹 프레임워크를 만들어서 써야 했다. 물론, 이를 누군가는 삽질이라고 생각할 수 있겠지만, 그런 “삽질”이 나를 성장시킨 것도 사실이다. Stack Overflow에 답이 없을 때, 소스 코드를 직접 읽어야 했고, 그 과정에서 HTTP 프로토콜의 세세한 부분까지 이해하게 되었다. 그리고 그 기술이 오픈 소스라면, 실제로 그 기술에 기여할 기회도 많이 얻는다. 내가 제출한 풀 리퀘스트가 머지되는 순간의 희열은 정석 스택에서는 느끼기 힘든 것이다. 청개구리 스택의 또 다른 특징은 대체로 후발주자라는 것이다. 즉, 정석 스택에서 불만스러운 부분을 인식한 사람들이 참지 못하고 만든 경우가 많다. 그렇다 보니 대안적인 설계를 하게 된다. Solid가 React의 가상 DOM 오버헤드를 피하기 위해 정밀한 반응성(fine-grained reactivity)을 구현한 것처럼 말이다. 그리고 항상 그런 건 아니지만, 그러한 대안적인 설계가 정석 스택의 설계보다 더 나을 때도 많다. 정석 스택의 잘못된 선택들을 보고 배운 다음 그것들을 피해서 만드는 경우가 많기 때문이다. 이로 인해 청개구리 스택을 선택한 사람은 정석 스택을 선택한 사람보다 그 분야에 대해 조금 더 나은 이해, 좀 더 정돈된 이해를 갖출 기회가 더 많다. 한편, 정석 스택은 많은 경우 종합 선물 세트의 형태를 갖는 경우가 많다. Rails의 “설정보다 관행”(convention over configuration), Django의 “배터리 포함”(batteries included), Next.js의 풀 스택 솔루션을 생각해 보면 내부적으로는 여러 기술들을 품고 있더라도 사용자 입장에서는 그 경계를 느끼지 못할 만큼 잘 통합되어 있는 편이다. 반면 청개구리 스택은 많은 경우 여러 부품을 사용자가 직접 고른 다음 조립까지 해야 하는 경우가 많은데, 이 과정에서 시간이 많이 들긴 하지만 각 부품에 대해 최선을 고를 수 있다는 장점과 함께, 조립하는 과정에서도 각 기술에 대해 좀 더 깊게 이해할 기회가 된다. 이 조립 과정은 때로는 지난하다. Sinatra + DataMapper + Haml + Sass를 조합하면서 각각의 설정을 맞추고, 미들웨어를 연결하고, 오류를 디버깅하는 시간. 하지만 이 과정에서 나는 웹 프레임워크가 실제로 어떻게 작동하는지, 각 계층이 어떻게 연결되는지를 더 깊게 이해하게 되었다. 그리고 그 이해는 나중에 어떤 스택을 쓰든 큰 자산이 되었다. 그러나 한 가지 명심해야 할 것은, 오늘의 정석 스택도 과거에는 청개구리 스택으로 시작했을 수 있으며, 오늘의 청개구리 스택도 미래에는 정석 스택이 될 수 있다는 점이다. Ruby on Rails도 처음에는 Java 웹 개발의 대안으로 부상했고, React도 Backbone.js 같은 과거의 MVC 웹 프런트엔드 프레임워크의 대안으로 주목 받지 않았던가? 즉, 각 기술이 중요하다기 보다는 언제나 새로운 대안에 눈길을 주는 호기심과 기술적인 의사 결정을 할 때 기술 선택의 근거를 그저 대중의 선택에 위임하는 것이 아니라 직접 주체적으로 판단한다는 것이 중요하다고 생각한다. 학습과 추론이 분리되어 있는 LLM의 한계 탓에 앞으로 정석 스택은 더욱 더 정석이 되고, 청개구리 스택의 불리함은 커질 것이다. Claude Code는 Next.js 코드는 술술 짜주지만 SolidStart 코드는 헤맨다. 그럼에도 불구하고 청개구리 스택만이 줄 수 있는 배움의 기회는 여전할 것이라고 생각한다. LLM 시대에도 나는 계속 청개구리의 길을 걸을 것이다. 왜냐하면 청개구리 스택이 주는 배움의 기회는 단순한 지식 습득을 넘어서, 기술에 대한 좀 더 깊은 이해를 함양하기 때문이다. 그러니 이 글을 읽는 여러분도, 가끔은 Stack Overflow에 답이 없는 길을 걸어보길 권한다. 그 끝에서 만나는 깨달음은 온전히 자신의 것이 될 것이다. *[LLM]: large language model
06.07.2025 06:22 — 👍 3    🔁 6    💬 0    📌 2

* 솔리드 지원 넣기
* 스토어 구현 alien-signals 기반으로 교체하기
* TOE 지원 넣기
* 페이지네이션 지원 넣기
* 기타등등 까보면 할거 훨씬 많을듯

03.07.2025 18:41 — 👍 1    🔁 1    💬 0    📌 0

@xiniha.hackers.pub.ap.brid.gy is following 1 prominent accounts