🥇ಬೇರೆ ಏನಾದರೂ: ಹೈಕು ಅಪ್ಲಿಕೇಶನ್ ಬಂಡಲ್‌ಗಳು?

ಟಿಎಲ್; ಡಿಆರ್: ಅಪ್ಲಿಕೇಶನ್ ಡೈರೆಕ್ಟರಿಗಳಂತಹ ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೇಜುಗಳಿಗೆ ಹೈಕು ಸರಿಯಾದ ಬೆಂಬಲವನ್ನು ಪಡೆಯಬಹುದೇ (ಹಾಗೆ .app Mac ನಲ್ಲಿ) ಮತ್ತು/ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಚಿತ್ರಗಳು (Linux AppImage)? ಹೆಚ್ಚಿನ ಮೂಲಸೌಕರ್ಯಗಳು ಈಗಾಗಲೇ ಸ್ಥಳದಲ್ಲಿರುವುದರಿಂದ ಇದು ಇತರ ವ್ಯವಸ್ಥೆಗಳಿಗಿಂತ ಸರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸುಲಭವಾದ ಒಂದು ಯೋಗ್ಯವಾದ ಸೇರ್ಪಡೆಯಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಒಂದು ವಾರದ ಹಿಂದೆ ನಾನು ಹೈಕು, ಅನಿರೀಕ್ಷಿತವಾಗಿ ಉತ್ತಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೇನೆ. ಒಳ್ಳೆಯದು, ಡೈರೆಕ್ಟರಿಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಚಿತ್ರಗಳಲ್ಲಿ ನಾನು ಬಹಳ ಹಿಂದಿನಿಂದಲೂ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ (ಮ್ಯಾಕಿಂತೋಷ್‌ನ ಸರಳತೆಯಿಂದ ಸ್ಫೂರ್ತಿ), ನನ್ನ ಮನಸ್ಸಿಗೆ ಒಂದು ಕಲ್ಪನೆ ಬಂದಿರುವುದು ಆಶ್ಚರ್ಯವೇನಿಲ್ಲ...

ಪೂರ್ಣ ತಿಳುವಳಿಕೆಗಾಗಿ, ನಾನು AppImage ನ ಸೃಷ್ಟಿಕರ್ತ ಮತ್ತು ಲೇಖಕನಾಗಿದ್ದೇನೆ, ಇದು Mac ಸರಳತೆಗಾಗಿ ಗುರಿಯನ್ನು ಹೊಂದಿರುವ Linux ಅಪ್ಲಿಕೇಶನ್ ವಿತರಣಾ ಸ್ವರೂಪವಾಗಿದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಲೇಖಕರು ಮತ್ತು ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ (ನೀವು ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ನೋಡಿ ವಿಕಿ и ದಸ್ತಾವೇಜನ್ನು).

ನಾವು ಹೈಕುಗಾಗಿ AppImage ಮಾಡಿದರೆ ಏನು?

ಸ್ವಲ್ಪ ಯೋಚಿಸೋಣ, ಸಂಪೂರ್ಣವಾಗಿ ಸೈದ್ಧಾಂತಿಕವಾಗಿ: ಪಡೆಯಲು ಏನು ಮಾಡಬೇಕು ಆಪ್ಐಮೇಜ್, ಅಥವಾ ಅಂತಹದ್ದೇನಾದರೂ, ಹೈಕುದಲ್ಲಿ? ಇದೀಗ ಏನನ್ನಾದರೂ ರಚಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಹೈಕುವಿನಲ್ಲಿ ಈಗಾಗಲೇ ಇರುವ ವ್ಯವಸ್ಥೆಯು ಅದ್ಭುತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಕಾಲ್ಪನಿಕ ಪ್ರಯೋಗವು ಚೆನ್ನಾಗಿರುತ್ತದೆ. Linux ಡೆಸ್ಕ್‌ಟಾಪ್ ಪರಿಸರಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಇದು ಹೈಕುವಿನ ಅತ್ಯಾಧುನಿಕತೆಯನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಅಂತಹ ವಿಷಯಗಳು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿವೆ (ನನಗೆ ಹಾಗೆ ಹೇಳುವ ಹಕ್ಕಿದೆ: ನಾನು 10 ವರ್ಷಗಳಿಂದ ಡೀಬಗ್ ಮಾಡುವುದರೊಂದಿಗೆ ಹೋರಾಡುತ್ತಿದ್ದೇನೆ).

ಮ್ಯಾಕಿಂತೋಷ್ ಸಿಸ್ಟಮ್ 1 ನಲ್ಲಿ, ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಫೈಂಡರ್‌ನಲ್ಲಿ "ನಿರ್ವಹಿಸುವ" ಪ್ರತ್ಯೇಕ ಫೈಲ್ ಆಗಿತ್ತು. AppImage ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಾನು Linux ನಲ್ಲಿ ಅದೇ ಬಳಕೆದಾರ ಅನುಭವವನ್ನು ಮರುಸೃಷ್ಟಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇನೆ.

ಮೊದಲನೆಯದಾಗಿ, AppImage ಎಂದರೇನು? ಇದು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ (ಉದಾಹರಣೆಗೆ, ಅಲ್ಟಿಮೇಕರ್ ಕ್ಯುರಾ), ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಯಾವಾಗ ಮತ್ತು ಹೇಗೆ ಅವರು ಬಯಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ: ವಿವಿಧ ವಿತರಣೆಗಳ ನಿಶ್ಚಿತಗಳನ್ನು ತಿಳಿದುಕೊಳ್ಳುವ ಅಗತ್ಯವಿಲ್ಲ, ನೀತಿಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಅಥವಾ ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿರ್ಮಿಸುವುದು, ಯಾವುದೇ ನಿರ್ವಹಣಾ ಬೆಂಬಲ ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ಅವರು ಏನು (ಅಲ್ಲ) ಸ್ಥಾಪಿಸಬಹುದು ಎಂಬುದನ್ನು ಅವರು ಬಳಕೆದಾರರಿಗೆ ತಿಳಿಸುವುದಿಲ್ಲ. ಅವರ ಕಂಪ್ಯೂಟರ್‌ಗಳಲ್ಲಿ. AppImage ಅನ್ನು ಸ್ವರೂಪದಲ್ಲಿ ಮ್ಯಾಕ್ ಪ್ಯಾಕೇಜ್‌ಗೆ ಹೋಲುವ ರೀತಿಯಲ್ಲಿ ಅರ್ಥೈಸಿಕೊಳ್ಳಬೇಕು .app ಡಿಸ್ಕ್ ಚಿತ್ರದ ಒಳಗೆ .dmg. ಮುಖ್ಯ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಕಲಿಸಲಾಗಿಲ್ಲ, ಆದರೆ AppImage ನಲ್ಲಿ ಶಾಶ್ವತವಾಗಿ ಉಳಿಯುತ್ತದೆ, ಹೈಕು ಪ್ಯಾಕೇಜ್‌ಗಳಂತೆಯೇ ಇರುತ್ತದೆ .hpkg ಆರೋಹಿಸಲಾಗಿದೆ, ಮತ್ತು ಸಾಮಾನ್ಯ ಅರ್ಥದಲ್ಲಿ ಎಂದಿಗೂ ಸ್ಥಾಪಿಸಲಾಗಿಲ್ಲ.

10 ವರ್ಷಗಳ ಅಸ್ತಿತ್ವದ ಅವಧಿಯಲ್ಲಿ, AppImage ಕೆಲವು ಆಕರ್ಷಣೆ ಮತ್ತು ಜನಪ್ರಿಯತೆಯನ್ನು ಗಳಿಸಿದೆ: ಲಿನಸ್ ಟೊರ್ವಾಲ್ಡ್ಸ್ ಸ್ವತಃ ಇದನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿ ಅನುಮೋದಿಸಿದ್ದಾರೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಯೋಜನೆಗಳು (ಉದಾಹರಣೆಗೆ, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) ಇದನ್ನು ಮುಖ್ಯ ಮಾರ್ಗವಾಗಿ ಅಳವಡಿಸಿಕೊಂಡಿವೆ. ನಿರಂತರ ಅಥವಾ ರಾತ್ರಿಯ ಬಿಲ್ಡ್‌ಗಳನ್ನು ವಿತರಿಸಲು, ಸ್ಥಾಪಿಸಲಾದ ಅಥವಾ ಅನ್‌ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಲಾದ ಬಳಕೆದಾರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಮಧ್ಯಪ್ರವೇಶಿಸುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, Linux ಡೆಸ್ಕ್‌ಟಾಪ್ ಪರಿಸರಗಳು ಮತ್ತು ವಿತರಣೆಗಳು ಇನ್ನೂ ಹೆಚ್ಚಾಗಿ ಸಾಂಪ್ರದಾಯಿಕ, ಕೇಂದ್ರೀಕೃತ ನಿರ್ವಹಣಾ-ಆಧಾರಿತ ವಿತರಣಾ ಮಾದರಿಗೆ ಅಂಟಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು/ಅಥವಾ ತಮ್ಮದೇ ಆದ ಉದ್ಯಮ ವ್ಯವಹಾರ ಮತ್ತು/ಅಥವಾ ಎಂಜಿನಿಯರಿಂಗ್ ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ಆಧರಿಸಿ ಫ್ಲಾಟ್ಪ್ಯಾಕ್ (RedHat, Fedora, GNOME) ಮತ್ತು ಸಿಡುಕಿನ (ಕ್ಯಾನೋನಿಕಲ್, ಉಬುಂಟು). ಅದು ಬರುತ್ತದೆ ಹಾಸ್ಯಾಸ್ಪದವಾಗಿ.

ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ಪ್ರತಿ AppImage 2 ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ: ಸಣ್ಣ ಡಬಲ್-ಕ್ಲಿಕ್ ELF (ಕರೆಯಲಾಗುತ್ತದೆ. runtime.c), ನಂತರ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಇಮೇಜ್ ಸ್ಕ್ವಾಶ್ಎಫ್ಎಸ್.

SquashFS ಕಡತ ವ್ಯವಸ್ಥೆಯು ಅಪ್ಲಿಕೇಶನ್‌ನ ಪೇಲೋಡ್ ಮತ್ತು ಅದನ್ನು ಚಲಾಯಿಸಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಒಳಗೊಂಡಿದೆ, ಸರಿಯಾದ ಮನಸ್ಸಿನಲ್ಲಿ ಪ್ರತಿ ತಕ್ಕಮಟ್ಟಿಗೆ ಇತ್ತೀಚಿನ ಗುರಿ ವ್ಯವಸ್ಥೆಗೆ (ಲಿನಕ್ಸ್ ವಿತರಣೆ) ಡೀಫಾಲ್ಟ್ ಸ್ಥಾಪನೆಯ ಭಾಗವಾಗಿ ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ. ಇದು ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರು, ಐಕಾನ್‌ಗಳು, MIME ಪ್ರಕಾರಗಳು ಇತ್ಯಾದಿಗಳಂತಹ ಮೆಟಾಡೇಟಾವನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ.

ಬಳಕೆದಾರರಿಂದ ಚಲಾಯಿಸಿದಾಗ, ರನ್‌ಟೈಮ್ ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಅನ್ನು ಆರೋಹಿಸಲು FUSE ಮತ್ತು ಸ್ಕ್ವಾಶ್‌ಫ್ಯೂಸ್ ಅನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಆರೋಹಿತವಾದ AppImage ಒಳಗೆ ಕೆಲವು ಪ್ರವೇಶ ಬಿಂದುವನ್ನು (ಅಕಾ AppRun) ಚಲಾಯಿಸುವುದನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ.
ಪ್ರಕ್ರಿಯೆಯು ಪೂರ್ಣಗೊಂಡ ನಂತರ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅನ್ಮೌಂಟ್ ಮಾಡಲಾಗಿದೆ.

ಎಲ್ಲವೂ ಸರಳವೆಂದು ತೋರುತ್ತದೆ.

ಮತ್ತು ಈ ಅಂಶಗಳು ಎಲ್ಲವನ್ನೂ ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತವೆ:

ಅಂತಹ ವೈವಿಧ್ಯಮಯ ಲಿನಕ್ಸ್ ವಿತರಣೆಗಳೊಂದಿಗೆ, "ಸರಿಯಾದ ಮನಸ್ಸಿನಲ್ಲಿ" ಯಾವುದನ್ನೂ "ಪ್ರತಿ ಹೊಸ ಗುರಿ ವ್ಯವಸ್ಥೆಗೆ ಡೀಫಾಲ್ಟ್ ಸ್ಥಾಪನೆಯ ಭಾಗ" ಎಂದು ಕರೆಯಲಾಗುವುದಿಲ್ಲ. ನಾವು ನಿರ್ಮಿಸುವ ಮೂಲಕ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತೇವೆ ಹೊರಗಿಡುವವನು, AppImage ನಲ್ಲಿ ಏನನ್ನು ಪ್ಯಾಕ್ ಮಾಡಲಾಗುವುದು ಮತ್ತು ಬೇರೆಲ್ಲಿಯಾದರೂ ಏನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಸಾಮಾನ್ಯವಾಗಿ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ ನಾವು ಕೆಲವೊಮ್ಮೆ ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತೇವೆ. ಈ ಕಾರಣಕ್ಕಾಗಿ, ಪ್ಯಾಕೇಜ್ ರಚನೆಕಾರರು ಎಲ್ಲಾ ಗುರಿ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ (ವಿತರಣೆಗಳು) AppImages ಅನ್ನು ಪರೀಕ್ಷಿಸಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.
ಅಪ್ಲಿಕೇಶನ್ ಪೇಲೋಡ್‌ಗಳು ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಾದ್ಯಂತ ಸ್ಥಳಾಂತರಗೊಳ್ಳಬೇಕು. ದುರದೃಷ್ಟವಶಾತ್, ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹಾರ್ಡ್-ಕೋಡೆಡ್ ಸಂಪೂರ್ಣ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿವೆ, ಉದಾಹರಣೆಗೆ, ಸಂಪನ್ಮೂಲಗಳಲ್ಲಿ /usr/share. ಇದನ್ನು ಹೇಗಾದರೂ ಸರಿಪಡಿಸಬೇಕು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನೀವು ರಫ್ತು ಮಾಡಬೇಕು LD_LIBRARY_PATH, ಅಥವಾ ಸರಿಪಡಿಸಿ rpath ಇದರಿಂದ ಲೋಡರ್ ಸಂಬಂಧಿತ ಲೈಬ್ರರಿಗಳನ್ನು ಹುಡುಕಬಹುದು. ಮೊದಲ ವಿಧಾನವು ಅದರ ನ್ಯೂನತೆಗಳನ್ನು ಹೊಂದಿದೆ (ಇದು ಸಂಕೀರ್ಣ ರೀತಿಯಲ್ಲಿ ಹೊರಬರುತ್ತದೆ), ಮತ್ತು ಎರಡನೆಯದು ಸರಳವಾಗಿ ತೊಡಕಿನದ್ದಾಗಿದೆ.
ಬಳಕೆದಾರರಿಗೆ ದೊಡ್ಡ UX ಅಪಾಯವೆಂದರೆ ಅದು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಬಿಟ್ ಅನ್ನು ಹೊಂದಿಸಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ನಂತರ AppImage ಫೈಲ್. ಇದನ್ನು ನಂಬಿರಿ ಅಥವಾ ಇಲ್ಲ, ಇದು ಕೆಲವರಿಗೆ ನಿಜವಾದ ತಡೆಗೋಡೆಯಾಗಿದೆ. ಅನುಭವಿ ಬಳಕೆದಾರರಿಗೆ ಸಹ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಬಿಟ್ ಅನ್ನು ಹೊಂದಿಸುವ ಅಗತ್ಯವು ತೊಡಕಾಗಿದೆ. ಪರಿಹಾರವಾಗಿ, AppImage ಫೈಲ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಮತ್ತು ಅವುಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಬಿಟ್ ಅನ್ನು ಹೊಂದಿಸುವ ಸಣ್ಣ ಸೇವೆಯನ್ನು ಸ್ಥಾಪಿಸಲು ನಾವು ಸಲಹೆ ನೀಡಿದ್ದೇವೆ. ಅದರ ಶುದ್ಧ ರೂಪದಲ್ಲಿ, ಇದು ಉತ್ತಮ ಪರಿಹಾರವಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಪೆಟ್ಟಿಗೆಯಿಂದ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. Linux ವಿತರಣೆಗಳು ಈ ಸೇವೆಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ, ಬಳಕೆದಾರರು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಕೆಟ್ಟ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದಾರೆ.
ಲಿನಕ್ಸ್ ಬಳಕೆದಾರರು ಹೊಸ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಟಾರ್ಟ್ಅಪ್ ಮೆನುವಿನಲ್ಲಿ ಐಕಾನ್ ಅನ್ನು ಹೊಂದಲು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ. ನೀವು ಸಿಸ್ಟಮ್ಗೆ ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ: "ನೋಡಿ, ಹೊಸ ಅಪ್ಲಿಕೇಶನ್ ಇದೆ, ನಾವು ಕೆಲಸ ಮಾಡೋಣ." ಬದಲಿಗೆ, XDG ವಿವರಣೆಯ ಪ್ರಕಾರ, ನೀವು ಫೈಲ್ ಅನ್ನು ನಕಲಿಸಬೇಕಾಗುತ್ತದೆ .desktop ಸರಿಯಾದ ಸ್ಥಳಕ್ಕೆ /usr ಸಿಸ್ಟಮ್-ವೈಡ್ ಅನುಸ್ಥಾಪನೆಗೆ, ಅಥವಾ ಇನ್ $HOME ವ್ಯಕ್ತಿಗೆ. XDG ವಿವರಣೆಯ ಪ್ರಕಾರ ನಿರ್ದಿಷ್ಟ ಗಾತ್ರದ ಐಕಾನ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಸ್ಥಳಗಳಲ್ಲಿ ಇರಿಸಬೇಕಾಗುತ್ತದೆ usr ಅಥವಾ $HOME, ತದನಂತರ ಐಕಾನ್ ಸಂಗ್ರಹವನ್ನು ನವೀಕರಿಸಲು ಕಾರ್ಯ ಪರಿಸರದಲ್ಲಿ ಆಜ್ಞೆಗಳನ್ನು ಚಲಾಯಿಸಿ, ಅಥವಾ ಕಾರ್ಯ ಪರಿಸರ ನಿರ್ವಾಹಕರು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪತ್ತೆ ಮಾಡುತ್ತಾರೆ ಎಂದು ಭಾವಿಸುತ್ತೇವೆ. MIME ಪ್ರಕಾರಗಳೊಂದಿಗೆ ಅದೇ. ಪರಿಹಾರವಾಗಿ, ಅದೇ ಸೇವೆಯನ್ನು ಬಳಸಲು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ, ಇದು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿಸುವುದರ ಜೊತೆಗೆ, ಐಕಾನ್‌ಗಳು ಇದ್ದರೆ, ಇತ್ಯಾದಿ. AppImage ನಲ್ಲಿ, ಅವುಗಳನ್ನು AppImage ನಿಂದ XDG ಪ್ರಕಾರ ಸರಿಯಾದ ಸ್ಥಳಗಳಿಗೆ ನಕಲಿಸಿ. ಅಳಿಸಿದಾಗ ಅಥವಾ ಸರಿಸಿದಾಗ, ಸೇವೆಯು ಎಲ್ಲವನ್ನೂ ತೆರವುಗೊಳಿಸುವ ನಿರೀಕ್ಷೆಯಿದೆ. ಸಹಜವಾಗಿ, ಪ್ರತಿ ಕೆಲಸದ ಪರಿಸರದ ನಡವಳಿಕೆಯಲ್ಲಿ ವ್ಯತ್ಯಾಸಗಳಿವೆ, ಗ್ರಾಫಿಕ್ ಫೈಲ್ ಫಾರ್ಮ್ಯಾಟ್‌ಗಳು, ಅವುಗಳ ಗಾತ್ರಗಳು, ಶೇಖರಣಾ ಸ್ಥಳಗಳು ಮತ್ತು ಕ್ಯಾಶ್‌ಗಳನ್ನು ನವೀಕರಿಸುವ ವಿಧಾನಗಳು, ಇದು ಸಮಸ್ಯೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಈ ವಿಧಾನವು ಒಂದು ಊರುಗೋಲು.
ಮೇಲಿನವು ಸಾಕಾಗದಿದ್ದರೆ, ಫೈಲ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ ಇನ್ನೂ ಯಾವುದೇ AppImage ಐಕಾನ್ ಇಲ್ಲ. ಲಿನಕ್ಸ್ ಪ್ರಪಂಚವು ಇನ್ನೂ ಎಲ್ಫಿಕಾನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿರ್ಧರಿಸಿಲ್ಲ (ಆದರೂ ಚರ್ಚೆ и ಅನುಷ್ಠಾನ), ಆದ್ದರಿಂದ ಐಕಾನ್ ಅನ್ನು ನೇರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಎಂಬೆಡ್ ಮಾಡುವುದು ಅಸಾಧ್ಯ. ಆದ್ದರಿಂದ ಫೈಲ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ತಮ್ಮದೇ ಆದ ಐಕಾನ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ (ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲ, AppImage ಅಥವಾ ಬೇರೆ ಯಾವುದಾದರೂ), ಅವು ಪ್ರಾರಂಭ ಮೆನುವಿನಲ್ಲಿ ಮಾತ್ರ ಇರುತ್ತವೆ. ಪರಿಹಾರವಾಗಿ, ನಾವು ಥಂಬ್‌ನೇಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ, ಇದು ಮೂಲತಃ ಡೆಸ್ಕ್‌ಟಾಪ್ ನಿರ್ವಾಹಕರು ಗ್ರಾಫಿಕ್ ಫೈಲ್‌ಗಳ ಥಂಬ್‌ನೇಲ್ ಪೂರ್ವವೀಕ್ಷಣೆ ಚಿತ್ರಗಳನ್ನು ತಮ್ಮ ಐಕಾನ್‌ಗಳಾಗಿ ತೋರಿಸಲು ಅನುಮತಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ. ಪರಿಣಾಮವಾಗಿ, ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಬಿಟ್ ಅನ್ನು ಹೊಂದಿಸುವ ಸೇವೆಯು "ಮಿನಿಯೇಟರೈಸರ್" ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಸೂಕ್ತವಾದ ಸ್ಥಳಗಳಿಗೆ ಐಕಾನ್ ಥಂಬ್‌ನೇಲ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಬರೆಯುತ್ತದೆ /usr и $HOME. AppImage ಅನ್ನು ಅಳಿಸಿದರೆ ಅಥವಾ ಸರಿಸಿದರೆ ಈ ಸೇವೆಯು ಸ್ವಚ್ಛಗೊಳಿಸುತ್ತದೆ. ಪ್ರತಿ ಡೆಸ್ಕ್‌ಟಾಪ್ ನಿರ್ವಾಹಕರು ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತಾರೆ ಎಂಬ ಅಂಶದಿಂದಾಗಿ, ಉದಾಹರಣೆಗೆ, ಯಾವ ಸ್ವರೂಪಗಳಲ್ಲಿ ಅದು ಐಕಾನ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಯಾವ ಗಾತ್ರಗಳು ಅಥವಾ ಸ್ಥಳಗಳಲ್ಲಿ, ಇದು ನಿಜವಾಗಿಯೂ ನೋವಿನಿಂದ ಕೂಡಿದೆ.
ದೋಷಗಳು ಸಂಭವಿಸಿದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಕೇವಲ ಎಕ್ಸಿಕ್ಯೂಶನ್‌ನಲ್ಲಿ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಬೇಸ್ ಸಿಸ್ಟಮ್‌ನ ಭಾಗವಾಗಿರದ ಮತ್ತು AppImage ನಲ್ಲಿ ಸರಬರಾಜು ಮಾಡದ ಲೈಬ್ರರಿ ಇದೆ), ಮತ್ತು GUI ನಲ್ಲಿ ಬಳಕೆದಾರರಿಗೆ ನಿಖರವಾಗಿ ಏನಾಗುತ್ತಿದೆ ಎಂದು ಯಾರೂ ಹೇಳುವುದಿಲ್ಲ. ನಾವು ಇದನ್ನು ಬಳಸಿಕೊಂಡು ಸುತ್ತಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಅಧಿಸೂಚನೆಗಳು ಡೆಸ್ಕ್‌ಟಾಪ್‌ನಲ್ಲಿ, ಅಂದರೆ ನಾವು ಆಜ್ಞಾ ಸಾಲಿನಿಂದ ದೋಷಗಳನ್ನು ಹಿಡಿಯಬೇಕು, ಅವುಗಳನ್ನು ಬಳಕೆದಾರರಿಗೆ ಅರ್ಥವಾಗುವ ಸಂದೇಶಗಳಾಗಿ ಪರಿವರ್ತಿಸಬೇಕು, ನಂತರ ಅದನ್ನು ಡೆಸ್ಕ್‌ಟಾಪ್‌ನಲ್ಲಿ ಪ್ರದರ್ಶಿಸಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ಸಹಜವಾಗಿ, ಪ್ರತಿ ಡೆಸ್ಕ್‌ಟಾಪ್ ಪರಿಸರವು ಅವುಗಳನ್ನು ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ.
ಈ ಸಮಯದಲ್ಲಿ (ಸೆಪ್ಟೆಂಬರ್ 2019 - ಅನುವಾದಕರ ಟಿಪ್ಪಣಿ) ಫೈಲ್ ಅನ್ನು ಸಿಸ್ಟಮ್‌ಗೆ ಹೇಳಲು ನಾನು ಸರಳವಾದ ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಂಡಿಲ್ಲ 1.png ಕೃತವನ್ನು ಬಳಸಿ ತೆರೆಯಬೇಕು, ಮತ್ತು 2.png - GIMP ಬಳಸಿ.

ಕ್ರಾಸ್-ಡೆಸ್ಕ್‌ಟಾಪ್ ವಿಶೇಷಣಗಳಿಗಾಗಿ ಶೇಖರಣಾ ಸ್ಥಳವನ್ನು ಬಳಸಲಾಗಿದೆ ಗ್ನೋಮ್, ಕೆಡಿಇ и Xfce freedesktop.org ಆಗಿದೆ

ಹೈಕು ಕೆಲಸದ ವಾತಾವರಣದಲ್ಲಿ ಆಳವಾಗಿ ನೇಯ್ದಿರುವ ಅತ್ಯಾಧುನಿಕತೆಯ ಮಟ್ಟವನ್ನು ಸಾಧಿಸುವುದು ಕಷ್ಟ, ಆದರೆ ಅಸಾಧ್ಯವಲ್ಲ, ವಿಶೇಷಣಗಳ ಕಾರಣದಿಂದಾಗಿ freedesktop.org ನಿಂದ XDG ಕ್ರಾಸ್-ಡೆಸ್ಕ್‌ಟಾಪ್‌ಗಾಗಿ, ಹಾಗೆಯೇ ಈ ವಿಶೇಷಣಗಳ ಆಧಾರದ ಮೇಲೆ ಡೆಸ್ಕ್‌ಟಾಪ್ ಮ್ಯಾನೇಜರ್‌ಗಳ ಅಳವಡಿಕೆಗಳು. ಉದಾಹರಣೆಯಾಗಿ, ನಾವು ಒಂದು ಸಿಸ್ಟಮ್-ವೈಡ್ ಫೈರ್‌ಫಾಕ್ಸ್ ಐಕಾನ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಬಹುದು: ಸ್ಪಷ್ಟವಾಗಿ, XDG ಯ ಲೇಖಕರು ಬಳಕೆದಾರರು ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹಲವಾರು ಆವೃತ್ತಿಗಳನ್ನು ಸ್ಥಾಪಿಸಬಹುದೆಂದು ಯೋಚಿಸಿರಲಿಲ್ಲ.

ಫೈರ್‌ಫಾಕ್ಸ್‌ನ ವಿವಿಧ ಆವೃತ್ತಿಗಳಿಗೆ ಐಕಾನ್‌ಗಳು

ಸಿಸ್ಟಮ್ ಏಕೀಕರಣವನ್ನು ತಪ್ಪಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು Mac OS X ನಿಂದ Linux ಜಗತ್ತು ಏನು ಕಲಿಯಬಹುದು ಎಂದು ನಾನು ಆಶ್ಚರ್ಯ ಪಡುತ್ತಿದ್ದೆ. ನಿಮಗೆ ಸಮಯವಿದ್ದರೆ ಮತ್ತು ಇದರಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದರೆ, ಮೊದಲ ಮ್ಯಾಕ್ ಒಎಸ್ ಎಕ್ಸ್ ಎಂಜಿನಿಯರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರಾದ ಅರ್ನಾಡ್ ಗುರ್ಡಾಲ್ ಅವರು ಏನು ಹೇಳಿದರು ಎಂಬುದನ್ನು ಓದಲು ಮರೆಯದಿರಿ:

ಅಪ್ಲಿಕೇಶನ್ ಐಕಾನ್ ಅನ್ನು ಎಲ್ಲಿಂದಲಾದರೂ (ಸರ್ವರ್, ಬಾಹ್ಯ ಡ್ರೈವ್) ನಿಮ್ಮ ಕಂಪ್ಯೂಟರ್ ಡ್ರೈವ್‌ಗೆ ಎಳೆಯುವಷ್ಟು ಸುಲಭವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ಇದನ್ನು ಮಾಡಲು, ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೇಜ್ ಐಕಾನ್‌ಗಳು, ಆವೃತ್ತಿ, ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಿರುವ ಫೈಲ್ ಪ್ರಕಾರ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಿಸ್ಟಮ್ ತಿಳಿಯಬೇಕಾದ URL ಸ್ಕೀಮ್‌ಗಳ ಪ್ರಕಾರ ಸೇರಿದಂತೆ ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಇದು ಐಕಾನ್ ಸೇವೆಗಳು ಮತ್ತು ಲಾಂಚ್ ಸೇವೆಗಳ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ 'ಕೇಂದ್ರ ಸಂಗ್ರಹಣೆ' ಗಾಗಿ ಮಾಹಿತಿಯನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ. ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಬೆಂಬಲಿಸಲು, ಹಲವಾರು 'ಪ್ರಸಿದ್ಧ' ಸ್ಥಳಗಳಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು 'ಶೋಧಿಸಲಾಗುತ್ತದೆ': ಸಿಸ್ಟಮ್ ಮತ್ತು ಬಳಕೆದಾರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಡೈರೆಕ್ಟರಿಗಳು, ಮತ್ತು ಬಳಕೆದಾರರು ಅಪ್ಲಿಕೇಶನ್ ಹೊಂದಿರುವ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಫೈಂಡರ್‌ಗೆ ನ್ಯಾವಿಗೇಟ್ ಮಾಡಿದರೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕೆಲವು. ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದು ತುಂಬಾ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 ಸೆಷನ್ 144 - Mac OS X: ಪ್ಯಾಕೇಜಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಮುದ್ರಣ ದಾಖಲೆಗಳು.

Linux ಡೆಸ್ಕ್‌ಟಾಪ್‌ಗಳಲ್ಲಿ ಈ ರೀತಿಯ ಮೂಲಸೌಕರ್ಯ ಏನೂ ಇಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು AppImage ಯೋಜನೆಯಲ್ಲಿ ರಚನಾತ್ಮಕ ಮಿತಿಗಳ ಸುತ್ತ ಪರಿಹಾರಗಳನ್ನು ಹುಡುಕುತ್ತಿದ್ದೇವೆ.

ಹಾಯ್ಕು ನೆರವಿಗೆ ಬರುತ್ತಿದೆಯೇ?

ಇನ್ನೂ ಒಂದು ವಿಷಯ: ಡೆಸ್ಕ್‌ಟಾಪ್ ಪರಿಸರದ ಆಧಾರವಾಗಿರುವ ಲಿನಕ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಎಷ್ಟು ಕಡಿಮೆ ನಿರ್ದಿಷ್ಟಪಡಿಸಲ್ಪಟ್ಟಿವೆ ಎಂದರೆ ಸುಸಂಬದ್ಧ ಪೂರ್ಣ-ಸ್ಟಾಕ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಸರಳವಾದ ಅನೇಕ ವಿಷಯಗಳು ನಿರಾಶಾದಾಯಕವಾಗಿ ವಿಘಟಿತವಾಗಿವೆ ಮತ್ತು ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ಸಂಕೀರ್ಣವಾಗಿವೆ. ಡೆಸ್ಕ್‌ಟಾಪ್ ಪರಿಸರಕ್ಕಾಗಿ ಲಿನಕ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಸಮಸ್ಯೆಗಳಿಗೆ ನಾನು ಸಂಪೂರ್ಣ ವರದಿಯನ್ನು ಮೀಸಲಿಟ್ಟಿದ್ದೇನೆ (ತಿಳಿವಳಿಕೆಯುಳ್ಳ ಡೆವಲಪರ್‌ಗಳು ಎಲ್ಲವೂ ಬಹಳ ಸಮಯದವರೆಗೆ ಹೀಗೆಯೇ ಇರುತ್ತದೆ ಎಂದು ದೃಢಪಡಿಸಿದ್ದಾರೆ).

2018 ರಲ್ಲಿ Linux ಡೆಸ್ಕ್‌ಟಾಪ್ ಪರಿಸರದ ಸಮಸ್ಯೆಗಳ ಕುರಿತು ನನ್ನ ವರದಿ

ಲಿನಸ್ ಟೊರ್ವಾಲ್ಡ್ಸ್ ಸಹ ವಿಘಟನೆಯು ಕಾರ್ಯಸ್ಥಳದ ಕಲ್ಪನೆಯು ಏಕೆ ವಿಫಲವಾಗಿದೆ ಎಂದು ಒಪ್ಪಿಕೊಂಡರು.

ಹೈಕು ನೋಡಲು ಸಂತೋಷವಾಗಿದೆ!

ಹೈಕು ಎಲ್ಲವನ್ನೂ ಅದ್ಭುತವಾಗಿ ಸರಳಗೊಳಿಸುತ್ತದೆ

AppImage ಅನ್ನು ಹೈಕುಗೆ "ಪೋರ್ಟಿಂಗ್" ಮಾಡುವ ನಿಷ್ಕಪಟ ವಿಧಾನವೆಂದರೆ ಅದರ ಘಟಕಗಳನ್ನು (ಮುಖ್ಯವಾಗಿ ರನ್‌ಟೈಮ್.ಸಿ ಮತ್ತು ಸೇವೆ) ನಿರ್ಮಿಸಲು ಪ್ರಯತ್ನಿಸುವುದು (ಇದು ಸಾಧ್ಯವಾಗಬಹುದು!), ಇದು ಹೈಕುಗೆ ಹೆಚ್ಚಿನ ಪ್ರಯೋಜನವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. ಏಕೆಂದರೆ ವಾಸ್ತವವಾಗಿ, ಈ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಹೈಕುವಿನಲ್ಲಿ ಪರಿಹರಿಸಲಾಗಿದೆ ಮತ್ತು ಕಲ್ಪನಾತ್ಮಕವಾಗಿ ಉತ್ತಮವಾಗಿದೆ. ಲಿನಕ್ಸ್ ಡೆಸ್ಕ್‌ಟಾಪ್ ಪರಿಸರದಲ್ಲಿ ನಾನು ಇಷ್ಟು ದಿನ ಹುಡುಕುತ್ತಿದ್ದ ಮತ್ತು ಇಲ್ಲ ಎಂದು ನಂಬಲು ಸಾಧ್ಯವಾಗದ ಸಿಸ್ಟಮ್ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಹೈಕು ನಿಖರವಾಗಿ ಒದಗಿಸುತ್ತದೆ. ಅವುಗಳೆಂದರೆ:

ಇದನ್ನು ನಂಬಿರಿ ಅಥವಾ ಇಲ್ಲ, ಇದು ಅನೇಕ ಲಿನಕ್ಸ್ ಬಳಕೆದಾರರಿಗೆ ಜಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಹೈಕುದಲ್ಲಿ ಎಲ್ಲವೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ!

ಎಕ್ಸಿಕ್ಯೂಟಬಿಲಿಟಿ ಬಿಟ್ ಹೊಂದಿರದ ELF ಫೈಲ್‌ಗಳು ಫೈಲ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ ಡಬಲ್ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಒಂದನ್ನು ಪಡೆಯುತ್ತವೆ.
ಫೈಲ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾದ ಐಕಾನ್‌ಗಳಂತಹ ಅಂತರ್ನಿರ್ಮಿತ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹೊಂದಿರಬಹುದು. ಐಕಾನ್‌ಗಳೊಂದಿಗೆ ವಿಶೇಷ ಡೈರೆಕ್ಟರಿಗಳಿಗೆ ಚಿತ್ರಗಳ ಗುಂಪನ್ನು ನಕಲಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಳಿಸಿದ ಅಥವಾ ಸರಿಸಿದ ನಂತರ ಅವುಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.
ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಲಿಂಕ್ ಮಾಡಲು ಡೇಟಾಬೇಸ್ ಇದೆ, ಇದಕ್ಕಾಗಿ ಯಾವುದೇ ಫೈಲ್‌ಗಳನ್ನು ನಕಲಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.
ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್‌ನ ಪಕ್ಕದಲ್ಲಿರುವ lib/ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ, ಲೈಬ್ರರಿಗಳನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಹುಡುಕಲಾಗುತ್ತದೆ.
ಯಾವುದೇ ಹಲವಾರು ವಿತರಣೆಗಳು ಮತ್ತು ಡೆಸ್ಕ್‌ಟಾಪ್ ಪರಿಸರಗಳಿಲ್ಲ; ಏನೇ ಕೆಲಸ ಮಾಡಿದರೂ, ಎಲ್ಲೆಡೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಡೈರೆಕ್ಟರಿಗಿಂತ ಭಿನ್ನವಾಗಿರುವ ಯಾವುದೇ ಪ್ರತ್ಯೇಕ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಇಲ್ಲ.
ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ತಮ್ಮ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಅಂತರ್ನಿರ್ಮಿತ ಸಂಪೂರ್ಣ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿಲ್ಲ; ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಸ್ಥಳವನ್ನು ನಿರ್ಧರಿಸಲು ಅವು ವಿಶೇಷ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿವೆ.
ಸಂಕುಚಿತ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಚಿತ್ರಗಳ ಕಲ್ಪನೆಯನ್ನು ಪರಿಚಯಿಸಲಾಗಿದೆ: ಇದು ಯಾವುದೇ hpkg ಪ್ಯಾಕೇಜ್ ಆಗಿದೆ. ಅವೆಲ್ಲವನ್ನೂ ಕರ್ನಲ್ ಮೂಲಕ ಜೋಡಿಸಲಾಗಿದೆ.
ನೀವು ಸ್ಪಷ್ಟವಾಗಿ ಸೂಚಿಸದ ಹೊರತು ಪ್ರತಿ ಫೈಲ್ ಅನ್ನು ರಚಿಸಿದ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ತೆರೆಯಲಾಗುತ್ತದೆ. ಇದು ಎಷ್ಟು ತಂಪಾಗಿದೆ!

ಎರಡು png ಫೈಲ್‌ಗಳು. ಡಬಲ್-ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ ವಿಭಿನ್ನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ ಅವುಗಳನ್ನು ತೆರೆಯಲಾಗುತ್ತದೆ ಎಂದು ಸೂಚಿಸುವ ವಿಭಿನ್ನ ಐಕಾನ್‌ಗಳನ್ನು ಗಮನಿಸಿ. "ಇದರೊಂದಿಗೆ ತೆರೆಯಿರಿ:" ಡ್ರಾಪ್-ಡೌನ್ ಮೆನುವನ್ನು ಗಮನಿಸಿ, ಅಲ್ಲಿ ಬಳಕೆದಾರರು ಪ್ರತ್ಯೇಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಎಷ್ಟು ಸರಳ!

ಲಿನಕ್ಸ್‌ನಲ್ಲಿ AppImage ಗೆ ಅಗತ್ಯವಿರುವ ಅನೇಕ ಊರುಗೋಲುಗಳು ಮತ್ತು ಪರಿಹಾರಗಳು ಹೈಕುದಲ್ಲಿ ಅನಗತ್ಯವಾದಂತೆ ತೋರುತ್ತಿದೆ, ಇದು ನಮ್ಮ ಹೆಚ್ಚಿನ ಅಗತ್ಯಗಳನ್ನು ನಿಭಾಯಿಸುವಂತೆ ಮಾಡುವ ಸರಳತೆ ಮತ್ತು ಅತ್ಯಾಧುನಿಕತೆಯನ್ನು ಅದರ ಕೇಂದ್ರಭಾಗದಲ್ಲಿ ಹೊಂದಿದೆ.

ಅಷ್ಟಕ್ಕೂ ಹೈಕುಗೆ ಆಪ್ ಪ್ಯಾಕೇಜ್‌ಗಳು ಬೇಕೇ?

ಇದು ದೊಡ್ಡ ಪ್ರಶ್ನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಲಿನಕ್ಸ್‌ಗಿಂತ ಹೈಕುದಲ್ಲಿ AppImage ನಂತಹ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುವುದು ಸುಲಭವಾದ ಕ್ರಮವಾಗಿದ್ದರೆ, ಅದನ್ನು ಮಾಡುವುದು ಯೋಗ್ಯವಾಗಿದೆಯೇ? ಅಥವಾ ಹೈಕು ತನ್ನ hpkg ಪ್ಯಾಕೇಜ್ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಅಂತಹ ಕಲ್ಪನೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಅಗತ್ಯವನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ತೆಗೆದುಹಾಕಿದೆಯೇ? ಸರಿ, ಉತ್ತರಿಸಲು ನಾವು AppImages ಅಸ್ತಿತ್ವದ ಹಿಂದಿನ ಪ್ರೇರಣೆಯನ್ನು ನೋಡಬೇಕಾಗಿದೆ.

ಬಳಕೆದಾರರ ದೃಷ್ಟಿಕೋನ

ನಮ್ಮ ಅಂತಿಮ ಬಳಕೆದಾರರನ್ನು ನೋಡೋಣ:

ನಿರ್ವಾಹಕರ (ರೂಟ್) ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಕೇಳದೆಯೇ ನಾನು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಬಯಸುತ್ತೇನೆ. ಹೈಕುದಲ್ಲಿ ನಿರ್ವಾಹಕರ ಪರಿಕಲ್ಪನೆ ಇಲ್ಲ, ಇದು ವೈಯಕ್ತಿಕ ವ್ಯವಸ್ಥೆಯಾಗಿರುವುದರಿಂದ ಬಳಕೆದಾರರ ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಣವಿದೆ! (ತಾತ್ವಿಕವಾಗಿ, ನೀವು ಇದನ್ನು ಮಲ್ಟಿಪ್ಲೇಯರ್ ಮೋಡ್‌ನಲ್ಲಿ ಕಲ್ಪಿಸಿಕೊಳ್ಳಬಹುದು, ಡೆವಲಪರ್‌ಗಳು ಇದನ್ನು ಸರಳವಾಗಿರಿಸುತ್ತಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ)
ನನ್ನ ವಿತರಣೆಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವವರೆಗೆ ಕಾಯದೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಇತ್ತೀಚಿನ ಮತ್ತು ಶ್ರೇಷ್ಠ ಆವೃತ್ತಿಗಳನ್ನು ಪಡೆಯಲು ನಾನು ಬಯಸುತ್ತೇನೆ (ಹೆಚ್ಚಾಗಿ ಇದರರ್ಥ "ಎಂದಿಗೂ", ಕನಿಷ್ಠ ನಾನು ಸಂಪೂರ್ಣ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ನವೀಕರಿಸದ ಹೊರತು). ಹೈಕುದಲ್ಲಿ ಇದನ್ನು ತೇಲುವ ಬಿಡುಗಡೆಗಳೊಂದಿಗೆ "ಪರಿಹರಿಸಲಾಗಿದೆ". ಇದರರ್ಥ ನೀವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಇತ್ತೀಚಿನ ಮತ್ತು ಶ್ರೇಷ್ಠ ಆವೃತ್ತಿಗಳನ್ನು ಪಡೆಯಬಹುದು, ಆದರೆ ಇದನ್ನು ಮಾಡಲು ನೀವು ಉಳಿದ ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ನವೀಕರಿಸಬೇಕಾಗುತ್ತದೆ, ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಅದನ್ನು "ಚಲಿಸುವ ಗುರಿ" ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ..
ನಾನು ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹಲವಾರು ಆವೃತ್ತಿಗಳನ್ನು ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ಬಯಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯಲ್ಲಿ ಏನು ಮುರಿದಿದೆ ಎಂದು ತಿಳಿಯಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ, ಅಥವಾ ಹೇಳುವುದಾದರೆ, ನಾನು ವೆಬ್ ಡೆವಲಪರ್ ಆಗಿ, ಬ್ರೌಸರ್‌ನ ವಿವಿಧ ಆವೃತ್ತಿಗಳ ಅಡಿಯಲ್ಲಿ ನನ್ನ ಕೆಲಸವನ್ನು ಪರೀಕ್ಷಿಸಬೇಕಾಗಿದೆ. ಹೈಕು ಮೊದಲ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಆದರೆ ಎರಡನೆಯದು ಅಲ್ಲ. ನವೀಕರಣಗಳನ್ನು ಹಿಂತಿರುಗಿಸಲಾಗಿದೆ, ಆದರೆ ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್‌ಗೆ ಮಾತ್ರ; ಚಲಾಯಿಸಲು ಅಸಾಧ್ಯ (ನನಗೆ ತಿಳಿದಿರುವಂತೆ) ಉದಾಹರಣೆಗೆ, ಒಂದೇ ಸಮಯದಲ್ಲಿ ವೆಬ್‌ಪಾಸಿಟಿವ್ ಅಥವಾ ಲಿಬ್ರೆ ಆಫೀಸ್‌ನ ಹಲವಾರು ಆವೃತ್ತಿಗಳು.

ಅಭಿವರ್ಧಕರಲ್ಲಿ ಒಬ್ಬರು ಬರೆಯುತ್ತಾರೆ:

ಮೂಲಭೂತವಾಗಿ ತಾರ್ಕಿಕತೆ ಹೀಗಿದೆ: ಬಳಕೆಯ ಪ್ರಕರಣವು ತುಂಬಾ ಅಪರೂಪವಾಗಿದ್ದು, ಅದನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸುವುದರಲ್ಲಿ ಅರ್ಥವಿಲ್ಲ; ಹೈಕುಪೋರ್ಟ್ಸ್‌ನಲ್ಲಿ ಇದನ್ನು ವಿಶೇಷ ಪ್ರಕರಣವಾಗಿ ಪರಿಗಣಿಸುವುದು ಸ್ವೀಕಾರಾರ್ಹಕ್ಕಿಂತ ಹೆಚ್ಚು ಎಂದು ತೋರುತ್ತದೆ.

ನನ್ನ ಸ್ಟಾರ್ಟ್‌ಅಪ್ ಡ್ರೈವ್‌ನಲ್ಲಿ ಅಲ್ಲ, ನಾನು ಇಷ್ಟಪಡುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಾನು ಇರಿಸಿಕೊಳ್ಳಬೇಕು. ನಾನು ಆಗಾಗ್ಗೆ ಡಿಸ್ಕ್ ಸ್ಥಳದಿಂದ ರನ್ ಆಗುತ್ತೇನೆ, ಆದ್ದರಿಂದ ನಾನು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಾಹ್ಯ ಡ್ರೈವ್ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ಸಂಪರ್ಕಿಸಬೇಕಾಗಿದೆ (ನಾನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಎಲ್ಲಾ ಆವೃತ್ತಿಗಳು). ನಾನು ಅಂತಹ ಡ್ರೈವ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿದರೆ, ಡಬಲ್ ಕ್ಲಿಕ್ ಮಾಡುವ ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ನನಗೆ ಅಗತ್ಯವಿದೆ. Haiku ಪ್ಯಾಕೇಜುಗಳ ಹಳೆಯ ಆವೃತ್ತಿಗಳನ್ನು ಉಳಿಸುತ್ತದೆ, ಆದರೆ ಅವುಗಳನ್ನು ಬಾಹ್ಯ ಡ್ರೈವ್‌ಗೆ ಹೇಗೆ ಸರಿಸುವುದು ಅಥವಾ ಅಲ್ಲಿಂದ ನಂತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸುವುದು ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ.

ಡೆವಲಪರ್ ಕಾಮೆಂಟ್:

ತಾಂತ್ರಿಕವಾಗಿ, ಇದು ಈಗಾಗಲೇ ಮೌಂಟ್ ಆಜ್ಞೆಯೊಂದಿಗೆ ಸಾಧ್ಯ. ಸಹಜವಾಗಿ, ನಾವು ಸಾಕಷ್ಟು ಆಸಕ್ತ ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿದ ತಕ್ಷಣ ನಾವು ಇದಕ್ಕಾಗಿ GUI ಅನ್ನು ಮಾಡುತ್ತೇವೆ.

ನನ್ನ ಕೈಯಾರೆ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗದ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಾದ್ಯಂತ ಹರಡಿರುವ ಲಕ್ಷಾಂತರ ಫೈಲ್‌ಗಳು ನನಗೆ ಅಗತ್ಯವಿಲ್ಲ. ನಾನು ಸುಲಭವಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು, ಸರಿಸಲು, ಅಳಿಸಬಹುದಾದ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಒಂದು ಫೈಲ್ ಬೇಕು. ಹೈಕುದಲ್ಲಿ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪ್ಯಾಕೇಜುಗಳನ್ನು ಬಳಸಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ .hpkg, ಇದು ಸಾವಿರಾರು ಫೈಲ್‌ಗಳಿಂದ ಪೈಥಾನ್ ಅನ್ನು ಒಂದಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತದೆ. ಆದರೆ, ಉದಾಹರಣೆಗೆ, ಪೈಥಾನ್ ಅನ್ನು ಬಳಸುವ ಸ್ಕ್ರೈಬಸ್ ಇದ್ದರೆ, ನಾನು ಕನಿಷ್ಠ ಎರಡು ಫೈಲ್‌ಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸಬೇಕು. ಮತ್ತು ಪರಸ್ಪರ ಕೆಲಸ ಮಾಡುವ ಆವೃತ್ತಿಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಲು ನಾನು ಕಾಳಜಿ ವಹಿಸಬೇಕು.

AppImages ನ ಬಹು ಆವೃತ್ತಿಗಳು ಒಂದೇ Linux ನಲ್ಲಿ ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ಚಾಲನೆಯಾಗುತ್ತಿವೆ

ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್‌ನ ದೃಷ್ಟಿಕೋನ

ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ ನೋಡೋಣ:

ನಾನು ಸಂಪೂರ್ಣ ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ನಿಯಂತ್ರಿಸಲು ಬಯಸುತ್ತೇನೆ. ನಾನು ಯಾವಾಗ ಮತ್ತು ಹೇಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬೇಕು ಎಂದು ಹೇಳಲು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅವಲಂಬಿಸಲು ನಾನು ಬಯಸುವುದಿಲ್ಲ. ಹೈಕು ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮದೇ ಆದ hpkg ರೆಪೊಸಿಟರಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಇದರರ್ಥ ಬಳಕೆದಾರರು ಅವುಗಳನ್ನು ಕೈಯಾರೆ ಹೊಂದಿಸಬೇಕಾಗುತ್ತದೆ, ಇದು ಕಲ್ಪನೆಯನ್ನು "ಕಡಿಮೆ ಆಕರ್ಷಕ" ಮಾಡುತ್ತದೆ.
ನಾನು ವಿತರಿಸುವ ನನ್ನ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ನಾನು ಡೌನ್‌ಲೋಡ್ ಪುಟವನ್ನು ಹೊಂದಿದ್ದೇನೆ .exe ವಿಂಡೋಸ್‌ಗಾಗಿ, .dmg ಮ್ಯಾಕ್ ಮತ್ತು .AppImage Linux ಗಾಗಿ. ಅಥವಾ ಬಹುಶಃ ನಾನು ಈ ಪುಟಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ಹಣಗಳಿಸಲು ಬಯಸುತ್ತೇನೆ, ಏನಾದರೂ ಸಾಧ್ಯವೇ? ಹೈಕಿಗಾಗಿ ನಾನು ಏನು ಹಾಕಬೇಕು? ಫೈಲ್ ಸಾಕು .hpkg ಹೈಕುಪೋರ್ಟ್‌ಗಳಿಂದ ಮಾತ್ರ ಅವಲಂಬನೆಗಳೊಂದಿಗೆ
ನನ್ನ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಇತರ ಸಾಫ್ಟ್‌ವೇರ್‌ನ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಗಳ ಅಗತ್ಯವಿದೆ. ಉದಾಹರಣೆಗೆ, ಕ್ರಿತಾಗೆ ಕ್ಯೂಟಿಯ ಪ್ಯಾಚ್ಡ್ ಆವೃತ್ತಿಯ ಅಗತ್ಯವಿದೆ ಎಂದು ತಿಳಿದಿದೆ, ಅಥವಾ ಕ್ಯೂಟಿಯ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಗೆ ಉತ್ತಮವಾದ ಟ್ಯೂನ್ ಆಗಿರುತ್ತದೆ, ಕನಿಷ್ಠ ತೇಪೆಗಳನ್ನು ಕ್ಯೂಟಿಗೆ ತಳ್ಳುವವರೆಗೆ. ಪ್ಯಾಕೇಜ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ನಿಮ್ಮ ಸ್ವಂತ Qt ಅನ್ನು ನೀವು ಪ್ಯಾಕೇಜ್ ಮಾಡಬಹುದು .hpkg, ಆದರೆ ಹೆಚ್ಚಾಗಿ ಇದು ಸ್ವಾಗತಾರ್ಹವಲ್ಲ.

ನಿಯಮಿತ ಅಪ್ಲಿಕೇಶನ್ ಡೌನ್‌ಲೋಡ್ ಪುಟ. ಹೈಕುಗಾಗಿ ನಾನು ಇಲ್ಲಿ ಏನು ಪೋಸ್ಟ್ ಮಾಡಬೇಕು?

ವಿಲ್ ಬಂಡಲ್‌ಗಳು (ಅಪ್ಲಿಕೇಶನ್ ಡೈರೆಕ್ಟರಿಗಳಂತೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ AppDir ಅಥವಾ .app Apple ಶೈಲಿಯಲ್ಲಿ) ಮತ್ತು/ಅಥವಾ ಚಿತ್ರಗಳು (ಅತ್ಯಂತ ಮಾರ್ಪಡಿಸಿದ AppImages ರೂಪದಲ್ಲಿ ಅಥವಾ .dmg Apple ನಿಂದ) ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹೈಕು ಡೆಸ್ಕ್‌ಟಾಪ್ ಪರಿಸರಕ್ಕೆ ಉಪಯುಕ್ತ ಸೇರ್ಪಡೆಯಾಗಿದೆಯೇ? ಅಥವಾ ಇದು ಇಡೀ ಚಿತ್ರವನ್ನು ದುರ್ಬಲಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ವಿಘಟನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಸಂಕೀರ್ಣತೆಯನ್ನು ಸೇರಿಸುತ್ತದೆಯೇ? ನಾನು ಹರಿದಿದ್ದೇನೆ: ಒಂದೆಡೆ, ಹೈಕುದ ಸೌಂದರ್ಯ ಮತ್ತು ಅತ್ಯಾಧುನಿಕತೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಏನನ್ನಾದರೂ ಮಾಡಲು ಒಂದು ಮಾರ್ಗವಿದೆ ಎಂಬ ಅಂಶವನ್ನು ಆಧರಿಸಿದೆ. ಮತ್ತೊಂದೆಡೆ, ಕ್ಯಾಟಲಾಗ್‌ಗಳು ಮತ್ತು/ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಸೂಟ್‌ಗಳಿಗಾಗಿ ಹೆಚ್ಚಿನ ಮೂಲಸೌಕರ್ಯಗಳು ಈಗಾಗಲೇ ಜಾರಿಯಲ್ಲಿವೆ, ಆದ್ದರಿಂದ ಸಿಸ್ಟಮ್ ಉಳಿದ ಕೆಲವು ಪ್ರತಿಶತವನ್ನು ಸ್ಥಳದಲ್ಲಿ ಬೀಳುವಂತೆ ಕೂಗುತ್ತದೆ.

ಡೆವಲಪರ್ ಪ್ರಕಾರ ಶ್ರೀ waddlesplash

Linux ನಲ್ಲಿ ಅವರು (ಕ್ಯಾಟಲಾಗ್‌ಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕಿಟ್‌ಗಳು, - ಅಂದಾಜು. ಅನುವಾದಕ) ಹೆಚ್ಚಾಗಿ ವ್ಯವಸ್ಥಿತ ಸಮಸ್ಯೆಗಳಿಗೆ ತಾಂತ್ರಿಕ ಪರಿಹಾರವಾಗಿದೆ. ಹೈಕುದಲ್ಲಿ ನಾವು ಸಿಸ್ಟಮ್ ಸಮಸ್ಯೆಗಳನ್ನು ಸರಳವಾಗಿ ಪರಿಹರಿಸಲು ಬಯಸುತ್ತೇವೆ.

ನೀವು ಏನು ಯೋಚಿಸುತ್ತೀರಿ?

ನೀವು ಉತ್ತರಿಸುವ ಮೊದಲು ...

ನಿರೀಕ್ಷಿಸಿ, ನಾವು ತ್ವರಿತ ರಿಯಾಲಿಟಿ ಚೆಕ್ ಮಾಡೋಣ: ವಾಸ್ತವವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಡೈರೆಕ್ಟರಿಗಳು - ಈಗಾಗಲೇ ಹೈಕು ಭಾಗ:

ಹೈಕುದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಡೈರೆಕ್ಟರಿಗಳು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ, ಆದರೆ ಫೈಲ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ ಇನ್ನೂ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ

ಅವರು ಹೇಳುವುದಾದರೆ, ಮ್ಯಾಕಿಂತೋಷ್ ಫೈಂಡರ್‌ನಂತೆ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ. QtCreator ಡೈರೆಕ್ಟರಿಯು ಮೇಲಿನ ಎಡ ಮೂಲೆಯಲ್ಲಿ "QtCreator" ಹೆಸರು ಮತ್ತು ಐಕಾನ್ ಹೊಂದಿದ್ದರೆ, ಡಬಲ್-ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದರೆ ಅದು ಎಷ್ಟು ತಂಪಾಗಿರುತ್ತದೆ?

ಸ್ವಲ್ಪ ಮುಂಚಿತವಾಗಿ ನಾನು ಈಗಾಗಲೇ ಎಂದು ಕೇಳಿದರು:

ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಟೋರ್‌ಗಳು ಮತ್ತು ವಿತರಣಾ ರೆಪೊಸಿಟರಿಗಳು ಮತ್ತು ಅವುಗಳ ಅವಲಂಬನೆಗಳನ್ನು ಮರೆತಿರುವಾಗ ನೀವು ಇಂದು ನಿಮ್ಮ ದಶಕದ-ಹಳೆಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಚಲಾಯಿಸಬಹುದು ಎಂದು ನೀವು ಖಚಿತವಾಗಿ ಬಯಸುವಿರಾ? ಭವಿಷ್ಯದಲ್ಲಿ ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಕೆಲಸವನ್ನು ನೀವು ಇನ್ನೂ ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ನಿಮಗೆ ವಿಶ್ವಾಸವಿದೆಯೇ?

ಹೈಕುದಿಂದ ಈಗಾಗಲೇ ಉತ್ತರವಿದೆಯೇ ಅಥವಾ ಕ್ಯಾಟಲಾಗ್‌ಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಬಂಡಲ್‌ಗಳು ಇಲ್ಲಿ ಸಹಾಯ ಮಾಡಬಹುದೇ? ಅವರು ಮಾಡಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಶ್ರೀ ಪ್ರಕಾರ. ವಾಡ್ಲ್‌ಸ್ಪ್ಲಾಶ್:

ಹೌದು, ಈ ಪ್ರಶ್ನೆಗೆ ನಮ್ಮಲ್ಲಿ ಉತ್ತರವಿದೆ: ಯಾರಾದರೂ ತಮ್ಮ ಫೈಲ್ ಫಾರ್ಮ್ಯಾಟ್‌ಗಳನ್ನು ಸರಿಯಾದ ರೀತಿಯಲ್ಲಿ ಓದುವವರೆಗೆ ಅಥವಾ ಒಂದರಿಂದ ಒಂದು ಕಾರ್ಯವನ್ನು ಒದಗಿಸುವವರೆಗೆ ನಾವು ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಅಗತ್ಯವಿರುವವರೆಗೆ ಬೆಂಬಲಿಸುತ್ತೇವೆ. ಹೈಕುದಲ್ಲಿ BeOS R5 ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ ನಮ್ಮ ಬದ್ಧತೆಯು ಇದಕ್ಕೆ ಪುರಾವೆಯಾಗಿದೆ...

ಇದು ಖಚಿತವಾಗಿ!

ಹೈಕು ಯಾವ ಕ್ರಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು?

hpkg, ಡೈರೆಕ್ಟರಿಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಚಿತ್ರಗಳ ಶಾಂತಿಯುತ ಸಹಬಾಳ್ವೆಯನ್ನು ನಾನು ಊಹಿಸಬಲ್ಲೆ:

ಸಿಸ್ಟಮ್ ಸಾಫ್ಟ್‌ವೇರ್ ಬಳಸುತ್ತದೆ .hpkg
ಹೆಚ್ಚಾಗಿ ಬಳಸುವ ಸಾಫ್ಟ್‌ವೇರ್‌ಗಾಗಿ (ವಿಶೇಷವಾಗಿ ರೋಲಿಂಗ್ ಬಿಡುಗಡೆಗಳನ್ನು ನಿಗದಿಪಡಿಸಲು ಅಗತ್ಯವಿರುವವುಗಳು), ಬಳಸಿ .hpkg (ಎಲ್ಲಾ ಪ್ರಕರಣಗಳಲ್ಲಿ ಸರಿಸುಮಾರು 80%)
ಕೆಲವು ಮೂಲಕ ಸ್ಥಾಪಿಸಲಾಗಿದೆ .hpkg, ಅಪ್ಲಿಕೇಶನ್ ಡೈರೆಕ್ಟರಿ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಚಲಿಸುವುದರಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತವೆ (ಉದಾ QtCreator): ಅವುಗಳನ್ನು ಹೀಗೆ ವಿತರಿಸಲಾಗುತ್ತದೆ .hpkg, ಮೊದಲಿನಂತೆ.

ಶ್ರೀ waddlesplash ಬರೆಯುತ್ತಾರೆ:

ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಲು ನಿಮಗೆ ಬೇಕಾಗಿದ್ದರೆ /system/apps, ಬದಲಿಗೆ ನಾವು ಡೆಸ್ಕ್‌ಬಾರ್‌ನಲ್ಲಿರುವ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಬಳಕೆದಾರರಿಗೆ ಹೆಚ್ಚು ನಿರ್ವಹಿಸುವಂತೆ ಮಾಡಬೇಕು /system/apps ಬಳಕೆದಾರರಿಂದ ನಿಯಮಿತವಾಗಿ ತೆರೆಯಲು ಮತ್ತು ವೀಕ್ಷಿಸಲು ಉದ್ದೇಶಿಸಿಲ್ಲ (MacOS ಗಿಂತ ಭಿನ್ನವಾಗಿ). ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಹೈಕು ವಿಭಿನ್ನ ಮಾದರಿಯನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಈ ಆಯ್ಕೆಯು ಸಿದ್ಧಾಂತದಲ್ಲಿ ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದೆ.

ಹೈಕು ಅಪ್ಲಿಕೇಶನ್ ಇಮೇಜ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಮೂಲಸೌಕರ್ಯವನ್ನು ಪಡೆಯುತ್ತದೆ, ರಾತ್ರಿಯ, ನಿರಂತರ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ನಿರ್ಮಾಣಗಳು, ಹಾಗೆಯೇ ಬಳಕೆದಾರರು "ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಫ್ರೀಜ್ ಮಾಡಲು" ಬಯಸಿದಾಗ, ಖಾಸಗಿ ಮತ್ತು ಆಂತರಿಕ ಸಾಫ್ಟ್‌ವೇರ್ ಮತ್ತು ಇತರ ವಿಶೇಷ ಬಳಕೆಯ ಸಂದರ್ಭಗಳಿಗಾಗಿ (ಸುಮಾರು 20% ಎಲ್ಲಾ). ಈ ಚಿತ್ರಗಳು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಅಗತ್ಯವಾದ ಫೈಲ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ .hpkg, ಸಿಸ್ಟಮ್ನಿಂದ ಆರೋಹಿಸಲಾಗಿದೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪೂರ್ಣಗೊಂಡ ನಂತರ - ಅನ್ಮೌಂಟ್ ಮಾಡಲಾಗಿದೆ. (ಬಹುಶಃ ಫೈಲ್ ಮ್ಯಾನೇಜರ್ ಫೈಲ್‌ಗಳನ್ನು ಹಾಕಬಹುದು .hpkg ಅಪ್ಲಿಕೇಶನ್ ಚಿತ್ರಗಳಿಗೆ, ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಥವಾ ಬಳಕೆದಾರರ ಕೋರಿಕೆಯ ಮೇರೆಗೆ - ಅಲ್ಲದೆ, ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೆಟ್‌ವರ್ಕ್ ಡೈರೆಕ್ಟರಿ ಅಥವಾ ಬಾಹ್ಯ ಡ್ರೈವ್‌ಗೆ ಡ್ರ್ಯಾಗ್ ಮಾಡಿದಾಗ. ಇದು ಕೇವಲ ಒಂದು ಹಾಡು! ಅಥವಾ ಬದಲಿಗೆ ಕವನ - ಹೈಕು.) ಮತ್ತೊಂದೆಡೆ, ಬಳಕೆದಾರರು ಚಿತ್ರದ ವಿಷಯಗಳನ್ನು ಫೈಲ್‌ಗಳ ರೂಪದಲ್ಲಿ ಸ್ಥಾಪಿಸಲು ಬಯಸಬಹುದು.hpkg, ನಂತರ ಅವುಗಳನ್ನು ಹೈಕು ಡಿಪೋ ಮೂಲಕ ಸ್ಥಾಪಿಸಿದ ರೀತಿಯಲ್ಲಿಯೇ ನವೀಕರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ ... ನಾವು ಬುದ್ದಿಮತ್ತೆ ಮಾಡಬೇಕಾಗಿದೆ).

ಶ್ರೀ ಅವರಿಂದ ಉಲ್ಲೇಖ. ವಾಡ್ಲ್‌ಸ್ಪ್ಲಾಶ್:

ಬಾಹ್ಯ ಡ್ರೈವ್‌ಗಳು ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಡೈರೆಕ್ಟರಿಗಳಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರನ್ ಮಾಡುವುದು ಸಂಭಾವ್ಯವಾಗಿ ಉಪಯುಕ್ತವಾಗಬಹುದು. ಮತ್ತು pkgman ಗಾಗಿ ಹೆಚ್ಚಿನ "ವಲಯಗಳನ್ನು" ಸಂರಚಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸೇರಿಸುವುದು ಖಂಡಿತವಾಗಿಯೂ ಉತ್ತಮ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ.

ಇಂತಹ ವ್ಯವಸ್ಥೆಯು hpkg, ಡೈರೆಕ್ಟರಿಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಚಿತ್ರಗಳ ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯುತ್ತದೆ. ಅವರು ಪ್ರತ್ಯೇಕವಾಗಿ ಒಳ್ಳೆಯವರು, ಆದರೆ ಒಟ್ಟಿಗೆ ಅವರು ಅಜೇಯರಾಗುತ್ತಾರೆ.

ತೀರ್ಮಾನಕ್ಕೆ

Haiku PC ಗಾಗಿ ಸರಳ ಮತ್ತು ಅತ್ಯಾಧುನಿಕ ಬಳಕೆದಾರ ಅನುಭವವನ್ನು ಒದಗಿಸುವ ಚೌಕಟ್ಟನ್ನು ಹೊಂದಿದೆ ಮತ್ತು Linux PC ಗಾಗಿ ಸಾಮಾನ್ಯವಾಗಿ ಒದಗಿಸಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದಾಗಿದೆ. ಪ್ಯಾಕೇಜ್ ವ್ಯವಸ್ಥೆ .hpkg ಅಂತಹ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ, ಆದರೆ ಉಳಿದ ವ್ಯವಸ್ಥೆಯು ಅತ್ಯಾಧುನಿಕತೆಯಿಂದ ಕೂಡಿದೆ. ಆದಾಗ್ಯೂ, ಹೈಕು ಸರಿಯಾದ ಡೈರೆಕ್ಟರಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಇಮೇಜ್ ಬೆಂಬಲದಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತದೆ. ಹೈಕು, ಅದರ ತತ್ವಶಾಸ್ತ್ರ ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ನನಗಿಂತ ಉತ್ತಮವಾಗಿ ತಿಳಿದಿರುವ ಜನರೊಂದಿಗೆ ಇದನ್ನು ಹೇಗೆ ಉತ್ತಮವಾಗಿ ಮಾಡುವುದು ಎಂದು ಚರ್ಚಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಎಲ್ಲಾ ನಂತರ, ನಾನು ಒಂದು ವಾರದಿಂದ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಹೈಕು ಬಳಸುತ್ತಿದ್ದೇನೆ. ಅದೇನೇ ಇದ್ದರೂ, ಈ ತಾಜಾ ದೃಷ್ಟಿಕೋನವು ಹೈಕು ವಿನ್ಯಾಸಕರು, ಅಭಿವರ್ಧಕರು ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪಿಗಳಿಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಕನಿಷ್ಠ, ನಾನು ಅವರ "ಸ್ಪಾರಿಂಗ್ ಪಾಲುದಾರ" ಎಂದು ಸಂತೋಷಪಡುತ್ತೇನೆ. Linux ಅಪ್ಲಿಕೇಶನ್ ಕ್ಯಾಟಲಾಗ್‌ಗಳು ಮತ್ತು ಬಂಡಲ್‌ಗಳೊಂದಿಗೆ ನಾನು 10 ವರ್ಷಗಳ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದೇನೆ ಮತ್ತು ಹೈಕುದಲ್ಲಿ ಅವುಗಳ ಬಳಕೆಯನ್ನು ಹುಡುಕಲು ಬಯಸುತ್ತೇನೆ, ಈ ಪರಿಕಲ್ಪನೆಗಾಗಿ ಅವು ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನಾನು ಪ್ರಸ್ತಾಪಿಸಿದ ಸಂಭಾವ್ಯ ಪರಿಹಾರಗಳು ನಾನು ವಿವರಿಸಿದ ಸಮಸ್ಯೆಗಳಿಗೆ ಮಾತ್ರ ನಿಜವಲ್ಲ, ಮತ್ತು ಹೈಕು ತಂಡವು ಇತರ, ಹೆಚ್ಚು ಸೊಗಸಾದವಾದವುಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಿರ್ಧರಿಸಿದರೆ, ನಾನು ಅದಕ್ಕೆಲ್ಲ. ಮೂಲಭೂತವಾಗಿ, ನಾನು ಈಗಾಗಲೇ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂಬುದರ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಿದ್ದೇನೆ hpkg ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವಿಧಾನವನ್ನು ಬದಲಾಯಿಸದೆ ಇನ್ನಷ್ಟು ಅದ್ಭುತವಾಗಿದೆ. ಪ್ಯಾಕೇಜ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ ಹೈಕು ತಂಡವು ದೀರ್ಘಕಾಲದವರೆಗೆ ಅಪ್ಲಿಕೇಶನ್ ಬಂಡಲ್‌ಗಳ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ, ಆದರೆ ದುರದೃಷ್ಟವಶಾತ್ (ನಾನು ಭಾವಿಸುತ್ತೇನೆ) ಕಲ್ಪನೆಯು "ಬಳಕೆಯಲ್ಲಿಲ್ಲ". ಬಹುಶಃ ಅದನ್ನು ಪುನರುಜ್ಜೀವನಗೊಳಿಸುವ ಸಮಯವಿದೆಯೇ?

ನೀವೇ ಪ್ರಯತ್ನಿಸಿ! ಎಲ್ಲಾ ನಂತರ, ಹೈಕು ಯೋಜನೆಯು ಡಿವಿಡಿ ಅಥವಾ ಯುಎಸ್‌ಬಿಯಿಂದ ಬೂಟ್ ಮಾಡಲು ಚಿತ್ರಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ ежедневно.
ಪ್ರಶ್ನೆಗಳಿವೆಯೇ? ನಾವು ನಿಮ್ಮನ್ನು ರಷ್ಯನ್ ಭಾಷೆಗೆ ಆಹ್ವಾನಿಸುತ್ತೇವೆ ಟೆಲಿಗ್ರಾಮ್ ಚಾನಲ್.

ದೋಷ ಅವಲೋಕನ: C ಮತ್ತು C++ ನಲ್ಲಿ ಪಾದದಲ್ಲಿ ನಿಮ್ಮನ್ನು ಶೂಟ್ ಮಾಡುವುದು ಹೇಗೆ. ಹೈಕು ಓಎಸ್ ರೆಸಿಪಿ ಸಂಗ್ರಹ

ನಿಂದ ಲೇಖಕ ಅನುವಾದ: ಇದು ಹೈಕು ಕುರಿತ ಸರಣಿಯ ಎಂಟನೆಯ ಮತ್ತು ಅಂತಿಮ ಲೇಖನವಾಗಿದೆ.

ಲೇಖನಗಳ ಪಟ್ಟಿ: ಮೊದಲನೆಯದು ಎರಡನೆಯದು ಮೂರನೇ ನಾಲ್ಕನೇ ಐದನೇ ಆರನೇ ಏಳನೇ

ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. ಸೈನ್ ಇನ್ ಮಾಡಿ, ದಯವಿಟ್ಟು.

hpkg ಸಿಸ್ಟಮ್ ಅನ್ನು Linux ಗೆ ಪೋರ್ಟ್ ಮಾಡಲು ಇದು ಅರ್ಥವಾಗಿದೆಯೇ?

ಹೌದು
ಯಾವುದೇ
ಈಗಾಗಲೇ ಅಳವಡಿಸಲಾಗಿದೆ, ನಾನು ಕಾಮೆಂಟ್ಗಳಲ್ಲಿ ಬರೆಯುತ್ತೇನೆ

20 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 5 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.

ಮೂಲ: www.habr.com

ಬೇರೇನಾದರೂ: ಹೈಕು ಅಪ್ಲಿಕೇಶನ್ ಬಂಡಲ್‌ಗಳು?