Да не развалится, но темпы развития снизится могут. А ведь осенью Центос6…
openSuSE хорошая система, но два года это слишком короткий жизненный цикл для сервера.
На дебиан еще можно, хотя управлять серверами на нем мне не особо понравилось.
Как это ни печально, но выбор пригодных для серверов дистров крайне мал.
zhnikitka: Хоть я сам такое не люблю, но штука интересная, спасибо за наводку.
Что до менеджера пакетов и репозитария, то я давно собирался им заняться и когда-то набросал архитектуру этого дела. Если есть располагающие свободным временем и желанием, то можно заняться.
Этот вариант не намного лучше просто сайта со ссылками на скачивание программ.
Кроме того, он создает ряд проблем, таких как отслеживание зависимостей и обновления.
Я полагаю, что действительно привлечь пользователей можно только реализацией, близкой по функциональности к линуксовым менеджерам пакетов или портажам *BSD.
Мне мысль про менеджер пакетов для винды давно приходила в голову, и, в принципе, windows installer умеет отслеживать зависимости. Но объем работ тут будет существенно больше: пересборка пакетов, создание .msi, написание менеджера пакетов. Плюс еще нужны сервер и место на нем под репозитарии.
На это нужен уже не один человек, если желаете присоединится, пишите на почту или в сообщения.
plin2s: о, надо учесть его.
axm: разумеется. Для счастья человеческого и делаю :)
Осталось только придумать, куда это все выложить, потому как там уже два с лишним гигабайта.
О, надо обмениваться опытом! Внесу то, что есть в моем, но пока нет в вашем на досуге.
zvie: да, разумно. Поставлю чуть позже, ну и после релиза он доступен будет.
У Google Chrome с лицензией не вполне понятно. Код объявлен доступным, но у бинарных сборок типичная проприетарная лицензия.
Про Songbird надо учесть, и правда забыл про него.
connect_simple я не нашел, но не особо и искал. Надо глянуть в доки.
Убить сразу можно, но мало ли чего еще захочется сделать при получении сигнала? Закрыть соединения, например, или еще чего-то в этом духе.
Поэтому я для всех обработчиков делаю отдельные методы, на случай если потребуется туда что-то еще дописать.
Я просто хотел показать, как пишутся обработчики событий и сигналов, и что они выглядят немного по-разному.
Конечно, здесь со второго обработчика пользы никакой, но для ознакомления пусть будет.
Если нетбинс качать будешь, то вроде пайтон там отдельным пакетом пока. Но для мелких программ и скриптов они оба слишком уж тяжелы, реальная потребность в них возникает при больших проектах из многих файлов.
Именнно редактор даже не знаю. Если IDE, то Eclipse, в последней версии NetBeans тоже поддержка его есть.
Есть некая Idle, менее навороченная, но я ее не пробовал.
На первый взгляд вполне себе хорошая библиотека, и статья понятно написано. Разве что пару слов об архитектуре wxWidgets добавить, может быть, имеет смысл.
С меня теперь по pyGTK :)
openSuSE хорошая система, но два года это слишком короткий жизненный цикл для сервера.
На дебиан еще можно, хотя управлять серверами на нем мне не особо понравилось.
Как это ни печально, но выбор пригодных для серверов дистров крайне мал.
Что до менеджера пакетов и репозитария, то я давно собирался им заняться и когда-то набросал архитектуру этого дела. Если есть располагающие свободным временем и желанием, то можно заняться.
Кроме того, он создает ряд проблем, таких как отслеживание зависимостей и обновления.
Я полагаю, что действительно привлечь пользователей можно только реализацией, близкой по функциональности к линуксовым менеджерам пакетов или портажам *BSD.
На это нужен уже не один человек, если желаете присоединится, пишите на почту или в сообщения.
axm: разумеется. Для счастья человеческого и делаю :)
Осталось только придумать, куда это все выложить, потому как там уже два с лишним гигабайта.
Только сделайте лучше кросспост, а не ссылку — читать станет гораздо удобнее.
zvie: да, разумно. Поставлю чуть позже, ну и после релиза он доступен будет.
JRE придеться включить, она для NetBeans нужна как минимум.
А вот OpenJDK под винду пока нету, она только для линукса и солярки.
Про Songbird надо учесть, и правда забыл про него.
Убить сразу можно, но мало ли чего еще захочется сделать при получении сигнала? Закрыть соединения, например, или еще чего-то в этом духе.
Поэтому я для всех обработчиков делаю отдельные методы, на случай если потребуется туда что-то еще дописать.
Конечно, здесь со второго обработчика пользы никакой, но для ознакомления пусть будет.
Есть некая Idle, менее навороченная, но я ее не пробовал.
С меня теперь по pyGTK :)