[Firefox] 파이어폭스 환경 이동 시 실행 오류(프로파일 구버전 오류) 경고 해소 방법

파이어 폭스 환경을 다른 곳으로 옮길 경우 종종 '구버전으로 생성된 환경'이라며 새로운 버전으로 프로파일을 새로 생성하는 청천 벽력 같은 경고가 발생하는 일이 종종 있다.

해결 방법 없나 찾아 보니 역시나 해결 방법이 있는데 

https://www.trishtech.com/2020/01/how-to-avoid-older-version-warning-in-firefox-easily/

의 사항을 참조 했다.

환경 폴더 내부에 compatibility.ini 파일을 삭제 하거나 이름을 변경한 후 다시한번 파일을 실행하면 문제가 해결됨.

[Linux] 맥북 리눅스에서 fn키 기본 설정 끄기(F1~F12 기본으로 사용하기)

맥북에 리눅스를 설치해 두고 사용할 경우 의외로 기능키(F1~F12)를 사용할 일이 많은데 문제는 기본이 이 기능키가 아닌 기능키(소리 저정, 화면 밝기 조정 등)으로 되어 있어 코딩 등에는 오히려 방해닥 되는 경우가 많다.(매번 fn키를 누르고서 기능키를 눌러야 작동 한다고 생각해 봐라 특히 상당수의 어플리케이션이 전체 화면 단축키가 F11로 잡혀 있는 경우가 많다)

그래서 기본을 기능키로 두고 fn키를 누를 경우에만 키를 작동하게끔 하고 싶다고 생각한 분들이 상당수 계시리라 생각하나 이게 키보드 설정에 가서 아무리 찾아 봐도 내용을 찾을 방법이 없다는 문제가 발생했다.

그러나 난이도가 어떠냐가 문제여서 그렇지 어디든 해결 방법이 있는 리눅스 답게 해결 방법은 있어서 여기 정리하고자 한다

전체적인 글은 아래의 링크에서 찾아 내었고 :

https://unix.stackexchange.com/questions/121395/on-an-apple-keyboard-under-linux-how-do-i-make-the-function-keys-work-without-t

전체적으로 같은 해결책을 여러 가지로 해결 해 두었기만

echo 2| sudo tee /sys/module/hid_apple/parameters/fnmode




라고 한줄 명령을 내리는게 가장 간평하고 명확한 해결 방법인듯 하다.


파이썬의 장단점

2.7버전부터 3버젼까지 책까지 사가며 공부해본 파이썬에 대해서(결국 깊은 수준까지는 단 한번도 코딩 못해 봤지만서도)느끼는 사항이 있어 글을 적어 봅니다.

장점 :
파이썬을 사용하기 전에는 자바를 사용했는데 자바를 사용하며 느낀 불편점이 사실상 파이썬의 장점이었습니다.

1)간결성 : 사실 HelloWorld를 작성하면서도 자바는 익혀야 하는게 상당히 많았습니다.(당장 System.IO는 뭔지 이걸 왜 추가해야 하는건지 등등) 그냥 습관적으로 쓰는 문구가 되어 나중에 이 뜻을 이해 해야 했지만 어째든 굉장히 단순하다는 자바(적어도 C나 C++, 특히 GUI코드쪽은 더더욱)와 비교해도 파이썬은 굉장히 단순한 언어였습니다.

2)코드의 표준성 :어떤 사람에게는 이게 약점으로 지적되는 사항이기는 한데 적어도 코드가 모두 획일된 구조를 갖는다는게 저한테는 장점이었습니다.

3)즉시 실행 : 예전에 베이직 코딩을 해보신 분들이라면 알겠지만 초기의 베이직 언어는 코딩후 그 코드를 세이브하거나 그 세이브 코드를 컴파일 하는 과정이 필요 없는 완전한 스크립 코드였습니다. 그탓에 코드를 쭉 적어준후 RUN명령어만 내려주면 즉시즉시 실행(거기에 매 라인 에러 체크까지 해주니 중간에 잘못될 가능성도 낮음)해 주니 적어도 아주 단순한 코드 기준에서는 컴파일 언어가 오히려 더 늦는(분명 작동 속도야 컴파일 언어가 압도적으로 빠르겠지만 문제는 그 코드를 작동 시키기까지의 과정이)상황이었지요. 거의 모든 스크립코드가 멸종되어 가던 시기에 이 문제(특히 컴파일 명령을 터미널에서 일일이 내려줄땐 더더욱)가 꽤나 한심하게 느껴지었는데(물론 IDE도입하며 없어졌지만) 이게 파이썬에서는 없어졌습니다.

4)패키지 설치 기본 지원 : 요즘은 별거 아닌 사항이지만, 사실 패키지를 설치하기 위해서는 해당 라이브러리를 라이브러리 사이트에 가서 다운 받은뒤 이를 설치해 주어야 합니다. 반면 파이썬의 경우 pip 혹은 easy_install이라는 좋은 툴이 있어 쉽게 인스톨 가능합니다만은...(아래 단점에서 다시 설명하겠습니다.)

5)범용 언어 : 특정 종목(수학이라든가 하는)에만 한정해 사용할수 있는 다른 언어와는 달리 파이썬 자체는 데이타 분석에서 제어, 수학, 데이타 수집, 서버의 제어언어, CAD프로그램의 스크립코드 등등 여러가지 용도로 두루 사용되고 있고 이 점이 내가 파이썬을 자바 이후의 코드로 선택하게 된 가장 커다란 이유이기도 하다.

6)ipython 특히 notebook : 파이썬 툴 중에서 ipython 특히 노트북은 거의 필수라고 해도 좋을 만큼 중요한 툴이 되었고 이거 덕분에 원거리 코딩 작업(코딩은 노트북 돌리는건 서버)도 너무나 수월해 졌음.(거기에 중간중간 설명을 하며 적을 수 있으니 나중에 보고서로 쓰기도 수월하고)

단점
1)2와 3가 서로 호환 않됨...
2버젼과 3버젼이 서로 호환이 않됨. 단순히 println문제야 양쪽에 가로 기호 추가하는걸로 끝나지만 참조한 라이브러리가 부재하는 등의 이유로(더군다나 c기반이여서 어디서 고쳐야 하는지 막막할때) 작동 도중 에러 뜨면 진짜 막막해 져서 아예 해당 패키지의 사용을 포기하는 때도 많음.


2)2에서 3로 잘 않넘어감.
이게 제일 큰 문제인데, 그럼 2에서 3로 넘어간 패키지를 설치해 주면되는거 아니냐라고 생각할 터이지만 애석하게도 상당수의 패키지가 아직도 2에서 안주하고 있습니다.
그리고 아직도 상당수의 예제 코드가 2기준으로 작성되어 있어 코드 실습 조차 쉽지가 않은게 실정입니다.


3)패키지가 잘 않설치되...
1)과 2)로 인해 파생된 문제이기는 하지만 pip로 설치 시도하다 에러뜨면 정말 멍때리게 됨... 당초 소스와 패키지가 구분이 없다시피한 파이썬이다 보니 코드를 수정해서 설치(어차피 패키지 파일이 소스 파일을 압축해 모아둔 것이다.)하기도 역시 난감해 진다. 그나마 구글링해도 이상하게 해결책이 잘 않뜨고(나만 이런거야? 응? 응?)해서 나중에는 설치 및 사용을 포기하는 경우도 많음.


4)성능
사실 용도를 생각하면 큰 문제는 아니기는 한데, 예전에 10만팩토리얼 계산때(2시절) 상당히 오랜 시간이 걸렸다는걸(그래 봤자 몇초지만) 생각하면 꽤 큰문제로 생각할 수도 있음.(근데 같은 머신에서 3버젼은 0.xx초 이내로 줄어듬...)
 거기에 멀티코어 환경에서는 GIL이라는 고전적인 문제(읽었던 책에서는 이 문제를 수치스럽다라고까지 표현했음)가 있다는 점도 이 언어의 가치를 상당히 낮추는 어려운 문제임.



그래서 바라는건

1)패키지 정리좀 하고, APT툴 수준으로 설치에 문제가 없게끔 했으면 좋겠음. 이 문제 때문에 파이썬 실습이 아예 리눅스가 더 쉬울 지경(하긴 파이썬 문제뿐만이 아니라 모든 패키지가 적어도 설치는 리눅스가 더 쉬움)이라는건 심각한 문제다.

2)멀티코어 문제좀 : 이미 성능 향상을 위해 멀티코어로 가는게 정해진지 오래인 상황에서 여전히 이 부분에 대한 수월한 지원(비록 multiprocess라는 좋은 툴이 있기는 하지만)이 요원함.

3)gui : 많은 gui툴이 있기는 하지만 여전히 쓸만하다고 보기는 어려움.

어째서 병렬 연산은 어려울까?(사견)

지금의 컴퓨터에게는 지극히 당연한 문제이기는 하지만, 과거의 컴퓨터(한 XT나 286시절?)에게 멀티프로세스라는건 정신나간 이야기나 마찬가지였습니다.

가뜩이나 모자란 자원(특히 이 당시 메모리는 굉장히 비싼 자원이었습니다.)을 여러개로 분산 시켜 사용할 여력도 없었고, 딱히 그런식으로 할 일도 없었다는 점이 그 이유였습니다. 요컨데 지금처럼 게임을 하면서 mp3를 틀어 두고 토런트로 다운을 받는다는건 생각도 할수 없을 정도의 수준의 프로세서와 메모리 뿐이었고 그런거 할 이유도 없었습니다.

 음악? 그런거야 라디오나 오디오로 듣는게 당연한 시절이었고, 책은 당연히 종이에 인쇄되어 나온것으로 읽는 것이고, 하나의 프로그램을 작동하다가 다른 프로그램을 작동 시키려면 당연히 프로그램을 종료하고 도스에서 다시 명령을 내리는게 당연한 시절이었지요.

 그런데 통신이라는 것을 하면서 처음으로 이러한 생활에 변화가 생기기 시작했습니다. 지금은 상상도 못하겠지만 2400bps(56k조차 아닙니다.)로 파일을 주고 받다 보니 다운 대기 시간이 30분을 넘기는 일이 다반사 였고 다운 받는동안 무슨일을 할수 있느냐 하면 그것도 아니였습니다. 그저 하염없이 이야기의 다운 창이 다 차기만을 하염없이 기다려야 하는 서글픈 인생이었습니다.(그리고 이 시절에 들어서서 처음으로 하드디스크가 모자를 수도 있다는 것을 경험했지요)

 그래서 이 시절에 등장한게 컴퓨터를 두대를 사용하는 방식이었는데, 주로 새 컴퓨터를 구입하면서 옛 컴퓨터를 옆에 두고서 다운로드 전용 컴퓨터로 활용하는 방법이었습니다.(이것 역시 지금 보면 정신 나간 짓으로 보이겠지만 홈서버와 데스크탑이라는 형태로 이러한 활용이 계승된 방법도 있기는 합니다.)

서론이 너무 길었는데, 이런식으로 PC의 극 초기부터 사람들은 하나의 컴퓨터로 여러 작업을 동시에 하기를 바랬고 그후 컴퓨터의 성능이 급격히 좋아 지면서 과거 아주 값비싼 컴퓨터에서나 가능한 멀티프로세서(사실 지금은 아무렇게나 쓰는 GPU라는 개념조차 과거에는 워크스테이션에서나 가능한 개념이었습니다.)가 일상이 되는 어떤 의미로는 '꿈이 이루어진' 세상에서 살고 있습니다.

그런데, 이러한 멀티프로세서의 시대에서 조차 사실 멀티프로세서를 완전히 활용한 프로그래밍은  굉장히 어려운 프로그래밍입니다. 그래서 오늘은 (사실 이런 종류의 글을 써보는것 자체가 처음이지만) 왜 이런게 병렬 연산이라는게 어려운지 한번 사견을 써볼까 합니다.

미리 이야기 드리지만 저는 전산을 전공한적이 없기 때문에 여기에 쓰여지는 이야기는 모두 스스로 생각한의견에 불과하니 진위는 스스로 생각하셔야 할 것이라고 봅니다.


1)우리의 수학 메카니즘
 처음부터 갑자기 스트라이크 존이라 정말 죄송합니다만, 우리의 수학적 체계 자체가 병렬 연산이라는 정신 나간 짓에는 적합하지 않게 되어 있습니다.
  예를 들자면, 누구도 사칙 연산을 할때 이것을 분산 연산을 하지는 않습니다.

 1+1 = 2라는 연산을 할때 우리의 머리 속에서는 1이라는 개체와 1이라는 개채를 더해 2라는 개체를 만들어 내는 식으로(혹은 그냥 암기한 것을 내 뱉거나)연산을 하게 됩니다. 컴퓨터라고 해도 2진 연산을 한다는 점을 제외하고 크게 다르지 않고 이것은 어떤 연산을 할때 선형적으로 연속 연산을 한다는 뜻이지 평행적인 복합 연산을 하지는 않습니다.(대부분의 사람은 아마도 암기한 결과를 조합해서 최종적으로 답을 만들어 내는 형식일 겁니다.)

 병렬 연산 테스트에 제일 많이 쓰이는 원주율 계산을 살펴 봐도 대부분의 계산 방법이 직선적이고 순차적으로 진행되는 방법이지 무한 소수를 구하기 위해서 병렬적인 방법을 사용하는 방법은 거의 없습니다.
(http://en.wikipedia.org/wiki/Pi#Modern_quest_for_more_digits)






http://mathworld.wolfram.com/PiFormulas.html (이곳에 가면 좀더 자세히 정리 되어 있습니다.)

즉, 정리하자면 우리의 컴퓨터의 연산을 결정하는 가장 커다란 요소는 '수학'인데(당초 컴퓨터의 이름의 유례가 왜 computer라고 부르는지 조금만 생각해도 답이 나오죠) 수학이라는 개념이 정립된 고대 이집트와 그리스이래 수의 계산이라는 것은 당연히 한 사람에 의해서 순차적으로 진행되는 것이었고 이를 대신하기 위해 만들어진 컴퓨터 또한 이 구조를 당연히 인간의 수학 구조를 따라 갔으니 당연히 컴퓨터 또한 순차적으로 실행하도록 발전할 수 밖에 없었던 것입니다.


2)더딘 프로그래밍 기법의 발전
감히 이런 말을 하면 '이단 심문'을 당할지 모르겠지만 (그래서 살아 남기 위해 이 업계의 고약하게 유명한 사람의 말을 빌리자면)

'빠른 하드웨어의 발전 속도와 비교했을 때 너무나 더딘 프로그래밍 기법의 발전'

이 사실상 전반적으로 새로운 시대의 프로그래밍을 발목을 붙잡고 있는게 아닌가 하는 생각이 듭니다.


물론 컴퓨터 언어의 발전이 굉장히 눈부신건 사실입니다.

천공 카드(저도 과거 실습으로 한번 해보기는 했습니다만은 이게 얼마나 공포스러운 방법인지 잘 아실겁니다.)에서 시작한 프로그래밍이제가 요즘에 공부하고 있는 파이썬까지 과거의 엔지니어들이 봤다면 눈이 휘둥그래질 정도의 발전을 이룬건 사실입니다.(스페이스 오디세이에서 미래의 언어로 생각한게 프트란이랑 베이직이었고 HAL9000은 이 두개의 언어로 프로그래밍 되었습니다. 역시 천조국 엔지니어!)

그러나 우리가 현실에서 겪고 있는 문제를 생각하면 여전히 너무나 모자릅니다.

여전히 하드웨어에 대해서 너무나 많은 것을 알고 있어야 하고 그러한 사항들을 무시한체 프로그래밍을 진행할 경우 코드의 작동 속도가 너무나 떨어지는 경험을 수많은 프로그래머들이 해봤을 터이고 여전히 많은 사람들에게 프로그래머라고(특히 그 중에서도 해커와 크레커들) 하면 달밤에 악마를 소환하는 마술사랑 별반 다를게 없는 느낌인게 사실입니다.(가끔 아포칼립스 세계에서 해커가 이단 심문이나 마녀 재판을 당하는 상상을 하곤 합니다.)

그리고 멀티 스레드 혹은 멀티 프로세서 프로그래밍을 가능한 어느 언어도 사실상 이것을 최하위 기반으로 가정하고서 설계된 언어는 존재하지 않습니다.(예외적으로 Haskell같은 언어가 있기는 합니다만은 결과물이 유니콘이라고 부를 정도로 범용성과는 거리가 먼 언어입니다.)

 제일 큰 문제는 이러한 언어들의 설계가 사실상 과거의 순차 컴퓨터들을 운용할때 설계된 구조들이다 보니 새로운 병렬 구조로 프로그래밍을 해야 할때 동기화 문제(지금도 멀티 스레드 프로그램을 짤 때 디버그시 최대 문제지요)등을 유발하게 됩니다.(대부분의 컴퓨터 언어가 멀티 스레드 코딩을 하여주기 위해서는 반드시 외부 라이브러리를 호출해야 합니다.) 안그래도 코드의 구조가 머리 속에 않들어 오는 마당에 상이하기 그지 없는 구조와 라이브러리가 겹치고 나면 이걸 평범하게 이해할 방법은 없는거나 마찬가지 입니다.

즉, 정리하자면 프로그램을 짜는 사람의 사고 구조에서 시작해서 사용하는 대다수의 언어 또한 동시에 어떤 수학적 논리가 동시에 그리고 협력적으로 진행되는 것이 통상적 인간의 사고를 벗어나기 때문에 우리 모두 이 괴이한 행동이 당연히 이해가 않된다라는게 최종 결론입니다.


<해결안 제시는 다음 번에>