Archiwum kategorii: linux

Sway w Waylandzie zamiast X-ów.

Wysłany by

Z X Window System szedłem przez życie, ale odkąd pierwszy raz przeczytałem o Wayland, od czasu do czasu sprawdzałem postępy w tym projekcie. Nie, żebym miał jakieś wielkie „ale” do X-ów, jednak na moje niewielkie potrzeby ta armata zawsze wydawała mi się zbyt wielkiego kalibru.

Mijały lata, zawsze czegoś jednak brakowało. Na początku duże „desktopy” jeszcze Wayland nie wspierały, później moja karta graficzna niezbyt działała (NV3100m, bo lubię stare laptopy). Aż w końcu nouveau i kernel polubiły się z moim retro-sprzętem i jest:

Najbardziej zaskoczył mnie sway. Złapał „w locie” moją konfigurację i3 na tyle skutecznie, że musiałem sie upewnić, czy to na pewno sway.

Zyn-fusion, Helm.

Wysłany by

Ostatnio eksperymentuje trochę z soft-syntezatorami na Linuksie i zupełnie przy okazji odkryłem Unfę:

Tobiasz jest żywym dowodem na to, że da się na Linuksie produkować muzykę, a wszystkie dźwięki na tej płycie powstały w zyn-fusion. Dla mnie to jest rewelacyjna zabawa w dźwięki, poznawanie skal i interwałów, których na gitarze nigdy nie mogłem ogarnąć ;), ale zarówno zyn-fusion jak i helm są po prostu świetne.

Minimalizm, czyli i3-wm + connman.

Wysłany by

Od kilku lat używałem Plasma Desktop, ale mój sprzęt nie jest bardzo szybki i czas startu tego środowiska zaczął być uciążliwy. Nie byłem przekonany co do tzw. tiling window managerów, jednak powoli zmieniam zdanie.
Zmiany środowiska zwykle generują problemy, które rozsądnie byłoby szybko rozwiązać. U mnie problemem okazał się Network Manager, którego szczerze mówiąc nigdy nie lubiłem. Wszystkie te dodatkowe warstwy (polkity i inne wynalazki) czasem po prostu wchodzą w drogę, jednak connman, jako alternatywa dla Network Managera sprawdził się doskonale i raczej na pewno zostanie u mnie na dłużej.

i3wm najbardziej trafnie określa powyższy zrzut ekranu. Po raz kolejny zdałem sobie sprawę, że tak na prawdę do pełni szczęścia potrzebny mi dobrze działający dostęp do sieci i programy typu dmenu i rofi jako wygodna alternatywa tzw. menu „Start”.

Szybkość i wygoda jest na tyle duża, że oba moje laptopy działają od dziś z i3-wm.

Jackd i PulseAudio.

Wysłany by

Jackd + Chromium albo Firefox = problem. Tak się jakoś porobiło w Linuksie, że PulseAudio stało się standardem w obsłudze audio i chyba nie ma w tym nic złego. Mimo tego, że Firefox w Archlinuksie  skompilowany jest z obsługą jackd, to wyjście jackd w FF nie działa. Na szczęście nie jestem z obozu ultra-tradycjonalistów i udało mi się szybko i prosto pożenić jackd z Pulseaudio.

Potrzebny będzie pakiet pulseaudio-jack zawierający module-jack-sink.so i module-jack-source.so​.  Do /etc/pulse/default.pa trzeba dodać te moduły:

load-module module-jack-sink
load-module module-jack-source

Każdorazowo po odpaleniu jackd pulseaudio musi zostać przeładowane: pulseaudio -k, a potem: pactl set-default-sink jack_out. Dzięki temu pulseaudio przekieruje audio systemowe na jackd, co pozwala jak w moim przypadku bębnić w realtime do kawałków na Youtube. Pozytywne jest to, że po ubiciu jackd, PulseAudio przywraca odtwarzanie na defaultowej karcie dźwiękowej „w locie”.

Przykre, że jackd nie jest traktowane jak należy, a użytkowników w niszy audio na Linuksie chyba nie ma wielu i od przynajmniej dekady nic się w temacie nie robi, żeby im ułatwić życie.

i686 out…

Wysłany by

Nieźle:

Due to the decreasing popularity of i686 among the developers and the community, we have decided to phase out the support of this architecture.

The decision means that February ISO will be the last that allows to install 32 bit Arch Linux. The next 9 months are deprecation period, during which i686 will be still receiving upgraded packages. Starting from November 2017, packaging and repository tools will no longer require that from maintainers, effectively making i686 unsupported.

 

Aspeqt na github.

Wysłany by

Aktualny deweloper Aspeqt pokłócił się z paroma osobami na forum Atari Age i dostał tam bana. W odwecie usunął wszystkie wprowadzone przez niego zmiany od wersji 0.6 do 1.0 i postanowił rozwijać to dalej w zaciszu swojego forum, udostępniając za opłatą. Szkoda.

Wrzuciłem ostatnie udostępione na AAge źródła 1.0.0 preview 6 do repo na Github.

https://github.com/greblus/aspeqt/tree/master

Nie mam jakichś wielkich planów, chciałbym kompilować od czasu do czasu aby działało na aktualnych wersjach bibliotek. Fajnie by było też zrobić nowe gui, bo aktualne jest beznadziejne, zwłaszcza na małych ekranach, ale to w wolnych chwilach.

Pierwszy pomysł jest taki: minimalna geometria okna i dynamiczne dodawanie slotów:

mini_aspeqtUpdate:

Tak sobie niezobowiązująco myślę… Jest port QT5 na Androida: http://doc.qt.io/qt-5/android-support.html muszę się więc zaznajomić z Android NDK. Nawet gdyby trzeba było Gui zrobić od nowa, zdecydowanie jest to do zrobienia.

FTDI też działa: http://www.ftdichip.com/Android.htm (sprawdzałem na tablecie z 4.2.2 i faktycznie, wygląda że to działa out-of-the-box).

Myślę, że przy odrobinie wolnego czasu można by to ze sobą pożenić. Jest w TME nawet FTDI w wersji zintegrowanej z kablem. SIO2PC zmieści się we wtyczce SIO. Dałoby się z tego zrobić coś fajnego ;).

Update: AspeQt na Androida tutaj.

Printf() pod Windows.

Wysłany by

Printf() pod Windows okazuje się sporo wolniejszy niż pod Linuksem.

printf_windowsParadoksalnie, jak widać powyżej, pythonowy print() jest ~3x szybszy od printf() z biblioteki standardowej Mingw-w64. Pod Linuksem na odwrót, 4x wolniejszy względem tego z libc.stdio:

print_linux

Poczytałem stdio.h i doszedłem do tego, że gdy  -D__USE_MINGW_ANSI_STDIO=1 używana jest funkcja printf() z Mingw (ponad 11 razy wolniejsza od printf() pod Linuksem) i tak jest „by default”.

Jeśli do gcc dodam  -D__USE_MINGW_ANSI_STDIO=0, używana jest wersja printf() z msvcrt.dll. Mimo, że ta funkcja ma swoje braki, różnica jest dość znaczna:

$ time ./fib_mingw_printf.exe 300000 > /dev/null

real 0m5.513s
user 0m0.000s
sys 0m0.031s

$ time ./fib_msvcrt_printf.exe 300000 > /dev/null

real 0m1.081s
user 0m0.015s
sys 0m0.000s

Jeszcze jedna ciekawostka: przekierowanie do /dev/null w MSYS2 (które jest prawdopodobnie mapowane na NUL) pod Windows jest powolne. Przekierowanie do pliku jest ~2x szybsze:

$ time ./fib_msvcrt_printf.exe 300000 > output.txt

real 0m0.562s
user 0m0.000s
sys 0m0.015s

(Pod Linuksem bez różnicy).

Na szczęście %timeit pozwala się przekonać, że kod generowany w tej samej wersji gcc pod Windows i pod Linuksem jest niemal tak samo wydajny.