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 쪽이 접속속도가 빨랐다.
