Обновить
-9

Пользователь

0,1
Рейтинг
1
Подписчики
Отправить сообщение

где файловую систему менять нельзя или не хочется (например, уже развернутая система на 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'а каждый зарепортил несколько битых секторов. Т.к. у каждого битые были свои, данные не потерялись.

Вывод -- даже нахождение под питанием не гарантирует сохранность. Даже проведение вычитки всех данных время от времени не гарантирует сохранность.

Ну вот и пылесосили бы перед конкордами, фигли. Сэкономили?

https://www.heritageconcorde.com/concorde-orders-and-options

Вот там пишут, что даже те, кто "купили" -- были госкомпаниями (в то время), а следовательно "покупка" была лишь перекладыванием бюджетных денег из одного кармана в другой. И даже такие "покупки" и близко не окупили затраты на разработку (опять же эти затраты шли из бюджетиков aka денежек налогоплательщиков).

Это единственная катастрофа «Конкорда» за 27 лет эксплуатации и вторая катастрофа сверхзвукового самолёта во Франции (после катастрофы Ту-144 под Парижем).

Случай, приведший к катастрофе -- единственный, а вот случай разрушения шин, приведший к потенциально опасным утечкам топлива -- примерно 50ый. Первые звоночки прозвенели ещё в 70ые годы -- и до самой катастрофы всем было как обычно.

Во время разбега по ВПП на скорости примерно 280 км/ч лайнер наехал на металлический обломок от DC-10, из-за чего покрышка правого первого колеса на левой стойке шасси лопнула

Ведь никто же не пылесосит ВПП после каждого взлёта и каждой посадки? А значит, мусор на полосу от улетевшего самолёта время от времени будет падать. И последующие самолёты будут пороть шины. Вот только я не то чтобы очень слышал, чтобы это приводило к катастрофам, подобным конкордовской.

И ещё. Суммарное кол-во полётов у всех конкордов целиком примерно как кол-во полётов, совершаемых всеми остальными самолётами сейчас за неделю. Если бы все остальные самолёты были бы так же ненадёжны касательно последствий взрыва покрышек, то эффектные падающие факелы мы бы видели где-то раз в месяц, если не чаще.

Следовательно, мой (конечно же необоснованный) вывод -- что конкорды были конкретно опасными самолётами, об этом было известно десятилетия и никто даже не почесался, пока не стало поздно. Чисто чтоб всех собак на Ту-144 не вешали.

И да, сам нарратив о том что мол "это же с того гадкого dc-10 что-то выпало" -- пример отвлечения внимания публики от истинной проблемы и истинных причин.

PS: На закуску, вот ещё пара картиночек:

И какие меры были приняты? Правильно, никакие. Разве что склад запчастей для рулей направления устроили в каждом аэропорте, который посещали конкорды.

Никто никогда не купил ни один Конкорд. Тем двум конторам, что на нём летали, он достался практически нахаляву.

какой md5?

  1. Нулевая стойкость к коллизиям, но к нахождению прообразов -- вполне себе. Там, где 1ое не важно и хватает 128 бит хеша -- его можно применять

  2. на процессорах с SHA-NI или эквивалентами действительно md5 получается сильно медленнее чем SHA1 или SHA256. Но вот во всех остальных случаях md5 всё ещё чуть ли не самый быстрый (без чита типа "а тут мы считаем хеш в 32 потока", который так любят некоторые изобретатели криптохешей)

Объем зависит от водянки, у меня больше литра несильно, но больше

Литр воды имеет теплоёмкость примерно как 5 кг алюминия. При этом вода постоянно циркулирует, а тепло в 5 кг алюминия будет медленно распределяться за счёт только теплопроводности.

Когда-то игрался в netbsd. Кончилось тем, что sshfs отказался монтировать то, что должен был. В официальных рассылках никто ничем помочь не смог.

Отдельной строчкой не понимал и до сих пор не могу понять какую-то инопланетную систему разделов в разделах в этой netbsd. Чем их до сих пор не устраивают обычные разделы MBR или GPT? Ну и с интероперабельностью linux<->netbsd вроде как тоже были проблемы -- они ФС друг друга только read-only могут или типа того.

Отдельной строчкой пакетные системы. В netbsd или жить с бинарными пакетами или вручную пересобирать пакеты из pkgsrc. Пакетный "менеджер" не будет следить за приходом новых версий в репах и не будет предлагать пересобрать новьё.

Подбирал вайфайку в ноутбуке под netbsd -- драйверов под какие попало там нет.

А так конечно как игрушка прикольное -- может собрать себя с нуля (почти) в любой хостовой оси, например.

HDD будут "засыпать" и стартовать при обращении к ним, это даёт неприятную задержку в пару секунд

  1. hdparm может настроить диски при стартапе, в т.ч. время, после которого они останавливаются (или не останавливаются вообще)

  2. можно раз в 10 минут простым скриптом на питоне вычитывать рандомный сектор с каждого диска, что не даст им заснуть.

от только пробка возникает не из-за узости дорог, а из-за того, что многим людям нужно одновременно попасть в одно и то же место.

Ook. Аффтору в голову не пришло, что парковки для "летающих машин" можно распределять по этажам зданий, например через каждые 10 этажей. И по длине зданий, если они допустим в длину тоже километры. Итого, байка в стиле "через 50 лет улицы Лондона покроются 9-футовым слоем навоза из-за огромного количества конных экипажей".

Но допустим это -- проблема. Далее аффтор пишет, что:

Один поезд метро или электробус с выделенной полосой перевозит больше людей, чем десятки «воздушных этажей», забитых персональными аппаратами. Развитие скоростного общественного транспорта — это умножение пропускной способности в чистом виде.

Ну и что же, пользователям скоростного общественного транспорта не бывает надо одновременно попасть в одно и то же место или одновременно ехать в одном и том же направлении? Давайте посмотрим на ст. м. Выхино утром в будни. Или вспомним о профессии заталкивателя людей в поезда в Японии.

Итого, просто опять урбанутые вопли "частный транспорт ненужен111, пользуйтесь общественным111", и даже нетрудно догадаться в пользу кого. Вот например если завтра запретят любой частный некоммерческий транспорт, чем придётся пользоваться? Общественным, такси, арендованным.

Можно поинтересоваться, о каком автомобиле и двигателе идет речь, который за час потребляет почти 55 литров бензина?

Лиаз-677 наверное. Который с бутылочками :)

upd: правда не в час, а на 100 км.
Из того, что в голове вертится -- 50 литров в час это какой-нибудь вертолёт с ДВС типа R-44

Дык некоторые программисты любят разглагольствовать, мол В/О им не нужно. А это -- результат того "ненужно" :)

Если механическая мощность мотора 100 кВт, то тепловая - 400 кВт

допустим 400. Но какая часть из этого тепла выводится с выхлопом, а какая в охлаждайку?

Тепловая мощность печки - 3...4 кВт, что составляет примерно 1% от тепла, производимого двигателем.

Как вам уже сказали, двигатель не 100% времени работает на максимуме оборотов с максимальным моментом (условие выдачи максимальной мощности)

Более типичная ситуация медленного перегрева -- это какое-нибудь стояние в пробке, и тогда 3-4 кВт печки уже могут оказаться 10-20 процентами и таки повлиять.

На основной радиатор идет шланг толщиной с кулак

И что с той толщины, если допустим радиатор сильно грязный или термостат не открывается полностью?

Чем умнее и образованнее человек, тем в более сложных вещах он заблуждается)

Лучше и не скажешь ;) Но вам ещё есть куда образовываться.

если у вас несколько независимых кешей, а выше них ничего нет (оперативка), то обычно когерентность делается либо снупингом (операции одного кеша c озу предварительно запрашивают все остальные кеши на предмет пересечений), или же поддерживается центральная "директория", которая хранит, какие кеш-линии и в каких состояниях (те самые modified-exclusive-shared-invalid) находятся во всех кешах. Просто так оперативку никто дёргать при конфликтах не будет, кеши между собой гонять будут эксклюзивную кеш-линию скорее.

Приведённый код работает для всех вообще констант. lui/addi для младшей части (конструируется в a0) будет с расширенным знаком, т.е. биты 63..32 могут быть единичные. Если такое происходит, в старшей части (a5) надо собрать число на единичку больше.

Прикол, менты полиционеры тоже читают хабр!

1
23 ...

Информация

В рейтинге
4 785-й
Зарегистрирован
Активность