Linux kernel इतिहास: आजही टिकलेले निर्णय कोणते?

Linux kernel इतिहासाची संक्षिप्त रूपरेषा

Linux kernel इतिहास सप्टेंबर 1991 मधील version 0.01 पासून आज servers वर boot होणाऱ्या 7.x series पर्यंत पोहोचतो. Release list हा त्यातील सर्वांत महत्त्वाचा भाग नाही. काही मोजक्या निर्णयांनी या kernel ची रचना निश्चित केली. आज दुपारी तुम्ही भाड्याने घेतलेल्या machine वरही प्रत्येक निर्णयाचा परिणाम दिसतो.

येथील dates आणि version numbers kernel.org आणि त्यावर प्रकाशित केलेल्या release history मधून घेतले आहेत. August 2026 पर्यंतची सद्यस्थिती अशी आहे: 7.0 12 April 2026 रोजी आले, 7.1 14 June 2026 रोजी आले, आणि 7.2 release candidates टप्प्यात आहे.

1992 मधील GPL ची निवड आजही महत्त्वाची का आहे

Version 0.01 हे 17 September 1991 रोजी Torvalds यांनी स्वतः लिहिलेल्या licence अंतर्गत प्रकाशित झाले. त्यानुसार source वितरित करणे आवश्यक होते. त्यात आणखी एक महत्त्वाची ओळ होती: "तुम्ही हे शुल्क घेऊन वितरित करू शकत नाही; 'handling' खर्चसुद्धा आकारता येणार नाही." 1991 मध्ये software floppy disks वर वितरित होत असे आणि floppy disks कॉपी करून पोस्ट करण्यासाठी खर्च येत असे. या अटीमुळे commercial Linux distribution अशक्य झाली.

त्यांनी ही अट बदलली. GNU General Public License (GPL) कडे झालेल्या बदलाची घोषणा January 1992 मध्ये 0.12 च्या release notes मध्ये करण्यात आली आणि तो बदल 1 February 1992 रोजी लागू झाला. March 1992 मधील Version 0.95 हे GPL अंतर्गत प्रकाशित झालेले पहिले release होते. त्यानंतर Linux वर उभारलेल्या प्रत्येक व्यवसायाचा आधार या बदलावर आहे.

Kernel फक्त GPL version 2 अंतर्गत आहे आणि तो कधीही version 3 कडे गेला नाही. Torvalds यांनी 2007 मध्ये याला नकार दिला. यामागे मुख्यतः GPLv3 मधील anti-tivoisation नियम होता. या नियमानुसार GPL code असलेले device तो code सुधारित स्वरूपात स्वीकारण्याची सुविधाही देणे आवश्यक असते. Locked hardware हा manufacturer च्या स्वतःच्या व्यवसायाचा विषय आहे, असे त्यांनी मानले. 2017 मध्ये kernel developers यांनी Kernel Enforcement Statement प्रकाशित केले. त्यात GPLv3 मधील एक बाब स्वीकारली आहे: violation बद्दल कळवल्यानंतर ते दुरुस्त करणाऱ्या व्यक्तीचा licence कायम राहतो; पहिल्याच breach वेळी तो कायमचा गमावला जात नाही.

यामुळे server वर दोन परिणाम होतात. तुम्ही boot करत असलेल्या kernel binary सोबत त्याच्या matching source चा अधिकार मिळतो. त्यामुळे तुम्हाला तपासता किंवा पुन्हा build करता येणार नाही असा Linux kernel कोणीही देऊ शकत नाही. तसेच kernel वरील copyright notice नुसार normal system calls द्वारे kernel services वापरणाऱ्या user programs वर ही licence लागू होत नाही. त्यामुळे proprietary databases आणि monitoring agents Linux साठी वितरित करता येतात आणि त्यातून कोणतेही उल्लंघन होत नाही. Permissive licence याच्या उलट दबाव निर्माण करते. Platform निवडण्यापूर्वी हा फरक समजून घेणे महत्त्वाचे आहे: server platforms म्हणून Linux आणि FreeBSD.

प्रत्यक्ष वापरात monolithic kernel का यशस्वी ठरला

29 January 1992 रोजी Andrew Tanenbaum यांनी comp.os.minix newsgroup वर "LINUX is obsolete" या शीर्षकाचा संदेश पोस्ट केला. त्यांनी दोन दावे केले. Monolithic kernel मध्ये drivers आणि filesystems एकाच privileged address space मध्ये चालतात. ही रचना 1970 च्या दशकातील होती. Microkernel मध्ये हे भाग सामान्य processes म्हणून चालतात. त्यामुळे microkernels हे भविष्यातील तंत्रज्ञान होते. तसेच Linux Intel 386 शी घट्ट जोडलेले होते. त्यामुळे ते इतर प्लॅटफॉर्मवर कधीही port करता येणार नाही, असा त्यांचा दावा होता.

Portability या दाव्याचे उत्तर porting ने दिले. March 1995 मधील Version 1.2 मध्ये Alpha, SPARC आणि MIPS साठी समर्थन जोडले गेले. June 1996 मधील Version 2.0 मध्ये 64-bit Alpha port जोडला गेला.

Design या दाव्याचे उत्तर तडजोडीने दिले. Linux microkernel बनले नाही. त्यात loadable kernel modules आले. हे object files running kernel मध्ये insert करून पुन्हा remove करता येतात. त्यामुळे driver kernel binary पासून स्वतंत्रपणे release करता येतो.

lsmod | head
modinfo virtio_net | head -5

lsmod सध्या कोणते modules loaded आहेत ते दाखवते. modinfo module कोणत्या file मधून आले आहे आणि ते कोणते parameters स्वीकारते ते दाखवते. Virtual server वर disk आणि network path चा मोठा भाग modules मध्ये असतो. त्यामुळे ज्या hardware शी kernel image पूर्वी कधीही जोडले गेलेले नाही, त्यावरही एकच kernel image boot होऊ शकते.

Microkernel design मधील खर्च न करता modules मुळे ही लवचिकता मिळाली. Driver स्वतंत्र process मध्ये isolate करण्यासाठी प्रत्येक call वेळी context switch आणि message चा खर्च करावा लागतो. 1992 मध्ये हा खर्च मोठा होता.

Linux मध्ये राहिलेला खर्च मात्र नियोजनात लक्षात घ्यावा लागतो. Module पूर्ण kernel privileges सह चालतो. त्यामुळे चुकीचा module एका process ऐवजी संपूर्ण machine down करू शकतो. Out-of-tree modules मध्ये ही समस्या विशेषतः दिसते. Mainline मध्ये नसलेला vendor driver प्रत्येक नवीन kernel साठी पुन्हा build करावा लागतो. Upgrade दरम्यान DKMS हे काम करते. हा build fail झाला, तर reboot नंतर device उपलब्ध राहत नाही.

SMP पूर्ण होण्यासाठी पंधरा वर्षे का लागली

जून 1996 मधील Linux 2.0 हा symmetric multiprocessing (SMP) ला समर्थन देणारा पहिला kernel होता. याचा अर्थ, एकाच kernel वर एकापेक्षा जास्त CPU चालू असणे. पहिल्या अंमलबजावणीत एकच lock वापरला जात असे. त्याला big kernel lock (BKL) म्हणत. त्यामुळे एका वेळी फक्त एक processor kernel code मध्ये प्रवेश करू शकत असे. म्हणून दुसरा CPU user space मध्ये computation करणाऱ्या workload साठी उपयुक्त ठरत असे. मात्र system calls असलेल्या workload साठी त्याचा फारसा उपयोग होत नसे, कारण त्या सर्व requests त्याच lock मागे रांगेत थांबत.

तो lock काढून टाकण्यासाठी पंधरा वर्षे लागली. उरलेले users fine-grained locking मध्ये रूपांतरित करण्यात आले. हे काम मोठ्या प्रमाणावर Arnd Bergmann यांनी केले. BKL 2.6.39 मध्ये delete करण्यात आला. ही आवृत्ती 18 May 2011 रोजी release झाली. Scheduler मध्येही अशीच संथ प्रगती झाली: 2.6.0 मधील O(1) scheduler, 2007 मध्ये 2.6.23 पासूनचा Completely Fair Scheduler (CFS), आणि October 2023 मध्ये 6.6 मधील CFS ची जागा घेणारा EEVDF.

या कामामुळे आज 4 vCPU plan असणे असामान्य मानले जात नाही. मात्र यामुळे एक महत्त्वाची मर्यादा स्पष्ट होते. Shared virtual server वर तुमचा kernel तुमचे threads schedule करतो आणि hypervisor तुमचा kernel schedule करतो. top चालवा आणि %st field वाचा. Steal time म्हणजे तुमचा kernel वापरण्यासाठी तयार असलेला CPU वेळ, जो host ने दुसऱ्या guest ला दिला. त्यामुळे तुमच्या kernel मध्ये केलेले कोणतेही tuning हे CPU time परत मिळवू शकत नाही.

2.6 मालिकेने kernel build करण्याची पद्धत का बदलली

2.6 पूर्वी version numbers जोड्यांमध्ये येत असत. दुसरा क्रमांक सम असेल, तर ती stable series असे (2.4); विषम क्रमांक development series दर्शवत असे (2.5). 2.4 हे 4 January 2001 रोजी आणि 2.6 हे 17 December 2003 रोजी release झाले. त्यामुळे पुढील stable series साठी वापरकर्त्यांना जवळजवळ तीन वर्षे प्रतीक्षा करावी लागली. Distributions इतकी प्रतीक्षा करू शकत नव्हत्या. त्यामुळे त्यांनी patches backport केले. "2.4" shipping करणाऱ्या दोन vendors कडील kernels मध्ये हजारो patches चे अंतर असू शकत होते.

2.6 नंतर ही विभागणी काढून टाकण्यात आली. आता mainline सुमारे दोन आठवड्यांची merge window उघडते, नवीन काम स्वीकारते, त्यानंतर release candidates चालवते आणि बदल थांबेपर्यंत प्रक्रिया सुरू ठेवते. मग ते प्रत्येक 9 ते 10 आठवड्यांनी release होते. kernel.org अजूनही हाच cadence दस्तऐवजीकरण करते. या model चा दुसरा भाग 4 March 2005 रोजी stable tree च्या पहिल्या release सह आला. तो 2.6.11 साठीचा फक्त fixes असलेला update होता. त्याची देखभाल Greg Kroah-Hartman आणि Chris Wright यांनी केली. stable tree fixes स्वीकारते आणि features नाकारते.

याचा एक परिणाम असा झाला की version number हे आश्वासन राहिले नाही. 3.0, 4.0, 5.0 आणि 7.0 ही पूर्णपणे नव्याने लिहिलेली releases नाहीत. दुसरा क्रमांक इतका मोठा झाला की त्याचा त्रास होऊ लागला, असे Torvalds यांना वाटते तेव्हा ते पहिला क्रमांक वाढवतात. म्हणूनच April 2026 मध्ये 6.19 नंतर 7.0 आले. Server साठी महत्त्वाचे हे आहे की तुमची distribution कोणती branch follow करते आणि त्या branch ला अजूनही fixes मिळतात का.

एप्रिल 2005 मध्ये BitKeeper वादातून git कसे निर्माण झाले

फेब्रुवारी 2002 पासून 2.5 मालिकेपासून kernel चा विकास Larry McVoy यांच्या BitMover कंपनीच्या मालकीच्या distributed version control system BitKeeper मध्ये केला जात होता. BitMover ने kernel developers ना काही अटींसह विनामूल्य licence दिले होते: तुम्ही प्रतिस्पर्धी version control tool वर काम करू शकत नव्हता आणि BitKeeper चे reverse engineer करू शकत नव्हता. अनेक developers ना असा free kernel तयार करणे आवडत नव्हते, ज्याचे tool त्यांना तपासता येत नव्हते.

एप्रिल 2005 मध्ये हा करार तुटला. Andrew Tridgell यांनी BitKeeper repositories शी संवाद साधणारा program दाखवल्यानंतर हे घडले. BitMover ने त्याला reverse engineering म्हटले आणि विनामूल्य licence मागे घेतले. विकासचक्राच्या मध्यात kernel कडे version control system उरले नाही.

git वर 3 April 2005 रोजी काम सुरू झाले. Torvalds यांनी 6 April रोजी त्याची घोषणा केली. 7 April रोजी git self-hosting झाले. याचा अर्थ git चा स्वतःचा इतिहास आधीपासून git मध्येच ठेवला जात होता. अनेक branches चे पहिले merge 18 April रोजी चालवण्यात आले. June 2005 मध्ये git ने 2.6.12 चे release व्यवस्थापित केले. त्यानंतर लवकरच Torvalds यांनी maintenance Junio Hamano यांच्याकडे सोपवली आणि ते kernel कडे परतले.

या समस्येतूनच design थेट निर्माण झाले: हजारो contributors आणि अशा network वर एकमेकांकडून code pull करणारे maintainers, ज्यावर कोणाचाही विश्वास नाही. प्रत्येक object ला त्याच्या content च्या hash वर आधारित नाव दिले जाते. त्यामुळे जुन्या history मधील एक byte बदलल्यास त्यानंतरच्या प्रत्येक commit चे नाव बदलते. म्हणून clone हा दावा नसून पुरावा असतो. प्रत्येक deploy pipeline, प्रत्येक configuration repository, बहुतेक teams जिथे code push करतात तो code host आणि तुम्ही स्वतः चालवू शकणारा git server हे सर्व kernel संदर्भातील licensing वादातून निर्माण झाले.

LTS मॉडेल काय आश्वासन देते आणि काय देत नाही

Mainline ही तुम्ही चालवणारी आवृत्ती नाही. Mainline release 9 ते 10 आठवड्यांनंतर superseded होते. प्रत्येक release नंतर stable tree मध्ये काही आठवडे fixes ठेवल्या जातात. Longterm branches, ज्यांना सामान्यतः LTS असे लिहिले जाते, fixes अनेक वर्षे ठेवतात आणि distributions त्यांच्यावर आधारित builds तयार करतात.

December 2009 मध्ये released झालेली 2.6.32 ही या मॉडेलची उपयुक्तता सिद्ध करणारी आवृत्ती होती. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 आणि Ubuntu 10.04 LTS यांनी ती ship केली. हा branch February 2016 पर्यंत maintained होता, म्हणजे तो उपलब्ध झाल्यानंतर 6 वर्षांहून अधिक काळ.

हे आश्वासन एकापेक्षा अधिक वेळा बदलले आहे. सुरुवातीला कालावधी 2 वर्षे होता. काही branches साठी तो 6 वर्षे करण्यात आला. 2023 मध्ये stable maintainers नी default कालावधी पुन्हा 2 वर्षांवर आणला, कारण जुन्या trees मध्ये backporting करण्यासाठी maintainer चा वेळ लागतो आणि जुन्या branches ची प्रत्यक्ष testing कमी होते. 25 February 2026 रोजी Greg Kroah-Hartman यांनी या branches वर अवलंबून असलेल्या कंपन्यांशी चर्चा केल्यानंतर पुन्हा दीर्घ projections प्रकाशित केली. सध्याचे framework 3 ते 6 वर्षांपर्यंतचा कालावधी वापरते.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

August 2026 पर्यंत kernel.org वर 6 longterm branches सूचीबद्ध आहेत. सर्वांत जुना branch, 5.10, Dec 2026 मध्ये समाप्त होईल तेव्हा त्यामध्ये 6.0 वर्षे fixes ठेवलेल्या असतील. सर्वांत नवीन branch, 6.18, Dec 2028 पर्यंत चालण्याचा अंदाज आहे. त्यामध्ये 3.1 वर्षे fixes असतील.

या तारखांना करार नव्हे, तर किमान कालावधी समजा. February 2026 मध्ये 6.6 आणि 6.12 या दोन्ही branches चे projections पुढे ढकलले गेले. मात्र कोणीही वापरत नसलेला branch त्याऐवजी काढून टाकला जाऊ शकतो. तुमचे distribution सामान्यतः हा निर्णय तुमच्यासाठी घेते: Debian 13 6.12 ship करते आणि Ubuntu 26.04 LTS 7.0 ship करते. या फरकाचा व्यावहारिक अर्थ सर्व्हरवर LTS आणि interim release यांमधील प्रश्न यात दिसतो. तुम्ही Ubuntu 24.04 ला 26.04 वर upgrade करता तेव्हा तुमच्या प्रणालीखाली प्रत्यक्षात काय बदलते, हे याच्याशी संबंधित आहे.

यातून एक गैरसमज निर्माण होऊ शकतो. Ubuntu 24.04 वर uname -r चालवल्यास साधारणपणे 6.8.0-51-generic असे output मिळते. हा upstream base आणि distribution चे स्वतःचे backports यांचा संयोग असतो. त्यामुळे हा number branch कुठून सुरू झाला हे सांगतो; त्यामध्ये कोणते fixes आहेत हे सांगत नाही. याच कारणामुळे version string वरून kernel चे मूल्यांकन करणारे scanners distribution kernels विरुद्ध false alarms निर्माण करतात.

कर्नल सध्या कोणत्या मुद्द्यांवर वाद घालत आहे

सध्या दोन वाद सुरू आहेत. दोन्ही वाद काम कोण करणार याबद्दल आहेत.

Rust हे 6.1 मध्ये December 2022 मध्ये infrastructure म्हणून समाविष्ट झाले. 7.0 मध्ये त्यावरील experimental लेबल काढण्यात आले. त्यामुळे कर्नलच्या मूलभूत भाषा C, assembly आणि Rust आहेत. आता build साठी nightly compiler आवश्यक नाही. हा वाद maintenance बद्दल आहे. C maintainer ने interface बदलल्यास, त्याने न वाचलेल्या Rust bindings मध्ये त्रुटी येऊ शकतात. त्या bindings दुरुस्त करण्याची जबाबदारी कोणाची, यावर हा वाद आहे.

दुसरा वाद AI contribution बद्दल आहे. Machine-assisted patches ची संख्या वाढल्यानंतर Sasha Levin यांनी July 2025 मध्ये एक policy प्रस्तावित केली. हे document 23 December 2025 रोजी commit करण्यात आले. आता ते कर्नलच्या process documentation मध्ये docs.kernel.org/process/coding-assistants.html येथे आहे. AI agent ने Signed-off-by tag जोडू नये, कारण त्या ओळीमधून Developer Certificate of Origin (DCO) प्रमाणित होते आणि ते केवळ व्यक्ती प्रमाणित करू शकते. Assistance घोषित करण्यासाठी Assisted-by: tag वापरला जातो. Review दरम्यान तो Co-developed-by: वरून बदलण्यात आला, कारण tool हा author नसतो. Generated code GPL-2.0-only शी compatible असणे आवश्यक आहे. Patch पाठवणारा मानव त्याचा review करतो आणि त्याची जबाबदारी स्वीकारतो.

या policy मागील मुख्य कारण review time आहे. Patch तयार करण्यासाठी काही सेकंद लागतात. मात्र त्याचा review करण्यासाठी maintainer चा पूर्ण दुपारचा वेळ लागू शकतो. Tag मुळे हा असमतोल दूर होत नाही. मात्र provenance जतन होते. प्रत्येक बदलासाठी कोणाने स्वाक्षरी केली, याची नोंद history मध्ये कायम राहते. हीच बाब DCO ने 2004 मध्ये संरक्षित करण्यासाठी सुरुवातीपासून उद्दिष्ट ठेवले होते.

तुम्ही भाड्याने घेतलेल्या सर्व्हरसाठी या इतिहासाचा अर्थ

• तुम्ही तुमच्या provider ने सुरू केलेला kernel वाचू आणि पुन्हा build करू शकता, तसेच त्यावर proprietary software चालवू शकता, यामागे licence हे कारण आहे.
• monolithic रचनेमुळे एका driver मधील bug मुळे संपूर्ण मशीन reboot होते. तसेच प्रत्येक kernel upgrade नंतर out-of-tree module पुन्हा build करावा लागतो.
• release model मुळे version number मधून फारच कमी माहिती मिळते. त्याउलट branch आणि तिची end-of-life date जवळजवळ संपूर्ण चित्र स्पष्ट करतात.
• virtualisation चा प्रकार तुम्ही प्रत्यक्षात काय करू शकता हे ठरवतो. KVM वर तुम्ही स्वतःचा kernel boot करून modules load करू शकता. Host kernel share करणाऱ्या container virtualisation मध्ये uname -r host ची version दाखवते, modprobe अयशस्वी होते आणि काही sysctl फक्त read-only असतात.

FAQ

Linux kernel अजूनही GPLv2 अंतर्गतच का आहे, GPLv3 अंतर्गत का नाही?

Torvalds यांनी 2007 मध्ये GPLv3 नाकारले. यामागे मुख्य कारण त्यातील anti-tivoisation अट होती. या अटीनुसार GPL code वापरून वितरित केलेल्या device ने त्या code ची सुधारित आवृत्ती स्वीकारणेही शक्य केले पाहिजे. Locked hardware हा उत्पादकाच्या व्यवसायाचा भाग आहे, असे त्यांचे मत आहे. प्रत्यक्षात relicensing करणेही जवळपास अशक्य आहे. Kernel वरील copyright हजारो contributors कडे आहे आणि त्यासाठी आधार घेता येईल असा assignment agreement उपलब्ध नाही. Kernel GPL-2.0-only अंतर्गत आहे. त्यामुळे केवळ GPLv3 अंतर्गत उपलब्ध असलेला code merge करता येत नाही.

Linux kernel monolithic kernel आहे की microkernel?

तो loadable modules असलेला monolithic kernel आहे. Drivers आणि filesystems kernel च्या address space मध्ये चालतात. सध्या load केलेले drivers आणि filesystems lsmod दाखवते. यामुळे एका बाजूला वेग मिळतो, तर दुसऱ्या बाजूला परिणामक्षेत्र मोठे राहते. Faulty module मुळे संपूर्ण machine panic होऊ शकते. Microkernel मध्ये त्याऐवजी एक process बंद पडला असता. 1992 पासून user space मधील FUSE filesystems आणि kernel चालवण्यापूर्वी तपासतो असे eBPF programs यांमुळे हे चित्र काही प्रमाणात बदलले आहे.

mainline, stable आणि longterm kernels मध्ये काय फरक आहे?

Mainline म्हणजे Torvalds यांचे tree. ते प्रत्येक 9 ते 10 आठवड्यांनी release केले जाते आणि नवीन features प्रथम तिथे येतात. Stable मध्ये सर्वात अलीकडील mainline release घेतला जातो आणि काही आठवडे bug fixes दिले जातात. Longterm branches ना अनेक वर्षे fixes मिळत राहतात. Distributions त्यांच्यावर आधारित kernels तयार करतात. kernel.org वर सध्याच्या longterm branches आणि प्रत्येक branch ची अपेक्षित end-of-life date दिलेली असते.

Linux kernel AI ने लिहिलेला code स्वीकारतो का?

होय. December 2025 मध्ये स्वीकारलेल्या policy अंतर्गत हे शक्य आहे. Tool चे नाव Assisted-by: tag मध्ये देणे आवश्यक आहे. AI agent ने Signed-off-by line जोडू नये. Generated code GPL-2.0-only शी compatible असणे आवश्यक आहे. Human submitter sign off करतो. याचा अर्थ त्याने patch चे review केले आहे आणि Developer Certificate of Origin अंतर्गत त्याची जबाबदारी स्वीकारली आहे.

Server वर कोणती kernel version चालवावी?

जवळजवळ प्रत्येक बाबतीत तुमची distribution जी maintain करते तीच version वापरा. Distribution kernel म्हणजे longterm branch, backported fixes आणि vendor चे testing यांचे संयोजन आहे. तुमच्या provider च्या images आणि support arrangements याच kernel version वर आधारित असतात. विशिष्ट driver किंवा feature आवश्यक असल्यास नवीन mainline kernel तयार करा. मात्र त्या branch ची end-of-life date आधी तपासा, कारण त्यावर अवलंबून राहण्याचा निर्णय घेतल्यानंतर बदल करणे कठीण होऊ शकते.