Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Před několika dny vyšel Linux 3.19 (zprávička) a bylo otevřeno začleňovací okno pro další verzi. Bude to 3.20 nebo 4.0? Linus Torvalds spustil na Google+ hlasování.
Tiskni
Sdílej:
13.2.2015 18:37
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
13.2.2015 20:03
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
13.2.2015 17:38
Prcek | skóre: 43
| Jindřichův Hradec / Brno
.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
13.2.2015 22:42
3.20 jako velké / dlouhé číslo verze? To by mě zajímalo, co říká na verze flashpluginu - např. 11.2.202.442 apod.
(teda, nepocitam povery skolaku ve smyslu "zitra piseme pisemku z XY... to nosi smulu")
14.2.2015 08:12
GeoRW | skóre: 13
| blog: GeoRW
| Bratislava
Podla verzie sa to tvari ako intergalakticky genialne vyladeni software, ale castokrat je to horsie ako beta verzia.
Myslím, že číslo verze samo o sobě nic neznamená – třeba takový less mám ve verzi 458.
A co sémantické verzování?
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Tak buď je to tak v pořádku a chceme to, pak se není za co stydět a nevadí, že ta pravda vyjde na povrch i v podobě čísel verzí – nebo se autoři trochu víc zamyslí nad zaváděním nekompatibilních změn.
Další možnost je nečíslovat jen jádro jako celek, ale verzovat API jednotlivých podsystémů – aplikace/knihovny by pak byly závislé jen na některých komponentách jádra a nevadilo by jim, že v jiných komponentách došlo k nekompatibilním změnám, protože je vůbec nepoužívají.
A jak to vyřeší případ, kdy aplikace bude závislá na komponentě jádra, která se změnila? Nijak, aplikace přestane s novým jádrem fungovat (nebo v horším případě něco rozbije.)
Dejme tomu, že máš serverovou aplikaci, která využívá souborový systém a nějaké síťové věci – ale nezajímají ji multimédia. Pak ti může být jedno, že se změnila komponenta související s multimédii a stačí, když si budeš hlídat verze těch komponent týkajících se FS a sítě.
Je otázka, jak a s jakou granularitou to rozdělit a samostatně verzovat… Ale i kdyby se verzovalo jen jádro jako celek: jistě najdeme verze, které lze libovolně zaměnit a vše bude fungovat, navenek se nic nezměnilo a lze je tedy považovat za kompatibilní. A pak zase verze, na které nejde jen tak upgradovat a u kterých je potřeba změnit i něco mimo jádro.
Hádám, že tvrzení v případě jádra se "incompatible API changes" objevují prakticky v každé verzi se týkalo vnitřních API uvnitř jádra, nikoliv mimo něj.
Mně se tohle tvrzení taky moc nezdálo, ale nechtěl jsem to rozpitvávat. U vnitřního API, kde jádro používá samo sebe, v tom není problém, to si musí vyřešit jeho autoři a okolní svět to moc nezajímá – pro ten je důležité to vnější/veřejné API.
Hádám, že tvrzení v případě jádra se "incompatible API changes" objevují prakticky v každé verzi se týkalo vnitřních API uvnitř jádra, nikoliv mimo něj.
Přesně tak. Rozhraní směrem k userspace se naopak zachovává velmi striktně, a to i případech, kdy je všem jasné, že bylo navrženo úplně špatně.
Mně se tohle tvrzení taky moc nezdálo, ale nechtěl jsem to rozpitvávat. U vnitřního API, kde jádro používá samo sebe, v tom není problém, to si musí vyřešit jeho autoři a okolní svět to moc nezajímá – pro ten je důležité to vnější/veřejné API.
Záleží na tom, co přesně myslíte okolním světem. Není to problém pro userspace aplikace, ale může to být docela velký problém pro ty, kdo píší nebo používají out-of-tree moduly. To má ale i své výhody, takže je to tak trochu i záměr.
Například i malé a zdánlivě nevinné změny mohou rozbít cizí kód. Třeba když v Javě do třídy přidám soukromou metodu.
Když přidám soukromou metodu, tak i kdyby v potomcích byla jiná metoda se stejným názvem, tak to ničemu nevadí. A kódu, který tyto třídy používá, to nevadí už vůbec – od toho jsou to soukromé metody, aby je nikdo zvenku nemusel řešit.
Navíc API by v první řadě mělo být definované pomocí abstrakce tzn. rozhraní – pokud přidám/odeberu/upravím metodu v tomto rozhraní, jedná se o nekompatibilní změnu.
Pokud chci jen přidávat metody/funkcionalitu, můžu vydat nové rozhraní označené nějakou verzí, které rozšiřuje to staré (interface Interface2 extends Interface1 { … }). Z pohledu klientského kódu, který toto rozhraní používá, je to zpětně kompatibilní (nové rozhraní jen přidává nové funkce, které nemusím využít) a z pohledu implementace rozhraní si musím vybrat, kterou úroveň/verzi budu podporovat/nabízet.
klientský kód závislý na hashi knihovny
K čemu je to dobré?
nebo na tom, zda existuje nějaká privátní metoda (lze zjistit pomocí reflexe)?
To už je jen jeho problém resp. chyba. Privátní metody nikdo nikomu neslíbil, nelze se na ně spoléhat – od toho jsou privátní
K čemu je to dobré?Třeba, když si program stahuje knihovnu z internetu, tak potřebuje ověřit, že si ji správně stáhl (tohle dělají některé aplikace na Androidu, jenž nejsou svobodné, ale pro svou práci potřebují svobodné knihovny).
Privátní metody nikdo nikomu neslíbil, nelze se na ně spoléhatOk, proto se ptám, co přesně je slíbené, jinými slovy, jak je kompatibilita definována? Například, kdyby měla knihovna specifikaci a splňovala jí, pak by nová verze knihovny byla kompatibilní se starou verzí právě tehdy, když všechny vlastnosti, jenž jde odvodit ze staré specifikace, jde odvodit i z nové. Důsledkem je, že pokud klient využívá knihovnu pouze dle specifikace, tak lze nahradit starou verzi knihovny kompatibilní novou verzí, aniž by se změnilo chování klienta. Problém je, že málokterá knihovna má dostatečně obsáhlou specifikaci, aby ji šlo používat pouze dle specifikace (tj. když ji chcete použít, musíte využít i vlastnost, která není nikde slíbena, ale momentálně platí).
Třeba, když si program stahuje knihovnu z internetu, tak potřebuje ověřit, že si ji správně stáhl (tohle dělají některé aplikace na Androidu, jenž nejsou svobodné, ale pro svou práci potřebují svobodné knihovny).
Mluvíš o porušování autorského práva?
Každopádně tenhle přístup je zvrácený sám o sobě 1) program si nemá co stahovat nějaké závislosti – ty má stahovat balíčkovací systém. 2) pokud chceš kontrolovat hash, tak stahuj konkrétní známou verzi třeba foobar-1.1.3.tar.gz a ne foobar-latest.tar.gz. Jednou vydaná a očíslovaná verze by měla být neměnná, binárně shodná. 3) pokud chceš nejnovější kompatibilní verzi knihovny, tak nekontroluj hash ale elektronický podpis proti známému veřejnému klíči (což je lepší tak jako tak).
Ok, proto se ptám, co přesně je slíbené, jinými slovy, jak je kompatibilita definována? Například, kdyby měla knihovna specifikaci
Ano, dobrá knihovna by měla mít specifikaci, resp. pokud ten vývoj bereš vážně, tak bys měl udělat specifikaci a k tomu referenční implementaci knihovny/programu. Ale i když nezávislá specifikace není a splývá s (jedinou/referenční) implementací, tak by mělo být zřejmé, co je poskytované API a co jsou interní záležitosti, které se mohou kdykoli bez varování změnit.
Soukromé metody zcela jistě do veřejného API nepatří. Stejně tak tam nepatří třídy a metody z balíčků (jmenných prostorů), které autoři v dokumentaci (nebo třeba pomocí nějakých anotací či komentářů) označili jako interní. Stejně tak parametry metod – když budeš mít v JavaDocu (nebo jeho obdobě) napsáno, že tenhle parametr nemá být null nebo že má být menší než 1000 nebo kratší text než 256 znaků, tak by ses tím měl řídit – přestože současná implementace může být tolerantnější a poradí si i s jiným vstupem. Kdykoli se to může změnit a je to tvoje chyba – autoři tě jasně varovali.
Mluvíš o porušování autorského práva?Myslím, že jde spíše o obcházení. Dělají to např. některé programy pro čtení PDF, jenž používají Poppler.
Když přidám soukromou metodu, tak i kdyby v potomcích byla jiná metoda se stejným názvem, tak to ničemu nevadí.Jak je to možné? Pokud vim, metody jsou v Javě by-default virtual (tj. nejsou final, v Javovském žargonu). Očekával bych teda, že přidání metody ovlivní vtable. Nebo Java nepoužívá vtables? Počítám, že nějak musí dynamic dispatch řešit.
Očekával bych teda, že přidání metody ovlivní vtable.Ano. vtable však není součástí bajtkódu, ale linker jí vytváří až za běhu programu.
Ok, ale i tak, když přidáš metodu, tak se vytvoří jinak ne?Ano, vtable bude jiná (někde tam bude ta metoda), ale ničemu to nevadí.
14.2.2015 20:50
13.2.2015 23:28
14.2.2015 11:29
Base a Derived (která dědí Base), které obě obsahují metodu foo(), která je ve vtable na slotu #1. Dejme tomu, že nějaký externí kód používá tyhle dvě třídy v rámci nějaké binárně distribuované knihovny.
Dejme tomu, že v nové verzi knihovny do třídy Base přidám metodu bar(). Jak se zajistí, aby se metoda bar() nedostala ve vtable na slot #1 (foo() by se dostala na slot #2), a tím pádem se nestalo, že klientský kód zavolá metodu na slotu #1 v domění, že volá foo(), ale ve skutečnosti by zavolal bar()?
Je možné, že by linker ty indexy dynamicky určoval před spuštěním programu podle jmen metod?
v rámci nějaké binárně distribuované knihovnyvtable není součástí bajtkódu, nýbrž se vytvoří až za běhu programu (a navíc vtable pro
Derived se vytvoří až po vtable pro Base).
To je ale pro mě docela zajímavé zjištění; TIL: Java je v podstatě skriptovací jazyk
na private metody se v Javě dynamic binding nepoužijeTo nejsem schopen potvrdit ani vyvrátit, nicméně v aktuální implementaci OpenJDK 8 se soukromé metody, jenž nejsou final, dávají do vtable.
to by byla i bez nej ... je to jen nic nerikajci cislo co s casem stoupa ...
live patching k tomu doda jen punc neceho vetsiho
16.2.2015 01:01
