Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 182
Блин, не увидел RHEL сразу… Считайте +1 за него :)
Очевидно же что дебьян/убунту победит а затем какой-нибудь центос.
скорее всего
но всё может быть
но всё может быть
Не холивара ради, но в чем их преимущество перед freebsd или centos?
Лично для меня — APT мне больше нравится чем RPM (о портах во фряхе говорить не будем, да? :) ), хотя бы из-за более продуманной политики зависимостей.
Второй пункт — стабильность. Настроенный сервер может крутиться и обновляться годами без ошибок. С CentOS увы я такого не замечал. Насколько я знаю, в stable-релизы кладут пусть и старые, но полностью надежные версии софта.
Ну и, опять же имхо, Xen лучше дружит с Debian'ом чем с CentOS.
Второй пункт — стабильность. Настроенный сервер может крутиться и обновляться годами без ошибок. С CentOS увы я такого не замечал. Насколько я знаю, в stable-релизы кладут пусть и старые, но полностью надежные версии софта.
Ну и, опять же имхо, Xen лучше дружит с Debian'ом чем с CentOS.
Скажите, а почему вам не нравятся порты?
Пакеты или конкретно порты?
Если второе, то, вкратце, замечательными B-deps'ами, которые так приятно разнообразят софт на сервере. R-deps'ы тоже занятная вещь, особенно те, которые билдятся при конфиге, немало раз получался конфликт софта на этой почве. «Легкостью и удобством» разработки собственных и модификации чужих портов, особенно если искать нетривиальный баг сборки. Компиляция тоже мне по нраву, так хорошо посидеть полчасика наблюдая сборку особенно тяжелого пакета.
Пакеты тоже не сахар, особенно собранные для какой-нибудь i386, с вырубленными оптимизациями, с отличной конфигурацией, в которой пропущена половина нужных мне настроек.
В общем rpm/apt я считаю малость лучше портов :)
Если второе, то, вкратце, замечательными B-deps'ами, которые так приятно разнообразят софт на сервере. R-deps'ы тоже занятная вещь, особенно те, которые билдятся при конфиге, немало раз получался конфликт софта на этой почве. «Легкостью и удобством» разработки собственных и модификации чужих портов, особенно если искать нетривиальный баг сборки. Компиляция тоже мне по нраву, так хорошо посидеть полчасика наблюдая сборку особенно тяжелого пакета.
Пакеты тоже не сахар, особенно собранные для какой-нибудь i386, с вырубленными оптимизациями, с отличной конфигурацией, в которой пропущена половина нужных мне настроек.
В общем rpm/apt я считаю малость лучше портов :)
Воопервых apt и rpm сравнивать очень странно. Или deb и rpm или apt и yum.
Во вторых чем более продуманы зависимости? O_o? в deb дистрах они package-based, в отлчии от file-based в rpm, что приводит к тому, что пакеты вынуждены указывать provides.
В третьих «годами» — это сильно сказано про deb, при учете, что срок жизни debian релиза всего 3 года.
Вообще судя по всему вы просто не умеете готовить RHEL.
Во вторых чем более продуманы зависимости? O_o? в deb дистрах они package-based, в отлчии от file-based в rpm, что приводит к тому, что пакеты вынуждены указывать provides.
В третьих «годами» — это сильно сказано про deb, при учете, что срок жизни debian релиза всего 3 года.
Вообще судя по всему вы просто не умеете готовить RHEL.
в deb дистрах они package-based, в отлчии от file-based в rpm, что приводит к тому, что пакеты вынуждены указывать provides.
Я думаю, многие дебианщики прочитали это предложение несколько раз, пытаясь понять, действительно ли вы package-based зависимости (а не file-based) относите к недостаткам. Для них это звучит как «зато в этом ноутбуке более энергоёмкий и менее производительный процессор!»
В третьих «годами» — это сильно сказано про deb, при учете, что срок жизни debian релиза всего 3 года.
А какое отношение срок жизни debian-релиза имеет к обновлению системы годами? При выходе следующего stable-релиза сервер может обновиться до него — и заново отсчитываем три года…
>> «зато в этом ноутбуке более энергоёмкий и менее производительный процессор!»
Ага. расскажите-ка, зачем вместо того, что-бы указать в завимостях «libxxxx.so версии yy для i386» в deb дистрибутивах указывается «пакет xxxx» или «пакет xxx версии y»?
В первом случае пакет может обновиться и сломать вам ABI, в другом обновиться и не сломать, но ваша завимиость будет требовать именно эту версию. Еще хуже, если «libxxx.so» нужной версии поставляет другой пакет, в котором не написали «provides xxxx».
А какие недостатки у «file-based», если по вашему это «более энергоемкий и менее производительный» O_O? Если, конечно, дебиянщики не знают как работет yum, то тогда вполне возможно они так и считают.
>>При выходе следующего stable-релиза сервер может обновиться до него — и заново отсчитываем три года…
Обновить? Продакшн? У меня заряжена продакшен система с софтом умеющим только python 2.3, php 4 или mysql 3.x. Или апач соответствующей версии. Что мне после обновления делать? Разыскивать по сторонним репам и заново восстанавливать завимимости?
>> Настроенный сервер может крутиться и обновляться годами без ошибок.
так и пишите, 3 года, потом обновление и перенастройка сервисов. Вообще шаги дебиян-сообщества по сокарщению срока поддержки вызывают у многих знакомых ужас и переползание в сторону убунты-сервера, у которого срок жизни значительно дольше.
Ага. расскажите-ка, зачем вместо того, что-бы указать в завимостях «libxxxx.so версии yy для i386» в deb дистрибутивах указывается «пакет xxxx» или «пакет xxx версии y»?
В первом случае пакет может обновиться и сломать вам ABI, в другом обновиться и не сломать, но ваша завимиость будет требовать именно эту версию. Еще хуже, если «libxxx.so» нужной версии поставляет другой пакет, в котором не написали «provides xxxx».
А какие недостатки у «file-based», если по вашему это «более энергоемкий и менее производительный» O_O? Если, конечно, дебиянщики не знают как работет yum, то тогда вполне возможно они так и считают.
>>При выходе следующего stable-релиза сервер может обновиться до него — и заново отсчитываем три года…
Обновить? Продакшн? У меня заряжена продакшен система с софтом умеющим только python 2.3, php 4 или mysql 3.x. Или апач соответствующей версии. Что мне после обновления делать? Разыскивать по сторонним репам и заново восстанавливать завимимости?
>> Настроенный сервер может крутиться и обновляться годами без ошибок.
так и пишите, 3 года, потом обновление и перенастройка сервисов. Вообще шаги дебиян-сообщества по сокарщению срока поддержки вызывают у многих знакомых ужас и переползание в сторону убунты-сервера, у которого срок жизни значительно дольше.
в deb дистрибутивах указывается «пакет xxxx» или «пакет xxx версии y»?
… или, например, «пакет xxxx версии >= y | пакет xxxy». Возможностей много, в т.ч. защиты от изменения ABI. Если изменение ABI уже предсказуемо (наш пакет работает на Python 2.5/2.6, но не работает на 2.7), то зависимость ровно так же и описывается.
Зависимость "=" обычно значит, что оба пакета входят в одну метасистему — например, собраны из одного исходника. В реальности обычно используются ">=" и "<<".
Еще хуже, если «libxxx.so» нужной версии поставляет другой пакет, в котором не написали «provides xxxx».
Возможно, вы проецируете свойственное для редхатоидов на дебианоиды. В дебиане подобная ситуация является… ну, нонсенсом, ошибкой мейнтейнера, серьёзной проблемой. Причём кроме provides, в таком случае пишут ещё и conflicts.
А какие недостатки у «file-based», если по вашему это «более энергоемкий и менее производительный» O_O?
Ну, ABI — это не единственная причина, почему один пакет может требовать другого. Равно как provides не обязательно обозначает «ABI-библиотеку», но может, например, обозначать какую-то подсистему. Например, какой-нибудь метапакет «modern-linux-desktop» может зависеть от любого пакета «www-browser» (предоставляемого, например, пакетами google-chrome, firefox и opera), и в результате будет требовать как минимум одного из них (но, при отсутствии conflicts, не запрещать установку более чем одного). При этом пакеты самих браузеров могут не иметь общего для всех файла.
Но вообще, конечно, различие архитектурное. В случае «пакет зависит от пакетов» содержимое пакетов инкапсулировано в них и никак не связано с реальными их связями, отношениями и зависимостями: dpkg работает с пофайловым содержимым одного пакета (не обеспечивая межпакетные связи), apt работает со связями (совершенно не интересуясь пофайловым содержимым пакетов).
У меня заряжена продакшен система с софтом умеющим только python 2.3, php 4 или mysql 3.x. Или апач соответствующей версии.
Общего между этими ситуациями разве что одно. Недостаточная предусмотрительность руководителя IT-подразделения.
Вы знаете, я вот буквально вчера размышлял: в последнее время как-то неожиданно случаются технологические прорывы на ровном месте. То на поделенном ещё в советские времена рынке автопрома появляется новый производитель, который собирается с нуля (без полувековых наработок! Без легендарных «старых слесарей, ощущающих твёрдость стали по звону от щелчка»!) запустить производство современных гибридных автомобилей. То вот, буквально за срок менее года, в Москве запустили производство высокоточных снайперских винтовок (<0.3 MOA). Я вот думаю, мы, благодаря технической революции, доступности интернета, автоматизации всего и вся, случайно не перешагнули за границу технологической сингулярности?
Я это к тому, что, похоже, расположение «на переднем крае прогресса» нынче уже является одним из ключевых бизнес-преимуществ. А если мы уже перешагнули за границу, то being on the bleeding edge уже не преимущество, а необходимость, чтобы держаться на одном уровне с конкурентами (а обогнать их можно только в случае, если ты сам обгоняешь прогресс своими действиями).
И в этих условиях вы жалуетесь, что… нет, блин, не месяц на апгрейд, даже не год на апгрейд — три года на апгрейд, 36 месяцев на то, чтобы перейти на софт, являвшийся устаревшим (ибо замороженным за несколько месяцев до выхода) даже на момент выхода stable-релиза — это слишком мало. За это время админ, дескать, не сможет раскачаться, подготовить, протестировать и реализовать план перехода на более-менее актуальный софт. За 2 года существования нового релиза со всеми его нововведениями в виде testing, за год после официального выпуска…
Что я могу сказать… без обид, но мне абсолютно не жаль бизнесы ваших «многих знакомых». С таким «апатичным» подходом к жизни они уже обречены.
>>Если изменение ABI уже предсказуемо (наш пакет работает на Python 2.5/2.6, но не работает на 2.7), то зависимость ровно так же и описывается.
Т.е. маинтейнер пакета в дебияне должен вручную проверять не сломали ли ABI зависимости? O_o?
Написал я python>=2.3. В 2.4 ABI сломали — Бага.
Написал я python = 2.4, А в 2.5 ABI не сломали, но пакет конфликтует — Бага.
И все это, из за невозможности сослаться в зависимостях на конкретную soшку.
>> Возможно, вы проецируете свойственное для редхатоидов на дебианоиды. В дебиане подобная ситуация является… ну, нонсенсом, ошибкой мейнтейнера, серьёзной проблемой.
Оба пакета могут лежать в абсолютно разных репозиторях с разными маинтейнерами которые знать не знают друг про друга.
>> Например, какой-нибудь метапакет «modern-linux-desktop» может зависеть от любого пакета «www-browser»
Это вы сейчас к чему? O_o Мета-пакеты есть и отлично живут в RHEL/CentOS.
>> Что я могу сказать… без обид, но мне абсолютно не жаль бизнесы ваших «многих знакомых». С таким «апатичным» подходом к жизни они уже обречены.
Зачем менять работающую систему? ЗАЧЕМ?
— Она написана на python 2.3.
— Она написана 10 лет назад
— Она на 100% выполняет свои задачи
Зачем менять и ломать? Ради понтов?
Попробуйте заикнуться о 3х летнем TTL автору софта для автономного телескопа или точки наблюдения за погодой, автору софта для банального терминала по приему бабла, автору софта по работе банкоматов — я посмотрю куда они вас пошлют и как на долго.
Т.е. маинтейнер пакета в дебияне должен вручную проверять не сломали ли ABI зависимости? O_o?
Написал я python>=2.3. В 2.4 ABI сломали — Бага.
Написал я python = 2.4, А в 2.5 ABI не сломали, но пакет конфликтует — Бага.
И все это, из за невозможности сослаться в зависимостях на конкретную soшку.
>> Возможно, вы проецируете свойственное для редхатоидов на дебианоиды. В дебиане подобная ситуация является… ну, нонсенсом, ошибкой мейнтейнера, серьёзной проблемой.
Оба пакета могут лежать в абсолютно разных репозиторях с разными маинтейнерами которые знать не знают друг про друга.
>> Например, какой-нибудь метапакет «modern-linux-desktop» может зависеть от любого пакета «www-browser»
Это вы сейчас к чему? O_o Мета-пакеты есть и отлично живут в RHEL/CentOS.
>> Что я могу сказать… без обид, но мне абсолютно не жаль бизнесы ваших «многих знакомых». С таким «апатичным» подходом к жизни они уже обречены.
Зачем менять работающую систему? ЗАЧЕМ?
— Она написана на python 2.3.
— Она написана 10 лет назад
— Она на 100% выполняет свои задачи
Зачем менять и ломать? Ради понтов?
Попробуйте заикнуться о 3х летнем TTL автору софта для автономного телескопа или точки наблюдения за погодой, автору софта для банального терминала по приему бабла, автору софта по работе банкоматов — я посмотрю куда они вас пошлют и как на долго.
Т.е. маинтейнер пакета в дебияне должен вручную проверять не сломали ли ABI зависимости?
«А никто не говорил, что будет легко».
И все это, из за невозможности сослаться в зависимостях на конкретную soшку.
Повторюсь, so-шки — это совершенно другой слой абстракции. Это файлы, содержимое которых… никому ничего не должно, таксзать. Введение их на уровень абстракции пакетов привело бы к мешанине. Точно так же в зависимостях дебиана нельзя указать зависимость «этот пакет предоставляет обработчик какого-то MIME-type-а», «этот пакет лицензируется по такой-то лицензии», «этот пакет сто́ит такую-то сумму». Возможно, если бы это было можно, это было бы… ну, прикольно. Но работает и без этого.
Оба пакета могут лежать в абсолютно разных репозиторях с разными маинтейнерами которые знать не знают друг про друга.
И при этом оба пакета предоставляют одну и ту же libxxx.so. Два разных репозитория, два разных мейнтейнера, одна и та же libxxx.so (и, что важно, с одним и тем же предоставляемым функционалом!) и зависимость пакета именно от имени libxxx.so…
Честно говоря, для дебианщика подобное звучит как-то безумно и инопланетно. Для дебианщика, который помнит, что для редхатоидов не существует центрального репозитория размером порядка 9 DVD-дисков для каждой платформы, зато существует огромное количество мелких репозиториев, где каждый кто во что горазд собирает пакеты как может — менее безумно, но всё равно инопланетно.
Для дебиана описанная проблема, скажем так, нетипична, ибо…
Во-первых, если мейнтейнеру (и я так понимаю, речь здесь и дальше идёт именно про стороннего мейнтейнера какого-то пакета, не входящего в официальный Debian-релиз, ибо в случае с входящим зависимости на сторонние пакеты просто не может быть) надо сослаться зависимостью на… нет, не на «файлик so-шки», а на какой-то конкретный функционал, то, наиболее вероятно, эта библиотека уже просто есть в Debian. Ссылаться на что-то стороннее просто незачем.
Во-вторых, если этой библиотеки нет пакетом в Debian, то, возможно, она есть на сайте разработчика библиотеки. Использовать неофициальную сборку при наличии официальной — это как-то…
Впрочем, на самом деле, и это не главное. В-третьих, главное — то, что мейнтейнер стороннего пакета, создавая пакет, должен как-то обеспечить его работоспособность. Он не может понадеяться, что «этот пакет будет работать, если установлен какой угодно другой пакет, в котором есть файлик libxxx.so по нужному пути» — может, какой-то сумасшедший китайский гений в своей распространяющейся в rpm-ах игре решил в таком файле хранить спрайты!
То есть, это значит, что мейнтейнер реально способен гарантировать (да что там, даже не гарантировать не способен, разве что более-менее предположить «наверное, будет работать») только работу своего пакета при наличии конкретного доступного функционала. Обещать работоспособность своего «xxx-money-crunching-server» при условии «наличие в системе файла libxxx.so» — огромная наивность, потому что код может рассчитывать, что libxxx.so является частью пакета xxxmoney, который «xxx-es your money», а на каком-то левом сервере лежит пакет showxxx, который «display hot XXX pictures», и в который тоже входит libxxx.so.
К чему это я? К тому, что мейнтейнеру слепо верить, что любой файл libxxx.so из любого пакета в интернете делает именно то, что надо, нельзя. Это может быть не так по целому ряду причин, включая злонамеренность создававших пакеты с libxxx.so мейнтейнеров, сделанные ими ошибки при мейнтейнинге пакета (а что если кто-то сделал пакет с libxxx.2.so, содержащий на самом деле libxxx.1.so?) и даже случайность совпадения имён.
Мейнтейнер должен (постараться) гарантировать работу не при «наличии файла в системе», а при «наличии установленной в системе функциональности». А единственный способ нормально обеспечить это находится именно на уровне пакетов. Если в природе в разных местах существуют предоставляющие libxxx.so и (почему-то) собранные разными мейнтейнерами пакеты lib-xxx, xxx-lib и lib-showxxx (и первые два из них предоставляют нужный функционал, а третий показывает картинки), то мейнтейнер должен явно написать Depends: lib-xxx | xxx-lib, и тогда пакет будет работать с намного бо́льшей вероятностью, чем если бы он написал Depends: libxxx.so.
Впрочем, что это я мысью по древу. В реальности же, всё будет намного проще. На странице xxx-money-crunching-server будет написано «Для работы вам понадобится установленная библиотека libxxx. Взять её пакеты можно с сайтов code.google.com/p/lib-xxx или с xxx-lib.sourceforge.net». И очень вероятно, что будет указана только один сайт, а не два, предпочитаемый мейнтейнером.
—
Зачем менять работающую систему? ЗАЧЕМ?
Попробуйте заикнуться о 3х летнем TTL автору софта для автономного телескопа или точки наблюдения за погодой, автору софта для банального терминала по приему бабла, автору софта по работе банкоматов — я посмотрю куда они вас пошлют и как на долго.
Хорошо, вы меня убедили. Я с вами полностью согласен, что существуют некоторые embeddedообразные системы, обновлять софт на которых в случае удовлетворения текущей версией всех потребностей нецелесообразно.
Я надеюсь, теперь вы сумеете меня убедить, что при том, что обновлять отдельные версии софта там нецелесообразно, в это же самое время целесообразно на таких системах обновлять операционную систему.
Добавлю одну вещь, про которую забывают: ведь выходом новых версий софта не только вносятся улучшения и новые фичи, но и исправляются старые баги и латаются дыры! Поэтому нельзя держать старый софт на продакшне, который доступен извне, даже если это только локальная сеть — вы гарантируете что не найдётся ни одного «интрудера»? Да, тяжело обновлять, и могут быть конфликты — но в таком случае как раз возможность сборки из исходников с прикладыванием патча — лучший выход.
Осспади. Дык RH тем и занимается, что бекпортит 14 лет все заплатки из новых версий.
Вот именно! Потому я и пишу, что обновляться всё-таки надо. Хотите — сами патчите, хотите — платите за RHEL… Но за 3 года без обновлений вас «поимеют».
Вы вообще о чем пишете?? O_o
Есть RHEL. В котором 14 лет в (например) mysql 4.0 бекпортят секурити патчи, при
этом версия мускуля не изменяется (ABI не изменяется), обновляется только версия пакета.
Есть бесплатный RHEL в виде Scientific Linux/CentOS.
Зачем обновлять версию софта или за что-то обязательно платить?
Есть RHEL. В котором 14 лет в (например) mysql 4.0 бекпортят секурити патчи, при
этом версия мускуля не изменяется (ABI не изменяется), обновляется только версия пакета.
Есть бесплатный RHEL в виде Scientific Linux/CentOS.
Зачем обновлять версию софта или за что-то обязательно платить?
Бывает что дыру без смены версии не заткнуть…
А CentOS и т.п. — это не RHEL, никакой уверенности что не притянется какой-то левый пакет при апдейте — нет, мало ли что там майнтайнер подложил (да и вообще с левых репозитариев мало ли что утянется). Да, такое маловероятно, но тем не менее вероятность не 0… А в настоящем RHEL — есть поддержка, и есть гарантия что если что-то не так — «рублём ответят». Впрочем, тем он и ценен, что все апдейты можно смело ставить, не боясь за живучесть продакшн.
А CentOS и т.п. — это не RHEL, никакой уверенности что не притянется какой-то левый пакет при апдейте — нет, мало ли что там майнтайнер подложил (да и вообще с левых репозитариев мало ли что утянется). Да, такое маловероятно, но тем не менее вероятность не 0… А в настоящем RHEL — есть поддержка, и есть гарантия что если что-то не так — «рублём ответят». Впрочем, тем он и ценен, что все апдейты можно смело ставить, не боясь за живучесть продакшн.
>> Мейнтейнер должен (постараться) гарантировать работу не при «наличии файла в системе», а при «наличии установленной в системе функциональности». А единственный способ нормально обеспечить это находится именно на уровне пакетов.
Феерический бред.
Вы вообще пакеты собирать пробовали?
При сборке бинарника линкукется конкретная версия версия (конкретный файлк). Какой — подсмотреть можно с помощью ldd. Причем тут «функциональность» — вообще не понятно никак.
Феерический бред.
Вы вообще пакеты собирать пробовали?
При сборке бинарника линкукется конкретная версия версия (конкретный файлк). Какой — подсмотреть можно с помощью ldd. Причем тут «функциональность» — вообще не понятно никак.
При сборке бинарника линкукется конкретная версия версия (конкретный файлк).
Мы всё ещё обсуждаем мир, в котором одну и ту же .so-шку могут предоставлять несколько разных пакетов, поддерживаемых разными не знающими друг друга мейнтейнерами с разными репозиториями?
И да, надеюсь, вы помните, что кроме «линковки .so с динамической загрузкой» на каком-нибудь C/C++, существует ещё огромное количество языков со своими способами code reuse-а и динамического связывания — .class-ы в Java, модули (причём, возможно, предкомпилированные) в Python, assemblies для Mono…
перед centos неоспоримое преимущество — конфигурация сети в одном файле.
Скорее всего Windows Server войдет в тройку.
Эх. Windows Server не увидал.
ммм, Slackware.
На работе мандрива (cups, ftp, http, cifs), дома арч (ftp, http, squid, nfs).
XenServer
Windows побеждает… Удевлен.
Сейчас 20% windows, 70% linux, 10% freebsd. Кто-кто побеждает?
Человек имел ввиду, что в текущем голосовании. Прокрутите страницу вверх и посмотрите.
А если убунту в вариантах ответов поделить ещё на 10.04 i386, 11.10 i386, 11.10 x64 и так далее, каждая и процента не наберёт. Вывод — убунты не нужны?
Я о том, что нужно или windows поделить на 2000, 2003, 2008, или линуксы объединить.
Я о том, что нужно или windows поделить на 2000, 2003, 2008, или линуксы объединить.
Нормальные варианты ответов, что вы придираетесь. Любой из списка можно подробить, но незачем.
А так можно составить результаты и линь-винда, и по дистрам линя.
А так можно составить результаты и линь-винда, и по дистрам линя.
Голову включаем, пожалуйста. Если бы винду разбили на 2003, 2008, 2008R2, то я бы отдал 3 голоса за винду вместо одного сейчас. Таким образом только из-за одного меня у неё бы сейчас было +2 голоса «в копилку», а суммарно было бы, я думаю, уже процентов 25, наверное. То же самое, если объединить линуксы — винда бы от этого только выиграла в смысле процентиков.
Смысл в том, что автора не особо интересует винда, и этот вариант ответа тут только для того, чтобы виндоадминам было куда проголосовать.
Смысл в том, что автора не особо интересует винда, и этот вариант ответа тут только для того, чтобы виндоадминам было куда проголосовать.
Oracle Unbreakable Linux, чтоб его…
Т.к. первая дистра линукса которая попала ко мне в руки и была освоена была Mandrake (6-ка иил 7-ка, уже не помню), то с тех пор ее и использую. Сначала Mandrake, потом Mandriva, но постепенно начинаю наспешно посматривать в сторону Ubuntu Server.
Вперёд Debian!
На рабочих серверах Debian, на домашних Ubuntu.
./configure && make && make install
Как уже писали, за make install на сервере надо убивать.
Предпочитаю Debian, стабильно, надежно и пока не подводил ниразу.
Как уже писали, за make install на сервере надо убивать.
Предпочитаю Debian, стабильно, надежно и пока не подводил ниразу.
> Как уже писали, за make install на сервере надо убивать.
Да-да, особенно если в Фряхе такое написать, то сразу на казнь!
Да-да, особенно если в Фряхе такое написать, то сразу на казнь!
Значит, мало использовали. У дебиана огромная херь есть в районе ha/hp-решений. В изобилии, я бы даже сказал. Другое дело, что у остальных с этим не сильно лучше.
А что конкретно имеется ввиду?
Проблемы с IET'ом (не вина дебиана, но они запаковали релиз с багом, вместо «тестинг» в котором бага нет), drbd8 не совсем правильно запакован, про настройку pacekeeper из коробочного дистрибутива и говорить нечего. NFS-сервер в 2.6.24 (ленни) с критическим багом (был?) и т.д.
Кроме того, периодически вылазят проблемы с совместимостью компонент и криво преднастроенными пакетами. Например, examples в порте фришного iscsitarget'а не совпадают между файлами. Я сейчас целиком список не оглашу, но проблемы там постоянно торчат хвостиками. Так у всех, кстати, всё равно сложную конфигурацию нужно целиком руками делать.
Кроме того, периодически вылазят проблемы с совместимостью компонент и криво преднастроенными пакетами. Например, examples в порте фришного iscsitarget'а не совпадают между файлами. Я сейчас целиком список не оглашу, но проблемы там постоянно торчат хвостиками. Так у всех, кстати, всё равно сложную конфигурацию нужно целиком руками делать.
Debian расстроил старыми репам, перешел на Ubuntu Server, там довольно свежо всегда
>7 на gentoo. Без нереканий.
1 на LFS. Роутер, фаерволл, балансировщик и прокси. Собирал не я, но работает отлично. Поражает как это всё умещается в 60мб памяти.
1 на LFS. Роутер, фаерволл, балансировщик и прокси. Собирал не я, но работает отлично. Поражает как это всё умещается в 60мб памяти.
основная масса на FreeBSD, и не сколько на ubuntu :)
на 10 серверах gentoo на одном RHEL
Slackware/DeepStyle пользую уже который год.
Более сотни серверов в HPC кластере на RHEL5. Дома Windows Server на поиграться :).
>Дома Windows Server на поиграться :).
дорогие у вас игрушки однако :)
дорогие у вас игрушки однако :)
На одной конференции была «боянистая» шутка.
Докладчик: «Кто из здесь присутствующих использует Visual Stuido?» — Результат лес рук. Второй вопрос: «Кто купил VS?» — 3 человека подняли руку.
Докладчик: «Кто из здесь присутствующих использует Visual Stuido?» — Результат лес рук. Второй вопрос: «Кто купил VS?» — 3 человека подняли руку.
Для того что бы использовать Visual Stuido, вовсе не обязательно ее покупать:
* есть бесплатные версии Express
* есть программы:
— BizSpark
— WebSiteSpark
— DreamSpark
Как видим достаточно много путей приобрести лицензионный софт бесплатно. И это касается не только VS, но так же SQL Server, Windows Server и многого другого
* есть бесплатные версии Express
* есть программы:
— BizSpark
— WebSiteSpark
— DreamSpark
Как видим достаточно много путей приобрести лицензионный софт бесплатно. И это касается не только VS, но так же SQL Server, Windows Server и многого другого
Как сервер для 1С пользую Сервер 2003. Как файлопомойка на другой фирме у меня Федора 14.
На своих — Gentoo, потому что работает как нужно. На клиентских — Ubuntu LTS, потому что быстро разворачивать + удобно рулить.
Однозначно Debian/Ubuntu, на чем вырос из *nix’ов, тем и пользуюсь на серверах, ничего лучше из пингвиноподобных не нашел. Не имею ничего против Mac на серверах, в виду того, что это основная, если не единственная, личная/рабочая платформа для меня, но как-то мало этого в серверной жизни встречается в принципе.
А лидирует, тем временем, Windows Server, ппц… что за ад тут творится? Серьезно? Всё так плохо? о_О
А лидирует, тем временем, Windows Server, ппц… что за ад тут творится? Серьезно? Всё так плохо? о_О
> А лидирует, тем временем, Windows Server, ппц… что за ад тут творится? Серьезно? Всё так плохо? о_О
Чекбоксы же.
Неужели не доводилось админить винсервер?
Чекбоксы же.
Неужели не доводилось админить винсервер?
Да, чекбоксы, потому и Debian + Ubuntu.
Ну вопрос-то «что вы используете на серверах», а не доводилось ли… Доводилось-то много чего, но вот пользую совсем не то же самое. Одно дело, если бы я был именно администратором где-то, мол, что сказали адмнить, то и админить, баста, но я — разработчик, поэтому сам выбираю, что и куда ставить, и тут места win-серверам не находится никогда, отчасти, именно потому, что доводилось трогать =)
Ну вопрос-то «что вы используете на серверах», а не доводилось ли… Доводилось-то много чего, но вот пользую совсем не то же самое. Одно дело, если бы я был именно администратором где-то, мол, что сказали адмнить, то и админить, баста, но я — разработчик, поэтому сам выбираю, что и куда ставить, и тут места win-серверам не находится никогда, отчасти, именно потому, что доводилось трогать =)
Нормального АД, например, сейчас можно добиться только с виндовым сервером. Или вы обходитесь без него? Садамаза…
Если речь идет о сервере в офисе, например, раз уж речь об Active Directory, то, возможно, в этом есть смысл, хотя, есть иные решения для групповых политик и т.п., да и в целом иные подходы к вопросу.
Но, опять же, я — разработчик, поэтому логическая цепочка, относительно названия опроса, у меня начинается с тех серверов, на которых бегут http-сервера, какие-то web-проекты и т.д. Юзкейсы разные. К тому же, представьте, что в офисе дни Маки стоят, — тут AD вряд ли пригодится вообще.
Но, опять же, я — разработчик, поэтому логическая цепочка, относительно названия опроса, у меня начинается с тех серверов, на которых бегут http-сервера, какие-то web-проекты и т.д. Юзкейсы разные. К тому же, представьте, что в офисе дни Маки стоят, — тут AD вряд ли пригодится вообще.
Если система смешанная (рабочие станции и линукс, и мак и винда), то управление доменом проще всего реализовать на винсервере, т.к. с АД работают все, а вот воткнуть виндовую рабочую станцию в какой-нибудь опенлдап не так просто :)
Никто не спорит, у каждого частного случая своя специфика и своё решение. Если все чекбоксы винды отвечают именно таким случаям, то я спокоен. Но что-то подсказывает мне, что это не совсем, а то и далеко не, так.
Да и настройка AD в Open Directory на OS X Server, начиная с 10.5, занимает минут 5, насколько мне известно, хоть и не моего поле действо, могу ошибаться.
Да и настройка AD в Open Directory на OS X Server, начиная с 10.5, занимает минут 5, насколько мне известно, хоть и не моего поле действо, могу ошибаться.
Вот хоть убей, не понимаю, чем осх более крутой сервер, нежли вин. Для управления виндовым парком валом тулз от мс, аналогов у которых либо нет, либо более кривы.
Обойдемся без кровопролития. Удобный, не стоит сравнительно диких денег, можно собрать всё или почти всё, что угодно, ибо полноценная «Unix-based POSIX compatible BSD» система и терминал ;-) Думаю и этого с лихвой хватит для ответа. Да и не утверждал никто, что «более крутой», необходимость и целесообразность решения для конкретного случая — вот, что круто… Раз уж разговор пошел про простоту настройки AD, то и упомянул OS X Server, как вариант.
Предпочтения одно. Но не все рашаеют что и где ставить. У нас все сервера в основном Windows 2003-2008, хотя душа больше лежит к FreeBSD/Linux. Однако против компании не попрёшь.
Прошу прощения, но что за ненависть к тому, чем сами не пользуетесь? Я абсолютно не защищаю Windows, и не говорю какой он хороший. Но статистика есть статистика. Сам на новой работе первый раз столкнулся с Windows-серверами (до этого сугубо FreeBSD, Ubuntu, Debian и CentOS), и скажу вам, что некоторые вещи там делать удобнее. Что именно? Как уже говорилось, AD, а также DNS, DHCP, File Share (с нужными правами доступа определенных пользователей из AD). Огромный плюс, впрочем как и огромный минус, продуктов Microsoft — это интеграция друг с другом. Например, пользователь, получивший по DHCP IP-адрес, может автоматически внести имя своего компьютера как IN A, так и IN PTR запись в DNS. Удобно? Да. Сделать такое на *nix? Реально, но далеко не одной галочкой.
Но остается также куча задач, которое на *nix'ах делаются намного проще и намного быстрее. И стабильнее к тому же.
Так что под каждую задачу есть инструмент. И одни инструменты лучше подходят, а другие хуже. И говорить, что я буду забивать гвоздь плоскогубцами только потому, что молоток мне не нравится — не есть правильный путь.
Но остается также куча задач, которое на *nix'ах делаются намного проще и намного быстрее. И стабильнее к тому же.
Так что под каждую задачу есть инструмент. И одни инструменты лучше подходят, а другие хуже. И говорить, что я буду забивать гвоздь плоскогубцами только потому, что молоток мне не нравится — не есть правильный путь.
В плане интеграции и автоматизации у MS конечно все хорошо.
Вот никто мне пока не смог рассказать как, и можно ли вообще, на Linux-based фаерволе/проксе (в полностью линуксовй среде или в среде с AD, не важно) сделать сквозную авторизацию, а на прозрачном прокси, или делегировать маршрутизатору права авторизации пользователей? Правда интересно, ибо TMG ну очень жруч не хочется покупать под него полноценный сервер (да и стоит, хоть не очень больших, но все таки денег)
Вот никто мне пока не смог рассказать как, и можно ли вообще, на Linux-based фаерволе/проксе (в полностью линуксовй среде или в среде с AD, не важно) сделать сквозную авторизацию, а на прозрачном прокси, или делегировать маршрутизатору права авторизации пользователей? Правда интересно, ибо TMG ну очень жруч не хочется покупать под него полноценный сервер (да и стоит, хоть не очень больших, но все таки денег)
Я уже несколько раз в данной ветке комментариев упоминал, что для каждой задачи свои решения. Мои задачи никак не соприкасаются с необходимостью использовать Windows Server. Ненависти нет, но и не пользуюсь не просто так… Если молоток хлипок и плох, то не грех и плоскогубцами забить ;) Холиварить не хочу и не буду, моё мнение.
На серверах Ubuntu Server и CentOS (примерно 50/50 из 5 и 6 версий). На IBM P series стоит AIX. Плюс мейнфрейм с z/OS.
В администрировании находится три сервера.
Два — Windows Server 2008 Standard 32-bit, один Windows Server 2008 R2 64-bit.
Три года — полет нормальный.
Два — Windows Server 2008 Standard 32-bit, один Windows Server 2008 R2 64-bit.
Три года — полет нормальный.
uptime?Да собственно не отслеживаем как-то.
Перезагрузки обычно после установки новых апдейтов для которых это требуется.
Перезагрузки обычно после установки новых апдейтов для которых это требуется.
да не все так плохо у венды с аптаймом. У меня на работе 2008й с 1Ской спокойно работает месяцами. Правда после долгого аптайма у 1Ски полезли странные глюки, несмотря на ежесуточный рестар службы. Вылечилось ребутом
А какая разница? Не у всех нагрузка круглые сутки. У меня, например, нагрузка на сервер в нерабочее время практически стремится к нулю. Если я ставлю какую-то заплатку на сервер, то безболезненно делаю это в нерабочее время. Даже две минуты роли не сыграет. Сервер FreeBSD и на данный момент аптайм небольшой — 52 дня. Не у всех критически важные сервера с необходимостью аптайма 24/7.
AD, IIS — uptime 268 days
hyper-v server — uptime 268 days :)
hyper-v server — uptime 268 days :)
У сервера БД на WinServ2003R2+MSSQL2005 — 492 дня. А если бы не аварияна подстанции, то и больше бы было.
Остальные так или иначе перегружались в последние три месяца. По разным причинам, но ни одна из них не была связана с «глюками ОС».
Statistics since 27.07.2010 14:56Остальные так или иначе перегружались в последние три месяца. По разным причинам, но ни одна из них не была связана с «глюками ОС».
Вот очень интересно, а чем обусловлены минусы к комменту и в карму?
Или у кого-то просто аллергия на слова Windows и Microsoft?
Минусуете — потрудитесь высказать с чем не согласны.
И да, я успешно применяю технологии Microsoft уже около 10 лет и полностью всем доволен, как и мои клиенты.
Или у кого-то просто аллергия на слова Windows и Microsoft?
Минусуете — потрудитесь высказать с чем не согласны.
И да, я успешно применяю технологии Microsoft уже около 10 лет и полностью всем доволен, как и мои клиенты.
Нууу… Это, знаете ли, хабр. Любое упоминание «майнстримной попсы» — сразу минусы. Windows в контексте приимуществ перед nix — тоже самое. PC — лучше чем Mac — на кол без разговоров. Ну ничего не поделаешь основная масса активной аудитории ресурса такие. Адекватные люди конечно есть, но и фанатиков не мало. Это видно в любой холиварной статье. Приоритеты таковы: Apple (soft или железо) Linux/pc > MS (не важно что и на сколько хорошее). Именно так, и никак иначе. Увы.
При этом многие, кто тут с гордостью отметил чуть-ли не все линуксы, а еще HP-UX, и о ужас AIX, не то что не знают что это, а даже издали не видали. Так, малюсенький вебсерверок на виртуалке дома — и весь кейс.
При этом многие, кто тут с гордостью отметил чуть-ли не все линуксы, а еще HP-UX, и о ужас AIX, не то что не знают что это, а даже издали не видали. Так, малюсенький вебсерверок на виртуалке дома — и весь кейс.
Надо количественно считать, а то например два на фре и двадцать на генте, а галочки по 1 баллу и дтуда и туда добавили.
Разве понятия Debian GNU/Linux не полностью включает в себя (например) Ubuntu Server?
Иначе подробность статистики, которую вы в нее вложили, портится: при не самом внимательном голосовании, что голосующий увидел первым, за то и проголосовал.
Иначе подробность статистики, которую вы в нее вложили, портится: при не самом внимательном голосовании, что голосующий увидел первым, за то и проголосовал.
Debian GNU/Linux и Ubuntu Linux — это разные дистрибутивы. По вашей логике надо тогда все Linux объединить в одно. Только вот многим интересна не соотношение Lin/Win, а именно среди Lin Distros статистика.
Сложили все виндовсы, сложили все линуксы и сравнили :)
Linux и BSD разные ОС. Так что должен быть минимум такой набор:
[] Linux
[] Windows Server
[] *BSD
[] Другие POSIX-системы (Solaris, HP-UX, etc.)
[] Linux
[] Windows Server
[] *BSD
[] Другие POSIX-системы (Solaris, HP-UX, etc.)
Толк следующий: по результатам кто-то может задуматься над вопросом: «а не взглянуть ли мне в другую сторону?». А кто-то подумает: «мой выбор совпал с выбором большенства, это наверное все-таки хорошо», или «мой выбор совсем не в мэйнстриме, это точно хорошо?». Ну или «вот эти муравьишки-дебианщики, ничего не понимают в жизни… Гента — вот это сила!», «Сервер на Убунте? Зачем… А может потому, что удобно разбираться только в одном дистре, а не в 10». Или вот еще: «Убунту слишком динамична, чтобы рабоать на серверах… Хотя походу многим на это пофигу. Хм...»
Короче, топик — пища к размышлению. А мысли у каждого свои будут :)
Короче, топик — пища к размышлению. А мысли у каждого свои будут :)
Используем Oracle Linux под базы Oracle, Ubuntu LTS для остального, для AD и т.д. — Windows 2003
Mandriva. Просто привычка, первый дистр был mandrake 9.1
FreeBSD, Microsoft Windows Server, Mikrotik RouterOS.
Почему именно Mikrotik RouterOS?
потому что умеет все, что нужно для core router, стоит вменяемых денег, работает на x86 совместимом железе, поставляется на router board'ах, проста в эксплуатации, надежна, подходит как для дома, так и для мелких, средних и, может быть, даже для крупных предприятий.
собственно я пока не встречал задач по маршрутизации, которые не смог бы на ней решить.
собственно я пока не встречал задач по маршрутизации, которые не смог бы на ней решить.
Это понятно. А чем оно лучше бесплатного FreeNAS, например?
ну во-первых давайте не будем сравнивать ОС для файл сервера и ОС маршрутизатора. они вообщене пересекаются по функционалу.
с друшой стороны я предпочитаю проприетарный софт для серверов т.к. качество его исполнения как правило на более высоком уровне. да и нечего мне делать, кроме как возиться со сборками/пересборками никс систем, когда нужно получить рабочее надежное изделие.
с друшой стороны я предпочитаю проприетарный софт для серверов т.к. качество его исполнения как правило на более высоком уровне. да и нечего мне делать, кроме как возиться со сборками/пересборками никс систем, когда нужно получить рабочее надежное изделие.
Я думаю keedhost ошибся и имел ввиду pfSense.
а каклй смысл от нее в сравнении с микротиком? разве что возможность сохранить подключения при подмене вышедшего из строя маршрутизатора живым.
в остальном что в ней хорошего кроме бесплатности?
после поверхностного обзора я вижу только очень малый саисок поддерживаемых технологий и обновление раз в пару лет.
в остальном что в ней хорошего кроме бесплатности?
после поверхностного обзора я вижу только очень малый саисок поддерживаемых технологий и обновление раз в пару лет.
В универе у нас был курс фряхоориентированый, не понравилась она мне в общем. Мой выбор — убунту.
Главное для сервера — ничего лишнего. Я выбираю Gentoo Linux.
CentOS/RHEL
Сервера бывают разные. И серверные системы нужно использовать под конкретные нужды.
К чему привык админ, то обычно и ставят, если нет жестких требований.
И дома основная и на серверах — Ubuntu 11.10 x64(естественно дома десктоп версия а на серверах серверные)
Захожу в топик как на ипподром. Кто же наберет больше голосов?!
10.04 Люблю LTS )
Freebsd (2 года стабильной работы с переодическими secure-based обновлениями и таким же аптаймом)
Centos на машинках попроще
Windows на десктопах
Centos на машинках попроще
Windows на десктопах
Винда + другие (Mikrotik)
FreeBSD + Centos.
7 серверов на фряхе — самый длинный аптайм был 3 года, и то пришлось тушить по причине переезда в другой ДЦ.
3 виртуальных на центосе. Linode не ставит фряху :(
7 серверов на фряхе — самый длинный аптайм был 3 года, и то пришлось тушить по причине переезда в другой ДЦ.
3 виртуальных на центосе. Linode не ставит фряху :(
Как читать эту статистику: «какие админы читают Хабр?».
Как не следует читать эту статистику: «какие серверные ОС более популярны?».
Думаю, что именно по этой причине такой мелкий процент у Винды. Ведь очевидно, что большенство «серверов»* на постсовковом пространстве работают под Windows Server.
* — включая десктопное оборудование, которое исполняет роль сервера.
Как не следует читать эту статистику: «какие серверные ОС более популярны?».
Думаю, что именно по этой причине такой мелкий процент у Винды. Ведь очевидно, что большенство «серверов»* на постсовковом пространстве работают под Windows Server.
* — включая десктопное оборудование, которое исполняет роль сервера.
Это же очевидно. Это просто «Какие серверные ОС более популярны среди проголосовавших на Хабре», раз тут голосовалка стоит.
По поводу Винды непонятно почему очевидно что большинство серверов на этой системе. Не вижу очевидности.
По поводу Винды непонятно почему очевидно что большинство серверов на этой системе. Не вижу очевидности.
Спросите у 10/100/1000 знакомых неадминов* какие сервера у них в офисе. Возможно в России в последнее время из-за «борьбы с пиратсвом» что-то поменялось, но в у нас Беларуси 99 % офисов полностью на Винде. А серверов в офисах на порядки больше, чем в датацентрах, где ситуация наверное обратная.
* — именно неадминов, потому что у линуксовых админов скорее всего будут и друзья линуксята (а вот для Виндовых админов, кстати, это правило может не действовать).
* — именно неадминов, потому что у линуксовых админов скорее всего будут и друзья линуксята (а вот для Виндовых админов, кстати, это правило может не действовать).
Сколько контор сменил в России, только в одной был один виндовый сервер. В остальных только GNU/Linux на серверах(ну и как-то было OpenBSD и Solaris)
Я не спрашивал, но просто знаю что среди моих знакомых никто не админит сервер на Винде.
Среди них есть Linux, фрюха, всякие коммерческие Unix'ы и т.п.
Спросить у знакомых не самый лучший вариант тут, так как обычно знакомые у людей появляются по интересам. Я серверной Виндой не очень интересуюсь, поэтому у меня легко не может быть таких знакомых вообще.
Думаю, что по большому счёту с этим связано.
Среди них есть Linux, фрюха, всякие коммерческие Unix'ы и т.п.
Спросить у знакомых не самый лучший вариант тут, так как обычно знакомые у людей появляются по интересам. Я серверной Виндой не очень интересуюсь, поэтому у меня легко не может быть таких знакомых вообще.
Думаю, что по большому счёту с этим связано.
И Ваша с вашей трактовкой «Какие серверные ОС более популярны...» я не согласен. У одних и тех же людей с большой вероятностью могут стоять разные оси на серверах и десктопах. Кстати, я как раз один из них.
Я как то по акции (Amazon EC2 mini год бесплатно был) использовал какую-то Амазоновскую ОС rpm-based для тестов. За весь год почему-то вышло всего одно обновление bind-а. Откуда там и что бралось разбираться не стал
Slackware!
Интересно что народ делает на HP-UX до сих пор? Разве что древний софт какой-то мешает перейти.
Большие конторы уже давно начали уходить с HP-UX на тот же Linux, это дешевле и эффективнее.
Большие конторы уже давно начали уходить с HP-UX на тот же Linux, это дешевле и эффективнее.
Там, где выбираю не я — Debian (разные версии).
Там, где выбираю я — FreeBSD, которую плавно заменяю на ArchLinux.
Фряха вполне достойно поработала ~4 года; Дебиан тоже около того. Обеими системами в целом доволен, но Арч несравнимо прозрачнее и яснее. Еще раньше была Fedora, от которой остались довольно скверные воспоминания, но я склонен винить скорее собственный непрофессионализм.
Там, где выбираю я — FreeBSD, которую плавно заменяю на ArchLinux.
Фряха вполне достойно поработала ~4 года; Дебиан тоже около того. Обеими системами в целом доволен, но Арч несравнимо прозрачнее и яснее. Еще раньше была Fedora, от которой остались довольно скверные воспоминания, но я склонен винить скорее собственный непрофессионализм.
Забавно, что ни в опросе, ни в комментах нет ASP-a, единственного линукса, лицензированного ФСТЭК.
Закон о персональных данных пролетает мимо:)
Закон о персональных данных пролетает мимо:)
Ubuntu Server 10.10, которая изначально была 10.04.х LTS, но из-за дурацкой политики обновил подменой репозиториев. Под дурацкой политикой я подразумеваю тот факт, что в репах 10.04 не добавляются новые стабильные пакеты, а только исправления безопасности. Итого мы имеем отсутствие, например, пакета php-fpm, который появляется уже в 10.10. Следующей осью на моём домашнем сервере будет Debian.
В Debian тоже не добавляют новых пакетов в стабильные репозитории ;)
Достаточно подключить в использование Testing, чтобы я и сделал. Там есть всё что надо. А дистр живёт поболее чем пол года (до выпуска следующей версии, в смысле). В убунте как ни крути, либо подключай репу 10.10 и выходит ни два ни полтора, либо обновляйся, что я и сделал.
Подключение тестинга на продакшен тоже плохой вариант, на мой взгляд.
Уж лучше обновиться до следующего релиза.
Уж лучше обновиться до следующего релиза.
Почему же? Это свежие пакеты, но уже прошедшие анстейбл. Да и что сейчас есть выше 6.0.3? :) По идее все необходимые пакеты в дебиане должны быть в стейбл, типа того же php-fpm. А если нету (что, имхо, странновато, конец 2011 на дворе) и паранойя гложет, то можно подключить, поставить пакет и отключить.
Только в 'generic'-случае. На практике часто приходится работать с конкретными версиями, насрав на то, что в stable. Кстати, яркий пример «думай, а не доверяй» — в sqeeze находится кривая версия эрланга (альфа-версия новой версии на момент freeze'а), а стабильная версия (релиз той же альфы) — в sid'е. Багрепорты засланы колоссальные, но мейнтейнер боится в security team идти, а без них в stable нельзя новые версии засылать.
Я могу рассказать о печальной истории под названием LuaRocks и Debian/Ubuntu…
Когда сломанный LueRocks в обоих дистрибутивах в релиз ушли
Потому у меня свой репозиторий для части пакетов просто напросто :)
Когда сломанный LueRocks в обоих дистрибутивах в релиз ушли
Потому у меня свой репозиторий для части пакетов просто напросто :)
Именно так и получается в крупных и серьёзных фермах серверов. А задача дистрибутива не мешать этому и обеспечивать вменяемое окружение (чтобы деплой касался конкретного языка/библиотеки/демона, а не пачки базовых утилит для выживания, вроде psutils, moreutils и т.д.). Ну и инфраструктура управления конфигурацией.
Кстати, почему-то никто дебиану не написал главного преимущества — детальной полиси, позволяющей не изучать конфигурацию методом тыка, а понимать её.
Кстати, почему-то никто дебиану не написал главного преимущества — детальной полиси, позволяющей не изучать конфигурацию методом тыка, а понимать её.
zOS.
20% — большой показатель. В большинстве дата-центров Windows Werver встречается не чаще FreeBSD. А самые популярные Debian и CentOS. Фейковые голоса…
Это все так только во-первых: речь тут далеко не только про дата-центры. Во-вторых: не учитывается количество. У меня например три десятка серверов с Windows на борту, и всего 3 с линуксом, причем два на Ubunte и один на CentOSе. А по результатам голосавания следует, что у меня Linux-ов вдвое больше чем windows-ов.
Ничего себе «лишь». Вас так учат в опенсорсе говорить что ли: если проприетарка, то «лишь», а если никсы, то «целых»? На каждом пятом сервере (куда местные с лёгкой руки включили домашних франкенштейнов, файерволлы и файлопомойки на которые ставят микротик и freenas) — винда — это долбанись какое количество, если вдуматься.
Одному мне смешно читать комменты типа «у меня ДОМА на СЕРВЕРЕ установлена %OSName%»? Хотя, какой вопрос — такой ответ, конечно…
Ну, во-первых, у большинства есть домашняя локалка — т.е. на домашнем компьютере будет нелишним как минимум ftp поднять. Во-вторых, некоторые счастливчики обладают внешними айпишниками — таким не грех и торренты поднять, веб-серверок организовать…
В общем, почему бы домашнему компьютеру не выступать в роли сервера?
В общем, почему бы домашнему компьютеру не выступать в роли сервера?
От того, что я подниму фтп-сервис на вин7, то моя помойка с двуядерным атлоном тут же превратится в сервер? Или если я поставлю Вин2008 на неё же? Если уходить в терминологию, то любой компьютер с открытым портом, на котором что-то слушает, является сервером. Включая роутеры, NAS'ы и прочие умные потребительские железки. Вряд ли автор поста хотел собрать статистику по ним.
> От того, что я подниму фтп-сервис на вин7, то моя помойка с двуядерным атлоном тут же превратится в сервер?
Конечно. Неужели вы думаете, что автор хотел собрать статистику по серверам с высокой загрузкой?
Много ли на хабре найдется админов таких серверов? Лично я такие серверы вживую ни разу не видел. Большинство серверов, которые мне встречались, представляли собой самые обычные десктопы (причем зачастую — старые десктопы, которые жалко выкидывать), даже почтовые и прокси-серверы.
Конечно. Неужели вы думаете, что автор хотел собрать статистику по серверам с высокой загрузкой?
Много ли на хабре найдется админов таких серверов? Лично я такие серверы вживую ни разу не видел. Большинство серверов, которые мне встречались, представляли собой самые обычные десктопы (причем зачастую — старые десктопы, которые жалко выкидывать), даже почтовые и прокси-серверы.
А что внешний айпишник для домашнего абонента — это уже диковина? У меня пров раздает за ~450 выделение + 30р/мес. Почти халява.
Было бы интересно увидеть статистику исходя из задач. Линуксов, конечно, много здесь, но какие задачи на них ложатся? Какие требования в рамках задач: минимальный даунтайм, максимальная производительность, ПО и т.д.?
Например, я работаю с HP-UX и AIX. Корпоративные сервера с аппликейшнами и ораклом. К серверам очень высокие требования к аптайму, производительности и т.д. При чем параметр, например, «аптайм», говорит не только о том, что система «заглючит и потребуется ребут», но еще и, например, возможность расширения/уменьшения разделов без отмонтирования и т.д.
В данных условиях я вижу следующую картину: Windows server не справляется абсолютно никак (реакция на внешние проблемы неадекватна, проблемы могут появиться в случайный момент времени просто из ниоткуда; Linux гораздо лучше, но все равно не хватает пока той же динамики).
В условиях вычислений, где требования идут чисто к производительности, linux, конечно, на высоте: производительность, ПО, конфигурируемость дают свое. Кстати, эти задачи, в основном, и возлагаются на то подавляющее большинство из топа.
В общем, мое предложение специалистам по опросам я описал :-) Ибо фигня эта статистика, если не берутся во внимание задачи.
Например, я работаю с HP-UX и AIX. Корпоративные сервера с аппликейшнами и ораклом. К серверам очень высокие требования к аптайму, производительности и т.д. При чем параметр, например, «аптайм», говорит не только о том, что система «заглючит и потребуется ребут», но еще и, например, возможность расширения/уменьшения разделов без отмонтирования и т.д.
В данных условиях я вижу следующую картину: Windows server не справляется абсолютно никак (реакция на внешние проблемы неадекватна, проблемы могут появиться в случайный момент времени просто из ниоткуда; Linux гораздо лучше, но все равно не хватает пока той же динамики).
В условиях вычислений, где требования идут чисто к производительности, linux, конечно, на высоте: производительность, ПО, конфигурируемость дают свое. Кстати, эти задачи, в основном, и возлагаются на то подавляющее большинство из топа.
В общем, мое предложение специалистам по опросам я описал :-) Ибо фигня эта статистика, если не берутся во внимание задачи.
>реакция на внешние проблемы неадекватна, проблемы могут появиться в случайный момент времени просто из ниоткуда
Не могли бы на примерах пояснить?
Не могли бы на примерах пояснить?
Не хочу холивар разводить. Это всего лишь мои выводы как стороннего наблюдателя, я написал это для более глубокого понимания того, какие выводы я хотел бы вынести из опроса.
Вообще-то фраза
«не справляется абсолютно никак (реакция на внешние проблемы неадекватна, проблемы могут появиться в случайный момент времени просто из ниоткуда; Linux гораздо лучше, но все равно не хватает пока той же динамики).»
сама по себе холиварна так не несет никакой конкретики.
Точно так же я могу привести пример когда на сервере с линуксом база данных не выдерживала высоких нагрузок, а после перехода на MS SQL все проблемы удалось решить.
«не справляется абсолютно никак (реакция на внешние проблемы неадекватна, проблемы могут появиться в случайный момент времени просто из ниоткуда; Linux гораздо лучше, но все равно не хватает пока той же динамики).»
сама по себе холиварна так не несет никакой конкретики.
Точно так же я могу привести пример когда на сервере с линуксом база данных не выдерживала высоких нагрузок, а после перехода на MS SQL все проблемы удалось решить.
Да боже упаси холиварить, взрослые же люди. Просто такая абстрактная и безаппеляционная формулироска, мягко говоря, наталкивает на уточнения. Мой опыт не подверждает такую непригодность винды и продуктов МС. Тем более, что глючит как правило не сама ОС а приложения, так что говорить что сама ОС дерьмо имея опыт неудачной эксплуатации какого-либо софта, по иеньшей мере не корректно.
Вот мне и интересо, чем именно вызвана такая категоричность?
Вот мне и интересо, чем именно вызвана такая категоричность?
Уточнения привлекут толпу вендотролей и начнется… не хочу. Да и не вижу в этом смысла, мне от продуктов МС ни холодно, и ни жарко, я лишь написал свой вывод исходя из опыта работы в команде админов серверов довольно крупной компании, при чем написал для конкретной цели, и отходить от этого в комментах я не буду.
И я говорю именно об ОС, не о ПО.
И я говорю именно об ОС, не о ПО.
AltLinux
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какие операционные системы и дистрибутивы вы используете на серверах?