எப்படியாவது ஒரு கட்டத்தில் டோக்கர் கொள்கலன்கள் மற்றும் டெப் பேக்கேஜ்கள் வடிவில் டெலிவரி பற்றி ஒரு கட்டுரை எழுத முடிவு செய்தேன், ஆனால் நான் தொடங்கியபோது, சில காரணங்களால் நான் முதல் தனிப்பட்ட கணினிகள் மற்றும் கால்குலேட்டர்களின் தொலைதூர காலத்திற்கு மீண்டும் கொண்டு செல்லப்பட்டேன். பொதுவாக, டோக்கர் மற்றும் டெப் ஆகியவற்றின் உலர் ஒப்பீடுகளுக்குப் பதிலாக, பரிணாமம் என்ற தலைப்பில் இந்த எண்ணங்களைப் பெற்றுள்ளோம், அதை உங்கள் கருத்தில் முன்வைக்கிறேன்.
எந்தவொரு தயாரிப்பு, அது என்னவாக இருந்தாலும், எப்படியாவது தயாரிப்பு சேவையகங்களுக்குச் செல்ல வேண்டும், கட்டமைக்கப்பட்டு தொடங்கப்பட வேண்டும். அதைப் பற்றித்தான் இந்தக் கட்டுரை இருக்கும்.
"நான் எதைப் பற்றிப் பாடுகிறேன், எதைப் பற்றி நான் காண்கிறேன்," நான் முதலில் குறியீடு எழுதத் தொடங்கியபோது என்ன பார்த்தேன், இப்போது நான் என்ன கவனிக்கிறேன், இந்த நேரத்தில் நாம் எதைப் பயன்படுத்துகிறோம், ஏன் என்று ஒரு வரலாற்று சூழலில் சிந்திப்பேன். கட்டுரை முழுக்க முழுக்க படிப்பதாகக் காட்டவில்லை, சில புள்ளிகள் தவறவிடப்பட்டுள்ளன, இது என்ன, இப்போது என்ன என்பது பற்றிய எனது தனிப்பட்ட பார்வை.
எனவே, நல்ல பழைய நாட்களில்... நான் கண்டறிந்த டெலிவரிக்கான ஆரம்ப முறை டேப் ரெக்கார்டர்களில் இருந்து கேசட் டேப்கள். என்னிடம் கணினி BK-0010.01 இருந்தது...
கால்குலேட்டர்களின் சகாப்தம்
இல்லை, இன்னும் முந்தைய தருணம் இருந்தது, ஒரு கால்குலேட்டரும் இருந்தது
அதனால் நான் இருந்தபோது
அடுத்த மாற்றம் ஒரு கால்குலேட்டர்
கால்குலேட்டரில் உள்ள மிகப்பெரிய நிரலின் அளவு 105 படிகள், மற்றும் MK-52 இல் நிரந்தர நினைவகத்தின் அளவு 512 படிகள்.
மூலம், இந்த கட்டுரையைப் படிக்கும் இந்த கால்குலேட்டர்களின் ரசிகர்கள் இருந்தால், கட்டுரையை எழுதும் பணியில் ஆண்ட்ராய்டுக்கான கால்குலேட்டர் முன்மாதிரி மற்றும் அதற்கான நிரல்கள் இரண்டையும் கண்டேன். கடந்த காலத்திற்கு முன்னோக்கி!
MK-52 பற்றி ஒரு சிறிய திசைதிருப்பல் (விக்கிபீடியாவிலிருந்து)
சோயுஸ் டிஎம்-52 விண்கலத்தில் எம்கே-7 விண்ணில் பறந்தது. ஆன்-போர்டு கணினி தோல்வியுற்றால் தரையிறங்கும் பாதையைக் கணக்கிட இது பயன்படுத்தப்பட வேண்டும்.
52 ஆம் ஆண்டு முதல், எலெக்ட்ரோனிகா-ஆஸ்ட்ரோ நினைவக விரிவாக்க அலகு கொண்ட MK-1988 கடற்படைக் கப்பல்களுக்கு வழிசெலுத்தல் கணினி கருவியின் ஒரு பகுதியாக வழங்கப்படுகிறது.
முதல் தனிப்பட்ட கணினிகள்
காலத்துக்குப் போவோம்
ஒரு கேசட்டில் சேமிப்பு பொதுவாக ஒன்று அல்லது இரண்டு பைனரி கோப்புகளின் வடிவத்தில் இருக்கும், மற்ற அனைத்தும் உள்ளே இருக்கும். நம்பகத்தன்மை மிகவும் குறைவாக இருந்தது, நான் நிரலின் 2-3 நகல்களை வைத்திருக்க வேண்டியிருந்தது. ஏற்றும் நேரங்களும் ஏமாற்றமளித்தன, மேலும் ஆர்வலர்கள் இந்தக் குறைபாடுகளைப் போக்க வெவ்வேறு அதிர்வெண் குறியாக்கங்களைப் பயன்படுத்தினர். அந்த நேரத்தில், நானே இன்னும் தொழில்முறை மென்பொருள் மேம்பாட்டில் ஈடுபடவில்லை (அடிப்படையில் எளிய நிரல்களைக் கணக்கிடவில்லை), எனவே, துரதிர்ஷ்டவசமாக, உள்ளே எல்லாம் எவ்வாறு ஏற்பாடு செய்யப்பட்டது என்பதை நான் உங்களுக்கு விரிவாகக் கூற மாட்டேன். கணினியில் பெரும்பாலும் ரேம் மட்டுமே இருந்தது என்பது தரவு சேமிப்பு திட்டத்தின் எளிமையை தீர்மானித்தது.
நம்பகமான மற்றும் பெரிய சேமிப்பக ஊடகங்களின் தோற்றம்
பின்னர், நெகிழ் வட்டுகள் தோன்றின, நகலெடுக்கும் செயல்முறை எளிமைப்படுத்தப்பட்டது மற்றும் நம்பகத்தன்மை அதிகரித்தது.
ஆனால் போதுமான அளவு பெரிய உள்ளூர் சேமிப்பகங்கள் HDD வடிவில் தோன்றும் போது மட்டுமே நிலைமை வியத்தகு முறையில் மாறுகிறது.
விநியோக வகை அடிப்படையில் மாறுகிறது: நிறுவி நிரல்கள் தோன்றும், அவை கணினியை உள்ளமைக்கும் செயல்முறையை நிர்வகிக்கின்றன, அத்துடன் அகற்றப்பட்ட பிறகு சுத்தம் செய்கின்றன, ஏனெனில் நிரல்கள் நினைவகத்தில் படிக்கப்படுவதில்லை, ஆனால் ஏற்கனவே உள்ளூர் சேமிப்பகத்திற்கு நகலெடுக்கப்படுகின்றன, அதில் இருந்து நீங்கள் செய்ய வேண்டும். தேவைப்பட்டால் தேவையற்ற விஷயங்களை அழிக்க முடியும்.
அதே நேரத்தில், வழங்கப்பட்ட மென்பொருளின் சிக்கலான தன்மை அதிகரித்து வருகிறது.
டெலிவரியில் உள்ள கோப்புகளின் எண்ணிக்கை சிலவற்றிலிருந்து நூற்றுக்கணக்கான மற்றும் ஆயிரங்களாக அதிகரிக்கிறது, வெவ்வேறு நிரல்கள் ஒரே தரவைப் பயன்படுத்தும் போது நூலக பதிப்புகள் மற்றும் பிற மகிழ்ச்சிகளுக்கு இடையிலான முரண்பாடுகள் தொடங்குகின்றன.
அந்த நேரத்தில், லினக்ஸின் இருப்பு இன்னும் எனக்கு திறக்கப்படவில்லை; நான் MS DOS மற்றும் பின்னர், விண்டோஸ் உலகில் வாழ்ந்தேன், மற்றும் Borland Pascal மற்றும் Delphi இல் எழுதினேன், சில சமயங்களில் C++ நோக்கிப் பார்த்தேன். தயாரிப்புகளை வழங்க பலர் InstallShield ஐப் பயன்படுத்தினர்.
இணைய யுகம்
படிப்படியாக, மென்பொருள் அமைப்புகளின் சிக்கலானது இன்னும் சிக்கலானதாகி வருகிறது; மோனோலித் மற்றும் டெஸ்க்டாப் பயன்பாடுகளிலிருந்து விநியோகிக்கப்பட்ட அமைப்புகள், மெல்லிய கிளையண்டுகள் மற்றும் மைக்ரோ சர்வீஸ்களுக்கு மாற்றம் உள்ளது. இப்போது நீங்கள் ஒரு நிரலை மட்டும் கட்டமைக்க வேண்டும், ஆனால் அவற்றின் தொகுப்பை உருவாக்க வேண்டும், மேலும் அவை அனைத்தும் ஒன்றாக வேலை செய்யும்.
கருத்து முற்றிலும் மாறிவிட்டது, இணையம் வந்தது, கிளவுட் சேவைகளின் சகாப்தம் வந்தது. இதுவரை, ஆரம்ப கட்டத்தில் மட்டுமே, வலைத்தளங்களின் வடிவத்தில், யாரும் குறிப்பாக சேவைகளை கனவு கண்டதில்லை. ஆனால் இது பயன்பாடுகளின் வளர்ச்சி மற்றும் விநியோகம் ஆகிய இரண்டிலும் ஒரு திருப்புமுனையாக இருந்தது.
என்னைப் பொறுத்தவரை, அந்த நேரத்தில் டெவலப்பர்களின் தலைமுறைகளில் ஒரு மாற்றம் ஏற்பட்டது என்று குறிப்பிட்டேன் (அல்லது அது என் சூழலில் மட்டுமே இருந்தது), மேலும் அனைத்து நல்ல பழைய டெலிவரி முறைகளும் ஒரு கணத்தில் மறந்துவிட்டன, எல்லாமே மிகத் தொடங்கின என்ற உணர்வு இருந்தது. ஆரம்பம்: அனைத்து பிரசவங்களும் முழங்கால் ஸ்கிரிப்ட்களாக செய்யத் தொடங்கின மற்றும் பெருமையுடன் "தொடர்ச்சியான விநியோகம்" என்று அழைக்கப்பட்டன. உண்மையில், குழப்பத்தின் காலம் தொடங்கியது, பழையதை மறந்துவிட்டு, பயன்படுத்தப்படாமல், புதியது வெறுமனே இல்லை.
நான் அப்போது பணிபுரிந்த எங்கள் நிறுவனத்தில் (நான் பெயரிட மாட்டேன்), எறும்பு வழியாகக் கட்டுவதற்குப் பதிலாக (மேவன் இன்னும் பிரபலமாகவில்லை அல்லது இல்லை) மக்கள் IDE இல் ஜாடிகளைச் சேகரித்து அமைதியாக உறுதியளித்த நேரங்கள் எனக்கு நினைவிருக்கிறது. அது SVN இல். அதன்படி, SVN இலிருந்து கோப்பை மீட்டெடுப்பது மற்றும் SSH வழியாக விரும்பிய இயந்திரத்திற்கு நகலெடுப்பது வரிசைப்படுத்தல் ஆகும். இது மிகவும் எளிமையானது மற்றும் விகாரமானது.
அதே நேரத்தில், PHP இல் உள்ள எளிய தளங்களின் விநியோகம், FTP வழியாக சரிசெய்யப்பட்ட கோப்பை இலக்கு இயந்திரத்திற்கு நகலெடுப்பதன் மூலம் மிகவும் பழமையான முறையில் செய்யப்பட்டது. சில நேரங்களில் இது அவ்வாறு இல்லை - தயாரிப்பு சேவையகத்தில் குறியீடு நேரடியாகத் திருத்தப்பட்டது, மேலும் எங்காவது காப்புப்பிரதிகள் இருந்தால் அது மிகவும் புதுப்பாணியானது.
RPM மற்றும் DEB தொகுப்புகள்
மறுபுறம், இணையத்தின் வளர்ச்சியுடன், யுனிக்ஸ் போன்ற அமைப்புகள் மேலும் மேலும் பிரபலமடையத் தொடங்கின, குறிப்பாக, அந்த நேரத்தில்தான் நான் RedHat Linux 6 ஐக் கண்டுபிடித்தேன், தோராயமாக 2000. இயற்கையாகவே, மென்பொருளை வழங்குவதற்கான சில வழிமுறைகளும் இருந்தன; விக்கிபீடியாவின் படி, RPM முதன்மை தொகுப்பு மேலாளராக ஏற்கனவே 1995 இல் RedHat Linux 2.0 பதிப்பில் தோன்றியது. அன்றிலிருந்து இன்றுவரை, கணினி RPM தொகுப்புகளின் வடிவத்தில் விநியோகிக்கப்படுகிறது மற்றும் மிகவும் வெற்றிகரமாக உள்ளது மற்றும் வளர்ந்து வருகிறது.
டெபியன் குடும்பத்தின் விநியோகங்களும் இதேபோன்ற பாதையை பின்பற்றி டெப் பேக்கேஜ்கள் வடிவில் விநியோகத்தை செயல்படுத்தியது, இது இன்றுவரை மாறாமல் உள்ளது.
தொகுப்பு மேலாளர்கள் மென்பொருள் தயாரிப்புகளை தாங்களாகவே வழங்கவும், நிறுவல் செயல்பாட்டின் போது அவற்றை உள்ளமைக்கவும், வெவ்வேறு தொகுப்புகளுக்கு இடையே உள்ள சார்புகளை நிர்வகிக்கவும், தயாரிப்புகளை அகற்றவும் மற்றும் நிறுவல் நீக்கும் செயல்பாட்டின் போது தேவையற்ற பொருட்களை சுத்தம் செய்யவும் உங்களை அனுமதிக்கின்றனர். அந்த. பெரும்பாலும், அவ்வளவுதான் தேவை, அதனால்தான் அவை பல தசாப்தங்களாக கிட்டத்தட்ட மாறாமல் நீடித்தன.
கிளவுட் கம்ப்யூட்டிங் பொதி மேலாளர்களுக்கு இயற்பியல் ஊடகத்திலிருந்து மட்டுமல்லாமல், கிளவுட் களஞ்சியங்களிலிருந்தும் நிறுவலைச் சேர்த்தது, ஆனால் அடிப்படையில் சிறிதளவு மாறிவிட்டது.
தற்போது டெப்பில் இருந்து விலகி ஸ்னாப் பேக்கேஜ்களுக்கு மாறுவதற்கு சில நகர்வுகள் உள்ளன என்பது குறிப்பிடத்தக்கது, ஆனால் பின்னர் அது பற்றி.
எனவே, DEB அல்லது RPM இரண்டையும் அறியாத இந்த புதிய தலைமுறை கிளவுட் டெவலப்பர்களும் மெதுவாக வளர்ந்தனர், அனுபவத்தைப் பெற்றனர், தயாரிப்புகள் மிகவும் சிக்கலானதாக மாறியது, மேலும் FTP, பாஷ் ஸ்கிரிப்டுகள் மற்றும் மாணவர்களின் கைவினைகளை விட சில நியாயமான டெலிவரி முறைகள் தேவைப்பட்டன.
மெய்நிகராக்கம், வளங்களை வரையறுத்தல் மற்றும் விநியோக முறை ஆகியவற்றின் ஒரு வகையான கலவையான டோக்கர் படத்தில் வருகிறது. இது இப்போது நாகரீகமாகவும் இளமையாகவும் இருக்கிறது, ஆனால் எல்லாவற்றிற்கும் இது தேவையா? இது ஒரு சஞ்சீவி?
எனது அவதானிப்புகளிலிருந்து, பெரும்பாலும் டோக்கர் ஒரு நியாயமான தேர்வாக முன்மொழியப்படவில்லை, ஆனால் ஒருபுறம், இது சமூகத்தில் பேசப்படுவதால், அதை முன்மொழிபவர்களுக்கு மட்டுமே தெரியும். மறுபுறம், அவர்கள் நல்ல பழைய பேக்கேஜிங் அமைப்புகளைப் பற்றி மௌனமாக இருக்கிறார்கள் - அவை உள்ளன மற்றும் அமைதியாகவும் கவனிக்கப்படாமலும் தங்கள் வேலையைச் செய்கின்றன. அத்தகைய சூழ்நிலையில், உண்மையில் வேறு வழியில்லை - தேர்வு வெளிப்படையானது - டோக்கர்.
டோக்கரை நாங்கள் எவ்வாறு செயல்படுத்தினோம் மற்றும் அதன் விளைவாக என்ன நடந்தது என்பது பற்றிய எனது அனுபவத்தைப் பகிர்ந்து கொள்ள முயற்சிக்கிறேன்.
சுயமாக எழுதப்பட்ட ஸ்கிரிப்டுகள்
ஆரம்பத்தில், தேவையான இயந்திரங்களுக்கு ஜார் காப்பகங்களை வரிசைப்படுத்தும் பாஷ் ஸ்கிரிப்டுகள் இருந்தன. இந்த செயல்முறையை ஜென்கின்ஸ் நிர்வகித்தார். ஜார் காப்பகமே ஏற்கனவே வகுப்புகள், வளங்கள் மற்றும் உள்ளமைவுகளைக் கொண்ட ஒரு சட்டசபையாக இருப்பதால் இது வெற்றிகரமாக வேலை செய்தது. நீங்கள் எல்லாவற்றையும் அதில் அதிகபட்சமாக வைத்தால், அதை ஒரு ஸ்கிரிப்டாக விரிவுபடுத்துவது உங்களுக்கு மிகவும் கடினமான விஷயம் அல்ல
ஆனால் ஸ்கிரிப்ட்களுக்கு பல குறைபாடுகள் உள்ளன:
- ஸ்கிரிப்டுகள் பொதுவாக அவசரமாக எழுதப்படுகின்றன, எனவே அவை மிகவும் பழமையானவை, அவை ஒரே ஒரு சிறந்த சூழ்நிலையை மட்டுமே கொண்டிருக்கின்றன. டெவலப்பர் விரைவான விநியோகத்தில் ஆர்வமாக இருப்பதால் இது எளிதாக்கப்படுகிறது, மேலும் ஒரு சாதாரண ஸ்கிரிப்ட்டிற்கு ஒழுக்கமான அளவு வளங்களை முதலீடு செய்ய வேண்டும்.
- முந்தைய புள்ளியின் விளைவாக, ஸ்கிரிப்ட்களில் நிறுவல் நீக்குதல் நடைமுறைகள் இல்லை
- நிறுவப்பட்ட மேம்படுத்தல் நடைமுறை இல்லை
- ஒரு புதிய தயாரிப்பு தோன்றும் போது, நீங்கள் ஒரு புதிய ஸ்கிரிப்டை எழுத வேண்டும்
- சார்பு ஆதரவு இல்லை
நிச்சயமாக, நீங்கள் ஒரு அதிநவீன ஸ்கிரிப்டை எழுதலாம், ஆனால், நான் மேலே எழுதியது போல, இது வளர்ச்சி நேரம், மற்றும் குறைந்தது அல்ல, எங்களுக்குத் தெரிந்தபடி, எப்போதும் போதுமான நேரம் இல்லை.
இவை அனைத்தும் இந்த வரிசைப்படுத்தல் முறையின் பயன்பாட்டின் வரம்பை எளிமையான அமைப்புகளுக்கு மட்டுமே கட்டுப்படுத்துகிறது. இதை மாற்ற வேண்டிய நேரம் வந்துவிட்டது.
கூலியாள்
ஒரு கட்டத்தில், புதிதாகத் தயாரிக்கப்பட்ட நடுநிலைகள் எங்களிடம் வரத் தொடங்கின, யோசனைகள் மற்றும் டாக்கரைப் பற்றி பொங்கி எழுகின்றன. சரி, கையில் கொடி - செய்வோம்! இரண்டு முயற்சிகள் இருந்தன. இரண்டுமே தோல்வியடைந்தன - பெரிய லட்சியங்கள் காரணமாக, ஆனால் உண்மையான அனுபவமின்மை காரணமாக சொல்லலாம். அதை வற்புறுத்தி எந்த வழியிலாவது முடிக்க வேண்டியது அவசியமா? இது சாத்தியமில்லை - பொருத்தமான கருவிகளைப் பயன்படுத்துவதற்கு முன்பு குழு தேவையான நிலைக்கு உருவாக வேண்டும். கூடுதலாக, ஆயத்த டோக்கர் படங்களைப் பயன்படுத்தும் போது, நெட்வொர்க் சரியாக வேலை செய்யவில்லை (டோக்கரின் ஈரப்பதம் காரணமாக இருக்கலாம்) அல்லது மற்றவர்களின் கொள்கலன்களை விரிவுபடுத்துவது கடினம் என்ற உண்மையை நாங்கள் அடிக்கடி எதிர்கொள்கிறோம்.
நாங்கள் என்ன சிரமங்களை சந்தித்தோம்?
- பிரிட்ஜ் பயன்முறையில் நெட்வொர்க் சிக்கல்கள்
- ஒரு கொள்கலனில் பதிவுகளைப் பார்ப்பது சிரமமாக உள்ளது (அவை ஹோஸ்ட் இயந்திரத்தின் கோப்பு முறைமையில் தனித்தனியாக சேமிக்கப்படாவிட்டால்)
- ElasticSearch எப்போதாவது கொள்கலனுக்குள் விசித்திரமாக உறைகிறது, காரணம் கண்டறியப்படவில்லை, கொள்கலன் அதிகாரப்பூர்வமானது
- ஒரு கொள்கலனுக்குள் ஒரு ஷெல் பயன்படுத்துவது அவசியம் - எல்லாம் மிகவும் அகற்றப்பட்டது, வழக்கமான கருவிகள் எதுவும் இல்லை
- சேகரிக்கப்பட்ட கொள்கலன்களின் பெரிய அளவு - சேமிக்க விலை உயர்ந்தது
- கொள்கலன்களின் பெரிய அளவு காரணமாக, பல பதிப்புகளை ஆதரிப்பது கடினம்
- மற்ற முறைகள் (ஸ்கிரிப்டுகள் அல்லது டெப் தொகுப்புகள்) போலல்லாமல், நீண்ட கால உருவாக்க நேரம்
மறுபுறம், அதே டெப் மூலம் ஜார் காப்பகத்தின் வடிவத்தில் ஸ்பிரிங் சேவையை வரிசைப்படுத்துவது ஏன் மோசமானது? வளங்களை தனிமைப்படுத்துவது உண்மையில் அவசியமா? ஒரு சேவையை பெரிதும் குறைக்கப்பட்ட கொள்கலனில் அடைப்பதன் மூலம் வசதியான இயக்க முறைமை கருவிகளை இழப்பது மதிப்புள்ளதா?
நடைமுறையில் காட்டப்பட்டுள்ளபடி, உண்மையில் இது தேவையில்லை, 90% வழக்குகளில் டெப் தொகுப்பு போதுமானது.
நல்ல பழைய டெப் எப்போது தோல்வியடைகிறது, நமக்கு எப்போது டோக்கர் தேவை?
எங்களைப் பொறுத்தவரை, இது பைத்தானில் சேவைகளைப் பயன்படுத்துவதாகும். இயந்திர கற்றலுக்கு நிறைய நூலகங்கள் தேவைப்படுகின்றன மற்றும் இயக்க முறைமையின் நிலையான விநியோகத்தில் சேர்க்கப்படவில்லை (மற்றும் தவறான பதிப்புகள் இருந்தன), அமைப்புகளுடன் ஹேக்குகள், ஒரே ஹோஸ்ட் அமைப்பில் வாழும் வெவ்வேறு சேவைகளுக்கு வெவ்வேறு பதிப்புகளின் தேவை வழிவகுத்தது. இந்த அணுக்கரு கலவையை வழங்குவதற்கான ஒரே நியாயமான வழி டாக்கர் ஆகும். ஒரு டோக்கர் கொள்கலனை அசெம்பிள் செய்வதற்கான உழைப்பு தீவிரம், அனைத்தையும் தனித்தனி டெப் பேக்கேஜ்களில் சார்புகளுடன் பேக் செய்யும் யோசனையை விட குறைவாக மாறியது, உண்மையில் அவர்களின் சரியான மனதில் யாரும் இதை மேற்கொள்ள மாட்டார்கள்.
டோக்கரைப் பயன்படுத்த திட்டமிடப்பட்டுள்ள இரண்டாவது புள்ளி நீல-பச்சை வரிசைப்படுத்தல் திட்டத்தின் படி சேவைகளை வரிசைப்படுத்துவதாகும். ஆனால் இங்கே நான் சிக்கலில் படிப்படியான அதிகரிப்பு பெற விரும்புகிறேன்: முதலில், டெப் தொகுப்புகள் கட்டப்பட்டுள்ளன, பின்னர் அவற்றிலிருந்து ஒரு டோக்கர் கொள்கலன் கட்டப்பட்டது.
ஸ்னாப் தொகுப்புகள்
ஸ்னாப் தொகுப்புகளுக்கு வருவோம். அவை முதலில் உபுண்டு 16.04 இல் அதிகாரப்பூர்வமாகத் தோன்றின. வழக்கமான deb தொகுப்புகள் மற்றும் rpm தொகுப்புகள் போலல்லாமல், snap அனைத்து சார்புகளையும் கொண்டுள்ளது. ஒருபுறம், இது நூலக மோதல்களைத் தவிர்க்க உங்களை அனுமதிக்கிறது, மறுபுறம், இதன் விளைவாக வரும் தொகுப்பு அளவு பெரியது. கூடுதலாக, இது கணினியின் பாதுகாப்பையும் பாதிக்கலாம்: ஸ்னாப் டெலிவரி விஷயத்தில், சேர்க்கப்பட்ட லைப்ரரிகளில் அனைத்து மாற்றங்களும் தொகுப்பை உருவாக்கும் டெவலப்பரால் கண்காணிக்கப்பட வேண்டும். பொதுவாக, எல்லாம் மிகவும் எளிமையானது அல்ல, உலகளாவிய மகிழ்ச்சி அவற்றைப் பயன்படுத்துவதில் இருந்து வரவில்லை. இருப்பினும், அதே டோக்கர் ஒரு பேக்கேஜிங் கருவியாக மட்டுமே பயன்படுத்தப்பட்டால், மெய்நிகராக்கத்திற்காக அல்ல, இது முற்றிலும் நியாயமான மாற்றாகும்.
இதன் விளைவாக, நாங்கள் இப்போது deb தொகுப்புகள் மற்றும் டோக்கர் கொள்கலன்கள் இரண்டையும் ஒரு நியாயமான கலவையில் பயன்படுத்துகிறோம், ஒருவேளை, சில சமயங்களில் நாம் ஸ்னாப் தொகுப்புகளுடன் மாற்றுவோம்.
பதிவு செய்த பயனர்கள் மட்டுமே கணக்கெடுப்பில் பங்கேற்க முடியும்.
டெலிவரிக்கு நீங்கள் எதைப் பயன்படுத்துகிறீர்கள்?
-
சுயமாக எழுதப்பட்ட ஸ்கிரிப்டுகள்
-
FTPக்கு கைமுறையாக நகலெடுக்கவும்
-
deb தொகுப்புகள்
-
rpm தொகுப்புகள்
-
ஸ்னாப் தொகுப்புகள்
-
டோக்கர்-படங்கள்
-
மெய்நிகர் இயந்திர படங்கள்
-
முழு HDDயையும் குளோன் செய்யவும்
-
கைப்பாவை
-
ansible
-
மற்ற
109 பயனர்கள் வாக்களித்தனர். 32 பயனர்கள் வாக்களிக்கவில்லை.
ஆதாரம்: www.habr.com