Re: Установить debian без systemd
>>> портабельно".
>> Ага, и стандартов C++ должно быть минимум три, параллельно действующих
>> конечно же (не продолжающих один другой, а именно разных). И SQL, и
>
> Так так оно и есть. Вот мы сейчас поддерживаем GCC от 4.3.4 до 6.3.0,
> clang нескольких версий и MSVC от 2010 onward. Вот тебе и три разных
> стандарта, и каждый в своем развитии. Это еще у нас достаточно
> ограниченные аппетиты. А upstream по-моему до сих пор MSVC 2003
> поддерживает, плюс еще всякие компиляторы от вендорских юниксов, какие
> еще живы.
Какой апстрим поддерживает 2003-й мсвс? Его микрософт-то давно уже не
поддерживает.
Кроме того, не вполне понятно, что это значит.
Мне видится, что либо вы живёте на старом стандарте, не используя нового
из 11 и выше, либо вы медленно переписываете код на 11 и выше, а старые
ветки продукта заморожены и в них делаются только багфиксы.
Насчёт clang - у него совсем немного особенностей, которые требуется
поддерживать, и он очень хорошо совместим и со стандартом и с gcc (с ним
даже по опциям). К тому же, возможно, что он нужен исключительно для
компиляции под MacOS, и для него есть участки кода, которые gcc не
компилируются.
Это не тоже самое, что полноценная поддержка.
И делается это не потому, что "так круто и делает софт надёжнее", а
потому, что есть legacy код, который сразу не выкинешь.
Вменяемые разработчики, если вы добровольно будете разводить зоопарк
компиляторов, от вас сбегут.
>> Python, ну и шеллы тоже разные нужно применять для системных скриптов.
>
> Python постгресом официально поддерживается от 2.4 до 3.5 последних.
> И поддержка старых питонов (до 2.7) это еще тот квест. Все современные
> удобства питона вплоть до ключика -m в командной строке, оказывается,
> свойства 2.7 версии.
>
Вам нравится решать квесты?
Поддержка старого питона осталась из-за того, что третий обратно не
совместим со вторым, а на питоне есть куча софта.
Со второго постепенно уходят, его поддержку рано или поздно прекратят,
потому что наличие двух "стандартов" абсолютно никого не радует.
> Разные SQL это, к счастью, не к нам. У нас он один.
Это неправильно. Чтобы ваша система стала более надёжной, кроме SQL надо
поддержать несколько других стандартов.
Я помню, в середине 2000-х ещё писали про всякие альтернативные языки.
> Мы его не
> поддерживаем, мы его реализуем. Но я еще помню, как разрабатывал
> систему, которая была клиентом, а не сервером SQL. И во что там
> обходилась одновременная поддержка Oracle и Postgres тоже помню.
Так хорошо же. MySQL ещё не забудьте. Надёжнее же это.
> И вообще, инженеры которые занимаются миграцией клиентских систем с
> Oracle на Postgres от меня в 10 метрах сидят. Можно как-нибудь их
> раскрутить на "бойцы вспоминали минувшие дни".
>
Хех, постгрес давно уже тоже Oracle. :-)
Расскажите им, что поддерживать две разных СУБД лучше?
Потому что надёжность кода возрастает.
> А уж грустная история про башизмы в скриптах при переносе на bsd
> или solaris - это вообще. Еще есть грустные истории про сисадминов,
> которые прописали в этих системах bash логин-шеллом руту, а потом
> траблшутили несмонтировававшийся /usr/local
>
По-моему, это всё были камни в огород вашего утверждения, вам не кажется?
>> А Posix, так вообще твари, навязывают здесь свою идеологию.
>
> Posix - это как раз почти lowest common denominator. Проблема в том,
> что когда современному разработчику нужна какая-то фича, он не лезет в
> posix, стандарт C++ или еще какой руководящий документ. Он пробует это
> на своей машине, где у него стоит довольно свежая версия компилятора
> или интерпретатора с кучей нестандартных расширений, и считает, что
> если у него работает, будет работать у всех.
>
1. Если у него компилируется. А если скомпилировать надо кому-то
другому, есть стандартный компилятор, который в компании официально
принят и работает на сборочных серверах. Скомпилировал у себя, не важно
чем, работать оно всё-равно будет на всех поддерживаемых платформах
(предполагается, что на них результат проходит тесты).
2. Разработчики очень часто заглядывают в стандарт. И я заглядываю.
Особенно, если код кроссплатформенный, а если нет, то и компилить
студией мне его нафиг не надо, сойдут расширения.
> В общем. Добро пожаловать в реальный мир. В котором клиентам позарез
> нужна поддержка Windows Server 2003, HP/UX 10 на Itanium и спасибо что
> не VMS.
>
И что? Есть варианты, как это делать. И втаскивать в основную ветку
поддержку старья из-за того, что хорошо заплатили, часто не самый лучший
выход.
Reply to: