ਲੀਨਕਸ ਦੇ ਬਹੁਤ ਸਾਰੇ ਚਿਹਰੇ ਹਨ: ਕਿਸੇ ਵੀ ਵੰਡ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ

ਇੱਕ ਬੈਕਅੱਪ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣਾ ਜੋ ਕਿਸੇ ਵੀ ਵੰਡ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਕੋਈ ਆਸਾਨ ਕੰਮ ਨਹੀਂ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਲੀਨਕਸ ਲਈ ਵੀਮ ਏਜੰਟ Red Hat 6 ਅਤੇ ਡੇਬੀਅਨ 6 ਤੋਂ, OpenSUSE 15.1 ਅਤੇ Ubuntu 19.04 ਤੱਕ ਵੰਡਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਪਵੇਗਾ, ਖਾਸ ਤੌਰ 'ਤੇ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਸੌਫਟਵੇਅਰ ਉਤਪਾਦ ਵਿੱਚ ਇੱਕ ਕਰਨਲ ਮੋਡੀਊਲ ਸ਼ਾਮਲ ਹੈ।

ਲੇਖ ਕਾਨਫਰੰਸ ਵਿੱਚ ਇੱਕ ਭਾਸ਼ਣ ਤੋਂ ਸਮੱਗਰੀ ਦੇ ਅਧਾਰ ਤੇ ਬਣਾਇਆ ਗਿਆ ਸੀ ਲੀਨਕਸ ਪੀਟਰ 2019.

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

ਪੈਕੇਜ ਪ੍ਰਬੰਧਕ। .deb ਬਨਾਮ .rpm

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

ਡੇਬ ਪੈਕੇਜਾਂ ਦੀ ਦੁਨੀਆ ਵਿੱਚ, ਅਨੁਕੂਲਤਾ ਦਾ ਪੱਧਰ ਸ਼ਾਨਦਾਰ ਹੈ. ਉਹੀ ਪੈਕੇਜ ਡੇਬੀਅਨ 6 ਅਤੇ ਉਬੰਟੂ 19.04 ਦੋਵਾਂ 'ਤੇ ਇੰਸਟੌਲ ਕਰਦਾ ਹੈ ਅਤੇ ਬਰਾਬਰ ਕੰਮ ਕਰਦਾ ਹੈ। ਪੁਰਾਣੇ ਡੇਬੀਅਨ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਨਿਰਧਾਰਤ ਪੈਕੇਜਾਂ ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਮਾਪਦੰਡ, ਨਵੇਂ ਲੀਨਕਸ ਮਿੰਟ ਅਤੇ ਐਲੀਮੈਂਟਰੀ OS ਵਿੱਚ ਢੁਕਵੇਂ ਰਹਿੰਦੇ ਹਨ। ਇਸ ਲਈ, ਲੀਨਕਸ ਲਈ ਵੀਮ ਏਜੰਟ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਹਰੇਕ ਹਾਰਡਵੇਅਰ ਪਲੇਟਫਾਰਮ ਲਈ ਇੱਕ ਡੈਬ ਪੈਕੇਜ ਕਾਫੀ ਹੈ।

ਪਰ rpm ਪੈਕੇਜਾਂ ਦੀ ਦੁਨੀਆ ਵਿੱਚ, ਅੰਤਰ ਬਹੁਤ ਵਧੀਆ ਹਨ। ਪਹਿਲਾਂ, ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਇੱਥੇ ਦੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਤੰਤਰ ਵਿਤਰਕ ਹਨ, Red Hat ਅਤੇ SUSE, ਜਿਸ ਲਈ ਅਨੁਕੂਲਤਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਲੋੜੀ ਹੈ। ਦੂਜਾ, ਇਨ੍ਹਾਂ ਡਿਸਟ੍ਰੀਬਿਊਟਰਾਂ ਤੋਂ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਕਿੱਟਾਂ ਹਨ। ਸਮਰਥਨ ਅਤੇ ਪ੍ਰਯੋਗਾਤਮਕ. ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਅਨੁਕੂਲਤਾ ਦੀ ਵੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ el6, el7 ਅਤੇ el8 ਦੇ ਆਪਣੇ ਪੈਕੇਜ ਹਨ। ਫੇਡੋਰਾ ਲਈ ਵੱਖਰਾ ਪੈਕੇਜ। SLES11 ਅਤੇ 12 ਲਈ ਪੈਕੇਜ ਅਤੇ openSUSE ਲਈ ਇੱਕ ਵੱਖਰਾ। ਮੁੱਖ ਸਮੱਸਿਆ ਨਿਰਭਰਤਾ ਅਤੇ ਪੈਕੇਜ ਨਾਮ ਹੈ।

ਨਿਰਭਰਤਾ ਦੀ ਸਮੱਸਿਆ

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਉਹੀ ਪੈਕੇਜ ਅਕਸਰ ਵੱਖ-ਵੱਖ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਵੱਖੋ-ਵੱਖਰੇ ਨਾਮਾਂ ਹੇਠ ਖਤਮ ਹੁੰਦੇ ਹਨ। ਹੇਠਾਂ veeam ਪੈਕੇਜ ਨਿਰਭਰਤਾ ਦੀ ਇੱਕ ਅੰਸ਼ਕ ਸੂਚੀ ਹੈ।

EL7 ਲਈ:
SLES 12 ਲਈ:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• fuse-libs
• ਫਾਈਲ-ਲਿਬਸ
• veeamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc++6
• libmagic1
• libfuse2
• veeamsnap-kmp=3.0.2.1185

ਨਤੀਜੇ ਵਜੋਂ, ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਲਈ ਨਿਰਭਰਤਾ ਦੀ ਸੂਚੀ ਵਿਲੱਖਣ ਹੈ।

ਕੀ ਬੁਰਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਅੱਪਡੇਟ ਕੀਤਾ ਸੰਸਕਰਣ ਪੁਰਾਣੇ ਪੈਕੇਜ ਨਾਮ ਦੇ ਹੇਠਾਂ ਛੁਪਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।

ਉਦਾਹਰਨ:

ਪੈਕੇਜ ਨੂੰ ਫੇਡੋਰਾ 24 ਵਿੱਚ ਅੱਪਡੇਟ ਕੀਤਾ ਗਿਆ ਹੈ nurses ਸੰਸਕਰਣ 5 ਤੋਂ ਸੰਸਕਰਣ 6 ਤੱਕ। ਸਾਡੇ ਉਤਪਾਦ ਨੂੰ ਪੁਰਾਣੇ ਵਿਤਰਣਾਂ ਦੇ ਨਾਲ ਅਨੁਕੂਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਸੰਸਕਰਣ 5 ਨਾਲ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਫੇਡੋਰਾ 5 'ਤੇ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਪੁਰਾਣੇ 24ਵੇਂ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਮੈਨੂੰ ਪੈਕੇਜ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਈ ncurses-compat-libs.

ਨਤੀਜੇ ਵਜੋਂ, ਫੇਡੋਰਾ ਲਈ ਵੱਖ-ਵੱਖ ਨਿਰਭਰਤਾਵਾਂ ਦੇ ਨਾਲ ਦੋ ਪੈਕੇਜ ਹਨ।

ਹੋਰ ਵੀ ਦਿਲਚਸਪ. ਅਗਲੇ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ, ਪੈਕੇਜ ncurses-compat-libs ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਸੰਸਕਰਣ 5 ਦੇ ਨਾਲ ਇਹ ਅਣਉਪਲਬਧ ਸਾਬਤ ਹੁੰਦਾ ਹੈ। ਵਿਤਰਕ ਲਈ ਪੁਰਾਣੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ ਵਿੱਚ ਖਿੱਚਣਾ ਮਹਿੰਗਾ ਹੈ। ਕੁਝ ਸਮੇਂ ਬਾਅਦ, ਸਮੱਸਿਆ SUSE ਵੰਡਾਂ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨੂੰ ਦੁਹਰਾਉਂਦੀ ਹੈ।

ਨਤੀਜੇ ਵਜੋਂ, ਕੁਝ ਵੰਡਾਂ ਨੂੰ ਆਪਣੀ ਸਪੱਸ਼ਟ ਨਿਰਭਰਤਾ ਛੱਡਣੀ ਪਈ ncurses-libs, ਅਤੇ ਉਤਪਾਦ ਨੂੰ ਠੀਕ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਕਿਸੇ ਵੀ ਸੰਸਕਰਣ ਨਾਲ ਕੰਮ ਕਰ ਸਕੇ।

ਵੈਸੇ, Red Hat ਦੇ ਵਰਜਨ 8 ਵਿੱਚ ਹੁਣ ਕੋਈ ਮੈਟਾ ਪੈਕੇਜ ਨਹੀਂ ਹੈ ਪਾਇਥਨ, ਜੋ ਚੰਗੇ ਪੁਰਾਣੇ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ ਪਾਈਥਨ 2.7. ਉਥੇ ਹੈ python2 и ਪਾਇਥਨ3.

ਪੈਕੇਜ ਪ੍ਰਬੰਧਕਾਂ ਦਾ ਵਿਕਲਪ

ਨਿਰਭਰਤਾ ਦੀ ਸਮੱਸਿਆ ਪੁਰਾਣੀ ਹੈ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਸਪੱਸ਼ਟ ਹੈ। ਬਸ ਨਿਰਭਰਤਾ ਨਰਕ ਨੂੰ ਯਾਦ ਰੱਖੋ.
ਵੱਖ-ਵੱਖ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਜੋੜਨ ਲਈ ਤਾਂ ਜੋ ਉਹ ਸਾਰੀਆਂ ਸਥਿਰਤਾ ਨਾਲ ਕੰਮ ਕਰਨ ਅਤੇ ਵਿਵਾਦ ਨਾ ਹੋਣ - ਅਸਲ ਵਿੱਚ, ਇਹ ਉਹ ਕੰਮ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਵੀ ਲੀਨਕਸ ਵਿਤਰਕ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।

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

ਫਲੈਟਪੈਕ ਤੁਹਾਨੂੰ ਲੀਨਕਸ ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸੈਂਡਬੌਕਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਚਲਾਉਣ ਦੀ ਵੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਸੈਂਡਬੌਕਸ ਵਿਚਾਰ ਵੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ AppImage.

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

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

ਦੂਜੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ Red Hat ਅਤੇ SUSE ਤੋਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਾਤਾਵਰਣ ਵਿੱਚ ਪ੍ਰਸਿੱਧ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਅਜੇ ਸਨੈਪੀ ਅਤੇ ਫਲੈਟਪੈਕ ਲਈ ਸਮਰਥਨ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ।

ਇਸ ਸਬੰਧ ਵਿੱਚ, ਲੀਨਕਸ ਲਈ ਵੀਮ ਏਜੰਟ ਉਪਲਬਧ ਨਹੀਂ ਹੈ snapraft.io ਚਾਲੂ ਨਹੀਂ flathub.org.

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

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

ਅੱਪਡੇਟ ਸਮੱਸਿਆ

ਭਾਵੇਂ ਸਾਰੇ ਨਿਰਭਰਤਾ ਮੁੱਦੇ ਹੱਲ ਹੋ ਜਾਣ, ਪਰੋਗਰਾਮ ਇੱਕੋ ਡਿਸਟਰੀਬਿਊਸ਼ਨ 'ਤੇ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਚੱਲ ਸਕਦਾ ਹੈ। ਇਹ ਅੱਪਡੇਟ ਦੀ ਗੱਲ ਹੈ.

ਇੱਥੇ 3 ਅੱਪਡੇਟ ਰਣਨੀਤੀਆਂ ਹਨ:

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

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

ਹਾਰਡਵੇਅਰ ਪਲੇਟਫਾਰਮਾਂ ਦੀਆਂ ਕਈ ਕਿਸਮਾਂ

ਵੱਖ-ਵੱਖ ਹਾਰਡਵੇਅਰ ਪਲੇਟਫਾਰਮ ਇੱਕ ਸਮੱਸਿਆ ਹੈ ਜੋ ਕਿ ਮੂਲ ਕੋਡ ਲਈ ਖਾਸ ਹੈ। ਘੱਟੋ-ਘੱਟ, ਤੁਹਾਨੂੰ ਹਰੇਕ ਸਮਰਥਿਤ ਪਲੇਟਫਾਰਮ ਲਈ ਬਾਈਨਰੀਆਂ ਇਕੱਠੀਆਂ ਕਰਨੀਆਂ ਪੈਣਗੀਆਂ।

ਲੀਨਕਸ ਪ੍ਰੋਜੈਕਟ ਲਈ ਵੀਮ ਏਜੰਟ ਵਿੱਚ, ਅਸੀਂ ਅਜੇ ਵੀ ਇਸ RISC ਵਰਗੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਾਂ।

ਮੈਂ ਇਸ ਮੁੱਦੇ 'ਤੇ ਵਿਸਥਾਰ ਨਾਲ ਨਹੀਂ ਬੋਲਾਂਗਾ। ਮੈਂ ਸਿਰਫ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦੇਵਾਂਗਾ: ਪਲੇਟਫਾਰਮ-ਨਿਰਭਰ ਕਿਸਮਾਂ, ਜਿਵੇਂ ਕਿ size_t, ਬਣਤਰ ਅਲਾਈਨਮੈਂਟ ਅਤੇ ਬਾਈਟ ਆਰਡਰ।

ਸਥਿਰ ਅਤੇ/ਜਾਂ ਗਤੀਸ਼ੀਲ ਲਿੰਕਿੰਗ

ਪਰ ਸਵਾਲ ਇਹ ਹੈ ਕਿ "ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਾਲ ਕਿਵੇਂ ਲਿੰਕ ਕਰਨਾ ਹੈ - ਗਤੀਸ਼ੀਲ ਜਾਂ ਸਥਿਰ ਤੌਰ 'ਤੇ?" ਚਰਚਾ ਕਰਨ ਯੋਗ।

ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਲੀਨਕਸ ਦੇ ਅਧੀਨ C/C++ ਐਪਲੀਕੇਸ਼ਨਾਂ ਡਾਇਨਾਮਿਕ ਲਿੰਕਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਖਾਸ ਤੌਰ 'ਤੇ ਕਿਸੇ ਖਾਸ ਵੰਡ ਲਈ ਬਣਾਈ ਗਈ ਹੈ।

ਜੇਕਰ ਕੰਮ ਇੱਕ ਬਾਈਨਰੀ ਫਾਈਲ ਨਾਲ ਵੱਖ-ਵੱਖ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਨੂੰ ਕਵਰ ਕਰਨਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਪੁਰਾਣੀ ਸਮਰਥਿਤ ਵੰਡ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨਾ ਹੋਵੇਗਾ। ਸਾਡੇ ਲਈ, ਇਹ Red Hat 6 ਹੈ। ਇਸ ਵਿੱਚ gcc 4.4 ਹੈ, ਜੋ ਕਿ C++ 11 ਸਟੈਂਡਰਡ ਵੀ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਪੂਰੀ ਤਰ੍ਹਾਂ.

ਅਸੀਂ gcc 6.3 ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣਾ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਂਦੇ ਹਾਂ, ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ C++14 ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਹਾਨੂੰ Red Hat 6 ਉੱਤੇ libstdc++ ਲੈ ਕੇ ਜਾਣਾ ਪਵੇਗਾ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਨਾ ਪਵੇਗਾ। ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਉਹਨਾਂ ਨਾਲ ਸਥਿਰਤਾ ਨਾਲ ਲਿੰਕ ਕਰਨਾ ਹੈ।

ਪਰ ਅਫ਼ਸੋਸ, ਸਾਰੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਸਥਿਰ ਤੌਰ 'ਤੇ ਲਿੰਕ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਪਹਿਲਾਂ, ਸਿਸਟਮ ਲਾਇਬ੍ਰੇਰੀਆਂ ਜਿਵੇਂ ਕਿ libfuse, libblkid ਕਰਨਲ ਅਤੇ ਇਸਦੇ ਮੋਡੀਊਲ ਨਾਲ ਉਹਨਾਂ ਦੀ ਅਨੁਕੂਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਲਿੰਕ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ।

ਦੂਜਾ, ਲਾਇਸੰਸ ਦੇ ਨਾਲ ਇੱਕ ਸੂਖਮਤਾ ਹੈ.

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

ਆਮ ਤੌਰ 'ਤੇ, ਡਾਇਨਾਮਿਕ ਲਿੰਕਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਤੁਹਾਨੂੰ ਕੁਝ ਵੀ ਪ੍ਰਦਾਨ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।

C/C++ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣਾ

ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮਾਂ ਅਤੇ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ਲਈ C/C++ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ, gcc ਦਾ ਇੱਕ ਢੁਕਵਾਂ ਸੰਸਕਰਣ ਚੁਣਨਾ ਜਾਂ ਬਣਾਉਣਾ ਅਤੇ ਖਾਸ ਆਰਕੀਟੈਕਚਰ ਲਈ ਕਰਾਸ-ਕੰਪਾਈਲਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਪੂਰੇ ਸੈੱਟ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਕਾਫ਼ੀ ਹੈ। ਇਹ ਕੰਮ ਕਾਫ਼ੀ ਸੰਭਵ ਹੈ, ਪਰ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੈ. ਅਤੇ ਇਸ ਗੱਲ ਦੀ ਕੋਈ ਗਰੰਟੀ ਨਹੀਂ ਹੈ ਕਿ ਚੁਣੇ ਗਏ ਕੰਪਾਈਲਰ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਇੱਕ ਕੰਮ ਕਰਨ ਯੋਗ ਸੰਸਕਰਣ ਪ੍ਰਦਾਨ ਕਰਨਗੇ।

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

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

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

ਇਸ ਤਰ੍ਹਾਂ veeamsnap ਕਰਨਲ ਮੋਡੀਊਲ ਦੇ KMOD ਪੈਕੇਜਾਂ ਨੂੰ Red Hat ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਲਈ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਬਿਲਡ ਸਰਵਿਸ ਖੋਲ੍ਹੋ

SUSE ਦੇ ਸਹਿਯੋਗੀਆਂ ਨੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਕੰਪਾਇਲ ਕਰਨ ਅਤੇ ਪੈਕੇਜਾਂ ਨੂੰ ਅਸੈਂਬਲ ਕਰਨ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸੇਵਾ ਦੇ ਰੂਪ ਵਿੱਚ ਕੁਝ ਮੱਧ ਆਧਾਰ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ - openbuildservice.

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

OpenBuildService ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਸ਼ਡਿਊਲਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰੇਗਾ ਕਿ ਇਹ ਅਨੁਕੂਲ ਪੈਕੇਜ ਬਿਲਡਿੰਗ ਸਪੀਡ ਲਈ ਕਿੰਨੀਆਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਲਾਂਚ ਕਰ ਸਕਦਾ ਹੈ। ਬਿਲਟ-ਇਨ ਸਾਈਨਿੰਗ ਵਿਧੀ ਪੈਕੇਜਾਂ 'ਤੇ ਦਸਤਖਤ ਕਰੇਗੀ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਿਲਟ-ਇਨ ਰਿਪੋਜ਼ਟਰੀ 'ਤੇ ਅਪਲੋਡ ਕਰੇਗੀ। ਬਿਲਟ-ਇਨ ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ ਪ੍ਰਣਾਲੀ ਤਬਦੀਲੀਆਂ ਅਤੇ ਬਿਲਡਾਂ ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੇਗੀ। ਜੋ ਕੁਝ ਬਚਦਾ ਹੈ ਬਸ ਇਸ ਸਿਸਟਮ ਵਿੱਚ ਆਪਣੇ ਸਰੋਤਾਂ ਨੂੰ ਜੋੜਨਾ ਹੈ। ਤੁਹਾਨੂੰ ਸਰਵਰ ਨੂੰ ਆਪਣੇ ਆਪ ਸਥਾਪਤ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਨਹੀਂ ਹੈ; ਤੁਸੀਂ ਇੱਕ ਓਪਨ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਹੋਰ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਲਈ ਸਮਰਥਨ - ਉਦਾਹਰਨ ਲਈ, Red Hat - ਬਹੁਤ ਮਾੜੇ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਕਿ ਸਮਝ ਵਿੱਚ ਆਉਂਦਾ ਹੈ।

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

ਸਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ, OpenBuildService ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, SUSE ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਲਈ veeamsnap ਕਰਨਲ ਮੋਡੀਊਲ ਦੇ KMP ਪੈਕੇਜਾਂ ਦੀ ਪੂਰੀ ਕਿਸਮ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਅੱਗੇ, ਮੈਂ ਕਰਨਲ ਮੋਡੀਊਲ ਨਾਲ ਸੰਬੰਧਿਤ ਮੁੱਦਿਆਂ 'ਤੇ ਧਿਆਨ ਦੇਣਾ ਚਾਹਾਂਗਾ।

ਕਰਨਲ ABI

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

ਵਨੀਲਾ ਕਰਨਲ ਲਈ ਇੱਕ ਮੋਡੀਊਲ ਬਣਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇਸ ਖਾਸ ਕਰਨਲ ਦੇ ਸਿਰਲੇਖਾਂ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਇਹ ਸਿਰਫ਼ ਇਸ ਕਰਨਲ 'ਤੇ ਕੰਮ ਕਰੇਗਾ।

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

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

ਪ੍ਰਸ਼ਾਸਕ ਸੁਰੱਖਿਆ ਕਾਰਨਾਂ ਕਰਕੇ ਵਿਕਾਸ ਸਾਧਨਾਂ ਨੂੰ ਉਤਪਾਦਨ ਸਰਵਰਾਂ 'ਤੇ ਨਹੀਂ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹਨ। Enterprise Linux ਵਿਤਰਕਾਂ ਜਿਵੇਂ ਕਿ Red Hat ਅਤੇ SUSE ਨੇ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਉਹ ਆਪਣੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸਥਿਰ kABI ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦੇ ਹਨ। ਨਤੀਜਾ Red Hat ਲਈ KMOD ਪੈਕੇਜ ਅਤੇ SUSE ਲਈ KMP ਪੈਕੇਜ ਸੀ।

ਇਸ ਹੱਲ ਦਾ ਸਾਰ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੈ. ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦੇ ਇੱਕ ਖਾਸ ਸੰਸਕਰਣ ਲਈ, ਕਰਨਲ API ਨੂੰ ਫ੍ਰੀਜ਼ ਕੀਤਾ ਗਿਆ ਹੈ। ਡਿਸਟ੍ਰੀਬਿਊਟਰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਹ ਕਰਨਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, 3.10, ਅਤੇ ਸਿਰਫ ਸੁਧਾਰ ਅਤੇ ਸੁਧਾਰ ਕਰਦਾ ਹੈ ਜੋ ਕਰਨਲ ਇੰਟਰਫੇਸਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਦੇ ਹਨ, ਅਤੇ ਪਹਿਲੇ ਕਰਨਲ ਲਈ ਇਕੱਠੇ ਕੀਤੇ ਮੋਡੀਊਲ ਨੂੰ ਮੁੜ-ਕੰਪਾਈਲੇਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਸਾਰੇ ਬਾਅਦ ਵਾਲੇ ਲੋਕਾਂ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

Red Hat ਆਪਣੇ ਪੂਰੇ ਜੀਵਨ ਚੱਕਰ ਵਿੱਚ ਵੰਡ ਲਈ kABI ਅਨੁਕੂਲਤਾ ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ। ਭਾਵ, rhel 6.0 (ਰਿਲੀਜ਼ ਨਵੰਬਰ 2010) ਲਈ ਅਸੈਂਬਲਡ ਮੋਡੀਊਲ ਨੂੰ ਸੰਸਕਰਣ 6.10 (ਜੂਨ 2018 ਨੂੰ ਰਿਲੀਜ਼) 'ਤੇ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਇਹ ਲਗਭਗ 8 ਸਾਲ ਹੈ. ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਇਹ ਕੰਮ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੈ.
ਅਸੀਂ ਕਈ ਕੇਸ ਦਰਜ ਕੀਤੇ ਹਨ ਜਿੱਥੇ veeamsnap ਮੋਡੀਊਲ ਨੇ kABI ਅਨੁਕੂਲਤਾ ਮੁੱਦਿਆਂ ਦੇ ਕਾਰਨ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ।

veeamsnap ਮੋਡੀਊਲ, RHEL 7.0 ਲਈ ਕੰਪਾਇਲ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, RHEL 7.5 ਤੋਂ ਕਰਨਲ ਨਾਲ ਅਸੰਗਤ ਸਾਬਤ ਹੋਇਆ, ਪਰ ਇਹ ਲੋਡ ਹੋ ਗਿਆ ਅਤੇ ਸਰਵਰ ਦੇ ਕਰੈਸ਼ ਹੋਣ ਦੀ ਗਾਰੰਟੀ ਦਿੱਤੀ ਗਈ, ਅਸੀਂ RHEL 7 ਲਈ kABI ਅਨੁਕੂਲਤਾ ਦੀ ਵਰਤੋਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੱਤਾ।

ਵਰਤਮਾਨ ਵਿੱਚ, RHEL 7 ਲਈ KMOD ਪੈਕੇਜ ਵਿੱਚ ਹਰੇਕ ਰੀਲੀਜ਼ ਸੰਸਕਰਣ ਲਈ ਇੱਕ ਅਸੈਂਬਲੀ ਅਤੇ ਇੱਕ ਸਕ੍ਰਿਪਟ ਹੈ ਜੋ ਮੋਡੀਊਲ ਨੂੰ ਲੋਡ ਕਰਦੀ ਹੈ।

SUSE ਨੇ KABI ਅਨੁਕੂਲਤਾ ਦੇ ਕੰਮ ਨੂੰ ਹੋਰ ਧਿਆਨ ਨਾਲ ਪਹੁੰਚਾਇਆ। ਉਹ ਸਿਰਫ਼ ਇੱਕ ਸਰਵਿਸ ਪੈਕ ਦੇ ਅੰਦਰ KABI ਅਨੁਕੂਲਤਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, SLES 12 ਦੀ ਰਿਲੀਜ਼ ਸਤੰਬਰ 2014 ਵਿੱਚ ਹੋਈ ਸੀ। ਅਤੇ SLES 12 SP1 ਪਹਿਲਾਂ ਹੀ ਦਸੰਬਰ 2015 ਵਿੱਚ ਸੀ, ਯਾਨੀ ਕਿ ਇੱਕ ਸਾਲ ਤੋਂ ਥੋੜ੍ਹਾ ਵੱਧ ਸਮਾਂ ਬੀਤ ਗਿਆ ਹੈ। ਭਾਵੇਂ ਦੋਵੇਂ ਰੀਲੀਜ਼ 3.12 ਕਰਨਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਉਹ kABI ਅਸੰਗਤ ਹਨ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਸਿਰਫ ਇੱਕ ਸਾਲ ਲਈ ਕੇਬੀਆਈ ਅਨੁਕੂਲਤਾ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਬਹੁਤ ਸੌਖਾ ਹੈ. ਸਾਲਾਨਾ ਕਰਨਲ ਮੋਡੀਊਲ ਅੱਪਡੇਟ ਚੱਕਰ ਮੋਡੀਊਲ ਸਿਰਜਣਹਾਰਾਂ ਲਈ ਸਮੱਸਿਆ ਪੈਦਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ SUSE ਨੀਤੀ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਆਪਣੇ veeamsnap ਮੋਡੀਊਲ ਵਿੱਚ kABI ਅਨੁਕੂਲਤਾ ਨਾਲ ਇੱਕ ਵੀ ਸਮੱਸਿਆ ਦਰਜ ਨਹੀਂ ਕੀਤੀ ਹੈ। ਇਹ ਸੱਚ ਹੈ ਕਿ SUSE ਲਈ ਪੈਕੇਜਾਂ ਦੀ ਗਿਣਤੀ ਲਗਭਗ ਇੱਕ ਕ੍ਰਮ ਤੋਂ ਵੱਧ ਹੈ।

ਪੈਚ ਅਤੇ ਬੈਕਪੋਰਟ

ਹਾਲਾਂਕਿ ਵਿਤਰਕ kABI ਅਨੁਕੂਲਤਾ ਅਤੇ ਕਰਨਲ ਸਥਿਰਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਉਹ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਸੁਧਾਰਨ ਅਤੇ ਇਸ ਸਥਿਰ ਕਰਨਲ ਦੇ ਨੁਕਸ ਨੂੰ ਦੂਰ ਕਰਨ ਦੀ ਵੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।

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

ਕਈ ਵਾਰੀ ਇਹ ਨਵੇਂ ਲੋਕਾਂ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ ਗਲਤੀਆਂ.

Red Hat 6 ਦੇ ਨਵੀਨਤਮ ਰੀਲੀਜ਼ ਵਿੱਚ, ਇੱਕ ਮਾਮੂਲੀ ਅੱਪਡੇਟ ਵਿੱਚ ਇੱਕ ਗਲਤੀ ਕੀਤੀ ਗਈ ਸੀ. ਇਹ ਇਸ ਤੱਥ ਵੱਲ ਅਗਵਾਈ ਕਰਦਾ ਹੈ ਕਿ ਸਨੈਪਸ਼ਾਟ ਜਾਰੀ ਕੀਤੇ ਜਾਣ 'ਤੇ veeamsnap ਮੋਡੀਊਲ ਸਿਸਟਮ ਨੂੰ ਕਰੈਸ਼ ਕਰਨ ਦੀ ਗਾਰੰਟੀ ਦਿੱਤੀ ਗਈ ਸੀ। ਅੱਪਡੇਟ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕਰਨਲ ਸਰੋਤਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਾਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ ਬੈਕਪੋਰਟ ਜ਼ਿੰਮੇਵਾਰ ਸੀ। ਵਨੀਲਾ ਕਰਨਲ ਸੰਸਕਰਣ 4.19 ਵਿੱਚ ਇੱਕ ਸਮਾਨ ਫਿਕਸ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਹ ਸਿਰਫ ਇਹ ਹੈ ਕਿ ਇਸ ਫਿਕਸ ਨੇ ਵਨੀਲਾ ਕਰਨਲ ਵਿੱਚ ਵਧੀਆ ਕੰਮ ਕੀਤਾ, ਪਰ ਜਦੋਂ ਇਸਨੂੰ "ਸਥਿਰ" 2.6.32 ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਸਪਿਨਲਾਕ ਨਾਲ ਇੱਕ ਸਮੱਸਿਆ ਪੈਦਾ ਹੋਈ।

ਬੇਸ਼ੱਕ, ਹਰ ਕਿਸੇ ਕੋਲ ਹਮੇਸ਼ਾ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਪਰ ਕੀ ਸਥਿਰਤਾ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾ ਕੇ ਕੋਡ ਨੂੰ 4.19 ਤੋਂ 2.6.32 ਤੱਕ ਘਸੀਟਣਾ ਯੋਗ ਸੀ?... ਮੈਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ...

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

ਜਦੋਂ ਮੈਂ SLES 4.4 SP12 ਤੋਂ ਕਰਨਲ 3 'ਤੇ ਇੱਕ ਮੋਡੀਊਲ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਤਾਂ ਮੈਂ ਇਸ ਵਿੱਚ ਵਨੀਲਾ 4.8 ਤੋਂ ਕਾਰਜਸ਼ੀਲਤਾ ਲੱਭ ਕੇ ਹੈਰਾਨ ਰਹਿ ਗਿਆ। ਮੇਰੀ ਰਾਏ ਵਿੱਚ, SLES 4.4 SP12 ਤੋਂ 3 ਕਰਨਲ ਦਾ ਬਲਾਕ I/O ਲਾਗੂ ਕਰਨਾ SLES4.8 SP4.4 ਤੋਂ ਸਥਿਰ 12 ਕਰਨਲ ਦੇ ਪਿਛਲੇ ਰੀਲੀਜ਼ ਨਾਲੋਂ 2 ਕਰਨਲ ਵਰਗਾ ਹੈ। ਮੈਂ ਨਿਰਣਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਕੋਡ ਦੀ ਕਿੰਨੀ ਪ੍ਰਤੀਸ਼ਤ ਨੂੰ SP4.8 ਲਈ ਕਰਨਲ 4.4 ਤੋਂ SLES 3 ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਮੈਂ ਕਰਨਲ ਨੂੰ ਉਹੀ ਸਥਿਰ 4.4 ਵੀ ਨਹੀਂ ਕਹਿ ਸਕਦਾ।

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

ਨਤੀਜੇ ਵਜੋਂ, ਕੋਡ ਅਜੀਬ ਕੰਡੀਸ਼ਨਲ ਕੰਪਾਈਲੇਸ਼ਨ ਨਿਰਦੇਸ਼ਾਂ ਨਾਲ ਵੱਧ ਗਿਆ ਹੈ।

ਅਜਿਹੇ ਪੈਚ ਵੀ ਹਨ ਜੋ ਦਸਤਾਵੇਜ਼ੀ ਕਰਨਲ API ਨੂੰ ਬਦਲਦੇ ਹਨ।
ਮੈਂ ਵੰਡ ਕੇ ਆਇਆ ਕੇਡੀਏ ਨੀਯਨ 5.16 ਅਤੇ ਇਹ ਦੇਖ ਕੇ ਬਹੁਤ ਹੈਰਾਨੀ ਹੋਈ ਕਿ ਇਸ ਕਰਨਲ ਸੰਸਕਰਣ ਵਿੱਚ lookup_bdev ਕਾਲ ਨੇ ਇੰਪੁੱਟ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਸੂਚੀ ਬਦਲ ਦਿੱਤੀ ਹੈ।

ਇਸ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਲਈ, ਮੈਨੂੰ ਮੇਕਫਾਈਲ ਵਿੱਚ ਇੱਕ ਸਕ੍ਰਿਪਟ ਜੋੜਨੀ ਪਈ ਜੋ ਇਹ ਜਾਂਚ ਕਰਦੀ ਹੈ ਕਿ lookup_bdev ਫੰਕਸ਼ਨ ਵਿੱਚ ਮਾਸਕ ਪੈਰਾਮੀਟਰ ਹੈ ਜਾਂ ਨਹੀਂ।

ਦਸਤਖਤ ਕਰਨਲ ਮੋਡੀਊਲ

ਪਰ ਆਓ ਪੈਕੇਜ ਵੰਡ ਦੇ ਮੁੱਦੇ 'ਤੇ ਵਾਪਸ ਚਲੀਏ.

ਸਥਿਰ kABI ਦਾ ਇੱਕ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਕਰਨਲ ਮੋਡੀਊਲ ਨੂੰ ਬਾਈਨਰੀ ਫਾਈਲ ਦੇ ਤੌਰ ਤੇ ਸਾਈਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਡਿਵੈਲਪਰ ਇਹ ਯਕੀਨੀ ਬਣਾ ਸਕਦਾ ਹੈ ਕਿ ਮੋਡੀਊਲ ਨੂੰ ਗਲਤੀ ਨਾਲ ਨੁਕਸਾਨ ਨਹੀਂ ਹੋਇਆ ਹੈ ਜਾਂ ਜਾਣਬੁੱਝ ਕੇ ਸੋਧਿਆ ਨਹੀਂ ਗਿਆ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ modinfo ਕਮਾਂਡ ਨਾਲ ਚੈੱਕ ਕਰ ਸਕਦੇ ਹੋ।

Red Hat ਅਤੇ SUSE ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਤੁਹਾਨੂੰ ਮੋਡੀਊਲ ਦੇ ਦਸਤਖਤ ਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਸਿਰਫ਼ ਤਾਂ ਹੀ ਲੋਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਜੇਕਰ ਸੰਬੰਧਿਤ ਸਰਟੀਫਿਕੇਟ ਸਿਸਟਮ 'ਤੇ ਰਜਿਸਟਰਡ ਹੋਵੇ। ਸਰਟੀਫਿਕੇਟ ਜਨਤਕ ਕੁੰਜੀ ਹੈ ਜਿਸ ਨਾਲ ਮੋਡੀਊਲ ਸਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ ਵੱਖਰੇ ਪੈਕੇਜ ਦੇ ਰੂਪ ਵਿੱਚ ਵੰਡਦੇ ਹਾਂ।

ਇੱਥੇ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਤਾਂ ਕਰਨਲ ਵਿੱਚ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ (ਵਿਤਰਕ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ) ਜਾਂ ਇੱਕ ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ EFI ਗੈਰ-ਅਸਥਿਰ ਮੈਮੋਰੀ ਵਿੱਚ ਲਿਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਮੋਕੁਟਿਲ. ਉਪਯੋਗਤਾ ਮੋਕੁਟਿਲ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਇੰਸਟਾਲ ਕਰਨ ਵੇਲੇ, ਤੁਹਾਨੂੰ ਸਿਸਟਮ ਨੂੰ ਰੀਬੂਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕਰਨਲ ਨੂੰ ਲੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਪਰਬੰਧਕ ਨੂੰ ਇੱਕ ਨਵਾਂ ਸਰਟੀਫਿਕੇਟ ਲੋਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਪੁੱਛਦਾ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਜੋੜਨ ਲਈ ਸਿਸਟਮ ਤੱਕ ਭੌਤਿਕ ਪ੍ਰਸ਼ਾਸਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਮਸ਼ੀਨ ਕਲਾਊਡ ਵਿੱਚ ਕਿਤੇ ਸਥਿਤ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਰਿਮੋਟ ਸਰਵਰ ਰੂਮ ਵਿੱਚ ਹੈ ਅਤੇ ਪਹੁੰਚ ਸਿਰਫ਼ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ssh ਰਾਹੀਂ), ਤਾਂ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਜੋੜਨਾ ਅਸੰਭਵ ਹੋਵੇਗਾ।

ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ 'ਤੇ EFI

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

ਸਾਰੇ ਹਾਈਪਰਵਾਈਜ਼ਰ EFI ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ ਹਨ। VMWare vSphere ਸੰਸਕਰਣ 5 ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ EFI ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
ਮਾਈਕਰੋਸਾਫਟ ਹਾਈਪਰ-ਵੀ ਨੇ ਵਿੰਡੋਜ਼ ਸਰਵਰ 2012R2 ਲਈ ਹਾਈਪਰ-ਵੀ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ EFI ਸਮਰਥਨ ਵੀ ਪ੍ਰਾਪਤ ਕੀਤਾ।

ਹਾਲਾਂਕਿ, ਡਿਫੌਲਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਇਹ ਕਾਰਜਸ਼ੀਲਤਾ ਲੀਨਕਸ ਮਸ਼ੀਨਾਂ ਲਈ ਅਸਮਰੱਥ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਸਥਾਪਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

vSphere 6.5 ਵਿੱਚ, ਵਿਕਲਪ ਸੈੱਟ ਕਰੋ ਸੁਰੱਖਿਅਤ ਬੂਟ ਵੈੱਬ ਇੰਟਰਫੇਸ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਵਿੱਚ ਹੀ ਸੰਭਵ ਹੈ, ਜੋ ਫਲੈਸ਼ ਦੁਆਰਾ ਚਲਦਾ ਹੈ। HTML-5 'ਤੇ ਵੈੱਬ UI ਅਜੇ ਵੀ ਬਹੁਤ ਪਿੱਛੇ ਹੈ।

ਪ੍ਰਯੋਗਾਤਮਕ ਵੰਡ

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

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

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

ਤੁਸੀਂ ਵਰਜਨ 3.0 ਲਈ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ ਵੰਡਾਂ ਦੀ ਮੌਜੂਦਾ ਸੂਚੀ ਦਾ ਅਧਿਐਨ ਕਰ ਸਕਦੇ ਹੋ ਇੱਥੇ. ਪਰ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ਦੀ ਅਸਲ ਸੂਚੀ ਜਿਸ 'ਤੇ ਸਾਡਾ ਉਤਪਾਦ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਉਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਆਪਕ ਹੈ।

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

ਖੈਰ, ਨਵੀਆਂ ਵੰਡਾਂ ਲਈ ਸਮਰਥਨ ਜਾਰੀ ਹੈ। ਅਸੀਂ ਸੰਸਕਰਣ 4.0 ਦੇ ਜਾਰੀ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਾਂ। ਬੀਟਾ ਪ੍ਰਗਟ ਹੋਣ ਵਾਲਾ ਹੈ, ਇਸ ਲਈ ਧਿਆਨ ਰੱਖੋ ਨਵਾਂ ਕੀ ਹੈ!

ਸਰੋਤ: www.habr.com