based on a true story
https://redd.it/1l33rkp
@r_linuxmemes

Czy wybory sfałszowano? Oddajmy głos nauce.

Na Li pojawił się fajny post prof. Przemysława Biecka (profesor nauk inżynieryjno-technicznych o specjalności statystyka matematyczna).

Badacz sprawdził, czy anomalii takich jak w Mińsku Mazowieckim, było więcej. Wczytał więc dane z wyborów do R.

Wyniki? Spójrzmy na ten wykres. Przedstawia on % głosów na RT oraz KN w pierwszej i drugiej turze. Z wykresu usunięto komisje z mniej niż 250 głosami.

Jeśli kropki idą z lewego dolnego do prawego górnego rogu, to dobrze, ponieważ znaczy to, że głosy rozkładały się podobnie. Jeśli protokoły w którejś (niekoniecznie drugiej) turze wysłano na odwrót, to stworzyłyby one czarne jeziorko punktów, ale ciągnące się z lewego górnego rogu do prawego dolnego. Czerwona kropka to Mińsk Mazowiecki.

WNIOSKI
Zakładając, że w pierwszej turze wszystkie protokoły wypełniono poprawnie, można powiedzieć, że nieco więcej komisji pomyliło się na korzyść KN (choć różnica nie jest duża będąc szczerym).

Profesor jest obecny na Twitterze: @PrzeBiec

https://x.com/AwDitrich/status/1931375747450515699?t=HvFZCxKd8v-SJF2GV7ymiQ&s=09

Czy wybory sfałszowano? Oddajmy głos nauce.

Na Li pojawił się fajny post prof. Przemysława Biecka (profesor nauk inżynieryjno-technicznych o specjalności statystyka matematyczna).

Badacz sprawdził, czy anomalii takich jak w Mińsku Mazowieckim, było więcej. Wczytał więc dane z wyborów do R.

Wyniki? Spójrzmy na ten wykres. Przedstawia on % głosów na RT oraz KN w pierwszej i drugiej turze. Z wykresu usunięto komisje z mniej niż 250 głosami.

Jeśli kropki idą z lewego dolnego do prawego górnego rogu, to dobrze, ponieważ znaczy to, że głosy rozkładały się podobnie. Jeśli protokoły w którejś (niekoniecznie drugiej) turze wysłano na odwrót, to stworzyłyby one czarne jeziorko punktów, ale ciągnące się z lewego górnego rogu do prawego dolnego. Czerwona kropka to Mińsk Mazowiecki.

WNIOSKI
Zakładając, że w pierwszej turze wszystkie protokoły wypełniono poprawnie, można powiedzieć, że nieco więcej komisji pomyliło się na korzyść KN (choć różnica nie jest duża będąc szczerym).

Profesor jest obecny na Twitterze: @PrzeBiec

https://x.com/AwDitrich/status/1931375747450515699?t=HvFZCxKd8v-SJF2GV7ymiQ&s=09

Każdy język wymaga programisty który zna swoją robotę 😛

Latency Insurance: Request Hedging

One more interesting concept I came across recently is request hedging. I've not seen it's actively used in enterprise software, but it can be useful for some scenarios where tail latency is critical.

Imagine that service A calls service B, service B has multiple instances. These instances can have different response times—some are fast, some are slow. There are number of protentional reasons for such behavior, but we'll skip them for simplicity.

Request hedging is a technique where the client sends the same request to multiple instances, uses the first successful response, and cancel the other requests.

Obviously, if you do this for all requests, the system load will increase and the overall performance will degrade.

That's why hedging is usually applied only to a subset of requests.

The following strategies are used for a request selection:
✏️ Token Buckets. Use a token bucket that refills every N operation and send a sub-request only if there is an available token (rate-limiting).
✏️ Slow Responses Only. Send hedged requests only if the first request takes longer than a specific latency threshold (95th percentile, 99th percentile)
✏️ Threshold. Send hedge requests only if Nth percentile latency exceeds expectation. For example, if the threshold is the 99th percentile, only 1% of requests will be duplicated.

Request hedging is efficient approach to reduce tail latency. It prevents occasional slow operations from slowing the overall user interaction. But If the variance in a system is already small, then request hedging will not provide any improvement.

#systemdesign #patterns

Defragmentacja dysku 😁

Zanzibar: Google Global Authorization System

Finally I had a chance to go into details about Zanzibar - Google global authorization system. I already mentioned it in OpenFGA overview where authors said that they based their solution on Zanzibar architecture principles.

Let's check how the system that performed millions of authorization checks per minute is organized:

✏️ Any authorization rule takes a form of a tuple `user U has relation R to object O`. For example, User 15 is an owner of doc:readme. This unification helps to support efficient reads and incremental updates.

✏️ Zanzibar stores ACLs and their metadata in Google Spanner database. Zanzibar logic strongly relies on Spanner external consistency guarantees. So each ACL update gets a timestamp that reflects its order. If update x happens before y, then x has an earlier timestamp.

✏️ Each ACL is identified by shard ID, object ID, relation, user, and commit timestamp. Multiple tuple versions are stored in different rows, that helps to evaluate checks and reads at any timestamp within the garbage collection window (7 days).

✏️ Each Zanzibar client gets a special consistency token called zookie. Zookie contains the current global timestamp. Client uses zookie to ensure that authorization check is based on ACL data at least as fresh as the change.

✏️ Zookies are also used in read requests to guarantee that clients get a data snapshot not earlier than a previous write.

✏️ Incoming requests are handled by aclservers clusters. Each server in the cluster can delegate intermediate results computation to other servers.

✏️ To provide performance isolation Zanzibar measures how much CPU each RPC uses in cpu-seconds. Each client has a global CPU usage limit, and if it goes over, its requests may be slowed down. Each aclserver also limits the total number of active RPCs to manage memory usage.

✏️ Request hedging with 99th percentile threshold is used to reduce tail-latency.

According to the whitepaper, authorization checks are performed for each object independently. It means that each search request for service like Drive or Youtube can trigger from tens to hundreds of authorization checks. That's why the overall architecture is heavily focused on keeping authorization request latency as low as possible.

Implementation results are impressive: Zanzibar handles over 2 trillion relation tuples, that occupy more than 100 terabytes of storage. The load is spread across 10,000+ servers in dozens of clusters worldwide. Despite that scale, it keeps the 95th percentile latency at ~9 ms for in-zone requests and ~60 ms other requests.

#systemdesign #usecase #architecture

Geniusze i biznesmeni robią sztuczną inteligencję dla siebie i na skutek swoich traum.
https://youtu.be/9sUOLzZeomc?si=GiE1viAYQiUjd6B7

Jest tam też o plastyczności mózgu i wolnej woli... I ludobójstwie w Gazie (mimo że pan jest żydem)

#AI #GaborMate #mózg i #Gaza

"Rzadko czyta się o tak groźnym oprogramowaniu dla smartfonów, jak właśnie „Ojciec Chrzestny”. Nazwane po kultowej książce i serii filmów nieprzypadkowo, bo podmienia zainstalowane na smartfonach aplikacje bankowe na fałszywe wersje, celem wyłudzenia danych logowania i wykradzenia środków z konta. Dlatego też podpowiadamy wam, jak się ochronić przed najnowszym zagrożeniem."

Źródło: ANDROID.COM.PL
https://android.com.pl/tech/941241-ojciec-chrzestny-wirus-na-smartfonach/

Dokumentacja jako kod

Jestem naprawdę przekonany, że dokumentacja jest częścią aplikacji . Powinna być rozwijana, aktualizowana i sprawdzana przy użyciu tych samych procesów i narzędzi, co kod aplikacji.

Jeśli dokumentacja jest przechowywana gdzie indziej, np. na oddzielnej wiki , to w zasadzie przestaje być aktualna w ciągu 5 minut od opublikowania .

Oznacza to, że dokumentacja powinna znajdować się w repozytorium git. Jeśli jakieś zachowanie systemu zostanie zmienione podczas naprawiania błędów lub opracowywania nowej funkcji, odpowiednia dokumentacja powinna zostać zaktualizowana w tym samym PR. Takie podejście pomaga utrzymać dokumentację na bieżąco .

To naprawdę proste, jeśli używasz monorepo . Wszystkie dokumenty i kod są umieszczone w jednym miejscu, więc łatwo znaleźć to, czego potrzebujesz. Rzeczy stają się bardziej skomplikowane, jeśli masz wiele mikrorepo . Nawet jeśli dokumenty są aktualne, użytkownikom trudno je znaleźć. Zwykle rozwiązuje się to, publikując dokumenty w centralnym portalu jako część procesu CI lub obecnie, korzystając z bota AI, który pomaga.

Niedawno Pinterest opublikował artykuł o tym, jak przyjęli podejście dokumentowania jako kodu . Ponieważ używają mikrorepozytoriów, głównym wyzwaniem było uczynienie dokumentacji możliwą do odnalezienia dla ich użytkowników w setkach repozytoriów.

Co zrobili:
🔸 Przeniesiono ich dokumenty do repozytoriów git, korzystając z języka znaczników Markdown.
🔸 Wykorzystano MkDocs w CI do wygenerowania wersji HTML dokumentów.
🔸 Utworzono centralne miejsce do przechowywania i indeksowania dokumentów o nazwie PDocs (Pinterest Docs).
🔸 Zintegrowana dokumentacja z GenAI — botem AI połączonym z głównymi kanałami komunikacji firmy.
🔸 Zbudowałem narzędzie umożliwiające migrację starych stron wiki do gita za pomocą jednego kliknięcia.

Nie znam żadnego standardowego rozwiązania dla agregacji dokumentów w wielu repozytoriach, więc byłoby wspaniale, gdyby Pinterest w przyszłości udostępnił swoje PDocs jako open-source. Myślę, że mogłoby to naprawdę pomóc wielu zespołom w ulepszeniu procesów dokumentowania.

#engineering #documentation
👇🏻👇🏻👇🏻👇🏻👇🏻

Documentation As a Code

I have a really strong opinion that the documentation is part of the application. It should be developed, updated and reviewed using the same processes and tools as the application code.

If the documentation is stored somewhere else, like in a separate wiki, it's basically dead within 5 minutes after it's published.

This means documentation should live in the git repo. If some system behavior is changed during bugfixing or a new feature development, the relevant documentation should be updated in the same PR. This approach helps to keep documentation up to date.

It's really simple if you use a monorepo. All docs and code are placed in one place, so it's easy to find what you need. Things become more complicated if you have lots of microrepos. Even if docs are up to date, it's quite hard for users to find them. Usually, this is solved by publishing docs to a central portal as part of the CI process, or nowadays by using an AI bot to help.

Recently, Pinterest published an article about how they adopted the documentation-as-code approach. Since they use microrepos, the main challenge was to make documentation discoverable for their users across hundreds of repos.

What they did:
🔸 Moved their docs to git repos using markdown.
🔸 Used MkDocs in CI to generate HTML versions of the docs.
🔸 Created a central place to host and index docs called PDocs (Pinterest Docs).
🔸 Integrated docs with GenAI — an AI bot connected to the main company communication channels.
🔸 Built a one-click tool to migrate old wiki pages to git.

I don’t know any standard solution for doc aggregation across multiple repos, so it would be great if Pinterest open-sourced their PDocs in the future. I think it could really help a lot of teams to improve their documentation processes.

#engineering #documentation

#płace
8670 zł #brutto na umowę o pracę to około 6240 zł #netto (na rękę). Na umowę zlecenie kwota netto wyniesie około 6390 zł, a na umowę o dzieło około 8138 zł.
♨️https://t.me/gospodarkaIpolityka/1007

2025-06