سٹیگنوگرافی کا استعمال کرتے ہوئے ہارڈ ڈرائیو کی جگہ بچائیں۔

جب ہم سٹیگنوگرافی کے بارے میں بات کرتے ہیں، تو لوگ دہشت گردوں، پیڈو فائلوں، جاسوسوں، یا بہترین طور پر، کرپٹو انارکسٹ اور دیگر سائنسدانوں کے بارے میں سوچتے ہیں۔ اور واقعی، اور کس کی ضرورت ہو سکتی ہے۔ چھپائیں بیرونی آنکھوں سے کچھ؟ اس سے ایک عام آدمی کو کیا فائدہ ہو سکتا ہے؟

یہ ایک ہے باہر کر دیتا ہے. اسی لیے آج ہم سٹیگنوگرافی کے طریقوں کا استعمال کرتے ہوئے ڈیٹا کو کمپریس کریں گے۔ اور آخر میں، قاری یہاں تک کہ فائل سسٹم پر مفت گیگا بائٹس کی تعداد بڑھانے کے لیے اپنے قیمتی فوٹو آرکائیوز کو JPEGs میں استعمال کر سکے گا۔

کیا؟

اگر قارئین کو یاد ہو تو سٹیگنوگرافی ایک ایسا عجیب الگورتھم ہے جو ایک معلومات کی موجودگی کو دوسری معلومات کے اندر چھپانا ممکن بناتا ہے۔ اس سے بھی آسان زبان میں: تصویر + فائل == تقریبا ایک ہی تصویر، لیکن بالکل نہیں (تصاویر کے بجائے کچھ بھی ہوسکتا ہے، لیکن عام طور پر ان میں سب کچھ واضح ہوتا ہے)۔ اس بات کا تعین کرنے کا کوئی آسان طریقہ نہیں ہونا چاہیے کہ اندر کچھ ہے یا نہیں۔

لیکن اگر ایک کو دوسرے سے ممتاز نہیں کیا جا سکتا تو کیا کوئی فرق ہے؟ صارف کے نقطہ نظر سے، صارف ریاضی کی درستگی کی پرواہ نہیں کرتا ہے (بٹس کے ایک مخصوص سیٹ سے ظاہر ہوتا ہے)، صرف وہی جو اسے سمجھتا ہے۔

مثال کے طور پر، آئیے ایک پیارے کتے کی تین تصاویر دیکھیں:

خبردار، JPEG!

سائز میں بہت زیادہ فرق کے باوجود، چند لوگ تیسرے ورژن کا انتخاب کریں گے۔ دوسری طرف، پہلی دو تصویروں میں فرق اتنا نمایاں نہیں ہے، اور ان میں معلومات کی مقدار (میرے نقطہ نظر سے) برابر ہو سکتی ہے۔

یہ اصول خود پہلے سے ہی پرانا ہے اور کئی سالوں سے نقصان دہ معلومات کمپریشن طریقوں سے فعال طور پر استحصال کیا جا رہا ہے۔ لیکن ٹوٹنا تعمیر نہیں ہے؛ ہم مسئلے کے زیادہ جدید پہلو میں دلچسپی رکھتے ہیں۔ کیا اضافی سائز کی معلومات کو سرایت کرنا ممکن ہے؟ N فائل میں تاکہ اس کا سائز بڑھ جائے۔ M < Nلیکن تبدیلیاں صارف کے لیے قابل توجہ نہیں تھیں؟

یقیناً آپ کر سکتے ہیں۔ لیکن یہ ابھی کچھ تحفظات کرنے کے قابل ہے:

• سب سے پہلے، طریقہ یونیورسل ہونا چاہیے اور زیادہ تر ان پٹ ڈیٹا پر مثبت نتیجہ دینا چاہیے۔ یعنی اوسطاً، بے ترتیب ان پٹ کے لیے، ذخیرہ شدہ معلومات کی مقدار میں حقیقی کمی ہونی چاہیے۔ "اوسط" کا مطلب ہے کہ اس کے برعکس ہوسکتا ہے، لیکن غالب نہیں ہونا چاہئے۔
• دوم، معلومات کو سرایت کرنے سے پہلے کمپریسڈ کنٹینر کا سائز اسی طرح کمپریس کی گئی ترمیم سے بڑا ہونا چاہیے۔ LSB طریقہ کا استعمال کرتے ہوئے صرف BMP امیجز میں بٹس کا ایک گروپ شامل کرنا سٹیگنوگرافک کمپریشن نہیں ہے، کیونکہ، کسی قسم کے DEFLATE کے ذریعے چلائے جانے کے بعد، اصل تصویر زیادہ تر ممکنہ طور پر چھوٹی ہوگی۔
• تیسرا، نتیجہ اخذ کیا جانا چاہیے اور اس کا موازنہ کلاسیکی طریقوں سے پہلے ہی کمپریس کیے گئے ڈیٹا کے حوالے سے کیا جانا چاہیے۔ یہ ان کی فالتو پن میں اختلافات کے امکانی اثر کو ختم کر دے گا اور عام صورت میں زیادہ موثر کمپریشن فراہم کرے گا۔

کہاں

سٹیگنوگرافی کے استعمال کا مطلب یہ ہے کہ، کمپریسڈ معلومات کے علاوہ، ہمیں کنٹینرز کی ضرورت ہوگی جس میں اسے سرایت کیا جائے گا۔ سرایت شدہ معلومات کی زیادہ سے زیادہ مقدار انفرادی خصوصیات پر منحصر ہے، لیکن ان کی تعداد کے ساتھ پیمانہ کرنا بہت آسان ہے۔ اس لیے، کنٹینر کی شکل عام ہونی چاہیے تاکہ صارف کے پاس ان میں سے کافی ہو کہ وہ "کمپریشن" کے عمل سے کوئی فائدہ حاصل کر سکے۔

اس تناظر میں، گرافکس، آڈیو، اور ویڈیو فائلیں اچھے امیدوار ہیں۔ لیکن، مختلف قسم کے فارمیٹس، کوڈیکس، وغیرہ کی وجہ سے، عملی طور پر ہمارے پاس اتنے زیادہ اختیارات میں سے ایک انتخاب باقی رہ جاتا ہے۔

ان سب باتوں پر غور کرتے ہوئے، میری پسند JPEG پر پڑی۔ تقریباً ہر کسی کے پاس ہے، یہ ذاتی اور کاروباری دونوں مقاصد کے لیے وسیع پیمانے پر استعمال ہوتا ہے، جو کہ زیادہ تر تصاویر کے لیے تقریباً ڈی فیکٹو فارمیٹ ہے۔

یہ منحصر کرتا ہے؟

اس کے بعد قریب اور تکنیکی خاکے اور تفصیل کے بغیر زیادہ وضاحت کے ہیں، لہذا دلچسپی رکھنے والے "ہائی ٹیکنالوجیز" سیکشن میں سکرول کرکے انہیں چھوڑ سکتے ہیں۔

عام خصوصیات

ڈیٹا کو کہیں ایمبیڈ کرنے کے لیے، آپ کو پہلے یہ تعین کرنا ہوگا کہ کہاں ہے۔ فائل سسٹم پر مختلف تصویروں کی تعداد ہو سکتی ہے، جن میں سے صارف صرف چند ہی استعمال کرنا چاہتا ہے۔ ہم کنٹینرز کے ایسے مطلوبہ سیٹ کو لائبریری کہیں گے۔

یہ دو صورتوں میں بنتا ہے: کمپریشن سے پہلے اور ڈیکمپریشن سے پہلے۔ پہلی صورت میں، آپ فائلوں کے فائلوں کے ناموں کا ایک سیٹ (یا اس سے بہتر ابھی تک، ان کے لیے باقاعدہ اظہار) استعمال کر سکتے ہیں، لیکن دوسری صورت میں، کچھ زیادہ قابل اعتماد کی ضرورت ہے: صارف انہیں کاپی کر کے فائل سسٹم میں منتقل کر سکتا ہے۔ ، اس طرح ان کی صحیح شناخت ہونے سے روکتا ہے۔ لہذا، تمام ترامیم کے بعد ان کی ہیشز (md5 کافی ہے) کو ذخیرہ کرنا ضروری ہے۔

اس صورت میں، پورے فائل سسٹم میں باقاعدہ اظہار کا استعمال کرتے ہوئے ابتدائی تلاش کرنے کا کوئی فائدہ نہیں ہے؛ یہ ایک مخصوص روٹ ڈائرکٹری کی وضاحت کرنے کے لئے کافی ہے. اس میں ایک خاص آرکائیو فائل کو محفوظ کیا جائے گا، جس میں وہ ہیشز ہوں گی، ساتھ ہی دیگر میٹا انفارمیشن بھی جو بعد میں کمپریسڈ معلومات کی بازیافت کے لیے ضروری ہیں۔

یہ سب کسی بھی سٹیگنوگرافک ڈیٹا کمپریشن الگورتھم کے نفاذ پر یکساں طور پر لاگو ہوتا ہے۔ ڈیٹا کمپریشن اور ریکوری کے عمل کو خود پیکنگ اور ان پیکنگ کہا جا سکتا ہے۔

F5

اب جبکہ یہ واضح ہو گیا ہے کہ ہم کیا کر رہے ہیں اور کیوں، مقصد کے حصول کے لیے الگورتھم کو بیان کرنا باقی ہے۔ آئیے جے پی ای جی فائل کو انکوڈنگ کرنے کے عمل کو یاد کرتے ہیں (باؤمن نیشنل لائبریری کے ویکی کا شکریہ):

اسے دیکھتے ہوئے، فوری طور پر چند تبصرے کرنا بہتر ہے:

• JPEG فائل کے سائز کو کسی قسم کے Winrar کے ساتھ کمپریس کرنے کی کوشش کیے بغیر بھی بہترین سمجھا جا سکتا ہے۔
• کم از کم قابل قبول کارکردگی فراہم کرنے کے لیے صرف ذخیرہ شدہ معلومات (جو کہ مجرد کوزائن ٹرانسفارم، DCT سے آؤٹ پٹ ہے) میں ترمیم کی جا سکتی ہے۔
• صارف کے لیے قابل توجہ صنعتی پیمانے پر ڈیٹا کو ضائع نہ کرنے کے لیے، ہر ایک تصویر میں کم از کم ترمیم کرنا ضروری ہے۔

الگورتھم کا ایک پورا خاندان ان شرائط پر پورا اترتا ہے، جن سے آپ خود کو واقف کر سکتے ہیں۔ اس اچھی پیشکش میں. ان میں سب سے جدید الگورتھم ہے۔ F5 اینڈریاس ویسٹ فیلڈ کی طرف سے، چمک کے اجزاء کے ڈی سی ٹی کوفیشینٹس کے ساتھ کام کرتے ہوئے (انسانی آنکھ اپنی تبدیلیوں کے لیے کم سے کم حساس ہوتی ہے)۔ موجودہ JPEG فائل کے ساتھ کام کرتے وقت اس کی عمومی ترتیب اس طرح ظاہر ہوتی ہے:

F5 بلاک میٹرکس انکوڈنگ پر مبنی ایک جدید ایمبیڈنگ تکنیک کا استعمال کرتا ہے۔ قارئین اوپر دیے گئے لنک پر اس کے بارے میں اور خود الگورتھم کے بارے میں مزید جان سکتے ہیں، لیکن ہم بنیادی طور پر اس حقیقت میں دلچسپی رکھتے ہیں کہ اس کی مدد سے آپ اتنی ہی معلومات کو سرایت کرتے وقت کم تبدیلیاں کر سکتے ہیں، استعمال شدہ کنٹینر کا سائز جتنا بڑا ہو گا۔ اور الگورتھم کو انجام دینے کے لیے صرف سادہ Huffman اور RLE (de)کوڈنگ آپریشنز کرنے کی ضرورت ہے۔

تبدیلیاں بذات خود انٹیجر گتانکوں میں کی جاتی ہیں اور ان کی مطلق قدر کو ایک سے کم کرنے پر آتی ہیں، جو عام طور پر ڈیٹا کمپریشن کے لیے F5 استعمال کرنے کی اجازت دیتی ہے۔ نقطہ یہ ہے کہ JPEG میں اقدار کی شماریاتی تقسیم کی وجہ سے Huffman انکوڈنگ کے بعد مطلق قدر میں کم گتانک زیادہ تر ممکنہ طور پر کم بٹس پر قبضہ کرے گا۔

صفر کی تشکیل کی صورت میں (نام نہاد کمی)، ذخیرہ شدہ معلومات کی تعداد اس کے سائز سے کم ہو جائے گی، کیونکہ سابقہ ​​آزاد عدد صفر کے RLE انکوڈ شدہ ترتیب کا حصہ بن جائے گا:

ترمیم

ڈیٹا پروٹیکشن اور کمپریشن آرتھوگونل مسائل ہیں، لہذا اصل الگورتھم سے خفیہ پاس ورڈ کی تبدیلی کو نظر انداز کیا جا سکتا ہے۔ مزید برآں، ہمیں یہ جاننے کی ضرورت ہے کہ ڈیٹا کو کیسے نکالا جائے، اس لیے اس کے لیے ضروری تمام معلومات (کون سے کنٹینرز استعمال کیے گئے، کس ترتیب میں وغیرہ) ایک علیحدہ فائل میں ریکارڈ کیے جائیں اور آرکائیور کے ذریعے مفت پڑھنے کے لیے کھلے رہیں۔

اصل الگورتھم کو خفیہ پیغامات کی ترسیل کے لیے ڈیزائن کیا گیا ہے، اس لیے یہ ایک وقت میں صرف ایک کنٹینر کے ساتھ کام کرتا ہے، یہ فرض کرتے ہوئے کہ صارف خود اسے حصوں میں تقسیم کر دے گا، اگر ضرورت ہو تو، اگر کوئی ہو۔ مزید برآں، جب ہر کنٹینر میں آزادانہ طور پر ایمبیڈ کیا جاتا ہے، تو آپ کو پہلے سے یہ جاننا ہوگا کہ ہر ایک میں کتنے بٹس ڈیٹا ڈالنا ہے۔ لہٰذا، لائبریری کے ہر عنصر کے گتانک کو ایک تجریدی بڑے میں ملا کر اصل الگورتھم کے مطابق اس کے ساتھ کام کرنا چاہیے۔

چونکہ اصل F5 کنٹینر کے سائز کے 12% تک کی اجازت دیتا ہے، اس لیے یہ ترمیم زیادہ سے زیادہ صلاحیت میں بھی اضافہ کرے گی: پوری لائبریری کے سائز کا "12% تک" "12% تک" کے حجم سے زیادہ یا اس کے برابر ہے۔ "اس کے ہر ایک عنصر سے۔

کوڈفائیڈ جنرل اسکیم مندرجہ ذیل ہے:

الگورتھم خود

اب وقت آگیا ہے کہ الگورتھم کو شروع سے آخر تک بیان کریں، تاکہ قاری کو اندھیرے میں نہ رکھا جا سکے۔

• صارف ریگولر ایکسپریشن اور سرچ روٹ ڈائرکٹری کا استعمال کرتے ہوئے بائنری کمپریس ایبل ڈیٹا M اور لائبریری L کی وضاحت کرتا ہے۔
• جس ترتیب سے وہ FS پر ظاہر ہوتے ہیں، لائبریری کے عناصر MC بناتے ہیں:
  • گتانک C کی ایک سیریز کو فائل ڈیٹا سے ڈی کوڈ کیا جاتا ہے۔
  • ایم سی <- ایم سی | ج;
• پیرامیٹر k کا تعین خوفناک عدم مساوات کی بنیاد پر کیا جاتا ہے: |M| * 8 / (count_full(MC) + count_ones(MC) * k_rate(k)) < k / ((1 << k) - 1);
• اگلا لیا گیا۔ n = (1 << k) - 1 MC سے غیر صفر عناصر کے کم سے کم اہم بٹس اور اس پر لکھا گیا ہے۔ a:
  • میجک ہیش فنکشن کو سمجھا جاتا ہے۔ f، ایک n-bit لفظ کی نمائندگی کرتا ہے۔ a کے بٹ تک s;
  • اگر s == 0، پھر کسی بھی چیز کو تبدیل کرنے کی ضرورت نہیں ہے اور الگورتھم اگلے گتانکوں کی طرف بڑھتا ہے۔
  • قابلیت کی مطلق قدر کو کم کریں جس کے لیے ذمہ دار ہے۔ s- ارے لفظ میں تھوڑا سا a;
  • اگر کمی کے نتیجے میں کمی واقع ہوتی ہے (گتانک 0 ہو جاتا ہے)، تو شروع سے مرحلہ دہرائیں؛
• تمام گتانکوں کو RLE اور Huffman کے ذریعے انکوڈ کیا جاتا ہے، جو سورس فائلوں کو لکھا جاتا ہے۔
• پیرامیٹر k کو آرکائیو فائل میں لکھا جاتا ہے۔
• ایک MD5 ہیش کا حساب ہر فائل L سے ان کے اصل مقام کی ترتیب میں کیا جاتا ہے اور آرکائیو فائل میں لکھا جاتا ہے۔

ہائی ٹیک۔

الگورتھم کی سادہ شکل اور دیگر اعلیٰ سطحی زبانوں (خاص طور پر کوڑا کرکٹ جمع کرنے والی) زبانوں میں عمل درآمد خوفناک کارکردگی پیش کرے گا، اس لیے میں نے ان تمام پیچیدگیوں کو خالص C میں لاگو کیا اور عملدرآمد کی رفتار اور دونوں لحاظ سے متعدد اصلاحیں کیں۔ میموری (آپ کو اندازہ نہیں ہے کہ ڈی سی ٹی سے پہلے بھی کمپریشن کے بغیر ان تصویروں کا وزن کتنا ہے)۔ لیکن اس کے باوجود، سب سے پہلے پھانسی کی رفتار نے بہت زیادہ مطلوبہ چھوڑ دیا، لہذا میں پورے عمل اور استعمال شدہ طریقوں کو بیان نہیں کروں گا.

کراس پلیٹ فارم libjpeg، pcre اور tinydir لائبریریوں کے امتزاج سے حاصل کیا جاتا ہے، جس کے لیے ہم ان کا شکریہ ادا کرتے ہیں۔ پہلے سے طے شدہ طور پر، سب کچھ نارمل کے ذریعے مرتب کیا جاتا ہے۔ make، لہذا ونڈوز صارفین اپنے لیے کچھ سائگ وِن انسٹال کرنا چاہتے ہیں، یا خود بصری اسٹوڈیو اور لائبریریوں سے نمٹنا چاہتے ہیں۔

عمل درآمد کنسول یوٹیلیٹی اور لائبریری کی شکل میں دستیاب ہے۔ جو لوگ دلچسپی رکھتے ہیں وہ گیتھب پر ریپوزٹری میں ریڈمی میں مؤخر الذکر کو استعمال کرنے کے بارے میں مزید معلومات حاصل کرسکتے ہیں، جس کا لنک میں پوسٹ کے آخر میں منسلک کروں گا۔ اور یہاں ہم کام کی تفصیل اور مظاہرے کی طرف بڑھتے ہیں۔

استعمال کیسے کریں

احتیاط سے۔ استعمال شدہ تصاویر کو منتقل کیا جا سکتا ہے، نام تبدیل کیا جا سکتا ہے اور اپنی مرضی کے مطابق کاپی کیا جا سکتا ہے۔ تاہم، آپ کو انتہائی محتاط رہنا چاہیے اور ان کے مواد کو کسی بھی طرح تبدیل نہیں کرنا چاہیے۔ تھوڑا سا تبدیل کرنے سے ہیش میں خلل پڑے گا اور معلومات کو بازیافت کرنا ناممکن ہو جائے گا۔

فرض کریں کہ تالیف کے بعد ہمیں ایگزیکیوٹیبل فائل f5ar ملتی ہے۔ آپ پرچم کا استعمال کرتے ہوئے اس کے استعمال کے امکانات کا حساب لگانے کے لیے لائبریری کے سائز کا تجزیہ کر سکتے ہیں -a: ./f5ar -a [папка поиска] [Perl-совместимое регулярное выражение]. پیکیجنگ ٹیم کے ذریعہ کی جاتی ہے۔ ./f5ar -p [папка поиска] [Perl-совместимое регулярное выражение] [упаковываемый файл] [имя архива]، اور استعمال کرتے ہوئے پیک کھولنا ./f5ar -u [файл архива] [имя восстановленного файла].

کام کا مظاہرہ

طریقہ کار کی تاثیر کو ظاہر کرنے کے لیے، میں نے سروس سے کتوں کی 225 بالکل مفت تصاویر کا مجموعہ اپ لوڈ کیا Unsplash سے. ان میں سے ہر ایک کی کوالٹی عام صارف کی تصاویر سے قدرے زیادہ ہے، لیکن پھر بھی۔ ان میں سے ہر ایک کو libjpeg کا استعمال کرتے ہوئے دوبارہ انکوڈ کیا گیا تاکہ مجموعی سائز پر لائبریری کی انکوڈنگ خصوصیات کے اثرات کو بے اثر کیا جا سکے۔ کمپریس ایبل ڈیٹا کی بدترین مثال کی نشاندہی کرنے کے لیے، ایک بے ترتیب 36 میٹر (کل سائز کا 5% سے تھوڑا زیادہ) یکساں طور پر تقسیم شدہ فائل ڈی ڈی کا استعمال کرتے ہوئے تیار کی گئی تھی۔

جانچ کا عمل بہت آسان ہے:

$ ls
binary_data dogs f5ar
$ du -sh dogs/
633M dogs/
$ du -h binary_data
36M binary_data

$ ./f5ar -p dogs/ .*jpg binary_data dogs.f5ar
Reading compressing file... ok
Initializing the archive... ok
Analysing library capacity... done in 16.8s
Detected somewhat guaranteed capacity of 48439359 bytes
Detected possible capacity of upto 102618787 bytes
Compressing... done in 32.6s
Saving the archive... ok

$ ./f5ar -u dogs/dogs.f5ar unpacked
Initializing the archive... ok
Reading the archive file... ok
Filling the archive with files... done in 1.2s
Decompressing... done in 17.5s
Writing extracted data... ok

$ sha1sum binary_data unpacked
ba7ade4bc77881ab463121e77bbd4d41ee181ae9 binary_data
ba7ade4bc77881ab463121e77bbd4d41ee181ae9 unpacked
$ du -sh dogs/
563M dogs/

یا شائقین کے لیے اسکرین شاٹ

جیسا کہ آپ دیکھ سکتے ہیں، ہارڈ ڈرائیو پر اصل 633 + 36 == 669 میگا بائٹس ڈیٹا سے، ہم نے ایک اچھے 563 کے ساتھ اختتام کیا، جس سے ہمیں ~ 1,188 کا کمپریشن تناسب ملا۔ اس بنیادی فرق کی وضاحت انتہائی چھوٹے نقصانات سے کی گئی ہے، جیسا کہ کلاسیکی طریقوں (جیسے tinyjpg) کا استعمال کرتے ہوئے JPEG فائلوں کو بہتر بنانے کے وقت حاصل کیا جاتا ہے۔ قدرتی طور پر، سٹیگنوگرافک کمپریشن کا استعمال کرتے وقت، معلومات صرف "گمشدہ" نہیں ہوتی، بلکہ دوسرے ڈیٹا کو انکوڈ کرنے کے لیے استعمال ہوتی ہے۔

اس میں جو بھی ترمیمات ہیں، وہ بالکل نظر سے اوجھل ہیں۔ نیچے دیے گئے بگاڑنے والے کے تحت، قاری آنکھ سے اور تبدیل شدہ جز کی قدروں کو اصل سے گھٹا کر فرق کا اندازہ لگا سکتا ہے (جتنا زیادہ رنگ خاموش ہوگا، فرق اتنا ہی کم ہوگا):

تصاویر کے لنکس جو ہیبراسٹوریج پر فٹ نہیں ہوتے ہیں۔

اصل - https://i.ibb.co/wNDLNcZ/1.jpg
ترمیم شدہ - https://i.ibb.co/qWvpfFM/1.jpg
فرق - https://i.ibb.co/2ZzhHfD/diff.jpg

اس کے بجائے کسی نتیجے کے

مجھے امید ہے کہ میں قارئین کو قائل کرنے میں کامیاب ہو گیا ہوں کہ اس طرح کے طریقے ممکن ہیں اور زندگی گزارنے کا حق رکھتے ہیں۔ تاہم، ہارڈ ڈرائیو یا ایک اضافی چینل (نیٹ ورک ٹرانسمیشن کے لیے) خریدنا اس طرح پیسہ بچانے کی کوشش کرنے سے کہیں زیادہ آسان آپشن لگتا ہے۔ ایک طرف، یہ سچ ہے؛ وسیع ترقی اکثر آسان اور زیادہ قابل اعتماد ہوتی ہے۔ لیکن دوسری طرف، ہمیں شدید کے بارے میں نہیں بھولنا چاہئے. بہر حال، اس بات کی کوئی گارنٹی نہیں ہے کہ کل آپ دکان پر آ کر اپنے آپ کو ایک اور ہزار ٹیرابائٹ ہارڈ ڈرائیو خرید سکیں گے، لیکن آپ ہمیشہ وہ استعمال کر سکتے ہیں جو آپ پہلے ہی گھر میں پڑی ہیں۔

-> GitHub کے

ماخذ: www.habr.com