Jaderné noviny - 3. 9. 2008 (diskuse)

[YYY]

Cislovani verzi jadra by imho bylo nejlepsi ponechat tak, jak je. Celkem mi, u pro mne klicovych veci, nedela problemy pamatovat si, od jake verze kernelu je to podporovano.

[kavol]

problém je, když si člověk musí pamatovat také do jaké verze je to podporováno ...

třeba ta ISA, znám spoustu strojů, které mají ISA sloty a v pohodě zatím slouží, představa, že by se místo nich měly kupovat nové nebo že přijdou o možnost mít aktuální software, mi tak úplně super nepřijde :-/

[Mandarinka]

Oni jaderní hackeři to dělají tak, že už ve skutečnosi většinu ovladačů rozbili předem, takže křičet, že vám přestane HW fungovat, už není nic platné:)

Moje ISA karty například už nefungujou. jedna od té doby, co vykopnuli OSS ovladače ("ALSA funguje"), u ostatních nevím, kdy ovladače přestaly fungovat..

[trekker.dk]

A hlásil jsi to?

[Mandarinka]

Jak říkám, třeba ta zvukovka má léta nefungující ALSA (cs4237b; nicméně zřejmě pouze v některých případech, protože modul se považuje za funkční) a že OSS z jádra vyhodili jsem zjistil po cca roce, takže se na mě asi zvysoka vykašlou... nebo spíš řeknou, jděte hlásit do ALSA. Což jsem udělal, ale 1) staré stroje nikoho netankujou - nejsem guru, abych to dokázal nareportovat fakt kvalitně (dump etc). Takže pro všechno dohromady zřejmě můj report zůstal nezodpovězen a vzhledem k nejistému osudu nemám chuť se snažit o víc. Už jsem s tou zvukovkou strávil mnoho, mnoho hodin, a víc už ani nápad. Protlačil jsem do toho přístroje Win XP a vzhledem k tomu, že to všecko funguje (a o dost líp než předtím) to tak už zůstane...

[trekker.dk]

třeba ta ISA, znám spoustu strojů, které mají ISA sloty a v pohodě zatím slouží, představa, že by se místo nich měly kupovat nové nebo že přijdou o možnost mít aktuální software, mi tak úplně super nepřijde

Nakonec se nic vyhazovat nebude.

[David Watzke]

A i kdyby jo, tak by to neznamenalo, že člověk nebude moct mít aktuální software. Linux 2.4 se taky pořád vyvíjí...

[cronin]

Cislovanie verzii je dost osemetna zalezitos a bol som svedkom toho, ako pri niektorych sw produktoch architekti, dizajneri a manazeri venovali pramalo zaujmu o fungovanie sw, ale o cislovani artefaktov a celych vydani dokazali viest niekolkodnove porady. Problem release managementu je v tom, ze postihuje prakticky vsetkych zainteresovanych: zakaznika, marketingove oddelenie, support, etc. az po posledneho vyvojara.

Ja ako pouzivatel chcem od verzovania sw, aby mi umoznil:

- porovnat dve rozlicne verzie a rozhodnut, ktora z nich je novsia.

- urcit, od akej verzie je to a to podporovane alebo opravene.

Ako sw vyvojar naviac chcem, aby mi verzovanie sw umoznilo povedat, ze to a to je deprecated a bude to odstranene "vtedy a vtedy". Preto ako cisla verzii pouzivam YYYY.MM, napriklad takto. Rozlisenie na mesiace mi postacuje, kto ma agresivnejsie planovane vydania, nech si prida dni. Cislovanie podla datumu napr. umoznuje povedat, ze "Tato ficura je dnes -- v oktobri 2008 -- deprecated, ale bude dostupna este aspon rok." a pouzivatel vie, ze vo vydani 2009.11 uz nemusi byt dostupna. Inak povedane, verzovanie na zaklade datumov umoznuje odvolavat sa dopredu na este neexistujuce verzie.

Aktualne cislovanie jadra mi pride trochu neprakticke. Co vlastne vyjadruje major cislo 2 a minor cislo 6? Existuje politika urcujuca, kedy sa niektore z nich ma a kedy nema zmenit? Ak neexistuje, rovnako dobre cislovanie by bolo 1, 2, 3, ..., 42, ...

[vlk]

ako pri niektorych sw produktoch architekti, dizajneri a manazeri venovali pramalo zaujmu o fungovanie sw, ale o cislovani artefaktov a celych vydani dokazali viest niekolkodnove porady

Pretoze cislovanie verzii je to jedine o com si manazeri myslia, ze tomu rozumeju a chcu dokazat, ze dany projekt riadia.

Naposledy ma vytocila poziadavka, ze cislovanie verzii dodavanych k zakaznikovi sa musia zvysovat vzdy o jedna. Ak je niektora instalacia chybna, tak sa vymaze a s rovnakym nazvom ( a cislom verzie ) sa doda nova instalacka ... Tato poziadavka ich presla, hned ako som im vyprodukoval dve rozne instalacie s rovnakym nazvom, a oni sa mali rozhodnut, ktoru odnesu k zakaznikovi.

[cronin]

Pretoze cislovanie verzii je to jedine o com si manazeri myslia, ze tomu rozumeju a chcu dokazat, ze dany projekt riadia.

Nastastie to nie je vzdy pravda. Vo firme, kde pracujem, su project manazeri napodiv technicky zdatni a ak neovladaju tu ktoru technologiu, snazia sa do problemu vniknut aspon natolko, aby svoje projekty vedeli skutocne manazovat.

Naposledy ma vytocila poziadavka, ze cislovanie verzii dodavanych k zakaznikovi sa musia zvysovat vzdy o jedna.

Ale ano, aj tuto alternativu som zazil: nech to vyzera, ze nieco robime. To je ta nepochopitelna honba za cislom verzie: Java 1.0, 1.1, 1.2, 1.3, 1.4, 5, 6, ... Zaujimave je, ze relativne stare a vyspele programy ako QCad, GIMP ci Linux kernel su vo verzii 2.

[Field]

Ne ze bych cislovani Javy hajil, ale mezi verzemi 1.4, 5 a 6 jsou skutecne velke zmeny, nikoli "nech to vyzera, ze nieco robime".

[cronin]

Ano, samozrejme. Ale skok z 1.4 na 5 je stale akysi iracionalny.

[Filip Jirsák]

Jenomže žádný skok z 1.4 na 5 u Javy nebyl. Byl skok v platformě Java z Java 2 na Java 5, a zároveň s tím byl „skok“ ve verzích JRE a JDK od Sunu z 1.4 na 1.5. Ten „skok“ z 2 na 5 byl celkem racionální, teď souhlasí verze Javy s druhým číslem ve verzi JRE/JDK.

[Filip Jirsák]

Problém číslování podle data je v tom, že až (nikoli když…) se vám podaří vydat nějakou hodně nepovedenou verzi, ke které budete potřebovat vydat ihned záplatu, budete muset tu opravenou verzi vydat s datem v budoucnosti.

[Michal Vyskočil]

Proč v budoucnu? Prostě se vydá opravná verze datum.x.

[Filip Jirsák]

Verze 2008.08.1 ale už nesplňuje formát verzování YYYY.MM…

[PePa]

Bude se muset použít formát: počet vteřin od 1.1.1970. Pak můžete každou vteřinu vygenerovat špatnou verzi. A stačí jedna šťastná vteřina ročne, abyste byl úspěšným.

[Andrej Herceg]

To by problém nevyriešilo. Z toho čísla by nebolo jasné, či ide len o opravu nejakej staršej verzie, alebo je to úplne nová verzia.

[Michal Vyskočil]

Jenže číslování podle data není dogma, jak to tu prezentujete, ale konvence. YYYY.MM se může brát jako major číslo, nebo jako major.minor s tím, že se výchozí číslo vydání (0) prostě uvádět nebude. Hlavní je, aby bylo jednoznačné, že je 2008.08 starší, než 2008.08.1.

[Filip Jirsák]

Jako dogma jsem to neprezentoval já, ale autor komentáře, na který jsem reagoval. A snažil jsem se mu vysvětlit to samé, co píšete vy – číslovat verze datem je nevhodné; číslování verzí systémem, který je založený na datu, je jeden z použitelných způsobů číslování.

[Michal Vyskočil]

Přiznám se, že jsem v tom původním příspěvku nic takového nenašel, ale díky za osvětlení.

[Nicky726]

+1

[Robert Krátký]

Cislovani verzi jadra by imho bylo nejlepsi ponechat tak, jak je.

Díky za námět na anketu.

[mrzout]

jak má být v číslování podle let probíhat aktualizace staré verze?

dnešní stav: -jádra 2.2.*, 2.4.* a 2.6.* Lze bez problémů provést aktualizaci například nad 2.4 a očíslovat ji třetím číslem. Všichni vědí, která verze v této řadě je novější.

Je jasné, že staré verze by se nepřečíslovávali, ale pokud si pokusím tento stav převést do budoucnosti (protože stabilizovaných větví bude jistě více), jak by se číslovala dnešní 2.4? Pokud by byla 2001.03.* (měsíc fakt nevím, jen jsem tam něco plácl), tak nebude zřejmé, ze kdy jádro s úpravou v roce 2008 pochází.

[David Watzke]

To by mě zajímalo na co jim tam tedy doteď ty nanosekundový časovače byly, když ty polling funkce odpovídaji v řádu milisekund.

[thingie]

Bylo/je to jediné použití časovačů?