기본 콘텐츠로 건너뛰기

좌표축에 접하는 원의 방정식

원문 보기:  https://dawoum.duckdns.org/wiki/좌표축에_접하는_원의_방정식 원의 방정식 에서 일반형과 표준형에 대해 알아보았습니다. 어떤 조건으로부터 원의 방정식을 만들 때에는 주로 표준형을 사용하며, 일반형은 원이 지나는 세 점이 주어진 경우에 사용합니다. 여기서는 축에 접하는 경우에 원의 방정식의 표준형이 어떻게 달라지는지 알아보고자 합니다. x 축에 접하는 원 오른쪽 그림은 원이 \(x\)축의 위쪽에서 \(x\)축에 접하는 경우의 그림을 보여줍니다. 여기서 반지름의 길이는 중심의 \(y\)좌표인 \(b\)의 값과 동일합니다. \(\quad\)\(b=r\Rightarrow r^2=b^2\) 반면 원이 x축의 아래쪽에서 \(x\)축에 접하는 경우에는 원의 중심의 \(y\)좌표가 음의 값을 갖기 때문에 부호를 반대로 바꾸어 주어야 반지름의 길이와 동일해집니다. \(\quad\)\(-b=r\Rightarrow r^2=b^2\) 그러나, 표준형의 원의 방정식에서는 \(r^2\)을 사용할 것이기 때문에 어느 쪽에 접할지 확인할 필요는 없습니다. 그러므로, \(x\)축에 접하는 표준형의 원의 방정식은 다음과 같이 정할 수 있습니다. \(\quad\)\((x-a)^2+(y-b)^2=b^2\) y 축에 접하는 원 오른쪽 그림처럼 \(y\)축에 접할 경우에는 \(x\)축에 접할 때와는 반대로 중심의 \(x\)좌표가 반지름과 관련이 있습니다. \(x\)축때와 같은 방법을 통해서, \(y\)축에 접할 때 표준형의 원의 방정식은 다음과 같이 정할 수 있습니다. \(\quad\)\((x-a)^2+(y-b)^2=a^2\) x , y 축에 동시에 접하는 원 양축에 동시에 접하는 경우에는 \(|a|=|b|=r\)과 동일합니다. 그렇기 때문에 다음과 같이 어떤 것을 선택해도 상관이 없습니다. \(\quad\)\(r^2=a^2=b^2\) 1,3 사분면 한편 중심의 좌표는 부호를 정해야 합니다. 1,3 사분면은 중심의 \(x,y\)의 좌표가 동일합니...

CachyOS

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


CachyOS는 아치 리눅스를 기반으로 하는 리눅스 배포판입니다. 그것은 속도와 보안 최적화에 중점을 둡니다 - 기본 리눅스 커널은 BORE(Burst-Oriented Response Enhancer) 스케줄러를 사용하여 크게 최적화되는 반면, 데스크탑 패키지는 LTO 및 x86-64-v3 최적화, 보안 플래그 및 성능 개선으로 컴파일됩니다. 사용 가능한 데스크탑 환경과 창 관리자에는 KDE Plasma, GNOME, Xfce, i3, bspwm, LXQt, Openbox, Wayfire, 및 Cutefish가 포함됩니다. CachyOS는 역시 그래픽 및 명령줄 설치 프로그램과 함께 제공되며 일부 보안 강화 및 성능 최적화 기능을 갖춘 파이어폭스 기반 브라우저 (Cachy-Browser라고 함)를 제공합니다.

Introduction

2025년 3월 기준, 디스트로와치의 경향을 보면, 그 동안 부동의 1위를 차지했든 MX LinuxLinux Mint에게 자리를 내주면서 2위로 밀리고 점점 인기가 식고 있습니다.

다른 한편, CachyOS의 약진이 두드러집니다.

추정컨데, 과거에 MX Linux의 최적화가 낮은 성능의 컴퓨터에서 꽤 괜찮은 반응 속도를 보임으로써 높은 인기를 누렸지만, 그 자리를 CachyOS에게 내주고 있는 것으로 보입니다:

하지만, 최근의 빠른 컴퓨터에서는 크게 차이를 느끼지 못할 수 있고, 안정성에 문제가 있을 수 있습니다 (특히, 가상 기계 아래에서 문제를 발견할 수 있습니다)

Installation

아치를 기반으로 하고, 독일에서 개발되기 시작했습니다.

매체 얻기

홈페이지 다운로드 지면에서 구할 수 있습니다. 이전에는 KDE Plasma, GNOME ,Xfce에 대한 iso 이미지를 제공했고, GNOME-231210.iso를 사용했을 때, 설치 자체에 문제가 있어 테스트가 더 이상 진행되지 못했습니다.

2025년 3월 기준, 설치 이미지는 KDE Plasma만을 제공하며, 사용된 이미지는 250202.iso입니다.

QEMU/KVM

아치 리눅스 기반으로 만듭니다:

  • Memory : 4G
  • CPU : 4
  • HDD : 30G

설치시작

그럽 기본 옵션으로 부팅한 후, Hello 화면에서, 아래쪽 중앙에 있는 Launch Installer를 누릅니다. 설치 프로그램은 Calamares (software)을 수정한 것입니다. 위치를 확인하는지 설치 화면에서 한글을 볼 수 있습니다.

  • Welcome : American English
  • Location : Asia/Seoul (자동 검색함)
  • Keyboard : Korean/Default
  • Partitions : Erase disk (기본값: btrfs)
  • Desktop : GNOME
  • Packages : CachyOS Packages에서 fish-config, zsh-config 제거, 이전 설치에서 다른 배포판과 다르게 설정함.
  • Users :
  • Summary :
  • Install :
  • Finish : Restart

Configurations

화면 글꼴이 작아서 scale factor 1.2로 적용했습니다.

  • sudo pacman -S yay
  • yay -Syu
  • yay -S ghostty
  • yay -S zen-browser-bin
  • yay -S ibus-hangul
  • yay -S starship
  • yay -S zsh (Z shell 설정)

Troubleshootings

Epiphany Segfault

데스크탑 파일에서 반응이 없어 명령-줄에서 실행해 보니, 오류가 발생하고, 아직 해결되지 않았습니다.


댓글

이 블로그의 인기 게시물

리눅스 한글 입력기 (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 마지막 점을 찍으면 마지막 글자 앞에 찍힘. ...

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/원리합계 등비급수 는 대표적으로 닮은 도형의 합을 구하는 것과 원리합계가 있습니다. 닮은 도형의 합은 무한등비급수에서 자세히 설명될 것입니다. 원리합계 는 원 금과 이(리) 자를 합하는 것들을 통칭하는 말입니다. 여기서는 기본 이론으로부터 다음의 네 가지 유형을 생각할 수 있습니다. 기수불 기말불 상환(할부) 연금의 현가 원리합계의 네 가지 유형에 대한 공식을 외우는 것보다는 원금과 이자를 구하는 과정과 등비급수를 만드는 과정을 이해해 두는 것이 필요합니다. 그래야만 이를 응용한 문제들에 적응할 수 있습니다. 원리합계 문제에 대한 분석 등비수열의 합인 등비급수 이므로 공비가 1인 경우와 그렇지 않은 경우로 나누어집니다. 그렇지만 공비가 1인 경우에는 변화 없이 초항이 계속 유지되는 경우이므로 이를 다루지는 않습니다. 한편, 공비가 1이 아닐 때 등비급수의 식은 다음과 같이 구해져 있습니다. \(\quad\)\(\displaystyle S_n=\frac{a_1 (1-r^n)}{1-r}\) 위 식에서 미지수로 둘 수 있는 것은 초항 , 공비 , 항수 뿐입니다. 문제의 표현에 따라 수식을 세우는 기본 방법만 이해한다면, 원리합계와 관련된 문제들은 쉽게 풀 수가 있습니다. 공비 구하기 원리합계와 관련된 문제들은 실생활 문제이므로, 공비가 얼마라는 표현을 쓰지 않습니다. 다음과 같은 형태로 표현됩니다. 현재값의 k%씩 증가한다. 현재값의 k%씩 감소한다. 첫 번째 값이 \(A\)인 경우에 두 번째 값은 다음과 같이 표현됩니다. 증가 \(\displaystyle A+A\times \frac{k}{100}=A\left(1+\frac{k}{100}\right)\) 감소 \(\displaystyle A-A\times \frac{k}{100}=A\left(1-\frac{k}{100}\right)\) 세 번째 값을 구할 때에도 두 번째 값을 \(A\)라고 치환해 버리면 항상 같은 수식을 이용할 수 있...