Именно, но сложные команды x86 декомпилируются в поток в поток простых RISC, который затем исполняется параллельно несколькими блоками. Во что декомпилировать ARM? Оптимизировать и параллелить сразу его инструкции? Эффективнее будет несколько ядер поставить :)
Ну, наличие такого ПО будет косвенной уликой, которой однозначно не достаточно. Вот в совокупности с другими уликами она может быть принята во внимание.
Можно просто сделать невидимый полностью шифрованный раздел раздел и пусть доказывают, что это шифрованный раздел. А доказательством будет только его расшифровка, т.к. загрузчик это ни разу не доказательство — поставили шифрование, а потом шифрованный раздел убили и теперь там глубоко случайные данные — пойди докажи обратное. А сомнения, как известно, должны трактоваться в пользу обвиняемого.
На том, что Вы не обязаны свидетельствовать против себя и не обязаны доказывать свою невиновность — наоборот, следствие должно доказать Вашу вину. Вот пусть и доказывает. А Вы ключей не помните и не вспомните, потому, как там на диске лежит Ваше признание в административном правонарушении со штрафом в триста рублей, в которым Вы категорически отказываетесь сознаваться.
Видел, но объём написанного кода и сложность программы суть есть объективная реальность :)
два раза на спор писали программы Qt против Delphi на время — написать не сложное гуёвое приложение на время. Оба раза разработка приложения на C++ занимала больше времени, получался более сложный код и нативность и юзабелость на дельфях получалась лучше — было время даже реализовать всякие плюшки, вроде всплывающих подсказок, дополнительных статус баров и т.п.
Используют по причине достаточной мощности при хорошем быстродействии и могучей вижуальности при возможночти написания нативного приложения. А Вы что предлагаете?
Java? Необходима JRE. Нет или затруднён доступ к нативным функция оси — COM, железо, API и т.п.
С++? Необходимо писать в разы больше кода — больше трудоёмкость и трудно с вижуальностью.
.NET? Ну, не плохая альтернатива, но не позволяет писать самодостаточные приложения — приносишь на систему и оказывается, что нужно 200 метров .NET тащить, а потом ещё и интернет подключать для обновления.
Собственно всё :)
Преимущество современных x86 в том что НЕСКОЛЬКО инструкций выполняется за такт :) Ибо многоконвейерность и динамическая перекомпиляция :) Реализовать это для ARM можно, но сложнее — слишком много регистров и и инструкции, в большинстве своём простые — некуда их рекомпилировать. И ковейер сильно не удлинишь — инструкции будут перекрываться и и толку от конвейера будет мало. Проще и эффективнее применять оптимизацию на кровне компилятора компилятора, но как показывает опыт Itanuim — с компиляторами и оптимизацией обычного кода (не математики) как-то прогресс встал. Получается проще и эффективнее для ARM просто увеличивать количество ядер на кристале. Но тогда упираемся в шину, кеши и межпроцессорный обмен. Плюс грабли с софтом — распараллеливание кода нынче хоть и модно, но только набирает обороты.
В общем, получается, что с ARM и прочим RISC не всё так просто и радужно. Потому и не родился ещё «убийца x86» — все сравнимое по производительности получается или дорого, или сложно (и дорого).
Никогда не понимал, что мешает сканер отпечатков приделать.
Чтобы не программно драйвером, а аппаратно в самой флэшке. С возможностью программной разблокировки по длинному и секретному коду программно (на случай, если владелец палец порезал :).
Уверен, что спрос был бы. Сам пользую truecrypt, но было бы удобнее получить аппаратное решение — дёшево и сердито :)
И снова на арене недодизайнеры!
Без доступа воздуха щётка не просохнет и там заведутся страшные анаэробные бактерии и плесень!
Жуть и ужас — гики плюются зубами, но упорно покупают футляр для щётки с повышенной пулестойкостью.
Помнится были в инете публикации, что излучением при низких температурах удавалось заставить аппаратные Intell'овские ГСЧ (которые в hub) генерировать предсказуемую последовательность.
Так что, не всё просто с триггерами :)
А ничего :) Входное сопростивление чудо-телефона соответствует допустимому?
Если нет и заметят — отключат.
Более того, на АТС стоит защита от КЗ и если потребляемый ток в течении 30 сек превышает макимальный, то абонентский комплект отключается.
8 ярких светодиодом — это ~400мВт потребления при очень оптимистичном раскале. При том, что в норме телефонная линия может выдать 175..525 мВт. Т.е. очень близко к пределу или даже превышает его. Отсель мораль — при параллельно подколюченном телефоне, однозначно выйдете за допустимые пределы, а если только лампу втыкать, то как повезёт.
Угу, а потом на АТС по какой-нибудь причине проверяют ваш абонентский комплект и линию, видят потребляемый ток и отрубают телефон. Ибо в договоре ясно написанно, что именно можно втыкать в телефонную розетку.
Ну, тогда отошлите аналогичный по значимости баг-репорт какой-нибудь альтернативной ОС и иофисному пакету. Особенно бесплатной :) Внуки ваши ещё ждать будут :)
два раза на спор писали программы Qt против Delphi на время — написать не сложное гуёвое приложение на время. Оба раза разработка приложения на C++ занимала больше времени, получался более сложный код и нативность и юзабелость на дельфях получалась лучше — было время даже реализовать всякие плюшки, вроде всплывающих подсказок, дополнительных статус баров и т.п.
Java? Необходима JRE. Нет или затруднён доступ к нативным функция оси — COM, железо, API и т.п.
С++? Необходимо писать в разы больше кода — больше трудоёмкость и трудно с вижуальностью.
.NET? Ну, не плохая альтернатива, но не позволяет писать самодостаточные приложения — приносишь на систему и оказывается, что нужно 200 метров .NET тащить, а потом ещё и интернет подключать для обновления.
Собственно всё :)
В общем, получается, что с ARM и прочим RISC не всё так просто и радужно. Потому и не родился ещё «убийца x86» — все сравнимое по производительности получается или дорого, или сложно (и дорого).
Чтобы не программно драйвером, а аппаратно в самой флэшке. С возможностью программной разблокировки по длинному и секретному коду программно (на случай, если владелец палец порезал :).
Уверен, что спрос был бы. Сам пользую truecrypt, но было бы удобнее получить аппаратное решение — дёшево и сердито :)
Без доступа воздуха щётка не просохнет и там заведутся страшные анаэробные бактерии и плесень!
Жуть и ужас — гики плюются зубами, но упорно покупают футляр для щётки с повышенной пулестойкостью.
Так что, не всё просто с триггерами :)
Если нет и заметят — отключат.
Более того, на АТС стоит защита от КЗ и если потребляемый ток в течении 30 сек превышает макимальный, то абонентский комплект отключается.
8 ярких светодиодом — это ~400мВт потребления при очень оптимистичном раскале. При том, что в норме телефонная линия может выдать 175..525 мВт. Т.е. очень близко к пределу или даже превышает его. Отсель мораль — при параллельно подколюченном телефоне, однозначно выйдете за допустимые пределы, а если только лампу втыкать, то как повезёт.