Не знаю, не знаю - когда я даю английские цитаты даже здесь, на Хабре (где публика не самая русофобская) их мало кто прочитывает... А если отойти от IT, то и вообще...
В конце-концов фильмы и сериалы находится кому переводить и выкладывать - почему для сайтов того же не может случиться ? Другое дело - масштабы. Хорошо если 1% будет переводиться...
Люди, которые работают непрофессионально - матеряться тоже. И дело тут в мелочах, на самом деле. Даже не в том что Photoshop чего-то такое умеет чего GMIP не умеет (такие вещи тоже есть, но их немного). Главное - интерфейс совсем другой. Лучше/хуже - неважно. Другой. И нужно ему учиться фактически с нуля.
Правда в последних версиях Wine Photoshop 7 работает пристойно, но Photoshop CS 3 - чегой-то сомневаюсь (у меня его нет и желания его искать тоже, в общем, нет). Гонки преледования получаются. Вот если фирма-производитель заточит продукт под Wine - получается гораздо лучше (см. Picasa for Linux). Так что если у Adobe есть желание...
На самом деле самая большая проблема электронных переводчиков сейчас - это отсуствие большого массива переведенных текстов - в которых можно было бы понять какое cловосочетание оригинала соответствует какому словосочетанию перевода (переводить отдельные слова, а потом составлять из них предложения, увы, нельзя). Если такие тескты появятся во множестве - качество и ПРОМПТа и Google Translate'а можно будет заметно улучшить. Но вот настолько ли чтобы включить его в GTalk или ICQ ? Сложный вопрос... не знаю...
P.S. Эсперанто - тупиковая ветвь. Просто потому что пока знающих его - не сотни миллионов полезнее изучать английский или там китайский. А разница в скорости изучения до уровня "могу свободно читать и говорить" - не так велика. Эсератно можно выучить "до конца", а английский - нет, но с точки зрения практики разница невелика...
Проблема орбитального прыжка в том что нужна теплозащита чтобы не сгореть "при входе в плотные слои атмосферы". Фактически нужно спускаться в мини-космическом корабле. Тянуть такое на орбиту или суборбиту - маразм. Хотя теоретически возможно...
F1000 - это список самых забюрокротизированных компаний где рулит принцип "никто ещё не был уволен за выбор продукции IBM^H^H^HMicrosoft". Особенно это верно для не-IT компаний (которых там болльшинство). Скажем если http://www.dupont.com рухнет - много ли денег компания потеряет ? Как наладили они свою инфраструктуру лет 10-15 назад - так она и сейчас стоит...
Если прыжок с МКС совершишь - то это будет смертельно. Если что-то произойдёт в космосе - то кранты сразу (никакая система спуска не поможет). Вот из стратосферы - да, можно. Иногда. Если повезёт...
Это для нас привязка к оператору - нонсенс. В Штатах подавляющее большинство телефонов продаются лочеными, в Японии - 99.99%. Так что вряд ли. Другое дело что могут договориться с ещё какими-нибудь другими операторами...
Потому же почему Sun угрохал много лет на то чтобы открыть сначала Solaris, потом Java'у: нужно убедиться в том что у тебя есть права на то чтобы это сделать, а сейчас мало кто делает всё сам и если проект изначально не был рассчитан на OpenSource'инг - это сделать непросто...
Это космопорт для туристров :-) Если бы оттуда летали в космос, а не "запрыгивали" - тогда да. А так и сам полёт состваляет 0.1% от стоимости "настоящего" и космопорт тоже в 1000 дешевле.
P.S. Только не надо думать что я проект осуждаю: невесомость там вполне натуральная, космос - тоже самый что ни на есть, с точки зрения "человеческих" ощущений всё почти как в большом полёте. А невозможность "крутиться вокруг шарика" сутками - так ли уж это критично для туриста ?
Рейтрейсинг на мало-мальски сложных объектах приводит к достаточно случайным обращениям к разным частям модели. Против этого восстаёт вся "потоковая" организация видеокарты (да и современных CPU, если уж на то пошло: никогда не задумывались почему RayTracing считают на кластерах и никогда - на суперкомпьютерах?)... Да, некоторые приёмы могут снизить эту проблему - но в едва достаточной степени чтобы его можно было эффективно на CPU исполнять (и даже там латентность памяти частенько доминирует), а его архитектура куда менее "заточена" под потоковые исполнения...
- OSPF использует Дейкстру для того чтобы уравлять роутингом, так что возникают проблемы с ресурсами, но есть у него и другие проблемы. Хотя на самом деле главная проблема в том что просто когда вопрос встал то было проще перейти от IGP к BGP чем придумать реализацию OSPF, которая бы скалировалась на весь Internet. К тому же BGP легко позволяет врать (не передавать соседям полную информацию о своей связности) и он остается при этом работоспособен, а с OSPF это сложнее.
- EGMP ? Если вы от "Ethernet Group Membership Protocol" (никакого другого EGMP, увы, не знаю) - то у него вообще ограничений масса (прямо из названия понятно)...
- 192.168.0.18&~255.255.255.224=0.0.0.16, а должно быть 0 (хотя это хороший вопрос для админа, а не для программиста: чистый вопрос на знание)
- последнего вопроса не понял, но наверное имеется ввиду CISCO/NGINX/TUX vs Apache/MySQL ? в первом случае одна нить обрабатывает десятки заданий - для этого нужно представить обработку каждого запроса как конечный автомат и аккуратно следить за состояниями оного, во втором - одна нить обслуживает одного клиента. Первый вариант требует меньше ресурсов, но гораздо сложнее в написании и отладке (в случае сложных сервисов большой проблемой становится влияние разных запросов друг на друга).
Не вижу в чём проблема с вашими вопросами: 1й и 3й хорошие вопросы чтобы поговорить о них с пристрстием (там есть о чём поговорить), 2й - простой тест на знание TCP/IP (в принципе какое-то понятие о нём у программиста должно быть, хотя не знаю - насколько оно реально нужно: ЭТА деталь из TCP/IP "наверх" почти никогда "наверх" не протекает)...
Исходники они открыть не могут (видимо в 3D-части хватает лицензированных у других разработок). Обещают открыть спеки. Посмотрим. Если будут спеки, а не отписка - можно брать ATI и забыть про мучения с NVidia...
P.S. В общем-то открытия спеков ждали с момента покупки ATI. Хорошо что ожидания не обманулись (а на исходники особенно народ и не рассчитывал)... Плохо будет если спеки будут сильно урезанные (скажем не будет возможности переложить декодирование H.264 на видеокарту), но с учётом того что у NVidia и этого нету... В общем будем ждать...
1. Да, разумеется - ибо это обязанность подателя заявки доказывать что она чего-нибудь стоит, а не наоборот.
2. ODF не подавался в ISO как средство решения проблемы чтения документов DOC/XLS/etc; OOXML подавался - и при этом он не содержит способов чтения этих документов; единственная разумная интерпретация это "описание конвертора не нужно ибо все пользующие DOC/XLS/etc скоро перейдут на OOXML и всем будет щастя горстями"... но перехода пока не наблюдается...
Никак ибо даже при наличии очень хорошей электрифицированной отвертки гвозди приходится вколачивать молотком...
jQuery можно использовать для того чтобы вызвать в нужный момент валидатор - а собственно проверка она чисто на JS пишелся. Но все эти решения, которые создают framework для проверки форм вам кажутся слишком тяжёлыми...
Zeroglif написал грамотный комментарий. jQuery (как и большая часть других фреймворков) пытается обойти тот печальный факт, что JavaScript в большинстве browser'ов не поддерживает XPath. И, соответсвенно, использование jQuery провоцирует написание кода, который будет безумно тормозить. И вам всё равно придётся спускаться на уровень JavaScript'а (хорошо если не ниже).
Вроде бы самые вопиющие проблемы со скоростью в 1.1.4 поправили - но эта версия ещё слишком молода, чтобы её можно было рекомендовать всем и вся, а 1.1.2 - просто слишком медленная в большинстве случаев. Но даже и 1.1.4 нельзя и сравнить с прямым использованием JavaScript'а. По моему ниша jQuery досточно узка: его стоит использовать тогда когда в проект нужно что-то добавить "сбочку" без больших переделок движка. Ну и для прототипов/внутренних проектов, когда скорость разработки важнее качества результата. Но для внутренних разработок можно просто использовать имеющийся в Mozilla (и движках на основе Mozilla) XPath - и не мучиться ни с какими фреймворками!
P.S. Оценка способностей человека к выполнению работы по выполненной работе - это ни в каком смысле не замер "прямых показателей" (если это не ACM contest или TopCoder). Ибо стартовые условия в реальной жизни у всех - разные и они вносят подавляющий вклад в результат. Гораздо больший чем способности самого человека. Умение грамотно решать задачки - гораздо более прямой показатель, так как они гораздо меньше зависят от предистории: тябе обычно мало волнует кем был человек - куда важнее кем он стал, а людям свойственно меняться и, увы, не всегда в лучшую сторону... "Идеал объективности", конечно, недостижим, но стремиться к нему стоит...
Собственно основной постулат прост: хороший программист имеет рудиментарные познания про всё что лежит "под ним", но главное - он умеет думать. Хороший ворос - не вопрос, требущий глубинных знаний (для ответов на такие вопросы есть Yandex и Google), а вопрос, на который можно ответить зная лишь основопологающие принципы и имею голову на пречах. Знать основопологающие принципы в смежных областях - всегда полезно, а голова на плечах - она просто необходима...
Как раз для людей "пишущих 3д движкии и подобные вещи" часто подобные проблемы оказываются сложнее, чем для "простых смертных". Они слишком много знают - и потому начинают мыслить с уровня шейдеров, ограничений в Cg и прочих высокоуровневых вещей - а там не так всё ужасно и вроде бы RayTracing должен бы быть возможен, но нет: "протекают" сюда (через все слои абстракций) весьма глубинные вещи, тесно связанные с законами физики, а не подробности GPU, с которыми обычно имеет дело "программист, пишущий 3д движки"...
Да низачем, в общем-то. Но дело в том что для ответа на этот вопрос нужно знать два с половиной факта:
1. Видеокарты используют очень широкую шину
2. Видеокарты используют много параллельных конвееров для рассчёта 3D
3. Видеопамять оптимизирована под большую пропускную способность и [относительно] большие задержки (во-первых это уже не так важно, а во-вторых можно догадаться про это из пункта 1)
Положа руку на сердце: вы действительно этих фактов не знаете ? Это как с задачами про мячики для гольфа, блендеры, мосты и прочее: формально про свойства этих объектов вы знать ничего не должны, но если вы совсем ничего про них не знаете - это вызывает недоумение. То же и с видеокартой: чтобы ответить на вопрос про неё знать нужно очень мало - примерно столько сколько знает нормальный человпек, который ежедневно общается с компьютером или даже чуть меньше (более подробные знания устройства видеокарты, конечно, помогут, но они не нужны!!!)...
И насколько это всё поможет - тоже интересный вопрос: JS-можно ускорить в 10-20 раз, а толку ? Если тормозит в основном DOM...
В конце-концов фильмы и сериалы находится кому переводить и выкладывать - почему для сайтов того же не может случиться ? Другое дело - масштабы. Хорошо если 1% будет переводиться...
P.S. Не путать vi с vim'ом!!!
Правда в последних версиях Wine Photoshop 7 работает пристойно, но Photoshop CS 3 - чегой-то сомневаюсь (у меня его нет и желания его искать тоже, в общем, нет). Гонки преледования получаются. Вот если фирма-производитель заточит продукт под Wine - получается гораздо лучше (см. Picasa for Linux). Так что если у Adobe есть желание...
P.S. Эсперанто - тупиковая ветвь. Просто потому что пока знающих его - не сотни миллионов полезнее изучать английский или там китайский. А разница в скорости изучения до уровня "могу свободно читать и говорить" - не так велика. Эсератно можно выучить "до конца", а английский - нет, но с точки зрения практики разница невелика...
P.S. Только не надо думать что я проект осуждаю: невесомость там вполне натуральная, космос - тоже самый что ни на есть, с точки зрения "человеческих" ощущений всё почти как в большом полёте. А невозможность "крутиться вокруг шарика" сутками - так ли уж это критично для туриста ?
- EGMP ? Если вы от "Ethernet Group Membership Protocol" (никакого другого EGMP, увы, не знаю) - то у него вообще ограничений масса (прямо из названия понятно)...
- 192.168.0.18&~255.255.255.224=0.0.0.16, а должно быть 0 (хотя это хороший вопрос для админа, а не для программиста: чистый вопрос на знание)
- последнего вопроса не понял, но наверное имеется ввиду CISCO/NGINX/TUX vs Apache/MySQL ? в первом случае одна нить обрабатывает десятки заданий - для этого нужно представить обработку каждого запроса как конечный автомат и аккуратно следить за состояниями оного, во втором - одна нить обслуживает одного клиента. Первый вариант требует меньше ресурсов, но гораздо сложнее в написании и отладке (в случае сложных сервисов большой проблемой становится влияние разных запросов друг на друга).
Не вижу в чём проблема с вашими вопросами: 1й и 3й хорошие вопросы чтобы поговорить о них с пристрстием (там есть о чём поговорить), 2й - простой тест на знание TCP/IP (в принципе какое-то понятие о нём у программиста должно быть, хотя не знаю - насколько оно реально нужно: ЭТА деталь из TCP/IP "наверх" почти никогда "наверх" не протекает)...
P.S. В общем-то открытия спеков ждали с момента покупки ATI. Хорошо что ожидания не обманулись (а на исходники особенно народ и не рассчитывал)... Плохо будет если спеки будут сильно урезанные (скажем не будет возможности переложить декодирование H.264 на видеокарту), но с учётом того что у NVidia и этого нету... В общем будем ждать...
2. ODF не подавался в ISO как средство решения проблемы чтения документов DOC/XLS/etc; OOXML подавался - и при этом он не содержит способов чтения этих документов; единственная разумная интерпретация это "описание конвертора не нужно ибо все пользующие DOC/XLS/etc скоро перейдут на OOXML и всем будет щастя горстями"... но перехода пока не наблюдается...
jQuery можно использовать для того чтобы вызвать в нужный момент валидатор - а собственно проверка она чисто на JS пишелся. Но все эти решения, которые создают framework для проверки форм вам кажутся слишком тяжёлыми...
Вроде бы самые вопиющие проблемы со скоростью в 1.1.4 поправили - но эта версия ещё слишком молода, чтобы её можно было рекомендовать всем и вся, а 1.1.2 - просто слишком медленная в большинстве случаев. Но даже и 1.1.4 нельзя и сравнить с прямым использованием JavaScript'а. По моему ниша jQuery досточно узка: его стоит использовать тогда когда в проект нужно что-то добавить "сбочку" без больших переделок движка. Ну и для прототипов/внутренних проектов, когда скорость разработки важнее качества результата. Но для внутренних разработок можно просто использовать имеющийся в Mozilla (и движках на основе Mozilla) XPath - и не мучиться ни с какими фреймворками!
P.S. Оценка способностей человека к выполнению работы по выполненной работе - это ни в каком смысле не замер "прямых показателей" (если это не ACM contest или TopCoder). Ибо стартовые условия в реальной жизни у всех - разные и они вносят подавляющий вклад в результат. Гораздо больший чем способности самого человека. Умение грамотно решать задачки - гораздо более прямой показатель, так как они гораздо меньше зависят от предистории: тябе обычно мало волнует кем был человек - куда важнее кем он стал, а людям свойственно меняться и, увы, не всегда в лучшую сторону... "Идеал объективности", конечно, недостижим, но стремиться к нему стоит...
Как раз для людей "пишущих 3д движкии и подобные вещи" часто подобные проблемы оказываются сложнее, чем для "простых смертных". Они слишком много знают - и потому начинают мыслить с уровня шейдеров, ограничений в Cg и прочих высокоуровневых вещей - а там не так всё ужасно и вроде бы RayTracing должен бы быть возможен, но нет: "протекают" сюда (через все слои абстракций) весьма глубинные вещи, тесно связанные с законами физики, а не подробности GPU, с которыми обычно имеет дело "программист, пишущий 3д движки"...
1. Видеокарты используют очень широкую шину
2. Видеокарты используют много параллельных конвееров для рассчёта 3D
3. Видеопамять оптимизирована под большую пропускную способность и [относительно] большие задержки (во-первых это уже не так важно, а во-вторых можно догадаться про это из пункта 1)
Положа руку на сердце: вы действительно этих фактов не знаете ? Это как с задачами про мячики для гольфа, блендеры, мосты и прочее: формально про свойства этих объектов вы знать ничего не должны, но если вы совсем ничего про них не знаете - это вызывает недоумение. То же и с видеокартой: чтобы ответить на вопрос про неё знать нужно очень мало - примерно столько сколько знает нормальный человпек, который ежедневно общается с компьютером или даже чуть меньше (более подробные знания устройства видеокарты, конечно, помогут, но они не нужны!!!)...