Czym to się różni w praktyce od kas samoobsługowych w Polsce?

Czy jest jakiś cel rozwoju tych wszystkich klawiatur mechanicznych? Są jakieś ideały do których się dąży?

Myślę, że jest szereg kierunków rozwoju i każdy sam definiuje sobie, czy któryś z nich go interesuje.
Ja np. poszedłem w kierunku klawiatur programowalnych, bo mam swój fork QMK z różnymi usprawnieniami.
Są też ludzie, których interesuje bardziej ergonomia (klawiatury dzielone/ortoliniowe), akustyka albo wygląd. Jeszcze inna nisza dąży do minimalizacji liczby klawiszy.

Koleś na filmiku na pewno robi sobie reklamę, ale o tuningu klawiatur powiedział prawdę.
Mi wystarcza przesmarowanie stabilizatorów, ale niektórzy wymieniają i smarują sprężyny w każdym przełączniku i wkładają na PCB różne folie/gąbki, żeby dopasować dźwięk do swoich preferencji.
Odnośnie ideałów, kiedyś modne były przełączniki “klikające”. Dzisiaj bardziej popularne są przytłumione dźwięki (tzw. “thock”).

Nie zwracałem uwagi na ksiązki. W takim układzie (wymieszane z kwiatkami) uznałem, że są dekoracjami.

Nie wiedziałem, że tam były 3 “kernele”. Ciekawe czy utrzymywały je oddzielne zespoły.

Widzę, że Amigę i Atari już ktoś wsadził do obudowy rackowej. C64 nie mogłem znaleźć.

Czyli Cosmic naśladuje Windows 10 z wymieszanymi stylami aplikacji z 3 frameworków?

Czy geohotowi nie udało się jednak zrobić tego frameworku do NN?

O nie, szpiegostwo przemysłowe!

Żartuję, ochrona właśności intelektualnej nie działa poprzez granicę z Chinami (w obie strony). :-)

No i tak właśnie robię. Chcę napisać narzędzie, które wizualizuje flow przetwarzania jakichś danych w dość skomplikowanym systemie. Celem jest ułatwienie analizy niedziałających przypadków na maszynach deweloperów.

Wprowadzenie takiego tracingu na poziomie kodu źrodłowego jest trywialne, ale wtedy zaczynają się pytania o wpływ na wydajność, utrzymanie tego mechanizmu, itp.

Lepiej integrować ten mechanizm na etapie budowania kodu na maszynie dewelopera, albo jeszcze później, hookując kluczowe miejsca w gotowej binarce.
Tak naprawdę to problem rozwiązałoby reflection z C++26, ale sporo czasu minie, zanim ta wersja pojawi się w toolchainie :-)

Odniosłem wrażenie, że oryginalna implementacja na automaty była nieźle przekombinowana.
Z drugiej strony, automaty produkuje się w ograniczonej liczbie sztuk, więc może koszt optymalizacji software’u był w tych czasach zbyt wysoki w porównaniu z dołozeniem drugiego CPU.

Rozumiem tę obsesję, że doprowadzić do perfekcji działanie jakiegoś elementu.
Zastnawiam się tylko, czy ten problem nie został rozwiązany znacznie niższym kosztem. Uświadomiłem sobie ostatnio, że nawet relatywnie tanie klawiatury (niskoprofilowe) nie mają brzęczących spacji.

Modyfikacja kodu w projekcie jest czasem zbyt trudna ze względu na proces zatwierdzania zmian w repozytorium.

To tak jakbyś powiedział Linusowi, że chcesz dodać logowanie do kilkuset funkcji w kernelu (w różnych modułach).
Teoretyczniei możesz to zrobić, ale wymagałoby to takich fikołków, że łatwiej zrobić wszystko lokalnie na środowisku developerskim.

Zależało mi na dobrej wydajności, bo te hookowane funkcje są często wywoływane.
Frida ma chyba możliwość działania w ramach hookowanego procesu, więc liczyłem, że koszt logowania do SQLite będzie niższy.

Finalnie chyba będę musiał obadać instrumentację binarnego kodu pluginem do gcc.

Nie wiem, w Polsce telegazeta działa z transmisją cyfrową.

Mnie wyszło, że to nie pamięć jest wolna tylko abstrakcje systemu operacyjnego.

To prawda, szczególnie, że koszt przełączenia kontekstu jest coraz wyższy (chociażby ze względu na meltdown/spectre itp.).

Możliwe, że dorównałbyś autorowi, ale w rzeczywistości marnowałbyś moc obliczeniową na niwelowanie opóźnienia. Prawdopodobnie zablokowałbyś wszystkie procesy. Jądro by je kolejno odblokowywało w trakcie napływu danych.

Tak, zablokowałbym więcej procesów, ale N czekających jednocześnie procesów otrzyma więcej danych niż jeden.
Żeby nie być gołosłownym, odczyt 13 GB ze zmapowanego pliku z zimnym cachem dysku:

• 1 wątek - 25.9s,
• 2 wątki - 15,4
• 4 wątki - 9,0s

Spodziewam się, że io_uring byłby znacznie efektywniejszy, ale wypadałoby porównać oba przypadki z tą samą liczbą wątków zamiast sztucznie ograniczać mmapa.

To porównanie jest nie do końca uczciwe.
Rozwiązanie oparte na mmap jest jednowątkowe, więc wszystkie pagefaulty potrzebne do załadowania danych spowalniają program.
W przykładzie z kolejką IO koleś ma 6 dodatkowych workerów.

Mogę się założyć o czekoladę z okienkiem, że dodanie kilku workerów prefaultujących z wyprzedzeniem strony z mmapowanymi danymi, przyspieszyłoby znacząco odczyt. Oczywiście io_uring będzie nadal szybszy, ale przewaga nie będzie tak znacząca.

Pamiętam, że w latach 90 chciałem mieć telegazetę, ale mój tv tego nie obsługiwał.
To było jeszcze przed dostępem do sieci.

Ciekawe, czy w Japonii są jeszcze nadawane dźwięki.

Niezła robota. Nie znałem tych technik robienia płytek z nawijaniem przewodu i robieniem wysepek.
Zaskoczyło mnie, że program z lat 90 nadal liczy orbity tych satelitów.

Z tego co widzę, R2 używa fridy do tracingu?
Szkoda, liczyłem, że mają jakieś niezależne narzędzie.
Próbowałem kiedyś logować wywołania dość dużego zbioru funkcji w binarce. Niestety okazało się, że proces crashuje, jeśli z hookowanej metody wyleci wyjątek C++. Wydaje mi się, że Frida obsługuje tylko SEH.

Personally I can’t conceive how posting comments on websites could lead to any kind of friendship.
We used to have much better tools to meet people online - IRC, instant messengers. Places, where you could easily switch from a group chat to 1:1 discussion with someone.

While technically possible with some blogging sites, or platforms like Fediverse/Reddit, it requires so much effort, that few people will care to do that.

On IRC there are still small communities of people who have known each other for 20-30 years. But in practice it has been completely replaced by Discord.