Припущення

Чесно кажучи, я не знаю багато про оснащення пакетами - але це питання не має значення для цього - дивіться нижче. Я припускаю, що система значно відрізняється від існуючої.

Чи має зміна сенс?

Чи є реальна потреба, достатньо сильна? Тобто - чи є новий випадок використання, достатньо важливий для розробки нового формату - та пов'язаної з ним інфраструктури?

Чи не було можливо змінити поточний метод, щоб охопити і нові випадки використання?

Або я пропускаю суть?

Цілком можливо, що те, що я бачу, - це здебільшого маркетинг - нові назви та презентація для мінімальних технічних змін, щоб отримати шанс, що будь-який орган вважає його "новим і кращим", і він може бути фактично використаний. Також, можливо, нові пакети настільки тісно базуються на існуючому форматі, що це, головним чином, зміна презентації користувачеві. Це, звичайно, може бути хорошим рішенням. У цьому випадку це питання мало б велике значення.

Тоді я би сподівався, що це все ще достатньо корисно, щоб відповісти на побічні аспекти. Просто дайте мені знати, якщо питання не корисне чи не бентежить нових користувачів, я радий його видалити.

Отже, навіщо вони існують?

Фон

Моя перша реакція була "Це не має сенсу!"

Це схоже на ситуацію, коли на сайті фізики хтось невдоволено запитав, чому ніхто не обговорює своїх блискучих нових ідей у ​​відповідях. Це сильно виглядало як ідеї про тріски; Настільки далекі від фактичних фізичних знань, що важко було знайти сенс навіть почати. Я написав відповідь, яка жодним словом не торкнулася його ідей, але пояснила, чому б просто не обговорювати припущення про ідеї кракпоту - не перший випадок цього. Думаю, відповідь насправді вплинула на точку.

Якщо мої припущення були правильними, цей випадок подібний.

Але тоді, може, ні - подивимось.

Так, є реальна потреба.

Існує реальна потреба в чомусь подібному з першого разу, коли одне програмне забезпечення залежало від іншого.

Давайте зрозуміємо це:

Управління залежностями важко .

Є причина, чому його називають пеклом залежності . Системи упаковки, такі як RPM і Debian, були створені з метою уникнути пекла залежності. Однак хтось повинен оплатити витрати:

1. У Windows, де програми вбудовують свої залежності, користувач повинен подбати про оновлення (та будь-які проблеми із безпекою через їх відсутність). Якщо я, розробник, хоче версія X для чогось свого додатка, просто: я надаю це моєму додатку. Тепер як я обробляю оновлення?
2. У більшості дистрибутивів Linux (після Debian або Red Hat), де програма може залежати від програмного забезпечення із сховища, програма з сховища повинна залежати від програмного забезпечення із сховища. Якщо я хочу, щоб версія X чогось для мого додатка, а дистрибутив надав X, простий: я від цього залежу. А якщо дистрибутиву немає? Тоді: ???
   • Додавання декількох версій до дистрибутива збільшує навантаження на сервіс
   • Втрата можливості використовувати версію вибору залежностей збільшує навантаження на розробника
   • Втрата можливості користуватися версією вибору програм засмучує користувача

Будь-яка методика втрачає свободу.

І ось тут з'являються знімки: вони дозволяють розробнику включати версію X, а система упаковки керувати оновленнями. Хто оплачує витрати? Користувач:

• вимагаючи більше місця.
• піддаючи їх ризику через недбалий розробник, який не відновлює свої знімки, коли залежність виправлена.

Які вигоди я отримую в обмін?

• Окрім безпеки за допомогою оновлень (про що, чесно кажучи, мало хто дбає), мені користувачеві не потрібно переживати про залежність, що стосується оснащення. Слово здебільшого втрачає значення.
• Крім оновлень безпеки, розробнику програмного забезпечення не потрібно турбуватися про те, щоб користувачі встановили правильні залежності.

Однією особливістю знімків, яка може бути корисною, є можливість вибору каналу для розробників, які надають більше одного каналу, наприклад, випуск , кандидат , майстер тощо.

Наприклад, натиснувши кнопку " канал" для, nextcloudз'явиться діалогове вікно на скріншоті нижче.

Іншими сильними точками продажу є ізоляція, незмінність та пісочниця, які контролюються контекстом політики безпеки , що дозволяє визначати дозволи на додаток, також звані "штекерами", наприклад:

• читати / записувати місця
• доступ до знімного сховища
• країни, де оснащення є білим / чорним списком
• доступ до мережі
• камера, принтер, джойстик, розташування GPS
• налаштування системи
• ... повний список оснащення інтерфейсів

Цей підхід певною мірою імітує пакети додатків MacOS та пісочницю додатків Android із дозволами та постачальниками / приймачами контенту.

Тепер уявіть, що вам потрібно запустити десяток додатків із кожною власною версією певних бібліотек, власною версією виконання Python / Ruby / NodeJS, і ви не хочете потрапляти в пекло залежностей і псувати або забруднювати системні бібліотеки, ваші системні модулі Python / Node / Perl / Ruby тощо.