Пользуясь случаем, можно спросить, а как вы относитесь к пробиотикам для восстановления микрофлоры как раз в полости рта, после использование антисептиков? Есть какие-то полезные варианты? Кстати было бы очень интересно увидеть от вас статью про правильный уход и про поддержание здоровой микрофлоры.
Трёхполосники Амфитон 25 АС-027 так же были сделаны. СЧ динамик в стакане, ленточный ВЧ динамик 10ГИ-1 (до 35КГц), естественно, вообще изолирован. Звук у них после небольшой доработки был просто шикарен, с тех пор хочу трёхполосную систему с ленточным ВЧ. Таких кристально чистых высоких я не слышал с другим типом пищалок. Цены на АС с таким типом динамиков (да и даже сами динамики отдельно для DIY) очень и очень кусачие.
Серьезное исследование, спасибо. Система блокировки и так не выдерживает никакой критики, а уж если за неё возьмутся по-крупному, то не только простые пользователи пострадают, весь онлайн сегмент бизнса с банками и транзакциями полетит «в труху». Типичный DOS-сценарий «завали конкурента» или «посей полный хаос», по факту РКН даёт убийственный набор инструментов в руки всем желающим. Интересно, сами дойдут что это нереально или дождутся пока всё развалится само.
PS: и да, тэги улыбнули.
Не нахожу. Наиболее популярное смещение (на любой платформе) — это нуль
… потому что вы привыкли приводить типы указателей на LE платформе? Замечательно, особенно если вы пропускаете такое в ваш код.
На BE практически любая попытка исполнить подобный код приводит к катастрофе, разбирательствам и, соответственно, исправлению программы.
Как я уже сказал, особенно замечательно, если этот код поселится в ветке, которая не покрывается вашими тестами (нет, не обработчик ошибок, а функциональность при определённой комбинации фич). +10 к надежности. И еще, вы уверены что любая попытка исполнить подобный код приведёт к крашу а не к потенциальному эксплоиту?
Там не было хаков. Там было банальное рассогласование типов. Так вот на BE — подобная проблема обнаруживается почти сразу, а на LE — живёт годами, пока не «выстрелит».
Опять же, повторюсь, если вы считаете «не хаками» приведение типов указателей, которое разваливается при сборке на платформе с другой endianness, то мне здесь добавить нечего.
При работе с регистрами разницы между BigEndian и LittleEndian нет вообще. Она появляется при обращении в память.
Регистры тут совершенно ни при чем, при присвоении переменных по значению компилятор делает всё работу правильно по приведению типа.
Я не говорю о том, что мир LE — ужасен, а мир BE — абсолютно безопасен. Это не так. Но то, что мир BE безопаснее, так как ошибки обнаруживаются раньше — это однозначно.
Вот это утверждение для меня неоднозначно, есть статистика на эту тему? Еще один пример кривой игры с указателями не статистика, как я и говорил в своем комментарии, такие кодописатели сами себе буратины, огребут проблем независимо от BE или LE.
Как вы думаете — долго бы программа прожила на BE-системе если бы к переменной типа DWORD лазили бы через указатель на WORD? А на LE-системе — она дожила до всемирной эпидемии.
Да, долго. На BE платформах так же лазят к переменным типа DWORD через указатели на WORD, только по немного другим смещениям, не находите? Если бы Windows был только под BE, то приведённый вами код добили бы похожими хаками до рабочего состояния именно на этой платформе. При попытке собрать код под LE, оно бы предсказуемо рассыпалось.
вся конструкция бы немедленно сломалась и её пришлось бы чинить
У них именно всё сломалось (заметьте, на LE платформе, а не на BE), а программист починил «как смог», смотрите их описание:
there is a important change from WinNT4 (to fix OOB read)
Почему вы уверены, что когда ломается код на BE платформе, его внезапно починят правильно а не напихают подобных кривых хаков с выборочной загрузкой байтов из памяти?
Что происходит на Big Endian, если вы перепутали размеры? Правильно: программа получает в качестве входных данных мусор, падает, программист ругается матом, чинит проблему — и на этом всё кончается.
Неправильно, по двум причинам:
1. Компилятор C при явном приведении типа uint32->uint16 на BE правильно обрежет данные, он достаточно умный в этом плане. Ну а если программист сам читает данные побайтно и/или вручную кастует указатели не понимая различия LE/BE, то он сам себе буратино и проблем огребёт независимо от платформы.
2. Если бы все ветки кода и варианты его использования попадали в test coverage, то PVS Studio, в блоге которого мы сидим, был бы не нужен, не так ли? Граничных условий море и я не видел проектов, где хотя бы бОльшая часть покрывается тестами. Так что в общем случае, тесты пройдут и ничего не будет заметно, пока не выстрелит та самая ветка кода.
Что происходит на Little Endian, если вы перепутали размеры? Тесты проходят, программа сдана заказчику, exploit написан, весь мир на ушах.
До переполнения типа не происходит ничего, в остальных случаях происходит классический случай переполнения типа, что мешает переполнить переменную типа uint16/uint32 и получить то же самое поведение? Эта проблема не имеет отношения к endianness.
Вот и вы их спутали, хотя казлось бы — всё очевидно.
Совершенно неочевидно, особенно про то как связан buffer overflow в EternalBlue с различиями в BE/LE, поделитесь деталями, если не секрет. При обрезании индекса буфера на little endian мы можем получить только buffer underflow.
А как надо? Почему у нас все процессоры little endian при том, что big endian безопаснее? Ответ: потому что так исторически сложлось. То же самое и здесь.
Ворвусь в холивар про табы vs пробелы с замечанием, что little endian таки безопаснее, в нём при неявном кастинге указателя на другой (меньший) тип не нужно менять значение указателя. А это гораздо безопаснее чем иметь вероятность считать старшую половину слова при кастинге например uint32->uint16. Даже большинство ARMов на Linux/Android уже в LE режиме, несмотря на допзатраты по разворачиванию заголовков в TCP/IP.
Согласен, очень правильная подача материала, как говорится умный учится на чужих ошибках, а дурак на своих. Тем более повторение всегда полезно для того что освежить знания. Мы стали пользоваться PVS как только вышла тестовая версия под Linux.
Расскажите мне какими процессами за такое время можно промодулировать и какие параметры лампы чтобы это сказалось на звуке?
Хинт: модулировать ничего не надо, изменение температуры (как и деградация) катода приводит к выходу лампы из того куска псевдолинейного режима, про который тут любят упоминать. Да оно играет, с бОльшими искажениями.
А большинство транзисторных усилителей охвачены ООС, им наплевать на нелинейность элементов, надеюсь не надо объяснять почему. На этом собственно всё в этом треде.
вам же просто хочется хоть что- то возразить и «докопаться до столба», разумеется с фейспалмами и дешевой театральшиной. ))))
Это хорошее образование по физике не даёт промолчать на такие заявления, а вам советую почитать книжку по физике на тему ВАХ вакуумных триодов и их зависимости от разных параметров, в том числе и от температуры.
Все Вами перечисленное- процессы медленные
Так вы определитесь — «у ламп нет изменения параметров в зависимости от температуры» или всё-таки есть? А то меняете свои показания со скоростью звука. И приведите аргументы по поводу «меняются очень медленно», как насчёт графика зависимости ВАХ от температуры в комнате в случае усилителя без обратной связи? Как насчёт таких же характеристик, скажем, после 500 часов работы лампы?
Хотя вопросы риторические, у вас ни одного аргумента в обоснование своих теорий как не было так и нет, а физика как наука, вам не аргумент. Данный коммент написал для людей интересующихся вопросом.
У ламп нет изменения параметров в зависимости от температуры.
Это в лампе-то нет зависимости эмиссии от температуры? А зачем же лампе, простите, нить накала нужна и как там со стабильностью накала и деградацией нагревающих элементов, не говоря уже о том что от нагрева они помаленьку испаряются в рабочий объём.
У меня полнейший фейспалм от таких заявлений.
Понятно, что WannaCry не работает под Linux, зато libmagic вполне себе кроссплатформенная штука. Я это всё к тому, что очевидно единственный способ надежно спасти файлы это держать бэкапы на удалённой системе, версионирование которой не даст вирусу возможности удалить файлы, даже если произойдет бэкап после шифрования. Спасение файлов на локальной системе это security by obscurity в любом случае.
Поддерживаю, ничего иного тут и быть не может, провайдер сошлётся на существующий закон и точка. Зачем в этой цепочке напрягать провайдера вообще непонятно.
Покупка платиновых кабелей питания и выстраивание их по фен-шую, это, если помните, было в галактике кин-дза-дза. «Когда у общества нет цветовой дифференциации штанов, то нет цели»
Просто эти люди лучше ощущают музыку, когда у них есть малиновые штаны)
Библиотека libmagic.so у меня в линуксе весит аж целых 146KB, причем она умеет определять огромное количество форматов. Уверен что для целевых файлов вируса такой libmagic будет занимать на порядок меньше.
А если криптовирусы всё-таки начнут определять тип содержимого не по расширению а по начальной сигнатуре, как делают даже простые просмотрщики картинок?
PS: и да, тэги улыбнули.
… потому что вы привыкли приводить типы указателей на LE платформе? Замечательно, особенно если вы пропускаете такое в ваш код.
Как я уже сказал, особенно замечательно, если этот код поселится в ветке, которая не покрывается вашими тестами (нет, не обработчик ошибок, а функциональность при определённой комбинации фич). +10 к надежности. И еще, вы уверены что любая попытка исполнить подобный код приведёт к крашу а не к потенциальному эксплоиту?
Опять же, повторюсь, если вы считаете «не хаками» приведение типов указателей, которое разваливается при сборке на платформе с другой endianness, то мне здесь добавить нечего.
Регистры тут совершенно ни при чем, при присвоении переменных по значению компилятор делает всё работу правильно по приведению типа.
Вот это утверждение для меня неоднозначно, есть статистика на эту тему? Еще один пример кривой игры с указателями не статистика, как я и говорил в своем комментарии, такие кодописатели сами себе буратины, огребут проблем независимо от BE или LE.
Да, долго. На BE платформах так же лазят к переменным типа DWORD через указатели на WORD, только по немного другим смещениям, не находите? Если бы Windows был только под BE, то приведённый вами код добили бы похожими хаками до рабочего состояния именно на этой платформе. При попытке собрать код под LE, оно бы предсказуемо рассыпалось.
У них именно всё сломалось (заметьте, на LE платформе, а не на BE), а программист починил «как смог», смотрите их описание:
Почему вы уверены, что когда ломается код на BE платформе, его внезапно починят правильно а не напихают подобных кривых хаков с выборочной загрузкой байтов из памяти?
Неправильно, по двум причинам:
1. Компилятор C при явном приведении типа uint32->uint16 на BE правильно обрежет данные, он достаточно умный в этом плане. Ну а если программист сам читает данные побайтно и/или вручную кастует указатели не понимая различия LE/BE, то он сам себе буратино и проблем огребёт независимо от платформы.
2. Если бы все ветки кода и варианты его использования попадали в test coverage, то PVS Studio, в блоге которого мы сидим, был бы не нужен, не так ли? Граничных условий море и я не видел проектов, где хотя бы бОльшая часть покрывается тестами. Так что в общем случае, тесты пройдут и ничего не будет заметно, пока не выстрелит та самая ветка кода.
До переполнения типа не происходит ничего, в остальных случаях происходит классический случай переполнения типа, что мешает переполнить переменную типа uint16/uint32 и получить то же самое поведение? Эта проблема не имеет отношения к endianness.
Совершенно неочевидно, особенно про то как связан buffer overflow в EternalBlue с различиями в BE/LE, поделитесь деталями, если не секрет. При обрезании индекса буфера на little endian мы можем получить только buffer underflow.
Ворвусь в холивар про табы vs пробелы с замечанием, что little endian таки безопаснее, в нём при неявном кастинге указателя на другой (меньший) тип не нужно менять значение указателя. А это гораздо безопаснее чем иметь вероятность считать старшую половину слова при кастинге например uint32->uint16. Даже большинство ARMов на Linux/Android уже в LE режиме, несмотря на допзатраты по разворачиванию заголовков в TCP/IP.
Хинт: модулировать ничего не надо, изменение температуры (как и деградация) катода приводит к выходу лампы из того куска псевдолинейного режима, про который тут любят упоминать. Да оно играет, с бОльшими искажениями.
А большинство транзисторных усилителей охвачены ООС, им наплевать на нелинейность элементов, надеюсь не надо объяснять почему. На этом собственно всё в этом треде.
Это хорошее образование по физике не даёт промолчать на такие заявления, а вам советую почитать книжку по физике на тему ВАХ вакуумных триодов и их зависимости от разных параметров, в том числе и от температуры.
Так вы определитесь — «у ламп нет изменения параметров в зависимости от температуры» или всё-таки есть? А то меняете свои показания со скоростью звука. И приведите аргументы по поводу «меняются очень медленно», как насчёт графика зависимости ВАХ от температуры в комнате в случае усилителя без обратной связи? Как насчёт таких же характеристик, скажем, после 500 часов работы лампы?
Хотя вопросы риторические, у вас ни одного аргумента в обоснование своих теорий как не было так и нет, а физика как наука, вам не аргумент. Данный коммент написал для людей интересующихся вопросом.
Это в лампе-то нет зависимости эмиссии от температуры? А зачем же лампе, простите, нить накала нужна и как там со стабильностью накала и деградацией нагревающих элементов, не говоря уже о том что от нагрева они помаленьку испаряются в рабочий объём.
У меня полнейший фейспалм от таких заявлений.
Просто эти люди лучше ощущают музыку, когда у них есть малиновые штаны)