Собственно задумал себе апгрейд. Время не очень благоприятное, но если не сейчас, то придется ждать еще месяца 3... А нужно.

В принципе, чипесет под сабж только один. Пока смотрю на мат. плату Intel DP55KG. Что посоветуйте/отсоветуйте?

И еще вопрос насчет оперативки. Какую выбирать? Стоит ли гнаться за нестандартными разогнанными 1600 и 2000 MHz модулями?

Есть МФУшка, которая позволяет отсылать отсканированное изображение по электронной почте (PDF'ка в аттачменте). Вроде бы все нормально, только у меня почта во-первых ексчейндж, во-вторых далеко и не на очень широком канале. А заюзать сей функционал хочется.

Пришла в голову идейка. Настраиваю MTA, который принимает почту, выдирает PDF из аттача и в соответствии с определенными правилами рассовывает по пользовательским каталогам. Т.е. еще с одной почтой и с дополнительным MUA трахаться не хочется.

Получилось так, что с устройством MTA я знаком чисто теоретически и никогда мне не приходилось ковырять какой-то конкретный. Ситуацию усугубляет то, что всяких-разных MTA пруд пруди. Посоветуйте, какой лучше.

Т.е. должен быть маленьким, понятным и поддерживать пользовательские фильтры и пользовательскую доставку... Пока склонаюсь в сторону qmail с патчами.

Сабж. Различных извращений типа маппинга ява-пролог и стандартной библиотеки пролога не требуется. Можно интерпретатор.

1. Кто? Кто в дебьяне делал такие инит-скрипты, что в lenny(!!!), когда по какой-то причине start-stop-daemon не удаляет .pid файл, система при перезагрузке/выключении замораживается на последней стадии и ее приходится сносить ресетом?

2. Какая сволочь в делала selinux вообще и selinux-basics в частости в squeeze? Найду - убью гада.

3. Какая сволочь сделала так, что если не стартован hald - иксы не видят клаву и мышь, и систему приходится приводить в чувство по ssh или сносить ресетом?

4. Кто в дебьяне сделал идентичными ранлевелы 2,3 и 4?

А вообще - кактус вкусный.

Нужна программа, которая бы выкачала целевой урл, представляясь разными браузерами.

Да, вгет с ключом -U, список UA и скрипты рулят, но может есть какая-то специальная штука?

Сколько не насиловал гугл, по сабжу ничего кроме как в контексте а)параллельного программирования и б)вычислительной математики не нашел. Только кое-где оговорки, что де MPI может применяться для создания распределенных систем.

Может кто знает какие-нибудь статьи где рассмотрено такое применение MPI?

Задумал собрать комп на чипсете Intel Q45, главным образом для целей виртуализации. Собственно говоря, материнских плат только две. По функционалу примерно идентичные... но интеловскую все никак не могу найти, нету ее нигде.

Асус покупать чего-то не хочется. Или у них уже более-менее приличные матери стали делать?

Посоветуйте, как быть. И, кстати, как там поддержка видюхи интел 4500 в линуксе?

Посоветуйте недорогой сабж. Требования: неограниченный трафик без наколок и "условий", 256/512 RAM, толерантность к проходящему трафику (ессно без спама, червей, публичных прокси и прочего), DNS с возможностью размещения MX записи (ну а если будут домены давать, так вообще здорово), все остальное по барабану.

Из возможностей управления - безгиморная перезагрузка и развертывание образа системы.

Систему лучше линукс/CentOS.

Планируемое использование: web-визитка, mail, jabber, частный proxy для защиты от "бытового" определения местоположения на всяких быдлосайтах.

Есть некая форма документа, изначально в виде Excel. Мне нужно вставить ее в качестве иллюстарции в LaTeX'овский документ. Как мне проще всего это сдлеать?

Лично я думал, открываю OO, сохраняю в PDF, преобразую в EPS и юзаю через \includegraphics. Но может быть есть способ короче?

И каким образом мне PDF преобразовать в EPS?

У всякого разные хобби, кто марки собирает, кто монеты, кто бутылки, а я вот люблю на досуге разрабатывать криптоанархические схемы.

Есть исходное сообщение мы:

1. В начало добавляем балласт (большое случайное число)
2. Полученный результат хешируем.
3. Генерируем ключ шифрования, случайное число или из пароля по какой-нибудь схеме вывода.
4. Шифруем п.1 ключом из п.3 по какому-нибудь симметричному алгоритму.
5. Формиируем криптозаголовок: хеш(п.2) + ключ(п.3) + балласт (случайное чило).
6. Хешируем данные из п.5, получаем ИД сообщения.
7. Отправляем ИД на сервер меток времени, полученный результат будет глобальным ИД.
8. Данные: ГИД(п.7)+данные из п.4.
9. Ключ: ГИД(п.7)+криптозаголовок(п.5), зашифрованный открытым ключом получателя.

Данная схема разработана для организации блогов и форумов, и не очень подходит для распространения контента.

Фишки схемы:
1. Ключ и исходное сообщение распространяются независимо, возможно через P2P сеть.
2. Владелец ключа ничего не знает об исходном сообщении, кроме его ГИД, даже хеш.
3. Владелец ключа может перешифровать ключ (п.9), для дальнейшего распространения, даже без получения данных из п.8.
4. Антицензурная стойкость. Как против изменения, так и идентификации исходного сообщения.
5. Балласт служит для внесения дополинительной энтропии, но может служить средой для передачи внедиапазонных сообщений: служебной информации, дополнительных ключей шифрования и т.п.
6. Некоторое количество plausible deniability для распростарнителей ключей(п.9) и данных(п.8).

Ищу работы окружения tabular. Или хотя бы полную документацию по его использованию, с описанием параметров типа \arraystretch, \tabcolsep, алгоритма расчета ширины колонки, описание спецификаторов l, c, и p. И прочую низкоуровневую хрень.

Не так давно была дискуссия насчет разрабоки DSL'ов, и высказывалось мнение, что конечно DSL'ы - шутка хорошая НО:

1. Нужен компилятор.
2. Нужен отладчик.
3. Нужен рантайм.

Насчет всего вышеперечисленного появилась следующая идея:

1. Скармиливаем GCC программу на нашем DSL в форме GIMPLE.
2. GCC преобразует ее в SSA GIMPLE и проводит серию извращенных оптимизаций и формирует целевой код.
3. Поддержка отладочной информации в gdb, как минимум на уровне GIMPLE.
4. Рантайм на выбор: С, C++, Ada.
5. Profit.

Недостаток - нужно серьезно разбираться в потрохах GCC.

Комментарии?

В течение 2008-го года группа немецких товарищей риверсинжернула проприетарный и NDA'шный протокол аутентификации DECT (DSAA). Результаты приведены в работе http://eprint.iacr.org/2009/078.pdf

Правда есть еще алгоритм шифрования DSC, и с ним есть некоторые не решенные еще проблемы, он реализован в железе. НО большинство телефонов его не включают, и видимо все соглашаются его отключать по требованию базовой станции. А поскольку аутентификации между БС и телефоном не происходит, то ее можно легко подменить.

И дело тут даже не в том, что DSAA обосрался по полной, дело даже не в том, что проверить факт использования DSC с помощью бытового телефона невозможно (ну не пишет он нифига). Дело даже не в позиции DECT-форума (голову в песок, задницу наружу).

Дело в том, что детали NDA'шного алгоритма DSC опубликованы в испанском патенте!!! Тут контора Alcatel расстаралась. Занавес.

И вот я что подумал. Если смотреть с позиции вышеприведенных фактов, то фанатичные взревывания Столлмана обретают смысл. А наше родное требование использования ГОСТ 34.10/34.11 кажется намного менее маразматичным.

Как сделать сабж? В гугле нашел что-то наподобие ser2net. А нужно, чтобы сам демон был инициатором TCP соединения.

Подскажите, плз. Сабж поддерживает LCP-echo и соответственно разрыв соединения с _клиентской_ стороны по неполучению.

Вот, блин, все люди как люди, ночью спят. А меня вот идеи посещают.

0. Генерим пару ключей.

1. Открытый колюч и UUID, который будет нашим user id (UID) отправляем в сеть. На этом процедура регистрации заканчивается.

2. Допустим, мы хотим отправить некое сообщение. Подписываем, шифруем его нашим открытым ключом и отправляем: UID, UUID-сообщения, UUID-родителя (или наш UID если нет), хэш подписанного сообщения, криптованное собщение, ЭЦП пакета. Такое сообщение будем назыать первичным сообщением.

3. Ессно, на данном этапе никто прочитать сообщение не может, но зато может его "запросить". Отправляем запрос: UUID-сообщения, UID получателя.

4. Теперь, пользователь сети увидит запрос и может его обработать: найти нужное сообщение, расшифровать его своим секретным ключом, зашифровать открытым ключом получателя и отправить в сеть. Такое сообщение будем называть зеркальным сообщением.

5. Получатель расшифровывает своим секретным ключом, проверяет хэш, проверяет ЭЦП.

6. Поскольку, у нас социальная сеть, значит у нас есть френды. Допустим, мы делаем так, что при отправке нового сообщения, юзер ОБЯЗАН отправлять зеркальное сообщение всем своим взаимным френдам.

7. Чтобы не захламлять сеть зеркальными сообщениями, разумно установить срок их жизни, по истечении которого сообщение удаляется.

8. Ессно, владелец зеркального сообшения, может самостоятельно перешифровать его другому получателю, т.е. исполнить запрос в п.4. В принципе, можно сделать ограничения на "зеркалирование" зеркальных сообщений, но реальных рычагов для осуществления подобного ограничения я найти не могу.

9. Поскольку, это социальная сеть, значит есть сообщества. Чисто технически, сообщество - это специальный UID, который указывается в поле "родитель" сообщения.

10. Поскольку это сообщество, то значит нужно обеспечить быстрое получение зеркальных сообщений. Этим занимаются модераторы. При формировании первичного сообщения в сообщество, пользователь ОБЯЗАН отправить "зеркало" модераторам.

11. В принципе, модератор может быть демоном, который будет рассылать "зеркала" членам сообщества и отвечать на их запросы. Ессно, "время жизни" сообщений на модераторов не распространяется.

Что это дает:

1. Простота реализации. Полное отсутствие логики обеспечения безопасности. Все что нужно - это проведение нескольких проверок перед помещением сообщения в сеть.

2. На серваке все шифровано. И паяльник против владельца сети поможет слабо. Нужно искать, либо владельца первичного сообщения, либо владельцев зеркал.

3. Обеспечение приватности с одной стороны, обеспечение широкой доступности с другой.

Дополнительные возможности (не рассмотренные здесь):

1. Можно сделать только зеркальные сообщения, которые будут жить в сети только то время, пока они востребованы.

2. Можно сделать отправку по поручению. Т.е. отправляем кому-нибудь сообщение, в теле которого содержится сообщение, которое получатель может отправить в сеть. (Для сокрытия IP отправителя, притом, глубина рекурсии может быть произвольной).

3. Различные модели доверия, подписки, рассылки, фильтры, подтверждения.

4. Служба меток времени.

>>>

Нужен сабж с коэффициентом усиления >5dbi,в принципе, наличие 900 MHz опционально.

Кто что может посоветовать?

>>>

После двух лет ожидания сбылся страшный сон вирусных аналитиков. Если предыдущую версию с длинной ключа 660 бит удалось поломать, то теперь ситуация очень плачевная. Секретный ключ можно получить только применив небезызвестную процедуру терморектального криптоанализа к его авторам.

Я только надеюсь что у многоуважаемого автора хватило ума не просто стирать файлы, а записать туда сначала FF'ы, потом 00, затем еще раз FF, затем еще раз 00.

Думаю можно предполагать, что скоро такие зловреды войдут в моду.

>>>

Требования:

1. Без лишнего функционала.
2. На небольшую нагрузку.
3. Дешевую.
4. Основная задача - прикрывать веб-приложение.

>>>

Dogtag Certificate System - это открытый центр сертификации (CA) промышленного уровня, основанный на недавно открытой Red Hat Certificate System.

Центр сертификации - это компонент PKI (Инфраструктуры Открытых Ключей), отвечающий за выпуск, отзыв и хранение цифровых сертификатов.

Цифровые сертификаты применяются в различных приложениях, требующих защищенного электронного обмена: электронная почта, HTTPS, защита данных в сетях TCP/IP (SSL, TLS), SSL VPN, могут использоваться для аутентификации в различных приложениях.

Также Dogtag Certificate System поддерживает протокол SCEP и управление токенами и смарт-картами.

>>> Подробности