Сдается мне, что сетевые "способности" зависят от ядра, а не от дистрибутива (RedHat не в счет). No holy wars, please!

Это я к тому, что в подобных заметках обычно упор делается на название дистрибутива, хотя на самом деле использовать можно фактически любой, другое дело, если SuSE имеет управляемость требуемую для таких проектов (например централизованное обновление специализированного ПО).

Сусе имеет для этого другое - широкую популярность в Западной Европе, ею пользуются и в учебно-научных заведених и просто как корпоративный стандарт - и под десктоп и под SAP/Oracl... Так что пусть в России и Америке обсуждают, дорос ли Линукс для десктопа. А в Европе иногда специально пишит, что Linux - это не только SuSE.

А вот прессрелизу уже месяц...

А на курске линукса не было? :)
Бред блин какой-то орать про каждую инсталляцию.

На Курске был Windows :(

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

Чем переводили?

Интересно, какой программой переводили эту новость?

Неужели кому-то в лом было перевести самому, или, хотя бы, подправить несколько строк? Уж лучше бы на английском запостили. :-(

SuSE 7.3 Don't use!

А я любил SuSE от версий 4.x (когда с ним познакомился) и до 7.3 - в котором глюкавый кернел и отсуттсвуют или не собираются исходники. :(((

Загубили менеджерюги Суську...

Да что вы Сусе-круто, Сусе-говно. Факт-то просто в другом, несмотря на толкание имени, видно что на Линухе можно реализовать не один грамотный проект. Вот и все. Порадовались бы, что Линух взяли. А не ДОС :) Как обычно бывает в России :(

Just.

>> Главные причины для этого выбора были его стабильность, >> пригодность превосходного программного обеспечения, и прежде >> всего, его сетевые способности.

Был один-единственный фактор. То что денег не надо было платить. :0)

Блюзмен , вот как раз за такой дистр выложили много-много денег. Ты цену на него узнай.

2 anonymous (*) (2001-12-26 19:23:15.0): А вообще да. Там дуал-бут был на всех 5 машинах. Windows 2000 управляла, Linux считал. Так что похоже, что кроме цены были еще и другие резоны. Если верить SuSE то этот IgH Linux использует весьма широко у себя.

Шоб Ты здох такой умный :)))

Ну, вы, блин, даете.

конечно, новость эта не сильно свежая -- этот пресс-релиз вышел довольно-таки давно.

По поводу того что ядра у всех одинаковые -- эта чистая неправда, сейчас каждый крупный вендор свои патчи внедряет. Например -- СуСЕвое ядро -- это vanilla+aa со своими фирменными добавками (драйвера, подстройки параметров, еще чьи-нибудь авторские патчи, прочее)

лично я с версией 7.3 никаких проблем не имел -- прекрасный дистр и все в нем собиралось.

А по поводу стоимости SuSE -- то он как раз стоит подешевле конкурентов. (RH или MDK) -- хотя вы его и бесплатно скачать можете с ftp.

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

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

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

Огр и блюзмен как всегда:
>о Виндовс использовался на критическиз работах (контролировал
>механизмы)
The software that controlled the mechanism on the deck of the salvage vessel is written in Delphi and runs under Windows 2000.

критичный софт на дельфи :))))))))))))))))))
электронными ключами управлять :)))))))
а мат. моделирование процесса и все такое - это ерунда не требующая ни надежности ни производительности :))))))))))))))))))))))))
я скоро лопну...

PS
Огр и Блюзмен это , имхо, не придурки - это алиасы дергачевой и еще одного менеджера-полудурка (забыл фамилию)

А какая тебе надежность при мат. моделировании процесса нужна ? Это ведь не релтайм софт. А управление механизмами - релтайм. Так, что надежность, требуемая моделированием меньше надежности, требуемой управлением. А насчет Delphi - эта публика легко тебе заявит, что Яндекс написан на html'е. Ну а клиент, написанный на Delphi, наверняка будет постабильней, чем клиент, писанный в Линуксе на любом из тулкитов.

Oracle на линухе? В отдел фантастики. Он на этой платформе не работает, что охвициально признается кстати.

Тады у меня преднововгодние глюки - когда смотрю на Oracle 8.1.7 под Suse 7.3 на raw partition. > охвициально признается кстати Я просто пиздинею с этих придурков-анонимусов. Для интереса зашел бы на http://www.suse.com или http://www.oracle.com

Про оракле под линухом класно придумано.

"Огр и Блюзмен это , имхо, не придурки - это алиасы дергачевой и еще одного менеджера-полудурка (забыл фамилию)"

Кстати о придурках. Фамилия регионального представителя Microsoft на Урале - Аникеенко. Так его никто иначе как "эникейщик" и не зовет. Sorry за offtopic

Дарагой! Ты сам-то понял, что написал? 

>А какая тебе надежность при мат. моделировании процесса нужна ? Это 
>ведь не релтайм софт. А управление механизмами - релтайм. Так, что 
>надежность, требуемая моделированием меньше надежности, требуемой
>управлением. А насчет Delphi - эта публика легко тебе заявит, что
>Яндекс написан на html'е. Ну а клиент, написанный на Delphi,
>наверняка будет постабильней, чем клиент, писанный в Линуксе на 
>любом из тулкитов.

Неужто надежность виндов такова, что реалтайм без них никак? И почему
это дурни-капиталисты тратили жуткие деньги на покупку к примеру QNX?
А фраза "клиент, писанный в Линуксе" - просто шедевр работы
неизвестного мастера :) А про дельфи, я думаю, народ еще добавит пару
ласковых...

2anonymous (*) (2001-12-27 09:30:42.0): " А про дельфи, я думаю, народ еще добавит пару ласковых..."
Тем не менее факт остается фактом, реальными, читай - ответственными, работами управляла виндовс. И как видно весьма успешно.

> Неужто надежность виндов такова, что реалтайм без них никак?
Где ты это заметил в моем постинге ? Я сказал, что для релтайма надежности требуется больше. И что, кстати, "шедеврального" во фразе "клиент, писанный в линуксе на любом из тулкитов" ? Ответь, "дарагой". Конкретного ответа я от тебя скорее всего и не дождусь, потому, что ты гумманитарий, нет - хуже даже - пиздабол.

Насчет того, что Линукс СуСЕ и Оракл жить вместе не могут - долго смеялся :-))) А насчет Выни и управления механизмами под ею же, то кое-кто уже отличился в треде под названием "Очередные нападки мелкософт на линукс". Почитайте не пожалеете!

А мне кажется, что сценарий был такой. Была некоторая фирма Мамут, у которой были Windows 2000 и Delphi куплены. Скорее всего стенд с тросами принадлежат Мамуту и они сделали программку на Delphi силами своих программистов, которая ими управляет (зачем покупать еще что-то, когда и Делфи сойдет). Потом появилась необходимость софт для моделирования. Разумеется, Мамут - организация подъемная, а не математики, им такие задачи решать не приходилось. Вот они нанимают на деньги наших налогоплатильщиков эту фирму IgH, которая отродясь кроме SuSe ничего не видела (и правильно делали, что не засоряли себе голову). Мало того, у них все библиотеки рассчетные были написаны под этой платформой, давно обкатаны. Приходят они на Мамут посмотреть на механизм, которым управлять. А под чем он у вас работает? Они: "Под Windows2000, у нас другого ПО нет, нам и этого достаточно". "Хорошо!", - сказали IgH, - "Тогда мы для экономии времени соединим все это хозяйство как-нить: нашу числодробилку на SuSe и вашу Windows систему. Не будем же мы писать занго драйвера для вашего стенда, так как это экономически не выгодно!". Вот и получилась вся эта система такой, как описывается в прессрелизе.

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

Не знаю, как сейчас, а в мои времена серьезные задачи считались сутками. И бывало очень обидно, прождав несколько дней, начинать сначала.

>> Не знаю, как сейчас, а в мои времена серьезные задачи считались сутками. И бывало очень обидно, прождав несколько дней, начинать сначала.

Сейчас процессоры несколько быстрее, чем в твои времена ;)

>Сейчас процессоры несколько быстрее, чем в твои времена ;) ага, и задачки сейчас другие. чем тогда...

>Сейчас процессоры несколько быстрее, чем в твои времена ;)

ага, и задачки сейчас другие. чем тогда...

>Не знаю, как сейчас, а в мои времена серьезные задачи считались
>сутками. И бывало очень обидно, прождав несколько дней, начинать
>сначала.
Не спорю. Поэтому и написал, что надежность, требуемая моделированием меньше (а не равна нулю), чем надежность, требуемая релтаймом.

Блин, ну где вы нашли рилтайм в дельфи?
нет.
Блин, где вы нашли рилтайм в win*?
Огр, понятно, лепит все что можно, но остальные то куда смотрят?
Единственный прикол дельфи -скорость втыкания кнопок в проект. очень удобная и действительно rapid development system.
ни надежности ни рилтайма (хотя бы секундного или минутного :) в дельфи нет и никогда не было.
а вот по таймеру на определенный порт кинуть определенное число где еденички - включить механизм а нолики - выключить - почему нет?
а если зависнет, то можно просто рестартовать с того же места. я думаю заморозить состояние механизмов можно было одним тумблером.
все тоже самое в питоне было бы написано еще быстрее но это уже выбор программиста. что ему сподручней.
а теперь от том, как сделать временную диаграмму для этой "рилтаймовой" проги. что, тоже на дельфи? там просчета сколько... и памятью управлять ой как надо. Дельфи сдохнет сразу, за ним и виндоза в небытие уйдет. не вычислительная это платформа.

> лично я с версией 7.3 никаких проблем не имел -- прекрасный дистр и все в нем собиралось.

1) reiserfs там глючит (segfault-ы при обращениях к файлам).

2) Попробуй найти исходники alsa.spm - нарушение GPL

3) Попробуй собрать исходники исходников ядра (kernel.spm) - второе нарушение GPL (там одни только патчи к ядру, как они пакет собрали - я без понятия).

4) На кой там lnx_source-2.4.9 - The rest of kernel sources?!!! И где тогда первая половина (lnx_headers-2.4.9) - в SuSE-7.2?!

Если у тебя нет проблем с SuSE - радуйся и молись.

Два комментария.

=================
Как это работало:
=================
1. Мы знаем текущее состояние лодки - надо поднять ее
на 30 сантиметров, при этом добавить диферент корму на 5 см и
выронять разворот по продольной оси на 2 градуса.
2. Delphi - рассчитываем конечное состояние лебедок и предполагаемую динамику вращения и вместе с данными о внешней обстановке (сила и
направления ветра, волнение, положение судна, данные о ходовой части и
т.п.) передаем на linux-овый симулятор.
3. Linux-овый симулятор - тужится и говорит - все нормально, но после
первой минуты работы надо поменять динамику на 5-й лебедке таким-то образом ибо далее с вероятностью N% это все может ...
4. Delphi - OK . Меняем согласно рекомендаций. И уточнив данные персчитываем.
5. Linux - теперь - OK.
6. Delphi - начинаем подъем. Отдаем команды лебедкам. Через 3 минуты
уточняем данные и передаем их симулятору.
7. Linux - пересчитываем отсюда и далее согласно уточненным данным и
выдаем новые рекомендации.
И так далее до окончания процесса.

В такой ситуации спорить кто главный, а кто нет - бессмысленно.
Delphi управляет механизмами, Linux просчитывает вперед, что бы не было
проблем при подъеме.
Более того, не открою секрет, если скажу что непосредственное
управление лебедками производили какие-нибудь встроенные контроллеры
или нечто аналогичное.

Отсюда выводы:
--------------
"Прекрасные сетевые свойства Linux" были необходимы, чтобы
распараллеливать задачу эмуляции.
Windows для задач эмуляции использовать было проблематично, ибо
большинство такого софта написано под Unix, и искать себе проблем с
портированием на Windows - удел людей недалеких.
Создавать пользовательские интерфейсы на Linux - задача бессмысленная,
ибо помимо софта управления лебедками на управляющих компьютерах нужна еще масса других приложений, которых на Linux нет (например, GPS,
получение метеопрогнозов, получение данных от всевозможных датчиков и
т.д.).
Короче, хочу только похлопать разработчикам проекта за умело выбранную
стратегию.

==============
ORACLE & Linux
==============
Работает в двух банках.
1. Oracle 8 (точную версию на память не помню), месяцев 6-8 в
продуктиве, ядро 2.2.17.
2. Кластер(!) на Oracle 8.1.7, 3 месяца в продуктиве, ядро 2.2.19, массив FC.

Проблем не было, за исключением желания оторвать что-нибудь Oracle за
"прекрасную" готовность к тиражированию систем (ощущение, что они сами не пробовали ставить кластер из того, что раздают).

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

>Создавать пользовательские интерфейсы на Linux - задача бессмысленная,
>ибо помимо софта управления лебедками на управляющих компьютерах нужна
>еще масса других приложений, которых на Linux нет (например, GPS,
>получение метеопрогнозов, получение данных от всевозможных датчиков и
>т.д.).

не буду спорить ибо не компетентен, но про системы сбора данных или GPS под линуксом я слышал неоднократно. тем более сбор метеопрогнозов :) имхо это вообще задачка для питона. (если я врубился в суть вопроса)

>3. Linux-овый симулятор -
>4. Delphi - OK .
>5. Linux - теперь - OK.
>6. Delphi - начинаем подъем.
>7. Linux - пересчитываем отсюда

из статьи этого не следует. вроде dual-boot это что то попеременно загружаемое. столько гемора с перезагрузками трудно себе предствавить. или они там wmware пустили :)?

>Короче, хочу только похлопать разработчикам проекта
присоединяюсь. лодку то подняли :)
при этом использовали свободные продукты, что вобщем, является еще одним признанием преспективности этой платформы (lintel linamd linalpha ...)

Последнее, это уже препарированная мысль для менагеров (только москвичей - я в пока только Москве и Подмосковье линукс внедряю. Если есть вопросы или сразу заказы, обсудим)

не в тему конечно но раз затронули Oracle и кластер вопрос кто нить знает решение как можно 2 Sybase заставить работать с одной базой ? Под Linux соответсвенно

2Bluzaman: Шоб ты хорошо так жил такой умный :)

Никак, ибо это должна уметь делать сама база (например, как это делает Oracle). Т.е. надо уметь разрешать конфликты при одновременном доступе к fs, записям базы и еще много разных вкусностей, которые Sybase делать не умеет. Конфликты на уровне fs должна уметь разрешать операционка, а я не имею сведений, что Linux это умеет. Поэтому (потому, что Linux не умеет, а не потому, что я не знаю) Oracle реализовала свой кластер под Linux на raw-devices, ибо тогда за разрешение конфликтов доступа к дискам отвечает СУБД, а не операционка.

>потому, что Linux не умеет, а не потому, что я не знаю
потому, что не знаешь, а вообще то умеет.
oracle нормально живет и не на raw devices. и не только он.

2anonymous (*) (2001-12-28 19:47:54.0) Сударь Ваши наезды неуместны, ибо речь идет не о том, может ли Oracle под Linux жить поверх fs, а возможности кластерной обработки (т.е. об управлении одновременным доступом к одной базе от нескольких СУБД и разрешении конфликтов, есс-но, в т.ч. и на уровне mass storage devices).

Если у Вас есть сведения о кластеризации Linux на уровне fs, попрошу их в студию - буду крайне признателен.

Сорри, не мог не вмешаться. Так может рассуждать только дилетант, который никогда не занимался решением реальных задач (тех, которые можно решить только численно). Элементарно, задача, например, дискретного программирования может решаться ОЧЕНЬ долго, не смотря на всю скорострельность современных процессоров.

Там не зря смайлик стоИт. Шутка это.

PS: В этом я действительно дилетант ;)

Объясняю для всех. Статья на сервере Сусе жутко старая и не слишком умная.
Что касается Вынь 2000, я специально читал - на выне у них был сделан верхний уровень - общее управление, интерфейс с оператором и тп. Как были сделаны системы управления приводами (те реальными двигателями, замкнутый контур управления, съем информации о датчиков) я не знаю - врать не буду. Но точно не на вынь.
Кстати, именно для верхнего уровня, где время реакции идет на сотни миллисекунд, Вынь 2000 вполне работоспособна. На нижнем уровне (время реакции менее 500 мкс) ее небыло - иначеб Курск не подняли. Так что весь 3.14здеж на эту тему ломаного гроша не стоит...

Ну и где ты это читал? Или что скорее всего решил не умело защитить линукс.

Vy sravnite cebu gcc + gnu libs vs. Borland C++ + libs