Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #34319

Re: Spieszmy się kochać Windows

Show all headers | View raw

On 08/01/2021 22:42, Maciej Sobczak wrote:
>> Taki producent odpowiednika STM32 ale opartego o rdzeń RISC może ściąć
>> cenę swoich cpu o dolara, powiedzmy. A to robi różnicę kiedy ich
>> sprzedajesz setki milionów, choćby jako sterowniki dildo i szczoteczek
>> do zębów.
> Ale przecież do tego już mają rdzenie.

Nie wiesz jakie mają kryteria. Jak dildo ma 40 programów i trzeba tak 
pod 1Ghz FPU do tego?

> Texas ma MSP430

I sprzedają go jako IpCores coby sobie ASICowy SoC dorobić na około?

> To po co jakiś RISC-V?

Bo pewnego dnia Texas zatrudni na CEO Balmera, który znowu będzie rzucał 
krzesłami?

Od jakiegoś czasu jest tendencja aby w miarę mozliwości nie zamykac się 
ze swoimi projektami za bardzo. RISC-V to jest taki "opensource ARM". 
Tak jest postrzegany. W razie jak na stanowisku CEO ARMa stanie świr, 
mamy się gdzie ewakuować.

>> POSIX w embedded nie jest dobry.
> Nadal nie napisałeś, dlaczego.

Wiele systmów embedded:
a) nie ma plików
b) nie ma procesów
c) nie ma rurek
d) nie ma sygnałów
e) nie ma konsoli
f) a wniej interaktywnych poleceń

Ale ma 40 programów w dildo, albo 20 programów w respiratorze. W tym 
drugim nawet formalnie weryfikowanych.

POSIXa w jakiejś implementacji ciężko będzie formalnie weryfikować, on 
sam z siebie jest bardzo kiepski i mocno chaotyczny, oraz *NIE DO TEGO*.

>> Osobiscie wolałbym aby mój respirator niekoniecznie pracował na POSIXie.
> Na pewno nie chcesz, żeby opracował na FreeRTOSie, bo to ma poziom poniżej amatorskiego.

Jednak wolę dalej FreeRTOSa nad POSIXa w respiratrorze, jesli już mam 
wykitować z powodu OSa. Może sygnał przyjdzie w wątku z obsługa, a może 
nie. POSIX? Nie, dziękuję.

> Ale ponieważ POSIX to jest tylko API a nie implementacja, to dlaczego nie?

Bo POSIX jest niezwykle trudny do weryfikacji. Z powodu komplikacji 
swojego API.

> Mogę mieć dobrej jakości implementację

Możesz. A masz?

> z interfejsem POSIX. Nadal nie napisałeś niczego, co by temu przeczyło.

Weryfikacji formalnej by przeczyło. Z tego powodu czasem wybiera się 
takie cuda na kiju jak jadra formalnie zweryfikowane (L4) i dziwaczne 
metody kostrukcji scalaków.

Niekiedy, aby dostać jakiś konkretny certyfikat, musisz wykazac że dany 
kawałek softu jest *dobrze* napisany. To kłopotliwe pojęcie, ale fakt że 
wsadziłeś POSIXa do migania diodą lub kontroli oddechu może być powaznym 
problemem w odpowiedzi na pytanie czy jest dobrze napisany. 
Najzwyczajniej możesz nie dać rady jej formalnie udzielić. Dlatego 
istnieją znacząco mniejsze systemy w któych masz na to jakąś szansę.

> Przykładowo, dobrej jakości systemem do embedded z interfejsem POSIX jest QNX.
> W szczególności, jest używany w systemach medycznych:
> https://blackberry.qnx.com/en/software-solutions/embedded-software/medical
> Więc jednak masz POSIX w urządzeniu medycznym. I dobrze.

Tak, istnieją systemy, narzędzia, cores certyfikowane. Nie ma problemu 
aby były zgodne w jakiejś częsci z posix. Nic tak nie powoduje ulgi 
doczesnej jak to że na moim respiratorze można zrobić fread z EINTR i 
jest na to 15 ifów, a miało być 16.

>> Ale musisz mieć abstrkację. Masz, prawda? Jak byś inaczej mógł
>> to testować. Wiec musisz mieć.
> Przecież napisałem, że mam. Nazywa się POSIX.

Nie, to tylko kilka implementacji. Abstrakcja to nie jest.

>> Zaznajom się np. z Qt.
> Już mnie kiedyś chciałeś do tego zachęcić, ale słabo wyszło.

Nie namawiam, to tylko przykład co to jest abstrakcja na OS a nie 
abstrkacja na rodzię OSów.

>> POSIX nie jest przenośny. Istnieje masa systemów z nim niezgodnych.
> Ręce opadają, nic nie rozumiesz.
> To nie POSIX ma być przenośny, tylko programy napisane pod to API.

Staje się wtedy tak samo nieprzenośne jak implementacja POSIXa. Na 
przykład sa nieprzenośne na to i tamto.

> I zapewniam, że takie programy są przenośne pomiędzy systemami, które ten standard implementują.

Czyli wąska grupa unixo-podobnych + duperele.

> Np. kod, który napisałem na Linuksie zadziałał od ręki na QNX.

A na freeRTOS? A na Windows CE?

Ok, ustalmy wobec tego że masz program *częściowo* przenośny. Tak lepiej?

> Właśnie na tym polega ta przenośność.

Nie. Ale może takie masz warunki pracy, w których interesuje Cie 
przenośnośc z Ubuntu na NetBSD i wtedy POSIX faktycznie można uznać za 
jakiś rodzaj abstrakcji. Ja nie mam takiego komfortu. Nie tylko ja.

>> Zaś wszystkei zgodne maja mała użytecznośc w embedded. POSIX jest do
>> stacji roboczych a nie migania diodami lub kontroli oddechu. Naprwadę,
>> nie potrzebujesz parentpid i fopen w respiratorze.
> Czyli dalej nie rozumiesz. Kto powiedział, że system ma mieć wszystkie funkcje?

Czyli nie jest zgodny z POSIX?

> Chodzi o to, że jeśli już ma np. funkcję inicjalizującą mutex, to niech ta funkcja się nazywa pthread_mutex_init a nie ourMutexCreate.

Wycinasz przenośność na nieposixy.

> I jeśli system ma tylko 10 takich funkcji, to niech one się nazywają tak jak 10 funkcji z POSIX.

Nie, to już za daleko. Przecieka Ci implementacja przez abstrkację. 
Dotyczy ona nie tylko nazw, ale przede wszystkim sposobu użycia. W sumie 
bez znaczenia czy masz pthread_mutex_init nazwany dupa. Istotne jest że 
w innym systemie (niezgodnymz POSIX) może w ogóle nie itnieć inicjacja 
poza miejscem deklaracji, albo istnieć przyjmująca paramter resursive. 
Itd itp. Przeciekanie POSIXa do kodu to nie tylko nazwy, to sposoby ich 
używania.

Dlatego masz class MyMutex a nie void MyMutexInit(). To drugie 
faktycznie nic by nie dało.

> zrobić mu unit-testy na innym systemie, np. na Linuksie, bo akurat taki jest łatwiej dostępny.

A na windowsie?

>>> Albo korzystam ze standardów. Takim standardem jest POSIX.
>> Dalej nie pojmujesz że posix nie jest abstrakcją.
> Dalej nie przeczytałeś nawet pierwszego zdania z Wikipedii na ten temat. A dałem linka.

Przeczytałem. Zmartwie Cie równiez. Na codzień piszę kod na POSIXie i 
Windowsie *jednoczesnie*. Powiedzmy że mam zielone pojęcie gdzie POSIX 
jest przenośny. Powiedzmy że nieco powyżej średniej, mam to pojęcie. 
Nijak nie udało mi się zawołać funkjci Posixowych w Windowsie. 
Najwyraźniej Wikipedia pisze od rzeczy lub nie pojmujesz o co chodziło 
autorom.

>> Abstrakcją jest
>> MyTools::MyMutex a nie pthread_mutex.
> To jest abstrakcja na abstrakcję.

To jest abstrakcja na więcej implementacji OSów niż tylko POSIX.

> Też tak robię - ale to jest dodatkowy koszt

Kosztuje mnie absolutnie 0 czasu w runtime, absolutnie 0 czasu w 
pisaniu. Ba, jest tańszy niż POSIX bo mogę używać RAII, więc robie mniej 
błedów emulując ręcznie RAII, tak jak chce POSIX.

> I teraz masz milion firm robiących systemy embedded i każda z nich robi wrapper MyTools::MyMutex. Dlaczego?

Aby się uniezależnić od OSa. Aby móc przeprowadzić unit testy. Aby móc 
łatwiej znaleźć błedy. Aby szybciej pisać kod. Aby łatwiej go czytać. 
Aby łatwiej go refaktorować.

Zgadnij dlaczego mamy (wreszcie) std:: z obsługą wątków, i to nie jest 
POSIX like API. Najwidoczniej ktoś kombinuje jak ja - abstrakcja na OS.

> Ile jest interesujących systemów w użyciu, nawet wliczając te dziadoskie typu FreeRTOS? No ile?

Co najmniej kilkanaście. Twoje POSIXy, Win32/64, mikroskopijne RTOSy, 
dedykowane dziwadła jak L4 i systemy pisane pod zagadnienie, np. do 
lotów kosmicznych. I pewnie masę, których nie wymieniam, bo przecież 
znam je tylko z tego że się obiły o uszy.

> To zobacz teraz, jaki jest stosunek kosztów: milion firm robi własne abstrakcje do abstrakcji

Które kosztują, zwyczajowo prawie nic i dzięki temu, że sa pisane z 
myslą o czymś nowoczesniejszym niż kompilatory z lat 70, pozwalaja 
dodatkowo zredukować koszta pisania kodu, używając nowocześniejszych 
technik generujacych mniej błedu. std::lock_guard jest nieskończenie 
lepszym wyborem niż ręczne dziubdzianie mutex lock/unlock w posixie.

Nie robią własnych. Wiele z tych abstrakcji jest już napisanych: 
boost/std i masa pomniejszych dupereli.

> , bo w przybliżeniu 2-3 systemy koniecznie musiały mieć ourMutexCreate

Zniknąłeś pozostałe zalety.

>. Czyli sumaryczny koszt tych wszystkich abstrakcji jest większy

Jest prawie zerowy. Przykładowo moja abstrakcja na rurki, zajeła mi 2h 
do napisania i otestowania i od lat nie zmieniłem w niej bajta. Ta sama 
funkcjonalność, reimplemntowana ręcznie kończy się deadlockiem bo ktoś 
zapomniał ponowić ::read, bo wyleciał EINTR.

Koszta takich bugów są niebotyczne, bo wylatują tylko przy pełni 
księżyca w Kambodży podczas monsunów. Po to owijamy, między innymi, 
POSIXa w dodatkową abstrakcję wysokopoziomową, aby chronić się od 
popełniania w kółko tych samych błedów tego dziwdowskiego interfejsu.

Zauważyłeś ile jest makr które "ułatwiają" pracę z funkcjami POSIXowymi? 
To dlatego, że to jest wyjątkowo żałosne API i nawet najbardziej 
zatwardziali unixiarze w końcu poddali się, wrapując te klocki w makra.

> To jest choroba naszej branży.

Nie. Pisanie na wysokim poziomie nie jest chorobą.

>> Abstrakcją może byc też Qt
> Ale czemu sobie żałować? Zróbmy abstrakcję na to też.

Oczywiście że się robi i na to abstrkację. Chcesz aby po Twoim kodzie 
latały QString czy std::string? Co jest bardziej niebezpieczne?

Wybór może być biznesowy. Przykładowo kilka lat temu zamieszanie z 
licencjonowaniem Qt spowodowało że "ludzie" poważnie zastanowili się czy 
warto się od Qt uzależnić. I zauważyli że część abstrakcji z Qt można 
znaleźc w boost/std.

> Przecież nie wszystkie frameworki są zgodne, prawda?

Nie są. Dlatego najlepiej oddzielić wartwę logiki od wartwy GUI aby w 
razie czego "łatwo" GUI wymienić. To rodzaj sztuki, w prewnym sensie 
robienie abstrkacji na GUI uważam za znacznie trudniejsze niż na OS.

> A co jak management zdecyduje, że zmieniamy Qt na coś innego?

To mam do przepisania jakieś 10% kodu, często tylko poprawienia. 
Pozostały jest abstrakcyjny, przetestowany, nic się w nim nie zmienia.

> I teraz, jeśli programiści nie są idiotami, to pójdzie sprawnie, bo mają abstrakcje, tak?

Nie, bo używanie Qt jest mocno zaraźliwe. Znacznie bardziej niż uzywanie 
POSIXa. Wiec, o ile można część apliakcji skompilować w oderwaniu od Qt 
(np. modele i częsciowo kontrolery) to już widoki będą wymagały wymiany.

Ale dalej, poprawna higiena ratuje 90% apliakcji.

> Wszystkie Twoje argumenty można tu zastosować.

Tak, Qt było przykładem jak wygląda abstrakcja na OS 3-rd party, a nie 
wzorzec w dyskusji jak ją robić. Co napisałem wyraźnie. Uzycie Qt jako 
abstrakcji to wybór biznesowy i niekoniecznie poprawny wszędzie i zawsze.

> [POSIX]
>> Przeczytałeś cos nie na temat. To jest abstrkacja do konkretnej rodziny
>> systemów.
> Konkretnej? Nie, żadnej rodziny tam nie było. Niektórych systemów w ogóle jeszcze nie było, jak ten standard powstał.

I jakimś trafem mało który system suwerena ten standard implementuje, 
podobnie w embedded OSa może w ogóle nie być, ba, może być napisany na 
miejscu, do potrzeb. Nikt nie będzie implementował dziadowskich 
koncepcji z POSIXa tylko dlatego że jest jakiś "standard" pochodzący z 
mainframes.

>> W tej rodzinie nie ma FreeRTOSa ani Widnowsa CE, a są one w
>> embedded używane.
> No są. Niestety. Bo po co być zgodnym ze standardami, skoro można mieć - *beż żadnej wartości dodanej* - ourMutexCreate?

Pisałem juz kilka razy o tej wartości dodanej. W sprawie zgodności z 
POSIxem udaj się do MS. Zaznaczam, ze mimo lat dziubdziania Cywina i 
ostatnio samego MS, POSIXa w windowsie nie zobaczysz, są fundamentalne 
problemy z faktem że posix to nie przemyslany standard, tylko zbiór 
aktualnie działajacego stanu jakiegoś wiekowego UNIXa, zamrożony i 
nazwany "abstrakcją", pełen debilizmów i workaroundów.

> Ale o to można obwiniać tylko autorów tych systemów.

Zgadza się, jednak z jakiejś przyczyny WinApi, mimo stwojej śmieszności 
w tak wielu kwestiach, nie ma kompletych bzdur w np. obsłudze pipes, jak 
jest w unixie. Nie ma sygnałów wyskakujących w dowolnym wątku i 
kopiących programistę prosto w dupę. Itd itp. Może jednak WinAPI było 
bardziej przemyślane i nie po drodze im z POSIXem. To co, postulujesz 
nie używać Windowsa w programowaniu bo niezgodny z tym zbiorem głupich 
rozwiązań nazywancyh POSIX i oferujący swój własny zbiór głupich 
rozwizań nazywanych WinAPI? A może jednak odciąc się od obydwu, co?

> POSIX jest standardem. QNX spełnia ten standard. FreeRTOS nie spełnia tego standardu. Co zrobić.

Odciąć się abstrakcją.

>> Co najwyżej na wąską
>> grupę bardzo podobnych systemów, o nikłej uzytecznosci w embedded.
> Nadal czekam na wyjaśnienie, dlaczego nie do embedded.

Bo mało kiedy potrzebujesz mieć procesy, rurki, pliki w systemie 
embedded. A jak ich nie masz, to nie masz POSIXa.

> Dlaczego ourMutexCreate jest do embedded a pthread_mutex_init nie jest.

Bo jest nieprzenośne na inne embedded.

> To ciekawe bardzo. Funkcja się inaczej nazywa i już nie nadaje się do embedded.

Tak, właśnie odkryłeś na czym polega abstrakcja w wyjaśnieniu dla 
przedszkolaka.

> Kurdę, muszę uważać, jak funkcje nazywam.

Dokładnie tak, jesteś na własciwym trope. Dodatkowo jeśli dodasz że 
musisz uważać jakich typów są zmienne, jakich flag używasz itd itp to 
szybko dojdzieszdo tego co to jest *prosta* abstrakcja na system 
operacyjny. Tylko nie zakładaj że to koniec, dalsze tematy są bardziej 
skomplikoane, ale do ogarnięcia. Tak, trzeba zacząć od uszelniania 
szamba, aby POSIX nie przeciekał do kodu, a potem małymi krokami usuwasz 
kod supportujący dziwactwa i przenosisz go do wspólnych miejsc i jesteś 
już o krok od abstrakcji w której nie ma supportu dla EINTR czyli 
przeciekania szamba.

>> Abstrakcja na systemy operacyje jest wysokopoziomowa. Tam gdzie nie
>> wiadomo czy mutex to int, handle, pointer czy foo.
> Właśnie tak jest w POSIX.

Dokładnie, nie czyni to z niego jednk abstrakcji na Windows.

>> Pewnego dnia januszowy RTOSik zostanie zamieniony na mirkowy CE bo taki
>> się zwidziało właścicielowi biznesu. Jesli Janusz nie był iditiotą to
>> zmiana na to CE może być mało bolesna.
> Niestety nie jest to zgodne z moimi obserwacjami. Zmiana jednego systemu POSIX na drugi system POSIX może być mało bolesna, ale zmiana OurRTOS na TheirRTOS to większy problem, bo jak już ktoś miał gdzieś standardy, to zwykle w różnych, niezależnych kierunkach. Wtedy to nie jest kwestia taniego wrappera.

Nikt tu nie pisze o *darmowej* migracji. Owszem, napisałem niedawno o 
zmianie kompilatora w makefile, ale to dotyczyło rekompilacji kodu na 
Macu z x86 na ARM, kiedy API systemu się nie zmienia, zmienia się tylko 
cpu i ABI. Wiele projektów embedded też będzie miało łatwo, bo nie 
zależą od CPU.

Zmiana ma być mało bolesna. Przepisanie kilku adapterów nie kosztuje 
mało, ale na pewno taniej niż przepisanie całego kodu zasranego 
odwołaniami do POSIXa i logiką z EINTR.

> Zwłaszcza, jak to tego dołożymy stos TCP

To tego POSIX nie załatwił? A to niegrzeczny!

>. Np. popularnym partnerem dla dziadoskiego FreeRTOSa jest dziadoski LwIP. To jest dopiero duet, wszystko wtedy opada.

Nie miałem przyjemnosci, chętnie sprawdzę na ile jest rozsądniejszy od 
impelemntacji z unixów. Bo ta, moim skromnym zdaniem, wyznacza jednak 
poziom podłogi. Nie da się gorzej.

>> Pamiętaj o czym rozmawiamy: stwierdziłeś że zmiana procesora to nie
>> tylko zmiana makefile, tylko bardzo ciezka rzecz.
>> No więc to cieżka rzecz, jak się ma dziadowski kod.
> Jeszcze cięższa, jak się nie ma kodu.

Nie wydaje mi się, aby taki był temat dyskutowania.

> O tej możliwości też cały czas mówimy, bo to jest realna możliwość.

Pewnie, ktoś musi stworzyc puste repo na nowy projekt, jednak w dużych 
firmach jest super jak można go zapełnić gotowcami z poprzeniego 
projektu. I to wszystko dzięki abstrakcji. O dzieki Ci, abstrakcjo!

> Ale trochę rozwlekła nam się ta dyskusja zrobiła, więc może skupmy się: dlaczego POSIX nie jest dobry do embedded?

Napisałem wyżej. Zawiera śmieci, które nie są użyteczne, oraz sam z 
siebie jest wyjątkowo dziadowski.

> Dlaczego funkcja, która się nazywa na literkę "p" nie nadaje się do embedded a funkcja robiąca dokładnie to samo, ale na inną literkę się nadaje?

Aby nie musieć zmieniać jej nazwy w 100 miejscach kiedy zmieniasz OS, 
poprawiajac przy okazji kod supportujacy też 100 razy.

Aby udostepnić wysokopoziomy interfejs uzywajacy wspólczesnych jezyków 
zamiast POSIXowego, kieskiego API.

Aby umożliwić unit testy.

Aby odstrzec że czasem ta funkcja nie może być wywołana w innym systemie 
i trzeba pakować ją do wyższysz struktur języka.

Pisałem to chyba ze 100 razy. Prosze, nie pytaj więcej, jestem zmęczony.

> "U mnie działa."

U mnie też. Przeciez wymieniamy doświadczenia. Ty masz jakieś, ja mam 
jakieś.

Ja nie mogę spobie pozwolić na komfort "tylko POSIX" bo inaczej trace 
połowę klientów, dzięki temu wypracowałem metody uszczelniania szamba 
POSIXa i WinAPI tak, aby nie przeciekały do kodu.

Ty najwidoczniej możesz sobie pozwolić na ogarnieniae abstrakcji w 
POSIXowym OSie.

Stąd różne opinie. Moja w tym wypadku jest mojsza i tyle.

Back to pl.comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Spieszmy się kochać Windows slawek <x.y@org.org> - 2020-12-06 10:41 +0100
  Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2020-12-06 13:26 -0800
    Re: Spieszmy się kochać Windows slawek <x.y@org.org> - 2020-12-24 12:05 +0100
  Re: Spieszmy się kochać Windows arnold@hooterville.invalid (Arnold Ziffel) - 2020-12-16 09:26 +0000
    Re: Spieszmy się kochać Windows slawek <x.y@org.org> - 2020-12-24 12:02 +0100
      Re: Spieszmy się kochać Windows Luke <luke@luke.net> - 2021-01-03 12:42 +0100
        Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-03 12:53 +0100
          Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-03 07:19 -0800
            Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-03 16:45 +0100
              Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-04 09:59 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-05 09:18 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-05 12:06 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-05 22:51 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-06 08:02 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-06 17:28 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-07 13:13 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-07 23:46 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-08 13:42 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-09 01:23 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-09 07:48 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-09 18:53 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-10 07:56 -0800
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-10 08:25 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-10 18:05 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-11 08:41 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-11 18:07 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-12 09:43 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-13 07:14 +0100
          Re: Spieszmy się kochać Windows Luke <luke@luke.net> - 2021-01-04 19:02 +0100
            Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-04 20:35 +0100
              Re: Spieszmy się kochać Windows Luke <luke@luke.net> - 2021-01-06 10:58 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-06 14:28 +0100
                Re: Spieszmy się kochać Windows fir <profesor.fir@gmail.com> - 2021-01-06 08:32 -0800
                Re: Spieszmy się kochać Windows fir <profesor.fir@gmail.com> - 2021-01-07 04:27 -0800
                Re: Spieszmy się kochać Windows Smok Eustachy <smok@wurg.pl> - 2021-01-07 14:55 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-07 15:03 +0100
                Re: Spieszmy się kochać Windows Luke <luke@luke.net> - 2021-01-09 20:57 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-09 21:28 +0100
                Re: Spieszmy się kochać Windows Smok Eustachy <smokeustachy@WURG.pl> - 2021-01-10 14:37 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-10 15:43 +0100
                Re: Spieszmy się kochać Windows Smok Eustachy <smok@wurg.pl> - 2021-01-10 21:07 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-10 21:49 +0100
                Re: Spieszmy się kochać Windows Smok Eustachy <smok@wurg.pl> - 2021-01-11 09:24 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-11 12:33 +0100
                Re: Spieszmy się kochać Windows Mateusz Viste <mateusz@xyz.invalid> - 2021-01-11 13:03 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-11 13:26 +0100
                Re: Spieszmy się kochać Windows Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> - 2021-01-11 11:37 +0000
                Re: Spieszmy si? kocha? Windows antispam@math.uni.wroc.pl - 2021-01-23 02:50 +0000
                Re: Spieszmy si? kocha? Windows heby <heby@poczta.onet.pl> - 2021-01-26 16:25 +0100
                Re: Spieszmy si? kocha? Windows antispam@math.uni.wroc.pl - 2021-01-26 23:40 +0000
                Re: Spieszmy si? kocha? Windows heby <heby@poczta.onet.pl> - 2021-01-27 11:53 +0100
                Re: Spieszmy się kochać Windows Marcin Debowski <agatek@INVALID.zoho.com> - 2021-01-15 08:21 +0000
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-15 19:20 +0100
                Re: Spieszmy się kochać Windows Marcin Debowski <agatek@INVALID.zoho.com> - 2021-01-16 03:07 +0000
                Re: Spieszmy się kochać Windows Luke <luke@luke.net> - 2021-01-23 09:48 +0100
                Re: Spieszmy się kochać Windows Wojciech Bancer <wojciech.bancer@gmail.com> - 2021-01-23 21:44 +0100
                Re: Spieszmy się kochać Windows Maciek Godek <godek.maciek@gmail.com> - 2021-01-25 02:28 -0800
                Re: Spieszmy się kochać Windows Roman Tyczka <romantyczka@hate.you.spammer> - 2021-01-30 19:31 +0100
                Re: Spieszmy się kochać Windows Marek <fake@fakeemail.com> - 2021-02-21 17:51 +0100
              Re: Spieszmy się kochać Windows Smok Eustachy <smok@wurg.pl> - 2021-01-07 14:50 +0100
        Re: Spieszmy się kochać Windows Marcin Debowski <agatek@INVALID.zoho.com> - 2021-01-05 12:23 +0000

csiph-web