Rating@Mail.ru
IPB
Etersoft - from Windows to Linux
Etersoft
решения для перехода
с Windows на Linux
Дружественные сайты: alv.me и Rus-Linux.net

Здравствуйте, гость ( Вход | Регистрация ) Поиск · 

Профиль
Фотография
Опции
Опции
О себе
PVOzerski не указал(а) ничего о себе.
Личная информация
PVOzerski
Завсегдатай
Возраст не указан
Мужской
SPb
День рождения не указан
Интересы
Нет данных
Другая информация
Операционная система: OpenSUSE, ALT Linux
JID: Нет данных
Город: СПб
Статистика
Регистрация: 30-September 09
Просмотров профиля: 21874*
Последнее посещение: 4th October 2016 - в 23:28
Часовой пояс: Oct 19 2017, в 20:20
297 сообщений (0.1 за день)
Контактная информация
AIM Нет данных
Yahoo Нет данных
ICQ Нет данных
MSN Нет данных
Contact E-mail скрыт
* Просмотры профиля обновляются каждый час

PVOzerski

Участники


Темы
Сообщения
Друзья
Содержимое
Несколько дней как наблюдаю при попытке зайти на некоторые сайты из 40-й оперы (из-под Debian jessie) следующий глюк: сначала безуспешные попытки пробиться на сайт, потом сообщение о превышении времени. С какого-то раза удается "пробиться", после этого всё работает нормально. Среди проблемных сайтов - facebook и официальное хранилище расширений от Оперы. Удаление сторонних расширений не помогает, полная переустановка оперы с уничтожением какталога настроек в ~/.config - тоже. При этом другие браузеры (Firefox, Chromium, Vivaldi) работают с этими сайтами штатным образом. Однако проблема воспроизвелась также на более старой Опере (36), запущенной в PCLinuxOS в виртуальной машине VirtualBox (хост - всё тот же Debian). Есть ли идеи, куда копать? Я уже на провайдера грешить начинаю, но все равно не понимаю, как можно добиться такого "браузер-селективного" эффекта.
10 Feb 2016
В связи с грядущим изменением лицензии ALT Linux начал я искать этому, вообще-то весьма добротному, дистру замену и решил пощупать Debian. Установил себе для начала на домашний комп стабильную сборку (Jessie 8.3) и начал изучать и эксплуатировать систему. Естественно, не всё оказалось гладко, причем виноваты были далеко не всегда мои кривые руки. Случалось и так, что источники проблем были со мной не связаны, по крайней мере прямо. А самый яркий случай, меня весьма впечатливший, произошел на днях.

Пару дней назад после очередного обновления я налетел на баг. Есть нюанс: баг, возможно, не проявился бы, если бы у меня не был установлен софт из сторонних реп. Однако проблема (кстати, неслабая: из-за нее KDE и wine не могли сосуществовать в одной системе) была вызвана неправильно собранным пакетом из официального репозитория. Вычислив этот пакет, я сделал сообщение о баге в официальную базу Debian. И получил примерно вот такой ответ: "Баг известен, имеет такой-то номер, пофиксен в testing-ветке, а в stable исправляться не будет". Ну ладно, у меня оказались достаточно прямые руки для того, чтобы локально на своем компе проблему разрешить. А если кто-то другой не справится? На форуме debianforum.ru в ответ на мое возмущение мне доходчиво стали разъяснять правоту разработчиков в духе "а нефиг сторонние репы подключать" и "хочешь свежий софт - ставь testing". Мое мнение, правда, таково: да, устаревший софт как таковой в этой ситуации официально обновлять в стабильной ветке не следует, но почему это должно относиться также и к явным багам?

К слову: мэйнтейнер одного из сторонних репозиториев (deb-multimedia.org) среагировал на аналогичное мое сообщение адекватно и оперативно, решив проблему обходным путем, не затрагивая бажного пакета. А у меня осталось весьма специфическое впечатление о политике разработчиков Debian. Вот, им и делюсь sad.gif
14 May 2015
Скрипт лежит вот здесь: https://gist.github.com/ruario/3ed0d3a6c0764c4ae9f9
С его помощью я получал пакеты вполне приемлемого качества для двух сборок Opera 28 и свежей Opera 29.

Единственная проблемка - работа с pepperflash по умолчанию не получается, потому что Опера не ищет этот плагин в той директории, куда ее кладет альтовая утилита update-pepperflash. Обходил ее так: вручную создавал каталог /opt/google/chrome/PepperFlash и делал в нем симлинки на /usr/lib64/pepper-plugins/libpepflashplayer.so и /usr/lib64/pepper-plugins/manifest.json с теми же названиями.
13 Nov 2014
Понадобилось установить 1-е на 2-е. Вариант с Libreoffice пришлось отмести, так как слабые компы (локальная сеть одного из подразделений НИИ smile.gif ) его не потянули: начались лютые тормоза. На 2 компах был установлен ALT Linux p7 Kdeskop - на одном 32-разрядный, на другом 64. В обоих случаях OOO Pro завелся нормально (на 1-м - 32-разрядный, на 2-м - 64-). На двух других - ALT Linux p7 Centaurus с установленным впоследствии KDE4. И вот тут трабл. Офис ставится, но отказывается работать с майкрософтскими форматами файлов: вордовские просто игнорит, про экселевские пишет о внутренней ошибке импорта. Симптоматика примерно такая, как здесь: https://bbs.archlinux.org/viewtopic.php?id=94372 (только сообщения по-русски) - но в сети описаны траблы с 3.2 и 4.x, а тут 3.3. Куда копать, не подскажете?
19 Oct 2014
Сразу говорю: обстоятельства, которые эту проблему вскрыли, довольно специфические - но сама проблема от этого проблемой быть не перестает. Возможно, она касается не только pae-ядер, а возможно - и не только сусевых. Хотя конкретно всё это происходит на OpenSUSE 13.1

У компа моего нового довольно новое "железо", капризничающее с линуксом. Конкретно - с гибернейтом. С uswsusp оно не дружит вообще. Через ядро (echo -n disk > /sys/power/state) до какого-то очередного обновления всё работало, но потом комп стал зависать на пробуждении. Лазанье по форумам навело на идею попробовать другие ядра. И действительно, с другими ядрами конкретно этот симптом исправился. Однако всплыл другой, и он, вероятно, касается не только моего "железа".
Я не пересобирал ядра, просто взял несколько готовых сборок pae-ядер, которые нашел через software.opensuse.org. Сборки делались разными людьми, что характерно. Так вот, все они выдавали один и тот же баг. Если просто стартануть машину "с нуля", то она нормально ребутится и выключается. Но вот если ее сначала вывести из спящего режима (напоминаю: используется ядро, а не uswsusp), то она зависает в процессе выключения или ребута. Сообщение в консоли: "Could not unmount /usr: Device or resource busy. Could finalize remaining file systems and devices, giving up". Гугл подсказал, что такой симптом бывал у каких-то совсем старых ядер и квалифицировался как баг. Ну да, /usr в отдельном разделе - это особенность моей конфигурации. Но, во-первых, у меня нет никакой уверенности, что /home отмонтировался тоже (до соответствующего сообщения дело просто могло не дойти), а во-вторых, это в любом случае не дело.

Некоторые из проверенных ядер:
3.12.28 (Amkubecek)
3.16.4 (Warhammer40k)
3.17.1 (giordanoboschetti)
3.17.1 (pontostroy)
Просмотры


7 Dec 2014 - 21:45


26 Nov 2012 - 0:04


7 Apr 2010 - 22:28


8 Mar 2010 - 1:57


2 Jan 2010 - 9:19


Друзья
Друзей нет.
RSS Текстовая версия Сейчас: 19th October 2017 - в 19:20




Rating@Mail.ru