"সবকিছুই একটি ফাইল" কিছুটা গ্লিব। " ফাইল সিস্টেমে সমস্ত কিছু কোথাও উপস্থিত হয় " চিহ্নের কাছাকাছি এবং তারপরেও এটি সিস্টেম ডিজাইনের আইনের চেয়ে আদর্শ।
উদাহরণস্বরূপ, ইউনিক্স ডোমেন সকেটগুলি ফাইল নয় তবে সেগুলি ফাইল সিস্টেমে প্রদর্শিত হয়। আপনি ls -lএর বৈশিষ্ট্যগুলি প্রদর্শন করতে একটি ডোমেন সকেট করতে পারেন , catএকটিকে / থেকে ডেটা, এর মাধ্যমে অ্যাক্সেস নিয়ন্ত্রণ পরিবর্তন করতে পারেন chmodইত্যাদি etc.
কিন্তু, যদিও নিয়মিত করে TCP / IP নেটওয়ার্ক সকেট তৈরি করেছেন এবং একই সঙ্গে কাজে ব্যবহৃত হয় বাসদ সকেট সিস্টেম ইউনিক্স ডোমেইন সকেট যেমন কল, বিভিন্ন TCP / IP এর সকেট না না আপ ফাইল সিস্টেম দেখানোর, ¹ যদিও যে এই উচিত কোন বিশেষত ভাল কারণ নেই সত্যবাদী হও.
ফাইল সিস্টেমে নন-ফাইল অবজেক্টগুলির আরেকটি উদাহরণ হ'ল লিনাক্সের /procফাইল সিস্টেম । এই বৈশিষ্ট্যটি ব্যবহারকারীর স্পেসে কার্নেলের রান-টাইম অপারেশন সম্পর্কে বেশিরভাগ বিশদ প্রকাশ করে, বেশিরভাগ ভার্চুয়াল প্লেইন ফাইল হিসাবে। অনেকগুলি /procএন্ট্রি কেবল পঠনযোগ্য, তবে অনেকগুলি /procরচনাযোগ্যও হয়, যাতে কোনও ফাইল পরিবর্তন করতে পারে এমন কোনও প্রোগ্রাম ব্যবহার করে সিস্টেমটি যেভাবে চালায় সেগুলি আপনি পরিবর্তন করতে পারেন। হায়রে, এখানে আবার আমাদের একটি অদৃশ্যতা রয়েছে: বিএসডি টাইপ ইউনিক্সগুলি সাধারণত ছাড়াই চলে/proc এবং সিস্টেম ভি ইউনিক্সগুলি /procলিনাক্সের চেয়ে অনেক কম প্রকাশ করে।
আমি এমএস উইন্ডোজের সাথে এর বিপরীতে পারছি না
প্রথমত, ইউনিক্স সম্পর্কে ফাইলগুলি I / O এবং উইন্ডোজকে "ভাঙা" হওয়া সম্পর্কে ফাইলগুলি সম্পর্কে অনলাইনে এবং বইগুলিতে আপনি বেশিরভাগ অনুভূতি অপ্রচলিত। উইন্ডোজ এনটি এটির অনেকগুলি স্থির করে।
উইন্ডোজের আধুনিক সংস্করণগুলিতে ইউনিক্সের মতোই একটি ইউনিফাইড আই / ও সিস্টেম রয়েছে, আপনি চাইলে ReadFile()উইন্ডোজ সকেট নির্দিষ্ট এপিআইয়ের পরিবর্তে টিসিপি / আইপি সকেটের মাধ্যমে নেটওয়ার্ক ডেটা পড়তে পারেন WSARecv()। এটি ইউনিক্স ওয়েয়ের ঠিক সমান্তরাল , যেখানে আপনি জেনেরিক read(2)ইউনিক্স সিস্টেম কল বা সকেট-নির্দিষ্ট কল সহ কোনও নেটওয়ার্ক সকেট থেকে পড়তে পারেন recv(2)²
তবুও, উইন্ডোজ এখনও এই ধারণাটি ইউনিক্সের মতো একই স্তরে নিয়ে যেতে ব্যর্থ হয়েছে, এমনকি এখানে 2018 সালেও। কিছু উদাহরণ:
ড্রাইভার।
উইন্ডোজের ড্রাইভার সাবসিস্টেমটি ইউনিক্সের মতো সহজেই সমৃদ্ধ এবং শক্তিশালী, তবে ড্রাইভারগুলি চালিত করতে প্রোগ্রাম লিখতে আপনাকে সাধারণত উইন্ডোজ ড্রাইভার কিট ব্যবহার করতে হয় , যার অর্থ সি বা .NET কোড লেখা।
ইউনিক্স টাইপ ওএসে, আপনি কমান্ড লাইন থেকে চালকদের অনেক কিছু করতে পারেন। আপনি প্রায় অবশ্যই ইতিমধ্যে এটি সম্পন্ন করেছেন, যদি কেবলমাত্র অযাচিত আউটপুট /dev/null³
আন্ত: প্রোগ্রাম যোগাযোগ।
উইন্ডোজ প্রোগ্রামগুলি একে অপরের সাথে সহজে যোগাযোগ করে না।
ইউনিক্স কমান্ড লাইন প্রোগ্রামগুলি পাঠ্য স্ট্রিম এবং পাইপগুলির মাধ্যমে সহজে যোগাযোগ করে। জিইউআই প্রোগ্রামগুলি প্রায়শই হয় কমান্ড লাইন প্রোগ্রামের শীর্ষে নির্মিত হয় বা একটি পাঠ্য কমান্ড ইন্টারফেস রফতানি করে, যাতে একই সাধারণ পাঠ্য-ভিত্তিক যোগাযোগ ব্যবস্থা জিইউআই প্রোগ্রামগুলির সাথেও কাজ করে।
রেজিস্ট্রি।
ইউনিক্সের উইন্ডোজ রেজিস্ট্রির কোনও সরাসরি সমতুল্য নেই। একই তথ্য, এটা অধিকাংশ ফাইলসিস্টেম মাধ্যমে বিক্ষিপ্ত হয় /etc, /procএবং /sys।
আপনি যদি দেখতে না পান যে ড্রাইভার, পাইপ এবং ইউনিক্সের উইন্ডোজ রেজিস্ট্রিতে উত্তরটির "" সমস্ত কিছুই একটি ফাইল, "এর সাথে কিছু করার আছে।
"সবকিছুই একটি ফাইল" দর্শনের এখানে কীভাবে পার্থক্য রয়েছে?
আমি উপরের আমার তিনটি পয়েন্টটি বিস্তারিতভাবে প্রসারিত করে ব্যাখ্যা করব।
দীর্ঘ উত্তর, অংশ 1: ড্রাইভ বনাম ডিভাইস ফাইল
ধরা যাক আপনার সিএফ কার্ড রিডারটি E:উইন্ডোজ এবং /dev/sdcলিনাক্সের অধীনে প্রদর্শিত হবে । এটি ব্যবহারিক পার্থক্য কি করে?
এটি কেবল একটি ছোটখাট সিনট্যাক্স পার্থক্য নয়।
লিনাক্স-এ, আমি শূন্যগুলি সহ dd if=/dev/zero of=/dev/sdcসামগ্রীগুলি ওভাররাইট করতে বলতে পারি /dev/sdc।
এটি একটি সেকেন্ডের জন্য কী বোঝায় তা ভেবে দেখুন। এখানে আমার কাছে একটি সাধারণ ব্যবহারকারীর স্পেস প্রোগ্রাম রয়েছে ( dd(1)যা আমি ভার্চুয়াল ডিভাইস ( /dev/zero) থেকে ডেটা পড়তে /dev/sdcএবং ইউনিফাইড ইউনিক্স ফাইল সিস্টেমের মাধ্যমে এটি একটি প্রকৃত শারীরিক ডিভাইসে ( ) পড়তে লিখতে বলেছি । ddজানে না যে এটি পড়ছে এবং বিশেষ ডিভাইসে লেখা হচ্ছে। এটি নিয়মিত ফাইলগুলিতে ঠিক পাশাপাশি কাজ করবে বা ডিভাইস এবং ফাইলগুলির মিশ্রণে কাজ করবে, যেমন আমরা নীচে দেখব।
E:উইন্ডোজে ড্রাইভটি শূন্য করার কোনও সহজ উপায় নেই , কারণ উইন্ডোজ ফাইল এবং ড্রাইভের মধ্যে একটি পার্থক্য তৈরি করে, তাই আপনি সেগুলি ব্যবহারের জন্য একই আদেশগুলি ব্যবহার করতে পারবেন না। আপনি যে নিকটস্থ এটি পেতে পারেন তাড়াতাড়ি বিন্যাস বিকল্প ব্যতীত একটি ডিস্ক ফর্ম্যাট করা, যা বেশিরভাগ ড্রাইভের বিষয়বস্তুগুলিকে শূন্য করে , তবে তারপরে একটি নতুন ফাইল সিস্টেম লিখে। আমি যদি নতুন ফাইল সিস্টেমটি না চাই ? আমি যদি সত্যিই চাই যে ডিস্কটি শূন্য ছাড়া আর কিছু না ভরা হোক?
আসুন উদার হোন এবং বলুন যে আমরা সত্যই একটি নতুন ফাইল ফাইল চালু করতে চাই E:। উইন্ডোজের কোনও প্রোগ্রামে এটি করতে, আমাকে একটি বিশেষ ফর্ম্যাটিং এপিআই কল করতে হবে ⁴ লিনাক্সে, আপনাকে ওএসের "ফর্ম্যাট ডিস্ক" কার্যকারিতা অ্যাক্সেস করার জন্য কোনও প্রোগ্রাম লেখার দরকার নেই। আপনি শুধু ফাইল-সিস্টেমের ধরন আপনার তৈরি করতে চান তাদের জন্য উপযুক্ত ক্ষেত্রে ব্যবহারকারীদের স্থান প্রোগ্রাম চালানো: mkfs.ext4, mkfs.xfs, বা কি আপনার আছে। এই প্রোগ্রামগুলি আপনি যে কোনও ফাইল বা /devনোড পাস করে তাতে একটি ফাইল সিস্টেম লিখবে ।
কারণ mkfsUnixy সিস্টেমে টাইপ প্রোগ্রাম ডিভাইস এবং স্বাভাবিক ফাইল মধ্যে কৃত্রিম প্রভেদ না করে ফাইল কাজ করে, এটা মানে আমি একজন তৈরি করতে পারেন ext4 ফাইল-সিস্টেমটি আমার লিনাক্স বাক্সে সাধারন ফাইল ভিতরে:
$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs
এটি আক্ষরিকভাবে বর্তমান ডিরেক্টরিতে 1 এমআইবি ডিস্ক চিত্র তৈরি করে, যাকে বলে myfs। আমি তখন এটিকে মাউন্ট করতে পারি যেন এটি অন্য কোনও বাহ্যিক ফাইল সিস্টেমের মতো:
$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint
এখন আমার কাছে একটি ফাইল নামক একটি ext4 ডিস্ক চিত্র my-passwd-entryরয়েছে যার মধ্যে আমার ব্যবহারকারীর /etc/passwdপ্রবেশ রয়েছে।
যদি আমি চাই, আমি আমার সিএফ কার্ডের মাধ্যমে ছবিটি ব্লাস্ট করতে পারি:
$ sudo dd if=myfs of=/dev/sdc1
বা, আমি সেই ডিস্ক চিত্রটি প্যাক করে রাখতে পারি, এটি আপনাকে মেল করতে পারি এবং আপনাকে এটি আপনার পছন্দসই একটি মিডিয়ামে লিখতে দেয় , যেমন একটি ইউএসবি মেমরি স্টিক:
$ gzip myfs
$ echo "Here's the disk image I promised to send you." |
mutt -a myfs.gz -s "Password file disk image" you@example.com
এই সমস্ত কিছুই লিনাক্স⁵ এ সম্ভব কারণ ফাইল, ফাইল সিস্টেম এবং ডিভাইসগুলির মধ্যে কোনও কৃত্রিম পার্থক্য নেই। ইউনিক্স সিস্টেমে অনেক কিছুই পারেন হয় ফাইল, অথবা ফাইল সিস্টেম মাধ্যমে ব্যবহার করা হয় যাতে তারা মত চেহারা ফাইল, অথবা অন্য কোনো উপায় চেহারা পর্যাপ্ত ফাইল মত যে তারা যেমন সারিয়ে তোলা যায়।
উইন্ডোজ ফাইল ফাইলের ধারণাটি একটি হজপড; এটি ডিরেক্টরি, ড্রাইভ এবং নেটওয়ার্ক সংস্থানগুলির মধ্যে পার্থক্য তৈরি করে। উইন্ডোজে তিনটি পৃথক বাক্য গঠন রয়েছে, সবগুলি একত্রে মিশ্রিত: ইউনিক্সের মতো ..\FOO\BARপাথ সিস্টেম, ড্রাইভের মতো অক্ষর C:এবং ইউএনসি পাথের মতো \\SERVER\PATH\FILE.TXT। এটি একক সুসংগত ডিজাইনের পরিবর্তে ইউনিক্স, সিপি / এম , এমএস-ডস এবং ল্যান ম্যানেজারের কাছ থেকে ধারণাগুলির স্বীকৃতি because এই কারণেই উইন্ডোজ ফাইলের নামে অনেকগুলি অবৈধ অক্ষর রয়েছে ।
ইউনিক্সের একটি ইউনিফাইড ফাইল সিস্টেম রয়েছে, যা একটি সাধারণ প্রচলিত স্কিম দ্বারা অ্যাক্সেস করা সমস্ত কিছু রয়েছে। লিনাক্স বক্স চলমান একটি প্রোগ্রাম করতে, মধ্যে কোন কার্মিক পার্থক্য নেই /etc/passwd, /media/CF_CARD/etc/passwdএবং /mnt/server/etc/passwd। স্থানীয় ফাইল, বাহ্যিক মিডিয়া এবং নেটওয়ার্ক শেয়ারগুলি সমস্ত একইরূপে আচরণ করে ⁶
উইন্ডোজ উপরে আমার ডিস্ক চিত্রের উদাহরণের অনুরূপ প্রান্তগুলি অর্জন করতে পারে, তবে আপনাকে অস্বাভাবিক মেধাবী প্রোগ্রামারদের দ্বারা রচিত বিশেষ প্রোগ্রামগুলি ব্যবহার করতে হবে। এই কারণেই উইন্ডোজটিতে অনেকগুলি "ভার্চুয়াল ডিভিডি" টাইপ প্রোগ্রাম রয়েছে । একটি মূল ওএস বৈশিষ্ট্যের অভাব কর্মসূচিগুলি পূরণ করার জন্য একটি কৃত্রিম বাজার তৈরি করেছে, যার অর্থ আপনার কাছে প্রচুর লোকেরা সেরা ভার্চুয়াল ডিভিডি টাইপ প্রোগ্রাম তৈরির জন্য প্রতিযোগীতা করছে ing আমাদের * আইএক্স সিস্টেমে এ জাতীয় প্রোগ্রামগুলির দরকার নেই, কারণ আমরা কেবল একটি লুপ ডিভাইস ব্যবহার করে কোনও আইএসও ডিস্ক চিত্র মাউন্ট করতে পারি ।
ডিস্ক মোছা প্রোগ্রামগুলির মতো অন্যান্য সরঞ্জামগুলির ক্ষেত্রেও এটি একই রকম হয় , যার ইউনিক্স সিস্টেমে আমাদেরও প্রয়োজন হয় না। আপনার সিএফ কার্ডের বিষয়বস্তুগুলি কেবল শূন্যের পরিবর্তে অনিবার্যভাবে স্ক্র্যাম্বল করতে চান? ঠিক আছে, এর /dev/randomপরিবর্তে ডেটা উত্স হিসাবে ব্যবহার করুন /dev/zero:
$ sudo dd if=/dev/random of=/dev/sdc
লিনাক্সে, আমরা এই জাতীয় চাকার পুনরায় উদ্দীপনা রাখি না কারণ মূল ওএস বৈশিষ্ট্যগুলি কেবল যথেষ্ট পরিমাণে কাজ করে না, তারা এত ভালভাবে কাজ করে যে সেগুলি ব্যাপকভাবে ব্যবহার করা হচ্ছে। লিনাক্স বক্স বুট করার জন্য একটি সাধারণ স্কিমের মধ্যে ভার্চুয়াল ডিস্ক চিত্র অন্তর্ভুক্ত রয়েছে, কেবলমাত্র একটি উদাহরণ হিসাবে, আমি উপরে দেখানোর মতো কৌশলগুলি ব্যবহার করে তৈরি করেছি ⁷
আমি মনে করি এটা নির্দেশ করে ইউনিক্স শুরু থেকে ফাইলসিস্টেম একত্রিত করেছিলেন TCP / IP এর ইনপুট / আউটপুট, আমরা হতো না শুধুমাত্র ন্যায্য netcatবনাম socatবনাম Ncatবনাম জগাখিচুড়ি , কারণ যা একই নকশা দুর্বলতা ছিল যে সীসা উইন্ডোতে ডিস্ক ইমেজিং এবং ওয়াইপিং সরঞ্জাম প্রসারণ: একটি গ্রহণযোগ্য ওএস সুবিধার অভাব।nc
দীর্ঘ উত্তর, অংশ 2: ভার্চুয়াল ফাইল হিসাবে পাইপ
ডসটিতে এর শিকড় থাকা সত্ত্বেও উইন্ডোজের কখনও সমৃদ্ধ কমান্ড লাইনের hadতিহ্য ছিল না।
এই বলে নয় যে উইন্ডোজ না আছে একটি কমান্ড লাইন, অথবা এটি অনেক কমান্ড লাইন প্রোগ্রাম অভাব আছে যে। উইন্ডোজগুলির আজকাল খুব শক্তিশালী কমান্ড শেল রয়েছে, যাকে যথাযথভাবে পাওয়ারশেল বলা হয় ।
তবুও, কমান্ড-লাইনের lackতিহ্যের এই অভাবের প্রভাব রয়েছে kn আপনি DISKPARTউইন্ডোজ বিশ্বে প্রায় অচেনা এমন সরঞ্জামগুলি পান কারণ বেশিরভাগ লোকেরা কম্পিউটার ম্যানেজমেন্ট এমএমসি স্ন্যাপ-ইন এর মাধ্যমে ডিস্ক বিভাজন এবং এ জাতীয় কাজ করে। তারপরে আপনার যখন পার্টিশন তৈরির স্ক্রিপ্ট দরকার হয়, আপনি দেখতে পান যে DISKPARTঅন্য প্রোগ্রাম দ্বারা চালিত হওয়ার জন্য এটি সত্যই তৈরি হয়নি। হ্যাঁ, আপনি কোনও স্ক্রিপ্ট ফাইলে একটি সিরিজ কমান্ড লিখতে এবং এর মাধ্যমে চালাতে পারেন DISKPART /S scriptfile, তবে এটি সর্বদাই বা কিছুই নয়। আপনি কি সত্যিই এই ধরনের একটি পরিস্থিতি চাইলে আরো ভালো কিছু হয় গনুহparted , যা মত একক কমান্ড গ্রহণ করবে parted /dev/sdb mklabel gpt। এটি আপনার স্ক্রিপ্টকে ধাপে ধাপে ভিত্তিতে ত্রুটি পরিচালনা করতে দেয়।
"সবকিছুই একটি ফাইল" এর সাথে এইগুলির কী সম্পর্ক রয়েছে? সহজ: পাইপ কমান্ড লাইন প্রোগ্রাম I / O কে "ফাইলগুলিতে" সাজায়। পাইপগুলি নিয়মিত ডিস্ক ফাইলের মতো এলোমেলোভাবে অ্যাক্সেস নয়, একমুখী প্রবাহ থাকে, তবে অনেক ক্ষেত্রে পার্থক্যটির কোনও ফল হয় না। গুরুত্বপূর্ণ বিষয়টি হ'ল আপনি দুটি স্বতঃ-বিকাশযুক্ত প্রোগ্রাম সংযুক্ত করতে পারেন এবং এটিকে সাধারণ পাঠ্যের মাধ্যমে যোগাযোগ করতে পারেন। সেই দিক থেকে ইউনিক্স ওয়েকে মাথায় রেখে যে কোনও দুটি প্রোগ্রাম যোগাযোগ করতে পারে।
সেই ক্ষেত্রে যেখানে আপনার সত্যিই কোনও ফাইলের প্রয়োজন আছে, প্রোগ্রাম আউটপুটটিকে কোনও ফাইলে রূপান্তর করা সহজ:
$ some-program --some --args > myfile
$ vi myfile
কিন্তু "সবকিছুই একটি ফাইল" দর্শন যখন আপনাকে আরও ভাল উপায় দেয় তখন কেন একটি অস্থায়ী ফাইলে আউটপুট লিখবেন? আপনি যদি যা করতে চান তা যদি সেই আদেশের আউটপুটটিকে viসম্পাদক বাফারে পড়তে হয় তবে তা viসরাসরি আপনার জন্য করতে পারেন। থেকে vi"স্বাভাবিক" মোড, বলে,
:r !some-program --some --args
এটি বর্তমান কার্সার অবস্থানে সক্রিয় সম্পাদক বাফারে সেই প্রোগ্রামটির আউটপুট সন্নিবেশ করায়। হুডের অধীনে, viপ্রোগ্রামের আউটপুটটিকে কিছুটা কোডের সাথে সংযুক্ত করতে পাইপ ব্যবহার করা হচ্ছে যা একই ওএস কলগুলি ব্যবহার করে পরিবর্তে কোনও ফাইল থেকে পড়তে ব্যবহার করবে। দু'টি ক্ষেত্রে :r- অর্থাত্ !- সাথে এবং ছাড়া - উভয়ই সাধারণ জেনারিক ডেটা রিডিং লুপের সমস্ত সাধারণ বাস্তবায়নে ব্যবহার করলে আমি অবাক হব না vi। আমি না করার একটি ভাল কারণ ভাবতে পারি না।
এটি হয় এর সাম্প্রতিক বৈশিষ্ট্য viনয়; এটি প্রাচীন ed(1)পাঠ্য সম্পাদকের কাছে ফিরে আসে ⁸
এই শক্তিশালী ধারণাটি ইউনিক্সে বার বার আসে।
এর দ্বিতীয় উদাহরণের জন্য, muttউপরে আমার ইমেল কমান্ডটি স্মরণ করুন । আমার কেবল দুটি পৃথক কমান্ড হিসাবে লেখার কারণটি হ'ল আমি চেয়েছিলাম যে অস্থায়ী ফাইলটির নাম দেওয়া হোক *.gz, যাতে ইমেল সংযুক্তিটি সঠিকভাবে নামকরণ করা যায়। আমি যদি ফাইলটির নামটি যত্ন না করতাম তবে অস্থায়ী ফাইলটি তৈরি এড়াতে আমি প্রক্রিয়া বিকল্প ব্যবহার করতে পারতাম :
$ echo "Here's the disk image I promised to send you." |
mutt -a <(gzip -c myfs) -s "Password file disk image" you@example.com
এটি আউটপুটটিকে gzip -cফিফোর (যা ফাইল-জাতীয়) বা কোনও /dev/fdঅবজেক্টে (যা ফাইল-জাতীয়) রূপান্তর করে অস্থায়ীতা এড়ায় । (বাশ সিস্টেমের সক্ষমতার উপর ভিত্তি করে পদ্ধতিটি বেছে নেয়, যেহেতু /dev/fdসর্বত্র উপলব্ধ নয় isn't)
তৃতীয়বারের মতো ইউনিক্সে এই শক্তিশালী ধারণাটি উপস্থিত হয়, gdbলিনাক্স সিস্টেমগুলি বিবেচনা করুন। এটি সি এবং সি ++ তে লেখা যে কোনও সফ্টওয়্যারটির জন্য ব্যবহৃত ডিবাগার। অন্যান্য সিস্টেমগুলি থেকে ইউনিক্সে আগত প্রোগ্রামাররা gdbএটি সম্পর্কে প্রায় অবিস্মরণীয়ভাবে তাকান এবং "ইয়াক, এটি এত আদিম!" তারপরে তারা জিইউআই ডিবাগারের সন্ধানে যান, বিদ্যমান বেশ কয়েকটিতে একটি আবিষ্কার করেন এবং আনন্দের সাথে তাদের কাজ চালিয়ে যান ... প্রায়শই কখনই বুঝতে পারেন না যে জিইউআই কেবল gdbনীচে চলেছে , এটির উপরে একটি সুন্দর শেল সরবরাহ করে। বেশিরভাগ ইউনিক্স সিস্টেমে প্রতিযোগিতামূলক নিম্ন-স্তরের ডিবাগার নেই কারণ সেই স্তরে প্রতিযোগিতা করার জন্য কোনও প্রোগ্রামের প্রয়োজন নেই। আমাদের কেবল একটি ভাল নিম্ন-স্তরের সরঞ্জামের প্রয়োজন যা আমরা সকলেই আমাদের উচ্চ-স্তরের সরঞ্জামগুলিকে বেস করতে পারি, যদি সেই নিম্ন-স্তরের সরঞ্জামটি পাইপের মাধ্যমে সহজে যোগাযোগ করে।
এর অর্থ আমাদের কাছে এখন একটি ডকুমেন্টেড ডিবাগার ইন্টারফেস রয়েছে যা ড্রপ-ইন প্রতিস্থাপনের অনুমতি দেবে gdb, তবে দুর্ভাগ্যক্রমে, প্রাথমিক প্রতিযোগী gdb কম-ঘর্ষণের পথটি গ্রহণ করেনি ।
তবুও, কমপক্ষে এটি সম্ভব যে ভবিষ্যতের কিছু gdbপ্রতিস্থাপন স্বতন্ত্রভাবে কমান্ড লাইন ইন্টারফেসের ক্লোনিংয়ের মাধ্যমে নেমে আসবে। উইন্ডোজ বাক্সে একই জিনিসটি টানতে, প্রতিস্থাপনযোগ্য সরঞ্জামটির নির্মাতাদের কোনও প্রকারের ফর্মাল প্লাগইন বা অটোমেশন এপিআই সংজ্ঞায়িত করতে হবে। এর অর্থ এটি খুব জনপ্রিয় প্রোগ্রামগুলি ব্যতীত ঘটে না কারণ একটি সাধারণ কমান্ড লাইন ব্যবহারকারী ইন্টারফেস এবং একটি সম্পূর্ণ প্রোগ্রামিং এপিআই উভয়ই তৈরি করা অনেক কাজ।
এই যাদুটি বিস্তৃত পাঠ্য-ভিত্তিক আইপিসির অনুগ্রহের মাধ্যমে ঘটে ।
যদিও উইন্ডোজ কার্নেলের ইউনিক্স-স্টাইলের বেনামে পাইপ রয়েছে , সাধারণ ব্যবহারকারী প্রোগ্রামগুলি কমান্ড শেলের বাইরে আইপিসির জন্য এগুলি ব্যবহার করে দেখা বিরল , কারণ উইন্ডোজ প্রথমে একটি কমান্ড লাইনের সংস্করণে সমস্ত মূল পরিষেবা তৈরি করার, এবং তারপরে জিইউআই নির্মাণের এই traditionতিহ্যের অভাব রয়েছে because এটি শীর্ষে পৃথকভাবে। এটি জিইউআই ব্যতীত কিছু কিছু করতে না পারা যায়, এটিই লিনাক্সের তুলনায় উইন্ডোজের জন্য অনেকগুলি দূরবর্তী ডেস্কটপ সিস্টেম থাকার কারণ: জিইউআই ছাড়া উইন্ডোজ ব্যবহার করা খুব শক্ত।
বিপরীতে, ইউএসিক্স, বিএসডি, ওএস এক্স এবং লিনাক্স বাক্সগুলি দূরবর্তীভাবে এসএসএইচের মাধ্যমে পরিচালনা করা সাধারণ common এবং কিভাবে যে কাজ করে, আপনি জিজ্ঞাসা? এসএসএইচ একটি নেটওয়ার্ক সকেটকে (যা ফাইলের মতো) সিউডো টিটির সাথে সংযুক্ত করে /dev/pty*(যা ফাইলের মতো)। এখন আপনার রিমোট সিস্টেমটি আপনার স্থানীয়টির সাথে একটি সংযোগের মাধ্যমে সংযুক্ত হয়েছে যা ইউনিক্স ওয়েয়ের সাথে এতটাই নির্বিঘ্নে মেলে যে আপনি যদি প্রয়োজন হয় তবে এসএসএইচ সংযোগের মাধ্যমে ডেটা পাইপ করতে পারেন ।
আপনি এখন এই ধারণাটি কতটা শক্তিশালী তা সম্পর্কে একটি ধারণা পেয়ে যাচ্ছেন?
একটি পাইপযুক্ত পাঠ্য স্ট্রিমটি প্রোগ্রামের দৃষ্টিকোণ থেকে একটি ফাইল থেকে পৃথক পৃথক, এটি একমুখী নয় except একটি ফাইল পাইপ থেকে যেভাবে ফাইল থেকে পড়ে সেভাবে পঠিত: একটি ফাইল বর্ণনাকারীর মাধ্যমে । এফডিগুলি ইউনিক্সের একেবারে মূল; ফাইল এবং পাইপ উভয়ই I / O এর জন্য একই বিমূর্ত ব্যবহার করে তা আপনাকে কিছু বলা উচিত ⁹
উইন্ডোজ ওয়ার্ল্ড, সাধারণ পাঠ্য যোগাযোগের এই traditionতিহ্যটির অভাব, COM বা .NET এর মাধ্যমে হেভিওয়েট ওওপি ইন্টারফেসগুলির সাথে কাজ করে । আপনি যদি এই জাতীয় প্রোগ্রামটি স্বয়ংক্রিয় করতে চান তবে আপনাকে অবশ্যই একটি COM বা .NET প্রোগ্রাম লিখতে হবে। এটি ইউনিক্স বাক্সে পাইপ স্থাপনের চেয়ে মোটামুটি আরও কঠিন।
এই জটিল প্রোগ্রামিং এপিআইয়ের অভাবযুক্ত উইন্ডোজ প্রোগ্রামগুলি কেবল ক্লিপবোর্ড বা ফাইল / সেভের পরে ফাইল / ওপেনের মতো দরিদ্র ইন্টারফেসের মাধ্যমে যোগাযোগ করতে পারে।
দীর্ঘ উত্তর, অংশ 3: রেজিস্ট্রি বনাম কনফিগারেশন ফাইল
উইন্ডোজ রেজিস্ট্রি এবং ইউনিক্স ওয়ে সিস্টেম কনফিগারেশনের মধ্যে ব্যবহারিক পার্থক্য "সমস্ত কিছু একটি ফাইল" দর্শনের সুবিধাও চিত্রিত করে।
ইউনিক্স টাইপ সিস্টেমে, আমি কেবল ফাইল পরীক্ষা করে কমান্ড লাইন থেকে সিস্টেম কনফিগারেশন সম্পর্কিত তথ্য দেখতে পারি। আমি একই ফাইলগুলিকে সংশোধন করে সিস্টেমের আচরণ পরিবর্তন করতে পারি। বেশিরভাগ ক্ষেত্রে, এই কনফিগারেশন ফাইলগুলি কেবল প্লেইন পাঠ্য ফাইল, যার অর্থ আমি ইউনিক্সের যে কোনও সরঞ্জাম ব্যবহার করতে পারি যাতে সেগুলি সরল পাঠ্য ফাইলগুলির সাথে কাজ করতে পারে man
উইন্ডোজটিতে রেজিস্ট্রি স্ক্রিপ্ট করা প্রায় এত সহজ নয়।
সবচেয়ে সহজ পদ্ধতি হ'ল একটি মেশিনে রেজিস্ট্রি এডিটর জিইউআইয়ের মাধ্যমে আপনার পরিবর্তনগুলি করা, তারপরে অন্ধভাবে ফাইলগুলির regeditমাধ্যমে এই পরিবর্তনগুলি অন্য মেশিনে প্রয়োগ করুন*.reg । এটি আসলে "স্ক্রিপ্টিং" নয়, কারণ এটি আপনাকে শর্তাধীন কিছু করতে দেয় না: এটি সব কিছুই বা কিছুই নয়।
যদি আপনার রেজিস্ট্রি পরিবর্তনগুলিতে কোনও পরিমাণ যুক্তি প্রয়োজন হয় তবে পরবর্তী সহজ বিকল্পটি পাওয়ারশেল শিখতে হবে যা মূলত। নেট নেটওয়ার্ক প্রোগ্রামিং শেখার পরিমাণ। এটি এমন হবে যে ইউনিক্সের কেবল পার্ল থাকলে এবং আপনাকে এটির মাধ্যমে সমস্ত অ্যাডহক সিস্টেম প্রশাসন করতে হয়েছিল। এখন, আমি পার্ল ফ্যান, তবে সবাই নন। ইউনিক্স আপনাকে যতটা সরঞ্জাম পছন্দ করতে পারে ততক্ষণ তা ব্যবহার করতে দেয় যতক্ষণ না এটি সরল পাঠ্য ফাইলগুলি পরিচালনা করতে পারে।
পাদটিকা:
পরিকল্পনা 9 এই নকশা ভুল সংশোধন করা হয়েছে, নেটওয়ার্ক, I / O প্রকাশক মাধ্যমে ভার্চুয়াল ফাইল সিস্টেম ।/net
বাশ নামে একটি বৈশিষ্ট্য রয়েছে যা/dev/tcp নিয়মিত ফাইল সিস্টেমের মাধ্যমে নেটওয়ার্ক I / O কে মঞ্জুরি দেয় allows যেহেতু এটি একটি বাশ বৈশিষ্ট্য, বরং কার্নেল বৈশিষ্ট্য, এটি ব্যাশের বাইরে বা এমন সিস্টেমগুলিতে দৃশ্যমান নয় যা বাশকে একেবারেই ব্যবহার করে না । এটি কাউন্টারে নমুনা দ্বারা দেখায়, ফাইল সিস্টেমের মাধ্যমে সমস্ত ডেটা রিসোর্স দৃশ্যমান করা কেন এটি এত ভাল ধারণা।
"আধুনিক উইন্ডোজ" দ্বারা আমি উইন্ডোজ এনটি এবং এর প্রত্যক্ষ বংশধরদের অর্থ, যার মধ্যে উইন্ডোজ 2000, উইন্ডোজ সার্ভারের সমস্ত সংস্করণ এবং এক্সপি থেকে উইন্ডোজের সমস্ত ডেস্কটপ-ভিত্তিক সংস্করণ রয়েছে। আমি এই শব্দটি উইন্ডোজের ডস-ভিত্তিক সংস্করণগুলি বাদ দেওয়ার জন্য ব্যবহার করি, উইন্ডোজ 95 এবং এর প্রত্যক্ষ বংশধর, উইন্ডোজ 98 এবং উইন্ডোজ এমই, এবং তাদের 16-বিট পূর্বসূরীরা।
আপনি those উত্তরবর্তী ওএসগুলিতে একীভূত আই / ও সিস্টেমের অভাবে পার্থক্যটি দেখতে পাচ্ছেন। আপনি ReadFile()উইন্ডোজ 95 এ কোনও টিসিপি / আইপি সকেটটি পাস করতে পারবেন না ; আপনি কেবল উইন্ডোজ সকেট এপিআইতে সকেটগুলি পাস করতে পারেন। অ্যান্ড্রু শুলম্যানের চূড়ান্ত নিবন্ধটি দেখুন, উইন্ডোজ 95: এই বিষয়টির আরও গভীর ডুব দেওয়ার জন্য এটি কী নয় ।
কোনও ভুল করবেন না, /dev/nullএটি ইউনিক্স টাইপ সিস্টেমে একটি আসল কার্নেল ডিভাইস, কেবলমাত্র একটি বিশেষ-কেসড ফাইলের নাম নয়, যেমন NULউইন্ডোজে অতিপরিচয় সমতুল্য ।
যদিও উইন্ডোজ আপনাকে কোনও NULফাইল তৈরি থেকে বাঁচানোর চেষ্টা করে , তবে উইন্ডোজ ফাইলের নাম পার্সিং যুক্তিটিকে বোকা বানিয়ে নিছক কৌশল দ্বারা এই সুরক্ষাটিকে বাইপাস করা সম্ভব । আপনি যদি সেই ফাইলটি cmd.exeবা এক্সপ্লোরার দিয়ে সেই ফাইলটি অ্যাক্সেস করার চেষ্টা করেন তবে উইন্ডোজ এটিকে খুলতে অস্বীকার করবে, তবে আপনি সাইগউইনের মাধ্যমে এটি লিখতে পারবেন, কারণ এটি উদাহরণ প্রোগ্রামে অনুরূপ পদ্ধতি ব্যবহার করে ফাইলগুলি খোলায় এবং আপনি এটি একই কৌশল দ্বারা চালিত করতে পারেন ।
বিপরীতে, ইউনিক্স আপনাকে খুশিভাবে অনুমতি দেবে rm /dev/null, যতক্ষণ না আপনার কাছে লেখার অ্যাক্সেস রয়েছে এবং যতক্ষণ /devনা আপনি কোনও ট্র্যাগার ছাড়াই একটি নতুন ফাইল পুনরায় তৈরি করতে দিন, কারণ সেই ডিভ নোড হ'ল অন্য একটি ফাইল। সেই ডিভ নোড অনুপস্থিত থাকা সত্ত্বেও, কার্নেলের নাল ডিভাইসটি এখনও বিদ্যমান; আপনি দেব নোড দিয়ে পুনরায় তৈরি না করা পর্যন্ত এটি কেবল অ্যাক্সেসযোগ্য mknod।
আপনি অন্য কোথাও অতিরিক্ত নাল ডিভাইস ডেভ নোড তৈরি করতে পারেন: আপনি যদি এটি কল করেন তবে তাতে কিছু আসে যায় না /home/grandma/Recycle Bin, যতক্ষণ না এটি নাল ডিভাইসের জন্য ডেভ নোড, এটি ঠিক ঠিক তেমন কাজ করবে /dev/null।
উইন্ডোজটিতে আসলে দুটি উচ্চ-স্তরের "ফর্ম্যাট ডিস্ক" এপিআই রয়েছে: SHFormatDrive()এবং Win32_Volume.Format()।
দুটি খুব খুব ... ভাল ... উইন্ডোজ সাজানোর কারণে রয়েছে। প্রথমটি উইন্ডোজ এক্সপ্লোরারকে তার সাধারণ "ফর্ম্যাট ডিস্ক" ডায়ালগ বাক্সটি প্রদর্শন করতে বলে, যার অর্থ এটি উইন্ডোজের যে কোনও আধুনিক সংস্করণে কাজ করে তবে কোনও ব্যবহারকারী ইন্টারেক্টিভভাবে লগ ইন করে থাকে তবে অন্যটি আপনি ব্যবহারকারী ইনপুট ব্যাকগ্রাউন্ডে কল করতে পারেন, কিন্তু এটি উইন্ডোজ সার্ভার 2003 এর ঠিক আছে, কোর ওএস আচরণ 2003 পর্যন্ত একটি GUI পিছনে লুকানো ছিল যে একটি বিশ্ব যেখানে ইউনিক্স জাহাজে মধ্যে পর্যন্ত উইন্ডোজ না যোগ করা হয়েছিল mkfs 1 দিন থেকে ।
1974 সালের আমার ইউনিক্স ভি 5 এর অনুলিপিটিতে/etc/mkfs একটি 4136 বাইট স্ট্যাটিকালি লিঙ্কযুক্ত পিডিপি -11 এক্সিকিউটেবল। (১৯ix০ এর দশকের শেষদিকে ইউনিক্স গতিশীল সংযোগ পায় নি , সুতরাং এটির মতো নয় যে অন্য কোনও আসল কাজ অন্য কোথাও বড় লাইব্রেরি রয়েছে -) এর উত্স কোড - ভি 5 সিস্টেমের ছবিতে অন্তর্ভুক্ত /usr/source/s2/mkfs.c- এটি সম্পূর্ণ স্ব-সংযুক্ত 457- লাইন সি প্রোগ্রাম। এমনকি কোনও #includeবিবৃতিও নেই!
এর অর্থ আপনি কেবল mkfsউচ্চ স্তরে কী করেন তা পরীক্ষা করে দেখতে পারবেন না , আপনি চার দশক আগে কেন থম্পসনের মতোই ইউনিক্স তৈরি করেছিলেন একই সরঞ্জাম সেটটি ব্যবহার করে এটি নিয়ে পরীক্ষা করতে পারবেন । উইন্ডোজ দিয়ে চেষ্টা করুন। আপনি আজ যে নিকটে আসতে পারেন তা হ'ল 2014 সালে প্রথম প্রকাশিত ডস সোর্স কোডটি ডাউনলোড করা , যা আপনি কেবল সমাবেশ উত্সের পরিমাণ হিসাবে খুঁজে পান । এটি কেবল অপ্রচলিত সরঞ্জামগুলির সাহায্যে তৈরি করবে যা সম্ভবত আপনার হাতে নেই, এবং শেষ পর্যন্ত আপনি ডস 2.0 এর নিজস্ব কপিটি পেয়ে যান , এটি প্রায় এক দশক পরে প্রকাশিত হওয়া সত্ত্বেও 1974 এর ইউনিক্স ভি 5 এর চেয়ে অনেক কম শক্তিশালী একটি ওএস get
(ইউনিক্স ভি 5 সম্পর্কে কেন কথা বলবেন? কারণ এটি এখনও প্রথম দিকের সম্পূর্ণ ইউনিক্স সিস্টেম এখনও পাওয়া যায় Earlier পূর্ববর্তী সংস্করণগুলি আপাতদৃষ্টিতে হারিয়ে গেছে There এমন একটি প্রকল্প ছিল যা ভি 1 / ভি 2 যুগের ইউনিক্সকে একসাথে তৈরি করেছিল, তবে এটি mkfsঅস্তিত্ব সত্ত্বেও অনুপস্থিত বলে মনে হচ্ছে appears উপরে লিঙ্কযুক্ত ভি 1 ম্যানুয়াল পৃষ্ঠার এটি অবশ্যই কোথাও না কোথাও উপস্থিত থাকতে পারে প্রমাণিত হয় নয়তো যারা এই প্রকল্পটি একত্রিত করছেন mkfsতারা অন্তর্ভুক্ত করার জন্য একটি অতিরিক্ত কপি খুঁজে পেলেন না , বা আমি ফাইলগুলি খুঁজে না পেয়ে চুষতে পারি find(1), যা সে সিস্টেমেও নেই doesn't । :))
এখন, আপনি হয়তো ভাবছেন, "আমি কি কেবল কল করতে পারি না format.com? উইন্ডোজে mkfsইউনিক্সে ফোন করার মতো নয় ?" হায়রে, না, এটি এক রকম নয়, অনেকগুলি কারণে:
প্রথমত, format.comস্ক্রিপ্ট করার জন্য ডিজাইন করা হয়নি। এটি আপনাকে "প্রস্তুত হওয়ার পরে ENTER টিপুন" বলতে অনুরোধ জানায়, এর অর্থ হল এর ইনপুটটিতে আপনাকে একটি এন্টার কী প্রেরণ করতে হবে, বা এটি কেবল স্তব্ধ হয়ে যাবে।
তারপরে, আপনি যদি সাফল্য / ব্যর্থতার স্থিতি কোডের চেয়ে আরও কিছু চান, আপনাকে পড়ার জন্য এর স্ট্যান্ডার্ড আউটপুটটি খুলতে হবে, যা উইন্ডোজটিতে হওয়ার চেয়ে অনেক জটিল । (ইউনিক্সে, লিঙ্কযুক্ত নিবন্ধের সমস্ত কিছুই সাধারণ popen(3)কল দিয়ে সম্পন্ন করা যেতে পারে ))
এই সমস্ত জটিলতার মধ্যে দিয়ে যাওয়ার পরে, format.comকম্পিউটার প্রোগ্রামগুলির আউটপুটটি আউটপুটের তুলনায় পার্সিং করা শক্ত mkfs, মূলত মানুষের ব্যবহারের উদ্দেশ্যে তৈরি করা।
আপনি ট্রেস কি যদি format.comনা, আপনি যে এটি জটিল কল একটি গুচ্ছ আছে খুঁজে DeviceIoControl(), ufat.dllএবং এই ধরনের। এটি কেবল কোনও ডিভাইস ফাইল খুলছে না এবং সেই ডিভাইসে একটি নতুন ফাইল সিস্টেম লিখছে না। এটি এমন একটি ডিজাইন যা আপনি কোনও সংস্থা থেকে পান যা 126000 জনকে নিয়োগ দেয় এবং তাদের নিয়োগ দেওয়া চালিয়ে যাওয়া প্রয়োজন ।
লুপ ডিভাইসগুলির বিষয়ে কথা বলার সময়, আমি সাধারণভাবে ইউনিক্সের চেয়ে লিনাক্স সম্পর্কেই কথা বলি কারণ লুপ ডিভাইসগুলি ইউনিক্স টাইপ সিস্টেমের মধ্যে বহনযোগ্য নয়। ওএস এক্স, বিএসডি ইত্যাদিতে একই রকম প্রক্রিয়া রয়েছে তবে বাক্য গঠনটি কিছুটা ভিন্ন হয় ।
সেই দিনগুলিতে যখন ডিস্ক ড্রাইভগুলি ওয়াশিং মেশিনের আকার ছিল এবং বিভাগীয় প্রধানের বিলাসবহুল গাড়ির চেয়ে বেশি দাম ছিল, বড় কম্পিউটার ল্যাবগুলি আধুনিক কম্পিউটিং পরিবেশের তুলনায় তাদের সম্মিলিত ডিস্ক জায়গার একটি বৃহত পরিমাণ অনুভব করবে। স্থানীয় ফাইল সিস্টেমে স্বচ্ছভাবে একটি রিমোট ডিস্ক গ্রাফ্ট করার ক্ষমতা যেমন বিতরণ করা সিস্টেমগুলি ব্যবহার করা আরও সহজ করে তোলে। /usr/shareউদাহরণস্বরূপ, আমরা এখানেই পেয়েছি ।
কনট্রাস্ট উইন্ডোজ, যেখানে একটি রিমোট ডিস্ক সাধারণত ড্রাইভ লেটারে ম্যাপ করা হয় বা একটি ইউএনসি পাথের মাধ্যমে অ্যাক্সেস করতে হবে, স্থানীয় ফাইল সিস্টেমে স্বচ্ছভাবে সংহত না করে। ড্রাইভ চিঠিগুলি আপনাকে প্রতীকী অভিব্যক্তির জন্য কয়েকটি পছন্দ সরবরাহ করে; নেই P:BigServer উপর বা সফ্টওয়্যার আয়না সার্ভারে "প্যাকেজেস" নির্দেশিকাতে "সর্বজনীন" স্থান পড়ুন? ইউএনসি পাথের অর্থ হল আপনার রিমোট ফাইলগুলি কোন সার্ভারে রয়েছে তা আপনার মনে রাখতে হবে, যা কয়েকশ বা হাজার হাজার ফাইল সার্ভারের সাথে একটি বৃহত সংস্থায় কঠিন হয়ে যায়।
উইন্ডোজ 2007 সালে প্রকাশিত উইন্ডোজ ভিস্তার আগ পর্যন্ত সিমলিংক পায়নি, যা এনটিএফএসের প্রতীকী লিঙ্কগুলি প্রবর্তন করেছিল । উইন্ডোজটির প্রতীকী লিঙ্কগুলি ইউনিক্সের প্রতীকী লিঙ্কগুলির চেয়ে কিছুটা বেশি শক্তিশালী - ১৯ Un7 সাল থেকে ইউনিক্সের একটি বৈশিষ্ট্য - যাতে তারা কেবল স্থানীয় পথের দিকে নয়, একটি দূরবর্তী ফাইল ভাগের দিকেও ইঙ্গিত করতে পারে। ইউনিক্স ১৯ different৪ সালে এনএফএসের মাধ্যমে এটি আলাদাভাবে করেছিল, যা ইউনিক্সের প্রিক্সিস্টিং মাউন্ট পয়েন্ট বৈশিষ্ট্যের শীর্ষে তৈরি করে , যা এটি শুরু থেকেই ছিল।
সুতরাং, আপনি এটি কীভাবে দেখেন তার উপর নির্ভর করে উইন্ডোজ প্রায় 2 বা 3 দশক ধরে ইউনিক্সকে অনুসরণ করে।
তারপরেও, প্রতীকী লিঙ্কগুলি বেশ কয়েকটি কারণে উইন্ডোজ ব্যবহারকারীর অভিজ্ঞতার একটি সাধারণ অংশ নয়।
প্রথমত, আপনি কেবল সেগুলি পশ্চাদপটে কমান্ড লাইন প্রোগ্রাম দিয়ে তৈরি করতে পারেন MKLINK। আপনি তাদেরকে উইন্ডোজ এক্সপ্লোরার থেকে তৈরি করতে পারবেন না, যেহেতু উইন্ডোজ এক্সপ্লোরারে ইউনিক্স সমতুল সাধারণত না আপনি symlinks তৈরি করা যাক।
দ্বিতীয়ত, ডিফল্ট উইন্ডোজ কনফিগারেশন প্রতিরোধ সিম্বলিক লিংক তৈরি করার সময়, যে আপনি হয় প্রশাসক হিসেবে কমান্ড শেল চালাতে বা এর মাধ্যমে তাদের তৈরি করতে ব্যবহারকারী অনুমতি দিতে প্রয়োজন থেকে স্বাভাবিক ব্যবহারকারীদের একটি অস্পষ্ট পথ একটি হাতিয়ার আপনার গড় ব্যবহারকারীদের এমনকি দেখা যায় না, অনেক কম জানে ব্যবহারবিধি. (এবং উইন্ডোজের বেশিরভাগ অ্যাডমিন সুবিধাগুলি সমস্যার সাথে বিপরীতে, ইউএসি এই ক্ষেত্রে কোনও সহায়ক নয়))
লিনাক্স বাক্সগুলি সর্বদা বুট অনুক্রমের মধ্যে ভার্চুয়াল ডিস্ক চিত্র ব্যবহার করে না। আছে এটা করতে বিভিন্ন উপায়ে একটি গুচ্ছ ।
man ed
নেটওয়ার্ক সকেট বর্ণনাকারীরা হ'ল নীচে, এফডিও।