▲

Debian 13 "Trixie" 출시

 (debian.org)
2P by GN⁺ 3일전 | ★ favorite | 댓글 4개
  • Debian 프로젝트는 약 2년 1개월 30일의 개발 끝에 새로운 안정 버전 Debian 13 "Trixie" 를 선보임
  • GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0, Xfce 4.20 등 여러 데스크탑 환경을 기본 지원함
  • 14,100개 이상의 신규 패키지가 추가되어 총 패키지 수 69,830개, 8,840개 패키지가 노후화로 제거됨
  • 44,326 패키지의 업데이트 및 대규모 코드 기반 정비가 이루어졌으며, 전체 디스크 사용량은 403GB, 코드 라인 수는 14억에 달함
  • 지원 아키텍처: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x
    • 공식적으로 riscv64 지원이 최초 도입
    • i386 지원 중단 결정: 공식 커널 및 설치 도구 미제공, 64비트 CPU에서 제한적 사용만 가능함
    • armel 아키텍처는 이번 릴리스가 마지막 지원임
  • i386 외 모든 아키텍처에서 64비트 time_t ABI를 적용, 2038년 이후의 날짜도 지원함

  • 소프트웨어 및 개발 도구

    • 전체 패키지의 63% 이상이 업데이트되어 제공됨
    • 대표 소프트웨어 및 개발 툴: Apache 2.4.64, Bash 5.2.37, BIND 9.20, curl/libcurl 8.14.1, Emacs 30.1, GNU Compiler Collection 14.2, GIMP 3.0.4, LibreOffice 25.2, Linux kernel 6.12 LTS, LLVM/Clang 19, Python 3.13, Rustc 1.85, Systemd 257, Vim 9.1 등
    • arch, 서버, 데스크탑, 클러스터, 데이터베이스, 웹 및 스토리지 서버 등 다양한 용도에 적합
    • 자동 설치 및 업그레이드 테스트 등 품질 보증 프로세스가 강화

  • 클라우드 및 라이브 설치 지원

    • Amazon EC2, Microsoft Azure, OpenStack, PlainVM, NoCloud 등 클라우드 서비스용 이미지 제공
    • 클라우드 이미지는 cloud-init 자동화와 빠른 인스턴스 부팅을 위한 커널/부트로더 최적화가 반영됨
    • 라이브 이미지는 amd64, arm64용으로 DVD, USB, 네트워크 부팅 형태로 제공
    • 라이브 이미지는 여러 데스크탑 환경을 선택해 경험 가능하며, GUI 없는 표준 이미지도 사용 가능
    • Calamares 및 표준 Debian Installer로 설치 가능, HTTP Boot 지원 등 다양한 설치 방식 활용 가능
▲
zihado 14시간전  [-]

irc debian 채널에 계시던 분들 건강하신지 모르겠네요. debian potato 시절에 irc에서 많이 놀았는데.. ㅎㅎ

답변달기
▲
dongjinahn 19시간전  [-]

저도 램512MB짜리 $2.5/month VPS에 우분투 쓰다가 데비안으로 넘어갔는데 좋아요. 우분투를 쓰다 넘어갔으니 당연히 익숙하고, 메모리도 적게 먹더라고요

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 지금 이 글을 Debian 시스템에서 작성 중임, 개인적으로 데일리 드라이버로 정말 만족하며 사용 중임. Ubuntu가 예전보다 많이 나빠진 이후 Debian 6으로 갈아탔는데 후회한 적이 없음. Debian이 이념과 실용성 모두에 있어 균형 잡힌 점, 기본적으로는 자유 소프트웨어를 추구하되 필요하다면 non-free 소프트웨어나 펌웨어 설치도 쉽게 해두었다는 점, 패키지 가이드라인과 dpkg, 그리고 아주 탄탄한 문서화도 마음에 듦(문서는 Arch가 최고긴 하지만). stable/testing 패키지 스트림이 있어서 구버전의 안정성이나 더 최신의 거의 안정적인 것 중에 고를 수 있는 것도 좋음. 무엇보다 내가 실수하지 않는 이상 Debian 자체 결함으로 시스템이 고장나본 적이 단 한 번도 없음. 심각하게 부팅이 안 되거나 문제가 생긴 적이 있었는데, 그때마다 서드파티 저장소를 추가한다든지 직접 설정을 잘못 만졌던 게 원인이었음

    • Debian이 훌륭한 건 맞지만, 시스템이 내가 잘못하기 전까지는 절대 깨지지 않는다는 경험을 나도 공유하긴 어려움. 특히 Debian stable에서 커널에 패치가 많이 적용되어 있는데, 빠르게 변하는 DRM 서브시스템 쪽에 backport 과정에서 문제가 생겨 디버깅하기 힘든 크래시를 여러 번 겪었음. 명목상 커널 버전은 발표 기간 내내 같지만, 실제로는 Ubuntu처럼 꾸준히 최신 커널(hwe 계열)을 사용하는 게 이런 패치 스트레스가 적음. 그래서 나는 VM엔 Debian을 쓰고 베어메탈에는 Ubuntu를 씀. debian-backports repo에서 커널을 써보진 않았음

    • 나도 Ubuntu Server 쓸 때 업그레이드 이슈로 고생 많이 해서 버림. 75개 넘는 VPS를 운영하는데, 유지보수 업데이트할 때마다 부팅 불능이 되는 경우가 나올까봐 걱정되는 경험이 많았음. 그런 장애 복구만 VPS 당 1~2시간씩 추가로 걸림. 2015년쯤 8.x 시절부터 Debian으로 넘어온 뒤로는 훨씬 안정적임. 내가 뭔가 잘못 만지지 않는 이상 깨진 적이 없음

    • Ubuntu가 많이 나빠졌다는 게 어느 부분에서 그렇게 느꼈는지 궁금함

    • Debian의 유일한 단점이라면, 새로운 서버 소프트웨어를 설치하자마자 바로 실행을 시도한다는 점임. 대부분 기본 설정이 안전하긴 하지만, 아직 내가 설정하기 전인데 서비스가 뜨는 게 좀 무서움. Red Hat은 설치만 하고 내가 직접 켜기 전까지 서비스가 안 뜨는 방식이라 그 부분이 더 맘에 듦

    • Debian은 내 서버 운영의 기반임. 서버들은 Old Stable로 두고, 새로운 릴리즈 기능들은 임시 시스템에 테스트함. Bookworm에서 nftables를 배웠고, Trixie에서 labwc를 써봄. labwc는 Wayland를 지원하면서도 Openbox 스타일 설정이 가능함

  • Debian 커뮤니티 자원봉사자분들께 감사한 마음임. Debian과 Debian을 기반으로 한 수많은 프로젝트가 가능해진 건 모두 여러분 덕분임. 정말 많은 사람들과 기업들이 여러분의 노력으로부터 이익을 얻고 있음. 내 개인적인 얘기로는, 이번 Trixie 릴리즈가 특히 신남. 내 사이드 프로젝트인 ntfy가 패키지로 포함되어 Trixie에 들어감. 단, 릴리즈 주기 후반에야 ntfy 패키저가 라이선스 관련 질의를 하면서 알게 됐는데, Debian 패키지에선 웹 앱이 빠졌고, 몇몇 기능이 패치로 제거됨. Stripe, Firebase, WebPush 등을 빼기 쉽게 build tags도 추가했으니, 다음 Debian 릴리즈에서는 패치가 더 적어질 것이라 기대함. 업스트림 메인테이너 입장에서 보면, 왜 웹 앱이 빠졌는지 명확한 안내가 없어 아쉬움. 일부러 제거한 건 알겠는데, 다음 릴리즈엔 넣으려면 어떻게 하면 되는지 잘 모르겠음. apt install ntfy 했는데 웹 앱이 안 된다면 많은 유저가 실망할 듯함. 조언이나 가이드 환영임. 소스 코드도 참고할 수 있음

    • 패키지 메인테이너가 관련 설명을 덧붙여둠. 웹앱이 nodejs 기반이고, 해당 nodejs 패키지들이 Debian에 없음. Debian 철학상 패키지에 의존성 소스를 직접 포함하는 걸 지양함. 그렇게 하려면 의존 패키지도 직접 만들고 관리해야 해서 부담이 컸던 듯함

    • Debian의 npm 패키지 빌드는 반드시 빌드가 가능해야 함. 그래서 별도의 debian-specific package.json에서 npm 의존성을 Debian 패키지로 바꾸거나, 포팅하거나, 아니면 별도 패키지로 제공해야 함. 잠재적으로 상당히 많은 작업량임. lockfile이 큰 경우엔 정말 손이 많이 감. 아마 메인테이너가 이정도 분량은 부담스럽다고 생각했을 듯함. Debian식으로는 ntfy-web 같은 별도 패키지로 제공하는 게 더 자연스러워 보임

    • ntfy 덕분에 감사한 마음임. 집에서 Meshtastic 노드에서 이벤트 알림 받을 때 매일 씀

    • ntfy 소프트웨어 정말 잘 쓰고 있음

    • 의존성 문제를 해결하고 싶다면 컨테이너 이미지로 배포하는 게 더 좋은 방법일 수 있음

  • Debian은 내 자유로운 컴퓨팅 인생의 안정적인 기반임. Condorcet 투표 방식에서 배운 점, 절차적 합의, 원칙 기반 의사결정 등에서 많은 영향을 받음. 이 프로젝트와 그 문화가 세상에 끼친 영향은 정말 측량할 수 없을 만큼 큼. 사랑을 담아 축하함

  • i386 아키텍처가 드디어 일반 지원이 끝났다는 내용(최신 커널이나 설치 프로그램이 없음, 64비트 CPU에서만 사용 권장, 순수 32비트 하드웨어는 더 이상 업그레이드 비권장). 2025년 8월까지 i386 지원이 이어졌다는 게 대단함. 난 아직도 Pentium 3 기반 하드웨어에서 Debian 10 Buster를 돌리고 있었음(2024년 6월 EOL). 구형 하드웨어에서 써볼 수 있어 지원이 오래간 게 고마움. 혹시라도 i386 으로 최신 OS를 원하는 분은 OpenBSD도 고려할 만함

    • 난 2007년쯤 Pentium 3 쓴 게 마지막인 줄 알았는데, 지금은 단돈 $1에 성능이 100배 빠른 PC도 구할 수 있는 시대임

    • i386이 최신 Debian ports 인프라(예: m68k)가 있는 쪽으로 넘어가면 Debian 14나 15에서도 계속 실험적으로 쓸 수 있을 거라 기대함

    • old stable은 약 1년 정도 추가 지원되는 걸로 기억함. 즉, 2025년 이후에도 완전히 끝은 아님

    • 이건 Debian 지원에 대한 이야기임. 실제로 리눅스 커널 자체는 오리지널 Pentium 이후의 32비트 CPU까진 계속 지원함 (일부 클론 칩셋 제외)

    • "386"하고 32bit를 혼동한 거 아님? 보통 686이 일반적인 32bit 아키텍처고, 386은 1980년대 이야기임

  • sysvinit도 여전히 사용 가능함. 이미 서버/데스크톱에서 테스트함. 특정 패키지의 의존성 문제로 인해 아래와 같은 명령으로 동시에 제거/설치를 병행하면 문제를 피해갈 수 있음. 관련 Debian 버그에 따르면 systemd-sysv 및 systemd에 "-"를 붙여서 제거하는 게 핵심임. 이 방식으로 debootstrap으로 만드는 sysvinit 빌드는 bookworm 때와 거의 동일함(데스크톱 포함). bookworm이나 buster 쓸 때처럼 apt preferences에서 libsystemd0만 유지하고 나머지 systemd 패키지를 priority -1로 막으면 됨

    • 정말 debian 13에서도 sysvinit이 제대로 동작하는지 궁금함. 즉, systemd를 빼고도 sysvinit으로 서버가 운용이 가능한지 묻고 싶음

    • 정보 공유에 감사함. 최소한 lxc 컨테이너에서는 적용해 볼 생각임

    • 굳이 이렇게까지 하는 이유가 궁금함

  • x86-64용 .torrent 이미지가 어디있는지 찾기 힘들 수 있어 링크를 정리함
    Minimal: netinstall ISO
    Full: DVD ISO

    • 대부분의 유저는 DVD(full) 이미지가 필요 없음. 설치 시 패키지를 다운로드하는 minimal netinstall CD만으로 충분함

  • trixie에서 공식적으로 지원하는 7개 아키텍처를 정리함

    • amd64(64-bit PC)
    • arm64
    • armel(ARM EABI)
    • armhf(ARMv7 EABI hard-float)
    • ppc64el(64-bit little-endian PowerPC)
    • riscv64(64-bit little-endian RISC-V)
    • s390x(IBM System z)
      RISC-V가 실제로 쓸만한 하드웨어는 별로 없지만 드디어 1류 플랫폼 취급을 받는 게 반가움. 요즘 PowerPC나 System z는 어디에 쓰이고 있는지, amd64/arm64/riscv64 이외에 다른 아키텍처가 실제 배포되는 곳이 궁금함

    • Power와 z는 지금도 수십억 달러짜리 비즈니스임. 두 아키텍처 모두 금융권이나 은행에서 많이 씀. IBM은 z에 대해선 여전히 자부심이 있지만, Power는 요즘 단순히 유지만 되는 느낌이라 아쉬움. Power는 아키텍처도 시스템도 참 잘 만들어져 있음

    • 메인프레임은 서버 한 대로 수십 년간 중단 없이 서비스해야 하는 용도에서 자리 잡고 있음. 심지어 프로세서, 메모리 같은 부품도 hot-swap(운영 중 교체 가능)이 되고, OS 서비스와 별개로 하드웨어 상시 모니터링/진단도 가능함. 하드웨어 문제가 탐지되면 자동으로 소유주와 IBM에 알림이 감. IBM은 2000년대 초부터 메인프레임에서 Linux를 1급 OS로 지원함. 개발자 입장에서는 s390x가 마지막으로 남은 빅엔디안 아키텍처라(아직 SPARC가 있긴 하지만 사실상 유지보수 모드고, Oracle만 Solaris로 신경 쓰는 중), 엔디안 버그 잡기에도 유용함. 현재 남은 32비트 아키텍처는 armel, armhf 두 개뿐이고, 이번 릴리즈가 armel 지원의 마지막임(참고). 머지 않아 공식 32비트 지원도 종료될 듯함

    • IBM은 이 두 아키텍처가 주요 배포판에서 계속 잘 동작하게 만드는 데 꽤 많은 노력을 들이고 있음. 그래서 다른 아키텍처와 달리 생태계에서 자연 발생적으로 유지된다기 보다는, IBM의 지원 덕분에 계속 포함되는 느낌임

  • systemd에서 NIC 이름 관리 이슈가 걱정된다면, 릴리즈 노트(링크)를 참고하면 됨. udevadm 명령으로 업그레이드 후 인터페이스 이름이 어떻게 변경될지 미리 확인 가능함. bond/lo 인터페이스를 뺀 나머지 목록도 아래 one-liner로 확인 가능함. 지금까지 직접 테스트해봤을 때에는, 실제로 업그레이드 때문에 인터페이스 이름이 바뀐 적은 없었음. 그래서 위 방법이 진짜 이름 변화를 미리 잡을 수 있는지는 자신 없음

    • 아마도 마지막으로 인터페이스 네이밍 관련 큰 변화일 듯함. enoX 표기는 항상 안정적으로 유지되어야 하는데, 이는 BIOS(ACPI 테이블 등)에서 어떤 포트가 어떤 ID인지 알려주기 때문임. ensX 방식은 PCIe 슬롯 기준이긴 한데, PCIe 트리 구조에 따라 한 슬롯에 여러 NIC가 생길 수도 있어서 복잡함. 시스템드가 이런 예외 케이스를 해결하기 위해 인터페이스 네이밍 로직을 여러 번 바꿔왔음. 예전에 PCIe 슬롯 번호를 간접적으로 읽어서 충돌 난 적도 있었는데, 이건 systemd 257에서 수정됨

    • 업그레이드 전에 systemd의 Predictable Network Interface Names를 미리 꺼둔 경우에도 인터페이스 이름이 변할 수 있는지 궁금함

  • slink 때부터 Debian을 써왔음. 지금도 apt-get ...을 꼭 입력하게 되는데 여전히 여차저차 잘 돌아감. 25년 넘게 업그레이드 중 크고 작은 문제가 있었지만, 그로 인한 시간/노력은 다른 리눅스나 비공개 소프트웨어와 비교하면 정말 별것 아니었음. 한 가지 아쉬움은 커뮤니티 기여를 좀 더 하지 않은 것임. Debian의 가장 큰 장점은 사용자가 시스템 동작을 최소한 어느 정도는 이해해야 쓸 수 있다는 점임. 그 덕분에 "최대한 단순하지만 지나치게 단순하지 않은" 철학을 잘 지키고 있다고 생각함

  • Debian의 대표적인 장점은 stable에서 stable로 15분 이하에 업그레이드가 가능한 점임. 내 첫 시스템은 패키지 다운로드와 리부트까지 10분도 안 걸려 마이그레이션 완료함. 특별히 성능 좋은 컴퓨터도 아니고, 네트워크도 50Mbps짜리 mini PC임

답변달기