Google Chrome 126 byl prohlášen za stabilní. Nejnovější stabilní verze 126.0.6478.55 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán Mozilla Firefox 127.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 127 je již k dispozici také na Flathubu a Snapcraftu.
Byla vydána (𝕏) nová verze 9.5 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Společnost Raspberry Pi dnes vstoupila na Londýnskou burzu jako Raspberry Pi Holdings plc (investor).
Do 17. června do 19:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | červen 2024 doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.
Apple na své vývojářské konferenci WWDC24 (Worldwide Developers Conference, keynote) představil řadu novinek: svou umělou inteligenci pojmenovanou jednoduše Apple Intelligence, iOS 18, visionOS 2, macOS Sequoia, iPadOS 18, watchOS 11, …
Vyšla nová verze XMPP (Jabber) klienta Gajim, která přidává podporu reakcí pomocí emoji (XEP-0444: Message Reactions) a citace zpráv (XEP-0461: Message Replies). Přehled dalších vylepšení je k dispozici na oficiálních stránkách.
Po po téměř roce vývoje od vydání verze 5.38 byla vydána nová stabilní verze 5.40 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 75 vývojářů. Změněno bylo přibližně 160 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Aplikace vyžadující X Window System mohou běžet nad Waylandem díky XWaylandu. Jak ale nad Waylandem spustit X display manager nebo X správce oken, když se o správu oken stará kompozitor Waylandu (například Weston)? Odpovědí může být Xweston. [Arch Linux Forums, reddit]
Tiskni Sdílej:
Spousta lidí se snaží pošpinit Wayland tvrzením že všechny drivery je potřeba přepsat a tedy obzlášť tvůrci proprietárních driverů se k tomu mít nebudou. Ale Wayland používá převážně věci který už existujou, do proprietárních driverů je potřeba dopsat jen relativně málo aby na nich mohl Wayland bežet.Čiže je potrebné všetky ovládače prepísať.
Ne,z výše uvedeného mi plyne, že protistrana by klidně mohla říci "ano", zdá se, že je to subjektivní (co je to "přepis"? co je to "málo", teď 10% a v budoucnu, až to nabobtná jako X, to bude proti současnému stavu 99%?) raděj bych tady viděl vyjádření někoho, kdo ty drivery fakt píše, nežli nadšené hýkání fanklubu změn pro změny, podle kterých cokoli se blíží stáří dvou let už je vykopávka, kterou je nutno nahradit
Některé aplikace tunelováním X přes ssh ovládám skoro denněHmm ja to parkrat zkousel, hlavne v dobach, kdy jsem si neumel udelat ssh tunel a tak jsem takhle spoustel vzdalene iceweasel, abych mohl nastavit nejaky port forward na adsl routeru (pres links to neslo...), a bylo to teda silene nepouzitelne, hrozne pomale, hrozne lagy, obcas se to proste zaseklo a s tim i cela moje lokalni Xka...naprosto nesrovnatelne s teamviewerem nebo sveho casu freenx, co se dalo pouzivat i na hodne spatnych linkach. Takze mozna na lokalni siti si umim predstavit, ze to funguje, ale i kdyz bylo na obou stranach adsl, bylo to totalne nepouzitelne.
Ony už se přes tu síť ve většině případů stejně posílaly jen bitmapy.to ale už považuju za krok zpět ... ono se to hezky křičí "je to pomalé a nepraktické", když by být nemuselo, kdyby to předtím někdo "nerozbil" (viz vývoj popsaný výše, např. proč musí Qt řešit kreslení primitiv, když je umí kreslit X server, a stačilo by mu o to říct, jak se ve verzích <4 dělo ...)
Ze stavu "o vsechno se stara X server" se postupne zodpovednost rozdelila na vic mist.nějak nerozumím, co je na tom tak zdravého, proč je vůbec potřeba mít to na více místech nad rámec modularity X ...
Nizky HW veci se presunuly do kernelu.v souvislosti s výše uvedeným nechápu, co mám vidět za výhodu v tom, že je jeden moloch zeštíhlen na úkor toho, že druhý ztloustne
Spousta veci se extrahovala do knihoven ktery muze pouzit i nekdo jiny. (Tak treba libevdev pro cteni /dev/evdev* zarizeni.)viz výše o modularitě ... k tomu snad nebylo potřeba znovu vynalézat kolo
Vyvoj waylandu pomohl odhalit hodne bugu v Mese (OpenGL).to je zajisté užitečný vedlejší efekt, ale jako argument pro vývoj to má nulovou hodnotu
Aplikace/frameworky muzou kreslit s OpenGL, ktery je standardni a dostupny na spouste jinejch platforem, tj. ta platforme zavisla cast je o dost mensi.no, nevím, proč by nemohly i tak - popravdě, tvrzení o "fakt pomalém" XGL se mi nějak nezdá ... já tedy po letech nevím, jestli to bylo zrovna XGL nebo nějaký jiný čert, ale kdysi mi Quake 3 Arena chodil na Linuxu líp než na Woknech; o velikosti jeho platformově závislé části nemám ponětí, ale řekl bych opengl jako opengl ...?
á tedy po letech nevím, jestli to bylo zrovna XGL nebo nějaký jiný čertXGL bylo zalezitost XFree 3.x. Pokud dobre pamatuju, tak uz od verze 4 se pouzival direct rendering pri lokalnim pouziti. Na druhou stranu nevidim duvod, proc by XGL bylo nejak extra pomale. Opecne OpenGL je asynchronni rozhrani a ma separaci mezi klintskymi a renderovacimi objekty, takze provest jeho sitovou serializaci rozumne rychle by nemel byt problem. Samozrejme v pripade, kdy se provadi rendering lokalne, je to zbytecny overhead, a OpenGL knihovna muze automaticky zvolit direct rendering nebo sitovou serializaci.
Díky za komentář.
Moznost pouzit X pres sit mi bude taky chybet.
Mně taky. Šlo by to nahradit přes Spice? Dneska používám Xka tunelovaná přes SSH pro 3D grafiku (nic moc náročného, ale jde o to, aby 3D fungovalo).
PS: Moznost pouzit X pres sit mi bude taky chybet. Ale vim ze to neni rozhodnuti z rozmaru, ale vychazi to z principu.V podstatě to ani není až tak velký problém, jen to prostě je mimo Wayland. Vcelku se nabízí možnost spustit na vzdáleném stroji nějakou proxy, která nakreslené buffery pošle na lokální displej. O nějakém snažení už jsem zaslechl. Co bych ale ocenil, je síťový přenos událostí už na úrovni toolkitu. Aplikace by se namísto k displeji připojila k GUI serveru a posílala mu, co chce zobrazit, a přijímala, co provedl uživatel. Narozdíl od X by to bylo na úrovni primitiv toolkitu, nikoliv kreslení čar a stisků kláves. Například v Qt by se přenesl signál o kliknutí na tlačítko, namísto stisknutí myšítka, nebo při stisku písmenka by se objevil text v QLineEdit, ale po síti by se nic nepřeneslo, protože aplikace by měla odchycený signál na potvrzení dialogu. Potíž je, co s widgety specifickými pro aplikaci, které si kreslí, jak je napadne.
Co bych ale ocenil, je síťový přenos událostí už na úrovni toolkitu. Aplikace by se namísto k displeji připojila k GUI serveru a posílala mu, co chce zobrazit, a přijímala, co provedl uživatel. Narozdíl od X by to bylo na úrovni primitiv toolkitu, nikoliv kreslení čar a stisků kláves. Například v Qt by se přenesl signál o kliknutí na tlačítko, namísto stisknutí myšítka, nebo při stisku písmenka by se objevil text v QLineEdit, ale po síti by se nic nepřeneslo, protože aplikace by měla odchycený signál na potvrzení dialogu.Tady bych viděl hlavní potíž ve změnách protokolu - jednak se GUI toolkity vyvíjí velmi rychle, druhak potřebuješ nějak syncat schopnosti klienta, serveru a programu. To buď vede na využívání jen malé vzájemně kompatibilní podmnožiny schopností toolkitu (takže můžeš rovnou používat ty klapnutí, kliknutí a čáry), nebo musíš zajistit sync verzí na klientovi a serveru (vem do úvahu spojení k víc serverům různých architektur naráz), nebo budeš pokaždé přenášet část knihovny ze serveru na klienta. Jako myšlenka dobrý, ale nedokážu si představit, že by v praxi přínosy převážily problémy při nasazování.
Jako myšlenka dobrý, ale nedokážu si představit, že by v praxi přínosy převážily problémy při nasazování.+1 Nic proti waylandu, ale trochu mě děsí ta halda lidí, co se vždy snaží nějak obhájit to, že už možná nikdy nebude fungovat klasický X11 forwarding a spouštění jednotlivých aplikací na vzdálených strojích vykreslujících své okno dolokální session. Však ono se to nějak vyřeší, že. To už je snad lepší, když řeknou, že je to nezajímá, protože to oni nepoužívají. A ani představa, že různé vzdálené aplikace budou mít namísto jednoho standardu různé požadavky na lokální software mi nepřijde zrovna lákavá.
Škoda. Občas není špatný se podívat, jestli ti před 10 lety neujel vlak.Rétorika podomního obchodníka. Do toho, co používám ke své práci a potažmo i zábavě je ti hovno. Spousta lidí používá windows ke své spokojenosti nebo s jejich pomocí vydělává a přesto nemají potřebu je druhým vnucovat.