en to ko translation catalogue (87 entries)

note: type: Content of: <chapter><title>
en: Choosing a Debian distribution
ko: 데비안 배포판 선택

note: type: Content of: <chapter><para>
en: There are many different Debian distributions.  Choosing the proper Debian distribution is an important decision.  This section covers some information useful for users that want to make the choice best suited for their system and also answers possible questions that might be arising during the process.  It does not deal with "why you should choose Debian" but rather "which distribution of Debian".
ko: 여러 다른 데비안 배포판이 있습니다. 적절한 데비안 배포판 선택은 중요한 결정입니다. 이 절은 시스템에 가장 적절한 선택을 하는데 필요한 정보를 주고, 절차 중 생길 수 있는 질문에 답합니다. "데비안을 선택하는 까닭" 아니라 "데비안의 어느 배포판"을 다룹니다.

note: type: Content of: <chapter><para>
en: For more information on the available distributions read <xref linkend="dists"/>.
ko: 가능한 배포판에 대한 자세한 내용 <xref linkend="dists"/>.

note: type: Content of: <chapter><section><title>
en: Which Debian distribution (stable/testing/unstable) is better for me?
ko: 어느 데비안 배포판(stable/testing/unstable)이 나에게 좋은가요?

note: type: Content of: <chapter><section><para>
en: The answer is a bit complicated.  It really depends on what you intend to do.  One solution would be to ask a friend who runs Debian.  But that does not mean that you cannot make an independent decision.  In fact, you should be able to decide once you complete reading this chapter.
ko: 대답은 약간 복잡합니다. 그것은 사실 당신이 하려는 것에 따라 다릅니다. 한 가지 해결책은 데비안을 사용하는 친구에게 물어보는 것입니다. 그러나, 그렇다고 해서 독립적인 결정을 내릴 수 없는 것은 아닙니다. 사실, 이 장을 다 읽으면 결정할 수 있을 겁니다.

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: If security or stability are at all important for you: install stable.  period.  This is the most preferred way.
ko: 보안이나 안정성이 중요하다면: stable 설치하십시오. 끝. 이것이 가장 권장하는 방법입니다.

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: If you are a new user installing to a desktop machine, start with stable.  Some of the software is quite old, but it's the least buggy environment to work in.  You can easily switch to the more modern unstable (or testing) once you are a little more confident.
ko: 데스크톱 컴퓨터에 설치하는 신규 사용자인 경우 stable로 시작하십시오. 일부 소프트웨어는 꽤 오래되었지만 작업하기에 버그가 가장 적은 환경입니다. 조금 더 자신감이 생기면 최신 unstable(또는 testing)으로 쉽게 전환할 수 있습니다.

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: If you are a desktop user with a lot of experience in the operating system and do not mind facing the odd bug now and then, or even full system breakage, use unstable.  It has all the latest and greatest software, and bugs are usually fixed swiftly.
ko: 운영 체제에 대한 많은 경험이 있는 데스크톱 사용자이고 때때로 이상한 버그가 발생하거나 전체 시스템이 손상되는 것을 걱정하지 않는다면 unstable 사용하십시오. 모든 최신 소프트웨어가 있으며 버그는 대개 빨리 고칩니다.

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: If you are running a server, especially one that has strong stability requirements or is exposed to the Internet, install stable.  This is by far the strongest and safest choice.
ko: 서버, 특히 강력한 안정성 요구 사항이 있거나 인터넷에 노출된 서버를 실행 중인 경우 stable 설치하십시오. 이것이 지금까지 가장 강력하고 안전한 선택입니다.

note: type: Content of: <chapter><section><para>
en: The following questions (hopefully) provide more detail on these choices.  After reading this whole FAQ, if you still could not make a decision, stick with the stable distribution.
ko: 다음 질문은 이러한 선택에 대한 자세한 정보를 제공합니다. 이 전체 FAQ를 읽은 후에도 여전히 결정을 내릴 수 없다면 stable 배포판을 고르시오.

note: type: Content of: <chapter><section><section><title>
en: You asked me to install stable, but in stable so and so hardware is not detected/working. What should I do?
ko: 요청은 stable 설치 하라고 하지만, stable에서 하드웨어가 감지/동작하지 않습니다. 어떻게 하나요?

note: type: Content of: <chapter><section><section><para>
en: Try to search the web using a search engine and see if someone else is able to get it working in stable.  Most of the hardware should work fine with stable.  But if you have some state-of-the-art, cutting edge hardware, it might not work with stable.  If this is the case, you might want to install/upgrade to either testing or unstable.
ko: 검색 엔진을 사용하여 웹을 검색하고 다른 사람이 안정적으로 작동하도록 할 수 있는지 확인하십시오. 대부분의 하드웨어는 안정적으로 잘 작동해야 합니다. 그러나 최첨단 하드웨어가 있으면 stable에서 동작하지 않을 수 있습니다. 이 경우 testing 또는 unstable로 설치/업그레이드할 수 있습니다.

note: type: Content of: <chapter><section><section><para>
en: For laptops, <ulink url="https://www.linux-on-laptops.com/"/> is a very good website to see if someone else is able to get it to work under Linux.  The website is not specific to Debian, but is nevertheless a tremendous resource.  I am not aware of any such website for desktops.
ko: 랩톱에서 <ulink url="https://www.linux-on-laptops.com/"/>은 다른 사람이 리눅스에서 동작하게 할 수 있는지 확인할 수 있는 매우 좋은 웹사이트입니다. 이 웹사이트는 데비안에만 국한된 것은 아니지만, 엄청난 재료입니다. 나는 데스크톱 용 웹사이트는 모릅니다.

note: type: Content of: <chapter><section><section><para>
en: Another option would be to ask in the debian-user mailing list by sending an email to debian-user@lists.debian.org.  Messages can be posted to the list even without subscribing.  The archives can be read through <ulink url="https://lists.debian.org/debian-user/"/>.  Information regarding subscribing to the list can be found at the location of archives.  You are strongly encouraged to post your questions on the mailing-list rather than on <ulink url="&url-debian-support;">irc</ulink>.  The mailing-list messages are archived, so the solution to your problem can help others with the same issue.
ko: 다른 옵션은 debian-user@lists.debian.org로 전자메일 보내서 debian-user 메일링 리스트에 요청하는 것입니다. 메시지를 구독하지 않아도 목록에 게시할 수 있습니다. 아카이브는 <ulink url="https://lists.debian.org/debian-user/"/> 통해 읽을 수 있습니다 . 목록 구독에 대한 정보는 아카이브 위치에서 찾을 수 있습니다. 질문을  <ulink url="&url-debian-support;">irc</ulink> 아니고 메일링 리스트에 게시하는 것을 강력 추천합니다 . 메일링 리스트 메시지는 보관되므로 문제에 대한 해법이 같은 문제를 가진 다른 사람을 도울 수 있습니다.

note: type: Content of: <chapter><section><section><title>
en: Will there be different versions of packages in different distributions?
ko: 다른 배포판에 다른 버전 패키지가 있나요?

note: type: Content of: <chapter><section><section><para>
en: Yes.  Unstable has the most recent (latest) versions.  But the packages in unstable are not well tested and might have bugs.
ko: 예. unstable에는 가장 최신(최근) 버전이 있습니다. 그러나 unstable에 있는 패키지는 잘 테스트되지 않았으며 버그가 있을 수 있습니다.

note: type: Content of: <chapter><section><section><para>
en: On the other hand, stable contains old versions of packages.  But this package is well tested and is less likely to have any bugs.
ko: 반면, stable 패키지에는 이전 버전의 패키지가 들어 있습니다. 그러나 이 패키지는 잘 테스트 되었으며 버그가 있을 가능성이 적습니다.

note: type: Content of: <chapter><section><section><para>
en: The packages in testing fall between these two extremes.
ko: 패키지 중 testing에 있는 것은 이 두 극단 사이에 있습니다.

note: type: Content of: <chapter><section><section><title>
en: The stable distributions really contains outdated packages. Just look at Kde, Gnome, Xorg or even the kernel. They are very old. Why is it so?
ko: stable 배포판에는 실제로 오래된 패키지가 들어 있습니다. Kde, Gnome, Xorg 또는 커널을 살펴보십시오. 아주 오래되었습니다. 왜 그런가요?

note: type: Content of: <chapter><section><section><para>
en: Well, you might be correct.  The age of the packages at stable depends on when the last release was made.  Since there is typically over 1 year between releases you might find that stable contains old versions of packages.  However, they have been tested in and out.  One can confidently say that the packages do not have any known severe bugs, security holes etc., in them.  The packages in stable integrate seamlessly with other stable packages.  These characteristics are very important for production servers which have to work 24 hours a day, 7 days a week.
ko: 글쎄, 당신이 맞을 수도 있습니다. stable 패키지의 수명은 마지막 릴리스가 만들어진 시기에 따라 다릅니다. 릴리스 사이에는 대개 1년 이상 있으므로 stable 패키지에 이전 버전의 패키지가 들어 있음을 알 수 있습니다. 그러나 그것은 안팎으로 테스트되었습니다. 패키지에는 알려진 심각한 버그, 보안 허점 등이 없다고 자신 있게 말할 수 있습니다. stable 패키지는 다른 stable 패키지와 원활하게 통합됩니다. 이러한 특성은 하루 24시간, 주 7일 작동해야 하는 프로덕션 서버에 매우 중요합니다.

note: type: Content of: <chapter><section><section><para>
en: On the other hand, packages in testing or unstable can have hidden bugs, security holes etc.  Moreover, some packages in testing and unstable might not be working as intended.  Usually people working on a single desktop prefer having the latest and most modern set of packages.  Unstable is the solution for this group of people.
ko: 한편, testing 또는 unstable 패키지에 숨겨진 버그, 보안 구멍 등이 있을 수 있습니다. 게다가 testing 및 unstalbe은 기대한 대로 동작하지 않을 수 있습니다.

note: type: Content of: <chapter><section><section><para>
en: As you can see, stability and novelty are two opposing ends of the spectrum.  If stability is required: install stable distribution.  If you want to work with the latest packages, then install unstable.
ko: 보는 바와 같이, 안정성과 새로움은 스펙트럼의 양 끝입니다. 안정성이 필요하면: stable 배포판을 설치하십시오. 최신 패키지로 작업하려면 unstable 설치하십시오.

note: type: Content of: <chapter><section><section><title>
en: If I were to decide to change to another distribution, can I do that?
ko: 다른 배포판으로 바꾸기로 결정했다면, 내가 할 수 있나요?

note: type: Content of: <chapter><section><section><para>
en: Yes, but it is a one way process.  You can go from stable --&gt; testing --&gt; unstable.  But the reverse direction is not "possible".  So better be sure if you are planning to install/upgrade to unstable.
ko: 예, 하지만 단방향 프로세스입니다. stable --&gt; testing --&gt; unstable 가능합니다. 그러나 반대 방향은 "가능"하지 않습니다. 따라서 unstable 설치/업그레이드할 계획인지 확인하는 것이 좋습니다.

note: type: Content of: <chapter><section><section><para>
en: Actually, if you are an expert and if you are willing to spend some time and if you are real careful and if you know what you are doing, then it might be possible to go from unstable to testing and then to stable.  The installer scripts are not designed to do that.  So in the process, your configuration files might be lost and...
ko: 사실, 당신이 전문가이고 시간을 할애할 의향이 있고 정말로 조심하고 무엇을 하고 있는지 안다면 unstable에서 testing으로, 그리고 stable로 갈 수 있습니다. 설치프로그램 스크립트는 그렇게 하도록 설계되지 않았습니다. 따라서 이 과정에서 구성 파일을 잃을 수 있으며...

note: type: Content of: <chapter><section><section><title>
en: Could you tell me whether to install stable, testing or unstable?
ko: 나에게 stable, testing 또는 unstable 중에 무엇을 설치할 지 말해주시겠어요?

note: type: Content of: <chapter><section><section><para>
en: No.  This is a rather subjective issue.  There is no perfect answer as it depends on your software needs, your willingness to deal with possible breakage, and your experience in system administration.  Here are some tips:
ko: 아뇨. 그건 주관적 이슈입니다. 소프트웨어 요구 사항, 파손 가능성에 대한 대처 의지, 시스템 관리 경험에 따라 달라지므로 완벽한 답은 없습니다. 다음은 몇 가지 팁:

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Stable is rock solid.  It does not break and has full security support.  But it not might have support for the latest hardware.
ko: stable은 견고합니다. 깨지지 않고 완벽한 보안 지원을 제공합니다. 그러나 최신 하드웨어를 지원하지 않을 수 있습니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Testing has more up-to-date software than Stable, and it breaks less often than Unstable.  But when it breaks, it might take a long time for things to get rectified.  Sometimes this could be days and it could be months at times.  It also does not have permanent security support.
ko: testing에는 stable 보다 최신 소프트웨어가 있으며 unstable보다 덜 중단됩니다. 하지만, 그것이 깨지면 문제를 해결하는 데 오랜 시간이 걸릴 수 있습니다. 때로는 이것이 며칠이 될 수도 있고 때로는 몇 달이 될 수도 있습니다. 영구적인 보안 지원을 제공하지도 않습니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Unstable has the latest software and changes a lot.  Consequently, it can break at any point.  However, fixes get rectified in many occasions in a couple of days and it always has the latest releases of software packaged for Debian.
ko: Unstable은 최신 소프트웨어를 갖고 있으며 많이 바뀝니다. 결과적으로, 어디서나 깨질 수 있습니다. 그러나, 고친 것은 며칠 안에 여러 번 수정되며 항상 데비안용으로 패키지된 최신 소프트웨어 릴리스가 있습니다.

note: type: Content of: <chapter><section><section><para>
en: When deciding between testing and unstable bear in mind that there might be times when tracking testing would be beneficial as opposed to unstable.  One of this document's authors experienced such situation due to the gcc transition from gcc3 to gcc4.  He was trying to install the <systemitem role="package">labplot</systemitem> package on a machine tracking unstable and it could not be installed in unstable as some of its dependencies have undergone gcc4 transition and some have not.  But the package in testing was installable on a testing machine as the gcc4 transitioned packages had not "trickled down" to testing.
ko: testing 및 unstable 사이에서 결정할 때 testing을 추적하는 것이 unstable 보다 좋을 때가 있을 수 있다는 점을 주의하십시오. 이 문서의 작성자 중 한 명이 gcc3에서 gcc4로의 gcc 전환으로 인해 이러한 상황을 경험했습니다. 그는 unstable을 추적하는 컴퓨터에 <systemitem role="package">labplot</systemitem>를  설치하려 했습니다. unstable에 설치할 수 없었는데, 왜냐면 종속성 중 일부가 gcc4 전환을 거쳤고 일부는 그렇지 않았기 때문. 그러나 testing에 있는 패키지는 testing 컴퓨터에 설치가능했는데, 왜냐면 gcc4로 전환된 패키지가 테스트로 "trickled down" 안 되었기 때문.

note: type: Content of: <chapter><section><section><title>
en: You are talking about testing being broken. What do you mean by that?
ko: testing이 깨지는 것에 대해 말합니다. 저건 무슨 뜻이죠?

note: type: Content of: <chapter><section><section><para>
en: Sometimes, a package might not be installable through package management tools.  Sometimes, a package might not be available at all, maybe it was (temporarily)  removed due to bugs or unmet dependencies.  Sometimes, a package installs but does not behave in the proper way.
ko: 때때로, 패키지 관리 도구를 통해 패키지를 설치하지 못할 수 있습니다. 때로는, 패키지를 전혀 사용할 수 없거나, 버그 또는 충족되지 않은 종속성으로 인해 (일시적으로) 제거되었을 수 있습니다. 때로는, 패키지가 설치되지만 제대로 작동하지 않습니다.

note: type: Content of: <chapter><section><section><para>
en: When these things happen, the distribution is said to be broken (at least for this package).
ko: 이러한 일이 생기면 배포판이 깨졌다고 합니다(적어도 이 패키지는).

note: type: Content of: <chapter><section><section><title>
en: Why is it that testing could be broken for months? Won't the fixes introduced in unstable flow directly down into testing?
ko: 왜 testing이 몇 달 동안 깨질 수 있나요? unstable 흐름에 도입된 수정 사항이 testing에 직접 적용되지 않나요?

note: type: Content of: <chapter><section><section><para>
en: The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days.  Let's say this threshold is 5 days.  The packages in unstable go into testing only when there are no RC-bugs reported against them.  If there is a RC-bug filed against a package in unstable, it will not go into testing after the 5 days.
ko: unstable 배포판에 도입된 버그 수정 및 개선 사항은 일정 기간이 지나면 테스트 단계까지 이어집니다. 이 임계값이 5일이라고 가정해 보겠습니다. 불안정한불안정한 배포판에 도입된 버그 수정 및 개선 사항은 일정 기간이 지나면 테스트 단계까지 이어집니다. 이 임계값이 5일이라고 가정해 보겠습니다. unstable 패키지는 RC 버그가 보고되지 않은 경우에만 테스트에 들어갑니다. 불안정한 패키지에 대해 RC-버그가 있으면 5일 후에 테스트에 들어가지 않습니다.

note: type: Content of: <chapter><section><section><para>
en: The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing.  This keeps testing in a usable state for most of the time.  Overall a brilliant concept, if you ask me.  But things aren't always that simple.  Consider the following situation:
ko: 아이디어는 그렇습니다. 만약 패키지가 문제 있으면 unstable 쓰는 사람이 발견할 거고 testing에 들어가기 전에 고칠 거다. 이것이 testing을 쓸 수 있는 상태로 대부분 시간 동안 유지한다. 전반적으로 좋은 개념, 만약 나에게 물어본다면. 그러나, 모든 게 늘 간단하지는 않습니다. 고려할 상황:

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Imagine you are interested in package XYZ.
ko: 패키지 XYZ에 관심있다고 합시다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Let's assume that on June 10, the version in testing is XYZ-3.6 and in unstable it is XYZ-3.7.
ko: 6월 10일에 testing 버전이 XYZ-3.6이고 unstable 버전이 XYZ-3.7이라고 가정해 보겠습니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: After 5 days, XYZ-3.7 from unstable migrates into testing.
ko: 5일 후, XYZ-3.7이 unstable 마이그레이션이 testing으로 들어갑니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: So on June 15, both testing and unstable have XYZ-3.7 in their repositories.
ko: 그래서, 6월 15일에 testing 및 unstable 모두 저장소에 XYZ-3.7이 있습니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Let's say, the user of testing distribution sees that a new XYZ package is available and updates the XYZ-3.6 to XYZ-3.7.
ko: 예를들어, testing 배포 사용자가 새 XYZ 패키지를 사용할 수 있음을 확인하고 XYZ-3.6을 XYZ-3.7로 업데이트한다고 가정합니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Now on June 25, someone using testing or unstable discovers an RC bug in XYZ-3.7 and files it in the BTS.
ko: 이제 6월 25일에 testing 또는 unstable 사용자가 XYZ-3.7에서 RC 버그를 발견하고 BTS에 신고합니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: The maintainer of XYZ fixes this bug and uploads it to unstable say on June 30.  Here it is assumed that it takes 5 days for the maintainer to fix the bug and upload the new version.  The number 5 should not be taken literally.  It could be less or more, depending upon the severity of the RC-bug at hand.
ko: XYZ의 메인테이너가 이 버그를 수정하여 6월 30일에 unstable에 업로드했다고 합시다. 여기서는 메인테이너가 버그를 수정하고 새 버전을 업로드하는 데 5일이 걸린다고 가정합니다. 숫자 5를 문자 그대로 받아들이면 안 됩니다. 당면한 RC 버그의 심각도에 따라 적거나 많을 수 있습니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: This new version in unstable, XYZ-3.8 is scheduled to enter testing on July 5th.
ko: unstable에 있는 이 새 버전 XYZ-3.8은 7월 5일에 testing에 들어갈 예정입니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: But on July 3rd some other person discovers another RC-bug in XYZ-3.8.
ko: 그러나 7월 3일 다른 사람이 XYZ-3.8에서 또 다른 RC 버그를 발견합니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Let's say the maintainer of XYZ fixes this new RC-bug and uploads new version of XYZ after 5 days.
ko: XYZ의 관리자가 이 새로운 RC 버그를 수정하고 5일 후에 새 버전의 XYZ를 업로드한다고 가정해 보겠습니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: So on July 8th, testing has XYZ-3.7 while unstable has XYZ-3.9.
ko: 따라서 7월 8일에 testing에는 XYZ-3.7이 있고 unstable에는 XYZ-3.9가 있습니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: This new version XYZ-3.9 is now rescheduled to enter testing on July 13th.
ko: 이 새 버전 XYZ-3.9는 이제 7월 13일에 testing에 들어가도록 일정이 변경되었습니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Now since you are running testing, and since XYZ-3.7 is buggy, you could probably use XYZ only after July 13th.  That is you essentially ended up with a broken XYZ for about one month.
ko: 이제 testing을 실행 중이고, XYZ-3.7에 버그가 있으므로, 7월 13일 이후에만 XYZ를 사용할 수 있습니다. 그것은 당신이 본질적으로 약 한 달 동안 깨진 XYZ로 끝났다는 것입니다.

note: type: Content of: <chapter><section><section><para>
en: The situation can get much more complicated, if say, XYZ depends on 4 other packages. This could in turn lead to an unusable testing distribution for months. While the scenario above is imaginary, similar things can occur in real life, though they are rare.
ko: 상황이 훨씬 더 복잡해질 수 있습니다. 예를 들어 XYZ는 4개의 다른 패키지에 의존합니다. 이로 인해 몇 달 동안 사용할 수 없는 testing 배포가 발생할 수 있습니다. 위의 시나리오는 상상이지만, 비슷한 일이 현실에서 드물더라도 일어날 수 있습니다.

note: type: Content of: <chapter><section><section><title>
en: From an administrator's point of view, which distribution requires more attention?
ko: 관리자 관점에서 더 주의가 필요한 배포는 무엇인가요?

note: type: Content of: <chapter><section><section><para>
en: One of the main reasons why many people choose Debian over other Linux distributions is that it requires very little administration.  People want a system that just works.  In general one can say that stable requires very little maintenance, while testing and unstable require constant maintenance from the administrator.  If you are running stable, all you need to worry about is keeping track of security updates.  If you are running either testing or unstable it is a good idea to be aware of the new bugs discovered in the installed packages, new bugfixes/features introduced etc.
ko: 많은 사람이 다른 리눅스 배포판보다 데비안을 선택하는 주된 이유 중 하나는 관리가 거의 필요하지 않기 때문입니다. 제대로 작동하는 시스템을 원합니다. 일반적으로 stable은 유지 관리가 거의 필요하지 않지만 testing 및 unstable은 관리자가 지속적인 유지 관리해야 합니다. stable을 실행 중이라면 보안 업데이트를 추적하기만 하면 됩니다. testing 또는 unstable을 쓰면 설치된 패키지에서 발견된 새로운 버그, 새로운 버그 수정/기능 도입 등을 알고 있는 것이 좋습니다.

note: type: Content of: <chapter><section><section><title>
en: What happens when a new release is made?
ko: 새 릴리스를 만들면 어떻게 되나요?

note: type: Content of: <chapter><section><section><para>
en: This question will not help you in choosing a Debian distribution.  But sooner or later you will face this question.
ko: 이 질문은 데비안 배포판을 선택하는 데 도움이 되지 않습니다. 그러나 조만간 이 질문에 직면하게 될 것입니다.

note: type: Content of: <chapter><section><section><para>
en: The stable distribution is currently &releasename;; The next stable distribution will be called &nextreleasename;.  Let's consider the particular case of what happens when &nextreleasename; is released as the new stable version.
ko: stable 배포판은 현재 &releasename;. 다음 stable 배포판은 &nextreleasename;. &nextreleasename;가 새 stable 버전으로 릴리스되었을 때 어떤 일이 일어나는지 특별한 경우를 생각해 봅시다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Unstable is always referred to as sid irrespective of whether a release is made or not.
ko: Unstable은 릴리스 여부에 관계없이 항상 sid라고 합니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Packages constantly migrate from sid to testing (i.e. &nextreleasename;).  But packages in stable (i.e. &releasename;) remain the same except for security updates.
ko: 패키지는 지속적으로 sid에서 testing(&nextreleasename;)로 마이그레이트 됩니다. 그러나 stable 안의 패키지(&releasename;)는 보안 업데이트를 제외하고는 동일하게 유지됩니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: After some time testing becomes frozen.  But it will still be called testing.  At this point no new packages from unstable can migrate to testing unless they include release-critical (RC) bug fixes.
ko: 얼마 후 testing은 동결됩니다. 그러나 여전히 testing 이라고 할 것입니다. 이 시점에서 RC(릴리스 크리티컬) 버그 수정이 없으면 unstable에 있는 새 패키지는 testing으로 마이그레이트 안 됩니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: When testing is frozen, all the new bugfixes introduced have to be manually checked by the members of the release team.  This is done to ensure that there won't be any unknown severe problems in the frozen testing.
ko: testing이 동결되면, 릴리스 팀 구성원이 새로 도입된 모든 버그 수정을 수동으로 확인해야 합니다. 동결된 테스트에서 알려지지 않은 심각한 문제가 없도록 하기 이렇게 합니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: RC bugs in 'frozen testing' are reduced to either zero or, if greater than zero, the bugs are either marked as ignored for the release or are deferred for a point release.
ko: '동결된 testing'의 RC 버그는 0으로 줄거나 0보다 크면, 버그가 릴리스에 대해 무시된 것으로 표시되거나 포인트 릴리스에 대해 연기됩니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: The 'frozen testing' with no rc-bugs will be released as the new stable version.  In our example, this new stable release will be called &nextreleasename;.
ko: rc-bug 없는 '프로즌 testing'은 새 stable 버전으로 릴리스 될 것입니다. 이 예에서 이 새로운 안정적인 릴리스는 &nextreleasename;.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: At this stage oldstable = &releasename;, stable = &nextreleasename;.  The contents of stable and 'frozen testing' are same at this point.
ko: 이 단계에서 oldstable = &releasename;, stable = &nextreleasename;. 이 시점에서 stable 및 '동결된 testing' 내용은 같습니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: A new testing is based on the old testing.
ko: 새 testing은 old testing 기반입니다.

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Packages start coming down from sid to testing and the Debian community will be working towards making the next stable release.
ko: 패키지가 sid에서 testing으로 내려오기 시작하고 데비안 커뮤니티는 다음 stable 릴리스를 만들려고 일합니다.

note: type: Content of: <chapter><section><section><title>
en: I have a working Desktop/cluster with Debian installed. How do I know which distribution I am running?
ko: 데비안을 설치한 작동하는 데스크톱/클러스터가 있습니다. 실행 중인 배포판을 어떻게 아나요?

note: type: Content of: <chapter><section><section><para>
en: In most situations it is very easy to figure this out.  Take a look at the <filename>/etc/apt/sources.list</filename> file.  There will be an entry similar to this:
ko: 대부분의 상황에서 이것을 알아내는 것은 매우 쉽습니다. <filename>/etc/apt/sources.list</filename> 파일을 살펴보십시오. 다음과 유사한 항목이 있습니다:

note: type: Content of: <chapter><section><section><para>
en: The third field ('unstable' in the above example) indicates the Debian distribution the system is currently tracking.
ko: 세 번째 필드(위의 예에서 'unstable')는 시스템이 현재 추적 중인 데비안 배포판을 나타냅니다.

note: type: Content of: <chapter><section><section><para>
en: You can also use <command>lsb_release</command> (available in the <systemitem role="package">lsb-release</systemitem> package).  If you run this program in an unstable system you will get:
ko: <command>lsb_release</command>를 사용할 수도 있습니다 (<systemitem role="package">lsb-release</systemitem> 패키지에서 가능). 이 프로그램을 unstable 시스템에서 실행하면 얻는 것:

note: type: Content of: <chapter><section><section><para>
en: However, this is not always that easy.  Some systems might have <filename>sources.list</filename> files with multiple entries corresponding to different distributions.  This could happen if the administrator is tracking different packages from different Debian distributions.  This is frequently referred to as apt-pinning.  These systems might run a mixture of distributions.
ko: 그러나 이것이 항상 쉬운 것은 아닙니다. 일부 시스템에는 <filename>sources.list</filename> 파일에 다른 배포판에 해당하는 여러 항목이 있을 수 있습니다 . 이것은 관리자가 다른 데비안 배포판에서 다른 패키지를 추적할 때 생길 수 있습니다. 이것을 흔히 apt-pinning이라고 합니다. 이러한 시스템은 배포판 혼합을 실행할 수 있습니다.

note: type: Content of: <chapter><section><section><title>
en: I am currently tracking stable. Can I change to testing or unstable? If so, how?
ko: 현재 stable을 추적 중입니다. testing 또는 unstable로 바꿀 수 있나요? 그렇다면 어떻게?

note: type: Content of: <chapter><section><section><para>
en: If you are currently running stable, then in the <filename>/etc/apt/sources.list</filename> file the third field will be either '&releasename;' or 'stable'.  You need to change this to the distribution you want to run.  If you want to run testing, then change the third field of <filename>/etc/apt/sources.list</filename> to 'testing'.  If you want to run unstable, then change the third field to 'unstable'.
ko: 현재 stable을 실행한다면, <filename>/etc/apt/sources.list</filename> 파일 3번째 필드는 '&releasename;' 또는 'stable'. 이것을 실행하려는 배포판으로 바꾸어야 합니다. testing을 실행하려면, <filename>/etc/apt/sources.list</filename>의 3번째 필드를 'testing'으로 바꾸세요.  If you want to run unstable을 실행하려면, 3번째 필드를 'unstable'으로 바꾸세요.

note: type: Content of: <chapter><section><section><para>
en: Currently testing is called &nextreleasename;.  So, if you change the third field of <filename>/etc/apt/sources.list</filename> to '&nextreleasename;', then also you will be running testing.  But even when &nextreleasename; becomes stable, you will still be tracking &nextreleasename;.
ko: 현재 testing은 &nextreleasename;. <filename>/etc/apt/sources.list</filename> 파일의 3번째 필드를 '&nextreleasename;'로 바꾸면, testing을 실행합니다. 그러나 &nextreleasename; 이 stable로 될 때에도 &nextreleasename;을 추적합니다.

note: type: Content of: <chapter><section><section><para>
en: Unstable is always called Sid.  So if you change the third field of <filename>/etc/apt/sources.list</filename> to 'sid', then you will be tracking unstable.
ko: 불안정은 항상 Sid라고 합니다. 따라서 <filename>/etc/apt/sources.list</filename> 파일의 세 번째 필드를 'sid'로 바꾸면 unstable을 추적합니다.

note: type: Content of: <chapter><section><section><para>
en: Currently Debian offers security updates for testing but not for unstable, as fixes in unstable are directly made to the main archive.  So if you are running unstable make sure that you remove the lines relating to security updates in <filename>/etc/apt/sources.list</filename>.
ko: 현재 데비안은 testing 용 보안 업데이트를 제공하지만 unstable에는 제공하지 않는데, 왜냐면 unstable에 있는 수정 사항은 기본 아카이브에 직접 적용되기 때문입니다. 따라서 unstable을 실행 중이면 .<filename>/etc/apt/sources.list</filename>에서 보안 업데이트와 관련된 줄을 제거하십시오.

note: type: Content of: <chapter><section><section><para>
en: If there is a release notes document available for the distribution you are upgrading to (even though it has not yet been released) it would be wise to review it, as it might provide information on how you should upgrade to it.
ko: 업그레이드하려는 배포판에 사용할 수 있는 릴리스 정보 문서가 있는 경우(아직 릴리스되지는 않았더라도) 이를 검토하는 것이 현명합니다. 이 문서에서 업그레이드 방법에 대한 정보를 제공할 수 있기 때문입니다.

note: type: Content of: <chapter><section><section><para>
en: Nevertheless, once you make the above changes, you can run <filename>aptitude update</filename> and then install the packages that you want.  Notice that installing a package from a different distribution might automatically upgrade half of your system.  If you install individual packages you will end up with a system running mixed distributions.
ko: 그럼에도, 위와 같이 바꾸면, <filename>aptitude update</filename> 실행하고 그러면 원하는 패키지를 설치할 수 있습니다. 다른 배포판에서 패키지를 설치하면 시스템의 절반이 자동으로 업그레이드될 수 있습니다. 개별 패키지를 설치하면 혼합 배포판을 실행하는 시스템이 됩니다.

note: type: Content of: <chapter><section><section><para>
en: It might be best in some situations to just fully upgrade to the new distribution running <command>apt full-upgrade</command>, <command>aptitude safe-upgrade</command> or <command>aptitude full-upgrade</command>.  Read apt's and aptitude's manual pages for more information.
ko: 어떤 상황에서는 <command>apt full-upgrade</command>, <command>aptitude safe-upgrade</command> or <command>aptitude full-upgrade</command>를 실행하여 새 배포판으로 완전히 업그레이드하는 것이 가장 좋습니다 . 자세한 내용은 apt 및 aptitude의 매뉴얼 페이지 참조하세요.

note: type: Content of: <chapter><section><section><title>
en: I am currently tracking testing (&nextreleasename;). What will happen when a release is made? Will I still be tracking testing or will my machine be running the new stable distribution?
ko: 현재 testing (&nextreleasename;)을 추적하고 있습니다. 릴리스되면 어떻게 됩니까? testing을 계속 추적할 예정인가요, 아니면 내 컴퓨터에서 새로운 stable 배포판을 실행하나요?

note: type: Content of: <chapter><section><section><para>
en: It depends on the entries in the <filename>/etc/apt/sources.list</filename> file.  If you are currently tracking testing, these entries are similar to either:
ko: 그건 <filename>/etc/apt/sources.list</filename> 파일 항목에 달려있습니다. 현재 testing을 추적 중이라면, 이런 항목은 다음 중 하나와 비슷합니다:

note: type: Content of: <chapter><section><section><para>
en: or
ko: 또는

note: type: Content of: <chapter><section><section><para>
en: If the third field in <filename>/etc/apt/sources.list</filename> is 'testing' then you will be tracking testing even after a release is made.  So after &nextreleasename; is released, you will be running a new Debian distribution which will have a different codename.  Changes might not be apparent at first but will be evident as soon as new packages from unstable go over to the testing distribution.
ko: 만약 <filename>/etc/apt/sources.list</filename> 파일의 3번째 필드가 'testing'이면 릴리스 만든 후에도 testing을 추척합니다. 그래서 &nextreleasename;이 릴리스 되면, 새 데비안 배포판을 실행하는데 다른 코드명을 가질 겁니다.바뀐 사항은 처음에는 명확하지 않을 수 있지만 unstable 패키지의 새 패키지가 testing 배포판으로 넘어가는 즉시 분명해질 겁니다.

note: type: Content of: <chapter><section><section><para>
en: But if the third field contains '&nextreleasename;' then you will be tracking stable (since &nextreleasename; will then be the new stable distribution).
ko: 그러나, 3째 필드에 '&nextreleasename;'가 들어있으면 stable을 추적합니다.(왜냐면 &nextreleasename;가 새 stable 배포판이 되므로)

note: type: Content of: <chapter><section><section><title>
en: I am still confused. What did you say I should install?
ko: 아직 헷갈립니다. 무엇을 설치해야 한다고 했나요?

note: type: Content of: <chapter><section><section><para>
en: If unsure, the best bet would be the stable distribution.
ko: 불확실하다면, stable 배포판이 좋습니다.

note: type: Content of: <chapter><section><title>
en: But what about Knoppix, Linux Mint Debian Edition, Ubuntu, and others?
ko: 그러나 Knoppix, 리눅스 민트 데비안 판, 우분투 등은 무엇인가요?

note: type: Content of: <chapter><section><para>
en: They are not Debian; they are <emphasis>Debian based</emphasis>.  Though there are many similarities and commonalities between them, there are also crucial differences.
ko: 그건 데비안이 아닙니다. <emphasis>데비안 기반</emphasis>입니다. 비슷한 점 및 공통점이 있지만 결정적 차이도 있습니다.
