Интервью (http://www.informationweek.com/news/security/app-security/sh...) с Джимом Вайтхерстом (Jim Whitehurst), руководителем компании Red Hat. По словам Джима его фирма столкнулась с "идеальным штормом" в положительном смысле, который способствовал ее росту в период рецессии. Оправдала себя и модель подписки, 164.4 миллиона долларов из общего объема прибыли в $193.3 млн. за последний квартал получено именно за счет системы подписки на ПО. Что касается новых клиентов, то раньше их основная масса формировалась из-за перехода на Linux с Unix систем, а теперь наблюдается большой поток миграции с Windows. По данным Red Hat, под управлением Red Hat Enterprise Linux работает около 15% всех серверов в дата-центрах.
По прежнему большие план компания связывает с технологиями виртуализации, делая при этом ставку на систему KVM и пытаясь конкурировать с VMware. Вайтхерст утверждает, что KVM в RHEL 5.4 обеспечивает более высокую производительность, лучшую под...URL: http://www.informationweek.com/news/security/app-security/sh...
Новость: http://www.opennet.me/opennews/art.shtml?num=24933
"дробление кода и сообщества на несколько независимых частей, вместо того чтобы разрабатывать систему единой командой и под влиянием единого вектора развития." — это плохо только для коммерческих компаний, которые зарабатывают на ПОДДЕРЖКЕ Open Source продуктов. Однако для программистов, работающих по модели Open Source, форки, кастомизация продукта, портирование его на другие платформы с неизбежной переработкой исходного кода — единственный способ заработка. Именно в этой грани надо искать противоречие между трудом и капиталом.
Это вообще плохо. Если бы Unix в своё время не раздробили на подвиды, не было бы сейчас 95% винды на десктопах.
Учите историю. Windows продвинулась на десктопы и на сервера за счёт агрессивной политики распространения по каналам OEM-поставок оборудования. При этом вытеснялись альтернативные ОС.
Unix на серверах устоял благодаря той же политике — продажам вместе с оборудованием.
Silicon Graphics, Inc. привёл к краху засланный казачок из Microsoft — Рик Белуццо, который также "отличился" в попытке убийства HP/UX.
http://av5.com/journals-magazines-online/1/13/107
История говорит нам о том, что клиенты предпочитают вместо зоопарка консолидированное решение. Сегодня один юникс, завтра другой - кому это надо ?Если бы на серверах вместо десятков вариантов юникса тогда был один, то рынок поделился бы примерно пополам между Unix\Windows.
В подтверждение моих слов постоянный рост доли Linux на серверах. Рост устойчивый, постоянный и непрекращающийся. Клиенты видят, что в Linux можно вкладывать, потому что это стабильная и поддерживаемая сообществом и компаниями платформа для развёртывания приложений. Плюс это свободный софт, само собой. Вот вам и разница. Странно, что вы это не видите.
Списывать на отдельных засланных казачков провал концепции - на мой взгляд, это слабый аргумент. Ну попробуйте сейчас заслать в сообщество Linux казачка, что вы получите в ответ ? От ворот поворот, в лучшем случае. А в худшем могут и навалять, да так, что мало не покажется :-)
Я бы связал рост инсталляций серверной Винды также со (сказками) о том, что специалист более не нужен - сам директор сможет все администрировать в красивом графическом интерфейсе. Ну или технический директор (доверенный секретарь). Плюс в это время была полная совместимость с предыдущим Виндовым кодом.
Как только ОБА эти условия изменились - пошел рост инсталляций Линукса и БСД. А почему не Юникса - ввиду дешевизны (бесплатности) и сходного с Юниксом качества. Солярис не пошел ввиду дороговизны серверов.
мигель, например.
Очень часто мне думается, безотносительно самого проекта моно, что его агрессивное поведение просто раскалывает гном и многие просто отворачиваются.
Да ладно, Мигель с этим долбаным моно носится, конечно, как курица с яйцом, но гнома-то он писал, так что его казачком называть язык не поворачивается. Ну так бывает, все люди ошибаются (я про моно).
а доказать сможете?
Лехххко, см. выше :-)
После разделения проекта на две части, скорость развития и качество релизов заметно уменьшается раза в два - оба проекта начинают ходить по тем же граблям: разработчики дублировать работу, а тестировщики находить и исправлять те же баги, но только теперь в два раза медленнее.
> это плохо только для коммерческих компаний, которые зарабатывают на
> ПОДДЕРЖКЕ Open Source продуктов.Это плохо для всех. Гора одинаковых по смыслу недолелков вместо сильного продукта - ничего хорошего.
>Вайтхерст утверждает, что KVM в RHEL 5.4 обеспечивает более высокую производительность, ... чем в ранее используемых в RHEL решениях на базе XenНе вижу бенчмарков kvm+virtio vs paravirt xen.
Подозреваю, что вранье.
>>Вайтхерст утверждает, что KVM в RHEL 5.4 обеспечивает более высокую производительность, ... чем в ранее используемых в RHEL решениях на базе Xen
>
>Не вижу бенчмарков kvm+virtio vs paravirt xen.
>Подозреваю, что вранье.Может и вранье.
Но не будет же генеральный директор компании говорить "Да, мы разрабатываем KVM, но Xen лучше")
Такие слова чреваты падением прибыли.Если вы хотите узнать, что быстрее, лучший способ - провести тесты самому.
Ну, вообще, редхат обычно не только языком трындеть горазд. Посему даже если kvm не обгоняет, то уж будет обгонять как пить дать - редхат на ядро достаточно большое влияние оказывает. И уж наверное KVM у них будет доведен до ума.
И пускай ! Вот меня щас XEN очень радует, а если ещё и KVM будет работать не хуже, то вообще будет щястье :-)
Примерно одинаково, если суммировать результаты тестов.
http://virt.kernelnewbies.org/XenVsKVM
Xen, вроде бы, ругают за длинные конвееры. Бенчмарки есть, они легко гуглятся, даже несколько проскальзывало тут на opennet (был тест сравнения даже с ESXi, с которым нельзя сравнивать по условиям лицензии VmWare :)))На сколько я помню выводы, xen существенно уступает только в дисковых операциях, KVM реально использовать с централизованным NAS на NFS(о таком варианте использования рассказывал знакомый из RHT), а вот с файловым Xen уже не получится нормальной производительности.
З.Ы. У нас KVM и Xen виртуалки на локальных дисках(без СХД/NAS) с отдельными Logical Volumes под каждую виртуалку.