GUI보다 명령 줄을 선호하는 이유는 무엇입니까?

다른 기사를 검토하면서 저에게 많은 재미를 준이 작은 질문을 발견했습니다. 다른 시스템 (FreeBSD 제외)의 사용자가 가장 먼저 느끼는 것 중 하나는 GUI를 사용하지 않는다는 것입니다. 사실을 말하면 GNU / 리눅스 여정을 시작할 때도 꽤 궁금해 보였습니다. 나는 시간이 지남에 따라 다른 GUI 프로그램보다 명령 줄을 훨씬 더 많이 사용하고 있으며, 눈부신 GUI를 가진보다 정교한 프로그램보다 명령 줄 프로그램을 선호하는 경우가 많다는 사실을 인정해야합니다.

신화

실제로 이것은 도시 신화에 지나지 않습니다. 여기에 이름이 언급되지 않은 다른 시스템과는 달리 GNU / Linux에 있습니다. 자유 선택. 다른 시스템에서 여기에 존재하는 다재다능 함이 있었으면합니다. 그러나이 문제를 자세히 살펴 보겠습니다. 그렇지 않으면 많은 것이 명확하지 않습니다.

서버

우리는 모두 그 말씀을 들었습니다 섬기는 사람, 어떤 사람들은 그들이 구글이나 아마존을 구동하는 슈퍼 컴퓨터 나 당신 회사의 슈퍼 컴퓨터라고 믿습니다. 하지만 현실은 서버 에 응답 작업 모델. 이 용어는 사용자가 사용할 수있는 프로그램이 있다는 사실을 나타냅니다 (고객) 무언가를 건네줍니다. 기본적인 예는 아파치, 사용되는 서브 인터넷상의 웹 페이지. 이 프로그램은 HTML을 고객 요청합니다.

이미지 서버

그러나 서버는 Google과 다른 많은 회사에서 가능하게하는 슈퍼 컴퓨터에있을 수있을뿐만 아니라 "가장 오래된"노트북도 서버, 특히 이미지에 대해 이야기 할 때. 우리 모두는 서버 기능적인 화면을 갖기 위해 랩톱에있는 이미지의 수,이 경우 서버 과 고객 그들은 같은 사람입니다. 가장 일반적인 예는 X (로 알려진 xorg-server 많은 배포판에서) 및 새로운 교체 Wayland. 우리는 조직의 이유, Wayland의 작동 방식, 이러한 훌륭한 프로젝트 뒤에 존재하는 철학에 대해 자세히 설명하지는 않겠지 만, 웹 브라우저를 가질 수 있다는 것은 그들 덕분임을 분명히 할 것입니다. Firefox 나 Chrome 또는 기타 여러 프로그램과 같은

창 관리자

창 관리자는 이미지 서버와 직접 작업하며, 창을 만들고, 수정하고, 닫는 방법을 관리 (중복을 용서)하기 때문에 작업은 "낮은"수준입니다. 일반적으로 매우 간단하며 데스크톱 환경이이를 기반으로 구축됩니다. 목록은 많지만 여기에 미니멀 한 소프트웨어, 이를 통해 이미지 서버를 상당히 기본적으로 제어 할 수 있습니다.

데스크탑 환경

이미지 서버 작동을 가능하게 할뿐만 아니라 사용자 정의 기능도 제공하는보다 전문화 된 소프트웨어 세트입니다. 이 중 가장 오래되고 무거운 것은 KDE와 GNOME이지만 LXDE 또는 Mate, Cinnamon 등과 같은 더 가벼운 환경도 있습니다.

CLI (명령 줄 인터페이스)

이미지 서버의 세계를 간략히 살펴본 후 이제 다시 주제로 넘어갑니다. CLI, 명령 줄에 의해 실행되는 모든 프로그램을 의미합니다. git, vim, weechat, 또는 다른 생각이 떠 오릅니다. 명령 줄에서 실행되지만 다음과 같은 일종의 "그래픽 인터페이스"를 표시하는 프로그램에 대해 이야기하고 있음을 알 수 있습니다. weechat o vim. 시도해 보지 않은 모든 분들에게 추천합니다. 기본적으로 하루 종일 사용합니다.

CLI가 GUI보다 나은 이유

아주 간단한 것을 시도해 봅시다 🙂 지난번에 패치 작업을하고 싶었습니다. 포티지 (젠투의 패키지 관리자). 다른 훌륭한 협업 프로젝트와 마찬가지로 코드 줄 수가 70k를 초과합니다. NinjaIDE (Portage는 Python으로 작성 됨)와 같은 IDE에서 열어 보면 곧 화면이로드되기 시작하면 컴퓨터가 매우 느려지고 (적어도 내 i7이 수행 했음) 코드를 열려고하는 것입니다. «help»의 기본 색상으로 변경합니다.

이제 똑같이 해보십시오. vim, 나는 천분의 일 초 만에로드되었고 동시에 "예쁜"색상과 다른 모든 것을 넣었습니다.

CLI는 오래 전에

여기 일부는 그 프로그램이 antiguos, 나는 그들을 부른다 건장한. 건물에 투자 한 시간을 볼 수 있다면 emacs, vim, gdb, 그리고 수백 개의 다른 콘솔 프로그램에서 코드와 기능의 양이 너무 많아서 해결하는 데 필요한 모든 것을 실제로 이미 해결했음을 알 수 있습니다. 많은 GUI CLI에서 이미 강력한 프로그램의 경우 동일한 기능을 가질 수 없습니다. 예를 들어 사용 가능한 각 하위 명령에 대한 탭을 만들었 기 때문입니다. git, 우리는 옵션 사이에서 자신을 잃을 것이고 그것은 일하기 어렵게 만들 것이기 ​​때문에 비생산적 일 것입니다.

CLI가 더 빠름

마법은 열쇠에서 시작됩니다 Tab, 이것은 터미널에서 데스크탑을 탐색 할 때 가장 친한 친구 일뿐만 아니라 올바르게 구성되어 있으면 긴 문장을 2 자 및 탭, 3 자 및 탭 또는 심지어 문자와 탭으로 줄일 수 있습니다. .

그러나 이것이 유일한 이점은 아닙니다. vim o emacs 요즘 IDE보다 학습 곡선이 약간 높지만 결국 생산성 결과는 놀랍지 만 마우스를 움직일 때 잃을 수있는 시간을 상상할 수 없다고 말할 수 있습니다. 90 %의 시간 동안 키보드에 손을 대면 집중력을 배울 수있을뿐만 아니라 키보드에 너무 많이 입력한다는 사실은 매우 민첩하고 생산적으로 만듭니다. 그리고 이제 우리는 이전 요점으로 돌아가서, 오랫동안 우리와 함께 해왔고, 이와 같은 프로그램은 이미 누군가가 생각할 수있는 모든 기능을 가지고 있습니다. vim을 사용하는 사람들에게 상당히 일반적인 말이 떠 오릅니다.

4 개 이상의 키를 사용하는 경우 더 나은 방법이있을 수 있습니다.

간단하지만 강력한 vim을 사용하면 많은 수의 키와 가능한 조합으로 모든 작업을 수행 할 수 있습니다. 하나는 학습을 멈추지 않습니다. 생산성을 높일 수 있습니다.

CLI는 완전한 제어를 제공합니다

마우스로 작업을 실행하거나 이미지 서버에서 프로그램을 실행할 때 클릭하는 순간에 실행되는 모든 추가 구성이 항상 존재하는 것은 아닙니다. 터미널에서는 이런 일이 발생하지 않습니다. 여기에서 그것이 무엇인지에 대한 절대적인 힘을 갖게됩니다. 실행 여부, 옵션 또는 범위. 시간이 지남에 따라 생각보다 적은 양이 필요하다는 것을 깨닫고 더 집중적으로 작업을 수행 할 수 있습니다.

GUI에도 자체 기능이 있습니다.

저는 우리 모두가 항상 CLI를 사용해야한다고 말하지는 않겠습니다. 그것도 이상적이 아닙니다. 저도 거의 항상 GUI를 사용하고,이 게시물을 작성하기 위해 Chrome을 사용하고, 이메일을보기 위해 Evolution을 사용합니다. 또한 사용 mutt 꽤 최근에). 그리고 저는 이것이 가장 큰 신화라고 생각합니다 ... 사람들은 GNU / 리눅스가 그들을 그냥 종료한다고 생각합니다. 저는 제 데스크탑 환경을 좋아하고, 상당히 미니멀하지만 그런 식으로 좋아합니다 🙂 그리고 저는 보통 XNUMX ~ XNUMX 개만 가지고 있습니다. 실행중인 프로그램, 내 Chrome, 내 Evolution 및 내 터미널 🙂

이것들은 내가 CLI를 너무 좋아하는 이유 중 몇 가지이고 시도해 보도록 초대하는 이유입니다. 그들은 나중에 GUI보다 더 많은 CLI를 사용하여 나처럼 끝날 수 있습니다 😉 인사말


기사의 내용은 우리의 원칙을 준수합니다. 편집 윤리. 오류를보고하려면 여기에.

17 코멘트, 당신의 것을 남겨주세요

코멘트를 남겨주세요

귀하의 이메일 주소는 공개되지 않습니다. 필수 필드가 표시되어 있습니다 *

*

*

  1. 데이터 책임자 : Miguel Ángel Gatón
  2. 데이터의 목적 : 스팸 제어, 댓글 관리.
  3. 합법성 : 귀하의 동의
  4. 데이터 전달 : 법적 의무에 의한 경우를 제외하고 데이터는 제 XNUMX 자에게 전달되지 않습니다.
  5. 데이터 저장소 : Occentus Networks (EU)에서 호스팅하는 데이터베이스
  6. 권리 : 귀하는 언제든지 귀하의 정보를 제한, 복구 및 삭제할 수 있습니다.

  1.   익명

    «좋은 협업 프로젝트와 마찬가지로 코드 라인 수는 70k를 초과합니다. 이 부분은 나를 너무 시끄럽게 만들었습니다. 동일한 파일에서 코드를 압축해야하는 기술적 불가능한 이유가 있습니까? 다른 엔티티 (파일 / 클래스 / 모듈)에서 동작을 분리하는 것이 더 낫지 않습니까?
    하나의 기술을 다른 기술보다 강요하고 개발 형태의 부족으로 인해 제안하는 이점을 제쳐두는 것은 타당한 이유가 아닌 것 같습니다. 어쨌든 나는 그것이 어떤 특정 프로젝트를 가리키는 지 모른 채 이야기하고 있는데, 그 작업 방식을 강요하는 더 큰 원인이 있습니다

    1.    크리스ADR

      안녕하세요

      글쎄, 아마도 이것은 약간의 설명이 필요하지만, 내가 "좋은 프로젝트"라고 부르는 것은 줄의 숫자가 그것이 계속 성장하는 건강한 커뮤니티임을 표현한다는 것을 의미합니다. 훨씬 적은 수의 라인을 가진 프로젝트가 있지만 개발은 상당히 건전합니다. 사실을 말하기 위해 포티지는 가능한 한 많은 파일로 나뉘어져 있지만 라이브러리 나 다른 기능으로 이끄는 스위치처럼 부분을 함께 묶어 두는 것이 항상 필요합니다. 그러나 오늘날 많은 IDE로 프로젝트를 가져올 때 이는 프로젝트의 모든 파일을 읽고 올바른 "시각적"형식을 넣으려고한다는 것을 의미합니다.

      좀 더 명확하게 🙂 해주셔서 감사합니다.
      안부

  2.   익명

    명령 줄을 사용하십니까? 예,하지만 해당되는 경우에만 가능합니다. 즉, 더 편안하고 빠를 때입니다. 예를 들어, 특정 프로그램을 설치하려면 소프트웨어 관리자를 열고 검색하고 설치하도록 표시하고 "설치"를 누르는 것보다 sudo apt install programname을 입력하는 것이 더 편리합니다. 그러나 일반적으로 이것은 사실이 아닙니다. 예를 들어, 내가 가장 좋아하는 20 곡을 한 디렉토리에서 다른 디렉토리로 복사하려면 Ctrl + 클릭을 수행하는 것이 매우 편리하며 파일 관리자에서 방대한 목록을 차분하게 검토 한 다음 끌어서 놓는 것이 좋습니다. 또 다른 예 : 디스크를 분할하려면 수동으로 수행하는 것보다 gparted (다양한 명령을 실행하는 프로그램)를 통해 수행하는 것이 훨씬 낫습니다. 목록은 끝이 없을 수 있습니다. GUI는 (사실 일반적으로) 주어진 cli 애플리케이션에 대해 불가능할 수있는 기능을 추가하는 것 외에도 작업을 훨씬 쉽게 만들 수 있습니다.

    1.    크리스ADR

      그것은 명령 줄이 얼마나 편한지에 달려 있습니다 ... 예를 들면 :

      find dir/musica -name "archivo" -exec grep cp {} dir/nuevo \;

      bash에서 약간의 마술을 사용하면 노래 이름을 입력하는 것만으로도 동일한 기능을 수행 할 수 있습니다.

      같은 것

      mover(){
      find dir/musica -name $1 -exec grep cp {} dir/nuevo \;
      }

      그리고 준비! 간단하게 모든 노래를 이동할 수 있습니다.

      mover cancion1.mp3

      🙂 두 번째 부분에서는 GUI가 명령을 기억하고 반복하는 것을 피하여 작업을 "단순"하게 만들지 만, 이것은 일반 프레임 워크에서만 유용합니다. 특수한 것이 필요할 때, gparted 또는 기타 GUI가 짧을 수 있습니다 🙂 및 GUI 추가 기능을 추가하지 말고 CLI에 존재하는 기능 만 취하고 (모두는 아님) 그룹화하지만 crean을 만들지는 않습니다.

      안부

      1.    익명

        프로세스가 얼마나 자동화 되었든 상관 없습니다 :
        이동 song1.mp3

        그러면 반드시 다음이있을 것입니다.
        이동 song2.mp3
        이동 song3.mp3
        .
        .
        .
        이동 song20.mp3
        움직이는 노래가 많이 있습니다 ...
        모든 파일 관리자로 .. 20 번의 클릭과 드래그 앤 드롭 제스처 만 있으면됩니다. 잘 모르겠지만 적어도 제 매니저 (돌핀)는 이름, 날짜, 크기, 태그, 순위, 앨범, 아티스트, 재생 시간별로 5 곡의 목록을 간단하고 초고속 (100 초 미만) 정렬 할 수있게 해줍니다. 등은 저에게 PRODUCTIVITY이며 명령 줄에 기능을 추가하고 있습니다.

        다른 예는 .. GParted : OK .. 포맷 할 때 inode 당 기본값을 변경하는 것과 같은 매우 전문적인 것이 필요하면 콘솔로 이동해야합니다. .. 친구, 그것은 정상이 아닙니다. 99 %의 시간 동안 GParted는 매우 간단하고 빠른 방법으로 우리의 요구를 완벽하게 충족시킬 것이며, 적어도 저에게는 생산성도 마찬가지입니다.

        안부

        1.    크리스ADR

          "가장 좋아하는 20 곡을 한 디렉토리에서 다른 디렉토리로 복사하려면"이라고 말했듯이 가장 간단한 형태의 자동화 예입니다.이 모든 것은 "침착하게"하는 데 걸리는 시간과 함께 중요합니다. 목록을 검토하십시오. 주문하고 클릭 등을 한 후 터미널은 한 줄로 훨씬 더 많은 것을 허용합니다 (오래된 경우에도 프로세서에서 약 0.1 초 실행), 눈과 마우스가이를 극복 할 수 있다면 , 글쎄, 나는 GUI로 갈거야 🙂 그리고 내가 그것들을 사용하지 않는다고 말한 것이 아니라 유용한 것이 많고 부정하지 않을 것이지만 적어도 터미널에서 훨씬 더 다양한 기능을 발견했습니다. 작업을 자동화 할 때 매일 약간의 프로그래밍을 연습하도록 도와줍니다. SysAdmins 사이에서 매우 일반적인 말은 "하루에 한 번 이상 같은 일을하면 자동화하고, XNUMX 일 이상 하루에 한 번 수행하면 자동화하고, 한 달에 한 번만 수행하면 자동화합니다. . "

          하지만 취향과 색상의 측면에서 각각 고유 한 것이 있습니다. 저는 제가 좋아하는 것을 공유하는 것으로 제한하고 있습니다. emacs, vim 또는 동일한 터미널과 같은 것을 "두려워하는"사람들이 많을 수도 있습니다. ,이 게시물을 통해 나는 당신이 시도하고 결정할 수 있도록 약간의 자신감과 호기심을 제공하려고 노력하고 있습니다 🙂

          안부

          추신 : 나는 일상 생활에서 요구하는 복잡성 때문에 GUI가 문제를 해결하지 못하는 많은 개발자를 알고 있습니다. 아마도 "일반적인"사용자는 결코 보지 못할 것입니다. 그러나 이것이 더 많은 "공통"을 의미하지는 않습니다. "이러한 도구를 사용하여 동일한 더 다양한 이점을 얻을 수 있습니다.

          1.    익명

            나는 여전히이 작업 (및 다른 많은 작업)에서 명령 줄보다 파일 관리자를 사용하는 데 훨씬 더 적은 시간이 소요된다고 생각합니다 ...하지만 모든 사람에게 취향과 색상이 있다고 말했듯이.

            나는 터미널을 부정하거나 두려워하지 않지만 거의 필수 문장으로 보지 않기 때문에 "명령 줄 예,하지만 적절할 때"라고 말하면서 시작했습니다.

            개발자에게는 모든 것이 있지만 규모는 명확하게 한쪽으로 기울어집니다. 다음을 살펴 보시기 바랍니다.

            https://pypl.github.io/IDE.html

            "일반적인"개발자는 "텍스트 전용"편집기로 작업하는 것에 베팅하는 사람들과 비교해 보면 시설이 가득한 그래픽 환경에서 작업하는 것의 이점을 느끼는 것 같습니다.

    2.    당신은 태워

      예를 들어, 내가 가장 좋아하는 20 곡을 한 디렉토리에서 다른 디렉토리로 복사하려면 Ctrl + 클릭을 수행하는 것이 매우 편리합니다. 파일 관리자에서 방대한 목록을 차분하게 검토 한 다음 끌어서 놓습니다.

      Vifm 또는 Ranger와 같이 실용적이거나 그래픽 이상인 명령 줄 파일 관리자가 있습니다. 또한 디스크 분할을 위해 e ncurses 인터페이스가있는 cgdisk와 같은 명령 줄 응용 프로그램이 있습니다.

      1.    크리스ADR

        글쎄, 사실입니다 🙂 터미널을 두려워하는 사람들이 왜 그렇게 많은지 정말 모르겠습니다. 실제로는 매우 강력하고 다재다능한 도구입니다. 모든 사람이 적어도 한 번은 깊이 시도해야합니다.

        나눔과 인사에 감사드립니다.

      2.    익명

        예, 터미널 파일 관리자는 그래픽보다 먼저 존재합니다. 실용성은 당신이 원하는 것에 달려 있습니다. 모든 그래픽 파일 관리자에는 탭, 즐겨 찾기,보기 모드, 미리보기, 1000 가지 다른 방법으로 주문 가능, 터미널 연결, 플러그인 설치 등이 제공됩니다. 어떤 텍스트 파일 관리자보다 훨씬 더 다양하게 사용할 수 있습니다.

        선이 반드시 추악 할 필요는 없다

    3.    츄피35

      그것은 당신이 cli에서하는 일을 배우는 것입니다. 그리고 저는 그것이 더 쉬울 것이라는 것을 보증합니다. 당신이 언급 한 것은 rsync로 매우 쉽게 할 수 있고 스크립트로 쉽게 할 수 있습니다.

      당신이 언급 한 모든 것이있는 ranger라는 cli 파일 관리자를 추천합니다.

  3.   알베르토 카르 도나

    훌륭한!!
    여전히 Gentoo를 설치할지 결정할 수 없습니다.
    하지만 Vim이나 Emacs에 도전하고 싶게 만듭니다!
    안부
    나는 당신의 게시물을 읽는 것을 좋아합니다

    1.    크리스ADR

      Alberto 대단히 감사합니다 🙂 제 기사가 마음에 들어서 기쁩니다. 게시물 작성을 좋아합니다.
      나는 당신이 응원하고 물론 그렇게하기를 바랍니다. 항상 새로운 것을 시도하는 것입니다 🙂

  4.   크리스ADR

    글쎄, 이것으로 나는 마지막 두 코멘트에 대한 대답을 마치고 나는 그것에 대해 더 많은 것을 받아들이지 않는 중재자들에게 감사 할 것입니다. 이것은 아무데도 가지 않고 코멘트 목록을 일련의 찬성 또는 반대 주장으로 채우지 않는 것입니다. 다른 하나.

    "다재다능 함"에 관해서는 아마도 GUI에만 플러그인이 있다고 생각하는 사람이 있겠지만 사실은 터미널 플러그인이 사용하는 사람들만큼 다양하고 기능적이라는 것입니다. 가장 명확한 예는 다음과 같습니다.

    https://vimawesome.com/

    거의 끝이없는 vim 용 플러그인 목록으로 많은 IDE보다 더 다양하게 사용할 수 있습니다.이 링크에는 Windows 및 Mac에서 IDE를 사용하는 사람들이 포함되어 있다는 사실이 언급되지 않습니다. 실제로 Vim에 대해 훨씬 잘 설명합니다. 이클립스 세 가지 플랫폼에서 이클립스를 사용하는 사람들의 수를 비교하면 Vim이 4 위를 차지하는 것을 부끄러워 할 것이 없기 때문입니다.

    그러나 조금 더 나아가 ... "일반적인"사람들이 무언가를 사용한다고해서 이것이 반드시 좋다고 말하는 것은 아니지만 아마도 Windows가 다른 시스템보다 훨씬 더 좋을 것입니다. 🙂 아마도 그들은 무언가를 사용하는 방법을 배우지 않기를 원할 것입니다. 그들은 쉬운 옵션을 선호합니다 ... 또는 귀사가 표준을 구현하기로 결정했기 때문에 (Eclipse는 많은 회사의 표준이므로 많은 사용자를 설명합니다 ... 유일한 Android 및 Visual Studio와 마찬가지로 각각의 언어로 작업하는 것을 의미합니다 ... 반면 Vim은 그것을 사용하는 사람들의 무료 선택입니다)

    . "Ugly"는 매우 주관적인 용어입니다. Qt, WebKit 또는 Mac OS 인터페이스의 디자인을 "추악한"것으로 간주 할 수 있습니다.하지만 다른 사람이 그런 식으로 보는 것은 아닙니다. 습관 umbres

    안부

    1.    익명

      나는 답변 할 권리를주고 싶지 않다는 욕구를 존중합니다.

      정보 용 :
      https://vim.sourceforge.io/download.php

  5.   클라우디오

    저는 Anonymous에 전적으로 동의하지만 제 경우에는 분석 가나 프로그래머에 대한 깊은 지식이없는 단순한 사용자입니다. 예를 들어 오늘과 2017 년이되자 리눅스 네트워크에서 폴더를 쉽게 공유 할 수있는 GUI 응용 프로그램이 없어서 Linux의 많은 보물을 실패하려면 GUI가 필요합니다. Samba와 Windows에서는 순전히 Linux 네트워크에 대해 이야기하고 있습니다. Linux 네트워크에서 공유 할 수 있으려면 특정 NFS를 구성해야하며 명령 줄에서만 시간이 낭비되며 Windows 에서처럼 쉽게 GUI를 사용하는 것이 왜 그렇게 어려운지 설명하지 않습니다. .
    ChrisADR에 따르면 "나는 젊은 소프트웨어 개발자입니다."라는 주제에 대해 많이 알고 있다는 것을 알 수 있습니다. 방금 설명한 내용을 용이하게하는 GUI 응용 프로그램을 개발해야합니까? 의사가 수술을 한 번도하지 않은 상태에서 수술을하는 것이 어떻게 더 나은지에 대한 의견을 제시 한 것과 같습니다. «핑 고는 법원에서 볼 수 있습니다»«소프트웨어 개발자»의 자리에서 의견을 제공하기 전에 GUI 응용 프로그램을 개발해야하며, 터미널을 사용하는 것이 더 낫거나 사용하지 않는 경우에는 누가 사용하는지 자리에 두어야합니다. 리눅스와 그것을 사용하는 사람. Linux 네트워크에서 파일 공유를 위해 GUI 애플리케이션을 제시하고 공유하는 ChrisADR의 기사를 볼 수 있기를 바랍니다. Windows 공유를 위해 Samba를 사용하지 않는 한 현재로서는 아무것도 없습니다.

    1.    길레

      프로그램을 만드는 것은 어느 날 오후에 쉬운 일이 아닙니다. 적어도 몇 주 정도의 노력이 필요하며 더 나쁜 것은 이전에 사용했던 라이브러리를 쓸모 없게 만드는 새로운 함수 라이브러리와 함께 오류를 수정하고 업데이트하는 데 수년이 걸립니다. ., 다양한 배포판을위한 포장, ...
      하지만 이미 SAMBA가있어서 Windows 없이도 두 GNU / Linux간에 사용할 수있는 경우 NFS 솔루션을 사용하고 싶은 이유는 무엇입니까?
      인터넷에서 볼 수있는 매뉴얼은 리눅스와 윈도우에 대해 이야기하고 있지만 지침에 따라 리눅스에서 폴더를 공유 한 다음 리눅스에서 다른 네트워크 폴더로도 연결하면됩니다.
      Ubuntu 16.04에는 여전히이 테마를 쉽게 구현할 수있는 것 같습니다. http://www.hernanprograma.es/ubuntu/como-compartir-una-carpeta-desde-ubuntu-16-04-a-traves-de-samba/