Авторское право возникает вне зависимости от документов. Оно возникает просто по факту авторства. Более того — исходя из сабжа, вопросов в авторстве также не возникает. Посему, тут дело уже на в авторских, а в смежных правах. Смежные права первоначально возникают у автора по тому самом факту авторства, а затем (это самое затем может оказаться весьма скоротечным — например, если вы разрабатываете ПО в конторе, в вашем трудовом договоре скорее всего зафиксирован факт автоматической передачи всех смежных прав этой самой конторе сразу по факту создания любого кода) могут быть переданы, платно или бесплатно, с условиями или без условий и т.д. Например, смежные права на Pure Open Source (типа Столлман) (воспроизведение, использование, модификация, использование в других продуктах, распространение) передаются при условии их дальнейшего свободного распространения и т.д.
Теперь внимание! В случае, если в лицензии прямо не было прямого указания на передачу определенных прав с перечислением этих прав, все права (и авторские, и смежные) сохраняются за автором. При этом вопрос оформления лицензии остается открытым — в общем случае годится все, начиная с устной договоренности. Более того — вопрос авторского права на программные продукты также не столь однозначен, как, например, на литературные произведения, фото и видео материалы.
А вообще, в данном случае, IMHO, если «Сайт довольно долго жил и развивался», и особых претензий к движку, видимо, не было, честно будет копирайт поставить. Если, при этом, движок «Хорошенько перелопа»чивался — поставить копирайт вроде «на основе такого-то».
Кликнулось слишком быстро. В смысле, MySQL тоже умеет писать свои функции? Мы просто с ним не работаем. Но показатель производительности на постгресе впечатляет — функция, написанная на C пашет быстрее функции, написанной на PL/PgSQL, думаю, на порядки. Во всяком случае сортировка по индексу на основе самопальной C-шной функции (и, соответственно — по самопальному типу данных) работает примерно с той же скоростью, что и сортировка по встроенным типам данных, что есть хорошо. Правда, там куча как теперь уже малознакомой специфики (конструкций языка) — так изаведомо малознакомой специфики — как Postgresql
Было бы интересно посмотреть примеры модулей к PHP и базам данных и т.д — т.е. к существующим приложениям общего назначения. А то книжки по юниховому C++, как правило, рассказывают про визуальные среды — типа «как нам сделать Visual Studio под Линух». Да и примеры кода там ужасающие приводятся. И, в самом деле, лучше начинать с азов — я последний раз (не считая микроопыта месячной давности, давшегося, надо признать, большой кровью) писал на C лет 20 назад, а пресловутый микроопыт показал, что С довольно сильно изменился.
офигительно минуснули. Я имел в виду, что ту же капчу, написанную на PHP и работающую через GD можно спокойно сваять на C, отчего она будет работать быстрее.
Я не предлагал делать капчу в виде анимированного квадратика)))
P.S. Нет —, конечно, догадывался, что к GD не обязательно лезть через PHP. Просто оно как-то всегда проходило как-то мимо.
а не лучше лы было бы в таком разе вместо картинки флешак зафигачить? по тому же принципу. Конечно, зависит от фона, но если удастся сделать фон целиком во флеше — весить будет меньше и тянуться адекватно
1876 км от МКАД метро, пожалуй, не поможет.))) А пробки-то там откуда?))). В качестве «чутка» запчастей я храню то, что может вылететь и повлиять на работоспособность серверов. RAID стоимостью 1К в них не входит. Я такое на свои сервера вообще не ставлю. Старая привычка еще со времен возни с FreeBSD — в начале 2000-х подобные игрушки без вазелина на нее, как правило, не вставали.
Впрочем, если учесть разницу в стоимости самосбора и готового решения вендора — можно было бы, пожалуй, и хранить.
В рабочее время лучше на метро)))). Быстрее и почти без пробок. У меня на такой случай всегда лежит чутка запчастей дома (обходится примерно как стоимость пресловутого HP Care Pack). Впрочем — холивар на эту тему страивать не стоит — каждый экономит свои нервы так, как им (нервам, в смысле) удобнее.
Экстрим)))). У нас, в этом плане ситуация чуть проще — наш провайдер держит дата-центр в закрытом институте, и доступ к серверам в нерабочее время мягко говоря затруднен (конечно, я слышал, бывает и по-другому, но на московском рынке, к сожалению, ситуация типичная). Ну а в рабочее… дайте подумать… наверное, на замену памяти ушло бы часа полтора (включая дорогу до провайдера).
А зачем покупать сервера за 4 — 10 тысяч (я ни в коей мере не против оптимизации кода — наоборот). Но приличный сервер можно собрать тысячи за 2 (TWIN Core Quadх8Гбх320Гб в корпусе 1 U на платформе Intel), а тысяч за 5 можно уже собрать совсем монстра на SuperMicro TWIN.
P.S. Для людей, считающих, что сервер может быть собран только вендором, отвечающим за его качество, можно прикинуть добавочную стоимость от вендора (порядка 200%) и попробовать пересчитать ее на классические гарантии при сборке из запчастей (3 года — платформа=хорошей гарантии вендора, + 1 год — винты (суммарно не более 10% стоимости сервера) — если они будут лететь регулярно на следующий день после окончания гарантии — даст удорожание сборки на 20% — соответственно от прибыли вендора остается 180%), + 1 год — процессоры (20% стоимости сервера — если будут ломаться как винты, от прибыли вендора останется 140%), ну и память (как правило с пожизненной гарантией).
Конечно, собрать сервер — дело несколько более сложное, чем тачку домой, но, мне кажется, трата 2 — 3 дней на изучение материала, в данном случае, себя окупит.
А на новом сервере провести оптимизацию и тонкий тюнинг софта.
Интерфейс — на 5. Сама CMS (по первому впечатлению) — на 3-. И чего-то долго оно все подгружает. Над серверной частью поработайте. При грамотном построении кода окошко должно грузиться за доли секунды.
P.S. А может и над клиентской тоже.
P.P.S. ЗАкрыл вкладку файрфокса, потом попробовал открыть админку и получил «Warning: Smarty error: unable to read resource: „/desktop.tpl“ in /home/ibpro/public_html/smarty/Smarty.class.php on line 1092». Все-таки есть ощущение, что серверная частьчудит
А самое забавное — что сей апокалиптический сценарий поведения AOL принадлежит вроде как (судя по Теминому ЖЖ) Эльдару Муртазину. То есть психуют все-таки где-то чуть поближе, чем в Америке.
Было бы интересно провести тест при параболическом распределении узлов. т.е. вначале детей немного, потом количество резко увеличивается, а потом падает. IMHO, такое распределение больше приближено к жизни. Впрочем, полагаю, реально картина если и изменится, то не сильно.
А еще есть пара полезных операций — как то смена порядка следования детей внутри родительского узла (и лучше смена на произвольное количество позиций), а также копирование ветки (то есть добавление в середину дерева не узла, но ветви произвольного размера).
P.S. алгоритмы AL можно серьезно оптимизировать, добавив level и havechild (тот же самый уровень и признак наличия потомков) Происходит некоторое замедление добавления (принудительный апдейт или апдейт с проверкой), удаления и апдейта (на отдельных операциях — ровно на проверку а остались ли еще дети).
Так когда мы пытались сформировать дерево в nested sets, оно там никогда выше 1300 — 1400 узлов не дорастало))). мы скрипт отрубали.
делать границы с шагом, разумеется, можно, но не универсально — а мы пытались выработать некий универсальный подход, который позволил бы нам работать с большими деревьями быстро и с минимальными затратами.
А предметная область удручающе банальна — web-дизайн. Мы используем дерево в качестве универсального хранилища данных для сайта/группы сайтов. Там, не то, чтобы постоянно, но регулярно возникают задачи по копированию/перемещению/вставке в середину иногда одиночных узлов, а иногда весьма ветвистых веток. Фактически, любое обновление сайта означает вставку одиночного узла, а если на сайте болтается какой-нить мультитоварный каталог посерьезнее — возникает необходимость делать вставки участков иерархии. Nested Sets для решения наших задач не подошло совсем — слишком много в общем случае объектов на update. Причем количество этих объектов, вообще говоря, не контролируется.
Это как с рекурсией. Рекурсия по дереву сверху вниз есть абсолютное зло, поскольку, находясь наверху, мы не можем оценить количество рекурсивных вызовов. С другой строны, рекурсия снизу вверх, при определенных обстоятельствах, вполне допустима — поскольку количество вызовов ограничено вложенностью начального узла.
Еще раз. Есть дерево. ветвистое. глубокое. Суммарно — около 100000 узлов, вложенность что-то порядка 15. Начинаем формировать дерево Nested Sets из имеющегося Adjacency List. Поскольку работа с деревом предполагает, в том числе, копирование, перемещение веток, а также вставку узлов в середину, данные перед вставкой берутся в сравнительно произвольном порядке. До 500 узлов тормозов не заметно, после начинаются нарастающие тормоза. Начиная с 700 узлов среднее время выполнения вставки составляет около минуты на узел. После вставки 1300 узлов процесс остановлен.
Опыт проводился на тестовом сервере (Athlon 2500XP) и на PostgreSQL 8.3. Для чистоты эксперимента был проведен раза три, с вариациями по порядку выборки исходного дерева. Существенных изменений в производительности не замечалось.
Железка, когда еще была боевым сервером, держала сайты суммарной посещаемостью около 800000 хитов в сутки + почту к этим сайтам и испытывала проблемы разве что от кривоватых рук тогдашнего админа (сволочь ротацию логов как-то совсем криво делал).
А с самими запросами ничего не делалось. просто вставлялся узел, потом апдейтилось дерево.
потому что дерево и граф — все-таки немного разны понятия. Графы в WEB (а иначе откуда берется мускуль, в отличие от деревьев, не юзаются). Для графа нужна совсем другая структура данных. по собственному опыту — мерзотная.
Неплохая статья. Хотя местами расходится с фактами.
Хотя данные в таком виде уже более приспособлены сразу для вывода, но, как видите, главный недостаток такого подхода — необходимо достоверно знать количество уровней вложенности в вашей иерархии, кроме того, чем больше иерархия, тем больше JOIN'ов — тем ниже производительность.
(про JOIN и про Adjacency List).
Там проблема скорее в ограничении количества таблиц, которые можно JOINуть. У Котерова был эксперимент — на ограничении 32 таблицы запрос по выборке дерева большого и сильно вложенного (уровень вложенности 8) с 32 JOINами работает (можно найти на dklab — проверял месяца три назад) примерно с той же скоростью, что и 8 JOINов (примерно с той же скоростью в данном случае означает флуктуации между запросами на уровне флуктуации скорости выполнения одного запроса)
NESTED SETS, если его попробовать (у меня ощущение, что про него пишут просто потому что он упоминается в любой статье про деревья) реально применить, годится либо для деревьев, которые никогда не будут меняться и данные в которые никогда не будут дописываться в середину дерева, либо для «кустиков» до 800 узлов суммарно. Потому как при больших (ударение на первую букву) размерах, вставка узла в середину начинает занимать около МИНУТЫ на не самом отстойном железе и внятно сконфигуренной базой. У Nested Sets имеется один единственный замечательный + — вывод дерева в правильном порядке.
Materialized Path в классическом виде хранит информацию о предках, а не порядок вывода по отношению к предкам. Если скомбинировать классический Materialized Path с Materialized Path, приведенным в этом примере, да еще написать правильную функцию сравнения того Materialized Path, в котором порядок вывода хранится, получится вполне внятное дерево, выводимое единым запросом в правильном порядке. Правда, остаются проблемы с переносом веток, но, проблемы эти решаются (т.е. перенос ветки с вложенностью 5 и 7000 потомков занимает, в среднем, около 2 секунд совместной работы PostgreSQL+PHP).
А в целом, хотелось бы в таких статьях (это вроде как уже не первая) побольше конкретики собственного опыта (я вырастил дерево такой-то вышины и такой-то ширины, и храню я это дерево там-то и там-то потому-тои потому-то)
Теперь внимание! В случае, если в лицензии прямо не было прямого указания на передачу определенных прав с перечислением этих прав, все права (и авторские, и смежные) сохраняются за автором. При этом вопрос оформления лицензии остается открытым — в общем случае годится все, начиная с устной договоренности. Более того — вопрос авторского права на программные продукты также не столь однозначен, как, например, на литературные произведения, фото и видео материалы.
А вообще, в данном случае, IMHO, если «Сайт довольно долго жил и развивался», и особых претензий к движку, видимо, не было, честно будет копирайт поставить. Если, при этом, движок «Хорошенько перелопа»чивался — поставить копирайт вроде «на основе такого-то».
Спасибо за ссылку — посмотрю обязательно.
Можно на эту тему почитать обсуждения предыдущих рейтингов здесь и на РОЕМе.
Я не предлагал делать капчу в виде анимированного квадратика)))
P.S. Нет —, конечно, догадывался, что к GD не обязательно лезть через PHP. Просто оно как-то всегда проходило как-то мимо.
Оченно даже полезно.
Впрочем, если учесть разницу в стоимости самосбора и готового решения вендора — можно было бы, пожалуй, и хранить.
P.S. Для людей, считающих, что сервер может быть собран только вендором, отвечающим за его качество, можно прикинуть добавочную стоимость от вендора (порядка 200%) и попробовать пересчитать ее на классические гарантии при сборке из запчастей (3 года — платформа=хорошей гарантии вендора, + 1 год — винты (суммарно не более 10% стоимости сервера) — если они будут лететь регулярно на следующий день после окончания гарантии — даст удорожание сборки на 20% — соответственно от прибыли вендора остается 180%), + 1 год — процессоры (20% стоимости сервера — если будут ломаться как винты, от прибыли вендора останется 140%), ну и память (как правило с пожизненной гарантией).
Конечно, собрать сервер — дело несколько более сложное, чем тачку домой, но, мне кажется, трата 2 — 3 дней на изучение материала, в данном случае, себя окупит.
А на новом сервере провести оптимизацию и тонкий тюнинг софта.
P.S. А может и над клиентской тоже.
P.P.S. ЗАкрыл вкладку файрфокса, потом попробовал открыть админку и получил «Warning: Smarty error: unable to read resource: „/desktop.tpl“ in /home/ibpro/public_html/smarty/Smarty.class.php on line 1092». Все-таки есть ощущение, что серверная частьчудит
А еще есть пара полезных операций — как то смена порядка следования детей внутри родительского узла (и лучше смена на произвольное количество позиций), а также копирование ветки (то есть добавление в середину дерева не узла, но ветви произвольного размера).
P.S. алгоритмы AL можно серьезно оптимизировать, добавив level и havechild (тот же самый уровень и признак наличия потомков) Происходит некоторое замедление добавления (принудительный апдейт или апдейт с проверкой), удаления и апдейта (на отдельных операциях — ровно на проверку а остались ли еще дети).
делать границы с шагом, разумеется, можно, но не универсально — а мы пытались выработать некий универсальный подход, который позволил бы нам работать с большими деревьями быстро и с минимальными затратами.
А предметная область удручающе банальна — web-дизайн. Мы используем дерево в качестве универсального хранилища данных для сайта/группы сайтов. Там, не то, чтобы постоянно, но регулярно возникают задачи по копированию/перемещению/вставке в середину иногда одиночных узлов, а иногда весьма ветвистых веток. Фактически, любое обновление сайта означает вставку одиночного узла, а если на сайте болтается какой-нить мультитоварный каталог посерьезнее — возникает необходимость делать вставки участков иерархии. Nested Sets для решения наших задач не подошло совсем — слишком много в общем случае объектов на update. Причем количество этих объектов, вообще говоря, не контролируется.
Это как с рекурсией. Рекурсия по дереву сверху вниз есть абсолютное зло, поскольку, находясь наверху, мы не можем оценить количество рекурсивных вызовов. С другой строны, рекурсия снизу вверх, при определенных обстоятельствах, вполне допустима — поскольку количество вызовов ограничено вложенностью начального узла.
Опыт проводился на тестовом сервере (Athlon 2500XP) и на PostgreSQL 8.3. Для чистоты эксперимента был проведен раза три, с вариациями по порядку выборки исходного дерева. Существенных изменений в производительности не замечалось.
Железка, когда еще была боевым сервером, держала сайты суммарной посещаемостью около 800000 хитов в сутки + почту к этим сайтам и испытывала проблемы разве что от кривоватых рук тогдашнего админа (сволочь ротацию логов как-то совсем криво делал).
А с самими запросами ничего не делалось. просто вставлялся узел, потом апдейтилось дерево.
(про JOIN и про Adjacency List).
Там проблема скорее в ограничении количества таблиц, которые можно JOINуть. У Котерова был эксперимент — на ограничении 32 таблицы запрос по выборке дерева большого и сильно вложенного (уровень вложенности 8) с 32 JOINами работает (можно найти на dklab — проверял месяца три назад) примерно с той же скоростью, что и 8 JOINов (примерно с той же скоростью в данном случае означает флуктуации между запросами на уровне флуктуации скорости выполнения одного запроса)
NESTED SETS, если его попробовать (у меня ощущение, что про него пишут просто потому что он упоминается в любой статье про деревья) реально применить, годится либо для деревьев, которые никогда не будут меняться и данные в которые никогда не будут дописываться в середину дерева, либо для «кустиков» до 800 узлов суммарно. Потому как при больших (ударение на первую букву) размерах, вставка узла в середину начинает занимать около МИНУТЫ на не самом отстойном железе и внятно сконфигуренной базой. У Nested Sets имеется один единственный замечательный + — вывод дерева в правильном порядке.
Materialized Path в классическом виде хранит информацию о предках, а не порядок вывода по отношению к предкам. Если скомбинировать классический Materialized Path с Materialized Path, приведенным в этом примере, да еще написать правильную функцию сравнения того Materialized Path, в котором порядок вывода хранится, получится вполне внятное дерево, выводимое единым запросом в правильном порядке. Правда, остаются проблемы с переносом веток, но, проблемы эти решаются (т.е. перенос ветки с вложенностью 5 и 7000 потомков занимает, в среднем, около 2 секунд совместной работы PostgreSQL+PHP).
А в целом, хотелось бы в таких статьях (это вроде как уже не первая) побольше конкретики собственного опыта (я вырастил дерево такой-то вышины и такой-то ширины, и храню я это дерево там-то и там-то потому-тои потому-то)