ലിനക്സും ഗ്നു സംരംഭവും

പല കമ്പ്യൂട്ടര്‍ ഉപയോക്താക്കളും ഗ്നു സിസ്റ്റത്തിന്റെ മാറ്റം വരുത്തിയ പതിപ്പാണെന്നറിയാതെയാണു് നിത്യേന ഇതുപയോഗിയ്ക്കുന്നതു്. ചില പ്രത്യേക സാഹചര്യങ്ങളുടെ ഫലമായി ഇന്നു് പരക്കെ ഉപയോഗിയ്ക്കുന്ന ഗ്നുവിന്റെ പതിപ്പു് കൂടുതല്‍ സമയവും “ലിനക്സ്”എന്നാണറിയപ്പെടുന്നതു്, എന്നു് മാത്രമല്ല പല ഉപയോക്താക്കളും ഗ്നു സംരംഭവുമായി അതിനു് എത്ര മാത്രം ബന്ധമുണ്ടെന്നതിനെപ്പറ്റി ബോധവാന്‍മാരുമല്ല..

ശരിയ്ക്കും അങ്ങനെ ഒരു ലിനക്സ് ഉണ്ടു് എന്നു് മാത്രമല്ല ആളുകള്‍ അതു് ഉപയോഗിയ്ക്കുന്നുമുണ്ടു്, പക്ഷേ അതു് പ്രവര്‍ത്തക സംവിധാനമല്ല. ലിനക്സൊരു കെര്‍ണലാണു്: നിങ്ങള്‍ പ്രവര്‍ത്തിപ്പിയ്ക്കുന്ന മറ്റു് പ്രോഗ്രാമുകള്‍ക്കു് സിസ്റ്റത്തിന്റെ വിഭവങ്ങള്‍ വിട്ടുകൊടുക്കുന്ന പ്രോഗ്രാമാണതു്. ഒരു പ്രവര്‍ത്തക സംവിധാനത്തിന്റെ ഒഴിച്ചുകൂടാനാവാത്ത ഭാഗമാണു് കെര്‍ണല്‍, പക്ഷേ അതു് മാത്രം കൊണ്ടു് വലിയ പ്രയോജനമൊന്നുമില്ല; മുഴുവന്‍ പ്രവര്‍ത്തക സംവിധാനത്തിനൊപ്പമേ അതിനു് പ്രവര്‍ത്തിയ്ക്കാനാകൂ. ലിനക്സ് സാധാരണയായി ഗ്നു എന്ന പ്രവര്‍ത്തക സംവിധാനവുമായി ചേര്‍ന്നാണുപയോഗിയ്ക്കുന്നതു്: ലിനക്സ് കെര്‍ണലായി പ്രവര്‍ത്തിയ്ക്കുന്ന മുഴുവന്‍ സിസ്റ്റം അടിസ്ഥാനപരമായി ഗ്നുവാണു്.

പല ഉപയോക്താക്കളും ലിനക്സെന്ന കെര്‍ണലും “ലിനക്സ്”എന്നു് തന്നെ അവര്‍ വിളിയ്ക്കുന്ന മുഴുവന്‍ സിസ്റ്റവും തമ്മിലുള്ള വ്യത്യാസത്തെപ്പറ്റി ബോധവാന്‍മാരല്ല. കാര്യങ്ങള്‍ മനസ്സിലാക്കാന്‍ ഈ പേരിന്റെ അവ്യക്തമായ ഉപയോഗം സഹായിയ്ക്കുന്നില്ല. ഇത്തിരി സഹായത്തോടെ 1991 ല്‍ ലിനസ് ടോര്‍വാള്‍ഡ്സാണു് മുഴുവന്‍ പ്രവര്‍ത്തക സംവിധാനവും വികസിപ്പിച്ചെടുത്തതെന്നാണു് ഈ ഉപയോക്താക്കള്‍ വിചാരിയ്ക്കുന്നതു് .

ലിനക്സൊരു കെര്‍ണലാണെന്നു് പ്രോഗ്രാമര്‍മാര്‍ക്കു് പൊതുവെ അറിയാം. പക്ഷേ പൊതുവേ മുഴുവന്‍ സിസ്റ്റത്തേയും “ലിനക്സ്” എന്നു് തന്നെ വിളിയ്ക്കുന്നതു് കേട്ടിട്ടുള്ളതു് കൊണ്ടു് പലപ്പോഴും അവര്‍ക്കു് മുഴുവന്‍ സിസ്റ്റത്തേയും കെര്‍ണലിന്റെ പേരില്‍ വിളിയ്ക്കുന്ന ചരിത്രമാണു് മനസ്സില്‍ വരുന്നതു്. ഉദാഹരണത്തിനു് ലിനക്സ് ടോര്‍വാള്‍ഡ്സ് ലിനക്സ് എന്ന കെര്‍ണല്‍ എഴുതി തീര്‍ക്കുകയും അതിന്റെ ഉപയോക്താക്കള്‍ അതിനൊപ്പമുപയോഗിയ്ക്കാന്‍ മറ്റു് സ്വതന്ത്ര സോഫ്റ്റുവെയറുകള്‍ക്കായി ചുറ്റും നോക്കുകയും (ഒരു പ്രത്യേക കാരണമൊന്നുമില്ലാതെ തന്നെ) യുണിക്സ് പോലുള്ളൊരു സിസ്റ്റം ഉണ്ടാക്കാന്‍ ആവശ്യമായ ഒരു വിധം എല്ലാം തന്നെ നേരത്തെ തന്നെ ലഭ്യമായിരുന്നുവെന്നുമാണു് പലരും വിശ്വസിയ്ക്കുന്നതു്.

അവര്‍ കണ്ടെത്തിയതു് യാദൃശ്ചികമായിരുന്നില്ല—അതു് തീര്‍ത്തും-മുഴുവനായിട്ടില്ലാത്ത ഗ്നു സിസ്റ്റമായിരുന്നു. ലഭ്യമായ സ്വതന്ത്ര സോഫ്റ്റുവെയറുകളെല്ലാം കൂടിച്ചേര്‍ന്നു് ഒരു പൂര്‍ണ്ണമായ സിസ്റ്റമായതിനു് കാരണം 1984 മുതല്‍ അങ്ങനെ ഒരെണ്ണം ഉണ്ടാക്കാന്‍ ഗ്നു സംരംഭം പ്രയത്നിയ്ക്കുകയായിരുന്നു എന്നതാണു്. ഗ്നു എന്നു് പേരായ യുണിക്സ് പോലുള്ള സ്വതന്ത്ര സിസ്റ്റം വികസിപ്പിയ്ക്കുന്നതിനുള്ള ലക്ഷ്യം ഗ്നു മാനിഫെസ്റ്റോയില്‍ വ്യക്തമാക്കിയിരുന്നു. ഗ്നു പ്രൊജക്റ്റിന്റെ ആദ്യ പ്രഖ്യാപനവും ഗ്നു സിസ്റ്റത്തിനുള്ള ആദ്യകാല ഉദ്ദേശ്യ ലക്ഷ്യങ്ങള്‍ വിവരിച്ചിട്ടുണ്ടായിരുന്നു. ലിനക്സ് തുടങ്ങിയപ്പോഴേയ്ക്കും ഗ്നു ഏതാണ്ടു് പൂര്‍ണ്ണമായിരുന്നു.

കൂടുതല്‍ സ്വതന്ത്ര സോഫ്റ്റുവെയര്‍ സംരംഭങ്ങള്‍ക്കും ഒരു പ്രത്യേക ജോലി ചെയ്യുന്നതിനുള്ള ഒരു പ്രത്യേക സോഫ്റ്റുവെയര്‍ വികസിപ്പിയ്ക്കാനുള്ള ലക്ഷ്യമാണുള്ളതു്. ഉദാഹരണത്തിനു് ലിനസ് ടോര്‍വാള്‍ഡ്സ് യുണിക്സ് പോലുള്ളൊരു കെര്‍ണല്‍ (ലിനക്സ്) എഴുതാനാണിറങ്ങിയതു്; ഡൊണാള്‍ഡ് നുത്തിറങ്ങിയതു് ഒരു ടെക്സ്റ്റ് ഫോര്‍മാറ്റര്‍ (ടെക്) എഴുതാനാണു്; ബോബ് ഷീഫ്ലര്‍ ജാലകസിസ്റ്റം (എക്സ് ജാലക സിസ്റ്റം) വികസിപ്പിയ്ക്കുന്നതിനും. സംരംഭത്തില്‍ നിന്നും പുറത്തു് വന്ന പ്രത്യേക പ്രോഗ്രാമുകളെ വച്ചു് ഇത്തരം സംരംഭങ്ങളെ അളക്കുന്നതു് സാധാരണമാണു്.

ഇങ്ങനെയാണു് ഗ്നു സംരംഭത്തിന്റെ സംഭാവന അളക്കുന്നതെങ്കില്‍ നിങ്ങള്‍ക്കെന്താണു് മനസ്സിലാക്കാന്‍ കഴിയുക? ഒരു സിഡി-റോമുകളുടെ വിതരണക്കാരന്‍ കണ്ടുപിടിച്ചതു് അവരുടെ “ലിനക്സ് വിതരണത്തില്‍”, ഏറ്റവും വലിയ ഘടകം മുഴുവന്‍ സോഴ്സ് കോഡിന്റെ ഏതാണു് 28% വരുന്ന ഗ്നു സോഫ്റ്റുവെയറായിരുന്നു എന്നാണു്, ഇതില്‍ ഒഴിച്ചു് കൂടാനാവാത്തതും ഞാനില്ലാതെ സിസ്റ്റം തന്നെയില്ല എന്ന അവസ്ഥയുമുള്ള സുപ്രധാന ഘടകങ്ങളുമുണ്ടു്. ലിനക്സ് മാത്രമായി ഏതാണ്ടു് 3% ആയിരുന്നു. സിസ്റ്റത്തിലെ പ്രോഗ്രാമുകളാരാണെഴുതിയതു് എന്നു് നോക്കിയിട്ടാണു് നിങ്ങള്‍ പേരു് നിശ്ചയിയ്ക്കുന്നതെങ്കില്‍ ഏറ്റവും യോജിച്ച ഒറ്റ ചോയിസ് “ഗ്നു” എന്നായിരിയ്ക്കും.

പക്ഷേ അതു് ഈ ചോദ്യം പരിഗണിയ്ക്കാനുള്ള നല്ലൊരു വഴിയല്ല. ഗ്നു സംരംഭം പ്രത്യേക സോഫ്റ്റ്‌വെയര്‍ പാക്കേജുകള്‍ വികസിപ്പിയ്ക്കാനുള്ള സംരംഭമായിരുന്നില്ല, ഇപ്പോഴുമല്ല. ഞങ്ങളൊരു സി കമ്പൈലര്‍ വികസിപ്പിച്ചെങ്കിലും ഇതു് അതിനായുള്ളൊരു സംരംഭമായിരുന്നില്ല. ഞങ്ങളൊരു ടെക്സ്റ്റ് എഴുത്തിടം വികസിപ്പിച്ചെങ്കിലും ഇതു് അതിനായുള്ളൊരു സംരംഭമായിരുന്നില്ല. ഗ്നു സംരംഭത്തിന്റെ ലക്ഷ്യം ഗ്നു എന്നു് പേരുള്ള സ്വതന്ത്രമായതും മുഴുവനായും യുണിക്സ്-പോലുള്ളതുമായ ഒരു സിസ്റ്റം വികസിപ്പിയ്ക്കുക എന്നതായിരുന്നു.

സിസ്റ്റത്തിലെ സ്വതന്ത്ര സോഫ്റ്റ്‌വെയറിനു് പലരും പ്രധാന സംഭാവനകള്‍ നല്‍കിയിട്ടുണ്ടു്, അവരെല്ലാവരും ഇതിനു് അംഗികാരം അര്‍ഹിയ്ക്കുന്നുണ്ടു്. പക്ഷേ ഇതു് ഒരു സംയോജിത സിസ്റ്റമാകാന്‍ —ഉപയോഗപ്രദമായ ഒരു കൂട്ടം പ്രോഗ്രാമുകളുടെ ശേഖരം മാത്രമല്ലാതെ—കാരണം ഗ്നു സംരംഭം ഇതങ്ങനെയുള്ളൊരെണ്ണമാക്കാന്‍ തീരുമാനിച്ചതു് കൊണ്ടാണു്. ഞങ്ങള്‍ മുഴുവനായും സ്വതന്ത്രമായൊരു സിസ്റ്റമുണ്ടാക്കാന്‍ ആവശ്യമായ പ്രോഗ്രാമുകളുടെ ഒരു പട്ടികയുണ്ടാക്കുകയും, ശാസ്ത്രീയമായി അതിലെ എല്ലാ പ്രോഗ്രാമുകളും കണ്ടെത്തുകയോ, എഴുതുകയോ, എഴുതാനായി ആളുകളെ കണ്ടെത്തുകയോ ചെയ്തു. അത്യാവശ്യമായതും എന്നാല്‍ രസകരമല്ലാത്തതുമായ (1) ചില ഘടകങ്ങള്‍ ഇല്ലാതെ ഒരു സിസ്റ്റം ഉണ്ടാക്കാന്‍ പറ്റാത്തതു് കൊണ്ട് അവ ഞങ്ങള്‍ തന്നെ എഴുതി. ഞങ്ങളുടെ ചില സിസ്റ്റത്തിന്റെ ഘടകങ്ങള്‍, പ്രോഗ്രാമിങ്ങിനുള്ള പണിയായുധങ്ങള്‍, ഒറ്റയ്ക്കു് തന്നെ പ്രോഗ്രാമര്‍മാരുടെയിടയില്‍ ജനകീയമായി, പക്ഷേ പണിയായുധങ്ങളല്ലാത്ത (2) പല ഘടകങ്ങളും ഞങ്ങള്‍ എഴുതി. ഞങ്ങള്‍ ഒരു ചതുരംഗ കളി, ഗ്നു ചെസ്സ്, പോലും വികസിപ്പിച്ചെടുത്തു, കാരണം മുഴുവനായുള്ളൊരു സിസ്റ്റത്തിനു് നല്ല കളികളും ആവശ്യമാണു് എന്നതു് തന്നെ.

90 കളുടെ ആദ്യത്തോടെ കെര്‍ണലൊഴികെയുള്ള മുഴുവന്‍ സിസ്റ്റവും ഞങ്ങള്‍ തയ്യാറാക്കിയിരുന്നു (മാകിനു് മുകളില്‍ പ്രവര്‍ത്തിയ്ക്കുന്ന ഗ്നു ഹര്‍ഡ്, എന്ന കെര്‍ണല്‍ ഞങ്ങള്‍ വികസിപ്പിച്ചു് കൊണ്ടിരിയ്ക്കുകയായിരുന്നു). ഈ കെര്‍ണല്‍ വികസിപ്പിയ്ക്കുന്നതു് ഞങ്ങള്‍ പ്രതീക്ഷിച്ചതിനേക്കാള്‍ വളരെയധികം പ്രയാസമേറിയതായിരുന്നു; 2001 ല്‍ ഗ്നു ഹര്‍ഡ് വിശ്വസനീയമായി പ്രവര്‍ത്തിച്ചു് തുടങ്ങി, പക്ഷേ ഇതു് ആളുകള്‍ക്കു് പൊതുവില്‍ ഉപയോഗിയ്ക്കാന്‍ തയ്യാറാകാന്‍ ഇനിയും എത്രയോ ദൂരം പോകാനുണ്ടു്.

ഭാഗ്യത്തിനു്, ലിനക്സ് ലഭ്യമായിരുന്നതു് കാരണം ഞങ്ങള്‍ക്കു് ഹര്‍ഡിനായി കാത്തിരിയ്ക്കേണ്ടി വന്നില്ല. ലിനസ് ടോര്‍വാള്‍ഡ്സ് ലിനക്സ് എഴുതിയതോടെ അദ്ദേഹം അവസാനത്തെ വലിയ വിടവും നികത്തി. ആളുകള്‍ക്കു് ലിനക്സും ഗ്നു സിസ്റ്റവും ഒന്നിച്ചു് ചേര്‍ത്തു് പൂര്‍ണ്ണമായും സ്വതന്ത്രമായ സിസ്റ്റം: ഗ്നു സിസ്റ്റത്തിന്റെ ലിനക്സ്-അടിസ്ഥിതമായൊരു പതിപ്പു്; ചുരുക്കത്തില്‍ ഗ്നു/ലിനക്സ് നിര്‍മ്മിയ്ക്കാന്‍ സാധിച്ചു. ഏറ്റവും ആദ്യത്തെ ലിനക്സിന്റെ പുറത്തിറക്കല്‍ കുറിപ്പു് ലിനക്സൊരു കെര്‍ണലാണെന്നും ഗ്നുവിന്റെ ഭാഗങ്ങള്‍ക്കൊപ്പമാണു് ഉപയോഗിച്ചിരിയ്ക്കുന്നതെന്നും തിരിച്ചറിഞ്ഞിരിയ്ക്കുന്നു: href="http://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01"> “ലിനക്സിനൊപ്പം ഉപയോഗിയ്ക്കുന്ന കൂടുതല്‍ പണിയായുധങ്ങളും ഗ്നു കോപിലെഫ്റ്റ് പ്രകാരമുള്ള ഗ്നു സോഫ്റ്റ്‌വെയറാണു്. ഈ പണിയായുധങ്ങള്‍ വിതരണത്തിലില്ല - കൂടുതല്‍ വിവരങ്ങള്‍ക്കു് എന്നോടു് (അല്ലെങ്കില്‍ ഗ്നുവിനോടു്) ചോദിയ്ക്കൂ.”

അവ ചേര്‍ത്തു് വയ്ക്കുന്നതൊരു നിസാര പണിയായിരുന്നില്ല. ചില ഗ്നു ഘടകങ്ങള്‍(3) ലിനക്സുമായി ചേര്‍ന്നു് പ്രവര്‍ത്തിയ്ക്കുന്നതിനു് വലിയ മാറ്റങ്ങള്‍ ആവശ്യമായി വന്നു. “പുറത്തെടുക്കുമ്പോള്‍ തന്നെ” പ്രവര്‍ത്തിയ്ക്കുന്ന വിതരണമായി മുഴുവന്‍ സിസ്റ്റവും സംയോജിപ്പിയ്ക്കുന്നതു് ഒരു വലിയ പണി തന്നെയായിരുന്നു. ഇതിനായി സിസ്റ്റം ഇന്‍സ്റ്റോള്‍ ചെയ്യുന്നതും ബൂട്ട് ചെയ്യുന്നതുമെങ്ങനെയാണെന്നു് പരിഗണിയ്ക്കേണ്ടിയിരുന്നു — ആ സ്ഥാനത്തെത്താത്തതിനാല്‍ ഞങ്ങള്‍ പരിഹരിയ്ക്കാതിരുന്നൊരു പ്രശ്നമായിരുന്നു അതു്. അതിനാല്‍ തന്നെ സിസ്റ്റത്തിന്റെ പല വിതരണങ്ങളും വികസിപ്പിച്ചെടുത്തവര്‍ പല അത്യാവശ്യ പണികളും ചെയ്തു. പക്ഷേ അതു്, കാര്യത്തിന്റെ കിടപ്പുവശം നോക്കിയാല്‍, ഉറപ്പായും ആരെങ്കിലും ചെയ്യാന്‍ പോകുന്ന ജോലിയായിരുന്നു.

ഗ്നു/ലിനക്സ് സിസ്റ്റങ്ങളേയും ഗ്നു എന്ന സിസ്റ്റത്തിനേയും ഗ്നു സംരംഭം പിന്തുണയ്ക്കുകയും അവയില്‍ പ്രവര്‍ത്തിയ്ക്കാന്‍ എഫ്എസ്എഫ് പണമിറക്കുകയും ചെയ്യുന്നു. ലിനക്സുമായി നന്നായി ചേര്‍ന്നു പ്രവര്‍ത്തിയ്ക്കുന്നതിനു് ലിനക്സുമായി ബന്ധപ്പെട്ട ഗ്നു സി ലൈബ്രറിയിലുള്ള കൂട്ടിച്ചേര്‍ക്കലുകള്‍ക്കു് വേണ്ടി മാറ്റിയെഴുതാന്‍ എഫ്എസ്എഫ് പണമിറക്കുകയും ഏറ്റവും പുതിയ ഗ്നു/ലിനക്സ് സിസ്റ്റങ്ങള്‍ അപ്പപ്പോഴിറങ്ങുന്ന ലൈബ്രറി പതിപ്പുകള്‍ മാറ്റമൊന്നുമില്ലാതെ തന്നെ ഉപയോഗിയ്ക്കുകയും ചെയ്യുന്നു. എഫ്എസ്എഫ് ഡെബിയന്‍ ഗ്നു/ലിനക്സിന്റെ ആദ്യഘട്ട വികസനത്തിനും പണമിറക്കി.

ലിനക്സ്-അടിസ്ഥാനമാക്കിയ ഗ്നു സിസ്റ്റങ്ങളാണു് ഇന്നു് ഞങ്ങള്‍ എല്ലാ ജോലികള്‍ക്കും ഉപയോഗിയ്ക്കുന്നതു്, നിങ്ങളും അവ തന്നെ ഉപയോഗിയ്ക്കുമെന്നാണു് ഞങ്ങളുടെ പ്രതീക്ഷ. ഇന്നു് ഗ്നു/ലിനക്സ് സിസ്റ്റത്തിന്റെ പല വ്യത്യസ്ത വ്യതിയാനങ്ങളും ഉണ്ടു് (പലപ്പോഴും “വിതരണങ്ങള്‍” എന്നാണവയെ വിളിയ്ക്കുന്നതു്). അവയില്‍ കൂടുതലും സ്വതന്ത്രമല്ലാത്ത സോഫ്റ്റ്‌വെയറും ചേര്‍ക്കുന്നുണ്ടു് — അവയുടെ രചയിതാക്കള്‍ ഗ്നുവിനു് പകരം ലിനക്സുമായി ബന്ധപ്പെട്ട തത്വശാസ്ത്രമാണു് പിന്തുടരുന്നതു്. പക്ഷേ മുഴുവനായും സ്വതന്ത്രമായ ഗ്നു/ലിനക്സ് വിതരണങ്ങളുമുണ്ടു് . ഉട്ടുട്ടോ, ഗ്ന്യൂസെന്‍സ് എന്നീ രണ്ടു് വിതരണങ്ങളെ എഫ്എസ്എഫ് കമ്പ്യൂട്ടര്‍ സൌകര്യങ്ങള്‍ വഴി പിന്തുണയ്ക്കുന്നു.

നിങ്ങള്‍ക്കു് “ഗ്നു/ലിനക്സിനെക്കുറിച്ചു്” കൂടുതല്‍ വിവരത്തിനായി കണ്ണിചേര്‍ക്കണമെങ്കില്‍ ഈ താളും http://www.gnu.org/gnu/the-gnu-project.html എന്ന താളും നല്ലതാണു്. ലിനക്സ് എന്ന കെര്‍ണലിനെക്കുറിച്ചു് കൂടുതല്‍ വിവരത്തിനു് കണ്ണിചേര്‍ക്കണമെങ്കില്‍ href="http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?Linux"> http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?Linux എന്നതു് ഉപയോഗിയ്ക്കാന്‍ ചേര്‍ന്നൊരു നല്ല യുആര്‍എല്ലാണു്.

അടിക്കുറിപ്പു്: ഗ്നുവിനു് പുറമേ വേരൊരു സംരംഭവും ഒരു സ്വതന്ത്രമായ യുണിക്സ്-പോലുള്ള പ്രവര്‍ത്തക സംവിധാനം ഒറ്റയ്ക്കു് നിര്‍മ്മിച്ചിട്ടുണ്ടു്. യുസി ബെര്‍ക്കിലിയില്‍ വികസിപ്പിച്ചെടുത്ത ഈ സിസ്റ്റം ബിഎസ്ഡി എന്നാണറിയപ്പെടുന്നതു്. 80 കളില്‍ ഇതു് സ്വതന്ത്രമല്ലായിരുന്നു, പക്ഷേ 90 കളുടെ ആദ്യത്തില്‍ ഇതു് സ്വതന്ത്രമായി. ഇന്നു് നിലവിലുള്ള ഒരു സ്വതന്ത്ര പ്രവര്‍ത്തക സംവിധാനം ഏതാണ്ടുറപ്പായും ഗ്നുവില്‍ നിന്നുള്ളൊരു വ്യതിയാനമോ അല്ലെങ്കില്‍ ഒരു ബിഎസ്ഡി സിസ്റ്റമോ ആണു്.

ഗ്നു/ലിനക്സ് പോലെ ബിഎസ്ഡിയും ഗ്നുവിന്റെ ഒരു പതിപ്പാണോ എന്നു് ആളുകള്‍ ചിലപ്പോള്‍ ചോദിയ്ക്കാറുണ്ടു്. ബിഎസ്ഡിയുടെ രചയിതാക്കള്‍ ഗ്നു സംരംഭത്തിന്റെ ഉദാഹരണത്തില്‍ നിന്നും ആവേശമുള്‍ക്കൊണ്ടും ഗ്നു പ്രവര്‍ത്തകരില്‍ നിന്നതിനായുള്ള ആവശ്യപ്പെടല്‍ കൊണ്ടും സ്വതന്ത്ര സോഫ്റ്റ്‌വെയറാക്കിയതാണെങ്കിലും അവരുടെ കോഡും ഗ്നുവുമായി ബന്ധമൊന്നുമുണ്ടായിരുന്നില്ല. ഇന്നു് ഗ്നുവും അതിന്റെ വ്യതിയാനങ്ങളും ബിഎസ്ഡി പ്രോഗ്രാമുകളുപയോഗിയ്ക്കുന്നതു് പോലെ തന്നെ ബിഎസ്ഡി സിസ്റ്റങ്ങള്‍ ചില ഗ്നു പ്രോഗ്രാമുകളുപയോഗിയ്ക്കുന്നുണ്ടു്; എന്നിരുന്നാലും മുഴുവനായെടുത്താല്‍ അവ രണ്ടും വെവ്വേറെ വളര്‍ന്നുവന്ന രണ്ടു് വ്യത്യസ്ത സിസ്റ്റങ്ങളാണു്. ബിഎസ്ഡിയുടെ രചയിതാക്കള്‍ ഒരു കെര്‍ണലെഴുതി ഗ്നുവിനോടു് ചേര്‍ത്തതല്ലാത്തതിനാല്‍ തന്നെ ഗ്നു/ബിഎസ്ഡി എന്ന പേരു് ഇവിടെ ചേരുകയില്ല. href="#gnubsd">(4)

Notes:

1. ഇപ്പോള്‍ ഗ്നു ബിന്‍യൂട്ടില്‍സിന്റെ ഭാഗമായ ഗ്നു അസംബ്ലര്‍ എന്ന ജിഎഎസ്, ലിങ്കര്‍ എന്ന ജിഎല്‍ഡി എന്നീ പാക്കേജുകളും ഗ്നു ടാറും, മറ്റു് പലതും ഉള്‍ക്കൊള്ളുന്നതാണു് ഈ അത്യാശ്യവും എന്നാല്‍ രസകരമല്ലാത്തതുമായ ഘടകങ്ങള്‍.
2. ഉദാഹരണത്തിനു് ബോണ്‍ എഗെയിന്‍ ഷെല്‍ (ബാഷ്), ഗോസ്റ്റ്സ്ക്രിപ്റ്റ് എന്ന പോസ്റ്റ്സ്ക്രിപ്റ്റ് ഇന്റര്‍പ്രട്ടര്‍, ഗ്നു സി ലൈബ്രറി തുടങ്ങിയവ പ്രോഗ്രാമിങ്ങിനുള്ള പണിയായുധങ്ങളല്ല. ഗ്നുകാഷ്, ഗ്നോം, ഗ്നു ചെസ്സ് എന്നിവയും അത്തരത്തിലുള്ളവയല്ല..
3. ഉദാഹരണത്തിനു്, ഗ്നു സി ലൈബ്രറി.
4. എന്നാല്‍, ഈ ലേഖനം എഴുതിയതിനു് ശേഷം വര്‍ഷങ്ങള്‍ കഴിഞ്ഞപ്പോള്‍ ഗ്നു സി ലൈബ്രറി പ്രവര്‍ത്തിയ്ക്കുന്നതാക്കിയട്ടുണ്ടു് എന്നതു് ഗ്നു സിസ്റ്റവും ആ കെര്‍ണലും ഒന്നിപ്പിയ്ക്കുന്നതു് സാധ്യമാക്കി. ഗ്നു/ലിനക്സ് പോലെ ഇവയും തീര്‍ച്ചയായും ഗ്നുവിന്റെ വ്യതിയാനങ്ങളാണു്, അതുകൊണ്ടു് തന്നെ സിസ്റ്റത്തിലെ കെര്‍ണലിനനുസരിച്ചു് ഇവയെ ഗ്നു/കെഫ്രീബിഎസ്ഡി ഗ്നു/കെനെറ്റ്ബിഎസ്ഡി എന്നിങ്ങനെ വിളിയ്ക്കാറുണ്ടു്. സാധാരണ ഉപയോക്താക്കള്‍ക്കു് ഗ്നു/ലിനക്സും ഗ്നു/*ബിഎസ്ഡിയുമായി വേര്‍തിരിച്ചറിയാന്‍ പോലും പ്രയാസമാണു്.

ഇതു് വെബ്‌ദുനിയയുടെ തെരച്ചില്‍ ഫലം.

"അതുകൊണ്ട് അധികം റിസോര്‍സസില്ലാത്ത ഡെവലപ്പര്‍മാരും കമ്പനികളും വിചാരിക്കും ‘ഓ.. ഈ മലയാളം ഭാഷയിലൊക്കെ ആരെഴുതാനാ? അതില്ലാത്ത സപ്പോര്‍ട്ട് ഒക്കെ മതി" - സിബു

നമ്മുടെ ഭാഷയോടെന്തു് സ്നേഹം അല്ലേ? ഇവിടെയാണു് സ്വതന്ത്ര സോഫ്റ്റ്‌വെയറിന്റെ പ്രസക്തി. നമ്മുടെ ഭാഷയെ പിന്തുണയ്ക്കുന്നില്ലെങ്കില്‍ വലിച്ചെറിയണം അങ്ങനെയുള്ള പ്രയോഗങ്ങളൊക്കെ. സ്വതന്ത്ര സോഫ്റ്റ്‌വെയറില്‍ മലയാളം പിന്തുണയില്ലെങ്കില്‍ അതിനാരോടും യാചിയ്ക്കേണ്ട കാര്യമൊന്നുമില്ല, നമുക്കു് തന്നെ ശരിയാക്കാം, അങ്ങനെ ഗ്നു ആസ്പെല്‍ പോലുള്ള പ്രയോഗങ്ങള്‍ ശരിയാക്കിയിട്ടുമുണ്ടു്.

മലയാളത്തെപ്പറ്റി ഇങ്ങനെയൊക്കെ ചിന്തിയ്ക്കുന്ന വെണ്ടര്‍മാര്‍ക്കു് വേണ്ടിയാണോ ഈ ആണവ ചില്ലു്?

Cibu C J wrote,

> Of course, Unicode and IETF have specs to specify locale or script based
> exceptions. The fact that chillus has to make use of all those is a pretty
> good indication that it is a excellent idea to encode them and remove all
> those requirement for exceptions.

Any time settings are referred to as "default", it means that they
are subject to change. Often the ability to change settings extends
all the way down the line to the end-user. Making a setting "default"
is a good indication that the engineer(s) expect people to want the
ability to change that setting.

Chillu forms should not require custom settings in most instances.
As sequences, they would not cause exceptional behaviour in any
application which did not strip ZWJs from the data. In those cases
where applications strip ZWJs from the data, users appear to consider
the process either beneficial or benign. In cases where ZWJ-stripping
is regarded as malign, then it may be an excellent idea to change the
default settings so that the application becomes workable.

> Those exceptions and character properties like 'default-ignorable' are there
> for a reason. It is there to choose between a coarse or fine tuned
> implementation based on the resources the implementor has. It is a great
> thing for the language that, the script can remain intact in a coarse
> implementaiton as well. For Malayalam, that will be more or less true after
> chillu encoding. So it will be better supported in resource constrained
> platforms or implementations.

The source data itself should remain intact regardless of an application's
tuning. In this way the author's intent is preserved and the script
remains intact as a matter of course.

I'm not understanding how atomic chillu encoding makes Malayalam
better supported in resource constrained environments. Would you
elaborate? To me, a resource constrained environment suggests a
system with limited memory, where duplicate encodings would add
to the strain.

(I do understand that character properties exist for good reason.)

Let's suppose you are involved with a hypothetical search engine
company called "DataQuest" and, for one reason or another, decide
to research the frequency of web pages which offer text in the
fictional Klingon language/script using the ConScript Unicode
Registry's Private Use Area Unicode encoding.

You might proceed by entering some common words into the
search box of your engine. If your engine restricts P.U.A. characters,
or maps them all to zero, your search results would be nothing.
However, since you pulled those common words from a web page
in the first place, you know that such pages exist. Would this
be a good indication that it is time to change the settings? Or
would it be better to encode Klingon in TUS? (smile)

If that hypothetical situation is too far-fetched, suppose you
are working for a real company and Malayalee users were complaining
about search results being too fuzzy because your collation interface
was stripping certain characters for comparison purposes.

Best regards,

Cibu,

Good that you finally understand what "tailoring" means. Now for the
problems of your "theory":

In the Unicode ecosystem, we can consider the following levels of systems:

1) Higher-level applications (including advanced rendering,
spell-check, grammar-check, etc)
2) Low-level applications (including rendering, input, sorting, etc)
3) the Unicode encoding itself

Your theory seeks to disambiguate chillus from vowelless consonants
(for some odd reason even though even you cannot state without
contradicting yourself, that they are the same), i.e., you want atomic
chillus at level 3 in order to support one application at level 2,
rendering application.

If the atomic chillus come into force, then all applications other
than rendering requires a "tailoring" which equates <atomic chillu> ==
<consonant> + chandrakkala ... for e.g.,
in sorting, atomic-chillu-NA == NA + chandrakkala
in IDN, atomic-chillu-NA == NA + chandrakkala

Implementation of input method "Inscript" will also require the
"tailoring" atomic-chillu-NA <= kNA + kChandrakkala + kNUK (aka ZWJ)

where kX means "key for character X on keyboard", and <= means
"produced by key sequence".

Implementation of input method "Typewriter" will have to disambiguate
when the user means atomic chillu from when the user means
vowelless-consonant

(Similiarly for other input methods).

People like Santhosh Thottingal, will probably agree that
atomic-chillu vs vowelless-consonant is a meaningless difference as
regards spell-check, because the system can never really rely on the
user to actually type atomic-chillu when he means vowelless-consonant
and vice-versa.

In other words, your theory seeks atomic-chillus, but for every
application other than rendering, we need to add tailorings for
Malayalam to state that this disastrous atomic-chillu ==
vowelless-consonant.

The case of rendering is a little more complicated. But it was
resolved in a pratical manner by the workshop help at Kerala
University. Please see the docs for more info. But we can say one
thing regarding rendering - it too requires two mappings for the
gChilluNa glyph viz., atomic-chillu-na CMAP and (gNa+gChandrakkala
GSUB or gNa + gChandrakkala + gZWJ GSUB depending on the shaping
engine involved).

So then, whats the real use of your atomic chillus, other than further
problems, and tailoring all other applications to require a map from
atomic-chillu back to consonant+chandrkkala ?

To Everyone Else: The UTC meeting is on the 4th i.e., tomorrow; have
you submitted your opposition to atomic-chillus ?

Cibu C J responded to an ostensibly rhetorical question,

Collation keys are not really my forte, so I must quote from an
established expert.

Quoting from Kenneth Whistler's message to the Unicode public list
from 2002/03/01,

http://www.unicode.org/mail-arch/unicode-ml/y2002-m03/0028.html

<begin quote>
The answer for this can be found in UTS #10 Unicode Collation Algorithm.

The default behavior that many people will be implementing for searching
and sorting will depend on the default collation table for the UCA.
And in that table, with few exceptions, format control characters,
such as ZWJ and ZWNJ are given completely ignorable weight values.
In particular, in the current allkeys.txt, you find:

200C ; [.0000.0000.0000.0000] # [200C] ZERO WIDTH NON-JOINER
200D ; [.0000.0000.0000.0000] # [200D] ZERO WIDTH JOINER

The all-zero weights mean that these two characters would contribute
nothing to sort key weight generation, and thus would effectively
be ignored for all comparisons.

Of course, the values can be tailored to any value desired. This
may not always be apparent to end users, however, as it will depend
on how particular implementations of the UCA surface their tailoring
options. In many instances, people will depend on a number of
preset options for searching and sorting via a GUI interface, or
at best an API, and won't be tinkering down at the level of
individual character weight assignments.

On the other hand, not all searching and sorting of Unicode data
will be making use of the Unicode Collation Algorithm (or ISO 14651),
and in those instances, different behavior may occur. For example,
for simple, binary string comparisons, the presence or absence
of any character, including a ZWJ or ZWNJ, obviously *would* make
a difference in results.
<end quote>

An important part of Kenneth Whistler's answer is this statement:
"Of course, the values can be tailored to any value desired."

The DUCET is the default. Speaking for myself, when an application
offers me a choice between "default" and "custom", I usually opt
for custom. It would be natural to expect that Malayalee engineers
working with collation will "get it right".

Best regards,

യൂണികോഡിന്റെ നിയമത്തില്‍ പോലും നിങ്ങള്‍ക്കിഷ്ടമുള്ള കൊളേഷന്‍ വില (അകാരാദിക്രമത്തില്‍ തരം തിരിയ്ക്കുമ്പോളുള്ള പ്രാധാന്യം) ജോയിനറുകള്‍ക്കു് കൊടുക്കാമെന്നു് പറയുമ്പോള്‍ ആണവ ചില്ലിന്റെ അവസാന വാദത്തിന്റേയും മുനയൊടിയുന്നു. പക്ഷേ ഇതൊന്നും ആര്‍ക്കും ഇവിടെ അറിയണ്ടല്ലോ. സ്വന്തം ഭാഷയെ അലുക്കുലുക്കാന്‍ ചില മലയാളികളുടെ ഗൂഢ ശ്രമത്തെ തുറന്നു കാട്ടാന്‍ ചില സായിപ്പന്‍മാരെങ്കിലും മുന്നോട്ടു് വരുന്നതെന്തൊരാശ്വാസം.

നന്ദി ജെയിംസ്.

Meaning change example using ZWNJ in Malayalam

The basic argument that Cils are independent is void, because a glyph of Cil-ya is not in use. The very reference used to “prove” the independent nature of Cils, presents the Cilling property of YA using an example kaay_kaRikaL(കായ്​കറികള്‍).

As there is no independent glyph for Cil-Y, atomic encoding is not possible

Let’s make the applications not remove/strip the joiners by suitable amendment in the standard. This is a solution and this is the solution.
If the vendors need their applications compliant to the standard, they will make necessary changes. There are open source solutions already working with the preserved joiners. These vendors also can follow the suit.

Rajiv J Sebastian responds to Cibu:

On Jan 28, 2008 2:22 AM, Cibu C J

> - It does not use any joiners and the associated mess: loosing them,
> collation weight 0, IDN anomalies etc.

This is hogwash.

There is no "mess" in using ZWJ.

In particular "losing them" is an irresponsible and totally worthless argument: if any system is compelled to randomly "lose" data, then such a system would be considered faulty and probably thrown in the junkyard.

Collation weight 0 for ZWJ is advantageous and actually leads to the correct sorting of malayalam.

IDN "anomalies" ? What anomalies ? Remember that noone except some innocent people who do not know Malayalam as well as we do, has accepted your so called "examples" of "vanyavanika" and "kanvalayam".

From eminent linguists like Prof. KP Mohanan to the common people, all laugh at these so called "words". The anomalies are created by your *theory* of how chillus should be handled, which btw carries no weight and holds no water among experts of Malayalam and Malayalam Computing.

Perhaps you have convinced some westerners sitting in meeting halls in California, but I would like to remind you that the minute that standards become useless to the people, they become irrelevant and they will be discarded. Nothing really forces people to stick to Unicode, just as none really stuck to IISCI and the other so-called "standards".

Cibu, with your new-found influence in certain corporations and decision-making bodies, what you are doing knowingly or unknowingly, you are destroying a language. From the beginning of the chillu debate, all the time you came up with some flimsy arguments with the under-table support of some Unicode officials and some policians and committee members and IT-establishment people at Thiruvananthapuram for your cause. Even with all this, the number of people that "support" the atomic chillu can be counted on one's hands; till now there has been no genuine counter-arguments to what we have said through our documents, instead there was only widespread support.

Also, I would like to remind people on the list that there is no logical reason why chillus are being encoded today. They are being added to the lists purely for political/administrative reasons. It is funny considering that the UTC is supposed to be standing for the side of truth and logic.

As far as "support" is concerned, please remember that a large number of scholars and scientists involved in Malayalam and malayalam computing met last year at the Kerala University-held workshop and resolved not to accept the atomic chillus. The important thing to note in this regard was that the "problems/issues" that Cibu and his playmates introduced were taken one by one, the pros and cons were enumerated impartially with academic honesty, were examined in detail, and finally came to the conclusion that these arguments were baseless and worthless. Apparently, they have sent it to UTC and concerned authorities.

Also, all sides of the issues have been discussed in several forums, both mailing lists and elsewhere. But, to date, there has been no credible supporting arguments for the atomic chillus. On the other hand, the arguments against atomic chillus have so far not been countered convincingly, including IDNA issue which atomic-chillu-people brought in as an argument of "last-resort".

The problem is that, none of the issues have been taken up on their merits.

This is the history of the Malayalam encoding debate. As people who brought the issues to the table, and who upheld the original stand of Unicode and UTC, what we have to say is that we are not for research on the various activities of people like Cibu, Everson, etc.

If the UTC wishes to ignore it, then so be it; but it would be at the risk of their own reputations. In any case, people like Cibu are not representative of Malayalam or Malayalees.

Either way, if UTC encodes atomic chillus, either Malayalam will fail in IDN, or UTC will contradict itself.

Regards
Rajeev J Sebastian

PS: For those who have not seen the report of the Kerala University workshop, please ask UC for a copy of the same, or I can send it to you.

You can read the report here.

5. അല്ല ഇതു് ഒരക്ഷരം തന്നെ കാഴ്ചയില്‍ വ്യത്യാസമില്ലാത്ത രണ്ടു് തരത്തിലെഴുതാവുന്നതാക്കില്ലേ (ഡ്യുവല്‍ എന്‍കോഡിങ്ങ്)? ഇതു് വ്യാജസൈറ്റുകളുണ്ടാക്കുന്നതെളുപ്പമാക്കുകയും തെരയുന്നതും അകാരദിക്രമത്തില്‍ തരം തിരിയ്ക്കുന്നതും പ്രയാസമാക്കുകയും ചെയ്യില്ലേ?

-> അവരും ഇവരുമൊക്കെ അതു് മനസ്സിലാക്കിയാല്‍ സംഗതി തീരില്ലേ? തെരച്ചില്‍ നടത്തുന്ന ബല്ല്യൊരു കമ്പനി എന്തായാലും ഇതൊക്കെ ശരിയാക്കും. പിന്നെ ജിലിബ്സി ജിലിബ്സി എന്നു് പറഞ്ഞൊരു സാധനമുണ്ടല്ലോ.

അപ്പോ ഈ ഭാരമൊക്കെ പ്രയോഗങ്ങളെഴുതുന്ന ഓരോരുത്തരം ചുമന്നോളുമെന്നോ?  ചില്ലക്ഷരമുള്ളൊരു വാക്കെങ്ങനെ തെരയും? പഴയ ചില്ലടിച്ചാല്‍ പുതിയ ചില്ലു് കിട്ടില്ല, പുതിയ ചില്ലടിച്ചാല്‍ പഴയ ചില്ലു് കിട്ടില്ല. ചില്ലക്ഷരമുള്ള രണ്ടു് വാക്കുകള്‍ പൊരുത്തമുണ്ടോന്നെങ്ങനെ നോക്ക്വാ? ഒന്നു് പഴേ ചില്ലുപയോഗിച്ചും മറ്റേതും പുതിയ ചില്ലുപയോഗിച്ചുമാണെങ്കില്‍ രണ്ടുമെങ്ങനെ സമമാകും?

> 4. But if you can't forbid the existing sequences what use is the newly
> added atomic chillus going to serve?

A.  It adds variant spellings, which is not always a good thing.
B.  It offers employment opportunities for people involved in
    file/character conversion.
C.  It offers more employment opportunities for anyone working
    in text processing, search engine technology, text display, and
    so forth because everything will need to be upgraded to support
    the new variant spellings.

ചര്‍ച്ചാവിഷയങ്ങള്‍

1. സ്വതന്ത്ര മലയാളം കമ്പ്യൂട്ടിങ്ങ്: പരിചയപ്പെടുത്തല്‍
2. മലയാളം പ്രാദേശികവത്കരണം- എങ്ങനെ പങ്കെടുക്കാം
3. മലയാളം സോഫ്റ്റ്വെയറുകള്‍ പരിചയപ്പെടല്‍
4. സ്വതന്ത്ര സോഫ്റ്റ്വെയറുകളെക്കുറിച്ചുള്ള സംശയങ്ങള്‍