Что такое авторское лево
www.gnu.org/copyleft/copyleft.ru.html
www.gnu.org/copyleft/copyleft.html

Категории свободных и несвободных программ
www.gnu.org/philosophy/categories.ru.html
www.gnu.org/philosophy/categories.html

Проблема лицензии BSD
www.gnu.org/philosophy/bsd.ru.html
www.gnu.org/philosophy/bsd.html

Свободные программы надежнее
www.gnu.org/software/reliability.ru.html
www.gnu.org/software/reliability.html

Почему «открытый исходный код» не передает понятия свободное ПО
www.gnu.org/philosophy/open-source-misses-the-point.ru.html
www.gnu.org/philosophy/open-source-misses-the-point.html

Зачем авторское лево
www.gnu.org/philosophy/why-copyleft.ru.html
www.gnu.org/philosophy/why-copyleft.html

FAQ по лицензии GNU
www.gnu.org/licenses/gpl-faq.html

Отличная подборка, как нарисовать различные геометрические фигуры одним элементом HTML.

Квадрат

#square {
	width: 100px;
	height: 100px;
	background: red;
}

Всем доброго времени суток!

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

Дерево ван Эмде Боаса (van Emde Boas tree) — ассоциативный массив, который позволяет хранить целые числа в диапазоне [0; U), где U = 2^k, проще говоря, числа, состоящие не более чем из k бит. Казалось бы, зачем нужно еще какое-то дерево, да еще позволяющее хранить только целые числа, когда существует множество различных сбалансриованных двоичных деревьев поиска, позволяющих выполнять операции вставки, удаления и прочие за O(log n), где n — количество элементов в дереве?

Главная особенность этой структуры — выполнение всех операций за время O(log(log(U))) независимо от количества хранящихся в ней элементов.

Вот уже около 3-х лет занимаюсь интернет коммерцией. Работа в основном направлена на зарубежные сайты по продаже электроники. Начинал бизнес с открытия ebay аккаунта и уже тогда вопрос стал ребром, т.к. для работы с ebay нужен верифицированный аккаунт PayPal. Я являюсь гражданином Украины, следовательно, никаких шансов открыть свой собственный аккаунт у меня не было, т.к. PayPal ни тогда ни сейчас не работает с Украиной, поэтому пришлось просить друга, который проживает в Великобритании, открыть аккаунт на его имя. Впринципе, открытие аккаунта в Англии является делом обыденным. Все что требуется, это действующий банковский счет, после чего нужно пройти несколько этапов для того чтобы подтвердить что вы владелец этого счета. Так же вы указываете свой адрес, который могут попросить подтвердить. Для этого достаточно будет отправить так называемый Bank Statement, т.е. выписку из банка. Выглядит она примерно так:

Некоторые замечания о времени

• UTC: время на нулевом меридиане называется Всемирное координированное время, Universal Coordinated Time. Несовпадение акронима было вызвано необходимостью универсальности его для всех языков.
• GMT: ранее вместо UTC использовалось среднее время по Гринвичу (Greenwich Mean Time, GMT), так как нулевой меридиан был выбран так, чтобы проходить через Гринвичскую королевскую обсерваторию.
• Прочие часовые пояса могут быть записаны как смещение от UTC. Например, Австралийское восточное стандартное время (EST) записывается как UTC+1000, то есть время 10:00 по UTC есть 20:00 по EST того же дня.

XPath является одним из ключевых моментов на дороге к пониманию XSLT. И на первых порах хочется получить какой-нибудь простой способ поэкспериментировать с ним, чтобы в деталях разобраться, как он работает. Способа такого, впрочем, не наблюдается. Приходится или качать совсем не бесплатные XML/XSLT редакторы, или довольствоваться статичными картинками с zvon.org. Может быть, я плохо искал. Но с моей колокольни все обстоит именно так. И когда передо мной в очередной раз встала задача «Объяснить XSLT», в голове и родилась идея крохотного сервиса. После того, как все заработало, было решено выкатить его для всеобщего пользования: наверняка не я один сталкивался с похожими проблемами.

(Тот факт, что русского перевода понятию «lock-free» в литературе ещё не устоялось, — нисколько меня не убеждает, что такого перевода не должно быть.)

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

BOOL IsPrime(int n)
{
 static int nLast = 1;
 static BOOL fLastIsPrime = FALSE;

 // если значение параметра не изменилось с прошлого раза,
 // воспользуемся готовым результатом
 if (n == nLast) return fLastIsPrime;

 // вычислим и запомним новый результат
 nLast = n;
 fLastIsPrime = slow_IsPrime(n);
 return fLastIsPrime;
}

Само собой, этот код потоконебезопасен: если один поток находится внутри вызова slow_IsPrime(), то другой поток, вызвавший IsPrime(), застанет значения переменных nLast и fLastIsPrime несоответствующими одно другому.

Простое решение — заключить код в критическую секцию; но простота идёт в ущерб производительности: если, скажем, nLast = 5, fLastIsPrime = TRUE, и два потока одновременно вызывают IsPrime(5), то совершенно ни к чему им выстраиваться в очередь: ничего не мешает им одновременно воспользоваться кэшированным значением.

Посмотрим, как можно реализовать наш кэш беззамочно.

Xpath — это язык запросов к элементам xml или xhtml документа. Также как SQL, xpath является декларативным языком запросов. Чтобы получить интересующие данные, необходимо всего лишь создать запрос, описывающий эти данные. Всю «черную» работу за вас выполнит интерпретатор языка xpath.
Очень удобно, не правда ли? Давайте посмотри какие возможности предлагает xpath для доступа к узлам веб-страниц.

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

Четвертая часть Гражданского кодекса, регулирующая отношения в сфере «интеллектуальной собственности», повторяет подавляющее большинство норм, которые содержались в тех законах, которые были до нее: «Об авторском праве...», Патентном законе, законе «О правовой охране программ для ЭВМ...», и других.

Вступление ее в силу сопровождалось обсуждением в интернете, участники которого почему-то считали, будто новая часть ГК «ужесточила охрану авторских прав», однако, мнения эти не имели под собой никаких оснований. Кардинальных изменений в главах, посвященных авторскому праву, сравнительно немного. А вот то, что четвертая часть действительно «ужесточила» – так это регулирование смежных прав, прежде всего путем введения новых их видов. «Смежными» называются такие права, которые связаны не с созданием произведения, а доведением его до аудитории. Например, поэт и композитор являются авторами песни, а вот исполнитель этой песни и изготовитель ее фонограммы обладают смежными правами.

Часто авторские и смежные права путают, но лучше их все же различать. Например, четвертой частью ГК введено так называемое «смежное право публикатора», в соответствии с которым тот, кто впервые опубликовал произведение, получает на срок в двадцать пять лет право ограничивать его использование – даже в том случае, если сроки охраны этого произведения давно истекли и оно перешло в общественное достояние. Рядом с этим правом стоит и «право изготовителя базы данных», о котором мы сейчас и поговорим…

О чем пойдет речь

Наверное никогда не прекратятся бои людей желающих проставить свои ссылки или что-то порекламировать, с людьми не желающими видеть у себя в комментах или на форумах «левую рекламу» а иногда даже и «правую».

Как человек, который в прошлом потратил много времени на разработку средств для спама веб-формы. Я хотел бы остановиться на моментах, которые упускают многие авторы, агитируя за тот или иной метод защиты.

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

Добрый день.
Недавно одни из наших заказчиков выразили желание получать дополнительную информацию о посетителях своего сайта, конкретнее — о людях, заполнивших контактную форму. Это крупная европейская компания и им хотелось бы «фильтровать» своих потенциальных клиентов. Поясню на примере — допустим, решают они организовать выставку своего оборудования в Венгрии и им нужно решить, кто из венгров, оставлявших им свои контакты, скорее всего стоящий клиент, а кто «мимо проходил».
Основными показателями «надежности» клиента для нас стали: число посещений сайта, время проведенное на сайте, количество просмотренных страниц. Всю эту информацию мы получили из Google Analytics Cookies.

Что же из себя представляют печеньки от Google?