LibreOffice 4.2.1

LibreOffice, OpenOffice.org

Három héttel a LibreOffice 4.2 után a The Document Foundation bejelentette a LibreOffice 4.2.1 megjelenését. Az első hibajavító kiadás a szokásosnál korábbi megjelenése azzal indokolható, hogy a 4.2-ben debütáló nagy léptékű kódátalakítások olyan hibákhoz vezettek, amelyek javítása nem tűrt halasztást. A LibreOffice 4.2.1 mindegy 100, különböző súlyosságú hibát javít. A változások listája itt olvasható.

A részletek itt olvashatók.

( hnsz2002 v | 2014. 02. 21., p – 09:54 )

És mindig jönnek új hibák is... Tegnap pont felraktam egyik helyen a usernek, mert mondta hogy sokszor befagynak a libreoffice processzek, nem nyit meg semmit (egyébként ez is egy ősi bug), mondom akkor teszek fel neki frissebbet. Ez is ugyanúgy produkálta a befagyást, plusz ebben éppen nem lehet a vágólapra másolni és másik programba beilleszteni (windowson). Úgyhogy visszatettem a 4.1-et, az legalább "csak" befagy.
--
The Community ENTerprise Operating System

A vágólapos hiba már megvan. Valaki úgy gondolta, hogy milyen régies dolog már, hogy a HTML export nagybetűs HTML tageket ír ki magából. Átírta mind kisbetűsre. Arra senki nem gondolt, hogy ettől a vágólap el fog romlani Windowson. :)

Most erre mondhatnánk azt, hogy minek nyúlt hozzá, de belátható, hogy ha nem nyúlunk hozzá semmihez, nehogy elromoljon, akkor az nem eredményez egy túlzottan dinamikus projektet. A tanács továbbra is érvényes, a .0, .1 kiadások early adoptereknek vannak, akik kalandvágyóak, és segíteni szeretnének.

( bathory | 2014. 02. 21., p – 09:58 )

Az a "mindegy 100" elég mókásan hangzik :)

( nagy_peter v | 2014. 02. 21., p – 17:56 )

Azért jó látni, hogy a 100 hibajavítás elég jelentős része készült magyarok által :)
Vajna Miklós, Tímár András és Zolnai Tamás kb a 10%-át javította az összes bugnak. Köszönjük nekik is!

Nagy Péter

( tombenko v | 2014. 02. 21., p – 18:25 )

Csak a szokásosat tudom hozzáfűzni - hajrá, hajrá!
--
Fight / For The Freedom / Fighting With Steel

Az álmoskönyv szerint ez nagyon rossz jel. A mai hálózati protokollok mellett az átvitel szinte soha nem sérül, így vagy a géped hibázik (de ha következetes, akkor ez nagyjából kizárható), vagy azok a tgz-k különböznek, ami nagyon komoly problémára utal. Tudnál írni konkrét linkeket?

Halozati hiba volt. Ezt lehozva masova:
http://download.documentfoundation.org/libreoffice/stable/4.2.1/deb/x86…

stimmelt az SHA1 a tavoli serveren az oldalon megadott ertekkel. Onnet atscp-ztem azon meg van integrity check. Igazabol az egy elterjedt tevhit hogy mindenhol van integrity check legalabb egy CRC vagy checksum formajaban. Pl.TCP eseten end2end ilyen nincs az adatra. Ethernet transport eseten FCS-t vagy neznek vagy nem.

Bár vagy húsz éve foglakozom hálózatokkal, de kissé elbizonytalanítottál. Igaz, hogy a tűzfalazás miatt főleg a headerek érdekeltek általában, vagy a data belseje, annak sértetlenségéven nemigen törődtem. Most megnéztem, hogy jól emlékszem-e iskolából, és ezeket találtam (csak a TCP-t tettem ide, de az UDP-ben is van):

[1] TCP provides reliable, ordered, error-checked delivery of a stream of octets between programs running on computers connected to a local area network, intranet or the public Internet. It resides at the transport layer.

[2] The TCP/IP checksum is used to detect corruption of data over a TCP or IPv4 connection.

[1] http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_com…
[2] http://locklessinc.com/articles/tcp_checksum/

Azért még mindig óvatosan kérdezem meg... Nem lehet, hogy tévedsz? Miből gondolod, hogy nincs integritás ellenőrzés?

Idézem magamat odafentről: "A mai hálózati protokollok mellett az átvitel szinte soha nem sérül"
Ha a network stack-ek között van checksum ellenőrzés, akkor tehát az átvitel alatt valószínűleg nem sérül, ugye? Akkor ha neki több szerverről több különböző az sha checksum, akkor vagy valaki manipulálta a letölthető csomagokat, vagy nála van a hiba, nemdebár?

"Valami a sorban tul egyszeru ahhoz hogy ellenorizze a bejovo csomagot"

Hát... Én eddig ilyet még sose láttam. Olyat már sokszor, hogy valami miatt megszakadt a letöltés vagy a csomagok elmentek dél Afrika felé valami routing hiba miatt, de hogy a TCP checksum _és_ az adat is pont úgy romlott el, hogy azt a végpont helyesnek vélte és ezért hibás lett a diszken a letöltött adat... Nem hinném, hogy ez túl gyakran előfordul manapság.

Miert? Van egy cucc aminek ujra kell szamolni a tcp cksum-ot mert piszkalta a headert (NAT). Ket modon lehet ezt:
1. kiszamolja csak a modositas kulonbseget ezt hozzaadja a cksum ertekhez
2. ujraszamolja az egeszet (hdr + data)

Jobb helyeken 1. az ajanlott, de lehet 'simple designer' baratunk kapott valami hibajegyet ahol ez nem ment (valami belepiszkalt a header-be amit kihagyott a szamitasbol), igy meginnovalta, lett 2. belole. Lassabb is meg szarabb is de a teszteken atment.

Most 1. transzparensen megorzi azt is ha kozben hiba tortent az atvitel soran. 2. meg jol elfed mindent. A vegberendezes egy tokeletes tcp cksum-al kapja a hibas csomagot is.

Ja es az ezt vegzo cucc modositas elott nem ellenorni a tcp cksum-ot az egesz data-ra, mert azt minek.

Hint: pl van egy bithiba a router memóriájában. Ezzel simán lehet a csomag és az újraszámolt checksum konzisztensen hibás.

Nyilván a szolgáltató-oldali cuccokban ECC-s puffermemória van, és rögtön kivágja az alertet, ha ECC hibát észlel. Otthoni kis routerekben viszont még sosem láttam ECC-s hardvert. Nem is triviális memtest-et futtatni rajtuk.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ez talan a legvaloszinubb, memoriahiba egy olcso home routerben. 16 bit cksum van tehat ha csomagon belul olyan paros bithiba van ami mindig egy adott bitpoziciot erint es egyszer 1->0 maskor meg 0->1 akkor a cksum ezt nem veszi eszre. Nagy file-ok eseten (60-200M) lattam az ereteti hibat, szoval ez valami kisvaloszinusegu esemeny sima HW hiba inkabb. Ha nem igy jon ki a lepes azt eszreveszi a TCP cksum es dobja az adott csomagot.

Áá nem kell ehhez ennyire szofisztikáltnak lenni. A checksum újraszámolásakor a CPU már hibás bitet olvassa fel, így a számol egy tökéletes checksumot a hibás adatra.

Én már jártam így, csak disk cache-sel. Néztem, mint bálám szamara az újkapura, hogy mi a búbánatért nem fogja meg semmi a hibát.
---
Régóta vágyok én, az androidok mezonkincsére már!