On Thu, 25 Jul 2019 09:04:21 +0300 artiom <artio...@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 (про эльбрусы я > > вообще полмолчу)... > > > > Так кто же вас заставляет поддерживать всякое старьё? Деньги, сэр. Заказчики хотят использовать именно это, и за это платят. --
