※제목을 저렇게 해놓긴했지만 정확히 말하면 일반인이 생각하는 해커에 더 가깝습니다. 하지만 개발자는 곧 해커라고 볼 수있으니(안좋은 의미의 해커가 아니라 좋은 의미의 해커)그게그거 아닐까 싶습니다.
영화나 드라마등에서 개발자는 무슨 컴퓨터 앞에서 뚜드리고 뭔가 척!하면 짠하고 뭐가되는 그런 이미지입니다. 그런데 현실은 다들 알다시피 "이게 왜 이러지?"단계가 존재합니다. "생각한다-구현한다-기도한다"라는 개발자유머가 있을정도지요.
하지만 비개발자들은 개발을 맡기면 그냥 알아서 뿅하고 가져온다고 생각하는듯 합니다. 사실 개발의 80%가 디버깅이니 수없는 노가다끝에 만드는건데 말이지요.
개발자가 말하는 기능구현 = 이제 첫단추끼웠다. 이제 디버깅작업이다. 비개발자가 생각하는 기능구현 = 아무문제없이 완벽하다
PSP가 막 팔리던 시절 펌웨어 첫 해킹성공으로 사진한장이 공개됐는데 그냥 PSP화면에 "Hello, World!"가 띄워져있었습니다. 당연히 관련 커뮤니티는 난리났는데 당시 모 게시판에선 "고작 문구하나 띄운거가지고 뭔 호들갑이냐"라는 댓글을 달려있었습니다. 비개발자입장에선 "고작 문구"겠지만 이게 무엇을 의미하는거냐면 PSP라는 플랫폼에서 새로운 무언가를 만들수 있는 환경이 생겼다는겁니다.
사실 모든 개발환경을 갖추고 제일먼저하는건 "Hello World"를 띄우는겁니다. 해당 개발환경이 제대로 만들어진건지 확인하는것이지요.
비개발자들은 이 Hello World띄우는게 쉽다고 생각한거 같지만 개발자들입장에선 개발환경의 완성이라는 큰 의미인겁니다. (이해가 안 된다면 집을 짓기위한 터다지기 작업이 완료됐다고 생각하시면 됩니다)
국내에선 디X인사이드 컴갤이나 Github갤에서 이런 요상한 글들이 많이 보이는데 거긴 아무래도 비개발자출신 자칭개발자들이 많아서 벌어지는듯 합니다. Hello World비하는 일상에 C99와 C17이 뭐가 다르냐고 하더군요. (Visual C++만 쓰는경우 이렇게 되곤합니다. 즉, 타 플랫폼 경험부족)
그러니까 개발자들에게 개발은 계단처럼 하나하나 밟아나가는 일입니다. 하지만 비개발자들은 개발이 짠하고 나오는걸로 착각을 자주합니다. 그러니 어렵게 하지말고 개발자들 힘들게 안 했으면 좋겠네요.
RHEL은 전세계에서 가장 인기있는 대규모 서버용 배포판이고 안정성도 충분히 검증되어왔습니다. 그리고 그 안정성을 바탕으로 기술지원등의 수익을 벌고 있습니다. 그리고 대한민국한정으로 리눅스로 밥벌어먹을때 익혀야할 필수 배포판입니다.(우분투는 대한민국에서 아쉽게도 이쪽에서 크게 힘을 못 씁니다)
그리고 CentOS는 이 RHEL과의 호환성을 보장하고 무료로 배포된 배포판이기에 RHEL쓰다가 CentOS로 바꿔도 쓰던거 그대로 쓸 수있을 정도로 RHEL과 호환성이 좋기에 굳이 기술지원이 필요없다면 개인차원에서도 RHEL공부용으로 쓰기 좋은 배포판이었습니다. 그리고 국내에선 네이버나 카카오같은 자체개발능력이 있는곳에선 CentOS를 주력으로 쓰고있었지요.
그러다 CentOS를 직접 레드햇이 인수하게 되는데 이때까진 그래도 괜찮았습니다. 호환성을 무기로 점유율을 늘린건데 호환성이 더 좋아지면 더 좋아졌지 개판이 될거라고는 생각못했으니까요.
하지만 레드햇은 CentOS의 목을 쳐버리고 말았습니다. 기존 CentOS의 지원기간을 줄이고 이후에는 CentOS Stream이라는 개발버전만 남기기로 했습니다.
이후 CentOS의 후신을 자처하며 Rocky가 등장했고 Oracle도 CentOS에서 넘어올 수있도록 스크립트까지 배포하며 열심이었는데 레드햇은 이 Rocky도 마음에 안들었는지 유료 구독자 이외에는 자신들의 소스접근을 차단하기에 이르렀습니다. (호환성을 얻기위해선 소스를 알아야겠지요. 이걸 못 하게 막은겁니다.)
레드햇이 리눅스 개발커뮤니티에서 끼치는 영향을 생각하면 이건 상당히 위험한 행보입니다. 당장 RHEL의 점유율에는 영향이 없겠지만 (아니, 오히려 RHEL의 점유율은 올라갔습니다) 이미 개발자들에게 찍혀버렸고 CentOS로 RHEL관리법을 배우던 학생들도 사라져버렸습니다.
보통 CentOS로 공부하던 사람들이 현장에서 RHEL을 쓰는 방식으로 점유율이 높아진건데 이들이 사라지고 말았으니 이후 미래는 조금 위험해지지 않았나 싶습니다.
P.S RHEL의 소규모버전은 무료로 풀었다고 합니다. 학교등의 소규모 서버는 이걸로 한다고쳐도 규모있는 중견기업은 어떻게 해야할까요? RHEL을 구독해야할까요?
대부분은 관심없는거 압니다. 하지만 eu에게 뚜드려맞은 이유중 하나가 바로 webkit입니다.
webkit은 애플이 만드는 웹브라우저 엔진입니다 KDE에서 쓰던 KHTML을 잘 개량해서 쓸만하게 만들었고 대부분 크롬이긴했지만 한때는 웹브라우저 엔진 점유율 1위에 빛나던 물건입니다.
하지만 Webkit2를 애플이 발표하면서 크롬을 만들던 구글과 분쟁이 생겼고 구글이 기존의 Webkit을 포크해서 Blink로 바꾸게 되었습니다. 그리고 이름을 바꾸면서 기존에 크롬이 쓰던 Webkit1이 Blink가 되고 애플이 새로만든 Webkit2가 Webkit이 되었습니다.
즉, 지금의 Webkit은 사실 Webkit2고 과거의 영광을 가진 Webkit은 Blink인것이지요.
그리고 MS도 Webkit대신 Blink를 선택했고 현재대세는 애플의 Webkit이 아닌 기존Webkit을 계승한 Blink가 되었습니다.
하지만 애플은 이게 마음에 안들었는지 자사플랫폼(iOS)에선 Webkit(정확히는 Webkit2기반의 Webkit)사용을 강제했습니다. 그래서 Gecko엔진을 가진 Mozilla재단조차 iOS용 Firefox조차 Webkit으로 만들어야했습니다.
여기까진 십분이해 할 수 있습니다. 자사 라이브러리쓰게 할 수 있지요. 하지만 같은 Webkit이라도 Safari와 다른브라우저간의 레이아웃이 상당히 다릅니다. 성능도 당연히 다르고요. Safari외의 다른 브라우저를 못 쓰게하는건지 성능차이가 심하게 납니다.
심지어 웹 개발자들 말에 의하면 Chrome에 맞춰서 만들고 firerox로 접속해보면 딱히 건들곳이 없는데 iOS로 접속하면 다 깨지고 난리부르스라 그냥 Webkit용으로 따로 만드는게 낫다고 할정도입니다.
크롬과 파이어폭스는 엔진이 다름에도 서로 차이가 없지만 웹킷은 "어쩌라고"를 시전하는것이지요. 혼자 유아독존입니다.
그리고 최근 EU에서 애플을 Webkit에대해 반독점법 위반으로고소했습니다. 이미 라이트닝고수하다가 처맞은 전적이 있기에 이번에도 또 처맞을거 같은데 만약 이대로 된다면 Webkit의 점유율이 또 폭락하겠지요. iOS사용자들도 크롬을 선호하니까요.
Blink에 비해 특출난게 없고 Gecko보다 불안정하니 결국 트라이던트처럼 버려지고 Blink기반 사파리가 나올지도 모르겠습니다.
사실 이 둘은 경쟁관계라고 볼 수 있습니다 VKD3D는 Wine환경에서 D3D를 Vulkan으로 돌리기위해 만들어진 라이브러리이고 DXVK는 DirectX환경에서 D3D를 Vulkan으로 돌리기위한 라이브러리입니다
이렇게보면 둘이 직접경쟁하는것 같지 않을겁니다. 하지만 이 둘은 경쟁중입니다. 바로 SteamDeck에서 구동하는 방식이지요.
저 위에 문구에서 D3D를 Vulkan으로라는 문구가 겹치는것이 보일겁니다. 사실 이게 이 둘의 핵심입니다만 구동방식이 약간 다릅니다.
DXVK는 DirectX환경. 즉, 윈도우환경을 전제로 합니다. 그런데 Wine은 윈도우와 호환되는 환경이기에 Wine에서도 구동이 이루어졌습니다. VKD3D는 Wine환경에서 구동이 전제이고 실제 윈도우에서 구동되는건 신경쓰지 않았습니다.
그럼 SteamDeck에선 어떨까요? 당연히 SteamDeck은 네이티브 리눅스용이 아니면 Proton으로 구동되고 이는 사실 게임에 최적화된 Wine입니다. 그러다보니 DXVK나 VKD3D를 쓰게 되었고 둘이서 성능에 관해 경쟁하게 되었습니다.
써본결과 둘 다 성능차이는 크게 없지만 특정게임에 한해 DXVK가 더 낫기도하고 VKD3D가 더 낫기도하고 그렇습니다. 이는 D3D11을 Vulkan으로 구동하냐와 D3D12를 Vulkan으로 구동하냐의 차이입니다. D3D12를 잘쓰는곳은 VKD3D가 훨씬 성능이 좋지만 D3D12보다 D3D11이 더 괜찮은 게임은 DXVK가 더 나은 상황입니다.
그리고 계속 SteamDeck이라고 하고 있지만 일반PC리눅스의 스팀도 동일한 방식을 쓰고 있으니 같은 방식 차이가 생길거라는 생각을 할 수가 있습니다.
참고로 DXVK는 윈도우환경을 전제로 했기에 DirectX11에서 느린게임(라데온이 보통 그렇습니다)을 Vulkan으로 구동해서 빠르게 구동할 수 있지만 VKD3D는 윈도우에서 구동을 보장하고 있지 않습니다. 이쪽은 애초에 리눅스나 유닉스에서 돌리는것으로 만든 Wine팀 작품이니까요.
딱 하나 문제가 있는데 OpenNI2/Drivers에 libFreenectDriver.so 파일이 시스템 업그레이드 할때마다 세그멘테이션 오류를 일으킨다는 겁니다. 그래서 libfreenect를 일일이 빌드해서 build/lib/OpenNI2-FreenectDriver/에 있는 so 파일을 가져와서 넣어줘야 합니다. 귀찮은데 이대로면 정상적으로 잘 돌아갑니다. libusb나 기타 문제겠제요.
# Kinect for Windows SUBSYSTEM=="usb", ATTR{idVendor}=="045e", ATTR{idProduct}=="02c2", MODE="0666" SUBSYSTEM=="usb", ATTR{idVendor}=="045e", ATTR{idProduct}=="02be", MODE="0666" SUBSYSTEM=="usb", ATTR{idVendor}=="045e", ATTR{idProduct}=="02bf", MODE="0666"
파일명은 대충 51-kinnect.rules 정도로 하면 되겠죠.
그리고 lsusb를 치면 보통 Xbox NUI Motor, Xbox NUI Audio, Xbox NUI Camera 이 세가지가 모두 떠야 하는데 하나만 뜨는 경우가 있습니다. 이경우 원인은 두가지 있습니다.
명령을 내리면 아래같이 뜨는게 정상이지만 하나만 뜨거나 하나도 안 뜨는경우가 있습니다.
lsusb | grep Xbox Bus 001 Device 021: ID 045e:02ae Microsoft Corp. Xbox NUI Camera Bus 001 Device 019: ID 045e:02b0 Microsoft Corp. Xbox NUI Motor Bus 001 Device 020: ID 045e:02ad Microsoft Corp. Xbox NUI Audio
1. Autosuspend 문제
전력 문제로 USB장치의 전력을 제한 하는 경우가 있습니다. 보통 노트북이 그렇죠.
간단하게 autosuspend를 끄면 됩니다.
echo -1 | sudo tee -a /sys/module/usbcore/parameters/autosuspend
위 명령을 쓰고 키넥트를 다시 연결하면 잘 뜹니다.
2. 그냥 어댑터 전력 문제
2023년 현재 키넥트가 나온지 오래된 관계로 어댑터들이 상태가 안 좋습니다. 그래서 전력문제를 호소하는 경우가 있더군요.
그도 그럴게 무선 리피터는 그냥 와이파이 신호를 받아서 다시 와이파이 신호를 쏘는 방식을 쓰는 반면 Mesh망은 여기저기 퍼진 노드들이 연계되면서 AP를 붙였다 뗐다 하는 방식이라 더 안정적이거든요
이렇게 되면 장점이 AP당 가해지는 부하가 분산 되면서 더 빨라지고 움직이면서 사용할 때 알아서 Handover 되면서 자연스럽게 속도 저하없이 와이파이 사용이 가능해집니다.
그에비해 리피터는 그냥 중간 지점에서 신호 중계하는 역할만 합니다. 그래서 대역폭이 반토막이 나는 문제가 생깁니다. 하지만 그만큼 오래된 기술이기에 그럭저럭 안정화 되어 최신 기기에선 적극적 Handover로 더 빠른 AP에 붙는 기능을 사용하면 그럭저럭 쓸만하게 인터넷을 쓸 수 있습니다.
다만 요즘 메쉬 기능이 갖는 큰 문제가 하나 있는데 제조사마다 호환을 말아먹은지 오래라서 같은 제조사제품 끼리만 된다는 겁니다. OpenWRT가 지원되는 공유기들이라면 이 문제는 빠져나갈 수 있지만 국내 원탑인 iptime제품은 OpenWRT가 쉽지 않지요. 그나마 MediaTek제품이면 어느정도 가능한데 대부분 쓰인 리얼텍 제품은 OpenWRT지원을 생각하기 힘듭니다.
최근 방에서 네트워크 속도가 너무 떨어져서 확인해보니 겨울이 되서 방문을 닫고 살아서 벽 2개를 뚫고 전파가 오기 힘들어서 그렇다는 결론을 냈습니다. 그래서 Mesh를 생각하고(방에서 쓰는 공유기가 A8004T로 컨트롤러모드가 가능한 제품입니다. 신호도 강한 편이지요. Mesh네트워크로 쓸만한게 무엇이 있을까 찾아보고 있었는데 밖에 비가 억수로 와서 나가기 귀찮음+방구석에서 옛날에 쓰던 A604(2014년 제조)이 보이는데 이건 Mesh가 안 되는 물건이라네요. 그래서 그냥 무선 리피터로 만들어서 달아봤습니다.
A604가 요상한 물건이라 유선은 100Mbps로 제한이 걸렸는데 무선은 867Mbps가 되는거라 무선 리피터용으로 쓰긴 좋았습니다. 무선을 받아서 무선으로 뿌리면 대역폭이 400정도로 반토막 나지만 어차피 유선이 100짜리인 이상한 물건이라 그냥 저냥 쓸 수 있습니다. 애초에 벽2개 뚫고 오는 신호도 80였었기에 박살나더라도 이게 어디냐 싶기도 했고요.
저희집 네트워크 구조는 대충 그리면 다음과 같습니다
방1에서 AP가 있고 다른 방에서 이 신호를 받아다가 인터넷을 합니다만 방1의 벽이 내력벽인 것인지 엄청 두꺼워서 다른 방에선 신호가 박살이 납니다.
그래도 거실은 문방향이기도 하고(문은 나무라 신호강도 문제가 없지요.) 거리상 문제로 속도가 떨어질 뿐이지만 다른 방은 속도가 엄청 떨어졌습니다. 특히 저 침실의 속도가 처참한데 5GHz는 포기해야 할 수준이고 2.4GHz가 딱 저 속도가 납니다. 심지어 화장실이 더 속도가 나네요. 그래서 메쉬를 쓰려고 한건데 역시 쉽지 않더군요. 대신 찾아보니 옛날에 쓰던 A604가 있더군요. 오래된 물건인데 어댑터가 망가진걸 제외하면 멀쩡합니다. 심지어 찾아보니 12V짜리 1A아무거다 꽂으면 된다네요.
그래서
이렇게 A604제품을 무선 리피터 설정 후에 돌리니까 침실에서 도저히 못볼 수준의 속도가 회복 되었습니다. 그리고 SSID와 비밀번호를 기존 A8004와 A604를 동일하게 하니 사용상의 큰 문제는 보이지 않았습니다.
하지만 가끔 거실에서 침실로 들어오면 속도가 떨어지는 것이 보이더군요. 알고보니 무선 리피터는 동일한 SSID라도 성능이 더 높은걸 잡는게 아니라 기존에 잡았던 AP를 잡으려고 한다네요. Mesh는 컨트롤러가 이걸 확인하면서 다시 잡아주고요. (이러한 방식의 통신을 Backhaul이라고 합니다.) 물론 그럴때는 Wifi를 껐다 켜주면 되긴 합니다.
어쨌건 이것이 Mesh와 무선 리피터의 큰 차이점입니다. 알아서 더 강한 신호의 AP로 바꿔주는것과 기존의 것을 잡으려 시도하는 것. 당연히 Mesh가 쓸 수 있다면 무선 리피터 보다 훨씬 더 낫겠죠. 무엇보다 IP대역 하나를 더 먹지요. 어차피 255개중 하나라 크게 문제는 없겠지만...그리고 Iptime의 EasyMesh의 쉬운 구성방법보다 무선 리피터는 DHCP설정부터 해서 좀 복잡한 편이고요.
그러면 복잡한 방법을 한번 소개하고자 합니다.
우선, 위의 것을 생각해봅시다.
1. 2.4GHz는 이미 포화상태고 굳이 리피터로 퍼트릴 이유가 없습니다. 무엇보다 자세히는 말하지 않았지만 침실 앞에 전자렌지가 있다보니 2.4GHz는 기존 방1의 것만 쓰고 리피터로는 따로 안 쓰기로 합니다.
2. 그리고 리피터와 기존 AP의 이름을 동일하게 해서 귀찮음을 해소합니다.
그러기 위해선 우선 기존 공유기가 아닌 리피터로 쓸 공유기를 유선으로 연결합니다. 그리고 브라우저를 켜고 192.168.0.1(기본 관리자 모드)로 들어갑니다.
그리고 당연히 관리자 비밀번호를 바꿔야겠지요. 이건 뭐... 알아서 하실거고 기존 공유기와 충돌을 막기 위해 설정을 해야 합니다.
고급설정 - 내부 IP주소를 바꿔줍니다. 이게 곧 해당 리피터의 관리IP가 됩니다. 기존에 사용하던 공유기나 PC와 다른 IP를 써야 합니다. 그리고 DHCP를 꺼야 하는데 그냥 끄는 것이 아닌 간단한 옵션으로 DHCP가 유동적으로 꺼질 수 있게 하는 것이 좋습니다.
네트워크 관리 - DHCP서버설정에서 DHCP서버충돌에 "충돌 발견시 중단" 체크해 주시면 지금 설정 단계에선 DHCP가 동작하지만 만약 다른 공유기가 있거나 다른 DHCP서버가 있다면 알아서 서버가 꺼집니다.
이제 핵심기능입니다. 무선확장설정으로 들어가서 무선 확장 방식을 멀티브리지(리피터)로 바꾸고 AP검색 버튼을 눌러서 우리가 사용할 AP, 기존 공유기로 접속 합니다. 이때 접속이 되어다면 유선으로 연결된 PC에서 갑자기 인터넷이 될겁니다.
이제 편의를 위해서 무선설정/보안에서 기존에 쓰던 SSID와 비밀번호를 동일하게 합니다. 이래야 좀 편해질거거든요.
무선설정/보안에서 기존에 쓰던 이름과 암호를 그대로 넣어서 똑같이 해줍니다. 이러면 Handover가 되는 기기라면 알아서 바뀔것이고 안된다면 재접속시 더 강한 AP로 접속 할 겁니다.
Virtualbox가 만들어진지는 꽤 오래되었습니다만 최신 커널에 언제나 대응하고 있었습니다.
다만 이번에는 조금 느려진 탓인지 대응이 좀 늦었군요.
커널 업데이트 후에 Virtualbox를 실행할때마다
vboxdrv.sh: failed: Look at /var/log/vbox-setup.log to find out what went wrong.
There were problems setting up VirtualBox. To re-start the set-up process, run /sbin/vboxconfig as root. If your system is using EFI Secure Boot you may need to sign the kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) before you can load them. Please see your Linux system's documentation for more information.
요런 문구가 뜨거나
메시지대로
sudo /sbin/vboxconfig 명령을 내려서
커널 모듈을 새로 설치를 하려고 하면
vboxdrv.sh: failed: Look at /var/log/vbox-setup.log to find out what went wrong.
