Forwarded from Ряды Фурье
Наконец-то снова серьёзная тема! Давайте поговорим про прекрасную ягодицу. Даже обе!
Есть две фундаментальные научные работы, которые определяют красоту попы.
Первая (doi:10.1097/prs.0000000000002192) появилась по той причине, что пластическим хирургам нужен был какой-то ориентир. А то наращивали как пойдёт, без системы, и получался некий разнобой. После исследования появился чёткий стандарт для хирургической коррекции. Так что вот эти вот "люблю женщин потолще" и "отрежьте удаву задницу по самое лицо" пропали. Появился эталон.
Основные результаты:
— Наиболее привлекательное соотношение талии к бедрам при виде сзади — 0,65 (44% респондентов), затем 0,6 (25% респондентов). Это мы отметили стрелочкой на фото выше среди ассортимента.
— При виде сбоку наиболее привлекательное соотношение талии к бедрам — 0,7.
— Наиболее привлекательное расположение латерального выступа ягодиц — в нижней части (26% предпочли нижнюю выпуклость, 23% — расположение на нижних 70% высоты ягодиц).
— При виде сбоку наиболее привлекательно расположение самой выступающей точки на середине высоты ягодиц (50:50).
— Не было выявлено значительных различий в предпочтениях между возрастными группами.
— Мужчины и женщины имели одинаковые предпочтения.
— Не обнаружено явных различий между этническими группами.
Из этого есть 3 прекрасных следствия:
— Любая достаточно выпуклая задница может быть красивой при правильном ракурсе.
— За последние годы предпочтения сместились в сторону несколько большей попы по сравнению с предыдущими стандартами (было соотношение 0,7).
— Хирургам рекомендовали стремиться к соотношению талии к бедрам 0,60 — 0,65 при виде сзади, сохранять соотношение около 0,70 при виде сбоку, увеличивать объем преимущественно в латеральных и периферических областях ягодиц.
Недостаток этой работы в том, что культурный код большинства исследуемых американский, то есть этнические группы разные, но почти все набраны в США.
Вторая важнейшая научная работа про то, что визуально ягодица представлена тремя вещами:
— Мышцами, которые можно накачать в зале
— Жиром, который можно наесть
— И углом крепления к позвоночнику, то есть грамотным изгибом.
И вот угол сильно недооценён!
Когда выяснилось, что в формировании красоты самое главное — половой отбор, решили проверить, не даёт ли оптимальный для родов угол крепления ягодиц к остальному человеку преимущества. И, внезапно, даёт и ещё как!
— Оптимальный угол изгиба поясницы у женщин (около 45,5°) сформировался в ходе эволюции как компромисс между недостаточным и чрезмерным изгибом. Оба эти крайних состояния связаны с проблемами во время беременности и родов.
— Привлекательность женщин для мужчин достигала пика при угле, близком к теоретически оптимальному (45,5°).
— Дальше попытались выяснить, что именно привлекает мужчин — сам по себе изгиб поясницы или объем ягодиц, который тоже влияет на визуальное восприятие изгиба.
— Мужчины предпочитают женщин, у которых изгиб поясницы обусловлен именно клиновидностью позвонков, а не объемом ягодиц.
— При углах выше оптимального картина была сложнее, что авторы объясняют влиянием других факторов (например, соотношения талии и бедер).
Таким образом, всё ещё круче: если в дополнение к ракурсу выбрать ещё и правильную позу, любой человек в теории может достичь максимума привлекательности этой частью тела. Так что продолжайте искать фотографа, способного прочитать научную работу.
Есть такое же исследование про мужские ягодицы, но оно ужасно грустное, его мы рассматривать не будем.
Лучше посмотрите ещё обучающие материалы. Часть не из научных работ, а просто для лучшего закрепления темы. В конце концов, рассматривая эти картинки, вы вообще-то заняты чтением научной документации!
Вот тут прошлый пост про другие аспекты красоты.
--
Вступайте в ряды Фурье! Частые колебания!
Есть две фундаментальные научные работы, которые определяют красоту попы.
Первая (doi:10.1097/prs.0000000000002192) появилась по той причине, что пластическим хирургам нужен был какой-то ориентир. А то наращивали как пойдёт, без системы, и получался некий разнобой. После исследования появился чёткий стандарт для хирургической коррекции. Так что вот эти вот "люблю женщин потолще" и "отрежьте удаву задницу по самое лицо" пропали. Появился эталон.
Основные результаты:
— Наиболее привлекательное соотношение талии к бедрам при виде сзади — 0,65 (44% респондентов), затем 0,6 (25% респондентов). Это мы отметили стрелочкой на фото выше среди ассортимента.
— При виде сбоку наиболее привлекательное соотношение талии к бедрам — 0,7.
— Наиболее привлекательное расположение латерального выступа ягодиц — в нижней части (26% предпочли нижнюю выпуклость, 23% — расположение на нижних 70% высоты ягодиц).
— При виде сбоку наиболее привлекательно расположение самой выступающей точки на середине высоты ягодиц (50:50).
— Не было выявлено значительных различий в предпочтениях между возрастными группами.
— Мужчины и женщины имели одинаковые предпочтения.
— Не обнаружено явных различий между этническими группами.
Из этого есть 3 прекрасных следствия:
— Любая достаточно выпуклая задница может быть красивой при правильном ракурсе.
— За последние годы предпочтения сместились в сторону несколько большей попы по сравнению с предыдущими стандартами (было соотношение 0,7).
— Хирургам рекомендовали стремиться к соотношению талии к бедрам 0,60 — 0,65 при виде сзади, сохранять соотношение около 0,70 при виде сбоку, увеличивать объем преимущественно в латеральных и периферических областях ягодиц.
Недостаток этой работы в том, что культурный код большинства исследуемых американский, то есть этнические группы разные, но почти все набраны в США.
Вторая важнейшая научная работа про то, что визуально ягодица представлена тремя вещами:
— Мышцами, которые можно накачать в зале
— Жиром, который можно наесть
— И углом крепления к позвоночнику, то есть грамотным изгибом.
И вот угол сильно недооценён!
Когда выяснилось, что в формировании красоты самое главное — половой отбор, решили проверить, не даёт ли оптимальный для родов угол крепления ягодиц к остальному человеку преимущества. И, внезапно, даёт и ещё как!
— Оптимальный угол изгиба поясницы у женщин (около 45,5°) сформировался в ходе эволюции как компромисс между недостаточным и чрезмерным изгибом. Оба эти крайних состояния связаны с проблемами во время беременности и родов.
— Привлекательность женщин для мужчин достигала пика при угле, близком к теоретически оптимальному (45,5°).
— Дальше попытались выяснить, что именно привлекает мужчин — сам по себе изгиб поясницы или объем ягодиц, который тоже влияет на визуальное восприятие изгиба.
— Мужчины предпочитают женщин, у которых изгиб поясницы обусловлен именно клиновидностью позвонков, а не объемом ягодиц.
— При углах выше оптимального картина была сложнее, что авторы объясняют влиянием других факторов (например, соотношения талии и бедер).
Таким образом, всё ещё круче: если в дополнение к ракурсу выбрать ещё и правильную позу, любой человек в теории может достичь максимума привлекательности этой частью тела. Так что продолжайте искать фотографа, способного прочитать научную работу.
Есть такое же исследование про мужские ягодицы, но оно ужасно грустное, его мы рассматривать не будем.
Лучше посмотрите ещё обучающие материалы. Часть не из научных работ, а просто для лучшего закрепления темы. В конце концов, рассматривая эти картинки, вы вообще-то заняты чтением научной документации!
Вот тут прошлый пост про другие аспекты красоты.
--
Вступайте в ряды Фурье! Частые колебания!
Будни #bootstrap
Обновился #dbus, со сменой сборки с autohell на #meson.
Обновился и обновился, но вот в dbus.pc теперь есть вот такое:
Тут важно обратить внимание набыло лучше его не было.
Все бы ничего, но теперь сборки проектов с meson, которые зависят от dbus, падают вот так вот:
Да, meson вызвал pkg-config, получил хрень в виде
Как я это починил?
Как обычно: 7 бед - 3 раза sed:
https://github.com/pg83/ix/blob/main/pkgs/lib/dbus/ix.sh#L5-L8
Морали не будет 😐
Обновился #dbus, со сменой сборки с autohell на #meson.
Обновился и обновился, но вот в dbus.pc теперь есть вот такое:
Name: dbus
Description: Free desktop message bus
Version: 1.16.0
Libs: -L${libdir} -ldbus-1 -pthread
Cflags: -I${includedir}/dbus-1.0 \
-pthread \
-I${libdir}/dbus-1.0/include
Тут важно обратить внимание на
-pthread
, раньше Все бы ничего, но теперь сборки проектов с meson, которые зависят от dbus, падают вот так вот:
In file included from <built-in>:413:
<command line>:7:9: error: \
macro name must be an identifier
7 | #define -pthread 1
Да, meson вызвал pkg-config, получил хрень в виде
-pthread
, и сделал из нее -D-pthread=1
.Как я это починил?
Как обычно: 7 бед - 3 раза sed:
https://github.com/pg83/ix/blob/main/pkgs/lib/dbus/ix.sh#L5-L8
Морали не будет 😐
GitHub
ix/pkgs/lib/dbus/ix.sh at main · pg83/ix
ix package manager. Contribute to pg83/ix development by creating an account on GitHub.
commit -m "better"
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Loser story
В ydb используется google tcmalloc, well, он примерно двухлетней давности.
Недавно один коллега обратил на это внимание, попробовал обновить и посмотреть на разных бенчмарках, что получится.
Memory usage упал в tcp-c упал аж на 15%, но латенси стало похуже.
Меня заинтересовало, что метрика того сколько занимают tcmalloc кеши изменилась довольно значительно, не только по размеру (как раз те 15%) но и по форме (став меняться динамически).
Я довольно давно не следил за tcmalloc репой (примерно с тех времён как они рассказывали как сделали большие аллокации huge page aware, 21~ год).
Ну и думал придется покопаться в их коммитах чтобы найти что такого в кешах они поменяли.
Но в процессе поиска наткнулся на то что недавно, они написали статью как меняли tcmalloc на скейле гугла последние два года.
https://zzhou612.com/publication/2024-asplos-malloc/2024-asplos-malloc.pdf
Статья прям приятно читается, хотя как следствие и не содержит каких-то подробных технических деталей.
Но если приводить TLDR, то
1) Взяли больших потребителей внутри гугла (spanner, f1, bigtable, etc) и пару внешних отличающихся workload-ов (redis, tensor flow, etc)
2) Начали все это активно и по разному мерять (a/b тесты, continues profiling, etc)
3) На каждом уровне кеширования нашли определеные проблемы
4) Получили средний профит на своих ворклоадах уровне: 3.5% по памяти, 1.5% по пропускной способности
5) Ещё интересно что как и с большинством идей из tcmalloc многие из этих можно переиспользовать в других аллокаторах
Ещё наверное интересно, что это показывает в какой-то степени насколько general-purpose аллокаторы (jemalloc, tcmalloc-и, может быть mimalloc) сложно сделать лучше чем сейчас.
Не потому что нельзя под конкретный ворклоад написать аллокатор быстрее в 2 раза, а потому что это замедлит другие юзкейсы.
Резюмируя кажется то что я искал, они называют "Heterogeneous per-CPU cache"
собственно включение которого у нас нет https://github.com/google/tcmalloc/commit/2407bb02b75ba00fd066bd5730a42cd319c303b0
сам код
https://github.com/google/tcmalloc/commit/691f9f62affb27764db8ca26f27159172c439001
Недавно один коллега обратил на это внимание, попробовал обновить и посмотреть на разных бенчмарках, что получится.
Memory usage упал в tcp-c упал аж на 15%, но латенси стало похуже.
Меня заинтересовало, что метрика того сколько занимают tcmalloc кеши изменилась довольно значительно, не только по размеру (как раз те 15%) но и по форме (став меняться динамически).
Я довольно давно не следил за tcmalloc репой (примерно с тех времён как они рассказывали как сделали большие аллокации huge page aware, 21~ год).
Ну и думал придется покопаться в их коммитах чтобы найти что такого в кешах они поменяли.
Но в процессе поиска наткнулся на то что недавно, они написали статью как меняли tcmalloc на скейле гугла последние два года.
https://zzhou612.com/publication/2024-asplos-malloc/2024-asplos-malloc.pdf
Статья прям приятно читается, хотя как следствие и не содержит каких-то подробных технических деталей.
Но если приводить TLDR, то
1) Взяли больших потребителей внутри гугла (spanner, f1, bigtable, etc) и пару внешних отличающихся workload-ов (redis, tensor flow, etc)
2) Начали все это активно и по разному мерять (a/b тесты, continues profiling, etc)
3) На каждом уровне кеширования нашли определеные проблемы
4) Получили средний профит на своих ворклоадах уровне: 3.5% по памяти, 1.5% по пропускной способности
5) Ещё интересно что как и с большинством идей из tcmalloc многие из этих можно переиспользовать в других аллокаторах
Ещё наверное интересно, что это показывает в какой-то степени насколько general-purpose аллокаторы (jemalloc, tcmalloc-и, может быть mimalloc) сложно сделать лучше чем сейчас.
Не потому что нельзя под конкретный ворклоад написать аллокатор быстрее в 2 раза, а потому что это замедлит другие юзкейсы.
Резюмируя кажется то что я искал, они называют "Heterogeneous per-CPU cache"
собственно включение которого у нас нет https://github.com/google/tcmalloc/commit/2407bb02b75ba00fd066bd5730a42cd319c303b0
сам код
https://github.com/google/tcmalloc/commit/691f9f62affb27764db8ca26f27159172c439001
Forwarded from Ньюсач/Двач
Please open Telegram to view this post
VIEW IN TELEGRAM
commit -m "better"
Даже Путину можно про порно, а те, кто наставил каках в https://www.tgoop.com/itpgchannel/2510 - ханжи и снобы!
https://www.opennet.ru/opennews/art.shtml?num=62441
29 новых уязвимостей в #gstreamer.
Текст про описание подхода - https://github.blog/security/vulnerability-research/uncovering-gstreamer-secrets/
TL;DR - был использован fuzzer, отдельный интерес представляет то, как коллега строил корпус для фаззинга.
Полагаю, что это только начало, потому что он нашел ошибки только в тех контейнерах, которые он явно таргетировал, а таргетировал он далеко не все, что бывает (mkv/mp4).
29 новых уязвимостей в #gstreamer.
Текст про описание подхода - https://github.blog/security/vulnerability-research/uncovering-gstreamer-secrets/
TL;DR - был использован fuzzer, отдельный интерес представляет то, как коллега строил корпус для фаззинга.
Полагаю, что это только начало, потому что он нашел ошибки только в тех контейнерах, которые он явно таргетировал, а таргетировал он далеко не все, что бывает (mkv/mp4).
www.opennet.ru
В мультимедийном фреймворке GStreamer выявлено 29 уязвимостей
В мультимедийном фреймворке GStreamer, используемом в GNOME, выявлено 29 уязвимостей. Восемь уязвимостей приводят к записи данных за пределы буфера, а одна (CVE-2024-47540) к перезаписи указателя на функцию. Указанные уязвимости могут потенциально использоваться…