Нет, конечно, не убивает. То, что мертво, умереть не может: доля Linux на десктопах уже много лет колеблется в районе 2% и не имеет тенденции ни к росту, ни к падению, изменяясь на уровне статистической погрешности.
Как выглядит захват рынка с конкурентоспособным продуктом, можно увидеть на примере Хром : рост на 70% за 10 лет. Или Андроид : рост на 75% за 5 лет. Поддержка Google своих продуктов отчасти ответственна за их успех, но поддержка и внедрение ее платформы не являются главным двигателем: Windows Mobile (как второй, так и первой) не помогло все стоящее за ними сообщество Microsoft. Но Linux растет, самое большее, полпроцента в год , несмотря на то, что это, например, лучший из существующих вариантов использования в качестве национальной/государственной ОС.
Так что да, учитывая долю в 2%, которая не растёт, но и не падает, она всё равно «мешает росту», а не «убивает».
Отказ от ответственности Автор не претендует на абсолютную правильность выводов и суждений; данная идея является скорее семенем для обсуждения, а не всеобъемлющей концепцией.
Автор предостерегает от рассуждений с позиции «у меня такая же нога и ничего не болит», и напоминает, что личный пример не служит доказательством.
У тебя нога не болит, а у меня болит: мы здесь на равных.
Но я потрудился дать хоть какое-нибудь логическое обоснование своим тезисам; также следует потрудиться аргументировать не конкретными примерами (для каждого из них можно найти или придумать контрпример и рассказать, почему это так), а идеями.
Примеры просто иллюстрируют идеи.
Под «Настольным Linux» автор подразумевает дистрибутивы на базе GNU/Linux (Ubuntu, Debian и т. д.), установленные на обычном компьютере/ноутбуке x86/x64 с графическим интерфейсом и используемые в домашних или рабочих целях.
Сюда не входят такие системы (даже если они используют ядро Linux и его среду): 1) Android и Chrome OS: несмотря на ядро, это не Linux в том смысле, в каком мы его понимаем как продукт: у него своя оболочка, свои настройки, свои интерфейсы, свои API для программных продуктов и так далее.
.
Это не Linux, точно так же, как MacOS не BSD. 2) Конкретные встраиваемые системы, тонкие клиенты, планшеты, смарт-телевизоры, смарт-приставки: хотя планшет и телевизор вряд ли можно назвать десктопом, если к нему подключить клавиатуру, для всех этих систем, как правило, так и есть.
невозможно выбрать ОС по своему вкусу.
Что поставил производитель, то и используется.
3) Специальные рабочие станции для рендеринга, расчета данных или проектирования микросхем, суперкомпьютеры и так далее.
Некоторые из них можно использовать в качестве десктопа, но из-за требований к рабочей среде выбор ОС на них также ограничен.
Берутся данные о процентном соотношении различных операционных систем.
отсюда .
Если у кого-то есть годовая статистика за десять лет, покажите мне, будет интересно посмотреть на долгосрочные тенденции.
Так в чем дело? Почему, несмотря на все усилия, Linux, ставший де-факто стандартом для встраиваемых устройств, работающий на подавляющем большинстве серверов, полностью захватил рынок суперкомпьютеров Linux, над которым работают сотни компаний и десятки тысяч людей.
.
на обычных компьютерах и ноутбуках практически не используется? Причины такой ситуации, как ни странно, те же, что сыграли роль в популярности Linux на серверах: unix-путь, «Философия Unix»: «Пишите программы, которые делают одно дело, и делают это хорошо, и имеют возможность получать и принимать данные через текстовый интерфейс (поскольку он универсален)».
Это очень хорошее решение, когда у вас есть Нет :
- Быстрый постоянный интернет
- Переполнение стека
- Гитхаб
- Простые языки высокого уровня, такие как Python
- Куча фреймворков и библиотек для этих языков легко доступны
ситуация 90-х или 2000-х).
Если вы специалист, который понимает некоторые абстрактные понятия, готов писать скрипты ссылок и не требует кнопки «сделать все хорошо».
Базовая среда хорошего качества, которую можно комбинировать как угодно, универсальная, бесплатная, портативная и настраиваемая (если какая-то функция полностью отсутствует или обнаружена ошибка) — это серьезный шаг по сравнению с поставкой первой ВМ, где зачастую не было нормального компилятора, или с другими операционками того времени, где приходилось пользоваться тем, что тебе давали, да еще и платить за это деньги.
В таких условиях проявляются все преимущества, которые так странно звучат в наше время: «Я могу посмотреть код любой программы, могу исправить ошибку или добавить фичу и отправить ее в мейнстрим».
Эти аргументы звучат странно, поскольку они являются наследием золотой эры открытого исходного кода, когда отдельные утилиты писались на одном стандартном языке для всей кодовой базы, были небольшими, потому что выполняли одну функцию, и сопровождались одним человеком, к которому можно было обратиться.
написать письмо.
Очень приятная ситуация, если вы еще и подобный специалист. Сейчас, когда код программы — это десятки мегабайт текста (и не весь это сам код, там может быть 2 МБ XML) и огромное количество библиотек, когда сборка — это отдельное приключение, когда кодовая база написана дюжиной человек, ни один обычный пользователь не был бы в здравом уме, чтобы просмотреть весь код или попытаться исправить ошибку в чем-то вроде OpenOffice, GIMP, KDE или Chrome. Прочитать весь исходный код очень сложно, и вероятность найти там ошибку или закладку, просто взглянув на код, стремится к нулю: простые места проверены до вас, а разобраться в сложных могут только профессионалы и авторы статических анализаторов.
такие :).
Найти место, где есть ошибка, которая вас беспокоит (даже если вы можете ее воспроизвести), если вы обычный пользователь - безнадежное дело: отладка больших программ со зрелой кодовой базой (читай "устаревшей") - это отдельная задача, требующая учиться, и даже чему-то искусство .
Это произошло потому, что ситуация изменилась за 30-50 лет. Аппаратное обеспечение стало более доступным, возникло такое понятие, как десктоп, также известный как «персональный компьютер», и над ним массово стали работать простые люди, не являющиеся специалистами ни в IT, ни в программировании.
И в этой новой ситуации преимущество Linux начинает превращаться в недостаток.
Чтобы понять, почему именно это становится недостатком, нам нужно немного поговорить о том, как вообще развиваются продукты в долгосрочной перспективе.
В процессе развития IT-индустрии мы постоянно обмениваемся ресурсами для охвата пользователей: именно этим и объясняются страдания людей на тему «почему процессоры в 10 раз быстрее, а скорость текстового редактора такая же».
Скорость работы одинаковая, потому что «выгоднее» увеличивать охват людей инструментом, чем улучшать пользовательский опыт тех, кто уже охвачен.
Вы этого не видите, потому что до вас, как уже существующего пользователя, доходят только отголоски этого процесса: новые возможности, переработанный интерфейс и так далее.
А если смотреть со стороны разработчиков, новый интерфейс означает более удобную навигацию пользователя -> простоту освоения инструмента -> меньший процент отказов -> большую базу пользователей -> больше денег и ресурсов для разработки.
И это ситуация, из которой нет выхода: если ваш сосед играет грязно, то без внешнего регулирующего механизма (которым может быть, например, государство) вам придется играть грязно, иначе вы не сможете конкурировать.
с ним.
Если ваш конкурент обменивает ресурсы на пользовательскую базу, то вам придется либо сделать то же самое, либо смириться с тем фактом, что ваш конкурент будет расти, а вы — нет. Но человеку, знакомому с современным десктопным Linux, понятно, что его разработчики в принципе не прочь размениваться ресурсами для покрытия пользователей: ни один из основных дистрибутивов не старается оставаться в голом терминальном состоянии, все они предлагают графические оболочки, конфигураторы, установщики, управление новыми программами и так далее.
Таким образом, проблемой не является ни нехватка ресурсов (например, веб-приложения постоянно зависают возле этой самой черты, а их разработчики гарантируют нормальную работу своих приложений только на достаточно мощном оборудовании и последних версиях браузеров), ни нежелание разработчиков идти по стандартному пути увеличения пользовательской базы.
По крайней мере, это не главная проблема.
Так в чем дело?
Проблема лежит не в плоскости разработки, а в плоскости управления
Развитие ИТ-индустрии не просто привлекает новых пользователей.Он привлекает неподготовленный пользователи.
Те истории о том, как технарь сразу разбирается в интерфейсе телевизора, а на вопрос «ой, у вас дома наверняка такой же» отвечает «нет, я первый раз такое вижу» — это не демонстрация высокого интеллекта этого технаря, это демонстрация знания принципов, на которых построены почти все интерфейсы.
Когда за последние десять лет вы используете интерфейсы iOS, Android, Symbian, Windows, Linux, две камеры, три телевизора, кассетный магнитофон с программируемой записью, факс, копировальный аппарат, настенный пульт дистанционного управления для кондиционер, MP3-плеер и vi, тогда вы получаете наблюдательность — вы знаете, как устроено большинство интерфейсов в мире, хотя вы не можете формализовать эти знания в виде четких инструкций, но можете ими пользоваться.
Например, быстро найти нужный пункт в меню, которое вы видите впервые.
Но те пользователи, которые сейчас приходят в ИТ — всего этого у них нет. Им не нужно изобретать способы решение задач – большая часть их работы превращается из творческой в алгоритмическую, когда специалиста обучают цепочкам необходимых для работы действий, а не умению создавать эти цепочки.
Потому что это дешевле, быстрее и к тому же неплохо работает. У них нет ни желания, ни необходимости сортировать файлы по папкам: для них уже создано облако, отдельное для каждого приложения.
И зачастую это не файлы, а абстрактные «проекты».
У них нет страха потерять все: их данные не хранятся на жестком диске, и это не совсем так.
их данные, давайте будем честными.
Им не нужно иметь дело с десятками интерфейсов; они могут дорасти до сознательного возраста, не видя иного интерфейса, кроме айфона и десятка приложений на нем для настройки кондиционера, лампы и вибратора.
Именно для них созданы такие интерфейсы, как, например, Fluent (лента) в MS Office: это непривычно и, возможно, менее удобно для тех, кто привык к старому меню и умеет им пользоваться, но определенно снижает входной барьер для тех, кто еще не знает как.
Время, когда в индустрии господствовали гики, прошло.
На этот раз это удалось, потому что только у гиков хватило настойчивости добраться до дефицитного железа и разобраться в текстовых интерфейсах, написанных такими же гиковами.
Теперь борьба за пользователя происходит на другом уровне: компьютеры и телефоны доступны каждому.
И если вы хотите, чтобы вашим приложением пользовалось максимальное количество людей, вам придется ориентироваться на всех: от ребенка-второклассника с Android за 5000 и 16-летней девочки с айфоном в розовом чехле до 55-летняя женщина, которой на юбилей внук подарил ноутбук.
И общего у них будет только одно: они просто квинтэссенция негиковства.
Чтобы они могли использовать ваш продукт, вам необходимо понять, как думает среднестатистический пользователь, спроектировать и протестировать интерфейс, функциональность, функции и пути пользователя, чтобы пользовательский опыт был максимально удобным (или, перефразируя, чтобы охватить максимальное количество пользователей: для достаточно большого числа это то же самое).
Этот процесс начался не сейчас и даже не десять лет назад: уже в 1992 году (почти 30 лет назад!) в Microsoft были специальные отделы , разработавший интерфейсы новой системы.
И не просто проектировали, а проводили то, что сейчас модно называют кастдевом — интервью с живыми пользователями, проверку гипотез на прототипах.
В настоящее время фокус исследований сместился с как именно пользователь будет взаимодействовать с интерфейсом каким образом он решит свои проблемы: основные элементы интерфейса известны, прорисованы в руководствах по дизайну, SDK, фреймворках и, что гораздо важнее, они уже помнят пользователи, поэтому придумывать их не нужно, да и следует меняйте их только в том случае, если у вас есть веская причина.
В настоящее время исследования юзабилити сосредотачиваются в другом месте: сложность логики и пользовательских путей, выведенных на пользовательский уровень, возрастает, и интерфейсы необходимо менять так, чтобы эта сложность была доступна пользователям.
Если десять лет назад интерфейс выбора билетов был текстовые формы с сокращениями в окне терминала , для работы с которыми в агентствах были специальные люди, к которым нужно было подходить с ногами, и они превращали ваши запросы в команды системе, сейчас произошла серьезная трансформация - процесс подбора рейса не потерял в комбинаторной сложности (рейсов и параметров не меньше), но сложность интерфейса сильно уменьшилась: сайты типа aviasales/tutu/skyscanner создали интерфейс настолько удобный, настолько тщательно пронизанный советами, предложениями, основанными на обычных запросах пользователей, что для их Гораздо важнее успешное использование фундаментальных знаний «да, вот так можно купить билет», в этом нет ничего плохого» и согласия делать это таким образом, чем умение использовать конкретный интерфейс.
Именно поэтому главное преимущество Linux — комбинативность и расширяемость, так любимые компьютерщиками, — становится главной проблемой.
У нас есть миллионы комбинации инструментов в системе, но это слишком сложно для обычного пользователя, ему нужны десятки и сотни путей.
Но чтобы понять, какой из миллионов способов сделать доступным и простым для пользователя, нужно сосредоточиться на пользовательском опыте, нужно работать с новыми пользователями и пытаться понять, как они будут использовать новый интерфейс.
В этой части в принципе участвовать не могут разработчики и даже просто существующие пользователи — проклятие знаний не дает им возможности беспристрастно судить о качестве нового интерфейса: существующий всегда будет лучше и привычнее.
Из этого следуют два вывода: во-первых, таргетинг на не-гиков требует интервью с не-гиками, а не просто идей разработчиков о том, как «сделать это лучше», а во-вторых, интересы пользователей должны быть поставлены выше интересов разработчиков: Мало люди любят выбрасывать существующие разработки и делать кучу скучной работы, чтобы упростить путь пользователя, что самому разработчику совсем не сложно, но это придется сделать.
Именно интересы разработчиков, которые ставятся выше интересов пользователей, являются бичом Linux.
Это происходит потому, что Linux разрабатывается и поддерживается разработчиками, а другие роли (продукты, аналитики, маркетологи, дизайнеры, UI/UX, редакторы) присутствуют там лишь случайно, если они каким-то образом оказались в одном человеке с этим разработчиком (или партнер этого человека).В традиционной заказной разработке программного обеспечения, где так или иначе участвует бизнес, есть четкое понимание, что пользователь = деньги.
Возможно не сейчас, возможно в будущем, возможно он будет платить не напрямую через подписку или покупку, а через рекламу, или вообще деньги придут от инвестора (но будут рассчитываться от количества потенциально платящих пользователей).
В корпоративном (B2B, B2B2C, B2G) развитии может быть по-другому, и деньги могут генерироваться даже от того, насколько хорошо ваш продавец дружит с лицом, принимающим решения в другой компании, но в коммерческом B2C-разработке деньги приносят пользователя, а удовлетворенность целевой аудитории пользователей – это то, что конвертируется в размер аудитории, а значит, и в деньги.
В OpenSource разработке настольного Linux дело не в том, что нет денег.
Есть: различные гранты, пожертвования, платная поддержка, выделение компанией бесплатного процента времени сотрудников, оплата разработки кода через коммиты на открытие исходный код от компаний, или просто выложить весь инструмент в открытый исходный код, в конце концов, программы государственной поддержки национальных операционных систем.
Но никакого бизнеса здесь нет: обычно ни одна из этих форм оплаты не принимает количество довольных пользователей продукта или даже просто использует их в качестве показателя успеха.
А без интересов бизнеса по отношению к пользователям невозможно продвигать решения, неинтересные разработчикам: сама разработка (кодирование, тестирование, документация) и написание новых функций занимает едва ли 30-40% разработки продукта.
Остальное берут на себя: предварительный анализ существующих продуктов и рынка, разработка унифицированных и документированных интерфейсов (в случае GUI — это соглашения об одинаковых шаблонах использования элементов, в случае API — это единообразие).
и согласованность методов и формата данных), высокоуровневая документация, описывающая принципы работы с продуктом («все есть файл» — именно такой принцип, например), изучение пользовательских задач и путей (а не функционала).
доступен пользователю, но как и для чего он будет его использовать: например, подходя к tar с этой точки зрения, мне пришлось бы добавить ключи --archive и --unarchive), логику миграции между разными версиями, механика пересылки низкоуровневых ошибок на уровень пользователя и так далее.
Но для всего этого, как правило, необходимо подняться на более высокий уровень, начать рассматривать совокупность орудий как систему, нечто большее, чем сумма ее частей.
Но это противоречит философии Unix: ответственность разработчика заканчивается тем, что он делает функциональную программу с унифицированным вводом-выводом.
Его уже не волнует, насколько интерфейсы этой программы совпадают с другими программами (насколько ключ -v работает одинаково для всех консольных утилит, например: --v/-vv/-v 1 и так далее): при в тот момент, когда ему удобнее принять решение о создании интерфейса по своему вкусу (создание нового интерфейса никто не регулирует), и в будущем не существует механизма доведения успешных решений до уровня составного продукта.
Создав новое удачное интерфейсное решение в open source, вы оказываетесь между двумя злами: либо применить его самостоятельно и тем самым сломать иллюзорную схему проектирования, либо забыть об этом удачном решении и поддержать бездействием устаревшие концепции девяностых годов, созданные в других страны.
условиях и для другого поколения пользователей.
Практически невозможно гарантировать, что это удачное решение сможет попасть в другие продукты, разрабатываемые рядом с вами.
Частично за это отвечает обратная совместимость, но это не единственный механизм: с болью и возмущением питон смог перейти на третью версию, а значит, это вполне возможно.
Примеры? Да, сколько угодно.
Проблема №1: Отсутствие изоляции программы
Традиционный путь Windows — хранить данные в папке пользователя, а настройки программы — в папке программы.Необходимые программе библиотеки, за исключением системных и любых .
Net Framework, хранятся в одной папке.
Тот факт, что Windows довольно долгое время была де-факто однопользовательской ОС, наложил отпечаток в виде того, что нет ничего плохого в хранении настроек вместе с кодом и библиотеками: все равно это настройки конкретного пользователя.
А если ему действительно нужны другие настройки, он может сделать копию папки.
Была еще возможность хранить свои настройки в реестре, но это вещь, которая убивает плюс миграции, не принося ничего взамен, кроме некоторого упрощения логики записи и чтения настроек.
Сейчас Windows приходит к модели отделения пользователей друг от друга и от системных данных, поэтому современные программы полностью теряют право записи в свою папку с исполняемыми файлами и библиотеками, а настройки предлагается хранить в глубине дома пользователя.
каталог (как в Linux, см.
ниже).
Традиционный путь Linux (ну, точнее, путь *nix) заключается в хранении настроек и данных в домашней папке пользователя (отличное начало), а программные библиотеки разбросаны тонким слоем по всей системе.
Так сложилось исторически, потому что *nix-системы представляли собой многопользовательские системы, работающие на одном «сервере», к которому пользователи подключались с помощью «тонких клиентов» (очень тонких) — в минимальной версии это был принтер и клавиатура, определявшие интерфейс текстовой консоли как основной, заложивший основы того, что позволило Linux занять нынешнюю позицию на серверах.
Со временем «очень тонкий клиент» превратился в монитор, к которому подключался либо символьный генератор, либо упрощенный компьютер.
Это, в свою очередь, привело к тому, что графический интерфейс был разделен на серверную и клиентскую части, что вызывало (и продолжает вызывать) массу проблем в условиях, когда в таком разделении уже не было необходимости.
Из-за большого количества пользователей логичным решением было сэкономить место на жестком диске за счет четкого отделения исполняемых файлов от данных, а следующим логическим шагом было сэкономить место между исполняемыми файлами путем разделения специальной логики и библиотек, специфичных для приложения, которые могли бы использоваться не только это приложение.
Это почти не давало выигрыша в ранних однопользовательских системах (все равно приходилось хранить хотя бы одну копию исполняемых файлов и библиотек для них), но существенно экономило место для многопользовательских систем.
Но в современном мире ситуация изменилась.
Во-первых, резко возросло количество библиотек, пакетов и их зависимостей, возросли темпы разработки, а место на жестком диске сильно подешевело.
Во-вторых, современные системы однопользовательские.
Ну, в худшем случае, двух- или трехпользовательская: стоимость «железа» такова, что не проблема купить каждому пользователю компьютер или даже высокопроизводительную рабочую станцию (это все равно не будет стоить дороже пары зарплата специалистов).
А если ресурсов недостаточно, с развитием Интернета к вашим услугам огромное количество облачных серверов: стоимость и развитие аппаратных ресурсов позволяют перевести многопользовательский режим в область виртуальных машин: накладные расходы на это невелики, они с лихвой компенсируются изоляцией и возможностью настройки каждой виртуальной машины.
В тех приложениях, где пользователей еще много (например, в веб-сервисах), их количество настолько велико, а диапазон запросов настолько мал (я имею в виду функциональность одного сервиса по сравнению со всеми комбинациями инструментов в *nix), что нет смысла давать им настоящую многопользовательскую систему со всеми ее возможностями и недостатками, гораздо проще написать свою, маленькую и карманную, сделав это выше уровня системы, на уровне пользователя ОС: когда есть одна база данных, одна логика приложения, один веб-сервер, все это работает от одного или 2-3 пользователей ОС, но внутри они разделяют тысячи учетных записей клиентов.
Из всего этого можно сделать вывод, что современная многопользовательская работа на уровне ОС – это возможность 50% для удобства разделения пользователей и их данных внутри одного компьютера, и 50% для безопасности.
Разделение пользователей полезно, если у вас есть один домашний компьютер, а также полезно для безопасности, когда процесс веб-сервера не может прочитать данные процесса базы данных, и оба они не могут перезаписать системные файлы.
Фактически современные системы однопользовательские.
Это не значит, что нам нужно избавляться от многозадачности, но это значит, что практически не бывает ситуации, когда у нас в одном пространстве ОС находится много пользователей, использующих одни и те же программы и библиотеки, чтобы их «развал» серьезно экономил потраченные деньги.
о хранении их в памяти.
Однако программное обеспечение Linux по-прежнему использует концепцию общих библиотек, отчасти «потому что так обстоят дела», отчасти из-за преимуществ безопасности: ошибка в библиотеке SSL может создать уязвимость в десятках приложений, которые ее используют. В случае с разделяемыми библиотеками достаточно будет обновить пакет библиотеки, и при условии, что ABI библиотеки останется неизменным, все остальные приложения немедленно исправят уязвимость без каких-либо действий со стороны авторов и сопровождающих.
Альтернативой является упаковка программ в автономные сборки со всеми (или большинством) зависимостями.
Есть много вариантов - Пакеты приложений / Изображение приложения / шустрый (Убунту) / В разобранном виде (Гном), но у них есть и недостатки и критика .
Однако текущая реализация механизма общих библиотек и установки пакетов с зависимостями далека от идеального дизайна, который легко перерастает в ад зависимости , что сразу на порядок увеличивает сложность обслуживания системы: там, где в Windows нужно просто переустановить программу, в Linux приходится ковыряться в недрах пакетного менеджера.
Более того, вы можете довольно легко попасть в ситуацию ада зависимостей — при попытке установить новую версию программного обеспечения, требующую новую версию библиотеки, несовместимую с существующим программным обеспечением, погуглите, как установить вторую версию библиотеки, вводим пару команд из SO. Всё, apt-get непонятно ругается, не предлагая никаких осмысленных действий.
Из-за отсутствия механизма миграции (см.
следующий пункт) альтернатива «снести все и установить заново» превращается в долгий и утомительный перенос данных и настроек — тоже плохой вариант. Готового представления, как решить этот вопрос, у меня нет: оба подхода имеют недостатки и преимущества, даже если не учитывать иллюзорную экономию места.
Однако проблема, безусловно, есть, но без четкого понимания того, кто будет платить за ее решение, ситуация никуда не сдвинется.
И Кстати , мнение, что динамическое связывание не всегда хорошо, не только мое.
В качестве рабочего примера можно посмотреть Docker. Поскольку она работает в сегменте серверного Linux, то там есть бизнес-интересы (в стоимости ресурсов, поддержки, обновлений, сопровождения, развертывания и т.д.), которые видят решение проблемы и из-за этого голосуют за использование и развитие Docker, даже несмотря на заметные затраты ресурсов.
Это связано с тем, что основным преимуществом Docker является не быстрое развертывание и обновление приложений — этого можно было бы добиться, например, с помощью Ansible. Сильная сторона Docker — в самодостаточности образа (он несет в себе все необходимое окружение, и при правильном оформлении образа есть хорошая гарантия, что он запустится где угодно) и принудительном хранении данных и настроек отдельно.
из кода (поскольку Docker-образы эфемерны и могут быть легко удалены и созданы заново при обновлении или новом развертывании, а для пользователя де-факто они неизменны, а значит, заставляют хранить данные в другом месте).
При всем этом Docker сводит логический модуль к черному ящику: дает ему ресурсы (память, хранилище, процессор, сеть), указывает место хранения настроек и данных через единый механизм ФС (хоть что-то у нас единое) и тогда он будет работать сам по себе.
Сломанный код? Вам нужно перейти на новую версию? Образ убит, собран новый, запускается с теми же параметрами и упс, все работает как прежде.
Я говорю о логических модулях, потому что изолированы именно кусочки логики (бизнес-логики, если хотите), а не отдельные программы: контейнер может включать в себя, например, два сервиса на разных языках программирования (или языках разных версий), сами языки программирования, их зависимости и библиотеки, логика обслуживания сбоев, клиент централизованного сбора логов, мониторинг, локальная временная база данных и так далее.
Причем для десяти разных контейнеров это не разносится тонким слоем по системе, начиная мешать друг другу, а работает изолированно и отдельно друг от друга, легко убивается, сносится и переустанавливается, никоим образом не ломая хост-систему.
или друг друга.
И именно поэтому, несмотря на ситуацию, когда образ с блоком логики 5 МБ весит 500 МБ, поскольку несет в себе копию внутренностей системы, эта концепция настолько упрощает работу, что принимается бизнесом на ура.
И что интересно, у этого подхода нет таких глобальных проблем с безопасностью, как можно было бы ожидать от упаковки программного обеспечения: поскольку наши образы состоят из слоев, их можно обновлять, по сути, независимо друг от друга (на самом деле нет, они накатываются).
заново, но для конечного пользователя разница лишь во времени обновления), поэтому исправление уязвимости в стандартной библиотеке на базовом системном уровне автоматически применяется ко всем запущенным приложениям, не требуя внимания создателей финальной версии.
прикладной уровень.
Нечто подобное можно реализовать и для установки программ для настольного Linux.
Проблема №2: Сложность перехода с версии на версию.
Во времена многопользовательской среды Linux настройки были разделены на два места: настройки пользовательских программ и общесистемные настройки программ.
Пользовательские настройки находились в /home/user/.
config, а системные настройки, которые применялись к программам, не запускаемым пользователем или используемым всеми пользователями, находились в /etc. Но в процессе становления де-факто однопользовательской системы эта стройная логика была разрушена.
Например, xorg/x11 — в нынешней реальности это программа пользовательского уровня: настройки в ней настраивают конкретную видеокарту и конкретный пользовательский монитор.
Второй может использовать консоль, третий — только ssh. Но файл настроек находится в /etc (и хорошо, если не в /usr/share/X11), и он у всех один.
apt-get также является программой пользовательского уровня.
У каждого пользователя могут быть свои собственные репозитории, и не стоит пытаться установить python-4-alpha-dev для всех пользователей только потому, что для одного из них это обычная среда.
Но конфиги и репозитории находятся в /etc. apt-get, кстати, можно запустить только под rootом.
Ладно, черт с ними, с репозиториями.
А вот список установленного ПО — это точно дело пользователя, не так ли? Я устанавливаю на каждый компьютер определенный список программ, и если у нас уже есть рабочая система с репозиториями, что избавляет от необходимости загружать и устанавливать программное обеспечение вручную, давайте упростим задачу установки любимых программ на новую систему.
Как я могу получить список установленных мной пакетов?.
Никак.
Нет нормального механизма, который бы показывал, что именно вы установили (есть тут такой неофициальные решения, которые могут сломаться в любой момент), и не существует специального способа хранения этого списка вместе с пользовательскими настройками.
Ладно установил программы, раз они шарятся между Теги: #linux #Управление проектами #открытый исходный код #Финансы в ИТ #opensourse #управление проектами #Монетизация ИТ-систем
-
Сетевые Компьютеры: Неутомимые Работники
19 Oct, 24 -
Как Часто Вы Пользуетесь Такси?
19 Oct, 24
