Reliability is more than just "we're more stable than Windows."

Веселый парень это Эрик :)))

в предвкушениии начал конца ))))))))))))

не доля правды канечно же есть в этом, но тут опять же с какой стороны подойти, сановец пишет про совместимость апи, драйверов etc, ну да это верно, он там нвидию приводит в пример, НО! товарсчи там солярку приподносят как _СЕРВЕР_ а линукс как десктоп типа тама дрова не пашут от нвидии, что за бред ну если сравниваем серверные оси так сравниваем!!, пингвину на серваке крутить тока сеть и скази (или сата) контроллеры, и в этом тут нету _НИКАКИХ_ проблем.... ей богу читать эту ерись сановцев пративно

Ну конечно, а общение с ситемами мониторинга, сервисными процессорами и т.д.

>Ему отвечает linux kernel moneky Greg

Опечатка ? Наверное имелось ввиду monkey ? btw, заслэшдотили гады блог линуксоида.

Я тоже обратил внимание, но ведь monkey - это обезьян?

Я чё то не понимаю такого тонкого юмора.

недавно ко мне компашки пришли с 10-м солярисом, вот думаю попробывать её на работе, поставить на второй сервер. Вообще как она на счёт стабильности, поддержки железа и т.д.?

Let's take these one by one:

reliability: both the Linux and Solaris kernels have a record of high reliability, so I don't know what this guy is going on about.

observability: seems to me that what's going on in the Linux kernel is a lot less opaque than what's going on in Solaris (though the situation may look different to Sun engineers if they have have kernel debug tools that they don't ship).

serviceability: as long as Solaris is not open source, if a user has a Solaris bug and Sun decides not to fix it, she's stuck, while any number of independent consultants can be hired to fix their Linux bugs. If he just means that it's easier for Sun engineers to service Solaris, that's because they are experienced with Solaris. resource management: don't know enough to compare.

binary compatibility: here he has a point. While there's an argument for changing interfaces when it can yield an improvement, it breaks old drivers, and even if they are open source, they languish until someone fixes them. And Sun has to deal with peripheral suppliers who won't agree to open-source their drivers or provide specs without an NDA. In my view, this is Eric Schrock's only legitimate objection.

Cанч. Поставь себе aspell. Я тебя умоляю!

Re:

У них (санок) вообще оживление наблюдается. Сначала Шварц рассказывает всем, как плохи и проприетарны Power5 (с линуксом на борту), и как хороши солярисы на всех из себя "Open" и "Standard" спарках. Потом вот этот Эрик. "Это ж неспроста", как говорил один мультипликационный герой.

Get the facts, так сказать, с другого боку.

P.S. Кстати, кто-нибудь Солярис10 вживую на Оптеронах видел? Или байка из склепа очередная?

Это агония.

Начальники вернувшиеся из амстердама с ТВ выставки от сана впечатлились сильно - так что сан скорее жив чем мертв.

>Кстати, кто-нибудь Солярис10 вживую на Оптеронах видел? Или байка из >склепа очередная?

Вроде уже в мультиюзер научили работать :)

А так в 2005 году релиз обещают

Больше 10-и прог запускает?

Solaris 10 видимо будет выпущен в конце этого года. Знакомый покрутил на Solaris 10 мультизонинг (аналог логических доменов в AIX) остался очень доволен.

> Больше 10-и прог запускает?

Точна! А как ви дохадались?

> Больше 10-и прог запускает?

Не, в стартер эдишн больше 10 не могет.

Если в солярке fork еще не полечили то счет не в ее пользу. В 2.6 треды уже относительно сносные.

Насчет "ненужности" бинарных дров в линухе - откровенный гон. То-то до сих пор опенсорсных дров ни для новых радеонов, ни для джифорсов нет. Так что не только Sun приходится иметь дело с не-опенсорсниками...

А вообще ответы линуксоида в данном споре как-то слабоваты... все больше из разряда "да, ну и что? все равно это никому не надо". Обидно.

ду тут вобще не ясно наболт этот спор и дикий усер ? линукс. - кучка кодеров кодят себе в удовльствие, дистростроители клепают дистры. все довольны. сантехники. пашут за лаве выходит не хуже но и не лучше им обидно. нада все засрать.. .....

Комментарии Эрика смотрятся горрраздо убедительнее... :(

int19h, Так в мире Linux'a так принято, если чего-то нет что есть в других системах, так сразу "да нам это не надо", а как появляется какая-нибудь малозначительная хрень так сразу крику "а у нас зато вот что есть!"

З.Ы. Про дрова на 100% поддерживаю.

> Я чё то не понимаю такого тонкого юмора.

ну вот ты пришешь про себя "я-то - ламерок", а он - про себя "обезьянка" ;)

Про дрова на НЕ поддерживаю. Линукса почти претендует на world domination :-), от пылесоса до космического корабля, поэтому нельзя замораживать Driver API. У сан только относительно узкий сегмент рынка, поэтому они могут с замороженным api медленнее развиватся.

Re:

Я ж спрашивал "вживую".

если дырка в голове, надо пить зеленку

> Линукса почти претендует на world domination :-), от пылесоса до космического корабля,

Именно поэтому Linux'-у и нужены стабильные API и ABI для драйверов. Чтоб kernel hackers успевали хоть как-то развивать ядро, а не заниматься переписыванием одного и того же кода по десять раз для всей массы железяк, про которые знает Linux, а оные драйвера писали те, кто эти железки клепает.

> поэтому нельзя замораживать Driver API.

Где логика? (C) Вовочка.

> У сан только относительно узкий сегмент рынка, поэтому они могут с замороженным api

Опять таки, все наоборот. Это они могли бы _в принципе_ позволить себе сломать API, если очень понадобится. Но не ломают...

>>Так в мире Linux'a так принято, если чего-то нет что есть в других >>системах, так сразу "да нам это не надо", а как появляется >>какая-нибудь малозначительная хрень так сразу крику "а у нас зато вот >>что есть!"
Это вы уважаемый путаете мир Linux'a с миром BSD.

> Начальники вернувшиеся из амстердама с ТВ выставки от сана > впечатлились сильно - так что сан скорее жив чем мертв.

Амстердама ? Это там, где "extasy, cocain", а потом Масяня по голове молотком бьет ? Я бы тоже впечатлился после такого :)

>> Линукса почти претендует на world domination :-), от пылесоса до космического корабля,
это в том смысле что он туда движется по всем направлениям, это не цель но результат его развития, впрочем разговор не об этом.
> Именно поэтому Linux'-у и нужены стабильные API и ABI для драйверов.
> Чтоб kernel hackers успевали хоть как-то развивать ядро, а не заниматься переписыванием одного и того же кода.

Дорогой user, таки очень трогательная забота о кернел hackers, которые не ведают что творят и не успевают развивать ядро.
Вот ваши советы им бы очень помогли.
Как раз бурное развитие Linux и просит смены API, точнее модификаций API.
Так как это требует модификаций множества драйверов, то такие решения принимаются не каждый день.
И принимаются они умными и грамотными программистами, например Линусом,
который всегда взвешивает за и против.
Впрочем это на втором месте. А на первом месте - система с открытыми исходниками и свобода модификации своей системы.

Линус много раз говорил что бинарные дрова UNwelcome. Они имеют много недостатков.
Ограничивают свободу управления своей системой, свободу от proprietary software
Они глючат гораздо сильней, чем дрова которые в mainline, и их нельзя самостоятельно исправить.
Они работют только под одной-двумя архитектурами, а Линукс на многих - т е недостаток.
Часто производители железа забивают фиксить баги в драйверах для
своего старого железа, которое сняли с производства.

Я слабо сформулировал, про ограничение свободы системы от проприетарщины, но это главный аргумент.
Эта свобода не продается ради вашего удобства пользователя.
Поэтому главных разработчиков Linux не волнует судьба binary драйверов
Они не занимаются проблемами UNwelcome кода.

> Линукса почти претендует на world domination :-), от пылесоса до космического корабля, поэтому нельзя замораживать Driver API.

Меня слабо волнуют перспективы применения линукса на пылесосах. Я в NWN поиграть нормально хочу и в UT2004! А тут что ни ядро - проблемы с дровами...

> Знакомый покрутил на Solaris 10 мультизонинг (аналог логических доменов в AIX) остался очень доволен.

да ничего революционного. по сути своей - chroot + restricted /proc.

> Опечатка ? Наверное имелось ввиду monkey ? btw, заслэшдотили гады блог линуксоида.

Monger

> Если в солярке fork еще не полечили то счет не в ее пользу. В 2.6 треды уже относительно сносные.

Cмысл лечить форк ? Не лучше ли причесывать трединг ? Форк - вешь достаточно дубовая. В смысле кодинга конечно просто, но в плане проектирования дублировать весь код для исполнения пары процедур ? ИМХО не эффективно. А до соляровых тредов Линуху до БСД и Солярки пока далековато. 2.6.х - Просьба не рекомендовать поскольку очень сырое ядро, не для продакшна. А в плане десктопа Солярис - не так уж плох. А принимая во внимание наличие под него серъезного проприетарного софта, и возможность портирования ОСС - это 100 очков вперед.

Это все мое мнение, сложившиееся на данный момент. Все еще может перемениться.

Driver API

>что ни ядро - проблемы с дровами

Каким-то образом несколько десятков злобных ядрописателей умудряются в свободное время править драйвера(вслед за API) сотен устройств с такой скоростью, что весь штат программистов NVidia/etc. не успевает исправить драйвера 2-3 железок этой компании. Может в консерватории что-то исправить?

>в плане проектирования дублировать весь код для исполнения пары процедур ?

Если Вы свято верите, что при fork'е ядро дублирует код, то и флаг Вам в руки - я думаю народ поимеет о Вас свое мнение, но объясните, как это связано с проектированием?

>в плане проектирования дублировать весь код для исполнения пары процедур ?

И в догонку - в нормальных юниксах ( и слюниксе тоже ) форк по стоимости почти не отличается от создания LWP. Ключевое слово COW.

> Если Вы свято верите, что при fork'е ядро дублирует код, то и флаг Вам в руки - я думаю народ поимеет о Вас свое мнение, но объясните, как это связано с проектированием?

Здрасте! Ну ДОПУСТИМ. ЕСЛИ я ошибся, но тогда каким же образом форкнутый процесс имеет собственную область данных и процедуры, независимые от родительского процесса ?

А как это связано с проектированием ? КХМ КХМ. Напрямую!

> В смысле кодинга конечно просто, но в плане проектирования дублировать весь код для исполнения пары процедур ?

Гы-гы-гы, дублировать код??? ROFL

Я тебе больше скажу, там и данные не дублируются, пока страницы не пытаются изменять, это называется copy-on-write.

> Здрасте!

Привет.

> Ну ДОПУСТИМ.

Не "ну допустим", а эти принципы описанны в любой серьёзной книжке по архитектуре юникс, виртуальной памяти, виртуальных машин, операционных систем.

> ЕСЛИ я ошибся, но тогда каким же образом форкнутый процесс имеет собственную область данных и процедуры, независимые от родительского процесса ?

Код он и есть код, зачем его дублировать, один процесс идёт по одной ветке, другой по следующей. На страницы данных ставиться защита, при записи вызывается страничное прерывание, обработчик которого и делает копию страницы, это и есть Copy-On-Write (COW), и всё это ты мог узнать, если бы учился в школе, а не орал на ЛОРе!

> Не "ну допустим", а эти принципы описанны в любой серьёзной книжке по архитектуре юникс, виртуальной памяти, виртуальных машин, операционных систем

Если бы реализации в книжках и в реали были-бы настолько одинаковыми, не было бы разницы в реализациях. ИМХО книги описывают, начало и конец, как то не очень вдаваясь в то как это реализовано в той или иной ОС.

>Copy-On-Write Т.е. область данных все-таки копируется ?

> и всё это ты мог узнать, если бы учился в школе, а не орал на ЛОРе! Если бы этому учили в школе я бы уже набелевскую хапнул, А по-поводу орать... это ты зряааааа.

> ИМХО книги описывают, начало и конец, как то не очень вдаваясь в то как это реализовано в той или иной ОС.

Естественно, но хитрый приём Copy-On-Write - известный конёк Юникс cистем.

> Т.е. область данных все-таки копируется ?

Копируется страница данных, если в неё пытаются писать!

> Cмысл лечить форк ?
вы postgresql или apache 1.x используете ?

> Естественно, но хитрый приём Copy-On-Write - известный конёк Юникс cистем.

Не знал. :( Из более-менее сурьезных мурзилок на эту тему ничего не посоветуешь. Просто гадом буду о дублировании кода форком где-то читал, прикинул в уме мол типа форк делает процесс-близнец посему области данных у родительского и дочернего разные и общатся им только через костыли, вроде сходится....

> вы postgresql или apache 1.x используете ? И то и другое только не под соляркой - для солярки есть оракл.

> Каким-то образом несколько десятков злобных ядрописателей умудряются в свободное время править драйвера(вслед за API) сотен устройств с такой скоростью, что весь штат программистов NVidia/etc. не успевает справить драйвера 2-3 железок этой компании.

Речь не столько об API, сколько об ABI. Стабильность последнего, разумеется, опенсорсные дрова не затрагивает.

>Речь не столько об API, сколько об ABI. Стабильность последнего, разумеется, опенсорсные дрова не затрагивает.

Если изменение ABI требует _только_ перекомпиляции исходников(к примеру struct-ы поменялись) - это не вызовет проблем у поставщика бинарных дров. Легко написать скрипт, автоматом пересобирающий драйвер для каждой выложеной версии исходников ядра и каждой существенно разной комбинации параметров и выкладывающий результат для скачивания клиентами.

Если изменения более глобальные и нужно _переписывать_ код - разработчики бинарных дров вынуждены это делать _только_ для нескольких железяк, причем в местах, скорее всего, общих для всех драйверов, т.е. 1 раз. Все равно это намного меньше работы, чем у разработчиков ядра с сотнями драйверов написаных в _разное_ время _разными_ людьми с _разными_ представлениями о том, как писать "правильно".

Т.о. не вижу проблем (за исключением написания скрипта для сборки ядра - может разработчики драйверов у них с sh-ами не знакомы:).

> И принимаются они умными и грамотными программистами, например Линусом

На второй курс ему надо, еще раз послушать Таненбаума. Может дойдет.

> Линус много раз говорил что бинарные дрова UNwelcome.

Ничего, дядьки из RH и SuSE ему вправят мозг.

> Ограничивают свободу управления своей системой, свободу от proprietary software

Плевать на идеологию.

> Они глючат гораздо сильней, чем дрова которые в mainline

Правильно. Нет драйвера -- нет и глюков.

> и их нельзя самостоятельно исправить.

Пускай VM исправят для начала.

> Я слабо сформулировал, про ограничение свободы системы от проприетарщины, но это главный аргумент.

В психушку с этими комуняцкими бреднями.

> Поэтому главных разработчиков Linux не волнует судьба binary драйверов

Также их не волнует ни NFS, ни LSM, ни PaX; им вообще на все забить.

Про API/ABI. Мысль такая: Линуса, наверное, не переубедить. И отмазы у него какие-то странные. Вопрос: выход есть? Мне кажется, есть. В первом (читай "грубом") приближении. Если Линус не хочет тратить силы на стабилизацию API/ABI ядра, то, думаю, логично это сделать кому-то из крупных дистростроителей. Лучший вариант, если они между собой о чем-то договорятся и изваяют некий враппер (*.o/*.ko + еще не знаю что) со стабильным внешним интерфейсом и нестабильным интерфейсом с ядром, который будет пачиться от ядра к ядру. При этом производители железяк смогут сориентироваться уже на этот враппер и быть в какой-то мере уверенными, что их железка "заиграет" на всех ядрах. Если этот враппер получит популярность, то Линусу уже некуда не будет деваться - придется поставить его в основную ветку ядра и не релизить ядра, пока не стабилизируют враппер. То есть его свобода не нарушается и пользователи останутся довольны. Такие вот мысли. Но вот пока никто за такую работу не взялся. Не актуально что-ли? Или так нельзя реализовать, как я написал?

>> И принимаются они умными и грамотными программистами, например Линусом
> На второй курс ему надо, еще раз послушать Таненбаума. Может дойдет
Dselect ты малограмотный ламер много из себя мнишь.
На ЛОРе много ламеров в области linux-kernel собралось, однако
большинство не мнит себя самыми умными.

>> Ограничивают свободу управления своей системой, свободу от proprietary software
> Плевать на идеологию. В психушку с этими комуняцкими бреднями.
С помощью этой идеологии сделали прекрасную ОС, потому
что в ней заложены __работающие__ технические принципы.
Эти принципы с одной стороны немного мешают, а с другой сильно помогают.
Мы видим как это __работает__ по распростронению Линукса.
Ты можешь не соглащатся и орать в ЛОРе, но это официальная политика,
и на твое мнение и ведущим разработчикам kernel и мне в частности глубоко наплевать.

P.S. Не нравится и мнишь себя самым умным - пиши свою ОС или пользуйся другой ОС.
Можешь сходить на лекции еще раз послушать Таненбаума.

> Не знал. :( Из более-менее сурьезных мурзилок на эту тему ничего не посоветуешь.

Эндрю Таненбаум "Современные операционные системы"

> Просто гадом буду о дублировании кода форком где-то читал, прикинул в уме мол типа форк делает процесс-близнец посему области данных у родительского и дочернего разные и общатся им только через костыли, вроде сходится....

Ну код дублировать навряд ли, страницы кода помечены сразу как "только для чтения", попытка записи в страницу кода вызовет прерывание, которое скорей всего свалит прогу в кору.

Данные да, по спецификации они должны при форке копируются, но в Юниксах используется этот хитрый приём.

А вот общение делается через трубы, разделяемую память, и прочии прелести юниксвэя.