Как вариант — PortableOpenOffice.org на флэшке. Но проще действительно сделать экспорт в PDF и печатать уже его; SumatraPDF на флэшке — на всякий случай ;)
Сам так делаю.
Если вдуматься, то это фактически повторение того, что микрософт (в теории) сделало давным-давно. Известно, что винда имеет несколько подсистем поверх ядра, которые способны обеспечивать работу разных программ. Подсистема Win32 используется почти эксклюзивно, но вообще есть и POSIX-подсистема (сейчас она вроде называется Interix). LUC фактически делает то же самое, но несколько грубее (вместо иерархии «ядро-подсистемы» получается один кусок «ядро-с-разными-интерфейсами»). Что в принципе ожидаемо (Linux — монолитное ядро by design).
Интересует меня то, как оно всё вместе увязывается. То есть, смогут ли виндовые дрова (использующие NT-интерфейс ядра) обеспечивать работу устройств так, чтобы ими могла пользоваться остальная часть ОС (использующая POSIX-интерфейс ядра)? Как будет осуществляться IPC (не считая bsd-сокетов) между программами, использующими разные интерфейсы («подсистема» Win32 у них, я так понимаю, использует NT-интерфейс ядра, иначе она бы ничем от Wine не отличалась)? Как там обстоят дела с файловой системой (в NT концепция единой файловой системы с монтируемыми директориями есть, а в Win32 — нету)?
И, что самое главное, чем это концептуально лучше использования кросс-платформенных приложений под ReactOS (то есть, все программы виндовые и запускаются нативно, некоторые из них — кросс-компилируемые; в крайнем случае можно использовать POSIX-подсистему)?
Я думаю чтение вот бояна должно напомнить, как именно получилось такое большое количество сущностей. Так что я бы сказал, что это более-менее естественный процесс. Только в мире СПО с ним пытаются бороться (сравните степень унификации в дистрибутивах GNU/Linux сегодня и 7 лет назад), а в мире ППО — наоборот, культивируют, по маркетинго-политическо-экономическим причинам.
from __future__ import print_function
a = 3
def somefun ():
a = 1
if a == 1:
print ("a == 1! {0}".format (a))
a = 2
print ("a == 2? {0}".format (a))
def fun2 (arg):
a = 5
print ("arg == {0}".format (arg))
print ("Now a == {0}".format (a))
fun2 (a)
print ("a before leaving somefun() == {0}".format (a))
a = 4
somefun()
print ("global a = {0}".format (a))
Вопрос для зубров: что выведет на stdout интерпретатор? Чтобы узнать это, не запуская интерпретатор, надо знать о том, как и чем в Питоне образуются скопы, и в каком порядке они просматриваются.
В частности, в отличие от C, в Питоне простые стэйтменты управления потоком вычисления (flow control; то есть if, for, while) не имеют собственного скопа, а переменные из глобального скопа являются read-only: попытка записать что-то в такую переменную без предварительной декларации её в качестве global в локальном скопе ведёт к созданию локальной переменной с тем же именем, с которой и проводятся все последующие операции.
Убунту вообще отличается меньшей протестированностью по сравнению с Debian (чем достигается большая частота релизов), так что результат, я бы сказал, ожидаемый.
В СПО в принципе считается хорошей практикой ставить последние ревизии более старых версий (которое уже опробованы на практике и в которых почти все проблемы решены) вместо нулевых ревизий свежевыпущенных версий (которые с почти 100% вероятностью имеют баги, избежавшие beta-тестирования, поскольку в отличие от микрософта у СПО как правило штат beta-тестеров несколько меньше, и железо у этих тестеров не покрывает весь спектр возможных конфигураций).
В данном случае стабильным следует считать 9.10 (который вышел полгода назад, в конце Октября).
Не заню насчёт открытого, но что касается свободного ПО, то оно полностью несовместимо с мультиплэерными играми. Ибо одна из основных идей игр — искусственно ограничивать возможности игрока, чтобы создать сложную ситуацию, которую нужно преодолеть. Это включает в себя отсутствие автоматизации расчётов и действий, а также сокрытие от игрока информации, которая на самом деле наличествует в программе. Это напрямую противоречит идеям свободного ПО. А преодоление этих «недостатков» (получение информации, которой у тебя не должно быть, автоматизация действий, которые ты должен был бы сам делать) назвается читерством.
С однопользовательскими играми несколько попроще — можно положиться на то, что игрок не будет жульничать (ибо этим он лишь обыграет сам себя), но в мультиплэере это не катит. Лучшее, что можно придумать — это очень ограниченный протокол обмена информацией между клиентом и сервером, чтобы у клиента просто физически не было неположенной информации. С автоматизацией тут никак не справиться.
Всё это весьма печально, поскольку именно мультиплэерная модель (создание некой игровой платформы, в которой игродел принимает постоянное и активное участие) позволяет получить гарантированную прибыль, в то время как сиглплэерные игры можно просто скопировать и распространить, не с чего рубить бабло.
Поэтому на мой взгляд коммерческого будущего у свободных игр нет (ну, если не считать лохотронов, когда делают ребрэндинг СПО и продают его).
Можно пытаться выделять общую функциональность в библиотеки и делать их свободными, а модули отвечающие за базовую логику, контроль над целостностью и игровой интерфейс оставлять проприетарными.
В этом случае я бы посоветовал LGPL (v3).
Делай то, что советует инсталлер операционки. Как правило это способ, который укладывается в концепцию её использования -> меньше проблем (очевидно, что нестандартные для данной ОС решения будут влечь за собой нестандартные неисправности). Кроме того, решение проблем для стандартной конфигурации легче найти. И это всё верно не только для домашнего компьютера, но и для сервера (ибо решение проблем с сервером ещё более критично).
1) Декодэры в foobar2000 — гаплесс по дефолту
2) Любой проигрыватель на основе GStreamer, использущий playbin2 — гаплесс по дефолту
3) Файлы могут иметь гап сами по себе. Это проблема не декодэра, а файла.
Я научился пользоваться OO.org Writer'ом, весьма доволен. Работает ЛОГИЧНО и использует структурный подход к документам. Мне это, как IT-шнику, весьма подходит. Я делал РПЗ для диплома с помощью Writer'а. Автоматическая нумерация формул оказалась весьма кстати. Как и автоматическое содержание (автоматическим списоком лит-ры я научился пользоваться несколько позже).
Calc тоже нравится, делает всё, что мне нужно. Хотя есть две вещи, которые там отсутствуют:
1) Функции для бинарных операций над числами
2) Масштабирование данных для графиков (хотя вообще это почти что выходит за рамки задач Calc'а)
OO.org Math — просто сказка, лучше MS'овского аналога на порядок.
Остальными программами из пакета почти не пользовался (ну, кроме Draw, ничего конкретного сказать про него не могу).
Меня вообще удручает, что в 2008 и 2009 годах я был единственным участником из МИРЭА. Да и вообще по России нас человек 30 набиралось, наверное… Видимо языковой барьер слишком высокий.
Лично я подбирал проекты из уже представленных, хотя конечно организации принимают и проекты, идеи которых были предложены студентами.
Но выбирать из представленных проектов удобнее — почти гарантированно есть ментор (тот, кто предложил проект) и, ИМХО, более высокие шансы быть принятым (в уже представленных организацией проектах разработчики обычно изначально заинтересованы, а в проектах предложенных студентами разработчики могут не заинтересоваться).
Почему нет — уже объяснял Файрболл. И ещё раз объяснит, если потребуется (благо Опенлайф он читает). Поскольку к Google и ReactOS я не имею отношения, то распространяться на эту тему не буду.
Всё просто. Свободное и открытое ПО — это две цели, которые достигаются подчас одними и теми же средствами. Сторонников СПО интересует свобода как таковая, для них собода разработчика, пользователя и дистрибьютора одинаково важны, потому что это наличие свободы по их мнению этически важно. Сторонников ОПО интересует совместная работа коллективов людей (разработчиков, тестеров, переводчиков, дизайнеров и т.д.) для быстрой и эффективной разработки качественного и надёжного ПО, потому что это экономически выгодно. В большинстве случаев ПО попадает как под определение СПО, так и под определение ОПО, потому что СПО (и GPL) всё-таки появилось раньше, а ОПО просто расширило изначальное определение, расщепив основные 4 критерия СПО на множество под-критериев и выкинув ненужные. Однако люди, которые пишут ПО, обязательно попадают только в одну категорию, соответственно со своими намерениями.
Сам так делаю.
Интересует меня то, как оно всё вместе увязывается. То есть, смогут ли виндовые дрова (использующие NT-интерфейс ядра) обеспечивать работу устройств так, чтобы ими могла пользоваться остальная часть ОС (использующая POSIX-интерфейс ядра)? Как будет осуществляться IPC (не считая bsd-сокетов) между программами, использующими разные интерфейсы («подсистема» Win32 у них, я так понимаю, использует NT-интерфейс ядра, иначе она бы ничем от Wine не отличалась)? Как там обстоят дела с файловой системой (в NT концепция единой файловой системы с монтируемыми директориями есть, а в Win32 — нету)?
И, что самое главное, чем это концептуально лучше использования кросс-платформенных приложений под ReactOS (то есть, все программы виндовые и запускаются нативно, некоторые из них — кросс-компилируемые; в крайнем случае можно использовать POSIX-подсистему)?
Вопрос для зубров: что выведет на stdout интерпретатор? Чтобы узнать это, не запуская интерпретатор, надо знать о том, как и чем в Питоне образуются скопы, и в каком порядке они просматриваются.
В частности, в отличие от C, в Питоне простые стэйтменты управления потоком вычисления (flow control; то есть if, for, while) не имеют собственного скопа, а переменные из глобального скопа являются read-only: попытка записать что-то в такую переменную без предварительной декларации её в качестве global в локальном скопе ведёт к созданию локальной переменной с тем же именем, с которой и проводятся все последующие операции.
В СПО в принципе считается хорошей практикой ставить последние ревизии более старых версий (которое уже опробованы на практике и в которых почти все проблемы решены) вместо нулевых ревизий свежевыпущенных версий (которые с почти 100% вероятностью имеют баги, избежавшие beta-тестирования, поскольку в отличие от микрософта у СПО как правило штат beta-тестеров несколько меньше, и железо у этих тестеров не покрывает весь спектр возможных конфигураций).
В данном случае стабильным следует считать 9.10 (который вышел полгода назад, в конце Октября).
С однопользовательскими играми несколько попроще — можно положиться на то, что игрок не будет жульничать (ибо этим он лишь обыграет сам себя), но в мультиплэере это не катит. Лучшее, что можно придумать — это очень ограниченный протокол обмена информацией между клиентом и сервером, чтобы у клиента просто физически не было неположенной информации. С автоматизацией тут никак не справиться.
Всё это весьма печально, поскольку именно мультиплэерная модель (создание некой игровой платформы, в которой игродел принимает постоянное и активное участие) позволяет получить гарантированную прибыль, в то время как сиглплэерные игры можно просто скопировать и распространить, не с чего рубить бабло.
Поэтому на мой взгляд коммерческого будущего у свободных игр нет (ну, если не считать лохотронов, когда делают ребрэндинг СПО и продают его).
Можно пытаться выделять общую функциональность в библиотеки и делать их свободными, а модули отвечающие за базовую логику, контроль над целостностью и игровой интерфейс оставлять проприетарными.
В этом случае я бы посоветовал LGPL (v3).
2) Любой проигрыватель на основе GStreamer, использущий playbin2 — гаплесс по дефолту
3) Файлы могут иметь гап сами по себе. Это проблема не декодэра, а файла.
Calc тоже нравится, делает всё, что мне нужно. Хотя есть две вещи, которые там отсутствуют:
1) Функции для бинарных операций над числами
2) Масштабирование данных для графиков (хотя вообще это почти что выходит за рамки задач Calc'а)
OO.org Math — просто сказка, лучше MS'овского аналога на порядок.
Остальными программами из пакета почти не пользовался (ну, кроме Draw, ничего конкретного сказать про него не могу).
ие кнопкиНо выбирать из представленных проектов удобнее — почти гарантированно есть ментор (тот, кто предложил проект) и, ИМХО, более высокие шансы быть принятым (в уже представленных организацией проектах разработчики обычно изначально заинтересованы, а в проектах предложенных студентами разработчики могут не заинтересоваться).