http://news.softpedia.com/news/canonical-wants-you-to-test-gnome-memory-leak-patches-in-ubuntu-18-04-lts-520751.shtml
케노니컬에서는 우분투 18.04 최신 버전 발표에 앞서서
그놈 메모리 누수 현상을 근본적으로 해결하기 위해서 그놈 메노리 누수 패치를 테스트할 사람을 구하고 있습니다.
이번 기회에 그동안 오랫동안 방치 되었던 이 문제를 근본적으로 해결해 보려고 하나 봅니다.
그나마 다행입니다. 모든 문제는 방치하면 안 되겠죠.
관심있으신 분은 기사 내용을 참고하여 도전해 보시기 바랍니다.
메모리 누수 현상과 가베지 컬렉션 문제는 아주 오래전부터 프로그래머 사이에는 핫 이슈이고, 실제로 다양한 방법으로 언어별로 처리하는 기법이 다 있습니다.
그러나 이런 것까지 고려해서 프로그래밍을 척척 잘 짜주시는 정성스러운 분들이 생각보다 적어서 최종 소비자인 대중들 입장에서는 메모리 누수 현상으로 인한 피해(?)아닌 피해를 입게됩니다.
예전에는 어떤 언어를 사용하던 간에 최적화라는 주제는 프로그래머의 가장 핵심적인 의식이었고 실제로 그렇게 프로그래밍했습니다. 요즈음은 프로그래머들이 편해져서 그냥 언어에서 지원하는 라이브러리에 의존해서 프로그래밍하다보니 근본적인 문제가 생기면 덜덜 떠는 분위기입니다. 이런 분위기는 많이 쇄신되어야 한다고 봅니다.
아주 옛날 80년대, 90년대 초반까지만 해도 원라인 테스트(베이직 언어 256자 내외로 프로그래밍을 하는 기발한 프로그래밍 테스트), 최적화 테스트 (어셈블리어와 기계어를 이용해서 가장 최적으로 원하는 결과를 얻어내는 테스트), 가베지 컬렉션 테스트(각 언어별로 최적의 메모리 관리 방법을 제시하는 테스트) 등... 말 할려면 한 도 끝도 없음...
여하튼 다양한 방법으로 최적화를 이루어서 지금으로는 말도 안 되는 64K 메모리, 128K 메모리에서 엄청난 작품들이 쏟아지고 실제로 현장에서 사용되었다는 사실을 기억해야 합니다.
지금은 너무 편해져서 이런 최적화 부분, 알고리즘 부분, 가베지 켈렉션 부분, 기타 코딩의 최적화 부분 등을 종합적으로 고려하지 못하는 분위기인 것 같습니다. 이번 기회를 통해서 오픈 소스 계열도 쇄신이 필요하다고 보입니다.
C언어에서도 가베지 켈렉션 방법론이 아무 오래전부터 이미 충분하게 공개되어 있으니, 이를 시스템에 맞게 잘 반영하면 문제해결 되는 것은 전혀 문제될 것 없다고 보입니다. 문제는 전문 프로그래머들이 돈을 받고 사업적으로 프로그래밍 하시는 분들이 아니라 취미 차원에서 또는 자신이 시간될 때 프로그래밍 하시는 분들이 많아서 이를 최적으로 협동적으로 결과를 이끌어 낼지가 고민이다고 보이네요.
기업 차원에서도 서로 협력하지 않으면 위에 언급한 게임과 같은 결과가 나오기도 합니다.
이미 알고리즘과 방법론 등에 모두 공개되어 있으나 이런 것까지 완벽하게 고려해서 프로그래밍하는 것은 사실 고역이죠. 그 마음은 이해합니다.
그렇지만, 이번 기회에 그놈이 이런 부분까지 해결을 근본적으로 본다고 하니 잘 한 일이라고 보입니다.
새롭게 그놈도 태어나야죠.
양, 질, 속도로 나눠 생각할 수 있습니다.
옛날부터 지금까지 양(量)을 추구하다가 어느정도 성과를 이루자, 질(質)을 추구할 수 밖에 없게 되었고,
질 역시도 어느정도 성과를 이루자 속도(速度)가 중요하게 되어 집중하게 된 결과, 오늘날
비슷한 문제가 잊을만하면 발생하게 된 것 같습니다.
편중(偏重)을 경계하며 균형(均衡)을 추구한다면 최상의 결과에 가까워지리라 생각합니다만, 그걸 구분할줄 안다면
이런 글을 쓸 이유도 없겠죠.
moordev 님 친절한 설명 감사합니다.
돈 빌리고 안 갚아서 문제가 생겼다고 보면 될까요?
늦게 봤네요.
많이 비슷합니다. 돈 빌리고 안 갚는 수준이 아니라 돈을 빌리고 계속 빌리기만 하는 상황이라고 봐야겠지요.
계속 빌리기만 하니 은행(가용 메모리)에는 자꾸 돈이 떨어지고 그러니 다른 사람들이 돈을 못빌리는 상황에 처하게 되는데 사회간접자본(중요 시스템, 네트워크 매니저, UI 관리자 등)에 들어갈 돈까지 가져가는 바람에 사채(스왑)까지 쓰게되면 시스템 전체가 망하게 되는 것이지요.
우분투 행보에 박수를 보냅니다.
메모리 누수가 있다는 자백은 보통 용기를 갖지 않고서는 안되는것이니 많은 응원 부탁드립니다.
저는 리눅스를 사용하시는 분들이 내 식구라고 버그에 관대하지 않으셨으면 합니다.
BUG(벌레)는 반드시 때려 잡아야 합니다. ㅋㅋ
예를 들어서 집에 바퀴벌레가 전혀 보이지 않다고 어떤 이유인지는 모르지만 한 두 마리씩 보이기 시작하면 그냥 그러느니 하고 방치하면 몇 달도 안 되어서 엄청나게 번식해서 나중에는 감당하기 힘든 지경에 까지 이릅니다. 그래서 근본적으로 바퀴벌레를 때려잡는 방법을 동원해서 전멸시켜야죠. ㅋㅋ
프로그램에서도 버그를 한 번 방치하기 시작하면 꼬리에 꼬리를 물고 예상하지 못한 큰 영향을 끼칩니다. 일종의 나비 효과와 비슷하다고 이해하시면 됩니다. 아주 사소한 것은 방치하지 말고 바로 때려잡아 주기....
이것이 프로그램과 관련된 사람들의 식견과 기본적인 수칙이 되어야 하지 않을까 생각합니다.
일종의 프로그래밍 습관에 관한 문제죠. 습관이라는 것이 이런 부분에서도 참으로 중요함을 느낍니다.
여하튼 오픈 소스 계의 버그에 대한 다양한 시각이 있는데, 분명한 사실은 버그는 방치하면 안 된다는 상식을 지켜나가야 더욱 발전적으로 나갈 것이라 보입니다.
그리고 최종 사용자도 "나는 전문가가 아니니 알아서 전문가들이 버그를 찾아서 고치시오"라는 심정으로 프로그램을 사용하는 것에 집중하는 것보다는 가능하면 자신이 할 수 있는 범위에서는 최선을 다해서 버그를 보고하고 피드백을 해서 근본적으로 프로그램 버그를 찾고, 고치고 하는데 일조하는 분위기가 된다면 더욱 시스템이 안정적으로 개선될 것입니다. 이 부분도 인식의 전환이 대단히 필요한 부분이죠.
Copyright © 2023 invesume, Licensed under the Apache License, Version 2.0. HamoniKR and HamoniKR OS logo are trademarks of The Invesume, Inc.
유익한 정보 감사합니다.
케노니컬이 OS사업 그만둘 생각은 없나 봅니다.
실례가 안 된다면 저 같은 문외한을 위해서 메모리 누수란 것이 어떤 것인지 간단히 설명 해주실 수 없을까요?