എല്ലാം ഒരു ഫയലാണ്: യൂനിക്സ് മുതൽ AI ഏജന്റ് രൂപകൽപ്പനയുടെ തത്വശാസ്ത്രം വരെ
എല്ലാം ഒരു ഫയലാണ്: യൂനിക്സ് മുതൽ AI ഏജന്റ് രൂപകൽപ്പനയുടെ തത്വശാസ്ത്രം വരെ
ഒറിജിനൽ: Ethan 业成


അരനൂറ്റാണ്ട് പിന്നിടുമ്പോളുള്ള പ്രതിധ്വനി
1970-കളുടെ തുടക്കത്തിൽ ബെൽ ലാബ്സിൽ (Bell Labs), യൂനിക്സിന്റെ പിതാവായ കെൻ തോംസണും (Ken Thompson) ഡെന്നിസ് റിച്ചിയും (Dennis Ritchie) ആദ്യമായി ഒരു ധീരമായ രൂപകൽപ്പന തത്വം മുന്നോട്ട് വെച്ചു: എല്ലാം ഒരു ഫയലാണ് - Everything is a file.
അമ്പത് വർഷങ്ങൾക്കിപ്പുറം, AI ഏജന്റ് ചട്ടക്കൂടുകൾ പൊട്ടിപ്പുറപ്പെടുന്നു. Manus, Claude Code, OpenClaw... ഇവ വ്യത്യസ്ത ടീമുകളിൽ നിന്നും വ്യത്യസ്ത സാങ്കേതിക സ്റ്റാക്കുകളിൽ നിന്നും വ്യത്യസ്ത വാണിജ്യ ലക്ഷ്യങ്ങളിൽ നിന്നും വരുന്നവയാണ്, എന്നിരുന്നാലും ഒരേയൊരു തിരഞ്ഞെടുപ്പ് അവർ നടത്തുന്നു: ഫയൽ സിസ്റ്റത്തെ ഏജന്റിന്റെ ബോധത്തിന്റെ അസ്ഥികൂടമായി ഉപയോഗിക്കുന്നു.
Manus ഏജന്റിന് ഒരു വെർച്വൽ മെഷീൻ നൽകുന്നു, ടാസ്ക്കുകൾ ഫയലുകളായി output ചെയ്യുന്നു. Claude Code ഉപയോക്താക്കളുടെ ലോക്കൽ ഫയൽ സിസ്റ്റത്തിൽ നേരിട്ട് വായിക്കുകയും എഴുതുകയും ചെയ്യുന്നു, കൂടാതെ CLAUDE.md എന്ന ഫയലിൽ എല്ലാ നിർദ്ദേശങ്ങളും സാഹചര്യങ്ങളും ഉൾക്കൊള്ളുന്നു. OpenClaw പോലുള്ള ഓപ്പൺ സോഴ്സ് ചട്ടക്കൂടുകൾ ടാസ്ക് വിഭജനവും ഇന്റർമീഡിയറ്റ് സ്റ്റേറ്റുകളും ഒരു ഡയറക്ടറി ഘടനയിൽ ക്രമീകരിക്കുന്നു.
പകുതി നൂറ്റാണ്ടിന്റെ ഇടവേളയ്ക്ക് ശേഷം, എഞ്ചിനീയർമാർ തികച്ചും വ്യത്യസ്തമായ സാങ്കേതിക പ്രശ്നങ്ങളെ അഭിമുഖീകരിക്കുമ്പോൾ, ഒരേയൊരു പരിഹാരത്തിലേക്ക് എത്തുന്നു - ഇത് യാദൃശ്ചികമല്ല, ഇതൊരു രൂപകൽപ്പന തത്വശാസ്ത്രത്തിന്റെ പ്രതിധ്വനിയാണ്.
യൂനിക്സിന്റെ ആ തീരുമാനം
ഇതിന്റെ പ്രാധാന്യം മനസ്സിലാക്കാൻ, യൂനിക്സ് എന്താണ് ചെയ്തതെന്ന് ആദ്യം അറിയണം.
യൂനിക്സ് ഫയൽ സിസ്റ്റത്തിന്റെ രൂപകൽപ്പന കമ്പ്യൂട്ടർ ശാസ്ത്രത്തിലെ ഏറ്റവും മികച്ച രൂപകൽപ്പനകളിൽ ഒന്നായി കണക്കാക്കപ്പെടുന്നു. ഇത് വളരെ സങ്കീർണ്ണമായ ഒരു പ്രശ്നം പരിഹരിച്ചു: ആയിരക്കണക്കിന് വ്യത്യസ്ത ഹാർഡ്വെയർ ഉറവിടങ്ങളെയും ഡാറ്റാ ഉറവിടങ്ങളെയും എങ്ങനെ ഏകീകൃതവും ലളിതവുമായ ഒരു ഇന്റർഫേസ് ഉപയോഗിച്ച് കൈകാര്യം ചെയ്യാമെന്ന്.
1970-കളിൽ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം പ്രവർത്തിച്ചിരുന്നത് ഇങ്ങനെയാണ്: നിങ്ങൾക്ക് ഡിസ്ക് വായിക്കണമെങ്കിൽ, ഡിസ്ക് ഇന്റർഫേസ് ഉപയോഗിക്കുക; നിങ്ങൾക്ക് മാഗ്നറ്റിക് ടേപ്പ് വായിക്കണമെങ്കിൽ, ടേപ്പ് ഇന്റർഫേസ് ഉപയോഗിക്കുക; നിങ്ങൾക്ക് ടെർമിനൽ ആക്സസ് ചെയ്യണമെങ്കിൽ, ടെർമിനൽ ഇന്റർഫേസ് ഉപയോഗിക്കുക. ഓരോ ഉപകരണത്തിനും അതിന്റേതായ API ഉണ്ട്, ഓരോ API-ക്കും അതിന്റേതായ അർത്ഥമുണ്ട്. നിങ്ങൾക്ക് N തരം ഉപകരണങ്ങളും M തരം പ്രവർത്തനങ്ങളും ഉണ്ടെങ്കിൽ, സിസ്റ്റത്തിന്റെ സങ്കീർണ്ണത N × M ആയിരിക്കും.
Thompson-ഉം Ritchie-യും ലളിതവും വിഡ്ഢിത്തപരവുമായ ഒരു കാര്യം ചെയ്തു:
എല്ലാത്തിനെയും ഫയലുകളാക്കി മാറ്റുക. എല്ലാം കൈകാര്യം ചെയ്യാൻ open, read, write, close എന്നീ നാല് ക്രിയകൾ ഉപയോഗിക്കുക.
ഇതിൻ്റെ പ്രധാന ആശയം ഇതാണ്: ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിലെ എല്ലാ ഉറവിടങ്ങളും - ഡോക്യുമെന്റുകൾ, ഡയറക്ടറികൾ, ഹാർഡ് ഡ്രൈവുകൾ, മോഡമുകൾ, കീബോർഡുകൾ, പ്രിന്ററുകൾ, നെറ്റ്വർക്ക് കണക്ഷനുകൾ, പ്രോസസ് വിവരങ്ങൾ എന്നിവയെല്ലാം - ഒരു ഫയൽ സ്ട്രീമായി (Stream of Bytes) ചുരുക്കാവുന്നതാണ്.
അതിനർത്ഥം, നിങ്ങൾക്ക് ഒരു കൂട്ടം API-കൾ മാത്രം പഠിച്ചാൽ മതി - open(), read(), write(), close() - കമ്പ്യൂട്ടറിലെ എല്ലാ ഉറവിടങ്ങളും കൈകാര്യം ചെയ്യാൻ സാധിക്കും.
തുടർന്ന്, സങ്കീർണ്ണത N × M എന്നതിൽ നിന്ന് 4 × 1 ആയി ചുരുങ്ങി. നാല് ക്രിയകൾ, ഒരു അബ്സ്ട്രാക്ഷൻ ലെയർ.
ഇതിലെ പ്രതിഭ 'ഫയൽ' എന്ന വാക്കിലല്ല, മറിച്ച് കൂടുതൽ ആഴത്തിലുള്ള ഒരു ഉൾക്കാഴ്ചയിലാണ്:
ഫയൽ ഡിസ്ക്രിപ്റ്ററിന് പിന്നിൽ എന്താണെന്ന് നിങ്ങൾ അറിയേണ്ടതില്ല. ഇന്റർഫേസ് എന്നാൽ കരാർ.
ഒരു fd (ഫയൽ ഡിസ്ക്രിപ്റ്റർ) അതാര്യമായ ഒരു ഹാൻഡിലാണ്. നിങ്ങൾ അതിലേക്ക് read() ചെയ്യുമ്പോൾ, ബൈറ്റ് സ്ട്രീം പുറത്തുവരുന്നു. ഈ ബൈറ്റുകൾ ഹാർഡ് ഡ്രൈവ് സെക്ടറിൽ നിന്നോ, നെറ്റ്വർക്ക് കാർഡ് ബഫറിൽ നിന്നോ, അല്ലെങ്കിൽ മറ്റൊരു പ്രോസസ്സിന്റെ സ്റ്റാൻഡേർഡ് ഔട്ട്പുട്ടിൽ നിന്നോ വരുന്നതാണോ എന്നത് നിങ്ങൾ ശ്രദ്ധിക്കുന്നില്ല, നിങ്ങൾ ശ്രദ്ധിക്കേണ്ടതുമില്ല.
ഇതാണ് ഏകീകൃത ഇന്റർഫേസിന്റെ ശക്തി: ഇത് അജ്ഞതയെ ഒരു നേട്ടമാക്കി മാറ്റുന്നു.

ഏജന്റ് അഭിമുഖീകരിക്കുന്ന അതേ ചോദ്യം
ഇപ്പോൾ AI ഏജന്റിന്റെ അവസ്ഥയിലേക്ക് തിരികെ നോക്കുക.
ഒരു സങ്കീർണ്ണമായ ടാസ്ക് പൂർത്തിയാക്കാൻ, ഒരു ഏജന്റ് 1970-കളിലെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന് സമാനമായ ഒരു പ്രതിസന്ധിയാണ് നേരിടുന്നത്:
- സ്ഥിരമായ മെമ്മറി**: LLM-ൻ്റെ കോൺടെക്സ്റ്റ് വിൻഡോ താൽക്കാലികമാണ്, ചിന്താ ശൃംഖല സെഷനോടൊപ്പം ഇല്ലാതാകുന്നു. ഒരു പ്രോസസ്സ് എക്സിറ്റ് ചെയ്ത ശേഷം മെമ്മറി റീസൈക്കിൾ ചെയ്യുന്നത് പോലെ, ഇടയിലുള്ള അവസ്ഥകൾ നിലനിർത്താൻ ഒരിടം വേണം. അല്ലെങ്കിൽ ഓരോ സംഭാഷണവും ആദ്യം മുതലേ തുടങ്ങേണ്ടിവരും.
- ക്രമാനുഗതമായ കോൺടെക്സ്റ്റ്**: സങ്കീർണ്ണമായ ടാസ്ക്കുകൾ ഒറ്റയടിക്ക് പൂർത്തിയാക്കാൻ കഴിയില്ല. Unix പ്രോസസ്സുകൾ ഫയലുകൾ എഴുതിയും വായിച്ചും പല തവണ എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ സ്റ്റേറ്റ് കൈമാറുന്നത് പോലെ, ഏജൻ്റിന് പല റൗണ്ടുകളിലുള്ള যুক্তവാദങ്ങളിൽ படிப்படியாக കോൺടെക്സ്റ്റ് കൂട്ടിച്ചേർക്കേണ്ടി വരും. ഫയൽ സിസ്റ്റം സ്വാഭാവികമായി "കുറച്ച് എഴുതുക, കുറച്ച് വായിക്കുക, വീണ്ടും കുറച്ച് എഴുതുക" എന്ന ക്രമാനുഗതമായ പ്രവർത്തന രീതി നൽകുന്നു.
- ഉപകരണങ്ങളുടെയും കഴിവുകളുടെയും ഏകീകൃത ഷെഡ്യൂളിംഗ്**: ഏജൻ്റ് സെർച്ച്, കോഡ് എക്സിക്യൂഷൻ, ഇമേജ് ജനറേഷൻ തുടങ്ങിയ വ്യത്യസ്ത ടൂളുകൾ ഉപയോഗിക്കണം. Unix ഡിസ്ക്, നെറ്റ്വർക്ക്, പ്രിൻ്റർ തുടങ്ങിയ വ്യത്യസ്ത ഉപകരണങ്ങളെ കൈകാര്യം ചെയ്യുന്നതുപോലെ, നിങ്ങൾക്ക് ഒരു ഏകീകൃത അബ്സ്ട്രാക്ഷൻ ലെയർ ആവശ്യമാണ്. അല്ലെങ്കിൽ ഓരോ പുതിയ ടൂളിനും പുതിയ ഇന്റഗ്രേഷൻ ലോജിക് എഴുതേണ്ടിവരും.
- കമ്പ്യൂട്ടർ ഉപയോഗത്തിനുള്ള അനുമതി അതിരുകൾ**: ഒരു ഏജൻ്റിന് കമ്പ്യൂട്ടർ പ്രവർത്തിപ്പിക്കാൻ കഴിവുണ്ടെങ്കിൽ, "അതിന് എന്ത് ചെയ്യാൻ കഴിയും, എന്ത് ചെയ്യാൻ കഴിയില്ല" എന്നത് നിർണായകമാണ്. Unix-ലെ ഫയൽ പെർമിഷൻ സിസ്റ്റം (rwx) നിലവിൽ ലഭ്യമായ സാൻഡ്ബോക്സ് മോഡൽ നൽകുന്നു - ഡയറക്ടറി അതിർത്തിയും പെർമിഷൻ കരാറുമാണ്.
നാല് ആവശ്യകതകൾ. ഇത് കേട്ട് പരിചയമുണ്ടോ?
ഇത് 1970-കളിൽ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം നേരിട്ട പ്രശ്നമാണ്.
സ്ഥിരമായ മെമ്മറി - ഫയൽ സിസ്റ്റം സ്വാഭാവികമായി പരിഹരിക്കുന്നു, എഴുതുന്നത് നിലനിർത്തുന്നു. ക്രമാനുഗതമായ കോൺടെക്സ്റ്റ് - ഡയറക്ടറി ഘടന തന്നെ ക്രമേണ നിർമ്മിക്കുന്നതാണ്, mkdir, touch, append എന്നിവ ഉപയോഗിച്ച് കോൺടെക്സ്റ്റ് ഫയലിനൊപ്പം വളരുന്നു. ടൂളുകളുടെ ഏകീകൃത ഷെഡ്യൂളിംഗ് - Unix പൈപ്പ്ലൈനിൻ്റെ പ്രധാന ആശയം: ഒരു പ്രോസസ്സിൻ്റെ stdout എന്നത് മറ്റൊരു പ്രോസസ്സിൻ്റെ stdin ആണ്, ഇടയിലുള്ള മാധ്യമം ബൈറ്റ് സ്ട്രീമാണ്. ഏജൻ്റിൻ്റെ ടൂൾ ചെയിനും ഇതുപോലെയാണ്: മുൻപത്തെ സ്റ്റെപ്പിൻ്റെ ഔട്ട്പുട്ട് ഫയലാണ് അടുത്ത സ്റ്റെപ്പിൻ്റെ ഇൻപുട്ട്. അനുമതി അതിരുകൾ - ഫയൽ സിസ്റ്റത്തിൻ്റെ rwx പെർമിഷനുകളും chroot സാൻഡ്ബോക്സും ഏജൻ്റിന് ഒരു "കഴിവ് വലയം" നിർണ്ണയിക്കുന്നു.
അതുകൊണ്ട് ഒരു ഏജൻ്റ് ഫ്രെയിംവർക്കിൻ്റെ ഡിസൈനർമാർ "ഏജൻ്റിൻ്റെ പ്രവർത്തന സ്റ്റേറ്റ് എവിടെ വെക്കണം" എന്ന് ചിന്തിക്കുമ്പോൾ, ഉത്തരം ഏകദേശം ഉറപ്പാണ്: ഫയൽ സിസ്റ്റത്തിൽ വെക്കുക. കാരണം ഈ നാല് നിബന്ധനകളും ഒരുമിച്ച് പാലിക്കാൻ ഇതിലും എളുപ്പമുള്ള ഒരു പരിഹാരമില്ല.
സിസ്റ്റത്തിന് "ധാരാളം വ്യത്യസ്ത ഉറവിടങ്ങളുടെ ഇടപെടൽ കൈകാര്യം ചെയ്യേണ്ടി വരുമ്പോൾ", നിങ്ങൾക്ക് രണ്ട് വഴികളുണ്ട്:
റൂട്ട് A: ഓരോ ഉറവിടത്തിനും പ്രത്യേക ഇൻ്റർഫേസുകൾ രൂപകൽപ്പന ചെയ്യുക. N ഉറവിടങ്ങൾ × M പ്രവർത്തനങ്ങൾ = NM ഇൻ്റർഫേസുകൾ. കൃത്യവും എന്നാൽ വിപുലവുമാണ്.
റൂട്ട് B: എല്ലാ ഉറവിടങ്ങളെയും ഒരേ വസ്ത്രം ധരിപ്പിക്കാൻ കഴിയുന്നത്ര നേരിയ ഒരു അബ്സ്ട്രാക്ഷൻ കണ്ടെത്തുക. 4 പ്രവർത്തനങ്ങൾ × 1 ലെയർ അബ്സ്ട്രാക്ഷൻ. ഏകദേശവും എന്നാൽ സംയോജിപ്പിക്കാൻ കഴിയുന്നതുമാണ്.
Unix B തിരഞ്ഞെടുത്തു. അമ്പതിലധികം വർഷങ്ങൾക്ക് ശേഷം, ഏജൻ്റ് ഫ്രെയിംവർക്ക് വീണ്ടും B തിരഞ്ഞെടുക്കുന്നു.

കൂടുതൽ ആഴത്തിൽ: ഫയൽ ചിന്തയുടെ ബാഹ്യരൂപമാണ്
എന്നാൽ "സാങ്കേതിക പരിഹാരങ്ങളുടെ ഒത്തുചേരലിൽ" മാത്രം ഒതുങ്ങി നിന്നാൽ, നമ്മുക്ക് പ്രധാനപ്പെട്ട ചില കാര്യങ്ങൾ നഷ്ടമാകും.
മനുഷ്യർ സങ്കീർണ്ണമായ ടാസ്ക്കുകൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നുവെന്ന് ഓർക്കുക.
നിങ്ങൾക്ക് ഒരു വലിയ പ്രോജക്റ്റ് ലഭിച്ചാൽ, നിങ്ങൾ ആദ്യം ചെയ്യുന്നത് ജോലി ചെയ്യാൻ തുടങ്ങുകയല്ല, മറിച്ച് ഒരു ഫോൾഡർ ഉണ്ടാക്കുകയാണ്. പ്രോജക്റ്റ് റൂട്ട് ഡയറക്ടറി, സബ് ടാസ്ക് ഡയറക്ടറി, റഫറൻസ് മെറ്റീരിയൽ ഡയറക്ടറി, ഔട്ട്പുട്ട് ഡയറക്ടറി. നിങ്ങൾക്ക് കൈകാര്യം ചെയ്യാൻ കഴിയുന്ന യൂണിറ്റുകളായി ചിട്ടയില്ലാത്ത ടാസ്ക്കുകളെ ഡയറക്ടറി ഘടന ഉപയോഗിച്ച് വിഭജിക്കുന്നു. ഓരോ യൂണിറ്റിനും ഫയലിൻ്റെ പേര് നൽകുന്നു. ചിന്താ പ്രക്രിയയും ഇടയിലുള്ള ഉൽപ്പന്നങ്ങളും ഫയലിൽ രേഖപ്പെടുത്തുന്നു.
ഫയൽ സിസ്റ്റം ഒരു സ്റ്റോറേജ് സൊല്യൂഷൻ മാത്രമല്ല. ഇത് മനുഷ്യൻ്റെ ചിന്തകളെ ബാഹ്യമായി കാണിക്കാനുള്ള ഒരു പ്രധാന ഉപകരണമാണ്.
എന്തുകൊണ്ടാണ് ഏജൻ്റ് ഫ്രെയിംവർക്ക് ഫയൽ സിസ്റ്റത്തിലേക്ക് ഒത്തുചേരുന്നത് എന്ന് ഈ നിരീക്ഷണം വിശദീകരിക്കുന്നു: LLM-ൻ്റെ "ചിന്ത" ബാഹ്യമായി കാണിക്കേണ്ടതുണ്ട് - അതിൻ്റെ കോൺടെക്സ്റ്റ് വിൻഡോ പരിമിതമാണ്, ദീർഘകാല যুক্তവാദങ്ങൾ ബാഹ്യ മെമ്മറിയെ ആശ്രയിച്ചിരിക്കുന്നു. ഫയൽ സിസ്റ്റം മനുഷ്യൻ കണ്ടുപിടിച്ച ഏറ്റവും സാധാരണമായ "ബാഹ്യ മെമ്മറി" ഫോർമാറ്റാണ്.
ഈ കാഴ്ചപ്പാടിൽ നിന്ന് നോക്കിയാൽ, Claude Code-ലെ CLAUDE.md ഒരു കോൺഫിഗറേഷൻ ഫയലല്ല. ഇത് ബാഹ്യമായ ഒരു ധാരണാപരമായ ഉടമ്പടിയാണ് - മനുഷ്യൻ ഉദ്ദേശങ്ങൾ ഫയലായി എഴുതുന്നു, ഏജൻ്റ് ആ ഫയൽ വായിച്ച് ഉദ്ദേശങ്ങൾ മനസ്സിലാക്കുന്നു. ഫയൽ മനുഷ്യ മനസ്സിനും ആർട്ടിഫിഷ്യൽ ഇന്റലിജൻസിനും ഇടയിലുള്ള ഒരു ഇൻ്റർഫേസ് ലെയറായി മാറുന്നു.
ഇത് Unix പൈപ്പ്ലൈനിൻ്റെ തത്വശാസ്ത്രവുമായി അതിശയകരമായി യോജിക്കുന്നു:
Write programs to handle text streams, because that is a universal interface. (ടെക്സ്റ്റ് സ്ട്രീമുകൾ കൈകാര്യം ചെയ്യാൻ പ്രോഗ്രാമുകൾ എഴുതുക, കാരണം അതൊരു സാർവത്രിക ഇൻ്റർഫേസാണ്.)"programs" എന്നതിനെ "agents" എന്നും "text streams" എന്നതിനെ "files" എന്നും മാറ്റുക, ഈ വാക്യം 2026-ലും നിലനിൽക്കും.
ആദ്യ തത്വങ്ങളിലേക്ക് മടങ്ങുക
മഹത്തായ അമൂർത്തീകരണം കാലഹരണപ്പെടില്ല, അത് പുതിയ മേഖലകളിൽ പുതിയ ഉദാഹരണങ്ങൾ കണ്ടെത്തും.
"ഏകീകൃത ഇന്റർഫേസ് സങ്കീർണ്ണത ഇല്ലാതാക്കുന്നു" എന്നത് Unix-ൻ്റെ കണ്ടുപിടുത്തമല്ല, ഇത് സിസ്റ്റം രൂപകൽപ്പനയുടെ ശാശ്വതമായ നിയമമാണ്. Unix ആകസ്മികമായി "ഫയൽ" എന്ന പേരിൽ ഇത് നടപ്പിലാക്കി. AI Agent ആകസ്മികമായി "വർക്ക് ഡയറക്ടറി" എന്ന രൂപത്തിൽ ഇത് വീണ്ടും നടപ്പിലാക്കി.
അടുത്ത തലമുറയിലെ സിസ്റ്റങ്ങളും ഇതേ തിരഞ്ഞെടുപ്പിനെ വീണ്ടും അഭിമുഖീകരിക്കും: എല്ലാത്തിനും പ്രത്യേക ഇന്റർഫേസുകൾ രൂപകൽപ്പന ചെയ്യണോ, അതോ നേരിയതും സാർവത്രികവും സംയോജിപ്പിക്കാൻ കഴിയുന്നതുമായ ഒരു അമൂർത്തീകരണം കണ്ടെത്തണോ?
ചരിത്രത്തിന് എന്തെങ്കിലും പഠിപ്പിക്കാനുണ്ടെങ്കിൽ, ഉത്തരം /dev/null-ന് അടുത്തായി എഴുതിയിട്ടുണ്ട്:
ലളിതമായി സൂക്ഷിക്കുക. അത് കൂട്ടിച്ചേർക്കാൻ കഴിയുന്നതാക്കുക. എല്ലാം ഒരു ഫയലാണ്.





