ক্রস প্ল্যাটফর্ম অ্যাপ্লিকেশনগুলির জন্য কেন "ফ্যাট বাইনারিগুলি" বেশি ব্যবহৃত হয় না?


27

আমি যতদূর জানি, তথাকথিত "ফ্যাট বাইনারি" - এক্সিকিউটেবল ফাইল যা একাধিক সিস্টেমের জন্য মেশিন কোড ধারণ করে - কেবলমাত্র অ্যাপল পিসিতে ব্যবহার করা হয়, এবং এমনকি সেখানে মনে হয় যে তারা কেবল তাদের ব্যবহার করেছে কারণ তাদের থেকে স্থানান্তরিত হওয়ার দরকার ছিল পাওয়ারপিসি থেকে x86।

আজকাল প্রচুর সফ্টওয়্যার ক্রস প্ল্যাটফর্ম, এবং মনে হয় যে একক ফ্যাট বাইনারি তৈরি করা অপারেটিং সিস্টেম এবং আর্কিটেকচারের প্রতিটি সংমিশ্রনের জন্য এক ডজন বা তারপরে বিভিন্ন ডাউনলোডের উপর নজর রাখার চেয়ে অনেক বেশি সহজ হবে, কোনওভাবে পৌঁছে দেওয়ার কথা উল্লেখ না করে গ্রাহকের কাছে যা তারা চায় to

উদাহরণস্বরূপ, কেন এই পদ্ধতিটি কখনই কার্যকর হয় নি তা নিয়ে আমি প্রচুর অনুমান নিয়ে আসতে পারি:

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

তবে যেহেতু আমি সবসময় একটি লাইব্রেরি বা কাঠামোর সাথে কাজ করি যা এই সমস্ত ওএস-নির্দিষ্ট এবং আর্কিটেকচার-নির্দিষ্ট বিশদটি আমার কাছ থেকে লুকিয়ে রাখে, আমি জানি না যে এর সত্যিকারের কোনওটি কতটা সত্য, বা আরও কিছু সমস্যা আছে যা আমি জানি না সম্পর্কিত. সুতরাং, চর্বি বাইনারিগুলি সাধারণত মাল্টি-আর্কিটেকচার এবং / বা মাল্টি-ওএস সফ্টওয়্যার তৈরি করতে ব্যবহার না করার প্রকৃত কারণগুলি কী? (অ্যাপলের বাইরে)


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

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

7
কারণ আমাদের কাছে বাইট কোড এবং ভার্চুয়াল মেশিন রয়েছে যা এই সমস্যাটিকে আরও ভাল সমাধান করে।
রবার্ট হার্ভে

2
আমাকে অবাক করে তোলে, উইন্ডোজ এবং কিছু * এনআইএক্স, উভয়ই কাজ করে এমন একটি পলিগ্লট এক্সিকিউটেবল ফাইল তৈরি করা কি সম্ভব?
এআআআআআআআআআআআআআআআআআআআআআআআআআআআআআআআ 19 এ 19

2
Recordতিহাসিক রেকর্ডের জন্য, ফ্যাট বাইনারিগুলি পিপিসি -> x86 রূপান্তর নয়, 68 কে -> পিপিসি রূপান্তর থেকে তারিখের হয়।
মার্ক

উত্তর:


9

একটি চর্বিযুক্ত বাইনারি পদ্ধতির সর্বাধিক অর্থপূর্ণ হয় যদি:

  1. উভয় আর্কিটেকচার একই সিস্টেমে সহাবস্থান করে
  2. সমস্ত কিছু আর্কিটেকচারের জন্য কমবেশি একই রকম

এ কারণেই এগুলি ক্রস-প্ল্যাটফর্ম কোডের জন্য ব্যবহার করা হয় না (উভয় মানদণ্ড প্রযোজ্য নয়), বা একটি বাইনারি সহ বিভিন্ন লিনাক্স বিতরণকে সমর্থন করার জন্য (1. প্রয়োগ হয় না, 2. একটি নির্দিষ্ট ডিগ্রিতে প্রয়োগ হয়)।

যদি আপনি একটি একক লিনাক্স বিতরণে 32 এবং 64 বিট উভয় সমর্থন করতে চান তবে লিনাক্সে, উভয়ই মানদণ্ড এখনও প্রযোজ্য । তবে কেন বিরক্ত হবেন, যদি আপনার ইতিমধ্যে একাধিক বিতরণকে সমর্থন করতে হয়?

উপর উইন্ডোজ , 16 বিট 32 বিট থেকে রূপান্তরটি উইন্ডোজ এনটি, যা অনেক শুভেচ্ছা 16 বিট উইন্ডোজ দুনিয়া থেকে প্রধান ডেভিয়েশন (ভার্চুয়াল মেমরি, মাল্টি ব্যবহারকারীর অ্যাক্সেস নিয়ন্ত্রণ, এপিআই পরিবর্তন ...) ছিল প্রবর্তনের সঙ্গে প্রাথমিকভাবে ঘটেছে। এই সমস্ত পরিবর্তনগুলির সাথে, 32 এবং 16 বিট বিশ্বকে আলাদা রাখা ভাল ছিল was এনটি ইতিমধ্যে "সাবসিস্টেমগুলি" বিভিন্ন ওএস "পার্সোনালি" (উইন 32, পসিক্স) সমর্থন করে, তাই উইন 16 কে তৃতীয় সাবসিস্টেম তৈরি করা একটি সরল পছন্দ ছিল।

উইন 32 থেকে উইন 64 রূপান্তর একই রকম বড় পরিবর্তনগুলির সাথে জড়িত ছিল না, তবে মাইক্রোসফ্ট যাই হোক না কেন একই ধরণের পন্থা ব্যবহার করেছিল, সম্ভবত এটি প্রমাণিত ও চেষ্টা করার কারণে।


11

ইন্টারনেট বয়সের বিতরণ রসদগুলি দুভাবে ফ্যাট বাইনারিগুলি ছড়িয়ে দেয়:

  1. বিক্রয় কেন্দ্রটি শারীরিক জিনিসগুলিকে জড়িত করে না এবং তাই পণ্যগুলি খুচরা বালুচর স্থানের জন্য প্রতিযোগিতা করে এবং গ্রাহকরা কেনার সুযোগ সীমিত রাখে সে ক্ষেত্রে কম এসকিউ'র পক্ষপাতিত্ব করে।

  2. ব্যান্ডউইথের ব্যয়গুলি নির্দিষ্ট সফ্টওয়্যার প্যাকেজের জন্য সর্বনিম্ন প্রয়োজনীয় বিট সরবরাহ করার পক্ষে হয়। তারের নিচে চর্বিযুক্ত বাইনারি সরবরাহ করা গ্রাহকের অভিজ্ঞতা এবং বিক্রেতার অবকাঠামোগত দক্ষতা উভয়কেই হ্রাস করে।

ফ্যাট বাইনারিগুলি আরও বোঝা যায় যখন সফ্টওয়্যার মোড়ানো শারীরিক মিডিয়া সঙ্কুচিত হয়।


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

2
@ রবার্টহারভে, তবে এইগুলি 5 মিনিটের আমি চেয়ে অপেক্ষা করি না।
আর্টুরো টরেস সানচেজ

2

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

কেবল লিনাক্স / x86-64 এর ক্ষেত্রে প্রতিটি লিনাক্স ডিস্ট্রিবিউশনগুলিতে বাইনারি এক্সিকিউটেবল চালানো সক্ষম করা কার্যত কঠিন (কারণ এটি প্রায়শই এর নির্দিষ্ট সংস্করণ libcবা এর সাথে আবদ্ধ থাকে libstdc++)। ফ্যাটএলএফ বিদ্যমান তবে খুব বেশি সফল নয়।

এমনকি একটি সংজ্ঞায়িত এবিআই এবং নির্দেশ সেট সহ, বিভিন্ন প্রসেসরের ব্র্যান্ডগুলিতে অপ্টিমাইজেশনটি আলাদা হবে - জিসিসির -mtune=native x86 অপ্টিমাইজেশান পতাকাটি দেখুন ।

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

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

উপলভ্য উত্স কোড সহ কিছু (ফ্রি) সফ্টওয়্যার পোর্ট করার জন্য আপনি কাউকে অর্থ প্রদান করতে (বা জিজ্ঞাসা করতে) দিতে পারেন, তবে বাইনারি এক্সিকিউটেবলের পোর্ট করা অবাস্তব।

অবশেষে, বিভিন্ন অবকাঠামো বিভিন্ন অপারেটিং সিস্টেম (প্রদত্ত সোর্স কোড উপলব্ধ আছে) এর মাধ্যমে সাহায্য পাবার পোর্টিং অস্তিত্ব, যেমন কিউটি & Poco

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

বিটিডব্লিউ, কম্পিউটার সিস্টেমগুলি সম্ভবত 1980 এর দশকের শুরু বা 1990-এর দশকের (বা মেইনফ্রেমের যুগে) তুলনায় আজ অনেক কম ভিন্ন ভিন্ন।

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


4
আমি এই ধারণাটিকে বিতর্ক করি যে সফটওয়্যারটিকে "ফ্রি" তৈরি করা এটিকে সহজে পোর্টেবলও করে তোলে।
রবার্ট হার্ভে

3
এটি সফ্টওয়্যারটিকে পোর্টেবল বানায় না, তবে এটি অন্য কোনও প্ল্যাটফর্মের কাছে পোর্ট করার জন্য প্রচেষ্টা ব্যয় করতে সক্ষম করে তোলে (সোর্স কোডটি সংশোধন করার অ্যাক্সেস এবং অধিকার না থাকলে আপনি
বাস্তবে

2
@ রবার্টহারভে নীতিগতভাবে কোনও মৌলিক যোগসূত্র নাও থাকতে পারে তবে ফ্রি সফটওয়্যারটি এতগুলি প্ল্যাটফর্ম জুড়ে ব্যাপকভাবে ছড়িয়ে পড়েছে এবং এতগুলি ক্রস-প্ল্যাটফর্ম তৈরির সরঞ্জাম এবং সরঞ্জাম চেইন তৈরি করার বিভিন্ন কারণ রয়েছে entire
ব্রুস

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

4
পছন্দ করেছেন নিখরচায় সফ্টওয়্যার যা এটি পোর্টে একেবারে বিশৃঙ্খলা বানাতে চূড়ান্ত জগাখালি - আপনি কেবল এমন একটি পৃষ্ঠকে বাড়িয়েছেন যাতে আপনি কোনও নির্দিষ্ট আর্কিটেকচার বা ওএসে এটি ব্যবহারের বিষয়ে যত্নশীল এমন কাউকে ধরতে পারেন যা এটি পোর্ট করতে পারে, বা এমন কোনও পথের প্রস্তাব দেয় যা হতে পারে এমন কোনও পোর্টিং তৈরি করুন যা লোকে রক্তক্ষরণ করে না।
টিম পোস্ট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.