Pan Sebastian Biały napisał:

>>> 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.

Ale to kernel był skopany. Więc wiadomo kto winny i gdzie poprawiać.

>>> 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.

Toć mówię, że dobrze. Źle by było, gdyby skończyło się wcześniej.

> 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.

>> Nic mi jeszcze nie zrobiło BSOD
>
> Jesteś w mniejszości.

Wiem. Na szczęście ta mniejszość ma lepiej niż większość.

>> 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?

Nie mam potrzeby, jestem zadowolony z tego co jest. Ale jak jeden taki
nie był zadowolony, to napisał.

--
Jarek

do góry

Pan Sebastian Biały napisał:

>> 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ń?

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.

> skąd to poprzednioustrojowe używanie "Wy" ?

Z użycia liczby mnogiej wywnioskowałem, że wypowiada się Pan w imieniu
jakiejś grupy (chyba programistów).

>>> 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.

> Tak, doskonale sobie zdaje sprawę że wiekszośc z nich przetrwala
> w przechowalni o nazwie embedded.

Jak już Pan zdążył zauważyć, jestem w mniejszości. Nigdy nie robiłem
kodu embedded (choć zdarzało mi się pisać soft do urządzeń, które gdyby
miały być produkowane w dłuższych seriach, to powinny taki kod otrzymać).

> 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?

>> 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ą.

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.

> Trudno. Takie języki też sa potrzebne, ale u diabła dlaczego ma od
> nich zależeć czyjeś życie?

Bo ja nie oddam swego życia (a nawet rzeczy o wiele mniej cennych)
w ręce koderów. Czasy Leonardów skończyły się wraz z Odrodzeniem,
nie ma takich, co potrafią wszystko. Tak więc koderzy do kodowania,
a ja nie łudzę się, że będą oni w stanie pojąć całość zagadnienia.

>> 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.

Moje gratulacje.

> Bo doskonale wiedzialem, po analizie, czego i jak potrzebuje użyć.

Świetnie. Widzę, że praca w zespole przynosi efekty.

> Pomimo tego nie potrafie nawet naszkicować zbioru warunków na które
> odpowiedzią byłby bash.

Nie wszyscy potrafią wszystko.

> Zawsze jest lepsza alternatywa.

Zawsze. Od początku Panu o tym mówiłem.

--
Jarek

do góry

On Fri, 16 Sep 2011 20:39:03 +0200, Sebastian Biały
<h...@p...onet.pl> wrote:

>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

do góry

On 2011-09-17 22:26, Grzegorz Krukowski wrote:
> 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.

> 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.

do góry

W dniu 2011-09-16 20:39, Sebastian Biały pisze:

> 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

do góry

On 2011-09-17 21:38, Jarosław Sokołowski wrote:
>> 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.

>> 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.

do góry

Pan Sebastian Biały napisał:

>> 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.

Wiem gdzie jestem -- nie tam. Tu nie mamy takich problemów.

> Pozostaje rękodzieło, poprawianie buga po kimś.

Brrr, wstrętne. To tak, jakby myć zęby cudzą szczoteczką do zębów.
Na samą myśl robi mi się niedobrze.

> A miało być tak tanio a wyszlo jak zwykle.

Nie miało być tanio, miało być dobrze.

>>> 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.

A ludzie powstali w wyniku przypadkowych mutacji DNA.

> 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.

Ja nie lubię literatury s-f. Znana mi rzeczywistość wygląda inaczej.

> I tak, jezyk C w embedded to gówno. Przy czym już kiedyś pisalem czemu.

W takim razie jeśli będę chciał wiedzieć co nie jest gównem, poszukam
sobie w archiwach.

--
Jarek

do góry

On 2011-09-17 21:47, Jarosław Sokołowski wrote:
>> 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. 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".

>> 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?".

>> 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.

> Bo ja nie oddam swego życia (a nawet rzeczy o wiele mniej cennych)
> w ręce koderów.

Oddajesz codziennie.

>> 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?

>> 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ść.

>> 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.

do góry

On 2011-09-17 23:10, Piotr wrote:
> 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.

Nie znam szczegółów poza ogólnym ustaleniem przyczyn wypadku.

do góry

W dniu 2011-09-17 22:26, Grzegorz Krukowski pisze:

> 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.
>
Maszyny *sterowane* przez PC to jednak wyjątki, PC'ty w automatyce
zwykle służą wyłącznie jako HMI/wizualizacja procesu. A gdyby ktoś wpadł
na pomysł budowy sterowania na pececie np. wcześniej wspomnianą prasą,
to proponuję poczytać aktualną dyrektywę maszynową, i już będzie
wiedział dlaczego jednak nie chce tego robić ;)

pozdrawiam

do góry