ટર્મિનલ એમ્યુલેટર્સની ઝાંખી

અમારા અનુવાદ બ્યુરોના થોડાક શબ્દો: સામાન્ય રીતે દરેક જણ નવીનતમ સામગ્રી અને પ્રકાશનોનું ભાષાંતર કરવાનો પ્રયત્ન કરે છે, અને અમે તેનો અપવાદ નથી. પરંતુ ટર્મિનલ્સ એવી વસ્તુ નથી કે જે અઠવાડિયામાં એકવાર અપડેટ થાય. તેથી, અમે તમારા માટે 2018 ની વસંતમાં પ્રકાશિત એન્ટોઈન બ્યુપ્રેના લેખનો અનુવાદ કર્યો છે: આધુનિક ધોરણો દ્વારા તેની નોંધપાત્ર "વય" હોવા છતાં, અમારા મતે, સામગ્રીએ તેની સુસંગતતા બિલકુલ ગુમાવી નથી. વધુમાં, આ મૂળરૂપે બે લેખોની શ્રેણી હતી, પરંતુ અમે તેમને એક મોટી પોસ્ટમાં જોડવાનું નક્કી કર્યું છે.

કોમ્પ્યુટર ઈતિહાસમાં ટર્મિનલ્સનું વિશેષ સ્થાન છે, પરંતુ તાજેતરના દાયકાઓમાં ગ્રાફિકલ ઈન્ટરફેસ સર્વવ્યાપક બની જતાં તેઓને આદેશ વાક્યની સાથે ટકી રહેવાની ફરજ પડી છે. ટર્મિનલ એમ્યુલેટર્સ તેમના પોતાના બદલ્યા હાર્ડવેર ભાઈઓ, જે બદલામાં, પંચ્ડ કાર્ડ્સ અને ટૉગલ સ્વીચો પર આધારિત સિસ્ટમ્સમાં ફેરફાર હતા. આધુનિક વિતરણો તમામ આકાર અને રંગોના વિવિધ ટર્મિનલ એમ્યુલેટર સાથે આવે છે. અને જ્યારે ઘણા લોકો તેમના કામના વાતાવરણ દ્વારા પૂરા પાડવામાં આવેલ માનક ટર્મિનલથી સંતુષ્ટ હોય છે, ત્યારે કેટલાક તેમના મનપસંદ શેલ અથવા ટેક્સ્ટ એડિટર ચલાવવા માટે ગર્વથી એકદમ વિચિત્ર સોફ્ટવેરનો ઉપયોગ કરે છે. પરંતુ, જેમ આપણે આ લેખમાંથી જોઈશું, બધા ટર્મિનલ્સ એક જ છબીમાં બનાવવામાં આવ્યા નથી: તેઓ કાર્યક્ષમતા, કદ અને પ્રભાવમાં મોટા પ્રમાણમાં અલગ છે.

કેટલાક ટર્મિનલ્સમાં એકદમ આશ્ચર્યજનક સુરક્ષા છિદ્રો હોય છે, ઉપરાંત મોટા ભાગનામાં ટેબવાળા ઈન્ટરફેસ માટે સપોર્ટથી લઈને સ્ક્રિપ્ટીંગ સુધીના કાર્યોનો સંપૂર્ણ અલગ સેટ હોય છે. જોકે અમે દૂરના ભૂતકાળમાં ટર્મિનલ ઇમ્યુલેટર્સ તરફ જોયું, આ લેખ અગાઉની સામગ્રીનું અપડેટ છે જે વાચકોને 2018 માં કયા ટર્મિનલનો ઉપયોગ કરવો તે નક્કી કરવામાં મદદ કરશે. લેખનો પ્રથમ અર્ધ લક્ષણોની તુલના કરે છે, અને બીજા ભાગમાં પ્રદર્શનનું મૂલ્યાંકન કરે છે.

મેં સમીક્ષા કરેલ ટર્મિનલ્સ અહીં છે:

આ નવીનતમ સંસ્કરણો ન હોઈ શકે, કારણ કે હું લેખન સમયે સ્થિર બિલ્ડ્સ સુધી મર્યાદિત હતો, જેને હું ડેબિયન 9 અથવા ફેડોરા 27 પર રોલ આઉટ કરવામાં સક્ષમ હતો. એકમાત્ર અપવાદ એલાક્રિટી છે. તે GPU-એક્સિલરેટેડ ટર્મિનલ્સનો વંશજ છે અને આ કાર્ય માટે અસામાન્ય અને નવી ભાષામાં લખાયેલ છે - રસ્ટ. મેં મારી સમીક્ષામાંથી વેબ ટર્મિનલ્સને બાકાત રાખ્યા છે (તેઓ સહિત ઇલેક્ટ્રોન), કારણ કે પ્રારંભિક પરીક્ષણોએ તેમનું અત્યંત નબળું પ્રદર્શન દર્શાવ્યું હતું.

યુનિકોડ સપોર્ટ

મેં યુનિકોડ સપોર્ટ સાથે મારા પરીક્ષણો શરૂ કર્યા. ટર્મિનલ્સની પ્રથમ કસોટી યુનિકોડ સ્ટ્રિંગને પ્રદર્શિત કરવાની હતી વિકિપીડિયા લેખો: “é, Δ, И, ק, م, ๗, あ, 叶, 葉 અને 말.” આ સરળ પરીક્ષણ બતાવે છે કે શું ટર્મિનલ વિશ્વભરમાં યોગ્ય રીતે કાર્ય કરી શકે છે. xterm ટર્મિનલ અરબી અક્ષર પ્રદર્શિત કરતું નથી મેમ ડિફૉલ્ટ રૂપરેખાંકનમાં:

મૂળભૂત રીતે, xterm ક્લાસિક "નિશ્ચિત" ફોન્ટનો ઉપયોગ કરે છે, જે મુજબ હજુ પણ એ જ વિકી, "1997 થી નોંધપાત્ર યુનિકોડ કવરેજ" ધરાવે છે. આ ફોન્ટમાં કંઈક એવું થઈ રહ્યું છે જેના કારણે અક્ષર ખાલી ફ્રેમ તરીકે દેખાય છે અને જ્યારે ટેક્સ્ટ ફોન્ટને 20+ પોઈન્ટ સુધી વધારવામાં આવે છે ત્યારે જ કેરેક્ટર આખરે યોગ્ય રીતે પ્રદર્શિત થવા લાગે છે. જો કે, આ "ફિક્સ" અન્ય યુનિકોડ અક્ષરોના પ્રદર્શનને તોડે છે:

આ સ્ક્રીનશૉટ્સ Fedora 27 માં લેવામાં આવ્યા હતા, કારણ કે તે ડેબિયન 9 કરતાં વધુ સારા પરિણામો આપે છે, જ્યાં ટર્મિનલ્સના કેટલાક જૂના સંસ્કરણો (ખાસ કરીને mlterm) ફોન્ટ્સને યોગ્ય રીતે હેન્ડલ કરી શકતા નથી. સદભાગ્યે આ પછીના સંસ્કરણોમાં સુધારેલ હતું.

હવે ધ્યાન રાખો કે xterm માં લીટી કેવી રીતે પ્રદર્શિત થાય છે. તે તારણ આપે છે કે પ્રતીક મેમ અને નીચેના સેમિટિક કોફ RTL શૈલી સ્ક્રિપ્ટ્સ નો સંદર્ભ લો (જમણે-થી-ડાબે), તેથી તકનીકી રીતે તેઓ જમણેથી ડાબે દર્શાવવા જોઈએ. ફાયરફોક્સ 57 જેવા વેબ બ્રાઉઝર્સ ઉપરોક્ત લીટીને યોગ્ય રીતે હેન્ડલ કરે છે. RTL ટેક્સ્ટનું સરળ સંસ્કરણ શબ્દ છે "Сара" હીબ્રુમાં (શરાહ). દ્વિપક્ષીય ગ્રંથો પર વિકી પૃષ્ઠ નીચેના કહે છે:

“ઘણા કોમ્પ્યુટર પ્રોગ્રામ દ્વિપક્ષીય ટેક્સ્ટને યોગ્ય રીતે પ્રદર્શિત કરી શકતા નથી. ઉદાહરણ તરીકે, હીબ્રુ નામ "સારાહ" માં અક્ષરો sin (ש) (જે જમણી બાજુએ દેખાય છે), પછી resh (ר) અને છેલ્લે he (ה) (જે ડાબી બાજુએ દેખાવા જોઈએ)નો સમાવેશ થાય છે."

ઘણા ટર્મિનલ્સ આ પરીક્ષણમાં નિષ્ફળ જાય છે: અલાક્રિટી, VTE-વ્યુત્પાદિત જીનોમ અને XFCE ટર્મિનલ્સ, urxvt, st અને xterm વિપરીત ક્રમમાં "સારા" પ્રદર્શિત કરે છે, જાણે કે આપણે નામ "અરાસ" તરીકે લખ્યું હોય.

દ્વિપક્ષીય લખાણોની બીજી સમસ્યા એ છે કે તેમને કોઈક રીતે સંરેખિત કરવાની જરૂર છે, ખાસ કરીને જ્યારે તે RTL અને LTR ટેક્સ્ટને મિશ્રિત કરવાની વાત આવે છે. RTL સ્ક્રિપ્ટો ટર્મિનલ વિન્ડોની જમણી બાજુથી ચાલવી જોઈએ, પરંતુ LTR અંગ્રેજીમાં ડિફોલ્ટ હોય તેવા ટર્મિનલ્સ માટે શું થવું જોઈએ? તેમાંના મોટા ભાગના પાસે કોઈ ખાસ મિકેનિઝમ નથી અને તમામ ટેક્સ્ટને ડાબી બાજુએ સંરેખિત કરો (કોન્સોલમાં સહિત). અપવાદો pterm અને mlterm છે, જે ધોરણોનું પાલન કરે છે અને આવી રેખાઓને જમણે-સંરેખિત કરે છે.

નિવેશ રક્ષણ

મેં ઓળખી છે તે આગલી નિર્ણાયક સુવિધા એ એન્ટિ-ઇન્સર્શન પ્રોટેક્શન છે. જો કે તે વ્યાપકપણે જાણીતું છે કે આના જેવા જોડણીઓ:

$ curl http://example.com/ | sh

કોડ એક્ઝેક્યુશન પુશ કમાન્ડ છે, થોડા લોકો જાણે છે કે વેબ બ્રાઉઝરમાંથી કોપી અને પેસ્ટ કરતી વખતે છુપાયેલા કમાન્ડ્સ કન્સોલમાં ઘૂસી શકે છે, સાવચેતીપૂર્વક તપાસ કર્યા પછી પણ. ચકાસણી સાઇટ Gianna Horna તેજસ્વી રીતે બતાવે છે કે આદેશ કેટલો નિર્દોષ દેખાતો છે:

git clone git: //git.kernel.org/pub/scm/utils/kup/kup.git

જ્યારે હોર્નની વેબસાઈટ પરથી ટર્મિનલમાં પેસ્ટ કરવામાં આવે ત્યારે આવા ઉપદ્રવમાં ફેરવાય છે:

git clone /dev/null;
    clear;
	echo -n "Hello ";
	whoami|tr -d 'n';
	echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust! 
	Here'"'"'s the first line of your /etc/passwd: ';
	head -n1 /etc/passwd
	git clone git://git.kernel.org/pub/scm/utils/kup/kup.git

તે કેવી રીતે કામ કરે છે? દૂષિત કોડ બ્લોકમાં શામેલ છે , જે CSS નો ઉપયોગ કરીને વપરાશકર્તાના દૃશ્યની બહાર ખસેડવામાં આવે છે.

બ્રેકેટેડ પેસ્ટ મોડ સ્પષ્ટપણે આવા હુમલાઓને બેઅસર કરવા માટે રચાયેલ છે. આ મોડમાં, ટર્મિનલ્સ શેલને ટેક્સ્ટના મૂળ વિશે જણાવવા માટે પેસ્ટ કરેલા ટેક્સ્ટને વિશિષ્ટ એસ્કેપ સિક્વન્સની જોડીમાં બંધ કરે છે. આ શેલને કહે છે કે તે પેસ્ટ કરેલા ટેક્સ્ટમાં સમાવિષ્ટ વિશિષ્ટ અક્ષરોને અવગણી શકે છે. આદરણીય xterm પર પાછા આવેલા તમામ ટર્મિનલ્સ આ સુવિધાને સમર્થન આપે છે, પરંતુ બ્રેકેટેડ મોડમાં પેસ્ટ કરવા માટે ટર્મિનલ પર ચાલતા શેલ અથવા એપ્લિકેશનના સમર્થનની જરૂર છે. ઉદાહરણ તરીકે, સોફ્ટવેરનો ઉપયોગ જીએનયુ રીડલાઇન (સમાન બાશ), ફાઇલની જરૂર છે ~/.inputrc:

set enable-bracketed-paste on

કમનસીબે, હોર્નની ટેસ્ટ સાઇટ એ પણ બતાવે છે કે કેવી રીતે ટેક્સ્ટ ફોર્મેટિંગ દ્વારા આ સુરક્ષાને બાયપાસ કરવી અને અકાળે તેના પર બ્રેકેટેડ મોડ લાગુ કરવાનું સમાપ્ત થાય છે. આ કામ કરે છે કારણ કે કેટલાક ટર્મિનલ્સ તેમના પોતાના ઉમેરતા પહેલા એસ્કેપ સિક્વન્સને યોગ્ય રીતે ફિલ્ટર કરતા નથી. ઉદાહરણ તરીકે, મારામાં હું ક્યારેય યોગ્ય રૂપરેખાંકન સાથે પણ કોન્સોલ પરીક્ષણો સફળતાપૂર્વક પૂર્ણ કરી શક્યો ન હતો. .inputrc ફાઇલ આનો અર્થ એ છે કે તમે અસમર્થિત એપ્લિકેશન અથવા ખોટી રીતે રૂપરેખાંકિત શેલને કારણે તમારી સિસ્ટમ રૂપરેખાંકન સરળતાથી બગડી શકો છો. આ ખાસ કરીને ખતરનાક છે જ્યારે રિમોટ સર્વર્સમાં લૉગ ઇન કરો, જ્યાં સાવચેતીપૂર્વક ગોઠવણીનું કામ ઓછું સામાન્ય છે, ખાસ કરીને જો તમારી પાસે આવા ઘણા રિમોટ મશીનો હોય.

આ સમસ્યાનો સારો ઉકેલ એ ટર્મિનલ માટે પેસ્ટ કન્ફર્મેશન પ્લગઇન છે urxvt, જે ફક્ત નવી લાઇન ધરાવતી કોઈપણ ટેક્સ્ટ દાખલ કરવાની પરવાનગી માંગે છે. મને હોર્ન દ્વારા વર્ણવેલ ટેક્સ્ટ હુમલા માટે વધુ સુરક્ષિત વિકલ્પ મળ્યો નથી.

ટૅબ્સ અને પ્રોફાઇલ્સ

અત્યારે એક લોકપ્રિય લક્ષણ એ ટેબ કરેલ ઈન્ટરફેસ માટે સપોર્ટ છે, જેને આપણે એક ટર્મિનલ વિન્ડો તરીકે વ્યાખ્યાયિત કરીશું જેમાં અન્ય ઘણા ટર્મિનલ્સ છે. આ કાર્ય વિવિધ ટર્મિનલ્સ માટે અલગ છે, અને તેમ છતાં પરંપરાગત xterm ટર્મિનલ્સ ટેબ્સને બિલકુલ સમર્થન આપતા નથી, વધુ આધુનિક ટર્મિનલ અવતાર જેમ કે Xfce ટર્મિનલ, જીનોમ ટર્મિનલ અને કોન્સોલ પાસે આ કાર્ય છે. Urxvt ટેબ્સને પણ સપોર્ટ કરે છે, પરંતુ જો તમે પ્લગઇનનો ઉપયોગ કરો તો જ. પરંતુ ટેબ સપોર્ટના સંદર્ભમાં જ, ટર્મિનેટર એ નિર્વિવાદ લીડર છે: તે માત્ર ટેબને જ સપોર્ટ કરતું નથી, પણ કોઈપણ ક્રમમાં ટર્મિનલ ગોઠવી શકે છે (નીચેની છબી જુઓ).

ટર્મિનેટરની બીજી વિશેષતા એ આ ટેબ્સને એકસાથે "ગ્રૂપ" કરવાની ક્ષમતા છે અને એક જ સમયે બહુવિધ ટર્મિનલ્સ પર સમાન કીસ્ટ્રોક મોકલવાની ક્ષમતા છે, જે એકસાથે બહુવિધ સર્વર પર બલ્ક ઑપરેશન કરવા માટે એક ક્રૂડ ટૂલ પ્રદાન કરે છે. સમાન સુવિધા કોન્સોલમાં પણ લાગુ કરવામાં આવી છે. અન્ય ટર્મિનલ્સમાં આ સુવિધાનો ઉપયોગ કરવા માટે, તમારે તૃતીય-પક્ષ સૉફ્ટવેરનો ઉપયોગ કરવો આવશ્યક છે જેમ કે ક્લસ્ટર SSH, xlax અથવા tmux.

જ્યારે પ્રોફાઇલ્સ સાથે જોડવામાં આવે ત્યારે ટેબ્સ ખાસ કરીને સારી રીતે કાર્ય કરે છે: ઉદાહરણ તરીકે, તમારી પાસે ઇમેઇલ માટે એક ટેબ, ચેટ માટે બીજું, વગેરે હોઈ શકે છે. આ કોન્સોલ ટર્મિનલ અને જીનોમ ટર્મિનલ દ્વારા સારી રીતે સપોર્ટેડ છે. બંને દરેક ટેબને તેની પોતાની પ્રોફાઇલ આપમેળે લોંચ કરવાની મંજૂરી આપે છે. ટર્મિનેટર પ્રોફાઇલ્સને પણ સપોર્ટ કરે છે, પરંતુ જ્યારે તમે ચોક્કસ ટેબ ખોલો છો ત્યારે મને અમુક પ્રોગ્રામ્સ આપમેળે લોંચ કરવાની રીત મળી નથી. અન્ય ટર્મિનલ્સમાં "પ્રોફાઇલ" નો ખ્યાલ બિલકુલ નથી.

રફલ્સ

છેલ્લી વસ્તુ જે હું આ લેખના પહેલા ભાગમાં આવરી લઈશ તે છે ટર્મિનલ્સનો દેખાવ. ઉદાહરણ તરીકે GNOME, Xfce અને urxvt પારદર્શિતાને સમર્થન આપે છે, પરંતુ તાજેતરમાં બેકગ્રાઉન્ડ ઇમેજ માટે સપોર્ટ છોડી દીધો છે, જેના કારણે કેટલાક વપરાશકર્તાઓને ટર્મિનલ પર સ્વિચ કરવાની ફરજ પડી છે. તિલિક્સ. અંગત રીતે, હું તેનાથી ખુશ છું અને તે સરળ છે ક્ષણો, જે urxvt માટે પૃષ્ઠભૂમિ રંગોનો આધાર સેટ કરે છે. જો કે, બિન-માનક રંગ થીમ્સ પણ સમસ્યાઓ ઊભી કરી શકે છે. દાખ્લા તરીકે, સોલાઇઝ્ડ કામ કરતું નથી એપ્લિકેશન્સ સાથે હૉટ и આઈપીટ્રાફ, કારણ કે તેઓ પહેલેથી જ તેમના પોતાના રંગોનો ઉપયોગ કરે છે.

મૂળ VT100 ટર્મિનલ રંગોને ટેકો આપતા ન હતા, અને નવા ઘણીવાર 256-રંગ પેલેટ સુધી મર્યાદિત હતા. અદ્યતન વપરાશકર્તાઓ કે જેઓ તેમના ટર્મિનલ્સ, શેલ પ્રોમ્પ્ટ્સ અથવા સ્ટેટસ બારને જટિલ રીતે સ્ટાઇલ કરે છે તેમના માટે હેરાન મર્યાદા હોઈ શકે છે. જાણવું કયા ટર્મિનલમાં "ટ્રુ કલર" સપોર્ટ છે તે ટ્રેક કરે છે. મારા પરીક્ષણો પુષ્ટિ કરે છે કે st, Alacritty અને VTE-આધારિત ટર્મિનલ્સ ટ્રુ કલરને સંપૂર્ણ રીતે સપોર્ટ કરે છે. અન્ય ટર્મિનલ્સ આ સંદર્ભમાં ખૂબ સારી રીતે ભાડે આપતા નથી અને હકીકતમાં, 256 રંગો પણ દર્શાવતા નથી. નીચે તમે GNOME ટર્મિનલ્સ, st અને xterm માં ટ્રુ કલર સપોર્ટ વચ્ચેનો તફાવત જોઈ શકો છો, જે તેમની 256 કલર પેલેટ અને urxvt સાથે આનું સારું કામ કરે છે, જે માત્ર ટેસ્ટમાં નિષ્ફળ જ નથી, પરંતુ તેના બદલે કેટલાક ઝબકતા અક્ષરો પણ દર્શાવે છે.

કેટલાક ટર્મિનલ્સ લિંક્સને ક્લિક કરવા યોગ્ય બનાવવા માટે URL પેટર્ન માટે ટેક્સ્ટનું વિશ્લેષણ પણ કરે છે. આ તમામ VTE-પ્રાપ્ત ટર્મિનલ્સ પર લાગુ થાય છે, જ્યારે urxvt ને એક વિશિષ્ટ પ્લગઇનની જરૂર છે જે એક ક્લિક પર અથવા કીબોર્ડ શોર્ટકટનો ઉપયોગ કરીને URL ને રૂપાંતરિત કરે. અન્ય ટર્મિનલ્સ મેં અન્ય રીતે ડિસ્પ્લે URL નું પરીક્ષણ કર્યું છે.

છેલ્લે, ટર્મિનલ્સમાં એક નવો ટ્રેન્ડ એ સ્ક્રોલ બફરની વૈકલ્પિકતા છે. ઉદાહરણ તરીકે, st પાસે કોઈ સ્ક્રોલ બફર નથી; એવું માનવામાં આવે છે કે વપરાશકર્તા ટર્મિનલ મલ્ટિપ્લેક્સરનો ઉપયોગ કરશે જેમ કે tmux અને જીએનયુ સ્ક્રીન.

અલાક્રિટીમાં બેકસ્ક્રોલ બફરનો પણ અભાવ છે, પરંતુ ટૂંક સમયમાં ઉમેરવામાં આવશે વપરાશકર્તાઓ તરફથી આ વિષય પર "વ્યાપક પ્રતિસાદ" ને કારણે તેનું સમર્થન. આ અપસ્ટાર્ટ્સ સિવાય, દરેક ટર્મિનલ જે મેં પરીક્ષણ કર્યું છે કે હું રિવર્સ સ્ક્રોલિંગને સપોર્ટ કરે છે તે શોધી શકું છું.

પેટાટોટલ

સામગ્રીના બીજા ભાગમાં (મૂળમાં આ બે અલગ અલગ લેખો હતા - આશરે. લેન) અમે પ્રદર્શન, મેમરી વપરાશ અને લેટન્સીની સરખામણી કરીશું. પરંતુ આપણે પહેલેથી જ જોઈ શકીએ છીએ કે પ્રશ્નમાં કેટલાક ટર્મિનલ્સમાં ગંભીર ખામીઓ છે. ઉદાહરણ તરીકે, જે વપરાશકર્તાઓ નિયમિતપણે RTL સ્ક્રિપ્ટ્સ સાથે કામ કરે છે તેઓ mlterm અને pterm ધ્યાનમાં લેવા માંગે છે, કારણ કે તેઓ અન્ય કરતાં સમાન કાર્યોને વધુ સારી રીતે સંભાળે છે. કોન્સોલે પણ સારું પ્રદર્શન કર્યું. જે વપરાશકર્તાઓ RTL સ્ક્રિપ્ટ સાથે કામ કરતા નથી તેઓ કંઈક બીજું પસંદ કરી શકે છે.

દૂષિત કોડ નિવેશ સામે રક્ષણના સંદર્ભમાં, urxvt તેના આ પ્રકારના હુમલા સામે રક્ષણના વિશેષ અમલીકરણને કારણે અલગ છે, જે મને ચોક્કસપણે અનુકૂળ લાગે છે. જેઓ ઘંટ અને સીટીઓ શોધી રહ્યા છે તેમના માટે કોન્સોલ જોવા યોગ્ય છે. છેલ્લે, એ નોંધવું યોગ્ય છે કે VTE એ ટર્મિનલ્સ માટે ઉત્તમ આધાર છે, જે રંગ આધાર, URL ઓળખ વગેરેની ખાતરી આપે છે. પ્રથમ નજરમાં, ડિફોલ્ટ ટર્મિનલ કે જે તમારા મનપસંદ પર્યાવરણ સાથે આવે છે તે બધી આવશ્યકતાઓને પૂર્ણ કરી શકે છે, પરંતુ ચાલો આ પ્રશ્નને જ્યાં સુધી અમે પ્રદર્શન સમજીએ નહીં ત્યાં સુધી ખુલ્લો છોડીએ.

ચાલો વાતચીત ચાલુ રાખીએ

સામાન્ય રીતે, ટર્મિનલ્સનું પ્રદર્શન પોતે જ દૂરની સમસ્યા જેવું લાગે છે, પરંતુ તે બહાર આવ્યું તેમ, તેમાંના કેટલાક આવા મૂળભૂત પ્રકારનાં સૉફ્ટવેર માટે આશ્ચર્યજનક રીતે ઉચ્ચ વિલંબતા દર્શાવે છે. આગળ પણ આપણે પરંપરાગત રીતે જેને "સ્પીડ" કહેવામાં આવે છે તે જોઈશું (હકીકતમાં, આ સ્ક્રોલિંગ સ્પીડ છે) અને ટર્મિનલની મેમરી વપરાશ (એ ચેતવણી સાથે કે આ દાયકાઓ પહેલાની જેમ આજે એટલું જટિલ નથી).

વિલંબ

ટર્મિનલ કામગીરીના સંપૂર્ણ અભ્યાસ પછી, હું નિષ્કર્ષ પર આવ્યો છું કે આ સંદર્ભમાં સૌથી મહત્વપૂર્ણ પરિમાણ લેટન્સી (પિંગ) છે. તેમના લેખમાં "અમે આનંદ સાથે છાપીએ છીએ" પાવેલ ફેટિને વિવિધ ટેક્સ્ટ એડિટર્સની લેટન્સી પર ધ્યાન આપ્યું અને સંકેત આપ્યો કે આ સંદર્ભમાં ટર્મિનલ્સ સૌથી ઝડપી ટેક્સ્ટ એડિટર્સ કરતાં ધીમા હોઈ શકે છે. તે આ સંકેત હતો જેણે આખરે મને મારા પોતાના પરીક્ષણો ચલાવવા અને આ લેખ લખવા તરફ દોરી.

પરંતુ વિલંબ શું છે અને તે શા માટે એટલું મહત્વનું છે? તેમના લેખમાં, ફેટિને તેને "કી દબાવવા અને અનુરૂપ સ્ક્રીન અપડેટ વચ્ચેનો વિલંબ" તરીકે વ્યાખ્યાયિત કર્યો અને ટાંક્યું "માનવ-કમ્પ્યુટર ક્રિયાપ્રતિક્રિયા માટે માર્ગદર્શિકા", જે જણાવે છે: "કોમ્પ્યુટર ડિસ્પ્લે પર દ્રશ્ય પ્રતિસાદમાં વિલંબ એ ટાઈપિસ્ટના વર્તન અને સંતોષ પર મહત્વપૂર્ણ અસર કરે છે."

ફેટિન સમજાવે છે કે આ પિંગ માત્ર સંતોષ કરતાં વધુ ઊંડા પરિણામો ધરાવે છે: "ટાઈપિંગ ધીમું થાય છે, વધુ ભૂલો થાય છે, અને આંખ અને સ્નાયુઓમાં તણાવ વધે છે." બીજા શબ્દોમાં કહીએ તો, મોટા વિલંબથી ટાઈપો થઈ શકે છે અને કોડની ગુણવત્તા પણ ઓછી થઈ શકે છે, કારણ કે તે મગજ પર વધારાના જ્ઞાનાત્મક ભાર તરફ દોરી જાય છે. પરંતુ સૌથી ખરાબ બાબત એ છે કે પિંગ "આંખ અને સ્નાયુઓના તાણને વધારે છે," જે સૂચવે છે વ્યવસાયિક ઇજાઓનો વિકાસ ભવિષ્યમાં (દેખીતી રીતે, લેખકનો અર્થ આંખો, પીઠ, હાથ અને, અલબત્ત, દ્રષ્ટિના સ્નાયુઓની સમસ્યાઓ છે - આશરે. લેન) પુનરાવર્તિત તણાવને કારણે.

આમાંની કેટલીક અસરો લાંબા સમયથી જાણીતી છે, અને પરિણામો સંશોધન, 1976 માં અર્ગનોમિક્સ જર્નલમાં પ્રકાશિત થયું હતું, જણાવ્યું હતું કે 100 મિલિસેકન્ડનો વિલંબ "નોંધપાત્ર રીતે ટાઇપિંગ ઝડપને નબળી પાડે છે." તાજેતરમાં જ, જીનોમ વપરાશકર્તા માર્ગદર્શિકા રજૂ કરવામાં આવી છે સ્વીકાર્ય પ્રતિભાવ સમય 10 મિલીસેકંડમાં, અને જો તમે આગળ જાઓ, તો પછી માઈક્રોસોફ્ટ સંશોધન બતાવે છે કે 1 મિલીસેકન્ડ આદર્શ છે.

ફેટિને ટેક્સ્ટ એડિટર્સ પર તેના પરીક્ષણો હાથ ધર્યા; તેણે એક પોર્ટેબલ ઇન્સ્ટ્રુમેન્ટ બનાવ્યું જેનું નામ છે ટાઇપોમીટર, જેનો ઉપયોગ હું ટર્મિનલ એમ્યુલેટરમાં પિંગનું પરીક્ષણ કરવા માટે કરું છું. ધ્યાનમાં રાખો કે પરીક્ષણ સિમ્યુલેશન મોડમાં હાથ ધરવામાં આવ્યું હતું: વાસ્તવમાં, અમારે ઇનપુટ (કીબોર્ડ, યુએસબી કંટ્રોલર, વગેરે) અને આઉટપુટ (વિડિયો કાર્ડ બફર, મોનિટર) લેટન્સી બંનેને ધ્યાનમાં લેવાની જરૂર છે. ફેટિન અનુસાર, લાક્ષણિક રૂપરેખાંકનોમાં તે લગભગ 20 એમએસ છે. જો તમારી પાસે ગેમિંગ સાધનો છે, તો તમે માત્ર 3 મિલીસેકન્ડમાં આ આંકડો હાંસલ કરી શકો છો. અમારી પાસે પહેલાથી જ આવા ઝડપી હાર્ડવેર હોવાથી, એપ્લિકેશનને તેની પોતાની લેટન્સી ઉમેરવાની જરૂર નથી. ફેટીનનો ધ્યેય એપ્લીકેશન લેટન્સીને 1 મિલીસેકન્ડ સુધી લાવવાનો છે અથવા તો ડાયલ કર્યા વિના પણ માપી શકાય તેવો વિલંબકેવી રીતે ઇન્ટેલલીજે આઈડીઆઈએ એક્સએન્યુએમએક્સ.

મારો પ્રયોગ તેના પરીક્ષણો સાથે સંમત છે તે બતાવવા માટે અહીં મારા માપના પરિણામો, તેમજ ફેટિનના કેટલાક પરિણામો છે:

xterm અને mlterm જેવા જૂના પ્રોગ્રામનો બહેતર રિસ્પોન્સ ટાઈમ એ મને સૌથી પહેલી વસ્તુ જે ત્રાટકી હતી. સૌથી ખરાબ રજિસ્ટર લેટન્સી (2,4 ms) સાથે, તેઓએ સૌથી ઝડપી આધુનિક ટર્મિનલ (ST માટે 10,6 ms) કરતાં વધુ સારું પ્રદર્શન કર્યું. કોઈપણ આધુનિક ટર્મિનલ 10 મિલીસેકન્ડ થ્રેશોલ્ડથી નીચે આવતું નથી. ખાસ કરીને, એલેક્રિટી "સૌથી ઝડપી ટર્મિનલ ઇમ્યુલેટર ઉપલબ્ધ" દાવાને પહોંચી વળવામાં નિષ્ફળ જાય છે, જો કે 2017માં તેની પ્રથમ સમીક્ષા પછી તેના સ્કોર્સમાં સુધારો થયો છે. ખરેખર, પ્રોજેક્ટના લેખકો પરિસ્થિતિથી વાકેફ છે અને ડિસ્પ્લે સુધારવા માટે કામ કરી રહ્યા છે. એ પણ નોંધવું જોઈએ કે GTK3 નો ઉપયોગ કરીને Vim એ તેના GTK2 સમકક્ષ કરતાં ધીમી તીવ્રતાનો ઓર્ડર છે. આના પરથી આપણે નિષ્કર્ષ પર આવી શકીએ કે GTK3 વધારાની લેટન્સી બનાવે છે, અને આ અન્ય તમામ ટર્મિનલ્સમાં પ્રતિબિંબિત થાય છે જે તેનો ઉપયોગ કરે છે (ટર્મિનેટર, Xfce4 ટર્મિનલ અને જીનોમ ટર્મિનલ).

જો કે, તફાવતો આંખ માટે ધ્યાનપાત્ર ન હોઈ શકે. ફેટિન સમજાવે છે તેમ, "તમારા પર તેની અસર થાય તે માટે તમારે વિલંબ વિશે જાગૃત રહેવાની જરૂર નથી." ફેટીન પ્રમાણભૂત વિચલન વિશે પણ ચેતવણી આપે છે: "લેટન્સી (જીટર) માં કોઈપણ વિક્ષેપ તેમની અણધારીતાને કારણે વધારાનો તણાવ પેદા કરે છે."

ઉપરનો ગ્રાફ શુદ્ધ ડેબિયન 9 (ખેંચ) પર લેવામાં આવ્યો છે i3 વિન્ડો મેનેજર. આ વાતાવરણ લેટન્સી ટેસ્ટમાં શ્રેષ્ઠ પરિણામો આપે છે. તે બહાર આવ્યું તેમ, જીનોમ તમામ માપન માટે વધારાના 20 ms પિંગ બનાવે છે. આ માટે સંભવિત સમજૂતી એ ઇનપુટ ઇવેન્ટ્સની સિંક્રનસ પ્રોસેસિંગ સાથેના પ્રોગ્રામ્સની હાજરી છે. ફેટીન આવા કેસ માટે એક ઉદાહરણ આપે છે વર્ક્રેવ, જે તમામ ઇનપુટ ઇવેન્ટ્સને સિંક્રનસ રીતે પ્રક્રિયા કરીને વિલંબ ઉમેરે છે. મૂળભૂત રીતે, જીનોમ વિન્ડો મેનેજર સાથે પણ આવે છે મટર, જે બફરિંગનું વધારાનું સ્તર બનાવે છે, જે પિંગને અસર કરે છે અને ઓછામાં ઓછી 8 મિલીસેકન્ડની લેટન્સી ઉમેરે છે.

સ્ક્રોલ ઝડપ

આગળની કસોટી એ પરંપરાગત "સ્પીડ" અથવા "બેન્ડવિડ્થ" પરીક્ષણ છે, જે સ્ક્રીન પર મોટી માત્રામાં ટેક્સ્ટ દર્શાવતી વખતે ટર્મિનલ પૃષ્ઠને કેટલી ઝડપથી સ્ક્રોલ કરી શકે છે તે માપે છે. પરીક્ષણની મિકેનિક્સ અલગ અલગ હોય છે; મૂળ પરીક્ષણ seq આદેશનો ઉપયોગ કરીને સમાન ટેક્સ્ટ સ્ટ્રિંગ બનાવવાનું હતું. અન્ય પરીક્ષણોમાં થોમસ ઇ. ડિકી (xterm જાળવણીકાર) પરીક્ષણનો સમાવેશ થાય છે, જે વારંવાર થાય છે terminfo.src ફાઈલ ડાઉનલોડ થયેલ છે. ટર્મિનલ કામગીરીની અન્ય સમીક્ષામાં ડેન લુ રેન્ડમ બાઇટ્સની બેઝ32 એન્કોડેડ સ્ટ્રિંગનો ઉપયોગ કરે છે, જે બિલાડીનો ઉપયોગ કરીને ટર્મિનલ પર આઉટપુટ કરે છે. લુઉ આવા પરીક્ષણને "કોઈ કલ્પના કરી શકે તેટલું નકામું માપદંડ" માને છે અને તેના બદલે પ્રાથમિક મેટ્રિક તરીકે ટર્મિનલ પ્રતિસાદનો ઉપયોગ કરવાનું સૂચન કરે છે. ડિકી પણ તેના ટેસ્ટને ભ્રામક ગણાવે છે. જો કે, બંને લેખકો સ્વીકારે છે કે ટર્મિનલ વિન્ડો બેન્ડવિડ્થ એક સમસ્યા હોઈ શકે છે. લુને મોટી ફાઇલો પ્રદર્શિત કરતી વખતે Emacs Eshell થીજી ગયેલું જણાયું, અને ડિકીએ xtrermની વિઝ્યુઅલ સુસ્તીથી છુટકારો મેળવવા માટે ટર્મિનલને ઑપ્ટિમાઇઝ કર્યું. તેથી આ પરીક્ષણમાં હજુ પણ કેટલીક યોગ્યતા છે, પરંતુ રેન્ડરીંગ પ્રક્રિયા ટર્મિનલથી ટર્મિનલ સુધી ખૂબ જ અલગ હોવાથી, અન્ય પરિમાણોને ચકાસવા માટે તેનો ટેસ્ટ ઘટક તરીકે પણ ઉપયોગ કરી શકાય છે.

અહીં આપણે સ્પર્ધાની આગળ rxvt અને st પુલ જોયે છે, ત્યારબાદ ઘણી નવી એલાક્રિટી છે, જે પ્રદર્શન પર ધ્યાન કેન્દ્રિત કરીને ડિઝાઇન કરવામાં આવી છે. આગળ Xfce (VTE કુટુંબ) અને Konsole છે, જે લગભગ બમણી ઝડપી છે. છેલ્લું xterm છે, જે rxvt કરતાં પાંચ ગણું ધીમું છે. પરીક્ષણ દરમિયાન, xterm એ પણ ઘણું લહેરી નાખ્યું, જેના કારણે ટેક્સ્ટ પસાર કરવું મુશ્કેલ બને છે, પછી ભલે તે સમાન લાઇન હોય. કોન્સોલ ઝડપી હતું, પરંતુ તે સમયે મુશ્કેલ હતું: ડિસ્પ્લે સમય સમય પર સ્થિર થઈ જશે, આંશિક ટેક્સ્ટ બતાવશે અથવા બિલકુલ બતાવશે નહીં. અન્ય ટર્મિનલ્સ સ્પષ્ટપણે સ્ટ્રિંગ્સ પ્રદર્શિત કરે છે, જેમાં st, Alacritty અને rxvt.

ડિકી સમજાવે છે કે પ્રદર્શન તફાવતો વિવિધ ટર્મિનલ્સમાં સ્ક્રોલ બફરની ડિઝાઇનને કારણે છે. ખાસ કરીને, તે rxvt અને અન્ય ટર્મિનલ્સ પર "સામાન્ય નિયમોનું પાલન ન કરવાનો" આરોપ મૂકે છે:

"xterm થી વિપરીત, rxvt એ તમામ અપડેટ્સ પ્રદર્શિત કરવાનો પ્રયાસ કર્યો નથી. જો તે પાછળ પડે છે, તો તે પકડવા માટે કેટલાક અપડેટ્સનો ઇનકાર કરશે. આંતરિક મેમરી ઓર્ગેનાઈઝેશન કરતાં સ્પષ્ટ સ્ક્રોલિંગ સ્પીડ પર આની વધુ અસર પડી હતી. એક ખામી એ હતી કે ASCII એનિમેશન કંઈક અંશે અસ્પષ્ટ હતું."

આ કથિત xterm સુસ્તીને ઠીક કરવા માટે, ડિકી સંસાધનનો ઉપયોગ કરવાનું સૂચન કરે છે ફાસ્ટસ્ક્રોલ, ફ્લો સાથે ચાલુ રાખવા માટે xterm ને કેટલાક સ્ક્રીન અપડેટ્સ કાઢી નાખવાની મંજૂરી આપે છે. મારા પરીક્ષણો પુષ્ટિ કરે છે કે ફાસ્ટસ્ક્રોલ કાર્યક્ષમતામાં સુધારો કરે છે અને xterm ને rxvt ની સમકક્ષ લાવે છે. જોકે, આ એકદમ રફ ક્રચ છે, જેમ કે ડિકી પોતે સમજાવે છે: "કેટલીકવાર xterm - જેમ કે કોન્સોલ - અટકી જતું હોય તેવું લાગે છે કારણ કે તે અમુકને દૂર કર્યા પછી સ્ક્રીન અપડેટ્સના નવા સેટની રાહ જુએ છે." આ નસમાં, એવું લાગે છે કે અન્ય ટર્મિનલ્સને ઝડપ અને પ્રદર્શન અખંડિતતા વચ્ચે શ્રેષ્ઠ સમાધાન મળ્યું છે.

સંસાધન વપરાશ

પર્ફોર્મન્સ મેટ્રિક તરીકે સ્ક્રોલ કરવાની ઝડપને ધ્યાનમાં લેવાનો અર્થ છે કે કેમ તે ધ્યાનમાં લીધા વિના, આ પરીક્ષણ અમને ટર્મિનલ્સ પરના ભારનું અનુકરણ કરવાની મંજૂરી આપે છે, જે બદલામાં અમને મેમરી અથવા ડિસ્ક વપરાશ જેવા અન્ય પરિમાણોને માપવા માટે પરવાનગી આપે છે. નિર્દિષ્ટ કસોટી ચલાવીને મેટ્રિક્સ મેળવવામાં આવ્યા હતા seq પાયથોન પ્રક્રિયા મોનીટરીંગ હેઠળ. તેણે મીટરનો ડેટા એકત્રિત કર્યો ગેટરુસેજ() માટે ru_maxrss, રકમ ru_oublock и ru_inblock અને એક સરળ ટાઈમર.

આ પરીક્ષણમાં, ST 8 MB ની સૌથી ઓછી સરેરાશ મેમરી વપરાશ સાથે પ્રથમ સ્થાન મેળવે છે, જે ડિઝાઇનનો મુખ્ય વિચાર સરળતા છે તે ધ્યાનમાં લેતા આશ્ચર્યજનક નથી. mlterm, xterm અને rxvt થોડો વધુ વપરાશ કરે છે - લગભગ 12 MB. અન્ય નોંધપાત્ર પરિણામ એલાક્રિટી છે, જેને ચલાવવા માટે 30 MB ની જરૂર છે. પછી ત્યાં 40 થી 60 MB સુધીના આંકડાઓ સાથે VTE પરિવારના ટર્મિનલ્સ છે, જે ઘણું બધું છે. આ વપરાશ એ હકીકત દ્વારા સમજાવી શકાય છે કે આ ટર્મિનલ્સ ઉચ્ચ-સ્તરની લાઇબ્રેરીઓનો ઉપયોગ કરે છે, ઉદાહરણ તરીકે, GTK. કોન્સોલ ટેસ્ટ દરમિયાન 65MB મેમરી વપરાશ સાથે છેલ્લે આવે છે, જો કે આ તેની ખૂબ જ વિશાળ શ્રેણીના લક્ષણો દ્વારા ન્યાયી ઠેરવી શકાય છે.

દસ વર્ષ પહેલાં મેળવેલા અગાઉના પરિણામોની તુલનામાં, બધા પ્રોગ્રામ્સ નોંધપાત્ર રીતે વધુ મેમરીનો વપરાશ કરવા લાગ્યા. Xterm ને 4 MB ની જરૂર પડતી હતી, પરંતુ હવે તેને સ્ટાર્ટઅપ સમયે 15 MB ની જરૂર પડે છે. rxvt માટે વપરાશમાં સમાન વધારો થયો છે, જેને હવે બોક્સની બહાર 16 MB ની જરૂર છે. Xfce ટર્મિનલ 34 MB લે છે, જે પહેલા કરતા ત્રણ ગણું મોટું છે, પરંતુ GNOME ટર્મિનલને માત્ર 20 MB ની જરૂર છે. અલબત્ત, અગાઉના તમામ પરીક્ષણો 32-બીટ આર્કિટેક્ચર પર હાથ ધરવામાં આવ્યા હતા. એલસીએ 2012 રસ્ટી રસેલ ખાતે કહ્યું, કે ત્યાં ઘણા વધુ સૂક્ષ્મ કારણો છે જે મેમરી વપરાશમાં વધારો સમજાવી શકે છે. એમ કહીને, અમે હવે એવા સમયમાં જીવીએ છીએ જ્યાં અમારી પાસે ગીગાબાઇટ્સ મેમરી છે, તેથી અમે કોઈક રીતે મેનેજ કરીશું.

જો કે, હું મદદ કરી શકતો નથી પરંતુ અનુભવી શકું છું કે ટર્મિનલ જેવી મૂળભૂત વસ્તુને વધુ મેમરી ફાળવવી એ સંસાધનોનો બગાડ છે. આ પ્રોગ્રામ્સ સૌથી નાનામાં નાનામાં નાના હોવા જોઈએ, કોઈપણ "બોક્સ" પર ચલાવવા માટે સક્ષમ હોવા જોઈએ, શૂબોક્સ પણ, જો આપણે ક્યારેય એવા મુદ્દા પર આવીએ કે જ્યાં તેમને લિનક્સ સિસ્ટમ્સથી સજ્જ કરવાની જરૂર હોય (અને તમે જાણો છો કે તે આવું હશે. ). પરંતુ આ સંખ્યાઓ સાથે, થોડા હળવા અને સૌથી મર્યાદિત ક્ષમતાઓ સિવાયના બહુવિધ ટર્મિનલ્સ ચલાવતા કોઈપણ વાતાવરણમાં ભવિષ્યમાં મેમરીનો ઉપયોગ એક સમસ્યા બની જશે. આની ભરપાઈ કરવા માટે, જીનોમ ટર્મિનલ, કોન્સોલ, urxvt, ટર્મિનેટર અને Xfce ટર્મિનલ પાસે ડિમન મોડ છે જે તમને એક પ્રક્રિયા દ્વારા બહુવિધ ટર્મિનલ્સને નિયંત્રિત કરવા માટે પરવાનગી આપે છે, તેમની મેમરી વપરાશને મર્યાદિત કરે છે.

મારા પરીક્ષણો દરમિયાન, હું ડિસ્ક રીડ-રાઇટ સંબંધિત અન્ય અણધારી પરિણામ પર આવ્યો: મને અહીં કંઈપણ જોવાની અપેક્ષા નથી, પરંતુ તે બહાર આવ્યું છે કે કેટલાક ટર્મિનલ્સ ડિસ્ક પર સૌથી વધુ વિશાળ ડેટા લખે છે. તેથી, VTE લાઇબ્રેરી ખરેખર ડિસ્ક પર સ્ક્રોલ બફર રાખે છે (આ સુવિધા 2010 માં જોવામાં આવ્યું હતું, અને આ હજુ પણ થઈ રહ્યું છે). પરંતુ જૂના અમલીકરણોથી વિપરીત, હવે ઓછામાં ઓછો આ ડેટા AES256 GCM નો ઉપયોગ કરીને એનક્રિપ્ટ થયેલ છે (આવૃત્તિ 0.39.2 થી). પરંતુ એક વાજબી પ્રશ્ન ઊભો થાય છે: VTE લાઇબ્રેરીમાં એવું શું ખાસ છે કે તેને અમલીકરણ માટે આવા બિન-માનક અભિગમની જરૂર છે...

નિષ્કર્ષ

લેખના પહેલા ભાગમાં, અમે જોયું કે VTE-આધારિત ટર્મિનલ્સમાં સુવિધાઓનો સારો સમૂહ છે, પરંતુ હવે આપણે જોઈએ છીએ કે આ કેટલાક પ્રદર્શન ખર્ચ સાથે આવે છે. હવે મેમરી એ કોઈ સમસ્યા નથી કારણ કે તમામ VTE ટર્મિનલ્સને ડિમન પ્રક્રિયા દ્વારા નિયંત્રિત કરી શકાય છે, જે તેમની ભૂખને મર્યાદિત કરે છે. જો કે, જૂની સિસ્ટમો કે જેઓ RAM અને કર્નલ બફરના જથ્થા પર ભૌતિક મર્યાદાઓ ધરાવે છે તેમને હજુ પણ ટર્મિનલ્સના પહેલાનાં સંસ્કરણોની જરૂર પડી શકે છે, કારણ કે તેઓ નોંધપાત્ર રીતે ઓછા સંસાધનોનો ઉપયોગ કરે છે. જો કે VTE ટર્મિનલ્સ થ્રુપુટ (સ્ક્રોલીંગ) પરીક્ષણોમાં સારું પ્રદર્શન કરે છે, તેમ છતાં તેમની ડિસ્પ્લે લેટન્સી જીનોમ યુઝર ગાઈડમાં સેટ થ્રેશોલ્ડ કરતા ઉપર છે. VTE વિકાસકર્તાઓએ કદાચ આને ધ્યાનમાં લેવું જોઈએ. જો આપણે ધ્યાનમાં લઈએ કે શિખાઉ Linux વપરાશકર્તાઓ માટે પણ ટર્મિનલનો સામનો કરવો અનિવાર્ય છે, તો તેઓ તેને વધુ વપરાશકર્તા મૈત્રીપૂર્ણ બનાવી શકે છે. અનુભવી ગીક્સ માટે, ડિફૉલ્ટ ટર્મિનલમાંથી સ્વિચ કરવાનો અર્થ એ પણ હોઈ શકે છે કે આંખની ઓછી તાણ અને લાંબા કાર્ય સત્રોને કારણે ભવિષ્યમાં કામ સંબંધિત ઇજાઓ અને બીમારીઓને ટાળવાની ક્ષમતા. કમનસીબે, માત્ર જૂના xterm અને mlterm જ અમને 10 મિલિસેકન્ડના મેજિક પિંગ થ્રેશોલ્ડ પર લાવે છે, જે ઘણા લોકો માટે અસ્વીકાર્ય છે.

બેન્ચમાર્ક માપન એ પણ દર્શાવે છે કે Linux ગ્રાફિકલ વાતાવરણના વિકાસને કારણે, વિકાસકર્તાઓએ સંખ્યાબંધ સમાધાનો કરવા પડ્યા હતા. કેટલાક વપરાશકર્તાઓ નિયમિત વિન્ડો મેનેજરને જોવા માંગે છે કારણ કે તેઓ નોંધપાત્ર પિંગ ઘટાડો પ્રદાન કરે છે. કમનસીબે, વેલેન્ડ માટે લેટન્સી માપવાનું શક્ય નહોતું: મેં ઉપયોગમાં લીધેલો ટાઇપોમીટર પ્રોગ્રામ એ માટે બનાવવામાં આવ્યો હતો કે જે વેલેન્ડને રોકવા માટે રચાયેલ છે: અન્ય વિન્ડો પર જાસૂસી. હું આશા રાખું છું કે વેલેન્ડ કમ્પોઝીટીંગ X.org કરતાં વધુ સારું પ્રદર્શન કરે છે, અને હું એ પણ આશા રાખું છું કે ભવિષ્યમાં કોઈને આ વાતાવરણમાં લેટન્સી માપવાનો માર્ગ મળશે.

સોર્સ: www.habr.com