More content might be added when I have time.

Hardware

A comparison of the compute nodes in the following table. The characteristics are relatively similar, but ABCI is generally more powerful and uses slightly more recent hardware.

In particular, one would not train a mixed-precision model on TSUBAME.

Trial Jobs

TSUBAME 3.0 allows one to submit up to two trial jobs using qsub. This is not supported in ABCI.

(Getting a shell through a trial job via qrsh seems to be rather tricky, possibly because trial jobs have extremely low priority. For the time being the cause of this is inconclusive.)

Interactive Node

TSUBAME has the interactive node world accessible through the following domain - which is load balanced between two nodes. (login0 and login1 - both can be accessed directly by changing the name in the domain.)

login.t3.gsic.titech.ac.jp

ABCI on the other hand does not allow direct access to the interactive node, and one needs to go through a proxy. The proxy is on the domain:

as.abci.ai

And one needs to use this as a jump node to get to the actual login servers. This can be done by ssh-ing into as.abci.ai, then ssh-ing into es. This is tedious and annoying, but recent versions of OpenSSH simplify this through a feature called "jump hosts". Ignore the official documentation - which gives you a convoluted method for connecting and use this:

ssh -J username@as.abci.ai username@es

es is load balanced between 4 nodes, which can be accessed directly.

Requesting Resources

Since both use the exact same job scheduler (Univa Grid Engine) - job submission generally works the same. The only thing you need to change when requesting a resource is the type, so the following command in TSUBAME:

qrsh -g my-tsubame-group -l q_node=1 -l h_rt=00:10:00

Would be this in ABCI:

qrsh -g my-abci-group -l rt_F=1 -l h_rt=00:10:00

Same rules apply in job scripts.

Module Naming

Both systems use GNU module to enable optional software packages. The naming convention is slightly different - ABCI uses two levels for module versions, while TSUBAME only uses a top level.

• ABCI: cuda/10.0/10.0.130
• TSUBAME: cuda/10.0.130

Choosing The Right Computer

ABCI is 2.5x more expensive than TSUBAME (for Tokyo Tech users, if your project billing falls under 第4条第4項(成果非公開), then it's a 25% difference.) - so the general rule of thumb seems to be this:

• I absolutely need FP16: ABCI, although it's worth noting that one can get 2x the nodes on TSUBAME so if you can setup distributed training, it might be more cost effective to do it there.
• I need more than 256GB RAM: ABCI
• I need lots of CPU cores: ABCI
• I need bleeding edge CPU instructions: ABCI
• TSUBAME is overbooked: ABCI, obviously
• Otherwise: TSUBAME

That said, both are way cheaper than EC2 or GCP.

Closing Remarks

I wish TSUBAME billing could be simplified, the points system seems to be designed to obfuscate how much money one is spending on compute.

Microsoft에서 지지난주에 Internet Explorer의 후속으로 개발하던 브라우저 Edge의 (코드명: Spartan) 엔진 개발을 중단하고, Chromium기반의 브라우저로 새로이 내놓겠다는 기사를 보았다. 소문은 그 이전에 돌기 시작하였는데, 이게 발표되고 나서 충격이 컸던건 사실이다.

전 직장이었던 Opera의 Presto엔진 개발 중단에 이어, 두번째 대형 엔진의 개발 포기 소식이다. 이에 대해서는 현재 소속 되어있는 Technical Architecture Group에서도 의견이 많이 나뉜다. 이는 어디까지나 개인적인 의견이지만, 단기적으로 보았을때는 컨텐츠 개발 편의성에 측면에서는 좋은 소식일 수 있으나 장기적인 웹의 미래를 생각한다면 좋으 소식이라고 하기 힘들다.

사람들이 Edge를 어떻게 생각했는지 모르겠지만, 브라우저 엔지니어링을 8.5년 해본 입장에서 봤을때는 굉장히 잘 만든 브라우저라고 생각해서 더욱 안타깝고, 나아가 노력이 아깝다는 생각이 들었다.

같은 주제에 대해 Andre Garzia씨가 쓴 글을 인용하면, 브라우저 엔진이 없어지는것은 세상에 언어가 없어지는것과 같다는 표현을 한다. 사실 어떻게 표현을 해야할지 좋은 아이디어가 떠오르지 않았는데, 적절한 예를 든 것 같다. 모두가 같은 언어를 사용한다면, 일반적인 관점에서는 편할 수 있으나 단일 문화가 정착되는 시점에서 그게 당연시되고, 그 당연시 됨에 따라 사실상 새로운 언어, 아울러 소수 언어가 소외되는 현상이 당연히 발생하게 된다.

기억을 더듬어보면 IE가 시장 주도권을 가졌던 시절 상당수 컨텐츠가 IE만을 지원했었다. 비주류 브라우저를 이용하는 사용자들은 엄청난 불편함을 감수하거나 윈도우와 IE를 병행해서 사용해야만 했다. (공고롭게도, 지금도 이렇게 해야하는 사이트가 남아있다.) 시장은 비주류 브라우저에게 혹독한 현실이었고, 회사에서 그러한 브라우저들 지원을 한다고 하면 [1] 보통 시간 낭비한다는 소리를 듣곤 하였다.

이러한 어려운 상황을 여러 사람이 열정적으로 합심하여 지금의 새로운 HTML로 표준화를 성공적으로 해냈고, 덕분에 플래시나 기타 플러그인에 의존하던 컨텐츠 대부분이 지금은 표준 기술만으로 구성되어 비교적 잘 돌아가고 있고, 어느 브라우저를 사용하든 [2] 대부분의 웹 서비스 기능은 이용할 수 있는 세상이 만들어지나 싶더니 이런 일이 생겨버린건 결코 긍정적으로 보기는 힘들다.

Chromium이 주류 브라우저가 된 지금, 이미 이러한 어두운 과거로 회귀하는 현상이 조금씩 보이고 있다. 특히 국내가 그런 현상이 심한 편인데, 모노컬쳐를 조장하는 행위다. 이미 엎질러진 물, [3] 이제는 컨텐츠 개발자들이 웹을 지킬 수 밖에 없게 되었다.

닭과 달걀의 문제로 보일 수 있겠지만, 유저 이전에 컨텐츠가 있다. 컨텐츠가 없는 웹 브라우저는 그저 about:blank가 담긴 창이니. 그러니 여러 사람이 이런 문제를 심각하게 받아들이고, 웹이라는 사회의 균형이 더 무너지지는 않게 모두가 신경을 써줘야만 살아남을 수 있다는 걸 이야기하고 싶다.

이제는 새로운 브라우저 엔진이 나오기에 웹은 너무 기능이 많기 때문에 이번에 무너지면 IE 독점 시장 시절과 같은 빙하기를 다시 한번, 이번에는 더욱 길게 경험하게 될꺼라는걸 잊지 말고 [4] 호환성을 지켜줬으면 하는 작은 바램이다.

1. 사실 나의 경우에는 넷스케이프 호환성을 맞출 수 있다는 이유로 틈새 시장의 이득을 보고, 그러한 잡기술이 바탕이 되어 결국 브라우저 회사에 취업을 할 수 있게 되었지만 이건 특수한 케이스라고 생각한다.
2. 단, 국내 정부 관련 서비스나 금융권은 특수 케이스로 예외로 치자. 이것 관련해서는 쓰던 글이 있었는데 시간이 되면 마저 썰을 푸는걸로.
3. Chromium은 오픈소스 프로젝트이지만, 관리 체계가 상당히 특이하다. 현재 구조에는 개선이 필요한데, 이와 관련해서는 나중에 시간이 허락할때 따로 생각을 좀 정리해볼 예정이다.
4. 특히, 요새는 Polyfill들이 잘 나오니 적극적으로 활용해주면 이게 어렵지 않게 가능하다. Polyfill.io 같은 서비스를 쓰면 브라우저 버전에 맞는 Polyfill을 내려주니 이런 서비스를 적극적으로 이용하자.

So here is the background story. It isn't a very interesting one. If you were expecting me talking about gender identity and what not, this isn't it. (Although I do wonder sometimes if I am a fish. More on that sometime later.)

So if that was what you were looking for - feel free to hit the back button.

Back in 1995, there was a public and free Unix system which one could sign up, login and try well, anything. This was provided by a Korean company that probably had an unused SunOS machine just doing nothing, and one of the employees probably just thought it would be a cool idea.

Back then - stuff like this was fine to do - nowadays, well - you know what would happen to services like this.

(I had already completely destroyed my dad's computer attempting to install Linux with a pile of bad sector polluted floppy disks and a poorly written guide on how to do it - so having a Unix compatible system at home really wasn't an option.)

So it turns out - this free service had a couple limitations - one was that your shell account was limited to 4-8 characters, was case insensitive (requests would be lowercase converted) - and thanks to that little quirk, almost any commonly imaginable English word - including my surname and my name were all taken. (I was at a friend's place - who also happened to have a slightly better modem than I did, and parents who wouldn't go crazy on the phone bill.)

If I roughly remember what we tried - this is the rough list: (Personal information redacted)

• moon
• sangwhan
• moon[birthYYYY]
• [birthYYYY]moon
• moon[birthmmdd]
• [birthmmdd]moon
• ...and some other ones, can't remember them all.

Then we pulled out a dictionary looking for anything useful under the word "moon", because we ran out of options.

• lunar
• lunatic: This would have been cool.
• ...and through the entire list. Which wasn't long.

No avail. However, it turns out that my friend's father was a hard core Christian and even doing a part-time program in graduate school studying related topics - and had an old Korean-Latin dictionary sitting around. So we took that, and went through the list of words that meant "moon".

The first option was diana, which was clearly a feminine name - so we that skipped that one. The next one in the list was cynthia. Little did this dictionary note that it was the goddess of the moon, not just the moon - so I went for that. This wouldn't have happened in 2018, since - Wikipedia. Google. Or well, actual internet.

I have never heard anyone with this name, so little did I know this was feminine [1] - only having limited exposure to the western world. [2]

So, to this day - all of the accounts which are somewhat related to PAM authentication of some form are "cynthia". I don't really have a good excuse - my fingers have been typing that for 22 years and counting, and I'm too lazy to have different account names across different machines.

I learned the lesson about muscle memory the hard way, as my previous employer forced me to use something that resembled my name - "smoon" in this case. Now at my new workplace I am back to cynthia. If I do hire a real Cynthia, then well - sucks to be her.

To give you a rough idea of how reluctant to change I am - my current macOS home directory (on a Retina 2012) is a cumulative migration which started from a Titanium Powerbook G4 in 2002.

[1] There was a gut feeling that this sort of felt feminine, but shit - it was supposed to be Latin, what would I know.

[2] This is probably why "English" names from people of Chinese heritage countries (e.g. Taiwan) around my age have some occasional surprises. My favorite to this day is Piggyboy - who was a customer contact at my previous workplace. I am not making this up.

NOTA BENE: Following this tutorial will most likely result in voiding multiple warranties across multiple devices. If done incorrectly this may result in extreme consequences - including fires, battery and or charger explosions and overheating, short circuits which can have consequences including burning your house or building down. The author takes no responsibility for damage caused by performing this modification.

Do not use the modified adapter on any 15 inch Macbook device, as the Finsix Dart is unable to provide the required output to sufficiently drive the device.

Please note that the final result of this has not been properly tested with lab equipment. Also note that the output of the Dart is 20VDC, while Magsafe 1 power supplies output 16.5VDC. While I have used a Magsafe 1 connector here (mostly because I had a readily available broken power supply to cut the cable off of), I used a Magsafe 2 converter and have not actually charged a Magsafe 1 device with this. If you plan to charge a Magsafe 1 device, it might be worth double checking if the output voltage is a safe setup or not.

TL:DR; for the experienced: 1) Get compatible connectors from eBay or Amazon (Links below) 2) wire up with a donor Magsafe.

Now that we have gone through that...

The Finsix Dart is a compact charger for laptops which comes a large set of tips that allows you to charge almost any laptop on the market. However, this does not include any Apple devices - mostly due to the legal complications for shipping Magsafe compatible devices. (There are rumors of Magsafe tips that shipped to Kickstarter backers, but I was unable to find any proof that these actually exist as none of them turned up in the used market.)

Parts needed:

• Magsafe (1 or 2) cable: You can get these from eBay as repair parts, or cut them off of a broken charger. Cut it roughly 10cm from the charger.
• Finsix compatible connectors: Finsix uses a proprietary connector, which is luckily a very simple form factor so finding one that fits isn't too hard. These are mostly sold as "outdoor waterproof LED cables" on either eBay or Aliexpress. Amazon Japan also has these here.
• Electric tape: As we are dealing with 20VDC, you absolutely want proper insulation. Don't cheap out on this.
• Multimeter: Any cheap multimeter that can test continuity (the "beep" mode) should do.
• EMI filters (optional): This isn't strictly necessary, but is a neat trick for hiding electric tape while doing passive filtering. Two birds, one stone. Get one that fits 5mm gauge wire. I used this.
• Solder kit (optional): If you want a slightly more secure connection between the two wires, this is strongly recommended.
• Wire stripper: Any stripper that can handle small gauge wires should work. I used a Vessel 3500 E-2.
• Knife (optional): A standard office paper knife or X-ACTO blade should do.

The Dart uses a connector that looks roughly like the diagram above. It is a circular connector, with one side cut out. This perfectly fits the connector that we are going to use, but as the connector only has a very small ridge to prevent incorrect polarity you need to be careful when connecting it. (Normally, you won't have to do this too often. I use the ridge as a visual indicator for the polarity.)

These LED cable connectors do not come with any standard wire color coding scheme (mind was brown/blue, which makes no sense), so you will need to use a multimeter to find out which one maps to which color, then make sure GND connects to GND on the Magsafe, and VCC maps to VCC.

Normally, if you cut a Magsafe cable - there are two internal cables - one white and one black. Black is GND, which maps to pin 1 and 5, and white is VCC which maps to 2 and 4. 3 is connected to a negotiation chip inside the connector, so there is no wire that corresponds to that pin. If you are using a aftermarket repair cable (e.g. eBay, Aliexpress) the colors may not match the genuine cables, so please test with a multimeter to ensure polarity.

Whatever combination you come up with using a multimeter, strip both sides of the wire around 1cm, connect the two wire pairs, isolate them with a piece of paper so they are not shorted, connect it to the Dart USB cable and test them by checking if pin 1 and 5 on the Magsafe maps to GND on the Dart cable, and 2 and 4 to VCC on the Dart cable.

Depending on the connector you used, you may need to use a shave off a bit of plastic on the compatible connector for a tighter fit.

Test between the two connectors as seen in photo above.

Now that you have everything in place, test continuity between the charger end of the Dart USB cable and the Magsafe pins. Make sure you test these combinations:

• Magsafe 1/5 to GND: Should be connected
• Magsafe 2/4 to VCC: Should be connected
• Magsafe 1/5 to VCC: Should not be connected
• Magsafe 2/4 to GND: Should not be connected

All four tests (or all 8 tests) should pass, otherwise something is wrong. If only one of the pin pairs (e.g. pin 1 connects to GND, but 5 does not) check for continuity, then it is most likely you have a broken Magsafe connector, and might want to throw it out.

When all of the tests have passed, either you can solder the wire pairs for stability or just tape it up with electric tape. After you are done, repeat the same continuity tests again and make sure nothing has changed. Mistakes here can happen, so make sure you test for short circuits.

(Optional) When you are done, wrap it up with enough electric tape so the tape thickness roughly matches up with the original Magsafe wire's gauge, then clip on a EMI filter for a more professional look.

First, you will need to create a self signed certificate. This can be done using the following command. (Example is valid for 10 years, Do not do this in production. Bad idea.)

openssl req -new -x509 -keyout /usr/local/etc/local-server.pem -out /usr/local/etc/local-server.pem -days 3650 -nodes

Then. you will need to start a local server that uses this certificate and serves HTTPS. The following snippet should be placed in a convenient location for execution, in my case I put it in /usr/local/bin/https-server. Put it wherever works for you, and add a +x bit. This is for Python 2.7. (or near versions.)

#!/usr/bin/python
import BaseHTTPServer, SimpleHTTPServer
import ssl
httpd = BaseHTTPServer.HTTPServer(('localhost', 4443), SimpleHTTPServer.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket (httpd.socket, certfile='/usr/local/etc/local-server.pem', server_side=True)
httpd.serve_forever()

(Note: The HTTP server modules have been moved in Python 3.x, so that will need to be patched.)

Now, go to the directory where you have the SW based application running. For the example of our JavaScript SDK, this will be the root of the checked out repository. Run the https-server script. If you prefer a standard port, you will need to change the line that mentioned 4443 above to 443, and run the server as root. This is not recommended.

The following example only covers Chrome. Other implementations probably involve different tricks for working around certificate validation.

Close all instances of Chrome. (or whatever Chrome based browser you are running) Make sure the root process is completely dead, and not just all the tabs closed. Now, start Chrome with the following flags:

--ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:4443

On macOS, this would normally be:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome  --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:4443

On Linux, this would normally be:

google-chrome  --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:4443

Now, you can go to https://localhost:4443 and debug your service worker locally. When you are done, make sure you shutdown the current browser instance - as the flag overrides are not safe for everyday browsing.

I luckily found some readymade Python bindings, but with extremely limited documentation, and missing key pieces to get this working.

https://github.com/georgedimitriadis/t_sne_bhcuda

Turns out that the binary building part was completely omitted in the repository, so here are pre-built binaries which I made for my own use.

Obviously, this comes with no warranty. If this works for you, good, if it doesn't - you are on your own.

Ubuntu Linux 16.04, CUDA 8.0:
https://sangwhan.com/freeware/t_sne_bhcuda

macOS 10.10, CUDA 7.5:
https://sangwhan.com/freeware/t_sne_bhcuda75

Place this into the bin directory of your checkout, and the library should work as expected. (The unfortunate bit is as this relies on a external binary, there is a lot of I/O and lexical casting involved - which I plan to look into someday.)

If the perplexity is too small, it will trip and trigger a assertion with very little useful information to debug the problem. If it doesn't work, try reducing the perplexity. (More on what that is in the official page, link above.)

One thing to note: There is an interesting bug in the implementation's VRAM calculation routine. (which I didn't bother looking into) Setting gpu_mem to a value above 0.9 triggers VRAM OOM. (It seems to think a Titan X has 13.2GBs of memory, based on the actual allocated VRAM and ratio I used.)

I use the binary outside of the Python binding as well, so in my case, I replaced the _find_exe_dir() helper in my site-package installation.

def _find_exe_dir():
    exe_dir = '/usr/local/bin'
    exe_file = 't_sne_bhcuda'

    return path_join(exe_dir, exe_file)

Both binaries are for 64-bit systems.

Example code: (Taken from the original source)

import t_sne_bhcuda.bhtsne_cuda as tsne_bhcuda
import matplotlib.pyplot as plt
import numpy as np

perplexity = 50.0
theta = 0.5
learning_rate = 200.0
iterations = 2000
gpu_mem = 0.8

t_sne_result = tsne_bhcuda.t_sne(samples=data_for_tsne, files_dir='/home/user/wherever', no_dims=2, perplexity=perplexity, eta=learning_rate, theta=theta, iterations=iterations, gpu_mem=gpu_mem, randseed=-1, verbose=2)
t_sne_result = np.transpose(t_sne_result)

fig = plt.figure()
ax = fig.add_subplot(111)
ax.scatter(t_sne_result[0], t_sne_result[1])
plt.show()

Step by step instructions:

1. Git clone Python bindings repository from Github.
2. Make bin directory, download binary for your platform and drop it in there with the filename t_sne_bhcuda
3. Alternatively, use the patch above and drop it into /usr/local/bin, same filename.
4. Use the example code above.

• Master 와 Slaveê°€ 있어 두개가 같은 설정으로 유지되었으면 했다.
• DNS의 내장 기능을 이용해도 되겠지만, MySQL의 master-slave replication을 이용하여 한개 노드가 실패할 경우 바로 masterë¡œ 사용할 수 있게 하고 싶었다.
• DHCP는 그냥 pkg에서 설치하면 되는 문제여서 큰 난관이 없었다.

여기서 문제가 하나 발생하게 되는데, FreeBSD pkg repository에 있는 powerdns 패키지에는 MySQL 백엔드가 아닌 Postgres 백엔드만 포함되어 있다는 것이었다.

일반적으로 Postgres를 사용할 줄 아는 경우라면 큰 문제가 되지 않는데, 공교롭게도 사내에서 Postgres를 다뤄본 경험이 있는 사람이 1명 밖에 없어 single point of failure의 위험성이 있었다. 그리하여, MySQL 백엔드를 포함하여 새로 빌드하기로.

설치에 앞서, 의존성이 최근에 추가된게 하나 있어 해당 의존성을 위해 pandoc이라는 문서 프리프로세서의 설치가 필요하다. (이전에 패키지 명칭이 pandoc 이었으니 만약에 아래 명령으로 설치가 안된다면 pandoc 으로 바꿔보면 될 수도 있다.)

pkg install hs-pandoc

컴파일 방법은 공식 문서에 있는 그대로 따라했고, 추가한건 MySQL 백엔드를 활성화 시켜준 것 밖에 없다. 명령은 아래와 같다.

./configure --with-modules="bind gmysql"

우분투의 build-essential에 해당하는것을 설치하고 (이와 관련해서는 이전 글에 설명 되어있으니 참고하면 된다.) 빌드를 진행하는데, 괴상한 컴파일 오류를 경험하게 되었다. (내가 겪었던 컴파일 에러는 터미널 스크롤백의 신들에게 재물로 바쳐졌기 때문에 더 이상 없다. 굳이 해당 refspec을 찾아가서 재현해보기는 귀찮으나, 궁극적으로는 같은 에러이다.)

이 오류의 원인은 대부분의 청중에게 의미가 없을 듯 하여, 이 글에서는 설명하지 않겠다. (명시적으로 생성된 std::string과 묵시적으로 생성된 std::string의 수명과 reference tuple 안에 rvalue를 담을 수 있는가 없는가에 대해 표준의 과도한 해석을 clang에서 하고 있는 문제인데, 더 이야기를 하자면 복잡하니 생략. 내용이 궁금하면 PR을 보면 된다.)

불행 중 다행은 나 말고 이 문제를 겪은 사람이 있다는 것이었고, 적어도 우리 환경에 한정된 문제가 아니었다는 것이다.

추가 (45879fae66a5fbc37d1edf32b2b9337383140d2f 기준): FreeBSD 빌드가 또 망가져버려서, PR#5067의 패치가 필요하고, export CXXFLAGS=-std=c++11을 추가해주어야 한다.

오픈소스의 문제점

여기서 문제는 깃헙에 버그 리포트가 들어간 날짜는 3월 11이었다는 것이고, 내가 이 문제를 겪은것은 10월 3일이었다는 것이다. 1줄 짜리 컴파일 에러 하나를 수정하는데 7달 동안 아무도 손을 대지 않았다는 것이다.

오픈소스의 문제점은 생산을 하는 사람이 소비를 하는 사람보다 월등하게 적다는 것이다. 특히나 난이도 높은 근본 라이브러리일수록 (특히, C/C++일 경우 이 문제가 심각하다) 사람들이 기여를 안하고 쓰기만 한다는 것이다. 문제는 기여를 하는 사람들이 적고, 요구사항을 외치는 유저들만 너무 많아 대응이 안되는 시점에 기여를 하던 사람들도 결국에는 하나씩 번아웃을 하여 오픈소스에 기여하는 것을 포기한다는 것이다.

한 줄짜리 패치 보내면서 생색 내는것 같지만, 이렇게라도 하는 사람이 너무 없는게 현실이다. 다행히도, PowerDNS 커미터들이 내 패치를 빠르게 (하루 걸렸던것으로 기억된다) PR을 반영해주었고, BSD + clang 환경 호환성 문제가 어렵지 않게 해결되었다.

오픈소스를 갖다 쓰지만 말고, 문제가 있으면 문제가 있다고 보고만 하던가 그냥 쉽게 동작하는 다른 라이브러리를 택하는 경우가 많은데 만약에 해결을 할 수 있는 문제면 해결을 해서 기여도 했으면 하는 바램이다.

삭제된 내용

원래 글에는 PowerDNS 설정 관련된 내용도 있었으나, 회사 내에서 PowerDNS를 사용하는 목적이 내부 DNS 및 비표준 내부 TLD를 지원 하기 위한 목적이어서 설정 공유를 하면 혼란만 있을 것 같아 (해당 설정을 그대로 복제하였을 경우 정상적인 DNS 환경이 아닌 특수한 환경으로 설정되어 버리기 때문에), 처음 작성한 내용에서 삭제하였다.

추가된 내용

2017.2.22: Pandoc 의존성 관련 내용 추가.

해당 버그는 수정이 된 상태이나, 부팅을 담당하는 모듈이 부팅을 완료하지 못하는 버그가 있는 상태에서 릴리즈가 되었다는 것 자체에 대해서 신뢰도의 문제가 있어, 일단은 당분간은 사내에 systemd를 사용하는 배포판의 도입은 미루는 것으로 하고, 그 사이에 대책을 조금 고민하다 systemd와 연이 있을래야 있을 수 없는 BSD를 사용하기로 하였다. (아울러 개인적으로 Lennart Poettering의 철학과 동의하지 않는다. 이건 어디까지나 사족이지만...)

여러가지를 검토하다 (DragonflyBSD를 특히 유심히 보았다) 결국은 해본적이 있는 FreeBSD로 결정을 하였는데, 오랫만에 해보니 (마지막으로 양산에서 썼던게 4.x대였던걸로 기억된다.) 저쪽 환경에 너무 익숙해져버려 불편한 점이 한두가지가 아니었다. 그래서 조금 환경을 비슷하게 맞추는 과정의 기록을 남기기로.

FreeBSD는 apt-get이나 yum이 없고, 자체 패키지 매니져를 사용한다. ports와 pkg 두 가지 중에서 선택을 할 수 있는데, 전자는 소스 빌드라고 생각하면 되고 후자는 빌드 된 바이너리를 사용한다. 배포 대상 하드웨어가 흔해빠진 인텔이어서, 아래 예시에는 시간 절약을 위해 후자를 사용하였다. 이전에 양산때에는 서버가 DEC Alpha여서 포트로 다 빌드를 했던 (좋지 않은) 기억이 있다.

설치 자체는 인스톨러를 사용할 경우 크게 어려움이 없으니 설명을 생략하고, 환경을 조금이나마 근대적인 환경으로 사용할 수 있도록 하는 방법을 공유하면 도움이 될 사람이 있을까 싶어 문서화. (이 서버들의 경우에는 ZFS 전체 디스크 사용으로 자동 설정, 나머지는 거의 기본 설정, 단 games 메타 패키지는 뺐다.)

한 가지 주의할 점이 있다면, 서버 목적이라면 설치 과정 중 사용자 계정 추가시 관리자는 wheel 그룹에 넣어주는게 좋다는 것 정도가 되겠다. OpenSSH 설치 기본 옵션에 root 로그인이 금지되어 있는데, wheel 그룹에 넣어줘야 su가 된다. (FreeBSD는 기본 배포시 sudo가 없다. 필요하면 설치해서 사용해야한다.) 이걸 까먹으면 이후에 물리적으로 서버에 가서 작업을 한번 해줘야하는 문제가 발생하니 주의하도록 하자.

개인적으로 사용중인 노트북 모니터가 작아서, motd가 보지 않을 내용이 너무 많이 표시되어 빈 내용으로 삭제.

mv /etc/motd /etc/motd.bak
touch /etc/motd

FreeBSD에는 설치시 컴파일러가 (10.x 설치시 LLVM 3.7이 깔려있다.) 따라오나 build-essential에 해당되는 메타패키지가 없어 이걸 알아서 조립을 해야한다. 아래가 그것.

pkg install autoconf automake devel/pkgconf libtool bison gmake ragel devel/boost-all git

이 중에서 매우 중요한것이 gmake이다. FreeBSD는 자체적인 make를 포함하여 배포를 하는데, GNU Make와 호환이 되지 않기 때문에 상당수 오픈 소스 프로젝트가 빌드가 되지 않는다. 마지막 2개는 나의 경우에는 필요했는데, 필요하지 않을 경우에는 생략하여도 된다.

상당수 오픈소스 프로젝트는 Makefile내에 게으르게 gcc/g++를 쓰도록 하드 코딩 되어있다. 컴파일러가 깔려있는 마당에 굳이 GNU Compiler를 설치할 의미는 없는듯 하여, 이 부분은 macOS에서 애플이 사용하는 꼼수를 사용하였다.

# 이런 짓 자주 하면 지옥 간다.
ln -s /usr/local/llvm37/bin/clang /usr/local/bin/gcc
ln -s /usr/local/llvm37/bin/clang++ /usr/local/bin/g++

사용하는 FreeBSD 버전에 따라 /usr/local/llvm[0-9]+ 에서 사용하고 싶은 버전을 찾아서 써주면 된다.

마지막으로, FreeBSD는 기본으로 쉘로 csh를, 기본 에디터로 BSD vi를 사용하는데, 상당 수 프로젝트들이 (아울러 사내 프로젝트들) bashism이 심하고, BSD vi의 기능상 제약이 많아 전역 bash 설정의 alias 레벨에서 바꾸었다. 아울러 make도 gmake로 alias. bash 사용자에만 해당되지만, rootfs를 손상시키지 않고 익숙한 환경을 유지할 수가 있는 편법이다.

/etc/profile 하단에 아래 내용 추가

if [ "$PS1" ]; then
  if [ "$BASH" ] && [ "$BASH" != "/bin/sh" ]; then
    . /etc/bash.bashrc
  fi
fi

/etc/bash.bashrc 작성

# Better prompt for both normal and sudo
PS1='[\u@\h \W]\$ '
SUDO_PS1='[\u@\h \W]\$ '

export TERM=xterm-color
export CLICOLOR=1
export LSCOLORS=ExFxCxDxBxegedabagacad

# BSD ls uses a different parameter for colorization
alias ls="ls -G"
alias l="ls -lG"
alias ll="ls -lGa"
alias vi="vim"
# BSD make isn't particularly useful, so replace that with gmake
alias make="gmake"

BSD ls의 경우는 색상 표시를 위한 옵션이 다르다. BSD에서 제공하는 coreutils에 해당되는 명령의 경우 GNU에 비해서 기능이 없거나, 사용 방법이 달라 불편함이 있을 수 있다. GNU에만 있는 기능들이 필요할 경우, sysutils/coreutils를 설치하면 된다. (현재 작업중인 배포 환경에는 디스크 용량 절약을 위해 coreutils설치를 하지 않았다.)

PowerDNS 설치법은 다음 글에.

최근에 NLP 처리 관련 ML 작업을 조금 하고 있는데, training iteration을 조금 더 단순화 하기 위해서 코드를 매번 바꾸는 형식 아니라 웹이나 CLI로 만들어서 고민하던 중 CLI를 만들어볼까 하다가 발견한 python-prompt-toolkit 이라는 페이지에서 우연히 발견하였다.

설치에 큰 노력이 들지 않아 설치해봤는데, 이게 꽤 물건이다. iPython을 버려도 될 정도로 훌륭하다. Quicksilver에서 Alfred로 넘어갔을때 처럼 30분 써보고 바로 결정하는 일이 잘 없는데, 이게 딱 그 경우.

이렇게 여러가지 설정도 제공하고, iPython 처럼 사용도 가능하다.

오류가 발생하면 구문 에러를 출력하고 위치를 알려주는게 아니라, 구문 에러가 나는 곳으로 커서가 이동이 된다.

vi 식으로 코드 편집도 가능해서, u를 이용해서 NAV 모드에서 ìž…ë ¥ 취소도 가능하다. 위 스크린샷은 Esc, Esc, w, w, cw, ;, Spaceë¡œ 오류를 ë³´ì •í•œ 모습.

히스토리 화면에서 전에 입력했던 이력을 짜집기해서 프로그램을 만들 수도 있다. 이건 꽤나 괜찮은 듯. 기능을 좀 더 확인해봐야겠지만, 왜 더 알려지지 않았는지 신기할 정도로 훌륭한 REPL이다.

아쉬운 점은, 자동 완성이 iPython에서 개선된것 같지는 않다. 동일한 버그(?)들이 있다. (그래도 Jupyter 보다야...)

위 스샷이 문제의 Photos.app

다행히도, 아래 명령으로 모든 장치에 대해서 영원히 이 기능을 꺼버릴 수 있다.

defaults -currentHost write com.apple.ImageCapture disableHotPlug -bool YES

또는 아래 명령 (iTerm 3.0.5 기준으로는 유효하나, 이후에 바뀔 수 있다) 를 복사해서 붙여넣으면 된다.

curl -L https://iterm2.com/misc/install_shell_integration_and_utilities.sh | bash

로컬에 있는 파일을 볼때는

imgcat 파일명

식으로 보면 되는데, 더 요긴한건 파이프가 지원이 된다. 단적인 예로,

curl https://stdio.sangwhan.com/content/images/2016/07/Screen-Shot-2016-07-21-at-7-49-58-PM.png | imgcat

를 하면 아래와 같이 나온다. (이미지는 때마침 링크가 있어 블로그 글 이미지를 그대로 사용하였다.)

이전에 사용하던것은 Skype. 전반적으로는 문제가 없었으나, 다소 신경쓰이는 문제들이 있었는데:

1. 모바일 클라이언트가 배터리를 너무 많이 먹는다.
2. 데스크탑에서는 P2P 네트워크의 bridge node로 기본으로 사용하기 때문에, 테더링할때 안끄면 후회할 일이 발생한다.
3. 상대가 오프라인일때 메시지를 보내고 내가 오프라인이 되면, 상대방이 이후 먼저 온라인이 되더라도 내가 온라인이 될때까지 메시지 전달이 되지 않는다. (단, 그룹 대화방의 경우는 그 메시지를 수신한 사람이 한명이라도 있고 온라인일 경우에는 전달이 된다.)
4. 파일 보낸건 그때 바로 안받으면 못받는다고 보면 된다.
5. 파일 전송 속도의 편차가 심하고, 공공 네트워크 같은 곳 (예를 들면, 스타벅스 Wifi) 에서 승인 handshake시 간혈적으로 말썽이 난다.
6. 대화록이 로컬에 저장되기 때문에 (보안 측면에서는 이 부분이 나쁘다고 할 수 없으나, 대화록 백업을 정상적인 방법으로는 못하고 export도 안된다) PC가 바뀔 경우 과거 대화 검색이 불가능하다.
7. 그 외 사소한것으로는 간혈적인 이중 푸시 노티 문제, 로그아웃 후 마지막 로그인했던 아이디의 푸시가 오는 문제. (...이건 사소하지는 않다. iOS에서 발생하는 문제이며, Android는 해당이 없는 듯 하다.)

이러한 문제 등으로 IRC (via IRCCloud), Campfire 등을 시도하였는데 여러가지로 반응이 좋지 않아 (사용률이 대단히 저조했다) 결국에는 서비스를 중단하고 (자체 IRC 서버를 운영했었다) 다시 Skype를 복귀를 했다가, 최근에 많이들 사용하는 Slack을 시도해보기로 하였다.

다른 후보들도 있었다.

• IRC / IRCCloud: 도입 실패 이력이 있어 스킵.
• Campfire: 도입 실패 이력이 있어 스킵.
• Hipchat: 지금 다니는 대학원에서 사용중. UXê°€ 일단 상당히 별로고, Atlassian ID 또는 Bitbucket IDê°€ 이미 있을 경우 골아픈 인증시스템 버그 때문에 고생한 적이 있어 일단 배제해버렸다. 장점은 (유료 플랜에 한하여) 영상 통화나 화면 공유가 되는데, 이게 얼마나 잘되는지는 시도해보지 ì•Šì•„ 모르겠다. (JIRA cloud 성능을 생각하면, 서버 중개식으로 Atlassian 서버를 경유한다면 서비스 품질에 대해서 조금 걱정이 되기는 한다.)
• 잔디: 파일 공유가 메인 기능이고, Integration이 구글 위주라 패스.
• Zulip: 무료로 사용이 가능하고, 이런 저런 측면에서 꽤 강력한 후보였으나 공교롭게도 도입 검토 시점에는 모바일 클라이언트가 제대로 빌드가 안되었다.

우선, 도입시도시에는 예외없이 전원 전향하고 Skype를 버리는 형태로 했는데, 전환은 꽤 매끄럽게 되었고, 사용률도 매우 높았다. (역시 UI가 이쁘고 봐야한다.) 지금 도입 만족도가 높고, 상당량의 커뮤니케이션이 그 안에서 발생한다. 대외 커뮤니케이션이나 기록이 확실히 남아야하는 경우에는 아직도 메일을 사용하고, 그 외 상당량 커뮤니케이션은 기록 없이 구두로 발생한다. 후자는 원격 근무자 밖에 없는 회사를 차리지 않는 이상은, 한국 사람 특성상 없어지기는 어려울 듯.

잘 나가는 애들 다들 쓴다니까 사람들이 반응이 좋았던것일지도 모른다는 생각이 조심스럽게 들기는 했다. 심지어 최근에 구글 안에서도 슬랙을 사용하는 팀이 있다 한다.

일단 슬랙의 가장 큰 장점은 Bot을 직접 짜거나 하지 않더라도 바로 사용할 수 있는 integration이 많다는 것이다. 현재 사용중인 App은 10개, 그 안에 integration은 정확히 모르겠으나, 꽤 많다. 자체적으로 Bot을 돌리고 있는것들도 있다. 최근에는 한잔씩 내릴 수 있는 기계를 사서 안쓰이지만, 이전에 아침에 커피 당번도 Slack Bot으로 정했었다. (사실은 불과 3주전까지의 이야기이다. 사실 커피는 핑계였고, 신입 직원에게 load balancer에서 사용할 queueing 알고리즘을 고민시키기 위함이었다.)

현재 업무 지원 용도로는 다음 기능들을 사용하고 있다.

• 서비스 장애/오류/관리자 손길이 필요한 상황 ë³´ê³ 
• 스토리지 장비 오류 ë³´ê³ 
• Teamcity Continuous Integration
• JIRA
• Trello (지금은 대부분 JIRAë¡œ 넘어갔다.)
• Google Calendarë¡œ 일정/휴가 관리 및 reminder

일단은 작은 회사인 만큼 한 사람이 한가지 일만 하지는 않는다. 슬랙 덕분에 내부에서 일어나는것 상당량을 모두가 관련 채널에 들어가 있으면 알 수 있다는건 공개성 측면에서 긍정적인 효과를 볼 수 있었다. 커지면 어떨지는 겪어봐야 알 듯.

simple-slack-api 라는것을 이용하여 기본적인 골격은 정말 금방 만들 수 있었다. 이전에 TCL로 Eggdrop 삽질 하던 시절 생각하면 세상 참 좋아진 것 같다. (예제는 Kotlin이나, 실제 운영중인 bot은 그냥 Java이다.)

package com.oddconcepts.coffeebot
import com.ullink.slack.simpleslackapi.impl.SlackSessionFactory

fun main(args: Array<String>) {
    val session = SlackSessionFactory.createWebSocketSlackSession(kKey);
    session.connect();
    session.addMessagePostedListener({ posted, session ->
        if (posted.sender.userName == kUserName)
            session.sendMessage(posted.channel, "Testing", null);
    });
}

지금까지 장점을 좀 정리하자면:

1. Integration이 기본 지원되는게 많아 그냥 폼 몇개 채우는거만으로 서비스 연계가 가능하다.
2. 시스템이 통보를 해줘야하는데 담당자 한명만 이 내용을 알고 있는 환경을 전원 공유 환경으로 오픈된 업무 문화를 만들 수 있다. (이건 조직 규모에 따라 적절하게 사용하기 나름이지만.)
3. Bot 개발이 편하다.
4. UI가 다른 엔터프라이즈 메시징 서비스에 비해서는 다가가기 쉽다.
5. 중개 서버가 있어 대화창에서 파일 공유가 매우 안정적으로 된다.

정도가 될 것 같다.

장점을 이야기했으니, 이제는 단점. 모든게 완벽할 수는 없으니 이 부분에 대해서는 확실히 짚고 넘어갈 필요가 있다.

우선, 가장 큰 문제. 데스크탑 클라이언트의 전반적인 퍼포먼스 문제왜 배터리 소모량 문제는 근시일 내에 해결되지 않으면 서비스의 실패 요인이 될 수 있을 정도로 심각하다. 만약에 전부 네이티브로 해결을 보고 기능상 동일한 수준을 제공하는 서비스가 나온다면 시장을 꽤 뺏어갈 수 있지 않을까 싶을 정도. 카페 근무시에는 아예 클라이언트를 꺼두고 모바일 푸시만 보면서 일할 정도로 배터리 수명에 지장을 준다.

브라우저 기반이라서는 사실 Slack의 사정이고, 이 부분은 절실하게 개선이 필요하다.

(위에서 Safari가 가장 많이 차지하고 있는 이유는 이 글을 사파리에서 작성하고 있기 때문이다. 슬랙은 사용하지도 않았다.)

그리고 구글을 제외한 대부분 외국 서비스에 공통되는 문제이나, 한글 검색이 상당히 문제가 있고 아울러 영어 검색도 딱히 좋지는 않다. 과거 대화록 검색에서 결국 원하던것을 찾지 못하여 스크롤로 찾은 적이 제법 있었으니, 검색은 사실상 포기하는게 나을수도 있다. (이건 Confluence나 JIRA 같은 경우에도 해당되는 문제이다)

Snippet (Command+엔터로 긴 글 붙여넣기) 처리가 상당히 느리다. 만약에 빌드 로그 같은걸 붙여넣을 경우 그걸 불러올때 클라이언트가 멈추는 수준으로 느려졌다가 간신히 표시된다는 느낌을 받았는데, 매번 다운로드를 받아서 봐야하는 불편함이 있다.

IFTTT인테그레이션에 의존한다면 그냥 잊고 사는게 편하다. 처음에 두번 정도 동작하고 그 뒤로는 동작하는 것을 본 적이 없다. 이게 업무상 중요한 기능이 아닌지라 (텀블러 연동) IFTTT의 문제인지 Slack의 문제인지는 확인해보지 않았으나, 엔드유저 입장에서 봤을때는 그 문제가 어디 있는지는 사실 관심이 없다. 된다 안된다에만 관심이 있는데, 경험상으로는 안된다.

비싸다. 우리 같은 경우 사람 수가 적어 크게 부담되는 금액은 아니지만, 메신저 주제에 Google Apps for Work보다 높은 금액을 지불해야하는건 사실 가격대 성능비가 좋다고 할 수는 없다. 100명 있는 조직이라고 하면, 1년에 메신저 사용료가 1000만원이라는 이야기다. 아주 큰 돈은 아니지만, 다른 무료 대안이 있는걸 감안했을때는 분명히 부담되는 비용.

단축키가 희한하고 (OS 표준하고는 좀 안맞는다) 커스터마이징이 안된다. 나의 경우, Command + Alt + 방향키와 Command + Shift + []를 사용하는 툴 대부분에서 굉장히 많이 사용한다. 문제는, 이게 동작하는 방식이 슬랙에서는 굉장히 이상한데 (특히 Command + Alt + 방향키) 원하는 기능의 단축키는 Alt + 위/아래 이다.

다조직을 사용하는 경우, 인증 시스템이 상당히 야리꾸리하다. 어차피 같은 백엔드일텐데, 같은 메일 주소, 허나 다른 비밀번호로 다른 조직 2개에 가입이 가능하다. 유저 매핑상 조직 가입 여부만 기록해두면 될 것 같은데 굳이 이런 형태로 구현한 이유에 대해서는 조금 이해가 안되는 점은 있다.

그리고 마지막으로, 개인적인 취향의 문제이지만 테마 기능이 상당히 미흡하다. 사이드바 색깔은 변경할 수 있으나, 눈이 아파서 어두운 배경을 선호하는 사람한테는 쥐약이다. 이걸 해결하는 방법은 Greasemonkey 스크립트 같은걸 이용하는 것인데, 이것 마저도 커스텀 MacGap 기반인 맥 버전에서는 사용할 수 없다. 사실 사이드바만 색상 변경 가능한건 무슨 의미인가 싶기도 하다.

사용할지 말지는 어디까지나 팀의 성향과 커뮤니케이션 스타일, 그리고 특히 타 서비스와 연동의 필요성에 따라 달려있는것 같다. 완벽하지는 않지만, 성향이 맞다면 써볼 만한 툴.

쓸데없는 사실: Slack 백엔드 스택의 상당량은 PHP(?!)임. 쓸데없는 사실2: 구글 인증 Slack 조직에 가입했다가 해당 구글 계정에 대한 권한을 상실하면 클라이언트에서 로그아웃이 영원히 불가능한 버그가 있다.

별점은 소리 외 실용성까지 포함되었으므로 소리에 대해서만 보고 싶으면 측정 결과를 보는 것을 추천한다.

Audio Technica ATH-M50(X)

이미지 출처: http://www.audio-technica.com/cms/headphones/99aff89488ddd6b1/

• 별점: ★★★★☆
• 가격: 25만원 전후.
• 휴대 가능: 임페던스가 낮고, 접이식이라 기술적으로는 가능하다.

Over-the-ear 헤드폰. (크다라고 해석하면 된다.) 오디오 테크니카 제품은 저가형과 적당히 가격이 나가는 제품하고 차이가 많이 난다. M50 정도까지 올라가는 시점부터 괜찮은 소리를 경험할 수 있다. M50은 사실 단종되었고, 이전에 케이블 교환이 불가능했던 M50 제품에 케이블 탈착이 가능하게 하면서 가격을 좀 (많이) 올린 M50X라는 모델이 현재 유통중이다. 소리 자체는 기존 M50하고 같으니 거치형으로 사용할 예정이고, 선을 잘 관리할 수 있으면 M50 중고를 사도 된다. 이동하면서 사용할 예정일 경우, M50은 풀린 선은 인질 납치하고 묶을 정도의 선 길이를 자랑하고, 꼬인선은 선 무게가 느껴지는 단점이 있으니, 자금의 여유가 된다면 M50X를 사는게 좋다. 필요한 선 길이로 하나 사서 바꿔끼면 되니. 개인적으로는 이상하게도 꼬인선이 2000엔 쌌기 때문에 M50 꼬인선을 사용한다.

소리는 저음이 살짝 강한 강한 감이 있지만, 단순 모니터가 아닌 청음 겸용으로 사용한다면 크게 문제가 안되고 그래도 비교적 균형감이 있는 소리가 나오는 제품. 기본으로 달려있는 이어패드는 여름에 땀이 굉장히 많이 찬다는 단점과 (순정품으로 나오는 Velour 소재의 별매 이어패드가 있는데, 이것도 마찬가지로 땀이 찬다. 게다가 땀을 흡수까지 하기 때문에 나중에 냄새가 날 우려도 있다.) 헤드밴드가 다소 무겁고 둔하기 때문에 착용시에 무게감이 좀 있다는게 사용자에 따라 장점도 단점도 될 수 있다. 크기하고 헤드밴드 디자인 때문에 덕분에 별점 하나 뺐다.

미국이나 일본에서 살 수 있으면 싸게 살 수 있으니 만약에 그렇게 살 수 있는 경로가 있다면 가성비 면에서 이 제품 만한 제품 찾기가 쉽지는 않을 것이다. 아울러 오디오 테크니카는 어느 정도 수준이 되는 제품부터는 외주 생산이 아니라 자체 운영하는 대만 공장이나 일본 공장에서 생산하므로, 여기서 생산하는 제품의 품질은 믿을만 하다.

장시간 착용해도 피로하지 않고, 밸런스가 좋은 소리를 내주는 만큼 듣는데 지치거나 하지 않는다. 가격도 그럭저럭 무난한 편이고, 꽤 튼튼하기 때문에 업무용 헤드폰으로 추천. 접이식이긴 하지만, 접어도 사이즈가 상당히 크기 때문에 이동용으로는 조금 애매한 감이 있다. (이 정도 소리를 내주는 헤드폰 중에 이 정도로 38옴 수준으로 임피던스가 낮은게 없어서 조금만 더 작았으면 매우 훌륭한 이동용이 되었을텐데 하는 아쉬움이 있다.) 마지막으로 측정 결과는 여기에.

Bang and Olufsen 3I

이미지 출처: http://www.beoplay.com/products/beoplayearset3

• 별점: ★★★★★
• 가격: 30만원 전후.
• 휴대 가능: 가능.

위험한 가격대의 디자이너 오디오 제품을 많이 만드는 덴마크 회사의 귀에 거는 이어폰. 이 회사 거치형 오디오 제품은 허락 없이 세트 구성했다가 일방적인 이혼 통보 등을 경험할 수 있으나, 다행히도 휴대용은 그 정도의 가격은 아니다. 아쉬운 점이라면 현재는 모든 이어폰/헤드폰 제품을 그곳에서 만든다는 것. 아울러 한국내 취급점이 적어보인다. 그렇다고 해도 이어폰 치고는 비싸다.

A8에 아이폰용 마이크/리모콘을 단 제품이다. 잘 알고 있을 A8 제품하고 같은 소리가 난다고 나는 확신하나, 몇몇 세력들이 아니라는 평이 있다. 왼쪽 귀에 A8, 오른쪽 귀에 3I를 끼고 같은 소스로 들어본 결과 같은 드라이버라고 적어도 나는 결론을 내렸다. 판단은 알아서. 어차피 A8은 지금 신품 구하기 어려우니 특별히 4극 플러그를 사용할때 말썽을 부리는 기기를 쓰지 않는 이상 이걸 사는게 맞다.

당연한 이야기이지만, 커널형보다는 소리가 시원하다. 솜을 사용하지 않으면 착용감도 애매하고, 그에 따라서 소리 균형이 좀 안좋다. 솜을 사용하면 확실히 저음쪽에 좀 편향된다는 느낌이 있으나, 그래도 다른 이어폰에 솜을 사용하는 것 보다는 훨씬 균형감이 있다. 착용감도 굉장히 좋은데, 안경을 끼는 사람은 귀에 거는게 두개가 되어서 애매할 수 있다. (직접 해본 결과, 애매하다. 안경 끼는 사람이면 별점 하나 빼는게 맞다.) 사소한 장점이지만, 예쁘다.

하우징 모양 특성상 솜을 잘못 끼면 나도 모르는 사이에 빠지기가 쉽다. (케이스에 넣었다가 빼거나 할때 빠지고 그런 일이 많다.) 싸구려 솜을 아예 여러 세트 사서 들고 다니는걸 추천. 케이스가 예쁘나 사용이 불편해서 (써보면 알 수 있다...) Brainwavz제 하드케이스에 넣어 갖고 다닌다. 공교롭게도 3I는 측정이 없으나, 같은 드라이버인 A8의 측정 결과는 여기에 있다.

Beyerdynamic DT1350

이미지 출처: http://tascam.jp/product/dt_1350/

• 별점: ★★★★☆
• 가격: 40만원 전후.
• 휴대 가능: 임페던스가 80Ω으로 높은 편이나 의외로 앰프 없어도 무난히 구동 가능. 있는 편이 좋으니 실제로 휴대할지는 본인 판단. 일단은 가능.

이 글에 있는 유일한 On-ear 헤드폰. (작다라고 해석하면 된다. 유사한 형태로는 젠하이저 PX100/PX200, Koss의 포타프로 같은 제품의 형태를 생각하면 된다.) 1937년에 최초의 다이나믹 헤드폰 DT48 (여담이지만 이 제품은 2012년까지 무려 75년 동안 생산했다) 처음으로 만든 역사와 전통이 있는 바이어다이나믹에서 새로 내놓은 Tesla 라인 중에서 저가 제품 중 하나이다. (최상위 제품인 T1은 100만원 넘어간다.)

저음에 치우친 성향이 있는 T50p/T51p와 달리, 레퍼런스 성향이 강한, 어찌보면 심심한 소리라고 생각될 수 있는 제품이다. M50X은 재미가 좀 있는 대신 저음 편향이 좀 심한데, DT1350은 전혀 편향되지 않은 소리를 즐길 수 있다. 장시간 착용해도 불편하지 않고, 아무래도 얼굴을 덮는 면적이 적은 만큼 땀도 상대적으로 덜 찬다. 헨드밴드도 가볍고, 접이가 되지는 않으나 기본 사이즈가 작기 때문에 휴대하기에 다른 헤드폰보다 수월하다. (물론, 포타프로처럼 손바닥에 들어갈 사이즈로 접히지는 않는다.) 개인적으로는 갈라지는 헤드밴드 디자인이 좋은데, 이건 호불호가 갈리는것 같다. 크기가 작기 때문에 이동용으로 사용하기 좋고, 예쁘지 않은 디자인이 대부분인 바이어다이나믹 라인업치고는 디자인이 예쁘다. (헤드폰 애호가들은 못느끼는것 중 하나가, 풀사이즈 over-the-ear를 차고 거리를 돌아다니는게 어울리는 사람은 거의 없다는거다. 게다가 DT990 같은 디자인은 아무리 예쁘고 잘생긴 연애인이라도 단박에 덕밍아웃 된다.)

소스랑 연결하는 선이 어째서인지 왼쪽에 달린건 한가지 단점. 상당수 사람들이 오른손 잡이이고, 오른쪽 주머니에 소스를 넣고 다니는걸 감안하면 좀 이해가 안되나, 대칭형이니 그냥 거꾸로 하면 된다. (inverse stereo로 듣는다고 이상해지는 음악은 거의 없다.) 교체도 안되는데 선이 매우 길기 때문에 선을 묶고 다녀야하는 점과, 임피던스가 80옴으로 비교적 높다는게 휴대하는데 다른 이유로는 완벽할 수도 있었던 제품을 깎아내리는 점이 약간 아쉬워서 별점 하나 빠졌다.

Etymotic Research ER4-PT

이미지 출처: http://www.etymotic.com/consumer/earphones/er4.html

• 별점: ★★★★★
• 가격: 40만원 전후.
• 휴대 가능: 가능.

커스텀의 영역으로 들어가지 않는 IEM중에서는 개인적으로 본좌급 제품. 싱글 BA라는걸 갖고 많이 까이지만, 개인적으로는 싱글로도 이 정도 소리를 내면 굳이 멀티 BA로 갈 필요가 있나 라는 생각이 든다. 여기서 소개한 제품 중에서 가장 철저한 QC 과정을 거치는 제품으로, 구매시 박스 안에 채널 균형하고 FR 측정한 결과를 같이 넣어주고, 해당 서류에 검수를 한 사람의 인증 서명이 들어가 있다. 혹시라도 채널 균형이 안맞거나 하면 에티모틱사에 보내면 수리/보정 후 다시 받을 수 있다.

ER4-PT와 ER4P는 기본적으로 이어폰 자체는 같은 제품이다. 차이는 위에 검수를 한 인증서와 ER4S 변환 케이블, 별로 쓸 일 없는 비행기용 어댑터가 들어있다는 차이 정도이다. 그 중에서 ER4S 케이블 정도는 원래 가격이 좀 있는 물건이라 (내용물 자체는, 사실 그냥 저항 2개다.) 꽤 큰 플러스이다. 아울러 FR 특성 자체도 ER4S가 더 좋기 때문에, 앰프 사용시에는 반갑게 사용할 수 있다. (다른 용도가 딱히 없어서, 나 같은 경우는 변환 케이블을 그냥 앰프에 꼽아두었다.) 거치용 ER4S와 휴대용 ER4P를 한번에 사는 격이니 이건 확실히 이득이다. ER4B도 직접 회로를 짜면 시뮬레이션은 가능하나, Binaural 오디오 이외에는 용도가 다소 애매하니 굳이 신경을 안써도 되겠다.

추가적으로, Etymotic의 고객 지원은 매우 좋기 때문에 기본적으로 먹고 들어가는 점수가 있다. (음향쪽에서는 최강의 고객 지원을 자랑하는 Koss 다음 정도라고 개인적으로 생각한다. 다만, Koss는 보증 기한이 무제한이라는 무시 못할 강점이 있다.) 고객 지원을 외주 센터에 주지 않고 전량 본사에서 직접 운영하기 때문에 문제점이 있어서 질의를 하면 뇌가 달린 사람이 대답을 해준다는 장점이 있다. 아울러 보증 기간 내에 있는 제품이 문제가 생겼을 경우에는 자세한 내용 묻지 않고 전체 무상 교환이 들어간다. (경험상 살짝 넘어간 것도 받았다. 너무 남용하지는 말자.)

단점. 3-flange 이어팁에 대해서 호불호가 굉장히 갈린다. 혹자들은 산낙지를 고막에 붙여놓은 듯한 고통을 호소하고, 혹자들은 훌륭한 차음성을 찬양한다. 교체를 자주 해줘야하는게 조금 문제이지만, 전자에 해당하는 사람이라면 연탄 이어팁을 사용하면 된다. (번들된 다른 폼팁은 소리 특성이 많이 바뀌기 때문에 추천하지 않는다.) 마지막으로, 레퍼런스 성향이 강한 제품인 만큼 소리가 균형 있지만 매우 심심하고, 특히 베이스가 중후한 소리를 좋아하는 사람한테는 좀 아쉬울 수 있다. 싱글 BA라고 많이 까이는데, 이 부분에 대해서는 본인이 판달 할 몫. 마지막으로 사소한 불평이지만 이어폰 주제에 선이 좀 길다.

Phonak PFE232

이미지 출처: http://www.amazon.com/Audeo-PFE-232-Perfect-Earphones/dp/B006GAERYS

• 별점: ★★★★☆
• 가격: 단종 제품. 50만원 전후. (정가는 70만원대. 포낙이 접으면서 가격 내려감.)
• 휴대 가능: 가능. 단, 이어폰 치고는 임페던스가 높다.

본업은 보청기회사에서 잠시 미쳐서 내고 접었던 Audeo라는 이어폰 브랜드의 최상위 제품군. 단종이 되기 전에 사운드캣에서 69.9만원이라는 살인적인 가격에 판매를 한 제품인 만큼 잘 팔리지는 않은 것으로 알고 있다. 이런 가격을 자랑하지만, 듀얼 BA라는 어찌보면 조금은 아쉬운 스펙을 갖고 있는데, Sonion제 BA를 사용하는 다른 PFE제품군과는 달리 Knowles제로 저음 대역을 위해서 EF-31264-000를, 고음 대역은 ED-23619를 크로스오버해서 사용하고 있다. 할인 가격을 감안해도 비싸기 때문에 별점 하나 빠진다.

PFE0xx나 PFE1xx의 상위 기종인 만큼 소리의 특색이 비슷할꺼라 기대하면 오산이다. 개인적인 소견으로는 굉장히 다른 성향의 소리를 내주는 제품으로, BA 제조사나 구성을 감안하면 충분히 있을 수 있는 일이다. 소리는 굳이 이야기하자면 균형이 있는 레퍼런스계 보다는 다이나믹한 느낌으로, 저음과 고음이 강하다. 특히나 고음의 시원함은 BA를 사용하는 이어폰 치고는 좀 드문 수준이라 좋다고 생각하나, 저음 때문에 중음이 좀 묻힌다는 인상은 있다.

원래 하라는대로 사이드를 사용하고 over-ear 형태로 착용할 경우 착용감이 좋다. (개인적으로는 PFE132에 포함된 투명 이어가이드가 PFE232에 포함된 검정색 보다 편하다고 생각하지만, 이건 개인적인 취향 문제인 듯.) 다만, over-ear가 다 그렇지만 안경과 동시에 사용하면 조금 불편하다. 이때에는 아쉬운대로 좌우를 바꿔서 그냥 in-ear로 착용할 수 있다. (꽤나 당연하게 느껴진 방법인데, 골든이어스나 헤드파이 같은 커뮤니티에 이 방법을 쓰는 사람이 없다는게 좀 신기하다고 생각했다.)

구성품이 좋은 편이나, PFE 1xx 제품군 대부분도 이 정도 되기 때문에 역시나 가격을 정당화 할 수 있는 수준은 아니다. 최상위 기종인 만큼 포낙의 필터 3인방 모두가 2쌍씩 포함되어있고, 공교롭게도 2015년 10월 현재 품귀 현상인 회색 필터 신품을 입수할 수 있는 유일한 방법이기도 하다. (다만, 그걸 위해서 감수해야하는 희생은... 크다. 현재 지구상에 남아있는 판매처는 Earphone Solutions 한 곳. 그나마도 재고가 없어질때까지만 판다고 한다.) 가장 큰 차이는 케이블이 교체가 가능하고 끊어지거나 하면 교체품을 구입할 수 있다는건데, 이것 역시 재고 소진이 되면 문제가 될 여지가 있다. 전 Audeo 제품군과 같은 문제이지만, 케이스는 확실히 애매하다. 사이즈가 작은 만큼 유닛끼리 안에서 부딧치면서 상처가 나는 문제는 둘째치고, Audeo 제품군이 전체적으로 선이 형상 기억이 잘 되는 만큼 제공된 케이스를 사용하면 꺼내서 사용할때 선이 꼬여서 반항을 하는 일이 자주 생긴다. 정신 건상을 위해서 다이소 같은데서 주머니 같은걸 사서 휴대하거나, Shure EASCASE나 EAHCASE 케이스를 사용할 것을 강력하게 권장한다. 다소 혹평을 받은 측정 결과는 여기에.

Sennheiser HD650

이미지 출처: http://en-us.sennheiser.com/high-quality-headphones-around-ear-audio-surround-hd-650

• 별점: ★★★★★
• 가격: 50만원 전후. (한국에서는 좀 더 싸게 ì‚´ 수도 있는것 같다.)
• 휴대 가능: 불가능.

집에서 사용할 거치용 헤드폰을 하나만 사서 동해물과 백두산이 마르고 닳도록 쓰고 싶다면 다른 리뷰 보지 말고 그냥 이걸 사면 된다. 역사와 전통이 있는 회사에서 만든 레퍼런스급인 만큼 소리는 흠잡을 곳이 없다. 착용감도 매우 좋고, 오픈형이다 보니 밀폐형 처럼 더운 문제는 확실히 없다. 완성도가 매우 높은 기종이고, 두고두고 쓸 수 있는 튼튼한 소재인 만큼 이어패드하고 (Part Number: H-50635) 헤드밴드 패드만 (Part Number: 088597) 닳았을때 교체해주면 된다. 이어패드는 잘하면 ATH 패드 중 몇 기종하고 호환이 될 수도 있는 사이즈이니 귀찮으면 그걸로, 헤드밴드 패드는 정 귀찮으면 문풍지로(...) 저렴하게 교체가 가능하다. (어차피 집에 놓고 쓸거니 모양이 신경 쓰이지 않는다면 말이다.) 생산은 아일랜드에서 한다.

소리는 성향은 레퍼런스계이긴 하지만, 따뜻하면서도 시원한 느낌의 (후자는 오픈형의 특성이다.) 소리를 경험할 수 있다. 오픈형의 특성을 잘 살렸고, 최상급 드라이버가 들어가 있는 제품이니 실망할 일은 절대 없을것이다. 아울러 꽤 가볍다. 300옴이라는 꽤나 높은 임피던스를 자랑하므로, 앰프 사용을 강력하게 권장한다. 테스트 결과 페어링이 가장 좋았던 기기는 Benchmark Media DAC2 HGC였으나, 정신이 똑바로 박힌 사람이라면 적당히 저렴한 헤드폰 앰프랑 붙여서 사용하면 된다. 굳이 그것도 귀찮다면, 그냥 갖고 있는 소스에 꼽아도 되는데 본연의 성능은 못낼 가능성이 있다는 점에 주의. 벤치마크사에서 헤드폰 앰프 회로 테스트를 할때 사용하는 레퍼런스가 HD650인 나큼 앞서 언급한 DAC2 HGC와의 페어링은 매우 훌륭하나, 이상하게도 사고나면 그 달 월급을 안받은 것 같은 기분을 느낄 수 있다.

동봉된 케이블이 존나게 길다. 3미터니까 어지간한 방에서는 책상위에 있는 앰프에 헤드폰을 꼽아두고 베란다에 담배를 피러 갈 수 있는 거리다. 문제는 이걸 책상에서 사용하게 될 경우 선이 걸리적 거리고, 의자에 걸리는 등 피곤한 일이 생긴다. 고로 50만원이라는 거금을 들여서 사고, 돈을 더 들여서 교체용 선을 사거나, 흉하게 빵봉지 묶는 철사로 대충 묶어서라도 케이블 끌림을 방지해주는게 좋다. (선은 교체가 가능한 디자인으로, 뽑으면 빠진다.) 개인적으로는 Oyaide제 HPC-35HDX라는 케이블을 사용하고 있다. HPC-22W 이라는 PCOCC-A라는 순도가 높고 잡음 등을 확실하게 잡아주는 최고급 소재의 0.08mm 굵기의 선을 20가닥씩 3개조를 꼬아서 대칭형으로 만들어 내부 선과 공간의 균형, 그리고 선의 변형 및 손상을 방지하는 새로운 디자인에 남은 공간을 섬유로 채워 전도성을 극대화 하면서 내구성을 올린 고급 케이블이다. 물론, 이건 제조사에서 하는 마케팅용 개소리이고, 결국은 그냥 선이다. 아마존 프라임 주문이 가능한 가장 싼 3.5파이 커넥터가 기본인 짧은 선이라는 이유에서 샀을 뿐, 음질이 더 좋아지거나 하지는 않는다. 싸다고 해도, 6만원 정도 하니, 시간의 여유가 있다면 알리나 이베이에서 좀 더 저렴한 선을 사는걸 추천한다. 묻지마 브랜드 대륙제는 커넥터 체결시 땜질 퀄리티 등에 대해서는 우려되는 바가 있으니, 싸다고 무턱대고 사는 것 보다는 인지도가 어느 정도 있는 벤더를 골라서 그 중에서 싼거 사면 된다. 블라인드 테스트로 돌고래 아니면 어차피 구분 못한다.

오픈형인 만큼 사무실에서 사용하면 모두가 헤드폰을 사용하는 건전한 업무 환경이 아닐 경우 동료들에게 뒤통수를 쳐맞을 각오를 해야한다. 소리가 새는건 막을 수 없고, 막아서도 안되는 디자인이다. 고로 밖에서도 사용 못한다. (아울러 밖의 소리가 들린다.) 내가 회사 사장이 아니면 이건 가정이나 스튜디오에서 사용하는 수 밖에 없다. 다만, 그런게 문제가 없는 상황이라면 정답은 이것이라고 할만한 헤드폰. 측정 결과는 여기에.

Sony MDR-E888

이미지 출처: http://www.amazon.co.jp/ソニー-MDR-E888LP-SONY-ステレオ・イヤーレシーバー/dp/B00008S22K

• 별점: ★★★☆☆
• 가격: 중고는 3만원부터 50만원까지 다양하고, 신품은 부르는게 가격.
• 휴대 가능: 잃어버려도 울지 않을 자신이 있다면 가능.

2015년 현재로 따지면 빈티지나 레트로로 분류될 수 있는 제품이다. 고가형 이어폰 시장을 개척했다고도 할 수 있는 제품으로, 발매 당시 8000엔이 넘어가는 이어폰 치고는 꽤나 파격적인 가격을 자랑했다. (지금은 8000엔이면 "쓸만한 수준이겠군"이라고 생각하는게 일반적이니, 오래 살고 볼 일이다.) 데이터시트 상으로는 최고 27Khz까지 표현이 가능하다고 하나, 주변에 실험해 볼 돌고래가 없어서 실제로 그 정도까지 올라가는지는 모르겠다. CDP와 MDP가 주류를 이루고, 주변에 한 두명 정도가 MP3 플레이어를 갖고 있었고, 지인과 사돈의 팔촌까지 다 동원하면 Sony Music Clip (소니에서 처음 내놓은 플래시 메모리 미디어 플레이어로, 내장 메모리가 NAND인 MD라고 생각하면 된다. 실제로 음성 코덱도 ATRAC3를 사용했다.) 갖고 있는 사람이 한대 나올까말까 하던 시절의 명기.

분명히 소리는 좋다. 15년이 넘은 제품이라고 믿을 수 없을 정도로 해상력이 좋고 (당대 일반적인 이어폰 중에 집에 아직 굴러다니는거 꺼내서 한번 들어보면 확실히 다르다.), 이어폰으로 흔하지 않은 오픈형이라 명쾌하면서 시원한 소리를 내준다. 개인적으로는 솜을 사용하지 않았을 경우 소리를 더 선호하는데, 세월이 세월인 만큼 최대한 교체품이 없는 고무링에 직접 접촉을 피하기 위해서 아쉽지만 솜을 사용하고 있다. 솜을 사용하면 해상력이 다소 떨어지고 저음에 치우치는 경향이 있다. 장시간 착용시에도 피로하지 않으나, 고무 목에 부하를 줄 수 있는 문제가 있다. (이것도 오래되었기 때문에 문제가 되는데, 고무를 상당히 많이 사용한 제품인 만큼 오래되면 고무가 하얗게 되는 문제가 있다.)

신품 구하기가 어렵다. 지금도 전설의 이어폰을 찾아서 온라인을 열심히 뒤지는 용자들이 있는데, 일본 생산 물량 미개봉을 구한다고 하면, 아마도 꽤나 금액이 나갈 것이다. 타오바오에서는 100만원까지 나가는걸 보았다. 이 이어폰이 그만한 가치가 있는가라고 물으면, 솔직히 소리로는 아니올시다라고 생각한다. 분명히 좋은 소리를 내주는 이어폰이긴 하나, 15년이 넘은 제품인 만큼 그 사이에 기술은 많이 발전했다. 물론 고급 이어폰 시장을 개척했다는 역사적 가치나 추억으로서의 의미는 꽤 강하다. 특히 BA 기술의 진보는 실로 경이로운 수준이니 지금와서 저런 돈을 들여서 이 제품을 구매하는건 크게 의미가 없다고 생각한다. 굳이 성향이 비슷한걸 원한다면, B&O 3I나 Yuin사의 PK시리즈가 있으니 그런 제품을 이용하면 되겠다. 측정 결과는 여기에.

아버지 차 앞 범퍼를 누가 긁고 가서 영상을 보겠다고 난리를 치셔서 귀찮음을 감수하고 세팅해드린다고 나른한 오후를 태워버렸다. (보는 방법도 모르는데 블랙박스 달고 다니면 무슨 의미가 있는지는 모르겠지만, 어쨋거나) 딱히 할일도 없어, 복날 똥개 훈련급 회원가입 및 정품 인증 절차를 마친김에 펌웨어를 다운받아 분해.

(잡설: 아이나비때도 느꼈지만, 내비게이션 회사들 홈페이지는 욕이 나올 정도로 못 만들었고 "정품 등록"에 대한 편집증은 사람을 매우 피곤하게 한다. 이것 때문에 지하 주차장에 다녀오는 수고를 해야했다.)

Automotive라 Freescale이거나 카메라니까 Ambarella나 둘 중 하나 쓰겠지라고 생각했는데, 의외의 물건이 안에 들어있었다. Core Logic이라는 들어보지도 못한 회사의 IP를 사용하고 있었는데, 좀 더 조사해보니 아이나비도 이걸 사용한다. 이에 대해서 추가적인 내용은 아래에. (기억을 더듬어보니, 이전에 삼성동에 출퇴근하던 시절에 지나가면서 괴상하게 입지가 좋은 곳에 [도심공항타워 맞은편] 이름도 들어보지 못한 회사가 있어 "뭘까" 했던 기억이 떠올랐다. 지금은 경기도로 이사간 듯.)

사용하고 있는 제품은 다본다 히든 II 라는 90년대스러운 작명 센스의 제품이나, 실제로 펌웨어를 뜯어본 제품은 II가 아닌 그냥 다본다 히든 라는 제품의 펌웨어이다. 별로 차이는 없지 않을까 싶다. 내용을 뜯어본 결과, 여러가지 공개 라이브러리를 사용하는것으로 보였으나, 확실히 리눅스는 아니었다.

해당 제품에 탑재되어 있는 추정 하드웨어는 아래와 같다. (이건 어디까지나 소프트웨어 분석에 의한 정보이며, 직접 뜯어보지 않았기 때문에 정확하지는 않다.)

SoC: http://www.corelogic.co.kr/eng/application/product.php?idx=84
Camera: https://www.aptina.com/products/soc/mt9m114/

흥미로운 것은 Core Logic에서 RTOS를 공급한다는것이고, 슬쩍 들여다 본 결과 실제로 운영체제는 국내 임베디드 업계의 약방 감초와 같은 마당쇠의 NEOS의 변종으로 보인다. 적어도 분석한 제품은 그것을 사용한다는것인데, 운영체제를 만들겠다고 空約을 날리고 애매하게 산으로 가버린 T모사보다는 건전하다고 할 수 있다.

게다가 OS에서 NxFS라는 자체 파일 시스템을 사용하는데, 사용하는 이유는 정확히 모르겠다. (가장 유력한 이유는 MTD 최적화된 공개 파일 시스템을 사용하면 GPL 위반 영역으로 들어가고, 타 커널에서 뜯어내면서 의존성을 풀어주기 위한 수고를 피하기 위함의 복합적인 요인이 아닐까 추측된다.) Core Logic사에서 공개 정보가 많지 않아서 일단은 조사가 조금 어려운 상황. 공개 소스를 발견해서 그걸 참고하여 취지를 알아내려 하였으나, 소스의 양이 너무나 방대하여 일단은 나중으로 보류.

이 자체 파일 시스템은 취지상으로는 어떤지 모르겠으나, 부작용으로 윈도우 사용자가 아니면 블랙박스 내용을 열어볼 수 없다는 치명적인 문제가 있다. 게다가 FUSE 플러그인이라든지 공개되어 있는 것이 없다는게 더 큰 문제. 이 부분에 대해서는 나중에 시간이 더 나면 일단 한번 다시 들여다 볼 생각이다. (16기가짜리 SD카드 덤프를 헥스 에디터로 들여다보는건 시간도 걸리는지라, 할 일이 매우 없는 날을 위해 아껴두는거다.)

추가적으로 재미있는 사실은 MT9M114는 웹캠용으로 많이 사용되는 것 같다는 것 정도.

펌웨어 내용물:

• CLBOOT.SYS
• lucy_fw_2nd_boot.bin
• lucy_fw_eboot.bin
• lucy_fw_etc.bin
• lucy_fw_main.bin
• lucy_fw_minfo.bin

펌웨어 중에서 CLBOOT.SYS와 lucy_fw_main.bin이 실제 실행되는 코드의 대부분을 차지하고 있고 (CLBOOT.SYS는 느낌상 OS와 시스템 라이브러리 등으로 보이고, lucyfwmain.bin은 리눅스로 따지면 userland로 보인다. 실제로 RTOS에는 userland의 구분이 명확히 없고 watchdog이 유일한 법인 춘추전국시대이지만, 어쨋거나.) lucy_fw_etc.bin은 리소스가 들어가 있는 "파티션" 같은 느낌으로 보인다. OS 상에서 R드라이브로 매핑이 되는것으로 보인다. eboot, 2nd_boot는 아마도 부트로더나 그런 류가 아닐까 싶다. 자세히 보지는 않았으나 경험상 eboot가 모포 깔고 2nd_boot가 고스톱 치는 그런 느낌이 아닐까 싶다. minfo는 정체불명.

조금 찾아보니, 다본다 히든과 하드웨어/소프트웨어상 유사품이 하나 있는데, 전혀 관련이 없는 제조사의 아이나비 BLACK CLAIR2라는 제품이다. 같은 플랫폼 기반이고, 슬쩍 본 결과 상당히 많은 부분이 겹친다. 아마도 Core Logic에서 준턴키 솔루션으로 공급을 하고, 개별 제조사에서 BSP를 받아서 상품화와 마케팅을 하는 형태인듯 하다. Mediatek이나 Ambarella의 모델과 유사하나 국내 위주로만 하는 것 같다. 찾아보니 국내 업체에서 같은 하드웨어로 GoPro 유사품을 만든 사례도 있었다. (해외에서 Core Logic 플랫폼을 사용하는 사례를 찾을 수가 없었다.)

TL:DR; 요약: 블랙박스라고 파는 제품은 사실상 코어 소프트웨어는 같으며, RTOS가 돌고 있는 ARM9 코어에 하드웨어 인코더가 박힌 비상식적인 권장소비자가를 요구하는 USB 웹캠이다.

(다본다 히든 II 공식 판매가가 33만9천원이다. MT9M114는 단가가 6불 정도이다. RK3168 같이 1080p 인코딩이 가능한 Cortex-A9 듀얼칩이 낱개 가격으로 쳐도 화창베이에서 10불이 안된다는걸 감안한다면, 아무리 Core Logic IP가 비싸다고 해도 제조사에서 단가 만원 이상 지불할 가능성은 적다고 생각되다. Fabbing등이랑 R&D를 감안해도 꽤나 마진율이 높은 물건이다.)

(일본에서 아직도 Super-H와 ALP의 화려한 잘라파고스 조합을 사용하는 것을 욕하고 다녔는데, 한국 블랙박스 시장도 비슷한 양상을 보이고 있다는 사실에 살짝 충격.)