Re: firefox + suspend to disk
Artem Chuprina wrote: > Stanislav Maslovski -> debian-russian@lists.debian.org @ Wed, 6 Mar 2019 > 11:44:41 +: > > > Ещё одна странность, замеченная после апгрейда до testing. Если на > > момент перехода в спячку (hibernate) был запущен Firefox c несколькими > > открытыми табами, система весьма долго приходит в себя после > > просыпания. Даже после появления на экране иксовой картинки, проходит > > несколько минут (!), прежде чем ноут прохрюкается (HDD все это время > > активен и система жутко лагает) и можно будет начать работать. > > > Все это происходит на ноуте с i5-2410M CPU @ 2.30GHz и 4 GB RAM, из > > которых минимум 50% обычно свободно. Как-то раньше такого торможения > > на нем не замечалось... > > По моему опыту FF с открытыми табами жрет поболе гига собственно памяти > и 3 с фигом виртуальной. Поэтому я его даже перед suspend-to-ram > выключаю, оно даже оттуда тормозит. Jessie, 6 GB RAM. Хм. Можно поподробнее? Никогда ничего такого не замечал, ни раньше, ни сейчас, ни с одним гигабайтом, ни с восемью. Впрочем, более полусотни окон Файрфокса я редко держу, ибо подтормаживать начинает уже во время бодрствования. Но так или иначе, никаких сверхобычных тормозов после подъема не творится. Да и не должно никак, насколько я вообще понимаю устройство спячки-в-памяти. > Так что ежели оно из гибернейта чекает все свои 3 с фигом гига > виртуальной памяти, то боюсь, кроме как принудительно прибивать его из > скрипта засыпания... Да в общем-то не велика эта задачка — считать пару-другую гигабайт с диска в память. Нескольких минут на это не надо. Тут что-то не то. А точно ли это Файрфокс что-то читает (пишет), а не кто-то другой начинает козлить, когда памяти не хватает? Можно, не копаясь в трассировках, поставить для начала такой простой опыт: разнести подъем во времени, для чего *остановить* Файрфокс, затем усыпить машинку, разбудить машинку, и только потом отпустить Файрфокс, — и оценить итог на глаз. signature.asc Description: PGP signature
[DONE] wml://security/2019/dsa-4402.wml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - --- ../../english/security/2019/dsa-4402.wml 2019-03-06 19:08:45.849743007 +0500 +++ 2019/dsa-4402.wml 2019-03-06 19:11:15.774996019 +0500 @@ -1,19 +1,20 @@ - -security update +#use wml::debian::translation-check translation="cdc990cfe6ed5dda7be8306834dce6def395036b" mindelta="1" maintainer="Lev Lamberov" +обновление безопасности - -It was discovered that insufficient restrictions in the connection - -handling of Mumble, a low latency encrypted VoIP client, could result in - -denial of service. +Было обнаружено, что недостаточные ограничения в коде для обработки +соединений в Mumble, VoIP-клиенте с низкой задержкой и шифрованием, могут +приводить к отказу в обслуживании. - -For the stable distribution (stretch), this problem has been fixed in - -version 1.2.18-1+deb9u1. +В стабильном выпуске (stretch) эта проблема была исправлена в +версии 1.2.18-1+deb9u1. - -We recommend that you upgrade your mumble packages. +Рекомендуется обновить пакеты mumble. - -For the detailed security status of mumble please refer to - -its security tracker page at: - -https://security-tracker.debian.org/tracker/mumble;>https://security-tracker.debian.org/tracker/mumble +С подробным статусом поддержки безопасности mumble можно ознакомиться на +соответствующей странице отслеживания безопасности по адресу +https://security-tracker.debian.org/tracker/mumble;>\ +https://security-tracker.debian.org/tracker/mumble # do not modify the following line #include "$(ENGLISHDIR)/security/2019/dsa-4402.data" - -# $Id: $ -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE3mumcdV9mwCc9oZQXudu4gIW0qUFAlx/1TAACgkQXudu4gIW 0qWejA/+NY6UAacNeB8oEpLMiPie6HZRxdDbW6OrCkfFYSG5LyIHDGRm5erkZ9Km CEqhLUPJoXiYYdcvnipQWgndCK8V38IYlgCVsqefWpfgeonrxPJgbwKKsb1Rkq6D vxhs4TGuatW7eahwuUNarC9Y+d0ZThUhIA8bAI0kPOKMvumAJ2a9wAwnx+tJQivJ Al9mY2uo0pocIbxCQIs1YfEsySPmrcecCiiSQpjL/K8dWqr8IgINzEAwJPaqwh3w kxrCKwDbUkQ9vmBYQiUfIaU5MTBJDHAe9++kR+strn5D9J/eSOq0RpfRr/PqsHpA OztdL+Xsxb9CL7aVjFnKUenVCX405OFEj0p9VhscjpsckYOpRcXoKN3C6+OmwWhH 6rVtQVr5iWdhn8hMPhuEuaW4tQQDmrVSHDCjikNyqvS8es4cnJX+xEBhrg5W85bU C6cp8TQjPhRr/Uo2u+2n9o1dXkWxjtverg8oyTcB+Vv0V/9i2lw0LD0PK48qGrgn OnO/t0jJ3dcAco/sObPJ08V4/Ycce2V4QCIbFf5PkhDqJsjOp72zL+0rHSIWWvsX rQ54mf+vz2fezf3rvjJLg437VcHaGgC+6V+g7b0Pf4/jD2J0hUCsGe4R6HVMQwDl u/yK4ycWK7weFxJPaTBlM7Zmo5e8gAAylRrWjUv3XUfe90cA3l8= =jr0f -END PGP SIGNATURE-
Re: firefox + suspend to disk
On Wed, Mar 06, 2019 at 04:32:19PM +0300, Artem Chuprina wrote: > > По моему опыту FF с открытыми табами жрет поболе гига собственно памяти > и 3 с фигом виртуальной. Поэтому я его даже перед suspend-to-ram > выключаю, оно даже оттуда тормозит. Jessie, 6 GB RAM. > > Так что ежели оно из гибернейта чекает все свои 3 с фигом гига > виртуальной памяти, то боюсь, кроме как принудительно прибивать его из > скрипта засыпания... В Firefox 67 вроде выгрузку вкладок из памяти сделали
Re: firefox + suspend to disk
On Wed, Mar 06, 2019 at 04:32:19PM +0300, Artem Chuprina wrote: > Stanislav Maslovski -> debian-russian@lists.debian.org @ Wed, 6 Mar 2019 > 11:44:41 +: > По моему опыту FF с открытыми табами жрет поболе гига собственно памяти > и 3 с фигом виртуальной. Поэтому я его даже перед suspend-to-ram > выключаю, оно даже оттуда тормозит. Jessie, 6 GB RAM. Субъективно, тормоза и на jessie были, но как-то не так все было жутко. Пробовал с chromium - там все ещё хуже. Память сжирается в момент, причём, всего-то с 3-4 открытыми табами. И течёт. Куда мир катится... > Так что ежели оно из гибернейта чекает все свои 3 с фигом гига > виртуальной памяти, то боюсь, кроме как принудительно прибивать его из > скрипта засыпания... Видимо, да. -- Stanislav
Re: firefox + suspend to disk
Stanislav Maslovski -> debian-russian@lists.debian.org @ Wed, 6 Mar 2019 11:44:41 +: > Ещё одна странность, замеченная после апгрейда до testing. Если на > момент перехода в спячку (hibernate) был запущен Firefox c несколькими > открытыми табами, система весьма долго приходит в себя после > просыпания. Даже после появления на экране иксовой картинки, проходит > несколько минут (!), прежде чем ноут прохрюкается (HDD все это время > активен и система жутко лагает) и можно будет начать работать. > Все это происходит на ноуте с i5-2410M CPU @ 2.30GHz и 4 GB RAM, из > которых минимум 50% обычно свободно. Как-то раньше такого торможения > на нем не замечалось... > Что с этим можно сделать? По моему опыту FF с открытыми табами жрет поболе гига собственно памяти и 3 с фигом виртуальной. Поэтому я его даже перед suspend-to-ram выключаю, оно даже оттуда тормозит. Jessie, 6 GB RAM. Так что ежели оно из гибернейта чекает все свои 3 с фигом гига виртуальной памяти, то боюсь, кроме как принудительно прибивать его из скрипта засыпания...
Re: Генерация pool-based репозиториев
Eugene Berdnikov wrote: > On Tue, Mar 05, 2019 at 09:58:17PM +0300, Andrey Jr. Melnikov wrote: > > Eugene Berdnikov wrote: > > > On Mon, Mar 04, 2019 at 04:19:58PM +0300, Andrey Jr. Melnikov wrote: > > > > Eugene Berdnikov wrote: > > > > > On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote: > > > ... > > > > > > > в принципе, залить файлы в хранилище много ума не нужно. > > > > > > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще > > > > > > какую-то > > > > > > экзотику и работать с ней как с локальным диском - бесценно. > > > > > > У меня reprepro свято уверен, что репозиторий на локальной машине. > > > > > > > > > А у меня, к сожалению, нет уверенности в том, что при моргании сети, > > > > > на которое fuse выбросит I/O error, твоя приблуда не сломает > > > > > репозиторий. > > > > > Потому как автор её скорее всего просто не предполагал, что > > > > > репозиторий > > > > > может быть удалённым, а дороги к нему будут перепаханы и минированы. > > > > Он всегда такой, т.к. любая софтина пишет в неведомые дали. Эт вы просто > > > > привыкли, что типа "жосткий диск" он "рядом". > > > > > Не только я, всё человечество к этому привыкло. Все пишут софт под > > > эту парадигму, потому что диск в системнике и бэкап в соседнем это > > > для большинства задач нормально по надёжности и оптимально по деньгам. > > > > Что-то тут у вас, бгатенька, не сходится. Если при записи воонтаго файла > > диск радостно отрапортовал UNC и ошибка поднялась до write(...) = -EIO а > > софтина этого не заметила - > Заметила или нет неважно, главное что сломала базу/репозиторий/etc. > Пому что в 99% случаев софтописатель не проверяет на EIO и вообще > транзакционной целостностью не озабочен. Он знает, что диски достаточно > надёжны: сбой может случиться через 5, 10 или 15 лет, и, как правило, > smartd поднимет тревогу до того, как диску придёт капец. Ага. Блаженны верующие. Предыдущий SSD от OCZ сказал кря без объявления войны, просто нагревшись контроллером градусов до 80 и отвалившись от интерфейса. smartd даже не взвизгнуло. Нагрузки на него не было, он просто был подключен. > А сетевой диск через fuse сбойнёт если не завтра, то послезавтра точно, > и что смешно, никто об этом заранее не предупредит. Да верьте в ваш S.M.A.R.T. верьте, вам никто не запрещает. Только вот еще может по дороге китайский кабель попасться, который рассохнется и отвалится и еще миллион причин. Но верить в smartd надежнее, я понимаю. > > так ну её в /dev/null ту софтину. Каким образом > > поможет от этого бакап - моя не понимайт. Его то на данный момент нету? > Бэкап есть, вчерашний. Только с обычным диском он может вообще никогда > не понадобиться, а с сетевым может понадобиться три раза за день. :) > Почувствуйте разницу. Мы говорим о разном. В моём случае тот бакап нужен был на 5 минут назад. Датасет то который писали в диск - проё, в бакапе его нет и хорошо, что это у нас репозиторий, который можно просканировать и создать датасет по новой, а не какие-нибудь скажем логи от невдомой херни, которые именно такими уже не получишь. > А насчёт "софтину в /dev/null" это скажи своему работодателю. Возможно, > он тебе ответит, что тебе лучше отдохнуть полгода-год за свой счёт, > а на досуге почитать что-нибудь про технологии работы с различного рода > ошибками -- аппаратными, сетевыми, человеческими и т.п., и что твоя > задача из ненадёжных дисков, глючных материнок и полных багов софтверных > продуктов строить надёжные ИС для его бизнеса. А если ты не умеешь > или не хочешь это делать -- найдутся другие, которые не станут ныть > и предлагать переписать 1С с нуля. Ты свой пафос то поприкрути, а то перегорит от перегрева. В случае с отстойным 1С - за дядин счет можно хоть в 8 ЦОДах держать ноды с синхронной репликацией. Ну и бакап этой 1С можно из бумажек раскатывать, зря их чтоль 3 года хранят в любой лавке? А мне нужно - для себя и с минимумом затрат. И жена стойку в кладовке не оценит и жить в серверной я не готов. А платить всем по периметру за "трехзвенки", "транзакции" и прочие "дедупликации" over модная-хипстерская-технолоджи и прочие линки в терабиты до хранилищ в петабайты - совсем не готов. Пропертарь выкинуть в /dev/null - готов. И даже opensource поправить под себя - готов. А работать на работодателей, которые будут мне рассказывать с чем и как мне работать - не готов. Они вмести со своим совтом идут в /dev/null, в обнимку. PS: и как показывает практика - самая нужная 1С, она стоит в одном экземпляре у буха на ноуте и НИКУДА НЕ РЕПЛИЦИРУЕТСЯ. Хорошо, если кто-нибудь умный сделал шифрованные бакапы в халявную помойку.
firefox + suspend to disk
Доброго времени суток! Ещё одна странность, замеченная после апгрейда до testing. Если на момент перехода в спячку (hibernate) был запущен Firefox c несколькими открытыми табами, система весьма долго приходит в себя после просыпания. Даже после появления на экране иксовой картинки, проходит несколько минут (!), прежде чем ноут прохрюкается (HDD все это время активен и система жутко лагает) и можно будет начать работать. Все это происходит на ноуте с i5-2410M CPU @ 2.30GHz и 4 GB RAM, из которых минимум 50% обычно свободно. Как-то раньше такого торможения на нем не замечалось... Что с этим можно сделать? -- Stanislav
Re: Генерация pool-based репозиториев
On 02/03/2019 11:52, Igor Savluk wrote: Для твоих запросов тебе всеравно прийдется использовать утилиту с бд. Без них нет утилит. А я думал только на лоре не принято по ссылкам ходить. https://wiki.debian.org/DebianRepository/Setup#mini-dak * No database (the pool is the database) https://wiki.debian.org/DebianRepository/Setup#mini-dinstall * Doesn't require a PostgreSQL database. -- sergio.
Re: Генерация pool-based репозиториев
On Tue, Mar 05, 2019 at 09:58:17PM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov wrote: > > On Mon, Mar 04, 2019 at 04:19:58PM +0300, Andrey Jr. Melnikov wrote: > > > Eugene Berdnikov wrote: > > > > On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote: > > ... > > > > > > в принципе, залить файлы в хранилище много ума не нужно. > > > > > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще > > > > > какую-то > > > > > экзотику и работать с ней как с локальным диском - бесценно. > > > > > У меня reprepro свято уверен, что репозиторий на локальной машине. > > > > > > > А у меня, к сожалению, нет уверенности в том, что при моргании сети, > > > > на которое fuse выбросит I/O error, твоя приблуда не сломает > > > > репозиторий. > > > > Потому как автор её скорее всего просто не предполагал, что репозиторий > > > > может быть удалённым, а дороги к нему будут перепаханы и минированы. > > > Он всегда такой, т.к. любая софтина пишет в неведомые дали. Эт вы просто > > > привыкли, что типа "жосткий диск" он "рядом". > > > Не только я, всё человечество к этому привыкло. Все пишут софт под > > эту парадигму, потому что диск в системнике и бэкап в соседнем это > > для большинства задач нормально по надёжности и оптимально по деньгам. > > Что-то тут у вас, бгатенька, не сходится. Если при записи воонтаго файла > диск радостно отрапортовал UNC и ошибка поднялась до write(...) = -EIO а > софтина этого не заметила - Заметила или нет неважно, главное что сломала базу/репозиторий/etc. Пому что в 99% случаев софтописатель не проверяет на EIO и вообще транзакционной целостностью не озабочен. Он знает, что диски достаточно надёжны: сбой может случиться через 5, 10 или 15 лет, и, как правило, smartd поднимет тревогу до того, как диску придёт капец. А сетевой диск через fuse сбойнёт если не завтра, то послезавтра точно, и что смешно, никто об этом заранее не предупредит. > так ну её в /dev/null ту софтину. Каким образом > поможет от этого бакап - моя не понимайт. Его то на данный момент нету? Бэкап есть, вчерашний. Только с обычным диском он может вообще никогда не понадобиться, а с сетевым может понадобиться три раза за день. :) Почувствуйте разницу. А насчёт "софтину в /dev/null" это скажи своему работодателю. Возможно, он тебе ответит, что тебе лучше отдохнуть полгода-год за свой счёт, а на досуге почитать что-нибудь про технологии работы с различного рода ошибками -- аппаратными, сетевыми, человеческими и т.п., и что твоя задача из ненадёжных дисков, глючных материнок и полных багов софтверных продуктов строить надёжные ИС для его бизнеса. А если ты не умеешь или не хочешь это делать -- найдутся другие, которые не станут ныть и предлагать переписать 1С с нуля. -- Eugene Berdnikov
