An object
is a data structure that represents a system resource, such as a file,
thread, or graphic image. An application cannot directly access object
data or the system resource that an object represents. Instead, an
application must obtain an object handle, which it can use to examine or modify the system resource.
Having a low ID does not mean that no upload or download is possible but has several disadvantages:
1) No IP is known of the machine eMule is running on therefore all requests like queue or connection requests to this client have to be routed over the server, the low ID
client is connected to. This routing causes considerable amount of CPU
load on the server thus reducing the maximum number of users the server
can cope with. Lugdunum’s servers limit the number low ID users or even ban them at all.
2) Two clients on low ID cannot connect to each other, as it is not possible to route messages over two different servers. This will lead to less sources for the downloads.
3) On busy servers it may well happen that the messages get lost and eMule misses important information about queue progression or download requests. This may lead to fewer credits and worse downloads.
I would like to access U-Boot's environment variables from my Linux application.
Is this possible?
Answer:
Yes, you can. The environment variables must be stored in flash memory,
and your Linux kernel must support flash access through the MTD layer.
In the U-Boot source tree you can find the environment tools in the directory
tools/env, which can be built with command:
make env
For building against older versions of the MTD headers (meaning before v2.6.8-rc1) it
is required to pass the argument "MTD_VERSION=old" to make:
make MTD_VERSION=old env
The resulting binary is called fw_printenv, but actually includes support for setting
environment variables too. To achieve this, the binary behaves according to the
name it is invoked as, so you will have to create a link called fw_setenv to fw_printenv.
These tools work exactly like the U-Boot commands printenv resp. setenv
You can either build these tools with a fixed configuration selected at compile time,
or you can configure the tools using the /etc/fw_env.config configuration file
in your target root filesystem.
아직 원하는 것을 실행하기에는 내공이 부족한지라 또 다시 좌절중 OTL
아무튼 최종 목표는 cygwin에 kscope를 구동시키는 것이다.
(kscope는 source insight와 유사한 KDE 프로그램이며, KDE는 QT 기반이며, kscope는 cscope의 GUI Frontend이다.)
Step 1. 다음 눌러도 되는 부분은 패스~하고
이 부분에서는 한국에서 한다면 ftp://ftp.daum.net 으로 설정한다. 엄청난 속도를 자랑한다 -.-b
Step 2. Cygwin/x를 위해서는 별도의 인스톨러가 있는 것이 아니라, 설치시에 원하는 패키지를 추가로 설치해주면 된다.
일단 X-start-menu-icons를 선택하면 자동으로 시작메뉴에 추가해줄 뿐만 아니라, 필수 패키지가 자동으로 선택된다.
필수 패키지 : xorg-server, xinit
Step 3. Cygwin 마지막 단계로, Icon을 생성하는 것에 대한 물음이다.
Step 4. 아무튼 설치가 끝나면(물론 마지막에 Add icon to Start Menu를 해줘야 할 듯?) 이렇게 추가가 된다.
XWin Server를 구동하면, 처음실행시에는 보안경고가 뜨므로, 방화벽에 예외로 추가 하도록 하면된다.
Step 5. 시스템 트레이에 가동중인 XWin Server의 아이콘
Step 6. 위의 메뉴에서 xterm을 구동하고 별도로 설치한 xclock 프로그램을 xterm에서 구동한 모습
Step 7. 별도로 설치한 gvim을 xterm에서 구동한 모습
이녀석을 구동하기 위해서는 fontconfig 라는 패키지를 별도로 설치해주어야 한다.
Cygwin is a Linux-like environment for Windows.
It consists of two parts:
A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing
substantial Linux API functionality.
A collection of tools which provide Linux look and feel.
The Cygwin DLL currently works with all recent, commercially released
x86 32 bit and 64 bit versions of Windows, with the exception of Windows
CE.
Note that the official support for Windows 95, Windows 98, and Windows Me
will be discontinued with the
next major version (1.7.0) of Cygwin, which is
in beta testing right now.
What Isn't Cygwin?
Cygwin is not a way to run native linux apps on Windows. You have
to rebuild your application from source if you want it to run on Windows.
Cygwin is not a way to magically make native Windows apps aware of UNIX ®
functionality, like signals, ptys, etc. Again, you need to build your apps from source
if you want to take advantage of Cygwin functionality.
일단 찾아 보니 cygwin에 이식된 QT도 있으니,
한번 소스를 받아서 cygwin + cygwin/x + KDE-cygwin + kscope 를 해봐야겠다.
일단 둘다 동일한 VNC이긴하다.
tightVNC는 realVNC 기반의 GPL 라이센스를 따르고 있고
realVNC는 free버전이 존재한다.
오늘 잠시 VNC 서버에 tightVNC로 접속해본 느낌은, real VNC free 버전에 비해서 화면 갱신이 매우 빠르다는 점이다.
자세한 내용은 tightVNC 서버를 설치 후 테스트를 해봐야 알 수 있을것 같다.
일단 tightVNC는 GPL 라이센스이므로 모든 기능을 100% 지원/공개 하기 때문에
real VNC 공개버전과 비교를 하자면, 파일 전송이 가능하다는 장점이 있다.
TightVNC Features
Here is a brief list of TightVNC features absent in the standard VNC.
File transfers in versions for Windows. You can updload files from your local
machine to the TightVNC Server, and download files from the server to your computer.
Support for video mirror driver (Windows 2000 and above). TightVNC Server can use
DFMirage mirror driver to detect screen updates and grab pixel data in a very efficient
way, saving processor cycles for other applications.
Scaling of the remote desktop (viewer for Windows and Java viewer). You can view
the remote desktop in whole on a screen of smaller size, or you can zoom in the picture to
see the remote screen in more details.
Efficient "Tight" encoding with optional JPEG compression. New Tight
encoding is optimized for slow and medium-speed connections and thus generates much less
traffic as compared to traditional VNC encodings. Unlike other encodings, Tight encoding is
configurable via compression levels and JPEG image quality setting.
Enhanced Web browser access. TightVNC includes a greatly improved Java viewer
with full support for Tight encoding, 24-bit color mode, and more. The Java viewer applet
can be accessed via built-in HTTP server like in the standard VNC.
Support for two passwords, full-control and read-only. The server allows or
disallows remote keyboard and mouse events depending on which password was used for
authentication.
Automatic SSH tunneling on Unix. The Unix version of TightVNC Viewer can
tunnel connections via SSH automatically using local SSH/OpenSSH client installation.
And more. TightVNC includes a number of other improvements, performance
optimizations and bugfixes, see change logs for more
information.
50% 축소해서 본 tightVNC의 remote화면
간추린요약 - tightVNC가 나은 점
1. tightVNC가 realVNC에 비해서 접속속도 및 화면갱신속도가 상당히 빠르다
(테스트 조건 realVNC 서버/윈도우 realVNC 서버)
2. 화면 scaling을 지원한다
3. 파일 전송을 지원한다고 한다(VNC free edition 대비, 테스트 해보지 못했음)
리눅스 서버로의 접속은 실질적인 화면갱신속도 차이는 거의 없지만, tightVNC 쪽이 접속속도가 빨랐다.
TortoiseSVN에는 Diff / Merge 툴이 내장되어 있다.
Diff/Merge 프로그램은 외관상으로는 WinMerge와 유사하고, 동일 프로젝트를 변형해서 사용하는게 아닐까라는 생각이 든다.
아무튼 이러한 개인적인 추측은 패스하고~ 장점과 단점을 말하자면 다음과 같다.
WinMerge
TortoiseMerge
Syntax Highlight
지원
미지원
UTF-8 지원
지원
미지원
네비게이션 부분 확대
미지원
지원
일반적인 소스를 다루는 경우에는 UTF-8 을 굳이 지원해야 할 필요는 없지만,
현재 다국어지원 작업을 하는데 UTF-8을 지원하지 않는 다면 아래와 같이 선택할 경우에 글씨가 깨지는 문제가 발생한다.
TortoiseMerge - 좌측의 네비게이션 부분확대가 매력적이다. (확대해서 비교해 보세요!!)
색상이 있는 줄이 차이점 부분이 확대된 것이고, 아래의 흐릿한 선들이 원래 크기의 차이점 부분표시이다.
WinMerge - 네비게이션을 제외하면 전반적으로 WinMerge가 낫다
구버전의 TortoiseCVS의 경우에는, 기본 비교/병합 프로그램이 없어, 무조건 하나만 입력이 가능한 단점이 있었지만,
TortoiseSVN은 내장 비교/병합 프로그램이 있어서, 사용하지 않더라도 외부 프로그램의 링크는 사라지지 않아 좋다.
남아있는 External Link (화면 배색문제로, 일반적인 pc에서는 회색으로 보임)
또 다른 TortoiseSVN의 내장 비교툴로 IDiff가 있다(Image Diff)
말그대로 이미지를 비교 하는 것인데, I가 굴림체인지라 Diff밖에 눈에 안들어 온다.
위의 이미지가 이미지 비교 프로그램, 아래는 소스 비교 프로그램
이 포스트에 들어간 이미지 a.png와 c.png를 비교한 화면이다
비교 옵션 중 겹쳐보기로 본 비교화면 (Overlay Mode)
비교 옵션 중 혼합겹쳐보기로 본 비교화면 (Overlay Mode + Alpha Blend)
