Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.
Got myself something for Black Friday + Christmas… Back in 2009, I fell in love with step sequencers. But the simple hardware and web browser ones that I could afford at the time were way too limited. So I made an iPad app (Koushion, now defunct) that fit my style.
Then Ableton released the Push not long after. I couldn’t afford one but I loved the idea.
Fast forward to this year, and I’ve been too busy to make music for almost a decade. But Ableton had a sale I couldn’t resist. No regrets 😍
https://github.com/yamadashy/repomix/releases/tag/v1.10.0
Repomix가 소스코드를 압축해서 LLM 친화적인 텍스트를 뽑아주는 CLI도구인데, 이제 그걸 넘어서 Claude Code Skill도 뽑아주는 기능이 추가되었다 .....
Wenn eine ehemalige Ministerin in einer großen Zeitung schreibt: „Was wir uns künftig nicht mehr leisten können“ und dieses „Was“ sind Menschen mit Behinderung, dann ist das kein Ausrutscher, sondern ein Statement.⬇️
#Ableismus #Ableism #Inklusion #Inkluencer #Behinderung #Sozialpolitik #Disability #Menschenrechte #DisabilityJustice #Solidarität #Vielfalt #Feminismus #Medienkritik #Diskursverschiebung #Rechtsruck #Sozialabbau #Neoliberalismus
酒が入ってめちゃめちゃねむい
SQLite JSON at Full Index Speed Using Generated Columns
Link: https://www.dbpro.app/blog/sqlite-json-virtual-columns-indexing
Discussion: https://news.ycombinator.com/item?id=46243904
夜ふかししちゃってた。
そろそろ
@schwaJonathan Wight the other issue is that constraints that worked when the code was originally written don’t hold over time/branches/teams
id Software just unionized, we LOVE to SEE IT https://www.rockpapershotgun.com/id-software-devs-form-wall-to-wall-union-with-165-workers-at-doom-studio-the-latest-to-vote-in-favour
それでは寝ましょ～！
天井とバスルームと机の下と棚の中に何かいないか隅々までチェック
これは休憩に描いたちびソネット…
この衣装めっちゃ
、
#リバース1999
" 브람스는 캠브릿지 대학에서 명예 박사 학위 수여 제안을 받았지만 1. 뱃길로 영국을 가기가 무서웠고 2. 영국 명사 만나기가 부담스러웠으며 3. 호의가 너무 부담스럽고 4. 읽고 이해하는 것까지는 할 수 있었지만 아무리 그래도 영어를 자유자재로 구사할 수 없다는 이유로 캠브릿지 박사학위를 포기했다. 브람스의 친구 요아힘은 캠브릿지 박사학위를 원래 브람스랑 같이 받으려 했는데, 브람스가 오지 않아서 혼자 수여받았다." 여기도 하남자력 만만치 않구나...
리비안은 새로운 Autonomy Platform의 세부 사항과 이를 훈련하는 데 사용된 엔드 투 엔드 데이터 루프를 공유했습니다. 이 대형 운전 모델(LDM)은 대형 언어 모델(LLM)과 유사하게 훈련되지만, 레벨 4 자율 주행 능력에 도달하는 궁극적인 목표로 기본 자율성을 달성하도록 프로그래밍되어 있는 게 특징입니다. 물론 이 행사가 리비안의 미래 전략을 보여주고 투자자들을 안심 시키기 위한 것임을 명심해야합니다. 그래도 테슬라와 달리 센서퓨전 방식으로 안전한 길을 선택한 것은 잘했다고 봅니다. (4/4)
가장 흥미로운 부분은 원가 절감으로 비전 온리를 택한 테슬라와 달리 리비안은 센서 퓨전 방식의 자율 주행을 목표로 하고 있으며 3세대 자율주행 컴퓨터는 11개의 카메라와 5개의 레이더 그리고 전면 LiDAR까지 포함할 예정입니다. 이러한 방식은 각각의 센서가 가진 장점을 활용해 서로의 단점을 보완해 줄 수 있어 더 안전한 자율 주행을 달성할 수 있게 해 줍니다. 또 RAP1은 칩을 연결하고 처리 능력을 배가시킬 수 있는 저지연 인터커넥트 기술인 RivLink를 갖추고 있습니다. (3/4🧵)
우선 리비안은 테슬라처럼 자체 자율주행 하드웨어를 설계할 계획입니다. 이걸 3세대 자율주행 컴퓨터(Gen 3 Autonomy Computer)라고 부르며 안에 탑재 되는 칩을 RAP1(Rivian Autonomy Processor)라고 부릅니다. 리비안의 설명에 따르면 이 칩은 INT8 정수 연산 기준으로, 희소성 최적화가 적용되었을 때 초당 최대 1600조 번의 연산 처리 성능을 가졌으며 초당 50억 픽셀을 처리할 수 있다고 합니다. (2/4🧵)
미국의 전기차 업체인 Rivian이 미국 시간 12월 11일, 자율주행 & AI 데이 이벤트를 가지면서 몇 가지 계획을 발표했는데요. 흥미로운 부분이 있어 다뤄 보려 합니다. (1/4🧵) #Techsky #Rivian
stories.rivian.com/rivian-auton...
Rivian Autonomy & AI Day -...
Unswitching loops for fun and profit via 
@lesleyLesley Lai https://lobste.rs/s/psiboc #assembly #compilers
https://xania.org/202512/12-loop-unswitching
今年の2月頃の絵
New post: a real-world look at how Fedify uses LogTape for logging.
Covers hierarchical categories, implicit contexts for request tracing, and why “silent by default” matters for library authors.
https://hackers.pub/@hongminhee/2025/logtape-fedify-case-study
Id Software devs form "wall-to-wall" union, with 165 workers at Doom studio the latest to vote in favour - https://www.rockpapershotgun.com/id-software-devs-form-wall-to-wall-union-with-165-workers-at-doom-studio-the-latest-to-vote-in-favour #Shooter:FirstPerson #Doom:TheDarkAges #unionisation #SinglePlayer #Firstperson #idSoftware #Shooter #unions #union
렌게님 안녕하세요
I couldn't find a logging library that worked for my library, so I made one.
Here's how LogTape powers Fedify's logging—and why library authors might want a different approach than winston or Pino.
I couldn't find a logging libr...
I couldn't find a logging library that worked for my library, so I made one
When I started building Fedify, an ActivityPub server framework, I ran into a problem that surprised me: I couldn't figure out how to add logging. Not because logging is hard—there are dozens of mature logging libraries for JavaScript. The problem was that they're primarily designed for applications, not for libraries that want to stay unobtrusive. I wrote about this a few months ago, and the response was modest—some interest, some skepticism, and quite a bit of debate about whether the post was AI-generated. I'll be honest: English isn't my first language, so I use LLMs to polish my writing. But the ideas and technical content are mine. Several readers wanted to see a real-world example rather than theory. The problem: existing loggers assume you're building an app Fedify helps developers build federated social applications using the ActivityPub protocol. If you've ever worked with federation, you know debugging can be painful. When an activity fails to deliver, you need to answer questions like: Did the HTTP request actually go out? Was the signature generated correctly? Did the remote server reject it? Why? Was there a problem parsing the response? These questions span multiple subsystems: HTTP handling, cryptographic signatures, JSON-LD processing, queue management, and more. Without good logging, debugging turns into guesswork. But here's the dilemma I faced as a library author: if I add verbose logging to help with debugging, I risk annoying users who don't want their console cluttered with Fedify's internal chatter. If I stay silent, users struggle to diagnose issues. I looked at the existing options. With winston or Pino, I would have to either: Configure a logger inside Fedify (imposing my choices on users), or Ask users to pass a logger instance to Fedify (adding boilerplate) There's also debug, which is designed for this use case. But it doesn't give you structured, level-based logs that ops teams expect—and it relies on environment variables, which some runtimes like Deno restrict by default for security reasons. None of these felt right. So I built LogTape—a logging library designed from the ground up for library authors. And Fedify became its first real user. The solution: hierarchical categories with zero default output The key insight was simple: a library should be able to log without producing any output unless the application developer explicitly enables it. Fedify uses LogTape's hierarchical category system to give users fine-grained control over what they see. Here's how the categories are organized: CategoryWhat it logs["fedify"]Everything from the library["fedify", "federation", "inbox"]Incoming activities["fedify", "federation", "outbox"]Outgoing activities["fedify", "federation", "http"]HTTP requests and responses["fedify", "sig", "http"]HTTP Signature operations["fedify", "sig", "ld"]Linked Data Signature operations["fedify", "sig", "key"]Key generation and retrieval["fedify", "runtime", "docloader"]JSON-LD document loading["fedify", "webfinger", "lookup"]WebFinger resource lookups …and about a dozen more. Each category corresponds to a distinct subsystem. This means a user can configure logging like this: await configure({ sinks: { console: getConsoleSink() }, loggers: [ // Show errors from all of Fedify { category: "fedify", sinks: ["console"], lowestLevel: "error" }, // But show debug info for inbox processing specifically { category: ["fedify", "federation", "inbox"], sinks: ["console"], lowestLevel: "debug" }, ],}); When something goes wrong with incoming activities, they get detailed logs for that subsystem while keeping everything else quiet. No code changes required—just configuration. Request tracing with implicit contexts The hierarchical categories solved the filtering problem, but there was another challenge: correlating logs across async boundaries. In a federated system, a single user action might trigger a cascade of operations: fetch a remote actor, verify their signature, process the activity, fan out to followers, and so on. When something fails, you need to correlate all the log entries for that specific request. Fedify uses LogTape's implicit context feature to automatically tag every log entry with a requestId: await configure({ sinks: { file: getFileSink("fedify.jsonl", { formatter: jsonLinesFormatter }) }, loggers: [ { category: "fedify", sinks: ["file"], lowestLevel: "info" }, ], contextLocalStorage: new AsyncLocalStorage(), // Enables implicit contexts}); With this configuration, every log entry automatically includes a requestId property. When you need to debug a specific request, you can filter your logs: jq 'select(.properties.requestId == "abc-123")' fedify.jsonl And you'll see every log entry from that request—across all subsystems, all in order. No manual correlation needed. The requestId is derived from standard headers when available (X-Request-Id, Traceparent, etc.), so it integrates naturally with existing observability infrastructure. What users actually see So what does all this configuration actually mean for someone using Fedify? If a Fedify user doesn't configure LogTape at all, they see nothing. No warnings about missing configuration, no default output, and minimal performance overhead—the logging calls are essentially no-ops. For basic visibility, they can enable error-level logging for all of Fedify with three lines of configuration. When debugging a specific issue, they can enable debug-level logging for just the relevant subsystem. And if they're running in production with serious observability requirements, they can pipe structured JSON logs to their monitoring system with request correlation built in. The same library code supports all these scenarios—whether the user is running on Node.js, Deno, Bun, or edge functions, without extra polyfills or shims. The user decides what they need. Lessons learned Building Fedify with LogTape taught me a few things: Design your categories early. The hierarchical structure should reflect how users will actually want to filter logs. I organized Fedify's categories around subsystems that users might need to debug independently. Use structured logging. Properties like requestId, activityId, and actorId are far more useful than string interpolation when you need to analyze logs programmatically. Implicit contexts turned out to be more useful than I expected. Being able to correlate logs across async boundaries without passing context manually made debugging distributed operations much easier. When a user reports that activity delivery failed, I can give them a single jq command to extract everything relevant. Trust your users. Some library authors worry about exposing too much internal detail through logs. I've found the opposite—users appreciate being able to see what's happening when they need to. The key is making it opt-in. Try it yourself If you're building a library and struggling with the logging question—how much to log, how to give users control, how to avoid being noisy—I'd encourage you to look at how Fedify does it. The Fedify logging documentation explains everything in detail. And if you want to understand the philosophy behind LogTape's design, my earlier post covers that. LogTape isn't trying to replace winston or Pino for application developers who are happy with those tools. It fills a different gap: logging for libraries that want to stay out of the way until users need them. If that's what you're looking for, it might be a better fit than the usual app-centric loggers.
hackers.pub · Hackers' Pub
Link author: 
洪 民憙 (Hong Minhee)@hongminhee@hackers.pub
明日は予定が昼間ないし夜更かししちゃおっかなァ〜♡とか思ってたけど既に眠気がある おじいちゃんだ
여러분, 이거 믿어도 되는 겁니까? 지금 이 백신이 개발되면 고양이들이 서른까지 살 수 있을지도 모른다는데요? 뭔 소리인지 잘 모르겠어요ㅠㅜㅠㅜ그리고 강아지는 이런 백신 없어요?
healthist.net/en/medicine/...
Could the macrophage-derived p...
오오오 가격 협상 성공 목표치에서 쬐끔 더 얹어서 불렀는데 굳굳 근데 목표치는 걍 업계 평균이라 당연한거였음 여태 너무 낮게 받은 ㅠ 휴
塩見
RE: https://mastodon.social/@pruef_by/115656602846098063
Hab gerade den Wetterbericht für München geprüft:
Morgen (Samstag, 13.12) ist bestes Dezember-Demowetter, 6°, trocken und teilweise sogar sonnig.
🌤️
#prüf_by #prüf #pruef #tdgr #München #Muenchen #Munich #GeschwisterSchollPlatz #1312muc
PR RTAのお時間です（13分）
$30 liquid cooler, what could possibly go wrong?
睡眠チャレンジ
ちょっと、気持ち良すぎだろ
안녕하세여.
밀키웨이 아틀리에가 사용하는 서버 일정으로 토-일 넘어가는 새벽에 서버 물리적인 리부팅이 진행 예정이라고 합니다.
일본시간으로 01:40-02:00 사이라고 하니 참고 부탁드려여.
シャワー浴びるのめんどうくさいが頑張って入るか……
洪 民憙 (Hong Minhee) 
shared the below article:
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
When I started building Fedify, an ActivityPub server framework, I ran into a problem that surprised me: I couldn't figure out how to add logging.
Not because logging is hard—there are dozens of mature logging libraries for JavaScript. The problem was that they're primarily designed for applications, not for libraries that want to stay unobtrusive.
I wrote about this a few months ago, and the response was modest—some interest, some skepticism, and quite a bit of debate about whether the post was AI-generated. I'll be honest: English isn't my first language, so I use LLMs to polish my writing. But the ideas and technical content are mine.
Several readers wanted to see a real-world example rather than theory.
Fedify helps developers build federated social applications using the ActivityPub protocol. If you've ever worked with federation, you know debugging can be painful. When an activity fails to deliver, you need to answer questions like:
These questions span multiple subsystems: HTTP handling, cryptographic signatures, JSON-LD processing, queue management, and more. Without good logging, debugging turns into guesswork.
But here's the dilemma I faced as a library author: if I add verbose logging to help with debugging, I risk annoying users who don't want their console cluttered with Fedify's internal chatter. If I stay silent, users struggle to diagnose issues.
I looked at the existing options. With winston or Pino, I would have to either:
There's also debug, which is designed for this use case. But it doesn't give you structured, level-based logs that ops teams expect—and it relies on environment variables, which some runtimes like Deno restrict by default for security reasons.
None of these felt right. So I built LogTape—a logging library designed from the ground up for library authors. And Fedify became its first real user.
The key insight was simple: a library should be able to log without producing any output unless the application developer explicitly enables it.
Fedify uses LogTape's hierarchical category system to give users fine-grained control over what they see. Here's how the categories are organized:
| Category | What it logs |
|---|---|
["fedify"] |
Everything from the library |
["fedify", "federation", "inbox"] |
Incoming activities |
["fedify", "federation", "outbox"] |
Outgoing activities |
["fedify", "federation", "http"] |
HTTP requests and responses |
["fedify", "sig", "http"] |
HTTP Signature operations |
["fedify", "sig", "ld"] |
Linked Data Signature operations |
["fedify", "sig", "key"] |
Key generation and retrieval |
["fedify", "runtime", "docloader"] |
JSON-LD document loading |
["fedify", "webfinger", "lookup"] |
WebFinger resource lookups |
…and about a dozen more. Each category corresponds to a distinct subsystem.
This means a user can configure logging like this:
.jpeg?auto=webp)
Jenniferplusplus
依田芳人
await configure({
sinks: { console: getConsoleSink() },
loggers: [
// Show errors from all of Fedify
{ category: "fedify", sinks: ["console"], lowestLevel: "error" },
// But show debug info for inbox processing specifically
{ category: ["fedify", "federation", "inbox"], sinks: ["console"], lowestLevel: "debug" },
],
});When something goes wrong with incoming activities, they get detailed logs for that subsystem while keeping everything else quiet. No code changes required—just configuration.
The hierarchical categories solved the filtering problem, but there was another challenge: correlating logs across async boundaries.
In a federated system, a single user action might trigger a cascade of operations: fetch a remote actor, verify their signature, process the activity, fan out to followers, and so on. When something fails, you need to correlate all the log entries for that specific request.
Fedify uses LogTape's implicit context feature to automatically tag every log entry with a requestId:
await configure({
sinks: {
file: getFileSink("fedify.jsonl", { formatter: jsonLinesFormatter })
},
loggers: [
{ category: "fedify", sinks: ["file"], lowestLevel: "info" },
],
contextLocalStorage: new AsyncLocalStorage(), // Enables implicit contexts
});With this configuration, every log entry automatically includes a requestId property. When you need to debug a specific request, you can filter your logs:
jq 'select(.properties.requestId == "abc-123")' fedify.jsonlAnd you'll see every log entry from that request—across all subsystems, all in order. No manual correlation needed.
The requestId is derived from standard headers when available (X-Request-Id, Traceparent, etc.), so it integrates naturally with existing observability infrastructure.
So what does all this configuration actually mean for someone using Fedify?
If a Fedify user doesn't configure LogTape at all, they see nothing. No warnings about missing configuration, no default output, and minimal performance overhead—the logging calls are essentially no-ops.
For basic visibility, they can enable error-level logging for all of Fedify with three lines of configuration. When debugging a specific issue, they can enable debug-level logging for just the relevant subsystem.
And if they're running in production with serious observability requirements, they can pipe structured JSON logs to their monitoring system with request correlation built in.
The same library code supports all these scenarios—whether the user is running on Node.js, Deno, Bun, or edge functions, without extra polyfills or shims. The user decides what they need.
Building Fedify with LogTape taught me a few things:
Design your categories early. The hierarchical structure should reflect how users will actually want to filter logs. I organized Fedify's categories around subsystems that users might need to debug independently.
Use structured logging. Properties like requestId, activityId, and actorId are far more useful than string interpolation when you need to analyze logs programmatically.
Implicit contexts turned out to be more useful than I expected. Being able to correlate logs across async boundaries without passing context manually made debugging distributed operations much easier. When a user reports that activity delivery failed, I can give them a single jq command to extract everything relevant.
Trust your users. Some library authors worry about exposing too much internal detail through logs. I've found the opposite—users appreciate being able to see what's happening when they need to. The key is making it opt-in.
If you're building a library and struggling with the logging question—how much to log, how to give users control, how to avoid being noisy—I'd encourage you to look at how Fedify does it.
The Fedify logging documentation explains everything in detail. And if you want to understand the philosophy behind LogTape's design, my earlier post covers that.
LogTape isn't trying to replace winston or Pino for application developers who are happy with those tools. It fills a different gap: logging for libraries that want to stay out of the way until users need them. If that's what you're looking for, it might be a better fit than the usual app-centric loggers.
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
When I started building Fedify, an ActivityPub server framework, I ran into a problem that surprised me: I couldn't figure out how to add logging.
Not because logging is hard—there are dozens of mature logging libraries for JavaScript. The problem was that they're primarily designed for applications, not for libraries that want to stay unobtrusive.
I wrote about this a few months ago, and the response was modest—some interest, some skepticism, and quite a bit of debate about whether the post was AI-generated. I'll be honest: English isn't my first language, so I use LLMs to polish my writing. But the ideas and technical content are mine.
Several readers wanted to see a real-world example rather than theory.
Fedify helps developers build federated social applications using the ActivityPub protocol. If you've ever worked with federation, you know debugging can be painful. When an activity fails to deliver, you need to answer questions like:
These questions span multiple subsystems: HTTP handling, cryptographic signatures, JSON-LD processing, queue management, and more. Without good logging, debugging turns into guesswork.
But here's the dilemma I faced as a library author: if I add verbose logging to help with debugging, I risk annoying users who don't want their console cluttered with Fedify's internal chatter. If I stay silent, users struggle to diagnose issues.
I looked at the existing options. With winston or Pino, I would have to either:
There's also debug, which is designed for this use case. But it doesn't give you structured, level-based logs that ops teams expect—and it relies on environment variables, which some runtimes like Deno restrict by default for security reasons.
None of these felt right. So I built LogTape—a logging library designed from the ground up for library authors. And Fedify became its first real user.
The key insight was simple: a library should be able to log without producing any output unless the application developer explicitly enables it.
Fedify uses LogTape's hierarchical category system to give users fine-grained control over what they see. Here's how the categories are organized:
| Category | What it logs |
|---|---|
["fedify"] |
Everything from the library |
["fedify", "federation", "inbox"] |
Incoming activities |
["fedify", "federation", "outbox"] |
Outgoing activities |
["fedify", "federation", "http"] |
HTTP requests and responses |
["fedify", "sig", "http"] |
HTTP Signature operations |
["fedify", "sig", "ld"] |
Linked Data Signature operations |
["fedify", "sig", "key"] |
Key generation and retrieval |
["fedify", "runtime", "docloader"] |
JSON-LD document loading |
["fedify", "webfinger", "lookup"] |
WebFinger resource lookups |
…and about a dozen more. Each category corresponds to a distinct subsystem.
This means a user can configure logging like this:
ぺこん
await configure({
sinks: { console: getConsoleSink() },
loggers: [
// Show errors from all of Fedify
{ category: "fedify", sinks: ["console"], lowestLevel: "error" },
// But show debug info for inbox processing specifically
{ category: ["fedify", "federation", "inbox"], sinks: ["console"], lowestLevel: "debug" },
],
});When something goes wrong with incoming activities, they get detailed logs for that subsystem while keeping everything else quiet. No code changes required—just configuration.
The hierarchical categories solved the filtering problem, but there was another challenge: correlating logs across async boundaries.
In a federated system, a single user action might trigger a cascade of operations: fetch a remote actor, verify their signature, process the activity, fan out to followers, and so on. When something fails, you need to correlate all the log entries for that specific request.
Fedify uses LogTape's implicit context feature to automatically tag every log entry with a requestId:
await configure({
sinks: {
file: getFileSink("fedify.jsonl", { formatter: jsonLinesFormatter })
},
loggers: [
{ category: "fedify", sinks: ["file"], lowestLevel: "info" },
],
contextLocalStorage: new AsyncLocalStorage(), // Enables implicit contexts
});With this configuration, every log entry automatically includes a requestId property. When you need to debug a specific request, you can filter your logs:
jq 'select(.properties.requestId == "abc-123")' fedify.jsonlAnd you'll see every log entry from that request—across all subsystems, all in order. No manual correlation needed.
The requestId is derived from standard headers when available (X-Request-Id, Traceparent, etc.), so it integrates naturally with existing observability infrastructure.
So what does all this configuration actually mean for someone using Fedify?
If a Fedify user doesn't configure LogTape at all, they see nothing. No warnings about missing configuration, no default output, and minimal performance overhead—the logging calls are essentially no-ops.
For basic visibility, they can enable error-level logging for all of Fedify with three lines of configuration. When debugging a specific issue, they can enable debug-level logging for just the relevant subsystem.
And if they're running in production with serious observability requirements, they can pipe structured JSON logs to their monitoring system with request correlation built in.
The same library code supports all these scenarios—whether the user is running on Node.js, Deno, Bun, or edge functions, without extra polyfills or shims. The user decides what they need.
Building Fedify with LogTape taught me a few things:
Design your categories early. The hierarchical structure should reflect how users will actually want to filter logs. I organized Fedify's categories around subsystems that users might need to debug independently.
Use structured logging. Properties like requestId, activityId, and actorId are far more useful than string interpolation when you need to analyze logs programmatically.
Implicit contexts turned out to be more useful than I expected. Being able to correlate logs across async boundaries without passing context manually made debugging distributed operations much easier. When a user reports that activity delivery failed, I can give them a single jq command to extract everything relevant.
Trust your users. Some library authors worry about exposing too much internal detail through logs. I've found the opposite—users appreciate being able to see what's happening when they need to. The key is making it opt-in.
If you're building a library and struggling with the logging question—how much to log, how to give users control, how to avoid being noisy—I'd encourage you to look at how Fedify does it.
The Fedify logging documentation explains everything in detail. And if you want to understand the philosophy behind LogTape's design, my earlier post covers that.
LogTape isn't trying to replace winston or Pino for application developers who are happy with those tools. It fills a different gap: logging for libraries that want to stay out of the way until users need them. If that's what you're looking for, it might be a better fit than the usual app-centric loggers.
クリスマスプレゼント作戦会議をしていたらすっかり時間が過ぎてしまった。サンタは大変やで
BREAKING: Elf on the Shelf acquired by Palantir
Cloudforce One sees active exploitation of React2Shell, with actors targeting critical infrastructure—including nuclear fuel and uranium operations. Probing is concentrated in Taiwan, Xinjiang, Vietnam, Japan, and New Zealand.
React also disclosed two new vulnerabilities (CVE-2025-55183 and CVE-2025-55184). Cloudflare customers are protected against all three flaws.
Read the full threat brief: https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-exploitation-threat-brief/
유튜브 요즘 UI 자주 바꾸네
뱀파이어 세이비어 '릴리스' 투명수채화
오늘 이런 앱을 알게됬는데 안드로이드 전용이고 비전공자에겐 좀 어려울수있습니다만 하여간 광고를 효과적으로 잘 차단하고 사생활 보호에 유용한것 같습니다 실제로 카톡 인앱 광고는 모두 막을수 있음 ... 그리고 역시 카카오톡과 페북 메신저는 사용도 안하는데 열심히 뒤에서 돌고 있더라고요 ㅎㅎ... rethinkdns.com
Rethink | Fast, secure, config...
RE: https://hachyderm.io/@sustainoss/115707191758680464
Check out this 
@sustainoss podcast episode featuring 
@lorenipsumLoren, PSF Deputy Executive Director, and 
@BajoranEngineerdawn, former Chair of the PSF Board, to learn more about the PSF's turn down of a federal grant and how that fueled a community outpouring of support 💪🐍
RE: https://hachyderm.io/@sustainoss/115707191758680464
It’s here!
なんか今日夜にしてはみんないらっしゃるな
にぎやかや〜
職場のチャットには予約投稿機能がついてるんだけど、月曜の朝に予約投稿される俺のチャットの数が12個になってて笑った。疲れたし帰るか。
