В таком случае, что мешает выдирать видео из HTML5 ?)
То, что идет через флеш-плейер, явно сжато не свободным кодаком, а тем же h.264. Я подозреваю, что выбор Google был основан именно на внутреннем формате хранения видео для YouTube. Не пережимать же это все еще раз. И скорее всего именно поэтому Google выступал за h.264 при обсуждении стандарта. Тогда не договорились по-хорошему, будут по-плохому. Даже возможностей Google не хватит, чтобы держать все видео в двух форматах. И если в браузеры воткнуть Theora не проблема, по большому счету, то в новые телефоны — неоправданно дорого. Не говоря уже о существующих
Что касается лично меня, Linux-пользователя, не то чтобы да :) Мы можем хоть оббороться, игнорируя ютюбный HTML5, и продолжать смотреть не менее проприетарный флеш, который кроме всего прочего еще и жрет проц как не в себя. Борьба тут получается из разряда «куплю билет — на зло кондуктору пойду пешком». Я думаю, что и Google и Vimeo понимают проблему лучше нас всех, и сами себя загонять в ловушку не станут. Они сделали выбор, теперь выбор за производителями браузеров и аппаратных решений, для которых, кстати, h.264 — уже стандарт де-факто.
В Linux все ставят mp3 кодеки, флеш-проигрыватели и прочие несвободные вещи. Просто потому, что по-другому никак. В то же время, если будет прецедент и за проигрывание mp3 попытаются брать деньги, люди просто перестанут им пользоваться. При нормальной, высокой конкуренции, сделать платным такую вещь очень сложно. Представьте себе, что, скажем, Google сделает почту платной? Ей просто перестанут пользоваться, благо альтернатив куча. То же самое и с кодеками. Владельцы патентов при всем желании не смогут удержать пользователей, попытавшись брать деньги за свои технологии. Если H.264 действительно дает лучшее качество или им это дешевле, удобней, проще, гиганты будут использовать его. Что сделает, в свою очередь, этот кодек стандартом де-факто, как было с mp3. А в пакет ubuntu-restricted-extras добавится еще один бинарник.
ActiveX гвоздями вбит разве что в каких-нибудь enterprise приложениях, где люди не имеют выбора. Ресурсы же, которые вынуждены бороться за аудиторию от него стараются отказаться.
Удачно у вас получилось там нащелкать :) Я один раз на мобилу сфотографировал центральный вход в Ангстрем, так меня боевые бабушки под белы рученьки и потребовали засветить пленку :)
В хроме после клика правой кнопкой на верхнем флешовом банере хабры, банер замирает вместе с флешом на любых других страницах. После этого нигде не работает. Сыроватенькая бета получилась
Тоесть вы сами проверяете все изменения разработчиков? У вас нет отдела тестирования и continious integration? Я вот все думаю как заставить Hudson дружить с такой кучей веток.
Я говорю не только и не столько о скорости, сколько о простоте. Ветви в SVN, даже в 1.6 гораздо менее удобны, чем в том же git. Именно это отторгает разработчиков от их использования. Люди не хотят «бренчеваться» до тех пор, пока это возможно. По опыту разработки в нескольких компаниях с SVN вижу, что решение «не коммититься» возникает естественным путем у совершенно несвязанных между собой людей.
Я очень надеюсь, что DVCS изменят эту ситуацию. Потому что ситуация, когда средство разработки влияет на workflow не лучшим образом, мне кажется сильно неправильной.
ведь все остальные базовые операции (ветвление, слияние, метки) — большинство систем делает почти одинаково эффективно, только с некоторыми различиями, связанными с реализацией
Даже со скидкой на «почти» это очень спорное утверждение. Т.к. многие базовые операции реализованы принципиально по-другому и справляются с ними распределенные системы и центральные очень по-разному.
Это не только и не столько балансер, сколько обеспечение реданденси, защита от физического выгорания одного из спаренных узлов. Тогда адрес переключится на запасной.
Доступ к машинам по исходным адресам тоже есть. Но обычно надо попасть на «активную»
Да. Виртуальный адрес висит на полноценном интерфейсе.
В общем, мы не можем предугадать какая физическая машина обслужит нас по этому виртуальному адресу в конкретный момент.
known_hosts при коллизии приходится чистить
Поэтому я и писал про фиксированный набор машин.
У нас далеко не локальная зона. Куча vpn-ов к заказчикам, на всех не наподымаешься :)
Кроме того, у нас часто используются виртуальные адреса балансера, за которым живет несколько реальных машин, в этом случае ssh сильно огорчается, когда видит в known_hosts другой хэш машины. Я не проверял еще решает ли ваше предложение эту проблему.
То, что идет через флеш-плейер, явно сжато не свободным кодаком, а тем же h.264. Я подозреваю, что выбор Google был основан именно на внутреннем формате хранения видео для YouTube. Не пережимать же это все еще раз. И скорее всего именно поэтому Google выступал за h.264 при обсуждении стандарта. Тогда не договорились по-хорошему, будут по-плохому. Даже возможностей Google не хватит, чтобы держать все видео в двух форматах. И если в браузеры воткнуть Theora не проблема, по большому счету, то в новые телефоны — неоправданно дорого. Не говоря уже о существующих
2. Get it from fring’s WAP site:
• On your Android phone, go to Settings > Applications and check the box to allow ’unknown sources’
• Point your phone browser to m.fring.com and download
Я очень надеюсь, что DVCS изменят эту ситуацию. Потому что ситуация, когда средство разработки влияет на workflow не лучшим образом, мне кажется сильно неправильной.
Даже со скидкой на «почти» это очень спорное утверждение. Т.к. многие базовые операции реализованы принципиально по-другому и справляются с ними распределенные системы и центральные очень по-разному.
Очень доволен устройством.
Доступ к машинам по исходным адресам тоже есть. Но обычно надо попасть на «активную»
В общем, мы не можем предугадать какая физическая машина обслужит нас по этому виртуальному адресу в конкретный момент.
known_hosts при коллизии приходится чистить
У нас далеко не локальная зона. Куча vpn-ов к заказчикам, на всех не наподымаешься :)
Кроме того, у нас часто используются виртуальные адреса балансера, за которым живет несколько реальных машин, в этом случае ssh сильно огорчается, когда видит в known_hosts другой хэш машины. Я не проверял еще решает ли ваше предложение эту проблему.