인기 번역
새로운 번역 아티클
커뮤니티의 최신 번역을 확인하세요
컨트롤 그룹, 7부: 통합을 넘어 그 너머로
리눅스 3.16의 개발자 프리뷰로 등장한 통합 계층을 평가하고, 자동 그룹 스케줄링과 대비되는 ‘하인드사이트 그룹’이라는 가상 설계를 통해 cgroups의 쟁점을 되짚는다.
1더 읽기 →
제어 그룹, 6부: 내부 들여다보기
리눅스 cgroup 핵심과 프로세스/스레드 및 cgroup 사이의 연결을 가능하게 하는 자료구조와 락킹을 코드 관점에서 살펴본다.
1더 읽기 →
제어 그룹, 5부: cgroup 계층
클래식 cgroup 계층의 구조와 선택의 문제, 네트워크 트래픽 제어 계층과의 비교, 그리고 리소스 컨트롤러 계층 분리에 따른 함의를 살펴본다.
1더 읽기 →
컨트롤 그룹, 4부: 회계(사용량 계측)에 대하여
Linux 컨트롤 그룹(cgroups)에서 자원 사용량 회계가 어떤 역할을 하며, cgroups의 설계와 구조가 회계의 요구를 어떻게 충족하는지 살펴본다.
1더 읽기 →
컨트롤 그룹, 3부: 제어를 위한 첫걸음
cgroups의 현재(Linux 3.15) 구현을 통해 제어가 어떻게 이루어지는지 살펴보고, 여러 서브시스템이 계층과 상호작용하는 방식을 비교한다.
1더 읽기 →
제어 그룹, 2부: 서로 다른 종류의 계층에 대하여
계층의 다양한 형태를 살펴보고, sysfs와 커널 소스 트리의 사례를 통해 cgroups 계층을 이해하기 위한 배경을 마련한다.
1더 읽기 →
컨트롤 그룹, 1부: 프로세스 그룹화의 역사에 대하여
Unix에서 리눅스에 이르기까지 프로세스 그룹화가 어떻게 발전해 왔는지 살펴보고, cgroups(컨트롤 그룹)를 이해하기 위한 관점과 쟁점을 정리한다.
1더 읽기 →
Typst의 진화 | Laurenz's Blog
Typst가 1.0에 이르기 전에 깨지는 변경을 어떻게 정의하고, 생태계의 고통을 줄이기 위해 패키지별 target 컴파일러 버전과 자동 마이그레이션 도구를 도입할 수 있는지에 대한 제안.
0더 읽기 →
버그는 누가 만드는가? 12만 5,000건 커널 취약점의 더 깊은 분석
12만 5,000건의 커널 취약점 데이터를 바탕으로 취약점을 누가, 언제 도입하는지와 ‘슈퍼 리뷰어’가 버그 발견 속도에 미치는 영향을 분석하고, 평균 버그 수명을 줄이기 위한 실무적 개선안을 제시한다.
1더 읽기 →
Claude가 Electron 앱인 이유: 우리는 네이티브를 잃었기 때문이다
네이티브 앱이 더 이상 웹 앱에 비해 API, 일관된 외관, OS 통합, 성능 면에서 뚜렷한 이점을 주지 못하게 된 이유를 살펴보며, 문제의 핵심은 스택이 아니라 제품에 대한 ‘돌봄’의 부재라고 주장한다.
34더 읽기 →
Smalltalk의 브라우저: 타의 추종을 불허하지만, 충분하지는 않다
40년 동안 Smalltalk 개발을 형성해 온 4분할 System Browser는 여전히 탁월한 맥락을 제공하지만, 더 큰 문제는 브라우저 자체가 아니라 이를 둘러싼 도구들이 서로 조합되지 못하는 데 있다.
0더 읽기 →
코드 리뷰는 무엇을 위한 것인가?
코드 리뷰의 목적은 버그를 잡는 데 있지 않으며, 프로세스 실패를 드러내고 팀 문화를 형성·갱신하는 사회적 활동이라는 점을 설명한다.
1더 읽기 →
Rust를 위한 거대한 비전
Rust의 효과, 부분구조적 타입, 정제 타입을 중심으로 언어가 나아갈 수 있는 발전 방향을 정리한다.
0더 읽기 →
struct를 사용했다고 해고되는 일은 없다
Rust struct는 단순하고 빠르지만, 수백 개의 NULL 가능 SQL 컬럼을 rkyv로 직렬화할 때는 Option 오버헤드가 병목이 될 수 있다. 비트맵과 (필요 시) 희소 레이아웃으로 직렬화 형식을 바꿔 행 크기와 디스크 I/O를 크게 줄인 사례를 다룬다.
2더 읽기 →
std::simd를 사용해야 하는 가장 큰 이유들
std::simd를 쓰면 컴파일 시간이 늘고, 초기 성능이 느리며, 에러 메시지가 길어지고, 코드 가독성과 휴대성에 대한 새로운 관점을 제공한다는 풍자적 이유들을 예제와 벤치마크로 보여준다.
1더 읽기 →
미래를 절대 스누즈하지 마라
폴링될 준비가 된 future가 깨어 달라고 요청했는데도 폴링되지 않아 멈춰버리는 ‘스누징’이 async Rust에서 어떻게 지연과 데드락(‘futurelock’)을 만들고, 이를 피하기 위한 패턴과 규칙, 그리고 가능한 대안을 살펴본다.
10더 읽기 →
Claude의 사이클
Don Knuth가 Claude Opus 4.6이 해결한 유향 해밀턴 사이클 분해 문제의 발견 과정과 홀수 m에 대한 구성 및 증명을 정리한 노트.
10더 읽기 →
Rust 제로 코스트 추상화 vs. SIMD
Rust의 “제로 코스트” 이터레이터가 벡터화를 조용히 막고 있어 병목이 되었던 사례를 통해, 배치 이터레이터로 SIMD 최적화를 되살려 쿼리 지연 시간을 크게 낮춘 과정을 살펴본다.
57더 읽기 →
일부 GitHub Actions 러너에서 glibc가 더 빠른 이유
겉보기엔 무관한 변경으로 벤치마크가 회귀한 것처럼 보이는 이유를 추적한 조사: GitHub Actions에서 서로 다른 CPU가 배정되며 glibc의 하드웨어 기능 탐지가 성능 변동을 만든다.
2더 읽기 →
M4 Apple Neural Engine 내부, 1부: 리버스 엔지니어링
CoreML을 우회해 M4 Apple Neural Engine에 직접 접근하기 위해 소프트웨어 스택을 역분석하고, MIL→E5 컴파일 경로와 바이너리 형식, 큐 심도, IOSurface 기반 I/O 및 전력/성능 특성을 밝혀낸 과정.
2더 읽기 →
Intel이 캐시 파티셔닝을 추가한 이유
데이터센터에서 여러 작업을 한 머신에 공존시키며 SLA를 지키기 위해 Intel의 CAT(캐시 할당 기술) 같은 격리 메커니즘이 왜 필요해졌는지, Heracles 연구를 통해 설명한다.
2더 읽기 →