সি স্ট্যাটিক লাইব্রেরি ভ্রমন করা হয়? [বন্ধ]

Question

ভাগ লাইব্রেরি থাকার জন্য 2 টি যুক্তি রয়েছে:

1. এটি ডিস্কের স্থান হ্রাস করতে সহায়তা করে।
2. যখন একটি ভাগ করা লাইব্রেরি আপডেট করা হয়, তার উপর নির্ভর করে সমস্ত বাইনারি আপডেট পায়।

ভাগ করা লাইব্রেরিগুলির জন্য মূলত একটি অপূর্ণতা রয়েছে:

• তারা (পারে) নির্ভরতা নরকের পরিচয় দেয়।

---

ডেস্কটপ কম্পিউটারগুলিতে, 1 ম সুবিধাটি আসলে আর ধারণ করে না। এই দিনগুলিতে ডিস্কের স্থান নষ্ট করা খুব একটা সমস্যা নয়।

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

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

---

যেহেতু শেয়ার্ড লাইব্রেরিগুলির অন্যতম প্রধান সুবিধা এখন আর বড় বিষয় নয়, সি স্ট্যাটিক লাইব্রেরিগুলি কি এখনও ভাবা হয়? যদি তাই হয় তবে কেন?

Comments

সি ব্যবহার করা হয় না এমন প্রাথমিক কারণটি বিশেষত আপনি আধুনিক ডেস্কটপ কম্পিউটারে কাজ করছেন না বলে হ'ল ।

— টেলাস্টিন

@ টেলাস্টিন আমি দুঃখিত? আমার ডেস্কটপ কম্পিউটারে ইনস্টল করা বেশিরভাগ সফ্টওয়্যার

— সিতে

সাইড বিট -

ডায়নামিক লাইব্রেরিগুলির একটি সুবিধা হ'ল লোকেরা আপনার 15 বছরের পুরানো ক্লোজড সোর্স গেমটিতে বাগগুলি, সুরক্ষা গর্তগুলি বা হার্ডওয়্যার সম্পর্কিত সমস্যাগুলির জন্য লাইব্রেরিগুলি আপডেট করতে পারে যা আপডেটগুলি পাওয়া বন্ধ করে দিয়েছে। কুলুঙ্গি ধরনের তবে ভাল গেমগুলি পণ্য নয়, "কেবলমাত্র অন্য প্রোগ্রাম ব্যবহার করুন" আসলেই সহায়তা করে না। আপনার নিজের কোডটি খোলা না করে এলজিপিএলকে মেনে চলাও গুরুত্বপূর্ণ।

— ডোভাল

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

— এসকে-যুক্তি

Answer 1

আপনার প্রশ্নের ভিত্তি ত্রুটিযুক্ত। যা ভ্রান্ত হয় তা হ'ল মতবাদ এবং এর পেছনের ভিত্তি (কার্গো কাল্ট প্রোগ্রামিং?) এর কোন ভিত্তি না বোঝার সাথে সম্পর্কিত।

সংযুক্ত এসও উত্তরটি সেই একই বিষয়টির একটি আকর্ষণীয় অধ্যয়ন - প্রশ্নটি ছিল কেন-স্ট্যাটিক বিকল্পের সাথে একটি সংকলন কাজ করছে না, আপনি যে উত্তরটির সাথে যুক্ত ছিলেন সেটি স্থির লিংক না ব্যবহারের বিরল ব্যতীত আর কিছুই নয়। এটির খারাপ কেন তা নিয়ে আলোচনা না করা হয় এবং ওপি গতিশীল লিঙ্ক ব্যবহার করে demands এটি দুর্ভাগ্যজনকভাবে এটিকে সঠিক উত্তর হিসাবে চিহ্নিত করা হয়েছে (নীচের উত্তরটি দ্বিগুণ ভোট পেয়েছে এবং ওপি'র প্রশ্নের সঠিক উত্তর) কারণ যদিও সঠিক উত্তরটি রয়েছে, তবে এটি গভীরভাবে গোপনে মতামতের মধ্যে লুকিয়ে রয়েছে।

আসল প্রশ্নটি হ'ল স্থির বনাম গতিশীল সংযোগের কী কী উপকারিতা এবং বিপরীতে তা কখন অন্যটির থেকে পছন্দ হবে।

Comments

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

— কোডি গ্রে

@ কোডি লিঙ্কিত উত্তরটি সম্পাদনা করা হয়েছে কারণ আমি একে অভিহিত বলেছি। স্ট্যাটিক বনাম গতিশীল লিঙ্কিংয়ের বিষয়ে আমি একমাত্র মতামতটি হ'ল আপনার প্রয়োজনের জন্য উপযুক্ত এটি ব্যবহার করা এবং পছন্দের শক্তি এবং দুর্বলতাগুলি বোঝার পরিবর্তে কার্গো কাল্ট প্রোগ্রামিং মতবাদে পড়ুন কারণ "কেউ এমন বলেছেন"।

— mattnz

হ্যাঁ, "বিশেষত ..." অংশটি যুক্ত হয়েছিল। এটি কীভাবে তার অভিজাত স্থিতিকে প্রভাবিত করে তা নিশ্চিত নয়। অবশ্যই আমি কার্গো কাল্ট প্রোগ্রামিংয়ের পক্ষে পরামর্শ দিচ্ছি না। এটি ঠিক যে স্থির সংযোগের প্রবক্তারা (আমার অভিজ্ঞতায়) প্রায়শই সুরক্ষার উদ্বেগকে বাদ দেয় বা অবমূল্যায়ন করে। স্ট্যাটিক লিঙ্কিং এক-অফ ইউটিলিটির জন্য খুব উপযুক্ত হতে পারে, অ্যাপটিকে স্ব-অন্তর্ভুক্ত করে এবং তাই বিতরণটি আরও সহজ। তবে যে কোনও অ্যাপ্লিকেশন যা ব্যাপকভাবে মোতায়েন করা হবে বা উত্পাদনের জন্য ব্যবহৃত হবে তার সত্যিকার অর্থে একটি ভাগ করা লাইব্রেরির সাথে লিঙ্ক করা উচিত। কোনও আসল অসুবিধা নেই: অ্যাপ্লিকেশানের এই স্তরে, আপনার ইতিমধ্যে একটি স্থাপনা প্রক্রিয়া প্রয়োজন।

— কোডি গ্রে

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

— mattnz

Answer 2

বিকাশকারী দৃষ্টিকোণ থেকে, গতিশীল লিঙ্কিং প্রায়শই আপনার সংকলন / লিঙ্ক / পরীক্ষার লুপটিকে যথেষ্ট গতিতে পারে।

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

কিউটি-র মতো জনপ্রিয় লাইব্রেরিতে সুরক্ষার সমস্যার কথা ভাবেন। ডায়নামিক লিঙ্কিংয়ের সাথে, আমি কেবলমাত্র সেই এক প্যাকেজটি আপডেট করতে পারি, প্রতি একক প্যাকেজ যা Qt- এ যুক্ত রয়েছে তা সনাক্ত, পুনরায় সংকলন এবং স্থাপনের পরিবর্তে package

স্ট্যাটিক লিঙ্কিংয়ের স্বতন্ত্রভাবে মোতায়েন করা ক্লোজ সোর্স অ্যাপ্লিকেশনগুলিতে সুবিধা থাকতে পারে তবে ওপেন সোর্স প্যাকেজ পরিচালনায় এটি যতটা সহায়তা করে তার চেয়ে বেশি ক্ষতি করে।

Comments

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

— আর .. গীটহাব বন্ধ করুন ICE

Answer 3

মূলত আপনার কারণ # 2 এর জন্য লিনাক্স বিতরণ রক্ষণাবেক্ষণকারীদের দ্বারা ভাগ করা লাইব্রেরিগুলি দৃ strongly়ভাবে পছন্দ হয় । এটি তাদের কাছে সত্যই গুরুত্বপূর্ণ যে উদাহরণস্বরূপ, যখন কেউ জিলিবিতে একটি সুরক্ষা বাগ খুঁজে পায় , তখন তাদের zlib ব্যবহার করে এমন প্রতিটি প্রোগ্রামই পুনরায় কম্পাইল করতে হবে না - কেবল তাদের জন্য আরও সিপিইউ চক্র ব্যয় করতে হবে না not পুনরায় সংশোধন করে, যারা ডিস্ট্রো ব্যবহার করে তাদের প্রত্যেককে সেই প্রোগ্রামগুলি পুনরায় ডাউনলোড করতে হবে। এই সময়ের মধ্যে, একটি বিতরণ দ্বারা সরবরাহিত প্যাকেজগুলির সেটগুলির মধ্যে, নির্ভরতা নরক কোনও সমস্যা নয়, কারণ libra লাইব্রেরির সেটের সাথে কাজ করার জন্য সবকিছু পরীক্ষা করা হয়।

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

জেনে রাখা অন্য গুরুত্বপূর্ণ বিষয়টি হ'ল জিএনইউ libcএবং জিসিসির দু'এরই libstdc++উপাদান রয়েছে যা গ্রন্থাগারটি স্ট্যাটিকভাবে সংযুক্ত থাকলে নির্ভরযোগ্যভাবে কাজ করে না। সর্বাধিক সাধারণ সমস্যাটি হ'ল dlopenকারণ আপনি যে মডিউলটি দিয়ে লোড করেন dlopenতা স্বয়ং গতির সাথে যুক্ত libc.so.6। সুতরাং এর অর্থ এখন আপনার নিজের ঠিকানা জায়গাতে সি লাইব্রেরির দুটি অনুলিপি রয়েছে এবং অভ্যন্তরীণ mallocডেটা কাঠামোর (যেমন উদাহরণস্বরূপ) কোন অনুলিপি অনুমোদনযোগ্য তা নিয়ে তারা যখন একমত না হন তখন হতাশার বিষয়টি নিশ্চিত হয়। এটি আরও খারাপ হয়: পুরো গুচ্ছ ফাংশনগুলির সাথে ব্যবহার dlopen, পছন্দ gethostbynameএবং iconvব্যবহারের কিছু করার থাকে না বলে মনে হয়dlopenঅভ্যন্তরীণভাবে (যাতে তাদের আচরণ রানটাইম-কনফিগারযোগ্য হয়)। ভাগ্যক্রমে, libc এবং libstdc ++ এর জন্য এবিআই খুব স্থিতিশীল, তাই আপনার এগুলি গতিশীলভাবে সংযোগ স্থাপনের সম্ভাবনা নেই are

Answer 4

আমি ম্যাটঞ্জের শেষ পয়েন্টের সাথে একমত: এই প্রশ্নটি একটি বোঝা প্রশ্ন। এটি ধরে নিয়েছে যে স্থির লিঙ্কটি খারাপ। কেন এটি না হয় তার দুটি কারণ সম্পর্কে আমি ভাবতে পারি:

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

• স্ট্যাটিক লিঙ্কিং নিশ্চিত করে যে কোনও অ্যাপ্লিকেশন আরও স্ব-অন্তর্ভুক্ত। ভাগ করা লাইব্রেরিগুলিকে প্রাথমিক নির্বাহযোগ্যের সাথে একত্র করা যেতে পারে, প্রায়শই সেগুলি ভাগ করা স্থানে জমা করা হয়। স্ট্যাটিকালি লিঙ্কযুক্ত অ্যাপ্লিকেশনগুলি "ওএসের মালিকানাধীন ফাইল, ডিরেক্টরি বা সেটিংসে পরিবর্তন প্রয়োজন নেই" এই অর্থে "পোর্টেবল" নিশ্চিত করা সহজ (উইন্ডোজ ডিরেক্টরি, রেজিস্ট্রি, ইত্যাদি বিবেচনা করুন)।

Comments

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

— ফ্লোরিয়ান মার্জাইন

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

— অ্যালান শুটকো

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

@ স্বনাম আমি মনে করি যে মূল বিষয়টি হ'ল যে কোনও বাস্তবসম্মত অপারেটিং সিস্টেম যা গতিশীল লিঙ্কিং সরবরাহ করে (আমি কোনও ওএস সম্পর্কে জানি না যা ডায়নামিক লিঙ্কিং ব্যবহার করে তবে পেজিংয়ের দাবি রাখে না) আপনার দ্বিতীয় পয়েন্টটি জল ধরে রাখে না: মেমরিটি আসলে ব্যবহার হয় না যদি না ফাংশনটি ব্যবহার করা হয় এবং ডায়নামিক লাইব্রেরি দ্বারা ব্যবহৃত মেমরিটি এটি ব্যবহার করে বিভিন্ন প্রোগ্রামের মধ্যে ভাগ করা যায় যা গতিশীল সংস্করণের জন্য মেমরির ব্যবহারকে কম পরিবর্তে আরও দক্ষ করে তোলে। আপনার প্রথম এবং তৃতীয় কারণগুলি বৈধ, তবে আমি কেবল দ্বিতীয়টি মুছব: কোনও বাস্তববাদী অনুমানের সাথে, এটি ঠিক ভুল।

— জুলে

@ জুলস আমি সম্মত, এটি এমন একটি বিষয় যা আধুনিক অপারেটিং সিস্টেমগুলিতে সমস্যাযুক্ত এবং সন্দেহজনক বৈধতা ছিল। আমি এটি সরিয়েছি।

Answer 5

স্ট্যাটিক এবং ডায়নামিক লাইব্রেরিগুলির প্রত্যেকের নিজস্ব ব্যবহার রয়েছে। সুযোগে একটি একক প্রয়োগের দিকে তাকালে আমরা কী প্রয়োজনীয় এবং কোনটি নয় সে সম্পর্কে আমরা আলাদা ধারণা পাই।

স্ট্যাটিক লিঙ্কিং অ্যাপ্লিকেশন স্থাপনাকে মারাত্মকভাবে সহজ করে তোলে। বিভিন্ন সংস্করণ সনাক্ত এবং ডিল করা হচ্ছে না। শুধু বেক এবং স্থাপন করা।

গতিশীল লাইব্রেরিগুলির সাথে সুস্পষ্ট সুবিধা হ'ল স্বাধীনভাবে আপডেট প্রয়োগ করার ক্ষমতা।

আমি জাভা এবং অন্যান্য অনুরূপ গতিশীল লিঙ্কিং প্রকল্প নির্মাতাদের ঘৃণার কারণগুলির মধ্যে এটি একটি। তারা প্রত্যাশা করে যে একটি একক গ্রন্থাগার সংস্করণ একটি প্রদত্ত ইউআরএলে চিরকালের জন্য উপলব্ধ থাকবে। 10 বছরে যে সমস্যাটি ঘটেছিল তা বুঝতে না পেরে যখন কেউ অ্যাপ্লিকেশনটি সংকলন করতে পারে না কারণ সমস্ত উত্স এবং জারগুলি চলে গেছে।

Comments

এমন কোনও কারণ আছে কি না যেগুলি প্রোগ্রামগুলির FooLib1.8পক্ষে সেই লাইব্রেরির জন্য কোডকে একটি কার্যকর পদ্ধতিতে তাদের এক্সিকিউটেবল প্যাকেজে কোড অন্তর্ভুক্ত করতে সক্ষম হয়, যাতে এটি আপগ্রেড ইউটিলিটিটিকে FooLib1.9আপগ্রেড বা ডাউনগ্রেড করার অনুমতি দেয় ? ক্লাসিক ম্যাকিনটোসে যেভাবে কোড সংরক্ষণ করা হয়েছে তা এটি বেশ সহজ করে তুলেছে; আজকের সিস্টেমগুলি আরও ভাল করতে সক্ষম হওয়া উচিত নয় এমন কোনও কারণ আছে কি?

— সুপারক্যাট

@ সুপের্যাট আপনার মানে কি কোনও প্রদত্ত লাইব্রেরির প্রতিটি সংস্করণ সিস্টেমে পাওয়া যাবে? নিশ্চিত না যে আমি প্রশ্নটি বুঝতে পেরেছি। ওপি প্রশ্নটি সিস্টেম বিস্তৃত লাইব্রেরি বনাম স্থির লাইব্রেরিগুলির দিকে আরও নির্দেশিত হয়েছিল যা একসাথে প্যাকেজ করা হবে।

— প্রচুর ক্রিপস

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

— সুপারক্যাট

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

— প্রচুর ক্রিপস