Ostatnie wiadomości
#1
Inne / Odp: Powłoki linuksa jak wybra...
Ostatnia wiadomość przez Piotr_1988 - Dzisiaj o 01:15:43 AMCytat: microsofter w Dzisiaj o 12:38:02 AMBash to powłoka używana głównie w GNU/Linuxie. Rzadko jest domyślna na innych systemach uniksowych, a niektóre z nich nie posiadają jej nawet w opcji. Przywiązując się do Basha, a zwłaszcza zaczynając od niego, skazujemy się na problemy przy pierwszej zmianie systemu.(1) Jak widać w tytule wątku, pytanie jest o powłokę dla Linuxa. (2) Mimo całej naszej sympatii do tych systemów, uczciwe będzie stwierdzenie, że zastosowanie *BSD i innych Unixów jest dość marginalne w porównaniu do Linuxa i raczej jeden na dziesiątki tysięcy użytkowników przesiadki Linux -> Unix w trakcie swojego życia dokona. Chyba, że mówimy o macOS.
Cytat: microsofter w Dzisiaj o 12:38:02 AMPisanie prostych skryptów w języku wysokiego poziomu, a następnie kompilacja, to dla mnie jakaś abstrakcja. Nie tylko dlatego, że nie jestem programistą, toteż jest to poza moimi możliwościami. Zwyczajnie, od zawsze stosuję najprosztszą powłokę, niezbędną dla danego skryptu - zadania które muszę wykonać. Czyli w Windows to jest CMD, a dopiero jeśli czegoś nie potrafi, sięgam po PowerShell. Podobnie w Unixie, używam Bourne lub C-Shella, a w razie czego Korn czeka w zanadrzu. Takie podejście dobrze sprawdza się, nie ma powodu aby komplikować proste rzeczy.Na myśli chyba masz języki niskiego poziomu, a nie wysokiego poziomu, a właściwie to średniego (niskiego jest Assembly). Owszem uchodzą ze średnio bardziej złożone, ale skoro w dzisiejszych czasach kod pisze nie człowiek, a sztuczna inteligencja, argument, że któryś z języków "jest trudny", odpada. Mogę poprosić np. Claude lub ChatGPT by mi napisały kod w jednym z conajmniej kilkudziesięciu języków i bez różnicy, czy język jest prosty, czy złożony, zajmie to sekundy...
#2
Inne / Odp: Powłoki linuksa jak wybra...
Ostatnia wiadomość przez microsofter - Dzisiaj o 12:38:02 AMBash to powłoka używana głównie w GNU/Linuxie. Rzadko jest domyślna na innych systemach uniksowych, a niektóre z nich nie posiadają jej nawet w opcji. Przywiązując się do Basha, a zwłaszcza zaczynając od niego, skazujemy się na problemy przy pierwszej zmianie systemu.
Co innego Bourne shell. Warto przyswoić go, wtedy możemy swobodnie przesiadać się pomiędzy BSD, GNU i Unixem SVR. Nasze skrypty, napisane dla sh, będą prawidłowo wykonane i pod Korn shellem, i powinny także pod Bashem. W drugą stronę to już nie zadziała.
Poza Linuxem, Bash nie cieszy się dobrą opinią i nie jest szczególnie lubiany. W środowiskach enterprise, Korn shell to standard.
Pisanie prostych skryptów w języku wysokiego poziomu, a następnie kompilacja, to dla mnie jakaś abstrakcja. Nie tylko dlatego, że nie jestem programistą, toteż jest to poza moimi możliwościami. Zwyczajnie, od zawsze stosuję najprosztszą powłokę, niezbędną dla danego skryptu - zadania które muszę wykonać. Czyli w Windows to jest CMD, a dopiero jeśli czegoś nie potrafi, sięgam po PowerShell. Podobnie w Unixie, używam Bourne lub C-Shella, a w razie czego Korn czeka w zanadrzu. Takie podejście dobrze sprawdza się, nie ma powodu aby komplikować proste rzeczy.
Co innego Bourne shell. Warto przyswoić go, wtedy możemy swobodnie przesiadać się pomiędzy BSD, GNU i Unixem SVR. Nasze skrypty, napisane dla sh, będą prawidłowo wykonane i pod Korn shellem, i powinny także pod Bashem. W drugą stronę to już nie zadziała.
Poza Linuxem, Bash nie cieszy się dobrą opinią i nie jest szczególnie lubiany. W środowiskach enterprise, Korn shell to standard.
Pisanie prostych skryptów w języku wysokiego poziomu, a następnie kompilacja, to dla mnie jakaś abstrakcja. Nie tylko dlatego, że nie jestem programistą, toteż jest to poza moimi możliwościami. Zwyczajnie, od zawsze stosuję najprosztszą powłokę, niezbędną dla danego skryptu - zadania które muszę wykonać. Czyli w Windows to jest CMD, a dopiero jeśli czegoś nie potrafi, sięgam po PowerShell. Podobnie w Unixie, używam Bourne lub C-Shella, a w razie czego Korn czeka w zanadrzu. Takie podejście dobrze sprawdza się, nie ma powodu aby komplikować proste rzeczy.
#3
Red Hat i Fedora / Odp: Problemy z wykryciem kont...
Ostatnia wiadomość przez linux4ever - Czerwiec 19, 2025, 07:15:54 PMCytat: żuroni w Czerwiec 19, 2025, 06:58:43 PMCytat: linux4ever w Czerwiec 19, 2025, 06:23:08 PMWybierz w prefiksie wine windows7 to powinno pomóc.Jak już wspomniałem jestem początkujący na linuxie i mam nadzieję że zmieniłem to prawidłowo ale nie pomogło.
Grę uruchamiam przez Steam, który był już w systemie i z tego co mi wiadomo to gry uruchamiają się za pomocą proton.
No jak sprawdziłem nie da się.
Pisałem o windows7 ponieważ powinien być w pełni kompatybilny ze wszystkimi grami na dx11.
Szkoda że tego nie da się zmienić.
Zostaje tylko jedno: sprawdź tryb analog na padzie w nim zarządza się gałkami pada zamiast przycisków czy coś w tym stylu.
#4
Red Hat i Fedora / Odp: Problemy z wykryciem kont...
Ostatnia wiadomość przez żuroni - Czerwiec 19, 2025, 06:58:43 PMCytat: linux4ever w Czerwiec 19, 2025, 06:23:08 PMWybierz w prefiksie wine windows7 to powinno pomóc.Jak już wspomniałem jestem początkujący na linuxie i mam nadzieję że zmieniłem to prawidłowo ale nie pomogło.
Grę uruchamiam przez Steam, który był już w systemie i z tego co mi wiadomo to gry uruchamiają się za pomocą proton.
#5
Red Hat i Fedora / Odp: Problemy z wykryciem kont...
Ostatnia wiadomość przez linux4ever - Czerwiec 19, 2025, 06:23:08 PMCytat: żuroni w Czerwiec 19, 2025, 06:17:41 PM@linux4ever gra chodzi na dx11.Cytat: linux4ever w Czerwiec 19, 2025, 05:16:59 PMPotrzebne ci winetricks do lepszego zarządzania ustawieniami.Mam zainstalowane ale nie bardzo wiem jak miało by mi to pomóc.
@żuroni
Wybierz w prefiksie wine windows7 to powinno pomóc.
Windows7 miał directx11.
#6
Red Hat i Fedora / Odp: Problemy z wykryciem kont...
Ostatnia wiadomość przez żuroni - Czerwiec 19, 2025, 06:17:41 PM@linux4ever gra chodzi na dx11.
Cytat: linux4ever w Czerwiec 19, 2025, 05:16:59 PMPotrzebne ci winetricks do lepszego zarządzania ustawieniami.Mam zainstalowane ale nie bardzo wiem jak miało by mi to pomóc.
#7
Red Hat i Fedora / Odp: Problemy z wykryciem kont...
Ostatnia wiadomość przez linux4ever - Czerwiec 19, 2025, 05:16:59 PM@żuroni a na jakim directx jest ta gra jeśli na dx9 wystarczy zainstalować dx9 sdk june 2010 bo to pełna ostatnia wersja.
Potrzebne ci winetricks do lepszego zarządzania ustawieniami.
Potrzebne ci winetricks do lepszego zarządzania ustawieniami.
#8
Inne / Odp: Powłoki linuksa jak wybra...
Ostatnia wiadomość przez Piotr_1988 - Czerwiec 19, 2025, 02:49:59 PMStandardem na Linuxie jest bash, więc początkujący użytkownik Linuxa ucząc się czegoś innego tylko utrudni sobie życie. Tu nie ma o czym dyskutować... 😉 Inna sprawa, że (1) zupełny początkujący raczej rzadko pisze własne skrypty i (2) w bash w moim odczuciu dość ciężko się coś pisze. Skrypty raczej łatwiej jest pisać w polskim języku programowania Amber opcjonalnie kompilowanym do bash. Prawdę powiedziawszy ja przestałem pisać skrypty, gdyż najpierw zaczęła za mnie je pisać sztuczna inteligencja, a później uznałem, że skoro już je za mnie pisze, niech pisze od razu w Rust zamiast w ślimaczym Bash. Jak teraz będę chciał jakiś skrypt, raczej niż pisać skrypt w bash lub czymkolwiek skryptowym, zagadam do Claude, by mi napisał odpowiedni program w Rust wykonujący dane operacje na plikach, itd. Poczekam kilkanaście sekund na wynik, zerknę, czy kod wygląda w porządku, a potem go skompiluję.
#9
Red Hat i Fedora / Odp: Problemy z wykryciem kont...
Ostatnia wiadomość przez Piotr_1988 - Czerwiec 19, 2025, 02:47:56 PM[post do usunięcia - przepraszam, umieściłem w złym wątku]
#10
Red Hat i Fedora / Problemy z wykryciem kontroler...
Ostatnia wiadomość przez żuroni - Czerwiec 19, 2025, 11:27:36 AMWitam. Niedawno przesiadłem się z Windows na Linux a wybór padł na Nobare.
Problem polega na błędnym wykrywaniu kontrolerów w grze MSFS2020.
Wszystkie kontrolery widziane są przez system i działają prawidłowo.
W grze msfs2020 kontroler taki jak joystick Thrustmaster Warthog Flight Stick widziany jest prawidłowo.
W Steam kontroler Honeycomb Bravo Throttle Quadrant widziany jako zwykły pad i tak samo widziany jest w MSFS2020 ale już orczyki TPR: Thrustmaster Pendular Rudder w grze nie są wykrywane wcale.
Dodam że nie bardzo znam się na linuxie a problem próbowałem rozwiązać za pomocą AI i jedyne co udało się zrobić to zrobić by gra prawidłowo wykryła moje orczyki ale niestety nie potrafię zrobić by moja przepustnica działała prawidłowo.
A tu streszczenie co było testowane przez AI:
1. Wyłączony Steam Input – globalnie i dla gry.
2. Próby blokowania Bravo jako pada:
- Zmienne środowiskowe SDL (SDL_GAMECONTROLLER_IGNORE_DEVICES, SDL_JOYSTICK_DEVICE_IGNORE)
- Reguły udev (SDL_JOYSTICK=0)
- Próby blokowania /dev/input/js0 przez udev
- Blacklistowanie modułu joydev (co skutecznie usuwa /dev/input/js0)
3. Ręczne dodanie profilu Bravo (inputprofile_Bravo.xml) do katalogu konfiguracyjnego MSFS – gra nie widzi profilu, bo nie widzi urządzenia.
4. Próby użycia protontricks/winetricks do instalacji dodatkowych bibliotek (dinput8, xinput, vcrun2019), z problemami z dostępem do prefixu i cache.
5. Testy z różnymi wersjami Protona (oficjalny, GE-Proton) – gra czasem nie startuje, czasem startuje bez zmian.
6. Dodanie pełnych uprawnień do systemu plików dla Flatpak Steam (flatpak override --filesystem=host) – bez efektu na wykrywanie Bravo.
Logi i szczegóły:
1. Logi Protona/Wine pokazują próby otwarcia urządzenia HID, ale kończą się na komunikatach typu not implemented lub semi-stub dla DirectInput/HIDAPI.
2. Bravo działa natywnie w Linuksie (np. X-Plane, FlightGear), ale nie w MSFS2020 pod Protonem.
Problem polega na błędnym wykrywaniu kontrolerów w grze MSFS2020.
Wszystkie kontrolery widziane są przez system i działają prawidłowo.
W grze msfs2020 kontroler taki jak joystick Thrustmaster Warthog Flight Stick widziany jest prawidłowo.
W Steam kontroler Honeycomb Bravo Throttle Quadrant widziany jako zwykły pad i tak samo widziany jest w MSFS2020 ale już orczyki TPR: Thrustmaster Pendular Rudder w grze nie są wykrywane wcale.
Dodam że nie bardzo znam się na linuxie a problem próbowałem rozwiązać za pomocą AI i jedyne co udało się zrobić to zrobić by gra prawidłowo wykryła moje orczyki ale niestety nie potrafię zrobić by moja przepustnica działała prawidłowo.
A tu streszczenie co było testowane przez AI:
1. Wyłączony Steam Input – globalnie i dla gry.
2. Próby blokowania Bravo jako pada:
- Zmienne środowiskowe SDL (SDL_GAMECONTROLLER_IGNORE_DEVICES, SDL_JOYSTICK_DEVICE_IGNORE)
- Reguły udev (SDL_JOYSTICK=0)
- Próby blokowania /dev/input/js0 przez udev
- Blacklistowanie modułu joydev (co skutecznie usuwa /dev/input/js0)
3. Ręczne dodanie profilu Bravo (inputprofile_Bravo.xml) do katalogu konfiguracyjnego MSFS – gra nie widzi profilu, bo nie widzi urządzenia.
4. Próby użycia protontricks/winetricks do instalacji dodatkowych bibliotek (dinput8, xinput, vcrun2019), z problemami z dostępem do prefixu i cache.
5. Testy z różnymi wersjami Protona (oficjalny, GE-Proton) – gra czasem nie startuje, czasem startuje bez zmian.
6. Dodanie pełnych uprawnień do systemu plików dla Flatpak Steam (flatpak override --filesystem=host) – bez efektu na wykrywanie Bravo.
Logi i szczegóły:
1. Logi Protona/Wine pokazują próby otwarcia urządzenia HID, ale kończą się na komunikatach typu not implemented lub semi-stub dla DirectInput/HIDAPI.
2. Bravo działa natywnie w Linuksie (np. X-Plane, FlightGear), ale nie w MSFS2020 pod Protonem.