Pull to refresh
33
0
Антоненко Артем @creker

Пользователь

Send message

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

В том числе по этой причине стендап и проводится в одно и тоже время

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

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

Почему с первым. В целом система защиты xbox 360 полагалась на eFuse как средство против даунгрейда. Там был счетчик, который при каждом обновлении увеличивался, физически "прожигая" фьюз.

Теоретически да с учетом, что сама ВМ написана на тех же плюсах. На практике, я не могу найти уязвимостей особо в их JITe. Почему так - сложно сказать. Возможно виной тому дизайн байткода, семантика самого языка. Его куда легче верифицировать чем JS, в котором все что угодно на уровне системы типов может твориться.

Другая часть это стандартная библиотека. Тут все очевидно. У Java и .Net она реализована на Java и C# соответственно. Тем самым, практически весь код JDK и .Net Core получает те же гарантии безопасности, что код приложений. Остается лишь относительно маленькая часть на плюсах, которая реализует GC, JIT и вот это все. Javascript и V8 реализация как минимум сделана иначе. Там и стандартная библиотека написана на плюсах и можно найти множество CVE, которые были вызваны именно этим.

И что? Для GC циклические ссылки не представляют проблемы. Или вы о чем?

Более правильный вывод

Нет, этот вывод как раз таки универсальный. Если погуглить, то примерно такая же статистика есть по Windows, Linux, iOS, macOS, android. И все эти проблемы были бы решены безопасными языками.

куда уж взломщикам понять во что выльется их попытка влезть в эту систему

Взломщикам плевать на компилятор. У них есть готовый бинарь и окружение и под них пишется шеллкод. Если надо, под конкретные версии.

Реальные уязвимости связаны с людьми и логическими ошибками

Реальные уязвимости связаны как раз с тем, что в статье перечислено. Выходы за границы, двойное освобождение, целочисленные переполнения - все это реально эксплуатируется постоянно. Более того, эксплуатируется порой не напрямую, а косвенно из того же Javascript атакуют JIT. И вы еще говорите о невозможности чего-то там взломщиками.

Эту проблему не способен решить никакой язык

Эта проблема полностью решена в GC языках как класс. Она практически полностью решена в Swift за исключением циклических ссылок. Но и они очень редко создают проблемы.

в языке Go нет 'const', при этом все функции принимают всё по (мутабельным) указателям, а менять данные из двух потоков - уб. Невероятно безопасный язык.

Во-первых, в Go не такого понятия как UB и гонки не приводят к UB в том понимании, в котором это заведено в C/C++. Есть строго определенное число возможных исходов. И самое главное, это не приведет к эксплуатируемой уязвимости. Максимум это логическая ошибка или рантайм паника.

Зато двоичный поиск генерирует кэш промахи и сбивает логику префетчинга, а на этом часто весь перформанс и умирает. Подобное надо бенчить на конкретных продовых данных.

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

Для инвалидации in-memory всех инстансов не нужно заводить редисы и прочие pub-sub. Достаточно каждый инстанс посадить на топик без consumer group и пусть каждый читает одни и теже эвенты.

По thundering herd. Есть простое решение в виде библиотеки singleflight и подобной ей механизмов. Пока один запрос выполняется, все остальные стоят и ждут на локе. После разблокировки все получат один и тот же ответ и дальше пойдет раздача из кэша. Можно сделать лок распределенным, но в большинстве случаев не страшно, если будут локальные локи и каждый инстанс пойдет на промахе один раз в основной стор.

По этой же причине отвал был и у xbox 360, и у nvidia чипов.

Помню эти времена и все эти колхозные решения. Реболл это был высший пилотаж. Обычно же в домашних условиях кулер посильнее прикручивался, так называемой метод прижима. Мой 360 в таких условиях прожил еще несколько лет. Сначала да, думали на шарики под bga. Потом уже додумали, что на самом деле проблема в креплении кристалла к подложке. А видео выше дало еще более точный ответ - проблема в компаунде. Тогда не помню, чтобы о такой версии говорили.

Можно сказать, переизобрели Loki

Именно! Когда язык не однороден - тут значение, а тут типа тоже "значение", которое указатель, появляется много не очевидных моментов в таких структурах.

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

Менять строки запрещено спецификацией языка. Там четко написано, immutable. Все отхождения от нее это неопределенное поведение. Строка может быть литералом, который указывает на read-only секцию в бинаре. Если попробуешь поменять, то получишь SIGBUS или SIGSEGV какой-нить. Если строка таки на хипе, то поведение уже вполне себе неопределенное. unsafe на то и unsafe, что он позволяет нарушать спеку и инварианты языка. Прямо как Rust.

Подобные ошибки с мапами могут совершать только совсем зеленые гошники. Всем известна простая истина - в Go абсолютно все передается по значению. И в случае мапы значение это адрес на структуру. Из этого вытекает все остальное. Тоже самое с каналами.

Это мелочи, но их должен знать даже джун. И это не является недостатками или преимуществами. Это просто особенности языка, которые есть у всех. Уж value/reference семантика так подавно. Это вполне себе обычная вещь, знакомая любому C/C++/C# программеру. С памятью надо уметь работать и Go выбрал путь, где программистам доступны некоторые подробности работы с памятью.

И правильно. Так и надо собесы проводить, где каждый вопрос позволяет немного уйти в сторону и реально проверить, что человек знает. Необязательно прогонять человека по всем вопросам. Можно на одном зависнуть, затронуть опыт работы, коснуться конкретного проекта и этого будет достаточно, чтобы понять уровень человека.

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

Если хочется подробностей, у Go есть модель памяти. Там описано, что делать можно, а что нет. Даже если бы у мапы не было перебалансировки, все равно делать так было бы нельзя. Мапа это большая структура. Операции с ней не будут атомарны и потоки будут видеть промежуточное некорректное состояние. Даже если мы один флажок пишем только в одном потоке, все равно нужны примитивы синхронизации, хотя бы какие-то. Барьер какой-нить или что-то, что и компилятору, и процессору намекнет, как правильно себя вести.

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

Неправильно.

Строки immutable типы. Для них эти проблемы неактуальны вообще.

Map это reference тип. По-значению у него передается указатель на саму структуру внутреннюю. Копии никакие не делаются.

Слайс - да, это единственный встроенный тип в Go, который имеет value семантику и копирует свое внутреннее представление. Есть мелкие особенности из-за этого (тот самый append), которые на практике проблем не доставляют. Зато профита от value семантики выше крыши. Если бы это был reference тип, то было бы в разы хуже. Неудивительно, что мейнстрим языки точно так же слайсы реализуют.

позднее включение в работу GC, настроенное по умолчанию на 1.5секунды или около того. Сколько раз отработает микросервис за это время, сколько памяти оторжут его копии?

Скорее всего нисколько. В продакшен системах дольше этих 1.5сек будут отрабатывать хелсчеки банальные. Эта особенность не стоит даже упоминания.

И вообще неплохо бы пруф. Про подобное поведение слышу в первый раз. Чисто любопытства ради знать полезно было бы, если это так. Не более.

Я специально написал про физическое ограничение, а не программное. Поэтому диод это специальная железка, которая никакой не межсетевой экран. По-другому просто такое решение никто не допустит.

 У вас же в статье вообще PHP - даже перекомпилировать ничего не нужно, поменял пару строк и всё.

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

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

Information

Rating
3,526-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity