Глядя на список поддерживаемых форматов, можно заметить, что по факту в приложении можно проиграть лишь файлы с видеокодеком H.264 и аудиокодеком FLAC либо MP3.
Это не такая уж большая проблема. Вы же не всеядный плеер изобретаете, а фактически инструмент для обучения
Можно перед просмотром перекодировать в поддерживаемый видео-аудио формат (ffmpeg'ом, например).
Нет на CD дублирования, там размазывание данных. Т.е. при ошибке чтения одного сектора ошибка «размазывается» по части данных из нескольких соседних секторов — а поскольку они защищены кодами Рида-Соломона, восстановить их не проблема. В результате даже при ошибке чтения нескольких подряд идущих секторов данные еще можно восстановить (если я правильно помню, длина царапины при этом может достигать нескольких миллиметров).
Во-первых, бэкапить с ключами -t (test files after archiving) и -ilog[error.log] (write errors to log file).
Во-вторых, периодически посматривать в лог ошибок. Если там сплошные «access denied» и «file not found» — это терпимо (когда бэкапим прямо на работающей системе). А вот если там вылазят ошибки CRC — это сигнальчик, что бэкапы битые.
У меня такое было, когда начала сбоить одна из планок памяти.
Нет. На АРМах обычно стоят видеоускорители семейства Mali, и с ними проблем как-то нет. Можно относительно без напряга найти, например, драйвера с поддержкой OpenCL и поиграться с вычислениями.
А на распберри стоит некое VideoCore — драйвера на него довольно специфичные.
Ну так-то raspberry pi 4 стоит недорого — навскидку, тыщ за 6-8 с алиэкспресса можно заказать набор «малина-корпус-радиаторы-карточка-блок питания». Можно взять для экспериментов и посмотреть, тянет ли оно нужные задачи.
Можно и с ОСями поэкспериментировать, т.к. есть 64-битные дистрибутивы, которые можно развернуть на малине. Тогда будет доступ ко всей памяти, но могут появиться тормоза в ютубе: у малинки специфичный видеоускоритель, и не во всех осях он работает.
Так а вы с какой целью девайс приобретаете? Если в качестве замены десктопу, то будет подтормаживать в любом случае — процессоры на бордах все-таки не топовые.
А для 8 Гб памяти нужно еще суметь поставить 64-битную ОСь. Скажем, на распберри паях до сих пор официальный дистрибутив Rasbian — 32-битный, так что от 8 гигов памяти толку будет немного.
Лично мне бы интересно было увидеть тематический разбор имеющихся одноплатников.
Скажем, какой из имеющихся подойдет в качестве NAS? И подробненько — какие варианты возможны с какой платой, сколько у кого портов, нет ли просадок по скорости, есть ли встроенный вайфай, имеются ли готовые корпуса и т.п.
Аналогично — для ТВ-бокса: потянет ли плата вывод в 4К, сможет ли при этом тянуть стрим из сети, да еще и по вайфайке… Есть ли неколхозные корпуса, да еще чтоб не перекрывали встроенную антенну.
Или вот принт-сервер на чем лучше организовать. Чтоб был мелкий, без лишних разъемов, но при этом желательно с вайфаем. И чтоб не перегревался. И чтоб корпус был уже готовый доступен.
А так получается репортаж из супермаркета: «Вот огурцы, сорт ZimaBoard зимний. Они хороши в салат, но запекать в духовке их не надо. А вот яблоки Джетсон Нано Джонагольд, они в салате не очень, зато их можно запекать с корицей».
Убедитесь, что входные хеши имеют совместимый с hashcat формат.
А какой у hashcat формат-то? А то вы пять раз одно и то же повторили, но непонятно зачем.
И вообще вы как-то обошли стороной самое главное — зачем может понадобиться эта утилита? Вот вы долго и муторно рассказываете, как ломать MD5, но ни слова не сказали о том, откуда эти хэши, собственно, возьмутся.
Если бы в статье были реальные сценарии использования, а не куски мануала, статья имела бы ценность. Скажем, вот сейчас будем ломать /etc/passwd, а вот сейчас поломаем пароль от вайфая из дампа airodump-ng…
Если внимательно посмотреть на замкнутые острова — то вполне может быть остров, где нет наземных животных, кроме перелетных птиц, может быть остров, где нет крупных хищников, опасных местным травоядным. То есть хищники вообще-то не обязательный этап эволюции.
Вы как-то очень лихо уравниваете эволюцию и экосистему островов. :)
Если успеют, если так рассуждать раз появился такой умный суперхищник, как человек, никто не мешал остальным зверям эволюционировать и стать не менее умными.
Это немножко не так работает. Слишком успешный хищник вымирает из-за того, что слишком успешно выедает всю кормовую базу.
Достаточно часто какой-то вид вдруг перестает иметь естественных врагов в принципе, потому что его враги не успели приспособится к его защите.
Мы ушли куда-то в сторону.
Скажем так:
— Плотоядность — это тип питания, который позволяет организмам получать больше энергии, затрачивая меньше усилий. По сравнению с травоядностью он более выгоден, следовательно, в процессе эволюции рано или поздно могут возникнуть плотоядные организмы (падальщики, а за ними и хищники).
Но есть несколько «но».
1. Все это справедливо для Земли. Не факт, что на других планетах жизнь будет строиться на тех же химических реакциях — может, там наиболее энергетически выгодно будет жрать местные одуванчики.
2. Не факт, что на других планетах жизнь вообще будет разделяться на растительную и животную. Может, там мыслящая грибница.
3. Эволюция — не панацея. Это на Земле эволюция привела к появлению более-менее развитых организмов (да и те через одного пишут с ошибками). На других планетах, возможно, дальше бактериальных матов дело не пойдет. Например, будут слишком частые глобальные катаклизмы, которые повыбивают все сложные организмы, или наоборот — не будет ни единого катаклизма и экосистема законсервируется в равновесии.
Где это доказано для любой возможной инопланетной экосистемы? Представим, что все травоядные смертельно ядовиты, вот абсолютно, откуда тут взяться хищникам?
Почему у вас только хищники обделены? Представим, что все растения ядовиты, вот абсолютно все — откуда тут взяться травоядным? :)
А если серьезно, то ядовитость не появляется сама по себе — это защитный механизм. Организму, у которого нет врагов, ядовитость не нужна. Ядовитым организмам приходится чем-то жертвовать: например, подстраивать метаболизм под имеющийся в организме яд так, чтобы не травиться, или отращивать защитные покровы, чтобы яд не проникал в жизненно-важные части организма. Если врагов нет, то и ядовитость становится обузой.
А если враги есть, то им ничто не мешает адаптироваться для поедания ядовитых организмов: раз сам ядовитый организм смог адаптироваться к собственному яду, то и хищник сможет «отрастить» аналогичную адаптацию.
Но убеждать меня в том, что он глючит и плохо работает, а ближаший апдейт CentOS'а — рассыпется, немного странно.
Немного странно то, что вы мне приписываете слова, которых я не говорил. Можно цитату, где я вас убеждаю, что UPX глючит и плохо работает?
Я говорю, что использование UPX потенциально может привести к проблемам. UPX работает на низком уровне и заменяет собой системный загрузчик — очевидно, если логика работы системного загрузчика поменяется, то и программы, ужатые UPX, перестанут запускаться. По-моему, это очевидно и спорить тут не о чем.
Однако, из-за парадокса дней рождений, если высчитать 2^(128/2) хешей то вероятность найти одну коллизию уже заметно отлична от 0.
2^64 это, впрочем, пока еще дофига.
Так 2^64 или 2000 итераций нужно, чтобы наткнуться на коллизию? Вы уж определитесь. :)
Что такое коллизия?
Это когда два разных пароля дают одинаковый хеш.
Один пароль у нас «хэш1+хвост», второй — «хэш2+хвост». В результате получаются одинаковые хэши3 — т.е. коллизия.
Почему вы думаете, что «хэш3+хвост» аннулирует предыдущую коллизию? Хвост-то у нас константный.
В контексте Linux-серверов меня опять таки это не беспокоит. Но на Windows, да, этот момент более актуален.
Вы забыли ключевое слово «пока».
Пока что да, на линуксе и антивирусы-то редко ставят. Но у меня был неприятный опыт, когда на сервере стоял, кажется, Касперский для линукс. Он упорно удалял один из скриптов на перле, считая его вирусом — в результате у клиентов не обновлялась статистика в личном кабинете. Пришлось бодаться с сисадмином, которому синдром вахтера не давал прописать исключения в конфиг.
На счет глючить — скорее, нет. Упаковщик не меняет ваш код.
Бгг.
Сам-то код не трогает, а вот релокейшены по всему коду фиксит.
Распаковщику приходится брать на себя функции системного загрузчика. А там, поверьте, мрачно, есть где запутаться и напортачить в коде. Тем более что код кроссплатформенный и не везде одинаково хорошо протестирован.
Потенциальное место для новых проблем — лишь сам код распаковки.
Не-а. Обновляются операционки, чуть-чуть меняется логика работы системного загрузчика — этого может быть достаточно для того, чтобы ВСЕ ваши упакованные бинари вдруг перестали запускаться на определенной системе.
И да, в упаковщиках тоже могут быть ошибки.
Есть ссылки на какие-то исследования по этому? Мне кажется там даже больше.
Исследования есть на поиск коллизий — но ЕМНИП, там размер хэшируемого сообщения как минимум в 2 раза больше размера хэша MD5.
Мой скептицизм строится на знании устройства MD5: там по факту перемешивание бит исходного сообщения, т.е. для сообщений размером, равным размеру хэша, коллизий вообще не должно быть. Но я вполне допускаю, что чего-то не учитываю и они таки есть — в любом случае, их количество далеко от 5%.
Если бы 5% хэшей совпадали, достаточно было бы высчитать пару миллионов хэшей и сравнить их между собой. В среднем процент совпадений был бы все тем же — 5%, верно? И чем больше выборка, тем точнее будет процент. Так вот, я пробовал гонять такой тест (и на бОльших выборках) — ни единой коллизии не обнаружено.
Это НЕ так для PBKDF2. Потому что они на каждом раунде примешивают пароль. То есть даже если на каком-то раунде будет коллизия, она перестанет быть коллизией на следующем.
Платой за компактный размер будет время на запуск, так как предварительно требуется распаковка.
Это только самое очевидное. А вот вам еще немножко очевидностей до кучи:
1. Плата за упаковщих — это повышенный расход оперативной памяти. Упаковщик сначала распаковывает весь код в память, потом передает ему управление. Т.е. в памяти будут как остатки распаковывающего кода, так и весь код программы.
При нормальной работе программы в память грузятся только те страницы памяти, к которым осуществляется доступ (т.к. практически все ОС используют memory mapping для загрузки исполняемых файлов в память).
2. Плата за упаковщик — срабатывание эвристического анализатора у некоторых антивирусов. Причем срабатывать может не на все версии программы, а только на некоторые билды. С точки зрения антивируса упаковщик занимается подозрительными вещами — раскладывает данные по памяти и передает им управление, да еще и манипулирует атрибутами страниц памяти.
3. Плата за упаковщик — повышенный риск глюков. Упаковщик тоже не боженька писал, в нем возможны ошибки. В результате программа может глючить или вообще не запускаться на некоторых машинах.
4. Нужно еще суметь правильно вкрячить упаковщик в систему сборки (это, наверное, не про go, но все-таки). Если у вас на каждый чих запускается upx и пять секунд пакует бинарь, на двадцатый раз вы будете тихо ненавидеть этот ползущий индикатор. :)
Это не такая уж большая проблема. Вы же не всеядный плеер изобретаете, а фактически инструмент для обучения
Можно перед просмотром перекодировать в поддерживаемый видео-аудио формат (ffmpeg'ом, например).
Во-вторых, периодически посматривать в лог ошибок. Если там сплошные «access denied» и «file not found» — это терпимо (когда бэкапим прямо на работающей системе). А вот если там вылазят ошибки CRC — это сигнальчик, что бэкапы битые.
У меня такое было, когда начала сбоить одна из планок памяти.
А на распберри стоит некое VideoCore — драйвера на него довольно специфичные.
Действительно есть, и уже активирован.
Можно и с ОСями поэкспериментировать, т.к. есть 64-битные дистрибутивы, которые можно развернуть на малине. Тогда будет доступ ко всей памяти, но могут появиться тормоза в ютубе: у малинки специфичный видеоускоритель, и не во всех осях он работает.
А для 8 Гб памяти нужно еще суметь поставить 64-битную ОСь. Скажем, на распберри паях до сих пор официальный дистрибутив Rasbian — 32-битный, так что от 8 гигов памяти толку будет немного.
Скажем, какой из имеющихся подойдет в качестве NAS? И подробненько — какие варианты возможны с какой платой, сколько у кого портов, нет ли просадок по скорости, есть ли встроенный вайфай, имеются ли готовые корпуса и т.п.
Аналогично — для ТВ-бокса: потянет ли плата вывод в 4К, сможет ли при этом тянуть стрим из сети, да еще и по вайфайке… Есть ли неколхозные корпуса, да еще чтоб не перекрывали встроенную антенну.
Или вот принт-сервер на чем лучше организовать. Чтоб был мелкий, без лишних разъемов, но при этом желательно с вайфаем. И чтоб не перегревался. И чтоб корпус был уже готовый доступен.
А так получается репортаж из супермаркета: «Вот огурцы, сорт
ZimaBoardзимний. Они хороши в салат, но запекать в духовке их не надо. А вот яблокиДжетсон НаноДжонагольд, они в салате не очень, зато их можно запекать с корицей».А какой у hashcat формат-то? А то вы пять раз одно и то же повторили, но непонятно зачем.
И вообще вы как-то обошли стороной самое главное — зачем может понадобиться эта утилита? Вот вы долго и муторно рассказываете, как ломать MD5, но ни слова не сказали о том, откуда эти хэши, собственно, возьмутся.
Если бы в статье были реальные сценарии использования, а не куски мануала, статья имела бы ценность. Скажем, вот сейчас будем ломать /etc/passwd, а вот сейчас поломаем пароль от вайфая из дампа airodump-ng…
Вы как-то очень лихо уравниваете эволюцию и экосистему островов. :)
Это немножко не так работает. Слишком успешный хищник вымирает из-за того, что слишком успешно выедает всю кормовую базу.
Мы ушли куда-то в сторону.
Скажем так:
— Плотоядность — это тип питания, который позволяет организмам получать больше энергии, затрачивая меньше усилий. По сравнению с травоядностью он более выгоден, следовательно, в процессе эволюции рано или поздно могут возникнуть плотоядные организмы (падальщики, а за ними и хищники).
Но есть несколько «но».
1. Все это справедливо для Земли. Не факт, что на других планетах жизнь будет строиться на тех же химических реакциях — может, там наиболее энергетически выгодно будет жрать местные одуванчики.
2. Не факт, что на других планетах жизнь вообще будет разделяться на растительную и животную. Может, там мыслящая грибница.
3. Эволюция — не панацея. Это на Земле эволюция привела к появлению более-менее развитых организмов (да и те через одного пишут с ошибками). На других планетах, возможно, дальше бактериальных матов дело не пойдет. Например, будут слишком частые глобальные катаклизмы, которые повыбивают все сложные организмы, или наоборот — не будет ни единого катаклизма и экосистема законсервируется в равновесии.
Почему у вас только хищники обделены? Представим, что все растения ядовиты, вот абсолютно все — откуда тут взяться травоядным? :)
А если серьезно, то ядовитость не появляется сама по себе — это защитный механизм. Организму, у которого нет врагов, ядовитость не нужна. Ядовитым организмам приходится чем-то жертвовать: например, подстраивать метаболизм под имеющийся в организме яд так, чтобы не травиться, или отращивать защитные покровы, чтобы яд не проникал в жизненно-важные части организма. Если врагов нет, то и ядовитость становится обузой.
А если враги есть, то им ничто не мешает адаптироваться для поедания ядовитых организмов: раз сам ядовитый организм смог адаптироваться к собственному яду, то и хищник сможет «отрастить» аналогичную адаптацию.
150 тысяч. 2 миллиона лет назад только эректусы появились, но вряд ли можно их считать цивилизацией.
Немного странно то, что вы мне приписываете слова, которых я не говорил. Можно цитату, где я вас убеждаю, что UPX глючит и плохо работает?
Я говорю, что использование UPX потенциально может привести к проблемам. UPX работает на низком уровне и заменяет собой системный загрузчик — очевидно, если логика работы системного загрузчика поменяется, то и программы, ужатые UPX, перестанут запускаться. По-моему, это очевидно и спорить тут не о чем.
Так 2^64 или 2000 итераций нужно, чтобы наткнуться на коллизию? Вы уж определитесь. :)
Один пароль у нас «хэш1+хвост», второй — «хэш2+хвост». В результате получаются одинаковые хэши3 — т.е. коллизия.
Почему вы думаете, что «хэш3+хвост» аннулирует предыдущую коллизию? Хвост-то у нас константный.
Вы забыли ключевое слово «пока».
Пока что да, на линуксе и антивирусы-то редко ставят. Но у меня был неприятный опыт, когда на сервере стоял, кажется, Касперский для линукс. Он упорно удалял один из скриптов на перле, считая его вирусом — в результате у клиентов не обновлялась статистика в личном кабинете. Пришлось бодаться с сисадмином, которому синдром вахтера не давал прописать исключения в конфиг.
Бгг.
Сам-то код не трогает, а вот релокейшены по всему коду фиксит.
Распаковщику приходится брать на себя функции системного загрузчика. А там, поверьте, мрачно, есть где запутаться и напортачить в коде. Тем более что код кроссплатформенный и не везде одинаково хорошо протестирован.
Не-а. Обновляются операционки, чуть-чуть меняется логика работы системного загрузчика — этого может быть достаточно для того, чтобы ВСЕ ваши упакованные бинари вдруг перестали запускаться на определенной системе.
И да, в упаковщиках тоже могут быть ошибки.
Исследования есть на поиск коллизий — но ЕМНИП, там размер хэшируемого сообщения как минимум в 2 раза больше размера хэша MD5.
Мой скептицизм строится на знании устройства MD5: там по факту перемешивание бит исходного сообщения, т.е. для сообщений размером, равным размеру хэша, коллизий вообще не должно быть. Но я вполне допускаю, что чего-то не учитываю и они таки есть — в любом случае, их количество далеко от 5%.
Если бы 5% хэшей совпадали, достаточно было бы высчитать пару миллионов хэшей и сравнить их между собой. В среднем процент совпадений был бы все тем же — 5%, верно? И чем больше выборка, тем точнее будет процент. Так вот, я пробовал гонять такой тест (и на бОльших выборках) — ни единой коллизии не обнаружено.
Здрасьте. А куда она денется?
Разве что использовали стильно-модно-молодежный XML.
Это только самое очевидное. А вот вам еще немножко очевидностей до кучи:
1. Плата за упаковщих — это повышенный расход оперативной памяти. Упаковщик сначала распаковывает весь код в память, потом передает ему управление. Т.е. в памяти будут как остатки распаковывающего кода, так и весь код программы.
При нормальной работе программы в память грузятся только те страницы памяти, к которым осуществляется доступ (т.к. практически все ОС используют memory mapping для загрузки исполняемых файлов в память).
2. Плата за упаковщик — срабатывание эвристического анализатора у некоторых антивирусов. Причем срабатывать может не на все версии программы, а только на некоторые билды. С точки зрения антивируса упаковщик занимается подозрительными вещами — раскладывает данные по памяти и передает им управление, да еще и манипулирует атрибутами страниц памяти.
3. Плата за упаковщик — повышенный риск глюков. Упаковщик тоже не боженька писал, в нем возможны ошибки. В результате программа может глючить или вообще не запускаться на некоторых машинах.
4. Нужно еще суметь правильно вкрячить упаковщик в систему сборки (это, наверное, не про go, но все-таки). Если у вас на каждый чих запускается upx и пять секунд пакует бинарь, на двадцатый раз вы будете тихо ненавидеть этот ползущий индикатор. :)