Интересно, как можно выпускать «фичи» раз в неделю? За последние года 3 я мало заметил серьёзных изменений (штуки 3 могу вспомнить). Кроме напоминания об отзыве, вопросы о товаре и работа с доставкой (последнее мало относится к программной «фиче»). Ещё — немного изменили дизайн. Если «фичами» назвать патчи на баги вызванные постоянными обновлениями и плохим тестированием/изначальной архитектурой — то это большая проблема. То есть, мне как пользователю хватило бы обновлений раз в год, только для этого весь функционал необходимо было бы продумывать, реализовывать и тестировать в должной мере.
По мне — обновления должны обновлять функционал, иногда дизайн и быть не постоянными, а необходимыми (Исправление ряда, а не одной маловажной проблемы. Исправление обнаруженной серьёзной проблемы и т.п.). А если политика требует постоянных исправлений — это должно требовать и постоянное появление новых проблем, а значит что-то не так с рабочим процессом. Тем более — Ваш рабочий процесс легко масштабируется на более долгий период обновлений и можно не заставлять пользователей испытывать из-за этого неудобства. К тому же, это позволит более вдумчиво подходить к разработке, а, следовательно, создавать меньше побочных проблем требующих исправления и ещё больше экономить на тестировании (повторном тестировании).
Для разработки, администрирования и сервер держал. Из минусов — долгое установка/обновление из-за сборки/пересборки пакетов и первоначальная настройка.
Восторге от Handbook! Самое подробное и доходчивое описание всех пакетов и рекомендации к настройке которое только видел.
Конечно, после первичной настройки обычно начинаешь использовать более простые источники типа ArchWiki (с корректировкой решений под свой дистрибутив), но для изучения механизмов работы системы, описания файлов настроек пакетов и т.п. — Handbook вне конкуренции.
Вот так хорошая идеология построения дистрибутива позволяет создать не только сам дистрибутив, но и замечательную экосистему!
Правда, скажу честно — первый опыт знакомства с документацией был негативный. На то время она была не очень хорошо структурирована, на мой взгляд. Да и казалось, что обилие текста для описания простых настроек — нелепо. Но при большем погружении начинаешь понимать и «интерполировать» знания на остальную систему.
У меня о линуксе сложилось схожее мнение. Разработчики не особо стремятся сделать систему дружелюбной для пользователя.
Постоянные проблемы при обновлении ( если систему не трогать — то можно один раз настроить и радоваться, в принципе ), то несоответствие версий Qt для программ его использующих, то не соответствие старых конфигурационных файлов новым стандартом ( сейчас такого уже, вроде, нет, но во время активного внедрения systemd и довольное продолжительное время после этого — было ). Это, кстати, следствие разрозненности самих разработчиков между собой ( что странно ).
К тому же системы зависимостей зачастую требуют обновления множества компонентов и если на машине ведётся какая-то разработка и используются приложения которые сильно завися от версии библиотек ( у меня было с Qt 5.7, чтоли, и во время установки какого-то приложения требовалось обновить часть системы — поставилась 5.14 и обновлённое приложение выдавало segfault на конечном оборудовании, что не говорило о проблемах именно с Qt ), то лучше от них отказаться, чтобы не словить неожиданную, возможно, трудноразрешимую и неочевидную проблему. Было бы куда проще организовать свободное применение библиотек и приложений различных версий централизовано ( а не отдельной установкой программ из внешних источников ) — без вреда для старых компонентов.
Вообще, сам процесс настройки многих вещей в системе посредством редактирования разрозненных файлов — очень неудобен. Причём меня больше всего удивляет, что эти файлы зачастую находятся вперемешку с исполняемыми файлами и файлами библиотек. Либо присутствует плохое разделение основных конфигов от редко используемых ( которых большинство, например в Asterisk'е приходится прыгать по списку файлов в mc если надо нового абонента внести и немного подправить правила набора ). Хотя это всё серверные компоненты иерархия которых должна быть продуманна до мелочей.
Если что-то не работает у обычного пользователя ( а такое часто бывает ) — он не в состоянии это исправить и, на самом деле — это действительно нелепо иметь проблемы с абсолютно обычными вещами, для которых ПК обычно и используется ( лет 5 назад часто ловил проблемы со звуком на ровном месте из-за неправильных стандартных конфигов в Ubuntu, Archlinux и Gentoo, то есть практически в любом дистрибутиве ). Мало кому захочется иметь десктоп с проблемами со звуком или графикой ( что бывает не реже — то тормоза даже в системном GUI из-за отсутствия драйвера, то ещё какая напасть в виде артефактов ). Сложно представить выбор системы с подобными проблемами если есть другие, в которых они встречаются значительно реже.
Ну и красивый/приятный внешний вид тоже надо настраивать. Много несуразного и неудобного в использовании ( например мне огромный размер элементов управления окна в GNOME кажется нелепым и неудобным. Мало тем для Qt и GTK с одинаковым отображением элементов. ). Хотя — если будет больше именно пользователей, то, скорее всего, это быстро поправят.
А вот качество низкоуровневых утилит и серверных приложений действительно очень высокое, стабильность и скорость работы системы, малое требование к ресурсам, масштабируемость — это огромные возможности для бизнеса которых нет в больших системах типа Windows и достойна всяких похвал. Именно за это любят весь *nix (BSD, QNX, Linux, Solaris ).
Мне видится толко такое применение, достойное и единственно возможное до тех пор пока не будет организована единая система конфигураций с удобным API ( чтобы не было разрозненности в спорах и стилях настройки разных частей системы ). Это приведёт к достаточной строгости, лаконичности и удобству использования системой как разработчиками, так и для пользователями, что создаст толчок к разработке дружелюбной каждому экосистемы.
Надеюсь когда-то мы всё это увидим и даже сами разработчики убедятся в целесообразности дружелюбного подхода.
По мне — обновления должны обновлять функционал, иногда дизайн и быть не постоянными, а необходимыми (Исправление ряда, а не одной маловажной проблемы. Исправление обнаруженной серьёзной проблемы и т.п.). А если политика требует постоянных исправлений — это должно требовать и постоянное появление новых проблем, а значит что-то не так с рабочим процессом. Тем более — Ваш рабочий процесс легко масштабируется на более долгий период обновлений и можно не заставлять пользователей испытывать из-за этого неудобства. К тому же, это позволит более вдумчиво подходить к разработке, а, следовательно, создавать меньше побочных проблем требующих исправления и ещё больше экономить на тестировании (повторном тестировании).
Для разработки, администрирования и сервер держал. Из минусов — долгое установка/обновление из-за сборки/пересборки пакетов и первоначальная настройка.
Восторге от Handbook! Самое подробное и доходчивое описание всех пакетов и рекомендации к настройке которое только видел.
Конечно, после первичной настройки обычно начинаешь использовать более простые источники типа ArchWiki (с корректировкой решений под свой дистрибутив), но для изучения механизмов работы системы, описания файлов настроек пакетов и т.п. — Handbook вне конкуренции.
Вот так хорошая идеология построения дистрибутива позволяет создать не только сам дистрибутив, но и замечательную экосистему!
Правда, скажу честно — первый опыт знакомства с документацией был негативный. На то время она была не очень хорошо структурирована, на мой взгляд. Да и казалось, что обилие текста для описания простых настроек — нелепо. Но при большем погружении начинаешь понимать и «интерполировать» знания на остальную систему.
Постоянные проблемы при обновлении ( если систему не трогать — то можно один раз настроить и радоваться, в принципе ), то несоответствие версий Qt для программ его использующих, то не соответствие старых конфигурационных файлов новым стандартом ( сейчас такого уже, вроде, нет, но во время активного внедрения systemd и довольное продолжительное время после этого — было ). Это, кстати, следствие разрозненности самих разработчиков между собой ( что странно ).
К тому же системы зависимостей зачастую требуют обновления множества компонентов и если на машине ведётся какая-то разработка и используются приложения которые сильно завися от версии библиотек ( у меня было с Qt 5.7, чтоли, и во время установки какого-то приложения требовалось обновить часть системы — поставилась 5.14 и обновлённое приложение выдавало segfault на конечном оборудовании, что не говорило о проблемах именно с Qt ), то лучше от них отказаться, чтобы не словить неожиданную, возможно, трудноразрешимую и неочевидную проблему. Было бы куда проще организовать свободное применение библиотек и приложений различных версий централизовано ( а не отдельной установкой программ из внешних источников ) — без вреда для старых компонентов.
Вообще, сам процесс настройки многих вещей в системе посредством редактирования разрозненных файлов — очень неудобен. Причём меня больше всего удивляет, что эти файлы зачастую находятся вперемешку с исполняемыми файлами и файлами библиотек. Либо присутствует плохое разделение основных конфигов от редко используемых ( которых большинство, например в Asterisk'е приходится прыгать по списку файлов в mc если надо нового абонента внести и немного подправить правила набора ). Хотя это всё серверные компоненты иерархия которых должна быть продуманна до мелочей.
Если что-то не работает у обычного пользователя ( а такое часто бывает ) — он не в состоянии это исправить и, на самом деле — это действительно нелепо иметь проблемы с абсолютно обычными вещами, для которых ПК обычно и используется ( лет 5 назад часто ловил проблемы со звуком на ровном месте из-за неправильных стандартных конфигов в Ubuntu, Archlinux и Gentoo, то есть практически в любом дистрибутиве ). Мало кому захочется иметь десктоп с проблемами со звуком или графикой ( что бывает не реже — то тормоза даже в системном GUI из-за отсутствия драйвера, то ещё какая напасть в виде артефактов ). Сложно представить выбор системы с подобными проблемами если есть другие, в которых они встречаются значительно реже.
Ну и красивый/приятный внешний вид тоже надо настраивать. Много несуразного и неудобного в использовании ( например мне огромный размер элементов управления окна в GNOME кажется нелепым и неудобным. Мало тем для Qt и GTK с одинаковым отображением элементов. ). Хотя — если будет больше именно пользователей, то, скорее всего, это быстро поправят.
А вот качество низкоуровневых утилит и серверных приложений действительно очень высокое, стабильность и скорость работы системы, малое требование к ресурсам, масштабируемость — это огромные возможности для бизнеса которых нет в больших системах типа Windows и достойна всяких похвал. Именно за это любят весь *nix (BSD, QNX, Linux, Solaris ).
Мне видится толко такое применение, достойное и единственно возможное до тех пор пока не будет организована единая система конфигураций с удобным API ( чтобы не было разрозненности в спорах и стилях настройки разных частей системы ). Это приведёт к достаточной строгости, лаконичности и удобству использования системой как разработчиками, так и для пользователями, что создаст толчок к разработке дружелюбной каждому экосистемы.
Надеюсь когда-то мы всё это увидим и даже сами разработчики убедятся в целесообразности дружелюбного подхода.