ਵਰਜ਼ਨ ਸਟ੍ਰਿੰਗ VPN ਪਲੱਗਇਨ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ

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

ਵਿਕਲਪ NetworkManager ਵਿੱਚ, ਇਸਦੇ VPN ਪਲੱਗਇਨ ਵਿੱਚ, ਹੇਠਲੇ ਇੰਜਣ ਵਿੱਚ, ਜਾਂ ਵੱਖਰੇ ਡੈਸਕਟਾਪ ਫਰੰਟਐਂਡ ਵਿੱਚ ਰਹਿ ਸਕਦਾ ਹੈ। ਇਹ ਚਾਰ ਪ੍ਰੋਜੈਕਟ ਹਨ, ਚਾਰ ਰਿਲੀਜ਼ ਇਤਿਹਾਸਾਂ ਨਾਲ।

ਚਾਰ ਹਿੱਸੇ, ਚਾਰ ਰਿਲੀਜ਼ ਇਤਿਹਾਸ

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

ਲੱਛਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਖੇਤਰ ਡਾਇਲਾਗ ਤੋਂ ਗੁੰਮ ਹੈ, ਆਯਾਤ ਤੋਂ ਬਾਅਦ ਗੈਰਹਾਜ਼ਰ ਹੈ, ਜਾਂ ਮੌਜੂਦ ਹੈ ਪਰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ? ਉਹ ਨਿਰੀਖਣ ਵੱਖਰੇ ਹਿੱਸਿਆਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ ਅਤੇ ਵੱਖਰੇ ਸਬੂਤ ਮੰਗਦੇ ਹਨ।

ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵਰਜ਼ਨ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ

Debian ਦੀ ਪੈਕੇਜ ਨੀਤੀ ਫਾਰਮੈਟ ਨੂੰ epoch, upstream ਵਰਜ਼ਨ ਅਤੇ ਪੈਕੇਜਿੰਗ revision ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀ ਹੈ। ਪਹਿਲਾਂ epoch, ਫਿਰ upstream ਭਾਗ, ਫਿਰ revision ਦੀ ਤੁਲਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪੈਕੇਜ ਮੈਨੇਜਰ ਦੇ ਆਪਣੇ ਕ੍ਰਮ ਨਿਯਮਾਂ ਅਨੁਸਾਰ, ਦਸ਼ਮਲਵ ਗਣਿਤ ਜਾਂ ਸਧਾਰਨ ਵਰਣਮਾਲਾ ਕ੍ਰਮ ਨਾਲ ਨਹੀਂ। ਟਿਲਡਾ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕ੍ਰਮਬੱਧ ਹੁੰਦਾ ਹੈ, ਉਸ ਭਾਗ ਦੇ ਅੰਤ ਸਮੇਤ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਰਿਲੀਜ਼ ਉਮੀਦਵਾਰ ਅੰਤਿਮ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ। ਭਾਗਾਂ ਨੂੰ ਵੱਖਰਾ ਪੜ੍ਹਨਾ ਹੀ ਤੁਲਨਾ ਨੂੰ ਅਰਥਪੂਰਨ ਬਣਾਉਂਦਾ ਹੈ।

0.8.999 ਨੂੰ 0.9 ਦੇ ਨੇੜੇ ਦਿਖਣ ਵਾਲੀ ਕਿਸੇ ਹੋਰ ਸਕੀਮ ਲਈ ਬਦਲਣ ਦਾ ਨਿਯਮ ਨਾ ਘੜੋ। ਅੰਕਾਂ ਦੀ ਨੇੜਤਾ ਸਮੱਗਰੀ ਬਾਰੇ ਸਬੂਤ ਨਹੀਂ ਹੈ।

ਪੁੱਛੋ ਕਿ ਕੀ ਸਥਾਪਿਤ ਹੈ ਅਤੇ ਕੀ ਹੋਵੇਗਾ

apt-cache policy ਤੁਹਾਡੇ ਵੱਲੋਂ ਨਾਮ ਦਿੱਤੇ ਹਰ ਪੈਕੇਜ ਲਈ ਸਥਾਪਿਤ ਵਰਜ਼ਨ, ਉਮੀਦਵਾਰ ਅਤੇ ਹਰ ਇੱਕ ਕਿਹੜੀ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਇੰਜਣ ਅਤੇ ਪਲੱਗਇਨ ਦੋਵਾਂ ਲਈ ਪੜ੍ਹੋ, ਅਤੇ ਸੰਖੇਪ ਰੂਪਾਂ ਦੀ ਬਜਾਏ ਪੂਰੀਆਂ ਸਟ੍ਰਿੰਗਾਂ ਦਰਜ ਕਰੋ। ਸਥਾਨਕ ਮੈਟਾਡੇਟਾ ਪੁਰਾਣਾ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਮੀਦਵਾਰ ਵਰਜ਼ਨ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਨੇ ਉਹ ਬਿਲਡ ਲੋਡ ਕੀਤਾ ਹੈ। ਜੇ ਅਪਗ੍ਰੇਡ ਤੋਂ ਬਾਅਦ ਸੇਵਾ ਮੁੜ ਸ਼ੁਰੂ ਨਹੀਂ ਕੀਤੀ ਗਈ, ਤਾਂ ਡਿਸਕ ਉੱਤੇ ਫਾਇਲ ਅਤੇ ਤੁਹਾਡੇ ਵੱਲੋਂ ਦੇਖਿਆ ਵਿਵਹਾਰ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ।

ਫਿਰ ਮੇਲ ਖਾਂਦਾ ਤਬਦੀਲੀ ਲਾਗ ਪੜ੍ਹੋ। ਪੈਕੇਜਿੰਗ revision ਨਵਾਂ upstream ਨੰਬਰ ਅਪਣਾਏ ਬਿਨਾਂ ਪੈਚ ਲੈ ਕੇ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਬਿਲਕੁਲ ਉਹੀ ਸਥਿਤੀ ਹੈ ਜਿੱਥੇ ਵਰਜ਼ਨ ਅਟੱਲ ਦਿਸਦਾ ਹੈ ਅਤੇ ਵਿਵਹਾਰ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।

ਵਿਕਲਪ ਨੂੰ ਮਾਲਕ ਹਿੱਸੇ ਵਿੱਚ ਸਾਬਤ ਕਰੋ

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

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

ਲਾਭਦਾਇਕ ਰਿਪੋਰਟ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ, ਪੂਰੇ ਪੈਕੇਜ ਵਰਜ਼ਨ, ਸਰਗਰਮ ਕਨੈਕਸ਼ਨ ਦਾ ਮਾਲਕ, ਲੋੜੀਂਦਾ ਵਿਕਲਪ ਅਤੇ ਦੇਖਿਆ ਸੰਭਾਲਿਆ ਵਿਵਹਾਰ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ। ਇਹ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਯੋਗ ਸਵਾਲ ਹੈ।