Goto page Previous 1, 2, 3 ... 6, 7, 8 ... 11, 12, 13 Next
Sebastian Biały
Guest
Sat Sep 17, 2011 5:47 pm
On 2011-09-17 19:28, Jarosław Sokołowski wrote:
Quote:
Mam nadzieję, że nie grywa Pan
Stosujesz żałosne metody A.L. do oceny dyskutantów?
Quote:
Fajnie. Znaczy odpalasz swoj skrypt jako admin?
Nie.
Więc jak uzyskujesz prawa do przestrzeni I/O LPT? Sterownikiem kernela?
Hackowaniem jądra?
Quote:
To wynik wielu czynników, ale jednym z nich są niedoróbki w kodzie
windowsa i sterownikow. Niby mamy to za sobą, ale czy na pewno pewnego
dnia następna prasa nie przywali kogoś w glowę bo sterownik się
wypierniczy na dereferencji nulowego pointera?
Bash nie wie co to jest defragmentacja
Ciąg dalszy żalosnych metod A.L. czy zwykłe przejęzyczenie?
Quote:
nulowego pointera
Albowiem bash działa w przestrzeni równoległej gdzie pojęcie nulowego
pointera nie istnieje i już! W szczegolności w sterowniku do LPT! I
wtedy się budzisz. Ja też kiedyś sniłem do czasu aż kernel z lini 2.4
zrobił oopsa przy obsłudzie - wydawało by się - trywialnego COMa.
Powtarzalnego 100%, żeby nie było że to krasnoludki.
Quote:
Nie mam z góry zaufania ani do jednego, ani do drugiego. Ale na ogół
ma się większe zaufanie do miliona linii sprawdzanych w praktyce od
dwadziestu lat, niż do stu linni napisanych wczoraj przez jakichś
debeściaków ("bo my to panie wszystko testujemy, a poza tym mamy
kilkadziesiąt lat doświadczenia").
Debesciaki są w ogólności bardziej bezpieczni niż windows zaopatrzony w
sterowniki produkowane na kolanie w chinach chodzace w trybie jądra.
Chwilowo nie ma na rynku popularnych mikrokernelów, więc *zawsze* jesteś
w czarnej dupie watpliwości co do tego czy sterownik myszki nie zrobi
BSOD po 3 tygodniach i 14 sekundach pracy. Chińczyk nie ma czasu na
testowanie takich dupereli.
Jarosław Sokołowski
Guest
Sat Sep 17, 2011 5:50 pm
Pan Jacek Radzikowski napisał:
Quote:
Poszukuję schematu/urządzenia które w dowolny sposób przy pomocy
komputera będzie potrafiło załączyć i wyłączyć urządzenie 230V max 10A.
Całym zapleczem oprogramowania (jeśli to będzie na mikroprocesorze)
zajmę się sam. Chodzi tylko o urządzenie które zapewni takie sterowanie.
Spotkał się ktoś z czymś takim ?
Myślę że potrzebujesz czegoś takiego:
http://www.ebay.com/itm/USB-Four-4-Relay-Card-Home-Automation-Software-/170621704739
Obsługa przez USB, powinno być łatwo napisać oprogramowanie sterujące.
Jeśli potrzebujesz więcej kanałów, to widziałem też wersję z 8 przekaźnikami.
Albo od tego samego producenta:
http://www.denkovi.com/product/40/internet-ethernet-four-channel-relay-board.html
Trochę drożej, ale za to porządnie, z ethernetem.
--
Jarek
Sebastian Biały
Guest
Sat Sep 17, 2011 6:02 pm
On 2011-09-17 19:11, Jarosław Sokołowski wrote:
Quote:
My. Programiści. My naprawde potrafimy pisać niezawodne programy. W
wielu językach. Zalicza się do nich C i C++. Bywa ze java. Bywa że Ada.
Bywa że lisp. Bash jest gdzieś na samym dnie jako utility language. Nic
dziwnego, to padlina.
Wiem, wiele potraficie. Ale też przecież potraficie popełniać błędy...
I dzięki temu że to wiemy nauczyliśmy się również im przeciwdziałać. W
sposób, ktory pozwala pisać programy o rzedy bardziej niezawodne niż w
jezykach dynamicznych/interpretowanych a w szczegolności niż języki
padlinowate jaki bash, perl czy inny cli-php.
Quote:
Chwalenie się, że programy napisane w języku interpretowanym (a więc
zapewne i dynamicznym) będa mniej awaryjne niż pisane w czymkolwiek
innym obnaża twoją wiedzę dotycząca innych jezyków i metod utrzymywania
jakości kodu.
Skoro rzeczywiście są mniej awaryjne, to co szkodzi się pochwalić?
Ale przecież nie chodzi o bezawaryjność i bezbłędność, tylko o możliwość
szybkiego dostrzeżenia i poprawienia pomyłek.
NIE. Chodzi o to by nie dopuścić do pomyłek w momecie pisania. Nie
dopuscić. Żadnego dostrzegania i poprawiania. W bashu nie ma o tym mowy.
W C++ można ogromną ilość pomylek wyeliminować w compile-time bez
jednego straconego cyklu w run-time. To dwa końce problemu jakości kodu
w związku z językiem. Można dyskutować czy poprawienie buga w C jest
łatwiejsze niż w bash, ale z doświadczenia powiem: jest łatwiejsze w C.
Przynajmniej sa narzędzia.
Żeby była jasność: mowimy o sofcie który jest nieco bardziej rozbudowany
niż klepanie przekaźnikiem. Klepanie przekaźnikiem pewno dało by się
napisać w command.com w miarę bez błedow.
Quote:
Natomiast staram się unikać dawania możliwości decyzji
inż. inź. Mamoniom, którzy potrafią docenić tylko to, co sami znają.
O dziwo czesto słyszę to od zwolenników wstawiania 8051 do
*wszystkiego*. Taki typowy embedded-banał.
Jarosław Sokołowski
Guest
Sat Sep 17, 2011 6:44 pm
Pan Sebastian Biały napisał:
Quote:
"Programista PC (w tym przypadku) pisze kilka linijek skryptu
działającego w znanym środowisku"
To jakie to środowisko? Jaki OS?
Znane. W moim przypadku będzie to jakiś unix.
Nie przeszkadza Ci fakt że unix to nie jest środowsko real-time,
Przy opuszczaniu rolet i włączaniu grzejnika olejowego? Nie.
Quote:
że bash nie ma dostepu do potów I/O, że w normalnej sytuacji jako
user nie masz dostępu do przestrzeni I/O?
Raczej pomaga.
Quote:
Swego czasu miałem w rękach kartę sterującą CNC. Ładna, pod USB. No to
pierwsze co zrobiłem to podczas pracy wyrwałem kabel. Zatrzymało, ale
silnik po kilkunastu sekundach zaczyna śmierdzieć. Od, nastepny tępy
debil zrobił sterowanie PWM z użyciem softu na PC a nie na karcie ...
Nic dziwnego, na karcie był tylko konweter USB->GPIO.
Dlaczego tępy debil?
Brak wyobraźni.
Nie mam żadnych przesłanek do oceny jego wyobraźni. W ogóle niewiele
o nim wiem.
Quote:
Człowiek o praktycznym podejściu do rzeczy.
Nie. On nie rózni się niczym od eksperów od sterowania przez LPT.
Mam szacunek do wszystkich ekspertów. Więc jeśli tak, to zasłużył na moje
uznanie.
Quote:
Albo przynajmnie nie napisał o skutkach i nie ostrzegł mniej kumatych.
Miło by to wygladało w instrukcji, prawda?
Kiedyś na końcówkach kabli USB były nalepki z ostrzeżeniem, by nie
wtykać tego w komputer z systemem Windows, zanim się nie zainstaluje
oprogramowania. No i faktycznie, gdy się to zignorowało, to jeśli ktoś
nie był fachowcem, to po czymś takim nie udawało mu się już zmusić
urządzenia do działania.
Quote:
"I pamiętaj, że odłaczenie kabla USB może doprowadzić do pożaru. W celu
uniknięcia pożaru proszę o owinięcie kabla i komputera załaczoną taśmą
samoprzylepna używając węzła szotowego."
Jeśli to mogło skutkować pożarem, to oczywiście powinien o tym napisać.
A jeśli się dało, to sam powinien zapewnić niemożnaość rozłączenia.
--
Jarek
Sebastian Biały
Guest
Sat Sep 17, 2011 6:51 pm
On 2011-09-17 20:38, Jarosław Sokołowski wrote:
Quote:
Albowiem bash działa w przestrzeni równoległej gdzie pojęcie nulowego
pointera nie istnieje i już! W szczegolności w sterowniku do LPT! I
wtedy się budzisz. Ja też kiedyś sniłem do czasu aż kernel z lini 2.4
zrobił oopsa przy obsłudzie - wydawało by się - trywialnego COMa.
Ten kernel był pisany w bashu?
Ten bash pracowal w środowisku stworzonym przez kernel. Sam z siebie
pracować nie potrafi. Problem kernela jest problemem basha.
Quote:
Powtarzalnego 100%, żeby nie było że to krasnoludki.
No to całe szczęście. W takim razie nie ma tragedii.
Jasne, skonczyło się na poprawianiu kodu w kernelu. Jeszcze jedna do
miliona niewiadomych o stabilności całości systemu. Przy takiej ilości
nie ma już żadnego znaczenia, kontrole straciłeś wiele milionów lini
kodu wczesniej.
Quote:
Chwilowo nie ma na rynku popularnych mikrokernelów, więc *zawsze* jesteś
w czarnej dupie watpliwości co do tego czy sterownik myszki nie zrobi
BSOD po 3 tygodniach i 14 sekundach pracy. Chińczyk nie ma czasu na
testowanie takich dupereli.
Nic mi jeszcze nie zrobiło BSOD
Jesteś w mniejszości.
Quote:
gdy chodzi o nowe rzeczy, staram się jak najwięcej robić we własnym
zakresie (to znaczy przynajmniej mieć nad tym kontrolę).
Czyli kernel też piszesz samodzielnie?
Sebastian Biały
Guest
Sat Sep 17, 2011 7:05 pm
On 2011-09-17 20:45, Jarosław Sokołowski wrote:
Quote:
W sposób, ktory pozwala pisać programy o rzedy bardziej niezawodne niż
w jezykach dynamicznych/interpretowanych a w szczegolności niż języki
padlinowate jaki bash, perl czy inny cli-php.
Co z tego, że macie sposoby na pisanie programów niezawodnych, skoro
nie umiecie przeanalizować założeń? Owszem, może uda wam się w ten
sposób zrobić działający program, ale to na nic, gdy robi on nie to,
co powinien.
Czekaj, skąd wytrzasnałeś brak umiejętności analizy założeń? Masz jakąs
szklaną kulę? I skąd to poprzednioustrojowe używanie "Wy" ?
Quote:
Ale przecież nie chodzi o bezawaryjność i bezbłędność, tylko o możliwość
szybkiego dostrzeżenia i poprawienia pomyłek.
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. Tak,
doskonale sobie zdaje sprawę że wiekszośc z nich przetrwala w
przechowalni o nazwie embedded. Widuje ich na codzień. Ta dyskusja wraca
bardzo czesto i zazwyczaj kończy się na inwektywach.
Quote:
Ani do żadnej roboty, bo człowiek jest omylny z definicji.
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ą. Trudno. Takie języki też sa potrzebne, ale u
diabła dlaczego ma od nich zależeć czyjeś życie?
Quote:
Ale przecież wy wszystko robicie tak samo, niezależnie czy chodzi
o klepanie przekaźnikiem czy czymś innym. Bo pisanie w innym języku
jest "gówniane".
Sam pisze oprogramowanie sterujące pewnym cusiem w JavaScript. Bo
doskonale wiedzialem, po analizie, czego i jak potrzebuje użyć. Pomimo
tego nie potrafie nawet naszkicować zbioru warunków na które odpowiedzią
byłby bash. Zawsze jest lepsza alternatywa.
Quote:
O dziwo czesto słyszę to od zwolenników wstawiania 8051 do
*wszystkiego*. Taki typowy embedded-banał.
Albo do *wszystkiego* używają jednego języka programowania.
Tak, to ci sami. Stosują jakąś lokalną gwarę C.
Jarosław Sokołowski
Guest
Sat Sep 17, 2011 7:11 pm
Pan Sebastian Biały napisał:
Quote:
Nie. Mamy kilkadziesią lat doświadczeń w pisaniu aplikacji. Naprawdę,
potrafimy pisac programy niezawodne i przetestowane używając językow
innych niż perl czy bash *nawet* w jednym egzemplarzu. Kwestia warsztatu.
Jeśli od kilkudziesięciu lat nie wyszliście
My. Programiści. My naprawde potrafimy pisać niezawodne programy. W
wielu językach. Zalicza się do nich C i C++. Bywa ze java. Bywa że Ada.
Bywa że lisp. Bash jest gdzieś na samym dnie jako utility language. Nic
dziwnego, to padlina.
Wiem, wiele potraficie. Ale też przecież potraficie popełniać błędy...
Quote:
powyżej robienia automatyki do zaciągania rolet w oknie obok komputera
i jeśli nie testujecie robionych rzeczy przed przekazaniem ich do
użytkowania (mimo że potraficie), to nie ma się czym chwalić.
Jeśli, jesli, jesli. I wniosek. No pięknie.
....na przykład nie dostrzegając kilku istotnych "jeśli" i iść dalej
jakby ich nie było. Nie zawsze wychodzi pięknie.
Quote:
Nawet warsztatem w takiej sytuacji nie ma co się chwalić, bo kogo to
obchodzi.
A kogo obchodzi pisanie kodu do sterowania czymkolwiek w bashu?
Tych co piszą.
Quote:
To chory język.
Chlorchinaldin powinien pomóc.
Quote:
Chwalenie się, że programy napisane w języku interpretowanym (a więc
zapewne i dynamicznym) będa mniej awaryjne niż pisane w czymkolwiek
innym obnaża twoją wiedzę dotycząca innych jezyków i metod utrzymywania
jakości kodu.
Skoro rzeczywiście są mniej awaryjne, to co szkodzi się pochwalić?
Ale przecież nie chodzi o bezawaryjność i bezbłędność, tylko o możliwość
szybkiego dostrzeżenia i poprawienia pomyłek.
Quote:
- Panie Kaziu, niech pan mi tu da zapasowago peceta z LPT bo się zjarał
znowu zasilacz i upier... płytę.
- Ale nie ma, zapasy się skonczyły, w sklepach nie ma
- Cholera... dobra, to bankrutujemy
Jeśli tam chadzają takie dialogi, to już dawno powinni zbankrutować.
Ani trochę mi ich (was?) nie żal.
Co sugerujesz w zamian zamiast następnej nietrafionej oceny?
Ich (wasza?) ocena akurat jest trafna: powinni(ście) zbankrutować.
Quote:
PS. Żeby była jasność. Nie jestem zwolennikiem stosowania *Atmela* jako
sterownika. Jestem natomiast wrogiem stosowania peceta tam, gdzie nie ma
miejsca na pomyłkę. A już na pewno nie peceta z gównianym bashem.
Ja nie jestem wrogiem stosowania czegokolwiek jako cokolwiek, o ile ma
to uzasadnienie. Natomiast staram się unikać dawania możliwości decyzji
inż. inź. Mamoniom, którzy potrafią docenić tylko to, co sami znają.
--
Jarek
Jarosław Sokołowski
Guest
Sat Sep 17, 2011 7:28 pm
Pan Sebastian Biały napisał:
Quote:
Nie przeszkadza Ci fakt że unix to nie jest środowsko real-time,
Przy opuszczaniu rolet i włączaniu grzejnika olejowego? Nie.
To bardzo skrajny przypadek sterowania.
A co ja poradzę, że przyszło nam taki analizować?
Quote:
Zaryzykuje ze stosowanie w tym celu peceta jest mało ekonomiczne.
Mam nadzieję, że nie grywa Pan na giełdzie. Ocena ryzyka (ekonomicznego)
słabo Panu wychodzi. Majstrowanie dodatkowego sterownika nigdy nie
będzie tańsze.
Quote:
że bash nie ma dostepu do potów I/O, że w normalnej sytuacji jako
user nie masz dostępu do przestrzeni I/O?
Raczej pomaga.
Fajnie. Znaczy odpalasz swoj skrypt jako admin?
Nie.
Quote:
No i proszę, problem solved.
?
Quote:
A ja tu glupio rozmyślam jak zrobić coś lepiej.
E tam lepiej. A poza tym, wszystko się zgadza.
Quote:
Brute force jest zawsze lepsze.
???
Quote:
Kiedyś na końcówkach kabli USB były nalepki z ostrzeżeniem, by nie
wtykać tego w komputer z systemem Windows, zanim się nie zainstaluje
oprogramowania. No i faktycznie, gdy się to zignorowało, to jeśli ktoś
nie był fachowcem, to po czymś takim nie udawało mu się już zmusić
urządzenia do działania.
To wynik wielu czynników, ale jednym z nich są niedoróbki w kodzie
windowsa i sterownikow. Niby mamy to za sobą, ale czy na pewno pewnego
dnia następna prasa nie przywali kogoś w glowę bo sterownik się
wypierniczy na dereferencji nulowego pointera?
Bash nie wie co to jest defragmentacja nulowego pointera, więc gdyby
miał akurat takie obsesje, to bym mu poradził używanie basha.
Quote:
Masz jakieś gwarancje że kod składający się z milionów lini kodu do
ktorego nawet nie masz wglądu jest lepiej wytestowany niż sto lini
w C na avr?
Nie mam z góry zaufania ani do jednego, ani do drugiego. Ale na ogół
ma się większe zaufanie do miliona linii sprawdzanych w praktyce od
dwadziestu lat, niż do stu linni napisanych wczoraj przez jakichś
debeściaków ("bo my to panie wszystko testujemy, a poza tym mamy
kilkadziesiąt lat doświadczenia").
Quote:
A jeśli się dało, to sam powinien zapewnić niemożnaość rozłączenia.
Nierozłaczalne gniazdka USB.
Albo brak gniazdka.
Quote:
Czyli jak naprawić problem w innym miejscu niż występuje.
Przecież dymić się zaczęło po wyciągnięciu wtyczki.
Quote:
Musze ten pomysł gdzies zanotować. Oczywiście, żeby nigdy na niego nie
wpaść.
Jest niepatentowalny, więc nie ma obaw.
--
Jarek
Grzegorz Krukowski
Guest
Sat Sep 17, 2011 8:26 pm
On Fri, 16 Sep 2011 20:39:03 +0200, Sebastian Biały
<heby@poczta.onet.pl> wrote:
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. Szczegółów nie znam,
opowiadał mi człek pracujący potem przy ustalaniu przyczyn. Raban był
potem wielki i zakonczyło się wyp... wszelkich gównianych pecetów z lini
produkcyjnej.
Po pierwsze, to w szpitalu umarł chłop na oko, szczególnie że
szczegółów nie znasz.
Po drugie, zamiast wysnuć wniosek, że autor felernego rozwiązania miał
niewielkie pojęcie o zapewnieniu bezpieczeństwa kolega wysuwa wniosek,
że to LPT bee, no ciekawe, ciekawe, ale jakby pasujące do kolegi tezy.
Po trzecie, robienie sterownika na przysłowiowym Atmelku jest wbrew
pozorom dość drogim oraz niebezpiecznym rozwiązaniem dla użytkownika
końcowego. Szczególnie jak urządzenie ma pracować wiele lat. Też na
początku swej kariery dziwiłem się, dlaczego w większych fabrykach i
odpowiedzialniejszych zadaniach spuszcza się Atmelkowców na drzewo.
Trochę doświadczenia i wszystko stało się jasne. A maszyny sterowane
przez PC pracowały, pracują i pracować będą jeszcze wiele lat,
niezagrożone, bezpieczne, tanie, modyfikowalne.
--
Grzegorz Krukowski
Jarosław Sokołowski
Guest
Sat Sep 17, 2011 8:38 pm
Pan Sebastian Biały napisał:
Quote:
Mam nadzieję, że nie grywa Pan
Stosujesz żałosne metody A.L. do oceny dyskutantów?
Nie wiem kto to taki ten A.L., więc nawet nie wiem czy jego metody
są żałosne. Sądzę, że może być Pan znakomitym fachowcem w swojej
dziedzinie (jakieś programowanie czegoś bardzo konkretnego?),
ale uważam, że za tworzenie założeń i ocenę ekonomiki działań nie
powinien się Pan brać.
Quote:
Fajnie. Znaczy odpalasz swoj skrypt jako admin?
Nie.
Więc jak uzyskujesz prawa do przestrzeni I/O LPT?
Nie potrzebuję.
Quote:
Sterownikiem kernela? Hackowaniem jądra?
W tym momencie (pisania w bash) nie muszę sobie tym głowy zaprzątać.
Quote:
To wynik wielu czynników, ale jednym z nich są niedoróbki w kodzie
windowsa i sterownikow. Niby mamy to za sobą, ale czy na pewno pewnego
dnia następna prasa nie przywali kogoś w glowę bo sterownik się
wypierniczy na dereferencji nulowego pointera?
Bash nie wie co to jest defragmentacja
Ciąg dalszy żalosnych metod A.L. czy zwykłe przejęzyczenie?
Przejęzyczenie. A właściwie dyfuzja sąsiedniego z okienka.
Quote:
nulowego pointera
Albowiem bash działa w przestrzeni równoległej gdzie pojęcie nulowego
pointera nie istnieje i już! W szczegolności w sterowniku do LPT! I
wtedy się budzisz. Ja też kiedyś sniłem do czasu aż kernel z lini 2.4
zrobił oopsa przy obsłudzie - wydawało by się - trywialnego COMa.
Ten kernel był pisany w bashu?
Quote:
Powtarzalnego 100%, żeby nie było że to krasnoludki.
No to całe szczęście. W takim razie nie ma tragedii.
Quote:
Nie mam z góry zaufania ani do jednego, ani do drugiego. Ale na ogół
ma się większe zaufanie do miliona linii sprawdzanych w praktyce od
dwadziestu lat, niż do stu linni napisanych wczoraj przez jakichś
debeściaków ("bo my to panie wszystko testujemy, a poza tym mamy
kilkadziesiąt lat doświadczenia").
Debesciaki są w ogólności bardziej bezpieczni niż windows zaopatrzony
w sterowniki produkowane na kolanie w chinach chodzace w trybie jądra.
Z Windows nigdy nie miałem na poważnie do czynienia. Z debeściakami
czasem tak. Trudno mi porównywać, ale niebezpieczni są. Ponad tolerowane
przeze mnie granice.
Quote:
Chwilowo nie ma na rynku popularnych mikrokernelów, więc *zawsze* jesteś
w czarnej dupie watpliwości co do tego czy sterownik myszki nie zrobi
BSOD po 3 tygodniach i 14 sekundach pracy. Chińczyk nie ma czasu na
testowanie takich dupereli.
Nic mi jeszcze nie zrobiło BSOD, a co do Chińczyków, to nie mam uprzedzeń
narodowościowych -- traktuję ich jak innych debeściaków. Z tego powodu,
gdy chodzi o nowe rzeczy, staram się jak najwięcej robić we własnym
zakresie (to znaczy przynajmniej mieć nad tym kontrolę).
--
Jarek
Jarosław Sokołowski
Guest
Sat Sep 17, 2011 8:45 pm
Pan Sebastian Biały napisał:
Quote:
Wiem, wiele potraficie. Ale też przecież potraficie popełniać błędy...
I dzięki temu że to wiemy nauczyliśmy się również im przeciwdziałać.
Niestety nie ma prostego wynikania.
Quote:
W sposób, ktory pozwala pisać programy o rzedy bardziej niezawodne niż
w jezykach dynamicznych/interpretowanych a w szczegolności niż języki
padlinowate jaki bash, perl czy inny cli-php.
Co z tego, że macie sposoby na pisanie programów niezawodnych, skoro
nie umiecie przeanalizować założeń? Owszem, może uda wam się w ten
sposób zrobić działający program, ale to na nic, gdy robi on nie to,
co powinien.
Quote:
Ale przecież nie chodzi o bezawaryjność i bezbłędność, tylko o możliwość
szybkiego dostrzeżenia i poprawienia pomyłek.
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.
Ani do żadnej roboty, bo człowiek jest omylny z definicji.
Quote:
Żeby była jasność: mowimy o sofcie który jest nieco bardziej rozbudowany
niż klepanie przekaźnikiem. Klepanie przekaźnikiem pewno dało by się
napisać w command.com w miarę bez błedow.
Ale przecież wy wszystko robicie tak samo, niezależnie czy chodzi
o klepanie przekaźnikiem czy czymś innym. Bo pisanie w innym języku
jest "gówniane".
Quote:
Natomiast staram się unikać dawania możliwości decyzji inż. inź.
Mamoniom, którzy potrafią docenić tylko to, co sami znają.
O dziwo czesto słyszę to od zwolenników wstawiania 8051 do
*wszystkiego*. Taki typowy embedded-banał.
Albo do *wszystkiego* używają jednego języka programowania.
--
Jarek
Sebastian Biały
Guest
Sat Sep 17, 2011 9:06 pm
On 2011-09-17 22:26, Grzegorz Krukowski wrote:
Quote:
Po drugie, zamiast wysnuć wniosek, że autor felernego rozwiązania miał
niewielkie pojęcie o zapewnieniu bezpieczeństwa kolega wysuwa wniosek,
że to LPT bee, no ciekawe, ciekawe, ale jakby pasujące do kolegi tezy.
To "ciekawe" to ustalenia ekspertów powołanych do zbadania przyczyn
wypadku. Osoba z którą rozmawiałem była w gronie tych ekspertów jako
miejscowy automatyk.
Quote:
A maszyny sterowane
przez PC pracowały, pracują i pracować będą jeszcze wiele lat,
niezagrożone, bezpieczne, tanie, modyfikowalne.
Z kupą drutów na LPT ...
I mała uwaga: nie jestem zwolennikiem Atmelków.
Piotr
Guest
Sat Sep 17, 2011 9:10 pm
W dniu 2011-09-16 20:39, Sebastian Biały pisze:
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. Szczegółów nie znam,
opowiadał mi człek pracujący potem przy ustalaniu przyczyn. Raban był
potem wielki i zakonczyło się wyp... wszelkich gównianych pecetów z lini
produkcyjnej.
Pomijając kwestię sterowania z PC, sprzętowo układ sterowania też musiał
być zupełnie spieprzony. Przy prawidłowo zaprojektowanych obwodach
bezpieczeństwa nie ma możliwości by sterowanie procesowe (obojętnie czy
to PLC czy PC) wymusiło przypadkowy ruch narzędzia prasy.
pozdrawiam
Sebastian Biały
Guest
Sat Sep 17, 2011 9:15 pm
On 2011-09-17 21:38, Jarosław Sokołowski wrote:
Quote:
Ten bash pracowal w środowisku stworzonym przez kernel. Sam z siebie
pracować nie potrafi. Problem kernela jest problemem basha.
Ale to kernel był skopany. Więc wiadomo kto winny i gdzie poprawiać.
Ale to jedyny kernel jaki masz, bo starsze nie obslugują hardware a
nowszych nie ma. Jesteś w dupie. Pozostaje rękodzieło, poprawianie buga
po kimś. A miało być tak tanio a wyszlo jak zwykle.
Quote:
Jeszcze jedna do miliona niewiadomych o stabilności całości systemu.
Przy takiej ilości nie ma już żadnego znaczenia, kontrole straciłeś
wiele milionów lini kodu wczesniej.
Kernel został napisany w C. Czy w tej sytuacji należy powiedzieć:
1. C jest gównianym językiem.
2. A co to ma do rzeczy?
3. Masaj.
Należy powiedzieć: kernel pisany jest przez przypadkowych ludzi
tworzących jako-tako działajace oprogramowanie. Problem buga we własnym
kodzie to tylko jeden z milionów miejsc gdzie coś się może popsuć. Przy
czym w kernelu który poza obsługą LPT zajmuje 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.
W przypadku Windowsa jest w sumie tak samo, może poza tym ze zamiast
reverse-engeneering mamy "stabilizacje sterownikow poprzez sprzężenie
zwrotne od userów".
I tak, jezyk C w embedded to gówno. Przy czym już kiedyś pisalem czemu.
Sebastian Biały
Guest
Sat Sep 17, 2011 9:29 pm
On 2011-09-17 21:47, Jarosław Sokołowski wrote:
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.
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".
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?".
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.
Quote:
Bo ja nie oddam swego życia (a nawet rzeczy o wiele mniej cennych)
w ręce koderów.
Oddajesz codziennie.
Quote:
Sam pisze oprogramowanie sterujące pewnym cusiem w JavaScript.
Moje gratulacje.
Bo doskonale wiedzialem, po analizie, czego i jak potrzebuje użyć.
Świetnie. Widzę, że praca w zespole przynosi efekty.
Jakim zespole?
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ść.
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.
Goto page Previous 1, 2, 3 ... 6, 7, 8 ... 11, 12, 13 Next