meduniver.com/Medical/gistologia/892.html
Там есть источники. Если в случае с урановой рудой нет ни одного научного факта вреда, и люди в урановых шахтах без особого ущерба здоровью там работали, и основную опасность в урановых шахтах представляет мелкая пыль, как в любой другой шахте, вызывая силикоз. Говорят Курчатов спокойно трогал урановую руду и даже не протирал после рук платком. Радон в небольших дозах полезен и используется в лечении, в урановых шахтах полно радона, к концу 80-х исследованиями были развеяны мифы о вреде радона и урановых шахт. С радием-226 не все так однозначно. У меня к примеру дядя сразу после армии где был летчиком облысел. В авиа приборах раньше использовали радий-226. Ну и если не согласны, проведите эксперимент на себе, расскажите через лет 20 страшилки это или нет…
dlinyj светомасса постоянного действия. Где-то до 70-80 годов ее использовали во многих приборах. Она радиоактивная на основе радия-226, со временем высыхает и сыпаться начинает, опасно вдыхание ее и если проглотить ее частички, плюс выделяет она радон-222. radiation.domachevo.com/spd-radium.htm
Наверное самый частый и сильный убийца среди доступных источников радиации. Убивает или колечит здоровье медленно, но верно…
Тоже насчет СПД подумал. Притом не только у компаса, а еще у прибора сверху который 1500 стоит и который с двумя стрелками V и A и непонятной сетчатой конструкцией на крышке. На барахолках СПД не редкость… А вот выше его фото dlinyj выложил.
Спасибо, за статью. Любители радиации урановое стекло ищут на блошках, и бывает за копейки его отдают продавцы. Фанаты ручной заточки ищут старые натуральные заточные камни типа бритвенного J.G. ESCHER(бывает у людей дед с войны как трофей привез и у кого-то лежал на даче или в деревне), Belgian Blue Whetstone, советские высококачественные байкалиты, арканзасы, вашиты и т.д… Но скорее всего в Москве на блошках большая часть продавцов уже прошаренные и цены завышают на этот товар, и есть не мало охотников на лакомые позиции. Но все равно выгоднее купить чем в интернете на вторичке.
Спасибо КЭП за разъяснение! У меня такое чувство, что люди совсем не читали статью и комментарии, сами себе чето-то надумали сами же на свой вопрос ответили…
yield() или sleep() это совсем другой случай, про это мной нигде не было написано. Поток даже может не вызвать yield() или sleep(). Ваши знания как раз видимо и spin loop ограничены…
И вы упустили самый главный момент, что yield() или sleep() займет суммарно значительно больше тактов процессора чем при SMT и HT.
Специально нигде сильно не углублялся, чтобы не усложнять теорию, просто описал основные принципы работы. А если углубиться в тему, то там еще вылезет кучу специфичных вещей для ОС и конкретной версии ядра… Если бы вы внимательно читали статью, то поняли бы, что речь не совсем про планировщик, а про Core Scheduling… Условно вы предлагаете в автошколе учить водителей, тому на какие контакты приходит сигнал зажигания, какая микросхема как работает, как паять контакты, что где-то там должен быть цифровой сигнал определенной формы и тогда автомобиль заведется. Когда можно просто дать ключи, объяснить, как завести, проверить уровень бензина в баке и все. Зачем водителю знать, как устроен двигатель внутреннего сгорания на инженерном уровне? Если ему достаточно знать, что есть бензин, свеча, свеча воспламеняет бензин и толкает поршень.
Мы не будем углубляться в эту тему слишком глубоко, так как это тема отдельной статьи. Но вы всегда можете найти комментарии и пояснения к коду, в файле: include/linux/sched.h, и изучить эту тему самостоятельно. Умение читать исходные коды ядра, является очень важным навыком для каждого разработчика, который хочет углубиться в программирование ядра Linux. Часть полезной информации также можно найти в официальной документации ядра Linux — Scheduler, но всё же лучше смотреть исходные коды ядра.
у меня не было цели максимально достоверно донести, как работает вытесняющая многозадачность, если углубляться в тему там еще много нюансов. Это тема отдельной статьи. Наоборот цель была передать человеку незнакомому с устройством ОС максимально просто смысл происходящего в ядре ОС. Моя задача не писать сложным языком о сложных вещах, моя задача уменьшить разрыв в знаниях у специалистов и показать, что в реальности все очень просто.
Нет. Например, если происходит кэш-промах при обращении к данным, то процессору приходится обращаться к памяти, а это — достаточно долгая операция (сотни тактов), за время выполнения которой все выбранные с опережением независимые от инструкции, обращающейся к памяти, инструкции успевают исполниться и исполнительные устройства процессора в результате простаивают. Планировщик ОС при этом не получает никакого уведомления: все это происходит для него прозрачно (да и не сможет он на это эффективно среагировать).
А вот наличие второго потока выполнения для другого логического процессора в физическом процессоре с поддержкой HT позволяет в данном примере загрузить эти простаивающие исполнительные устройства физического процессора (если, конечно, этому потоку тоже не понадобится вскоре обратиться в память за содержимым, которое остутствует в кэше).
Строго говоря, HT сама по себе в переключении потоков операционной системы в планировщике не участвует. Она просто представляет планировщику ОС физический процессор как два логических процессора, на каждый из которых ОС назначет по одному потоку выполнения. Огрубленно ( если не обращать внимание на детали, что современные ОС знают о логических процессорах и принимают меры, чтобы не снизить производительность их неправильным использованием), ОС работает с логическим процессом HT так же как с физическим ядром.
Мною про это было написано. Вы сами же что-то надумали, и сами же ответили себе…
WASD1 спасибо за ваше гениальное разъяснение претендующее на нобелевскую премию. Процессор не работает в категориях миллисекунд, он работает в категории тактов и инструкций процессора. Вы еще пытаетесь переложить ситуацию со 100% загрузкой процессора, на задачи, когда один поток уснул и работает другой поток. При 100% загрузке нет никакого преимущества и RT задачах тоже. И вы читали статью не внимательно, мною было сделано замечание на эту тему в статье. Читайте на здоровье www.cs.unc.edu/~anderson/papers/ecrts19d.pdf
Характер многозадачности (кооперативная или вытесняющая) и политика планировщика (простая очередь — FIFO, приоритетная очередь или ещё как) — это две независмые характеристики.
Да так и есть.
К примеру, в классической системе с кооперативной многозадачностью — MS Windows 3.х — была функция DirectedYield, позволявшая передать управление из текущей задачи указанной задаче.
Хоть у меня была 3.11 не знаю, что там было.
HT был введен с целью наиболее полно задействовать все функциональные блоки ядра, которые там есть самые разные — обычные вычисления, вычисления с плавоющей точкой и т.д.
Они без этого все задействованы. Так что тут вы не правы. Как раз дело в шедулере, что переключения через OC затрагивают суммарно больше времени и процессорных тактов.
А потому, для таких систем (например, серверов MS Exchange) включать HT не рекомендуется — выигрыш от задействия разных функциональных блоков не оправдывает потерь на диспетчеризацию для дополнительных ядер.
Это уже особенность Windows c его более микроядерной архитектурой. В Linux же используется монолитное ядро.
WASD1 ссылок нет, вполне логичная интерпретация. Выше уже был дан ответ, почему накладные расходы на переключение выше при использовании средств ОС. И в статье есть картинка иллюстрирующая это, похожие картинки есть в интернете по запросам Hyper-Threading, Intel HT, Simultaneous Multithreading, AMD SMT. Можно добавить еще, что в случае вытесняющей многозадачностью с таймером происходит прерывание, а все прерывания, как нас раньше учили самые дорогие операции для процессора. А в случае кооперативной многозадачности, мы можем не дождаться, что поток нам даст управление т.к. он должен делать это вручную, и при этом может простаивать. В случае с HT и SMT работает простой принцип если конвеер процессора простаивает происходит автоматические переключение на симметричный поток. Для понимания его принципа работы 99% людей этого более чем достаточно. Это все есть на картинке, где показан принцип работы. Могу предположить, что еще предсказание переходов лучше работает при HT и SMT, и отсюда тоже чуть лучше будет производительность. Если человек не занимается слишком низкоуровневым программирование, и низкоуровневой оптимизацией кода или производством процессоров, глубже нет смысла углубляться.
LynXzp у меня не было цели максимально достоверно донести, как работает вытесняющая многозадачность, если углубляться в тему там еще много нюансов. Это тема отдельной статьи. Наоборот цель была передать человеку незнакомому с устройством ОС максимально просто смысл происходящего в ядре ОС. Моя задача не писать сложным языком о сложных вещах, моя задача уменьшить разрыв в знаниях у специалистов и показать, что в реальности все очень просто.
13werwolf13 может и так. Просто у арча самые удобные для чтения скрипты сборки и нравится как сам дистрибутив устроен, но честно раньше я не ожидал, что там мейнтейнеры р*дяи, и тоже в скриптах сборки много грязи. Я им даже патчи на блюдечке преподносил для нескольких пакетов, чтобы они взяли и обновили зависимые пакеты. Все дистрибутивы это сделали, а они там что-то телятся, и многие совсем не умеют читать баги в астриме и писать патчи. Лично перерабатываю каждый скрипт сборки, смотрю багрепорты, оптимизирую код сборки, удаляю костыли времен царя гороха, где-то добавляю свои самопальные патчи, где могу сам решить проблему. Переход для меня не имеет смысл, уже на пути создании своего дистрибутива. В день просматривают не мало багрепортов и по объему написанных патчей RedHat впереди всех, больше всего багов они закрывают, но скрипты сборки тяжелые у них. Насчет универсальной сборки под arch, redhat, debian это не сложно сделать, все собирается в clean chroot просто разный упаковщик пакетов, главная проблема, что везде по разному именуются зависимости, вот это думаю они не смогли решит, иначе пакет будет сразу в себе все зависимости содержать, чтобы не ломать его работу.
В принципе ничего, просто будут дороже переключения контекста. Если взять вытесняющую многозадачность, то там используется таймер, по которому он запускается, т.е. до запуска таймера будет простой процессора. А в случае с кооперативной многозадачности мы должны ждать пока поток сам передаст управление другому потоку. Процессор же может моментально выполнить два потока, когда один поток простаивает и когда конвейер процессора пуст. Вычислительный конвейер
То есть, первый ответ Apple, в котором они признали проблему после получения видео с демонстрацией, вы не заметили случайно или притворяетесь шлангом в попытках отстоять свое мнение?
Вроде себя за профессионала, как автор статьи выдаете, а даже не понимаете банальных вещей, что скрины легко подделать. Тогда резонный вопрос, где видео демонстрации, которое вы упоминаете?
Кто действительно разбирается, тому вполне достаточно идеи, описанной в статье для объективной оценки подобного вектора атаки.
Правда? В таком случае, такие идеи озвучивались далеко до автора, так же как к примеру sql injection. Это не более чем абстрактный класс атак. Автор статьи ни делал никакого открытия, и не показал реализацию атаку. С таким же успехом можно сделать статью, как вы нашли sql injection на сайте google. И что они вам в переписке отказывают в выплате 1 миллиона долларов. Или вы нашли вместо sql injection, не раскрученную ошибку от sql сервера, но написали разработчикам, что у них там sql injection и у них серьезные проблемы с безопасностью. Вы разницу не понимаете?
Для того, чтобы оценить вкус молока, не обязательно быть коровой, которая его производит.
Вы сами поняли, что написали? С каких пор у вас сказочные фантазии, что коровы оценивают вкус молока? Такие же фантазии, что автору плюнули в лицо и не оценили его работу?
Какого уровня? Из статьи даже не понятно были ли уязвимость на самом деле, и куча воды с размышлениями в сферическом вакууме. За такие уязвимости никогда не платили. Судя по статье, из Apple ему готовы были заплатить довольно приличную сумму за то, что даже уязвимостью нельзя назвать. И не была проведена успешная атака, и еще главное у человека совсем туго с комбинаторикой. Статья просто хайповая, не более того… И кто действительно разбирается, понимает, что статья это полная вода, и сложность атаки значительно сложнее чем написана в статье и за такую «уязвимость» $18000 это переплата с лихвой. Такую уязвимость ни одна уважающая себя security компания не купит. Сколько уязвимостей вы нашли сами и продали, чтобы рассуждать, что заплатили мало и это плевок в лицо?
ЧСВ у автора в статье просто зашкаливает. Так и не была показана успешная реализация атаки, куча теоретических рассуждений в сферическом вакууме, и много текста о том какой автор молодец… В конце убило, что автор отказался от вознаграждения в $18000, ведь он такой молодец и достоин минимум награды в $100000, а лучше в $250000. Не говоря про то, что много воды.
"Радикальный — DPI: влезать в каждый пакет, анализировать шаблоны трафика, выявлять протоколы по статистическому анализу пакетов."
Увы, но уже с этим встречались в прошлом. В 2010 году когда работал в одной крупной компании, нас интернет провайдер уведомил об одностороннем изменении договора и VPN сеть объединяющая несколько офисов в один момент резко перестала работать. Т.е. об изменении условий договора мы узнали уже постфактум. Суть изменений была такова, что если раньше мы им платили круглую сумму, то теперь за использование VPN через их каналы связи, мы должны им платить круглую сумму умноженную на 3, и они режут теперь всем VPN трафик. Стоить заметить, что не через выделенный VLAN, а именно через сеть Internet. Переговоры не привели к успеху, поэтому послали их в дремучий лес и сменили провайдера.
В середине 2000-х с уходом эры dual-up, многие провайдеры ради экономии трафика и увеличения прибыли любили заворачивать весь http трафик на свой тормозной кэширующий прокси сервер. Благо с https это так просто не прокатит, но никто не защищен, что кому-то в руководстве взбредет в голову запретить весь https и vpn трафик ради "общей безопасности"...
Там есть источники. Если в случае с урановой рудой нет ни одного научного факта вреда, и люди в урановых шахтах без особого ущерба здоровью там работали, и основную опасность в урановых шахтах представляет мелкая пыль, как в любой другой шахте, вызывая силикоз. Говорят Курчатов спокойно трогал урановую руду и даже не протирал после рук платком. Радон в небольших дозах полезен и используется в лечении, в урановых шахтах полно радона, к концу 80-х исследованиями были развеяны мифы о вреде радона и урановых шахт. С радием-226 не все так однозначно. У меня к примеру дядя сразу после армии где был летчиком облысел. В авиа приборах раньше использовали радий-226. Ну и если не согласны, проведите эксперимент на себе, расскажите через лет 20 страшилки это или нет…
Наверное самый частый и сильный убийца среди доступных источников радиации. Убивает или колечит здоровье медленно, но верно…
yield() или sleep() это совсем другой случай, про это мной нигде не было написано. Поток даже может не вызвать yield() или sleep(). Ваши знания как раз видимо и spin loop ограничены…
И вы упустили самый главный момент, что yield() или sleep() займет суммарно значительно больше тактов процессора чем при SMT и HT.
Специально нигде сильно не углублялся, чтобы не усложнять теорию, просто описал основные принципы работы. А если углубиться в тему, то там еще вылезет кучу специфичных вещей для ОС и конкретной версии ядра… Если бы вы внимательно читали статью, то поняли бы, что речь не совсем про планировщик, а про Core Scheduling… Условно вы предлагаете в автошколе учить водителей, тому на какие контакты приходит сигнал зажигания, какая микросхема как работает, как паять контакты, что где-то там должен быть цифровой сигнал определенной формы и тогда автомобиль заведется. Когда можно просто дать ключи, объяснить, как завести, проверить уровень бензина в баке и все. Зачем водителю знать, как устроен двигатель внутреннего сгорания на инженерном уровне? Если ему достаточно знать, что есть бензин, свеча, свеча воспламеняет бензин и толкает поршень.
Мною про это было написано. Вы сами же что-то надумали, и сами же ответили себе…
Да так и есть.
Хоть у меня была 3.11 не знаю, что там было.
Они без этого все задействованы. Так что тут вы не правы. Как раз дело в шедулере, что переключения через OC затрагивают суммарно больше времени и процессорных тактов.
Это уже особенность Windows c его более микроядерной архитектурой. В Linux же используется монолитное ядро.
В принципе ничего, просто будут дороже переключения контекста. Если взять вытесняющую многозадачность, то там используется таймер, по которому он запускается, т.е. до запуска таймера будет простой процессора. А в случае с кооперативной многозадачности мы должны ждать пока поток сам передаст управление другому потоку. Процессор же может моментально выполнить два потока, когда один поток простаивает и когда конвейер процессора пуст. Вычислительный конвейер
@dlinyj Спасибо за отзыв.
Вроде себя за профессионала, как автор статьи выдаете, а даже не понимаете банальных вещей, что скрины легко подделать. Тогда резонный вопрос, где видео демонстрации, которое вы упоминаете?
Правда? В таком случае, такие идеи озвучивались далеко до автора, так же как к примеру sql injection. Это не более чем абстрактный класс атак. Автор статьи ни делал никакого открытия, и не показал реализацию атаку. С таким же успехом можно сделать статью, как вы нашли sql injection на сайте google. И что они вам в переписке отказывают в выплате 1 миллиона долларов. Или вы нашли вместо sql injection, не раскрученную ошибку от sql сервера, но написали разработчикам, что у них там sql injection и у них серьезные проблемы с безопасностью. Вы разницу не понимаете?
Вы сами поняли, что написали? С каких пор у вас сказочные фантазии, что коровы оценивают вкус молока? Такие же фантазии, что автору плюнули в лицо и не оценили его работу?
"Радикальный — DPI: влезать в каждый пакет, анализировать шаблоны трафика, выявлять протоколы по статистическому анализу пакетов."
Увы, но уже с этим встречались в прошлом. В 2010 году когда работал в одной крупной компании, нас интернет провайдер уведомил об одностороннем изменении договора и VPN сеть объединяющая несколько офисов в один момент резко перестала работать. Т.е. об изменении условий договора мы узнали уже постфактум. Суть изменений была такова, что если раньше мы им платили круглую сумму, то теперь за использование VPN через их каналы связи, мы должны им платить круглую сумму умноженную на 3, и они режут теперь всем VPN трафик. Стоить заметить, что не через выделенный VLAN, а именно через сеть Internet. Переговоры не привели к успеху, поэтому послали их в дремучий лес и сменили провайдера.
В середине 2000-х с уходом эры dual-up, многие провайдеры ради экономии трафика и увеличения прибыли любили заворачивать весь http трафик на свой тормозной кэширующий прокси сервер. Благо с https это так просто не прокатит, но никто не защищен, что кому-то в руководстве взбредет в голову запретить весь https и vpn трафик ради "общей безопасности"...