Má vůbec smysl reportovat někam chyby?

[Martin Sivák]

Tak samo aplikace typu IntelliJ apod., když mají crash, tak ty můžeš reportovat chybu. Další reportování chyb je přes OS, ale to nevím, jak funguje - jako vývojář potřebuju vidět logy z mojí aplikace, a ne nějaký memory dump, to ať si strčí dopr. Nevím, jak se tohle na úrovní OS řeší a co to všechno umí poslat vývojáři.

A jestli tam vůbec Linuxové distribuce pro tohle reportování mají nějaké zázemí, a nebo to umí reportovat velké hov*, žádné logy, nic. Nevšiml jsem si nikdy v Linuxu, že bych zaškrtvával "Souhlasím že budete odesílat informace o chybách".

Jako vývojář mám raději coredump nebo stacktrace (stav aplikace v době pádu) i logy (uživatelské akce vedoucí k pádu).

A samozřejmě na to systém existuje. Jak systemd coredump handler, který ty dumpy ukládá (https://github.com/systemd/systemd/blob/main/docs/COREDUMP.md), tak násedná podpora pro reportování bugů třeba ve Fedoře (ABRT a https://fedoramagazine.org/file-better-bugs-coredumpctl/).

KDE pak má třeba svůj vlastní: https://invent.kde.org/plasma/drkonqi

A v neposlední řadě - zálohování. ALe protože nemá Linux něco jako inkementální zálohovací systém, tak si to musíš udělat sám, ...

Hmm.. a co je DejaDup v Gnome (https://apps.gnome.org/cs/DejaDup/) nebo třeba Borg s Vorta kdekoliv (https://vorta.borgbase.com/), případně pro powerusery restic a resticprofile (https://creativeprojects.github.io/resticprofile/).

[Reklama]

[Ondrej Nemecek]

...

To jsou dost nepřesné informace, co píšete, nelze to psát takto obecně. Inkrementální zálohování, automatický bug reporting apod. - i v opensource světě na toto jsou nástroje, ale hlavně záleží na každém projektu nebo distribuci, jak danou věc řeší, jak komunikuje a jaký má mechanismus na opravu chyb. Software je dnes zabugovaný plošně (closed source i opensource) a situace je nepřehledná, s tím se dá jedině souhlasit. Ale můžete se s tím smířit, přiložit ruku k dílu anebo se odsunout do nějaké niky, kde je situace přehlednější třeba https://suckless.org/ 

BTW Místo rsync můžete použít rdiff-backup, skvělá nadstavba. Anebo nějaký z nástrojů postavený na snapshotech viz níže. Na automatické reporty je ABRT, Apport... a světe div se, tyto nástroje se ptají co všechno chcete v rámci bugreportu z počítače odeslat.

https://rdiff-backup.net/
https://github.com/linuxmint/timeshift
http://snapper.io/
https://borgbackup.readthedocs.io/en/stable/
https://www.bacula.org/
https://www.baeldung.com/linux/automatic-bug-reporting-tool-abrt

[Ondrej Nemecek]

Když to shrnu, tak software je prostě dnes moc složitý a provázaný a opravují se jen chyby, které jsou kritické a které postihují plošně příliš mnoho uživatelů. Na nic jiného není kapacita. Týká se to i komerčního software. Čím větší projekt, tím větší smršť chyb, které je potřeba analyzovat, zjistit zda jsou reprodukovatelná a zda se vůbec týkají příslušného software případně zda jde o chyby nebo features. Proto má každý větší projekt bug reporting guidelines, aby byla správa chyb vůbec zvládnutelná. Ale ne vždy se to daří. O to větší čest patří vyjímkám:

Více než desetiletou práci zakončil Knuth v roce 1990 (...) poté vyhlásil vývoj TEXu za dokončený a vrátil se k práci na The Art of Computer Programming. K TEXu se vrací jednou za rok, aby opravil chyby, pokud byly během uplynulého roku nějaké nalezeny. Při každé takové opravě přidá jednu číslici k verzi (...) Odměna vypsanáAmerickou Matematickou Asociací za nalezení další chyby je 327,68 dolarů.

https://www.root.cz/clanky/co-prichazi-s-texem/

Ale i dnes existují stabilně udržované projekty, které mohou sloužit jako etalon kvality, napadá mě třeba PostgreSQL  (tímto zdravím Pavla Stěhule). Spadá tam IMHO i linux kernel a zrovna reakce na bugzilla.kernel.org, kterou celé téma začalo, mi přijde dost vstřícná, doporučuju tu opravu dotáhnout. Jen je potřeba počítat s tím, že to zabere čas a úsilí.