On Fri, 2005-10-14 at 17:35 +0200, Daniel Mróz wrote: > Wysoki stopien "wkurzalnosci" komunikatu nie implikuje jego bezuzytecznosci.
Zgoda. Co innego jeśli wkurzenie jest jedynym efektem komunikatu (bo nie niesie on użytecznej informacji). W przypadku dowiedzenia się po raz n-ty, że program jest betą, IMO zachodzi taki przypadek. Podobna dyskusja była w przypadku bannerów %post. Tam stanęło na tym, że użyteczność pierwszego wystąpienia informacji o czymkolwiek jest dyskusyjna, ale od drugiego razu wzwyż informacja jest zbędna. > Jesli program jest produktem beta, moze > posiadac > drobne bledy, o ktorych nie trzeba uzytkownika informowac za kazdym > razem kiedy wystapia. Przesledz sobie np. uruchamianie programow z KDE. > Wywalaja tam mnostwo komunikatow, z czego kilka jest typu "Nie moge > otworzyc pliku X". Plik X nie jest wymagany do poprawnego dzialania > aplikacji, Jeśli plik powinien gdzieś być (powinien w sensie rpm -V), to chciałbym o tym że go nie ma wiedzieć (i naprawić albo kogoś opieprzyć). Nawet zadowolił bym się ubiciem programu na pierwszym nieznalezionym pliku, chociaż w tej kwestii oczywiście YMMV. Ale jeśli plik jest opcjonalny, to informacji "gdybyś miał /etc/foorc, to bym z niego skorzystał, a tak to korzystam z /etc/barrc" szukałbym w dokumentacji, a nie na konsoli. Analogia z bannerami jest aż nadto wyraźna. > ale dla ktoregos uzytkownika akurat moze byc to wazne (bo ma > taki plik, tylko np. w innym miejscu niz sie tego spodziewa aplikacja). Taki człowiek (który trzyma pliki w niestandardowych miejscach) pewnie szybciej odpali `strace...|grep ENOENT` niż spojrzy na jakikolwiek komunikat albo dokumentację. > > Informacja że to beta ma sens w description i/lub dokumentacji, nie przy > > każdym starcie. > Nie miala by zadnego sensu jesli bylaby wyswietlana w postaci okienka. > Jesli jest to komunikat na konsoli to nie widze zadnych przeciwskazan. A jakie widzisz zawskazania? Wątek zaczął się od tego, że userzy abrama właśnie przeciwskazania zobaczyli. > Powtarzam jeszcze raz: jesli Ci to przeszkadza, to mozesz sobie > przekierowac stderr i stdout do /dev/null i masz problem z glowy. Niepotrzebnie. Ja sobie tak czy inaczej poradzę. Chodzi o to jak być powinno. > >>Nie, konsola jest zawsze miejscem do wyrzucania bledow, nawet > >>jednoczesnie ze stosownym okienkiem > > Przeczytaj w http://www.faqs.org/docs/artu/ nt. "Rule of silence". > Ech. Jest tez kilka dokumentow i ksiazek, w ktorych jest napisane aby > komunikaty wrzucac na konsole. To co? Zaczynamy sie scigac na ilosc? ;) Na jakość, Raymond raczej pisuje rzeczy przemyślane. gcc nie krzyczy o błędach kompilacji na /dev/dsp0; fsck niepodpiętych inodeów nie raportuje na /dev/lp0; python nie ogłasza SyntaxError na forum Onetu. Program niekonsolowy nie ma żadnego interesu w pluciu na stdout. Informacja powinna być udostępniana jeśli jest (ew. może być) użyteczna, a przede wszystkim tam, gdzie jej udostępnienie będzie (ew. może być) użyteczne. > Od tylu lat nie slyszalem zeby ktos sie > na to skarzyl, a Ty chcesz wszystko zmieniac, bo Tobie nie pasuje. Sprostowanie: nie tylko mi, nie ja zacząłem ten wątek. > To > jest akurat przydatny ficzer i jak widac stosowany przez wiekszosc > programistow. "Większość" to argument z serii ścigania się na ilość, do tego trudny do obronienia. Nie zdarzyło mi się, żeby galeon& wypisywał coś na konsoli. xmms& też nie. pysol& też nie. Te programy informacje o problemach wypisują tam gdzie powinno (wg mojego osobistego rozumienia "powinny"). Nie wątpię, że jesteś w stanie podać kontrprzykłady. To, że jacyś programiści (czy ich jest 1% czy 99%) coś praktykuje, nie znaczy że jest to słuszne. -- Paweł Sakowski <[EMAIL PROTECTED]> PLD Linux Distribution _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
