반응형

출처 

https://mariadb.com/kb/en/mariadb/memory-storage-engine/



MEMORY 저장 엔진

MEMORY Storage Engine


(이전엔 HEAP으로 알려진) MEMORY 저장 엔진의 내용은 디스크보다 메모리에 보관됩니다.


Contents of the MEMORY storage engine (previously known as HEAP) are stored in memory rather than on disk.


다른 테이블로부터 데이터의 읽기전용 캐쉬 즉 임시적인 작업 영역에서 사용하는 데 최고입니다.


It is best-used for read-only caches of data from other tables, or for temporary work areas.


데이터가 메모리에 보관되기 때문에 정전이나 하드웨어 고장에 매우 취약하며 영원히 데이터를 보관하는 데는 적절하지 않습니다. 사실, 서버가 재시작 하면 MEMORY 테이블은 (정의 파일이 디스크에 저장되기 때문에) 재생성 되지만 그 내용은 비어있을 것입니다. --init-file 서버 시작(startup) 옵션을 사용하여 쿼리로 원하는 내용을 다시 채울 수 있습니다.


Since the data is stored in memory, it is highly vulnerable to power outages or hardware failure, and is unsuitable for permanent data storage. In fact, after a server restart, MEMORY tables will be recreated (because the definition file is stored on disk), but they will be empty. It is possible to re-populate them with a query using the --init-file server startup option.


VARCHAR 같은 변수-길이 타입은 MEMORY 테이블에서 사용될 수 있습니다. BLOB 또는 TEXT 열(column)은 MEMORY 테이블에서 지원되지 않습니다.


 Variable-length types like VARCHAR can be used in MEMORY tables. BLOB or TEXT columns are not supported for MEMORY tables.


MEMORY 테이블의 최대 총 용량은 max_heap_table_size 시스템 서버 변수를 넘어설 수 없습니다. 테이블이 만들어질 때 이 값은 그 테이블에 적용하며, 서버가 재시작될 때 이 값은 현재 있는 테이블에 적용합니다. 이 값을 바꾸는 것은 현재 있는 테이블에는 효과가 없습니다. 하지만 ALTER TABLE ... ENGINE=MEMORY 문장의 실행은 그 테이블의 max_heap_table_size의 현재 값을 적용합니다. 또한 테이블을 만들기 전에 max_heap_table_size의 세션 값을 변경하는 것이 가능합니다.


 The maximum total size of MEMORY tables cannot exceed the max_heap_table_size system server variable. When a table is created this value applies to that table, and when the server is restarted this value applies to existing tables. Changing this value has no effect on existing tables. However, executing a ALTER TABLE ... ENGINE=MEMORY statement applies the current value ofmax_heap_table_size to the table. Also, it is possible to change the session value of max_heap_table_size before creating a table, to make sure that tables created by other sessions are not affected.


MAX_ROWS 테이블 옵션은 당신이 테이블에 저장할 행수에 관해 힌트를 제공합니다. 이 값은 초과할 수 없는 한계는 없지만, max_heap_table_size를 넘어설 수 없습니다. 저장 엔진은 테이블에 할당된 최대 메모리를 계산하는 데 max_heap_table_size와 MAX_ROWS를 사용합니다.


 The MAX_ROWS table option provides a hint about the number of rows you plan to store in them. This is not a hard limit that cannot be exceeded, and does not allow to exceed max_heap_table_size. The storage engine uses max_heap_table_size and MAX_ROWS to calculate the maximum memory that could be allocated for the table.


행이 삭제되었을 때 그 공간은 자동으로 해제되지 않습니다. 테이블을 없애지(drop) 않고 공간을 해제하는 유일한 방법은 ALTER TABLE tbl_name ENGINE = MEMORY 를 사용하는 것입니다. TRUNCATE TABLE도 메모리를 해제합니다.


 When rows are deleted, space is not automatically freed. The only way to free space without dropping the table is usingALTER TABLE tbl_name ENGINE = MEMORY

TRUNCATE TABLE frees the memory too.


인덱스 타입

Index type


MEMORY 저장 엔진은 B-tree 또는 Hash 인덱스를 허용합니다. 해시는 MEMORY에 대한 기본 타입 입니다. 보관 엔진 인덱스 타입을 보시면 더 많은 성질들을 확인할 수 있습니다.


The MEMORY storage engine permits indexes to be either B-tree or Hash. Hash is the default type for MEMORY. See Storage Engine index types for more on their characteristics.


MEMORY 테이블은 64개의 인덱스까지, 각 인덱스당 16개의 열(column)과 최대 키의 길이는 3072바이트까지 가질 수 있습니다.


A MEMORY table can have up to 64 indexes, 16 columns for each index and a maximum key length of 3072 bytes.

추가 보기

See also

 

 


예시

Example

다음 예시는 위에서 묘사된 주어진 최대 크기로 MEMORY 테이블을 만드는 방법을 보여줍니다.

The following example shows how to create a MEMORY table with a given maximum size, as described above.


반응형

'번역' 카테고리의 다른 글

테스트 주도 개발  (0) 2016.01.22
Computer virus  (0) 2009.10.07
악성코드  (0) 2009.10.07
BHO  (0) 2009.10.07
행성의 정의  (0) 2009.08.03
반응형

테스트 주도 개발
Test-driven development
 테스트 주도 개발(TDD)은 매우 짧은 개발 사이클에 의존하는 소프트웨어 개발 프로세스입니다. 첫째로 개발자는 새로운 함수나 원하는 향상을 정의하면서 1. (처음에 실패할) 자동화된 테스트 케이스를 작성하고, 2. 그 테스트를 통과할 최소의 코드를 제작하며, 마지막으로 3. 받아들일 수 있는 표준으로 새로운 코드를 리팩토링 합니다. 이 기술을 개발해 왔고 재발견한 Kent Beck은 TDD가 간단한 설계와 자신감을 북돋게 한다고 2003년에 주장하였습니다.
 Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered'[1] the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.[2]
 테스트 주도 개발은 1999년에 시작한 XP의 테스트 우선 개발과 관련 있지만, 최근들어 자신의 권리에 더 관심이 있는 듯 합니다.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,[3] but more recently has created more general interest in its own right.[4]
 프로그래머들은 더 오래된 기술로 개발된 레거시 코드를 디버깅하고 향상시키기 위해 이 컨셉을 적용합니다.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.
테스트 주도 개발 주기
Test-driven development cycle
  1. 테스트를 추가하기
  1. Add a Test
테스트 주도 개발에서 각각 새로운 특징은 테스트를 작성하는 것으로 시작한다는 점입니다. 테스트를 작성하기 위해 개발자는 분명하게 업무 상세와 요구사항을 이해하여야 합니다. 개발자는 이를 요구사항과 예외 조건을 만족하기 위해 use cases와 user story를 통해 달성할 수 있고 소프트웨어 환경에 적절한 테스팅 프레임워크에서 테스트를 작성할 수 있습니다. 이미 있는 테스트의 수정된 버전이 될 수도 있습니다. 이는 테스트 주도 개발과 코드가 쓰여진 후 유닛테스트와 구별되는 특징입니다. 코드를 작성하기 전에 개발자로 하여금 요구사항에 집중하도록 합니다. 미묘하지만 중요한 차이입니다.
In test-driven development, each new feature begins with writing a test. To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. It could be a modified version of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.

     2. 모든 테스트를 실행하고 실패한 것을 알아보기

     2.  Run all tests and see if the new one fails
이는 어떤 새로운 코드 요구하는 거 없이 새로운 테스트가 실수 없이 통과하고 요구된 특징이 이미 존재하지 않는지에 대해 테스트 자동화 도구(자동화된 테스트 프레임워크)가 정확히 작동하는지 검증합니다. 이 단계는 그 테스트 자체를 검사합니다. 반대로 새로운 테스트가 항상 통과할 가능성을 정하기 때문에 유용합니다. 새로운 테스트는 기대한 이유에 대해 실패할 수 있습니다. 이 단계는 정확한 제약조건에서 유닛테스트가 테스트되고 있는지 의도된 경우에서만 통과하는지 개발자에게 자신감을 심어줄 수 있도록 합니다.
This validates that the test harness is working correctly, that the new test does not mistakenly pass without requiring any new code, and that the required feature does not already exist. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This step increases the developer's confidence that the unit test is testing the correct constraint, and passes only in intended cases.

     3. 일부 코드를 작성하기

     3.  Write some code
이 단계는 테스트를 통과하는데 몇몇 코드를 작성합니다. 이 단계에서 쓰여진 새로운 코드는 완벽하지 않은데 예를 들어 우아하지 않는 방법으로 테스트를 통과합니다. 이는 받아들일만 한데 5단계에서 코드의 질이 높아질 것이기 때문입니다. 요점은 이 단계의 목적은 테스트를 통과하는 것입니다. 더이상 (테스트를 하지 않는) 기능은 예측되지 않으며 어떤 단계에서도 '허용되지' 않을 것입니다.
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect and may, for example, pass the test in an inelegant way. That is acceptable because it will be improved and honed in Step 5.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted nor 'allowed for' at any stage.

     4. 테스트 실행하기

     4. Run tests
모든 테스트 케이스가 통과하였다면 새로운 코드는 테스트 요구사항을 만족하며 현재 존재하는 특징에서 지위를 낮추거나 멈출 필요가 없이 프로그래머는 자신감을 가질 수 있습니다. 그렇지 않으면 새로운 코드는 통과할 때까지 수정되어야 합니다.
If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.

     5. 코드를 리팩토링하기

     5. Refactor code
증가하는 코드는 테스트 주도 개발 동안에 정기적으로 정리되어야 합니다. 새로운 코드는 더 논리적으로 테스트에 통과되기에 편리하도록 바뀌어야 합니다. 중복은 제거되어야 합니다. 부가 기능이 추가될 때 객체, 클래스, 모듈, 변수와 메소드 이름은 현재 목적과 사용을 분명히 표현해야 합니다. 특징이 추가됨으로서 메소드의 body는 더 길어지며 다른 객체들도 더 커질 것입니다. 소프트웨어 라이프사이클에서 나중에 가치가 있기 위한 가독성 및 유지보수를 향상시키기 위해 주의깊게 더 커진 body 부분을 명명하고 코드를 쪼개면 이득을 볼 수 있습니다. 상속 관계는 더욱 논리적으로 정리되게 도울 것이며 디자인 패턴으로 알려진 방법으로 이득을 볼 수 있습니다. 깔끔한 코드를 작성하고 리팩토링하는 상세하고 일반적인 가이드라인이 있습니다. 각 리팩토링 구간동안 테스트 케이스들을 계속해서 재실행함으로서 개발자는 현재 기능을 수정하기 않는 프로세스를 만들 수 있습니다.
The growing code base must be cleaned up regularly during test-driven development. New code can be moved from where it was convenient for passing a test to where it more logically belongs. Duplication must be removed. Object, class, module, variable and method names should clearly represent their current purpose and use, as extra functionality is added. As features are added, method bodies can get longer and other objects larger. They benefit from being split and their parts carefully named to improve readability and maintainability, which will be increasingly valuable later in the software lifecycle. Inheritance hierarchies may be rearranged to be more logical and helpful, and perhaps to benefit from recognised design patterns. There are specific and general guidelines for refactoring and for creating clean code.[6][7] By continually re-running the test cases throughout each refactoring phase, the developer can be confident that process is not altering any existing functionality.
소프트웨어 디자인에서 중복을 제거하는 개념은 중요한 요소입니다. 그러나 이 경우 테스트 코드와 운영 코드 사이에 중복 제거를 적용할 수도 있습니다. 
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to the removal of any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in Step 3.
반복
Repeat
새로운 테스트를 시작하고 사이클은 다음 기능으로 반복됩니다. 각 단계의 크기는 각 테스트 사이에 1~10번정도 교정할 정도로 항상 작아야 합니다. 새로운 코드가 새로운 테스트를 갑자기 만족하지 않는다거나 다른 테스트가 예상치 못하게 실패한다면 프로그래머는 이 작업을 undo하거나 과도한 디버깅보다는 우선 이전 소스로 복귀해야 합니다. 계속된 통합은 되돌릴 수 있는 체크포인트를 제공하는 데 도움을 줍니다. 외부 라이브러리를 사용할 때 단기 그 라이브러리 자체를 테스트 하기 위한 코드 추가를 하지 않도록 하는 게 중요한데, 그렇지 않으면 개발 중인 모든 소프트웨어의 요구를 제공하기 위해 충분하지 못한 특징이나 라이브러리에 이유가 있다고 판단할 수 있기 때문입다.
Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging. Continuous integration helps by providing revertible checkpoints. When using external libraries it is important not to make increments that are so small as to be effectively merely testing the library itself,[4] unless there is some reason to believe that the library is buggy or is not sufficiently feature-complete to serve all the needs of the software under development.


반응형

'번역' 카테고리의 다른 글

MEMORY Storage Engine  (0) 2016.11.04
Computer virus  (0) 2009.10.07
악성코드  (0) 2009.10.07
BHO  (0) 2009.10.07
행성의 정의  (0) 2009.08.03
반응형

Computer virus

컴퓨터 바이러스

A computer worm is a computer program that can copy itself and infect a computer without permission or knowledge of the user.

컴퓨터 바이러스는 스스로 복사가 가능하고 사용자의 인지나 허락 없이 컴퓨터를 감염시키는 컴퓨터 프로그램이다.

The term "virus" is also commonly used, albeit errorneously, to refer to many different types of malware programs.

용어 바이러스는 널리 쓰이며 다른 많은 종류의 악성(malware) 프로그램으로 잘못 쓰이기도 한다.

The original virus may modify the copies, or the copies may modify themselves, as occurs in a metamorphic virus.

원래 바이러스는 변이하는 바이러스에서 발생하는 것처럼 복사본을 수정할 수 있거나 복사본이 스스로를 수정할 수 있다.

A virus can only spread from one computer to another when its host is taken to the uninfected computer, for instance by a user sending it over a network on the Internet, or by carrying it on a removable medium such as a floppy disk, CD or USB drive.

바이러스는 오직 한 호스트 컴퓨터가 감염되지 않은 컴퓨터로 전송될 때 예를 들어 인터넷의 네트워크로 바이러스를 보내거나 플로피 디스크, CD, USB 드라이브 같은 제거할 수 있는 매체를 통해 바이러스를 전송할 때 한 컴퓨터에서 다른 곳으로 퍼질 수 있다.

Meanwhile viruses are sometimes confused with computer worms and Trojan horses.

반면 컴퓨터 바이러스는 컴퓨터 웜이나 트로이 목마와 혼동된다.

A worm can spread itself to other computers without needing to be transffered as part of a host.

웜은 호스트의 부분으로써 전송될 필요가 없이 다른 컴퓨터에게 전파된다.

and Trojan horse is a file that appears harmless.

그리고 트로이 목마는 해가 없을 거 같은 파일이다.

Both worms and Trojans will cause harm to computers when executed.

웜과 트로이 목마 둘 다 실행될 때 컴퓨터에게 해를 끼친다.

Most personal computers are now connected to the Internet and to local area networks, facilitating the spread of malicious code.

대부분 개인 컴퓨터는 악성코드가 전파될 수 있는 LAN이나 인터넷에 연결되어 있다.

Today's viruses may also take advantage of network services such as the World Wide Web, e-mail, Instant Messaging and file sharing systems to spread, blurring the line between viruses and worms.

오늘날 바이러스와 웜의 경계선이 모호해 지고 파일 공유 시스템과 인스턴트 메세징, 이메일, 월드와이드웹 같은 네트워크 서비스에서 이익을 취한다.

Furthermore, some sources use an alternative terminology in which a virus is any form of self-replicating malware.

게다가 몇 곳은 어떤 자가 복제를 하는 악성코드인 바이러스를 대체용어로 사용하기도 한다.

Some viruses are programmed to damage the computer by damaging programs, deleting files, or reformating the hard disk.

일부 바이러스는 하드디스크를 포맷하거나 파일을 지우거나 프로그램을 손상시킴으로서 컴퓨터에 피해를 주도록 프로그래밍 되어 있다.

Others are not designed to do any damage, but simply replicate themselves and perhaps make their presence known by presenting text, vidio, or audio messages.

다른 바이러스는 피해를 주도록 만들어지지 않았지만 스스로 간단히 복사되며 글자, 비디오, 오디오 메시지로 표현함으로서 존재를 알릴 것이다.

Even these benign viruses can create problems for the computer user.

이러한 종양같은 바이러스들은 컴퓨터 사용자들에게 문제를 야기한다.

They typically take up computer memory used by legitimate programs.

바이러스들은 일반적으로 합법적인 프로그램에 의해 사용되는 컴퓨터 메모리에 올려진다.

As a result, they often cause erratic behavior and can result in system crashes.

결국, 바이러스는 엉뚱한 행동이나 시스템 충돌을 야기한다.

In addition, many viruses are bug-ridden, and these bugs may lead to system crashes and data loss.

게다가 많은 바이러스들은 버그 투성이이고 이러한 버그들은 데이터 손실이나 시스템 충돌을 야기한다.

반응형

'번역' 카테고리의 다른 글

MEMORY Storage Engine  (0) 2016.11.04
테스트 주도 개발  (0) 2016.01.22
악성코드  (0) 2009.10.07
BHO  (0) 2009.10.07
행성의 정의  (0) 2009.08.03
반응형

출처 : http://en.wikipedia.org/wiki/Malware


Malware

악성코드

Malware, short for malicious software, is a software designed to infiltrate or damage a computer system without the owner's informed consent.

악성 소프트웨어, 줄여서 악성코드는 사용자의 알려진 동의 없이 컴퓨터 시스템에 피해를 주거나 침투하는 소프트웨어이다.

The expression is a general term used by computer professionals to mean a variety of forms of hostile, intrusive, or annoying software or program code.

다양한 형태로 악의적으로 컴퓨터 사용자에 침입하고 괴롭히는 소프트웨어나 프로그램 코드를 의미하는 컴퓨터 전문가에 의해 사용되는 일반적인 용어다.

Many normal computer users are however still unfamiliar with the term, and most never use it.

많은 일반 컴퓨터 사용자들은 그러나 이 용어에 익숙하지 않고 대부분 사용하지 않는다.

Instead, "computer virus" is incorrectly used in common parlance and even in the media to describe all kinds of malware, though not all malware are viruses.

대신 "컴퓨터 바이러스"는 일반 회담에서 잘못 사용되며 대중매체에서조차 모든 종류의 악성코드를 묘사하지만 모든 악성코드는 바이러스가 아니다.

Software is considered malware based on the perceived intent of the creator rather than any particular features.

소프트웨어는 악성코드를 특별한 특징보다 제작자의 인지된 의도를 바탕으로 고려된다.

Malware includes computer viruses, worms, trojan horse, most rootkits, spyware, dishonest adware, and other malicious and unwanted software.

악성코드는 컴퓨터 바이러스, 웜, 트로이 목마, 대부분의 루트킷, 스파이웨어, 정직하지 못한 애드웨어 그리고 다른 악성코드 및 원하지 않는 소프트웨어를 포함한다.

In law, malware is sometimes known as a computer contaminant, for instance in the legal codes of California, West Virginia, and several other American states.

법에서 악성코드는 컴퓨터 오염물질로 알려져 있는데 예를 들어 켈리포니아, 웨스트 버지니아, 그리고 몇 개 다른 주에서는 합법적인 코드이다.

Malware is not the same as defective software, that is, soft which has a legitimate purpose but contains harmful bugs.

악성코드는 다른 컴퓨터를 감염시키는 소프트웨어와 같지 않다. 즉, 합법적인 목적을 가지지만 해로운 버그를 포함하는 소프트웨어이다. 


단어공부

infiltrate 침투하다

1. to enter or make sb enter a place or an organization secretly, especially in order to get information that can be used against it

2. to pass slowly into sth

intrusive 침입의, 주제넘게 참견하는

too noticeable, direct, etc. in a way that is disturbing or annoying

parlance 회담

(formal) a particular way of using words or expressing yourself, for example one used by a particular group

contaminant 오염균

a substance that makes sth impure

반응형

'번역' 카테고리의 다른 글

MEMORY Storage Engine  (0) 2016.11.04
테스트 주도 개발  (0) 2016.01.22
Computer virus  (0) 2009.10.07
BHO  (0) 2009.10.07
행성의 정의  (0) 2009.08.03
반응형

출처 : http://en.wikipedia.org/wiki/Browser_Helper_Object


Browser Helper Object

브라우저 도우미 객체

From Wikipedia, the free encyclopedia


Add-on Manager from Windows XP SP2 Internet Explorer

Window XP SP2 인터넷 익스플로어의 Add-on Manager

A Browser Helper Object (BHO) is a DLL module designed as a plugin for Microsoft's Internet Explorer web browser to provide added functionality. 

브라우저 도우미 객체는 추가된 기능을 제공하기 위해 인터넷 익스플로어 웹 브라우저를 위한 플러그인으로서 제작된 DLL module이다.

BHOs were introduced in October 1997 with the release of version 4 of Internet Explorer. 

BHO는 인터넷 익스플로어 버젼 4를 발매한 1997년 10월에 소개되었다.

Most BHOs are loaded once by each new instance of Internet Explorer. 

대부분의 BHO는 인터넷 익스플로러의 새 인스턴스를 만들 때 로드된다.

However, in the case of the Windows Explorer, a new instance is launched for each window.

그러나, 윈도우 익스플로러의 경우, 새 인스턴스가 각 윈도우에 대해 호출된다.

Some modules enable the display of different file formats not ordinarily interpretable by the browser. 

일부 모듈은 브라우저에 의해 보편적으로 해석될 수 없든 다른 파일 포멧의 표시를 가능하게 한다.

The Adobe Acrobat plugin that allows Internet Explorer users to read PDF files within their browser is a BHO.

브라우저 내에서 PDF 파일을 읽도록 인터넷 익스플로러 사용자에게 허용하는 Adobe Acrobat plugin이 BHO다.


Other modules add toolbars to Internet Explorer, such as the Alexa Toolbar that provides a list of web sites related to the one you are currently browsing, or the Google Toolbar that adds a toolbar with a Google search box to the browser user interface.

다른 모듈은 인터넷 익스플로러에 추가되는 툴바이다. 당신이 현재 찾고 있는 사이트와 관련된 웹 사이트의 리스트를 제공하는 Alexa 툴바나 브라우저 사용자 인터페이스로 구글 검색 창과 함께 툴바를 추가하는 구글 툴바가 있다.


Concerns

우려사항

The BHO API exposes hooks that allow the BHO to access the Document Object Model (DOM) of the current page and to control navigation. 

BHO API는 현재 페이지의 DOM을 접근하고 네비게이션을 제어하도록 BHO에게 허용하는 후킹에 노출되어 있다.

Because BHOs have unrestricted access to the Internet Explorer event model, some forms of malware have also been created as BHOs. 

BHO는 인터넷 익스플로어 이벤트 모델에 제한되지 않은 접근을 하기 때문에 악성코드의 일부 형태는 BHO로만들어져 왔다.

For example, the Download.ject malware installs a BHO that would activate upon detecting a secure HTTP connection to a financial institution, record the user's keystrokes (intending to capture passwords) and transmit the information to a website used by Russian computer criminals. 

예를 들어 Download.ject 악성코드는 금융기관으로 안전한 HTTP접속을 탐지하는데 활성화되고 (비밀번호를 얻기 위한) 사용자의 입력된 키를 기록하며 러시아 컴퓨터 범죄인들에 의해 사용되는 웹사이트로 정보를 전송하는 BHO를 설치한다.

Other BHOs such as the MyWay Searchbar track users' browsing patterns and pass the information they record to third parties.

MyWay Searchbar처럼 다른 BHO들은 사용자들의 웹서핑 패턴을 추적하고 그들이 기록한 정보를 3자에게 전달한다.

Many BHOs introduce visible changes to a browser's interface, such as installing toolbars in Internet Explorer and the like, but others run without any change to the interface.

많은 BHO들은 인터넷 익스플로어에 툴바를 설치하는 것처럼 브라우저의 인터페이스를 눈에 띄게 변화를 주지만 다른 BHO들은 인터페이스에 변화없이 실행한다.


 This renders it easy for malicious coders to conceal the actions of their browser add-on, especially since, after being installed, the BHO seldom requires permission before performing further actions.

이는 악성코드 작성자가 그들의 브라우저 add-on의 행동을 숨기기 쉽도록 하며 특히 설치된 후, BHO는 행동을 수행하기 전에 허락을 거의 요구하지 않는다.

 For instance, variants of the ClSpring trojan use BHOs to install scripts to provide a number of instructions to be performed such as adding and deleting registry values and downloading additional executable files, all completely transparent to the user [1]. 

예를 들어, CISpring 트로이 목마 변형은 BHO를 사용자들에게는 모두 완벽히 보이지 않고 추가적인 실행 파일을 다운로드 받고 레지스트리 값을 추가하거나 지우는 것 같은 일을 수행함으로써 많은 명령어들을 제공하는 스크립터를 설치하도록 한다.

The DyFuCA spyware even replaces IE's general error page with an ad page.

DyFuCA 스파이웨어는 광고 페이지와 함께 IE의 일반적인 오류 페이지를 대체하기도 한다.

In response to the problems associated with BHOs and similar extensions to Internet Explorer, Microsoft debuted an Add-on Manager in Internet Explorer 6 with the release of Service Pack 2 for Windows XP (updating it to IE6 Security Version 1 (a.k.a. SP2). 

인터넷 익스플로어의 BHO와 비슷한 확장 모듈과 관련된 문제에 대응하여, 마이크로소프트는 서비스 팩2 출시와 함께 인터넷 익스플로어에 Add-on 메니저를 출시했다.

This utility displays a list of all installed BHOs, browser extensions and ActiveX controls, and allows the user to enable or disable them at will. 

이 유틸리티는 모든 설치된 BHO의 목록을 보여주고, 브라우저 확장 모듈과 ActiveX 컨트롤, 그리고 사용자에게 의지대로 이러한 모듈들을 사용자가 가능하게 혹은 불가능하게 한다.

There are also free tools (such as BHODemon) that list installed BHOs and allow the user to disable malicious extensions. 

(BHODemon같은) 설치된 BHO들을 보여주는 무료 툴들이 있고 이는 사용자들에게 악성 확장모듈을 사용하지 못하도록 한다.

Spybot S&D has a similar tool built in to allow the user to disable installed BHOs. 

Spybot S&D는 설치된 BHO들을 사용하지 못하게 하는 비슷한 built-in 툴이 있다.

Many anti-spyware applications also offer the capability to block the download or install of BHOs identified as malicious.

많은 백신 프로그램들은 악성으로 확인된 BHO의 설치나 다운로드를 차단하는 능력들을 제공한다.


render = make, ~을 ~하게 하다.

conceal 숨기다.

반응형

'번역' 카테고리의 다른 글

MEMORY Storage Engine  (0) 2016.11.04
테스트 주도 개발  (0) 2016.01.22
Computer virus  (0) 2009.10.07
악성코드  (0) 2009.10.07
행성의 정의  (0) 2009.08.03
반응형

원본 참고주소 : http://en.wikipedia.org/w/index.php?title=Planet&oldid=77980546

지식iN에 작성했던 내용 : http://kin.naver.com/open100/db_detail.php?d1id=11&dir_id=110206&eid=66zRuRDk4GdUYWGVdAflaXILPeV+b2C5&l_url=




행성의 정의

국제천문연맹(IAU)은 천체로써 태양계에만 해당하는 행성에 대해 공식적이고 과학적인 명명법을 다음과 같이 정의하였다.

 

1. 태양을 공전한다.

2. 충분한 질량을 가져 자체 중력으로 유체역학적 평형을 이루는 한편 타원형이 아닌 구형(球形)을 유지~ (구형을 유지할만한 질량을 가져야 한다는 뜻입니다~)

3. 주변 궤도의 다른 천체들을 깨끗이 흡수할 수 있는 천체(공전 구역 내에서 지배적인 역할을 하는 천제)

 

우리 태양계는 이 정의에 의해 8개의 행성이 고려되었다. : 수성, 금성, 지구, 화성, 목성, 토성, 천왕성, 해왕성

 

왜행성(행성의 형태가 아님)은 천체로서 다음과 같이 정의하였다

 

1. 태양을 공전한다.

2. 충분한 질량을 가져 자체 중력으로 유체역학적 평형을 이루는 한편 타원형이 아닌 구형(球形)을 유지~ (구형을 유지할만한 질량을 가져야 한다는 뜻입니다~)

3. 주변 궤도의 다른 천체들을 깨끗이 흡수할 수 있는 천체가 아니다.

4. 위성이 아니다.

 

기준에 맞는 다른 천체들이 있을지라도 (우선은) 태양계에서 3개의 천체는 왜행성으로 인식된다 : 세레스, 명왕성, 에리스(제나)

 

이 정의는 다른 항성을 공전하는 천체에는 적용되지 않는다. 외부 태양계에 대한 국제천문연맹 working group은 다음과 같이 정의하고 있다.

 

1. 별을 공전하는 중수소 핵융합을 위한 최소한의 질량 미만의 질량을 가지는 천체이다. 행성이 되기 위해 외부태양계를 위해 요구되는 최소 질량/크기는 우리 태양계에서 사용되는 것과 같다.

2. 중수소 핵융합을 위한 최소한의 질량 이상의 질량을 가지는 천체는 갈색왜성이다. 어디에 있고 어떻게 형성되었는지 신경쓰지 않는다.

3. 중수소 핵융합을 위한 최소한의 질량 이하의 질량을 가지는 젋은 별 클러스터에서 자유롭게 떠다니는 천체는 행성이 아니다. 그들은 부갈색왜성이다.

 

다른 별에서 발견된 행성은 200개가 넘는다.

 

2006년 결정의 채택이 있기 전까지 행성의 과학적인 정의는 없었다. 정의가 없더라도 행성의 수는 바뀌어 왔다. (다양하게 보여져 왔다.)

 

천문학이 발전하고 지동설이 받아들여지면서 태양과 달이 (행성에서) 제외되었고 현재처럼 행성의 구성원이 추가되었다. 행성이 태양을 공전하는 큰 천체라고 생각될 지라도 행성의 정의에 대한 과학적으로 구체화되지 않았다. 과학적인 합의와 문화에 의해 수천년동안 받아들인 행성의 숫자는 다양했다.

 

1500년대 이전까지 - (7개)달, 수성, 금성, 태양, 화성, 목성, 토성 - 천동설

1550년 - (6개) 수성, 금성, 지구, 화성, 목성, 토성 - 지동설

1781년 - (7개) 수성, 금성, 지구, 화성, 목성, 토성, 천왕성

1807년 - (11개) 수성, 금성, 지구, 화성, 케레스, 팔라스, 주노, 베스타, 목성, 토성, 천왕성

1845년 - (12개) 아스트라이아 추가

1846년 - (13개) 해왕성 추가

1851년 - (8개) 수성, 금성, 지구, 화성, 목성, 토성, 천왕성, 해왕성(소행성대 제외)

1930년 - (9개) 수성, 금성, 지구, 화성, 목성, 토성, 천왕성, 해왕성, 명왕성

2006년 - (8개) 수성, 금성, 지구, 화성, 목성, 토성, 천왕성, 해왕성

반응형

'번역' 카테고리의 다른 글

MEMORY Storage Engine  (0) 2016.11.04
테스트 주도 개발  (0) 2016.01.22
Computer virus  (0) 2009.10.07
악성코드  (0) 2009.10.07
BHO  (0) 2009.10.07

+ Recent posts