The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Почему администрирование серверов ключевых открытых проектов..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от opennews (??) on 09-Янв-10, 01:26 
Ланс Альбертсон (Lance Albertson) главный системный адмнистратор  лаборатории открытого кода университета штата Орегон (OSU Open Source Lab (http://osuosl.org/)) рассказал (http://searchdatacenter.stage.techtarget.com/news/article/0,289142,sid80_gci1378294,00.html) в интервью изданию techtarget.com о том, что большинство системных администраторов в его подчинении студенты возрастом от 18 до 21 года. Именно им поручается управление серверами ключевых открытых проектов, среди которых основной сайт распространения Linux ядра Kernel.org, сайты Linux Foundation, Apache Software Foundation, сообщества Drupal,  Mozilla Firefox, One Laptop Per Child, GNOME, PostgreSQL и еще 50 проектов.

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

URL: http://searchdatacenter.stage.techtarget.com/news/article/0,289142,sid80_gci1378294,00.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=24946

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от vitek (??) on 09-Янв-10, 01:26 
>Почему администрирование серверов ключевых открытых проектов поручают студентам

да ПАТАМУ ШТА за каждным студентом стоим профессор.
и это правльно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от vitek (??) on 09-Янв-10, 11:18 
>>Почему администрирование серверов ключевых открытых проектов поручают студентам
>
>да ПАТАМУ ШТА за каждным студентом стоим профессор.
>и это правльно.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

34. "Почему администрирование серверов ключевых открытых проектов..."  +4 +/
Сообщение от FSA (ok) on 09-Янв-10, 14:18 
Вспомнил анекдот по теме:
Пишет девушка:
- Я устроилась в одну крупную фирму бухгалтером. Мне тут ничего не объясняют. Я не знаю что делать. Подскажите!
- Сухарики суши.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

48. "Почему администрирование серверов ключевых открытых проектов..."  +4 +/
Сообщение от vitek (??) on 09-Янв-10, 21:21 
именно так.
сколько раз уже при автоматизации производства/торговли такое видел - "ща мы студентов наймём и они нам всё за 3 копейки сделают".
ага! счаз! каждые два месяца увольняется такой админ/ы. а вслед за ним (раз в 4 месяца) и главбух (патаму шо писец пришел).
с другой стороны, сколько раз уже себе персонал брал - только бы глаза горели и дебилом бы не был. остальному научим. и отлично получается.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Аноним (??) on 09-Янв-10, 01:56 
постоянный приток свежей крови. умно
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от Аспирант on 09-Янв-10, 02:08 
А ещё студенты врубаются во всё намного быстрее.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Почему администрирование серверов ключевых открытых проектов..."  –1 +/
Сообщение от vitek (??) on 09-Янв-10, 11:21 
это когда есть у кого спросить. посоветоваться.
это когда кто-то уже намучался и изобрёл то, во что можно/надо "врубаться".

а так оно конечно да. вообще до 6 лет ребёнок узнаёт 80% слов.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Почему администрирование серверов ключевых открытых проектов..."  –2 +/
Сообщение от sHaggY_caT (ok) on 09-Янв-10, 02:24 
>и в ближайшее время планируется миграция на Puppet

Заметно, что puppet в последнее время стал все чаще появляться в новостях. Пока еще каждый IT-к не знает, что это "наш ответ <s>Чемберлену</s> групповым политикам AD", но многие уже интересуются...

Кстати, у него все-таки есть недостатки: мне, например, очень не нравится, что в "декларативном языке" by design нельзя нормально переназначить переменную: если инклюдим класс, в которой она объявлена, то все, в этом классе мы ничего уже не сможем сделать :(
Вот эта борьба за "чистоту кода" уже немного отдает фанатизмом, конечно, что goto зло я согласна (и что его не зря убрали из облюбованного быдло-кодерами PHP), но это уже перебор :(
Приходится изобретать костыли в виде еще одной переменной-селектора или дефиниций внутри классов, так же немного удручают возможности по работе с массивами.

Как кто обходит эти и другие проблемы?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Кай on 09-Янв-10, 06:08 
Я в puppet не силен и так и не понял, как я могу объединить несколько компьютеров в группу. Подскажете?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от sHaggY_caT (ok) on 09-Янв-10, 12:17 
>Я в puppet не силен и так и не понял, как я
>могу объединить несколько компьютеров в группу. Подскажете?

modules -/
        -/mod_apache
           -/manifests
=====init.pp====     <<<<=== в этом модуле описываем логику поведения Apache
class webserver {

file {"httpd.conf":  
operationsystem => ? { <<<<=== забираем с файлсервера паппета файл с настройками либо центоси, либо дебиана
Centos => "/etc/httpd/httpd.conf",
Debian => "/etc/apache2/apache.conf",
<...> }
source => [
"puppet:///mod_apache/httpd.conf",
"puppet:///mod_apache/apache2.conf",
],
notify => Service ["Apache"],
}

<...>  <<===где-то тут кучка кода, описывающая виртуальные хосты,пхп, SystemV сценарий и пр.
}

====site.pp, который описан в puppet.conf=====

class role_webserver {
import "mod_apache"
include webserver
include modphp

import "mod_mysql"
include mysql

import "mod_system_tools"
include smarmontools
include nagiosclient
include blah-blah-blah
<...>

}


node 'webserver01.int.corporatedomain.tld' {
include role_webserver

webserver::virtualhost {"customer1.tld":  <<<<== описано где-то в апачном модуле
ensure => "enabled",
phpmode => "enabled",
ovverride => "enabled",
}

webserver::virtualhost {"customer2.tld":
ensure => "enabled",
phpmode => "enabled",
ovverride => "disibled",
}

}

node 'webserver01.int.corporatedomain.tld' {  
include role_webserver

webserver::virtualhost {"customer3.tld":
ensure => "enabled",
phpmode => "disabled",
ovverride => "enabled",
}
}

node 'monitoring.infra.int.corporatedomain.tld' {
include role_nagios
<blah-blah-blah>

}


Вот Вам пример простенькой инфраструктуры. Часть ее описана где-то за пределами этого текста :) Написано на коленке за пару минут, синтаксической верности не должно быть, даже если убрать блах-блах (вряд ли скомпилится).

Если хотите, пишите inbox __ at ___ shaggycat.ru -<<<добавить посередине дефис, это что бы спам-ботов обмануть >>

Отвечу на вопросы, если таковые возникают (при условии, что большую часть времени будете думать все-таки сами, и сами читать документацию)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от _umka_ (??) on 09-Янв-10, 09:10 
Please read «О вреде оператора GOTO» (GOTO considered harmful) - Дейкстры.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "Почему администрирование серверов ключевых открытых проектов..."  –1 +/
Сообщение от sHaggY_caT (ok) on 09-Янв-10, 12:24 
>Please read «О вреде оператора GOTO» (GOTO considered harmful) - Дейкстры.

Обязательно прочитаю, когда доберусь до того, что бы по-настоящему разобраться с C/C++, спасибо.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Почему администрирование серверов ключевых открытых проектов..."  +4 +/
Сообщение от vitek (??) on 09-Янв-10, 11:26 
зло не в goto, а в том как его иногда применяют.
вообще-то в машинный код все команды ветвления так или иначе преобразуются в ту или иную вариацию goto - это Вам скажет любой, кто программировал на ассемблере.
(кстати, вот реальная польза от изучения ассемблера - как не надо использовать goto. а про работу стеков, сегментов, да и вообще адресации - незаменим)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "Почему администрирование серверов ключевых открытых проектов..."  –2 +/
Сообщение от sHaggY_caT (ok) on 09-Янв-10, 12:26 
>зло не в goto, а в том как его иногда применяют.
>вообще-то в машинный код все команды ветвления так или иначе преобразуются в
>ту или иную вариацию goto - это Вам скажет любой, кто
>программировал на ассемблере.
>(кстати, вот реальная польза от изучения ассемблера - как не надо использовать
>goto. а про работу стеков, сегментов, да и вообще адресации -
>незаменим)

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Free_Nice on 09-Янв-10, 13:08 
Оо, рекурсии, структуры
Все это на смех курам
Когда пред вами встанут коды
Всплывут утраченные годы
;)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

36. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от User294 (ok) on 09-Янв-10, 15:17 
> Может быть, но я в ассемблере пока разбираться не планировала

Тем не менее, у большинства процессоров есть команда "безсуловного перехода" - нечто типа JMP [адрес]. Влобовую прописывающий процу что брать следующую команду - вон там. Собссно это ваше goto и есть :). Процы так работают и стесняться этого факта - странно. Другое дело что читабельность и структурированность кода оно портит. Поэтому  юзать его по возможности и правда не надо. Но иногда - видно как чтобы не пользоваться goto сгорожено пять этажей таких невменяемых костылей что лучше б уж поюзали одно goto...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

38. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от xxx (??) on 09-Янв-10, 16:10 
>Но иногда - видно как чтобы не
>пользоваться goto сгорожено пять этажей таких невменяемых костылей что лучше б
>уж поюзали одно goto...

Вот-вот, сам сталкивался с таким. Городил костыли, а потом вспомнил, что есть goto - всё стало прозрачно и красиво. Но самое интересное, показываю код коллеге, он бегло осматривает его и восклицает: "ОЛОЛО!!! WTF?! Это же goto, ты что не знаешь, что goto - ЗЛО?". Объяснить почему goto зло, он так и не смог, всё ссылался на авторов мега книжек по программированию.  Вообще возникает ощущение, что дурная слава о goto пошла от людей которые застали первые высокоуровневые языки с бедными управляющими конструкциями. Например как в ранних версиях БЕЙСИКа, где небыло нормальных процедур и все делали 100 goto 1000.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

42. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Vitaly_loki (ok) on 09-Янв-10, 19:17 
Ну User294 прав - goto это то, что процы называют JPM. Насчет использования, есть случаи когда оно действительно оправдано (выход сразу из нескольких вложенных циклов, например). Кроме того оператор switch в ANSI C есть ничто иное как одна из разновидностей goto (переход к метке)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

45. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Ъ on 09-Янв-10, 20:27 
>Ну User294 прав - goto это то, что процы называют JPM. Насчет
>использования, есть случаи когда оно действительно оправдано (выход сразу из нескольких
>вложенных циклов, например). Кроме того оператор switch в ANSI C есть
>ничто иное как одна из разновидностей goto (переход к метке)

А вот break это точно оно(замаскированное goto).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

118. "Почему администрирование серверов ключевых открытых проектов..."  –1 +/
Сообщение от Belov Sergey email(ok) on 12-Янв-10, 00:23 
Выход из нескольких вложенных циклов не всегда бывает корректен. Допустим ситуацию, когда у некого компилятора некого языка каждый цикл что-то сохраняет в стеке. Тогда кто очистит стек при GoTo?
Кстати, выход из сразу нескольких вложенных циклов часто означает неправильную организацию программы.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

50. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от Ъ on 09-Янв-10, 22:16 
>Объяснить почему goto зло, он так и не смог, всё ссылался на авторов мега книжек по программированию.

Если отвлечься от теоретиков и вспомнить практику, как это было...

Раньше в основном goto это и было jmp  (в нынешнем понятии short jmp), т.е. преход был ограничен 128 байтами.  
Представьте что вы написали код и этот код работает, а потом спустя какое-то время вас просят внести дополнение в код своей программы вы вставляете дополнительный код и получаете неработоспособное приложение хотя вроде бы логика и синтаксис нигде не были нарушены, а разгадка неработоспособности вашего кода в этом самом ограничение перхода в jmp, переход просто перестает работать.

Разобравшись у вас есть два выхода или вынести неработоспособный код  в отдельную подпрограмму или сделать грубый хак вставив еще одну промежуточную инструкцию jmp/goto.

Отсюда и растут ноги о том что goto сильно запутывает код.

Поэтому "наевшись" такого вы в следующий раз вынесите этот код в подпрограмму и будете вызывать его методом call/retr  и советовать никогда не использовать jmp/goto.

Сейчас уже коротких переходов jmp в природе нет (если только вы явно не укажите это), но слава goto как инструкции мешающей понятию кода осталась.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

64. "Почему администрирование серверов ключевых открытых проектов..."  +2 +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 05:54 
вообще-то были и short jmp (2 байта, переход на -128/+127 байт), и был long jmp (4 байта). short jmp был предпочтителен поскольку 8086 выбирал два байта из очереди за такт (8088 один байт). Что касается размерности jmp, то ещё дремучий tasm сам мог посмотреть кто куда переходит и выбрать соотв. размер. Правда если переход был вперёд, то он выделял 4 байта и если нужен short jmp, то остальное забивал nop-ами (ограничение однопроходного компилятора).

goto вообще незаменим в языках в которых отсутсвует поддержка конструкций аля try/finally (например в C), для обработки ошибок и организации единой точки выхода и гарантированного освобождения ресурсов.

> Отсюда и растут ноги о том что goto сильно запутывает код.

Вы вообще goto пользовали в жизни? Проблема с goto в том что в неумелых руках он действительно приводит к запутыванию кода, но не из-за какого-то мифического jump-а, а потому что он не поддаётся заключению в какие-то рамки, что усложняет восприятие. Все циклические конструкции (for, while, until) имеют определённые ограничения, одну точку входа и одну точку выхода, что позволяет делать код линейным. Goto же нарушает эту линейность в большинстве случаев, за что его и не любят.

> Сейчас уже коротких переходов jmp в природе нет

Та ну, всё есть. Зачем выбрасывать такой короткий jmp который зачастую будет происходить в рамках соседних адресов и с большей долей вероятности попадёт в кеш.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

74. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от Ъ on 10-Янв-10, 09:06 
>вообще-то были и short jmp (2 байта, переход на -128/+127 байт), и был long jmp (4 байта).

В машинных кодах это выглядело как EB FF , где EB собственно jmp, а FF 7 бит адрес перехода и 1 бит на направление.

>Что касается размерности jmp, то ещё дремучий tasm сам мог посмотреть кто куда переходит и выбрать соотв. размер.

tasm мог, правда с версии большей двух, а как бы Дейкстра писал свою статью за более чем 20 лет до этого, задолго до 8086, задолго до tasm, задолго до DOS.  Я таки в те времена уже пописывал на асме, так что примеры я привел из собственного опыта.

>Проблема с goto в том что в неумелых руках он действительно приводит к запутыванию кода, но не из-за какого-то мифического jump-а

он не мифический jump, goto это и есть jump (jmp)

>Вы вообще goto пользовали в жизни?

Да. И сейчас использую.

>> Сейчас уже коротких переходов jmp в природе нет
>Та ну, всё есть.

Чё вы тут хотели сказать оборвав мою фразу по середине? Да есть, но по умолчанию short jmp не происходит как раньше, нужно явно указывать.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

84. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 13:06 
>>вообще-то были и short jmp (2 байта, переход на -128/+127 байт), и был long jmp (4 байта).
>В машинных кодах это выглядело как EB FF , где EB собственно
>jmp, а FF 7 бит адрес перехода и 1 бит на
>направление.

вообще-то FF это -1 в дополнительном коде, а не то что вы написали.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

90. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Ъ on 10-Янв-10, 18:52 
>вообще-то FF это -1 в дополнительном коде, а не то что вы написали.

А что я написал? Это к чему вообще?  

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

91. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Ъ on 10-Янв-10, 19:15 
>вообще-то были и short jmp (2 байта, переход на -128/+127 байт)

А всё понятно... Вы ошиблись, 2 байта это near jmp (-32767 / +32768), а вот 1 байт это short jmp (+-127).  

Поэтому jmp раньше частенько приводило к ошибкам вроде:  Relative jump out of range by 5 bytes, собственно про это и пишет Дейкстра, без знания этого факта, его статья становится не понятной.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

97. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 21:22 
>>вообще-то были и short jmp (2 байта, переход на -128/+127 байт)
>
>А всё понятно... Вы ошиблись, 2 байта это near jmp (-32767 /
>+32768), а вот 1 байт это short jmp (+-127).

инструкция jmp short занимает два байта.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

44. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Ъ on 09-Янв-10, 20:25 
>Тем не менее, у большинства процессоров есть команда "безсуловного перехода" - нечто типа JMP [адрес].

Мне goto больше не на ассемблере а в машинных кодах нравится, для x86 звучит как "EB"+"адрес_перехода".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

49. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от vitek (??) on 09-Янв-10, 22:11 
с goto вообще интересная история. Вы думаете его из-за не_читабильности кода попёрли?
если так, то Вы не правы.
это опять работа маркетологов. дело в том, что на западе кодеры - это работники без высшего образования. с высшим там только архитекторы и etc.
и вот, кто-то из самых умных маркетологов посчитал, что для успешного освоения языка программирования за 2-3 месяца в нём должно быть менее 30 (или около того, сейчас уже не помню) различных конструкций и т.д. он даже стоимость владения для предприятий подсчитал. жабу (!!!) заброкавал.
и понеслась... а что можно относительно безболезненно выкинуть практически из любого языка?
правильно, goto первый (и практически единственный :-D) кандидат.
забавно, что эти маркетологи не понимают, что знание библиотек, технологий и т.д. - вот где сила спеца того или иного языка программирования.
но в чём то он тоже прав конечно. перегруженность языка - это уже другая крайность. вот перл например. хоть и использую его порой. и даже нравиться. :-D
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

51. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Vitaly_loki (ok) on 09-Янв-10, 22:24 
Глубоко извиняюсь, но я думаю тут вы не правы... Публичное порекание goto высказал Дейкстра, было это за долго до появления Java (1968г), но есть мнение, что даже до Эдсгера уже от данного оператора отказывались. У меня, к примеру, есть "Язык программирования Си" авторов K&R 2008г издания, но ориинал 1978. И там то же самое написано - goto нежелателен.

> Вы думаете его из-за не_читабильности кода попёрли?

Дейкстру то почитайте все-таки, ни слова там о маркетологах

И таки тогда то как раз программисты были все с высочайшим образованием.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

59. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от vitek (??) on 09-Янв-10, 23:38 
возможно. я слышал/читал именно такую версию. и судя по тому как на goto накинулись (что характерно, не в 78 году) - это именно так.
лично мне его присутствия не мешает (по крайней мере я точно знаю во что он транслируется и с какой скоростью выполняется), а вот его отсутствие раздражает (я сам хочу выбирать что мне использовать, а что нет).
>У меня, к примеру, есть "Язык программирования Си" авторов K&R 2008г издания, но ориинал 1978. И там то же самое написано - goto нежелателен.

у меня к примеру тоже. и что?
на мыль не наводит тот факт, что в стандарте С он всё-таки есть?
>Дейкстру то почитайте все-таки, ни слова там о маркетологах

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

глупости. просто процент быдло_кодер/не_быдло_кодер был гораздо меньше, а в абсолютных величинах не_быдло_кодеров стало гораздо больше.
опять же, удешевлению обязаны маркетологам.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

63. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Vitaly_loki (ok) on 10-Янв-10, 01:06 
Да все верно, мне он тоже не мешает.. Более того я считаю отсутствие goto недостатком языка, потому что он не позволяет сделать "машинный безусловный переход", к-й сплошь и рядом в машинных коммандах. Просто пользоваться надо им умело, вот и все. Я всего лишь сделал предположение, что GOTO начали хаить задолго до "маркетологизации" IT-мира..

Ведь таким же образом давным-давно считалось, что и указатели зло (этот факт, кстати, упоминается и в K&R), что они способствуют запутыванию кода и т.д. Но один фиг после компиляции процессор оперирует адресной арифметикой, поэтому от указателей тоже было бы некорректно избавляться. Ведь указатель на объект или переменную соответстует машинному адресу этого объекта. И хороши те языки, где есть указатели. И хороши те языки, где есть goto, поскольку это не плохой стиль, а особенность работы CPU. Повторюсь - пользоваться надо просто правильно. Кстати, в Java насколько я помню и указателей тоже нет.

Мой пост относился только к причине, по к-й GOTO стал порицаем. Маркетологи по вашему мнениею. Только в этом я не согласен :-) Я считаю из академических кругов это пошло (тот же Дейкстра) :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

65. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 06:00 
> Ведь таким же образом давным-давно считалось, что и указатели зло

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

> Кстати, в Java насколько я помню и указателей тоже нет.

Всё там есть, только вам не дают ими манипулировать, что позволило искоренить целый класс проблем. А так всё есть, и передача by ref и by value, и boxing/unboxing, всё есть.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

67. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Vitaly_loki (ok) on 10-Янв-10, 06:11 
>И правильно считают. Одно дело когда указателями крутит вертит компилятор, который в
>общем резиновый, другое дело когда это делает человек у которого в
>голове стопицот мыслей.

Ну дак и вывод какой? Запрет "указателей и goto" - это "защита от дураков" (никого не имею ввиду, это метафора). По сути что означают эти запреты?, - невозможность в языке вызвать ту или иную инструцию процессора. Сами то инструкции в процессоре остаются, никуда не пропадают. То бишь намеренное ограничение функциональности компилятора, кастрация. :)

Вообшем не могу согласиться с вами. Как минимум передача указателя функции, например, с последующей манипуляцией этого указателя внутри функции. Как это сделать без оного? Примеров можно дофига привести полезности указателей.

>Всё там есть, только вам не дают ими манипулировать, что позволило искоренить
>целый класс проблем. А так всё есть, и передача by ref
>и by value, и boxing/unboxing, всё есть.

Ну тут я допускал, что ошибаюсь - оказалось не зря. Прошу прощения

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

68. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 06:27 
>Ну дак и вывод какой? Запрет "указателей и goto" - это "защита
>от дураков" (никого не имею ввиду, это метафора). По сути что
>означают эти запреты?, - невозможность в языке вызвать ту или иную
>инструцию процессора. Сами то инструкции в процессоре остаются, никуда не пропадают.
>То бишь намеренное ограничение функциональности компилятора, кастрация. :)

Запрет goto это всё же защита от дурака. А вот переход на управляемую модель памяти и упрятывание указателей - это решение целого класса проблем которые доставили немало головной боли. При этом, смею заметить, это не значит запрет на определённые инструкции. Если вам нужен блок памяти - выделите себе byte[] и работайте с ним. Вся адресная арифметика здесь присутствует, разве что base address вы не задаёте, а так вызов через sib и никаких проблем.

>Вообшем не могу согласиться с вами. Как минимум передача указателя функции, например.
>Как это сделать без оного? Примеров можно дофига привести полезности указателей.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

69. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Vitaly_loki (ok) on 10-Янв-10, 06:36 
>только вам к ним доступа не дают, чтобы дров не
>наломали.

Ну а если я осознаю всю опасность и последствия этого действия? :) Все равно нельзя ведь манипулировать поинтерами, правильно? :) Получается так же "защита" :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

70. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 06:44 
>>только вам к ним доступа не дают, чтобы дров не
>>наломали.
>Ну а если я осознаю всю опасность и последствия этого действия? :)
>Все равно нельзя ведь манипулировать поинтерами, правильно? :) Получается так же
>"защита" :)

Вы лучше скажите зачем вам манипулировать поинтерами? Для связи с unmanaged кодом языки имеют удобные (более-менее) средства для указания что и как передавать. Наружу уйдёт указатель куда нужно и всё такое.

PS А манипулировать указателями можно, если сильно хочется (правда непонятно зачем). В .net есть т.н. unsafe код, там уже можно делать всё что угодно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

73. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от vitek (??) on 10-Янв-10, 08:37 
вот когда на сишарпе будут к эмэсовскому ведру (с линуховым надеюсь такая беда не произойдёт) патчи/дрова принимать, тогда и зададите свой вопрос.
зы:
не всем нужен якобы мэнэджет код. некоторым нужны и с/с++. а ещё большим просто с. и ассемблерные вставки. и метки к ним.
ззы:
не нужно делать мой выбор за меня. если мне не нужен будет гоуту, то я не буду им пользоваться. и буду если будет нужен.
тоже самое с адресной арифметикой.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

81. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 12:38 
>вот когда на сишарпе будут к эмэсовскому ведру (с линуховым надеюсь такая
>беда не произойдёт) патчи/дрова принимать, тогда и зададите свой вопрос.

Нет, я серьёзно. Вот пишите вы прикладное приложение (для чего и предназначен тот же .net и питон). Зачем вам там указатели?

>зы:
>не всем нужен якобы мэнэджет код. некоторым нужны и с/с++.

Глядя на взрывной рост популярности питона, ню-ню.

>а ещё
>большим просто с. и ассемблерные вставки. и метки к ним.

Ассемблер это вообще из разряда фантастики.

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

Да как хотите, кто ж вам запрещает то.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

86. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от dq0s4y71 (??) on 10-Янв-10, 17:10 
>Запрет goto это всё же защита от дурака.

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

>Вы лучше скажите зачем вам манипулировать поинтерами?

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

>Глядя на взрывной рост популярности питона, ню-ню.

Да нет никакого "взрывного роста популярности Питона". Посмотрите _любой_ обзор популярности языков - как были С[++] и Java на первом месте - и _в_разы_ популярнее Питона - так и остаются.

>Ассемблер это вообще из разряда фантастики.

В ассемблере нет ничего фантастического, я вас уверяю. Расширяйте свой программистский кругозор, и такая прозаическая вещь, как ассемблер не будет казаться вам фантастикой.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

87. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 17:21 
>>Вы лучше скажите зачем вам манипулировать поинтерами?
>Вы придуриваетесь или вы в самом деле не знаете, что существуют какие-то
>виды программирования кроме прикладного?

Конечно не знаю.

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

Вам не кажется что это всё же более нишевые отрасли?

>>Ассемблер это вообще из разряда фантастики.
>В ассемблере нет ничего фантастического, я вас уверяю. Расширяйте свой программистский кругозор,
>и такая прозаическая вещь, как ассемблер не будет казаться вам фантастикой.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

88. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Vitaly_loki (ok) on 10-Янв-10, 17:40 
Алексей, я все же считаю, что вы не совсем правы. Не лучше ли, например, научиться правильно работать с указателями, оперировать им и т.д., вместо "тупого" запрета в лоб этих возможностей? Т.е. получается, что авторы языка считают, что все программисты обязательно "наломают дров" независимо от их уровня? Кардинально конечно это.. запретить фичу какую-то, вместо того чтобы научиться правильно ей пользоваться )) Насчет примера с манипуляцией поинтерами - я в свободное время пишу шутер от первого лица на опен сорс движке (движок сам использует OpenGL и написан на голом С++). Дак вот там часто приходится оперировать объектами через указатели.. Ну не копировать же их в самом деле? Они зачастую огромные быывают (текстуры, модели, например). Тем более в самом API движка это поощряется, и не надо писать что это значит движок плохой - движок отличный, автор профессор из Массачусетса.

Насчет .NET, на офф-топике и для офф-топика не пишу

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

89. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 18:14 
>Алексей, я все же считаю, что вы не совсем правы.

В интеренете всегка кто-то не прав :)

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

Это утопия и такого никогда не будет. Дешевле сделать горловину у мясорубки достаточно высокой чтобы рука не доставала до шнека (он же так называется?) чем учить каждого не совать руки.

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

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

>Кардинально конечно это.. запретить фичу какую-то, вместо того чтобы научиться
>правильно ей пользоваться )) Насчет примера с манипуляцией поинтерами - я
>в свободное время пишу шутер от первого лица на опен сорс
>движке (движок сам использует OpenGL и написан на голом С++). Дак
>вот там часто приходится оперировать объектами через указатели.. Ну не копировать
>же их в самом деле? Они зачастую огромные быывают (текстуры, модели,
>например). Тем более в самом API движка это поощряется, и не
>надо писать что это значит движок плохой - движок отличный, автор
>профессор из Массачусетса.

Ещё раз. В managed языках указатели никуда не делись, просто у вас отобрали адресную арифметику и взамен дали безопасные типы. Был char*, стал string, был T[], стал vector<T> или List<T> или T[], был void*/char* - стал byte[]. Вам нужно передать указатель, так передаёте соотв. ссылочный тип (object). Необходимо передавать значение - передаёте сущности соотв. типа (struct). Просто в случае interop-а компилятор с помощью ваших подсказок догадается как корректно передать соотв. тип дальше и что с ним делать.

>Насчет .NET, на офф-топике и для офф-топика не пишу

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

98. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от dq0s4y71 (??) on 10-Янв-10, 22:00 
>Смысл в следующем - если инструмент опасен, то его нужно заменить на
>аналогичный, но безопасный.

Все, кто так говорят, обычно забывают, что повышение безопасности всегда достигается за счет ограничения возможностей. Тому, кто пишет на дотнете "Hello world", это, конечно, не помешает, но существует программирование и за пределами дотнета. Я использую указатели не потому, что они мне так нравятся, а потому, что они - единственная возможность запихать программу на языке высокого уровня в мобильное устройство с 8 Кб ПЗУ и 1 Кб ОЗУ. Сможете ли вы впихнуть в такое устройство программу на "безопасном" языке?

>Ещё раз. В managed языках указатели никуда не делись, просто у вас отобрали адресную арифметику и взамен дали безопасные типы. Был char*, стал string, был T[], стал vector<T> или List<T> или T[], был void*/char* - стал byte[]. Вам нужно передать указатель, так передаёте соотв. ссылочный тип (object). Необходимо передавать значение - передаёте сущности соотв. типа (struct). Просто в случае interop-а компилятор с помощью ваших подсказок догадается как корректно передать соотв. тип дальше и что с ним делать.

Заменяя эти типы на "безопасные", вы лишаете их части функциональности. Например, char * - это не только строка. С помощью такого указателя вы можете, например, получить доступ к отдельным байтам блока двоичных данных, быстро извлечь битовые значения и т.п. В Питоне сделать это исключительно средствами языка, не прибегая к библиотечным функциям, просто невозможно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

103. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 23:01 
>Заменяя эти типы на "безопасные", вы лишаете их части функциональности. Например, char
>* - это не только строка. С помощью такого указателя вы
>можете, например, получить доступ к отдельным байтам блока двоичных данных, быстро
>извлечь битовые значения и т.п. В Питоне сделать это исключительно средствами
>языка, не прибегая к библиотечным функциям, просто невозможно.

var blob = new byte[20] ;
var elem = blob[10] ;

к битам сами достучитесь.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

111. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от dq0s4y71 (??) on 11-Янв-10, 11:49 
f(void * p) {
long x = *(long*)&((char*)p)[5];

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

100. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от User294 (ok) on 10-Янв-10, 22:38 
>не нравится .net, возьмите жаву или питон или что-то другое где есть
>автоматическое управление памятью.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

102. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от jxrjmsxovbb (ok) on 10-Янв-10, 22:51 
>Отличный рецепт как написать угробищную тормозилку стартующую полчаса и\или жрущую ресурсы.
>Шли б такие програмеры в свою виндозу с ее дотнетами, а?
>А то среди вашего тормозного говна нормальные программы искать приходится, знаете ли.

По части ресурсоемкости полезно сравнить в доску открытый Open Office на сях и "тормозное говно", как вы выразились, Microsoft Office 2010.
Даже не обращая внимания на функциональность, только сравнивая время запуска

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

104. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от User294 (ok) on 10-Янв-10, 23:06 
>и "тормозное говно", как вы выразились, Microsoft Office 2010.

Насчет 2010 не знаю а 2007 память жрет так что потом по минуте переключается между вордом, аутглюком и экселем. На машинах с 2-4 ядра, 4-8 гиг оперативы и прочая. Тоже мне пример скорострельной программы, ага. И кстати если вы не знали - тормозной код можно написать даже на асме. Просто стараться больше придется - там в 3 раза на ровном месте никто за вас ваш код не притормозит вагоном левых действий в тугих циклах. Придется самому дописывать тормозилки :). Ну и ессно никто не запрещает реализовывать алгоритмы неоптимально. Знаете, поиск в hash-таблице с 100 000 000 записей даже на яве таки уделает линейный перебор массива в 100 000 000 элементов на асме. Потому что выигрыш в 3  раза не скомпенсирует тупой алгоритм с перебором 100 000 000 элементов влобовую. Весь вопрос только в том что будет когда один и тот же алгоритм реализован на разных языках. А вот тут то мы и видим слив раза так в 3 по скорости и дикий выжирон памяти. Чудес не бывает - если есть лишние действия по собственно управлению кодом - они есть. Можно тасовать факты как угодно, но лишние действия от этого никуда не пропадут.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

105. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от jxrjmsxovbb (ok) on 10-Янв-10, 23:30 
>Насчет 2010 не знаю

проверьте. это бесплатно на время бета-тестирования.

>Тоже мне пример скорострельной программы, ага

да, проверите сами. "тормозной" .net и wpf
прозреваю когнитивный диссонанс

после запуска приложения можно остановить службу проверки лицензии (sc stop osppsvc) для пущей убедительности. всё-таки лишний десяток метров оперативы

>если есть лишние действия по собственно управлению кодом

а если их нет или они минимизированы? если управляемая модели используется в основном для верификации? код на "управляемых" языках может компилироваться в инструкции процессора, а код на сях - интерпретироваться. похоже, даже по прошествии десятилетий это для многих остается сюрпризом.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

108. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от User294 (ok) on 11-Янв-10, 02:33 
>проверьте. это бесплатно на время бета-тестирования.

Простите, но задарма я бетатестирую только то что по кайфу. Мсофис - весьма уродская софтина на мое мнение. Как минимум 2007 был настолько ж... что никакого желания юзать что либо в таком же духе я не испытываю. Штуки три неконсистентных интерфейса, и память выжирается в системе некисло, так что винда натужно хрустит свопом. Почему-то в пингвине, при переключении между опенофисом, браузером, почтовиком и чем там блин еще - ничего свопом не хрустит. На таком же 2-4 ядернике с такой же кучей гигзов. Странно. Как по мне - нехай MS сам кушает свой дотнет.

>да, проверите сами.

Да, давайте, проверим: а забенчите нам *одинаковый* алгоритм на этом вашем скоростном дотнете и сях, вот тогда и посмотрим. Вот например quicklz.org - либа нацеленная на скорость. Писаная на сях, дотнете и яве. Почему-то дотнет и ява сливают в ~три раза сям. И чего б это они? Наверное, подлые авторы этой либы специально поганили код на яве и дотнете. И кстати а чойта на ресурсах по алгоритмам сжатия народ советует тем кто изучает алгоритмы выбрасывать дотнет нафиг и юзать плюсы и народ потом фигеет от разницы в скорости? :)  

>"тормозной" .net и wpf

Вы прикиньте, я еще не видел ни 1 программы на дотнете время старта которых и отзывчивость которые на действия юзера вызывали бы оптимизм. То что сильно некоторые монстры-переростки типа опенофиса тормозные - не есть оправдание. А, простите, вам говорят что вон там - хреново. Вы начинаете кивать что у других тоже, иногда и местами бывает хреново. Это что за детский сад? Удачи в таком подходе к написанию софта. Лондонцы уже одних таких красавцев послали и правильно сделали.

>прозреваю когнитивный диссонанс

Прозревайте что хотите. Я вот прозреваю виндузевого дотнетчика судя по всему. Возможно даже пиар-бота, вы тут давно какие-то потуги пиара MSовских технологий устраиваете. Конечно не такая клиника как Трухин, но тоже хороши.

>после запуска приложения можно остановить службу проверки лицензии (sc stop osppsvc) для
>пущей убедительности. всё-таки лишний десяток метров оперативы

У меня в пингвине нет никакой службы лицензий. И это мне нравится. А накукуй мне эта служба сдалась?Правильно - мне она не нужна. Доступно, да? :)

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

Что, генератор нативного кода уже стал обладать искусственным интеллектом и способен прочухать что програмер вон там уже сам провалидировал входные данные и совсем не обязательно крутить левые проверки всяких там выходов за границы и прочее барахло в тугом цикле "для надежности"? Не верю, извините. Факты показывают обратное - критичные к скорости алгоритмы сливают в ~3 раза. Плюс-минус лапоть. С хрена ли они это делают? Сказки это замечательно, но мы то знаем что чудес не бывает и все имеет свое научное объяснение.

>код на "управляемых" языках может компилироваться в инструкции
>процессора,

Да, вот только для обеспечения его управляемости придется кроме полезной нагрузки впихать вагон левого барахла, которое притормозит все. Ну как раз в те три раза примерно, там где скорость критична. А где менее критично (GUI, etc) свое черное дело успешно делает гарбаж колектор, а точнее, его неохотная очистка памяти, так что тонна гумна утекает в своп а потом, когда мы хотим переключить в окно программы, оказывается что надо подождать минутку - а то оно видите ли уже в своп утекло со всеми своими мегатоннами дряни.

>а код на сях - интерпретироваться. похоже, даже по прошествии
>десятилетий это для многих остается сюрпризом.

Дотнетчики и жабисты столько бухтят про генерацию кода, про то как там можно круто заоптимизить и прочая. Но почему-то никогда не показывают сравнение ОДИНАКОВЫХ алгоритмов... видимо не получается в прямом честном сравнении победить то, а? вот и приходится сравнивать кривизну от сана с кривизной от мс, при том они мягко говоря нифига не идентичны по алгоритмам. Т.е. подтасовка фактов в свою пользу - налицо ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

106. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 23:51 
>Насчет 2010 не знаю а 2007 память жрет так что потом по
>минуте переключается между вордом, аутглюком и экселем. На машинах с 2-4
>ядра, 4-8 гиг оперативы и прочая.

Вот у меня Outlook 2007 запущен уже 7 дней, потребление памяти 80MB. Внутри два почтовых ящика, в одном 10K писем. Ничего не тормозит, ЧЯДНТ?

>Ну и ессно никто не запрещает реализовывать алгоритмы неоптимально. Знаете,
>поиск в hash-таблице с 100 000 000 записей даже на яве
>таки уделает линейный перебор массива в 100 000 000 элементов на
>асме. Потому что выигрыш в 3  раза не скомпенсирует тупой
>алгоритм с перебором 100 000 000 элементов влобовую.

Какие 3 раза? Вы о чём? Поиск в hash-таблице в случае int32 ключа будет занимать от 4-х до 30 шагов. 30 - это если у вас хеш-функция возвращает одно и то же значение.

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

где слив? У кого слив? Хотите быстро - выжирон памяти будет в любом случае.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

107. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от User294 (ok) on 11-Янв-10, 02:03 
>Вот у меня Outlook 2007 запущен уже 7 дней, потребление памяти 80MB.
>Внутри два почтовых ящика, в одном 10K писем. Ничего не тормозит,
>ЧЯДНТ?

Наверное сказки рассказываете. Но если что - я вскоре померяю сколько аутлук 2007 жрет, как раз будет удобный случай. А так - ну вон вьюжл студия 2008, абсолютно без нифига - спокойно кушает 260 метров активной памяти (про виртуальную я вообще молчу). На что?! А хрен знает - просто открыта. Без нифига. Чудеса дотнета, елки - пустое окошко жрет 200 мегов! А уж если запустить с аутлуком и вордом - все это барахло выдавится в своп и будет при переключении крайне уныло тормозить, как вин95 на первом пеньке с 16 мегами. С той разницей что это на некислой машине теперь. В жопу такой софт, который делает первый пентиум из 4-ядерника. Вам нравится - юзайте это тормозное барахло, а мне оно не надо.

>Какие 3 раза? Вы о чём?

Это типовой слив managed кода обычному по скорости работы в критичных по скорости кусках (типа сжатия, хеширования, etc). В самом тепличном случае. Так, если вы вдруг не знали. Это в случае если JIT есть и прочая. А если каконйить питон у которого и jit нету - там вообще с производительностью полный швах.

>где слив? У кого слив? Хотите быстро - выжирон памяти будет в любом случае.

Да вот знаете, ипучий велосипед с гарбаж колектором у того же дотнета - память жрет пока не приспичит ее отдать с ножом к горлу. А потому - гигазы говна выдавливаются в своп и немилосердно тормозят при переключении задач. Да и пока стартанет например снап-ин управления Exchange 2007 - задолбишься ждать. А от 2003 стартил довольно быстро. Итого? переход на дотнет сделал его и менее функциональным (половина фич только через тормозной и горбатый PowerShell теперь) и тормознутым. Замечательно, вашу мать. Только теперь пока в этом тормозилове что-то сделаешь - проще, мля, конфигу почтовику в пингвине написать ручками. Менее мучительно - по крайней мере ничего не тормозит по минуте. Ну и Cray для запуска не надо.А то на установку Exchange 2007 с всеми пререквизитами можно сутки просрать запросто. И требований три вагона. Ну не пипец?!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

113. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от partizan (??) on 11-Янв-10, 19:42 
1) Часто скорость разработки и лёгкость изменений важнее чем скорость:
Мне пофиг, что моя программа на руби стартует 2 секунды вместо 0.01 секунды (я дольше буду запускать терминал).

Также ерланг раз в 10 медленее чем С/С++, но всё равно на нём пишут. Просто многопоточный сервер, держащий десятки тысяч клиентов написать  очень сложно на С/С++, а если ещё нужно простота кластеризации на нескольких серверах и простота изменений...

2) Если не хватает скорости managed кода, то никто не мешает использовать нативный код в этих местах.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

95. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от dq0s4y71 (??) on 10-Янв-10, 20:20 
>Конечно не знаю.

Я уже понял.

>Вам не кажется что это всё же более нишевые отрасли?

Для тех, кто этим не занимается - разумеется.

>Ествественно что нет, но писать что-то для десктопов сейчас это идиотизм, тот же icc выдаст код на порядки качественей.

Ничего не понял. icc выдаст код на порядки качественней чем ЧТО? И почему вы решили, что писать что-то для десктопов - "идиотизм"?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

99. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от User294 (ok) on 10-Янв-10, 22:33 
>Ассемблер это вообще из разряда фантастики.

Хватит ламерствовать. Возьмите сорсы любого нормального кодека а то и плеера и посмотрите. Или плееры и т.п. - это не прикладные программы? Да и какойнить SHA-1 не стесняются оптимизнуть если десяток строк дают прирост скорости медленной и нудной операции в разы. А то что всяким халтурщикам охота побыстрее какого-то говна накорябать и вывалить - "нате, жрите" - никто и не сомневался. Вот только видно птицу по полету. Рапидчики и халтурщики - синонимы.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

78. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от vitek (??) on 10-Янв-10, 10:33 
>Я всего лишь сделал предположение, что GOTO начали хаить задолго до "маркетологизации" IT-мира..

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

57. "Почему администрирование серверов ключевых открытых проектов..."  –1 +/
Сообщение от sHaggY_caT (ok) on 09-Янв-10, 23:07 
>> Может быть, но я в ассемблере пока разбираться не планировала
>
>Тем не менее, у большинства процессоров есть команда "безсуловного перехода" - нечто
>типа JMP [адрес]. Влобовую прописывающий процу что брать следующую команду -
>вон там. Собссно это ваше goto и есть :). Процы так
>работают и стесняться этого факта - странно. Другое дело что читабельность
>и структурированность кода оно портит. Поэтому  юзать его по возможности
>и правда не надо. Но иногда - видно как чтобы не
>пользоваться goto сгорожено пять этажей таких невменяемых костылей что лучше б
>уж поюзали одно goto...

Goto из некоторых языков убрали by design, и поюзать получится не везде...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

60. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от vitek (??) on 09-Янв-10, 23:46 
и что? кому то стало легче?
или дырок в софте стало меньше?

глупость это всё. в нормальном коллективе и так свои стандарты на код, оформление и т.д.
а в не нормальном и без гоуту фигню такую напишут, мама не горюй.

вон, одноэсники такой отчёт порой слобают... на полтора часа...
а стоит запрос правильно написать- 3 минуты.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

62. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Gambler (ok) on 10-Янв-10, 01:02 
Нормальный коллектив - это утопия. Реально бывает так: на тебя вываливают мегабайт говна, написанный кем-то еще, и заставляют там что-то исправлять. И еще запрещают переписывать с нуля, потому что "настоящие программисты ничего сейчас с нуля не делают". Теперь вопрос. Какой код лучше, говеный код с goto или говеный код без goto? Вот. Вот поэтому и запрещают его во многих языках.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

76. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от vitek (??) on 10-Янв-10, 10:00 
утопия - это думать, что убрав гоуту Вы решите все свои проблемы.
г останется г и с гоуту, и без него.
впрочем как и хороший код останется хорошим кодом.

зы:
а про коллективы - Вы это зря.
если в России бардак и разруха, то это не значит, что нельзя жить как-то по-другому.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

93. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от User294 (ok) on 10-Янв-10, 20:08 
>Goto из некоторых языков убрали by design, и поюзать получится не везде...

А какойнить brainfuck и вовсе жутко мучителен в использовании.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

40. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от szh (ok) on 09-Янв-10, 17:27 
> царствует жесткая специализация

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

> если я сейчас увязну в ассемблере

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

58. "Почему администрирование серверов ключевых открытых проектов..."  –1 +/
Сообщение от sHaggY_caT (ok) on 09-Янв-10, 23:14 
>> царствует жесткая специализация
>
>тем не менее хороший специалист должен иметь четкое представление о смежных областях,
>иначе много-го не осилит.

В общем-то, я считаю примерно так же, и собираюсь конкретно сесть за C/C++, Python, Ruby (так как часто использую Puppet, а он написан именно на нем)

>> если я сейчас увязну в ассемблере
>
>А не надо в нем увязать.
>Я прочитал небольшую книжку 10 лет назад и чуток пописал тестовых задачек
>из той книжки, мне этого почти хватило на всю оставшуюся жизнь.
>Чтобы понимать в целом что к чему.

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

И так ли нужен ли системному администратору в современном мире ассемблер? Я просто не могу себе представить, где это можно применить, не будучи кодером (системщикам, и разрабатывающим высокопроизводительное ПО на C/C++ конечно, нужно, а вот уже web-программистам зачем?, разве что для понимания, и способности поддержать флейм вроде этого, стукнув себя пяткой в грудь, и сказав что Ъ-кодер, знающий ассемблер, например, PPC :)) )

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

61. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Gambler (ok) on 10-Янв-10, 00:56 
Вы не о том ассемблере думаете. Конкретно ассемблер интеловского i686 знать никому, кроме системщиков, конечно, не нужно. Но общее представление о том, как работает современный процессор, любому программисту помогает. В том числе и веб-программисту. И для этого бывает полезно поработать с _каким-то_ ассемблером, а так же подучить процессорную архитектуру. Например вот хорошая статья-книжка:

http://lwn.net/Articles/250967/

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

66. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 06:08 
> разрабатывающим высокопроизводительное ПО на C/C++ конечно

И много вы видели высокопроизводительного ПО на ассемблере? Я когда-то давным давно, ещё во временя 3dfx Voodoo и Intel Celeron 300A прочитал Intel Optimization Manual, это уже тогда был хороший талмуд. В общем вместить в голове весь объём знаний который там есть ни один нормальный человек не сможет, ненормальный, впрочем, тоже. Так что если хотите быстро - берите icc и не жужжите.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

72. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от vitek (??) on 10-Янв-10, 08:14 
дофига.
берём кернел и смотрим.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

83. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 13:01 
>дофига.
>берём кернел и смотрим.

линуксового ядра под рукой нет, посему взял фряшное. Итого 46 файлов, 25 - для поддержки загрузки (/usr/src/sys/boot), 15 файлов в i386 ветке, и всего два в amd64, и те ./amd64/linux32/linux32_support.s ./amd64/linux32/linux32_locore.s. Так что можно сказать что почти нет тут ручного ассемблера.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

109. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от User294 (ok) on 11-Янв-10, 02:39 
>Так что можно сказать что почти нет тут ручного ассемблера.

Логика человека, мозг которого убит дотнетом в хлам. Знаете, в какомнить кодеке типа xvid ассемблера тоже "почти нет" - считанные небольшие кусочки, ничто по сравнению с общей массой кода. Потому что ессно программить все это целиком на асме - садо-мазо нерельное, да и глобальные оптимизации компилер лучше сделает. Но вот именно это, которого "почти нет" ... и повышает скорость работы кодека В РАЗЫ по сравнению с чисто-севой версией. Прикольно, да? :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

75. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Ъ on 10-Янв-10, 09:24 
>> разрабатывающим высокопроизводительное ПО на C/C++ конечно
>
>И много вы видели высокопроизводительного ПО на ассемблере?

Можете в виртуалке посмотреть Kolibri OS целиком на ассемблере.
http://www.kolibrios.org/

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

82. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 12:46 
>>> разрабатывающим высокопроизводительное ПО на C/C++ конечно
>>
>>И много вы видели высокопроизводительного ПО на ассемблере?
>
>Можете в виртуалке посмотреть Kolibri OS целиком на ассемблере.
>http://www.kolibrios.org/

насколько оно выскокопроизводительное? Я понимаю что если делать нечего, то можно и чёрта лысого сделать, но тем не менее полистайте тот же Intel Optimization Manual, я думаю будет понятно что писать быстрый универсальный код на асме под весь зоопарк процессоров банально нереально.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

92. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Ъ on 10-Янв-10, 19:43 
>>>> разрабатывающим высокопроизводительное ПО на C/C++ конечно
>>>
>>>И много вы видели высокопроизводительного ПО на ассемблере?
>>
>>Можете в виртуалке посмотреть Kolibri OS целиком на ассемблере.
>>http://www.kolibrios.org/
>
>насколько оно выскокопроизводительное?

Иногда абсолютно не нужно никаких цифр и графиков, достаточно один раз увидеть, вы все-таки запустите в виртуалке, ну чего там, 5 мегабайт вся операционка, загрузка 1 секунда.  

>Я понимаю что если делать нечего, то можно и
>чёрта лысого сделать, но тем не менее полистайте тот же Intel
>Optimization Manual, я думаю будет понятно что писать быстрый универсальный код
>на асме под весь зоопарк процессоров банально нереально.

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

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

Мне тут на днях попалась хорошая статья по этой теме: http://russian.joelonsoftware.com/Articles/BacktoBasics.html


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

101. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 10-Янв-10, 22:41 
>>насколько оно выскокопроизводительное?
>Иногда абсолютно не нужно никаких цифр и графиков, достаточно один раз увидеть,
>вы все-таки запустите в виртуалке, ну чего там, 5 мегабайт вся
>операционка, загрузка 1 секунда.

И какие я должен сделать выводы? Она ведь ничего не поддерживает из оборудования, ей ничего грузить не нужно. Чему там тормозить если там функциональности кот наплакал.

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

Мне мой опыт подсказывает что проблемы с производительностью обычно вызваны следующими проблемами:
- ошибки в программе
- архитектурные недочёты (неправильный выбор алгоритма, пропущенные индексы в базе, etc.)

После того как все эти проблемы решены и улучшать уже некуда, тогда можно и думать о чём-то ещё, но обычно прирост можно получить на уровне единиц процентов, что в большинстве случаев никому не нужно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

110. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от User294 (ok) on 11-Янв-10, 02:47 
>можно и думать о чём-то ещё, но обычно прирост можно получить
>на уровне единиц процентов, что в большинстве случаев никому не нужно.

Да? А почему тогда xvid без асм вставок сливает xvid с асм вставками чуть ли не в разы? Может, врать то не надо? Грамотное применение асм вставок в критичных местах может поднять скорость в разы. Экономия пары команд в тугом цикле легко поднимет скорость в пару раз. Если там всего 4 команды было, например и компилер пролошился и не смог сгенерить код более ортимально;).При том - да, асмовый кусочек не будет выкабениваться на амдшных и каких там еще процессорах и корректно задетектит всякие SSE и прочая. В отличие от всяких там супер-дупер-icc и прочая.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

114. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от belpartizan (ok) on 11-Янв-10, 20:36 

>Да? А почему тогда xvid без асм вставок сливает xvid с асм
>вставками чуть ли не в разы? Может, врать то не надо?
>Грамотное применение асм вставок в критичных местах может поднять скорость в
>разы. Экономия пары команд в тугом цикле легко поднимет скорость в
>пару раз. Если там всего 4 команды было, например и компилер
>пролошился и не смог сгенерить код более ортимально;).При том - да,
>асмовый кусочек не будет выкабениваться на амдшных и каких там еще
>процессорах и корректно задетектит всякие SSE и прочая. В отличие от
>всяких там супер-дупер-icc и прочая.

Расскажите насколько ускорится утилита "cp" от переписывания на ассемблер. Ну или grep. И сколько времени у вас займёт реализация регулярных выражений на ассемблере.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

115. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Aleksey Salow email(ok) on 11-Янв-10, 20:59 
>Расскажите насколько ускорится утилита "cp" от переписывания на ассемблер.

Кстати, утилита "cp" ускоряется если её сделать многопоточной.
Сравнение тут: http://w00dy.livejournal.com/255237.html
Сорец тут: http://xxx.org.ua/cpmt.c

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

96. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от User294 (ok) on 10-Янв-10, 20:21 
>И много вы видели высокопроизводительного ПО на ассемблере?

Дофига. Кодеки, плееры, etc например. Разница между чисто сишной и си+асм вставки бывает чуть ли не в разы. Потому что когда компилер сгенерит какую-то ересь в тугом цикле - он разумеется тормознется. Там каждая лишняя команда может некисло просадить скорость, если цикл крутится много и часто.

>Так что если хотите быстро - берите icc и не жужжите.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

119. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от nvv13 on 12-Янв-10, 11:16 
>Вот эта борьба за "чистоту кода" уже немного отдает фанатизмом, конечно, что
>goto зло я согласна (и что его не зря убрали из
>облюбованного быдло-кодерами PHP), но это уже перебор :(

goto используется в новейшем языке от google - go
смотри  http://golang.org/doc/go_spec.html#Goto_statements
так что, goto не зло, а хорошая "фишка" !!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от XoRe (ok) on 09-Янв-10, 02:29 
Ланс Альбертсон отвечает на вопрос:
"Как поставить новичка на ответственную должность и не словить попу")
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от Pilat (ok) on 09-Янв-10, 03:19 
Денег нет - зовут студентов, так как это единственный выход, тем более в университете.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Почему администрирование серверов ключевых открытых проектов..."  –2 +/
Сообщение от XoRe (ok) on 09-Янв-10, 04:48 
>Денег нет - зовут студентов, так как это единственный выход, тем более
>в университете.

Хочу заметить в тексте:
> среди которых основной сайт распространения Linux ядра Kernel.org, сайты Linux Foundation, Apache Software Foundation, сообщества Drupal,  Mozilla Firefox, One Laptop Per Child, GNOME, PostgreSQL и еще 50 проектов.

У некоторых из перечисленных деньги есть.
Так что тут не только это.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от Анонимус666 on 09-Янв-10, 12:34 
Читаем вимательно:
По словам Ланса такой подход оправдывает себя, хотя главная причина использования студентов на ответственной работе - это желание свести стоимость обслуживания к минимуму.

Все остальное высосано из пальца.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

41. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от XoRe (ok) on 09-Янв-10, 18:44 
>Все остальное высосано из пальца.

Главное, чтобы было подешевле.
А кто там будет конфигурить сервер баз данных, а какая разница.
Я угадал? )

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

55. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от _Bulgarin (ok) on 09-Янв-10, 23:04 
>Читаем вимательно:
>По словам Ланса такой подход оправдывает себя, хотя главная причина использования студентов
>на ответственной работе - это желание свести стоимость обслуживания к минимуму.
>
>
>Все остальное высосано из пальца.

Точно. Но еще точнее - как из того косячного фуфла, что они натворят, что-то полезное извлечь :)
Шучу, но от правды недалеко - только разговаривал с начальником кафедры ВЦ, говорил он - первые два года бывшие студенты только учатся делать толково.
А как научастся - уходят где платят больше. Трамплин.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

77. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от vitek (??) on 10-Янв-10, 10:03 
абсолютно верно.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Почему администрирование серверов ключевых открытых проектов..."  +2 +/
Сообщение от Dear mr. DW on 09-Янв-10, 06:32 
McDonald's в IT: студенты на серьезную и полезную работу. :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от vitek (??) on 09-Янв-10, 11:28 
а кто сказал, что там нет профотбора и они там без_присмотра?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

37. "Почему администрирование серверов ключевых открытых проектов..."  +1 +/
Сообщение от nitrogear email on 09-Янв-10, 15:39 
Потому что у каждого профессора есть сын :-D
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

39. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от аноним on 09-Янв-10, 16:17 
>Потому что у профессора есть сын :-D

этот аргумент мне представляется наиболее важным.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

120. "Почему администрирование серверов ключевых открытых проектов..."  +/
Сообщение от sluge (ok) on 13-Янв-10, 15:03 
господа, скажу вам, что в крупных конторах, например в intel, софт зачастую пишут тоже студенты, так что если у вас будет глючит интеловский софт, знайте кто в этом виноват
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру