metaclass: (Default)
[personal profile] metaclass
Я вот подумал, что "в среднем" софт, сделанный, скажем так в идеологии опен-сорс-юникс-вея, будет содержать больше багов, чем монолитно-виндовско-проприетарный. Багов такого вида типа "определенная функция в определенных условиях не работает".

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

В монолитной виндовой проприетарщине же если что-то ломается - очевидно, первым этапом можно пойти поиметь мозг автору. А тому, в общем-то, и проще все исправить, т.к. код у него под контролем, а если автор еще и вменяем, то от сторонних сервисов у него вообще ничего не зависит. "Не принято вносить зависимости". И т.к. участвует одна единица "автор" или "контора-разработчик", исправление внести проще, чем когда это дело сначала надо обсудить со всем комьюнити в мейл-листах, поцеловать иконы столлмана и торвальдса в спину, сделать сначала патч, потом внести его куда-нибудь в основную ветку, долждаться пока выйдет очередная стабильная версия, а потом пару лет отвечать юзерам "обновите такое-то софтино версию 2.x.y на 2.x.z, если у вас при откручивании гайки из пупка жопа отваливается".

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

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

Date: 2009-06-13 11:07 am (UTC)
From: [identity profile] metaclass.livejournal.com
И таки не пофигу. Я сам юзеров поддерживаю и багофичи в своем проприетарном софте правлю и делаю по их заявкам.
Я скорее считаю, что линуксоидам должно быть пофигу, т.к. разорвана связь "качественный софт - есть что жрать завтра".

Date: 2009-06-13 11:32 am (UTC)
From: [identity profile] metaclass.livejournal.com
Залогинится на машину локально и посмотреть event log для начала. Там могут быть всякие нездоровые коды ошибок в логах.
Гугл знает только про такие же проблемы, ответов там вроде бы нет.

Такое ощущение, что в висте неправильный код ошибки где-то возвращается, т.к. эта ошибка из совершенно другой оперы(удаление сетевого диска). Я бы сел на той машине локально с procmon и попытался бы отследить, что происходит при попытке логиниться в rdp.

Date: 2009-06-13 11:54 am (UTC)
From: [identity profile] lionet.livejournal.com
Залогинился "нормально". После этого RDS сразу стал работать. В эвент логе без исходников того, что привело к проблеме, думаю, разобраться нереально:



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

Date: 2009-06-13 11:58 am (UTC)
From: [identity profile] metaclass.livejournal.com
Да, удаленная работа с виндой все таки менее удобна чем в линуксах. Хотя мы уже лет 5 удаленно винды обслуживаем, но там обычно есть свой админ, который в случае чего может что-нибудь исправить.

Date: 2009-06-13 03:34 pm (UTC)
From: [identity profile] vp.livejournal.com
в принципе физический доступ по опыту не нужен кроме случая включить комп после пропадания питания.

Date: 2009-06-13 03:36 pm (UTC)
From: [identity profile] metaclass.livejournal.com
Отключить файрволл еще.
И еще всякие действия связанные с безопасным режимом, удаленно их просто не сделаешь.

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 18th, 2025 08:49 am
Powered by Dreamwidth Studios