/Etc/apt/sources.list.d /etc/apt/sources.list ওভারের সুবিধা কী

Question

আমি জানি এই প্রশ্নটি আগে জিজ্ঞাসা করা হয়েছিল, তবে আমি উত্তরটি মানি না, "আপনি পরিষ্কারভাবে কাস্টম সংযোজনগুলি দেখতে পারেন"। আমি যখন পিপিএ যুক্ত করি (যা আমি বছরগুলিতে করিনি) আমি আমার কীবোর্ডে "এন্টার" লেবেলযুক্ত একটি কী চাপলাম যা আমাকে নতুন প্রবেশের আগে একটি খালি লাইন যুক্ত করতে দেয় (আমি এমনকি একটি ব্যাখ্যামূলক মন্তব্যও যুক্ত করতে পারি, তবে আমি একটি প্রযুক্তি লেখক, তাই ....)। আমি আমার sources.confপরিষ্কার এবং পরিষ্কার পরিচ্ছন্ন।

/etc/apt/sources.d

মানে আমার কাছে একটি মাত্রের পরিবর্তে পার্স করার জন্য আধা ডজন ফাইল রয়েছে।

আফাইক, 6 টি বনাম একটি কনফিগারেশন ফাইল রাখার "একেবারে" কোনও সুবিধা নেই (যুক্তির জন্য, আপনার কাছে সম্ভবত 3 বা 2 টিও আছে, তাতে কিছু আসে যায় না ... 1 এখনও 2 টি মারে)।

কেউ দয়া করে যুক্তিসঙ্গত সুবিধা নিয়ে আসতে পারেন, "আপনি পরিষ্কারভাবে কাস্টম সংযোজন দেখতে পাচ্ছেন" একটি দরিদ্র মানুষের অজুহাত।

আমি অবশ্যই যুক্ত করব, আমি পরিবর্তনটি পছন্দ করি, তবে কেবলমাত্র যখন পরিবর্তনের মাধ্যমে উপকারগুলি উপস্থিত হয়।

প্রথম প্রতিক্রিয়া পরে সম্পাদনা করুন:

এটি নতুন ইনস্টলেশনগুলিকে মঞ্জুরি দেয় যাতে তাদের নিজস্ব রেপোসের প্রয়োজন হয় যাতে এটি সদৃশ এন্ট্রি যোগ করছে না তা নিশ্চিত করার জন্য কোনও ফ্ল্যাট ফাইল অনুসন্ধান করতে হবে না।

এখন, তাদের ফ্ল্যাট ফাইলের পরিবর্তে ডুপের জন্য একটি ডিরেক্টরি অনুসন্ধান করতে হবে। যদি না তারা এডমিনকে ধরে না দেয় যে জিনিসগুলি পরিবর্তন করবেন না ...

এটি কোনও সিস্টেম অ্যাডমিনিস্ট্রেটরকে একচেটিয়া ফাইল সম্পাদনা না করে সহজেই কোনও (পুনর্নবীকরণের মাধ্যমে) কোনও ডিপোজিটরি সেটটি অক্ষম (মুছে ফেলার মাধ্যমে) মুছে ফেলার অনুমতি দেয়।

নাম বদলে দেওয়ার জন্য উপযুক্ত ফাইল খুঁজতে অ্যাডমিনকে ডিরেক্টরিটি গ্রেপ করতে হয়, তার আগে, তিনি একটি ফাইল অনুসন্ধান করে কোনও লাইন, কোনও অ্যাডমিনের "প্রায়" জন্য একটি লাইন মন্তব্য করতেন lin

এটি একটি প্যাকেজ রক্ষণাবেক্ষণকারীকে অযৌক্তিকভাবে সম্পর্কিত না হওয়া সম্পর্কিত সংগ্রহস্থলের জন্য কনফিগারেশন পরিবর্তন করার চিন্তা না করেই সংগ্রহস্থলগুলি আপডেট করার জন্য একটি সহজ কমান্ড দেওয়ার অনুমতি দেয়।

আমি এটি বুঝতে পারি না, আমি "ধরে নিই" প্যাকেজ রক্ষণাবেক্ষণকারী তার ভাণ্ডারের URL টি জানেন। আবার, sedএকটি একক ফাইলের পরিবর্তে একটি ডিরেক্টরিতে হবে।

Comments

মন্তব্যসমূহ এবং প্রশ্নোত্তর সম্পাদনাগুলি "প্রশ্নের অস্তিত্ব সম্পর্কে ঝাঁপিয়ে পড়ার" থেকে "প্রশ্নের উত্তর দেওয়ার চেষ্টা করা" থেকে দ্রুত চলে গেছে। দরকারী মন্তব্য ইতিমধ্যে গৃহীত উত্তরে প্রদর্শিত হবে

— মাইকেল মরোজেক

Answer 1

কারিগরি পর্যায়ে, যেহেতু কয়েকটি বড় এবং জনপ্রিয় সিস্টেম তথ্য সরঞ্জামগুলিতে এই পরিবর্তনগুলি পরিচালনা করতে হয়েছিল তাকে, মূলত এটি এখানে আসে:

উত্সের জন্য.লিস্ট.ডি /

# to add
if [[ ! -e /etc/apt/sources.list.d/some_repo.list ]];then
  echo 'some repo line for apt' > /etc/apt/sources.list.d/some_repo.list
fi

# to delete
if [[ -e /etc/apt/sources.list.d/some_repo.list ]];then
  rm -f /etc/apt/sources.list.d/some_repo.list
fi

মনে রাখবেন যে তারা নীচের মতো একই চেকটি না করে যদি আপনি কোনও রেপো লাইনটি মন্তব্য করেন তবে এই পরীক্ষাগুলি ভুল হবে be যদি তারা নীচের মতো একই চেক করছেন, তবে একাধিক ফাইলের বাইরে চালানো ব্যতীত এটি ঠিক একই জটিল। এছাড়াও, যতক্ষণ না তারা সমস্ত সম্ভাব্য ফাইলগুলি পরীক্ষা করে নিচ্ছে, ততক্ষণ তারা ডুপ্লিকেট আইটেম যুক্ত করতে এবং প্রায়শই করতে পারে, যতক্ষণ না আপনি সেগুলির একটি মুছে ফেলুন pt

উত্সের জন্য। তালিকা

# to add. Respect commented out lines. Bonus points for uncommenting
# line instead of adding a new line
if [[ -z $( grep -E '\s*[^#]\s*some repo line for apt' /etc/apt/sources.list ) ]];then
  echo 'some repo line for apt' >> /etc/apt/sources.list
fi

# to delete. Delete whether commented out or not. Bonus for not
# deleting if commented out, thus respecting the user's wishes
sed -i '/.*some repo line for apt.*/d' /etc/apt/sources.list

গুগল ক্রোম ডেভস গুগল ক্রোম সূত্রের উপস্থিতি যাচাই করে নি, তাদের ক্রোম প্যাকেজটি উপস্থিত হওয়ার জন্য সঠিক ফাইলটির উপর নির্ভর করে। অন্যান্য সমস্ত ক্ষেত্রে, তারা Source.list.d- এ নতুন ফাইলটি তৈরি করতে চাইবে ঠিক তার পছন্দ মতো named

আপনার কাছে কী উত্স রয়েছে তা দেখতে, এটি এত সুন্দর নয়, যেহেতু আপনি পড়া এবং বজায় রাখা সহজ করতে পারবেন না:

cat /etc/sources.list

সুতরাং এটি মূলত স্বয়ংক্রিয় আপডেটের উদ্দেশ্যে এবং যত সহজেই আমি বলতে পারি ব্যবহারকারীদের দিতে পারে এমন একক কমান্ড সরবরাহ করার উদ্দেশ্যেই এটি করা হয়েছিল। ব্যবহারকারীদের জন্য, এর অর্থ হ'ল তাদের একটি রেপো যুক্ত হয়েছে কিনা তা দেখতে তাদের 1 টি ফাইলের পরিবর্তে অনেকগুলি ফাইল পড়তে হবে, এবং উপযুক্ত হিসাবে এটির অর্থ এটিও একটি ফাইলের পরিবর্তে অনেকগুলি ফাইল পড়তে হবে।

আসল বিশ্বে যেহেতু, আপনি যদি এটি ভালভাবে চালিয়ে যাচ্ছিলেন তবে আপনাকে সমস্ত ফাইলগুলির চেকগুলি সমর্থন করতে হবে, সেগুলির নাম নির্বিশেষে, এবং তারপরে পরীক্ষা করা উচিত যে পদক্ষেপ নেওয়া দরকার কিনা বা প্রয়োজনীয় নয়।

তবে, আপনি যদি এটি ভালভাবে না চালাচ্ছেন তবে আইটেমটি উত্সের কোনও অংশে আছে কিনা তা দেখার জন্য আপনি কেবল চেকগুলি উপেক্ষা করবেন এবং কেবল ফাইলের নামটি পরীক্ষা করে দেখুন। আমি বিশ্বাস করি যে সর্বাধিক স্বয়ংক্রিয় স্টাফগুলি তাই করে তবে শেষ অবধি, আমাকে কেবল সবকিছু পরীক্ষা করতে হয়েছিল যাতে আমি এটিকে তালিকাবদ্ধ করতে পারি এবং সেই ফাইলগুলির মধ্যে একটি মিলে যায় তার ভিত্তিতে কাজ করতে পারি, কেবলমাত্র আসল ফলাফল এটিকে আরও জটিল করে তোলে।

বাল্ক সম্পাদনা

অনেক সার্ভার চলমান দেওয়া, আমি কেবল একটি রাত্রে কাজ স্ক্রিপ্ট করার প্রলুব্ধ হব যা /etc/apt/source.list.d/ এর মধ্য দিয়ে চলে এবং আইটেমটি ইতিমধ্যে সোর্স.লাইস্টে নেই তা নিশ্চিত করার জন্য প্রথমে চেক করে, যদি তা হয় তবে না, সেই আইটেমটি সোর্স.লিস্টে যুক্ত করুন, উত্স.লিস্ট.ডি ফাইলটি মুছুন, এবং ইতিমধ্যে সোর্স.লিস্টে থাকলে কেবল সোর্স.লিস্ট.ডি ফাইলটি মুছুন

যেহেতু কেবল উত্স ব্যবহারের ক্ষেত্রে নেতিবাচক কিছু নেই simp সরলতা এবং রক্ষণাবেক্ষণের স্বাচ্ছন্দ্যের বাইরে এমন কিছু যুক্ত করা কোনও খারাপ ধারণা নাও হতে পারে, বিশেষত সিএস প্রশাসকদের সৃজনশীল এলোমেলো ক্রিয়া দেওয়া।

উপরের মন্তব্যে উল্লিখিত হিসাবে, ইনসি -আর সক্রিয়ভাবে প্রতি ফাইলটি অ্যাক্টিভ রেপোগুলি মুদ্রণ করবে, তবে অবশ্যই তা সম্পাদনা বা পরিবর্তন করতে পারবে না, তবে এটি সমাধানের অর্ধেক হবে। যদি এটির অনেকগুলি বিতরণ হয় তবে এটি প্রত্যেকে কীভাবে এটি করে তা শিখতে ব্যথা হচ্ছে, এটি অবশ্যই নিশ্চিত and

Comments

মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।

— টেরডন

Answer 2

প্রতিটি নিজস্ব সংগ্রহস্থল (বা সংগ্রহশালা সংগ্রহ) এর নিজস্ব ফাইলে থাকা হাত এবং কর্মসূচী উভয়ই পরিচালনা করা সহজ করে তোলে:

• এটি নতুন ইনস্টলেশনগুলিকে মঞ্জুরি দেয় যাতে তাদের নিজস্ব রেপোসের প্রয়োজন হয় যাতে এটি সদৃশ এন্ট্রি যোগ করছে না তা নিশ্চিত করার জন্য কোনও ফ্ল্যাট ফাইল অনুসন্ধান করতে হবে না।
• এটি কোনও সিস্টেম অ্যাডমিনিস্ট্রেটরকে একচেটিয়া ফাইল সম্পাদনা না করে সহজেই কোনও (পুনর্নবীকরণের মাধ্যমে) কোনও ডিপোজিটরি সেটটি অক্ষম (মুছে ফেলার মাধ্যমে) মুছে ফেলার অনুমতি দেয়।
• এটি একটি প্যাকেজ রক্ষণাবেক্ষণকারীকে অযৌক্তিকভাবে সম্পর্কিত না হওয়া সম্পর্কিত সংগ্রহস্থলের জন্য কনফিগারেশন পরিবর্তন করার চিন্তা না করেই সংগ্রহস্থলগুলি আপডেট করার জন্য একটি সহজ কমান্ড দেওয়ার অনুমতি দেয়।

Comments

এটি গৃহীত উত্তরের চেয়ে ভাল ... মূল ধারণাটি "মালিকানা"। .dনকশা পরিষ্কারভাবে বিভিন্ন সত্ত্বা মালিকানাধীন কনফিগারেশন রাষ্ট্র আলাদা করে। এক একটি প্যাকেজ মালিকানাধীন হতে পারে। আরেকটি মাধ্যমে ইনস্টল করা হতে পারে wget ...। একটি একক দানব ফাইলের সাথে, কোনও স্বয়ংক্রিয় বা আধা-স্বয়ংক্রিয় পদ্ধতি কীভাবে কনফিগারটির কোন অংশটির মালিকানাটি "জানে"? এটি হয় না, এজন্যই .dনকশাটি সর্বোত্তম।

— নিমো

'হাত দ্বারা' সম্পর্কে নিশ্চিত না, তবে আমি বছরের পর বছর ধরে এটি করিনি। এটি প্রোগ্রামেটিক ম্যানেজমেন্টে উপকৃত হয়। পুতুলের মতো কনফিগারেশন ম্যানেজমেন্ট সফটওয়্যার ব্যবহার করার সময় লাইন যুক্ত বা অপসারণের জন্য কোনও ফাইলকে বিশ্লেষণের পরিবর্তে সবেমাত্র একটি ফাইল সরিয়ে ফেলা বা অপসারণ আপডেট করা সহজ। বিশেষত যেহেতু একাধিক স্বতন্ত্র মডিউল থেকে একটি 'ফাইল' রিসোর্স পরিচালনা করা এড়ানো যায়। আমি উবুন্টু এই কারণে ".d" ডায়ার ব্যবহারের প্রশংসা করি।

— মার্টিজন হিমেলস

@ মার্তিজন হিমেলস আমি যদি পারতাম তবে আমি আপনার মন্তব্যটি একশবার বার উচ্চারণ করব। ব্যক্তিগতভাবে আমার জন্য, .dএকবার ভারী পাপেট / সল্ট কনফিগারেশন পরিচালনা শুরু করার সাথে সাথে ডিজাইনের সুবিধাগুলি তত্ক্ষণাত ফোকাসে ফেলে।

— স্মিটেলি

@ থেরাপি, যদি আপনার প্রশাসকরা আপনাকে বোকা বানানোর চেষ্টা করে তবে আপনার আরও বিশ্বাসযোগ্য প্রশাসকদের সন্ধান করা উচিত। আমি (বা প্রকৃতপক্ষে কেউ) কী লিখব (গুলি) "একেবারে আবর্জনা", সর্বোপরি অভদ্র।

— ডোপঘোটি

অপ্সের দৃষ্টিকোণ থেকে এটি নিশ্চিত করা। নির্দিষ্ট প্যাকেজগুলির দ্বারা, বা আপনার কনফিগার ব্যবস্থাপনার মডিউলগুলির দ্বারা সম্পূর্ণ ফাইলগুলি সরবরাহ করা এবং মালিকানাধীন হওয়া আপনার কনফিগার করা প্রতিটি অ্যাপ্লিকেশনটির জন্য ফ্লাইতে পার্সার লেখার চেষ্টা করার চেয়ে পরিষ্কার। এটি কেবলমাত্র অ্যাপের জন্যই তুচ্ছ মনে হতে পারে, তবে তারপরে আপনি এমন অনেকগুলি সিস্টেম পাবেন যা একই কৌশল ব্যবহার করতে পারে (লোগ্রোটেট, ক্রোন, সিসেক্টল, সুডোরস, আরএসগ্লগ, মোডপ্রোব, ... service.d/*ফাইলগুলি থেকে কনফিগার লোড ) বিদ্যমান সংশোধন করার পরিবর্তে ফাইল মোতায়েন করা চিত্রগুলি ক্যাচিং / তুলনা করার জন্য এটিও ভাল।

— ভাইরাপোর

Answer 3

আপনি যদি নিজের সার্ভারকে ম্যানুয়ালি পরিচালনা করেন তবে আমি সম্মত হব এটি বিষয়গুলিকে আরও বিভ্রান্ত করে তোলে। তবে এটি প্রোগ্রামেটিক ম্যানেজমেন্ট (যেমন "কোড হিসাবে কনফিগারেশন") উপকার করে। কনফিগারেশন ম্যানেজমেন্ট সফটওয়্যার যেমন পুতুল, আনসিবল, শেফ, ইত্যাদি apt updateব্যবহার করার সময় নির্দিষ্ট লাইন যুক্ত করতে বা মুছে ফেলার জন্য কোনও ফাইলকে বিশ্লেষণের পরিবর্তে একটি ডিয়ারের মধ্যে একটি ফাইল ফেলে দেওয়া বা চালানো সহজ ।

বিশেষত যেহেতু এটি কোনও একক 'ফাইল' সংস্থার বিষয়বস্তু পরিচালনা করা এড়ানো যায় না, যেমন: /etc/apt/sources.listতৃতীয় পক্ষগুলি দ্বারা লিখিত একাধিক স্বতন্ত্র মডিউলগুলি থেকে।

আমি এই বিশেষ কারণে, যেমন sudoers.d, rsyslog.d, sysctl.d।, Cron.d, logrotate.d, ইত্যাদির জন্য উবুন্টুর ".d" ডায়ারের বিস্তৃত ব্যবহারের প্রশংসা করি

Answer 4

নিমো যেহেতু একটি মন্তব্যে উল্লেখ করেছেন, একটি ডিরেক্টরির অন্যতম প্রধান সুবিধা হ'ল এটি "মালিকানা" ধারণার অনুমতি দেয়।

আধুনিক লিনাক্স ডিস্ট্রিবিউশন এবং ইনস্টলারগুলি সমস্তই প্যাকেজগুলির ধারণার ভিত্তিতে তৈরি - স্বতন্ত্র সফটওয়্যারগুলির টুকরো যা যতটা সম্ভব, যোগ করা যায় এবং পরমাণুভাবে মুছে ফেলা যায়। আপনি যখনই কোনও প্যাকেজ ইনস্টল করেন dpkg(এবং তাই apt) এটি ইনস্টলার দ্বারা সিস্টেমে কোন ফাইলগুলি তৈরি করা হয়েছিল তা ট্র্যাক করে। প্যাকেজ আনইনস্টল করার পরে সেই ফাইলগুলি মুছতে অনেকাংশে অন্তর্ভুক্ত থাকতে পারে।

বর্তমানে গৃহীত উত্তর একটি খারাপ জিনিস একটি গুগল ক্রোম ইনস্টলার অধিকৃত যে এটি শুধুমাত্র তৈরি করা উচিত বা অবস্থান আশা একটি এন্ট্রি মুছে দিতে পারেন তবে স্বয়ংক্রিয় কিছু ভয়ঙ্কর প্রান্ত মামলা সমস্ত প্রকারের অন্য বিশালাকার যেমন নেয়; এই ক্ষেত্রে:

• যদি sources.listইনস্টল করার সময় লাইনটি বিদ্যমান থাকে তবে এতে মন্তব্য করা হয়, ইনস্টলারটি কি এটিকে অস্বচ্ছন্দ করা উচিত, বা একটি নকল যুক্ত করা উচিত?
• যদি আনইনস্টলারটি লাইনটি সরিয়ে দেয় তবে ব্যবহারকারী তার পাশের মন্তব্যগুলি যুক্ত বা সম্পাদনা করেছে, ফাইলটি ভাঙা ভাষ্য দিয়ে রেখে দেওয়া হবে।
• ব্যবহারকারী যদি ম্যানুয়ালি লাইনটি যুক্ত করেন তবে ইনস্টলার এটি যুক্ত না করতে জানত; তবে আনইনস্টলারটি কীভাবে এটি অপসারণ করতে পারবে না?

মালিকানার জন্য পৃথক পৃথক ফাইলের প্রয়োজন নেই; উদাহরণস্বরূপ, ইনস্টলারটি মন্তব্যগুলির একটি ব্লক অন্তর্ভুক্ত করতে পারে যাতে উল্লেখ করে যে এটি নির্দিষ্ট রেখাগুলির একটি সেট "মালিকানাধীন" রয়েছে। সেক্ষেত্রে, এটি সর্বদা সেই একই ব্লকের জন্য ফাইল অনুসন্ধান করবে, একই সংগ্রহস্থলের অন্য কোনও উল্লেখের জন্য নয়।

অন্য সকলটি সমান হওয়ায়, একটি একক কনফিগারেশন ফাইলে সম্পাদনাগুলি স্বয়ংক্রিয় করা সর্বদা পৃথক ফাইলের তৈরি ও মোছার চেয়ে জটিল হয়ে উঠবে। খুব কমপক্ষে, লাইনগুলি সরিয়ে ফেলার জন্য কিছু প্যাটার্ন-ম্যাচিং সরঞ্জাম ব্যবহার করা দরকার sed। আরও জটিল ফাইলে, উভয় লাইন যুক্ত করা এবং অপসারণের জন্য ফাইলের ফর্ম্যাট সম্পর্কিত জ্ঞান সহ একটি স্ক্রিপ্টিং সরঞ্জামের প্রয়োজন হতে পারে, উপযুক্ত বিভাগে যুক্ত করতে, বা আশেপাশের বিন্যাসকে ক্ষতিগ্রস্থ না করে অপসারণ করতে পারে।

যেহেতু কোনও ইনস্টলারকে ম্যানুয়ালি সম্পাদিত কনফিগারেশনের সাথে ঝামেলা এড়াতে হবে, তাই স্বয়ংক্রিয় সরঞ্জামগুলি পরিচালনা করার পক্ষে সহজ এমন বিন্যাসে স্বয়ংক্রিয়, সরঞ্জামের মালিকানাধীন, কনফিগারেশনটি রাখা অর্থপূর্ণ।

Answer 5

এটি স্ক্রিপ্টগুলির অবলম্বন ছাড়াই প্যাকেজগুলিকে অতিরিক্ত উত্স যুক্ত করতে দেয়।

উদাহরণস্বরূপ, আপনি যখন মাইক্রোসফ্টের স্কাইপ প্যাকেজ ইনস্টল করেন, স্কাইপ ডট কমের জন্য একটি উত্স আপডেটগুলি ডাউনলোড করার জন্য স্বয়ংক্রিয়ভাবে কনফিগার করা থাকে; সিস্টেম থেকে স্কাইপ প্যাকেজ অপসারণও এই প্যাকেজ উত্সটি আবার অক্ষম করে।

যদি আপনি একটি ফ্ল্যাট ফাইলের সাথে একই প্রভাব পেতে চান, তবে স্কাইপের জন্য ইনস্টলেশন স্ক্রিপ্টগুলির জন্য আপনার উত্সগুলি পরিবর্তন করতে হবে list তালিকা, সম্ভবত সিস্টেম প্রশাসকদের বেশিরভাগই সামান্য উদ্বেগজনক হতে পারে।

Answer 6

আমি দৃ convinced় বিশ্বাস করি না যে এর কোনও যুক্তিসঙ্গত কারণ আছে - অন্যথায় এটি কেতাদুরস্ত বলে মনে হয়। আমার কাছে এটি একটি নিয়ম ভঙ্গ করে যে ডিরেক্টরিতে হয় কোনও পাতা বা নোড হওয়া উচিত - অর্থাৎ এটিতে কেবল ফাইল বা ডিরেক্টরি থাকতে হবে, উভয়ের মিশ্রণ নয়।

আমি অনুমান করি যে এটি ফাইলগুলি আরও ছোট করে তোলে, এত সহজে পড়া সহজ - সুডোর নিয়মের উদাহরণস্বরূপ, যা দীর্ঘ দীর্ঘ হতে পারে, এক ধরণের ব্যবহারকারীর জন্য নিয়মের একটি মানক সেট করা সহজ করে তোলে (কোনও বিকাশকারী বলুন) ), এবং সেগুলি কনফিগার ডিরেক্টরিতে যুক্ত করুন যদি ডিভগুলি এই মেশিনে সুডো করার অনুমতি দেয়; সুতরাং আপনাকে কম ফাইল বজায় রাখতে হবে - প্রতিটি সম্ভাব্য সংমিশ্রণের পরিবর্তে কেবলমাত্র একটি ফাইল ডেভস, অ্যাডমিনদের জন্য, সিসপস ইত্যাদির জন্য।

সেখানে আমি নিজের সাথে বিরোধিতা করেছি।

Comments

আমি কোনও নিয়ম হিসাবে "ডিরেক্টরিতে একটি পাতা বা নোড হওয়া উচিত" নেব না। স্বীকৃত উদাহরণ হিসাবে, দেখুন /var/log। একটি সরল ডেমন এক একমাত্র ফাইল সরাসরি ভিতরে লিখতে পারেন: /var/log/simple.log। : একটি আরো জটিল ডেমন নিজস্ব সাব প্রয়োজন হতে পারে /var/log/complex/a.log, /var/log/complex/b.log, /var/log/complex/c.log... configs সঙ্গে অনুরূপ প্যাটার্ন।

— স্মিটেলি

আমি /var/log/simple/log.1 .2, ইত্যাদি হিসাবে ফ্যাশন চাই পথ আপনাকে তথ্য দেয়। SO var লগে প্রতিটি লগ টাইপের জন্য সাবডিয়ার থাকে এবং প্রতিটি সাবডির এতে এক বা একাধিক ফাইল থাকতে পারে। আমি স্বীকার করি, এমন কয়েকটি উদাহরণ রয়েছে যেখানে ব্যতিক্রমগুলি যুক্তিসঙ্গত, তবে সাধারণ নিয়ম হিসাবে এটি ভাল। আমি প্রমাণযুক্তি, ডিসঅরগানাইজেশন এর আইএমও ফাইল সহ হোম ডিরেক্টরি দেখতে ঘৃণা করি

— গ্রাহাম নিকোলস

সেখানে হয় একটি ভাল কারণ, তবে আপনি একটি প্রশাসক হিসাবে ভাবতে আগে আপনি এটা বুঝতে প্রয়োজন। ডোপঘোটির উত্তর দেখুন।

— পুনরায় পোস্টার

ঠিক আছে, এটি আমাকে আমার জায়গায় রেখেছিল, তাই না? স্পষ্টতই আমি প্রশাসক হিসাবে ভাবতে পারি না - বা আমি কেবল আপনার সাথে একমত নই।

— গ্রাহাম নিকোলস