On Thu, 25 Jul 2019 09:04:21 +0300
artiom <artiom14@yandex.ru> wrote:
> Прописывать адрес статически.
А, ну да, в IPv6 у каждого диапазон же.
Можно, конечно, особенно внутри сети.
Но сейчас всё настроено с IPv4 и автоматической выдачей адресов, не
хочется переделывать.
> Здесь все не так. И война за свободу ПО, которую начал Столлман в
> середине 80-х - проиграна.
Хм, надо будет почитать...
> Если ты не можешь написать софт, который компилируется любым GCC
> начиная с 4.6 и конччая 9.1, то ты не умеешь программировать. Если
> ты скачал откуда-то такой софт, сотри немедленно. Потому что его
> автор не умеет программировать, и отсутствие поддержки компилятора
> имеющейся у тебя версии, скорее всего не единственная и не главная
> его проблема.
Ну это излишне сильное утверждение.
Я так думаю, вы на C++ не программируете.
Правильно думаете. Я имею слишком большой опыт программирования на
этому уродце, чтобы заниматься этим в конце второго десятилетия XXI
века, когда есть Go и Rust.
Код на C писать и поддерижвать - это да, приходится. За полвека его
слишком много было написано, и хорошего.
А код на C++ который существует ну слова доброго не стоит (ну скажем
мозилла или qt).
Опять же код на столь безумно устаревших языках интересен только если у
нас есть огромная старая codebase (ну скажем mozilla или qt). А эта
codebase все равно была написана по стандартам конца прошлого века. Так
что продолжать в том же духе не столь уже сложно
(и почему gcc,
а не clang, MSVC, icc, ну и прочие?), а внятное донесение человеку
Потому что мы в debian-russian. Были бы во freebsd-russian или
macos-russian, шла бы речь про clang. Ну и понятно на какой платформе
шла бы речь про MSVC.
Лично мне clang под Debian стал интересен примерно год назад. Когда в
postgres появился jit-компилятор условий на базе llvm. И вот тут-то
оказалось что нужен И gcc, И clang. До этого я игрался периодически с
clang-analyze но как-то особой полезности в этом инструменте не увидел.
(особенно если у тебя есть 50Мб codebase четверть вековой давности, в
которой оно находит этак тысяч пять false positives).
идеи. Причём так, чтобы это ещё и быстро работало, не падая в местах,
где кривые внешние данные или нехватка ресурсов.
Вот совместимость с линейкой компиляторов очень способствует "чтобы оно
не падало в местах, где...". Разные компиляторы вылавливают в качестве
Warning-ов разные огрехи. И если все их гонять с -Werror и аналогами...
Очень полезно для этой цели также тестироваться на разных процессорах.
Вот, скажем если в тестовой ферме есть спарк, ни один не выровненный
доступ к памяти не уйдет.
> Но вообще, если нужен свеженький компилятор в deuvian, в чем
> проблема его собрать самому в пакет (а то и мейнтейнером
> заделаться).
Ну проблема в том, что это требует времени.
Так борьба с systemd тоже требует времени. Вопрос в том, на что
потратить время - на борьбу с поделиями поттерингов или на создание
альтернативы им.
Собственно проблема devuan как раз в том, что люди предпочитают бухтеть
про то, какой плохой поттеринг, вместо того чтобы засучить рукава и
сделать свое. Столлман 35 лет назад не бухтел про то какая плохая
Symbolics, а писал патчи для LMI.
А обновление зависимостей, среди которых будет glibc, от которого
зависит всё, требует ещё больше времени.
Не будет там glibc в зависимостях. Я же предлагаю собрать компилятор,
а не готовый бинарник тянуть. Я что-то в своей практике не припомню
случаев, чтобы софт такого класса, делаемый столь профессиональной
командой, не собирался бы на системе 2-3 летней давности. Там проблемы
обычно с системами более чем 15-летней давности бывают.
При этом, если моей задачей было что-то от сборки компилятора в
Devuan отличное, где-то на полпути я задумаюсь, что занимаюсь не тем,
чем требовалось.
В случае, если у меня не будет выбора, я просто возьму Docker-образ с
новым компилятором.
То есть вместо того, чтобы потратить время на то, чтобы решить проблему
для всех, вы будете тратить время и ресурсы на то, чтобы
воспользвоаться решением, сделанным за вам.
Да я не плачусь, а указываю вам на вполне объективные причины,
которые переход на Devuan блокируют.
Объективная причина тут одна - люди не хотят в этом участвовать.
Вы не хотите, я не хочу (разок сунулся, остался неуслышанным и плюнул,
все равно мне дистрибутивы с systemd поддерживать, так что знать его
придется).
Ну и прекращение их выхода для старых версий библиотек (та же OpenSSL
в конце года выкидывает какую-то версию) и прекращение официальной
разработки и поддержки старых диалектов, типа Python 2, на котором в
Devuan много что есть, тоже не стимулирует к переходу.
Подавляющее боьшинство крупных корпоративных заказчиков использует
системы на базе RHEL 6 и 7. Которые обе гораздо старее Devuan. Так что не
беспокойтесь по поводу прекращения поддержки софта менее чем
десятилетней давности.
> в ответе человеку, который вынужден
> поддерживать софт для RHEL 6, SLES 11sp4 и МСВС-6.3 (про эльбрусы я
> вообще полмолчу)...
>
Так кто же вас заставляет поддерживать всякое старьё?
Деньги, сэр. Заказчики хотят использовать именно это, и за это платят.