Forwarded from partially unsupervised
Иногда люди не видят лес за деревьями, и частный случай этого - не видеть здравый смысл за чеклистами.
Например, пишет мужик из издательства и намекает, что в книжке неоригинальный контент! Мол, переработайте перед печатью кое-какие куски, "so we can't be accused of any sort of plagiarism", и любезно присылает список этих кусков.
Открываем список и видим грозные коментарии "Needs rework; extremely close to the article text" и ссылки на какой-то notion, в котором человек составляет для себя конспект книги. Рекурсия!
Например, пишет мужик из издательства и намекает, что в книжке неоригинальный контент! Мол, переработайте перед печатью кое-какие куски, "so we can't be accused of any sort of plagiarism", и любезно присылает список этих кусков.
Открываем список и видим грозные коментарии "Needs rework; extremely close to the article text" и ссылки на какой-то notion, в котором человек составляет для себя конспект книги. Рекурсия!
🤣12👍3😁2🤡2
Forwarded from Технологический Болт Генона
Компания Google подвела итоги инициативы по внедрению в Android методов безопасной разработки (Safe Coding), таких как использование языков программирования, обеспечивающих безопасную работу с памятью, применение статических анализаторов и проектирование API с оглядкой на безопасность. Изменения позволили снизить долю связанных с памятью уязвимостей в Android c 76% в 2019 году до 24% в 2024 году, что значительно ниже среднего показателя по индустрии - 70%.
Инженеры Google также сделали вывод, что основным источником проблем с безопасностью является новый код и поэтому внимание следует сосредоточить на модернизации методов разработки нового кода. Уже существующий код со временем становится более проверенным и безопасным (наблюдается экспоненциальная зависимость безопасности от времени), что делает не столь выгодными вложения в проекты по переписыванию существующего кода. Например, 5-летний код в среднем имеет в 3.4 раза меньшую плотность уязвимостей, чем новый код. Для проектов Android и Chromium благодаря внедрению методов безопасной работы с памятью разница составляет 7.4 раза.
. . .
В общем виде Google рекомендует не переписывать старый код, а сосредоточиться на написании нового кода на языках безопасно работающих с памятью и обеспечении переносимости между новым и старым кодом
. . .
Скорость и качество разработки увеличивается за счёт упрощения тестирования и смещения выявления ошибок на ранние стадии разработки, на которых ошибки становятся заметны ещё до того, как разработчик приступает к проверке кода. В качестве примера приводятся показатели отката изменений - для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже чем для кода на C++.
Методы безопасной работы с памятью позволили существенно снизить число уязвимостей в Android
https://www.opennet.iss.one/opennews/art.shtml?num=61933
Оригинал
https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
👍19🔥5
#science
TIL что некоторые системы могут иметь негативную температуру. Но такая ситуация может быть лишь в системах с конечным числом состояний с высокой энергией, так что без специальных ухищрений сформировать такую систему проблематично.
TIL что некоторые системы могут иметь негативную температуру. Но такая ситуация может быть лишь в системах с конечным числом состояний с высокой энергией, так что без специальных ухищрений сформировать такую систему проблематично.
🤯8
(#game?)
https://t.iss.one/Fourier_series/159
Выигрывает тот, кто остаётся без фингала за столом последним. Если повезёт, уже через 3-4 вопроса вы либо почувствуете моральное и интеллектуальное превосходство над остальными жалким человечеством, либо подерётесь.
https://t.iss.one/Fourier_series/159
Выигрывает тот, кто остаётся без фингала за столом последним. Если повезёт, уже через 3-4 вопроса вы либо почувствуете моральное и интеллектуальное превосходство над остальными жалким человечеством, либо подерётесь.
Telegram
Ряды Фурье
Скоро начнутся корпоративы. Вы можете навсегда войти в историю, если подложите здоровенную свинью эйчарам и принесёте эту игру. Правила: берёте случайный вопрос и каждый в компании 2-3 минуты рассказывает свою позицию по нему.
Выигрывает тот, кто остаётся…
Выигрывает тот, кто остаётся…
😁1
#prog #article
Index 1,600,000,000 Keys with Automata and Rust
Старая (от 2015 года) статья Эндрю Галланта aka BurntSushi от трансдьюсере (и его реализации на Rust): структуре данных, позволяющей компактно хранить последовательности из ограниченного алфавита. Идейно эта структура данных схожа с префиксным деревом, но позволяет совместно хранить не только общие префиксы, но и общие подпоследовательности, что позволяет эффективно хранить и опрашивать набор слов.
За счёт своей структуры трансдьюсеры также позволяют проводить нечёткий поиск и поиск при помощи регулярных выражений, а конкретно изложенная в статье реализация ещё и хранит данные на диске в формате, который позволяет пользоваться структурой данных при помощи mmap (читай, без обязательной загрузки в память целиком).
Index 1,600,000,000 Keys with Automata and Rust
Старая (от 2015 года) статья Эндрю Галланта aka BurntSushi от трансдьюсере (и его реализации на Rust): структуре данных, позволяющей компактно хранить последовательности из ограниченного алфавита. Идейно эта структура данных схожа с префиксным деревом, но позволяет совместно хранить не только общие префиксы, но и общие подпоследовательности, что позволяет эффективно хранить и опрашивать набор слов.
За счёт своей структуры трансдьюсеры также позволяют проводить нечёткий поиск и поиск при помощи регулярных выражений, а конкретно изложенная в статье реализация ещё и хранит данные на диске в формате, который позволяет пользоваться структурой данных при помощи mmap (читай, без обязательной загрузки в память целиком).
burntsushi.net
Index 1,600,000,000 Keys with Automata and Rust - Andrew Gallant's Blog
I blog mostly about my own programming projects.
👍12❤1
Forwarded from Скучный секс-блог
Слон и его погонщик: как мы выносим моральные суждения
По книге Джонатана Хайдта The Righteous Mind
Человеческая мораль не рациональна, а интуитивна. Наш мозг выносит моральные оценки мгновенно, и лишь затем разум подбирает аргументы под готовый ответ, пишет исследователь Джонатан Хайдт в книге «Праведный ум».
История про курицу
Чтобы понаблюдать, как люди решают, что хорошо и что плохо, ученый предлагал им специально сочиненные шокирующие истории. Например:
Что вы об этом думаете? Плохо ли поступает мужчина?
Если плохо, то почему? Ведь никто не пострадал. Никто этого даже не видел.
Тем не менее, большинство скажет: так нельзя! А почему нельзя?
Студенты из продвинутого американского университета довольно быстро придумывают аргументы против секса с цыпленком. Или наоборот признают: «Ладно, он извращенец, но это его право». А вот люди попроще затрудняются с аргументами, но не отступают: «Вы что, сами не понимаете, что так с курицей не делают?!»
История про брата с сестрой
Что вы об этом думаете? Правильно ли они поступили?
Специально оговорено, что никому не причинен вред. Они взрослые. Предохранялись. Все по согласию. Оба довольны. Отношения не стали хуже. Никто не узнал. Но внутри нас что-то вопиет: это же, черт возьми, инцест!
Стремясь аргументировать свое осуждение, участники опроса нередко «изобретают жертву»: уверяют, что пострадавшие все-таки есть — скажем, сами герои историй. Если указать, что это противоречит условиям задачи, респондент обычно не сдается: «Я не могу объяснить, почему это плохо, но это плохо».
(Спойлер: потому что «моральные рецепторы» мозга не ограничиваются оценкой нанесенного вреда. Хайдт выделил еще пять критериев: справедливость, верность, свобода, авторитет и сакральная чистота. Если трахнуть куриную тушку, никто не пострадает, но будет нарушена «чистота» мироустройства.)
Слон идет, погонщик объясняет
Итак, моральные суждения мы выносим интуитивно, а рационализируем задним числом.
Человеческий мозг напоминает слона, на спине у которого сидит погонщик, сравнивает Хайдт. Погонщик — наш разум, а слон — остальные 99% ментальных процессов. Парадокс в том, что погонщик служит слону, а не слон погонщику.
В вопросах морали слон выбирает, куда ехать. А погонщик постфактум объясняет, почему «нам туда и надо».
Скучный секс-блог
По книге Джонатана Хайдта The Righteous Mind
Человеческая мораль не рациональна, а интуитивна. Наш мозг выносит моральные оценки мгновенно, и лишь затем разум подбирает аргументы под готовый ответ, пишет исследователь Джонатан Хайдт в книге «Праведный ум».
История про курицу
Чтобы понаблюдать, как люди решают, что хорошо и что плохо, ученый предлагал им специально сочиненные шокирующие истории. Например:
Некий мужчина раз в неделю идет в супермаркет и покупает курицу. Но прежде чем ее приготовить, он совершает с курицей половой акт. Потом готовит и съедает ее.
Что вы об этом думаете? Плохо ли поступает мужчина?
Если плохо, то почему? Ведь никто не пострадал. Никто этого даже не видел.
Тем не менее, большинство скажет: так нельзя! А почему нельзя?
Студенты из продвинутого американского университета довольно быстро придумывают аргументы против секса с цыпленком. Или наоборот признают: «Ладно, он извращенец, но это его право». А вот люди попроще затрудняются с аргументами, но не отступают: «Вы что, сами не понимаете, что так с курицей не делают?!»
История про брата с сестрой
Джули и Марк, брат и сестра, вместе путешествуют по Франции. Оба — студенты колледжа на каникулах. Однажды вечером они остановились в домике возле пляжа. И решили, что было бы интересно и приятно попробовать заняться любовью... Джули принимает противозачаточные таблетки, но Марк также использует презерватив для безопасности. Обоим понравилось, но они решили больше этого не повторять. Эта ночь осталась их личным секретом и сделала их ближе.
Что вы об этом думаете? Правильно ли они поступили?
Специально оговорено, что никому не причинен вред. Они взрослые. Предохранялись. Все по согласию. Оба довольны. Отношения не стали хуже. Никто не узнал. Но внутри нас что-то вопиет: это же, черт возьми, инцест!
Стремясь аргументировать свое осуждение, участники опроса нередко «изобретают жертву»: уверяют, что пострадавшие все-таки есть — скажем, сами герои историй. Если указать, что это противоречит условиям задачи, респондент обычно не сдается: «Я не могу объяснить, почему это плохо, но это плохо».
(Спойлер: потому что «моральные рецепторы» мозга не ограничиваются оценкой нанесенного вреда. Хайдт выделил еще пять критериев: справедливость, верность, свобода, авторитет и сакральная чистота. Если трахнуть куриную тушку, никто не пострадает, но будет нарушена «чистота» мироустройства.)
Слон идет, погонщик объясняет
Итак, моральные суждения мы выносим интуитивно, а рационализируем задним числом.
Человеческий мозг напоминает слона, на спине у которого сидит погонщик, сравнивает Хайдт. Погонщик — наш разум, а слон — остальные 99% ментальных процессов. Парадокс в том, что погонщик служит слону, а не слон погонщику.
В вопросах морали слон выбирает, куда ехать. А погонщик постфактум объясняет, почему «нам туда и надо».
Скучный секс-блог
👍10💩4🔥2👎1🤔1🤮1🤡1
> номинация "Лучший анонимный канал"
> требует личных данных для оформления заявки
https://mimp.mosreg.ru/pixel
🤡
> требует личных данных для оформления заявки
https://mimp.mosreg.ru/pixel
🤡
🤡21🌚3😁2
#prog #article
Fast Enough VMs in Fast Enough Time
Старая (2012 года) статья про применение RPython (языка реализации PyPy) к реализации VM для ЯП с семантикой слишком необычной, чтобы для него подходили существующие VM.
Чем привлекает RPython? Обещанием: напиши интепретатор для своего ЯП и получили JIT-компилятор бесплатно. Как это работает?
Во-первых, RPython, как можно догадаться по названию — подмножество Python, ограниченное достаточно, чтобы быть статически типизированным (с выводом типов btw) и потому гораздо более подходящим для статического анализа. Также RPython можно компилировать в C для получения бесплатного ускорения от существующих компиляторов.
Во-вторых, JIT-компиляция применяется не напрямую: ускорение происходит за счёт JIT-компиляции самого интепретатора, исполняющего RPython-код. Именно, специальные аннотации в исходном коде говорят интерпретатору RPython, какой регион кода нуждается в компиляции. Когда кусок кода исполняется достаточно много раз, он запускается не через скомпилированный через C машинный код, а через специальный трассирующий интепретатор. Он записывает операции, которые реально исполняются во время выполнения итерации. Полученный список операций (в байт-коде) за счёт трассировки является полностью линейным. Этот список затем подвергается оптимизациям, применимым за счёт статического анализа. Так как байт-код достаточно высокоуровневый, оптимизации могут, например, убирать лишние обращения к словарю, а также пары операций list_push и list_pop. Этот оптимизированный список операций затем компилируется через C в машинный код, и последующие вызовы используют уже его вместо интепретации байт-кода.
Разумеется, эти оптимизации корректны только для конкретной итерации оптимизируемого кода и потому зависимы от конкретных значений переменных и об конкретных выборов ветвления потока управления (а ещё от их конкретных типов). Поэтому трассировка включает в себя особые ассерты, которые это проверяют. В случае провала проверки они возвращают управление обратно интепретатору. С другой стороны, статический анализ трассировки может удостовериться, что некоторые из этих ассертов никогда не выстреливают и потому их можно безопасно убрать.
Автор рассматривает эффект от переписывания старой VM для своего ЯП (ранее написанной на C) на RPython. Замеры показывают, что новая реализация заметно обгоняет старую, и за счёт большей высокоуровневости языка в новую реализацию проще вносить изменения, ускоряющие её ещё больше.
Разумеется, RPython не всесилен. По понятным причинам, если ветвления в коде выбираются слишком непредсказуемо (как в бинарном поиске, например), ускорения реально не происходит, поскольку исполнение слишком часто рано переходит из нативного кода обратно в интепретатор. Как из этого следует, один и тот же код, эквивалентный семантически, может очень по разному проявлять себя под JIT. Также оптимизация байт-кода занимает время, и потому RPython прерывает трассировку, если трейс становится слишком длинным. С другой стороны, RPython позволил серьёзно (на пару порядков в некоторых бенчмарков) ускорить VM по сравнению со старой реализацией, и при этом потребовал весьма небольших вложений времени.
Fast Enough VMs in Fast Enough Time
Старая (2012 года) статья про применение RPython (языка реализации PyPy) к реализации VM для ЯП с семантикой слишком необычной, чтобы для него подходили существующие VM.
Чем привлекает RPython? Обещанием: напиши интепретатор для своего ЯП и получили JIT-компилятор бесплатно. Как это работает?
Во-первых, RPython, как можно догадаться по названию — подмножество Python, ограниченное достаточно, чтобы быть статически типизированным (с выводом типов btw) и потому гораздо более подходящим для статического анализа. Также RPython можно компилировать в C для получения бесплатного ускорения от существующих компиляторов.
Во-вторых, JIT-компиляция применяется не напрямую: ускорение происходит за счёт JIT-компиляции самого интепретатора, исполняющего RPython-код. Именно, специальные аннотации в исходном коде говорят интерпретатору RPython, какой регион кода нуждается в компиляции. Когда кусок кода исполняется достаточно много раз, он запускается не через скомпилированный через C машинный код, а через специальный трассирующий интепретатор. Он записывает операции, которые реально исполняются во время выполнения итерации. Полученный список операций (в байт-коде) за счёт трассировки является полностью линейным. Этот список затем подвергается оптимизациям, применимым за счёт статического анализа. Так как байт-код достаточно высокоуровневый, оптимизации могут, например, убирать лишние обращения к словарю, а также пары операций list_push и list_pop. Этот оптимизированный список операций затем компилируется через C в машинный код, и последующие вызовы используют уже его вместо интепретации байт-кода.
Разумеется, эти оптимизации корректны только для конкретной итерации оптимизируемого кода и потому зависимы от конкретных значений переменных и об конкретных выборов ветвления потока управления (а ещё от их конкретных типов). Поэтому трассировка включает в себя особые ассерты, которые это проверяют. В случае провала проверки они возвращают управление обратно интепретатору. С другой стороны, статический анализ трассировки может удостовериться, что некоторые из этих ассертов никогда не выстреливают и потому их можно безопасно убрать.
Автор рассматривает эффект от переписывания старой VM для своего ЯП (ранее написанной на C) на RPython. Замеры показывают, что новая реализация заметно обгоняет старую, и за счёт большей высокоуровневости языка в новую реализацию проще вносить изменения, ускоряющие её ещё больше.
Разумеется, RPython не всесилен. По понятным причинам, если ветвления в коде выбираются слишком непредсказуемо (как в бинарном поиске, например), ускорения реально не происходит, поскольку исполнение слишком часто рано переходит из нативного кода обратно в интепретатор. Как из этого следует, один и тот же код, эквивалентный семантически, может очень по разному проявлять себя под JIT. Также оптимизация байт-кода занимает время, и потому RPython прерывает трассировку, если трейс становится слишком длинным. С другой стороны, RPython позволил серьёзно (на пару порядков в некоторых бенчмарков) ускорить VM по сравнению со старой реализацией, и при этом потребовал весьма небольших вложений времени.
👍10🤔1
Блог*
#prog #article Fast Enough VMs in Fast Enough Time Старая (2012 года) статья про применение RPython (языка реализации PyPy) к реализации VM для ЯП с семантикой слишком необычной, чтобы для него подходили существующие VM. Чем привлекает RPython? Обещанием:…
#prog #python #article
И ещё серия старых (2012 год) статей от разработчика PyPy о том, как можно написать код таким образом, чтобы получить наибольшее преимущество от трассирующего JIT:
Controlling the Tracing of an Interpreter With Hints, Part 1: Controlling the Extent of Tracing
Controlling the Tracing of an Interpreter With Hints, Part 2: Controlling Optimization
Controlling the Tracing of an Interpreter With Hints, Part 3: Putting it All Together — про то, как организовать структуру представления объектов так, чтобы получить выгоду от JIT (ибо наивный подход со словарями методов толком не ускорить)
И ещё серия старых (2012 год) статей от разработчика PyPy о том, как можно написать код таким образом, чтобы получить наибольшее преимущество от трассирующего JIT:
Controlling the Tracing of an Interpreter With Hints, Part 1: Controlling the Extent of Tracing
Controlling the Tracing of an Interpreter With Hints, Part 2: Controlling Optimization
Controlling the Tracing of an Interpreter With Hints, Part 3: Putting it All Together — про то, как организовать структуру представления объектов так, чтобы получить выгоду от JIT (ибо наивный подход со словарями методов толком не ускорить)
Blogspot
Controlling the Tracing of an Interpreter With Hints, Part 1: Controlling the Extent of Tracing
The question I was asked most often during my recent US trip was how exactly the hints work that interpreter authors can use to improve the...
🔥3👍2