Здравствуйте, gandjustas, Вы писали:

DOO>>Товарищ, открытый порт еще ничего не значит. Давно уже все используют МЭ прикладного уровня, особенно для Web-трафика. Я тебе специально в пример привел RPC — на ISA сервере я могу перекрыть конкретные RPC интерфейсы, даже если используется транспорт nc_acn_named_pipes — который гуляет поверх SMB, т.е. 445-го или 139-го порта.
G>Это из тойже оперы что поудалять конфиги,а потом жаловаться на .NET.

Жаловаться я буду на программера, который от радости "что не надо ничего знать, чтобы написать коммуникацию между процессами на разных компьютерах" не удосужился правильно обработать различные вполне себе жизненные ситуации. Точнее даже не жаловаться, а материть его...
Точнее даже не конечного кодера, а архитектора. Классическому кодеру и не надо ничего знать — тут да, .Net удешевляет труд кодера за счет упрощения. Вот только упрощение это может привести к тому, что кодер пропадет вообще

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, lifrsdn, Вы писали:

L>>Ну и надо всё время проверять, что в этом месте процедуры этот tmp ещё нужен, а чуть ниже по тексту уже нет.
DOO>Неужели это такая проблема помнить свои переменные в рамках одной синтаксической конструкции?
DOO>Попиши на асме какое-то время — дисциплина подтянется

Аргумент ваще никакой.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, gandjustas, Вы писали:

DOO>>>Товарищ, открытый порт еще ничего не значит. Давно уже все используют МЭ прикладного уровня, особенно для Web-трафика. Я тебе специально в пример привел RPC — на ISA сервере я могу перекрыть конкретные RPC интерфейсы, даже если используется транспорт nc_acn_named_pipes — который гуляет поверх SMB, т.е. 445-го или 139-го порта.
G>>Это из тойже оперы что поудалять конфиги,а потом жаловаться на .NET.

DOO>Жаловаться я буду на программера, который от радости "что не надо ничего знать, чтобы написать коммуникацию между процессами на разных компьютерах" не удосужился правильно обработать различные вполне себе жизненные ситуации. Точнее даже не жаловаться, а материть его...
DOO>Точнее даже не конечного кодера, а архитектора. Классическому кодеру и не надо ничего знать — тут да, .Net удешевляет труд кодера за счет упрощения. Вот только упрощение это может привести к тому, что кодер пропадет вообще

То есть надо обработать Exeptionы. Да уж, тяжелая задача.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, gandjustas, Вы писали:


G>>Remoting вообще не использует DCOM.
DOO>Что бы он там не использовал, но у меня все равно должен быть инструмент, который скажет — вот эту бяку запускать только локлаьно и только админом, эту вообще не запускать и т.п.

G>>Для сборок на компе по-умолчанию FullTrust.
DOO>Настройки по умолчанию это неинтересно. Надо знать какие конкретно права необходимы сборке локально и удаленно, чтобы remoting работал как надо. Иначе будут непонятки (сменятся умолчания с выходом очередного SP и все — приехали).

Сомнительно. Аргумент из серии "а у вас негров линчуют".

DOO>Вообще проблема не надумана — после установки ISA Server 2004 SP2 на W2k3 SP1 R2 некоторые инструменты администрирования MS перестают работать (например, настройка NLB кластера) — в чем конкретно проблема

Ты явно куда-то не в ту степь полез.

G>>При работе через 80 порт по протоколу HTTP все будет пучком.
DOO>
DOO>А MS RPC тоже частенько работает только по 445-му порту (ну или 139-му), но это не значит, что нет грамотных МЭ, которые не отсекут конкретный интерфейс...

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

Здравствуйте, Сергей, Вы писали:

С>Здравствуйте, _d_m_, Вы писали:

___>>Неа. Только не стоит забывать, что JIT компилятор работает с байт кодом, а не с исходниками. Яволь?

С>Вот смотри: у нас есть обычный компилятор и JIT. У первого — времени столько, сколько понадобится, никаких ограничений не накладывается.

А теперь ты смотри: у нас есть сначала компилятор в байт код, у него есть времени столько, сколько понадобидться, никакаких ограничений не накладывается, чтобы произвести оптимизированный байт код. А потом этот код берет жит компилер и оптимизирует под конкретные: процессор/много процессоров/архитектуру (32/64)/ОС/объем ОЗУ. Хотя время на жит компиляцию конечно тратиться. Ну теперь яволь?

_>>И с gc тоже. Ещё какие!

kuj>Какие?

Легко. Лично сталкивался с ситуацией когда на одной из моторол (платформа Java ME)после каждого проигрывания wav-файла число потоков в системе всегда увеличивалось и не уменьшалось никакими средствами.
Понятно, что это вина не джавы, как таковой, а корявой реализации библиотек производителями телефонов, не всё же...

Здравствуйте, se_sss, Вы писали:

_>>>И с gc тоже. Ещё какие!

kuj>>Какие?

_> Легко. Лично сталкивался с ситуацией когда на одной из моторол (платформа Java ME)после каждого проигрывания wav-файла число потоков в системе всегда увеличивалось и не уменьшалось никакими средствами.
_>Понятно, что это вина не джавы, как таковой, а корявой реализации библиотек производителями телефонов, не всё же...

Моторолы, как я слышал, вабще отличаются глючностью софта.

Здравствуйте, Maxim S. Shatskih, Вы писали:

C>>, и достаточно убогая компонентная модель (в Дельфи они однозначно была лучше).
MSS>Это OCXы-то? весьма развитая модель.
В Дельфи вообще-то не OCXи, там свои собственные компоненты.

MSS>Когда программы, созданные тулом, плохо работают с базой данных — тут не то что VB6 лучше покажется, а и PowerBuilder.
Borland умел ADO использовать. А до появления ADO вообще везде плохо было.

Здравствуйте, _d_m_, Вы писали:

___>Здравствуйте, DOOM, Вы писали:

DOO>>Здравствуйте, lifrsdn, Вы писали:

L>>>Ну и надо всё время проверять, что в этом месте процедуры этот tmp ещё нужен, а чуть ниже по тексту уже нет.
DOO>>Неужели это такая проблема помнить свои переменные в рамках одной синтаксической конструкции?
DOO>>Попиши на асме какое-то время — дисциплина подтянется

___>Аргумент ваще никакой.

Каков изначальный посыл
Проблемы с запоминанием использования переменной на 10-15 строках (а длиннее редко бывают конструкции) — это тоже знаете ли...

Здравствуйте, hattab, Вы писали:
H>Я привер пример тула. Чего еще? Примеры нужны? Ищи. Только думаю это все в корпоративном секторе, коли на него нацелено...
Этот тул нежизнеспособен. Авторы WebSnap не поняли, что такое веб приложения, и как их нужно писать. Еще вопросы?

Здравствуйте, hattab, Вы писали:
H>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
Ну если захотелось помериться хамилками, то объясни мне, как Дельфи разработчик, отчего в дельфи программах утечки памяти наступают на ровном месте. Ась?
Я вот учил ПДД по вот такой дельфийской программе — приходилось перезапускать раз в десять минут из-за чудовищных ликов. А казалось бы — место ровнее некуда.

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, Сергей, Вы писали:

С>>У JIT-компиляторов оптимизация получается неважная — потому что важно обеспечить быструю компиляцию.

kuj>Хорошо придумал. В действительности, оптимизация на очень достойном уровне. RTFM вообщем.

Я верю, что оптимизация у .NET-компиляторов лучше, чем у Delphi — потому что у нее все совсем уж плохо.
Но если сравнить с хорошим оптимизирующим C/C++ компилятором, я думаю, дотнетовский JIT-компилятор проиграет.
Тут соображение такое: у обычного не-JIT-компилятора ограничений на время фактически нет, а для JIT — есть ограничения на время генерации кода.
Некоторая работа, конечно, делается заранее — компиляция в байт код (тут есть место для оптимизаций, но не "под конкретный процессор", о чем было написано в том сообщений, в ответ на которое я написал свое), но те задачи, что нужно делать Just-In-Time, должны выполняться быстро.
Т.е. JIT изначально находится в худших условиях по ограничениям на время, поэтому при прочих равных не-JIT имеет больше возможностей для оптимизации.
Разумеется, это не повод для выбрасывания дотнета "в печку".

Здравствуйте, _d_m_, Вы писали:

H>>Если люди чего-то там не знали/забывали, это характеризует только их, но не инструмент. Если выражаться простым языком: не можешь срать -- не мучай жопу. В управляемых средах, таки, есть место ручной очистке (пусть даже семантически скрываемой) для объектов владеющих ресурсами. Что начнется, когда

___>В оригинале вобще-то звучит вобще-то "не хочешь срать — не мучай жопу". Разница существенная. В дальнейшем просьба быть точнее, а то минусы буду ставить нещадно!

Мне доводилось слышать в моем варианте. А виртуальный фетишь меня не прет, т.ч. хоть обминусись

Здравствуйте, _d_m_, Вы писали:

___>Здравствуйте, hattab, Вы писали:

MC>>>>>Речь не о SOAP-сервисах, а о создании веб-морд. Т.е. упрощенно — когда есть HTML-шаблоны и java/.net код, который на их основе хитро генерит динамические страницы. Ну, короче, как в php.

H>>>>WebSnap. Ребята, оно было еще в 6 версии. Intraweb еще круче

___>Ну вот здесь говришь...

kuj>>>Хочу полноценный MVC с unit test`ами и расширяемым view-engine по типу Brail (из Castle Monorail)! Где?

H>>Я не занимаюсь вебом, ничего сказать не могу.

___>А здесь ничего не можешь сказать. Как так?

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

MSS>>BDE — аналог Jet из Access. Для своей родной файловой БД неплох, но обращения к внешним SQL источникам там идут через механизм attached table, который, как я понимаю, откачивает почти всю выборку из внешнего SQL в таблицу во временной "родной" БД, и потом листает именно ее.

H>Кажется, BDE появился раньше Jet (хотя тут могу ошибаться)

Примерно одновременно, в двух совершенно аналогичных продуктах Paradox и Access. BDE тогда назывался IDAPI.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, DOOM, Вы писали:

DOO>>Здравствуйте, gandjustas, Вы писали:

DOO>>>>Товарищ, открытый порт еще ничего не значит. Давно уже все используют МЭ прикладного уровня, особенно для Web-трафика. Я тебе специально в пример привел RPC — на ISA сервере я могу перекрыть конкретные RPC интерфейсы, даже если используется транспорт nc_acn_named_pipes — который гуляет поверх SMB, т.е. 445-го или 139-го порта.
G>>>Это из тойже оперы что поудалять конфиги,а потом жаловаться на .NET.

DOO>>Жаловаться я буду на программера, который от радости "что не надо ничего знать, чтобы написать коммуникацию между процессами на разных компьютерах" не удосужился правильно обработать различные вполне себе жизненные ситуации. Точнее даже не жаловаться, а материть его...
DOO>>Точнее даже не конечного кодера, а архитектора. Классическому кодеру и не надо ничего знать — тут да, .Net удешевляет труд кодера за счет упрощения. Вот только упрощение это может привести к тому, что кодер пропадет вообще

G>То есть надо обработать Exeptionы. Да уж, тяжелая задача.

Надо их корректно обработать.
Еще пример (опять жизненный): была у меня проблема в работе VMWare virtual infrastructure client (этот уже на .Net'е писан) — не мог цепляться к удаленной консоли. Клиент говорил, что-то типа: Failed to establish remote MKS connection. Could not read /bla-bla-bla/machine_name.vmx. Молодца. Просто море отладочной информации — а почему он его could not read? Если сам клиент не смог бы, например, показать свойства виртуальной машины без доступа к этому файлу? Вот сидел и гадал. Твоя обработка исключения будет приводить к точно таким же "подробным" диагностическим сообщениям. Чтобы сделать грамотно, надо все-таки знать, как это работает, а не так, что "вот как просто, можно даже ни черта не знать, чтобы пользоваться".

Здравствуйте, _d_m_, Вы писали:

H>>>>>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы

kuj>>>>>Угу, пропал exe-шник — отвалилась голова.

H>>>>У тебя конфиги ни разу не слетали? Если у меня слетит конфиг, моя прилага не забудет как по XML-RPC разговаривать

kuj>>>Не знаю как оно в Делфи, но в .NET и Java конфиги не имеют такой привычки — куда-то там слетать...

H>>И юзеры с админами ну прям небожители. Охотно верю.

___>Ну так какое отношение .Net имеет к админам? Если уж ты такой любитель народных поговорок (впрочем как и я): с дуру можно и х.. сломать"

Ситуация, вполне себе, жизненная

Здравствуйте, _d_m_, Вы писали:

ДГ>>>Гы. Это был аргумент из серии "я вот тут комп с десятого этажа уронил, теперь он гад загружаться не хочет". Догадываешься, что случится, если в линухе все конфиги пропадут? Конфиги — такие же файлы, как и екзешники.

H>>Какое мне дело до Линукса? Ни одного юзера не допрет править руками exe'шник, а конфиг за милу душу. Но если тебе приятно не замечать проблемы, чтож, хозяин -- барин.

___>Мужики, он против Линукса — налетай

Я не против Он мне... В общем, фиолетов.

Здравствуйте, _d_m_, Вы писали:

kuj>>>FxCop поможет... И не только с этой проблемой, кстати.

H>>Я знаю, что такое FxCop У Борланда давно уже был CodeGuadr для C++ (задачи примерно те же).

___>Бгга Я наелся дерьма C++ Builder даже не считая CodeGuard-а еще 5 лет назад. Ф топку .

___>До сих пор помню такой замечательный глюк CodeGuard-a: компилирую проект, в рантайме летит ошибка на ровном месте, я меняю местами объявления шаблонрв класса в исходном файле — все работает нормально. После этого отказался от CodeGuard-а, через некоторое время понял, что глюкавый компилятор тоже меня не устравает. Начинал я вообще с Turbo C++ 1.0.

Кто не без греха...

___>Про Дельфи не скажу, но от поделий Богланд меня что-то воротит. Может вспомним еще угробище под названием Interbase?

Есть такая штука: индивидуальная препаратная непереносимость Про интербейс спорить не буду, мне его клон (FB) вполне нравится (но я и с MSSQL (6.5-2000) работал).

Здравствуйте, _d_m_, Вы писали:

___>А теперь ты смотри: у нас есть сначала компилятор в байт код, у него есть времени столько, сколько понадобидться, никакаких ограничений не накладывается, чтобы произвести оптимизированный байт код.

Это все понятно. Тут у JIT и не-JIT условия одинаковые и работу свою они могут сделать одинаково хорошо.
К примеру, GCC и так сначала компилирует программу в некоторое промежуточное представление, а только потом — генерирует код под конкретную архитектуру.
Но на этой стадии — никаких оптимизаций под конкретную архитектуру нет и быть не может.

___> А потом этот код берет жит компилер и оптимизирует под конкретные: процессор/много процессоров/архитектуру (32/64)/ОС/объем ОЗУ. Хотя время на жит компиляцию конечно тратиться.

На этой стадии JIT долго работать не имеет права, а для обычного компилятора время не так важно.
Соответственно, у обычного компилятора (как их по-научному называть-то? а то уж больно похоже на "обычный порошок") больше возможностей для оптимизации машинного кода.
Это, конечно, не повод выбрасывать дотнет "в печку", только соображение о том, что там не все так хорошо, как хотелось бы.
Ну и недостаток этот, конечно, не критический.