SWIFT не работает, кроме России, только в Иране и КНДР. Mastercard в Беларуси и Тувалу принимается. Выходит, России сейчас составляет компанию только КНДР. Но северокорейцы за 70 лет привыкли, а мы ещё нет. Так что ситуация действительно уникальная.
Меня тоже двойные кавычки подбешивают в некоторых проектах. Мне кажется, лучше всего базировать стайл-гайд на том, как работает repr() для строк: одиночные кавычки за исключением тех случаев, когда двойные кавычки помогают избежать лишнего ескейпинга. Но уж лучше кривой стайл-гайд, чем никакого.
Ну так и на хосте, без контейнеров, можно запустить разные версии приложений с разными версиями либ под капотом.
Ключевое слово «можно». При том, что обычно так не делается. Обычно все приложения в дистрибутиве линкуются с одной версией либы, насколько это возможно. На то он и дистрибутив. Докеризация, напротив, позволяет для каждого приложения тащить разные версии всего подряд – не только слинкованных либ, а вообще всего, кроме ядра – при том, что никакой необходимости в этом нет.
А вот если запускать несколько контейнеров из одного образа, где версии приложений/либ совпадают, то по сути все контейнеры ссылаются на один и тот же файл внутри образа
Я это прекрасно понимаю, но мне почему-то кажется, что на практике такие счастливые совпадения происходят нечасто.
Выражусь поконкретней. У меня хост-система, допустим, Debian с glibc, а в контейнере – Alpine с musl. Соответственно, хостовые приложения у нас связаны с одной библиотекой, а контейнеризованные – с другой. Так под glibc и musl что, не выделяется память отдельно под ту и другую?
Далее, представим себе, что у нас уже контейнеризовано что-то на Alpine версии 3.15 с musl=1.2.2, и тут мы создаём новый контейнер с Alpine 3.16 и musl=1.2.3. У нас опять происходит магия и никакого оверхеда, или всё-таки расходуется память под обе версии musl?
А если ещё чуть-чуть подумать, разве не весь юзерспейс у нас ведёт себя точно так же? Библиотеки, утилиты, шеллы? На хосте и в каждом контейнере?
Всё правильно, но стоит ещё добавить, что рептилоид сначала делает цены на свой сервис ниже, чем может стоить запуск открытой БД on-premises. И фичи Е, Ж, З он плодит не просто так, а чтобы разработчик открытой БД не мог зарабатывать на поддержке бывшего своего продукта. А уж потом, когда пользователи перейдут к нему и оригинальный разраб загнётся с голоду, тогда можно задрать цены и отыграться.
Разве неочевидно? Они же омерзительно непитоничны. Судя по всему, их скопипастили в своё время с C++ или Java только потому, что надо было что-то такое иметь в стандартной либе как можно скорее. Теперь, когда есть нормальные альтернативы (loguru и pytest), поддерживать их там нет никакого смысла.
к сожалению, стало реальностью, когда при прохождении российской границы «погранцы» (и не только они) настойчиво интересуются его профессиональной деятельностью – не IT-шник ли он... Если вдруг выясняется, что пытается выехать программист, то… были даже случаи отказа в пересечении российской границы.
SWIFT не работает, кроме России, только в Иране и КНДР. Mastercard в Беларуси и Тувалу принимается. Выходит, России сейчас составляет компанию только КНДР. Но северокорейцы за 70 лет привыкли, а мы ещё нет. Так что ситуация действительно уникальная.
Но это же правда.
Это всё же с недавнего времени не работает. Авторизация теперь только через oAuth2. Или я что-то путаю?
В общем, в качестве замены Си подойдёт любой относительно новый новый язык без стандарта и с неопределённым поведением.
А можно было использовать Scrapy, там параллельные запросы и всякие лимиты из коробки.
К тому, что альтернативная вселенная 1С ещё не видела 1990 год на своём альтернативном календаре.
Согласно Википедии, первый релиз gettext состоялся в 1990 году.
Меня тоже двойные кавычки подбешивают в некоторых проектах. Мне кажется, лучше всего базировать стайл-гайд на том, как работает
repr()для строк: одиночные кавычки за исключением тех случаев, когда двойные кавычки помогают избежать лишнего ескейпинга. Но уж лучше кривой стайл-гайд, чем никакого.Ключевое слово «можно». При том, что обычно так не делается. Обычно все приложения в дистрибутиве линкуются с одной версией либы, насколько это возможно. На то он и дистрибутив. Докеризация, напротив, позволяет для каждого приложения тащить разные версии всего подряд – не только слинкованных либ, а вообще всего, кроме ядра – при том, что никакой необходимости в этом нет.
Я это прекрасно понимаю, но мне почему-то кажется, что на практике такие счастливые совпадения происходят нечасто.
А давайте я вам тоже ссылку дам: https://en.wikipedia.org/wiki/User_space_and_kernel_space.
Выражусь поконкретней. У меня хост-система, допустим, Debian с glibc, а в контейнере – Alpine с musl. Соответственно, хостовые приложения у нас связаны с одной библиотекой, а контейнеризованные – с другой. Так под glibc и musl что, не выделяется память отдельно под ту и другую?
Далее, представим себе, что у нас уже контейнеризовано что-то на Alpine версии 3.15 с musl=1.2.2, и тут мы создаём новый контейнер с Alpine 3.16 и musl=1.2.3. У нас опять происходит магия и никакого оверхеда, или всё-таки расходуется память под обе версии musl?
А если ещё чуть-чуть подумать, разве не весь юзерспейс у нас ведёт себя точно так же? Библиотеки, утилиты, шеллы? На хосте и в каждом контейнере?
Ядро-то изолировано, а над ядром – отдельный юзерспейс, ортогональный хостовому. Как тут может не быть оверхеда по памяти?
Просто единственная ссылка на скачивание со страницы продукта ведёт на старую версию. То, что это “предыдущая” система, кстати, легко не заметить.
А какой смысл в этих гарантиях? Можно же обеспечить себе то, что нужно, а не довольствоваться тем, что завезли.
Всё правильно, но стоит ещё добавить, что рептилоид сначала делает цены на свой сервис ниже, чем может стоить запуск открытой БД on-premises. И фичи Е, Ж, З он плодит не просто так, а чтобы разработчик открытой БД не мог зарабатывать на поддержке бывшего своего продукта. А уж потом, когда пользователи перейдут к нему и оригинальный разраб загнётся с голоду, тогда можно задрать цены и отыграться.
Разве неочевидно? Они же омерзительно непитоничны. Судя по всему, их скопипастили в своё время с C++ или Java только потому, что надо было что-то такое иметь в стандартной либе как можно скорее. Теперь, когда есть нормальные альтернативы (loguru и pytest), поддерживать их там нет никакого смысла.
Ещё бы выбросили logging и unittest, вообще супер было бы.
Ответ: никак. Если страна не способна наладить контакт с одним вендором, то взаимодействовать с международным сообществом тем более не получится.
Это уже не детсад, но и не энтерпрайз никаким боком. В школе как минимум учат Scrapy.
Химического всё-таки, а не биологического.
Можно с этого места поподробнее?