Forum stowarzyszenia „Trioda” - nowy serwer

A ja kiedyś kupiłem kontroler SATA RAID f-my Mint, w którym nie było możliwości wejścia w setup, czyli skonfigurowania RAIDa. Sklep zwrot przyjął, skończyło się na wymianie na Adapteca, który chodzi bezproblemowo już około 5 lat.
Z doświadczenia zawodowego - w jednym z modeli telewizorów Telestar 28" w zasilaczu był wkładany bezpiecznik 2A (powinien być 3,15A). Przy normalnej pracy TV wystarczał, ale przy podłączaniu do sieci (lub włączeniu wyłącznikiem sieciowym) pętla rozmagnesowująca powodowała rozżarzanie się bezpiecznika. Jak ktoś często wyłączał telewizor z prądu (np. na noc) to bezpiecznik padał po kilku miesiącach w okresie gwarancji. Ale jak ktoś zostawiał sprzęt większość czasu na stanby wówczas za wymianę musiał zapłacić.

jethrotull pisze: Akurat przez pewien czas pracowałem w IBMie i wiem, że jest to firma, która nie zawaha się opóźnić releasu o rok (co oznacza straty milionów $ na samych pensjach, o konkurencyjności rynkowej nie wspominając) żeby dostarczyć produkt o właściwej jakości. Czy program nadal się "wysypuje"? owszem. Jednak każdym błędem *natychmiast* się zajmują inżynierowie supportu, którzy mają określony czas na poprawienie go (a w dodatku, w zgodzie z polityką firmy, robią znacznie więcej niż to, np. dodają za darmo nowe featury na życzenie klienta).


Jeśli chodzi o rzekomy "przykład" dotyczący praktyk kontrolowania jakości który rzekomo "idzie" z Microsoftu, to zapewniam Cię że jest to całkowicie chybiona diagnoza.

Rozumiem bardzo szczególny przypadek. Ale to co podałem to powszechnie używana operacja na dużych tablicach. Wpadka polegająca na utracie danych bez zasygnalizowania problemu to poważny cios na wiarygodności firmy oferującej produkty na zupełnie innej niszy (na razie niedostępnej jeszcze dla M$). Job REORG'iem się wykonał bezbłędnie. A potem po pewnym czasie wychodzi na jaw że w jakichś danych brakuje? Co innego jakby zakrzyczał że coś mu się stało.... Wtedy wiadomo - odtwarzanie danych albo cofnięcie pilotażu. Sorry ale taka wpadka to naprawdę poważna utrata zaufania dla produktów na tę klasę sprzętu i oprogramowania.

Niestety tak lekceważące podejście do klientów wprowadziła firma Microsoft. Niestety skuteczne jeśli do historii przeszły firmy/marki: Sun, Digital, Informix, ICL....

To nie żadne lekceważenie, zwykły "bug" się trafił, jakże łatwy do popełnienia, tym bardziej w niskopoziomowym języku programowania. Musisz jednak wiedzieć, że w firmie takiej jak IBM (inne korporacje mają podobnie) na testowanie przeznacza się o rząd wielkości więcej czasu niż na samo programowanie. Do tego dochodzi ogromny wysiłek służący stworzeniu procesu który wspierałby jakość (w tym przypadku: słynny RUP, wykorzystywany zresztą z sukcesem nie tylko w inżynierii oprogramowania).
Nie szafowałbym stwierdzeniami, że jakiś defekt powstał dlatego, że ktoś coś zlekceważył, nie dopilnował, itp. Wiem z własnego doświadczenia, jak drobne ale paskudne błędy potrafią się prześlizgnąć przez nawet bardzo rozbudowaną i zformalizowaną procedurę kontroli jakości. Tworzenie oprogramowania jest bardzo młodą dziedziną inżynierii, niestety czasem musimy się uczyć na błędach. Z drugiej strony, jeśli zaproponujesz klientowi alternatywę w postaci nowoczesnej acz niedopracowanej technologii albo przestarzałej ale bardziej stabilnej, to 99% wybierze to pierwsze. Dla klientów (analogicznie jak i producentów) oprogramowania, straty wynikające z nie używania (wypuszczania na rynek) technologii przestarzałej znacznie przewyższają ewentualne straty wynikające z defektów. Nie odważyłbym się twierdzić, że jest to tendencja negatywna, mimo wszystko napędza ona skutecznie postęp techniczny.

jethrotull pisze:To nie żadne lekceważenie, zwykły "bug" się trafił, jakże łatwy do popełnienia, tym bardziej w niskopoziomowym języku programowania.

Tego produktu nie pisano w niskopoziomowym języku programowania.

jethrotull pisze:
Nie szafowałbym stwierdzeniami, że jakiś defekt powstał dlatego, że ktoś coś zlekceważył, nie dopilnował, itp. Wiem z własnego doświadczenia, jak drobne ale paskudne błędy potrafią się prześlizgnąć przez nawet bardzo rozbudowaną i zformalizowaną procedurę kontroli jakości. Tworzenie oprogramowania jest bardzo młodą dziedziną inżynierii, niestety czasem musimy się uczyć na błędach.

Czyli uważasz za OK że nie sprawdzono jednej z często używanej funkcji administracyjnej produktu?
Duża tablica - Ok, ale opisywany produkt nie jest adresowany do niewielkich baz danych. To nie MS SQL, Interbase, MySQL, Postgres itd...

STUDI pisze: Tego produktu nie pisano w niskopoziomowym języku programowania.

Silników bazy danych nie pisze się w językach wysokopoziomowych. C np. nie jest językiem wysokopoziomowym.

Czyli uważasz za OK że nie sprawdzono jednej z często używanej funkcji administracyjnej produktu?

Nie wiem, nie znam szczegółów technicznych, wiem tyle co mi opisałeś, a z tego wynika, że błąd jest raczej trudny do wykrycia. Za to wiem jak wygląda quality assurance w korporacji. Jakby to był trywialny błąd to by nie przeszedł. Może zresztą się zdarzają wypadki że ktoś coś oleje i w wyniku tego jakiś "głupi" błąd się prześlizgnie, ale na pewno nie jest to zjawisko masowe, ani, jak sugerujesz, napędzane polityką firmy.
Oczywiście, błąd o którym piszesz tak czy owak nie jest powodem do radości, ale proponuję jednak spojrzeć na to wszystko z pewnej perspektywy.

jethrotull pisze: Silników bazy danych nie pisze się w językach wysokopoziomowych. C np. nie jest językiem wysokopoziomowym.

Kwestia definicji - kod maszynowy, assembler, pseudokod itp to są dla mnie języki niskopoziomowe.

jethrotull pisze: Nie wiem, nie znam szczegółów technicznych, wiem tyle co mi opisałeś, a z tego wynika, że błąd jest raczej trudny do wykrycia.

Czy trudny? Wykonanie kopii obszaru (np. mając do dyspozycji macierz z flashcopy), wykonanie reorga i porównanie zawartości tablic.
Jeśli użytkownik ma zaufanie do produktu a operacja nie sygnalizuje problemów to w przypadku dużych tablic z danymi archiwalnymi wykrycie braku może zająć nieco czasu.

jethrotull pisze: Oczywiście, błąd o którym piszesz tak czy owak nie jest powodem do radości, ale proponuję jednak spojrzeć na to wszystko z pewnej perspektywy.

Tyle ze jeszcze niedawno produkty tej firmy przynajmniej na mainframe cechowały się wysoką jakością kodu. Niestety obecnie jest coraz gorzej. Choćby z tego powodu przejście na nowszą (i nie najnowszą!!!!) wersję motoru DB2 jest nadal odwlekane od ponad dwóch lat z racji iż nie ma zaufania co jego funkcjonowania - i to pomimo iż kolejna wersja ma pożądane nowe features co pozwoliłoby na wyłaczenie innych technologii jako obejść.

Aby nie przeciągać mówiłem o operacji wręcz podstawowej i wykonywanej praktycznie co tydzień lub w trakcie znacznych modyfikacji danych. Decyduje ona nie tylko wydajności ale też często o możliwości dopisania jakiegokolwiek nowego rekordu (dlaczego - wystarczy się zaznajomić z systemem plików na mainframe'ach....).

Ja wszystko rozumiem, natomiast nie zgadzam się z konstatacją jakoby problem z jakimś tam Starym Żelastwem był spowodowany tym, że IBM (na poziomie organizacji, polityki itp., nie mówię o tym że jakiś programista miał kaca, a testerowi akurat się kawa na klawiaturę rozlała itp.) olewa sobie jakość. Wręcz przeciwnie - jakość jest tam religią. Powód prozaiczny: pieniądze. Myślę, że nie zdradzę żadnej tajemnicy handlowej, jeśli powiem, że umowy supportowe są konstruowane w taki sposób, że najbłahszy błąd (typu literówka) oznacza tydzień pracy dwóch osób (nie liczę managerów, adminów itp). Grubszy błąd, którym klient jest bardzo rozsierdzony, oznacza stratę rzędu setek tysięcy $.

Nawet jeśli stwierdzisz (na podstawie jakiegoś tam buga w jakimś tam jednym produkcie) że jakość produktów się systematycznie obniża, to na pewno nie jest tak dlatego, że ktoś świadomie odpuszcza sobie jakość za cenę szybszego releasu. To jest zwyczajnie nieprawda.

A ja wrócę do tematu mojego dysku, Samsung wymienił mi go, na gorszy model
I znowu muszę czekać ponad 2tyg. bo nie zgodziłem się na taką opcję.

Z serii "Auto-Elektro": swego czasu spaliła mi się żarówka prawego światła mijania (typu H1), a że zapasową parę tygodni wcześniej poratowałem kumpla, musiałem udać się na zakupy. Po drodze był hipermarket OBI, gdzie trafiłem na żarówki ichniej marki w cenie 4,99zł/szt. Pełen radości zakupiłem trzy egzemplarze... Po dwóch dniach padła pierwsza, po kolejnych trzech druga. Trzecia wystraszyła się chyba puszczonej przeze mnie wiązanki, albowiem działa już od blisko dwóch miesięcy.

Żeby było śmieszniej, żarówki wcale się nie przepaliły; włókno było sprawne - nastąpiło odspojenie się "gorącego" wyprowadzenia od konektora z powodu marnego zgrzewu. Paragon, jak to zwykle bywa, wywaliłem...

Młody Technik nr 1/1983, artykuł "Elektronika w służbie wywiadu": Zapewne w HP nawet nie wiedzieli jacy są zdolni...

Oscyloskop C1-107: fabrycznie brak 2 układów scalonych, są na schemacie, są miejsca na płycie, nie ma śladów po układach - cała płyta razem z elementami pociągnięta jest lakierem i byłoby widać gdyby coś tam wcześniej było i zostało usunięte.
Oprócz tego brak co najmniej jednego "transformatorka" a dwa inne są tylko przyklejone ale nigdzie nie przylutowane, a dziwiłem się że multimetr oscyloskopu od nowości nie działa.

Czołem.

- Elizabeth HiPhi, w której nie wlutowano jednego z tranzystorów w stabilizatorze zasilania. Napięcie było mocno za duże i szybko padły końcówki (GML, obie jednocześnie).
- Bateryjka płaska z tak długimi blaszkami, że były zwarte. Oczywiście zalepione papierkiem, by kontakt był pewniejszy.

Pozdrawiam,
Jasiu

carlos pisze:..................
Paragon, jak to zwykle bywa, wywaliłem...

Syn rozstał się z pewną renomowaną uczelnią ładnych kilka lat temu.
Przetrzymał książkę z wypożyczalni.
Po chyba 2 latach został upomniany.
Oddał książkę zapłacił karę i tak jak ty paragon tak on wywalił kwit.
W następnym roku wypożyczalnia upomniała się o karę.
Zapłacił powtórnie ale przezornie kwitu już nie wyrzucił.
Od tej pory wypożyczalnia co roku upomina się o zapłacenie kary.
Chodzi o bagatela 451PLN.
W tym roku zapowiedzieliśmy im sprawę o nękanie.

Witam.
Byłem jeszcze nastolatkiem (końcówka lat 70.) jak kupiłem bardzo wysokiej, jak na tamte czasy, klasy tuner STEREO "KLEOPATRA". Do tunera dołączona została przez producenta specjalna indywidualna karta pomierzonych rzekomo parametrów. Czułość odbiornika dla odbioru stereofonicznego 1,9 uV, dla mono 0,7 uV. Coś mi się z tą czułością nie podobało, więc, pomimo posiadania karty gwarancyjnej, otworzyłem tuner i zauważyłem, że jedno z symetrycznych wejść głowicy UKF (300 omów, przystosowane dla kabla płaskiego) zostało na płytce drukowanej zalane grubą warstwą cyny z masą (stuprocentowe zwarcie). Na wejściu głowicy znajdowała się cewka, której uzwojenie antenowe posiadało na środku odczep, również podłączony był do masy (tu akurat poprawnie). Od tamtego momentu przestałem wierzyć w rzetelność krajowych producentów i podawane przez nich parametry techniczne sprzętu. Dodatkowo tuner miał fatalnie zaprojektowane prowadzenie mas, co powodowało, że poziom przydźwięku w sygnale audio był bardzo wysoki. Na szczęście udało mi się zaekranować transformator sieciowy, przeciąć i inaczej poprowadzić kilka mas, przez co poziom zakłóceń sprowadziłem do akceptowalnej dla mnie wartości.

Pozdrawiam,
Romek

Gdzieś w połowie lat 80-tych mój tata kupił (cudem, spod lady!) słuchawki Tonsil Sd-501. Podczas grania dźwięk był przerywany. Na okoliczność puszczenia lutów sprawdzone zostały wtyczka i koniec kabla z drugiej strony - w muszlach. Luty były w porządku. Obmacywanie kabla wykazało że to on jest przyczyną. Po zdjęciu izolacji okazało się że w środku jest dosłownie sieczka. Miedziane żyły były posiekane jak szczypiorek do twarożku na śniadanie - na całej długości przewodu.