'분류 전체보기'에 해당되는 글 407건

최근 안드로이드 커스텀롬의 기반은 두가지로 나눌 수 있습니다.
1. 기존의 전통적인 AOSP를 기반으로 이리저리 지지고 볶아서 만드는 커스텀롬(LinneageOS가 대표적)
2. 픽셀용으로 나온 OS를 이리저리 지지고 볶아서 만드는 커스텀롬(Pixel Experience가 대표적)

사실 AOSP기반의 롬이어도 gapps(구글앱스)를 설치하면 거기서 거기이긴합니다. 하지만 최근 이런저런 커스텀롬을 쓰다보니 차이가 하나 둘씩 눈에 보이더군요.

1. AOSP기반의 롬의 경우 구글특화기능이 빠지는 경우가 많습니다.
- gapps에 따라 해당기능이 작동하기도 하지만 대부분 QuickShare(구, NearbyShare)같은 기능이 막히는것을 확인했습니다.

2. gms(구글코어라고도 합니다)의 일부기능이 작동되지 않는 경우가 존재합니다.
-푸시알림같은 기능인데 구글에 해당 MAC어드레스를 등록하면 작동한다지만 이 또한 귀찮지요.

3. 게이밍쪽에서 커스텀 정도에 따라 성능차이가 벌어지는 편입니다.
-사실 이건 픽셀에 OpenGLES를 Vulkan으로 변환해서 렌더링하는 기능이 들어갔기 때문인데 이게 오픈되지 않은건지 대다수 AOSP기반 롬은 해당 기능이 없습니다.

4. 가끔 커스텀롬이 픽셀로 인식되는 경우가 있습니다.
-장점인지 단점인지 알 수 없지만 AOSP기반롬은 따로 루팅이라도 하지 않은 이상 대부분 본래 모델명으로 인식되지만 픽셀기반의 경우 픽셀로 인식되는 경우가 꽤 있습니다. 여러대의 휴대폰을 쓸 때 헷갈릴 수 있습니다.

안드로이드에 Treble이 적용된 이후 픽셀기반OS를 포팅하기 쉬워졌다고 합니다. 통칭 GSI롬이라고 하는데 GSI기반을 쓰면 그냥 픽셀기반OS에 가깝습니다. 이미 x86용 안드로이드도 gsi롬으로 나오고 있는데 이것도 구글의 야심과 관계가 있어보이는건 제 의심일까요?

블로그이름은 우분투분투기면서 왜 데비안을 쓰는가에 대해 이야기가 들어왔습니다.

뭐... 사실은 그냥 우분투보다 더 날것인 데비안이 쓰고 싶어서요.
그리고 데비안은 unstable혹은 testing으로 업데이트하면서 쓰다보면 어느새 최신판이 되어 있습니다. 우분투처럼 날 잡고 업데이트하는게 아닌거지요.

여기에는 장단점이 있는데 일부 호환성문제가 펑펑터집니다. 업데이트 전에는 잘 돌아가던게 업데이트 하고나니 안 돌아가는 경우가 꽤 있습니다.

보통 라이브러리 호환문제인데 이전에 올린 Python을 직접쓰는 몇몇 패키지가 특히 심각하지요. libstdc++를 쓰는 곳도 자주 사고를 치고요. 하지만 이것도 쓰다보니 다 방법이 생기네요.

최근 우분투는 apt대신 snap을 강제하는 경우가 늘었습니다. 위의 라이브러리 관련 호환성해결에는 아주 좋지만 뭔가 종속되는 느낌이라 그렇게 좋지는 않더군요.

제가 아이폰을 주폰으로 안 쓰는거랑 비슷한 이유입니다. 탈구글은 쉽지만 탈애플은 힘들거든요. 탈MS도 겨우했는데 탈애플은 그냥 모든걸 포기해야합니다. 그와중에 탈캐노니컬을 해야될거 같으니 그냥 미리 탈출한겁니다.

아무튼 자유를 위해 데비안으로 떠났습니다. 하지만 우분투도 쓰긴해야겠지요.

Playonlinux는 여기 블로그에서 자주 소개한 프로그램입니다.

다만 요즘은 Lutris나 다른 프로그램으로 많이 대체하고 있습니다.

문제는 저는 이미 Playonlinux가 많이 편하다는겁니다... 그리고 이미 사용중인 프로그램도 꽤 많고요. lutris로 실행이 가능하긴하지만 lutris를 또 설치하기도 귀찮기도 합니다.

아무튼.. playonlinux의 호환성 문제를 해결하려고 했던 기록을 남깁니다.

우선. Anaconda3와의 문제입니다.

Anaconda3를 설치하면 저는 기본적으로 conda init을 하게끔 옵션을 줍니다. 

앞에 요렇게 (base)가 뜨게 해서 필요할때마다 바로 conda activate (사용자환경) 이렇게 쓸수있게 해놓습니다.

문제는... 이게 Playonlinux에서 사용하는 Python이랑 충돌이 난다는겁니다. 기본 Anaconda의 Base 파이썬과 시스템에 설치된 Python은 서로 다르기 때문에 문제를 펑펑 일으킵니다.

기본적으로 Anaconda를 설치하면서 만들어진 파이썬에서 wx가 없기에 이를 설치하도록 유도합니다만...

Anaconda에서 제공하는 wx는 지금 시스템에 설치된 cairo와 호환성 문제를 일으킵니다. cairo나 기타등등조차 anaconda에서 제공한걸로 때우면 될 수도 있습니다만... 이건 이것대로 일일이 귀찮아지는 문제를 일으킵니다.

그래서 Playonlinux를 실행시에 deactivate 하도록 만들어야 합니다.

우선 Anaconda 실행시 바로 conda가 실행 가능한 이유는 .bashrc에 이런 코드가 추가되기 때문입니다.

anaconda가 설치된 곳의 bin을 우선시 해서 PATH설정을 해서 python이란 명령을 내리면 (anaconda가 설치된 곳)/bin/python을 실행하도록 하는 겁니다. 즉, 해당 위치의 PATH를 삭제해 버리면 다시 python명령은 시스템에 설정된 python으로 다시 돌아온다는 의미가 됩니다.

그래서 playonlinux 스크립트의 일부를 수정합니다.

sudo nano /usr/share/playonlinux/playonlinux

혹은

sudo gedit /usr/share/playonlinux/playonlinux

sudo mousepad /usr/share/playonlinux/playonlinux

 등등으로 편한 텍스트 에디터를 관리자권한으로 /usr/share/playonlinux/playonlinux 파일을 엽니다.

그러면 특유의 Playonlinux의 4잎클로버 로고가 보이게 되고 이 아래에 다음과 같이 적습니다.

export PATH=$(REMOVE_PART="아나콘다가 설치된곳/bin" sh -c 'echo ":$PATH:" | sed "s@:$REMOVE_PART:@:@g;s@^:\(.*\):\$@\1@"')

"아나콘다가 설치된곳/bin"

이게 어딘지 모른다면 ~/.bashrc 파일을 열고

export PATH= "(여기 부분):$PATH"

해당 부분을 복사해서 붙여넣으면 됩니다.

sudo apt install python3-wxgtk4.0

그리고 패키지 시스템에서 제공하는 wxgtk 패키지를 설치하면 됩니다.

--------다만---------

python3.12 이상부터는 playonlinux에서 사용하는 패키지중 asyncore가 deprecated 되었습니다. 본래는 파이썬 기본패키지였으나 이제는 사라졌기에 3.12가 아닌 구버전을 쓰거나 3.12에 맞춰서 다시 설치해줘야 합니다.

하지만 방법은 있습니다.

https://github.com/simonrob/pyasyncore

여기서 제공하는 모듈을 playonlinux 폴더에 설치하면 됩니다.

pip로 설치하는건 위험하니까 (시스템 파이썬입니다. 다시 말씀드리자만...)

playonlinux의 스크립트가 존재하는 곳에 이 모듈을 직접 설치합니다.

git clone https://github.com/simonrob/pyasyncore.git

sudo cp -rf pyasyncore/asyncore/ /usr/share/playonlinux/python/

rm -rf pyasyncore

이렇게 하고 playonlinux 를 실행하면...

호환성을 맞춰가면서 실행 성공!

Playonlinux의 일부 어딘가 덜그럭거리기는 하지만 어찌됐든 실행에 성공 했습니다!!!

python에서 ffmpeg를 사용하는 제일 좋은 방법은 사실 os.system으로 그냥 ffmpeg를 커맨드로 날리는 겁니다.

하지만 이건 불편하기도 하고 보안상 위협도 되면서 파라미터를 다 알기도 어려우니 절대로 추천하지 않습니다

그래서 여러가지 관련 패키지가 있는데

python-ffmpeg

ffmpeg-python

등이 있습니다.

신기하게도 다

import ffmpeg

이렇게 임포트를 합니다.

그래서 적당히 잘 알아서 써야 합니다. 제가 쓰고자 하는건 ffmpeg-python 패키지 입니다.

뭐.. 대충 사용법은

대충 이런식입니다. numpy형태로 out객체를 돌려줍니다.

그런데 여기서 유심히 봐야하는건 .run안의 cmd=["ffmpeg","-nostdin"]입니다.

-nostdin은 표준입력을 사용하지 않겠다는 의미입니다.

바로 앞의 "ffmpeg"는 ffmpeg를 실행하는 명령어를 의미합니다.

즉, 이 패키지는 ffmpeg를 실행해서 영상이나 음성을 numpy 형태로 바꿔주는 역할을 합니다. 그래서 ffmpeg가 설치되어야 합니다.

그래서 리눅스에서는 ffmpeg를 저장소에서 설치하라고 되어있습니다만...

어찌된 영문인지 제 PC에서는 설치되어있는 ffmpeg를 실행을 못하고 오류를 뿜더군요.

그래서 머리를 쓴게 cmd=["ffmpeg"]를 cmd["./ffmpeg"]로 고치고 ffmpeg 바이너리를 실행하는 모듈과 같은 폴더에 넣는 것이었습니다.

아 물론 chmod +x로 실행 옵션은 주고요.

리눅스에서 바로 실행 가능한 바이너리는

https://johnvansickle.com/ffmpeg/

여기서 다운로드가 가능합니다. 여기서 다른 필터는 다 버리고 ffmpeg와 ffprobe만 복사해서 해당 실행을 하는 파이썬 스크립트와 같은 곳에 넣어두면  ffmpeg를 실행하는데 문제를 해결 할 수 있습니다.

윈도우라면 역시 https://www.gyan.dev/ffmpeg/builds/ 여기서 바이너리를 다운로드받아 복사하고 cmd=["ffmpeg.exe"]로 하면됩니다.

fairseq는 페이스북에서 만든 모듈입니다.

딥러닝쪽에서 여기저기 사용하는 편인데 이게 업데이트가 안 된건지  pyinstaller랑 안 맞는건지 패키징 하면 문제가 생깁니다.

https://github.com/facebookresearch/fairseq/issues/5509

https://github.com/facebookresearch/fairseq/issues/4659

일명 NameError가 나는 문제가 있습니다.

이게 그냥 쓸때는 문제가 없지만 pyinstaller로 패키징을 하면 metadata안에 있는 help문구를 찾아서 그렇다고 합니다. 사실 그냥 무시하고 돌려도 문제가 없기에 간단한 Heck이 존재합니다.

그냥 Pyinstaller로 만드는 메인 스크립트중 fairseq을 로딩하는 모듈을 임포트할때 NameError를 except처리해 버리는 겁니다.

물론 pass로 무시하는 겁니다.

이해가 안 되신다면

import fairseq

위 코드에서 에러가 났다면 그냥

try:

    import fairseq

except NameError:

    pass

이렇게 해서 그냥 예외처리하라는 겁니다. 이렇게 Heck이 늘어나는걸 별로 안 좋아합니다만 어쩔수 없지요.

제기랄.. 그냥 fairseq의 버그입니다.

1103번 줄을 보시면 뭔가 이상하죠?

default=False, metadata={help: "store exponential moving average shadow model"}

이렇게 된걸

default=False, metadata={"help": "store exponential moving average shadow model"}

이렇게 고치니 문제가 사라집니다. 이게 뭐야...

최근 Nvidia드라이버의 상태가 이상한건지 아니면 커널의 상태가 이상한건지 우분투의 nvidia드라이버간 궁합이 이상한듯 합니다.

우분투에선 추천드라이버라는게 있어서 보통 이걸 씁니다만 추천드라이버가 바뀌는 경우가 있습니다.

원인은 커널업데이트인데 커널이 보안하고 직접적인 관련이 있는걸 생각하면 일종의 보안업데이트로 인한 문제라고 봐야할겁니다.

즉, 윈도에서 보안업데이트로 간간히 드라이버충돌이 나는것처럼 리눅스도 업데이트로 인해 드라이버 충돌이 나는겁니다.

그런데 무슨 이유인지 커널은 업데이트가 됐는데 드라이버는 업데이트가 안 되었다거나(dkms관련 오류) 커널은 업데이트가 안 됐는데 드라이버만 업데이트가 되는 일이 가끔 일어납니다. (이쪽은 저장소 관련 이슈)

그리고 이게 커널패닉을 일으키는듯 합니다.

반대로 드라이버 설치 스크립트가 꼬이는 바람에 문제를 일으키기도 합니다.
그러니 업데이트 리스트를 보고 커널이나 드라이버가 업데이트리스트에 있다면 한번 고민을 해보고 업데이트를 미루거나 날 좋을때 기도하면서(?)하는걸 추천드립니다.

rar포맷은 많은 곳에서 쓰이고 있습니다. 특히 분할압축할때 엄청 좋은 걸로 유명합니다.

rar.part0 rar.part1 ...

이런식으로 된걸 보실 수 있는데 어떻게 보면 압축프로그램중에서 잔뼈가 굵은 winrar에서 지원하는 포맷이기에 그러합니다.

우리나라야 막강한 반디집이 있다보니 그렇게 썩 중요하지 않지만 (매번 문제가 터지는 알집은 논외) 해외에선 Winrar가 사실상 표준이다보니 RAR포맷을 자주 사용합니다. 물론 진짜 사실상 표준인 ZIP포맷은 더 잘 지원합니다.

아무튼 이렇게 많이 쓰이는 포맷이다보니 리눅스에서도 잘 지원되리라는건 자명한데 의외로 데비안은 RAR을 기본지원하지 않습니다. 심지어 리눅스 민트에서도 기본 지원이 안 되는듯 합니다.

일단 간단하게 지원 하는 방법은

p7zip-rar 패키지를 설치하면 됩니다.

sudo apt install p7zip-rar

이렇게 하면 7zip에서 지원하는 rar라이브러리가 설치되면서 기본압축프로그램(Xarchiver Engrampa File-roller 등)에서 RAR이 지원되는 걸 볼 수 있습니다.

패키지에서 템플릿을 추출하는 중: 100%
패키지를 미리 설정하는 중입니다...
(데이터베이스 읽는중 ...현재 311192개의 파일과 디렉터리가 설치되어 있습니다.)
Preparing to unpack .../base-files_13.3_amd64.deb ...
Unpacking base-files (13.3) over (13.1) ...
base-files (13.3) 설정하는 중입니다 ...
Updating /etc/profile to current default.
(데이터베이스 읽는중 ...현재 311201개의 파일과 디렉터리가 설치되어 있습니다.)
Preparing to unpack .../libc-l10n_2.38-14_all.deb ...
Unpacking libc-l10n (2.38-14) over (2.37-18) ...
Preparing to unpack .../systemd-timesyncd_256.2-1_amd64.deb ...
Unpacking systemd-timesyncd (256.2-1) over (255.5-1) ...
Preparing to unpack .../locales_2.38-14_all.deb ...
Unpacking locales (2.38-14) over (2.37-18) ...
Preparing to unpack .../libsystemd-shared_256.2-1_amd64.deb ...
Unpacking libsystemd-shared:amd64 (256.2-1) over (255.5-1) ...
dpkg: considering deconfiguration of systemd, which would be broken by installat
ion of libc6:amd64 ...
dpkg: yes, will deconfigure systemd (broken by libc6:amd64)
Preparing to unpack .../libc6_2.38-14_amd64.deb ...
De-configuring systemd (255.5-1), to allow installation of libc6:amd64 (2.38-14)
 ...
De-configuring libc6:i386 (2.37-18), to allow configuration of libc6:amd64 (2.38
-14) ...
Checking for services that may need to be restarted...
Checking init scripts...
Unpacking libc6:amd64 (2.38-14) over (2.37-18) ...
dpkg: error processing package libc6:amd64 (--configure):
 package libc6:amd64 2.38-14 cannot be configured because libc6:i386 is at a dif
ferent version (2.37-18)
처리하는데 오류가 발생했습니다:
 libc6:amd64
오류: 시간 제한을 넘었습니다

대충 어떤 상황이었냐면 deb-helper를 설치하기 위해 설치를 하던 도중 패키지 업그레이드가 이루어진 상황이다.

기존에는 2.37-18 버전의 libc6을 쓰고 있었고 deb-helper를 설치하려고보니 최신버전인 libc6 2.38-14버전을 설치하는 중에 무슨 일인지 버그로 꼬여버린것.

특히 중간에 있는

package libc6:amd64 2.38-14 cannot be configured because libc6:i386 is at a dif
ferent version (2.37-18)

요 문구가 가장 중요한데 i386(32비트)패키지와 libc6패키지의 버전이 달라 오류가 난다고 떽떽 거리는 상황이다. 보통은

sudo apt -f install

이 명령어로 해결되어야 정상이지만 무슨 문제인지 계속 저 문구가 뜨면서 해결이 안 되는 상황

특히 i386의 버전이 낮아서 안 되요!!! 이 소리니까 이걸 최신판으로 먼저 바꿔주면 되는데 무슨일인지 amd64패키지만 열심히 올리려고 하고 있다.

그러면 수동으로 저 버전의 패키지를 먼저 설치하면 되는거 아닌가라는 생각에 데비안 홈페이지에서 libc6:i386의 최신 버전 패키지를 다운로드

https://packages.debian.org/sid/i386/libc6/download

sudo dpkg -i libc6_2.38-14_i386.deb

요렇게 해서 설치하고(설치중 오류가 없음..)

sudo apt -f install

이러니까 패키지 오류가 한번에 싹 풀린다.

이래서 unstable버전이라고 하는가보다. 돌겠네 진짜.

윈도우를 사용하다보면 강제 종료된 후 사용하던 창들이 다시 켜지는 경우가 있습니다.

이를 xfce4에서도 지원을 하는데 일명 세션 복원이라고 합니다.

문제는 처음에 세션복원이 되면 편리한데 다음에도 또 다음에도 해당 세션이 복구된다는 겁니다. 재부팅 되면 이게 리셋이 되어야 하는데 리셋이 안 되는거지요.

그럴 때는 저장된 세션을 지워버리면 됩니다.

~/.cache/sessions

위 경로에 가보면 저장된 세션이 존재합니다.

그냥 이걸 가뿐하게 지워주세요.

그리고 SaveOnExit를 지원하지 않게 하겠다면

xfconf-query -c xfce4-session -p /general/SaveOnExit -s false

안 되면

xfconf-query -c xfce4-session -p /general/SaveOnExit -n -t bool -s false

위 명령어로 SaveOnExit를 꺼주시면 됩니다. 이러면 그냥 강제 종료되면 다시 복귀되지 않습니다만 뭐... 깔끔하잖아요?

웹개발을 하다보면 User-Agent String이라는걸 보게됩니다.
접속한 사람의 브라우저가 뭔지 서버에서 확인하는 그런건데 이게 요상한 역사가 있습니다.
2024년현재 이 Agent String(이하 UA)는 그냥 꼼수와 꼼수와 꼼수를 거쳐 하나의 거대한 역사의 한 장면을 연출합니다

처음에는 간단했습니다. Mosaic시절부터 Netscape때 까지만.

위는 Win95의 모자이크고 아래는 윈도2000에서 넷스케이프4.8 (넷스케이프의 개발명이 Mozilla였습니다.)로 접속시 뜨는 UA입니다.
대충 이렇게 브라우저 이름과 운영체제가 뜨는 수준이었습니다.

하지만 Javascript(이하 JS)가 등장하면서 이를 활용한 웹페이지들이 만들어졌고 이를 지원하지 않으면 제대로 뜨지 않으니 웹개발자들은 지원여부를 구분해야했습니다. 다만 이를 지원하는지 확인하는게 UA밖에 없었습니다. 그래서 당시 주류이자 Javascript를 유일하게 지원했던 Netscape냐 아니냐 정도로 구분했습니다.

그 당시 쓰던 코드가 UA문구중에 Mozilla가 있느냐 없느냐 였습니다. 그러다 Internet Explorer(이하IE)가 등장하면서 꼬이기 시작합니다.

IE는 Netscape와 호환을 목표로 했기에 JS가 지원됐지만 웹페이지들은 Mozilla라는 문구만 확인했기에 IE에도 JS가 안되던 이전페이지만 보여줬고 이를 해결하기위해 MS가 만든건

(Win95에서 IE2.0사용시)

네... User Agent에 Mozilla라고 집어넣고 compatible이라는 문구를 넣었습니다.
즉 나는 넷스케이프와 호환되는 녀석이다라고 적은건데 이 때까지만해도 이게 재앙의 시작일줄은 몰랐을겁니다.

이후 버전업을 하고 Windows가 이런저런 에디션이 생기면서 UA는 더 지랄맞아지게 됩니다

WindowsXP x64버전의 IE6.0을 32비트버전으로 실행했으며 닷넷프레임웍을 3.5버전으로 설치된 환경이라는 의미입니다.

닷넷프레임웍버전이 끼어들어간 이유가 당시 MS가 당시 많이 쓰이던 자바대신 닷넷을 밀고있었는데 이게 또 버전별로 호환을 탔기 때문입니다.

네...벌써 개판입니다. 하지만 MS는 IE개발에 손을 놓았고 Firefox가 등장하면서 또 한번의 격변이 일어납니다.

Firefox는 그래도 MS보단 고집이 있어서 (그리고 무엇보다 Netscape의 직계후손이라서)UA를 깔끔하게 보냈습니다.

리눅스 X11환경에서 영문으로 돌아가는 Firefox 2.0 대충요런식입니다.
특히 여기서 Gecko라는 문구가 중요한데 당시 웹표준이 대두가 되면서 HTML5가 이슈가 되기 시작했습니다. 그 당시 HTML5의 지원을 제일 서두르던것이 Firefox의 Gecko엔진이었고 Firefox의 엔진인 Gecko를 쓰는지만으로 HTML5가 지원되는지 아닌지 판단하곤했습니다. (Gecko는 오픈소스였기에 Firefox기반브라우저가 우후죽순 있었습니다.)

여기서 그동안 IE를 쓰던 애플은 자기들만의 브라우저가 있어야겠다고 판단하고 오픈소스 엔진인 KHTML을 가지고 Webkit이라는 엔진을 발표한뒤 Safari라는 이름으로 브라우저를 내놓게 됩니다.

Webkit은 HTML5를 준수하는 브라우저 였지만 웹페이지는 이를 알 수가 없었고 Gecko와 호환된다는 명목으로 UA에 like Gecko라는 문구를 적습니다.

물론 자신의 이름도 꼭 뒤에 적어서 Safari인지 판단하도록 했습니다.

그리고 Webkit을 기반으로 한 Chrome이 등장하면서 또 한번의 격변이 일어나는데...

다시 개판이 되기 시작했습니다. 당시에는 Webkit을 이용한게 맞으니까 AppleWebkit이라고 적는건 이해하는데 뒤에 Safari도 함께 적었습니다. 그게 Webkit이 아닌 Safari라는 문구를 쓰는게 더 익숙했던 Webkit용 페이지 덕분에 그냥 Safari를 적었다고 합니다. 덕분에 크롬을 쓰면 애플홈페이지에서 맥 전용기능을 실행하려 들었다고 하네요.

추가로 IE11도 HTML5를 준수하면서 똑같이 like Gecko문구를 추가합니다.

어쩌다보니 자바스크립트지원 여부를 판단하는 Mozilla라는 문구처럼 Gecko라는 문구는 HTML5지원여부를 판단하는 문구가 되어버렸고 Mozilla와 관계없는 모든 브라우저가 Mozilla라고 적고 역시 Gecko엔진을 쓰지 않는 모든 브라우저가 Gecko를 적는 요상한 현상이 일어났습니다.

여기에 크롬이 브라우저의 대세가 되고 HTML5의 특정 기능들이 크롬에서 가장 먼저구현되며 Chrome이라는 문구를 찾아 전용코드를 쓰는 일이 생기게 되었는데

Chromium으로 만들어진 Edge는 당연히 이를 지원하기에 Chrome이라는 문구를 넣었습니다

당연히 뒤에 자신이 Edge라는 문구를 추가해서요.

Mozilla에 Gecko에 Safari에 이젠 Chrome이라는 문구까지 UA에 들어가기 시작했습니다.

하하...이젠 개판이네...