زموږ د ژباړې بیورو څخه یو څو ټکي: معمولا هرڅوک هڅه کوي وروستي توکي او خپرونې وژباړي، او موږ استثنا نه یو. مګر ترمینل هغه څه ندي چې په اونۍ کې یو ځل تازه کیږي. له همدې امله ، موږ ستاسو لپاره د انټوین بیوپرې لخوا یوه مقاله ژباړلې ، چې د 2018 په پسرلي کې خپره شوې: سره له دې چې د عصري معیارونو لخوا د پام وړ "عمر" سره سره ، زموږ په نظر ، موادو خپل تړاو له لاسه نه دی ورکړی. برسېره پردې، دا په اصل کې د دوو مقالو لړۍ وه، مګر موږ پریکړه وکړه چې دوی په یوه لوی پوسټ کې یوځای کړو.
ټرمینلونه د کمپیوټر په تاریخ کې ځانګړی ځای لري، مګر په وروستیو لسیزو کې دوی اړ شوي چې د کمانډ لاین تر څنګ ژوندي پاتې شي ځکه چې ګرافیکي انٹرفیس هر ځای کیږي. خپل ځای پرځای کړل ، کوم چې په پایله کې د پنچ شوي کارتونو او توګل سویچونو پراساس د سیسټمونو ترمیم و. عصري توزیع د ټولو شکلونو او رنګونو مختلف ټرمینل ایمولیټرونو سره راځي. او پداسې حال کې چې ډیری یې د دوی د کاري چاپیریال لخوا چمتو شوي معیاري ټرمینل سره مینځپانګه لري ، ځینې یې په ویاړ سره د خپل غوره شیل یا متن مدیر چلولو لپاره مستقیم بهرني سافټویر کاروي. مګر، لکه څنګه چې موږ به د دې مقالې څخه وګورو، ټول ټرمینالونه په ورته عکس کې ندي رامینځته شوي: دوی په فعالیت، اندازې او فعالیت کې خورا توپیر لري.
ځینې ټرمینلونه د حیرانتیا وړ امنیت سوري لري، او ډیری یې د دندو یو بشپړ مختلف سیټ لري، د ټب شوي انٹرفیس لپاره د ملاتړ څخه تر سکریپټینګ پورې. که څه هم موږ ، دا مقاله د پخوانیو موادو تازه کول دي چې له لوستونکو سره به مرسته وکړي چې په 2018 کې کوم ټرمینل وکاروي. د مقالې لومړۍ نیمه ځانګړتیاوې پرتله کوي، او دویمه نیمه د فعالیت ارزونه کوي.
دلته هغه ټرمینلونه دي چې ما بیاکتنه کړې:
دا ممکن وروستي نسخې نه وي، ځکه چې زه د لیکلو په وخت کې په باثباته ودانیو پورې محدود وم، کوم چې ما د دې توان درلود چې په Debian 9 یا Fedora 27 کې رول ولوبوم. یوازینی استثنا د الاکریټي ده. دا د GPU ګړندۍ ټرمینلونو اولاد دی او د دې کار لپاره په غیر معمولي او نوې ژبه لیکل شوی - زنګ. ما د خپلې بیاکتنې څخه ویب ټرمینالونه لرې کړل (د هغو په شمول )، ځکه چې لومړنیو ازموینو د دوی خورا ضعیف فعالیت ښودلی.
د یونیکوډ ملاتړ
ما خپلې ازموینې د یونیکوډ ملاتړ سره پیل کړې. د ترمینلونو لومړۍ ازموینه د یونیکوډ تار ښکاره کول وو : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 и 말». Этот простой тест показывает, может ли терминал корректно работать по всему миру. Терминал xterm не отображает арабский символ په ډیفالټ ترتیب کې:
د ډیفالټ په واسطه، xterm کلاسیک "فکسډ" فونټ کاروي، کوم چې په وینا ، "له 1997 راهیسې د پام وړ یونیکوډ پوښښ لري". په دې فونټ کې یو څه روان دي چې د دې لامل کیږي چې کرکټر د خالي چوکاټ په توګه څرګند شي او دا یوازې هغه وخت دی چې د متن فونټ 20+ پوائنټونو ته لوړ شي چې کرکټر په پای کې په سمه توګه ښودل پیل کوي. په هرصورت، دا "فکس" د نورو یونیکوډ کرکټرونو ښودنه ماتوي:
دا سکرین شاټونه په فیډورا 27 کې اخیستل شوي، ځکه چې دا د Debian 9 په پرتله غوره پایلې ورکړې، چیرې چې د ټرمینالونو ځینې زاړه نسخې (په ځانګړې توګه mlterm) نشي کولی فونټونه په سمه توګه اداره کړي. خوشبختانه دا په وروستیو نسخو کې ټاکل شوی.
اوس وګورئ چې دا کرښه په xterm کې څنګه ښودل کیږي. دا معلومه شوه چې سمبول میم او لاندې سیمیټیک د RTL سټایل سکریپټونو ته مراجعه وکړئ ()، نو له تخنیکي پلوه دوی باید له ښیې څخه کیڼ ته وښودل شي. ویب براوزرونه لکه فایرفوکس 57 پورتنۍ کرښه په سمه توګه اداره کوي. د RTL متن یوه ساده نسخه کلمه ده "په عبراني (). لاندې وايي:
"ډیری کمپیوټر پروګرامونه نشي کولی دوه اړخیز متن په سمه توګه ښکاره کړي. د مثال په توګه، د عبراني نوم "سارا" د حروف sin (ש) (چې په ښي خوا کې ښکاري)، بیا ریش (ר) او په پای کې هغه (ה) (چې باید په ښي خوا کې ښکاره شي).
ډیری ټرمینلونه پدې ازموینه کې ناکام شوي: Alacritty، VTE څخه ترلاسه شوي Gnome او XFCE ټرمینالونه، urxvt، st او xterm "سارا" په برعکس ترتیب کې ښکاره کوي، لکه څنګه چې موږ د "اراس" نوم لیکلی وي.
د دوه اړخیز متنونو سره بله ستونزه دا ده چې دوی باید په یو ډول تنظیم شي ، په ځانګړي توګه کله چې د RTL او LTR متنونو مخلوط کولو خبره راځي. د RTL سکریپټ باید د ټرمینل کړکۍ له ښي اړخ څخه وګرځي، مګر د ټرمینلونو لپاره چې LTR انګلیسي ته ډیفالټ وي څه باید وشي؟ ډیری یې کوم ځانګړي میکانیزمونه نلري او ټول متن کیڼ اړخ ته تنظیموي (د کنسول په شمول). استثناوې pterm او mlterm دي، کوم چې معیارونو ته غاړه کیږدي او دا ډول لینونه په سمه توګه تنظیموي.
د ننوتلو محافظت
راتلونکی مهم خصوصیت چې ما پیژندلی دی د ننوتلو ضد محافظت دی. که څه هم دا په پراخه کچه پیژندل کیږي چې منتر لکه:
$ curl http://example.com/ | shد کوډ اجرا کولو فشار کمانډونه دي، لږ خلک پوهیږي چې پټ کمانډونه کولی شي کنسول ته ننوځي کله چې د ویب براوزر څخه کاپي او پیسټ کول حتی د محتاط تفتیش وروسته. په زړه پورې ښیي چې حکم څومره بې ګناه ښکاري:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitکله چې د هارن ویب پا fromې څخه ترمینل ته ځړول کیږي نو په داسې یو ناورین بدلیږي:
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 ټرمینل، GNOME ټرمینل او کنسول دا فعالیت لري. Urxvt د ټبونو ملاتړ هم کوي، مګر یوازې که تاسو پلگ ان کاروئ. مګر پخپله د ټب ملاتړ په شرایطو کې ، ټرمینیټر بې بنسټه مشر دی: دا نه یوازې د ټبونو ملاتړ کوي ، بلکه کولی شي په هر ترتیب کې ټرمینلونه تنظیم کړي (لاندې عکس وګورئ).
د ټرمینیټر بله ځانګړتیا د دې وړتیا ده چې دا ټبونه یوځای "ګروپ" کړي او ورته کیسټروکونه په ورته وخت کې څو ټرمینالونو ته واستوي، په ورته وخت کې په ډیری سرورونو کې د بلک عملیاتو ترسره کولو لپاره خام وسیله چمتو کوي. ورته ځانګړتیا په کنسول کې هم پلي کیږي. په نورو ترمینلونو کې د دې ځانګړتیا کارولو لپاره، تاسو باید د دریمې ډلې سافټویر وکاروئ لکه , او یا .
ټبونه په ځانګړې توګه ښه کار کوي کله چې د پروفایلونو سره جوړه شي: د مثال په توګه، تاسو کولی شئ یو ټب د بریښنالیک لپاره، بل د چیٹ لپاره، او داسې نور. دا د کنسول ټرمینل او ګینوم ټرمینل لخوا ښه ملاتړ کیږي. دواړه هر ټب ته اجازه ورکوي چې په اوتومات ډول خپل پروفایل پیل کړي. ټرمینټر هم د پروفایلونو ملاتړ کوي، مګر زه نشم موندلی چې په اتوماتيک ډول ځینې پروګرامونه پیل کړم کله چې تاسو یو ځانګړی ټب خلاص کړئ. نور ترمینلونه د "پروفایل" مفهوم نه لري.
رفلونه
وروستی شی چې زه به یې د دې مقالې په لومړۍ برخه کې پوښم د ترمینلونو ظاهري بڼه ده. د مثال په توګه GNOME، Xfce او urxvt د روڼتیا ملاتړ کوي، مګر پدې وروستیو کې د شالید انځورونو لپاره ملاتړ کم شوی، ځینې کاروونکي مجبوروي چې ترمینل ته لاړ شي. . په شخصي توګه، زه له دې څخه خوښ یم او دا ساده دی سرچینې، کوم چې د urxvt لپاره د شالید رنګونو اساس سیټ ټاکي. په هرصورت، غیر معیاري رنګ موضوعات هم ستونزې رامینځته کولی شي. د مثال په ډول، د غوښتنلیکونو سره и ځکه چې دوی لا دمخه خپل رنګونه کاروي.
د رنګونو ملاتړ نه کوي، او نوي اکثرا د 256 رنګ پیلټ پورې محدود وو. د پرمختللو کاروونکو لپاره چې خپل ټرمینلونه سټایل کوي ، شیل پرامپټونه یا حالت بارونه په پیچلي لارو کې کیدی شي یو ځورونکی محدودیت وي. تعقیبوي کوم ټرمینلونه د "ریښتیني رنګ" ملاتړ لري. زما ازموینې تاییدوي چې سټیټ، الاکریټي او VTE میشته ټرمینلونه د ریښتیني رنګ ملاتړ کوي. نور ټرمینلونه پدې برخه کې ډیر ښه کار نه کوي او په حقیقت کې حتی 256 رنګونه هم نه ښیې. لاندې تاسو کولی شئ د GNOME ترمینلونو کې د ریښتیني رنګ ملاتړ ترمینځ توپیر وګورئ ، st او xterm ، کوم چې د دوی د 256 رنګ پیلټ او urxvt سره پدې کې ښه دنده ترسره کوي ، کوم چې نه یوازې دا ازموینه ناکامه کوي ، بلکه حتی د دوی پرځای ځینې روښانه حروف ښیې.
ځینې ټرمینلونه د URL نمونو لپاره متن هم تحلیلوي ترڅو لینکونه د کلک کولو وړ کړي. دا په ټولو VTE ترلاسه شوي ترمینلونو باندې تطبیق کیږي، پداسې حال کې چې urxvt یو ځانګړي پلگ ان ته اړتیا لري چې URLs په یو کلیک یا د کیبورډ شارټ کټ په کارولو سره بدل کړي. نور ټرمینلونه ما په نورو لارو کې د ښودلو URLs ازموینه کړې.
په نهایت کې ، په ټرمینالونو کې نوی رجحان د سکرول بفر اختیار دی. د مثال په توګه، st د سکرول بفر نلري؛ داسې انګیرل کیږي چې کارونکي به د ټرمینل ملټي پلیکسر لکه tmux او .
الیکریټي د بیک سکرول بفرونه هم نلري ، مګر د کاروونکو لخوا پدې موضوع باندې د "پراخه فیډبیک" له امله د دې ملاتړ. د دې اپسټارټونو سربیره ، هر ټرمینل چې ما ازموینه کړې چې زه یې موندلی شم د ریورس سکرول ملاتړ کوي.
فرعي مجموعه
د موادو په دویمه برخه کې (په اصل کې دا دوه مختلف مقالې وې - نږدې. لین) موږ به فعالیت، د حافظې کارول او ځنډ پرتله کړو. مګر موږ دمخه لیدلی شو چې د پوښتنې ځینې ټرمینالونه جدي نیمګړتیاوې لري. د مثال په توګه، هغه کاروونکي چې په منظمه توګه د RTL سکریپټونو سره کار کوي ممکن د mlterm او term په اړه فکر وکړي، ځکه چې دوی د نورو په پرتله د ورته کارونو په سمبالولو کې غوره دي. کنسول هم ښه فعالیت وکړ. هغه کاروونکي چې د RTL سکریپټونو سره کار نه کوي ممکن بل څه غوره کړي.
د ناوړه کوډ داخلولو پروړاندې د محافظت شرایطو کې ، urxvt د دې ډول برید پروړاندې د محافظت ځانګړي پلي کولو له امله ولاړ دی ، کوم چې زما لپاره یقینا اسانه ښکاري. د هغو کسانو لپاره چې ځینې زنګونه او سیستونه لټوي، کنسول د یو نظر ارزښت لري. په نهایت کې ، دا د یادونې وړ ده چې VTE د ټرمینلونو لپاره عالي اډه ده ، کوم چې د رنګ ملاتړ ، URL پیژندنه او داسې نور تضمینوي. په لومړي نظر کې ، ډیفالټ ټرمینل چې ستاسو د خوښې چاپیریال سره راځي ممکن ټولې اړتیاوې پوره کړي ، مګر راځئ چې دا پوښتنه خلاص پریږدو تر هغه چې موږ په فعالیت پوه شو.
راځئ چې خبرو ته دوام ورکړو
په عموم کې ، پخپله د ټرمینلونو فعالیت ممکن د لرې پرتې ستونزې په څیر ښکاري ، مګر لکه څنګه چې دا وګرځي ، ځینې یې د داسې لومړني ډول سافټویر لپاره د حیرانتیا وړ لوړ ځنډ څرګندوي. همدارنګه وروسته به موږ هغه څه وګورو چې په دودیز ډول د "سرعت" په نوم یادیږي (په حقیقت کې دا د سکرول کولو سرعت دی) او د ټرمینل د حافظې مصرف (د احتیاط سره چې دا نن ورځ دومره مهم ندي لکه لسیزې دمخه).
ځنډ
د ټرمینل فعالیت د بشپړې مطالعې وروسته، زه دې پایلې ته ورسیدم چې پدې برخه کې ترټولو مهم پیرامیټر د ځنډ (پنګ) دی. په خپله مقاله کې پاول فاټین د مختلف متن ایډیټورانو ځنډ ته کتنه وکړه او اشاره یې وکړه چې پدې برخه کې ټرمینالونه ممکن د ګړندي متن ایډیټرانو په پرتله ورو وي. دا اشاره وه چې په نهایت کې ما د دې لامل شو چې خپلې ازموینې پرمخ وړم او دا مقاله لیکم.
مګر ځنډ څه دی، او ولې دا خورا مهم دی؟ په خپله مقاله کې ، فاټین دا د "کیلي فشار کولو او اړوند سکرین تازه کولو ترمینځ ځنډ" په توګه تعریف کړی او حواله یې کړې. ، کوم چې وايي: "د کمپیوټر په ښودنه کې د لید لید کې ځنډ د ټایپیسټ چلند او رضایت باندې مهم اغیزه لري."
فاټین تشریح کوي چې دا پینګ یوازې د اطمینان په پرتله ژورې پایلې لري: "ټایپ کول ورو کیږي، ډیرې غلطۍ رامنځته کیږي، او د سترګو او عضلاتو فشار زیاتیږي." په بل عبارت، یو لوی ځنډ کولی شي د ټایپوس او همدارنګه د کوډ کیفیت ټیټ کړي، ځکه چې دا په دماغ کې د اضافي ادراکي بار لامل کیږي. مګر څه بدتر دی دا دی چې پینګ "د سترګو او عضلاتو فشار زیاتوي"، کوم چې داسې ښکاري په راتلونکي کې (په ښکاره ډول، لیکوال د سترګو عضلاتو، شا، لاسونو او البته، لید - نږدې د ستونزو معنی لري. لیند تکرار فشار له امله.
ځینې دا اغیزې د اوږدې مودې لپاره پیژندل شوي، او پایلې یې په 1976 کې د ارګونومیک په ژورنال کې خپور شو، وویل چې د 100 ملی ثانیو ځنډ "د پام وړ د ټایپ کولو سرعت خرابوي." په دې وروستیو کې، د GNOME کاروونکي لارښود معرفي شو په 10 ملی ثانیو کې، او که تاسو نور لاړ شئ، بیا ښیې چې 1 ملی ثانیه مثالی دی.
فاټین د متن ایډیټورانو په اړه خپلې ازموینې ترسره کړې؛ هغه یو پورټ ایبل وسیله جوړه کړه چې نوم یې دی ، کوم چې ما په ټرمینل ایمولیټرونو کې د پینګ ازموینه کارولې. په یاد ولرئ چې ازموینه د سمولیشن حالت کې ترسره شوې: په حقیقت کې ، موږ اړتیا لرو دواړه ان پټ (کیبورډ ، USB کنټرولر ، او نور) او محصول (ویډیو کارت بفر ، مانیټر) ځنډ په پام کې ونیسو. د فاټین په وینا، په عادي تشکیلاتو کې دا شاوخوا 20 ms دی. که تاسو د لوبو تجهیزات لرئ، تاسو کولی شئ دا ارقام یوازې په 3 ملی ثانیو کې ترلاسه کړئ. څنګه چې موږ دمخه دومره ګړندي هارډویر لرو ، نو غوښتنلیک اړتیا نلري خپل ځنډ اضافه کړي. د فاټین هدف دا دی چې د غوښتنلیک ځنډ 1 ملی ثانوي ته ورسوي، یا حتی پرته له ډایل کولو ترلاسه کړي لکه په .
دلته زما د اندازه کولو پایلې دي، او همدارنګه د فاټین ځینې پایلې، ترڅو وښيي چې زما تجربه د هغه له ازموینو سره موافق ده:
لومړی شی چې ما ته یې ټکان ورکړ د پخوانیو برنامو لکه xterm او mlterm غوره غبرګون وخت و. د خورا خراب راجستر ځنډ (2,4 ms) سره، دوی د خورا ګړندۍ عصري ټرمینل څخه ښه فعالیت وکړ (د st لپاره 10,6 ms). هیڅ عصري ترمینل د 10 ملی ثانوي حد څخه ښکته نه راځي. په ځانګړې توګه، الیکریټي د "د ګړندي ترمینل ایمولیټر شتون" ادعا په پوره کولو کې پاتې راغلی، که څه هم د هغې نمرې په 2017 کې د هغې د لومړۍ بیاکتنې راهیسې ښه شوي. په حقیقت کې، د پروژې لیکوالان او د نندارې د ښه کولو لپاره کار کوي. دا هم باید په پام کې ونیول شي چې ویم د GTK3 په کارولو سره د هغې د GTK2 همکار په پرتله ورو ورو شدت دی. له دې څخه موږ دې پایلې ته رسیږو چې GTK3 اضافي ځنډ رامینځته کوي ، او دا په نورو ټولو ټرمینلونو کې منعکس کیږي چې دا کاروي (ټرمینیټر ، Xfce4 ټرمینل او GNOME ټرمینل).
په هرصورت، توپیر ممکن د سترګو لپاره د پام وړ نه وي. لکه څنګه چې فاټین تشریح کوي، "تاسو باید د ځنډ څخه خبر نه یاست چې دا په تاسو باندې اغیزه لري." فاټین د معیاري انحراف په اړه هم خبرداری ورکوي: "په ځنډ کې هر ډول ګډوډي د دوی د نه اټکل کیدو له امله اضافي فشار رامینځته کوي."
پورته ګراف په خالص ډیبیان 9 (پراخه) کې اخیستل شوی . دا چاپیریال د ځنډ ازموینې کې غوره پایلې تولیدوي. لکه څنګه چې دا معلومه شوه، GNOME د ټولو اندازه کولو لپاره د 20 ms اضافي پینګ رامینځته کوي. د دې لپاره احتمالي توضیح د برنامو شتون دی چې د ان پټ پیښو ترکیب پروسس کولو سره. فاټین د داسې یوې قضیې لپاره مثال ورکوي ، کوم چې په همغږي ډول د ټولو ان پټ پیښو پروسس کولو سره ځنډ اضافه کوي. په ډیفالټ ډول، GNOME هم د کړکۍ مدیر سره راځي ، کوم چې د بفرینګ اضافي پرت رامینځته کوي ، کوم چې په پینګ اغیزه کوي او لږترلږه 8 ملی ثانیه ځنډ اضافه کوي.
د سکرول سرعت
بله ازموینه یو دودیز "سرعت" یا "بینډ ویت" ازموینه ده، کوم چې دا اندازه کوي چې څومره ژر ترمینل کولی شي پاڼه سکرول کړي پداسې حال کې چې په سکرین کې د متن لوی مقدار ښودل کیږي. د ازموینې میخانیکونه توپیر لري؛ اصلي ازموینه په ساده ډول د seq کمانډ په کارولو سره ورته متن تار رامینځته کول وو. په نورو ازموینو کې د توماس ای ډیکي (xterm ساتونکي) ازموینه شامله ده، چې په مکرر ډول . د ټرمینل فعالیت په بله بیاکتنه کې د تصادفي بایټونو بیس 32 کوډ شوی تار کاروي ، کوم چې د بلی په کارولو سره ترمینل ته محصول دی. لو دا ډول ازموینه د "لکه څنګه چې یو څوک تصور کولی شي بې ګټې بینچمارک" ګڼي او د دې پرځای د لومړني میټریک په توګه د ټرمینل ځواب کارولو وړاندیز کوي. ډیکي هم خپله ازموینه غلطه بولي. په هرصورت، دواړه لیکوالان دا مني چې د ټرمینل کړکۍ بینډ ویت یوه مسله کیدی شي. لو د لوی فایلونو د ښودلو پر مهال Emacs Eshell منجمد وموندل شو، او ډیکي د xtrerm بصری سستۍ څخه د خلاصون لپاره ټرمینل غوره کړ. نو پدې ازموینې کې لاهم یو څه وړتیا شتون لري ، مګر څنګه چې د رینډر کولو پروسه له ټرمینل څخه تر ټرمینل پورې خورا توپیر لري ، نو دا د نورو پیرامیټونو ازموینې لپاره د ازموینې برخې په توګه هم کارول کیدی شي.
دلته موږ د سیالۍ څخه مخکې rxvt او st پل ګورو، وروسته د خورا نوي الیکریټي په تعقیب، کوم چې د فعالیت په تمرکز سره ډیزاین شوی. ورپسې د Xfce (VTE کورنۍ) او کنسول دي، چې نږدې دوه چنده ګړندي دي. وروستی xterm دی، کوم چې د rxvt په پرتله پنځه ځله سست دی. د ازموینې په جریان کې ، xterm هم خورا ډیر راوتلی ، د متن تیریدل ستونزمن کوي حتی که دا ورته کرښه وي. کنسول ګړندی و، مګر دا په ځینو وختونو کې ستونزمن و: نندارتون به وخت په وخت کنګل شي، جزوی متن ښودل یا په هیڅ ډول نه ښودل. نور ټرمینلونه په واضح ډول تارونه ښیې، پشمول د st، Alakritty، او rxvt.
ډیکي تشریح کوي چې د فعالیت توپیرونه په مختلف ټرمینلونو کې د سکرول بفرونو ډیزاین له امله دي. په ځانګړې توګه، هغه rxvt او نور ټرمینالونه د "عمومي قواعدو نه تعقیب" تورنوي:
"د xterm برعکس، rxvt د ټولو تازه معلوماتو ښودلو هڅه نه ده کړې. که دا شاته راشي، نو دا به د نیولو لپاره ځینې تازه معلومات رد کړي. دا د داخلي حافظې تنظیم په پرتله په ښکاره سکرول کولو سرعت باندې خورا لوی اغیزه درلوده. یو نیمګړتیا دا وه چې د ASCII حرکت یو څه غلط و.
د دې پیژندل شوي xterm سستۍ د حل لپاره، ډیکي د سرچینې کارولو وړاندیز کوي ، xterm ته اجازه ورکوي چې د جریان سره ساتلو لپاره ځینې سکرین تازه معلومات رد کړي. زما ازموینې تاییدوي چې فاسټ سکرول فعالیت ښه کوي او xterm د rxvt سره برابروي. په هرصورت، دا یو ډیر خراب کرچ دی، لکه څنګه چې ډیکي پخپله تشریح کوي: "کله ناکله xterm - لکه کنسول - داسې ښکاري چې ودریږي ځکه چې دا د ځینې لرې کولو وروسته د سکرین تازه معلوماتو نوي سیټ ته انتظار کوي." په دې رګ کې، داسې بریښي چې نورو ترمینلونو د سرعت او نندارې بشپړتیا تر منځ غوره جوړجاړی موندلی دی.
د منابعو مصرف
پرته لدې چې ایا دا د فعالیت میټریک په توګه د سکرول کولو سرعت په پام کې نیولو سره معنی لري ، دا ازموینه موږ ته اجازه راکوي چې په ټرمینلونو کې بار انډول کړو ، کوم چې په پایله کې موږ ته اجازه راکوي نور پیرامیټونه اندازه کړو لکه د حافظې یا ډیسک کارول. میټریکونه د ټاکل شوي ازموینې په چلولو سره ترلاسه شوي seq د Python پروسې څارنې لاندې. هغه د میټر معلومات راټول کړل لپاره ru_maxrss، مقدار ru_oublock и ru_inblock او یو ساده ټایمر.
په دې ازموینه کې، ST د 8 MB د ټیټ اوسط حافظې مصرف سره لومړی ځای نیسي، کوم چې د حیرانتیا خبره نده چې د ډیزاین اصلي نظر سادگي ده. mlterm، xterm او rxvt لږ څه مصرفوي - شاوخوا 12 MB. بله د پام وړ پایله الاکریټي ده ، کوم چې د چلولو لپاره 30 MB ته اړتیا لري. بیا د VTE کورنۍ ټرمینلونه د 40 څخه تر 60 MB پورې ارقامو سره شتون لري ، کوم چې خورا ډیر دی. دا مصرف د دې حقیقت له مخې تشریح کیدی شي چې دا ټرمینالونه د لوړې کچې کتابتونونه کاروي، د بیلګې په توګه، GTK. کنسول د ازموینو په جریان کې د 65MB حافظې مصرف سره په وروستي کې راځي ، که څه هم دا د دې خورا پراخه ځانګړتیاو لخوا توجیه کیدی شي.
د تیرو پایلو په پرتله چې لس کاله دمخه ترلاسه شوي، ټول پروګرامونه د پام وړ ډیر حافظه مصرفوي. Xterm پخوا 4 MB ته اړتیا درلوده، مګر اوس دا یوازې په پیل کې 15 MB ته اړتیا لري. د rxvt لپاره په مصرف کې ورته زیاتوالی شتون لري ، کوم چې اوس له بکس څخه 16 MB ته اړتیا لري. د Xfce ټرمینل 34 MB اخلي، کوم چې د پخوا په پرتله درې ځله لوی دی، مګر د GNOME ټرمینل یوازې 20 MB ته اړتیا لري. البته، ټولې پخوانۍ ازموینې په 32-bit جوړښت کې ترسره شوي. په LCA 2012 کې Rusty Russell ، چې ډیری نور فرعي دلایل شتون لري چې کولی شي د حافظې مصرف کې زیاتوالی تشریح کړي. د دې په ویلو سره ، موږ اوس په داسې وخت کې ژوند کوو چیرې چې موږ ګیګابایټ حافظه لرو ، نو موږ به یو څه اداره کړو.
په هرصورت، زه مرسته نشم کولی مګر احساس کوم چې د ټرمینل په څیر بنسټیز یو څه ته د ډیرې حافظې تخصیص کول د سرچینو ضایع کول دي. دا پروګرامونه باید تر ټولو کوچنی وي، باید په هر "بکس" کې د چلولو وړ وي، حتی د بوټانو بکس، که موږ کله هم هغه ځای ته ورسیږو چیرې چې دوی د لینکس سیسټمونو سره سمبال شوي وي (او تاسو پوهیږئ چې دا به داسې وي. ) . مګر د دې شمیرو سره ، د حافظې کارول به په راتلونکي کې په هر چاپیریال کې یوه مسله شي چې ډیری ټرمینالونه چلوي پرته له یو څو خورا سپک او خورا محدود ظرفیتونو څخه. د دې د جبرانولو لپاره، GNOME ټرمینل، کنسول، urxvt، Terminator او Xfce ټرمینل د ډیمون حالت لري چې تاسو ته اجازه درکوي د یوې پروسې له لارې ډیری ټرمینلونه کنټرول کړئ، د دوی د حافظې مصرف محدودوي.
زما د ازموینو په جریان کې ، زه د ډیسک لوستلو لیکلو په اړه بلې غیر متوقع پایلې ته ورسیدم: ما تمه درلوده چې دلته هیڅ شی ونه لیدم ، مګر دا معلومه شوه چې ځینې ټرمینلونه ډیسک ته خورا لوی ډیټا لیکي. نو، د VTE کتابتون په حقیقت کې په ډیسک کې د سکرول بفر ساتي (دا خصوصیت ، او دا لاهم پیښیږي). مګر د پخوانیو تطبیقاتو برعکس، اوس لږترلږه دا ډاټا د AES256 GCM په کارولو سره کوډ شوی (). مګر یو معقول پوښتنه راپورته کیږي: د VTE کتابتون په اړه دومره ځانګړی څه دی چې دا د پلي کولو لپاره داسې غیر معیاري چلند ته اړتیا لري ...
پایلې
د مقالې په لومړۍ برخه کې، موږ وموندله چې د VTE پر بنسټ ټرمینلونه د ځانګړتیاوو ښه سیټ لري، مګر اوس موږ ګورو چې دا د ځینې فعالیت لګښتونو سره راځي. اوس حافظه کومه مسله نده ځکه چې د VTE ټول ټرمینلونه د ډیمون پروسې له لارې کنټرول کیدی شي ، کوم چې د دوی اشتها محدودوي. په هرصورت، زاړه سیسټمونه چې د RAM او کرنل بفرونو مقدار باندې فزیکي محدودیتونه لري ممکن لاهم د ټرمینل پخوانیو نسخو ته اړتیا ولري، ځکه چې دوی د پام وړ لږې سرچینې مصرفوي. که څه هم د VTE ټرمینالونو د ټریپټ (سکرولینګ) ازموینو کې ښه فعالیت کړی ، د دوی د ښودلو ځنډ د GNOME کارونکي لارښود کې ټاکل شوي حد څخه پورته دی. د VTE پراختیا کونکي باید دا په پام کې ونیسي. که موږ په پام کې ونیسو چې حتی د نوي لینکس کاروونکو لپاره چې د ټرمینل سره مخ کیږي ناگزیر دي ، دوی کولی شي دا ډیر کارونکي دوستانه کړي. د تجربه لرونکو ګیکسونو لپاره، د ډیفالټ ټرمینل څخه بدلول ممکن حتی د سترګو کم فشار او د اوږدې کاري غونډو له امله د راتلونکي کار پورې اړوند ټپونو او ناروغیو څخه مخنیوي وړتیا معنی ولري. له بده مرغه، یوازې زاړه xterm او mlterm موږ د 10 ملی ثانیو جادو پینګ حد ته راوړو، کوم چې د ډیری لپاره د منلو وړ ندي.
د بنچمارک اندازه کولو دا هم وښودله چې د لینکس ګرافیکي چاپیریال پراختیا له امله ، پراختیا کونکي باید یو شمیر جوړجاړی وکړي. ځینې کاروونکي ممکن د منظم کړکۍ مدیرانو ته وګوري ځکه چې دوی د پام وړ پینګ کمښت چمتو کوي. له بده مرغه، د ویلینډ لپاره د ځنډ اندازه کول ممکن ندي: د ټایپومیټر برنامه چې ما کارولې د هغه څه لپاره رامینځته شوی و چې ویلینډ د مخنیوي لپاره ډیزاین شوی: په نورو کړکیو کې جاسوسي. زه امید لرم چې د Wayland کمپوز کول د X.org په پرتله ښه فعالیت کوي، او زه دا هم امید لرم چې په راتلونکي کې به یو څوک پدې چاپیریال کې د ځنډ اندازه کولو لپاره لاره ومومي.
سرچینه: www.habr.com