![[info]](/images/41029.gif){kind=small}
Мартовский фуршет
-
-
- it_romance
- 15.03.2009 5:34
- ↑
- →
попасть в друзья? найти людей, которым страница доступна? Подкупить Дурова?))
взломом заниматься я бы не стал -
-
-
- it_romance
- 15.03.2009 6:24
- ↑
- →
постараться узнать какую-то инфу о человеке и искать его потенциальных френдов
-
-
-
- it_romance
- 15.03.2009 6:42
- ↑
- →
с технической - подкупить Дурова/найти знакомых в ФСБ.
по факту - можно попробовать следующее - внятно описать ситуацию по обратной связи и попросить помочь - мб они просто напишут этому человеку, что Вы хотите к нему попасть -
-
-
- it_romance
- 15.03.2009 7:12
- ↑
- →
там есть возможность донести информацию до него. правда, она будет публичной.
-
-
-
- timoha_spb
- 15.03.2009 17:29
- ↑
- →
Самый действенный способ в данном случае - социальная инженерия. Значительно эффективнее технических хаков.
-
-
Если страница закрыта, а фотки нужны то можно попробовать так:
когда кликаете на человека, то в адресной строке будет: http://vkontakte.ru/search.php?id=***
Замените "search" на "photos" и вам покажут незакрытые альбомы. -
-
- desstroyer
- 15.03.2009 11:15
- ↑
- →
Касаемо вконтакте: если человек открыл свою страницу только для друзей, но в настройках поставил, что фотки доступны всем, напрямую фотки смотрятся так: http://vkontakte.ru/photos.php?id=xxx,
где id - идентификатор пользователя. Попробуйте, если не прокатит - тогда попробовать подбор пароля и др. -
-
Если у человека расшарены кукисы или можете их каким-то образом вытащить с его винта, то можно найти в них файлы, в имени которых есть "@vk" (если совершаете взлом в соц. сети Вконтакте, насчет названия других не знаю), взять из них зашифрованные данные и с помощью специального плагина будучи залогиненным вконтакте заменить эти данные со своих на его, обновить страницу и вуаля - мы залогинены под чужим аккаунтом.
Другой способ - искать расшаренный wand.dat (запоминалка паролей в Опере) и вскрывать программой unwand.exe -
Вот эти плагины нужны:
Add N Edit Cookies: https://addons.mozilla.org/ru/firefox/addon/573
CookieSwap: https://addons.mozilla.org/ru/firefox/addon/3255
Из кукисов жертвы копировать в редактор Add N Edit Cookies такие строчки
remixmid(зашифрованный id), например 6220264
remixemail(мыло), например nasty_i%40mail.ru
remixpass(зашифрованный пароль), например de51c170783c5eadd7a0b7daa5276b0e -
-
- dmitriy_sun
- 15.03.2009 5:41
- ↑
- →
Потому что:
во-первых, они не привязаны к среде исполнения (Win, Unix, etc...) - это главное.
во-вторых, их легче модифицировать прямо во время работы - это второстепенное. -
-
-
- eternal__here
- 15.03.2009 6:04
- ↑
- →
1. Ну тебе придётся, например, пересесть с одного сервера на другой.
Да и проблема это больше тянется с того времени, когда решения Microsoft ещё не были на высоком уровне, а сайты работали почти все под unix. Проблемы-то как запустить приложение под уёбишным юниксом - не компилировать же каждый раз.
2. .net пока "почти" только под Виндой. Реально типа будет не только.
Но с другой стороны - хостинг под винду тоже стоит что и под unix, решения Microsoft сейчас не менее стабильны чем под unix и т.д.
А фишка тут ещё появляется, что, создавая сайты на связке asp - c#, например, код c# компилируется в машинные коды.
И ещё. Программирование на perl, php, с++, delphi и прочим - полное уебанство по сравнению с программированием на c#. На c# гораздо быстрее, надёжней, понятней и т.д. -
-
-
- dmitriy_sun
- 15.03.2009 6:21
- ↑
- →
C# быстрее... это... вы как специалист говорите?
"Проблемы-то как запустить приложение под уёбишным юниксом - не компилировать же каждый раз." - ну вы смешной правда, конечно не компилировать - просто скопировать, и все (про скриптовые языки) :-)))
Ну... конечно все что не C# - это уебанство... А Win - это единственная нормальная среда... Угу...
Где сейчас .Net действительно рулит - это внутренняя корпоративная среда. Пока что все. -
-
-
- eternal__here
- 15.03.2009 6:29
- ↑
- →
C# быстрее... это... вы как специалист говорите?
Да. Ответственно заявляю: на c# разработка ведётся СУЩЕСТВЕННО быстрее. Готов поспорить на деньги.
Ну и разумеется, быстрее выполняется чем perl, php, java и очень частенько чем delphi.
Ну... конечно все что не C# - это уебанство... А Win - это единственная нормальная среда... Угу...
Ну я такого не заявлял.
Тут надо понимать, что для чего нормально.
Apache запустить? Ну да, unix.
Для embedded - местами qnx (этот симпатичный тухлый труп). Как вариант.
Приложение написать - винду, c#, Microsoft SQL (пусть и Express). Всё остальное - нахуй.
Где сейчас .Net действительно рулит - это внутренняя корпоративная среда. Пока что все
Посмотрите вокруг. Уже давно нет. -
-
-
- dmitriy_sun
- 15.03.2009 7:19
- ↑
- →
"
Да. Ответственно заявляю: на c# разработка ведётся СУЩЕСТВЕННО быстрее. Готов поспорить на деньги.
Ну и разумеется, быстрее выполняется чем perl, php, java и очень частенько чем delphi.
"
C++? Почему не в списке? На C# отладка идет быстрее? Ну и что... Он не кроссплатформенен (однако !)...
"Для embedded - местами qnx (этот симпатичный тухлый труп). Как вариант."
Win не обеспечивает realtime - так что о тухлых трупах предлагаю дискутировать в контексте ОС, а не языков. :-) Вы яхту с глубоководной подлодкой сравниваете.
"Apache запустить? Ну да, unix." - Apache хорошо здравствует и на Win... дело в другом. Win платформа не обеспечивает такой же производительности и гибкости (вот уж точно) TCP/IP-стека. Так что... *nix в Инете еще долго будет превалировать... -
-
-
- eternal__here
- 15.03.2009 7:33
- ↑
- →
Неконструктивно пошло, товарищ.
C++? Почему не в списке? На C# отладка идет быстрее?
C++ в том же списке. Где-то по середине.
Ну и что... Он не кроссплатформенен (однако !)...
Дятька в Киеве.
Win не обеспечивает realtime - так что о тухлых трупах предлагаю дискутировать в контексте ОС, а не языков. :-) Вы яхту с глубоководной подлодкой сравниваете.
Дятька в Киеве. Я отвечал на "А Win - это единственная нормальная среда.".
Apache хорошо здравствует и на Win
Чушь. RTFM.
Apache глючит и падает под виндой. Он некорректно написан. Он конфликтует с антивирями. И т.д.
Да и попробуйте реальный проект под винду с Apache запустить, а потом спорьте.
Я умею его стабильно настраивать под Win, но это гемор несусветный. Надо кучу всего в системе перелапачивать.
Win платформа не обеспечивает такой же производительности и гибкости (вот уж точно) TCP/IP-стека
Опоздали. Уже давно не актуально. Я бы мог с Вами об этом подискутировать, но лучше Вы это, с Яндексом и ручками.
Это байка старая.
Так что... *nix в Инете еще долго будет превалировать
OFFTOP. Домашние маршрутизаторы D-Link работают под Виндой.
Спокойной Вам ночи! -
-
-
- dmitriy_sun
- 15.03.2009 7:54
- ↑
- →
"
Win не обеспечивает realtime - так что о тухлых трупах предлагаю дискутировать в контексте ОС, а не языков. :-) Вы яхту с глубоководной подлодкой сравниваете.
Дятька в Киеве. Я отвечал на "А Win - это единственная нормальная среда.".
Тогда зачем упомянули?
"
Ну и что... Он не кроссплатформенен (однако !)...
Дятька в Киеве.
"
Ога. Вообще вопрос возник из того - почему скриптовые языки рулят. Так вот(!). При переносе с хостинга на хостинг достаточно просто скопировать файлы. И никого не чешет, под чем работают эти сервера. .Net это обеспечит? (а почему бы не вернуться к началу топика? :-))) ) -
-
-
- eternal__here
- 15.03.2009 8:21
- ↑
- →
1. Для того чтобы ответить на промежуточный комментарий, считаю ли я что только Винда рулез и т.д.
2. См. выше свой коммент "C++? Почему не в списке? На C# отладка идет быстрее? Ну и что... Он не кроссплатформенен (однако !)... ".
3. Хватит флудить.
4. Удачи. -
-
-
- dmitriy_sun
- 15.03.2009 7:56
- ↑
- →
"
Apache хорошо здравствует и на Win
Чушь. RTFM.
Apache глючит и падает под виндой. Он некорректно написан. Он конфликтует с антивирями. И т.д.
Да и попробуйте реальный проект под винду с Apache запустить, а потом спорьте.
Я умею его стабильно настраивать под Win, но это гемор несусветный. Надо кучу всего в системе перелапачивать.
"
Прям не знаю, что сказать. 3 сервера. Все работает. Прямо развожу руками... Ничего не падает... ничего не глючит... Аномалия. -
-
-
- eternal__here
- 15.03.2009 8:18
- ↑
- →
1. Посещаемость в сутки?
2. Что ещё активно работает на этих серверах?
Мы говорим о win + apache + php + mysql, так? -
-
-
- kanapfelka
- 15.03.2009 9:16
- ↑
- →
OFFTOP. Домашние маршрутизаторы D-Link работают под Виндой.
ну, так, д-линк говно -
-
"На C# отладка идет быстрее? Ну и что... Он не кроссплатформенен (однако !)... "
http://www.mono-project.com/
"Win платформа не обеспечивает такой же производительности и гибкости (вот уж точно) TCP/IP-стека"
1. миф
2. сколько процентов серверов в сети имеют хорошо настроенный tcp/ip стек под свои задачи? < 0.001% -
-
- eternal__here
- 15.03.2009 8:38
- ↑
- →
1.Пробовали? Стабильно?
Я предположу, что это ещё не серьёзное решение, но в будущем будет всё как надо.
2. Да. Именно. Они всё за миф 96-го года цепляются. -
-
-
- eternal__here
- 15.03.2009 7:25
- ↑
- →
В данном контексте выше, как не сложно догадаться, я говорил прежде всего о скорости разработки.
-
-
-
- eternal__here
- 15.03.2009 8:35
- ↑
- →
Ну я бы с Вами почти согласился, но...
В delphi куча лишнего мусора на выходе. Это факт.
Java. Я не являюсь большим специалистом по Java, поэтому могу что-то упустить. Но те сравнения (из совершенно разных источников), что я видел, говорят о том, что решение c# быстрее. И здесь играет роль и оптимизированность кода на выходе, и JIT для Java.
Всё развивается, всё движется. Но насколько я вижу, решения от Microsoft уже на голову выше. И я ещё больше уверен, что в будущем всё будет только больше в пользу .net и Microsoft. -
-
Современные байт-код и JIT компиляторы Java и .NET примерно равны - обе этих платформы современные и крайне сложные. Есть разница в реализации крупных вещей. Скажем веб-сервисы by-default быстрее под .NET + IIS чем под Java + Tomcat. Но заслуги .NET в этом мало.
К сожалению решения MS в последнее время скорее разочаровывают - такие как новый IIS, новый Win Server, неразбериха с новыми довесками к .NET, которые противоречат друг другу. Microsoft по прежнему сильная компания, которая может многое. Но не на голову выше других, не стоит быть фанатиком до упора. -
-
- eternal__here
- 15.03.2009 9:16
- ↑
- →
1. Сложный спорный момент.
Те "10 раз" я подзагнул относительно текущего момента, но тот коммент был больше эмоциональный, трендовый. Я это уже указал там.
Здесь, кстати, можно и про кросплатформенность Tomcat поговорить. И про его нестабильность при ряде условий.
2. Это временно. Всё и здесь устаканется.
Я не "фанатик до упора". Многие решения Microsoft отвратительны. Но .net, Windows и т.п. - гораздо лучше аналогов. -
-
-
- eternal__here
- 15.03.2009 6:30
- ↑
- →
А да, ещё.
ну вы смешной правда, конечно не компилировать - просто скопировать, и все (про скриптовые языки) :-)))
Я привёл как обоснование распространения скриптовых языков. См. сам вопрос выше. =) LOL. -
-
-
- it_romance
- 15.03.2009 5:49
- ↑
- →
Уже ответили - главное, что они платформонезвисимые. Когда надо сделать очень высоконагруженный сайт - используют С++ для оптимизации, но обычно это не требуется.
.NET И Java компилируются хитро. По большому счету, они компилируются в промежуточное представление - байткод, которое уже на машине интерпретируется (достаточно эффективно), или компилируется и кешируется(.NET) -
-
-
- eternal__here
- 15.03.2009 5:57
- ↑
- →
Почти все интерпретируемые языки компилируются перед выполнением. Просто это делается "на лету". И обычно прикомпилированное кэшируется при отсутствии изменений.
С .net в 1000 раз круче и интересней. Он не просто компилируется при первом запуске, он компилируется в родные для текущей системы машинные кода. И ничем после этого не уступает программам написанным, например, на неуправляемом с++.
При это по производительности выигрывает у той же Java в 10 раз. Поэтому .net очень быстро распространяется и всё остальное ждёт участь какого-нибудь перла. Всё подсдохнет кроме c#, .net и сопутствующих.
Это так, небольшое дополнение. -
-
-
- dmitriy_sun
- 15.03.2009 6:02
- ↑
- →
Да вы фанатик, чесслово. :-) У всех сред есть свои плюсы, не забывайте про это... Именно по этому .Net за... (сколько, кстати, уже времени ;-) ) ВЕБ в подавляющем большинстве так и не завоевала. А процент использования - это и есть самый лучший показатель. Это так... небольшое дополнение. :-)
-
-
-
- eternal__here
- 15.03.2009 6:12
- ↑
- →
Не согласен. Фанатики на всяком говне устаревшем парятся.
Плюсы и минусы у всех - с этим согласен.
.net завоёвывает web со страшной скоростью. Даже Битрикс готовит во всю решения на asp, хотя на php у них уже всё готово. Прекрасно понимают, за чем будущее.
И как только у Битрикса будет готова CMS на asp с достаточным количеством модулей - процентное соотношение поменяется.
Ещё можно посмотреть высоконагруженные серверы. Там как атавизм perl, во всю java на сервере, с++ и asp. Java, кстати, восновном из-за того что на ней разрабатывать сложные вещи было легко. Perl из-за того, что на нём давно начали, тот же Яндекс местами его использует.
Php же распространён из-за того, что на нём легко учиться писать.
И ещё дополнение. Тот, кто собрал хоть 1 серьёзный проект на C# в жизни никогда больше не будет писать ни на чём другом. И это лучший показатель.
И какой смысл разрабатывать в 5 раз дольше, но на старых технологиях? =) -
-
-
- dmitriy_sun
- 15.03.2009 6:30
- ↑
- →
"Даже Битрикс готовит во всю решения на asp, хотя на php у них уже всё готово"
Вы путаете теплое и мягкое. .Net Битрикс - рассчитан на тех - кто выбрал .Net как внутрикорпоративную платформу. Это не значит, что .Net лучше - это значит, что .Net рулит во внутрикорпоративной среде (опирающейся на AD).
Про высоконагруженные серверы - чем преимущество .Net? - факты в студию.
"
И ещё дополнение. Тот, кто собрал хоть 1 серьёзный проект на C# в жизни никогда больше не будет писать ни на чём другом. И это лучший показатель.
"
Я знаю 12 языков программирования, на 7-ми пишу без справочников (программирую уже 18 лет). К сожалению C# относится к 5-ти остальным. Не уверен в том, что C# выродится в дальнейшем более чем в очередной Visual Язык... -
-
-
- it_romance
- 15.03.2009 6:35
- ↑
- →
Про C# - он действительно очень эстетичен и на нем удобно писать (особенно если учесть степень его интеграции со средой разработки).
Мне кажется, что С# занимает свою нишу и никуда вырождаться не будет - такое у меня от него впечатление.
с остальным согласен -
-
-
- dmitriy_sun
- 15.03.2009 6:38
- ↑
- →
Эстетичность C# не вызывает никакого сомнения. Мне нравится. Я немного о другом. :-) Парень выше говорит, что .Net будет рулить в Интернете... мне так не кажется.
-
-
-
- it_romance
- 15.03.2009 6:47
- ↑
- →
Это сложный вопрос. на самом деле я не рассматривал .NET как платформу для высокой нагрузки.
Для невысоких нагрузок .NET удобен, для веб-приложений он удобен тысячу раз - за счет расширения визуальных возможностей.
Слабые места .NET для web - для высоких нагрузок все равно нельзя использовать большое количество фишек, а еще плохо разделен дизайн и код - верстальщик должен разбираться в библиотеке, чтобы писать код.
А еще есть принципиальные сторонники PHP и очень много готовых решений на PHP.
Рулить.. когда-нибудь, может быть.. но не сегодня -
-
Забавно что для высоких нагрузок нельзя использовать .NET, а почему.
Скажем www.microsoft.com - это большая нагрузка или нет? Вы в курсе, что в среднем сайт php на хостинге создает в 5-10 раз больше нагрузку чем asp.net?
Единственные две проблемы для asp.net в убийстве php это то, что он не динамический язык, и то что требует windows (для тех кто не знает про Mono). -
-
- eternal__here
- 15.03.2009 6:40
- ↑
- →
Ещё серьёзное достоинство .net - чем больше им занимаешься, тем больше удивляешься красоте, мощности и т.д. такого решения.
Про остальное - я ответил чуть ниже. -
-
-
- eternal__here
- 15.03.2009 6:37
- ↑
- →
Вы путаете теплое и мягкое. .Net Битрикс - рассчитан на тех - кто выбрал .Net как внутрикорпоративную платформу. Это не значит, что .Net лучше - это значит, что .Net рулит во внутрикорпоративной среде (опирающейся на AD).
Поддержка ldap уже 100 лет есть в Битриксе.
Про высоконагруженные серверы - чем преимущество .Net? - факты в студию.
1. Скорость разработки.
2. Широченные библиотеки.
3. Надёжность и безошибочность кода.
4. Масштабируемость.
5. Доступность внешних сервисов.
6. Возможность легко предоставлять сервисы наружу.
Ну и заодно:
7. Меньшая стоимость программиста.
Тут редко идут путём кастомизированных высокопроизводительных решений. Как правило минимизируют время разработки и наращивают производительность за счёт железа.
Я знаю 12 языков программирования, на 7-ми пишу без справочников (программирую уже 18 лет). К сожалению C# относится к 5-ти остальным. Не уверен в том, что C# выродится в дальнейшем более чем в очередной Visual Язык...
Сколько у Вас серьёзных проектов на с#? Пример приведёте? -
-
-
- dmitriy_sun
- 15.03.2009 6:51
- ↑
- →
"Семен Семеныч..." :-)
Изо всех преимуществ .Net для высоконагруженных серверов, к высоконагруженности относятся... я даже затрудняюсь сказать... ну может... да ни одного. :-) Епрст.... Под LAMP все тоже самое... Конкретнее аргументируйте! Пожалуйста.
Пункт 7 - ? Специалистов Net меньше => они дороже. Не понял аргументации.
Проблема минимизации времени разработки, как правило лежит вне конкретных решений. А то, что для web пока что рулит LAMP - это несомненно. И специалистов больше. И... Ну вот вас, например, не пугает тот факт, что даже уже при 4-х летней бесплатной раздачи Ms средств разработки, количество .Net решений в Интернете не увеличивается. Кстати, а какие высоконагруженные .Net решения вы знаете? (кроме серверов Ms) (я без подкола - сам не знаю ни одного - интересно просто).
Серьезных проектов на C# - ни одного. Я тоже могу с вас спросить за другие языки... Ответите? - Ваш подкол - просто флуд - давайте сосредоточимся на реальных фактах. Да? -
-
-
- eternal__here
- 15.03.2009 7:09
- ↑
- →
Изо всех преимуществ .Net для высоконагруженных серверов, к высоконагруженности относятся... я даже затрудняюсь сказать... ну может... да ни одного. :-) Епрст.... Под
Я не говорил, что там .net используется из-за высокой производительности его.
LAMP все тоже самое... Конкретнее аргументируйте! Пожалуйста.
Нет. LAMP - говно. Сравните хотя бы среды разработки. Время разработки. Стабильность при разработке. Да мы вообще о чём говорим? PHP - это жопа полная по сравнению с asp.
MySQL при хоть сколько-то серьёзном использовании - это безответственное глючное говно! Я говорю не о старых версиях, а о 5.1, например.
Пункт 7 - ? Специалистов Net меньше => они дороже. Не понял аргументации.
Нет. Программистов под юникс НОРМАЛЬНЫХ меньше -> они дороже. Ну и т.д.
Проблема минимизации времени разработки, как правило лежит вне конкретных решений.
Не понял. В смысле? Что можно решать эту задачу аналогичными мерами как при разработке на PHP так и asp? Ну да, если так в общем брать... Но исходно сама среда разработки даёт преимущество в 20 раз. Я не преувеличиваю.
А то, что для web пока что рулит LAMP - это несомненно. И специалистов больше. И... Ну вот вас, например, не пугает тот факт, что даже уже при 4-х летней бесплатной раздачи Ms средств разработки, количество .Net решений в Интернете не увеличивается.
"Специалистов" больше - это потому что проще стартовать. Ну вот Delphi - говно-говном, а распространение среди начинающих колоссальное.
Кстати, а какие высоконагруженные .Net решения вы знаете? (кроме серверов Ms) (я без подкола - сам не знаю ни одного - интересно просто).
microsoft.com Годится?
Серьезных проектов на C# - ни одного. Я тоже могу с вас спросить за другие языки... Ответите? - Ваш подкол - просто флуд - давайте сосредоточимся на реальных фактах. Да?
Ок. Я непосредственно участвовал в разработке серьёзной системы на с++ под unix. Я не шучу. Я поэтому неплохо понимаю, о чём я говорю. -
-
-
- dmitriy_sun
- 15.03.2009 7:37
- ↑
- →
"
MySQL при хоть сколько-то серьёзном использовании - это безответственное глючное говно! Я говорю не о старых версиях, а о 5.1, например.
"
Ну... MsSQL я давно не использую как программист, но вот например, до 3-го SP MsSQL2000 - был такое же беспросветное гавно. Oracle под Win до 9-ки включительно - тоже беспросветно УГ... И гарантии безошибочности и правильности вообще никто никогда дать не может (кроме маркетологов, конечно). И эти платформы используются, как вы говорите: "серьезно". Блин. Откуда ж сервиспаки берутся?... неужели от "безглючности".
"Не понял. В смысле? Что можно решать эту задачу аналогичными мерами как при разработке на PHP так и asp?"
Я говорил про правильное планирование самого процесса разработки.
"microsoft.com Годится?"
Во-первых, я просил его не упоминать, а во вторых до 2005-го года они хостились на Unix'е... и последующий переход скорее спровоцирован маркетинговыми соображениями.
"Нет. Программистов под юникс НОРМАЛЬНЫХ меньше -> они дороже. Ну и т.д."
Скриптовые языки не привязаны к Unix. :-)))))))))) -
-
-
- eternal__here
- 15.03.2009 7:55
- ↑
- →
1. Сравните 2000 и 2008. Что всё бывает когда-то говном - в принципе, согласен.
2. Я так и понял. И ответил там.
3. 2005? Не удивлён. Время перемен. =)
4. Эмм.. Мы про высокотехнологичные решения говорили, про кастомизацию и т.п. Я сравнивал, скажем, с с++. Да и про непривязанность скриптов к ОС - это Вы ещё кому-нибудь рассказывайте. Чушь это.
5. Вы всё время пытаетесь "поймать" на не знании простых вещей. Детский сад, ей богу.
6. Удачи. -
-
-
- dmitriy_sun
- 15.03.2009 6:54
- ↑
- →
Я поясню - C#-то мне нравится. В легкости освоения это просто песня, в легкости сознания клиентских приложений - тоже неплохо... не буду сравнивать с Delphi (ибо ее после 7-ой версии не юзал) - но простенько - хорошо.
Но вот в WEB-е .Net не будет рулить никогда (ну или по крайней мере еще лет 10 точно не будет.) И даже не думайте об этом. -
-
-
- kanapfelka
- 15.03.2009 9:23
- ↑
- →
не встречал быстроработающий сайт на асп (или слепой/глупый?)
«Ещё можно посмотреть высоконагруженные серверы.» http://vkontakte.ru/index.php? -
-
-
- it_romance
- 15.03.2009 6:07
- ↑
- →
про .net - они, конечно, так и пишут про компиляцию. Вероятно, даже делают - компилируют в машинные кода как надо.
Но проблема в том, что практически любой вызов функции из framework порождает кучу внутренних вызовов и проверок, что накладывает свой отпечаток на производительность (убедиться в этом можно в отладчике - заставьте системные функции выдавать исключения). стандартная библиотека С++ гораздо легче по вызовам, поэтому эффективнее. Кроме этого в native C++ есть механизм указателей, который несет в себе много потенциальных проблем при разработке, но и несет возможность писать высокоэффективный код - потому что арифметика указателей преобразовываются в машинный код почти дословно (переводится напрямую в команды процессора без вызовов и проверок).
А в том же .NET при адресации массива есть проверка на его границы и код для выброса исключения.
Исключения в .NET используются повсеместно, а они не очень эффективны сами по себе - появляется много лишнего машинного кода - проверка и генерация исключения.
так что их рекламные слова ложью назвать нельзя, но они недоговаривают.
А вообще, я сам фанат .Net и C# в частности ) Очень приятная и эстетичная для разработчика среда) -
-
-
- eternal__here
- 15.03.2009 6:24
- ↑
- →
Но проблема в том, что практически любой вызов функции из framework порождает кучу внутренних вызовов и проверок, что накладывает свой отпечаток на производительность
Чушь.
(убедиться в этом можно в отладчике - заставьте системные функции выдавать исключения).
1. Не надо сравнивать производительность "под отладчиком". Ок?
2. Исключения не могут быть в основе нормального функционирования.
Обратите внимание, что есть int.Parse(...) и int.TryParse(...) Вовсе не случайно.
стандартная библиотека С++ гораздо легче по вызовам, поэтому эффективнее.
Чушь.
Кроме этого в native C++ есть механизм указателей, который несет в себе много потенциальных проблем при разработке, но и несет возможность писать высокоэффективный код - потому что арифметика указателей преобразовываются в машинный код почти дословно (переводится напрямую в команды процессора без вызовов и проверок).
В c# тоже есть указатели. Да-да. Врубил unsafe и еби себе мозг всякой хуйнёй.
Кто сказал, что в компилированном c# остаются лишние проверки?
А в том же .NET при адресации массива есть проверка на его границы и код для выброса исключения.
Уффф... Там чуть хитрее. Не стану особо спорить, но при адресации машинными кодами есть механизм автопроверки границ. И т.д.
Исключения в .NET используются повсеместно, а они не очень эффективны сами по себе - появляется много лишнего машинного кода - проверка и генерация исключения.
1. Это того стоит.
2. Не всё так плохо.
3. Большинство кода предназначено для использования в условиях похер-на-производительность.
так что их рекламные слова ложью назвать нельзя, но они недоговаривают.
Они уже много лет честно об этом говорят. Просто читать надо, они всё пишут.
А вообще, я сам фанат .Net и C# в частности ) Очень приятная и эстетичная для разработчика среда)
И как оно? Неужто осталось желание писать ещё на чём-то? =) -
-
-
- it_romance
- 15.03.2009 6:32
- ↑
- →
Вы действительно говорите, как фанатик.
Как программист - я в восторге, а вот производительность - ниже плинтуса, много головной боли с этим.
Кстати, про стоимость хостинга - приведите, плс, ссылки на цены виндового хостинга, который по цене равен линуксовому. (очень надо) -
-
-
- eternal__here
- 15.03.2009 6:45
- ↑
- →
Вы действительно говорите, как фанатик.
Ок. А факты по сути вопроса есть?
Как программист - я в восторге, а вот производительность - ниже плинтуса, много головной боли с этим.
Поговорим об этом? Задайте вопрос, приведите пример. Давайте тогда рассмотрим конкретный случай, где производительность с# и .net подкачала.
Кстати, про стоимость хостинга - приведите, плс, ссылки на цены виндового хостинга, который по цене равен линуксовому. (очень надо)
http://masterhost.ru/service/hosting/virtual/main/win/
и сравнить с http://masterhost.ru/service/hosting/virtual/main/unix/
Годится? -
-
-
- it_romance
- 15.03.2009 7:02
- ↑
- →
По сути вопроса:
>>стандартная библиотека С++ гораздо легче по вызовам, поэтому эффективнее.
>Чушь.
Это был неконструктивный комментарий, Вы меня не убедили))
Насчет лишних проверок - они в принципе не могут быть убраны из кода в большом количестве случаев, поскольку входные данные недетерменированны.
возьмем, например, ситуацию, скажем, с запросом к базе данных через DataSet
Я как разработчик и администратор портала могу точно сказать, что вот конкретный запрос никогда-никогда не вернет ошибку. .NETу я это сообщить не могу, да он мне и не поверит. Потому что с его точки зрения, базы данных вообще может не быть - в этом месте всегда останется мусорный код и проверки. Еще такая вещь - этот класс (DataSet) скомпилирован и находится во фреймворке, каждый раз он не пересобирается - все вызовы, которые всплывают при отладке есть и в оптимизированной версии. А вызов функции - операция накладная. Я не верю, что они инлайнятся (а было бы здорово именно так с ними и поступить).
Про пример - ситуация примерно такая: делается выборка, скажем, на тысячу записей и выводится в браузер через GridView c TemplateField ами.
Предвариательно, чтобы шаблон правильно понял некторые параметры (конкретно - параметр Visible для Label внутри TemplateField) вся выборка прогоняется циклом и проставляется еще одно поле в DataTable.
Ситуация, в целом, вполне нормальная и решена максимально средствами .NET - т.е. именно так кажется наиболее логичным написать в .NET.
страница (одна) грузится примерно 5 секунд (на локалхосте). Когда у меня стояла примерно такая же задача(таблица на 1000 строк, одно из полей вычисляется) и я её решал на php - скорость загрузки страницы составляла около 2 секунд. -
-
-
- eternal__here
- 15.03.2009 7:22
- ↑
- →
Это был неконструктивный комментарий, Вы меня не убедили))
Куда по-Вашему уходят вызовы стандартных функций с++? Ответ, как не сложно догадаться, должен содержать название компилятора.
Про dataset... Да Вы такими темпами и smarty угробите. Всё использовать при критичных случаях надо с умом.
Абсолютно те же механизмы, что Вы использовали с PHP, Вы можете использовать с asp. Но разработка всё равно будет быстрее.
1000 строк? 2 секунды? Процессор 386-й? Или под Opera пробовали?
Сколько времени при этом была выборка из БД? Где узкое место, Вы посмотрели? -
-
-
- it_romance
- 15.03.2009 7:36
- ↑
- →
и там и там я уже занимался оптимизацией и смотрел узкие места, поэтому этот вопрос я не задаю)
я привел примеры. технических деталей в них довольно мало (например, для подсчета одного из полей в таблице (в php задаче) надо было каждый раз делать дополнительный sql-запрос).
по С++ - подозреваю, что код стандартных библиотек практически не зависит от компилятора. В с++ замена использования стандартной библиотеки прямыми вызовами функций ядра дает выигрыш всего 1-3%
.NET практически везде оперирует объектами своих же классов, все компилируется до байт-кода MSIL, который работает с framework, а framework для конкретной архитектуры уже работает с функциями ядра ОС. Получаем прослойку, от которой никуда не деться. Если сделать такую же прослойку на С++ - производительность .NET кода и того же кода на С++ сравняется. но изначально при программировании на С++ этой прослойки нет. -
-
-
- eternal__here
- 15.03.2009 7:48
- ↑
- →
Ну это лажово выглядит. Я, конечно, всех деталей задачи не знаю, но подзапросы надо было снести в единый SQL. И про индексы не забыть.
С с++ и библиотеками фишки есть. Ну Borland всегда базовые функции (strlen там) свои брал. Microsoft это же из ОС брал. Выигрыш больше по объёму дистрибутива конечного продукта.
MSIL дело не ограничивается. Здесь как раз важное отличие. IL по запросу или при первом запуске компилируется в машинные коды. Кстати, в отличие от убогого JIT Java или аналогичного PHP.
Так что прослойки-то особо нет. Избыточность некоторая может быть. Но сравните результат с Delphi и поцелуйте Билла Гейтса. Я лично видел, во что оно превращается в машинных кодах. Страх и ужас.
Всё. Спокойной ночи. -
-
-
- eternal__here
- 15.03.2009 9:01
- ↑
- →
1. Да. У PHP есть компилятор в промежуточный интерпретируемый код. Я с этим сравнивал. Там есть ещё пара вариантов, но всё существенно хуже чем у .net
2. Ну у Java сейчас несколько другая технология используется.
Про "схожесть" - у меня несколько другие данные. Всё схоже, но что-то развивается динамичнее. -
-
Но проблема в том, что практически любой вызов функции из framework порождает кучу внутренних вызовов и проверок, что накладывает свой отпечаток на производительность
Чушь.
ЭЭЭ А как по вашему там происходит проверка на наличие функций у классов. При первичном запуске пока код не весь скомпилирован в машинный каждый раз происходят проверки. В том числе и проверки на типы и прочее. что в C# что в Java.
стандартная библиотека С++ гораздо легче по вызовам, поэтому эффективнее.
Чушь.
Вот это я не тоже не понял почему чушь. Учитывая что что Java что .Net это дополнительные уровени надстройки над системой. Так что однозначно будет медленнее. Проверено.
А вообще, я сам фанат .Net и C# в частности ) Очень приятная и эстетичная для разработчика среда)
И как оно? Неужто осталось желание писать ещё на чём-то? =)
Не видной единой)) -
-
- eternal__here
- 15.03.2009 7:50
- ↑
- →
RTFM.
Спорить не буду. Просто Вам сюда: http://rsdn.ru
Ну и остальные ветки здесь почитать можно.
Удачи. -
-
Во-первых в спецификации не сказано когда, код будет компилироваться в нативный. Там вообще про это ничего не сказано. вто вторых рефлекшн, При котором мы ищем нужный метод, а его может не быть. В третьих при КАЖДОМ вызове будет проверяться тип класса, на котором вызывается этот метод и в зависомости от того вызываться нужный метод. Тем байткод и хорош, что в нем можно обпроверяться. Чем собственно виртуальная машина и занимается. Так что про одну проверку это вы погорячились. Если вы считаете, что я не прав, то, пожалуйста, пришлите ссылку на пункт спецификации.
-
Код компилируется в нативным перед первым вызовом. Других вариантов нет. Просто нет интерпретатора IL кода в .NET скажем.
Рефлекшен это просто набор метаданных в памяти с указателями. Никакой связи с прямым кодом нет.
Байткод существует до тех пор пока не нужно метод запустить. После чего он уже нативный целиком до следующего метода, который еще не прошел JIT.
Виртуальная машина ничем не занимается. Это просто термин такой. Реально просто подряд работает сгенеренный нативный код. К сожалению он не всегда такой эффективный какой хотелось бы. Но реально это проблема лишь такого минимума задач, что их все-равно должны решать те, кому не проблема написать на чем угодно.
В общем не знаю о какой спецификации идет речь. Политика работы JIT компилятора .NET в ECMA не записана. То о чем я говорю вполне задокументировано про .NET в MSDN. Достаточно читать. А работать за гугл не хочу. -
Ok, я не профи в дотнете. могу не знать.
Подозреваю что в дотнете может отсутствивать интерпретатор виду отсутствия переносимости. В переносимых языках которые исполняются виртуальной машиной он есть. Что Java что python.
В java используется технология динамической компиляции. То есть код компилируется в нативный по частям. В зависимости от режима виртуальной машины(серверная или клиентская) разные алгоритмы. -
Ну почему же - есть Mono, он переносим. Сделай JIT под платформу трудно. Насколько я знаю, в Яве сейчас почти не осталось платформ где используется интерпретатор. Python не содержит JIT, это просто довольно эффективный (самый быстрый) интерпретатор. Еще раз повторю - виртуальная машина всего-лишь термин, нет никакой прослойки ни у явы, ни у .net между непосредственно процессором и кодом. Разница в скорости только эффективность компиляторов. Даже самый эффективный интерпретатор Питона сливает на примитивных операциях в 10 и более раз .net/java/c++. Все JIT компиляторы динамические - они все компилируют код на лету кусками, могу перекомпилировать повторно и т.д. Режим виртуальной машины не более чем режим работы коллектора мусора - это не режим исполнения.
-
"Но проблема в том, что практически любой вызов функции из framework порождает кучу внутренних вызовов и проверок, что накладывает свой отпечаток на производительность (убедиться в этом можно в отладчике - заставьте системные функции выдавать исключения)."
1. Проверок безопасности в сгенеренном коде .net очень мало и там где надо. Еще есть работа GC, которая тоже вносит лепту, но тоже не большую (зато это управляемый язык без возможности утечек памяти).
2. Исключения в .NET относительно медленные по той простой причине, что либо исключения брошенные будут медленными (что вообще то часто не должно происходить), либо все остальное, либо вообще их не будет (как в большинстве других языков).
"Кроме этого в native C++ есть механизм указателей, который несет в себе много потенциальных проблем при разработке, но и несет возможность писать высокоэффективный код - потому что арифметика указателей преобразовываются в машинный код почти дословно (переводится напрямую в команды процессора без вызовов и проверок)."
Есть очень малое число задач выигрывающих от жонглирования с указателями. ОЧЕНЬ. Для таких случаев есть unsafe код в C#. В большинстве же случаев это не более чем ненужная игра, которая приводит к экспоненциальному росту числа багов и сложностей с развитием софта.
"А в том же .NET при адресации массива есть проверка на его границы и код для выброса исключения."
Нет, при работе с массивами используется масса оптимизаций, которые в подавляющем большинстве случаев делают число проверок меньше, чем программист указателей в С++.
"Исключения в .NET используются повсеместно, а они не очень эффективны сами по себе - появляется много лишнего машинного кода - проверка и генерация исключения."
Они КРАЙНЕ эффективны и медленны лишь если произошли. Во всех остальных случаях они стоят процессору 0. И механизм исключений это то, что позволяет писать и отлаживать код по человечески.
Вы очень мало работали с .NET и много наслушались тех, кто его в глаза не видел. -
-
- it_romance
- 15.03.2009 6:15
- ↑
- →
про .NET в веб-технологиях - они существенно расширяют обычный html своими надстройками, это подкупает, но формирование html+js кода для всех компонент накладно для сервера, поэтому злоупотребление богатейшими возможностями .NET приводит к повышению нагрузки на сервер и замедлению выдачи отдельной страницы. Самописные вещи (если писать прямыми руками) будут всегда эффективнее универсальных и автоматических.
Единственный высоконагруженный сайт на aspx, известный мне - это Microsoft.com и msdn, в частности. Большая часть aspx страниц, которые я видел - сильно тормозят.
т.к. предварительная компиляция кода в MSIL не учитывает особенности внешних условий, где будет сайт - нет возможности оптимизировать код и убрать лишние проверки, дополнительные возможности, генерацию html-кода.
неаккуратно написанный на .NET сайт способен сожрать все ресурсы очень мощного сервера уже на 20 соединениях. А на .NET сложно, но все-таки можно написать неаккуратно. -
-
-
- eternal__here
- 15.03.2009 7:41
- ↑
- →
формирование html+js кода для всех компонент накладно для сервера,
Ну всё-таки js на клиенте исполняется и его тогда уж "тормозит". А файлы, запрошенные с сервера, всё-таки кэшируются.
Единственный высоконагруженный сайт на aspx, известный мне - это Microsoft.com и msdn, в частности. Большая часть aspx страниц, которые я видел - сильно тормозят.
Специально проверил. У меня на посредственном канале ничего не тормозит. Давно там были?
Я, кстати, offline версию MSDN предпочитаю.
Ну и что данных там дофига выложено надо бы упомянуть.
т.к. предварительная компиляция кода в MSIL не учитывает особенности внешних условий, где будет сайт - нет возможности оптимизировать код и убрать лишние проверки, дополнительные возможности, генерацию html-кода.
Да это не важно. Т.е. не это важно. =)
неаккуратно написанный на .NET сайт способен сожрать все ресурсы очень мощного сервера уже на 20 соединениях. А на .NET сложно, но все-таки можно написать неаккуратно.
Есть примеры, где это не применимо? Не видели сайты на php, рушащие мощнейшие сервера? -
-
Ну вот полная ерунда если честно... Кривые приложения, написанные на PHP это 99% минимум всех PHP приложений. Включая самые распространенные CMS и форумы. Буде написанное идентичным кодом тоже самое на ASP просто работало бы в разы быстрее пока не уткнулось бы в кривую архитектуру, которой не поможет язык.
Присмотритесь - огромное число сайтов на ASP. PHP гораздо медленнее конечно. -
-
- eternal__here
- 15.03.2009 8:15
- ↑
- →
Ну ок. Пусть не в 10. Устроит?
10 - это скорей общий тренд, чем рассчитанное число.
В 10 - это типа максимум, при определённом сочетании условий.
Да и с "1000 раз круче и интересней" я тоже перегнул. Каюсь. =) Всего в 856 раз. =)
А можете и не читать. Придраться к одной цифре, которая явно не точна и поставлена для указания тренда - это Вам лечиться надо. От мании величия, например.
Факт есть факт: Java сдохнет. Даже JavaScript несколько ссохнется под влиянием разработок от Microsoft.
Я Вам по-дружески говорю: бросайте Вы это, программировать на жаве, скорей впрыгивайте в будущее. =)
Удачи. -
-
-
- eternal__here
- 15.03.2009 9:03
- ↑
- →
Ну и я всё правильно сказал, что 10 - это не точное рассчитанное число.
Я его взял из материалов нескольколетней давности. Java, естественно, сделала шаг вперёд.
Мы о чём спорим? -
-
Да не, не о чем. Я пытался лишь подсказать, что Java вовсе не ребенок для битья по сравнению с .NET. Вовсе.
Можно пинать Перл (к сожалению).
С натяжкой PHP (так как язык крайне популярен и прост для простых вещей).
Но не Яву (хотя ее популярность в вебе вообще мизерна при том, что asp отстает всего-то раза в 3). -
-
- eternal__here
- 15.03.2009 9:39
- ↑
- →
1. Согласен.
2. Не к сожалению, а поделом.
3. Средства разработки для PHP ужасны. Хороши для 2000-го года, но не для 2009-го.
4. Постепенно.
Заодно: http://www.rsdn.ru/article/devtools/perftest3.xml
Всё, конечно, относительно и субъективно, но всё же. -
-
Смешно блин. Вы про джаву видимо краем уха слышали, но не пытались программировать ни разу? Особенно радует в тысячу раз меньшее удобство разработки ))) Eclipse с Ant, svn и прочим, и прочим как бы тоже не дураки придумывали и используют. А если вы имели в виду логичность самого кода, то видимо джаву даже не видели?
Я не буду пытаться доказать, что джава круче .NET, что-то лучше реализовано там, что-то там. Программа на .net под виндой скорее всего в общем случае будет работать чуть быстрее, да и то не факт.
А как быть с кроссплатформенностью? Ждать еще лет 5 пока майкрософт все-таки либо захватит мир, либо выпустит фреймворк под другие платформы?
Про устаревшесть джавы особенно радует, сходите на java.sun.com чтоли, просветитесь. Про Java FX, кстати, слышали что-нибудь? -
-
- eternal__here
- 15.03.2009 20:12
- ↑
- →
1. Eclipse - говно по сравнению с VS. Для java Eclipse, конечно, лучше чем для php, но первое не отменяет.
И это не просто субъективное восприятие, это скорей факт.
2. Логичность самого кода, имхо, у c# несравненно лучше, чем у Java. Это, кстати, математически можно показать, просто сравнив ряд показателей, важных для разработчика.
3. Не дураки. Тот же Microsoft руку приложил, кстати.
4. Факт.
5. Погугли "Mono".
Да и нахуй unix и прочее подобное несусветное говно для извращенцев. =)
Это, конечно, уже элементы холивар, но сути не меняет. Unix в России отсасывает и будет дальше отсасывать, не смотря на все достижения.
6. Посмотрите аналогичные решения от Microsoft.
И не надо путать указание тенденций с результатами конкретных тестирований. Разумеется число типа 1000 - это не точное значение. -
-
1. На вкус и цвет... я когда-то считал что JBuilder лучшая IDE. Есть еще IDEA. Я так понимаю вы с ними не работали, какой же тогда это факт?
2. Примеры?
4. Примеры, не устаревшие на 7 лет?
5. А подумать про разные области применения? Различные embedded?
Хотя можно не отвечать, мнение "C# рулит, остальное - говно" ясно ) А спор ради спора неинтересен. -
-
- eternal__here
- 15.03.2009 20:36
- ↑
- →
1. Непосредственно с Eclipse работал. Многое остальное смотрел поверхностно.
5. Embedded лучше у .net, насколько я сталкивался.
Там есть пока ньюансы, но тенденцию я верную указал.
Только что, кстати, скачал пример с java.sun.com. Я вообще не настроен ругать java - довольно многое сделано по уму, хоть и отсасывает у c#.
Так вот это приложение мало того, что не закрылось по нажатию на крестик. Его пришлось снимать через диспетчер задач. И ещё каким-то непонятным мне способом оно похерило переключение раскладок. До этого и после перезагрузки всё нормально.
Так что тенденции я совершенно верные подметил, товарищ. -
-
-
- eternal__here
- 15.03.2009 9:38
- ↑
- →
2 раза по ряду тестов, кстати, устроит?
http://www.rsdn.ru/article/devtools/perftest3.xml
Я уж не говорю про сетевое взаимодействие.
Про "особенность" тестов можно не упомянать. Просто ссылки на тесты приводите, посмотрим. -
-
Ерунду пишете.
Java и .NET оба содержат равноценные на сегодня JIT компиляторы.
Однако грамотные программы на С++ с хорошим компилятором добиваются большей производительности за счет более компактного кода. Тем не менее идиотизм программистов легко перекрывает все достижения любых средств разработки, так что это мелочи. -
-
- crimeanelf
- 15.03.2009 5:39
- ↑
- →
X-Win по SSH мееееееееееееееееееееееееедленный. Графические окна открываются минутами. Можно как-нибудь ускорить процесс?
-
-
-
- crimeanelf
- 15.03.2009 5:47
- ↑
- →
1. Удалённо. По локалке всё "летает". :-/
2. На моём конце 2.1GHz, на сервере - не знаю. Но "тяжёлая" математика на сервере считается быстрее. -
-
Значит, завтык в сети. Ну, собственно, это и не странно, такие объемы графики передавать. Есть варианты со сжатием X-трафика, сам не пробовал, но гугль находит. Но вряд ли это на порядки поднимет скорость, то есть тормоза будут все равно. А обязательно ли именно пробрасывать иксовые программы по интернету? То есть какие задачи вы решаете? Возможно, существует более удобный вариант.
-
-
- crimeanelf
- 15.03.2009 6:00
- ↑
- →
Ну например сижу в пакете типа Матлаба и хочется построить график. Ну я не знаю, в окне 400 на 300 пикселей. Никакой экзотики.
Не, я могу, конечно, перебросить данные на свой ноут, просто вдруг можно проще. -
-
-
- crimeanelf
- 15.03.2009 6:11
- ↑
- →
Вах, какая программа!
Я-то по старинке пользуюсь ФАРом, а вот многим коллегам она, наверное, понравится. -
-
-
- it_romance
- 15.03.2009 5:51
- ↑
- →
Честно говоря, я не очень компетентен в данном вопросе. Ускорить процесс можно облегчением передаваемой графики - уменьшение разрешения экрана, меньше картинок - это облегчает канал.
насколько мне известно, они и так пытались оптимизировать насколько можно и работы продолжаются.
по факту - я радминю через мобильник иногда - медленно, но жить можно, если приспичит.
для линукса удаленно лучше использовать ssh, имхо. Хотя я не знаю, какие стоят задачи -
-
Плавали, знаем.
Ключевая проблема - именно время round-trip. Х11 передает очень много запросов, десятки и более в секунду обычно, поэтому для стабильной работы лучше иметь пинг < 1 мс.
Лучшее решение на практике - пользоваться Remote Desctop через SSH (ну, или в *nix-варианте — TightVNC и иже с ними). Если на сервер нельзя залогиниться по TightVNC - не беда, можно открыть для Remote Desctop свой рабочий компьютер, уходя оставить его включенным (предположительно он в одной локалке с сервером и тоже доступен по SSH), логиниться удаленно на него, а уже оттуда открывать сессию X11. Скорость интерфейса будет приемлемая даже не при очень толстом канале - Remote Desctop весьма неплохо оптимизирован.
Описанный подход не "теоретический", а основан на личном опыте и регулярно применяется :) -
Если общаться с сервером через рабочий комп, то ставить не нужно ничего, главные проблемы - оставить уходя свой комп включенным и потом добраться до него удаленно.
Логиниться же на сервер напрямую, скорее всего, технически сложнее, так как требует установки на сервер TightVNC.
Но все равно стоит обсудить с местным сисадмином оба варианта. -
-
- it_romance
- 15.03.2009 5:57
- ↑
- →
связаться с тех.подержкой вконтакта. обычно банят, когда один айпишник на подсеть у провайдера, а в подсети сидит бот или спамер.
какой провайдер?
Вообще, приличные сайты забаненным пользователям выдают объяснение, почему они забанены и что делать. может быть проблема не на стороне вконтакта.
PS. соц. сети - зло -
-
-
- it_romance
- 15.03.2009 7:06
- ↑
- →
будующее нейронных сетей я вижу интересным)
Если учесть, что есть процессоры (NM6403), которые нейросетевые вычисления поддерживают на уровне команд процессора )
Нейросетям и сейчас неплохо - во многих задачах они оправдали надежды и используются. мне самому интересна возможность для автоматического масштабирования нейронной сети при приближении к насыщению (в плане количества хранимой информации). Мне кажется, что это перспективная задача -
-
-
- it_romance
- 15.03.2009 7:38
- ↑
- →
ну да, тогда убунта - в самый раз.
Я рекомендую Kate - подсветка синтаксиса есть, свертка тегов есть - мне для html верстки обычно ничего больше и не надо.
в линуксе не особо много работал, поэтому более удобных решений никогда не искал.
Кстати, про верстку под линуксом - надо позаботиться установкой IE в убунту, чтобы верстку тестить. Это должно делаться с помощью wine. -
-
-
- crimeanelf
- 15.03.2009 14:42
- ↑
- →
Ещё. У меня тормозит Firefox на висте. То есть, раз в час он "замирает" секунд на 15. Что это? Как сделать, чтобы этого не было?
-
-
-
- it_romance
- 15.03.2009 16:48
- ↑
- →
я бы не использовал firefox.
если он это делает раз в час - то это неплохо) Подозреваю, что это связано с освобождением ресурсов. -
-
-
- minstrellll
- 15.03.2009 16:05
- ↑
- →
Карточка Cisco Aironet под седьмой фрей при обновлении портов и вообще нагрузке именно с сервака вылетает. В логах ничего нет. При обращении через ancontrol, например ancontrol -d 1 связь восстанавливается. Но на двадцатый раз пишет Operation not permitted. Во время вылета пингую карту - нехватка буфера. Увеличение NMBCLUSTERS и maxusers ничего не дало. Что это может быть? Очень хочется снести винду. Но эта трабла не дает покоя.
-
-
-
- minstrellll
- 15.03.2009 16:48
- ↑
- →
В следующую субботу попробую линукс поставить. Там драйвера поновее.
-
-
-
- it_romance
- 15.03.2009 16:47
- ↑
- →
не очень понял вопрос. выставить права - рекурсивно.
связь с поисковиками я не понял -
-
-
- danyastuff
- 15.03.2009 17:51
- ↑
- →
В таких необычных языках как Prolog есть модули, позволяющие работать с вебом (подробностей не знаю, но знакомый пытался увлекаться). Насколько все это распрастранено на практике. Если ли известные проекты, использующие Prolog.
Да и вообще, насколько логическое и функциональное программирование распрастранено в вебе? Есть ли у него будущее? -
-
-
- it_romance
- 16.03.2009 5:32
- ↑
- →
Практических применений я не знаю, я уверен, что будующего в вебе у него нет, потому что он не для этого создан и не для этого используется.
Тем не менее, на практически любом языке можно создавать веб-приложения. -
-
Как правильно развернуть самба-шару, чтобы на нее могли заходить адовые юзвери? Проблема в том, что в сети ваяется куча руководств для случая "адын домен", в моем же случае есть как минимум 3 леса в трастинге. Прописал для кербероса все домены, указал их DC - в RHEL5 часть доменов видится (юзвери авторизируются) часть - нет. Подставляю те же конфиги с центось - при вводе в домен пишет что днс не смог обновиться. Через какое-то время в рхеле начинают проявляться непрописанные домены с которыми трастинг, а явно прописанные так и не видятся. В общем требуется мощный бубен, но в сети нифига не нашел мануала на тему как же скрестить самбу со сложной многолесовой структурой =\ Вопрос стандартный - что делать, что и где почитать?
-
-
- it_romance
- 16.03.2009 5:32
- ↑
- →
Если будет работать и выполнять свои задачи - то ок. Если есть какие-то причины, которые оправдывают переход (например, не хочется платить за лицензию) - то ок.
С точки зрения закрепления пользователей (чтобы не могли сменить обслуживающую фирму) - то вообще замечательно))
Но я лично, будь я Вашим клиентам - попросил бы этого не делать. Это скорее психологический аспект) -
-
-
- it_romance
- 17.03.2009 1:03
- ↑
- →
Имеется в виду питон?
Будущее - несомненно есть. Я вокруг себя замечаю общую тенденцию к тому, что он нравится все большему количеству человек (профессионалов), а значит его так или иначе будут использовать, смерть ему в ближайшее время не грозит.
Но в веб-программировании, например, он явно не лидирует, большинство популярных готовых решений используют не его - в короткое время эта ситуация скорее всего не изменится.
Сам не использовал. -
