Подходит ли стек LAMP для корпоративного использования?
Подходит ли стек LAMP (Linux, Apache, MySQL, PHP / Ruby / Python) для корпоративного использования?
Чтобы быть ясным, под «предприятием» я подразумеваю большую или очень большую компанию, где ключевыми факторами являются безопасность, надежность, доступность набора навыков, совокупная стоимость владения (TCO), масштабируемость и доступность инструментов. Другими словами, компания, которая ищет внешнего внедрения фреймворков / архитектуры - что-то повсеместное будет рассматриваться как более «действительное», чем что-то экзотическое / эзотерическое в подобной среде.
Я видел примеры использования, когда Oracle, IBM и Sun внедряли системы на стеке LAMP для различных предприятий. Я также видел примеры, когда на нем построены такие сайты, как yellowpages.com (Ruby on rails) и Facebook (php). Однако ни один из этих примеров не совсем то, что я ищу.
Я действительно пытаюсь найти примеры, где это корпоративный стандарт в очень большом банке (например, Citigroup), телекоммуникационной компании (например, AT&T) или производителя (например, Proctor and Gamble). Для ясности: я ищу не пример, где он используется в ограниченном смысле (как в JPMorgan Chase), а где это основная платформа для таких систем, как CRM, производственные системы или управление персоналом, а также для внутренних и внешние веб-сайты.
До сих пор я заметил, что приложения, построенные на стеке LAMP, работают медленнее и менее гибки. Вот некоторые из доводов, которые я слышал:
Считается, что Linux не так хорошо поддерживается, как серверы Unix, Solaris или Windows.
Apache сложнее настроить и поддерживать, чем веб-серверы, такие как BEA WebLogic или IIS.
MySQL - это БД «не готовая к использованию в прайм-тайм» для любителей, и не является конкурентом SQL Server или Oracle (хотя PostgreSQL, кажется, имеет репутацию более надежной).
PHP / Ruby on rails оптимизирован для CRUD (операции создания, чтения, обновления и удаления). Хотя это является преимуществом при создании веб-приложений с интенсивным использованием CRUD, оба они работают медленнее, чем Java / Java EE или C# (которые являются общими корпоративными стандартами). Кроме того, многие приложения и системы (например, производственные системы) имеют множество функций, отличных от CRUD, которые может быть труднее создать с помощью PHP, Ruby или даже Python.
Может ли кто-нибудь предоставить аргументы в поддержку или опровержение идеи о том, что стек LAMP подходит для Enterprise?
Спасибо!
КА
ОБНОВЛЕНИЕ: Иногда стек LAMP подходит для корпоративного использования: внешние блоги
Я имею в виду любую телекоммуникационную компанию. Например, Bell или KT.
KT Я слышал о (NYSE: KTC). Однако о Белле я не слышал.
@ Джеймс Ван Хьюис: Как вы узнали, что "Bell" означает "AT&T"? Что я упустил в вопросе?
@S. Лотт: AT&T использовала название Bell System почти столетие. Конечно, это была старая AT&T, а не нынешняя. Нынешняя AT&T ранее была известна как SBC, которая раньше была Southwestern Bell Corporation.
Извините, я должен был быть более ясным. Однако имейте в виду, что целью было найти примеры, когда стек LAMP используется для основных систем в крупных компаниях в таких отраслях, как телекоммуникации, производство или банковское дело.
@Kaiser Advisor: вот моя точка зрения. Вопрос кажется аргументированным именно потому, что вы можете наугад разбрасывать названия компаний. Возможно, это не аргумент, но упоминание названий несуществующих компаний кажется аргументом.
@ S.Lott - Мои извинения за аргументированность! Это действительно не было моим намерением. Я просто хотел привести примеры отраслей, в которых есть много надежных компаний с хорошими ИТ-предприятиями, и примеры ведущих компаний в каждой из них. Bell не прекратила свое существование в моей стране. :-)
@ S.Lott - Прочитав ваш комментарий еще раз, я думаю, что тот факт, что Bell не существует в вашей стране, а не в моей, был камнем преткновения. Bell Canada здесь рассматривается как «флагманская» телекоммуникационная компания. Еще раз извините за путаницу. Я изменил это в вопросе.
Интересно - несмотря на то, что я подробно рассмотрел вопрос, я, по-видимому, получаю отрицательное голосование на основании того, что некоторые любители LAMP не могут объективно решить этот вопрос. Это просто конкурс популярности LAMP? Если да, то почему я потрудился дать честный и опытный ответ?
@Rob: Почему ты удалил свой ответ? У меня нет опыта, чтобы судить о его точности, но похоже, что это ценный вклад.
Ответы 21
Для крупных предприятий, использующих стеки LAMP, есть две основные проблемы:
- ТШО: учитывая, что LAMP в основном предоставляется бесплатно, предприятия по-прежнему достигают более низкой общей стоимости эксплуатации с другими коммерческими решениями
- Поддерживаемость: у предприятий нет проблем с дополнительными затратами, чтобы получить круглосуточную профессиональную поддержку от своих коммерческих поставщиков.
Юваль, совокупная стоимость владения включает в себя расходы на поддержку - я видел исследования, в которых совокупная стоимость владения программного обеспечения с открытым исходным кодом может быть выше, чем у частного программного обеспечения, потому что наборы навыков менее распространены (и, следовательно, более дороги). Не могли бы вы оказать поддержку?
Я знаю, это то, что я сказал, или, по крайней мере, то, что я имел в виду :)
«но где это основная платформа для таких систем, как CRM и HR, а также для внутренних и внешних веб-сайтов»
Сначала найдите приложение LAMP CRM или HR.
Затем найдите клиента для приложения LAMP CRM или HR.
К сожалению, примеров пункта 1 немного. Следовательно, ваша версия доказана. Его нельзя использовать для корпоративных приложений, потому что в настоящее время нет приложений, которые вы называете «корпоративными».
Однако другие ваши замечания очень интересны.
Считается, что Linux не так хорошо поддерживается, как серверы Unix, Solaris или Windows.. Я думаю, что Red Hat будет категорически против этого. Позвоните им. Я думаю, они сделают очень убедительную коммерческую идею. Прочтите их Истории успеха.
Apache сложнее настроить и поддерживать, чем веб-серверы, такие как BEA WebLogic или IIS.. Кем? Менеджеры веб-сайтов Apache? Или менеджеры веб-сайтов IIS? Это полностью субъективно.
MySQL - это БД "не готовая к работе в прайм-тайм". Обратитесь к Sun Microsystems. Я думаю, они будут категорически против этого. Позвоните им. Я думаю, они сделают очень убедительную коммерческую идею. Прочтите их Истории успеха.
PHP / Ruby on rails оптимизированы для CRUD, и оба работают медленно.. Может быть правдой. Java и Python могут быть быстрее. PHP и Ruby - не последнее слово в LAMP.
SugarCRM используется довольно часто.
SugarCRM - тоже мусор, так что это не лучший пример.
Более того, это субъективно. Слишком легко спорить, достаточно ли это «предприятия» или данный клиент похож на «предприятия», перечисленные в вопросе.
Возможно, вы захотите упомянуть, что FastCGI позволяет обойти множество проблем с производительностью Perl / PHP / Ruby / Python. PHP также выигрывает от наличия установленного кеша опкодов, такого как APC.
Мне нравится, как вы цитировали Red Hat в примере с Linux - вы не знаете, какие ссылки они бы цитировали?
Собственно PHP является последнее слово в LAMP.
@ Дэн Дайер: Забавно, ребята из Python постоянно говорят мне, что Python - последнее слово в LAMP.
Люди PostgreSQL обычно говорят, что M для Middleware, а P для PostgreSQL.
Позвоните в Zend, я думаю, они сделают очень убедительную коммерческую идею.
@ Дэн Дайер: XML - последнее слово в AJAX, но тем не менее я использую JSON. С.Лотт говорит, что вы не привязаны к PHP так же, как вы не привязаны к Linux. Вы можете использовать FreeBSD, lighthttpd, PostgreSQL и Python, и это все равно будет LAMP (у FLPP нет такого же кольца;)
Собственно, PHP - это последние 3,5,7,9, ... слова в LAMP.
ИМО, нет хороших общих аргументов против Linux и Apache; Вы, безусловно, можете получить поддержку Linux на корпоративном уровне, если готовы за нее платить (и примерно бесплатно, если вы готовы играть по правилам сообщества). И Apache не так сложно настроить, если вам не нужны его более сложные функции, что маловероятно для сервера приложений.
Вы, безусловно, можете возразить против MySQL, поскольку некоторые из наиболее важных функций, касающихся безопасности данных, были добавлены совсем недавно. Если вас это беспокоит, используйте вместо этого PostgreSQL.
Что касается языка, на котором вы пишете свое приложение: PHP определенно доказал свою способность запускать чрезвычайно большие и сложные системы; Меня больше беспокоит ремонтопригодность, чем производительность. И Ruby on Rails «оптимизирован для CRUD» только постольку, поскольку простое веб-приложение CRUD можно написать почти мгновенно (буквально за несколько минут), но это не значит, что оно как-то менее подходит для более сложных приложений, просто для этого потребуется гораздо больше времени (все еще меньше, чем со многими другими языками)
Redhat и IBM полностью поддерживают Linux, Sun купила MySQL, Yahoo использует Php, многие компании используют стек LAMP, но многие используют части.
Почему голосование против? Похоже, что произошла какая-то случайная стрельба, поскольку ответ JeeBee и мой отказался от голосования без видимой причины
строго субъективное мнение, но я лично считаю MySQL и, в меньшей степени, PHP слабым местом, но, безусловно, есть много людей, которые не согласны с этим, и крупные компании, которые выбрали LAMP.
Я бы предпочел, чтобы postgres или даже SQLite частично вытеснили рынок MySQL, и я бы хотел больше видеть приложения на основе моно, jsp или кокон. Я полагаю, LAMP слишком специфичен для общего термина. :)
Я думаю, вы обнаружите, что многие предприятия используют серверы Linux, часто поддерживаемые Redhat, Novell или IBM, а также широко используется Apache.
Но многие предприятия склонны использовать базы данных, такие как Oracle или IBM DB2, вместо предложений с открытым исходным кодом - хотя многие предприятия действительно не нуждаются в той мощности, которую предоставляют эти системы, и могут обойтись MySQL или PostgreSQL.
Что касается языка веб-сервера, я думаю, вы можете использовать что угодно. Однако, если вы используете Apache, вероятно, проще использовать PHP, Ruby или Python, тогда как если вы используете IIS, Weblogic или Domino, это будет проще сделать на Java / C#.
Linux используется очень часто. Очень часто используются Apache и Tomcat. MySQL теперь может быть надежным. Вместо этого я бы использовал PostgreSQL. Банки будут использовать Oracle, но там есть хорошая поддержка Java и Tomcat. PHP используется очень часто, но многие крупные компании предпочли бы Java.
На мой взгляд, лучше всего выступать за Linux (возможно, коммерчески поддерживаемую версию) Tomcat, Java, Tomcat | Oracle | MSSQL.
Вам понадобится системный администратор Linux, особенно по мере роста количества серверов, хотя я уверен, что вы можете получить его на неполный рабочий день до того, как наступит это время. Если у компании уже есть системные администраторы Windows, то спорить в пользу Linux будет сложно.
Я просто хочу добавить, что я много раз был свидетелем того, что клиенты чувствуют себя комфортно только тогда, когда они вкладывают серьезные $$$ за какое-то решение, даже если это еще больше затрудняет интеграцию предприятия, несмотря на то, какие аргументы вы приводите.
Я уверен, что RedHat и Sun с радостью примут огромные суммы денег от вашей компании :-)
напоминает мне: thedailywtf.com/Articles/…
Если для его реализации нанять идиотов, C++ и Oracle не смогут масштабироваться. Если вы нанимаете умных людей, которые добиваются результатов, PHP и MySQL прекрасно масштабируются.
Тот же аргумент касается безопасности и надежности.
Facebook, Digg и Yahoo работают на PHP. Конечно, они нанимают много докторов наук.
да, это ответ, язык программирования не имеет большого значения, хорошие программисты делают!
Я также думаю, что маловероятно, что большинство разработчиков будут работать над системами, в которых масштабируемость является большой проблемой. Все распространенные платформы (LAMP, .NET, UNIX и т. д.) Легко справляются с очень большими масштабами. Если вы не создаете следующий Google, вам есть о чем беспокоиться.
Я думаю, что первым критерием должен быть уровень навыков вашей команды, уровень комфорта, чтобы убедиться, что все принятые платформенные решения хорошо с ними работают. Что бы вы ни решили, думайте о масштабируемости и ремонтопригодности вашего кода. Инструменты великолепны, какой бы набор вы ни выбрали.
Я бы лично разбил его на 3 стека -
Стек Java, в котором у вас есть Solaris или Enterprise Linux, например (RedHat) с Weblogic / Websphere / Tomcat и т. д. И Java Enterprise вместе с технологиями Hibernate, Spring и т. д. Большинство выбрало бы Oracle в качестве БД.
Стек Microsoft с открытым исходным кодом при необходимости Win Server - IIS - .net / C# (ASP.net и т. д.) - NHibernate, NUnit (модульное тестирование) и т. д. Скорее всего, вы захотите использовать SQL Server в качестве БД.
Ни один из вышеперечисленных стеков с Enterprise Linux, на котором работает целый набор вещей с открытым исходным кодом, таких как MySQL (теперь в домене Sun, поэтому на него можно серьезно взглянуть), Apache (там есть гуру apache), Ruby (не мой личный выбор) / PHP (удачи) / Python (мне нравится, потому что это зрелый язык). Я бы защищал Python или Ruby с точки зрения управляющего кода. Может быть, для кого-то это может быть PHP… я не в восторге.
Лично я не считаю, что Linux поддерживается хуже, чем другие упомянутые ОС; на самом деле поставщики оборудования обычно поддерживают Linux поверх любой другой ОС (за исключением Windows, которую они, как правило, поддерживают достаточно хорошо, если вы используете дистрибутивы maintream).
При условии, что вы не используете причудливую разновидность (Совет: просто используйте RHEL или Centos, которые являются его бесплатным эквивалентом), Linux очень хорошо поддерживается.
MySQL может иметь некоторые недостатки, но, на мой взгляд, у него много сильных сторон; мы используем его в больших масштабах непредусмотренными способами, но в целом он по-прежнему работает достаточно хорошо (большинство проблем связано с тем, что наши версии устарели или плохо настроены).
Что «P» означает в ЛАМПА спорно. Я чувствую, что PHP не готов для предприятий, потому что у него так много индивидуальных недостатков (например, плохая обработка Unicode, отсутствие пространств имен, несогласованные API, несогласованный синтаксис, плохая обратная совместимость версий, дублированная / устаревшая функциональность), что они усложняют внедрить обслуживаемую систему.
Но при наличии достаточно опытной команды, даже если вы выберете PHP, его можно использовать для создания приложения исключительно высокого качества.
Linux / Apache надежны, экономичны, и каждый поставляется с множеством людей (за разумную цену, конечно), которые предоставят поддержку, множество полезных инструментов, многие из которых имеют исключительно высокий уровень полезности, которые работают с ними и которые были построены на них. .
Однако насчет двух других не уверен. В частности, MySQL, похоже, принял странный оборот к худшему с тех пор, как их приобрела Sun, вопреки сообщениям в этой ветке, предполагающим, что Sun может иметь хорошее влияние:
Something ubiquitous will be seen as more "valid" than something exotic / esoteric in this kind of environment.
Хотя я лично не рекомендовал бы PHP из-за множества недостатков в языке, он определенно повсеместен. С появлением пассажира phusion, поддержка Rails среди компаний, занимающихся общим хостингом, также довольно быстро растет. Я даю ему еще год или два максимум, прежде чем 90 +% учетных записей общего хостинга будут поддерживать рельсы из коробки. Если это не повсеместно, то что?
Linux is seen as not as well supported as Unix, Solaris, or Windows Servers.
Если вас это беспокоит, приобретите поддержку у RedHat или установите Solaris и приобретите поддержку у Sun. Оба из них предоставят вам такую же хорошую поддержку, как и Microsoft.
Apache is harder to configure and maintain than web servers like BEA WebLogic or IIS.
Я не могу говорить о BEA WebLogic, но, настроив Apache, IIS и Tomcat, Apache проще всего понять и найти примеры и документацию для долгим путем..
MySQL is a "not ready for prime time" DB for hobbyists, and not a competitor for SQL Server or Oracle.
Да неужели?. Вы должны сделать своей миссией сообщить NASA, Google, CERN, Reuters и т. д., Что все они используют базу данных для любителей, которая не готова к работе в прайм-тайм.
PHP / Ruby on rails are optimized for CRUD, and both perform slower than Java/Java EE or C# (which are both common Enterprise standards).
Здесь есть 2 вещи:
Оптимизирован для CRUD - это совершенно не важно.
Rails и некоторые фреймворки python / php оптимизированы для приложений CRUD. Многие из фреймворков C# / Java также оптимизированы для приложений CRUD. Однако, если приложение, которое вы создаете, является приложением CRUD (а это 99% веб-приложений), разве это не хорошо?
Если вы не создаете приложение CRUD, в ruby / python / php / java / C# есть множество не оптимизированных для crud фреймворков. Чистая победа: никто (следовательно, не имеет значения)
Работать медленнее, чем Java / C# - это, несомненно, правда, но это также не имеет значения. Для сайта с низким трафиком разница в производительности не будет иметь никакого значения, а для сайта с высоким трафиком узким местом будет база данных, будь то MySQL, Oracle или что-то еще.
На все это приходится жертвовать временем разработки. Как только вы воспользуетесь всеми этими советами, чтобы убедить своего босса, что вы не будет проиграете что-либо, используя LAMP, если вы подсчитаете цифры и покажете им, что создание сайта на Java займет 6 человеко-месяцев только 3, чтобы построить его на ruby / python, тогда это действительно то, к чему все сводится.
Просто подумал, что добавлю еще один сайт в список тех, что работают на LAMP - Википедия. Седьмой по величине веб-сайт в мире, полностью написанный на PHP и работающий на базе MySQL, и у них всего два или три платных разработчика. Конечно, им помогают волонтеры, но это не так уж и много, и они хорошо масштабируются. Не знаю, действительно ли вы назовете их «корпоративными», но для такого огромного и популярного веб-сайта они, похоже, неплохо справились сами.
Linux is seen as not as well supported as Unix, Solaris, or Windows Servers.
Как уже говорили другие, позвоните Red Hat, и я уверен, что они будут возражать. И объем поддержки Linux абсолютно бесплатно просто поражает.
Apache is harder to configure and maintain than web servers like BEA WebLogic or IIS.
Это зависит от того, кого вы спрашиваете. Люди, которые обычно администрируют серверы IIS, вероятно, будут так рассматривать это. Люди, которые обычно администрируют Apache, этого не делают. Это зависит от того, кого вы нанимаете, и если ваш стек - LAMP, вы все равно не захотите нанимать людей без опыта работы с Apache.
Для цитирования re: Wikipedia просто прочтите их технический FAQ.
Я полагаю, что крупные коммерческие приложения CRM и HR могут быть склонны к предоставлению крупных коммерческих продуктов РСУБД в качестве основы для своих продуктов. Во всяком случае, я уверен, что они предпочтут объединиться против общей угрозы.
И им труднее обосновать плату за лицензию и поддержку, если они интегрируют продукты, в которых их нет.
Мой 2с:
Linux: С тех пор, как вышло ядро 2.6, я бы сказал, что это определенно качественная ОС. Версия 2.4 была не совсем там, и 2.2 была шуткой, но 2.6 действительно хороша. Однако будьте осторожны с выбором дистрибутива. По моему опыту, RedHat / CentOS очень хороши, и очевидно, что Debian (оригинальный, а не Ubuntu!) Может быть хорошо настроен, если у вас есть хороший администратор. Мой опыт работы с OpenSUSE был не очень хорошим.
Apache: Не использовал, но не понимаю, почему это может быть проблемой.
MySQL: это самое слабое место в стеке. Я не буду здесь вдаваться в подробности - посмотрите комментарии на reddit.programming, если вам интересно. Лучше посмотрите PostgreSQL.
PHP / Perl / Ruby / Python: я работал с Perl и в меньшей степени с Python. Они, вероятно, подходят для веб-приложений, где основная часть работы в любом случае выполняется веб-сервером и СУБД. Однако я предпочитаю систему статических типов и предпочитаю Java / C# для бизнес-приложений и C++ для системного программирования.
Причина, по которой не удается найти корпоративные приложения, построенные на LAMP, заключается не в том, что они не уровня предприятия, а в чем-то совершенно другом, на мой взгляд. Многие крупные игроки используют LAMP или что-то подобное - сразу приходят на ум Facebook и Мое пространство. Так что это явно не проблема масштаб и производительность.
Тем не менее, причина того, что я считаю, что на LAMP нет корпоративных приложений, заключается в их внутренней открытой природе. Я не хочу создавать актуарный модуль в виде файла PHP, потому что любой может украсть логику. С другой стороны, если у меня есть DLL, я могу сохранить контроль. Именно по этой причине вы не найдете много 30-пробных приложений, созданных на PHP, но гораздо проще добиться такой защиты, скажем, с помощью ASP.NET.
MySpace построен на .NET, а не на LAMP.
Если этого достаточно для Google, поверьте мне, этого достаточно для вас.
Что Google делает со стандартной LAMP. AFAIK там платформа сильно настроена.
Это ставит первоначальное утверждение о том, что LAMP менее гибок. И большая часть этой настройки доступна каждому (например, Google MySQL Tools). Но Google взвесил все за и против, подумал и с самого начала выбрал LAMP. Эта настройка появилась позже.
Я хотел бы предложить нам определить требования к масштабируемости корпоративных систем и их отличия от веб-приложений. Взгляните на некоторые из наиболее масштабируемых систем, таких как Wikipedia, Flickr, Wordpress, Facebook, MySpace и множество других. Вы увидите там стопку ЛАМПЫ. Я больше поклонник Python (так как считаю, что язык стал более чистым), но я слушаю таких экспертов, как Кэл Хендерсон (Flickr), который написал книгу по масштабируемости, рассказывающую о том, как он масштабировал банк серверов MySQL.
Каковы основные особенности корпоративной системы?
Поддержка, наличие опыта, стабильность платформы / языка, вероятно, важны.
Но у LAMP есть и другие функции, такие как более быстрая разработка, более простая расширяемость, множество доступных библиотек для повторного использования, несколько задокументированных историй масштабируемости, зрелые веб-фреймворки.
Вот пара указателей на создание масштабируемых систем (я говорю о веб-масштабировании). В свете всех этих свидетельств я всегда задавался вопросом, почему постоянно возникает мнение о том, что LAMP не готов к работе с корпоративными приложениями.
Что касается Apache, каждое исследование Netcraft показывает совершенно разные истории внедрения. Из-за огромного количества серверов может быть больше людей, обладающих знаниями в области настройки, настройки и расширения веб-сервера.
Масштабируемые веб-архитектурыПожалуйста, посмотрите на долю рынка всех серверов с августа 1995 г. по январь 2009 г.
В вашем посте есть несколько плохих мифов:
Мифы JavaEE: -Серверы приложений проще настроить, чем apache, нет, apache проще. -Вы подразумеваете, что только полное решение JavaEE является корпоративным, нет.
Мифы CRUD: -CRUD медленнее JavaEE? Какого черта? POJO и EJB используют CRUD. Ограничивающим фактором является не сырость, ее пропускная способность сервера.
Есть 3 ограничивающих узких места, независимо от того, какая технология - даже MS… реализация сервера, уровень сохраняемости и уровень приложения… выбранная технология не является фактором скорости, так как вы можете поменять преимущества на одном уровне на недостатки на другом уровне. Например, мы могли бы дублировать Java, используя хранилище документов вместо обычной БД.
Большинство новых реализаций Rails используют серверы без apache, которые в 3-5 раз быстрее, чем Apache .. даже хорошо настроенный сервер Apache может превзойти некоторые стеки javaEE ... просто спросите yahoo, поскольку они используют Symfony для некоторых своих свойств ..
Я считаю, что это не значит, что технология является преждевременной или что-то такое, что заставляет таких крупных компаний, как AT&T, продолжать полное внедрение на уровне предприятия. У этих компаний такой большой бюджет на ИТ-расходы, что последнее, о чем они могли бы подумать, - это потратить больше на настройку и усовершенствование технологий с открытым исходным кодом, необходимых для удовлетворения потребностей их бизнеса.
Итак, что они ищут (что исходит из моего опыта консультирования), так это купить и запустить пакет продуктов и не тратить больше на исследования и взлом. Компании, использующие сборку с открытым исходным кодом, создали свои собственные группы поддержки по всему миру, чтобы удовлетворить любые потребности в поддержке, на что крупные предприятия не очень охотно соглашаются. Им нужно, чтобы все было сделано быстро и точно, и они могут заплатить.
«Телекоммуникационная компания (т.е. Bell)» О какой компании вы имеете в виду?