>BSD то можно брать нахаляву

FreeBSD делается одним небольшим коллективом достаточно консервативно, согласованно. То же можно сказать и про OpenBSD и NetBSD. Когда появляюся ядра x.yy.zz-rc4 и x.yy.zz.0.13mdk то вспоминаеся "однажды лебедь, рак да щука..."

А что линух уже умеет делиться на domains? Хотя 9 соляра оставила тоскливые впечатления своей глюкавостью.

Мне пожалуйста многопоточные (ну в плане SMP) tcp стек и VFS в *BSD, а? PAE в *BSD раньше всех появилось несомненно, эт все знают. Стабильность и скорость работы FreeBSD-5 потрясает воображение ;)

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

Ну-ка выдай сюда где и на каких "недетских задачах" уделываются "юнихи с ораклом"?

Хотя, мог бы и заметить, что я не говорил, будто нельзя взгромоздить или соорудить на виндовой платформе что-то монстровое и что это будет ненадёжным или неудобным в юзанье. Речь о том, что полный жизненный цикл (девелопмент, разработка, сопровождение, модернизация) _кастомереского_бизнес_софта_ любого масштаба на MS платформе выливается в заметно более ЗАТРАТНЫЙ ПРОЦЕСС (время, деньги, гемморой неожиданный, подножки с багами и новыми 'улучшенными' версиями, необходимость содержания не только специалистов но и аникейщиков - список вкратце), чем аналогичное юниксовое решение.

Чаще всего в MS-авантюру вписываются вслепую - потому-что очень просто и дешево её начать, а потом уже почти невозможно бросить. Те же, кому это удается, испытывают сильное облегчение, в том числе и финансовое. До недавнего времени (3-5 лет назад) было тяжело убедить людей не делать глупостей и идти по юникс-вей, так как стартовая цена была многим непонятна или непосильна, но теперь это не так - во многом благодаря прогрессу и известности Linux.

Причина затратности Виндов (кроме маркетинговых исканий Б.Гейтса, направленных на максимизации дохода и удержание рынка) - в родовой травме самой системы и ее базовых приложений - она продвигалась и развивалась для облегчения РУЧНОГО труда - вот вам велик с моторчиком, вот мотопила, вот мотокультиватор - но ехать, пилить, копать всё равно должен оператор. И оно по сей день не куда не делось.

Это выводы на основании личного опыта, наблюдений и размышлений. Вполне возможно, что ошибочные. Аргументированные возражения приветствуются.

>Что сказали в Sun "Используйте Solaris и не имейте проблем."

Вас послали (а зачем клиента терять?) и вы утёрлись, потому что не было у вас линуха с нормальной явой и поддержкой всего этого добра вместе. Поигрались вы с ним нахалявку, а потом бросили...

Но причем тут "плохие треды", может дело не в них? Как разобрались-то в причинах?

>>>В пингвиниксе (не юниксе) вылететь за границы стека - как нечего делать!

Эээ, просвятите пожалуйста - как от вылета за стек (это в смысле исчерпания свободного места там или ещё как бывает?) можно защититься программно? Или оно железом поддержано должно быть?

green: Стабильность и скорость работы FreeBSD-5 потрясает воображение ;)

Рад за тебя! А у меня вот просто работает. И, надо сказать, производит весьма приятное впечатление. Особенно 5.1

> Уверен"! Верить можно только в Господа Бога. Нету "еще и free", не-ту!
> Я понятным языком выразился? Кроме J2EE реализаций.
> IBM и Oracle как запали, так и отпадут, когда будут сыпаться Java
> сервера приложений.

Будьте любезны на полтона ниже. Отлично. Считаем что free нет,
( будем считать, что нет free CORBA + Transaction service типа
TAO, OMNI, и еще кучи )
что это меняет ? Не free то веть есть. Или мало и еще носом ткнуть?

> IBM и Oracle как запали
Они еще запали на java - ану как отпадут в пользу .net, которую
они уже сейчас активно потдерживают ?

> Только трэды в Solaris на порядок правильней сделаны, чем в
> пингвиниксе, на которого

Человек, который знает о чем говорит, обычно обосновывает свои
слова.
Если Вы имеете ввиду что m:n scheduling policy и scheduler activation
в Solaris это огромное преимущество ( на порядок! о как!!! и не стыдно
брехать то ? ), то позвольте Вас огорчить - начиная с 9 Соляры потоки
там работают ТОЧНО ТАК ЖЕ КАК И В Linux (1:1).

Interview with Solaris Kernel Engineer Andy Tucker at
http://www.osnews.com/story.php?news_id=3830

An example is the two-level thread scheduling model, where thread
scheduling happens both at user level and in the kernel. Although this
approach had some theoretical advantages in terms of thread creation
and context switch time, it turned out to be enormously complicated,
particularly when dealing with traditional Unix process semantics like
signals. In Solaris 8, we made an "alternate" version of the threads
library available that relied solely on kernel-based scheduling;

***
it turned out to be not only much simpler and easier to maintain, but
also faster in almost every case. It particularly sped up Java code,
***

which is obviously important to us. In Solaris 9 (and later) we
switched over to the single-level library as the only one available.


> В пингвиниксе (не юниксе) вылететь за границы стека - как нечего
> делать!

Это надо послать Задорнову - он ( я слышал ) такие перлы собирает !


> 1. А что, это шит кому-то нужен?

На вскидку: technet.oracle.com, www-106.ibm.com/developerworks/,
java.sun.com.
На мой взгляд идея неплохая ...

> 5. Если с C++ всё прекрасно, то зачем .NET, основной упор в котором
> как раз на лёгкости деланья сервисов и был сделан?

С++ - язык программирования .net - технология и.е. набор стандартов
протоколов, интерфейсов и т.п. - несравнимые вещи.

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

В Ada есть перегрузка операторов. Или Вы считаете что в этом и
кроется причина падения ракет, самолетов, взрывов атомных реакторов
и т.п. ?



Captain Nemo.

>>>На мой взгляд идея неплохая...

WEB services - идея плохая, хотя уже и непобедимая. Содержательного в ней исключительно одно-единственное ПРАКТИЧЕСКОЕ соображение - раз все сидят за файрволами-проксями, которые выпускают наружу часто только http req/resp, то сделаем так, чтобы поверх этого самого "hypertext transfer protocol" можно было обмениваться чем угодно - мессагами, RPCями, p2p, объектами... Технически это дурь всё того же - htmlного - замеса. Один уродец родил другого...

>>>С++ - язык программирования .net - технология и.е. набор стандартов протоколов, интерфейсов и т.п. - несравнимые вещи.

Yo! Но то, как замечательно на C++ пишутся сервисы и что не надо никаких [java|net|foo]framework (aka набор стандартов протоколов, интерфейсов) вы сами и написали. Получается, что про C++ было не в тему и вами теперь отозвано.

>>>В Ada есть перегрузка операторов. Или Вы считаете что в этом и кроется причина падения ракет, самолетов, взрывов атомных реакторов и т.п. ?

С чего вы это взяли? Я заметил только КОМУ эта возможность кажется привлекательной и жуть как необходимой, когда сравнивают java и C#. Сравнивать же Ada и Java в контексте обсуждения и в голову не приходит - так как речь идет не о языковых конструкциях, а о технологиях, как вы сами прекрасно понимаете.

А че,Линух уже не юникс? А кто тогда? дос? CP-M80? Ученые,блин...

Linux - конечно не юникс. Linux - это такая реализация posix, и то кривая.

Что же тогда юникс? Только не пример, а определение..

UNIX - это такая торговая марка (вариант - стандарт). Если ты хочешь зваться юниксом - ты башляешь денег The Open Group, они тебя сертифицируют и при успехе - дают тебе право называться юниксом.

Если ты им не башляешь - они ставят тебя на бабки (вот как Apple с Mac OS X)

Fuck UNIX. fuck Solaris, fuck NT/200o/XP! Linux forever!

2green

Коллега, в русском издании книги Митчелла, Оулдема и Самьюэла (бывших соавторов GCC) на странице 92 сказано: "Потоковые функции, соответствующие стандарту POSIX, реализованы в Linux не так, как в большинстве других версий UNIX..." Позвольте обратить ваше внимание на выссказывание хороших людей.

Скажу честно, мои скромные попытки Java программирования не выявили падения программ в среде Linux, мои несложные программы работали в Linux весьма корректно. Тем не менее, я лично наблюдал, как промышленный программный комплекс, написанный большой группой программистов, специализирующихся исключительно на создании банковского софта, крашился при миграции из Solaris 8 в Linux. При этом проверялись различные дистрибутивы Linux и различные JVM (Blackdown, Sun, IBM - то есть "тенденция, однака..."). До этого я считал данную проблему слухами. При миграции данного приложения в AIX и HP/UP проблем не возникало.

PS. Где все-таки линукс-хакеры нашли TLI в BSD? Уверен, что не в книге господина Робачевского.

PS2. Курица не птица, пингвин не Юникс (и не птица тоже :)))

>Эээ, просвятите пожалуйста - как от вылета за стек (это в смысле исчерпания свободного места там или ещё как бывает?) можно защититься программно? Или оно железом поддержано должно быть?

Очень хороший вопрос.

>Будьте любезны на полтона ниже.

Извините, пожалуйста, если я допустил бестактность.

"можно защититься программно"

Тогда возможно предположить, что дело в реализации виртуальной Java машины. Есть ли принципиальные ограничения на то, что JVM в Linux до сих пор уступает JVM'ам в Solaris, AIX, HP/UX и ... я, скажу честно, не знаю, хотя флейм на ЛОРе где-то год назад был. Докладываю только эмпирические факты, то что мне показали. Если у кого есть рациональное объяснение, то с удовольствием бы выслушал.

>> В пингвиниксе (не юниксе) вылететь за границы стека - как нечего >> делать!

> Это надо послать Задорнову - он ( я слышал ) такие перлы собирает !

Совершенно ламерский вопрос. Только не посылайте меня, как это принято среди великих гуру ЛОРа, сразу.

Как вообще можно вылететь за границы стека используя не С, а Java (без native методов, причем), то есть используя язык, в котором строжайше запрещена работа с указателями?

Значит коряво написана JVM под Linux. Что делать несчастному пользователю, не являющемуся хакером?

Странная цитата, она подразумевает что Linux - тоже Unix ;) Как я уже говорил, хотя линукс и задумывался как одна из реализаий posix, именно посикс реализован местами кривовато. А какие потоковые функции имеются в виду не совсем понятно. Я поку придумать как минимум два варианта для слова "потоковый" (threads и streams (последних в линуксе кстати вообще нет)). Тем не менее не стоит принимать реализации всяких стандартов в "других юниксах" как истинну в последней инстанции, любопытный обзор заморочек с advisory/mandatory file locking можно увидеть в /usr/src/linux/Documentation/locks.txt && /usr/src/linux/Documentation/mandatory.txt

>>>Очень хороший вопрос.

Хотелось бы видеть хоть какой-нибудь ответ...

>>>Если у кого есть рациональное объяснение, то с удовольствием бы выслушал.

Как можно рационально объяснить что-то, если нет не то чтобы стек-трейса, но и вообще каких-либо сведений о происходившем?! Может дело даже не в JVM, а скажем, в DB-backend или программистской ошибке в сихронизации тредов, которая не проявлялась на гораздо более быстром процессоре?

Или всё было просто и тупо - памяти не хватало для громоздкого приложения, а? Если оно писалось-гонялось на "Solaris, AIX, HP/UX", то значит требовало соотвествующих ЖЕЛЕЗНЫХ ресурсов, а на чём линукс запускали - на PC? Попытались бы ещё на PDA c Jeode портировать 8[

Учитывая что у Linux & Solaris JVM общий codebase, было бы любопытно узнать в чем же кто там кому уступает.

На самом деле определение "быстрый процессор" применимо скорее к PC.

>>>Как вообще можно вылететь за границы стека используя не С, а Java (без native методов, причем),

Что такое "вылететь" я и просил прояснть, утверждавшего это.

Исчерпать же стек (и нативный и JVM) можно на любой платформе/OS - поэтому вторая часть вопрос была о том, КАКАЯ платформа/OS и как умеет справляться с этой ситуации без абортирования процесса...

>А какие потоковые функции имеются в виду не совсем понятно.

Судя из контекста треды. Далее авторы объясняют pthread_t и прочее.

Я конечно прошу простить меня за назойливость, но продемонстрированный мне краш был именно segmentation fault, а не генерация исключения Жабы. Если кто мог бы объяснить это явление, то он, IMHO, существенно бы помог в борьбе против мелкомягких.

>или программистской ошибке в сихронизации тредов, которая не проявлялась на гораздо более быстром процессоре?

Вряд ли. На то же машине был и мастдай2000.

Помню, был флейм про Linux JVM где-то год или чуть более назад.

>КАКАЯ платформа/OS и как умеет справляться с этой ситуации без абортирования процесса...

Хорошо. Тогда такой вопрос. Может ли (теоретически) хорошо написанная JVM вылетать на segmentation fault? Или, при обнаружении исключительной ситуации, должно генерироваться исключение Джавы?

Уязвимость в Adobe PDF File Readers

>Я конечно прошу простить меня за назойливость, но продемонстрированный мне краш был именно segmentation fault, а не генерация исключения Жабы. Если кто мог бы объяснить это явление, то он, IMHO, существенно бы помог в борьбе против мелкомягких.

gdb + аварийный дамп процесса

Причиной Segmentation fault может служить множество причин, и выезд за границы физического стека - лишь одна из них. Демонстрирую segmentation fault JVM на любой платформе с изменяемыми лимитами на AS и stack size за умеренную цену ;)

>gdb + аварийный дамп процесса

Можно, конечно с java_g было попробовать. Но вот в чем дело. Если бы была нехватка памяти, то было бы исключение

java.lang.OutOfMemoryError

или по Java руководству в случае проблем со стеком

java.lang.StackOverflowError

(Thrown when a stack overflow occurs because an application recurses too deeply.)

Но никак не segmentation fault.

Разбираться с этим просто не позволят - начальству работа нужна.

Впрочем, начальство приняло "соломоново решение"...

>Демонстрирую segmentation fault JVM на любой платформе с изменяемыми лимитами на AS и stack size за умеренную цену ;)

Ну вот, а говорят GPL! :(((

По теории (и практике не больших юниксах) должно быть StackOverflowError - в Жабе нет указателей (за что ее прикладники и любят, а хакеры ненавидят :)))).

Эй-эй, так значить задачка работала под w2k и падала на Linux на одном и том же железе? Причем работала она в одном системе и стабильно трапалась по segm fault в другой с _разными_ JVM? На ошибки в разных JVM я напарывался, но чтобы все jvm под линукс валились одинаково - такого не видел.

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

Уязвимость в Adobe PDF File Readers

Что говорит Sun по этому поводу: (февраль 2002)

One of the most likely root causes for the JVM exiting with segmentation faults is a problem with specific versions of the Linux glibc library and the JVM for Linux. It has been discovered that the combination of glibc v2.2.2 and the JVM for Linux is not stable and causes the JVM to crash. Upgrading the glibc to a newer version such as glibc 2.2.4 will ensure that the JVM does not exit with segmentation faults under a heavy load.

Значит проблема в лялихе ?

Падать без StackTrace jvm ессно могут в самых разнообразных ситуациях - сам видел такое в какой-то достаточно древней ibm'овской реализации на элементарной операции - работе с zip 8( Потом конечно поправили...

Гриныч, чего насчет Adobe тормозишь ?

Проблема не в лялихе, а в разнообразии возможных комбинаций gcc/glibc, сильно остро стоит в последний год, поэтому jvm надо пользовать не скаченную с sun, а собранную из сырцов. Или же покупать SuSE c поддержкой.

>Значит проблема в лялихе ?

Саныч у нас как фокусник - всегда запасного кролика из рукава достанет:))). Вообще-то у меня старшие версии glibc, так что меня, наверное, поэтому Бог миловал. Буду надеяться, что glibc > 2.2.4 выдержит нагрузку.

Я то прикладник-"код давай", не системщик. Мне вообще все равно, что хозяин выберет. Но мастдай не люблю, а люблю юниксы, ну Линукс, можно дома поставить.:)))

Кстати, планируется ли "настоящая" Java для *BSD?

Мало ли что должно быть, однако особенности реализации вносят свои коррективы

>а собранную из сырцов

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

>Или же покупать SuSE c поддержкой.

Это дороже Sun Blade 150 будет.

Вроде как написано, что в glibc

А че с файром тормозишь? я уж заждался весь ;)

Уже ж есть. ТОт же codebase что и Liunx/Solaris JVM, тока слегка подпатченный.

Собрирать ее из сырцов - то еще удовольствие. gcc/glibc никакой особой проблемы кстати не ставит. Другое дело mixing g++ 2.95 и g++ 3 об'ектники, там и правда жопа.

А кто еще glibc пользует кроме лялиха ?

Debian/BSD, например, а ешшо GNU Hurd

Дык не будет лялих на нем работать ?

Да ладно вам тут спорить, а сейчас новость про GPL посмотрел и расстроился. Особенно IBM расстроила. У Ирши сегодня просто праздник. Объединяться беэсдешникам и линуксоидам надо, а не мобилами меряться. Так же не надо противопоставляться прикладникам и системщикам.

Санычу за цитату спасибо.

Как ты можешь знать - ешшо ж не попробовали ;)

>Кстати, планируется ли "настоящая" Java для *BSD?

Все *BSD могут исполнять программы из лялих, даже Oracle

NetBSD на спарках может исполнять бинарники из Solaris

Только нафига ?

Oracle? На BSD? Это как же так? Про линух-эмулятор слышать ничего не хочу, сказано - на BSD!

>Все *BSD могут исполнять программы из лялих

Это понятно, вроде как LOR на фряке крутится. Интересно чтобы быстрая нативная Жаба была под *BSD. Что там слышно по поводу kaffe?

Твои сведения устарели на пол года. LOR ноныча крутится на красной шапке