Если каждый со своими доработками полезет, это будет бардак и раздрай. А вообще хорошая иллюстрация того, что бывает, когда железо придумывают программисты :)
нет конечно же. Раз уж есть DMA которое прогружает все прямоугольники в начале кадра, то оно же и могло бы перегружать каждый окончившийся прямоугольник.
вы забыли даже про компиляторы от Intel, от Microsoft и от IBM
Вот 5-минутный гуглёж показывает, что и ibm и intеl выкинули уже свои компиляторы и перешли на llvm. Так что всё же 2шт. Ну а SDCC тут вовсе не в тему. Как пожалуй и microsoft со своим мини-компилером под моноплатформу, которую в РФ уже не купить.
А основные проблемы становятся ясны уже на этапе обсуждения.
И какие же основные проблемы есть сейчас у следующих ISA
Карно здесь ни при чем, он именно про тепловые машины с расширением/сжатием газа
Если вы для заданной разницы температур сделаете тепловую машину без газа с КПД лучше, чем у цикла Карно, то часть полученной механической работы вы можете пустить в тепловую машину с циклом Карно, которая вам будет поддерживать тепловые потоки вашей первой машины, а другую часть механической работы пустить на ваши нужны. Другими словами, у вас получится вечный двигатель.
где файловую систему менять нельзя или не хочется (например, уже развернутая система на ext4).
Самое сложное в замене rootfs на btrfs -- это пересобрать initramfs и переустановить модули для grub с поддержкой оной. Делается через chroot, после физического копирования файлов с ext4 на btrfs -- 1 раз.
Того же не могу сказать про OpenZFS, она со своими заморочками (груб поддерживает только старую версию дискового формата, маунт её в рутфс надо делать в явном виде в initramfs etc.) и тормознутостью (сильно медленнее при начальной загрузке, когда кеши не прогреты) явно не очень подходит для rootfs.
Высокая скорость в некоторых применениях может быть желательна
Поэтому за скорость криптохешей борьба идёт до сих пор (правда вроде как MD5 так никто особо и не обогнал, не считая читов типа SHA-NI и работы не в один поток).
Что для паролей "хеши" должны быть медленными люди поняли помоему ещё в 90ые, когда появился bcrypt, странно преподносить это как откровение.
А вот аргументация типа "раз эти вот хеши по коллизиям никакие, то давайте их вообще выпилим" (а SHA1 не то чтобы и "никакой") -- это так себе аргументация. Для целей HMAC например коллизии не важны, а эффективных атак на предмет 2ого прообраза вроде ещё и для MD5 не придумали. Если параноить то и AES выбрасывать пора, там же почти все раунды уже поломали: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Known_attacks
При этом устаревшие функции (MD5, SHA-1) отправлены в отставку из-за обнаруженных коллизий и слишком высокой скорости. Их нельзя использовать не только для хеширования паролей, даже с солью, но и вообще для любой криптографии.
Не понял, вообще для любой криптографии нельзя из-за "слишком высокой скорости" или "из-за обнаруженных коллизий"? Поясните.
У меня однажды 2шт gnusmas evo 860, стоявшие в raid1 и всё время под питанием, запортили данные. Примерно одновременно, ЧСХ. Во время очередного scrub'а каждый зарепортил несколько битых секторов. Т.к. у каждого битые были свои, данные не потерялись.
Вывод -- даже нахождение под питанием не гарантирует сохранность. Даже проведение вычитки всех данных время от времени не гарантирует сохранность.
Вот там пишут, что даже те, кто "купили" -- были госкомпаниями (в то время), а следовательно "покупка" была лишь перекладыванием бюджетных денег из одного кармана в другой. И даже такие "покупки" и близко не окупили затраты на разработку (опять же эти затраты шли из бюджетиков aka денежек налогоплательщиков).
Вот этот ваш Сурчин и выглядит как большая трешовая деревня.
Аэропорт-то может и новый. А вот деревня рядом с ним трешовая.
есть же алгоритмы брезенхема чтоб обходиться вообще без умножений.
Если каждый со своими доработками полезет, это будет бардак и раздрай. А вообще хорошая иллюстрация того, что бывает, когда железо придумывают программисты :)
нет конечно же. Раз уж есть DMA которое прогружает все прямоугольники в начале кадра, то оно же и могло бы перегружать каждый окончившийся прямоугольник.
именно поэтому их и можно было бы переиспользовать.
Имеется ли возможность переиспользовать генераторы прямоугольников ниже по кадру по аналогии например со спрайтами в денди и c64? И почему? :)
Вот 5-минутный гуглёж показывает, что и ibm и intеl выкинули уже свои компиляторы и перешли на llvm. Так что всё же 2шт. Ну а SDCC тут вовсе не в тему. Как пожалуй и microsoft со своим мини-компилером под моноплатформу, которую в РФ уже не купить.
И какие же основные проблемы есть сейчас у следующих ISA
amd64
arm64
risc-v
ну допустим power
ну допустим mips/loongarch
?
...он бы тоже смог врать, что РК86 - копия Альтаира. https://habr.com/ru/articles/941628/comments/#comment_28779812
будет мешать работа "входа" в это покрытие и соответственно работы выхода из того на что это покрытие нанесено.
Если вы для заданной разницы температур сделаете тепловую машину без газа с КПД лучше, чем у цикла Карно, то часть полученной механической работы вы можете пустить в тепловую машину с циклом Карно, которая вам будет поддерживать тепловые потоки вашей первой машины, а другую часть механической работы пустить на ваши нужны. Другими словами, у вас получится вечный двигатель.
Ваш нейросблёв бредит. А вы пока изучите что ли тему "уравновешивание ДВС"
Поржал, спасибо.
Самое сложное в замене rootfs на btrfs -- это пересобрать initramfs и переустановить модули для grub с поддержкой оной. Делается через chroot, после физического копирования файлов с ext4 на btrfs -- 1 раз.
Того же не могу сказать про OpenZFS, она со своими заморочками (груб поддерживает только старую версию дискового формата, маунт её в рутфс надо делать в явном виде в initramfs etc.) и тормознутостью (сильно медленнее при начальной загрузке, когда кеши не прогреты) явно не очень подходит для rootfs.
Поэтому за скорость криптохешей борьба идёт до сих пор (правда вроде как MD5 так никто особо и не обогнал, не считая читов типа SHA-NI и работы не в один поток).
Что для паролей "хеши" должны быть медленными люди поняли помоему ещё в 90ые, когда появился bcrypt, странно преподносить это как откровение.
А вот аргументация типа "раз эти вот хеши по коллизиям никакие, то давайте их вообще выпилим" (а SHA1 не то чтобы и "никакой") -- это так себе аргументация. Для целей HMAC например коллизии не важны, а эффективных атак на предмет 2ого прообраза вроде ещё и для MD5 не придумали.
Если параноить то и AES выбрасывать пора, там же почти все раунды уже поломали: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Known_attacks
Не понял, вообще для любой криптографии нельзя из-за "слишком высокой скорости" или "из-за обнаруженных коллизий"? Поясните.
У меня однажды 2шт gnusmas evo 860, стоявшие в raid1 и всё время под питанием, запортили данные. Примерно одновременно, ЧСХ. Во время очередного scrub'а каждый зарепортил несколько битых секторов. Т.к. у каждого битые были свои, данные не потерялись.
Вывод -- даже нахождение под питанием не гарантирует сохранность. Даже проведение вычитки всех данных время от времени не гарантирует сохранность.
Ну вот и пылесосили бы перед конкордами, фигли. Сэкономили?
Хакер в столовой?
https://www.heritageconcorde.com/concorde-orders-and-options
Вот там пишут, что даже те, кто "купили" -- были госкомпаниями (в то время), а следовательно "покупка" была лишь перекладыванием бюджетных денег из одного кармана в другой. И даже такие "покупки" и близко не окупили затраты на разработку (опять же эти затраты шли из бюджетиков aka денежек налогоплательщиков).