В рамках проекта Skein-Bash (http://sourceforge.net/projects/skeinbash/) создана (http://matt16060936.blogspot.com/2011/09/welcome-to-internet... реализация алгоритма хэширования Skein 512-512 (http://ru.wikipedia.org/wiki/Skein), выполненного полностью на языке командного интерпретатора Bash. Код (http://sourceforge.net/p/skeinbash/code/ci/ed9a27d0096e55408... занимает около 500 строк. На расчет одного хэша на современном ПК тратится около 10 секунд. Работа выполнена с целью популяризации алгоритма Skein, который в следующем году будет бороться за звание стандарта SHA-3. Разработка показала, что Skein может быть легко реализован для различных платформ и языков программирования.
URL: http://matt16060936.blogspot.com/2011/09/welcome-to-internet...
Новость: http://www.opennet.ru/opennews/art.shtml?num=31745
Прекрасная пурпуляризация! Ещё бы на брэйнфаке написали бы - вообще народ ломился бы!
> Прекрасная пурпуляризация! Ещё бы на брэйнфаке написали бы - вообще народ ломился бы!Модный тренд сегодняшнего дня - яваскрипт. Если поднапрячь моск - даже можно представить себе какую-то пользу от таковой. В отличие от баша. Ну, можно например браузеры на скорость JS бенчмаркать. Пустячок, а приятно :)
> Модный тренд сегодняшнего дня - яваскрипт.пока не стандартизируют функции связанные с двоичными данными в Javascript
( всё что витает около [нестандартизирвоанного, кстате] https://developer.mozilla.org/en/DOM/Blob )
-- ябы ОЧЕНЬ ОПАСАЛСЯ появления Javascript-библиотек связанных с двоичными данными :-) ..
в интернетах и так существует куча быдлокодерских javascript-поделок которые запихивают двоичные данные внутрь ТЕКСТОВОЙ СТРОКИ... на это без ужаса даже поглядеть в исходный код нельзя!
> пока не стандартизируют функции связанные с двоичными данными в JavascriptТипизированные массивы уже сделали. В принципе можно и без них, хоть и изврат.
> -- ябы ОЧЕНЬ ОПАСАЛСЯ появления Javascript-библиотек связанных с двоичными данными :-)
Ну если мне в браузер захотятя вгрузить нативный код аналогичный по смыслу, я еще больше опасаться буду :)
> в интернетах и так существует куча быдлокодерских javascript-поделок которые запихивают
> двоичные данные внутрь ТЕКСТОВОЙ СТРОКИ... на это без ужаса даже поглядеть
> в исходный код нельзя!Да я и не сомневаюсь что поделок масса :P. Тем не менее, как вы могли заметить, какойнить jslinux или doom на js вполне себе грузят бинарные файлы, декомпрессят данные и прочая.
Хорошая тенденция - переход с традиционных компилируемых языков на сценарии оболочки.Еще бы всякие coreutils и util-linux на шелле переписать. А то ведь, если захочешь поправить код, надо пересобирать - неудобно же.
zip.zip? :)
> zip.zip? :)(pk)unizip.zip забавнее :P
Насколько я помню, штатный бинарник программы upx, предназначенной для сжатия бинарного кода, сам является upx-сжатым =)
> Насколько я помню, штатный бинарник программы upx, предназначенной для сжатия бинарного
> кода, сам является upx-сжатым =)А gcc версии N сам собран gcc, версии N :). Это наш ответ барону Мюнхаухену :D.
и скорость торможения сразу вырастет в 200 раз
>и скорость торможения сразу вырастет в 200 разЗато удобство возрастет в 100500 раз, очевидно же! А лишняя пара секунд - кого она беспокоит?
два чаю этому адеквету. а еще надо бы переписать ядро на whitespace
> Зато удобство возрастет в 100500 раз, очевидно же! А лишняя пара секунд
> - кого она беспокоит?Капитан сообщает что пара секунд на маленьком файле легко станет парой часов на большом файле. А хешируют зачастую допустим ISO-sized файлы. Сколько бнопня на баше будет жевать стандартное DVD-ISO на 4.7 гига? Всего несколько суток, да? А скачаный дистр дебиана - будет проверяться примерно месяц? :)))
>Всего несколько суток, да? А скачаный дистр дебиана - будет проверяться примерно месяц? :)))Но зато какой выигрыш по гибкости и удобству модификации!
> Но зато какой выигрыш по гибкости и удобству модификации!Ну если вам это необходимо, в хешировалке файлов, на баше - пользуйтесь наздоровье. Хотя почему-то напоминает удаление гланд через ж-у автогеном.
по поводу удобства модификации - это был сарказм. КО.
Что очевидно же? Удобство возрастет? Если вам стиральную машинку сделать без корпуса и с ручным приводом удобство возрастет. Ее ведь так легко будет ремонтировать. Да и вообще она гораздо реже будет ломаться, т.к. обороты отжима будут гораздо меньше 10 тыс. Очевидно же.
Кстати, и все остальные бытовые приборы нужно сделать тоже с ручным приводом и без корпуса. Удобство возрастет в 100500 раз! Представляете как легко будет домохозяйкам ремонтировать эти приборы. Да и электричество не нужно совсем. Нужно просто бегать по квартире и крутить ручки. Кого беспокоят задержки в несколько секунд?
Вы не правы - ручной привод тоже не нужен, равно и приборы - достаточно одних хозяек!
И как часто ты поправлял код cd или ls?
> И как часто ты поправлял код cd или ls?К сожалению, очень часто не получается - не всегда есть время и силы валандаться с пересборкой.
Напиши хоть один недостаток cd или ls
В ls -l нет поддержки вывода различных хешей для файлов, например.
> И как часто ты поправлял код cd или ls?С каких это пор встроенная команда оболочки cd стала отдельной программой?
Пытаться переписать cd на шелле - это все равно что переписывать сишные кейворды на сях.
> Еще бы всякие coreutils и util-linux на шелле переписать. А то ведь, если захочешь поправить код, надо пересобирать - неудобно же.Что-то я прям усомнился, что Ваш код есть в coreutils.
>Что-то я прям усомнился, что Ваш код есть в coreutils.А кто сказал, что я разрабатываю его в мейнстриме? Речь идет о модификациях под конкретные задачи, возникающие при администрировании отдельных систем.
> модификациях под конкретные задачи, возникающие при администрировании отдельных систем.Нормальный unix-way это
1) Набор быстрых и эффективных утилит на сях
2) Скрипты, ака glue logic, объединяющая их между собой так, как этого требуют задачи администрирования систем.Хотя посредством маразма можно дойти и до больших высот. Например, можно зявить что хочется легко и просто модифицировать все сисколы, а дебагеры и тому подобные - фигня. Тогда наверное и ядро надо на баше переписать. Ну чтоб сисколы можно было править без компиляции, ога.
Это не маразм, а всего лишь попытка трезво оценить размер "кирпичика" (гранулярность). Чем меньше кирпичики (т.е., чем точнее и конкретнее определены функции программных модулей), тем более гибкие решения можно из них строить.Так что unix-way, если исходить из того, что glue logic должна быть именно интерпретируемая, в конечном счете ведет к тому, что практически вся система должна быть написана на шелле.
Вы не сильно быстрый, вернее вы сильно медленный, ну вы поняли.
> Это не маразм, а всего лишь попытка трезво оценить размер "кирпичика" (гранулярность).
> Чем меньше кирпичики (т.е., чем точнее и конкретнее определены функции программных
> модулей), тем более гибкие решения можно из них строить.Несомненно, дома из отдельных атомов - могут быть более произвольной формы и конструкции чем из отдельных кирпичей. Просто их такие строить раскладывая атомы по одному - долго. Очень долго.
> Так что unix-way, если исходить из того, что glue logic должна быть
> именно интерпретируемая, в конечном счете ведет к тому, что практически вся
> система должна быть написана на шелле.Любое начинание можно довести до маразма. Можно предложить строить дворцы, раскладывая отдельные атомы (будет круто, даже очень, но при существующих технологиях вы просто не доживете до окончания строительства - сущая ерунда, правда?).
p.s. если уж на то пошло, то надо у каждой буквы лично выставлять биты в хексэдиторе. Ну, чтоб кирпич был минимального размера.
>Несомненно, дома из отдельных атомов - могут быть более произвольной формы и конструкции чем из отдельных кирпичей. Просто их такие строить раскладывая атомы по одному - долго. Очень долго.Это всего лишь вопрос технологий. Действительно, если научиться не класть дома из кирпичей, а выращивать их из цельных полимерных молекул, когда вся несущая конструкция здания является одной молекулой и держится на межатомных связях - можно получить множество бонусов по надежности, гибкости и т.д. А скорость такого строительства зависит исключительно от технологии.
> Любое начинание можно довести до маразма.Поясняю: стремление сделать _всю_ glue logic обязательно интерпретируемой - автоматически превращает unix way в маразм. Потому что такая логика требуется на разных уровнях, и не всегда интепретируемость является оптимальным решением.
Так перлисты собирались уже делать свой дистр, где замена coreutils и util-linux иключительно на Perl.
Скорее бы башисты свой дистр сделали. И чтобы это был единственный дистр с конфигурацией init на баше.
> если захочешь поправить код, надо пересобирать - неудобно же.Ну так перепишите. Правда подозреваю что вы будете единственным придурком который использует столь тормознутую хешилку всерьез. Знаете, если мне надо хеш пары исох посчитать, я лучше сишную хешировалку возьму, чем ждать конца рассчетов до послезавтрашнего дня, но зато с удобством модификации. А, собственно, зачем мне часто и удобно модифицироать утиль считающую хеш? Если я разработчик, у меня всяко рабочее окружение для разработки, тестирования и отладки - на мази. А если я не разработчик - то на кой мне туда соваться?
>Правда подозреваю что вы будете единственным придурком который использует столь тормознутую хешилку всерьез.Вот уж вряд ли. Я неоднократно видел, как люди чуть ли не рубаху на груди рвали, доказывая, что им пофигу на скорость загрузки компа (почитайте скептические комменты в любой новости про upstart или systemd). А если им пофигу на время загрузки компа - почему их должно беспокоить время хеширования файла? Ведь необходимость в этом действии возникает сравнительно редко, его можно запускать в фоне и т.д. В итоге получаем, что сомнительный выигрыш в скорости вовсе не заменяет полной прозрачности и простоты модификации.
> А если им пофигу на время загрузки компа - почему их
> должно беспокоить время хеширования файла?Может, потому что люди не живут вечно? И если файл хешируется месяц - ну так этот месяц вы не сможете использовать слитый дистр, не зная корректно ли он скачался. При том, качается он сильно быстрее. Так что по этом поводу предлагаю переписать ядро и TCP/IP на bash. Пусть как максимум выжимает скорость диалапа, для симметрии. А то не порядок когда хешируется медленнее чем качается.
> В итоге получаем, что сомнительный выигрыш в скорости вовсе не заменяет полной
> прозрачности и простоты модификации.А зачем нужна простота модификации хешировалки файлов? Сколько раз в жизни у вас зудело запатчить md5sum, например?
> Может, потому что люди не живут вечно? И если файл хешируется месяцА кто сказал, что md5sum на баше будет хешировать DVD-образ именно месяц? Возможно, даже на слабом компе оно уложится в несколько часов. До проведения бенчмарков подобные заявления не могут служить аргументом.
> А зачем нужна простота модификации хешировалки файлов? Сколько раз в жизни у
> вас зудело запатчить md5sum, например?Речь идет не только об md5sum, но вообще о базовом наборе системных утилит. Если считать их все - такая необходимость возникает регулярно.
Ну, а что тут такого? Проводят же чемпионаты по плеванию вишневыми косточками - пользы ничуть не больше. Когда человек пишет хеширование на баше, он в это время не грабит, не убивает, не насилует и не пытается свергнуть правительство. Запретить ему писать, чтобы он этим всем занялся?
как будто грабить, убивать, насиловать и пытается свергнуть правительство это что-то плохое
> как будто грабить, убивать, насиловать и пытается свергнуть правительство это что-то плохоеС точки зрения правительства - да, последнее нехорошо.
Уж лучше воровать, убивать и сношаться с гусями нежели писать хеш на баше.Если серьезно, то как тут заметил один индивид: написали бы _понятно_ на брейнфаке, вайтспейсе или яве - вот тогда бы народ зауважал.
> Уж лучше воровать, убивать и сношаться с гусями нежели писать хеш на баше.Слово "хеш" здесь немного лишнее.
Ну вы даете! Реализация алгоритма на bash показывает простоту алгоритма. Не более того. Никто не требует использовать именно эту реализацию.
Нет, лучше всего простоту алгоритма показывает его реализация на брейнфаке. Как посмотришь на двадцать страниц точек и плюсиков, сразу понимаешь - алгоритм предельно прост и прозрачен.
А 500 строчек кода на баше такой наглядностью не обладают.
Знаешь, можно и мега-сложные алгоритмы на Bash'e написать, только толку от этого ноль.
> Ну вы даете! Реализация алгоритма на bash показывает простоту алгоритма.Каким хреном? Баш - тоже полный по Тюрингу, поэтому теоретически на нем реализуем _любой_ алгоритм.
А на практике видно, что никаких извращений особых нет даже на баше, который хоть и тьюринг-полный, но примитивный до ужаса. ЧТо и даёт простоту алгоритма.
> А на практике видно, что никаких извращений особых нет даже на баше,
> который хоть и тьюринг-полный, но примитивный до ужаса.Если у вас баш "примитивный до ужаса" - вы явно не видели брейнфака и уайтспейса.
> выполненная полностью на языке командного интерпретатора BashМсье знают толк. Нет, ну поятно что любой язык в принципе годится, вплоть до брейнфака, но какая польза то от этого потом?