> Стоимость поддержки и электроэнергии - это разве принципиальные отличия?Не поверите, но более чем принципиальные. Представьте сколько энергии жрет стандартная 49U стойка, забитая 1U-серваками, у каждого из которых пусть даже один 300W блок питания.
Хоть это и совершенно некорректное сравнение ужа с ежом, но предположим, что у гипотетического сервера (пусть даже не SPARC, а вообще любого) столько же ядер, памяти и дискового пространства. И он один стоит дороже кучи этих дешевых серверов. Предположим (что еще более фантастично, но раз уж начали сравнивать такое, то чего уж там) - у них примерно одинаковая производительность (мы ведь в любом случае должны учитывать накладные расходы распределенных вычислений). Но один сервер жрет в 10 раз меньше энергии. И обслуживать, по сути, надо один сервер, а не четыре десятка, т.к. нужен штат из меньшего числа специалистов.
Посчитайте разницу в зарплатах и затратах на электроэнергию, посчитайте сумму за год (или, лучше, два-три года).
Думаю, после этого принципиальность будет несколько очевиднее.
> Это говорит о том, что компании, которые достигли успеха не используют
> закрытых решений и не страдают от vendor lock-in, а используют или
> open source решения или свои собственные разработки. И то и другое
> они могут адаптировать любым способом к своим задачам и потребностям.
> И это - гораздо более сильный аргумент, чем "стоимость поддержки и электроэнергии".
А известно ли вам, что для компаний, для которых разработка софта не является профильной, или субпрофильной деятельностью - разработка любых более-менее серьезных локальных программных решений стоит ОЧЕНЬ много денег? Временами, настолько много, что действительно электроэнергия и поддержка серверов отдыхает.
Именно поэтому они и покупают готовые решения. Это просто дешевле.
> Не только для гугла, но и для многих других компаний тоже,
> http://www.insight-it.ru/highload/ - с подробными описаниями.
Большая часть - веб-компании, про уместность в которых подобных решения я уже и не помню сколько раз тут упоминал. Так что вы лишь подтвердили тезис, высказанный мной же ранее.
> Разумеется, лучше начинать с SQL баз данных. Но когда один сервер баз данных
> уже не справляется, а sharding не особо спасает - обычно тогда дешевле миграция
> на open source NoSQL решения, вместо того чтобы покупать SPARC/Oracle или решение
> от IBM.
Повторюсь, когда требуется не разработать решение, а купить готовое - что и куда мигрировать никого особо не интересует. Нужен компании SAP для решения бизнес-задач - будет покупаться SAP, вместе с Oracle, DB2, или чем-то подобным. И с железом, ясный пончик, наиболее рекомендованным вендором. И, увы, зачастую это не x86. Хотя, зависит, конечно, от масштабов.
> Java и C# обладают двумя важными свойствами: а) они лишают программиста
> возможности сделать некоторые чрезвычайно болезненные ошибки, исправление которых часто
> требовало неадекватного и непредсказуемого времени,
Индусы и китайцы - люди находчивые, они и сумели обойти все эти предосторожности! ;-)
Ну а если серьезно - все это хорошо, но вот только все эти плюшки даются ценой огромных накладных расходов. Просто чудовищных. Культура разработки ПО - лежит в руинах. Уже упоминавшийся ранее Android - хороший тому пример. То, что на Symbian лет 10 назад летало - умудряется лагать на Android с невероятным (в сравнении с теми десятилетними Symbian-устройствами) количеством памяти и ресурсов CPU.
А все почему? Разработка железа - дешевле разработки ПО. Плюс ко всему, написание все более медленного и требовательного к ресурсам ПО - подстегивает продажи новых железок, так что в плюсе все. Кроме пользователей.
> по поводу "не везде оно работало так, как ожидали" можно подробнее?
В конце 90-х, начале 00-х на Java пытались делать совершенно все, десктопные приложения, драйвера и даже целые ОС.
Где оно все сейчас?
> А куда нам спешить? Сейчас есть вполне хорошие и надежные файловые системы
> ext4 и XFS.
Ну, мы же говорим про новые решения, нет? XFS, хоть и хорошая, но разработана была уже очень давно, все изменения в ней с тех пор носят скорее инкрементальный характер. Ext4 тоже "новой" можно считать лишь очень условно.
> Развивается, только попытки использовать ZFS на FreeBSD в highload
> приводили к тому, что рано или поздно народ отказывался от использования ZFS.
Это потому, что ZFS, все таки, разрабатывался под Solaris, у которого в целом поддержка highload сделана получше.
> Те же GFS2 и GlusterFS выглядят привлекательнее, чем не-кластерная ZFS.
Это все равно, что сравнивать NTFS и VMFS с позиции того, что хуже, или лучше, без учета некоторых обстоятельств. ;-)
> Зарабатывание денег - это цель, ради достижения которой Oracle
> готова пойти на все что угодно? Например, добить платформу Itanium.
> Или попытаться уничтожить Red Hat, продавая то, что создает Red Hat.
Совершенно верно.
В СССР ведь не зря капитализм считался злом. Если бы не сдерживание законом - давно бы там уже все друг друга перегрызли.
> Тем не менее, они сами создали этот рынок, до майкрософта рынка software просто не было.
Как это не было? Unix, CP/M, софт под них - бесплатно раздавали, что ли?
> По поводу MS-DOS - смысл претензий не понятен. Билл Гейтс честно купил эту систему.
Он честно купил одно, а нечестно впаривал это как несколько иное. Ну и за несколько иные деньги. Претензий никаких - это был гениальный маркетинговый ход, вошедший в историю.
> Есть предложения по улучшению патентной системы США?
Пока в конкрессе активно процветает лоббизм - что-либо предлагать бессмысленно. Что в свое время студия Disney пыталась добиться, лоббируя увеличения срока авторского права? Думаю, очевидно, что последнее, что им было нужно - так это чтобы бренд "Mickey Mouse" стал public domain. Финансовые потери от такого - трудно описать.
И далеко не все эти лицензионные нападки друг на друга в суде - являются публичными средствами патентных споров. Большинство улаживается мирно, оплатой отчислений, или кросс-лицензированием. Платят-то издержки все равно не компании, а потребители.
> Излишняя беспринципность тоже. Пример SCO будет всем наукой.
На момент событий SCO - те уже и так были на грани банкротства, так что для них это был способ временного выживания.
Который, в общем-то, сработал.
