위와 같이 LSB: Start and stop the mysql database server daemon 에러가 발생한 경우

my.cnf 파일에서 [mysqld] 섹션 아래에 아래와 같이 옵션을 추가한 뒤 실행하면 된다.

원인은 어떤 요인으로 innodb가 깨져서 mysql이 실행이 안되는 것으로 강제로 복구옵션을 켜주면 일단 켜지는건 가능하다.

혹시 모르니 백업 후 db를 다시 세팅하는 것을 권장한다.

사실 이 포스팅을 하게 된 계기는 오늘 새벽 내 하드디스크 한 장이 보드가 나가버리는 일이 발생했습니다.

그런데 예전에

하드디스크에서 윈도우 설치, 2012/11/07 - [Windows/VHD] - VHD를 사용하는데 복구시 마다 명령어 입력이 귀찮을때

 등 실험하느라 부트로더를 HDD로 옮기고 SSD는 여러번 포멧을 거치며 기존 부트로더는 삭제되었는데, 하필 보드가 나간 하드가 부트로더가 들어있는 하드였...네요..

samsung | SM-N920L | Normal program | Center-weighted average | 1/60sec | F/1.9 | 0.00 EV | 4.3mm | ISO-125 | Flash did not fire | 2017:06:18 08:20:26

운명하신.... 시게이트 바라쿠다 2테라..

내 포트폴리오가 들은 하드인데.. 그건 업체 맡기면 된다지만 당장 부팅을 해야 과제도 외주도 작업할 거 아닌가...??

문제는 USB가 없었습니다.

평소에 시놀로지 만만세를 외치고 HDD에 윈도우 이미지 올려놓아서 usb의 필요성을 느끼지 못했던 것에 대해 후회가 밀려오지만 뭐... 이제와서 땅 파면 안나오잖아요..?

이 때 예전에 Windows Server 2012 R2 운용 당시 윈도우 배포 서버를 만졌던 기억이 나서 일반 데스크톱도 PXE 서버 구성이 되지 않을까 하고 찾아봤습니다.

마침 저는 같은 네트워크 안에 다른 pc가 무려 두 대! 나 있기 때문에 네트워크로 윈도우 복구를 해봤습니다.

TFTPd32 / 64(바이러스 사이트라 나오나 문제 없습니다.)

Tiny PXE Server ( 추천)

사실 저는 둘 다 실험해봤고 아랫것이 더 좋다고 판단하여 추천 드렸습니다.

TFTPd32는 부트 이미지들을 커널레벨부터 손수 찾아서 넣어주고 설정해야하는 반면에 Tiny PXE Server(이하 tps)는 커널 파일들이 패키지로 종류별로 전부 들어있습니다.

또 부팅시에 사용한 이미지가 있는데 윈도우 10 은 어째서인지 WinPe로 100% 복구가 불가능하거나, WinRe iso 파일이 없습니다.

대부분의 포스팅을 보면 WinRe를 직접 USB에 굽는 방법만 나와있을 뿐 그 iso 파일은 없었습니다.

그런데 Kyhi 라는 유저가 Windows 10 용 Recovery Tool Image 파일을 제공해주셨습니다. 박수 짝

Windows 10 Recovery Tools - Bootable Rescue Disk

자세한 파일 구성은 위 링크를 통해서 확인하시고 저는 바로 설명하겠습니다.

먼저 주의 사항은 두 프로그램 모두 iso 파일이 3기가 정도를 넘어가면 안됩니다.

TFTPd의 경우는 아예 파일을 보내주지 않고, tps는 일정 용량(3기가 추정)이 넘어가면 메모리 에러가 발생합니다.

제 생각엔 둘 다 iso를 위해서는 memtest를 커널로 사용하는데, 이 커널이 읽을 수 있는 최대 메모리가 3.x 기가로 제한되는 것같습니다.

바로 32비트 윈도우의 메모리 제한량과 같죠..

그래서 윈도우를 새로 설치하거나 복구할 때 윈도우 이미지를 직접 불러올 수가 없었습니다.

방법은 두 가지 있는데, 

1. PXE 서버에서 네트워크 공유(SMB)를 통해 파일을 당겨오는 방법.

2. 우선 부팅 후 브라우저를 통해 새로 내려받아 설치하는 법.

애초에 1번의 경우 PXE 자체가 같은 서브넷 안에서 동작하기 때문에 (ip 할당 및 PXE 요청을 브로드캐스트로 요청함) 언제나 가능한 기능이고, 2번의 경우는 pxe 서버로 쓰는 컴퓨터에 비밀번호가 없거나 걸기 싫은 경우, SMB가 차단된 경우 사용할 수 있는 방법입니다.

1번은 그저 아무 iso 마운트 프로그램이나 (윈10은 기본 내장) 가져다가 iso를 시디롬으로 마운트하고, 그 시디롬을 통째로 공유하면 됩니다.

2번은 뭐 알아서.. 내려받으시면...

TFTPd 설정

압축을 풀면 아래와 같이 파일이 있습니다.

여기서 각 값을 아래와 같이 수정합니다.

IP Pool start address : 본인 dhcp 대역 내에서 알아서.. 대게 iptime은 192.168.0.2 zio나 신형 kt허브는 172.30.1.1, 구형 kt허브나 기타 브랜드는 10.0.0.2로 입력하면 됩니다.

Size of pool : 10보다만 크게 해주세요.

Boot File : pxelinux.0 (추후 설명)

Def. router : 공유기

Mask : 본인 아이피 시작 192.168 -> 255.255.255.0, 172.30 -> 255.255.255.0 또는 255.255.0.0, 10.0 -> 255.255.255.0 인데 가끔 진짜 이상하게 이것을 255.0.0.0 하는 공유기가 있음.. 공유기가...

그리고 TFTP 탭에서 PXE Compatibility 체크하시면 됩니다.

체크하는 이유는 일부 iso 부팅이 이 옵션 없이는 부팅이 안됩니다.

pxelinux.0은 Kernel.org 의 syslinux에 있습니다.

Syslinux

4.04 버전이나 3.86버전을 내려받아 압축을 풀고(제가 테스트해본건 저 두버전)

3.86기준

core -> pxelinux.0

com32 -> menu -> menu.c32

그리고 pxelinux.cfg 폴더를 만들고 그 아래에 Default 파일을 만들고 아래 내용과 같이 본인 파일에 맞춰 적습니다.

TPS 설정

tps는.. 애초에 다 준비가 되어 있습니다.

여러분들이 해야 할 것은 뭐다..? iso 구해넣고 메뉴 추가하고 설정하고 끝..

좀전에 tftpd에서 본 모양이죠? 척척 넣습니다.

Boot File의 Filename은 설치 폴더 아래에 files 안에 있으니 찾아보시면 됩니다.

다른 커널을 쓰더라도 이 폴더를 잘 보시면 이미 다 들어 있습니다.. 네..

이제 files/iso에 파일을 넣습니다.

iso는 WinPe, Re, 뭐 기타 3기가 정도만 안넘으면 다 가능합니다.

다 넣으셨으면 files/pxelinux.cfg/default 열고 아래와 같이 수정합니다. 위에거와 방법이 같죠? 같은 커널이니까요..

다 하셨으면 위에 online을 한번 offline으로 껐다 다시 켜주시구요.

이제 메인보드에서 PXE 설정만 하면 됩니다.

PXE 설정은 다음 글에서 다루겠습니다. 

별다른 내용은 없고 메인보드에서 PXE 를 찾아 on 시키고 부팅 순서에 넣어주시면 서버에서 찾아서 알아서 부팅합니다.

델파이는 잘 만든듯 하면서 엉뚱한데서 허술하다.
예를들어 요즘엔 당연시 되는 자동 uses 따위 없다.
컴포넌트를 올리고 저장하면 그 부분은 자동으로 되지만 함수나 클래스를 당겨올 경우는 자동 uses 가 안된다.
데브기어 측에서는 여러가지 말을 해줬지만 그냥 결론은 엠바가 이걸 만들줄 모른다 라고 밖에 안들린다.
철학은 무슨 델파이 기본이 빠른 생산성인데 uses 해야할 라이브러리 찾아 다니다가 시간만 다 잡아먹는다.
이상한데서 개발 능력이 떨어지는 엠바가 또 한가지 버그가 있는데 기본 클래스가 ide에서 에러로 걸린다는 거다.
이건 진짜 내가 쓰는 도쿄버전에 국한된 문제가 아니라 전의 전의 전의 전의 내가 델파이를 처음썼던 xe2부터 이미 보고가 된 것인데 고치지 못했다는건
엠바 IDE 개발 수준은 딱 거기까지 라는 것.
이런 엉뚱한 점을 이의제기하면 덮기 일쑤던데 (특히 나같이 입문한지 얼마 안된 사람은) 기본은 좀 하고 덮자.

어쨌든 아래와 같은 상황이 있다.

보면 델파이의 가장 기본 클래스인 TObject가 밑줄이 들어가있다.

이런 식으로 기본 기능 자체가 좀... 이상하다 델파이는.. 심각하게..

그대로 빌드해도 큰 문제는 없지만 찝찝해도 이대로 해야된다.. 아님 IDE를 재시작하거나..

엠바에 신고한 버그 리포트에 따르면 ide가 기본적으로 system을 먹고 들어가야 하는데 이걸 못먹는단다.

근데 이게 내가 본것이 08년도 글인데 10년째 못고치고 있다는 소리다..

PWD (-L) 현재 환경상 경로 반영

PWD -P 실제 현재 위치 반영

ex)

라즈베리 뿐만 아니라 리눅스에서 gui. tui를 동시에 지원하는 프로그램을 사용할 때, tui에서 tui 실행용 명령어를 입력했음에도 아래와 같은 에러가 발생하는 경우가 있다.

이럴때는 X11 Forwarding이 활성화되어 있기 때문인데

/etc/ssh/sshd_config 파일에서 X11Forwarding 을 no로 바꾸거나 주석처리하면 된다.

X11 Forwarding 이란 쉽게 하자면 SSH 환경에서 X11 인터페이스 사용이 가능하게끔 디스플레이 정보를 포워딩 해주는 것이다.

xming과 같은 프로그램과 같이 사용하면 ssh 접속만으로 저쪽의 gui 프로그램을 당겨올 수 있다.

(ex gedit.. firefox... minecraft(된다... 프레임은 보장 못하지만..))

17.03.20 현재 기준, 언제부터인가 라즈베리파이에서 시리얼 포트 활성화가 매우 간편해졌다.

그런데 이를 모르고 예전 방식을 계속 사용하거나 포스팅하는 사람들이 많아 메모 겸 포스팅을 작성한다.

방법은

pi@raspberrypi:~ $ raspi-config

2017:03:20 23:31:34

2017:03:20 23:32:32

2017:03:20 23:33:19

더이상 예전처럼 환경파일을 직접 수정하고 할 필요가 없어졌다. (특히 그 환경파일이 버전마다 내용이 바뀌어서 찾는 글 족족 맞는게 없더라..)

C#을 배우기에 앞서 내가 왜 C#을 배우게 되었는지에 대해 먼저 포스팅해보려고 한다. 많은 학생분들이나 선배 개발자님들도 C#을 많이 학습하고 있는데 이러한 흐름에 몸을 실으면서 학습을 하게 된 것은 아니다. 먼저 델파이와 C#의 차이를 먼저 비교해야한다. 먼저 난 델파이가 싫어져서 C#을 배우기 시작한 것이 아니다. C#에 그렇게 큰 비중을 두고 학습하는 것도 아니고 여전히 내 주력 언어는 델파이일지도 모른다. 하지만 한 우물만 파면 더 좋은 것이 있어도 보질 못하고 생각또한 갇히게 된다. 나는 C#을 통해 델파이에서의 불편했던 점을 찾고, 하일스베르 등이 델파이에서는 이렇게 생각하고 구현한 것을 C#에서는 어떻게 처리했는지, C#에서 더 매끄럽거나 더 뛰어난 컨트롤이 있다면 보고 배워 델파이의 컴포넌트로 포팅해 보기까지 다양한 호기심을 충족하고자 학습을 시작한다.

이 글을 적는 이유는 먼저 C#은 델파이가 아니다. 델파이의 많은 철학이 그대로 녹아있지만 동일하게 봐서는 안된다. 오히려 나는 이것을 배우면서 현재까지는 자바와 드림위버같은 느낌을 더 크게 받았다. 게다가 계속 개발되어지고 있는 언어이다. 너무 델파이만 신봉하여선 안된다는 소리다. MS 닷넷 특성상 델파이처럼 코드 단일화가 되기는 조금 힘들겠지만. (MS의 Object-C 같다는 소리도 한다고 한다) 

최근들어 델파이를 잘 사용하지 못하게 되었고, 간간히 내가 찾은 팁이나 국내 책에서 알려주지 않는 소소한 기능 설명을 위해 업로드하던 포스팅도 겨우 4건에서 그쳤다.

가만 고민해보면 우선 델파이의 지원 범위가 아직은 내가 원하는 범위까지 지원되지 못하는 탓이 클 것이다. 

라자루스를 통해 오브젝트 파스칼을 쓸 수 있다지만 라자루스 또한 다양한 리눅스 제품군을 커버하지는 못하고 있고 나의 경우 임베디드 리눅스와 TUI 환경의 프로그램을 주로 접하다보니( 그러고보니 요 몇년간 리눅스에서 GUI를 쓴 적은 X11 포워딩을 통한 gedit 밖에 없다.) 더욱 델파이와 거리를 두게 되었다고 할까.

사실상 델파이는 내게 있어서 아직은 임베디드의 제어를 위한 서브 도구에 지나지 않는다고 하면 되겠다.

그렇다고 델파이가 별로 좋지 않다는 것은 아니다. 오히려 내가 비록 보잘것없으나 이 정도의 언어 실력까지 올라올 수 있었던 것은 델파이의 단순함과 직관적인 UI를 통해 빠른 생산성을 얻을 수 있음은 부정할 수 없다. 네이티브이기 때문에 자바나 닷넷보다 빠를 수 있음은 두말할 것 없고. 델파이는 여전히 훌륭한 도구이고 훌륭한 개발자들의 손을 통해 오늘날에도 철학을 지키며 만들어져 오고 있다. 많은 개발자들이 많은 훌륭한 프로그램을 만들어 내고 있으며 때로는 기존의 많은 프로그래머들이 찬양하던 자바 언어로 된 프로그램이 하나 둘 델파이로 대체되는 경향도 없잖아 보이고 있다. 

많은 사람들이 델파이는 너무 마이너적인 언어라고 한다. 인정할 수 밖에 없다. 마이너라는 것은 아무리 훌륭한 언어라도 비주류라면 어디에나 붙을 수 있는 칭호고 델파이는 여전히 마이너라고 생각한다. 많은 프로젝트가 여전히 자바와 닷넷 위에서 진행되고 있고 임베디드 또한 C와 C++로 작성되어지고 있다. 한때 빠른 취직을 위해 찾아볼 때도 구인 구직 또한 자바가 압도적이었으니까. (물론 대부분 제값 받을 수 있는 일은 아니었다.) 하지만 나는 이 부분이 한창 IDE 플랫폼 시장이 격화될 때 인재 유출로 인해 많은 개발자와 고객사를 잃어버린 탓이 크다고 생각한다. 만약 당시에 MS가 Delphi, Turbo Pascal의 개발자들을 전원 스카웃하지 않았다면 어땠을지는 개개인의 의견차가 크니 별다로 언급하지 않겠다.

내가 이런 좋은 언어를 배웠음에도 C#을 배우려는 점은 몇 가지가 있는데 그중 하나는 Visual Studio라는 IDE 플랫폼의 매력이 크다. 델파이는 언어 철학과 직관적인 배치, 사용법은 확실히 VS보다 편하다. 적응의 문제가 아니다. 나는 작년 이맘 때 처음 델파이를 학습했고, c#을 학습하는 지금 벌써부터 불편함이 느껴진다. 디폴트 환경에 도구 상자가 감춰져 있어야 하는 이유를 모르겠으며 Control의 Drag & Drop 시 왜 내가 끌어다 놓은 곳에 정확히 안착하지 못하고 좌상단 모서리에 안착이 되는지는 여전히 이해할 수가 없다. 

위치 포인트는 무시하더라도 여러 도구를 가져오는 시간도 상당히 오래 걸린다. 내가 왜 xaml을 봐야하는지 이것 또한 이해할 수 없는 요소이다. 그렇다고 보기 좋게 작성되는 것도 아니며 속성 팔레트가 존재하는데도!

하지만 델파이가 VS를 따라오지 못하고 있는 부분도 보이는데, 델파이는 라이브러리 확인이 다소 불편하다. 델파이의 라이브러리를 살펴보기가 어렵다는 것이 아니다. 라이브러리 자체는 훨씬 쉬운데, 그 방법론의 문제다.

우선 델파이에서의 정의 확인부터 간단히 넘어가보자.

델파이에서 어떤 변수가 어디에 선언 되었는지, 사용되었는지 찾기는 VS보다 쉽다.

Ctrl 누른 상태에서 해당 변수든 프로시저든 펑션이든 누르면 넘어간다.

그렇다. 누르면? 넘어간다. 그냥...

완전히 커서가 해당 구역으로 넘어가버린다는 의미이다.

라이브러리에서의 정의를 확인하기 위해 누르면?

VS에서는 이 기능이 윗처럼도 가능하지만 이렇게 구현이 될 수도 있다.

델파이를 공부하다가 후배가 물어봐서 VS를 오랜만에 설치해서 연 적이 있는데 이 기능은 정말... 정말이지 놀라웠다.

델파이는 단일 모니터에 최적화된 툴의 느낌이라면 VS는 넓은 화면을 효율적으로 볼 수 있다고 봐야겠다.(그것이 도구 팔레트를 기본으로 고정시켜주지 않은 것을 변명할 수는 없지만) 실제 델파이를 코딩하다보면 라이브러리를 직접 확인할 일이 생각보다 많은데 다른 언어는 레퍼런스를 주로 보고 의지한다면 델파이는 각 변수의 용도 정도만 알아도 초보 개발자가 라이브러리를 보는데 큰 지장이 오지는 않는다. 되려 델파이의 레퍼런스나 책을 볼 일보다 책에 나오지 않는 컴퍼넌트의 명확한 용도를 알고자 구글링할 때가 더욱 많으니까. 그런데 그 보는 방식이 너무 불편하다는 것이다. 무조건 탭이 넘어가고 동시에 두가지 탭을 보기 힘들다. 하지만 이 기능은 내가 수정하고자 하는 코드 바로 근처에서 내가 원하는 정보를 찾아주므로 비교해보고 내용을 파악하기에 최적화되어 있다는 거다.

그 외에 차이점을 더 느끼지만 한번에 다 공개해버리면 뭔가 언어간 디스전과 같이 흘러갈 것같다. 나는 특정 언어가 우월하다는 것에는 반대하는 입장이고, 디스보다는 이 언어는 이게 낫고 저 언어는 이게 좋더라.. 정도로 봐주었으면 한다. 앞으로의 c# 학습 글은 얼마나 올라올 지 모르겠지만 전체적인 흐름은 델파이나 이클립스와의 비교로 진행하게 될 듯하다. 급할땐 한번에 내가 필요한 정보를 제공하는 것도 좋고 따라함으로써 금세 성취감을 느낄 수 있는 구성도 좋지만, 그런 책이나 강의, 강사님들은 많다. 하지만 처음부터 여러 언어의 차이나 해당 언어의 원리에 대해 맛보기나마 호기심을 채워주는 글은 많지 않다. 

나 또한 언어의 학습에 있어 많은 부분이 부족했지만 초보자 수준에서 접할 수 있는 정보의 양은 한계가 있었고 지금도 나는 초보자일 뿐이다. 하지만 초보자가 초보자의 입장에서, 책만으로는 알기 어려웠던 접시물의 깊이를 내가 겪었던 그대로 풀어 설명을 하고 싶다. 결국 나는 나중에도 언제나 초보자일 것이고 나 또한 이 글들을 통해 다시금 배우고 새로운 것을 알게 될 것이니까.

PS. 실제로 나는 중학생 때 C를 배우면서도 왜 이게 이러는지 모르고 배웠다. 이 글을 어쩌다가 읽게된 몇몇 당신도 찔리지는 않으시는지..?

상당히 오래전 DD-WRT 펌웨어를 소개하고, 이 설치 방법을 포스팅하겠다고 했는데 어느새 벌써 11월의 마지막 주입니다.

DD-WRT는 WRT계열 오픈소스 라우터 펌웨어로 라즈베리파이를 깊게 사용해보신 분이라면 OpenWRT 정도는 들어보셨을 겁니다.

OpenWRT는 가장 오래되었고 가장 많은 기능을 수행할 수 있지만 여타 리눅스처럼 기본 기능만 들어있고 나머지는 패키지로 별도 설치, 설정해야하는 불편함이 있습니다. 

DD-WRT는 빌드 버전별로, 빈티지 별로 사전에 정의된 모든 기능이 다같이 들어있는 펌웨어로 초보자도 비교적 쉽게 다루지만 세세한 설정을 하기는 힘듭니다.

두 펌웨어 모두 공통적으로 리눅스 기반입니다.

즉, 라우터로써의 기능 뿐 아니라 다른 기능도(웹서버 등) 가능하다는 이야기입니다.

사실 소형 컴퓨터 하나 생긴다고 보셔도 됩니다.

WRT 펌웨어는 WRT 계열만 가능합니다. 모델명이 WRT가 아니라 WRT 계열 펌웨어만 WRT 계열의 다른 해킹펌, 오픈소스 펌웨어로 해킹이 가능합니다.

DD-WRT의 커펌 가능 여부와 다운로드는 이곳에서 조회할 수 있습니다.

DD-WRT의 설치에 앞서 갑자기 다시 포스팅을 한 이유를 알려드리겠습니다.

samsung | SM-N920L | Normal program | Pattern | 1/24sec | F/1.9 | 0.00 EV | 4.3mm | ISO-160 | Flash did not fire | 2016:11:27 20:25:20

바로 요놈인데요.

요놈의 이름은 WRT54G Rev.2로 정말 잔고장치레조차 안하기로 유명한 공유기중에서도 제일 안나기로 유명한 리비전입니다.

유선 100mbps, 무선 11g 밖에 지원하지 않는 구형이지만, 여전히 한번 써본 사람들은 11n 공유기가 있음에도 혼용해서 쓰거나 뜯지도 않을 정도로 많은 분들이 애용하는 공유기입니다.

그 정도로 좋고 요즘은 시중에서 보기 힘든, 공유기 안정성으로는 레전드로 칭해도 괜찮은 공유기인데요.

누가 학교에 일반 쓰레기로 버렸더라구요.

<ⓒ 영광군청>

재활용합시다.

어쨌든, 리비전 7 8은 지금도 쉽게 구하지만 리비전 2는 중고로도 구하기 힘든 공유기입니다. 중3? 고1때 모 Wireless lab에 반납한 뒤로 처음 보게되어 되게 설레네요.

일단 공유기를 위 사진과 같이 전원을 공급하고, 컴퓨터와 연결했습니다.

먼저 공유기가 정상 작동을 하는지를 진단하기 위함인데요.

먼저, 저는 820라인에 32g램으로 워크스테이션처럼 굴리기 때문에 랜카드가 다수 설치되어 있어 아이피 대역 충돌이 예상되는 랜카드를 먼저 Off 했습니다.

그 다음 54g가 연결된 이더넷 2의 정보를 확인하니 게이트웨이가 192.168.1.1이네요.

TFTP 방식도 있지만, TFTP는 처음 접하는 분들은 꺼리는 방법이고, 실제로 위험하기도 해서 WebGUI로 먼저 테스트했습니다.

다행히 펌웨어가 잘 올라오고 lan을 하나 더 빼서 다른 공유기에 물려보니 외부 통신도 잘 진행이 됩니다.

이제 DD-WRT 펌웨어로 펌웨어를 교체하는데요.

주의사항이 있습니다.

하드웨어의 내장 프로그램을 교체하는 만큼 아래의 작업을 신중하게 해주셔야 합니다.

SW적인 오작동은 TFTP로 복구가 가능하지만, HW적인 오작동을 하는 순간 그 공유기는 더 이상 살릴 수 없습니다.(수리비가 더 나가죠)

다음으로 30/30/30 Hard Reset을 수행합니다.

30/30/30 하드 리셋은 공유기의 롬을 완전히 초기화하는 기능입니다.

공유기 기종에 따라서 WebGUI에 아무 데이터가 없는 상태로 초기화 되는 것부터, Web마저 동작하지 않는, TFTP만 살아있는 깡통이 되기까지의 상태로 공유기가 필요 최소한의 기능만 제외하고 전부 초기화되는 것을 의미합니다.

WRT 이식에 있어 공장 초기화보다 로우레벨의 초기화를 수행해야 이기종 펌웨어 이식에 문제가 없습니다.

리셋이 끝나면 공유기와 컴퓨터를 연결한 뒤, 아이피는 192.168.1.7 / Sub 255.255.255.0 주시고 192.168.1.1 로 연결합니다.

Administration -> Firmware Upgrade -> 파일 선택을 눌러 DD-WRT 펌웨어를 엽니다.

펌웨어는 RouterDatabases 에서 구할 수 있으며 자신의 기종과 리비전에 맞는 펌웨어중 가장 최신의 바이너리를 다운로드 합니다.

다운로드는 공유기마다 상이하지만 일반적으로 동일 버전 동일 패키지의 mini, std 두가지가 필요합니다.

mini와 std 두가지를 전부 내려받는 이유는

mini는 일종의 인터페이스 역할을 합니다.

Java에도 interface가 있고 Delphi에도 interface가 있죠?

mini는 DD-WRT의 본체가 이식되기 전 먼저 파티셔닝과 사전설치를 해주는 펌웨어입니다.

이놈을 통해서 DD-WRT의 본체가 이식이 되게 됩니다.

Router Databases 에서 본인의 기종 모델명을 검색한 뒤, Revision이 일치하는 레코드를 클릭합니다.

자신의 FLASH 용량을 체크하고, 지원하는 버전중 고르고(안전한 커펌을 원하면 pre가 있는 빌드는 사용하지 마세요) 다운로드 합니다.

저는 여기서 v24SP2 Build 13064 빈티지 버전을 사용했습니다.

이제 다운로드한 파일 중 mini를 선택해서 열고 

Upgrade를 누르면 아래와 같이 진행이 됩니다.

경과 시간은 약 3~4분정도 걸립니다.

폄웨어 교체하는 동안 절대 전원에 문제가 생기면 안됩니다.

잠시 기다리면 완료 되었다는 메시지가 나옵니다.

다시 주소창의 url을 지우고 192.168.1.1 로 접속합니다.

우측 상단에 mini가 보이고 v24sp2가 정상적으로 업로드 되었음을 볼 수 있습니다.

Memory -> Total Available의 손실된 2.4MB는 손실된 것이 아니라 펌웨어가 설치되어 소모된 메모리 용량이니 걱정하지 않으셔도 됩니다. (사실은 제가 처음에 그랬거든요. 손상된줄 알고 ㅋㅋ)

이제 다시 Administration -> Firmware Upgrade 로 들어가서 

파일 선택을 누르고 이번엔 std, 스탠다드를 엽니다.

그리고 Upgrade를 누르면 아래와 같이 진행이 되며 잠시 후 공유기로 재접속이 됩니다.

업그레이드 대기 시간은 최대 300초로 보통은 1분 전후로 끝납니다.

(예, 사실 54g 시간 측정 안했습니다._. WNDR3700은 1분 정도면 끝나더군요)

정상적으로 업그레이드가 되면 우측 상단에 mini가 std로 변경됨을 보실 수 있습니다.

이제 원하는 대로 설정해서 사용하시면 되며 비교적 최신 기종이어서 향후 업데이트가 나오는 기종이라면 별도의 설명이 없다면 Firmware Upgrade에서 std 파일만 바로 올리셔도 됩니다.

WNDR3700 기준으로 13년 이후로 sp는 중단되었지만, 이후 빌드는 16/11/14 기준 30880을 마지막으로 계속 나오고 있네요.

php에서 현재의 시간으로부터 특정 시간의 값을 취하고 싶을 때

방법 1에서

format 에는

interval 에는

방법 2에서

DateInterval 에는

P+

델파이는 Try ... except ... end 로 예외처리를 지원하고 있고 Indy 또한 Error Exception을 지원합니다.

하지만 예전에는 Indy의 exception이 IdException에 정의되어 있었습니다.

하지만 지금은 IdException을 uses 하면 파일이 있다고 나오지만

예전 코드나 예제는 더이상 사용할 수 없습니다.

왜냐하면 에러 정의가 IdException이 아닌 IdStack으로 옮겨졌기 때문입니다. 

그래서 옛날 코드나 예제를 사용하면 특정 인디 버전부터는 E2003 Undeclared identifier 에러가 발생합니다.

델파이는 대부분의 예제가 08년 09년을 기점으로 그 이전에 많이 기록이 남아 있습니다.

이제는 인디 컴포넌트의 예외처리를 하려면 IdStack을 uses해야 합니다.

위와 같이 처리하면 됩니다.

위 코드는 서버 접속 시 10060 Time Out 에러에 대한 예외처리를 하고 있습니다.

어느 상황의 에러가 어떤 코드인지 알고 싶다면, 아래 사이트를 참고하세요.