Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
Do konference přišlo celkem 1483 emailů, nejvíce jich poslali "David S. Miller", Geert Uytterhoeven, Greg KH.
Jean-pierre Cartal si všiml, že chování kernelu 2.6-test se oproti 2.4 změnilo v tom, že root suid soubory o svůj suid bit nepřijdou, když jsou přepsány běžným uživatelem. Zeptal se, jestli je to záměr nebo chyba.
Ian Hastie to chování potvrdil a řekl: vypadá to, že ta chyba má co dělat s keší výpisu adresáře. Když po překopírování provedete sync, suid bit bude ukázán odstraněný.
Bill Davidsen se zeptal, co by se stalo, kdyby chtěl někdo program spustit před sync. Běžel by se setuid právy?
V tu dobu řekl Andries Brouwer, že už napsal opravu a zeptal se, jestli funguje. Ian odpověděl, že na jeho XFS filesystému oprava nefunguje. Konec vlákna.
Marcelo Tosatti napsal:
Přišlo mi několik stížností, že HT počínaje 2.4.22 potřebuje povolené ACPI. Uživatelé, kterým dříve fungovalo HT, teď musí používat ACPI, kdežto předtím nemuseli.
HT by mělo fungovat AUTOMATICKY bez povoleného ACPI a BEZ speciálního boot parametru, jako dřív.
Požádal Lena Browna, aby se na to podíval; a Jun Nakajima potvrdil, že Len na tom pracuje. Len odpověděl: CONFIG_ACPI_HT_ONLY "CPU Enumeration Only" je v menu CONFIG_ACPI kvůli žádosti Red Hatu - chtěli mít možnost zakázat všechno týkající se ACPI jedinou volbou (CONFIG_ACPI). HT závisí na této části ACPI, protože logické HT procesory jsou zjištěny podle položek ACPI MADT LAPIC.
O pár zpráv dále navrhl:
Co s tím?
Mohli bychom udělat 2.4.23 jako 2.4.21, kde byl ACPI kód pro HT obsažen v kernelu, i když nebylo CONFIG_ACPI nastaveno.
Nebo můžeme 2.4.23 ponechat jako 2.4.22, kde zakázání CONFIG_ACPI skutečně odstraní všechen ACPI kód z kernelu; a když se nastaví CONFIG_ACPI, je k dispozici CONFIG_ACPI_HT_ONLY, které omezí ACPI pouze na tabulkovou část potřebnou pro HT.
Já jsem pro to druhé (nedělat nic), protože CONFIG_ACPI by skutečně mělo vyřadit všechno z ACPI. Jestli začneme zařazovat kousky z ACPI bez CONFIG_ACPI, kde to skončí?
Nejsem si jistý, jak řešit koncepty "kompatibility" a "regrese" zároveň se změnou konfiguračních souborů. Make oldconfig se vás zeptá na CONFIG_ACPI -- možná bych měl upravit text nápovědy tak, aby zdůrazňoval, že je nezbytné HT a že je-li povoleno, zpřístupní se tím CONFIG_ACPI_HT_ONLY?
Používá se defconfig? Definuje "kompatibilitu"? Jestli ano, mohli bychom definovat CONFIG_ACPI && CONFIG_ACPI_HT_ONLY v defconfigu a získat tak chování 2.4.21 -- vlk by se nažral a koza zůstala celá.
Nemám na to příliš vyhraněný názor, ale budu chtít v této oblasti udržet 2.4 a 2.6 co nejvíce podobné.
Marcelo souhlasil, že CONFIG_ACPI_HT by nemělo být závislé na CONFIG_ACPI. Požádal Lena, aby v konfiguraci objasnil, že tato závislost neexistuje a aby přesunul položku CONFIG_ACPI_HT ze sekce ACPI. Jeff Garzik poznamenal, že by mohlo být matoucí vidět "ACPI" v názvu konfigurační položky mimo sekci ACPI a navrhl jako alternativy "CONFIG_HYPERTHREAD" nebo "CONFIG_HT".
Ale Len se změnou nesouhlasil, protože stávající název výstižně popisuje skutečnou situaci. Jeff znovu řekl, že "CONFIG_HT" by bylo o mnoho srozumitelnější; ale Len trval na tom, že "CONFIG_HT" nedává smysl. Naznačuje to, že můžeš mít CONFIG_ACPI, ale i tak vynechat HT, což nejde. Len si stál za svým, ale řekl, že implementoval Marcelovy požadavky. A vlákno skončilo.
Během diskuze Andrea Arcangeli poznamenal, že kdyby Marcelo Tosatti používal pro vývoj open source nástroj místo BitKeeperu, bylo by možné implementovat určitou šikovnou funkci pro changelogy. Linus Torvalds odpověděl:
Andrea - zmlkni už, prosím.
Dokud nebudeš moci nabídnout něco alespoň _vzdáleně_ tak dobrého jako je BitKeeper, tak nemá smysl neustále zkoušet začínat flamy.
Souhlasím s tím, že Larry se kvůli tomu nakonec také chová jako pitomec, ale dovedu snadno pochopit, že to jsou reakce na tvoje naprosto neproduktivní komentáře.
BK už email v meta-data má a také mnoho nástrojů pro vytažení potřebných údajů z mailboxů atd.
Jinými slovy, tvůj argument nemá smysl a celá tvoje zpráva je zbytečná - kromě toho, že je návnadou na flame. A ano, Larry tvoji návnadu pravděpodobně spolkne, což jsem mu už několikrát v soukromých emailech vyčítal.
Takže buď mlč nebo se přizpůsob. Dej se do toho a napiš svůj vlastní nástroj. Do té doby si přestaň stěžovat na lidi, kteří napsali _své_ nástroje a zvolili si licenci, kterou by sis ty nevybral.
Až napíšeš nějaký svůj kód, budeš si moct zvolit licenci. A zatím jsem si nevšiml, že bys dovedl CVS do použitelné podoby - vidím tě jen prudit, fňukat a stěžovat si.
Andrea odpověděl: Kdybych věděl, že tě nakonec začne zajímat něco jiného než BitKeeper, rád bych v té oblasti pracoval (také se mi hodí trochu volného času), abych poskytl komunitě nějaké služby. Hlavním důvodem, proč nikdy nebudu b*tkeeper používat, je ten, že si chci uchovat volnost tak jednat - něco, co ty a mnoho ostatních už nemůžete udělat. Navrhl, že CVSPS a Subversion by mohly být odpovídajícími nástroji pro vývoj kernelu.
Linus odpověděl:
Ani jeden z těchto nástrojů nedosahuje kvalit bk.
Především nepodporují žádný druh distribuovaného vývoje. Je mi to líto, ale dokonce se o to ani nesnaží. A pro mě je distribuovaný vývoj jedinou věcí, na které záleží.
A uvědomuji si, že pro tebe ne. Ty se moc nestaráš o slučování. Máš na starosti pouze svůj strom.
A víš co? To je v pořádku, že se nestaráš. Já ti nevyčítám, že používáš CVS/SVN/cokoliv. Vyčítám ti, že si stěžuješ, když _jiní_ dojdou k závěru, že CVS/SVN/cokoliv pro ně prostě není to pravé.
Používej CVS a buď spokojený. Ale nestěžuj si ostatním, kteří mají potřeby, s nimiž jim jednoduše CVS nepomůže.
Ve stejném mailu dodal:
Nezajímá mě software pro zvládání zdrojových kódů, takže je nepravděpodobné, že bych se kdy (tedy "nikdy") pustil do psaní nějakého - ale kdybych to udělal, musel bych se propadnout studem, kdybych uživatelům vnucoval software nižší kvality. Omluvil bych se a přiznal svou chybu, když by to nefungovalo. A pak bych se snažil, jak nejlépe bych uměl, abych to vylepšil. I kdyby to mělo trvat desel let.
Naopak to, co děláš ty, je "nevšímejte si toho kvalitního: používejte tenhle zmetek, protože já jsem kámoš lidí, kteří to vyvíjejí. Ani se nesnažíme konkurovat v technických záležitostech, ale budeme vám svoji verzi vnucovat, protože my máme náboženství a v tomhle není žádné hovězí". To je špatně - zvlášť, když ostatní to náboženství nesdílejí.
Nemám nic proti lide kteří používají NT. Když jim to více vyhovuje, je to jejich volba. Usilovně pracuji na tom, aby byl linuxový kernel technicky vyspělejší a když není, chci to napravit. Prože já nechci, aby lidi Linux používali z náboženských důvodů. Chci, aby ho používali, protože je pro ně _lepší_, nebo protože skutečně věří, že mu k tomu mohou dopomoci (nebo se aspoň bavit, zatímco se o to snaží).
Buď pyšný na to, co děláš. Ale nenech se tou pýchou zaslepit při posuzování, co je a co není dobrá technologie. Nepleť do toho náboženství. Je to věda.
V tuto dobu navrhl Pau Aliagas, že arch by zvládl vše, co Linus požaduje a ještě více. Ale nikdo o tom nediskutoval.
Poblíž požádal Larry McVoy Andrea, aby se přestal chovat nevděčně, když mu někdo nabízí pomoc. O pár zpráv dále Larry poznamenal, že Andrea pro kernel nedělá žádnou významnou práci, a proto si nezasluhuje respekt. Andrea připomenul, že hrál důležitou roli ve vývoji linuxového subsystému virtuální paměti, který, jak řekl, pravděpodobně běží i na Larryho systémech. Larry reagoval, že subsystém virtuální paměti byla dětská hračka v porovnání s jeho vlastními výtvory, především subsystém VM, na kterém pracoval pro SunOS. Někdy v tu dobu se ozval Linus:
Larry, myslím, že si pamatuješ ty staré, dobré časy se SunOS, kdy bylo 16MB RAM hodně a lidi od svého hardware nečekali tolik. Konkrétně interaktivní programy měly _malinkou_ stopu. Často dokonce pod X.
Pak jsme na ty křápy dali Solaris, Motif a CDE a bylo to děsné.
Jo, SunOS byl fajn. Ale opravdu si myslím, že to, co se změnilo, jsou přístupové vzory.
Na jiném místě poblíž řekl Linus Andreovi: tvůj nezájem o BK _nevysvětluje_, proč kvůli němu fňukáš, snažíš se Larryho vyprovokovat a jsi prostě všeobecně nepříjemný.
Dodal, že každý má právo si vybrat licenci, pod kterou chtějí vydat svůj kód, a nikdo nemá právo se kvůli tomu rozčilovat. A také zopakoval, že Andreovy komentáře jsou neslušné a dokonce urážlivé.
Ale vložil se do toho Roman Zippel: Tomu ty říkáš neslušné? Poslední dobou bývám při těchto flamech ticho, protože bych nedokázal zůstat slušný k arogantnímu kreténovi, ale nebudu mlčet, když teď může Larry urážet jiné vývojáře a projde mu to. Jestli si tu někdo stěžuje, tak je to Larry. Do kernelu přispívá mnoho lidí, ale on je jediný, který neustále naříká, že na něj máme být hodní a hloupě vyhrožuje. Mohli bychom se tu, prosím, dočkat akce a reakce? Samozřejmě, že si Larry může vybrat licenci, která se mu zalíbí, ale propagace stupidní licence v prostředí svobodného software také pochopitelně vzbudí nesouhlas a stížnosti. Kromě Larryho s tím nikdo _nic_ nenadělá, ale i přesto si Larry dokáže vztáhnout každou stížnost jako osobní urážku a dělá tak každý flame o bk ještě horší, než je.
Jinde Eric W. Biederman upozornil, že existují projekty, které využívají BK jen proto, že se snaží napodobit správu Linuxu, ale jejich kód se tak nedá bez BK získat. Takže přeci jen má využívání BK pro vývoj kernelu nějaké stinné stránky.
Eric také poznamenal, že arch si moc dobře neporadí s distribuovanými repozitáři nebo slučováním repozitářů, na což reagoval Miles Bader, který toto tvrzení vyvracel s tím, že arch je naopak výborný pro distribuovaný vývoj. A Davide Libenzi potvrdil, že arch byl vyvíjen především pro distribuovaný vývoj, takže pokud něco zvládá opravdu dobře, tak je to tohle.
Nigel Cunningham oznámil:
Tímto oznamuji, že LinuxFund.org (http://www.linuxfund.org) souhlasilo s tím, že mě bude podporovat při práci na softwarovém uspání na plný úvazek od 1. října.
Tento vývoj by měl vést k rychlejšímu dokončení verze pro 2.4 a rychlejšímu vydání portu na 2.6. Dá-li pán, bude testovací verze pro 2.6, která by podporovala všechny funkce jako verze pro 2.4, dostupná během pár týdnů.
Několik lidí pogratulovalo.
V originálu Kernel Traffic 235 vyšla navíc ještě tato témata:
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
ok. uniklo mi dost preklepu. omlouvam se a dekuji za upozorneni.
pravda je takova, ze pro jaderne noviny spell check nepouzivam. pokazde je tam totiz tolik vyrazu, ktere nejsou v zadnem slovniku, ale presto jsou spravne, ze to ani nestoji za to.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz