Máirín Duffy a Brian Smith v článku pro Fedora Magazine ukazují použití LLM pro diagnostiku systému (Fedora Linuxu) přes Model Context Protocol od firmy Anthropic. I ukázkové výstupy v samotném článku obsahují AI vygenerované nesmysly, např. doporučení přeinstalovat balíček pomocí správce balíčků APT z Debianu místo DNF nativního na Fedoře.
Projekt D7VK dospěl do verze 1.0. Jedná se o fork DXVK implementující překlad volání Direct3D 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána nová verze 2025.4 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) zveřejnil Národní politiku koordinovaného zveřejňování zranitelností (pdf), jejímž cílem je nejen zvyšování bezpečnosti produktů informačních a komunikačních technologií (ICT), ale také ochrana objevitelů zranitelností před negativními právními dopady. Součástí je rovněž vytvoření „koordinátora pro účely CVD“, jímž je podle nového zákona o kybernetické … více »
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 25.12. Přehled novinek i s náhledy a videi v oficiálním oznámení.
Společnost System76 vydala Pop!_OS 24.04 LTS s desktopovým prostředím COSMIC. Videoukázky na YouTube.
Byla vydána verze 1.92.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Free Software Foundation zveřejnila ocenění Free Software Awards za rok 2024. Oceněni byli Andy Wingo, jeden ze správců GNU Guile, Alx Sa za příspěvky do Gimpu a Govdirectory jako společensky prospěšný projekt.
Bylo vydáno Eclipse IDE 2025-12 aneb Eclipse 4.38. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
U příležitosti oslav osmi let prací na debianím balíčku vyšlo GPXSee 15.6. Nová verze přináší především podporu pro geotagované MP4 soubory, včetně GoPro videí. Kdo nechce čekat, až nová verze dorazí do jeho distribuce, nalezne zdrojové kódy na GitHubu.
Benjamin Meyer, jeden z vývojářů Qt, píše o vylepšeních v novém webovém prohlížeči Qt Demo Browser (který je součástí Qt 4.4 jako ukázka schopností Qt WebKitu). Prohlížeč nově podporuje záložky, obsahuje vylepšený adresní řádek (integrovaný progress bar a indikace HTTPS spojení), private browsing, spoustu nových nastavení (otvírání stránek v novém tabu, vypnutí JavaScriptu a pluginů, uživatelské CSS, atp.), ukládání a tisk stránek, atd. Mezi zajímavosti patří extrémně rychlý (téměř okamžitý) start aplikace, Qt pluginy a plně fungující session management. Ze základních funkcí schází už jen Netscape pluginy a disková cache.
Tiskni
Sdílej:
Pravidelně sleduju v KDE Subversion repozitáři modul webkitkde (kde se vyvíjí QtWebKit KPart). Už to funguje, ale pořád to ještě není źuplně vychytaný (a stále je to taky ještě v playground).
Nicméně tenhle Qt Demo Browser má také něco do sebe (díky tomu jak je jednoduchý a rychlý). Po vydání finálního Qt 4.4.0 se dost možná oddělí, přejmenuje (zatím padl návrh na jméno QuesT) a stane se z něj samostatný projekt (kam už bude moct přispívat kdokoliv, nejen vývojáři Qt).
Proběhly od té doby nějaké změny, jako třeba zbavení se závislosti na RE MSVC++ na Windows?
6.4.2008 11:57
David Watzke | skóre: 74
| blog: Blog...
| Praha
Proběhly od té doby nějaké změnyVždyť o tom je ta zprávička... RTFA.
6.4.2008 12:00
Rezza | skóre: 25
| blog: rezza
| Brno
6.4.2008 12:54
Rezza | skóre: 25
| blog: rezza
| Brno
).
A nekdo bude muset napsat zase dalsi jednoduchy demo projektik pro Qt, z toho zase vznikne samostatny projekt a historie se bude porad donekonecna tocit!zapomněl jsi na jednu věc, a to že poté, co se z toho stane "samostatný" projekt, se kolem toho začne motat pár bývalých vývojářů Konqueroru, několik z nich bude mít blbé hlášky na aktivní vývojáře Konqueroru, ti si to nenechají líbit, komunitní týpci "aktivní blbec" je dík tomu totálně zdiskreditují poukazováním na uraženou ješitnost a podobné hlody, načež frontman_KDE_v_té_době hodí Konqueror přes palubu a podpoří plíživou snahu jej nahradit Qt_Demo_Browserem, čemuž bude typ "aktivní blbec" zuřivě tleskat a pod každou zmínkou o Qt/KDE/jiném browseru nezapomene připsat, jak je Qt_Demo_Browser super a že je dobře že vytlačil Konqueror, přičemž z každého, kdo si dovolí říct, že se mu takový vývoje nelíbí, bude do roztrhání dělat idiota ... aby bylo to opakování historie kompletní
Vám asi někdo šlápl na kuří oko
Teď vážně: Konqueror (prohlížeč) se podle mě o svou budoucnost obávat nemusí. Je postaven na KDE a využívá skrz na skrz jeho technologie, zatímco DemoBrowser je odlehčená multiplatformní hračka nad čistým Qt, která už z principu nemůže být do KDE (tolik) integrovaná. Každý přístup má jiné vlastnosti a dva takové browsery mohou v klidu žít vedle sebe aniž by si konkurovaly (jako např. Firefox a Epiphany v Gtk/Gnome). Něco jiného by bylo, kdyby někdo začal vyvíjet nový superhyperprohlížeč čistě pro KDE - pak by se s Konquerorem časem požraly jako Epiphany s Galleonem.
Trochu jiné je to s vlastním vykreslovacím jádrem: s tímto přístupem případnému mergi v podstatě nic nebrání.
Ještě ti tam chybí vynoření se fungl nového a ještě mnohem lepšího browseru, který vytlačí DemoBrowser stejným způsobem jako ten předtím vytlačil Konqueror.no však to tam má kolega
Teď vážně: Konqueror (prohlížeč) se podle mě o svou budoucnost obávat nemusí. Je postaven na KDE a využívá skrz na skrz jeho technologie, zatímco DemoBrowser je odlehčená multiplatformní hračka nad čistým Qt, která už z principu nemůže být do KDE (tolik) integrovaná.neřekl bys něco velmi podobného před pěti lety o KHTML?
Trochu jiné je to s vlastním vykreslovacím jádrem: s tímto přístupem případnému mergi v podstatě nic nebrání.no, "v podstatě" ... z "proti" považuju body 2 a 4 za celkem podstatný problém, bohužel :-/
neřekl bys něco velmi podobného před pěti lety o KHTML?Nevím. U samotného vykreslovacího jádra podle mě stačí, že kreslí přes tytéž knihovny, jako program (= Qt v případě KDE), a závislost na vyšších věcech (kdelibs a vyšší) je spíš na škodu. Applové to pochopili dřív než kucí od KHTML, a proto se teď všude možně začíná cpát právě WebKit (což má za následek více vývojářů WK
no, "v podstatě" ... z "proti" považuju body 2 a 4 za celkem podstatný problém, bohužel :-/Obojí to jsou především organizační věci - bude-li zájem, tak si je dotyční domluví rychle.
U samotného vykreslovacího jádra podle mě stačí, že kreslí přes tytéž knihovny, jako program (= Qt v případě KDE), a závislost na vyšších věcech (kdelibs a vyšší) je spíš na škodu.potíž této úvahy je v tom, že to nelze brát jakou jednorozměrný problém - bod na přímce od lowlevel věcí (abstrakce hardware) přes grafický toolkit po highlevel věci (kompletní desktopové prostředí) Qt se snaží dělat věci, které v klasickém pojetí řešil (a pravděpodobně dosti často lépe) Xserver na straně jedné, na straně druhé dělá věci, které jsou daleko za rámcem toho, co bych očekával od grafického toolkitu ... a tudíž vázat se čistě na prostředky Qt je IMHO zbytečně omezující
obávám se, že z druhé strany zájem prostě není - co jim to přinese?no, "v podstatě" ... z "proti" považuju body 2 a 4 za celkem podstatný problém, bohužel :-/Obojí to jsou především organizační věci - bude-li zájem, tak si je dotyční domluví rychle.
Však jo, nemám nic proti jádru, které využívá kdelibs (nebo jinou knihovnu/platformu). Pouze mi připadá nevhodné, když se omezí pouze na tuto platformu - je pak dostupné pro omezenou skupinu uživatelů a ubývají mu tak potenciální vývojáři, testeři a jádru se ve výsledku dostává méně pozornosti, než by zasloužilo. To všechno ale neplatí o prohlížeči, který může být výrazně jednodušší (špinavou práci dělá především jádro) a integrací s platformou u něj dává větší smysl, protože je s uživatelem v přímém kontaktu. Ve vztahu WK a KDE stojí za zmínku ještě jedna okolnost: podobně složité věci z Qt KDE běžně používá (namátkou třeba Arthur) a nikdo nebrble, že nad tím nemá kontrolu atd. U KHTML/WK je to ale kvůli jejich historii nemyslitelné...U samotného vykreslovacího jádra podle mě stačí, že kreslí přes tytéž knihovny, jako program (= Qt v případě KDE), a závislost na vyšších věcech (kdelibs a vyšší) je spíš na škodu.potíž této úvahy je v tom, že to nelze brát jakou jednorozměrný problém - bod na přímce od lowlevel věcí (abstrakce hardware) přes grafický toolkit po highlevel věci (kompletní desktopové prostředí) Qt se snaží dělat věci, které v klasickém pojetí řešil (a pravděpodobně dosti často lépe) Xserver na straně jedné, na straně druhé dělá věci, které jsou daleko za rámcem toho, co bych očekával od grafického toolkitu ... a tudíž vázat se čistě na prostředky Qt je IMHO zbytečně omezující
obávám se, že z druhé strany zájem prostě není - co jim to přinese?Kde jsem říkal, že se v dohledné době (za současné situace) spojí? Jen jsem psal, že pokud se situace změní a bude o spojení zájem, budou největší překážky organizačního rázu...
Však jo, nemám nic proti jádru, které využívá kdelibs (nebo jinou knihovnu/platformu). Pouze mi připadá nevhodné, když se omezí pouze na tuto platformu - je pak dostupné pro omezenou skupinu uživatelů a ubývají mu tak potenciální vývojáři, testeři a jádru se ve výsledku dostává méně pozornosti, než by zasloužilo.otázka je, zda tento "(ne)dostatek pozornosti" je či není dostatečně vyvážen ústupky, které se (ne)musí udělat v zájmu nezávislosti na platformě řekl bych, že psí hrob je v tom, že jádro prohlížeče je docela monolit - určitě by se dalo rozsekat na menší kusy, některé navázané na určitou platformu (a třeba vyměnitelné pro jinou) a některé zcela platformově nezávislé ostatně pokusy na toto téma byly (minimálně GTK port)
To všechno ale neplatí o prohlížeči, který může být výrazně jednodušší (špinavou práci dělá především jádro) a integrací s platformou u něj dává větší smysl, protože je s uživatelem v přímém kontaktu. Ve vztahu WK a KDE stojí za zmínku ještě jedna okolnost: podobně složité věci z Qt KDE běžně používá (namátkou třeba Arthur)tímto ses ovšem dotknul takové implicitní myšlenky v mém původním příspěvku, že Qt absorbovalo spoustu věcí, které by logicky patřily do kdelibs ... ostatně o tom již výše, že Qt je dnes všechno možné, jenom ne jednoduchý x-window toolkit takže za těch pět let může být "integrace s platformou, přímý kontakt s uživatelem" v případě browseru otázkou integrace s Qt, nikoliv s kdelibs
a nikdo nebrble, že nad tím nemá kontrolu atd. U KHTML/WK je to ale kvůli jejich historii nemyslitelné...nejen kvůli historii, ale i kvůli budoucnosti ... připadá mi, že stávající vývojáři KHTML jsou ti poslední mohykáni, kteří bojují bitvu, aby KDE využívalo to nejlepší, co mu může Qt nabídnout, ale stálo si za svými zájmy, zatímco zbytek se vydal pseudopragmatickou cestou přizpůsobit KDE tomu, co nabízí Qt - ale Qt tu není kvůli KDE, nýbrž kvůli komerčním zájmům, které ne vždy vedou k věcem, které jsou uživatelům KDE ku prospěchu ... tedy alespoň KDE v klasickém pojetí coby "nejlepšího un*xového desktopového prostředí" (které už ovšem asi vzalo zasvé
)
(což zase zavdává podnět k úvaze na téma jiného opakování historie, a to zda nové KDE podobně jako Firefox přitáhne windowsovské vývojáře, kteří posléze začnou převládat, a KDE začne řešit problémy špatného chodu na un*xech )
a kde jsem říkal, že ty jsi říkal?obávám se, že z druhé strany zájem prostě není - co jim to přinese?Kde jsem říkal, že se v dohledné době (za současné situace) spojí? Jen jsem psal, že pokud se situace změní a bude o spojení zájem, budou největší překážky organizačního rázu...
- jenom poznamenávám, že tyto překážky, byť organizační, považuju právě za ty největší ...
otázka je, zda tento "(ne)dostatek pozornosti" je či není dostatečně vyvážen ústupky, které se (ne)musí udělat v zájmu nezávislosti na platformě řekl bych, že psí hrob je v tom, že jádro prohlížeče je docela monolit - určitě by se dalo rozsekat na menší kusy, některé navázané na určitou platformu (a třeba vyměnitelné pro jinou) a některé zcela platformově nezávisléChce se mi říct, že porty WebKitu ukazují, že to možné je a docela dobře. Ale radši budu opatrnější a postavím to tak: do roka a do dne se nejpozději ukáže, jestli je to opravdu správný přístup.
tímto ses ovšem dotknul takové implicitní myšlenky v mém původním příspěvku, že Qt absorbovalo spoustu věcí, které by logicky patřily do kdelibs ... ostatně o tom již výše, že Qt je dnes všechno možné, jenom ne jednoduchý x-window toolkit takže za těch pět let může být "integrace s platformou, přímý kontakt s uživatelem" v případě browseru otázkou integrace s Qt, nikoliv s kdelibsJe fakt, že se postupně zmenšuje volnost desktopových prostředí - z jedné strany přibývá standardizovaných rozhraní, konfigurací, úložišť atd. a z druhé strany toho umí základní knihovny čím dál více.
připadá mi, že stávající vývojáři KHTML jsou ti poslední mohykáni, kteří bojují bitvu, aby KDE využívalo to nejlepší, co mu může Qt nabídnout, ale stálo si za svými zájmy, zatímco zbytek se vydal pseudopragmatickou cestou přizpůsobit KDE tomu, co nabízí QtTak tady zase ukáže až za čas, která cesta se víc přiblíží k "nejlepšímu un*xovému prostředí".
(což zase zavdává podnět k úvaze na téma jiného opakování historie, a to zda nové KDE podobně jako Firefox přitáhne windowsovské vývojáře, kteří posléze začnou převládat, a KDE začne řešit problémy špatného chodu na un*xech )Sobecky bych jakékoliv un*xové DE na windows přivítal, abych se zbavil debilního explorera, ale přesně z tohoto důvodu bych byl nerad, kdyby vzniklo.
... Tak tady zase ukáže až za čas, která cesta se víc přiblíží k "nejlepšímu un*xovému prostředí".obávám se, že čas toho příliš neukáže, protože nebude s čím srovnávat - alternativy patrně zajdou na úbytě ... budeme vědět, jestli máme věci dobré, ale nikdy se nedozvíme, jestli bychom neměli lepší, kdyby část vývojářů dala přednost té druhé cestě
mno, mě je silně proti srsti už jenom to, že KDE se hodně vydalo cestou kopírování Applu (a z toho především věcí, které stejně dělá i Microsoft) ... dodnes mě nadzvedává ze židle problém adresář vs. složka - když si někdo pustí KDE nad Macovským filesystémem, ať si tomu klidně říká složky, ale jestliže mi KDE běží nad ReiserFS, a na příkazové řádce mám(což zase zavdává podnět k úvaze na téma jiného opakování historie, a to zda nové KDE podobně jako Firefox přitáhne windowsovské vývojáře, kteří posléze začnou převládat, a KDE začne řešit problémy špatného chodu na un*xech )Sobecky bych jakékoliv un*xové DE na windows přivítal, abych se zbavil debilního explorera, ale přesně z tohoto důvodu bych byl nerad, kdyby vzniklo.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
6.4.2008 11:48
rmdir, tak ať jdou do háje s "remove folder" - jasně, blbina, ale tohle je jen špička ledovce, která je viditelná a dobře se to na ní ilustruje
takže natažení windowsovských programátorů (které už se zlehka děje) se opravdu děsím
ale už bych nechal tuto diskusi spát, pokračování v hospodě
mno, mě je silně proti srsti už jenom to, že KDE se hodně vydalo cestou kopírování Applu (a z toho především věcí, které stejně dělá i Microsoft) ... dodnes mě nadzvedává ze židle problém adresář vs. složka - když si někdo pustí KDE nad Macovským filesystémem, ať si tomu klidně říká složky, ale jestliže mi KDE běží nad ReiserFS, a na příkazové řádce mámVe všem +1rmdir, tak ať jdou do háje s "remove folder" - jasně, blbina, ale tohle je jen špička ledovce, která je viditelná a dobře se to na ní ilustruje takže natažení windowsovských programátorů (které už se zlehka děje) se opravdu děsím