올해에 Python을 주 기술스택으로 사용하는 회사에 들어갔다보니, Java세계에서 경험하기 어려운 일을 경험하게 됩니다.

이번에 Python 3.10에서 hiredis wheel 빌드 오류를 발견하였습니다.

gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -I/usr/include/openssl11 -I/usr/include/openssl11 -fPIC -Ivendor -I/home/dhsung/.pyenv/versions/3.10.5/envs/tmp-hiredis-build/include -I/home/dhsung/.pyenv/versions/3.10.5/include/python3.10 -c src/hiredis.c -o build/temp.linux-x86_64-cpython-310/src/hiredis.o
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -I/usr/include/openssl11 -I/usr/include/openssl11 -fPIC -Ivendor -I/home/dhsung/.pyenv/versions/3.10.5/envs/tmp-hiredis-build/include -I/home/dhsung/.pyenv/versions/3.10.5/include/python3.10 -c src/reader.c -o build/temp.linux-x86_64-cpython-310/src/reader.o
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -I/usr/include/openssl11 -I/usr/include/openssl11 -fPIC -Ivendor -I/home/dhsung/.pyenv/versions/3.10.5/envs/tmp-hiredis-build/include -I/home/dhsung/.pyenv/versions/3.10.5/include/python3.10 -c vendor/hiredis/alloc.c -o build/temp.linux-x86_64-cpython-310/vendor/hiredis/alloc.o
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -I/usr/include/openssl11 -I/usr/include/openssl11 -fPIC -Ivendor -I/home/dhsung/.pyenv/versions/3.10.5/envs/tmp-hiredis-build/include -I/home/dhsung/.pyenv/versions/3.10.5/include/python3.10 -c vendor/hiredis/read.c -o build/temp.linux-x86_64-cpython-310/vendor/hiredis/read.o
vendor/hiredis/read.c: In function ‘redisReaderFree’:
vendor/hiredis/read.c:646:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int i = 0; i < r->tasks; i++) {
^
vendor/hiredis/read.c:646:9: note: use option -std=c99 or -std=gnu99 to compile your code
error: command ‘/usr/bin/gcc’ failed with exit code 1
[end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for hiredis

이 오류는 CentOS7에서 python3.10 버전으로 빌드할때 나오는것으로, 다른 배포판(CentOS 8 Stream, Rocky Linux 8, Ubuntu 20.04, 22.04 LTS)에서는 정상적으로 빌드가 됨을 확인하였습니다.

에러로그를 보고 cpython 3.10용 hiredis wheel이 없나 검색을 하였습니다.

 

New release for cp3.10 is not on pypi · Issue #121 · redis/hiredis-py

Time for a new release? Btw, travis-ci.org is dead, maybe time to move to github action and cibuildwheel?

github.com

 

그러나, cpython3.10용 hiredis wheel이 없어서 CentOS7에서 직접 wheel 빌드 어떻게 하나 고민을 했습니다.

에러를 보면 `error: ‘for’ loop initial declarations are only allowed in C99 mode` 메시지가 나옴을 확인하였습니다.

이 에러를 해결을 어떻게 할까 stackoverflow로 검색을 하니 다음의 링크를 발견하였습니다

 

How to use make and compile as C99?

I'm trying to compile a linux kernel module using a Makefile: obj-m += main.o all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname...

stackoverflow.com

 

즉, CentOS7에서 python 3.10용 hiredis 2.0.0 wheel 생성을 하려면 환경변수에 `CFLAGS=-std=c99` 를 추가해야합니다.

환경변수에 `CFLAGS=-std=c99` 를 추가한 결과, cpython3.10용 hiredis wheel 빌드 및 생성 성공하였습니다.

 
 
 
Buy me a coffeeBuy me a coffee

CentOS 7에서 Python 3.10 이상 버전 사용하기 전 OpenSSL 1.1.1을 RPM으로 설치하는 방법

PEP644 문서에는 Python 3.10 이상부터 OpenSSL 1.1.1 이상을 요구하고 있습니다.

PEP 644 — Require OpenSSL 1.1.1 or newer 

https://peps.python.org/pep-0644/

 

PEP 644 – Require OpenSSL 1.1.1 or newer | peps.python.org

PEP 644 – Require OpenSSL 1.1.1 or newer PEP 644 Title Require OpenSSL 1.1.1 or newer Author Christian Heimes BDFL-Delegate n/a Discussions-To https://discuss.python.org/t/pep-644-require-openssl-1-1-or-newer/5584 Status Final Type Standards Track Create

peps.python.org

 

그러나, 여러 대기업, 관공서등에서 CentOS 7을 아직도 많이 사용을 하고 있고, CentOS 7은 OpenSSL 1.1.1이 아닌 OpenSSL 1.0.2가 설치되어있습니다.

$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017

CentOS 7에서 Python 3.10을 사용하고 싶은데, OpenSSL 1.1.1이 설치가 되지 않아 소스 컴파일하여 사용해야 하나 이런 고민을 많이 했습니다.

그러나, 일본의 파이썬 개발자가 공유한 글을 보고, CentOS 7에서 OpenSSL 1.1.1을 소스 컴파일이 아닌 RPM설치로도 가능하다는 걸 알게 되었습니다.

아래는 일본 파이썬 개발자가 작성한 글 “Python 3.10の新機能(その8) OpenSSL 1.1.1が必須に”[번역: Python 3.10의 신기능(8번째 부분) OpenSSL 1.1.1이 필수임] 입니다.

 

Python 3.10の新機能(その8) OpenSSL 1.1.1が必須に - python.jp

Pythonでは、https通信やメッセージダイジェストの作成などの暗号関連機能に、OpenSSLを利用しています。 これまで、Pythonでは OpenSSL のVersion 1.0.2以降が利用可能でしたが、Python 3.10からは、OpenSS

www.python.jp

여기에서는 CentOS 7에서 OpenSSL1.1.1을 설치하려면 Fedora Project에서 제공하는 EPEL(Extra Packages for Enterprise Linux) 저장소를 추가하여 설치하면 된다고 하더군요.

다음의 명령어로 CentOS 7에서 OpenSSL1.1.1을 설치할 수 있습니다.

yum install epel-release
yum install openssl11 openssl11-devel

OpenSSL1.1.1 설치가 끝나면 아래의 명령어로 확인 가능합니다

$ openssl11 version 
OpenSSL 1.1.1k  FIPS 25 Mar 2021

pyenv로 설치 시 아래와 같이 환경변수를 지정해야 CentOS 7에서 Python을 설치할 수 있습니다

export CFLAGS=$(pkg-config --cflags openssl11)
export LDFLAGS=$(pkg-config --libs openssl11)
pyenv install 3.10.4

만약, Python을 소스 빌드로 설치하려면 아래와 같이 명령어를 입력하면 됩니다.

yum install epel-release
yum install openssl11 openssl11-devel
export CFLAGS=$(pkg-config --cflags openssl11)
export LDFLAGS=$(pkg-config --libs openssl11)
./configure
make
sudo make install

여담으로, 3월 24일에 예정된 일정 이전에 Python 3.10.4 및 3.9.12 버전이 출시되었다고 글이 공개되었습니다.

Python 3.10.4 and 3.9.12 are now available out of schedule

https://blog.python.org/2022/03/python-3104-and-3912-are-now-available.html

 

Python Insider: Python 3.10.4 and 3.9.12 are now available out of schedule

Did anybody say cursed releases? Well, it turns out that 3.10.3 and 3.9.11 both shipped a regression which caused those versions not to build on Red Hat Enterprise Linux 6. While this 11-year-old version is now out of maintenance support, it’s still used

blog.python.org

글 내용을 보면, “Red Hat Enterprise Linux 6”에서 Python3.10.3 및 3.9.11 버전이 빌드가 되지 않는 문제 때문이라고 하더군요. RHEL(Red Hat Enterprise Linux) 6은 11년 전에 출시되었고, 이제는 유지보수 지원이 끝났습니다만, 많은 사무 업무분야에서 여전히 많이 사용되고 있다고 합니다. 게다가 자체 manylinux2010 이미지는 CentOS 6을 기반으로 합니다….

아직도 RHEL 6/Cent OS6기반으로 이미지를 사용하는 경우도 많군요

 

보안 이슈때문에 라이브러리를 새로 바꿔줘야 하는데 Legacy(낡은 것)를 뺄 수가 없으니, 버리는 것이 쉽지 않다는 걸, CentOS 7에서 Python 3.10(지금 기준 — 3.10.4)을 설치하며 알게 되었습니다.

ps.CentOS 7에서 pyenv 로 3.11-dev설치할때도, OpenSSL1.1.1에 대한 환경변수 설정 후에 설치를 해야 정상 설치 됩니다.

export CFLAGS=$(pkg-config --cflags openssl11)
export LDFLAGS=$(pkg-config --libs openssl11)
pyenv install 3.11-dev

참고: PEP(Python Enhancement Proposal)는 “파이썬 언어의 개선된 제안”으로 번역하며, 파이썬 커뮤니티에서 수많은 사람들이 의견을 내고 토론하고 발전하며 논의된 주제를 PEP(Python Enhancement Proposal)로 문서화를 하였습니다 

출처: https://wikidocs.net/21733

 

 

1) PEP

## PEP 파이썬 창시자 귀도를 중심으로 수많은 사람들이 기여해서 발전해온 언어입니다. 귀도라는 최종 결정권자 혹은 그리고 결정을 하는데 가장 큰 영향력을 끼치는 독재 ...

wikidocs.net

 

Buy me a coffeeBuy me a coffee

MS사의 우리말 번역 가이드 링크 

Top 10 Tips for Microsoft Translation into Korean

https://docs.microsoft.com/en-us/globalization/localization/ministyleguides/mini-style-guide-korean

 

Korean Localization Style Guide - Globalization

Are you helping with translation into Korean, but don't have time to study all aspects of the Korean Style Guide on the Microsoft Language Portal? Here are ten of the most important aspects to keep in mind.

docs.microsoft.com

현지화 스타일 가이드

https://www.microsoft.com/ko-kr/language/StyleGuides

(Localization의 MS사의 번역어인 "현지화"보다는 "지역화"라는 낱말을 좋아합니다.)

 

아마, 리브레오피스(LibreOffice)의 번역 관련으로 MS사의 번역 가이드로 번역하는 것이 최선이지 않을까 한다.

그렇다고 한글(HWP)보다는 MS사의 오피스 기능에 더 가까운 게 많다보니 HWP의 용어를 그대로 쓰는 것이 완전히 와닿지 않음 

Buy me a coffeeBuy me a coffee

이번에 Apple M1탑재된 MacBook Air를 구입하였습니다.



Apple M1 구입후, 초기 설정을 열심히 하였습니다.


초기 설정후, Xcode와 Homebrew를 설치하여, 소프트웨어 빌드 설정을 하였습니더.

Brew 링크
https://brew.sh/

Homebrew

The Missing Package Manager for macOS (or Linux).

brew.sh

개발 환경 설정을 한후에, 예전에 Intel기반의 Macbook Pro 2013 Late에서 설정했던 LODE를 이용하여 빌드 환경을 설정하였습니다.
https://wiki.documentfoundation.org/Development/lode
빌드 환경 설정이 완료되어서 core (LibreOffice의 빌드 소스) 디렉토리로 이동하여, 다음의 명령어로 빌드를 실행하였습니다.

./autogen.sh --with-locales="ko en-US zh ja" --with-vendor="DaeHyunSung" --disable-werror --with-lang="ko en-US ja zh-TW zh-CN" --enable-dbgutil

그런데, 빌드 설정이 실패하였습니다.

configure: error: in `/Users/sungdaehyun/dev/lode/dev/core':
configure: error: online update or breakpad/crashreporting are enabled, but no --with-privacy-policy-url=... was provided

해당 이슈에 대해서 왜 나오는지 이유를 알 수 없어, 내용을 IRC로 문의를 하니 다음과 같은 답변을 받았습니다.

10:25 PM <dhsung> Hello 
10:25 PM <dhsung> Today, I bought new Apple M1 MacbookAir. So, I prepare autogen option for build. But, I found the message "online update or breakpad/crashreporting are enabled, but no --with-privacy-policy-url=... was provided" What is mean? 
10:26 PM <mst___> either disable those features or use an arbitrary value for the url, it's just shown in a dialog somewhere

답변을 듣고, 구글링을 하고는 빌드 옵션 --disable-breakpad --disable-online-update를 추가하였습니다.

./autogen.sh --with-locales="ko en-US zh ja" --with-vendor="DaeHyunSung" --disable-werror --with-lang="ko en-US ja zh-TW zh-CN" --enable-dbgutil --disable-breakpad --disable-online-update

옵션 추가 후, 빌드 설정이 완료됨을 나왔습니다.


To build, run:
/Users/****/dev/lode/opt/bin/make

To view some help, run:
/Users/****/dev/lode/opt/bin/make help

After the build has finished successfully, you can immediately run what you built using the command:
open instdir/LibreOfficeDev.app

If you want to run the smoketest, run:
/Users/****/dev/lode/opt/bin/make check

HOST config (config.warn)
*************************************
* WARNING : Cannot find Clang headers to build compiler plugins, plugins disabled.

이후에 make로 빌드를 실행하였습니다.

Apple M1에서 빌드가 완료되고, 다음과 같이 빌드 완료된 프로그램 실행을 해보았습니다.

open instdir/LibreOfficeDev.app

실행이 아주 잘됩니다!

여기까지, Apple M1에서 LibreOffice(리브레오피스) 빌드 및 실행해보기 기록이였습니다.

Buy me a coffeeBuy me a coffee

2020년 12월 14일 새벽

뜬금없이 2020년 백엔드(Back-End), 데브옵스(DevOps), 프론트엔드(Front-End) 개발자 로드맵 내용이 페이스북에서 조회가 되서 차근차근 읽어보았다. 

회사일로 바쁘다보니, 최신 신기술에 대한 내용 습득이 쉽지 않다는걸 느끼고, 많이 부족하다는 걸 느낌.

그렇지만, 이거 보고 채용 관련 면접 문제 내는데 도움이 될듯?

회사에서 주로 백엔드(Back-End)를 주로 개발하면서 데브옵스(DevOps)내용도 좀 알지만, 프론트엔드(Front-End)는 10여년전에 사회생활때 다룬 jQuery 기술 이것만 쓰니 발전이 없다는걸 느낌.

 

코로나 덕에 새로운 AMD Ryzen3 르누아르(Renoir) CPU 및 Nvidia GPU 탑재 노트북을 사고, 대형 모니터 22인치와 17인치 모니터 연결하여 쓰는 재택근무환경 구축으로, 이제 집에서 열심히 모르는 내용을 2020년 말 유종의 미를 거두기 위해서 열심히 시간 날때마다 자투리로 공부를 해야할것 같음.

 

2020 백엔드 개발자 로드맵 velog.io/@exploit017/2020-%EB%B0%B1%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A1%9C%EB%93%9C%EB%A7%B5

 

2020 백엔드 개발자 로드맵

https://github.com/devJang/developer-roadmap/blob/master/pdf/backend.pdf

velog.io

 

 

2020년 백엔드(Back-end) 개발자 로드백 PDF 한국어 번역 파일 

github.com/devJang/developer-roadmap/blob/master/pdf/backend.pdf

 

devJang/developer-roadmap

2020년 웹 개발자가 되기 위한 로드맵 :kr:. Contribute to devJang/developer-roadmap development by creating an account on GitHub.

github.com

2020년 데브옵스(DevOps) 개발자 로드백 PDF 한국어 번역 파일 

github.com/devJang/developer-roadmap/blob/master/pdf/devops.pdf

 

devJang/developer-roadmap

2020년 웹 개발자가 되기 위한 로드맵 :kr:. Contribute to devJang/developer-roadmap development by creating an account on GitHub.

github.com

2020년 프론트엔드(Front-end) 개발자 로드백 PDF 한국어 번역 파일 

github.com/devJang/developer-roadmap/blob/master/pdf/frontend.pdf

 

devJang/developer-roadmap

2020년 웹 개발자가 되기 위한 로드맵 :kr:. Contribute to devJang/developer-roadmap development by creating an account on GitHub.

github.com

참조한 내용

www.facebook.com/finereportkorea/posts/206365954287198

 

Facebook에 로그인

메뉴를 열려면 alt + / 키 조합을 누르세요

www.facebook.com

 

Buy me a coffeeBuy me a coffee

gnome-builder에서 gnome SDK, Platform등이 설치 안될때

Flatpak 설치 확인후, Flatpak에서 직접 org.gnome.Sdk, org.gnome.Platform 런타임 을 설치해본다.

$ flatpak install org.gnome.Platform
$ flatpak install org.gnome.Sdk     
Buy me a coffeeBuy me a coffee

올해 10월 동안 열리는 핵토버페스트(Hacktoberfest)행사가 시작되었습니다.

핵토버페스트(Hacktoberfest) 2020 - https://hacktoberfest.digitalocean.com/

핵토버페스트(Hacktoberfest)는 매년 10월 한달동안 열리는 행사이며, 온 세상의 어느 누구든 참여할 수 있는 행사입니다. 

이 행사는 개발자, 학생, 행사 주최자, 여러 규모의 크고 작은 회사 등등 모두가 자유오픈소스 프로젝트의 성장을 돕고, 공동체에 긍정적인 공헌(貢獻)/기여(寄與)/컨트리뷰션(Contribution)을 하도록 촉진하는 행사입니다.

다양한 배경과 기술 숙련도를 가진 모든 이들이 도전 가능하며,  이 글을 작성하는 오늘인 10월 1일부터 10월 31일까지 Github에 호스팅된 공개 저장소/프로젝트에 보내는 풀리퀘스트(Pull Request)에 대해서 인정됩니다.

이 글을 작성하는 저는 올해 열리는 핵토버페스트(Hacktoberfest) 행사에 리브레오피스 우리말 모듬(LibreOffice Korean Team)의 저장소에 자동 교정 내용을 담은 저장소를 추가하였습니다.

github.com/libreoffice-kr/autocorr_kr

 

libreoffice-kr/autocorr_kr

리브레오피스(LibreOffice) 자동 교정(Autocorrect)기능에 대한 말모이 저장소 - libreoffice-kr/autocorr_kr

github.com

올해 열리는 핵토버페스트(Hacktoberfest)에 리브레오피스(LibreOffice)에서 사용하는 우리말 자동 교정 내용 추가하면서 행사 참여를 해보아요!

이번에 리브레오피스 우리말모듬에서는 핵토버페스트(Hacktoberfest)의 행사에 참여하는 분을 위하여, 우리말 자동 교정 저장소를 만들고, 행사 참여할 수 있게 풀리퀘스트(Pull Request)를 전달하면 행사 참여 인정을 할 수 있게 이벤트를 만들었습니다.

 

열심히 자동 교정 내용을 추가하여, 리브레오피스(LibreOffice)의 우리말 사용성 향상에 공헌(貢獻)/기여(寄與)/컨트리뷰션(Contribution)을 해보아요!

Buy me a coffeeBuy me a coffee

올해 처음으로, 대한민국 과학기술정보통신부에서 주최하고 NIPA(정보통신산업진흥원)에서 주관하는 오픈소스 프로젝트 지원 사업인 "오픈소스 컨트리뷰톤 2020"에 "LibreeOffice 한국어 사용성 향상 및 공헌자 양성 프로젝트" 멘토(Mentor)로 참여를 하였습니다.

이 행사에 처음 참여하였고, 참가 후기를 정리하여 공개합니다.

컨트리뷰톤(Contributon)은 공헌(貢獻), 기여(寄與), 컨트리뷰트(Contribute)와 마라톤(Marathon)의 합성어로 6주간 자유 오픈소스 소프트웨어 프로젝트에 참여, 공유, 오픈, 협업하여 다양한 방식의 기여(Contribute)를 직접 경험하는 프로그램이라고 소개를 하더군요. 이 행사는 2016년부터 시작된 행사라고 합니다.

올해의 "오픈소스 컨트리뷰톤 2020"이 2016, 2017, 2018, 2019년에 이어 5번째로 열리는 행사라고 하더군요.

더보기

첨언. 저는 국가에서 Open Source Software를 "공개 소프트웨어"로 번역하여 사용하는 것에 대하여 좋게 보지 않습니다.

그 이유는, 번역어 "공개 소프트웨어"에서 "Source"가 빠져있기 때문에 실행파일만 공개하면 되는 것이 아닌가란 오해를 사기 쉽기 때문입니다.

그래서, "Source"에 대한 번역 낱말이 빠져있기 때문에, 저는 OSS(Open Source Software)에 대해서 "공개 소프트웨어" 또는 "공개 SW" 대신 오픈소스 소프트웨어 혹은 "공개 원천 소프트웨어"(북한은 Open Source Software에 대하여 "공개 원천 쏘프트웨어"로 번역함)으로 부르겠습니다.

참고 2. "Open Source Software"를 "공개 소프트웨어"로 번역하면 "Open Source"에 대한 번역을 "공개(Open)"로만 번역을 해야 하는 문제가 있음. 

English(영어, 英語): Open Source

Korean(한국어): 오픈소스/공개 원천

Japanese(일본어, 日本語): オープンソース

Traditional Chinese(중국어 번체, 繁體中文): 開源 / 開放原始碼

Simplified Chinese(중국어 간체, 简体中文): 开源 / 开放原始码

ps. 개인적인 의견입니다.

 

해당 행사의 주최는 과학기술정보통신부(科學技術情報通信部, Ministry of Science and ICT), 주관은 정부통신산업진흥원(情報通信産業進興院, National IT Industry Promotion Agency, NIPA), 후원(Sponsor)으로는 Microsoft(MS Korea), LINE, 카카오(Kakao), 가비아(gabia), 네이버(NAVER), SK텔레콤(SK Telecom), 래블업(LABLUP), 넥스클리퍼(NexClipper)등의 회사가 참여하였습니다. 

 

준비단계

스프린트서울(SprintSeoul) 행사 참여를 하다 보니, 어느 분께서 스프린트 서울 프로젝트 참여하시는 분께서 "2020 오픈소스 컨트리뷰톤" 행사에 멘토로 참여하는 것에 대해서 어떻나는 글을 보았습니다.

2020년 04월 09일  22:12 : 올해도 컨트리뷰톤 2020을 한다고 합니다. 작년에 멘토로 참가하였을 때는 꽤 괜찮은 느낌을 받은 대회였습니다. (개최 측 멘토 배려측면에서) 
www.oss.kr/notice/show/89192428-ebf7-4de9-93a7-35caf76a1f4b
 

[2020 오픈소스 컨트리뷰톤] 프로젝트(멘토) 모집 안내 - 공개SW 포털

 

www.oss.kr

혹시 프로젝트 리드하시는 분들 중에서 관심있는 분이 있으실 것 같아 여기에 공유를 합니다. :)

 

참고: 스프린트 서울(Sprint Seoul): www.sprintseoul.org/

 

SprintSeoul - Go further together

오픈소스 프로젝트의 작성자 또는 기여자와 함께 짧은 시간 동안 함께 문제를 찾고 해결하며, 해당 오픈소스 프로젝트에 대해 보다 깊게 알아가는 행사입니다.

www.sprintseoul.org

 

위의 내용을 보고, "2020 오픈소스 컨트리뷰톤"행사 내용을 보니 행사 취지가 좋게 느껴지더군요. 다른 정부과제와 다르게 멘토를 배려한다는 측면이 있다는 글을 보고 참여를 결정하게 되었습니다.

2020 오픈소스 컨트리뷰톤 행사 프로젝트(멘토) 모집

 

멘토 신청 및 제안서 작성 

멘토 신청을 진행하려고 했습니다. 그런데 신청 양식이 hwp와 docx 및 pptx(MS사의 OOXML규격)입니다. 

다행히, 리브레오피스(LibreOffice)는 OOXML규격의 docx 파일 및 pptx을 지원을 하여 신청서를 작성하는 데는 큰 문제가 없었다는 아니고, Windows의 docx파일에 hwp포맷에서 주로 사용하는 글꼴을 적용이 되었습니다.

Windows와 다르게 MacOS 및 Linux를 사용하는 사람으로서 리브레오피스(LibreOffice)에서 한글 글꼴이 깨지는 현상은 감안하고 문서 작성을 하였습니다.

참가신청서 양식이 MS사에서 밀고 있는 OOXML규격의 docx, HWP으로 참가신청서를 작성해야함

 

작년과 올해에 컨트리뷰톤 행사에 참여한 mocha 프로젝트의 리더의 경우도 hwp, doc 등으로 보고서를 받는 것에 대해 문제제기를 하였습니다.

twitter.com/Outsideris/status/1261301179641819137

 

Outsider on Twitter

“오픈소스 지원 프로그램에서 보고서를 PDF로는 받지 않고 .hwp나 .doc으로만 받겠다는 것도 참….”

twitter.com

https://twitter.com/Outsideris/status/1261301179641819137

위의 내용을 보고, 리브레오피스(LibreOffice)가 선정되면 정부기관인 NIPA가 ODF 포맷으로 문서를 공개할까란 생각을 했습니다만 꿈같은 소리...

NIPA에서 HWP, DOC 기준으로 문서를 작성하다 보니 ODF로 문서를 만들 생각은 안 하는 듯합니다.

 

어튼 doc파일로 신청서를 리브레오피스(LibreOffice)에서 작성하였습니다.

프로젝트 이름을 무엇으로 지을까 고민을 했습니다만, 정직하게 "LibreeOffice 한국어 사용성 향상 및 공헌자 양성 프로젝트"라고 이름을 지었습니다.

다행히, 리브레오피스(LibreOffice)의 OOXML형식의 호환성 지원은 상당한 수준이라 편집하고, 주최 측에 전달을  일단 해보았습니다.

그리고, 혼자서 고민도 안 하고 회사일 하느라 바쁜데 준비과정 없이 신청하였고, 리브레오피스(LibreOffice)로 작성을 하였다 보니 호환성이 안 맞아 내용이 깨져서 주최 측에서 서류 탈락으로 처리하여 떨어질 수 있을 거란 생각을 했습니다.

그러나, 프로젝트 선정(무려 26개 프로젝트)이 되었습니다.

제가 참여한 프로젝트가 아닌 다른 프로젝트(25개 팀)를 보니 쟁쟁한 프로젝트들이 있어서 엄청 걱정했습니다.

이후, 참가자 선정 관련으로 주최 측에서 프로젝트 소개 등을 요구하였습니다.

그런데, pptx 포맷으로 전달받아서 pptx로 작성하였습니다.

전달받은 양식이 MS사에서 밀고 있는 OOXML규격의 pptx

MacOS에서 네이버의 Nanum Square 글꼴 설치 전의 리브레오피스(LibreOffice)의 프로젝트 소개 슬라이드 보기 

MacOS에서 네이버의 Nanum Square 글꼴 설치 후의 리브레오피스(LibreOffice)의 프로젝트 소개 슬라이드 보기 

컨트리뷰톤 시작 전부터 글꼴 fallback 버그를 발견하니 이거 컨트리뷰톤 진행하면 대박 터질 것 같은 느낌이 들었습니다.

실행할 때부터 버그를 발견하고, 리브레오피스(LibreOffice)의 버그질라(Bugzilla)에 보고하면 엄청난 큰 수확이 되지 않을까란 생각을 했습니다. (이미 리브레오피스를 직접 사용해본 사용자라면 한국어 사용할 때 버그는 확실히 보입니다.)

거기에, 몇 년 동안 소프트웨어의 번역도 누락된 것도 꽤 크고, 위키의 한글 문서화도 제대로 되지 않았다 보니, 여기서 참여하면 리브레오피스(LibreOffice)라는 프로젝트가 전 세계에서 유명한데, 한국에서도 이름이 알려질 수 있고, 이 행사에서 아무리 못해도 "장려상"을 받을 수 있지 않을까란 꿈같은 생각을 해보았습니다.

(그러나, 꿈은 꿈일 뿐 진행해보면서 회사일 하면서 시간 쪼개면서 하다 보니 전달력이 부족하다는 것을 느꼈음. 내가 생각한걸 다른 사람에게 전달하려면 정말 부단히 시간 투자를 해야 하는 것을 느꼈음.)

"LibreeOffice 한국어 사용성 향상 및 공헌자 양성 프로젝트"이란 제목에서 저의 의도는 리브레오피스(LibreOffice)의 한국어 사용성 향상을 위해서 버그 발견으로 멘티들이 버그를 많이 발견하고  보고를 하는 것을 생각하였습니다. (그 이유는 제가 리브레오피스 사용하다 보니 한국어 사용 관련으로 꽤나 많은 버그를 확인하였으나, 회사 다니면서 바쁘게 살다 보니 제대로 보고를 안 한 버그가 꽤 상당함)

그러나, 저의 의도와 다르게 버그 발견 및 보고에 대해선 생각보다 활동이 많이 저조했던 것에 대해서 아쉬웠습니다.  그러나, 코로나19(COVID-19)로 약 3주가량만 오프라인 미팅을 하였고, 나머지 3주를 온라인 미팅으로 진행하다 보니, 면대면(face to face)가 아닌 온라인으로 컨트리뷰션을 알리는 것이 쉽지 않은 과정임을 알게 되었습니다.

멘티 선정

프로젝트 멘토 선정 이후에, 주최 측에서 멘티 모집 공고를 냈습니다

멘티 모집 공고 관련으로 트위터와 페이스북에 홍보를 하였습니다.

멘티 선정은 신청받은 사람 대부분 수락하였습니다. 처음 진행을 하는 것이라 보니, 멘티 선정을 어떻게 해야 하는지에 대한 걸 알 수가 없었고, 일단 뽑고 대학생의 수준이 어디까지인지 확인해야 알 수 있기 때문에 거의 대부분 묻지마 선정을 하였습니다

참가지원서에서 간단한 자기소개, 지원동기, 프로젝트 개발 경험을 공개했는데 개발 경험이 학교 과제로 간단하게 한 수준이기 때문이기 때문에 자유 오픈소스 프로젝트(FLOSS)에 관심 있으면 무조건 선정했습니다.

자기소개에 앱 개발하면서 돈을 벌기 위해서나 돈과 창업을 목적으로 한다 등 상업적으로 나가는 자기소개서를 작성한 경우가 아닌 이상, 대학생과 회사원 모두 선정하였습니다. 

이 부분에서 후회되는 건, 선정된 분들의 수준을 전혀 모르고 뽑다 보니 진행이 조금 난감한 경우가 있었습니다. (뭐 이런 프로젝트가 처음이라 어찌 되든 잘 되겠지 생각을 하였습니다.)

멘티 선정 고민의 결과로 상업(돈, 창업)을 목적으로 한 사람들 제외하고 대부분 선정하였습니다.

이번 경험을 토대로 내년에 열릴 정부의 오프소스 소프트웨어 지원사업인 컨트리뷰톤에 멘티 선정 때 고려를 많이 해야 할 것 같습니다.

멘티 선정 이후, 주최 측에서 ZOOM으로 26개 프로젝트의 멘토들을 모아서 컨트리뷰톤에 대한 내용에 대하여 설명하였습니다.

이때 왜 ZOOM으로 컨퍼런스를 여는 것에 대하여 좀 이해가 되지 않았습니다. (오픈소스 프로젝트 및 기여자(寄與者)/공헌자(貢獻者)/컨트리뷰터(Contributor)를 후원하는 정부기관에서 보안 이슈가 있는 Zoom을 사용하는 것이 좀 꺼림칙했었음)

발대식

주최 측에서 코로나19(COVID-19)여파로 발대식은 4번에 나눠서 진행하였습니다. 저는 욕심이 엄청 과하여 8월 1일 시작 전에 발대식을 진행을 해보았습니다.

발대식에서 선정한 멘티분들을 만나게 되었습니다. 저와 같이 오픈소스 프로젝트 기여(寄與)/공헌(貢獻)/컨트리뷰션(Contribution)을 할 분들을 만나 뵈어서 반가웠습니다.

그러나, 회사일이 바빠서 발대식 하기 전에 참가자(멘티)와 원활한 커뮤니케이션을 못한 것이 아쉬웠습니다.

진행

이 컨트리뷰톤 행사는 8월 1일부터 9월 14일까지 6주간 진행되었습니다. 진행하는 동안 앞서 3주 동안은 주말에 면대면(face to face), 오프라인 모임 및 온라인 모임을 지속적으로 진행하였습니다.

주최 측에서는 줌(ZOOM)을 이용하는 것을 추천하였습니다. 그러나, 저는 여기서  jitsi라는 웹 기반 자유 오픈소스 프로젝트로 된 비디오 컨퍼런스, 인스턴스 메시징 플랫폼으로 온라인 컨퍼런스를 진행하였습니다.

그리고, 문의사항 및 토론으로 gitter를 사용하였습니다.

첫 3주 동안은 뭔가 잘될 것 같았습니다.

그러나 8월 15일 기점으로 갑작스러운 코로나19(COVID-19)확산으로 면대면(face to face), 오프라인 모임이 할 수 없었기 때문에 온라인으로 진행하였습니다.

면대면(face to face), 오프라인으로 모임을 하는 것도 어려웠지만, 온라인(online)으로 진행하는 것은 생각보다 매우 어려웠습니다.

그리고, 다른 사람을 가르치려면 정말 준비를 많이 해야 하는데, 회사일도 바쁘고, 다른 프로젝트와 다르게 혼자 멘토로 참여하다 보니 시간이 지날수록 몸이 피곤해짐을 느꼈습니다.

그리고 회사일이 바빠진 데다, 대학생 참가자분들이 9월 1일 기점으로 개학을 하다 보니 연락이 힘들었습니다

적극적인 직장인 분과 학생 몇 분 제외하고는 거의 피드백(feedback)을 받지 못하여 전달이 되는 건지 진행을 하는 건지 확인할 길이 없었습니다.

저도 회사일이 바빠서 8월 후반부터 컨트리뷰톤관련 기여에 대하여 일일이 챙기지 못한 것을 아쉬워합니다.

 

그리고 8월 후반부터 온라인으로 진행하다 보니, 제가 사용하는 2013년도형 맥북프로(Mac book pro 2013 Late)의 성능이 부족한 데다, 2013년도에 생산된 HP랩탑이 구형에다 GPU 성능이 좋지 않아서, jitsi를 이용한 화면 공유가 원활히 되지 않은 이슈를 확인하였습니다. 그래서 결국, CUDA 연산이 되는 GPU 달린 새로운 게이밍 랩탑을 구매하여 진행하였습니다.

새로운 랩탑 구매 후에 저 나름대로, 기존보다  빌드가 빨라져서 컨트리뷰션 관련 소스코드 리뷰를 빨리 할 수 있어 편리하더군요. 그리고 jitsi 화면 공유가 원활히 되는 것을 보며, 온라인으로 뭘 하려면 기기 투자가 중요하다는 걸 느꼈습니다.

중간평가

중간평가 시에는 몇 분이 도중에 포기한다고 하였습니다. 멘티들이 제가 생각한 대로 따라가기 어렵다고 느꼈고요.

9월 16일 부로 공식적으로 멘티들의 컨트 리뷰톤 행사 진행이 끝났습니다. 그래서 메일로 결과 서류 관련으로 작성 및 공유를 하였습니다만 몇몇 분들 빼고는 피드백이 없어서 답답하였습니다. (그 이유는 온라인으로 진행하다 보니 관심도가 떨어졌고, 9월 1일 기점으로 대학생들의 2학기 개강으로 참여도가 많이 떨어짐)

 

컨트리뷰톤 결과

리브레오피스 QA/쉬운 해킹(LibreOffice Easy Hacks)에 한국어에 대한 자동교정(Auto correct) 확장 추가

wiki.documentfoundation.org/QA/Easy_Hacks

버그질라

[ko] Extend Autocorrect list for Korean language

bugs.documentfoundation.org/show_bug.cgi?id=135727

 

135727 – [ko] Extend Autocorrect list for Korean language

Reported: 2020-08-13 17:40 UTC by DaeHyun Sung Modified: 2020-09-21 18:49 UTC (History) CC List: 1 user (show) mentoring See Also: Crash report or crash signature:

bugs.documentfoundation.org

소스코드 기여 관련

자동 교정 내용 추가 및 리브레오피스의 단위 테스트(Unit test)의 파이썬 관련 소스코드 수정 등이 있었습니다.

현재, 소스코드 기여 관련으로 huspell-ko의 한국어 맞춤법 기능 적용 관련으로 커미터에게 적용 요청을 하고 있습니다.

꾸준히 위키 번역을 해주신 분이 계셨습니다. 다음에 매 5월 및 11월에 리브레오피스 스티커를 받는 행사를 소개하고 번역에 대해 열중하도록 독려를 해드려야 할 것 같습니다.

소프트웨어 번역 관련으론 꾸준히 하시는 분들이 적어서 불만이긴 합니다. 이 부분은 제가 독려를 하고 계속 푸시를 했어야 하는 점이 있는데, 회사 일이 바빠서 번역 관련으로 못 챙긴 것이 아쉽습니다.

 

1차 서류 평가

8월 16일 이후 온라인으로 진행하다 보니, 대부분의 많은 기여(寄與)/공헌(貢獻)/컨트리뷰션(Contribution)이 8월 1일부터 3주간 동안만 진행되었습니다. 후의 3주간은 다들 강의를 들어도 시간 투자를 많이 못해서인지 참여도가 확실히 떨어지는 문제가 있었습니다.

서류 평가는 생각보다 후하게 받은 것 같습니다. 26개 팀에서 상위 18개 팀 선정이 된 것에 놀라웠습니다.

 

2차 발표평가

발표 평가 관련으로 발표자료 정리하여 메일을 전달하였으나, 발표자로 진행하려는 사람이 없었습니다. 대부분 메일 답변하는 사람이 없었습니다. 다행히, 가까스로 발표평가 관련으로 멘티 선정을 하였습니다

발표 평가는 온라인(ZOOM)과 26개 팀에서 선정된 상위 18개 팀의 멘토가 참여하여 평가를 진행하였습니다.

참, 이 행사에서 주최 측이 ZOOM을 엄청 좋아하더군요.

줌(ZOOM)의 보안 이슈가 있는데도 행사 시작부터 끝까지 ZOOM으로 진행하는 것이 뭐랄까 뭔 똥고집인가란 생각을 하였습니다. 

참고로 Zoom은 보안 이슈가 있다 보니, 대만(臺灣, Taiwan)에서는 Zoom을 사용 금지를 하였습니다.

대만(臺灣, Taiwan)의 디지털 장관인 오드리 탕(唐鳳)씨는 대만 교육부에서는 상용 프로그램인 CyberLink U Meeting, Microsoft Teams, Cisco WebEx, Adobe Connect, Google Hangouts Meet과 자유 오픈소스 프로젝트인 Jitsi meet 등을 사용한다고 소개하였습니다.

twitter.com/audreyt/status/1247451325622702081

 

Audrey Tang 唐鳳 on Twitter

“@ral_liou 教育部建議,學校可採用CyberLink U Meeting、Microsoft Teams、Cisco WebEx、Adobe Connect、Google Hangouts Meet 及開源的 Jitsi Meet 等軟體。 教育部將陸續製作相關使用說明手冊及教學影片,放在教育雲�

twitter.com

정부 기관이 보안 이슈가 있는 Zoom을 사용하는 것에 대하여 고민이 없는 것 같고, 후원사인 MS사에서 Teams를 왜 밀지 못하는가란 생각이 들었습니다. (제가 이 행사 담당자라면 Zoom을 제외하고 MS Teams, Google Hangouts meet을 사용할 것 같습니다. 최소한이라도 오픈소스 프로젝트에 관심 있는 기관이었으면 jitsi등의 컨퍼런스 관련 오픈소스 프로젝트를 사용하는 것에 대하여 최소한 고민을 한 흔적이라도 있어야 하는데 아쉽습니다)

 

어튼, 아래 사진은 발표 평가 장소에서 찍었으며, 저는 심사위원으로 참여하였습니다.

다음에는 발표자를 미리 선정후, 직접 발표 교육을 시켜야 할 것 같았습니다.

 

결과

어튼, 특별상은 받았습니다. 

특별상을 받은 기념으로, 참여한 멘티에게 기프티콘을 전달 및 수상 관련 메일을 전달하였습니다. 그러나 대다수의 멘티가 이제 리브레오피스 컨트리뷰션에 대한 관심이 사라졌는지 제가 메일 전달한 것에 대한 답변은 정말 별로 없네요...

이 행사를 통해서 한국의 오픈소스 커뮤니티에 리브레오피스(LibreOffice)가 있다고 이름 정도는 알린 것에 대하여 의의를 두었습니다.

욕심대로라면 컨트리뷰션을 하는 사람을 많이 만들려고 했습니다. 그러나 제가 리브레오피스를 왜 사용해야 하는지 이유등 의도를 제대로 전달을 못하였다는 문제를 확인하였습니다. 그래도 리브레오피스(LibreOffice)에 관심 많은 사람 몇 명을 찾은 것은 다행이라고 봅니다. 다음에는저의 의사전달 능력을 키워야 할것 같습니다.

 

후기 정리

1. 이번 컨트리뷰톤(Contributon)을 진행하면서, 회사일 하면서 다른 사람을 가르치는 일이 엄청 벅찼음. 작년에는 회사일로 거의 오전 9시부터 오후 9시까지 일하다 보니 커뮤니티 쪽으로 한 번도 챙기지 못하여 올해는 그나마 커뮤니티를 챙기려고 노력을 하였음. 어떻게 하면 커뮤니티 활성을 할까 고민하다 컨트리뷰톤행사 멘토로 진행을 해보았습니다. 일단 의도대로 리브레오피스(LibreOffice)라는 프로젝트가 있다고 이름을 알렸음.

2. 코로나19(COVID-19)이후로, 면대면(face to face)가 아닌 온라인 중심으로 진행하다 보니 일방적으로 진행한 것 같음. 멘티들이 많이 못 따라가는 걸 확인하였고 앞으로 어떻게 정보 전달을 해야 할지 고민을 해야겠음. 이 프로젝트에 포기한 사람도 몇 사람 생기고 , 따라가지 못하고 아예 잠수한 사람도 몇 명 있었음.

"LibreeOffice 한국어 사용성 향상 및 공헌자 양성 프로젝트"이란 제목에서 저의 의도는 리브레오피스(LibreOffice)의 한국어 사용성 향상을 위해서 버그 발견으로 멘티들이 버그를 많이 발견하고  보고를 하는 것을 생각하였습니다. (그 이유는 제가 리브레오피스 사용하다 보니 한국어 사용 관련으로 꽤나 많은 버그를 확인하였으나, 회사 다니면서 바쁘게 살다 보니 제대로 보고를 안 한 버그가 꽤 상당함) 그러나 저의 의도대로 버그 발견 관련으로 버그 보고가 많이 활성화되지 않은 것에 대하여 아쉬웠습니다.

그러나, 코로나19(COVID-19)로 약 3주가량만 오프라인 미팅을 하였고, 나머지 3주를 온라인 미팅으로 진행하다 보니, 면대면(face to face)가 아닌 온라인으로 컨트리뷰션을 알리는 것이 쉽지 않은 과정임을 알게 되었습니다.

오랜만에 사람들을 가르치니 정보 전달 및 강의 방식에 문제가 있다는 걸 느꼈습니다. 

참여한 멘티 대부분(거의 대학생)들이 질문도 없고 피드백에 대한 내용도 없으니 내가 전달한 내용이 제대로 이해했나는 생각이 들었음. 그러나 코로나19(COVID-19)로 인하여 제대로 의사소통을 하는 것이 어려웠기 때문에 어떻게 하면 온라인으로 의사소통을 무리 없이 할 수 있을까란 숙제가 주어짐.

3. 주최기관에서 신청서나, ODF양식이 아닌 한글과컴퓨터의 HWP 또는 MS사가 밀고 있는 OOXML의 docx, pptx를 사용. 대한민국 정부와 정보통신산업진흥원은 과연 ODF를 지속적으로 사용하려는 의지가 전혀 없어 보임. 대한민국 정부 표준으로 ODF를 선정하였으나 사용한다는 증거가 없음.

KS X ISOIEC 26300 "정보기술-오픈도큐먼트양식"이 대한민국 ODF 규격 표준입니다.

이 행사를 계기로 정부기관에 리브레오피스(LibreOfice) 소프트웨어가 있다는 걸 알림. 그러나, 정부기관 특성상 보여주기 행사나 행정을 하고 왜 ODF를 사용해야 하는지에 대한 고민이 없을 거라 다음 컨트리뷰톤에서도 ODF포맷으로 된 신청서나 결과 보고서 파일을 공유할 것이라는 보장이 없다고 봄.

4. NIPA등 여러 한국의 정부기관이 컨퍼런스 도구로 Zoom을 엄청 좋아하는 것에 대하여 우려를 하고 있습니다.

Zoom은 보안 이슈가 있다 보니, 대만(臺灣, Taiwan)에서는 Zoom을 사용 금지를 하였습니다.
대만(臺灣, Taiwan)의 디지털 장관인 오드리 탕(唐鳳)씨는 대만 교육부에서는 상용 프로그램인 CyberLink U Meeting, Microsoft Teams, Cisco WebEx, Adobe Connect, Google Hangouts Meet과 자유오픈소스 프로젝트인 Jitsi meet 등을 사용한다고 소개하였습니다

twitter.com/audreyt/status/1247451325622702081

 

Audrey Tang 唐鳳 on Twitter

“@ral_liou 教育部建議,學校可採用CyberLink U Meeting、Microsoft Teams、Cisco WebEx、Adobe Connect、Google Hangouts Meet 及開源的 Jitsi Meet 等軟體。 教育部將陸續製作相關使用說明手冊及教學影片,放在教育雲�

twitter.com

전 세계에서 Zoom의 보안 이슈 관련으로 금지를 하려는 추세인데, 오픈소스 기여자/공헌자/컨트리뷰터(Contributor)를 양성 관련으로 관심 있는 정부기관이 Zoom을 쓴다는 것에 대해서는 이상하게 보입니다. 차라리 오픈소스 jitsi 같은 플랫폼을 발굴해서 서버 구축하는 것이 좋지 않을까란 생각을 하기도 하고,  Zoom보다는 후원사로 오픈소스 프로젝트를 활성화하는 MS사의 Teams를 사용하는 것이 낫지 않을까란 생각을 할 정도였습니다.

5. 처음 참가한 행사 치고는 성과가 생각보다 많이 나서 놀랍긴 하였음. 다음에 컨트리뷰톤(Contributon)행사가 추진되면 아마 같이 보조로 활동할 분을 선정하여 진행을 해야 할 것 같습니다. 혼자는 너무 힘들었음. 다음 행사 참여를 한다면 올해보다 더 활발하게 진행할 수 있게 고민을 해야겠습니다.  그리고, 많은 사람들에게 리브레오피스의 공헌(貢獻)/기여(寄與)/컨트리뷰션(Contribution)에 대하여 지속적인 관심을 가지는 방법에 대해서도 고민을 해야겠습니다. 이런 행사만 챙기면 컨트리뷰션은 반짝하고 끝날 것이 뻔하게 보이더군요.

6. 이 행사 내용을 토대로, 10월 15일~17일 3일간 열리는 openSUSE +LibreOffice 가상 컨퍼런스에서 발표자로 참여하는데, 해당 오픈소스 컨트리뷰톤 참여 내용을 전 세계에 공유할 예정.

홈페이지: events.opensuse.org/conferences/oSLO 

 

openSUSE + LibreOffice Virtual Conference

The openSUSE and LibreOffice Projects are combining their annual conferences together for one year in 2020 to have a joint openSUSE + LibreOffice Conference. This joint conference, which is combined this one year to celebrate 10 years of the LibreOffice Pr

events.opensuse.org

10월 16일 일정: events.opensuse.org/conferences/oSLO/schedule#2020-10-16 

저는 10월 16일 UTC+0 10:30~11:00(한국시각 19:30~20:00, KST) 30분 동안 발표 예정입니다.

Buy me a coffeeBuy me a coffee

이번에 오픈수세(openSUSE)에서 Visual Studio Code를 설치해보았습니다.

참고
Visual Studio Code on Linux

설치 하기

SNAP으로 설치하기

Snapcraft의 'Visual Studio Code'

위 링크로 확인하면 됩니다.

openSUSE에서 설치하기

다음의 명령어와 스크립트로 키(Key)와 저장소(Repository)를 등록합니다.

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
sudo sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ntype=rpm-md\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/zypp/repos.d/vscode.repo'

그 다음, 저장소(repository)를 새로 고칩니다.

sudo zypper refresh

저장소(repository)를 새로 고침하면, Visual Studio Code를 설치합니다.

sudo zypper install code

설치 결과

openSUSE에서 잘 돌아감을 확인

Buy me a coffeeBuy me a coffee

Python의 우리말 번역(飜譯, Translation)은 파이선? 파이썬? 파이쏜? 정확한 우리말 번역어(飜譯語)는 뭘까요?

대한민국 특허청의 특허정보 검색 서비스 사이트인 키프리스에서는 PYCON이라는 상표를 파이콘으로 번역을 하였고, 상표출원자인 Python Software Foundation파이쏜 소프트웨어 파운데이션으로 번역하였습니다.

즉, 특허청에서는 Python파이쏜으로 번역하여 사용하고 있습니다.

Python Software Foundation(1076192), 파이쏜 소프트웨어 파운데이션(520190825203)

그러나, EBS에서 내놓은 수학과 함께하는 AI 기초에서는 Python파이선으로 번역하였습니다.

‘문제 해결하기’로 문제 해결에 필요한 데이터 수집부터 시각화까지 파이선 프로그래밍으로 처리하는 과정을 쉽게 이해할 수 있도록 Step by Step으로 구성하였습니다.

그러나, 파이콘 한국(PyCon Korea)에서는 Python파이썬으로 표기하더군요.

파이콘 한국은 한국의 파이썬 개발자들이 지식을 공유하고 만남을 갖기 위한 장입니다.

그러면, Python의 공식 우리말 번역은 무엇일까요? 파이쏜? 파이선? 파이썬?

어렵네요. Python이 한국에 소개된 지 약 20~30년이 되어가다 보니 아직까지 번역어에 대하여 혼동이 많이 있는 것 같습니다.

프로그래밍 언어 Python을 개발자들이 주로 파이썬으로 말하다보니 사실상 표준(De Facto Standard)으로 파이썬이 표준 번역어로 되어간다만요. 기존 법률상에서는 파이쏜, 공공기관에서는 된소리 표기를 회피하는 것 때문에 파이선으로 사용하다보니 검색을 할 때 상당히 혼란이 올 것으로 봅니다.

Buy me a coffeeBuy me a coffee

+ Recent posts