Yasix

Тоже так думал. Переименовал "Мои документы" в "MyDocuments". Шифры из листинга ушли, но лучше не стало, ошибка осталась та же.

Попытался проанализировать, что выдаёт вайн при запуске из консоли: eugen@yasix:~/.wine/drive_c$ env WINEPREFIX="/home/eugen/.wine" wine "e:\install\electr\Multisim\NICDS10.1\setup.exe" fixme:volume:GetVolumePathNameW (L"E:\\install\\electr\\Multisim\\NICDS10.1\\Supportfiles\\resource_eng.cab", 0x7778c8, 68), stub! fixme:volume:GetVolumePathNameW (L"E:\\install\\electr\\Multisim\\NICDS10.1\\supportfiles\\nipie.exe", 0x7793f0, 61), stub! fixme:volume:GetVolumePathNameW (L"E:\\install\\electr\\Multisim\\NICDS10.1\\supportfiles\\NISysInf.dll", 0x784cc8, 64), stub! err:ole:CoGetClassObject class {5b9cece7-5b14-44da-a00b-d38c3c97fe66} not registered err:ole:CoGetClassObject class {5b9cece7-5b14-44da-a00b-d38c3c97fe66} not registered err:ole:create_server class {5b9cece7-5b14-44da-a00b-d38c3c97fe66} not registered fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported err:ole:CoGetClassObject no class object {5b9cece7-5b14-44da-a00b-d38c3c97fe66} could be created for context 0x17 fixme:advapi:LookupAccountNameW (null) L"eugen" (nil) 0x7de8fbd8 (nil) 0x7de8fbdc 0x7de8fbd0 - stub fixme:advapi:LookupAccountNameW (null) L"eugen" 0x164740 0x7de8fbd8 0x164288 0x7de8fbdc 0x7de8fbd0 - stub fixme:msi:MsiGetLastErrorRecord fixme:msi:MsiGetFeatureValidStatesW 1 L"EWBEdu_lic.EWB.EDU_LIC.101" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"CoreDLLs.EWB.CORE.101" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"Complete.NILM.LM30201" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"HelpAsst.HELPASST101" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"HelpAsst64.HELPASST64101" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MDF_Support.MIFMDFS251" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MDF_EULADepot.MIFMDFE251" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"USI.USI" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"Logos.LV.LOGOS.490" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"OdbcCitadel4.LV.LOGOS.490" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"LOGOS_XT.LOGOSXT.85000" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"SvcLoc.LV.SVCLOC.850" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MKL.LV.MKL700" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"LVRTE.LV.RTE820" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"Netscape6Plugin.LV.RTE820" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"Netscape7Plugin1.LV.RTE820" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"Netscape7Plugin2.LV.RTE820" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"FireFox.LV.RTE820" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MozillaPlugin.LV.RTE820" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"IEPlugin.LV.RTE820" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"PortIO.LV.RTE820" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"LVRT_NBFIFO.LRT.82035" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"LVRTE.LV.RTE850" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"Netscape6Plugin.LV.RTE850" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"Netscape7Plugin1.LV.RTE850" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"Netscape7Plugin2.LV.RTE850" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"FireFox.LV.RTE850" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MozillaPlugin.LV.RTE850" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"IEPlugin.LV.RTE850" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"PortIO.LV.RTE850" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"LVRT_NBFIFO.LRT.85035" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"tdms.NI.TDMS" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"TDMSmsm.NI.TDMS" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"CVIRTE.CVIRTE08101" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"VC2005MSMs_x86.VC8X868012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MFCLOC.VC8X868012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"OpenMP.VC8X868012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MFC.VC8X868012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"CRT.VC8X868012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"ATL.VC8X868012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"VC2005MSMs_x64.VC8X648012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"CRT.VC8X648012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"ATL.VC8X648012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"OpenMP.VC8X648012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MFC.VC8X648012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MFCLOC.VC8X648012" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"UpdateServiceCore.US.CORE100" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"UpdateService.US.FULL100" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MetaSuite.METASUITE" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"DN200x86_Main.DN20X861" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"MetaUninstaller.MIFMUI251" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"EWBEdu.EWB.EDU.101" 0x7de902e4 stub returning 8 fixme:msi:MsiGetFeatureValidStatesW 1 L"ELVIS.EWB.EDU.101" 0x7de902e4 stub returning 8 fixme:msi:ACTION_HandleStandardAction unhandled standard action L"SetODBCFolders" fixme:msi:msi_unimplemented_action_stub MigrateFeatureStates -> 56 ignored L"Upgrade" table values fixme:volume:GetVolumePathNameW (L"C:\\windows\\profiles\\eugen\\\041c\043e\0438 \0434\043e\043a\0443\043c\0435\043d\0442\044b\\", 0x7f3570, 42), stub! <<< тут и выскакивает вышеозначенная ошибка >>> ... никаких конструктивных мыслей по поводу прочитанного не пришло пока...

Поставил MytUbuntu (инсталлятор запускается прям с ихнего сайта). Как поставил, понял, что это малость не то, что хотелось. Хочу вернуть всё взад. Насколько я понимаю, надо вернуть старое ядро и вычистить всё что Myth намутил. Подскажите, пож, можно ли это сделать и как.

При запуске инсталлятора NI MultiSim 10.1 (быв. Electronics Workbench) выскакивает Error: Installer needs access to "My Documents", however this location 'C:\windows\profiles\eugen\MyDocuments\' is not accessible. В настройках Wine диски прописаны. Требуемая папка существует. Я её владелец. Права все есть. Другие проги ставятся нормально. (Я даже на всяк случай переименовал "Мои документы" в MyDocuments, чтоб не было русских букв и пробелов - не помогло).

Brungilda Например, можно найти соответствующий файл конфига и сделать ему запрет на запись. Угу, тоже такая идея была. Не канает: очевидно, при загрузке старый файл конфига банально удаляется и на его месте создаёцца новый. Ставить ридонли на каталог /etc? Гы... Brungilda Или вообще отключить этот стартовый скрипт (сделать его неисполняемым). Ну типа о том и вопрос. Где эти скрипты находятся-то? Или мож в Юбунте это и через графический интерфейс сделать можно?

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

Спасибо, стало чуть-чуть понятнее. Но вопросы остались. Например, при установке я задал имя локального пользователя и задал пароль (собс-но, мне деваться было некуда, ибо пустой пароль не прокатывал). Однако же теперь при загрузке Юбунта вваливается в десктоп и никаких паролей не спрашивает. Почему? Да, пароль запрашивается для "решения административных задач". Только вот, например, грохнуть всё в моём дом. каталоге - административной задачей не считается: кто хошь, включай комп, загружайся и грохай... Оно понятно, что можно отключить автоматический вход и т.п. Это частности. Непонятна концепция, принцип, идея... Дальше. Что ж у нас всё-таки с рутовым паролем? При установке Юбунта ничего насчёт этого не спрашивает. Получается, что по умолчанию он пустой? Или не пустой, но никому неведомый? И почему когда я позже явно задал пароль root - это была ошибка (как утверждает Legalizer)? Если это ошибка, то как эту ошибку можно исправить? Насчёт "подтелнетиться" - это я фигурально, это собирательный образ всяческих хакерских уловок, используемых для взлома. Мне неоднократно приходилось слышать, что работать в какой-нть общающейся с сетью прикладной проге под root-ом - крайне опасно. А, вроде как получается, что в Юбунте по умолчанию все п-ли с рутовыми правами, сл-но все проги работают под рутом. И при этом система неуязвима? Не, чё-то я явно не догоняю...

Алилуййа! Зарабоооотало! Но как! Прописал в /etc/resolv.conf nameserver 208.67.222.222 -- nslookup прописанный сервер не упомянул /*вполне возможно, что у моего провайдера сетевые настройки не ахти какие прозрачные, такчто Убунта его просто не увидела; но это не суть*/, зато, после привычной задержки nslookup, выдав что всё ок, сослался на некий адрес, который нигде не был прописан ни как первичный ни как вторичный. Так-с, значит мы кладём на настройки и можем откуда-то из кустов достать адрес некоего nameserver-а. Ну чё, флаг в руки. А давай-ка, подумалось мне, я в resolv.conf вообще все namesrver-ы закомментирую. Закомментировал. И - вот оно, щастье. Задержек больше нет. Спасибо за помощь! Сам бы я ни в жисть до этого не догадался. Хотя пока не очень уверен, что найденное решение будет стабильно работать.

Ой, да, забыл: до недавнего времени работал в ХР - никаких проблем не было, всё "летало". Когда ставил Убунту, шаловливыми ручками по ошибке снес партишн, и ХР, увы, безвременно почила. Теперь на компе кроме Убунты ничего не стоит, так что сравнивать не с чем. Ставить ХР по новой только для того чтобы сравнить ... как-то не хотелось бы. Собсно, оно и щас "летает". Когда идёт непосредственно загрузка. 300 Кб/сек. Тормоза только в начале - при установке соединения. Раньше такого явно не было.

Прокси нету; в файерфоксе стоит "брать системные настройки прокси".... С настройками прокси и с lynx не экспериментировал, т.к. что-то мне подсказывает, что собака зарыта все-таки где-то уровнем пониже, нежели браузер. Вот, например, реальные распечатки пинга /* он ведь тоже не использует прокси? */ eugen@yasix:~$ ping linux.ru PING linux.ru (217.23.133.20) 56(84) bytes of data. 64 bytes from upirdotyen.decisionbound.net (217.23.133.20): icmp_seq=1 ttl=57 time=9.41 ms 64 bytes from upirdotyen.decisionbound.net (217.23.133.20): icmp_seq=2 ttl=57 time=8.53 ms 64 bytes from upirdotyen.decisionbound.net (217.23.133.20): icmp_seq=3 ttl=57 time=8.61 ms 64 bytes from upirdotyen.decisionbound.net (217.23.133.20): icmp_seq=4 ttl=57 time=8.77 ms ^C64 bytes from upirdotyen.decisionbound.net (217.23.133.20): icmp_seq=5 ttl=57 time=8.59 ms --- linux.ru ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 20080ms rtt min/avg/max/mdev = 8.531/8.785/9.411/0.333 ms итого на отправку 5 пакетов ушло 20 (двадцать!) секунд. После ввода команды через ~4 с появляется "PING linux.ru (217.23.133.20) 56(84) bytes of data." и дальше с интервалом в ~4 с идут строчки о переданных пакетах. Сразу после 4-го пакета нажимал Ctrl+C - ещё пауза в 4 с, приходит 5-й пакет и уже только тогда - выход. (и, кстати, что это за upirdotyen.decisionbound.net?) Теперь по прямому адресу: eugen@yasix:~$ ping 217.23.133.20 PING 217.23.133.20 (217.23.133.20) 56(84) bytes of data. 64 bytes from 217.23.133.20: icmp_seq=1 ttl=57 time=8.44 ms 64 bytes from 217.23.133.20: icmp_seq=2 ttl=57 time=10.1 ms 64 bytes from 217.23.133.20: icmp_seq=3 ttl=57 time=9.97 ms 64 bytes from 217.23.133.20: icmp_seq=4 ttl=57 time=9.83 ms ^C --- 217.23.133.20 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3009ms rtt min/avg/max/mdev = 8.446/9.600/10.141/0.678 ms "PING 217.23.133.20 (217.23.133.20) 56(84) bytes of data." появляется вообще без задержки, строчки о пакетах - как и положено, чопают каждую секунду - итого 4 пакета за 3 с. По Ctrl+C выскакивает сразу. Вот я и думаю .........

Server: 217.10.32.4 Address: 217.10.32.4#53 Non-authoritative answer: Name: linux.ru Address: 217.23.133.20 задержка около секунды один раз без задержки выдал ;; Got SERVFAIL reply from 217.10.39.4, trying next server Server: 217.10.32.4 Address: 217.10.32.4#53 Non-authoritative answer: Name: linux.ru Address: 217.23.133.20 (.39.4 - это первичный DNS, .32.4 - вторичный) Физически - подключение по DOCSIS через USB-модем Motorola SURFBoard 1501. Провайдер - akado.ru Программно - про настройку сети ничего внятного сказать не могу, ибо ничего не настраивал - Убунта при установке всё сама сделала. Имя соединения - Auto eth0, выводится на закладке "Проводные соединения".

э-э-э... правильно ли я понял что по умолчанию рутовый пароль в Убунте не задан? т.е. пустой? ... и что тогда мешает кому-нть подтелнетиться и воспользоваться тем же sudo? ( я вообще-то не Настоящий Линуксоид и стать таковым особо не стремлюсь, так что вчитываться в мануалы мне, откровенно говоря, лень. Поэтому, если кому не влом отвечать на мои, возможно, тупые вопросы - буду очччень признателен, но только, пожалуйста, не в стиле RTFM)

Что-то я не догоняю концепцию авторизации (или аутентификации, или как это правильно называется) в Убунте... При установке она спросила имя п-ля и пароль, а если, грит, надо ещё п-лей, то потом, типа, сам добавишь. Ну я ввёл, к примеру, Yasix, задал пароль, к примеру, 111. Установка прошла успешно. Теперь при загрузке вваливается в десктоп, никаких паролей при этом не спрашивая. Только иногда, например, при попытке открыть НТФСный том, просит авторизоваться под именем Yasix - ну, ввожу пароль 111 и работаю дальше. Оно вроде ж как некоторым программам требуются рутовые привелегии, для чего они запрашивают пароль п-ля root. Так вот пароль п-ля root при установке меня никто не спрашивал. Странно, однако. Зашёл в Админитрирование/Пользователи и группы - глядь, а там есть п-ль root, только нарисован сереньким, типа заблокирован, ну я, в очередной раз авторизовавшись как рядовой Yаsix, этого root-а разблокировал и пароль ему задал. Как-то совсем уж не понятно: с какой это стати рядовой п-ль может рутовый пароль задавать?... Проясните, пож. (прошу прощения за несколько пространное изложение)

Привет! Вот, поставил на днях Убунту. Подключение Интернет определилось автоматически, работает прекрасно, за исключением одной "особенности". При открытии к-нить (любого) сайта всегда подтормаживает на стадии "Поиск узла" (в самом начале, то есть). Имея некие скудные познания в тырнет-технологиях предположил, что, м.б. тормозит DNS? К примеру, ping linux.ru обменивается пакетами ощутимо медленнее, чем тот же ping с явно заданным ip: ping 217.23.133.20 "Медленне" - в том смысле, что каждая новая строчка вида "64 bytes from 217.23.133.20: icmp_seq=1 ttl=57 time=15.8 ms" в случае "ping linux.ru" появляется где-то каждые 4 сек, а в случае явного указания "ping 217.23.133.20" - каждую секунду. Причем в обоих случаях собственно время пересылки в среднем 10 мс. Аналогично и в самом браузере "http://linux.ru/" открывается с задержкой секунд в пять. "http://217.23.133.20/" - открывает сразу, без всякой задержки. В ХР ничего подобного не наблюдалось. Сама загрузка содержимого страниц, равно как и всевозможный даунлоадинг идёт бодренько, так что грешить на модем и настройки коннекта, вроде как, не след.