> Правильно думаете. Я имею слишком большой опыт программирования на
> этому уродце, чтобы заниматься этим в конце второго десятилетия XXI
> века, когда есть Go и Rust.
Go - это для микросервисов, да и то, где не требуется особая
предсказуемость, как и любой язык с коллектором.
Ну и сам по себе: начали за здравие, кончили за упокой, когда туда
набежали пионеры и стали засовывать директивы в комментарии, а систему
его сборки объединять с Git, параллельно напиливая костыли, типа вендоринга.
Rust, увы, не взлетел, и похоже, что сейчас уже не предполагается.
> А код на C++ который существует ну слова доброго не стоит (ну скажем
> мозилла или qt).
Mozilla я не копал, а Qt вполне приятная библиотека, подозреваю, чем она
вас не устроила, однако в целом, достаточно неплоха.
> Опять же код на столь безумно устаревших языках интересен только если у
> нас есть огромная старая codebase (ну скажем mozilla или qt). А эта
> codebase все равно была написана по стандартам конца прошлого века.
> Так что продолжать в том же духе не столь уже сложно
Похоже, вы очень давно не программируете на C++.
Сейчас это другой язык, и от Стандарта 2003 года сильно отличается.
А насчёт "устарелости" - он в пятёрке наиболее популярных в списке TIOBE.
> Потому что мы в debian-russian. Были бы во freebsd-russian или
> macos-russian, шла бы речь про clang. Ну и понятно на какой платформе
> шла бы речь про MSVC.
>
Ну мы - да, а софт - нет: это более обоснованно, чем поддерживать всю
линейку _одного_ компилятора.
> Вот совместимость с линейкой компиляторов очень способствует "чтобы оно
> не падало в местах, где...". Разные компиляторы вылавливают в качестве
> Warning-ов разные огрехи. И если все их гонять с -Werror и аналогами...
Ну многие так делают, это неплохо.
Только не с линейкой компиляторов.
Именно с разными компиляторами: достаточно новыми версиями, как правило.
> Очень полезно для этой цели также тестироваться на разных процессорах.
> Вот, скажем если в тестовой ферме есть спарк, ни один не выровненный
> доступ к памяти не уйдет.
>
Это уже вопрос наличия ресурсов.
> Так борьба с systemd тоже требует времени. Вопрос в том, на что
> потратить время - на борьбу с поделиями поттерингов или на создание
> альтернативы им.
>
В том и дело, что я не борюсь: стараюсь обходить стороной, пока работает.
Если уж совсем что-то невменяемое, как в этот раз - отключаю.
Благо, предыдущий вариант ещё не сломали.
> Собственно проблема devuan как раз в том, что люди предпочитают бухтеть
> про то, какой плохой поттеринг, вместо того чтобы засучить рукава и
> сделать свое.
Зачем? Уже много делали. "Выбрали" творение поттеринга, потому что RH.
> Столлман 35 лет назад не бухтел про то какая плохая
> Symbolics, а писал патчи для LMI.
>
Столлман живёт в США, и он мог себе позволить бросить престижный и
дорогой ВУЗ, не опасаясь того, что ему будет негде жить и нечего есть.
Конечно, жертвенность - это вопрос приоритетов и силы духа.
Но далеко не всем требуется переписать ОС: разные приоритеты и желания,
но это не отменяет того, что хочется нормально работающую систему, а не
компиляцию поделок.
>
> То есть вместо того, чтобы потратить время на то, чтобы решить проблему
> для всех, вы будете тратить время и ресурсы на то, чтобы
> воспользвоаться решением, сделанным за вам.
>
Очевидно. Потому что, свою проблему мне надо решить в первую очередь. И,
желательно, с минимумом затрат, так что, "для всех", - это когда припрёт.
Хотите мне сказать, что это плохо? :-/
Так и вы не святой, чтобы праведно судить: делаете то, за что вам платят
заказчики.
> Объективная причина тут одна - люди не хотят в этом участвовать.
> Вы не хотите, я не хочу (разок сунулся, остался неуслышанным и плюнул,
> все равно мне дистрибутивы с systemd поддерживать, так что знать его
> придется).
>
Ну так о чём говорить? А поттеринг сунулся - не услышали, сунулся -
послали, сунулся - отгородились.
Но он делал это снова и снова, пока не пробился.
>> Ну и прекращение их выхода для старых версий библиотек (та же OpenSSL
>> в конце года выкидывает какую-то версию) и прекращение официальной
>> разработки и поддержки старых диалектов, типа Python 2, на котором в
>> Devuan много что есть, тоже не стимулирует к переходу.
>
> Подавляющее боьшинство крупных корпоративных заказчиков использует
> системы на базе RHEL 6 и 7. Которые обе гораздо старее Devuan. Так что не
> беспокойтесь по поводу прекращения поддержки софта менее чем
> десятилетней давности.
Да как факт в openssl (по-моему, 1.12.x) больше патчей не будет.
Это риск по SDL.
Его заставляют менять, следовательно, придётся обновлять то, что в
образах, а с учётом завязок других компонентов, надо обновлять саму ОС.
25.07.2019 10:12, Victor Wagner пишет:
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 (про эльбрусы я
> вообще полмолчу)...
>
Так кто же вас заставляет поддерживать всякое старьё?
Деньги, сэр. Заказчики хотят использовать именно это, и за это платят.
