@perillamint
서버메이드 깐프 음식에 충격 받아서 그만... 요약 한번 시켜보고 알려드리죠
Perlmint
@perlmint@hackers.pub · 38 following · 29 followers
크로스 플랫폼 빌드 고치는 노동자
Github- @perlmint
Bluesky- bsky.perlmint.dev
@perillamint서버메이드 깐프 요약 해달라니까 관련된 내용으로 창조를 하는데요...?
아니 이것들은 글을 요약해달라고 했지 평가해달라고 했나...;
@perillamint서버메이드 깐프 음식에 충격 받아서 그만... 요약 한번 시켜보고 알려드리죠
오... open-webui 에서 모델 여러개 선택하면 이렇게 나오는구나
네이버에서 모델 공개했다고 해서 ollama로 변환해서 돌려봤는데...
아무도 읽을 필요가 없길 바라는 글을 작성했다.
간단한 rpmbuild의 사용과 private rpm package 배포
Perlmint @perlmint@hackers.pub
마지못해 패키지를 만들어야 할 것 같은 사람을 위한 설명입니다. 제대로된 패키지를 만들고 싶은 경우에는 부족한 점이 많습니다.
대부분의 경우에는 프로그램을 직접 소스에서 빌드하는 일도 적고, 그걸 시스템 전역에 설치하는 일도 흔치는 않을 것입니다. 좋은 패키지매니저와 관리가 잘되는 패키지 저장소들을 두고 아주 가끔은 직접 빌드를 할 일이 생기고, 흔치 않게 시스템 전역에 설치할 일이 생길 수 있습니다. 어지간한 프로그램들은 요즈음의 장비에서는 별 불만 없이 빌드 할 만한 시간이 소요되나, 컴파일러처럼 한번 빌드했으면 다시는 하고 싶지 않은 프로그램을 다시 설치해야하는 경우도 있을 수 있습니다. 하필 이런 프로그램들은 결과물도 덩치가 매우 큽니다. 이럴 때는 최대한 간단하고 필요한 항목만 패키지에 넣어서 만들어두고 다시 활용하면 좋을 것이기에 이런 경우를 위한 rpmbuild에 대한 나름 최소한의 사용 방법을 정리해봅니다.
rpmbuild
rpmbuild는 rpm-build 패키지로 설치가 가능하며, 나름 단순하게 rpm으로 패키징을 할 수 있는 유틸리티입니다. spec파일에 패키지 정보, 빌드 명령, 설치 명령, 패키지가 포함해야 할 파일 목록을 작성해서 rpmbuild에 입력으로 넣어주면 빌드부터 시작해서 rpm패키지를 만들어줍니다. native 프로그램의 경우 디버그 심볼을 알아서 분리해서 별도의 패키지로 만들어주고, 필요한 의존성도 추정해서 명시해줍니다. 또한, 필요한 경우 하나의 spec 명세로 연관된 서브 패키지도(ex. 실행파일 패키지인 curl과 라이브러리 패키지 libcurl, 라이브러리를 사용하기 위한 개발 패키지 libcurl-devel) 같이 만들 수 있습니다.
작업 환경
rpmbuild는 기본으로 ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS,BUILDROOT}의 경로에서 동작하며 각 경로의 용도는 다음과 같습니다.
SOURCES에는 압축된 소스코드가 위치합니다.SPECS에는 패키지 정의인 spec파일을 둡니다.BUILD밑에서 빌드 작업이 진행됩니다.RPMS에 바이너리 rpm결과물이 생성됩니다.SRPMS에는 소스 rpm결과물이 생성됩니다.BUILDROOT는 패키징 하기 위해 빌드 결과물을 모으는 경로입니다.
spec파일
spec파일은 패키지를 어떻게 빌드하고 어떤 항목들이 패키지에 포함될지, 패키지의 이름, 설명 및 의존성 등의 메타데이터, 패키지 설치, 삭제시의 스크립트를 정의할 수 있습니다. 보통 시작 부분에는 메타데이터 정의로 시작하며, 다음과 같은 기본적인 형태를 취합니다. 나름 단순하게 만든 python을 위한 spec을 예시로 들어보겠습니다.
Summary: Python %{version}
Name: python-alternative
Version: %{version}
Release: 1%{?dist}
Obsoletes: %{name} <= %{version}
Provides: %{name} = %{version}
URL: https://www.python.org
Requires: libffi openssl
AutoReq: no
License: PSFL
Source: https://www.python.org/ftp/python/%{version}/Python-%{version}.tgz
BuildRequires: libffi-devel openssl-devel
BuiltRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
%define major_version %(echo "%{version}" | sed -E 's/^([0-9]+)\\..+/\1/' | tr -d)
%define minor_version %(echo "%{version}" | sed -E 's/^[0-9]+\\.([0-9]+)\\..+/\1/' | tr -d)
%description
Python
%package devel
Summary: python development files
Requires: %{name} = %{version}-%{release}
%description devel
Python development package
%prep
%setup -q -n Python-%{version}
%build
./configure --prefix=%{_prefix}
%install
%{__make} altinstall DESTDIR=%{buildroot}
%{__ln_s} -f %{_bindir}/python%{major_version}.%{minor_version} %{buildroot}/%{_bindir}/python%{major_version}
%clean
%{__rm} -rf %{buildroot}
%files
%{_bindir}/python*
%exclude %{_bindir}/idle*
%{_bindir}/pip*
%{_bindir}/pydoc*
%exclude %{_bindir}/2to3*
%{_libdir}/libpython*
%{_prefix}/lib/libpython*
%{_prefix}/lib/python*
%{_mandir}/man1/python*
%files devel
%{_includedir}/python*
%{_prefix}/lib/pkgconfig/python*%로 매크로를 사용할 수 있으며, %package, %description, %files 같은 매크로는 인자를 주어서 서브 패키지를 정의하는데도 쓸 수 있습니다.
앞선 예제처럼 devel 이라고작성하면 메인 패키지이름 뒤에 붙여서 python-alternative-devel가 되며, curl - libcurl과 같은 경우에는 메인의 이름은 curl이고, 딸린 패키지를 정의할 때는 %package -n libcurl과 같이 -n옵션을 추가해서 지정할 수 있습니다. 몇몇 매크로는 단계를 정의하는 것과 같은 동작을 하며 다음과 같습니다.
%package
유사성을 보면 spec파일의 맨 첫부분은 메인 패키지의 %package에 해당하는 것이 아닌가 싶습니다. <Key>: <Value>의 형태로 메타정보를 작성합니다. 대부분은 Key를 보면 무슨 값인지 추측 할 만합니다.
나중에 설명할 %files에서 나열한 파일을 rpmbuild가 분석하여 자동으로 패키지가 필요로 하는 의존성을 추정해서 추가 해 줍니다. python 스크립트, perl 스크립트, native 실행파일 등을 분석해서 알아서 추가해주는 것 같은데, 경우에 따라서는 틀린 의존성을 추가해주기도 합니다. 이 때는 AutoReq: no를 설정하여 자동 의존성 추가를 막을 수 있습니다. 이 python-alternative 패키지는 /usr/local/bin/python%{version}을 설치하는데 아마도 같이 포함되는 python 스크립트에 의해서 /bin/python을 의존성으로 추정하여 요구합니다. 패키지 스스로가 제공하는 의존성은 미리 설치 되어있기를 요구하지 않게 동작하는 것 같으니 보통은 문제가 없습니다만, 이 경우에는 스스로 제공을 하지 않기 때문에 python을 설치하기 위해서 python이 필요한 경우가 발생하므로 AutoReq를 껐습니다.
%prep
준비단계로 소스코드의 압축을 해제하고 필요한경우 패치를 적용합니다.
%setup 매크로를 이 안에서 보통 사용하며, %setup은 Source에 명시된 파일명의 압축 파일을 SOURCES 밑에서 찾아서 압축을 풉니다. 그리고 동일한 이름의 디렉토리로 이동을 합니다. 앞선 예제에서는 SOURCES/Python-%{version}.tgz의 압축을 풀고 Python-%{version}으로 이동을 합니다.
패치가 필요한 경우 보통 이 뒤에 패치를 적용하는 명령들을 추가 합니다.
%build
설정, 컴파일 등을 수행하는 단계입니다. 이곳에서 자주 하는 매크로로 %configure, %make_build 등이 있습니다. %configure는 configure를 prefix 및 기타 몇가지 일반적으로 쓰이는 옵션을 추가하여 실행해주며, %make_build는 make와 비슷하게 모든 타겟을 빌드 합니다. 예제에서는 둘다 안쓰고 있고, 심지어 실제 빌드는 안하는데 어쨌든 이후의 %install까지 지나고나서 빌드 결과물만 맞는 위치에 만들어지면 대충 패키지를 만드는데는 별 문제는 없는 것 같습니다.
%install
여기서 빌드 결과물을 설치하는 명령을 작성합니다. 일반적으로 %make_install을 사용하여 make install DESTDIR=%{buildroot}와 비슷한 명령을 수행하여 %{buildroot}밑에 빌드 결과물이 prefix를 유지하여 설치되게 합니다. 예제의
%{__ln_s} -f %{_bindir}/python%{major_version}.%{minor_version} %{buildroot}/%{_bindir}/python%{major_version}을 보면 추정 할 수 있듯이, 패키지에 포함시킬 파일들을 %{buildroot}밑에 생성을 하면 되며, 추가적인 심볼릭 링크는 패키지를 빌드하는 시점에는 존재하지 않지만, 패키지를 설치하게되면 존재하게 될 %{_bindir}/python%{major_version}.%{minor_version}를 향하는 것을 %{buildroot} 밑인 %{buildroot}/%{_bindir}/python%{major_version}에 만듭니다.
%files
패키지에 포함될 파일 목록을 작성합니다. glob 양식으로 파일 목록을 작성할 수 있습니다. %{buildroot} 밑에 생성 되었지만 어느 %files에도 포함되지 않은 파일이 있는 경우에는 빌드를 실패합니다. 그러므로 %exclude를 사용해서 명시적으로 제외해줘야 합니다.
기타 매크로
rpmbuild에서는 기본으로 다양한 매크로를 제공하고 있습니다. --define "_libdir %{_prefix}/lib64"와 같은 옵션을 실행시에 주어서 실행시점에 매크로를 덮어 쓸 수도 있고, 앞선 spec파일 내의 %define major_version 와 같이 다른 매크로와 셸 명령을 활용하여 매크로를 정의 할 수도 있습니다.
원하는 동작을 안하는 것 같은 경우에는 --show-rc옵션을 사용하여 매크로가 어떻게 정의되어있는지 확인해 볼 수 있습니다.
빌드
rpmbuild의 매뉴얼을 보면 자세하게 나와있지만 가장 단순하게는
rpmbuild -bb <specfile>로 바이너리 패키지를 빌드할 수 있습다. 이 때, 압축된 소스코드는 미리 SOURCES밑에 두어야 합니다.
private rpm package 배포
직접 비공개 패키지 저장소 프로그램을 실행하여 제공하는 방법도 있겠지만, 최대한 간단하게 할 수 있는 방법으로, rpm관련 패키지 설치 명령이 입력으로 http등의 URL도 받는 것을 활용하여 적당한 장비에서 http로 서빙을 해주면 됩니다.
힘들게 작성했던 스크립트가 사라졌나 했는데 아직 머지가 안되어서 안보이는 것이었다. 진짜 놀랬네...
vcpkg에서 혹시 모르니까 컴파일러 해시를 비교해서 패키지를 다시 빌드하게 한다는데, MSVC만 유독 다른 머신에 같은 버전으로 죄다 설치해도 해시가 다르게 나와버려서 사실상 공유를 못하는 문제가 있나보다. 이것 때문에 쓸데없는 리빌드로 20분정도씩 매번 낭비하는 것 같은데...
CI에서만 인자 파싱이 아무래도 이상하길래 pwsh를 7.2.2에서 7.5.0으로 업데이트 하니까 해결 되었다.
AI 생태계에 씨앗을 뿌리다: 상업용 오픈소스 AI, HyperCLOVA X SEED | CLOVA
https://bit.ly/4cOkG8e
- 네이버는 상업용 오픈소스 AI 모델 HyperCLOVA X SEED를 공개
- 3B(이미지 이해), 1.5B(텍스트 처리), 0.5B(경량 대화) 세 가지 크기로 출시
- 모두 한국어에 특화되어 동급 모델보다 우수한 성능을 보임
- 2024년 4월 24일부터 Hugging Face에서 다운로드 가능
Gemma 3 와 비교하는군요
오는 8월 9일 Microsoft Korea에서 열리는 #우분투 #사용자 와 #기여자 가 모이는 국내 최대 행사, #UbuCon Korea 2025의 #연사 를 찾습니다! 🎤
올해는 특별히 커뮤니티 #20주년 을 맞아, #초보자 부터 #전문가 까지 모두를 위한 우분투 #활용법 과 경험, 흥미로운 #사례 를 공유해주실 분들을 기다립니다. 여러분의 우분투, #리눅스 그리고 #오픈소스 이야기를 들려주세요! ✨
🗓️ #CFP 마감: 2025년 5월 16일
🔗 자세히 보기 및 #제안서 제출: https://2025.ubuntu-kr.org/cfp
#UbuConKorea #UbuConKorea2025 #Ubuntu #컨퍼런스 
@ubuntuCanonical Ubuntu
친구가 외국 반도체회사에 다니는데 이름만 들으면 다 아는 세계에서 손꼽히는 회사다. 1년 전쯤에, 친구가 자기 팀에서 예전부터 쓰고있는 시뮬레이션 코드가 너무 복잡해서 리팩토링 하고 싶다고 나를 찾아왔다. 한 2, 3000줄 되는 Numpy 코드였다.
나는 시뮬레이션의 의미 자체는 전혀 이해를 못하니(이래서 보안문제도 익스큐즈 할수 있었을 것이다), 그냥 코드의 모양만 보고 이상한 부분을 조금씩 고쳐나갔다. 그... 전형적인 물리학자들의 실험실 코드였다(코드를 못짜는건 이해를 하는데, 거기에 대해 한치의 부끄러움도 느끼지 않는다는 점이 뒷목을 잡게 만든다). Numpy 함수도 제대로 활용을 못해놨길래, 나도 Numpy 잘 못쓰지만 대충 이런 함수가 아마 있겠지... 하고 검색해서 찾아내서 교체하고 이런걸 반복했다.
이것저것 고친 다음에 잘돌아가나 한번 실행을 해봤는데, 이럴수가. 시뮬레이션이 1000배 빨라졌다. 아니 뭐, 한 2배 3배 빨라졌으면 내 솜씨라고 자부할텐데, 1000배 빨라진거는 그냥 원래 코드가 똥통이었다고 해석할수 밖에 없다. 구라안치고 정말 1000배다. 1000배의 성능향상의 보답으로 나는 교촌치킨웨지콤보세트를 현장에서 받아먹었다.
그 이후에 어떤 일이 있었냐. 기존 시뮬레이션 코드로는 하루에 시뮬레이션을 2, 3번정도밖에 돌리지 못했는데, 1000배 빨라지고 나니까 결과가 수십초만에 나오니 하루에 수백번 돌릴수 있게 된것이다(내가 고친 코드가 전부는 아니어서 1000배 향상은 아닌데, 가장 큰 병목이긴 해서 결국 100배 이상이라는 듯). 그때부터 100배 많아진 데이터를 처리하기 위한 인프라가 필요해졌다. 그래서 거기 개발팀이 데이터베이스와 데이터 파이프라인 구축을 시작하게 되었다고 한다. 그 팀에서는 일종의 특이점이 시작된것이다;;
결론: 교촌치킨웨지콤보 세트는 개맛있었다.
deno-lsp가 lsp-mode에서 자동완성이 왜 안되는지 모르겠어서 그냥 순수수제코딩 시도하는데 잘 모륵는 것에 대해서는 역시 할만한 일이 아니다
이게 다 모바일 브라우저의 IME가 이상해서 code-server가 쓸만하지 못해서 그렇다... 구글마저도 뭔가 이상한 동작을 당하니 IME가 문제일 듯
deno-lsp가 lsp-mode에서 자동완성이 왜 안되는지 모르겠어서 그냥 순수수제코딩 시도하는데 잘 모륵는 것에 대해서는 역시 할만한 일이 아니다
Gemini 2.5 pro 품질 꽤 괜찮다고 이것도 되나? 하면서 이상한 것 시키면서 낭비했다
확실히 문서에 잘 정리해놓으니까 AI랑 협업하기가 수월한 것 같음. 개인 프로젝트에도 잘 해놓으면 아주 좋겠구먼
코파일럿에게 주석 고쳐달라고 했더니 저 혼자서 고치고는, "누락된 것이 있네요. 고치겠습니다"를 두번째 반복해서 한번의 요청에 혼자서 같은 파일을 세번 고쳤다.
소프트웨어 엔지니어를 위한 연합우주 서비스 Hackers' Pub을 알고 계신가요? 저희가 특별히 중요시하는 것은 다른 플랫폼과는 조금 다른 행동 강령입니다.
저희는 현실 세계의 불평등이 온라인 공간에도 그대로 반영된다는 사실을 인식하고 있습니다. 그래서 “모든 사람을 동등하게 대우”한다는 표면적인 중립성이 아닌, 구조적 불평등에 적극적으로 대응하는 자세를 분명히 하고 있습니다. 이러한 접근의 일환으로, 차별적 발언과 차별에 대항하는 발언을 구분합니다. 이를 통해 “차별은 안 된다”는 명목 하에 차별 비판까지 동일시하는 “양비론”의 함정을 피할 수 있다고 생각합니다.
기술 커뮤니티에서 자주 볼 수 있는 문제로는 특정 기술 선택에 대한 비판이나 기술 수준에 따른 계층화가 있습니다. “이것도 모르냐?”는 태도는 학습을 방해할 뿐입니다. 저희는 초보자와 경험자 모두 동등하게 존중받는 환경 조성을 중요시합니다.
또한, 연합우주의 핵심 가치로 프라이버시가 있지만, Hackers' Pub에서는 특히 익명성의 권리를 강조합니다. 타인의 신원을 특정하려는 행위나 익명이라는 이유로 차별하는 것을 금지함으로써, 안심하고 참여할 수 있는 공간을 지향합니다.
이러한 행동 강령 자체도 완벽하지 않으며, 커뮤니티와 함께 발전해 나가는 것이라고 생각합니다. 모든 구성원이 개선안을 제안할 수 있는 체계를 마련함으로써, 더 나은 환경을 함께 만들어 나가고자 합니다.
자세한 내용은 Hackers' Pub 행동 강령을 참조해 주세요. 연합우주에서 더 건강한 기술 커뮤니티를 함께 키워나가지 않으실래요?
코파일럿이 태업한다. 코드 안고치고 넘어가네
해커뉴스에서 Fabrice Bellard의 QuickJS가 한 파일에 5만줄 집어 넣고 한 함수가 몇백 몇천줄 되는 걸 보고서 파일 및 함수 길이를 강력하게 제한하는 도그마가 항상 옳은 것은 아니다, 라는 코멘트를 보았는데 이는 반만 맞는 말이다. 나도 대부분의 개발자보다 파일이나 함수 길이에 훨씬 관대한 (그리고 이 사실을 한참 뒤에야 깨달은) 사람이라 아는 건데, 그냥 Bellard가 5만줄 전체의 맥락을 전부 기억하고 있고 해당 코드를 거의 Bellard만 건들고 있기 때문에 추가적으로 모듈화할 필요가 없는 거고, 대부분은 그 정도의 기억이 불가능하기 때문에 여럿이 같이 짜는 코드라면 최저치에 맞춰서 파일이나 함수 길이를 줄일 필요가 있다고 하는 것이다. 지나친 도그마를 부정하는 것도 중요하지만 도그마가 생긴 진짜 이유를 파악해서 취사 선택하는 것이 더 중요한 이유.
@ailrunAilrun (UTC-5/-4) 
@kodingwarriorJaeyeol Lee 
@lionhairdino 아아 어떤 느낌인지 상상이 갑니다. 저는@parksb
님이 하신것처럼 맥주가 차있으면 좋겠다싶어 H 중간 막대를 위로 올렸습니다.
H가 컵이고, P가 손잡이어야 하는데, H가 컵 모양이 잘 안나와서, 포기하고 그냥 맥주에 담가 버렸습니다. (근데 호스트분 아주 근거리에 디자이너분 계신 거 아닌가 모르겠습니다.) @ailrunAilrun (UTC-5/-4)
코파일럿 + 클로드 에이전트로 쓰니 확실히 쓸만하다
무한재귀하는 코드 작성해주는 것에 당하기는 했지만
코파일럿 + 클로드 에이전트로 쓰니 확실히 쓸만하다
오늘의 MFC. 라디오버튼을 클릭해서 값을 설정하고, 그 라디오버튼 그룹의 다른 값으로 비 UI적인 방식으로 선택 된 후, 해당 프로그램이 포커스를 다시 얻으면 맨 처음에 클릭했던 값으로 선택이 바뀐다.
아이패드에서 원격 개발을 하려는 노력으로 emacs를 오랜만에 세팅하는김에 회사 개발환경도 통일시켜볼까 했는데, 회사 장비에서는 백신과 사이가 나빠서 써먹기 어려울 정도로 느리다.
전에 rpi에서 돌릴 컨테이너 이미지를 x86_64에서 빌드하는데 musl사용한 단일 실행 바이너리라고 크로스컴파일하고는 scratch에 넣었더니만 aarch64 바이너리를 포함한 x86_64 이미지가 나왔던 기억이 있다. 그때 당시에 고칠 방법이 이미지를 파일로 export하고는 메타데이터를 고치는 방법 뿐이었던 것 같은데, 지금은 어떤지 모르겠다.
기어코 CMake 2.8, 3.10, 4.0의 CI테스트를 돌리게 고쳤고 이슈도 일단 해결했다.
어우... cmake지옥... 2.8은 Ubuntu latest의 gcc로 컴파일 에러가 나고, 4.0은 openssl을 필요로 한다.
Hackers' Pub은 검색에서 몇 가지 기본적인 문법들을 지원하고 있습니다. 문서화되지 않았기 때문에 한 번 정리해 봅니다.
| 문법 | 설명 | 예시 |
|---|---|---|
" 키워드 " |
따옴표 안에 들어간 문자열을 띄어쓰기를 포함하여 찾습니다. 대소문자는 구분하지 않습니다. (따옴표 안에 따옴표를 넣으려면 \"와 같이 이스케이프.) |
"Hackers' Pub" |
from: 핸들 |
해당 사용자가 쓴 콘텐츠만 추립니다. | from:hongminheefrom:hongminhee@hollo.social |
lang: ISO 639-1 |
해당 언어로 쓰여진 콘텐츠만 추립니다. | lang:ko |
# 태그 |
해당 태그가 달린 콘텐츠만 추립니다. 대소문자는 구분하지 않습니다. |
#Fedify |
조건 조건 |
띄어쓰기 양 옆의 조건을 모두 만족하는 콘텐츠만 추립니다(논리곱). | "Hackers' Pub" lang:ko |
조건 OR 조건 |
OR 연산자 양 옆의 조건 중 하나라도 만족하는 콘텐츠를 추립니다(논리합). |
해커즈퍼브 OR "Hackers' Pub" lang:ko |
( 조건 ) |
괄호 안의 연산자들을 먼저 결합합니다. | (해커즈퍼브 OR 해커즈펍 OR 해커스펍) lang:ko |
구체적인 동작 방식은 Hackers' Pub 소스 코드를 보시면 더 자세히 알 수 있습니다.
빌드 이미지에서 소스빌드가 필요한 프로그램을 전부 패키징했다. 이걸로 빌드이미지 구워서 CI돌리기까지 시작했다. 8개를 패키징 하는데만 약 3일 정도 소모한 듯 하다
2025년에 굳이 꾸역꾸역 cmake 2.8에서의 빌드를 보장 할 필요가 있을까...? 이제는 CI 돌리는게 더 어렵다... 해보니까 소스빌드도 실패하네
@hongminhee洪 民憙 (Hong Minhee) 이슈는 먼저 봐서 알고 있기는 했으나 더 심한 비율에 놀랐습니다 ㅎㅎ...
그와 반대로 맥 데스크탑은 생각외로 컴팩트하고 예쁜데다가 맥 데스크탑 셋업은 꽤 좋아보이더라
습 이게맞나
맥 스튜디오는 귀여운거 맞음
가격이 흉악해서 문제지
Article은 진짜 폰에서는 작성 못하겠네
코파일럿 이제 써봤는데 기능적인건 잘 못하고 주석에 해당하는 것 써달라는 것은 적당히 하네요. 하지만 느려...
코드 자동완성은 기존에 쓰던 로컬LLM하고 싸우는지 안나와서 못 써봤고 edit모드로만 해봤습니다
코파일럿 이제 써봤는데 기능적인건 잘 못하고 주석에 해당하는 것 써달라는 것은 적당히 하네요. 하지만 느려...
오늘 하루는 근무시간 내내 빌드만 하겠네, 그래도 이제 큰 빌드거리 2개 남았다... python과 clang...
쿠버네티스는 컴포즈만으로는 할 수 없는 HA (네트워킹 포함) 까지 책임져주는 솔루션 중 de-facto 라서 쓴다고 생각해요
앵간한 상황 다 대응되고
복잡하고 어려운 이유는 "앵간한 상황 다 대응"되기 때문이 아닐까 싶음... 컨테이너만 띄울거면 이렇게 복잡해질 이유가 없었음 - 사실 그 부분만 보면 컴포즈랑 비슷하기도 하고
rpmbuild 잘 만들어져있네, 하지만 원래부터 프로그램 소스 빌드, 설치는 중구난방이라 잘 만들어도 혼란스럽기는 여전하다
GeekNews의 〈소프트웨어 엔지니어로 산다는 건 미친 짓이야〉 주제에 @youknowone 님께서 쓰신 좋은 댓글:
소프트웨어 개발이 어려운 일이라는 사람들은 본인이 그 일을 하는 이유가 뭘까요? 고되고 힘든 일이지만 보람있는 일이라서 하시나요? 이 업계에서 그런 분들은 그리 많지는 않았던 것 같습니다. 남들이 못하는 것 같으니까 어렵다고 주장하는거지, 실상은 그게 본인한테 가장 쉬운 일이니까 하시는 것 아닌가요? 남들이 좀 띄워준다고 자화자찬하면서 나만 특별한 양 여기면서 눈을 가리지 말고 주위를 봐야합니다. 이공계에서 어떤 분야가 방구석에서 인터넷 좀 보고 독학한다고 (잘 하면) 몇달만에 현업에 투입할 수 있는 전문가가 됩니까?
(…중략…)
물론 남들이 가지지 못한 훌륭한 손재주를 가진 사람은 존중받아 마땅하지만, 약간의 손재주를 연마했다고 해서 소싯적 배워둔 손재주로 평생 먹고 살면 좋을텐데 왜 그럴수 없을까, 나는 이런 훌륭한 손재주를 가졌는데 다른 사람들처럼 힘들게 일하지 않아야 하는 것 아닐까, 나는 남들은 쉽게 하지 못하는 대단한 재능을 가진 것이 아닐까 등등의 특별한 나에 심취하는건 교만에 가까운 일이 아닐까 합니다.
Jira, Linear 등 일정 관리 앱이 풀어야할 가장 어려운 문제는, 사용자 중 상당수는 애초에 일정 관리를 하기 싫어하는 사람이라는 것이다. 안타깝게도 나도 거기 포함되는데, 문제는 그런 사람일 수록 일정 관리가 꼭 필요하다. 나중에 프로젝트가 복잡해지면 일정 관리 앱을 켜는 거 자체를 꺼리게 된다. 이걸 어쩌면 좋지.
주말에 했던 〈국한문혼용체에서 Hollo까지〉의 발표에서 대강:
- 연합우주에서도 국한문혼용체로 글을 쓰는데 사람들이 읽기 쉽게 한글 독음을
<ruby>태그로 달고 싶다! - Mastodon에 패치를 할 수는 있지만 업스트림에 받아들여질 리가 없으니 패치된 Mastodon 서버를 직접 운영할 수 밖에 없다.
- 혼자 쓰자고 Mastodon 서버를 운영하려니 비용이 크다. 가벼운 ActivityPub 서버 구현을 만들어야겠다.
- ActivityPub 서버 구현을 바닥부터 하자니 할 일이 너무 많다. ActivityPub 프레임워크를 만들어야겠다. → Fedify
- Fedify를 만들었으니 일인 사용자용 ActivityPub 서버를 구현하자. → Hollo
- Hollo를 만들었으니 Seonbi를 연동하자.
- Seonbi를 연동하여 한자어에 한글 독음이
<ruby>로 달게 했으나 Mastodon과 Misskey에서<ruby>태그를 지원 안 한다. - Mastodon 쪽에 이슈를 만들고 연합우주에서 홍보하여 결국 패치됨. Mastodon에서도
<ruby>지원! - Misskey 쪽에 패치를 보내서 결국 Misskey에서도
<ruby>지원! - 행복한 국한문혼용 생활.
이상과 같은 이야기를 했더니, “야크 셰이빙이 엄청나다”라는 의견을 들었다.
RE: https://hackers.pub/@hongminhee/019603e0-33ef-700f-90f4-153c8c995135
간혹 "이모지"가 아니라 "에모지"라고 쓰는 이유에 대한 질문을 받습니다. 여기다 써 두면 앞으로 링크만 던지면 되겠지?
요약: 에모지라서 에모지라고 씁니다.
"이모지"라는 표기는 아마도 "emoji"가 "emotion"이나 "emoticon"과 관련이 있다고 생각해서 나오는 것으로 보이는데요. "emoji"와 "emoticon"은 가짜동족어(false cognate)입니다. "emoji"는 일본어 絵文字(에모지)를 영어에서 그대로 받아들여 쓰고 있는 것입니다. 심지어 구성원리도 에모+지가 아니고 에+모지(絵+文字)입니다. "emotion"과 유사해 보이는 것은 순전히 우연일 뿐, 계통적으로 전혀 아무 상관이 없습니다. "이모티콘"과 "이미지"의 합성어가 아닙니다. (그랬으면 "-ji"가 아니라 "-ge"였겠죠.)
그리고 그렇기 때문에 에모지를 에모지로 표기할 실익이 생깁니다. :), ¯\_(ツ)_/¯, ^_^ 등은 이모티콘입니다. 반면 😂는 명확히 에모지입니다.
프로그래머에게 이건 정말 중요한 구분입니다. "이모티콘을 잘 표현하는 시스템"과 "에모지를 잘 표현하는 시스템"은 전혀 다른 과제이기 때문입니다. 에모지는 "그림 문자"라는 원래 뜻 그대로, 어떤 문자 집합(예를 들어 유니코드)에서 그림 문자가 "따로 있는" 것입니다. 내부 표현이야 어떻든, 적어도 최종 렌더링에서는 별도의 글리프가 할당되는 것이 에모지입니다. "무엇이 에모지이고 무엇이 에모지가 아닌가"는 상대적으로 명확합니다(문자 집합에 규정되어 있으니까).
반면 이모티콘은 "무엇이 이모티콘인가?"부터 불명확합니다. 우선 대부분의 이모티콘은 이모티콘이 아닌 문자를 조합하여 이모티콘이 만들어지는 형식입니다. 예를 들어 쌍점(:)이나 닫는 괄호())는 그 자체로는 이모티콘이 아니지만 합쳐 놓으면 :) 이모티콘이 됩니다. 하지만 조합에 새로운 의미를 부여했다고 해서 다 이모티콘이라고 부르지도 않습니다. -_- 같은 것은 대다수가 이모티콘으로 인정하지만, -> 같은 것은 이모티콘이라고 부르지 않는 경향이 있습니다.
- 문자와 > 문자에는 화살표라는 의미가 없기 때문에, -> 조합과 화살표의 시각적 유사성에 기대어 화살표라는 새로운 의미로 "오용"한 것은 이모티콘의 구성 원리에 해당합니다. 하지만 화살표는 인간의 특정한 정서(emotion)에 대응하지 않으므로 이모티콘이라고는 잘 부르지 않습니다. 그렇다고 얼굴 표정을 나타내야만 이모티콘인가 하면 그렇지도 않습니다. orz 같은 것은 이모티콘으로 간주하는 경향이 있어 보입니다. 오징어를 나타내는 <:=는 이모티콘인가? 이모티콘이 맞다면, 왜 ->는 이모티콘이 아니고 <:=는 이모티콘인가? 알 수 없습니다. ㅋㅋ과 ㅠㅠ는 둘 다 정서를 나타내는데, ㅠㅠ만이 아이콘적 성질을 가지므로 이모티콘이고 ㅋ는 이모티콘이 아닌가? 알 수 없습니다. 만약 ㅋ만 이모티콘이 아니라고 한다면, ㅋ큐ㅠ 에서 큐는 이모티콘인가 아닌가?? 알 수 없습니다. 이 알 수 없음은 이모티콘의 생래적 성질입니다. 어쩔 수 없죠.
https://mathstodon.xyz/@dginev/114299575351888130
arXiv에서 개발자 채용하는데, PHP/Perl 로 작성되어있는걸 Python으로 재작성하는 단계라고
Powershell은. Net기반이라. Net 라이브러리도 가져다 쓸 수 있고 좀 더 이상하게까지 가면 C#코드를 임베딩해서 쓸 수도 있다. 어쨌든 셸 이지만 모든 것이 문자열이 아닌 납득할만한 타입이 있는 셸이다. 그리고 크로스 플랫폼도 지원한다. 하지만 몇몇 명령어는 어째 특정 경우의 동작이 괴상하고, 나중에 나온 크로스 플랫폼 버전에서만 납득 할만한 동작을 하게 하는 플래그가 제공 되기도 한다. 예를 들어 ConvertTo-Json은 json 문자열로 직렬화 해주는 명령인데, https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/convertto-json?view=powershell-7.5#-asarray 옵션이 없으면 요소가 한개인 배열의 경우 그 요소만 꺼내서 직렬화 해버린다.
