수요일, 1월 06, 2010

Debugging Linux kernels with Workstation 6.0

Debugging Linux kernels with Workstation 6.0
Source: http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html


Debugging Linux kernels with Workstation 6.0

We just quietly added an exciting feature to Workstation 6.0. I believe it will make WS6 a great tool for Linux kernel development. You can now use gdb on your host to debug the Linux kernel running inside the VM. No kdb, no recompiling and no need for second machine. All you need is a single line in VM's configuration file.

To use the new feature, grab the latest build of Workstation here(http://www.vmware.com/download/ws/),( or free 30-day evaluation here(http://www.vmware.com/download/ws/eval.html). Put this line into configuration file of your Linux VM:

debugStub.listen.guest32=1

Now whenever you run the virtual machine, you'll see the following in the vmware.log file (debug builds will also print this message to Host console):

VMware Workstation is listening for debug connection on port 8832.

Run gdb on the Host, reference it to the kernel with symbols and attach to the virtual machine:

% gdb
(gdb) file vmlinux-2.4.21-27.EL.debug
(gdb) target remote localhost:8832

That's it. The VM is blocked now, so you can "continue" it and "^C" back to gdb. Breakpoints, single step, memory inspection - all this works as usual. If you have SMP VM, then each VCPU is mapped on a thread, so use "info threads" and "thread NN" to switch between them.

Debugging the 64-bit kernel works in the same way, except you need to use a different option:

debugStub.listen.guest64=1

and connect to port 8864. Since gdb starts in 32-bit mode by default, you may also need to switch it to i386:x64-64 before connecting:

(gdb) set architecture i386:x86-64
(gdb) target remote localhost:8864

The kernels with symbols are sadly lacking on most distributions, but if you use RHEL then this website may help (look for kernel-debuginfo rpm):

http://people.redhat.com/duffy/debuginfo/index-js.html

The gdb support in WS6 is experimental, so there may be rough edges here and there. Please post on community forums if something doesn't work right or if you have a suggestion:

http://communities.vmware.com/community/vmtn/general/guestdebugmonitor

There are more debugging specific features in WS6 (for example, you can use gdb hand-in-hand with Record/Replay!). I will describe them shortly.

Updated 4/20/07: added explanation of 64-bit support.
Updated 5/14/07: release build prints "waiting for gdb" message into vmware.log only.
Updated 7/24/07: pointers to new build and discussion forum.


-----
Cheers,
June

화요일, 1월 05, 2010

일기 (2010.01.04) Heavy Snowfall today

I surprised today morning by heavy snowfall.
its height may almost 30 cm. unbelievable... can you see this?




















blocked road, accidents, yea that is, South Korea have deadlock today.

에씨... 여기에서 부턴 한글로 쓰자...
오늘 날씨도 이런데, 퇴근후에 집에 가는길이었다.
한 여자가 나에게 "excuse me" 하면서 길을 물어 보는 것이다.

말투를 들어보니 일본인 이었다. 책을 가리키면서 여기가 어디냐고 물어보길래 map 에서 여기 위치를 알려 주었다.
여행 guide book 을 보니 일본인 이었다.

신사역 근처 "원조 할머니 보쌈?" 식당에 가서 저녁을 먹을 것이라고 한다.
마침 가는 길이라서 "just follow me" 라고 외치며 함께 신사역까지 이동했다.

그런데, 옆에 있던 남자분... 동양인인데, 다들 일본인 이냐고 물어보니 여자는 일본인이며, 남자는 중국인 이라고 한다.
하지만 미국에서 자라서 영어를 한다. native 다... -_-;;;

얘기 하는내내 나는 꿀먹은 벙어리? 마냥 말문이 트이지 않았다.
너무 갑작스러운 만남이었으며 'tall' 과 'hill' 단어의 native pronunciation 에 좌절을 하고 말았다.
일본으로 가는 부산에서 하와이 출신이며 학교 선생님인 흑인과의 대화에서 'taurine' 의 pronunciation 에 좌절을 맛본 이후 이번이 두 번째이다...

학동 사거리쯤에서 신사역까지 걸어 가면서 위치나 신기해 하는 것들을 알려줬다.
여자는 한국에 몇 번 와보았다고 하며 남자는 이번이 처음 이라고 했다.
남자가 나에게 이렇게 얘기했다. 미국에 왔냐고.
가보지 않았다고 하니 한 번 와보지 않겠냐고 해서 그냥 희망 한다고만 말했다.
부러웠다.... 아니 부러우면 지는건가?

지금은 을지병원으로 바뀐 안세병원 사거리에서, 남자분이 을지병원을 보며 저게 뭐냐고 물어봤다.
병원이라고 알려주었더니 멋지다고 했다 미국엔 hospital 이 'ugly' 하다고 한다. ㅋㅋ 어찌나 재밌던지...
그리고 '박찬호' (pronunciation 역시였다... -_-;) 는 아는데 '앙드레 김' 은 모르더라...
그래서 한국과 프랑스 파리에서 유명한 디자이너라고 했다. ㅎㅎ

여자분은 호기심이 많은건지, 큰 복어가 있는 식당을 카메라에 담겠다며 도로까지 나가 버렸다. -_-;;
덕분에 중국인 남자분과 나는 그 귀여운 여연을 위하여(?) 기꺼이 도로로 나가서 guard 해주었다.
나는 내 발목 위까지 쌓인 눈을 밟고(-_-;) 여자분은 너무 신이 났던것 같다.

나는 영화 'Avatar' 를 봤는데 둘은 아직 보지 못했다고 한다. 그냥 "fantastic" 하다고 했다. ㅋㅋ
이렇게 얘기를 하다보니 신사역에 도착.

신사역까지 내려가서 가는 길 한번 더 확인 하고 서로 "Happy New Year" 를 건네며 헤어졌다.
짧은 시간 이었지만, 한/중/일 이렇게 세 명이서 영어로 이렇게 저렇게 얘기를 하면서 행복을 느꼈다.
나도 일본 여행때 많은(?) 여인들의 도움을 받았기에 한국에 여행온 관광객을 목적지까지 편히 갈 수 있게 도와주었다.
그치만 오늘 영어회화는 0점이어서 나에게도 실망했지만, 너무 쪽팔렸다. ㅠ.ㅠ
정말 쪽팔렸다. 회화는 꾸준이 계속해야겠다.

-----
Cheers,
June

월요일, 1월 04, 2010

2016 Bug Hits Text Messages, Payment Processing

2016 Bug Hits Text Messages, Payment Processing

Source: http://tech.slashdot.org/story/10/01/03/1312209/2016-Bug-Hits-Text-Messages-Payment-Processing

Posted by Soulskill  on Sunday January 03, @09:01AM
from the y2k16-has-more-characters-than-2016 dept.

An anonymous reader writes "It seems some systems are suffering from a Y2K16 bug.
When 2009 ticked over to 2010, some Australian EFTPOS machines skipped to the year 2016.
Coincidentally, some Windows Mobile users are also having issues with their new year SMSes coming from 2016.
What function could cause this kind of error?"


-----
That problem has been occurred in South Korea here too. ^^; lol

Article: LG전자, 휴대폰 문자메시지 '오류' 발생
Source: http://www.zdnet.co.kr/Contents/2010/01/02/zdnet20100102220431.htm

this means,
you've got SMS on 0 o'clock January, 1st 2010 then '2010' will be displayed as '2016'.
my mobile phone also has been occurred... shit !!!

LG Telecom supports patching this bug in there official web site

LGT Apologizes:
http://www.cyon.co.kr/lgcyon/pop/20100103/20100103_sorry.html

LGT Patch Software:
http://www.cyon.co.kr/lgcyon/pop/20100101/pop_sms_20100101.html


Cheers,
June

Debugging the kernel using Ftrace - part 2

Debugging the kernel using Ftrace - part 2


Source: http://lwn.net/


Debugging the kernel using Ftrace - part 2
[Kernel] Posted Dec 22, 2009 17:39 UTC (Tue) by jake
The Ftrace tracing utility has many different features that will assist in tracking down Linux kernel problems. The previous article discussed setting up Ftrace, using the function and function graph tracers, using trace_printk(), and a simple way to stop the recording of a trace from user space. This installment will touch on how user space can interact with Ftrace, faster ways of stopping the trace, debugging a crash, and finding what kernel functions are the biggest stack hogs.


-----
Cheers,
June

Debugging the kernel using Ftrace - part 1

Debugging the kernel using Ftrace - part 1

Source: http://lwn.net/Articles/365835/

Ftrace is a tracing utility built directly into the Linux kernel. Many distributions already have various configurations of Ftrace enabled in their most recent releases. One of the benefits that Ftrace brings to Linux is the ability to see what is happening inside the kernel. As such, this makes finding problem areas or simply tracking down that strange bug more manageable.

Ftrace's ability to show the events that lead up to a crash gives a better chance of finding exactly what caused it and can help the developer in creating the correct solution. This article is a two part series that will cover various methods of using Ftrace for debugging the Linux kernel. This first part will talk briefly about setting up Ftrace, using the function tracer, writing to the Ftrace buffer from within the kernel, and various ways to stop the tracer when a problem is detected.
Ftrace was derived from two tools. One was the "latency tracer" by Ingo Molnar used in the -rt tree. The other was my own "logdev" utility that had its primary use on debugging the Linux kernel. This article will mostly describe features that came out of logdev, but will also look at the function tracer that originated in the latency tracer.

Setting up Ftrace

Currently the API to interface with Ftrace is located in the Debugfs file system. Typically, that is mounted at /sys/kernel/debug. For easier accessibility, I usually create a /debug directory and mount it there. Feel free to choose your own location for Debugfs.
When Ftrace is configured, it will create its own directory called tracing within the Debugfs file system. This article will reference those files in that directory as though the user first changed directory to the Debugfs tracing directory to avoid any confusion as to where the Debugfs file system has been mounted.
[~]# cd /sys/kernel/debug/tracing
    [tracing]#
This article is focusing on using Ftrace as a debugging tool. Some configurations for Ftrace are used for other purposes, like finding latency or analyzing the system. For the purpose of debugging, the kernel configuration parameters that should be enabled are:
CONFIG_FUNCTION_TRACER
    CONFIG_FUNCTION_GRAPH_TRACER
    CONFIG_STACK_TRACER
    CONFIG_DYNAMIC_FTRACE

Function tracing - no modification necessary

One of the most powerful tracers of Ftrace is the function tracer. It uses the -pg option of gcc to have every function in the kernel call a special function "mcount()". That function must be implemented in assembly because the call does not follow the normal C ABI.
When CONFIG_DYNAMIC_FTRACE is configured the call is converted to a NOP at boot time to keep the system running at 100% performance. During compilation the mcount() call-sites are recorded. That list is used at boot time to convert those sites to NOPs. Since NOPs are pretty useless for tracing, the list is saved to convert the call-sites back into trace calls when the function (or function graph) tracer is enabled.
It is highly recommended to enable CONFIG_DYNAMIC_FTRACE because of this performance enhancement. In addition, CONFIG_DYNAMIC_FTRACE gives the ability to filter which function should be traced. Note, even though the NOPs do not show any impact in benchmarks, the addition of frame pointers that come with the -pg option has been known to cause a slight overhead.
To find out which tracers are available, simply cat the available_tracers file in the tracing directory:
[tracing]# cat available_tracers 
    function_graph function sched_switch nop
To enable the function tracer, just echo "function" into the current_tracer file.
[tracing]# echo function > current_tracer
    [tracing]# cat current_tracer
    function

    [tracing]# cat trace | head -10
    # tracer: function
    #
    #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
    #              | |       |          |         |
                bash-16939 [000]  6075.461561: mutex_unlock <-tracing_set_tracer
              -0     [001]  6075.461561: _spin_unlock_irqrestore <-hrtimer_get_next_event
              -0     [001]  6075.461562: rcu_needs_cpu <-tick_nohz_stop_sched_tick
                bash-16939 [000]  6075.461563: inotify_inode_queue_event <-vfs_write
              -0     [001]  6075.461563: mwait_idle <-cpu_idle
                bash-16939 [000]  6075.461563: __fsnotify_parent <-vfs_write
The header explains the format of the output pretty well. The first two items are the traced task name and PID. The CPU that the trace was executed on is within the brackets. The timestamp is the time since boot, followed by the function name. The function in this case is the function being traced with its parent following the "<-" symbol.
This information is quite powerful and shows the flow of functions nicely. But it can be a bit hard to follow. The function graph tracer, created by Frederic Weisbecker, traces both the entry and exit of a function, which gives the tracer the ability to know the depth of functions that are called. The function graph tracer can make following the flow of execution within the kernel much easier to follow with the human eye:
[tracing]# echo function_graph > current_tracer 
    [tracing]# cat trace | head -20
    # tracer: function_graph
    #
    # CPU  DURATION                  FUNCTION CALLS
    # |     |   |                     |   |   |   |
     1)   1.015 us    |        _spin_lock_irqsave();
     1)   0.476 us    |        internal_add_timer();
     1)   0.423 us    |        wake_up_idle_cpu();
     1)   0.461 us    |        _spin_unlock_irqrestore();
     1)   4.770 us    |      }
     1)   5.725 us    |    }
     1)   0.450 us    |    mutex_unlock();
     1) + 24.243 us   |  }
     1)   0.483 us    |  _spin_lock_irq();
     1)   0.517 us    |  _spin_unlock_irq();
     1)               |  prepare_to_wait() {
     1)   0.468 us    |    _spin_lock_irqsave();
     1)   0.502 us    |    _spin_unlock_irqrestore();
     1)   2.411 us    |  }
     1)   0.449 us    |  kthread_should_stop();
     1)               |  schedule() {
This gives the start and end of a function denoted with the C like annotation of "{" to start a function and "}" at the end. Leaf functions, which do not call other functions, simply end with a ";". The DURATION column shows the time spent in the corresponding function. The function graph tracer records the time the function was entered and exited and reports the difference as the duration. These numbers only appear with the leaf functions and the "}" symbol. Note that this time also includes the overhead of all functions within a nested function as well as the overhead of the function graph tracer itself. The function graph tracer hijacks the return address of the function in order to insert a trace callback for the function exit. This breaks the CPU's branch prediction and causes a bit more overhead than the function tracer. The closest true timings only occur for the leaf functions.
The lonely "+" that is there is an annotation marker. When the duration is greater than 10 microseconds, a "+" is shown. If the duration is greater than 100 microseconds a "!" will be displayed.

Using trace_printk()

printk() is the king of all debuggers, but it has a problem. If you are debugging a high volume area such as the timer interrupt, the scheduler, or the network, printk() can lead to bogging down the system or can even create a live lock. It is also quite common to see a bug "disappear" when adding a few printk()s. This is due to the sheer overhead that printk() introduces.
Ftrace introduces a new form of printk() called trace_printk(). It can be used just like printk(), and can also be used in any context (interrupt code, NMI code, and scheduler code). What is nice about trace_printk() is that it does not output to the console. Instead it writes to the Ftrace ring buffer and can be read via the trace file.
Writing into the ring buffer with trace_printk() only takes around a tenth of a microsecond or so. But using printk(), especially when writing to the serial console, may take several milliseconds per write. The performance advantage of trace_printk() lets you record the most sensitive areas of the kernel with very little impact.
For example you can add something like this to the kernel or module:
trace_printk("read foo %d out of bar %p\n", bar->foo, bar);
Then by looking at the trace file, you can see your output.
[tracing]# cat trace
    # tracer: nop
    #
    #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
    #              | |       |          |         |
               <...>-10690 [003] 17279.332920: : read foo 10 out of bar ffff880013a5bef8
The above example was done by adding a module that actually had a foo and bar construct.
trace_printk() output will appear in any tracer, even the function and function graph tracers.
[tracing]# echo function_graph > current_tracer
    [tracing]# insmod ~/modules/foo.ko
    [tracing]# cat trace
    # tracer: function_graph
    #
    # CPU  DURATION                  FUNCTION CALLS
    # |     |   |                     |   |   |   |
     3) + 16.283 us   |      }
     3) + 17.364 us   |    }
     3)               |    do_one_initcall() {
     3)               |      /* read foo 10 out of bar ffff88001191bef8 */
     3)   4.221 us    |    }
     3)               |    __wake_up() {
     3)   0.633 us    |      _spin_lock_irqsave();
     3)   0.538 us    |      __wake_up_common();
     3)   0.563 us    |      _spin_unlock_irqrestore();
Yes, the trace_printk() output looks like a comment in the function graph tracer.

Starting and stopping the trace

Obviously there are times where you only want to trace a particular code path. Perhaps you only want to trace what is happening when you run a specific test. The file tracing_on is used to disable the ring buffer from recording data:
[tracing]# echo 0 > tracing_on
This will disable the Ftrace ring buffer from recording. Everything else still happens with the tracers and they will still incur most of their overhead. They do notice that the ring buffer is not recording and will not attempt to write any data, but the calls that the tracers make are still performed.
To re-enable the ring buffer, simply write a '1' into that file:
[tracing]# echo 1 > tracing_on
Note, it is very important that you have a space between the number and the greater than sign ">". Otherwise you may be writing standard input or output into that file.
[tracing]# echo 0> tracing_on   /* this will not work! */
A common run might be:
[tracing]# echo 0 > tracing_on
    [tracing]# echo function_graph > current_tracer
    [tracing]# echo 1 > tracing_on; run_test; echo 0 > tracing_on
The first line disables the ring buffer from recording any data. The next enables the function graph tracer. The overhead of the function graph tracer is still present but nothing will be recorded into the trace buffer. The last line enables the ring buffer, runs the test program, then disables the ring buffer. This narrows the data stored by the function graph tracer to include mostly just the data accumulated by the run_test program.

What's next?

The next article will continue the discussion on debugging the kernel with Ftrace. The method above to disable the tracing may not be fast enough. The latency between the end of the program run_test and echoing the 0 into the tracing_on file may cause the ring buffer to overflow and lose the relevant data. I will discuss other methods to stop tracing a bit more efficiently, how to debug a crash, and looking at what functions in the kernel are stack hogs. The best way to find out more is to enable Ftrace and just play with it. You can learn a lot about how the kernel works by just following the function graph tracer.

(Log in to post comments)

Debugging the kernel using Ftrace - part 1
Posted Dec 11, 2009 23:43 UTC (Fri) by eparis123 (subscriber, #59739) [Link]
This is indeed a great writeup, and the interface is unixy and elegant.
Thanks a lot for your efforts on ftrace and for writing this article :)

Debugging the kernel using Ftrace - part 1
Posted Dec 14, 2009 5:09 UTC (Mon) by gdt (subscriber, #6284) [Link]
Typically, that is mounted at /sys/kernel/debug. For easier accessibility, I usually create a /debug directory and mount it there.
Please don't do this sort of weirdness in tutorials, unnecessarily changing a perfectly usable default just gets in the way of your [otherwise very fine] exposition.
That goes double for reviewers of Linux distributions. I've lost count of the number of reviews that don't review the out-of-the-box distribution, but rather review some author's preferences applied to that distribution.

Debugging the kernel using Ftrace - part 1
Posted Dec 14, 2009 15:14 UTC (Mon) by nevets (guest, #11875) [Link]
BTW, I noticed that if DEBUGFS is configured, the /sys/kernel/debug directory automatically is created. But why isn't the debugfs automatically mounted there? I mean, the /sys file system is already a pseudo system, why not have it automatically mount debugfs?
If this was the case, I would not need to create a "find_debugfs()" function to search through mounts to find that directory in my tools.

I do pick /debug because I usually do not do my tracing in the debugfs/tracing directory. And it is much easier to type /debug than to type /sys/kernel/debug (even with tab completion). I could also ln -s to /sys/kernel/debug, but if I have to do that, why not just mount it at /debug.

Again, if /sys/kernel/debug automatically mounted debugfs, then a link would be reasonable.

Debugging the kernel using Ftrace - part 1
Posted Dec 17, 2009 5:59 UTC (Thu) by abadidea (guest, #62082) [Link]
gdt: bikeshedding much? :)

Debugging the kernel using Ftrace - part 1
Posted Dec 18, 2009 8:38 UTC (Fri) by tejparkash (guest, #53332) [Link]
I guess these lines should be there in Setting up Ftrace
HowTo mount the debugfs system:
# mkdir /debug
# mount -t debugfs nodev /debug

Anyway simple and excellent article, specially trace_printk is something new to me, as i have observed the all problems listed due to printk.
Waiting eagerly Part-II......


-----
Cheers,
June

[경/공매] 2억으로 강남아파트에 입성하다.

this story is like a novel, but interesting... ^___^
read this smoothly.


[경/공매] 2억으로 강남아파트에 입성하다.

아파트, 그 떨쳐버릴 수 없는 매력
벌써 6월이다.
코끝을 기분 좋게 간지르는 미풍의 산들거림에 스르르 눈이 감겨온다.
수많은 상념 속에서 작년 이 맘 때의 기억들이 아련하게 피어오른다.
이리 치이고 저리 차이고 ..... 희망 없이 암담하기만 했던, 그저 힘들기만 했던 1년 전의 기억들이 시간너머 아득하다.

 미래에 대한 희망을 품어 보고 싶어서.... 사람같이.... 인간처럼 살고 싶어서 돌파구를 모색하다가 우연찮게 경매계로 접어든지 벌써 1년.

경매입문 초반에는 환금성 좋은 아파트가 주된 관심의 대상이었다.
얼마를 투자해서, 얼마 후에 급매를 놓고, 얼마의 차익을 내면, 얼마의 수익률이 되고....
장미빛 환상 속에서 끝없이 공부하고, 끝없이 현장조사하고, 끝없이 응찰하고, 끝없이 낙방했다.
희망과 좌절의 비율이 적절히 배합된, 그럼으로써 하루하루 견딜 수 있었던....그저 버티기만해도 성공인 그런 나날이었다.


어느 정도 실전 경험이 쌓이자 경매의 꽃이라고 할 수 있는 아파트에 본격적으로 눈을 돌렸다.
그러나 당시 아파트에만 10여건을 집중적으로 응찰했는데 한 건도 낙찰 받지 못했다.
그때에도 실수요자나 아줌마 부대들을 고려하여 누구나 쉽게 판단할 수 있는 평범한 물건은 거들떠보지도 않았었는데.....

유치권 신고 된 물건이나 선순위 가처분이 있는 물건, 대지권 미등기 물건이나 예고등기 있는 물건.......
이도저도 아니면 최소한 토지 별도등기라도 있는 물건에 응찰을 했으나 평균적으로 20명 이상씩 응찰하여 2등을 2번했던 기억 말고는 모두 순위조차 알 수 없거나 1등하고의 금액차가 너무 커서 순위조차 알고 싶지 않았던 경우가 대부분이었다.


그 중에 기억나는 물건이 하나 있다!
서울 성북구 정릉동에 소재한 30평형대 재건축 아파트.
거의 감정가의 반에 육박하는 거액의 유치권이 신고 되어 있었고 대지권은 미등기에다가 대지권 유무 불명이 아닌, 아예 대지권 없음이 공지된 물건. 그리고 채무자의 소유권과 경매신청 채권인 저당권이 추후 소송결과에 따라 말소되리라는 예고등기까지 있었던 물건이었다.
최저가는 감정가 대비 50%대....

오랫만에 물건이다 싶어 장장 일주일을 권리분석에 매진(?)했다.
현장탐문결과, 유치권은 허위의 개연성이 상당했고 신고금액의 10%정도면 협상이 가능하리라 판단되었다.
예고등기 또한 대법원 사이트 검색결과 원고 패로 이미 소송이 끝난 상태였기 때문에 아무런 문제가 없었으나 문제는 대지권 미등기였다.
대지지분이 아예 없는 것으로 물건 명세서 상 공지되었고 당연히 감정가에도 대지지분은 포함되지 않았다. 결국 외관상으로는 낙찰자가 현재 대지소유자에게 대지지분을 매수해야하는 상황이었다.
토지등기부 등본을 떼보니 누군가가 위 아파트 호수의 대지지분을 미리 사놓고 있었다.
이름이 낯익어 자세히 보니 바로 유치권자였다.
유치권자가 대지지분을 사놓고 위 건물을 낙찰 받으려는 의도였다.
저가에 낙찰받기 위해 허위의 유치권을 신고해 두고......

흠......대강 알만한 스토리였다....!

판례를 검색하다가 '대지권이 이미 성립한 후에 건물과 분리하여 대지권만을 매도하는 경우에는 그 매매계약은 무효이고 대지권은 건물의 처분에 종속하여 건물소유자에게 귀속한다'는 내용의 판례를 찾아냈다. 잘하면 공짜로 대지권을 얻을 수 있겠다 싶었다.
여러 자료들을 분석하여 나름의 비하인드 스토리를 구성해 보고 별문제 없겠다 싶어서 응찰했다.
이렇듯 복잡한 물건에 누가 들어오겠는가....!
그래도 혹시 몰라 신중을 기하기로 하고 응찰가를 최저가보다 1000만원 정도 더 쓰고 끝자리는 평소 습관에 따라 붙여 넣었는데........!

서울 중앙지법에서 세 번째로 진행된 이 건 개찰에 응찰자로 호명되어 나가는 사람이 끝도 없었다. 나가면서도 모두들 어이없어 했다.
이런 물건에..... 도대체 이 많은 사람들이....!
모두들 표정이 어두웠다. 대부분 최저가 언저리에서 응찰가를 써 넣었으리라.

중풍에라도 걸렸는지 지팡이를 짚고 비척이는 걸음걸이로 간신히 법대 앞에 나온 사람이 인상적이었다.
도대체 무슨 사정이 있길래 저런 몸을 이끌고....!
마음은 더 무거워 졌다. 우린 안돼도 저 사람은 꼭 돼야 할 것 같았다.
자포자기의 심정으로 기다리는 데 낙찰자가 호명 되었고 낙찰가는 거의 감정가의 90%에 육박하는 수준이었다.
환하게 웃고 있는 낙찰자는 건강해 뵈는 젊은 친구였다.

곧이어 지팡이를 짚고 또 다시 힘겹게 계단을 올라가는 그 사람의 뒷모습!
처연했다.....하마터먼 눈물이 날 뻔했다.
내가 떨어져서가 아니라, 지팡이의 주인공의 뒷모습이 너무나 지쳐보여서....
그 한 걸음 한 걸음이 너무도 위태로워 보여서.....


암튼 그때 이후로 나는 아무리 좋아 보여도 아파트는 거들떠도 보지 않았다.
그래서 다가구 주택으로 눈을 돌렸고 상계동 소재 다가구 주택과 팽성읍에 있는 단층주택을 낙찰 받았다.
그럼에도 환금성 좋고 대출 잘되는 아파트의 매력은 떨쳐버릴 수 없었나 보다.
상계동 물건이 해결되고 여유가 생기자 강남역 인근에 소재한 90평짜리 주상복합아파트가 우연찮게 눈에 띄었다. 90평짜리 아파트인데 감정가가 12억원에 불과했고 감정시점도 한창 아파트값이 폭등하기 전인 2005년도였다.
현재 최저가는 감정가 대비 64%인 7억 4천여만원......
물건이다.....!   가슴이 뛰기 시작했다....!!!


흙속의 진주인가


아무리 생각해도 강남에 있는 90평짜리 아파트가 12억원밖에 나가지 않는다는 것이 믿기지 않았다.
부동산 사이트에서 대략적이나마 가격을 확인해 보기로 했다.
주소가 서초구 서초동 00밀라트 0타운......
부동산 사이트 어느 곳에서도 위 아파트는 검색되지 않았다.
이걸 어떻게 받아들여야 하나....
이름 없는 아파트라 아예 등록조차 되어 있지 않은 건가. 약간 실망했지만 부동산 사이트 어느 곳을 찾아봐도 서초동 인근 90평형대 주상복합아파트가 12억원 대로 매물등록이 되어 있는 곳은 없었다.
그만한 평수면 대부분 시세가 20억원을 상회하고 있었다.
이것저것 고려해도  15억원 이상은 나갈 것 같았다.

시세는 나중에 현장에서 정확히 확인해 보기로 하고 물건의 법적인 하자에 집중했다.
이 물건에 외관상 드러난 하자는 '토지별도 등기 있음'과 ‘선순위 대항력 있는 임차인의 존재’였다.
인터넷상에서 토지 등기부등본을 발급받아 보았다. 일견 보기에도 부담스러울 만큼 복잡하고 두툼한 등기부 등본이었다!

그러나 꼼꼼히 분석해 본 결과 이건 토지별도등기는 낙찰자가 인수해야 할 성질의 것이 아니었다. 그저 등기부만 복잡할 뿐, 이 건 아파트의 권리관계에는 하등 영향이 없는 별도등기였던 것이다.


그렇다면 남은 문제는 대항력 있는 선순위 임차인.......!
물건 명세서에는 현황조사결과 신**라는 임차인이 액수 미상의 보증금으로 점유하는 것으로 되어 있었다.
위 세입자의 전입신고일은 말소기준권리인 채권자의 최초 가압류 설정일보다 한참을 앞서 있는데 세입자는 배당요구를 하지 않았다. 그리고 보증금의 액수도 모른다.
진정한 임차인이라면 낙찰자가 위 임차인의 얼마인지도 모르는 보증금 전액을 떠안아야 할 상황이었다.
강남지역의 전세가가 보통 매매가의 40%수준이라면 감정가를 시세로 보더라도 5억 가까운 금액을 떠안아야할 판이었다.
결국 전입신고자가 진정한 임차인이라면 현재의 최저가도 높은 것이고 한번은 더 유찰이 되어야 할 물건이었다.

감정평가서를 꼼꼼히 읽어 보았다.
감정평가서에는 위 아파트가 복층구조로 되어 있고 아래층이 60평, 윗층이 30평으로 나누어져 있다고 기재되어 있었다.
곰곰히 생각해 보았다.
주인이 아랫층을 쓰고 윗층은 임대를 내준 게 아닐까? 그렇다면 보증금의 액수가 그리 클 것 같지는 않았다.
그러나 감정평가서상의 내부구조도를 보고는 추측이 틀렸음을 깨달았다.
아랫층은 넓긴 하지만 방이 하나밖에 없었다. 집주인이 방 하나를 쓰고 임차인이 윗층 전부를 사용한다? 상상하기 어려운 일이었다.
역시 아파트 전체를 빌려 쓰는 경우만이 상정 가능한 스토리였다.
음......감이 좋은 물건이긴 했지만 보증금을 떠안고 나면 남는 게 없을 물건인지라 포기해야 할 것 같았다. 그래도 조금의 미련이 남아 건물등기부등본을 들추어 보았다.

몇 장을 떠들어 보다가.....
어라?
나도 모르게 단발마의 감탄사가 새어 나왔다.....!

위장임차인, 딱 걸렸어


등기부는 그야말로 지저분함 그 자체였다. 가압류가 셀 수 없이 많이 등재되어 있었다.
신용보증기금,기술신용보증, 중소기업은행 등등.....
눈짐작으로도 액수가 100억원이 넘어 보였다.
소유자가 중소기업을 운영하다 망했나 보다.
추측건대, 그래도 초반에는 운영이 잘 되었던 것 같다.
근저당권은 하나 없고 어느 시점부터 가압류가 집중적으로 올라와 있는 걸보니.....

만신창이가 된 등기부 내용 중 나의 시선을 잡아 끄는 것이 있었다.
바로 등기부상의 소유자의 주소지였다.....!
처음 이 물건을 매수할 때 등기부상의 소유자의 주소지는 이건 물건의 소재지가 아니었다.그런데 중간에 이건 물건 소재지로 주소를 변경했다. 주소 변경의 원인은 '전거'였다.

소유자가 이 물건을 매수한 뒤 얼마 되지 않아 세입자가 전입신고를 하고 또 그 후 얼마 되지 않아 소유자가 이 물건 소재지로 주소지를 옮겼다......?
소유자의 이름은 남자, 세입자의 이름은 여자.....혹시 둘이 부부가 아닐까?

뇌세포들이 꿈틀댄다.
평소에는 둔하다가도 필요한 순간에는 비록 찰나지만 번득이는 직감....!

'중소기업을 운영하던 남편이 사업이 잘되어 강남에 대형평수의 아파트를 장만했다. 남편이 집에서도 업무를 볼 수 있게 복층 구조 중 아래층은 사무실 용도로 꾸며 놓고 윗층은 주거용으로 사용했을 것이다.
남편은 소유자니까 서둘러 전입 신고할 필요가 없었으나 아이들 학교문제도 있고 하니까 부인과 자녀들이 일부라도 먼저 전입신고를 했을 것이고 뒤이어 남편도 전입신고를 해서 온전한 세대가 되었으리라......그 후 남편사업이 갑자기 어려워지기 시작했고 여기저기서 채권자들이 가압류를 해댔을 것이다.'
마구잡이로 떠오르는 추리를 적당하게 배열해 놓고 보니 그럴듯한 스토리가 되었다...

이제는 추리를 뒷받침할만한 증거자료들의 수집이 필요한 때....!
확인도 안될 머릿속 상상은 그만두고 몸이 나서야 할 차례였다.

현장에 가보자....!
호적등본만 떼어 볼 수 있으면 몸이 고생하지 않아도 될 텐데.....
혹시 몰라 서초동에서 변호사로 개업 중인 후배에게 도움을 청해 보았다.
쉽진 않겠지만 알아봐 주겠단다....
후배만 믿고 있을 수 없어 현장으로 출동했다.
조만간 뭔가 나와도 나올 것이다........!

현장에 가보니


이건 아파트는 강남역에서 교대역으로 가는 중간에 위치해 있었다.
비록 강남역 3번 출구를 위시한 핵심 상권은 아니었지만  테헤란로 대로변 상에 위치한 발전가능성이 무궁한 요지였다.
그리고 19층짜리 주상복합아파트 2개동 중 뒤에 지어진 2타운에 속해 있었고 15층 로얄층에 향 또한 정남향이었다.


오호라.......!
현장에 가보니 더더욱 마음이 끌리는 물건이었다..
한 블럭 옆으로 삼성타운 3개동의 공사가 한창 활기차게 진행 중이었고 바로 옆에는 롯데칠성의 방대한 물류창고가 개발을 기다리며 움츠리고 있었다.
강남의 스카이라인이 점차 교대역, 서초역 방향으로 뻗어 가고 있는 징후가 현장에 가보니 생생하게 느껴진다.

갖고 있으면 꽤 값이 오르겠는데......!

일단 인근의 공인중개사부터 찾았다. 처음에는 전세를 구한다고 했다.
이왕이면 사무실용도로 겸용할 수 있게 복층구조로 된 대형평수를 찾는다고 했더니 곧바로 이 건 아파트 11층 매물을 소개해 준다.
이 건 물건과 동일한 평수이고 내부구조도 동일하다고 한다.
중개사를 대동하고 가보니 휘황찬란한 샹들리에와 고급대리석 바닥.....
전형적인 부자들만의 공간이었다.
짜임새 있게 설계된 복층구조라, 90평이라 해도 광활한(?)느낌은 없었다. 전세가는 6억원이었고 윗층으로 갈수록 좀 더 비싸다고 한다. 그런데 전세 매물은 이건 하나밖에 없다고 한다.
전세뿐만 아니라 일반 매물도 없어 거래는 거의 없다고 한다.
몇 년 전에 한번 자기가 거래를 성사시킨 적이 있는 데 그 후로는 통 거래가 없단다.
조심스럽게 15층 이상의 매매가를 물어보니 거래가 없어 정확히는 모르겠지만 15억에서 17억원까지는 가지 않겠냐는 분석이다.
그리고 옆에서 신축중인 삼성타운 3개동의 입주가 끝나는 내년 상반기 정도면 수요가 늘어 매매가도 높아지지 않겠냐는 전망도 내놓는다.

공인중개사가 보여준 전세물건은 '어둡고.... 시끄럽고.....구조가 답답하고.....'등등
이런 저런 핑계로 거절하고 이번에는 혼자서 다시 현장으로 돌아왔다.

먼저 우편함을 살펴보는 게 순서겠지.....? 
우편물을 살펴보는데 등 뒤에서 걸걸한 목소리가 귀청을 때렸다!


허물어지는 모래성


돌아보니 인상 좋아 보이는 중년의 아저씨가 털털한 눈웃음을 짓고 있었다.
모범택시기사들이나 입을 듯한 빛바랜 제복을 입고 빤히 쳐다본다.
경비아저씨였다!
“거기서 뭐하세요? 누굴 찾으세요?”
경계의 빛은 없는, 단지 의아함만이 묻어나는 목소리다.
순간 당황했지만 애써 태연을 가장하며 둘러댔다.
'아, 예.....15**호 사는 분을 좀 찾아 왔는데요.'
'아, 김사장님? 김사장님 조금 전에 가족들하고 나가셨는데.....어쩌나.....'
낯선 사람이 입주자의 우편함을 뒤지는 것을 목격한 후임에도 오히려 내가 찾아 온 사람을 못 만나고 그냥 가는 것이 다만 안타까운듯한 목소리였다.
"그래요......? 다음에 또 오지요 뭐....그럼 수고하세요.''

정중하게 인사를 하고 황급히 돌아 나오면서도 머릿속으로 불안한 상념이 스쳐 지나간다.
'김 사장이라....? 소유자는 성이 임씨였고 임차인은 신씨던데.....김 사장이라니?'
기껏 쥐어짜낸 추리가 모래성처럼 허물어질 판이었다.
임차인이 김씨 성을 가진 사람하고 살고 있구나.....!
그렇다면 진정한 임차인일 가능성이 높았다.
공인중개업자 말에 의하면 11층의 전세보증금이 6억원에 윗층으로 갈수록 조금씩 비싸다고 했으니 최소한 6억원을 더 떠안고 나면.....?
술 담배에 찌들어 머리가 많이 무뎌졌으나 이 건 쉽사리 계산이 되었다.^^::

더 볼 것도 없었다! 포기하자!!!


아쉬움을 뒤로한 채 발걸음을 돌렸다.
돌아오면서 둘러 본 이 건 물건 일대!
삼성 타운 3개동 중 1개동은 벌써 입주가 끝나 은백색의 창속에 푸른빛의 하늘을 가득 품고 있었고 나머지 2개동도 어느 정도는 마천루로서의 위용을 드러내고 있었다.
삼성직원들 5만명이 입주하면 관련업체들과 방문객들을 고려할 때 늘어나는 유동인구는 20만명!
이 지역 인근에 나오는 상가나 오피스텔은 꼭 잡아야겠다는 결심이 이번 임장의 수확이라면 수확이었다.
허탈한 마음으로 돌아오는 길에 담배하나를 피워 물었다.
라이터를 찾으려고 주머니에 손을 넣자 손끝을 가볍게 간지르는 휴대폰의 진동!
후배 변호사였다!!!


상황은 역전되고


현장 확인결과 포기하기로 마음먹은 후였음에도 후배의 전화에 사뭇 긴장된다.
'여보세요?'
목소리가 가볍게 떨린다 . 이런 새가슴......!
심호흡을 하고 다소 힘을 내본다.
'그래 좀 알아봤어? '
의례적인 인사는 생략하고 곧바로 본론으로 들어갔다.
'예, 형 여직원 시켜서 알아봤는데 .....호적등본 떼는 거 그거 쉽지 않데요.
여직원 고생 무지했어요. 나중에 한턱 크게 쏘셔야 겠어요!'
한턱 쏘라고? 그럼?

후배의 입에서 기대했던 이야기가 흘러나왔다..
“네. 처음에는 담당 직원이 이해관계인이 아니면 변호사 아닌 대통령이 와도 안된다고 막무가내랍니다.....그래서 자초지종을 얘기했데요. 경매 들어가려는데 그 집에 세입자가 있는지 없는지를 도저히 알아볼 수가 없어서 그러니 소유자와 전입자가 부부인지 아닌지만 알려달라고요. 한참을 고민하다가 결국은 안된다고 해서 돌아서려는데 그 모습이 안쓰러웠는지 옆 사람과 상의하더니 둘이 부부가 맞다고 알려 주더라네요. 요즘 공무원들 철저해요. 조금이라도 불법의 소지가 있으면 안하려고 하지요. 근데 이건 개인의 신상정보를 알려 준 것이 아니고 단지 둘이 부부라는 것만 확인해 준거니까  불법은 아니지요. 그러니 괜한 걱정은 마시구요.”
“그래 고생이 정말 많았구나!”

정말 듣던 중 반가운 소리였지만 이내 의문이 생겨 내친 김에 물어 보았다.
“근데 경비아저씨가 그 호수에는 다른 사람이 산다던데......성이 김씨라던데.....”
“경비아저씨가 잘 모를 수도 있지요 뭐. 만약 그렇다 해도 뭔 걱정이에요. 전입신고한 사람과 소유자가 부부고 그렇다면 형이 낙찰 받아도 떠안을게 없다는 것이 중요한 거지요.”
그렇다. 물건 명세서 상 분명히 임차인은 신**씨 한명이었고 전입세대 열람부에도 전입신고자는 신씨뿐이었다.
그렇다면 혹시 현재 그 집에 다른 사람이 살고 있어도 낙찰자에게는 대항할 수 없는 것이다. 그저 인도명령 대상자일 뿐.....

“둘이 이혼은 안했겠지?”
부부사이라도 이혼한 후라면 그때부터 임대차관계가 성립한다는 판례를 본 적이 있어 조심스럽게 물어 보았다.
“네에~공무원이 별다른 얘기는 안했다니 아직까지는 적법한(?) 부부로 보여요~”
내 질문의 의도를 알아챘는지 말꼬리를 길게 늘이며 너스레를 떤다.”
“그래 고맙다. 나중에 한턱 쏠게. 그때 여직원도 꼭 데리고 나와!”
필요할 때 힘이 되어 주는 고마운 후배였다.


허물어질 뻔했던 모래성이 든든한 반석으로 다시 지어졌다!
정리해보면, 이 건에는 현재 아무런 법적인 문제가 없는 상태다.
이건 물건 명세서는 집행관이 현황 조사할 때 폐문으로 인하여 임대차 관계를 파악하지 못하자, 일단 소유자가 아닌 다른 사람이 전입 신고되어 있으니 잠정적으로 이를 임차인으로 보고 응찰자들에게 확인을 해보라는 취지로 작성되었을 것이다.


세입자라고 기재된 신**씨는 이 건 물건의 어엿한 안주인이니 법원에서 임대차권리관계를 신고하라고 문건을 보내와도 그냥 흘려버렸을 것이고. 그래서 법원에 제출된 문건은 아무것도 없었고.....당연히 배당요구도 안했을 것이니 보증금 액수도 미상인 것이고....


그나저나 이 글 제목을 위장임차인 색출기라 했는데, 그 집의 전입신고자는 저가낙찰을 노린 위장임차인이 아니었다! 너무나도 정직하고 성실한 대한민국의 국민이자, 자랑스러운 서울 시민이었던 것이다.  임차인 만세......!
돌아오는 발걸음에 힘이 넘쳐흘렀다.
처음에는  막연한 상상의 나래로 접근했다가 우여곡절 끝에 추리가 사실로 들어난 순간이었다.


다시금 머릿속을 정리해 본다.
토지별도등기는 낙찰자의 소유권과는 무관하고, 일견 대항력 있는 임차인으로 보이는 전입자 또한 낙찰자와는 무관하다. 100억원이 넘어가는 가압류들이야 낙찰로서 추풍낙엽처럼 빨간 줄이 그어질 운명들.....

좋다! 들어가자!!
문제는 응찰가였다.
이 물건 누가 들어오겠어? 한두 명 들어와도 최저가 언저리에서들 쓰겠지....?
당시 우쭐한 기분에 떠올랐던 생각들이 나중에 며칠 밤을 하얗게 지세우게 하는 빌미가 될 줄이야 그때는 정말이지 짐작도 하지 못했다.......!


과연 얼마를 써야할까


앞으로 입찰일까지 주어진 시간은 나흘!
응찰가를 얼마를 써야할지 지루한 고민이 시작되었다.
현장에서 느낀 직감은 단독응찰이거나 고작해야 한두 명의 경쟁자가 있을 것이라는 판단이었지만 시간이 갈수록 머리속으로 떠오르는 경쟁자의 숫자가 늘어난다.
그로 인하여 예상 낙찰가 또한 하염없이 올라간다.
처음에는 최저가보다 1000만원 정도만 높게 쓰면 무난히 낙찰되겠다 싶었는데 고민에 고민을 거듭하다보니 예상 응찰가가  11억원대까지 올라가 있었다.
이런 식으로 고민하다가는 막판에는 감정가를 넘겨 쓸 것 같았다.^^:;
마음에 확신을 줄만한 무엇인가가 필요했다.

실전경험이 풍부한 후배 변호사에게 도움을 청하기로 했다.
전화를 걸어 이 건에 대해 조사한 내용을 상세히 설명해 주었다.
그리고는 어떤 식으로 응찰가를 정해야 할지 방향을 좀 알려달라고 부탁했다.
'허어~ 이건 물건은 수익률이 하도 좋아 보여서 형 몰래 나도 들어가려고 했는데 포기해야겠네~'

특유의 썰렁한 농담으로 간담을 서늘하게 한다. 후배변호사랑 붙어서는 승산이 없다.
법적으로 지극히도 복잡했던 균형개발 촉진지구 내 빌라입찰에서 3억원 짜리 빌라를 17명의 경쟁자를 물리치고 7300만원에 낙찰 받은 전력이 있는 친구다. 2등과는 단돈 90만원 차이였다. 당시 우리는 후배에게 변호사 말고 박수무당을 해 보라고 적극 권한 바 있었다!
경쟁자의 응찰가를 신들린 듯이 예상하고 항상 근소한 차이로 낙찰 받는 그 친구랑 만약 법정에서 맞딱뜨리면 진검승부고 뭐고 없다. 그냥 내가 깨끗이 포기하던가, 아니면 선배라는 점을 십분 악용하여 반협박으로 후배를 포기시키던가 둘 중 하나다.


후배의 설명이 이어졌다.
'이 건 물건은 비록 아파트라 해도 경쟁자는 3명 내외일 거예요. 토지별도등기가 결론적으로야 아무런 문제가 없음이 드러났지만, 일단 복잡하고 두꺼운 등기부를 해독할 수 있는 능력이 필요한 만큼 어설픈 실수요자들은 덤비지 못할 것이고 전입신고자가 대항력 있는 세입자가 아니라는 것을 밝혀내는 것도 그리 쉬운 일은 아니거든요.

제가 상정해 볼 수 있는 경쟁자는 일단 전입신고자가 진정한 임차인이라는 전제하에 보증금을 떠안고서라도 이 물건을 낙찰 받겠다는 실수요자인데 이 부류는 응찰가를 최저가 언저리에서 쓰거나 최저가 보다 조금 높은 수준에서 쓸 겁니다.

실수요자다보니 법적인 하자를 판단할 수 있는 능력이 부족하여 응찰가를 자신 있게 쓰지 못하는 부류들이지요. 결국 8억원은 넘기지 않거나 넘겨도 초반 대에 머물겁니다.

또 하나의 경쟁자는 소유자와 전입자가 부부라는 내막을 아는 사람들이겠지요. 여기에도 두부류가 있는데 소유자의 측근들로서 자연스럽게 내막을 아는 경우와 우리처럼 고생고생해서 정보를 캐낸 경우로 나눌 수 있겠지요.
다만, 이 건은 소유자가 저가낙찰을 노리고 위장임차인을 의도적으로 만들어 놓은 경우가 아니기 때문에 소유자의 측근들이 들어올 가능성은 제 직감으로는 희박하다고 보여져요.


지금 소유자는 100억원이 넘는 채권자들의 등살에 못 이겨  잠적했거나 도주 중일 가능성이 농후하고 부인인 전입자 또한 뒤에 남아서 사태를 수습하느라 정신없을 거예요.
결국 남은 것은 우리처럼 노력을 통하여  이 건의 내막을 알게 된 사람들인데 우리가 흔히 고수라고 칭하는 사람들이지요. 그 사람들은 응찰가를 최저가 언저리에서 쓰는 일 따위는 하지 않을 겁니다.

경매를 전업으로 하는 사람들이거나 나름대로 이론과 경험으로 무장된 사람들이기 때문에 응찰가 또한 신중하게들 써낼 것이고 특히 이건의 경우 임대차 보증금을 떠안지 않아도 된다는 사실을 알고들 있기 때문에 응찰가를 쓸 때 보증금의 범위만큼의 유도리가 있지요. 그러니 굳이 최저가 언저리를 고집할 필요가 없는 것이지요.

이 같은 고수들의 특징은 응찰가를 쓸 때 최저가를 기준으로 하지 않고 목표로 하는 수익을 기준으로 삼는다는 것이지요 .그러니까 이건 물건의 급매가가 14억원이라면 5억원 정도의 수익을 목표로 9억원을 쓰자, 뭐 이런 식이 되겠지요.

고수들은 2등과의 금액차이를 크게 신경 쓰지 않습니다. 차이가 몇 천만원이든, 몇 억이든 그저 엿 사먹은 셈치자며 호방하게 한번 웃고 미련을 버리지요.
그런데 초보들은 그렇지를 못해요. 응찰가를 높게 썼다가 단독응찰이면  어쩌나....
2등은 얼마를 쓸까.....2등하고 차이가 크면  어쩌나 ....최대한 차이를 줄이려면 도대체 얼마를 써야할까....등등.....(애고~~ 찔려라^^::)


신이 아닌 이상 알 수 없는 상대방의 정확한 응찰가를 추측해 보느라 쓸데없는 헛힘을 다써버리는 것이지요. 이렇듯 하수와 고수의 차이가 극명히 드러나는 때가 바로 응찰가를 결정할 때입니다.

이 건 물건의 경쟁자는 주로 고수들이라고 볼 때 최소한 최저가보다 1억원 이상은 더 쓸 겁니다. 다만 터무니없이 높게도 쓰지 않겠지요. 오랜만에 물건이다 싶어 어느 정도의 수익을 올리고 싶어 할 것이니까요.
다만, 수익을 어느 정도로 잡고 응찰가를 얼마로 쓰느냐는 오랜 기간의 경륜으로 자연스레 체화된 내공의 크기에 따라 달라지겠지요.'


경쟁자의 부류와 심리, 그리고 경륜까지도 고려해 응찰가를 정한다? 허어 역시~!!

거두절미하고 단도직입으로 물어 보았다.
'그래 너 같으면 이 경우에 얼마나 쓸 것 같냐....?'
과연 후배가 정확한 답을 내려 줄 것인가......
온 신경이 수화기로 집중되는 것을 느꼈다!


장고 끝에 내린 결론


짧은 침묵이 이어졌다. 평소에는 급한 성격이지만 중요한 순간에는 신중한 후배다.
드디어........!
“제 생각에는  토지별도등기는 문제가 아니겠지만 고수들의 견지에서도 이 건 전입자가 소유자와 부부임을 밝히는 것은 쉽지 않을 듯 해요.
현재 전입자는 웬만한 방문객들과의 만남은  회피할 것이기 때문에 직접 만나 확인하는 것은 불가능해 보이구요. 경비 아저씨 말대로라면 그 집의 거주자는 김 사장이라는 사람이니 여기서도 한번 혼돈스러울 거예요....

둘이 부부라는 추리도 상상력 풍부한 형이나 가능한 거지,  고수들 중에도 그냥 흘려버리는 경우가 있을 것이고.....만약 형처럼 생각하는 사람이 있어서 부부라고 추측했다 해도 아시다시피 호적열람해 보는 게 여간해선 쉽지가 않거든요...
그렇다면 아무리 고수들이 경쟁자라해도 응찰가를 너무 높게 쓸 필요는 없을 것 같아요.
최소한 1억은 넘기되 2억 이상 더 쓰실 필요는 없을 듯해요.
한번 신중하게 생각해 보세요.....최종 결정은 형이 하시구요. 제가 괜히 응찰가까지 말했다가 나중에 잘못되면 그 원성을 어떻게 들어요? '

그렇다......난 단지 후배에게  도움을 청하려 했던 것이지 내 고민을 떠넘기려 했던 것이 아니었다.
어차피 최종결정은 내 몫이었다........!


                                                     ***


밤이다......
구름한 점 없는 청명한 밤하늘 너머로 오랫만에 별들이 가득하다.
도심을 벗어나.... 금방이라도 쏟아질 듯한 별들의 폭포아래서 사랑하는 사람들과 별자리 이야기로 웃음 꽃을 피울 날 언제 오려나......
숱한 상념 속에서도 낮에 들었던 후배의  일갈이 머릿속을 맴돈다.
'고수들은 응찰가를 쓸 때 목표수익만이 고려의 대상이지 2등과의 차이는 크게 신경 쓰지 않는다!'
물론 고수들도 사람이니 결과적으로 단독응찰이거나 2등과의 차이가 크게 나면 속이 좀 쓰리겠지만 그래도 '엿 사먹은 셈' 치고 훌훌 미련을 털어 버린다잖는가!
그러나 그러한 경지는 억지로 흉내 낸다고 될 것이 아니었다. 오랜 시간 좌절과 성공의 반복 끝에 자연스럽게 몸에 스며든 경륜과 연륜의 결과일 것이기에......

막연하게 상상해 본다.
최저가보다 1억 5천만원이 높은 금액을 써서 낙찰은 받았는데 결과적으로 단독응찰이라면  어떤 기분일까....?
아무리 생각해도 난 호방하게 웃으며 미련을 날려 버릴 수 있을 것 같지가 않았다.
나에게 1억 5천만원은 엿 값이 아니라 엿 공장 하나를 차릴만한 큰돈인 것이다....!
부인할 수 없는 하수인 나는 적어도 한 달은 속 앓이를 할 것 같았다.

전전반측!!
잠자리에 누워도 이리 뒤 척, 저리 뒤 척 일뿐 쉬 잠들지 못했다.

이렇게 마음을 못 잡고 사흘이 흘러갔다.
입찰일은 다음날인데 아직까지 최종 응찰가를 정하지 못했다.

나는 딜레마에 빠져 있었다.
낙찰을 받아야 하는 것과 차순위와의 차이가 근소해야 하는 것!
그러나 내 능력의 한계 내에서는 양자는 결코 섞일 수 없는, 조율이 불가능한 물과 기름이었다.
낙찰을 받으려면 수익에 대한 욕심을 버리고 낙찰가를 올려붙여야 맞을 것인데 자꾸 단독응찰이면 어쩌나 하는 불안감이 발목을 잡는다.

후배의 지적대로라면 난 지금 전형적인 하수들의 고민을 하고 있는 것이다.
일단 며칠 전 후배의 말들을 빠짐없이 정리해 본다.
'예상 경쟁자는 3명 정도에 한명은 8억 초반대를 쓸 실수요자! 나머지는 경매경험 풍부한 고수! 고수들도 1억 이상은 쓰되 난이도가 있어 2억 이상 쓰기는 쉽지 않을 거라는 판단들!'
후배의 분석과정이 설득력 있었던 만큼 신뢰가 가는 추리였다.
좋다! 그렇다면 일단은 8억 5천만원은 넘겨보자!
고민 끝에 정해진 응찰가는 878,930,000원 이었다.

응찰가를 정해놓고 잠자리에 들긴 했지만 평소처럼 쉽사리 잠이 오지는 않는다.

가만히 수익률을 따져본다.
'낙찰가의 80%를 대출받으면 실제 필요한 돈은 세금포함해서 2억원 정도에 한달 만에 14억원 정도에 급매로 팔면 그 차익이 5억원 남짓!  세금 50%를 공제하고 나면......수익이  2억5천만원...!
허억! 입이 다물어 지지 않는다. 연수익률이 1000%를 넘어선다....!
수익률 계산 후 응찰가를 상향 조정했다. 9억을 넘겨보기로 했다.
끝자리는 평소 습관대로 8,400,000원를 붙이기로 했고 그래서 정해진 최종 응찰가는 908,400,000원이었다..!!
상계동 물건 낙찰 받을 당시와 응찰가의 구조가 비슷해 감이 좋았다.
더 이상 바꿀 일이 없기를 바라며 편안한 마음으로 잠자리에 들었다.
딸깍(형광등 불 끄는 소리.^^::)
(어둠....어둠,....)
잠깐 눈을 감았다 뜬것 같은데 벌써 아침이었다. 창가로 밀려드는 햇살이 눈부시다.
본능적으로 시계를 본다.
이런! 절망적인 탄식이 새어나왔다.


숨 막히는 긴장 속에서

9시였다!
밤늦도록 뒤척이다 새벽녘에야 겨우 잠들어 늦잠을 잔 것이다.
여기는 일산,  법정은 서울 서초동 중앙지법이었다....!
당장 해야 할 일들을 머릿속으로 정리해 본다.
은행에서 보증금을 수표 1장으로 끊고 곧바로 올림픽대로를 달려 중앙지법까지 최소 1시간 30분.....
 빠듯하다는 생각이 드는 것과 동시에 움직이기 시작했다.

부산부산.....우왕좌왕.....안절부절......!

서울 중앙지법 앞에 도착하여 무사히 차량을 주차한 뒤 시계를 보았다.
10시 30분!
중앙지법은 입찰마감시간이 11시 20분까지니 시간은 충분했다.
예전보다는 다소 한산해진 법정분위기.
경매붐도 그저 한 때 뿐일런가!
입찰표를 받아들고 심호흡을 한번 했다.
어제 정해놓은 응찰가가 908,400,000원! 
조금 더 올려 볼까, 잠깐 유혹이 있었지만 평소 원칙대로 하기로 했다.
경매장 분위기에 휩쓸려 응찰가를 조정하지 않는다!! 
금과옥조처럼 지켜져야 할 경매의 기본인 것이다.
입찰표를 작성하는데 괜스리 천원단위 끝자리가 신경이 쓰였다.
혹시 몰라 천원단위 기재 란에 살며시 1자를 그었다. 천원단위까지 신경써보긴 처음이었다.좋은 물건이라는 욕심에 신중을 기한다고 써넣은 것이었지만 나중에 얼굴 붉어지는 사건의 발단이 될 줄이야...!


입찰표를 넣고 기다린다. 당일은 두개의 경매계 사건이 병합되어 진행되었다.
내 건은 사건번호는 빨랐지만 앞선 경매계 사건이 모두 끝난 후 진행된다고 하니 1시간 이상은 여유가 있었다.
밖에서 커피한잔을 뽑아 마시고 있는데 누군가가 가볍게 어깨에 손을 짚는다.
돌아보니 후배변호사였다. 경매법정 바로 옆 건물인 행정법원에 사건이 있었는데 궁금해서 들렸단다.
'형! 응찰가 얼마 썼어요?'
정말로 많이 궁금한지 눈이 반짝인다. 하긴 궁금할 만도 할 것이다.
많은 고민을 함께 나눈 물건이니......
' 908,400.000원!!!'  끝자리에 1천원을 더 써 넣은 것은 말하지 않았다. ^^::
'와~ 잘 쓰셨네요. 저도 그쯤 쓰면 될 듯했는데, 감 좋은데요...!!'
후배의 칭찬에 벌써부터 뭔가 된 듯한 느낌이 들어 가슴이 벅차올랐다.
경매법정 밖에서 이런저런 이야기를 나누는 중에  여러 사람들에 둘러싸인 채 상기된 얼굴로 발걸음을 옮기는 사람들이 하나둘 보이기 시작했다.

오늘의 주인공인 낙찰자들이다! 주변사람들은 은행직원이나 대출 알선업에 종사하는 사람들일 터이고!
모르는 사람들이 보면 인기스타에게 사인을 받으려 팬들이 몰려드는 풍경과 흡사하다!
오늘만이라도 낙찰의 기쁨을 맘껏 누리시기를...!
조용한 미소로 축복을 빌어 주었다.
그만 들어가 보자는 후배의 말에 상념을 접고 법정 안으로 들어갔다.
사건번호를 보니 앞으로 3건 진행 후에 우리 건이다.
슬슬 심장박동이 빨라지기 시작하고 숨소리가 불규칙해진다.
개찰이 얼마 남지 않았음을 알리는 내 몸속 기관들의 신호다.
앞선 사건들의 응찰자가 많지 않아 금방 우리차례가 되었다.

집행관 앞에 놓인 서류 봉투는 3장!!
오호! 후배변호사랑 눈이 마주쳤다. 말이 없어도 내가 무슨 말을 하고 싶어 하는지 알 것이다.
'너 변호사 때려 치고 박수무당 개업해라...!'
후배가 씨익 웃는다. 알아 들었다는 듯......
일단 후배의 추리 첫머리가 맞았으니 나머지도 맞아주기를....
속으로 기도를 하는데 조용하고 침착한 집행관의 음성이 마이크를 통해 흘러 나왔다..
'사건번호 0000번호에 응찰하신 분 호명하겠습니다. 누구, 누구, 누구씨 앞으로 나오세요.'
사뭇 어깨가 떨리고 발걸음이 흔들린다.
아.. ! 나는 언제쯤 이런 상황에서도 초연할 수 있는 고수가  되려는가!'
입찰표를 유심히 보고 있는 집행관의 눈빛이 심상치 않다.
혹시 입찰표 작성할 때 실수라도 했나?
예전에 상가물건을 입찰했다가 서너 명의 경쟁자를 물리치고 낙찰은 받았는데 보증금액과 응찰금액을 바꿔 써서 무효 처리됐었던 기억이 악몽처럼 떠오른다.

심호흡을 하며 마음을 가라앉히는데 각자의 응찰가가 불려진다...
'000씨,  810,000,000원! 여자이름!  일단 한명은 제꼈다!
000씨, 9억 8백.........!  헉! 목소리가 작아 이름을 못들었다!
집행관이 여기까지 말하고는 조금 뜸을 들인다. 손바닥이 축축해 지고 입이 마짝 마른다.
어떤 고수가 백만원 단위까지 나랑 같게 쓴 것이다!
이런!! 내 끝자리는 고작 401,000원인데...
10,000원단위까지 신경 쓰지 않은 경솔함이 뼈에 사무치게 후회되는 순간이었다......!


부끄러운 낙찰


집행관이 응찰가를 부르다 말고 유심히 입찰표를 살핀다.
그러더니 재차 응찰자를 호명하며 응찰가를 읽어 내려간다.
'000씨..! 908,401,000원 ....!  이런! 다른 사람 아닌 내 응찰가였다!
응찰가 중간 중간에 0자가 2개나 박혀 있으니 빠르게 읽어 내려가기가 쉽지 않아 멈칫했던 것이었다.
귀 끝까지 새빨개지는 듯한 느낌이 들었다.. 끝자리 1000원은 괜히 붙여 가지고!
''당황하지 말자. 아직까지 사람들은 저 복잡하고 촌스런 응찰가가 내 꺼라는 것을 모른다!'
심호흡으로 마음을 추스리고 태연한 척 했다....^^::


자...이제 마지막 사람이 남았다...!
그런데 이번에도 집행관이 바로 응찰가를 읽어 내려가지 않고 주춤한다.
그러더니 만회라도 하듯 재빨리 ''000씨! .... 888,850,000원.....!! 해버린다.
내거 보다는 덜 복잡하지만 그래도 빠르게 읽기에는 역시 다소 어려운 응찰가였다...!
2000만원 차이였다!
최고가 매수인으로 내 이름이 호명되는 소리..!
법정 끝에 서 있는 후배의 짧은 환호성도 환청처럼 들은 듯했다!
한바탕 크게 웃으며 외치고 싶었다.

‘나 오늘 2000만원짜리 엿 사먹었다~! '

더 이상 2000만원에 대한 미련은 없었다!


그런데 들뜬 기쁨도 잠시.....
최고가매수인을 호명하고 낙찰가를 재차 불러 주면서 집행관이 또 심하게 버벅인다.
''9억 8백...(뜸을 들이다가...^^::)....4십만...(또 뜸......TT) .. 1000원을 쓰신 000씨를 최고가 매수인으로 호명합니다!''
마지막에 1000원! 이라는 소리가 유난히 크게 귓전을 때렸다.
영수증 받으러 앞으로 나서기가 참으로 민망한 순간이었다.^^::
흑~ 내가 앞으로 다시는 천원단위 끝자리를 붙이나 봐라....TT

입찰봉투대신 영수증을 교부받고 나오면서 후배와 눈이 마주쳤다. 누가 먼저라고 할 것도 없이 각자 주먹을 들어  이마 언저리에서 살짝 맞부딪혔다!
뭔가를 이루어 냈을 때 하는 우리들만의 하이파이브였다....!

에필로그

이건 물건을 낙찰받자 마자 전세물건 소개해 줬던 공인 중개사를 찾아 갔습니다.
낙찰 받은 사실을 알리며 급매로 팔아 달라고 하자 놀라는 눈치입니다. 자기도 이건 물건이 경매로 나온지는 알고 있었는데 자금여력이 없어 못 들어 갔다고 합니다.
그러면서 한마디 합니다.
'야, 대단하시네. 거기 전입신고한 사람하고 주인하고 부부인 것은 어떻게 알아냈데요?'
대답대신 조용히 미소를  지어 주었습니다.
그 집 경비아저씨의 털털한 눈웃음이 떠오름과 동시에 그간의 일들이 주마등처럼 스쳐 지나갑니다. ^^

공인중개사한테 급매로 팔아달라고 부탁하니까 얼마를 받고 싶냐고 오히려 되물어 봅니다.
'한 17억원 정도 받았으면 좋겠는데....힘들겠지요...급매로 15억원 정도 받아주세요.'
공인중개사의 표정에 별다른 변화는 없었지만 조심스러운 목소리로 권합니다.
'예전에 아파트 경기 좋을 때는 가능하겠는데 요즘은 원체 거래가 뜸해서....14억원 정도면 보름 안에 해결해 드릴 수 있을 것 같은데...15억원은 좀 부담되네요. 그리고 이 물건 당장 팔지 말고 한 1년만 갖고 있어 보시지 그러세요. 내년에 정권 바뀌고 경기 좋아지면 20억원까지도 갈수 있을 것 같은데...... 내년 상반기 쯤 옆 삼성타운 입주가 끝나면 수요도 몰릴 것 같구요.'

자신의 영업보다는 고객의 이익을 최우선시하는 중개사가 마음에 들어 14억원에 급매로 팔아달라고 부탁하고는 돌아왔습니다.
일주일 후 무사히 낙찰허가 결정이 났고 현재 경락잔금대출을 신청 중입니다.
아파트 담보대출 규제가 강화되었다고는 해도 금융계에서 강남불패의 신화는 여전히 이어지고 있습니다. 평소 친분 있는 금융 알선사에게 문의해보니 낙찰가의 90%대출에 이율 또한 6.5%~7%까지 가능하답니다....수익률이 조금 더 올라갈 것 같습니다. ^^

아직 잔금도 안냈는데 벌써 공인중개사에게 연락이 왔습니다. 2명 정도가 집을 보기를 원한다고......
 월세문의도 있습니다. 보증금 1억원에 월 400만원에 들어오겠다고 합니다.
월세로 돌려 투하원금 회수하고 은행이자를 월세로 막으면서 한 1년 갖고 있어 볼까?
잠깐 흔들리긴 했지만 그냥 급매로 내놓고 시세차익만큼 재투자하기로 마음먹었습니다.
남편 사업이 망해 한참 어려울 때인 전입자에게는 섭섭지 않은 이사비를 지급할 생각입니다.

-----
Cheers,
June

Infamous Chinese pirates launch Ubuntu that looks just like Windows XP

Infamous Chinese pirates launch Ubuntu that looks just like Windows XP

From the Chinese pirate masters of the non-sea-faring variety comes ... Ylmf OS! Not happy with pirating Windows XP itself, these creative Chinese have gone one step further and hacked Ubuntu to look exactly like Windows XP. Why have they moved to Ubuntu? Because their previous release -- a pirate version of Windows XP itself -- is being cracked down on by Microsoft.

(blah, blah...)

Source:
http://www.downloadsquad.com/2009/12/26/chinese-copy-cat-pirates-launch-ubuntu-that-looks-just-like-windows-xp/

Download:
http://www.ylmf.org/download.html


Screenshots and full article
Source: http://www.cnbeta.com/articles/100827.htm

山寨XP也疯狂 雨林木风Ylmf OS多图赏


hjj0529发布于 2009-12-25 19:50:33|84523 次阅读 字体: 打印预览
Linux 雨林木风官方团队在平安夜发布了“Ylmf OS”开源操作系统,引人关注的是,其界面与Windows XP非常类似。其官方介绍称:Ylmf OS不仅系统界面默认为精仿的XP主题,系统还集成OpenOffice办公套装、浏 览器Firefox、QQ即时通讯、Linux下的在线电影平台等大量能满足国内用户日常使用的必备软件,用户在Windows平台下的基本应用都可以在 这个操作系统上良好运行,同样具有很好的用户体验。

到目前为止,Ylmf OS是最接近Windows XP的开源操作系统,连操作习惯都没什么区别。
至于这款“山寨版的XP”究竟怎么样呢?我们一齐来看看吧。
山寨XP也疯狂 雨林木风Ylmf OS多图赏
光盘自引导启动
山寨XP也疯狂 雨林木风Ylmf OS多图赏
LiveCD模式


山寨XP也疯狂 雨林木风Ylmf OS多图赏
独立安装开始
山寨XP也疯狂 雨林木风Ylmf OS多图赏
选择安装磁盘
山寨XP也疯狂 雨林木风Ylmf OS多图赏
格式化分区
山寨XP也疯狂 雨林木风Ylmf OS多图赏
复制系统文件
山寨XP也疯狂 雨林木风Ylmf OS多图赏
继续ing
山寨XP也疯狂 雨林木风Ylmf OS多图赏
速度还可以,25分钟安装完毕

山寨XP也疯狂 雨林木风Ylmf OS多图赏
启动界面
山寨XP也疯狂 雨林木风Ylmf OS多图赏
登录界面
山寨XP也疯狂 雨林木风Ylmf OS多图赏
进入桌面
山寨XP也疯狂 雨林木风Ylmf OS多图赏
文件浏览器
山寨XP也疯狂 雨林木风Ylmf OS多图赏
多媒体播放器
山寨XP也疯狂 雨林木风Ylmf OS多图赏
OpenOffice
山寨XP也疯狂 雨林木风Ylmf OS多图赏
山寨XP也疯狂 雨林木风Ylmf OS多图赏
文档编辑工具Writer

山寨XP也疯狂 雨林木风Ylmf OS多图赏
幻灯片制作Impress
山寨XP也疯狂 雨林木风Ylmf OS多图赏
电子表格Calc
山寨XP也疯狂 雨林木风Ylmf OS多图赏
Firefox浏览器
山寨XP也疯狂 雨林木风Ylmf OS多图赏
控制终端



-----
Great! look so good terminal in last image. i think that so cute!

Cheers,
June

Sun Studio C, C++ and Fortran Compilers and Tools

:: Sun Studio software provides compilers and tools for C, C++, and Fortran development on Solaris, OpenSolaris, and Linux platforms, with support of multicore x86- and SPARC-based systems.
Source: http://developers.sun.com/sunstudio/index.jsp


::Sun Studio software in the OpenSolaris Repositories
Source: http://developers.sun.com/sunstudio/downloads/opensolaris/index.jsp


:: The OpenSolaris Operating System offers unique features designed to help you build and deploy high-performance application services, starting with the Image Packaging System (IPS), continuing to the latest enhancements to the award-winning ZFS and featuring integrated virtualizaton options that span OS, network and storage -- and that's just the beginning. OpenSolaris gives you next generation Solaris technologies coupled with the best in open source software and a vibrant development community. Download OpenSolaris 2009.06 now!
Source: http://www.opensolaris.com/get/index.jsp


:: Sun Studio Features
Source: http://developers.sun.com/sunstudio/features/index.jsp

Sun Studio Software - Advanced Tooling for C, C++ and Fortran Developers

Data Sheet: Sun Studio 12 Update 1 (PDF)
Sun Studio 12 Update 1 is the latest production release of Sun Studio software. Available on Solaris, OpenSolaris and the latest Linux distributions, this release contains new features and enhancements that simplify multicore development, increase application runtime performance and enhance developer productivity. Feature Highlights:
  • Optimizing C, C++ and Fortran compilers: The Sun Studio compilers generate improved binary application performance on Intel x86, AMD x86, UltraSPARC and SPARC64-based systems. With dozens of recent industry-based benchmarks, Sun Studio compilers take full advantage of the latest multicore architectures.
    » Sun Benchmarks
  • Full OpenMP 3.0 compiler, debugger and tools support: The OpenMP 3.0 specification contains new features to ease multicore development. Take a more general approach to multithreaded programming by using tasks to support complex and dynamic control flows.
    » Screencast
  • DLight: System profiling tools allow you to explore your system, understand how it works and track down performance problems across many software layers. DLight is a new tool which unifies application profiling and system profiling using DTrace technology on Solaris platforms.
    » Screencast    » Tutorial
  • dbxTool: The dbx Debugger is fully integrated into the IDE and available via command line. Sun Studio 12 Update 1 now features dbxtool, a stand-alone debugging solution with a user-friendly interface. Quickly and easily debug an executable, core file or attach to a running process.
    » Screencast
  • Performance analysis of MPI applications: The Performance Analyzer includes an MPI Timeline, MPI charts, zooming and filtering capabilities and with Sun HPC ClusterTools, clock-profiling MPI experiments show 2 new metrics: MPI Work Time and MPI Wait Time.
    » Screencast   » Tutorial
  • Updated Sun Studio IDE: Sun Studio features a next-generation IDE based on NetBeans 6.5.1 software, specifically geared for C/C++ developers. New features include improved code completion, error highlighting, semantic highlighting, call graph, memory window, packaging of application as tar files, zip files, SVR4 packages, RPMs, or Debian packages, and much more.
    » Tutorial
  • Sun Performance Library: The Sun Performance Library is a set of optimized, high-speed mathematical subroutines for solving linear algebra and other numerically intensive problems. Increase application performance with enhanced and newly added standard routines including, BLAS, LAPACK, FFTPACK, SuperLU, Sparse Solvers, and ScaLAPACK.
Documentation:
Complete Sun Studio documentation for current and previous releases includes release notes and reference manuals, on docs.sun.com, man pages, tutorials, and ReadMes for each major software component, on this web site. See also the technical articles that discuss and demonstrate the use of many important features of the compilers and tools. See the Sun Studio 12 Update 1 Documentation index page.


-----

Great package!
I've been downloaded already... lol
but not installed... -_-;;;


Cheers,
June

토요일, 1월 02, 2010

일기 (2010.01.01)

Happy New Year!

January 1st, 2010,  i'm 31 now. ㅠ.ㅠ
i hopes will become happiness and peace in my family this year.
and everything will be okay.

i hope that there will be happiness and peace in your home.

-----
Cheers,
June