„Zawieszenie” Linuxa

[mirekc]

I jeszcze żeby podrzucił Big Maca i duże frytki.

Sarkazm nie na miejscu. Ja naprawdę używam i chcę dalej używać tego co napisałem. No może z tymi CAD-ami to dawno temu, ale też używałem.

Nie ma takich systemów, oprócz Windows,

No właśnie: czyli jeden taki system jest, a przydała by się konkurencja. Przez wiele lat uważałem, że właśnie Windows jest najlepszym systemem na desktopy (laptopy notebooki itp.), dopóki Microsoft nie zaczął uzurpować sobie kontroli nad komputerami użytkowników.

i pewnie nigdy nie będzie.

I szkoda. Mam nadzieję że właśnie Linux będzie się rozwijał w tym kierunku.

Wątpię, czy zadowoliłoby cię nawet Apple.

Tego nie wiem. Systemy Apple zawsze były dla mnie za drogie, więc ich nie poznałem.

Obawiam się, że będziesz musiał sam go sobie napisać.

Obawiam się, że to niemożliwe. Nie jestem programistą a napisanie takiego systemu nie jest proste, o czym świadczy fiasko projektu ReactOS. To właśnie taki system wybrałbym dla siebie, gdyby wyszedł z fazy alfa i spełniał założenia projektu. Niestety teraz już na to za późno.

Ale jak zejdziesz na ziemię, jest w czym wybierać.

Ale w imię czego? Co miałbym zyskać? Ja nie jestem pasjonatem systemów operacyjnych. Włożona praca musi mi się opłacić, to znaczy efektem końcowym ma być wszechstronny system do codziennego użytkowania (a nie ,,dziabania" i eksperymentowania).

ps. Używanie Linuxa musi być frustrujące.

Zaczynam się przyzwyczajać.

[mirekc]

Zobacz sobie freebsd i haiku.

Używasz i polecasz, czy tylko tak sobie ,,rzuciłeś"? Bo ja testowałem haiku kilka lat temu i mnie nie zachwycił. Czyżby rozwinął się tak że osiągnął nową jakość? Co do freebsd to system na serwer, na desktopa wiele mu brakuje, nawet do Linuxa. Desktop i  serwer to całkiem inna bajka.

[PomPom]

Też bym poczytał coś więcej o Haiku i FreeBSD, skoro zostały polecone do przy tak wysokich wymaganiach. Jakie doświadczenia z używania Haiku i FreeBSD na desktopie?

[microsofter]

haiku.

Kontynuacja BeOS, który nigdy nie odniósł sukcesu, ciągnięta przez jego entuzjastów. Ciekawostka i nie sądzę, aby kiedykolwiek wyszedł poza niszę.

czyli jeden taki system jest, a przydała by się konkurencja. Przez wiele lat uważałem, że właśnie Windows jest najlepszym systemem na desktopy (laptopy notebooki itp.), dopóki Microsoft nie zaczął uzurpować sobie kontroli nad komputerami użytkowników.

Zgadzam się w 100%. Co do kontroli, to nawet Win10 da się w pełni ujarzmić - jest to możliwe, tylko wymaga o wiele więcej pracy i sztuczek, niż w starszych wersjach. Moim zdaniem, Microsoft nagrabił sobie, gdy zaczął blokować możliwość instalacji Win na starym sprzęcie, bez żadnych technicznych powodów. Ktoś kupi nowy komputer, a ktoś inny wybierze system uniksowy i pokaże MS środkowy palec.

Mam nadzieję że właśnie Linux będzie się rozwijał w tym kierunku.

Rozwija się dokładnie w przeciwnym kierunku w stosunku do pierwotnej koncepcji (darmowy Unix). Programiści, zamiast naprawiać błędy w Linuksie i dodawać brakujące funkcjonalności, ostatnio skupili się na grach.

napisanie takiego systemu nie jest proste, o czym świadczy fiasko projektu ReactOS. To właśnie taki system wybrałbym dla siebie, gdyby wyszedł z fazy alfa i spełniał założenia projektu. Niestety teraz już na to za późno.

Masz na myśli, że jego rozwój stanął, czy dotychczasowy brak sukcesu? ReactOS to wciąż alpha, bo projekt ruszył o wiele lat za późno i ma za mało programistów. MS szybciej wydaje nowe Windowsy, niż ekipa ReactOS nadąża z reimplementacją starych.

Ja nie jestem pasjonatem systemów operacyjnych. Włożona praca musi mi się opłacić, to znaczy efektem końcowym ma być wszechstronny system do codziennego użytkowania (a nie ,,dziabania" i eksperymentowania).

A może nie iść na kompromisy, tylko zamiast jednego systemu do wszystkiego, mieć 2 na raz? Nie mówię o dual-boot. Mam drugi komputer, kiedyś dostałem za darmo, teraz kupiłem tylko drugi TV (jako monitor) i stoją 2 obok siebie. Na jednym mam Unix jako ,,ten podstawowy", na drugim Windows, głównie do oglądania filmów i używania softu, króry nie jest dostępny na Unix (np. mapy).

Co do freebsd to system na serwer

FreeBSD błyszczy na serwerze dzięki swojemu legendarnemu network stackowi i podsystemowi storage, ale reklamuje się jako uniwersal (serwer/desktop). Domyślna instalacja jest bez GUI, to może powodać błędne pierwsze wrażenie.

na desktopa wiele mu brakuje, nawet do Linuxa. Desktop i  serwer to całkiem inna bajka.

To tym bardziej nie podejdzie ci Unix SVR. Zastanów się nad rozwiązaniem z dwoma kompami. Na chwilę obecną, za żadne skarby nie wróciłbym do jednego PC. Kosztowało mnie to jedynie 150 zł na drugi telewizor plazmowy. Wszystko, co trzeba do pełnej interoperacyjności, to doinstalować SaMBę + Sharity na Unixie i obsługę NFS na Windows (WinServer ma to out-of-the-box). Określone zadanie robisz na tym kompie, którego OS jest lepszy do danej czynności. Bez stresu i kompromisów.

[pavbaranov]

@mirekc - Kilka uwag i podpowiedzi.
1. Masz stosunkowo słaby sprzęt, procesy konwersji plików, zwłaszcza dużych są często dla takich systemów problematyczne. W pierwszej kolejności proponowałbym rezygnację z graficznych programów do konwersji plików i robić to w konsoli (ffmpeg da radę, a bez problemu znajdziesz w necie konkretną komendę, jakiej musisz użyć dla pożądanej przez Ciebie konwersji).
2. Często opisywane przez Ciebie zawieszenie występuje wówczas, gdy ze względu na zajęcie RAM system dokonuje konwersji w SWAP. Być może - jeśli to duży plik - należałoby choćby tymczasowo go rozszerzyć (jeśli jest to plik, to nie jest to duży problem).
3. Niekiedy dobrym pomysłem (znów kluczowa jest wielkość pliku) jest stworzenie (znów tymczasowo) jakiegoś RAMDysku i dokonanie operacji konwersji właśnie na tym dysku.
4. Czy można się zabezpieczyć przed takimi zawieszeniami? Powiedzmy tak: jeśli problem nie polega na jakiejś usterce programu (tzw. wycieki pamięci), to można. Są narzędzia dostępne w linuksie, które umożliwiają priorytetowanie pewnych zadań itp. Można zatem spróbować się tym pobawić. Zob. np. tu: https://wiki.archlinux.org/title/Improving_performance#Adjusting_priorities_of_processes

[mirekc]

@mirekc - Kilka uwag i podpowiedzi.
1. Masz stosunkowo słaby sprzęt, procesy konwersji plików, zwłaszcza dużych są często dla takich systemów problematyczne. W pierwszej kolejności proponowałbym rezygnację z graficznych programów do konwersji plików i robić to w konsoli (ffmpeg da radę, a bez problemu znajdziesz w necie konkretną komendę, jakiej musisz użyć dla pożądanej przez Ciebie konwersji).

Powiem tak: o ile w przypadku ,,czystej" konwersji 1:1 jest to prawda, o tyle gdy do tego dojdzie jeszcze prosta edycja (np. wycięcie fragmentu z dokładnym pozycjonowaniem co do klatki, zmiana rozdzielczości, likwidacja przeplotu, wybór ścieżki dźwiękowej ze zmianą jej formatu itp.) – na konsoli robi się mordęga. Da się, ale po co? Aplikacje graficzne ułatwiają pracę, po to zostały wymyślone. Do tego dochodzą jeszcze indywidualne przyzwyczajenia, a ja się dorywczo zajmuję przerabianiem plików video od ponad 20 lat (tyle że pod Windows, na Linuxie dopiero zaczynam).

2. Często opisywane przez Ciebie zawieszenie występuje wówczas, gdy ze względu na zajęcie RAM system dokonuje konwersji w SWAP. Być może - jeśli to duży plik - należałoby choćby tymczasowo go rozszerzyć (jeśli jest to plik, to nie jest to duży problem).

Ja to rozumiem. Spotykałem się z tym już wcześniej, również pod Windows (plik wymiany). Tyle że w tym drugim systemie można próbować wyprowadzić system z tego stanu bez brutalnego wyłączania (i zwykle się udaje), w Linuxie – nie. Stąd było moje pytanie, bo może jest jakiś sposób którego nie znam, albo jakiś sposób zapobiegania o którym nie wiem (w stylu np. limit RAM dla aplikacji). Wszystko inne to tylko poboczne dywagacje. A swap jest partycją.

3. Niekiedy dobrym pomysłem (znów kluczowa jest wielkość pliku) jest stworzenie (znów tymczasowo) jakiegoś RAMDysku i dokonanie operacji konwersji właśnie na tym dysku.

Z 4 GB RAM? Zapomnij.

4. Czy można się zabezpieczyć przed takimi zawieszeniami? Powiedzmy tak: jeśli problem nie polega na jakiejś usterce programu (tzw. wycieki pamięci), to można. Są narzędzia dostępne w linuksie, które umożliwiają priorytetowanie pewnych zadań itp. Można zatem spróbować się tym pobawić. Zob. np. tu: https://wiki.archlinux.org/title/Improving_performance#Adjusting_priorities_of_processes

Nie wgłębiałem się w to specjalnie (nie miałem czasu), ale na pierwszy rzut oka wygląda to na priorytetowanie zadań ze względu na przydział czasu CPU, o pamięci nie ma tam nic. Może się więc przydać, ale nie do tego o czym tu mówimy. Sprostuj, jeśli się mylę.

[microsofter]

3. Niekiedy dobrym pomysłem (znów kluczowa jest wielkość pliku) jest stworzenie (znów tymczasowo) jakiegoś RAMDysku i dokonanie operacji konwersji właśnie na tym dysku.

Jeśli walczymy z brakiem RAMu, to taka czynność przyniesie skutek odwrotny do zamierzonego

Spotykałem się z tym już wcześniej, również pod Windows (plik wymiany). Tyle że w tym drugim systemie można próbować wyprowadzić system z tego stanu bez brutalnego wyłączania (i zwykle się udaje), w Linuxie – nie. Stąd było moje pytanie, bo może jest jakiś sposób którego nie znam, albo jakiś sposób zapobiegania o którym nie wiem (w stylu np. limit RAM dla aplikacji).

Unix oferuje szerokie możliwości automatyzacji. Napisałem sobie skrypt dla Korn shella, który, oprócz tworzenia snapshotu, sprawdza wolne miejsce w puli ZFS i - w razie potrzeby - automatycznie kasuje najstarszy snapshot(y). Jak ogarniasz Bourne/Korn shella, możesz stworzyć podobny skrypt monitorujący RAM, który będzie ubijał twój program do konwersji wideo. Musisz tylko właściwie dobrać próg działania komendy kill. Ustawiasz crona, żeby odpalał skrypt co minutę i gotowe.

Ksh+cron dają naprawdę potężne możliwości. Musisz poświęcić czas na stworzenie i dopracowanie skryptów, ale potem tylko patrzysz, jak system sam wszystko robi, dostosowując przebieg akcji do wielu zmiennych.

[mirekc]

Unix oferuje szerokie możliwości automatyzacji. Napisałem sobie skrypt dla Korn shella, który, oprócz tworzenia snapshotu, sprawdza wolne miejsce w puli ZFS i - w razie potrzeby - automatycznie kasuje najstarszy snapshot(y). Jak ogarniasz Bourne/Korn shella, możesz stworzyć podobny skrypt monitorujący RAM, który będzie ubijał twój program do konwersji wideo. Musisz tylko właściwie dobrać próg działania komendy kill. Ustawiasz crona, żeby odpalał skrypt co minutę i gotowe.

To jest pomysł i rozważę go jeśli się okaże, że problem jest uciążliwy. Na razie wygląda że wystarczy nie zostawiać nieużywanych aplikacji w tle (a zwłaszcza Firefoxa).

[pavbaranov]

3. Niekiedy dobrym pomysłem (znów kluczowa jest wielkość pliku) jest stworzenie (znów tymczasowo) jakiegoś RAMDysku i dokonanie operacji konwersji właśnie na tym dysku.

Jeśli walczymy z brakiem RAMu, to taka czynność przyniesie skutek odwrotny do zamierzonego

Jeśli RAM utworzymy "na stałe", to oczywiście tak, ale jeśli dla wykonania określonego zadania, to już niekoniecznie. Przy małej ilości RAM programy "walczą" ze sobą o niego, co powoduje, że część zrzucana jest do SWAP. Przy zasobożernych czynnościach efekt jest taki, jak opisany na wstępie: zawieszenie (choć nie powinno tak długo mimo wszystko trwać). Uruchamiając dysk w RAM ograniczymy wprawdzie pamięć dla innych programów, ale jednocześnie najbardziej potrzebujący go proces (konwersja pliku wideo) zostanie przeprowadzona w nim sprawniej i nie dojdzie (nie powinno dojść) do zawieszenia systemu. Pozostałe programy natomiast w istocie będą się gnieździły w dostępnym im RAM, ale winny sobie z tym dać radę. Chyba, że znów będzie to coś mocno zasobożernego.
Inna sprawa, że przyglądnąłbym się temu Firefox, albowiem użycie procesora przez niego jest olbrzymie. Albo otwartych jest sporo zakładek i to zwłaszcza z treściami multimedialnymi w dodatku w sesjach prywatnych (wówczas FF tak się potrafi zachować), albo trzeba by pomyśleć nad czy to zmianą jego wersji, czy używaniem w takiej sytuacji innej, mniej zasobożernej sytuacji.
Tak, czy inaczej - spróbowałbym. Niewiele się traci (wyłącznie chwila czasu na tworzenie RAMDisc), a może się okazać dobrym pomysłem.

[mirekc]

Tak, czy inaczej - spróbowałbym. Niewiele się traci (wyłącznie chwila czasu na tworzenie RAMDisc), a może się okazać dobrym pomysłem.

Wydajność konwersji niewiele zależy od wydajności dysku. To jest zadanie które ,,jedzie" po CPU. No ale załóżmy, że jednak zdecydowałbym się na RAM dysk. Przeciętna wielkość pliku wejściowego to jakieś 1,5 GB, wyjściowego gdzieś tak 0,85 GB (zwykle zmniejszam rozdzielczość i coś wycinam co daje mniejszy plik). Prawdopodobnie powstaje jeszcze jakiś plik tymczasowy (w tej chwili nie jestem pewny). Jeśli ma być jakikolwiek wzrost wydajności, to wszystkie te pliki musiałyby znaleźć się na RAM dysku. Czyli co: 3 GB RAM dysk? Ale mam tylko 4 GB RAM, więc wtedy dla systemu i aplikacji zostałby 1 GB. Uważam, że rację ma microsofter. W ten sposób można tylko pogorszyć sytuację i to drastycznie.

[microsofter]

Optymalnie jest tak gospodarować RAMem, aby OS lekko swapował, z naciskiem na lekko. Kiedyś dużo edytowałem ścieżki audio. Stare czasy, miałem wtedy 128 MB RAM. Minuta dźwięku w jakości CD to 10 MB, toteż standardową, kilkuminutową piosenkę, najszybciej obrabiało się w RAMie. Program tylko wczytywał plik i na końcu zapisywał go, a sama obróbka (cięcie) odbywała się błyskawicznie. Natomiast przy dłuższych utworach, ta metoda zmuszała system do takiego swapowania, że szybciej było obrabiać plik bezpośrednio na HDD, przepisując go przy każdej operacji.

Piszecie o tworzeniu RAM-dysku, rozmiarach RAM-dysku. Czy dobrze rozumiem, że MX Linux nie posiada dynamicznie alokowanego RAM-dysku? jak to wygląda w innych distrach linuxowych? Solaris ma dynamiczny RAM-dysk z pudełka. Jest automatycznie montowany jako /tmp:

Kod [Zaznacz] Rozwiń

# mount | grep tmp
/tmp on swap read/write/setuid/devices/rstchown/xattr/dev=4a00002 on Wt st  9 03:53:06 2024
# df -h | grep tmp
swap                   1,7G    15M   1,7G     1%    /tmp

Po starcie ten dysk nic nie zabiera pamięci. Później, im więcej tu wrzucicie, tym bardziej wzrasta zajęta pamięć, i na odwrót przy kasowaniu zawartości. I znowu, da się tu skopiować np. obraz ISO, lecz powyżej pewnego rozmiaru traci to sens, bo zmusza system do intensywnego swapowania.

Dziwne, jeśli Linux nie posiada podobnego rozwiązania RAM-dysku. Solaris ma to już od bardzo dawna, nawet nie pamiętam kiedy pojawiło się.

[pavbaranov]

@mirekc - Ten RAMDisc u Ciebie w takim razie sensu nie ma. Pobawiłbym się w takim razie tym priorytetowaniem zadań. Z opisu mogę jedynie przypuszczać, że po prostu CPU się "zatyka". Albo zatem puszczasz konwersję i komputer zasadniczo niemal tylko do tego służy (pasjansa możesz sobie być może postawić), albo - w zależności co jest dla Ciebie priorytetem - dajesz niższy konwersji (będzie długo trwać, bo korzystać z CPU jedynie, gdy ten w miarę wolny), albo wyższy konwersji (ale wówczas korzystanie np. z przeglądarki może trwać wieki).

[mirekc]

Z opisu mogę jedynie przypuszczać, że po prostu CPU się "zatyka".

Podczas konwersji obciążenie CPU jest bliskie 100%, ale to jest normalne. Jednak w opisanej przeze mnie sytuacji konwersja już się zakończyła, a system nadal był ,,zatkany". Przy tym intensywnie pracował dysk, co według mnie sugeruje, że chodzi jednak o pamięć i swap. Jednakże pewności nie mam, bo przy ,,zatkanym" systemie jakakolwiek diagnostyka nie była możliwa. Nie reagował na nic.

Albo zatem puszczasz konwersję i komputer zasadniczo niemal tylko do tego służy (pasjansa możesz sobie być może postawić),

Zasadniczo tak właśnie ma być. Zostawiłem otwartą przeglądarkę i pocztę bo nie spodziewałem się kłopotów i na początku nic na to nie wskazywało. Wcześniej kiedy konwersja była jedynym zadaniem, problemów nie było.