બીજું કંઈક: હાઈકુ એપ બંડલ્સ?

TL; DR: શું હાઇકુ એપ્લીકેશન પેકેજીસ માટે યોગ્ય સમર્થન મેળવી શકે છે, જેમ કે એપ્લિકેશન ડિરેક્ટરીઓ (જેમ કે .app Mac પર) અને/અથવા એપ્લિકેશન છબીઓ (Linux AppImage)? મને લાગે છે કે આ એક લાયક ઉમેરો હશે જે અન્ય સિસ્ટમો કરતાં યોગ્ય રીતે અમલમાં મૂકવો સરળ છે કારણ કે મોટાભાગની ઈન્ફ્રાસ્ટ્રક્ચર પહેલેથી જ જગ્યાએ છે.

એક અઠવાડિયા પહેલા મેં હાઈકુ શોધ્યું, જે એક અણધારી રીતે સારી સિસ્ટમ છે. ઠીક છે, કારણ કે મને ડિરેક્ટરીઓ અને એપ્લિકેશન છબીઓમાં લાંબા સમયથી રસ છે (મેકિન્ટોશની સરળતાથી પ્રેરિત), તે આશ્ચર્યજનક નથી કે મારા મગજમાં એક વિચાર આવ્યો ...

સંપૂર્ણ સમજણ માટે, હું એપ ઇમેજનો સર્જક અને લેખક છું, એક Linux એપ્લિકેશન વિતરણ ફોર્મેટ કે જે Mac સરળતા માટે લક્ષ્ય રાખે છે અને એપ્લિકેશન લેખકો અને અંતિમ વપરાશકર્તાઓને સંપૂર્ણ નિયંત્રણ આપે છે (જો તમે વધુ જાણવા માંગતા હો, તો જુઓ વિકી и દસ્તાવેજીકરણ).

જો આપણે હાઈકુ માટે AppImage બનાવીએ તો શું?

ચાલો થોડું વિચારીએ, સંપૂર્ણ સૈદ્ધાંતિક રીતે: મેળવવા માટે શું કરવાની જરૂર છે AppImage, અથવા કંઈક એવું જ, હાઈકુ પર? અત્યારે કંઈક બનાવવું જરૂરી નથી, કારણ કે હાઈકુમાં પહેલેથી જ અસ્તિત્વમાં છે તે સિસ્ટમ આશ્ચર્યજનક રીતે કામ કરે છે, પરંતુ એક કાલ્પનિક પ્રયોગ સરસ રહેશે. તે લિનક્સ ડેસ્કટોપ એન્વાયર્નમેન્ટ્સની તુલનામાં હાઈકુની અભિજાત્યપણુ પણ દર્શાવે છે, જ્યાં આવી વસ્તુઓ ભયંકર રીતે મુશ્કેલ છે (મને આમ કહેવાનો અધિકાર છે: હું 10 વર્ષથી ડિબગીંગ સાથે સંઘર્ષ કરી રહ્યો છું).

મેકિન્ટોશ સિસ્ટમ 1 પર, દરેક એપ્લિકેશન ફાઇન્ડરમાં "વ્યવસ્થાપિત" એક અલગ ફાઇલ હતી. AppImage નો ઉપયોગ કરીને હું Linux પર સમાન વપરાશકર્તા અનુભવને ફરીથી બનાવવાનો પ્રયાસ કરી રહ્યો છું.

સૌ પ્રથમ, AppImage શું છે? આ તૃતીય-પક્ષ એપ્લિકેશનો (ઉદાહરણ તરીકે, અલ્ટિમેકર ક્યુરા), એપ્લીકેશનને તેઓ ક્યારે અને કેવી રીતે ઇચ્છે છે તે રીલીઝ કરવાની મંજૂરી આપે છે: વિવિધ વિતરણોની વિશિષ્ટતાઓ જાણવાની, નીતિઓ બનાવવાની અથવા ઇન્ફ્રાસ્ટ્રક્ચર બનાવવાની જરૂર નથી, કોઈ જાળવણીકાર સપોર્ટની જરૂર નથી, અને તેઓ વપરાશકર્તાઓને જણાવતા નથી કે તેઓ શું (નથી) ઇન્સ્ટોલ કરી શકે છે. તેમના કમ્પ્યુટર્સ પર. AppImage ને ફોર્મેટમાં Mac પેકેજ જેવું જ કંઈક સમજવું જોઈએ .app ડિસ્ક ઈમેજની અંદર .dmg. મુખ્ય તફાવત એ છે કે એપ્લીકેશનની નકલ કરવામાં આવતી નથી, પરંતુ AppImage ની અંદર કાયમ રહે છે, જે હાઈકુ પેકેજોની જેમ જ છે. .hpkg માઉન્ટ થયેલ છે, અને સામાન્ય અર્થમાં ક્યારેય ઇન્સ્ટોલ કરેલું નથી.

અસ્તિત્વના 10 વર્ષથી વધુ સમય દરમિયાન, AppImageએ થોડી આકર્ષણ અને લોકપ્રિયતા મેળવી છે: લિનસ ટોરવાલ્ડ્સે પોતે તેને જાહેરમાં સમર્થન આપ્યું છે, અને સામાન્ય પ્રોજેક્ટ્સ (ઉદાહરણ તરીકે, લિબરઓફિસ, ક્રિટા, ઇન્કસ્કેપ, સ્ક્રાઇબસ, ઇમેજમેજિક)એ તેને મુખ્ય માર્ગ તરીકે અપનાવ્યો છે. ઇન્સ્ટોલ કરેલ અથવા અનઇન્સ્ટોલ કરેલ યુઝર એપ્લીકેશનમાં દખલ ન કરતા, સતત અથવા રાત્રિના બિલ્ડ્સનું વિતરણ કરવા. જો કે, લિનક્સ ડેસ્કટોપ એન્વાયર્નમેન્ટ્સ અને ડિસ્ટ્રિબ્યુશન મોટાભાગે હજુ પણ પરંપરાગત, કેન્દ્રિય જાળવણી-આધારિત વિતરણ મોડલને વળગી રહે છે અને/અથવા તેના આધારે તેમના પોતાના એન્ટરપ્રાઇઝ બિઝનેસ અને/અથવા એન્જિનિયરિંગ પ્રોગ્રામ્સને પ્રોત્સાહન આપે છે. Flatpak (RedHat, Fedora, GNOME) અને સ્નીપી (કેનોનિકલ, ઉબુન્ટુ). તે આવે છે હાસ્યાસ્પદ રીતે.

તે બધું કેવી રીતે કાર્ય કરે છે

• દરેક AppImageમાં 2 ભાગો હોય છે: એક નાનું ડબલ-ક્લિક ELF (કહેવાતા. runtime.c), ફાઇલ સિસ્ટમ ઇમેજ દ્વારા અનુસરવામાં આવે છે સ્ક્વૅશએફએસ.

• SquashFS ફાઇલ સિસ્ટમમાં એપ્લિકેશનનો પેલોડ અને તેને ચલાવવા માટે જરૂરી દરેક વસ્તુનો સમાવેશ થાય છે, જે યોગ્ય રીતે દરેક એકદમ તાજેતરની લક્ષ્ય સિસ્ટમ (Linux વિતરણ) માટે ડિફોલ્ટ ઇન્સ્ટોલેશનનો ભાગ ગણી શકાય નહીં. તે મેટાડેટા પણ સમાવે છે, જેમ કે એપ્લિકેશનનું નામ, ચિહ્નો, MIME પ્રકારો, વગેરે, વગેરે.

• જ્યારે વપરાશકર્તા દ્વારા ચલાવવામાં આવે છે, ત્યારે રનટાઇમ ફાઇલસિસ્ટમને માઉન્ટ કરવા માટે FUSE અને સ્ક્વોશફ્યુઝનો ઉપયોગ કરે છે, અને પછી માઉન્ટ થયેલ AppImage ની અંદર કેટલાક એન્ટ્રી પોઈન્ટ (ઉર્ફે AppRun) ચલાવવાનું હેન્ડલ કરે છે.
  પ્રક્રિયા પૂર્ણ થયા પછી ફાઇલ સિસ્ટમ અનમાઉન્ટ થાય છે.

બધું સરળ લાગે છે.

અને આ વસ્તુઓ બધું જટિલ બનાવે છે:

• આવા વિવિધ Linux વિતરણો સાથે, "સાચા મગજમાં" કંઈપણ "દરેક નવી લક્ષ્ય સિસ્ટમ માટે ડિફોલ્ટ ઇન્સ્ટોલેશનનો ભાગ" કહી શકાય નહીં. અમે બિલ્ડીંગ દ્વારા આ મુદ્દા પર કામ કરીએ છીએ બાકાત, તમને એપ ઇમેજમાં શું પેક કરવામાં આવશે અને બીજે ક્યાંક શું લેવાની જરૂર પડશે તે નિર્ધારિત કરવાની મંજૂરી આપે છે. તે જ સમયે, અમે કેટલીકવાર ચૂકી જઈએ છીએ, તે હકીકત હોવા છતાં કે, સામાન્ય રીતે, બધું સરસ કાર્ય કરે છે. આ કારણોસર, અમે ભલામણ કરીએ છીએ કે પેકેજ સર્જકો તમામ લક્ષ્ય સિસ્ટમો (વિતરણો) પર AppImages નું પરીક્ષણ કરે.
• એપ્લિકેશન પેલોડ્સ સમગ્ર ફાઇલ સિસ્ટમમાં સ્થાનાંતરિત કરવા યોગ્ય હોવા જોઈએ. કમનસીબે, ઘણી એપ્લિકેશન્સમાં હાર્ડ-કોડેડ સંપૂર્ણ પાથ હોય છે, ઉદાહરણ તરીકે, માં સંસાધનો /usr/share. આને કોઈક રીતે ઠીક કરવાની જરૂર છે. વધુમાં, તમારે કાં તો નિકાસ કરવું આવશ્યક છે LD_LIBRARY_PATH, અથવા ઠીક કરો rpath જેથી લોડર સંબંધિત પુસ્તકાલયો શોધી શકે. પ્રથમ પદ્ધતિમાં તેની ખામીઓ છે (જે જટિલ રીતે દૂર થાય છે), અને બીજી સરળ રીતે બોજારૂપ છે.
• વપરાશકર્તાઓ માટે સૌથી મોટી UX મુશ્કેલી તે છે એક્ઝિક્યુટેબલ બીટ સેટ કરો AppImage ફાઇલ ડાઉનલોડ કર્યા પછી. માનો કે ના માનો, કેટલાક માટે આ એક વાસ્તવિક અવરોધ છે. એક્ઝેક્યુબિલિટી બીટ સેટ કરવાની જરૂરિયાત અનુભવી વપરાશકર્તાઓ માટે પણ બોજારૂપ છે. ઉકેલ તરીકે, અમે એક નાની સેવા ઇન્સ્ટોલ કરવાનું સૂચન કર્યું છે જે AppImage ફાઇલોનું નિરીક્ષણ કરે છે અને તેમની એક્ઝેક્યુબિલિટી બીટ સેટ કરે છે. તેના શુદ્ધ સ્વરૂપમાં, તે શ્રેષ્ઠ ઉકેલ નથી, કારણ કે તે બોક્સની બહાર કામ કરશે નહીં. Linux વિતરણો આ સેવા પૂરી પાડતા નથી, તેથી, વપરાશકર્તાઓને બોક્સની બહાર ખરાબ અનુભવ છે.
• Linux વપરાશકર્તાઓ અપેક્ષા રાખે છે કે નવી એપ્લિકેશન સ્ટાર્ટઅપ મેનૂમાં આઇકોન ધરાવે છે. તમે સિસ્ટમને કહી શકતા નથી: "જુઓ, એક નવી એપ્લિકેશન છે, ચાલો કામ કરીએ." તેના બદલે, XDG સ્પષ્ટીકરણ અનુસાર, તમારે ફાઇલની નકલ કરવાની જરૂર છે .desktop માં યોગ્ય સ્થાને /usr સિસ્ટમ-વ્યાપી ઇન્સ્ટોલેશન માટે, અથવા માં $HOME વ્યક્તિગત માટે. ચોક્કસ કદના ચિહ્નો, XDG સ્પષ્ટીકરણ અનુસાર, ચોક્કસ સ્થળોએ મૂકવાની જરૂર છે usr અથવા $HOME, અને પછી આઇકોન કેશને અપડેટ કરવા માટે કાર્યકારી વાતાવરણમાં આદેશો ચલાવો, અથવા આશા રાખો કે કાર્યકારી પર્યાવરણ વ્યવસ્થાપક તેને શોધી કાઢશે અને આપમેળે બધું શોધી કાઢશે. MIME પ્રકારો સાથે સમાન. વર્કઅરાઉન્ડ તરીકે, તે જ સેવાનો ઉપયોગ કરવાનો પ્રસ્તાવ છે, જે, એક્ઝિક્યુટેબિલિટી ફ્લેગ સેટ કરવા ઉપરાંત, જો ત્યાં ચિહ્નો હોય, વગેરે. AppImage માં, XDG અનુસાર તેમને AppImage થી યોગ્ય સ્થાનો પર કૉપિ કરો. જ્યારે કાઢી નાખવામાં આવે છે અથવા ખસેડવામાં આવે છે, ત્યારે સેવાને બધું સાફ કરવાની અપેક્ષા રાખવામાં આવે છે. અલબત્ત, દરેક કાર્યકારી વાતાવરણની વર્તણૂકમાં, ગ્રાફિક ફાઇલ ફોર્મેટમાં, તેમના કદ, સંગ્રહ સ્થાનો અને કેશ અપડેટ કરવાની પદ્ધતિઓમાં તફાવત છે, જે સમસ્યા બનાવે છે. ટૂંકમાં, આ પદ્ધતિ એક ક્રૉચ છે.
• જો ઉપરોક્ત પૂરતું નથી, તો ફાઇલ મેનેજરમાં હજી પણ કોઈ AppImage આયકન નથી. Linux વિશ્વએ હજુ સુધી એલ્ફિકોનને અમલમાં મૂકવાનો નિર્ણય લીધો નથી (છતાં ચર્ચા и અમલીકરણ), તેથી આયકનને સીધા જ એપ્લિકેશનમાં એમ્બેડ કરવું અશક્ય છે. તેથી તે તારણ આપે છે કે ફાઇલ મેનેજરમાં એપ્લિકેશનો પાસે તેમના પોતાના ચિહ્નો નથી (કોઈ તફાવત નથી, AppImage અથવા બીજું કંઈક), તે ફક્ત પ્રારંભ મેનૂમાં છે. એક ઉપાય તરીકે, અમે થંબનેલ્સનો ઉપયોગ કરી રહ્યા છીએ, એક પદ્ધતિ કે જે મૂળરૂપે ડેસ્કટોપ મેનેજરોને તેમના આઇકોન તરીકે ગ્રાફિક ફાઇલોની થંબનેલ પૂર્વાવલોકન છબીઓ બતાવવાની મંજૂરી આપવા માટે બનાવવામાં આવી હતી. તેથી, એક્ઝેક્યુબિલિટી બીટ સેટ કરવા માટેની સેવા "મિનિએચરાઇઝર" તરીકે પણ કામ કરે છે, યોગ્ય સ્થાનો પર આઇકોન થંબનેલ્સ બનાવવા અને લખવા. /usr и $HOME. જો AppImage કાઢી નાખવામાં આવે અથવા ખસેડવામાં આવે તો આ સેવા સફાઈ પણ કરે છે. હકીકત એ છે કે દરેક ડેસ્કટોપ મેનેજર સહેજ અલગ રીતે વર્તે છે, ઉદાહરણ તરીકે, તે કયા ફોર્મેટમાં ચિહ્નો સ્વીકારે છે, કયા કદમાં અથવા સ્થાનો પર, આ બધું ખરેખર પીડાદાયક છે.
• જો ભૂલો થાય (ઉદાહરણ તરીકે, ત્યાં એક લાઇબ્રેરી છે જે બેઝ સિસ્ટમનો ભાગ નથી અને AppImage માં પૂરી પાડવામાં આવતી નથી), અને GUI માં વપરાશકર્તાને ખરેખર શું થઈ રહ્યું છે તે વિશે કોઈ કહેતું નથી. અમે ઉપયોગ કરીને આ આસપાસ વિચાર શરૂ કર્યું સૂચનાઓ ડેસ્કટોપ પર, જેનો અર્થ છે કે આપણે કમાન્ડ લાઇનમાંથી ભૂલોને પકડવાની જરૂર છે, તેમને વપરાશકર્તા-સમજાયેલા સંદેશાઓમાં રૂપાંતરિત કરવાની જરૂર છે, જે પછી ડેસ્કટોપ પર પ્રદર્શિત કરવાની જરૂર છે. અને અલબત્ત, દરેક ડેસ્કટોપ પર્યાવરણ તેમને થોડી અલગ રીતે હેન્ડલ કરે છે.
• આ ક્ષણે (સપ્ટેમ્બર 2019 - અનુવાદકની નોંધ) મને સિસ્ટમને કહેવાની સરળ રીત મળી નથી કે ફાઇલ 1.png Krita નો ઉપયોગ કરીને ખોલવું આવશ્યક છે, અને 2.png - GIMP નો ઉપયોગ કરીને.

માં વપરાયેલ ક્રોસ-ડેસ્કટોપ વિશિષ્ટતાઓ માટે સંગ્રહ સ્થાન જીનોમ, KDE и Xfce freedesktop.org છે

હાઇકુ કાર્ય વાતાવરણમાં ઊંડે વણાયેલા અભિજાત્યપણુનું સ્તર હાંસલ કરવું મુશ્કેલ છે, જો અશક્ય ન હોય તો, વિશિષ્ટતાઓને કારણે freedesktop.org પરથી XDG ક્રોસ-ડેસ્કટોપ માટે, તેમજ આ સ્પષ્ટીકરણોના આધારે ડેસ્કટોપ મેનેજરોના અમલીકરણ માટે. ઉદાહરણ તરીકે, અમે એક સિસ્ટમ-વ્યાપી ફાયરફોક્સ આઇકોન ટાંકી શકીએ છીએ: દેખીતી રીતે, XDG ના લેખકોએ વિચાર્યું પણ ન હતું કે વપરાશકર્તા પાસે સમાન એપ્લિકેશનના ઘણા સંસ્કરણો ઇન્સ્ટોલ થઈ શકે છે.

ફાયરફોક્સના વિવિધ સંસ્કરણો માટેના ચિહ્નો

હું વિચારી રહ્યો હતો કે સિસ્ટમ એકીકરણને ખરાબ ન કરવા માટે Linux વિશ્વ Mac OS X પાસેથી શું શીખી શકે છે. જો તમારી પાસે સમય હોય અને તમે આમાં છો, તો પ્રથમ Mac OS X એન્જિનિયરોમાંના એક આર્નોડ ગુરડોલે શું કહ્યું તે વાંચવાની ખાતરી કરો:

અમે એપ્લીકેશનને ઇન્સ્ટોલ કરવાનું એટલુ જ સરળ બનાવવા માંગીએ છીએ જેટલું તમારી કોમ્પ્યુટર ડ્રાઇવ પર ક્યાંકથી (સર્વર, એક્સટર્નલ ડ્રાઇવ) એપ્લીકેશન આઇકોનને ખેંચવા જેવું છે. આ કરવા માટે, એપ્લિકેશન પેકેજ બધી માહિતી સંગ્રહિત કરે છે, જેમાં ચિહ્નો, સંસ્કરણ, પ્રક્રિયા કરવામાં આવી રહેલી ફાઇલનો પ્રકાર, URL સ્કીમનો પ્રકાર કે જે સિસ્ટમને એપ્લિકેશન પર પ્રક્રિયા કરવા માટે જાણવાની જરૂર છે. આમાં આઇકોન સર્વિસીસ અને લોન્ચ સર્વિસ ડેટાબેઝમાં 'સેન્ટ્રલ સ્ટોરેજ' માટેની માહિતીનો પણ સમાવેશ થાય છે. પ્રદર્શનને સમર્થન આપવા માટે, એપ્લીકેશનો ઘણા 'જાણીતા' સ્થળોએ 'શોધવામાં' આવે છે: સિસ્ટમ અને વપરાશકર્તા એપ્લિકેશન ડિરેક્ટરીઓ, અને કેટલીક અન્ય આપમેળે જો વપરાશકર્તા એપ્લિકેશન ધરાવતી ડિરેક્ટરીમાં ફાઇન્ડર પર નેવિગેટ કરે છે. વ્યવહારમાં આ ખૂબ જ સારી રીતે કામ કર્યું.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 સત્ર 144 - Mac OS X: પેકેજિંગ એપ્લિકેશન્સ અને પ્રિન્ટિંગ દસ્તાવેજો.

Linux ડેસ્કટોપ પર આ ઈન્ફ્રાસ્ટ્રક્ચર જેવું કંઈ નથી, તેથી અમે AppImage પ્રોજેક્ટમાં માળખાકીય મર્યાદાઓની આસપાસના ઉકેલો શોધી રહ્યા છીએ.

શું હાઈકુ બચાવમાં આવી રહ્યું છે?

અને એક વધુ વસ્તુ: ડેસ્કટોપ એન્વાયર્નમેન્ટના આધાર તરીકે લિનક્સ પ્લેટફોર્મ્સ એટલા અન્ડરસ્પેસિફાઇડ હોય છે કે સુસંગત ફુલ-સ્ટેક સિસ્ટમમાં એકદમ સરળ હોય તેવી ઘણી વસ્તુઓ Linux માં નિરાશાજનક રીતે વિભાજિત અને જટિલ છે. મેં ડેસ્કટૉપ એન્વાયર્નમેન્ટ્સ માટે લિનક્સ પ્લેટફોર્મને લગતી સમસ્યાઓ માટે આખો રિપોર્ટ સમર્પિત કર્યો છે (જાણકાર વિકાસકર્તાઓએ પુષ્ટિ કરી છે કે બધું ખૂબ લાંબા સમય સુધી આ રીતે રહેશે).

2018 માં લિનક્સ ડેસ્કટોપ પર્યાવરણોની સમસ્યાઓ પરનો મારો અહેવાલ

લીનસ ટોરવાલ્ડ્સે પણ સ્વીકાર્યું કે વર્કસ્પેસ વિચાર નિષ્ફળ કેમ થયો તે ફ્રેગમેન્ટેશન હતું.

હાઈકુ જોઈને આનંદ થયો!

હાઈકુ બધું અદ્ભુત રીતે સરળ બનાવે છે

જ્યારે Haiku માટે AppImage ને "પોર્ટિંગ" કરવા માટેનો નિષ્કપટ અભિગમ એ છે કે તેના ઘટકો (મુખ્યત્વે runtime.c અને સર્વિસ) બનાવવાનો પ્રયત્ન કરવો (જે શક્ય પણ હોઈ શકે!), આ હાઈકુને વધુ લાભ આપશે નહીં. કારણ કે વાસ્તવમાં, આમાંની મોટાભાગની સમસ્યાઓ હાઇકુમાં ઉકેલાય છે અને કલ્પનાત્મક રીતે સાઉન્ડ છે. હાઈકુ એ સિસ્ટમ ઈન્ફ્રાસ્ટ્રક્ચર બિલ્ડીંગ બ્લોક્સ પૂરા પાડે છે જે હું ઘણા લાંબા સમયથી Linux ડેસ્કટોપ વાતાવરણમાં શોધી રહ્યો છું અને ત્યાં નહોતા તે માની શકતો નથી. જેમ કે:

માનો કે ના માનો, આ એવી વસ્તુ છે જે ઘણા Linux વપરાશકર્તાઓ દૂર કરી શકતા નથી. હાઈકુ પર બધું આપોઆપ થઈ જાય છે!

• ELF ફાઇલો કે જેમાં એક્ઝેક્યુબિલિટી બીટ નથી તે ફાઇલ મેનેજરમાં ડબલ-ક્લિક કરવા પર આપમેળે એક મેળવે છે.
• એપ્લિકેશન્સમાં બિલ્ટ-ઇન સંસાધનો હોઈ શકે છે, જેમ કે ચિહ્નો, જે ફાઇલ મેનેજરમાં પ્રદર્શિત થાય છે. ચિહ્નો સાથે ખાસ ડિરેક્ટરીઓમાં છબીઓના સમૂહની નકલ કરવાની જરૂર નથી, અને તેથી એપ્લિકેશનને કાઢી નાખ્યા અથવા ખસેડ્યા પછી તેને સાફ કરવાની જરૂર નથી.
• દસ્તાવેજો સાથે એપ્લિકેશનને લિંક કરવા માટે એક ડેટાબેઝ છે, આ માટે કોઈપણ ફાઇલોની નકલ કરવાની જરૂર નથી.
• એક્ઝેક્યુટેબલ ફાઇલની બાજુમાં lib/ ડિરેક્ટરીમાં, લાઇબ્રેરીઓ મૂળભૂત રીતે શોધાય છે.
• ત્યાં કોઈ અસંખ્ય વિતરણો અને ડેસ્કટોપ વાતાવરણ નથી, જે પણ કામ કરે છે, દરેક જગ્યાએ કાર્ય કરે છે.
• ચલાવવા માટે કોઈ અલગ મોડ્યુલ નથી જે એપ્લિકેશન ડાયરેક્ટરીથી અલગ હોય.
• એપ્લિકેશન્સમાં તેમના સંસાધનોના બિલ્ટ-ઇન સંપૂર્ણ પાથ નથી; તેઓ રનટાઇમ પર સ્થાન નક્કી કરવા માટે વિશેષ કાર્યો ધરાવે છે.
• સંકુચિત ફાઇલ સિસ્ટમ છબીઓનો વિચાર રજૂ કરવામાં આવ્યો છે: આ કોઈપણ hpkg પેકેજ છે. તે બધા કર્નલ દ્વારા માઉન્ટ થયેલ છે.
• દરેક ફાઇલને તે એપ્લિકેશન દ્વારા ખોલવામાં આવે છે જેણે તેને બનાવી છે, સિવાય કે તમે સ્પષ્ટપણે અન્યથા સ્પષ્ટ કરો. આ કેટલું સરસ છે!

બે png ફાઇલો. જ્યારે ડબલ-ક્લિક કરવામાં આવે ત્યારે વિવિધ એપ્લિકેશનો દ્વારા ખોલવામાં આવશે તે દર્શાવતા વિવિધ ચિહ્નોની નોંધ લો. "આની સાથે ખોલો:" ડ્રોપ-ડાઉન મેનૂની પણ નોંધ લો જ્યાં વપરાશકર્તા વ્યક્તિગત એપ્લિકેશન પસંદ કરી શકે છે. કેટલું સરળ!

એવું લાગે છે કે લિનક્સ પર AppImage દ્વારા જરૂરી ઘણા ક્રૉચ અને વર્કઅરાઉન્ડ્સ હાઇકુ પર બિનજરૂરી બની જાય છે, જે તેના મૂળમાં સરળતા અને અભિજાત્યપણુ ધરાવે છે જે તેને અમારી મોટાભાગની જરૂરિયાતોને નિયંત્રિત કરે છે.

શું હાઈકુને આખરે એપ્લિકેશન પેકેજની જરૂર છે?

આ એક મોટો પ્રશ્ન ઉભો કરે છે. જો લિનક્સ કરતાં હાઈકુ પર AppImage જેવી સિસ્ટમ બનાવવી વધુ સરળ હોય, તો શું તે કરવું યોગ્ય હતું? અથવા હાઈકુએ તેની hpkg પેકેજ સિસ્ટમ સાથે આવા વિચાર વિકસાવવાની જરૂરિયાતને અસરકારક રીતે દૂર કરી છે? ઠીક છે, જવાબ આપવા માટે આપણે AppImages ના અસ્તિત્વ પાછળની પ્રેરણા જોવાની જરૂર છે.

વપરાશકર્તાનો પરિપ્રેક્ષ્ય

ચાલો અમારા અંતિમ વપરાશકર્તાને જોઈએ:

• હું એડમિનિસ્ટ્રેટર (રુટ) પાસવર્ડ પૂછ્યા વિના એપ્લિકેશન ઇન્સ્ટોલ કરવા માંગુ છું. હાઈકુ પર એડમિનિસ્ટ્રેટરનો કોઈ ખ્યાલ નથી, વપરાશકર્તા પાસે સંપૂર્ણ નિયંત્રણ છે કારણ કે તે એક વ્યક્તિગત સિસ્ટમ છે! (સૈદ્ધાંતિક રીતે, તમે મલ્ટિપ્લેયર મોડમાં આની કલ્પના કરી શકો છો, હું આશા રાખું છું કે વિકાસકર્તાઓ તેને સરળ રાખે)
• હું એપ્લિકેશનના નવીનતમ અને શ્રેષ્ઠ સંસ્કરણો મેળવવા માંગુ છું, મારા વિતરણમાં તે દેખાય તેની રાહ જોયા વિના (મોટાભાગે આનો અર્થ "ક્યારેય નહીં" થાય છે, જ્યાં સુધી હું આખી ઑપરેટિંગ સિસ્ટમ અપડેટ ન કરું ત્યાં સુધી નહીં). હાઈકુ પર આ ફ્લોટિંગ પ્રકાશનો સાથે "ઉકેલ" છે. આનો અર્થ એ છે કે એપ્લિકેશનના નવીનતમ અને શ્રેષ્ઠ સંસ્કરણો મેળવવાનું શક્ય છે, પરંતુ આ કરવા માટે તમારે બાકીની સિસ્ટમને સતત અપડેટ કરવાની જરૂર છે, અસરકારક રીતે તેને "મૂવિંગ ટાર્ગેટ" માં ફેરવીને..
• મને એક જ એપ્લીકેશનના અનેક વર્ઝન એકસાથે જોઈએ છે, કારણ કે નવીનતમ સંસ્કરણમાં શું તૂટી ગયું છે તે જાણવાની કોઈ રીત નથી, અથવા, કહો કે, એક વેબ ડેવલપર તરીકે, મને બ્રાઉઝરના વિવિધ સંસ્કરણો હેઠળ મારા કાર્યનું પરીક્ષણ કરવાની જરૂર છે. હાઈકુ પ્રથમ સમસ્યાનું નિરાકરણ લાવે છે, પરંતુ બીજી સમસ્યા નથી. અપડેટ્સ પાછું ફેરવવામાં આવે છે, પરંતુ માત્ર સમગ્ર સિસ્ટમ માટે તે ચલાવવું અશક્ય છે (જ્યાં સુધી હું જાણું છું), ઉદાહરણ તરીકે, એક જ સમયે WebPositive અથવા LibreOffice ના ઘણા સંસ્કરણો.

વિકાસકર્તાઓમાંના એક લખે છે:

મૂળભૂત રીતે તર્ક આ છે: ઉપયોગનો કેસ એટલો દુર્લભ છે કે તેના માટે ઑપ્ટિમાઇઝ કરવાનો કોઈ અર્થ નથી; હાઈકુપોર્ટ્સમાં તેને વિશેષ કેસ તરીકે ગણવું એ સ્વીકાર્ય કરતાં વધુ લાગે છે.

• મારી સ્ટાર્ટઅપ ડ્રાઇવ પર નહીં, પણ મને એપ્સ ગમે ત્યાં રાખવાની જરૂર છે. મારી પાસે ઘણી વખત ડિસ્ક સ્પેસ સમાપ્ત થઈ જાય છે, તેથી મને એપ્લીકેશન સ્ટોર કરવા માટે બાહ્ય ડ્રાઈવ અથવા નેટવર્ક ડિરેક્ટરી કનેક્ટ કરવાની જરૂર છે (મેં ડાઉનલોડ કરેલ તમામ સંસ્કરણો). જો હું આવી ડ્રાઇવને કનેક્ટ કરું છું, તો મને ડબલ-ક્લિક કરીને એપ્લિકેશન શરૂ કરવાની જરૂર છે. હાઈકુ પેકેજોના જૂના સંસ્કરણોને સાચવે છે, પરંતુ મને ખબર નથી કે તેમને બાહ્ય ડ્રાઈવમાં કેવી રીતે ખસેડવું અથવા પછીથી ત્યાંથી એપ્લિકેશન કેવી રીતે શરૂ કરવી.

વિકાસકર્તા ટિપ્પણી:

તકનીકી રીતે, આ માઉન્ટ આદેશ સાથે પહેલેથી જ શક્ય છે. અલબત્ત, અમારી પાસે પર્યાપ્ત રસ ધરાવતા વપરાશકર્તાઓ હશે કે તરત જ અમે આ માટે GUI બનાવીશું.

• મને ફાઇલ સિસ્ટમમાં પથરાયેલી લાખો ફાઇલોની જરૂર નથી કે જે હું જાતે મેન્યુઅલી મેનેજ કરી શકતો નથી. મને એપ્લિકેશન દીઠ એક ફાઇલ જોઈએ છે જે હું સરળતાથી ડાઉનલોડ કરી શકું, ખસેડી શકું, કાઢી શકું. હાઈકુ પર આ સમસ્યાને પેકેજની મદદથી ઉકેલવામાં આવે છે .hpkg, જે ટ્રાન્સફર કરે છે, ઉદાહરણ તરીકે, python, હજારો ફાઇલોમાંથી એકમાં. પરંતુ જો ત્યાં છે, ઉદાહરણ તરીકે, પાયથોનનો ઉપયોગ કરીને સ્ક્રિબસ, તો મારે ઓછામાં ઓછી બે ફાઇલો સાથે વ્યવહાર કરવો પડશે. અને મારે તેમની આવૃત્તિઓ રાખવાની કાળજી લેવી પડશે જે એકબીજા સાથે કામ કરે છે.

AppImages ની બહુવિધ આવૃત્તિઓ એક જ Linux પર બાજુમાં ચાલી રહી છે

એપ્લિકેશન ડેવલપરનો પરિપ્રેક્ષ્ય

ચાલો એપ્લિકેશન ડેવલપરના દૃષ્ટિકોણથી જોઈએ:

• હું સમગ્ર વપરાશકર્તા અનુભવને નિયંત્રિત કરવા માંગુ છું. મારે ક્યારે અને કેવી રીતે અરજીઓ રિલીઝ કરવી જોઈએ તે જણાવવા માટે હું ઓપરેટિંગ સિસ્ટમ પર આધાર રાખવા માંગતો નથી. હાઈકુ વિકાસકર્તાઓને તેમની પોતાની hpkg રિપોઝીટરીઝ સાથે કામ કરવાની મંજૂરી આપે છે, પરંતુ આનો અર્થ એ છે કે વપરાશકર્તાઓએ તેને મેન્યુઅલી સેટ કરવું પડશે, જે વિચારને "ઓછા આકર્ષક" બનાવે છે.
• મારી વેબસાઇટ પર મારી પાસે એક ડાઉનલોડ પૃષ્ઠ છે જ્યાં હું વિતરણ કરું છું .exe વિન્ડોઝ માટે, .dmg મેક માટે અને .AppImage Linux માટે. અથવા કદાચ હું આ પૃષ્ઠની ઍક્સેસનું મુદ્રીકરણ કરવા માંગુ છું, કંઈપણ શક્ય છે? હાઈકુ માટે મારે ત્યાં શું મૂકવું જોઈએ? ફાઇલ પૂરતી છે .hpkg માત્ર હાઈકુપોર્ટ્સથી નિર્ભરતા સાથે
• મારા સૉફ્ટવેરને અન્ય સૉફ્ટવેરના વિશિષ્ટ સંસ્કરણોની જરૂર છે. ઉદાહરણ તરીકે, તે જાણીતું છે કે ક્રિતાને ક્યુટીના પેચ કરેલ સંસ્કરણની જરૂર છે, અથવા ક્યુટી કે જે ક્રિતાના ચોક્કસ સંસ્કરણ સાથે ફાઇન-ટ્યુન થયેલ છે, ઓછામાં ઓછું જ્યાં સુધી પેચોને Qt માં પાછા ન ધકેલવામાં આવે ત્યાં સુધી. તમે તમારી એપ્લિકેશન માટે તમારી પોતાની Qt પેકેજમાં પેકેજ કરી શકો છો .hpkg, પરંતુ મોટે ભાગે આ આવકાર્ય નથી.

નિયમિત એપ્લિકેશન ડાઉનલોડ પૃષ્ઠ. હાઈકુ માટે મારે અહીં શું પોસ્ટ કરવું જોઈએ?

વિલ બંડલ્સ (એપ્લિકેશન ડિરેક્ટરીઓ તરીકે અસ્તિત્વમાં છે જેમ કે AppDir અથવા .app Apple શૈલીમાં) અને/અથવા છબીઓ (અત્યંત સંશોધિત AppImages અથવા .dmg એપલ તરફથી) એપ્લિકેશનો હાઇકુ ડેસ્કટોપ પર્યાવરણમાં ઉપયોગી ઉમેરો છે? અથવા તે સમગ્ર ચિત્રને પાતળું કરશે અને વિભાજન તરફ દોરી જશે, અને તેથી જટિલતા ઉમેરશે? હું ફાટી ગયો છું: એક તરફ, હાઈકુની સુંદરતા અને અભિજાત્યપણુ એ હકીકત પર આધારિત છે કે સામાન્ય રીતે ઘણી જગ્યાએ કંઈક કરવાની એક રીત હોય છે. બીજી તરફ, કેટલોગ અને/અથવા એપ્લીકેશન સ્યુટ્સ માટે મોટાભાગની ઈન્ફ્રાસ્ટ્રક્ચર પહેલેથી જ જગ્યાએ છે, તેથી સિસ્ટમ બાકીના થોડા ટકા સ્થાન પર આવવા માટે પોકાર કરે છે.

વિકાસકર્તા અનુસાર શ્રીમાન. waddlesplash

લિનક્સ પર તેઓ (કેટલોગ અને એપ્લિકેશન કિટ્સ, - આશરે. અનુવાદક) મોટે ભાગે પ્રણાલીગત સમસ્યાઓ માટે તકનીકી ઉકેલ છે. હાઈકુમાં અમે સિસ્ટમની સમસ્યાઓનું નિરાકરણ કરવાનું પસંદ કરીએ છીએ.

તમે શુ વિચારો છો, તમને શુ લાગે છે?

તમે જવાબ આપો તે પહેલાં...

રાહ જુઓ, ચાલો એક ઝડપી વાસ્તવિકતા તપાસ કરીએ: હકીકતમાં એપ્લિકેશન ડિરેક્ટરીઓ - હાઈકુનો પહેલેથી જ ભાગ:

હાઇકુ પર એપ્લિકેશન ડિરેક્ટરીઓ પહેલેથી જ અસ્તિત્વમાં છે, પરંતુ ફાઇલ મેનેજરમાં હજી સુધી સપોર્ટેડ નથી

તેઓ મેકિન્ટોશ ફાઇન્ડરની જેમ સમર્થિત નથી. જો QtCreator ડિરેક્ટરીમાં ઉપરના ડાબા ખૂણામાં "QtCreator" નામ અને આઇકન હોય, જ્યારે ડબલ-ક્લિક કરવામાં આવે ત્યારે એપ્લીકેશન લોન્ચ કરવામાં આવે તો તે કેટલું સરસ રહેશે?

થોડા સમય પહેલા હું પહેલેથી જ પૂછ્યું:

શું તમને ખાતરી છે કે તમે આજે તમારી દાયકા જૂની એપ્સ ચલાવી શકશો જ્યારે તમામ એપ સ્ટોર્સ અને ડિસ્ટ્રિબ્યુશન રિપોઝીટરીઝ તેમના વિશે અને તેમની અવલંબન વિશે ભૂલી ગયા છે? શું તમને વિશ્વાસ છે કે તમે હજુ પણ ભવિષ્યમાં તમારી વર્તમાન નોકરીને ઍક્સેસ કરી શકશો?

શું હાઈકુ તરફથી પહેલેથી જ કોઈ જવાબ છે, અથવા કેટલોગ અને એપ્લિકેશન બંડલ અહીં મદદ કરી શકે છે? મને લાગે છે કે તેઓ કરી શકે છે.

મિસ્ટર મુજબ. waddlesplash:

હા, અમારી પાસે પ્રશ્નનો જવાબ છે: જ્યાં સુધી કોઈ વ્યક્તિ તેમના ફાઇલ ફોર્મેટને યોગ્ય રીતે વાંચી ન શકે અથવા એક-થી-એક કાર્યક્ષમતા પ્રદાન ન કરી શકે ત્યાં સુધી અમે આ એપ્લિકેશનોને જરૂરી હોય ત્યાં સુધી સમર્થન આપીશું. હાઈકુ પર BeOS R5 એપ્સને સમર્થન આપવા માટેની અમારી પ્રતિબદ્ધતા આનો પુરાવો છે...

તે ખાતરી માટે છે!

હાઈકુએ શું પગલાં લેવા જોઈએ?

હું hpkg, ડિરેક્ટરીઓ અને એપ્લિકેશન છબીઓના શાંતિપૂર્ણ સહઅસ્તિત્વની કલ્પના કરી શકું છું:

• સિસ્ટમ સોફ્ટવેર વાપરે છે .hpkg
• સૌથી વધુ ઉપયોગમાં લેવાતા સૉફ્ટવેર માટે (ખાસ કરીને જેમને રોલિંગ રિલીઝ શેડ્યૂલ કરવાની જરૂર છે), ઉપયોગ કરો .hpkg (બધા કેસોમાં લગભગ 80%)
• કેટલાક મારફતે સ્થાપિત .hpkg, એપ્લિકેશનોને એપ્લીકેશન ડાયરેક્ટરી ઈન્ફ્રાસ્ટ્રક્ચર (દા.ત. QtCreator) પર જવાથી ફાયદો થશે: તેઓ આ રીતે વિતરિત કરવામાં આવશે .hpkg, પહેલાની જેમ.

શ્રીમાન. waddlesplash લખે છે:

જો તમારે ફક્ત એપ્લિકેશન્સ જોવાની જરૂર હોય તો /system/apps, તેના બદલે આપણે ડેસ્કબારમાંની ડિરેક્ટરીઓ વપરાશકર્તાઓ માટે વધુ વ્યવસ્થિત બનાવવી જોઈએ, ત્યારથી /system/apps વપરાશકર્તાઓ દ્વારા નિયમિતપણે ખોલવા અને જોવાનો હેતુ નથી (મેકઓએસથી વિપરીત). આવી પરિસ્થિતિઓ માટે, હાઈકુમાં એક અલગ દાખલો છે, પરંતુ આ વિકલ્પ, સિદ્ધાંતમાં, સ્વીકાર્ય છે.

• હાઈકુ એપ્લીકેશન ઈમેજીસ ચલાવવા માટે ઈન્ફ્રાસ્ટ્રક્ચર મેળવે છે, રાત્રિના સમયે, સૉફ્ટવેરના સતત અને પરીક્ષણ બિલ્ડ્સ, તેમજ જ્યારે વપરાશકર્તા "સમયસર તેને સ્થિર કરવા" માંગે છે ત્યારે ખાનગી અને આંતરિક સૉફ્ટવેર માટે અને અન્ય વિશિષ્ટ ઉપયોગના કિસ્સાઓ (લગભગ 20%) તમામ). આ છબીઓમાં એપ્લિકેશન ચલાવવા માટે જરૂરી ફાઇલો છે .hpkg, સિસ્ટમ દ્વારા માઉન્ટ થયેલ છે, અને એપ્લિકેશન પૂર્ણ થયા પછી - અનમાઉન્ટ થયેલ છે. (કદાચ ફાઇલ મેનેજર ફાઇલો મૂકી શકે છે .hpkg એપ્લિકેશન છબીઓમાં, આપમેળે અથવા વપરાશકર્તાની વિનંતી પર - સારું, જેમ કે જ્યારે તમે એપ્લિકેશનને નેટવર્ક ડિરેક્ટરી અથવા બાહ્ય ડ્રાઇવ પર ખેંચો છો. તે માત્ર એક ગીત છે! અથવા તેના બદલે, કવિતા - હાઈકુ.) બીજી બાજુ, વપરાશકર્તા કદાચ ફાઈલોના રૂપમાં ઈમેજની સામગ્રીઓ ઇન્સ્ટોલ કરવા માંગે છે..hpkg, જે પછી તેઓને અપડેટ કરવામાં આવશે અને તે જ રીતે પ્રક્રિયા કરવામાં આવશે જેમ કે તેઓ HaikuDepot દ્વારા ઇન્સ્ટોલ કરવામાં આવ્યા હતા... અમારે મંથન કરવાની જરૂર છે).

શ્રી પાસેથી અવતરણ. waddlesplash:

બાહ્ય ડ્રાઈવો અથવા નેટવર્ક ડિરેક્ટરીઓમાંથી એપ્લીકેશન ચલાવવાનું સંભવિત રીતે ઉપયોગી થઈ શકે છે. અને pkgman માટે વધુ "ઝોન" રૂપરેખાંકિત કરવાની ક્ષમતા ઉમેરવી એ ચોક્કસપણે એક સરસ લક્ષણ હશે.

આવી સિસ્ટમ hpkg, ડિરેક્ટરીઓ અને એપ્લિકેશન ઈમેજોનો લાભ લેશે. તેઓ વ્યક્તિગત રીતે સારા છે, પરંતુ સાથે મળીને તેઓ અજેય બનશે.

નિષ્કર્ષ

હાઈકુ પાસે એક માળખું છે જે પીસી માટે સરળ અને અત્યાધુનિક વપરાશકર્તા અનુભવ પ્રદાન કરે છે, અને તે સામાન્ય રીતે Linux PC માટે પ્રદાન કરવામાં આવે છે તેના કરતાં ઘણું આગળ જાય છે. પેકેજ સિસ્ટમ .hpkg આવું જ એક ઉદાહરણ છે, પરંતુ બાકીની સિસ્ટમ પણ અભિજાત્યપણુથી તરબોળ છે. જો કે, હાઈકુને યોગ્ય ડિરેક્ટરી અને એપ્લિકેશન ઈમેજ સપોર્ટથી ફાયદો થશે. આ કેવી રીતે કરવું શ્રેષ્ઠ છે તે લોકો સાથે ચર્ચા કરવા યોગ્ય છે જેઓ હાઈકુ, તેની ફિલસૂફી અને આર્કિટેક્ચરને મારા કરતા વધુ સારી રીતે જાણે છે. છેવટે, હું એક અઠવાડિયાથી થોડા સમય માટે હાઈકુનો ઉપયોગ કરી રહ્યો છું. તેમ છતાં, હું માનું છું કે હાઇકુના ડિઝાઇનરો, વિકાસકર્તાઓ અને આર્કિટેક્ટ્સને આ નવા પરિપ્રેક્ષ્યથી લાભ થશે. ઓછામાં ઓછું, હું તેમના "ઝડપી ભાગીદાર" બનવા માટે ખુશ થઈશ. મને Linux એપ્લિકેશન કેટલોગ અને બંડલ્સ સાથે 10 વર્ષથી વધુનો અનુભવ છે, અને હું હાઈકુમાં તેમના માટે ઉપયોગ શોધવા માંગુ છું, જેના માટે મને લાગે છે કે તેઓ યોગ્ય છે. મેં જે સંભવિત ઉકેલો પ્રસ્તાવિત કર્યા છે તે કોઈ પણ રીતે મેં વર્ણવેલ સમસ્યાઓ માટે યોગ્ય નથી, અને જો હાઈકુ ટીમ અન્ય, વધુ ભવ્ય મુદ્દાઓ શોધવાનું નક્કી કરે છે, તો હું તેના માટે સંપૂર્ણ છું. મૂળભૂત રીતે, હું પહેલેથી જ સિસ્ટમ કેવી રીતે બનાવવી તે વિચાર વિશે વિચારી રહ્યો છું hpkg તે કામ કરવાની રીતને બદલ્યા વિના પણ વધુ આકર્ષક. તે તારણ આપે છે કે પેકેજ મેનેજમેન્ટ સિસ્ટમ લાગુ કરતી વખતે હાઈકુ ટીમ લાંબા સમયથી એપ્લિકેશન બંડલ વિશે વિચારતી હતી, પરંતુ કમનસીબે (મને લાગે છે) આ વિચાર "અપ્રચલિત" થઈ ગયો છે. કદાચ તેને પુનર્જીવિત કરવાનો સમય છે?

તેને જાતે અજમાવી જુઓ! છેવટે, હાઈકુ પ્રોજેક્ટ ડીવીડી અથવા યુએસબી માંથી બુટ કરવા માટે ઈમેજો પ્રદાન કરે છે, જે જનરેટ થાય છે દૈનિક.
શું તમારી પાસે કોઈ પ્રશ્નો છે? અમે તમને રશિયન બોલતા માટે આમંત્રિત કરીએ છીએ ટેલિગ્રામ ચેનલ.

ભૂલ વિહંગાવલોકન: C અને C++ માં પગમાં તમારી જાતને કેવી રીતે મારવી. હાઈકુ ઓએસ રેસીપી સંગ્રહ

થી લેખક અનુવાદ: હાઈકુ વિશેની શ્રેણીનો આ આઠમો અને અંતિમ લેખ છે.

લેખોની સૂચિ: પ્રથમ બીજો ત્રીજો ચોથું પાંચમો છઠ્ઠા સાતમી

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

શું hpkg સિસ્ટમને Linux પર પોર્ટ કરવાનો અર્થ છે?

• હા

• કોઈ

• પહેલેથી જ અમલમાં મૂકાયેલ છે, હું ટિપ્પણીઓમાં લખીશ

20 વપરાશકર્તાઓએ મતદાન કર્યું. 5 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com