Тогда в приведенном выше примере вероятность случайного угадывания составит 25 %. Без всяких умных ботов тогда в среднем из каждых четырех попыток одна будет удачной. Для усложнения необходимо либо увеличить количество вариантов ответа, либо использовать первоначальный вариант в котором вводим название предмета, а не его координату.
Возможно кому-нибудь поможет. Периодически я сносил-ставил системы на своем домашнем компе по разным причинам. И всегда винда была в паре с убунтой. Поэтому испытал за это время несколько вариантов установки загрузчика grub и выработал правила для себя:
1. grub не ставить на раздел с файловой системой NTFS — возможна нестабильная работа, либо загрузчик будет зависать, хотя по началу у меня работал такой вариант
2. позволить винде самой для себя создать раздел для установки — не всегда она дружит с ntfs, сделанным в линуксе (всегда думал что разницы нет)
3. не играть с маппингом, а всегда ставить винду на первый жесткий диск. У меня тоже ни разу маппинг не сработал.
На мой взгляд, удобен вариант когда для загрузчика grub создаешь отдельный основной раздел с fat (100 МБ) и там все параметры загрузок расписываешь. Плюс такого подхода состоит в том, что удаляя любую из операционных систем загрузчик остается работоспособным и следовательно не влияет на загрузку других установленных систем. Минус — тратим один из четырех возможных основных разделов на жестком диске, хотя это решается созданием дополнительных ;)
Спасибо, пригодилось сравнение PostgreDAC и ZEOSLib. Сам использую Zeos 6.6 и тоже сталкивался с проблемой чтения полей типа «bytea». Замечу, что корректно (по крайней мере в моем случае) обрабатывается подобное поле в ситуации когда оно является OUT параметром хранимой процедуры.
Например:
CREATE FUNCTION get_data (id_parent integer, x1 numeric, y1 numeric, x2 numeric, y2 numeric, out geom bytea, ...) RETURNS SETOF record AS
$body$
SELECT geom::bytea,…
FROM gdata
WHERE…
$body$
LANGUAGE 'sql';
Еще как вариант советуют использовать вместо bytea типа поля lo (large object)
Сам не ставил Windows 7, но почему бы нет. Существуют же различные виды «заливок» для XP, где голая система ставится за «5 минут» (время копирования) + время на установку нестандартных драйверов. Вполне возможно, что дядя Билл сделал нечто похожее.
Если говорить про кроссплатформенность и скорость взаимодействия клиента и сервера, то можно предложить сделать Java-приложения. Общение между ними при помощи RMI. RMI все-таки шустрее работает чем при использовании SOAP запросов и ответов в веб-сервисах.
1. grub не ставить на раздел с файловой системой NTFS — возможна нестабильная работа, либо загрузчик будет зависать, хотя по началу у меня работал такой вариант
2. позволить винде самой для себя создать раздел для установки — не всегда она дружит с ntfs, сделанным в линуксе (всегда думал что разницы нет)
3. не играть с маппингом, а всегда ставить винду на первый жесткий диск. У меня тоже ни разу маппинг не сработал.
На мой взгляд, удобен вариант когда для загрузчика grub создаешь отдельный основной раздел с fat (100 МБ) и там все параметры загрузок расписываешь. Плюс такого подхода состоит в том, что удаляя любую из операционных систем загрузчик остается работоспособным и следовательно не влияет на загрузку других установленных систем. Минус — тратим один из четырех возможных основных разделов на жестком диске, хотя это решается созданием дополнительных ;)
Например:
CREATE FUNCTION get_data (id_parent integer, x1 numeric, y1 numeric, x2 numeric, y2 numeric, out geom bytea, ...) RETURNS SETOF record AS
$body$
SELECT geom::bytea,…
FROM gdata
WHERE…
$body$
LANGUAGE 'sql';
Еще как вариант советуют использовать вместо bytea типа поля lo (large object)