Солярка & Линукс : кто круче ?

Sun Studio это набор закрытых компиляторов без которого солярку не собрать из-за того что build архитектура сильно зависит от проприетарных экстеншенов сановского мейка который входит в этот набор.

Всё флейм разжигаем?!

ну, флейм так флейм....

венда круче!!!

IMHO все плюсы солярки (которые действительно имеют место быть) меркнут перед одним большим недостатком - стабильный драйверный ABI. раньше я был его сторонником, но когда понял какие ограничения он налагает, поменял свое мнение в другую сторону.

и еще, супер файловая система ZFS требует в районе гигабайта памяти для нормальной работы.

>>Sun Studio это набор закрытых компиляторов без которого солярку не

Я почему-то подумал , что Sun Studio - это среда типа еклипса :-)

>>стабильный драйверный ABI

а можно поподробнее ?

нет нельзя. сами разбирайтесь.

HINT в исходниках линукса рассказано почему в линуксе не стабильный.

по поводу файловой системы :
чел пишет , что и сановская UFS , и линуксовая ext2f произошли от одного предка - BSD UFS filesystem
он говорит , что UFS реализован лучше - типа ACL в ней поддерживается уже лет 10 как , в то время как в линуксе - только начиная с версии 2.6
вообще , многие вещи впервые появились в солярке - это идеология файловых каталогов /proc , /home , PPC , NFS ,

еще раньше /proc появился в plan 9, и если не ошибаюсь ext пошел как переработанная миниксовская фс.

к недостаткам линуксовой ext2 относится тот факт , что первоначально , в бсд-шной редакции , файловая система была завязана на run level . а влинуксе это поломали , и все завязано на UID

> в бсд-шной редакции , файловая система была завязана на run level

Это о каком run level в BSD речь идёт?

Защита стека - built-in stack overflow protection - в солярке это есть , в линуксе нет.
Это предотвращает неавторизованный рутовый доступ к системе

Далее :
RBAC в солярке появился еще в 2000 году , и в виде SELinux в редхате - много позже

>Это о каком run level в BSD речь идёт?

Наверно , речь идет о бсд-шном securelevel

> Сетевой стек в солярке реализован лучше

Да-да-да, и ping of death в солярке пинговее и дисовее :-)

> В линуксе сложился олигархический стиль управления.На вершине стоит Линус , и все , что бы он не сказал , да будет исполнено

Замени "линукс" на "солярис", а потом еще и "линус" на sun microsystems. Никакой разницы, верно?

> Нет преемственности и традиций в разработке ядра

И несмотря на все "традиции" солярис на x86 не выжил, и остался на рынке только благодаря "персональной платформе" (спарк) и охрененным бабкам которые вложили когда-то в эту платформу клиенты sun (для сохранения инвестиций было выгодней покупать поддержку а не новое железо). И первый раз соляриса убил, кстати, именно линукс. OpenSolaris - это уже вторая попытка.

> и потоки внутри единого процесса выполняются внутри единого виртуального пространства , и нету context switch

Ну и пофиг. С точки зрения приладного программиста context switching'а не существует. А тот же оракел (а соляру кроме как подкладку под него редко где встретишь) все равно в разных процессах крутится - так что пофиг.

Если у тебя есть спарки (куча спарков) с солярисом, то солярис и опенсолярис для некоторых других серверов и рабочих станций вполне подойдут. А есои спарков нет - зачем огород городить, возьми линукс и не мучайся.

> и еще, супер файловая система ZFS требует в районе гигабайта памяти для нормальной работы.

Дык оно нормально - все равно в рабочейй время на этом железе сантехники виндовс висту гонять будут - а ей тоже примерно столько и надо.

Что-то я не пойму, а какая к черту разница, где и что раньше появилось?

Интересна статистика по тестам :
Есть такой тест - SPEC CPU2000 - на интеловском железе у сана вообще нет никакого преимущества перед линуксом - независимо от числа процессоров

ты - флеймокачегар

Да никто не круче.. у каждого есть свои преимущества и свои недостатки.. Ну а Linux он просто обошёл Solaris на определённом этапе развития.. SM слишком поздно расшевелилась.. То, что они делают сейчас, надо было делать ещё лет 10 тому назад.. Тогда, возможно, расклад был бы иной..

>Защита стека - built-in stack overflow protection - в солярке это есть , в линуксе нет.

Это прополис что-ли? Это фича компилятора и есть везде, даже в offtopic XPSP2 и 2003. Неисполняемые сегменты даже при отсутствии аппаратных NX-битов тоже есть.

>RBAC в солярке появился еще в 2000 году , и в виде SELinux в редхате - много позже

Линуксовому RSBAC сколько лет?

>, а в линуксе поток - это фактически процесс ...

и какой давности статья?

> и какой давности статья?

годичной , по-моему
оригинал лежит тут :
http://www.softpanorama.org/Articles/Linux_vs_Solaris/comparison_of_internal_...

1. В линуксе сложился олигархический стиль управления.На вершине стоит Линус , и все , что бы он не сказал , да будет исполнено

Качай сырцы и делай все что хочешь, линус за тобой с топором не прийдет. То же с опенсоляркой.

2. Нет преемственности и традиций в разработке ядра :-) Вот , типа , если рассмотреть историю развития ядра начиная с версии 1.0 , то если взять базовый шедулер , то он несколько раз переписывался с нуля

За традициями и родовыми табу к чукотским шаманам.

3. Ядро солярки многопоточное , и потоки внутри единого процесса выполняются внутри единого виртуального пространства , и нету context switch , а в линуксе поток - это фактически процесс ...

И ?

4. Линуксовый сетевой стек ориентирован в основном на bsd-сокеты , и в случае работы со stream у него все плохо

Чето не сильно заметно...

5. Сетевой стек в солярке реализован лучше , в нем можно индивидуально настраивать каждый сетевой поток

Угу! Наши сокеты сокетнее! Файерволы файервольнее и зубы мы чистим колючей проволокой.

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

Cкажем так сделать из солярки десктоп - не больше секса чем собрать LFS.

> Да , и что это за чудо такое - Sun Studio ?

Среда для разработчика. Компиляторы + Vim + Xemacs + Netbeans на выбор.

> но когда понял какие ограничения он налагает, поменял свое мнение в другую сторону.

Каждый день драйвера пишем ?

> и еще, супер файловая система ZFS требует в районе гигабайта памяти для нормальной работы.

А она вроде не для домашних боксов предназначена.

1. аминь

2. just for fun

3. Ну и фих с им. Работает, и ладно.

4. см.п.3

5. см.п.3

Вообще, одно другого стОит. Солярка возможно и круче, но похоже что она рип, к сожалению...

Она не рип, она все более перемещается в сегмент ынтерпрайза, а вот потом уже ей настанет рип.

Ребятам уже реально расти некуда толком, никто за их солярой в очередь не становиться, бо в линуксе можно не хуже а иногда и лучше. В этом их проблема.

>годичной , по-моему

незаметно, там еще вспоминается про 2.4 без NPTL,
и упоминания про то, что в Linux поток, это по сути процесс не нашел,
там говорится, а в Солярис так, и все, наверное до прямой лжи решил не скатываться.

ЗЫ

в статье куча замечаний, типа не пробывал под Linux,
не пробовал на x86, но это наверное так,
и выдранные цитаты из контекста,
типа Мортона: "баги быстрее появляются, чем мы их исправляем",

в общем хвалебная песня соларис, без фактов.

> Защита стека - built-in stack overflow protection - в солярке это есть , в линуксе нет.

А CONFIG_CC_STACKPROTECTOR наверное мне после ударного абсентового марафона приглючился, да, дядя?

> Это предотвращает неавторизованный рутовый доступ к системе

Вечно всяким быдлокодерам жопу приходится вытирать централизованным средством.

Ага ... в солярке чудный огород из GNU и native утилит .. это плюс или минус ?

> >, а в линуксе поток - это фактически процесс ... >и какой давности статья?

а разве сейчас это не так? конечно потоки это легковесные процессы (совместные ресурсы), но все же процессы.

NPTL !!!

потоки поддерживаются ядром

Скачай Соляру с сайта Сан, потрогай руками. Порадуешься.

с 4 штук ps с разным синтаксисом, что например lsusb называется cfgadm (не угадал?), с общего быстродействия, с package management.

зато сантехника умеет hot-swap процессоры :)

линукс тоже не первый год умеет

да?

и каким образом, если это не умеет железо?

ах да, ключ конфига ядра фстудию.

>NPTL !!! >потоки поддерживаются ядром

IMHO потоки (как и полноценные процессы) создаются при помощи syscall'а clone, процессы от потоков отличают флаги, что передаются вызову clone. и причем здесь "NPTL !!!" с таким же успехом можно было написать "LinuxThreads !!!"?

Во первых: http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library#History

NPTL uses a similar approach to LinuxThreads, in that the primary abstraction known by the kernel is still a process, and new threads are created with the clone() system call (called from the NPTL library). However, NPTL requires specialized kernel support to implement (for example) the contended case of synchronisation primitives which might require threads to sleep and be re-awoken. The primitive used for this is known as a mutex.

Во вторых: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl/sysdeps/pthread/create...

смотреть в функции create_thread флаги (и их описание) clone_flags с которыми вызываеться do_clone (а затем __clone)

ps не согласны - ссылки

> 1. В линуксе сложился олигархический стиль управления.На вершине стоит Линус , и все , что бы он не сказал , да будет исполнено

Прочитай Documentation/ManagementStyle и процедуры по принятию кода в ядро OpenSolaris :)

> 2. Нет преемственности и традиций в разработке ядра :-)

Это личное аффтара. Как вообще измеряется "преемственность"?

> Вот , типа , если рассмотреть историю развития ядра начиная с версии 1.0 , то если взять базовый шедулер , то он несколько раз переписывался с нуля

Зато теперь в Линуксе отличный шедулер (а раньше был просто хороший).

> 3. Ядро солярки многопоточное ,

Формально, ядро Линукс многопоточное с версии 2.2

> и потоки внутри единого процесса выполняются внутри единого виртуального пространства ,

То же и в Линуксе

> и нету context switch , а в линуксе поток - это фактически процесс...

context switch бывает разный. При переключении контекстов между нитями в Линукс не происходит самого затратного дейсвтия - обновления контекста MMU с TLB flush, потому что нити в Линуксе - это такие особые процессы :) (но всё это относится к LinuxThreads, а в реальности давно используется NPTL).

> 4. Линуксовый сетевой стек ориентирован в основном на bsd-сокеты , и в случае работы со stream у него все плохо

Это было сознательное решение - что-то вроде "у нас открытый код, и если нужно ввести в ядро новый протокол, так иделайте, а усложнять/тормозить ядро введением STREAMS мы не станем".

> 5. Сетевой стек в солярке реализован лучше , в нем можно индивидуально настраивать каждый сетевой поток

Здесь крыть нечем - только спросить, а нахнада?

P.S. Ненавижу, <censored>, когда термин "thread" переводят как "поток". "thread" - это "нить", ОК?

> <censored>

Сейчас придёт Модератор и объяснит тебе, что ты имел в виду под словом <censored> :P

Ламир!

zless /usr/share/doc/linux-doc-2.6.18/Documentation/cpu-hotplug.txt.gz

хе, в моем 16 этого нет :)

Хм... Да я вижу, автора зовут Николай Безруков :)

В обещм можете с ним запросто пообщаться на руссокм, попутно объясняя, что он быдлокодер, так как пользует жабу и что ОС Emacs рвёт солярку, особенно тем, что там программы компилировать не надо и работают покруче жабовских, так как на лиспе :)

я юзаю вим.

вы промахнулись :)

>3. Ядро солярки многопоточное , и потоки внутри единого процесса >выполняются внутри единого виртуального пространства , и нету >context switch , а в линуксе поток - это фактически процесс ...

"Поток", то бишь нить, не может быть процессом в общепринятом понимании этих терминов, поскольку это совершенно разные вещи. Linux изнутри оперирует понятием task (задание), которое представляет собой единицу диспетчеризации. Между заданиями возможно разделение ресурсов. Определенное разделение ресурсов позволяет выделить целостное POSIX-совместимое представление для концепций "процесса" и его "нитей".

>а разве сейчас это не так? конечно потоки это легковесные процессы (совместные ресурсы), но все же процессы.

Не знаю, что там у кого куда течет, а нити NPTL - это полноценные нити... и к LWP отношения не имеют.

>смотреть в функции create_thread флаги (и их описание) clone_flags с которыми вызываеться do_clone (а затем __clone)

И что это должно доказать по-вашему? Такой в Linux механизм создания нити.