FreeBSD jails بمقابلہ Docker containers: فرق کیا ہے؟

FreeBSD jails بمقابلہ Docker containers، ایک پیراگراف میں

FreeBSD jails اور Docker containers ایک ہی مسئلے کو دو مختلف طریقوں سے حل کرتے ہیں۔ دونوں ایک ہی shared kernel پر isolated userlands چلاتے ہیں، اس لیے ان میں سے کوئی بھی virtual machine نہیں ہے۔ فرق اس بات میں ہے کہ ان کے اندر کیا چلتا ہے۔ Docker container ایک registry سے حاصل کی گئی layered image کے ایک process کو چلاتا ہے۔ jail مکمل FreeBSD userland چلاتا ہے: اس کا اپنا /etc، اپنے rc startup scripts، اپنا pkg database، اور جتنے چاہیں processes ہوتے ہیں۔ اس صفحے پر موجود تقریباً ہر دوسرا فرق اسی بنیادی فرق سے پیدا ہوتا ہے۔

SSD Nodes، FreeBSD images فراہم نہیں کرتا۔ آپ اس platform پر FreeBSD server کرائے پر نہیں لے سکتے، اور ذیل میں دی گئی کوئی چیز ایسی machine کے لیے installation guide نہیں ہے جسے آپ یہاں خرید سکتے ہوں۔ یہ دو isolation models کا تقابل ہے، تاکہ آپ سمجھ سکیں کہ کسی workload کو حقیقتاً کون سا model درکار ہے، اور FreeBSD ٹیم کی setup کو اندازے کے بغیر پڑھ سکیں۔

اصل میں jail کیا ہوتا ہے

Jails مارچ 2000 میں FreeBSD 4.0 کے ساتھ متعارف ہوئے۔ اس وجہ سے یہ cgroups سے پرانے اور تقریباً ایک دہائی سے Docker سے بھی پرانے ہیں۔ یہ طریقۂ کار ایک kernel call پر مشتمل ہے۔ jail(8) ایک directory tree لیتا ہے اور اس کے اندر processes شروع کرتا ہے، جن کے ساتھ jail ID منسلک ہوتی ہے۔ اس کے بعد kernel اس ID رکھنے والے ہر process کے لیے operations کا ایک مقررہ مجموعہ مسترد کر دیتا ہے۔ jailed process اپنے jail سے باہر کے processes نہیں دیکھ سکتا، filesystems کو mount یا unmount نہیں کر سکتا، kernel modules load نہیں کر سکتا، اور ان network addresses پر bind نہیں کر سکتا جو jail کو نہیں دیے گئے۔ سیکھنے کے لیے کوئی الگ namespace type نہیں ہے اور نہ ہی ہر feature کے لیے الگ opt-in درکار ہے۔ یہ پابندیاں ایک ہی unit کے طور پر لاگو ہوتی ہیں، اور jail کے config میں parameters کے ذریعے ان میں تبدیلی کی جاتی ہے۔

Host پر jls چلنے والے jails کی فہرست دکھاتا ہے، جبکہ jexec web sh آپ کو web نام والے jail کے اندر shell میں لے جاتا ہے۔

آپ ایک directory میں FreeBSD userland رکھ کر jail بناتے ہیں۔ base system یہ کام آپ کے لیے کرتا ہے:

sudo bsdinstall jail /usr/local/jails/containers/web

یہ آپ کی release کے لیے base distribution set fetch کرتا ہے اور عام post-install steps چلاتا ہے۔ اس لیے آپ root password مقرر کرتے ہیں اور timezone منتخب کرتے ہیں، بالکل اسی طرح جیسے نئے server پر کرتے ہیں۔ نتیجے میں ایک folder کے اندر FreeBSD installation موجود ہوتی ہے۔ اس کے بعد آپ اسے /etc/jail.conf میں بیان کرتے ہیں:

web {
  host.hostname = "web.example.internal";
  path = "/usr/local/jails/containers/web";
  ip4.addr = "10.0.0.10";
  exec.start = "/bin/sh /etc/rc";
  exec.stop = "/bin/sh /etc/rc.shutdown";
  mount.devfs;
}

اسے start کریں، پھر اس کی جانچ کریں:

sudo service jail start web
jls

jls میں اب web کو JID، اس کے hostname اور IP address کے ساتھ دکھائی دینا چاہیے۔ اگر jail ظاہر نہ ہو تو sudo jail -c web براہِ راست چلائیں۔ یہ foreground میں وہی configuration لاگو کرتا ہے اور وہ parameter دکھاتا ہے جسے یہ قبول نہیں کر سکا، بجائے اس کے کہ failure کو service output میں پوشیدہ چھوڑ دے۔

جس line کو دوبارہ پڑھنا چاہیے وہ exec.start = "/bin/sh /etc/rc" ہے۔ Jail شروع کرنے سے اس کے اندر FreeBSD کی معمول کی boot script چلتی ہے۔ اس لیے jail اپنے /etc/rc.conf میں enabled ہر service شروع کر دیتا ہے۔ Docker container میں اس کے مساوی کوئی step نہیں ہوتا، کیونکہ وہ image کے entrypoint process کو چلاتا ہے اور اس process کے رکنے پر خود بھی رک جاتا ہے۔

آپ کو سافٹ ویئر کیسے ملتا ہے: images اور registries بمقابلہ وہ userland جسے آپ خود بھرتے ہیں

یہ وہ فرق ہے جو پہلے ہی دن محسوس ہوتا ہے۔

Docker میں آپ سافٹ ویئر کا نام بتاتے ہیں اور وہ آپ کو مل جاتا ہے۔ docker pull nginx ایک layered، content-addressed image حاصل کرتا ہے جسے کسی دوسرے شخص نے build اور test کیا ہوتا ہے، جبکہ docker compose up -d اسے اس کے volumes اور network کے ساتھ start کرتا ہے۔ registry ہی اصل product ہے۔ Docker workflow کی زیادہ تر قدر اس بات میں ہے کہ ہزاروں projects ایک working image publish کرتے ہیں۔ اسی وجہ سے VPS پر Docker چلانا کسی بڑے project کے بجائے مختصر کام بن جاتا ہے۔

FreeBSD میں jail images کے لیے کوئی default public registry شامل نہیں ہوتی۔ آپ ایک خالی userland بناتے ہیں اور اس میں سافٹ ویئر install کرتے ہیں، بالکل اسی طرح جیسے bare server تیار کرتے ہیں۔ اس میں زیادہ typing ہوتی ہے۔ یہ عمل زیادہ شفاف بھی ہے، کیونکہ jail میں وہی چیز چلتی ہے جو pkg نے host کے استعمال کردہ اسی package set سے اس میں install کی ہو۔

Tooling اس عمل کو مختصر بنا دیتی ہے۔ BastilleBSD عام jail manager ہے اور یہ ایک package ہے:

sudo pkg install bastille
sudo sysrc bastille_enable=YES
sudo bastille setup
sudo bastille bootstrap 15.1-RELEASE

bastille setup آپ کے لیے networking، storage اور firewall configure کرتا ہے۔ bastille bootstrap ایک بار release download کرتا ہے، اور اس کے بعد بننے والی ہر jail اسے دوبارہ استعمال کرتی ہے۔ FreeBSD 15.1 موجودہ production release ہے، جو June 2026 میں جاری ہوئی؛ آپ جو release چلا رہے ہیں، اس کے مطابق اسے تبدیل کریں۔

اس کے بعد jail بنانا ایک command کا کام ہے، اور اسے بھرنا ایک مزید command کا:

sudo bastille create web 15.1-RELEASE 10.17.89.10/24
sudo bastille pkg web install nginx
sudo bastille service web nginx start
sudo bastille console web

bastille console web jail کے اندر login shell فراہم کرتا ہے، جبکہ bastille list دکھاتا ہے کہ host پر کیا موجود ہے۔ Build کو دوبارہ چلانے کے لیے Bastille templates مراحل کو ایک file میں محفوظ کرتے ہیں اور انہیں jail پر apply کرتے ہیں۔ یہ اس ماحول میں Dockerfile سے سب سے قریب چیز ہے۔ ہر jail پر template دوبارہ apply کیا جاتا ہے۔ کچھ بھی پہلے سے built حالت میں نہیں آتا۔

خلاصہ واضح ہے۔ Docker آپ کو دوسرے لوگوں کے builds فراہم کرتا ہے۔ Jails میں آپ خود software installs کرتے ہیں۔ اگر آپ کی فہرست میں موجود سافٹ ویئر صرف container image کے طور پر ship ہوتا ہے اور اس کے علاوہ کچھ نہیں، تو کسی دوسرے معیار پر غور کرنے سے پہلے ہی فیصلہ ہو جاتا ہے۔

حالت اور اپ گریڈز: ZFS کیا تبدیلی لاتا ہے

Docker جان بوجھ کر state کو الگ رکھتا ہے۔ Container filesystem عارضی ہوتا ہے، آپ کا data named volume یا bind mount میں رہتا ہے، اور upgrade میں docker compose pull کے بعد docker compose up -d ہوتا ہے۔ Container تبدیل کر دیا جاتا ہے، اور جو کچھ آپ نے volume میں نہیں رکھا وہ ضائع ہو جاتا ہے۔ جب آپ اس اصول پر عمل کرتے ہیں تو یہ ایک مفید خصوصیت ہے، لیکن اسے بھولنے پر data loss کا واقعہ بن جاتی ہے۔ اسی لیے Compose stack میں bind mounts اور named volumes کے درمیان انتخاب بہت اہم ہے۔

Jail state کو الگ نہیں کرتا، اور یہ ZFS کی وجہ سے ممکن ہے۔ پوری jail ایک dataset ہوتی ہے:

sudo zfs snapshot zroot/jails/containers/web@pre-upgrade
sudo pkg -j web upgrade
sudo zfs rollback zroot/jails/containers/web@pre-upgrade

اسے چلانے سے پہلے zfs list کے ذریعے dataset کا اصل نام چیک کریں؛ اوپر دیا گیا path وہ layout ہے جو handbook استعمال کرتا ہے۔ Snapshot بنانے میں تقریباً ایک second لگتا ہے، اور جب تک jail کے contents تبدیل نہ ہوں، یہ تقریباً کوئی اضافی space استعمال نہیں کرتا۔ اگر upgrade سے service خراب ہو جائے تو rollback پورے userland کو اس کی سابقہ حالت میں واپس لے آتا ہے۔ اس میں package database اور وہ config files بھی شامل ہیں جنہیں آپ نے رات 2 بجے دستی طور پر edit کیا تھا۔ Docker میں اس کا built-in متبادل نہیں ہے، کیونکہ اس کا model یہ فرض کرتا ہے کہ آپ کو کبھی ایسا snapshot درکار ہی نہیں ہوگا۔

zfs clone دوسرا اہم حصہ ہے۔ Snapshot کا clone ایک نئی writable jail ہوتی ہے جو اپنے parent کے ساتھ غیر تبدیل شدہ blocks share کرتی ہے۔ اس لیے 3 GB کی jail کی staging copy disk پر تقریباً کوئی اضافی لاگت نہیں ڈالتی، جب تک آپ اس میں تبدیلیاں شروع نہ کریں۔ اسی طریقے سے FreeBSD admin ایسی jail بناتا ہے جو production کے عین مطابق ہو، تاکہ اس میں upgrade کی مشق کی جا سکے۔

Base system upgrade، packages سے الگ ہوتا ہے۔ ایسی jail کے لیے جو userland کی اپنی copy رکھتی ہو:

sudo freebsd-update -b /usr/local/jails/containers/web fetch install

Thin jails یہ کام بار بار کرنے سے بچاتی ہیں۔ وہ nullfs کے ذریعے ایک مشترکہ read-only base mount کرتی ہیں اور ہر jail کو اپنی الگ چھوٹی writable layer دیتی ہیں۔ اس طرح آپ base کو ایک بار patch کرتے ہیں اور ہر jail میں اس کا نتیجہ نظر آتا ہے۔ Bastille بطور default thin jails بناتا ہے۔

نیٹ ورکنگ: published ports بمقابلہ addressing کا فیصلہ

Docker آپ کے لیے نیٹ ورکنگ کا فیصلہ کرتا ہے اور آپ سے صرف مستثنیٰ ports publish کرنے کو کہتا ہے۔ Containers ایک bridge پر آتے ہیں، user-defined network میں service name کے ذریعے ایک دوسرے تک پہنچتے ہیں، اور -p 8080:80 ان میں سے ایک کو host کے لیے exposed کرتا ہے۔ Docker یہ عمل ممکن بنانے کے لیے اپنے packet filter rules لکھتا ہے۔ اسی طریقے سے published container port براہِ راست ufw سے آگے نکل جاتا ہے۔

جیل میں آپ کو شروع ہی میں ماڈل منتخب کرنا ہوتا ہے، اور دو ماڈل موجود ہیں۔

Shared IP۔ ip4.addr = "10.0.0.10" یہ address کسی موجودہ host interface میں شامل کرتا ہے اور jail کو اسی address تک محدود کرتا ہے۔ jail کا اپنا network stack نہیں ہوتا، اس لیے وہ اپنا firewall نہیں چلا سکتی۔ یہ ہر address پر واقعی bind بھی نہیں کر سکتی۔ جب jailed socket 0.0.0.0 کے لیے درخواست کرتا ہے تو kernel اسے jail کے اپنے address پر rewrite کر دیتا ہے۔ ایک ہی address کے port 80 پر دو jails بیک وقت listen نہیں کر سکتیں۔ اس لیے ہر jail کو الگ address دیں، یا سامنے reverse proxy رکھیں۔

VNET۔ jail میں vnet; شامل کریں تو اسے مکمل network stack مل جاتا ہے: اس کے اپنے interfaces، اپنی routing table، اور اپنے firewall rules۔ اسے host سے epair کے ذریعے جوڑیں۔ یہ ایک virtual cable ہے، جس کا ایک سرا ہر جانب ہوتا ہے، اور host والے سرے کو bridge پر رکھیں۔ یہ Docker کے فراہم کردہ ماڈل سے سب سے زیادہ مشابہ ہے، اور Bastille کے -V اور -B jail types کے پیچھے یہی mode استعمال ہوتا ہے۔

Host port کو jail میں forward کرنا pf redirect rule ہے۔ Bastille اسے اس طرح wrap کرتا ہے:

sudo bastille rdr web tcp 80 80

یہاں EXPOSE موجود نہیں اور automatic publishing بھی نہیں ہوتی۔ کسی jail تک کوئی چیز نہیں پہنچ سکتی جب تک اس کا address یا redirect rule اس کی اجازت نہ دے۔ آغاز میں یہ طریقہ زیادہ کام لیتا ہے، لیکن firewall زیادہ پرسکون رہتا ہے۔

وسائل محدودیت: cgroups بمقابلہ rctl

Docker، cgroups کے ذریعے container پر حد مقرر کرتا ہے، اور یہ حد وہیں موجود ہوتی ہے جہاں container کی تعریف کی گئی ہو: command line پر --memory=1g --cpus=1.5، یا Compose file میں متعلقہ keys کے ذریعے۔ اگر آپ پہلے ہی VPS پر Docker Compose file میں اپنا stack رکھتے ہیں، تو limit اسی service کے ساتھ موجود رہتی ہے جس پر اس کا اطلاق ہوتا ہے، اور git میں اس کے ساتھ منتقل ہوتی ہے۔

FreeBSD، rctl استعمال کرتا ہے، اور اسے ایک subsystem کے طور پر فعال کرنا ضروری ہے۔ Resource accounting بطور default بند ہوتی ہے، کیونکہ ہر allocation پر اس کی کچھ لاگت آتی ہے۔ tunable کو /boot/loader.conf میں شامل کریں اور reboot کریں:

kern.racct.enable=1

پھر ایک rule مقرر کریں اور اسے monitor کریں:

sudo rctl -a jail:web:vmemoryuse:deny=1g
rctl -hu jail:web

rctl -hu jail:web jail کا موجودہ استعمال انسانی فہم کے units میں دکھاتا ہے۔ اس سے آپ دیکھ سکتے ہیں کہ کسی چیز کے ناکام ہونے سے پہلے استعمال limit کے کتنا قریب پہنچ چکا ہے۔ deny action، limit سے تجاوز کرنے والی allocation کو jail کے اندر ناکام بنا دیتا ہے۔ یوں host پر kill message دیکھنے کے بجائے آپ کو application کی اپنی allocation error نظر آتی ہے۔

rctl -a کے ذریعے شامل کیے گئے rules اگلے reboot پر ختم ہو جاتے ہیں۔ FreeBSD کی rctl service انہیں /etc/rctl.conf سے دوبارہ load کرتی ہے۔ اس لیے rule اس file میں لکھیں اور service فعال کریں:

sudo sysrc rctl_enable=YES

یہ وہ معاملہ ہے جہاں Docker واضح طور پر زیادہ آسان ہے۔ Compose file میں موجود limit کو اسی service کے ساتھ review کیا جاتا ہے جس پر یہ پابندی عائد کرتی ہے۔ rctl rule ایک الگ file میں موجود ایسی line ہوتی ہے جو کسی ایسے jail کا نام دیتی ہے جس کی تعریف کہیں اور کی گئی ہو۔

جب جواب virtual machine ہو: bhyve

Jail میزبان kernel کا اشتراک کرتا ہے، اس لیے کچھ کام مستقل طور پر اس کی دسترس سے باہر رہتے ہیں۔ یہ مختلف kernel version نہیں چلا سکتا، kernel module لوڈ نہیں کر سکتا، اور Linux binaries کو اس طرح نہیں چلا سکتا جیسے Linux container چلاتا ہے۔ FreeBSD میں Linux compatibility layer موجود ہے جسے linuxulator کہتے ہیں، لیکن یہ Linux system calls کے ایک subset کو نافذ کرتی ہے۔ یہ من مانے Linux images کے لیے عمومی حل نہیں ہے۔

bhyve، FreeBSD کا hypervisor ہے۔ جب آپ کو حقیقی machine boundary درکار ہو تو یہی درست tool ہے: مختلف operating system، مختلف kernel، یا ایسا tenant جس کے ساتھ آپ kernel کا اشتراک نہیں کرنا چاہتے۔ اس کے لیے shared memory کے بجائے reserved memory درکار ہوتی ہے، اور patch کرنے کے لیے ایک دوسرا kernel بھی درکار ہوتا ہے۔ Linux پر containers اور مکمل virtual machines کے درمیان انتخاب بھی یہی ہوتا ہے۔ اسی انتخاب سے طے ہوتا ہے کہ آپ کو ایسا VPS درکار ہے جو nested virtualization کو support کرے۔

وہ ecosystem جو زیادہ تر teams کے Docker استعمال کرنے کی اصل وجہ ہے

اوپر بیان کی گئی ہر بات model سے متعلق ہے۔ زیادہ تر teams کے لیے انتخاب کا فیصلہ ہر model کے اردگرد موجود ecosystem کے حجم سے ہوتا ہے۔

Docker، Docker Hub اور GHCR، docker compose، جب ایک box کافی نہ رہے تو Kubernetes، container support کے ساتھ پہلے سے configured CI runners، اور تقریباً ہر project کے README میں one-command quickstart فراہم کرتا ہے۔ Jails کے ساتھ FreeBSD ports tree موجود ہے، جو وسیع اور احتیاط سے maintain کیا جاتا ہے، لیکن ready-to-run application bundles کا مجموعہ کہیں چھوٹا ہے۔ جب کوئی project صرف container image publish کرتا ہے اور کچھ نہیں، تو FreeBSD کا طریقہ یہ ہے کہ اس کی documentation پڑھیں اور تمام اجزا خود assemble کریں۔

اس trade-off کے دوسرے رخ پر Jails اپنی جگہ بناتے ہیں۔ انہیں اس وقت منتخب کریں جب آپ پہلے ہی ZFS چلا رہے ہوں اور پوری service کے snapshot اور rollback کو اہمیت دیتے ہوں، جب آپ کی services FreeBSD native ہوں، جب آپ ہر tenant کے لیے صرف ایک process کے بجائے مکمل userland چاہتے ہوں، یا جب آپ kernel، packet filter، filesystem اور documentation کو ایک ہی system کے طور پر ساتھ maintain کرنا چاہتے ہوں۔ لوگ FreeBSD کو coherent کہتے وقت اسی آخری نکتے کی طرف اشارہ کرتے ہیں۔ اس کی مزید وضاحت server platforms کے طور پر Linux اور FreeBSD کے وسیع تر تقابل اور server استعمال کے لیے FreeBSD 15 میں ہونے والی تبدیلیاں میں ملتی ہے۔

آخر میں ایک فیصلہ کن بات۔ اگر آپ کی team پہلے ہی Docker جانتی ہے تو منتقل ہونے کی لاگت حقیقی ہے، اور اس کے فوائد کی کوئی مخصوص وجہ ہونی چاہیے۔ isolation quality کی وجہ سے تبدیل نہ کریں؛ دونوں models اس قدر قریب ہیں کہ آپ کی configuration زیادہ اہم ہے۔ تبدیل اس لیے کریں کہ آپ پوری services کے لیے ZFS-backed rollback چاہتے ہیں، یا اس لیے کہ آپ پہلے ہی FreeBSD استعمال کر رہے ہیں۔

FAQ

کیا میں FreeBSD پر Docker images چلا سکتا ہوں؟

Linux images نہیں، اور نہ ہی یہ supported طریقہ ہے۔ FreeBSD میں OCI container support موجود ہے: sudo pkg install -y podman-suite، Podman install کرتا ہے جو ocijail کے ذریعے containers چلاتا ہے۔ یہ ایسا runtime ہے جو اندرونی طور پر حقیقی jails بناتا ہے۔ Container monitor کے لیے fdescfs کو /dev/fd پر mount کرنا ضروری ہے، جبکہ container NAT (network address translation) کے لیے pf درکار ہے۔ FreeBSD-native OCI images بہترین طریقے سے کام کرتی ہیں۔ Linux images کے لیے اضافی طور پر Linux compatibility layer درکار ہے، اور August 2026 تک FreeBSD Podman port کو اب بھی experimental قرار دیا گیا ہے۔ اگر آپ کی deployment Linux images کے stack پر مشتمل ہے تو اسے Linux پر چلائیں۔

کیا FreeBSD jails، Docker containers سے زیادہ محفوظ ہیں؟

دونوں ایک ہی host kernel شیئر کرتے ہیں، اس لیے kernel bug دونوں کے لیے خطرہ ہے، اور حقیقی طور پر غیر معتبر code کے لیے آپ ان میں سے کسی کو بھی مناسب boundary نہیں سمجھیں گے۔ فرق ابتدائی configuration میں ہے۔ jail میں operations کا ایک وسیع مجموعہ ابتدا ہی سے منع ہوتا ہے، اور آپ انہیں ایک ایک parameter کے ذریعے دوبارہ فعال کرتے ہیں۔ Docker container namespaces کے ایک مجموعے میں root کے طور پر شروع ہوتا ہے، جہاں کچھ capabilities پہلے ہی drop کی جا چکی ہوتی ہیں، جبکہ مزید hardening اختیاری ہوتی ہے۔ عملی طور پر model سے زیادہ configuration فیصلہ کن ہوتی ہے: allow.mount اور allow.raw_sockets کے ساتھ چلنے والا jail، احتیاط سے configured container سے زیادہ محفوظ نہیں ہوتا۔

میں jail کا backup کیسے بناؤں؟

Dataset کا snapshot بنائیں اور اسے منتقل کریں۔ sudo zfs snapshot zroot/jails/containers/web@backup، پھر اس snapshot کو کسی دوسرے pool میں یا ایسی file میں zfs send کریں جسے آپ host سے باہر copy کر سکیں۔ چونکہ jail اپنا پورا userland ایک ہی dataset میں رکھتا ہے، اس لیے snapshot installed packages اور data کو ایک ہی consistent point پر محفوظ کرتا ہے، نیز ہر وہ config file بھی شامل ہوتی ہے جسے آپ نے دستی طور پر edit کیا ہو۔ یہ Docker کے معمول کے بالکل برعکس ہے، جہاں آپ named volumes اور Compose file کا backup بناتے ہیں اور باقی environment کو image سے دوبارہ بناتے ہیں۔

کیا مجھے BastilleBSD درکار ہے، یا base system کافی ہے؟

Base system کافی ہے، اور ابتدا کے لیے یہی بہتر مقام ہے۔ jail.conf، jls، jexec اور service jail start پورے model کا احاطہ کرتے ہیں۔ جب آپ انہیں سمجھ لیتے ہیں تو host کے tooling کو پہلے سیکھے بغیر کسی بھی FreeBSD host کو پڑھ سکتے ہیں۔ Bastille اس کے اوپر ایک convenience layer ہے: یہ releases کو bootstrap کرتا ہے، thin jails بناتا ہے، templates لاگو کرتا ہے، اور pf redirect rules آپ کی طرف سے لکھتا ہے۔ پہلے base commands سیکھیں، پھر جب jails کی تعداد کے باعث دستی typing دشوار ہو جائے تو Bastille شامل کریں۔