В районе 9ого квартуса они поняли, что надо нормально поддерживать линукс, вот сейчас начинают сворачивать поддержку венды (всл означает ровно одно — у вас теперь работают линуксовые, а не вендовые бинари). Пора и вам шагнуть в правильном направлении.
Не защищаю яндех, но некоторое время назад ихняя веб-почта позволяла регать аккаунты из-под тора без никаких 'введите другое емыло или номер телефона для проверки кода'. Как сейчас — не знаю, давно не приходилось.
нет, если взять Termux. Это не ssh-клиент, а просто терминал и юзерспейс линукса (не требующий рута), с пакетным менеджером apt и кучей софта. Ставите туда ssh-клиент и далее как обычно ssh user@host -L3389:localhost:3389
А юзеры яблок пусть страдают :)
Правильно ли я понимаю, что в данном случае не только можно восстановить данные на сломавшемся носителе, но и задетектить случай, когда носитель как бы нормальный, работает, но данные испортил? Ну или если кто-то ещё подгадил: ошибка передачи по сети, глючное железо и т.д.
Общий ущерб экономике Эстонской ССР в период немецкой оккупации оценивается в 16 млрд. советских рублей (в довоенных ценах), здесь были разрушены 45% промышленных предприятий и 50% жилых домов
В 1970-е — 1980-е годы Эстония фактически находилась на первом месте в СССР по объёму инвестиций в основной капитал на душу населения
Для стирания рекомендую лампочки с али: искать по "E17 UV bulb". Выглядят как обычная лампа накаливания с 2 перекрещенными спиралями внутри. Сначала накаляются спиральки, потом между ними загорается разряд. Ту ПЗУшку, которую я пробовал ими стирать, они тёрли за 5 минут, будучи приложенными вплотную к окошку.
Но есть и особенности:
Такие лампы требуют кормить их определённым (300 ма) стабилизированным током. Можно от лаб. БП, можно от LM317 по схеме стабилизации тока, можно из розетки через гасящий кондёр или дроссель. При этом вначале (спиральки нагреваются) напряжение на них около 15-16 вольт, а потом (заряд загорелся) падает до ~12 вольт.
Эти лампочки ОЧЕНЬ сильно пахнут озоном (а как известно, если озоном пахнет, то его ПДК уже превышено), так что использовать их в жилых помещениях не очень.
Под ними не стоит загорать, т.к. они светят довольно коротковолновым УФ.
Вот тут на странице 34 говорится, что макс. время каждого полупериода клока — 2 мкс. Соответственно, 100 кГц или внезапные паузы в тактировании могут оказаться слишком долгими и как результат — глюки. Самое простое, пожалуй, это вернуть CMOS Z80 (Z84C****), который полностью статический.
с какой частотой на нём идут импульсы, когда ардуна клочит проц, и какой длительности паузы бывают? Я это к тому, соблюдаются ли мин. и макс. ограничения на длительность полупериодов? Ограничение на макс. полупериоды важно для NMOS Z80 (который на фоткаx: Z0840004), т.к. он построен на динамической логике и может 'забыть' своё состояние со слишком длинными паузами в тактировании. Ограничение на мин. период (макс. частоту) думаю понятно.
AES делают потому, что он плохо ложится на обычные команды процессора (приходится или табличками, что чревато атаками через кеш, или же долгими и нудными расчётами мультипликативной обратной величины). А чача хорошо ложится на SIMD, как и SHA-3 в общем-то.
Нумерация битов в слове не имеет никакого отношения к порядку байт того же слова в памяти. И что в ibm360 и всех последующих, а также в powerpc нумерация битов со старшего разряда — это конечно дремучий трындец.
тут интересный вопрос, что именно делает ARM — RISC'ом. если его называть load/store архитектурой — то всё верно. а c очень уж расплывчатым понятием "RISC" как быть?
Были архитектуры, где правильно выбранный порядок байт упрощал или ускорял работу процессора. Были — где наоборот, замедлял. И были же — те, где на него пофиг было процессору. примеры:
pdp-11: процессор 16-битный и слова всегда выровнены по 2 байта. на порядок байт в слове пофиг, сделали LE.
i8080: процессор 8-битный, но читает 16-битные слова всегда как 2 подряд идущих байта. тоже на порядок байтов пофиг, сделали LE
mc6800 (не путать с mc68000!). 8-битный, порядок байт BE. за что расплата лишним тактом в адресации типа LDA ADDR,X, где процессор побайтно читает 16-битное число, прибавляет к нему 8-битный индексный регистр и с полученным адресом выходит на шину прочитать аргумент. порядок байт выбран неправильно (почему — см. ниже)
6502! идеологически похож на 6800, порядок байт LE. благодаря этому, в описанном в п.3 случае читает сначала младший байт, потом во время чтения старшего — одновременно прибавляет к уже прочитанному индексный регистр. и если нет переноса в старшую часть, то на шину выходит сразу же, не тратя дополнительный такт. порядок байт выбран верно!
ну и соглашусь, что уже в i8086, mc68000 и далее — порядок байт перестал играть какую-либо роль. например архитектура ARMv7A позволяет переключать порядок байт прям в пользовательской программе, инструкциями SETEND BE/LE.
Такая уязвимость ничего не может сделать против банального включенного iommu в процессоре. Его что, оси, указанные в статье как поломанные — не используют? Вот это настоящий fail, а не дыры одного из многих контроллеров, которые умеют dma в хостовую память.
В статье увидел в недостатках 'плохой pf'. Когда говорят, что это недостаток, стоит понимать — это не есть недостаток для конечного потребителя (ну по крайней мере пока ваши счётчики не начисляют вам деньги за плохой pf). Если на контору начисляют деньги за это — ну ок, им есть смысл стремиться улучшить pf. Обычным домашним пользователям — нет смысла, ни в лампочках, ни в БП комповых и указывать это как недостаток стоит как минимум с этой оговоркой. Что такое pf — https://en.wikipedia.org/wiki/Power_factor .
Вариант со стабилитронами вполне нормальный для преобразования сигналов 5в в 3.3в. В обратную сторону, кстати, совершенно законно подавать сигнал с лог.1 в 3.3 вольта на вход ТТЛ-микросхемы и никаких компараторов не нужно. Пороговый уровень для лог.1 у ТТЛ-микросхемы составляет 2.4в, что меньше, чем выдаваемые карточкой 3.3 вольта.
Простите, аффтар, вы ПРИНЦИПИАЛЬНЫЕ СХЕМЫ умеете рисовать? Это вас в ардебилино-сообществах научили вместо чтоб нарисовать обычную и всем понятную схему — копипастить распиновку микросхемы и подписывать куда это якобы подсоединено? А потом еще портянку текста писать о том же:
В нашем случае, мы подключаем сам декодер следующим образом: старший бит (3я нога) к земле, там всегда будет 0.
Правильно ли я понимаю, что это относится к чисто 32-битной сборке (когда и ядро и юзерспейс 32-битные), а просто 32-битные либы как в макосе не выпилили?
спасибо. правильно ли я понимаю, что ваши измерения скоростей сделаны на кусках по 8 килобайт? возможно, если вы возьмёте например 8 мегабайт, вы приблизитесь к 25 мегабитам (исходя из скорости SPI-интерфейса), как минимум на чтении (т.к. скорость записи может ограничиваться неидеальностью SD-карты как микро-пародии на SSD :))
Bы не правы. B linux например, даже 32битном, все .so (динамические библиотеки, аналог .dll в шиндошс) компилируются с флагом -fPIC (position-independent code) и не нуждаются в релокации при маппинге в разные виртуальные адреса каждому процессу. Tак что это сугубо вендовая недоработка.
Kак следствие, в linuxе одна и та же soшка может подставляться любому процессу в любые его вирт. адреса из одних и тех же физических страниц памяти.
не очень понял из кода: использовались команды чтения/записи по 1 сектору или по много подряд? во 2 случае достаточно задать начальный сектор и лить данные сколько надо.
Правильно ли я понял, как работает эта самая короткая программа? Она узнаёт остаток и частное от деления числа на 10 методом вычитания этих самых десяток? И если например у нее на входе будет 30000 то она будет заниматься вычитаниями 3 тысячи раз, в первом проходе по большому циклу? И сколько это времени займёт? Полсекунды на БК? Может, действительно такая процедура самая короткая, но в реальной жизни неприменима.
Ещё один пример в тему некоторых комментов. Понадобилось на древнем дистрибе убунты завести свежую вайфайку. Из сорцов, с некоторыми танцами с бубнами, удалось собрать рабочий модуль ядра. А теперь заведите в ХР (да чо там, в семерке хотя бы) то, подо что есть дрова только для 10ки. И во всех случаях, когда надо что-то собрать из сорцов — линукс как система (дистрибутив) — рулит. Ну например, надо собрать kicad — пожалуйста, наставил пакетов, собрал, работает. С ужасом представляю себе процесс установки в венде всей той кучи инклудов для сборки кикада.
Крыло самолета, создающее подъемную силу, обладает сопутствующим, можно сказать, негативным побочным продуктом в виде пикирующего момента, стремящегося ввести самолет в пикирование.
Извините, но нет. Есть центр давления (на крыло, но не только) и центр тяжести. Если центр тяжести находится впереди центра давления (это требование ко всем гражданским самолётам), то ессно без хвостового оперения такой самолет будет пикировать, но ровно из-за положения центра тяжести, а не из-за каких-то мнимых побочных продуктов. Так делают потому, что добавление хвостового оперения делает такой самолёт устойчивым. В начале развития авиации были аэродинамические схемы с центром тяжести позади центра давления, и тогда самолёт получался неустойчивым. А никаких "побочных продуктов" крыла вовсе нет.