ਟਰਮੀਨਲ ਇਮੂਲੇਟਰਾਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ

ਸਾਡੇ ਅਨੁਵਾਦ ਬਿਊਰੋ ਤੋਂ ਕੁਝ ਸ਼ਬਦ: ਆਮ ਤੌਰ 'ਤੇ ਹਰ ਕੋਈ ਨਵੀਨਤਮ ਸਮੱਗਰੀ ਅਤੇ ਪ੍ਰਕਾਸ਼ਨਾਂ ਦਾ ਅਨੁਵਾਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਕੋਈ ਅਪਵਾਦ ਨਹੀਂ ਹਾਂ। ਪਰ ਟਰਮੀਨਲ ਅਜਿਹੀ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਹੈ ਜੋ ਹਫ਼ਤੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਅੱਪਡੇਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਲਈ, ਅਸੀਂ ਤੁਹਾਡੇ ਲਈ 2018 ਦੀ ਬਸੰਤ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਤ ਐਂਟੋਨੀ ਬੇਉਪ੍ਰੇ ਦੁਆਰਾ ਇੱਕ ਲੇਖ ਦਾ ਅਨੁਵਾਦ ਕੀਤਾ ਹੈ: ਆਧੁਨਿਕ ਮਾਪਦੰਡਾਂ ਦੁਆਰਾ ਇਸਦੀ ਕਾਫ਼ੀ "ਉਮਰ" ਦੇ ਬਾਵਜੂਦ, ਸਾਡੀ ਰਾਏ ਵਿੱਚ, ਸਮੱਗਰੀ ਨੇ ਆਪਣੀ ਪ੍ਰਸੰਗਿਕਤਾ ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਗੁਆਇਆ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਅਸਲ ਵਿੱਚ ਦੋ ਲੇਖਾਂ ਦੀ ਇੱਕ ਲੜੀ ਸੀ, ਪਰ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵੱਡੀ ਪੋਸਟ ਵਿੱਚ ਜੋੜਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਕੰਪਿਊਟਰ ਇਤਿਹਾਸ ਵਿੱਚ ਟਰਮੀਨਲਾਂ ਦਾ ਵਿਸ਼ੇਸ਼ ਸਥਾਨ ਹੈ, ਪਰ ਹਾਲ ਹੀ ਦੇ ਦਹਾਕਿਆਂ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਕਮਾਂਡ ਲਾਈਨ ਦੇ ਨਾਲ-ਨਾਲ ਜਿਉਂਦੇ ਰਹਿਣ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿਉਂਕਿ ਗ੍ਰਾਫਿਕਲ ਇੰਟਰਫੇਸ ਸਰਵ ਵਿਆਪਕ ਹੋ ਗਏ ਹਨ। ਟਰਮੀਨਲ ਇਮੂਲੇਟਰ ਉਹਨਾਂ ਦੀ ਥਾਂ ਲੈ ਲਈ ਹਾਰਡਵੇਅਰ ਭਰਾਵਾਂ, ਜੋ ਬਦਲੇ ਵਿੱਚ, ਪੰਚਡ ਕਾਰਡਾਂ ਅਤੇ ਟੌਗਲ ਸਵਿੱਚਾਂ ਦੇ ਅਧਾਰ ਤੇ ਸਿਸਟਮਾਂ ਦੀ ਇੱਕ ਸੋਧ ਸਨ। ਆਧੁਨਿਕ ਵੰਡ ਸਾਰੇ ਆਕਾਰਾਂ ਅਤੇ ਰੰਗਾਂ ਦੇ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਟਰਮੀਨਲ ਇਮੂਲੇਟਰਾਂ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ। ਅਤੇ ਜਦੋਂ ਕਿ ਬਹੁਤ ਸਾਰੇ ਆਪਣੇ ਕੰਮ ਦੇ ਵਾਤਾਵਰਣ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਸਟੈਂਡਰਡ ਟਰਮੀਨਲ ਨਾਲ ਸੰਤੁਸ਼ਟ ਹਨ, ਕੁਝ ਆਪਣੇ ਮਨਪਸੰਦ ਸ਼ੈੱਲ ਜਾਂ ਟੈਕਸਟ ਐਡੀਟਰ ਨੂੰ ਚਲਾਉਣ ਲਈ ਮਾਣ ਨਾਲ ਸਿੱਧੇ ਵਿਦੇਸ਼ੀ ਸੌਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਪਰ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਇਸ ਲੇਖ ਤੋਂ ਦੇਖਾਂਗੇ, ਸਾਰੇ ਟਰਮੀਨਲ ਇੱਕੋ ਚਿੱਤਰ ਵਿੱਚ ਨਹੀਂ ਬਣਾਏ ਗਏ ਸਨ: ਉਹ ਕਾਰਜਸ਼ੀਲਤਾ, ਆਕਾਰ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਬਹੁਤ ਵੱਖਰੇ ਹਨ।

ਕੁਝ ਟਰਮੀਨਲਾਂ ਵਿੱਚ ਬਿਲਕੁਲ ਹੈਰਾਨੀਜਨਕ ਸੁਰੱਖਿਆ ਛੇਕ ਹੁੰਦੇ ਹਨ, ਨਾਲ ਹੀ ਜ਼ਿਆਦਾਤਰ ਵਿੱਚ ਇੱਕ ਟੈਬਡ ਇੰਟਰਫੇਸ ਲਈ ਸਮਰਥਨ ਤੋਂ ਲੈ ਕੇ ਸਕ੍ਰਿਪਟਿੰਗ ਤੱਕ ਫੰਕਸ਼ਨਾਂ ਦਾ ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰਾ ਸਮੂਹ ਹੁੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਅਸੀਂ ਦੂਰ ਦੇ ਅਤੀਤ ਵਿੱਚ ਟਰਮੀਨਲ ਇਮੂਲੇਟਰਾਂ ਨੂੰ ਦੇਖਿਆ, ਇਹ ਲੇਖ ਪਿਛਲੀ ਸਮੱਗਰੀ ਦਾ ਇੱਕ ਅੱਪਡੇਟ ਹੈ ਜੋ ਪਾਠਕਾਂ ਨੂੰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਕਿ 2018 ਵਿੱਚ ਕਿਹੜਾ ਟਰਮੀਨਲ ਵਰਤਣਾ ਹੈ। ਲੇਖ ਦਾ ਪਹਿਲਾ ਅੱਧ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਅੱਧ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ।

ਇੱਥੇ ਉਹ ਟਰਮੀਨਲ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਮੈਂ ਸਮੀਖਿਆ ਕੀਤੀ ਹੈ:

ਇਹ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਮੈਂ ਲਿਖਣ ਦੇ ਸਮੇਂ ਸਥਿਰ ਬਿਲਡਾਂ ਤੱਕ ਸੀਮਿਤ ਸੀ, ਜਿਸ ਨੂੰ ਮੈਂ ਡੇਬੀਅਨ 9 ਜਾਂ ਫੇਡੋਰਾ 27 'ਤੇ ਰੋਲ ਆਊਟ ਕਰਨ ਦੇ ਯੋਗ ਸੀ। ਸਿਰਫ ਅਪਵਾਦ ਅਲੈਕ੍ਰਿਟੀ ਹੈ। ਇਹ ਜੀਪੀਯੂ-ਐਕਸਲਰੇਟਿਡ ਟਰਮੀਨਲਾਂ ਦਾ ਵੰਸ਼ਜ ਹੈ ਅਤੇ ਇਸ ਕੰਮ ਲਈ ਇੱਕ ਅਸਾਧਾਰਨ ਅਤੇ ਨਵੀਂ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ - ਜੰਗਾਲ। ਮੈਂ ਆਪਣੀ ਸਮੀਖਿਆ ਤੋਂ ਵੈਬ ਟਰਮੀਨਲਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ ਹੈ (ਉਨ੍ਹਾਂ ਸਮੇਤ ਇਲੈਕਟਰੋਨ), ਕਿਉਂਕਿ ਸ਼ੁਰੂਆਤੀ ਟੈਸਟਾਂ ਨੇ ਉਹਨਾਂ ਦੀ ਬਹੁਤ ਮਾੜੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦਿਖਾਈ ਹੈ।

ਯੂਨੀਕੋਡ ਸਮਰਥਨ

ਮੈਂ ਯੂਨੀਕੋਡ ਸਹਾਇਤਾ ਨਾਲ ਆਪਣੇ ਟੈਸਟ ਸ਼ੁਰੂ ਕੀਤੇ। ਟਰਮੀਨਲ ਦਾ ਪਹਿਲਾ ਟੈਸਟ ਯੂਨੀਕੋਡ ਸਤਰ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨਾ ਸੀ ਵਿਕੀਪੀਡੀਆ ਲੇਖ: “é, Δ, И, ק, م, ๗, あ, 叶, 葉 ਅਤੇ 말।” ਇਹ ਸਧਾਰਨ ਟੈਸਟ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਟਰਮੀਨਲ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। xterm ਟਰਮੀਨਲ ਅਰਬੀ ਅੱਖਰ ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ ਹੈ ਮੈਮ ਡਿਫਾਲਟ ਸੰਰਚਨਾ ਵਿੱਚ:

ਮੂਲ ਰੂਪ ਵਿੱਚ, xterm ਕਲਾਸਿਕ "ਸਥਿਰ" ਫੌਂਟ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਅਨੁਸਾਰ ਅਜੇ ਵੀ ਉਹੀ ਵਿੱਕੀ, ਦੀ "1997 ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਯੂਨੀਕੋਡ ਕਵਰੇਜ" ਹੈ। ਇਸ ਫੌਂਟ ਵਿੱਚ ਕੁਝ ਅਜਿਹਾ ਚੱਲ ਰਿਹਾ ਹੈ ਜਿਸ ਕਾਰਨ ਅੱਖਰ ਇੱਕ ਖਾਲੀ ਫਰੇਮ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇਹ ਉਦੋਂ ਹੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਟੈਕਸਟ ਫੌਂਟ ਨੂੰ 20+ ਪੁਆਇੰਟਾਂ ਤੱਕ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿ ਅੱਖਰ ਅੰਤ ਵਿੱਚ ਸਹੀ ਢੰਗ ਨਾਲ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ "ਫਿਕਸ" ਦੂਜੇ ਯੂਨੀਕੋਡ ਅੱਖਰਾਂ ਦੇ ਡਿਸਪਲੇ ਨੂੰ ਤੋੜਦਾ ਹੈ:

ਇਹ ਸਕਰੀਨਸ਼ਾਟ ਫੇਡੋਰਾ 27 ਵਿੱਚ ਲਏ ਗਏ ਸਨ, ਕਿਉਂਕਿ ਇਸ ਨੇ ਡੇਬੀਅਨ 9 ਨਾਲੋਂ ਵਧੀਆ ਨਤੀਜੇ ਦਿੱਤੇ ਸਨ, ਜਿੱਥੇ ਟਰਮੀਨਲ ਦੇ ਕੁਝ ਪੁਰਾਣੇ ਸੰਸਕਰਣ (ਖਾਸ ਤੌਰ 'ਤੇ mlterm) ਫੌਂਟਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਨਹੀਂ ਸੰਭਾਲ ਸਕਦੇ ਸਨ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ ਇਹ ਬਾਅਦ ਦੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਹੱਲ ਕੀਤਾ ਗਿਆ ਸੀ।

ਹੁਣ ਧਿਆਨ ਦਿਓ ਕਿ xterm ਵਿੱਚ ਲਾਈਨ ਕਿਵੇਂ ਦਿਖਾਈ ਜਾਂਦੀ ਹੈ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਪ੍ਰਤੀਕ ਮੇਮ ਅਤੇ ਹੇਠਲਾ ਸਾਮੀ qoph RTL ਸ਼ੈਲੀ ਸਕ੍ਰਿਪਟਾਂ (ਸੱਜੇ-ਤੋਂ-ਖੱਬੇ), ਇਸ ਲਈ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਸੱਜੇ ਤੋਂ ਖੱਬੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰ ਜਿਵੇਂ ਕਿ ਫਾਇਰਫਾਕਸ 57 ਉਪਰੋਕਤ ਲਾਈਨ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕਰਦੇ ਹਨ। RTL ਟੈਕਸਟ ਦਾ ਇੱਕ ਸਰਲ ਸੰਸਕਰਣ ਸ਼ਬਦ ਹੈ "ਸਾਰਾਹ"ਇਬਰਾਨੀ ਵਿੱਚ (שרה). ਦੋ-ਦਿਸ਼ਾਵੀ ਲਿਖਤਾਂ 'ਤੇ ਵਿਕੀ ਪੰਨਾ ਹੇਠ ਲਿਖਿਆ ਹੈ:

"ਬਹੁਤ ਸਾਰੇ ਕੰਪਿਊਟਰ ਪ੍ਰੋਗਰਾਮ ਦੋ-ਦਿਸ਼ਾਵੀ ਟੈਕਸਟ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇਬਰਾਨੀ ਨਾਮ "ਸਾਰਾਹ" ਵਿੱਚ ਅੱਖਰ sin (ש) (ਜੋ ਸੱਜੇ ਪਾਸੇ ਦਿਸਦਾ ਹੈ), ਫਿਰ resh (ר) ਅਤੇ ਅੰਤ ਵਿੱਚ he (ה) (ਜੋ ਖੱਬੇ ਪਾਸੇ ਦਿਸਣਾ ਚਾਹੀਦਾ ਹੈ) ਸ਼ਾਮਲ ਹਨ।"

ਬਹੁਤ ਸਾਰੇ ਟਰਮੀਨਲ ਇਸ ਟੈਸਟ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦੇ ਹਨ: ਅਲਾਕ੍ਰਿਟੀ, VTE-ਪ੍ਰਾਪਤ ਗਨੋਮ ਅਤੇ XFCE ਟਰਮੀਨਲ, urxvt, st ਅਤੇ xterm "ਸਾਰਾ" ਨੂੰ ਉਲਟ ਕ੍ਰਮ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ "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

ਜਦੋਂ ਹੌਰਨ ਦੀ ਵੈੱਬਸਾਈਟ ਤੋਂ ਟਰਮੀਨਲ ਵਿੱਚ ਪੇਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਅਜਿਹੀ ਪਰੇਸ਼ਾਨੀ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ:

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 ਰੀਡਲਾਈਨ (ਉਹੀ ਬੈਸ਼), ਇੱਕ ਫਾਈਲ ਦੀ ਲੋੜ ਹੈ ~/.inputrc:

set enable-bracketed-paste on

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਹੌਰਨ ਦੀ ਟੈਸਟ ਸਾਈਟ ਇਹ ਵੀ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਟੈਕਸਟ ਫਾਰਮੈਟਿੰਗ ਦੁਆਰਾ ਇਸ ਸੁਰੱਖਿਆ ਨੂੰ ਕਿਵੇਂ ਬਾਈਪਾਸ ਕਰਨਾ ਹੈ ਅਤੇ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਇਸ 'ਤੇ ਬ੍ਰੈਕੇਟਡ ਮੋਡ ਲਾਗੂ ਕਰਨਾ ਹੈ। ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਕੁਝ ਟਰਮੀਨਲ ਆਪਣੇ ਖੁਦ ਦੇ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਬਚਣ ਦੇ ਕ੍ਰਮ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਫਿਲਟਰ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਮੇਰੇ ਵਿੱਚ ਮੈਂ ਕਦੇ ਵੀ ਸਹੀ ਸੰਰਚਨਾ ਦੇ ਨਾਲ ਵੀ ਕੋਨਸੋਲ ਟੈਸਟਾਂ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰਾ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਸੀ। .inputrc ਫਾਈਲ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਅਸਮਰਥਿਤ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਗਲਤ ਸੰਰਚਿਤ ਸ਼ੈੱਲ ਦੇ ਕਾਰਨ ਆਸਾਨੀ ਨਾਲ ਆਪਣੀ ਸਿਸਟਮ ਸੰਰਚਨਾ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੇ ਹੋ। ਰਿਮੋਟ ਸਰਵਰਾਂ ਵਿੱਚ ਲੌਗਇਨ ਕਰਨ ਵੇਲੇ ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਖ਼ਤਰਨਾਕ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਧਿਆਨ ਨਾਲ ਸੰਰਚਨਾ ਦਾ ਕੰਮ ਘੱਟ ਆਮ ਹੁੰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਅਜਿਹੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਰਿਮੋਟ ਮਸ਼ੀਨਾਂ ਹਨ।

ਇਸ ਸਮੱਸਿਆ ਦਾ ਇੱਕ ਚੰਗਾ ਹੱਲ ਟਰਮੀਨਲ ਲਈ ਪੇਸਟ ਪੁਸ਼ਟੀ ਪਲੱਗਇਨ ਹੈ urxvt, ਜੋ ਸਿਰਫ਼ ਨਵੀਂ ਲਾਈਨਾਂ ਵਾਲੇ ਕਿਸੇ ਵੀ ਟੈਕਸਟ ਨੂੰ ਸੰਮਿਲਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਮੰਗਦਾ ਹੈ। ਮੈਨੂੰ ਹੌਰਨ ਦੁਆਰਾ ਵਰਣਿਤ ਟੈਕਸਟ ਹਮਲੇ ਲਈ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਨਹੀਂ ਮਿਲਿਆ ਹੈ।

ਟੈਬਾਂ ਅਤੇ ਪ੍ਰੋਫਾਈਲਾਂ

ਇੱਕ ਪ੍ਰਸਿੱਧ ਵਿਸ਼ੇਸ਼ਤਾ ਹੁਣ ਇੱਕ ਟੈਬਡ ਇੰਟਰਫੇਸ ਲਈ ਸਮਰਥਨ ਹੈ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਇੱਕ ਟਰਮੀਨਲ ਵਿੰਡੋ ਦੇ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰਾਂਗੇ ਜਿਸ ਵਿੱਚ ਕਈ ਹੋਰ ਟਰਮੀਨਲ ਹਨ। ਇਹ ਫੰਕਸ਼ਨ ਵੱਖ-ਵੱਖ ਟਰਮੀਨਲਾਂ ਲਈ ਵੱਖਰਾ ਹੈ, ਅਤੇ ਹਾਲਾਂਕਿ ਰਵਾਇਤੀ xterm ਟਰਮੀਨਲ ਟੈਬਾਂ ਨੂੰ ਬਿਲਕੁਲ ਵੀ ਸਮਰਥਨ ਨਹੀਂ ਦਿੰਦੇ ਹਨ, ਹੋਰ ਆਧੁਨਿਕ ਟਰਮੀਨਲ ਅਵਤਾਰਾਂ ਜਿਵੇਂ ਕਿ Xfce ਟਰਮੀਨਲ, ਗਨੋਮ ਟਰਮੀਨਲ ਅਤੇ ਕੋਨਸੋਲ ਵਿੱਚ ਇਹ ਫੰਕਸ਼ਨ ਹੈ। Urxvt ਟੈਬਾਂ ਦਾ ਵੀ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਪਰ ਕੇਵਲ ਤਾਂ ਹੀ ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਪਲੱਗਇਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ। ਪਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਟੈਬ ਸਮਰਥਨ ਦੇ ਰੂਪ ਵਿੱਚ, ਟਰਮੀਨੇਟਰ ਇੱਕ ਨਿਰਵਿਵਾਦ ਲੀਡਰ ਹੈ: ਇਹ ਨਾ ਸਿਰਫ ਟੈਬਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਬਲਕਿ ਕਿਸੇ ਵੀ ਕ੍ਰਮ ਵਿੱਚ ਟਰਮੀਨਲਾਂ ਦਾ ਪ੍ਰਬੰਧ ਵੀ ਕਰ ਸਕਦਾ ਹੈ (ਹੇਠਾਂ ਚਿੱਤਰ ਦੇਖੋ)।

ਟਰਮੀਨੇਟਰ ਦੀ ਇੱਕ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹਨਾਂ ਟੈਬਾਂ ਨੂੰ ਇਕੱਠੇ "ਗਰੁੱਪ" ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ ਅਤੇ ਇੱਕੋ ਸਮੇਂ ਵਿੱਚ ਕਈ ਟਰਮੀਨਲਾਂ ਨੂੰ ਇੱਕੋ ਕੀਸਟ੍ਰੋਕ ਭੇਜਣ ਦੀ ਸਮਰੱਥਾ ਹੈ, ਇੱਕੋ ਸਮੇਂ ਕਈ ਸਰਵਰਾਂ 'ਤੇ ਬਲਕ ਓਪਰੇਸ਼ਨ ਕਰਨ ਲਈ ਇੱਕ ਕੱਚਾ ਟੂਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹੋ ਜਿਹੀ ਵਿਸ਼ੇਸ਼ਤਾ ਕੋਨਸੋਲ ਵਿੱਚ ਵੀ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ। ਹੋਰ ਟਰਮੀਨਲਾਂ ਵਿੱਚ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਤੀਜੀ-ਧਿਰ ਦੇ ਸੌਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਿਵੇਂ ਕਿ ਕਲੱਸਟਰ SSH, xlax ਜ tmux.

ਟੈਬਾਂ ਖਾਸ ਤੌਰ 'ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਪ੍ਰੋਫਾਈਲਾਂ ਨਾਲ ਪੇਅਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ ਈਮੇਲ ਲਈ ਇੱਕ ਟੈਬ, ਚੈਟ ਲਈ ਦੂਸਰੀ, ਆਦਿ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਕੋਨਸੋਲ ਟਰਮੀਨਲ ਅਤੇ ਗਨੋਮ ਟਰਮੀਨਲ ਦੁਆਰਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਹਿਯੋਗੀ ਹੈ। ਦੋਵੇਂ ਹਰੇਕ ਟੈਬ ਨੂੰ ਆਪਣੇ ਆਪ ਹੀ ਆਪਣੇ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਲਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਟਰਮੀਨੇਟਰ ਪ੍ਰੋਫਾਈਲਾਂ ਦਾ ਵੀ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਖਾਸ ਟੈਬ ਖੋਲ੍ਹਦੇ ਹੋ ਤਾਂ ਮੈਨੂੰ ਕੁਝ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਆਟੋਮੈਟਿਕ ਲਾਂਚ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਮਿਲਿਆ। ਹੋਰ ਟਰਮੀਨਲਾਂ ਵਿੱਚ "ਪ੍ਰੋਫਾਈਲ" ਦੀ ਧਾਰਨਾ ਬਿਲਕੁਲ ਨਹੀਂ ਹੈ।

ਰਫਲਾਂ

ਆਖਰੀ ਚੀਜ਼ ਜੋ ਮੈਂ ਇਸ ਲੇਖ ਦੇ ਪਹਿਲੇ ਹਿੱਸੇ ਵਿੱਚ ਕਵਰ ਕਰਾਂਗਾ ਉਹ ਹੈ ਟਰਮੀਨਲਾਂ ਦੀ ਦਿੱਖ. ਉਦਾਹਰਨ ਲਈ ਗਨੋਮ, Xfce ਅਤੇ urxvt ਪਾਰਦਰਸ਼ਤਾ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਪਰ ਹਾਲ ਹੀ ਵਿੱਚ ਬੈਕਗ੍ਰਾਉਂਡ ਚਿੱਤਰਾਂ ਲਈ ਸਮਰਥਨ ਛੱਡ ਦਿੱਤਾ ਹੈ, ਕੁਝ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਟਰਮੀਨਲ 'ਤੇ ਜਾਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਟਿਲਿਕਸ. ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ, ਮੈਂ ਇਸ ਤੋਂ ਖੁਸ਼ ਹਾਂ ਅਤੇ ਇਹ ਸਧਾਰਨ ਹੈ ਐਕਸ ਸਰੋਤ, ਜੋ ਕਿ urxvt ਲਈ ਬੈਕਗਰਾਊਂਡ ਰੰਗਾਂ ਦਾ ਅਧਾਰ ਸੈੱਟ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਗੈਰ-ਮਿਆਰੀ ਰੰਗ ਦੇ ਥੀਮ ਵੀ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਉਦਾਹਰਣ ਲਈ, ਸੋਲਰਾਈਜ਼ਡ ਕੰਮ ਨਹੀ ਕਰਦਾ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਨਾਲ htop и ਆਈਪੀਟ੍ਰਾਫ, ਕਿਉਂਕਿ ਉਹ ਪਹਿਲਾਂ ਹੀ ਆਪਣੇ ਰੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ.

ਅਸਲੀ VT100 ਟਰਮੀਨਲ ਰੰਗਾਂ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ ਸਨ, ਅਤੇ ਨਵੇਂ ਅਕਸਰ ਇੱਕ 256-ਰੰਗ ਪੈਲੇਟ ਤੱਕ ਸੀਮਿਤ ਹੁੰਦੇ ਸਨ। ਉੱਨਤ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਜੋ ਆਪਣੇ ਟਰਮੀਨਲਾਂ ਨੂੰ ਸਟਾਈਲ ਕਰਦੇ ਹਨ, ਸ਼ੈੱਲ ਪ੍ਰੋਂਪਟ ਜਾਂ ਸਥਿਤੀ ਬਾਰ ਗੁੰਝਲਦਾਰ ਤਰੀਕਿਆਂ ਨਾਲ ਇੱਕ ਤੰਗ ਕਰਨ ਵਾਲੀ ਸੀਮਾ ਹੋ ਸਕਦੀ ਹੈ। ਸਾਰ ਟਰੈਕ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਟਰਮੀਨਲਾਂ ਵਿੱਚ "ਸੱਚਾ ਰੰਗ" ਸਮਰਥਨ ਹੈ। ਮੇਰੇ ਟੈਸਟ ਇਸ ਗੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ ਕਿ ਸਟ, ਅਲਾਕ੍ਰਿਟੀ ਅਤੇ VTE-ਅਧਾਰਿਤ ਟਰਮੀਨਲ ਸਹੀ ਰੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਹੋਰ ਟਰਮੀਨਲ ਇਸ ਸਬੰਧ ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਹਨ ਅਤੇ, ਅਸਲ ਵਿੱਚ, 256 ਰੰਗ ਵੀ ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਕਰਦੇ ਹਨ. ਹੇਠਾਂ ਤੁਸੀਂ ਗਨੋਮ ਟਰਮੀਨਲਾਂ, st ਅਤੇ xterm ਵਿੱਚ ਟਰੂ ਕਲਰ ਸਪੋਰਟ ਵਿੱਚ ਅੰਤਰ ਦੇਖ ਸਕਦੇ ਹੋ, ਜੋ ਕਿ ਆਪਣੇ 256 ਰੰਗ ਪੈਲਅਟ ਅਤੇ urxvt ਨਾਲ ਇਸਦਾ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ, ਜੋ ਨਾ ਸਿਰਫ਼ ਟੈਸਟ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਸਗੋਂ ਉਹਨਾਂ ਦੀ ਬਜਾਏ ਕੁਝ ਝਪਕਦੇ ਅੱਖਰ ਵੀ ਦਿਖਾਉਂਦਾ ਹੈ।

ਲਿੰਕਾਂ ਨੂੰ ਕਲਿੱਕ ਕਰਨ ਯੋਗ ਬਣਾਉਣ ਲਈ ਕੁਝ ਟਰਮੀਨਲ URL ਪੈਟਰਨਾਂ ਲਈ ਟੈਕਸਟ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਵੀ ਕਰਦੇ ਹਨ। ਇਹ ਸਾਰੇ VTE-ਪ੍ਰਾਪਤ ਟਰਮੀਨਲਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ urxvt ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪਲੱਗਇਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ URL ਨੂੰ ਇੱਕ ਕਲਿੱਕ 'ਤੇ ਜਾਂ ਕੀਬੋਰਡ ਸ਼ਾਰਟਕੱਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਹੋਰ ਟਰਮੀਨਲ ਮੈਂ ਹੋਰ ਤਰੀਕਿਆਂ ਨਾਲ ਡਿਸਪਲੇ URL ਦੀ ਜਾਂਚ ਕੀਤੀ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਟਰਮੀਨਲਾਂ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਰੁਝਾਨ ਸਕ੍ਰੌਲ ਬਫਰ ਦੀ ਵਿਕਲਪਿਕਤਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, st ਦਾ ਕੋਈ ਸਕ੍ਰੋਲ ਬਫਰ ਨਹੀਂ ਹੈ; ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਇੱਕ ਟਰਮੀਨਲ ਮਲਟੀਪਲੈਕਸਰ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ ਜਿਵੇਂ ਕਿ tmux ਅਤੇ GNU ਸਕਰੀਨ.

ਅਲਾਕ੍ਰਿਟੀ ਵਿੱਚ ਵੀ ਬੈਕਸਕਰੋਲ ਬਫਰਾਂ ਦੀ ਘਾਟ ਹੈ, ਪਰ ਜਲਦੀ ਹੀ ਜੋੜਿਆ ਜਾਵੇਗਾ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਇਸ ਵਿਸ਼ੇ 'ਤੇ "ਵਿਆਪਕ ਫੀਡਬੈਕ" ਦੇ ਕਾਰਨ ਇਸਦਾ ਸਮਰਥਨ। ਇਹਨਾਂ ਅੱਪਸਟਾਰਟਸ ਤੋਂ ਇਲਾਵਾ, ਹਰ ਟਰਮੀਨਲ ਜਿਸ ਦੀ ਮੈਂ ਜਾਂਚ ਕੀਤੀ ਹੈ ਕਿ ਮੈਨੂੰ ਰਿਵਰਸ ਸਕ੍ਰੋਲਿੰਗ ਦਾ ਸਮਰਥਨ ਮਿਲਦਾ ਹੈ।

ਉਪ-ਯੋਗ

ਸਮੱਗਰੀ ਦੇ ਦੂਜੇ ਭਾਗ ਵਿੱਚ (ਅਸਲ ਵਿੱਚ ਇਹ ਦੋ ਵੱਖ-ਵੱਖ ਲੇਖ ਸਨ - ਲਗਭਗ. ਲੇਨ) ਅਸੀਂ ਪ੍ਰਦਰਸ਼ਨ, ਮੈਮੋਰੀ ਵਰਤੋਂ ਅਤੇ ਲੇਟੈਂਸੀ ਦੀ ਤੁਲਨਾ ਕਰਾਂਗੇ। ਪਰ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਦੇਖ ਸਕਦੇ ਹਾਂ ਕਿ ਸਵਾਲ ਵਿੱਚ ਕੁਝ ਟਰਮੀਨਲਾਂ ਵਿੱਚ ਗੰਭੀਰ ਕਮੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਉਹ ਉਪਭੋਗਤਾ ਜੋ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ RTL ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ ਉਹ mlterm ਅਤੇ pterm 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਦੂਜਿਆਂ ਨਾਲੋਂ ਸਮਾਨ ਕਾਰਜਾਂ ਨੂੰ ਸੰਭਾਲਣ ਵਿੱਚ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ। ਕੋਂਸੋਲ ਨੇ ਵੀ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ। ਉਪਭੋਗਤਾ ਜੋ RTL ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰਦੇ ਹਨ ਉਹ ਕੁਝ ਹੋਰ ਚੁਣ ਸਕਦੇ ਹਨ।

ਖਤਰਨਾਕ ਕੋਡ ਸੰਮਿਲਨ ਤੋਂ ਸੁਰੱਖਿਆ ਦੇ ਸੰਦਰਭ ਵਿੱਚ, urxvt ਇਸ ਕਿਸਮ ਦੇ ਹਮਲੇ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਦੇ ਇਸਦੇ ਵਿਸ਼ੇਸ਼ ਲਾਗੂਕਰਨ ਦੇ ਕਾਰਨ ਵੱਖਰਾ ਹੈ, ਜੋ ਮੇਰੇ ਲਈ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਸੁਵਿਧਾਜਨਕ ਜਾਪਦਾ ਹੈ। ਕੁਝ ਘੰਟੀਆਂ ਅਤੇ ਸੀਟੀਆਂ ਦੀ ਤਲਾਸ਼ ਕਰਨ ਵਾਲਿਆਂ ਲਈ, ਕੋਨਸੋਲ ਦੇਖਣ ਦੇ ਯੋਗ ਹੈ। ਅੰਤ ਵਿੱਚ, ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ VTE ਟਰਮੀਨਲਾਂ ਲਈ ਇੱਕ ਸ਼ਾਨਦਾਰ ਅਧਾਰ ਹੈ, ਜੋ ਕਿ ਰੰਗ ਸਮਰਥਨ, URL ਪਛਾਣ, ਆਦਿ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ। ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਤੁਹਾਡੇ ਮਨਪਸੰਦ ਵਾਤਾਵਰਣ ਨਾਲ ਆਉਣ ਵਾਲਾ ਡਿਫੌਲਟ ਟਰਮੀਨਲ ਸਾਰੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਆਓ ਇਸ ਸਵਾਲ ਨੂੰ ਉਦੋਂ ਤੱਕ ਖੁੱਲ੍ਹਾ ਛੱਡ ਦੇਈਏ ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਨਹੀਂ ਸਮਝਦੇ।

ਆਓ ਗੱਲਬਾਤ ਜਾਰੀ ਰੱਖੀਏ

ਆਮ ਤੌਰ 'ਤੇ, ਟਰਮੀਨਲਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਦੂਰ ਦੀ ਸਮੱਸਿਆ ਵਾਂਗ ਜਾਪਦੀ ਹੈ, ਪਰ ਜਿਵੇਂ ਕਿ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਅਜਿਹੇ ਬੁਨਿਆਦੀ ਕਿਸਮ ਦੇ ਸੌਫਟਵੇਅਰ ਲਈ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਉੱਚ ਵਿਲੰਬਤਾ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਨ। ਨਾਲ ਹੀ ਅੱਗੇ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਕਿਸ ਨੂੰ ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ "ਸਪੀਡ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ (ਅਸਲ ਵਿੱਚ, ਇਹ ਸਕ੍ਰੋਲਿੰਗ ਸਪੀਡ ਹੈ) ਅਤੇ ਟਰਮੀਨਲ ਦੀ ਮੈਮੋਰੀ ਖਪਤ (ਸਾਵਧਾਨ ਦੇ ਨਾਲ ਕਿ ਇਹ ਅੱਜ ਓਨਾ ਨਾਜ਼ੁਕ ਨਹੀਂ ਹੈ ਜਿੰਨਾ ਦਹਾਕਿਆਂ ਪਹਿਲਾਂ ਸੀ)।

ਦੇਰੀ

ਟਰਮੀਨਲ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਡੂੰਘੇ ਅਧਿਐਨ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚਿਆ ਕਿ ਇਸ ਸਬੰਧ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਮਾਪਦੰਡ ਲੇਟੈਂਸੀ (ਪਿੰਗ) ਹੈ। ਉਸ ਦੇ ਲੇਖ ਵਿਚ "ਅਸੀਂ ਖੁਸ਼ੀ ਨਾਲ ਛਾਪਦੇ ਹਾਂ" ਪਾਵੇਲ ਫੈਟੀਨ ਨੇ ਵੱਖ-ਵੱਖ ਟੈਕਸਟ ਐਡੀਟਰਾਂ ਦੀ ਲੇਟੈਂਸੀ ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਸੰਕੇਤ ਦਿੱਤਾ ਕਿ ਇਸ ਸਬੰਧ ਵਿੱਚ ਟਰਮੀਨਲ ਸਭ ਤੋਂ ਤੇਜ਼ ਟੈਕਸਟ ਐਡੀਟਰਾਂ ਨਾਲੋਂ ਹੌਲੀ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਇਹ ਸੰਕੇਤ ਸੀ ਜਿਸ ਨੇ ਆਖਰਕਾਰ ਮੈਨੂੰ ਆਪਣੇ ਖੁਦ ਦੇ ਟੈਸਟ ਚਲਾਉਣ ਅਤੇ ਇਸ ਲੇਖ ਨੂੰ ਲਿਖਣ ਲਈ ਅਗਵਾਈ ਕੀਤੀ.

ਪਰ ਲੇਟੈਂਸੀ ਕੀ ਹੈ, ਅਤੇ ਇਹ ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ? ਆਪਣੇ ਲੇਖ ਵਿੱਚ, ਫੈਟਿਨ ਨੇ ਇਸਨੂੰ "ਕੁੰਜੀ ਦਬਾਉਣ ਅਤੇ ਸੰਬੰਧਿਤ ਸਕ੍ਰੀਨ ਅਪਡੇਟ ਵਿੱਚ ਦੇਰੀ" ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਅਤੇ ਹਵਾਲਾ ਦਿੱਤਾ। "ਮਨੁੱਖੀ-ਕੰਪਿਊਟਰ ਇੰਟਰਐਕਸ਼ਨ ਲਈ ਗਾਈਡ", ਜੋ ਕਹਿੰਦਾ ਹੈ: "ਕੰਪਿਊਟਰ ਡਿਸਪਲੇ 'ਤੇ ਵਿਜ਼ੂਅਲ ਫੀਡਬੈਕ ਵਿੱਚ ਦੇਰੀ ਦਾ ਟਾਈਪਿਸਟ ਦੇ ਵਿਵਹਾਰ ਅਤੇ ਸੰਤੁਸ਼ਟੀ 'ਤੇ ਮਹੱਤਵਪੂਰਣ ਪ੍ਰਭਾਵ ਪੈਂਦਾ ਹੈ।"

ਫੈਟਿਨ ਦੱਸਦਾ ਹੈ ਕਿ ਇਸ ਪਿੰਗ ਦੇ ਸਿਰਫ਼ ਸੰਤੁਸ਼ਟੀ ਨਾਲੋਂ ਡੂੰਘੇ ਨਤੀਜੇ ਹਨ: "ਟਾਈਪਿੰਗ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਹੋਰ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਅੱਖਾਂ ਅਤੇ ਮਾਸਪੇਸ਼ੀਆਂ ਵਿੱਚ ਤਣਾਅ ਵਧਦਾ ਹੈ।" ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇੱਕ ਵੱਡੀ ਦੇਰੀ ਨਾਲ ਟਾਈਪੋਜ਼ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਕੋਡ ਦੀ ਗੁਣਵੱਤਾ ਵੀ ਘੱਟ ਹੋ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਦਿਮਾਗ 'ਤੇ ਵਾਧੂ ਬੋਧਾਤਮਕ ਬੋਝ ਵੱਲ ਖੜਦੀ ਹੈ। ਪਰ ਸਭ ਤੋਂ ਮਾੜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਪਿੰਗ "ਅੱਖਾਂ ਅਤੇ ਮਾਸਪੇਸ਼ੀਆਂ ਦੇ ਤਣਾਅ ਨੂੰ ਵਧਾਉਂਦੀ ਹੈ," ਜਿਸਦਾ ਅਰਥ ਜਾਪਦਾ ਹੈ ਪੇਸ਼ੇਵਰ ਸੱਟਾਂ ਦਾ ਵਿਕਾਸ ਭਵਿੱਖ ਵਿੱਚ (ਜ਼ਾਹਰਾ ਤੌਰ 'ਤੇ, ਲੇਖਕ ਦਾ ਮਤਲਬ ਹੈ ਅੱਖਾਂ ਦੀਆਂ ਮਾਸਪੇਸ਼ੀਆਂ, ਪਿੱਠ, ਬਾਹਾਂ ਅਤੇ, ਬੇਸ਼ਕ, ਨਜ਼ਰ - ਲਗਭਗ. ਲੇਨਦੁਹਰਾਉਣ ਵਾਲੇ ਤਣਾਅ ਦੇ ਕਾਰਨ.

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਨਤੀਜੇ ਖੋਜ, ਜਰਨਲ ਐਰਗੋਨੋਮਿਕਸ ਵਿੱਚ 1976 ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਤ ਹੋਇਆ, ਨੇ ਕਿਹਾ ਕਿ 100 ਮਿਲੀਸਕਿੰਟ ਦੀ ਦੇਰੀ "ਟਾਇਪਿੰਗ ਦੀ ਗਤੀ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਕਮਜ਼ੋਰ ਕਰਦੀ ਹੈ।" ਹਾਲ ਹੀ ਵਿੱਚ, ਗਨੋਮ ਯੂਜ਼ਰ ਗਾਈਡ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਹੈ ਸਵੀਕਾਰਯੋਗ ਜਵਾਬ ਸਮਾਂ 10 ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ, ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਅੱਗੇ ਜਾਂਦੇ ਹੋ, ਤਾਂ Microsoft ਖੋਜ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ 1 ਮਿਲੀਸਕਿੰਟ ਆਦਰਸ਼ ਹੈ।

ਫੈਟੀਨ ਨੇ ਟੈਕਸਟ ਐਡੀਟਰਾਂ 'ਤੇ ਆਪਣੇ ਟੈਸਟ ਕਰਵਾਏ; ਉਸਨੇ ਇੱਕ ਪੋਰਟੇਬਲ ਯੰਤਰ ਬਣਾਇਆ ਜਿਸਨੂੰ ਕਹਿੰਦੇ ਹਨ ਟਾਈਪੋਮੀਟਰ, ਜਿਸਨੂੰ ਮੈਂ ਟਰਮੀਨਲ ਇਮੂਲੇਟਰਾਂ ਵਿੱਚ ਪਿੰਗ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਵਰਤਿਆ ਸੀ। ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ ਕਿ ਟੈਸਟ ਸਿਮੂਲੇਸ਼ਨ ਮੋਡ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਸੀ: ਅਸਲ ਵਿੱਚ, ਸਾਨੂੰ ਇਨਪੁਟ (ਕੀਬੋਰਡ, USB ਕੰਟਰੋਲਰ, ਆਦਿ) ਅਤੇ ਆਉਟਪੁੱਟ (ਵੀਡੀਓ ਕਾਰਡ ਬਫਰ, ਮਾਨੀਟਰ) ਲੇਟੈਂਸੀ ਦੋਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ। ਫੈਟੀਨ ਦੇ ਅਨੁਸਾਰ, ਆਮ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਇਹ ਲਗਭਗ 20 ਐਮ.ਐਸ. ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਗੇਮਿੰਗ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ 3 ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਇਹ ਅੰਕੜਾ ਹਾਸਲ ਕਰ ਸਕਦੇ ਹੋ। ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੰਨਾ ਤੇਜ਼ ਹਾਰਡਵੇਅਰ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਆਪਣੀ ਲੇਟੈਂਸੀ ਜੋੜਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਫੈਟਿਨ ਦਾ ਟੀਚਾ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਲੇਟੈਂਸੀ ਨੂੰ 1 ਮਿਲੀਸਕਿੰਟ ਤੱਕ ਲਿਆਉਣਾ ਹੈ, ਜਾਂ ਬਿਨਾਂ ਡਾਇਲਿੰਗ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ ਮਾਪਣਯੋਗ ਦੇਰੀਦੇ ਰੂਪ ਵਿੱਚ ਇੰਟੈਲੀਜ ਆਈਡੀਆ 15.

ਇਹ ਦਰਸਾਉਣ ਲਈ ਕਿ ਮੇਰਾ ਪ੍ਰਯੋਗ ਉਸਦੇ ਟੈਸਟਾਂ ਨਾਲ ਸਹਿਮਤ ਹੈ, ਮੇਰੇ ਮਾਪਾਂ ਦੇ ਨਤੀਜੇ, ਅਤੇ ਨਾਲ ਹੀ ਫੈਟਿਨ ਦੇ ਕੁਝ ਨਤੀਜੇ ਹਨ:

ਪਹਿਲੀ ਚੀਜ਼ ਜਿਸਨੇ ਮੈਨੂੰ ਮਾਰਿਆ ਉਹ ਪੁਰਾਣੇ ਪ੍ਰੋਗਰਾਮਾਂ ਜਿਵੇਂ ਕਿ xterm ਅਤੇ mlterm ਦਾ ਬਿਹਤਰ ਜਵਾਬ ਸਮਾਂ ਸੀ। ਸਭ ਤੋਂ ਖਰਾਬ ਰਜਿਸਟਰ ਲੇਟੈਂਸੀ (2,4 ms) ਦੇ ਨਾਲ, ਉਹਨਾਂ ਨੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਆਧੁਨਿਕ ਟਰਮੀਨਲ (ਸਟ ਲਈ 10,6 ms) ਨਾਲੋਂ ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ। ਕੋਈ ਵੀ ਆਧੁਨਿਕ ਟਰਮੀਨਲ 10 ਮਿਲੀਸਕਿੰਟ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਹੇਠਾਂ ਨਹੀਂ ਆਉਂਦਾ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਅਲਾਕ੍ਰਿਟੀ "ਸਭ ਤੋਂ ਤੇਜ਼ ਟਰਮੀਨਲ ਇਮੂਲੇਟਰ ਉਪਲਬਧ" ਦਾਅਵੇ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦੀ ਹੈ, ਹਾਲਾਂਕਿ 2017 ਵਿੱਚ ਇਸਦੀ ਪਹਿਲੀ ਸਮੀਖਿਆ ਤੋਂ ਬਾਅਦ ਇਸਦੇ ਸਕੋਰ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ ਹੈ। ਦਰਅਸਲ, ਪ੍ਰੋਜੈਕਟ ਦੇ ਲੇਖਕ ਸਥਿਤੀ ਤੋਂ ਜਾਣੂ ਹੈ ਅਤੇ ਡਿਸਪਲੇ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਕੰਮ ਕਰ ਰਹੇ ਹਨ। ਇਹ ਵੀ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ GTK3 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ Vim ਇਸਦੇ GTK2 ਹਮਰੁਤਬਾ ਨਾਲੋਂ ਹੌਲੀ ਤੀਬਰਤਾ ਦਾ ਕ੍ਰਮ ਹੈ। ਇਸ ਤੋਂ ਅਸੀਂ ਇਹ ਸਿੱਟਾ ਕੱਢ ਸਕਦੇ ਹਾਂ ਕਿ GTK3 ਵਾਧੂ ਲੇਟੈਂਸੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਹੋਰ ਸਾਰੇ ਟਰਮੀਨਲਾਂ (ਟਰਮੀਨੇਟਰ, Xfce4 ਟਰਮੀਨਲ ਅਤੇ ਗਨੋਮ ਟਰਮੀਨਲ) ਵਿੱਚ ਪ੍ਰਤੀਬਿੰਬਿਤ ਹੁੰਦਾ ਹੈ।

ਹਾਲਾਂਕਿ, ਅੰਤਰ ਅੱਖਾਂ ਨੂੰ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ. ਜਿਵੇਂ ਕਿ ਫੈਟਿਨ ਸਮਝਾਉਂਦਾ ਹੈ, "ਤੁਹਾਨੂੰ ਤੁਹਾਡੇ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਣ ਲਈ ਦੇਰੀ ਬਾਰੇ ਸੁਚੇਤ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।" ਫੈਟੀਨ ਮਿਆਰੀ ਭਟਕਣ ਬਾਰੇ ਵੀ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ: "ਲੇਟੈਂਸੀ (ਜਿੱਟਰ) ਵਿੱਚ ਕੋਈ ਵੀ ਵਿਘਨ ਉਹਨਾਂ ਦੀ ਅਨਿਸ਼ਚਿਤਤਾ ਦੇ ਕਾਰਨ ਵਾਧੂ ਤਣਾਅ ਪੈਦਾ ਕਰਦਾ ਹੈ।"

ਉਪਰੋਕਤ ਗ੍ਰਾਫ਼ ਸ਼ੁੱਧ ਡੇਬੀਅਨ 9 (ਖਿੱਚ) ਨਾਲ ਲਿਆ ਗਿਆ ਹੈ i3 ਵਿੰਡੋ ਮੈਨੇਜਰ. ਇਹ ਵਾਤਾਵਰਣ ਲੇਟੈਂਸੀ ਟੈਸਟਾਂ ਵਿੱਚ ਵਧੀਆ ਨਤੀਜੇ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ, ਗਨੋਮ ਸਾਰੇ ਮਾਪਾਂ ਲਈ ਇੱਕ ਵਾਧੂ 20 ms ਪਿੰਗ ਬਣਾਉਂਦਾ ਹੈ। ਇਸਦੇ ਲਈ ਇੱਕ ਸੰਭਾਵਿਤ ਵਿਆਖਿਆ ਇਨਪੁਟ ਇਵੈਂਟਸ ਦੀ ਸਮਕਾਲੀ ਪ੍ਰੋਸੈਸਿੰਗ ਵਾਲੇ ਪ੍ਰੋਗਰਾਮਾਂ ਦੀ ਮੌਜੂਦਗੀ ਹੈ। ਫੈਟਿਨ ਅਜਿਹੇ ਮਾਮਲੇ ਲਈ ਇੱਕ ਉਦਾਹਰਣ ਦਿੰਦਾ ਹੈ ਵਰਕਰਾਵ, ਜੋ ਸਾਰੀਆਂ ਇਨਪੁਟ ਇਵੈਂਟਾਂ ਨੂੰ ਸਮਕਾਲੀ ਰੂਪ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕਰਕੇ ਇੱਕ ਦੇਰੀ ਜੋੜਦਾ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ, ਗਨੋਮ ਇੱਕ ਵਿੰਡੋ ਮੈਨੇਜਰ ਨਾਲ ਵੀ ਆਉਂਦਾ ਹੈ ਮੰਟਰ, ਜੋ ਬਫਰਿੰਗ ਦੀ ਇੱਕ ਵਾਧੂ ਪਰਤ ਬਣਾਉਂਦੀ ਹੈ, ਜੋ ਪਿੰਗ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ ਅਤੇ ਘੱਟੋ-ਘੱਟ 8 ਮਿਲੀਸਕਿੰਟ ਲੇਟੈਂਸੀ ਜੋੜਦੀ ਹੈ।

ਸਕ੍ਰੌਲ ਸਪੀਡ

ਅਗਲਾ ਟੈਸਟ ਇੱਕ ਪਰੰਪਰਾਗਤ "ਸਪੀਡ" ਜਾਂ "ਬੈਂਡਵਿਡਥ" ਟੈਸਟ ਹੈ, ਜੋ ਮਾਪਦਾ ਹੈ ਕਿ ਸਕ੍ਰੀਨ 'ਤੇ ਟੈਕਸਟ ਦੀ ਵੱਡੀ ਮਾਤਰਾ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਹੋਏ ਟਰਮੀਨਲ ਕਿੰਨੀ ਜਲਦੀ ਇੱਕ ਪੰਨੇ ਨੂੰ ਸਕ੍ਰੋਲ ਕਰ ਸਕਦਾ ਹੈ। ਟੈਸਟ ਦੇ ਮਕੈਨਿਕਸ ਵੱਖੋ-ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ; ਅਸਲ ਟੈਸਟ ਸਿਰਫ਼ seq ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕੋ ਟੈਕਸਟ ਸਤਰ ਬਣਾਉਣਾ ਸੀ। ਹੋਰ ਟੈਸਟਾਂ ਵਿੱਚ ਥਾਮਸ ਈ. ਡਿਕੀਜ਼ (ਐਕਸਟਰਮ ਮੇਨਟੇਨਰ) ਟੈਸਟ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਜੋ ਵਾਰ-ਵਾਰ ਹੁੰਦਾ ਹੈ terminfo.src ਫਾਈਲ ਡਾਊਨਲੋਡ ਕੀਤੀ ਗਈ ਹੈ. ਟਰਮੀਨਲ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਇੱਕ ਹੋਰ ਸਮੀਖਿਆ ਵਿੱਚ ਡੇਨ ਲੂ ਬੇਸ 32 ਇੰਕੋਡਡ ਸਟ੍ਰਿੰਗ ਬੇਤਰਤੀਬ ਬਾਈਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਕੈਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਟਰਮੀਨਲ ਲਈ ਆਉਟਪੁੱਟ ਹੈ। Luu ਅਜਿਹੇ ਟੈਸਟ ਨੂੰ "ਉਨਾ ਹੀ ਬੇਕਾਰ ਬੈਂਚਮਾਰਕ ਜਿੰਨਾ ਕੋਈ ਕਲਪਨਾ ਕਰ ਸਕਦਾ ਹੈ" ਮੰਨਦਾ ਹੈ ਅਤੇ ਇਸਦੀ ਬਜਾਏ ਟਰਮੀਨਲ ਜਵਾਬ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕ ਵਜੋਂ ਵਰਤਣ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ। ਡਿਕੀ ਵੀ ਆਪਣੇ ਟੈਸਟ ਨੂੰ ਗੁੰਮਰਾਹਕੁੰਨ ਦੱਸਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਦੋਵੇਂ ਲੇਖਕ ਮੰਨਦੇ ਹਨ ਕਿ ਟਰਮੀਨਲ ਵਿੰਡੋ ਬੈਂਡਵਿਡਥ ਇੱਕ ਮੁੱਦਾ ਹੋ ਸਕਦਾ ਹੈ। ਲੂ ਨੇ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਸਮੇਂ Emacs Eshell ਫ੍ਰੀਜ਼ਿੰਗ ਦੀ ਖੋਜ ਕੀਤੀ, ਅਤੇ ਡਿਕੀ ਨੇ xtrerm ਦੀ ਵਿਜ਼ੂਅਲ ਸੁਸਤਤਾ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਲਈ ਟਰਮੀਨਲ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਇਆ। ਇਸ ਲਈ ਇਸ ਟੈਸਟ ਲਈ ਅਜੇ ਵੀ ਕੁਝ ਯੋਗਤਾ ਹੈ, ਪਰ ਕਿਉਂਕਿ ਰੈਂਡਰਿੰਗ ਪ੍ਰਕਿਰਿਆ ਟਰਮੀਨਲ ਤੋਂ ਟਰਮੀਨਲ ਤੱਕ ਬਹੁਤ ਵੱਖਰੀ ਹੈ, ਇਸ ਨੂੰ ਹੋਰ ਮਾਪਦੰਡਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਟੈਸਟ ਕੰਪੋਨੈਂਟ ਵਜੋਂ ਵੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਥੇ ਅਸੀਂ ਮੁਕਾਬਲੇ ਤੋਂ ਅੱਗੇ rxvt ਅਤੇ st ਪੁੱਲ ਦੇਖਦੇ ਹਾਂ, ਇਸ ਤੋਂ ਬਾਅਦ ਬਹੁਤ ਨਵੀਂ ਅਲਾਕ੍ਰਿਟੀ, ਜਿਸ ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਤ ਕਰਕੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਅੱਗੇ Xfce (VTE ਪਰਿਵਾਰ) ਅਤੇ ਕੋਨਸੋਲ ਹਨ, ਜੋ ਲਗਭਗ ਦੁੱਗਣੇ ਤੇਜ਼ ਹਨ। ਆਖਰੀ ਹੈ xterm, ਜੋ ਕਿ rxvt ਨਾਲੋਂ ਪੰਜ ਗੁਣਾ ਹੌਲੀ ਹੈ। ਟੈਸਟ ਦੇ ਦੌਰਾਨ, xterm ਨੇ ਵੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਰਿਪਬਲ ਕੀਤਾ, ਟੈਕਸਟ ਨੂੰ ਪਾਸ ਕਰਨਾ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ ਭਾਵੇਂ ਇਹ ਇੱਕੋ ਲਾਈਨ ਸੀ। ਕੋਨਸੋਲ ਤੇਜ਼ ਸੀ, ਪਰ ਇਹ ਕਈ ਵਾਰ ਔਖਾ ਸੀ: ਡਿਸਪਲੇਅ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਫ੍ਰੀਜ਼ ਹੋ ਜਾਂਦੀ ਸੀ, ਅੰਸ਼ਕ ਟੈਕਸਟ ਦਿਖਾਉਂਦੀ ਸੀ ਜਾਂ ਬਿਲਕੁਲ ਨਹੀਂ ਦਿਖਾਉਂਦੀ ਸੀ। ਹੋਰ ਟਰਮੀਨਲ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸਤਰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ st, Alacritty, ਅਤੇ rxvt ਸ਼ਾਮਲ ਹਨ।

ਡਿਕੀ ਦੱਸਦਾ ਹੈ ਕਿ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਅੰਤਰ ਵੱਖ-ਵੱਖ ਟਰਮੀਨਲਾਂ ਵਿੱਚ ਸਕ੍ਰੌਲ ਬਫਰਾਂ ਦੇ ਡਿਜ਼ਾਈਨ ਕਾਰਨ ਹਨ। ਖਾਸ ਤੌਰ 'ਤੇ, ਉਹ rxvt ਅਤੇ ਹੋਰ ਟਰਮੀਨਲਾਂ 'ਤੇ "ਆਮ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਨਾ ਕਰਨ" ਦਾ ਦੋਸ਼ ਲਗਾਉਂਦਾ ਹੈ:

"xterm ਦੇ ਉਲਟ, rxvt ਨੇ ਸਾਰੇ ਅੱਪਡੇਟ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕੀਤੀ। ਜੇ ਇਹ ਪਿੱਛੇ ਪੈ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਫੜਨ ਲਈ ਕੁਝ ਅਪਡੇਟਾਂ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦੇਵੇਗਾ. ਇਸ ਦਾ ਅੰਦਰੂਨੀ ਮੈਮੋਰੀ ਸੰਗਠਨ ਨਾਲੋਂ ਸਪੱਸ਼ਟ ਸਕ੍ਰੌਲਿੰਗ ਸਪੀਡ 'ਤੇ ਵਧੇਰੇ ਪ੍ਰਭਾਵ ਸੀ। ਇੱਕ ਕਮੀ ਇਹ ਸੀ ਕਿ ASCII ਐਨੀਮੇਸ਼ਨ ਕੁਝ ਹੱਦ ਤੱਕ ਅਸ਼ੁੱਧ ਸੀ।"

ਇਸ ਅਨੁਭਵੀ xterm ਸੁਸਤਤਾ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, ਡਿਕੀ ਸਰੋਤ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਤੇਜ਼ ਸਕਰੋਲ, ਵਹਾਅ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਲਈ xterm ਨੂੰ ਕੁਝ ਸਕ੍ਰੀਨ ਅੱਪਡੇਟ ਰੱਦ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਮੇਰੇ ਟੈਸਟ ਇਸ ਗੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ ਕਿ fastScroll ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ ਅਤੇ xterm ਨੂੰ rxvt ਦੇ ਬਰਾਬਰ ਲਿਆਉਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਇੱਕ ਮੋਟਾ ਕਰੈਚ ਹੈ, ਜਿਵੇਂ ਕਿ ਡਿਕੀ ਖੁਦ ਦੱਸਦਾ ਹੈ: "ਕਈ ਵਾਰ ਐਕਸਟਰਮ - ਜਿਵੇਂ ਕਿ ਕੋਨਸੋਲ - ਰੁਕ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕੁਝ ਹਟਾਏ ਜਾਣ ਤੋਂ ਬਾਅਦ ਸਕ੍ਰੀਨ ਅਪਡੇਟਾਂ ਦੇ ਇੱਕ ਨਵੇਂ ਸੈੱਟ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ।" ਇਸ ਨਾੜੀ ਵਿੱਚ, ਇਹ ਲਗਦਾ ਹੈ ਕਿ ਹੋਰ ਟਰਮੀਨਲਾਂ ਨੇ ਗਤੀ ਅਤੇ ਡਿਸਪਲੇ ਦੀ ਇਕਸਾਰਤਾ ਵਿਚਕਾਰ ਸਭ ਤੋਂ ਵਧੀਆ ਸਮਝੌਤਾ ਪਾਇਆ ਹੈ.

ਸਰੋਤ ਦੀ ਖਪਤ

ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਕਿ ਸਕ੍ਰੋਲਿੰਗ ਸਪੀਡ ਨੂੰ ਇੱਕ ਪ੍ਰਦਰਸ਼ਨ ਮੈਟ੍ਰਿਕ ਦੇ ਤੌਰ 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਸਮਝਦਾਰ ਹੈ, ਇਹ ਟੈਸਟ ਸਾਨੂੰ ਟਰਮੀਨਲਾਂ 'ਤੇ ਲੋਡ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜੋ ਬਦਲੇ ਵਿੱਚ ਸਾਨੂੰ ਹੋਰ ਮਾਪਦੰਡਾਂ ਜਿਵੇਂ ਕਿ ਮੈਮੋਰੀ ਜਾਂ ਡਿਸਕ ਦੀ ਵਰਤੋਂ ਨੂੰ ਮਾਪਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਮੈਟ੍ਰਿਕਸ ਨਿਰਧਾਰਤ ਟੈਸਟ ਚਲਾ ਕੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਸਨ seq ਪਾਈਥਨ ਪ੍ਰਕਿਰਿਆ ਦੀ ਨਿਗਰਾਨੀ ਅਧੀਨ. ਉਸਨੇ ਮੀਟਰ ਦਾ ਡਾਟਾ ਇਕੱਠਾ ਕੀਤਾ getrusage() ਨੂੰ 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 ਲੈਂਦਾ ਹੈ, ਜੋ ਕਿ ਪਹਿਲਾਂ ਨਾਲੋਂ ਤਿੰਨ ਗੁਣਾ ਵੱਡਾ ਹੈ, ਪਰ ਗਨੋਮ ਟਰਮੀਨਲ ਲਈ ਸਿਰਫ਼ 20 MB ਦੀ ਲੋੜ ਹੈ। ਬੇਸ਼ੱਕ, ਸਾਰੇ ਪਿਛਲੇ ਟੈਸਟ 32-ਬਿੱਟ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਕੀਤੇ ਗਏ ਸਨ। LCA 2012 'ਤੇ Rusty Russell ਮੈਨੂੰ ਦੱਸਿਆ, ਕਿ ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਹੋਰ ਸੂਖਮ ਕਾਰਨ ਹਨ ਜੋ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਵਿੱਚ ਵਾਧੇ ਦੀ ਵਿਆਖਿਆ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਕਹਿਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਹੁਣ ਅਜਿਹੇ ਸਮੇਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਾਂ ਜਿੱਥੇ ਸਾਡੇ ਕੋਲ ਗੀਗਾਬਾਈਟ ਮੈਮੋਰੀ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਪ੍ਰਬੰਧਿਤ ਕਰਾਂਗੇ।

ਹਾਲਾਂਕਿ, ਮੈਂ ਮਦਦ ਨਹੀਂ ਕਰ ਸਕਦਾ ਪਰ ਮਹਿਸੂਸ ਕਰ ਸਕਦਾ ਹਾਂ ਕਿ ਟਰਮੀਨਲ ਵਾਂਗ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਹੋਰ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕਰਨਾ ਸਰੋਤਾਂ ਦੀ ਬਰਬਾਦੀ ਹੈ। ਇਹ ਪ੍ਰੋਗਰਾਮ ਸਭ ਤੋਂ ਛੋਟੇ ਤੋਂ ਛੋਟੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਕਿਸੇ ਵੀ "ਬਾਕਸ" 'ਤੇ ਚੱਲਣ ਦੇ ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਜੁੱਤੀਬਾਕਸ, ਜੇਕਰ ਅਸੀਂ ਕਦੇ ਉਸ ਬਿੰਦੂ 'ਤੇ ਆਉਂਦੇ ਹਾਂ ਜਿੱਥੇ ਉਹਨਾਂ ਨੂੰ ਲੀਨਕਸ ਸਿਸਟਮਾਂ ਨਾਲ ਲੈਸ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ (ਅਤੇ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਅਜਿਹਾ ਹੋਵੇਗਾ. ) . ਪਰ ਇਹਨਾਂ ਸੰਖਿਆਵਾਂ ਦੇ ਨਾਲ, ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਭਵਿੱਖ ਵਿੱਚ ਕਿਸੇ ਵੀ ਵਾਤਾਵਰਣ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਬਣ ਜਾਵੇਗੀ, ਜੋ ਕਿ ਕੁਝ ਸਭ ਤੋਂ ਹਲਕੇ ਅਤੇ ਸਭ ਤੋਂ ਸੀਮਤ ਸਮਰੱਥਾਵਾਂ ਤੋਂ ਇਲਾਵਾ ਮਲਟੀਪਲ ਟਰਮੀਨਲ ਚਲਾ ਰਹੇ ਹਨ। ਇਸਦੀ ਭਰਪਾਈ ਕਰਨ ਲਈ, ਗਨੋਮ ਟਰਮੀਨਲ, ਕੋਨਸੋਲ, urxvt, ਟਰਮੀਨੇਟਰ ਅਤੇ Xfce ਟਰਮੀਨਲ ਵਿੱਚ ਇੱਕ ਡੈਮਨ ਮੋਡ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਦੀ ਮੈਮੋਰੀ ਖਪਤ ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹੋਏ, ਇੱਕ ਸਿੰਗਲ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਕਈ ਟਰਮੀਨਲਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

ਮੇਰੇ ਟੈਸਟਾਂ ਦੇ ਦੌਰਾਨ, ਮੈਂ ਡਿਸਕ ਰੀਡ-ਰਾਈਟ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਇੱਕ ਹੋਰ ਅਚਾਨਕ ਨਤੀਜੇ 'ਤੇ ਆਇਆ: ਮੈਨੂੰ ਇੱਥੇ ਕੁਝ ਵੀ ਨਹੀਂ ਦੇਖਣ ਦੀ ਉਮੀਦ ਸੀ, ਪਰ ਇਹ ਸਾਹਮਣੇ ਆਇਆ ਕਿ ਕੁਝ ਟਰਮੀਨਲ ਡਿਸਕ 'ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਡਾਟਾ ਲਿਖਦੇ ਹਨ। ਇਸ ਲਈ, VTE ਲਾਇਬ੍ਰੇਰੀ ਅਸਲ ਵਿੱਚ ਡਿਸਕ ਉੱਤੇ ਇੱਕ ਸਕ੍ਰੌਲ ਬਫਰ ਰੱਖਦੀ ਹੈ (ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ 2010 ਵਿੱਚ ਵਾਪਸ ਦੇਖਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਇਹ ਅਜੇ ਵੀ ਹੋ ਰਿਹਾ ਹੈ). ਪਰ ਪੁਰਾਣੇ ਲਾਗੂਕਰਨਾਂ ਦੇ ਉਲਟ, ਹੁਣ ਘੱਟੋ-ਘੱਟ ਇਸ ਡੇਟਾ ਨੂੰ AES256 GCM ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਗਿਆ ਹੈ (ਸੰਸਕਰਣ 0.39.2 ਤੋਂ). ਪਰ ਇੱਕ ਵਾਜਬ ਸਵਾਲ ਉੱਠਦਾ ਹੈ: VTE ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਇੰਨਾ ਖਾਸ ਕੀ ਹੈ ਕਿ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਅਜਿਹੀ ਗੈਰ-ਮਿਆਰੀ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੈ ...

ਸਿੱਟਾ

ਲੇਖ ਦੇ ਪਹਿਲੇ ਹਿੱਸੇ ਵਿੱਚ, ਅਸੀਂ ਪਾਇਆ ਕਿ VTE- ਅਧਾਰਤ ਟਰਮੀਨਲਾਂ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਇੱਕ ਵਧੀਆ ਸੈੱਟ ਹੈ, ਪਰ ਹੁਣ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਇਹ ਕੁਝ ਪ੍ਰਦਰਸ਼ਨ ਲਾਗਤਾਂ ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ। ਹੁਣ ਮੈਮੋਰੀ ਕੋਈ ਮੁੱਦਾ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਸਾਰੇ VTE ਟਰਮੀਨਲਾਂ ਨੂੰ ਡੈਮਨ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜੋ ਉਹਨਾਂ ਦੀ ਭੁੱਖ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਪੁਰਾਣੇ ਸਿਸਟਮ ਜਿਨ੍ਹਾਂ ਦੀ RAM ਅਤੇ ਕਰਨਲ ਬਫਰਾਂ ਦੀ ਮਾਤਰਾ 'ਤੇ ਭੌਤਿਕ ਸੀਮਾਵਾਂ ਹਨ, ਨੂੰ ਅਜੇ ਵੀ ਟਰਮੀਨਲਾਂ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਬਹੁਤ ਘੱਟ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਹਾਲਾਂਕਿ VTE ਟਰਮੀਨਲਾਂ ਨੇ ਥਰੂਪੁੱਟ (ਸਕ੍ਰੌਲਿੰਗ) ਟੈਸਟਾਂ ਵਿੱਚ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ, ਉਹਨਾਂ ਦੀ ਡਿਸਪਲੇਅ ਲੇਟੈਂਸੀ ਗਨੋਮ ਉਪਭੋਗਤਾ ਗਾਈਡ ਵਿੱਚ ਨਿਰਧਾਰਤ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਉੱਪਰ ਹੈ। VTE ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸ਼ਾਇਦ ਇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਅਸੀਂ ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿਚ ਰੱਖਦੇ ਹਾਂ ਕਿ ਨਵੇਂ ਲੀਨਕਸ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਵੀ ਟਰਮੀਨਲ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਉਹ ਇਸਨੂੰ ਵਧੇਰੇ ਉਪਭੋਗਤਾ ਦੇ ਅਨੁਕੂਲ ਬਣਾ ਸਕਦੇ ਹਨ। ਤਜਰਬੇਕਾਰ ਗੀਕਸਾਂ ਲਈ, ਡਿਫੌਲਟ ਟਰਮੀਨਲ ਤੋਂ ਸਵਿਚ ਕਰਨ ਦਾ ਮਤਲਬ ਵੀ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਅੱਖਾਂ ਦਾ ਘੱਟ ਦਬਾਅ ਅਤੇ ਲੰਬੇ ਕੰਮ ਦੇ ਸੈਸ਼ਨਾਂ ਕਾਰਨ ਭਵਿੱਖ ਵਿੱਚ ਕੰਮ ਨਾਲ ਸਬੰਧਤ ਸੱਟਾਂ ਅਤੇ ਬਿਮਾਰੀਆਂ ਤੋਂ ਬਚਣ ਦੀ ਸਮਰੱਥਾ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਸਿਰਫ ਪੁਰਾਣੇ xterm ਅਤੇ mlterm ਸਾਨੂੰ 10 ਮਿਲੀਸਕਿੰਟ ਦੇ ਜਾਦੂ ਪਿੰਗ ਥ੍ਰੈਸ਼ਹੋਲਡ 'ਤੇ ਲਿਆਉਂਦੇ ਹਨ, ਜੋ ਕਿ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਲਈ ਅਸਵੀਕਾਰਨਯੋਗ ਹੈ।

ਬੈਂਚਮਾਰਕ ਮਾਪਾਂ ਨੇ ਇਹ ਵੀ ਦਿਖਾਇਆ ਕਿ ਲੀਨਕਸ ਗ੍ਰਾਫਿਕਲ ਵਾਤਾਵਰਣ ਦੇ ਵਿਕਾਸ ਦੇ ਕਾਰਨ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਸਮਝੌਤਾ ਕਰਨੇ ਪਏ। ਕੁਝ ਉਪਭੋਗਤਾ ਨਿਯਮਤ ਵਿੰਡੋ ਪ੍ਰਬੰਧਕਾਂ ਨੂੰ ਵੇਖਣਾ ਚਾਹ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਮਹੱਤਵਪੂਰਨ ਪਿੰਗ ਕਟੌਤੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਵੇਲੈਂਡ ਲਈ ਲੇਟੈਂਸੀ ਨੂੰ ਮਾਪਣਾ ਸੰਭਵ ਨਹੀਂ ਸੀ: ਮੇਰੇ ਦੁਆਰਾ ਵਰਤੇ ਗਏ ਟਾਈਪੋਮੀਟਰ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਇਸ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ ਕਿ ਵੇਲੈਂਡ ਨੂੰ ਰੋਕਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ: ਹੋਰ ਵਿੰਡੋਜ਼ 'ਤੇ ਜਾਸੂਸੀ। ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਵੇਲੈਂਡ ਕੰਪੋਜ਼ਿਟਿੰਗ X.org ਨਾਲੋਂ ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਮੈਂ ਇਹ ਵੀ ਉਮੀਦ ਕਰਦਾ ਹਾਂ ਕਿ ਭਵਿੱਖ ਵਿੱਚ ਕੋਈ ਵਿਅਕਤੀ ਇਸ ਵਾਤਾਵਰਣ ਵਿੱਚ ਲੇਟੈਂਸੀ ਨੂੰ ਮਾਪਣ ਦਾ ਤਰੀਕਾ ਲੱਭੇਗਾ।

ਸਰੋਤ: www.habr.com