Po 9 týdnech vývoje od vydání Linuxu 6.14 oznámil Linus Torvalds vydání Linuxu 6.15. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies.
plwm je nový, poměrně minimalistický správce oken pro X11. Podporuje dynamické dláždění okny, plochy, pravidla pro okna atd. Zvláštností je, že je napsaný v logickém programovacím jazyce Prolog. Používá implementaci SWI-Prolog.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Sean Heelan se na svém blogu rozepsal o tom, jak pomocí OpenAI o3 nalezl vzdálenou zranitelnost nultého dne CVE-2025-37899 v Linuxu v implementaci SMB.
Jiří Eischmann v příspěvku na svém blogu představuje typy, jak lépe chránit své soukromí na mobilním telefonu: "Asi dnes neexistuje způsob, jak se sledování vyhnout úplně. Minimálně ne způsob, který by byl kompatibilní s tím, jak lidé technologie běžně používají. Soukromí ovšem není binární věc, ale škála. Absolutního soukromí je dnes na Internetu dost dobře nedosažitelné, ale jen posun na škále blíže k němu se počítá. Čím méně dat se o vás posbírá, tím nepřesnější budou vaše profily a tím méně budou zneužitelné proti vám."
Byla vydána nová stabilní verze 25.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Warbler. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Multiplatformní open source spouštěč her Heroic Games Launcher byl vydán v nové stabilní verzi 2.17.0 Franky (Mastodon, 𝕏). Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 26 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Klávesnice IBM Enhanced Keyboard, známá také jako Model M, byla poprvé představena v roce 1985, tzn. před 40 lety, s počítači IBM 7531/7532 Industrial Computer a 3161/3163 ASCII Display Station. Výročí připomíná článek na zevrubném sběratelském webu Admiral Shark's Keyboards. Rozložení kláves IBM Enhanced Keyboard se stalo průmyslovým standardem.
Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
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