fossplanet.ru: Архив
2008-08-01 - 2008-08-31
Всем, кто интересуется детским образованием и еще не зафрендил
mex3_course, советую это сделать, по крайней мере до окончания курсов, репортажи о которых ведут Александра Панюкова и Михаил Якшин.
Выступление Greg Kroah Hartman в Google в июне 2008 с объяснением процесса разработки ядра Linux:
http://www.youtube.com/v/L2SED6sewRw Рекомендую.
Небольшой обзор последних изменений в connexion на тему кластеризации (вешаю hook, чтобы не засорять ленту многими буквами). mDNS/heartbeat, всё такое. Кластеризация шагает по коду семибитными^W семимильными шагами :)
Натали Леднева продолжает публиковать интервью с участниками школьного проекта из ALT Linux. Вслед за
Аней Шадеевой,
Тарасом Абламским и
Алексеем Русаковым, --
рассказ о Виталии Кузнецове.
Только что в апелляционном суде США (United States Court of Appeals for the Federal Circuit) закончилась
апелляция по делу Jacobsen vs. Katzer and KAMIND Associates, Inc. В рамках апелляции было признано, что свободная лицензия Artistic License является значимой в рамках законодательства по авторскому праву. Суд прямо ссылается на класс лицензий, который представляют Artistic License, Creative Commons, GNU General Public License и другие, как на лицензии со значимыми условиями в поле закона об авторском праве, а не только вид договора. Нарушение значимых условий в лицензии, касающейся авторских прав, в американском юридическом поле означает нарушение авторского права. Если бы положения лицензии были бы договорными, то их нарушение рассматривалось бы в рамках контрактного законодательства, а не авторского права.
Важность этого дела состоит в том, что Artistic License опирается на ту же концепцию значимых условий в авторском праве, на которой выстроены Creative Commons, GNU General Public License и некоторые другие свободные лицензии. То, что суд прямо ссылается на них в обосновании решения, позволяет разработчикам свободного ПО в рамках прецедентного законодательства США иметь хорошие шансы на положительные решения по делам об нарушении их авторских прав.
Другим важным аспектом стало разъяснение суда того, что отсутствие финансовых условий в лицензии не является разрешением не соблюдать остальные условия лицензии. Суд специально объясняет, что именно структура условий в свободной лицензии Artistic License позволяет автору организовать распространение и работу над его произведением таким образом, что автор получает доход от производных работ. То, что этот доход не выражается в финансовых терминах, не делает условия менее защищенными юридически.
Текст решения очень хорошо сформулирован. Вот типичный пример:
The clear language of the Artistic License creates conditions to protect the economic rights at issue in the granting of a public license. These conditions govern the rights to modify and distribute the computer programs and files included in the downloadable software package. The attribution and modification transparency requirements directly serve to drive traffic to the open source incubation page and to inform downstream users of the project, which is a significant economic goal of the copyright holder that the law will enforce. Through this controlled spread of information, the copyright holder gains creative collaborators to the open source project; by requiring that changes made by downstream users be visible to the copyright holder and others, the copyright holder learns about the uses for his software and gains others' knowledge that can be used to advance future software releases.
При чем здесь "любишь кататься"? Дело в том, что Якобсен организовал проект по созданию ПО для управления моделями поездов. А Катцер и его компания использовали код из проекта Якобсена для своих коммерческих продуктов (моделей поездов и систем управления ими) с нарушением условий Artistic License. Если вспомнить, что термин "хакеры" пришел из MIT 60-х годов, где студенты и сотрудники занимались моделированием железнодорожного движения и были увлечены построением сложных сетей переключения семафоров и стрелок, то историчность этого дела станет понятна...
В своем
пространном интервью Сергею Голубеву я говорил о большом, если не бОльшем, интересе сельских учителей к внедрению СПО, что многих удивило. Помимо более высокого социального статуса учителя на селе и лучше сохранности кадров в 90-х, есть, видимо, еще одна причина, -- меньшее число семейных компьютеров и, тем более, -- личных компьютеров учеников. То есть школьный компьютерный класс, тем более с подключением к Интернет, на селе действительно является центром притяжения для детей. А интерес детей вызывает интерес учителя, стремление удивить учеников, показать что-то новое (если он, конечно, хоть немного учитель).
С одной стороны, нельзя не порадоваться за сельских детей и учителей. С другой стороны, как мы все надеемся, скоро и на селе почти у всех детей будет компьютер, потому важно понять проблемы, которые мы сейчас видим в больших городах. Подчеркну, дело тут не в СПО, а в том, что школа не дает никаких новых возможностей в сравнении с теми, которые есть у каждого дома. Даже если московские власти вдруг раскошелятся и поставят в школу очень мощные PC, завтра, если не вчера, они будут у учеников дома, да еще и с таким софтом, который власти не купят.
Видимо, для школ нужны принципиально иные решения для преподавания IT, которых дома нет и не будет. И эти решения должны стать продолжением личного компьюетра школьника, а не его устаревшим аналогом.
Мы как раз
говорим об этом с
abbra, присоединяйтесь, если интересно.
В списке рассылки emacs-devel уже которую неделю идет бурная дискуссия о том, как будет развиваться Emacs.
Все началось с того, что кто-то пожаловался на проблемы со сборкой емакса на висте, и Столлман незамедлительно влез на свой любимый пенек и начал призывать к бойкоту проприетарных систем и призывать всех пользователей к переходу на Линукс. При этом он игнорировал практически все письма пользователей, что windows часто используется из-за того, что на линукс нет многих программ, нужных для работы и т.п.
Сейчас дискуссия свернула в сторону обсуждения того, что нужна ли в емаксе возможность загрузки бинарных модулей для расширения функциональности емакса (у кого-то уже есть такой патч, да и как показывает практика разработки SXEmacs, такая функциональность вполне востребована), и опять позиция Столлмана выливается в то, что эта возможность в емаксе не нужна, поскольку кто-то может написать закрытый модуль и загружать его в емакс. Все возражения о том, что "популярные" закрытые модули, могут спровоцировать разработку таких же, но открытых модулей, также отметаются...
Почему-то мне больше всего такая позиция Столлмана напоминает "Сказку о тройке", когда кто-то пытается решать за людей "кто чем должен пользоваться и т.п."
P.S. очень будет жаль, если разработчики емакс пойдут в этом русле (как предлагает столлман)... Придется мигрировать мне на SXEmacs :-(
На следующей картинке можно наблюдать как silicium сидит в недрах большой машины и водружает туда ALT ;)

Я обычно мало пишу о работе, потому что это не очень интересно рассказывать, да и не могу от имени компании выступать. Зато могут заказчики рассказывать. :-) Вот таиландская компания, которая занимается производством мультфильмов, выложила ролик о том, как для их нового мультфильма было важно создание единой системы хранения:
http://www.youtube.com/v/4dvqCjpy7OAВнутри у нее неонка, уже упоминавшаяся
Scale-out File System (SoFS), внутри которой есть еще две неонки: Samba 3 и CTDB 1.0. И вот без них слонов не было бы. :-)
С подачи
bugware я играюсь с Vala и построением интерфейсов на GTK+.
Vala -- это такой продвинутый макротранслятор с C#-подобного по синтаксису языка на C с активным применением GObject. Все, что не очень хорошо читалось в коде на C при программировании GTK+, преображается в Vala.
Мы строим интерфейс программы в Glade, конвертируем его с помощью gtk-builder-convert в формат, который понимает класс Gtk.Builder из GTK+ 2.14 и старше, а затем динамически загружаем этот интерфейс в программу и используем его.
Сам по себе Vala -- полноценный язык, на нем можно просто писать приложения и без использования GTK+. В данном случае мне было интересно, а как сделать так, чтобы интерфейс рисовался в Glade, грузился во время исполнения, а обработчики сигналов к элементам интерфейса задавались бы в виде лямбда-функций, которые поддерживаются в Vala.
Естественно, можно автоматически связывать обработчики сигналов с загруженным интерфейсом через Gtk.Builder.connect_signals(), который просто берет имена обработчиков из описания интерфейса и ищет эти символы в загруженном приложении. Но хотелось разобраться с лямбдами.
Код приложения на Vala, в котором у нас в интерфейсе только две работающие команды: File->Open вызывает диалог выбора файла (и показ имени выбранного файла), а File->Quit выполняет выход из программы, выглядит так:
using GLib;
using Gtk;
public class App : Gtk.Builder {
private Gtk.Window _main_window;
public Gtk.Window window { get { return _main_window; }}
public signal void open_file(string file_name);
public void exit_with_message_on_error(string error_message) {
Gtk.MessageDialog message = new
Gtk.MessageDialog(null, DialogFlags.MODAL,
MessageType.ERROR, ButtonsType.OK,
error_message);
message.run();
message.destroy();
Gtk.main_quit();
/* never reached */
}
public void connect_my_signals(Gtk.Builder builder, GLib.Object object,
string signal_name, string handler_name,
GLib.Object connect_object, GLib.ConnectFlags flags) {
Gtk.Action action = object as Gtk.Action;
if (null == action) {
exit_with_message_on_error("Expected Gtk.Action!\n");
return;
}
switch (signal_name) {
case "activate":
switch (action.name) {
case "File|Menu|Open":
/* Define signal handler as lambda function */
action.activate += (app) => {
Gtk.FileChooserDialog fchooser = new
Gtk.FileChooserDialog("Open a file", (app as App).window,
FileChooserAction.OPEN,
STOCK_CANCEL, ResponseType.CANCEL,
STOCK_OPEN, ResponseType.ACCEPT);
int result = fchooser.run();
fchooser.hide();
if (result == ResponseType.ACCEPT) {
open_file(fchooser.get_filename());
}
fchooser.destroy();
};
break;
/* This is File|Quit in our sample UI */
case "File|Menu|Quit":
action.activate += Gtk.main_quit;
break;
default:
break;
}
break;
default:
break;
}
}
public void process_files() {
try {
add_from_file("myapp.gtk");
} catch (GLib.Error er) {
exit_with_message_on_error(er.message);
return;
}
_main_window = get_object("main_window") as Gtk.Window;
connect_signals_full(connect_my_signals);
_main_window.destroy += Gtk.main_quit;
_main_window.realize();
_main_window.show_all();
/* Process file opening after selection as lambda function */
open_file += (app, file_name) => {
Gtk.MessageDialog message = new
Gtk.MessageDialog(app.window, DialogFlags.MODAL,
MessageType.INFO, ButtonsType.OK, file_name);
message.run();
message.destroy();
};
Gtk.main();
}
static int main (string[] args){
Gtk.init(ref args);
App app = new App();
app.process_files();
return 0;
}
}
В App.connect_my_signals() мы используем switch для расстановки наших обработчиков сигналов. В Gtk.Builder предполагается, что мы по имени обработчика, прописанного в интерфейсе, можем определить какую функцию в нашем коде регистрировать как сигнал (если используем штатный Gtk.Builder.connect_signals(), который делает это автоматически).
В нашем случае мы хотим эти сигналы связать вручную (у лямбда-функций нет заранее известных имен). Для повышения читаемости исходного кода на Vala мы используем switch по имени сигнала и по имени виджета, к которому относится сигнал. Имена виджетов, как и имена обработчиков сигналов, мы задаем в Glade (или руками в файле описания интерфейса Gtk.Builder) заранее, поэтому можем сами себе гарантировать их уникальность. Поскольку по этим именам виджетов Gtk.Builder делает поиск ссылок между объектами при загрузке описания интерфейса, то имена попадают в специальный кэш, используемый функциями g_quark_from_string()/g_quark_from_string_static(). Туда же попадают и имена сигналов, которые регистрируют классы GObject при создании их в системе.
То есть, к моменту вызова App.connect_my_signals() у нас в кэше кварков уже есть все нужные строки и сравнение по ним будет довольно эффективным. Чего не скажешь об именах обработчиков сигналов, описанных в файле интерфейса: эти имена используем только мы и только в момент назначения сигналов.
В результате (можно посмотреть на сгенерированный Vala код на C), получается довольно эффективный код, который в своем первоначальном виде на Vala к тому же хорошо читаем человеком. А это, пожалуй, главное. Для автоматической регистрации пришлось бы только вместо connect_signals_full() вызывать connect_signals(self), но тогда бы лямбды не использовались. Реализацию оставлю вам. :-)
Код примера вместе с описанием интерфейса можно скачать здесь:
http://boids.name/extract/myapp.tar.bz2Собирается он так:
valac -g --pkg glib-2.0 --pkg gtk+-2.0 myapp.vala, запускать надо myapp.
P.S. В Сизиф я Vala скоро соберу, текущая работа идет тут:
http://git.altlinux.org/people/ab/packages/vala.git. Есть несколько нюансов, связанных с тем, что я хочу аккуратно запаковать все расширения, чтобы у них были правильные зависимости. Но это будет скоро сделано.
Наверное, сначала стоит рассказать о том, как дети восприняли систему, в которой они работали. А восприняли они ее, пожалуй, ещё лучше, чем в прошлом году: некоторые радовались ("Ура, снова линукс! Я всю зиму ждал!"), некоторые с интересом ("Что это такое? А я смогу дома это запустить? Вы подарите диск? Правда? Суперрр!"), некоторые равнодушно ("мне без разницы, что тут - главное, я хочу научиться").
Alexey Tourbin (
svpv)
24.08.2008 20:38:37
Опять программировал rpm5.org, немножко
переписал код в районе rpmdbNextIterator, в котором теперь исправлен
бесконечный цикл.
Вспомнил песенку из детства:
Раз подругу посадил на мотоцикл,
У неё от страха прекратился цикл...
Ещё несколько проблем нужно решить, прежде чем этот код можно будет взять в
альтовский rpm. В общем, очень такой специфический мотоцикл этот rpm.
Назад