1. Открыть терминал

2. Выполнить следующую команду, чтобы проверить, присутствует ли «deb http://http.kali.org/kali kali-rolling main non-free contrib» в файле.

Примечание. Перед http: //http.kali…. Не должно быть символа решетки #, в противном случае он закомментирован, что означает, что он не равен там вообще = не получится, переходите к шагу 3

cat /etc/apt/sources.list

3. Если нет, выполните следующую команду, чтобы добавить его

echo "deb http://http.kali.org/kali kali-rolling main non-free contrib" | sudo tee /etc/apt/sources.list

4. Обновите Kali Linux, выполните следующую команду

sudo apt update && sudo apt -y full-upgrade

5. Перезагрузите систему

reboot

6. После этого проверьте текущую версию (ваш вывод должен соответствовать следующему, если обновление прошло успешно), используйте следующие:

grep VERSION /etc/os-release

Вывод

VERSION="2020.3"

VERSION_ID="2020.3"

VERSION_CODENAME="kali-rolling"

Команда

uname -v

Вывод

1 SMP Debian 5.7.6-1kali2 (01.07.2020)

Команда

uname -r

Вывод

5.7.0-kali1-amd64

Управление и лицензирование не являются привлекательными, но их правильное выполнение жизненно важно для долгосрочного здоровья программного обеспечения с открытым исходным кодом.

Развитие программного обеспечения с открытым исходным кодом не всегда проходит гладко, особенно когда разработка программного обеспечения связана с более широкими корпоративными стратегиями.

Действительно, сложная история и неразбериха при разработке OpenOffice, скачать русскую версию OpenOffice можно на сайте https://openoffice-pc.ru/, а также разногласия между LibreOffice и Apache OpenOffice являются полезным уроком.

Они показывают, что какими бы прекрасными ни были намерения управляющей организации, такой как Sun Microsystems, последовательность и прозрачность управления и лицензирования жизненно важны для долгосрочного благополучия и успеха любого бесплатного проекта с открытым исходным кодом.

Когда Sun Microsystems в 2000 г. представила сообществу разработчиков ПО с открытым исходным кодом программный пакет StarOffice с открытым исходным кодом, компания пообещала создать самоуправляемый фонд и передать код под контроль сообщества. Но авторские права на код остались за Sun, а управление проектом оставалось за ней.OpenOffice.org (OO.o) можно было рассматривать как проект с открытым исходным кодом только в том смысле, что исходный код был видимым. Но ни лицензирование, ни управление не были прозрачными, и последующий прогресс никогда не соответствовал амбициям разработчиков.

Собственность и жесткий контроль

Sun имеет давнюю традицию вносить вклад в проекты с открытым исходным кодом и извлекать из них выгоду, но всегда сохраняет за собой право собственности и жесткий контроль. Вначале Sun лицензировала код OO.o по двойной лицензии LGPL и Sun Industry Standards Source License (SISSL). SISSL была разрешающей лицензией и позволяла повторно использовать код в проприетарных продуктах третьими сторонами.

К сентябрю 2005 года Sun отказалась от SISSL, но авторские права на код всех участников по-прежнему принадлежали Sun. Право собственности на код позволило Sun перелицензировать программное обеспечение и добавлять компенсацию за патент.

Код, номинально переданный в дар проекту под лицензией с авторским левом, был передан IBM в качестве основы для Lotus Symphony, что не входило в планы разработчиков. IBM не вносила поправок в код.

Управление OO.o оставалось внутри компании. Исправление ошибки было медленным и трудоемким. Авторы разочаровались, приходили и уходили.

Novell создала свою собственную ветвь OO.o, go-oo.org, для поглощения изменений, отклоненных Sun по причинам лицензирования, и эта ветка стала установкой по умолчанию для всех дистрибутивов GNU/Linux.

Взносы сторонних разработчиков прекратились, и OO.o так и не добился того прогресса, которого от него ожидали.

Солнце садится

Когда в 2010 году Sun вошла в состав Oracle, OpenOffice.org не входил в число приоритетов компании.

После нескольких месяцев уловок со стороны Oracle и StarDivision сообщество сделало радикальный шаг, основав Document Foundation, по-настоящему независимую некоммерческую организацию по модели, обещанной Sun в начале проекта, и разработало код для создания LibreOffice.

Document Foundation был шансом исправить некоторые недостатки прошлого и создать настоящее сообщество обмена кодами.

Через шесть месяцев после объявления о выходе из состава LibreOffice Oracle объявила о своем намерении передать авторские права и товарный знак OpenOffice.org Apache Software Foundation. Этот подход также представляет собой улучшение предыдущего режима.

IBM поддержала этот шаг и объявила о своем намерении в будущем выпустить «идентичный выпуск кода Apache OpenOffice под лицензией Apache», но опасность репликации кода под другой лицензией заключалась в том, что это настраивало сообщество против сообщества, лицензию против лицензии, и Apache OpenOffice против LibreOffice.

LibreOffice предложила участие как IBM, так и Oracle и была готова перелицензировать код под слабой лицензией с авторским левом, Mozilla Public License (MPL), чтобы упростить задачу.

Но ее достижения были отвергнуты, и ветвь Apache стала излюбленным маршрутом IBM. Теперь было два офисных пакета, и у обоих возникали все возрастающие проблемы с перелицензированием программного обеспечения.

Переход Apache OpenOffice

Остаточная проблема LibreOffice заключается в том, что, хотя она предпочитает режим лицензирования с авторским левом, авторские права на код, унаследованный от Oracle-Sun, по-прежнему принадлежат Oracle.

Таким образом, разработчики LibreOffice рассматривают возможность переустановки кода LibreOffice на основе перелицензированного кода Apache, поскольку лицензия Apache позволяет повторно выпускать код под другими лицензиями.

С перелицензированием исходной базы кода OpenOffice.org на лицензию Apache License 2.0 компанией Oracle, — говорили они, — мы теперь можем постепенно переустанавливать наш собственный код поверх этого, чтобы предложить выбор лицензирования, который не только включают LGPLv3, но также любые из GPLv3.0 +, LGPLv3.0 + и AGPLv3.0 +, которые допускаются MPLv2 +.

«Это также позволит нам включать любые полезные улучшения, которые время от времени становятся доступными по этой лицензии».

Для этого есть веская причина, как заявляют разработчики: «Поскольку мы конкурируем с нашим собственным кодом, лицензированным по бесполезно разрешительной лицензии, MPL дает некоторые преимущества в привлечении коммерческих поставщиков, распространении в магазинах приложений Apple и Microsoft, а также по мере развития наших портов Android и iPhone на планшетах и ​​мобильных устройствах «.

Двойное лицензирование в рамках LGPLv3 + и Mplv2 + позволяет переносить LibreOffice в магазины приложений, которые по извращенным причинам разрешают код под лицензией MPL с авторским левом, но не допускают код под лицензией GPL с авторским левом.

Проблемы Apache OpenOffice

Однако у Apache OpenOffice есть свои особенности: текущий выпуск Apache OpenOffice основан на последнем выпуске Oracle OpenOffice.org. Но с тех пор IBM пожертвовала код Lotus Symphony для Apache с намерением интегрировать Apache OpenOffice и Lotus Symphony, который основан на более старых версиях OpenOffice.org и включает несколько лет адаптации IBM.

Следующая версия Apache OpenOffice, вероятно, будет сильно отличаться от текущей версии Apache OpenOffice, и различия, вероятно, будут касаться самого кода, потому что Lotus Symphony никогда не был открытым исходным кодом, и код никогда не выпускался в апстриме.

По сути, и Apache OpenOffice, и LibreOffice имеют одну и ту же проблему — перебазирование кода, чтобы исправить унаследованную амбивалентность в лицензировании.

Последний поворот в наследстве OpenOffice.org заключается в том, что текущий выпуск Unbreakable Linux от Oracle, который является клоном Red Hat Enterprise Linux, включает LibreOffice, ответвление сообщества OpenOffice.org , в качестве предпочтительного офиса. пакет повышения производительности, а не Apache OpenOffice, официальная версия кода, которым он когда-то владел.