Is there an official policy for FSF with regards how long to carry the ever increasing legacy baggage before breaking backward compatibility and coming up with something entirely new?<br><br>Sometimes we have done that... like we have made Gnu/Linux compatible (that is, with respect to POSIX) with UNIX. But then we were not feeling that UNIX System Call Interfaces were wrong. We were fighting with the licensing.<br>
<br>At other times, we broke backward compatibility. Non of the ogg Vorbis files were playable in Mp3 players back then. We broke backward compatibility due to the presence of patents.<br><br>We (FSF) wanted people to use Open Document Format for Office Applications, when it was not at all compatible with Microsoft Word 1997 Format. We broke compatibility, for greater good.<br>
<br><div class="gmail_quote">2011/2/10 കെവി & സിജി <span dir="ltr"><<a href="mailto:kevinsiji@gmail.com" target="_blank">kevinsiji@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

2011/2/3 Jayadevan Raja <<a href="mailto:jayadevanraja@gmail.com" target="_blank">jayadevanraja@gmail.com</a>>:<br>
<div>> നിലവിലുള്ള സ്റ്റാന്‍ഡേഡിന്റെ അപാകതകള്‍ വളരെ വലുതാണെങ്കില്‍, അവയെ മാറ്റാന്‍<br>
> തീര്‍ത്തും പുതിയ ഒരു സമീപനം നല്ലതാണെങ്കില്‍, പുതിയ ഒരു സ്റ്റാന്‍ഡേഡ്<br>
> അത്യാവശ്യം ആണല്ലൊ...<br>
><br>
> യുണികോഡിന്റെ തുടക്കത്തിലെ ലക്ഷ്യങ്ങളില്‍നിന്നു് ഇപ്പോഴത്തെ അവസ്ഥ എത്ര മാറി,<br>
> തുടക്കത്തിലെ ലക്ഷ്യങ്ങളുടെ പിഴവുകള്‍ ഏവ, മുതലായ കാര്യങ്ങള്‍<br>
> പരിശോധിക്കണ്ടതല്ലെ?<br>
><br>
><br>
><br>
> നിലവിലുള്ള യുണികോഡിന്റെ ചില പിശകുകള്‍<br>
><br>
> (1) CJK ക്കും ലാറ്റിനും വളരെ ഏറെ കോംപോസിറ്റ് കാരക്റ്ററുകളുണ്ടു്. ഇവയെല്ലാം<br>
> ഒഴിവാക്കപ്പെട്ടാല്‍, 16 ബിറ്റില്‍ എല്ലാ ലിപികളേയും ഉള്‍പ്പെടുത്താം. ലോകത്തു്<br>
> പ്രധാന ലിപികള്‍ (Writing Systems) കുറച്ചു് നൂറുകളല്ലെ ഉള്ളൂ.<br>
<br>
</div>ഈ കാര്യത്തില്‍ അതാതു ഭാഷാവിദഗ്ദ്ധര്‍ തീരുമാനിയ്ക്കട്ടെ.<br>
ഭാഷാവിദഗ്ദ്ധരല്ലാത്ത വിദേശികള്‍ തീരുമാനങ്ങളെടുക്കുന്നതാണല്ലോ<br>
യൂണീക്കോഡിന്റെ ഏറ്റവും വലിയ പ്രശ്നം.<br>
<div><br>
> (2) എല്ലാ കാരക്റ്ററിനും ഒരൊറ്റ യുനീക്‍ റെപ്രസന്റേഷന്‍ കൊടുത്താല്‍<br>
> (പ്രീകംപോസ്ഡ് ഫോം ഒന്നും ഇല്ലെങ്കില്‍) ലാളിത്യം ഉണ്ടാവും<br>
> (3) 16 ബിറ്റ് തന്നെ ആണെങ്കില്‍ ഒരു യുനീക്‍ എങ്കോഡിങ് കൊടുക്കാം. UTF8,<br>
> UTF16LE, UTF16BE, UTF32LE, UTF32BE മുതലായ പല എങ്കോഡിങ്ങുകളുടെ ആവശ്യം<br>
> ഉണ്ടാവില്ല. കണ്‍ഫ്യൂഷന്‍ ഒഴിവാവും.<br>
<br>
</div>യുണീക്കോഡ് എന്തിനു വിവിധ പ്ലെയ്നുകള്‍ ഉണ്ടാക്കി?<br>
<div><br>
> (4) ചരിത്രപരം ആയ തെറ്റുകളെ തിരുത്താം. ഉദാഹരണത്തിനു് 1,2,3,... ഇന്ത്യന്‍<br>
> സംഭാവനയാണു്. ഇന്തൊ-അറബി എന്നറിയപ്പെടുന്നു. പക്ഷെ, യുണികോഡില്‍ ഇതു് ബേസിക്‍<br>
> ലാറ്റിനാണു്! സത്യത്തില്‍ ബേസിക്‍ ലാറ്റിന്‍ ഇതല്ലെ: I, II, III, IV, V, ...?<br>
<br>
</div>ശരിയാണു്, ഒരു സ്വതന്ത്രസ്റ്റാന്‍ഡേഡ് ഉണ്ടാക്കുമ്പോള്‍, പൂര്‍ണ്ണമായും<br>
പുതുതായി തുടങ്ങുന്ന അവസരത്തില്‍, ആസ്കിയെ അടിസ്ഥാനമാക്കി എടുക്കേണ്ടതില്ല.<br>
അപ്പോള്‍ ഈ പ്രശ്നവും പരിഹരിയ്ക്കപ്പെടും.<br>
<font color="#888888"><br>
കെവി.<br>
</font><div><div></div><div>_______________________________________________<br>
Swathanthra Malayalam Computing discuss Mailing List<br>
Project: <a href="https://savannah.nongnu.org/projects/smc" target="_blank">https://savannah.nongnu.org/projects/smc</a><br>
Web: <a href="http://smc.org.in" target="_blank">http://smc.org.in</a> | IRC : #smc-project @ freenode<br>
<a href="mailto:discuss@lists.smc.org.in" target="_blank">discuss@lists.smc.org.in</a><br>
<a href="http://lists.smc.org.in/listinfo.cgi/discuss-smc.org.in" target="_blank">http://lists.smc.org.in/listinfo.cgi/discuss-smc.org.in</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Thanking You,<br>Jayadevan V<br>