У нас что хотят, то и творят. Мне, например, в Нормане запрещали записывать цены на бумажку (прикидывал сумму на банкет). Про фотографировать или снимать видео в магазине я вообще молчу, ногами вперед вынесут, хотя и не имеют права:
По России они не проедут, т.к. у автопилота нет прав, со всеми вытекающими за каждым кустом.
Да и то, что итальянцы называют дорогами, у нас отсутствует. По чему машина будет ориентироваться? Не по спутнику же, при том, что у нас карт нормальных нет.
Понятно. Только возникает логичный вопрос: какой смысл переводить описание, если само приложение все равно англоязычное (а таких немало)? Не логичнее ли это делать одновременно?
Получается, что тем самым «домохозяйкам» от работы, упомянутой в посте, все равно ни жарко, ни холодно, только разочарование будет еще больше: прочитала «рекламу», установила, а там ей фига :)
Кстати, какова схема обновлений переводов при обновлении самих приложений?
Сколько раз встречал частичные переводы в разных пакетах, которые явно возникали из-за добавления новых функций в приложение. Такие пакеты возвращаются в исходную очередь?
1. «Потому что Linux сейчас, преимущественно, серверная платформа»
Круто. Это FreeBSD, NetBSD, OpenBSD и т.п. преимущественно серверные, GNU/Linux же нужно специально затачивать под серверное использование. Да и что плохого в том, что люди хотят на десктопе получить надежность сервера?
2. «Уже сейчас полным ходом идет портирование ReactOS на ARM»
И как там будет работать виндовый софт? Портирование самой операционки и нативного софта — это вопрос времени, только как же первоначальная цель проекта?
В любом случае, идея продвижения альтернативной операционки, тем более совместимой с виндовыми приложениями, конечно, хороша, но мне кажется, что линукс тут спокойно всех задавит, а совместимость с виндовыми приложениями не настолько критична, как кажется (тем более, что есть wine, а ресурсы нетбуков будут только расти).
Про смысл спрашивайте у авторов драйверов. Куда проще сделать обертку, чем два раза реализовать взаимодействие с железом через совершенно разные API.
Насколько я помню, тип реализации можно посмотреть через какие-то функции OGL: софтовая, аппаратная, софтово-аппаратная. Последние как раз обычно и являются оболочками если не напрямую для DX, то для драйвера, созданного для работы с DX, а это по сути тот же костыль, только без лишней прослойки.
Абсолютно некорректная статья. Сравнивать фотки и ПО совершенно бессмысленно.
Свободное ПО делается для людей, чтобы они этим ПО пользовались. А чужими фотографиями обычный человек пользуется только двумя основными способами: любуется ими на сайте автора (или его страничке на фоторесурсе) или ставит их на рабочий стол (как вариант сохраняет в какой-нибудь папочке) все в тех же целях.
Первое вообще никак не запрещено, а второе как раз разрешают все виды CC (с оговоркой, что изменение размера фотки под рабочий стол мы не будем считать переработкой, хотя формально это не так).
Запрет на изменение: фотография — это не ПО, там нечего исправлять и доделывать. Людей, которые любят делать коллажи из чужих фотографий просто ради собственного удовольствия на самом деле очень мало, соответственно, переработка чужих фотографий требуется либо в коммерческих целях, либо в опосредованно коммерческих (всякие развлекательные сайты с добавлением пользовательских надписей на фотки и т.п.).
Может сервер из-за высокой нагрузки проигнорировал (или не получил) поисковый запрос?
Причин много разных может быть. У нас сервер иногда так тормозит, что сообщения в общий чат проходят секунд через 30-50 после отправки.
Клиенту все равно сколько там шара. Поисковый запрос отправляется на сервер, сервер рассылает его всем подключенным клиентам с указанием координат отправителя, после этого клиенты, обнаружившие у себя совпадения, отправляют ответы напрямую запрашивавшему.
Именно из-за такого алгоритма ограничена частота повторных запросов и то, что ответы приходят как попало (пока до конкретной машины дойдет запрос, пока он поищет у себя, пока дойдет ответ...), особенно при условии подключения не через локалку (т.е. по медленным каналам).
Таки виндовые OpenGL драверы обычно и являются оберткой над DirectX. Не очень понятно, в чем проблема, кроме того, что лишняя прослойка может глючить и тормозить.
Более того, не очень понятно, почему бы не сделать абстрактную реализацию OpenGL поверх DirectX, тогда и жаловаться на отсутствие драйверов будет незачем. Есть родные OGL драйвера, используйте их, нет родных, используйте универсальный OGL > DX адаптер. Возможно такая штука даже есть в готовом виде, я просто никогда не интересовался, но в стародавние времена встречал довольно глючные попытки подобных реализаций.
Ну вот на моем скриншоте шара только на одном хабе 1.13 петабайт, и это далеко не рекорд данного хаба. Правда, это локалка и напрямую хаб из инета недоступен.
А в чем проблема с поиском?
Так тут как настроишь. Даже XP понимает 4ГБ.
Если видяшка мапится в до 4ГБ, то будет видно чуть меньше 4ГБ оперативки, а если в BIOS отправить видяшку за пределы 4ГБ, то вполне можно выжать и 4ГБ. Просто в винде многие драйверы видеокарточек страшно глючат, если память видеокарты мапится за пределы 4ГБ.
В линухе вроде с этим легче, но в любом случае лучше брать x86-64 дистрибутив и не париться, если железо позволяет.
Да и то, что итальянцы называют дорогами, у нас отсутствует. По чему машина будет ориентироваться? Не по спутнику же, при том, что у нас карт нормальных нет.
Получается, что тем самым «домохозяйкам» от работы, упомянутой в посте, все равно ни жарко, ни холодно, только разочарование будет еще больше: прочитала «рекламу», установила, а там ей фига :)
Сколько раз встречал частичные переводы в разных пакетах, которые явно возникали из-за добавления новых функций в приложение. Такие пакеты возвращаются в исходную очередь?
Круто. Это FreeBSD, NetBSD, OpenBSD и т.п. преимущественно серверные, GNU/Linux же нужно специально затачивать под серверное использование. Да и что плохого в том, что люди хотят на десктопе получить надежность сервера?
2. «Уже сейчас полным ходом идет портирование ReactOS на ARM»
И как там будет работать виндовый софт? Портирование самой операционки и нативного софта — это вопрос времени, только как же первоначальная цель проекта?
В любом случае, идея продвижения альтернативной операционки, тем более совместимой с виндовыми приложениями, конечно, хороша, но мне кажется, что линукс тут спокойно всех задавит, а совместимость с виндовыми приложениями не настолько критична, как кажется (тем более, что есть wine, а ресурсы нетбуков будут только расти).
Насколько я помню, тип реализации можно посмотреть через какие-то функции OGL: софтовая, аппаратная, софтово-аппаратная. Последние как раз обычно и являются оболочками если не напрямую для DX, то для драйвера, созданного для работы с DX, а это по сути тот же костыль, только без лишней прослойки.
Свободное ПО делается для людей, чтобы они этим ПО пользовались. А чужими фотографиями обычный человек пользуется только двумя основными способами: любуется ими на сайте автора (или его страничке на фоторесурсе) или ставит их на рабочий стол (как вариант сохраняет в какой-нибудь папочке) все в тех же целях.
Первое вообще никак не запрещено, а второе как раз разрешают все виды CC (с оговоркой, что изменение размера фотки под рабочий стол мы не будем считать переработкой, хотя формально это не так).
Запрет на изменение: фотография — это не ПО, там нечего исправлять и доделывать. Людей, которые любят делать коллажи из чужих фотографий просто ради собственного удовольствия на самом деле очень мало, соответственно, переработка чужих фотографий требуется либо в коммерческих целях, либо в опосредованно коммерческих (всякие развлекательные сайты с добавлением пользовательских надписей на фотки и т.п.).
Причин много разных может быть. У нас сервер иногда так тормозит, что сообщения в общий чат проходят секунд через 30-50 после отправки.
Именно из-за такого алгоритма ограничена частота повторных запросов и то, что ответы приходят как попало (пока до конкретной машины дойдет запрос, пока он поищет у себя, пока дойдет ответ...), особенно при условии подключения не через локалку (т.е. по медленным каналам).
Более того, не очень понятно, почему бы не сделать абстрактную реализацию OpenGL поверх DirectX, тогда и жаловаться на отсутствие драйверов будет незачем. Есть родные OGL драйвера, используйте их, нет родных, используйте универсальный OGL > DX адаптер. Возможно такая штука даже есть в готовом виде, я просто никогда не интересовался, но в стародавние времена встречал довольно глючные попытки подобных реализаций.
А в чем проблема с поиском?
Если видяшка мапится в до 4ГБ, то будет видно чуть меньше 4ГБ оперативки, а если в BIOS отправить видяшку за пределы 4ГБ, то вполне можно выжать и 4ГБ. Просто в винде многие драйверы видеокарточек страшно глючат, если память видеокарты мапится за пределы 4ГБ.
В линухе вроде с этим легче, но в любом случае лучше брать x86-64 дистрибутив и не париться, если железо позволяет.