DiskCrypt — софт именно для защиты данных. Для сокрытия данных лучше применять FreeOTFE. В частности, FreeOTFE умеет создавать скрытые зашифрованные волюмы (внутри обычных зашифрованных волюмов), доказать наличие которых технически невозможно (и соответственно нельзя нести ответственность за сокрытие данных от ЦРУ/КГБ/хакеров).
Мог бы написать про экспериментальную ветку 0.9.x — там впервые появились 64-битные версии (хотя кому они нафиг нужны?) и поддержка UTF-8 в именах передаваемых файлов.
Потому что туториал писался под 2.x
Но уже где-то в 2.6 можно использовать print(), если импортировать его из будущего
В 3.x print по-моему нету (или есть, но потом не будет)
Если уже используешь Питон — медленно переползаешь с print на print(). Если только учишься — лучше сразу привыкать к print(). ИМХО.
Та же претензия, что и к «краткому» введению — используется print вместо print()
Поскольку присутствует академическое занудство, можно было бы упомянуть о том, что присваивание — это на самом деле alias (на эти грабли часто наступают)
По-хорошему следовало бы упомянуть об утиной типизации Питона (в конце концов, Питон вообще весь объектный, «под капюшоном»).
GTK сама по себе является не столь всеобъемлющей и занимается всё-таки в основном GUI. Векторное рисование выделено в библиотеку Cairo, кросс-платформенная базовая библиотека — в библиотеку GLib, объектная система — в библиотеку GObject, работа с HTTP/FTP — libsoup. Вот неплохая. Чем дальше от GUI, тем меньше вероятность того, что библиотека будет иметь какую-либо связь с GTK. В лучшем случае будет использовать GLib и/или GObject. Не знаю, какие библиотеки есть для работы с SQL, и имеют ли они отношение к GTK/GLib/GObject. Думаю, если глянуть на зависимости GTK'шных программ, работающих с SQL, то станет ясно.
Правильный перевод «We are not evil» — «Мы не злые». Чтобы было «Мы не зло», надо чтобы был артикль перед «evil» — либо «an» (абстрактное зло), либо «the» (конкретное зло).
Если ты смотрел презентацию про Google Wave, то должен знать, что увеличение скорости работы web-примочек — основа, на которой строятся все гугловские заморочки. Если решили делать такую OS — то видимо действительно есть какие-то значительные улучшения.
Вообще, интересная идея. Положительно отличается от проектов типа MyCoolOS тем, что web-приложения останутся кросс-платформенными. То есть изоляция из-за несовместимости приложений Хром-ОС вроде бы не грозит. В теории.
Вообще, я не эксперт в области экономики, но мне как-то сложно применить понятие «монополия» к Гуглу. То есть, если все покупают шмокобяки у тебя, потому что твои шмокобяки — лучшие, или потому что больше никто шмокобяки не продаёт — тогда ясно, это монополия. А если ты раздаёшь шмокобяки бесплатно? Или, допустим, ты предоставляешь услуги по буковыканью. И все обращаются к тебе за буковыканьем, потому что ты буковыкаешь лучше всех, или потому что больше никто не буковыкает — это монополия. А если ты буковыкаешь бесплатно?
Гугл зарабатывает на рекламе. Поэтому хочет, чтобы люди больше проводили времени в инете. Но ведь нет никакой гарантии, что при просмотре конкретной страницы будет отображаться реклама именно гугловская. Следовательно, Хром сам по себе не монополизирует рынок. Скорее, создаёт новую среду, в которой у него есть определённое преимущество (поскольку остальным участникам потребуется время, чтобы акклиматизироваться в этой среде), но не более того. Вот рынок рекламы в инете Гугл монополизировать в принципе может. Но этого пока не произошло (или произошло, но я не в курсе).
Относительно приведённого куска поясняю его смысл: если куски комбинированной программы ты написал сам, не основываясь на свободных кусках, и эти (свои) куски способны работать в отрыве от свободных кусков, ты можешь эти (свои) куски распространять как хочешь (потому что они твои) отдельно от свободных кусков. Но если ты распространяешь всё вместе, то оно должно быть свободным всё вместе (хочешь ты того или нет), и эти (свои) куски тоже становятся свободными.
То есть опять же, основной камень преткновения — вопрос о том, способны ли несвободные части произведения работать в отрыве от свободных (т.е. свободные части — опциональны). Если да, то GPL в принципе не нарушен, если обе части остаются отдельными [на уровне сырцов?] (не уверен, можно ли в таком случае распространять бинарники вместе, наверное — да). Но это уже тонкости.
Да, т.е. тот факт, что ты производишь комбинацию не на уровне сырцов, а только на уровне бинарников, никаких ограничений не снимает, даже если ты линкуешь в рантайме (dlopen), а не при запуске. Исключение — плагины (скорее всего потому, что комбинирование опционально и производится конечным пользователем, а не основным разработчиком), и то с ними не совсем понятно, что делать. Но если твоя программа тупо линкуется с GPL-библиотекой, то твоя программа либо должна быть GPL, либо не должна быть вообще :)
Итак, насчёт разных лицензий. Фактически, 3 варианта:
GPL — полная защита СПО, ничего комбинировать нельзя
LGPL — неполная защита СПО, можно комбинировать, но свободная часть остаётся свободной
3-clause BSD, MIT и аналоги — отсутствие защиты СПО, можно закрывать код
Надо сказать, что «комбинирование» — не совсем удачный термин. Строго говоря, GPL не запрещает комбинировать СПО и не-СПО. GPL запрещает распространять такую комбинацию без сырцов. То есть можно использовать GPL-библиотеки с проприетарным ПО. Но нельзя такое ПО распространять (вообще, можно попробовать распространять в виде сырцов, но тогда теряется основной смысл проприетарности).
Теперь, о бинарниках. Я в своё время направил подобный вопрос в FSF. Они мне сказали примерно следующее: степень интеграции двух программных объектов (СПО-объекта и не-СПО-объекта) определяется в суде. Если суд скажет, что имеет место комбинация, то разработчик нарушил GPL. Это касается таких экзотических способов как связывание GPL-библиотеки через сокет с проприетарной программой, так как с простой линковкой всё и так ясно — нельзя.
Сайт FSF отдельно говорит о плагинах (когда происходит динамическая линковка, но при этом отсутствует явная заточка головного ПО под плагин, то есть разработчики головного ПО не могут предвидеть, плагины под какими лицензиями будут комбинироваться с их ПО, поскольку интерфейс универсальный). Это — серая зона. В частности, известны проприетарные программы, под которые пишутся свободные плагины — и никто никого пока не судит.
Но уже где-то в 2.6 можно использовать print(), если импортировать его из будущего
В 3.x print по-моему нету (или есть, но потом не будет)
Если уже используешь Питон — медленно переползаешь с print на print(). Если только учишься — лучше сразу привыкать к print(). ИМХО.
Поскольку присутствует академическое занудство, можно было бы упомянуть о том, что присваивание — это на самом деле alias (на эти грабли часто наступают)
По-хорошему следовало бы упомянуть об утиной типизации Питона (в конце концов, Питон вообще весь объектный, «под капюшоном»).
Хотя нет, тогда 3.x получается тоже unstable…
Вообще, интересная идея. Положительно отличается от проектов типа MyCoolOS тем, что web-приложения останутся кросс-платформенными. То есть изоляция из-за несовместимости приложений Хром-ОС вроде бы не грозит. В теории.
Гугл зарабатывает на рекламе. Поэтому хочет, чтобы люди больше проводили времени в инете. Но ведь нет никакой гарантии, что при просмотре конкретной страницы будет отображаться реклама именно гугловская. Следовательно, Хром сам по себе не монополизирует рынок. Скорее, создаёт новую среду, в которой у него есть определённое преимущество (поскольку остальным участникам потребуется время, чтобы акклиматизироваться в этой среде), но не более того. Вот рынок рекламы в инете Гугл монополизировать в принципе может. Но этого пока не произошло (или произошло, но я не в курсе).
Если без библиотеки работает — то другое дело.
Но опять же — это тонкости. И см. замечание насчёт решения суда.
Относительно приведённого куска поясняю его смысл: если куски комбинированной программы ты написал сам, не основываясь на свободных кусках, и эти (свои) куски способны работать в отрыве от свободных кусков, ты можешь эти (свои) куски распространять как хочешь (потому что они твои) отдельно от свободных кусков. Но если ты распространяешь всё вместе, то оно должно быть свободным всё вместе (хочешь ты того или нет), и эти (свои) куски тоже становятся свободными.
То есть опять же, основной камень преткновения — вопрос о том, способны ли несвободные части произведения работать в отрыве от свободных (т.е. свободные части — опциональны). Если да, то GPL в принципе не нарушен, если обе части остаются отдельными [на уровне сырцов?] (не уверен, можно ли в таком случае распространять бинарники вместе, наверное — да). Но это уже тонкости.
GPL — полная защита СПО, ничего комбинировать нельзя
LGPL — неполная защита СПО, можно комбинировать, но свободная часть остаётся свободной
3-clause BSD, MIT и аналоги — отсутствие защиты СПО, можно закрывать код
Надо сказать, что «комбинирование» — не совсем удачный термин. Строго говоря, GPL не запрещает комбинировать СПО и не-СПО. GPL запрещает распространять такую комбинацию без сырцов. То есть можно использовать GPL-библиотеки с проприетарным ПО. Но нельзя такое ПО распространять (вообще, можно попробовать распространять в виде сырцов, но тогда теряется основной смысл проприетарности).
Теперь, о бинарниках. Я в своё время направил подобный вопрос в FSF. Они мне сказали примерно следующее: степень интеграции двух программных объектов (СПО-объекта и не-СПО-объекта) определяется в суде. Если суд скажет, что имеет место комбинация, то разработчик нарушил GPL. Это касается таких экзотических способов как связывание GPL-библиотеки через сокет с проприетарной программой, так как с простой линковкой всё и так ясно — нельзя.
Сайт FSF отдельно говорит о плагинах (когда происходит динамическая линковка, но при этом отсутствует явная заточка головного ПО под плагин, то есть разработчики головного ПО не могут предвидеть, плагины под какими лицензиями будут комбинироваться с их ПО, поскольку интерфейс универсальный). Это — серая зона. В частности, известны проприетарные программы, под которые пишутся свободные плагины — и никто никого пока не судит.