Ну эта проблема может быть всегда, «не нравится чужое — компилируй сам».
решает все проблемы
Не решает это проблемы наличия небезопасных версий библиотек в комплекте. Потому что отслеживать их все руками. Если посмотреть на работу инфрраструктурой контейнеров — там вот проверка их всех на наличие известных уязвимостей достаточно острая тема. Сначала все бросились делать контейнеры, а теперь вот наконец задумались об уязвимостях либ.
подумайте о той части масс которые не хотят сложностей с системой и менеджерами пакетов
С менеджерами пакетов сложностей нет. Те, кто не хотят сложностей с системой — используют менеджеры пакетов. А вы как раз идете по достаточно сложному пути, с телодвижениями, которых можно избегать.
Осталось убедить моих клиентов
А в чем проблема? Если вы понимаете преимущества — вы их и клиентам объясните. А если не понимаете… ну тогда или поймите, или живите как привыкли.
если бы существовал только один менеджер пакетов и один репозиторий для всех существующих в мире программ и библиотек, в котором хранились бы как самые актуальные (стабильные) версии так и все предшествующие
Он существует — pacman, ArchLinux. У него есть архив старых пакетов. Если вдруг из-за новизны системы старый пакет уже не работает — пересобрать пакетом же старый под систему с обновленными либами очень легко.
но сейчас можно себе позволить не думать о shared libs и прочих анахронизмах
Shared libs нужны не для экономии места. В первую очередь они уверенность, что используется именно то, что нужно. К примеру я знаю, что версия 1.2.3 имеет эксплоит. И я, установив 1.2.4 с исправлением этого эксплоита уверен, что моя система защищена. А если у меня по системе либ версии 1.2.3 раскидано с разным софтом с десяток, уверенности у меня никакой нет.
невозможность использования менеджера пакетов обычным пользователем
Так а зачем, зачем использовать его без sudo? Сложно дописать sudo к команде что ли?
сюда входит также возможность полной переустановки системы (или её апгрейда)
Нормальную систему не надо переустанавливать. В общем попробуйте rolling release дистрибутив, например Arch, избавитесь от многих описанных проблем. Я даже с 32 на 64 без переустановки переходил (сами вспоминайте, сколько ж это лет назад вообще было), а уж нынче я вообще не представляю, зачем что-то переустанавливать на десктопе. А серверы все равно через ansible катятся и там все вышеописанные проблемы отсутствуют или решаются иначе, нежели на десктопах.
Вы не умеете пользоваться менеджерами пакетов в линуксе? Иначе непонятно, откуда такое желание вручную что-то переносить и удалять. «Менеджеры пакетов конкретного языка» типа npm ужасны как раз тем, что делают примерно как вам нравится — «давайте засунем и код, и модули в одну папку», и плевать, что потом у юзера домашний каталог на 10% занят его файлами, и на 90% непонятно чем.
Будут конечно, но я не представляю, как вписать в модель какое-то большое предложение. Ну вот к примеру этот мой комментарий вполне подходит для пароля, и запомнить мне его несложно. При этом тут такое количество символов, которое рядом с UA1D4zc54anI не валялось, что и усложняет подбор перебором на порядки.
Ну в нашем случае «офис» — это браузер (в нашем случае Firefox) и LibreOffice. Так что на линуксе десктопы уже несколько лет :) В бухгалтерии линукс + RDP из-за 1С. Так что можно прекрасно без облаков.
В зависимости от процессора и экрана ёмкость батарейки может быть очень разной для одного и того же времени автономной работы, так что если батарейка не цифрами красоваться, а ради решения конкретной задачи «продержаться без зарядки N времени», то и плясать не от цифр ёмкости батареи, а от прожорливости устройства. Ну и так далее.
Обычный заурядный шмот все равно у всех разный, и его приходится выбирать. А уж телефон так вообще — после того как выбрал наконец, запомнишь еще надолго, какой же выбрал.
А что странного? Репозиторий у себя заморозь на тот день, когда инсталлился, и раскатывайся с него какое-то время. Набежит апдейтов — обновил репо и потом через Ansible например все машины обновил. Так без проблем все живет у нас, например. На проде тоже. Арч чем чаще обновляешь — тем он стабильнее, условно говоря (меньше в будущем всплывет проблем при обновлении).
Судя по тестам — они отлично подходят туда, где резервируют уровнями выше: сервера, датацентра… А если вас устраивает RAID'ы строить — значит и нагрузка не такая высокая, на какую эти диски расчитаны.
Optane — это новое поколение памяти. По сути «SSD v 2.0». Поэтому отвечать на него будут все, но — когда смогут технологии подтянуть. А пока высокая стоимость обусловлена и новизной, и затратами на НИОКР, и просто отсутствием прямой конкуренции. Диски свежие, в первую очередь для серверов, поэтому тестов с десктопными сценариями практически нет еще (если есть толковые — делитесь ссылками!).
У нас в компании все 15 лет почта используется в первую очередь как «место, куда всяким сервисам уведомления удобно присылать». А для общения строго мессенджер. Когда-то это был ICQ, потом перешли на Jabber, сейчас в процессе очередной этап, благо наконец появились Slack, Telegram и прочее, есть из чего выбрать. Круто, что и сервисы уведомления массово учатся слать не только в почту.
Документам вообще не место ни в почте, ни в мессенджере — для этого своя система должна быть.
Просто инвентаризацию и учет надо с бухгалтерии снять (точнее — проведение инвентаризаций, постановку учета компонентов и поддержание всего этого в актуальном виде) и переложить на тех, кто может всё это сделать правильно. А в бухгалтерию отдавать уже готовые данные, какие им реально нужны. Вопрос запаса решается бюджетированием, обоснованием трат и т.д. Таким образом получается, что описанные вами претензии либо притензии к себе самому («не смог обосновать перед руководством»), либо к руководству фирмы (которое не умеет считать свои деньги, экономить и планировать). Коли первое — никогда не поздно научится, коли второе — уволится.
Ну эта проблема может быть всегда, «не нравится чужое — компилируй сам».
Не решает это проблемы наличия небезопасных версий библиотек в комплекте. Потому что отслеживать их все руками. Если посмотреть на работу инфрраструктурой контейнеров — там вот проверка их всех на наличие известных уязвимостей достаточно острая тема. Сначала все бросились делать контейнеры, а теперь вот наконец задумались об уязвимостях либ.
С менеджерами пакетов сложностей нет. Те, кто не хотят сложностей с системой — используют менеджеры пакетов. А вы как раз идете по достаточно сложному пути, с телодвижениями, которых можно избегать.
А в чем проблема? Если вы понимаете преимущества — вы их и клиентам объясните. А если не понимаете… ну тогда или поймите, или живите как привыкли.
Он существует — pacman, ArchLinux. У него есть архив старых пакетов. Если вдруг из-за новизны системы старый пакет уже не работает — пересобрать пакетом же старый под систему с обновленными либами очень легко.
Shared libs нужны не для экономии места. В первую очередь они уверенность, что используется именно то, что нужно. К примеру я знаю, что версия 1.2.3 имеет эксплоит. И я, установив 1.2.4 с исправлением этого эксплоита уверен, что моя система защищена. А если у меня по системе либ версии 1.2.3 раскидано с разным софтом с десяток, уверенности у меня никакой нет.
Так а зачем, зачем использовать его без sudo? Сложно дописать sudo к команде что ли?
Нормальную систему не надо переустанавливать. В общем попробуйте rolling release дистрибутив, например Arch, избавитесь от многих описанных проблем. Я даже с 32 на 64 без переустановки переходил (сами вспоминайте, сколько ж это лет назад вообще было), а уж нынче я вообще не представляю, зачем что-то переустанавливать на десктопе. А серверы все равно через ansible катятся и там все вышеописанные проблемы отсутствуют или решаются иначе, нежели на десктопах.
Т.е. ваш десант профессионалов до работы с Republic не знал, что надо лимиты проставлять?
Они ведь его используют, так что слово «непредвзятый» тут вряд ли подходит.
Просто во многих дистрибутивах с systemd папка /lib — симлинк на /usr/lib (равно как и /bin > /usr/bin).
Документам вообще не место ни в почте, ни в мессенджере — для этого своя система должна быть.