Nie działa mi komenda trickle na wszystkich przeglądarkach (z wyjątkiem firefox).
Np. komenda trickle -s -d 64 opera , która powinna uruchomić przeglądarkę opera z ograniczeniem transferu przychodzącego do 64 KB/s (kiedyś to tak działało), obecnie:
uruchamia jedynie proces /usr/lib/opera/opera , który zajmuje tylko(!?) ok 9 MB pamięci,
nie otwiera się okno przeglądarki opera,
nie pojawiają się żadne komunikatu błędu w terminalu.
Normalnie, gdy uruchamiam operę bezpośrednio, proces /usr/lib/opera/opera , zajmuje ok 200 MB.
Identycznie (błędnie) wygląda to z przeglądarką palemoon, basilisk i chromium.
Czy macie to samo?
Jak ew. można rozwiązać ten problem?
Nie korzystam z programu, ale strzelam, że skoro program pochodzi z aur (są dwie wersje, być może z drugą jest w porządku) to mogą być jakieś różnice w wymaganych zależnościach, a wersjami pakietów, które posiadasz (lub jakieś inne konflikty wynikające z różnicy między Archem a Manjaro).
Edit: Ewentualnie problem może leżeć w tym, że Firefox w inny sposób obsługuje swoje procesy niż wszelkie przeglądarki chromopodobne.
Z testowanych przeglądarek palemoon i basilisk nie bazują na chromium.
Mają natomiast wspólne korzenie z Firefoxem (do Firefox-ESR wersja 52).
Jeszcze kilka miesięcy temu trickle działało poprawnie z każdą z tych przeglądarek.
ostatnio zacząłem korzystać z psd z czystej ciekawości i tak zostało
psd p
Profile-sync-daemon v6.34 on Arch Linux
Systemd service is currently active.
Systemd resync-timer is currently active.
Overlayfs technology is currently inactive.
Psd will manage the following per /home/lingruby/.config/psd/.psd.conf:
browser/psname: vivaldi-snapshot/vivaldi-bin
owner/group id: lingruby/985
sync target: /home/lingruby/.config/vivaldi-snapshot
tmpfs dir: /run/user/1000/lingruby-vivaldi-snapshot
profile size: 588M <- tu przed odpaleniem było 890M
recovery dirs: none
i powiem że działa zacnie
Kolejna sprawa korzystanie z chińskiej opery ( bo o takiej chyba mowa ) bo wersja 12 starej opery to chyba nie jest
to tak trochę… nawet jest gdzieś filmik na YT przez co idzie ruch w nowej operze
a co do stosowania Trickle w ówczesnym necie to takie trącenie myszką ( jak wszędzie jest b.o. )
Opera to jedna z kilku przeglądarek, z której akurat korzystam bardzo sporadycznie i wtedy nie przeszkadza mi, że jest chińska. Wymieniona została jedynie, jako przykład. Zostawmy ten poboczny wątek.
Korzystałem z trickle, gdy chciałem przyciąć transfer danej aplikacji (zasadniczo przeglądarce) i to było b. proste i skuteczne narzędzie.
Nie znam żadnej alternatywy w Manjaro dającej tą funkcjonalność. Jeśli znacie takową, to chętnie skorzystam.
Pomysł z przebudowaniem pakietu sprytny (i niewątpliwie będę z niego korzystał w podobnych sytuacjach w przyszłości). Ponownie zbudowana paczka trickle-1.07-11-x86_64.pkg.tar.xz różni się od tej poprzedniej, jednak, niestety, ciągle działa tak samo błędnie.
Może, to zmiany w kodzie przeglądarek, a może w bibliotekach - bezpośrednio zależy od dwóch, które zmieniły się parę miesięcy po ostatnich zmianach trickle, a te zależą od całej armii kolejnych. Pakiet nie był modyfikowany od prawie roku (co nie musi, ale może być problemem) i nawet, jeżeli chodzi pod Arch’em, to pod Manjaro nie ma obowiązku.
Sprawdź parametry, z jakimi możesz go uruchomić - być może któryś coś da.
Raz jeszcze sprawdziłem obie wersje: trickle i trickle-git z AUR i sygnalizowany problem zawsze występuje z przeglądarką opera, palemoon, basilisk, vivaldi i chromium, tj. np. polecenie: trickle -s -d 64 operaw ogóle nie otwiera okna przeglądarki.
Czy ktoś może potwierdzić/zaprzeczyć, czy u niego jest tak samo?
Sprawdziłem i potwierdzam, że Opera i Chromium się nie uruchamiają z podanego przez ciebie polecenia, ale Firefox i Surf już tak. Dalej nie grzebię, nie znam narzędzia i ostatnio nie mam zbytnio czasu na takie zabawy.
OK. Dzięki za weryfikację. Teraz wiem, że to nie jest problem tylko u mnie.
Znalazłem natomiast ciekawą alternatywę - pakiet traffictoll z AUR, który umożliwia ograniczyć ruch, zarówno globalnie, jak i dla poszczególnych pakietów/procesów.
Początkowo wydawało mi się, że on też nie działa, jednak, jak doświadczalnie odkryłem, w pakiecie tym posługują się (wg mojej wiedzy błędnym) oznaczeniem kbps, które nie jest traktowane wcale jako kilobity na sekundę, ale jako kilobajty na sekundę.
Zatem ustawiając tu np. download: 100kbps faktycznie ustawiamy prędkość 100 KBps (czyli faktycznie 800 kb/s).
Jeśli chodzi o blokowanie poszczególnych pakietów/procesów, to odkryłem, że sugerowany filtr np. dla Firefoxa: - exe: /usr/lib/firefox/firefox nie będzie wystarczający dla stron, gdzie uruchomi się kontener, więc należałoby zastosować szerszy filtr: - exe: /usr/lib/firefox/*
Wiedząc o tym, traffictoll działa b. sprawnie.
Reasumując, wprawdzie nie udało się naprawić trickle, ale traffictoll rozwiązał problem.
