On 14/07/2011 08:52, Stachu 'Dozzie' K. wrote:
> On 2011-07-13, Andrzej Jarzabek<a...@g...com> wrote:
>> On 13/07/2011 19:04, Sebastian Biały wrote:
>>> On 2011-07-13 18:41, Andrzej Jarzabek wrote:
>>>> Ochrona patentowa też służy rozwojowi.
>>>
>>> OOOczywiście. Absolutnie natomiast nie służy nękaniu konkurencji z byle
>>> powodu. Szczególnie na pewno nie przez duże korporacjie i troli.
>>
>> Żeby nękać, trzeba mieć patent. Żeby mieć patent, ktoś musi wynaleźć
>> patentowalny wynalazek. To wynajdowanie to właśnie rozwój.
>
> Ktoś bodajże w Australii opatentował koło. Tak, ten patent służy
> rozwojowi, bo gościu wynalazł przedmiot patentu.

Przepraszam, ale nie będę teraz wyszukiwał informacji na temat prawa
patentowego w Australii, żeby wykazać, że to jest bzdura, skoro tobie
nawet się nie chce sprawdzić, czy to faktycznie było w Australii.

Ale załóżmy nawet, że tak było. Czy to, że sąd w Korei Północnej skazał
kogoś na śmierć na zbyt mało entuzjastyczne klaskanie Kimowi świadczy,
że sądy i karanie przestępców to zły pomysł?

> Kilka przykładowych patentów służących rozwojowi:

Masz jakąś tezę, bo nie chce mi się czytać całości tych wniosków? Jak
dla mnie wyglądają na jakieśtam rzeczywiście innowacyjne i że wymyślanie
tych rzeczy było faktycznie rozwojem oprogramowania, chociaż oczywiście
nie jestem w stanie ocenić, czy patenty są ważne.

do góry

On 2011-07-14, Sebastian Biały <h...@p...onet.pl> wrote:
> On 2011-07-14 18:12, Stachu 'Dozzie' K. wrote:
>>> Dziwne. Produkcja programowania to 1% działalności firmy ona nie znika
>>> jak robi bugi w sofcie i zlewa klienta. Naprawdę dziwne.
>> Podałem konkretny przykład, tylko raczyłeś orżnąć cytat ze stosownego
>> fragmentu.
>
> Oto stosowny fragment "bo nie produkcja oprogramowania jest jego główną
> działalnością". Cóż to zmienia postać rzeczy o 360 stopni.
>
> > Softu u nich nie
>> kupujesz. Kupujesz usługi transportowe.
>
> Czyli ile mają programistow vs marketingowców?
>
> Na wlasne oczy widzisz jak działa rynek: gówno się sprzedaje. Zupelnie
> jak iRzeczy. Takie czasy, jakie społeczeństwo taka jakość.

Zupełnie nie odniosłeś się do przykładu. Schenker sprzedaje usługi
logistyczne, nie oprogramowanie. Żeby zlecić im te usługi, używasz ich
programu, który jest zepsuty. To nie usługom było coś do zarzucenia,
tylko programowi.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2011-07-14, Sebastian Biały <h...@p...onet.pl> wrote:
> On 2011-07-14 18:09, Stachu 'Dozzie' K. wrote:
>>> Utopia. Komu by się chciało szukać buga który przychodzi od klienta z
>>> Somalii "bo jak tu klikam to mi się psuje" i jest gluchy na próby
>>> wyciągnięcia lepszego opisu. Tu nawet nie ma co debugować. Nagle trzeba
>>> zwracać kasę.
>> Ale wiesz że to nie tak działa? Nigdy nie słyszałeś o odrzuceniu
>> zgłoszenia reklamacyjnego z powodu niedostatecznego opisu usterki?
>
> Czekaj, a kto decyduje o tym jaki jest niedostateczny?

A w innych branżach? Jeśli się nie dogada sprzedający i kupujący,
zostaje zaufana strona trzecia (np. sąd konsumencki).

> Masz dwa przypadki:
>
> a) jak tu klikam to mi się psuje
>
> b) instrukcja store a0,$00f45560 z pod adresu $00568332 odwołuje się do
> pamięci poza heapem w sytuacji gdy zapytanie SQL przychodzi 5 milisekund
> po odrysowaniu okna na Ubuntu 10.10 z zainstalowanym KDE w werji 3.4.5 z
> poprawką foo-bar-fix-1 zawsze jesli zegar systemowy wskazuje parzysta
> sekundę.
>
> Dla mnie b) jest niedostateczny bo gdzie są do cholery pozostałe
> rejestry i wersja zasilacza ?!?!? Reklamacja odrzucona!

I w tym momencie pewnie UOKiK czy inny rzecznik praw konsumenta nakłada
na ciebie karę, bo klient podał tyle, ile był w stanie. Natomiast
odrzucenie a), jeśli to by był cały otrzymany opis, mogłoby być (choć
nie musiało) zasadne.

>> Oczywiście że nie. Ale widzisz, to już twoja wina że wybrałeś błędogenne
>> narzędzia do wyprodukowania swojego softu.
>
> Powiedz to tym którzy piszą soft przez kilkanaście lat. Nie przepisują -
> piszą, dopisują i sprzedają *ciągle*. Powiedz że hello world można
> przepisać w kilka minut na pythona to może niech przepiszą te swoje
> prymitywne systemy finansowe nad ktorymi pracują 15 lat z
> C/COBOLA/Pascala na coś lepszego. Pstryk i już. Python jest przecież
> taki fajny.

Bzdurzysz, gościu. Zaperzyłeś się. Może idź i się uspokój najpierw?

Jak ktoś produkuje system finansowy od 15 lat, to przez ten czas już
pewnie opracował standardy zapewniania jakości -- inaczej by się nie
utrzymał na rynku. Ale jeśli sprzedają mi (firmie w której pracuję)
system obiegu dokumentów, który nie wytrzymuje obciążenia *nastu nowych
dokumentów dziennie i wywołuje OOM-killera na maszynie z 8GB RAM-u, to
chyba mam prawo domagać się naprawy bądź zwrotu kosztów?

>> I to wcale nie jest dobrze że tak wybrałeś, bo produkujesz z błędami,
>> których dałoby się uniknąć.
>
> Jasne. Właściwy język == zero błedów. Utopia.

A kto ci nakłamał że zero? O_o

Dobór właściwego języka i właściwych narzędzi do niego pomaga
*zmniejszyć* ilość błędów, a nie zlikwidować je całkowicie.

I naprawdę nie będę płakał, jeśli hipotetycznie twoja firma, która
umyślnie kładzie laskę na jakość (skoro uważa że jej soft jest tak
podatny na błędy, że obawia się roszczeń gwarancyjnych, a wybrała
narzędzia i proces produkcji tylko dlatego że tanie i szybkie), upadnie.
Powiedziałbym że rynek wręcz na tym zyska.

>> A teraz poproszę argument merytoryczny, chyba że ci takiego brakuje.
>
> Merytoryczny argument jest bardzo prosty: software zawsze zawiera błędy.
> *ZAWSZE*. Dzięki furtce typu "ojej, odrysowalo mi się w zlym kolorze,
> ide oddać do sklepu tylko dokończe ten projekt samolotu" producenci
> dostana po dupie.

Nie dostaną. Twoim zdaniem można zwrócić pralkę sprzedawcy, bo się nie
spodobał kolor drzwiczek albo diody na wyświetlaczu? To dlaczego uważasz
że w oprogramowaniu nie byłoby zastosowania takiego terminu jak "istotna
wada, uniemożliwiająca lub utrudniająca używanie"?

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2011-07-14, Andrzej Jarzabek <a...@g...com> wrote:
> On 14/07/2011 08:52, Stachu 'Dozzie' K. wrote:
>> On 2011-07-13, Andrzej Jarzabek<a...@g...com> wrote:
>>> Żeby nękać, trzeba mieć patent. Żeby mieć patent, ktoś musi wynaleźć
>>> patentowalny wynalazek. To wynajdowanie to właśnie rozwój.
>>
>> Ktoś bodajże w Australii opatentował koło. Tak, ten patent służy
>> rozwojowi, bo gościu wynalazł przedmiot patentu.
>
> Przepraszam, ale nie będę teraz wyszukiwał informacji na temat prawa
> patentowego w Australii, żeby wykazać, że to jest bzdura, skoro tobie
> nawet się nie chce sprawdzić, czy to faktycznie było w Australii.

Chciało mi się sprawdzić. To było w Australii.
http://www.wprost.pl/ar/15998/Patent-na-kolo/

> Ale załóżmy nawet, że tak było. Czy to, że sąd w Korei Północnej skazał
> kogoś na śmierć na zbyt mało entuzjastyczne klaskanie Kimowi świadczy,
> że sądy i karanie przestępców to zły pomysł?

Nie. Ale pozwól że przypomnę cytat:
#v+
> Żeby mieć patent, ktoś musi wynaleźć
> patentowalny wynalazek. To wynajdowanie to właśnie rozwój.

Ktoś bodajże w Australii opatentował koło. Tak, ten patent służy
rozwojowi, bo gościu wynalazł przedmiot patentu.
#v-

Otóż bzdurą jest, że gościu (John Keogh, to be specific) wynalazł
przedmiot patentu. Udało mu się opatentować coś, co jest znane od bardzo
dawna.

>> Kilka przykładowych patentów służących rozwojowi:
>
> Masz jakąś tezę, bo nie chce mi się czytać całości tych wniosków? Jak
> dla mnie wyglądają na jakieśtam rzeczywiście innowacyjne i że wymyślanie
> tych rzeczy było faktycznie rozwojem oprogramowania, chociaż oczywiście
> nie jestem w stanie ocenić, czy patenty są ważne.

Nie to jest istotne czy są ważne, tylko to, w jaki sposób zabronienie
wszystkim innym producentom na rynku używania nazw dla zbiorów danych
miałoby pomagać rozwojowi oprogramowania? Bo ja tego nie widzę.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2011-07-14 22:43, Stachu 'Dozzie' K. wrote:
> Zupełnie nie odniosłeś się do przykładu. Schenker sprzedaje usługi
> logistyczne, nie oprogramowanie. Żeby zlecić im te usługi, używasz ich
> programu, który jest zepsuty. To nie usługom było coś do zarzucenia,
> tylko programowi.

Który stanowi 1% ich działalności. To tylko narzędzie. Dlaczego uważasz
że powinni o nie dbać i dopieszczać? Przecież ono nie jest celem samym w
sobie. Jesli działa wystarczająco to spełnia założenia, przeciez *nie*
ma alternatywy/konkurencji jak rozumiem, prawda? Monopol w małej skali
też jest szkodliwy, ale niewiele ma to wspólnego z gwarancją.

Co nie znaczy że uważam to za komfortową sytuację kiedy ktoś produkuje
g... z którym musze pracować. W przypadku mojego banku wyprodukowano
ajaksowe gówno które poza wytryskami zgubilo gdzieć funkcjonalność.
Tylko że stada tumanistów tego nie widzą i produkt został przygotowany
pod nich. Rynek wyoptymalizował rzeczy zbędne. No bo komu potrzebny
byłby eksport konta do XMLa poza paroma pryszczersami?

do góry

On 2011-07-14, Sebastian Biały <h...@p...onet.pl> wrote:
> On 2011-07-14 22:43, Stachu 'Dozzie' K. wrote:
>> Zupełnie nie odniosłeś się do przykładu. Schenker sprzedaje usługi
>> logistyczne, nie oprogramowanie. Żeby zlecić im te usługi, używasz ich
>> programu, który jest zepsuty. To nie usługom było coś do zarzucenia,
>> tylko programowi.
>
> Który stanowi 1% ich działalności. To tylko narzędzie. Dlaczego uważasz
> że powinni o nie dbać i dopieszczać?

Nie chodzi o to żeby je dopieszczać, tylko żeby je wytworzyć bez
poważniejszych błędów. Błąd wywracający aplikację dwa razy w tygodniu
i powodujący konieczność odtwarzania kopii zapasowej kwalifikuje się
jako poważniejszy.

> Przecież ono nie jest celem samym w
> sobie. Jesli działa wystarczająco to spełnia założenia, przeciez *nie*
> ma alternatywy/konkurencji jak rozumiem, prawda?

Alternatywne sposoby (sztuk jeden) są gorsze. Natomiast konkurencyjne
firmy spedycyjne miały prawdopodobnie słabsze oferty (cena, czas
transportu i inne tego typu). Nikt się nie interesował jakością
narzędzia, które Schenker przysłał, przy wybieraniu właśnie tej firmy.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 14/07/2011 13:02, Sebastian Biały wrote:
> On 2011-07-14 01:29, Andrzej Jarzabek wrote:
>> - Chciałbym napisać program, który wyświetla niebieski ekran.
>> - To pisz pan.
>> - Ale chciałbym go też sprzedawać za 50 tys. dolarów jako program
>> wyliczający wartość koszyków instrumentów finansowych 24 godziny na
>> dobę...
>
> To pytaj pan czy kupią, jak kupią to pisz. Jaki widzisz problem? Idziesz

Widzę problem taki, że ktoś zostaje przez kogoś nacięty na kasę.

> do firmy z ofertą a firma kupuje lub nie.

To tak samo jak ze sprzedawaniem kolumny Zygmunta: ktoś przedstawia
ofertę, a jeleń kupuje, lub nie.

> Jęsli w ofercie jest support
> to może sprzedasz tego więcej. Jesli w ofercie nie ma supportu to
> będziesz miał tańszy produkt i może jakieś biro maklerskie
> malinowski&córki się skusi.

No i ja nie widzę dlaczego biuro maklerskie malinowski&córki nie miałoby
mieć takiej ochrony prawnej jak nabywca czegokolwiek innego.

>>> Która blondynka z nk.pl ma świadomość SQ Injection i z tego powodu
>>> przestała go używać?
>> A która blondynka zapłaci choćby 100PLN żeby móc używać nk.pl?
>
> Wiele zapłaci w postaci durnych smsów, płatności kartą, wysylania
> prezentów, eurogabek i innych dupereli. Bedą to faktyczne pieniądze.
> Mają gwarancje?

Scenariusz, gdzie blondynka wydała 100PLN na rzeczy, które faktycznie
nie doszły wydaje mi się mało prawdopodobny - dla odróżnienia powiedzmy
od scenaiusza, kiedy blondynka wydała 100PLN, z czego nie doszły 2 SMSy
za 1,35PLN. W tej drugiej sytuacji straciła 1,35PLN a nie 100PLN i nie
ma się o co pyszczyć. W tej pierwszej - jak najbardziej uważam, że
powinna mieć prawo domagać się zwrotu tych 100PLN.

>> W świecie iRzeczy nabywców iRzeczy interesuje jakość iRrzeczy i to, że
>> jak iRzeczy przestaną chodzić, to będzie je można zwrócić do punktu
>> sprzedaży i tam je naprawią albo wymienią.
>
> iRzeczy składaja się z hardware (na które mamy stosowane przepisy) i
> software (na ktore nie mamy). Popsuje Ci się bateria - zwracasz. Popsuje
> Ci się jakis soft do słuchania hip-hopu w tramwaju - to mowisz ziomalom
> żeby nie kupowali. I już.

Po pierwsze, to osobiście nie miałem takiej sytuacji, ale jestem
jednakowoż raczej przekonany, że jak iPod przestanie odtwarzać MP3 albo
iPhone przestanie dzwonić, to można go oddać i w ramach gwarancji
naprawią ci albo wymienią niezależnie od tego, czy zepsuł się hardware,
czy to wina oprogramowania. Za to jestem absolutnie przekonany, że tego
właśnie oczekuje nabywca iRzeczy, i że go naprawdę nie obchodzi, czy to
sprzęt czy oprogramowanie zawiniło.

Stąd też właśnie producent iRzeczy, wychodząc naprzeciw nabywcom
iRzeczy, realizuje taki model, gdzie aplikacje third party są izolowane
od sprzętu i dodatkowo producent sprzętu może kontrolować, co jest na
nim instalowane. W ten sposób jest mało prawdopodobne, żeby dana
aplikacja zaburzyła działanie całego urządzenia, a nawet jak to się uda,
to Apple może ją wywalić z App Store i powiedzieć producentowi, że
dopóki nie naprawią, to nie będą jej mogli sprzedawać.

>> Jak mi się telewizor zepsuje, to też
>> mam się interesować, czy to wina kondensatora, opornika czy EPROMu?
>
> Bywa że to wina nie włożonej wtyczki do gniazdka. Czy w takiej sytuacji
> gwarant ma odpowiadać i mają mu zawracać dupę?

Uważam, że jak najbardziej, jak klient przychodzi do punktu serwisowego
lub do sprzedawcy, twierdząc że telewizor nie działa, to powinni mu tam
przynajmniej spróbować podłączyć do gniazdka i nacisnąć ON, a nie
spuszczać od razu ze schodów. Ty, jak rozumiem, uważasz, że w takiej
sytuacji powinni spuścić ze schodów bez sprawdzania?

> Przecież soft jest
> niesłychanie skompilowany. Ktoś będzie musiał się zainteresować czy to
> wina tego czy tamtego, czy reklamacja jest zasadnia, napisać tonę
> papieru, dzwonić czyli generować koszty bo klient odpalił software
> zapominając włożyc klucz sprzętowy do usb.

Jak się nie opłaca, to mogą mu po prostu zwrócić kasę.

>> Nieprawda. Ja otóż miewam często do czynienia z różnymi Kowalskimi,
>> którym jak najbardziej przeszkadza, jak coś nie działa albo źle działa.
>> _Zwłaszcza_ jeśli za to coś zapłacili pieniądze.
>
> To niech oddadzą Windowsa, Linuxa, Maca i zostana z samym hardware.

No ale czego chcesz dowieść? Że skoro bez softu będzie im gorzej, to
bugi nie przeszkadzają? Myślę, że z taką retoryką świetnie nadawałbyś
się na PRL-owskiego rzecznika rządu.

> Wolno przecież? Bo te produkty mają pierdyliard bugów, niektóre żyją
> sobie od kilku lat. Zwlaszcza że zapłacili za to pieniądze.

No i co? Dostaną z powrotem te pieniądze?

>> Żeby nękać, trzeba mieć patent. Żeby mieć patent, ktoś musi wynaleźć
>> patentowalny wynalazek. To wynajdowanie to właśnie rozwój.
>
> Zapomniałeś: żeby mieć patent trzeba mieć pieniądze.

To nie są jakieś wielkie kwoty. W porównaniu z ogólnym kosztem
doprowadzenia startupu do rentowności to są kompletne grosze.

> Zapomnialeś #2: każde rozbudowane oprogamowanie narusza kilkadziesiąt
> patentów. O wielu nawet nie słyszałeś. Ale nie martw się, trole obserwują.

Nie zapomniałem, tylko to po prostu nieprawda.

do góry

On 2011-07-14 22:44, Stachu 'Dozzie' K. wrote:
>> Czekaj, a kto decyduje o tym jaki jest niedostateczny?
> A w innych branżach? Jeśli się nie dogada sprzedający i kupujący,
> zostaje zaufana strona trzecia (np. sąd konsumencki).

I będzie analizował coredumpy lub bedzie miał ekspertow analizujących
coredumpy?

>> Dla mnie b) jest niedostateczny bo gdzie są do cholery pozostałe
>> rejestry i wersja zasilacza ?!?!? Reklamacja odrzucona!
> I w tym momencie pewnie UOKiK czy inny rzecznik praw konsumenta nakłada
> na ciebie karę, bo klient podał tyle, ile był w stanie.

ROTFL. Klient zazwyczaj nie podaje wszystkiego. Klient to zazwyczaj
idiota techniczny. Chcesz karać firmy za to że na podstawie pustych
technicznie opisów problemu nie sa w stanie usunąć rzeczywistych albo
wymyslonych problemów? Problem u klienta może być niepowtarzalny
gdziekolwiek indziej. Wystarczy że klient ma nietypowy hardware,
firewall, antywirus i twoj soft szlag trafia. Nie mozna tego
przetestować we wszystkich warunkach i co gorsza nie można mieć
identycznych środowisk jak klient bo jest ich za dużo.

> Natomiast
> odrzucenie a), jeśli to by był cały otrzymany opis, mogłoby być (choć
> nie musiało) zasadne.

*Kto* o tym decyduje co jest a co nie kompletne i zasadne?

>>> Oczywiście że nie. Ale widzisz, to już twoja wina że wybrałeś błędogenne
>>> narzędzia do wyprodukowania swojego softu.
>> Powiedz to tym którzy piszą soft przez kilkanaście lat. Nie przepisują -
>> piszą, dopisują i sprzedają *ciągle*. Powiedz że hello world można
>> przepisać w kilka minut na pythona to może niech przepiszą te swoje
>> prymitywne systemy finansowe nad ktorymi pracują 15 lat z
>> C/COBOLA/Pascala na coś lepszego. Pstryk i już. Python jest przecież
>> taki fajny.
> Bzdurzysz, gościu. Zaperzyłeś się. Może idź i się uspokój najpierw?

Czy ja wiem, widziałem juz kilku ludzi ze świetnymi radami co można by
zrobić żeby było lepiej. Rady jak to rady - słuszne w koncepcjach
podstawowych.

> Jak ktoś produkuje system finansowy od 15 lat, to przez ten czas już
> pewnie opracował standardy zapewniania jakości -- inaczej by się nie
> utrzymał na rynku.

I standardy te po 15 latach są dokladnie zbalansowane z potrzebami
klienta. Włącznie z tym ze producent i klient wie o jakis-tam problemach
które nie są krytyczne i można z nimi żyć.

> Ale jeśli sprzedają mi (firmie w której pracuję)
> system obiegu dokumentów, który nie wytrzymuje obciążenia *nastu nowych
> dokumentów dziennie i wywołuje OOM-killera na maszynie z 8GB RAM-u, to
> chyba mam prawo domagać się naprawy bądź zwrotu kosztów?

Oczywiście, przecież nie kupileś tego na półce w warzywniaku. Kupileś
ten system na umowę, a na pewno na niej zawarty jest support/serwis.
Dzień jak co dzień.

>>> I to wcale nie jest dobrze że tak wybrałeś, bo produkujesz z błędami,
>>> których dałoby się uniknąć.
>> Jasne. Właściwy język == zero błedów. Utopia.
> A kto ci nakłamał że zero? O_o

Twierdzisz że jakiś błedów mozna uniknąć w wyniku złego wyboru języka.
Ale wybor nastapił 15 lat temu, był wtedy najlepszy a dzisiaj masz
miliony lini kodu z czego 80% nie ma żadnej dokumentacji poza kodem.
Oczywiście, teoretycznie to jest źle, ale praktycznie to codzienność. To
*nie* jest pralka z dokumentacją na 30 stronach pojmowalną przez
przeciętnego elektryka.

> Dobór właściwego języka i właściwych narzędzi do niego pomaga
> *zmniejszyć* ilość błędów, a nie zlikwidować je całkowicie.

Dobór to sobie robisz *przed* a nie w trakcie. Niestety soft na rynku
zazwyczaj jest w trakcie. Malo kto ma komfort zaczynania na nowo.

> I naprawdę nie będę płakał, jeśli hipotetycznie twoja firma, która
> umyślnie kładzie laskę na jakość (skoro uważa że jej soft jest tak
> podatny na błędy, że obawia się roszczeń gwarancyjnych, a wybrała
> narzędzia i proces produkcji tylko dlatego że tanie i szybkie), upadnie.
> Powiedziałbym że rynek wręcz na tym zyska.

Uff ciekawy wniosek. Niestety codzienność jest odmienna, ale to moje
skromne obserwacje.

>> Merytoryczny argument jest bardzo prosty: software zawsze zawiera błędy.
>> *ZAWSZE*. Dzięki furtce typu "ojej, odrysowalo mi się w zlym kolorze,
>> ide oddać do sklepu tylko dokończe ten projekt samolotu" producenci
>> dostana po dupie.

> Nie dostaną. Twoim zdaniem można zwrócić pralkę sprzedawcy, bo się nie
> spodobał kolor drzwiczek albo diody na wyświetlaczu?

Tak. Niektórzy sprzedawcy uważają to za istotny punkt przyciągający
klientów. Niektórzy nie. Wolny rynek.

W zdaniu powyzej chodziło jednak o coś innego: *dowolna* wada
oprogramowania może stac się podstawą gwarancji. Dowolna pierdoła.
Wystarczy że klient uprze się że to jest super ważne. Może to zrobić
złosliwe lub z premedytacją. Bo przecież zawsze jakaś wada istnieje.

> To dlaczego uważasz
> że w oprogramowaniu nie byłoby zastosowania takiego terminu jak "istotna
> wada, uniemożliwiająca lub utrudniająca używanie"?

Nie działa przycisk do drukowania literek do gory nogami. To tylko
promil promila funkckonalności ale mi utrudnia używanie bo mam taki
kaprys. Poproszę o zwrot kasy lub usunięcie wady w 14 dni.

Czy możesz powiedzieć kto będzie decydował o istotności wady?

do góry

On 14/07/2011 13:29, Paweł Kierski wrote:
> W dniu 2011-07-13 13:42, Mariusz Kruk pisze:
> [...]
>>
>> Możliwe. Co wcale nie musi znaczyć, że całościowo dla społeczeństwa
>> będzie to gorszą sytuacją.
>> Przykład ekstremalny - brak regulacji na rynku broni skutkowałby
>> prawdopodobnie znacząco większą konkurencją i niższymi cenami broni niż
>> obecnie. Tylko czy chciałbyś żyć w takich warunkach?
>
> W sytuacji docelowej nie musiałoby być aż tak źle. Długofalowo
> prawdopodobnie zadziałała by strategia odstraszania - lepiej nie
> zaczepiać gościa i nie grozić mu bronią, bo on też pewnie ma broń.

Zupełnie jak w Somalii. Znajomy warlord radzi, żeby w takiej sytuacji
nie grozić, tylko od razu strzelać.

do góry

On 2011-07-14, Sebastian Biały <h...@p...onet.pl> wrote:
> On 2011-07-14 22:44, Stachu 'Dozzie' K. wrote:
>>> Czekaj, a kto decyduje o tym jaki jest niedostateczny?
>> A w innych branżach? Jeśli się nie dogada sprzedający i kupujący,
>> zostaje zaufana strona trzecia (np. sąd konsumencki).
>
> I będzie analizował coredumpy lub bedzie miał ekspertow analizujących
> coredumpy?

Na tych samych warunkach jak ma ekspertów-szewców analizujących but albo
ekspertów-mechaników samochodowych.

Akurat nie trzeba być programistą żeby widzieć że klient nie podał
podstawowych informacji niezbędnych do diagnozowania problemu (na
przykład nie podał kiedy błąd występuje czy jak go odtworzyć), albo że
podał tyle ile było w jego możliwościach.

>>> Dla mnie b) jest niedostateczny bo gdzie są do cholery pozostałe
>>> rejestry i wersja zasilacza ?!?!? Reklamacja odrzucona!
>> I w tym momencie pewnie UOKiK czy inny rzecznik praw konsumenta nakłada
>> na ciebie karę, bo klient podał tyle, ile był w stanie.
>
> ROTFL. Klient zazwyczaj nie podaje wszystkiego. Klient to zazwyczaj
> idiota techniczny. Chcesz karać firmy za to że na podstawie pustych
> technicznie opisów problemu nie sa w stanie usunąć rzeczywistych albo
> wymyslonych problemów?

Na razie poważnym firmom się to udaje. Jeśli klient podał za mało
danych, wsparcie techniczne dopytuje się o pozostałe.

> Problem u klienta może być niepowtarzalny
> gdziekolwiek indziej. Wystarczy że klient ma nietypowy hardware,
> firewall, antywirus i twoj soft szlag trafia. Nie mozna tego
> przetestować we wszystkich warunkach i co gorsza nie można mieć
> identycznych środowisk jak klient bo jest ich za dużo.

I wtedy oddajesz klientowi pieniądze, skoro mu twój soft nie działa.
Niby z jakiej okazji klient ma płacić za twój soft, skoro nie jest
w stanie go używać?

>> Natomiast
>> odrzucenie a), jeśli to by był cały otrzymany opis, mogłoby być (choć
>> nie musiało) zasadne.
>
> *Kto* o tym decyduje co jest a co nie kompletne i zasadne?

Próbujesz stworzyć problem tam gdzie go nie ma, gdy się przejdzie do
innej branży, na przykład samochodowej.

>>>> Oczywiście że nie. Ale widzisz, to już twoja wina że wybrałeś błędogenne
>>>> narzędzia do wyprodukowania swojego softu.
>>> Powiedz to tym którzy piszą soft przez kilkanaście lat. Nie przepisują -
>>> piszą, dopisują i sprzedają *ciągle*. Powiedz że hello world można
>>> przepisać w kilka minut na pythona to może niech przepiszą te swoje
>>> prymitywne systemy finansowe nad ktorymi pracują 15 lat z
>>> C/COBOLA/Pascala na coś lepszego. Pstryk i już. Python jest przecież
>>> taki fajny.
>> Bzdurzysz, gościu. Zaperzyłeś się. Może idź i się uspokój najpierw?
>
> Czy ja wiem, widziałem juz kilku ludzi ze świetnymi radami co można by
> zrobić żeby było lepiej. Rady jak to rady - słuszne w koncepcjach
> podstawowych.

Tylko na razie wyjmujesz coraz bardziej wydumane przypadki jako
argumenty, podczas gdy w ogóle nie próbujesz obalić (ani w inny sposób
się odnieść) analogii z innymi branżami usługowo-przemysłowymi, które
zostały podane.

>> Jak ktoś produkuje system finansowy od 15 lat, to przez ten czas już
>> pewnie opracował standardy zapewniania jakości -- inaczej by się nie
>> utrzymał na rynku.
>
> I standardy te po 15 latach są dokladnie zbalansowane z potrzebami
> klienta. Włącznie z tym ze producent i klient wie o jakis-tam problemach
> które nie są krytyczne i można z nimi żyć.

Ale tylko dlatego że to branża finansowa, że soft przetwarza bardzo
ważne dane i może spowodować znaczne straty oraz że klient z producentem
ma starannie przygotowaną umowę. A my tu mówimy o możliwości odzyskania
pieniędzy przez Kowalskiego, który ma serdecznie w dupie czy to ATI się
opiera przed naprawieniem sterowników karty graficznej, czy to jednak CD
Projekt zjebał grę. Kowalskiemu Wiedźmin nie chodzi, więc Kowalskiemu ta
gra niepotrzebna, chce ją oddać i chce z powrotem wydane na nią
pieniądze. Pójdzie za nie na piwo.

>> Ale jeśli sprzedają mi (firmie w której pracuję)
>> system obiegu dokumentów, który nie wytrzymuje obciążenia *nastu nowych
>> dokumentów dziennie i wywołuje OOM-killera na maszynie z 8GB RAM-u, to
>> chyba mam prawo domagać się naprawy bądź zwrotu kosztów?
>
> Oczywiście, przecież nie kupileś tego na półce w warzywniaku. Kupileś
> ten system na umowę, a na pewno na niej zawarty jest support/serwis.
> Dzień jak co dzień.

No chyba że jednak ten system jest kupiony właśnie w "warzywniaku",
czyli w sklepie komputerowym. Czyli chcę moje pieniądze z powrotem.

>>>> I to wcale nie jest dobrze że tak wybrałeś, bo produkujesz z błędami,
>>>> których dałoby się uniknąć.
>>> Jasne. Właściwy język == zero błedów. Utopia.
>> A kto ci nakłamał że zero? O_o
>
> Twierdzisz że jakiś błedów mozna uniknąć w wyniku złego wyboru języka.
> Ale wybor nastapił 15 lat temu, był wtedy najlepszy a dzisiaj masz
> miliony lini kodu z czego 80% nie ma żadnej dokumentacji poza kodem.
> Oczywiście, teoretycznie to jest źle, ale praktycznie to codzienność. To
> *nie* jest pralka z dokumentacją na 30 stronach pojmowalną przez
> przeciętnego elektryka.

(W tym akapicie na potrzeby argumentacji zakładam że jesteś autorem
takiego piętnastoletniego systemu; nie ma to absolutnie związku z tym,
czy uważam że rzeczywiście masz coś takiego na koncie.)

Trudno. Za błędy młodości też trzeba czasem płacić. Ja doskonale
rozumiem że chcesz uniknąć odpowiedzialności za taki piętnastoletni
system, gdzie wprowadzenie jakiejś poprawki może się skończyć
tragicznie; też bym chciał będąc na twoim miejscu, bo to jak chodzenie
po polu minowym. Choć być może wypracowałeś przez te piętnaście lat
metody wyłapywania błędów, przez co twój program jednak ma dość wysoką,
wypróbowaną jakość; wtedy raczej zgłoszeń reklamacyjnych się nie musisz
obawiać, bo nie będą występować.

>> Dobór właściwego języka i właściwych narzędzi do niego pomaga
>> *zmniejszyć* ilość błędów, a nie zlikwidować je całkowicie.
>
> Dobór to sobie robisz *przed* a nie w trakcie. Niestety soft na rynku
> zazwyczaj jest w trakcie. Malo kto ma komfort zaczynania na nowo.

Trochę kiepski argument żeby się wymigać od podniesienia jakości
kiepskiego softu. Jeśli jest kiepski na tyle że producent się obawia
reklamacji, tzn. producent nie ma pewności że jego program będzie
działać, to znaczy że należy ten program przepisać tak, żeby pewność
dawał.

>> I naprawdę nie będę płakał, jeśli hipotetycznie twoja firma, która
>> umyślnie kładzie laskę na jakość (skoro uważa że jej soft jest tak
>> podatny na błędy, że obawia się roszczeń gwarancyjnych, a wybrała
>> narzędzia i proces produkcji tylko dlatego że tanie i szybkie), upadnie.
>> Powiedziałbym że rynek wręcz na tym zyska.
>
> Uff ciekawy wniosek. Niestety codzienność jest odmienna, ale to moje
> skromne obserwacje.

Aj, widzisz. Obserwacja codzienności wcale nie ma obowiązku się zgadzać
ze spekulacjami zakładającymi upadek rozważanej hipotetycznej firmy,
niezależnie od tego czego zgodność miałaby dotyczyć (bo nie rozumiem
do którego fragmentu się odnosi twój komentarz).

>>> Merytoryczny argument jest bardzo prosty: software zawsze zawiera błędy.
>>> *ZAWSZE*. Dzięki furtce typu "ojej, odrysowalo mi się w zlym kolorze,
>>> ide oddać do sklepu tylko dokończe ten projekt samolotu" producenci
>>> dostana po dupie.
>
>> Nie dostaną. Twoim zdaniem można zwrócić pralkę sprzedawcy, bo się nie
>> spodobał kolor drzwiczek albo diody na wyświetlaczu?
>
> Tak. Niektórzy sprzedawcy uważają to za istotny punkt przyciągający
> klientów. Niektórzy nie. Wolny rynek.

Ale sprzedawca nie ma obowiązku przyjąć takiego zwrotu. To jest istotne.

Ty jako dostawca softu nie masz (nie miałbyś) obowiązku przyjąć zwrotu
programu li tylko na podstawie niepodobającego się koloru menu.

> W zdaniu powyzej chodziło jednak o coś innego: *dowolna* wada
> oprogramowania może stac się podstawą gwarancji. Dowolna pierdoła.

Tylko musi to być wadą. A jeśli ta wada jest _pierdołą_, to na ogół da
się ją naprawić w parę chwil.

>> To dlaczego uważasz
>> że w oprogramowaniu nie byłoby zastosowania takiego terminu jak "istotna
>> wada, uniemożliwiająca lub utrudniająca używanie"?
>
> Nie działa przycisk do drukowania literek do gory nogami. To tylko
> promil promila funkckonalności ale mi utrudnia używanie bo mam taki
> kaprys. Poproszę o zwrot kasy lub usunięcie wady w 14 dni.
>
> Czy możesz powiedzieć kto będzie decydował o istotności wady?

"A był kiedyś taki przycisk? Nie było? To jaka to niby wada? Do widzenia
Panu."

--
Secunia non olet.
Stanislaw Klekot

do góry