2"-Direct": Но полностью не согласен насчет того что Unix надо продвигать на Desktop'ы.

Какое счастье, что вас об этом никто не спрашивает.

avp

>Если Linux нормально собирать из исходников не может

Какое-то безграмотное заявление :)))
Не Linux, а GCC - разница видна ???
GCC - это все xxxBSDx и много чего другого, не только Linux.
Тем более, что на спарк проблема была с ранней версией линкера
который в binutils находится. Теперь эта проблема пофиксена.
(GCC с соляркиным ld - работал вполне нормально. )
Кстати я собирал 64 bit приложения GCC-ом на True64, Alpha и Itanium
- работает вполне нормалоно. Как нибудь соберусь и погонаю его
на sparc64

2Direct: Я, в общем, не хотел влазить в этот флейм, но гхм, фраза "доказательство: посмотрите какие крупные ресурсы стоят на FreeBSD" меня добила. В курсе, что Altavista c марта стоит на линуксе? (источник - неткрафт, специально в апрельском отчете подчеркнули, что-де, переехали, и еще пара серверов компаковских серверов куда-то откочевала). Вообще, я согласен: фряшное ядро написано (в смысле coding style) аккуратнее линуксового. Но то, что фряшка плетется в хвосте у этого самого линукса (и, прежде всего, в маркетинговом плане, и, гхм, местами в технологическом) - абсолютно точно. Взять хоть те новомодные QoS, PCMCIA CardBus и еще всякие фишки (да, знаю, NEWCARD уже в стабильном, 4.3 ядре. Наконец-то. После того, как соответствующий код в линухе года два как рабочий). Алексей Морозов. P.S. А линки фряшка теряет точно также, как и линукс, чего бы там дядя Вова не вещал в ру.линукс :-). Сам давеча видел. С одной стороны уже CLOSE/WAIT, с другой все как будто так и надо.

2ZhekaSmith: А никак не обходят. Факт, что некоторые драйвера (вэйвлановские, в частности) - просто порт линуксового - зуб даю, ползал по ним на брюхе (более того, источник указан :-)). Да, разумеется, "нэйтивные" написаны сильно прямее и аккуратнее :-) Алексей Морозов.

"То что 64 бита дают автоматом радость это наивный, и я бы даже сказал, детский предрассудок."

Это как раз не предрассудок - а факт...Просто надо было посмотреть на 64-х
битные платформы и серьезные приложения под них.

---

"GCC с соляркиным ld - работал вполне нормально."
"Какое-то безграмотное заявление :)))
Не Linux, а GCC - разница видна ???"

Вот именно: если GCC не подправленный и не заточенный под конкретную
платформу, то и бинарники будут кривыми. И именно в Linux'е во всех портах
так и просходит (из тех которые встречал: Alpha и Sparc).

"Кстати я собирал 64 bit приложения GCC-ом на True64, Alpha и Itanium
- работает вполне нормалоно."

А что True64 это теперь такая платформа или Alpha и Itanium теперь ОС?

---

"В курсе, что Altavista c марта стоит на линуксе?"

А Altavista это что половина интернета или 1/3? Я говорю вообще...
Я неспорю что Linux тоже может быть вполне хорошим для сервера, но при
этом я утверждаю что на SMP (крупных) и архитектуре не x86 - он ещё
слабоват (по сравнения с тем же FreeBSD).

"Но то, что фряшка плетется в хвосте у этого самого
линукса (и, прежде всего, в маркетинговом плане, и, гхм, местами в технологическом) - абсолютно
точно. Взять хоть те новомодные QoS, PCMCIA CardBus и еще всякие фишки (да, знаю, NEWCARD
уже в стабильном, 4.3 ядре. Наконец-то. После того, как соответствующий код в линухе года два как
рабочий)."

Сейчас уже не ОС под железо подбирают, а железо под ОС. Зачем в FreeBSD
например PCMCIA?

P.S.: Идеальных ОС не бывает...

----

-Direct

P.S.: Я вообще обычно только читаю обсуждения на linux.org.ru, но подобного рода высказывания
меня просто напросто раздражают. Хоть кто нибудь из тех кто по этой теме постил сообщения
видел нормальные сервера (а не на базе Pentium II) и другие платформы кроме x86?

Дорогой Direct:

Вы написали: "какие крупные сервера стоят на ..." Я Вам привел пример "крупного сайта". За свои слова обычно отвечать надо.

"Зачем PCMCIA во FreeBSD?" Cходите на www.freebsd.org, подпишитесь там на freebsd-mobile и задайте этот вопрос в листе. А можно и прямо Варнеру Лошу (Warner Losh), интересно, что он Вам на это ответит :-).

"Зачем QoS 'нармальной OS' (орфография сохранена :-))?" Ну, тут не знаю, и вправду, видимо, не надо.

Я видел "нормальные сервера". На базе PentiumIII, например :-)) (сейчас сам вот на PIII/800 сижу, но только это не сервер, а WS :-))) Такой сервер - это "нормальный сервер"? :-). А если Вам охота странного, то вон, в трехстах метрах от меня. в соседнем корпусе нашей конторы, сколько-то ультр стоит и O2 где-то завалялся. Это "нормальные сервера"? А почему на них не FreeBSD, а какой-то "СанОС x.x" и, не к ночи будет помянут, Ирикс? :-)

В общем, некоторые уязвленные забытым первородством господа BSDшники в запале готовы сказать то, от чего потом сидишь и похохатывешь.

Я думаю, пора заканчивать с этим флеймом :-)

АМ

To: Irsi

> "На сегодняшний день SMP hardware решения чрезвычайно дороги и я думаю, они останутся таковыми ещё
> достаточно долго."
> Угу... безумно дороги... 2х процессорная системапроцентов этак на 10-20% дороже однопроцессорной с
> аналогичном процом. :) А прирост производительности - не менее 70%... Под нормальной ОС, с нормальным
> софтом разумеется...

Ну это смотря как считать. 20% - только дополнительные затраты на второй CPU. Если прогрес для одного
процессора остановится, то и для двух тоже, а значит потребуется увеличить их число. Просто так сделать
это будет очень не просто и разумеется не дёшево. Иначи зачем появились кластеры?

Просто представь себе хотя бы два CPU работающие вместе. В какой то момент (а на самом деле почти постоянно)
они одновременно занимают шину, которая и с одним то бежит как черепаха... ну ты понял.

> "Производительность же однопроцессорных систем всё ещё далека от их предела и этот факт также будет
> иметь место ещё довольно долго." 
> Больше чем на порядок производительность современных процов врятли удасться увеличить - размер p-n
> перехода нельзя уменьшать до бесконечности...

На порядок - это в 10 раз, то есть на 900%. Неужели мало или ты по жизни binary пользуешся? :))
Размер p-n перехода - не единственный показатель. Можно дальше сокращать количество тактов на чтение
и запись памяти, на выполнение инструкции, выполнять больше простых инструкций за один такт.

> А закон Мура пока никто не отменял... так что в течении 5-10
> лет в потолок упремся. Кто думает что 10 лет это очень долго, тот простите заблуждается, к тому же
> экономические соображения могут весьма основательно сократить этот срок.

В потолок, в общем то, давно упёрлись, но мы говорим не о последних достижениях науки и техники.

> "Сегодня наиболее узким местом остаётся не столько обработка, сколько передача данных."
> В принципе ты прав... Но все не так просто... Впрочем боюсь это нас заведет в такие дебри...:)

Почему же дебри? Всё упирается в деньги и только в деньги.
-----

Вот ещё рассуждения одного не глупого человека, в том числе и по теме:
http://lib.ru/UNIXOID/bogatsys.txt

2Direct: "Это как раз не предрассудок - а факт...Просто надо было посмотреть на 64-х битные платформы и серьезные приложения под них. "

Я их пишу (64-битные приложения). Чтобы заставить 64-битное приложение работать быстрее чем 32-битные нужны серьезные усилия. Если их не прилагать, то лучше использовать 32-бита.

anonymous:

"Просто представь себе хотя бы два CPU работающие вместе. В какой то момент (а на самом деле почти постоянно) они одновременно занимают шину, которая и с одним то бежит как черепаха... ну ты понял."

Правильно. Поэтому нужно чтобы кэш хотя бы второго уровня был один на оба процессора. А сами процессоры желательно на одном кристале, тогда CPU lock будет занимать копейки - с десяток тактов.

2hoopoe

Да помню, помню Я. Sequent были машины, хорошие. В ВИНИТИ на них ДНС до сих пор держат

>Alpha и Itanium теперь ОС? Sorry, описался на Alpha и Itanium стоял Linux

>Alpha и Itanium теперь ОС?
Sorry, описался
на Alpha и Itanium стоял Linux

ребяты вы не правы насчет 64 битного доступа к памяти на 64 битных же платформах. На 64 битных платформах шина данных 64 битная, так что за такт читается как минимум 64 бита. И ни какого ухудшения по сравнению с 32 битным доступом быть не может, если оно есть то это косяк компиллера и только.

2chuchelo: "ребяты вы не правы насчет 64 битного доступа к памяти на 64 битных же платформах. На 64 битных платформах шина данных 64 битная, так что за такт читается как минимум 64 бита."

а кэши на что? имеется ввиду упорядоченный доступ. и если мне кто скажет что нет разницы прокачать n int'ов или n longlongint'ов то я буду долго смеятся...

To: ZhekaSmith

> "Просто представь себе хотя бы два CPU работающие вместе. В какой то момент (а на самом деле почти
> постоянно) они одновременно занимают шину, которая и с одним то бежит как черепаха... ну ты понял." 
>
> Правильно. Поэтому нужно чтобы кэш хотя бы второго уровня был один на оба процессора. А сами
> процессоры желательно на одном кристале, тогда CPU lock будет занимать копейки - с десяток тактов.

Кеш не просто должен быть общим, его должно быть больше. Это дорого, даже для третьего и второго
уровня, не говоря уже о первом. Много процессоров на одном кристалле тоже не сделаеш, туда и один то
с трудом влазит.

Ой только не надо гнать, что один с трудом влазит на кристал.Ты не смотрел какой проц ибм забабахала?По моему прошлый год.Как минимум 2 на чипе (или уже 4).И все забибись. А по поводу многопроцессорности:)) кхм у меня книжка валяется - описание програмирования на асемблере под старые apple, так там четыре каретки под процы стояли, хошь - воткни еще один.А было это тогда, когда твой x86 наверно еще "на горшке сидел", или даже в него проваливался.

> я утверждаю что на SMP (крупных) и архитектуре не x86 - он ещё > слабоват (по сравнения с тем же FreeBSD).

Мда, FreeBSD с ее двумя архитектурами (2-я, Alpha, так и не вошла пока в стабильное состояние) конечно в на порядок лучше поддерживает не x86 архитектуры. И это учитывая, что порт FreeBSD на Alpha появился через три года после после порта туда Linux. А про SMP во фре с ее global kernel lock как в Linux 2.0 лучше вобще молчать.

Лучше меньше, но лучше, как говорила мой преподаватель математики :)
Подождем пятерки, там обещали SMP и threads весьма серьезно переделать.

2 Havoc (*) (2001-04-27 10:55:49.0)
Дык, ядро 2.5 тоже не за горами и там, тоже, многое вкусное обещают.
Фряху, погубила элитарность и лицензируемость (согласен с irsi),
думаешь Oracle+Imb+Intel отчего linux так обкатывают?

2BlackRabbit 2.5, как ты наверно знаешь будет девелоперное. А стабильного 2.6 ждать еще не мало. Да и hardware под хорошие смп должно быть с аппаратом, заточенным под мультипроцессорность (саны к примеру). Давно еще была сделана машина такая - Sequent (модель не помню). Так в ней было четыре 386 проца. Вот эта машина хорошо с ними работала и дело явно было не только в операционке (насколько помню она не совместима с осами для обычных писюков). На ней до сих пор в ВИНИТИ named и фтп.

2BlackRabit: хммм... имхо фраху элитарность и лицензия какраз спасли, а популизм линукс какраз погубил...:)
Вот сейчас флейм поднимется...;)

А я думаю, что SMP кроме дополнительного геморроя разработчикам и пользователям
в наше время ничего не несет. Основное его назначение - удовлетворять любителей
прыгнуть выше своей головы. У меня на сервере 1.3 Ghz Athlon, на десктопе - 1Ghz.
И где их загрузка 100%? Только на компилляции (очень кратковременно) и
на mp3-кодировании. Все. Во всех остальных случаях тормозом является дисковая
система. Я понимаю еще когда были p166, ppro. Что сейчас можно делать
на SMP с гигагерцовыми камнями? Вы их хоть 50% загрузить сможете в реальных
условиях?

2anonymous:
>И где их загрузка 100%?
Хочешь рецепт? Машина 1MGz x2, 512MB, дисковая система RAID-0 из трех
SCSI 18GB, на всем этом - Oracle 8.0.5 - загрузка - до 70%
>Во всех остальных случаях тормозом является дисковая система
Правильно :), но и это преодолимо

> Что сейчас можно делать на SMP с гигагерцовыми камнями? Вы их хоть 50% загрузить сможете в реальных условиях?

Ато. Типичный веб-сервер например с PHP в легкую загрузит подобное железо. Мне например на прошлой работе нехватило 2xPIII-1Ghz. Памяти при этом было достаточно (1Gb), SCSI. Нехватало именно процессора - в итоге пришось делать кластер из двух таких машин.