PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
A zadruhe: Zajimalo by me, jak to spoustis. Normalne .exe v linuxu nenastartuje. Jedine v DosEmu a v tom ti pojede i .com a .bat a vsecko co v dosu.
Takze rada: Nainstalovat DosEmu.
Peter
Co neni na freshmeat, jako by ani neexistovalo.
Peter
si pak mohou myslet, že tento (MZ) formát je Linuxem podporován. A rovněž se jako v tomto případě diví, že to nespouští 8 a 16 bitové (.com) aplikace. Ale wine je psaný na spouštění POUZE 32 bitových aplikací, na 8 a 16 bitové je zde výše zmíněné DOSEmu, nebo pro Xka xdos (opět nejsem dost přesný 16 bitové aplikace určené pro platformu Win16 a Win16s spustit většinou umí).
To jen tak pro pořádek, ale v zásadě souhlasím
Co třeba DosBox?
Kromě toho, spustitelné soubory v UNIXu žádnou specifickou příponu nemají. Spouštění souborů s příponou .exe (binárek pro Windows) určitě možné není. Zpravidla se to dělá tak, že se v nějakém klikacím prostředí nastaví otvírání souborů .exe ve Wine nebo jiném vhodném emulátoru. Nejde tedy o spuštění v pravém slova smyslu, přestože kdekdo křičí Wine Is Not an Emulator...
No nevím, co je tohle za řeči. Poslední DOS byl někdy v pětadevadesátém, takže není důvod, proč nepoužít sarší emulátor. DosBox mi funguje skvěle.
) a jen ho někdo vytáhl.
Jo takhle, tak přece jen jsem zase blbec já. Teď ještě vytáhnout „Proč je Linux pomalejší než Windows 95“ a je to.
)
<flame>Další anonym, další blbé řeči...</flame>
Kdybych uvažoval takovým způsobem, mohl bych klidně tvrdit, že kenel umí „spouštět“ skripty v PHP, Pythonu, Ruby, Perlu a vůbec celkem jakékoliv formáty. Nejde ale o spouštění spustitelných souborů. Stačí jen, aby kernel věděl, kde je interpret příslušného formátu...
Zdaleka ne každá distribuce má tuhle rádoby zajímavou fičuru zapnutou a zdaleka ne každý uživatel ji chce. Já tento nesmysl nechci, protože chci vědět, co dělám. Měl bych snad mít povoleno, aby mi jakýkoliv skript směl spouštět binárky z Windows? To je špatný vtip, nebo je to míněno vážně??? (Ruku na srdce, kolik lidí spouští Wine pod odděleným uživatelským účtem? A kolik lidí má ve Wine zakázaný pověstný disk Z?)
Shell (například bash) spouští skripty i bez jakékoliv kernelové podpory a bez první řádky s #!... Ale v tomhle má pointa vůbec netkví. Tvrdím pouze že .exe soubory v Linuxu spustit nelze. Sice je sám denně „spouštím“, ale vždy jde o emulaci, ať už ji spustí sám kernel nebo KDE nebo někdo jiný. Kernel-based Wine zatím neexistuje. Tak jaké lži tady vypouštím???
Kernel-based Wine zatím neexistuje.Ja si napriklad pamatuji, ze nekdy pred osmy lety se objevil wineservmod. Kdybyste se alespon obtezoval pouzit google, nez zas zacnete neco blabolit...
Řeči o blábolení by si měl nechat od cesty především ten, kdo sám blábolí nesmysly.
Koho zajímá, co existovalo někdy před osmi lety? Dnes kernel-based wine v distribucích běžně není. Nehledě na to, že jakékoliv mletí o Wine je v podstatě off-topic. Stačí zběžné přečtení otázky a hned je jasné, že řeč byla pouze o souborech .com.
Spuštění procesu v Linuxu je složitá procedura, z formátu ELF se čte spousta tabulek, pak následuje hledání knihoven, několik fází počítání offsetůBezne procesy vznikaji pomoci fork nebo clone vzdy z jineho jiz beziciho procesu. Vas popis je dost mimo.
Tvrdite, ze vec jako wineservmod neexistuje, ale ukazalo se ze ano. Chcete rict, ze jste nelhal?
Co Vás na té vykopávce tak fascinuje? Možná se ukázalo, že před osmi lety existoval pokus něco takového vytvořit. Ukažte mi jednu distribuci, která pochází z letošního roku a něco takového má. Pak se můžeme bavit dál. Co takhle použít Google? Moc tam toho není, že...
Než mě příště nařknete ze lži, zkuste si aspoň napočítat do pěti...
Bezne procesy vznikaji pomoci fork nebo clone vzdy z jineho jiz beziciho procesu. Vas popis je dost mimo.
Podle tohoto výroku se tedy procesy dělí na „běžné“ (pouze shell) a „mimořádné“ (cokoliv jiného). Já ale považuji například soffice taktéž za běžný proces. Je třeba odlišit podstatné od nepodstatného. Samozřejmě, že shell volá fork, aby mohl vůbec něco spustit. Podstatné ovšem je, co potom dělá exec. Ten dělá přesně to, co jsem psal. Takže můj popis není ani trochu mimo.
Pozor na věc, co kdyby si Vaše nesmysly přečetl někdo méně zkušený a pak je šířil dál...?
Tvrdite, ze vec jako wineservmod neexistuje, ale ukazalo se ze ano. Chcete rict, ze jste nelhal?V současnosti nic takového "v provozu" není. Jen se objevily nové snahy o vytvoření takové věci.
Nejde tedy o spuštění v pravém slova smyslu, přestože kdekdo křičí Wine Is Not an EmulatorWine _není_ emulátor. Programy se spouštějí přímo na procesoru - emulátor by to byl, kdyby programové instrukce nějak překládal a interpretoval po svém - to Wine nedělá. Posílá ty instrukce přímo do procesoru, tak jako by to na jeho místě dělal Windows. Jediný rozdíl je v komunikaci spouštěného programu se systémovými knihovnami - zde přichází ke slovu "aplikační vrstva" která volání překládá do "linuxového světa" - samotný program ale pod žádným emulátorem neběží, běží samostatně,přímo na procesoru, jako jakákoli jiná aplikace.
To je zcela správný rejp, nic proti tomu. Aplikace běží přímo na procesoru. Ale to ještě neznamená, že se spouští. Spuštění procesu v Linuxu je složitá procedura, z formátu ELF se čte spousta tabulek, pak následuje hledání knihoven, několik fází počítání offsetů, vyplňování relokačních tabulek, nastavování tisíců pointerů... Pokud je mi známo, Linux žádné spuštění (v tomto slova smyslu) .exe souborů neprovádí. O to se stará Wine se svými vlastními knihovnami.
Kdybych ten rejp dotáhl do extrému, program v Javě spuštěný na JVM s JIT-kompilátorem taktéž běží přímo na procesoru, bez další interpretace. Ale soubor .class je, stejně jako .exe, bez dalšího zpracování bezcenný. V případě souboru .class je mnohem víc důvodů, proč ho Linux neumí spustit (bytecode nezávislý na platformě, potřeba run-time podpory, ...), ale jinak je téměř tatáž úvaha.
Dokud neexistuje kernel-based Wine, Linux neumí spustit .exe. Howgh.
Dokud neexistuje kernel-based Wine, Linux neumí spustit .exe. Howgh.Já taky netvrdím, že linux umí spustit .exe. Já tvrdím, ne křičím, "Wine Is Not an Emulator!!!"

Tiskni
Sdílej: