기본 콘텐츠로 건너뛰기

KeePassXC

원문 보기: https://dawoum.duckdns.org/wiki/KeePassXC Original article: w:KeePassXC KeePassXC 는 자유와 오픈-소스 암호 관리 기 입니다. 그것은 KeePassX (그 자체로 KeePass 의 크로스-플랫폼 포트)의 커뮤니티 포크로 시작되었습니다. [2] [3] 그것은 Qt5 라이브러리 를 사용하여 구축되어, Linux , Windows , macOS , 및 BSD 에서 실행될 수 있는 다중-플랫폼 응용 프로그램입니다. [4] [5] [6] KeePassXC는 기본적으로 KeePass 2.x (.kdbx) 암호 데이터베이스 형식을 사용합니다. [7]   그것은 역시 버전 2 및 이전 KeePass 1 (.kdb) 데이터베이스를 가져올 수 있습니다 (그리고 변환할 수 있습니다). KeePassXC는 추가 보안을 위해 키 파일과 YubiKey 챌린지-응답을 지원합니다. [2] Electronic Frontier Foundation 은 KeePassXC를 "사용하기 쉽고 강건한 소프트웨어"라고 언급합니다. [8]   KeePassXC 버전 2.7.4의 보안 검토는 2022년 말에 완료되었습니다. [9] 함께 제공되는 브라우저 확장 프로그램은 Firefox , [10] Tor-Browser, Google Chrome , [11] Vivaldi , Microsoft Edge , [12] 및 Chromium 에서 사용할 수 있습니다. [13] 확장은 데스크탑 응용 프로그램에서 브라우저 통합을 활성화함으로써 연결될 수 있습니다. [14] Installation 데비안 저장소에서 설치할 수 있습니다: sudo nala install keepassxc  
댓글 쓰기

fsck

원문 보기: https://dawoum.duckdns.org/wiki/Fsck

Original article: w:Fsck

시스템 유틸리티 fsck (file system check)는 Linux, macOS, 및 FreeBSD와 같은 유닉스와 유닉스-계열 운영 시스템에서 파일 시스템의 일관성을 검사하는 도구입니다. MS-DOS와 Microsoft Windows에서 동등한 프로그램은 CHKDSK, SFC, 및 SCANDISK입니다.

Use

일반적으로, fsck는 부팅 시 자동으로 실행되거나, 시스템 관리자에 의해 수동으로 실행됩니다. 그 명령은 디스크에 저장된 데이터 구조에서 직접 작동하며, 이는 사용 중인 특정 파일 시스템에 내부적이고 특화되어 있으므로 일반적으로 파일 시스템에 맞게 조정된 fsck 명령이 필요합니다. 다양한 fsck 구현의 정확한 행위는 다양하지만, 전형적으로 공통적인 내부 연산의 순서를 따르고 사용자에게 공통적인 명령-줄 인터페이스를 제공합니다. 현대 시스템에서, fsck는 단순히 파일 시스템의 유형을 감지하고 각 유형에 대해 특수화된 fsck.type (리눅스) 또는 fsck_type (BSD, macOS) 프로그램을 호출합니다.

대부분의 fsck 유틸리티는 손상된 파일 시스템을 대화형으로 복구 (사용자가 특정 문제를 해결하는 방법을 결정해야 함), 특정 문제를 해결하는 방법을 자동으로 결정 (사용자가 질문에 답할 필요가 없음), 또는 실제로 문제를 해결하지 않고 파일 시스템에서 해결해야 할 문제를 검토하는 옵션을 제공합니다. 원래 파일 이름을 재구성할 수 없는 부분적으로 복구된 파일은 전형적으로 파일 시스템의 루트에 저장된 "lost+found" 디렉토리로 복구됩니다.

시스템 관리자는 파일 시스템에 문제가 있다고 생각되면 fsck를 수동으로 실행할 수도 있습니다. 파일 시스템은 통상적으로 마운트 해제, 읽기 전용으로 마운트, 또는 시스템이 특수 유지 관리 모드에 있는 동안 검사됩니다.

Boot time

부팅 시간 fsck는 사용자 개입 없이 실행될 것으로 예상되므로, 일반적으로 임의의 파괴적인 연산을 수행하지 않도록 기본 설정되어 있습니다. 이는 읽기-전용 검사 (문제가 발견될 때마다 실패) 형태일 수도 있고, 더 공통적으로, "preen" -p 모드는 공통적으로 부정확한 종료 (예를 들어, 충돌, 전원 고장) 후에 발견되는 무해한 문제만 수정하는 것입니다.

ext2/3/4는 지정된 수의 마운트 후 주기적 검사를 수행할 수 있도록 부팅-시간 검사를 강제로 수행하는 옵션을 제공합니다.

일부 최신 파일 시스템은 부정확한 종료 후 부팅 시 fsck가 필요하지 않습니다. 몇 가지 예는 다음과 같습니다:

  • XFS, 하나의 저널링 파일 시스템. 그것은 아무것도 하지 않는 더미 fsck와 문제가 의심될 때 실행되는 실제 xfs_repair 도구가 있습니다.
  • UFS2, FreeBSD에서 파일 시스템, 이는 소프트 업데이트가 활성화되면 백그라운드 검사를 지연시킬 수 있습니다. 결과로써, 보통 디스크에 접근하기 전에 fsck가 완료될 때까지 기다릴 필요가 없습니다. 이 설계는 부팅 시 사용되는 -F 플래그에 반영됩니다.
  • ZFS 및 Btrfs, 두 개의 전체 복사-쓰기 파일 시스템. 그것들은 저널과 유사한 수준의 일관성을 보장하기 위해 제자리 변경을 피합니다. 그것들은 역시 더미 fsck를 제공합니다. btrfs-check는 여전히 파일 시스템 구조에서 의심되는 문제를 확인하기 위해 사용할 수 있습니다 (예를 들어, 소프트웨어 버그 또는 하드웨어 문제가 의심될 때).

파일 시스템 구조를 검사하는 것과는 독립적으로, 현대 파일 시스템은 미러 또는 체크섬에 대해 저장된 데이터에서 침묵 손상을 검사하는 데이터 스크러빙 도구를 제공할 수 있습니다. 스크러빙은 디스크의 모든 데이터를 다루기 때문에 느린 경향이 있지만, 주기적인 실행은 데이터 부패를 방어하고 고장난 드라이브를 식별하는 데 도움이 될 수 있습니다.

History

fsck는 1980년 벨 연구소 "V7 부록 테이프"에 처음 등장했습니다. 그것은 NetBSD 1.3 (1998)에서 현대 래퍼 형태로 바뀌었습니다. fsck는 임의의 기존 표준에 정의되어 있지 않지만, 원시적인 비-래퍼 형태는 X/Open로부터 1995년 초안 Systems Management: File System and Scheduling Utilities (FSSU)에 존재합니다.

As an expletive

파일 시스템 손상의 심각성으로 인해 "fsck"와 "fscked"라는 용어가 유닉스 시스템 관리자 사이에서 "fuck"과 "fucked"를 의미하는 굳은 맹세로 사용되기 시작했습니다. 이러한 사용이 원인인지 결과인지는 불분명한데, 왜냐하면 USENIX 1998에서 질의응답 세션 보고서로부터 "fsck"는 원래 다른 이름을 가졌다고 주장하기 때문입니다:

Dennis Ritchie: "따라서 fsck는 원래 다른 이름으로 불렸어요" Question: "뭐라고 불렸나요?" Dennis Ritchie: "음, 두 번째 글자가 달랐어요"

그 이야기는 2023년 12월 17일 Mastodon 소셜 네트워크에서 Rob Pike에 의해 확인되었습니다:

Ted Kowalski, 사용자 이름 frodo, 평화롭게 쉬시길 바랍니다는 원래 저자였고, Murray Hill에 있는 제 사무실 복도 바로 아래에 있었고, 프로그램 이름에 'u'가 있었는데 지금은 's'가 있습니다. 경영진은 배포를 위해 이름을 바꾸게 했지만, 발음을 바꾸게 할 수는 없었습니다.

— Rob Pike,

"직접 fsck를 해라(Go fsck yourself)"는 말은 가끔 온라인에서 어떤 사람에게 문제 (태도, 주제에 대한 무지, 등)를 바로잡으라고 명령하는 데 사용됩니다 - 이는 fsck를 실행하는 것이 근본적인 오류를 수정하는 것과 같은 방식입니다.

Examples

다음 예제는 /usr 파티션에 마운트되도록 구성된 파일 시스템을 확인합니다; 먼저 파일 시스템을 마운트 해제해야 합니다:

fsck /usr

다음 예제에서는 mdadm 소프트웨어 RAID 장치에서 Linux JFS 파일 시스템을 확인합니다:

fsck -t jfs /dev/md0

See also

 

 

라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

리눅스 한글 입력기 (Wayland 편)

원문 보기: https://dawoum.duckdns.org/wiki/한글 입력기/On_Wayland 최근 소프트웨어들의 버전 업그레이드로 인해, X11에서도 님프 입력기에서 문제들이 발생하고 있습니다. 따라서 이제는 X11이든, Wayland이든 kime을 사용하는 것이 바람직해 보입니다!! 리눅스 생태계에서 X11에서 Wayland로의 전환은 여러 가지 새로운 장점과 단점을 만들어 냅니다. 일반 사용자들은 이런 전환이 가진 장점에 열광하기도 하지만 기존에 작동하는 메커니즘이 작동하지 않을 때 더욱 불만을 표출합니다. 리눅스에서 가장 큰 문제점은 한글 입력에 있습니다. 그러나, 이 문제는 거의 한국 사람들에 국한된 문제입니다. 물론, 중국과 일본도 비슷한 처지에 있어서 CJK로 묶어서 얘기가 되지만, 한글은 다른 두 언어에 비해 더 고려할 사항이 있어서 한글 입력기 개발에 어려움이 더해진다고 알려져 있습니다. 이런 상황 아래에서, kime과 nimf는 최근에 한국에서 개발된 두 개의 한글 입력기입니다. 먼저, 개인적인 경험을 기반으로 결론부터 얘기하자면, X11에서는 nimf를 추천합니다. Wayland에서는 kime을 추천합니다. 이유는 간단하게도, X11에서는 nimf가 더 많은 프로그램에서 올바르게 동작했지만, Wayland에서는 X11에서 잘 입력되던 프로그램에서 입력이 되지 않거나 잘못 입력되는 경우가 발생합니다. 반면에 kime은 Wayland에서 nimf가 입력하지 못하는 프로그램에서 입력이 되거나 잘못 입력되던 것이 제대로 입력되는 경우가 있기 때문입니다. 예를 들어, 그놈 Wayland에서 적어도 아래의 현상이 있습니다: gnome-calendar : nimf 입력기 전환 안됨. kime 정상 작동. nimf 이 문제는 gooroom에서 제공되는 gtk4 패치를 이용해 보십시오. kakaotalk (bottles: wine) : nimf 마지막 점을 찍으면 마지막 글자 앞에 찍힘. kime 정상 작동. alac...
댓글 쓰기
자세한 내용 보기

Btrfs 압축 수준 설정

원문 보기:  https://dawoum.duckdns.org/wiki/Btrfs 보통, 마운트 옵션에서 compress=zstd를 사용할 경우에 압축 레벨 3를 사용하고, HDD와 느린 플래시 스토리지에 적합하다고 알려져 있습니다. 좀 더 빠른 SATA SSD는 압축 레벨 2가 적당하고, NVME는 압축 레벨 1이 적당하다고 합니다: Yup, this is it. On slow storage higher compression levels tend to yield higher total storage throughput because you spend less time bound by slow storage bandwidth, instead you spend CPU time compressing/decompressing that data. The rick is to pick a compression level that yields greater total throughput than storage bandwidth can accommodate on its own. This approach works well on bandwidth limited storage like HDD pools, slow flash nand, flash nand attached to the system via slow USB, etc. On the flip side you don't want to constrain high bandwidth storage by sending data through a compression algorithm that limits throughput so lower compression levels (like zstd:1 on nvme storage, or zstd:2 on fast SATA SSDs) are usually safe choices. —  seaQueue, Btrfs compress level, https://...
댓글 쓰기
자세한 내용 보기

리눅스 한글 입력기

원문 보기:  https://dawoum.duckdns.org/wiki/한글_입력기 컴퓨터에서 한글을 입력하기 위해서 한글 입력기가 필요합니다. 리눅스 배포판마다 기본으로 설치되는 입력기가 있지만, 설치 후에 바로 한글 입력이 가능한 경우는 드뭅니다. 배포판의 설치 후에, 바로 한글 입력이 가능하려면, 적어도 언어를 한국어 ( Korean )로 선택해야 합니다. 그러나, 대부분의 배포판은 설치시에 한국어 ( Korean )를 선택하더라도 별도로 설정을 해야 한글 입력이 가능합니다. 게다가, 배포판이 기본으로 제공하는 데스크탑 환경에 따라 한글 입력기 설정이 다를 수 있습니다. 아래의 입력기는 사용 당시 일부 문제점이 발견되었고, 현재 문제가 남아 있는지 확인을 하지 않았습니다. 또한, snapd와 flatpak 아래에 설치된 프로그램들도 ibus에서 한글 입력이 입력될 가능성이 있고, 나머지에서는 지원이 되지 않는 것으로 알려져 있습니다. 다른 입력기에서 입력이 되는 것처럼 보이는 것은 ibus와 해당 입력기가 동시에 동작하고 있을 가능성이 있습니다. 한글 입력기 문제들 보고 장소 한글 입력기를 사용하면서, 만날 수 있는 문제는 아래에서 볼 수 있습니다: https://github.com/korean-input/issues 이미 보고된 내용 외에도 문제가 있는 분들은 같은 장소에 내용을 기록해 둘 필요가 있습니다. kime 한글 입력기(Korean ime)를 줄여서 만든 kime은 Rust로 작성되었습니다. 아래에서 소스를 볼 수 있습니다: https://github.com/Riey/kime 개별적인 설정을 수정 또는 추가하기 위해, 패키지에서 제공된 설정 파일을 사용자 설정으로 복사할 필요가 있습니다: mkdir -p ~/.config/kime cp /usr/share/doc/kime/default_config.yaml ~/.config/kime/config.yaml 예를 들어, 한/영 전환이 기본적으로 오른쪽 Alt 로 동작하는 ...
댓글 쓰기
자세한 내용 보기