LiveStreet

На последний вопрос можно ответить сразу: сейчас логичнее использовать 2.6, потому что на 3.x портированы еще не все распространенные библиотеки, и (в случае веб-приложений) его почти нет на хостингах. Различий там полно, многие из них касаются ООП.
Анонимная функция достаточно распространенный термин, поэтому я и употребил именно его.
Про срезы и self напишу, но уже завтра. Предыдущие пожелания тоже учту.

Про print я упомянул, что речь идет о 2.5, функцией он стал в 3.0
Про alias и утиную типизацию разумно, надо дописать, но думаю, на уровне упоминания. По-хорошему про это надо отдельную подробную статью, но потом.

Если кдешники не найдутся, можно будет совместными усилиями :)

Лучше вы опишите wxPython, а я pyGTK. Тогда у читателей будет возможность сравнить и выбрать себе библиотеку по вкусу.

Сделал повыше. И правда силишком много оставил в анонсе.

Отличная идея. Даешь Веб 3.0 к 2010 году! :)
С удовольствием посмотрю код, и если позволит время, то приму участие.
Про документацию: документацию для разработчиков можно сделать посредством Doxygen или аналогичного инструмента. Хорошо экономит время и силы.

Для самого начала неплохо, хотя не без недостатков. Например, список я бы не стал называть массивом, пусть даже для новичка разница не критична.
> без этой строки употребление русско-язычных невозможно.
Нехорошо построенная фраза. Нужно написать, что невозможно использование чего невозможно.
Сейчас напишу «Наш ответ Чемберлену», более подробный :)

Возможно, но это будет весьма не быстро работать.
С запуском линуксовых программ в FreeBSD и Solaris проще, у них различаются только соглашение о системных вызовых (в линуксе параметры передаются через регистры, в BSD через стек), а API и формат исполняемого файла примерно одинаковый. Там не происходит полная эмуляция чужого ядра.
Совместимость на уровне исходного кода сделать проще, и даже логичнее. Кстати, в серверных версиях винды есть Services for UNIX, она же Interix, представляющая собой реализацию POSIX API для Win32 приложений.

По объектно-ориентированному уже много литературы, а вот функциональное большинсту разработчиков почти не знакомо :)

Следующий номер обещают в сентябре. Надеюсь, сдержат обещание и будут выпускать дальше.

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

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

Судя по всему, основная экономия там на софте для мейнфреймов, IBM деньги с клиентов драть умеет.
Стоимость владения линуксом и соляркой сравнима, а вот софт на C++ явно дешевле держать, чем на коболе — разработчиков на последнем уже почти не осталось.

Жаль, что я не в Одессе, и скорее всего не смогу там появится в это время. Но другу из Одессы передам :)

Нет смысла приписывать злые намерения тому, что можно объяснить глупостью ©
Может, конечно, но странноват способ, потому как компрометирует не СПО в целом, а конкретного исполнителя.

Никто не против, но с выбором исполнителя явно прокосячились.

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

Это как повезет. Если локализация нормально сделана, то да, а иной раз и программа хорошо написана, а локализация сделана таким способом, что ее исправление граничит с модификацией самого кода. Любимый мной OpenGoo яркий тому пример :)
А к перепиливанию/написанию SPEC-файлов (я работаю на rpm-based дистрибутивах) как-то привык уже.

Аналогично, часто сталкиваешься еще и с необходимостью применить напильник как минимум к локализации, а зачастую и к функциональной части :)
Но попробовать все же стоит.
Создал дискуссионную группу в гугле для обсуждений, комментарии в блоге, на мой взгляд, не лучший вариант. groups.google.com/group/floss-demoplatform. Желающие могут присоединяться.

Тогда предлагаю вариант первый.
Часть первая, организационная.
1. Формируется комитет из опытных пользователей, который осуществляет поиск, оценку перспективности и интереса программы, прием и рассмотрение предложений.
2. Путем обсуждения решается что из найденного и в какой очередности будут тестировать.
3. Кто-то из комитета или сторонний доброволец развертывает и настраивает выбранную программу.
4. После убеждения в работоспособности программы она открывается для публичного тестирования всеми желающими.
5. По результатам комитет формирует более или менее подробную оценку программы и выкладывает рецензию.

Часть вторая, техническая.
1. Берется виртуальный выделенный сервер (не так уж дорого, можно скинуться)
2. Выбранная программа развертывается в любом изолированном контейнере (chroot, jail, лучше виртуальная машина или контейнеры типа OpenVZ), для безопасности и удобства удаления по завершению.
3. Производятся вышеперечисленные действия.
Образ ВМ можно потом даже распространять для желающих самостоятельно повторить эксперимент.

Прошу объективной критики и предложений.