Paweł Sakowski napisał(a): >>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. No wlasnie, nie jest na tyle wazny zeby usera o tym powiadamiac natychmiast (w postaci okienka), wiec sobie pisze na stderr. Jak user bedzie chcial sobie obejrzec komunikaty, to sobie odpali spod konsoli. Nadal nie rozumiem dlaczego Wam to przeszkadza.
> 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. To jest troche inna bajka. > 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. I po kazdej aktualizacji aplikacji okienkowej mam przeczesywac dokumentacje w poszukiwaniu informacji czy przypadkiem sie cos nie pozmienialo w plikach? Przelicz sobie z grubsza ile czasu zajmie Ci przeszukanie dokumentacji, a ile uruchomienie programu na konsoli i obejrzenie komunikatow startowych. >>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ę. Daj spokoj. Nie znasz wszystkich uzytkownikow. >>>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. No to niech sobie abram przekieruje stderr/stdout do /dev/null. Ludzie, przeciez po to sa te przekierowania wyjsc. Jesli abram sobie nie moze poradzic z tak trywialna rzecza, to jest jego problem. Modyfikowanie aplikacji dystrybucyjnych z tego powodu jest conajmniej glupie, tym bardziej, ze wiele osob z tego korzysta. >>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. Powinno byc tak jak jest. > 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. Przeciez jest udostepniona. Standardowo jej nie widac, ale wiadomo gdzie jest i jak sie do niej dostac w razie potrzeby. >>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. No to jest dwoch adminow, bo userow nie licze (maja prawo nie wiedziec jak sobie poradzic z czyms takim). Jak dla mnie to za malo zeby zmieniac wszystkie programy okienkowe. > To, że jacyś programiści (czy ich jest 1% czy 99%) coś praktykuje, nie > znaczy że jest to słuszne. To, ze dwoch adminow mysli, ze cos jest zle, nie znaczy ze jest to sluszne. Z mojej strony EOT, bo to nie ma sensu. Mam nadzieje, ze jesli zaczniecie zmieniac dystrybucyjne aplikacje, to ktos Was powstrzyma. Pozdrawiam Beorn _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
