А представьте, если бы через javascript еще и память можно было портить. У всего браузера сразу. Вот крутота то была б!
Помните как все спешно чинили heartbleed, кстати? А ведь это всего лишь одна маленькая ошибка при работе с памятью. А шороху навела больше чем все XSS вместе взятые.
Абсолютно пофиг. "Не пофиг" начинается когда этот человек начинает ходить и рассказывать что у него единственно правильный сетап, что те кто не купил позолоченный кабель питания из бескислородной меди вообще не имеют права слушать музыку, что он может на слух отличить 48кГц от 96кГц, и FLAC от WAV и так далее.
Покажите мне кабель по которому можно 1.5 мегабита, а 480 - нельзя. Хоть один. Поудивляемся вместе.
Чем эти кабеля отличаются?
Количеством линий данных в первую очередь. В USB2 - одна пара которая работает и на прием и на передачу. В USB3.0 - их уже три: одна пара для совместимости с USB2, одна на прием и одна на передачу на высоких скоростях. Так же, из-за того что в USB3 выше частоты усилились требования к экранированию и волновым характеристикам кабеля.
В USB3.1 таких пар уже 5: одна старая низкоскоростная для совместимости с USB2 и еще 4 высокоскоростных.
Кабеля физически разные, там в них разное количество проводников. Поэтому и разная скорость. А еще толщина некоторых проводников влияет на скорость зарядки, да. Но это другая история.
И да, естественно эти проводники по-разному уложены и экранированы. Да, у них разные требования к характеристикам. Но это уже детали. Вы можете взять самый позолоченный и самый офигенный кабель USB2, но он никогда не сможет работать с USB3, просто потому что там проводов не хватит. Вот и все.
А что с USB3? Его bandwidth тем более покроет любые требования к передачи звука. И если вы о том что плохие кабеля могут приводить к проблемам - да, они могут. Это будет выглядеть как полное отваливание устройства.
USB любой версии обязательно контролирует корректность пакетов. Не может быть такого, что на USB DAC придет поврежденный пакет и он его примет. Он его должен проигнорировать целиком. Если пакеты целиком будут терятся, то это заметит кто угодно, не только аудиофил.
Прикиньте, если у вас не музыка играется по USB, а файл пишется на диск. Вам понравится случайное изменение в одном бите? Никому не понравится...
И в чём разница между проводами? А материале? В качестве изготовления? В экранировании?
Ну да, в этом самом. Обычно это выливается в то что данное устройство с данным кабелем либо работает, либо нет. Не может быть такого что из-за плохого кабеля у вас будут менятся случайные биты и это дойдет аж до аналогового тракта.
Дело в том, что в ответ на небольшую ересь аудиофильства, имеющую под собой реальное обоснование в виде проблем с контактами, нам начинают рассказывать лютейшее мракобесие о том, что материал и качество изготовления проводов ни на что не влияет.
Ну оно влияет, но не так как в аналоговой части. Данные то там ходят в цифре и соответственно эффекты тоже двоичные, так сказать: либо работает, либо нет.
USB2 выдает 420 мегабит/с по паспорту. Этого достаточно для любого звука. Кабель на это никак повлиять не может. Он либо будет работать, либо не будет. Два варианта. Все.
Интересно как оно работает в больших и действительно распределенных сетапах. Особенно там, где патчами обмениваются через email.
Да и вообще, у нас в команде очень редко коммит с первого раза попадает в master. Обычно происходит несколько циклов ревью перед этим и иногда коммит изменяется до неузнаваемости.
Кстати, интересный терминологический вопрос. Композиторы так называются, потому что они делают композицию из окон на экране. С другой стороны рисованием композиций занимаются художники...
Вы так говорите - будто композиторы это что-то плохое. Типа давайте, у нас изображение на экране будет зависеть от того как приложения быстро отрабатывают запрос на перерисовку окон (забыли уже "шлейфы" от окон в виндах или равномерно закрашенные прямоугольники в иксах, да?), заодно откажемся от аппаратного ускорения и будем делать блиттинг в софте, поимеем обратно проблемы с проигрыванием видео (забыли зеленые или розовые подложки в окнах видеоплееров, да?) и так далее...
То что большинство композиторов в линуксе заодно впихивает всякие свистоперделки вроде трехмерных эффектов больше говорит о вкусе их авторов и юзеров, нежели о самом подходе к композиции финального изображения на экране.
Ну это ж классический tradeoff между скоростью и потреблением памяти. Если памяти много - то реально можно смириться с тем что какие-то куски потом когда-нибудь освободятся. Зато не нужно подсчитывать ссылки, да. С другой стороны, в своей работе я редко вижу когда софт упирается в скорость процессора. Чаще - как раз в объем свободной памяти.
Это только если вы можете гарантировать что ваше "сообщение о том что операция завершена" никогда не выбросит исключение. В принципе, даже std::cout может бросить исключение если ему разрешить: cout.exceptions(iostate) .
В этому по сути фундаментальное различие - Rust дает сильно больше гарантий. Если ваш код уже скомпилировался, то вероятность того что в нем что-то неожиданно пойдет не так гораздо ниже чем в C++. С++ считает что программист не делает ошибок и что любая программа не содержит UB. Вот только я гарантирую что я найду UB в любом более-менее большом проекте на C++.
Так никто не говорит про /sys. Я скорее про общий подход с интерфейсами и их имплементацией через коллбеки в структурах. Там даже есть некоторый вариант наследования, когда в сабклассах переопределяется только часть коллбеков, например.
По моему такая система будет в разы более удобна для программистов.
Для программистов будет удобнее всего использовать unixtime. Все эти часы, минуты, дни недели и месяцы - от лукавого.
Заодно и на СИ перейти. Килосекунда - это типа минут 15. Вместо суток - 100 килосекунд. Вместо недели - мегасекунда. 50 мегасекунд - это год. Удобно! Людишки конечно первое время будут возмущаться что 100 килосекунд не синхронизированы с длиной суток, а Новый Год припадает на разные поры года, но потом привыкнут. Зато все просто и понятно.
Ну да, как тут правильно заметили подход автора ломает поддержку multi threading. Так что да, если отказаться от части фич, то можно сделать быстрее. Если забить на переносимость, например, то можно вообще поюзать mmap/MapViewOfFile и получить еще нефиговый прирост в скорости.
А представьте, если бы через javascript еще и память можно было портить. У всего браузера сразу. Вот крутота то была б!
Помните как все спешно чинили heartbleed, кстати? А ведь это всего лишь одна маленькая ошибка при работе с памятью. А шороху навела больше чем все XSS вместе взятые.
Абсолютно пофиг. "Не пофиг" начинается когда этот человек начинает ходить и рассказывать что у него единственно правильный сетап, что те кто не купил позолоченный кабель питания из бескислородной меди вообще не имеют права слушать музыку, что он может на слух отличить 48кГц от 96кГц, и FLAC от WAV и так далее.
Покажите мне кабель по которому можно 1.5 мегабита, а 480 - нельзя. Хоть один. Поудивляемся вместе.
Количеством линий данных в первую очередь. В USB2 - одна пара которая работает и на прием и на передачу. В USB3.0 - их уже три: одна пара для совместимости с USB2, одна на прием и одна на передачу на высоких скоростях. Так же, из-за того что в USB3 выше частоты усилились требования к экранированию и волновым характеристикам кабеля.
В USB3.1 таких пар уже 5: одна старая низкоскоростная для совместимости с USB2 и еще 4 высокоскоростных.
Кабеля физически разные, там в них разное количество проводников. Поэтому и разная скорость. А еще толщина некоторых проводников влияет на скорость зарядки, да. Но это другая история.
И да, естественно эти проводники по-разному уложены и экранированы. Да, у них разные требования к характеристикам. Но это уже детали. Вы можете взять самый позолоченный и самый офигенный кабель USB2, но он никогда не сможет работать с USB3, просто потому что там проводов не хватит. Вот и все.
А что с USB3? Его bandwidth тем более покроет любые требования к передачи звука. И если вы о том что плохие кабеля могут приводить к проблемам - да, они могут. Это будет выглядеть как полное отваливание устройства.
USB любой версии обязательно контролирует корректность пакетов. Не может быть такого, что на USB DAC придет поврежденный пакет и он его примет. Он его должен проигнорировать целиком. Если пакеты целиком будут терятся, то это заметит кто угодно, не только аудиофил.
Прикиньте, если у вас не музыка играется по USB, а файл пишется на диск. Вам понравится случайное изменение в одном бите? Никому не понравится...
Ну да, в этом самом. Обычно это выливается в то что данное устройство с данным кабелем либо работает, либо нет. Не может быть такого что из-за плохого кабеля у вас будут менятся случайные биты и это дойдет аж до аналогового тракта.
Ну оно влияет, но не так как в аналоговой части. Данные то там ходят в цифре и соответственно эффекты тоже двоичные, так сказать: либо работает, либо нет.
Это все правда. Но при чем тут качество кабеля?
USB2 выдает 420 мегабит/с по паспорту. Этого достаточно для любого звука.
Кабель на это никак повлиять не может. Он либо будет работать, либо не будет. Два варианта. Все.
Тогда диодом будет управлять процессор, что как бы нивелирует всю идею.
Интересно как оно работает в больших и действительно распределенных сетапах. Особенно там, где патчами обмениваются через email.
Да и вообще, у нас в команде очень редко коммит с первого раза попадает в master. Обычно происходит несколько циклов ревью перед этим и иногда коммит изменяется до неузнаваемости.
Или может MS просто не сломали всю архитектуру к черту, а встроили свою фичу как надо. Не могу сказать что это в духе MS, но чем черт не шутит.
Кстати, интересный терминологический вопрос. Композиторы так называются, потому что они делают композицию из окон на экране. С другой стороны рисованием композиций занимаются художники...
Вы так говорите - будто композиторы это что-то плохое. Типа давайте, у нас изображение на экране будет зависеть от того как приложения быстро отрабатывают запрос на перерисовку окон (забыли уже "шлейфы" от окон в виндах или равномерно закрашенные прямоугольники в иксах, да?), заодно откажемся от аппаратного ускорения и будем делать блиттинг в софте, поимеем обратно проблемы с проигрыванием видео (забыли зеленые или розовые подложки в окнах видеоплееров, да?) и так далее...
То что большинство композиторов в линуксе заодно впихивает всякие свистоперделки вроде трехмерных эффектов больше говорит о вкусе их авторов и юзеров, нежели о самом подходе к композиции финального изображения на экране.
Ну это ж классический tradeoff между скоростью и потреблением памяти. Если памяти много - то реально можно смириться с тем что какие-то куски потом когда-нибудь освободятся. Зато не нужно подсчитывать ссылки, да. С другой стороны, в своей работе я редко вижу когда софт упирается в скорость процессора. Чаще - как раз в объем свободной памяти.
Это только если вы можете гарантировать что ваше "сообщение о том что операция завершена" никогда не выбросит исключение. В принципе, даже
std::coutможет бросить исключение если ему разрешить:cout.exceptions(iostate).В этому по сути фундаментальное различие - Rust дает сильно больше гарантий. Если ваш код уже скомпилировался, то вероятность того что в нем что-то неожиданно пойдет не так гораздо ниже чем в C++. С++ считает что программист не делает ошибок и что любая программа не содержит UB. Вот только я гарантирую что я найду UB в любом более-менее большом проекте на C++.
Это определенно было у Винджа в "Глубине в небе".
Так никто не говорит про
/sys. Я скорее про общий подход с интерфейсами и их имплементацией через коллбеки в структурах. Там даже есть некоторый вариант наследования, когда в сабклассах переопределяется только часть коллбеков, например.Для программистов будет удобнее всего использовать unixtime. Все эти часы, минуты, дни недели и месяцы - от лукавого.
Заодно и на СИ перейти. Килосекунда - это типа минут 15. Вместо суток - 100 килосекунд. Вместо недели - мегасекунда. 50 мегасекунд - это год. Удобно! Людишки конечно первое время будут возмущаться что 100 килосекунд не синхронизированы с длиной суток, а Новый Год припадает на разные поры года, но потом привыкнут. Зато все просто и понятно.
Или пролет исключений через границы библиотек, например.
Проблема 2038 года куда ближе и страшнее.
Ну да, как тут правильно заметили подход автора ломает поддержку multi threading. Так что да, если отказаться от части фич, то можно сделать быстрее. Если забить на переносимость, например, то можно вообще поюзать mmap/MapViewOfFile и получить еще нефиговый прирост в скорости.
Ага, вот бы например nginx удивился бы, узнав что не может читать файлы не из того потока, которых их открывал.