По-моему лисп это как раз самое простое что можно только вообще интерпретировать. Интерпретатор лиспа на Си с реализацией основных функций укладывается в несколько сот строк кода, что идеально подходит для изучения языков программирования. Вот кстати один такой: piumarta.com/software/lysp/
Щупайте man, там всё есть. Да и что у вас были за книжки такие, в хороших книгах вроде Linux in a Nutshell всё это написано очень подробно. Да и мне кажется для администратора достаточно только этой книги в 90% случаев.
chattr +i более навороченная вещь — после этого даже root не сможет удалить или что-то сделать с файлом. Это уже расширения классической системы безопасности UNIX. Есть ACL, обычные «классические» атрибуты, расширенные атрибуты и вдобавок SELinux — можно вообще закрыться наглухо. По понятным причинам хостеры не заморачиваются с безопасностью.
У того же ffmpeg или mplayer есть возможность померить качество кодирования «в попугаях». Метрика называется PSNR, нужно полистать man-ы, и можно будет качественно оценить, насколько просело качество картинки.
Так суть в этом и состоит — выбрать вариант, который в реальных боевых условиях показывает себя с наилучшей стороны. Тесты с академической точки зрения вещь интересная, но практически — сначала делаем продукт, далее, если узкое место — хэши — начинаем перебирать в поисках лучшего алгоритма. Конечно есть показательная порка плюсовой unordered_map, реализации boost (которая оказалась совсем не boost), но там и разница в несколько раз и отличаются они скорее организацией памяти, нежели хэш-функциями (они везде пользователем задаются).
GLib по сравнению с Java — крошечный проект. Всего 2 мегабайта. Это не оконная библиотека, а библиотека общего назначения для Си, на хэшах там ООП (GObject). Более-менее представление о библиотеке может дать та же Википедия. И в отличие от ораклоидов, GLib свободный проект куда относительно без проблем любой может прислать патч.
Производительность объектной системы неважная даже по сравнению с плюсами, но её ключ — универсальность (есть биндиги практически ко всему), чем не может похвастатья даже Qt. С появлением интроспекции стала серебряной пулей вавилонского столпотворения языков программирования.
Ява — это к ораклоидам, не ко мне:) С тенденциями JVM потреблять в пять раз больше памяти (для словарей) чем Питон, даже не хочется задумываться, почему так.
В ключевых библиотеках Linux GNOME всё зиждется на DJB. В Qt — PJW. И ни одну из них вы не выбрали? Гораздо интереснее будет взять эти хэш-функции, засунуть по очереди в центральные библиотеки и посмотреть на практический результат. В GLib вся объектная система построена на хэшах — так что у вас есть шанс сделать доброе дело, если грамотно докажете непригодность используемых хэшей.
Вот ещё коммент для размышления из исходников Qt:
// ### Qt 5: see tests/benchmarks/corelib/tools/qhash/qhash_string.cpp
// Hashing of the whole string is a waste of cycles.
/*
These functions are based on Peter J. Weinberger's hash function
(from the Dragon Book). The constant 24 in the original function
was replaced with 23 to produce fewer collisions on input such as
"a", "aa", "aaa", "aaaa", ...
*/
P.S. Надо конечно заметить, что Qt использует для строк UTF-16, а GLib — UTF-8, поэтому хэш-таблицы GLib неоднократно показывали превосходство над остальными реализациями, с GLib может потягаться только хэш от Google.
Тут уже как уровни подкорректировать. Я unsharp и level на глазок поставил. Можно paint или median фильтр применить, буквально единичку для более равномерного контура. А если убрать unsharp и deskew — ещё раза в два быстрее будет:)
Я аналогичный алгоритм для обработки сканов использую, но там надо аккуратно — попадаются рисунки, которые такими агрессивными фильтрами можно сильно покалечить. Будет время сделаю заметку на эту тему.
В шопе… Каждому студенту по программе за килобакс, для того чтобы фоткать лекции:) В ГИМПе такой batch, что можно сказать его и нет. Для студента как раз полезнее приобщиться к IM-сообществу, так как есть реально чему поучиться, поучаствовать в GSoC и т. п.
В любом случае, подобрать параметры, играть с тестовым изображением лучше в графическом редакторе
Это пожалуй единственное, чего не хватает в ImageMagick после GIMP/PS. Там есть GUI, но он настолько убог, что командная строка на порядки удобнее. Но сделать обертку над ImageMagick в виде GUI не так уж сложно, так что со временем не исключено что появится.
Все консольные программы хороши только тем что на них можно орабатывать изображения без интерфейса.
Они хороши тем, что работают быстро и применимы к целому ряду задач. Вот методом ручной коррекции в GIMP отсканированную книгу 500 листов не обработаешь, а в ImageMagick — элементарно. Если у вас куча таких лекций и сотня фотографий — ImageMagick ваш друг.
Спасибо за детальный обзор статей по теме:) В статье, которую я смотрел стояла дата 2003 год. Наверное, есть эффективные алгоритмы (есть один с учетом антилалиасинга, который я представил в ссылках), но это всё делалось в рамках OpenSource проекта генератора шрифтов UBFG, поэтому я не сильно вдавался в детали алгоритмов или сравнительный анализ. Если получится сделать быстрее — contributions are welcome:) Когда я делал этот алгоритм для UBFG, я просто задумался, а можно ли это сделать имеющимися OpenSource средствами? Оказалось, что ImageMagick умеет это делать, скорость и качество для большинства разработчиков являются приемлемыми.
man --path | tr : "\n" | xargs -I{} find {} -type fКак-то так:)
Естественно, рут может и снять этот атрибут.
Производительность объектной системы неважная даже по сравнению с плюсами, но её ключ — универсальность (есть биндиги практически ко всему), чем не может похвастатья даже Qt. С появлением интроспекции стала серебряной пулей вавилонского столпотворения языков программирования.
Вот ещё коммент для размышления из исходников Qt:
P.S. Надо конечно заметить, что Qt использует для строк UTF-16, а GLib — UTF-8, поэтому хэш-таблицы GLib неоднократно показывали превосходство над остальными реализациями, с GLib может потягаться только хэш от Google.
Я аналогичный алгоритм для обработки сканов использую, но там надо аккуратно — попадаются рисунки, которые такими агрессивными фильтрами можно сильно покалечить. Будет время сделаю заметку на эту тему.
Это пожалуй единственное, чего не хватает в ImageMagick после GIMP/PS. Там есть GUI, но он настолько убог, что командная строка на порядки удобнее. Но сделать обертку над ImageMagick в виде GUI не так уж сложно, так что со временем не исключено что появится.
Они хороши тем, что работают быстро и применимы к целому ряду задач. Вот методом ручной коррекции в GIMP отсканированную книгу 500 листов не обработаешь, а в ImageMagick — элементарно. Если у вас куча таких лекций и сотня фотографий — ImageMagick ваш друг.
Можно будет сравнить на реальном проекте, использующем SDF.