Pull to refresh
126
0.4
Evgeny Talyzin @Mnemonik

User

Send message

Именно вера в эту черту политики "кто там чё говорит не важно, главное как оно на самом деле", или "мистическое мышление" отличает российскую политику от современной западной. В политике в 21-м веке то, что говорит представитель страны очень важно, поэтому они взвешивают каждое слово, поэтому политики уходят со своих должностей когда неосторожно сказанное слово вызывает скандал. Потому что то, что говорит представитель страны (а политик это тот, кто выражает мнение страны и её народа, а не своё) это то, какое намерение действовать по тому или иному вопросу имеет страна.

Аллегория со взрывчаткой была призвана всего лишь показать, что оценка россии как "посредственной экономической силы", но "сильным источником проблем" не противоречива. Возможно кто-то как император считает миллионами, ну там миллион "населения" туда, миллион сюда, не большая разница перед лицом мировых событий, но сейчас не 19 век, и ещё до недавнего времени даже случайный выстрел в сторону города населённого людьми попадал во все новости, не говори уж о том если он в кого попал. Была такая, знаете ли, современная тенденция, считать даже незначительные разрушения проблемами. Сложно было бы считать что Россия не стала гораздо большей/сильной/значительной угрозой миру в этом плане, как в плане риторики, так и на деле.

В аналитических отчётах НАТО всегда была "большая опасность" и "меньшая опасность". И это не константа которую определили наши отцы как число Пи, она может меняться со временем. Россия представляла меньшую опасность десять лет назад, когда не бомбила соседние страны, и представляет большую опасность сейчас, когда открыто каждый день говорит что ради достижения своих целей готова прибегнуть к любым мерам. И это не называется русофобия, русофобией называется предвзятое отношение без оснований. Тут же оценка делается на основе и действий, и особенно заявлений о намерениях. Болтать всё что угодно, а потом сказать "ну вы же понимаете, это же несерьёзно всё было" можно с друганами в шестом классе.

РФ может быть крайне слабой в демографическом и экономическом плане, но крайне сильной в плане разрушений и проблем которые может нанести, так же как килограмм взрывчатки крайне энергоэффективно упакован и содержит огромное количество энергии которую может выделить, но крайне мало эффективен в качестве еды, которая вроде как тоже представляет собой источник энергии.

"Сам протокол" не "не запрещает" GET с Body. До 2014-го года RFC2616 (HTTP 1.1 Spec) декларировал что GET запрос может иметь Body, но этот Body должен быть проигнорирован сервером. Если сервер как-то обрабатывает Body, и его ответ меняется в зависимости от передаваемых в нём данных - он нарушает RFC.

После 2014-го это убрали, и заменили на "body GET запроса не имеет семантики и может вызвать реджект запроса".

Это собственно довольно заметно становится в последнее время. Всё больше библиотек просто зафейлит и исходящий GET реквест с Body (javascript fetch, Unity из тех с чем я работал), и входящий GET c Body (вот на вскидку не помню...).

Так что GET с Body был прикольным костылём, но сейчас уже пора писать прямо что это не просто плохая практика, а что так вообще делать нельзя.

Нет, он имеет ввиду что он делает /castrandom, получает то, что выбросил внутренний рандом игры, сравнивает с той последовательностью что есть у него исходя из формулы, если число совпало, повторяет и сверяет следующее (в своей последовательности), если не совпало - двигается дальше по своей последовательности, пока не найдёт тот участок, на котором в данный момент находится внутренний рандом. собственно узнав место в последовательности на котором находится внутренний рандом все следующие числа которые будут выкинуты - доступны. ничего он не передопределяет, "сдвигаем RNG" в этом контексте - это поиск по последовательности которая у него на руках в поисках последовательности которую выкидывает внутренний рандом.

"прокручивать рандом пока не выпадет нужное число" в вашей концепции прямо скажем сильно странное занятие. ну вот мне нужно число 6, я буду крутить рандом пока не выпадет 6. докручу. ииииии...??? ну как бы, я победитель, безусловно, что дальше-то?..

Ничего он там не предопределял. Я специально внимательно прочитал что он делал конкретно.

Он создавал список из нескольких заклинаний в виде листа, который можно вызывать как "castrandom", чтобы "закрытое окружение", то есть сам код игры, скастовало из этого списка рандомное заклинание. потом, исходя из того какое заклинание было скастовано, выводил какое число выбросил рандом кода игры, и, прогнав этот же процесс несколько раз, исходя из того что код для рандома явно лажовый, получал возможность узнать какие числа будут следующими.

вопрос остаётся всё тем же - и чо?..

castrandom итак довольно малоприменимый вызов, ума не приложу для чего им можно пользоваться, ну так ты получишь возможность узнать что из списка который ты сам же составил будет вызвано следующим. умопомрачительные знания, просто хоть стой хоть падай (сарказм). с тем же успехом можно просто составить лист заклинаний и вызывать их подряд, и они ВОТ ЭТО ПОВОРОТ будут вызываться в нужном тебе порядке...

вполне возможно что рандом-то на клиенте как раз был не самый успешный именно потому что лучше и не нужен...

ну допустим был бы ещё вариант размотав внутреннее состояние генератора случайных чисел узнать какой будет следующий /roll, но как там сверху заметили уже, - если бы /roll обсчитывался на клиенте, его бы уже давно наклонили и без аддонов...

Это вы так поняли если статью прочитали, но в сам вов не играли и аддоны не писали.

Я и играл и писал, и такой проблемы там нет вообще.

Аддоны в вове наверное лучший пример того как надо делать расширяемую игру со скриптовым языком. Это event based система, у которой есть огромный лист эвентов за которые можно цепляться и выполнять свой код, реагируя на это как угодно, либо как-то обрабатывая данные логически, либо рисуя на экране что угодно (с довольно простым фреймворком который позволет быстро накидывать на экран примитивы - цифры там разные, либо небольшие спрайты, либо UI элементы которые можно описать .xml файлами).

Так вот этот event stream просто огромен, вов отправляет абсолютно всю инфу в клиента и она вся доступна для того чтобы к ней цепляться. И твои изменения здоровья, и изменения здоровья всех вокруг и все эвенты в определённом радиусе даже если ты их не видишь на экране. Даже рудиментарное отслеживание движений присутствует. То есть можно узнать насколько от тебя далеко кто-то находится, и даже прицепиться к эвенту типа "что-то стало ближе такого-то расстояния ко мне". Отличная, мощная система, спроектированная так, как нужно делать нерд системы для нердов в играх, а не какой-то куцый обрубок с "ну мы подумали вот этого вам хватит, чё вам там ковыряться в нашей игре, вы же не программисты".

Lua прекрасный выбор языка для всего этого. Это один поток, безумно скоростной язык из-за своей простоты. Нужно постараться чтобы всрать производительность даже если ты очень плохо пишешь. Что кстати доказывают тысячи аддонов для вова. Многие из них написаны геймерами, а не программистами.

Короче всё со скриптовой подсистемой в вове нормально, логично, не противоречиво и совсем практически ничем не ограничено.

Конечно есть ограничения которые не позволят сделать прям полноценного бота - никак нельзя контролировать перемещение персонажа, и при входе в состояние боя лочиться АПИ применения заклинаний. То есть не получиться сделать какого-то бота которого можно будет таскать за собой, а он будет допустим автоматом тебя лечить когда твоё здоровье упало до кого-то минимума. Это практически всё из реальных серъёзных ограничений, всё остальное это какие-то реакции на то как кто-то супер умный смог хардкорно запилить что-то через АПИ что покоробило игровой баланс или вводило какие-то фичи которые близзард намеренно запрещали. Типа нельзя использовать АПИ чата до достижения какого-то уровня, и всемирный АПИ не гарантирует ни чтение ни отправление сообщений (люди делали аддоны которые позволяли синхронизироваться через весь мир друг с другом).

Абсолютно никаких проблем, описаных в статье я вообще не помню, и автор комментария выше задал тот же самый вопрос который возник и у меня после прочтения - "и чо?". Не помню ни одной проблемы в вове которую можно было бы размотать предсказав следующее число в генераторе случайных чисел на клиенте. Да я даже не представляю особо что там на клиенте генератором случайных чисел производится...

Сами программки — просто технические инструменты для скачивания общедоступногоконтента, они ничего не воруют и не пиратят.

Если контент общедоступный, обратились бы к его авторам и получили прямо от них, делов-то...

Все пользователи одной ОС, например винды, попав на мак (или линукс) отчаянно бросаются "осваивать" его, называя почему-то этим словом бесконечную затяжную попытку сделать всё "как привычно", то есть как на другой ОС. Потом пишут огромную статью на хабр о каждой мелочи которую смогли подпилить, подкрутить, подменить, немножко подогнуть и сделать "правильно". И страшно довольны и результатом, и статьёй, столько добра принесли в мир, такой ценный подробный гайд!..

Печальная правда такова, что всё это вода и наносное и особо никому не понадобится никогда... Либо вы через год вернётесь на свою винду, устав бесконечно бороться с тем что по вам "не так" на маке, либо врубитесь что к чему, просто станете пользоваться тем что предлагает мак на маке, потому что это удобно и логично, а на винде тем что предлагает винда, потому что это удобно и логично, и со стыдом и усмешкой будете вспоминать и посматривать на эту длинную простыню, ну уж не удалять же...

У нас есть новая отличная быстрая архитектура aarch64, и куча тулзов которые уже годы её поддерживают, позволяющие использовать её в любых задачах.

Но нет, давайте заколотим костылей по кругу, и запустим эмуляцию x86_64 потому что всё новое очень страшно...

Не надо так. Просто собирайте контейнеры под две архитектуры, это не сложно. Особенно с учётом того что сервера на aarch64 уже вполне себе распространённая вещь, они дешевле и зачастую быстрее.

Надо один раз настроить билдер, чтобы создавались контейнеры под обе архитектуры и multiarch манифест, и никто даже не догадается что у кого-то arm, а у кого-то intel.

увидел кучу макбуков, подумал «вот это дичь», прочитал про 1 айфон - 1 макбук, подумал что «дичь конечно, но теперь понятно почему». потом сразу подумал - а не пробовали виртуализировать macos и пробрасывать usb порты в виртуалки? macos легально запускать в виртуалке на другой макос (хардваре эппл), не пробовали поставить макмини помощнее, запустить на нем пяток виртуалок и пробросить в каждую 1 usb порт?

а в целом нереальный респект за очевидный «колхоз», но без снобизма объяснённый зачем так сделано и почему. нестандартные задачи требуют нестандартных решений!

И это всё так же не имеет смысла для домашнего стенда описанного в статье.

Не представляю что надо делать с кластером чтобы убить его мастер за 4 месяца.

У меня есть тестовый стенд с которым я что только не делал, и сертификаты на нём кончались, и неудачное обновление CNI выводило из строя всю сеть, но мастер это просто пара процессов и файлы в двух директориях на диске. Причём не так много. Пока эти файлы целые - ничего с мастером не случиться.

Все эти мануалы о том как надо бахнуть три мастера обязательно, а то развернуться ворота в ад это безусловно классно, если вы делаете кластер для сбербанка. Но для домашней лаборатории три виртуалки для задачи с которой справляется raspberrypi просто потому что так написано в документациях которые писали люди которые прочли другие документации - это чистый карго культ и шаманизм делания ради делания без понимания что вы делаете.

В статье говорится про тестовый кластер для экспериментов.

И давайте ещё раз, как high-available соотносится с мастерами? мастер это control-plane, если он выключится, high-availability данных не изменится, всё что в кластере запущено так и будет работать и отвечать. Пропадёт возможность управлять кластером, но это всё. На доступность данных это не повлияет.

если .ValueString это "[ var='B0' metric='Zombie' labels={} value=10.85 ]" то скорее всего все эти данные доступны либо как .Value.metric/.Value.value либо .Values.B0.metric/.Values.B0.value и так далее.

Как минимум в алертах это работает (там через $, как {{ $values.B0.value }})

Основная проблема новых алертов в графане не запутанность, а то что это абсолютно новая система, к которой если начать читать документацию, то дойти до раздела где будет описано то что тебе нужно почти нереально (а часто это будет вообще один абзац который можно запросто пропустить) и гугл ещё не набрал достаточное количество людей с такой же проблемой как у тебя. Раскопать что-то быстро чтобы узнать как это выписать практически невозможно сейчас.

по излишнему употреблению нелепого слова «сие» в текстах и комментариях можно всегда отличить человека который читает много всякой чуши претендующей на серьезность. да и сам такую пишет.

Если программист будет излагать свои мысли (и писать код) так, что надо учиться понимать что он имеет ввиду, я сильно скептически отношусь к тому что ему стоит писать критические статьи про других.

А вы точно не перепутали красивый код и рабочий? Потому что проблему которую вы тут так смачно описывали стопудово можно было бы решить бахнув пяток if'ов тут и там. Работало бы прям хорошо. Правда почему-то другие глядя на такое называют это legacy, да ещё и говорят так, как будто это что-то плохое...

Интересно что за люди пишут такие статьи вообще, у меня есть два варианта и оба крайние - это когда люди считают что если всё по PSR, отступы, стиль кодирования, DI, интерфейсы и наследование то такой код в принципе не содержит багов. И другой тип когда считают что если задача выполнена то продукт в принципе готов. Если код работает и проходит все тесты - это уже полный продакшн реди и в комментариях не нуждается.

Оба типа сильно ошибаются...

да вы вполне правильно поняли, что эксперт в области безопасности это наверное максимально тот самый человек который может себе позволить запускать всё что угодно, приняв меры предосторожности которые он в силу своей профессии знает очень хорошо. а то и, просто вдумайтесь, обладает несложным, не находящимся в публичном доступе способом отследить или даже ограничить выход за пределы песочницы любого, в том числе северокорейского эксплоита. а, как вам такой встречный аргумент?

"эксплоитов выходящих из песочниц"? а не подскажете рабочий, а то мне надоели бесплатные тарифы на AWS, хотелось бы захватить весь сервер там выйдя из виртуалки, должно быть несложно вроде как вы описываете.

Ни первый ни второй явно не работали с arm.

На arm декдоер видео это отдельный IP, отдельный блок в процессоре. Никакого отношения не имеет ни к видеокарте и ни к процессору. То есть в свой armv8 можно прицепить кусок одного производителя, или другого, как захочется. У rockchip этот блок называется Hantro, у Samsung - MFC, у Amlogic... блин вот взял и забыл. Ну короче не важно. Важно то, что практически для всех этих блоков нужен отдельный драйвер в ядре линукса, писать который страшная, древняя жопоболь. А потом этот драйвер ещё и должен быть корректно использован плеером, который будет в него пихать сжатые кадры, а из другого места читать распакованные. Все вендоры лабают жуткий кусок лапши для андроида который стыкуется с их древним проприетарным ядром и андроидским фреймворком для видео и перекрестившись считают на этом свою задачу выполненной. Единственная плата у которой более-менее поддержка декодирования видео работает - raspberry pi. Для их VideoCore есть драйвер в ядре и его более менее умеет использовать ffmpeg. Что уже делает его на голову продвинутей поддержки в линуксе любого другого кодека. Samsung-овский MFC был в ядре давно, но у него свой особенный интерфейс который с трудом понимает ffmpeg и чтобы его завести надо было писать прослойку для каждого плеера. Hantro от рокчипа в зачаточном состоянии, если вообще принят, а не до сих пор в виде патчей, для Amlogic Baylibre (которые просто энтузиасты которые пытаются сделать апстрим линукс работающим на процах Amlogic нормально) целый отдел создали чтобы написать драйвер который примут в апстрим. Более-менее ни шатко ни валко дело идёт, аж целый h264 вроде как работает. Возможно даже 4к. И вроде даже можно связать его с ffpmeg без особой магии.

Так вот. Для начала я сомневаюсь что Байкал вообще поставил какой-то IP для видео в процессор, зачем? И уж совсем сомнительно чтобы они написали достойный драйвер который стыкуется с ffmpeg который без труда смогут понять плееры видео. Если бы они это сделали, шум бы в чатиках которые занимаются видео на встроенных одноплатниках поднялся бы до небес.

Так что всё это скорее всего просто тупо исполняется на проце. И это настоящая печаль, потому что современный арм может h264, и даже 1080 будет видно, если прикрыть глаза и не смотреть на загрузку и температуру, но вот 4к это уже будет во-первых плохо, 24 кадра если сцена не сильно меняется, во-вторых загрузка уедет в небо сразу и прочно.

Меня одного смутило "Bare-metal" в названии и рассказ о том как запустить всё на виртуалках?..

Ещё конечно бы хотелось услышать обоснование аж трёх мастеров для тестового кластера, тогда как и продакшн справится с одним. Ведь вы же знаете что мастер не критичен для работы кластера, это control-plane. Им кластер управляется, то есть если мастера выключить, то всё мгновенно не исчезент в варпе, просто пропадёт возможность что-то менять и вообще доступ к API. но поды всё так же будут запущены и будут работать и отвечать? Знаете же да? Что в кластере с одним мастером если его перегрузить пока он перегружается особо ничего не произойдёт? Ну так зачем в тестовом кластере ТРИ мастера?

Information

Rating
1,646-th
Registered
Activity