Goto page Previous 1, 2, 3 ... 8, 9, 10, 11, 12, 13 Next
Jarosław Sokołowski
Guest
Sat Sep 17, 2011 11:53 pm
Pan Sebastian Biały napisał:
Quote:
Czekaj, skąd wytrzasnałeś brak umiejętności analizy założeń?
Z dyskusji w tym wątku (ale też trochę z wcześniejszych obserwacji).
A dokładnie z ignorowania wcześniej opisanych warunków przy formułowaniu
własnych sądów.
A jakie warunki były opisane? Bo ja się wtryniłem z butami w dyskusję
która dawno wykraczala poza potrzebe inicjatora wątku i wy tam sobie
wesoło ględziliście o wyższośc LPT nad atmelkami w sytuacjach ogólnych.
Nie mogę każdemu wszystkiego tłumaczyć i nakazywać jakie ma zająć
stanowisko w dyskusji. Może sobie ględziliśmy wesoło, może o wyższości,
ale jak się wchodzi w dyskusję (z butami lub bez), to dobrze jest
robić to tak, by odnieść się do tego, co mówia inni. A nie po to,
by zamianifestować swoje poglądy (uprzedzenia, kompleksy czy co to
tam jest).
Quote:
NIE. Chodzi o to by nie dopuścić do pomyłek w momecie pisania.
Z takim podejściem w ogóle nie ma co się zabierać za pisanie programu.
Prezentujesz poziom zblizony do poglądow programistów z lat 80.
Programowałem również wcześniej.
To bardzo wiele tłumaczy. Szczególnie styl: jak zabraknie argumentu to
ucieczka w "za młody jesteś żeby pamiętać jak żeśmy z Józkiem klepali
sterowniki na PDP w kodzie maszynowym na kartach perforowanych".
Wręcz przeciwnie -- niech teraz młodzi kodują, im to szybciej idzie,
nie zastanawiają się nad każdą rzeczą, tylko piszą i idą do przodu.
Wystarczy takimi pokierować, a efekty są znakomite.
Quote:
Widuje ich na codzień. Ta dyskusja wraca bardzo czesto i zazwyczaj
kończy się na inwektywach.
Mam się spodziewać, że zaraz zacznie Pan rzucać mięsem?
Wręcz przeciwnie, zazwyczaj to reakcja alergiczna strony przeciwnej na
hasło "przeciez od dawna jest silne typowanie w C++" albo "po co tyle
niebezpiecznego kodu, nie słyszaleś o RAII?".
Nie mam alergii, nawet na pyłki.
Quote:
Błedy lepiej blokować niż dopuszczać i debugować. Języki interpretowane
i dynamicznie typowane nie potrafią blokować błedów poza trywialnymi w
składni. Na tej planecie są całe stada programistów którzy sobie tego
nigdy nie uświadomią.
Więcej błędów powstaje przy tworzeniu założeń, a nawet przy określaniu
wymagań. A jeśli nawet nie więcej, to są one bardziej istotne.
Wow, to była szybka ucieczka w bok. Nie doceniałem doświadczenia
usenetowego kolegi. Zapomniałeś jednak wyciąć cytatu, było by
bardziej z sensem.
A co tu jest bez sensu?
Quote:
Bo ja nie oddam swego życia (a nawet rzeczy o wiele mniej cennych)
w ręce koderów.
Oddajesz codziennie.
Jeśli już, to bez udziału woli. To całkiem co innego. Ale gdy mogę,
unikam takich sytuacji.
Quote:
Bo doskonale wiedzialem, po analizie, czego i jak potrzebuje użyć.
Świetnie. Widzę, że praca w zespole przynosi efekty.
Jakim zespole?
Jeden analizuje, drugi koduje -- tak jak napisano wyżej.
Quote:
Pomimo tego nie potrafie nawet naszkicować zbioru warunków na które
odpowiedzią byłby bash.
Nie wszyscy potrafią wszystko.
Spodziewałem się raczej przykladu ale jak zwykle zostala tylko żałosna
złośliwość.
Przykłady (niepotrafienia) są wyżej. Więcej nie potrzeba.
Quote:
Zawsze jest lepsza alternatywa.
Zawsze. Od początku Panu o tym mówiłem.
Nie. Bash nie jest lepszą alternatywą. Naprawdę, w stosunku do
czegokolwiek. Podobnie jak i perl.
Bash może być lepszą alternatywą dla perla, podobnie perl może być
lepszą alternatywą dla basha.
--
Jarek
Jarosław Sokołowski
Guest
Sun Sep 18, 2011 12:05 am
Pan Sebastian Biały napisał:
Quote:
Ale to jedyny kernel jaki masz, bo starsze nie obslugują hardware a
nowszych nie ma. Jesteś w dupie.
Wiem gdzie jestem -- nie tam. Tu nie mamy takich problemów.
A ja takie problemy mam/miewam. Ale ja jestem szumem statystycznym.
Współczuję. "A miało być tak pięknie."
Quote:
Pozostaje rękodzieło, poprawianie buga po kimś.
Brrr, wstrętne.
Zajmuje czas, nie daje żadnych gwarancji. W przypadku systemow
krytycznych jest skandaliczne/niebezpieczne.
Niektórzy tylko potrafią systematycznie krytykować. To im zajmuje
cały czas.
Quote:
Należy powiedzieć: kernel pisany jest przez przypadkowych ludzi
tworzących jako-tako działajace oprogramowanie.
A ludzie powstali w wyniku przypadkowych mutacji DNA.
Co jednoznacznie udowania wyższość kernela Linu... oh wait.
Miało coś udowodnić? To co "należało powiedzieć" o kernelu też miało?
Quote:
się jednoczesnie obsługą chińskich myszek, chińskich kart sieciowych,
chińskich mostków supportowanych dzięki reverse-engeneering i reakcją
na pierdyliard przerwań na sekundę mamy poważne powody by nie dawać mu
zadań od których wprost zależy czyjeś życie.
Ja nie lubię literatury s-f. Znana mi rzeczywistość wygląda inaczej.
Tak. Developerzy Linuxa dostają pełną dokumentacje scalaków, a każdy z
nich, bez wyjątku, pracuje zgodnie z nią. No i kod piszą automaty, bez
żadnych bugow. I się budzisz.
Jeśli mam podejrzenia, że super-duper scalak z USB czy czymś jeszcze
nowszym ma bugi (w sobie lub w oprogramowaniu do niego) to wtedy używam
na przykład starego sprawdzonego LPT.
Quote:
Nie ma znaczenia styl developingu OS - jakoś kodu w obszarze
zainteresowań automatyka w obydwu rozwiązaniach jest mizerna.
Jest tu pewna symetria -- jakość pewnych automatyków oceniam jako
mizerną. Wypadają poza obszar zainteresowań tak daleko, że nawet
nie mam ochoty na sprawdzanie pisanego przez nich kodów.
--
Jarek
Jarosław Sokołowski
Guest
Sun Sep 18, 2011 12:16 am
Pan Sebastian Biały napisał:
Quote:
ale jak się wchodzi w dyskusję (z butami lub bez), to dobrze jest
robić to tak, by odnieść się do tego, co mówia inni. A nie po to,
by zamianifestować swoje poglądy (uprzedzenia, kompleksy czy co to
tam jest).
Pierwszy raz na usenecie jesteś czy co? Jest rzeczą naturalną że
gdybym chciał się odnieść do pierwtnego problemu to bym odpowiedział
kilkanaście postown niżej. Ja tu tylko protestuje przed wciskaniem
kombinacji pc+linux+bash do sterowania czegokolwiek. To niebezpieczne.
Trzeb się odnisić do tego *co* piszą inni, a nie *o czym* piszą.
Reakcje na zasadzie "piszą o bashu, to trzeba napisać, że bash jest
gówniany", to są dobre w laboratorium Iwana Pietrowicza Pawłowa,
a nie w Usenecie.
Quote:
Więcej błędów powstaje przy tworzeniu założeń, a nawet przy określaniu
wymagań. A jeśli nawet nie więcej, to są one bardziej istotne.
Wow, to była szybka ucieczka w bok. Nie doceniałem doświadczenia
usenetowego kolegi. Zapomniałeś jednak wyciąć cytatu, było by
bardziej z sensem.
A co tu jest bez sensu?
Używanie stwierdzeń z okolicy Captain Obvious unikając w ten sposób
ustosunkowania się do czegokolwiek merytorycznie.
Ale tu nie można się ustosunkować merytorycznie inaczej niż w mniej
jub bardziej delikatny sposób mówiąc: to są duby smalone. Poprzednio
próbowałem delikatniej.
Quote:
Nie. Bash nie jest lepszą alternatywą. Naprawdę, w stosunku do
czegokolwiek. Podobnie jak i perl.
Bash może być lepszą alternatywą dla perla, podobnie perl może być
lepszą alternatywą dla basha.
Stack overflow.
Parse error ("może", to co inego nić "jest"; nie ma języków bezwzględnie
lepszych i bezwzględnie gorszych).
--
Jarek
Jarosław Sokołowski
Guest
Sun Sep 18, 2011 12:29 am
Pan Sebastian Biały napisał:
Quote:
Jeśli mam podejrzenia, że super-duper scalak z USB czy czymś jeszcze
nowszym ma bugi (w sobie lub w oprogramowaniu do niego) to wtedy używam
na przykład starego sprawdzonego LPT.
Ktorego nie ma we współczesnym PC.
To naprawdę jest jakieś s-f. Nie mam problemów z nieprzewidywalnym
działaniem PC.
Quote:
Chyba że chcesz użyć nowego niesprawdzonego LPT na PCI.
Ono dość leciwe jest. Więc sprawdzone.
Quote:
A oczekuj przygody, moja karta LPT na PCI
Mam używać karty PCI po kimś?! Brrr.
Quote:
generowała śliczne szpileczki co każde restartowanie systemu (nawet nie
wlaczenie zasilania). Wylądowała w końcu w smieciach jak się okazało że
byle przepięcie uwaliło połowę portów.
Jedną gdzieś jeszcze mam. Używałem. Niczego mi nie uwaliła. Ale jak
pech, to pech.
Quote:
Aż się boje jakie przygody miewają osoby które LPT bawią się na codzień.
Ja się nie boję, ale jakby miewali jakieś straszne, to by tu pewnie już
dawno napisali.
--
Jarek
Jarosław Sokołowski
Guest
Sun Sep 18, 2011 12:36 am
Pan Sebastian Biały napisał:
Quote:
Ale tu nie można się ustosunkować merytorycznie inaczej niż w mniej
jub bardziej delikatny sposób mówiąc: to są duby smalone. Poprzednio
próbowałem delikatniej.
Co *konkretnie* uważasz za bzdury? Twierdzenie że języki silnie typowane
zapewniają lepszą jakośc kodu? Że bugi lepiej wykrywać wczesniej nie
dopuszczając do wystapnienia? Cos innego? Możesz być mniej tajemniczy?
A nie da się powędrować w górę po gałązce wątku i przeczytać?
Tu konkretnie ocenę znaczenia błędów. Ale wiele innych rzeczy
oczywiście też.
--
Jarek
Michoo
Guest
Sun Sep 18, 2011 12:57 am
W dniu 17.09.2011 23:29, Sebastian Biały pisze:
Quote:
Nie. Bash nie jest lepszą alternatywą. Naprawdę, w stosunku do
czegokolwiek. Podobnie jak i perl.
Mamy w korytarzu powieszony LCD na HD44780 wyświetlający dużo różnych
informacji. Do lcd jest przylutowany tiny2313 + max232 i całość po
serialu jest połączona do PC.
120 firmware.cpp //obsługa USARTa i wyświetlacza
18 /home/michoo/pogoda.pe // pobieranie z internetu aktualnej prognozy
pogody
52 /home/jarek/lcd2.pe // zbieranie wszystkich danych do kupy i
wysyłanie do wyświetlacza linia po linii z odpowiednimi opóźnieniami
Jaki sens miałoby rzeźbienie tych 2 skryptów w innym języku? Ile by zajęły?
Jak bym robił frezarkę CNC, czy inne sterowanie prasą to też bym to
pewnie tak zrobił - mały uC, który dba o poprawność działania (zapewnia
bezpieczny protokół) i kod w czymś w czym się szybko pisze do obsługi po
stronie PC.
--
Pozdrawiam
Michoo
Jarosław Sokołowski
Guest
Sun Sep 18, 2011 1:34 am
Pan Sebastian Biały napisał:
Quote:
A nie da się powędrować w górę po gałązce wątku i przeczytać?
Myslę że jak się komuś pluje w twarz "bzdury" to można choć troche je
precyzyjniej określić. Tak żeby się dalo odnieść. Inaczej to inwektywa
na poziomie podłogi politycznej na która można tylko wzruszyć ramionami.
To dołożę kolejną na tym samym poziomie: trzeba wiedzieć do czego służy
"References" i umieć zrobić z tej wiedzy użytek.
Quote:
Tu konkretnie ocenę znaczenia błędów.
Czy ja gdzieś twierdze które błedy są ważniejsze od innych?
Nie, to ja tak twierdzę.
Quote:
Masz jakieś massage-id?
Aż tak bardzo lenistwa nie mam zamiaru wspierać.
Quote:
Śmiem natomiast wierdzić że pewien zbiór błedow można wyeliminować
poprzez *nie* używanie gównianych języków. To całkiem spory zbiór.
Cóż z tego, jeśli samo użycie jakiegoś języka może być aż tak dużym
błędem, że nie równoważy to błędów które ów język może wyeliminować?
--
Jarek
Desoft
Guest
Sun Sep 18, 2011 6:53 am
Quote:
Przejście w automatyce na sterowanie przy pomocy standardowych PC
uważam za jeden z najbardziej nietrafionych pomysłów.
A co oznacza CNC?
"Computer numerical control" - czyli sterowanie komputerem. Często używa
się tej nazwy w odniesieniu do obrabiarek sterowanych numerycznie.
No to jak może być komputer bez komputera?
Quote:
Jakoś ciężko wyobrazić mi sobie maszynę sterowaną przez PLC.
Fanuc może trochę przypomina podrasowany PLC.
A jak zrobić HMI na czymś innym oprócz PC-ta?
W środowisku przemysłowym używa się specjalizowanych paneli operatorskich.
Może w takim panelu siedzieć pecet przemysłowy z windowsem, czy
czymkolwiek innym, ale to nie jest niezbędne.
Obawiam się że jest niezbędne.
Nasuwa mi się analogia pomiędzy DOSem a OS-em graficznym.
Aby używać DOSa trzeba było być fachowcem, teraz w windowsach klika 5-7
latek.
Quote:
Wiele lat temu robiłem UI do maszyny na czymś takim:
http://avgautomation.com/avgmodconnect/assets/images/vfd_pci185bg.jpg
Maszyna miała w sobie 3 PLC, przez panel można było kłapać zaworami,
uruchamiać sekwencje działań, zmieniać nastawy PIDa, itp. Część operacji
była dostępna dla wszystkich, część zabezpieczona dwoma poziomami haseł,
czyli dość rozbudowane UI. Jedyna styczność jaką panel miał z pecetem to
programowanie.
A jak zrobiłeś sterowanie napędami? Powiązania pomiędzy nimi, np
iterpolację?
Jak zrobić na takich PLC symulację graficzną?
Wydaje mi się że mówimy o różnych maszynach. To nie było centrum obróbcze?
Jest wiele - bardzo wiele - miejsc gdzie PLC się sprawdzają i najbardziej
optymalne.
Chociaż SCADA zaczyna odgrywać coraz większą rolę.
--
Desoft
Waldemar Krzok
Guest
Sun Sep 18, 2011 8:19 am
Sebastian Biały wrote:
Quote:
Wiele znasz systemów operacyjnych ktore wspierają pisanie aplikacji
pod LPT?
FlexOS, RT-Linux a nawet Windows. Tylko po co?
A tu mnie zaciekawiłeś. Windows i LPT? Chyba że masz namyśli protokół
centronics. Po drugiej stronie trzeba by kupkę TTLi żeby to przerobić na
coś sensownego.
Nie. Wystarczy napisać driver, który obsługuje LPT tak, jak chcesz.
Quote:
Te złacza i mnożenie częsci generują problemy. W jednej z fabryk
u madzirów koło lat 90-tych pecet uśmiercił operatora bo sterował
"przez LPT" prasą i mu się wymsknęła karta z gniazda.
To nie wina PC-ta tylko programisty względnie projektanta hardware'u.
Projektant hardwareu to chińczyk który produkował pecety do obslugi
norton commandera w msdosie, a programista po wysunięciu karty z gniazda
miał nikłe szanse na wyłączenie prasy bez wględu na to ile napisał
wczesniej programów w turbo pascalu.
No nie. Pisałeś i robiłeś cokolwiek, co ma związek z bezpieczeństwem?
Waldek
--
My jsme Borgové. Sklopte štíty a vzdejte se. Odpor je marný.
Sebastian Biały
Guest
Sun Sep 18, 2011 8:35 am
On 2011-09-18 10:19, Waldemar Krzok wrote:
Quote:
Wiele znasz systemów operacyjnych ktore wspierają pisanie aplikacji
pod LPT?
FlexOS, RT-Linux a nawet Windows. Tylko po co?
A tu mnie zaciekawiłeś. Windows i LPT? Chyba że masz namyśli protokół
centronics. Po drugiej stronie trzeba by kupkę TTLi żeby to przerobić na
coś sensownego.
Nie. Wystarczy napisać driver, który obsługuje LPT tak, jak chcesz.
No własnie. Dokładnie na tej samej zasadzie można powiedzieć że Windows
supportuje promy kosmiczne, bo wystarczy napisać driver.
Quote:
Projektant hardwareu to chińczyk który produkował pecety do obslugi
norton commandera w msdosie, a programista po wysunięciu karty z gniazda
miał nikłe szanse na wyłączenie prasy bez wględu na to ile napisał
wczesniej programów w turbo pascalu.
No nie. Pisałeś i robiłeś cokolwiek, co ma związek z bezpieczeństwem?
Owszem. Tylko to nie ja wcisnąłem peceta z kartą LPT. Ja bym tego nie
zrobił. Od tego są sterowniki w których scalaki z podstawek nie
wypadają, druty z gniazdek nie wychodzą i zasilacze się nie palą. Pecet
może sobie co najwyżej grzecznie liczyć ile wyciśnięto garnków.
Waldemar Krzok
Guest
Sun Sep 18, 2011 8:57 am
Sebastian Biały wrote:
Quote:
On 2011-09-18 10:19, Waldemar Krzok wrote:
Wiele znasz systemów operacyjnych ktore wspierają pisanie aplikacji
pod LPT?
FlexOS, RT-Linux a nawet Windows. Tylko po co?
A tu mnie zaciekawiłeś. Windows i LPT? Chyba że masz namyśli protokół
centronics. Po drugiej stronie trzeba by kupkę TTLi żeby to przerobić na
coś sensownego.
Nie. Wystarczy napisać driver, który obsługuje LPT tak, jak chcesz.
No własnie. Dokładnie na tej samej zasadzie można powiedzieć że Windows
supportuje promy kosmiczne, bo wystarczy napisać driver.
Jeszcze nie widziałem PCta z wbudowanym promem kosmicznym.
A na serio, jak nie wiesz jak pisać drivery to twój problem. Ale Windows
pozwala na pisanie swoich driverów.
Quote:
Projektant hardwareu to chińczyk który produkował pecety do obslugi
norton commandera w msdosie, a programista po wysunięciu karty z gniazda
miał nikłe szanse na wyłączenie prasy bez wględu na to ile napisał
wczesniej programów w turbo pascalu.
No nie. Pisałeś i robiłeś cokolwiek, co ma związek z bezpieczeństwem?
Owszem. Tylko to nie ja wcisnąłem peceta z kartą LPT. Ja bym tego nie
zrobił. Od tego są sterowniki w których scalaki z podstawek nie
wypadają, druty z gniazdek nie wychodzą i zasilacze się nie palą. Pecet
może sobie co najwyżej grzecznie liczyć ile wyciśnięto garnków.
Są też PCty spełniające ww warunki. Oprócz tego zabezpieczenia robi się, w
zależności od niebezpieczeństw w przypadku awarii. Analizy kumulacji błędów
też trzeba zrobić.
Waldek
--
My jsme Borgové. Sklopte štíty a vzdejte se. Odpor je marný.
Sebastian Biały
Guest
Sun Sep 18, 2011 9:12 am
On 2011-09-18 10:57, Waldemar Krzok wrote:
Quote:
Nie. Wystarczy napisać driver, który obsługuje LPT tak, jak chcesz.
No własnie. Dokładnie na tej samej zasadzie można powiedzieć że Windows
supportuje promy kosmiczne, bo wystarczy napisać driver.
Jeszcze nie widziałem PCta z wbudowanym promem kosmicznym.
Ja zaś ostatnio nie widziałem peceta z wbudowanym LPT. Dalej to nijak
nie tłumaczy że Windows ma wsparcie dla LPT w sensie jaki istnieje w tym
wątku.
Quote:
A na serio, jak nie wiesz jak pisać drivery to twój problem.
K... znowu jakaś osobista wycieczka. Skąd wiesz że nie potrafię?
Quote:
Ale Windows
pozwala na pisanie swoich driverów.
ROTFL. No właśnie. System nie wspiera bezpośrednio i tylko o to mi
chodzi. Znalezienie się windowsa na tej liście to pomyłka. On nie
wspiera dłubania po pinach LPT. Nie ma żadnego API do tego. Nie ma
żadnego sterownika do tego. Musisz sobie sam to wydziobać. Prawie jak w
Atmelku, z resztą co tam prawie, *DOKŁADNIE* jak w Atmelku.
Quote:
Są też PCty spełniające ww warunki.
Gdyby Babcia miała wąsy.... Skoro była mowa o wypadającej karcie LPT to
zapewniam, że nie ma mowy o *takim* pececie.
Quote:
Oprócz tego zabezpieczenia robi się, w
zależności od niebezpieczeństw w przypadku awarii. Analizy kumulacji błędów
też trzeba zrobić.
Polemizuje tutaj z Twoją tezą że winny jest programista od softu na PC.
Otóż on nie jest winny - winny jest wyłacznie pokemon projektujący cusia
po drugiej stronie LPT. Programista softu na PC po wypadnięciu karty ze
złacza *NIC* nie może zrobić. On stracił właśnie kontrolę nad wszystkim.
Mario
Guest
Sun Sep 18, 2011 10:06 am
W dniu 2011-09-18 08:53, Desoft pisze:
Quote:
Przejście w automatyce na sterowanie przy pomocy standardowych PC
uważam za jeden z najbardziej nietrafionych pomysłów.
A co oznacza CNC?
"Computer numerical control" - czyli sterowanie komputerem. Często
używa się tej nazwy w odniesieniu do obrabiarek sterowanych numerycznie.
No to jak może być komputer bez komputera?
Jakoś ciężko wyobrazić mi sobie maszynę sterowaną przez PLC.
Fanuc może trochę przypomina podrasowany PLC.
A jak zrobić HMI na czymś innym oprócz PC-ta?
W środowisku przemysłowym używa się specjalizowanych paneli
operatorskich. Może w takim panelu siedzieć pecet przemysłowy z
windowsem, czy czymkolwiek innym, ale to nie jest niezbędne.
Obawiam się że jest niezbędne.
W panelu może siedzieć armowy komputer z windows CE. Bardziej można go
porównać do palmtopa czy tableta niż do PC. A jeśli nawet HMI jest
zrobione na PC (na przykład ze SCADA) to przecież służy do wizualizacji
a nie odpowiada bezpośrednio za bezpieczeństwo maszyny.
--
Pozdrawiam
MD
Desoft
Guest
Sun Sep 18, 2011 11:09 am
Quote:
W panelu może siedzieć armowy komputer z windows CE. Bardziej można go
porównać do palmtopa czy tableta niż do PC. A jeśli nawet HMI jest
zrobione na PC (na przykład ze SCADA) to przecież służy do wizualizacji a
nie odpowiada bezpośrednio za bezpieczeństwo maszyny.
Brdzo trudno zrobić "bezpieczeństwo" na sterowaniu. 90% nowych maszyn nadal
używa specjalizowanych modułow do tego.
--
Desoft
Michoo
Guest
Sun Sep 18, 2011 12:26 pm
W dniu 18.09.2011 11:12, Sebastian Biały pisze:
Quote:
ROTFL. No właśnie. System nie wspiera bezpośrednio i tylko o to mi
chodzi. Znalezienie się windowsa na tej liście to pomyłka. On nie
wspiera dłubania po pinach LPT. Nie ma żadnego API do tego. Nie ma
żadnego sterownika do tego. Musisz sobie sam to wydziobać. Prawie jak w
Atmelku, z resztą co tam prawie, *DOKŁADNIE* jak w Atmelku.
Po sieci krąży coś o nazwie zdaje się inout32.dll co jest sterownikiem
pozwalającym na bezpośrednie odwołania do LPT z userspace. Problem jest
jedynie taki, że scheduler może nadal robić dziwne numery. (Opisywałem
chyba jakiś czas temu jak to po SPI zrobionym za pomocą LPT co pewien
czas przychodziły śmieci.)
--
Pozdrawiam
Michoo
Goto page Previous 1, 2, 3 ... 8, 9, 10, 11, 12, 13 Next